RFR (S): 8204668: Cleanup management of the java.vm.info System property
Chris Plummer
chris.plummer at oracle.com
Tue Jun 12 22:29:17 UTC 2018
Ok. Changes look good to me.
thanks,
Chris
On 6/12/18 2:37 PM, David Holmes wrote:
> Hi Chris,
>
> Thanks for looking at this.
>
> On 13/06/2018 3:52 AM, Chris Plummer wrote:
>> Hi David,
>>
>> Is there a reason you moved the PropertyList_add() call to a slightly
>> later point?
>
> Just following the existing pattern in that method: define the
> SystemProperty objects, then later add them.
>
>> You moved the Arguments::update_vm_info_property() call up a bit. How
>> did you decide exactly how early it can be called without risk of
>> other flags changing?
>
> Trial and error. I originally thought it was safe to do this once all
> the argument processing was complete: ergo changes, OS changes etc.
> But in fact the two flags we are concerned with do not get their final
> value until somewhere deep in init_globals(). If I put the update
> before init_globals() then it had the wrong value; if I put it after
> then it was correct. The main thing was to move it before the
> initialization of the system classes which would push the value
> through to the Java side.
>
> Thanks,
> David
>
>> thanks,
>>
>> Chris
>>
>> On 6/12/18 2:56 AM, David Holmes wrote:
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8204668
>>> webrev: http://cr.openjdk.java.net/~dholmes/8204668/webrev/
>>>
>>> JDK-8203329 fixed a problem where the native system property for the
>>> vm.info string was not updated after argument parsing, resulting in
>>> JVM TI reporting an incorrect value.
>>>
>>> Looking at the overall approach for this property it can be
>>> simplified quite a bit. The basic issue is that it is initialized
>>> early in VM startup (so it can be present for crash logs) before
>>> argument parsing, but some details can change due to argument
>>> parsing. If we update the native value immediately after argument
>>> parsing, and so before the properties are passed through to the Java
>>> side, then we don't need to execute the Java code in reset_vm_info()
>>> to perform that update. Additionally, if we expose the
>>> SystemProperty directly (as done for other properties) then we can
>>> do away with the new PropertyList_update_value() function that has
>>> to search for the property to be updated.
>>>
>>> Overall this cuts out a chunk of initialization code that may aid
>>> with startup costs; and simplifies the code.
>>>
>>> There's some additional history in the bug report.
>>>
>>> Testing:
>>> - tier 1, 2, 3
>>> - regression test from JDK-8203329:
>>> -
>>> serviceability/jvmti/GetSystemProperty/JvmtiGetSystemPropertyTest.java
>>>
>>> Thanks,
>>> David
>>
>>
>>
More information about the hotspot-runtime-dev
mailing list