harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregory Shimansky <gshiman...@apache.org>
Subject Re: [drlvm][verifier] Using the Harmony verifier code for computing the StackMapTable attribute
Date Wed, 07 Nov 2007 20:01:50 GMT
Pavel Pervov wrote:
> 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.

Nope. According to [1] CFLH may happen in primordial phase. According to 
[2] JNI functions may be used only in the start and live phase.

[1] 
http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#ClassFileLoadHook
[2] http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#jvmtiPhase


>  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
> 
> 
> 
> 


-- 
Gregory


Mime
View raw message