RFR(XXS): 8043180: SIGSEGV in Events::log_deopt_message

Christian Thalinger christian.thalinger at oracle.com
Thu May 15 01:05:25 UTC 2014


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?

On May 14, 2014, at 5:29 PM, Igor Veresov <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> wrote:
> 
>> Can we add verification code to make sure this is the case?
>> 
>> const char* Deoptimization::_trap_reason_name[Reason_LIMIT] = {
>>   // Note:  Keep this in sync. with enum DeoptReason.
>> 
>> And maybe this one too?
>> 
>> const char* 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> 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
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140514/bed6cfba/attachment.html>


More information about the hotspot-compiler-dev mailing list