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

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

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

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

Issue:
https://bugs.openjdk.java.net/browse/JDK-8189368

Webrev:
http://cr.openjdk.java.net/~egahlin/8189368_1/

Best regards,
Robin
Reply | Threaded
Open this post in threaded view
|

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

Erik Gahlin
Looks good.

Erik

> 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.
>
> Issue:
> https://bugs.openjdk.java.net/browse/JDK-8189368
>
> Webrev:
> http://cr.openjdk.java.net/~egahlin/8189368_1/
>
> Best regards,
> Robin

Reply | Threaded
Open this post in threaded view
|

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

David Holmes
In reply to this post by Robin Westberg
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.

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.

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
>
Reply | Threaded
Open this post in threaded view
|

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

Robin Westberg
In reply to this post by Erik Gahlin
Hi Erik,

Thanks for reviewing!

Best regards,
Robin

> On 26 Oct 2017, at 18:50, Erik Gahlin <[hidden email]> wrote:
>
> Looks good.
>
> Erik
>> 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.
>>
>> Issue:
>> https://bugs.openjdk.java.net/browse/JDK-8189368
>>
>> Webrev:
>> http://cr.openjdk.java.net/~egahlin/8189368_1/
>>
>> Best regards,
>> Robin
>

Reply | Threaded
Open this post in threaded view
|

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

Robin Westberg
In reply to this post by David Holmes
Hi David,

Thanks for taking a look!

> On 27 Oct 2017, at 12:13, David Holmes <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

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

Markus Gronlund
In reply to this post by Robin Westberg
Hi Robin,

Looks good, thanks for adding this information to the event.

Cheers
Markus

-----Original Message-----
From: Robin Westberg
Sent: den 25 oktober 2017 15:52
To: [hidden email]
Subject: RFR(S): 8189368: Add information on current bias holder for BiasedLockRevocation event

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.

Issue:
https://bugs.openjdk.java.net/browse/JDK-8189368

Webrev:
http://cr.openjdk.java.net/~egahlin/8189368_1/

Best regards,
Robin