System.currentTimeMillis check in System class during startup.

[Martin Buchholz]

On Wed, Jul 7, 2010 at 08:00,  <jon.vanalten at redhat.com> wrote:
>
> ----- "Martin Buchholz" <martinrb at google.com> wrote:
>
>
>> The JDK should find some other anti-inlining technique.
>>
>
> I would go one step further, and say that perhaps this anti-inlining is no longer necessary.  I tried taking these methods out entirely and simply setting the in/out/err streams to null initially.  This works.  Probably due to some combination of 1) they are later on set from JNI code, and 2) JSR133, which among other things changed some rules about static final variables, notably:
>
> "Static final fields may only be modified in the class initializer that defines them, with the ex-
> ception of the java.lang.System.in, java.lang.System.out, and java.lang.System.err static
> fields, which can be modified by the java.lang.System.setIn, java.lang.System.setOut, and
> java.lang.System.setErr methods."

That's a specification for what a JDK has to do.  Perhaps the
anti-inlining trick in System.java is one way that the Sun JDK tries
to ensure that the JIT does not treat these fields as constant
(although there is code in hotspot that is aware of the 3 special
fields).

> I've attached a patch that (for me) has not caused any problems.  Does anyone else have thoughts about this?

It seems hard to predict what the JVM will do under any circumstances.
 In particular, it's untestable.

Martin