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

[Robin Westberg]

Hi David,

Thanks for taking the time to look at this!

> On 9 Oct 2017, at 03:26, David Holmes <david.holmes at oracle.com> wrote:
> 
> Hi Robin,
> 
> On 6/10/2017 8:22 PM, Robin Westberg wrote:
>> Hi all,
>> Please review this change to add event-based tracing events for biased lock revocations:
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8187042
>> Webrev (courtesy of Erik Gahlin): http://cr.openjdk.java.net/~egahlin/8187042/
> 
> I have a few queries:
> 
> First, why is there no event for the self-revocation path?

That’s a good question, I did not want to add events for revocations done without consulting the bulk revocation heuristics (as that could generate a very large amount of events), so I may have mistakenly thought of the self-revocation as a part of that.. But certainly makes sense to have an event there as well, I’ll do a bit of testing and add one.

> Second, is there a reason you can't put the event management inside the VM operation code and so avoid the need to adjust the safepoint counter?

Well yes, the event itself is configured to record the current thread together with a stack trace, but that requires that the event is actually generated from the thread that should be recorded.

> 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.

I will create an updated webrev after looking into adding an event for the self-revocation path.

Best regards,
Robin