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] rebuilding stackmaptable attribute without loading the classes
Date Wed, 07 Nov 2007 12:24:09 GMT
Hi Mikhail,

Thinking about it, my last statement does not make any sense (*blush*). Please ignore it.


To summarize this point: I am still not sure whether using the existing StackMapTable (before
instrumentation) will solve the "class load" problem when verifying the instrumented code.

Thanks,
Asaf


----- Original Message ----
From: Mikhail Loenko <mloenko@gmail.com>
To: dev@harmony.apache.org
Sent: Wednesday, November 7, 2007 12:35:36 PM
Subject: Re: [drlvm][verifier] rebuilding stackmaptable attribute without loading the classes


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?

Thanks,
Mikhail






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





__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message