RFR(XXS): 8043180: SIGSEGV in Events::log_deopt_message
Vladimir Kozlov
vladimir.kozlov at oracle.com
Thu May 15 01:10:01 UTC 2014
On 5/14/14 6:05 PM, Christian Thalinger wrote:
> Yeah, something like this. Better would be to check all entries in a
> verify method. Also, can we be sure that undefined entries are
> initialized to zero on all platforms?
According C++ spec, it should be NULL.
Vladimir
>
> On May 14, 2014, at 5:29 PM, Igor Veresov <igor.veresov at oracle.com
> <mailto:igor.veresov at oracle.com>> wrote:
>
>> Don’t quite know an easy way to that statically, but we can check at
>> runtime:
>>
>> http://cr.openjdk.java.net/~iveresov/8043180/webrev.01
>>
>> igor
>>
>> On May 14, 2014, at 5:07 PM, Christian Thalinger
>> <christian.thalinger at oracle.com
>> <mailto:christian.thalinger at oracle.com>> wrote:
>>
>>> Can we add verification code to make sure this is the case?
>>>
>>> constchar* Deoptimization::_trap_reason_name[Reason_LIMIT] = {
>>> // Note: Keep this in sync. with enum DeoptReason.
>>>
>>> And maybe this one too?
>>>
>>> constchar* Deoptimization::_trap_action_name[Action_LIMIT] = {
>>> // Note: Keep this in sync. with enum DeoptAction.
>>>
>>> On May 14, 2014, at 4:49 PM, Igor Veresov <igor.veresov at oracle.com
>>> <mailto:igor.veresov at oracle.com>> wrote:
>>>
>>>> Forgot to name the deopt reason in the aging change. Also fixed some
>>>> related LogCompilation printing.
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~iveresov/8043180/webrev.00/
>>>>
>>>> Thanks,
>>>> igor
>>>
>>
>
More information about the hotspot-compiler-dev
mailing list