RFR: 8167194: [JVMCI] no reliable mechanism for querying JVMCI system properties

Tom Rodriguez tom.rodriguez at oracle.com
Wed Oct 5 22:01:56 UTC 2016


> On Oct 5, 2016, at 1:52 PM, Doug Simon <doug.simon at oracle.com> wrote:
> 
> Thanks for the review!

I kind of preferred the behavior that it exited after printing the output but looking at it again I think it’s ok to remove the exit.  It does the right thing if you pass no other options to the only extra output you get is the normal Java help.  Looks good to me too.

tom

> 
>> On 05 Oct 2016, at 22:21, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>> 
>> Looks good.
>> 
>> thanks,
>> Vladimir
>> 
>> On 10/5/16 1:03 PM, Doug Simon wrote:
>>> 
>>>> On 05 Oct 2016, at 21:10, Doug Simon <doug.simon at oracle.com> wrote:
>>>> 
>>>>> 
>>>>> On 05 Oct 2016, at 20:49, Vladimir Kozlov <vladimir.kozlov at oracle.com> wrote:
>>>>> 
>>>>> On 10/5/16 11:34 AM, Doug Simon wrote:
>>>>>> I chose system property because these properties are set with the command line system property syntax.
>>>>> 
>>>>> You mean "were set"? It use normal VM flag now.
>>>> 
>>>> No. The properties *are* still system properties (e.g., -Dgraal.PrintCompilation=true). The only non-standard way about how we use them is that they are accessed via VM.getSavedProperties() instead of System.getProperty() so that non-trusted code cannot influence JVMCI or Graal.
>>>>> 
>>>>>> I’d actually prefer shortening it to just “properties” if you think it doesn’t risk any ambiguity.
>>>>> 
>>>>> For me "shortening" is better - few bytes less in VM size :)
>>>> 
>>>> Ok, I’ll create a new webrev.
>>> 
>>> http://cr.openjdk.java.net/~dnsimon/8167194.v2/
>>> 
>>> -Doug
>>> 
> 



More information about the hotspot-compiler-dev mailing list