Project proposal: Graal
Douglas Simon
doug.simon at oracle.com
Mon Jan 30 12:32:37 UTC 2012
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/
More information about the discuss
mailing list