harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Asaf Yaffe <asaf_ya...@yahoo.com>
Subject Re: [drlvm][verifier] Using the Harmony verifier code for computing the StackMapTable attribute
Date Wed, 31 Oct 2007 09:18:45 GMT
Hi Mikhail,

Thank you for the prompt reply. This information is encouraging!

Here are the answers to your questions:

IsStackMapTableAttributeValid(): the original idea behind this function is to optimize the
process and do not compute the StackMapTable if not necessary. However, after considering
your options, it seems that only option 3 makes sense and hence we will not gain any performance
benefit (because we effectively run full verification). I also think that the TPTP instrumentation
engine has enough knowledge to know if a computation is really needed. Therefore, lets consider
option 3 (for completeness) but I think this function is not required for TPTP.

- subroutines: we can assume there are no subroutines (jsr/ret instructions). Java 6 classes
should not have them in the first place. Our instrumentation engine may use these instructions
(e.g., some probe injections in Probekit use jsr/ret), but we can update the engine.
- dead-code: while our instrumentation engine does not add "dead-code", I assume that the
code we instrument may contain dead code. We should further discuss what are the best ways
of handling this case (dead-code removal, "nop-ing" the dead code, etc).
- extending the constant pool: no problem. We have the necessary functionality to arbitrarily
modify the constant pool. Exposing this functionality to the verifier seems like a simple
thing to do.

Best regards,

----- Original Message ----
From: Mikhail Loenko <mloenko@gmail.com>
To: dev@harmony.apache.org
Sent: Tuesday, October 30, 2007 5:51:23 PM
Subject: Re: [drlvm][verifier] Using the Harmony verifier code for computing the StackMapTable

Hi Asaf!

Welcome to Harmony dev forum :)

I beleive current implementation of Harmony verifier [1] already covers
of what's necessary for you. It contains both old-style (Java5)
and new-style (StackMapTable attribute based) one. So, it seems like
a lightweigh extension to what Harmony already has would be enough.

So, I have some questions.
IsStackMapTableAttributeValid() - this seems to be the same as a full
(or partial) new-style verification of a method. The following three
ways are easiest to implement given current Harmony verifier design

1) check only structure of the attribute
2) the structure PLUS content except assignability of not-loaded
classes (i.e. make a full verification WITHOUT checking assignability
of not-loaded classes)
3) load missing classes and make a full verification

Will anything from above suit your needs?

Can the method byte-codes contain subroutines? Dead (unreachable) code?
as a result of stackmaptable calculation it might be necessary to
constant pool of the class. Is it acceptable in your environment?



2007/10/30, Asaf Yaffe <asaf_yaffe@yahoo.com>:
> Hi,
> My name is Asaf Yaffe and I am a committer on the Eclipse Test and
 Performance Tool Platform (TPTP) Java Profiler project. We are currently
 working on updating our Binary Code Instrumentation (BCI) engine to
 support the new Java 6 class file format (version 50.0) and the new
 StackMapTable attribute. When the BCI engine modifies the byte-codes of a
 method, it must recompute the StackMapTable attribute to successfully pass
 the Java 6 verifier. The current implementation of Java 6 gracefully
 "falls-back" to the old verification scheme (which does not depend on
 the StackMapTable attribute) in face of a missing/invalid StackMapTable
 attribute. This may not be the case in future Java versions, and tool
 writers are encouraged to update their BCI-based tools (see here for more
 information: https://jdk.dev.java.net/verifier.html).
> Instead of developing StackMapTable calculation for the BCI engine,
 we would like to explore the option of reusing code from the Harmony
 byte-code verifier to recompute the StackMapTable of a method from its
 byte-codes. Ideally, we would like to have a stand-alone library (provided
 in source or binary form – exact distribution model should be
 discussed) which exports two APIs:
> -    IsStackMapTableAttributeValid(): given the method byte-codes and
 StackMapTable, checks whether the StackMapTable is valid.
> -    RecomputeStackMapTableAttribute(): given the method byte-codes,
 produces a new valid StackMapTable that can be used by the Java 6
 verifier of any Java 6-compliant JVM.
> With best regards,
> Asaf Yaffe
> Eclipse TPTP Committer, JVMTI Profiler component.
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com

Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message