Re: Mach5 test failure when testing JDK-8237192
On 21/02/2020 6:30 am, Daniel D. Daugherty wrote: Greetings, I filed two relevant bugs when I swept the JDK15 CI this AM: JDK-8239566 gtest/GTestWrapper.java fails due to "libstlport.so.1: open failed: No such file or directory" https://bugs.openjdk.java.net/browse/JDK-8239566 JDK-8239565 sa/ClhsdbJhisto.java failed due to "assert(false) failed: unscheduable graph" https://bugs.openjdk.java.net/browse/JDK-8239565 The second bug is similar to a bug I filed earlier this week: JDK-8239367 RunThese30M.java failed due to "assert(false) failed: graph should be schedulable" https://bugs.openjdk.java.net/browse/JDK-8239367 I thought I had seen a similar failure, but I searched for unschedulable and so it failed to match. :( David - The second bug is also with a different test than is mentioned below: serviceability/sa/ClhsdbCDSJstackPrintAll.java but the assertion and the stack look like they match... Dan On 2/20/20 3:51 AM, Langer, Christoph wrote: Thanks, David for the information. As I don't see a relation from the crash to my change (I didn't touch any hotspot code at least), I guess I'm confident enough to push my patch. If worse comes to worse there's still the option to back it out again... Best regards Christoph -Original Message- From: David Holmes Sent: Donnerstag, 20. Februar 2020 09:28 To: Langer, Christoph ; 'build- d...@openjdk.java.net' ; 'hotspot- d...@openjdk.java.net' ; Erik Joelsson ; Magnus Ihse Bursie Subject: Re: Mach5 test failure when testing JDK-8237192 Hi Christoph, The Solaris failure looks like an infra issue. The test failure is a crash - info below. I don't see any open, or recently fixed, bugs for the same crash. David - # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/scratch/mesos/slaves/90726e33-be99-4e27-9d68-25dad266ef13- S3967/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd- 0196/executors/9c4085d3-922a-46c2-b44a-9835e74ddb36/runs/ecd258eb- 38e6-4966-b233- 0cdfa582f713/workspace/open/src/hotspot/share/opto/gcm.cpp:276), pid=34522, tid=43267 # assert(false) failed: unscheduable graph # # JRE version: Java(TM) SE Runtime Environment (15.0) (fastdebug build 15-internal+0-2020-02-19-1905201.christoph.langer.source) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 15-internal+0-2020-02-19-1905201.christoph.langer.source, mixed mode, sharing, tiered, compressed oops, g1 gc, bsd-amd64) # Core dump will be written. Default location: core.34522 # # If you would like to submit a bug report, please visit: # https://bugreport.java.com/bugreport/crash.jsp # --- S U M M A R Y Command Line: -Denv.class.path=/scratch/mesos/slaves/90726e33-be99-4e27-9d68- 25dad266ef13-S80/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd- 0196/executors/fb2f58a7-7e16-4340-8783-4207c1d11742/runs/3ca5d907- 2207-49d1-a673-f3617d83173d/testoutput/test- support/jtreg_open_test_hotspot_jtreg_tier1_serviceability/classes/1/servi ceability/sa/ClhsdbCDSJstackPrintAll.d:/scratch/mesos/jib- master/install/2020-02-19- 1905201.christoph.langer.source/src.full/open/test/hotspot/jtreg/serviceabil ity/sa:/scratch/mesos/slaves/90726e33-be99-4e27-9d68-25dad266ef13- S80/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd- 0196/executors/fb2f58a7-7e16-4340-8783-4207c1d11742/runs/3ca5d907- 2207-49d1-a673-f3617d83173d/testoutput/test- support/jtreg_open_test_hotspot_jtreg_tier1_serviceability/classes/1/test/ lib:/scratch/mesos/jib-master/install/2020-02-19- 1905201.christoph.langer.source/src.full/open/test/lib:/scratch/mesos/jib- master/install/java/re/jtreg/4.2/promoted/all/b16/bundles/jtreg_bin- 4.2.zip/jtreg/lib/javatest.jar:/scratch/mesos/jib- master/install/java/re/jtreg/4.2/promoted/all/b16/bundles/jtreg_bin- 4.2.zip/jtreg/lib/jtreg.jar -Dapplication.home=/scratch/mesos/jib-master/install/2020-02-19- 1905201.christoph.langer.source/macosx-x64-debug.jdk/jdk-15/fastdebug -Xms8m -Djdk.module.main=jdk.hotspot.agent jdk.hotspot.agent/sun.jvm.hotspot.SALauncher clhsdb --pid=34506 Host: scaaa915.us.oracle.com, MacPro6,1 x86_64 3700 MHz, 8 cores, 16G, Darwin 17.5.0 Time: Wed Feb 19 19:49:38 2020 GMT elapsed time: 5 seconds (0d 0h 0m 5s) --- T H R E A D --- Current thread (0x7f9158008800): JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=43267, stack(0x77ca8000,0x77da8000)] Current CompileTask: C2: 5392 726 ! 4 jdk.internal.reflect.GeneratedConstructorAccessor3::newInstance (53 bytes) Stack: [0x77ca8000,0x77da8000], sp=0x77da3b70, free space=1006k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.dylib+0xb48133] VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x6e5 V [libjvm.dylib+0xb4884f] VMError:
Re: Is anyone still building multiple JVMs?
I am just wondering, what are the practical reasons for including two libjvms in the same JDK? We had server/client VMs in the past so we can use the same JDK for running "throughput" jobs vs "desktop/interactive" jobs. But that's no longer needed with advances in tier compilation, etc. Thanks - Ioi On 2/20/20 10:33 AM, Magnus Ihse Bursie wrote: 20 feb. 2020 kl. 16:13 skrev Bob Vandette : Keep in mind that any change here will have an impact on the jlink option that allows for the selection of JVM. Jlink Plugin Name: vm Option: --vm= Description: Select the HotSpot VM in the output image. Default is all Good point. I think if we remove building of multiple JVMs in the same pass, we need to instead add an option to “import” additional JVMs. That way, the user can build the JVM in a separate configuration, so we can simplify the logic to mean one configuration == one JVM variant, and then it would still be possible to create a resulting jimage that consists of multiple JVM variants. /Magnus Bob. On Feb 20, 2020, at 10:04 AM, Magnus Ihse Bursie wrote: On 2020-02-20 12:52, Baesken, Matthias wrote: run a separate task with "configure --with-jvm-variants=minimal && make hotspot". Hello, this would , as far as I know, not produce the same result jdk image with both minimal+server libjvm in the image . So the proposed change sounds a bit like a workaround, but not a real replacement to what we have currently . Well, almost. The resulting minimal/libjvm.so would reside in a different directory, and would have to be copied into place. And the jvm.cfg file needs to be correspondingly updated. All of this is trivial for you to do in your wrapper CI scripts. Just as what Adrian does with zero. The simplicity of that solution compared to the logistical nightmare in the make files does not make a compelling case for keeping the multi-JVM support. However if you do that, you *should* get the same result. If not, then it's a bug somewhere (and that would really explain why this business of having multiple JVMs is hairy!). Give it a try! You can use the compare.sh script to verify that the resulting images are equal. The one thing you need to take care of is making sure that the set of JVM features that code outside Hotspot cares about is matching. This is one of the thing the current system is trying hard to do (and failing, mostly, in all edge cases). E.g., you need to either enable CDS on both the server and the minimal build, or disable it on both. /Magnus Best Regards, Matthias On 2020-02-19 16:59, Baesken, Matthias wrote: Hi Magnus, yes we do. We build (on Linux only currently) "--with-jvm- variants=minimal,server" in our central builds to test that minimal is still working and that is was not destroyed by recent changes . Best Regards, Matthias Is this just to test that minimal is working? If so, you could just as well run a separate task with "configure --with-jvm-variants=minimal && make hotspot". Unless you are actually shipping this configuration, that does not seem like a solid reason for keeping this functionality in the build. /Magnus
Re: Mach5 test failure when testing JDK-8237192
Greetings, I filed two relevant bugs when I swept the JDK15 CI this AM: JDK-8239566 gtest/GTestWrapper.java fails due to "libstlport.so.1: open failed: No such file or directory" https://bugs.openjdk.java.net/browse/JDK-8239566 JDK-8239565 sa/ClhsdbJhisto.java failed due to "assert(false) failed: unscheduable graph" https://bugs.openjdk.java.net/browse/JDK-8239565 The second bug is similar to a bug I filed earlier this week: JDK-8239367 RunThese30M.java failed due to "assert(false) failed: graph should be schedulable" https://bugs.openjdk.java.net/browse/JDK-8239367 The second bug is also with a different test than is mentioned below: serviceability/sa/ClhsdbCDSJstackPrintAll.java but the assertion and the stack look like they match... Dan On 2/20/20 3:51 AM, Langer, Christoph wrote: Thanks, David for the information. As I don't see a relation from the crash to my change (I didn't touch any hotspot code at least), I guess I'm confident enough to push my patch. If worse comes to worse there's still the option to back it out again... Best regards Christoph -Original Message- From: David Holmes Sent: Donnerstag, 20. Februar 2020 09:28 To: Langer, Christoph ; 'build- d...@openjdk.java.net' ; 'hotspot- d...@openjdk.java.net' ; Erik Joelsson ; Magnus Ihse Bursie Subject: Re: Mach5 test failure when testing JDK-8237192 Hi Christoph, The Solaris failure looks like an infra issue. The test failure is a crash - info below. I don't see any open, or recently fixed, bugs for the same crash. David - # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/scratch/mesos/slaves/90726e33-be99-4e27-9d68-25dad266ef13- S3967/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd- 0196/executors/9c4085d3-922a-46c2-b44a-9835e74ddb36/runs/ecd258eb- 38e6-4966-b233- 0cdfa582f713/workspace/open/src/hotspot/share/opto/gcm.cpp:276), pid=34522, tid=43267 # assert(false) failed: unscheduable graph # # JRE version: Java(TM) SE Runtime Environment (15.0) (fastdebug build 15-internal+0-2020-02-19-1905201.christoph.langer.source) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 15-internal+0-2020-02-19-1905201.christoph.langer.source, mixed mode, sharing, tiered, compressed oops, g1 gc, bsd-amd64) # Core dump will be written. Default location: core.34522 # # If you would like to submit a bug report, please visit: # https://bugreport.java.com/bugreport/crash.jsp # --- S U M M A R Y Command Line: -Denv.class.path=/scratch/mesos/slaves/90726e33-be99-4e27-9d68- 25dad266ef13-S80/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd- 0196/executors/fb2f58a7-7e16-4340-8783-4207c1d11742/runs/3ca5d907- 2207-49d1-a673-f3617d83173d/testoutput/test- support/jtreg_open_test_hotspot_jtreg_tier1_serviceability/classes/1/servi ceability/sa/ClhsdbCDSJstackPrintAll.d:/scratch/mesos/jib- master/install/2020-02-19- 1905201.christoph.langer.source/src.full/open/test/hotspot/jtreg/serviceabil ity/sa:/scratch/mesos/slaves/90726e33-be99-4e27-9d68-25dad266ef13- S80/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd- 0196/executors/fb2f58a7-7e16-4340-8783-4207c1d11742/runs/3ca5d907- 2207-49d1-a673-f3617d83173d/testoutput/test- support/jtreg_open_test_hotspot_jtreg_tier1_serviceability/classes/1/test/ lib:/scratch/mesos/jib-master/install/2020-02-19- 1905201.christoph.langer.source/src.full/open/test/lib:/scratch/mesos/jib- master/install/java/re/jtreg/4.2/promoted/all/b16/bundles/jtreg_bin- 4.2.zip/jtreg/lib/javatest.jar:/scratch/mesos/jib- master/install/java/re/jtreg/4.2/promoted/all/b16/bundles/jtreg_bin- 4.2.zip/jtreg/lib/jtreg.jar -Dapplication.home=/scratch/mesos/jib-master/install/2020-02-19- 1905201.christoph.langer.source/macosx-x64-debug.jdk/jdk-15/fastdebug -Xms8m -Djdk.module.main=jdk.hotspot.agent jdk.hotspot.agent/sun.jvm.hotspot.SALauncher clhsdb --pid=34506 Host: scaaa915.us.oracle.com, MacPro6,1 x86_64 3700 MHz, 8 cores, 16G, Darwin 17.5.0 Time: Wed Feb 19 19:49:38 2020 GMT elapsed time: 5 seconds (0d 0h 0m 5s) --- T H R E A D --- Current thread (0x7f9158008800): JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=43267, stack(0x77ca8000,0x77da8000)] Current CompileTask: C2: 5392 726 ! 4 jdk.internal.reflect.GeneratedConstructorAccessor3::newInstance (53 bytes) Stack: [0x77ca8000,0x77da8000], sp=0x77da3b70, free space=1006k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.dylib+0xb48133] VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x6e5 V [libjvm.dylib+0xb4884f] VMError::report_and_die(Thread*, void*, char const*, int, char const*, char const*, __va_list_tag*)+0x47 V [libjvm.dylib+0x338454] report_vm_error(char const*, int, char const*, char const*, ...)+0x145
Re: Is anyone still building multiple JVMs?
> 20 feb. 2020 kl. 16:13 skrev Bob Vandette : > > Keep in mind that any change here will have an impact on the jlink option > that allows for the > selection of JVM. > > Jlink Plugin Name: vm > Option: --vm= > Description: Select the HotSpot VM in the output image. Default is all Good point. I think if we remove building of multiple JVMs in the same pass, we need to instead add an option to “import” additional JVMs. That way, the user can build the JVM in a separate configuration, so we can simplify the logic to mean one configuration == one JVM variant, and then it would still be possible to create a resulting jimage that consists of multiple JVM variants. /Magnus > > Bob. > > >> On Feb 20, 2020, at 10:04 AM, Magnus Ihse Bursie >> wrote: >> >> On 2020-02-20 12:52, Baesken, Matthias wrote: run a separate task with "configure --with-jvm-variants=minimal && make hotspot". >>> Hello, this would , as far as I know, not produce the same result jdk >>> image with both minimal+server libjvm in the image . >>> So the proposed change sounds a bit like a workaround, but not a real >>> replacement to what we have currently . >> >> Well, almost. The resulting minimal/libjvm.so would reside in a different >> directory, and would have to be copied into place. And the jvm.cfg file >> needs to be correspondingly updated. All of this is trivial for you to do in >> your wrapper CI scripts. Just as what Adrian does with zero. The simplicity >> of that solution compared to the logistical nightmare in the make files does >> not make a compelling case for keeping the multi-JVM support. >> >> However if you do that, you *should* get the same result. If not, then it's >> a bug somewhere (and that would really explain why this business of having >> multiple JVMs is hairy!). Give it a try! You can use the compare.sh script >> to verify that the resulting images are equal. >> >> The one thing you need to take care of is making sure that the set of JVM >> features that code outside Hotspot cares about is matching. This is one of >> the thing the current system is trying hard to do (and failing, mostly, in >> all edge cases). E.g., you need to either enable CDS on both the server and >> the minimal build, or disable it on both. >> >> /Magnus >>> >>> Best Regards, Matthias >>> >>> > On 2020-02-19 16:59, Baesken, Matthias wrote: > Hi Magnus, yes we do. We build (on Linux only currently) "--with-jvm- variants=minimal,server" in our central builds to test that minimal is still working and that is was not destroyed by recent changes . > Best Regards, Matthias Is this just to test that minimal is working? If so, you could just as well run a separate task with "configure --with-jvm-variants=minimal && make hotspot". Unless you are actually shipping this configuration, that does not seem like a solid reason for keeping this functionality in the build. /Magnus >> >
Re: RFR: JDK-8239450 Overhaul JVM feature handling in configure
Hello,
On 2020-02-20 01:05, Magnus Ihse Bursie wrote:
On 2020-02-19 16:00, Erik Joelsson wrote:
Hello Magnus,
This is certainly a nice improvement.
Thanks! It's been long overdue...
It looks good to me. I have some comments on implementation details,
but nothing serious enough to require a new webrev.
Instead of using "echo $foo | sed 's/,/ /g'", since we know we run in
bash, could just use ${foo//,/ }. (jvm-features.m4:82)
Good point. I just copied this from the old code.
The $AWK expressions are just copied from the previous
implementation, so they are probably working ok. I would still
recommend using $NAWK to increase likelihood of them really working
the same across platforms.
Hm, well, here's the thing. (I had to really check this up.) We set up
the following definitions:
BASIC_REQUIRE_PROGS(NAWK, [nawk gawk awk])
BASIC_REQUIRE_SPECIAL(AWK, [AC_PROG_AWK])
and AC_PROG_AWK, according to the documentation, "[c]heck for gawk,
mawk, nawk, and awk, in that order".
So, if you have nawk and awk (but no other) installed, both NAWK and
AWK will be set to nawk. If you have only awk, both will be set to
awk. The difference is if you have gawk installed, then NAWK will be
nawk and AWK will be gawk. On my mac, I only have awk, so both AWK and
NAWK will be awk. Which works fine with these expressions.
On my ubuntu box, things are even more confused. I have:
$ ls -l /usr/bin/*awk
lrwxrwxrwx 1 root root 21 Feb 6 10:36 awk -> /etc/alternatives/awk*
-rwxr-xr-x 1 root root 658072 Feb 11 2018 gawk*
-rwxr-xr-x 1 root root 3189 Feb 11 2018 igawk*
-rwxr-xr-x 1 root root 125416 Apr 3 2018 mawk*
lrwxrwxrwx 1 root root 22 Feb 6 10:37 nawk ->
/etc/alternatives/nawk*
$ ls -l /etc/alternatives/*awk
lrwxrwxrwx 1 root root 13 Feb 10 10:56 /etc/alternatives/awk ->
/usr/bin/gawk*
lrwxrwxrwx 1 root root 13 Feb 10 10:56 /etc/alternatives/nawk ->
/usr/bin/gawk*
So awk, nawk and gawk all executes the same binary, i.e. gawk. Only
mawk is different. So on that machine, AWK would be gawk and NAWK
would be nawk, but both will execute gawk.
I propose that we remove NAWK, and only use AWK, but we should stop
using AC_PROG_AWK and define it in an order that is transparent to us.
I recommend [gawk nawk awk], since on Linux systems nawk (as we've
seen) is likely to be gawk under disguise anyway, so it's better to be
clear about that.
Also, if we truly believe the flavor of awk we're using is having any
significance, we should test what version we've actually found, and
then either require a specific flavor, and/or test our awk scripts on
different awks. But that is better left for another time. For now,
I'll keep the AWK. :-)
I think the only platform where I've seen it matter is Solaris, but if
our $AWK is resolved in that order, it doesn't matter. Disregard my comment!
/Erik
jvm-features.m4:370,372-373: wrong indentation
Good catch!
/Magnus
/Erik
On 2020-02-19 04:05, Magnus Ihse Bursie wrote:
The JVM feature handling in configure needs a complete overhaul. The
current logic is hard to understand and to make changes to. The
method of enabling features with --with-jvm-features="feature list"
means that it is not possible to incrementally add features without
throwing away settings done earlier on the command line.
With this patch, the most noticeable effect for normal users is the
addition of a group of configure arguments, on the pattern
--enable-jvm-feature-. So, instead of doing e.g.
--with-jvm-features="zgc,-dtrace", you can now do
--enable-jvm-feature-zgc --disable-jvm-feature-dtrace. The major
benefit from this is that it is possible to build up a command line
in steps, where a later step enables or disables a feature, without
throwing away the settings made earlier (which was what happened if
two --with-jvm-features= options were given).
Arguably, this is the way that JVM features should have been
implemented all along. There were ever only two reasons for the
--with-jvm-features argument list, neither of them particularly
good: It allows for simple selection of multiple features (e.g. for
the custom variant), and it avoided the complexity in
programmatically generating autoconf options in m4.
I have now bit the bullet, and wrangled m4 into doing this. The old
way of --with-jvm-features="" is of course still supported,
but I think for the most part, the new style is recommended. Some
features, e.g. cds, had their own options (--enable-cds) which were
weirdly translated into features. These options are now defined as
aliases (of e.g. --enable-jvm-feature-cds), and I intend to keep
them as such.
Under the hood, much more has changed. There is no longer the
schizophrenic split between handling stuff the "old" way or the
"new" way using features. All features are handled the same, period.
Furthermore, the logic has been cleared up considerably.
First of all, I check if a feature is possible to build on your
platform. For instance,
Re: Is anyone still building multiple JVMs?
Keep in mind that any change here will have an impact on the jlink option that allows for the selection of JVM. Jlink Plugin Name: vm Option: --vm= Description: Select the HotSpot VM in the output image. Default is all Bob. > On Feb 20, 2020, at 10:04 AM, Magnus Ihse Bursie > wrote: > > On 2020-02-20 12:52, Baesken, Matthias wrote: >>> run a separate task with "configure --with-jvm-variants=minimal && >>> make hotspot". >> Hello, this would , as far as I know, not produce the same result jdk >> image with both minimal+server libjvm in the image . >> So the proposed change sounds a bit like a workaround, but not a real >> replacement to what we have currently . > > Well, almost. The resulting minimal/libjvm.so would reside in a different > directory, and would have to be copied into place. And the jvm.cfg file needs > to be correspondingly updated. All of this is trivial for you to do in your > wrapper CI scripts. Just as what Adrian does with zero. The simplicity of > that solution compared to the logistical nightmare in the make files does not > make a compelling case for keeping the multi-JVM support. > > However if you do that, you *should* get the same result. If not, then it's a > bug somewhere (and that would really explain why this business of having > multiple JVMs is hairy!). Give it a try! You can use the compare.sh script to > verify that the resulting images are equal. > > The one thing you need to take care of is making sure that the set of JVM > features that code outside Hotspot cares about is matching. This is one of > the thing the current system is trying hard to do (and failing, mostly, in > all edge cases). E.g., you need to either enable CDS on both the server and > the minimal build, or disable it on both. > > /Magnus >> >> Best Regards, Matthias >> >> >>> On 2020-02-19 16:59, Baesken, Matthias wrote: Hi Magnus, yes we do. We build (on Linux only currently) "--with-jvm- >>> variants=minimal,server" in our central builds to test that minimal is >>> still >>> working and that is was not destroyed by recent changes . Best Regards, Matthias >>> Is this just to test that minimal is working? If so, you could just as >>> well run a separate task with "configure --with-jvm-variants=minimal && >>> make hotspot". Unless you are actually shipping this configuration, that >>> does not seem like a solid reason for keeping this functionality in the >>> build. >>> >>> /Magnus >
Re: Is anyone still building multiple JVMs?
On 2020-02-20 12:52, Baesken, Matthias wrote: run a separate task with "configure --with-jvm-variants=minimal && make hotspot". Hello, this would , as far as I know, not produce the same result jdk image with both minimal+server libjvm in the image . So the proposed change sounds a bit like a workaround, but not a real replacement to what we have currently . Well, almost. The resulting minimal/libjvm.so would reside in a different directory, and would have to be copied into place. And the jvm.cfg file needs to be correspondingly updated. All of this is trivial for you to do in your wrapper CI scripts. Just as what Adrian does with zero. The simplicity of that solution compared to the logistical nightmare in the make files does not make a compelling case for keeping the multi-JVM support. However if you do that, you *should* get the same result. If not, then it's a bug somewhere (and that would really explain why this business of having multiple JVMs is hairy!). Give it a try! You can use the compare.sh script to verify that the resulting images are equal. The one thing you need to take care of is making sure that the set of JVM features that code outside Hotspot cares about is matching. This is one of the thing the current system is trying hard to do (and failing, mostly, in all edge cases). E.g., you need to either enable CDS on both the server and the minimal build, or disable it on both. /Magnus Best Regards, Matthias On 2020-02-19 16:59, Baesken, Matthias wrote: Hi Magnus, yes we do. We build (on Linux only currently) "--with-jvm- variants=minimal,server" in our central builds to test that minimal is still working and that is was not destroyed by recent changes . Best Regards, Matthias Is this just to test that minimal is working? If so, you could just as well run a separate task with "configure --with-jvm-variants=minimal && make hotspot". Unless you are actually shipping this configuration, that does not seem like a solid reason for keeping this functionality in the build. /Magnus
RE: Is anyone still building multiple JVMs?
> run a separate task with "configure --with-jvm-variants=minimal && > make hotspot". Hello, this would , as far as I know, not produce the same result jdk image with both minimal+server libjvm in the image . So the proposed change sounds a bit like a workaround, but not a real replacement to what we have currently . Best Regards, Matthias > > On 2020-02-19 16:59, Baesken, Matthias wrote: > > Hi Magnus, yes we do. We build (on Linux only currently) "--with-jvm- > variants=minimal,server" in our central builds to test that minimal is > still > working and that is was not destroyed by recent changes . > > > > Best Regards, Matthias > Is this just to test that minimal is working? If so, you could just as > well run a separate task with "configure --with-jvm-variants=minimal && > make hotspot". Unless you are actually shipping this configuration, that > does not seem like a solid reason for keeping this functionality in the > build. > > /Magnus
Re: Is anyone still building multiple JVMs?
On 2020-02-19 16:59, Baesken, Matthias wrote: Hi Magnus, yes we do. We build (on Linux only currently) "--with-jvm-variants=minimal,server" in our central builds to test that minimal is still working and that is was not destroyed by recent changes . Best Regards, Matthias Is this just to test that minimal is working? If so, you could just as well run a separate task with "configure --with-jvm-variants=minimal && make hotspot". Unless you are actually shipping this configuration, that does not seem like a solid reason for keeping this functionality in the build. /Magnus Message: 2 Date: Wed, 19 Feb 2020 13:26:35 +0100 From: Magnus Ihse Bursie To: build-dev@openjdk.java.net Subject: Is anyone still building multiple JVMs? Message-ID: <3916a515-d67f-4f20-b149-a50408e13...@oracle.com> Content-Type: text/plain; charset=utf-8 Are there still any realistic scenarios where anyone builds multiple variants of Hotspot in the same configuration? This was basically introduced for 32-bit builds, where both the server and the client variant of Hotspot were built. In Oracle at least, we stopped building multiple JVM variants a long time ago. Since the build system is taxed with convoluted logic in places just to support this, I?d prefer to remove it if it is not used anymore. So, is there anyone out there, still doing this? /Magnus
RE: RFR: 8201429: Support AIX Input Method Editor (IME) for AWT Input Method Framework (IMF)
Hi Sergey, from what I can see your proposed changes seem to make sense, given that XSetForeground and XSetBackground do their job. The change itself comes from Ichiroh-san, I only helped to review/sponsor it at the time and ran a few tests in our infrastructure. I suggest you prepare a patch and we run it through our testing to see whether it builds or causes regressions on AIX. However, as for the IME/IMF context, I really would like to see Ichiroh verify it, since he's got an environment where he can test the graphics stuff on AIX and is knowledgeable about IMs needed for e.g. Japanese. Cheers Christoph > -Original Message- > From: Ichiroh Takiguchi > Sent: Donnerstag, 20. Februar 2020 10:57 > To: Sergey Bylokhov > Cc: Langer, Christoph ; Philip Race > ; awt-...@openjdk.java.net; build- > d...@openjdk.java.net; ppc-aix-port-...@openjdk.java.net > Subject: Re: RFR: 8201429: Support AIX Input Method Editor > (IME) for AWT Input Method Framework (IMF) > > Hello Sergey. > > I'm not sure if I understand what you want to change... > > XCreateGC: > The colors are created upper code, they will be overwritten. > > XSetBackground: > I'm sorry, I have no idea about XSetBackground(), > I thought background might have default value, But I could not find out > the doc. > > Ichiroh Takiguchi > IBM Japan, Ltd. > > On 2020-02-20 14:10, Sergey Bylokhov wrote: > > Hello, Christoph. > > > > Could you shed some light on the changes below: > > > > -statusWindow->fgGC = XCreateGC(dpy, status, valuemask, &values); > > +statusWindow->fgGC = create_gc(status, FALSE); > > XSetForeground(dpy, statusWindow->fgGC, fg); > > -statusWindow->bgGC = XCreateGC(dpy, status, valuemask, &values); > > +statusWindow->bgGC = create_gc(status, TRUE); > > XSetForeground(dpy, statusWindow->bgGC, bg); > > > > The new method create_gc() is used to set the FG and BG color of the > > GC. > > But foreground color immediately replaced by the XSetForeground. > > I am asking because the create_gc() uses > > AwtScreenDataPtr.whitepixel/blackpixel > > which I would like to delete. I guess it should be possible rewrite > > this code like this: > > > > statusWindow->fgGC = XCreateGC(dpy, status, valuemask, &values); > > XSetForeground(dpy, statusWindow->fgGC, fg); > > XSetBackground(dpy, statusWindow->fgGC, bg); > > statusWindow->bgGC = XCreateGC(dpy, status, valuemask, &values); > > XSetForeground(dpy, statusWindow->bgGC, bg); > > XSetBackground(dpy, statusWindow->bgGC, fg); > > > > What do you think? > > > > On 5/28/18 5:38 am, Langer, Christoph wrote: > >> Hi Phil, > >> > >> thanks for your review. I have incorporated your suggestions: > >> http://cr.openjdk.java.net/~clanger/webrevs/8201429.3/ > >> > >> I'll run it through our internal testing and run a jdk-submit job with > >> it. When all is green, I'll push it to jdk-client tomorrow. > >> > >> Best regards > >> Christoph > >> > >>> -Original Message- > >>> From: Philip Race [mailto:philip.r...@oracle.com] > >>> Sent: Sonntag, 20. Mai 2018 01:53 > >>> To: Langer, Christoph > >>> Cc: awt-...@openjdk.java.net; Ichiroh Takiguchi > >>> ; build-dev@openjdk.java.net; > >>> ppc-aix-port- > >>> d...@openjdk.java.net > >>> Subject: Re: RFR: 8201429: Support AIX Input Method Editor > >>> (IME) for AWT Input Method Framework (IMF) > >>> > >>> I think I am 99% OK with this. > >>> > >>> In general I see what you are doing here and how you've presented the > >>> webrev. > >>> Treating even the new files as moved helps see the differences but it > >>> is > >>> still > >>> a challenge to follow all the moving pieces. > >>> > >>> So before we had just > >>> > >>> abstract class unix/X11InputMethod <-class > >>> unix/XInputMethod > >>> > >>> Now we have > >>> > >>> abstract class unix/X11InputMethodBase > >>> > >>> /\ > >>> > >>> / \ > >>> > >>> / \ > >>> > >>>/\ > >>> > >>> abstract class unix/X11InputMethodabstract class > >>> aix/X11InputMethod > >>> > >>> \/ > >>> \ / > >>> \/ > >>> class unix/XInputMethod > >>> > >>> > >>> > >>> I have submitted a build job with this patch to make sure it all > >>> builds > >>> on Linux & Solaris .. > >>> and it was all fine. > >>> > >>> But testing for this would have to be manual, and I don't have cycles > >>> for that. > >>> So I'll have to accept that the testing done by IBM was enough > >>> > >>> So only minor comments ... > >>> > http://cr.openjdk.java.net/~clanger/webrevs/8201429.2/src/java.desktop/u > >>> nix/classes/sun/awt/X11InputMethodBase.j
Re: RFR: 8201429: Support AIX Input Method Editor (IME) for AWT Input Method Framework (IMF)
Hello Sergey. I'm not sure if I understand what you want to change... XCreateGC: The colors are created upper code, they will be overwritten. XSetBackground: I'm sorry, I have no idea about XSetBackground(), I thought background might have default value, But I could not find out the doc. Ichiroh Takiguchi IBM Japan, Ltd. On 2020-02-20 14:10, Sergey Bylokhov wrote: Hello, Christoph. Could you shed some light on the changes below: -statusWindow->fgGC = XCreateGC(dpy, status, valuemask, &values); +statusWindow->fgGC = create_gc(status, FALSE); XSetForeground(dpy, statusWindow->fgGC, fg); -statusWindow->bgGC = XCreateGC(dpy, status, valuemask, &values); +statusWindow->bgGC = create_gc(status, TRUE); XSetForeground(dpy, statusWindow->bgGC, bg); The new method create_gc() is used to set the FG and BG color of the GC. But foreground color immediately replaced by the XSetForeground. I am asking because the create_gc() uses AwtScreenDataPtr.whitepixel/blackpixel which I would like to delete. I guess it should be possible rewrite this code like this: statusWindow->fgGC = XCreateGC(dpy, status, valuemask, &values); XSetForeground(dpy, statusWindow->fgGC, fg); XSetBackground(dpy, statusWindow->fgGC, bg); statusWindow->bgGC = XCreateGC(dpy, status, valuemask, &values); XSetForeground(dpy, statusWindow->bgGC, bg); XSetBackground(dpy, statusWindow->bgGC, fg); What do you think? On 5/28/18 5:38 am, Langer, Christoph wrote: Hi Phil, thanks for your review. I have incorporated your suggestions: http://cr.openjdk.java.net/~clanger/webrevs/8201429.3/ I'll run it through our internal testing and run a jdk-submit job with it. When all is green, I'll push it to jdk-client tomorrow. Best regards Christoph -Original Message- From: Philip Race [mailto:philip.r...@oracle.com] Sent: Sonntag, 20. Mai 2018 01:53 To: Langer, Christoph Cc: awt-...@openjdk.java.net; Ichiroh Takiguchi ; build-dev@openjdk.java.net; ppc-aix-port- d...@openjdk.java.net Subject: Re: RFR: 8201429: Support AIX Input Method Editor (IME) for AWT Input Method Framework (IMF) I think I am 99% OK with this. In general I see what you are doing here and how you've presented the webrev. Treating even the new files as moved helps see the differences but it is still a challenge to follow all the moving pieces. So before we had just abstract class unix/X11InputMethod <-class unix/XInputMethod Now we have abstract class unix/X11InputMethodBase /\ / \ / \ /\ abstract class unix/X11InputMethodabstract class aix/X11InputMethod \/ \ / \/ class unix/XInputMethod I have submitted a build job with this patch to make sure it all builds on Linux & Solaris .. and it was all fine. But testing for this would have to be manual, and I don't have cycles for that. So I'll have to accept that the testing done by IBM was enough So only minor comments ... http://cr.openjdk.java.net/~clanger/webrevs/8201429.2/src/java.desktop/u nix/classes/sun/awt/X11InputMethodBase.java.sdiff.html 730 case 0: //None of the value is set by Wnn "value is " -> "values are " ? http://cr.openjdk.java.net/~clanger/webrevs/8201429.2/src/java.desktop/u nix/native/libawt_xawt/awt/awt_InputMethod.c.sdiff.html why did you move 26 #ifdef HEADLESS 27 #error This file should not be included in headless library 28 #endif I think it should be first. It is also missing from the equivalent AIX file but that is up to you .. I really didn't look any further at the AIX files. .. and there seems no point to moving around some of the other includes except to make the webrev harder to read :-) But good job cleaning up a lot of the formatting of the native code. -phil. On 5/18/18, 4:59 AM, Langer, Christoph wrote: Hi all, Here is an updated webrev: http://cr.openjdk.java.net/~clanger/webrevs/8201429.2/ Can someone from the graphics/awt team please have a look at that change? Especially checking that we don't break non-AIX platforms? Thanks in advance. @Ichiroh: Thanks for your review and tests. Adressing your points: resetCompositionState() was missing in src/java.desktop/aix/classes/sun/awt/X11InputMethod.java == == --- a/src/java.desktop/aix/classes/sun/awt/X11InputMethod.java Wed May 09 09:05:32 2018 +0900 +++ b/src/java.desktop/aix/classes/sun/awt/X11InputMethod.java Mon May 14 21:25:50 2018 +0900 @@ -56,6 +56,21 @@ } /** + * Reset the
Re: RFR: JDK-8239450 Overhaul JVM feature handling in configure
On 2020-02-19 16:00, Erik Joelsson wrote:
Hello Magnus,
This is certainly a nice improvement.
Thanks! It's been long overdue...
It looks good to me. I have some comments on implementation details,
but nothing serious enough to require a new webrev.
Instead of using "echo $foo | sed 's/,/ /g'", since we know we run in
bash, could just use ${foo//,/ }. (jvm-features.m4:82)
Good point. I just copied this from the old code.
The $AWK expressions are just copied from the previous implementation,
so they are probably working ok. I would still recommend using $NAWK
to increase likelihood of them really working the same across platforms.
Hm, well, here's the thing. (I had to really check this up.) We set up
the following definitions:
BASIC_REQUIRE_PROGS(NAWK, [nawk gawk awk])
BASIC_REQUIRE_SPECIAL(AWK, [AC_PROG_AWK])
and AC_PROG_AWK, according to the documentation, "[c]heck for gawk,
mawk, nawk, and awk, in that order".
So, if you have nawk and awk (but no other) installed, both NAWK and AWK
will be set to nawk. If you have only awk, both will be set to awk. The
difference is if you have gawk installed, then NAWK will be nawk and AWK
will be gawk. On my mac, I only have awk, so both AWK and NAWK will be
awk. Which works fine with these expressions.
On my ubuntu box, things are even more confused. I have:
$ ls -l /usr/bin/*awk
lrwxrwxrwx 1 root root 21 Feb 6 10:36 awk -> /etc/alternatives/awk*
-rwxr-xr-x 1 root root 658072 Feb 11 2018 gawk*
-rwxr-xr-x 1 root root 3189 Feb 11 2018 igawk*
-rwxr-xr-x 1 root root 125416 Apr 3 2018 mawk*
lrwxrwxrwx 1 root root 22 Feb 6 10:37 nawk -> /etc/alternatives/nawk*
$ ls -l /etc/alternatives/*awk
lrwxrwxrwx 1 root root 13 Feb 10 10:56 /etc/alternatives/awk ->
/usr/bin/gawk*
lrwxrwxrwx 1 root root 13 Feb 10 10:56 /etc/alternatives/nawk ->
/usr/bin/gawk*
So awk, nawk and gawk all executes the same binary, i.e. gawk. Only mawk
is different. So on that machine, AWK would be gawk and NAWK would be
nawk, but both will execute gawk.
I propose that we remove NAWK, and only use AWK, but we should stop
using AC_PROG_AWK and define it in an order that is transparent to us. I
recommend [gawk nawk awk], since on Linux systems nawk (as we've seen)
is likely to be gawk under disguise anyway, so it's better to be clear
about that.
Also, if we truly believe the flavor of awk we're using is having any
significance, we should test what version we've actually found, and then
either require a specific flavor, and/or test our awk scripts on
different awks. But that is better left for another time. For now, I'll
keep the AWK. :-)
jvm-features.m4:370,372-373: wrong indentation
Good catch!
/Magnus
/Erik
On 2020-02-19 04:05, Magnus Ihse Bursie wrote:
The JVM feature handling in configure needs a complete overhaul. The
current logic is hard to understand and to make changes to. The
method of enabling features with --with-jvm-features="feature list"
means that it is not possible to incrementally add features without
throwing away settings done earlier on the command line.
With this patch, the most noticeable effect for normal users is the
addition of a group of configure arguments, on the pattern
--enable-jvm-feature-. So, instead of doing e.g.
--with-jvm-features="zgc,-dtrace", you can now do
--enable-jvm-feature-zgc --disable-jvm-feature-dtrace. The major
benefit from this is that it is possible to build up a command line
in steps, where a later step enables or disables a feature, without
throwing away the settings made earlier (which was what happened if
two --with-jvm-features= options were given).
Arguably, this is the way that JVM features should have been
implemented all along. There were ever only two reasons for the
--with-jvm-features argument list, neither of them particularly good:
It allows for simple selection of multiple features (e.g. for the
custom variant), and it avoided the complexity in programmatically
generating autoconf options in m4.
I have now bit the bullet, and wrangled m4 into doing this. The old
way of --with-jvm-features="" is of course still supported, but
I think for the most part, the new style is recommended. Some
features, e.g. cds, had their own options (--enable-cds) which were
weirdly translated into features. These options are now defined as
aliases (of e.g. --enable-jvm-feature-cds), and I intend to keep them
as such.
Under the hood, much more has changed. There is no longer the
schizophrenic split between handling stuff the "old" way or the "new"
way using features. All features are handled the same, period.
Furthermore, the logic has been cleared up considerably.
First of all, I check if a feature is possible to build on your
platform. For instance, CDS is not available on AIX, or dtrace
requires proper tooling. If that is the case, it is considered
unavailable, and it is an error to try to enable it.
This check is also done on a per-variant basis. Some feat
RE: Mach5 test failure when testing JDK-8237192
Thanks, David for the information. As I don't see a relation from the crash to my change (I didn't touch any hotspot code at least), I guess I'm confident enough to push my patch. If worse comes to worse there's still the option to back it out again... Best regards Christoph > -Original Message- > From: David Holmes > Sent: Donnerstag, 20. Februar 2020 09:28 > To: Langer, Christoph ; 'build- > d...@openjdk.java.net' ; 'hotspot- > d...@openjdk.java.net' ; Erik Joelsson > ; Magnus Ihse Bursie > > Subject: Re: Mach5 test failure when testing JDK-8237192 > > Hi Christoph, > > The Solaris failure looks like an infra issue. > > The test failure is a crash - info below. I don't see any open, or > recently fixed, bugs for the same crash. > > David > - > > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error > (/scratch/mesos/slaves/90726e33-be99-4e27-9d68-25dad266ef13- > S3967/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd- > 0196/executors/9c4085d3-922a-46c2-b44a-9835e74ddb36/runs/ecd258eb- > 38e6-4966-b233- > 0cdfa582f713/workspace/open/src/hotspot/share/opto/gcm.cpp:276), > pid=34522, tid=43267 > # assert(false) failed: unscheduable graph > # > # JRE version: Java(TM) SE Runtime Environment (15.0) (fastdebug build > 15-internal+0-2020-02-19-1905201.christoph.langer.source) > # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug > 15-internal+0-2020-02-19-1905201.christoph.langer.source, mixed mode, > sharing, tiered, compressed oops, g1 gc, bsd-amd64) > # Core dump will be written. Default location: core.34522 > # > # If you would like to submit a bug report, please visit: > # https://bugreport.java.com/bugreport/crash.jsp > # > > --- S U M M A R Y > > Command Line: > -Denv.class.path=/scratch/mesos/slaves/90726e33-be99-4e27-9d68- > 25dad266ef13-S80/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd- > 0196/executors/fb2f58a7-7e16-4340-8783-4207c1d11742/runs/3ca5d907- > 2207-49d1-a673-f3617d83173d/testoutput/test- > support/jtreg_open_test_hotspot_jtreg_tier1_serviceability/classes/1/servi > ceability/sa/ClhsdbCDSJstackPrintAll.d:/scratch/mesos/jib- > master/install/2020-02-19- > 1905201.christoph.langer.source/src.full/open/test/hotspot/jtreg/serviceabil > ity/sa:/scratch/mesos/slaves/90726e33-be99-4e27-9d68-25dad266ef13- > S80/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd- > 0196/executors/fb2f58a7-7e16-4340-8783-4207c1d11742/runs/3ca5d907- > 2207-49d1-a673-f3617d83173d/testoutput/test- > support/jtreg_open_test_hotspot_jtreg_tier1_serviceability/classes/1/test/ > lib:/scratch/mesos/jib-master/install/2020-02-19- > 1905201.christoph.langer.source/src.full/open/test/lib:/scratch/mesos/jib- > master/install/java/re/jtreg/4.2/promoted/all/b16/bundles/jtreg_bin- > 4.2.zip/jtreg/lib/javatest.jar:/scratch/mesos/jib- > master/install/java/re/jtreg/4.2/promoted/all/b16/bundles/jtreg_bin- > 4.2.zip/jtreg/lib/jtreg.jar > -Dapplication.home=/scratch/mesos/jib-master/install/2020-02-19- > 1905201.christoph.langer.source/macosx-x64-debug.jdk/jdk-15/fastdebug > -Xms8m -Djdk.module.main=jdk.hotspot.agent > jdk.hotspot.agent/sun.jvm.hotspot.SALauncher clhsdb --pid=34506 > > Host: scaaa915.us.oracle.com, MacPro6,1 x86_64 3700 MHz, 8 cores, 16G, > Darwin 17.5.0 > Time: Wed Feb 19 19:49:38 2020 GMT elapsed time: 5 seconds (0d 0h 0m 5s) > > --- T H R E A D --- > > Current thread (0x7f9158008800): JavaThread "C2 CompilerThread0" > daemon [_thread_in_native, id=43267, > stack(0x77ca8000,0x77da8000)] > > > Current CompileTask: > C2: 5392 726 ! 4 > jdk.internal.reflect.GeneratedConstructorAccessor3::newInstance (53 bytes) > > Stack: [0x77ca8000,0x77da8000], sp=0x77da3b70, > free space=1006k > Native frames: (J=compiled Java code, A=aot compiled Java code, > j=interpreted, Vv=VM code, C=native code) > V [libjvm.dylib+0xb48133] VMError::report_and_die(int, char const*, > char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char > const*, int, unsigned long)+0x6e5 > V [libjvm.dylib+0xb4884f] VMError::report_and_die(Thread*, void*, char > const*, int, char const*, char const*, __va_list_tag*)+0x47 > V [libjvm.dylib+0x338454] report_vm_error(char const*, int, char > const*, char const*, ...)+0x145 > V [libjvm.dylib+0x49c0fb] assert_dom(Block*, Block*, Node*, PhaseCFG > const*)+0x15d > V [libjvm.dylib+0x497588] PhaseCFG::schedule_early(VectorSet&, > Node_Stack&)+0x29a > V [libjvm.dylib+0x499c49] PhaseCFG::global_code_motion()+0x1ad > V [libjvm.dylib+0x49a211] PhaseCFG::do_global_code_motion()+0x41 > V [libjvm.dylib+0x304254] Compile::Code_Gen()+0x224 > V [libjvm.dylib+0x301f3b] Compile::Compile(ciEnv*, C2Compiler*, > ciMethod*, int, bool, bool, bool, DirectiveSet*)+0xbf1 > V [libjvm.dylib+0x254242] C2Compiler::compile_method(ciEnv*, > ciMethod*, int, DirectiveSet*)+0xe8 > V [libjvm.dylib+0x3142ae] > CompileBroker::invoke_c
Re: Is anyone still building multiple JVMs?
On 2/20/20 9:32 AM, Magnus Ihse Bursie wrote: >>> I think we should also ask -- is anyone actually shipping a JDK build with >>> multiple libjvm variants in it? >> Debian and therefore Ubuntu always build and ship both Hotspot and Zero on >> every architecture which supports both [1]. > But that is not supported by the build system -- if you build zero, you > cannot build any other JVM at the > same time! So if you ship this, you must build them separately and then in a > post-processing step copy them > together and modify jvm.cfg, right? Yeah, I think those are separate builds running each their own configure run [1]. Adrian > [1] > https://git.launchpad.net/~openjdk/ubuntu/+source/openjdk/+git/openjdk/tree/debian/rules -- .''`. 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: Is anyone still building multiple JVMs?
On 2020-02-20 09:28, John Paul Adrian Glaubitz wrote: On 2/20/20 9:24 AM, Ioi Lam wrote: I think we should also ask -- is anyone actually shipping a JDK build with multiple libjvm variants in it? Debian and therefore Ubuntu always build and ship both Hotspot and Zero on every architecture which supports both [1]. But that is not supported by the build system -- if you build zero, you cannot build any other JVM at the same time! So if you ship this, you must build them separately and then in a post-processing step copy them together and modify jvm.cfg, right? /Magnus Adrian [1] https://packages.debian.org/source/sid/openjdk-14
Re: Mach5 test failure when testing JDK-8237192
Hi Christoph, The Solaris failure looks like an infra issue. The test failure is a crash - info below. I don't see any open, or recently fixed, bugs for the same crash. David - # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/scratch/mesos/slaves/90726e33-be99-4e27-9d68-25dad266ef13-S3967/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/9c4085d3-922a-46c2-b44a-9835e74ddb36/runs/ecd258eb-38e6-4966-b233-0cdfa582f713/workspace/open/src/hotspot/share/opto/gcm.cpp:276), pid=34522, tid=43267 # assert(false) failed: unscheduable graph # # JRE version: Java(TM) SE Runtime Environment (15.0) (fastdebug build 15-internal+0-2020-02-19-1905201.christoph.langer.source) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 15-internal+0-2020-02-19-1905201.christoph.langer.source, mixed mode, sharing, tiered, compressed oops, g1 gc, bsd-amd64) # Core dump will be written. Default location: core.34522 # # If you would like to submit a bug report, please visit: # https://bugreport.java.com/bugreport/crash.jsp # --- S U M M A R Y Command Line: -Denv.class.path=/scratch/mesos/slaves/90726e33-be99-4e27-9d68-25dad266ef13-S80/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/fb2f58a7-7e16-4340-8783-4207c1d11742/runs/3ca5d907-2207-49d1-a673-f3617d83173d/testoutput/test-support/jtreg_open_test_hotspot_jtreg_tier1_serviceability/classes/1/serviceability/sa/ClhsdbCDSJstackPrintAll.d:/scratch/mesos/jib-master/install/2020-02-19-1905201.christoph.langer.source/src.full/open/test/hotspot/jtreg/serviceability/sa:/scratch/mesos/slaves/90726e33-be99-4e27-9d68-25dad266ef13-S80/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/fb2f58a7-7e16-4340-8783-4207c1d11742/runs/3ca5d907-2207-49d1-a673-f3617d83173d/testoutput/test-support/jtreg_open_test_hotspot_jtreg_tier1_serviceability/classes/1/test/lib:/scratch/mesos/jib-master/install/2020-02-19-1905201.christoph.langer.source/src.full/open/test/lib:/scratch/mesos/jib-master/install/java/re/jtreg/4.2/promoted/all/b16/bundles/jtreg_bin-4.2.zip/jtreg/lib/javatest.jar:/scratch/mesos/jib-master/install/java/re/jtreg/4.2/promoted/all/b16/bundles/jtreg_bin-4.2.zip/jtreg/lib/jtreg.jar -Dapplication.home=/scratch/mesos/jib-master/install/2020-02-19-1905201.christoph.langer.source/macosx-x64-debug.jdk/jdk-15/fastdebug -Xms8m -Djdk.module.main=jdk.hotspot.agent jdk.hotspot.agent/sun.jvm.hotspot.SALauncher clhsdb --pid=34506 Host: scaaa915.us.oracle.com, MacPro6,1 x86_64 3700 MHz, 8 cores, 16G, Darwin 17.5.0 Time: Wed Feb 19 19:49:38 2020 GMT elapsed time: 5 seconds (0d 0h 0m 5s) --- T H R E A D --- Current thread (0x7f9158008800): JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=43267, stack(0x77ca8000,0x77da8000)] Current CompileTask: C2: 5392 726 ! 4 jdk.internal.reflect.GeneratedConstructorAccessor3::newInstance (53 bytes) Stack: [0x77ca8000,0x77da8000], sp=0x77da3b70, free space=1006k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.dylib+0xb48133] VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x6e5 V [libjvm.dylib+0xb4884f] VMError::report_and_die(Thread*, void*, char const*, int, char const*, char const*, __va_list_tag*)+0x47 V [libjvm.dylib+0x338454] report_vm_error(char const*, int, char const*, char const*, ...)+0x145 V [libjvm.dylib+0x49c0fb] assert_dom(Block*, Block*, Node*, PhaseCFG const*)+0x15d V [libjvm.dylib+0x497588] PhaseCFG::schedule_early(VectorSet&, Node_Stack&)+0x29a V [libjvm.dylib+0x499c49] PhaseCFG::global_code_motion()+0x1ad V [libjvm.dylib+0x49a211] PhaseCFG::do_global_code_motion()+0x41 V [libjvm.dylib+0x304254] Compile::Code_Gen()+0x224 V [libjvm.dylib+0x301f3b] Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool, DirectiveSet*)+0xbf1 V [libjvm.dylib+0x254242] C2Compiler::compile_method(ciEnv*, ciMethod*, int, DirectiveSet*)+0xe8 V [libjvm.dylib+0x3142ae] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x664 V [libjvm.dylib+0x313a3f] CompileBroker::compiler_thread_loop()+0x283 V [libjvm.dylib+0xabf30b] JavaThread::thread_main_inner()+0x1a1 V [libjvm.dylib+0xabeebd] JavaThread::run()+0x23d V [libjvm.dylib+0xabb861] Thread::call_run()+0x11b V [libjvm.dylib+0x93521c] thread_native_entry(Thread*)+0xe0 C [libsystem_pthread.dylib+0x3661] _pthread_body+0x154 C [libsystem_pthread.dylib+0x350d] _pthread_body+0x0 C [libsystem_pthread.dylib+0x2bf9] thread_start+0xd On 20/02/2020 6:06 pm, Langer, Christoph wrote: Hi, I tested my change for JDK-8237192 in the submit repo. I got this back. Can anybody from Oracle please have a look whether the failures could be related to my patch? At first sight and from the i
Re: Is anyone still building multiple JVMs?
On 2/20/20 9:24 AM, Ioi Lam wrote: > I think we should also ask -- is anyone actually shipping a JDK build with > multiple libjvm variants in it? Debian and therefore Ubuntu always build and ship both Hotspot and Zero on every architecture which supports both [1]. Adrian > [1] https://packages.debian.org/source/sid/openjdk-14 -- .''`. 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: Is anyone still building multiple JVMs?
I think we should also ask -- is anyone actually shipping a JDK build with multiple libjvm variants in it? I guess people may be building multiple variants during testing just because it's convenient (and requires less time), but if this is the only reason, then it doesn't seem to be worth the complexity in the build system. (I think are also logics in jlink that are needed to support multiple variants, so those can also be simplified). Thanks - Ioi On 2/19/20 4:26 AM, Magnus Ihse Bursie wrote: Are there still any realistic scenarios where anyone builds multiple variants of Hotspot in the same configuration? This was basically introduced for 32-bit builds, where both the server and the client variant of Hotspot were built. In Oracle at least, we stopped building multiple JVM variants a long time ago. Since the build system is taxed with convoluted logic in places just to support this, I’d prefer to remove it if it is not used anymore. So, is there anyone out there, still doing this? /Magnus
Mach5 test failure when testing JDK-8237192
Hi, I tested my change for JDK-8237192 in the submit repo. I got this back. Can anybody from Oracle please have a look whether the failures could be related to my patch? At first sight and from the information I can see here, I don’t see the relation… Thanks Christoph From: do-not-re...@oracle.com Sent: Mittwoch, 19. Februar 2020 21:16 To: Langer, Christoph Subject: [Mach5] mach5-one-clanger-JDK-8237192-20200219-1906-8861422: FAILED, Failed tests: 1 Job: mach5-one-clanger-JDK-8237192-20200219-1906-8861422 BuildId: 2020-02-19-1905201.christoph.langer.source Failed tests: showing 1 out of 1 Test Tier Platform Description serviceability/sa/ClhsdbCDSJstackPrintAll.java tier1 macosx-x64-debug Exception: java.io.IOException: LingeredApp terminated with non-zero exit code ... Tasks Summary * UNABLE_TO_RUN: 1 * PASSED: 76 * FAILED: 1 * NA: 0 * NOTHING_TO_RUN: 0 * EXECUTED_WITH_FAILURE: 1 * HARNESS_ERROR: 0 * KILLED: 0 Build 1 Failed * solaris-sparcv9-open-debug-solaris-sparcv9-build-11 SOURCE_MASTER REASON_INVALID_...d68-25dad266ef13-O20132041 is no longer valid Test 1 Unable to run * tier1-solaris-sparc-open_test_hotspot_jtreg_tier1_common-solaris-sparcv9-open-debug-62 Dependency task failed: mach5...s-sparcv9-open-debug-solaris-sparcv9-build-11 1 Executed with failure * tier1-debug-open_test_hotspot_jtreg_tier1_serviceability-macosx-x64-debug-59 Results: total: 44, passed: 43, failed: 1, skipped: 0
