[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-runtime-dev
Subject:    RE: RFR(S): 8035493: JVMTI PopFrame capability must instruct compilers not to prune locals
From:       Markus Gronlund <markus.gronlund () oracle ! com>
Date:       2014-02-22 9:16:12
Message-ID: 7ab51072-a4c2-49dc-a2cf-6e58ff11a36f () default
[Download RAW message or body]

Ok, thanks, i'll line it all up before pushing.

Thanks!

/Markus

-----Original Message-----
From: Vladimir Kozlov 
Sent: den 21 februari 2014 22:12
Cc: hotspot-compiler-dev@openjdk.java.net; serviceability-dev@openjdk.net; \
                hotspot-runtime-dev
Subject: Re: RFR(S): 8035493: JVMTI PopFrame capability must instruct compilers not \
to prune locals

Indent is off:

+  if (!_jvmti_can_access_local_variables &&
+    JvmtiExport::can_access_local_variables()) {

otherwise it is good.

Thanks,
Vladimir

On 2/21/14 12:27 PM, Markus Gronlund wrote:
> Hi Vladimir,
> 
> You are absolutely right, many thanks for pointing it out - I should have inspected \
> that more closely... 
> Updated:
> 
> http://cr.openjdk.java.net/~mgronlun/8035493/webrev02/
> 
> 
> Thanks again
> Best regards
> 
> Markus
> 
> 
> 
> -----Original Message-----
> From: Vladimir Kozlov
> Sent: den 21 februari 2014 19:06
> To: Markus Gronlund; serviceability-dev@openjdk.net; 
> hotspot-runtime-dev; hotspot-compiler-dev@openjdk.java.net
> Subject: Re: RFR(S): 8035493: JVMTI PopFrame capability must instruct 
> compilers not to prune locals
> 
> Markus,
> 
> jvmti_state_changed() produces different result than the code it replaced. If \
> original jvmti cached values were true we did not bailout compilation regardless \
> their current. Only with change from false to true we do that. 
> Thanks,
> Vladimir
> 
> On 2/21/14 2:53 AM, Markus Gronlund wrote:
> > Greetings,
> > 
> > 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)
> > 
> > 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
> > 


[prev in list] [next in list] [prev in thread] [next in thread]