Hi David, Thanks for taking the time to look at this!
> On 9 Oct 2017, at 03:26, David Holmes <david.hol...@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
