Request for review (S): add the JRE name to the error log

[Coleen Phillimore]

Kris,

I'm sorry I didn't comment on this earlier.  This looks fantastic.  I 
tried to do this but didn't know how and had settled on the 
not-very-good version line in vmError that you improved.   Thanks!!
Coleen

On 6/13/2012 5:12 PM, Christian Thalinger wrote:
> Does anyone from runtime have an opinion on this one?
>
> -- Chris
>
> On May 16, 2012, at 1:26 PM, Christian Thalinger wrote:
>
>>
>> On May 16, 2012, at 12:44 PM, Krystal Mok wrote:
>>
>>> Hi all,
>>>
>>> Could I get some review for this change, please?
>>> https://gist.github.com/2709918#file_jre_name.patch
>>> I'm considering this as an initial draft version, and will improve 
>>> it later on
>>> based on comments received.
>>>
>>> Background:
>>>
>>> An earlier case on hotspot-dev [1][2] seemed to have hit a bug 
>>> caused by mix-
>>> matching an Oracle JRE with a OpenJDK-based HotSpot VM.
>>>
>>> Chris suggested [3] that, to better aid future analysis of similar 
>>> problems,
>>> it's useful to print the JRE name in the error log, in addition to 
>>> the JRE
>>> version as printed currently. This patch implements Chris' suggestion.
>>>
>>> An example of the effect of this patch is avaiable [4].
>>>
>>> There are a few details that I'm not too sure about yet, and I'm 
>>> looking for
>>> comments on them:
>>>
>>> 1. How and when should I get the JRE name?
>>>
>>> The JRE name is only exposed as a field of a Java-level class, 
>>> namely the
>>> "java_runtime_name" constant field in sun.misc.Version. I couldn't 
>>> find it
>>> exposed anywhere else. It is set into the Java-level system 
>>> properties, by the
>>> key "java.runtime.name <http://java.runtime.name/>", but that's not 
>>> immediately available to the VM side.
>>>
>>> In my patch, I'm fetching the JRE name from 
>>> sun.misc.Version.java_runtime_name
>>> immediately after java.lang.System.initializeSystemClass() is 
>>> invoked, and then
>>> storing it in a static field in JDK_Version. This is safer to do 
>>> then fetching
>>> the name during error reporting, because it may be unreliable to 
>>> access Java
>>> heap contents when the VM is crashing.
>>>
>>> There are other alternatives that I've thought about. One is adding 
>>> a new
>>> private interface between JDK/JVM that would allow the JDK to expose 
>>> its name
>>> to the VM directly, perhaps with a new function JDK_GetName0(). But 
>>> this is
>>> more involved then the proposed change.
>>>
>>> 2. Where should I store the JRE name?
>>>
>>> As mentioned, I'm storing it in a newly added static field in 
>>> JDK_Version right
>>> now. But I'm not sure if this is the place it belongs. Universe 
>>> doesn't seem
>>> like the right place, neither.
>>>
>>> Any suggestions or comments are welcomed.
>>
>> I looked at the changes and I think this is the right way to 
>> implement it.  It will definitely help debugging some strange crashes 
>> like the one mentioned.
>>
>> -- Chris
>>
>>>
>>> Should I cc serviceability-dev as well?
>>>
>>> Regards,
>>> Kris
>>>
>>> [1]: 
>>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2012-May/007647.html
>>> [2]: 
>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-May/005711.html
>>> [3]: 
>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2012-May/005725.html
>>> [4]: https://gist.github.com/2709918
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20120613/8400a598/attachment.html