RFR: Here are some Thread cleanup patches

[David Holmes]

On 28/03/2018 10:48 AM, Martin Buchholz wrote:
> On Tue, Mar 27, 2018 at 4:42 PM, David Holmes <david.holmes at oracle.com 
> <mailto:david.holmes at oracle.com>> wrote:
> 
>     Hi Martin,
> 
>         8200123: Replace Thread.init with telescoping constructor
>         http://cr.openjdk.java.net/~martin/webrevs/jdk/Thread-init/
>         <http://cr.openjdk.java.net/~martin/webrevs/jdk/Thread-init/>
>         https://bugs.openjdk.java.net/browse/JDK-8200123
>         <https://bugs.openjdk.java.net/browse/JDK-8200123>
> 
> 
>     Looks fine - for some reason I thought we had a direct VM call to
>     init() but we don't.
> 
>     What is the effect of @stable? I'm just thinking about any possible
>     impact on initialization order.
> 
> 
> @Stable final
> just means the VM can really truly assume the value will only ever 
> change from the default value once.
> Like a per-field -XX:+TrustFinalNonStaticFields
> http://www.progdoc.de/papers/JET2015/How_final_is_final.pdf
> http://hg.openjdk.java.net/jdk/jdk/file/b6671a111395/src/java.base/share/classes/jdk/internal/vm/annotation/Stable.java

Yep I grok the semantics, but am wondering about the actual runtime 
impact. Is the Stable annotation class going to have to be loaded and 
processed when Thread is initialized? Will this change the 
initialization order?

Thanks,
David