RFR: 8187042: Events to show which objects are associated with biased object revocations

[Robin Westberg]

Thanks for the reviews Markus, Erik and David!

Filed https://bugs.openjdk.java.net/browse/JDK-8189368 <https://bugs.openjdk.java.net/browse/JDK-8189368> for the improvement to add information on the thread currently holding the bias when it is revoked.

Best regards,
Robin

> On 16 Oct 2017, at 13:23, Markus Gronlund <markus.gronlund at oracle.com> wrote:
> 
> Hi Robin,
>  
> Looks good.
> 
> Thanks
> Markus
>  
> From: Robin Westberg 
> Sent: den 13 oktober 2017 16:56
> To: David Holmes
> Cc: serviceability-dev at openjdk.java.net
> Subject: Re: RFR: 8187042: Events to show which objects are associated with biased object revocations
>  
> Hi again,
>  
> Here’s an updated version that adds a separate event for the self-revocation path. It’s a new event class as it is a bit different from the non-self-revocation path, it does not have any relevant safepoint ID for example.
>  
> Webrev:
> http://cr.openjdk.java.net/~egahlin/8187042_2/ <http://cr.openjdk.java.net/~egahlin/8187042_2/> 
>  
> Third, I would have expected to see more detail in the event such as which thread (id) the object was biased to and which thread revoked the bias. Even perhaps some notion of which instance was involved (though that's harder to shows).
> Right, I’ve been looking at capturing which thread the object was biased towards, but I was afraid of the possible races there as the thread pointer in the mark would have to be saved before executing the VM operation. For that to work 100% reliably I suspect it would have to be done inside the safepoint.
> 
> Right the thread holding the bias may not even exist any more! This may need to utilise the new Thread-SMR work (as a future RFE of course). :)
>  
> Ah yeah, that may be an effective way of doing it. Another idea suggested by Markus Grönlund was to capture the thread’s id inside the operation and propagate it through an additional field in the VM operation class. But anyway, I’ll file a separate RFE for investigating that improvement.
>  
> Best regards,
> Robin
> 
> 
> I will create an updated webrev after looking into adding an event for the self-revocation path.
> 
> Thanks,
> David
> 
> 
> Best regards,
> Robin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20171016/462cc516/attachment-0001.html>