From david.holmes at oracle.com Mon Aug 1 00:46:16 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 1 Aug 2016 10:46:16 +1000 Subject: RFR 8161445: [BACKOUT] MemberNameTable doesn't purge stale entries In-Reply-To: References: Message-ID: <9b3d22b3-5ad5-3fac-97f4-7c3dbc3965cb@oracle.com> Hi Coleen, Looks like a clean reversal of the original changes to me. Thanks, David On 30/07/2016 3:52 AM, Coleen Phillimore wrote: > Summary: Original change caused performance regression in > microbenchmarks after GC > > Eric Caspole's additional performance measurements are in the bug > report. Also, I don't think it was a good idea for the jvm to intern > MemberName assuming they are immutable. The interning should be in > Java code. I didn't see a huge advantage to interning these as there > weren't a big proportion of duplicates that I could see in my logging. > I added a REDO bug and contacted the submitter for the severity of this > problem in real life, since what they sent was a microbenchmark as well. > > Tested with JPRT and original test case. The backout was clean and had > no conflicts. > > open webrev at http://cr.openjdk.java.net/~coleenp/8161445/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8161445 > > Thanks, > Coleen From coleen.phillimore at oracle.com Mon Aug 1 01:46:25 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Sun, 31 Jul 2016 21:46:25 -0400 Subject: RFR 8161445: [BACKOUT] MemberNameTable doesn't purge stale entries In-Reply-To: <9b3d22b3-5ad5-3fac-97f4-7c3dbc3965cb@oracle.com> References: <9b3d22b3-5ad5-3fac-97f4-7c3dbc3965cb@oracle.com> Message-ID: <77d70ddb-883d-3d7b-c727-7feeefa8d154@oracle.com> Thanks David. Coleen On 7/31/16 8:46 PM, David Holmes wrote: > Hi Coleen, > > Looks like a clean reversal of the original changes to me. > > Thanks, > David > > On 30/07/2016 3:52 AM, Coleen Phillimore wrote: >> Summary: Original change caused performance regression in >> microbenchmarks after GC >> >> Eric Caspole's additional performance measurements are in the bug >> report. Also, I don't think it was a good idea for the jvm to intern >> MemberName assuming they are immutable. The interning should be in >> Java code. I didn't see a huge advantage to interning these as there >> weren't a big proportion of duplicates that I could see in my logging. >> I added a REDO bug and contacted the submitter for the severity of this >> problem in real life, since what they sent was a microbenchmark as well. >> >> Tested with JPRT and original test case. The backout was clean and had >> no conflicts. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8161445/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8161445 >> >> Thanks, >> Coleen From erik.joelsson at oracle.com Mon Aug 1 11:34:34 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 1 Aug 2016 13:34:34 +0200 Subject: PING: [8u112] Request for review & approval for CR8151841: Build needs additional flags to compile with GCC 6 In-Reply-To: <788404102.5570020.1468596130974.JavaMail.zimbra@redhat.com> References: <488374967.2958104.1467922862145.JavaMail.zimbra@redhat.com> <577F4C58.6060101@oracle.com> <1053522900.3503496.1468213009871.JavaMail.zimbra@redhat.com> <788404102.5570020.1468596130974.JavaMail.zimbra@redhat.com> Message-ID: <75eba245-b501-6567-445c-836fa7fc3885@oracle.com> Looks good now, thanks! Sorry for not answering earlier. I just got back from vacation. /Erik On 2016-07-15 17:22, Andrew Hughes wrote: > Ping? > > ----- Original Message ----- >> ----- Original Message ----- >>> Hello, >>> >>> It looks like TOOLCHAIN_CXX_COMPILER_CHECK_ARGUMENTS is always returning >>> yes and TOOLCHAIN_C_COMPILER_CHECK_ARGUMENTS still does both the C and >>> C++ checks. >>> >> Ugh, merged a block in the wrong place by the looks of it. >> >> Fixed in http://cr.openjdk.java.net/~andrew/8u/8151841/webrev.02/ >> >> configure:29739: checking if the C++ compiler supports "-std=gnu++98 " >> configure:29755: /usr/bin/g++ -c -std=gnu++98 conftest.cpp >&5 >> configure:29755: $? = 0 >> configure:29769: result: yes >> configure:29815: checking if the C compiler supports >> "-fno-delete-null-pointer-checks -Werror" >> configure:29832: /usr/bin/gcc -c -fno-delete-null-pointer-checks -Werror >> conftest.c >&5 >> configure:29832: $? = 0 >> configure:29846: result: yes >> configure:29855: checking if the C++ compiler supports >> "-fno-delete-null-pointer-checks -Werror" >> configure:29871: /usr/bin/g++ -c -fno-delete-null-pointer-checks -Werror >> conftest.cpp >&5 >> configure:29871: $? = 0 >> configure:29885: result: yes >> configure:29894: checking if both compilers support >> "-fno-delete-null-pointer-checks -Werror" >> configure:29899: result: yes >> configure:29911: checking if the C compiler supports "-fno-lifetime-dse >> -Werror" >> configure:29927: /usr/bin/gcc -c -fno-lifetime-dse -Werror conftest.c >&5 >> configure:29927: $? = 0 >> configure:29941: result: yes >> configure:29950: checking if the C++ compiler supports "-fno-lifetime-dse >> -Werror" >> configure:29966: /usr/bin/g++ -c -fno-lifetime-dse -Werror conftest.cpp >&5 >> configure:29966: $? = 0 >> configure:29980: result: yes >> configure:29989: checking if both compilers support "-fno-lifetime-dse >> -Werror" >> configure:29994: result: yes >> >> >>> /Erik >>> >>> On 2016-07-07 22:21, Andrew Hughes wrote: >>>> Webrev: http://cr.openjdk.java.net/~andrew/8u/8151841/webrev.01/ >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8151841 >>>> >>>> This is a backport of the original fix to support building OpenJDK >>>> with GCC 6. It was necessary to cherry-pick parts of a number of >>>> earlier fixes to make this work with the build system in 8: >>>> >>>> 8149647: Incremental enhancements from build-infra >>>> 8032045: Enable compiler and linker safety switches for debug builds >>>> >>>> and so I'm requesting a review of the 8 version of the patch here as well >>>> as approval for 8u. >>>> >>>> In brief, the patch makes OpenJDK build with GCC 6 by explicitly >>>> specifying >>>> the C++ standard to use (-std=gnu++98) and disabling two optimisations >>>> with >>>> -fno-lifetime-dse and -fno-delete-null-pointer-checks. Further >>>> information >>>> on the changes is available in the GCC 6 release notes [0]. GCC 6 uses >>>> a newer C++ standard, C++14, with which the OpenJDK codebase is not yet >>>> compliant. The simplest way to fix this, especially for existing >>>> releases, >>>> is to explicitly request the previous default, gnu++98. The deletion >>>> of null pointer checks and more aggressive lifetime dead store >>>> elimination >>>> in 6 lead to a crashing virtual machine being built, so we disable them >>>> if GCC >= 6 is used. >>>> >>>> To make the original patch work with 8u, a number of changes from other >>>> fixes had to also be brought over: >>>> >>>> * We need to check we are using GCC 6 or above, so we need to bring >>>> over the TOOLCHAIN_CHECK_COMPILER_VERSION and >>>> TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS macros from 8149647. >>>> TOOLCHAIN_CHECK_COMPILER_VERSION is converted back to a traditional >>>> numbered rather than named argument macro so we don't need to backport >>>> BASIC_DEFUN_NAMED. >>>> * We bring over the introduction of COMMON_CCXXFLAGS_JDK from 8030245 >>>> as we need to apply the -std option only to the C++ compiler, not the >>>> C compiler. If passed to the C compiler, it will produce a warning, >>>> and this is converted to an error at one point in the build >>>> (a -Werror in libsctp). >>>> >>>> Generally, we've kept things in toolchain.m4 (8034788 introduced >>>> flags.m4, >>>> separating out some code, and so many of these changes are in that file >>>> in 9) and avoid named argument macros. Otherwise, it's largely the >>>> same as the 9 version. We have adopted the longer name for >>>> the -fno-delete-null-pointer-checks flag variable as suggested in the >>>> review of the update to this patch for the new HotSpot build [1]. >>>> >>>> [0] https://gcc.gnu.org/gcc-6/porting_to.html >>>> [1] >>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-July/023840.html >>> >> -- >> Andrew :) >> >> Senior Free Java Software Engineer >> Red Hat, Inc. (http://www.redhat.com) >> >> PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) >> Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 >> >> >> From eric.caspole at oracle.com Mon Aug 1 18:02:41 2016 From: eric.caspole at oracle.com (Eric Caspole) Date: Mon, 1 Aug 2016 14:02:41 -0400 Subject: RFR 8161445: [BACKOUT] MemberNameTable doesn't purge stale entries In-Reply-To: References: Message-ID: <579F8EC1.7090000@oracle.com> Hi Coleen, Looks good. Thanks, Eric On 07/29/2016 01:52 PM, Coleen Phillimore wrote: > Summary: Original change caused performance regression in > microbenchmarks after GC > > Eric Caspole's additional performance measurements are in the bug > report. Also, I don't think it was a good idea for the jvm to intern > MemberName assuming they are immutable. The interning should be in > Java code. I didn't see a huge advantage to interning these as there > weren't a big proportion of duplicates that I could see in my logging. I > added a REDO bug and contacted the submitter for the severity of this > problem in real life, since what they sent was a microbenchmark as well. > > Tested with JPRT and original test case. The backout was clean and had > no conflicts. > > open webrev at http://cr.openjdk.java.net/~coleenp/8161445/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8161445 > > Thanks, > Coleen From kim.barrett at oracle.com Mon Aug 1 18:46:11 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 1 Aug 2016 14:46:11 -0400 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: <59522cd6-3823-bfa2-8785-bb472dd875ca@oracle.com> References: <88A2872D-70F9-48DB-94B1-4314B3D9D217@oracle.com> <3933D052-50B2-43F1-AA20-2E75F60B61CE@oracle.com> <3f6719ad-95a3-12eb-572a-8c171306fc8d@oracle.com> <94572805-06D5-456B-B73E-70BBD642CA22@oracle.com> <59522cd6-3823-bfa2-8785-bb472dd875ca@oracle.com> Message-ID: <160607E6-2021-4BA3-A9AB-72E59E721E78@oracle.com> This updated webrev addresses the concerns around initialization order for Throwable and OutOfMemoryError. It doesn't address the VM API used by the reference processor thread; that will be in a later webrev. New webrevs: full: http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.02/ incr: http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.02.incr/ The jdk tree is unchanged from webrev.01. I've backed out the change to initialize_java_lang_classes. (To verify this, look at the runtime/thread.cpp in the full webrev.) Instead, Universe::gen_out_of_memory_error now also requires Throwable to be initialized before it will attempt to fill in the stack trace. This means that VM generated OOMEs occurring early in initialization won't have a stack trace. An alternative that I considered was to remove the assert at the end of fill_in_stack_trace_of_preallocated_backtrace that requires java_lang_Throwable;:unassigned_stacktrace() to return non-NULL. I did some testing that seemed to work and provide stacktraces, relying on code in the Throwable class that special cases this "out of protocol" state. However, having read some of the history around that (JDK-6998871, JDK-7045138, JDK-7046490), that special casing seems to have been intended to be temporary, and expected to be removed. (Though I didn't find an RFE for doing so, and I'm not doing so here.) Even if we decided it wasn't going to be removed, this approach seems somewhat fragile. [Note to Coleen: This is the reverse of what you and I talked about a few days ago; I hadn't reviewed the history carefully then.] From kim.barrett at oracle.com Mon Aug 1 18:47:26 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 1 Aug 2016 14:47:26 -0400 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: <764F8C8B-AFE6-4A3F-8C0D-3D24F72CED58@oracle.com> References: <88A2872D-70F9-48DB-94B1-4314B3D9D217@oracle.com> <3933D052-50B2-43F1-AA20-2E75F60B61CE@oracle.com> <764F8C8B-AFE6-4A3F-8C0D-3D24F72CED58@oracle.com> Message-ID: This updated webrev addresses concerns about the performance of the VM API used by the reference processor thread in the original webrev. New webrevs: full: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.03/ http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.03/ incr: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.03.incr/ http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.03.incr/ The originally offered approach was an attempt to minimize changes. I was trying to be as similar to the existing code as possible, while moving part of it into the VM, where we have the necessary control over suspension and the like. We already know we want to make changes in this area, in order to eliminate the use of jdk.internal.ref.Cleaner (JDK-8149925). But we've also agreed that JDK-8149925 wasn't urgent and to defer it to JDK 10. I don't think we should revisit that. As Peter pointed out, my original change introduces a small performance regression on a microbenchmark for reference processing throughput. It also showed a small performance benefit on a different microbenchmark (allocation rate for a stress test of direct byte buffers), as noted in the original RFR. I can reproduce both of those. I think reference processing thread throughput is the right measure to use, so long as others don't become horrible. Focusing on that, it's better to just let the reference processing thread do the processing, rather than slowing it down to allow for the rare case when there's another thread that could possibly help. This is especially true now that Cleaner has such limited usage. This leads to a different API for other threads; rather than tryHandlePending that other threads can call to help and to examine progress, we now have waitForReferenceProcessing. The VM API is also different; rather than popReferencePendingList to get or wait, we now have getAndClearReferencePendingList and checkReferencePendingList, the latter with an optional wait. The splitting of the VM API allows us to avoid a narrow race condition discussed by Peter in his prototypes. Peter suggested this race was ok because java.nio.Bits makes several retries. However, those retries are only done before throwing OOME. There are no retries before invoking GC, so this race could lead to unnecessary successive GCs. Doing all the processing on the reference processing thread eliminates execution of Cleaners on application threads, though that's not nearly as much an issue now that the use of Cleaner is so restricted. We've also eliminated a pre-existing issue where a helper could report no progress even though the reference processing thread (and other helpers) had removed a pending reference, but not yet processed it. This could result in the non-progressing helper invoking GC or reporting failure, even though it might have succeeded if it had waited for the other thread(s) to complete processing the reference(s) being worked on. I think the new waitForReferenceProcessing could be used to fix JDK-6306116, though that isn't part of this change, and was not really a motivating factor. I don't know if the new waitForReferenceProcessing will be used by whatever we eventually do for JDK-8149925, but I think the new VM API will suffice for that. That is, I think JDK-8149925 might require changes to the core-libs API used by nio.Bits, and won't require further VM API changes. From coleen.phillimore at oracle.com Mon Aug 1 20:23:21 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 1 Aug 2016 16:23:21 -0400 Subject: RFR 8161445: [BACKOUT] MemberNameTable doesn't purge stale entries In-Reply-To: <579F8EC1.7090000@oracle.com> References: <579F8EC1.7090000@oracle.com> Message-ID: Thanks, Eric. Coleen On 8/1/16 2:02 PM, Eric Caspole wrote: > Hi Coleen, > Looks good. > Thanks, > Eric > > > On 07/29/2016 01:52 PM, Coleen Phillimore wrote: >> Summary: Original change caused performance regression in >> microbenchmarks after GC >> >> Eric Caspole's additional performance measurements are in the bug >> report. Also, I don't think it was a good idea for the jvm to intern >> MemberName assuming they are immutable. The interning should be in >> Java code. I didn't see a huge advantage to interning these as there >> weren't a big proportion of duplicates that I could see in my logging. I >> added a REDO bug and contacted the submitter for the severity of this >> problem in real life, since what they sent was a microbenchmark as well. >> >> Tested with JPRT and original test case. The backout was clean and had >> no conflicts. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8161445/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8161445 >> >> Thanks, >> Coleen From chris.plummer at oracle.com Mon Aug 1 22:46:16 2016 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 1 Aug 2016 15:46:16 -0700 Subject: RFR(XS): 8162670: make of jtreg_tests fails if no tests are run, causing jprt test runs to also fail Message-ID: Hello, Please review this simple change: https://bugs.openjdk.java.net/browse/JDK-8162670 http://cr.openjdk.java.net/~cjplummer/8162670/webrev-00/ Note the copyright dates haven't been updated in this webrev, but I did update them locally after noticing that. Tested with jprt test case given in the CR, and also with a jprt run using "testset -hotspot" to make sure I didn't break anything. thanks, Chris From stanislav.smirnov at oracle.com Mon Aug 1 23:01:26 2016 From: stanislav.smirnov at oracle.com (Stas Smirnov) Date: Mon, 1 Aug 2016 16:01:26 -0700 Subject: RFR(XS): 8162670: make of jtreg_tests fails if no tests are run, causing jprt test runs to also fail In-Reply-To: References: Message-ID: Hi Chris, changes look good On 01.08.2016 15:46, Chris Plummer wrote: > Hello, > > Please review this simple change: > > https://bugs.openjdk.java.net/browse/JDK-8162670 > http://cr.openjdk.java.net/~cjplummer/8162670/webrev-00/ > > Note the copyright dates haven't been updated in this webrev, but I > did update them locally after noticing that. > > Tested with jprt test case given in the CR, and also with a jprt run > using "testset -hotspot" to make sure I didn't break anything. > > thanks, > > Chris From coleen.phillimore at oracle.com Mon Aug 1 23:38:50 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 1 Aug 2016 19:38:50 -0400 Subject: RFR 8159284: bigapps/Jetty - assert(jfa->last_Java_sp() > sp()) failed with tracing code in use Message-ID: Summary: Test condition in assert in frame::safe_for_sender() for entry frames and return false. This bug is for a confidential part of the project that needs more robustness checks to verify that frame::sender() can be called. Also refactored into frame::entry_frame_is_safe() because these platforms had the same code for entry frames to determine whether it is still safe to trust this frame to call sender(). These platforms had also the same assert in sender_for_entry_frame() that the sampling code hit. Tested with our nightly tests on all platforms and bigapps/Jetty. open webrev at http://cr.openjdk.java.net/~coleenp/8159284.01/webrev Thanks, Coleen From david.holmes at oracle.com Tue Aug 2 00:58:22 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 2 Aug 2016 10:58:22 +1000 Subject: RFR(XS): 8162670: make of jtreg_tests fails if no tests are run, causing jprt test runs to also fail In-Reply-To: References: Message-ID: <8bbb54eb-e179-6c10-5d18-7838f08e847e@oracle.com> Hi Chris, On 2/08/2016 8:46 AM, Chris Plummer wrote: > Hello, > > Please review this simple change: > > https://bugs.openjdk.java.net/browse/JDK-8162670 > http://cr.openjdk.java.net/~cjplummer/8162670/webrev-00/ You've split a compound expression with your code: 227 jtregExitCode=$$? && \ 228 if [ $${jtregExitCode} == 1 ]; then \ 229 jtregExitCode=0; \ 230 fi ; \ 231 _summary="$(SUMMARY_TXT)"; \ I'm not clear exactly why the && was needed here but rather than find out later I suggest rearranging the above to: jtregExitCode=$$? && \ _summary="$(SUMMARY_TXT)"; \ if [ $${jtregExitCode} == 1 ]; then \ jtregExitCode=0; \ fi ; \ Thanks, David > Note the copyright dates haven't been updated in this webrev, but I did > update them locally after noticing that. > > Tested with jprt test case given in the CR, and also with a jprt run > using "testset -hotspot" to make sure I didn't break anything. > > thanks, > > Chris From dean.long at oracle.com Tue Aug 2 01:11:25 2016 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 1 Aug 2016 18:11:25 -0700 Subject: RFR 8159284: bigapps/Jetty - assert(jfa->last_Java_sp() > sp()) failed with tracing code in use In-Reply-To: References: Message-ID: <7e666611-eac2-3f7b-70b5-942fb68f9e39@oracle.com> Hi Coleen. If I understand correctly, previously we would get backtraces that end with the first C frame: [...] J 3335 C1 java.lang.Thread.run()V java.base at 9-ea (17 bytes) @ 0xe7fdc480 [0xe7fdc420+0x00000060] v ~StubRoutines::call_stub V [libjvm.so+0x66fe39] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x2b9 V [libjvm.so+0x931669] os::os_exception_wrapper(void (*)(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*), JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x19 V [libjvm.so+0x66eb2b] JavaCalls::call_virtual(JavaValue*, Handle, KlassHandle, Symbol*, Symbol*, Thread*)+0x13b V [libjvm.so+0x708069] thread_entry(JavaThread*, Thread*)+0x89 V [libjvm.so+0xaa5434] JavaThread::thread_main_inner()+0xf4 V [libjvm.so+0xaa5589] JavaThread::run()+0x119 V [libjvm.so+0x933cdc] thread_native_entry(Thread*)+0x10c C [libpthread.so.0+0x6bc9] C [libc.so.6+0xe2c9e] clone+0x5e but now with your change, won't all backtraces end on the last Java frame? So the above backtrace would be truncated to: [...] J 3335 C1 java.lang.Thread.run()V java.base at 9-ea (17 bytes) @ 0xe7fdc480 [0xe7fdc420+0x00000060] dl On 8/1/16 4:38 PM, Coleen Phillimore wrote: > Summary: Test condition in assert in frame::safe_for_sender() for > entry frames and return false. > > This bug is for a confidential part of the project that needs more > robustness checks to verify that frame::sender() can be called. > > Also refactored into frame::entry_frame_is_safe() because these > platforms had the same code for entry frames to determine whether it > is still safe to trust this frame to call sender(). These platforms > had also the same assert in sender_for_entry_frame() that the sampling > code hit. > > Tested with our nightly tests on all platforms and bigapps/Jetty. > > open webrev at http://cr.openjdk.java.net/~coleenp/8159284.01/webrev > > Thanks, > Coleen > From dean.long at oracle.com Tue Aug 2 01:39:10 2016 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 1 Aug 2016 18:39:10 -0700 Subject: RFR 8159284: bigapps/Jetty - assert(jfa->last_Java_sp() > sp()) failed with tracing code in use In-Reply-To: <7e666611-eac2-3f7b-70b5-942fb68f9e39@oracle.com> References: <7e666611-eac2-3f7b-70b5-942fb68f9e39@oracle.com> Message-ID: Upon a closer look, it appears that the backtraces we get for a crash come from print_native_stack() in debug.cpp, and that code uses a slightly different algorithm, so your changes shouldn't affect it. dl On 8/1/16 6:11 PM, dean.long at oracle.com wrote: > Hi Coleen. If I understand correctly, previously we would get > backtraces that end with the first C frame: > > [...] > J 3335 C1 java.lang.Thread.run()V java.base at 9-ea (17 bytes) @ > 0xe7fdc480 [0xe7fdc420+0x00000060] > v ~StubRoutines::call_stub > V [libjvm.so+0x66fe39] JavaCalls::call_helper(JavaValue*, > methodHandle const&, JavaCallArguments*, Thread*)+0x2b9 > V [libjvm.so+0x931669] os::os_exception_wrapper(void (*)(JavaValue*, > methodHandle const&, JavaCallArguments*, Thread*), JavaValue*, > methodHandle const&, JavaCallArguments*, Thread*)+0x19 > V [libjvm.so+0x66eb2b] JavaCalls::call_virtual(JavaValue*, Handle, > KlassHandle, Symbol*, Symbol*, Thread*)+0x13b > V [libjvm.so+0x708069] thread_entry(JavaThread*, Thread*)+0x89 > V [libjvm.so+0xaa5434] JavaThread::thread_main_inner()+0xf4 > V [libjvm.so+0xaa5589] JavaThread::run()+0x119 > V [libjvm.so+0x933cdc] thread_native_entry(Thread*)+0x10c > C [libpthread.so.0+0x6bc9] > C [libc.so.6+0xe2c9e] clone+0x5e > > > but now with your change, won't all backtraces end on the last Java > frame? So the above backtrace would be truncated to: > > [...] > J 3335 C1 java.lang.Thread.run()V java.base at 9-ea (17 bytes) @ > 0xe7fdc480 [0xe7fdc420+0x00000060] > > > dl > > On 8/1/16 4:38 PM, Coleen Phillimore wrote: >> Summary: Test condition in assert in frame::safe_for_sender() for >> entry frames and return false. >> >> This bug is for a confidential part of the project that needs more >> robustness checks to verify that frame::sender() can be called. >> >> Also refactored into frame::entry_frame_is_safe() because these >> platforms had the same code for entry frames to determine whether it >> is still safe to trust this frame to call sender(). These platforms >> had also the same assert in sender_for_entry_frame() that the >> sampling code hit. >> >> Tested with our nightly tests on all platforms and bigapps/Jetty. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8159284.01/webrev >> >> Thanks, >> Coleen >> > From chris.plummer at oracle.com Tue Aug 2 02:11:02 2016 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 1 Aug 2016 19:11:02 -0700 Subject: RFR(XS): 8162670: make of jtreg_tests fails if no tests are run, causing jprt test runs to also fail In-Reply-To: <8bbb54eb-e179-6c10-5d18-7838f08e847e@oracle.com> References: <8bbb54eb-e179-6c10-5d18-7838f08e847e@oracle.com> Message-ID: <4579a80c-6eb8-27e0-4e0d-cd68e6420df0@oracle.com> On 8/1/16 5:58 PM, David Holmes wrote: > Hi Chris, > > On 2/08/2016 8:46 AM, Chris Plummer wrote: >> Hello, >> >> Please review this simple change: >> >> https://bugs.openjdk.java.net/browse/JDK-8162670 >> http://cr.openjdk.java.net/~cjplummer/8162670/webrev-00/ > > You've split a compound expression with your code: > > 227 jtregExitCode=$$? && \ > 228 if [ $${jtregExitCode} == 1 ]; then \ > 229 jtregExitCode=0; \ > 230 fi ; \ > 231 _summary="$(SUMMARY_TXT)"; \ > > I'm not clear exactly why the && was needed here but rather than find > out later I suggest rearranging the above to: > > jtregExitCode=$$? && \ > _summary="$(SUMMARY_TXT)"; \ > if [ $${jtregExitCode} == 1 ]; then \ > jtregExitCode=0; \ > fi ; \ > Yeah, that makes sense. I'll make the change. However, it's really unclear what the use case for && is here. How can jtregExitCode=$$? ever fail? thanks, Chris > Thanks, > David > >> Note the copyright dates haven't been updated in this webrev, but I did >> update them locally after noticing that. >> >> Tested with jprt test case given in the CR, and also with a jprt run >> using "testset -hotspot" to make sure I didn't break anything. >> >> thanks, >> >> Chris From david.holmes at oracle.com Tue Aug 2 02:25:28 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 2 Aug 2016 12:25:28 +1000 Subject: RFR(XS): 8162670: make of jtreg_tests fails if no tests are run, causing jprt test runs to also fail In-Reply-To: <4579a80c-6eb8-27e0-4e0d-cd68e6420df0@oracle.com> References: <8bbb54eb-e179-6c10-5d18-7838f08e847e@oracle.com> <4579a80c-6eb8-27e0-4e0d-cd68e6420df0@oracle.com> Message-ID: <6ac6f874-ce28-bc37-cd0f-575ce45af452@oracle.com> On 2/08/2016 12:11 PM, Chris Plummer wrote: > On 8/1/16 5:58 PM, David Holmes wrote: >> Hi Chris, >> >> On 2/08/2016 8:46 AM, Chris Plummer wrote: >>> Hello, >>> >>> Please review this simple change: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8162670 >>> http://cr.openjdk.java.net/~cjplummer/8162670/webrev-00/ >> >> You've split a compound expression with your code: >> >> 227 jtregExitCode=$$? && \ >> 228 if [ $${jtregExitCode} == 1 ]; then \ >> 229 jtregExitCode=0; \ >> 230 fi ; \ >> 231 _summary="$(SUMMARY_TXT)"; \ >> >> I'm not clear exactly why the && was needed here but rather than find >> out later I suggest rearranging the above to: >> >> jtregExitCode=$$? && \ >> _summary="$(SUMMARY_TXT)"; \ >> if [ $${jtregExitCode} == 1 ]; then \ >> jtregExitCode=0; \ >> fi ; \ >> > Yeah, that makes sense. I'll make the change. However, it's really > unclear what the use case for && is here. How can jtregExitCode=$$? ever > fail? I wonder if it evaluates to the $? value and so only sets _summary if we had a zero exit code? (Not that I understand why we would only set _summary in that context.) David > thanks, > > Chris >> Thanks, >> David >> >>> Note the copyright dates haven't been updated in this webrev, but I did >>> update them locally after noticing that. >>> >>> Tested with jprt test case given in the CR, and also with a jprt run >>> using "testset -hotspot" to make sure I didn't break anything. >>> >>> thanks, >>> >>> Chris > > From chris.plummer at oracle.com Tue Aug 2 04:30:41 2016 From: chris.plummer at oracle.com (Chris Plummer) Date: Mon, 1 Aug 2016 21:30:41 -0700 Subject: RFR(XS): 8162670: make of jtreg_tests fails if no tests are run, causing jprt test runs to also fail In-Reply-To: <6ac6f874-ce28-bc37-cd0f-575ce45af452@oracle.com> References: <8bbb54eb-e179-6c10-5d18-7838f08e847e@oracle.com> <4579a80c-6eb8-27e0-4e0d-cd68e6420df0@oracle.com> <6ac6f874-ce28-bc37-cd0f-575ce45af452@oracle.com> Message-ID: On 8/1/16 7:25 PM, David Holmes wrote: > On 2/08/2016 12:11 PM, Chris Plummer wrote: >> On 8/1/16 5:58 PM, David Holmes wrote: >>> Hi Chris, >>> >>> On 2/08/2016 8:46 AM, Chris Plummer wrote: >>>> Hello, >>>> >>>> Please review this simple change: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8162670 >>>> http://cr.openjdk.java.net/~cjplummer/8162670/webrev-00/ >>> >>> You've split a compound expression with your code: >>> >>> 227 jtregExitCode=$$? && \ >>> 228 if [ $${jtregExitCode} == 1 ]; then \ >>> 229 jtregExitCode=0; \ >>> 230 fi ; \ >>> 231 _summary="$(SUMMARY_TXT)"; \ >>> >>> I'm not clear exactly why the && was needed here but rather than find >>> out later I suggest rearranging the above to: >>> >>> jtregExitCode=$$? && \ >>> _summary="$(SUMMARY_TXT)"; \ >>> if [ $${jtregExitCode} == 1 ]; then \ >>> jtregExitCode=0; \ >>> fi ; \ >>> >> Yeah, that makes sense. I'll make the change. However, it's really >> unclear what the use case for && is here. How can jtregExitCode=$$? ever >> fail? > > I wonder if it evaluates to the $? value and so only sets _summary if > we had a zero exit code? (Not that I understand why we would only set > _summary in that context.) I tried the following: bash-4.1$ x=0 && echo "foo"; And "foo" is always printed. I also tried non-zero values for x. Here are some other examples: bash-4.1$ (exit 1) && echo "foo" bash-4.1$ (exit 0) && echo "foo" foo Commands evaluate to true if the exit status is 0, and false otherwise, so I guess you could say commands evaluate to !?$. For &&, the rhs is only executed if the lhs has a zero exit status. Chris > > David > >> thanks, >> >> Chris >>> Thanks, >>> David >>> >>>> Note the copyright dates haven't been updated in this webrev, but I >>>> did >>>> update them locally after noticing that. >>>> >>>> Tested with jprt test case given in the CR, and also with a jprt run >>>> using "testset -hotspot" to make sure I didn't break anything. >>>> >>>> thanks, >>>> >>>> Chris >> >> From david.holmes at oracle.com Tue Aug 2 07:04:52 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 2 Aug 2016 17:04:52 +1000 Subject: Query: 6422210: _GNU_SOURCE is not the right way to test for gcc Message-ID: <3223804e-68c1-ed2d-0547-ad68619c329d@oracle.com> bug: https://bugs.openjdk.java.net/browse/JDK-6422210 Just wondering if anyone is building on Solaris using gcc? Thanks, David From sean.coffey at oracle.com Tue Aug 2 07:58:25 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 2 Aug 2016 08:58:25 +0100 Subject: [8u] request for approval: "8152172: PPC64: Support AES intrinsics" In-Reply-To: References: Message-ID: <5637bef2-120c-9d3b-80e1-2e2b7a57e78c@oracle.com> Volker, Have the jdk8u hotspot edits been reviewed ? Looks like they should be. Can you add a suitable noreg label to the master bug report also. Regards, Sean. On 29/07/2016 19:58, Volker Simonis wrote: > Ping! > > Can I please have an approval for backporting this change to 8u-dev? > > Thanks, > Volker > > > On Fri, Jul 22, 2016 at 11:08 AM, Volker Simonis > wrote: >> Hi, >> >> could you please approve the backport of the following, mostly ppc64 >> change to jdk8u-dev: >> >> 8152172: PPC64: Support AES intrinsics >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8152172 >> Webrev: http://cr.openjdk.java.net/~simonis/webrevs/2016/8152172_8u_hs/ >> Webrev http://cr.openjdk.java.net/~simonis/webrevs/2016/8152172_8u_jdk/ >> Review: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-March/thread.html#22032 >> URL:http://hg.openjdk.java.net/jdk9/hs-comp/jdk/rev/74bc7be0777b >> URL:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/68394bf0a09f >> >> As you can see, the change consists of two parts - the main one in the >> hotpsot repo and a small part in the jdk repo. >> >> The jdk part applied cleanly to jdk8u (with the usual directory shuffling). >> >> The hotspot part required a small tweak, but only in the ppc-only >> part. This is because the feature detection for the AES instructions >> was already active in jdk9 when the original change was made but is >> not available in jdk8u until now. You can find the additional changes >> at the end of this mail for your convenience. >> >> The required shared changes cleanly apply to jdk8u. >> >> As Vladimir pointed out in a previous thread, shared Hotspot changes >> have to go through JPRT even in jdk8u-dev. So I need a sponsor to do >> that and synchronously push both parts. >> >> @Hiroshii: could you please verify that you are fine with the change? >> I've done some tests on Power8LE but just want to be sure this >> downport satisfies your needs as well. >> >> Thank you and best regards, >> Volker >> >> ===================== >> >> diff -r 15928d255046 src/cpu/ppc/vm/vm_version_ppc.cpp >> --- a/src/cpu/ppc/vm/vm_version_ppc.cpp Wed Jul 13 00:47:40 2016 -0700 >> +++ b/src/cpu/ppc/vm/vm_version_ppc.cpp Fri Jul 22 10:32:36 2016 +0200 >> @@ -452,6 +476,7 @@ >> a->popcntw(R7, R5); // code[7] -> popcntw >> a->fcfids(F3, F4); // code[8] -> fcfids >> a->vand(VR0, VR0, VR0); // code[9] -> vand >> + a->vcipher(VR0, VR1, VR2); // code[10] -> vcipher >> a->blr(); >> >> // Emit function to set one cache line to zero. Emit function >> descriptor and get pointer to it. >> @@ -495,6 +520,7 @@ >> if (code[feature_cntr++]) features |= popcntw_m; >> if (code[feature_cntr++]) features |= fcfids_m; >> if (code[feature_cntr++]) features |= vand_m; >> + if (code[feature_cntr++]) features |= vcipher_m; >> >> // Print the detection code. >> if (PrintAssembly) { >> diff -r 15928d255046 src/cpu/ppc/vm/vm_version_ppc.hpp >> --- a/src/cpu/ppc/vm/vm_version_ppc.hpp Wed Jul 13 00:47:40 2016 -0700 >> +++ b/src/cpu/ppc/vm/vm_version_ppc.hpp Fri Jul 22 10:32:36 2016 +0200 >> @@ -42,6 +42,7 @@ >> fcfids, >> vand, >> dcba, >> + vcipher, >> num_features // last entry to count features >> }; >> enum Feature_Flag_Set { >> @@ -56,6 +57,7 @@ >> fcfids_m = (1 << fcfids ), >> vand_m = (1 << vand ), >> dcba_m = (1 << dcba ), >> + vcipher_m = (1 << vcipher), >> all_features_m = -1 >> }; >> static int _features; >> @@ -83,6 +85,7 @@ >> static bool has_fcfids() { return (_features & fcfids_m) != 0; } >> static bool has_vand() { return (_features & vand_m) != 0; } >> static bool has_dcba() { return (_features & dcba_m) != 0; } >> + static bool has_vcipher() { return (_features & vcipher_m) != 0; } >> >> static const char* cpu_features() { return _features_str; } From sean.coffey at oracle.com Tue Aug 2 10:11:10 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 2 Aug 2016 11:11:10 +0100 Subject: PING: [8u112] Request for review & approval for CR8151841: Build needs additional flags to compile with GCC 6 In-Reply-To: <75eba245-b501-6567-445c-836fa7fc3885@oracle.com> References: <488374967.2958104.1467922862145.JavaMail.zimbra@redhat.com> <577F4C58.6060101@oracle.com> <1053522900.3503496.1468213009871.JavaMail.zimbra@redhat.com> <788404102.5570020.1468596130974.JavaMail.zimbra@redhat.com> <75eba245-b501-6567-445c-836fa7fc3885@oracle.com> Message-ID: I'm seeing this patch fail across all platforms on internal builds. Please hold off any push for now. Maybe other config changes are needed on our build systems. e.g. > /opt/jprt/products/P1/SS12u1/SS12u1/prod/bin/CC \ > -m64 -G -KPIC \ > -I/opt/jprt/T/P1/094712.scoffey/s/hotspot/agent/src/os/solaris/proc \ > -I../generated \ > -I/opt/jprt/products/P1/jdk7u7-latest/jdk1.7.0_07/include \ > -I/opt/jprt/products/P1/jdk7u7-latest/jdk1.7.0_07/include/solaris \ > \ > /opt/jprt/T/P1/094712.scoffey/s/hotspot/agent/src/os/solaris/proc/saproc.cpp \ > sadis.o \ > -M /opt/jprt/T/P1/094712.scoffey/s/hotspot/agent/src/os/solaris/proc/mapfile -mt -xnolib -norunpath \ > -o libsaproc.so \ > -ldl -ldemangle -lthread -lc > ld: fatal: file @NO_DELETE_NULL_POINTER_CHECKS_CFLAG@: open failed: No such file or directory > ld: fatal: file @NO_LIFETIME_DSE_CFLAG@: open failed: No such file or directory > ld: fatal: file @CXXSTD_CXXFLAG@: open failed: No such file or directory > ld: fatal: file processing errors. No output written to libgenerateJvmOffsets.so > gmake[6]: *** [libgenerateJvmOffsets.so] Error 1 > gmake[6]: *** Waiting for unfinished jobs.... > gmake[6]: Leaving directory `/opt/jprt/T/P1/094712.scoffey/s/build/solaris-x86_64-normal-server-release/hotspot/solaris_amd64_compiler2/product' > gmake[5]: *** [the_vm] Error 2 Regards, Sean. On 01/08/2016 12:34, Erik Joelsson wrote: > Looks good now, thanks! > > Sorry for not answering earlier. I just got back from vacation. > > /Erik > > On 2016-07-15 17:22, Andrew Hughes wrote: >> Ping? >> >> ----- Original Message ----- >>> ----- Original Message ----- >>>> Hello, >>>> >>>> It looks like TOOLCHAIN_CXX_COMPILER_CHECK_ARGUMENTS is always >>>> returning >>>> yes and TOOLCHAIN_C_COMPILER_CHECK_ARGUMENTS still does both the C and >>>> C++ checks. >>>> >>> Ugh, merged a block in the wrong place by the looks of it. >>> >>> Fixed in http://cr.openjdk.java.net/~andrew/8u/8151841/webrev.02/ >>> >>> configure:29739: checking if the C++ compiler supports "-std=gnu++98 " >>> configure:29755: /usr/bin/g++ -c -std=gnu++98 conftest.cpp >&5 >>> configure:29755: $? = 0 >>> configure:29769: result: yes >>> configure:29815: checking if the C compiler supports >>> "-fno-delete-null-pointer-checks -Werror" >>> configure:29832: /usr/bin/gcc -c -fno-delete-null-pointer-checks >>> -Werror >>> conftest.c >&5 >>> configure:29832: $? = 0 >>> configure:29846: result: yes >>> configure:29855: checking if the C++ compiler supports >>> "-fno-delete-null-pointer-checks -Werror" >>> configure:29871: /usr/bin/g++ -c -fno-delete-null-pointer-checks >>> -Werror >>> conftest.cpp >&5 >>> configure:29871: $? = 0 >>> configure:29885: result: yes >>> configure:29894: checking if both compilers support >>> "-fno-delete-null-pointer-checks -Werror" >>> configure:29899: result: yes >>> configure:29911: checking if the C compiler supports "-fno-lifetime-dse >>> -Werror" >>> configure:29927: /usr/bin/gcc -c -fno-lifetime-dse -Werror >>> conftest.c >&5 >>> configure:29927: $? = 0 >>> configure:29941: result: yes >>> configure:29950: checking if the C++ compiler supports >>> "-fno-lifetime-dse >>> -Werror" >>> configure:29966: /usr/bin/g++ -c -fno-lifetime-dse -Werror >>> conftest.cpp >&5 >>> configure:29966: $? = 0 >>> configure:29980: result: yes >>> configure:29989: checking if both compilers support "-fno-lifetime-dse >>> -Werror" >>> configure:29994: result: yes >>> >>> >>>> /Erik >>>> >>>> On 2016-07-07 22:21, Andrew Hughes wrote: >>>>> Webrev: http://cr.openjdk.java.net/~andrew/8u/8151841/webrev.01/ >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8151841 >>>>> >>>>> This is a backport of the original fix to support building OpenJDK >>>>> with GCC 6. It was necessary to cherry-pick parts of a number of >>>>> earlier fixes to make this work with the build system in 8: >>>>> >>>>> 8149647: Incremental enhancements from build-infra >>>>> 8032045: Enable compiler and linker safety switches for debug builds >>>>> >>>>> and so I'm requesting a review of the 8 version of the patch here >>>>> as well >>>>> as approval for 8u. >>>>> >>>>> In brief, the patch makes OpenJDK build with GCC 6 by explicitly >>>>> specifying >>>>> the C++ standard to use (-std=gnu++98) and disabling two >>>>> optimisations >>>>> with >>>>> -fno-lifetime-dse and -fno-delete-null-pointer-checks. Further >>>>> information >>>>> on the changes is available in the GCC 6 release notes [0]. GCC 6 >>>>> uses >>>>> a newer C++ standard, C++14, with which the OpenJDK codebase is >>>>> not yet >>>>> compliant. The simplest way to fix this, especially for existing >>>>> releases, >>>>> is to explicitly request the previous default, gnu++98. The deletion >>>>> of null pointer checks and more aggressive lifetime dead store >>>>> elimination >>>>> in 6 lead to a crashing virtual machine being built, so we disable >>>>> them >>>>> if GCC >= 6 is used. >>>>> >>>>> To make the original patch work with 8u, a number of changes from >>>>> other >>>>> fixes had to also be brought over: >>>>> >>>>> * We need to check we are using GCC 6 or above, so we need to bring >>>>> over the TOOLCHAIN_CHECK_COMPILER_VERSION and >>>>> TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS macros from 8149647. >>>>> TOOLCHAIN_CHECK_COMPILER_VERSION is converted back to a traditional >>>>> numbered rather than named argument macro so we don't need to >>>>> backport >>>>> BASIC_DEFUN_NAMED. >>>>> * We bring over the introduction of COMMON_CCXXFLAGS_JDK from 8030245 >>>>> as we need to apply the -std option only to the C++ compiler, not the >>>>> C compiler. If passed to the C compiler, it will produce a warning, >>>>> and this is converted to an error at one point in the build >>>>> (a -Werror in libsctp). >>>>> >>>>> Generally, we've kept things in toolchain.m4 (8034788 introduced >>>>> flags.m4, >>>>> separating out some code, and so many of these changes are in that >>>>> file >>>>> in 9) and avoid named argument macros. Otherwise, it's largely the >>>>> same as the 9 version. We have adopted the longer name for >>>>> the -fno-delete-null-pointer-checks flag variable as suggested in the >>>>> review of the update to this patch for the new HotSpot build [1]. >>>>> >>>>> [0] https://gcc.gnu.org/gcc-6/porting_to.html >>>>> [1] >>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-July/023840.html >>>>> >>>> >>> -- >>> Andrew :) >>> >>> Senior Free Java Software Engineer >>> Red Hat, Inc. (http://www.redhat.com) >>> >>> PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) >>> Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 >>> >>> >>> > From markus.gronlund at oracle.com Tue Aug 2 10:17:02 2016 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Tue, 2 Aug 2016 03:17:02 -0700 (PDT) Subject: RFR 8159284: bigapps/Jetty - assert(jfa->last_Java_sp() > sp()) failed with tracing code in use In-Reply-To: References: Message-ID: Hi Coleen, Thanks for addressing this. The refactoring and the sp verification added looks good. Nit: You might want to consider changing (jcw <= thread->stack_base()) to instead read (jcw < thread->stack_base()) . Reason for this is that on Windows, thread->stack_base() is unmapped. No need for an updated webrev. Thanks Markus -----Original Message----- From: Coleen Phillimore Sent: den 2 augusti 2016 01:39 To: hotspot-dev developers Subject: RFR 8159284: bigapps/Jetty - assert(jfa->last_Java_sp() > sp()) failed with tracing code in use Summary: Test condition in assert in frame::safe_for_sender() for entry frames and return false. This bug is for a confidential part of the project that needs more robustness checks to verify that frame::sender() can be called. Also refactored into frame::entry_frame_is_safe() because these platforms had the same code for entry frames to determine whether it is still safe to trust this frame to call sender(). These platforms had also the same assert in sender_for_entry_frame() that the sampling code hit. Tested with our nightly tests on all platforms and bigapps/Jetty. open webrev at http://cr.openjdk.java.net/~coleenp/8159284.01/webrev Thanks, Coleen From sean.coffey at oracle.com Tue Aug 2 11:21:18 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 2 Aug 2016 12:21:18 +0100 Subject: PING: [8u112] Request for review & approval for CR8151841: Build needs additional flags to compile with GCC 6 In-Reply-To: References: <488374967.2958104.1467922862145.JavaMail.zimbra@redhat.com> <577F4C58.6060101@oracle.com> <1053522900.3503496.1468213009871.JavaMail.zimbra@redhat.com> <788404102.5570020.1468596130974.JavaMail.zimbra@redhat.com> <75eba245-b501-6567-445c-836fa7fc3885@oracle.com> Message-ID: <2204d04d-4e7d-6d47-dc6b-398bac5506b1@oracle.com> Andrew, there are some non-OpenJDK related changes that I need to make at time of this push. Is it OK if I push this patch to jdk8u-dev for you ? Approved for jdk8u-dev. Regards, Sean. On 02/08/2016 11:11, Se?n Coffey wrote: > > I'm seeing this patch fail across all platforms on internal builds. > Please hold off any push for now. Maybe other config changes are > needed on our build systems. > > e.g. > >> /opt/jprt/products/P1/SS12u1/SS12u1/prod/bin/CC \ >> -m64 -G -KPIC \ >> -I/opt/jprt/T/P1/094712.scoffey/s/hotspot/agent/src/os/solaris/proc \ >> -I../generated \ >> -I/opt/jprt/products/P1/jdk7u7-latest/jdk1.7.0_07/include \ >> -I/opt/jprt/products/P1/jdk7u7-latest/jdk1.7.0_07/include/solaris \ >> \ >> /opt/jprt/T/P1/094712.scoffey/s/hotspot/agent/src/os/solaris/proc/saproc.cpp \ >> sadis.o \ >> -M /opt/jprt/T/P1/094712.scoffey/s/hotspot/agent/src/os/solaris/proc/mapfile -mt -xnolib -norunpath \ >> -o libsaproc.so \ >> -ldl -ldemangle -lthread -lc >> ld: fatal: file @NO_DELETE_NULL_POINTER_CHECKS_CFLAG@: open failed: No such file or directory >> ld: fatal: file @NO_LIFETIME_DSE_CFLAG@: open failed: No such file or directory >> ld: fatal: file @CXXSTD_CXXFLAG@: open failed: No such file or directory >> ld: fatal: file processing errors. No output written to libgenerateJvmOffsets.so >> gmake[6]: *** [libgenerateJvmOffsets.so] Error 1 >> gmake[6]: *** Waiting for unfinished jobs.... >> gmake[6]: Leaving directory `/opt/jprt/T/P1/094712.scoffey/s/build/solaris-x86_64-normal-server-release/hotspot/solaris_amd64_compiler2/product' >> gmake[5]: *** [the_vm] Error 2 > > Regards, > Sean. > On 01/08/2016 12:34, Erik Joelsson wrote: >> Looks good now, thanks! >> >> Sorry for not answering earlier. I just got back from vacation. >> >> /Erik >> >> On 2016-07-15 17:22, Andrew Hughes wrote: >>> Ping? >>> >>> ----- Original Message ----- >>>> ----- Original Message ----- >>>>> Hello, >>>>> >>>>> It looks like TOOLCHAIN_CXX_COMPILER_CHECK_ARGUMENTS is always >>>>> returning >>>>> yes and TOOLCHAIN_C_COMPILER_CHECK_ARGUMENTS still does both the C >>>>> and >>>>> C++ checks. >>>>> >>>> Ugh, merged a block in the wrong place by the looks of it. >>>> >>>> Fixed in http://cr.openjdk.java.net/~andrew/8u/8151841/webrev.02/ >>>> >>>> configure:29739: checking if the C++ compiler supports "-std=gnu++98 " >>>> configure:29755: /usr/bin/g++ -c -std=gnu++98 conftest.cpp >&5 >>>> configure:29755: $? = 0 >>>> configure:29769: result: yes >>>> configure:29815: checking if the C compiler supports >>>> "-fno-delete-null-pointer-checks -Werror" >>>> configure:29832: /usr/bin/gcc -c -fno-delete-null-pointer-checks >>>> -Werror >>>> conftest.c >&5 >>>> configure:29832: $? = 0 >>>> configure:29846: result: yes >>>> configure:29855: checking if the C++ compiler supports >>>> "-fno-delete-null-pointer-checks -Werror" >>>> configure:29871: /usr/bin/g++ -c -fno-delete-null-pointer-checks >>>> -Werror >>>> conftest.cpp >&5 >>>> configure:29871: $? = 0 >>>> configure:29885: result: yes >>>> configure:29894: checking if both compilers support >>>> "-fno-delete-null-pointer-checks -Werror" >>>> configure:29899: result: yes >>>> configure:29911: checking if the C compiler supports >>>> "-fno-lifetime-dse >>>> -Werror" >>>> configure:29927: /usr/bin/gcc -c -fno-lifetime-dse -Werror >>>> conftest.c >&5 >>>> configure:29927: $? = 0 >>>> configure:29941: result: yes >>>> configure:29950: checking if the C++ compiler supports >>>> "-fno-lifetime-dse >>>> -Werror" >>>> configure:29966: /usr/bin/g++ -c -fno-lifetime-dse -Werror >>>> conftest.cpp >&5 >>>> configure:29966: $? = 0 >>>> configure:29980: result: yes >>>> configure:29989: checking if both compilers support "-fno-lifetime-dse >>>> -Werror" >>>> configure:29994: result: yes >>>> >>>> >>>>> /Erik >>>>> >>>>> On 2016-07-07 22:21, Andrew Hughes wrote: >>>>>> Webrev: http://cr.openjdk.java.net/~andrew/8u/8151841/webrev.01/ >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8151841 >>>>>> >>>>>> This is a backport of the original fix to support building OpenJDK >>>>>> with GCC 6. It was necessary to cherry-pick parts of a number of >>>>>> earlier fixes to make this work with the build system in 8: >>>>>> >>>>>> 8149647: Incremental enhancements from build-infra >>>>>> 8032045: Enable compiler and linker safety switches for debug builds >>>>>> >>>>>> and so I'm requesting a review of the 8 version of the patch here >>>>>> as well >>>>>> as approval for 8u. >>>>>> >>>>>> In brief, the patch makes OpenJDK build with GCC 6 by explicitly >>>>>> specifying >>>>>> the C++ standard to use (-std=gnu++98) and disabling two >>>>>> optimisations >>>>>> with >>>>>> -fno-lifetime-dse and -fno-delete-null-pointer-checks. Further >>>>>> information >>>>>> on the changes is available in the GCC 6 release notes [0]. GCC 6 >>>>>> uses >>>>>> a newer C++ standard, C++14, with which the OpenJDK codebase is >>>>>> not yet >>>>>> compliant. The simplest way to fix this, especially for existing >>>>>> releases, >>>>>> is to explicitly request the previous default, gnu++98. The deletion >>>>>> of null pointer checks and more aggressive lifetime dead store >>>>>> elimination >>>>>> in 6 lead to a crashing virtual machine being built, so we >>>>>> disable them >>>>>> if GCC >= 6 is used. >>>>>> >>>>>> To make the original patch work with 8u, a number of changes from >>>>>> other >>>>>> fixes had to also be brought over: >>>>>> >>>>>> * We need to check we are using GCC 6 or above, so we need to bring >>>>>> over the TOOLCHAIN_CHECK_COMPILER_VERSION and >>>>>> TOOLCHAIN_PREPARE_FOR_VERSION_COMPARISONS macros from 8149647. >>>>>> TOOLCHAIN_CHECK_COMPILER_VERSION is converted back to a traditional >>>>>> numbered rather than named argument macro so we don't need to >>>>>> backport >>>>>> BASIC_DEFUN_NAMED. >>>>>> * We bring over the introduction of COMMON_CCXXFLAGS_JDK from >>>>>> 8030245 >>>>>> as we need to apply the -std option only to the C++ compiler, not >>>>>> the >>>>>> C compiler. If passed to the C compiler, it will produce a warning, >>>>>> and this is converted to an error at one point in the build >>>>>> (a -Werror in libsctp). >>>>>> >>>>>> Generally, we've kept things in toolchain.m4 (8034788 introduced >>>>>> flags.m4, >>>>>> separating out some code, and so many of these changes are in >>>>>> that file >>>>>> in 9) and avoid named argument macros. Otherwise, it's largely the >>>>>> same as the 9 version. We have adopted the longer name for >>>>>> the -fno-delete-null-pointer-checks flag variable as suggested in >>>>>> the >>>>>> review of the update to this patch for the new HotSpot build [1]. >>>>>> >>>>>> [0] https://gcc.gnu.org/gcc-6/porting_to.html >>>>>> [1] >>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-July/023840.html >>>>>> >>>>> >>>> -- >>>> Andrew :) >>>> >>>> Senior Free Java Software Engineer >>>> Red Hat, Inc. (http://www.redhat.com) >>>> >>>> PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) >>>> Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 >>>> >>>> >>>> >> > From peter.levart at gmail.com Tue Aug 2 12:55:20 2016 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 2 Aug 2016 14:55:20 +0200 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: References: <88A2872D-70F9-48DB-94B1-4314B3D9D217@oracle.com> <3933D052-50B2-43F1-AA20-2E75F60B61CE@oracle.com> <764F8C8B-AFE6-4A3F-8C0D-3D24F72CED58@oracle.com> Message-ID: Hi Kim, This looks very good. I like the way you dealt with race between the ReferenceHandler thread and threads waiting for it to do some cleanup progress. I think the VM API is suitable for possible further development on JDK-8149925. It's also nice that the whole pending list is obtained in one native call, so further optimizations on Java side are possible. Regards, Peter On 08/01/2016 08:47 PM, Kim Barrett wrote: > This updated webrev addresses concerns about the performance of the VM > API used by the reference processor thread in the original webrev. > > New webrevs: > full: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.03/ > http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.03/ > incr: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.03.incr/ > http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.03.incr/ > > The originally offered approach was an attempt to minimize changes. I > was trying to be as similar to the existing code as possible, while > moving part of it into the VM, where we have the necessary control > over suspension and the like. We already know we want to make changes > in this area, in order to eliminate the use of > jdk.internal.ref.Cleaner (JDK-8149925). But we've also agreed that > JDK-8149925 wasn't urgent and to defer it to JDK 10. I don't think we > should revisit that. > > As Peter pointed out, my original change introduces a small > performance regression on a microbenchmark for reference processing > throughput. It also showed a small performance benefit on a different > microbenchmark (allocation rate for a stress test of direct byte > buffers), as noted in the original RFR. I can reproduce both of > those. > > I think reference processing thread throughput is the right measure to > use, so long as others don't become horrible. Focusing on that, it's > better to just let the reference processing thread do the processing, > rather than slowing it down to allow for the rare case when there's > another thread that could possibly help. This is especially true now > that Cleaner has such limited usage. > > This leads to a different API for other threads; rather than > tryHandlePending that other threads can call to help and to examine > progress, we now have waitForReferenceProcessing. The VM API is also > different; rather than popReferencePendingList to get or wait, we now > have getAndClearReferencePendingList and checkReferencePendingList, > the latter with an optional wait. > > The splitting of the VM API allows us to avoid a narrow race condition > discussed by Peter in his prototypes. Peter suggested this race was > ok because java.nio.Bits makes several retries. However, those > retries are only done before throwing OOME. There are no retries > before invoking GC, so this race could lead to unnecessary successive > GCs. > > Doing all the processing on the reference processing thread eliminates > execution of Cleaners on application threads, though that's not nearly > as much an issue now that the use of Cleaner is so restricted. > > We've also eliminated a pre-existing issue where a helper could report > no progress even though the reference processing thread (and other > helpers) had removed a pending reference, but not yet processed it. > This could result in the non-progressing helper invoking GC or > reporting failure, even though it might have succeeded if it had > waited for the other thread(s) to complete processing the reference(s) > being worked on. > > I think the new waitForReferenceProcessing could be used to fix > JDK-6306116, though that isn't part of this change, and was not really > a motivating factor. > > I don't know if the new waitForReferenceProcessing will be used by > whatever we eventually do for JDK-8149925, but I think the new VM API > will suffice for that. That is, I think JDK-8149925 might require > changes to the core-libs API used by nio.Bits, and won't require > further VM API changes. > > > From stefan.anzinger at oracle.com Tue Aug 2 14:07:01 2016 From: stefan.anzinger at oracle.com (Stefan Anzinger) Date: Tue, 2 Aug 2016 14:07:01 +0000 Subject: RFR: 8161550: [JVMCI] Crash: assert(sig_bt[member_arg_pos] == T_OBJECT) Message-ID: <229e1052-ac4a-148d-028b-1a0674e6b517@oracle.com> Hello, this RFR fixes 8161550. JVMCI must not return intrinsified MethodHandle methods. The test had to be updated and the shortcut evaluation in HotSpotResolvedObjectTypeImpl.resolveMethod needs take care of this fact. http://cr.openjdk.java.net/~sanzinger/8161550/webrev.00/ Stefan From chris.plummer at oracle.com Tue Aug 2 14:40:48 2016 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 2 Aug 2016 07:40:48 -0700 Subject: RFR 8159284: bigapps/Jetty - assert(jfa->last_Java_sp() > sp()) failed with tracing code in use In-Reply-To: References: <7e666611-eac2-3f7b-70b5-942fb68f9e39@oracle.com> Message-ID: os::is_first_C_frame() is used by print_native_stack() and os::get_native_stack() (NMT) to sanity check the frame walking. Chris On 8/1/16 6:39 PM, dean.long at oracle.com wrote: > Upon a closer look, it appears that the backtraces we get for a crash > come from print_native_stack() in debug.cpp, and that code uses a > slightly different algorithm, so your changes shouldn't affect it. > > dl > > > On 8/1/16 6:11 PM, dean.long at oracle.com wrote: >> Hi Coleen. If I understand correctly, previously we would get >> backtraces that end with the first C frame: >> >> [...] >> J 3335 C1 java.lang.Thread.run()V java.base at 9-ea (17 bytes) @ >> 0xe7fdc480 [0xe7fdc420+0x00000060] >> v ~StubRoutines::call_stub >> V [libjvm.so+0x66fe39] JavaCalls::call_helper(JavaValue*, >> methodHandle const&, JavaCallArguments*, Thread*)+0x2b9 >> V [libjvm.so+0x931669] os::os_exception_wrapper(void >> (*)(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*), >> JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x19 >> V [libjvm.so+0x66eb2b] JavaCalls::call_virtual(JavaValue*, Handle, >> KlassHandle, Symbol*, Symbol*, Thread*)+0x13b >> V [libjvm.so+0x708069] thread_entry(JavaThread*, Thread*)+0x89 >> V [libjvm.so+0xaa5434] JavaThread::thread_main_inner()+0xf4 >> V [libjvm.so+0xaa5589] JavaThread::run()+0x119 >> V [libjvm.so+0x933cdc] thread_native_entry(Thread*)+0x10c >> C [libpthread.so.0+0x6bc9] >> C [libc.so.6+0xe2c9e] clone+0x5e >> >> >> but now with your change, won't all backtraces end on the last Java >> frame? So the above backtrace would be truncated to: >> >> [...] >> J 3335 C1 java.lang.Thread.run()V java.base at 9-ea (17 bytes) @ >> 0xe7fdc480 [0xe7fdc420+0x00000060] >> >> >> dl >> >> On 8/1/16 4:38 PM, Coleen Phillimore wrote: >>> Summary: Test condition in assert in frame::safe_for_sender() for >>> entry frames and return false. >>> >>> This bug is for a confidential part of the project that needs more >>> robustness checks to verify that frame::sender() can be called. >>> >>> Also refactored into frame::entry_frame_is_safe() because these >>> platforms had the same code for entry frames to determine whether it >>> is still safe to trust this frame to call sender(). These platforms >>> had also the same assert in sender_for_entry_frame() that the >>> sampling code hit. >>> >>> Tested with our nightly tests on all platforms and bigapps/Jetty. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8159284.01/webrev >>> >>> Thanks, >>> Coleen >>> >> > From chris.plummer at oracle.com Tue Aug 2 14:50:30 2016 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 2 Aug 2016 07:50:30 -0700 Subject: RFR(XS): 8162670: make of jtreg_tests fails if no tests are run, causing jprt test runs to also fail In-Reply-To: References: <8bbb54eb-e179-6c10-5d18-7838f08e847e@oracle.com> <4579a80c-6eb8-27e0-4e0d-cd68e6420df0@oracle.com> <6ac6f874-ce28-bc37-cd0f-575ce45af452@oracle.com> Message-ID: On 8/1/16 9:30 PM, Chris Plummer wrote: > On 8/1/16 7:25 PM, David Holmes wrote: >> On 2/08/2016 12:11 PM, Chris Plummer wrote: >>> On 8/1/16 5:58 PM, David Holmes wrote: >>>> Hi Chris, >>>> >>>> On 2/08/2016 8:46 AM, Chris Plummer wrote: >>>>> Hello, >>>>> >>>>> Please review this simple change: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8162670 >>>>> http://cr.openjdk.java.net/~cjplummer/8162670/webrev-00/ >>>> >>>> You've split a compound expression with your code: >>>> >>>> 227 jtregExitCode=$$? && \ >>>> 228 if [ $${jtregExitCode} == 1 ]; then \ >>>> 229 jtregExitCode=0; \ >>>> 230 fi ; \ >>>> 231 _summary="$(SUMMARY_TXT)"; \ >>>> >>>> I'm not clear exactly why the && was needed here but rather than find >>>> out later I suggest rearranging the above to: >>>> >>>> jtregExitCode=$$? && \ >>>> _summary="$(SUMMARY_TXT)"; \ >>>> if [ $${jtregExitCode} == 1 ]; then \ >>>> jtregExitCode=0; \ >>>> fi ; \ >>>> >>> Yeah, that makes sense. I'll make the change. However, it's really >>> unclear what the use case for && is here. How can jtregExitCode=$$? >>> ever >>> fail? >> >> I wonder if it evaluates to the $? value and so only sets _summary if >> we had a zero exit code? (Not that I understand why we would only set >> _summary in that context.) > I tried the following: > > bash-4.1$ x=0 && echo "foo"; > > And "foo" is always printed. I also tried non-zero values for x. Here > are some other examples: > > bash-4.1$ (exit 1) && echo "foo" > bash-4.1$ (exit 0) && echo "foo" > foo > > Commands evaluate to true if the exit status is 0, and false > otherwise, so I guess you could say commands evaluate to !?$. For &&, > the rhs is only executed if the lhs has a zero exit status. Updated webrev: http://cr.openjdk.java.net/~cjplummer/8162670/webrev-01/ thanks, Chris > > Chris >> >> David >> >>> thanks, >>> >>> Chris >>>> Thanks, >>>> David >>>> >>>>> Note the copyright dates haven't been updated in this webrev, but >>>>> I did >>>>> update them locally after noticing that. >>>>> >>>>> Tested with jprt test case given in the CR, and also with a jprt run >>>>> using "testset -hotspot" to make sure I didn't break anything. >>>>> >>>>> thanks, >>>>> >>>>> Chris >>> >>> > From coleen.phillimore at oracle.com Tue Aug 2 14:51:43 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 2 Aug 2016 10:51:43 -0400 Subject: RFR 8159284: bigapps/Jetty - assert(jfa->last_Java_sp() > sp()) failed with tracing code in use In-Reply-To: References: <7e666611-eac2-3f7b-70b5-942fb68f9e39@oracle.com> Message-ID: On 8/1/16 9:39 PM, dean.long at oracle.com wrote: > Upon a closer look, it appears that the backtraces we get for a crash > come from print_native_stack() in debug.cpp, and that code uses a > slightly different algorithm, so your changes shouldn't affect it. yes, it shouldn't affect it. It's basically moving the condition in the assert from sender_for_entry_frame() into safe_for_sender by way of a entry_frame_is_safe() function where I consolidated the duplicated code. The stack traces in vframeStream don't call safe_for_sender(), it's only used for profiling ie. AsyncGetCallTrace, where it may not be safe. Unless there's a call path I don't see. Thanks, Coleen > > dl > > > On 8/1/16 6:11 PM, dean.long at oracle.com wrote: >> Hi Coleen. If I understand correctly, previously we would get >> backtraces that end with the first C frame: >> >> [...] >> J 3335 C1 java.lang.Thread.run()V java.base at 9-ea (17 bytes) @ >> 0xe7fdc480 [0xe7fdc420+0x00000060] >> v ~StubRoutines::call_stub >> V [libjvm.so+0x66fe39] JavaCalls::call_helper(JavaValue*, >> methodHandle const&, JavaCallArguments*, Thread*)+0x2b9 >> V [libjvm.so+0x931669] os::os_exception_wrapper(void >> (*)(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*), >> JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x19 >> V [libjvm.so+0x66eb2b] JavaCalls::call_virtual(JavaValue*, Handle, >> KlassHandle, Symbol*, Symbol*, Thread*)+0x13b >> V [libjvm.so+0x708069] thread_entry(JavaThread*, Thread*)+0x89 >> V [libjvm.so+0xaa5434] JavaThread::thread_main_inner()+0xf4 >> V [libjvm.so+0xaa5589] JavaThread::run()+0x119 >> V [libjvm.so+0x933cdc] thread_native_entry(Thread*)+0x10c >> C [libpthread.so.0+0x6bc9] >> C [libc.so.6+0xe2c9e] clone+0x5e >> >> >> but now with your change, won't all backtraces end on the last Java >> frame? So the above backtrace would be truncated to: >> >> [...] >> J 3335 C1 java.lang.Thread.run()V java.base at 9-ea (17 bytes) @ >> 0xe7fdc480 [0xe7fdc420+0x00000060] >> >> >> dl >> >> On 8/1/16 4:38 PM, Coleen Phillimore wrote: >>> Summary: Test condition in assert in frame::safe_for_sender() for >>> entry frames and return false. >>> >>> This bug is for a confidential part of the project that needs more >>> robustness checks to verify that frame::sender() can be called. >>> >>> Also refactored into frame::entry_frame_is_safe() because these >>> platforms had the same code for entry frames to determine whether it >>> is still safe to trust this frame to call sender(). These platforms >>> had also the same assert in sender_for_entry_frame() that the >>> sampling code hit. >>> >>> Tested with our nightly tests on all platforms and bigapps/Jetty. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8159284.01/webrev >>> >>> Thanks, >>> Coleen >>> >> > From coleen.phillimore at oracle.com Tue Aug 2 15:00:53 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 2 Aug 2016 11:00:53 -0400 Subject: RFR 8159284: bigapps/Jetty - assert(jfa->last_Java_sp() > sp()) failed with tracing code in use In-Reply-To: References: Message-ID: <2f43cd6d-9dfe-59c9-74e4-4257e7c93e27@oracle.com> Hi Markus, Thank you for the code review. On 8/2/16 6:17 AM, Markus Gronlund wrote: > Hi Coleen, > > Thanks for addressing this. The refactoring and the sp verification added looks good. > > Nit: > > You might want to consider changing (jcw <= thread->stack_base()) to instead read (jcw < thread->stack_base()) . Reason for this is that on Windows, thread->stack_base() is unmapped. No need for an updated webrev. I'll make this change as you suggest. Thanks, Coleen > > Thanks > Markus > > -----Original Message----- > From: Coleen Phillimore > Sent: den 2 augusti 2016 01:39 > To: hotspot-dev developers > Subject: RFR 8159284: bigapps/Jetty - assert(jfa->last_Java_sp() > sp()) failed with tracing code in use > > Summary: Test condition in assert in frame::safe_for_sender() for entry frames and return false. > > This bug is for a confidential part of the project that needs more robustness checks to verify that frame::sender() can be called. > > Also refactored into frame::entry_frame_is_safe() because these platforms had the same code for entry frames to determine whether it is still safe to trust this frame to call sender(). These platforms had also the same assert in sender_for_entry_frame() that the sampling code hit. > > Tested with our nightly tests on all platforms and bigapps/Jetty. > > open webrev at http://cr.openjdk.java.net/~coleenp/8159284.01/webrev > > Thanks, > Coleen > From coleen.phillimore at oracle.com Tue Aug 2 15:08:13 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 2 Aug 2016 11:08:13 -0400 Subject: RFR 8159284: bigapps/Jetty - assert(jfa->last_Java_sp() > sp()) failed with tracing code in use In-Reply-To: References: <7e666611-eac2-3f7b-70b5-942fb68f9e39@oracle.com> Message-ID: On 8/2/16 10:40 AM, Chris Plummer wrote: > os::is_first_C_frame() is used by print_native_stack() and > os::get_native_stack() (NMT) to sanity check the frame walking. Yes, this uses a different algorithm for native frame walking even though some of the names of the functions are similar. Coleen > > Chris > > On 8/1/16 6:39 PM, dean.long at oracle.com wrote: >> Upon a closer look, it appears that the backtraces we get for a crash >> come from print_native_stack() in debug.cpp, and that code uses a >> slightly different algorithm, so your changes shouldn't affect it. >> >> dl >> >> >> On 8/1/16 6:11 PM, dean.long at oracle.com wrote: >>> Hi Coleen. If I understand correctly, previously we would get >>> backtraces that end with the first C frame: >>> >>> [...] >>> J 3335 C1 java.lang.Thread.run()V java.base at 9-ea (17 bytes) @ >>> 0xe7fdc480 [0xe7fdc420+0x00000060] >>> v ~StubRoutines::call_stub >>> V [libjvm.so+0x66fe39] JavaCalls::call_helper(JavaValue*, >>> methodHandle const&, JavaCallArguments*, Thread*)+0x2b9 >>> V [libjvm.so+0x931669] os::os_exception_wrapper(void >>> (*)(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*), >>> JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x19 >>> V [libjvm.so+0x66eb2b] JavaCalls::call_virtual(JavaValue*, Handle, >>> KlassHandle, Symbol*, Symbol*, Thread*)+0x13b >>> V [libjvm.so+0x708069] thread_entry(JavaThread*, Thread*)+0x89 >>> V [libjvm.so+0xaa5434] JavaThread::thread_main_inner()+0xf4 >>> V [libjvm.so+0xaa5589] JavaThread::run()+0x119 >>> V [libjvm.so+0x933cdc] thread_native_entry(Thread*)+0x10c >>> C [libpthread.so.0+0x6bc9] >>> C [libc.so.6+0xe2c9e] clone+0x5e >>> >>> >>> but now with your change, won't all backtraces end on the last Java >>> frame? So the above backtrace would be truncated to: >>> >>> [...] >>> J 3335 C1 java.lang.Thread.run()V java.base at 9-ea (17 bytes) @ >>> 0xe7fdc480 [0xe7fdc420+0x00000060] >>> >>> >>> dl >>> >>> On 8/1/16 4:38 PM, Coleen Phillimore wrote: >>>> Summary: Test condition in assert in frame::safe_for_sender() for >>>> entry frames and return false. >>>> >>>> This bug is for a confidential part of the project that needs more >>>> robustness checks to verify that frame::sender() can be called. >>>> >>>> Also refactored into frame::entry_frame_is_safe() because these >>>> platforms had the same code for entry frames to determine whether >>>> it is still safe to trust this frame to call sender(). These >>>> platforms had also the same assert in sender_for_entry_frame() that >>>> the sampling code hit. >>>> >>>> Tested with our nightly tests on all platforms and bigapps/Jetty. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8159284.01/webrev >>>> >>>> Thanks, >>>> Coleen >>>> >>> >> > From frederic.parain at oracle.com Tue Aug 2 18:02:38 2016 From: frederic.parain at oracle.com (Frederic Parain) Date: Tue, 2 Aug 2016 14:02:38 -0400 Subject: RFR 8159284: bigapps/Jetty - assert(jfa->last_Java_sp() > sp()) failed with tracing code in use In-Reply-To: References: Message-ID: Coleen, src/cpu/aarch64/vm/frame_aarch64.cpp line 116: return entry_frame_is_safe(thread); line 207: return sender.is_entry_frame_safe(thread); Method names are different, is it a typo? src/cpu/sparc/vm/frame_sparc.cpp No comments src/cpu/x86/vm/frame_x86.cpp No comments src/share/vm/runtime/frame.cpp No comments src/share/vm/runtime/frame.hpp I would expect the new method name to be is_entry_frame_safe() as most tester methods begin with "is_" but I this is just a personal opinion. Fred On 08/01/2016 07:38 PM, Coleen Phillimore wrote: > Summary: Test condition in assert in frame::safe_for_sender() for entry > frames and return false. > > This bug is for a confidential part of the project that needs more > robustness checks to verify that frame::sender() can be called. > > Also refactored into frame::entry_frame_is_safe() because these > platforms had the same code for entry frames to determine whether it is > still safe to trust this frame to call sender(). These platforms had > also the same assert in sender_for_entry_frame() that the sampling code > hit. > > Tested with our nightly tests on all platforms and bigapps/Jetty. > > open webrev at http://cr.openjdk.java.net/~coleenp/8159284.01/webrev > > Thanks, > Coleen > From coleen.phillimore at oracle.com Tue Aug 2 18:22:42 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 2 Aug 2016 14:22:42 -0400 Subject: RFR 8159284: bigapps/Jetty - assert(jfa->last_Java_sp() > sp()) failed with tracing code in use In-Reply-To: References: Message-ID: Fred, Thank you for reviewing this. On 8/2/16 2:02 PM, Frederic Parain wrote: > Coleen, > > src/cpu/aarch64/vm/frame_aarch64.cpp > > line 116: return entry_frame_is_safe(thread); > line 207: return sender.is_entry_frame_safe(thread); > > Method names are different, is it a typo? > Yes, it is a typo. Thank you for catching it. > src/cpu/sparc/vm/frame_sparc.cpp > > No comments > > src/cpu/x86/vm/frame_x86.cpp > > No comments > > src/share/vm/runtime/frame.cpp > > No comments > > src/share/vm/runtime/frame.hpp > > I would expect the new method name to be is_entry_frame_safe() > as most tester methods begin with "is_" but I this is just a > personal opinion. I named it entry_frame_is_safe() because I thought it looked less redundant and more distinct in the code fragments where they occurred: // Entry frame checks if (is_entry_frame()) { // an entry frame must have a valid fp. if (!fp_safe) return false; return entry_frame_is_safe(thread); } is_entry_frame_safe() looks like is_entry_frame() or implies it's a "safe" call to is_entry_frame. I guess it is the standard to start with 'is' for these sorts of tests. How about is_safe_entry_frame() ? thanks, Coleen > > Fred > > On 08/01/2016 07:38 PM, Coleen Phillimore wrote: >> Summary: Test condition in assert in frame::safe_for_sender() for entry >> frames and return false. >> >> This bug is for a confidential part of the project that needs more >> robustness checks to verify that frame::sender() can be called. >> >> Also refactored into frame::entry_frame_is_safe() because these >> platforms had the same code for entry frames to determine whether it is >> still safe to trust this frame to call sender(). These platforms had >> also the same assert in sender_for_entry_frame() that the sampling code >> hit. >> >> Tested with our nightly tests on all platforms and bigapps/Jetty. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8159284.01/webrev >> >> Thanks, >> Coleen >> From coleen.phillimore at oracle.com Tue Aug 2 18:25:32 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 2 Aug 2016 14:25:32 -0400 Subject: RFR 8159284: bigapps/Jetty - assert(jfa->last_Java_sp() > sp()) failed with tracing code in use In-Reply-To: References: Message-ID: <5acb32e0-8cf1-fc4c-e32b-ef777503292a@oracle.com> On 8/2/16 2:22 PM, Coleen Phillimore wrote: > > Fred, Thank you for reviewing this. > > On 8/2/16 2:02 PM, Frederic Parain wrote: >> Coleen, >> >> src/cpu/aarch64/vm/frame_aarch64.cpp >> >> line 116: return entry_frame_is_safe(thread); >> line 207: return sender.is_entry_frame_safe(thread); >> >> Method names are different, is it a typo? >> > > Yes, it is a typo. Thank you for catching it. > >> src/cpu/sparc/vm/frame_sparc.cpp >> >> No comments >> >> src/cpu/x86/vm/frame_x86.cpp >> >> No comments >> >> src/share/vm/runtime/frame.cpp >> >> No comments >> >> src/share/vm/runtime/frame.hpp >> >> I would expect the new method name to be is_entry_frame_safe() >> as most tester methods begin with "is_" but I this is just a >> personal opinion. > > I named it entry_frame_is_safe() because I thought it looked less > redundant and more distinct in the code fragments where they occurred: > > // Entry frame checks > if (is_entry_frame()) { > // an entry frame must have a valid fp. > > if (!fp_safe) return false; > > return entry_frame_is_safe(thread); > } > > is_entry_frame_safe() looks like is_entry_frame() or implies it's a > "safe" call to is_entry_frame. > > I guess it is the standard to start with 'is' for these sorts of > tests. How about is_safe_entry_frame() ? I've got it. There's is_interpreted_frame and there's is_interpreted_frame_valid. I'll use is_entry_frame_valid for consistency. Thanks, Coleen > > thanks, > Coleen > >> >> Fred >> >> On 08/01/2016 07:38 PM, Coleen Phillimore wrote: >>> Summary: Test condition in assert in frame::safe_for_sender() for entry >>> frames and return false. >>> >>> This bug is for a confidential part of the project that needs more >>> robustness checks to verify that frame::sender() can be called. >>> >>> Also refactored into frame::entry_frame_is_safe() because these >>> platforms had the same code for entry frames to determine whether it is >>> still safe to trust this frame to call sender(). These platforms had >>> also the same assert in sender_for_entry_frame() that the sampling code >>> hit. >>> >>> Tested with our nightly tests on all platforms and bigapps/Jetty. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8159284.01/webrev >>> >>> Thanks, >>> Coleen >>> > From frederic.parain at oracle.com Tue Aug 2 18:28:17 2016 From: frederic.parain at oracle.com (Frederic Parain) Date: Tue, 2 Aug 2016 14:28:17 -0400 Subject: RFR 8159284: bigapps/Jetty - assert(jfa->last_Java_sp() > sp()) failed with tracing code in use In-Reply-To: References: Message-ID: <49266448-6924-c5fd-5ab1-27fb4fad4301@oracle.com> On 08/02/2016 02:22 PM, Coleen Phillimore wrote: > > Fred, Thank you for reviewing this. > > On 8/2/16 2:02 PM, Frederic Parain wrote: >> Coleen, >> >> src/cpu/aarch64/vm/frame_aarch64.cpp >> >> line 116: return entry_frame_is_safe(thread); >> line 207: return sender.is_entry_frame_safe(thread); >> >> Method names are different, is it a typo? >> > > Yes, it is a typo. Thank you for catching it. > >> src/cpu/sparc/vm/frame_sparc.cpp >> >> No comments >> >> src/cpu/x86/vm/frame_x86.cpp >> >> No comments >> >> src/share/vm/runtime/frame.cpp >> >> No comments >> >> src/share/vm/runtime/frame.hpp >> >> I would expect the new method name to be is_entry_frame_safe() >> as most tester methods begin with "is_" but I this is just a >> personal opinion. > > I named it entry_frame_is_safe() because I thought it looked less > redundant and more distinct in the code fragments where they occurred: > > // Entry frame checks > if (is_entry_frame()) { > // an entry frame must have a valid fp. > > if (!fp_safe) return false; > > return entry_frame_is_safe(thread); > } > > is_entry_frame_safe() looks like is_entry_frame() or implies it's a > "safe" call to is_entry_frame. > > I guess it is the standard to start with 'is' for these sorts of > tests. How about is_safe_entry_frame() ? Sounds good. Fred > thanks, > Coleen > >> >> Fred >> >> On 08/01/2016 07:38 PM, Coleen Phillimore wrote: >>> Summary: Test condition in assert in frame::safe_for_sender() for entry >>> frames and return false. >>> >>> This bug is for a confidential part of the project that needs more >>> robustness checks to verify that frame::sender() can be called. >>> >>> Also refactored into frame::entry_frame_is_safe() because these >>> platforms had the same code for entry frames to determine whether it is >>> still safe to trust this frame to call sender(). These platforms had >>> also the same assert in sender_for_entry_frame() that the sampling code >>> hit. >>> >>> Tested with our nightly tests on all platforms and bigapps/Jetty. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8159284.01/webrev >>> >>> Thanks, >>> Coleen >>> > From kim.barrett at oracle.com Tue Aug 2 18:28:40 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 2 Aug 2016 14:28:40 -0400 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: References: <88A2872D-70F9-48DB-94B1-4314B3D9D217@oracle.com> <3933D052-50B2-43F1-AA20-2E75F60B61CE@oracle.com> <764F8C8B-AFE6-4A3F-8C0D-3D24F72CED58@oracle.com> Message-ID: <5E608891-21D4-4518-BA75-66F7DE53C64E@oracle.com> > On Aug 2, 2016, at 8:55 AM, Peter Levart wrote: > > Hi Kim, > > This looks very good. I like the way you dealt with race between the ReferenceHandler thread and threads waiting for it to do some cleanup progress. I think the VM API is suitable for possible further development on JDK-8149925. It's also nice that the whole pending list is obtained in one native call, so further optimizations on Java side are possible. > > Regards, Peter Thanks! > > On 08/01/2016 08:47 PM, Kim Barrett wrote: >> This updated webrev addresses concerns about the performance of the VM >> API used by the reference processor thread in the original webrev. >> >> New webrevs: >> full: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.03/ >> http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.03/ >> incr: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.03.incr/ >> http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.03.incr/ [snip] From frederic.parain at oracle.com Tue Aug 2 18:35:42 2016 From: frederic.parain at oracle.com (Frederic Parain) Date: Tue, 2 Aug 2016 14:35:42 -0400 Subject: RFR 8159284: bigapps/Jetty - assert(jfa->last_Java_sp() > sp()) failed with tracing code in use In-Reply-To: <5acb32e0-8cf1-fc4c-e32b-ef777503292a@oracle.com> References: <5acb32e0-8cf1-fc4c-e32b-ef777503292a@oracle.com> Message-ID: <2e5e4cd5-7836-63cf-1a36-187ee0f0968b@oracle.com> On 08/02/2016 02:25 PM, Coleen Phillimore wrote: > > > On 8/2/16 2:22 PM, Coleen Phillimore wrote: >> >> Fred, Thank you for reviewing this. >> >> On 8/2/16 2:02 PM, Frederic Parain wrote: >>> Coleen, >>> >>> src/cpu/aarch64/vm/frame_aarch64.cpp >>> >>> line 116: return entry_frame_is_safe(thread); >>> line 207: return sender.is_entry_frame_safe(thread); >>> >>> Method names are different, is it a typo? >>> >> >> Yes, it is a typo. Thank you for catching it. >> >>> src/cpu/sparc/vm/frame_sparc.cpp >>> >>> No comments >>> >>> src/cpu/x86/vm/frame_x86.cpp >>> >>> No comments >>> >>> src/share/vm/runtime/frame.cpp >>> >>> No comments >>> >>> src/share/vm/runtime/frame.hpp >>> >>> I would expect the new method name to be is_entry_frame_safe() >>> as most tester methods begin with "is_" but I this is just a >>> personal opinion. >> >> I named it entry_frame_is_safe() because I thought it looked less >> redundant and more distinct in the code fragments where they occurred: >> >> // Entry frame checks >> if (is_entry_frame()) { >> // an entry frame must have a valid fp. >> >> if (!fp_safe) return false; >> >> return entry_frame_is_safe(thread); >> } >> >> is_entry_frame_safe() looks like is_entry_frame() or implies it's a >> "safe" call to is_entry_frame. >> >> I guess it is the standard to start with 'is' for these sorts of >> tests. How about is_safe_entry_frame() ? > > I've got it. There's is_interpreted_frame and there's > is_interpreted_frame_valid. I'll use is_entry_frame_valid for consistency. Sounds consistent and explicit, I like it. Fred > Thanks, > Coleen > >> >> thanks, >> Coleen >> >>> >>> Fred >>> >>> On 08/01/2016 07:38 PM, Coleen Phillimore wrote: >>>> Summary: Test condition in assert in frame::safe_for_sender() for entry >>>> frames and return false. >>>> >>>> This bug is for a confidential part of the project that needs more >>>> robustness checks to verify that frame::sender() can be called. >>>> >>>> Also refactored into frame::entry_frame_is_safe() because these >>>> platforms had the same code for entry frames to determine whether it is >>>> still safe to trust this frame to call sender(). These platforms had >>>> also the same assert in sender_for_entry_frame() that the sampling code >>>> hit. >>>> >>>> Tested with our nightly tests on all platforms and bigapps/Jetty. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8159284.01/webrev >>>> >>>> Thanks, >>>> Coleen >>>> >> > From volker.simonis at gmail.com Tue Aug 2 19:47:45 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 2 Aug 2016 21:47:45 +0200 Subject: [8u] request for approval: "8152172: PPC64: Support AES intrinsics" In-Reply-To: <5637bef2-120c-9d3b-80e1-2e2b7a57e78c@oracle.com> References: <5637bef2-120c-9d3b-80e1-2e2b7a57e78c@oracle.com> Message-ID: Hi Sean, thanks a lot for your reply. You're right - I'm still waiting for a review of the hotspot part. Any volunteers :) Regarding the noreg label: I used 'noreg-other' because there already exist AES tests (they have never been part of this original change). Is that the right label? There are simply too many different noreg labels without documentation so if I selected the wrong one, please advice which one to choose. Thanks, Volker On Tue, Aug 2, 2016 at 9:58 AM, Se?n Coffey wrote: > Volker, > > Have the jdk8u hotspot edits been reviewed ? Looks like they should be. > > Can you add a suitable noreg label to the master bug report also. > > Regards, > Sean. > > > On 29/07/2016 19:58, Volker Simonis wrote: >> >> Ping! >> >> Can I please have an approval for backporting this change to 8u-dev? >> >> Thanks, >> Volker >> >> >> On Fri, Jul 22, 2016 at 11:08 AM, Volker Simonis >> wrote: >>> >>> Hi, >>> >>> could you please approve the backport of the following, mostly ppc64 >>> change to jdk8u-dev: >>> >>> 8152172: PPC64: Support AES intrinsics >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152172 >>> Webrev: http://cr.openjdk.java.net/~simonis/webrevs/2016/8152172_8u_hs/ >>> Webrev http://cr.openjdk.java.net/~simonis/webrevs/2016/8152172_8u_jdk/ >>> Review: >>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-March/thread.html#22032 >>> URL:http://hg.openjdk.java.net/jdk9/hs-comp/jdk/rev/74bc7be0777b >>> URL:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/68394bf0a09f >>> >>> As you can see, the change consists of two parts - the main one in the >>> hotpsot repo and a small part in the jdk repo. >>> >>> The jdk part applied cleanly to jdk8u (with the usual directory >>> shuffling). >>> >>> The hotspot part required a small tweak, but only in the ppc-only >>> part. This is because the feature detection for the AES instructions >>> was already active in jdk9 when the original change was made but is >>> not available in jdk8u until now. You can find the additional changes >>> at the end of this mail for your convenience. >>> >>> The required shared changes cleanly apply to jdk8u. >>> >>> As Vladimir pointed out in a previous thread, shared Hotspot changes >>> have to go through JPRT even in jdk8u-dev. So I need a sponsor to do >>> that and synchronously push both parts. >>> >>> @Hiroshii: could you please verify that you are fine with the change? >>> I've done some tests on Power8LE but just want to be sure this >>> downport satisfies your needs as well. >>> >>> Thank you and best regards, >>> Volker >>> >>> ===================== >>> >>> diff -r 15928d255046 src/cpu/ppc/vm/vm_version_ppc.cpp >>> --- a/src/cpu/ppc/vm/vm_version_ppc.cpp Wed Jul 13 00:47:40 2016 -0700 >>> +++ b/src/cpu/ppc/vm/vm_version_ppc.cpp Fri Jul 22 10:32:36 2016 +0200 >>> @@ -452,6 +476,7 @@ >>> a->popcntw(R7, R5); // code[7] -> popcntw >>> a->fcfids(F3, F4); // code[8] -> fcfids >>> a->vand(VR0, VR0, VR0); // code[9] -> vand >>> + a->vcipher(VR0, VR1, VR2); // code[10] -> vcipher >>> a->blr(); >>> >>> // Emit function to set one cache line to zero. Emit function >>> descriptor and get pointer to it. >>> @@ -495,6 +520,7 @@ >>> if (code[feature_cntr++]) features |= popcntw_m; >>> if (code[feature_cntr++]) features |= fcfids_m; >>> if (code[feature_cntr++]) features |= vand_m; >>> + if (code[feature_cntr++]) features |= vcipher_m; >>> >>> // Print the detection code. >>> if (PrintAssembly) { >>> diff -r 15928d255046 src/cpu/ppc/vm/vm_version_ppc.hpp >>> --- a/src/cpu/ppc/vm/vm_version_ppc.hpp Wed Jul 13 00:47:40 2016 -0700 >>> +++ b/src/cpu/ppc/vm/vm_version_ppc.hpp Fri Jul 22 10:32:36 2016 +0200 >>> @@ -42,6 +42,7 @@ >>> fcfids, >>> vand, >>> dcba, >>> + vcipher, >>> num_features // last entry to count features >>> }; >>> enum Feature_Flag_Set { >>> @@ -56,6 +57,7 @@ >>> fcfids_m = (1 << fcfids ), >>> vand_m = (1 << vand ), >>> dcba_m = (1 << dcba ), >>> + vcipher_m = (1 << vcipher), >>> all_features_m = -1 >>> }; >>> static int _features; >>> @@ -83,6 +85,7 @@ >>> static bool has_fcfids() { return (_features & fcfids_m) != 0; } >>> static bool has_vand() { return (_features & vand_m) != 0; } >>> static bool has_dcba() { return (_features & dcba_m) != 0; } >>> + static bool has_vcipher() { return (_features & vcipher_m) != 0; } >>> >>> static const char* cpu_features() { return _features_str; } > > From vladimir.kozlov at oracle.com Tue Aug 2 20:16:24 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 2 Aug 2016 13:16:24 -0700 Subject: RFR: 8162944 - Testbug: jdk.test.lib.Utils in root repo missing newer methods In-Reply-To: <57A0912A.8010400@oracle.com> References: <57A0912A.8010400@oracle.com> Message-ID: <57A0FF98.3040806@oracle.com> Sending to hotspot-dev. Changes are good I think. Can we remove Utils.java from hotspot/test/testlibrary to avoid this in a future? Thanks, Vladimir On 8/2/16 5:25 AM, Dmitrij Pochepko wrote: > Hi, > > please review fix for 8162944 - Testbug: jdk.test.lib.Utils in root repo missing newer methods > > jdk.test.lib.Utils deprecated copy was updated with new methods, so, these methods has to be copied into actual version in root repo. This fix copies 3 respective methods. > > webrev: http://cr.openjdk.java.net/~dpochepk/8162944/webrev.01/ > CR: https://bugs.openjdk.java.net/browse/JDK-8162944 > > I've tested this fix on linux-amd64 by running tests which use root version. > > Thanks, > Dmitrij From christian.tornqvist at oracle.com Tue Aug 2 20:27:37 2016 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Tue, 2 Aug 2016 16:27:37 -0400 Subject: RFR: 8162944 - Testbug: jdk.test.lib.Utils in root repo missing newer methods In-Reply-To: <57A0FF98.3040806@oracle.com> References: <57A0912A.8010400@oracle.com> <57A0FF98.3040806@oracle.com> Message-ID: <4bd801d1ecfc$4f6c5af0$ee4510d0$@oracle.com> Hi Vladimir, My change for JDK-8157957 will get rid of the duplicate classes in hotspot/test/testlibrary, I'm almost done after having to merge with the massive test refactoring the compiler team just did. Thanks, Christian -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov Sent: Tuesday, August 2, 2016 4:16 PM To: hotspot-dev at openjdk.java.net Subject: Re: RFR: 8162944 - Testbug: jdk.test.lib.Utils in root repo missing newer methods Sending to hotspot-dev. Changes are good I think. Can we remove Utils.java from hotspot/test/testlibrary to avoid this in a future? Thanks, Vladimir On 8/2/16 5:25 AM, Dmitrij Pochepko wrote: > Hi, > > please review fix for 8162944 - Testbug: jdk.test.lib.Utils in root repo missing newer methods > > jdk.test.lib.Utils deprecated copy was updated with new methods, so, these methods has to be copied into actual version in root repo. This fix copies 3 respective methods. > > webrev: http://cr.openjdk.java.net/~dpochepk/8162944/webrev.01/ > CR: https://bugs.openjdk.java.net/browse/JDK-8162944 > > I've tested this fix on linux-amd64 by running tests which use root version. > > Thanks, > Dmitrij From max.ockner at oracle.com Tue Aug 2 20:38:25 2016 From: max.ockner at oracle.com (Max Ockner) Date: Tue, 02 Aug 2016 16:38:25 -0400 Subject: RFR(XS): 8159917: Added missing space to class+loader+data logging Message-ID: <57A104C1.7050808@oracle.com> Hello, Please review this small correction to class+loader+data logging. bug: https://bugs.openjdk.java.net/browse/JDK-8159917 webrev: http://cr.openjdk.java.net/~mockner/8159917/ Previously in ClassLoaderData::print_value_on(), there was a space missing between the hex address and the letter 'a' as part of a separate field in the logging info. This space has been removed. Thanks, Max From gromero at linux.vnet.ibm.com Tue Aug 2 20:38:36 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Tue, 2 Aug 2016 17:38:36 -0300 Subject: RFR(S) 8162369: PPC64: Wrong ucontext used after SIGTRAP while in HTM critical section Message-ID: <57A104CC.7090608@linux.vnet.ibm.com> Hi, Could the following webrev be hosted and reviewed, please? Webrev: http://81.de.7a9f.ip4.static.sl-reverse.com/8162369/v1 CR: https://bugs.openjdk.java.net/browse/JDK-8162369 Thomas, I've tested the proposed fix under two different (unexpected) error conditions that can happen when in an HTM transaction: a SIGSEGV and a SIGILL. Since reporting pc at tbegin+4 is misleading, in both cases the correct context for error reporting is the second (transactional). Then: 1) in a segmentation fault in the middle of a transaction it will be reported correctly, like this: # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00003fff4c2dffac, pid=31046, tid=31047 siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x0000000000000000 Hence when we inspect the offending location indicated by the pc value in the hs_err log we find the right root cause of the SIGSEGV: (gdb) disas 0x00003fff4c2dffac-4,+8 Dump of assembler code from 0x3fff4c2dffa8 to 0x3fff4c2dffb0: 0x00003fff4c2dffa8: li r15,0 0x00003fff4c2dffac: ld r15,0(r15) End of assembler dump. Tested by the injection of a load from memory position 0x0, accordingly to this patch: https://paste.fedoraproject.org/400032/ Full log hs_err log: http://paste.fedoraproject.org/400035/raw/ 2) in an illegal instruction in the middle of a transaction it will be reported correctly as well, like this: # # A fatal error has been detected by the Java Runtime Environment: # # SIGILL (0x4) at pc=0x00003fff7c2dd930, pid=21140, tid=21141 siginfo: si_signo: 4 (SIGILL), si_code: 1 (ILL_ILLOPC), si_addr: 0x00003fff7c2dd930 Hence when we inspect the offending location indicated by the pc value we find the right offending instruction: (gdb) disas 0x00003fff7c2dd930-4,+8 Dump of assembler code from 0x3fff7c2dd92c to 0x3fff7c2dd934: 0x00003fff7c2dd92c: cmpwi cr6,r0,1 0x00003fff7c2dd930: .long 0xea2f0013 End of assembler dump. Tested by the injection of a illegal instruction, accordingly to this patch: https://paste.fedoraproject.org/400080/ Full log hs_err log: https://paste.fedoraproject.org/400073/raw/ Martin, although the detection using is_tbegin() is equivalent to checking the uc_link pointer, I've decided to use the detection suggested by the Linux kernel documentation, i.e checking the uc_link pointer plus the MSR TS bits. As you said it's not an issue since uc_link isn't new and the msr register isn't also new. So this kind of check will compile on both PPC64 LE and BE fine. Thank you for sponsoring the change. No regression was observed. One additional test now passes: Passed: compiler/rtm/cli/TestUseRTMForStackLocksOptionOnSupportedConfig.java Thank you! Best regards, Gustavo From chris.plummer at oracle.com Tue Aug 2 21:18:22 2016 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 2 Aug 2016 14:18:22 -0700 Subject: RFR(XXS): 8161030: GPL header missing comma after year Message-ID: <694c431a-e827-22b8-46ce-0cc5ed08f067@oracle.com> Hello, Please review following simple fix to the GPL header in a few files: https://bugs.openjdk.java.net/browse/JDK-8161030 http://cr.openjdk.java.net/~cjplummer/8161030/webrev.00/webrev.hotspot/ No testing since they are just comment changes. JPRT commit testing will catch any blunders. thanks, Chris From vladimir.kozlov at oracle.com Tue Aug 2 21:29:49 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 2 Aug 2016 14:29:49 -0700 Subject: RFR: 8162944 - Testbug: jdk.test.lib.Utils in root repo missing newer methods In-Reply-To: <4bd801d1ecfc$4f6c5af0$ee4510d0$@oracle.com> References: <57A0912A.8010400@oracle.com> <57A0FF98.3040806@oracle.com> <4bd801d1ecfc$4f6c5af0$ee4510d0$@oracle.com> Message-ID: <57A110CD.4000803@oracle.com> Thank you, Christian Yes, lets wait your changes. We can close 8162944 then. What is your bug id? Thanks, Vladimir On 8/2/16 1:27 PM, Christian Tornqvist wrote: > Hi Vladimir, > > My change for JDK-8157957 will get rid of the duplicate classes in hotspot/test/testlibrary, I'm almost done after having to merge with the massive test refactoring the compiler team just did. > > Thanks, > Christian > > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov > Sent: Tuesday, August 2, 2016 4:16 PM > To: hotspot-dev at openjdk.java.net > Subject: Re: RFR: 8162944 - Testbug: jdk.test.lib.Utils in root repo missing newer methods > > Sending to hotspot-dev. > > Changes are good I think. Can we remove Utils.java from hotspot/test/testlibrary to avoid this in a future? > > Thanks, > Vladimir > > On 8/2/16 5:25 AM, Dmitrij Pochepko wrote: >> Hi, >> >> please review fix for 8162944 - Testbug: jdk.test.lib.Utils in root repo missing newer methods >> >> jdk.test.lib.Utils deprecated copy was updated with new methods, so, these methods has to be copied into actual version in root repo. This fix copies 3 respective methods. >> >> webrev: http://cr.openjdk.java.net/~dpochepk/8162944/webrev.01/ >> CR: https://bugs.openjdk.java.net/browse/JDK-8162944 >> >> I've tested this fix on linux-amd64 by running tests which use root version. >> >> Thanks, >> Dmitrij > From frederic.parain at oracle.com Tue Aug 2 21:32:37 2016 From: frederic.parain at oracle.com (Frederic Parain) Date: Tue, 2 Aug 2016 17:32:37 -0400 Subject: RFR(XXS): 8161030: GPL header missing comma after year In-Reply-To: <694c431a-e827-22b8-46ce-0cc5ed08f067@oracle.com> References: <694c431a-e827-22b8-46ce-0cc5ed08f067@oracle.com> Message-ID: <79beb236-1597-3197-a633-f96c25d33310@oracle.com> Looks good. Fred On 08/02/2016 05:18 PM, Chris Plummer wrote: > Hello, > > Please review following simple fix to the GPL header in a few files: > > https://bugs.openjdk.java.net/browse/JDK-8161030 > http://cr.openjdk.java.net/~cjplummer/8161030/webrev.00/webrev.hotspot/ > > No testing since they are just comment changes. JPRT commit testing will > catch any blunders. > > thanks, > > Chris From coleen.phillimore at oracle.com Tue Aug 2 21:57:53 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 2 Aug 2016 17:57:53 -0400 Subject: RFR(XXS): 8161030: GPL header missing comma after year In-Reply-To: <79beb236-1597-3197-a633-f96c25d33310@oracle.com> References: <694c431a-e827-22b8-46ce-0cc5ed08f067@oracle.com> <79beb236-1597-3197-a633-f96c25d33310@oracle.com> Message-ID: <6c630705-cf65-d455-5b37-e6d71a878422@oracle.com> Looks good. Coleen On 8/2/16 5:32 PM, Frederic Parain wrote: > Looks good. > > Fred > > On 08/02/2016 05:18 PM, Chris Plummer wrote: >> Hello, >> >> Please review following simple fix to the GPL header in a few files: >> >> https://bugs.openjdk.java.net/browse/JDK-8161030 >> http://cr.openjdk.java.net/~cjplummer/8161030/webrev.00/webrev.hotspot/ >> >> No testing since they are just comment changes. JPRT commit testing will >> catch any blunders. >> >> thanks, >> >> Chris From coleen.phillimore at oracle.com Tue Aug 2 22:08:02 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 2 Aug 2016 18:08:02 -0400 Subject: RFR 8159284: bigapps/Jetty - assert(jfa->last_Java_sp() > sp()) failed with tracing code in use In-Reply-To: <49266448-6924-c5fd-5ab1-27fb4fad4301@oracle.com> References: <49266448-6924-c5fd-5ab1-27fb4fad4301@oracle.com> Message-ID: <821c378c-9b78-2f5c-dda6-a2c85c0c9d4e@oracle.com> Hi, I have another webrev with the name change of is_entry_frame_valid(), which passes JPRT. thanks, Coleen On 8/2/16 2:28 PM, Frederic Parain wrote: > > > On 08/02/2016 02:22 PM, Coleen Phillimore wrote: >> >> Fred, Thank you for reviewing this. >> >> On 8/2/16 2:02 PM, Frederic Parain wrote: >>> Coleen, >>> >>> src/cpu/aarch64/vm/frame_aarch64.cpp >>> >>> line 116: return entry_frame_is_safe(thread); >>> line 207: return sender.is_entry_frame_safe(thread); >>> >>> Method names are different, is it a typo? >>> >> >> Yes, it is a typo. Thank you for catching it. >> >>> src/cpu/sparc/vm/frame_sparc.cpp >>> >>> No comments >>> >>> src/cpu/x86/vm/frame_x86.cpp >>> >>> No comments >>> >>> src/share/vm/runtime/frame.cpp >>> >>> No comments >>> >>> src/share/vm/runtime/frame.hpp >>> >>> I would expect the new method name to be is_entry_frame_safe() >>> as most tester methods begin with "is_" but I this is just a >>> personal opinion. >> >> I named it entry_frame_is_safe() because I thought it looked less >> redundant and more distinct in the code fragments where they occurred: >> >> // Entry frame checks >> if (is_entry_frame()) { >> // an entry frame must have a valid fp. >> >> if (!fp_safe) return false; >> >> return entry_frame_is_safe(thread); >> } >> >> is_entry_frame_safe() looks like is_entry_frame() or implies it's a >> "safe" call to is_entry_frame. >> >> I guess it is the standard to start with 'is' for these sorts of >> tests. How about is_safe_entry_frame() ? > > Sounds good. > > Fred > >> thanks, >> Coleen >> >>> >>> Fred >>> >>> On 08/01/2016 07:38 PM, Coleen Phillimore wrote: >>>> Summary: Test condition in assert in frame::safe_for_sender() for >>>> entry >>>> frames and return false. >>>> >>>> This bug is for a confidential part of the project that needs more >>>> robustness checks to verify that frame::sender() can be called. >>>> >>>> Also refactored into frame::entry_frame_is_safe() because these >>>> platforms had the same code for entry frames to determine whether >>>> it is >>>> still safe to trust this frame to call sender(). These platforms had >>>> also the same assert in sender_for_entry_frame() that the sampling >>>> code >>>> hit. >>>> >>>> Tested with our nightly tests on all platforms and bigapps/Jetty. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8159284.01/webrev >>>> >>>> Thanks, >>>> Coleen >>>> >> From coleen.phillimore at oracle.com Tue Aug 2 22:19:46 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 2 Aug 2016 18:19:46 -0400 Subject: RFR 8159284: bigapps/Jetty - assert(jfa->last_Java_sp() > sp()) failed with tracing code in use In-Reply-To: <821c378c-9b78-2f5c-dda6-a2c85c0c9d4e@oracle.com> References: <49266448-6924-c5fd-5ab1-27fb4fad4301@oracle.com> <821c378c-9b78-2f5c-dda6-a2c85c0c9d4e@oracle.com> Message-ID: <566f441f-22ed-5c14-6129-afdea58df8f9@oracle.com> On 8/2/16 6:08 PM, Coleen Phillimore wrote: > > Hi, I have another webrev with the name change of > is_entry_frame_valid(), which passes JPRT. http://cr.openjdk.java.net/~coleenp/8159284.02/webrev/index.html > > thanks, > Coleen > > > On 8/2/16 2:28 PM, Frederic Parain wrote: >> >> >> On 08/02/2016 02:22 PM, Coleen Phillimore wrote: >>> >>> Fred, Thank you for reviewing this. >>> >>> On 8/2/16 2:02 PM, Frederic Parain wrote: >>>> Coleen, >>>> >>>> src/cpu/aarch64/vm/frame_aarch64.cpp >>>> >>>> line 116: return entry_frame_is_safe(thread); >>>> line 207: return sender.is_entry_frame_safe(thread); >>>> >>>> Method names are different, is it a typo? >>>> >>> >>> Yes, it is a typo. Thank you for catching it. >>> >>>> src/cpu/sparc/vm/frame_sparc.cpp >>>> >>>> No comments >>>> >>>> src/cpu/x86/vm/frame_x86.cpp >>>> >>>> No comments >>>> >>>> src/share/vm/runtime/frame.cpp >>>> >>>> No comments >>>> >>>> src/share/vm/runtime/frame.hpp >>>> >>>> I would expect the new method name to be is_entry_frame_safe() >>>> as most tester methods begin with "is_" but I this is just a >>>> personal opinion. >>> >>> I named it entry_frame_is_safe() because I thought it looked less >>> redundant and more distinct in the code fragments where they occurred: >>> >>> // Entry frame checks >>> if (is_entry_frame()) { >>> // an entry frame must have a valid fp. >>> >>> if (!fp_safe) return false; >>> >>> return entry_frame_is_safe(thread); >>> } >>> >>> is_entry_frame_safe() looks like is_entry_frame() or implies it's a >>> "safe" call to is_entry_frame. >>> >>> I guess it is the standard to start with 'is' for these sorts of >>> tests. How about is_safe_entry_frame() ? >> >> Sounds good. >> >> Fred >> >>> thanks, >>> Coleen >>> >>>> >>>> Fred >>>> >>>> On 08/01/2016 07:38 PM, Coleen Phillimore wrote: >>>>> Summary: Test condition in assert in frame::safe_for_sender() for >>>>> entry >>>>> frames and return false. >>>>> >>>>> This bug is for a confidential part of the project that needs more >>>>> robustness checks to verify that frame::sender() can be called. >>>>> >>>>> Also refactored into frame::entry_frame_is_safe() because these >>>>> platforms had the same code for entry frames to determine whether >>>>> it is >>>>> still safe to trust this frame to call sender(). These platforms had >>>>> also the same assert in sender_for_entry_frame() that the sampling >>>>> code >>>>> hit. >>>>> >>>>> Tested with our nightly tests on all platforms and bigapps/Jetty. >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8159284.01/webrev >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>> > From coleen.phillimore at oracle.com Tue Aug 2 22:35:25 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 2 Aug 2016 18:35:25 -0400 Subject: RFR(XS): 8159917: Added missing space to class+loader+data logging In-Reply-To: <57A104C1.7050808@oracle.com> References: <57A104C1.7050808@oracle.com> Message-ID: <323a30ab-4135-959b-6cac-c50e1312be96@oracle.com> Looks good, Max. Under the trivial change rules, you can check it in with one Reviewer. thanks, Coleen On 8/2/16 4:38 PM, Max Ockner wrote: > Hello, > Please review this small correction to class+loader+data logging. > > bug: https://bugs.openjdk.java.net/browse/JDK-8159917 > webrev: http://cr.openjdk.java.net/~mockner/8159917/ > > Previously in ClassLoaderData::print_value_on(), there was a space > missing between the hex address and the letter 'a' as part of a > separate field in the logging info. This space has been removed. > > Thanks, > Max From vladimir.kozlov at oracle.com Tue Aug 2 23:22:38 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 2 Aug 2016 16:22:38 -0700 Subject: RFR: 8161550: [JVMCI] Crash: assert(sig_bt[member_arg_pos] == T_OBJECT) In-Reply-To: <229e1052-ac4a-148d-028b-1a0674e6b517@oracle.com> References: <229e1052-ac4a-148d-028b-1a0674e6b517@oracle.com> Message-ID: <57A12B3E.4060107@oracle.com> Looks good. Thanks, Vladimir On 8/2/16 7:07 AM, Stefan Anzinger wrote: > Hello, > > this RFR fixes 8161550. JVMCI must not return intrinsified MethodHandle > methods. The test had to be updated and the shortcut evaluation in > HotSpotResolvedObjectTypeImpl.resolveMethod needs take care of this fact. > > http://cr.openjdk.java.net/~sanzinger/8161550/webrev.00/ > > Stefan > From chris.plummer at oracle.com Tue Aug 2 23:29:06 2016 From: chris.plummer at oracle.com (Chris Plummer) Date: Tue, 2 Aug 2016 16:29:06 -0700 Subject: RFR(XXS): 8161030: GPL header missing comma after year In-Reply-To: <6c630705-cf65-d455-5b37-e6d71a878422@oracle.com> References: <694c431a-e827-22b8-46ce-0cc5ed08f067@oracle.com> <79beb236-1597-3197-a633-f96c25d33310@oracle.com> <6c630705-cf65-d455-5b37-e6d71a878422@oracle.com> Message-ID: <1d2dba70-bbbe-2c63-a02f-3ed2a4a903d1@oracle.com> Thanks Coleen and Fred! Chris On 8/2/16 2:57 PM, Coleen Phillimore wrote: > Looks good. > Coleen > > On 8/2/16 5:32 PM, Frederic Parain wrote: >> Looks good. >> >> Fred >> >> On 08/02/2016 05:18 PM, Chris Plummer wrote: >>> Hello, >>> >>> Please review following simple fix to the GPL header in a few files: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8161030 >>> http://cr.openjdk.java.net/~cjplummer/8161030/webrev.00/webrev.hotspot/ >>> >>> No testing since they are just comment changes. JPRT commit testing >>> will >>> catch any blunders. >>> >>> thanks, >>> >>> Chris > From vladimir.kozlov at oracle.com Tue Aug 2 23:42:04 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 2 Aug 2016 16:42:04 -0700 Subject: RFR: JDK-8141634 Implement VarHandles/Unsafe intrinsics on SPARC In-Reply-To: <7ebde74d-dd50-bfa8-4f2f-502088348c0d@oracle.com> References: <7ebde74d-dd50-bfa8-4f2f-502088348c0d@oracle.com> Message-ID: <57A12FCC.7070702@oracle.com> Looks good. Our group will sponsor it. Thanks, Vladimir On 7/29/16 1:37 AM, Trevor Watson wrote: > Summary: > > SPARC assembler implementations of the compareAndExchange* intrinsics and the addition of the WeakCompareAndSwap* matchers. > > Have successfully run the 'gmake test' target and the benchmarks mentioned in the bug report. > > Benchmarks for the compareAndExchange* intrinsic operations now show an approximate 9x-20x improvement: > > Before: > Benchmark Mode Cnt Score Error Units > caeAcquire.IntTest.varHandle avgt 15 351.933 ? 7.161 ns/op > caeAcquire.LongTest.varHandle avgt 15 435.872 ? 3.129 ns/op > caeAcquire.ObjectTest.varHandle avgt 15 975.728 ? 88.362 ns/op > caeRelease.IntTest.varHandle avgt 15 346.391 ? 2.798 ns/op > caeRelease.LongTest.varHandle avgt 15 439.734 ? 9.739 ns/op > caeRelease.ObjectTest.varHandle avgt 15 934.279 ? 19.454 ns/op > caeVolatile.IntTest.varHandle avgt 15 346.076 ? 1.771 ns/op > caeVolatile.LongTest.varHandle avgt 15 436.788 ? 1.825 ns/op > caeVolatile.ObjectTest.varHandle avgt 15 935.250 ? 59.526 ns/op > > With new intrinsic implementation: > caeAcquire.IntTest.varHandle avgt 15 38.514 ? 0.974 ns/op > caeAcquire.LongTest.varHandle avgt 15 38.411 ? 0.359 ns/op > caeAcquire.ObjectTest.varHandle avgt 15 42.616 ? 0.916 ns/op > caeRelease.IntTest.varHandle avgt 15 38.235 ? 0.185 ns/op > caeRelease.LongTest.varHandle avgt 15 38.165 ? 0.145 ns/op > caeRelease.ObjectTest.varHandle avgt 15 42.320 ? 0.156 ns/op > caeVolatile.IntTest.varHandle avgt 15 38.321 ? 0.221 ns/op > caeVolatile.LongTest.varHandle avgt 15 38.270 ? 0.198 ns/op > caeVolatile.ObjectTest.varHandle avgt 15 42.541 ? 0.720 ns/op > > > Webrev: http://cr.openjdk.java.net/~alanbur/JDK-8141634/ > Bug link: https://bugs.openjdk.java.net/browse/JDK-8141634 From kim.barrett at oracle.com Wed Aug 3 00:03:20 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 2 Aug 2016 20:03:20 -0400 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: References: <88A2872D-70F9-48DB-94B1-4314B3D9D217@oracle.com> <3933D052-50B2-43F1-AA20-2E75F60B61CE@oracle.com> <764F8C8B-AFE6-4A3F-8C0D-3D24F72CED58@oracle.com> Message-ID: > On Aug 1, 2016, at 2:47 PM, Kim Barrett wrote: > > This updated webrev addresses concerns about the performance of the VM > API used by the reference processor thread in the original webrev. > > New webrevs: > full: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.03/ > http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.03/ > incr: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.03.incr/ > http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.03.incr/ Sorry, typo in the incremental webrev URLs ? ?incr? => ?inc?. From aph at redhat.com Wed Aug 3 00:04:22 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 3 Aug 2016 01:04:22 +0100 Subject: Does transition_and_fence really assume TSO? Message-ID: <57A13506.9070108@redhat.com> Here's an interesting comment: static inline void transition_and_fence(JavaThread *thread, JavaThreadState from, JavaThreadState to) { assert(thread->thread_state() == from, "coming from wrong thread state"); assert((from & 1) == 0 && (to & 1) == 0, "odd numbers are transitions states"); // Change to transition state (assumes total store ordering! -Urs) thread->set_thread_state((JavaThreadState)(from + 1)); The "assumes total store ordering!" comment is rather alarming. My processor is not TSO. But as far as I can see, all this really requires is single-variable coherency. Is that right? Andrew. From david.holmes at oracle.com Wed Aug 3 00:25:16 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 3 Aug 2016 10:25:16 +1000 Subject: Does transition_and_fence really assume TSO? In-Reply-To: <57A13506.9070108@redhat.com> References: <57A13506.9070108@redhat.com> Message-ID: Hi Andrew, On 3/08/2016 10:04 AM, Andrew Haley wrote: > Here's an interesting comment: > > static inline void transition_and_fence(JavaThread *thread, JavaThreadState from, JavaThreadState to) { > assert(thread->thread_state() == from, "coming from wrong thread state"); > assert((from & 1) == 0 && (to & 1) == 0, "odd numbers are transitions states"); > // Change to transition state (assumes total store ordering! -Urs) > thread->set_thread_state((JavaThreadState)(from + 1)); > > The "assumes total store ordering!" comment is rather alarming. My > processor is not TSO. But as far as I can see, all this really > requires is single-variable coherency. Is that right? That comment is pre-historic. The code does not assume TSO. There is a direct, or implicit, full fence between the two stores: // Make sure new state is seen by VM thread if (os::is_MP()) { if (UseMembar) { // Force a fence between the write above and read below OrderAccess::fence(); } else { // Must use this rather than serialization page in particular on Windows InterfaceSupport::serialize_memory(thread); } } Cheers, David > Andrew. > From david.holmes at oracle.com Wed Aug 3 02:04:30 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 3 Aug 2016 12:04:30 +1000 Subject: RFR(XS): 8162670: make of jtreg_tests fails if no tests are run, causing jprt test runs to also fail In-Reply-To: References: <8bbb54eb-e179-6c10-5d18-7838f08e847e@oracle.com> <4579a80c-6eb8-27e0-4e0d-cd68e6420df0@oracle.com> <6ac6f874-ce28-bc37-cd0f-575ce45af452@oracle.com> Message-ID: <364119db-f315-2f9e-68c2-80ea382de535@oracle.com> Looks good. Thanks, David On 3/08/2016 12:50 AM, Chris Plummer wrote: > On 8/1/16 9:30 PM, Chris Plummer wrote: >> On 8/1/16 7:25 PM, David Holmes wrote: >>> On 2/08/2016 12:11 PM, Chris Plummer wrote: >>>> On 8/1/16 5:58 PM, David Holmes wrote: >>>>> Hi Chris, >>>>> >>>>> On 2/08/2016 8:46 AM, Chris Plummer wrote: >>>>>> Hello, >>>>>> >>>>>> Please review this simple change: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8162670 >>>>>> http://cr.openjdk.java.net/~cjplummer/8162670/webrev-00/ >>>>> >>>>> You've split a compound expression with your code: >>>>> >>>>> 227 jtregExitCode=$$? && \ >>>>> 228 if [ $${jtregExitCode} == 1 ]; then \ >>>>> 229 jtregExitCode=0; \ >>>>> 230 fi ; \ >>>>> 231 _summary="$(SUMMARY_TXT)"; \ >>>>> >>>>> I'm not clear exactly why the && was needed here but rather than find >>>>> out later I suggest rearranging the above to: >>>>> >>>>> jtregExitCode=$$? && \ >>>>> _summary="$(SUMMARY_TXT)"; \ >>>>> if [ $${jtregExitCode} == 1 ]; then \ >>>>> jtregExitCode=0; \ >>>>> fi ; \ >>>>> >>>> Yeah, that makes sense. I'll make the change. However, it's really >>>> unclear what the use case for && is here. How can jtregExitCode=$$? >>>> ever >>>> fail? >>> >>> I wonder if it evaluates to the $? value and so only sets _summary if >>> we had a zero exit code? (Not that I understand why we would only set >>> _summary in that context.) >> I tried the following: >> >> bash-4.1$ x=0 && echo "foo"; >> >> And "foo" is always printed. I also tried non-zero values for x. Here >> are some other examples: >> >> bash-4.1$ (exit 1) && echo "foo" >> bash-4.1$ (exit 0) && echo "foo" >> foo >> >> Commands evaluate to true if the exit status is 0, and false >> otherwise, so I guess you could say commands evaluate to !?$. For &&, >> the rhs is only executed if the lhs has a zero exit status. > Updated webrev: > > http://cr.openjdk.java.net/~cjplummer/8162670/webrev-01/ > > thanks, > > Chris >> >> Chris >>> >>> David >>> >>>> thanks, >>>> >>>> Chris >>>>> Thanks, >>>>> David >>>>> >>>>>> Note the copyright dates haven't been updated in this webrev, but >>>>>> I did >>>>>> update them locally after noticing that. >>>>>> >>>>>> Tested with jprt test case given in the CR, and also with a jprt run >>>>>> using "testset -hotspot" to make sure I didn't break anything. >>>>>> >>>>>> thanks, >>>>>> >>>>>> Chris >>>> >>>> >> > From vladimir.kozlov at oracle.com Wed Aug 3 02:32:48 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 2 Aug 2016 19:32:48 -0700 Subject: [9] RFR[XS] 8163018: Slow compiler tests in JPRT Message-ID: <57A157D0.4070707@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8163018 http://cr.openjdk.java.net/~kvn/8163018/webrev/ JDK-8132919 changes missed '\' in few places which affected hotspot_fast_compiler_1 time execution by executing long running tests. needs_compact3 was also affected by similar but opposite problem - test were not included. I also added -XX:-TieredCompilation to Test6792161 which significantly reduced its execution time. Thanks, Vladimir From david.holmes at oracle.com Wed Aug 3 02:35:31 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 3 Aug 2016 12:35:31 +1000 Subject: [9] RFR[XS] 8163018: Slow compiler tests in JPRT In-Reply-To: <57A157D0.4070707@oracle.com> References: <57A157D0.4070707@oracle.com> Message-ID: Looks good! Thanks Vladimir. David On 3/08/2016 12:32 PM, Vladimir Kozlov wrote: > https://bugs.openjdk.java.net/browse/JDK-8163018 > http://cr.openjdk.java.net/~kvn/8163018/webrev/ > > JDK-8132919 changes missed '\' in few places which affected > hotspot_fast_compiler_1 time execution by executing long running tests. > needs_compact3 was also affected by similar but opposite problem - test > were not included. > > I also added -XX:-TieredCompilation to Test6792161 which significantly > reduced its execution time. > > Thanks, > Vladimir From daniel.daugherty at oracle.com Wed Aug 3 02:36:52 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 2 Aug 2016 20:36:52 -0600 Subject: [9] RFR[XS] 8163018: Slow compiler tests in JPRT In-Reply-To: <57A157D0.4070707@oracle.com> References: <57A157D0.4070707@oracle.com> Message-ID: On 8/2/16 8:32 PM, Vladimir Kozlov wrote: > https://bugs.openjdk.java.net/browse/JDK-8163018 > http://cr.openjdk.java.net/~kvn/8163018/webrev/ test/TEST.groups No comments. test/compiler/c2/Test6792161.java No comments. Thumbs up. Dan > > JDK-8132919 changes missed '\' in few places which affected > hotspot_fast_compiler_1 time execution by executing long running tests. > needs_compact3 was also affected by similar but opposite problem - > test were not included. > > I also added -XX:-TieredCompilation to Test6792161 which significantly > reduced its execution time. > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Wed Aug 3 02:40:11 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 2 Aug 2016 19:40:11 -0700 Subject: [9] RFR[XS] 8163018: Slow compiler tests in JPRT In-Reply-To: References: <57A157D0.4070707@oracle.com> Message-ID: <57A1598B.2080905@oracle.com> Thank you, David and Dan, for reviews. Vladimir On 8/2/16 7:36 PM, Daniel D. Daugherty wrote: > On 8/2/16 8:32 PM, Vladimir Kozlov wrote: >> https://bugs.openjdk.java.net/browse/JDK-8163018 >> http://cr.openjdk.java.net/~kvn/8163018/webrev/ > > test/TEST.groups > No comments. > > test/compiler/c2/Test6792161.java > No comments. > > Thumbs up. > > Dan > > >> >> JDK-8132919 changes missed '\' in few places which affected hotspot_fast_compiler_1 time execution by executing long running tests. >> needs_compact3 was also affected by similar but opposite problem - test were not included. >> >> I also added -XX:-TieredCompilation to Test6792161 which significantly reduced its execution time. >> >> Thanks, >> Vladimir > From zoltan.majo at oracle.com Wed Aug 3 04:43:07 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Tue, 2 Aug 2016 21:43:07 -0700 Subject: RFR: 8161550: [JVMCI] Crash: assert(sig_bt[member_arg_pos] == T_OBJECT) In-Reply-To: <229e1052-ac4a-148d-028b-1a0674e6b517@oracle.com> References: <229e1052-ac4a-148d-028b-1a0674e6b517@oracle.com> Message-ID: Hi Stefan, thank you for fixing this issue! Your fix looks good to me. Do you need a sponsor? If yes, I can sponsor your change. Best regards, Zoltan On 08/02/2016 07:07 AM, Stefan Anzinger wrote: > Hello, > > this RFR fixes 8161550. JVMCI must not return intrinsified MethodHandle > methods. The test had to be updated and the shortcut evaluation in > HotSpotResolvedObjectTypeImpl.resolveMethod needs take care of this fact. > > http://cr.openjdk.java.net/~sanzinger/8161550/webrev.00/ > > Stefan From david.holmes at oracle.com Wed Aug 3 07:41:54 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 3 Aug 2016 17:41:54 +1000 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: <160607E6-2021-4BA3-A9AB-72E59E721E78@oracle.com> References: <88A2872D-70F9-48DB-94B1-4314B3D9D217@oracle.com> <3933D052-50B2-43F1-AA20-2E75F60B61CE@oracle.com> <3f6719ad-95a3-12eb-572a-8c171306fc8d@oracle.com> <94572805-06D5-456B-B73E-70BBD642CA22@oracle.com> <59522cd6-3823-bfa2-8785-bb472dd875ca@oracle.com> <160607E6-2021-4BA3-A9AB-72E59E721E78@oracle.com> Message-ID: On 2/08/2016 4:46 AM, Kim Barrett wrote: > This updated webrev addresses the concerns around initialization order > for Throwable and OutOfMemoryError. It doesn't address the VM API > used by the reference processor thread; that will be in a later > webrev. > > New webrevs: > full: http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.02/ > incr: http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.02.incr/ > > The jdk tree is unchanged from webrev.01. > > I've backed out the change to initialize_java_lang_classes. (To > verify this, look at the runtime/thread.cpp in the full webrev.) > > Instead, Universe::gen_out_of_memory_error now also requires Throwable > to be initialized before it will attempt to fill in the stack trace. > This means that VM generated OOMEs occurring early in initialization > won't have a stack trace. This change looks good to me. Thanks, David > An alternative that I considered was to remove the assert at the end > of fill_in_stack_trace_of_preallocated_backtrace that requires > java_lang_Throwable;:unassigned_stacktrace() to return non-NULL. I > did some testing that seemed to work and provide stacktraces, relying > on code in the Throwable class that special cases this "out of > protocol" state. However, having read some of the history around that > (JDK-6998871, JDK-7045138, JDK-7046490), that special casing seems to > have been intended to be temporary, and expected to be removed. > (Though I didn't find an RFE for doing so, and I'm not doing so here.) > Even if we decided it wasn't going to be removed, this approach seems > somewhat fragile. > > [Note to Coleen: This is the reverse of what you and I talked about a > few days ago; I hadn't reviewed the history carefully then.] > From trevor.d.watson at oracle.com Wed Aug 3 09:03:20 2016 From: trevor.d.watson at oracle.com (Trevor Watson) Date: Wed, 3 Aug 2016 10:03:20 +0100 Subject: RFR: JDK-8141634 Implement VarHandles/Unsafe intrinsics on SPARC In-Reply-To: <57A12FCC.7070702@oracle.com> References: <7ebde74d-dd50-bfa8-4f2f-502088348c0d@oracle.com> <57A12FCC.7070702@oracle.com> Message-ID: <437e6887-c93e-6556-e2a9-c81eaca59b8b@oracle.com> Thanks Vladimir! On 03/08/16 00:42, Vladimir Kozlov wrote: > Looks good. Our group will sponsor it. > > Thanks, > Vladimir > > On 7/29/16 1:37 AM, Trevor Watson wrote: >> Summary: >> >> SPARC assembler implementations of the compareAndExchange* intrinsics >> and the addition of the WeakCompareAndSwap* matchers. >> >> Have successfully run the 'gmake test' target and the benchmarks >> mentioned in the bug report. >> >> Benchmarks for the compareAndExchange* intrinsic operations now show >> an approximate 9x-20x improvement: >> >> Before: >> Benchmark Mode Cnt Score Error >> Units >> caeAcquire.IntTest.varHandle avgt 15 351.933 ? 7.161 >> ns/op >> caeAcquire.LongTest.varHandle avgt 15 435.872 ? 3.129 >> ns/op >> caeAcquire.ObjectTest.varHandle avgt 15 975.728 ? 88.362 >> ns/op >> caeRelease.IntTest.varHandle avgt 15 346.391 ? 2.798 >> ns/op >> caeRelease.LongTest.varHandle avgt 15 439.734 ? 9.739 >> ns/op >> caeRelease.ObjectTest.varHandle avgt 15 934.279 ? 19.454 >> ns/op >> caeVolatile.IntTest.varHandle avgt 15 346.076 ? 1.771 >> ns/op >> caeVolatile.LongTest.varHandle avgt 15 436.788 ? 1.825 >> ns/op >> caeVolatile.ObjectTest.varHandle avgt 15 935.250 ? 59.526 >> ns/op >> >> With new intrinsic implementation: >> caeAcquire.IntTest.varHandle avgt 15 38.514 ? 0.974 ns/op >> caeAcquire.LongTest.varHandle avgt 15 38.411 ? 0.359 ns/op >> caeAcquire.ObjectTest.varHandle avgt 15 42.616 ? 0.916 ns/op >> caeRelease.IntTest.varHandle avgt 15 38.235 ? 0.185 ns/op >> caeRelease.LongTest.varHandle avgt 15 38.165 ? 0.145 ns/op >> caeRelease.ObjectTest.varHandle avgt 15 42.320 ? 0.156 ns/op >> caeVolatile.IntTest.varHandle avgt 15 38.321 ? 0.221 ns/op >> caeVolatile.LongTest.varHandle avgt 15 38.270 ? 0.198 ns/op >> caeVolatile.ObjectTest.varHandle avgt 15 42.541 ? 0.720 ns/op >> >> >> Webrev: http://cr.openjdk.java.net/~alanbur/JDK-8141634/ >> Bug link: https://bugs.openjdk.java.net/browse/JDK-8141634 From sean.coffey at oracle.com Wed Aug 3 11:32:01 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 3 Aug 2016 12:32:01 +0100 Subject: [8u] request for approval: "8152172: PPC64: Support AES intrinsics" In-Reply-To: References: <5637bef2-120c-9d3b-80e1-2e2b7a57e78c@oracle.com> Message-ID: <57A1D631.10500@oracle.com> On 02/08/16 20:47, Volker Simonis wrote: > Hi Sean, > > thanks a lot for your reply. > > You're right - I'm still waiting for a review of the hotspot part. Any > volunteers :) OK - would be good to get a hotspot reviewer to look at those first. > > Regarding the noreg label: I used 'noreg-other' because there already > exist AES tests (they have never been part of this original change). > Is that the right label? There are simply too many different noreg > labels without documentation so if I selected the wrong one, please > advice which one to choose. noreg labels are documented at : http://openjdk.java.net/guide/changePlanning.html#noreg noreg-other seems fine. You might want to add a short comment to bug outlining your comment on existing AES tests. regards, Sean. > > Thanks, > Volker > > > On Tue, Aug 2, 2016 at 9:58 AM, Se?n Coffey wrote: >> Volker, >> >> Have the jdk8u hotspot edits been reviewed ? Looks like they should be. >> >> Can you add a suitable noreg label to the master bug report also. >> >> Regards, >> Sean. >> >> >> On 29/07/2016 19:58, Volker Simonis wrote: >>> Ping! >>> >>> Can I please have an approval for backporting this change to 8u-dev? >>> >>> Thanks, >>> Volker >>> >>> >>> On Fri, Jul 22, 2016 at 11:08 AM, Volker Simonis >>> wrote: >>>> Hi, >>>> >>>> could you please approve the backport of the following, mostly ppc64 >>>> change to jdk8u-dev: >>>> >>>> 8152172: PPC64: Support AES intrinsics >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8152172 >>>> Webrev: http://cr.openjdk.java.net/~simonis/webrevs/2016/8152172_8u_hs/ >>>> Webrev http://cr.openjdk.java.net/~simonis/webrevs/2016/8152172_8u_jdk/ >>>> Review: >>>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-March/thread.html#22032 >>>> URL:http://hg.openjdk.java.net/jdk9/hs-comp/jdk/rev/74bc7be0777b >>>> URL:http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/68394bf0a09f >>>> >>>> As you can see, the change consists of two parts - the main one in the >>>> hotpsot repo and a small part in the jdk repo. >>>> >>>> The jdk part applied cleanly to jdk8u (with the usual directory >>>> shuffling). >>>> >>>> The hotspot part required a small tweak, but only in the ppc-only >>>> part. This is because the feature detection for the AES instructions >>>> was already active in jdk9 when the original change was made but is >>>> not available in jdk8u until now. You can find the additional changes >>>> at the end of this mail for your convenience. >>>> >>>> The required shared changes cleanly apply to jdk8u. >>>> >>>> As Vladimir pointed out in a previous thread, shared Hotspot changes >>>> have to go through JPRT even in jdk8u-dev. So I need a sponsor to do >>>> that and synchronously push both parts. >>>> >>>> @Hiroshii: could you please verify that you are fine with the change? >>>> I've done some tests on Power8LE but just want to be sure this >>>> downport satisfies your needs as well. >>>> >>>> Thank you and best regards, >>>> Volker >>>> >>>> ===================== >>>> >>>> diff -r 15928d255046 src/cpu/ppc/vm/vm_version_ppc.cpp >>>> --- a/src/cpu/ppc/vm/vm_version_ppc.cpp Wed Jul 13 00:47:40 2016 -0700 >>>> +++ b/src/cpu/ppc/vm/vm_version_ppc.cpp Fri Jul 22 10:32:36 2016 +0200 >>>> @@ -452,6 +476,7 @@ >>>> a->popcntw(R7, R5); // code[7] -> popcntw >>>> a->fcfids(F3, F4); // code[8] -> fcfids >>>> a->vand(VR0, VR0, VR0); // code[9] -> vand >>>> + a->vcipher(VR0, VR1, VR2); // code[10] -> vcipher >>>> a->blr(); >>>> >>>> // Emit function to set one cache line to zero. Emit function >>>> descriptor and get pointer to it. >>>> @@ -495,6 +520,7 @@ >>>> if (code[feature_cntr++]) features |= popcntw_m; >>>> if (code[feature_cntr++]) features |= fcfids_m; >>>> if (code[feature_cntr++]) features |= vand_m; >>>> + if (code[feature_cntr++]) features |= vcipher_m; >>>> >>>> // Print the detection code. >>>> if (PrintAssembly) { >>>> diff -r 15928d255046 src/cpu/ppc/vm/vm_version_ppc.hpp >>>> --- a/src/cpu/ppc/vm/vm_version_ppc.hpp Wed Jul 13 00:47:40 2016 -0700 >>>> +++ b/src/cpu/ppc/vm/vm_version_ppc.hpp Fri Jul 22 10:32:36 2016 +0200 >>>> @@ -42,6 +42,7 @@ >>>> fcfids, >>>> vand, >>>> dcba, >>>> + vcipher, >>>> num_features // last entry to count features >>>> }; >>>> enum Feature_Flag_Set { >>>> @@ -56,6 +57,7 @@ >>>> fcfids_m = (1 << fcfids ), >>>> vand_m = (1 << vand ), >>>> dcba_m = (1 << dcba ), >>>> + vcipher_m = (1 << vcipher), >>>> all_features_m = -1 >>>> }; >>>> static int _features; >>>> @@ -83,6 +85,7 @@ >>>> static bool has_fcfids() { return (_features & fcfids_m) != 0; } >>>> static bool has_vand() { return (_features & vand_m) != 0; } >>>> static bool has_dcba() { return (_features & dcba_m) != 0; } >>>> + static bool has_vcipher() { return (_features & vcipher_m) != 0; } >>>> >>>> static const char* cpu_features() { return _features_str; } >> From frederic.parain at oracle.com Wed Aug 3 13:15:21 2016 From: frederic.parain at oracle.com (Frederic Parain) Date: Wed, 3 Aug 2016 09:15:21 -0400 Subject: RFR 8159284: bigapps/Jetty - assert(jfa->last_Java_sp() > sp()) failed with tracing code in use In-Reply-To: <566f441f-22ed-5c14-6129-afdea58df8f9@oracle.com> References: <49266448-6924-c5fd-5ab1-27fb4fad4301@oracle.com> <821c378c-9b78-2f5c-dda6-a2c85c0c9d4e@oracle.com> <566f441f-22ed-5c14-6129-afdea58df8f9@oracle.com> Message-ID: Looks good to me. Thank you for the renaming. Fred On 08/02/2016 06:19 PM, Coleen Phillimore wrote: > > > On 8/2/16 6:08 PM, Coleen Phillimore wrote: >> >> Hi, I have another webrev with the name change of >> is_entry_frame_valid(), which passes JPRT. > > http://cr.openjdk.java.net/~coleenp/8159284.02/webrev/index.html > >> >> thanks, >> Coleen >> >> >> On 8/2/16 2:28 PM, Frederic Parain wrote: >>> >>> >>> On 08/02/2016 02:22 PM, Coleen Phillimore wrote: >>>> >>>> Fred, Thank you for reviewing this. >>>> >>>> On 8/2/16 2:02 PM, Frederic Parain wrote: >>>>> Coleen, >>>>> >>>>> src/cpu/aarch64/vm/frame_aarch64.cpp >>>>> >>>>> line 116: return entry_frame_is_safe(thread); >>>>> line 207: return sender.is_entry_frame_safe(thread); >>>>> >>>>> Method names are different, is it a typo? >>>>> >>>> >>>> Yes, it is a typo. Thank you for catching it. >>>> >>>>> src/cpu/sparc/vm/frame_sparc.cpp >>>>> >>>>> No comments >>>>> >>>>> src/cpu/x86/vm/frame_x86.cpp >>>>> >>>>> No comments >>>>> >>>>> src/share/vm/runtime/frame.cpp >>>>> >>>>> No comments >>>>> >>>>> src/share/vm/runtime/frame.hpp >>>>> >>>>> I would expect the new method name to be is_entry_frame_safe() >>>>> as most tester methods begin with "is_" but I this is just a >>>>> personal opinion. >>>> >>>> I named it entry_frame_is_safe() because I thought it looked less >>>> redundant and more distinct in the code fragments where they occurred: >>>> >>>> // Entry frame checks >>>> if (is_entry_frame()) { >>>> // an entry frame must have a valid fp. >>>> >>>> if (!fp_safe) return false; >>>> >>>> return entry_frame_is_safe(thread); >>>> } >>>> >>>> is_entry_frame_safe() looks like is_entry_frame() or implies it's a >>>> "safe" call to is_entry_frame. >>>> >>>> I guess it is the standard to start with 'is' for these sorts of >>>> tests. How about is_safe_entry_frame() ? >>> >>> Sounds good. >>> >>> Fred >>> >>>> thanks, >>>> Coleen >>>> >>>>> >>>>> Fred >>>>> >>>>> On 08/01/2016 07:38 PM, Coleen Phillimore wrote: >>>>>> Summary: Test condition in assert in frame::safe_for_sender() for >>>>>> entry >>>>>> frames and return false. >>>>>> >>>>>> This bug is for a confidential part of the project that needs more >>>>>> robustness checks to verify that frame::sender() can be called. >>>>>> >>>>>> Also refactored into frame::entry_frame_is_safe() because these >>>>>> platforms had the same code for entry frames to determine whether >>>>>> it is >>>>>> still safe to trust this frame to call sender(). These platforms had >>>>>> also the same assert in sender_for_entry_frame() that the sampling >>>>>> code >>>>>> hit. >>>>>> >>>>>> Tested with our nightly tests on all platforms and bigapps/Jetty. >>>>>> >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8159284.01/webrev >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>>>> >>>> >> > From martin.doerr at sap.com Wed Aug 3 13:17:39 2016 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 3 Aug 2016 13:17:39 +0000 Subject: RFR(S) 8162369: PPC64: Wrong ucontext used after SIGTRAP while in HTM critical section In-Reply-To: <57A104CC.7090608@linux.vnet.ibm.com> References: <57A104CC.7090608@linux.vnet.ibm.com> Message-ID: <2e4fa52ec9764949a7708043e1c3574a@DEWDFE13DE14.global.corp.sap> Hi Gustavo, thank you very much for providing the webrev and doing experiments. A couple of questions came into my mind when taking a look at it: 1. A future C++ compiler or runtime code may use HTM, too. Should your new code get invoked in such a case? Or is it only for transactions which were started in the code cache (UseRTMLocking)? 2. I was wondering why you only check for zombie_not_entrant. There are many cases in which a signal may occur during a transaction (e.g. implicit null check, range check, stack overflow check, safepoint poll, ... and possibly more in the future). What about them? I guess continuing execution in the context of the 'treclaim'ed transaction is incorrect. 3. I think reporting errors which occur during transactions is cool. But if it's too complex, I could live without it. Other platforms don't support this either (they just abort by hardware). I was not involved in the earlier discussion. Maybe I missed something. Thanks and best regards, Martin -----Original Message----- From: Gustavo Romero [mailto:gromero at linux.vnet.ibm.com] Sent: Dienstag, 2. August 2016 22:39 To: ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Cc: Thomas St?fe ; Doerr, Martin ; Lindenmaier, Goetz ; Breno Leitao Subject: RFR(S) 8162369: PPC64: Wrong ucontext used after SIGTRAP while in HTM critical section Importance: High Hi, Could the following webrev be hosted and reviewed, please? Webrev: http://81.de.7a9f.ip4.static.sl-reverse.com/8162369/v1 CR: https://bugs.openjdk.java.net/browse/JDK-8162369 Thomas, I've tested the proposed fix under two different (unexpected) error conditions that can happen when in an HTM transaction: a SIGSEGV and a SIGILL. Since reporting pc at tbegin+4 is misleading, in both cases the correct context for error reporting is the second (transactional). Then: 1) in a segmentation fault in the middle of a transaction it will be reported correctly, like this: # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00003fff4c2dffac, pid=31046, tid=31047 siginfo: si_signo: 11 (SIGSEGV), si_code: 1 (SEGV_MAPERR), si_addr: 0x0000000000000000 Hence when we inspect the offending location indicated by the pc value in the hs_err log we find the right root cause of the SIGSEGV: (gdb) disas 0x00003fff4c2dffac-4,+8 Dump of assembler code from 0x3fff4c2dffa8 to 0x3fff4c2dffb0: 0x00003fff4c2dffa8: li r15,0 0x00003fff4c2dffac: ld r15,0(r15) End of assembler dump. Tested by the injection of a load from memory position 0x0, accordingly to this patch: https://paste.fedoraproject.org/400032/ Full log hs_err log: http://paste.fedoraproject.org/400035/raw/ 2) in an illegal instruction in the middle of a transaction it will be reported correctly as well, like this: # # A fatal error has been detected by the Java Runtime Environment: # # SIGILL (0x4) at pc=0x00003fff7c2dd930, pid=21140, tid=21141 siginfo: si_signo: 4 (SIGILL), si_code: 1 (ILL_ILLOPC), si_addr: 0x00003fff7c2dd930 Hence when we inspect the offending location indicated by the pc value we find the right offending instruction: (gdb) disas 0x00003fff7c2dd930-4,+8 Dump of assembler code from 0x3fff7c2dd92c to 0x3fff7c2dd934: 0x00003fff7c2dd92c: cmpwi cr6,r0,1 0x00003fff7c2dd930: .long 0xea2f0013 End of assembler dump. Tested by the injection of a illegal instruction, accordingly to this patch: https://paste.fedoraproject.org/400080/ Full log hs_err log: https://paste.fedoraproject.org/400073/raw/ Martin, although the detection using is_tbegin() is equivalent to checking the uc_link pointer, I've decided to use the detection suggested by the Linux kernel documentation, i.e checking the uc_link pointer plus the MSR TS bits. As you said it's not an issue since uc_link isn't new and the msr register isn't also new. So this kind of check will compile on both PPC64 LE and BE fine. Thank you for sponsoring the change. No regression was observed. One additional test now passes: Passed: compiler/rtm/cli/TestUseRTMForStackLocksOptionOnSupportedConfig.java Thank you! Best regards, Gustavo From coleen.phillimore at oracle.com Wed Aug 3 13:35:41 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 3 Aug 2016 09:35:41 -0400 Subject: RFR 8159284: bigapps/Jetty - assert(jfa->last_Java_sp() > sp()) failed with tracing code in use In-Reply-To: References: <49266448-6924-c5fd-5ab1-27fb4fad4301@oracle.com> <821c378c-9b78-2f5c-dda6-a2c85c0c9d4e@oracle.com> <566f441f-22ed-5c14-6129-afdea58df8f9@oracle.com> Message-ID: <1e15c7ff-2798-0253-6f1e-309214e06cc1@oracle.com> Thank you, Fred. Coleen On 8/3/16 9:15 AM, Frederic Parain wrote: > Looks good to me. > Thank you for the renaming. > > Fred > > On 08/02/2016 06:19 PM, Coleen Phillimore wrote: >> >> >> On 8/2/16 6:08 PM, Coleen Phillimore wrote: >>> >>> Hi, I have another webrev with the name change of >>> is_entry_frame_valid(), which passes JPRT. >> >> http://cr.openjdk.java.net/~coleenp/8159284.02/webrev/index.html >> >>> >>> thanks, >>> Coleen >>> >>> >>> On 8/2/16 2:28 PM, Frederic Parain wrote: >>>> >>>> >>>> On 08/02/2016 02:22 PM, Coleen Phillimore wrote: >>>>> >>>>> Fred, Thank you for reviewing this. >>>>> >>>>> On 8/2/16 2:02 PM, Frederic Parain wrote: >>>>>> Coleen, >>>>>> >>>>>> src/cpu/aarch64/vm/frame_aarch64.cpp >>>>>> >>>>>> line 116: return entry_frame_is_safe(thread); >>>>>> line 207: return sender.is_entry_frame_safe(thread); >>>>>> >>>>>> Method names are different, is it a typo? >>>>>> >>>>> >>>>> Yes, it is a typo. Thank you for catching it. >>>>> >>>>>> src/cpu/sparc/vm/frame_sparc.cpp >>>>>> >>>>>> No comments >>>>>> >>>>>> src/cpu/x86/vm/frame_x86.cpp >>>>>> >>>>>> No comments >>>>>> >>>>>> src/share/vm/runtime/frame.cpp >>>>>> >>>>>> No comments >>>>>> >>>>>> src/share/vm/runtime/frame.hpp >>>>>> >>>>>> I would expect the new method name to be is_entry_frame_safe() >>>>>> as most tester methods begin with "is_" but I this is just a >>>>>> personal opinion. >>>>> >>>>> I named it entry_frame_is_safe() because I thought it looked less >>>>> redundant and more distinct in the code fragments where they >>>>> occurred: >>>>> >>>>> // Entry frame checks >>>>> if (is_entry_frame()) { >>>>> // an entry frame must have a valid fp. >>>>> >>>>> if (!fp_safe) return false; >>>>> >>>>> return entry_frame_is_safe(thread); >>>>> } >>>>> >>>>> is_entry_frame_safe() looks like is_entry_frame() or implies it's a >>>>> "safe" call to is_entry_frame. >>>>> >>>>> I guess it is the standard to start with 'is' for these sorts of >>>>> tests. How about is_safe_entry_frame() ? >>>> >>>> Sounds good. >>>> >>>> Fred >>>> >>>>> thanks, >>>>> Coleen >>>>> >>>>>> >>>>>> Fred >>>>>> >>>>>> On 08/01/2016 07:38 PM, Coleen Phillimore wrote: >>>>>>> Summary: Test condition in assert in frame::safe_for_sender() for >>>>>>> entry >>>>>>> frames and return false. >>>>>>> >>>>>>> This bug is for a confidential part of the project that needs more >>>>>>> robustness checks to verify that frame::sender() can be called. >>>>>>> >>>>>>> Also refactored into frame::entry_frame_is_safe() because these >>>>>>> platforms had the same code for entry frames to determine whether >>>>>>> it is >>>>>>> still safe to trust this frame to call sender(). These platforms >>>>>>> had >>>>>>> also the same assert in sender_for_entry_frame() that the sampling >>>>>>> code >>>>>>> hit. >>>>>>> >>>>>>> Tested with our nightly tests on all platforms and bigapps/Jetty. >>>>>>> >>>>>>> open webrev at >>>>>>> http://cr.openjdk.java.net/~coleenp/8159284.01/webrev >>>>>>> >>>>>>> Thanks, >>>>>>> Coleen >>>>>>> >>>>> >>> >> From dmitrij.pochepko at oracle.com Wed Aug 3 13:25:18 2016 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Wed, 3 Aug 2016 16:25:18 +0300 Subject: RFR(S): 8162727 - Testbug: additional requires properties can't be used for filtering server vm in jdk jtreg tests In-Reply-To: <579BA386.20608@oracle.com> References: <579A3EB9.7060704@oracle.com> <579AB182.8040502@oracle.com> <9491a957-7368-b373-b676-1987ba814550@oracle.com> <579BA386.20608@oracle.com> Message-ID: <57A1F0BE.7040505@oracle.com> Hi, can somebody with official reviewer role review this? Thanks, Dmitrij On 29.07.2016 21:42, Dmitrij Pochepko wrote: > Sure, > > now including core-libs-dev > > Thanks, > Dmitrij > > On 29.07.2016 20:16, joe darcy wrote: >> Hello, >> >> I also recommend sending this review request over to core-libs-dev >> since it affect the jdk repo. >> >> Thanks, >> >> -Joe >> >> >> On 7/29/2016 12:35 AM, Dmitry Fazunenko wrote: >>> Hi Dmitrij, >>> >>> The change itself looks good. >>> >>> One note: this change adds a little overhead (a very little) for >>> running tests in jdk repository, but it's required only for VM >>> specific tests stored in jdk. As alternative of this change I can >>> suggest moving VM specific tests from the 'jdk' to 'hotspot' >>> repository. Perhaps, such massive update is too late for JDK9 time >>> frame and could be done only in JDK10. >>> So, if the changes depending on 8162727 are not so critical and >>> could be deferred I would prefer to postpone this fix. >>> >>> Thanks, >>> Dima >>> >>> >>> On 29.07.2016 4:29, Vladimir Kozlov wrote: >>>> It affects all groups. Should be reviewed on hotspot-dev. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 7/28/16 10:19 AM, Dmitrij Pochepko wrote: >>>>> Hi, >>>>> >>>>> please review small patch for 8162727 - Testbug: additional >>>>> requires properties can't be used for filtering server vm in jdk >>>>> jtreg tests >>>>> >>>>> A problem is that tests under jdk repo can't use additional jtreg >>>>> requires properties(like vm.flavor to filter out client or server >>>>> vm). The same functionality was introduced for hotspot repo as part >>>>> of JDK-8154956. So, in order to filter tests using these >>>>> additional properties a small fix is created. >>>>> >>>>> webrev: http://cr.openjdk.java.net/~dpochepk/8162727/webrev.01/ >>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8162727 >>>>> >>>>> Thanks, >>>>> Dmitrij >>> >> > From kim.barrett at oracle.com Wed Aug 3 18:21:17 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 3 Aug 2016 14:21:17 -0400 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: References: <88A2872D-70F9-48DB-94B1-4314B3D9D217@oracle.com> <3933D052-50B2-43F1-AA20-2E75F60B61CE@oracle.com> <3f6719ad-95a3-12eb-572a-8c171306fc8d@oracle.com> <94572805-06D5-456B-B73E-70BBD642CA22@oracle.com> <59522cd6-3823-bfa2-8785-bb472dd875ca@oracle.com> <160607E6-2021-4BA3-A9AB-72E59E721E78@oracle.com> Message-ID: <687D0D66-6E84-49FA-9384-D4CB111755AF@oracle.com> > On Aug 3, 2016, at 3:41 AM, David Holmes wrote: > > On 2/08/2016 4:46 AM, Kim Barrett wrote: >> This updated webrev addresses the concerns around initialization order >> for Throwable and OutOfMemoryError. It doesn't address the VM API >> used by the reference processor thread; that will be in a later >> webrev. >> >> New webrevs: >> full: http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.02/ >> incr: http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.02.incr/ >> >> The jdk tree is unchanged from webrev.01. >> >> I've backed out the change to initialize_java_lang_classes. (To >> verify this, look at the runtime/thread.cpp in the full webrev.) >> >> Instead, Universe::gen_out_of_memory_error now also requires Throwable >> to be initialized before it will attempt to fill in the stack trace. >> This means that VM generated OOMEs occurring early in initialization >> won't have a stack trace. > > This change looks good to me. Thanks! From david.holmes at oracle.com Wed Aug 3 20:56:29 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 4 Aug 2016 06:56:29 +1000 Subject: RFR(S): 8162727 - Testbug: additional requires properties can't be used for filtering server vm in jdk jtreg tests In-Reply-To: <57A1F0BE.7040505@oracle.com> References: <579A3EB9.7060704@oracle.com> <579AB182.8040502@oracle.com> <9491a957-7368-b373-b676-1987ba814550@oracle.com> <579BA386.20608@oracle.com> <57A1F0BE.7040505@oracle.com> Message-ID: Hi Dmitrij, I know this reflects the changes made in hotspot/test but I have a query. Does this: + requires.extraPropDefns.vmOpts = -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI -Xbootclasspath/a:bootClasses mean that the VM under test is executed with those additional flags when running the tests? Or is it run once with those flags to establish the "requires" properties? If the latter then I have no concern and this change seems fine. Thanks, David On 3/08/2016 11:25 PM, Dmitrij Pochepko wrote: > Hi, > > can somebody with official reviewer role review this? > > Thanks, > Dmitrij > > On 29.07.2016 21:42, Dmitrij Pochepko wrote: >> Sure, >> >> now including core-libs-dev >> >> Thanks, >> Dmitrij >> >> On 29.07.2016 20:16, joe darcy wrote: >>> Hello, >>> >>> I also recommend sending this review request over to core-libs-dev >>> since it affect the jdk repo. >>> >>> Thanks, >>> >>> -Joe >>> >>> >>> On 7/29/2016 12:35 AM, Dmitry Fazunenko wrote: >>>> Hi Dmitrij, >>>> >>>> The change itself looks good. >>>> >>>> One note: this change adds a little overhead (a very little) for >>>> running tests in jdk repository, but it's required only for VM >>>> specific tests stored in jdk. As alternative of this change I can >>>> suggest moving VM specific tests from the 'jdk' to 'hotspot' >>>> repository. Perhaps, such massive update is too late for JDK9 time >>>> frame and could be done only in JDK10. >>>> So, if the changes depending on 8162727 are not so critical and >>>> could be deferred I would prefer to postpone this fix. >>>> >>>> Thanks, >>>> Dima >>>> >>>> >>>> On 29.07.2016 4:29, Vladimir Kozlov wrote: >>>>> It affects all groups. Should be reviewed on hotspot-dev. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 7/28/16 10:19 AM, Dmitrij Pochepko wrote: >>>>>> Hi, >>>>>> >>>>>> please review small patch for 8162727 - Testbug: additional >>>>>> requires properties can't be used for filtering server vm in jdk >>>>>> jtreg tests >>>>>> >>>>>> A problem is that tests under jdk repo can't use additional jtreg >>>>>> requires properties(like vm.flavor to filter out client or server >>>>>> vm). The same functionality was introduced for hotspot repo as part >>>>>> of JDK-8154956. So, in order to filter tests using these >>>>>> additional properties a small fix is created. >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~dpochepk/8162727/webrev.01/ >>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8162727 >>>>>> >>>>>> Thanks, >>>>>> Dmitrij >>>> >>> >> > From max.ockner at oracle.com Wed Aug 3 21:12:19 2016 From: max.ockner at oracle.com (Max Ockner) Date: Wed, 03 Aug 2016 17:12:19 -0400 Subject: RFR(XS): 8145543: Removed @ignore for compiler/floatingpoint/ModNaN.java Message-ID: <57A25E33.2020104@oracle.com> Hello, Please review this extra small change. There was supposedly a bug which caused compiler/floatingpoint/ModNaN.java to fail, but this bug is not reproducible. I have removed the @ignore for this test. bug: https://bugs.openjdk.java.net/browse/JDK-8145543 webrev: http://cr.openjdk.java.net/~mockner/8145543/ I ran this change through jprt several times and saw no failure. I also had clean runs on several other machines, including a Standard Oracle Linux linux-x64 JDK9 machine. This issue that caused this bug originally (https://sourceware.org/bugzilla/show_bug.cgi?id=14048) has been patched, and the patch has been backported to previous versions. It is now very difficult to find a machine which is far enough out of date to still have this issue. Thanks, Max From coleen.phillimore at oracle.com Wed Aug 3 21:18:06 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 3 Aug 2016 17:18:06 -0400 Subject: RFR(XS): 8145543: Removed @ignore for compiler/floatingpoint/ModNaN.java In-Reply-To: <57A25E33.2020104@oracle.com> References: <57A25E33.2020104@oracle.com> Message-ID: <05d85bf1-fdda-6539-4849-004f3df9380b@oracle.com> Looks good, Max. Thanks, Coleen On 8/3/16 5:12 PM, Max Ockner wrote: > Hello, > Please review this extra small change. There was supposedly a bug > which caused compiler/floatingpoint/ModNaN.java to fail, but this bug > is not reproducible. I have removed the @ignore for this test. > > bug: https://bugs.openjdk.java.net/browse/JDK-8145543 > webrev: http://cr.openjdk.java.net/~mockner/8145543/ > > I ran this change through jprt several times and saw no failure. I > also had clean runs on several other machines, including a Standard > Oracle Linux linux-x64 JDK9 machine. This issue that caused this bug > originally (https://sourceware.org/bugzilla/show_bug.cgi?id=14048) has > been patched, and the patch has been backported to previous versions. > It is now very difficult to find a machine which is far enough out of > date to still have this issue. > > Thanks, > Max > From chris.plummer at oracle.com Thu Aug 4 04:35:09 2016 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 3 Aug 2016 21:35:09 -0700 Subject: RFR(XS): 8162670: make of jtreg_tests fails if no tests are run, causing jprt test runs to also fail In-Reply-To: References: <8bbb54eb-e179-6c10-5d18-7838f08e847e@oracle.com> <4579a80c-6eb8-27e0-4e0d-cd68e6420df0@oracle.com> <6ac6f874-ce28-bc37-cd0f-575ce45af452@oracle.com> Message-ID: Unfortunately I need another review of these changes. I ran into a minor problem. Although all the jprt testing I tried passed, when I looked into the log files I noticed an issue. I saw the following: Test results: passed: 1 Report written to /opt/jprt/T/P1/003906.cplummer/s/hotspot/testoutput/JTreport/html/report.html Results written to /opt/jprt/T/P1/003906.cplummer/s/hotspot/testoutput/JTwork /bin/sh: 15: [: 0: unexpected operator Summary: TEST STATS: name= run=1 pass=1 fail=0 EXIT CODE: 0 EXIT CODE: 0 Notice the "unexpected operator" message in the middle. This only happens on our arm platforms. It doesn't seem to affect the test results, but should be cleaned up anyway. The "0" turns out to be the exit code. I see the same message if a test fails, except the 0 changes to a 2. Looking more closely at the code I added, I see I used ==, whereas other code nearby uses =. I change it to = and the error message went away. I retested with various test cases that fail, pass, or run no tests, and all of them do as expected still. New webrev can be found at: http://cr.openjdk.java.net/~cjplummer/8162670/webrev-02/ thanks, Chris On 8/2/16 7:50 AM, Chris Plummer wrote: > On 8/1/16 9:30 PM, Chris Plummer wrote: >> On 8/1/16 7:25 PM, David Holmes wrote: >>> On 2/08/2016 12:11 PM, Chris Plummer wrote: >>>> On 8/1/16 5:58 PM, David Holmes wrote: >>>>> Hi Chris, >>>>> >>>>> On 2/08/2016 8:46 AM, Chris Plummer wrote: >>>>>> Hello, >>>>>> >>>>>> Please review this simple change: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8162670 >>>>>> http://cr.openjdk.java.net/~cjplummer/8162670/webrev-00/ >>>>> >>>>> You've split a compound expression with your code: >>>>> >>>>> 227 jtregExitCode=$$? && \ >>>>> 228 if [ $${jtregExitCode} == 1 ]; then \ >>>>> 229 jtregExitCode=0; \ >>>>> 230 fi ; \ >>>>> 231 _summary="$(SUMMARY_TXT)"; \ >>>>> >>>>> I'm not clear exactly why the && was needed here but rather than find >>>>> out later I suggest rearranging the above to: >>>>> >>>>> jtregExitCode=$$? && \ >>>>> _summary="$(SUMMARY_TXT)"; \ >>>>> if [ $${jtregExitCode} == 1 ]; then \ >>>>> jtregExitCode=0; \ >>>>> fi ; \ >>>>> >>>> Yeah, that makes sense. I'll make the change. However, it's really >>>> unclear what the use case for && is here. How can jtregExitCode=$$? >>>> ever >>>> fail? >>> >>> I wonder if it evaluates to the $? value and so only sets _summary >>> if we had a zero exit code? (Not that I understand why we would only >>> set _summary in that context.) >> I tried the following: >> >> bash-4.1$ x=0 && echo "foo"; >> >> And "foo" is always printed. I also tried non-zero values for x. Here >> are some other examples: >> >> bash-4.1$ (exit 1) && echo "foo" >> bash-4.1$ (exit 0) && echo "foo" >> foo >> >> Commands evaluate to true if the exit status is 0, and false >> otherwise, so I guess you could say commands evaluate to !?$. For &&, >> the rhs is only executed if the lhs has a zero exit status. > Updated webrev: > > http://cr.openjdk.java.net/~cjplummer/8162670/webrev-01/ > > thanks, > > Chris >> >> Chris >>> >>> David >>> >>>> thanks, >>>> >>>> Chris >>>>> Thanks, >>>>> David >>>>> >>>>>> Note the copyright dates haven't been updated in this webrev, but >>>>>> I did >>>>>> update them locally after noticing that. >>>>>> >>>>>> Tested with jprt test case given in the CR, and also with a jprt run >>>>>> using "testset -hotspot" to make sure I didn't break anything. >>>>>> >>>>>> thanks, >>>>>> >>>>>> Chris >>>> >>>> >> > From david.holmes at oracle.com Thu Aug 4 07:31:55 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 4 Aug 2016 17:31:55 +1000 Subject: RFR(XS): 8162670: make of jtreg_tests fails if no tests are run, causing jprt test runs to also fail In-Reply-To: References: <8bbb54eb-e179-6c10-5d18-7838f08e847e@oracle.com> <4579a80c-6eb8-27e0-4e0d-cd68e6420df0@oracle.com> <6ac6f874-ce28-bc37-cd0f-575ce45af452@oracle.com> Message-ID: <9a249ef1-2466-28da-a818-d0cb42ebe58d@oracle.com> On 4/08/2016 2:35 PM, Chris Plummer wrote: > Unfortunately I need another review of these changes. I ran into a minor > problem. Although all the jprt testing I tried passed, when I looked > into the log files I noticed an issue. I saw the following: > > Test results: passed: 1 > Report written to > /opt/jprt/T/P1/003906.cplummer/s/hotspot/testoutput/JTreport/html/report.html > > Results written to > /opt/jprt/T/P1/003906.cplummer/s/hotspot/testoutput/JTwork > /bin/sh: 15: [: 0: unexpected operator > Summary: > TEST STATS: name= run=1 pass=1 fail=0 > EXIT CODE: 0 > EXIT CODE: 0 > > Notice the "unexpected operator" message in the middle. This only > happens on our arm platforms. It doesn't seem to affect the test > results, but should be cleaned up anyway. The "0" turns out to be the > exit code. I see the same message if a test fails, except the 0 changes > to a 2. Looking more closely at the code I added, I see I used ==, > whereas other code nearby uses =. I change it to = and the error message > went away. I retested with various test cases that fail, pass, or run no > tests, and all of them do as expected still. Must be an old sh that uses a [ built-in which doesn't alias == to =. Changes look fine. Thanks, David > New webrev can be found at: > > http://cr.openjdk.java.net/~cjplummer/8162670/webrev-02/ > > thanks, > > Chris > > On 8/2/16 7:50 AM, Chris Plummer wrote: >> On 8/1/16 9:30 PM, Chris Plummer wrote: >>> On 8/1/16 7:25 PM, David Holmes wrote: >>>> On 2/08/2016 12:11 PM, Chris Plummer wrote: >>>>> On 8/1/16 5:58 PM, David Holmes wrote: >>>>>> Hi Chris, >>>>>> >>>>>> On 2/08/2016 8:46 AM, Chris Plummer wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Please review this simple change: >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8162670 >>>>>>> http://cr.openjdk.java.net/~cjplummer/8162670/webrev-00/ >>>>>> >>>>>> You've split a compound expression with your code: >>>>>> >>>>>> 227 jtregExitCode=$$? && \ >>>>>> 228 if [ $${jtregExitCode} == 1 ]; then \ >>>>>> 229 jtregExitCode=0; \ >>>>>> 230 fi ; \ >>>>>> 231 _summary="$(SUMMARY_TXT)"; \ >>>>>> >>>>>> I'm not clear exactly why the && was needed here but rather than find >>>>>> out later I suggest rearranging the above to: >>>>>> >>>>>> jtregExitCode=$$? && \ >>>>>> _summary="$(SUMMARY_TXT)"; \ >>>>>> if [ $${jtregExitCode} == 1 ]; then \ >>>>>> jtregExitCode=0; \ >>>>>> fi ; \ >>>>>> >>>>> Yeah, that makes sense. I'll make the change. However, it's really >>>>> unclear what the use case for && is here. How can jtregExitCode=$$? >>>>> ever >>>>> fail? >>>> >>>> I wonder if it evaluates to the $? value and so only sets _summary >>>> if we had a zero exit code? (Not that I understand why we would only >>>> set _summary in that context.) >>> I tried the following: >>> >>> bash-4.1$ x=0 && echo "foo"; >>> >>> And "foo" is always printed. I also tried non-zero values for x. Here >>> are some other examples: >>> >>> bash-4.1$ (exit 1) && echo "foo" >>> bash-4.1$ (exit 0) && echo "foo" >>> foo >>> >>> Commands evaluate to true if the exit status is 0, and false >>> otherwise, so I guess you could say commands evaluate to !?$. For &&, >>> the rhs is only executed if the lhs has a zero exit status. >> Updated webrev: >> >> http://cr.openjdk.java.net/~cjplummer/8162670/webrev-01/ >> >> thanks, >> >> Chris >>> >>> Chris >>>> >>>> David >>>> >>>>> thanks, >>>>> >>>>> Chris >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> Note the copyright dates haven't been updated in this webrev, but >>>>>>> I did >>>>>>> update them locally after noticing that. >>>>>>> >>>>>>> Tested with jprt test case given in the CR, and also with a jprt run >>>>>>> using "testset -hotspot" to make sure I didn't break anything. >>>>>>> >>>>>>> thanks, >>>>>>> >>>>>>> Chris >>>>> >>>>> >>> >> > From gromero at linux.vnet.ibm.com Thu Aug 4 07:36:28 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Thu, 4 Aug 2016 04:36:28 -0300 Subject: RFR(S) 8162369: PPC64: Wrong ucontext used after SIGTRAP while in HTM critical section In-Reply-To: <2e4fa52ec9764949a7708043e1c3574a@DEWDFE13DE14.global.corp.sap> References: <57A104CC.7090608@linux.vnet.ibm.com> <2e4fa52ec9764949a7708043e1c3574a@DEWDFE13DE14.global.corp.sap> Message-ID: <57A2F07C.80603@linux.vnet.ibm.com> Hi Martin, Thanks a lot for reviewing. On 03-08-2016 10:17, Doerr, Martin wrote: > 1. A future C++ compiler or runtime code may use HTM, too. Should your new code get invoked in such a case? Or is it only for transactions which were started in the code cache (UseRTMLocking)? I see. Initially I was just thinking in the case of a transaction started in the code cache, but it's fine for a runtime code to use HTM and generate a signal in the middle of it as we simply return the control back to the HTM abort handler (new webrev below). For a C++ compiler with TM (PPC64), I'm unable to foresee the final implementation of the atomic blocks and how it would affect the signal handler in the specific case of PPC64 (where we have two contexts due to the additional suspend TM state). Anyway I believe the abortion in an atomic block would yield an event similar to the runtime code, so in that case it's already covered. > 2. I was wondering why you only check for zombie_not_entrant. There are many cases in which a signal may occur during a transaction (e.g. implicit null check, range check, stack overflow check, safepoint poll, ... and possibly more in the future). What about them? I guess continuing execution in the context of the 'treclaim'ed transaction is incorrect. Sorry, I forgot all those cases, hence yes, it's incorrect to continue the execution in the second context (or speculated state). > 3. I think reporting errors which occur during transactions is cool. But if it's too complex, I could live without it. Other platforms don't support this either (they just abort by hardware). Yes, I was really focused on finding a way to report errors that could occur during transactions. I think it would be cool, nonetheless I agree, it's too complex (also as an implication of all the cases mentioned in 2.). > I was not involved in the earlier discussion. Maybe I missed something. No, you did not miss anything. Thomas raised the question on if two contexts exist, then which one would be correct/valid for error reporting. My try on using the second context to report precisely the root cause of an abortion was inspired by his question. new webrev: http://81.de.7a9f.ip4.static.sl-reverse.com/8162369/v2 Thanks and best regards, Gustavo From dmitry.fazunenko at oracle.com Thu Aug 4 07:55:00 2016 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Thu, 4 Aug 2016 10:55:00 +0300 Subject: RFR(S): 8162727 - Testbug: additional requires properties can't be used for filtering server vm in jdk jtreg tests In-Reply-To: References: <579A3EB9.7060704@oracle.com> <579AB182.8040502@oracle.com> <9491a957-7368-b373-b676-1987ba814550@oracle.com> <579BA386.20608@oracle.com> <57A1F0BE.7040505@oracle.com> Message-ID: <8df0b483-4f52-facf-be76-f44070371ab0@oracle.com> Hi David, On 03.08.2016 23:56, David Holmes wrote: > Hi Dmitrij, > > I know this reflects the changes made in hotspot/test but I have a > query. Does this: > > + requires.extraPropDefns.vmOpts = -XX:+UnlockDiagnosticVMOptions > -XX:+WhiteBoxAPI -Xbootclasspath/a:bootClasses > > mean that the VM under test is executed with those additional flags > when running the tests? Or is it run once with those flags to > establish the "requires" properties? That flags are used only once for establishing the "requires" properties. Thanks, Dima > > If the latter then I have no concern and this change seems fine. > > Thanks, > David > > On 3/08/2016 11:25 PM, Dmitrij Pochepko wrote: >> Hi, >> >> can somebody with official reviewer role review this? >> >> Thanks, >> Dmitrij >> >> On 29.07.2016 21:42, Dmitrij Pochepko wrote: >>> Sure, >>> >>> now including core-libs-dev >>> >>> Thanks, >>> Dmitrij >>> >>> On 29.07.2016 20:16, joe darcy wrote: >>>> Hello, >>>> >>>> I also recommend sending this review request over to core-libs-dev >>>> since it affect the jdk repo. >>>> >>>> Thanks, >>>> >>>> -Joe >>>> >>>> >>>> On 7/29/2016 12:35 AM, Dmitry Fazunenko wrote: >>>>> Hi Dmitrij, >>>>> >>>>> The change itself looks good. >>>>> >>>>> One note: this change adds a little overhead (a very little) for >>>>> running tests in jdk repository, but it's required only for VM >>>>> specific tests stored in jdk. As alternative of this change I can >>>>> suggest moving VM specific tests from the 'jdk' to 'hotspot' >>>>> repository. Perhaps, such massive update is too late for JDK9 time >>>>> frame and could be done only in JDK10. >>>>> So, if the changes depending on 8162727 are not so critical and >>>>> could be deferred I would prefer to postpone this fix. >>>>> >>>>> Thanks, >>>>> Dima >>>>> >>>>> >>>>> On 29.07.2016 4:29, Vladimir Kozlov wrote: >>>>>> It affects all groups. Should be reviewed on hotspot-dev. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 7/28/16 10:19 AM, Dmitrij Pochepko wrote: >>>>>>> Hi, >>>>>>> >>>>>>> please review small patch for 8162727 - Testbug: additional >>>>>>> requires properties can't be used for filtering server vm in jdk >>>>>>> jtreg tests >>>>>>> >>>>>>> A problem is that tests under jdk repo can't use additional jtreg >>>>>>> requires properties(like vm.flavor to filter out client or server >>>>>>> vm). The same functionality was introduced for hotspot repo as part >>>>>>> of JDK-8154956. So, in order to filter tests using these >>>>>>> additional properties a small fix is created. >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~dpochepk/8162727/webrev.01/ >>>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8162727 >>>>>>> >>>>>>> Thanks, >>>>>>> Dmitrij >>>>> >>>> >>> >> From igor.ignatyev at oracle.com Thu Aug 4 08:46:28 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 4 Aug 2016 11:46:28 +0300 Subject: RFR(S): 8162727 - Testbug: additional requires properties can't be used for filtering server vm in jdk jtreg tests In-Reply-To: <57A1F0BE.7040505@oracle.com> References: <579A3EB9.7060704@oracle.com> <579AB182.8040502@oracle.com> <9491a957-7368-b373-b676-1987ba814550@oracle.com> <579BA386.20608@oracle.com> <57A1F0BE.7040505@oracle.com> Message-ID: Dima, I?d prefer to have tests moved into hotspot repo instead. none of jdk tests should depend on vm kind or any other details of vm. your change just makes things worse, we will not just have tests which depend on vm implementation details in jdk, we will also have an mechanism for other tests to express such dependency, which can lead to increased number of ?hotspot? tests in jdk. we went similar path w/ testlibrary and we are still paying for that. so how many tests which need these properties do we have now? Thanks, ? Igor > On Aug 3, 2016, at 4:25 PM, Dmitrij Pochepko wrote: > > Hi, > > can somebody with official reviewer role review this? > > Thanks, > Dmitrij > > On 29.07.2016 21:42, Dmitrij Pochepko wrote: >> Sure, >> >> now including core-libs-dev >> >> Thanks, >> Dmitrij >> >> On 29.07.2016 20:16, joe darcy wrote: >>> Hello, >>> >>> I also recommend sending this review request over to core-libs-dev since it affect the jdk repo. >>> >>> Thanks, >>> >>> -Joe >>> >>> >>> On 7/29/2016 12:35 AM, Dmitry Fazunenko wrote: >>>> Hi Dmitrij, >>>> >>>> The change itself looks good. >>>> >>>> One note: this change adds a little overhead (a very little) for running tests in jdk repository, but it's required only for VM specific tests stored in jdk. As alternative of this change I can suggest moving VM specific tests from the 'jdk' to 'hotspot' repository. Perhaps, such massive update is too late for JDK9 time frame and could be done only in JDK10. >>>> So, if the changes depending on 8162727 are not so critical and could be deferred I would prefer to postpone this fix. >>>> >>>> Thanks, >>>> Dima >>>> >>>> >>>> On 29.07.2016 4:29, Vladimir Kozlov wrote: >>>>> It affects all groups. Should be reviewed on hotspot-dev. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 7/28/16 10:19 AM, Dmitrij Pochepko wrote: >>>>>> Hi, >>>>>> >>>>>> please review small patch for 8162727 - Testbug: additional requires properties can't be used for filtering server vm in jdk jtreg tests >>>>>> >>>>>> A problem is that tests under jdk repo can't use additional jtreg requires properties(like vm.flavor to filter out client or server vm). The same functionality was introduced for hotspot repo as part >>>>>> of JDK-8154956. So, in order to filter tests using these additional properties a small fix is created. >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~dpochepk/8162727/webrev.01/ >>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8162727 >>>>>> >>>>>> Thanks, >>>>>> Dmitrij >>>> >>> >> > From dmitrij.pochepko at oracle.com Thu Aug 4 10:56:23 2016 From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko) Date: Thu, 4 Aug 2016 13:56:23 +0300 Subject: RFR(S): 8162727 - Testbug: additional requires properties can't be used for filtering server vm in jdk jtreg tests In-Reply-To: References: <579A3EB9.7060704@oracle.com> <579AB182.8040502@oracle.com> <9491a957-7368-b373-b676-1987ba814550@oracle.com> <579BA386.20608@oracle.com> <57A1F0BE.7040505@oracle.com> Message-ID: <57A31F57.3020606@oracle.com> Hi, I'm aware of one test only so far. Shoud I move this single test or a whole testgroup which this test belongs to? Thanks, Dmitrij > Dima, > > I?d prefer to have tests moved into hotspot repo instead. none of jdk tests should depend on vm kind or any other details of vm. your change just makes things worse, we will not just have tests which depend on vm implementation details in jdk, we will also have an mechanism for other tests to express such dependency, which can lead to increased number of ?hotspot? tests in jdk. we went similar path w/ testlibrary and we are still paying for that. > > so how many tests which need these properties do we have now? > > Thanks, > ? Igor > >> On Aug 3, 2016, at 4:25 PM, Dmitrij Pochepko wrote: >> >> Hi, >> >> can somebody with official reviewer role review this? >> >> Thanks, >> Dmitrij >> >> On 29.07.2016 21:42, Dmitrij Pochepko wrote: >>> Sure, >>> >>> now including core-libs-dev >>> >>> Thanks, >>> Dmitrij >>> >>> On 29.07.2016 20:16, joe darcy wrote: >>>> Hello, >>>> >>>> I also recommend sending this review request over to core-libs-dev since it affect the jdk repo. >>>> >>>> Thanks, >>>> >>>> -Joe >>>> >>>> >>>> On 7/29/2016 12:35 AM, Dmitry Fazunenko wrote: >>>>> Hi Dmitrij, >>>>> >>>>> The change itself looks good. >>>>> >>>>> One note: this change adds a little overhead (a very little) for running tests in jdk repository, but it's required only for VM specific tests stored in jdk. As alternative of this change I can suggest moving VM specific tests from the 'jdk' to 'hotspot' repository. Perhaps, such massive update is too late for JDK9 time frame and could be done only in JDK10. >>>>> So, if the changes depending on 8162727 are not so critical and could be deferred I would prefer to postpone this fix. >>>>> >>>>> Thanks, >>>>> Dima >>>>> >>>>> >>>>> On 29.07.2016 4:29, Vladimir Kozlov wrote: >>>>>> It affects all groups. Should be reviewed on hotspot-dev. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 7/28/16 10:19 AM, Dmitrij Pochepko wrote: >>>>>>> Hi, >>>>>>> >>>>>>> please review small patch for 8162727 - Testbug: additional requires properties can't be used for filtering server vm in jdk jtreg tests >>>>>>> >>>>>>> A problem is that tests under jdk repo can't use additional jtreg requires properties(like vm.flavor to filter out client or server vm). The same functionality was introduced for hotspot repo as part >>>>>>> of JDK-8154956. So, in order to filter tests using these additional properties a small fix is created. >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~dpochepk/8162727/webrev.01/ >>>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8162727 >>>>>>> >>>>>>> Thanks, >>>>>>> Dmitrij From dmitry.fazunenko at oracle.com Thu Aug 4 12:56:11 2016 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Thu, 4 Aug 2016 15:56:11 +0300 Subject: RFR(S): 8162727 - Testbug: additional requires properties can't be used for filtering server vm in jdk jtreg tests In-Reply-To: References: <579A3EB9.7060704@oracle.com> <579AB182.8040502@oracle.com> <9491a957-7368-b373-b676-1987ba814550@oracle.com> <579BA386.20608@oracle.com> <57A1F0BE.7040505@oracle.com> Message-ID: Igor, Regardless this change I agree with you: VM specific tests should be moved from jdk to hotspot. But we can't get rid of VM specific tests in the jdk repository at all. Tests for java.lang.management belong to JDK, but may use VM specific... I count 11 open and 100 closed jdk tests which use @requires vm.*. I don't see s a big problem in having a few lines duplicated in TEST.ROOT. We don't duplicate the code, but repeat a sort of "import" statements. So, I'm okay with the proposed change. Thanks, Dima On 04.08.2016 11:46, Igor Ignatyev wrote: > Dima, > > I?d prefer to have tests moved into hotspot repo instead. none of jdk tests should depend on vm kind or any other details of vm. your change just makes things worse, we will not just have tests which depend on vm implementation details in jdk, we will also have an mechanism for other tests to express such dependency, which can lead to increased number of ?hotspot? tests in jdk. we went similar path w/ testlibrary and we are still paying for that. > > so how many tests which need these properties do we have now? > > Thanks, > ? Igor > >> On Aug 3, 2016, at 4:25 PM, Dmitrij Pochepko wrote: >> >> Hi, >> >> can somebody with official reviewer role review this? >> >> Thanks, >> Dmitrij >> >> On 29.07.2016 21:42, Dmitrij Pochepko wrote: >>> Sure, >>> >>> now including core-libs-dev >>> >>> Thanks, >>> Dmitrij >>> >>> On 29.07.2016 20:16, joe darcy wrote: >>>> Hello, >>>> >>>> I also recommend sending this review request over to core-libs-dev since it affect the jdk repo. >>>> >>>> Thanks, >>>> >>>> -Joe >>>> >>>> >>>> On 7/29/2016 12:35 AM, Dmitry Fazunenko wrote: >>>>> Hi Dmitrij, >>>>> >>>>> The change itself looks good. >>>>> >>>>> One note: this change adds a little overhead (a very little) for running tests in jdk repository, but it's required only for VM specific tests stored in jdk. As alternative of this change I can suggest moving VM specific tests from the 'jdk' to 'hotspot' repository. Perhaps, such massive update is too late for JDK9 time frame and could be done only in JDK10. >>>>> So, if the changes depending on 8162727 are not so critical and could be deferred I would prefer to postpone this fix. >>>>> >>>>> Thanks, >>>>> Dima >>>>> >>>>> >>>>> On 29.07.2016 4:29, Vladimir Kozlov wrote: >>>>>> It affects all groups. Should be reviewed on hotspot-dev. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 7/28/16 10:19 AM, Dmitrij Pochepko wrote: >>>>>>> Hi, >>>>>>> >>>>>>> please review small patch for 8162727 - Testbug: additional requires properties can't be used for filtering server vm in jdk jtreg tests >>>>>>> >>>>>>> A problem is that tests under jdk repo can't use additional jtreg requires properties(like vm.flavor to filter out client or server vm). The same functionality was introduced for hotspot repo as part >>>>>>> of JDK-8154956. So, in order to filter tests using these additional properties a small fix is created. >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~dpochepk/8162727/webrev.01/ >>>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8162727 >>>>>>> >>>>>>> Thanks, >>>>>>> Dmitrij From george.triantafillou at oracle.com Thu Aug 4 13:46:08 2016 From: george.triantafillou at oracle.com (George Triantafillou) Date: Thu, 4 Aug 2016 09:46:08 -0400 Subject: RFR(XS): 8145543: Removed @ignore for compiler/floatingpoint/ModNaN.java In-Reply-To: <05d85bf1-fdda-6539-4849-004f3df9380b@oracle.com> References: <57A25E33.2020104@oracle.com> <05d85bf1-fdda-6539-4849-004f3df9380b@oracle.com> Message-ID: <1e537fe6-8828-e11d-12ad-a703a47db5b3@oracle.com> +1 -George On 8/3/2016 5:18 PM, Coleen Phillimore wrote: > > Looks good, Max. > Thanks, > Coleen > > On 8/3/16 5:12 PM, Max Ockner wrote: >> Hello, >> Please review this extra small change. There was supposedly a bug >> which caused compiler/floatingpoint/ModNaN.java to fail, but this bug >> is not reproducible. I have removed the @ignore for this test. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8145543 >> webrev: http://cr.openjdk.java.net/~mockner/8145543/ >> >> I ran this change through jprt several times and saw no failure. I >> also had clean runs on several other machines, including a Standard >> Oracle Linux linux-x64 JDK9 machine. This issue that caused this bug >> originally (https://sourceware.org/bugzilla/show_bug.cgi?id=14048) >> has been patched, and the patch has been backported to previous >> versions. It is now very difficult to find a machine which is far >> enough out of date to still have this issue. >> >> Thanks, >> Max >> > From volker.simonis at gmail.com Thu Aug 4 16:17:43 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 4 Aug 2016 18:17:43 +0200 Subject: RFR(S) 8162369: PPC64: Wrong ucontext used after SIGTRAP while in HTM critical section In-Reply-To: <57A2F07C.80603@linux.vnet.ibm.com> References: <57A104CC.7090608@linux.vnet.ibm.com> <2e4fa52ec9764949a7708043e1c3574a@DEWDFE13DE14.global.corp.sap> <57A2F07C.80603@linux.vnet.ibm.com> Message-ID: Hi Gustavo, thanks for the new webrev. It looks good in general. However I think we must check for uc being NULL. Something like: + if (uc && uc->uc_link) {+ ucontext_t* second_uc = uc->uc_link;+ I also didn't fully understand the comment about LSB/MSB. Doesn't it mean that we need to compare the msr register against different masks depending on the endianess? Regards, Volker On Thu, Aug 4, 2016 at 9:36 AM, Gustavo Romero wrote: > Hi Martin, > > Thanks a lot for reviewing. > > On 03-08-2016 10:17, Doerr, Martin wrote: > > 1. A future C++ compiler or runtime code may use HTM, too. Should your > new code get invoked in such a case? Or is it only for transactions which > were started in the code cache (UseRTMLocking)? > I see. Initially I was just thinking in the case of a transaction started > in the code cache, but it's fine for a runtime code to use HTM and generate > a signal in the middle of it as we simply return the control back to the > HTM abort handler (new webrev below). > > For a C++ compiler with TM (PPC64), I'm unable to foresee the final > implementation of the atomic blocks and how it would affect the signal > handler in the specific case of PPC64 (where we have two contexts due to > the additional suspend TM state). Anyway I believe the abortion in an > atomic block would yield an event similar to the runtime code, so in > that case it's already covered. > > > > 2. I was wondering why you only check for zombie_not_entrant. There are > many cases in which a signal may occur during a transaction (e.g. implicit > null check, range check, stack overflow check, safepoint poll, ... and > possibly more in the future). What about them? I guess continuing execution > in the context of the 'treclaim'ed transaction is incorrect. > Sorry, I forgot all those cases, hence yes, it's incorrect to continue the > execution in the second context (or speculated state). > > > > 3. I think reporting errors which occur during transactions is cool. But > if it's too complex, I could live without it. Other platforms don't support > this either (they just abort by hardware). > Yes, I was really focused on finding a way to report errors that could > occur during transactions. I think it would be cool, nonetheless I agree, > it's too complex (also as an implication of all the cases mentioned in 2.). > > > > I was not involved in the earlier discussion. Maybe I missed something. > No, you did not miss anything. Thomas raised the question on if two > contexts exist, then which one would be correct/valid for error reporting. > My try on using the second context to report precisely the root cause of an > abortion was inspired by his question. > > new webrev: > http://81.de.7a9f.ip4.static.sl-reverse.com/8162369/v2 > > Thanks and best regards, > Gustavo > > From igor.ignatyev at oracle.com Thu Aug 4 16:29:43 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 4 Aug 2016 19:29:43 +0300 Subject: RFR(S): 8162727 - Testbug: additional requires properties can't be used for filtering server vm in jdk jtreg tests In-Reply-To: References: <579A3EB9.7060704@oracle.com> <579AB182.8040502@oracle.com> <9491a957-7368-b373-b676-1987ba814550@oracle.com> <579BA386.20608@oracle.com> <57A1F0BE.7040505@oracle.com> Message-ID: > On Aug 4, 2016, at 3:56 PM, Dmitry Fazunenko wrote: > > Igor, > > Regardless this change I agree with you: VM specific tests should be moved from jdk to hotspot. > > But we can't get rid of VM specific tests in the jdk repository at all. Tests for java.lang.management belong to JDK, but may use VM specific... > I count 11 open and 100 closed jdk tests which use @requires vm.*. > Well, I looked thru them and almost all of them look as hotspot tests. > I don't see s a big problem in having a few lines duplicated in TEST.ROOT. We don't duplicate the code, but repeat a sort of "import" statements. > So, I'm okay with the proposed change. the problem is not in code duplication, it is in making that easy to have hotspot tests in jdk. > > Thanks, > Dima > > > On 04.08.2016 11:46, Igor Ignatyev wrote: >> Dima, >> >> I?d prefer to have tests moved into hotspot repo instead. none of jdk tests should depend on vm kind or any other details of vm. your change just makes things worse, we will not just have tests which depend on vm implementation details in jdk, we will also have an mechanism for other tests to express such dependency, which can lead to increased number of ?hotspot? tests in jdk. we went similar path w/ testlibrary and we are still paying for that. >> >> so how many tests which need these properties do we have now? >> >> Thanks, >> ? Igor >> >>> On Aug 3, 2016, at 4:25 PM, Dmitrij Pochepko wrote: >>> >>> Hi, >>> >>> can somebody with official reviewer role review this? >>> >>> Thanks, >>> Dmitrij >>> >>> On 29.07.2016 21:42, Dmitrij Pochepko wrote: >>>> Sure, >>>> >>>> now including core-libs-dev >>>> >>>> Thanks, >>>> Dmitrij >>>> >>>> On 29.07.2016 20:16, joe darcy wrote: >>>>> Hello, >>>>> >>>>> I also recommend sending this review request over to core-libs-dev since it affect the jdk repo. >>>>> >>>>> Thanks, >>>>> >>>>> -Joe >>>>> >>>>> >>>>> On 7/29/2016 12:35 AM, Dmitry Fazunenko wrote: >>>>>> Hi Dmitrij, >>>>>> >>>>>> The change itself looks good. >>>>>> >>>>>> One note: this change adds a little overhead (a very little) for running tests in jdk repository, but it's required only for VM specific tests stored in jdk. As alternative of this change I can suggest moving VM specific tests from the 'jdk' to 'hotspot' repository. Perhaps, such massive update is too late for JDK9 time frame and could be done only in JDK10. >>>>>> So, if the changes depending on 8162727 are not so critical and could be deferred I would prefer to postpone this fix. >>>>>> >>>>>> Thanks, >>>>>> Dima >>>>>> >>>>>> >>>>>> On 29.07.2016 4:29, Vladimir Kozlov wrote: >>>>>>> It affects all groups. Should be reviewed on hotspot-dev. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 7/28/16 10:19 AM, Dmitrij Pochepko wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> please review small patch for 8162727 - Testbug: additional requires properties can't be used for filtering server vm in jdk jtreg tests >>>>>>>> >>>>>>>> A problem is that tests under jdk repo can't use additional jtreg requires properties(like vm.flavor to filter out client or server vm). The same functionality was introduced for hotspot repo as part >>>>>>>> of JDK-8154956. So, in order to filter tests using these additional properties a small fix is created. >>>>>>>> >>>>>>>> webrev: http://cr.openjdk.java.net/~dpochepk/8162727/webrev.01/ >>>>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8162727 >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Dmitrij > From kim.barrett at oracle.com Thu Aug 4 22:02:07 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 4 Aug 2016 18:02:07 -0400 Subject: RFR: 8155043: BitMap set operations assume clear bits beyond unaligned end Message-ID: Please review this change to the BitMap set operations to avoid depending on or modifying bits beyond the size of the BitMap when the size is not word aligned. This change also adds some unit tests for these operations. In addition: - Changed set_from to use Copy::disjoint_words. For other set operations, use a consistent iteration idiom for all. - In the set_xxx_with_result operations, eliminated conditionals in the accumulation of the result. - Removed unused BitMap::set_intersection_at_offset, rather than writing tests for it. CR: https://bugs.openjdk.java.net/browse/JDK-8155043 Webrev: http://cr.openjdk.java.net/~kbarrett/8155043/webrev.00/ Testing: RBT runtime and gc nightly. From aph at redhat.com Thu Aug 4 22:26:43 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 4 Aug 2016 23:26:43 +0100 Subject: Does transition_and_fence really assume TSO? In-Reply-To: References: <57A13506.9070108@redhat.com> Message-ID: <57A3C122.7020304@redhat.com> On 03/08/16 01:25, David Holmes wrote: >> The "assumes total store ordering!" comment is rather alarming. My >> > processor is not TSO. But as far as I can see, all this really >> > requires is single-variable coherency. Is that right? > That comment is pre-historic. The code does not assume TSO. There is a > direct, or implicit, full fence between the two stores: Mmm, that's what I thought. Thanks for confirming! Andrew. From stanislav.smirnov at oracle.com Thu Aug 4 22:36:21 2016 From: stanislav.smirnov at oracle.com (Stas Smirnov) Date: Thu, 4 Aug 2016 15:36:21 -0700 Subject: RFR(XS): 8162670: make of jtreg_tests fails if no tests are run, causing jprt test runs to also fail In-Reply-To: <9a249ef1-2466-28da-a818-d0cb42ebe58d@oracle.com> References: <8bbb54eb-e179-6c10-5d18-7838f08e847e@oracle.com> <4579a80c-6eb8-27e0-4e0d-cd68e6420df0@oracle.com> <6ac6f874-ce28-bc37-cd0f-575ce45af452@oracle.com> <9a249ef1-2466-28da-a818-d0cb42ebe58d@oracle.com> Message-ID: <5a059e4f-ac30-12e4-9779-df13d87e0f8f@oracle.com> I am ok with the recent changes On 04.08.2016 00:31, David Holmes wrote: > On 4/08/2016 2:35 PM, Chris Plummer wrote: >> Unfortunately I need another review of these changes. I ran into a minor >> problem. Although all the jprt testing I tried passed, when I looked >> into the log files I noticed an issue. I saw the following: >> >> Test results: passed: 1 >> Report written to >> /opt/jprt/T/P1/003906.cplummer/s/hotspot/testoutput/JTreport/html/report.html >> >> >> Results written to >> /opt/jprt/T/P1/003906.cplummer/s/hotspot/testoutput/JTwork >> /bin/sh: 15: [: 0: unexpected operator >> Summary: >> TEST STATS: name= run=1 pass=1 fail=0 >> EXIT CODE: 0 >> EXIT CODE: 0 >> >> Notice the "unexpected operator" message in the middle. This only >> happens on our arm platforms. It doesn't seem to affect the test >> results, but should be cleaned up anyway. The "0" turns out to be the >> exit code. I see the same message if a test fails, except the 0 changes >> to a 2. Looking more closely at the code I added, I see I used ==, >> whereas other code nearby uses =. I change it to = and the error message >> went away. I retested with various test cases that fail, pass, or run no >> tests, and all of them do as expected still. > > Must be an old sh that uses a [ built-in which doesn't alias == to =. > > Changes look fine. > > Thanks, > David > >> New webrev can be found at: >> >> http://cr.openjdk.java.net/~cjplummer/8162670/webrev-02/ >> >> thanks, >> >> Chris >> >> On 8/2/16 7:50 AM, Chris Plummer wrote: >>> On 8/1/16 9:30 PM, Chris Plummer wrote: >>>> On 8/1/16 7:25 PM, David Holmes wrote: >>>>> On 2/08/2016 12:11 PM, Chris Plummer wrote: >>>>>> On 8/1/16 5:58 PM, David Holmes wrote: >>>>>>> Hi Chris, >>>>>>> >>>>>>> On 2/08/2016 8:46 AM, Chris Plummer wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Please review this simple change: >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8162670 >>>>>>>> http://cr.openjdk.java.net/~cjplummer/8162670/webrev-00/ >>>>>>> >>>>>>> You've split a compound expression with your code: >>>>>>> >>>>>>> 227 jtregExitCode=$$? && \ >>>>>>> 228 if [ $${jtregExitCode} == 1 ]; then \ >>>>>>> 229 jtregExitCode=0; \ >>>>>>> 230 fi ; \ >>>>>>> 231 _summary="$(SUMMARY_TXT)"; \ >>>>>>> >>>>>>> I'm not clear exactly why the && was needed here but rather than >>>>>>> find >>>>>>> out later I suggest rearranging the above to: >>>>>>> >>>>>>> jtregExitCode=$$? && \ >>>>>>> _summary="$(SUMMARY_TXT)"; \ >>>>>>> if [ $${jtregExitCode} == 1 ]; then \ >>>>>>> jtregExitCode=0; \ >>>>>>> fi ; \ >>>>>>> >>>>>> Yeah, that makes sense. I'll make the change. However, it's really >>>>>> unclear what the use case for && is here. How can jtregExitCode=$$? >>>>>> ever >>>>>> fail? >>>>> >>>>> I wonder if it evaluates to the $? value and so only sets _summary >>>>> if we had a zero exit code? (Not that I understand why we would only >>>>> set _summary in that context.) >>>> I tried the following: >>>> >>>> bash-4.1$ x=0 && echo "foo"; >>>> >>>> And "foo" is always printed. I also tried non-zero values for x. Here >>>> are some other examples: >>>> >>>> bash-4.1$ (exit 1) && echo "foo" >>>> bash-4.1$ (exit 0) && echo "foo" >>>> foo >>>> >>>> Commands evaluate to true if the exit status is 0, and false >>>> otherwise, so I guess you could say commands evaluate to !?$. For &&, >>>> the rhs is only executed if the lhs has a zero exit status. >>> Updated webrev: >>> >>> http://cr.openjdk.java.net/~cjplummer/8162670/webrev-01/ >>> >>> thanks, >>> >>> Chris >>>> >>>> Chris >>>>> >>>>> David >>>>> >>>>>> thanks, >>>>>> >>>>>> Chris >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> Note the copyright dates haven't been updated in this webrev, but >>>>>>>> I did >>>>>>>> update them locally after noticing that. >>>>>>>> >>>>>>>> Tested with jprt test case given in the CR, and also with a >>>>>>>> jprt run >>>>>>>> using "testset -hotspot" to make sure I didn't break anything. >>>>>>>> >>>>>>>> thanks, >>>>>>>> >>>>>>>> Chris >>>>>> >>>>>> >>>> >>> >> From gromero at linux.vnet.ibm.com Fri Aug 5 02:58:07 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Thu, 4 Aug 2016 23:58:07 -0300 Subject: RFR(S) 8162369: PPC64: Wrong ucontext used after SIGTRAP while in HTM critical section In-Reply-To: References: <57A104CC.7090608@linux.vnet.ibm.com> <2e4fa52ec9764949a7708043e1c3574a@DEWDFE13DE14.global.corp.sap> <57A2F07C.80603@linux.vnet.ibm.com> Message-ID: <57A400BF.2080908@linux.vnet.ibm.com> Hi Volker, Thanks a lot for reviewing. On 04-08-2016 13:17, Volker Simonis wrote: > thanks for the new webrev. It looks good in general. However I think we > must check for uc being NULL. Something like: > > + if (uc && uc->uc_link) {+ ucontext_t* second_uc = uc->uc_link;+ Fixed. > I also didn't fully understand the comment about LSB/MSB. Doesn't it mean > that we need to compare the msr register against different masks depending > on the endianess? It's just matter of notation, a different way to point out which bit is in position 0 in a register. It's not related to the endianness because we are not dealing how a word (word could mean 16 bits [Intel], 32 bits [POWER], or anything else) or a register value is stored in memory, i.e the order bytes composing the value in a register will be stored in memory. The MSR (a 64-bit register) value can be stored in memory as BE or LE but when it is loaded back into another 64-bit GPR register it (the value) is the same, regardless the endianness. That's why in the Linux kernel, for instance, MSR Transactional State bits are defined just once and not specific to any endianness (note that they differ here from Power ISA, since C/C++ expect LSB 0 notation by convention in bitwise operations, regardless of endianness): https://github.com/torvalds/linux/blob/master/arch/powerpc/include/asm/reg.h#L32-L33 MSB 0 is also known as IBM bit ordering/numbering. For example, as we can find in this subtle comment in the code regarding the implementation of HTM intrinsics on gcc: https://github.com/gcc-mirror/gcc/blob/master/gcc/config/rs6000/htmintrin.h#L44-L45 I wrote a simple example to show that the value of MSR won't change from BE to LE: https://github.com/gromero/htm/blob/master/threads10.c This code when compiled and run in BE will produce the same result as in LE (you can see the MSR TS bits that match the mask 0x600000000 flipping): [LE] gromero at gromero2:~/git/htm$ uname -a Linux gromero2 4.4.0-28-generic #47-Ubuntu SMP Fri Jun 24 10:09:20 UTC 2016 ppc64le ppc64le ppc64le GNU/Linux gromero at gromero2:~/git/htm$ make threads10 gcc -c -g -O0 threads10.c -o threads10.o gcc -pthread -mhtm -mcpu=power8 -g -O0 threads10.o -o threads10 gromero at gromero2:~/git/htm$ ./threads10 => I'm thread 3fffa078f1a0. I'll perform JUST A TRAP every 2 seconds => I'm thread 3fff9ff8f1a0. I'll perform A TRAP IN TRANSACTION every 1 second * Caught a SIGTRAP in transaction: uc->uc_mcontext.regs->msr = 0x800000050282d033 => I'm thread 3fff9ff8f1a0. I'll perform A TRAP IN TRANSACTION every 1 second * Caught a SIGTRAP but NOT in transaction: uc->uc_mcontext.regs->msr = 0x800000010282d033 => I'm thread 3fffa078f1a0. I'll perform JUST A TRAP every 2 seconds * Caught a SIGTRAP in transaction: uc->uc_mcontext.regs->msr = 0x800000050282d033 => I'm thread 3fff9ff8f1a0. I'll perform A TRAP IN TRANSACTION every 1 second * Caught a SIGTRAP in transaction: uc->uc_mcontext.regs->msr = 0x800000050282d033 => I'm thread 3fff9ff8f1a0. I'll perform A TRAP IN TRANSACTION every 1 second * Caught a SIGTRAP but NOT in transaction: uc->uc_mcontext.regs->msr = 0x800000010282d033 => I'm thread 3fffa078f1a0. I'll perform JUST A TRAP every 2 seconds * Caught a SIGTRAP in transaction: uc->uc_mcontext.regs->msr = 0x800000050282d033 => I'm thread 3fff9ff8f1a0. I'll perform A TRAP IN TRANSACTION every 1 second * Caught a SIGTRAP in transaction: uc->uc_mcontext.regs->msr = 0x800000050282d033 => I'm thread 3fff9ff8f1a0. I'll perform A TRAP IN TRANSACTION every 1 second ... [BE] [root at localhost htm]# uname -a Linux localhost 3.10.0-327.18.2.el7.ppc64 #1 SMP Fri Apr 8 05:12:29 EDT 2016 ppc64 ppc64 ppc64 GNU/Linux [root at localhost htm]# make threads10 gcc -c -g -O0 threads10.c -o threads10.o gcc -pthread -mhtm -mcpu=power8 -g -O0 threads10.o -o threads10 [root at localhost htm]# ./threads10 => I'm thread 3fffa902f1d0. I'll perform JUST A TRAP every 2 seconds => I'm thread 3fffa882f1d0. I'll perform A TRAP IN TRANSACTION every 1 second * Caught a SIGTRAP in transaction: uc->uc_mcontext.regs->msr = 0x800000050282d032 => I'm thread 3fffa882f1d0. I'll perform A TRAP IN TRANSACTION every 1 second * Caught a SIGTRAP but NOT in transaction: uc->uc_mcontext.regs->msr = 0x800000010282d032 => I'm thread 3fffa902f1d0. I'll perform JUST A TRAP every 2 seconds * Caught a SIGTRAP in transaction: uc->uc_mcontext.regs->msr = 0x800000050282d032 => I'm thread 3fffa882f1d0. I'll perform A TRAP IN TRANSACTION every 1 second * Caught a SIGTRAP in transaction: uc->uc_mcontext.regs->msr = 0x800000050282d032 => I'm thread 3fffa882f1d0. I'll perform A TRAP IN TRANSACTION every 1 second * Caught a SIGTRAP but NOT in transaction: uc->uc_mcontext.regs->msr = 0x800000010282d032 => I'm thread 3fffa902f1d0. I'll perform JUST A TRAP every 2 seconds * Caught a SIGTRAP in transaction: uc->uc_mcontext.regs->msr = 0x800000050282d032 => I'm thread 3fffa882f1d0. I'll perform A TRAP IN TRANSACTION every 1 second * Caught a SIGTRAP in transaction: uc->uc_mcontext.regs->msr = 0x800000050282d032 => I'm thread 3fffa882f1d0. I'll perform A TRAP IN TRANSACTION every 1 second ... new webrev: http://81.de.7a9f.ip4.static.sl-reverse.com/8162369/v3 Thank you! Regards, Gustavo From martin.doerr at sap.com Fri Aug 5 07:51:19 2016 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 5 Aug 2016 07:51:19 +0000 Subject: RFR(S) 8162369: PPC64: Wrong ucontext used after SIGTRAP while in HTM critical section In-Reply-To: <57A400BF.2080908@linux.vnet.ibm.com> References: <57A104CC.7090608@linux.vnet.ibm.com> <2e4fa52ec9764949a7708043e1c3574a@DEWDFE13DE14.global.corp.sap> <57A2F07C.80603@linux.vnet.ibm.com> <57A400BF.2080908@linux.vnet.ibm.com> Message-ID: Hi Gustavo, thank you very much for the new webrev and your experiments. @Volker: Thanks for reviewing. I'll push it later. Best regards, Martin -----Original Message----- From: Gustavo Romero [mailto:gromero at linux.vnet.ibm.com] Sent: Friday, August 05, 2016 4:58 AM To: Volker Simonis Cc: Doerr, Martin ; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; Thomas St?fe ; Lindenmaier, Goetz ; Breno Leitao Subject: Re: RFR(S) 8162369: PPC64: Wrong ucontext used after SIGTRAP while in HTM critical section Importance: High Hi Volker, Thanks a lot for reviewing. On 04-08-2016 13:17, Volker Simonis wrote: > thanks for the new webrev. It looks good in general. However I think we > must check for uc being NULL. Something like: > > + if (uc && uc->uc_link) {+ ucontext_t* second_uc = uc->uc_link;+ Fixed. > I also didn't fully understand the comment about LSB/MSB. Doesn't it mean > that we need to compare the msr register against different masks depending > on the endianess? It's just matter of notation, a different way to point out which bit is in position 0 in a register. It's not related to the endianness because we are not dealing how a word (word could mean 16 bits [Intel], 32 bits [POWER], or anything else) or a register value is stored in memory, i.e the order bytes composing the value in a register will be stored in memory. The MSR (a 64-bit register) value can be stored in memory as BE or LE but when it is loaded back into another 64-bit GPR register it (the value) is the same, regardless the endianness. That's why in the Linux kernel, for instance, MSR Transactional State bits are defined just once and not specific to any endianness (note that they differ here from Power ISA, since C/C++ expect LSB 0 notation by convention in bitwise operations, regardless of endianness): https://github.com/torvalds/linux/blob/master/arch/powerpc/include/asm/reg.h#L32-L33 MSB 0 is also known as IBM bit ordering/numbering. For example, as we can find in this subtle comment in the code regarding the implementation of HTM intrinsics on gcc: https://github.com/gcc-mirror/gcc/blob/master/gcc/config/rs6000/htmintrin.h#L44-L45 I wrote a simple example to show that the value of MSR won't change from BE to LE: https://github.com/gromero/htm/blob/master/threads10.c This code when compiled and run in BE will produce the same result as in LE (you can see the MSR TS bits that match the mask 0x600000000 flipping): [LE] gromero at gromero2:~/git/htm$ uname -a Linux gromero2 4.4.0-28-generic #47-Ubuntu SMP Fri Jun 24 10:09:20 UTC 2016 ppc64le ppc64le ppc64le GNU/Linux gromero at gromero2:~/git/htm$ make threads10 gcc -c -g -O0 threads10.c -o threads10.o gcc -pthread -mhtm -mcpu=power8 -g -O0 threads10.o -o threads10 gromero at gromero2:~/git/htm$ ./threads10 => I'm thread 3fffa078f1a0. I'll perform JUST A TRAP every 2 seconds => I'm thread 3fff9ff8f1a0. I'll perform A TRAP IN TRANSACTION every 1 second * Caught a SIGTRAP in transaction: uc->uc_mcontext.regs->msr = 0x800000050282d033 => I'm thread 3fff9ff8f1a0. I'll perform A TRAP IN TRANSACTION every 1 second * Caught a SIGTRAP but NOT in transaction: uc->uc_mcontext.regs->msr = 0x800000010282d033 => I'm thread 3fffa078f1a0. I'll perform JUST A TRAP every 2 seconds * Caught a SIGTRAP in transaction: uc->uc_mcontext.regs->msr = 0x800000050282d033 => I'm thread 3fff9ff8f1a0. I'll perform A TRAP IN TRANSACTION every 1 second * Caught a SIGTRAP in transaction: uc->uc_mcontext.regs->msr = 0x800000050282d033 => I'm thread 3fff9ff8f1a0. I'll perform A TRAP IN TRANSACTION every 1 second * Caught a SIGTRAP but NOT in transaction: uc->uc_mcontext.regs->msr = 0x800000010282d033 => I'm thread 3fffa078f1a0. I'll perform JUST A TRAP every 2 seconds * Caught a SIGTRAP in transaction: uc->uc_mcontext.regs->msr = 0x800000050282d033 => I'm thread 3fff9ff8f1a0. I'll perform A TRAP IN TRANSACTION every 1 second * Caught a SIGTRAP in transaction: uc->uc_mcontext.regs->msr = 0x800000050282d033 => I'm thread 3fff9ff8f1a0. I'll perform A TRAP IN TRANSACTION every 1 second ... [BE] [root at localhost htm]# uname -a Linux localhost 3.10.0-327.18.2.el7.ppc64 #1 SMP Fri Apr 8 05:12:29 EDT 2016 ppc64 ppc64 ppc64 GNU/Linux [root at localhost htm]# make threads10 gcc -c -g -O0 threads10.c -o threads10.o gcc -pthread -mhtm -mcpu=power8 -g -O0 threads10.o -o threads10 [root at localhost htm]# ./threads10 => I'm thread 3fffa902f1d0. I'll perform JUST A TRAP every 2 seconds => I'm thread 3fffa882f1d0. I'll perform A TRAP IN TRANSACTION every 1 second * Caught a SIGTRAP in transaction: uc->uc_mcontext.regs->msr = 0x800000050282d032 => I'm thread 3fffa882f1d0. I'll perform A TRAP IN TRANSACTION every 1 second * Caught a SIGTRAP but NOT in transaction: uc->uc_mcontext.regs->msr = 0x800000010282d032 => I'm thread 3fffa902f1d0. I'll perform JUST A TRAP every 2 seconds * Caught a SIGTRAP in transaction: uc->uc_mcontext.regs->msr = 0x800000050282d032 => I'm thread 3fffa882f1d0. I'll perform A TRAP IN TRANSACTION every 1 second * Caught a SIGTRAP in transaction: uc->uc_mcontext.regs->msr = 0x800000050282d032 => I'm thread 3fffa882f1d0. I'll perform A TRAP IN TRANSACTION every 1 second * Caught a SIGTRAP but NOT in transaction: uc->uc_mcontext.regs->msr = 0x800000010282d032 => I'm thread 3fffa902f1d0. I'll perform JUST A TRAP every 2 seconds * Caught a SIGTRAP in transaction: uc->uc_mcontext.regs->msr = 0x800000050282d032 => I'm thread 3fffa882f1d0. I'll perform A TRAP IN TRANSACTION every 1 second * Caught a SIGTRAP in transaction: uc->uc_mcontext.regs->msr = 0x800000050282d032 => I'm thread 3fffa882f1d0. I'll perform A TRAP IN TRANSACTION every 1 second ... new webrev: http://81.de.7a9f.ip4.static.sl-reverse.com/8162369/v3 Thank you! Regards, Gustavo From stefan.karlsson at oracle.com Fri Aug 5 13:27:02 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 5 Aug 2016 15:27:02 +0200 Subject: RFR: 8155043: BitMap set operations assume clear bits beyond unaligned end In-Reply-To: References: Message-ID: Hi Kim, This looks mostly good to me. I have a few comments inlined: On 2016-08-05 00:02, Kim Barrett wrote: > Please review this change to the BitMap set operations to avoid > depending on or modifying bits beyond the size of the BitMap when the > size is not word aligned. This change also adds some unit tests for > these operations. > > In addition: > > - Changed set_from to use Copy::disjoint_words. For other set > operations, use a consistent iteration idiom for all. > > - In the set_xxx_with_result operations, eliminated conditionals in > the accumulation of the result. I guess this was done for performance reasons? Have you measured and seen any gains with this? The generated code becomes significantly larger when using the or/xor combination in your patch. > > - Removed unused BitMap::set_intersection_at_offset, rather than > writing tests for it. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8155043 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8155043/webrev.00/ Some minor comments/suggestions that you might want to consider: ========== http://cr.openjdk.java.net/~kbarrett/8155043/webrev.00/src/share/vm/utilities/bitMap.cpp.frames.html There are a few places where the tail calculations are slightly different compared to the calculations of the aligned part. Would it be good to use the same bitwise operations, just to get consistency between the two parts? For example, in BitMap::contains we have 408 bm_word_t value = dest_map[index]; 409 if (value != (value | other_map[index])) return false; vs 414 return (rest == 0) || tail_of_set(~dest_map[limit] & other_map[limit], rest) == 0; We could replace 408-409 with 'if (~dest_map[limit] & other_map[limit]) == 0) return false'. ---------- I find that the introduction of the 'bm_word_t orig' variable just makes the code extra noisy, and would have preferred the calculations without it. ---------- The new code has a few functions named *_of_set. The terminology "set" is previously not used in the BitMap file, so I'm a bit reluctant to introduce it. Could we get rid of it by renaming the functions: tail_of_set -> tail_of_map merge_tail_of_set -> merge_tail_of_map or maybe: tail_of_set -> tail_bits merge_tail_of_set -> merge_tail_bits ========== http://cr.openjdk.java.net/~kbarrett/8155043/webrev.00/test/native/utilities/test_bitMap_setops.cpp.html The file tests more than the set operations, so maybe the _setops suffix should be dropped? ---------- Some of the tests restore the previous bitmap value after all checks, but some don't. It would probably be good to make that more consistent. ---------- class BitMapMemory { ... private: idx_t _words; bm_word_t* _memory; }; Most of the classes in the HotSpot have the members at the top of the class. ---------- static bm_word_t make_even_bits() { bm_word_t result = 1; while (true) { bm_word_t next = (result << 2) | 1; if (next == result) return result; result = next; } } I'd prefer if you moved down the return statement to a separate line and add braces. ---------- Thanks, StefanK > > Testing: > RBT runtime and gc nightly. > From gnu.andrew at redhat.com Fri Aug 5 15:12:22 2016 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 5 Aug 2016 11:12:22 -0400 (EDT) Subject: PING: [8u112] Request for review & approval for CR8151841: Build needs additional flags to compile with GCC 6 In-Reply-To: References: <488374967.2958104.1467922862145.JavaMail.zimbra@redhat.com> <577F4C58.6060101@oracle.com> <1053522900.3503496.1468213009871.JavaMail.zimbra@redhat.com> <788404102.5570020.1468596130974.JavaMail.zimbra@redhat.com> <75eba245-b501-6567-445c-836fa7fc3885@oracle.com> Message-ID: <247448866.1378063.1470409942851.JavaMail.zimbra@redhat.com> ----- Original Message ----- > I'm seeing this patch fail across all platforms on internal builds. > Please hold off any push for now. Maybe other config changes are needed > on our build systems. > > e.g. > > > /opt/jprt/products/P1/SS12u1/SS12u1/prod/bin/CC > > \ > > -m64 -G -KPIC \ > > -I/opt/jprt/T/P1/094712.scoffey/s/hotspot/agent/src/os/solaris/proc > > \ > > -I../generated \ > > -I/opt/jprt/products/P1/jdk7u7-latest/jdk1.7.0_07/include > > \ > > -I/opt/jprt/products/P1/jdk7u7-latest/jdk1.7.0_07/include/solaris > > \ > > \ > > /opt/jprt/T/P1/094712.scoffey/s/hotspot/agent/src/os/solaris/proc/saproc.cpp > > \ > > sadis.o \ > > -M > > /opt/jprt/T/P1/094712.scoffey/s/hotspot/agent/src/os/solaris/proc/mapfile > > -mt -xnolib -norunpath > > \ > > -o libsaproc.so > > \ > > -ldl -ldemangle -lthread -lc > > ld: fatal: file @NO_DELETE_NULL_POINTER_CHECKS_CFLAG@: open failed: No such > > file or directory > > ld: fatal: file @NO_LIFETIME_DSE_CFLAG@: open failed: No such file or > > directory > > ld: fatal: file @CXXSTD_CXXFLAG@: open failed: No such file or directory > > ld: fatal: file processing errors. No output written to > > libgenerateJvmOffsets.so > > gmake[6]: *** [libgenerateJvmOffsets.so] Error 1 > > gmake[6]: *** Waiting for unfinished jobs.... > > gmake[6]: Leaving directory > > `/opt/jprt/T/P1/094712.scoffey/s/build/solaris-x86_64-normal-server-release/hotspot/solaris_amd64_compiler2/product' > > gmake[5]: *** [the_vm] Error 2 > It needs to be pushed by someone at Oracle anyway, so your internal configure can be updated. I think that might be the problem here. @CXXSTD_CXXFLAG@ and friends should be substituted by configure with either the flag or the empty string, so something is going wrong earlier with the configure stage. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gromero at linux.vnet.ibm.com Fri Aug 5 16:52:03 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Fri, 5 Aug 2016 13:52:03 -0300 Subject: RFR(S) 8162369: PPC64: Wrong ucontext used after SIGTRAP while in HTM critical section In-Reply-To: References: <57A104CC.7090608@linux.vnet.ibm.com> <2e4fa52ec9764949a7708043e1c3574a@DEWDFE13DE14.global.corp.sap> <57A2F07C.80603@linux.vnet.ibm.com> <57A400BF.2080908@linux.vnet.ibm.com> Message-ID: <57A4C433.9080108@linux.vnet.ibm.com> Hi Martin, Volker Thank you very much for reviewing and sponsoring the fix. Best regards, Gustavo From coleen.phillimore at oracle.com Fri Aug 5 17:08:33 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 5 Aug 2016 13:08:33 -0400 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: References: <88A2872D-70F9-48DB-94B1-4314B3D9D217@oracle.com> <3933D052-50B2-43F1-AA20-2E75F60B61CE@oracle.com> <764F8C8B-AFE6-4A3F-8C0D-3D24F72CED58@oracle.com> Message-ID: <14fd7b88-9956-5f8a-32ad-f7bb4210250f@oracle.com> I think you have to update your compatibility request for the new API, if you haven't already. The hotspot changes look good. Coleen On 8/1/16 2:47 PM, Kim Barrett wrote: > This updated webrev addresses concerns about the performance of the VM > API used by the reference processor thread in the original webrev. > > New webrevs: > full: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.03/ > http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.03/ > incr: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.03.incr/ > http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.03.incr/ > > The originally offered approach was an attempt to minimize changes. I > was trying to be as similar to the existing code as possible, while > moving part of it into the VM, where we have the necessary control > over suspension and the like. We already know we want to make changes > in this area, in order to eliminate the use of > jdk.internal.ref.Cleaner (JDK-8149925). But we've also agreed that > JDK-8149925 wasn't urgent and to defer it to JDK 10. I don't think we > should revisit that. > > As Peter pointed out, my original change introduces a small > performance regression on a microbenchmark for reference processing > throughput. It also showed a small performance benefit on a different > microbenchmark (allocation rate for a stress test of direct byte > buffers), as noted in the original RFR. I can reproduce both of > those. > > I think reference processing thread throughput is the right measure to > use, so long as others don't become horrible. Focusing on that, it's > better to just let the reference processing thread do the processing, > rather than slowing it down to allow for the rare case when there's > another thread that could possibly help. This is especially true now > that Cleaner has such limited usage. > > This leads to a different API for other threads; rather than > tryHandlePending that other threads can call to help and to examine > progress, we now have waitForReferenceProcessing. The VM API is also > different; rather than popReferencePendingList to get or wait, we now > have getAndClearReferencePendingList and checkReferencePendingList, > the latter with an optional wait. > > The splitting of the VM API allows us to avoid a narrow race condition > discussed by Peter in his prototypes. Peter suggested this race was > ok because java.nio.Bits makes several retries. However, those > retries are only done before throwing OOME. There are no retries > before invoking GC, so this race could lead to unnecessary successive > GCs. > > Doing all the processing on the reference processing thread eliminates > execution of Cleaners on application threads, though that's not nearly > as much an issue now that the use of Cleaner is so restricted. > > We've also eliminated a pre-existing issue where a helper could report > no progress even though the reference processing thread (and other > helpers) had removed a pending reference, but not yet processed it. > This could result in the non-progressing helper invoking GC or > reporting failure, even though it might have succeeded if it had > waited for the other thread(s) to complete processing the reference(s) > being worked on. > > I think the new waitForReferenceProcessing could be used to fix > JDK-6306116, though that isn't part of this change, and was not really > a motivating factor. > > I don't know if the new waitForReferenceProcessing will be used by > whatever we eventually do for JDK-8149925, but I think the new VM API > will suffice for that. That is, I think JDK-8149925 might require > changes to the core-libs API used by nio.Bits, and won't require > further VM API changes. > > > From kim.barrett at oracle.com Fri Aug 5 17:14:42 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 5 Aug 2016 13:14:42 -0400 Subject: RFR: 8156500: deadlock provoked by new stress test com/sun/jdi/OomDebugTest.java In-Reply-To: <14fd7b88-9956-5f8a-32ad-f7bb4210250f@oracle.com> References: <88A2872D-70F9-48DB-94B1-4314B3D9D217@oracle.com> <3933D052-50B2-43F1-AA20-2E75F60B61CE@oracle.com> <764F8C8B-AFE6-4A3F-8C0D-3D24F72CED58@oracle.com> <14fd7b88-9956-5f8a-32ad-f7bb4210250f@oracle.com> Message-ID: <56E68549-4104-4B70-AFD7-CE9ECFED809A@oracle.com> > On Aug 5, 2016, at 1:08 PM, Coleen Phillimore wrote: > > > > I think you have to update your compatibility request for the new API, if you haven't already. Yes, I still need to do that. I figured I?d wait until reviewers said they like this new one before cycling through that again. > The hotspot changes look good. > > Coleen > > > > On 8/1/16 2:47 PM, Kim Barrett wrote: >> This updated webrev addresses concerns about the performance of the VM >> API used by the reference processor thread in the original webrev. >> >> New webrevs: >> full: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.03/ >> http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.03/ >> incr: http://cr.openjdk.java.net/~kbarrett/8156500/jdk.03.incr/ >> http://cr.openjdk.java.net/~kbarrett/8156500/hotspot.03.incr/ >> [snip] From zoltan.majo at oracle.com Fri Aug 5 18:59:18 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 5 Aug 2016 11:59:18 -0700 Subject: RFR: JDK-8141634 Implement VarHandles/Unsafe intrinsics on SPARC In-Reply-To: <7ebde74d-dd50-bfa8-4f2f-502088348c0d@oracle.com> References: <7ebde74d-dd50-bfa8-4f2f-502088348c0d@oracle.com> Message-ID: <5ef8a504-5668-0519-839a-528044baab30@oracle.com> Hi Trevor, thank you for working on this enhancement! I executed all tests in the hotspot/test directory for your proposed change. Unfortunately, five tests fail: compiler/unsafe/JdkInternalMiscUnsafeAccessTestDouble.java compiler/unsafe/JdkInternalMiscUnsafeAccessTestFloat.java compiler/unsafe/JdkInternalMiscUnsafeAccessTestInt.java compiler/unsafe/JdkInternalMiscUnsafeAccessTestLong.java compiler/unsafe/JdkInternalMiscUnsafeAccessTestObject.java You can find more information about the failures (incl. a stack trace) here [1]. The failures can be reproduced using JTREG. I've used a SPARC T5 machine to reproduce them. Please let me know if you need more information on the setup I used to reproduce the failures. Also, could you please execute the hotspot/compiler tests locally on a SPARC machine before sending out the updated webrev? That way we will catch failures earlier. Thank you! Best regards, Zoltan [1] https://bugs.openjdk.java.net/browse/JDK-8141634?focusedCommentId=13983682&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13983682 On 07/29/2016 01:37 AM, Trevor Watson wrote: > Summary: > > SPARC assembler implementations of the compareAndExchange* intrinsics > and the addition of the WeakCompareAndSwap* matchers. > > Have successfully run the 'gmake test' target and the benchmarks > mentioned in the bug report. > > Benchmarks for the compareAndExchange* intrinsic operations now show > an approximate 9x-20x improvement: > > Before: > Benchmark Mode Cnt Score Error Units > caeAcquire.IntTest.varHandle avgt 15 351.933 ? 7.161 ns/op > caeAcquire.LongTest.varHandle avgt 15 435.872 ? 3.129 ns/op > caeAcquire.ObjectTest.varHandle avgt 15 975.728 ? 88.362 > ns/op > caeRelease.IntTest.varHandle avgt 15 346.391 ? 2.798 ns/op > caeRelease.LongTest.varHandle avgt 15 439.734 ? 9.739 ns/op > caeRelease.ObjectTest.varHandle avgt 15 934.279 ? 19.454 > ns/op > caeVolatile.IntTest.varHandle avgt 15 346.076 ? 1.771 ns/op > caeVolatile.LongTest.varHandle avgt 15 436.788 ? 1.825 ns/op > caeVolatile.ObjectTest.varHandle avgt 15 935.250 ? 59.526 > ns/op > > With new intrinsic implementation: > caeAcquire.IntTest.varHandle avgt 15 38.514 ? 0.974 ns/op > caeAcquire.LongTest.varHandle avgt 15 38.411 ? 0.359 ns/op > caeAcquire.ObjectTest.varHandle avgt 15 42.616 ? 0.916 ns/op > caeRelease.IntTest.varHandle avgt 15 38.235 ? 0.185 ns/op > caeRelease.LongTest.varHandle avgt 15 38.165 ? 0.145 ns/op > caeRelease.ObjectTest.varHandle avgt 15 42.320 ? 0.156 ns/op > caeVolatile.IntTest.varHandle avgt 15 38.321 ? 0.221 ns/op > caeVolatile.LongTest.varHandle avgt 15 38.270 ? 0.198 ns/op > caeVolatile.ObjectTest.varHandle avgt 15 42.541 ? 0.720 ns/op > > > Webrev: http://cr.openjdk.java.net/~alanbur/JDK-8141634/ > Bug link: https://bugs.openjdk.java.net/browse/JDK-8141634 From mandy.chung at oracle.com Fri Aug 5 20:11:28 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 5 Aug 2016 13:11:28 -0700 Subject: Review request 8136930: Simplify use of module-system options by custom launchers Message-ID: This patch renames the module-system options to GNU-style as specified in JEP 293 [1] (see below for the new proposed option names). This addresses the problems discussed in [2] that the launcher will pass the module-system options down to the VM in the form of