JaCIL: A CLI to JVM Compiler Technical Report. Almann T. Goo Rochester Institute of Technology Department of Computer Science

Transcription

1 JaCIL: A CLI to JVM Compiler Technical Report Almann T. Goo atg2335@cs.rit.edu Rochester Institute of Technology Department of Computer Science July 25, 2006

2 Abstract Both the.net Framework via the Common Language Infrastructure (CLI) [15] and the Java Virtual Machine (JVM) [14] provide a managed, virtual execution environment for running high-level virtual machine code. As these two platforms become ubiquitous, it is of pragmatic and academic interest to have the capability of running CLI code on the JVM and vice-versa. This report describes JaCIL (pronounced jackal ), a project that implements a CLI assembly to JVM class file byte-code compiler framework. Also provided by JaCIL, is a user-land tool interfacing this framework, and a runtime library to support translated code.

3 Contents 1 Introduction The Java Virtual Machine The Common Language Infrastructure Related Work Previous Translation Efforts and Platform Comparisons IKVM.NET Java Virtual Machine Visual MainWin for J2EE Retroweaver The Mono and DotGNU Projects JaCIL Software Design Functional Specification JaCIL Compiler Framework JaCIL Run-time Library Technical Design and Architecture Compiler Framework Overview The Compiler API The Context API Standard Context API Implementation

4 2.2.4 The Translator API Standard Translator API Implementation The Utility API The jacilc Application CLI Feature Specification Assemblies Assembly Translation Limitations Assembly Entry Points Entry Point Translation Limitations Modules Types Type Translation Limitations Name Mangling Array Support Generics Inner Classes Enumerations Delegates Managed Pointers Managed Pointer Translation Limitations Value Types Value Type Translation Limitations Type Definitions Value Type Definitions Type Definition Translation Limitations

5 3.8 Field Definitions Field Definition Translation Limitations Method Definitions Method Name Mangling Local Variables Exception Handling Support Constructors Method Definition Translation Limitations JaCIL Implementation of Standard CLI API System.Object Implementation System.Type Implementation Other Classes Instruction Set Support Non-operation Instructions Stack Instructions Stack Duplication of Value Types Local Variable and Argument Instructions Implicit Conversions Loading and Storing to Boxed Local Variables Value Type Loading Constant Loading Instructions Arithmetic Instructions Arithmetic Instruction Translation Limitations Numeric Conversion Instructions Branch and Comparison Instructions Unconditional Branches

6 The switch Instruction Comparison and Other Conditional Branches Method Invocation and Return Instructions Method Invocation on Value Types Method Invocation Translation Limitations Static and Instance Field Access Instructions Field Access on Value Types Object Creation and Initialization Vector Instructions Vector Element Access Vector Creation Vector Length Exception Instructions Exception Throwing Leaving Protected Blocks Leaving Finally Blocks Indirection Instructions Address Load Instructions Local Variable Address Load Static and Instance Field Address Load Array Element Address Load Value Type and Reference Type Instructions Boxing and Unboxing The initobj instruction Reference Type Checking and Conversion Translation Examples

7 Basic Operations Exceptions Value Types and Managed Pointers JaCIL User Guide Building JaCIL Using the Compiler Tool Running Compiled Code Performance and Benchmarking Blowfish Cipher MD5 Message Digest Line Drawing Algorithm with Value Types Bresenham s Line Drawing Algorithm with Managed Pointers 85 6 Conclusions Lessons Learned Future Work Missing Compiler Features CLI Standard API JaCIL on the JVM CLI Implementation

8 List of Figures 2.1 Compiler API class relationships Context API interface hierarchy Cross-section of the Context API interface relationships Standard Context API control flow Cross-section of Translator API interface relationships IInstructionTranslator creation flow in standard factory implementation jacilc control flow Value type translation memory diagram for local variables Sample C# method definition with basic operations CIL code compiled from source in figure Java byte-code generated by JaCIL from the code in figure Sample C# method definition with a catch handler CIL code compiled from source in figure Java byte-code generated by JaCIL from the code in figure Sample C# method definition with value type operations CIL code compiled from source in figure Java byte-code generated by JaCIL from the code in figure

9 4.1 jacilc.exe output with -? switch Using jacilc.exe to compile an assembly to a JAR file Running translated code Sample C# Hello World type program

10 List of Tables 2.1 JaCIL Compiler Framework namespaces ICompiler primary methods ITypeTranslator translation methods JaCIL Compiler utility primary classes JaCIL built-in type mapping JaCIL managed pointer type mapping Supported CLI type attributes and their JVM translations Supported CLI field attributes and their JVM translations Supported CLI method attributes and their JVM translations Supported CLI implementation attributes and their JVM translations java.lang.object method overrides in System.Object JaCIL supported instructions add through ldelem.u JaCIL supported instructions ldelem.u2 through xor CIL Local variable and argument load instructions JVM Local variable load instructions CIL Local variable and argument store instructions JVM Local variable store instructions CIL field access instruction translation semantics

11 3.15 JVM numeric instruction prefixes JaCIL translations for CIL arithmetic operations on integers and floating point values CIL Arithmetic Instructions for integer types only CIL conversion instruction target types CIL conversion instruction target JVM stack types Additional operations for small integer conversion Translation semantics for brtrue and brfalse Translation semantics for CIL comparison branch instructions CIL supported comparison instructions and their branch counterparts CIL ret translation semantics CIL field access instruction translation semantics Supported CIL vector load instruction variants JVM array element access instructions Supported CIL vector store instruction variants JaCIL base managed pointer types in the JaCIL.Runtime.- Pointers package Supported CIL indirect load instruction variants Supported CIL indirect store instruction variants JaCIL NAnt build targets jacilc.exe command-line options Benchmarking systems used in JaCIL benchmarking Blowfish benchmarking results MD5 benchmarking results Value type line drawing benchmarking results

12 5.5 Bresenham s line drawing benchmarking results

13 Chapter 1 Introduction The concept of a Virtual Machine (VM) is far from a new concept, but undoubtedly with the advent of Sun s Java Platform it has become far more popular as application code can be compiled to a platform independent image and executed on any machine that has a Java Virtual Machine (JVM) implementation [11]. Microsoft has since introduced its own competing.net Framework platform that has similar aims. With the influence that a major company like Microsoft has, it would seem destined that its platform shall also rise in popularity, creating two sets of applications and libraries that exist on one platform or the other. Even though both platforms have strikingly similar features [11], they are not binary compatible with one another. Thus, platform independent code from one execution environment is unavailable to the other. Since each platform itself can be viewed as another machine, albeit much more high-level than a physical machine, it would seem reasonable then, that an implementation of either platform could be created on the other. This has in fact been done in the IKVM.NET [10] project, which implements the JVM on the CLI this is discussed in section With that said, the author knows of no such open implementation for other direction a full CLI implementation on the JVM. 1.1 The Java Virtual Machine As many have stated, the JVM was developed as an execution environment for the Java Programming Language [11, 18, 12]. The JVM is an abstract stack-based machine with some of its major characteristics noted 11

14 below: [14] Direct operations for primitive integers and floating point values. A notion of a reference which is an address, but no primitives to manipulate the value of such an address (e.g. taking the address of a local variable or incrementing such an address). A run-time heap, shared by all program threads, where all objects are allocated; complex types are never allocated in a stack frame. A private per-thread stack to store frames of method executions, containing an activation s operand stack and local variables. JVM class files, the binary image of a loadable component (class), contain various metadata that define the class, its fields, and its methods. This structure also defines symbolic information accessed by byte-code instructions in method definitions [14]. 1.2 The Common Language Infrastructure The CLI, from a high level, has much in common with the description given of the JVM in section 1.1. It too, has a stack-based architecture, but has features that make it more friendly for various programming language paradigms to target [13]. Given its high-level similarities, some of the compelling differences are highlighted below: [8, 15, 11] The CLI instruction set tends to be more generalized for operations such as arithmetic most equivalent JVM instructions have the type information embedded in them. The CLI supports user defined value types that can be allocated directly on the stack or directly within the memory of another object. The concept of a managed pointer, which is like a JVM reference address, but with additional instruction support to manipulate such pointers. More specifically, the CLI provides instructions that take an address of a local variable, argument, field, or method, and instructions to perform indirection on such a pointer. Support for tail calls. The CLI provides support for invoking a method and discarding the stack frame of the caller. This is essential for languages that depend on tail recursion as a looping mechanism (e.g. Scheme). 12

15 CLI assemblies are the binary image of a loadable component in the CLI. Unlike their Java equivalent, they can consist of numerous types (classes) and contain global metadata as well as metadata for each class [8]. In fact it is not difficult to draw the parallel between Java Archive (JAR) files and CLI assemblies [15]. CLI assemblies, much like their Java analog contain similar types of metadata. 1.3 Related Work The following subsections describe related work and relevance to the JaCIL project Previous Translation Efforts and Platform Comparisons Perhaps the most prominent work in translating from the CLI to the JVM comes from Shiel and Bayley who have actually implemented a rudimentary translator from the CLI to the JVM [17]. The intent of their work was to discuss how the semantics of the CLI compare with the JVM and to use this study as a basis for formalizing CLI semantics [17]. These surveys provided some good insight as to various approaches that could be taken when translating CLI semantics. Shiel and Bayley s highlevel descriptions of translating certain CLI semantics were considered when implementing such semantics in JaCIL IKVM.NET Java Virtual Machine IKVM.NET is an open source implementation of the JVM on the CLI. It provides a VM implementation consisting of a JVM to CLI JIT compiler, Java Standard API (via GNU Classpath), and support tools like an AOT compiler and an analog of the java command [10]. IKVM.NET, which is essentially the reverse implementation of the JaCIL project, served a very important role for this project. Besides serving as inspiration for the project itself, leveraging the IKVM.NET run-time in the JaCIL Compiler allowed JaCIL access to practically any Java API in addition to the APIs already available in the CLI. In particular, the ObjectWeb ASM Framework (ASM) [6] is used via the IKVM.NET to generate JVM class files. 13

16 1.3.3 Visual MainWin for J2EE Visual MainWin for J2EE is a commercial product that consists of an AOT byte-code compiler from CLI assemblies to JVM class files, a run-time layer, and an implementation of the.net Framework Standard API (via the Mono Project) [7]. It is in essence, a commercial offering of what JaCIL is aiming to provide. Unfortunately, not much can be leveraged from this product because it is a closed, proprietary system. Also, the target audience of this product seems to be Java 2 Enterprise Edition (J2EE) integration from Visual Studio [7], so it is not clear to the author how general purpose the product aims to be. It should be noted that Mainsoft, the producer of this software, does make open source contributions to the Mono Project (see 1.3.5), specifically to Mono s class libraries [7]. Such contributions could be leveraged in a future effort to use JaCIL to translate or port such APIs Retroweaver This project provides a byte-code converter for Java 1.5 byte-code to Java 1.4 compatible byte-code. This project also provides a thin compatibility run-time emulating semantics not natively present on legacy JVM implementations [1]. Retroweaver is similar to the JaCIL project in that its goals parallel this project the key difference, of course, is that it is a JVM-to-JVM translation system The Mono and DotGNU Projects Both the Mono [5] and the DotGNU [3] projects are open source projects providing an implementation of the.net Framework including the CLI and the.net Framework Standard API. These projects point out implementations of the CLI other than that of Microsoft and could be leveraged in future directions of this project. Specifically, having a working CLI to JVM byte-code compiler would enable the CLI byte-code portions of the libraries to be converted to JVM byte-code thus eliminating the need to directly implement a considerable portion of the CLI standard API in Java. This would leave only the native portions of the CLI standard API to port to Java the end result being nearly a complete CLI standard API implementation in Java. This is in fact the strategy the IKVM.NET JVM implementation employs 14

17 by using a statically JVM to CLI byte-code compiled version of the GNU Classpath Java Standard API implementation [10, 4]. Furthermore, the author used Mono as the principal development environment for implementing the compiler and other code targeting the CLI for the project. 15

18 Chapter 2 JaCIL Software Design This chapter describes the architecture and design of the JaCIL project. 2.1 Functional Specification The JaCIL Project consists of a two major components: the JaCIL Compiler Framework and the JaCIL Run-time Library JaCIL Compiler Framework The compiler framework consists of the byte-code compiler to translate CLI compiled assemblies into equivalent JVM class files. This framework translates types (e.g. classes), fields, methods, and appropriate metadata defined in a CLI assembly into the equivalent JVM analog. This system also translates program code written in Common Intermediate Language (CIL) instructions the byte-code language of the CLI that comprises the code within method definitions. The compiler framework provides a public CLI API for working with, extending, and embedding the compiler. Public interfaces are provided by the framework s API to allow a developer to embed the compiler. The framework also provides the concept of compiler profiles which allow a developer to extend or change the behavior of the compiler (this is discussed in detail in section 2.2) A front-end application, jacilc, using the standard implementation and 16

19 profile of the framework is provided to be used as a compiler tool much like Java s javac. This tool provides a command-line interface allowing usage of the framework by an end-user. The JaCIL Compiler Framework does not leverage new features introduced in Microsoft s.net Framework 2.0. As such, it is known to compile and run on Mono or later, Microsoft s.net Framework 1.1, and Microsoft s.net Framework 2.0. Code translated by the compiler framework is designed to run on the Java 1.5 virtual machine lower versions are not supported and are known not to be able to execute JaCIL translated code. Chapter 3 provides the specification of how CLI semantics are translated by the standard implementation (i.e. standard profiles) of the framework. Furthermore, the binary distribution of JaCIL contains the complete framework API specification JaCIL Run-time Library The run-time library is a Java hosting library that is used to provide the support routines needed to run translated classes on the JVM. This library is designed to target the Java 1.5 virtual machine. The run-time library provides two major sets of support classes. The first is a subset of the classes found in the CLI standard API s System namespace. The functional scope of this subset is limited to an implementation suitable for basic translation (e.g. a System.Object implementation is provided because all CLI types are derived from it). The second is a JaCIL only namespace, JaCIL.Runtime, which provides support classes to emulate semantics that do not have a direct JVM equivalent. Chapter 3 specifies to what extent the standard CLI API is supported and the classes defined to emulate CLI features in the run-time library. Also, the binary distribution of JaCIL contains the complete run-time library API specification. 2.2 Technical Design and Architecture The following subsections describe in detail the design of the JaCIL Compiler Framework. Since the JaCIL Run-time Library is inextricably linked to the translation semantics, this system is discussed in further detail in chapter 3. 17

20 2.2.1 Compiler Framework Overview The compiler framework is a single CLI assembly. The namespaces that are used to logically separate sub-components of the framework are listed in table 2.1. Namespace JaCIL.Compiler JaCIL.Compiler.Instruction JaCIL.Compiler.Context JaCIL.Compiler.Translator JaCIL.Compiler.Standard.Context JaCIL.Compiler.Standard.Translator JaCIL.Compiler.Standard.Translator.Instruction JaCIL.Compiler.Util Description Top-level API and system exceptions Instruction and analysis API The compiler context API interfaces The compiler translator API interfaces Standard implementation of the context API Standard implementation of the translator API Instruction-level implementation of the translator API Compiler utility API Table 2.1: JaCIL Compiler Framework namespaces For reading the binary format of CLI assemblies, the compiler framework depends on the Mono Cecil Project [9]. To emit the binary format of the JVM, the Java based ObjectWeb ASM Framework [6] is used in conjunction with IKVM.NET [10] The Compiler API The JaCIL.Compiler namespace provides high-level interfaces to the JaCIL Compiler. The root compiler interface, ICompiler, defines two public methods to invoke the compilation process (listed in table 2.2). This API also defines all exception classes used throughout the framework, as well as a compiler specific data structure and collection interface. The data structure, ClassInfo, provides a data structure consisting of an ObjectWeb ASM ClassWriter and a string name for a generated class this is structure is provided because the ClassWriter class does not store the class name. The collection interface, IClassInfoSet, represents an aggregation of ClassInfo objects and has a standard implementation (i.e. ClassInfoSet). Also provided in this API is the ICompilerReferences interface. This interface defines functionality to look up information about CLI types that may or may not be within direct context of the compiler instance (e.g. types being used by an assembly, but not being compiled by a compiler instance). 18

21 Method CompileToClassWriter() CompileToJar() Description Invokes the compiler on the named assemblies and returns the resulting compiled classes into IClassInfoSet data structure. Invokes the compiler on the named assemblies and generates a JAR file directly. Table 2.2: ICompiler primary methods This interface is intended to provide additional information during the compilation process that is not otherwise available from a CLI assembly being translated (e.g. querying if a referenced type is an interface or a class). This functionality is similar to passing references to a C# compiler or using the class path when invoking the Java compiler. The standard implementation, CompilerReferences, allows a user to specify both assembly objects from the standard CLI reflection API and assembly definition objects from the Mono Cecil Framework. This implementation also allows for automatically using core, system references: the mscorlib and IKVM.GNU.Classpath (e.g. the Java standard API provided by IKVM.NET) assemblies. The ICompiler interface serves as the top-level context for an entire compiler session. It provides, to lower parts of the framework, the ICompiler- References that are to be used to during the compilation process, a messaging object for user output, the JVM class file version to generate, and the context profile (section 2.2.3) and translator profile (section 2.2.4) that drive the behavior of the compiler. An ICompiler implementation loads the CLI assemblies to be compiled and creates and delegates to contexts representing them (see section 2.2.3). The standard compiler implementation, Compiler, uses the standard context and translator profiles, but can be overridden with user-defined instances of such profiles. Figure 2.1 depicts the class relationship in this API. 19

22 org.objectweb.asm.classwriter 1 ClassInfo 0..* <<interface>> IClassInfoSet ClassInfoSet <<interface>> ICompiler <<interface>> JaCIL.Context.IContextProfile 1 Compiler <<interface>> JaCIL.Translator.ITranslatorProfile 1 <<interface>> ICompilerReferences 1 0..* Mono.Cecil.AssemblyDefinition CompilerReferences 0..* System.Reflection.Assembly Figure 2.1: Compiler API class relationships 20

23 2.2.3 The Context API The JaCIL.Compiler.Context namespace provides the interfaces that abstract the logical structure of a CLI assembly. The main purpose of these interfaces is to provide a JaCIL specific abstraction over the Mono Cecil representation of an assembly. Implementations of the Context API also provide analysis and information for the compilation process, and delegate to JaCIL.Compiler.Translator interface implementations as needed to execute the actual translation. There is a context for each logical aspect of a CLI assembly supported by the compiler. For example, a type definition in an assembly is represented by the ITypeContext interface. For each context type, there is a factory interface that defines the protocol for creating instances for ITypeContext, this is ITypeContextFactory. Since there are numerous contexts that can be produced and a factory exists for each, a top-level context profile defines how to retrieve factories this is the IContextProfile interface. This multi-tiered design allows for maximal flexibility and point customization. For instance, a developer could define a custom IContextProfile implementation that defined a completely different scheme for producing factories and instances or simply extend the standard ContextProfile and overload a single property to provide a new factory for generating ITypeContext instances. Figures 2.2 and 2.3 illustrate an example cross section of the interface relationships for the Context API. Each context interface defines a TraverseXXX() method, where XXX is dependent on each context interface. These methods are invoked in an implementation specific manner during the compilation process. It is during traversal, that a context implementation creates a translator object for its context and delegates to it to generate the actual JVM translation for that context (see section for details on the translator API). One part of this API that does not follow the 1-to-1 relationship of CLI assembly construct to context object is the IInstructionAnalyzer interface. This interface is responsible for doing most of the analysis on the CLI instruction stream. The JaCIL.Compiler.Instruction namespace provides instruction level primitives to support this analysis. This namespace includes classes to support operand stack analysis, branch source/target analysis, and a higher level abstraction of the CLI instruction stream. An IInstructionAnalyzer implementation specifies one method, Generate- InstructionStream(), that is required to perform such analysis. 21

24 <<interface>> IInstructionAnalyzer <<interface>> IContext <<interface>> IAssemblyContext <<interface>> IModuleContext <<interface>> IInstructionContext <<interface>> ITypeContext <<interface>> IMemberContext <<interface>> IFieldContext <<interface>> IMethodContext Figure 2.2: Context API interface hierarchy 22

25 <<interface>> IContextProfile <<interface>> ITypeContextFactory 1 <<interface>> IMethodContextFactory 1 <<interface>> ITypeContext Creates 0..* <<interface>> Creates 0..* IMethodContext Figure 2.3: Cross-section of the Context API interface relationships Standard Context API Implementation JaCIL s standard implementation of the Context API is defined in the JaCIL.- Compiler.Standard.Context namespace. This implementation provides the standard compilation flow for the compiler. This flow is depicted in figure 2.4. Because instruction translation from the CLI to the JVM is not a direct 1- to-1 process, this implementation also provides special implementations of IInstructionContext that are used to represent synthetic instructions that are particular to JVM translation. An example of this is the NewDup- InstructionContext, which is used for translating object creation opcodes in the CLI The Translator API This API is represented by the JaCIL.Compiler.Translator namespace. Interfaces defined in this namespace represent the components of the translator that generate JVM byte-code with ObjectWeb ASM Framework classes. The structure of this API parallels the Context API very closely. Where 23

26 Traverse Assembly Context Create and Delegate to Instruction Translator Create and Delegate to Assembly Translator All Modules Translated Traverse to Instruction Context in Instruction Stream Untranslated Modules Remain Create and Traverse to Module Context All Types Translated Untranslated Instructions Remain Create and Delegate to Method Translator Create and Delegate to Module Translator Untranslated Types Remain All Methods Translated Instructions Translated Create and Delegate to Instruction Analyzer Create and Traverse to Type Context Create and Traverse to Method Context Untranslated Methods Remain All Fields Translated Create and Delegate to Type Translator Create and Delegate to Field Translator Untranslated Fields Remain Create and Traverse to Field Context Figure 2.4: Standard Context API control flow 24

27 the Context API provides the analysis and abstraction of the CLI assembly to be translated, the Translator API defines how each context is to be converted to JVM semantics. For each Context API interface, IXXXContext (e.g. IMethodContext), there is an equivalent IXXXTranslator (e.g. IMethodTranslator) interface. This follows similarly for factory interfaces and the overall translator profile, ITranslatorProfile. Very similar to the Context API, figure 2.5 represents an example cross-section of this relationship. <<interface>> ITranslatorProfile <<interface>> IAssemblyTranslatorFactory 1 <<interface>> IModuleTranslatorFactory 1 <<interface>> Creates 0..* IAssemblyTranslator <<interface>> Creates 0..* IModuleTranslator Figure 2.5: Cross-section of Translator API interface relationships Each translator interface provides a set of TranslateYYY() methods specific to each translator. These methods are invoked in an implementation specific manner during the compilation process from the translator s context. As an example, table 2.3 shows the translation methods for the ITypeTranslator interface. There is one interface that has no Context API analog, IEmitter. This interface represents general byte-code generation routines, and is intended to be context interface independent. There are numerous unrelated translation points within the standard implementation that generate similar streams of JVM instructions. Instead of duplicating the code to emit these streams at each point, the standard implementation defines implementations of IEmitter to centralize the related generation code. 25

28 Method TranslateExceptionTable() TranslateInstructionStream() TranslateMethodDefinition() TranslateMethodSupportClasses() Description Generates the JVM exception table for the method being translated. Rearranges the instruction stream for any JVM specific reasons. Defines the JVM method and returns the appropriate ClassInfo object for instructions to be emitted to. Emits any JVM classes that are needed to support the translation of the method. Table 2.3: ITypeTranslator translation methods Standard Translator API Implementation The standard implementation of the Translator API is contained within two namespaces: JaCIL.Compiler.Standard.Translator and JaCIL.Compiler.- Standard.Translator.Instruction. The individual IInstruction- Translator and IEmitter implementations are contained within the latter, while the rest of the standard implementation is contained within the former. The IInstructionTranslatorFactory implementation, Instruction- TranslatorFactory, is probably of most interest within the standard implementation. This class is responsible for creating IInstruction- Translator objects based on the instruction represented by the IInstruction- Context being translated. Within this implementation, a switch is executed over the op-code of the instruction to generate a translator instance for. Instead of constructing the standard IInstructionTranslator from the switch target, a virtual, protected method that proxies the object creation is invoked. The rationale for this approach is that a custom implementation that wants to leverage most of the standard translation semantics need only override these proxy methods to instantiate custom implementations of IInstructionTranslator. Figure 2.6 illustrates this. 26

29 Create Appropriate Instruction Translator Create Instruction Translator for Instruction Context Invoke Appropriate Factory "Create" Method for Instruction Translator Supported Instruction Switch on Op-code Throw Translation Exception Unsupported Instruction Since the "gray" action is a virtual method, a custom implementation can simply override it, this way the switch block does not need to be re-implemented. Figure 2.6: IInstructionTranslator creation flow in standard factory implementation 27

30 2.2.5 The Utility API The JaCIL.Compiler.Util namespace contains classes that provide common operations that are used by other parts of the framework and are not necessarily tied to the standard implementation. Table 2.4 describes briefly the major classes in this namespace. Utility Class Mangler TypeMapper TypeMetrics Description Provides the standard name mangling from CLI names to JVM names (e.g. the mapping between the CLI constructor name,.ctor, and the JVM equivalent, <init>). Provides an abstraction on top of Mangler for mapping various CLI type information to JVM equivalents (e.g. mapping the CLI type name System.Int32 as JVM descriptor I). Encapsulates various information that comprises a CLI type for use in translating into equivalent semantics on the JVM. Used by various parts of the compiler to preserve the semantics of the CLI primitives, some of which have no direct JVM equivalent. Table 2.4: JaCIL Compiler utility primary classes The jacilc Application The front-end application for the compiler framework is a CLI assembly with a simple entry point. The command line arguments are parsed with the Mono.GetOptions library and based on user provided arguments, an instance of JaCIL.Compiler.Compiler is constructed, and CompileToJar() is invoked on the instance to run the translation process. Figure 2.7 shows a high-level control flow for the compiler tool. Classes comprising the jacilc.exe CLI assembly are defined in the namespace JaCIL.Compiler.Tool. 28

31 Parse Options Create Compiler References Well Formed Options Invalid Options Display Error Message Create Standard Compiler Instance Invoke Compiler to Generate JAR Figure 2.7: jacilc control flow 29

32 Chapter 3 CLI Feature Specification The following sections describe the translation semantics of the JaCIL Compiler. This chapter defines the extent of the CLI that can be translated, and the limitations (i.e. caveats) of such translations. The following sections follow closely in structural order to topics listed in Partitions II and III of ECMA-335, Common Language Infrastructure (CLI) Specification [8]. 3.1 Assemblies A single deployable unit in the CLI is an assembly. The JaCIL project supports this structure only as far as an assembly is a collection of modules (see section 3.3). With the exception of a user defined program entry point (see section 3.2), all metadata defined at the assembly level is not translated by the compiler, and is silently ignored. The CLI also allows the notion top-level global fields and methods within an assembly. That is, fields and methods that do not have an enclosing class [8]. Although to the programmer this feature gives the impression of global fields and methods, in reality these are members of a class named <Module> that is defined in a module contained within the assembly. 30

33 3.1.1 Assembly Translation Limitations JaCIL does not make any special provisions for the special type, <Module>, and it is translated verbatim as the JVM type <Module>. Technically, the class generated is legal in Java 1.5 and can in fact be used, however the limitation of this is that classes that use the <Module> class will invariably run into a name clash if more than one translated assembly is used together under the same class loader. A potential solution to this limitation is the mangling the name of <Module> to be unique per assembly. This format could be similar to how entry points are translated (see section 3.2), and be in the form CLI.AssemblyName.- Module. For this to work properly, the method mapping semantics in the compiler would also have to map references to <Module> to this mangled name. 3.2 Assembly Entry Points The CLI defines a program entry point at the assembly level. Unlike the JVM, where any class can be run as an entry point provided it defines a main method of the proper form, the CLI uses metadata in the assembly to define the entry point for that assembly. As a result, a CLI assembly may have zero or one entry points. A CLI entry point method must be static, return nothing or a 32-bit integer, and have either no parameters or accept a single string array as its parameter. There is no restrictions in the CLI as to accessibility of the method or the name of the method. When translating this feature, JaCIL synthesizes a class named CLI.- AssemblyName.Main containing a JVM entry point of the proper form Entry Point Translation Limitations Currently, the system only supports translating CLI entry points that are publicly accessible outside of the class it is defined in. JaCIL will not emit an error or warning when translating entry points for classes that do not meet this criteria, but the resulting code will not run. A possible solution to this issue would be to always translate a method marked as the entry point public so it is accessible from the synthesized JVM entry point. Also, for entry points that return an integer, this is currently discarded by the JVM translated entry point. 31

34 3.3 Modules Each CLI assembly is comprised of one or more modules. A CLI module is considered to be a compilation unit comprising a collection of types (i.e. classes). JaCIL supports only this aspect of modules explicitly. As with assemblies, all module-level metadata is not directly translated by JaCIL. 3.4 Types Table 3.1 defines the built-in CLI types that are translatable with JaCIL. Within this table, the JVM type indicates the operative storage type used to store values of the CLI type (e.g. in JVM method and field descriptors). CLI Type JVM Type Description System.Boolean boolean The boolean type. System.Char char A 16-bit Unicode character. System.Single float A 32-bit floating point number. System.Double double A 64-bit floating point number. System.Byte byte An unsigned 8-bit integer. System.SByte byte A signed 8-bit integer. System.UInt16 short An unsigned 16-bit integer. System.Int16 short A signed 16-bit integer. System.UInt32 int An unsigned 32-bit integer. System.Int32 int A signed 32-bit integer. System.UInt64 long An unsigned 64-bit integer. System.Int64 long A signed 64-bit integer. System.Object java.lang.object An object type. System.String java.lang.string A string type. System.ValueType System.ValueType A valuetype type. Type[] JVM Type[] A vector type. Type & See table 3.2 A managed pointer type. Table 3.1: JaCIL built-in type mapping The storage type mappings for managed pointers are defined in table 3.2. The JVM mapped classes for managed pointers are defined as abstract classes in the JaCIL Run-time Library. All type names are converted to the equivalent native JVM representation. A type name will have any. characters converted to / characters. Section 3.7 discusses in detail the translation semantics for type definitions. 32

35 CLI Managed Pointer Type System.Boolean & System.Char & System.Single & System.Double & System.Byte & System.SByte & System.UInt16 & System.Int16 & System.UInt32 & System.Int32 & System.UInt64 & Other Type & JVM Type JaCIL.Runtime.Pointers.BoolPtr JaCIL.Runtime.Pointers.CharPtr JaCIL.Runtime.Pointers.Float32Ptr JaCIL.Runtime.Pointers.Float64Ptr JaCIL.Runtime.Pointers.UInt8Ptr JaCIL.Runtime.Pointers.Int8Ptr JaCIL.Runtime.Pointers.UInt16Ptr JaCIL.Runtime.Pointers.Int16Ptr JaCIL.Runtime.Pointers.UInt32Ptr JaCIL.Runtime.Pointers.Int32Ptr JaCIL.Runtime.Pointers.UInt64Ptr JaCIL.Runtime.Pointers.ObjectPtr Table 3.2: JaCIL managed pointer type mapping Type Translation Limitations The following subsections describe current limitations with regard to the general translation of types Name Mangling Types with names that are legal in the CLI, but are not legal in the JVM are translated verbatim and are thus become invalid class files when compiled with JaCIL. This can be mitigated in the future by defining better name mangling semantics Array Support JaCIL only supports zero-based index, single dimensional arrays called vectors in the CLI. Implicitly, this means that jagged arrays (vectors of vectors) are supported. CLI multi-dimensional arrays or arrays with a nonzero lower bound are not supported. The JaCIL Compiler will not emit an error when translating such constructs, since there are no special instructions for multi-dimensional arrays, but the class references emitted for such arrays do not exist in the run-time. A possible solution for this could be to utilize a custom class loader on the run-time that generates the multi-dimensional arrays as needed by translated code. This approach has the benefit of requiring no modification to 33

36 the compiler, but adds complexity to the run-time requirements of translated code Generics JaCIL does not support CLI generics. One potential approach, though potentially a problematic one, is to support generics in the same way that the JVM supports it by type erasure Inner Classes JaCIL does not support inner class definitions. Since the JVM supports this semantic, future support for this should be a straightforward task Enumerations JaCIL does not support user-defined enumerations. Since current versions of the JVM supports this semantic, future support for this should be a straightforward task Delegates JaCIL does not support user-defined delegates. From a CLI point of view, a delegate is a class definition that encapsulates a method pointer and an optional object instance. This object instance is used to bind the this parameter when used on instance methods. In order to support delegates in the future, JaCIL will have to define a translation semantic for the ldftn and ldvirtftn instructions. In addition to supporting these instructions, JaCIL will have to synthesize the body of a delegate class s invoke method, as such code is provided by the run-time [8]. 3.5 Managed Pointers JaCIL supports CLI managed pointers, which can point to local variables, arguments, fields, and array elements. Managed pointers are also distinguished from unmanaged pointers in the CLI in that the operations allowed on them are severely restricted arithmetic, for instance, is only allowed on managed pointers to array elements [8]. 34

37 The extent that JaCIL supports managed pointers are limited to their use in method definitions (see section 3.9), address instructions (see section ), and indirection instructions (see section ) Managed Pointer Translation Limitations JaCIL does not support the limited arithmetic support for managed pointers that has been previously mentioned. This support could be potentially added as an API change to the pointer classes defined in the JaCIL Runtime Library package JaCIL.Runtime.Pointers. 3.6 Value Types JaCIL supports CLI value types, which are types whose memory is allocated directly (e.g. on the operand stack, local variable register, or user-defined type field). JaCIL can translate value type definitions (see section 3.7.1), usage of value types in method definitions (see section 3.9), field definitions that are value types (see section 3.8), and value type semantics for instructions that operate on them (see section 3.11) Value Type Translation Limitations Due to no native equivalent of value types in the JVM, JaCIL translates value types that are not primitive types as heap objects. This adds considerable overhead when using value types, as translated code clones the heap object when a copy is needed. Figure 3.1 illustrates the memory model for value types with local variables. 3.7 Type Definitions JaCIL supports the translation of user-defined classes (i.e. non-interface reference types), interfaces, and value types. From the CLI perspective, all user-defined types are classes, it is manner in which they are declared in the CLI assembly that define whether they are a normal class, interface, or value type. Since all defined types in the JVM are also classes, JaCIL translates a class definition in the CLI as a JVM class definition. 35

38 Value Types as Local Variables in CLI Local Variables Local 0 Local 1 Value Types as Local Variables in JVM Translation Object Heap Heap Object Overhead Heap Object Overhead Value Type Value Type Value Type Value Type Local Variables Local 0 Local 1 Reference Reference Figure 3.1: Value type translation memory diagram for local variables Table 3.3 lists the CLI type attributes that are supported, and the JVM class attributes that they are translated to by JaCIL. CLI Attribute JVM Attribute CLI Semantic abstract ACC ABSTRACT The defined type is abstract. interface ACC INTERFACE The defined type is an interface. sealed ACC FINAL The defined type cannot be derived. public ACC PUBLIC The defined type is accessible outside of the assembly. private ACC PUBLIC The defined type is only accessible within the assembly. (see section 3.7.2) Table 3.3: Supported CLI type attributes and their JVM translations For translated types, the CLI base class (i.e. superclass) defined for a type definition is translated directly as the JVM class s superclass. The one exception to this is interface definitions. JVM interfaces must always extend java.lang.object, and CLI interfaces always extend System.Object, thus JaCIL translates such classes to conform to JVM requirements. See section 3.8 for details on translation of field definitions, and section 3.9 for details on translation of method definitions. 36

39 3.7.1 Value Type Definitions A value type is defined in the CLI as a type definition whose base class is System.ValueType. Such a type is translated directly to the JVM by JaCIL in addition to defining a public, parameterless constructor. This constructor is generated because CLI value types are not ever null (as they are allocated in place) and are always zero initialized. Thus translated code can initialize such types before user code that uses such types is executed Type Definition Translation Limitations JaCIL translates the type access modifier, private, as ACC PUBLIC in the translated JVM type. The rationale for this behavior is that the JVM has no equivalent access modifier. Besides public, a top-level class in the JVM can be declared as package protected. This is potentially too restrictive, as types in different namespaces could access each other even if declared as private; translating this scenario with package protected would not allow such types to access the other. Furthermore, besides the properties listed in table 3.3, the definition of fields, and the definition of methods, no other metadata in a type definition is translated by JaCIL. 3.8 Field Definitions All fields in a type definition are translated directly as JVM fields for that translated type. Table 3.4 lists the CLI field attributes that are supported and the JVM field attributes that they are translated to by JaCIL. When translating literal fields, JaCIL also assigns the value of that field as the initial value of the translated field Field Definition Translation Limitations JaCIL translates any field accessibility attributes that rely on assembly or compilation unit accessibility as ACC PUBLIC in the JVM. The rationale for this follows similarly to section The JVM has no accessibility level that is more course grained than package protected, so, in order to retain accessibility across namespaces, public accessibility is used in the translation. 37