Fwd: Review request for JDK-8017177: more explicit code location information in hs_err crash log

[Coleen Phillimore]

Doug,

This looks good to me too.  Will you replace the %d to SIZE_FORMAT?
If you send me a patch, I will commit it for you.

Coleen

On 06/20/2013 03:49 PM, Vladimir Kozlov wrote:
> Hi Doug,
>
> I think this is good. One thing I would change is offset value to 
> hexadecimal value instead of "+%d]".
>
> And you need review and sponsor from runtime group.
>
> thanks,
> Vladimir
>
> On 6/20/13 7:31 AM, Albert Noll wrote:
>> Begin forwarded message:
>>
>>> From: Doug Simon <doug.simon at oracle.com>
>>> Subject: Review request for JDK-8017177: more explicit code location
>>> information in hs_err crash log
>>> Date: June 20, 2013 4:12:09 PM GMT+02:00
>>> To: "hotspot-dev at openjdk.java.net developers"
>>> <hotspot-dev at openjdk.java.net>
>>>
>>> When debugging compiler issues, it would be useful to know where
>>> exactly in compiled code a crash happened. Currently, only the name
>>> and signature of a compiled frame is shown in a crash stack trace. If
>>> would be useful to know the address and offset of the crashing
>>> instruction.
>>>
>>> For example, instead of:
>>>
>>> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
>>> v ~DeoptimizationBlob
>>> J
>>> java.util.concurrent.ConcurrentHashMap$Segment.remove(Ljava/lang/Object;ILjava/lang/Object;)Ljava/lang/Object; 
>>>
>>>
>>>
>>> one would get something like:
>>>
>>> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
>>> v ~DeoptimizationBlob
>>> J
>>> java.util.concurrent.ConcurrentHashMap$Segment.remove(Ljava/lang/Object;ILjava/lang/Object;)Ljava/lang/Object; 
>>>
>>> @ 0x7f502892e095 [0x7f502892e000+149]
>>>
>>> Potential issue: may break hs_err crash log parsers
>>>
>>> open webrev at http://cr.openjdk.java.net/~dnsimon/JDK-8017177/
>>
>>
>>