harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Loenko" <mloe...@gmail.com>
Subject Re: [drlvm][verifier] Dead-code and Java 6 verification issues
Date Tue, 06 Nov 2007 09:04:20 GMT
Hi Asaf,

thanks for separating this discussion into a different thread!

2007/11/6, Asaf Yaffe <asaf_yaffe@yahoo.com>:
> Hi,
> This mail thread is for discussing Java 6 verification issues related to dead-code. The
issue was first brought up by Mikhail Loenko in the "[drlvm][verifier] Using the Harmony verifier
code for computing the StackMapTable attribute" mail thread.
> Here's a general overview of this subject for anyone who wishes to join this discussion:
the Java 6 verifier requires the presence of StackMap data at the beginning of each basic
block. This requirements is true for all types of blocks, including "dead-blocks" (i.e., blocks
unreachable from the first block in a method's control-flow graph). The problem is that StackMaps
are computed using a control-flow/data-flow algorithm which (by definition) processes only
reachable blocks, and hence cannot be used on "dead" blocks. In short - StackMaps cannot be
computed for "dead" blocks.
> So, the main question is this: what do we do with dead blocks? How do we compute their
> One possible option is to remove the dead-code from the method by means of a dead-code
removal algorithm applied to the method byte codes. Another possible option (implemented by
the ASM BCI library) is to "nop" all instructions in the dead block up to the last one, modify
the last instruction to "athrow" and assigning a StackMap of [][java/lang/Throwable] to this
block [1].
> Any other thoughts, suggestions or ideas?

As I understand, there are three options possible:
1) remove the dead code,
2) provide valid stackmaps for it, and
3) simplify the code and provide stackmaps for the simplified code

I like the idea of simplification which you pointed, but I think this
approach is not quite correct in general: the dead code might be in
the try block. In this case stackmap locals at the dead block should
be assignable to stackmap at the handler_pc instruction.

In other words, if catch block accesses locals defined before the try block and
this try block has a dead code, then stackmap for the dead code can't
have empty locals: otherwise Java6 verification would fail

I suggest that we take locals from the stackmap of the first
instruction after the dead code. And we modify try blocks that have
dead code in the beginning or in the end so that dead code is excluded
from try blocks (unless it's in the middle)


> Thanks,
> Asaf
> [1] ASM developer guide: http://asm.objectweb.org/doc/developer-guide.html#deadcode
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com

View raw message