RFR(S): 8035493: JVMTI PopFrame capability must instruct compilers not to prune locals

[Markus Gronlund]

Thanks Coleen,

 

Maybe the places in the compiler where particular  JVMTI capabilities are checked could instead be restated into a higher level questions and ask the CompilationPolicy (which I now saw already exist runtime/CompilationPolicy.hpp):

 

 

Like something which already exists:

 

if (CompilationPolicy::policy()->should_not_inline()) {

.

}

 

 

In light of this, for example, instead of checking jvmti_can_access_local_variables() and jvmti_can_pop_frame() directly, the compilers would ask a question which is more compiler relevant:

 

if (CompilationPolicy::policy()->retain_local_variables()) {

.

}

 

retain_local_variables() could hide whatever logic is necessary to come up with an answer.

 

Or something along those lines.

 

Thanks for reviewing!

 

/Markus

 

From: Coleen Phillimore 
Sent: den 21 februari 2014 16:26
To: Markus Gronlund; serviceability-dev at openjdk.net; hotspot-runtime-dev; hotspot-compiler-dev at openjdk.java.net
Subject: Re: RFR(S): 8035493: JVMTI PopFrame capability must instruct compilers not to prune locals

 


Markus,
This change looks really good to me.  I agree with your comments below but I don't know how one would do this in the current framework.

Thanks,
Coleen

On 2/21/14 5:53 AM, Markus Gronlund wrote:

Greetings,

 

Kindly asking for reviews for the following changeset:

 

Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Emgronlun/8035493/webrev01/"http://cr.openjdk.java.net/~mgronlun/8035493/webrev01/

Bug: https://bugs.openjdk.java.net/browse/JDK-8035493 

 

Problem statement summary and details are outlined in bug HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8035493"JDK-8035493 .

 

Testing completed:

 

nsk/jvmti/scenarios/* (this includes JVMTI Hotswap and PopFrame testing)

hotspot/test/compiler/*

 

Additionals:

 

I would like, if possible, if we could move away from intertwining specific jvmti capabilities inside the different compilers. 

 

The existing code makes it difficult to evolve and extend with additional instructions to the compilers, esp. if we would like to pass results from higher level conditions, perhaps by combining contextual data with/without JVMTI. If possible, a suggestion would be the creation of a higher level interface which the ciEnv can query for compilation instructions- the implementations of this interface could then be shielded away and allow for any type of combinatorial logic - leaving the code in the compilers themselves untouched.

 

Thanks in advance

Markus

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20140221/46d5dbad/attachment.html