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

Coleen Phillimore coleen.phillimore at oracle.com
Fri Feb 21 15:25:58 UTC 2014


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: http://cr.openjdk.java.net/~mgronlun/8035493/webrev01/ 
> <http://cr.openjdk.java.net/%7Emgronlun/8035493/webrev01/>
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8035493
>
> Problem statement summary and details are outlined in bug JDK-8035493 
> <https://bugs.openjdk.java.net/browse/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/1ecb4fc9/attachment-0001.html 


More information about the hotspot-runtime-dev mailing list