> On 8 Dec 2016, at 13:50, Magnus Ihse Bursie <magnus.ihse.bur...@oracle.com> > wrote: > > On 2016-12-07 23:10, 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/ > > * In CompileJavaModules.gmk, there is an *extreme* list of excludes. I note > that most of them end in ".test". The proper solution to this is to move the > test code to the test/ directory instead of the src/ directory. Also, four of > them are the javac processor build tools. These should move to make/src, as > other build tools.
Keeping like it is simplifies pulling changes from https://github.com/graalvm/graal-core. It's possible to write a more sophisticated tool for pulling changes in from the github and places the sources into more openjdk compatible locations. It's up to the HotSpot compiler team whether investing in such a tool makes sense. > * In hotspot.m4: AC_MSG_CHECKING must always be matched by a AC_MSG_RESULT, > even before AC_MSG_ERROR, otherwise the output will be garbled. > > * In hotspot.m4: The test to determine if we should set INCLUDE_GRAAL is > incorrect. It only tests for the default value, not for the explicitely set > (i.e., HOTSPOT_CHECK_JVM_FEATURE(graal)). > > * The file hotspot/make/Tools.gmk is broken ("ifeq ($(ENABLE_AOT), true)" > will never evaluate to true). But on the other hand, it is not needed, and > should just be removed. :-) > > * The file hotspot/src/jdk.vm.compiler/share/classes/overview.html seems a > bit dangling. Is this supposed to be included in some Javadoc generation? The > html file refers to a projects.jpg and projects.html that does not exist. > Maybe it should just be removed? I would recommend omitting all graal-core overview.html files in OpenJDK. > * Finally, just for the record, I too think the source should be structured > according to the OpenJDK praxis. (But I won't fight about this.) -Doug >> >> 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 >
