On Wed, Jul 7, 2010 at 08:00, <jon.vanal...@redhat.com> wrote: > > ----- "Martin Buchholz" <marti...@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
