RFR (S) 8203479: JFR enabled ARM32 build assertion failure
Boris Ulasevich
boris.ulasevich at bell-sw.com
Mon Jun 18 09:18:51 UTC 2018
Hi David,
Many thanks! Here is the werbev with updated copyrights:
http://cr.openjdk.java.net/~bulasevich/8203479/webrev.02
thanks,
Boris
On 18.06.2018 05:39, David Holmes wrote:
> Hi Boris,
>
> On 15/06/2018 8:44 PM, Boris Ulasevich wrote:
>> Hi,
>>
>> Please review the following patch:
>> http://cr.openjdk.java.net/~bulasevich/8203479/webrev.01
>> https://bugs.openjdk.java.net/browse/JDK-8203479
>>
>> Assertion fires in JFR codes on first VM thread setup because VM
>> globals are not yet initialized (and supports_cx8 property is not
>> predefined for ARM32 platform). I propose to exploit
>> early_initialize() method to set up supports_cx8 property on early
>> stage of VM initialization.
>
> Your fix looks good. Please update copyright years.
> Just some additional commentary ... from the bug report:
>
> First _supports_cx8 usage:
> Threads::create_vm -> JavaThread::JavaThread(bool) -->
> Thread::Thread() --> JfrThreadLocal::JfrThreadLocal() -->
> atomic_inc(unsigned long long volatile*)
>
> I'm not sure when this was introduced but it's risky to perform atomic
> operations on jlong early during VM initialization.
For me it comes from revision when JFR was opensourced:
changeset: 50113:caf115bb98ad
user: egahlin
date: Tue May 15 20:24:34 2018 +0200
summary: 8199712: Flight Recorder
> Apart from the
> problem you encountered with ARM32, on some platforms it may require
> that the stub-generator has been initialized. (Though in that case we
> may harmlessly fallback to using non-atomic operations - which is okay
> when creating the initial JavaThread.)
Good point! Yes, we discussed as an optional solution: (1) reworking jfr
next_thread_id() function to increase counter without atomic_inc
function call when counter value is zero, and (2) disable assertion when
!is_init_completed(). We decided that for our case initialization
sequence reorder works better.
> Thanks,
> David
>
>> Thanks
>> Boris
More information about the hotspot-dev
mailing list