The problem

A while ago a colleague of mine discovered a weird behavior when writing some integration tests. He fi rst noticed that the test worked in JDeveloper, but not in Eclipse. Then he noticed that he could make a small change to the test setup and the test would pass. Another small change and it would fail again. He got some help and managed to reduce the problem to the following:

Original code

import junit.framework.TestCase;
public class ObjectCreationTest extends TestCase {
        class MyObject {
                Object temp;
                public MyObject() {
                        set();
                }
                void set() {
                }
                Object get() {
                        return temp;
                }
        }
        public void testWithNewString() throws Throwable {
                fi nal String value = new String(”Value”);
                assertEquals(”Value”, value); 

                MyObject tested = new MyObject() {
                        void set() {
                                temp = value;
                        }
                };
                String result = (String) tested.get();
                assertEquals(”Value”, result);
        }
}

This test fails in some environments and works in others. When the test fails it is
because result is null. How can this be? But it gets even stranger: By changing how
the value is initialized the test always pass:

Using a String constant

public void testWithConstant() throws Throwable {
        fi nal String value = ”Value”;
        assertEquals(”Value”, value); 

        MyObject tested = new MyObject() {
                void set() {
                        temp = value;
                }
        };
        String result = (String) tested.get();
        assertEquals(”Value”, result);
}

This test works for all environments. Why does the initialization of value affect
result? Very strange indeed!
Finally, by changing the type of the value we are back to the situation where the test
case fails in some environments, but not all.

Using Object instead of String

public void testWithObject() throws Throwable {
        fi nal Object value = ”Value”;
        assertEquals(”Value”, value); 

        MyObject tested = new MyObject() {
                void set() {
                        temp = value;
                }
        };
        String result = (String) tested.get();
        assertEquals(”Value”, result);
}

Challenge

Here are some challenges for you! Try to solve them before reading the solution!

• Explain the difference between the middle test case and the other two (easy).
• Explain why the initial test case fails in some environments and works in others (hard).
• Find the bad design that might cause problems (and indeed does in this case!).

I can give you a hint. The differences are both related to the Java compiler. Don’t
cheat! You should at least be able to answer the irst question before reading on.

Solution

There are several things going on here. I’ll start by explaining what is going on when
we change the variable named ”value” and then I’ll look more closely at anonymous
inner classes. Finally I will describe the problem with the design.

Constant variablConstant variables

Here are the three cases again:

final String value1 = new String(”Value”);
final String value2 = ”Value”;
final Object value3 = ”Value”;

According to the Java Language Specifi cation (JLS) ”We call a variable, of primitive
type or type String, that is fi nal and initialized with a compile-time constant expres-
sion (§15.28) a constant variable”. Lets go through each variable:

• ”value1” is not a constant since it does not have a compile-time constant expres-
  sion! That is, the compiler does not know what the String constructor is doing and
  therefore assumes that this needs to be evaluated at runtime.
• ”value2” is a constant variable since it is clearly of type String and also initialized with a compile-time constant value.
• ”value3” is not a constant since it is not a primitive type or a String. Yes, the object it refers to is a String, but the variable itself is an Object.

This means that only the middle case is a constant. When the compiler spots a
constant it automatically replaces all references with the constant value, ie in the
compiled class a constant variable is never referenced! The result is that the next
problem I will describe does not occur and the test case works.

Anonymous inner classes

As you know an inner class is able to access not only fi elds in the creating instance
but also fi nal variables in the method that creates the class. Did you ever wonder
how this magic is done? Maybe you have also noticed that it is not possible for an
anonymous class to have a constructor. When you create an anonymous inner class
the compiler actually creates the constructor for you. Let’s decompile the original
version and see what is going on.

Decompiled the original version (using JAD and javap)

final class ObjectCreationTest$1 extends MyObject {
        fi nal ObjectCreationTest this$0;
        private fi nal Object val$value;
        ObjectCreationTest$1(ObjectCreationTest that, Object obj)
                this$0 = that;
                val$value = obj;
                super();
        }
        void set() {
                temp = val$value;
        }
}
public void testWithNewString() throws Throwable{
        fi nal Object value = new String(”value”);
        MyObject tested = new ObjectCreationTest$1(this, value);
        Object result = tested.get();
        assertEquals(value, result);
}

Now it is easy to see that there is no magic going on! The compiler has simply added
a constructor and two instance variables. The set method is not using the fi nal vari-
able from the method, instead it is simply using its own reference to the value.
Well, this is all very nice, but why did the test case fail in some environments?
Notice how the generated constructor fi rst initializes the members and then calls super. This is normally not allowed in Java, but consider what would happen if the
compiler didn’t work this way. MyObject constructor would be called, which then
calls set and tries to use val$value which has not been initialized yet. Because of a
bug in the compiler this is exactly what happened in Java compilers before release
1.4.
OK, so if this problem is fi xed in 1.4 and later, why should you care? Take a look
at the next problem!

Bad design

The problem with the design is that the base class MyObject is calling methods in the
anonymous subclass before the subclass instance variables have been created. Unfor-
tunately this is not only a problem with anonymous classes, but a problem in general.
Take a look at the following test case and see if you know what will happen.

public class BaseCallingSubTest extends TestCase {
        class Base {
                Base() {
                        doStuff();
                }
                void doStuff() {
                }
        }
        class Sub extends Base {
                private fi nal int fi nalField = 5;
                private int normalField = 5;
                void doStuff() {
                        assertEquals(5, fi nalField);
                        assertEquals(5, normalField);
                }
        } 

        public void testSub() {
                Sub s = new Sub();
        }
}

The test case will fail at the second assertEquals. Why? Two things are happening.
First of all ”fi nalField” is a constant variable and the compiler automatically uses 5
instead of referencing the variable, see above. Secondly, the constructor for Base is
called before the fi elds of Sub are initialized! Things are actually happening in this
order:

1. The fields in Base are initialized
2. Base constructor is run
3. The fi elds in Sub are initialized
4. Sub constructor is run

This is not a bug! This is exactly according to JLS Ӥ12.5 Creation of New Class
Instances”. The following is perhaps even more surprising:

public class BaseCallingSub2Test extends TestCase {
        class Base {
                Base() {
                        doStuff();
                }
                void doStuff() {
                }
        }
        class Sub extends Base {
                private int normalField = 5;
                void doStuff() {
                        normalField = 7;
                }
        } 

        public void testBase() {
                Sub s = new Sub();
                assertEquals(7, s.normalField);
        }
}

This test case also fails because after Base and doStuff have been called, Sub is ini-
tialized and the normalField is assigned to 5. This is possible to solve by not initial-
izing normalField.

class Sub extends Base {
        private int normalField;
        void doStuff() {
                normalField = 7;
        }
}

This works as expected. However, try to avoid constructions like this as it is very
easy to forget that the fi elds might not be initialized yet. There are actually more
problems with this construction as it might affect thread safety. For instance if the
subclass starts a thread in the overridden method this thread might be given access
to the uninitialized object. Brian Goetz (author of ”Java Concurrency in Practice”)
goes as far as calling this ”not properly constructed”.

Lessons learned

• Make sure you understand constant variables and how they are used by the compiler
• Use a recent version of Java compiler. Sun is constantly adding improvements and
  fixing bugs.
• Avoid calling non fi nal methods from the constructor. If you have to, be aware
  that the object might not be initialized yet.
• Do not perform unnecessary initialization of fields.

Originally published in JayView.

Innan arbetet med JRockit inleddes gjordes en undersökning av vad ut- vecklare av serverapplikationer egentligen ville ha för egenskaper i en JVM. Denna lista har legat till grund för det som är JRockit idag:

1. Pålitlighet/Robusthet (24x7)
2. Skalbarhet
3. Korta pauser
4. Kodprestanda

Pålitlighet och möjlighet att kunna köra sina system dag ut och dag in, vecka efter vecka, var den i särklass mest efterfrågade egenskapen i en server-JVM. För att, som ett litet företag, kunna erbjuda detta är det Appeals målsättning att se till att så många som möjligt får möjlighet att testa JRockit och att bugrapporter besvaras och åtgärdas så snart det går.

Skalbarhet eller möjligheten att kunna hantera en stor mängd samtidiga användare och att utnyttja tillagd maskin- vara så effektivt som möjligt står näst högst upp på listan.
Trea på listan är korta pauser. Allt för många serversystem lider fortfarande av skräpsamlingspauser som är flera
sekunder långa.

Vad som kanske är mest anmärkningsvärt med denna lista är att kodprestanda kom först på fjärdeplats. Det är ett av de mindre problem man har i ett serversystem, något som kanske är värt att komma ihåg när man står i valet mellan en svårdebuggad men snabb C++ lösning mot java.

JRockit - en JVM med siktet inställt på mer än bara kod och skräpsamling
Sun och IBM ser på JVM:en som någonting vars uppgift är att exekvera kod och att skräpsamla, d v s kodexekvering och minneshantering är de områden som man optimerar. JRockit har en annan filosofi: Ett av de viktigaste underliggande designvalen i JRockit är att JVM:en inte bara ska kunna förbättra kodexekvering och minneshantering, utan att även trådhantering, fil och nätkommunikation ska ingå bland de områden JRockit optimerar.

Varför skiljer sig då JRockits optimerings- områden från de andra JVMernas? För att förstå detta måste vi gå tillbaka i tiden till Javas födelse: När Sun i början av 1997 gjorde en analys av prestandaproblemen, kom man fram till att för en godtycklig applikation låg 75% av tiden i kodexekvering och 20% av tiden i skräpsamling. Naturligtvis valde man att satsa på optimerad kodexekvering och skräpsamling i sin kommande JVM, HotSpot. Ett problem med analysen var att de applikationer man undersökte var typiska klientapplikationer. Användandet av Java på serversidan låg fortfarande i sin vagga.

JRockit har tagit fasta på att fördelningen mellan de olika områdena på serversidan inte är alls likadan. En typisk serverapp- likation kan tillbringa 25% av sin tid i kod, 25% av tiden i skräpsamling, 25% av tiden i trådhantering och de resterande 25% med nätverkskommunikation. Att inte optimera tråd- och nätverkshantering för sådana system resulterar i att man bara kan förbättra 50% av applikationen, och då teoretiskt maximalt halvera exekveringstiden. Genom att ge JVM:en bättre kontroll över tråd- och nätverkskom- munikationen kan dessa områden väsentligt snabbas upp utan förbättringar i det underliggande operativsystemet.

Vad det gäller tråd- och näthantering har man på Sun fortfarande åsikten att de största förbättringarna inom dessa om- råden inte kommer ifrån JVM:en utan från utvecklingen inom operativsystemavdel- ningarna.

Dynamisk Optimering
Dynamisk optimering är ett annat av huvudkoncepten i JRockit. Dynamisk optimering innebär att det körande programmet förbättras under körningens gång, JVMen anpassar exekvering av programmet till hur det används och vilka delar som används. Dynamisk optimering möjliggör ointuitivt nog högre exekveringshastigheter än traditionell kompilering för stora komplexa system. För att förstå varför måste vi först förstå vilka egenheter stora system har. För det första så är systemen ofta flerlagersarkitekturer, en nödvändighet för att skapa abstraktion och få överblick över systemen.

Det är bra för människans förståelse av systemet på en övergripande nivå, men för datorn som exekverar systemet leder det till att man måste passera genom fler lager, vilket tar mer tid. För det andra så bygger man vanligtvis nya system ovanpå andra system (t ex applikationsservrar) eller med hjälp av andra komponenter (skrivna av andra eller i tidigare system). I allmänhet är dessa komponenter generella, dvs de är byggda för att lösa en mängd olika uppgifter, varav endast en del utnyttjas i det aktuella systemet. Givetvis är det bra att systemutvecklare lär sig att inte hela tiden uppfinna hjulet på nytt, men ur en prestandasynvinkel så skulle antagligen systemet exekvera snabbare om man använde mer specialiserade komponenter.

Dessvärre kan statisk kompilering inte hjälpa till speciellt mycket om språket är dynamiskt som t ex Java: det är svårt, för att inte säga omöjligt att veta vilka komponenter som kommer att finnas i systemet innan man startat det. Detta på grund av att Java tilllåter ny funktionalitet att laddas in under körningens gång (klassladdning). Genom dynamisk optimering kan JVM:en under körningen skala bort de lager som bara fyller en abstraktionsfunktion för människan och dessutom kan de komponenter som används på ett specifikt ställe i systemet specialiseras till hur de används på det stället. Dynamisk optimering ger alltså, åtminstone i teorin, människan en möjlighet att bevara i stort sett all abstraktion utan att förlora allt för mycket prestanda. Kritik har dock riktats mot att själva optimeringsprocessen tar tid från exekveringen. Detta kan förvisso vara sant men om optimeringar görs under systemets första tio minuters drifttid och systemet kommer att vara uppe i flera veckor i streck är det en försumbar kostnad och dessutom kan man tänka sig att det optimeringsarbete som görs sparas för att återanvändas.

Konfigurerbarhet

Ytterligare en unik filosofi hos JRockit som andra JVM-tillverkare först på senare tid börjat titta på är baserad på det faktum att ingen applikation är den andra lik. Det finns inga patentlösning. Finns inte en perfekt konfiguration av en JVM som kommer att fungera lika bra för alla applikationer.

JVM:ens konfiguration måste kunna anpassas till olika applikationer. Detta kan göras på två sätt:
1) JVM:en analyserar applikationen under körning och justerar sina parametrar för att kunna exekvera applikationen så effektivt som möjligt. En del av denna process är den dynamiska optimeringen som beskrevs ovan,
2) Utvecklarna av systemet kan själva konfigurera JVM:en både vid uppstart och under körningen. Konfigureringen under körningen ska kunna göras ifrån Java.

Tanken är att JVM:en på bästa sätt ska anpassa sig men även bli anpassad till applikationen för högsta möjliga pre- standa.

Installera och testa JRockit

Den nyfikna läsaren har nu börjat fråga sig ”kan jag jag pröva JRockit”? Ja, du kan ladda ned en fullfjädrad version för Solaris, Linux eller Win2000 från http:// www.jrockit.com.

Framtiden

Vad händer med JRockit i framtiden. Ett av de viktigaste områdena man arbetar med är licensiering: att få applikations- servertillverkarna (BEA Weblogic, IBM Websphere, ATG Dynamo, Orion m.fl.) att ta upp JRockit som en rekommenderad JVM för sina applikationsservrar.

För den första versionen av JRockit satsade man på att bli avsevärt mycket snabbare än de andra JVM:erna inom tråd- och nätverksprestanda, någonting man lyckades med. Detta visades genom den oslagbara skalbarhet man lyckas uppnå på det välkända Volano-testet: http:// www.volano.com/report.html .

Vad det gällde kod och skräpsamlings- prestanda var man dock för den första versionen av JRockit tvungna att inse att avståndet till de andra JVM:erna var för stort. Därför pågår nu intensivt arbete inom dessa områden för att bli bättre än de andra även här. Lyckas man? Svaret återstår att se senare i år.

Originally published in JayView.