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
