[9] RFR(XL) 8166417: Integrate Graal-core into JDK for AOT compiler

Doug Simon doug.simon at oracle.com
Thu Dec 8 09:04:51 UTC 2016

> On 8 Dec 2016, at 08:25, David Holmes <david.holmes at oracle.com> wrote:
> On 8/12/2016 9:32 AM, Vladimir Kozlov wrote:
>> jdk.vm.compiler is only one jigsaw module.
>> It is the project based layout (each directory is separate Java IDE
>> project) :
> Why does each directory need to be a separate IDE project? This naming looks awful to me.

We’ve gone through this same discussion with JVMCI.

We’ve organized the Graal (and JVMCI) source code into fine grained units of logic, each of which is a separate IDE project. The granularity of Graal modules allows downstream clients (e.g., AOT, SubstrateVM) to depend on some pieces of Graal without depending on the whole thing. Ideally, we’d like to represent each project/directory in the Graal sources as a separate JDK module but have been informed that would be too many modules. Maybe in the JDK10 timeframe we can start to refactor the Graal projects to be JDK modules. In that process, we may compromise on the granularity if there are good reasons to do so.


>> Tom Rodriguez wrote:
>>> Having the file structure follow the project structure is kind of the
>> only sane way to organize it. It's really to be Java IDE friendly.
>> Thanks,
>> Vladimir
>> On 12/7/16 3:16 PM, Coleen Phillimore wrote:
>>> Hi,
>>> Out of curiosity, why do you have this redundancy in the paths of new
>>> code files?  Is this because of modules?
>>> *src/jdk.vm.compiler/share/classes/org.graalvm.compiler.api.directives.test/src/org/graalvm/compiler/api/directives/test
>>> *
>>> Thanks,
>>> Coleen
>>> On 12/7/16 5:10 PM, Vladimir Kozlov wrote:
>>>> https://bugs.openjdk.java.net/browse/JDK-8166417
>>>> It is part of JEP 295: Ahead-of-Time Compilation
>>>> https://bugs.openjdk.java.net/browse/JDK-8166089
>>>> http://cr.openjdk.java.net/~kvn/8166417/top.webrev/
>>>> http://cr.openjdk.java.net/~kvn/8166417/jdk.webrev/
>>>> http://cr.openjdk.java.net/~kvn/8166417/hotspot.webrev/
>>>> This is formal review request for integration Graal-core sources into
>>>> OpenJDK. AOT compiler uses Graal-core as backend compiler. We need to
>>>> integrated Graal-core sources into JDK and add build changes to build
>>>> Graal module.
>>>> Note, changes are based on latest jdk9/hs sources which do not have
>>>> latest jigsaw update yet. With jigsaw update small changes will be
>>>> done to module-info.java.extra in java.base:
>>>>  exports jdk.internal.misc to jdk.vm.compiler;
>>>> + opens jdk.internal.misc to jdk.vm.compiler;
>>>> - exports com.sun.crypto.provider to jdk.vm.compiler;
>>>> + opens com.sun.crypto.provider to jdk.vm.compiler;
>>>> And changes in top make/GensrcModuleInfo.gmk will not be needed.
>>>> Graal is a dynamic compiler written in Java that integrates with the
>>>> HotSpot JVM. It has a focus on high performance and extensibility. In
>>>> addition, it provides optimized performance for Truffle based
>>>> languages running on the JVM.
>>>> https://github.com/graalvm/graal-core
>>>> Oracle Labs is developing and maintaining it.
>>>> Here are people who contributed into Graal development (sorry if
>>>> someone is missing or misspelled, please speak):
>>>> ~70k LOC: Douglas Simon
>>>> ~60k LOC: Lukas Stadler
>>>> ~30k LOC: Thomas Wuerthinger
>>>> ~30k LOC: Tom Rodriguez
>>>> ~30k LOC: Roland Schatz
>>>> ~30k LOC: Josef Eisl
>>>> ~30k LOC: Christian Wimmer
>>>> ~16k LOC: Chris Thalinger
>>>> ~13k LOC: Gilles Duboscq
>>>> ~11k LOC: David Leopoldseder
>>>> ~ 8k LOC: Stefan Anzinger
>>>> ~ 8k LOC: Christian Humer
>>>> Other contributors >100 LOC in approximate order of contribution size:
>>>> Michael Berg, Bernhard Urban, Miguel Garcia, Yudi Zheng, Christos
>>>> Kotselidis, Andreas Woess, Stefan Rumzucker, Aleksandar Prokopec,
>>>> Christian Haeubl, Morris Meyer, Matthias Grimmer, Erik Eckstein, Josef
>>>> Haider, Manuel Rigger, Michael Haupt, Niclas Adlertz, Jaroslav Tulach,
>>>> Chris Seaton, Peter B. Kessler, Christian Wirth, Benoit Daloze.
>>>> Thanks,
>>>> Vladimir

More information about the hotspot-dev mailing list