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] rebuilding stackmaptable attribute without loading the classes
Date Wed, 07 Nov 2007 10:35:36 GMT
Hi Asaf,

2007/11/7, Asaf Yaffe <asaf_yaffe@yahoo.com>:
> Hi Mikhail,
> The existing StackMap attribute (before instrumentation) can help only for the code that
was part of the method *before* is was instrumented. It cannot help with code *added* by instrumentation.

I did not quite understand this. Do you mean information about the
classes references to which are added by instrumentation, or something
else? Could you please provide an example?


Therefore I see two options here:
> 1. Find a way for the instrumentor to annotate the the added code with enough data so
that the verifier can use this information without the need to load classes
> 2. Delay the entire StackMap computation process to the point where JNI is available
(i.e., when VM_Start JVMTI event fires) and use RedefineClasses to instrument the (bootstrap)
classes already loaded.
> The main issue I see with Option 2 is that RedefineClasses is not a mature feature in
most JVM out there (some cannot redefine certain bootstrapping classes at all), and relying
on this feature will hurt the robustness of our tools.
> Any thoughts about option 1? Maybe other suggestions?
> Thanks,
> Asaf
> ----- Original Message ----
> From: Mikhail Loenko <mloenko@gmail.com>
> To: dev@harmony.apache.org
> Sent: Tuesday, November 6, 2007 11:40:09 AM
> Subject: [drlvm][verifier] rebuilding stackmaptable attribute without loading the classes
> 2007/11/6, Asaf Yaffe <asaf_yaffe@yahoo.com>:
> > 2. Class Load issues (as described in my previous post): are there
>  any options for running the verifier when classes cannot be loaded as
>  necessary? Please open a separate mail thread for this (prefixed with
>  [drlvm][verifier]).
> If we have a point where e.g. two types are comming like class A and
>  class B
> and the differrent successor instruction expect to see there two other
>  classes
> like class C and class D, then for the stackmap we should place such a
>  class
> X so that A and B are assignsable to X and X is assignable to C and D.
> If all classes might be loaded (like in case of javac who usually
> generates stackmap table attribute) than it's an easy task.
> If nethier of A, B, C, and D might be loaded then the task becomes a
> bit challenging :)
> What comes to my mind is if we have code and stackmap of the original
> class (before instrumentation), we could extract some info from there.
> For example if original class implies that A is assignable to B, then
> we could choose X=B as a solution for the above
> Thanks,
> Mikhail
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com

View raw message