RFR: Here are some Thread cleanup patches

[mandy chung]

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?
>>
>> Mandy
>
> 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.

Mandy

> VM experts, please advise!
>
> Regards, Peter
>