RFR(S): 8035493: JVMTI PopFrame capability must instruct compilers not to prune locals
coleen.phillimore at oracle.com
Fri Feb 21 07:25:58 PST 2014
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.
On 2/21/14 5:53 AM, Markus Gronlund wrote:
> Kindly asking for reviews for the following changeset:
> Webrev: 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 JDK-8035493
> <https://bugs.openjdk.java.net/browse/JDK-8035493> .
> Testing completed:
> nsk/jvmti/scenarios/* (this includes JVMTI Hotswap and PopFrame testing)
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-compiler-dev