Project proposal: Graal
paul.hohensee at oracle.com
Mon Jan 30 09:06:12 PST 2012
Just what I was hoping to hear. :)
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
>> 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 ;-).
>> On 1/25/12 5:03 AM, Douglas Simon wrote:
>>> In accordance with the OpenJDK guidelines , 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 .
>>> 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 .
>>> The compiler uses a clearly defined interface  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 .
>>> To ensure the broadest possible collaboration between potential contributors
>>> the project will maintain one or more code repositories derived from the
>>> OpenJDK HotSpot repository  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.
>>> Doug Simon and Thomas Wuerthinger
>>>  http://openjdk.java.net/projects/#new-project
>>>  https://wikis.oracle.com/display/MaxineVM/Home
>>>  https://wikis.oracle.com/download/attachments/4161575/vee2010.pdf
>>>  https://wikis.oracle.com/display/MaxineVM/Graal
>>>  http://jikesrvm.org/
>>>  http://hg.openjdk.java.net/hsx/hotspot-main/
More information about the discuss