Project proposal: Graal

[Paul Hohensee]

Just what I was hoping to hear. :)

Thanks,

Paul

On 1/30/12 7:32 AM, Douglas Simon wrote:
> Hi Paul,
>
> Thanks for your comments and observations. We agree that the points
> you state are indeed challenges that must be addressed by this project.
> Here's our current thinking on how we can address them.
>
> On Jan 26, 2012, at 10:59 PM, Paul Hohensee wrote:
>
>> Just to register my support, I think this is an interesting and potentially
>> quite useful line of development that would allow us to inject arbitrary
>> Java code into the Hotspot JVM.  Some problems I'd like to see solved
>> by this effort include
>>
>> 1. Startup time.  The compiler should itself be compiled before the JVM
>> starts executing in order to avoid pause time hiccups during startup
>> as the compiler compiles itself.  Some sort of ahead-of-time compilation
>> scheme is needed for Hotspot.  Such a scheme would be quite useful
>> for general application use also, particularly in an embedded context.
> We plan on leveraging our experience with the Maxine boot image process
> as much as possible to address this issue. Also, we'd obviously like to
> work with any other HotSpot engineers exploring solutions in this area.
> We are also considering whether it's possible to extends class data sharing
> (CDS) somehow to share the prebuilt Graal binaries across multiple VM
> executions.
>
>> 2. Graal-generated code quality should be quite close to that obtained from
>> C++ compilers.  For example, the transition from gcc 3 to gcc 4 for
>> compiling Hotspot on Linux significantly improved GC execution time.
> In this area, we are relying on the proven benefits of runtime and deoptimization
> to concentrate code generation on the hot spots of the compiler itself. We
> will be making closed world assumptions about (some of) the compiler which
> in turn will enable aggressive optimizations and inlining without causing code bloat.
> As of now, we are already intrinsifying some of the compiler's most important
> methods to improve compilation speed.
>
>> 3. The interface between Java land and C++ land must be efficient in
>> terms of both time and space.  Conventional JNI is far to slow.
>> Copying may (or may not) result in a significant footprint increase
>> as well as require update synchronization.
> In general, we will attempt to not duplicate VM data structures but
> access them directly from Java code. For example, Graal currently
> does not use the C++ CI interface code (used by c1 and c2).
> The current perm-gen removal project may have an adverse impact on
> this issue. However, we may also be able to directly access C++ data
> structures (we control the compiler ;-).
>
> -Doug
>
>> On 1/25/12 5:03 AM, Douglas Simon wrote:
>>> In accordance with the OpenJDK guidelines [1], we would like to start the
>>> discussion of a new project to explore implementing a dynamic compiler
>>> in Java that can be used in a native JVM such as HotSpot as well as in
>>> a meta-circular JVM such as Maxine [2].
>>>
>>> The goal of this project is to design a dynamic compiler in Java that
>>> produces excellent code quality without compromising compile time and
>>> memory usage by the JVM. The origin and starting point for this project
>>> would be the Graal compiler from the Maxine code base. This compiler is
>>> already integrated and runs in both HotSpot and Maxine. The Maxine wiki
>>> contains a brief history of its heritage [4].
>>>
>>> The compiler uses a clearly defined interface [3] for interacting with
>>> the runtime of the JVM. Furthermore, it uses features of Java that make
>>> it highly extensible such that adding extra IR nodes and/or transformations
>>> is as easy as possible.
>>>
>>> In addition to performance goals, this project aims to demonstrate the
>>> advantages of writing (some of) a JVM in Java while at the same time
>>> addressing the unique challenges such an approach entails. In this sense,
>>> Graal is a narrower application of meta-circular JVM design principles as
>>> embodied in Maxine and Jikes RVM [5].
>>>
>>> To ensure the broadest possible collaboration between potential contributors
>>> the project will maintain one or more code repositories derived from the
>>> OpenJDK HotSpot repository [6] and a developers' mailing list. The Graal
>>> code repository and developers' mailing list will be under the GPL license
>>> (GPL) version 2 with the Classpath exception and the OpenJDK Assembly Exception.
>>>
>>> Through private correspondence, we have the support and an offer of sponsorship
>>> from the lead of the HotSpot Group (Paul Hohensee). We would now like to invite
>>> anyone who supports our goal to nominate themselves as an initial supporter
>>> to be listed on the formal project proposal that will follow after the discussion.
>>>
>>> Regards,
>>>
>>> Doug Simon and Thomas Wuerthinger
>>>
>>> [1] http://openjdk.java.net/projects/#new-project
>>> [2] https://wikis.oracle.com/display/MaxineVM/Home
>>> [3] https://wikis.oracle.com/download/attachments/4161575/vee2010.pdf
>>> [4] https://wikis.oracle.com/display/MaxineVM/Graal
>>> [5] http://jikesrvm.org/
>>> [6] http://hg.openjdk.java.net/hsx/hotspot-main/