On 28/03/2018 10:48 AM, Martin Buchholz wrote:
On Tue, Mar 27, 2018 at 4:42 PM, David Holmes <david.hol...@oracle.com
<mailto:david.hol...@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
