RFR(S): 8189368: Add information on current bias holder for BiasedLockRevocation event

[Robin Westberg]

Hi David,

Thanks for taking a look!

> On 27 Oct 2017, at 12:13, David Holmes <david.holmes at oracle.com> wrote:
> 
> Hi Robin,
> 
> On 25/10/2017 11:52 PM, Robin Westberg wrote:
>> Hi all,
>> Please review the following changes which add a new field to the BiasedLockRevocation event, previousOwner, containing information on which thread (if any) owned the bias before it was revoked.
> 
> So to be clear the previous bias owner is only recorded for the case where we are doing a direct bias revocation**, at a safepoint and the owner thread is still alive - correct?
> 
> ** By which I mean the only case you don't pass NULL to revoke_bias.

Right, that’s the intention. The other calls to revoke_bias are either covered by another event (bulk revocation), or comes from jvmti-interaction. 

> Is it necessary for the thread to still be alive to get the thread-id? (If yes then SMR may help here). I was just thinking that it might be useful to distinguish the anonymously-biased case from the owner-was-dead case.

Yeah, the THREAD_TRACE_ID macro eventually turns into accessing a field in the thread instance. Could be done with SMR outside of revoke_bias I guess, but as the thread pointer is already validated in there, it seemed easiest to just make use of that.

If I understand it correctly, revoking an anonymous bias will not normally happen inside revoke_bias, as this is checked before issuing the VM operation (and does not generate an event in that case). It will only be used if the revocation comes from one of the calls originating in jvmti.

Maybe revocation of anonymously biased objects would be an interesting event as well, they would be generated a lot more frequently though I suspect.. It could also be interesting to generate events on the jvmti-specific revocation paths as well, not sure how common it is to mix it with event tracing. Perhaps stuff for further RFEs. :)

Best regards,
Robin

> 
> But overall this seems fine for what it does.
> 
> Thanks,
> David
> 
>> Issue:
>> https://bugs.openjdk.java.net/browse/JDK-8189368
>> Webrev:
>> http://cr.openjdk.java.net/~egahlin/8189368_1/
>> Best regards,
>> Robin