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] Using the Harmony verifier code for computing the StackMapTable attribute
Date Thu, 01 Nov 2007 05:38:21 GMT
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

Mime
View raw message