2 Egon Borger, Wolfram Schulte: Initialization Problems for Java 1 class A implements I{ } 2 3 interface I { static boolean dummy = Main.sideeffect =

Transcription

1 Initialization Problems for Java? Egon Borger 1, Wolfram Schulte 2 1 Universita di Pisa, Dipartimento di Informatica, I Pisa, Italy, boerger@di.unipi.it 2 Universitat Ulm, Fakultat fur Informatik, D Ulm, Germany, wolfram@informatik.uni-ulm.de Abstract. We exhibit a grey area in the specication of Java and of its implementation through the Java Virtual Machine (JVM): the treatment of initialization of classes and interfaces. We report the result of our experiments with dierent implementations of Java, which conrm the theoretical prediction of our work on mathematical models for Java [4] and the JVM [3], namely that the designers of Java and the JVM have used notions of initialization which do not match and which aict the portability of Java programs. We show also that concurrent initialization may deadlock and that various current Java compilers violate the initialization semantics through standard optimization techniques. Key words: Programming language { Java { Virtual machine { Compiler 1 The Initialization Problem Any programming language that supports libraries of autonomous components has to determine when to initialize a library component. Examples of components are modules, packages or classes. In traditional block oriented languages, like Pascal, C or C++, a global variable is associated with the initialization status of a component. This variable is initialized in the main program. However, this does not work for modern object-oriented languages like Eiel or Java. By denition they do not have a main program. Additionally, Java's support for dynamic class loading requires that initialization should be lazy, that is, it should take place just before a rst use of any item declared in a class. An additional complication is caused by parallel threads that try to initialize the same class at the same time.? This paper appears in Software { Concepts & Tools. Vol. 20, No. 4, Through two recent studies, where we provide a mathematical denition of the meaning of Java [4] and prove a natural scheme for compilation of Java on the Java Virtual Machine (JVM) to be correct [3], we discovered the following problems with initialization in Java and its implementations: { The exact moment when initializers for static elds in interfaces are executed is underspecied in the Java Language Specication (JLS) [6]. They can either be initialized when an interface eld is rst used, or when a class (an interface) that implements (extends) the interface is initialized. { The JLS and the JVM Specication (JVMS) [7] use semantically dierent and conicting concepts to de- ne when a class or interface is initialized. Whereas the JLS uses the concept of rst active use to trigger class or interface initialization, the JVM implements the initialization as a mandatory step of its (constant pool) resolution process. This process, however, is also triggered for instructions whose execution does not constitute rst active uses. { Concurrent initialization in Java may deadlock. If two threads initialize two dierent classes concurrently and both threads detect a rst active use of a component of the other class, then both threads become blocked, because they both wait that the respective other thread nishes its initialization. { Most Java compilers are awed, because their optimizations do not preserve the initialization semantics of a class or an interface. As a consequence programs with static initializers or initializers for static elds that have side eects, for example, perform input/output, assign non inherited class elds or throw exceptions, behave nondeterministically in unspecied ways. This behavior is inconsistent with Java's strive for portability.

2 2 Egon Borger, Wolfram Schulte: Initialization Problems for Java 1 class A implements I{ } 2 3 interface I { static boolean dummy = Main.sideeffect = true; } 4 5 class Main{ 6 static boolean sideeffect=false; 7 8 public static void main(string[] args){ 9 A a = new A(); 10 System.out.println("Side effect happened: " + sideeffect); 11 } } Fig. 1. The execution of the program Main shows whether the interface I is initialized when the implementing class A is initialized. 2 Initialization is Underspecied The JLS leaves an amount of implementation freedom for initialization, which is incompatible with the portability of programs. The JLS says that the superinterfaces of a class or of an interface need not be initialized before a class or an interface is initialized [6, x ]. They can be initialized, but their initialization is not required. Starting from our models for Java [4] and for the JVM [3] one can provide dierent renements that are compatible with the requirements of the JLS but yield dierent results for interface initialization. Experimentation with current implementations conrms this: Figure 1 shows the application Main, which execution in dierent implementations leads to dierent results due to this underspecication of interface initialization. Sun's Java Development Kit (JDK) 1.1 running the application Main on several platforms initializes the interface; the respective JVM prints Side effect happened : true. 1 On the other hand IBM's Visual Age 1.0 for Java running Main on Windows or Netscape 3.0 running the corresponding applet on Solaris do not initialize the interface, i.e. they print Side effect happened : false. Even the main vendors of Java (machines) implement the initialization strategy dierently, which obviously contradicts portability. Table 1 shows the interface initialization behavior of dierent implementations. 3 Initialization is Ambiguous Initialization in Java is based on the concept of rst active use: if a constructor or a member of a class is used, the class must be initialized. 2 On the level of the JVM initialization is triggered by constant pool resolution [7, x 5]. The constant pool plays 1 It has been pointed out to us by G. Attardi that in JDK 1.2 for Solaris of Sun our program is not initialized anymore. 2 With respect to the JLS [6, x ] this description is slightly simplied, however, for our purposes it suces. For a more rigorous and complete denition see also [4]. the role of a symbol table. JVM instructions that take classes, interfaces, elds or methods as operands, reference these entities symbolically using the constant pool. At runtime the symbolic reference is checked whether the denoted entity has been successfully loaded, linked and initialized and otherwise loading, linking and initializing it. Next, it is checked whether the access to the resolved item is granted. In case both checks are passed, the symbolic reference is translated into a concrete reference to a runtime data structure. The JLS and the JVMS initialization descriptions dier: Since the JVM checkcast and instanceof instructions reference classes or interfaces, execution of these instructions require constant pool resolution, possibly initializing the referenced type. Yet, the corresponding Java phrases, namely the reference type cast expression and the instanceof operator, are not active uses in Java. These expressions do not trigger the initialization of the referenced types. This inconsistency can be traced in our rigorous models for Java [4] and the JVM [3] as platform for compiling Java code. The inconsistency is experimentally demonstrated by slightly changing application Main of Fig. 1. We extend the class A (in line 1) by a static method someobject that returns a new instance of class A. Additionally, we change line 9, so that it tries to cast null or the result of the someobject method invocation to the interface I. 3 1 class A implements I { static Object someobject(){ return new A();} } 9 I i = (I) (args.length==0? null : A.someObject()); Sun's JDK 1.1 follows the JVM description. The application of the checkcast operation with operand I triggers I's initialization and prints Side effect 3 The statement I i = (I) null; would expose the same problem. However, several compilers eliminate the cast, which mixes up the experiment.

3 Egon Borger, Wolfram Schulte: Initialization Problems for Java 3 Toolkit JDK 1.1 MS J Platform diverse Windows IBM Java 1.0 Windows Borland JBuilder 1.0 Windows Netscape 3/4 Apple Appletrunner MS Explorer 3.0 diverse Mac OS Windows Underspecied Eager Eager Lazy Eager Lazy 4 Eager Eager Ambigous JVM JVM Java JVM JVM JVM JVM Correct No Yes No No { { { Table 1. Behavior of dierent Java/JVM implementations. The row `Underspecied' shows whether an interface is initialized lazy or eager. The row `Ambigous' shows whether the implementation uses Java or JVM semantics for initialization. The row `Correct' shows whether compiler optimizations respect the point of initialization. happened : true. However, according to the Java semantics the output should be Side effect happened : false, because the cast to I is not a rst active use. In fact, this is what IBM Visual Age 1.0 running on Windows produces. Both implementations behave dierently, yet both are right but on dierent levels. Table 1 describes the behavior of our program for several dierent systems. A similar problem arises in the context of array creation expressions. Whereas the JLS [6, x ] denes that in an array creation expression the array's base type is initialized, this is left out in the JVMS [7, x ]. But on the other hand constant pool resolution requires the initialization of the base type of any referenced array [7, x 5.1.3]. As a consequence, most implementations trigger class resolution in array creation expressions, an exception is Visual Age 1.0 on Windows. Another ambiguity appears, if a class initializer raises an exception that is not handled within the method. In this case the JLS [6, x ] and the JVMS [6, x ] require that the method's class must be labeled as erroneous. If the thrown exception is not an Error or one of its subclasses, then an ExceptionInInitializerError is thrown instead of the error. 5 If a class should be initialized or should be resolved but is already marked as erroneous, Java and the JVM require that a NoClassDefFoundError is reported. Experimentation, however, conrms only the following: If a class is not found for the rst n uses of the class, then n NoClassDefFoundErrors are thrown. But if rst an ExceptionInInitializerError is thrown, then in most implementations (e.g. the JDK 1.1) successive uses of the class do not throw NoClassDefFoundErrors. Although the class is in an inconsistent state, the class is accessed. This behavior contradicts the language and machine specication as well as our models [3, 4]. 4 Netscape 3 initializes the interface lazily, whereas Netscape 4 does it eagerly. 5 An ExceptionInInitializerError is a subclass of RuntimeException as specied in [6, x 20.23] and not a subclass of Error as specied in the introduction to chapter 20 in [6]. 4 Optimization May Go Wrong Several compilers do not preserve the semantics of initialization. This can be demonstrated experimentally by slightly changing Main of Sect. 3. We replace the call of A:someObject in line 9 by the body of the method someobject declared in class A. 9 I i = (I) (args.length==0? null : new A()); According to the Java semantics (see [6]), which is reected in our model [4], this change should have no eect. However, most compilers deduce that the type of the conditional expression is either A or the null type. In both cases the reference type cast to the interface I will succeed and so most compilers eliminate it (see Table 1). According to the JLS this is correct, but it is inconsistent with the use of resolution. Note, that some compilers also eliminate \redundant" phrases like dead = instance.field, where dead is, at the point where the phrase appears, never subsequently used. This transformation is only correct, provided the class of the instance is already resolved. However, in general this cannot be statically decided. Indeed, most aforementioned compilers do not preserve the semantics of initialization under all circumstances. An exception might be Microsoft J++, for which we did not nd a negative test case. The language designers of Java have foreseen this problem (cf. [6, x ]). Nevertheless, we found this compiler error interesting to note, since this kind of error is typical for subtle errors involving implicit actions and side eects. 5 Initialization May Deadlock Java supports concurrency. Concurrent initialization is dicult because several threads may be trying to initialize a class at the same time. Java proposes the following strategy [6, x ]: When initialization of a class is in progress by some thread, then other threads that

4 4 Egon Borger, Wolfram Schulte: Initialization Problems for Java 1 class A { 5 class B { 2 static char a = 'a'; 6 static char b = 'b'; 3 static { a = B.b;} 7 static { b = A.a;} 4 } 8 } Fig. 2. Concurrent execution of the static initializers of classes A and B may deadlock. also want to initialize the class have to wait until initialization of the class is done or an error occurs. In both cases all waiting threads have to be awaked by the active thread. Awaked threads check the initialization status of the class. If initialization was successful the awaked thread immediately returns, if initialization failed an exception is thrown. This behavior of Java is formalized in our model Java T [4]. Now consider the problem that there are two classes A and B, which static initializer depend on each other (see Fig. 2 for the example). The result of executing these initializers is dependent on the thread scheduler. If a single thread executes both initializers and if the thread has rst entered the static initializer of A, then A.a and B.b are set to 'a'; if the thread has rst entered the static initializer of B, then both class variables are set to 'b'. However, if two threads concurrently enter the static initializers, then as can be checked in our model [4] for Java both will detect a rst use of the respective other class. But since the initialization of the other class is in progress by the respective other thread, both start waiting, but no thread will awake them. This is a typical deadlock. This deadlock, however, is not visible for the programmer. He has not used any synchronization mechanism. This usually means that the result of a computation may be nondeterministic, but there is always progress. Another complication arises from the fact that it is the thread scheduler who is actually responsible for running the threads in parallel. If the scheduler switches between runnable threads during initialization, the program might deadlock. If the scheduler does not switch, the program makes progress. The implementation of the thread scheduling, however, is up to the vendor and can usually not be inuenced by the programmer. As predicted by our mathematical model for Java, dierent implementations (e.g. the JDK 1.1) deadlock. 6 Discussion and Proposal of Solution Mostly the analysis of Java is concentrated on nding security errors. Work in this area can be classied as experimental, for instance [9, 10], or theoretical, for instance [1, 11]. To simplify the formal analysis, none of these theoretical studies does care about initialization and as a consequence none of them did detect Java's initialization problems. In their descriptions of defensive JVMs Bertelsen [2] and Cohen [5] noticed the problems of underspecication and ambiguity. However, their observations were never conrmed. Perara and Bertelsen maintain an on-line list of errors, ommissions, and ambiguities of the JLS and the JVMS [8]. There is a simple solution to the initialization problem: Programmers should strive for initializations that only read or write inherited variables. (This check could easily be integrated into the Java compiler as well as the bytecode verier.) In case one has to read or write non inherited variables, for example to open a network connection, an extra method should be used to encapsulate the eect, and must be called outside of a static initializer or an initializer of a static eld. 6 The designers of the Java language should eliminate the underspecication of interface initialization and should agree with the designers of the JVM on the used concept for when classes are initialized. Finally, compiler writers should implement the specication correctly. Acknowledgements. We thank G. Attardi, P. Bertelsen, C. Pusch, J. Schmid, T. Thorn, and T. Vullinghs for valuable comments on the draft of this paper. References 1. J. Alves-Foss, editor. Formal Syntax and Semantics of Java(tm). Springer LNCS, to appear P. Bertelsen. Semantics of Java byte code. Ftp at: ftp://ftp.dina.kvl.dk/pub/sta/peter.bertelsen/jvmsemantics.ps.gz, E. Borger and W. Schulte. Dening the Java Virtual Machine as platform for provably correct Java compilation. In L. Brim, J. Gruska, and J. Zlatuska, editors, MFCS'98, Springer LNCS 1450, E. Borger and W. Schulte. A programmer friendly modular denition of the semantics of Java. In Alves-Foss [1]. 5. R. M. Cohen. Defensive Java virtual machine version 0.5 alpha release. Web pages at: http: // J. Gosling, B. Joy, and G. Steele. The Java(tm) Language Specication. Addison Wesley, One could develop weaker constraints, for example that the dependency relation between classes, established by the use of variables in static initializers and initializers for static elds, must be acyclic. However, this would complicate compile-time checking as well as bytecode verication.

5 Egon Borger, Wolfram Schulte: Initialization Problems for Java 5 7. T. Lindholm and F. Yellin. The Java(tm) Virtual Machine Specication. Addison Wesley, R. Perera and P. Bertelsen. Java spec report. Web pages at: V. Saraswat. Java is not type-safe. Web pages at: E.G. Sirer, S. McDirmid, and B. Bershad. Kimera: A Java system security architecture. Web pages at: R. Stata and M. Abadi. A type system for Java bytecode subroutines. In Proceedings of the 25th Annual SIGPLAN-SIGACT Symposium on Principles of Programming Languages, 1998.