RFR: Here are some Thread cleanup patches
mandy.chung at oracle.com
Wed Mar 28 11:30:24 UTC 2018
On 3/28/18 6:34 PM, Peter Levart wrote:
> On 03/28/2018 11:32 AM, mandy chung wrote:
>> On 28/03/2018 4:28 AM, Martin Buchholz wrote:
>> > The usual story when I change Thread.java is that I'm missing
>> something and
>> > I end up reverting, so I was extra careful this time.
>> > 8200122: Remove unused field Thread.threadQ
>> > http://cr.openjdk.java.net/~martin/webrevs/jdk/Thread-threadQ/
>> > https://bugs.openjdk.java.net/browse/JDK-8200122
>> Looks fine.
>> > 8200123: Replace Thread.init with telescoping constructor
>> > http://cr.openjdk.java.net/~martin/webrevs/jdk/Thread-init/
>> > https://bugs.openjdk.java.net/browse/JDK-8200123
>> Looks good too.
>> Did you see any performance difference with and without @Stable?
> I doubt there would be any. @Stable is only effective when the
> reference to an object containing the annotated field can be constant
> folded by JIT. And Thread objects are typically not assigned to static
> final field(s) or (by transitivity) to @Stable fields.
> Thread.currentThread() could be an exception, but it's not a constant.
> It's a thread-local constant, so a possible optimization would be for
> JIT to cache Thread's @Stable fields in a thread-local storage, but I
> doubt it is programmed to do so.
I was wondering how Martin made the decision to mark it with @Stable. In
addition to the above, the ID is mostly used in tracing. I'd like to
see performance number for adding @Stable.
> VM experts, please advise!
> Regards, Peter
More information about the core-libs-dev