RFR: 8220724: TestBiasedLockRevocationEvents fails while matching revoke events to VMOperation events
Patricio Chilano
patricio.chilano.mateo at oracle.com
Fri May 3 05:38:42 UTC 2019
Hi David,
On 5/2/19 10:42 PM, David Holmes wrote:
> Hi Patricio,
>
> On 3/05/2019 4:48 am, Patricio Chilano wrote:
>> Hi,
>>
>> Could you review this small patch?
>>
>> https://bugs.openjdk.java.net/browse/JDK-8220724
>> http://cr.openjdk.java.net/~pchilanomate/8220724/v01/webrev/
>
> Basic approach is good. However as VM_BulkRevokeBias inherits from
> VM_RevokeBias you don't need to duplicate all this _safepoint_id stuff:
>
> 578 uint64_t _safepoint_id;
> 587 , _safepoint_id(0) {}
> 598 uint64_t safepoint_id() const {
> 599 return _safepoint_id;
> 600 }
Done! Missed the inheritance.
> Also please update copyright year.
Done.
Here is the updated webrev:
inc: http://cr.openjdk.java.net/~pchilanomate/8220724/v02/inc/webrev/
full: http://cr.openjdk.java.net/~pchilanomate/8220724/v02/webrev/
Thanks for reviewing this change!
Thanks,
Patricio
> Thanks,
> David
> ----
>
>
>> The subtest testRevocationSafepointIdCorrelation() in
>> TestBiasedLockRevocationEvents.java fails intermittently because
>> there could be a mismatch between the safepoint id recorded by the
>> VMThread during the execution of a VM_RevokeBias or VM_BulkRevokeBias
>> operation, and the one recorded by the JavaThread that requested the
>> VM operation. I added a more detailed description of the problem in
>> the comments of the bug.
>>
>> Testing tiers1-3 in mach5 and test
>> TestBiasedLockRevocationEvents.java with flag -XX:+SafepointALot.
>>
>> Thanks!
>> Patricio
More information about the hotspot-runtime-dev
mailing list