RFR(XS): JDK-8030808 dtrace/hotspot/Monitors/Monitors001 fails in product builds on solaris-sparc

David Holmes david.holmes at oracle.com
Thu Feb 6 02:15:56 PST 2014


On 6/02/2014 7:32 PM, Frederic Parain wrote:
> Hi David,
>
> The dtrace_waited_probe() function successfully
> work around the tail-call optimization for some
> time, and still works for non SPARC platforms.
> This is why I didn't try to remove it.
> Now, something new is breaking this code again
> on SPARC, and this changetset just aims to fix
> the code on SPARC without impacting other
> platform.

Okay. But might my suggestion fix the tail-call issue, and the new one?

> Of course, The "Good" solution is to clearly
> identify the issue in the SS12u1 compiler and
> to fix it.

I wonder if it will disappear with the compiler upgrade?

Cheers,
David

> Fred
>
> On 02/06/2014 06:07 AM, David Holmes wrote:
>> Hi Fred,
>>
>> On 6/02/2014 12:23 AM, Frederic Parain wrote:
>>> Greetings,
>>>
>>> Please review this small fix for bug 8030808.
>>> The bug is caused by a compiler bug preventing the
>>> hotspot:::monitor-waited DTrace probe to be fired
>>> on SPARC. After several failed attempts to fix
>>> the compiler behavior with #pragma and flags, I'm
>>> proposing this simple workaround.
>>>
>>> CR:
>>> https://bugs.openjdk.java.net/browse/JDK-8030808
>>> Webrev:
>>> http://cr.openjdk.java.net/~fparain/8030808/webrev.00/
>>
>> So ... if the dtrace_waited_probe call was attempting (but failing?) to
>> work around the tail-call optimization bug, would it not suffice to drop
>> the call and just add a return:
>>
>> DTRACE_MONITOR_PROBE(waited, monitor, obj(), THREAD);
>> // This dummy return is in place to get around dtrace bug 6254741.  Once
>> // that's fixed we can remove it and change this back to a void method
>> return 0;
>>
>> ??
>>
>> David
>> -----
>>
>>> The fix has been tested with the dtrace/hotspot test suite
>>> and the vm.quick testlist.
>>>
>>> Thanks,
>>>
>>> Fred
>>>
>


More information about the hotspot-runtime-dev mailing list