Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (nike.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID;
  b=VpUd2Tq3OtT9RnAUHXKen7mznK+nGW9nYmMTmXIKWn4Lpc8xS/Q6kPVm8BFivJ91BxQzIZBE2The57l49572wBdMpb1qqada4K+6c8yj3ihLJCPcn5Jys8aY7iCNwok2c4mw4Wf5tecoy2LwG3BLJqxBBWryJ76qniFjwfYSXEE=;
Date: Wed, 7 Nov 2007 02:25:40 -0800 (PST)
From: Asaf Yaffe <asaf_yaffe@yahoo.com>
Subject: Re: [drlvm][verifier] rebuilding stackmaptable attribute without
 loading the classes
To: dev@harmony.apache.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="0-1691452503-1194431140=:54488"
Message-ID: <942355.54488.qm@web55205.mail.re4.yahoo.com>

--0-1691452503-1194431140=:54488
Content-Type: text/plain; charset=us-ascii

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. 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 
--0-1691452503-1194431140=:54488--