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
