Re: RFR: JDK-8203795: Change default compiler on Windows to VS2017
Hi Erik, will Oracle change the jdk-submit builds to VS2017? Most of our guys still work with VS2013, so we may miss build errors on our machines. Thanks, Thomas On Fri, May 25, 2018 at 12:26 AM, Erik Joelsson wrote: > Now that we have support for building with VS2017, it's time to change the > default compiler picked up by the configure script to VS2017. > > Oracle is also changing the version used internally, by updating > jib-profiles.js > > Webrev: http://cr.openjdk.java.net/~erikj/8203795/webrev.01/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8203795 > > /Erik >
Re: RFR(XL) : 8199383 : [TESTBUG] Open source VM testbase JVMTI tests
Hi Igor, It looks good to me. Thanks, Serguei On 5/22/18 16:35, Igor Ignatyev wrote: http://cr.openjdk.java.net/~iignatyev//8199383/webrev.00/index.html 308253 lines changed: 308253 ins; 0 del; 0 mod; Hi all, could you please review this patch which open sources JVMTI tests from VM testbase? As usually w/ VM testbase code, these tests are old, they have been run in hotspot testing for a long period of time. Originally, these tests were run by a test harness different from jtreg and had different build and execution schemes, some parts couldn't be easily translated to jtreg, so tests might have actions or pieces of code which look weird. In a long term, we are planning to rework them. webrev: http://cr.openjdk.java.net/~iignatyev//8199383/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8199383 testing: :vmTestbase_nsk_jvmti test group Thanks, -- Igor
Re: RFR: JDK-8203795: Change default compiler on Windows to VS2017
# The order of these defines the priority by which we try to find them. -VALID_VS_VERSIONS="2013 2012 2010 2015 2017" +VALID_VS_VERSIONS="2017 2015 2013 2012 2010" I think it better to have VS2013 as the 2nd option since 2015 was never an official compiler and people might have 2015 configs that are not suitable in some way but it did not matter before .. -phil On 5/24/18, 3:26 PM, Erik Joelsson wrote: Now that we have support for building with VS2017, it's time to change the default compiler picked up by the configure script to VS2017. Oracle is also changing the version used internally, by updating jib-profiles.js Webrev: http://cr.openjdk.java.net/~erikj/8203795/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8203795 /Erik
RFR: JDK-8203795: Change default compiler on Windows to VS2017
Now that we have support for building with VS2017, it's time to change the default compiler picked up by the configure script to VS2017. Oracle is also changing the version used internally, by updating jib-profiles.js Webrev: http://cr.openjdk.java.net/~erikj/8203795/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8203795 /Erik
Re: RFR: JDK-8203366 tag added wrongly in Docs.gmk
Looks good. /Erik On 2018-05-24 05:32, Magnus Ihse Bursie wrote: From the bug report: This line in Docs.gmk is incorrect, and should be removed. -tag version \ It incorrectly enables support for the @version tag, which should only be enabled by the (poorly-named) -version option. (@version and -version are a similar pair to @author and -author). A small number of java SE API files contain a very-old @version tag, and this started showing up in JavaSE docs in JDK 8. You can find these files by grepping recursively for @version. The change that added this line is probably a side-effect of adding support for the @apiNote, @implNote, @implSpec tags. Note that removing this line will change the Java SE API docs, reverting the handling of @version back to its original treatment of being ignored up through and including JDK 7. Bug: https://bugs.openjdk.java.net/browse/JDK-8203366 Patch inline: diff --git a/make/Docs.gmk b/make/Docs.gmk --- a/make/Docs.gmk +++ b/make/Docs.gmk @@ -85,7 +85,6 @@ -tag throws \ -taglet build.tools.taglet.ModuleGraph \ -tag since \ - -tag version \ -tag serialData \ -tag factory \ -tag see \ /Magnus
Re: Configure broken on MIPS when uname returns mipsel or mips64el
This looks ok to me.
/Erik
On 2018-05-23 18:08, Ao Qi wrote:
Hi Erik,
Thanks for your comments. I made a new patch:
$ hg diff
diff -r 31361382634b make/autoconf/build-aux/config.guess
--- a/make/autoconf/build-aux/config.guess Tue May 22 10:08:04 2018 -0700
+++ b/make/autoconf/build-aux/config.guess Thu May 24 09:07:17 2018 +0800
@@ -86,6 +86,17 @@
fi
fi
+# Test and fix little endian MIPS.
+if [ "x$OUT" = x ]; then
+ if [ `uname -s` = Linux ]; then
+if [ `uname -m` = mipsel ]; then
+ OUT=mipsel-unknown-linux-gnu
+elif [ `uname -m` = mips64el ]; then
+ OUT=mips64el-unknown-linux-gnu
+fi
+ fi
+fi
+
# Test and fix cpu on Macosx when C preprocessor is not on the path
echo $OUT | grep i386-apple-darwin > /dev/null 2> /dev/null
if test $? = 0; then
Cheers,
Ao Qi
2018-05-24 0:19 GMT+08:00 Erik Joelsson :
Hello Ao Qi,
Due to licensing reasons, we are unable to directly update the
autoconf-config.guess file. Instead we have the wrapper, config.guess in
which we make adjustments to the result returned by autoconf-config.guess.
Your fix needs to go in the wrapper file.
/Erik
On 2018-05-23 03:18, Ao Qi wrote:
Hi all,
I tried to configure jdk/jdk on MIPS, but I failed. The output of
configure:
...
checking for pandoc... no
checking build system type...
/home/loongson/aoqi/jdk/make/autoconf/build-aux/config.guess: unable
to guess system type
This script, last modified 2012-02-10, has failed to recognize
the operating system you are using. It is advised that you
download the most up to date version of the config scripts from
http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD
and
http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD
If the version you run
(/home/loongson/aoqi/jdk/make/autoconf/build-aux/config.guess) is
already up to date, please
send the following data and any information you think might be
pertinent to in order to provide the needed
information to handle your system.
config.guess timestamp = 2012-02-10
uname -m = mips64el
uname -r = 3.10.0-693.5.2.ns7.032.mips64el
uname -s = Linux
uname -v = #1 SMP PREEMPT Fri Dec 29 16:42:48 CST 2017
/usr/bin/uname -p = mips64el
/bin/uname -X =
hostinfo =
/bin/universe =
/usr/bin/arch -k =
/bin/arch = mips64el
/usr/bin/oslevel =
/usr/convex/getsysinfo =
UNAME_MACHINE = mips64el
UNAME_RELEASE = 3.10.0-693.5.2.ns7.032.mips64el
UNAME_SYSTEM = Linux
UNAME_VERSION = #1 SMP PREEMPT Fri Dec 29 16:42:48 CST 2017
configure: error: cannot guess build type; you must specify one
configure exiting with result code 1
...
I think the reason is that uname returns mips64el.
autoconf-config.guess can handle mips and mips64, but cannot handle
mipsel and mips64el.
I made a patch to pass the configure:
$ hg diff
diff -r 31361382634b make/autoconf/build-aux/autoconf-config.guess
--- a/make/autoconf/build-aux/autoconf-config.guess Tue May 22
10:08:04 2018 -0700
+++ b/make/autoconf/build-aux/autoconf-config.guess Wed May 23
18:06:52 2018 +0800
@@ -977,6 +977,9 @@
eval `$CC_FOR_BUILD -E $dummy.c 2>/dev/null | grep '^CPU'`
test x"${CPU}" != x && { echo "${CPU}-unknown-linux-gnu"; exit; }
;;
+mipsel:Linux:*:* | mips64el:Linux:*:*)
+ echo ${UNAME_MACHINE}-unknown-linux-gnu
+ exit ;;
or32:Linux:*:*)
echo ${UNAME_MACHINE}-unknown-linux-gnu
exit ;;
I think ppc has the same problem, but it is fixed in
make/autoconf/build-aux/config.guess.
Thanks,
Ao Qi
Re: RFR: JDK-8203366 tag added wrongly in Docs.gmk
Looks good to me. -- Jon On 5/24/18 5:32 AM, Magnus Ihse Bursie wrote: From the bug report: This line in Docs.gmk is incorrect, and should be removed. -tag version \ It incorrectly enables support for the @version tag, which should only be enabled by the (poorly-named) -version option. (@version and -version are a similar pair to @author and -author). A small number of java SE API files contain a very-old @version tag, and this started showing up in JavaSE docs in JDK 8. You can find these files by grepping recursively for @version. The change that added this line is probably a side-effect of adding support for the @apiNote, @implNote, @implSpec tags. Note that removing this line will change the Java SE API docs, reverting the handling of @version back to its original treatment of being ignored up through and including JDK 7. Bug: https://bugs.openjdk.java.net/browse/JDK-8203366 Patch inline: diff --git a/make/Docs.gmk b/make/Docs.gmk --- a/make/Docs.gmk +++ b/make/Docs.gmk @@ -85,7 +85,6 @@ -tag throws \ -taglet build.tools.taglet.ModuleGraph \ -tag since \ - -tag version \ -tag serialData \ -tag factory \ -tag see \ /Magnus
Re: RFR 8203454: Minimal, Zero builds fail after JDK-8202377 (Modularize C2 barriers)
On 05/24/2018 03:01 PM, David Holmes wrote: >> I'm not building Zero in this case but Hotspot native for linux-sparc. > > Are you building an interpreter only version of linux-sparc? No, I don't think so: MAKE_VERBOSE=y QUIETLY= LOG=debug sh ./configure --with-jvm-variants=server --with-boot-jdk=/usr/lib/jvm/java-10-openjdk-sparc64 --disable-precompiled-headers --with-debug-level=release --disable-warnings-as-errors --disable-javac-server --with-num-cores=16 > This barrier code seems highly suspect to me with regards to how it tries to > deal with C1 versus C2. I suspect at least one must be present. > > But if this is not Minimal nor Zero then it needs another bug filed :) Already done: https://bugs.openjdk.java.net/browse/JDK-8203787 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: RFR 8203454: Minimal, Zero builds fail after JDK-8202377 (Modularize C2 barriers)
On 05/24/2018 02:59 PM, John Paul Adrian Glaubitz wrote: > On 05/24/2018 02:57 PM, Aleksey Shipilev wrote: >> Oh. I am just confused you are replying to the stale review thread for >> "Minimal, Zero builds fail >> after JDK-8202377 (Modularize C2 barriers)". What you are seeing is >> something else. > > As I said, "hg blame" indicates the change which probably broke linux-sparc > here is 8202377, most likely because it was assumed SPARC needs to work > on Solaris only -.-. Yes, 8202377 might have caused more than one type of regression! This is something else. Submit the new bug for it. Let's not do this discussion in the thread for *another* bug that was already fixed. This would bite us once you would start doing mailing list archeology months later. -Aleksey
Re: RFR 8203454: Minimal, Zero builds fail after JDK-8202377 (Modularize C2 barriers)
On 24/05/2018 10:55 PM, John Paul Adrian Glaubitz wrote: On 05/24/2018 02:53 PM, Aleksey Shipilev wrote: Yeah, but this issue dealt with: /pool/buildbot/slaves/sobornost/jdkX/build/src/hotspot/share/opto/optoreg.hpp:32:39: fatal error: adfiles/adGlobals_x86.hpp: No such file or directory #include CPU_HEADER(adfiles/adGlobals) Let's not conflate the two. What you are seeing seems to be specific to Zero, and not to Minimal. I'm not building Zero in this case but Hotspot native for linux-sparc. Are you building an interpreter only version of linux-sparc? This barrier code seems highly suspect to me with regards to how it tries to deal with C1 versus C2. I suspect at least one must be present. But if this is not Minimal nor Zero then it needs another bug filed :) David Adrian
Re: RFR 8203454: Minimal, Zero builds fail after JDK-8202377 (Modularize C2 barriers)
On 05/24/2018 02:57 PM, Aleksey Shipilev wrote: > Oh. I am just confused you are replying to the stale review thread for > "Minimal, Zero builds fail > after JDK-8202377 (Modularize C2 barriers)". What you are seeing is something > else. As I said, "hg blame" indicates the change which probably broke linux-sparc here is 8202377, most likely because it was assumed SPARC needs to work on Solaris only -.-. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: RFR (round 3), JEP-318: Epsilon GC
On 05/24/2018 02:09 PM, Magnus Ihse Bursie wrote: > Please remember to include build-dev whenever you make changes to the build > system. Yeah, this was by accident: the prior webrevs had no changes in the build system, and only after GC modularization uptake some of them emerged. > Build part of your webrev looks good. Thanks! -Aleksey
Re: RFR 8203454: Minimal, Zero builds fail after JDK-8202377 (Modularize C2 barriers)
On 05/24/2018 02:55 PM, John Paul Adrian Glaubitz wrote: > On 05/24/2018 02:53 PM, Aleksey Shipilev wrote: >> Yeah, but this issue dealt with: >> >> /pool/buildbot/slaves/sobornost/jdkX/build/src/hotspot/share/opto/optoreg.hpp:32:39: >> fatal error: >> adfiles/adGlobals_x86.hpp: No such file or directory >> #include CPU_HEADER(adfiles/adGlobals) >> >> Let's not conflate the two. What you are seeing seems to be specific to >> Zero, and not to Minimal. > > I'm not building Zero in this case but Hotspot native for linux-sparc. Oh. I am just confused you are replying to the stale review thread for "Minimal, Zero builds fail after JDK-8202377 (Modularize C2 barriers)". What you are seeing is something else. -Aleksey
Re: RFR 8203454: Minimal, Zero builds fail after JDK-8202377 (Modularize C2 barriers)
On 05/24/2018 02:53 PM, Aleksey Shipilev wrote: > Yeah, but this issue dealt with: > > /pool/buildbot/slaves/sobornost/jdkX/build/src/hotspot/share/opto/optoreg.hpp:32:39: > fatal error: > adfiles/adGlobals_x86.hpp: No such file or directory > #include CPU_HEADER(adfiles/adGlobals) > > Let's not conflate the two. What you are seeing seems to be specific to Zero, > and not to Minimal. I'm not building Zero in this case but Hotspot native for linux-sparc. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: RFR 8203454: Minimal, Zero builds fail after JDK-8202377 (Modularize C2 barriers)
On 05/24/2018 02:49 PM, John Paul Adrian Glaubitz wrote: > On 05/24/2018 02:42 PM, Aleksey Shipilev wrote: >>> Does SPARC have support for C2 on Solaris so that we need to >>> add it for linux-sparc as well or is this limited to x86_64 only? >> >> You must be seeing something new, because the fix for Minimal and Zero was >> pushed to jdk/jdk >> already. Submit a bug report? > > I am seeing the same problem as yesterday (or was it the day before > yesterday?), > after running "hg pull && hg update --clean" today. And "hg blame" showed me > the regression came through JDK-8202377. > > The error remains the same: > > === Output from failing command(s) repeated here === > /usr/bin/printf "* For target > hotspot_variant-server_libjvm_objs_library_call.o:\n" > * For target hotspot_variant-server_libjvm_objs_library_call.o: > (/bin/grep -v -e "^Note: including file:" < > /srv/openjdk/jdk/build/linux-sparcv9-normal-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_library_call.o.log > || true) | /usr/bin/head -n 12 > /srv/openjdk/jdk/src/hotspot/share/opto/library_call.cpp: In member function > ‘bool LibraryCallKit::inline_native_clone(bool)’: > /srv/openjdk/jdk/src/hotspot/share/opto/library_call.cpp:4272:38: error: > incomplete type ‘BarrierSet’ used in nested name specifier >BarrierSetC2* bs = BarrierSet::barrier_set()->barrier_set_c2(); > ^~~ Yeah, but this issue dealt with: /pool/buildbot/slaves/sobornost/jdkX/build/src/hotspot/share/opto/optoreg.hpp:32:39: fatal error: adfiles/adGlobals_x86.hpp: No such file or directory #include CPU_HEADER(adfiles/adGlobals) Let's not conflate the two. What you are seeing seems to be specific to Zero, and not to Minimal. -Aleksey
Re: RFR 8203454: Minimal, Zero builds fail after JDK-8202377 (Modularize C2 barriers)
On 05/24/2018 02:42 PM, Aleksey Shipilev wrote: >> Does SPARC have support for C2 on Solaris so that we need to >> add it for linux-sparc as well or is this limited to x86_64 only? > > You must be seeing something new, because the fix for Minimal and Zero was > pushed to jdk/jdk > already. Submit a bug report? I am seeing the same problem as yesterday (or was it the day before yesterday?), after running "hg pull && hg update --clean" today. And "hg blame" showed me the regression came through JDK-8202377. The error remains the same: === Output from failing command(s) repeated here === /usr/bin/printf "* For target hotspot_variant-server_libjvm_objs_library_call.o:\n" * For target hotspot_variant-server_libjvm_objs_library_call.o: (/bin/grep -v -e "^Note: including file:" < /srv/openjdk/jdk/build/linux-sparcv9-normal-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_library_call.o.log || true) | /usr/bin/head -n 12 /srv/openjdk/jdk/src/hotspot/share/opto/library_call.cpp: In member function ‘bool LibraryCallKit::inline_native_clone(bool)’: /srv/openjdk/jdk/src/hotspot/share/opto/library_call.cpp:4272:38: error: incomplete type ‘BarrierSet’ used in nested name specifier BarrierSetC2* bs = BarrierSet::barrier_set()->barrier_set_c2(); ^~~ if test `/usr/bin/wc -l < /srv/openjdk/jdk/build/linux-sparcv9-normal-server-release/make-support/failure-logs/hotspot_variant-server_libjvm_objs_library_call.o.log` -gt 12; then /bin/echo " ... (rest of output omitted)" ; fi /usr/bin/printf "\n* All command lines available in /srv/openjdk/jdk/build/linux-sparcv9-normal-server-release/make-support/failure-logs.\n" * All command lines available in /srv/openjdk/jdk/build/linux-sparcv9-normal-server-release/make-support/failure-logs. /usr/bin/printf "=== End of repeated output ===\n" === End of repeated output === Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: RFR 8201815: Use Mozilla Public Suffix List
On 2018-05-24 06:52, Weijun Wang wrote: Good. It's now simply $(GENDATA_PUBLICSUFFIXLIST): $(GENDATA_PUBLICSUFFIXLIST_SRC) $(BUILD_TOOLS) $(call LogInfo, Generating public suffix list) $(call MakeDir, $(@D)) $(RM) $@ $(TOOL_PUBLICSUFFIXLIST) $< $@ $(CHMOD) 444 $@ Thanks Max Great! Looks good to me now. I've forgotten that we started using .DELETE_ON_ERROR. Thanks for reminding me Erik. :) /Magnus On May 24, 2018, at 12:30 AM, Erik Joelsson wrote: On 2018-05-23 03:54, Magnus Ihse Bursie wrote: mv should not modify attributes. cp will, but mv should not. Your solution might fail in the (admittedly unlikely) case that the build is interrupted before the chmod but after the mv. In that case, an incremental rebuild will not see that anything is missing. I believe the other cases that you quote are also incorrect. But I'd like to hear Erik's input on this as well. We have the pseudo target .DELETE_ON_ERROR defined globally (in MakeBase.gmk) which causes make to delete the target of any failed or interrupted recipe. This should actually remove any need for using .tmp files and mv on the last line. We still have a lot of those constructs around since forever though. The recipe copied here (and the two other examples) are based on a template from very early build-infra makefile history and do not represent current best practices. If anything I would recommend getting rid of the .tmp and mv completely, but if you prefer both belt and suspenders, putting the move last should be the correct construct. /Erik /Magnus 23 maj 2018 kl. 02:01 skrev Weijun Wang : On May 23, 2018, at 4:21 AM, Magnus Ihse Bursie wrote: ... but you should switch order on the chmod and the mv in the new gensrc file, so the mv comes last. I thought it's safer to call CHMOD last so MV won't change file mode back. (I'm not saying it will, just afraid.) In below cases, CHMOD is called after MV/CP. gendata/Gendata-java.base.gmk 59-$(MV) $@.tmp $@ 60:$(CHMOD) 444 $@ 61- common/JavaCompilation.gmk 80-$(CP) $$< $$@ 81:$(CHMOD) -f ug+w $$@ Thanks Max /Magnus 22 maj 2018 kl. 17:44 skrev Erik Joelsson : Build changes look ok. /Erik On 2018-05-22 08:25, Weijun Wang wrote: Please take a review at http://cr.openjdk.java.net/~weijun/8201815/webrev.00/ With this change, We switch from a home-grown public suffix list (implemented in sun/net/RegisteredDomain.java) to Mozilla's PSL. The PSL data was re-encoded as a zip file with entries for different TLDs. There is no plan to update the data in a different channel other than a JDK release. Thanks Max
Re: RFR 8203454: Minimal, Zero builds fail after JDK-8202377 (Modularize C2 barriers)
On 05/24/2018 02:38 PM, John Paul Adrian Glaubitz wrote: > Hi! > > On 05/19/2018 11:20 AM, Aleksey Shipilev wrote: >> Other GCs that would eventually bring their own BarrierSetC2 files (e.g. >> Epsilon, Shenandoah, ZGC) >> would require excluding their "gc//c2" as well. > > I'm seeing this bug on linux-sparc as well. > > Does SPARC have support for C2 on Solaris so that we need to > add it for linux-sparc as well or is this limited to x86_64 only? You must be seeing something new, because the fix for Minimal and Zero was pushed to jdk/jdk already. Submit a bug report? -Aleksey
Re: RFR 8203454: Minimal, Zero builds fail after JDK-8202377 (Modularize C2 barriers)
Hi! On 05/19/2018 11:20 AM, Aleksey Shipilev wrote: > Other GCs that would eventually bring their own BarrierSetC2 files (e.g. > Epsilon, Shenandoah, ZGC) > would require excluding their "gc//c2" as well. I'm seeing this bug on linux-sparc as well. Does SPARC have support for C2 on Solaris so that we need to add it for linux-sparc as well or is this limited to x86_64 only? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
RFR: JDK-8203366 tag added wrongly in Docs.gmk
From the bug report: This line in Docs.gmk is incorrect, and should be removed. -tag version \ It incorrectly enables support for the @version tag, which should only be enabled by the (poorly-named) -version option. (@version and -version are a similar pair to @author and -author). A small number of java SE API files contain a very-old @version tag, and this started showing up in JavaSE docs in JDK 8. You can find these files by grepping recursively for @version. The change that added this line is probably a side-effect of adding support for the @apiNote, @implNote, @implSpec tags. Note that removing this line will change the Java SE API docs, reverting the handling of @version back to its original treatment of being ignored up through and including JDK 7. Bug: https://bugs.openjdk.java.net/browse/JDK-8203366 Patch inline: diff --git a/make/Docs.gmk b/make/Docs.gmk --- a/make/Docs.gmk +++ b/make/Docs.gmk @@ -85,7 +85,6 @@ -tag throws \ -taglet build.tools.taglet.ModuleGraph \ -tag since \ - -tag version \ -tag serialData \ -tag factory \ -tag see \ /Magnus
Re: RFR (round 3), JEP-318: Epsilon GC
Hi Aleksey!
Please remember to include build-dev whenever you make changes to the
build system.
Build part of your webrev looks good.
/Magnus
On 2018-05-21 15:07, Aleksey Shipilev wrote:
Hi,
This is third (and hopefully final) round of code review for Epsilon GC changes.
JEP, targeted to 11:
http://openjdk.java.net/jeps/318
(you can find links to binary builds and sandbox locations there)
Webrev:
http://cr.openjdk.java.net/~shade/epsilon/webrev.07/
Notes:
*) C2 barrier modularization had landed, and now Epsilon has no
platform-specific impact (this
alone makes me impressed and happy);
*) Elastic TLAB machinery is now able to decay TLAB sizes as well, cutting
down memory footprint
on bursty allocations, more tests for it added, gating by VM options
implemented;
*) Serviceability support implemented, verified with ad-hoc hsdb session
("universe" and
"scanoops" work as expected), and serviceability/sa tests;
*) Tests are properly keyed with vm.gc.Epsilon, so they are ignored if
Epsilon is not built
Builds:
server X {x86_64, x86_32, aarch64, arm32, ppc64le, s390x}
zero X {x86_64}
minimal X {x86}
Testing: gc/epsilon on x86_64
Thanks,
-Aleksey
