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 <[EMAIL PROTECTED]>
To: [email protected]
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 <[EMAIL PROTECTED]>:
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.
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 <[EMAIL PROTECTED]>
To: [email protected]
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 <[EMAIL PROTECTED]>:
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
