System.currentTimeMillis check in System class during startup.
martinrb at google.com
Thu Jul 8 05:38:02 UTC 2010
On Wed, Jul 7, 2010 at 18:08, David Holmes <David.Holmes at oracle.com> wrote:
> I think there has been some confusion here. It seems to me that the
> anti-inlining that is being referred to is javac's "inlining" of
> compile-time constants - BUT that doesn't apply to reference types other
> than String, so it seems to me that the current code contortions serve no
> useful purpose and direct initialization to null could have been used.
I was actually afraid of what the VM would do, not javac.
I freely admit to a bit of superstition.
Surely there must have been a time when the
anti-inlining was effective?
Anyways, with two votes for making the code sane,
I'll go along and simply initialize to null.
If there's a problem with setOut, we'll surely find out before this jdk
goes into production.
> There is a second memory-model issue concerning these fields but basically
> that requires that no code gets compiled and caches the initial null values
> of these fields, prior to the setXX methods being called to initialize them
> correctly. I don't see how the use of the current code would change that one
> way or another though, so again the current code seems to serve no purpose.
> Did I miss something?
> David Holmes
More information about the core-libs-dev