Re: RFR: 8275874: [JVMCI] use volatile accessors for all unaligned reads in c2v_readFieldValue
On Mon, 25 Oct 2021 14:33:27 GMT, Doug Simon wrote: > [JDK-8275645](https://bugs.openjdk.java.net/browse/JDK-8275645) resulted in > loosing single-copy atomicity for reads in `c2v_readFieldValue`. This PR > fixes that by using `_field_acquire` accessors for all aligned reads > and only using `_field` accessors for unaligned reads. Marked as reviewed by never (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/6109
Re: RFR: 8254827: JVMCI: Enable it for Windows+AArch64 [v3]
On Tue, 20 Oct 2020 15:46:36 GMT, Bernhard Urban-Forster wrote: >> Use r18 as allocatable register on Linux only. >> >> A bootstrap works now (it has been crashing before due to r18 being >> allocated): >> $ ./windows-aarch64-server-fastdebug/bin/java.exe >> -XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler -XX:+BootstrapJVMCI >> -version >> Bootstrapping JVMCI. in 17990 ms >> (compiled 3330 methods) >> openjdk version "16-internal" 2021-03-16 >> OpenJDK Runtime Environment (fastdebug build >> 16-internal+0-adhoc.NORTHAMERICAbeurba.openjdk-jdk) >> OpenJDK 64-Bit Server VM (fastdebug build >> 16-internal+0-adhoc.NORTHAMERICAbeurba.openjdk-jdk, mixed mode) >> >> Jtreg tests `test/hotspot/jtreg/compiler/jvmci` are passing as well. > > Bernhard Urban-Forster has updated the pull request with a new target base > due to a merge or a rebase. The incremental webrev excludes the unrelated > changes brought in by the merge/rebase. The pull request contains five > additional commits since the last revision: > > - add missing precompiled.hpp include > - Merge remote-tracking branch 'upstream/master' into > 8254827-enable-jvmci-win-aarch64 > - rename argument to canUsePlatformRegister > - comment for platformRegister > - 8254827: JVMCI: Enable it for Windows+AArch64 > >Use r18 as allocatable register on Linux only. > >A bootstrap works now (it has been crashing before due to r18 being > allocated): >```console >$ ./windows-aarch64-server-fastdebug/bin/java.exe > -XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler -XX:+BootstrapJVMCI > -version >Bootstrapping JVMCI. in 17990 ms >(compiled 3330 methods) >openjdk version "16-internal" 2021-03-16 >OpenJDK Runtime Environment (fastdebug build > 16-internal+0-adhoc.NORTHAMERICAbeurba.openjdk-jdk) >OpenJDK 64-Bit Server VM (fastdebug build > 16-internal+0-adhoc.NORTHAMERICAbeurba.openjdk-jdk, mixed mode) >``` > >Jtreg tests `test/hotspot/jtreg/compiler/jvmci` are passing as well. Marked as reviewed by never (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/685
Re: code review round 0 for minor FDS makefile fix (8033714)
Looks good to me too. Thanks for fixing this. tom On Feb 6, 2014, at 6:07 AM, Daniel D. Daugherty daniel.daughe...@oracle.com wrote: On 2/5/14 9:28 PM, David Holmes wrote: Hi Dan, Looks good to me. Thanks for the review! (I never run the install targets :( ) Neither do I and apparently neither does JPRT... That's how this slipped through the cracks... Dan Thanks, David On 6/02/2014 9:20 AM, Daniel D. Daugherty wrote: This code review request is going to three different aliases. Don't use Thunderbird's reply to list option since it will pick just _one_ of the _three_ lists. Greetings, Doug Simon and Tom Rodriguez have sent a Full Debug Symbols (FDS) makefile fix our way. Here are the bug and webrev URLs: http://cr.openjdk.java.net/~dcubed/8033714-webrev/0-jdk9-hs-runtime/ 8033714 hotspot 'install_jvm' bld target broken with ZIP_DEBUGINFO_FILES=0 https://bugs.openjdk.java.net/browse/JDK-8033714 As you might guess from the bug synopsis, this fix is needed when building without ZIP'ing the debuginfo files (ZIP_DEBUGINFO_FILES=0). Based on the Graal project fix, I've updated a few other places where building with FDS disabled is affected. As always, comments and suggestions are welcome. Dan
Re: dacapo bloat benchmark fails on openjdk7
I built a copy of hotspot from b33 on ubuntu with gcc 4.2 and I'm seeing the same failure you are. I believe this is the same issue covered by 6741642 which was found and fixed by the IcedTea folks. Applying the fix to a copy of b33 allowed dacapo to complete normally. 6741642 is in the hotspot-comp repository but won't trickle up into a promoted build for a couple weeks so you may need to apply this by hand to your version. http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/fa4d1d240383 is the changeset of interest. tom On Aug 28, 2008, at 1:34 AM, Luca Martini wrote: Tom Rodriguez wrote: Could you be more specific about what bits you are running, i.e. which changeset of hotspot? The official openjdk bits run fine for me with at least b30-b33. It seems b33. [EMAIL PROTECTED]:~/mp/interfaces/OpenJDK/jdk7/hotspot$ hg log | head -n 6 changeset: 241:5b3b8a69f10f tag: tip user:xdono date:Thu Aug 14 09:26:23 2008 -0700 summary: Added tag jdk7-b33 for changeset 585535ec8a14 Bloat is not the only dacapo benchmark to fail, but also antlr, chart, eclipse, fop, jython, lusearch, pmd, xalan. hsqldb and luindex do not fail. I think it is definitively a problem of my OpenJDK build. Once the build finished, to use the new VM, is it necessary to set some environemnt variable or invoking the new java executable will suffice? I also put on pastebin my make sanity: http://pastebin.com/f52ad5606 Do you see something strange? Thanks for all your help. Luca -- * Ing. Luca Martini Dipartimento di Ing. dell'Informazione Università di Pisa Via Diotisalvi, 2, I-56126 Pisa, Italy Tel: +39 050 2217 465 Fax: +39 050 2217 600 e-mail: [EMAIL PROTECTED] *
Re: fastdebug_build triggers -Werror with g++ 4.3.1-9 (Debian)
This was fixed as part of 6712835. http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/6ca61c728c2d tom On Aug 27, 2008, at 5:24 AM, Florian Weimer wrote: g++ -DLINUX -D_GNU_SOURCE -DAMD64 -DASSERT -DFASTDEBUG -I. -I../ generated/adfiles -I../generated/jvmtifiles -I/home/fw/src/java/jdk7/ hotspot/src/share/vm/asm -I/home/fw/src/java/jdk7/hotspot/src/share/ vm/ci -I/home/fw/src/java/jdk7/hotspot/src/share/vm/classfile -I/ home/fw/src/java/jdk7/hotspot/src/share/vm/code -I/home/fw/src/java/ jdk7/hotspot/src/share/vm/compiler -I/home/fw/src/java/jdk7/hotspot/ src/share/vm/gc_implementation -I/home/fw/src/java/jdk7/hotspot/src/ share/vm/gc_implementation/parNew -I/home/fw/src/java/jdk7/hotspot/ src/share/vm/gc_implementation/concurrentMarkSweep -I/home/fw/src/ java/jdk7/hotspot/src/share/vm/gc_implementation/shared -I/home/fw/ src/java/jdk7/hotspot/src/share/vm/gc_implementation/ parallelScavenge -I/home/fw/src/java/jdk7/hotspot/src/share/vm/ gc_interface -I/home/fw/src/java/jdk7/hotspot/src/share/vm/ interpreter -I/home/fw/src/java/jdk7/hotspot/src/share/vm/libadt -I/ home/fw/src/java/jdk7/hotspot/src/share/vm/memory -I/home/fw/src/ java/jdk7/hotspot/src/share/vm/oops -I/home/fw/src/java/jdk7/hotspot/ src/share/vm/opto -I/home/fw/src/java/jdk7/hotspot/src/share/vm/ prims -I/home/fw/src/java/jdk7/hotspot/src/share/vm/runtime -I/home/ fw/src/java/jdk7/hotspot/src/share/vm/services -I/home/fw/src/java/ jdk7/hotspot/src/share/vm/utilities -I/home/fw/src/java/jdk7/hotspot/ src/cpu/x86/vm -I/home/fw/src/java/jdk7/hotspot/src/os/linux/vm -I/ home/fw/src/java/jdk7/hotspot/src/os_cpu/linux_x86/vm -I../generated -DHOTSPOT_RELEASE_VERSION=\14.0-b01\ - DHOTSPOT_BUILD_TARGET=\fastdebug\ -DHOTSPOT_BUILD_USER=\fw\ - DHOTSPOT_LIB_ARCH=\amd64\ -DJRE_RELEASE_VERSION=\1.7.0-internal- fastdebug-fw_2008_08_27_11_45-b00\ -DHOTSPOT_VM_DISTRO=\OpenJDK \ -DCOMPILER2 -fPIC -fno-rtti -fno-exceptions -D_REENTRANT -fcheck- new -m64 -pipe -O3 -fno-strict-aliasing -DVM_LITTLE_ENDIAN -D_LP64=1 -fno-omit-frame-pointer -Werror -Wpointer-arith -Wsign-compare-c -o ciMethodBlocks.o /home/fw/src/java/jdk7/hotspot/src/share/vm/ci/ ciMethodBlocks.cpp cc1plus: warnings being treated as errors /home/fw/src/java/jdk7/hotspot/src/share/vm/ci/ciMethodBlocks.cpp: 362: error: deprecated conversion from string constant to ‘char*’ It's inside #ifndef PRODUCT, that's why it hasn't been caught before. This happens with this tip: changeset: 241:5b3b8a69f10f tag: tip user:xdono date:Thu Aug 14 09:26:23 2008 -0700 summary: Added tag jdk7-b33 for changeset 585535ec8a14 To be honest, I think -Werror should be disabled except for test builds (with well-defined compilers). For downstream consumers, -Werror only adds additional hassle.
Re: dacapo bloat benchmark fails on openjdk7
Could you be more specific about what bits you are running, i.e. which changeset of hotspot? The official openjdk bits run fine for me with at least b30-b33. tom On Aug 27, 2008, at 1:34 AM, Luca Martini wrote: Apologies for cross posting to the dacapobench-researchers and [EMAIL PROTECTED] lists. Hi all, I recently tried to execute the DaCapo benchmark on OpenJDK 7 and I found that bloat benchmark fails with the following exception: $ OpenJDK/jdk7/build/linux-i586/j2re-image/bin/java-jar ~/dacapo-2006-10-MR2.jar bloat = DaCapo bloat starting = ** Exception while optimizing transform(LEDU/purdue/cs/bloat/editor/MethodEditor;)Z of class EDU/purdue/cs/bloat/trans/CompactArrayInitializer String index out of range: -1802716504 java.lang.StringIndexOutOfBoundsException: String index out of range: -1802716504 at java.lang.String.getChars(String.java:860) at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:408) at java.lang.StringBuilder.append(StringBuilder.java:136) at java.lang.StringBuilder.append(StringBuilder.java:132) at java.util.AbstractCollection.toString(AbstractCollection.java:439) at EDU.purdue.cs.bloat.codegen.RegisterAllocator $IGNode.toString(RegisterAllocator.java:570) at java.lang.String.valueOf(String.java:2838) at java.lang.StringBuffer.append(StringBuffer.java:236) at EDU.purdue.cs.bloat.util.Graph$4.next(Graph.java:983) at java.util.AbstractCollection.addAll(AbstractCollection.java:322) at EDU .purdue .cs.bloat.codegen.RegisterAllocator.init(RegisterAllocator.java:288) at EDU.purdue.cs.bloat.optimize.Main.bloatMethod(Main.java:1078) at EDU.purdue.cs.bloat.optimize.Main.editClass(Main.java:688) at EDU.purdue.cs.bloat.optimize.Main.main(Main.java:446) at dacapo.bloat.BloatHarness.iterate(BloatHarness.java:25) at dacapo.Benchmark.run(Benchmark.java:126) at dacapo.TestHarness.runBenchmark(TestHarness.java:302) at dacapo.TestHarness.main(TestHarness.java:242) at Harness.main(Harness.java:5) I really don't know if it's a DaCapo problem or if I missed something in the build process of OpenJDK. The version of the DaCapo is 2006-10- MR2. I built OpenJDK both using mercurial repository and source bundle, and the build runs fine but when executing the benchmark the same error come up. These are the options I used for building OpenJDK 7: LANG=C FINDBUGS_HOME= local path for findbugs ALT_BOOTDIR=/usr/lib/jvm/java-6-sun ALT_BINARY_PLUGS_PATH= local path for binary plugs ANT_HOME=/usr/share/ant ARCH_DADA_MODEL=32 Here there are some information on my machine: $ uname -a Linux 2.6.24-21-generic #1 SMP Tue Aug 12 13:37:22 UTC 2008 i686 GNU/ Linux Any clues? Can anybody confirm such error? Thanks for your attention, Luca -- * Ing. Luca Martini Dipartimento di Ing. dell'Informazione Università di Pisa Via Diotisalvi, 2, I-56126 Pisa, Italy Tel: +39 050 2217 465 Fax: +39 050 2217 600 e-mail: [EMAIL PROTECTED] *
