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.
VM experts, please advise!
Regards, Peter
