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