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 Thu, 08 Nov 2007 10:25:02 GMT
Hi Pavel,

JVMTI does not expose any functionality for loading classes. If my native application needs
to load classes, it must use JNI. As previously discussed, JNI is not available to a JVMTI
Agent until the VM_Start event fires.

JNI availability aside, you also raise an important issue of potentially causing circular
class loads when trying to load classes in the context of the ClassFileLoadHook event. We
will definitely need to take this into account in our design.

Thanks,
Asaf


----- Original Message ----
From: Pavel Pervov <pmcfirst@gmail.com>
To: dev@harmony.apache.org
Sent: Wednesday, November 7, 2007 4:47:54 PM
Subject: Re: [drlvm][verifier] Using the Harmony verifier code for computing the StackMapTable
attribute

Asaf,

What particular JNI functionality you may need is unavailable when
 class
file load hook (CFLH) is generated for j.l.Object?

The only problem I can see here is that if you try to load any class in
 a
callback to CFLH for j.l.Object, it will require loading j.l.Object as
superclass and ClassCircularityError will be reported for j.l.Object.

WBR,
    Pavel.

P.S. It looks like it is only possible to instrument j.l.Object with a
 call
to RedefineClasses...

On 11/7/07, Asaf Yaffe <asaf_yaffe@yahoo.com> wrote:
>
> Hi Pavel,
>
> What you said about ClassFileLoadHook *may* be true for Java-based
 Agents
> (implementing the java.lang.instrument.* interfaces), but is not true
 for
> native JVMTI agents. All JVMs supporting the
> can_generate_all_class_load_hook_events capability (basically all
 major
> 1.5+ JVMs on the market) sends the ClassFileLoadHook for *all*
 classes
> (even for java.lang.Object). This is fully documented in the JVMTI
 spec
> (see
>
 http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#ClassFileLoadHook
> ).
>
> Regards,
> Asaf
>
> ----- Original Message ----
> From: Pavel Pervov <pmcfirst@gmail.com>
> To: dev@harmony.apache.org
> Sent: Wednesday, November 7, 2007 4:17:18 PM
> Subject: Re: [drlvm][verifier] Using the Harmony verifier code for
> computing the StackMapTable attribute
>
> Hello Asaf,
>
> On 11/5/07, Asaf Yaffe <asaf_yaffe@yahoo.com> wrote:
> >
> > Hi Mikhail,
> >
> > All class_*, method_* and field_* functions from the class
 interface
> can
> > be mapped to an implementation within the TPTP BCI engine. The main
> issue is
> > with the Class Loader functions (cl_*): generally, these functions
> can be
> > implemented using JNI. However, some classes are being instrumented
> during
> > the JVM bootstrapping, where JNI is not yet available.
>
>
> AFAIU, agent receives first ClassFileLoadHook event when JNI is
 already
> available. So, you can safely implement class loading related
> functionality
> through JNI. Class loader is passed into a callback so it can be used
> to
> load all classes which are neccessary for verification.
>
> Therefore, we cannot guarantee that class loading functionality will
> always
> > be available, and we will need to somehow work around this
> limitation. One
> > option, for example, is not to do any byte-code modifications until
> the JVM
> > is initialized, and then use RedefineClasses to instrument
 bootstrap
> > classes.
> >
> > Please let me know if there are any other issues, and what do you
> think
> > should be the next steps.
> >
> > Best regards,
> > Asaf
> >
> >
> > ----- Original Message ----
> > From: Mikhail Loenko <mloenko@gmail.com>
> > To: dev@harmony.apache.org
> > Sent: Thursday, November 1, 2007 7:38:21 AM
> > Subject: Re: [drlvm][verifier] Using the Harmony verifier code for
> > computing the StackMapTable attribute
> >
> > Hi Asaf
> >
> > see some questions below
> >
> > 2007/10/31, Asaf Yaffe <asaf_yaffe@yahoo.com>:
> > > 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.
> > >
> > > RecomputeStackMapTableAttribute():
> > > - 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).
> >
> > I need to think about that...
> >
> >
> > > - 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.
>
> Currently verifier uses the following list of functions from the
> > class_interface:
> >
> > cl_get_class
> > cl_load_class
> >
> > cl_acquire_lock
> > cl_release_lock
> >
> > cl_get_verify_data_ptr
> > cl_set_verify_data_ptr
> >
> > class_get_class_loader
> >
> > class_get_cp_class_name_index
> > class_get_cp_descriptor_index
> > class_get_cp_name_index
> > class_get_cp_ref_class_index
> > class_get_cp_ref_name_and_type_index
> > class_get_cp_size
> > class_get_cp_tag
> > class_get_cp_utf8_bytes
> > class_get_method
> > class_get_method_number
> > class_get_name
> > class_get_super_class
> > class_get_version
> > class_is_interface_
> > class_is_same_package
> > class_resolve_method
> > class_resolve_nonstatic_field
> >
> > field_is_protected
> >
> > method_get_bytecode
> > method_get_code_length
> > method_get_descriptor
> > method_get_exc_handler_info
> > method_get_exc_handler_number
> > method_get_max_local
> > method_get_max_stack
> > method_get_name
> > method_get_stackmaptable
> > method_is_protected
> > method_is_static
> >
> > The description of what these functions do can be found here[1]
> > Please let me know whether there is a necessary functionality to
> > implement
> > thse interface functions and whether they can be invoked at the
> moment
> > when recompute of stackmap attribute happens
> >
> > Thanks,
> > Mikhail
> >
> > [1]
> >
> >
>
>
 http://svn.apache.org/viewvc/harmony/enhanced/drlvm/trunk/vm/vmcore/include/class_interface.h?view=markup
> >
> >
> > >
> > > Best regards,
> > > Asaf
> > >
> > >
> > > ----- 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 attribute
> > >
> > >
> > > Hi Asaf!
> > >
> > > Welcome to Harmony dev forum :)
> > >
> > > I beleive current implementation of Harmony verifier [1] already
> > covers
> > >  most
> > > of what's necessary for you. It contains both old-style (Java5)
> > >  verification
> > > 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?
> > >
> > > RecomputeStackMapTableAttribute()
> > > Can the method byte-codes contain subroutines? Dead (unreachable)
> > code?
> > > as a result of stackmaptable calculation it might be necessary to
> > >  extend
> > > constant pool of the class. Is it acceptable in your environment?
> > >
> > > Thanks,
> > > Mikhail
> > >
> > > [1]
> > >
> >
> >
>
>
 http://svn.apache.org/viewvc/harmony/enhanced/drlvm/trunk/vm/vmcore/src/verifier-3363/
> > >
> > > 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
> > > http://mail.yahoo.com
> >
> >
> >
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
>
>
>
>
> --
> Pavel Pervov,
> Intel Enterprise Solutions Software Division
>
>
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com




-- 
Pavel Pervov,
Intel Enterprise Solutions Software Division





__________________________________________________
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