From david.holmes at oracle.com Mon Feb 2 00:00:07 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 02 Feb 2015 10:00:07 +1000 Subject: [aarch64-port-dev ] RFR: AARCH64: 8064594: Top-level JDK changes In-Reply-To: <54CD4F79.7060202@oracle.com> References: <546348F8.9060900@redhat.com> <54CB2D7F.2000607@oracle.com> <54CB4149.7080503@redhat.com> <54CB4541.7030407@redhat.com> <54CD4F79.7060202@oracle.com> Message-ID: <54CEBE07.4090709@oracle.com> On 1/02/2015 7:56 AM, Dean Long wrote: > On 1/30/2015 12:48 AM, Andrew Dinn wrote: >> >> On 30/01/15 08:31, Andrew Haley wrote: >>> On 30/01/15 07:06, Dean Long wrote: >>>> Sorry for the late question, but how is >>>> src/java.base/unix/native/libjli/aarch64/jvm.cfg different from >>>> src/java.base/unix/conf/aarch64/jvm.cfg? I can't find where the former >>>> is used. >>> I'm sorry, I have no idea! I can investigate next week when I >>> get back from FOSDEM. >> It looks like that has been copied there by mistake. There is no such >> file in the aarch64-port jdk9 tree from which stage was derived nor is >> there one in the arch64-port jdk8 tree. >> >> regards, >> >> >> Andrew Dinn >> ----------- >> > > I filed a bug: > > https://bugs.openjdk.java.net/browse/JDK-8072053 Shouldn't this just be fixed as part of the push of the current bug? Separate bugs are only needed for things that will need to be fixed after the merge with mainline. David > dl > From dean.long at oracle.com Mon Feb 2 00:07:53 2015 From: dean.long at oracle.com (Dean Long) Date: Sun, 01 Feb 2015 16:07:53 -0800 Subject: [aarch64-port-dev ] RFR: AARCH64: 8064594: Top-level JDK changes In-Reply-To: <54CEBE07.4090709@oracle.com> References: <546348F8.9060900@redhat.com> <54CB2D7F.2000607@oracle.com> <54CB4149.7080503@redhat.com> <54CB4541.7030407@redhat.com> <54CD4F79.7060202@oracle.com> <54CEBE07.4090709@oracle.com> Message-ID: <54CEBFD9.70001@oracle.com> On 2/1/2015 4:00 PM, David Holmes wrote: > On 1/02/2015 7:56 AM, Dean Long wrote: >> On 1/30/2015 12:48 AM, Andrew Dinn wrote: >>> >>> On 30/01/15 08:31, Andrew Haley wrote: >>>> On 30/01/15 07:06, Dean Long wrote: >>>>> Sorry for the late question, but how is >>>>> src/java.base/unix/native/libjli/aarch64/jvm.cfg different from >>>>> src/java.base/unix/conf/aarch64/jvm.cfg? I can't find where the >>>>> former >>>>> is used. >>>> I'm sorry, I have no idea! I can investigate next week when I >>>> get back from FOSDEM. >>> It looks like that has been copied there by mistake. There is no such >>> file in the aarch64-port jdk9 tree from which stage was derived nor is >>> there one in the arch64-port jdk8 tree. >>> >>> regards, >>> >>> >>> Andrew Dinn >>> ----------- >>> >> >> I filed a bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8072053 > > Shouldn't this just be fixed as part of the push of the current bug? > Separate bugs are only needed for things that will need to be fixed > after the merge with mainline. > 8064594 has already been pushed to the staging repo, so I don't see how we can fix it in the staging repo without a new bugid. And while it would be nice to get it fixed before it goes into mainline, I don't want it to cause any delay in the merge with the mainline. dl > David > >> dl >> From david.holmes at oracle.com Mon Feb 2 00:54:55 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 02 Feb 2015 10:54:55 +1000 Subject: [aarch64-port-dev ] RFR: AARCH64: 8064594: Top-level JDK changes In-Reply-To: <54CEBFD9.70001@oracle.com> References: <546348F8.9060900@redhat.com> <54CB2D7F.2000607@oracle.com> <54CB4149.7080503@redhat.com> <54CB4541.7030407@redhat.com> <54CD4F79.7060202@oracle.com> <54CEBE07.4090709@oracle.com> <54CEBFD9.70001@oracle.com> Message-ID: <54CECADF.4000809@oracle.com> On 2/02/2015 10:07 AM, Dean Long wrote: > On 2/1/2015 4:00 PM, David Holmes wrote: >> On 1/02/2015 7:56 AM, Dean Long wrote: >>> On 1/30/2015 12:48 AM, Andrew Dinn wrote: >>>> >>>> On 30/01/15 08:31, Andrew Haley wrote: >>>>> On 30/01/15 07:06, Dean Long wrote: >>>>>> Sorry for the late question, but how is >>>>>> src/java.base/unix/native/libjli/aarch64/jvm.cfg different from >>>>>> src/java.base/unix/conf/aarch64/jvm.cfg? I can't find where the >>>>>> former >>>>>> is used. >>>>> I'm sorry, I have no idea! I can investigate next week when I >>>>> get back from FOSDEM. >>>> It looks like that has been copied there by mistake. There is no such >>>> file in the aarch64-port jdk9 tree from which stage was derived nor is >>>> there one in the arch64-port jdk8 tree. >>>> >>>> regards, >>>> >>>> >>>> Andrew Dinn >>>> ----------- >>>> >>> >>> I filed a bug: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8072053 >> >> Shouldn't this just be fixed as part of the push of the current bug? >> Separate bugs are only needed for things that will need to be fixed >> after the merge with mainline. >> > > 8064594 has already been pushed to the staging repo, so I don't see how > we can fix it in the staging repo without a new bugid. I hadn't realized these were pushed - I thought they were still under discussion. > And while it would be nice to get it fixed before it goes into mainline, > I don't want it to cause any delay in the merge with the mainline. Ok. It just means at the moment the bug is in a disassociative state :) If it will be fixed in the staging repo then it needs affects version port-stage-aarch64. If it will be fixed post merge then it needs affects version 9. There should also be a request to get arm64 or aarch64 added to the CPU list in JBS. Cheers, David > dl > >> David >> >>> dl >>> > From vladimir.kozlov at oracle.com Mon Feb 2 01:44:35 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sun, 01 Feb 2015 17:44:35 -0800 Subject: [aarch64-port-dev ] RFR: AARCH64: 8064594: Top-level JDK changes In-Reply-To: <54CECADF.4000809@oracle.com> References: <546348F8.9060900@redhat.com> <54CB2D7F.2000607@oracle.com> <54CB4149.7080503@redhat.com> <54CB4541.7030407@redhat.com> <54CD4F79.7060202@oracle.com> <54CEBE07.4090709@oracle.com> <54CEBFD9.70001@oracle.com> <54CECADF.4000809@oracle.com> Message-ID: <54CED683.8040602@oracle.com> >> And while it would be nice to get it fixed before it goes into mainline, >> I don't want it to cause any delay in the merge with the mainline. > > Ok. It just means at the moment the bug is in a disassociative state :) If it will be fixed in the staging repo then it > needs affects version port-stage-aarch64. If it will be fixed post merge then it needs affects version 9. I would suggest to fix 8072053 in stage repo. We potentially still 2 weeks away from merge into main repo. I set "Affected Version" 'port-stage-aarch64' for it. Thanks, Vladimir On 2/1/15 4:54 PM, David Holmes wrote: > On 2/02/2015 10:07 AM, Dean Long wrote: >> On 2/1/2015 4:00 PM, David Holmes wrote: >>> On 1/02/2015 7:56 AM, Dean Long wrote: >>>> On 1/30/2015 12:48 AM, Andrew Dinn wrote: >>>>> >>>>> On 30/01/15 08:31, Andrew Haley wrote: >>>>>> On 30/01/15 07:06, Dean Long wrote: >>>>>>> Sorry for the late question, but how is >>>>>>> src/java.base/unix/native/libjli/aarch64/jvm.cfg different from >>>>>>> src/java.base/unix/conf/aarch64/jvm.cfg? I can't find where the >>>>>>> former >>>>>>> is used. >>>>>> I'm sorry, I have no idea! I can investigate next week when I >>>>>> get back from FOSDEM. >>>>> It looks like that has been copied there by mistake. There is no such >>>>> file in the aarch64-port jdk9 tree from which stage was derived nor is >>>>> there one in the arch64-port jdk8 tree. >>>>> >>>>> regards, >>>>> >>>>> >>>>> Andrew Dinn >>>>> ----------- >>>>> >>>> >>>> I filed a bug: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8072053 >>> >>> Shouldn't this just be fixed as part of the push of the current bug? >>> Separate bugs are only needed for things that will need to be fixed >>> after the merge with mainline. >>> >> >> 8064594 has already been pushed to the staging repo, so I don't see how >> we can fix it in the staging repo without a new bugid. > > I hadn't realized these were pushed - I thought they were still under discussion. > >> And while it would be nice to get it fixed before it goes into mainline, >> I don't want it to cause any delay in the merge with the mainline. > > Ok. It just means at the moment the bug is in a disassociative state :) If it will be fixed in the staging repo then it > needs affects version port-stage-aarch64. If it will be fixed post merge then it needs affects version 9. > > There should also be a request to get arm64 or aarch64 added to the CPU list in JBS. > > Cheers, > David > >> dl >> >>> David >>> >>>> dl >>>> >> From goetz.lindenmaier at sap.com Mon Feb 2 07:22:57 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 2 Feb 2015 07:22:57 +0000 Subject: RFR (S): 8071996: split_if accesses NULL region of ConstraintCast Message-ID: <4295855A5C1DE049A61835A1887419CC2CF8A11B@DEWDFEMB12A.global.corp.sap> Hi, I fixed a small bug in the C2 compiler. It appeared in our s390/zArch port running hs25.31 with jdk6 when executing jvm2008/compiler.compiler. Split_if encounters a ConstraintCast without region edge, which is a valid pattern. But it reads the region edge unconditionally, thus failing. Please review this change. I please need a sponsor. http://cr.openjdk.java.net/~goetz/webrevs/8071996-fixSplitIf/webrev.01/ Best regards, Goetz. From mikael.auno at oracle.com Mon Feb 2 15:40:01 2015 From: mikael.auno at oracle.com (Mikael Auno) Date: Mon, 02 Feb 2015 16:40:01 +0100 Subject: RFR(L): 8071908, 8071909: Port internal Diagnostic Command tests and test framework to jtreg (plus some testlibrary changes) In-Reply-To: <54CBE74B.7040104@oracle.com> References: <54CB527B.4060503@oracle.com> <54CB5A60.8020401@oracle.com> <54CBDC4E.2010002@oracle.com> <54CBE022.20502@oracle.com> <54CBE74B.7040104@oracle.com> Message-ID: <54CF9A51.8090309@oracle.com> Thanks everyone for the reviews. This has now been pushed. Mikael On 2015-01-30 21:19, Mikael Auno wrote: > Thanks Jaroslav! > > I'll leave this open for further comments if someone else has them until > Monday afternoon (CET). If there are no more comments by then I'll get > it pushed at that time. > > Mikael > > On 2015-01-30 20:48, Jaroslav Bachorik wrote: >> Nice! For me it's good to go. >> >> -JB- >> >> On 30.1.2015 20:32, Mikael Auno wrote: >>> Jaroslav, >>> >>> First of all, thanks for the quick response and sorry for my slow one >>> (your message didn't sort into the mail folder I expected, so didn't see >>> it until now). >>> >>> Secondly, all good comments; all fixed. >>> >>> Updated webrev: >>> http://cr.openjdk.java.net/~miauno/8071908_8071909/webrev.02/ >>> >>> Thanks, >>> Mikael >>> >>> On 2015-01-30 11:18, Jaroslav Bachorik wrote: >>>> Hi Mikael, >>>> >>>> it's great to see this moving forward! >>>> >>>> Comments follow: >>>> >>>> * instead of throwing a RuntimeException from within the test classes >>>> you could use o.testng.Assert.fail(...) method >>>> >>>> * all the newly introduced tests are missing @summary >>>> >>>> * test/serviceability/dcmd/compiler/CodelistTest.java >>>> L43 - unused import >>>> L68 - an unused, commented out, line >>>> >>>> * test/testlibrary/com/oracle/java/testlibrary/OutputAnalyzer.java >>>> L436-438 - use Arrays.asList() >>>> >>>> * test/serviceability/dcmd/vm/UptimeTest.java >>>> L44 - spurious wakeups may cause the test fail intermittently; should >>>> make sure the wait was at least 'someUptime' seconds long >>>> >>>> >>>> -JB- >>>> >>>> On 30.1.2015 10:44, Mikael Auno wrote: >>>>> Hi, could I please some reviews for this test port? >>>>> >>>>> Issues: https://bugs.openjdk.java.net/browse/JDK-8071908 >>>>> https://bugs.openjdk.java.net/browse/JDK-8071909 >>>>> Webrev: http://cr.openjdk.java.net/~miauno/8071908_8071909/webrev.00/ >>>>> >>>>> Read on for the rationale on a few questions that might arise. >>>>> >>>>> * Why two issues? >>>>> >>>>> These changes are mainly a port of the Diagnostic Command (DCMD) tests >>>>> and corresponding framework/utility classes from an internal (non-open) >>>>> test framework to jtreg. The reason for the two issues is that the >>>>> changes depend on a few modifications to testlibrary that are available >>>>> in jdk/test but not yet in hotspot/test, as well as a small new >>>>> addition >>>>> to OutputAnalyzer, that are not specific to main subject (i.e. the DCMD >>>>> tests). To keep the history as clean and coherent as possible, those >>>>> changes will go in under JDK-8071909 while the new tests and >>>>> DCMD-related additions to testlibrary go in under JDK-8071908. >>>>> >>>>> * Isn't there already utility classes for calling Diagnostic Commands? >>>>> >>>>> The main idea with the new utility classes in testlibrary is to provide >>>>> a single interface to call Diagnostic Commands from tests, >>>>> regardless of >>>>> the transport used (e.g. jcmd or JMX). There are a few tests scattered >>>>> around jdk/test and hotspot/test today that already utilize Diagnostic >>>>> Commands in some way, but they either use different utility classes for >>>>> this in different places or just do it directly in the test. Also, some >>>>> of these utility classes or tests go through jcmd and some through JMX >>>>> (most often without any real requirement for one transport over the >>>>> other in the test). All this means that there are, today, numerous >>>>> different implementations for calling Diagnostic Commands, and >>>>> consequently a lot of code duplication. These utility classes are meant >>>>> to replace all of these implementations, and with a single interface >>>>> regardless of the transport at that. >>>>> >>>>> * You've missed this or that test using one of the existing utility >>>>> classes! >>>>> >>>>> This is "by design". In order to keep the change at a more manageable >>>>> size and to get the core of this change in sooner, we've chosen to do >>>>> this transition in multiple steps. The first of those steps is what is >>>>> in this review request; the core utility classes, the tests ported from >>>>> the internal test framework and the adaption of the tests already in >>>>> hotspot/test/serviceability/dcmd (since they happened to reside in the >>>>> directory where we wanted to put the ported tests). When this is >>>>> integrated and have gone a few rounds through nightly testing, the >>>>> adaption of other tests in hotspot/test will follow, and after that >>>>> jdk/test. >>>>> >>>>> Thanks, >>>>> Mikael >>>>> >>>> >>> >> > From edward.nevill at linaro.org Mon Feb 2 16:51:15 2015 From: edward.nevill at linaro.org (Edward Nevill) Date: Mon, 02 Feb 2015 16:51:15 +0000 Subject: RFR: JDK-8066900 : Array Out Of Bounds Exception causes variable corruption Message-ID: <1422895875.14125.13.camel@mylittlepony.linaroharston> Hi, Could someone please review this change to fix the following issue in aarch64 staging. https://bugs.openjdk.java.net/browse/JDK-8066900 Here is the webrev:- http://cr.openjdk.java.net/~enevill/8066900/webrev.00/ This is fixed for x86 in the following changeset (in the aarch64 staging), but that change has not made it to aarch64. changeset: 7547:bf3499dc002a parent: 7545:6d819d1fff7a user: iveresov date: Tue Dec 09 12:25:38 2014 -0800 files: src/cpu/x86/vm/c1_Runtime1_x86.cpp test/compiler/exceptions/SumTest.java description: 8066900: Array Out Of Bounds Exception causes variable corruption Summary: Fix FP registers save/restore during exception handling Reviewed-by: kvn, vlivanov I have tested using the SumTest.java test and verified that it fails on aarch64 before applying this patch and passes after applying the patch. If approved could someone please push to ssh://hg.openjdk.java.net/aarch64-port/stage/hotspot Many thanks, Ed. From claes.redestad at oracle.com Mon Feb 2 16:54:16 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 02 Feb 2015 17:54:16 +0100 Subject: RFR:8047290:Ensure consistent safepoint checking in MutexLockerEx In-Reply-To: <548B1194.1090905@oracle.com> References: <543EB71A.8000403@oracle.com> <543F174F.7040204@oracle.com> <545CF033.4010503@oracle.com> <54619729.30704@oracle.com> <546E638E.2020208@oracle.com> <547437EF.5010806@oracle.com> <5480D73F.7070907@oracle.com> <548547B4.7000205@oracle.com> <54887B57.2050201@oracle.com> <5488B705.6060203@oracle.com> <548B1194.1090905@oracle.com> Message-ID: <54CFABB8.8020004@oracle.com> Hi, I know this has been pushed, but I wonder if the removal of _num_mutex++ from the def macro in mutexLocker.cpp was really intentional? It seems to me this means _mutex_array won't initialize properly in the current code, breaking print_owned_locks_on_error (always prints None). Bug? /Claes On 2014-12-12 17:02, Max Ockner wrote: > OK, I have made these changes. > Thanks to everyone who helped me through this, especially Dan, David, > and Coleen. > > On 12/10/2014 4:11 PM, Daniel D. Daugherty wrote: >> On 12/10/14 9:56 AM, Max Ockner wrote: >>> New webrev: >>> http://cr.openjdk.java.net/~coleenp/8047290absolutely_final/ >> >> Thumbs up! No need for a re-review if you address any of the >> formatting comments below. >> >> Repeat from last time (I've seen trailing white space in this >> round; haven't checked for the other jcheck-ish things). >> >> - jcheck is going to complain about some of your lines that >> have trailing white space: >> >> $ grep -n ' *$' `cat files.list` >> $ grep -n '\t' `cat files.list` >> >> Don't know if you have any tabs, but I included that one also. >> Not all platforms like '\t' for the grep parameter. >> >> - jcheck may also complain about the blank lines at the end >> of the new tests >> >> src/share/vm/runtime/mutex.hpp >> line 197: SafepointCheckRequired >> safepoint_check_required = _safepoint_check_always); >> One space too many after the '='. >> >> Also, I see an extra space at the end of the line; jcheck >> will not be happy. >> >> src/share/vm/runtime/mutex.cpp >> No comments. >> >> src/share/vm/runtime/mutexLocker.cpp >> line 174: } >> Should be moved left by two spaces (i.e., one indent to the >> left of the code block above it). >> >> src/share/vm/runtime/thread.cpp >> No comments. >> >> src/share/vm/runtime/vmThread.cpp >> No comments. >> >> src/os/aix/vm/osThread_aix.cpp >> No comments. >> >> src/os/bsd/vm/osThread_bsd.cpp >> No comments. >> >> src/os/linux/vm/osThread_linux.cpp >> No comments. >> >> src/share/vm/classfile/classLoaderData.cpp >> No comments. >> >> src/share/vm/memory/metaspace.cpp >> No comments. >> >> src/share/vm/runtime/vm_operations.cpp >> No comments. >> >> src/share/vm/memory/sharedHeap.cpp >> No comments. >> >> src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp >> >> No comments. >> >> src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp >> >> line 6391: _lock(mutex_rank >= 0 ? new Mutex(mutex_rank, >> mutex_name, true , >> Extra space before the last comma. >> >> src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp >> >> No comments. >> >> src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp >> No comments. >> >> src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp >> No comments. >> >> src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp >> No comments. >> >> src/share/vm/gc_implementation/parallelScavenge/gcTaskManager.cpp >> No comments. >> >> src/share/vm/gc_implementation/shared/concurrentGCThread.cpp >> No comments. >> >> src/share/vm/services/diagnosticFramework.cpp >> No comments. >> >> src/share/vm/services/memoryManager.cpp >> No comments. >> >> src/share/vm/utilities/decoder.cpp >> No comments. >> >> src/share/vm/utilities/events.hpp >> No comments. >> >> src/share/vm/utilities/workgroup.cpp >> No comments. >> >> src/share/vm/prims/whitebox.cpp >> line 1045: WB_END >> Please add a blank line after this line. >> >> test/testlibrary/whitebox/sun/hotspot/WhiteBox.java >> No comments. >> >> test/runtime/Safepoint/AssertSafepointCheckConsistency1.java >> line 42: >> WhiteBox.getWhiteBox().assertMatchingSafepointCalls(true, true); >> Java code indent is four spaces. >> >> test/runtime/Safepoint/AssertSafepointCheckConsistency2.java >> line 42: >> WhiteBox.getWhiteBox().assertMatchingSafepointCalls(false, false); >> Java code indent is four spaces. >> >> test/runtime/Safepoint/AssertSafepointCheckConsistency3.java >> line 42: >> WhiteBox.getWhiteBox().assertMatchingSafepointCalls(false, true); >> Java code indent is four spaces. >> >> test/runtime/Safepoint/AssertSafepointCheckConsistency4.java >> line 42: >> WhiteBox.getWhiteBox().assertMatchingSafepointCalls(true, false); >> Java code indent is four spaces. >> >> Dan >> >> >> >>> >>> I have addressed dan's suggestions. I also removed unnecessary >>> "this->" occurrences from the assert statements. >>> >>> Though I realize that I have unnecessarily duplicated code in my >>> tests, I do not want to combine the tests into one right now because >>> (1) They work as they are, (2) They can fail independently, (3) The >>> amount of code needed to run all four tests in one file without >>> crashing out after the first failure is not as small as you might >>> think, and (4) I want to commit this before someone else messes with >>> the locks to avoid more merge conflicts. To be clear, I am not >>> opposed to fixing this separately if people think it is important, >>> but I prefer to put it off until the bulk of the fix is committed. >>> >>> Does this look ready? >>> >>> Thanks for your help, >>> Max O >>> >>> >>> >>> On 12/8/2014 1:39 AM, David Holmes wrote: >>>> Hi Max, >>>> >>>> Just a nit with the tests - it seems to me we should be able to >>>> write a single Java class that can process all four combinations >>>> rather than duplicating the bulk of the code. >>>> >>>> Thanks, >>>> David >>>> >>>> On 5/12/2014 7:50 AM, Max Ockner wrote: >>>>> Hello once again... >>>>> I have a new (and suggestively titled) webrev: >>>>> http://cr.openjdk.java.net/~coleenp/8047290final/ >>>>> >>>>> Ran aurora tests. >>>>> >>>>> Here is a list of "sometimes" locks: >>>>> >>>>> "WorkGroup monitor" share/vm/utilities/workgroup.cpp >>>>> "SLTMonitor" share/vm/gc_implementation/shared/concurrentGCThread.cpp >>>>> "CompactibleFreeListSpace._lock" >>>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp >>>>> >>>>> "freelist par lock" >>>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp >>>>> >>>>> "SR_lock" share/vm/runtime/thread.cpp >>>>> "CMS_markBitMap_lock" >>>>> share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp >>>>> >>>>> >>>>> >>>>> The remaining "sometimes" locks can be found in >>>>> share/vm/runtime/mutexLocker.cpp: >>>>> >>>>> ParGCRareEvent_lock >>>>> Safepoint_lock >>>>> Threads_lock >>>>> VMOperationQueue_lock >>>>> VMOperationRequest_lock >>>>> Terminator_lock >>>>> Heap_lock >>>>> Compile_lock >>>>> PeriodicTask_lock >>>>> JfrStacktrace_lock >>>>> >>>>> >>>>> Thanks, >>>>> Max Ockner >>>>> >>>>> >>>>> >>>>> >>>>> On 11/25/2014 3:03 AM, David Holmes wrote: >>>>>> Hi Max, >>>>>> >>>>>> On 21/11/2014 7:56 AM, Max Ockner wrote: >>>>>>> Hello again, >>>>>>> >>>>>>> I have made changes based on all comments. There is now a pair >>>>>>> of assert >>>>>>> statements in the Monitor/Mutex wait() methods. When I reran >>>>>>> tests, I >>>>>> >>>>>> Is there an updated webrev? >>>>>> >>>>>>> caught another lock that I had to change to "sometimes", but the >>>>>>> assert >>>>>>> that caught this lock was not in wait. There are currently no >>>>>>> locks that >>>>>>> use try to pass an incorrect safepoint check argument to wait(). >>>>>>> Instead, gcbasher did not catch this lock last time, when the only >>>>>>> asserts were in lock and lock_without_safepoint. This lock is >>>>>>> "CMS_markBitMap_lock" in >>>>>>> share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp. >>>>>>> >>>>>>> >>>>>>> I'm guessing that it was not caught by the tests because this >>>>>>> section of >>>>>>> code is not reached very often. My initial inspection failed to >>>>>>> catch >>>>>>> this lock because it is passed around between various structures >>>>>>> and >>>>>>> renamed 4 times. I have not yet found a good way to check for this >>>>>>> situation, even with a debugger. >>>>>>> >>>>>>> Are there any tests which actually manage to hit every line of >>>>>>> code? >>>>>> >>>>>> No. There is too much code that is dependent on low-level details of >>>>>> the GC used, the compilation strategy, plus the set of runtime flags >>>>>> used (and whether product or fastdebug). That's why we have lots of >>>>>> tests run in lots of different ways, to try to get coverage. >>>>>> >>>>>>> How should I handle this situation where I can't rely on the >>>>>>> tests that >>>>>>> I have run to tell me if I have missed something? >>>>>>> At what point can I assume that everything is OK? >>>>>> >>>>>> Difficult to answer in general - there are a number of recommended >>>>>> test suites used by the runtime team, but your changes will also >>>>>> impact GC and compiler code and so may not get exercised by the >>>>>> runtime test suites (unless run with various compiler and GC >>>>>> options). >>>>>> Perhaps an ad-hoc test run similar to nightlies? Or you push >>>>>> after the >>>>>> weekly snapshot so as to maximise nightly testing, and if there are >>>>>> issues exposed then you have time to address them or revert the fix. >>>>>> >>>>>> Cheers, >>>>>> David >>>>>> >>>>>>> Thanks, >>>>>>> Max Ockner >>>>>>> >>>>>>> On 11/10/2014 11:57 PM, David Holmes wrote: >>>>>>>> Hi Max, >>>>>>>> >>>>>>>> On 8/11/2014 2:15 AM, Max Ockner wrote: >>>>>>>>> Hello all, >>>>>>>>> I have made these additonal changes: >>>>>>>>> -Moved the assert() statements into the lock and >>>>>>>>> lock_without_safepoint >>>>>>>>> methods. >>>>>>>>> -Changed Monitor::SafepointAllowed to >>>>>>>>> Monitor::SafepointCheckRequired >>>>>>>>> -Changed the Monitor::SafepointCheckRequired values for >>>>>>>>> several locks >>>>>>>>> which were locked outside of a MutexLockerEx (some were locked >>>>>>>>> with >>>>>>>>> MutexLocker, some were locked were locked without any >>>>>>>>> MutexLocker* ) >>>>>>>>> >>>>>>>>> New webrev location: http://cr.openjdk.java.net/~coleenp/8047290/ >>>>>>>> >>>>>>>> Generally this is all okay - a few style and other nits below. >>>>>>>> >>>>>>>> However you missed adding an assert in Monitor::wait to check >>>>>>>> if the >>>>>>>> no_safepoint_check flag was being used correctly for the current >>>>>>>> monitor. >>>>>>>> >>>>>>>> Specific comments: >>>>>>>> >>>>>>>> src/share/vm/runtime/mutex.hpp >>>>>>>> >>>>>>>> This comment is no longer accurate with the moved check location: >>>>>>>> >>>>>>>> + // MutexLockerEx checks these flags when acquiring a lock >>>>>>>> + // to ensure consistent checking for each lock. >>>>>>>> >>>>>>>> The same goes for other references to MutexLockerEx in the enum >>>>>>>> description. >>>>>>>> >>>>>>>> Also copyright year needs updating. >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> src/share/vm/runtime/mutex.cpp >>>>>>>> >>>>>>>> 898 //Ensure >>>>>>>> 961 //Ensure >>>>>>>> >>>>>>>> Space needed after // >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> src/share/vm/runtime/mutexLocker.cpp >>>>>>>> >>>>>>>> + var = new type(Mutex::pri, #var, >>>>>>>> vm_block,safepoint_check_allowed); \ >>>>>>>> >>>>>>>> space needed after comma in k,s >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> src/share/vm/runtime/mutexLocker.hpp >>>>>>>> >>>>>>>> Whitespace only changes - looks like leftovers from removed edits. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>> >>>>>>>>> Additional testing: >>>>>>>>> jtreg ./jdk/test/java/lang/invoke >>>>>>>>> jtreg jfr tests >>>>>>>>> >>>>>>>>> Here is a list of ALL of the "sometimes" locks: >>>>>>>>> >>>>>>>>> "WorkGroup monitor" share/vm/utilities/workgroup.cpp >>>>>>>>> "SLTMonitor" >>>>>>>>> share/vm/gc_implementation/shared/concurrentGCThread.cpp >>>>>>>>> "CompactibleFreeListSpace._lock" >>>>>>>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> "freelist par lock" >>>>>>>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> "SR_lock" share/vm/runtime/thread.cpp >>>>>>>>> >>>>>>>>> The remaining "sometimes" locks can be found in >>>>>>>>> share/vm/runtime/mutexLocker.cpp: >>>>>>>>> >>>>>>>>> ParGCRareEvent_lock >>>>>>>>> Safepoint_lock >>>>>>>>> Threads_lock >>>>>>>>> VMOperationQueue_lock >>>>>>>>> VMOperationRequest_lock >>>>>>>>> Terminator_lock >>>>>>>>> Heap_lock >>>>>>>>> Compile_lock >>>>>>>>> PeriodicTask_lock >>>>>>>>> JfrStacktrace_lock >>>>>>>>> >>>>>>>>> I have not checked the validity of the "sometimes" locks, and I >>>>>>>>> believe >>>>>>>>> that this should be a different project. >>>>>>>>> >>>>>>>>> Thanks for your help! >>>>>>>>> Max Ockner >>>>>>>>> On 10/15/2014 8:54 PM, David Holmes wrote: >>>>>>>>>> Hi Max, >>>>>>>>>> >>>>>>>>>> This is looking good. >>>>>>>>>> >>>>>>>>>> A few high-level initial comments: >>>>>>>>>> >>>>>>>>>> I think SafepointAllowed should be SafepointCheckNeeded >>>>>>>>>> >>>>>>>>>> Why are the checks in MutexLocker when the state is >>>>>>>>>> maintained in the >>>>>>>>>> mutex itself and the mutex/monitor has >>>>>>>>>> lock_without_safepoint, and >>>>>>>>>> wait() ? I would have expected to >>>>>>>>>> see the >>>>>>>>>> check in the mutex/monitor methods. >>>>>>>>>> >>>>>>>>>> Checking consistent usage of the _no_safepoint_check_flag is >>>>>>>>>> good. >>>>>>>>>> But >>>>>>>>>> another part of this is that a monitor/mutex that never >>>>>>>>>> checks for >>>>>>>>>> safepoints should never be held when a thread blocks at a >>>>>>>>>> safepoint - >>>>>>>>>> is there some way to easily check that? I was surprised how many >>>>>>>>>> locks >>>>>>>>>> are actually not checking for safepoints. >>>>>>>>>> >>>>>>>>>> Did you find any cases where the mutex/monitor was being used >>>>>>>>>> inconsistently and incorrectly? >>>>>>>>>> >>>>>>>>>> Did you analyse the "sometimes" cases to see if they were safe? >>>>>>>>>> (Aside: just for fun check out what happens if you lock the >>>>>>>>>> Threads_lock with a safepoint check and a safepoint has been >>>>>>>>>> requested >>>>>>>>>> :) ). >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>> On 16/10/2014 4:04 AM, Max Ockner wrote: >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> I am a new member of the Hotspot runtime team in Burlington, >>>>>>>>>>> MA. >>>>>>>>>>> Please review my first fix related to safepoint checking. >>>>>>>>>>> >>>>>>>>>>> Summary: MutexLockerEx can either acquire a lock with or >>>>>>>>>>> without a >>>>>>>>>>> safepoint check. >>>>>>>>>>> In some cases, a particular lock must either safepoint check >>>>>>>>>>> always or >>>>>>>>>>> never to avoid deadlocking. >>>>>>>>>>> Some other locks have semantics which allow them to avoid >>>>>>>>>>> deadlocks >>>>>>>>>>> despite having a safepoint check only some of the time. >>>>>>>>>>> All locks that are OK having inconsistent safepoint checks >>>>>>>>>>> have been >>>>>>>>>>> marked. All locks that should never safepoint check and all >>>>>>>>>>> locks >>>>>>>>>>> that >>>>>>>>>>> should always safepoint check have also been marked. >>>>>>>>>>> When a MutexLockerEx acquires a lock with or without a >>>>>>>>>>> safepoint >>>>>>>>>>> check, >>>>>>>>>>> the lock's safepointAllowed marker is checked to ensure >>>>>>>>>>> consistent >>>>>>>>>>> safepoint checking. >>>>>>>>>>> >>>>>>>>>>> Webrev: http://oklahoma.us.oracle.com/~mockner/webrev/8047290/ >>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8047290 >>>>>>>>>>> >>>>>>>>>>> Tested with: >>>>>>>>>>> jprt "-testset hotspot" >>>>>>>>>>> jtreg hotspot >>>>>>>>>>> vm.quick.testlist >>>>>>>>>>> >>>>>>>>>>> Whitebox tests: >>>>>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency1.java: Test >>>>>>>>>>> >>>>>>>>>>> expects Assert ("This lock should always have a safepoint >>>>>>>>>>> check") >>>>>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency2.java: Test >>>>>>>>>>> >>>>>>>>>>> expects Assert ("This lock should never have a safepoint >>>>>>>>>>> check") >>>>>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency3.java: code >>>>>>>>>>> >>>>>>>>>>> should not assert. (Lock is properly acquired with no safepoint >>>>>>>>>>> check) >>>>>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency4.java: code >>>>>>>>>>> >>>>>>>>>>> should not assert. (Lock is properly acquired with safepoint >>>>>>>>>>> check) >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Max >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> >> > From coleen.phillimore at oracle.com Mon Feb 2 17:07:50 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 02 Feb 2015 12:07:50 -0500 Subject: RFR:8047290:Ensure consistent safepoint checking in MutexLockerEx In-Reply-To: <54CFABB8.8020004@oracle.com> References: <543EB71A.8000403@oracle.com> <543F174F.7040204@oracle.com> <545CF033.4010503@oracle.com> <54619729.30704@oracle.com> <546E638E.2020208@oracle.com> <547437EF.5010806@oracle.com> <5480D73F.7070907@oracle.com> <548547B4.7000205@oracle.com> <54887B57.2050201@oracle.com> <5488B705.6060203@oracle.com> <548B1194.1090905@oracle.com> <54CFABB8.8020004@oracle.com> Message-ID: <54CFAEE6.1060407@oracle.com> That appears unintentional. Yes, that is a bug. Do you want to file one, or we could? Thanks! Coleen On 2/2/15, 11:54 AM, Claes Redestad wrote: > Hi, > > I know this has been pushed, but I wonder if the removal of > _num_mutex++ from > the def macro in mutexLocker.cpp was really intentional? > > It seems to me this means _mutex_array won't initialize properly in > the current > code, breaking print_owned_locks_on_error (always prints None). Bug? > > /Claes > > On 2014-12-12 17:02, Max Ockner wrote: >> OK, I have made these changes. >> Thanks to everyone who helped me through this, especially Dan, David, >> and Coleen. >> >> On 12/10/2014 4:11 PM, Daniel D. Daugherty wrote: >>> On 12/10/14 9:56 AM, Max Ockner wrote: >>>> New webrev: >>>> http://cr.openjdk.java.net/~coleenp/8047290absolutely_final/ >>> >>> Thumbs up! No need for a re-review if you address any of the >>> formatting comments below. >>> >>> Repeat from last time (I've seen trailing white space in this >>> round; haven't checked for the other jcheck-ish things). >>> >>> - jcheck is going to complain about some of your lines that >>> have trailing white space: >>> >>> $ grep -n ' *$' `cat files.list` >>> $ grep -n '\t' `cat files.list` >>> >>> Don't know if you have any tabs, but I included that one also. >>> Not all platforms like '\t' for the grep parameter. >>> >>> - jcheck may also complain about the blank lines at the end >>> of the new tests >>> >>> src/share/vm/runtime/mutex.hpp >>> line 197: SafepointCheckRequired >>> safepoint_check_required = _safepoint_check_always); >>> One space too many after the '='. >>> >>> Also, I see an extra space at the end of the line; jcheck >>> will not be happy. >>> >>> src/share/vm/runtime/mutex.cpp >>> No comments. >>> >>> src/share/vm/runtime/mutexLocker.cpp >>> line 174: } >>> Should be moved left by two spaces (i.e., one indent to the >>> left of the code block above it). >>> >>> src/share/vm/runtime/thread.cpp >>> No comments. >>> >>> src/share/vm/runtime/vmThread.cpp >>> No comments. >>> >>> src/os/aix/vm/osThread_aix.cpp >>> No comments. >>> >>> src/os/bsd/vm/osThread_bsd.cpp >>> No comments. >>> >>> src/os/linux/vm/osThread_linux.cpp >>> No comments. >>> >>> src/share/vm/classfile/classLoaderData.cpp >>> No comments. >>> >>> src/share/vm/memory/metaspace.cpp >>> No comments. >>> >>> src/share/vm/runtime/vm_operations.cpp >>> No comments. >>> >>> src/share/vm/memory/sharedHeap.cpp >>> No comments. >>> >>> src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp >>> >>> No comments. >>> >>> src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp >>> >>> line 6391: _lock(mutex_rank >= 0 ? new Mutex(mutex_rank, >>> mutex_name, true , >>> Extra space before the last comma. >>> >>> src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp >>> >>> No comments. >>> >>> src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp >>> No comments. >>> >>> src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp >>> No comments. >>> >>> src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp >>> No comments. >>> >>> src/share/vm/gc_implementation/parallelScavenge/gcTaskManager.cpp >>> No comments. >>> >>> src/share/vm/gc_implementation/shared/concurrentGCThread.cpp >>> No comments. >>> >>> src/share/vm/services/diagnosticFramework.cpp >>> No comments. >>> >>> src/share/vm/services/memoryManager.cpp >>> No comments. >>> >>> src/share/vm/utilities/decoder.cpp >>> No comments. >>> >>> src/share/vm/utilities/events.hpp >>> No comments. >>> >>> src/share/vm/utilities/workgroup.cpp >>> No comments. >>> >>> src/share/vm/prims/whitebox.cpp >>> line 1045: WB_END >>> Please add a blank line after this line. >>> >>> test/testlibrary/whitebox/sun/hotspot/WhiteBox.java >>> No comments. >>> >>> test/runtime/Safepoint/AssertSafepointCheckConsistency1.java >>> line 42: >>> WhiteBox.getWhiteBox().assertMatchingSafepointCalls(true, true); >>> Java code indent is four spaces. >>> >>> test/runtime/Safepoint/AssertSafepointCheckConsistency2.java >>> line 42: >>> WhiteBox.getWhiteBox().assertMatchingSafepointCalls(false, false); >>> Java code indent is four spaces. >>> >>> test/runtime/Safepoint/AssertSafepointCheckConsistency3.java >>> line 42: >>> WhiteBox.getWhiteBox().assertMatchingSafepointCalls(false, true); >>> Java code indent is four spaces. >>> >>> test/runtime/Safepoint/AssertSafepointCheckConsistency4.java >>> line 42: >>> WhiteBox.getWhiteBox().assertMatchingSafepointCalls(true, false); >>> Java code indent is four spaces. >>> >>> Dan >>> >>> >>> >>>> >>>> I have addressed dan's suggestions. I also removed unnecessary >>>> "this->" occurrences from the assert statements. >>>> >>>> Though I realize that I have unnecessarily duplicated code in my >>>> tests, I do not want to combine the tests into one right now >>>> because (1) They work as they are, (2) They can fail independently, >>>> (3) The amount of code needed to run all four tests in one file >>>> without crashing out after the first failure is not as small as you >>>> might think, and (4) I want to commit this before someone else >>>> messes with the locks to avoid more merge conflicts. To be clear, I >>>> am not opposed to fixing this separately if people think it is >>>> important, but I prefer to put it off until the bulk of the fix is >>>> committed. >>>> >>>> Does this look ready? >>>> >>>> Thanks for your help, >>>> Max O >>>> >>>> >>>> >>>> On 12/8/2014 1:39 AM, David Holmes wrote: >>>>> Hi Max, >>>>> >>>>> Just a nit with the tests - it seems to me we should be able to >>>>> write a single Java class that can process all four combinations >>>>> rather than duplicating the bulk of the code. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 5/12/2014 7:50 AM, Max Ockner wrote: >>>>>> Hello once again... >>>>>> I have a new (and suggestively titled) webrev: >>>>>> http://cr.openjdk.java.net/~coleenp/8047290final/ >>>>>> >>>>>> Ran aurora tests. >>>>>> >>>>>> Here is a list of "sometimes" locks: >>>>>> >>>>>> "WorkGroup monitor" share/vm/utilities/workgroup.cpp >>>>>> "SLTMonitor" >>>>>> share/vm/gc_implementation/shared/concurrentGCThread.cpp >>>>>> "CompactibleFreeListSpace._lock" >>>>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp >>>>>> >>>>>> "freelist par lock" >>>>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp >>>>>> >>>>>> "SR_lock" share/vm/runtime/thread.cpp >>>>>> "CMS_markBitMap_lock" >>>>>> share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp >>>>>> >>>>>> >>>>>> >>>>>> The remaining "sometimes" locks can be found in >>>>>> share/vm/runtime/mutexLocker.cpp: >>>>>> >>>>>> ParGCRareEvent_lock >>>>>> Safepoint_lock >>>>>> Threads_lock >>>>>> VMOperationQueue_lock >>>>>> VMOperationRequest_lock >>>>>> Terminator_lock >>>>>> Heap_lock >>>>>> Compile_lock >>>>>> PeriodicTask_lock >>>>>> JfrStacktrace_lock >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Max Ockner >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 11/25/2014 3:03 AM, David Holmes wrote: >>>>>>> Hi Max, >>>>>>> >>>>>>> On 21/11/2014 7:56 AM, Max Ockner wrote: >>>>>>>> Hello again, >>>>>>>> >>>>>>>> I have made changes based on all comments. There is now a pair >>>>>>>> of assert >>>>>>>> statements in the Monitor/Mutex wait() methods. When I reran >>>>>>>> tests, I >>>>>>> >>>>>>> Is there an updated webrev? >>>>>>> >>>>>>>> caught another lock that I had to change to "sometimes", but >>>>>>>> the assert >>>>>>>> that caught this lock was not in wait. There are currently no >>>>>>>> locks that >>>>>>>> use try to pass an incorrect safepoint check argument to wait(). >>>>>>>> Instead, gcbasher did not catch this lock last time, when the only >>>>>>>> asserts were in lock and lock_without_safepoint. This lock is >>>>>>>> "CMS_markBitMap_lock" in >>>>>>>> share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp. >>>>>>>> >>>>>>>> >>>>>>>> I'm guessing that it was not caught by the tests because this >>>>>>>> section of >>>>>>>> code is not reached very often. My initial inspection failed to >>>>>>>> catch >>>>>>>> this lock because it is passed around between various >>>>>>>> structures and >>>>>>>> renamed 4 times. I have not yet found a good way to check for this >>>>>>>> situation, even with a debugger. >>>>>>>> >>>>>>>> Are there any tests which actually manage to hit every line of >>>>>>>> code? >>>>>>> >>>>>>> No. There is too much code that is dependent on low-level >>>>>>> details of >>>>>>> the GC used, the compilation strategy, plus the set of runtime >>>>>>> flags >>>>>>> used (and whether product or fastdebug). That's why we have lots of >>>>>>> tests run in lots of different ways, to try to get coverage. >>>>>>> >>>>>>>> How should I handle this situation where I can't rely on the >>>>>>>> tests that >>>>>>>> I have run to tell me if I have missed something? >>>>>>>> At what point can I assume that everything is OK? >>>>>>> >>>>>>> Difficult to answer in general - there are a number of recommended >>>>>>> test suites used by the runtime team, but your changes will also >>>>>>> impact GC and compiler code and so may not get exercised by the >>>>>>> runtime test suites (unless run with various compiler and GC >>>>>>> options). >>>>>>> Perhaps an ad-hoc test run similar to nightlies? Or you push >>>>>>> after the >>>>>>> weekly snapshot so as to maximise nightly testing, and if there are >>>>>>> issues exposed then you have time to address them or revert the >>>>>>> fix. >>>>>>> >>>>>>> Cheers, >>>>>>> David >>>>>>> >>>>>>>> Thanks, >>>>>>>> Max Ockner >>>>>>>> >>>>>>>> On 11/10/2014 11:57 PM, David Holmes wrote: >>>>>>>>> Hi Max, >>>>>>>>> >>>>>>>>> On 8/11/2014 2:15 AM, Max Ockner wrote: >>>>>>>>>> Hello all, >>>>>>>>>> I have made these additonal changes: >>>>>>>>>> -Moved the assert() statements into the lock and >>>>>>>>>> lock_without_safepoint >>>>>>>>>> methods. >>>>>>>>>> -Changed Monitor::SafepointAllowed to >>>>>>>>>> Monitor::SafepointCheckRequired >>>>>>>>>> -Changed the Monitor::SafepointCheckRequired values for >>>>>>>>>> several locks >>>>>>>>>> which were locked outside of a MutexLockerEx (some were >>>>>>>>>> locked with >>>>>>>>>> MutexLocker, some were locked were locked without any >>>>>>>>>> MutexLocker* ) >>>>>>>>>> >>>>>>>>>> New webrev location: >>>>>>>>>> http://cr.openjdk.java.net/~coleenp/8047290/ >>>>>>>>> >>>>>>>>> Generally this is all okay - a few style and other nits below. >>>>>>>>> >>>>>>>>> However you missed adding an assert in Monitor::wait to check >>>>>>>>> if the >>>>>>>>> no_safepoint_check flag was being used correctly for the current >>>>>>>>> monitor. >>>>>>>>> >>>>>>>>> Specific comments: >>>>>>>>> >>>>>>>>> src/share/vm/runtime/mutex.hpp >>>>>>>>> >>>>>>>>> This comment is no longer accurate with the moved check location: >>>>>>>>> >>>>>>>>> + // MutexLockerEx checks these flags when acquiring a lock >>>>>>>>> + // to ensure consistent checking for each lock. >>>>>>>>> >>>>>>>>> The same goes for other references to MutexLockerEx in the enum >>>>>>>>> description. >>>>>>>>> >>>>>>>>> Also copyright year needs updating. >>>>>>>>> >>>>>>>>> --- >>>>>>>>> >>>>>>>>> src/share/vm/runtime/mutex.cpp >>>>>>>>> >>>>>>>>> 898 //Ensure >>>>>>>>> 961 //Ensure >>>>>>>>> >>>>>>>>> Space needed after // >>>>>>>>> >>>>>>>>> --- >>>>>>>>> >>>>>>>>> src/share/vm/runtime/mutexLocker.cpp >>>>>>>>> >>>>>>>>> + var = new type(Mutex::pri, #var, >>>>>>>>> vm_block,safepoint_check_allowed); \ >>>>>>>>> >>>>>>>>> space needed after comma in k,s >>>>>>>>> >>>>>>>>> --- >>>>>>>>> >>>>>>>>> src/share/vm/runtime/mutexLocker.hpp >>>>>>>>> >>>>>>>>> Whitespace only changes - looks like leftovers from removed >>>>>>>>> edits. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>> >>>>>>>>>> Additional testing: >>>>>>>>>> jtreg ./jdk/test/java/lang/invoke >>>>>>>>>> jtreg jfr tests >>>>>>>>>> >>>>>>>>>> Here is a list of ALL of the "sometimes" locks: >>>>>>>>>> >>>>>>>>>> "WorkGroup monitor" share/vm/utilities/workgroup.cpp >>>>>>>>>> "SLTMonitor" >>>>>>>>>> share/vm/gc_implementation/shared/concurrentGCThread.cpp >>>>>>>>>> "CompactibleFreeListSpace._lock" >>>>>>>>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> "freelist par lock" >>>>>>>>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> "SR_lock" share/vm/runtime/thread.cpp >>>>>>>>>> >>>>>>>>>> The remaining "sometimes" locks can be found in >>>>>>>>>> share/vm/runtime/mutexLocker.cpp: >>>>>>>>>> >>>>>>>>>> ParGCRareEvent_lock >>>>>>>>>> Safepoint_lock >>>>>>>>>> Threads_lock >>>>>>>>>> VMOperationQueue_lock >>>>>>>>>> VMOperationRequest_lock >>>>>>>>>> Terminator_lock >>>>>>>>>> Heap_lock >>>>>>>>>> Compile_lock >>>>>>>>>> PeriodicTask_lock >>>>>>>>>> JfrStacktrace_lock >>>>>>>>>> >>>>>>>>>> I have not checked the validity of the "sometimes" locks, and I >>>>>>>>>> believe >>>>>>>>>> that this should be a different project. >>>>>>>>>> >>>>>>>>>> Thanks for your help! >>>>>>>>>> Max Ockner >>>>>>>>>> On 10/15/2014 8:54 PM, David Holmes wrote: >>>>>>>>>>> Hi Max, >>>>>>>>>>> >>>>>>>>>>> This is looking good. >>>>>>>>>>> >>>>>>>>>>> A few high-level initial comments: >>>>>>>>>>> >>>>>>>>>>> I think SafepointAllowed should be SafepointCheckNeeded >>>>>>>>>>> >>>>>>>>>>> Why are the checks in MutexLocker when the state is >>>>>>>>>>> maintained in the >>>>>>>>>>> mutex itself and the mutex/monitor has >>>>>>>>>>> lock_without_safepoint, and >>>>>>>>>>> wait() ? I would have expected to >>>>>>>>>>> see the >>>>>>>>>>> check in the mutex/monitor methods. >>>>>>>>>>> >>>>>>>>>>> Checking consistent usage of the _no_safepoint_check_flag is >>>>>>>>>>> good. >>>>>>>>>>> But >>>>>>>>>>> another part of this is that a monitor/mutex that never >>>>>>>>>>> checks for >>>>>>>>>>> safepoints should never be held when a thread blocks at a >>>>>>>>>>> safepoint - >>>>>>>>>>> is there some way to easily check that? I was surprised how >>>>>>>>>>> many >>>>>>>>>>> locks >>>>>>>>>>> are actually not checking for safepoints. >>>>>>>>>>> >>>>>>>>>>> Did you find any cases where the mutex/monitor was being used >>>>>>>>>>> inconsistently and incorrectly? >>>>>>>>>>> >>>>>>>>>>> Did you analyse the "sometimes" cases to see if they were safe? >>>>>>>>>>> (Aside: just for fun check out what happens if you lock the >>>>>>>>>>> Threads_lock with a safepoint check and a safepoint has been >>>>>>>>>>> requested >>>>>>>>>>> :) ). >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>> On 16/10/2014 4:04 AM, Max Ockner wrote: >>>>>>>>>>>> Hi all, >>>>>>>>>>>> >>>>>>>>>>>> I am a new member of the Hotspot runtime team in >>>>>>>>>>>> Burlington, MA. >>>>>>>>>>>> Please review my first fix related to safepoint checking. >>>>>>>>>>>> >>>>>>>>>>>> Summary: MutexLockerEx can either acquire a lock with or >>>>>>>>>>>> without a >>>>>>>>>>>> safepoint check. >>>>>>>>>>>> In some cases, a particular lock must either safepoint check >>>>>>>>>>>> always or >>>>>>>>>>>> never to avoid deadlocking. >>>>>>>>>>>> Some other locks have semantics which allow them to avoid >>>>>>>>>>>> deadlocks >>>>>>>>>>>> despite having a safepoint check only some of the time. >>>>>>>>>>>> All locks that are OK having inconsistent safepoint checks >>>>>>>>>>>> have been >>>>>>>>>>>> marked. All locks that should never safepoint check and all >>>>>>>>>>>> locks >>>>>>>>>>>> that >>>>>>>>>>>> should always safepoint check have also been marked. >>>>>>>>>>>> When a MutexLockerEx acquires a lock with or without a >>>>>>>>>>>> safepoint >>>>>>>>>>>> check, >>>>>>>>>>>> the lock's safepointAllowed marker is checked to ensure >>>>>>>>>>>> consistent >>>>>>>>>>>> safepoint checking. >>>>>>>>>>>> >>>>>>>>>>>> Webrev: http://oklahoma.us.oracle.com/~mockner/webrev/8047290/ >>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8047290 >>>>>>>>>>>> >>>>>>>>>>>> Tested with: >>>>>>>>>>>> jprt "-testset hotspot" >>>>>>>>>>>> jtreg hotspot >>>>>>>>>>>> vm.quick.testlist >>>>>>>>>>>> >>>>>>>>>>>> Whitebox tests: >>>>>>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency1.java: >>>>>>>>>>>> Test >>>>>>>>>>>> expects Assert ("This lock should always have a safepoint >>>>>>>>>>>> check") >>>>>>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency2.java: >>>>>>>>>>>> Test >>>>>>>>>>>> expects Assert ("This lock should never have a safepoint >>>>>>>>>>>> check") >>>>>>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency3.java: >>>>>>>>>>>> code >>>>>>>>>>>> should not assert. (Lock is properly acquired with no >>>>>>>>>>>> safepoint >>>>>>>>>>>> check) >>>>>>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency4.java: >>>>>>>>>>>> code >>>>>>>>>>>> should not assert. (Lock is properly acquired with >>>>>>>>>>>> safepoint check) >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Max >>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>> >>> >> > From vladimir.kozlov at oracle.com Mon Feb 2 19:23:35 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 02 Feb 2015 11:23:35 -0800 Subject: RFR: JDK-8066900 : Array Out Of Bounds Exception causes variable corruption In-Reply-To: <1422895875.14125.13.camel@mylittlepony.linaroharston> References: <1422895875.14125.13.camel@mylittlepony.linaroharston> Message-ID: <54CFCEB7.4090703@oracle.com> Hi, Ed Changes look good. But we need a separate bug for this to avoid conflict during future merge into jdk9 (can't have changesets with the same bug id). I created one and will push with its id: https://bugs.openjdk.java.net/browse/JDK-8072129 Thanks, Vladimir On 2/2/15 8:51 AM, Edward Nevill wrote: > Hi, > > Could someone please review this change to fix the following issue in aarch64 staging. > > https://bugs.openjdk.java.net/browse/JDK-8066900 > > Here is the webrev:- > > http://cr.openjdk.java.net/~enevill/8066900/webrev.00/ > > This is fixed for x86 in the following changeset (in the aarch64 staging), but that change has not made it to aarch64. > > changeset: 7547:bf3499dc002a > parent: 7545:6d819d1fff7a > user: iveresov > date: Tue Dec 09 12:25:38 2014 -0800 > files: src/cpu/x86/vm/c1_Runtime1_x86.cpp test/compiler/exceptions/SumTest.java > description: > 8066900: Array Out Of Bounds Exception causes variable corruption > Summary: Fix FP registers save/restore during exception handling > Reviewed-by: kvn, vlivanov > > I have tested using the SumTest.java test and verified that it fails on aarch64 before applying this patch and passes after applying the patch. > > If approved could someone please push to > > ssh://hg.openjdk.java.net/aarch64-port/stage/hotspot > > Many thanks, > Ed. > > From dean.long at oracle.com Mon Feb 2 22:46:39 2015 From: dean.long at oracle.com (Dean Long) Date: Mon, 02 Feb 2015 14:46:39 -0800 Subject: RFR(XS) 8069030: support new PTRACE_GETREGSET In-Reply-To: <54C9899A.2070206@oracle.com> References: <54C70F7D.3010003@oracle.com> <54C9899A.2070206@oracle.com> Message-ID: <54CFFE4F.7020007@oracle.com> Ping. I'm still waiting for a second review on this. thanks, dl On 1/28/2015 5:15 PM, Dean Long wrote: > Adding serviceability-dev at openjdk.java.net. Can I get another review > for this please? > > thanks, > > dl > > On 1/26/2015 11:02 PM, Staffan Larsen wrote: >> Looks good! >> >> Thanks, >> /Staffan >> >>> On 27 jan 2015, at 05:09, Dean Long wrote: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8069030 >>> >>> http://cr.openjdk.java.net/~dlong/8069030/webrev.00/ >>> >>> Testing on linux x86 by temporarily undefining PTRACE_GETREGS_REQ so >>> that the new code >>> would get triggered, then stepping through "jstack -m " with >>> gdb to make sure the new >>> code executed correctly. >>> >>> dl >>> > From vladimir.kozlov at oracle.com Mon Feb 2 23:08:14 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 02 Feb 2015 15:08:14 -0800 Subject: RFR (S): 8071996: split_if accesses NULL region of ConstraintCast In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CF8A11B@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CF8A11B@DEWDFEMB12A.global.corp.sap> Message-ID: <54D0035E.7090907@oracle.com> Hi, Goetz The fix is good but the comment is slightly off. It is not "region edge", it is "control edge". In current case it could be IfTrue or IfFalse projection nodes which points to If node which we compare. Also this control edge is required: 359 } else if( v->is_ConstraintCast() ) { 360 proj = v->in(0); // Controlling projection 361 } else { 362 assert( 0, "do not know how to handle this guy" ); 363 } 364 365 Node *proj_path_data, *proj_path_ctrl; 366 if( proj->Opcode() == Op_IfTrue ) { Thanks, Vladimir On 2/1/15 11:22 PM, Lindenmaier, Goetz wrote: > Hi, > > I fixed a small bug in the C2 compiler. > It appeared in our s390/zArch port running hs25.31 with jdk6 when executing > jvm2008/compiler.compiler. > > Split_if encounters a ConstraintCast without region edge, which is a valid pattern. > But it reads the region edge unconditionally, thus failing. > > Please review this change. I please need a sponsor. > http://cr.openjdk.java.net/~goetz/webrevs/8071996-fixSplitIf/webrev.01/ > > Best regards, > Goetz. > > From dean.long at oracle.com Mon Feb 2 23:26:09 2015 From: dean.long at oracle.com (Dean Long) Date: Mon, 02 Feb 2015 15:26:09 -0800 Subject: Request for approval: Backport of 8031064(XS) Message-ID: <54D00791.6000801@oracle.com> I would like to backport 8031064 to 8u60: https://bugs.openjdk.java.net/browse/JDK-8031064 http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/72904af52714 It has been baking in jdk9 for over a week, and the patch applied cleanly except for the copyright year. dl From david.holmes at oracle.com Tue Feb 3 01:07:32 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 03 Feb 2015 11:07:32 +1000 Subject: RFR(XS) 8069030: support new PTRACE_GETREGSET In-Reply-To: <54CFFE4F.7020007@oracle.com> References: <54C70F7D.3010003@oracle.com> <54C9899A.2070206@oracle.com> <54CFFE4F.7020007@oracle.com> Message-ID: <54D01F54.9050601@oracle.com> Looks good. Thanks, David On 3/02/2015 8:46 AM, Dean Long wrote: > Ping. I'm still waiting for a second review on this. > > thanks, > > dl > > On 1/28/2015 5:15 PM, Dean Long wrote: >> Adding serviceability-dev at openjdk.java.net. Can I get another review >> for this please? >> >> thanks, >> >> dl >> >> On 1/26/2015 11:02 PM, Staffan Larsen wrote: >>> Looks good! >>> >>> Thanks, >>> /Staffan >>> >>>> On 27 jan 2015, at 05:09, Dean Long wrote: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8069030 >>>> >>>> http://cr.openjdk.java.net/~dlong/8069030/webrev.00/ >>>> >>>> Testing on linux x86 by temporarily undefining PTRACE_GETREGS_REQ so >>>> that the new code >>>> would get triggered, then stepping through "jstack -m " with >>>> gdb to make sure the new >>>> code executed correctly. >>>> >>>> dl >>>> >> > From david.holmes at oracle.com Tue Feb 3 01:19:29 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 03 Feb 2015 11:19:29 +1000 Subject: Request for approval: Backport of 8031064(XS) In-Reply-To: <54D00791.6000801@oracle.com> References: <54D00791.6000801@oracle.com> Message-ID: <54D02221.1080508@oracle.com> On 3/02/2015 9:26 AM, Dean Long wrote: > I would like to backport 8031064 to 8u60: > > https://bugs.openjdk.java.net/browse/JDK-8031064 > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/72904af52714 > > It has been baking in jdk9 for over a week, and the patch applied > cleanly except for the copyright year. Seems fine to backport to me. Thanks, David > > dl From dean.long at oracle.com Tue Feb 3 04:31:40 2015 From: dean.long at oracle.com (Dean Long) Date: Mon, 02 Feb 2015 20:31:40 -0800 Subject: RFR(XS) 8069030: support new PTRACE_GETREGSET In-Reply-To: <54D01F54.9050601@oracle.com> References: <54C70F7D.3010003@oracle.com> <54C9899A.2070206@oracle.com> <54CFFE4F.7020007@oracle.com> <54D01F54.9050601@oracle.com> Message-ID: <54D04F2C.60405@oracle.com> Thanks David and Staffan for the reviews. dl On 2/2/2015 5:07 PM, David Holmes wrote: > Looks good. > > Thanks, > David > > On 3/02/2015 8:46 AM, Dean Long wrote: >> Ping. I'm still waiting for a second review on this. >> >> thanks, >> >> dl >> >> On 1/28/2015 5:15 PM, Dean Long wrote: >>> Adding serviceability-dev at openjdk.java.net. Can I get another review >>> for this please? >>> >>> thanks, >>> >>> dl >>> >>> On 1/26/2015 11:02 PM, Staffan Larsen wrote: >>>> Looks good! >>>> >>>> Thanks, >>>> /Staffan >>>> >>>>> On 27 jan 2015, at 05:09, Dean Long wrote: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8069030 >>>>> >>>>> http://cr.openjdk.java.net/~dlong/8069030/webrev.00/ >>>>> >>>>> Testing on linux x86 by temporarily undefining PTRACE_GETREGS_REQ so >>>>> that the new code >>>>> would get triggered, then stepping through "jstack -m " with >>>>> gdb to make sure the new >>>>> code executed correctly. >>>>> >>>>> dl >>>>> >>> >> From dean.long at oracle.com Tue Feb 3 04:33:22 2015 From: dean.long at oracle.com (Dean Long) Date: Mon, 02 Feb 2015 20:33:22 -0800 Subject: Request for approval: Backport of 8031064(XS) In-Reply-To: <54D02221.1080508@oracle.com> References: <54D00791.6000801@oracle.com> <54D02221.1080508@oracle.com> Message-ID: <54D04F92.7060607@oracle.com> Thanks David. dl On 2/2/2015 5:19 PM, David Holmes wrote: > On 3/02/2015 9:26 AM, Dean Long wrote: >> I would like to backport 8031064 to 8u60: >> >> https://bugs.openjdk.java.net/browse/JDK-8031064 >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/72904af52714 >> >> It has been baking in jdk9 for over a week, and the patch applied >> cleanly except for the copyright year. > > Seems fine to backport to me. > > Thanks, > David > >> >> dl From goetz.lindenmaier at sap.com Tue Feb 3 09:38:22 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 3 Feb 2015 09:38:22 +0000 Subject: RFR (S): 8071996: split_if accesses NULL region of ConstraintCast In-Reply-To: <54D0035E.7090907@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CF8A11B@DEWDFEMB12A.global.corp.sap> <54D0035E.7090907@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CF90E6A@DEWDFEMB12A.global.corp.sap> Hi Vladimir, thanks for looking at this! I updated the comment: // If the cast is derived from data flow edges, it may not have a control. // If so, it should be save to split. But follow-up code can not deal with // this (l. 359). So skip. And uploaded a new webrev. http://cr.openjdk.java.net/~goetz/webrevs/8071996-fixSplitIf/webrev.02/ Best regards, Goetz. -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov Sent: Dienstag, 3. Februar 2015 00:08 To: hotspot-dev at openjdk.java.net Subject: Re: RFR (S): 8071996: split_if accesses NULL region of ConstraintCast Hi, Goetz The fix is good but the comment is slightly off. It is not "region edge", it is "control edge". In current case it could be IfTrue or IfFalse projection nodes which points to If node which we compare. Also this control edge is required: 359 } else if( v->is_ConstraintCast() ) { 360 proj = v->in(0); // Controlling projection 361 } else { 362 assert( 0, "do not know how to handle this guy" ); 363 } 364 365 Node *proj_path_data, *proj_path_ctrl; 366 if( proj->Opcode() == Op_IfTrue ) { Thanks, Vladimir On 2/1/15 11:22 PM, Lindenmaier, Goetz wrote: > Hi, > > I fixed a small bug in the C2 compiler. > It appeared in our s390/zArch port running hs25.31 with jdk6 when executing > jvm2008/compiler.compiler. > > Split_if encounters a ConstraintCast without region edge, which is a valid pattern. > But it reads the region edge unconditionally, thus failing. > > Please review this change. I please need a sponsor. > http://cr.openjdk.java.net/~goetz/webrevs/8071996-fixSplitIf/webrev.01/ > > Best regards, > Goetz. > > From goetz.lindenmaier at sap.com Tue Feb 3 09:41:16 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 3 Feb 2015 09:41:16 +0000 Subject: [8u] backport 8068013: [TESTBUG] Aix support in hotspot jtreg tests In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CF71269@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CF71269@DEWDFEMB12A.global.corp.sap> Message-ID: <4295855A5C1DE049A61835A1887419CC2CF90E7D@DEWDFEMB12A.global.corp.sap> Hi, any comments on this? Could somebody please volunteer to sponsor? Thanks, Goetz. From: Lindenmaier, Goetz Sent: Donnerstag, 22. Januar 2015 10:25 To: hotspot-dev at openjdk.java.net Subject: [8u] backport 8068013: [TESTBUG] Aix support in hotspot jtreg tests Hi, I would like to backport this change. It basically makes the jtreg test infrastructure aware of aix. This fixes a lot of the jtreg tests. The change from 9 applied cleanly with some obvious exceptions: - The copyright adaption didn't merge in * test/runtime/6888954/vmerrors.sh * test/test_env.sh * test/testlibrary/com/oracle/java/testlibrary/Platform.java - Changes in files not available in 8: * test/serviceability/dcmd/DynLibDcmdTest.java: Test does not * test/testlibrary_tests/TestMutuallyExclusivePlatformPredicates.java The webrev applying to 8: http://cr.openjdk.java.net/~goetz/webrevs/8068013-jtregAix/webrev.02-jdk8/ The original webrev http://cr.openjdk.java.net/~goetz/webrevs/8068013-jtregAix/webrev-02/ The incremental patch: http://cr.openjdk.java.net/~goetz/webrevs/8068013-jtregAix/webrev.02-jdk8/incremental_diff.patch I please need a sponsor. Best regards, Goetz. From claes.redestad at oracle.com Tue Feb 3 12:21:32 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 03 Feb 2015 13:21:32 +0100 Subject: RFR:8047290:Ensure consistent safepoint checking in MutexLockerEx In-Reply-To: <54CFAEE6.1060407@oracle.com> References: <543EB71A.8000403@oracle.com> <543F174F.7040204@oracle.com> <545CF033.4010503@oracle.com> <54619729.30704@oracle.com> <546E638E.2020208@oracle.com> <547437EF.5010806@oracle.com> <5480D73F.7070907@oracle.com> <548547B4.7000205@oracle.com> <54887B57.2050201@oracle.com> <5488B705.6060203@oracle.com> <548B1194.1090905@oracle.com> <54CFABB8.8020004@oracle.com> <54CFAEE6.1060407@oracle.com> Message-ID: <54D0BD4C.4080201@oracle.com> Filed https://bugs.openjdk.java.net/browse/JDK-8072406, thanks! /Claes On 02/02/2015 06:07 PM, Coleen Phillimore wrote: > > That appears unintentional. Yes, that is a bug. Do you want to > file one, or we could? > Thanks! > Coleen > > On 2/2/15, 11:54 AM, Claes Redestad wrote: >> Hi, >> >> I know this has been pushed, but I wonder if the removal of >> _num_mutex++ from >> the def macro in mutexLocker.cpp was really intentional? >> >> It seems to me this means _mutex_array won't initialize properly in >> the current >> code, breaking print_owned_locks_on_error (always prints None). Bug? >> >> /Claes >> >> On 2014-12-12 17:02, Max Ockner wrote: >>> OK, I have made these changes. >>> Thanks to everyone who helped me through this, especially Dan, >>> David, and Coleen. >>> >>> On 12/10/2014 4:11 PM, Daniel D. Daugherty wrote: >>>> On 12/10/14 9:56 AM, Max Ockner wrote: >>>>> New webrev: >>>>> http://cr.openjdk.java.net/~coleenp/8047290absolutely_final/ >>>> >>>> Thumbs up! No need for a re-review if you address any of the >>>> formatting comments below. >>>> >>>> Repeat from last time (I've seen trailing white space in this >>>> round; haven't checked for the other jcheck-ish things). >>>> >>>> - jcheck is going to complain about some of your lines that >>>> have trailing white space: >>>> >>>> $ grep -n ' *$' `cat files.list` >>>> $ grep -n '\t' `cat files.list` >>>> >>>> Don't know if you have any tabs, but I included that one also. >>>> Not all platforms like '\t' for the grep parameter. >>>> >>>> - jcheck may also complain about the blank lines at the end >>>> of the new tests >>>> >>>> src/share/vm/runtime/mutex.hpp >>>> line 197: SafepointCheckRequired >>>> safepoint_check_required = _safepoint_check_always); >>>> One space too many after the '='. >>>> >>>> Also, I see an extra space at the end of the line; jcheck >>>> will not be happy. >>>> >>>> src/share/vm/runtime/mutex.cpp >>>> No comments. >>>> >>>> src/share/vm/runtime/mutexLocker.cpp >>>> line 174: } >>>> Should be moved left by two spaces (i.e., one indent to the >>>> left of the code block above it). >>>> >>>> src/share/vm/runtime/thread.cpp >>>> No comments. >>>> >>>> src/share/vm/runtime/vmThread.cpp >>>> No comments. >>>> >>>> src/os/aix/vm/osThread_aix.cpp >>>> No comments. >>>> >>>> src/os/bsd/vm/osThread_bsd.cpp >>>> No comments. >>>> >>>> src/os/linux/vm/osThread_linux.cpp >>>> No comments. >>>> >>>> src/share/vm/classfile/classLoaderData.cpp >>>> No comments. >>>> >>>> src/share/vm/memory/metaspace.cpp >>>> No comments. >>>> >>>> src/share/vm/runtime/vm_operations.cpp >>>> No comments. >>>> >>>> src/share/vm/memory/sharedHeap.cpp >>>> No comments. >>>> >>>> src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp >>>> >>>> No comments. >>>> >>>> src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp >>>> >>>> line 6391: _lock(mutex_rank >= 0 ? new Mutex(mutex_rank, >>>> mutex_name, true , >>>> Extra space before the last comma. >>>> >>>> src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp >>>> >>>> No comments. >>>> >>>> src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp >>>> No comments. >>>> >>>> src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp >>>> No comments. >>>> >>>> src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp >>>> No comments. >>>> >>>> src/share/vm/gc_implementation/parallelScavenge/gcTaskManager.cpp >>>> No comments. >>>> >>>> src/share/vm/gc_implementation/shared/concurrentGCThread.cpp >>>> No comments. >>>> >>>> src/share/vm/services/diagnosticFramework.cpp >>>> No comments. >>>> >>>> src/share/vm/services/memoryManager.cpp >>>> No comments. >>>> >>>> src/share/vm/utilities/decoder.cpp >>>> No comments. >>>> >>>> src/share/vm/utilities/events.hpp >>>> No comments. >>>> >>>> src/share/vm/utilities/workgroup.cpp >>>> No comments. >>>> >>>> src/share/vm/prims/whitebox.cpp >>>> line 1045: WB_END >>>> Please add a blank line after this line. >>>> >>>> test/testlibrary/whitebox/sun/hotspot/WhiteBox.java >>>> No comments. >>>> >>>> test/runtime/Safepoint/AssertSafepointCheckConsistency1.java >>>> line 42: >>>> WhiteBox.getWhiteBox().assertMatchingSafepointCalls(true, true); >>>> Java code indent is four spaces. >>>> >>>> test/runtime/Safepoint/AssertSafepointCheckConsistency2.java >>>> line 42: >>>> WhiteBox.getWhiteBox().assertMatchingSafepointCalls(false, false); >>>> Java code indent is four spaces. >>>> >>>> test/runtime/Safepoint/AssertSafepointCheckConsistency3.java >>>> line 42: >>>> WhiteBox.getWhiteBox().assertMatchingSafepointCalls(false, true); >>>> Java code indent is four spaces. >>>> >>>> test/runtime/Safepoint/AssertSafepointCheckConsistency4.java >>>> line 42: >>>> WhiteBox.getWhiteBox().assertMatchingSafepointCalls(true, false); >>>> Java code indent is four spaces. >>>> >>>> Dan >>>> >>>> >>>> >>>>> >>>>> I have addressed dan's suggestions. I also removed unnecessary >>>>> "this->" occurrences from the assert statements. >>>>> >>>>> Though I realize that I have unnecessarily duplicated code in my >>>>> tests, I do not want to combine the tests into one right now >>>>> because (1) They work as they are, (2) They can fail >>>>> independently, (3) The amount of code needed to run all four tests >>>>> in one file without crashing out after the first failure is not as >>>>> small as you might think, and (4) I want to commit this before >>>>> someone else messes with the locks to avoid more merge conflicts. >>>>> To be clear, I am not opposed to fixing this separately if people >>>>> think it is important, but I prefer to put it off until the bulk >>>>> of the fix is committed. >>>>> >>>>> Does this look ready? >>>>> >>>>> Thanks for your help, >>>>> Max O >>>>> >>>>> >>>>> >>>>> On 12/8/2014 1:39 AM, David Holmes wrote: >>>>>> Hi Max, >>>>>> >>>>>> Just a nit with the tests - it seems to me we should be able to >>>>>> write a single Java class that can process all four combinations >>>>>> rather than duplicating the bulk of the code. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> On 5/12/2014 7:50 AM, Max Ockner wrote: >>>>>>> Hello once again... >>>>>>> I have a new (and suggestively titled) webrev: >>>>>>> http://cr.openjdk.java.net/~coleenp/8047290final/ >>>>>>> >>>>>>> Ran aurora tests. >>>>>>> >>>>>>> Here is a list of "sometimes" locks: >>>>>>> >>>>>>> "WorkGroup monitor" share/vm/utilities/workgroup.cpp >>>>>>> "SLTMonitor" >>>>>>> share/vm/gc_implementation/shared/concurrentGCThread.cpp >>>>>>> "CompactibleFreeListSpace._lock" >>>>>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp >>>>>>> >>>>>>> "freelist par lock" >>>>>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp >>>>>>> >>>>>>> "SR_lock" share/vm/runtime/thread.cpp >>>>>>> "CMS_markBitMap_lock" >>>>>>> share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp >>>>>>> >>>>>>> >>>>>>> >>>>>>> The remaining "sometimes" locks can be found in >>>>>>> share/vm/runtime/mutexLocker.cpp: >>>>>>> >>>>>>> ParGCRareEvent_lock >>>>>>> Safepoint_lock >>>>>>> Threads_lock >>>>>>> VMOperationQueue_lock >>>>>>> VMOperationRequest_lock >>>>>>> Terminator_lock >>>>>>> Heap_lock >>>>>>> Compile_lock >>>>>>> PeriodicTask_lock >>>>>>> JfrStacktrace_lock >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Max Ockner >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 11/25/2014 3:03 AM, David Holmes wrote: >>>>>>>> Hi Max, >>>>>>>> >>>>>>>> On 21/11/2014 7:56 AM, Max Ockner wrote: >>>>>>>>> Hello again, >>>>>>>>> >>>>>>>>> I have made changes based on all comments. There is now a pair >>>>>>>>> of assert >>>>>>>>> statements in the Monitor/Mutex wait() methods. When I reran >>>>>>>>> tests, I >>>>>>>> >>>>>>>> Is there an updated webrev? >>>>>>>> >>>>>>>>> caught another lock that I had to change to "sometimes", but >>>>>>>>> the assert >>>>>>>>> that caught this lock was not in wait. There are currently no >>>>>>>>> locks that >>>>>>>>> use try to pass an incorrect safepoint check argument to wait(). >>>>>>>>> Instead, gcbasher did not catch this lock last time, when the >>>>>>>>> only >>>>>>>>> asserts were in lock and lock_without_safepoint. This lock is >>>>>>>>> "CMS_markBitMap_lock" in >>>>>>>>> share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp. >>>>>>>>> >>>>>>>>> >>>>>>>>> I'm guessing that it was not caught by the tests because this >>>>>>>>> section of >>>>>>>>> code is not reached very often. My initial inspection failed >>>>>>>>> to catch >>>>>>>>> this lock because it is passed around between various >>>>>>>>> structures and >>>>>>>>> renamed 4 times. I have not yet found a good way to check for >>>>>>>>> this >>>>>>>>> situation, even with a debugger. >>>>>>>>> >>>>>>>>> Are there any tests which actually manage to hit every line of >>>>>>>>> code? >>>>>>>> >>>>>>>> No. There is too much code that is dependent on low-level >>>>>>>> details of >>>>>>>> the GC used, the compilation strategy, plus the set of runtime >>>>>>>> flags >>>>>>>> used (and whether product or fastdebug). That's why we have >>>>>>>> lots of >>>>>>>> tests run in lots of different ways, to try to get coverage. >>>>>>>> >>>>>>>>> How should I handle this situation where I can't rely on the >>>>>>>>> tests that >>>>>>>>> I have run to tell me if I have missed something? >>>>>>>>> At what point can I assume that everything is OK? >>>>>>>> >>>>>>>> Difficult to answer in general - there are a number of recommended >>>>>>>> test suites used by the runtime team, but your changes will also >>>>>>>> impact GC and compiler code and so may not get exercised by the >>>>>>>> runtime test suites (unless run with various compiler and GC >>>>>>>> options). >>>>>>>> Perhaps an ad-hoc test run similar to nightlies? Or you push >>>>>>>> after the >>>>>>>> weekly snapshot so as to maximise nightly testing, and if there >>>>>>>> are >>>>>>>> issues exposed then you have time to address them or revert the >>>>>>>> fix. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> David >>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Max Ockner >>>>>>>>> >>>>>>>>> On 11/10/2014 11:57 PM, David Holmes wrote: >>>>>>>>>> Hi Max, >>>>>>>>>> >>>>>>>>>> On 8/11/2014 2:15 AM, Max Ockner wrote: >>>>>>>>>>> Hello all, >>>>>>>>>>> I have made these additonal changes: >>>>>>>>>>> -Moved the assert() statements into the lock and >>>>>>>>>>> lock_without_safepoint >>>>>>>>>>> methods. >>>>>>>>>>> -Changed Monitor::SafepointAllowed to >>>>>>>>>>> Monitor::SafepointCheckRequired >>>>>>>>>>> -Changed the Monitor::SafepointCheckRequired values for >>>>>>>>>>> several locks >>>>>>>>>>> which were locked outside of a MutexLockerEx (some were >>>>>>>>>>> locked with >>>>>>>>>>> MutexLocker, some were locked were locked without any >>>>>>>>>>> MutexLocker* ) >>>>>>>>>>> >>>>>>>>>>> New webrev location: >>>>>>>>>>> http://cr.openjdk.java.net/~coleenp/8047290/ >>>>>>>>>> >>>>>>>>>> Generally this is all okay - a few style and other nits below. >>>>>>>>>> >>>>>>>>>> However you missed adding an assert in Monitor::wait to check >>>>>>>>>> if the >>>>>>>>>> no_safepoint_check flag was being used correctly for the current >>>>>>>>>> monitor. >>>>>>>>>> >>>>>>>>>> Specific comments: >>>>>>>>>> >>>>>>>>>> src/share/vm/runtime/mutex.hpp >>>>>>>>>> >>>>>>>>>> This comment is no longer accurate with the moved check >>>>>>>>>> location: >>>>>>>>>> >>>>>>>>>> + // MutexLockerEx checks these flags when acquiring a lock >>>>>>>>>> + // to ensure consistent checking for each lock. >>>>>>>>>> >>>>>>>>>> The same goes for other references to MutexLockerEx in the enum >>>>>>>>>> description. >>>>>>>>>> >>>>>>>>>> Also copyright year needs updating. >>>>>>>>>> >>>>>>>>>> --- >>>>>>>>>> >>>>>>>>>> src/share/vm/runtime/mutex.cpp >>>>>>>>>> >>>>>>>>>> 898 //Ensure >>>>>>>>>> 961 //Ensure >>>>>>>>>> >>>>>>>>>> Space needed after // >>>>>>>>>> >>>>>>>>>> --- >>>>>>>>>> >>>>>>>>>> src/share/vm/runtime/mutexLocker.cpp >>>>>>>>>> >>>>>>>>>> + var = new type(Mutex::pri, #var, >>>>>>>>>> vm_block,safepoint_check_allowed); \ >>>>>>>>>> >>>>>>>>>> space needed after comma in k,s >>>>>>>>>> >>>>>>>>>> --- >>>>>>>>>> >>>>>>>>>> src/share/vm/runtime/mutexLocker.hpp >>>>>>>>>> >>>>>>>>>> Whitespace only changes - looks like leftovers from removed >>>>>>>>>> edits. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Additional testing: >>>>>>>>>>> jtreg ./jdk/test/java/lang/invoke >>>>>>>>>>> jtreg jfr tests >>>>>>>>>>> >>>>>>>>>>> Here is a list of ALL of the "sometimes" locks: >>>>>>>>>>> >>>>>>>>>>> "WorkGroup monitor" share/vm/utilities/workgroup.cpp >>>>>>>>>>> "SLTMonitor" >>>>>>>>>>> share/vm/gc_implementation/shared/concurrentGCThread.cpp >>>>>>>>>>> "CompactibleFreeListSpace._lock" >>>>>>>>>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> "freelist par lock" >>>>>>>>>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> "SR_lock" share/vm/runtime/thread.cpp >>>>>>>>>>> >>>>>>>>>>> The remaining "sometimes" locks can be found in >>>>>>>>>>> share/vm/runtime/mutexLocker.cpp: >>>>>>>>>>> >>>>>>>>>>> ParGCRareEvent_lock >>>>>>>>>>> Safepoint_lock >>>>>>>>>>> Threads_lock >>>>>>>>>>> VMOperationQueue_lock >>>>>>>>>>> VMOperationRequest_lock >>>>>>>>>>> Terminator_lock >>>>>>>>>>> Heap_lock >>>>>>>>>>> Compile_lock >>>>>>>>>>> PeriodicTask_lock >>>>>>>>>>> JfrStacktrace_lock >>>>>>>>>>> >>>>>>>>>>> I have not checked the validity of the "sometimes" locks, and I >>>>>>>>>>> believe >>>>>>>>>>> that this should be a different project. >>>>>>>>>>> >>>>>>>>>>> Thanks for your help! >>>>>>>>>>> Max Ockner >>>>>>>>>>> On 10/15/2014 8:54 PM, David Holmes wrote: >>>>>>>>>>>> Hi Max, >>>>>>>>>>>> >>>>>>>>>>>> This is looking good. >>>>>>>>>>>> >>>>>>>>>>>> A few high-level initial comments: >>>>>>>>>>>> >>>>>>>>>>>> I think SafepointAllowed should be SafepointCheckNeeded >>>>>>>>>>>> >>>>>>>>>>>> Why are the checks in MutexLocker when the state is >>>>>>>>>>>> maintained in the >>>>>>>>>>>> mutex itself and the mutex/monitor has >>>>>>>>>>>> lock_without_safepoint, and >>>>>>>>>>>> wait() ? I would have expected to >>>>>>>>>>>> see the >>>>>>>>>>>> check in the mutex/monitor methods. >>>>>>>>>>>> >>>>>>>>>>>> Checking consistent usage of the _no_safepoint_check_flag >>>>>>>>>>>> is good. >>>>>>>>>>>> But >>>>>>>>>>>> another part of this is that a monitor/mutex that never >>>>>>>>>>>> checks for >>>>>>>>>>>> safepoints should never be held when a thread blocks at a >>>>>>>>>>>> safepoint - >>>>>>>>>>>> is there some way to easily check that? I was surprised how >>>>>>>>>>>> many >>>>>>>>>>>> locks >>>>>>>>>>>> are actually not checking for safepoints. >>>>>>>>>>>> >>>>>>>>>>>> Did you find any cases where the mutex/monitor was being used >>>>>>>>>>>> inconsistently and incorrectly? >>>>>>>>>>>> >>>>>>>>>>>> Did you analyse the "sometimes" cases to see if they were >>>>>>>>>>>> safe? >>>>>>>>>>>> (Aside: just for fun check out what happens if you lock the >>>>>>>>>>>> Threads_lock with a safepoint check and a safepoint has been >>>>>>>>>>>> requested >>>>>>>>>>>> :) ). >>>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>> On 16/10/2014 4:04 AM, Max Ockner wrote: >>>>>>>>>>>>> Hi all, >>>>>>>>>>>>> >>>>>>>>>>>>> I am a new member of the Hotspot runtime team in >>>>>>>>>>>>> Burlington, MA. >>>>>>>>>>>>> Please review my first fix related to safepoint checking. >>>>>>>>>>>>> >>>>>>>>>>>>> Summary: MutexLockerEx can either acquire a lock with or >>>>>>>>>>>>> without a >>>>>>>>>>>>> safepoint check. >>>>>>>>>>>>> In some cases, a particular lock must either safepoint check >>>>>>>>>>>>> always or >>>>>>>>>>>>> never to avoid deadlocking. >>>>>>>>>>>>> Some other locks have semantics which allow them to avoid >>>>>>>>>>>>> deadlocks >>>>>>>>>>>>> despite having a safepoint check only some of the time. >>>>>>>>>>>>> All locks that are OK having inconsistent safepoint checks >>>>>>>>>>>>> have been >>>>>>>>>>>>> marked. All locks that should never safepoint check and >>>>>>>>>>>>> all locks >>>>>>>>>>>>> that >>>>>>>>>>>>> should always safepoint check have also been marked. >>>>>>>>>>>>> When a MutexLockerEx acquires a lock with or without a >>>>>>>>>>>>> safepoint >>>>>>>>>>>>> check, >>>>>>>>>>>>> the lock's safepointAllowed marker is checked to ensure >>>>>>>>>>>>> consistent >>>>>>>>>>>>> safepoint checking. >>>>>>>>>>>>> >>>>>>>>>>>>> Webrev: >>>>>>>>>>>>> http://oklahoma.us.oracle.com/~mockner/webrev/8047290/ >>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8047290 >>>>>>>>>>>>> >>>>>>>>>>>>> Tested with: >>>>>>>>>>>>> jprt "-testset hotspot" >>>>>>>>>>>>> jtreg hotspot >>>>>>>>>>>>> vm.quick.testlist >>>>>>>>>>>>> >>>>>>>>>>>>> Whitebox tests: >>>>>>>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency1.java: >>>>>>>>>>>>> Test >>>>>>>>>>>>> expects Assert ("This lock should always have a safepoint >>>>>>>>>>>>> check") >>>>>>>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency2.java: >>>>>>>>>>>>> Test >>>>>>>>>>>>> expects Assert ("This lock should never have a safepoint >>>>>>>>>>>>> check") >>>>>>>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency3.java: >>>>>>>>>>>>> code >>>>>>>>>>>>> should not assert. (Lock is properly acquired with no >>>>>>>>>>>>> safepoint >>>>>>>>>>>>> check) >>>>>>>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency4.java: >>>>>>>>>>>>> code >>>>>>>>>>>>> should not assert. (Lock is properly acquired with >>>>>>>>>>>>> safepoint check) >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Max >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>>> >>> >> > From daniel.daugherty at oracle.com Tue Feb 3 14:54:00 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 03 Feb 2015 07:54:00 -0700 Subject: RFR:8047290:Ensure consistent safepoint checking in MutexLockerEx In-Reply-To: <54D0BD4C.4080201@oracle.com> References: <543EB71A.8000403@oracle.com> <543F174F.7040204@oracle.com> <545CF033.4010503@oracle.com> <54619729.30704@oracle.com> <546E638E.2020208@oracle.com> <547437EF.5010806@oracle.com> <5480D73F.7070907@oracle.com> <548547B4.7000205@oracle.com> <54887B57.2050201@oracle.com> <5488B705.6060203@oracle.com> <548B1194.1090905@oracle.com> <54CFABB8.8020004@oracle.com> <54CFAEE6.1060407@oracle.com> <54D0BD4C.4080201@oracle.com> Message-ID: <54D0E108.9020903@oracle.com> Claes, Coleen filed the following bug yesterday: JDK-8072128 mutexLocker.cpp _mutex_array[] initialization broken with safepoint check change https://bugs.openjdk.java.net/browse/JDK-8072128 I've closed JDK-8072406 as a dup of JDK-8072128. Dan On 2/3/15 5:21 AM, Claes Redestad wrote: > Filed https://bugs.openjdk.java.net/browse/JDK-8072406, thanks! > > /Claes > > On 02/02/2015 06:07 PM, Coleen Phillimore wrote: >> >> That appears unintentional. Yes, that is a bug. Do you want to >> file one, or we could? >> Thanks! >> Coleen >> >> On 2/2/15, 11:54 AM, Claes Redestad wrote: >>> Hi, >>> >>> I know this has been pushed, but I wonder if the removal of >>> _num_mutex++ from >>> the def macro in mutexLocker.cpp was really intentional? >>> >>> It seems to me this means _mutex_array won't initialize properly in >>> the current >>> code, breaking print_owned_locks_on_error (always prints None). Bug? >>> >>> /Claes >>> >>> On 2014-12-12 17:02, Max Ockner wrote: >>>> OK, I have made these changes. >>>> Thanks to everyone who helped me through this, especially Dan, >>>> David, and Coleen. >>>> >>>> On 12/10/2014 4:11 PM, Daniel D. Daugherty wrote: >>>>> On 12/10/14 9:56 AM, Max Ockner wrote: >>>>>> New webrev: >>>>>> http://cr.openjdk.java.net/~coleenp/8047290absolutely_final/ >>>>> >>>>> Thumbs up! No need for a re-review if you address any of the >>>>> formatting comments below. >>>>> >>>>> Repeat from last time (I've seen trailing white space in this >>>>> round; haven't checked for the other jcheck-ish things). >>>>> >>>>> - jcheck is going to complain about some of your lines that >>>>> have trailing white space: >>>>> >>>>> $ grep -n ' *$' `cat files.list` >>>>> $ grep -n '\t' `cat files.list` >>>>> >>>>> Don't know if you have any tabs, but I included that one also. >>>>> Not all platforms like '\t' for the grep parameter. >>>>> >>>>> - jcheck may also complain about the blank lines at the end >>>>> of the new tests >>>>> >>>>> src/share/vm/runtime/mutex.hpp >>>>> line 197: SafepointCheckRequired >>>>> safepoint_check_required = _safepoint_check_always); >>>>> One space too many after the '='. >>>>> >>>>> Also, I see an extra space at the end of the line; jcheck >>>>> will not be happy. >>>>> >>>>> src/share/vm/runtime/mutex.cpp >>>>> No comments. >>>>> >>>>> src/share/vm/runtime/mutexLocker.cpp >>>>> line 174: } >>>>> Should be moved left by two spaces (i.e., one indent to the >>>>> left of the code block above it). >>>>> >>>>> src/share/vm/runtime/thread.cpp >>>>> No comments. >>>>> >>>>> src/share/vm/runtime/vmThread.cpp >>>>> No comments. >>>>> >>>>> src/os/aix/vm/osThread_aix.cpp >>>>> No comments. >>>>> >>>>> src/os/bsd/vm/osThread_bsd.cpp >>>>> No comments. >>>>> >>>>> src/os/linux/vm/osThread_linux.cpp >>>>> No comments. >>>>> >>>>> src/share/vm/classfile/classLoaderData.cpp >>>>> No comments. >>>>> >>>>> src/share/vm/memory/metaspace.cpp >>>>> No comments. >>>>> >>>>> src/share/vm/runtime/vm_operations.cpp >>>>> No comments. >>>>> >>>>> src/share/vm/memory/sharedHeap.cpp >>>>> No comments. >>>>> >>>>> src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp >>>>> >>>>> No comments. >>>>> >>>>> src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp >>>>> >>>>> line 6391: _lock(mutex_rank >= 0 ? new Mutex(mutex_rank, >>>>> mutex_name, true , >>>>> Extra space before the last comma. >>>>> >>>>> src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp >>>>> >>>>> No comments. >>>>> >>>>> src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp >>>>> No comments. >>>>> >>>>> src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp >>>>> No comments. >>>>> >>>>> src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp >>>>> No comments. >>>>> >>>>> src/share/vm/gc_implementation/parallelScavenge/gcTaskManager.cpp >>>>> No comments. >>>>> >>>>> src/share/vm/gc_implementation/shared/concurrentGCThread.cpp >>>>> No comments. >>>>> >>>>> src/share/vm/services/diagnosticFramework.cpp >>>>> No comments. >>>>> >>>>> src/share/vm/services/memoryManager.cpp >>>>> No comments. >>>>> >>>>> src/share/vm/utilities/decoder.cpp >>>>> No comments. >>>>> >>>>> src/share/vm/utilities/events.hpp >>>>> No comments. >>>>> >>>>> src/share/vm/utilities/workgroup.cpp >>>>> No comments. >>>>> >>>>> src/share/vm/prims/whitebox.cpp >>>>> line 1045: WB_END >>>>> Please add a blank line after this line. >>>>> >>>>> test/testlibrary/whitebox/sun/hotspot/WhiteBox.java >>>>> No comments. >>>>> >>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency1.java >>>>> line 42: >>>>> WhiteBox.getWhiteBox().assertMatchingSafepointCalls(true, true); >>>>> Java code indent is four spaces. >>>>> >>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency2.java >>>>> line 42: >>>>> WhiteBox.getWhiteBox().assertMatchingSafepointCalls(false, false); >>>>> Java code indent is four spaces. >>>>> >>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency3.java >>>>> line 42: >>>>> WhiteBox.getWhiteBox().assertMatchingSafepointCalls(false, true); >>>>> Java code indent is four spaces. >>>>> >>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency4.java >>>>> line 42: >>>>> WhiteBox.getWhiteBox().assertMatchingSafepointCalls(true, false); >>>>> Java code indent is four spaces. >>>>> >>>>> Dan >>>>> >>>>> >>>>> >>>>>> >>>>>> I have addressed dan's suggestions. I also removed unnecessary >>>>>> "this->" occurrences from the assert statements. >>>>>> >>>>>> Though I realize that I have unnecessarily duplicated code in my >>>>>> tests, I do not want to combine the tests into one right now >>>>>> because (1) They work as they are, (2) They can fail >>>>>> independently, (3) The amount of code needed to run all four >>>>>> tests in one file without crashing out after the first failure is >>>>>> not as small as you might think, and (4) I want to commit this >>>>>> before someone else messes with the locks to avoid more merge >>>>>> conflicts. To be clear, I am not opposed to fixing this >>>>>> separately if people think it is important, but I prefer to put >>>>>> it off until the bulk of the fix is committed. >>>>>> >>>>>> Does this look ready? >>>>>> >>>>>> Thanks for your help, >>>>>> Max O >>>>>> >>>>>> >>>>>> >>>>>> On 12/8/2014 1:39 AM, David Holmes wrote: >>>>>>> Hi Max, >>>>>>> >>>>>>> Just a nit with the tests - it seems to me we should be able to >>>>>>> write a single Java class that can process all four combinations >>>>>>> rather than duplicating the bulk of the code. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> On 5/12/2014 7:50 AM, Max Ockner wrote: >>>>>>>> Hello once again... >>>>>>>> I have a new (and suggestively titled) webrev: >>>>>>>> http://cr.openjdk.java.net/~coleenp/8047290final/ >>>>>>>> >>>>>>>> Ran aurora tests. >>>>>>>> >>>>>>>> Here is a list of "sometimes" locks: >>>>>>>> >>>>>>>> "WorkGroup monitor" share/vm/utilities/workgroup.cpp >>>>>>>> "SLTMonitor" >>>>>>>> share/vm/gc_implementation/shared/concurrentGCThread.cpp >>>>>>>> "CompactibleFreeListSpace._lock" >>>>>>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp >>>>>>>> >>>>>>>> "freelist par lock" >>>>>>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp >>>>>>>> >>>>>>>> "SR_lock" share/vm/runtime/thread.cpp >>>>>>>> "CMS_markBitMap_lock" >>>>>>>> share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The remaining "sometimes" locks can be found in >>>>>>>> share/vm/runtime/mutexLocker.cpp: >>>>>>>> >>>>>>>> ParGCRareEvent_lock >>>>>>>> Safepoint_lock >>>>>>>> Threads_lock >>>>>>>> VMOperationQueue_lock >>>>>>>> VMOperationRequest_lock >>>>>>>> Terminator_lock >>>>>>>> Heap_lock >>>>>>>> Compile_lock >>>>>>>> PeriodicTask_lock >>>>>>>> JfrStacktrace_lock >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Max Ockner >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 11/25/2014 3:03 AM, David Holmes wrote: >>>>>>>>> Hi Max, >>>>>>>>> >>>>>>>>> On 21/11/2014 7:56 AM, Max Ockner wrote: >>>>>>>>>> Hello again, >>>>>>>>>> >>>>>>>>>> I have made changes based on all comments. There is now a >>>>>>>>>> pair of assert >>>>>>>>>> statements in the Monitor/Mutex wait() methods. When I reran >>>>>>>>>> tests, I >>>>>>>>> >>>>>>>>> Is there an updated webrev? >>>>>>>>> >>>>>>>>>> caught another lock that I had to change to "sometimes", but >>>>>>>>>> the assert >>>>>>>>>> that caught this lock was not in wait. There are currently no >>>>>>>>>> locks that >>>>>>>>>> use try to pass an incorrect safepoint check argument to wait(). >>>>>>>>>> Instead, gcbasher did not catch this lock last time, when the >>>>>>>>>> only >>>>>>>>>> asserts were in lock and lock_without_safepoint. This lock is >>>>>>>>>> "CMS_markBitMap_lock" in >>>>>>>>>> share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I'm guessing that it was not caught by the tests because this >>>>>>>>>> section of >>>>>>>>>> code is not reached very often. My initial inspection failed >>>>>>>>>> to catch >>>>>>>>>> this lock because it is passed around between various >>>>>>>>>> structures and >>>>>>>>>> renamed 4 times. I have not yet found a good way to check for >>>>>>>>>> this >>>>>>>>>> situation, even with a debugger. >>>>>>>>>> >>>>>>>>>> Are there any tests which actually manage to hit every line >>>>>>>>>> of code? >>>>>>>>> >>>>>>>>> No. There is too much code that is dependent on low-level >>>>>>>>> details of >>>>>>>>> the GC used, the compilation strategy, plus the set of runtime >>>>>>>>> flags >>>>>>>>> used (and whether product or fastdebug). That's why we have >>>>>>>>> lots of >>>>>>>>> tests run in lots of different ways, to try to get coverage. >>>>>>>>> >>>>>>>>>> How should I handle this situation where I can't rely on the >>>>>>>>>> tests that >>>>>>>>>> I have run to tell me if I have missed something? >>>>>>>>>> At what point can I assume that everything is OK? >>>>>>>>> >>>>>>>>> Difficult to answer in general - there are a number of >>>>>>>>> recommended >>>>>>>>> test suites used by the runtime team, but your changes will also >>>>>>>>> impact GC and compiler code and so may not get exercised by the >>>>>>>>> runtime test suites (unless run with various compiler and GC >>>>>>>>> options). >>>>>>>>> Perhaps an ad-hoc test run similar to nightlies? Or you push >>>>>>>>> after the >>>>>>>>> weekly snapshot so as to maximise nightly testing, and if >>>>>>>>> there are >>>>>>>>> issues exposed then you have time to address them or revert >>>>>>>>> the fix. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Max Ockner >>>>>>>>>> >>>>>>>>>> On 11/10/2014 11:57 PM, David Holmes wrote: >>>>>>>>>>> Hi Max, >>>>>>>>>>> >>>>>>>>>>> On 8/11/2014 2:15 AM, Max Ockner wrote: >>>>>>>>>>>> Hello all, >>>>>>>>>>>> I have made these additonal changes: >>>>>>>>>>>> -Moved the assert() statements into the lock and >>>>>>>>>>>> lock_without_safepoint >>>>>>>>>>>> methods. >>>>>>>>>>>> -Changed Monitor::SafepointAllowed to >>>>>>>>>>>> Monitor::SafepointCheckRequired >>>>>>>>>>>> -Changed the Monitor::SafepointCheckRequired values for >>>>>>>>>>>> several locks >>>>>>>>>>>> which were locked outside of a MutexLockerEx (some were >>>>>>>>>>>> locked with >>>>>>>>>>>> MutexLocker, some were locked were locked without any >>>>>>>>>>>> MutexLocker* ) >>>>>>>>>>>> >>>>>>>>>>>> New webrev location: >>>>>>>>>>>> http://cr.openjdk.java.net/~coleenp/8047290/ >>>>>>>>>>> >>>>>>>>>>> Generally this is all okay - a few style and other nits below. >>>>>>>>>>> >>>>>>>>>>> However you missed adding an assert in Monitor::wait to >>>>>>>>>>> check if the >>>>>>>>>>> no_safepoint_check flag was being used correctly for the >>>>>>>>>>> current >>>>>>>>>>> monitor. >>>>>>>>>>> >>>>>>>>>>> Specific comments: >>>>>>>>>>> >>>>>>>>>>> src/share/vm/runtime/mutex.hpp >>>>>>>>>>> >>>>>>>>>>> This comment is no longer accurate with the moved check >>>>>>>>>>> location: >>>>>>>>>>> >>>>>>>>>>> + // MutexLockerEx checks these flags when acquiring a lock >>>>>>>>>>> + // to ensure consistent checking for each lock. >>>>>>>>>>> >>>>>>>>>>> The same goes for other references to MutexLockerEx in the enum >>>>>>>>>>> description. >>>>>>>>>>> >>>>>>>>>>> Also copyright year needs updating. >>>>>>>>>>> >>>>>>>>>>> --- >>>>>>>>>>> >>>>>>>>>>> src/share/vm/runtime/mutex.cpp >>>>>>>>>>> >>>>>>>>>>> 898 //Ensure >>>>>>>>>>> 961 //Ensure >>>>>>>>>>> >>>>>>>>>>> Space needed after // >>>>>>>>>>> >>>>>>>>>>> --- >>>>>>>>>>> >>>>>>>>>>> src/share/vm/runtime/mutexLocker.cpp >>>>>>>>>>> >>>>>>>>>>> + var = new type(Mutex::pri, #var, >>>>>>>>>>> vm_block,safepoint_check_allowed); \ >>>>>>>>>>> >>>>>>>>>>> space needed after comma in k,s >>>>>>>>>>> >>>>>>>>>>> --- >>>>>>>>>>> >>>>>>>>>>> src/share/vm/runtime/mutexLocker.hpp >>>>>>>>>>> >>>>>>>>>>> Whitespace only changes - looks like leftovers from removed >>>>>>>>>>> edits. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> David >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Additional testing: >>>>>>>>>>>> jtreg ./jdk/test/java/lang/invoke >>>>>>>>>>>> jtreg jfr tests >>>>>>>>>>>> >>>>>>>>>>>> Here is a list of ALL of the "sometimes" locks: >>>>>>>>>>>> >>>>>>>>>>>> "WorkGroup monitor" share/vm/utilities/workgroup.cpp >>>>>>>>>>>> "SLTMonitor" >>>>>>>>>>>> share/vm/gc_implementation/shared/concurrentGCThread.cpp >>>>>>>>>>>> "CompactibleFreeListSpace._lock" >>>>>>>>>>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> "freelist par lock" >>>>>>>>>>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> "SR_lock" share/vm/runtime/thread.cpp >>>>>>>>>>>> >>>>>>>>>>>> The remaining "sometimes" locks can be found in >>>>>>>>>>>> share/vm/runtime/mutexLocker.cpp: >>>>>>>>>>>> >>>>>>>>>>>> ParGCRareEvent_lock >>>>>>>>>>>> Safepoint_lock >>>>>>>>>>>> Threads_lock >>>>>>>>>>>> VMOperationQueue_lock >>>>>>>>>>>> VMOperationRequest_lock >>>>>>>>>>>> Terminator_lock >>>>>>>>>>>> Heap_lock >>>>>>>>>>>> Compile_lock >>>>>>>>>>>> PeriodicTask_lock >>>>>>>>>>>> JfrStacktrace_lock >>>>>>>>>>>> >>>>>>>>>>>> I have not checked the validity of the "sometimes" locks, >>>>>>>>>>>> and I >>>>>>>>>>>> believe >>>>>>>>>>>> that this should be a different project. >>>>>>>>>>>> >>>>>>>>>>>> Thanks for your help! >>>>>>>>>>>> Max Ockner >>>>>>>>>>>> On 10/15/2014 8:54 PM, David Holmes wrote: >>>>>>>>>>>>> Hi Max, >>>>>>>>>>>>> >>>>>>>>>>>>> This is looking good. >>>>>>>>>>>>> >>>>>>>>>>>>> A few high-level initial comments: >>>>>>>>>>>>> >>>>>>>>>>>>> I think SafepointAllowed should be SafepointCheckNeeded >>>>>>>>>>>>> >>>>>>>>>>>>> Why are the checks in MutexLocker when the state is >>>>>>>>>>>>> maintained in the >>>>>>>>>>>>> mutex itself and the mutex/monitor has >>>>>>>>>>>>> lock_without_safepoint, and >>>>>>>>>>>>> wait() ? I would have expected to >>>>>>>>>>>>> see the >>>>>>>>>>>>> check in the mutex/monitor methods. >>>>>>>>>>>>> >>>>>>>>>>>>> Checking consistent usage of the _no_safepoint_check_flag >>>>>>>>>>>>> is good. >>>>>>>>>>>>> But >>>>>>>>>>>>> another part of this is that a monitor/mutex that never >>>>>>>>>>>>> checks for >>>>>>>>>>>>> safepoints should never be held when a thread blocks at a >>>>>>>>>>>>> safepoint - >>>>>>>>>>>>> is there some way to easily check that? I was surprised >>>>>>>>>>>>> how many >>>>>>>>>>>>> locks >>>>>>>>>>>>> are actually not checking for safepoints. >>>>>>>>>>>>> >>>>>>>>>>>>> Did you find any cases where the mutex/monitor was being used >>>>>>>>>>>>> inconsistently and incorrectly? >>>>>>>>>>>>> >>>>>>>>>>>>> Did you analyse the "sometimes" cases to see if they were >>>>>>>>>>>>> safe? >>>>>>>>>>>>> (Aside: just for fun check out what happens if you lock the >>>>>>>>>>>>> Threads_lock with a safepoint check and a safepoint has been >>>>>>>>>>>>> requested >>>>>>>>>>>>> :) ). >>>>>>>>>>>>> >>>>>>>>>>>>> Cheers, >>>>>>>>>>>>> David >>>>>>>>>>>>> >>>>>>>>>>>>> On 16/10/2014 4:04 AM, Max Ockner wrote: >>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I am a new member of the Hotspot runtime team in >>>>>>>>>>>>>> Burlington, MA. >>>>>>>>>>>>>> Please review my first fix related to safepoint checking. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Summary: MutexLockerEx can either acquire a lock with or >>>>>>>>>>>>>> without a >>>>>>>>>>>>>> safepoint check. >>>>>>>>>>>>>> In some cases, a particular lock must either safepoint check >>>>>>>>>>>>>> always or >>>>>>>>>>>>>> never to avoid deadlocking. >>>>>>>>>>>>>> Some other locks have semantics which allow them to avoid >>>>>>>>>>>>>> deadlocks >>>>>>>>>>>>>> despite having a safepoint check only some of the time. >>>>>>>>>>>>>> All locks that are OK having inconsistent safepoint >>>>>>>>>>>>>> checks have been >>>>>>>>>>>>>> marked. All locks that should never safepoint check and >>>>>>>>>>>>>> all locks >>>>>>>>>>>>>> that >>>>>>>>>>>>>> should always safepoint check have also been marked. >>>>>>>>>>>>>> When a MutexLockerEx acquires a lock with or without a >>>>>>>>>>>>>> safepoint >>>>>>>>>>>>>> check, >>>>>>>>>>>>>> the lock's safepointAllowed marker is checked to ensure >>>>>>>>>>>>>> consistent >>>>>>>>>>>>>> safepoint checking. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Webrev: >>>>>>>>>>>>>> http://oklahoma.us.oracle.com/~mockner/webrev/8047290/ >>>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8047290 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Tested with: >>>>>>>>>>>>>> jprt "-testset hotspot" >>>>>>>>>>>>>> jtreg hotspot >>>>>>>>>>>>>> vm.quick.testlist >>>>>>>>>>>>>> >>>>>>>>>>>>>> Whitebox tests: >>>>>>>>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency1.java: >>>>>>>>>>>>>> Test >>>>>>>>>>>>>> expects Assert ("This lock should always have a safepoint >>>>>>>>>>>>>> check") >>>>>>>>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency2.java: >>>>>>>>>>>>>> Test >>>>>>>>>>>>>> expects Assert ("This lock should never have a safepoint >>>>>>>>>>>>>> check") >>>>>>>>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency3.java: >>>>>>>>>>>>>> code >>>>>>>>>>>>>> should not assert. (Lock is properly acquired with no >>>>>>>>>>>>>> safepoint >>>>>>>>>>>>>> check) >>>>>>>>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency4.java: >>>>>>>>>>>>>> code >>>>>>>>>>>>>> should not assert. (Lock is properly acquired with >>>>>>>>>>>>>> safepoint check) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Max >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >>> >> > > > From coleen.phillimore at oracle.com Tue Feb 3 16:57:06 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 03 Feb 2015 11:57:06 -0500 Subject: RFR:8047290:Ensure consistent safepoint checking in MutexLockerEx In-Reply-To: <54D0E108.9020903@oracle.com> References: <543EB71A.8000403@oracle.com> <543F174F.7040204@oracle.com> <545CF033.4010503@oracle.com> <54619729.30704@oracle.com> <546E638E.2020208@oracle.com> <547437EF.5010806@oracle.com> <5480D73F.7070907@oracle.com> <548547B4.7000205@oracle.com> <54887B57.2050201@oracle.com> <5488B705.6060203@oracle.com> <548B1194.1090905@oracle.com> <54CFABB8.8020004@oracle.com> <54CFAEE6.1060407@oracle.com> <54D0BD4C.4080201@oracle.com> <54D0E108.9020903@oracle.com> Message-ID: <54D0FDE2.5070208@oracle.com> Thanks, Dan. Coleen On 2/3/15, 9:54 AM, Daniel D. Daugherty wrote: > Claes, > > Coleen filed the following bug yesterday: > > JDK-8072128 mutexLocker.cpp _mutex_array[] initialization broken > with safepoint check change > https://bugs.openjdk.java.net/browse/JDK-8072128 > > I've closed JDK-8072406 as a dup of JDK-8072128. > > Dan > > > On 2/3/15 5:21 AM, Claes Redestad wrote: >> Filed https://bugs.openjdk.java.net/browse/JDK-8072406, thanks! >> >> /Claes >> >> On 02/02/2015 06:07 PM, Coleen Phillimore wrote: >>> >>> That appears unintentional. Yes, that is a bug. Do you want to >>> file one, or we could? >>> Thanks! >>> Coleen >>> >>> On 2/2/15, 11:54 AM, Claes Redestad wrote: >>>> Hi, >>>> >>>> I know this has been pushed, but I wonder if the removal of >>>> _num_mutex++ from >>>> the def macro in mutexLocker.cpp was really intentional? >>>> >>>> It seems to me this means _mutex_array won't initialize properly in >>>> the current >>>> code, breaking print_owned_locks_on_error (always prints None). Bug? >>>> >>>> /Claes >>>> >>>> On 2014-12-12 17:02, Max Ockner wrote: >>>>> OK, I have made these changes. >>>>> Thanks to everyone who helped me through this, especially Dan, >>>>> David, and Coleen. >>>>> >>>>> On 12/10/2014 4:11 PM, Daniel D. Daugherty wrote: >>>>>> On 12/10/14 9:56 AM, Max Ockner wrote: >>>>>>> New webrev: >>>>>>> http://cr.openjdk.java.net/~coleenp/8047290absolutely_final/ >>>>>> >>>>>> Thumbs up! No need for a re-review if you address any of the >>>>>> formatting comments below. >>>>>> >>>>>> Repeat from last time (I've seen trailing white space in this >>>>>> round; haven't checked for the other jcheck-ish things). >>>>>> >>>>>> - jcheck is going to complain about some of your lines that >>>>>> have trailing white space: >>>>>> >>>>>> $ grep -n ' *$' `cat files.list` >>>>>> $ grep -n '\t' `cat files.list` >>>>>> >>>>>> Don't know if you have any tabs, but I included that one also. >>>>>> Not all platforms like '\t' for the grep parameter. >>>>>> >>>>>> - jcheck may also complain about the blank lines at the end >>>>>> of the new tests >>>>>> >>>>>> src/share/vm/runtime/mutex.hpp >>>>>> line 197: SafepointCheckRequired >>>>>> safepoint_check_required = _safepoint_check_always); >>>>>> One space too many after the '='. >>>>>> >>>>>> Also, I see an extra space at the end of the line; jcheck >>>>>> will not be happy. >>>>>> >>>>>> src/share/vm/runtime/mutex.cpp >>>>>> No comments. >>>>>> >>>>>> src/share/vm/runtime/mutexLocker.cpp >>>>>> line 174: } >>>>>> Should be moved left by two spaces (i.e., one indent to the >>>>>> left of the code block above it). >>>>>> >>>>>> src/share/vm/runtime/thread.cpp >>>>>> No comments. >>>>>> >>>>>> src/share/vm/runtime/vmThread.cpp >>>>>> No comments. >>>>>> >>>>>> src/os/aix/vm/osThread_aix.cpp >>>>>> No comments. >>>>>> >>>>>> src/os/bsd/vm/osThread_bsd.cpp >>>>>> No comments. >>>>>> >>>>>> src/os/linux/vm/osThread_linux.cpp >>>>>> No comments. >>>>>> >>>>>> src/share/vm/classfile/classLoaderData.cpp >>>>>> No comments. >>>>>> >>>>>> src/share/vm/memory/metaspace.cpp >>>>>> No comments. >>>>>> >>>>>> src/share/vm/runtime/vm_operations.cpp >>>>>> No comments. >>>>>> >>>>>> src/share/vm/memory/sharedHeap.cpp >>>>>> No comments. >>>>>> >>>>>> src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp >>>>>> >>>>>> No comments. >>>>>> >>>>>> src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp >>>>>> >>>>>> line 6391: _lock(mutex_rank >= 0 ? new Mutex(mutex_rank, >>>>>> mutex_name, true , >>>>>> Extra space before the last comma. >>>>>> >>>>>> src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp >>>>>> >>>>>> No comments. >>>>>> >>>>>> src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp >>>>>> No comments. >>>>>> >>>>>> src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp >>>>>> No comments. >>>>>> >>>>>> src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp >>>>>> No comments. >>>>>> >>>>>> src/share/vm/gc_implementation/parallelScavenge/gcTaskManager.cpp >>>>>> No comments. >>>>>> >>>>>> src/share/vm/gc_implementation/shared/concurrentGCThread.cpp >>>>>> No comments. >>>>>> >>>>>> src/share/vm/services/diagnosticFramework.cpp >>>>>> No comments. >>>>>> >>>>>> src/share/vm/services/memoryManager.cpp >>>>>> No comments. >>>>>> >>>>>> src/share/vm/utilities/decoder.cpp >>>>>> No comments. >>>>>> >>>>>> src/share/vm/utilities/events.hpp >>>>>> No comments. >>>>>> >>>>>> src/share/vm/utilities/workgroup.cpp >>>>>> No comments. >>>>>> >>>>>> src/share/vm/prims/whitebox.cpp >>>>>> line 1045: WB_END >>>>>> Please add a blank line after this line. >>>>>> >>>>>> test/testlibrary/whitebox/sun/hotspot/WhiteBox.java >>>>>> No comments. >>>>>> >>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency1.java >>>>>> line 42: >>>>>> WhiteBox.getWhiteBox().assertMatchingSafepointCalls(true, true); >>>>>> Java code indent is four spaces. >>>>>> >>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency2.java >>>>>> line 42: >>>>>> WhiteBox.getWhiteBox().assertMatchingSafepointCalls(false, false); >>>>>> Java code indent is four spaces. >>>>>> >>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency3.java >>>>>> line 42: >>>>>> WhiteBox.getWhiteBox().assertMatchingSafepointCalls(false, true); >>>>>> Java code indent is four spaces. >>>>>> >>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency4.java >>>>>> line 42: >>>>>> WhiteBox.getWhiteBox().assertMatchingSafepointCalls(true, false); >>>>>> Java code indent is four spaces. >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> I have addressed dan's suggestions. I also removed unnecessary >>>>>>> "this->" occurrences from the assert statements. >>>>>>> >>>>>>> Though I realize that I have unnecessarily duplicated code in my >>>>>>> tests, I do not want to combine the tests into one right now >>>>>>> because (1) They work as they are, (2) They can fail >>>>>>> independently, (3) The amount of code needed to run all four >>>>>>> tests in one file without crashing out after the first failure >>>>>>> is not as small as you might think, and (4) I want to commit >>>>>>> this before someone else messes with the locks to avoid more >>>>>>> merge conflicts. To be clear, I am not opposed to fixing this >>>>>>> separately if people think it is important, but I prefer to put >>>>>>> it off until the bulk of the fix is committed. >>>>>>> >>>>>>> Does this look ready? >>>>>>> >>>>>>> Thanks for your help, >>>>>>> Max O >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 12/8/2014 1:39 AM, David Holmes wrote: >>>>>>>> Hi Max, >>>>>>>> >>>>>>>> Just a nit with the tests - it seems to me we should be able to >>>>>>>> write a single Java class that can process all four >>>>>>>> combinations rather than duplicating the bulk of the code. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>> On 5/12/2014 7:50 AM, Max Ockner wrote: >>>>>>>>> Hello once again... >>>>>>>>> I have a new (and suggestively titled) webrev: >>>>>>>>> http://cr.openjdk.java.net/~coleenp/8047290final/ >>>>>>>>> >>>>>>>>> Ran aurora tests. >>>>>>>>> >>>>>>>>> Here is a list of "sometimes" locks: >>>>>>>>> >>>>>>>>> "WorkGroup monitor" share/vm/utilities/workgroup.cpp >>>>>>>>> "SLTMonitor" >>>>>>>>> share/vm/gc_implementation/shared/concurrentGCThread.cpp >>>>>>>>> "CompactibleFreeListSpace._lock" >>>>>>>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp >>>>>>>>> >>>>>>>>> "freelist par lock" >>>>>>>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp >>>>>>>>> >>>>>>>>> "SR_lock" share/vm/runtime/thread.cpp >>>>>>>>> "CMS_markBitMap_lock" >>>>>>>>> share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> The remaining "sometimes" locks can be found in >>>>>>>>> share/vm/runtime/mutexLocker.cpp: >>>>>>>>> >>>>>>>>> ParGCRareEvent_lock >>>>>>>>> Safepoint_lock >>>>>>>>> Threads_lock >>>>>>>>> VMOperationQueue_lock >>>>>>>>> VMOperationRequest_lock >>>>>>>>> Terminator_lock >>>>>>>>> Heap_lock >>>>>>>>> Compile_lock >>>>>>>>> PeriodicTask_lock >>>>>>>>> JfrStacktrace_lock >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Max Ockner >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 11/25/2014 3:03 AM, David Holmes wrote: >>>>>>>>>> Hi Max, >>>>>>>>>> >>>>>>>>>> On 21/11/2014 7:56 AM, Max Ockner wrote: >>>>>>>>>>> Hello again, >>>>>>>>>>> >>>>>>>>>>> I have made changes based on all comments. There is now a >>>>>>>>>>> pair of assert >>>>>>>>>>> statements in the Monitor/Mutex wait() methods. When I reran >>>>>>>>>>> tests, I >>>>>>>>>> >>>>>>>>>> Is there an updated webrev? >>>>>>>>>> >>>>>>>>>>> caught another lock that I had to change to "sometimes", but >>>>>>>>>>> the assert >>>>>>>>>>> that caught this lock was not in wait. There are currently >>>>>>>>>>> no locks that >>>>>>>>>>> use try to pass an incorrect safepoint check argument to >>>>>>>>>>> wait(). >>>>>>>>>>> Instead, gcbasher did not catch this lock last time, when >>>>>>>>>>> the only >>>>>>>>>>> asserts were in lock and lock_without_safepoint. This lock is >>>>>>>>>>> "CMS_markBitMap_lock" in >>>>>>>>>>> share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I'm guessing that it was not caught by the tests because >>>>>>>>>>> this section of >>>>>>>>>>> code is not reached very often. My initial inspection failed >>>>>>>>>>> to catch >>>>>>>>>>> this lock because it is passed around between various >>>>>>>>>>> structures and >>>>>>>>>>> renamed 4 times. I have not yet found a good way to check >>>>>>>>>>> for this >>>>>>>>>>> situation, even with a debugger. >>>>>>>>>>> >>>>>>>>>>> Are there any tests which actually manage to hit every line >>>>>>>>>>> of code? >>>>>>>>>> >>>>>>>>>> No. There is too much code that is dependent on low-level >>>>>>>>>> details of >>>>>>>>>> the GC used, the compilation strategy, plus the set of >>>>>>>>>> runtime flags >>>>>>>>>> used (and whether product or fastdebug). That's why we have >>>>>>>>>> lots of >>>>>>>>>> tests run in lots of different ways, to try to get coverage. >>>>>>>>>> >>>>>>>>>>> How should I handle this situation where I can't rely on the >>>>>>>>>>> tests that >>>>>>>>>>> I have run to tell me if I have missed something? >>>>>>>>>>> At what point can I assume that everything is OK? >>>>>>>>>> >>>>>>>>>> Difficult to answer in general - there are a number of >>>>>>>>>> recommended >>>>>>>>>> test suites used by the runtime team, but your changes will also >>>>>>>>>> impact GC and compiler code and so may not get exercised by the >>>>>>>>>> runtime test suites (unless run with various compiler and GC >>>>>>>>>> options). >>>>>>>>>> Perhaps an ad-hoc test run similar to nightlies? Or you push >>>>>>>>>> after the >>>>>>>>>> weekly snapshot so as to maximise nightly testing, and if >>>>>>>>>> there are >>>>>>>>>> issues exposed then you have time to address them or revert >>>>>>>>>> the fix. >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Max Ockner >>>>>>>>>>> >>>>>>>>>>> On 11/10/2014 11:57 PM, David Holmes wrote: >>>>>>>>>>>> Hi Max, >>>>>>>>>>>> >>>>>>>>>>>> On 8/11/2014 2:15 AM, Max Ockner wrote: >>>>>>>>>>>>> Hello all, >>>>>>>>>>>>> I have made these additonal changes: >>>>>>>>>>>>> -Moved the assert() statements into the lock and >>>>>>>>>>>>> lock_without_safepoint >>>>>>>>>>>>> methods. >>>>>>>>>>>>> -Changed Monitor::SafepointAllowed to >>>>>>>>>>>>> Monitor::SafepointCheckRequired >>>>>>>>>>>>> -Changed the Monitor::SafepointCheckRequired values for >>>>>>>>>>>>> several locks >>>>>>>>>>>>> which were locked outside of a MutexLockerEx (some were >>>>>>>>>>>>> locked with >>>>>>>>>>>>> MutexLocker, some were locked were locked without any >>>>>>>>>>>>> MutexLocker* ) >>>>>>>>>>>>> >>>>>>>>>>>>> New webrev location: >>>>>>>>>>>>> http://cr.openjdk.java.net/~coleenp/8047290/ >>>>>>>>>>>> >>>>>>>>>>>> Generally this is all okay - a few style and other nits below. >>>>>>>>>>>> >>>>>>>>>>>> However you missed adding an assert in Monitor::wait to >>>>>>>>>>>> check if the >>>>>>>>>>>> no_safepoint_check flag was being used correctly for the >>>>>>>>>>>> current >>>>>>>>>>>> monitor. >>>>>>>>>>>> >>>>>>>>>>>> Specific comments: >>>>>>>>>>>> >>>>>>>>>>>> src/share/vm/runtime/mutex.hpp >>>>>>>>>>>> >>>>>>>>>>>> This comment is no longer accurate with the moved check >>>>>>>>>>>> location: >>>>>>>>>>>> >>>>>>>>>>>> + // MutexLockerEx checks these flags when acquiring a lock >>>>>>>>>>>> + // to ensure consistent checking for each lock. >>>>>>>>>>>> >>>>>>>>>>>> The same goes for other references to MutexLockerEx in the >>>>>>>>>>>> enum >>>>>>>>>>>> description. >>>>>>>>>>>> >>>>>>>>>>>> Also copyright year needs updating. >>>>>>>>>>>> >>>>>>>>>>>> --- >>>>>>>>>>>> >>>>>>>>>>>> src/share/vm/runtime/mutex.cpp >>>>>>>>>>>> >>>>>>>>>>>> 898 //Ensure >>>>>>>>>>>> 961 //Ensure >>>>>>>>>>>> >>>>>>>>>>>> Space needed after // >>>>>>>>>>>> >>>>>>>>>>>> --- >>>>>>>>>>>> >>>>>>>>>>>> src/share/vm/runtime/mutexLocker.cpp >>>>>>>>>>>> >>>>>>>>>>>> + var = new type(Mutex::pri, #var, >>>>>>>>>>>> vm_block,safepoint_check_allowed); \ >>>>>>>>>>>> >>>>>>>>>>>> space needed after comma in k,s >>>>>>>>>>>> >>>>>>>>>>>> --- >>>>>>>>>>>> >>>>>>>>>>>> src/share/vm/runtime/mutexLocker.hpp >>>>>>>>>>>> >>>>>>>>>>>> Whitespace only changes - looks like leftovers from removed >>>>>>>>>>>> edits. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Additional testing: >>>>>>>>>>>>> jtreg ./jdk/test/java/lang/invoke >>>>>>>>>>>>> jtreg jfr tests >>>>>>>>>>>>> >>>>>>>>>>>>> Here is a list of ALL of the "sometimes" locks: >>>>>>>>>>>>> >>>>>>>>>>>>> "WorkGroup monitor" share/vm/utilities/workgroup.cpp >>>>>>>>>>>>> "SLTMonitor" >>>>>>>>>>>>> share/vm/gc_implementation/shared/concurrentGCThread.cpp >>>>>>>>>>>>> "CompactibleFreeListSpace._lock" >>>>>>>>>>>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> "freelist par lock" >>>>>>>>>>>>> share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> "SR_lock" share/vm/runtime/thread.cpp >>>>>>>>>>>>> >>>>>>>>>>>>> The remaining "sometimes" locks can be found in >>>>>>>>>>>>> share/vm/runtime/mutexLocker.cpp: >>>>>>>>>>>>> >>>>>>>>>>>>> ParGCRareEvent_lock >>>>>>>>>>>>> Safepoint_lock >>>>>>>>>>>>> Threads_lock >>>>>>>>>>>>> VMOperationQueue_lock >>>>>>>>>>>>> VMOperationRequest_lock >>>>>>>>>>>>> Terminator_lock >>>>>>>>>>>>> Heap_lock >>>>>>>>>>>>> Compile_lock >>>>>>>>>>>>> PeriodicTask_lock >>>>>>>>>>>>> JfrStacktrace_lock >>>>>>>>>>>>> >>>>>>>>>>>>> I have not checked the validity of the "sometimes" locks, >>>>>>>>>>>>> and I >>>>>>>>>>>>> believe >>>>>>>>>>>>> that this should be a different project. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks for your help! >>>>>>>>>>>>> Max Ockner >>>>>>>>>>>>> On 10/15/2014 8:54 PM, David Holmes wrote: >>>>>>>>>>>>>> Hi Max, >>>>>>>>>>>>>> >>>>>>>>>>>>>> This is looking good. >>>>>>>>>>>>>> >>>>>>>>>>>>>> A few high-level initial comments: >>>>>>>>>>>>>> >>>>>>>>>>>>>> I think SafepointAllowed should be SafepointCheckNeeded >>>>>>>>>>>>>> >>>>>>>>>>>>>> Why are the checks in MutexLocker when the state is >>>>>>>>>>>>>> maintained in the >>>>>>>>>>>>>> mutex itself and the mutex/monitor has >>>>>>>>>>>>>> lock_without_safepoint, and >>>>>>>>>>>>>> wait() ? I would have expected >>>>>>>>>>>>>> to see the >>>>>>>>>>>>>> check in the mutex/monitor methods. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Checking consistent usage of the _no_safepoint_check_flag >>>>>>>>>>>>>> is good. >>>>>>>>>>>>>> But >>>>>>>>>>>>>> another part of this is that a monitor/mutex that never >>>>>>>>>>>>>> checks for >>>>>>>>>>>>>> safepoints should never be held when a thread blocks at a >>>>>>>>>>>>>> safepoint - >>>>>>>>>>>>>> is there some way to easily check that? I was surprised >>>>>>>>>>>>>> how many >>>>>>>>>>>>>> locks >>>>>>>>>>>>>> are actually not checking for safepoints. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Did you find any cases where the mutex/monitor was being >>>>>>>>>>>>>> used >>>>>>>>>>>>>> inconsistently and incorrectly? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Did you analyse the "sometimes" cases to see if they were >>>>>>>>>>>>>> safe? >>>>>>>>>>>>>> (Aside: just for fun check out what happens if you lock the >>>>>>>>>>>>>> Threads_lock with a safepoint check and a safepoint has been >>>>>>>>>>>>>> requested >>>>>>>>>>>>>> :) ). >>>>>>>>>>>>>> >>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>> David >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 16/10/2014 4:04 AM, Max Ockner wrote: >>>>>>>>>>>>>>> Hi all, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I am a new member of the Hotspot runtime team in >>>>>>>>>>>>>>> Burlington, MA. >>>>>>>>>>>>>>> Please review my first fix related to safepoint checking. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Summary: MutexLockerEx can either acquire a lock with or >>>>>>>>>>>>>>> without a >>>>>>>>>>>>>>> safepoint check. >>>>>>>>>>>>>>> In some cases, a particular lock must either safepoint >>>>>>>>>>>>>>> check >>>>>>>>>>>>>>> always or >>>>>>>>>>>>>>> never to avoid deadlocking. >>>>>>>>>>>>>>> Some other locks have semantics which allow them to >>>>>>>>>>>>>>> avoid deadlocks >>>>>>>>>>>>>>> despite having a safepoint check only some of the time. >>>>>>>>>>>>>>> All locks that are OK having inconsistent safepoint >>>>>>>>>>>>>>> checks have been >>>>>>>>>>>>>>> marked. All locks that should never safepoint check and >>>>>>>>>>>>>>> all locks >>>>>>>>>>>>>>> that >>>>>>>>>>>>>>> should always safepoint check have also been marked. >>>>>>>>>>>>>>> When a MutexLockerEx acquires a lock with or without a >>>>>>>>>>>>>>> safepoint >>>>>>>>>>>>>>> check, >>>>>>>>>>>>>>> the lock's safepointAllowed marker is checked to ensure >>>>>>>>>>>>>>> consistent >>>>>>>>>>>>>>> safepoint checking. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Webrev: >>>>>>>>>>>>>>> http://oklahoma.us.oracle.com/~mockner/webrev/8047290/ >>>>>>>>>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8047290 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Tested with: >>>>>>>>>>>>>>> jprt "-testset hotspot" >>>>>>>>>>>>>>> jtreg hotspot >>>>>>>>>>>>>>> vm.quick.testlist >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Whitebox tests: >>>>>>>>>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency1.java: >>>>>>>>>>>>>>> Test >>>>>>>>>>>>>>> expects Assert ("This lock should always have a >>>>>>>>>>>>>>> safepoint check") >>>>>>>>>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency2.java: >>>>>>>>>>>>>>> Test >>>>>>>>>>>>>>> expects Assert ("This lock should never have a safepoint >>>>>>>>>>>>>>> check") >>>>>>>>>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency3.java: >>>>>>>>>>>>>>> code >>>>>>>>>>>>>>> should not assert. (Lock is properly acquired with no >>>>>>>>>>>>>>> safepoint >>>>>>>>>>>>>>> check) >>>>>>>>>>>>>>> test/runtime/Safepoint/AssertSafepointCheckConsistency4.java: >>>>>>>>>>>>>>> code >>>>>>>>>>>>>>> should not assert. (Lock is properly acquired with >>>>>>>>>>>>>>> safepoint check) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>> Max >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >> >> > From volker.simonis at gmail.com Tue Feb 3 17:09:53 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 3 Feb 2015 18:09:53 +0100 Subject: build failure in perfMemory_solaris.cpp? In-Reply-To: <54C2E812.7060106@oracle.com> References: <54C196EF.3090504@oracle.com> <54C1CBE1.7070505@oracle.com> <54C28DF4.6070902@oracle.com> <54C29260.1070105@oracle.com> <54C2C61D.7060900@oracle.com> <54C2E812.7060106@oracle.com> Message-ID: Hi, is somebody working on this issue? It's really annoying that is is not possible to build on plain Solaris 11 system any more. Regards, Volker On Sat, Jan 24, 2015 at 1:32 AM, David Holmes wrote: > The Solaris problem doesn't appear when using our S10u6 devkits so wasn't > noticed internally. It isn't clear exactly when Solaris decided to switch > from SVR4 definition to POSIX definition. Not sure if we want ugly ifdefs or > wait until our official compiler set encounters the problem. > > Can't comment on the AIX situation. > > David > > > On 24/01/2015 8:07 AM, Alejandro E Murillo wrote: >> >> >> by the timing when this started to happen, I believe >> this was caused by the CPU changes integrated into jdk9/dev >> on Wednesday (they didn't come through jdk9/hs). >> I went to check those changesets and this looks like the prime suspect: >> >> Changeset: c656c7540cb1 >> Author: gthornbr >> Date: 2014-11-17 15:51 -0500 >> URL:http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c656c7540cb1 >> >> 8050807: Better performing performance data handling >> Reviewed-by: dcubed, pnauman, ctornqvi, dholmes, mschoene >> Contributed-by:gerald.thornbrugh at oracle.com >> >> ! src/os/bsd/vm/perfMemory_bsd.cpp >> ! src/os/linux/vm/perfMemory_linux.cpp >> ! src/os/solaris/vm/perfMemory_solaris.cpp >> ! src/share/vm/utilities/vmError.cpp >> >> >> Jerry, I'm assigning the bug to you. Check it out and reassign if needed >> >> Alejandro >> >> On 1/23/2015 11:26 AM, Anthony Scarpino wrote: >>> >>> I created one: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8071501 >>> >>> Tony >>> >>> On 01/23/2015 10:07 AM, Bradford Wetmore wrote: >>>> >>>> Is there a bug id yet? I haven't seen one showing up in a quick search >>>> for dd_fd or perfMemory_solaris.cpp. >>>> >>>> For the record, I'm on what I think is the required platform/compilers: >>>> >>>> % uname -a >>>> SunOS sca00bkv 5.11 11.1 sun4v sparc sun4v >>>> >>>> % more /etc/release >>>> Oracle Solaris 11.1 SPARC >>>> Copyright (c) 1983, 2013, Oracle and/or its affiliates. All rights >>>> reserved. >>>> Assembled 06 November 2013 >>>> >>>> % grep BUILD_CC out.txt >>>> BUILD_CC:= /java/devtools/sparc/SUNWspro/SS12u3/bin/cc >>>> >>>> Brad >>>> >>>> >>>> >>>> On 1/23/2015 8:32 AM, Volker Simonis wrote: >>>>> >>>>> Hi, >>>>> >>>>> we can see the same in our nightly OpenJDK 8/9 builds >>>>> (http://cr.openjdk.java.net/~simonis/ppc-aix-port/) and would be >>>>> interested in a solution as well. >>>>> >>>>> Thanks, >>>>> Volker >>>>> >>>>> On Fri, Jan 23, 2015 at 5:19 AM, David Holmes >>>>> wrote: >>>>>> >>>>>> Hi Anthony, >>>>>> >>>>>> >>>>>> On 23/01/2015 10:33 AM, Anthony Scarpino wrote: >>>>>>> >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I just pulled the jdk9/dev gate today and hit a build failure on >>>>>>> SPARC >>>>>>> Solaris 11.1 when compiling perfMemory_solaris.cpp in hotspot. I'm >>>>>>> using SS12u3 compilers. Anyone else see a similar error or know what >>>>>>> might be going wrong? >>>>>>> >>>>>>> ...hotspot/src/os/solaris/vm/perfMemory_solaris.cpp", line 337: >>>>>>> Error: >>>>>>> dd_fd is not a member of DIR. >>>>>>> ...hotspot/src/os/solaris/vm/perfMemory_solaris.cpp", line 369: >>>>>>> Error: >>>>>>> dd_fd is not a member of DIR." >>>>>>> gmake[8]: *** [perfMemory_solaris.o] Error 2 >>>>>> >>>>>> >>>>>> >>>>>> This code was brought in via the recent CPU integration of bug >>>>>> 8050807. (Hi >>>>>> Jerry! - cc'd) >>>>>> >>>>>> It looks like Solaris has two potential definitions of DIR: >>>>>> >>>>>> #if defined(__USE_LEGACY_PROTOTYPES__) >>>>>> /* traditional SVR4 definition */ >>>>>> typedef struct { >>>>>> int dd_fd; /* file descriptor */ >>>>>> int dd_loc; /* offset in block */ >>>>>> int dd_size; /* amount of valid data */ >>>>>> char *dd_buf; /* directory block */ >>>>>> } DIR; /* stream data from opendir() */ >>>>>> #else >>>>>> /* default definition (POSIX conformant) */ >>>>>> typedef struct { >>>>>> int d_fd; /* file descriptor */ >>>>>> int d_loc; /* offset in block */ >>>>>> int d_size; /* amount of valid data */ >>>>>> char *d_buf; /* directory block */ >>>>>> } DIR; /* stream data from opendir() */ >>>>>> #endif /* __USE_LEGACY_PROTOTYPES__ */ >>>>>> >>>>>> I can't see what controls __USE_LEGACY_PROTOTYPES__ but presumably >>>>>> either >>>>>> something in Solaris 11.1, or something in SS12u3 is causing this >>>>>> difference. >>>>>> >>>>>> David >>>>>> >>>>>>> thanks >>>>>>> >>>>>>> Tony >>> >>> >> > From vladimir.kozlov at oracle.com Tue Feb 3 17:20:52 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 03 Feb 2015 09:20:52 -0800 Subject: RFR (S): 8071996: split_if accesses NULL region of ConstraintCast In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CF90E6A@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CF8A11B@DEWDFEMB12A.global.corp.sap> <54D0035E.7090907@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF90E6A@DEWDFEMB12A.global.corp.sap> Message-ID: <54D10374.6060005@oracle.com> Okay. I will push it. Thanks, Vladimir On 2/3/15 1:38 AM, Lindenmaier, Goetz wrote: > Hi Vladimir, > > thanks for looking at this! > > I updated the comment: > // If the cast is derived from data flow edges, it may not have a control. > // If so, it should be save to split. But follow-up code can not deal with > // this (l. 359). So skip. > And uploaded a new webrev. > http://cr.openjdk.java.net/~goetz/webrevs/8071996-fixSplitIf/webrev.02/ > > Best regards, > Goetz. > > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov > Sent: Dienstag, 3. Februar 2015 00:08 > To: hotspot-dev at openjdk.java.net > Subject: Re: RFR (S): 8071996: split_if accesses NULL region of ConstraintCast > > Hi, Goetz > > The fix is good but the comment is slightly off. It is not "region > edge", it is "control edge". In current case it could be IfTrue or > IfFalse projection nodes which points to If node which we compare. > > Also this control edge is required: > > 359 } else if( v->is_ConstraintCast() ) { > 360 proj = v->in(0); // Controlling projection > 361 } else { > 362 assert( 0, "do not know how to handle this guy" ); > 363 } > 364 > 365 Node *proj_path_data, *proj_path_ctrl; > 366 if( proj->Opcode() == Op_IfTrue ) { > > Thanks, > Vladimir > > On 2/1/15 11:22 PM, Lindenmaier, Goetz wrote: >> Hi, >> >> I fixed a small bug in the C2 compiler. >> It appeared in our s390/zArch port running hs25.31 with jdk6 when executing >> jvm2008/compiler.compiler. >> >> Split_if encounters a ConstraintCast without region edge, which is a valid pattern. >> But it reads the region edge unconditionally, thus failing. >> >> Please review this change. I please need a sponsor. >> http://cr.openjdk.java.net/~goetz/webrevs/8071996-fixSplitIf/webrev.01/ >> >> Best regards, >> Goetz. >> >> From vladimir.kozlov at oracle.com Tue Feb 3 18:58:59 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 03 Feb 2015 10:58:59 -0800 Subject: [8u] backport RFR (XS) 8071534: assert(!failing()) failed: Must not have pending failure. Reason is: out of memory Message-ID: <54D11A73.3000708@oracle.com> 8u60 backport request. Changes were pushed into jdk9 last week, no problems were found since then. Changes are applied to 8u cleanly. https://bugs.openjdk.java.net/browse/JDK-8071534 http://cr.openjdk.java.net/~kvn/8071534/webrev jdk9 changeset: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/25454f0d37d3 Thanks Vladimir From vladimir.kozlov at oracle.com Tue Feb 3 18:59:29 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 03 Feb 2015 10:59:29 -0800 Subject: [8u] backport 8068013: [TESTBUG] Aix support in hotspot jtreg tests In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CF90E7D@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CF71269@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CF90E7D@DEWDFEMB12A.global.corp.sap> Message-ID: <54D11A91.1000405@oracle.com> In JPRT queue. Regards, Vladimir On 2/3/15 1:41 AM, Lindenmaier, Goetz wrote: > Hi, > > any comments on this? Could somebody please volunteer to sponsor? > > Thanks, > Goetz. > > From: Lindenmaier, Goetz > Sent: Donnerstag, 22. Januar 2015 10:25 > To: hotspot-dev at openjdk.java.net > Subject: [8u] backport 8068013: [TESTBUG] Aix support in hotspot jtreg tests > > Hi, > > I would like to backport this change. > It basically makes the jtreg test infrastructure aware of aix. This fixes a lot of > the jtreg tests. > > The change from 9 applied cleanly with some obvious exceptions: > - The copyright adaption didn't merge in > * test/runtime/6888954/vmerrors.sh > * test/test_env.sh > * test/testlibrary/com/oracle/java/testlibrary/Platform.java > - Changes in files not available in 8: > * test/serviceability/dcmd/DynLibDcmdTest.java: Test does not > * test/testlibrary_tests/TestMutuallyExclusivePlatformPredicates.java > > The webrev applying to 8: > http://cr.openjdk.java.net/~goetz/webrevs/8068013-jtregAix/webrev.02-jdk8/ > The original webrev > http://cr.openjdk.java.net/~goetz/webrevs/8068013-jtregAix/webrev-02/ > The incremental patch: > http://cr.openjdk.java.net/~goetz/webrevs/8068013-jtregAix/webrev.02-jdk8/incremental_diff.patch > > I please need a sponsor. > > Best regards, > Goetz. > From igor.veresov at oracle.com Tue Feb 3 22:07:52 2015 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 3 Feb 2015 14:07:52 -0800 Subject: [8u] backport RFR (XS) 8071534: assert(!failing()) failed: Must not have pending failure. Reason is: out of memory In-Reply-To: <54D11A73.3000708@oracle.com> References: <54D11A73.3000708@oracle.com> Message-ID: Good. igor > On Feb 3, 2015, at 10:58 AM, Vladimir Kozlov wrote: > > 8u60 backport request. Changes were pushed into jdk9 last week, no problems were found since then. Changes are applied to 8u cleanly. > > https://bugs.openjdk.java.net/browse/JDK-8071534 > > http://cr.openjdk.java.net/~kvn/8071534/webrev > > jdk9 changeset: > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/25454f0d37d3 > > Thanks > Vladimir From vladimir.kozlov at oracle.com Tue Feb 3 22:22:40 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 03 Feb 2015 14:22:40 -0800 Subject: [8u] backport RFR (XS) 8071534: assert(!failing()) failed: Must not have pending failure. Reason is: out of memory In-Reply-To: References: <54D11A73.3000708@oracle.com> Message-ID: <54D14A30.9070405@oracle.com> Thank you, Igor Vladimir On 2/3/15 2:07 PM, Igor Veresov wrote: > Good. > > igor > >> On Feb 3, 2015, at 10:58 AM, Vladimir Kozlov wrote: >> >> 8u60 backport request. Changes were pushed into jdk9 last week, no problems were found since then. Changes are applied to 8u cleanly. >> >> https://bugs.openjdk.java.net/browse/JDK-8071534 >> >> http://cr.openjdk.java.net/~kvn/8071534/webrev >> >> jdk9 changeset: >> http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/25454f0d37d3 >> >> Thanks >> Vladimir > From david.holmes at oracle.com Wed Feb 4 01:35:39 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 04 Feb 2015 11:35:39 +1000 Subject: build failure in perfMemory_solaris.cpp? In-Reply-To: References: <54C196EF.3090504@oracle.com> <54C1CBE1.7070505@oracle.com> <54C28DF4.6070902@oracle.com> <54C29260.1070105@oracle.com> <54C2C61D.7060900@oracle.com> <54C2E812.7060106@oracle.com> Message-ID: <54D1776B.1060403@oracle.com> Hi Volker, On 4/02/2015 3:09 AM, Volker Simonis wrote: > Hi, > > is somebody working on this issue? It is assigned to Gerald but I don't know what his current priorities are. Also I hope we're trying to figure out whether the best way to fix this is to change the code or change the build flags - but that needs info from the Studio compiler folk. David > It's really annoying that is is not possible to build on plain Solaris > 11 system any more. > > Regards, > Volker > > > On Sat, Jan 24, 2015 at 1:32 AM, David Holmes wrote: >> The Solaris problem doesn't appear when using our S10u6 devkits so wasn't >> noticed internally. It isn't clear exactly when Solaris decided to switch >> from SVR4 definition to POSIX definition. Not sure if we want ugly ifdefs or >> wait until our official compiler set encounters the problem. >> >> Can't comment on the AIX situation. >> >> David >> >> >> On 24/01/2015 8:07 AM, Alejandro E Murillo wrote: >>> >>> >>> by the timing when this started to happen, I believe >>> this was caused by the CPU changes integrated into jdk9/dev >>> on Wednesday (they didn't come through jdk9/hs). >>> I went to check those changesets and this looks like the prime suspect: >>> >>> Changeset: c656c7540cb1 >>> Author: gthornbr >>> Date: 2014-11-17 15:51 -0500 >>> URL:http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c656c7540cb1 >>> >>> 8050807: Better performing performance data handling >>> Reviewed-by: dcubed, pnauman, ctornqvi, dholmes, mschoene >>> Contributed-by:gerald.thornbrugh at oracle.com >>> >>> ! src/os/bsd/vm/perfMemory_bsd.cpp >>> ! src/os/linux/vm/perfMemory_linux.cpp >>> ! src/os/solaris/vm/perfMemory_solaris.cpp >>> ! src/share/vm/utilities/vmError.cpp >>> >>> >>> Jerry, I'm assigning the bug to you. Check it out and reassign if needed >>> >>> Alejandro >>> >>> On 1/23/2015 11:26 AM, Anthony Scarpino wrote: >>>> >>>> I created one: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8071501 >>>> >>>> Tony >>>> >>>> On 01/23/2015 10:07 AM, Bradford Wetmore wrote: >>>>> >>>>> Is there a bug id yet? I haven't seen one showing up in a quick search >>>>> for dd_fd or perfMemory_solaris.cpp. >>>>> >>>>> For the record, I'm on what I think is the required platform/compilers: >>>>> >>>>> % uname -a >>>>> SunOS sca00bkv 5.11 11.1 sun4v sparc sun4v >>>>> >>>>> % more /etc/release >>>>> Oracle Solaris 11.1 SPARC >>>>> Copyright (c) 1983, 2013, Oracle and/or its affiliates. All rights >>>>> reserved. >>>>> Assembled 06 November 2013 >>>>> >>>>> % grep BUILD_CC out.txt >>>>> BUILD_CC:= /java/devtools/sparc/SUNWspro/SS12u3/bin/cc >>>>> >>>>> Brad >>>>> >>>>> >>>>> >>>>> On 1/23/2015 8:32 AM, Volker Simonis wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> we can see the same in our nightly OpenJDK 8/9 builds >>>>>> (http://cr.openjdk.java.net/~simonis/ppc-aix-port/) and would be >>>>>> interested in a solution as well. >>>>>> >>>>>> Thanks, >>>>>> Volker >>>>>> >>>>>> On Fri, Jan 23, 2015 at 5:19 AM, David Holmes >>>>>> wrote: >>>>>>> >>>>>>> Hi Anthony, >>>>>>> >>>>>>> >>>>>>> On 23/01/2015 10:33 AM, Anthony Scarpino wrote: >>>>>>>> >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I just pulled the jdk9/dev gate today and hit a build failure on >>>>>>>> SPARC >>>>>>>> Solaris 11.1 when compiling perfMemory_solaris.cpp in hotspot. I'm >>>>>>>> using SS12u3 compilers. Anyone else see a similar error or know what >>>>>>>> might be going wrong? >>>>>>>> >>>>>>>> ...hotspot/src/os/solaris/vm/perfMemory_solaris.cpp", line 337: >>>>>>>> Error: >>>>>>>> dd_fd is not a member of DIR. >>>>>>>> ...hotspot/src/os/solaris/vm/perfMemory_solaris.cpp", line 369: >>>>>>>> Error: >>>>>>>> dd_fd is not a member of DIR." >>>>>>>> gmake[8]: *** [perfMemory_solaris.o] Error 2 >>>>>>> >>>>>>> >>>>>>> >>>>>>> This code was brought in via the recent CPU integration of bug >>>>>>> 8050807. (Hi >>>>>>> Jerry! - cc'd) >>>>>>> >>>>>>> It looks like Solaris has two potential definitions of DIR: >>>>>>> >>>>>>> #if defined(__USE_LEGACY_PROTOTYPES__) >>>>>>> /* traditional SVR4 definition */ >>>>>>> typedef struct { >>>>>>> int dd_fd; /* file descriptor */ >>>>>>> int dd_loc; /* offset in block */ >>>>>>> int dd_size; /* amount of valid data */ >>>>>>> char *dd_buf; /* directory block */ >>>>>>> } DIR; /* stream data from opendir() */ >>>>>>> #else >>>>>>> /* default definition (POSIX conformant) */ >>>>>>> typedef struct { >>>>>>> int d_fd; /* file descriptor */ >>>>>>> int d_loc; /* offset in block */ >>>>>>> int d_size; /* amount of valid data */ >>>>>>> char *d_buf; /* directory block */ >>>>>>> } DIR; /* stream data from opendir() */ >>>>>>> #endif /* __USE_LEGACY_PROTOTYPES__ */ >>>>>>> >>>>>>> I can't see what controls __USE_LEGACY_PROTOTYPES__ but presumably >>>>>>> either >>>>>>> something in Solaris 11.1, or something in SS12u3 is causing this >>>>>>> difference. >>>>>>> >>>>>>> David >>>>>>> >>>>>>>> thanks >>>>>>>> >>>>>>>> Tony >>>> >>>> >>> >> From goetz.lindenmaier at sap.com Wed Feb 4 08:04:32 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 4 Feb 2015 08:04:32 +0000 Subject: [8u] backport 8068013: [TESTBUG] Aix support in hotspot jtreg tests In-Reply-To: <54D11A91.1000405@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CF71269@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CF90E7D@DEWDFEMB12A.global.corp.sap> <54D11A91.1000405@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CF9111B@DEWDFEMB12A.global.corp.sap> Hi Vladimir, thanks a lot for pushing this! Best regards, Goetz. -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov Sent: Dienstag, 3. Februar 2015 19:59 To: hotspot-dev at openjdk.java.net Subject: Re: [8u] backport 8068013: [TESTBUG] Aix support in hotspot jtreg tests In JPRT queue. Regards, Vladimir On 2/3/15 1:41 AM, Lindenmaier, Goetz wrote: > Hi, > > any comments on this? Could somebody please volunteer to sponsor? > > Thanks, > Goetz. > > From: Lindenmaier, Goetz > Sent: Donnerstag, 22. Januar 2015 10:25 > To: hotspot-dev at openjdk.java.net > Subject: [8u] backport 8068013: [TESTBUG] Aix support in hotspot jtreg tests > > Hi, > > I would like to backport this change. > It basically makes the jtreg test infrastructure aware of aix. This fixes a lot of > the jtreg tests. > > The change from 9 applied cleanly with some obvious exceptions: > - The copyright adaption didn't merge in > * test/runtime/6888954/vmerrors.sh > * test/test_env.sh > * test/testlibrary/com/oracle/java/testlibrary/Platform.java > - Changes in files not available in 8: > * test/serviceability/dcmd/DynLibDcmdTest.java: Test does not > * test/testlibrary_tests/TestMutuallyExclusivePlatformPredicates.java > > The webrev applying to 8: > http://cr.openjdk.java.net/~goetz/webrevs/8068013-jtregAix/webrev.02-jdk8/ > The original webrev > http://cr.openjdk.java.net/~goetz/webrevs/8068013-jtregAix/webrev-02/ > The incremental patch: > http://cr.openjdk.java.net/~goetz/webrevs/8068013-jtregAix/webrev.02-jdk8/incremental_diff.patch > > I please need a sponsor. > > Best regards, > Goetz. > From staffan.larsen at oracle.com Wed Feb 4 08:42:00 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 4 Feb 2015 09:42:00 +0100 Subject: RFR: 8072455 Use jtreg's requiredVersion tag in hotspot/test/TEST.ROOT Message-ID: Hotspot tests are using 4.1 b10 features (@requires) for example and we should declare this in TEST.ROOT. Small patch below. Thanks, /Staffan diff --git a/test/TEST.ROOT b/test/TEST.ROOT --- a/test/TEST.ROOT +++ b/test/TEST.ROOT @@ -31,3 +31,6 @@ groups=TEST.groups [closed/TEST.groups] requires.properties=sun.arch.data.model + +# Tests using jtreg 4.1 b10 features +requiredVersion=4.1 b10 From david.holmes at oracle.com Wed Feb 4 09:46:13 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 04 Feb 2015 19:46:13 +1000 Subject: RFR: 8072455 Use jtreg's requiredVersion tag in hotspot/test/TEST.ROOT In-Reply-To: References: Message-ID: <54D1EA65.3010308@oracle.com> On 4/02/2015 6:42 PM, Staffan Larsen wrote: > Hotspot tests are using 4.1 b10 features (@requires) for example and we should declare this in TEST.ROOT. > > Small patch below. Looks okay ... but now I'm going to have to upgrade my local copy :) David > Thanks, > /Staffan > > > diff --git a/test/TEST.ROOT b/test/TEST.ROOT > --- a/test/TEST.ROOT > +++ b/test/TEST.ROOT > @@ -31,3 +31,6 @@ > > groups=TEST.groups [closed/TEST.groups] > requires.properties=sun.arch.data.model > + > +# Tests using jtreg 4.1 b10 features > +requiredVersion=4.1 b10 > From christian.tornqvist at oracle.com Wed Feb 4 11:38:04 2015 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Wed, 4 Feb 2015 06:38:04 -0500 Subject: 8072455 Use jtreg's requiredVersion tag in hotspot/test/TEST.ROOT In-Reply-To: References: Message-ID: <06ec01d0406f$0af8f620$20eae260$@oracle.com> Looks good! Thanks, Christian -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Staffan Larsen Sent: Wednesday, February 4, 2015 3:42 AM To: hotspot-dev at openjdk.java.net Developers Subject: RFR: 8072455 Use jtreg's requiredVersion tag in hotspot/test/TEST.ROOT Hotspot tests are using 4.1 b10 features (@requires) for example and we should declare this in TEST.ROOT. Small patch below. Thanks, /Staffan diff --git a/test/TEST.ROOT b/test/TEST.ROOT --- a/test/TEST.ROOT +++ b/test/TEST.ROOT @@ -31,3 +31,6 @@ groups=TEST.groups [closed/TEST.groups] requires.properties=sun.arch.data.model + +# Tests using jtreg 4.1 b10 features +requiredVersion=4.1 b10 From goetz.lindenmaier at sap.com Wed Feb 4 11:53:18 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 4 Feb 2015 11:53:18 +0000 Subject: Test mentioned in [9] RFR(S): 8005873: JRuby test_respond_to.rb asserts with: MT-unsafe modification of inline cache Message-ID: <4295855A5C1DE049A61835A1887419CC2CF9124E@DEWDFEMB12A.global.corp.sap> Hi, we are currently seeing a problem in our VM that resembles what was discussed in 8005873. http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-May/013902.html We would like to try the test that's mentioned there with our VM, but we don't know where to find it. vm/mlvm/meth/stress/jni/nativeAndMH Is this test publicly available? Where can it be found? Thanks and best regards, Goetz. From goetz.lindenmaier at sap.com Wed Feb 4 15:55:46 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 4 Feb 2015 15:55:46 +0000 Subject: RFR(S): 8072434: 8064457: introduces performance regressions in 9-b47 Message-ID: <4295855A5C1DE049A61835A1887419CC2CF9137F@DEWDFEMB12A.global.corp.sap> Hi, There is a performance regression after my change 8064457. 30G heaps do not displace the CompressedClassSpace from the lower memory region and instead are allocated in upper regions. This webrev should fix the Problem. http://cr.openjdk.java.net/~goetz/webrevs/8072434-css/webrev.01/ I verified that it works now and ran runtime/CompressedOops jtreg tests on linuxx86_64. I'll get a comprehensive test run by tomorrow. Best regards, Goetz. From goetz.lindenmaier at sap.com Wed Feb 4 19:14:44 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 4 Feb 2015 19:14:44 +0000 Subject: RFR(XS): 8068778: [TESTBUG] CompressedClassSpaceSizeInJmapHeap.java fails if SA not available In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CF70D2F@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CF6DE04@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CF6FAFC@DEWDFEMB12A.global.corp.sap> <54B9970B.7040502@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF70D2F@DEWDFEMB12A.global.corp.sap> Message-ID: <4295855A5C1DE049A61835A1887419CC2CF92467@DEWDFEMB12A.global.corp.sap> This is obsolete, it stuck in the queue waiting moderator approval. Sorry, Goetz. -----Original Message----- From: serviceability-dev [mailto:serviceability-dev-bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz Sent: Wednesday, January 21, 2015 11:40 AM To: hotspot-dev at openjdk.java.net; serviceability-dev Subject: RE: RFR(XS): 8068778: [TESTBUG] CompressedClassSpaceSizeInJmapHeap.java fails if SA not available Hi, could please somebody from servicability sponsor this tiny change? Thanks, Goetz. -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Coleen Phillimore Sent: Freitag, 16. Januar 2015 23:56 To: hotspot-dev at openjdk.java.net Subject: Re: RFR(XS): 8068778: [TESTBUG] CompressedClassSpaceSizeInJmapHeap.java fails if SA not available This seems fine. Someone from the serviceability group should probably sponsor. Thanks, Coleen On 1/16/15, 6:15 AM, Lindenmaier, Goetz wrote: > Hi, > > could I please get a review for this small fix? I also please need a sponsor. > > Thanks, > Goetz. > > From: goetz.lindenmaier at sap.com > Sent: Montag, 12. Januar 2015 09:23 > To: hotspot-dev at openjdk.java.net > Subject: RFR(XS): 8068778: [TESTBUG] CompressedClassSpaceSizeInJmapHeap.java fails if SA not available > > Hi, > > This test uses SA, thus fails on platforms where that's not implemented. > I see problems on mac and aix. > Call Platform.shouldSAAttach() to check whether SA should work. > > Please review this small fix. I please need a sponsor. > http://cr.openjdk.java.net/~goetz/webrevs/8068778-jtregSA/webrev.01/ > > Best regards, > Goetz. From coleen.phillimore at oracle.com Wed Feb 4 23:13:54 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 04 Feb 2015 18:13:54 -0500 Subject: RFR(S): 8072434: 8064457: introduces performance regressions in 9-b47 In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CF9137F@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CF9137F@DEWDFEMB12A.global.corp.sap> Message-ID: <54D2A7B2.6000109@oracle.com> Hi Goetz, I was trying to figure out how we used to decide whether to put the compressed class space above the heap in preferred_heap_base(). The code was: const size_t total_size = heap_size + heap_base_min_address_aligned; // 30G + 2G ... // space so it can be decoded with no base. if (UseCompressedClassPointers && !UseSharedSpaces && OopEncodingHeapMax <= 32*G) { uint64_t class_space = align_size_up(CompressedClassSpaceSize, alignment); // 1G assert(is_size_aligned((size_t)OopEncodingHeapMax-class_space, alignment), "difference must be aligned too"); uint64_t new_top = OopEncodingHeapMax-class_space; // 32G - 1G if (total_size <= new_top) { // 32G <= 31G false, don't use the new_top. heap_top = new_top; } } // Align base to the adjusted top of the heap base = heap_top - heap_size; This is also one instance where 32*G is much easier to understand in the code than the symbolic name OopEncodingHeapMax. Anyway, your code fix looks correct. You want it to be KlassEncodingMetaspaceMax logically (I thought it should be OopEncodingHeapMax) since allocating the class space above the heap and getting zero based compressed oops, the class decoding algorithm can only shift by 3 not 5. The clause above it excludes the ObjAlignmentInBytes = shifting 5 case anyway. Thank you for fixing this! Coleen On 2/4/15, 10:55 AM, Lindenmaier, Goetz wrote: > > Hi, > > There is a performance regression after my change 8064457. > > 30G heaps do not displace the CompressedClassSpace from the lower memory > > region and instead are allocated in upper regions. > > This webrev should fix the Problem. > > http://cr.openjdk.java.net/~goetz/webrevs/8072434-css/webrev.01/ > > > I verified that it works now and ran runtime/CompressedOops jtreg > tests on linuxx86_64. > > I'll get a comprehensive test run by tomorrow. > > Best regards, > > Goetz. > From david.holmes at oracle.com Thu Feb 5 07:19:54 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 05 Feb 2015 17:19:54 +1000 Subject: Test mentioned in [9] RFR(S): 8005873: JRuby test_respond_to.rb asserts with: MT-unsafe modification of inline cache In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CF9124E@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CF9124E@DEWDFEMB12A.global.corp.sap> Message-ID: <54D3199A.5080101@oracle.com> Hi Goetz, On 4/02/2015 9:53 PM, Lindenmaier, Goetz wrote: > Hi, > > we are currently seeing a problem in our VM that resembles what was discussed in 8005873. > http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-May/013902.html > > We would like to try the test that's mentioned there with our VM, but we don't know where to find it. > vm/mlvm/meth/stress/jni/nativeAndMH > > Is this test publicly available? Where can it be found? Sorry it isn't public at this time (you shouldn't be able to see the reference to it in the bug report). David > Thanks and best regards, > Goetz. > > From aph at redhat.com Thu Feb 5 08:35:34 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 05 Feb 2015 08:35:34 +0000 Subject: JDK-6584008: jvmtiStringPrimitiveCallback should not be invoked when string value is null Message-ID: <54D32B56.6090106@redhat.com> I'd like this to be back-ported to 8. I'm not sure about the workflow. To start the process do I need to do anything more than creating a backport link in the bug entry? Thanks, Andrew. From jaroslav.bachorik at oracle.com Thu Feb 5 09:16:28 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 05 Feb 2015 10:16:28 +0100 Subject: RFR 8062303: Remove com.sun.tracing API Message-ID: <54D334EC.6050207@oracle.com> Please, review the following removal of functionality Issue : https://bugs.openjdk.java.net/browse/JDK-8062303 Webrev: http://cr.openjdk.java.net/~jbachorik/8062303/webrev.00 This API was introduced in JDK7 and immediately made proprietary/unsupported [1]. It didn't see any uptake since then. It'll not be accessible when it moves to modules. The proposed solution is to drop this proprietary API completely. Thanks, -JB- From Alan.Bateman at oracle.com Thu Feb 5 09:26:31 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 05 Feb 2015 09:26:31 +0000 Subject: RFR 8062303: Remove com.sun.tracing API In-Reply-To: <54D334EC.6050207@oracle.com> References: <54D334EC.6050207@oracle.com> Message-ID: <54D33747.1070900@oracle.com> On 05/02/2015 09:16, Jaroslav Bachorik wrote: > Please, review the following removal of functionality > > Issue : https://bugs.openjdk.java.net/browse/JDK-8062303 > Webrev: http://cr.openjdk.java.net/~jbachorik/8062303/webrev.00 > > This API was introduced in JDK7 and immediately made > proprietary/unsupported [1]. It didn't see any uptake since then. > It'll not be accessible when it moves to modules. > > The proposed solution is to drop this proprietary API completely. > This looks okay, you can also drop com/sun/tracing/BasicWithSecurityMgr.java from the exclude list (ProblemList.txt) as part of this. -Alan From david.holmes at oracle.com Thu Feb 5 09:26:57 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 05 Feb 2015 19:26:57 +1000 Subject: RFR 8062303: Remove com.sun.tracing API In-Reply-To: <54D334EC.6050207@oracle.com> References: <54D334EC.6050207@oracle.com> Message-ID: <54D33761.50906@oracle.com> On 5/02/2015 7:16 PM, Jaroslav Bachorik wrote: > Please, review the following removal of functionality > > Issue : https://bugs.openjdk.java.net/browse/JDK-8062303 > Webrev: http://cr.openjdk.java.net/~jbachorik/8062303/webrev.00 > > This API was introduced in JDK7 and immediately made > proprietary/unsupported [1]. It didn't see any uptake since then. It'll > not be accessible when it moves to modules. > > The proposed solution is to drop this proprietary API completely. The change in make/lib/Lib-jdk.runtime.gmk seems related to the JSDT removal. Is it included by mistake? Otherwise seems like a complete removal from the OpenJDK sources. Thanks, David > Thanks, > > -JB- From jaroslav.bachorik at oracle.com Thu Feb 5 09:39:36 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 05 Feb 2015 10:39:36 +0100 Subject: RFR 8062303: Remove com.sun.tracing API In-Reply-To: <54D33761.50906@oracle.com> References: <54D334EC.6050207@oracle.com> <54D33761.50906@oracle.com> Message-ID: <54D33A58.4030900@oracle.com> On 5.2.2015 10:26, David Holmes wrote: > On 5/02/2015 7:16 PM, Jaroslav Bachorik wrote: >> Please, review the following removal of functionality >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8062303 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8062303/webrev.00 >> >> This API was introduced in JDK7 and immediately made >> proprietary/unsupported [1]. It didn't see any uptake since then. It'll >> not be accessible when it moves to modules. >> >> The proposed solution is to drop this proprietary API completely. > > The change in make/lib/Lib-jdk.runtime.gmk seems related to the JSDT > removal. Is it included by mistake? No. The JSDT implementation depends on com.sun.tracing API (it implements it) and it must be removed together with the API. The request for the removal of the hotspot JSDT integration was reviewed in http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-January/016800.html -JB- > > Otherwise seems like a complete removal from the OpenJDK sources. > > Thanks, > David > >> Thanks, >> >> -JB- From jaroslav.bachorik at oracle.com Thu Feb 5 09:41:49 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 05 Feb 2015 10:41:49 +0100 Subject: RFR 8062303: Remove com.sun.tracing API In-Reply-To: <54D33747.1070900@oracle.com> References: <54D334EC.6050207@oracle.com> <54D33747.1070900@oracle.com> Message-ID: <54D33ADD.9080207@oracle.com> On 5.2.2015 10:26, Alan Bateman wrote: > On 05/02/2015 09:16, Jaroslav Bachorik wrote: >> Please, review the following removal of functionality >> >> Issue : https://bugs.openjdk.java.net/browse/JDK-8062303 >> Webrev: http://cr.openjdk.java.net/~jbachorik/8062303/webrev.00 >> >> This API was introduced in JDK7 and immediately made >> proprietary/unsupported [1]. It didn't see any uptake since then. >> It'll not be accessible when it moves to modules. >> >> The proposed solution is to drop this proprietary API completely. >> > This looks okay, you can also drop > com/sun/tracing/BasicWithSecurityMgr.java from the exclude list > (ProblemList.txt) as part of this. With updated ProblemList.txt : http://cr.openjdk.java.net/~jbachorik/8062303/webrev.01 -JB- > > -Alan From david.holmes at oracle.com Thu Feb 5 09:48:01 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 05 Feb 2015 19:48:01 +1000 Subject: RFR 8062303: Remove com.sun.tracing API In-Reply-To: <54D33A58.4030900@oracle.com> References: <54D334EC.6050207@oracle.com> <54D33761.50906@oracle.com> <54D33A58.4030900@oracle.com> Message-ID: <54D33C51.8050808@oracle.com> On 5/02/2015 7:39 PM, Jaroslav Bachorik wrote: > On 5.2.2015 10:26, David Holmes wrote: >> On 5/02/2015 7:16 PM, Jaroslav Bachorik wrote: >>> Please, review the following removal of functionality >>> >>> Issue : https://bugs.openjdk.java.net/browse/JDK-8062303 >>> Webrev: http://cr.openjdk.java.net/~jbachorik/8062303/webrev.00 >>> >>> This API was introduced in JDK7 and immediately made >>> proprietary/unsupported [1]. It didn't see any uptake since then. It'll >>> not be accessible when it moves to modules. >>> >>> The proposed solution is to drop this proprietary API completely. >> >> The change in make/lib/Lib-jdk.runtime.gmk seems related to the JSDT >> removal. Is it included by mistake? > > No. The JSDT implementation depends on com.sun.tracing API (it > implements it) and it must be removed together with the API. Ah I see. In that case you seem to have overlooked the removal of: jdk/src/jdk.runtime/unix/native/libjsdt/jvm_symbols_md.c jdk/src/jdk.runtime/windows/native/libjsdt/jvm_symbols_md.c Thanks, David > The request for the removal of the hotspot JSDT integration was reviewed > in > http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-January/016800.html > > -JB- > >> >> Otherwise seems like a complete removal from the OpenJDK sources. >> >> Thanks, >> David >> >>> Thanks, >>> >>> -JB- > From aph at redhat.com Thu Feb 5 10:32:25 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 05 Feb 2015 10:32:25 +0000 Subject: RFR: 8072483: AARCH64: aarch64.ad uses the wrong operand class for some operations Message-ID: <54D346B9.1070000@redhat.com> In a few instruction patterns we're using iReg (all registers) rather than iRegNoSp (all general registers) for an output. The difference between these operand classes is the set of fixed registers such as the frame pointer and the thread pointer. This causes C2's register allocator to try to use these registers, and predictably bad stuff happens. It's hard to find a reproducer for this bug because it only triggers at times of very high register pressure and the code generated may not even be visibly wrong. However, it sometimes causes assertion failures. http://cr.openjdk.java.net/~aph/aarch64-8072483/ Andrew. From adinn at redhat.com Thu Feb 5 12:56:32 2015 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 05 Feb 2015 12:56:32 +0000 Subject: RFR: 8072483: AARCH64: aarch64.ad uses the wrong operand class for some operations In-Reply-To: <54D346B9.1070000@redhat.com> References: <54D346B9.1070000@redhat.com> Message-ID: <54D36880.1090401@redhat.com> On 05/02/15 10:32, Andrew Haley wrote: > In a few instruction patterns we're using iReg (all registers) rather > than iRegNoSp (all general registers) for an output. The difference > between these operand classes is the set of fixed registers such as > the frame pointer and the thread pointer. This causes C2's register > allocator to try to use these registers, and predictably bad stuff > happens. > > It's hard to find a reproducer for this bug because it only triggers > at times of very high register pressure and the code generated may not > even be visibly wrong. However, it sometimes causes assertion > failures. > > http://cr.openjdk.java.net/~aph/aarch64-8072483/ Firstly, I'll take the blame for the NoSp suffix -- it was meant to indicate 'no special' rather than 'no stack pointer'. Second, I'm not a JDK9 committer, let alone reviewer, but, having provided these NoSp register classes precisely to avoid the problem Andrew mentions, I can confirm that the patch is correct and necessary. regards, Andrew Dinn ----------- From daniel.daugherty at oracle.com Thu Feb 5 14:32:59 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 05 Feb 2015 07:32:59 -0700 Subject: JDK-6584008: jvmtiStringPrimitiveCallback should not be invoked when string value is null In-Reply-To: <54D32B56.6090106@redhat.com> References: <54D32B56.6090106@redhat.com> Message-ID: <54D37F1B.2050200@oracle.com> Do the backport and send a request for review/approval to hotspot-dev at openjdk.java.net. Make it clear that this is a backport for JDK8u. For straight forward backports, just one reviewer is needed to agree. You'll need a sponsor to do the JPRT job for you and when the bits push the backport bug will be automatically created by the JBS backend. Dan On 2/5/15 1:35 AM, Andrew Haley wrote: > I'd like this to be back-ported to 8. I'm not sure about the > workflow. To start the process do I need to do anything more than > creating a backport link in the bug entry? > > Thanks, > Andrew. From goetz.lindenmaier at sap.com Thu Feb 5 15:00:46 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 5 Feb 2015 15:00:46 +0000 Subject: RFR(S): 8072434: 8064457: introduces performance regressions in 9-b47 In-Reply-To: <54D2A7B2.6000109@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CF9137F@DEWDFEMB12A.global.corp.sap> <54D2A7B2.6000109@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CF926C7@DEWDFEMB12A.global.corp.sap> Hi Coleen, You are right, I missed to move that condition into the new code. I designed a test for zerobased startup with 30G I would like to add to the webrev as you proposed. I had to use WhiteBox, which took a while to get right ... I thought of these two test cases. 1.) Setting 30G plain, and 2.) setting the flags used in the benchmark. -Xmx30g -Xms30g -Xmn26g-XX:+AggressiveOpts -XX:+UseNUMA 2.) causes two problems. First it's slow as the debug build initializes the heap which walks all the memory. Second it fails on machines that don't have 30G main memory. So I have to skip it. 1.) I'm not sure whether that will work with all OSes, the OS might not return all of the theoretical available address space below 32G, even if zerobased works for medium size heaps. I will run 1.) with my tests tonight for a broader coverage, it worked on linuxx86_64 and linuxppc64 fine, and breaks with the VM without the fix. Also, all our other tests worked fine with the patch from yesterday. Best regards, Goetz. From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com] Sent: Thursday, February 05, 2015 12:14 AM To: Lindenmaier, Goetz; hotspot-dev Source Developers Subject: Re: RFR(S): 8072434: 8064457: introduces performance regressions in 9-b47 Hi Goetz, I was trying to figure out how we used to decide whether to put the compressed class space above the heap in preferred_heap_base(). The code was: const size_t total_size = heap_size + heap_base_min_address_aligned; // 30G + 2G ... // space so it can be decoded with no base. if (UseCompressedClassPointers && !UseSharedSpaces && OopEncodingHeapMax <= 32*G) { uint64_t class_space = align_size_up(CompressedClassSpaceSize, alignment); // 1G assert(is_size_aligned((size_t)OopEncodingHeapMax-class_space, alignment), "difference must be aligned too"); uint64_t new_top = OopEncodingHeapMax-class_space; // 32G - 1G if (total_size <= new_top) { // 32G <= 31G false, don't use the new_top. heap_top = new_top; } } // Align base to the adjusted top of the heap base = heap_top - heap_size; This is also one instance where 32*G is much easier to understand in the code than the symbolic name OopEncodingHeapMax. Anyway, your code fix looks correct. You want it to be KlassEncodingMetaspaceMax logically (I thought it should be OopEncodingHeapMax) since allocating the class space above the heap and getting zero based compressed oops, the class decoding algorithm can only shift by 3 not 5. The clause above it excludes the ObjAlignmentInBytes = shifting 5 case anyway. Thank you for fixing this! Coleen On 2/4/15, 10:55 AM, Lindenmaier, Goetz wrote: Hi, There is a performance regression after my change 8064457. 30G heaps do not displace the CompressedClassSpace from the lower memory region and instead are allocated in upper regions. This webrev should fix the Problem. http://cr.openjdk.java.net/~goetz/webrevs/8072434-css/webrev.01/ I verified that it works now and ran runtime/CompressedOops jtreg tests on linuxx86_64. I'll get a comprehensive test run by tomorrow. Best regards, Goetz. From jaroslav.bachorik at oracle.com Thu Feb 5 15:06:08 2015 From: jaroslav.bachorik at oracle.com (Jaroslav Bachorik) Date: Thu, 05 Feb 2015 16:06:08 +0100 Subject: RFR 8062303: Remove com.sun.tracing API In-Reply-To: <54D33C51.8050808@oracle.com> References: <54D334EC.6050207@oracle.com> <54D33761.50906@oracle.com> <54D33A58.4030900@oracle.com> <54D33C51.8050808@oracle.com> Message-ID: <54D386E0.1090507@oracle.com> On 5.2.2015 10:48, David Holmes wrote: > On 5/02/2015 7:39 PM, Jaroslav Bachorik wrote: >> On 5.2.2015 10:26, David Holmes wrote: >>> On 5/02/2015 7:16 PM, Jaroslav Bachorik wrote: >>>> Please, review the following removal of functionality >>>> >>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8062303 >>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8062303/webrev.00 >>>> >>>> This API was introduced in JDK7 and immediately made >>>> proprietary/unsupported [1]. It didn't see any uptake since then. It'll >>>> not be accessible when it moves to modules. >>>> >>>> The proposed solution is to drop this proprietary API completely. >>> >>> The change in make/lib/Lib-jdk.runtime.gmk seems related to the JSDT >>> removal. Is it included by mistake? >> >> No. The JSDT implementation depends on com.sun.tracing API (it >> implements it) and it must be removed together with the API. > > Ah I see. In that case you seem to have overlooked the removal of: > > jdk/src/jdk.runtime/unix/native/libjsdt/jvm_symbols_md.c > jdk/src/jdk.runtime/windows/native/libjsdt/jvm_symbols_md.c ... and they are gone - http://cr.openjdk.java.net/~jbachorik/8062303/webrev.02/ I re-ran the tests successfully. -JB- > > Thanks, > David > >> The request for the removal of the hotspot JSDT integration was reviewed >> in >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-January/016800.html >> >> >> -JB- >> >>> >>> Otherwise seems like a complete removal from the OpenJDK sources. >>> >>> Thanks, >>> David >>> >>>> Thanks, >>>> >>>> -JB- >> From coleen.phillimore at oracle.com Thu Feb 5 15:10:03 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 05 Feb 2015 10:10:03 -0500 Subject: RFR(S): 8072434: 8064457: introduces performance regressions in 9-b47 In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CF926C7@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CF9137F@DEWDFEMB12A.global.corp.sap> <54D2A7B2.6000109@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF926C7@DEWDFEMB12A.global.corp.sap> Message-ID: <54D387CB.5050600@oracle.com> Hi Goetz, I agree, don't add #2. If you send me the complete patch for the test, I'll run it through JPRT. Hopefully the test will "work" on all platforms, but if it doesn't you shouldn't add it after all. Thanks, Coleen On 2/5/15, 10:00 AM, Lindenmaier, Goetz wrote: > > Hi Coleen, > > You are right, I missed to move that condition into the new code. > > I designed a test for zerobased startup with 30G I would like to add to > > the webrev as you proposed. I had to use WhiteBox, which took a while > > to get right ... > > I thought of these two test cases. > > 1.) Setting 30G plain, and > > 2.) setting the flags used in the benchmark. -Xmx30g -Xms30g > -Xmn26g-XX:+AggressiveOpts -XX:+UseNUMA > > 2.) causes two problems. First it's slow as the debug build > initializes the heap which walks all > > the memory. Second it fails on machines that don't have 30G > main memory. So I have to > > skip it. > > 1.)I'm not sure whether that will work with all OSes, the OS might not > return all > > of the theoretical available address space below 32G, even if > zerobased works > > for medium size heaps. > > I will run 1.) with my tests tonight for a broader coverage, it worked > on linuxx86_64 and > > linuxppc64 fine, and breaks with the VM without the fix. > > Also, all our other tests worked fine with the patch from yesterday. > > Best regards, > > Goetz. > > *From:*Coleen Phillimore [mailto:coleen.phillimore at oracle.com] > *Sent:* Thursday, February 05, 2015 12:14 AM > *To:* Lindenmaier, Goetz; hotspot-dev Source Developers > *Subject:* Re: RFR(S): 8072434: 8064457: introduces performance > regressions in 9-b47 > > > Hi Goetz, > > I was trying to figure out how we used to decide whether to put the > compressed class space above the heap in preferred_heap_base(). The > code was: > > const size_t total_size = heap_size + > heap_base_min_address_aligned; // 30G + 2G > > ... > // space so it can be decoded with no base. > if (UseCompressedClassPointers && !UseSharedSpaces && > OopEncodingHeapMax <= 32*G) { > > uint64_t class_space = > align_size_up(CompressedClassSpaceSize, alignment); // 1G > assert(is_size_aligned((size_t)OopEncodingHeapMax-class_space, > alignment), "difference must be aligned too"); > uint64_t new_top = OopEncodingHeapMax-class_space; // > 32G - 1G > > if (total_size <= new_top) { // 32G <= 31G false, > don't use the new_top. > heap_top = new_top; > } > } > > // Align base to the adjusted top of the heap > base = heap_top - heap_size; > > > This is also one instance where 32*G is much easier to understand in > the code than the symbolic name OopEncodingHeapMax. > > Anyway, your code fix looks correct. You want it to be > KlassEncodingMetaspaceMax logically (I thought it should be > OopEncodingHeapMax) since allocating the class space above the heap > and getting zero based compressed oops, the class decoding algorithm > can only shift by 3 not 5. The clause above it excludes the > ObjAlignmentInBytes = shifting 5 case anyway. > > Thank you for fixing this! > > Coleen > > On 2/4/15, 10:55 AM, Lindenmaier, Goetz wrote: > > Hi, > > There is a performance regression after my change 8064457. > > 30G heaps do not displace the CompressedClassSpace from the lower > memory > > region and instead are allocated in upper regions. > > This webrev should fix the Problem. > > http://cr.openjdk.java.net/~goetz/webrevs/8072434-css/webrev.01/ > > > I verified that it works now and ran runtime/CompressedOops jtreg > tests on linuxx86_64. > > I'll get a comprehensive test run by tomorrow. > > Best regards, > > Goetz. > From goetz.lindenmaier at sap.com Thu Feb 5 15:40:25 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 5 Feb 2015 15:40:25 +0000 Subject: RFR(S): 8072434: 8064457: introduces performance regressions in 9-b47 In-Reply-To: <54D387CB.5050600@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CF9137F@DEWDFEMB12A.global.corp.sap> <54D2A7B2.6000109@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF926C7@DEWDFEMB12A.global.corp.sap> <54D387CB.5050600@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CF92769@DEWDFEMB12A.global.corp.sap> Hi Coleen, here you go: http://cr.openjdk.java.net/~goetz/webrevs/8072434-css/webrev.02/ Thanks for testing! Best regards, Goetz. From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com] Sent: Thursday, February 05, 2015 4:10 PM To: Lindenmaier, Goetz; 'hotspot-dev Source Developers' Subject: Re: RFR(S): 8072434: 8064457: introduces performance regressions in 9-b47 Hi Goetz, I agree, don't add #2. If you send me the complete patch for the test, I'll run it through JPRT. Hopefully the test will "work" on all platforms, but if it doesn't you shouldn't add it after all. Thanks, Coleen On 2/5/15, 10:00 AM, Lindenmaier, Goetz wrote: Hi Coleen, You are right, I missed to move that condition into the new code. I designed a test for zerobased startup with 30G I would like to add to the webrev as you proposed. I had to use WhiteBox, which took a while to get right ... I thought of these two test cases. 1.) Setting 30G plain, and 2.) setting the flags used in the benchmark. -Xmx30g -Xms30g -Xmn26g-XX:+AggressiveOpts -XX:+UseNUMA 2.) causes two problems. First it's slow as the debug build initializes the heap which walks all the memory. Second it fails on machines that don't have 30G main memory. So I have to skip it. 1.) I'm not sure whether that will work with all OSes, the OS might not return all of the theoretical available address space below 32G, even if zerobased works for medium size heaps. I will run 1.) with my tests tonight for a broader coverage, it worked on linuxx86_64 and linuxppc64 fine, and breaks with the VM without the fix. Also, all our other tests worked fine with the patch from yesterday. Best regards, Goetz. From: Coleen Phillimore [mailto:coleen.phillimore at oracle.com] Sent: Thursday, February 05, 2015 12:14 AM To: Lindenmaier, Goetz; hotspot-dev Source Developers Subject: Re: RFR(S): 8072434: 8064457: introduces performance regressions in 9-b47 Hi Goetz, I was trying to figure out how we used to decide whether to put the compressed class space above the heap in preferred_heap_base(). The code was: const size_t total_size = heap_size + heap_base_min_address_aligned; // 30G + 2G ... // space so it can be decoded with no base. if (UseCompressedClassPointers && !UseSharedSpaces && OopEncodingHeapMax <= 32*G) { uint64_t class_space = align_size_up(CompressedClassSpaceSize, alignment); // 1G assert(is_size_aligned((size_t)OopEncodingHeapMax-class_space, alignment), "difference must be aligned too"); uint64_t new_top = OopEncodingHeapMax-class_space; // 32G - 1G if (total_size <= new_top) { // 32G <= 31G false, don't use the new_top. heap_top = new_top; } } // Align base to the adjusted top of the heap base = heap_top - heap_size; This is also one instance where 32*G is much easier to understand in the code than the symbolic name OopEncodingHeapMax. Anyway, your code fix looks correct. You want it to be KlassEncodingMetaspaceMax logically (I thought it should be OopEncodingHeapMax) since allocating the class space above the heap and getting zero based compressed oops, the class decoding algorithm can only shift by 3 not 5. The clause above it excludes the ObjAlignmentInBytes = shifting 5 case anyway. Thank you for fixing this! Coleen On 2/4/15, 10:55 AM, Lindenmaier, Goetz wrote: Hi, There is a performance regression after my change 8064457. 30G heaps do not displace the CompressedClassSpace from the lower memory region and instead are allocated in upper regions. This webrev should fix the Problem. http://cr.openjdk.java.net/~goetz/webrevs/8072434-css/webrev.01/ I verified that it works now and ran runtime/CompressedOops jtreg tests on linuxx86_64. I'll get a comprehensive test run by tomorrow. Best regards, Goetz. From mandy.chung at oracle.com Thu Feb 5 16:01:46 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 05 Feb 2015 08:01:46 -0800 Subject: RFR 8062303: Remove com.sun.tracing API In-Reply-To: <54D386E0.1090507@oracle.com> References: <54D334EC.6050207@oracle.com> <54D33761.50906@oracle.com> <54D33A58.4030900@oracle.com> <54D33C51.8050808@oracle.com> <54D386E0.1090507@oracle.com> Message-ID: <54D393EA.9040005@oracle.com> On 2/5/2015 7:06 AM, Jaroslav Bachorik wrote: > > http://cr.openjdk.java.net/~jbachorik/8062303/webrev.02/ > > I re-ran the tests successfully. Looks good. thanks Mandy From staffan.larsen at oracle.com Thu Feb 5 16:20:50 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 5 Feb 2015 17:20:50 +0100 Subject: RFR 8062303: Remove com.sun.tracing API In-Reply-To: <54D386E0.1090507@oracle.com> References: <54D334EC.6050207@oracle.com> <54D33761.50906@oracle.com> <54D33A58.4030900@oracle.com> <54D33C51.8050808@oracle.com> <54D386E0.1090507@oracle.com> Message-ID: <0DB3E710-77AC-497B-BBE2-3A61E90629D2@oracle.com> Looks good! Thanks, /Staffan > On 5 feb 2015, at 16:06, Jaroslav Bachorik wrote: > > On 5.2.2015 10:48, David Holmes wrote: >> On 5/02/2015 7:39 PM, Jaroslav Bachorik wrote: >>> On 5.2.2015 10:26, David Holmes wrote: >>>> On 5/02/2015 7:16 PM, Jaroslav Bachorik wrote: >>>>> Please, review the following removal of functionality >>>>> >>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8062303 >>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8062303/webrev.00 >>>>> >>>>> This API was introduced in JDK7 and immediately made >>>>> proprietary/unsupported [1]. It didn't see any uptake since then. It'll >>>>> not be accessible when it moves to modules. >>>>> >>>>> The proposed solution is to drop this proprietary API completely. >>>> >>>> The change in make/lib/Lib-jdk.runtime.gmk seems related to the JSDT >>>> removal. Is it included by mistake? >>> >>> No. The JSDT implementation depends on com.sun.tracing API (it >>> implements it) and it must be removed together with the API. >> >> Ah I see. In that case you seem to have overlooked the removal of: >> >> jdk/src/jdk.runtime/unix/native/libjsdt/jvm_symbols_md.c >> jdk/src/jdk.runtime/windows/native/libjsdt/jvm_symbols_md.c > > ... and they are gone - http://cr.openjdk.java.net/~jbachorik/8062303/webrev.02/ > > I re-ran the tests successfully. > > -JB- > >> >> Thanks, >> David >> >>> The request for the removal of the hotspot JSDT integration was reviewed >>> in >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-January/016800.html >>> >>> >>> -JB- >>> >>>> >>>> Otherwise seems like a complete removal from the OpenJDK sources. >>>> >>>> Thanks, >>>> David >>>> >>>>> Thanks, >>>>> >>>>> -JB- From edward.nevill at linaro.org Thu Feb 5 16:39:47 2015 From: edward.nevill at linaro.org (Edward Nevill) Date: Thu, 05 Feb 2015 16:39:47 +0000 Subject: RFR: 8072483: AARCH64: aarch64.ad uses the wrong operand class for some operations In-Reply-To: <54D346B9.1070000@redhat.com> References: <54D346B9.1070000@redhat.com> Message-ID: <1423154387.6102.14.camel@mylittlepony.linaroharston> On Thu, 2015-02-05 at 10:32 +0000, Andrew Haley wrote: > http://cr.openjdk.java.net/~aph/aarch64-8072483/ > > Andrew. Hi Andrew, Thanks for this. I have applied the patch to jdk9 staging, built and tested it. It seems to fix the assertion failures. +1 from me. Ed. From aph at redhat.com Thu Feb 5 17:30:21 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 05 Feb 2015 17:30:21 +0000 Subject: RFR: Backport JDK-6584008: jvmtiStringPrimitiveCallback should not be invoked when string value is null Message-ID: <54D3A8AD.2000508@redhat.com> This is a backport request for JDK8u. The patch at http://hg.openjdk.java.net/jdk9/jdk9/hotspot/raw-rev/4a14bb075882 applies as is, requires no changes, and fixes the bug. Thanks, Andrew. From vladimir.kozlov at oracle.com Thu Feb 5 17:46:28 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 05 Feb 2015 09:46:28 -0800 Subject: RFR: 8072483: AARCH64: aarch64.ad uses the wrong operand class for some operations In-Reply-To: <1423154387.6102.14.camel@mylittlepony.linaroharston> References: <54D346B9.1070000@redhat.com> <1423154387.6102.14.camel@mylittlepony.linaroharston> Message-ID: <54D3AC74.7050201@oracle.com> Good. I will push it into stage repo. Thanks, Vladimir On 2/5/15 8:39 AM, Edward Nevill wrote: > On Thu, 2015-02-05 at 10:32 +0000, Andrew Haley wrote: > >> http://cr.openjdk.java.net/~aph/aarch64-8072483/ >> >> Andrew. > > Hi Andrew, > > Thanks for this. I have applied the patch to jdk9 staging, built and > tested it. It seems to fix the assertion failures. > > +1 from me. > > Ed. > > From david.holmes at oracle.com Thu Feb 5 20:13:10 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 06 Feb 2015 06:13:10 +1000 Subject: RFR 8062303: Remove com.sun.tracing API In-Reply-To: <54D386E0.1090507@oracle.com> References: <54D334EC.6050207@oracle.com> <54D33761.50906@oracle.com> <54D33A58.4030900@oracle.com> <54D33C51.8050808@oracle.com> <54D386E0.1090507@oracle.com> Message-ID: <54D3CED6.1060603@oracle.com> Looks good! Thanks, David On 6/02/2015 1:06 AM, Jaroslav Bachorik wrote: > On 5.2.2015 10:48, David Holmes wrote: >> On 5/02/2015 7:39 PM, Jaroslav Bachorik wrote: >>> On 5.2.2015 10:26, David Holmes wrote: >>>> On 5/02/2015 7:16 PM, Jaroslav Bachorik wrote: >>>>> Please, review the following removal of functionality >>>>> >>>>> Issue : https://bugs.openjdk.java.net/browse/JDK-8062303 >>>>> Webrev: http://cr.openjdk.java.net/~jbachorik/8062303/webrev.00 >>>>> >>>>> This API was introduced in JDK7 and immediately made >>>>> proprietary/unsupported [1]. It didn't see any uptake since then. >>>>> It'll >>>>> not be accessible when it moves to modules. >>>>> >>>>> The proposed solution is to drop this proprietary API completely. >>>> >>>> The change in make/lib/Lib-jdk.runtime.gmk seems related to the JSDT >>>> removal. Is it included by mistake? >>> >>> No. The JSDT implementation depends on com.sun.tracing API (it >>> implements it) and it must be removed together with the API. >> >> Ah I see. In that case you seem to have overlooked the removal of: >> >> jdk/src/jdk.runtime/unix/native/libjsdt/jvm_symbols_md.c >> jdk/src/jdk.runtime/windows/native/libjsdt/jvm_symbols_md.c > > ... and they are gone - > http://cr.openjdk.java.net/~jbachorik/8062303/webrev.02/ > > I re-ran the tests successfully. > > -JB- > >> >> Thanks, >> David >> >>> The request for the removal of the hotspot JSDT integration was reviewed >>> in >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-January/016800.html >>> >>> >>> >>> -JB- >>> >>>> >>>> Otherwise seems like a complete removal from the OpenJDK sources. >>>> >>>> Thanks, >>>> David >>>> >>>>> Thanks, >>>>> >>>>> -JB- >>> > From serguei.spitsyn at oracle.com Thu Feb 5 20:58:44 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 05 Feb 2015 12:58:44 -0800 Subject: RFR: Backport JDK-6584008: jvmtiStringPrimitiveCallback should not be invoked when string value is null In-Reply-To: <54D3A8AD.2000508@redhat.com> References: <54D3A8AD.2000508@redhat.com> Message-ID: <54D3D984.4060609@oracle.com> Hi Andrew, This is for 8u60, right? Looks good. I can sponsor the JPRT push once it gets approved. Thanks, Serguei On 2/5/15 9:30 AM, Andrew Haley wrote: > This is a backport request for JDK8u. > > The patch at > > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/raw-rev/4a14bb075882 > > applies as is, requires no changes, and fixes the bug. > > Thanks, > Andrew. From coleen.phillimore at oracle.com Thu Feb 5 22:16:38 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 05 Feb 2015 17:16:38 -0500 Subject: RFR(S): 8072434: 8064457: introduces performance regressions in 9-b47 In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CF926C7@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CF9137F@DEWDFEMB12A.global.corp.sap> <54D2A7B2.6000109@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF926C7@DEWDFEMB12A.global.corp.sap> Message-ID: <54D3EBC6.5020009@oracle.com> Your test #1 doesn't work on all machines either. I don't think we can add tests that assume memory allocation locations, so we shouldn't add your new test. It's been verified manually. Coleen On 2/5/15, 10:00 AM, Lindenmaier, Goetz wrote: > > Hi Coleen, > > You are right, I missed to move that condition into the new code. > > I designed a test for zerobased startup with 30G I would like to add to > > the webrev as you proposed. I had to use WhiteBox, which took a while > > to get right ... > > I thought of these two test cases. > > 1.) Setting 30G plain, and > > 2.) setting the flags used in the benchmark. -Xmx30g -Xms30g > -Xmn26g-XX:+AggressiveOpts -XX:+UseNUMA > > 2.) causes two problems. First it's slow as the debug build > initializes the heap which walks all > > the memory. Second it fails on machines that don't have 30G > main memory. So I have to > > skip it. > > 1.)I'm not sure whether that will work with all OSes, the OS might not > return all > > of the theoretical available address space below 32G, even if > zerobased works > > for medium size heaps. > > I will run 1.) with my tests tonight for a broader coverage, it worked > on linuxx86_64 and > > linuxppc64 fine, and breaks with the VM without the fix. > > Also, all our other tests worked fine with the patch from yesterday. > > Best regards, > > Goetz. > > *From:*Coleen Phillimore [mailto:coleen.phillimore at oracle.com] > *Sent:* Thursday, February 05, 2015 12:14 AM > *To:* Lindenmaier, Goetz; hotspot-dev Source Developers > *Subject:* Re: RFR(S): 8072434: 8064457: introduces performance > regressions in 9-b47 > > > Hi Goetz, > > I was trying to figure out how we used to decide whether to put the > compressed class space above the heap in preferred_heap_base(). The > code was: > > const size_t total_size = heap_size + > heap_base_min_address_aligned; // 30G + 2G > > ... > // space so it can be decoded with no base. > if (UseCompressedClassPointers && !UseSharedSpaces && > OopEncodingHeapMax <= 32*G) { > > uint64_t class_space = > align_size_up(CompressedClassSpaceSize, alignment); // 1G > assert(is_size_aligned((size_t)OopEncodingHeapMax-class_space, > alignment), "difference must be aligned too"); > uint64_t new_top = OopEncodingHeapMax-class_space; // > 32G - 1G > > if (total_size <= new_top) { // 32G <= 31G false, > don't use the new_top. > heap_top = new_top; > } > } > > // Align base to the adjusted top of the heap > base = heap_top - heap_size; > > > This is also one instance where 32*G is much easier to understand in > the code than the symbolic name OopEncodingHeapMax. > > Anyway, your code fix looks correct. You want it to be > KlassEncodingMetaspaceMax logically (I thought it should be > OopEncodingHeapMax) since allocating the class space above the heap > and getting zero based compressed oops, the class decoding algorithm > can only shift by 3 not 5. The clause above it excludes the > ObjAlignmentInBytes = shifting 5 case anyway. > > Thank you for fixing this! > > Coleen > > On 2/4/15, 10:55 AM, Lindenmaier, Goetz wrote: > > Hi, > > There is a performance regression after my change 8064457. > > 30G heaps do not displace the CompressedClassSpace from the lower > memory > > region and instead are allocated in upper regions. > > This webrev should fix the Problem. > > http://cr.openjdk.java.net/~goetz/webrevs/8072434-css/webrev.01/ > > > I verified that it works now and ran runtime/CompressedOops jtreg > tests on linuxx86_64. > > I'll get a comprehensive test run by tomorrow. > > Best regards, > > Goetz. > From coleen.phillimore at oracle.com Thu Feb 5 22:22:12 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 05 Feb 2015 17:22:12 -0500 Subject: RFR(S): 8072434: 8064457: introduces performance regressions in 9-b47 In-Reply-To: <54D3EBC6.5020009@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CF9137F@DEWDFEMB12A.global.corp.sap> <54D2A7B2.6000109@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF926C7@DEWDFEMB12A.global.corp.sap> <54D3EBC6.5020009@oracle.com> Message-ID: <54D3ED14.9070506@oracle.com> On 2/5/15, 5:16 PM, Coleen Phillimore wrote: > > Your test #1 doesn't work on all machines either. I don't think we > can add tests that assume memory allocation locations, so we shouldn't > add your new test. It's been verified manually. Forgot to mention it didn't pass on windows x64 maybe because of ASLR. Coleen > > Coleen > > On 2/5/15, 10:00 AM, Lindenmaier, Goetz wrote: >> >> Hi Coleen, >> >> You are right, I missed to move that condition into the new code. >> >> I designed a test for zerobased startup with 30G I would like to add to >> >> the webrev as you proposed. I had to use WhiteBox, which took a while >> >> to get right ... >> >> I thought of these two test cases. >> >> 1.) Setting 30G plain, and >> >> 2.) setting the flags used in the benchmark. -Xmx30g -Xms30g >> -Xmn26g-XX:+AggressiveOpts -XX:+UseNUMA >> >> 2.) causes two problems. First it's slow as the debug build >> initializes the heap which walks all >> >> the memory. Second it fails on machines that don't have 30G >> main memory. So I have to >> >> skip it. >> >> 1.)I'm not sure whether that will work with all OSes, the OS might >> not return all >> >> of the theoretical available address space below 32G, even if >> zerobased works >> >> for medium size heaps. >> >> I will run 1.) with my tests tonight for a broader coverage, it >> worked on linuxx86_64 and >> >> linuxppc64 fine, and breaks with the VM without the fix. >> >> Also, all our other tests worked fine with the patch from yesterday. >> >> Best regards, >> >> Goetz. >> >> *From:*Coleen Phillimore [mailto:coleen.phillimore at oracle.com] >> *Sent:* Thursday, February 05, 2015 12:14 AM >> *To:* Lindenmaier, Goetz; hotspot-dev Source Developers >> *Subject:* Re: RFR(S): 8072434: 8064457: introduces performance >> regressions in 9-b47 >> >> >> Hi Goetz, >> >> I was trying to figure out how we used to decide whether to put the >> compressed class space above the heap in preferred_heap_base(). The >> code was: >> >> const size_t total_size = heap_size + >> heap_base_min_address_aligned; // 30G + 2G >> >> ... >> // space so it can be decoded with no base. >> if (UseCompressedClassPointers && !UseSharedSpaces && >> OopEncodingHeapMax <= 32*G) { >> >> uint64_t class_space = >> align_size_up(CompressedClassSpaceSize, alignment); // 1G >> assert(is_size_aligned((size_t)OopEncodingHeapMax-class_space, >> alignment), "difference must be aligned too"); >> uint64_t new_top = OopEncodingHeapMax-class_space; // >> 32G - 1G >> >> if (total_size <= new_top) { // 32G <= 31G false, >> don't use the new_top. >> heap_top = new_top; >> } >> } >> >> // Align base to the adjusted top of the heap >> base = heap_top - heap_size; >> >> >> This is also one instance where 32*G is much easier to understand in >> the code than the symbolic name OopEncodingHeapMax. >> >> Anyway, your code fix looks correct. You want it to be >> KlassEncodingMetaspaceMax logically (I thought it should be >> OopEncodingHeapMax) since allocating the class space above the heap >> and getting zero based compressed oops, the class decoding algorithm >> can only shift by 3 not 5. The clause above it excludes the >> ObjAlignmentInBytes = shifting 5 case anyway. >> >> Thank you for fixing this! >> >> Coleen >> >> On 2/4/15, 10:55 AM, Lindenmaier, Goetz wrote: >> >> Hi, >> >> There is a performance regression after my change 8064457. >> >> 30G heaps do not displace the CompressedClassSpace from the lower >> memory >> >> region and instead are allocated in upper regions. >> >> This webrev should fix the Problem. >> >> http://cr.openjdk.java.net/~goetz/webrevs/8072434-css/webrev.01/ >> >> >> I verified that it works now and ran runtime/CompressedOops jtreg >> tests on linuxx86_64. >> >> I'll get a comprehensive test run by tomorrow. >> >> Best regards, >> >> Goetz. >> > From goetz.lindenmaier at sap.com Thu Feb 5 22:29:12 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 5 Feb 2015 22:29:12 +0000 Subject: RFR(S): 8072434: 8064457: introduces performance regressions in 9-b47 In-Reply-To: <54D3ED14.9070506@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CF9137F@DEWDFEMB12A.global.corp.sap> <54D2A7B2.6000109@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF926C7@DEWDFEMB12A.global.corp.sap> <54D3EBC6.5020009@oracle.com> <54D3ED14.9070506@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CF928C4@DEWDFEMB12A.global.corp.sap> Hi Coleen, OK, no matter. Will you then use webrev.01? Or should I make another one? Best regards, Goetz. From coleen.phillimore at oracle.com Thu Feb 5 23:12:23 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 05 Feb 2015 18:12:23 -0500 Subject: RFR(S): 8072434: 8064457: introduces performance regressions in 9-b47 In-Reply-To: <54D3ED14.9070506@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CF9137F@DEWDFEMB12A.global.corp.sap> <54D2A7B2.6000109@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF926C7@DEWDFEMB12A.global.corp.sap> <54D3EBC6.5020009@oracle.com> <54D3ED14.9070506@oracle.com> Message-ID: <54D3F8D7.7010305@oracle.com> Webrev 01 is good. You need another reviewer and I'll sponsor it. http://cr.openjdk.java.net/~goetz/webrevs/8072434-css/webrev.01/ thanks, Coleen On 2/5/15, 5:22 PM, Coleen Phillimore wrote: > > On 2/5/15, 5:16 PM, Coleen Phillimore wrote: >> >> Your test #1 doesn't work on all machines either. I don't think we >> can add tests that assume memory allocation locations, so we >> shouldn't add your new test. It's been verified manually. > > Forgot to mention it didn't pass on windows x64 maybe because of ASLR. > Coleen > >> >> Coleen >> >> On 2/5/15, 10:00 AM, Lindenmaier, Goetz wrote: >>> >>> Hi Coleen, >>> >>> You are right, I missed to move that condition into the new code. >>> >>> I designed a test for zerobased startup with 30G I would like to add to >>> >>> the webrev as you proposed. I had to use WhiteBox, which took a while >>> >>> to get right ... >>> >>> I thought of these two test cases. >>> >>> 1.) Setting 30G plain, and >>> >>> 2.) setting the flags used in the benchmark. -Xmx30g -Xms30g >>> -Xmn26g-XX:+AggressiveOpts -XX:+UseNUMA >>> >>> 2.) causes two problems. First it's slow as the debug build >>> initializes the heap which walks all >>> >>> the memory. Second it fails on machines that don't have 30G >>> main memory. So I have to >>> >>> skip it. >>> >>> 1.)I'm not sure whether that will work with all OSes, the OS might >>> not return all >>> >>> of the theoretical available address space below 32G, even if >>> zerobased works >>> >>> for medium size heaps. >>> >>> I will run 1.) with my tests tonight for a broader coverage, it >>> worked on linuxx86_64 and >>> >>> linuxppc64 fine, and breaks with the VM without the fix. >>> >>> Also, all our other tests worked fine with the patch from yesterday. >>> >>> Best regards, >>> >>> Goetz. >>> >>> *From:*Coleen Phillimore [mailto:coleen.phillimore at oracle.com] >>> *Sent:* Thursday, February 05, 2015 12:14 AM >>> *To:* Lindenmaier, Goetz; hotspot-dev Source Developers >>> *Subject:* Re: RFR(S): 8072434: 8064457: introduces performance >>> regressions in 9-b47 >>> >>> >>> Hi Goetz, >>> >>> I was trying to figure out how we used to decide whether to put the >>> compressed class space above the heap in preferred_heap_base(). The >>> code was: >>> >>> const size_t total_size = heap_size + >>> heap_base_min_address_aligned; // 30G + 2G >>> >>> ... >>> // space so it can be decoded with no base. >>> if (UseCompressedClassPointers && !UseSharedSpaces && >>> OopEncodingHeapMax <= 32*G) { >>> >>> uint64_t class_space = >>> align_size_up(CompressedClassSpaceSize, alignment); // 1G >>> assert(is_size_aligned((size_t)OopEncodingHeapMax-class_space, >>> alignment), "difference must be aligned too"); >>> uint64_t new_top = OopEncodingHeapMax-class_space; // >>> 32G - 1G >>> >>> if (total_size <= new_top) { // 32G <= 31G false, >>> don't use the new_top. >>> heap_top = new_top; >>> } >>> } >>> >>> // Align base to the adjusted top of the heap >>> base = heap_top - heap_size; >>> >>> >>> This is also one instance where 32*G is much easier to understand in >>> the code than the symbolic name OopEncodingHeapMax. >>> >>> Anyway, your code fix looks correct. You want it to be >>> KlassEncodingMetaspaceMax logically (I thought it should be >>> OopEncodingHeapMax) since allocating the class space above the heap >>> and getting zero based compressed oops, the class decoding algorithm >>> can only shift by 3 not 5. The clause above it excludes the >>> ObjAlignmentInBytes = shifting 5 case anyway. >>> >>> Thank you for fixing this! >>> >>> Coleen >>> >>> On 2/4/15, 10:55 AM, Lindenmaier, Goetz wrote: >>> >>> Hi, >>> >>> There is a performance regression after my change 8064457. >>> >>> 30G heaps do not displace the CompressedClassSpace from the lower >>> memory >>> >>> region and instead are allocated in upper regions. >>> >>> This webrev should fix the Problem. >>> >>> http://cr.openjdk.java.net/~goetz/webrevs/8072434-css/webrev.01/ >>> >>> >>> I verified that it works now and ran runtime/CompressedOops jtreg >>> tests on linuxx86_64. >>> >>> I'll get a comprehensive test run by tomorrow. >>> >>> Best regards, >>> >>> Goetz. >>> >> > From vladimir.kozlov at oracle.com Thu Feb 5 23:16:52 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 05 Feb 2015 15:16:52 -0800 Subject: RFR(S): 8072434: 8064457: introduces performance regressions in 9-b47 In-Reply-To: <54D3F8D7.7010305@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CF9137F@DEWDFEMB12A.global.corp.sap> <54D2A7B2.6000109@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF926C7@DEWDFEMB12A.global.corp.sap> <54D3EBC6.5020009@oracle.com> <54D3ED14.9070506@oracle.com> <54D3F8D7.7010305@oracle.com> Message-ID: <54D3F9E4.5020505@oracle.com> Reviewed. Good. Thanks, Vladimir On 2/5/15 3:12 PM, Coleen Phillimore wrote: > > Webrev 01 is good. You need another reviewer and I'll sponsor it. > > http://cr.openjdk.java.net/~goetz/webrevs/8072434-css/webrev.01/ > > thanks, > Coleen > > On 2/5/15, 5:22 PM, Coleen Phillimore wrote: >> >> On 2/5/15, 5:16 PM, Coleen Phillimore wrote: >>> >>> Your test #1 doesn't work on all machines either. I don't think we >>> can add tests that assume memory allocation locations, so we >>> shouldn't add your new test. It's been verified manually. >> >> Forgot to mention it didn't pass on windows x64 maybe because of ASLR. >> Coleen >> >>> >>> Coleen >>> >>> On 2/5/15, 10:00 AM, Lindenmaier, Goetz wrote: >>>> >>>> Hi Coleen, >>>> >>>> You are right, I missed to move that condition into the new code. >>>> >>>> I designed a test for zerobased startup with 30G I would like to add to >>>> >>>> the webrev as you proposed. I had to use WhiteBox, which took a while >>>> >>>> to get right ... >>>> >>>> I thought of these two test cases. >>>> >>>> 1.) Setting 30G plain, and >>>> >>>> 2.) setting the flags used in the benchmark. -Xmx30g -Xms30g >>>> -Xmn26g-XX:+AggressiveOpts -XX:+UseNUMA >>>> >>>> 2.) causes two problems. First it's slow as the debug build >>>> initializes the heap which walks all >>>> >>>> the memory. Second it fails on machines that don't have 30G >>>> main memory. So I have to >>>> >>>> skip it. >>>> >>>> 1.)I'm not sure whether that will work with all OSes, the OS might >>>> not return all >>>> >>>> of the theoretical available address space below 32G, even if >>>> zerobased works >>>> >>>> for medium size heaps. >>>> >>>> I will run 1.) with my tests tonight for a broader coverage, it >>>> worked on linuxx86_64 and >>>> >>>> linuxppc64 fine, and breaks with the VM without the fix. >>>> >>>> Also, all our other tests worked fine with the patch from yesterday. >>>> >>>> Best regards, >>>> >>>> Goetz. >>>> >>>> *From:*Coleen Phillimore [mailto:coleen.phillimore at oracle.com] >>>> *Sent:* Thursday, February 05, 2015 12:14 AM >>>> *To:* Lindenmaier, Goetz; hotspot-dev Source Developers >>>> *Subject:* Re: RFR(S): 8072434: 8064457: introduces performance >>>> regressions in 9-b47 >>>> >>>> >>>> Hi Goetz, >>>> >>>> I was trying to figure out how we used to decide whether to put the >>>> compressed class space above the heap in preferred_heap_base(). The >>>> code was: >>>> >>>> const size_t total_size = heap_size + >>>> heap_base_min_address_aligned; // 30G + 2G >>>> >>>> ... >>>> // space so it can be decoded with no base. >>>> if (UseCompressedClassPointers && !UseSharedSpaces && >>>> OopEncodingHeapMax <= 32*G) { >>>> >>>> uint64_t class_space = >>>> align_size_up(CompressedClassSpaceSize, alignment); // 1G >>>> assert(is_size_aligned((size_t)OopEncodingHeapMax-class_space, >>>> alignment), "difference must be aligned too"); >>>> uint64_t new_top = OopEncodingHeapMax-class_space; // >>>> 32G - 1G >>>> >>>> if (total_size <= new_top) { // 32G <= 31G false, >>>> don't use the new_top. >>>> heap_top = new_top; >>>> } >>>> } >>>> >>>> // Align base to the adjusted top of the heap >>>> base = heap_top - heap_size; >>>> >>>> >>>> This is also one instance where 32*G is much easier to understand in >>>> the code than the symbolic name OopEncodingHeapMax. >>>> >>>> Anyway, your code fix looks correct. You want it to be >>>> KlassEncodingMetaspaceMax logically (I thought it should be >>>> OopEncodingHeapMax) since allocating the class space above the heap >>>> and getting zero based compressed oops, the class decoding algorithm >>>> can only shift by 3 not 5. The clause above it excludes the >>>> ObjAlignmentInBytes = shifting 5 case anyway. >>>> >>>> Thank you for fixing this! >>>> >>>> Coleen >>>> >>>> On 2/4/15, 10:55 AM, Lindenmaier, Goetz wrote: >>>> >>>> Hi, >>>> >>>> There is a performance regression after my change 8064457. >>>> >>>> 30G heaps do not displace the CompressedClassSpace from the lower >>>> memory >>>> >>>> region and instead are allocated in upper regions. >>>> >>>> This webrev should fix the Problem. >>>> >>>> http://cr.openjdk.java.net/~goetz/webrevs/8072434-css/webrev.01/ >>>> >>>> >>>> I verified that it works now and ran runtime/CompressedOops jtreg >>>> tests on linuxx86_64. >>>> >>>> I'll get a comprehensive test run by tomorrow. >>>> >>>> Best regards, >>>> >>>> Goetz. >>>> >>> >> > From vladimir.kozlov at oracle.com Fri Feb 6 00:22:37 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 05 Feb 2015 16:22:37 -0800 Subject: 8072053 and 8071947 fixes for aarch64/stage Message-ID: <54D4094D.5050701@oracle.com> Would be nice to have next bugs fixed before we push the port into main jdk9: https://bugs.openjdk.java.net/browse/JDK-8072053 AARCH64: remove src/java.base/unix/native/libjli/aarch64/jvm.cfg https://bugs.openjdk.java.net/browse/JDK-8071947 AARCH64: Apply 8068655 frame::safe_for_sender() computes incorrect sender_sp value for interpreted frames Thanks, Vladimir From david.holmes at oracle.com Fri Feb 6 06:14:12 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 06 Feb 2015 16:14:12 +1000 Subject: RFR: Backport JDK-6584008: jvmtiStringPrimitiveCallback should not be invoked when string value is null In-Reply-To: <54D3D984.4060609@oracle.com> References: <54D3A8AD.2000508@redhat.com> <54D3D984.4060609@oracle.com> Message-ID: <54D45BB4.1070905@oracle.com> On 6/02/2015 6:58 AM, serguei.spitsyn at oracle.com wrote: > Hi Andrew, > > This is for 8u60, right? > Looks good. > > I can sponsor the JPRT push once it gets approved. This is fine for pushing to jdk8u/hs-dev. Thanks, David > Thanks, > Serguei > > > On 2/5/15 9:30 AM, Andrew Haley wrote: >> This is a backport request for JDK8u. >> >> The patch at >> >> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/raw-rev/4a14bb075882 >> >> applies as is, requires no changes, and fixes the bug. >> >> Thanks, >> Andrew. > From serguei.spitsyn at oracle.com Fri Feb 6 06:16:14 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 05 Feb 2015 22:16:14 -0800 Subject: RFR: Backport JDK-6584008: jvmtiStringPrimitiveCallback should not be invoked when string value is null In-Reply-To: <54D45BB4.1070905@oracle.com> References: <54D3A8AD.2000508@redhat.com> <54D3D984.4060609@oracle.com> <54D45BB4.1070905@oracle.com> Message-ID: <54D45C2E.3020504@oracle.com> On 2/5/15 10:14 PM, David Holmes wrote: > On 6/02/2015 6:58 AM, serguei.spitsyn at oracle.com wrote: >> Hi Andrew, >> >> This is for 8u60, right? >> Looks good. >> >> I can sponsor the JPRT push once it gets approved. > > This is fine for pushing to jdk8u/hs-dev. Yes, it has been pushed to the jdk8u/hs-dev. Thanks, Serguei > > Thanks, > David > >> Thanks, >> Serguei >> >> >> On 2/5/15 9:30 AM, Andrew Haley wrote: >>> This is a backport request for JDK8u. >>> >>> The patch at >>> >>> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/raw-rev/4a14bb075882 >>> >>> applies as is, requires no changes, and fixes the bug. >>> >>> Thanks, >>> Andrew. >> From goetz.lindenmaier at sap.com Fri Feb 6 07:21:35 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 6 Feb 2015 07:21:35 +0000 Subject: RFR(S): 8072434: 8064457: introduces performance regressions in 9-b47 In-Reply-To: <54D3F9E4.5020505@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CF9137F@DEWDFEMB12A.global.corp.sap> <54D2A7B2.6000109@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF926C7@DEWDFEMB12A.global.corp.sap> <54D3EBC6.5020009@oracle.com> <54D3ED14.9070506@oracle.com> <54D3F8D7.7010305@oracle.com> <54D3F9E4.5020505@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CF9293F@DEWDFEMB12A.global.corp.sap> Thanks Vladimir! Best regards, Goetz. -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov Sent: Freitag, 6. Februar 2015 00:17 To: Coleen Phillimore; hotspot-dev at openjdk.java.net Subject: Re: RFR(S): 8072434: 8064457: introduces performance regressions in 9-b47 Reviewed. Good. Thanks, Vladimir On 2/5/15 3:12 PM, Coleen Phillimore wrote: > > Webrev 01 is good. You need another reviewer and I'll sponsor it. > > http://cr.openjdk.java.net/~goetz/webrevs/8072434-css/webrev.01/ > > thanks, > Coleen > > On 2/5/15, 5:22 PM, Coleen Phillimore wrote: >> >> On 2/5/15, 5:16 PM, Coleen Phillimore wrote: >>> >>> Your test #1 doesn't work on all machines either. I don't think we >>> can add tests that assume memory allocation locations, so we >>> shouldn't add your new test. It's been verified manually. >> >> Forgot to mention it didn't pass on windows x64 maybe because of ASLR. >> Coleen >> >>> >>> Coleen >>> >>> On 2/5/15, 10:00 AM, Lindenmaier, Goetz wrote: >>>> >>>> Hi Coleen, >>>> >>>> You are right, I missed to move that condition into the new code. >>>> >>>> I designed a test for zerobased startup with 30G I would like to add to >>>> >>>> the webrev as you proposed. I had to use WhiteBox, which took a while >>>> >>>> to get right ... >>>> >>>> I thought of these two test cases. >>>> >>>> 1.) Setting 30G plain, and >>>> >>>> 2.) setting the flags used in the benchmark. -Xmx30g -Xms30g >>>> -Xmn26g-XX:+AggressiveOpts -XX:+UseNUMA >>>> >>>> 2.) causes two problems. First it's slow as the debug build >>>> initializes the heap which walks all >>>> >>>> the memory. Second it fails on machines that don't have 30G >>>> main memory. So I have to >>>> >>>> skip it. >>>> >>>> 1.)I'm not sure whether that will work with all OSes, the OS might >>>> not return all >>>> >>>> of the theoretical available address space below 32G, even if >>>> zerobased works >>>> >>>> for medium size heaps. >>>> >>>> I will run 1.) with my tests tonight for a broader coverage, it >>>> worked on linuxx86_64 and >>>> >>>> linuxppc64 fine, and breaks with the VM without the fix. >>>> >>>> Also, all our other tests worked fine with the patch from yesterday. >>>> >>>> Best regards, >>>> >>>> Goetz. >>>> >>>> *From:*Coleen Phillimore [mailto:coleen.phillimore at oracle.com] >>>> *Sent:* Thursday, February 05, 2015 12:14 AM >>>> *To:* Lindenmaier, Goetz; hotspot-dev Source Developers >>>> *Subject:* Re: RFR(S): 8072434: 8064457: introduces performance >>>> regressions in 9-b47 >>>> >>>> >>>> Hi Goetz, >>>> >>>> I was trying to figure out how we used to decide whether to put the >>>> compressed class space above the heap in preferred_heap_base(). The >>>> code was: >>>> >>>> const size_t total_size = heap_size + >>>> heap_base_min_address_aligned; // 30G + 2G >>>> >>>> ... >>>> // space so it can be decoded with no base. >>>> if (UseCompressedClassPointers && !UseSharedSpaces && >>>> OopEncodingHeapMax <= 32*G) { >>>> >>>> uint64_t class_space = >>>> align_size_up(CompressedClassSpaceSize, alignment); // 1G >>>> assert(is_size_aligned((size_t)OopEncodingHeapMax-class_space, >>>> alignment), "difference must be aligned too"); >>>> uint64_t new_top = OopEncodingHeapMax-class_space; // >>>> 32G - 1G >>>> >>>> if (total_size <= new_top) { // 32G <= 31G false, >>>> don't use the new_top. >>>> heap_top = new_top; >>>> } >>>> } >>>> >>>> // Align base to the adjusted top of the heap >>>> base = heap_top - heap_size; >>>> >>>> >>>> This is also one instance where 32*G is much easier to understand in >>>> the code than the symbolic name OopEncodingHeapMax. >>>> >>>> Anyway, your code fix looks correct. You want it to be >>>> KlassEncodingMetaspaceMax logically (I thought it should be >>>> OopEncodingHeapMax) since allocating the class space above the heap >>>> and getting zero based compressed oops, the class decoding algorithm >>>> can only shift by 3 not 5. The clause above it excludes the >>>> ObjAlignmentInBytes = shifting 5 case anyway. >>>> >>>> Thank you for fixing this! >>>> >>>> Coleen >>>> >>>> On 2/4/15, 10:55 AM, Lindenmaier, Goetz wrote: >>>> >>>> Hi, >>>> >>>> There is a performance regression after my change 8064457. >>>> >>>> 30G heaps do not displace the CompressedClassSpace from the lower >>>> memory >>>> >>>> region and instead are allocated in upper regions. >>>> >>>> This webrev should fix the Problem. >>>> >>>> http://cr.openjdk.java.net/~goetz/webrevs/8072434-css/webrev.01/ >>>> >>>> >>>> I verified that it works now and ran runtime/CompressedOops jtreg >>>> tests on linuxx86_64. >>>> >>>> I'll get a comprehensive test run by tomorrow. >>>> >>>> Best regards, >>>> >>>> Goetz. >>>> >>> >> > From goetz.lindenmaier at sap.com Fri Feb 6 07:44:10 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 6 Feb 2015 07:44:10 +0000 Subject: RFR(S): 8071822: [TEST_BUG] Adapt collectorPolicy internal tests to support 64K pages Message-ID: <4295855A5C1DE049A61835A1887419CC2CF929AC@DEWDFEMB12A.global.corp.sap> Hi, could someone please have a look at this change? Thanks a lot! Goetz. From: Lindenmaier, Goetz Sent: Freitag, 30. Januar 2015 10:36 To: hotspot-dev Source Developers Subject: RFR(S): 8071822: [TEST_BUG] Adapt collectorPolicy internal tests to support 64K pages Hi, this fixes a final problem with 64-bit page size in the jtreg tests. It addresses the internal VM tests of the collector policies. Those tests set a row of fixed flag values, and one special value to test. Then they call the heap ergonomics and check the expected result of the special value. With 64K page size, the heap ergonomics adapt more values, breaking the tests. Wrt. the adapted flag values the tests are correct though. This change makes the expected values depend on the adapted flags, and the tests pass. They only depend on adapted flags that are not subject of the corresponding test. Please review this test. I please need a sponsor. http://cr.openjdk.java.net/~goetz/webrevs/8071822-jtregColPol/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8071822 Best regards, Goetz. From aph at redhat.com Fri Feb 6 09:05:20 2015 From: aph at redhat.com (Andrew Haley) Date: Fri, 06 Feb 2015 09:05:20 +0000 Subject: RFR: Backport JDK-6584008: jvmtiStringPrimitiveCallback should not be invoked when string value is null In-Reply-To: <54D3D984.4060609@oracle.com> References: <54D3A8AD.2000508@redhat.com> <54D3D984.4060609@oracle.com> Message-ID: <54D483D0.8020800@redhat.com> Hi, On 05/02/15 20:58, serguei.spitsyn at oracle.com wrote: > This is for 8u60, right? > Looks good. OK, thanks. I'd like to see it as soon as possible, but I understand if it's too late for u40. Andrew. From serguei.spitsyn at oracle.com Fri Feb 6 10:09:08 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 06 Feb 2015 02:09:08 -0800 Subject: RFR: Backport JDK-6584008: jvmtiStringPrimitiveCallback should not be invoked when string value is null In-Reply-To: <54D483D0.8020800@redhat.com> References: <54D3A8AD.2000508@redhat.com> <54D3D984.4060609@oracle.com> <54D483D0.8020800@redhat.com> Message-ID: <54D492C4.9000003@oracle.com> On 2/6/15 1:05 AM, Andrew Haley wrote: > Hi, > > On 05/02/15 20:58, serguei.spitsyn at oracle.com wrote: > >> This is for 8u60, right? >> Looks good. > OK, thanks. I'd like to see it as soon as possible, but I > understand if it's too late for u40. Time goes fast. :) Sorry, I've already pushed it into 8u60. The P3 priority for 8u40 at this stage (RDP2) is too low. Thanks, Serguei > > Andrew. > From aph at redhat.com Fri Feb 6 15:49:00 2015 From: aph at redhat.com (Andrew Haley) Date: Fri, 06 Feb 2015 15:49:00 +0000 Subject: RFR: 8071947: Apply 8068655 frame::safe_for_sender() computes incorrect sender_sp value for interpreted frames Message-ID: <54D4E26C.1090307@redhat.com> http://cr.openjdk.java.net/~aph/aarch64-8071947/ Andrew. From aph at redhat.com Fri Feb 6 15:54:49 2015 From: aph at redhat.com (Andrew Haley) Date: Fri, 06 Feb 2015 15:54:49 +0000 Subject: RFR: AARCH64: remove jdk/src/java.base/unix/native/libjli/aarch64/jvm.cfg Message-ID: <54D4E3C9.1090403@redhat.com> This file was committed in error. No webrev because the webrev tool aborts on the deleted file! Thanks, Andrew. From aph at redhat.com Fri Feb 6 15:56:43 2015 From: aph at redhat.com (Andrew Haley) Date: Fri, 06 Feb 2015 15:56:43 +0000 Subject: RFR: 8071947: AARCH64: frame::safe_for_sender() computes incorrect sender_sp value for interpreted frames In-Reply-To: <54D4094D.5050701@oracle.com> References: <54D4094D.5050701@oracle.com> Message-ID: <54D4E43B.9000702@redhat.com> Apply the fix for 8068655 to the AArch64 sources. http://cr.openjdk.java.net/~aph/aarch64-8071947/ Thanks, Andrew. From aph at redhat.com Fri Feb 6 17:11:40 2015 From: aph at redhat.com (Andrew Haley) Date: Fri, 06 Feb 2015 17:11:40 +0000 Subject: RFR: AARCH64: Add AArch64 support to hsdis Message-ID: <54D4F5CC.5000307@redhat.com> http://cr.openjdk.java.net/~aph/aarch64-8072698/ Andrew. From vladimir.kozlov at oracle.com Fri Feb 6 18:24:06 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 06 Feb 2015 10:24:06 -0800 Subject: RFR: AARCH64: Add AArch64 support to hsdis In-Reply-To: <54D4F5CC.5000307@redhat.com> References: <54D4F5CC.5000307@redhat.com> Message-ID: <54D506C6.7060301@oracle.com> Good. Pushing. Thanks, Vladimir On 2/6/15 9:11 AM, Andrew Haley wrote: > http://cr.openjdk.java.net/~aph/aarch64-8072698/ > > Andrew. > From vladimir.kozlov at oracle.com Fri Feb 6 18:33:00 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 06 Feb 2015 10:33:00 -0800 Subject: RFR: 8071947: AARCH64: frame::safe_for_sender() computes incorrect sender_sp value for interpreted frames In-Reply-To: <54D4E43B.9000702@redhat.com> References: <54D4094D.5050701@oracle.com> <54D4E43B.9000702@redhat.com> Message-ID: <54D508DC.4050506@oracle.com> Changes are matching 8068655 fix. Good. Pushing. Thanks, Vladimir On 2/6/15 7:56 AM, Andrew Haley wrote: > Apply the fix for 8068655 to the AArch64 sources. > > http://cr.openjdk.java.net/~aph/aarch64-8071947/ > > Thanks, > Andrew. > From ysr1729 at gmail.com Sat Feb 7 02:04:16 2015 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Fri, 6 Feb 2015 18:04:16 -0800 Subject: Make several HotSpot flags manageable Message-ID: There are a bunch of Hotspot flags (several of them in GC, but also non-GC ones) that switch on various printing options. These started out historically as product flags but it might make sense to make them manageable to allow greater field serviceability of the VM in order to manually switch on verbose print options for debugging running JVM operation. If there is interest, I'd like to open (if one isn't already open) a bug on openjdk bugzilla and offer a patch. A prime example is SafepointDelay and PrintSafepointDelay, but there are a whole bunch of more such options, for example, the following from a syntactic filter to catch a sample. The idea isn't to only touch those flags which control the emission of logging/stats from the jvm, not alter its behaviour otherwise in any manner. Is there appetite for this kind of change? In most cases nothing would be needed other than to flip the flag from product to manageable. In other cases, one would need to make sure to use a periodically taken snapshot of the flag to allow cosistency in the work done in various routines involved in one "round" of logging/stats. The following is a syntactic sample, and more work would be needed to go over these flags and others to determine the specific change needed. I plan to do that and produce the patch once there is some agreement that this would be a positive step. Please let me know your thoughts/reactions/comments etc., but it would improve HotSpot's field debuggability/serviceability story by quite a bit to do this. thanks, and have a good weekend! -- ramki (openjdk: ysr) % $currentjdk/bin/java -XX:+PrintFlagsFinal -version | grep -v manag | grep -i print bool CMSPrintChunksInDump = false {product} bool CMSPrintEdenSurvivorChunks = false {product} bool CMSPrintObjectsInDump = false {product} bool PrintAdaptiveSizePolicy = false {product} bool PrintCMSInitiationStatistics = false {product} intx PrintCMSStatistics = 0 {product} bool PrintCodeCache = false {product} bool PrintCodeCacheOnCompilation = false {product} bool PrintCommandLineFlags = false {product} bool PrintCompilation = false {product} intx PrintFLSCensus = 0 {product} intx PrintFLSStatistics = 0 {product} bool PrintFlagsFinal := true {product} bool PrintFlagsInitial = false {product} bool PrintGCApplicationConcurrentTime = false {product} bool PrintGCApplicationStoppedTime = false {product} bool PrintGCCause = true {product} bool PrintGCTaskTimeStamps = false {product} bool PrintHeapAtGC = false {product rw} bool PrintHeapAtGCExtended = false {product rw} bool PrintHeapAtSIGBREAK = true {product} bool PrintJNIGCStalls = false {product} bool PrintJNIResolving = false {product} bool PrintOldPLAB = false {product} bool PrintOopAddress = false {product} bool PrintPLAB = false {product} bool PrintParallelOldGCPhaseTimes = false {product} bool PrintPromotionFailure = false {product} bool PrintReferenceGC = false {product} bool PrintSafepointStatistics = false {product} intx PrintSafepointStatisticsCount = 300 {product} intx PrintSafepointStatisticsTimeout = -1 {product} bool PrintSharedSpaces = false {product} bool PrintStringDeduplicationStatistics = false {product} bool PrintStringTableStatistics = false {product} bool PrintTLAB = false {product} bool PrintTenuringDistribution = false {product} bool PrintTieredEvents = false {product} bool PrintVMOptions = false {product} bool PrintVMQWaitTime = false {product} bool PrintWarnings = true {product} bool ProfilerPrintByteCodeStatistics = false {product} I know not all of the following or those above can necessarily be made manageable, but this is a possible starting point for the work/investigation..... % $currentjdk/bin/java -XX:+PrintFlagsFinal -version | grep -v manag | grep -i trace | grep produc ... intx BCEATraceLevel = 0 {product} bool DTraceAllocProbes = false {product} bool DTraceMethodProbes = false {product} bool DTraceMonitorProbes = false {product} bool ExtendedDTraceProbes = false {product} bool JavaMonitorsInStackTrace = true {product} intx MaxJavaStackTraceDepth = 1024 {product} bool OmitStackTraceInFastThrow = true {product} bool StackTraceInThrowable = true {product} bool TraceBiasedLocking = false {product} bool TraceClassLoading = false {product rw} bool TraceClassLoadingPreorder = false {product} bool TraceClassResolution = false {product} bool TraceClassUnloading = false {product rw} bool TraceDynamicGCThreads = false {product} bool TraceGen0Time = false {product} bool TraceGen1Time = false {product} ccstr TraceJVMTI = {product} bool TraceLoaderConstraints = false {product rw} bool TraceMetadataHumongousAllocation = false {product} bool TraceMonitorInflation = false {product} bool TraceParallelOldGCTasks = false {product} intx TraceRedefineClasses = 0 {product} bool TraceSafepointCleanupTime = false {product} bool TraceSuspendWaitFailures = false {product} From john.r.rose at oracle.com Sat Feb 7 06:40:29 2015 From: john.r.rose at oracle.com (John Rose) Date: Fri, 6 Feb 2015 22:40:29 -0800 Subject: split vtables (example code in C++) Message-ID: <7E7D207B-3E31-46D8-AF8A-A6A4B239036C@oracle.com> I was talking to some of the GC guys in Stockholm about refactoring the oop-tracing code. The long-standing problem is that each type heap node (InstanceKlass, ObjArrayKlass, etc.) needs its own oop iteration algorithm. For performance, each oop iteration must inline each major leaf operation (OopClosure, etc.). This requires devirtualization of the leaf operations, which in turn requires making customized copies of each kind of loop, for each kind of leaf. That is, the number of loop codes is MxN, where M is the number of loops and N the leaves. This is what I call the "loop customization problem". Solving it in the JVM (without quadratic code explosion) gives a powerful boost to Java programs. Solving it in C++, however, is very difficult. Basically, you need to have a "virtual template" member function for each Klass. That's illegal, for good reason: C++ is a static language, and variable-sized vtables are not a static construct. (The JVM needs to get better at such tricks also, as I said in my JFokus talk.) But, it is possible, with some careful work, to get an MxN dispatch in C++, by manually "splitting" the loop methods, and their vtable slots, across the desired leaf operation classes. I worked out a clean way to do this; please take a look if you are interested in this problem. http://cr.openjdk.java.net/~jrose/draft/splitvtbl.cpp Maybe this is written up in somebody's book of C++ patterns, but I've never seen it expressed in this way before. Visitors come close, but these are something more tightly coupled than the visitor pattern, because the branches of the visitor-like dispatch are versions of the same template. Enjoy, ? John From snazy at snazy.de Sat Feb 7 09:02:13 2015 From: snazy at snazy.de (Robert Stupp) Date: Sat, 7 Feb 2015 10:02:13 +0100 Subject: JNI faster than Unsafe? Message-ID: Hi there, I've setup a single microbenchmark just to know which off-heap memory allocation is faster on Linux + OSX. Candidates were Unsafe.allocateMemory and JNA's Native.malloc(). Both either against "raw" OS and against a preloaded jemalloc (LD_PRELOAD). My initial suspicion was, that both (Unsafe vs. Native) should perform quite equally since both methods are basically just wrappers for C malloc(). But they don't. Native.malloc() is much faster compared to Unsafe.allocateMemory(). Depending on the individual microbenchmark, Native.malloc() is up to 3 times faster than Unsafe.allocateMemory(). Here's a spreadsheet, that I've worked out during the benchmark. https://docs.google.com/spreadsheets/d/1kHqPArBXKI1izSRBcGyfomuQqq5VJHQUkrMxulqOpQc/edit#gid=0 (you may safely ignore the jemalloc-via-JNA stuff) The JMH source is here: https://github.com/snazy/cassandra/blob/8714-row-cache-jemalloc/test/microbench/org/apache/cassandra/test/microbench/OffHeapAllocationBench.java ? Robert Stupp @snazy From kirk at kodewerk.com Sat Feb 7 09:41:15 2015 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Sat, 7 Feb 2015 10:41:15 +0100 Subject: Make several HotSpot flags manageable In-Reply-To: References: Message-ID: <38B2AC4D-53BA-40E1-AA78-F90D867857E3@kodewerk.com> Hi Ramki, I would love for more of the boolean Product flags to be manageable. You touch on safe point printing but there certainly others where it would be very helpful to be able to switch them without having to bounce the JVM when there isn?t any other real need to do so. Kind regards Kirk Pepperdine On Feb 7, 2015, at 3:04 AM, Srinivas Ramakrishna wrote: > There are a bunch of Hotspot flags (several of them in GC, but also non-GC > ones) that switch on various printing options. > These started out historically as product flags but it might make sense to > make them manageable to allow greater field > serviceability of the VM in order to manually switch on verbose print > options for debugging running JVM operation. > If there is interest, I'd like to open (if one isn't already open) a bug on > openjdk bugzilla and offer a patch. > > A prime example is SafepointDelay and PrintSafepointDelay, but there are a > whole bunch of more such options, for example, > the following from a syntactic filter to catch a sample. The idea isn't to > only touch those flags which control the emission > of logging/stats from the jvm, not alter its behaviour otherwise in any > manner. > > Is there appetite for this kind of change? In most cases nothing would be > needed other than to flip the flag from product to > manageable. In other cases, one would need to make sure to use a > periodically taken snapshot of the flag to allow cosistency > in the work done in various routines involved in one "round" of > logging/stats. > > The following is a syntactic sample, and more work would be needed to go > over these flags and others to determine the specific > change needed. I plan to do that and produce the patch once there is some > agreement that this would be a positive step. > > Please let me know your thoughts/reactions/comments etc., but it would > improve HotSpot's field debuggability/serviceability story > by quite a bit to do this. > > thanks, and have a good weekend! > -- ramki (openjdk: ysr) > > % $currentjdk/bin/java -XX:+PrintFlagsFinal -version | grep -v manag | grep > -i print > > bool CMSPrintChunksInDump = false > {product} > > bool CMSPrintEdenSurvivorChunks = false > {product} > > bool CMSPrintObjectsInDump = false > {product} > > bool PrintAdaptiveSizePolicy = false > {product} > > bool PrintCMSInitiationStatistics = false > {product} > > intx PrintCMSStatistics = 0 > {product} > > bool PrintCodeCache = false > {product} > > bool PrintCodeCacheOnCompilation = false > {product} > > bool PrintCommandLineFlags = false > {product} > > bool PrintCompilation = false > {product} > > intx PrintFLSCensus = 0 > {product} > > intx PrintFLSStatistics = 0 > {product} > > bool PrintFlagsFinal := true > {product} > > bool PrintFlagsInitial = false > {product} > > bool PrintGCApplicationConcurrentTime = false > {product} > > bool PrintGCApplicationStoppedTime = false > {product} > > bool PrintGCCause = true > {product} > > bool PrintGCTaskTimeStamps = false > {product} > > bool PrintHeapAtGC = false > {product rw} > > bool PrintHeapAtGCExtended = false > {product rw} > > bool PrintHeapAtSIGBREAK = true > {product} > > bool PrintJNIGCStalls = false > {product} > > bool PrintJNIResolving = false > {product} > > bool PrintOldPLAB = false > {product} > > bool PrintOopAddress = false > {product} > > bool PrintPLAB = false > {product} > > bool PrintParallelOldGCPhaseTimes = false > {product} > > bool PrintPromotionFailure = false > {product} > > bool PrintReferenceGC = false > {product} > > bool PrintSafepointStatistics = false > {product} > > intx PrintSafepointStatisticsCount = 300 > {product} > > intx PrintSafepointStatisticsTimeout = -1 > {product} > > bool PrintSharedSpaces = false > {product} > > bool PrintStringDeduplicationStatistics = false > {product} > > bool PrintStringTableStatistics = false > {product} > > bool PrintTLAB = false > {product} > > bool PrintTenuringDistribution = false > {product} > > bool PrintTieredEvents = false > {product} > > bool PrintVMOptions = false > {product} > > bool PrintVMQWaitTime = false > {product} > > bool PrintWarnings = true > {product} > > bool ProfilerPrintByteCodeStatistics = false > {product} > > > I know not all of the following or those above can necessarily be made > manageable, but this is a possible > > starting point for the work/investigation..... > > % $currentjdk/bin/java -XX:+PrintFlagsFinal -version | grep -v manag | grep > -i trace | grep produc > > ... > > intx BCEATraceLevel = 0 > {product} > > bool DTraceAllocProbes = false > {product} > > bool DTraceMethodProbes = false > {product} > > bool DTraceMonitorProbes = false > {product} > > bool ExtendedDTraceProbes = false > {product} > > bool JavaMonitorsInStackTrace = true > {product} > > intx MaxJavaStackTraceDepth = 1024 > {product} > > bool OmitStackTraceInFastThrow = true > {product} > > bool StackTraceInThrowable = true > {product} > > bool TraceBiasedLocking = false > {product} > > bool TraceClassLoading = false > {product rw} > > bool TraceClassLoadingPreorder = false > {product} > > bool TraceClassResolution = false > {product} > > bool TraceClassUnloading = false > {product rw} > > bool TraceDynamicGCThreads = false > {product} > > bool TraceGen0Time = false > {product} > > bool TraceGen1Time = false > {product} > > ccstr TraceJVMTI = > {product} > > bool TraceLoaderConstraints = false > {product rw} > > bool TraceMetadataHumongousAllocation = false > {product} > > bool TraceMonitorInflation = false > {product} > > bool TraceParallelOldGCTasks = false > {product} > > intx TraceRedefineClasses = 0 > {product} > > bool TraceSafepointCleanupTime = false > {product} > > bool TraceSuspendWaitFailures = false > {product} From snazy at snazy.de Sat Feb 7 09:46:19 2015 From: snazy at snazy.de (Robert Stupp) Date: Sat, 7 Feb 2015 10:46:19 +0100 Subject: JNI faster than Unsafe? In-Reply-To: References: Message-ID: <3FE5D8A9-5D16-4716-8519-9740BCEF2754@snazy.de> I think I found the reason why Unsafe.allocateMemory is slower in os::malloc : inc_stat_counter > Am 07.02.2015 um 10:02 schrieb Robert Stupp : > > Hi there, > > I've setup a single microbenchmark just to know which off-heap memory allocation is faster on Linux + OSX. Candidates were Unsafe.allocateMemory and JNA's Native.malloc(). Both either against "raw" OS and against a preloaded jemalloc (LD_PRELOAD). > > My initial suspicion was, that both (Unsafe vs. Native) should perform quite equally since both methods are basically just wrappers for C malloc(). But they don't. > > Native.malloc() is much faster compared to Unsafe.allocateMemory(). > Depending on the individual microbenchmark, Native.malloc() is up to 3 times faster than Unsafe.allocateMemory(). > > Here's a spreadsheet, that I've worked out during the benchmark. > https://docs.google.com/spreadsheets/d/1kHqPArBXKI1izSRBcGyfomuQqq5VJHQUkrMxulqOpQc/edit#gid=0 > (you may safely ignore the jemalloc-via-JNA stuff) > > The JMH source is here: https://github.com/snazy/cassandra/blob/8714-row-cache-jemalloc/test/microbench/org/apache/cassandra/test/microbench/OffHeapAllocationBench.java > > ? > Robert Stupp > @snazy > ? Robert Stupp @snazy From david.holmes at oracle.com Sat Feb 7 11:48:53 2015 From: david.holmes at oracle.com (David Holmes) Date: Sat, 07 Feb 2015 21:48:53 +1000 Subject: Make several HotSpot flags manageable In-Reply-To: References: Message-ID: <54D5FBA5.8050706@oracle.com> Hi Ramki, On 7/02/2015 12:04 PM, Srinivas Ramakrishna wrote: > There are a bunch of Hotspot flags (several of them in GC, but also non-GC > ones) that switch on various printing options. > These started out historically as product flags but it might make sense to > make them manageable to allow greater field > serviceability of the VM in order to manually switch on verbose print > options for debugging running JVM operation. > If there is interest, I'd like to open (if one isn't already open) a bug on > openjdk bugzilla and offer a patch. Aren't we going to take a performance hit if we do this. The flags, IIUC, are effectively constants and so when not enabled can be ignored by the interpreter and by JITed code (but not the runtime). But if they are manageable then the interpreter and JITed code will have to actually load and check them on potentially hot paths. I think you would have to do a detailed performance analysis for each flag before switching. Flags that only affect the runtime are not a concern in this aspect of course. Plus there is the supported interface aspect of this. As per globals.hpp: // A flag can be made as "manageable" only if // - the flag is defined in a CCC as an external exported interface. // - the VM implementation supports dynamic setting of the flag. // This implies that the VM must *always* query the flag variable // and not reuse state related to the flag state at any given time. // - you want the flag to be queried programmatically by the customers. > A prime example is SafepointDelay and PrintSafepointDelay, but there are a > whole bunch of more such options, for example, > the following from a syntactic filter to catch a sample. The idea isn't to > only touch those flags which control the emission > of logging/stats from the jvm, not alter its behaviour otherwise in any > manner. The idea isn't or is? :) Cheers, David > Is there appetite for this kind of change? In most cases nothing would be > needed other than to flip the flag from product to > manageable. In other cases, one would need to make sure to use a > periodically taken snapshot of the flag to allow cosistency > in the work done in various routines involved in one "round" of > logging/stats. > > The following is a syntactic sample, and more work would be needed to go > over these flags and others to determine the specific > change needed. I plan to do that and produce the patch once there is some > agreement that this would be a positive step. > > Please let me know your thoughts/reactions/comments etc., but it would > improve HotSpot's field debuggability/serviceability story > by quite a bit to do this. > > thanks, and have a good weekend! > -- ramki (openjdk: ysr) > > % $currentjdk/bin/java -XX:+PrintFlagsFinal -version | grep -v manag | grep > -i print > > bool CMSPrintChunksInDump = false > {product} > > bool CMSPrintEdenSurvivorChunks = false > {product} > > bool CMSPrintObjectsInDump = false > {product} > > bool PrintAdaptiveSizePolicy = false > {product} > > bool PrintCMSInitiationStatistics = false > {product} > > intx PrintCMSStatistics = 0 > {product} > > bool PrintCodeCache = false > {product} > > bool PrintCodeCacheOnCompilation = false > {product} > > bool PrintCommandLineFlags = false > {product} > > bool PrintCompilation = false > {product} > > intx PrintFLSCensus = 0 > {product} > > intx PrintFLSStatistics = 0 > {product} > > bool PrintFlagsFinal := true > {product} > > bool PrintFlagsInitial = false > {product} > > bool PrintGCApplicationConcurrentTime = false > {product} > > bool PrintGCApplicationStoppedTime = false > {product} > > bool PrintGCCause = true > {product} > > bool PrintGCTaskTimeStamps = false > {product} > > bool PrintHeapAtGC = false > {product rw} > > bool PrintHeapAtGCExtended = false > {product rw} > > bool PrintHeapAtSIGBREAK = true > {product} > > bool PrintJNIGCStalls = false > {product} > > bool PrintJNIResolving = false > {product} > > bool PrintOldPLAB = false > {product} > > bool PrintOopAddress = false > {product} > > bool PrintPLAB = false > {product} > > bool PrintParallelOldGCPhaseTimes = false > {product} > > bool PrintPromotionFailure = false > {product} > > bool PrintReferenceGC = false > {product} > > bool PrintSafepointStatistics = false > {product} > > intx PrintSafepointStatisticsCount = 300 > {product} > > intx PrintSafepointStatisticsTimeout = -1 > {product} > > bool PrintSharedSpaces = false > {product} > > bool PrintStringDeduplicationStatistics = false > {product} > > bool PrintStringTableStatistics = false > {product} > > bool PrintTLAB = false > {product} > > bool PrintTenuringDistribution = false > {product} > > bool PrintTieredEvents = false > {product} > > bool PrintVMOptions = false > {product} > > bool PrintVMQWaitTime = false > {product} > > bool PrintWarnings = true > {product} > > bool ProfilerPrintByteCodeStatistics = false > {product} > > > I know not all of the following or those above can necessarily be made > manageable, but this is a possible > > starting point for the work/investigation..... > > % $currentjdk/bin/java -XX:+PrintFlagsFinal -version | grep -v manag | grep > -i trace | grep produc > > ... > > intx BCEATraceLevel = 0 > {product} > > bool DTraceAllocProbes = false > {product} > > bool DTraceMethodProbes = false > {product} > > bool DTraceMonitorProbes = false > {product} > > bool ExtendedDTraceProbes = false > {product} > > bool JavaMonitorsInStackTrace = true > {product} > > intx MaxJavaStackTraceDepth = 1024 > {product} > > bool OmitStackTraceInFastThrow = true > {product} > > bool StackTraceInThrowable = true > {product} > > bool TraceBiasedLocking = false > {product} > > bool TraceClassLoading = false > {product rw} > > bool TraceClassLoadingPreorder = false > {product} > > bool TraceClassResolution = false > {product} > > bool TraceClassUnloading = false > {product rw} > > bool TraceDynamicGCThreads = false > {product} > > bool TraceGen0Time = false > {product} > > bool TraceGen1Time = false > {product} > > ccstr TraceJVMTI = > {product} > > bool TraceLoaderConstraints = false > {product rw} > > bool TraceMetadataHumongousAllocation = false > {product} > > bool TraceMonitorInflation = false > {product} > > bool TraceParallelOldGCTasks = false > {product} > > intx TraceRedefineClasses = 0 > {product} > > bool TraceSafepointCleanupTime = false > {product} > > bool TraceSuspendWaitFailures = false > {product} > From kirk at kodewerk.com Sat Feb 7 12:31:52 2015 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Sat, 7 Feb 2015 13:31:52 +0100 Subject: Make several HotSpot flags manageable In-Reply-To: <54D5FBA5.8050706@oracle.com> References: <54D5FBA5.8050706@oracle.com> Message-ID: <16572D36-6749-475A-8961-298228EFEF5D@kodewerk.com> Hi David, An interesting take on the problem and given the events of recent days, yes, I think one would have to be careful to understand the full impact of making even seemingly trivial changes. That said, wouldn?t expect things like turning on or off a GC logging option to have any traumatic effect on performance or the behavior of the JVM. Kind regards, Kirk On Feb 7, 2015, at 12:48 PM, David Holmes wrote: > Hi Ramki, > > On 7/02/2015 12:04 PM, Srinivas Ramakrishna wrote: >> There are a bunch of Hotspot flags (several of them in GC, but also non-GC >> ones) that switch on various printing options. >> These started out historically as product flags but it might make sense to >> make them manageable to allow greater field >> serviceability of the VM in order to manually switch on verbose print >> options for debugging running JVM operation. >> If there is interest, I'd like to open (if one isn't already open) a bug on >> openjdk bugzilla and offer a patch. > > Aren't we going to take a performance hit if we do this. The flags, IIUC, are effectively constants and so when not enabled can be ignored by the interpreter and by JITed code (but not the runtime). But if they are manageable then the interpreter and JITed code will have to actually load and check them on potentially hot paths. > > I think you would have to do a detailed performance analysis for each flag before switching. Flags that only affect the runtime are not a concern in this aspect of course. > > Plus there is the supported interface aspect of this. As per globals.hpp: > > // A flag can be made as "manageable" only if > // - the flag is defined in a CCC as an external exported interface. > // - the VM implementation supports dynamic setting of the flag. > // This implies that the VM must *always* query the flag variable > // and not reuse state related to the flag state at any given time. > // - you want the flag to be queried programmatically by the customers. > >> A prime example is SafepointDelay and PrintSafepointDelay, but there are a >> whole bunch of more such options, for example, >> the following from a syntactic filter to catch a sample. The idea isn't to >> only touch those flags which control the emission >> of logging/stats from the jvm, not alter its behaviour otherwise in any >> manner. > > The idea isn't or is? :) > > Cheers, > David > >> Is there appetite for this kind of change? In most cases nothing would be >> needed other than to flip the flag from product to >> manageable. In other cases, one would need to make sure to use a >> periodically taken snapshot of the flag to allow cosistency >> in the work done in various routines involved in one "round" of >> logging/stats. >> >> The following is a syntactic sample, and more work would be needed to go >> over these flags and others to determine the specific >> change needed. I plan to do that and produce the patch once there is some >> agreement that this would be a positive step. >> >> Please let me know your thoughts/reactions/comments etc., but it would >> improve HotSpot's field debuggability/serviceability story >> by quite a bit to do this. >> >> thanks, and have a good weekend! >> -- ramki (openjdk: ysr) >> >> % $currentjdk/bin/java -XX:+PrintFlagsFinal -version | grep -v manag | grep >> -i print >> >> bool CMSPrintChunksInDump = false >> {product} >> >> bool CMSPrintEdenSurvivorChunks = false >> {product} >> >> bool CMSPrintObjectsInDump = false >> {product} >> >> bool PrintAdaptiveSizePolicy = false >> {product} >> >> bool PrintCMSInitiationStatistics = false >> {product} >> >> intx PrintCMSStatistics = 0 >> {product} >> >> bool PrintCodeCache = false >> {product} >> >> bool PrintCodeCacheOnCompilation = false >> {product} >> >> bool PrintCommandLineFlags = false >> {product} >> >> bool PrintCompilation = false >> {product} >> >> intx PrintFLSCensus = 0 >> {product} >> >> intx PrintFLSStatistics = 0 >> {product} >> >> bool PrintFlagsFinal := true >> {product} >> >> bool PrintFlagsInitial = false >> {product} >> >> bool PrintGCApplicationConcurrentTime = false >> {product} >> >> bool PrintGCApplicationStoppedTime = false >> {product} >> >> bool PrintGCCause = true >> {product} >> >> bool PrintGCTaskTimeStamps = false >> {product} >> >> bool PrintHeapAtGC = false >> {product rw} >> >> bool PrintHeapAtGCExtended = false >> {product rw} >> >> bool PrintHeapAtSIGBREAK = true >> {product} >> >> bool PrintJNIGCStalls = false >> {product} >> >> bool PrintJNIResolving = false >> {product} >> >> bool PrintOldPLAB = false >> {product} >> >> bool PrintOopAddress = false >> {product} >> >> bool PrintPLAB = false >> {product} >> >> bool PrintParallelOldGCPhaseTimes = false >> {product} >> >> bool PrintPromotionFailure = false >> {product} >> >> bool PrintReferenceGC = false >> {product} >> >> bool PrintSafepointStatistics = false >> {product} >> >> intx PrintSafepointStatisticsCount = 300 >> {product} >> >> intx PrintSafepointStatisticsTimeout = -1 >> {product} >> >> bool PrintSharedSpaces = false >> {product} >> >> bool PrintStringDeduplicationStatistics = false >> {product} >> >> bool PrintStringTableStatistics = false >> {product} >> >> bool PrintTLAB = false >> {product} >> >> bool PrintTenuringDistribution = false >> {product} >> >> bool PrintTieredEvents = false >> {product} >> >> bool PrintVMOptions = false >> {product} >> >> bool PrintVMQWaitTime = false >> {product} >> >> bool PrintWarnings = true >> {product} >> >> bool ProfilerPrintByteCodeStatistics = false >> {product} >> >> >> I know not all of the following or those above can necessarily be made >> manageable, but this is a possible >> >> starting point for the work/investigation..... >> >> % $currentjdk/bin/java -XX:+PrintFlagsFinal -version | grep -v manag | grep >> -i trace | grep produc >> >> ... >> >> intx BCEATraceLevel = 0 >> {product} >> >> bool DTraceAllocProbes = false >> {product} >> >> bool DTraceMethodProbes = false >> {product} >> >> bool DTraceMonitorProbes = false >> {product} >> >> bool ExtendedDTraceProbes = false >> {product} >> >> bool JavaMonitorsInStackTrace = true >> {product} >> >> intx MaxJavaStackTraceDepth = 1024 >> {product} >> >> bool OmitStackTraceInFastThrow = true >> {product} >> >> bool StackTraceInThrowable = true >> {product} >> >> bool TraceBiasedLocking = false >> {product} >> >> bool TraceClassLoading = false >> {product rw} >> >> bool TraceClassLoadingPreorder = false >> {product} >> >> bool TraceClassResolution = false >> {product} >> >> bool TraceClassUnloading = false >> {product rw} >> >> bool TraceDynamicGCThreads = false >> {product} >> >> bool TraceGen0Time = false >> {product} >> >> bool TraceGen1Time = false >> {product} >> >> ccstr TraceJVMTI = >> {product} >> >> bool TraceLoaderConstraints = false >> {product rw} >> >> bool TraceMetadataHumongousAllocation = false >> {product} >> >> bool TraceMonitorInflation = false >> {product} >> >> bool TraceParallelOldGCTasks = false >> {product} >> >> intx TraceRedefineClasses = 0 >> {product} >> >> bool TraceSafepointCleanupTime = false >> {product} >> >> bool TraceSuspendWaitFailures = false >> {product} >> From aleksey.shipilev at oracle.com Sun Feb 8 10:12:17 2015 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Sun, 08 Feb 2015 13:12:17 +0300 Subject: JNI faster than Unsafe? In-Reply-To: <3FE5D8A9-5D16-4716-8519-9740BCEF2754@snazy.de> References: <3FE5D8A9-5D16-4716-8519-9740BCEF2754@snazy.de> Message-ID: <54D73681.10908@oracle.com> Hi Robert. On 02/07/2015 12:46 PM, Robert Stupp wrote: > I think I found the reason why Unsafe.allocateMemory is slower in > os::malloc : inc_stat_counter I think inc_stat_counter has nothing to do with it, it's guarded by NOT_PRODUCT(...), which means it is stripped from the product VM. C/C++ is funny like that, you can hide an elephant behind a macro, see below. >> Am 07.02.2015 um 10:02 schrieb Robert Stupp : >> I've setup a single microbenchmark just to know which off-heap >> memory allocation is faster on Linux + OSX. Candidates were >> Unsafe.allocateMemory and JNA's Native.malloc(). Both either >> against "raw" OS and against a preloaded jemalloc (LD_PRELOAD). >> >> My initial suspicion was, that both (Unsafe vs. Native) should >> perform quite equally since both methods are basically just >> wrappers for C malloc(). But they don't. There is a difference though: JNI to VM version of AllocateMemory vs. JNA to malloc itself. Although JNA should also use a simple JNI stub to transit from Java to native, the minute details might differ enough. >> Native.malloc() is much faster compared to >> Unsafe.allocateMemory(). Depending on the individual >> microbenchmark, Native.malloc() is up to 3 times faster than >> Unsafe.allocateMemory(). Let me outline how you can disentangle the reason for the performance difference like this. It seems a better time investment to dive into the internals than doing multiple experiments on multiple platforms -- we get straight to the point, instead of indulging into the modern version of tasseography. The flow I followed is brain-dumped here: http://cr.openjdk.java.net/~shade/scratch/unsafe-allocate.txt I'll copy the conclusion here: 1. Unsafe.allocateMemory wastes 20 seconds, before calling to Unsafe_AllocateMemory. If you look into the disassembly for the generated code, you will see the preparations for the native call. 2. Unsafe_AllocateMemory wastes 44 seconds, before calling to os::malloc, HandleMarkCleaner and others. If you look into the disassembly for this stub, you will see a significant amount of time spent dealing with doing the actual JNI transition. In the source code, this is hidden behind the UNSAFE_ENTRY macros in unsafe.cpp: UNSAFE_ENTRY(jlong, Unsafe_AllocateMemory(JNIEnv *env, jobject unsafe, jlong size)) 3. os::malloc(unsigned long,MemoryType) wastes 17 seconds before calling to overloaded version of itself. The disassembly seems to show the inlined body of CALLER_PC macros that does a few "MemTracker" checks. 4. os::malloc(unsigned long,MemoryType,const NativeCallStack&) wastes another 20 seconds before finally reaching malloc. The disassembly seems to show the inlined body of MallocTracker::record_malloc before the call into the actual glibc's malloc. 5. HandleMarkCleaner, thread_from_jni_environment waste another 23 seconds for themselves. The disassemblies for them are trivial, and it does not seem obvious if we can optimize them. BOTTOM LINE: The overheads of Unsafe.allocateMemory seem to lie in both handling the actual JNI transition, doing the VM housekeeping, and also paying the dues for NMT support. If there is a version that can avoid both costs, it would experience a performance boost. Back-envelope calculation: saving (20+44+17+20+23)=124 seconds out of 221 seconds for allocateMemory itself brings the speedup of 221/(221-124) = 2.27x. (Note it does not explain the 3x difference against JNA, since JNI transition should also be involved here. But, using this flow, you can take the configuration where you had observed the difference, and dissect it). (Note #2: I'll let runtime/NMT folks to figure if NMT should provide less overhead here). Thanks, -Aleksey. From david.holmes at oracle.com Mon Feb 9 07:14:23 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 09 Feb 2015 17:14:23 +1000 Subject: RFR: 7143664: Clean up OrderAccess implementations and usage In-Reply-To: <54C9674C.2080600@oracle.com> References: <54C1EBD3.1000905@oracle.com> <54C1F3D8.5040507@oracle.com> <54C2C1EA.5020507@oracle.com> <54C87D16.40601@oracle.com> <54C9674C.2080600@oracle.com> Message-ID: <54D85E4F.5020305@oracle.com> On 29/01/2015 8:48 AM, David Holmes wrote: > Updated webrev: > > http://cr.openjdk.java.net/~dholmes/7143664/webrev.v2/ First let me say that Erik and I had a lot of offline discussions about this since he first proposed his reworking. My initial concern was ensuring the model changes were appropriate as this is a complex area and there can be different views of how things can/should be expressed. As per the bug report I was aware of a number of issues with the existing expression of semantics, but Erik showed me things were even worse than I had thought :) Basically the definitions of stand-alone release() and acquire() as they currently are in orderAccess.hpp are somewhat broken. "release" semantics must establish a barrier between accesses prior to the release() and a specific store after the release - hence release_store() and similarly for acquire() and a preceding load, hence load_acquire(). The general definitions of acquire() and release() as one-way movement barriers don't provide useful semantics - in part because regardless of which way you move things once everything is on the same side of the barrier you can't tell in which direction they moved. :) Further, those general definitions would imply that release_store() and release();store are semantically very different - but they are currently implemented (as are things like release_store_fence) as if semantically the same. And finally, while orderAccess.hpp suggests that release() can be implemented by a storeStore|loadStore barrier, there is code throughout the VM that expects it is exactly a storeStore|storeload barrier. (And similarly for acquire). C1 for example explicitly defines: membar_acquire := LoadLoad + LoadStore membar_release := LoadStore + StoreStore membar := StoreLoad (aka fence) and if I then look at where "release" is used in the codebase they all seem incorrect based on "release" semantics, but correct if you expect release() to mean LoadStore|StoreStore (and in most cases you would then actually use a release_store). So the changes Erik proposes to ensure that release() and acquire() are defined with respect to that subsequent-store or preceding-load, bring expectations in the code back into alignment. It means release(); store is the same as release_store() semantically, and the latter is a means for optimizing when you place the barrier and the store directly together - where often you can't because the actual store/load may be buried within other accessor methods eg: OrderAccess::release(); java_lang_Thread::set_xxx(threadobj, value); We can fix that by adding set_with_release/load_with_acquire, or passing in barrier enums C++11 style, but that is a lot of rework. On the implementation side I'm a template novice and was originally skeptical about the technique, but having implemented it for a couple of platforms I'm now a fan - even if I couldn't walk you through the exact behaviour of the template specialization code :) So on to the actual review comments ... --- src/share/vm/runtime/orderAccess.hpp Minor nit: I would prefer the term "bound" rather than "joined" when referring to load_acquire and store_release. In the implementation table I think "sparc" should be "sparc TSO". I still think we need to say something about C++ volatile and about compiler barriers in general. --- src/share/vm/runtime/orderAccess.inline.hpp No comment --- src/cpu/x86/vm/c1_LIRAssembler_x86.cpp No comment (this just removes stale/unused terminology) --- src/os_cpu/aix_ppc/vm/orderAccess_aix_ppc.inline.hpp src/os_cpu/linux_ppc/vm/orderAccess_linux_ppc.inline.hpp No comments - ppc64 folk need to review these. --- src/os_cpu/bsd_x86/vm/orderAccess_bsd_x86.inline.hpp src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp In OrderAccess::fence doesn't the existing asm already act as a compiler barrier; and on uniprocessor we need neither compiler nor hardware barriers; so isn't the compiler_barrier() redundant? --- src/os_cpu/bsd_zero/vm/orderAccess_bsd_zero.inline.hpp src/os_cpu/linux_zero/vm/orderAccess_linux_zero.inline.hpp No comments - The Zero folk will need to approve this change in terminology. --- src/os_cpu/linux_sparc/vm/orderAccess_linux_sparc.inline.hpp No comments. --- src/os_cpu/solaris_sparc/vm/orderAccess_solaris_sparc.inline.hpp src/os_cpu/solaris_sparc/vm/solaris_sparc.il You've removed the GNU_SOURCE ifdefs which means the new code has to be tested using gcc on Solaris. We don't officially support that platform so I have no way to verify these particular changes. --- src/os_cpu/solaris_x86/vm/orderAccess_solaris_x86.inline.hpp src/os_cpu/solaris_x86/vm/solaris_x86_32.il src/os_cpu/solaris_x86/vm/solaris_x86_64.il I think it makes sense to use the same code here as the linux x86 version. But as above can't verify this for gcc on Solaris; also query about need for compiler_barrier() in fence(). --- src/os_cpu/windows_x86/vm/orderAccess_windows_x86.inline.hpp Same comment about fence() and compiler_barrier() :) Do you have a reference to the MSVC volatile semantics? Not clear about the 32-bit versus 64-bit changes - mainly because I don't know why they were different in the first place. Why are windows release_store_fence specializations different to linux x86 versions? Not clear about your change to the float version of release_store_fence: a) do we need to change it? b) given what we changed it to isn't that the default ? --- General comment: copyright dates need updating in most, if not all, files. Thanks, David From staffan.larsen at oracle.com Mon Feb 9 09:27:10 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Mon, 9 Feb 2015 10:27:10 +0100 Subject: Make several HotSpot flags manageable In-Reply-To: References: Message-ID: Hi Ramki, This is a very worthwhile effort and I would appreciate your contribution. As you point out, every flag is different and needs its own consideration (both functionally and performance wise). Therefore, I would suggest any resulting patches are for one flag at a time. Also, you might want to keep an eye on JEP 158: Unified JVM Logging [1] which includes the ability to turn on and off specific logging at runtime. Over time all JVM logging will move to this framework and this may be good place to make that transition for some of the flags. Also, turning on and off JVM logging does not change the ?external exported interface? as the addition of a manageable flag would do. (BTW, the bug tracker of choice is JBS, not Bugzilla: https://bugs.openjdk.java.net/ ) Thanks, /Staffan [1] https://bugs.openjdk.java.net/browse/JDK-8046148 > On 7 feb 2015, at 03:04, Srinivas Ramakrishna wrote: > > There are a bunch of Hotspot flags (several of them in GC, but also non-GC > ones) that switch on various printing options. > These started out historically as product flags but it might make sense to > make them manageable to allow greater field > serviceability of the VM in order to manually switch on verbose print > options for debugging running JVM operation. > If there is interest, I'd like to open (if one isn't already open) a bug on > openjdk bugzilla and offer a patch. > > A prime example is SafepointDelay and PrintSafepointDelay, but there are a > whole bunch of more such options, for example, > the following from a syntactic filter to catch a sample. The idea isn't to > only touch those flags which control the emission > of logging/stats from the jvm, not alter its behaviour otherwise in any > manner. > > Is there appetite for this kind of change? In most cases nothing would be > needed other than to flip the flag from product to > manageable. In other cases, one would need to make sure to use a > periodically taken snapshot of the flag to allow cosistency > in the work done in various routines involved in one "round" of > logging/stats. > > The following is a syntactic sample, and more work would be needed to go > over these flags and others to determine the specific > change needed. I plan to do that and produce the patch once there is some > agreement that this would be a positive step. > > Please let me know your thoughts/reactions/comments etc., but it would > improve HotSpot's field debuggability/serviceability story > by quite a bit to do this. > > thanks, and have a good weekend! > -- ramki (openjdk: ysr) > > % $currentjdk/bin/java -XX:+PrintFlagsFinal -version | grep -v manag | grep > -i print > > bool CMSPrintChunksInDump = false > {product} > > bool CMSPrintEdenSurvivorChunks = false > {product} > > bool CMSPrintObjectsInDump = false > {product} > > bool PrintAdaptiveSizePolicy = false > {product} > > bool PrintCMSInitiationStatistics = false > {product} > > intx PrintCMSStatistics = 0 > {product} > > bool PrintCodeCache = false > {product} > > bool PrintCodeCacheOnCompilation = false > {product} > > bool PrintCommandLineFlags = false > {product} > > bool PrintCompilation = false > {product} > > intx PrintFLSCensus = 0 > {product} > > intx PrintFLSStatistics = 0 > {product} > > bool PrintFlagsFinal := true > {product} > > bool PrintFlagsInitial = false > {product} > > bool PrintGCApplicationConcurrentTime = false > {product} > > bool PrintGCApplicationStoppedTime = false > {product} > > bool PrintGCCause = true > {product} > > bool PrintGCTaskTimeStamps = false > {product} > > bool PrintHeapAtGC = false > {product rw} > > bool PrintHeapAtGCExtended = false > {product rw} > > bool PrintHeapAtSIGBREAK = true > {product} > > bool PrintJNIGCStalls = false > {product} > > bool PrintJNIResolving = false > {product} > > bool PrintOldPLAB = false > {product} > > bool PrintOopAddress = false > {product} > > bool PrintPLAB = false > {product} > > bool PrintParallelOldGCPhaseTimes = false > {product} > > bool PrintPromotionFailure = false > {product} > > bool PrintReferenceGC = false > {product} > > bool PrintSafepointStatistics = false > {product} > > intx PrintSafepointStatisticsCount = 300 > {product} > > intx PrintSafepointStatisticsTimeout = -1 > {product} > > bool PrintSharedSpaces = false > {product} > > bool PrintStringDeduplicationStatistics = false > {product} > > bool PrintStringTableStatistics = false > {product} > > bool PrintTLAB = false > {product} > > bool PrintTenuringDistribution = false > {product} > > bool PrintTieredEvents = false > {product} > > bool PrintVMOptions = false > {product} > > bool PrintVMQWaitTime = false > {product} > > bool PrintWarnings = true > {product} > > bool ProfilerPrintByteCodeStatistics = false > {product} > > > I know not all of the following or those above can necessarily be made > manageable, but this is a possible > > starting point for the work/investigation..... > > % $currentjdk/bin/java -XX:+PrintFlagsFinal -version | grep -v manag | grep > -i trace | grep produc > > ... > > intx BCEATraceLevel = 0 > {product} > > bool DTraceAllocProbes = false > {product} > > bool DTraceMethodProbes = false > {product} > > bool DTraceMonitorProbes = false > {product} > > bool ExtendedDTraceProbes = false > {product} > > bool JavaMonitorsInStackTrace = true > {product} > > intx MaxJavaStackTraceDepth = 1024 > {product} > > bool OmitStackTraceInFastThrow = true > {product} > > bool StackTraceInThrowable = true > {product} > > bool TraceBiasedLocking = false > {product} > > bool TraceClassLoading = false > {product rw} > > bool TraceClassLoadingPreorder = false > {product} > > bool TraceClassResolution = false > {product} > > bool TraceClassUnloading = false > {product rw} > > bool TraceDynamicGCThreads = false > {product} > > bool TraceGen0Time = false > {product} > > bool TraceGen1Time = false > {product} > > ccstr TraceJVMTI = > {product} > > bool TraceLoaderConstraints = false > {product rw} > > bool TraceMetadataHumongousAllocation = false > {product} > > bool TraceMonitorInflation = false > {product} > > bool TraceParallelOldGCTasks = false > {product} > > intx TraceRedefineClasses = 0 > {product} > > bool TraceSafepointCleanupTime = false > {product} > > bool TraceSuspendWaitFailures = false > {product} From volker.simonis at gmail.com Mon Feb 9 10:28:38 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 9 Feb 2015 11:28:38 +0100 Subject: What's the status of the "Hotspot makefile conversion to new build-infra" project? Message-ID: Hi everybody, I just wanted to ask what's the status of the "Hotspot makefile conversion to new build-infra" project which was announced [1] more than a year ago (yes, time flies:) I'm especially interested in the nmake to GNU-make conversion of the HotSpot make files for Windows. We've already done that at SAP a long time ago and I've offered to contribute it to the OpenJDK. However, taking into account the potential complete rewrite of the whole HotSpot build system, this probably doesn't make sense. On the other hand, taking into account the current Java 9 schedule, we probably don't have too much time left before the change of the build system will be considered too critical for integration into jdk9. So is there anybody (still) working on this project and is it still targeted for jdk 9 or has it been abandoned or re-targeted to after Java 9? Thank you and best regards, Volker [1] http://mail.openjdk.java.net/pipermail/build-infra-dev/2013-December/003339.html From erik.joelsson at oracle.com Mon Feb 9 10:38:47 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 09 Feb 2015 11:38:47 +0100 Subject: What's the status of the "Hotspot makefile conversion to new build-infra" project? In-Reply-To: References: Message-ID: <54D88E37.5000405@oracle.com> Hello Volker, It's true that this project has been pushed down the work queue for us several times now but AFAIK, we still intend to get working on this in time for JDK 9 (though this might of course change again). We are actually supposed to restart it "any day now". The work will take place in the open build-infra repos so you will be able to follow it (and contribute!) as soon as we get to start. /Erik On 2015-02-09 11:28, Volker Simonis wrote: > Hi everybody, > > I just wanted to ask what's the status of the "Hotspot makefile > conversion to new build-infra" project which was announced [1] more > than a year ago (yes, time flies:) > > I'm especially interested in the nmake to GNU-make conversion of the > HotSpot make files for Windows. We've already done that at SAP a long > time ago and I've offered to contribute it to the OpenJDK. However, > taking into account the potential complete rewrite of the whole > HotSpot build system, this probably doesn't make sense. > > On the other hand, taking into account the current Java 9 schedule, we > probably don't have too much time left before the change of the build > system will be considered too critical for integration into jdk9. > > So is there anybody (still) working on this project and is it still > targeted for jdk 9 or has it been abandoned or re-targeted to after > Java 9? > > Thank you and best regards, > Volker > > [1] http://mail.openjdk.java.net/pipermail/build-infra-dev/2013-December/003339.html From dean.long at oracle.com Mon Feb 9 19:22:04 2015 From: dean.long at oracle.com (Dean Long) Date: Mon, 09 Feb 2015 11:22:04 -0800 Subject: RFR: 7143664: Clean up OrderAccess implementations and usage In-Reply-To: <54D85E4F.5020305@oracle.com> References: <54C1EBD3.1000905@oracle.com> <54C1F3D8.5040507@oracle.com> <54C2C1EA.5020507@oracle.com> <54C87D16.40601@oracle.com> <54C9674C.2080600@oracle.com> <54D85E4F.5020305@oracle.com> Message-ID: <54D908DC.3010705@oracle.com> On 2/8/2015 11:14 PM, David Holmes wrote: > src/os_cpu/bsd_x86/vm/orderAccess_bsd_x86.inline.hpp > src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp > > In OrderAccess::fence doesn't the existing asm already act as a > compiler barrier; and on uniprocessor we need neither compiler nor > hardware barriers; so isn't the compiler_barrier() redundant? Wouldn't a uniprocessor need compiler barriers just in case it got a context switch in the middle of compiler-reordered instructions? dl From david.holmes at oracle.com Tue Feb 10 01:37:45 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 10 Feb 2015 11:37:45 +1000 Subject: RFR: 7143664: Clean up OrderAccess implementations and usage In-Reply-To: <54D908DC.3010705@oracle.com> References: <54C1EBD3.1000905@oracle.com> <54C1F3D8.5040507@oracle.com> <54C2C1EA.5020507@oracle.com> <54C87D16.40601@oracle.com> <54C9674C.2080600@oracle.com> <54D85E4F.5020305@oracle.com> <54D908DC.3010705@oracle.com> Message-ID: <54D960E9.9020109@oracle.com> On 10/02/2015 5:22 AM, Dean Long wrote: > On 2/8/2015 11:14 PM, David Holmes wrote: >> src/os_cpu/bsd_x86/vm/orderAccess_bsd_x86.inline.hpp >> src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp >> >> In OrderAccess::fence doesn't the existing asm already act as a >> compiler barrier; and on uniprocessor we need neither compiler nor >> hardware barriers; so isn't the compiler_barrier() redundant? > > Wouldn't a uniprocessor need compiler barriers just in case it got a > context switch in the middle of compiler-reordered instructions? Yes of course you are right. Thanks, David > > dl > From ysr1729 at gmail.com Tue Feb 10 10:32:51 2015 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Tue, 10 Feb 2015 14:32:51 +0400 Subject: Make several HotSpot flags manageable In-Reply-To: <54D5FBA5.8050706@oracle.com> References: <54D5FBA5.8050706@oracle.com> Message-ID: ysr1729 > On Feb 7, 2015, at 15:48, David Holmes wrote: > > Hi Ramki, > >> On 7/02/2015 12:04 PM, Srinivas Ramakrishna wrote: >> There are a bunch of Hotspot flags (several of them in GC, but also non-GC >> ones) that switch on various printing options. >> These started out historically as product flags but it might make sense to >> make them manageable to allow greater field >> serviceability of the VM in order to manually switch on verbose print >> options for debugging running JVM operation. >> If there is interest, I'd like to open (if one isn't already open) a bug on >> openjdk bugzilla and offer a patch. > > Aren't we going to take a performance hit if we do this. The flags, IIUC, are effectively constants and so when not enabled can be ignored by the interpreter and by JITed code (but not the runtime). But if they are manageable then the interpreter and JITed code will have to actually load and check them on potentially hot paths. Ah, I hadn't realized that. I'll definitely keep that mind and of course any perf fallout carefully. > > I think you would have to do a detailed performance analysis for each flag before switching. Flags that only affect the runtime are not a concern in this aspect of course. > > Plus there is the supported interface aspect of this. As per globals.hpp: > > // A flag can be made as "manageable" only if > // - the flag is defined in a CCC as an external exported interface. > // - the VM implementation supports dynamic setting of the flag. > // This implies that the VM must *always* query the flag variable > // and not reuse state related to the flag state at any given time. > // - you want the flag to be queried programmatically by the customers. > >> A prime example is SafepointDelay and PrintSafepointDelay, but there are a >> whole bunch of more such options, for example, >> the following from a syntactic filter to catch a sample. The idea isn't to >> only touch those flags which control the emission >> of logging/stats from the jvm, not alter its behaviour otherwise in any >> manner. > > The idea isn't or is? :) Sorry. Yes, is :-) Thanks! -- Ramki > > Cheers, > David > >> Is there appetite for this kind of change? In most cases nothing would be >> needed other than to flip the flag from product to >> manageable. In other cases, one would need to make sure to use a >> periodically taken snapshot of the flag to allow cosistency >> in the work done in various routines involved in one "round" of >> logging/stats. >> >> The following is a syntactic sample, and more work would be needed to go >> over these flags and others to determine the specific >> change needed. I plan to do that and produce the patch once there is some >> agreement that this would be a positive step. >> >> Please let me know your thoughts/reactions/comments etc., but it would >> improve HotSpot's field debuggability/serviceability story >> by quite a bit to do this. >> >> thanks, and have a good weekend! >> -- ramki (openjdk: ysr) >> >> % $currentjdk/bin/java -XX:+PrintFlagsFinal -version | grep -v manag | grep >> -i print >> >> bool CMSPrintChunksInDump = false >> {product} >> >> bool CMSPrintEdenSurvivorChunks = false >> {product} >> >> bool CMSPrintObjectsInDump = false >> {product} >> >> bool PrintAdaptiveSizePolicy = false >> {product} >> >> bool PrintCMSInitiationStatistics = false >> {product} >> >> intx PrintCMSStatistics = 0 >> {product} >> >> bool PrintCodeCache = false >> {product} >> >> bool PrintCodeCacheOnCompilation = false >> {product} >> >> bool PrintCommandLineFlags = false >> {product} >> >> bool PrintCompilation = false >> {product} >> >> intx PrintFLSCensus = 0 >> {product} >> >> intx PrintFLSStatistics = 0 >> {product} >> >> bool PrintFlagsFinal := true >> {product} >> >> bool PrintFlagsInitial = false >> {product} >> >> bool PrintGCApplicationConcurrentTime = false >> {product} >> >> bool PrintGCApplicationStoppedTime = false >> {product} >> >> bool PrintGCCause = true >> {product} >> >> bool PrintGCTaskTimeStamps = false >> {product} >> >> bool PrintHeapAtGC = false >> {product rw} >> >> bool PrintHeapAtGCExtended = false >> {product rw} >> >> bool PrintHeapAtSIGBREAK = true >> {product} >> >> bool PrintJNIGCStalls = false >> {product} >> >> bool PrintJNIResolving = false >> {product} >> >> bool PrintOldPLAB = false >> {product} >> >> bool PrintOopAddress = false >> {product} >> >> bool PrintPLAB = false >> {product} >> >> bool PrintParallelOldGCPhaseTimes = false >> {product} >> >> bool PrintPromotionFailure = false >> {product} >> >> bool PrintReferenceGC = false >> {product} >> >> bool PrintSafepointStatistics = false >> {product} >> >> intx PrintSafepointStatisticsCount = 300 >> {product} >> >> intx PrintSafepointStatisticsTimeout = -1 >> {product} >> >> bool PrintSharedSpaces = false >> {product} >> >> bool PrintStringDeduplicationStatistics = false >> {product} >> >> bool PrintStringTableStatistics = false >> {product} >> >> bool PrintTLAB = false >> {product} >> >> bool PrintTenuringDistribution = false >> {product} >> >> bool PrintTieredEvents = false >> {product} >> >> bool PrintVMOptions = false >> {product} >> >> bool PrintVMQWaitTime = false >> {product} >> >> bool PrintWarnings = true >> {product} >> >> bool ProfilerPrintByteCodeStatistics = false >> {product} >> >> >> I know not all of the following or those above can necessarily be made >> manageable, but this is a possible >> >> starting point for the work/investigation..... >> >> % $currentjdk/bin/java -XX:+PrintFlagsFinal -version | grep -v manag | grep >> -i trace | grep produc >> >> ... >> >> intx BCEATraceLevel = 0 >> {product} >> >> bool DTraceAllocProbes = false >> {product} >> >> bool DTraceMethodProbes = false >> {product} >> >> bool DTraceMonitorProbes = false >> {product} >> >> bool ExtendedDTraceProbes = false >> {product} >> >> bool JavaMonitorsInStackTrace = true >> {product} >> >> intx MaxJavaStackTraceDepth = 1024 >> {product} >> >> bool OmitStackTraceInFastThrow = true >> {product} >> >> bool StackTraceInThrowable = true >> {product} >> >> bool TraceBiasedLocking = false >> {product} >> >> bool TraceClassLoading = false >> {product rw} >> >> bool TraceClassLoadingPreorder = false >> {product} >> >> bool TraceClassResolution = false >> {product} >> >> bool TraceClassUnloading = false >> {product rw} >> >> bool TraceDynamicGCThreads = false >> {product} >> >> bool TraceGen0Time = false >> {product} >> >> bool TraceGen1Time = false >> {product} >> >> ccstr TraceJVMTI = >> {product} >> >> bool TraceLoaderConstraints = false >> {product rw} >> >> bool TraceMetadataHumongousAllocation = false >> {product} >> >> bool TraceMonitorInflation = false >> {product} >> >> bool TraceParallelOldGCTasks = false >> {product} >> >> intx TraceRedefineClasses = 0 >> {product} >> >> bool TraceSafepointCleanupTime = false >> {product} >> >> bool TraceSuspendWaitFailures = false >> {product} >> From ysr1729 at gmail.com Tue Feb 10 10:36:08 2015 From: ysr1729 at gmail.com (Srinivas Ramakrishna) Date: Tue, 10 Feb 2015 14:36:08 +0400 Subject: Make several HotSpot flags manageable In-Reply-To: References: Message-ID: Thanks Kirk, David, Staffan for yr advice and feedback. I'll keep these in mind and look at the JEP as well. I'm traveling at the moment and won't get back to this for at least a week, but will be in touch when I start work. Will do the work incrementally while keeping careful track of perf impacts. Thanks! -- ramki ysr1729 > On Feb 9, 2015, at 13:27, Staffan Larsen wrote: > > Hi Ramki, > > This is a very worthwhile effort and I would appreciate your contribution. As you point out, every flag is different and needs its own consideration (both functionally and performance wise). Therefore, I would suggest any resulting patches are for one flag at a time. > > Also, you might want to keep an eye on JEP 158: Unified JVM Logging [1] which includes the ability to turn on and off specific logging at runtime. Over time all JVM logging will move to this framework and this may be good place to make that transition for some of the flags. Also, turning on and off JVM logging does not change the ?external exported interface? as the addition of a manageable flag would do. > > (BTW, the bug tracker of choice is JBS, not Bugzilla: https://bugs.openjdk.java.net/) > > Thanks, > /Staffan > > [1] https://bugs.openjdk.java.net/browse/JDK-8046148 > >> On 7 feb 2015, at 03:04, Srinivas Ramakrishna wrote: >> >> There are a bunch of Hotspot flags (several of them in GC, but also non-GC >> ones) that switch on various printing options. >> These started out historically as product flags but it might make sense to >> make them manageable to allow greater field >> serviceability of the VM in order to manually switch on verbose print >> options for debugging running JVM operation. >> If there is interest, I'd like to open (if one isn't already open) a bug on >> openjdk bugzilla and offer a patch. >> >> A prime example is SafepointDelay and PrintSafepointDelay, but there are a >> whole bunch of more such options, for example, >> the following from a syntactic filter to catch a sample. The idea isn't to >> only touch those flags which control the emission >> of logging/stats from the jvm, not alter its behaviour otherwise in any >> manner. >> >> Is there appetite for this kind of change? In most cases nothing would be >> needed other than to flip the flag from product to >> manageable. In other cases, one would need to make sure to use a >> periodically taken snapshot of the flag to allow cosistency >> in the work done in various routines involved in one "round" of >> logging/stats. >> >> The following is a syntactic sample, and more work would be needed to go >> over these flags and others to determine the specific >> change needed. I plan to do that and produce the patch once there is some >> agreement that this would be a positive step. >> >> Please let me know your thoughts/reactions/comments etc., but it would >> improve HotSpot's field debuggability/serviceability story >> by quite a bit to do this. >> >> thanks, and have a good weekend! >> -- ramki (openjdk: ysr) >> >> % $currentjdk/bin/java -XX:+PrintFlagsFinal -version | grep -v manag | grep >> -i print >> >> bool CMSPrintChunksInDump = false >> {product} >> >> bool CMSPrintEdenSurvivorChunks = false >> {product} >> >> bool CMSPrintObjectsInDump = false >> {product} >> >> bool PrintAdaptiveSizePolicy = false >> {product} >> >> bool PrintCMSInitiationStatistics = false >> {product} >> >> intx PrintCMSStatistics = 0 >> {product} >> >> bool PrintCodeCache = false >> {product} >> >> bool PrintCodeCacheOnCompilation = false >> {product} >> >> bool PrintCommandLineFlags = false >> {product} >> >> bool PrintCompilation = false >> {product} >> >> intx PrintFLSCensus = 0 >> {product} >> >> intx PrintFLSStatistics = 0 >> {product} >> >> bool PrintFlagsFinal := true >> {product} >> >> bool PrintFlagsInitial = false >> {product} >> >> bool PrintGCApplicationConcurrentTime = false >> {product} >> >> bool PrintGCApplicationStoppedTime = false >> {product} >> >> bool PrintGCCause = true >> {product} >> >> bool PrintGCTaskTimeStamps = false >> {product} >> >> bool PrintHeapAtGC = false >> {product rw} >> >> bool PrintHeapAtGCExtended = false >> {product rw} >> >> bool PrintHeapAtSIGBREAK = true >> {product} >> >> bool PrintJNIGCStalls = false >> {product} >> >> bool PrintJNIResolving = false >> {product} >> >> bool PrintOldPLAB = false >> {product} >> >> bool PrintOopAddress = false >> {product} >> >> bool PrintPLAB = false >> {product} >> >> bool PrintParallelOldGCPhaseTimes = false >> {product} >> >> bool PrintPromotionFailure = false >> {product} >> >> bool PrintReferenceGC = false >> {product} >> >> bool PrintSafepointStatistics = false >> {product} >> >> intx PrintSafepointStatisticsCount = 300 >> {product} >> >> intx PrintSafepointStatisticsTimeout = -1 >> {product} >> >> bool PrintSharedSpaces = false >> {product} >> >> bool PrintStringDeduplicationStatistics = false >> {product} >> >> bool PrintStringTableStatistics = false >> {product} >> >> bool PrintTLAB = false >> {product} >> >> bool PrintTenuringDistribution = false >> {product} >> >> bool PrintTieredEvents = false >> {product} >> >> bool PrintVMOptions = false >> {product} >> >> bool PrintVMQWaitTime = false >> {product} >> >> bool PrintWarnings = true >> {product} >> >> bool ProfilerPrintByteCodeStatistics = false >> {product} >> >> >> I know not all of the following or those above can necessarily be made >> manageable, but this is a possible >> >> starting point for the work/investigation..... >> >> % $currentjdk/bin/java -XX:+PrintFlagsFinal -version | grep -v manag | grep >> -i trace | grep produc >> >> ... >> >> intx BCEATraceLevel = 0 >> {product} >> >> bool DTraceAllocProbes = false >> {product} >> >> bool DTraceMethodProbes = false >> {product} >> >> bool DTraceMonitorProbes = false >> {product} >> >> bool ExtendedDTraceProbes = false >> {product} >> >> bool JavaMonitorsInStackTrace = true >> {product} >> >> intx MaxJavaStackTraceDepth = 1024 >> {product} >> >> bool OmitStackTraceInFastThrow = true >> {product} >> >> bool StackTraceInThrowable = true >> {product} >> >> bool TraceBiasedLocking = false >> {product} >> >> bool TraceClassLoading = false >> {product rw} >> >> bool TraceClassLoadingPreorder = false >> {product} >> >> bool TraceClassResolution = false >> {product} >> >> bool TraceClassUnloading = false >> {product rw} >> >> bool TraceDynamicGCThreads = false >> {product} >> >> bool TraceGen0Time = false >> {product} >> >> bool TraceGen1Time = false >> {product} >> >> ccstr TraceJVMTI = >> {product} >> >> bool TraceLoaderConstraints = false >> {product rw} >> >> bool TraceMetadataHumongousAllocation = false >> {product} >> >> bool TraceMonitorInflation = false >> {product} >> >> bool TraceParallelOldGCTasks = false >> {product} >> >> intx TraceRedefineClasses = 0 >> {product} >> >> bool TraceSafepointCleanupTime = false >> {product} >> >> bool TraceSuspendWaitFailures = false >> {product} > From magnus.ihse.bursie at oracle.com Tue Feb 10 14:23:41 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 10 Feb 2015 15:23:41 +0100 Subject: RFR: JDK-8072842 Add support for building native JTReg tests Message-ID: <54DA146D.3060904@oracle.com> Here is an addition to the build system, that will compile native libraries and executables and make them available for JTReg tests written in Java. This patch is the result of the work (in serial, mostly) of Staffan Larsen, David Simms and me. (And possible more that I don't know about.) In it current form, the patch only provides the framework on which to attach real tests. To prove the concept, some initial dummy tests are present. These are supposed to be removed as soon as real tests starts to propagate into the jdk and hotspot jtreg test suites. The behavior is based on the following design: For directories with native jtreg compilation enabled, the build system searches for native files prefixed with either "lib" or "exe", and compiles a free-standing library or an executable, respectively, for each such file. Since all compiled files are placed in a single directory (this is currently a requirement from the jtreg native support), there is the additional requirement that all files have unique names. My personal opinion is that a better long-term approach is to compile all tests into a single library, if possible. (I realize some tests need to be separate to test library loading, etc.) For that to work, however, JTReg needs to be changed. The build framework in the patch is designed in such a way that it will be easy to add compilation to a common library in the future, if that restriction is lifted from JTReg. This patch also lays the foundation for building additional tests, not only native jtreg tests, by the build system in the future. For instance, it codifies the suggested correspondence between make targets, intermediate test output and test image final build results. With the on-going test co-location project, we expect a stream of tests to be added to the build system in the future, and we hope this project can serve as an example of a suitable way of integration. The patch modifies hotspot code, but it's mostly due to the addition of the new dummy tests. My preference would be to integrate this patch via jdk9-dev, since it modifies the build system most of all, but I'm open for discussion. Bug: https://bugs.openjdk.java.net/browse/JDK-8072842 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8072842-build-native-jtreg-tests/webrev.01 /Magnus From staffan.larsen at oracle.com Tue Feb 10 15:10:05 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 10 Feb 2015 16:10:05 +0100 Subject: RFR: JDK-8072842 Add support for building native JTReg tests In-Reply-To: <54DA146D.3060904@oracle.com> References: <54DA146D.3060904@oracle.com> Message-ID: > On 10 feb 2015, at 15:23, Magnus Ihse Bursie wrote: > > Here is an addition to the build system, that will compile native libraries and executables and make them available for JTReg tests written in Java. > > This patch is the result of the work (in serial, mostly) of Staffan Larsen, David Simms and me. (And possible more that I don't know about.) > > In it current form, the patch only provides the framework on which to attach real tests. To prove the concept, some initial dummy tests are present. These are supposed to be removed as soon as real tests starts to propagate into the jdk and hotspot jtreg test suites. > > The behavior is based on the following design: For directories with native jtreg compilation enabled, the build system searches for native files prefixed with either "lib" or "exe", and compiles a free-standing library or an executable, respectively, for each such file. Since all compiled files are placed in a single directory (this is currently a requirement from the jtreg native support), there is the additional requirement that all files have unique names. > > My personal opinion is that a better long-term approach is to compile all tests into a single library, if possible. (I realize some tests need to be separate to test library loading, etc.) For that to work, however, JTReg needs to be changed. The build framework in the patch is designed in such a way that it will be easy to add compilation to a common library in the future, if that restriction is lifted from JTReg. To clarify: The restriction in jtreg is that all tests are loaded in separate class loaders (when running in samevm mode). A native library can only be loaded in one class loader at a time. So if two tests tries to load the same library we get errors. It would be possible to change this if samevm mode is removed from jtreg. /Staffan > > This patch also lays the foundation for building additional tests, not only native jtreg tests, by the build system in the future. For instance, it codifies the suggested correspondence between make targets, intermediate test output and test image final build results. With the on-going test co-location project, we expect a stream of tests to be added to the build system in the future, and we hope this project can serve as an example of a suitable way of integration. > > The patch modifies hotspot code, but it's mostly due to the addition of the new dummy tests. My preference would be to integrate this patch via jdk9-dev, since it modifies the build system most of all, but I'm open for discussion. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8072842 > WebRev: http://cr.openjdk.java.net/~ihse/JDK-8072842-build-native-jtreg-tests/webrev.01 > > /Magnus From magnus.ihse.bursie at oracle.com Tue Feb 10 15:25:02 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 10 Feb 2015 16:25:02 +0100 Subject: RFR: JDK-8072842 Add support for building native JTReg tests In-Reply-To: References: <54DA146D.3060904@oracle.com> Message-ID: <4A2737F1-60D1-4C0A-9D56-10A2C1BA661F@oracle.com> > 10 feb 2015 kl. 16:10 skrev Staffan Larsen : > > >> On 10 feb 2015, at 15:23, Magnus Ihse Bursie wrote: >> >> Here is an addition to the build system, that will compile native libraries and executables and make them available for JTReg tests written in Java. >> >> This patch is the result of the work (in serial, mostly) of Staffan Larsen, David Simms and me. (And possible more that I don't know about.) >> >> In it current form, the patch only provides the framework on which to attach real tests. To prove the concept, some initial dummy tests are present. These are supposed to be removed as soon as real tests starts to propagate into the jdk and hotspot jtreg test suites. >> >> The behavior is based on the following design: For directories with native jtreg compilation enabled, the build system searches for native files prefixed with either "lib" or "exe", and compiles a free-standing library or an executable, respectively, for each such file. Since all compiled files are placed in a single directory (this is currently a requirement from the jtreg native support), there is the additional requirement that all files have unique names. >> >> My personal opinion is that a better long-term approach is to compile all tests into a single library, if possible. (I realize some tests need to be separate to test library loading, etc.) For that to work, however, JTReg needs to be changed. The build framework in the patch is designed in such a way that it will be easy to add compilation to a common library in the future, if that restriction is lifted from JTReg. > > To clarify: The restriction in jtreg is that all tests are loaded in separate class loaders (when running in samevm mode). A native library can only be loaded in one class loader at a time. So if two tests tries to load the same library we get errors. It would be possible to change this if samevm mode is removed from jtreg. I thought the problem was that we try to load the same library multiple times by different classloaders, and that the solution was to load the library only once, e.g. by the jtreg framework before launching samevm tests. However, if the library has to be loaded by the class loader in which the test executes, this will not work. :( Nevertheless, this discussion is tangential to the current review. If it is possible to add a singe-library approach to jtreg without sacrificing functionality, I believe that is a good thing, and this patch supports such an extension. If not, the current patch works anyway. /Magnus > > /Staffan > >> >> This patch also lays the foundation for building additional tests, not only native jtreg tests, by the build system in the future. For instance, it codifies the suggested correspondence between make targets, intermediate test output and test image final build results. With the on-going test co-location project, we expect a stream of tests to be added to the build system in the future, and we hope this project can serve as an example of a suitable way of integration. >> >> The patch modifies hotspot code, but it's mostly due to the addition of the new dummy tests. My preference would be to integrate this patch via jdk9-dev, since it modifies the build system most of all, but I'm open for discussion. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8072842 >> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8072842-build-native-jtreg-tests/webrev.01 >> >> /Magnus > From goetz.lindenmaier at sap.com Tue Feb 10 15:43:09 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 10 Feb 2015 15:43:09 +0000 Subject: RFR(S): 8071822: [TEST_BUG] Adapt collectorPolicy internal tests to support 64K pages Message-ID: <4295855A5C1DE049A61835A1887419CC2CF94BE5@DEWDFEMB12A.global.corp.sap> Hi, could someone please have a look at this change? It's really not that big. GC-folks maybe? Thanks, Goetz. From: Lindenmaier, Goetz Sent: Freitag, 30. Januar 2015 10:36 To: hotspot-dev Source Developers Subject: RFR(S): 8071822: [TEST_BUG] Adapt collectorPolicy internal tests to support 64K pages Hi, this fixes a final problem with 64-bit page size in the jtreg tests. It addresses the internal VM tests of the collector policies. Those tests set a row of fixed flag values, and one special value to test. Then they call the heap ergonomics and check the expected result of the special value. With 64K page size, the heap ergonomics adapt more values, breaking the tests. Wrt. the adapted flag values the tests are correct though. This change makes the expected values depend on the adapted flags, and the tests pass. They only depend on adapted flags that are not subject of the corresponding test. Please review this test. I please need a sponsor. http://cr.openjdk.java.net/~goetz/webrevs/8071822-jtregColPol/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8071822 Best regards, Goetz. From david.holmes at oracle.com Wed Feb 11 01:35:10 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 11 Feb 2015 11:35:10 +1000 Subject: RFR: JDK-8072842 Add support for building native JTReg tests In-Reply-To: <54DA146D.3060904@oracle.com> References: <54DA146D.3060904@oracle.com> Message-ID: <54DAB1CE.70506@oracle.com> Hi Magnus, On 11/02/2015 12:23 AM, Magnus Ihse Bursie wrote: > Here is an addition to the build system, that will compile native > libraries and executables and make them available for JTReg tests > written in Java. Sorry I'm missing the basics here: when does this compilation take place? As part of a normal build? Where will the build artifacts go? Thanks, David H. > This patch is the result of the work (in serial, mostly) of Staffan > Larsen, David Simms and me. (And possible more that I don't know about.) > > In it current form, the patch only provides the framework on which to > attach real tests. To prove the concept, some initial dummy tests are > present. These are supposed to be removed as soon as real tests starts > to propagate into the jdk and hotspot jtreg test suites. > > The behavior is based on the following design: For directories with > native jtreg compilation enabled, the build system searches for native > files prefixed with either "lib" or "exe", and compiles a free-standing > library or an executable, respectively, for each such file. Since all > compiled files are placed in a single directory (this is currently a > requirement from the jtreg native support), there is the additional > requirement that all files have unique names. > > My personal opinion is that a better long-term approach is to compile > all tests into a single library, if possible. (I realize some tests need > to be separate to test library loading, etc.) For that to work, however, > JTReg needs to be changed. The build framework in the patch is designed > in such a way that it will be easy to add compilation to a common > library in the future, if that restriction is lifted from JTReg. > > This patch also lays the foundation for building additional tests, not > only native jtreg tests, by the build system in the future. For > instance, it codifies the suggested correspondence between make targets, > intermediate test output and test image final build results. With the > on-going test co-location project, we expect a stream of tests to be > added to the build system in the future, and we hope this project can > serve as an example of a suitable way of integration. > > The patch modifies hotspot code, but it's mostly due to the addition of > the new dummy tests. My preference would be to integrate this patch via > jdk9-dev, since it modifies the build system most of all, but I'm open > for discussion. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8072842 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8072842-build-native-jtreg-tests/webrev.01 > > > /Magnus From magnus.ihse.bursie at oracle.com Wed Feb 11 08:09:21 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 11 Feb 2015 09:09:21 +0100 Subject: RFR: JDK-8072842 Add support for building native JTReg tests In-Reply-To: <54DAB1CE.70506@oracle.com> References: <54DA146D.3060904@oracle.com> <54DAB1CE.70506@oracle.com> Message-ID: <54DB0E31.3010201@oracle.com> On 2015-02-11 02:35, David Holmes wrote: > Hi Magnus, > > On 11/02/2015 12:23 AM, Magnus Ihse Bursie wrote: >> Here is an addition to the build system, that will compile native >> libraries and executables and make them available for JTReg tests >> written in Java. > > Sorry I'm missing the basics here: when does this compilation take > place? As part of a normal build? Where will the build artifacts go? This is the first application of the new test-image/product-images separation we discussed previously. :) These tests are built as part of the "test-image" target. (Actually, they are built by individual rules like build-test-jdk-jtreg-native, and the relevant parts are put into the test image by test-image-jdk-jtreg-native, which test-image depends on.) The test-image target, as we discussed earlier, are built as part of "all" or "all-images", but not the old "images" or "jdk" targets. Also, the "test" target depends on "test-image", so you can actually start off a complete build by specifying just what tests you want to run. ("test driven" from a makefile point of view :-)) The build artifacts go into the new test image, in build/$BUILD/images/test, which hitherto has only contained a placeholder. For Oracle engineers: This test image is built by default by JPRT, and some of the changes in jprt.properties allow JPRT to know to depend on that test image to run tests. /Magnus > > Thanks, > David H. > >> This patch is the result of the work (in serial, mostly) of Staffan >> Larsen, David Simms and me. (And possible more that I don't know about.) >> >> In it current form, the patch only provides the framework on which to >> attach real tests. To prove the concept, some initial dummy tests are >> present. These are supposed to be removed as soon as real tests starts >> to propagate into the jdk and hotspot jtreg test suites. >> >> The behavior is based on the following design: For directories with >> native jtreg compilation enabled, the build system searches for native >> files prefixed with either "lib" or "exe", and compiles a free-standing >> library or an executable, respectively, for each such file. Since all >> compiled files are placed in a single directory (this is currently a >> requirement from the jtreg native support), there is the additional >> requirement that all files have unique names. >> >> My personal opinion is that a better long-term approach is to compile >> all tests into a single library, if possible. (I realize some tests need >> to be separate to test library loading, etc.) For that to work, however, >> JTReg needs to be changed. The build framework in the patch is designed >> in such a way that it will be easy to add compilation to a common >> library in the future, if that restriction is lifted from JTReg. >> >> This patch also lays the foundation for building additional tests, not >> only native jtreg tests, by the build system in the future. For >> instance, it codifies the suggested correspondence between make targets, >> intermediate test output and test image final build results. With the >> on-going test co-location project, we expect a stream of tests to be >> added to the build system in the future, and we hope this project can >> serve as an example of a suitable way of integration. >> >> The patch modifies hotspot code, but it's mostly due to the addition of >> the new dummy tests. My preference would be to integrate this patch via >> jdk9-dev, since it modifies the build system most of all, but I'm open >> for discussion. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8072842 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8072842-build-native-jtreg-tests/webrev.01 >> >> >> >> /Magnus From david.holmes at oracle.com Wed Feb 11 08:23:17 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 11 Feb 2015 18:23:17 +1000 Subject: RFR: JDK-8072842 Add support for building native JTReg tests In-Reply-To: <54DB0E31.3010201@oracle.com> References: <54DA146D.3060904@oracle.com> <54DAB1CE.70506@oracle.com> <54DB0E31.3010201@oracle.com> Message-ID: <54DB1175.6030700@oracle.com> On 11/02/2015 6:09 PM, Magnus Ihse Bursie wrote: > On 2015-02-11 02:35, David Holmes wrote: >> Hi Magnus, >> >> On 11/02/2015 12:23 AM, Magnus Ihse Bursie wrote: >>> Here is an addition to the build system, that will compile native >>> libraries and executables and make them available for JTReg tests >>> written in Java. >> >> Sorry I'm missing the basics here: when does this compilation take >> place? As part of a normal build? Where will the build artifacts go? > > This is the first application of the new test-image/product-images > separation we discussed previously. :) > > These tests are built as part of the "test-image" target. (Actually, > they are built by individual rules like build-test-jdk-jtreg-native, and > the relevant parts are put into the test image by > test-image-jdk-jtreg-native, which test-image depends on.) Okay so if I just cd into hotspot/test and use the Makefile to try and run some jtreg tests it looks to me that it will define an invalid -nativepath David ----- > The test-image target, as we discussed earlier, are built as part of > "all" or "all-images", but not the old "images" or "jdk" targets. Also, > the "test" target depends on "test-image", so you can actually start off > a complete build by specifying just what tests you want to run. ("test > driven" from a makefile point of view :-)) > > The build artifacts go into the new test image, in > build/$BUILD/images/test, which hitherto has only contained a > placeholder. For Oracle engineers: This test image is built by default > by JPRT, and some of the changes in jprt.properties allow JPRT to know > to depend on that test image to run tests. > > /Magnus > >> >> Thanks, >> David H. >> >>> This patch is the result of the work (in serial, mostly) of Staffan >>> Larsen, David Simms and me. (And possible more that I don't know about.) >>> >>> In it current form, the patch only provides the framework on which to >>> attach real tests. To prove the concept, some initial dummy tests are >>> present. These are supposed to be removed as soon as real tests starts >>> to propagate into the jdk and hotspot jtreg test suites. >>> >>> The behavior is based on the following design: For directories with >>> native jtreg compilation enabled, the build system searches for native >>> files prefixed with either "lib" or "exe", and compiles a free-standing >>> library or an executable, respectively, for each such file. Since all >>> compiled files are placed in a single directory (this is currently a >>> requirement from the jtreg native support), there is the additional >>> requirement that all files have unique names. >>> >>> My personal opinion is that a better long-term approach is to compile >>> all tests into a single library, if possible. (I realize some tests need >>> to be separate to test library loading, etc.) For that to work, however, >>> JTReg needs to be changed. The build framework in the patch is designed >>> in such a way that it will be easy to add compilation to a common >>> library in the future, if that restriction is lifted from JTReg. >>> >>> This patch also lays the foundation for building additional tests, not >>> only native jtreg tests, by the build system in the future. For >>> instance, it codifies the suggested correspondence between make targets, >>> intermediate test output and test image final build results. With the >>> on-going test co-location project, we expect a stream of tests to be >>> added to the build system in the future, and we hope this project can >>> serve as an example of a suitable way of integration. >>> >>> The patch modifies hotspot code, but it's mostly due to the addition of >>> the new dummy tests. My preference would be to integrate this patch via >>> jdk9-dev, since it modifies the build system most of all, but I'm open >>> for discussion. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8072842 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8072842-build-native-jtreg-tests/webrev.01 >>> >>> >>> >>> /Magnus > From magnus.ihse.bursie at oracle.com Wed Feb 11 08:27:09 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 11 Feb 2015 09:27:09 +0100 Subject: RFR: JDK-8072842 Add support for building native JTReg tests In-Reply-To: <54DB1175.6030700@oracle.com> References: <54DA146D.3060904@oracle.com> <54DAB1CE.70506@oracle.com> <54DB0E31.3010201@oracle.com> <54DB1175.6030700@oracle.com> Message-ID: <54DB125D.2070706@oracle.com> On 2015-02-11 09:23, David Holmes wrote: > On 11/02/2015 6:09 PM, Magnus Ihse Bursie wrote: >> On 2015-02-11 02:35, David Holmes wrote: >>> Hi Magnus, >>> >>> On 11/02/2015 12:23 AM, Magnus Ihse Bursie wrote: >>>> Here is an addition to the build system, that will compile native >>>> libraries and executables and make them available for JTReg tests >>>> written in Java. >>> >>> Sorry I'm missing the basics here: when does this compilation take >>> place? As part of a normal build? Where will the build artifacts go? >> >> This is the first application of the new test-image/product-images >> separation we discussed previously. :) >> >> These tests are built as part of the "test-image" target. (Actually, >> they are built by individual rules like build-test-jdk-jtreg-native, and >> the relevant parts are put into the test image by >> test-image-jdk-jtreg-native, which test-image depends on.) > > Okay so if I just cd into hotspot/test and use the Makefile to try and > run some jtreg tests it looks to me that it will define an invalid > -nativepath I'm not sure if that is a supported use case. David or Staffan will have to answer to that. I have not tested that, only the "whole forest" approach. /Magnus From staffan.larsen at oracle.com Wed Feb 11 08:34:37 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 11 Feb 2015 09:34:37 +0100 Subject: RFR: JDK-8072842 Add support for building native JTReg tests In-Reply-To: <54DB125D.2070706@oracle.com> References: <54DA146D.3060904@oracle.com> <54DAB1CE.70506@oracle.com> <54DB0E31.3010201@oracle.com> <54DB1175.6030700@oracle.com> <54DB125D.2070706@oracle.com> Message-ID: > On 11 feb 2015, at 09:27, Magnus Ihse Bursie wrote: > > On 2015-02-11 09:23, David Holmes wrote: >> On 11/02/2015 6:09 PM, Magnus Ihse Bursie wrote: >>> On 2015-02-11 02:35, David Holmes wrote: >>>> Hi Magnus, >>>> >>>> On 11/02/2015 12:23 AM, Magnus Ihse Bursie wrote: >>>>> Here is an addition to the build system, that will compile native >>>>> libraries and executables and make them available for JTReg tests >>>>> written in Java. >>>> >>>> Sorry I'm missing the basics here: when does this compilation take >>>> place? As part of a normal build? Where will the build artifacts go? >>> >>> This is the first application of the new test-image/product-images >>> separation we discussed previously. :) >>> >>> These tests are built as part of the "test-image" target. (Actually, >>> they are built by individual rules like build-test-jdk-jtreg-native, and >>> the relevant parts are put into the test image by >>> test-image-jdk-jtreg-native, which test-image depends on.) >> >> Okay so if I just cd into hotspot/test and use the Makefile to try and run some jtreg tests it looks to me that it will define an invalid -nativepath > > I'm not sure if that is a supported use case. David or Staffan will have to answer to that. I have not tested that, only the "whole forest" approach. I?ve never done that. I?m always running all make commands from the top level. Is there a problem with that? /Staffan > > /Magnus From david.holmes at oracle.com Wed Feb 11 08:39:04 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 11 Feb 2015 18:39:04 +1000 Subject: RFR: JDK-8072842 Add support for building native JTReg tests In-Reply-To: References: <54DA146D.3060904@oracle.com> <54DAB1CE.70506@oracle.com> <54DB0E31.3010201@oracle.com> <54DB1175.6030700@oracle.com> <54DB125D.2070706@oracle.com> Message-ID: <54DB1528.4030708@oracle.com> On 11/02/2015 6:34 PM, Staffan Larsen wrote: > >> On 11 feb 2015, at 09:27, Magnus Ihse Bursie >> > >> wrote: >> >> On 2015-02-11 09:23, David Holmes wrote: >>> On 11/02/2015 6:09 PM, Magnus Ihse Bursie wrote: >>>> On 2015-02-11 02:35, David Holmes wrote: >>>>> Hi Magnus, >>>>> >>>>> On 11/02/2015 12:23 AM, Magnus Ihse Bursie wrote: >>>>>> Here is an addition to the build system, that will compile native >>>>>> libraries and executables and make them available for JTReg tests >>>>>> written in Java. >>>>> >>>>> Sorry I'm missing the basics here: when does this compilation take >>>>> place? As part of a normal build? Where will the build artifacts go? >>>> >>>> This is the first application of the new test-image/product-images >>>> separation we discussed previously. :) >>>> >>>> These tests are built as part of the "test-image" target. (Actually, >>>> they are built by individual rules like build-test-jdk-jtreg-native, and >>>> the relevant parts are put into the test image by >>>> test-image-jdk-jtreg-native, which test-image depends on.) >>> >>> Okay so if I just cd into hotspot/test and use the Makefile to try >>> and run some jtreg tests it looks to me that it will define an >>> invalid -nativepath >> >> I'm not sure if that is a supported use case. David or Staffan will >> have to answer to that. I have not tested that, only the "whole >> forest" approach. > > I?ve never done that. I?m always running all make commands from the top > level. Is there a problem with that? I must confess I also haven't done that - though I often run jtreg directly from there. Other hotspot engineers may use it. If nothing else it would be a way to test out what you expect JPRT to be running. But perhaps we just don't add the -nativepath component if TESTNATIVE_DIR remains unset? Cheers, David > /Staffan > >> >> /Magnus > From goetz.lindenmaier at sap.com Wed Feb 11 08:45:41 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 11 Feb 2015 08:45:41 +0000 Subject: RFR(S): 8071822: [TEST_BUG] Adapt collectorPolicy internal tests to support 64K pages Message-ID: <4295855A5C1DE049A61835A1887419CC2CF94DC9@DEWDFEMB12A.global.corp.sap> Hi, maybe my explanations to this change are too short to easily understand it. This concerns jtreg test sanity/ExecuteInternalVMTests.java. The error is ... Running test: TestNewSize_test() # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/collectorPolicy.cpp:1015 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/sapmnt/home1/d045726/oJ/aarch-hs-comp/src/share/vm/memory/collectorPolicy.cpp:1015), pid=30500, tid=4398080324160 # assert(msp.initial_young_size() == expected) failed: 44695552 != 34930688 I also added some explanations in the bug. Does this help? Thanks and best regards, Goetz. From: Lindenmaier, Goetz Sent: Dienstag, 10. Februar 2015 16:43 To: 'hotspot-dev Source Developers'; hotspot-gc-dev at openjdk.java.net Subject: RE: RFR(S): 8071822: [TEST_BUG] Adapt collectorPolicy internal tests to support 64K pages Hi, could someone please have a look at this change? It's really not that big. GC-folks maybe? Thanks, Goetz. From: Lindenmaier, Goetz Sent: Freitag, 30. Januar 2015 10:36 To: hotspot-dev Source Developers Subject: RFR(S): 8071822: [TEST_BUG] Adapt collectorPolicy internal tests to support 64K pages Hi, this fixes a final problem with 64-bit page size in the jtreg tests. It addresses the internal VM tests of the collector policies. Those tests set a row of fixed flag values, and one special value to test. Then they call the heap ergonomics and check the expected result of the special value. With 64K page size, the heap ergonomics adapt more values, breaking the tests. Wrt. the adapted flag values the tests are correct though. This change makes the expected values depend on the adapted flags, and the tests pass. They only depend on adapted flags that are not subject of the corresponding test. Please review this test. I please need a sponsor. http://cr.openjdk.java.net/~goetz/webrevs/8071822-jtregColPol/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8071822 Best regards, Goetz. From erik.joelsson at oracle.com Wed Feb 11 09:23:34 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 11 Feb 2015 10:23:34 +0100 Subject: RFR: JDK-8072904: building jdk9 with jdk9 boot jdk can cause failure or incorrect results Message-ID: <54DB1F96.7080602@oracle.com> Hello, Please review this change to how javah is run on sa classes. Since the sa classes in JDK 9 are now in a module instead of sa-jdi.jar, they are (at least currently) available from the default bootclasspath. This means that just setting -classpath to javah will not properly override the versions of the classes found in the boot jdk with the versions currently being built. The fix is to change -classpath with -Xbootclasspath/p:. Bug: https://bugs.openjdk.java.net/browse/JDK-8072904 Webrev: http://cr.openjdk.java.net/~erikj/8072904/webrev.hotspot.01/ Planning to push this through jdk9/hs-rt. /Erik From david.holmes at oracle.com Wed Feb 11 09:53:37 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 11 Feb 2015 19:53:37 +1000 Subject: RFR: JDK-8072904: building jdk9 with jdk9 boot jdk can cause failure or incorrect results In-Reply-To: <54DB1F96.7080602@oracle.com> References: <54DB1F96.7080602@oracle.com> Message-ID: <54DB26A1.3030906@oracle.com> Hi Erik, On 11/02/2015 7:23 PM, Erik Joelsson wrote: > Hello, > > Please review this change to how javah is run on sa classes. Since the > sa classes in JDK 9 are now in a module instead of sa-jdi.jar, they are > (at least currently) available from the default bootclasspath. This > means that just setting -classpath to javah will not properly override > the versions of the classes found in the boot jdk with the versions > currently being built. The fix is to change -classpath with > -Xbootclasspath/p:. Seems like a temporary workaround. javah should have a way to indicate which class to process without assuming it comes from the JVM used to run javah. Also putting what was sa-jdi.jar on the bootclasspath seems somewhat misplaced - these aren't "boot" classes. > Bug: https://bugs.openjdk.java.net/browse/JDK-8072904 > Webrev: http://cr.openjdk.java.net/~erikj/8072904/webrev.hotspot.01/ Were are the changes for all the other (non-linux) platforms? :) David > Planning to push this through jdk9/hs-rt. > > /Erik From staffan.larsen at oracle.com Wed Feb 11 10:36:15 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 11 Feb 2015 11:36:15 +0100 Subject: RFR: JDK-8072842 Add support for building native JTReg tests In-Reply-To: <54DB1528.4030708@oracle.com> References: <54DA146D.3060904@oracle.com> <54DAB1CE.70506@oracle.com> <54DB0E31.3010201@oracle.com> <54DB1175.6030700@oracle.com> <54DB125D.2070706@oracle.com> <54DB1528.4030708@oracle.com> Message-ID: <324EF37C-3FD2-4B8A-A509-D7315889D8DE@oracle.com> > On 11 feb 2015, at 09:39, David Holmes wrote: > > On 11/02/2015 6:34 PM, Staffan Larsen wrote: >> >>> On 11 feb 2015, at 09:27, Magnus Ihse Bursie >>> > >>> wrote: >>> >>> On 2015-02-11 09:23, David Holmes wrote: >>>> On 11/02/2015 6:09 PM, Magnus Ihse Bursie wrote: >>>>> On 2015-02-11 02:35, David Holmes wrote: >>>>>> Hi Magnus, >>>>>> >>>>>> On 11/02/2015 12:23 AM, Magnus Ihse Bursie wrote: >>>>>>> Here is an addition to the build system, that will compile native >>>>>>> libraries and executables and make them available for JTReg tests >>>>>>> written in Java. >>>>>> >>>>>> Sorry I'm missing the basics here: when does this compilation take >>>>>> place? As part of a normal build? Where will the build artifacts go? >>>>> >>>>> This is the first application of the new test-image/product-images >>>>> separation we discussed previously. :) >>>>> >>>>> These tests are built as part of the "test-image" target. (Actually, >>>>> they are built by individual rules like build-test-jdk-jtreg-native, and >>>>> the relevant parts are put into the test image by >>>>> test-image-jdk-jtreg-native, which test-image depends on.) >>>> >>>> Okay so if I just cd into hotspot/test and use the Makefile to try >>>> and run some jtreg tests it looks to me that it will define an >>>> invalid -nativepath >>> >>> I'm not sure if that is a supported use case. David or Staffan will >>> have to answer to that. I have not tested that, only the "whole >>> forest" approach. >> >> I?ve never done that. I?m always running all make commands from the top >> level. Is there a problem with that? > > I must confess I also haven't done that - though I often run jtreg directly from there. Other hotspot engineers may use it. If nothing else it would be a way to test out what you expect JPRT to be running. > > But perhaps we just don't add the -nativepath component if TESTNATIVE_DIR remains unset? Not adding -nativepath or adding it with an empty path will lead to the same errors I think: tests that need native code will fail. So it does not really matter. /Staffan > > Cheers, > David > >> /Staffan >> >>> >>> /Magnus >> From david.holmes at oracle.com Wed Feb 11 11:15:14 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 11 Feb 2015 21:15:14 +1000 Subject: RFR: JDK-8072842 Add support for building native JTReg tests In-Reply-To: <324EF37C-3FD2-4B8A-A509-D7315889D8DE@oracle.com> References: <54DA146D.3060904@oracle.com> <54DAB1CE.70506@oracle.com> <54DB0E31.3010201@oracle.com> <54DB1175.6030700@oracle.com> <54DB125D.2070706@oracle.com> <54DB1528.4030708@oracle.com> <324EF37C-3FD2-4B8A-A509-D7315889D8DE@oracle.com> Message-ID: <54DB39C2.5010607@oracle.com> On 11/02/2015 8:36 PM, Staffan Larsen wrote: > >> On 11 feb 2015, at 09:39, David Holmes wrote: >> >> On 11/02/2015 6:34 PM, Staffan Larsen wrote: >>> >>>> On 11 feb 2015, at 09:27, Magnus Ihse Bursie >>>> > >>>> wrote: >>>> >>>> On 2015-02-11 09:23, David Holmes wrote: >>>>> On 11/02/2015 6:09 PM, Magnus Ihse Bursie wrote: >>>>>> On 2015-02-11 02:35, David Holmes wrote: >>>>>>> Hi Magnus, >>>>>>> >>>>>>> On 11/02/2015 12:23 AM, Magnus Ihse Bursie wrote: >>>>>>>> Here is an addition to the build system, that will compile native >>>>>>>> libraries and executables and make them available for JTReg tests >>>>>>>> written in Java. >>>>>>> >>>>>>> Sorry I'm missing the basics here: when does this compilation take >>>>>>> place? As part of a normal build? Where will the build artifacts go? >>>>>> >>>>>> This is the first application of the new test-image/product-images >>>>>> separation we discussed previously. :) >>>>>> >>>>>> These tests are built as part of the "test-image" target. (Actually, >>>>>> they are built by individual rules like build-test-jdk-jtreg-native, and >>>>>> the relevant parts are put into the test image by >>>>>> test-image-jdk-jtreg-native, which test-image depends on.) >>>>> >>>>> Okay so if I just cd into hotspot/test and use the Makefile to try >>>>> and run some jtreg tests it looks to me that it will define an >>>>> invalid -nativepath >>>> >>>> I'm not sure if that is a supported use case. David or Staffan will >>>> have to answer to that. I have not tested that, only the "whole >>>> forest" approach. >>> >>> I?ve never done that. I?m always running all make commands from the top >>> level. Is there a problem with that? >> >> I must confess I also haven't done that - though I often run jtreg directly from there. Other hotspot engineers may use it. If nothing else it would be a way to test out what you expect JPRT to be running. >> >> But perhaps we just don't add the -nativepath component if TESTNATIVE_DIR remains unset? > > Not adding -nativepath or adding it with an empty path will lead to the same errors I think: tests that need native code will fail. So it does not really matter. If you add it with an invalid path (won't be empty as the variable is only a prefix) then tests that don't need native code may also fail. Though I don't know how jtreg responds to a non-existent nativepath. David > /Staffan > >> >> Cheers, >> David >> >>> /Staffan >>> >>>> >>>> /Magnus >>> > From erik.joelsson at oracle.com Wed Feb 11 11:35:58 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 11 Feb 2015 12:35:58 +0100 Subject: RFR: JDK-8072904: building jdk9 with jdk9 boot jdk can cause failure or incorrect results In-Reply-To: <54DB26A1.3030906@oracle.com> References: <54DB1F96.7080602@oracle.com> <54DB26A1.3030906@oracle.com> Message-ID: <54DB3E9E.4030407@oracle.com> Hello, New webrev: http://cr.openjdk.java.net/~erikj/8072904/webrev.hotspot.02/ On 2015-02-11 10:53, David Holmes wrote: > Hi Erik, > > On 11/02/2015 7:23 PM, Erik Joelsson wrote: >> Hello, >> >> Please review this change to how javah is run on sa classes. Since the >> sa classes in JDK 9 are now in a module instead of sa-jdi.jar, they are >> (at least currently) available from the default bootclasspath. This >> means that just setting -classpath to javah will not properly override >> the versions of the classes found in the boot jdk with the versions >> currently being built. The fix is to change -classpath with >> -Xbootclasspath/p:. > > Seems like a temporary workaround. javah should have a way to indicate > which class to process without assuming it comes from the JVM used to > run javah. Also putting what was sa-jdi.jar on the bootclasspath seems > somewhat misplaced - these aren't "boot" classes. > It was also pointed out to me that -Xbootclasspath is not future proof. So instead I opted for a different solution, using the new javac flag -h and the @Native annotation to automatically generate header files during compilation. >> Bug: https://bugs.openjdk.java.net/browse/JDK-8072904 >> Webrev: http://cr.openjdk.java.net/~erikj/8072904/webrev.hotspot.01/ > > Were are the changes for all the other (non-linux) platforms? :) > Right, I forgot about that. *sigh* This time I made the changes in all the makefiles. /Erik From staffan.larsen at oracle.com Wed Feb 11 12:08:16 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 11 Feb 2015 13:08:16 +0100 Subject: RFR: JDK-8072842 Add support for building native JTReg tests In-Reply-To: <54DB39C2.5010607@oracle.com> References: <54DA146D.3060904@oracle.com> <54DAB1CE.70506@oracle.com> <54DB0E31.3010201@oracle.com> <54DB1175.6030700@oracle.com> <54DB125D.2070706@oracle.com> <54DB1528.4030708@oracle.com> <324EF37C-3FD2-4B8A-A509-D7315889D8DE@oracle.com> <54DB39C2.5010607@oracle.com> Message-ID: <31B825DC-DFD2-4EC2-81AD-9BF0FC3364CC@oracle.com> > On 11 feb 2015, at 12:15, David Holmes wrote: > > On 11/02/2015 8:36 PM, Staffan Larsen wrote: >> >>> On 11 feb 2015, at 09:39, David Holmes wrote: >>> >>> On 11/02/2015 6:34 PM, Staffan Larsen wrote: >>>> >>>>> On 11 feb 2015, at 09:27, Magnus Ihse Bursie >>>>> > >>>>> wrote: >>>>> >>>>> On 2015-02-11 09:23, David Holmes wrote: >>>>>> On 11/02/2015 6:09 PM, Magnus Ihse Bursie wrote: >>>>>>> On 2015-02-11 02:35, David Holmes wrote: >>>>>>>> Hi Magnus, >>>>>>>> >>>>>>>> On 11/02/2015 12:23 AM, Magnus Ihse Bursie wrote: >>>>>>>>> Here is an addition to the build system, that will compile native >>>>>>>>> libraries and executables and make them available for JTReg tests >>>>>>>>> written in Java. >>>>>>>> >>>>>>>> Sorry I'm missing the basics here: when does this compilation take >>>>>>>> place? As part of a normal build? Where will the build artifacts go? >>>>>>> >>>>>>> This is the first application of the new test-image/product-images >>>>>>> separation we discussed previously. :) >>>>>>> >>>>>>> These tests are built as part of the "test-image" target. (Actually, >>>>>>> they are built by individual rules like build-test-jdk-jtreg-native, and >>>>>>> the relevant parts are put into the test image by >>>>>>> test-image-jdk-jtreg-native, which test-image depends on.) >>>>>> >>>>>> Okay so if I just cd into hotspot/test and use the Makefile to try >>>>>> and run some jtreg tests it looks to me that it will define an >>>>>> invalid -nativepath >>>>> >>>>> I'm not sure if that is a supported use case. David or Staffan will >>>>> have to answer to that. I have not tested that, only the "whole >>>>> forest" approach. >>>> >>>> I?ve never done that. I?m always running all make commands from the top >>>> level. Is there a problem with that? >>> >>> I must confess I also haven't done that - though I often run jtreg directly from there. Other hotspot engineers may use it. If nothing else it would be a way to test out what you expect JPRT to be running. >>> >>> But perhaps we just don't add the -nativepath component if TESTNATIVE_DIR remains unset? >> >> Not adding -nativepath or adding it with an empty path will lead to the same errors I think: tests that need native code will fail. So it does not really matter. > > If you add it with an invalid path (won't be empty as the variable is only a prefix) then tests that don't need native code may also fail. Though I don't know how jtreg responds to a non-existent nativepath. You are right. Jtreg validates the that the path is a directory. So better not to specify it. /Staffan > > David > >> /Staffan >> >>> >>> Cheers, >>> David >>> >>>> /Staffan >>>> >>>>> >>>>> /Magnus From stefan.karlsson at oracle.com Wed Feb 11 12:38:14 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 11 Feb 2015 13:38:14 +0100 Subject: RFR: 8072911: Remove includes of oop.inline.hpp from .hpp files Message-ID: <54DB4D36.2050907@oracle.com> Hi all, Please, review this patch to fix our includes of oop.inline.hpp. http://cr.openjdk.java.net/~stefank/8072911/webrev.01 https://bugs.openjdk.java.net/browse/JDK-8072911 From the enhancement description: --- Our inline.hpp files should preferably only be included from .cpp files or other .inline.hpp files. When they are included in .hpp files, the include dependency of the implementation spreads to unrelated parts of the code base, and it's easy to get circular dependencies. This guide line is documented on: https://wiki.openjdk.java.net/display/HotSpot/StyleGuide#Files oop.inline.hpp is one of the more problematic files, and I propose a patch to get rid of all inclusions of oop.inline.hpp from other .hpp files. --- Summary of the code changes: oop.inline.hpp - Added to needed .cpp and .inline.hpp files. oop.inline2.hpp - This file isn't needed anymore and the contents have been moved to oop.inline.hpp. oop.hpp - Inlined klass_gap_offset_in_bytes in the hpp file, since it's currently used from a few hpp files. - Create non-inlined versions of is_instance checks, to be used in asserts in handles.hpp. - Added has_klass_gap to get rid of dependency against globals.hpp javaClasses.hpp - There were a couple of usages of klass.hpp that were moved out to javaClasses.cpp and a few that were moved to javaClasses.inline.hpp when it wasn't obvious if we needed to inline the functions or not. vmGCOperations.hpp - Moved the VM_GC_Operation destructor to the cpp file. collectedHeap.hpp - Moved print_on_error barrierSet.hpp - Moved the inline keyword from the hpp file to the inline.hpp file. cardTableModRefBS.hpp - Moved inline_write_ref_field to the inline.hpp file. objArrayOop.hpp - Moved obj_at to the inline.hpp file. graphKit.hpp - Moved byte_map_base_node to .cpp file, where it's used. - Added missing includes that were removed when oop.inline.hpp was removed from the hpp files. The patch has been tested with JPRT. Thanks, StefanK From erik.osterlund at lnu.se Wed Feb 11 14:32:57 2015 From: erik.osterlund at lnu.se (=?iso-8859-1?Q?Erik_=D6sterlund?=) Date: Wed, 11 Feb 2015 14:32:57 +0000 Subject: RFR: 7143664: Clean up OrderAccess implementations and usage References: <54C1EBD3.1000905@oracle.com> <54C1F3D8.5040507@oracle.com> <54C2C1EA.5020507@oracle.com> <54C87D16.40601@oracle.com> <54C9674C.2080600@oracle.com> <54D85E4F.5020305@oracle.com> Message-ID: Hi David, Thanks a lot for reviewing my changes! Sorry for the delay, had a few other things I had to take care of. On 09/02/15 07:14, David Holmes wrote: > On 29/01/2015 8:48 AM, David Holmes wrote: >> Updated webrev: >> >> http://cr.openjdk.java.net/~dholmes/7143664/webrev.v2/ > > First let me say that Erik and I had a lot of offline discussions about > this since he first proposed his reworking. My initial concern was > ensuring the model changes were appropriate as this is a complex area > and there can be different views of how things can/should be expressed. > As per the bug report I was aware of a number of issues with the > existing expression of semantics, but Erik showed me things were even > worse than I had thought :) :) > src/share/vm/runtime/orderAccess.hpp > > Minor nit: I would prefer the term "bound" rather than "joined" when > referring to load_acquire and store_release. Fixed. > In the implementation table I think "sparc" should be "sparc TSO". Fixed. > I still think we need to say something about C++ volatile and about > compiler barriers in general. How about something like: C++ volatile semantics prevent compiler re-ordering between volatile memory accesses. However, reordering between non-volatile and volatile memory accesses is in general undefined. For compiler reordering constraints taking non-volatile memory accesses into consideration, a compiler barrier has to be used instead. Note also that both volatile semantics and compiler barrier do not prevent hardware reordering. > src/os_cpu/bsd_x86/vm/orderAccess_bsd_x86.inline.hpp > src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp > > In OrderAccess::fence doesn't the existing asm already act as a compiler > barrier; and on uniprocessor we need neither compiler nor hardware > barriers; so isn't the compiler_barrier() redundant? I saw this was already clarified. But yeah, even uniprocessor systems have concurrency. Therefore I added compiler barriers to properly protect even uniprocessor systems, that could previously suffer from data races involving unlikely yet possible compiler reorderings and context switches. > > --- > > src/os_cpu/bsd_zero/vm/orderAccess_bsd_zero.inline.hpp > src/os_cpu/linux_zero/vm/orderAccess_linux_zero.inline.hpp > > No comments - The Zero folk will need to approve this change in terminology. I didn't like talking about "read" and "write" barriers as it says little about what it actually means. And I also didn't like defining things like storestore/storeload etc. in terms of acquire/release and read/write barriers because I think it's weird. ;) That's why I changed this. But if the previous terminology is preferred, I'm fine with changing that. > src/os_cpu/solaris_sparc/vm/orderAccess_solaris_sparc.inline.hpp > src/os_cpu/solaris_sparc/vm/solaris_sparc.il > > You've removed the GNU_SOURCE ifdefs which means the new code has to be > tested using gcc on Solaris. We don't officially support that platform > so I have no way to verify these particular changes. Previously solaris studio did not support inline asm syntax. So the solaris studio variant used .il assembly instead while the GNU_SOURCE variant used inline asm. But since this is nowadays supported by solaris studio too, I joined them into one. Not only because it's nicer to unify, but because I need the compiler barrier constraints that inline asm can give us. I don't know the compiler reordering constraints are guaranteed when calling external assembly. So better make it explicit and safe. > src/os_cpu/solaris_x86/vm/orderAccess_solaris_x86.inline.hpp > src/os_cpu/solaris_x86/vm/solaris_x86_32.il > src/os_cpu/solaris_x86/vm/solaris_x86_64.il > > I think it makes sense to use the same code here as the linux x86 > version. But as above can't verify this for gcc on Solaris; also query > about need for compiler_barrier() in fence(). Same goes here as above. Solaris studio used to not support inline asm. So I joined the variants relevant for correctness fixes. But of course, it would be possible to add the optimizations from x86 bsd/linux as well. But I wanted to keep optimizations out of this changeset as I think it is already a lot to review without the addition of new optimizations. So if you don't mind, I'd like to defer that until the correctness fixes are in place. > Do you have a reference to the MSVC volatile semantics? https://msdn.microsoft.com/en-us/library/12a04hfd(v=vs.100).aspx Release: "A write to a volatile object (volatile write) has Release semantics; a reference to a global or static object that occurs before a write to a volatile object in the instruction sequence will occur before that volatile write in the compiled binary." Acquire: "A read of a volatile object (volatile read) has Acquire semantics; a reference to a global or static object that occurs after a read of volatile memory in the instruction sequence will occur after that volatile read in the compiled binary." Should fit our model right for compiler reordering. > Not clear about the 32-bit versus 64-bit changes - mainly because I > don't know why they were different in the first place. Seems like x86_64 didn't have good support for inline asm syntax at some point. I don't know if this is still true today. It would be nice to know because I have seen fishy x86_64 implementations of a lot of atomic stuff as well, assuming lack of compiler support that might actually be available today. > Why are windows release_store_fence specializations different to linux > x86 versions? How do you mean they are different? To me they look quite equivalent. xchg is always implicitly locked on x86, and they both use xchg to get the wanted fence semantics. > Not clear about your change to the float version of release_store_fence: > a) do we need to change it? > b) given what we changed it to isn't that the default ? I didn't want to have default specializations of jfloat/jdouble equalling jint/jlong. I thought maybe some architecture might want to put it in different registers or something, making a default conversion to int/long maybe undesirable. So the default for jfloat/jdouble is to use acquire()/release() paired with an atomic memory access. So you have to explicitly specialize them to be the same as jint/jlong if wanted, which I believe is what is done in the code you refer to. If you think I'm paranoid about floats, I can of course make it a default behaviour to use jint/jlong even if it isn't explicit, in the same way I handled unsigned variants. Rule of thumb: The variants that need specialization are the ones that have overrides for OrderAccess::store/OrderAccess::load, the rest is handled automatically. Currently jdouble and jfloat are part of that and hence need explicit specialization, but if we want to generalize floats too, that's fine by me. So is it preferred to generalize jfloat/jdouble to equal jint/jlong? > General comment: copyright dates need updating in most, if not all, files. Fixed. Do we want a new webrev? (changed copyright headers and few words in comments) Thanks a lot for taking time to review these changes! /Erik From bengt.rutisson at oracle.com Wed Feb 11 15:51:49 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 11 Feb 2015 16:51:49 +0100 Subject: RFR: 8072911: Remove includes of oop.inline.hpp from .hpp files In-Reply-To: <54DB4D36.2050907@oracle.com> References: <54DB4D36.2050907@oracle.com> Message-ID: <54DB7A95.40807@oracle.com> Hi Stefan, Pretty difficult to review this type of change, but I think it looks good. I verified that no hpp files inlcude oop.inline.hpp after your change. Nice cleanup! One minor thing (not your code): In src/share/vm/oops/oop.hpp there is this comment: // type test operations (inlined in oop.inline.h) I think the comment should say oop.inline.hpp not just .h. Do you mind fixing this as part of this change too? Thanks, Bengt On 11/02/15 13:38, Stefan Karlsson wrote: > Hi all, > > Please, review this patch to fix our includes of oop.inline.hpp. > > http://cr.openjdk.java.net/~stefank/8072911/webrev.01 > https://bugs.openjdk.java.net/browse/JDK-8072911 > > > From the enhancement description: > --- > Our inline.hpp files should preferably only be included from .cpp > files or other .inline.hpp files. When they are included in .hpp > files, the include dependency of the implementation spreads to > unrelated parts of the code base, and it's easy to get circular > dependencies. > > This guide line is documented on: > https://wiki.openjdk.java.net/display/HotSpot/StyleGuide#Files > > oop.inline.hpp is one of the more problematic files, and I propose a > patch to get rid of all inclusions of oop.inline.hpp from other .hpp > files. > --- > > > Summary of the code changes: > > oop.inline.hpp > - Added to needed .cpp and .inline.hpp files. > > oop.inline2.hpp > - This file isn't needed anymore and the contents have been moved to > oop.inline.hpp. > > oop.hpp > - Inlined klass_gap_offset_in_bytes in the hpp file, since it's > currently used from a few hpp files. > > - Create non-inlined versions of is_instance checks, to be used in > asserts in handles.hpp. > > - Added has_klass_gap to get rid of dependency against globals.hpp > > javaClasses.hpp > - There were a couple of usages of klass.hpp that were moved out to > javaClasses.cpp and a few that were moved to javaClasses.inline.hpp > when it wasn't obvious if we needed to inline the functions or not. > > vmGCOperations.hpp > - Moved the VM_GC_Operation destructor to the cpp file. > > collectedHeap.hpp > - Moved print_on_error > > barrierSet.hpp > - Moved the inline keyword from the hpp file to the inline.hpp file. > > cardTableModRefBS.hpp > - Moved inline_write_ref_field to the inline.hpp file. > > objArrayOop.hpp > - Moved obj_at to the inline.hpp file. > > graphKit.hpp > - Moved byte_map_base_node to .cpp file, where it's used. > > > - Added missing includes that were removed when oop.inline.hpp was > removed from the hpp files. > > > The patch has been tested with JPRT. > > Thanks, > StefanK > From stefan.karlsson at oracle.com Wed Feb 11 15:55:14 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 11 Feb 2015 16:55:14 +0100 Subject: RFR: 8072911: Remove includes of oop.inline.hpp from .hpp files In-Reply-To: <54DB7A95.40807@oracle.com> References: <54DB4D36.2050907@oracle.com> <54DB7A95.40807@oracle.com> Message-ID: <54DB7B62.8030408@oracle.com> Hi Bengt, On 2015-02-11 16:51, Bengt Rutisson wrote: > > Hi Stefan, > > Pretty difficult to review this type of change, but I think it looks > good. I verified that no hpp files inlcude oop.inline.hpp after your > change. Nice cleanup! > > One minor thing (not your code): > > In src/share/vm/oops/oop.hpp there is this comment: > > // type test operations (inlined in oop.inline.h) > > I think the comment should say oop.inline.hpp not just .h. Do you mind > fixing this as part of this change too? Thanks for reviewing. I'll fix the comment. Thanks, StefanK > > Thanks, > Bengt > > > > On 11/02/15 13:38, Stefan Karlsson wrote: >> Hi all, >> >> Please, review this patch to fix our includes of oop.inline.hpp. >> >> http://cr.openjdk.java.net/~stefank/8072911/webrev.01 >> https://bugs.openjdk.java.net/browse/JDK-8072911 >> >> >> From the enhancement description: >> --- >> Our inline.hpp files should preferably only be included from .cpp >> files or other .inline.hpp files. When they are included in .hpp >> files, the include dependency of the implementation spreads to >> unrelated parts of the code base, and it's easy to get circular >> dependencies. >> >> This guide line is documented on: >> https://wiki.openjdk.java.net/display/HotSpot/StyleGuide#Files >> >> oop.inline.hpp is one of the more problematic files, and I propose a >> patch to get rid of all inclusions of oop.inline.hpp from other .hpp >> files. >> --- >> >> >> Summary of the code changes: >> >> oop.inline.hpp >> - Added to needed .cpp and .inline.hpp files. >> >> oop.inline2.hpp >> - This file isn't needed anymore and the contents have been moved to >> oop.inline.hpp. >> >> oop.hpp >> - Inlined klass_gap_offset_in_bytes in the hpp file, since it's >> currently used from a few hpp files. >> >> - Create non-inlined versions of is_instance checks, to be used in >> asserts in handles.hpp. >> >> - Added has_klass_gap to get rid of dependency against globals.hpp >> >> javaClasses.hpp >> - There were a couple of usages of klass.hpp that were moved out to >> javaClasses.cpp and a few that were moved to javaClasses.inline.hpp >> when it wasn't obvious if we needed to inline the functions or not. >> >> vmGCOperations.hpp >> - Moved the VM_GC_Operation destructor to the cpp file. >> >> collectedHeap.hpp >> - Moved print_on_error >> >> barrierSet.hpp >> - Moved the inline keyword from the hpp file to the inline.hpp file. >> >> cardTableModRefBS.hpp >> - Moved inline_write_ref_field to the inline.hpp file. >> >> objArrayOop.hpp >> - Moved obj_at to the inline.hpp file. >> >> graphKit.hpp >> - Moved byte_map_base_node to .cpp file, where it's used. >> >> >> - Added missing includes that were removed when oop.inline.hpp was >> removed from the hpp files. >> >> >> The patch has been tested with JPRT. >> >> Thanks, >> StefanK >> > From thomas.stuefe at gmail.com Wed Feb 11 16:37:46 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 11 Feb 2015 17:37:46 +0100 Subject: RFR(xxs): 8072935: Fix missing newline at end of file after 8067447 Message-ID: Hi, Linux build did break after 8067447, please review this tiny fix: https://bugs.openjdk.java.net/browse/JDK-8072935 http://cr.openjdk.java.net/~stuefe/webrevs/8072935/webrev.01/webrev/ Thank you! Kind Regards, Thomas From jesper.wilhelmsson at oracle.com Wed Feb 11 16:51:00 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 11 Feb 2015 17:51:00 +0100 Subject: RFR(xxs): 8072935: Fix missing newline at end of file after 8067447 In-Reply-To: References: Message-ID: <54DB8874.2050304@oracle.com> Looks good! /Jesper Thomas St?fe skrev den 11/2/15 17:37: > Hi, > > Linux build did break after 8067447, please review this tiny fix: > > https://bugs.openjdk.java.net/browse/JDK-8072935 > http://cr.openjdk.java.net/~stuefe/webrevs/8072935/webrev.01/webrev/ > > Thank you! > > Kind Regards, Thomas > From jesper.wilhelmsson at oracle.com Wed Feb 11 16:57:15 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 11 Feb 2015 17:57:15 +0100 Subject: RFR: 8072911: Remove includes of oop.inline.hpp from .hpp files In-Reply-To: <54DB7B62.8030408@oracle.com> References: <54DB4D36.2050907@oracle.com> <54DB7A95.40807@oracle.com> <54DB7B62.8030408@oracle.com> Message-ID: <54DB89EB.50701@oracle.com> Looks good! /Jesper Stefan Karlsson skrev den 11/2/15 16:55: > Hi Bengt, > > On 2015-02-11 16:51, Bengt Rutisson wrote: >> >> Hi Stefan, >> >> Pretty difficult to review this type of change, but I think it looks good. I >> verified that no hpp files inlcude oop.inline.hpp after your change. Nice >> cleanup! >> >> One minor thing (not your code): >> >> In src/share/vm/oops/oop.hpp there is this comment: >> >> // type test operations (inlined in oop.inline.h) >> >> I think the comment should say oop.inline.hpp not just .h. Do you mind fixing >> this as part of this change too? > > Thanks for reviewing. I'll fix the comment. > > Thanks, > StefanK > >> >> Thanks, >> Bengt >> >> >> >> On 11/02/15 13:38, Stefan Karlsson wrote: >>> Hi all, >>> >>> Please, review this patch to fix our includes of oop.inline.hpp. >>> >>> http://cr.openjdk.java.net/~stefank/8072911/webrev.01 >>> https://bugs.openjdk.java.net/browse/JDK-8072911 >>> >>> >>> From the enhancement description: >>> --- >>> Our inline.hpp files should preferably only be included from .cpp files or >>> other .inline.hpp files. When they are included in .hpp files, the include >>> dependency of the implementation spreads to unrelated parts of the code base, >>> and it's easy to get circular dependencies. >>> >>> This guide line is documented on: >>> https://wiki.openjdk.java.net/display/HotSpot/StyleGuide#Files >>> >>> oop.inline.hpp is one of the more problematic files, and I propose a patch to >>> get rid of all inclusions of oop.inline.hpp from other .hpp files. >>> --- >>> >>> >>> Summary of the code changes: >>> >>> oop.inline.hpp >>> - Added to needed .cpp and .inline.hpp files. >>> >>> oop.inline2.hpp >>> - This file isn't needed anymore and the contents have been moved to >>> oop.inline.hpp. >>> >>> oop.hpp >>> - Inlined klass_gap_offset_in_bytes in the hpp file, since it's currently >>> used from a few hpp files. >>> >>> - Create non-inlined versions of is_instance checks, to be used in asserts >>> in handles.hpp. >>> >>> - Added has_klass_gap to get rid of dependency against globals.hpp >>> >>> javaClasses.hpp >>> - There were a couple of usages of klass.hpp that were moved out to >>> javaClasses.cpp and a few that were moved to javaClasses.inline.hpp when it >>> wasn't obvious if we needed to inline the functions or not. >>> >>> vmGCOperations.hpp >>> - Moved the VM_GC_Operation destructor to the cpp file. >>> >>> collectedHeap.hpp >>> - Moved print_on_error >>> >>> barrierSet.hpp >>> - Moved the inline keyword from the hpp file to the inline.hpp file. >>> >>> cardTableModRefBS.hpp >>> - Moved inline_write_ref_field to the inline.hpp file. >>> >>> objArrayOop.hpp >>> - Moved obj_at to the inline.hpp file. >>> >>> graphKit.hpp >>> - Moved byte_map_base_node to .cpp file, where it's used. >>> >>> >>> - Added missing includes that were removed when oop.inline.hpp was removed >>> from the hpp files. >>> >>> >>> The patch has been tested with JPRT. >>> >>> Thanks, >>> StefanK >>> >> > From volker.simonis at gmail.com Wed Feb 11 17:56:10 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 11 Feb 2015 18:56:10 +0100 Subject: RFR: 8072911: Remove includes of oop.inline.hpp from .hpp files In-Reply-To: <54DB89EB.50701@oracle.com> References: <54DB4D36.2050907@oracle.com> <54DB7A95.40807@oracle.com> <54DB7B62.8030408@oracle.com> <54DB89EB.50701@oracle.com> Message-ID: Hi Stefan, thanks for doing this change and thanks for changing the ppc-files as well. Unfortunately there still seems to be an error if building on Linux/ppc64 without precompiled headers. Can you please wait a little until I'll send you the additional changes which are required before pushing this one. Thanks, Volker PS: I've just checked that AIX/ppc64 builds without a problem. On Wed, Feb 11, 2015 at 5:57 PM, Jesper Wilhelmsson wrote: > Looks good! > /Jesper > > Stefan Karlsson skrev den 11/2/15 16:55: > >> Hi Bengt, >> >> On 2015-02-11 16:51, Bengt Rutisson wrote: >>> >>> >>> Hi Stefan, >>> >>> Pretty difficult to review this type of change, but I think it looks >>> good. I >>> verified that no hpp files inlcude oop.inline.hpp after your change. Nice >>> cleanup! >>> >>> One minor thing (not your code): >>> >>> In src/share/vm/oops/oop.hpp there is this comment: >>> >>> // type test operations (inlined in oop.inline.h) >>> >>> I think the comment should say oop.inline.hpp not just .h. Do you mind >>> fixing >>> this as part of this change too? >> >> >> Thanks for reviewing. I'll fix the comment. >> >> Thanks, >> StefanK >> >>> >>> Thanks, >>> Bengt >>> >>> >>> >>> On 11/02/15 13:38, Stefan Karlsson wrote: >>>> >>>> Hi all, >>>> >>>> Please, review this patch to fix our includes of oop.inline.hpp. >>>> >>>> http://cr.openjdk.java.net/~stefank/8072911/webrev.01 >>>> https://bugs.openjdk.java.net/browse/JDK-8072911 >>>> >>>> >>>> From the enhancement description: >>>> --- >>>> Our inline.hpp files should preferably only be included from .cpp files >>>> or >>>> other .inline.hpp files. When they are included in .hpp files, the >>>> include >>>> dependency of the implementation spreads to unrelated parts of the code >>>> base, >>>> and it's easy to get circular dependencies. >>>> >>>> This guide line is documented on: >>>> https://wiki.openjdk.java.net/display/HotSpot/StyleGuide#Files >>>> >>>> oop.inline.hpp is one of the more problematic files, and I propose a >>>> patch to >>>> get rid of all inclusions of oop.inline.hpp from other .hpp files. >>>> --- >>>> >>>> >>>> Summary of the code changes: >>>> >>>> oop.inline.hpp >>>> - Added to needed .cpp and .inline.hpp files. >>>> >>>> oop.inline2.hpp >>>> - This file isn't needed anymore and the contents have been moved to >>>> oop.inline.hpp. >>>> >>>> oop.hpp >>>> - Inlined klass_gap_offset_in_bytes in the hpp file, since it's >>>> currently >>>> used from a few hpp files. >>>> >>>> - Create non-inlined versions of is_instance checks, to be used in >>>> asserts >>>> in handles.hpp. >>>> >>>> - Added has_klass_gap to get rid of dependency against globals.hpp >>>> >>>> javaClasses.hpp >>>> - There were a couple of usages of klass.hpp that were moved out to >>>> javaClasses.cpp and a few that were moved to javaClasses.inline.hpp when >>>> it >>>> wasn't obvious if we needed to inline the functions or not. >>>> >>>> vmGCOperations.hpp >>>> - Moved the VM_GC_Operation destructor to the cpp file. >>>> >>>> collectedHeap.hpp >>>> - Moved print_on_error >>>> >>>> barrierSet.hpp >>>> - Moved the inline keyword from the hpp file to the inline.hpp file. >>>> >>>> cardTableModRefBS.hpp >>>> - Moved inline_write_ref_field to the inline.hpp file. >>>> >>>> objArrayOop.hpp >>>> - Moved obj_at to the inline.hpp file. >>>> >>>> graphKit.hpp >>>> - Moved byte_map_base_node to .cpp file, where it's used. >>>> >>>> >>>> - Added missing includes that were removed when oop.inline.hpp was >>>> removed >>>> from the hpp files. >>>> >>>> >>>> The patch has been tested with JPRT. >>>> >>>> Thanks, >>>> StefanK >>>> >>> >> > From volker.simonis at gmail.com Wed Feb 11 18:34:38 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 11 Feb 2015 19:34:38 +0100 Subject: RFR: 8072911: Remove includes of oop.inline.hpp from .hpp files In-Reply-To: References: <54DB4D36.2050907@oracle.com> <54DB7A95.40807@oracle.com> <54DB7B62.8030408@oracle.com> <54DB89EB.50701@oracle.com> Message-ID: I found the problem. Can you please include the following additional line in interp_masm_ppc_64.cpp: diff -r e9b3fedb3bca src/cpu/ppc/vm/interp_masm_ppc_64.cpp --- a/src/cpu/ppc/vm/interp_masm_ppc_64.cpp Wed Feb 11 13:20:41 2015 +0100 +++ b/src/cpu/ppc/vm/interp_masm_ppc_64.cpp Wed Feb 11 19:00:23 2015 +0100 @@ -29,6 +29,7 @@ #include "interp_masm_ppc_64.hpp" #include "interpreter/interpreterRuntime.hpp" #include "prims/jvmtiThreadState.hpp" +#include "runtime/sharedRuntime.hpp" #ifdef PRODUCT #define BLOCK_COMMENT(str) // nothing It seems this was somehow implicitly included before your change. Thanks, Volker On Wed, Feb 11, 2015 at 6:56 PM, Volker Simonis wrote: > Hi Stefan, > > thanks for doing this change and thanks for changing the ppc-files as well. > > Unfortunately there still seems to be an error if building on > Linux/ppc64 without precompiled headers. > Can you please wait a little until I'll send you the additional > changes which are required before pushing this one. > > Thanks, > Volker > > PS: I've just checked that AIX/ppc64 builds without a problem. > > On Wed, Feb 11, 2015 at 5:57 PM, Jesper Wilhelmsson > wrote: >> Looks good! >> /Jesper >> >> Stefan Karlsson skrev den 11/2/15 16:55: >> >>> Hi Bengt, >>> >>> On 2015-02-11 16:51, Bengt Rutisson wrote: >>>> >>>> >>>> Hi Stefan, >>>> >>>> Pretty difficult to review this type of change, but I think it looks >>>> good. I >>>> verified that no hpp files inlcude oop.inline.hpp after your change. Nice >>>> cleanup! >>>> >>>> One minor thing (not your code): >>>> >>>> In src/share/vm/oops/oop.hpp there is this comment: >>>> >>>> // type test operations (inlined in oop.inline.h) >>>> >>>> I think the comment should say oop.inline.hpp not just .h. Do you mind >>>> fixing >>>> this as part of this change too? >>> >>> >>> Thanks for reviewing. I'll fix the comment. >>> >>> Thanks, >>> StefanK >>> >>>> >>>> Thanks, >>>> Bengt >>>> >>>> >>>> >>>> On 11/02/15 13:38, Stefan Karlsson wrote: >>>>> >>>>> Hi all, >>>>> >>>>> Please, review this patch to fix our includes of oop.inline.hpp. >>>>> >>>>> http://cr.openjdk.java.net/~stefank/8072911/webrev.01 >>>>> https://bugs.openjdk.java.net/browse/JDK-8072911 >>>>> >>>>> >>>>> From the enhancement description: >>>>> --- >>>>> Our inline.hpp files should preferably only be included from .cpp files >>>>> or >>>>> other .inline.hpp files. When they are included in .hpp files, the >>>>> include >>>>> dependency of the implementation spreads to unrelated parts of the code >>>>> base, >>>>> and it's easy to get circular dependencies. >>>>> >>>>> This guide line is documented on: >>>>> https://wiki.openjdk.java.net/display/HotSpot/StyleGuide#Files >>>>> >>>>> oop.inline.hpp is one of the more problematic files, and I propose a >>>>> patch to >>>>> get rid of all inclusions of oop.inline.hpp from other .hpp files. >>>>> --- >>>>> >>>>> >>>>> Summary of the code changes: >>>>> >>>>> oop.inline.hpp >>>>> - Added to needed .cpp and .inline.hpp files. >>>>> >>>>> oop.inline2.hpp >>>>> - This file isn't needed anymore and the contents have been moved to >>>>> oop.inline.hpp. >>>>> >>>>> oop.hpp >>>>> - Inlined klass_gap_offset_in_bytes in the hpp file, since it's >>>>> currently >>>>> used from a few hpp files. >>>>> >>>>> - Create non-inlined versions of is_instance checks, to be used in >>>>> asserts >>>>> in handles.hpp. >>>>> >>>>> - Added has_klass_gap to get rid of dependency against globals.hpp >>>>> >>>>> javaClasses.hpp >>>>> - There were a couple of usages of klass.hpp that were moved out to >>>>> javaClasses.cpp and a few that were moved to javaClasses.inline.hpp when >>>>> it >>>>> wasn't obvious if we needed to inline the functions or not. >>>>> >>>>> vmGCOperations.hpp >>>>> - Moved the VM_GC_Operation destructor to the cpp file. >>>>> >>>>> collectedHeap.hpp >>>>> - Moved print_on_error >>>>> >>>>> barrierSet.hpp >>>>> - Moved the inline keyword from the hpp file to the inline.hpp file. >>>>> >>>>> cardTableModRefBS.hpp >>>>> - Moved inline_write_ref_field to the inline.hpp file. >>>>> >>>>> objArrayOop.hpp >>>>> - Moved obj_at to the inline.hpp file. >>>>> >>>>> graphKit.hpp >>>>> - Moved byte_map_base_node to .cpp file, where it's used. >>>>> >>>>> >>>>> - Added missing includes that were removed when oop.inline.hpp was >>>>> removed >>>>> from the hpp files. >>>>> >>>>> >>>>> The patch has been tested with JPRT. >>>>> >>>>> Thanks, >>>>> StefanK >>>>> >>>> >>> >> From david.holmes at oracle.com Wed Feb 11 20:11:48 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 12 Feb 2015 06:11:48 +1000 Subject: RFR: JDK-8072904: building jdk9 with jdk9 boot jdk can cause failure or incorrect results In-Reply-To: <54DB3E9E.4030407@oracle.com> References: <54DB1F96.7080602@oracle.com> <54DB26A1.3030906@oracle.com> <54DB3E9E.4030407@oracle.com> Message-ID: <54DBB784.4030206@oracle.com> On 11/02/2015 9:35 PM, Erik Joelsson wrote: > Hello, > > New webrev: http://cr.openjdk.java.net/~erikj/8072904/webrev.hotspot.02/ > > On 2015-02-11 10:53, David Holmes wrote: >> Hi Erik, >> >> On 11/02/2015 7:23 PM, Erik Joelsson wrote: >>> Hello, >>> >>> Please review this change to how javah is run on sa classes. Since the >>> sa classes in JDK 9 are now in a module instead of sa-jdi.jar, they are >>> (at least currently) available from the default bootclasspath. This >>> means that just setting -classpath to javah will not properly override >>> the versions of the classes found in the boot jdk with the versions >>> currently being built. The fix is to change -classpath with >>> -Xbootclasspath/p:. >> >> Seems like a temporary workaround. javah should have a way to indicate >> which class to process without assuming it comes from the JVM used to >> run javah. Also putting what was sa-jdi.jar on the bootclasspath seems >> somewhat misplaced - these aren't "boot" classes. >> > It was also pointed out to me that -Xbootclasspath is not future proof. > So instead I opted for a different solution, using the new javac flag -h > and the @Native annotation to automatically generate header files during > compilation. >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8072904 >>> Webrev: http://cr.openjdk.java.net/~erikj/8072904/webrev.hotspot.01/ >> >> Were are the changes for all the other (non-linux) platforms? :) >> > Right, I forgot about that. *sigh* This time I made the changes in all > the makefiles. :) Thanks Erik this looks good to me. I'd completely forgotten about @Native - much cleaner solution! David > /Erik From david.holmes at oracle.com Wed Feb 11 20:27:00 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 12 Feb 2015 06:27:00 +1000 Subject: RFR: 8072911: Remove includes of oop.inline.hpp from .hpp files In-Reply-To: References: <54DB4D36.2050907@oracle.com> <54DB7A95.40807@oracle.com> <54DB7B62.8030408@oracle.com> <54DB89EB.50701@oracle.com> Message-ID: <54DBBB14.8050203@oracle.com> Hi Jesper, On 12/02/2015 3:56 AM, Volker Simonis wrote: > Hi Stefan, > > thanks for doing this change and thanks for changing the ppc-files as well. > > Unfortunately there still seems to be an error if building on > Linux/ppc64 without precompiled headers. I was going to ask if this had been tested with PCH disabled. (Not that we'd detect this particular issue.) Otherwise changes seem okay to me - the proof si in the builoding :) One minor comment typo in oop.hpp and oop.cpp: // type test operations that doesn't require inclusion of oop.inline.hpp. s/doesn't/don't/ Thanks, David > Can you please wait a little until I'll send you the additional > changes which are required before pushing this one. > > Thanks, > Volker > > PS: I've just checked that AIX/ppc64 builds without a problem. > > On Wed, Feb 11, 2015 at 5:57 PM, Jesper Wilhelmsson > wrote: >> Looks good! >> /Jesper >> >> Stefan Karlsson skrev den 11/2/15 16:55: >> >>> Hi Bengt, >>> >>> On 2015-02-11 16:51, Bengt Rutisson wrote: >>>> >>>> >>>> Hi Stefan, >>>> >>>> Pretty difficult to review this type of change, but I think it looks >>>> good. I >>>> verified that no hpp files inlcude oop.inline.hpp after your change. Nice >>>> cleanup! >>>> >>>> One minor thing (not your code): >>>> >>>> In src/share/vm/oops/oop.hpp there is this comment: >>>> >>>> // type test operations (inlined in oop.inline.h) >>>> >>>> I think the comment should say oop.inline.hpp not just .h. Do you mind >>>> fixing >>>> this as part of this change too? >>> >>> >>> Thanks for reviewing. I'll fix the comment. >>> >>> Thanks, >>> StefanK >>> >>>> >>>> Thanks, >>>> Bengt >>>> >>>> >>>> >>>> On 11/02/15 13:38, Stefan Karlsson wrote: >>>>> >>>>> Hi all, >>>>> >>>>> Please, review this patch to fix our includes of oop.inline.hpp. >>>>> >>>>> http://cr.openjdk.java.net/~stefank/8072911/webrev.01 >>>>> https://bugs.openjdk.java.net/browse/JDK-8072911 >>>>> >>>>> >>>>> From the enhancement description: >>>>> --- >>>>> Our inline.hpp files should preferably only be included from .cpp files >>>>> or >>>>> other .inline.hpp files. When they are included in .hpp files, the >>>>> include >>>>> dependency of the implementation spreads to unrelated parts of the code >>>>> base, >>>>> and it's easy to get circular dependencies. >>>>> >>>>> This guide line is documented on: >>>>> https://wiki.openjdk.java.net/display/HotSpot/StyleGuide#Files >>>>> >>>>> oop.inline.hpp is one of the more problematic files, and I propose a >>>>> patch to >>>>> get rid of all inclusions of oop.inline.hpp from other .hpp files. >>>>> --- >>>>> >>>>> >>>>> Summary of the code changes: >>>>> >>>>> oop.inline.hpp >>>>> - Added to needed .cpp and .inline.hpp files. >>>>> >>>>> oop.inline2.hpp >>>>> - This file isn't needed anymore and the contents have been moved to >>>>> oop.inline.hpp. >>>>> >>>>> oop.hpp >>>>> - Inlined klass_gap_offset_in_bytes in the hpp file, since it's >>>>> currently >>>>> used from a few hpp files. >>>>> >>>>> - Create non-inlined versions of is_instance checks, to be used in >>>>> asserts >>>>> in handles.hpp. >>>>> >>>>> - Added has_klass_gap to get rid of dependency against globals.hpp >>>>> >>>>> javaClasses.hpp >>>>> - There were a couple of usages of klass.hpp that were moved out to >>>>> javaClasses.cpp and a few that were moved to javaClasses.inline.hpp when >>>>> it >>>>> wasn't obvious if we needed to inline the functions or not. >>>>> >>>>> vmGCOperations.hpp >>>>> - Moved the VM_GC_Operation destructor to the cpp file. >>>>> >>>>> collectedHeap.hpp >>>>> - Moved print_on_error >>>>> >>>>> barrierSet.hpp >>>>> - Moved the inline keyword from the hpp file to the inline.hpp file. >>>>> >>>>> cardTableModRefBS.hpp >>>>> - Moved inline_write_ref_field to the inline.hpp file. >>>>> >>>>> objArrayOop.hpp >>>>> - Moved obj_at to the inline.hpp file. >>>>> >>>>> graphKit.hpp >>>>> - Moved byte_map_base_node to .cpp file, where it's used. >>>>> >>>>> >>>>> - Added missing includes that were removed when oop.inline.hpp was >>>>> removed >>>>> from the hpp files. >>>>> >>>>> >>>>> The patch has been tested with JPRT. >>>>> >>>>> Thanks, >>>>> StefanK >>>>> >>>> >>> >> From david.holmes at oracle.com Wed Feb 11 20:28:13 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 12 Feb 2015 06:28:13 +1000 Subject: RFR: 8072911: Remove includes of oop.inline.hpp from .hpp files In-Reply-To: <54DBBB14.8050203@oracle.com> References: <54DB4D36.2050907@oracle.com> <54DB7A95.40807@oracle.com> <54DB7B62.8030408@oracle.com> <54DB89EB.50701@oracle.com> <54DBBB14.8050203@oracle.com> Message-ID: <54DBBB5D.6060101@oracle.com> On 12/02/2015 6:27 AM, David Holmes wrote: > Hi Jesper, Sorry meant Stefan :) David > On 12/02/2015 3:56 AM, Volker Simonis wrote: >> Hi Stefan, >> >> thanks for doing this change and thanks for changing the ppc-files as >> well. >> >> Unfortunately there still seems to be an error if building on >> Linux/ppc64 without precompiled headers. > > I was going to ask if this had been tested with PCH disabled. (Not that > we'd detect this particular issue.) > > Otherwise changes seem okay to me - the proof si in the builoding :) > > One minor comment typo in oop.hpp and oop.cpp: > > // type test operations that doesn't require inclusion of oop.inline.hpp. > > s/doesn't/don't/ > > Thanks, > David > >> Can you please wait a little until I'll send you the additional >> changes which are required before pushing this one. >> >> Thanks, >> Volker >> >> PS: I've just checked that AIX/ppc64 builds without a problem. >> >> On Wed, Feb 11, 2015 at 5:57 PM, Jesper Wilhelmsson >> wrote: >>> Looks good! >>> /Jesper >>> >>> Stefan Karlsson skrev den 11/2/15 16:55: >>> >>>> Hi Bengt, >>>> >>>> On 2015-02-11 16:51, Bengt Rutisson wrote: >>>>> >>>>> >>>>> Hi Stefan, >>>>> >>>>> Pretty difficult to review this type of change, but I think it looks >>>>> good. I >>>>> verified that no hpp files inlcude oop.inline.hpp after your >>>>> change. Nice >>>>> cleanup! >>>>> >>>>> One minor thing (not your code): >>>>> >>>>> In src/share/vm/oops/oop.hpp there is this comment: >>>>> >>>>> // type test operations (inlined in oop.inline.h) >>>>> >>>>> I think the comment should say oop.inline.hpp not just .h. Do you mind >>>>> fixing >>>>> this as part of this change too? >>>> >>>> >>>> Thanks for reviewing. I'll fix the comment. >>>> >>>> Thanks, >>>> StefanK >>>> >>>>> >>>>> Thanks, >>>>> Bengt >>>>> >>>>> >>>>> >>>>> On 11/02/15 13:38, Stefan Karlsson wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> Please, review this patch to fix our includes of oop.inline.hpp. >>>>>> >>>>>> http://cr.openjdk.java.net/~stefank/8072911/webrev.01 >>>>>> https://bugs.openjdk.java.net/browse/JDK-8072911 >>>>>> >>>>>> >>>>>> From the enhancement description: >>>>>> --- >>>>>> Our inline.hpp files should preferably only be included from .cpp >>>>>> files >>>>>> or >>>>>> other .inline.hpp files. When they are included in .hpp files, the >>>>>> include >>>>>> dependency of the implementation spreads to unrelated parts of the >>>>>> code >>>>>> base, >>>>>> and it's easy to get circular dependencies. >>>>>> >>>>>> This guide line is documented on: >>>>>> https://wiki.openjdk.java.net/display/HotSpot/StyleGuide#Files >>>>>> >>>>>> oop.inline.hpp is one of the more problematic files, and I propose a >>>>>> patch to >>>>>> get rid of all inclusions of oop.inline.hpp from other .hpp files. >>>>>> --- >>>>>> >>>>>> >>>>>> Summary of the code changes: >>>>>> >>>>>> oop.inline.hpp >>>>>> - Added to needed .cpp and .inline.hpp files. >>>>>> >>>>>> oop.inline2.hpp >>>>>> - This file isn't needed anymore and the contents have been >>>>>> moved to >>>>>> oop.inline.hpp. >>>>>> >>>>>> oop.hpp >>>>>> - Inlined klass_gap_offset_in_bytes in the hpp file, since it's >>>>>> currently >>>>>> used from a few hpp files. >>>>>> >>>>>> - Create non-inlined versions of is_instance checks, to be used in >>>>>> asserts >>>>>> in handles.hpp. >>>>>> >>>>>> - Added has_klass_gap to get rid of dependency against globals.hpp >>>>>> >>>>>> javaClasses.hpp >>>>>> - There were a couple of usages of klass.hpp that were moved out to >>>>>> javaClasses.cpp and a few that were moved to >>>>>> javaClasses.inline.hpp when >>>>>> it >>>>>> wasn't obvious if we needed to inline the functions or not. >>>>>> >>>>>> vmGCOperations.hpp >>>>>> - Moved the VM_GC_Operation destructor to the cpp file. >>>>>> >>>>>> collectedHeap.hpp >>>>>> - Moved print_on_error >>>>>> >>>>>> barrierSet.hpp >>>>>> - Moved the inline keyword from the hpp file to the inline.hpp >>>>>> file. >>>>>> >>>>>> cardTableModRefBS.hpp >>>>>> - Moved inline_write_ref_field to the inline.hpp file. >>>>>> >>>>>> objArrayOop.hpp >>>>>> - Moved obj_at to the inline.hpp file. >>>>>> >>>>>> graphKit.hpp >>>>>> - Moved byte_map_base_node to .cpp file, where it's used. >>>>>> >>>>>> >>>>>> - Added missing includes that were removed when oop.inline.hpp was >>>>>> removed >>>>>> from the hpp files. >>>>>> >>>>>> >>>>>> The patch has been tested with JPRT. >>>>>> >>>>>> Thanks, >>>>>> StefanK >>>>>> >>>>> >>>> >>> From dean.long at oracle.com Wed Feb 11 20:49:04 2015 From: dean.long at oracle.com (Dean Long) Date: Wed, 11 Feb 2015 12:49:04 -0800 Subject: RFR(xxs): 8072935: Fix missing newline at end of file after 8067447 In-Reply-To: References: Message-ID: <54DBC040.2010000@oracle.com> It looks like you replaced } with }\n\n where }\n would have been enough, but no harm done. dl On 2/11/2015 8:37 AM, Thomas St?fe wrote: > Hi, > > Linux build did break after 8067447, please review this tiny fix: > > https://bugs.openjdk.java.net/browse/JDK-8072935 > http://cr.openjdk.java.net/~stuefe/webrevs/8072935/webrev.01/webrev/ > > Thank you! > > Kind Regards, Thomas From david.holmes at oracle.com Wed Feb 11 23:55:50 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 12 Feb 2015 09:55:50 +1000 Subject: RFR(xxs): 8072935: Fix missing newline at end of file after 8067447 In-Reply-To: References: Message-ID: <54DBEC06.7040406@oracle.com> On 12/02/2015 2:37 AM, Thomas St?fe wrote: > Hi, > > Linux build did break after 8067447, please review this tiny fix: Howe did this break any build? The change should have been pushed via JPRT and so was built on a number of linux platforms! ?? Thanks, David > https://bugs.openjdk.java.net/browse/JDK-8072935 > http://cr.openjdk.java.net/~stuefe/webrevs/8072935/webrev.01/webrev/ > > Thank you! > > Kind Regards, Thomas > From david.holmes at oracle.com Thu Feb 12 01:38:30 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 12 Feb 2015 11:38:30 +1000 Subject: RFR: 7143664: Clean up OrderAccess implementations and usage In-Reply-To: References: <54C1EBD3.1000905@oracle.com> <54C1F3D8.5040507@oracle.com> <54C2C1EA.5020507@oracle.com> <54C87D16.40601@oracle.com> <54C9674C.2080600@oracle.com> <54D85E4F.5020305@oracle.com> Message-ID: <54DC0416.5070105@oracle.com> Hi Erik, On 12/02/2015 12:32 AM, Erik ?sterlund wrote: > Hi David, > > Thanks a lot for reviewing my changes! > Sorry for the delay, had a few other things I had to take care of. No problem, we're still waiting for others to chime in here. A few comments inlined below ... > On 09/02/15 07:14, David Holmes wrote: >> On 29/01/2015 8:48 AM, David Holmes wrote: >>> Updated webrev: >>> >>> http://cr.openjdk.java.net/~dholmes/7143664/webrev.v2/ >> >> First let me say that Erik and I had a lot of offline discussions about >> this since he first proposed his reworking. My initial concern was >> ensuring the model changes were appropriate as this is a complex area >> and there can be different views of how things can/should be expressed. >> As per the bug report I was aware of a number of issues with the >> existing expression of semantics, but Erik showed me things were even >> worse than I had thought :) > > :) > >> src/share/vm/runtime/orderAccess.hpp >> >> Minor nit: I would prefer the term "bound" rather than "joined" when >> referring to load_acquire and store_release. > > Fixed. > >> In the implementation table I think "sparc" should be "sparc TSO". > > Fixed. > >> I still think we need to say something about C++ volatile and about >> compiler barriers in general. > > How about something like: > > C++ volatile semantics prevent compiler re-ordering between volatile > memory accesses. However, reordering between non-volatile and volatile > memory accesses is in general undefined. For compiler reordering > constraints taking non-volatile memory accesses into consideration, a > compiler barrier has to be used instead. Note also that both volatile > semantics and compiler barrier do not prevent hardware reordering. Sounds great! Though perhaps add "Some compiler implementations may choose to enforce additional constraints beyond those required by the language." ( a reference to MVSC) >> src/os_cpu/bsd_x86/vm/orderAccess_bsd_x86.inline.hpp >> src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp >> >> In OrderAccess::fence doesn't the existing asm already act as a compiler >> barrier; and on uniprocessor we need neither compiler nor hardware >> barriers; so isn't the compiler_barrier() redundant? > > I saw this was already clarified. But yeah, even uniprocessor systems > have concurrency. Therefore I added compiler barriers to properly > protect even uniprocessor systems, that could previously suffer from > data races involving unlikely yet possible compiler reorderings and > context switches. Yeah that was brain fart on my part ;-) >> >> --- >> >> src/os_cpu/bsd_zero/vm/orderAccess_bsd_zero.inline.hpp >> src/os_cpu/linux_zero/vm/orderAccess_linux_zero.inline.hpp >> >> No comments - The Zero folk will need to approve this change in terminology. > > I didn't like talking about "read" and "write" barriers as it says > little about what it actually means. And I also didn't like defining > things like storestore/storeload etc. in terms of acquire/release and > read/write barriers because I think it's weird. ;) That's why I changed > this. But if the previous terminology is preferred, I'm fine with > changing that. I prefer what you have too :) But this isn't my code so the Zero folk (who?) need to give this their blessing (or else we leave it out and let them incorporate this later). Ditto we need the ppc64 folk (Volker, Goetz) to also give their blessing. >> src/os_cpu/solaris_sparc/vm/orderAccess_solaris_sparc.inline.hpp >> src/os_cpu/solaris_sparc/vm/solaris_sparc.il >> >> You've removed the GNU_SOURCE ifdefs which means the new code has to be >> tested using gcc on Solaris. We don't officially support that platform >> so I have no way to verify these particular changes. > > Previously solaris studio did not support inline asm syntax. So the > solaris studio variant used .il assembly instead while the GNU_SOURCE > variant used inline asm. > > But since this is nowadays supported by solaris studio too, I joined > them into one. Not only because it's nicer to unify, but because I need > the compiler barrier constraints that inline asm can give us. I don't > know the compiler reordering constraints are guaranteed when calling > external assembly. So better make it explicit and safe. Totally fine with making use of Solaris Studio's modern capabilities, only minor concern is no way to test gcc on Solaris. But unless someone else screams about this I'm happy to assume that gcc will still be okay. >> src/os_cpu/solaris_x86/vm/orderAccess_solaris_x86.inline.hpp >> src/os_cpu/solaris_x86/vm/solaris_x86_32.il >> src/os_cpu/solaris_x86/vm/solaris_x86_64.il >> >> I think it makes sense to use the same code here as the linux x86 >> version. But as above can't verify this for gcc on Solaris; also query >> about need for compiler_barrier() in fence(). > > Same goes here as above. Solaris studio used to not support inline asm. > So I joined the variants relevant for correctness fixes. But of course, > it would be possible to add the optimizations from x86 bsd/linux as > well. But I wanted to keep optimizations out of this changeset as I > think it is already a lot to review without the addition of new > optimizations. So if you don't mind, I'd like to defer that until the > correctness fixes are in place. Okay. >> Do you have a reference to the MSVC volatile semantics? > > https://msdn.microsoft.com/en-us/library/12a04hfd(v=vs.100).aspx > > Release: > "A write to a volatile object (volatile write) has Release semantics; a > reference to a global or static object that occurs before a write to a > volatile object in the instruction sequence will occur before that > volatile write in the compiled binary." > > Acquire: > "A read of a volatile object (volatile read) has Acquire semantics; a > reference to a global or static object that occurs after a read of > volatile memory in the instruction sequence will occur after that > volatile read in the compiled binary." > > Should fit our model right for compiler reordering. Yes. Though I was amused to read the comments on that page. :) I mainly wanted to check this was guaranteed by the versions of MSVC we are currently using - which it is. >> Not clear about the 32-bit versus 64-bit changes - mainly because I >> don't know why they were different in the first place. > > Seems like x86_64 didn't have good support for inline asm syntax at some > point. I don't know if this is still true today. It would be nice to > know because I have seen fishy x86_64 implementations of a lot of atomic > stuff as well, assuming lack of compiler support that might actually be > available today. Yeah something to follow up with making the x86 implementations uniform across all OS/compilers. >> Why are windows release_store_fence specializations different to linux >> x86 versions? > > How do you mean they are different? To me they look quite equivalent. > xchg is always implicitly locked on x86, and they both use xchg to get > the wanted fence semantics. Windows: 89 template<> 90 inline void OrderAccess::specialized_release_store_fence (volatile jint* p, jint v) { 91 __asm { 92 mov edx, p; 93 mov eax, v; 94 xchg eax, dword ptr [edx]; 95 } Linux: ! template<> ! inline void OrderAccess::specialized_release_store_fence (volatile jint* p, jint v) { __asm__ volatile ( "xchgl (%2),%0" : "=r" (v) : "0" (v), "r" (p) : "memory"); } but I'm guessing the MVSC inline assembler doesn't have the same capabilities as gcc hence we have to write the code to load the registers needed by the xchg. >> Not clear about your change to the float version of release_store_fence: >> a) do we need to change it? >> b) given what we changed it to isn't that the default ? > > I didn't want to have default specializations of jfloat/jdouble > equalling jint/jlong. I thought maybe some architecture might want to > put it in different registers or something, making a default conversion > to int/long maybe undesirable. So the default for jfloat/jdouble is to > use acquire()/release() paired with an atomic memory access. So you have > to explicitly specialize them to be the same as jint/jlong if wanted, > which I believe is what is done in the code you refer to. Okay. It was the difference between the jfloat and jdouble versions in the original code that threw me. But the jdouble needs to delegate so we end up doing an Atomic::load. > If you think I'm paranoid about floats, I can of course make it a > default behaviour to use jint/jlong even if it isn't explicit, in the > same way I handled unsigned variants. No I think that is okay. > Rule of thumb: The variants that need specialization are the ones that > have overrides for OrderAccess::store/OrderAccess::load, the rest is > handled automatically. Currently jdouble and jfloat are part of that and > hence need explicit specialization, but if we want to generalize floats > too, that's fine by me. So is it preferred to generalize jfloat/jdouble > to equal jint/jlong? I'm okay as-is. >> General comment: copyright dates need updating in most, if not all, files. > > Fixed. > > Do we want a new webrev? (changed copyright headers and few words in > comments) If you can send me an incremental patch I will update the webrev. > Thanks a lot for taking time to review these changes! Thanks for contributing them! :) Cheers, David > /Erik > From coleen.phillimore at oracle.com Thu Feb 12 03:44:26 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 11 Feb 2015 22:44:26 -0500 Subject: RFR: 8072911: Remove includes of oop.inline.hpp from .hpp files In-Reply-To: <54DB4D36.2050907@oracle.com> References: <54DB4D36.2050907@oracle.com> Message-ID: <54DC219A.1000709@oracle.com> Hi Stefan, I think these cleanups are great. On 2/11/15, 7:38 AM, Stefan Karlsson wrote: > Hi all, > > Please, review this patch to fix our includes of oop.inline.hpp. > > http://cr.openjdk.java.net/~stefank/8072911/webrev.01 > https://bugs.openjdk.java.net/browse/JDK-8072911 > > > From the enhancement description: > --- > Our inline.hpp files should preferably only be included from .cpp > files or other .inline.hpp files. When they are included in .hpp > files, the include dependency of the implementation spreads to > unrelated parts of the code base, and it's easy to get circular > dependencies. > > This guide line is documented on: > https://wiki.openjdk.java.net/display/HotSpot/StyleGuide#Files > > oop.inline.hpp is one of the more problematic files, and I propose a > patch to get rid of all inclusions of oop.inline.hpp from other .hpp > files. > --- > > > Summary of the code changes: > > oop.inline.hpp > - Added to needed .cpp and .inline.hpp files. > > oop.inline2.hpp > - This file isn't needed anymore and the contents have been moved to > oop.inline.hpp. Hooray!! > > oop.hpp > - Inlined klass_gap_offset_in_bytes in the hpp file, since it's > currently used from a few hpp files. > > - Create non-inlined versions of is_instance checks, to be used in > asserts in handles.hpp. > > - Added has_klass_gap to get rid of dependency against globals.hpp > Why not put klass_gap_offset_in_bytes in the .cpp file? It's not going to be inlined completely anyway because the new version is calling has_klass_gap() which is in the .cpp file. I don't think it's usage is performance critical. > javaClasses.hpp > - There were a couple of usages of klass.hpp that were moved out to > javaClasses.cpp and a few that were moved to javaClasses.inline.hpp > when it wasn't obvious if we needed to inline the functions or not. > I'm confused about this. Why is there an java_lang_String::is_instance_inlined() and an is_instance() ? > vmGCOperations.hpp > - Moved the VM_GC_Operation destructor to the cpp file. > > collectedHeap.hpp > - Moved print_on_error > > barrierSet.hpp > - Moved the inline keyword from the hpp file to the inline.hpp file. > > cardTableModRefBS.hpp > - Moved inline_write_ref_field to the inline.hpp file. > > objArrayOop.hpp > - Moved obj_at to the inline.hpp file. > > graphKit.hpp > - Moved byte_map_base_node to .cpp file, where it's used. > > > - Added missing includes that were removed when oop.inline.hpp was > removed from the hpp files. > > > The patch has been tested with JPRT. JPRT compiles without precompiled headers on at least one of the solaris platforms, I think. You could compile on linux without precompiled headers just for verification locally. This change looks awesome. Thank you for doing this cleanup! Can you update the copyright headers when you check it in? That should suppress this "please update the copyright headers" comment on all these files going forward. Thanks! Coleen > > Thanks, > StefanK > From thomas.stuefe at gmail.com Thu Feb 12 07:28:05 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 12 Feb 2015 08:28:05 +0100 Subject: RFR(xxs): 8072935: Fix missing newline at end of file after 8067447 In-Reply-To: <54DBEC06.7040406@oracle.com> References: <54DBEC06.7040406@oracle.com> Message-ID: On Thu, Feb 12, 2015 at 12:55 AM, David Holmes wrote: > On 12/02/2015 2:37 AM, Thomas St?fe wrote: > >> Hi, >> >> Linux build did break after 8067447, please review this tiny fix: >> > > Howe did this break any build? The change should have been pushed via JPRT > and so was built on a number of linux platforms! ?? > > Hi David, Older version of g++ warn about missing newlines. Error happens with g++ 4.1.2. This compiler may be too old, but then I would have expected configure to fail when checking the build prerequisites. Regards, Thomas > Thanks, > David > > > https://bugs.openjdk.java.net/browse/JDK-8072935 >> http://cr.openjdk.java.net/~stuefe/webrevs/8072935/webrev.01/webrev/ >> >> Thank you! >> >> Kind Regards, Thomas >> >> From stefan.karlsson at oracle.com Thu Feb 12 08:06:51 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 12 Feb 2015 09:06:51 +0100 Subject: RFR: 8072911: Remove includes of oop.inline.hpp from .hpp files In-Reply-To: <54DB7A95.40807@oracle.com> References: <54DB4D36.2050907@oracle.com> <54DB7A95.40807@oracle.com> Message-ID: <54DC5F1B.60007@oracle.com> On 2015-02-11 16:51, Bengt Rutisson wrote: > > Hi Stefan, > > Pretty difficult to review this type of change, but I think it looks > good. I verified that no hpp files inlcude oop.inline.hpp after your > change. Nice cleanup! > > One minor thing (not your code): > > In src/share/vm/oops/oop.hpp there is this comment: > > // type test operations (inlined in oop.inline.h) > > I think the comment should say oop.inline.hpp not just .h. Do you mind > fixing this as part of this change too? Thanks. I'll fix the comment. StefanK > > Thanks, > Bengt > > > > On 11/02/15 13:38, Stefan Karlsson wrote: >> Hi all, >> >> Please, review this patch to fix our includes of oop.inline.hpp. >> >> http://cr.openjdk.java.net/~stefank/8072911/webrev.01 >> https://bugs.openjdk.java.net/browse/JDK-8072911 >> >> >> From the enhancement description: >> --- >> Our inline.hpp files should preferably only be included from .cpp >> files or other .inline.hpp files. When they are included in .hpp >> files, the include dependency of the implementation spreads to >> unrelated parts of the code base, and it's easy to get circular >> dependencies. >> >> This guide line is documented on: >> https://wiki.openjdk.java.net/display/HotSpot/StyleGuide#Files >> >> oop.inline.hpp is one of the more problematic files, and I propose a >> patch to get rid of all inclusions of oop.inline.hpp from other .hpp >> files. >> --- >> >> >> Summary of the code changes: >> >> oop.inline.hpp >> - Added to needed .cpp and .inline.hpp files. >> >> oop.inline2.hpp >> - This file isn't needed anymore and the contents have been moved to >> oop.inline.hpp. >> >> oop.hpp >> - Inlined klass_gap_offset_in_bytes in the hpp file, since it's >> currently used from a few hpp files. >> >> - Create non-inlined versions of is_instance checks, to be used in >> asserts in handles.hpp. >> >> - Added has_klass_gap to get rid of dependency against globals.hpp >> >> javaClasses.hpp >> - There were a couple of usages of klass.hpp that were moved out to >> javaClasses.cpp and a few that were moved to javaClasses.inline.hpp >> when it wasn't obvious if we needed to inline the functions or not. >> >> vmGCOperations.hpp >> - Moved the VM_GC_Operation destructor to the cpp file. >> >> collectedHeap.hpp >> - Moved print_on_error >> >> barrierSet.hpp >> - Moved the inline keyword from the hpp file to the inline.hpp file. >> >> cardTableModRefBS.hpp >> - Moved inline_write_ref_field to the inline.hpp file. >> >> objArrayOop.hpp >> - Moved obj_at to the inline.hpp file. >> >> graphKit.hpp >> - Moved byte_map_base_node to .cpp file, where it's used. >> >> >> - Added missing includes that were removed when oop.inline.hpp was >> removed from the hpp files. >> >> >> The patch has been tested with JPRT. >> >> Thanks, >> StefanK >> > From stefan.karlsson at oracle.com Thu Feb 12 08:07:12 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 12 Feb 2015 09:07:12 +0100 Subject: RFR: 8072911: Remove includes of oop.inline.hpp from .hpp files In-Reply-To: <54DB89EB.50701@oracle.com> References: <54DB4D36.2050907@oracle.com> <54DB7A95.40807@oracle.com> <54DB7B62.8030408@oracle.com> <54DB89EB.50701@oracle.com> Message-ID: <54DC5F30.8010703@oracle.com> On 2015-02-11 17:57, Jesper Wilhelmsson wrote: > Looks good! Thanks! StefanK > /Jesper > > Stefan Karlsson skrev den 11/2/15 16:55: >> Hi Bengt, >> >> On 2015-02-11 16:51, Bengt Rutisson wrote: >>> >>> Hi Stefan, >>> >>> Pretty difficult to review this type of change, but I think it looks >>> good. I >>> verified that no hpp files inlcude oop.inline.hpp after your change. >>> Nice >>> cleanup! >>> >>> One minor thing (not your code): >>> >>> In src/share/vm/oops/oop.hpp there is this comment: >>> >>> // type test operations (inlined in oop.inline.h) >>> >>> I think the comment should say oop.inline.hpp not just .h. Do you >>> mind fixing >>> this as part of this change too? >> >> Thanks for reviewing. I'll fix the comment. >> >> Thanks, >> StefanK >> >>> >>> Thanks, >>> Bengt >>> >>> >>> >>> On 11/02/15 13:38, Stefan Karlsson wrote: >>>> Hi all, >>>> >>>> Please, review this patch to fix our includes of oop.inline.hpp. >>>> >>>> http://cr.openjdk.java.net/~stefank/8072911/webrev.01 >>>> https://bugs.openjdk.java.net/browse/JDK-8072911 >>>> >>>> >>>> From the enhancement description: >>>> --- >>>> Our inline.hpp files should preferably only be included from .cpp >>>> files or >>>> other .inline.hpp files. When they are included in .hpp files, the >>>> include >>>> dependency of the implementation spreads to unrelated parts of the >>>> code base, >>>> and it's easy to get circular dependencies. >>>> >>>> This guide line is documented on: >>>> https://wiki.openjdk.java.net/display/HotSpot/StyleGuide#Files >>>> >>>> oop.inline.hpp is one of the more problematic files, and I propose >>>> a patch to >>>> get rid of all inclusions of oop.inline.hpp from other .hpp files. >>>> --- >>>> >>>> >>>> Summary of the code changes: >>>> >>>> oop.inline.hpp >>>> - Added to needed .cpp and .inline.hpp files. >>>> >>>> oop.inline2.hpp >>>> - This file isn't needed anymore and the contents have been moved to >>>> oop.inline.hpp. >>>> >>>> oop.hpp >>>> - Inlined klass_gap_offset_in_bytes in the hpp file, since it's >>>> currently >>>> used from a few hpp files. >>>> >>>> - Create non-inlined versions of is_instance checks, to be used in >>>> asserts >>>> in handles.hpp. >>>> >>>> - Added has_klass_gap to get rid of dependency against globals.hpp >>>> >>>> javaClasses.hpp >>>> - There were a couple of usages of klass.hpp that were moved out to >>>> javaClasses.cpp and a few that were moved to javaClasses.inline.hpp >>>> when it >>>> wasn't obvious if we needed to inline the functions or not. >>>> >>>> vmGCOperations.hpp >>>> - Moved the VM_GC_Operation destructor to the cpp file. >>>> >>>> collectedHeap.hpp >>>> - Moved print_on_error >>>> >>>> barrierSet.hpp >>>> - Moved the inline keyword from the hpp file to the inline.hpp file. >>>> >>>> cardTableModRefBS.hpp >>>> - Moved inline_write_ref_field to the inline.hpp file. >>>> >>>> objArrayOop.hpp >>>> - Moved obj_at to the inline.hpp file. >>>> >>>> graphKit.hpp >>>> - Moved byte_map_base_node to .cpp file, where it's used. >>>> >>>> >>>> - Added missing includes that were removed when oop.inline.hpp was >>>> removed >>>> from the hpp files. >>>> >>>> >>>> The patch has been tested with JPRT. >>>> >>>> Thanks, >>>> StefanK >>>> >>> >> From stefan.karlsson at oracle.com Thu Feb 12 08:08:30 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 12 Feb 2015 09:08:30 +0100 Subject: RFR: 8072911: Remove includes of oop.inline.hpp from .hpp files In-Reply-To: References: <54DB4D36.2050907@oracle.com> <54DB7A95.40807@oracle.com> <54DB7B62.8030408@oracle.com> <54DB89EB.50701@oracle.com> Message-ID: <54DC5F7E.3000107@oracle.com> On 2015-02-11 19:34, Volker Simonis wrote: > I found the problem. Can you please include the following additional > line in interp_masm_ppc_64.cpp: > > diff -r e9b3fedb3bca src/cpu/ppc/vm/interp_masm_ppc_64.cpp > --- a/src/cpu/ppc/vm/interp_masm_ppc_64.cpp Wed Feb 11 13:20:41 2015 +0100 > +++ b/src/cpu/ppc/vm/interp_masm_ppc_64.cpp Wed Feb 11 19:00:23 2015 +0100 > @@ -29,6 +29,7 @@ > #include "interp_masm_ppc_64.hpp" > #include "interpreter/interpreterRuntime.hpp" > #include "prims/jvmtiThreadState.hpp" > +#include "runtime/sharedRuntime.hpp" > > #ifdef PRODUCT > #define BLOCK_COMMENT(str) // nothing > > It seems this was somehow implicitly included before your change. Thanks for verifying the build on these platforms and for providing the fix. I'll add it to the patch. StefanK > > Thanks, > Volker > > > On Wed, Feb 11, 2015 at 6:56 PM, Volker Simonis > wrote: >> Hi Stefan, >> >> thanks for doing this change and thanks for changing the ppc-files as well. >> >> Unfortunately there still seems to be an error if building on >> Linux/ppc64 without precompiled headers. >> Can you please wait a little until I'll send you the additional >> changes which are required before pushing this one. >> >> Thanks, >> Volker >> >> PS: I've just checked that AIX/ppc64 builds without a problem. >> >> On Wed, Feb 11, 2015 at 5:57 PM, Jesper Wilhelmsson >> wrote: >>> Looks good! >>> /Jesper >>> >>> Stefan Karlsson skrev den 11/2/15 16:55: >>> >>>> Hi Bengt, >>>> >>>> On 2015-02-11 16:51, Bengt Rutisson wrote: >>>>> >>>>> Hi Stefan, >>>>> >>>>> Pretty difficult to review this type of change, but I think it looks >>>>> good. I >>>>> verified that no hpp files inlcude oop.inline.hpp after your change. Nice >>>>> cleanup! >>>>> >>>>> One minor thing (not your code): >>>>> >>>>> In src/share/vm/oops/oop.hpp there is this comment: >>>>> >>>>> // type test operations (inlined in oop.inline.h) >>>>> >>>>> I think the comment should say oop.inline.hpp not just .h. Do you mind >>>>> fixing >>>>> this as part of this change too? >>>> >>>> Thanks for reviewing. I'll fix the comment. >>>> >>>> Thanks, >>>> StefanK >>>> >>>>> Thanks, >>>>> Bengt >>>>> >>>>> >>>>> >>>>> On 11/02/15 13:38, Stefan Karlsson wrote: >>>>>> Hi all, >>>>>> >>>>>> Please, review this patch to fix our includes of oop.inline.hpp. >>>>>> >>>>>> http://cr.openjdk.java.net/~stefank/8072911/webrev.01 >>>>>> https://bugs.openjdk.java.net/browse/JDK-8072911 >>>>>> >>>>>> >>>>>> From the enhancement description: >>>>>> --- >>>>>> Our inline.hpp files should preferably only be included from .cpp files >>>>>> or >>>>>> other .inline.hpp files. When they are included in .hpp files, the >>>>>> include >>>>>> dependency of the implementation spreads to unrelated parts of the code >>>>>> base, >>>>>> and it's easy to get circular dependencies. >>>>>> >>>>>> This guide line is documented on: >>>>>> https://wiki.openjdk.java.net/display/HotSpot/StyleGuide#Files >>>>>> >>>>>> oop.inline.hpp is one of the more problematic files, and I propose a >>>>>> patch to >>>>>> get rid of all inclusions of oop.inline.hpp from other .hpp files. >>>>>> --- >>>>>> >>>>>> >>>>>> Summary of the code changes: >>>>>> >>>>>> oop.inline.hpp >>>>>> - Added to needed .cpp and .inline.hpp files. >>>>>> >>>>>> oop.inline2.hpp >>>>>> - This file isn't needed anymore and the contents have been moved to >>>>>> oop.inline.hpp. >>>>>> >>>>>> oop.hpp >>>>>> - Inlined klass_gap_offset_in_bytes in the hpp file, since it's >>>>>> currently >>>>>> used from a few hpp files. >>>>>> >>>>>> - Create non-inlined versions of is_instance checks, to be used in >>>>>> asserts >>>>>> in handles.hpp. >>>>>> >>>>>> - Added has_klass_gap to get rid of dependency against globals.hpp >>>>>> >>>>>> javaClasses.hpp >>>>>> - There were a couple of usages of klass.hpp that were moved out to >>>>>> javaClasses.cpp and a few that were moved to javaClasses.inline.hpp when >>>>>> it >>>>>> wasn't obvious if we needed to inline the functions or not. >>>>>> >>>>>> vmGCOperations.hpp >>>>>> - Moved the VM_GC_Operation destructor to the cpp file. >>>>>> >>>>>> collectedHeap.hpp >>>>>> - Moved print_on_error >>>>>> >>>>>> barrierSet.hpp >>>>>> - Moved the inline keyword from the hpp file to the inline.hpp file. >>>>>> >>>>>> cardTableModRefBS.hpp >>>>>> - Moved inline_write_ref_field to the inline.hpp file. >>>>>> >>>>>> objArrayOop.hpp >>>>>> - Moved obj_at to the inline.hpp file. >>>>>> >>>>>> graphKit.hpp >>>>>> - Moved byte_map_base_node to .cpp file, where it's used. >>>>>> >>>>>> >>>>>> - Added missing includes that were removed when oop.inline.hpp was >>>>>> removed >>>>>> from the hpp files. >>>>>> >>>>>> >>>>>> The patch has been tested with JPRT. >>>>>> >>>>>> Thanks, >>>>>> StefanK >>>>>> From thomas.stuefe at gmail.com Thu Feb 12 08:09:18 2015 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 12 Feb 2015 09:09:18 +0100 Subject: RFR(xxs): 8072935: Fix missing newline at end of file after 8067447 In-Reply-To: <54DBC040.2010000@oracle.com> References: <54DBC040.2010000@oracle.com> Message-ID: On Wed, Feb 11, 2015 at 9:49 PM, Dean Long wrote: > It looks like you replaced } with }\n\n where }\n would have been enough, > but no harm done. > > dl > > webrev.sh produced an empty change ("0 lines modified") when I added a single linefeed. That's why I added two. Thomas > > On 2/11/2015 8:37 AM, Thomas St?fe wrote: > >> Hi, >> >> Linux build did break after 8067447, please review this tiny fix: >> >> https://bugs.openjdk.java.net/browse/JDK-8072935 >> http://cr.openjdk.java.net/~stuefe/webrevs/8072935/webrev.01/webrev/ >> >> Thank you! >> >> Kind Regards, Thomas >> > > From stefan.karlsson at oracle.com Thu Feb 12 08:14:42 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 12 Feb 2015 09:14:42 +0100 Subject: RFR: 8072911: Remove includes of oop.inline.hpp from .hpp files In-Reply-To: <54DBBB14.8050203@oracle.com> References: <54DB4D36.2050907@oracle.com> <54DB7A95.40807@oracle.com> <54DB7B62.8030408@oracle.com> <54DB89EB.50701@oracle.com> <54DBBB14.8050203@oracle.com> Message-ID: <54DC60F2.9070005@oracle.com> On 2015-02-11 21:27, David Holmes wrote: > Hi Jesper, > > On 12/02/2015 3:56 AM, Volker Simonis wrote: >> Hi Stefan, >> >> thanks for doing this change and thanks for changing the ppc-files as >> well. >> >> Unfortunately there still seems to be an error if building on >> Linux/ppc64 without precompiled headers. > > I was going to ask if this had been tested with PCH disabled. (Not > that we'd detect this particular issue.) I've tested without PCH on Linux, with 32 and 64 bits, and all combinations of build targets that I could think of. I'll rerun JPRT with PCH disabled. > > Otherwise changes seem okay to me - the proof si in the builoding :) > > One minor comment typo in oop.hpp and oop.cpp: > > // type test operations that doesn't require inclusion of > oop.inline.hpp. > > s/doesn't/don't/ Fixed. Thanks for reviewing, StefanK > > Thanks, > David > >> Can you please wait a little until I'll send you the additional >> changes which are required before pushing this one. >> >> Thanks, >> Volker >> >> PS: I've just checked that AIX/ppc64 builds without a problem. >> >> On Wed, Feb 11, 2015 at 5:57 PM, Jesper Wilhelmsson >> wrote: >>> Looks good! >>> /Jesper >>> >>> Stefan Karlsson skrev den 11/2/15 16:55: >>> >>>> Hi Bengt, >>>> >>>> On 2015-02-11 16:51, Bengt Rutisson wrote: >>>>> >>>>> >>>>> Hi Stefan, >>>>> >>>>> Pretty difficult to review this type of change, but I think it looks >>>>> good. I >>>>> verified that no hpp files inlcude oop.inline.hpp after your >>>>> change. Nice >>>>> cleanup! >>>>> >>>>> One minor thing (not your code): >>>>> >>>>> In src/share/vm/oops/oop.hpp there is this comment: >>>>> >>>>> // type test operations (inlined in oop.inline.h) >>>>> >>>>> I think the comment should say oop.inline.hpp not just .h. Do you >>>>> mind >>>>> fixing >>>>> this as part of this change too? >>>> >>>> >>>> Thanks for reviewing. I'll fix the comment. >>>> >>>> Thanks, >>>> StefanK >>>> >>>>> >>>>> Thanks, >>>>> Bengt >>>>> >>>>> >>>>> >>>>> On 11/02/15 13:38, Stefan Karlsson wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> Please, review this patch to fix our includes of oop.inline.hpp. >>>>>> >>>>>> http://cr.openjdk.java.net/~stefank/8072911/webrev.01 >>>>>> https://bugs.openjdk.java.net/browse/JDK-8072911 >>>>>> >>>>>> >>>>>> From the enhancement description: >>>>>> --- >>>>>> Our inline.hpp files should preferably only be included from .cpp >>>>>> files >>>>>> or >>>>>> other .inline.hpp files. When they are included in .hpp files, the >>>>>> include >>>>>> dependency of the implementation spreads to unrelated parts of >>>>>> the code >>>>>> base, >>>>>> and it's easy to get circular dependencies. >>>>>> >>>>>> This guide line is documented on: >>>>>> https://wiki.openjdk.java.net/display/HotSpot/StyleGuide#Files >>>>>> >>>>>> oop.inline.hpp is one of the more problematic files, and I propose a >>>>>> patch to >>>>>> get rid of all inclusions of oop.inline.hpp from other .hpp files. >>>>>> --- >>>>>> >>>>>> >>>>>> Summary of the code changes: >>>>>> >>>>>> oop.inline.hpp >>>>>> - Added to needed .cpp and .inline.hpp files. >>>>>> >>>>>> oop.inline2.hpp >>>>>> - This file isn't needed anymore and the contents have been >>>>>> moved to >>>>>> oop.inline.hpp. >>>>>> >>>>>> oop.hpp >>>>>> - Inlined klass_gap_offset_in_bytes in the hpp file, since it's >>>>>> currently >>>>>> used from a few hpp files. >>>>>> >>>>>> - Create non-inlined versions of is_instance checks, to be used in >>>>>> asserts >>>>>> in handles.hpp. >>>>>> >>>>>> - Added has_klass_gap to get rid of dependency against globals.hpp >>>>>> >>>>>> javaClasses.hpp >>>>>> - There were a couple of usages of klass.hpp that were moved >>>>>> out to >>>>>> javaClasses.cpp and a few that were moved to >>>>>> javaClasses.inline.hpp when >>>>>> it >>>>>> wasn't obvious if we needed to inline the functions or not. >>>>>> >>>>>> vmGCOperations.hpp >>>>>> - Moved the VM_GC_Operation destructor to the cpp file. >>>>>> >>>>>> collectedHeap.hpp >>>>>> - Moved print_on_error >>>>>> >>>>>> barrierSet.hpp >>>>>> - Moved the inline keyword from the hpp file to the inline.hpp >>>>>> file. >>>>>> >>>>>> cardTableModRefBS.hpp >>>>>> - Moved inline_write_ref_field to the inline.hpp file. >>>>>> >>>>>> objArrayOop.hpp >>>>>> - Moved obj_at to the inline.hpp file. >>>>>> >>>>>> graphKit.hpp >>>>>> - Moved byte_map_base_node to .cpp file, where it's used. >>>>>> >>>>>> >>>>>> - Added missing includes that were removed when oop.inline.hpp was >>>>>> removed >>>>>> from the hpp files. >>>>>> >>>>>> >>>>>> The patch has been tested with JPRT. >>>>>> >>>>>> Thanks, >>>>>> StefanK >>>>>> >>>>> >>>> >>> From stefan.karlsson at oracle.com Thu Feb 12 08:24:26 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 12 Feb 2015 09:24:26 +0100 Subject: RFR: 8072911: Remove includes of oop.inline.hpp from .hpp files In-Reply-To: <54DC219A.1000709@oracle.com> References: <54DB4D36.2050907@oracle.com> <54DC219A.1000709@oracle.com> Message-ID: <54DC633A.8040408@oracle.com> On 2015-02-12 04:44, Coleen Phillimore wrote: > > Hi Stefan, > I think these cleanups are great. Thanks. Inlined: > > On 2/11/15, 7:38 AM, Stefan Karlsson wrote: >> Hi all, >> >> Please, review this patch to fix our includes of oop.inline.hpp. >> >> http://cr.openjdk.java.net/~stefank/8072911/webrev.01 >> https://bugs.openjdk.java.net/browse/JDK-8072911 >> >> >> From the enhancement description: >> --- >> Our inline.hpp files should preferably only be included from .cpp >> files or other .inline.hpp files. When they are included in .hpp >> files, the include dependency of the implementation spreads to >> unrelated parts of the code base, and it's easy to get circular >> dependencies. >> >> This guide line is documented on: >> https://wiki.openjdk.java.net/display/HotSpot/StyleGuide#Files >> >> oop.inline.hpp is one of the more problematic files, and I propose a >> patch to get rid of all inclusions of oop.inline.hpp from other .hpp >> files. >> --- >> >> >> Summary of the code changes: >> >> oop.inline.hpp >> - Added to needed .cpp and .inline.hpp files. >> >> oop.inline2.hpp >> - This file isn't needed anymore and the contents have been moved to >> oop.inline.hpp. > > Hooray!! :) > >> >> oop.hpp >> - Inlined klass_gap_offset_in_bytes in the hpp file, since it's >> currently used from a few hpp files. >> >> - Create non-inlined versions of is_instance checks, to be used in >> asserts in handles.hpp. >> >> - Added has_klass_gap to get rid of dependency against globals.hpp >> > > Why not put klass_gap_offset_in_bytes in the .cpp file? It's not > going to be inlined completely anyway because the new version is > calling has_klass_gap() which is in the .cpp file. I don't think it's > usage is performance critical. has_klass_gap() is only used in the assert to in product builds it will be inlined. It's also used by instanceOopDesc::base_offset_in_bytes(), which is called a lot. I don't want to risk introduce a regression by moving it to the .cpp file. > >> javaClasses.hpp >> - There were a couple of usages of klass.hpp that were moved out to >> javaClasses.cpp and a few that were moved to javaClasses.inline.hpp >> when it wasn't obvious if we needed to inline the functions or not. >> > > I'm confused about this. Why is there an > java_lang_String::is_instance_inlined() and an is_instance() ? java_lang_String::is_instance() - Can be used were we don't care if the function is inlined or not, e.g. asserts. - Can be used in hpp files were we don't want to include javaClasses.inline.hpp java_lang_String::is_instance_inlined() - Should be used were we want to give the compiler a chance to inline the function. - The current usages of this version is in methodHandles.cpp and g1StringDedup.cpp and it isn't obvious to me that I wouldn't introduce a performance regression by using the non-inlineable version. An alternative to all the changes to javaClasses would be to make oopDesc::klass() completely inlined into oop.hpp, but that would require some care to make sure that we don't include "too much" into oop.hpp. It still might be worth doing as a separate change. > >> vmGCOperations.hpp >> - Moved the VM_GC_Operation destructor to the cpp file. >> >> collectedHeap.hpp >> - Moved print_on_error >> >> barrierSet.hpp >> - Moved the inline keyword from the hpp file to the inline.hpp file. >> >> cardTableModRefBS.hpp >> - Moved inline_write_ref_field to the inline.hpp file. >> >> objArrayOop.hpp >> - Moved obj_at to the inline.hpp file. >> >> graphKit.hpp >> - Moved byte_map_base_node to .cpp file, where it's used. >> >> >> - Added missing includes that were removed when oop.inline.hpp was >> removed from the hpp files. >> >> >> The patch has been tested with JPRT. > > JPRT compiles without precompiled headers on at least one of the > solaris platforms, I think. You could compile on linux without > precompiled headers just for verification locally. I've done that already. > > This change looks awesome. Thanks, StefanK > Thank you for doing this cleanup! Can you update the copyright > headers when you check it in? That should suppress this "please > update the copyright headers" comment on all these files going forward. > > Thanks! > Coleen >> >> Thanks, >> StefanK >> > From volker.simonis at gmail.com Thu Feb 12 09:13:15 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 12 Feb 2015 10:13:15 +0100 Subject: RFR(xxs): 8072935: Fix missing newline at end of file after 8067447 In-Reply-To: References: <54DBC040.2010000@oracle.com> Message-ID: What's the general opinion - shouldn't we add a check for missing newlines at the end of a file to jcheck? Who could do that? Regards, Volker On Thu, Feb 12, 2015 at 9:09 AM, Thomas St?fe wrote: > On Wed, Feb 11, 2015 at 9:49 PM, Dean Long wrote: > >> It looks like you replaced } with }\n\n where }\n would have been enough, >> but no harm done. >> >> dl >> >> > webrev.sh produced an empty change ("0 lines modified") when I added a > single linefeed. That's why I added two. > > Thomas > > >> >> On 2/11/2015 8:37 AM, Thomas St?fe wrote: >> >>> Hi, >>> >>> Linux build did break after 8067447, please review this tiny fix: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8072935 >>> http://cr.openjdk.java.net/~stuefe/webrevs/8072935/webrev.01/webrev/ >>> >>> Thank you! >>> >>> Kind Regards, Thomas >>> >> >> From david.holmes at oracle.com Thu Feb 12 11:53:48 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 12 Feb 2015 21:53:48 +1000 Subject: RFR(xxs): 8072935: Fix missing newline at end of file after 8067447 In-Reply-To: References: <54DBEC06.7040406@oracle.com> Message-ID: <54DC944C.40701@oracle.com> On 12/02/2015 5:28 PM, Thomas St?fe wrote: > > On Thu, Feb 12, 2015 at 12:55 AM, David Holmes > wrote: > > On 12/02/2015 2:37 AM, Thomas St?fe wrote: > > Hi, > > Linux build did break after 8067447, please review this tiny fix: > > > Howe did this break any build? The change should have been pushed > via JPRT and so was built on a number of linux platforms! ?? > > > Hi David, > > Older version of g++ warn about missing newlines. Error happens with g++ > 4.1.2. Ah I see. > This compiler may be too old, but then I would have expected configure > to fail when checking the build prerequisites. Yeah not sure we have a minimum gcc version set - but we probably should! Something for the build folk - I'll forward this over to build-dev. Thanks, David > Regards, Thomas > > > Thanks, > David > > > https://bugs.openjdk.java.net/__browse/JDK-8072935 > > http://cr.openjdk.java.net/~__stuefe/webrevs/8072935/webrev.__01/webrev/ > > > Thank you! > > Kind Regards, Thomas > > From stefan.johansson at oracle.com Thu Feb 12 12:07:53 2015 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Thu, 12 Feb 2015 13:07:53 +0100 Subject: Request for approval [8u60]: 8062672: JVM crashes during GC on various asserts which checks that HeapWord ptr is an oop Message-ID: <54DC9799.80509@oracle.com> Hi all, The linux-sparc specific issue described in [1] was fixed directly in 7u80 to ensure it got in in time. The fix has not yet been forward ported to 8u, but now it is time. The fix for 7u80 applies clean and for more information please refer to the old review thread [2]. After this fix is in 8u, I plan to move it into 9. There is a small conflict for 9 so I will send out a proper review for that patch. I've created a new webrev for 8u, it's available here: http://cr.openjdk.java.net/~sjohanss/8062672/8u/hotspot.00/ Thanks, Stefan [1] https://bugs.openjdk.java.net/browse/JDK-8062672 [2] http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-December/016324.html From dmytro_sheyko at hotmail.com Thu Feb 12 15:53:47 2015 From: dmytro_sheyko at hotmail.com (Dmytro) Date: Thu, 12 Feb 2015 17:53:47 +0200 Subject: on non-static field layout Message-ID: Hello, I would like to share a couple of thoughts-proposals about non-static field layout and get feed back from you. 1. about reference fields I can see that reference fields are tried to be laid out together. Moreover reference fields of subclass can be appended to the pack of reference fields of its superclass, reducing number of oop_map entries (especially when -XX:FieldsAllocationStyle=2). However reference fields can still be scattered throughout the object and oop_map can have more than 1 entry. What about if reference fields were allocated BEFORE header (with negative offset)? In this case they all would form single solid cluster. Maybe we wouldn't need oop_map at all, knowing just number of reference fields would be enough. 2. about filling gaps Current approach of field layout tries to allocate fields densely by sorting them by their sizes and placing them from largest (long/double) to shortest (byte/boolean). Gap that may appear before long/double fields due to alignment is tried to be filled by shorter fields of the same class (-XX:+CompactFields). But this approach is still not perfect because it does not fill gaps between fields in superclasses. I believe we can allocate fields more densely (i.e. without unnecessary gaps in superclasses) with one pass (i.e. without sorting). When fields are aligned and packed densely, there can be zero or one 1-byte gap, zero or one 2-bytes gap and zero or one 4-bytes gap. So we can just keep track of these gaps and use them when occasion offers. E.g. when we need to allocate 2-byte field, first we try to use 2-bytes gap, otherwise we try to use 4-bytes gap (actually only the first half of it, the second half becomes 2-bytes gap), otherwise we append field to the end. Finally the algorithm of nonstatic field layout may look something like below: int oops_count; // number of oop fields int descent_size; // 8b aligned size of those part of object that is below header (header and primitive fields, but not oop fields) int vacant_4b_off; // offset of vacant 4 bytes space (always 4b aligned), 0 if there is no such space int vacant_2b_off; // offset of vacant 2 bytes space (always 2b aligned), 0 if there is no such space int vacant_1b_off; // offset of vacant 1 byte space, 0 if there is no such space // Before laying out nonstatic fields, copy this information (i.e. oops_count, descent_size, vacant_?b_off) from super class // for java.lang.Object they have following values // | 32 bit | 64 bit | 64 bit | // | | -XX:+UseCompressedOops | -XX:-UseCompressedOops | // --------------+--------+------------------------+------------------------+ // *header size* | 8 | 12 | 16 | // oops_count | 0 | 0 | 0 | // descent_size | 8 | 16 | 16 | // vacant_4b_off | 0 | 12 | 0 | // vacant_2b_off | 0 | 0 | 0 | // vacant_1b_off | 0 | 0 | 0 | for (AllFieldStream fs(_fields, _cp); !fs.done(); fs.next()) { int real_offset; FieldAllocationType atype = (FieldAllocationType) fs.allocation_type(); switch (atype) { ... case NONSTATIC_OOP: { // just prepend oops_count += 1; real_offset = -(oops_count * BytesPerHeapOop); break; } case NONSTATIC_DOUBLE: { // 8 bytes: long or double // just append real_offset = descent_size; descent_size += BytesPerLong; break; } case NONSTATIC_WORD: { // 4 bytes: int or float if (vacant_4b_off != 0) { // use vacant 4b space if possible real_offset = vacant_4b_off; vacant_4b_off = 0; } else { // otherwise append... real_offset = descent_size; // ... and the second half of appended 8 bytes becomes vacant 4b space vacant_4b_off = descent_size + BytesPerInt; descent_size += BytesPerLong; } break; } case NONSTATIC_SHORT: { // 2 bytes: short or char if (vacant_2b_off != 0) { // use vacant 2b space if possible... real_offset = vacant_2b_off; vacant_2b_off = 0; } else if (vacant_4b_off != 0) { // then try to use the first half of vacant 4b space... real_offset = vacant_4b_off; // ... and the second half becomes vacant 2b space vacant_2b_off = vacant_4b_off + BytesPerShort vacant_4b_off = 0; } else { // otherwise append real_offset = descent_size; // the rest becomes vacant vacant_2b_off = descent_size + BytesPerShort; vacant_4b_off = descent_size + BytesPerInt; descent_size += BytesPerLong; } break; } case NONSTATIC_BYTE: { // 1 byte: byte or boolean if (vacant_1b_off != 0) { real_offset = vacant_1b_off; vacant_1b_off = 0; } else if (vacant_2b_off != 0) { real_offset = vacant_2b_off; vacant_1b_off = vacant_2b_off + 1 vacant_2b_off = 0; } else if (vacant_4b_off != 0) { real_offset = vacant_4b_off; vacant_1b_off = vacant_4b_off + 1 vacant_2b_off = vacant_4b_off + BytesPerShort vacant_4b_off = 0; } else { real_offset = descent_size; vacant_1b_off = descent_size + 1; vacant_2b_off = descent_size + BytesPerShort; vacant_4b_off = descent_size + BytesPerInt; descent_size += BytesPerLong; } break; } fs.set_offset(real_offset); } // ascent_size: 8b aligned size of those part of object that is above header int ascent_size = align_size_up(oops_count * BytesPerHeapOop, BytesPerLong); // when class instance is allocated, the pointer to allocated space is to be advanced by ascent_size to get pointer to object // // pointer to allocated space--> [ ref field m ] <-+ // ... | -- ascent size // [ ref field 1 ] <-+ // pointer to object ----------> [ header ] <-+ // [ prim field 1 ] | // [ prim field 2 ] + -- descent size // ... | // [ prim field n ] <-+ int total_size = accent_size + descent_size; Regards, Dmytro From coleen.phillimore at oracle.com Thu Feb 12 16:04:58 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 12 Feb 2015 11:04:58 -0500 Subject: RFR: 8072911: Remove includes of oop.inline.hpp from .hpp files In-Reply-To: <54DC633A.8040408@oracle.com> References: <54DB4D36.2050907@oracle.com> <54DC219A.1000709@oracle.com> <54DC633A.8040408@oracle.com> Message-ID: <54DCCF2A.2010809@oracle.com> Sorry for top-post. This is fine. I must have misread has_klass_gap(). You didn't answer about fixing the copyright headers. Please do it, so we don't have to deal with the discussion of who's going to do it. In the runtime group at least, we decided to update the copyright headers. I have a 'sed' script if you need it. Thanks, Coleen On 2/12/15, 3:24 AM, Stefan Karlsson wrote: > On 2015-02-12 04:44, Coleen Phillimore wrote: >> >> Hi Stefan, >> I think these cleanups are great. > > Thanks. > > Inlined: > >> >> On 2/11/15, 7:38 AM, Stefan Karlsson wrote: >>> Hi all, >>> >>> Please, review this patch to fix our includes of oop.inline.hpp. >>> >>> http://cr.openjdk.java.net/~stefank/8072911/webrev.01 >>> https://bugs.openjdk.java.net/browse/JDK-8072911 >>> >>> >>> From the enhancement description: >>> --- >>> Our inline.hpp files should preferably only be included from .cpp >>> files or other .inline.hpp files. When they are included in .hpp >>> files, the include dependency of the implementation spreads to >>> unrelated parts of the code base, and it's easy to get circular >>> dependencies. >>> >>> This guide line is documented on: >>> https://wiki.openjdk.java.net/display/HotSpot/StyleGuide#Files >>> >>> oop.inline.hpp is one of the more problematic files, and I propose a >>> patch to get rid of all inclusions of oop.inline.hpp from other .hpp >>> files. >>> --- >>> >>> >>> Summary of the code changes: >>> >>> oop.inline.hpp >>> - Added to needed .cpp and .inline.hpp files. >>> >>> oop.inline2.hpp >>> - This file isn't needed anymore and the contents have been moved >>> to oop.inline.hpp. >> >> Hooray!! > > :) > >> >>> >>> oop.hpp >>> - Inlined klass_gap_offset_in_bytes in the hpp file, since it's >>> currently used from a few hpp files. >>> >>> - Create non-inlined versions of is_instance checks, to be used in >>> asserts in handles.hpp. >>> >>> - Added has_klass_gap to get rid of dependency against globals.hpp >>> >> >> Why not put klass_gap_offset_in_bytes in the .cpp file? It's not >> going to be inlined completely anyway because the new version is >> calling has_klass_gap() which is in the .cpp file. I don't think >> it's usage is performance critical. > > has_klass_gap() is only used in the assert to in product builds it > will be inlined. It's also used by > instanceOopDesc::base_offset_in_bytes(), which is called a lot. I > don't want to risk introduce a regression by moving it to the .cpp file. > >> >>> javaClasses.hpp >>> - There were a couple of usages of klass.hpp that were moved out to >>> javaClasses.cpp and a few that were moved to javaClasses.inline.hpp >>> when it wasn't obvious if we needed to inline the functions or not. >>> >> >> I'm confused about this. Why is there an >> java_lang_String::is_instance_inlined() and an is_instance() ? > > java_lang_String::is_instance() > - Can be used were we don't care if the function is inlined or not, > e.g. asserts. > - Can be used in hpp files were we don't want to include > javaClasses.inline.hpp > > java_lang_String::is_instance_inlined() > - Should be used were we want to give the compiler a chance to inline > the function. > - The current usages of this version is in methodHandles.cpp and > g1StringDedup.cpp and it isn't obvious to me that I wouldn't introduce > a performance regression by using the non-inlineable version. > > An alternative to all the changes to javaClasses would be to make > oopDesc::klass() completely inlined into oop.hpp, but that would > require some care to make sure that we don't include "too much" into > oop.hpp. It still might be worth doing as a separate change. > >> >>> vmGCOperations.hpp >>> - Moved the VM_GC_Operation destructor to the cpp file. >>> >>> collectedHeap.hpp >>> - Moved print_on_error >>> >>> barrierSet.hpp >>> - Moved the inline keyword from the hpp file to the inline.hpp file. >>> >>> cardTableModRefBS.hpp >>> - Moved inline_write_ref_field to the inline.hpp file. >>> >>> objArrayOop.hpp >>> - Moved obj_at to the inline.hpp file. >>> >>> graphKit.hpp >>> - Moved byte_map_base_node to .cpp file, where it's used. >>> >>> >>> - Added missing includes that were removed when oop.inline.hpp was >>> removed from the hpp files. >>> >>> >>> The patch has been tested with JPRT. >> >> JPRT compiles without precompiled headers on at least one of the >> solaris platforms, I think. You could compile on linux without >> precompiled headers just for verification locally. > > I've done that already. > >> >> This change looks awesome. > > Thanks, > StefanK > >> Thank you for doing this cleanup! Can you update the copyright >> headers when you check it in? That should suppress this "please >> update the copyright headers" comment on all these files going forward. >> >> Thanks! >> Coleen >>> >>> Thanks, >>> StefanK >>> >> > From erik.osterlund at lnu.se Thu Feb 12 16:50:21 2015 From: erik.osterlund at lnu.se (=?iso-8859-1?Q?Erik_=D6sterlund?=) Date: Thu, 12 Feb 2015 16:50:21 +0000 Subject: RFR: 7143664: Clean up OrderAccess implementations and usage References: <54C1EBD3.1000905@oracle.com> <54C1F3D8.5040507@oracle.com> <54C2C1EA.5020507@oracle.com> <54C87D16.40601@oracle.com> <54C9674C.2080600@oracle.com> <54D85E4F.5020305@oracle.com> <54DC0416.5070105@oracle.com> Message-ID: Hi David, On 12/02/15 01:38, David Holmes wrote: >>> I still think we need to say something about C++ volatile and about >>> compiler barriers in general. >> >> How about something like: >> >> C++ volatile semantics prevent compiler re-ordering between volatile >> memory accesses. However, reordering between non-volatile and volatile >> memory accesses is in general undefined. For compiler reordering >> constraints taking non-volatile memory accesses into consideration, a >> compiler barrier has to be used instead. Note also that both volatile >> semantics and compiler barrier do not prevent hardware reordering. > > Sounds great! Though perhaps add "Some compiler implementations may > choose to enforce additional constraints beyond those required by the > language." ( a reference to MVSC) Sounds good, fixed! >> But since this is nowadays supported by solaris studio too, I joined >> them into one. Not only because it's nicer to unify, but because I need >> the compiler barrier constraints that inline asm can give us. I don't >> know the compiler reordering constraints are guaranteed when calling >> external assembly. So better make it explicit and safe. > > Totally fine with making use of Solaris Studio's modern capabilities, > only minor concern is no way to test gcc on Solaris. But unless someone > else screams about this I'm happy to assume that gcc will still be okay. Since solaris studio is now actually using GCC syntax of inline asm which worked well (on all other GCC variants as well), I just took for granted that GCC would handle its own syntax on solaris too. ;) But it never hurts to verify! >> How do you mean they are different? To me they look quite equivalent. >> xchg is always implicitly locked on x86, and they both use xchg to get >> the wanted fence semantics. > > Windows: > > 89 template<> > 90 inline void OrderAccess::specialized_release_store_fence > (volatile jint* p, jint v) { > 91 __asm { > 92 mov edx, p; > 93 mov eax, v; > 94 xchg eax, dword ptr [edx]; > 95 } > > Linux: > > ! template<> > ! inline void OrderAccess::specialized_release_store_fence > (volatile jint* p, jint v) { > __asm__ volatile ( "xchgl (%2),%0" > : "=r" (v) > : "0" (v), "r" (p) > : "memory"); > } > > but I'm guessing the MVSC inline assembler doesn't have the same > capabilities as gcc hence we have to write the code to load the > registers needed by the xchg. Yeah pretty sure the xchg instruction assumes operands are in certain registers. GCC is clever enough to know the constraints of the operands and I'm guessing MSVC inline assembly is not, so it's made explicit. Although who knows, maybe it's smarter nowadays. Add that on the list of things to find out about windows and modern compiler support! ;) >>> Not clear about your change to the float version of release_store_fence: >>> a) do we need to change it? >>> b) given what we changed it to isn't that the default ? >> >> I didn't want to have default specializations of jfloat/jdouble >> equalling jint/jlong. I thought maybe some architecture might want to >> put it in different registers or something, making a default conversion >> to int/long maybe undesirable. So the default for jfloat/jdouble is to >> use acquire()/release() paired with an atomic memory access. So you have >> to explicitly specialize them to be the same as jint/jlong if wanted, >> which I believe is what is done in the code you refer to. > > Okay. It was the difference between the jfloat and jdouble versions in > the original code that threw me. But the jdouble needs to delegate so we > end up doing an Atomic::load. jdouble and jlong is delegated to Atomic::* in orderAccess.inline.hpp as they should be. It would perhaps be preferrable to eventually forward all atomic accesses to Atomic since it's really a different concern and would be good to have in one place. But the methods we need are not there yet, so I elected not to for now. But yeah some jfloat vs jdouble stuff in the original code is very strange and inconsistent. Notably, release_store_fence on linux_x86 properly uses compiler barriers for release for all variants except the awkward jfloat, meaning it does not have the protection it needs. Looks to me like this was a human mistake due to the high redundancy of the code. >> If you think I'm paranoid about floats, I can of course make it a >> default behaviour to use jint/jlong even if it isn't explicit, in the >> same way I handled unsigned variants. > > No I think that is okay. Then we keep it that way. :) > If you can send me an incremental patch I will update the webrev. Will do, thanks for uploading! Thanks, /Erik From david.holmes at oracle.com Thu Feb 12 23:51:45 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 13 Feb 2015 09:51:45 +1000 Subject: RFR: 7143664: Clean up OrderAccess implementations and usage In-Reply-To: References: <54C1EBD3.1000905@oracle.com> <54C1F3D8.5040507@oracle.com> <54C2C1EA.5020507@oracle.com> <54C87D16.40601@oracle.com> <54C9674C.2080600@oracle.com> <54D85E4F.5020305@oracle.com> <54DC0416.5070105@oracle.com> Message-ID: <54DD3C91.3030404@oracle.com> Updated webrev: http://cr.openjdk.java.net/~dholmes/7143664/webrev.v3/ Incremental webrev from v2: http://cr.openjdk.java.net/~dholmes/7143664/webrev.v3-incr/ One response inlined below ... On 13/02/2015 2:50 AM, Erik ?sterlund wrote: > Hi David, > > On 12/02/15 01:38, David Holmes wrote: > >>>> I still think we need to say something about C++ volatile and about >>>> compiler barriers in general. >>> >>> How about something like: >>> >>> C++ volatile semantics prevent compiler re-ordering between volatile >>> memory accesses. However, reordering between non-volatile and volatile >>> memory accesses is in general undefined. For compiler reordering >>> constraints taking non-volatile memory accesses into consideration, a >>> compiler barrier has to be used instead. Note also that both volatile >>> semantics and compiler barrier do not prevent hardware reordering. >> >> Sounds great! Though perhaps add "Some compiler implementations may >> choose to enforce additional constraints beyond those required by the >> language." ( a reference to MVSC) > > Sounds good, fixed! > >>> But since this is nowadays supported by solaris studio too, I joined >>> them into one. Not only because it's nicer to unify, but because I need >>> the compiler barrier constraints that inline asm can give us. I don't >>> know the compiler reordering constraints are guaranteed when calling >>> external assembly. So better make it explicit and safe. >> >> Totally fine with making use of Solaris Studio's modern capabilities, >> only minor concern is no way to test gcc on Solaris. But unless someone >> else screams about this I'm happy to assume that gcc will still be okay. > > Since solaris studio is now actually using GCC syntax of inline asm > which worked well (on all other GCC variants as well), I just took for > granted that GCC would handle its own syntax on solaris too. ;) > But it never hurts to verify! > >>> How do you mean they are different? To me they look quite equivalent. >>> xchg is always implicitly locked on x86, and they both use xchg to get >>> the wanted fence semantics. >> >> Windows: >> >> 89 template<> >> 90 inline void OrderAccess::specialized_release_store_fence >> (volatile jint* p, jint v) { >> 91 __asm { >> 92 mov edx, p; >> 93 mov eax, v; >> 94 xchg eax, dword ptr [edx]; >> 95 } >> >> Linux: >> >> ! template<> >> ! inline void OrderAccess::specialized_release_store_fence >> (volatile jint* p, jint v) { >> __asm__ volatile ( "xchgl (%2),%0" >> : "=r" (v) >> : "0" (v), "r" (p) >> : "memory"); >> } >> >> but I'm guessing the MVSC inline assembler doesn't have the same >> capabilities as gcc hence we have to write the code to load the >> registers needed by the xchg. > > Yeah pretty sure the xchg instruction assumes operands are in certain > registers. GCC is clever enough to know the constraints of the operands > and I'm guessing MSVC inline assembly is not, so it's made explicit. > Although who knows, maybe it's smarter nowadays. Add that on the list of > things to find out about windows and modern compiler support! ;) > >>>> Not clear about your change to the float version of release_store_fence: >>>> a) do we need to change it? >>>> b) given what we changed it to isn't that the default ? >>> >>> I didn't want to have default specializations of jfloat/jdouble >>> equalling jint/jlong. I thought maybe some architecture might want to >>> put it in different registers or something, making a default conversion >>> to int/long maybe undesirable. So the default for jfloat/jdouble is to >>> use acquire()/release() paired with an atomic memory access. So you have >>> to explicitly specialize them to be the same as jint/jlong if wanted, >>> which I believe is what is done in the code you refer to. >> >> Okay. It was the difference between the jfloat and jdouble versions in >> the original code that threw me. But the jdouble needs to delegate so we >> end up doing an Atomic::load. > > jdouble and jlong is delegated to Atomic::* in orderAccess.inline.hpp as > they should be. It would perhaps be preferrable to eventually forward > all atomic accesses to Atomic since it's really a different concern and > would be good to have in one place. But the methods we need are not > there yet, so I elected not to for now. > > But yeah some jfloat vs jdouble stuff in the original code is very > strange and inconsistent. Notably, release_store_fence on linux_x86 > properly uses compiler barriers for release for all variants except the > awkward jfloat, meaning it does not have the protection it needs. Looks > to me like this was a human mistake due to the high redundancy of the code. You mean this: OrderAccess::release_store_fence(volatile jfloat* p, jfloat v) { *p = v; fence(); } technically should be: compiler_barrier(); *p =v; fence(); That's an artifact of the assumption that volatile writes are sequence points and hence a compiler-barrier (something we now know is not the case with respect to preceding non-volatile accesses). Cheers, David >>> If you think I'm paranoid about floats, I can of course make it a >>> default behaviour to use jint/jlong even if it isn't explicit, in the >>> same way I handled unsigned variants. >> >> No I think that is okay. > > Then we keep it that way. :) > >> If you can send me an incremental patch I will update the webrev. > > Will do, thanks for uploading! > > Thanks, > /Erik > From david.holmes at oracle.com Fri Feb 13 11:25:55 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 13 Feb 2015 21:25:55 +1000 Subject: RFR(xxs): 8072935: Fix missing newline at end of file after 8067447 In-Reply-To: References: <54DBEC06.7040406@oracle.com> Message-ID: <54DDDF43.7010403@oracle.com> Submitting this now with myself and Dean as reviewers. Sorry I got sidetracked from the actual fix :) David On 12/02/2015 5:28 PM, Thomas St?fe wrote: > > On Thu, Feb 12, 2015 at 12:55 AM, David Holmes > wrote: > > On 12/02/2015 2:37 AM, Thomas St?fe wrote: > > Hi, > > Linux build did break after 8067447, please review this tiny fix: > > > Howe did this break any build? The change should have been pushed > via JPRT and so was built on a number of linux platforms! ?? > > > Hi David, > > Older version of g++ warn about missing newlines. Error happens with g++ > 4.1.2. > > This compiler may be too old, but then I would have expected configure > to fail when checking the build prerequisites. > > Regards, Thomas > > > Thanks, > David > > > https://bugs.openjdk.java.net/__browse/JDK-8072935 > > http://cr.openjdk.java.net/~__stuefe/webrevs/8072935/webrev.__01/webrev/ > > > Thank you! > > Kind Regards, Thomas > > From erik.osterlund at lnu.se Fri Feb 13 12:22:45 2015 From: erik.osterlund at lnu.se (=?iso-8859-1?Q?Erik_=D6sterlund?=) Date: Fri, 13 Feb 2015 12:22:45 +0000 Subject: RFR: 7143664: Clean up OrderAccess implementations and usage References: <54C1EBD3.1000905@oracle.com> <54C1F3D8.5040507@oracle.com> <54C2C1EA.5020507@oracle.com> <54C87D16.40601@oracle.com> <54C9674C.2080600@oracle.com> <54D85E4F.5020305@oracle.com> <54DC0416.5070105@oracle.com> <54DD3C91.3030404@oracle.com> Message-ID: Hi David, Thanks for updating the webrev! On 12/02/15 23:51, David Holmes wrote: >> But yeah some jfloat vs jdouble stuff in the original code is very >> strange and inconsistent. Notably, release_store_fence on linux_x86 >> properly uses compiler barriers for release for all variants except the >> awkward jfloat, meaning it does not have the protection it needs. Looks >> to me like this was a human mistake due to the high redundancy of the code. > > You mean this: > > OrderAccess::release_store_fence(volatile jfloat* p, jfloat v) { > *p = v; fence(); > } > > technically should be: compiler_barrier(); *p =v; fence(); > > That's an artifact of the assumption that volatile writes are sequence > points and hence a compiler-barrier (something we now know is not the > case with respect to preceding non-volatile accesses). Actually, the need for compiler barriers was already known at the time and fixed only for linux_x86 (as this is where things were observed to crash). Release was consistently changed to use a compiler barrier for all overloads except this jfloat overload of release_store_fence. Of course this does not matter now as it is fixed in this patch, just an interesting observation, showing IMO that it is easier for things like these to slip by when code is replicated instead of generalized. ;) Thanks for helping me with the review! Let's see if I can attract some PPC64 people to review: src/os_cpu/aix_ppc/vm/orderAccess_aix_ppc.inline.hpp src/os_cpu/linux_ppc/vm/orderAccess_linux_ppc.inline.hpp and zero people (not the number) to review: src/os_cpu/bsd_zero/vm/orderAccess_bsd_zero.inline.hpp src/os_cpu/linux_zero/vm/orderAccess_linux_zero.inline.hpp Thanks, /Erik From aph at redhat.com Fri Feb 13 13:38:58 2015 From: aph at redhat.com (Andrew Haley) Date: Fri, 13 Feb 2015 13:38:58 +0000 Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses Message-ID: <54DDFE72.1050306@redhat.com> java.?nio.?DirectByteBuffer.getXXX is slow for types larger than byte because the runtime does not know that AArch64 can perform unaligned memory accesses. The problem is due to this code in java.nio.Bits.unaligned(): unaligned = arch.equals("i386") || arch.equals("x86") || arch.equals("amd64") || arch.equals("x86_64"); If we add AArch64 to this list code quality is very much improved. http://cr.openjdk.java.net/~aph/8073093/ Thanks, Andrew. From gnu.andrew at redhat.com Fri Feb 13 14:57:19 2015 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 13 Feb 2015 09:57:19 -0500 (EST) Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <531ED06F.5040905@oracle.com> References: <531E8309.2060206@oracle.com> <531ED06F.5040905@oracle.com> Message-ID: <107001365.11810418.1423839439509.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 11/03/2014 6:36 PM, Volker Simonis wrote: > > On Tue, Mar 11, 2014 at 4:29 AM, David Holmes > > wrote: > >> I don't see anything that actually controls what is built. Is it the case > >> that the new arch value will be reported by uname on the ppc64le system? > >> > >> (I cringe seeing a new top-level arch introduced for this.) > >> > > > > I didn't liked this too much as well in my first review and I think we > > can get along without a new top-level arch (see > > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2014-March/001790.html). > > > > But in the end I can live with both approaches (and having two > > top-level archs probably makes it slightly simpler to support them > > both in parallel) so I think finally it is up to you which approach we > > take. > > I agree with your initial review. I don't see a LE build as a distinct > architecture but a variant of ppc64. > > Lets see what anyone else has to say. > > Thanks, > David > > > > > > > Regards, > > Volker > > > >> Thanks, > >> David > >> > >> > >> On 7/03/2014 1:37 PM, Alexander Smundak wrote: > >>> > >>> This patch contains the changes to the build files to build JDK on the > >>> little endian PowerPC64 running Linux, and the changes to the source > >>> files to support little endian mode. > >>> This preceding related change > >>> https://bugs.openjdk.java.net/browse/JDK-8036767 added support for the > >>> ELFv2 ABi used on the little endian PowerPC64. > >>> > >>> Please review and test this change. I need a sponsor. > >>> > >>> The patch is at: > >>> http://cr.openjdk.java.net/~martin/asmundak/8036767/webrev.00/ > >>> > >>> Sasha > >>> > >> > We're now seeing problems with Java tools on ppc64le as a result of this decision not to give it a distinct arch name. The os.arch property on both ppc64be and ppc64le builds of OpenJDK is being reported as the same; "ppc64". This leaves Java applications no way of determining which of the two platforms the JDK is running on and, for example, means that Maven can't determine which native JNI binaries to download. There is a sun.cpu.endian property but this is non-standard and it seems wrong to me that every Java tool should have to add a special case for ppc64le using such a property. This value is traditionally not so much just the architecture as a composite of the architecture, the bit size and the endianness. The only difference with other platforms is that they only support one default endianness so the value is implied e.g. little-endian for amd64, big-endian for sparc. We do distinguish between ppc and ppc64 rather than expecting tools to check sun.arch.data.model, so we should do the same with endianness. To add to the confusion, other JDKs are reporting it as ppc64le (thanks to Tiago Sturmer Daitx for these results): IBM Java 2.7 SR1 os.arch: ppc64le sun.cpu.endian: little GCJ 4.8.2 (gij (GNU libgcj) version 4.8.2): os.arch: ppc64le sun.cpu.endian: null whereas OpenJDK gives: os.arch: ppc64 sun.cpu.endian: little It also means that ppc64le is alone in not having a unique architecture directory in jre/lib. I understand that a ppc64le machine is not going to support ppc64be, but likewise amd64 is not going to support arm, yet they have unique arch directories. I've prepared a webrev which fixes the external facing architecture names, LIBARCH and os.name, while leaving the HotSpot build architecture, BUILDARCH, as it is, to avoid the duplication mentioned as a problem in the original review. http://cr.openjdk.java.net/~andrew/rh1191652/webrev.01/ This is against our IcedTea OpenJDK7-based HotSpot where we've been testing but it should still be applicable to the 9 HotSpot repositories. The JDK side is another issue and I suspect we'll need a completely different patch there to the one we have for 7. Our builds of OpenJDK 7 with this fixed now give: java.library.path = /usr/java/packages/lib/ppc64le:/usr/lib64:/lib64:/lib:/usr/lib sun.boot.library.path = /builddir/build/BUILD/java-1.7.0-openjdk-1.7.0.75-2.5.4.5.ael7b.ppc64le/openjdk/build/linux-ppc64le/j2sdk-image/jre/lib/ppc64le os.arch = ppc64le I've filed a bug for this here: https://bugs.openjdk.java.net/browse/JDK-8073139 Thanks, -- Andrew :) 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 PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From Alan.Bateman at oracle.com Fri Feb 13 16:05:15 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 13 Feb 2015 16:05:15 +0000 Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses In-Reply-To: <54DDFE72.1050306@redhat.com> References: <54DDFE72.1050306@redhat.com> Message-ID: <54DE20BB.50302@oracle.com> On 13/02/2015 13:38, Andrew Haley wrote: > java.?nio.?DirectByteBuffer.getXXX is slow for types larger than byte > because the runtime does not know that AArch64 can perform unaligned > memory accesses. > > The problem is due to this code in java.nio.Bits.unaligned(): > > unaligned = arch.equals("i386") || arch.equals("x86") > || arch.equals("amd64") || arch.equals("x86_64"); > > If we add AArch64 to this list code quality is very much improved. > > http://cr.openjdk.java.net/~aph/8073093/ > Make sense, I assume this will go in when JEP 237 is pushed. -Alan From aph at redhat.com Fri Feb 13 16:07:13 2015 From: aph at redhat.com (Andrew Haley) Date: Fri, 13 Feb 2015 16:07:13 +0000 Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses In-Reply-To: <54DE20BB.50302@oracle.com> References: <54DDFE72.1050306@redhat.com> <54DE20BB.50302@oracle.com> Message-ID: <54DE2131.3090405@redhat.com> On 02/13/2015 04:05 PM, Alan Bateman wrote: > On 13/02/2015 13:38, Andrew Haley wrote: >> java.?nio.?DirectByteBuffer.getXXX is slow for types larger than byte >> because the runtime does not know that AArch64 can perform unaligned >> memory accesses. >> >> The problem is due to this code in java.nio.Bits.unaligned(): >> >> unaligned = arch.equals("i386") || arch.equals("x86") >> || arch.equals("amd64") || arch.equals("x86_64"); >> >> If we add AArch64 to this list code quality is very much improved. >> >> http://cr.openjdk.java.net/~aph/8073093/ >> > Make sense, I assume this will go in when JEP 237 is pushed. It will, but I need approval to push to the JEP 237 staging repo. 'Cos them's the rules. :-) Andrew. From volker.simonis at gmail.com Fri Feb 13 16:37:39 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 13 Feb 2015 17:37:39 +0100 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <107001365.11810418.1423839439509.JavaMail.zimbra@redhat.com> References: <531E8309.2060206@oracle.com> <531ED06F.5040905@oracle.com> <107001365.11810418.1423839439509.JavaMail.zimbra@redhat.com> Message-ID: On Fri, Feb 13, 2015 at 3:57 PM, Andrew Hughes wrote: > ----- Original Message ----- >> On 11/03/2014 6:36 PM, Volker Simonis wrote: >> > On Tue, Mar 11, 2014 at 4:29 AM, David Holmes >> > wrote: >> >> I don't see anything that actually controls what is built. Is it the case >> >> that the new arch value will be reported by uname on the ppc64le system? >> >> >> >> (I cringe seeing a new top-level arch introduced for this.) >> >> >> > >> > I didn't liked this too much as well in my first review and I think we >> > can get along without a new top-level arch (see >> > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2014-March/001790.html). >> > >> > But in the end I can live with both approaches (and having two >> > top-level archs probably makes it slightly simpler to support them >> > both in parallel) so I think finally it is up to you which approach we >> > take. >> >> I agree with your initial review. I don't see a LE build as a distinct >> architecture but a variant of ppc64. >> >> Lets see what anyone else has to say. >> >> Thanks, >> David >> >> >> >> >> >> > Regards, >> > Volker >> > >> >> Thanks, >> >> David >> >> >> >> >> >> On 7/03/2014 1:37 PM, Alexander Smundak wrote: >> >>> >> >>> This patch contains the changes to the build files to build JDK on the >> >>> little endian PowerPC64 running Linux, and the changes to the source >> >>> files to support little endian mode. >> >>> This preceding related change >> >>> https://bugs.openjdk.java.net/browse/JDK-8036767 added support for the >> >>> ELFv2 ABi used on the little endian PowerPC64. >> >>> >> >>> Please review and test this change. I need a sponsor. >> >>> >> >>> The patch is at: >> >>> http://cr.openjdk.java.net/~martin/asmundak/8036767/webrev.00/ >> >>> >> >>> Sasha >> >>> >> >> >> > > We're now seeing problems with Java tools on ppc64le as a result of this > decision not to give it a distinct arch name. > > The os.arch property on both ppc64be and ppc64le builds of OpenJDK is being > reported as the same; "ppc64". This leaves Java applications no way of > determining which of the two platforms the JDK is running on and, for example, > means that Maven can't determine which native JNI binaries to download. > > There is a sun.cpu.endian property but this is non-standard and it seems > wrong to me that every Java tool should have to add a special case for > ppc64le using such a property. This value is traditionally not so much > just the architecture as a composite of the architecture, the bit size > and the endianness. The only difference with other platforms is that they > only support one default endianness so the value is implied e.g. > little-endian for amd64, big-endian for sparc. We do distinguish between > ppc and ppc64 rather than expecting tools to check sun.arch.data.model, > so we should do the same with endianness. > > To add to the confusion, other JDKs are reporting it as ppc64le > (thanks to Tiago Sturmer Daitx for these results): > > IBM Java 2.7 SR1 > os.arch: ppc64le > sun.cpu.endian: little > > GCJ 4.8.2 (gij (GNU libgcj) version 4.8.2): > os.arch: ppc64le > sun.cpu.endian: null > > whereas OpenJDK gives: > > os.arch: ppc64 > sun.cpu.endian: little > > It also means that ppc64le is alone in not having a unique architecture > directory in jre/lib. I understand that a ppc64le machine is not going > to support ppc64be, but likewise amd64 is not going to support arm, > yet they have unique arch directories. > > I've prepared a webrev which fixes the external facing architecture names, > LIBARCH and os.name, while leaving the HotSpot build architecture, BUILDARCH, > as it is, to avoid the duplication mentioned as a problem in the original > review. > > http://cr.openjdk.java.net/~andrew/rh1191652/webrev.01/ > > This is against our IcedTea OpenJDK7-based HotSpot where we've been testing > but it should still be applicable to the 9 HotSpot repositories. The JDK side > is another issue and I suspect we'll need a completely different patch there > to the one we have for 7. > > Our builds of OpenJDK 7 with this fixed now give: > > java.library.path = /usr/java/packages/lib/ppc64le:/usr/lib64:/lib64:/lib:/usr/lib > sun.boot.library.path = /builddir/build/BUILD/java-1.7.0-openjdk-1.7.0.75-2.5.4.5.ael7b.ppc64le/openjdk/build/linux-ppc64le/j2sdk-image/jre/lib/ppc64le > os.arch = ppc64le > > I've filed a bug for this here: > > https://bugs.openjdk.java.net/browse/JDK-8073139 > > Thanks, > -- > Andrew :) > > 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 > > PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) > Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 > Hi Andrew, I don't have a problem with your change and it doesn't affect the ppc64 big endian build. I've prepared a patch which applies cleanly to jdk9-hs-rt here: http://cr.openjdk.java.net/~simonis/webrevs/2015/8073139/ Let's here some other opinions as well (you'll need a sponsor from Oracle anyway and it would also be interesting to here from Alexander if they already rely on os.arch being ppc64) but from my side thumbs up. Regards, Volker From vladimir.kozlov at oracle.com Fri Feb 13 16:56:41 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 13 Feb 2015 08:56:41 -0800 Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses In-Reply-To: <54DE2131.3090405@redhat.com> References: <54DDFE72.1050306@redhat.com> <54DE20BB.50302@oracle.com> <54DE2131.3090405@redhat.com> Message-ID: <54DE2CC9.3050805@oracle.com> Changes are fine. I agree with Alan. Please, wait when we merge aarch64 stage into jdk9/dev and then push this fix into jdk9 (by sponsor). We should finish testing of stage repo "soon". Thanks, Vladimir On 2/13/15 8:07 AM, Andrew Haley wrote: > On 02/13/2015 04:05 PM, Alan Bateman wrote: >> On 13/02/2015 13:38, Andrew Haley wrote: >>> java.?nio.?DirectByteBuffer.getXXX is slow for types larger than byte >>> because the runtime does not know that AArch64 can perform unaligned >>> memory accesses. >>> >>> The problem is due to this code in java.nio.Bits.unaligned(): >>> >>> unaligned = arch.equals("i386") || arch.equals("x86") >>> || arch.equals("amd64") || arch.equals("x86_64"); >>> >>> If we add AArch64 to this list code quality is very much improved. >>> >>> http://cr.openjdk.java.net/~aph/8073093/ >>> >> Make sense, I assume this will go in when JEP 237 is pushed. > > It will, but I need approval to push to the JEP 237 staging repo. > 'Cos them's the rules. :-) > > Andrew. > From asmundak at google.com Fri Feb 13 17:25:13 2015 From: asmundak at google.com (Alexander Smundak) Date: Fri, 13 Feb 2015 09:25:13 -0800 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: References: <531E8309.2060206@oracle.com> <531ED06F.5040905@oracle.com> <107001365.11810418.1423839439509.JavaMail.zimbra@redhat.com> Message-ID: I was always in favor of having ppc64le as a separate architecture. I hope this will be backported to JDK8? On Fri, Feb 13, 2015 at 8:37 AM, Volker Simonis wrote: > On Fri, Feb 13, 2015 at 3:57 PM, Andrew Hughes wrote: >> ----- Original Message ----- >>> On 11/03/2014 6:36 PM, Volker Simonis wrote: >>> > On Tue, Mar 11, 2014 at 4:29 AM, David Holmes >>> > wrote: >>> >> I don't see anything that actually controls what is built. Is it the case >>> >> that the new arch value will be reported by uname on the ppc64le system? >>> >> >>> >> (I cringe seeing a new top-level arch introduced for this.) >>> >> >>> > >>> > I didn't liked this too much as well in my first review and I think we >>> > can get along without a new top-level arch (see >>> > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2014-March/001790.html). >>> > >>> > But in the end I can live with both approaches (and having two >>> > top-level archs probably makes it slightly simpler to support them >>> > both in parallel) so I think finally it is up to you which approach we >>> > take. >>> >>> I agree with your initial review. I don't see a LE build as a distinct >>> architecture but a variant of ppc64. >>> >>> Lets see what anyone else has to say. >>> >>> Thanks, >>> David >>> >>> >>> >>> >>> >>> > Regards, >>> > Volker >>> > >>> >> Thanks, >>> >> David >>> >> >>> >> >>> >> On 7/03/2014 1:37 PM, Alexander Smundak wrote: >>> >>> >>> >>> This patch contains the changes to the build files to build JDK on the >>> >>> little endian PowerPC64 running Linux, and the changes to the source >>> >>> files to support little endian mode. >>> >>> This preceding related change >>> >>> https://bugs.openjdk.java.net/browse/JDK-8036767 added support for the >>> >>> ELFv2 ABi used on the little endian PowerPC64. >>> >>> >>> >>> Please review and test this change. I need a sponsor. >>> >>> >>> >>> The patch is at: >>> >>> http://cr.openjdk.java.net/~martin/asmundak/8036767/webrev.00/ >>> >>> >>> >>> Sasha >>> >>> >>> >> >>> >> >> We're now seeing problems with Java tools on ppc64le as a result of this >> decision not to give it a distinct arch name. >> >> The os.arch property on both ppc64be and ppc64le builds of OpenJDK is being >> reported as the same; "ppc64". This leaves Java applications no way of >> determining which of the two platforms the JDK is running on and, for example, >> means that Maven can't determine which native JNI binaries to download. >> >> There is a sun.cpu.endian property but this is non-standard and it seems >> wrong to me that every Java tool should have to add a special case for >> ppc64le using such a property. This value is traditionally not so much >> just the architecture as a composite of the architecture, the bit size >> and the endianness. The only difference with other platforms is that they >> only support one default endianness so the value is implied e.g. >> little-endian for amd64, big-endian for sparc. We do distinguish between >> ppc and ppc64 rather than expecting tools to check sun.arch.data.model, >> so we should do the same with endianness. >> >> To add to the confusion, other JDKs are reporting it as ppc64le >> (thanks to Tiago Sturmer Daitx for these results): >> >> IBM Java 2.7 SR1 >> os.arch: ppc64le >> sun.cpu.endian: little >> >> GCJ 4.8.2 (gij (GNU libgcj) version 4.8.2): >> os.arch: ppc64le >> sun.cpu.endian: null >> >> whereas OpenJDK gives: >> >> os.arch: ppc64 >> sun.cpu.endian: little >> >> It also means that ppc64le is alone in not having a unique architecture >> directory in jre/lib. I understand that a ppc64le machine is not going >> to support ppc64be, but likewise amd64 is not going to support arm, >> yet they have unique arch directories. >> >> I've prepared a webrev which fixes the external facing architecture names, >> LIBARCH and os.name, while leaving the HotSpot build architecture, BUILDARCH, >> as it is, to avoid the duplication mentioned as a problem in the original >> review. >> >> http://cr.openjdk.java.net/~andrew/rh1191652/webrev.01/ >> >> This is against our IcedTea OpenJDK7-based HotSpot where we've been testing >> but it should still be applicable to the 9 HotSpot repositories. The JDK side >> is another issue and I suspect we'll need a completely different patch there >> to the one we have for 7. >> >> Our builds of OpenJDK 7 with this fixed now give: >> >> java.library.path = /usr/java/packages/lib/ppc64le:/usr/lib64:/lib64:/lib:/usr/lib >> sun.boot.library.path = /builddir/build/BUILD/java-1.7.0-openjdk-1.7.0.75-2.5.4.5.ael7b.ppc64le/openjdk/build/linux-ppc64le/j2sdk-image/jre/lib/ppc64le >> os.arch = ppc64le >> >> I've filed a bug for this here: >> >> https://bugs.openjdk.java.net/browse/JDK-8073139 >> >> Thanks, >> -- >> Andrew :) >> >> 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 >> >> PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) >> Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 >> > > Hi Andrew, > > I don't have a problem with your change and it doesn't affect the > ppc64 big endian build. > > I've prepared a patch which applies cleanly to jdk9-hs-rt here: > > http://cr.openjdk.java.net/~simonis/webrevs/2015/8073139/ > > Let's here some other opinions as well (you'll need a sponsor from > Oracle anyway and it would also be interesting to here from Alexander > if they already rely on os.arch being ppc64) but from my side thumbs > up. > > Regards, > Volker From volker.simonis at gmail.com Fri Feb 13 17:40:11 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 13 Feb 2015 18:40:11 +0100 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: References: <531E8309.2060206@oracle.com> <531ED06F.5040905@oracle.com> <107001365.11810418.1423839439509.JavaMail.zimbra@redhat.com> Message-ID: OK, sounds good. So Andrew, could you please elaborate what other changes this would require for the other repositories like jdk and top-level (preferably in the jdk9 context because that's where we've to start with before we can downport this to 8u-dev). Volker On Fri, Feb 13, 2015 at 6:25 PM, Alexander Smundak wrote: > I was always in favor of having ppc64le as a separate architecture. > I hope this will be backported to JDK8? > > On Fri, Feb 13, 2015 at 8:37 AM, Volker Simonis > wrote: >> On Fri, Feb 13, 2015 at 3:57 PM, Andrew Hughes wrote: >>> ----- Original Message ----- >>>> On 11/03/2014 6:36 PM, Volker Simonis wrote: >>>> > On Tue, Mar 11, 2014 at 4:29 AM, David Holmes >>>> > wrote: >>>> >> I don't see anything that actually controls what is built. Is it the case >>>> >> that the new arch value will be reported by uname on the ppc64le system? >>>> >> >>>> >> (I cringe seeing a new top-level arch introduced for this.) >>>> >> >>>> > >>>> > I didn't liked this too much as well in my first review and I think we >>>> > can get along without a new top-level arch (see >>>> > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2014-March/001790.html). >>>> > >>>> > But in the end I can live with both approaches (and having two >>>> > top-level archs probably makes it slightly simpler to support them >>>> > both in parallel) so I think finally it is up to you which approach we >>>> > take. >>>> >>>> I agree with your initial review. I don't see a LE build as a distinct >>>> architecture but a variant of ppc64. >>>> >>>> Lets see what anyone else has to say. >>>> >>>> Thanks, >>>> David >>>> >>>> >>>> >>>> >>>> >>>> > Regards, >>>> > Volker >>>> > >>>> >> Thanks, >>>> >> David >>>> >> >>>> >> >>>> >> On 7/03/2014 1:37 PM, Alexander Smundak wrote: >>>> >>> >>>> >>> This patch contains the changes to the build files to build JDK on the >>>> >>> little endian PowerPC64 running Linux, and the changes to the source >>>> >>> files to support little endian mode. >>>> >>> This preceding related change >>>> >>> https://bugs.openjdk.java.net/browse/JDK-8036767 added support for the >>>> >>> ELFv2 ABi used on the little endian PowerPC64. >>>> >>> >>>> >>> Please review and test this change. I need a sponsor. >>>> >>> >>>> >>> The patch is at: >>>> >>> http://cr.openjdk.java.net/~martin/asmundak/8036767/webrev.00/ >>>> >>> >>>> >>> Sasha >>>> >>> >>>> >> >>>> >>> >>> We're now seeing problems with Java tools on ppc64le as a result of this >>> decision not to give it a distinct arch name. >>> >>> The os.arch property on both ppc64be and ppc64le builds of OpenJDK is being >>> reported as the same; "ppc64". This leaves Java applications no way of >>> determining which of the two platforms the JDK is running on and, for example, >>> means that Maven can't determine which native JNI binaries to download. >>> >>> There is a sun.cpu.endian property but this is non-standard and it seems >>> wrong to me that every Java tool should have to add a special case for >>> ppc64le using such a property. This value is traditionally not so much >>> just the architecture as a composite of the architecture, the bit size >>> and the endianness. The only difference with other platforms is that they >>> only support one default endianness so the value is implied e.g. >>> little-endian for amd64, big-endian for sparc. We do distinguish between >>> ppc and ppc64 rather than expecting tools to check sun.arch.data.model, >>> so we should do the same with endianness. >>> >>> To add to the confusion, other JDKs are reporting it as ppc64le >>> (thanks to Tiago Sturmer Daitx for these results): >>> >>> IBM Java 2.7 SR1 >>> os.arch: ppc64le >>> sun.cpu.endian: little >>> >>> GCJ 4.8.2 (gij (GNU libgcj) version 4.8.2): >>> os.arch: ppc64le >>> sun.cpu.endian: null >>> >>> whereas OpenJDK gives: >>> >>> os.arch: ppc64 >>> sun.cpu.endian: little >>> >>> It also means that ppc64le is alone in not having a unique architecture >>> directory in jre/lib. I understand that a ppc64le machine is not going >>> to support ppc64be, but likewise amd64 is not going to support arm, >>> yet they have unique arch directories. >>> >>> I've prepared a webrev which fixes the external facing architecture names, >>> LIBARCH and os.name, while leaving the HotSpot build architecture, BUILDARCH, >>> as it is, to avoid the duplication mentioned as a problem in the original >>> review. >>> >>> http://cr.openjdk.java.net/~andrew/rh1191652/webrev.01/ >>> >>> This is against our IcedTea OpenJDK7-based HotSpot where we've been testing >>> but it should still be applicable to the 9 HotSpot repositories. The JDK side >>> is another issue and I suspect we'll need a completely different patch there >>> to the one we have for 7. >>> >>> Our builds of OpenJDK 7 with this fixed now give: >>> >>> java.library.path = /usr/java/packages/lib/ppc64le:/usr/lib64:/lib64:/lib:/usr/lib >>> sun.boot.library.path = /builddir/build/BUILD/java-1.7.0-openjdk-1.7.0.75-2.5.4.5.ael7b.ppc64le/openjdk/build/linux-ppc64le/j2sdk-image/jre/lib/ppc64le >>> os.arch = ppc64le >>> >>> I've filed a bug for this here: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8073139 >>> >>> Thanks, >>> -- >>> Andrew :) >>> >>> 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 >>> >>> PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) >>> Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 >>> >> >> Hi Andrew, >> >> I don't have a problem with your change and it doesn't affect the >> ppc64 big endian build. >> >> I've prepared a patch which applies cleanly to jdk9-hs-rt here: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2015/8073139/ >> >> Let's here some other opinions as well (you'll need a sponsor from >> Oracle anyway and it would also be interesting to here from Alexander >> if they already rely on os.arch being ppc64) but from my side thumbs >> up. >> >> Regards, >> Volker From dean.long at oracle.com Fri Feb 13 22:52:07 2015 From: dean.long at oracle.com (Dean Long) Date: Fri, 13 Feb 2015 14:52:07 -0800 Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses In-Reply-To: <54DDFE72.1050306@redhat.com> References: <54DDFE72.1050306@redhat.com> Message-ID: <54DE8017.6080608@oracle.com> My understanding is that whether or not aarch64 allows unaligned accesses is based on a system setting, so this change is too simplistic. I would prefer that this was controlled with something more flexible, like "sun.cpu.unaligned". dl On 2/13/2015 5:38 AM, Andrew Haley wrote: > java.?nio.?DirectByteBuffer.getXXX is slow for types larger than byte > because the runtime does not know that AArch64 can perform unaligned > memory accesses. > > The problem is due to this code in java.nio.Bits.unaligned(): > > unaligned = arch.equals("i386") || arch.equals("x86") > || arch.equals("amd64") || arch.equals("x86_64"); > > If we add AArch64 to this list code quality is very much improved. > > http://cr.openjdk.java.net/~aph/8073093/ > > Thanks, > Andrew. From christos at zoulas.com Fri Feb 13 23:04:16 2015 From: christos at zoulas.com (Christos Zoulas) Date: Fri, 13 Feb 2015 18:04:16 -0500 Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses In-Reply-To: <54DE8017.6080608@oracle.com> from Dean Long (Feb 13, 2:52pm) Message-ID: <20150213230416.5E7B617FDAA@rebar.astron.com> On Feb 13, 2:52pm, dean.long at oracle.com (Dean Long) wrote: -- Subject: Re: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer | My understanding is that whether or not aarch64 allows unaligned=20 | accesses is based on a | system setting, so this change is too simplistic. I would prefer that=20 | this was controlled with | something more flexible, like "sun.cpu.unaligned". So does x86_64 and you can ask the CPU if it is enabled... I am not sure if a variable setting makes sense because if alignment is required you get a signal (BUS error -- hi linux, SEGV), or incorrect results. christos From dean.long at oracle.com Fri Feb 13 23:41:43 2015 From: dean.long at oracle.com (Dean Long) Date: Fri, 13 Feb 2015 15:41:43 -0800 Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses In-Reply-To: <20150213230416.5E7B617FDAA@rebar.astron.com> References: <20150213230416.5E7B617FDAA@rebar.astron.com> Message-ID: <54DE8BB7.5050801@oracle.com> On 2/13/2015 3:04 PM, christos at zoulas.com wrote: > On Feb 13, 2:52pm, dean.long at oracle.com (Dean Long) wrote: > -- Subject: Re: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer > > | My understanding is that whether or not aarch64 allows unaligned=20 > | accesses is based on a > | system setting, so this change is too simplistic. I would prefer that=20 > | this was controlled with > | something more flexible, like "sun.cpu.unaligned". > > So does x86_64 and you can ask the CPU if it is enabled... I am not sure > if a variable setting makes sense because if alignment is required you > get a signal (BUS error -- hi linux, SEGV), or incorrect results. > > christos So it sounds like we need to determine if unaligned accesses are supported during startup, in a platform-specific way. This could be exposed through a property like I suggested, or perhaps a new Unsafe method. Regarding x86_64, there may be places in the JVM that already assume unaligned accesses are allowed, so disabling them may completely break the JVM until those assumptions are fixed. dl From vladimir.kozlov at oracle.com Sat Feb 14 00:05:20 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 13 Feb 2015 16:05:20 -0800 Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses In-Reply-To: <54DE8BB7.5050801@oracle.com> References: <20150213230416.5E7B617FDAA@rebar.astron.com> <54DE8BB7.5050801@oracle.com> Message-ID: <54DE9140.3040604@oracle.com> x86 has flag UseUnalignedLoadStores which is set to true depending on which version of CPU VM runs. The CPU version is determined based on CPUID instruction results. Does AARCH64 has something similar? Regards, Vladimir On 2/13/15 3:41 PM, Dean Long wrote: > On 2/13/2015 3:04 PM, christos at zoulas.com wrote: >> On Feb 13, 2:52pm, dean.long at oracle.com (Dean Long) wrote: >> -- Subject: Re: RFR: 8073093: AARCH64: C2 generates poor code for >> ByteBuffer >> >> | My understanding is that whether or not aarch64 allows unaligned=20 >> | accesses is based on a >> | system setting, so this change is too simplistic. I would prefer >> that=20 >> | this was controlled with >> | something more flexible, like "sun.cpu.unaligned". >> >> So does x86_64 and you can ask the CPU if it is enabled... I am not sure >> if a variable setting makes sense because if alignment is required you >> get a signal (BUS error -- hi linux, SEGV), or incorrect results. >> >> christos > > So it sounds like we need to determine if unaligned accesses are > supported during startup, > in a platform-specific way. This could be exposed through a property > like I suggested, > or perhaps a new Unsafe method. > > Regarding x86_64, there may be places in the JVM that already assume > unaligned accesses > are allowed, so disabling them may completely break the JVM until those > assumptions > are fixed. > > dl From john.r.rose at oracle.com Sat Feb 14 00:09:17 2015 From: john.r.rose at oracle.com (John Rose) Date: Fri, 13 Feb 2015 16:09:17 -0800 Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses In-Reply-To: <54DE9140.3040604@oracle.com> References: <20150213230416.5E7B617FDAA@rebar.astron.com> <54DE8BB7.5050801@oracle.com> <54DE9140.3040604@oracle.com> Message-ID: These queries need to go into Unsafe. We also need Unsafe.getIntMisaligned, etc., which wire through to whatever second-best mechanism the platform offers. ? John From dean.long at oracle.com Sat Feb 14 00:22:51 2015 From: dean.long at oracle.com (Dean Long) Date: Fri, 13 Feb 2015 16:22:51 -0800 Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses In-Reply-To: <54DE9140.3040604@oracle.com> References: <20150213230416.5E7B617FDAA@rebar.astron.com> <54DE8BB7.5050801@oracle.com> <54DE9140.3040604@oracle.com> Message-ID: <54DE955B.4050905@oracle.com> There is a system register bit to read, but I don't think it can be accessed by an application, only the kernel. If the OS won't provide this information, you could do something similar to safeFetchN and catch the resulting SIGBUS. dl On 2/13/2015 4:05 PM, Vladimir Kozlov wrote: > x86 has flag UseUnalignedLoadStores which is set to true depending on > which version of CPU VM runs. The CPU version is determined based on > CPUID instruction results. > > Does AARCH64 has something similar? > > Regards, > Vladimir > > On 2/13/15 3:41 PM, Dean Long wrote: >> On 2/13/2015 3:04 PM, christos at zoulas.com wrote: >>> On Feb 13, 2:52pm, dean.long at oracle.com (Dean Long) wrote: >>> -- Subject: Re: RFR: 8073093: AARCH64: C2 generates poor code for >>> ByteBuffer >>> >>> | My understanding is that whether or not aarch64 allows unaligned=20 >>> | accesses is based on a >>> | system setting, so this change is too simplistic. I would prefer >>> that=20 >>> | this was controlled with >>> | something more flexible, like "sun.cpu.unaligned". >>> >>> So does x86_64 and you can ask the CPU if it is enabled... I am not >>> sure >>> if a variable setting makes sense because if alignment is required you >>> get a signal (BUS error -- hi linux, SEGV), or incorrect results. >>> >>> christos >> >> So it sounds like we need to determine if unaligned accesses are >> supported during startup, >> in a platform-specific way. This could be exposed through a property >> like I suggested, >> or perhaps a new Unsafe method. >> >> Regarding x86_64, there may be places in the JVM that already assume >> unaligned accesses >> are allowed, so disabling them may completely break the JVM until those >> assumptions >> are fixed. >> >> dl From vladimir.kozlov at oracle.com Sat Feb 14 00:29:28 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 13 Feb 2015 16:29:28 -0800 Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses In-Reply-To: <54DE955B.4050905@oracle.com> References: <20150213230416.5E7B617FDAA@rebar.astron.com> <54DE8BB7.5050801@oracle.com> <54DE9140.3040604@oracle.com> <54DE955B.4050905@oracle.com> Message-ID: <54DE96E8.3030608@oracle.com> On 2/13/15 4:22 PM, Dean Long wrote: > There is a system register bit to read, but I don't think it can be > accessed by an application, only the kernel. > If the OS won't provide this information, you could do something similar > to safeFetchN and catch the > resulting SIGBUS. Yes, I agree it could be done this way too. On x86 we trigger SEGV to verify that OS's signal handler correctly save/restore AVX registers so we can use them. Vladimir > > dl > > On 2/13/2015 4:05 PM, Vladimir Kozlov wrote: >> x86 has flag UseUnalignedLoadStores which is set to true depending on >> which version of CPU VM runs. The CPU version is determined based on >> CPUID instruction results. >> >> Does AARCH64 has something similar? >> >> Regards, >> Vladimir >> >> On 2/13/15 3:41 PM, Dean Long wrote: >>> On 2/13/2015 3:04 PM, christos at zoulas.com wrote: >>>> On Feb 13, 2:52pm, dean.long at oracle.com (Dean Long) wrote: >>>> -- Subject: Re: RFR: 8073093: AARCH64: C2 generates poor code for >>>> ByteBuffer >>>> >>>> | My understanding is that whether or not aarch64 allows unaligned=20 >>>> | accesses is based on a >>>> | system setting, so this change is too simplistic. I would prefer >>>> that=20 >>>> | this was controlled with >>>> | something more flexible, like "sun.cpu.unaligned". >>>> >>>> So does x86_64 and you can ask the CPU if it is enabled... I am not >>>> sure >>>> if a variable setting makes sense because if alignment is required you >>>> get a signal (BUS error -- hi linux, SEGV), or incorrect results. >>>> >>>> christos >>> >>> So it sounds like we need to determine if unaligned accesses are >>> supported during startup, >>> in a platform-specific way. This could be exposed through a property >>> like I suggested, >>> or perhaps a new Unsafe method. >>> >>> Regarding x86_64, there may be places in the JVM that already assume >>> unaligned accesses >>> are allowed, so disabling them may completely break the JVM until those >>> assumptions >>> are fixed. >>> >>> dl > From christos at zoulas.com Sat Feb 14 03:34:41 2015 From: christos at zoulas.com (Christos Zoulas) Date: Fri, 13 Feb 2015 22:34:41 -0500 Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses In-Reply-To: <54DE96E8.3030608@oracle.com> from Vladimir Kozlov (Feb 13, 4:29pm) Message-ID: <20150214033441.8238417FDAA@rebar.astron.com> On Feb 13, 4:29pm, vladimir.kozlov at oracle.com (Vladimir Kozlov) wrote: -- Subject: Re: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer | On 2/13/15 4:22 PM, Dean Long wrote: | > There is a system register bit to read, but I don't think it can be | > accessed by an application, only the kernel. | > If the OS won't provide this information, you could do something similar | > to safeFetchN and catch the | > resulting SIGBUS. | | Yes, I agree it could be done this way too. | On x86 we trigger SEGV to verify that OS's signal handler correctly | save/restore AVX registers so we can use them. It is PSL_AC (0x40000) and it is accessible by applications. Now if it works or not depends on the flavor of the x86... As I mentioned before there are implementations (for example pre-arm-v6 flavors) where unaligned accesses don't signal (but don't work). There is an even 3rd category where unaligned accesses trap, but the kernel can fix them if the binary is marked specially (sparc with misaligned for example). The "portable" to verify what's going on is to do the misaligned access and see if it works (dealing with SIGBUS/SIGSEGV). Even then (even when it works) you might not want to do it because of performance reasons (for example when the kernel fixes it). christos From aph at redhat.com Sat Feb 14 08:01:08 2015 From: aph at redhat.com (Andrew Haley) Date: Sat, 14 Feb 2015 08:01:08 +0000 Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses In-Reply-To: References: <20150213230416.5E7B617FDAA@rebar.astron.com> <54DE8BB7.5050801@oracle.com> <54DE9140.3040604@oracle.com> Message-ID: <54DF00C4.7030308@redhat.com> On 02/14/2015 12:09 AM, John Rose wrote: > We also need Unsafe.getIntMisaligned, etc., which wire through to whatever second-best mechanism the platform offers. Indeed. I'm intending to prototype a design for those next week. OK? Andrew. From aph at redhat.com Sat Feb 14 08:07:06 2015 From: aph at redhat.com (Andrew Haley) Date: Sat, 14 Feb 2015 08:07:06 +0000 Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses In-Reply-To: <54DE8017.6080608@oracle.com> References: <54DDFE72.1050306@redhat.com> <54DE8017.6080608@oracle.com> Message-ID: <54DF022A.9080707@redhat.com> On 02/13/2015 10:52 PM, Dean Long wrote: > My understanding is that whether or not aarch64 allows unaligned > accesses is based on a system setting, so this change is too > simplistic. Disabling unaligned access would be a really perverse thing to do, and I suspect that GCC and glibc already assume that unaligned accesses work so it would require a recompilation of libjvm (and probably the whole OS) to make it work. However, if you really think there's a point to making this a runtime flag I won't resist. Andrew. From chris.plummer at oracle.com Sat Feb 14 08:59:16 2015 From: chris.plummer at oracle.com (Chris Plummer) Date: Sat, 14 Feb 2015 00:59:16 -0800 Subject: [9] RFR (VS) 8073167: Undo change to -retain argument in hotspot/test/Makefile Message-ID: <54DF0E64.9000602@oracle.com> Can I get a quick review of this please. My commit yesterday for JDK-8054888 included a minor makefile change that was just there for debugging and wasn't suppose to be part of the commit. See http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/034eb71ab7fd http://cr.openjdk.java.net/~cjplummer/8073167/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8073167 thanks, Chris From staffan.larsen at oracle.com Sat Feb 14 09:47:33 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Sat, 14 Feb 2015 10:47:33 +0100 Subject: [9] RFR (VS) 8073167: Undo change to -retain argument in hotspot/test/Makefile In-Reply-To: <54DF0E64.9000602@oracle.com> References: <54DF0E64.9000602@oracle.com> Message-ID: Looks good! Thanks, /Staffan > On 14 feb 2015, at 09:59, Chris Plummer wrote: > > Can I get a quick review of this please. My commit yesterday for JDK-8054888 included a minor makefile change that was just there for debugging and wasn't suppose to be part of the commit. See http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/034eb71ab7fd > > http://cr.openjdk.java.net/~cjplummer/8073167/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8073167 > > thanks, > > Chris From chris.plummer at oracle.com Sat Feb 14 17:05:25 2015 From: chris.plummer at oracle.com (Chris Plummer) Date: Sat, 14 Feb 2015 09:05:25 -0800 Subject: [9] RFR (VS) 8073167: Undo change to -retain argument in hotspot/test/Makefile In-Reply-To: References: <54DF0E64.9000602@oracle.com> Message-ID: <54DF8055.4020509@oracle.com> Thanks Staffan! Chris On 2/14/15 1:47 AM, Staffan Larsen wrote: > Looks good! > > Thanks, > /Staffan > >> On 14 feb 2015, at 09:59, Chris Plummer wrote: >> >> Can I get a quick review of this please. My commit yesterday for JDK-8054888 included a minor makefile change that was just there for debugging and wasn't suppose to be part of the commit. See http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/034eb71ab7fd >> >> http://cr.openjdk.java.net/~cjplummer/8073167/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8073167 >> >> thanks, >> >> Chris From dean.long at oracle.com Sat Feb 14 22:10:59 2015 From: dean.long at oracle.com (Dean Long) Date: Sat, 14 Feb 2015 14:10:59 -0800 Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses In-Reply-To: <54DF022A.9080707@redhat.com> References: <54DDFE72.1050306@redhat.com> <54DE8017.6080608@oracle.com> <54DF022A.9080707@redhat.com> Message-ID: <54DFC7F3.9050309@oracle.com> On 2/14/2015 12:07 AM, Andrew Haley wrote: > On 02/13/2015 10:52 PM, Dean Long wrote: > >> My understanding is that whether or not aarch64 allows unaligned >> accesses is based on a system setting, so this change is too >> simplistic. > Disabling unaligned access would be a really perverse thing to do, and > I suspect that GCC and glibc already assume that unaligned accesses > work so it would require a recompilation of libjvm (and probably the > whole OS) to make it work. However, if you really think there's a > point to making this a runtime flag I won't resist. > > Andrew. Even if linux-aarch64 always allows unaligned, checking only for "aarch64" is not future-proof because it doesn't take the OS into account. However, I really don't like having to enumerate all relevant platforms in multiple places in shared code, so I disagree with the existing code and with perpetuating the pattern. As long as the decision is in platform-specific code, a build-time decision may be entirely appropriate. dl From david.holmes at oracle.com Mon Feb 16 05:44:24 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 16 Feb 2015 15:44:24 +1000 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: References: <531E8309.2060206@oracle.com> <531ED06F.5040905@oracle.com> <107001365.11810418.1423839439509.JavaMail.zimbra@redhat.com> Message-ID: <54E183B8.5010301@oracle.com> I have no issue with this minimal change for hotspot. I suppose I can also volunteer to sponsor it. :) Is the plan to also do the JDK changes under the same bug? That will need build-dev involvement. David On 14/02/2015 2:37 AM, Volker Simonis wrote: > On Fri, Feb 13, 2015 at 3:57 PM, Andrew Hughes wrote: >> ----- Original Message ----- >>> On 11/03/2014 6:36 PM, Volker Simonis wrote: >>>> On Tue, Mar 11, 2014 at 4:29 AM, David Holmes >>>> wrote: >>>>> I don't see anything that actually controls what is built. Is it the case >>>>> that the new arch value will be reported by uname on the ppc64le system? >>>>> >>>>> (I cringe seeing a new top-level arch introduced for this.) >>>>> >>>> >>>> I didn't liked this too much as well in my first review and I think we >>>> can get along without a new top-level arch (see >>>> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2014-March/001790.html). >>>> >>>> But in the end I can live with both approaches (and having two >>>> top-level archs probably makes it slightly simpler to support them >>>> both in parallel) so I think finally it is up to you which approach we >>>> take. >>> >>> I agree with your initial review. I don't see a LE build as a distinct >>> architecture but a variant of ppc64. >>> >>> Lets see what anyone else has to say. >>> >>> Thanks, >>> David >>> >>> >>> >>> >>> >>>> Regards, >>>> Volker >>>> >>>>> Thanks, >>>>> David >>>>> >>>>> >>>>> On 7/03/2014 1:37 PM, Alexander Smundak wrote: >>>>>> >>>>>> This patch contains the changes to the build files to build JDK on the >>>>>> little endian PowerPC64 running Linux, and the changes to the source >>>>>> files to support little endian mode. >>>>>> This preceding related change >>>>>> https://bugs.openjdk.java.net/browse/JDK-8036767 added support for the >>>>>> ELFv2 ABi used on the little endian PowerPC64. >>>>>> >>>>>> Please review and test this change. I need a sponsor. >>>>>> >>>>>> The patch is at: >>>>>> http://cr.openjdk.java.net/~martin/asmundak/8036767/webrev.00/ >>>>>> >>>>>> Sasha >>>>>> >>>>> >>> >> >> We're now seeing problems with Java tools on ppc64le as a result of this >> decision not to give it a distinct arch name. >> >> The os.arch property on both ppc64be and ppc64le builds of OpenJDK is being >> reported as the same; "ppc64". This leaves Java applications no way of >> determining which of the two platforms the JDK is running on and, for example, >> means that Maven can't determine which native JNI binaries to download. >> >> There is a sun.cpu.endian property but this is non-standard and it seems >> wrong to me that every Java tool should have to add a special case for >> ppc64le using such a property. This value is traditionally not so much >> just the architecture as a composite of the architecture, the bit size >> and the endianness. The only difference with other platforms is that they >> only support one default endianness so the value is implied e.g. >> little-endian for amd64, big-endian for sparc. We do distinguish between >> ppc and ppc64 rather than expecting tools to check sun.arch.data.model, >> so we should do the same with endianness. >> >> To add to the confusion, other JDKs are reporting it as ppc64le >> (thanks to Tiago Sturmer Daitx for these results): >> >> IBM Java 2.7 SR1 >> os.arch: ppc64le >> sun.cpu.endian: little >> >> GCJ 4.8.2 (gij (GNU libgcj) version 4.8.2): >> os.arch: ppc64le >> sun.cpu.endian: null >> >> whereas OpenJDK gives: >> >> os.arch: ppc64 >> sun.cpu.endian: little >> >> It also means that ppc64le is alone in not having a unique architecture >> directory in jre/lib. I understand that a ppc64le machine is not going >> to support ppc64be, but likewise amd64 is not going to support arm, >> yet they have unique arch directories. >> >> I've prepared a webrev which fixes the external facing architecture names, >> LIBARCH and os.name, while leaving the HotSpot build architecture, BUILDARCH, >> as it is, to avoid the duplication mentioned as a problem in the original >> review. >> >> http://cr.openjdk.java.net/~andrew/rh1191652/webrev.01/ >> >> This is against our IcedTea OpenJDK7-based HotSpot where we've been testing >> but it should still be applicable to the 9 HotSpot repositories. The JDK side >> is another issue and I suspect we'll need a completely different patch there >> to the one we have for 7. >> >> Our builds of OpenJDK 7 with this fixed now give: >> >> java.library.path = /usr/java/packages/lib/ppc64le:/usr/lib64:/lib64:/lib:/usr/lib >> sun.boot.library.path = /builddir/build/BUILD/java-1.7.0-openjdk-1.7.0.75-2.5.4.5.ael7b.ppc64le/openjdk/build/linux-ppc64le/j2sdk-image/jre/lib/ppc64le >> os.arch = ppc64le >> >> I've filed a bug for this here: >> >> https://bugs.openjdk.java.net/browse/JDK-8073139 >> >> Thanks, >> -- >> Andrew :) >> >> 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 >> >> PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) >> Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 >> > > Hi Andrew, > > I don't have a problem with your change and it doesn't affect the > ppc64 big endian build. > > I've prepared a patch which applies cleanly to jdk9-hs-rt here: > > http://cr.openjdk.java.net/~simonis/webrevs/2015/8073139/ > > Let's here some other opinions as well (you'll need a sponsor from > Oracle anyway and it would also be interesting to here from Alexander > if they already rely on os.arch being ppc64) but from my side thumbs > up. > > Regards, > Volker > From goetz.lindenmaier at sap.com Mon Feb 16 09:19:14 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 16 Feb 2015 09:19:14 +0000 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <54E183B8.5010301@oracle.com> References: <531E8309.2060206@oracle.com> <531ED06F.5040905@oracle.com> <107001365.11810418.1423839439509.JavaMail.zimbra@redhat.com> <54E183B8.5010301@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CF9594E@DEWDFEMB12A.global.corp.sap> Hi, The change looks good. I'll push it into the jdk7 ppc port directory once it's in 8. Best regards, Goetz. -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of David Holmes Sent: Montag, 16. Februar 2015 06:44 To: Volker Simonis; Andrew Hughes Cc: HotSpot Open Source Developers; Alexander Smundak Subject: Re: RFR (M): 8036767 PPC64: Support for little endian execution model I have no issue with this minimal change for hotspot. I suppose I can also volunteer to sponsor it. :) Is the plan to also do the JDK changes under the same bug? That will need build-dev involvement. David On 14/02/2015 2:37 AM, Volker Simonis wrote: > On Fri, Feb 13, 2015 at 3:57 PM, Andrew Hughes wrote: >> ----- Original Message ----- >>> On 11/03/2014 6:36 PM, Volker Simonis wrote: >>>> On Tue, Mar 11, 2014 at 4:29 AM, David Holmes >>>> wrote: >>>>> I don't see anything that actually controls what is built. Is it the case >>>>> that the new arch value will be reported by uname on the ppc64le system? >>>>> >>>>> (I cringe seeing a new top-level arch introduced for this.) >>>>> >>>> >>>> I didn't liked this too much as well in my first review and I think we >>>> can get along without a new top-level arch (see >>>> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2014-March/001790.html). >>>> >>>> But in the end I can live with both approaches (and having two >>>> top-level archs probably makes it slightly simpler to support them >>>> both in parallel) so I think finally it is up to you which approach we >>>> take. >>> >>> I agree with your initial review. I don't see a LE build as a distinct >>> architecture but a variant of ppc64. >>> >>> Lets see what anyone else has to say. >>> >>> Thanks, >>> David >>> >>> >>> >>> >>> >>>> Regards, >>>> Volker >>>> >>>>> Thanks, >>>>> David >>>>> >>>>> >>>>> On 7/03/2014 1:37 PM, Alexander Smundak wrote: >>>>>> >>>>>> This patch contains the changes to the build files to build JDK on the >>>>>> little endian PowerPC64 running Linux, and the changes to the source >>>>>> files to support little endian mode. >>>>>> This preceding related change >>>>>> https://bugs.openjdk.java.net/browse/JDK-8036767 added support for the >>>>>> ELFv2 ABi used on the little endian PowerPC64. >>>>>> >>>>>> Please review and test this change. I need a sponsor. >>>>>> >>>>>> The patch is at: >>>>>> http://cr.openjdk.java.net/~martin/asmundak/8036767/webrev.00/ >>>>>> >>>>>> Sasha >>>>>> >>>>> >>> >> >> We're now seeing problems with Java tools on ppc64le as a result of this >> decision not to give it a distinct arch name. >> >> The os.arch property on both ppc64be and ppc64le builds of OpenJDK is being >> reported as the same; "ppc64". This leaves Java applications no way of >> determining which of the two platforms the JDK is running on and, for example, >> means that Maven can't determine which native JNI binaries to download. >> >> There is a sun.cpu.endian property but this is non-standard and it seems >> wrong to me that every Java tool should have to add a special case for >> ppc64le using such a property. This value is traditionally not so much >> just the architecture as a composite of the architecture, the bit size >> and the endianness. The only difference with other platforms is that they >> only support one default endianness so the value is implied e.g. >> little-endian for amd64, big-endian for sparc. We do distinguish between >> ppc and ppc64 rather than expecting tools to check sun.arch.data.model, >> so we should do the same with endianness. >> >> To add to the confusion, other JDKs are reporting it as ppc64le >> (thanks to Tiago Sturmer Daitx for these results): >> >> IBM Java 2.7 SR1 >> os.arch: ppc64le >> sun.cpu.endian: little >> >> GCJ 4.8.2 (gij (GNU libgcj) version 4.8.2): >> os.arch: ppc64le >> sun.cpu.endian: null >> >> whereas OpenJDK gives: >> >> os.arch: ppc64 >> sun.cpu.endian: little >> >> It also means that ppc64le is alone in not having a unique architecture >> directory in jre/lib. I understand that a ppc64le machine is not going >> to support ppc64be, but likewise amd64 is not going to support arm, >> yet they have unique arch directories. >> >> I've prepared a webrev which fixes the external facing architecture names, >> LIBARCH and os.name, while leaving the HotSpot build architecture, BUILDARCH, >> as it is, to avoid the duplication mentioned as a problem in the original >> review. >> >> http://cr.openjdk.java.net/~andrew/rh1191652/webrev.01/ >> >> This is against our IcedTea OpenJDK7-based HotSpot where we've been testing >> but it should still be applicable to the 9 HotSpot repositories. The JDK side >> is another issue and I suspect we'll need a completely different patch there >> to the one we have for 7. >> >> Our builds of OpenJDK 7 with this fixed now give: >> >> java.library.path = /usr/java/packages/lib/ppc64le:/usr/lib64:/lib64:/lib:/usr/lib >> sun.boot.library.path = /builddir/build/BUILD/java-1.7.0-openjdk-1.7.0.75-2.5.4.5.ael7b.ppc64le/openjdk/build/linux-ppc64le/j2sdk-image/jre/lib/ppc64le >> os.arch = ppc64le >> >> I've filed a bug for this here: >> >> https://bugs.openjdk.java.net/browse/JDK-8073139 >> >> Thanks, >> -- >> Andrew :) >> >> 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 >> >> PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) >> Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 >> > > Hi Andrew, > > I don't have a problem with your change and it doesn't affect the > ppc64 big endian build. > > I've prepared a patch which applies cleanly to jdk9-hs-rt here: > > http://cr.openjdk.java.net/~simonis/webrevs/2015/8073139/ > > Let's here some other opinions as well (you'll need a sponsor from > Oracle anyway and it would also be interesting to here from Alexander > if they already rely on os.arch being ppc64) but from my side thumbs > up. > > Regards, > Volker > From aph at redhat.com Mon Feb 16 09:38:29 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 16 Feb 2015 09:38:29 +0000 Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses In-Reply-To: <54DFC7F3.9050309@oracle.com> References: <54DDFE72.1050306@redhat.com> <54DE8017.6080608@oracle.com> <54DF022A.9080707@redhat.com> <54DFC7F3.9050309@oracle.com> Message-ID: <54E1BA95.7030806@redhat.com> On 14/02/15 22:10, Dean Long wrote: > On 2/14/2015 12:07 AM, Andrew Haley wrote: >> On 02/13/2015 10:52 PM, Dean Long wrote: >> >>> My understanding is that whether or not aarch64 allows unaligned >>> accesses is based on a system setting, so this change is too >>> simplistic. >> >> Disabling unaligned access would be a really perverse thing to do, and >> I suspect that GCC and glibc already assume that unaligned accesses >> work so it would require a recompilation of libjvm (and probably the >> whole OS) to make it work. However, if you really think there's a >> point to making this a runtime flag I won't resist. > > Even if linux-aarch64 always allows unaligned, checking only for > "aarch64" is not future-proof because it doesn't take the OS into > account. Sure, but we can't predict all the crazy things that writers of future operating systems might do. > However, I really don't like having to enumerate all relevant > platforms in multiple places in shared code, so I disagree with the > existing code and with perpetuating the pattern. As long as the > decision is in platform-specific code, a build-time decision may be > entirely appropriate. That makes sense. I don't like the way that the decision is hidden in shared code either: if it had been in a more obvious place I would have found it earlier. I'll have a look at writing an Unsafe method which does the right thing. Andrew. From Alan.Bateman at oracle.com Mon Feb 16 11:02:19 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 16 Feb 2015 11:02:19 +0000 Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses In-Reply-To: <54DFC7F3.9050309@oracle.com> References: <54DDFE72.1050306@redhat.com> <54DE8017.6080608@oracle.com> <54DF022A.9080707@redhat.com> <54DFC7F3.9050309@oracle.com> Message-ID: <54E1CE3B.1020707@oracle.com> On 14/02/2015 22:10, Dean Long wrote: > > Even if linux-aarch64 always allows unaligned, checking only for > "aarch64" is not future-proof > because it doesn't take the OS into account. However, I really don't > like having to enumerate > all relevant platforms in multiple places in shared code, so I > disagree with the existing code > and with perpetuating the pattern. As long as the decision is in > platform-specific code, a build-time > decision may be entirely appropriate. This alignment test in Bits.java has been there for a long time (JDK 1.4). It's technical debt that hasn't surfaces very often as it's so rare to add architectures. If Unsafe gets a method to test the alignment then it would be great to get Bits changed. -Alan From aph at redhat.com Mon Feb 16 11:05:18 2015 From: aph at redhat.com (Andrew Haley) Date: Mon, 16 Feb 2015 11:05:18 +0000 Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses In-Reply-To: <54E1CE3B.1020707@oracle.com> References: <54DDFE72.1050306@redhat.com> <54DE8017.6080608@oracle.com> <54DF022A.9080707@redhat.com> <54DFC7F3.9050309@oracle.com> <54E1CE3B.1020707@oracle.com> Message-ID: <54E1CEEE.8070508@redhat.com> On 02/16/2015 11:02 AM, Alan Bateman wrote: > On 14/02/2015 22:10, Dean Long wrote: >> >> Even if linux-aarch64 always allows unaligned, checking only for >> "aarch64" is not future-proof >> because it doesn't take the OS into account. However, I really don't >> like having to enumerate >> all relevant platforms in multiple places in shared code, so I >> disagree with the existing code >> and with perpetuating the pattern. As long as the decision is in >> platform-specific code, a build-time >> decision may be entirely appropriate. > > This alignment test in Bits.java has been there for a long time (JDK > 1.4). It's technical debt that hasn't surfaces very often as it's so > rare to add architectures. If Unsafe gets a method to test the alignment > then it would be great to get Bits changed. Hopefully it's getting less rare to add architectures! I'll do that as part of my patch. Andrew. From gnu.andrew at redhat.com Mon Feb 16 16:48:06 2015 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 16 Feb 2015 11:48:06 -0500 (EST) Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: References: <531E8309.2060206@oracle.com> <531ED06F.5040905@oracle.com> <107001365.11810418.1423839439509.JavaMail.zimbra@redhat.com> Message-ID: <1896494872.12829739.1424105286571.JavaMail.zimbra@redhat.com> snip... > > > > We're now seeing problems with Java tools on ppc64le as a result of this > > decision not to give it a distinct arch name. > > > > The os.arch property on both ppc64be and ppc64le builds of OpenJDK is being > > reported as the same; "ppc64". This leaves Java applications no way of > > determining which of the two platforms the JDK is running on and, for > > example, > > means that Maven can't determine which native JNI binaries to download. > > > > There is a sun.cpu.endian property but this is non-standard and it seems > > wrong to me that every Java tool should have to add a special case for > > ppc64le using such a property. This value is traditionally not so much > > just the architecture as a composite of the architecture, the bit size > > and the endianness. The only difference with other platforms is that they > > only support one default endianness so the value is implied e.g. > > little-endian for amd64, big-endian for sparc. We do distinguish between > > ppc and ppc64 rather than expecting tools to check sun.arch.data.model, > > so we should do the same with endianness. > > > > To add to the confusion, other JDKs are reporting it as ppc64le > > (thanks to Tiago Sturmer Daitx for these results): > > > > IBM Java 2.7 SR1 > > os.arch: ppc64le > > sun.cpu.endian: little > > > > GCJ 4.8.2 (gij (GNU libgcj) version 4.8.2): > > os.arch: ppc64le > > sun.cpu.endian: null > > > > whereas OpenJDK gives: > > > > os.arch: ppc64 > > sun.cpu.endian: little > > > > It also means that ppc64le is alone in not having a unique architecture > > directory in jre/lib. I understand that a ppc64le machine is not going > > to support ppc64be, but likewise amd64 is not going to support arm, > > yet they have unique arch directories. > > > > I've prepared a webrev which fixes the external facing architecture names, > > LIBARCH and os.name, while leaving the HotSpot build architecture, > > BUILDARCH, > > as it is, to avoid the duplication mentioned as a problem in the original > > review. > > > > http://cr.openjdk.java.net/~andrew/rh1191652/webrev.01/ > > > > This is against our IcedTea OpenJDK7-based HotSpot where we've been testing > > but it should still be applicable to the 9 HotSpot repositories. The JDK > > side > > is another issue and I suspect we'll need a completely different patch > > there > > to the one we have for 7. > > > > Our builds of OpenJDK 7 with this fixed now give: > > > > java.library.path = > > /usr/java/packages/lib/ppc64le:/usr/lib64:/lib64:/lib:/usr/lib > > sun.boot.library.path = > > /builddir/build/BUILD/java-1.7.0-openjdk-1.7.0.75-2.5.4.5.ael7b.ppc64le/openjdk/build/linux-ppc64le/j2sdk-image/jre/lib/ppc64le > > os.arch = ppc64le > > > > I've filed a bug for this here: > > > > https://bugs.openjdk.java.net/browse/JDK-8073139 > > > > Thanks, > > -- > > Andrew :) > > > > 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 > > > > PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) > > Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 > > > > Hi Andrew, > > I don't have a problem with your change and it doesn't affect the > ppc64 big endian build. > > I've prepared a patch which applies cleanly to jdk9-hs-rt here: > > http://cr.openjdk.java.net/~simonis/webrevs/2015/8073139/ > Thanks. I see OpenJDK 9 still doesn't have aarch64; that seems to be the only difference. > Let's here some other opinions as well (you'll need a sponsor from > Oracle anyway and it would also be interesting to here from Alexander > if they already rely on os.arch being ppc64) but from my side thumbs > up. Thanks. I thought arch-specific changes were now able to go through without Oracle sponsorship? Anyway, if David is willing to shepherd it through, it's not a problem. > > Regards, > Volker > -- Andrew :) 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 PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From gnu.andrew at redhat.com Mon Feb 16 16:56:52 2015 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 16 Feb 2015 11:56:52 -0500 (EST) Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: References: <531E8309.2060206@oracle.com> <531ED06F.5040905@oracle.com> <107001365.11810418.1423839439509.JavaMail.zimbra@redhat.com> Message-ID: <1697995292.12840126.1424105812323.JavaMail.zimbra@redhat.com> ----- Original Message ----- > OK, sounds good. > > So Andrew, could you please elaborate what other changes this would > require for the other repositories like jdk and top-level (preferably > in the jdk9 context because that's where we've to start with before we > can downport this to 8u-dev). > On 7, it's the usual arch-specific additions; CFLAGS, jvm.cfg and the javax.sound definitions. I imagine it's similar on 8 but I'm working from the opposite direction here. The bug was raised on 7 and I've been testing there. We'll need to fix it on 8 too, but 9 is difficult because I don't have a direct way of building on ppc64le and there are currently no OpenJDK packages for 9. So it may take a little while... > Volker > > > On Fri, Feb 13, 2015 at 6:25 PM, Alexander Smundak > wrote: > > I was always in favor of having ppc64le as a separate architecture. > > I hope this will be backported to JDK8? > > > > On Fri, Feb 13, 2015 at 8:37 AM, Volker Simonis > > wrote: > >> On Fri, Feb 13, 2015 at 3:57 PM, Andrew Hughes > >> wrote: > >>> ----- Original Message ----- > >>>> On 11/03/2014 6:36 PM, Volker Simonis wrote: > >>>> > On Tue, Mar 11, 2014 at 4:29 AM, David Holmes > >>>> > > >>>> > wrote: > >>>> >> I don't see anything that actually controls what is built. Is it the > >>>> >> case > >>>> >> that the new arch value will be reported by uname on the ppc64le > >>>> >> system? > >>>> >> > >>>> >> (I cringe seeing a new top-level arch introduced for this.) > >>>> >> > >>>> > > >>>> > I didn't liked this too much as well in my first review and I think we > >>>> > can get along without a new top-level arch (see > >>>> > http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2014-March/001790.html). > >>>> > > >>>> > But in the end I can live with both approaches (and having two > >>>> > top-level archs probably makes it slightly simpler to support them > >>>> > both in parallel) so I think finally it is up to you which approach we > >>>> > take. > >>>> > >>>> I agree with your initial review. I don't see a LE build as a distinct > >>>> architecture but a variant of ppc64. > >>>> > >>>> Lets see what anyone else has to say. > >>>> > >>>> Thanks, > >>>> David > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > Regards, > >>>> > Volker > >>>> > > >>>> >> Thanks, > >>>> >> David > >>>> >> > >>>> >> > >>>> >> On 7/03/2014 1:37 PM, Alexander Smundak wrote: > >>>> >>> > >>>> >>> This patch contains the changes to the build files to build JDK on > >>>> >>> the > >>>> >>> little endian PowerPC64 running Linux, and the changes to the source > >>>> >>> files to support little endian mode. > >>>> >>> This preceding related change > >>>> >>> https://bugs.openjdk.java.net/browse/JDK-8036767 added support for > >>>> >>> the > >>>> >>> ELFv2 ABi used on the little endian PowerPC64. > >>>> >>> > >>>> >>> Please review and test this change. I need a sponsor. > >>>> >>> > >>>> >>> The patch is at: > >>>> >>> http://cr.openjdk.java.net/~martin/asmundak/8036767/webrev.00/ > >>>> >>> > >>>> >>> Sasha > >>>> >>> > >>>> >> > >>>> > >>> > >>> We're now seeing problems with Java tools on ppc64le as a result of this > >>> decision not to give it a distinct arch name. > >>> > >>> The os.arch property on both ppc64be and ppc64le builds of OpenJDK is > >>> being > >>> reported as the same; "ppc64". This leaves Java applications no way of > >>> determining which of the two platforms the JDK is running on and, for > >>> example, > >>> means that Maven can't determine which native JNI binaries to download. > >>> > >>> There is a sun.cpu.endian property but this is non-standard and it seems > >>> wrong to me that every Java tool should have to add a special case for > >>> ppc64le using such a property. This value is traditionally not so much > >>> just the architecture as a composite of the architecture, the bit size > >>> and the endianness. The only difference with other platforms is that they > >>> only support one default endianness so the value is implied e.g. > >>> little-endian for amd64, big-endian for sparc. We do distinguish between > >>> ppc and ppc64 rather than expecting tools to check sun.arch.data.model, > >>> so we should do the same with endianness. > >>> > >>> To add to the confusion, other JDKs are reporting it as ppc64le > >>> (thanks to Tiago Sturmer Daitx for these results): > >>> > >>> IBM Java 2.7 SR1 > >>> os.arch: ppc64le > >>> sun.cpu.endian: little > >>> > >>> GCJ 4.8.2 (gij (GNU libgcj) version 4.8.2): > >>> os.arch: ppc64le > >>> sun.cpu.endian: null > >>> > >>> whereas OpenJDK gives: > >>> > >>> os.arch: ppc64 > >>> sun.cpu.endian: little > >>> > >>> It also means that ppc64le is alone in not having a unique architecture > >>> directory in jre/lib. I understand that a ppc64le machine is not going > >>> to support ppc64be, but likewise amd64 is not going to support arm, > >>> yet they have unique arch directories. > >>> > >>> I've prepared a webrev which fixes the external facing architecture > >>> names, > >>> LIBARCH and os.name, while leaving the HotSpot build architecture, > >>> BUILDARCH, > >>> as it is, to avoid the duplication mentioned as a problem in the original > >>> review. > >>> > >>> http://cr.openjdk.java.net/~andrew/rh1191652/webrev.01/ > >>> > >>> This is against our IcedTea OpenJDK7-based HotSpot where we've been > >>> testing > >>> but it should still be applicable to the 9 HotSpot repositories. The JDK > >>> side > >>> is another issue and I suspect we'll need a completely different patch > >>> there > >>> to the one we have for 7. > >>> > >>> Our builds of OpenJDK 7 with this fixed now give: > >>> > >>> java.library.path = > >>> /usr/java/packages/lib/ppc64le:/usr/lib64:/lib64:/lib:/usr/lib > >>> sun.boot.library.path = > >>> /builddir/build/BUILD/java-1.7.0-openjdk-1.7.0.75-2.5.4.5.ael7b.ppc64le/openjdk/build/linux-ppc64le/j2sdk-image/jre/lib/ppc64le > >>> os.arch = ppc64le > >>> > >>> I've filed a bug for this here: > >>> > >>> https://bugs.openjdk.java.net/browse/JDK-8073139 > >>> > >>> Thanks, > >>> -- > >>> Andrew :) > >>> > >>> 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 > >>> > >>> PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) > >>> Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 > >>> > >> > >> Hi Andrew, > >> > >> I don't have a problem with your change and it doesn't affect the > >> ppc64 big endian build. > >> > >> I've prepared a patch which applies cleanly to jdk9-hs-rt here: > >> > >> http://cr.openjdk.java.net/~simonis/webrevs/2015/8073139/ > >> > >> Let's here some other opinions as well (you'll need a sponsor from > >> Oracle anyway and it would also be interesting to here from Alexander > >> if they already rely on os.arch being ppc64) but from my side thumbs > >> up. > >> > >> Regards, > >> Volker > -- Andrew :) 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 PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From volker.simonis at gmail.com Mon Feb 16 17:24:49 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 16 Feb 2015 18:24:49 +0100 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <1896494872.12829739.1424105286571.JavaMail.zimbra@redhat.com> References: <531E8309.2060206@oracle.com> <531ED06F.5040905@oracle.com> <107001365.11810418.1423839439509.JavaMail.zimbra@redhat.com> <1896494872.12829739.1424105286571.JavaMail.zimbra@redhat.com> Message-ID: On Mon, Feb 16, 2015 at 5:48 PM, Andrew Hughes wrote: > snip... > >> > >> > We're now seeing problems with Java tools on ppc64le as a result of this >> > decision not to give it a distinct arch name. >> > >> > The os.arch property on both ppc64be and ppc64le builds of OpenJDK is being >> > reported as the same; "ppc64". This leaves Java applications no way of >> > determining which of the two platforms the JDK is running on and, for >> > example, >> > means that Maven can't determine which native JNI binaries to download. >> > >> > There is a sun.cpu.endian property but this is non-standard and it seems >> > wrong to me that every Java tool should have to add a special case for >> > ppc64le using such a property. This value is traditionally not so much >> > just the architecture as a composite of the architecture, the bit size >> > and the endianness. The only difference with other platforms is that they >> > only support one default endianness so the value is implied e.g. >> > little-endian for amd64, big-endian for sparc. We do distinguish between >> > ppc and ppc64 rather than expecting tools to check sun.arch.data.model, >> > so we should do the same with endianness. >> > >> > To add to the confusion, other JDKs are reporting it as ppc64le >> > (thanks to Tiago Sturmer Daitx for these results): >> > >> > IBM Java 2.7 SR1 >> > os.arch: ppc64le >> > sun.cpu.endian: little >> > >> > GCJ 4.8.2 (gij (GNU libgcj) version 4.8.2): >> > os.arch: ppc64le >> > sun.cpu.endian: null >> > >> > whereas OpenJDK gives: >> > >> > os.arch: ppc64 >> > sun.cpu.endian: little >> > >> > It also means that ppc64le is alone in not having a unique architecture >> > directory in jre/lib. I understand that a ppc64le machine is not going >> > to support ppc64be, but likewise amd64 is not going to support arm, >> > yet they have unique arch directories. >> > >> > I've prepared a webrev which fixes the external facing architecture names, >> > LIBARCH and os.name, while leaving the HotSpot build architecture, >> > BUILDARCH, >> > as it is, to avoid the duplication mentioned as a problem in the original >> > review. >> > >> > http://cr.openjdk.java.net/~andrew/rh1191652/webrev.01/ >> > >> > This is against our IcedTea OpenJDK7-based HotSpot where we've been testing >> > but it should still be applicable to the 9 HotSpot repositories. The JDK >> > side >> > is another issue and I suspect we'll need a completely different patch >> > there >> > to the one we have for 7. >> > >> > Our builds of OpenJDK 7 with this fixed now give: >> > >> > java.library.path = >> > /usr/java/packages/lib/ppc64le:/usr/lib64:/lib64:/lib:/usr/lib >> > sun.boot.library.path = >> > /builddir/build/BUILD/java-1.7.0-openjdk-1.7.0.75-2.5.4.5.ael7b.ppc64le/openjdk/build/linux-ppc64le/j2sdk-image/jre/lib/ppc64le >> > os.arch = ppc64le >> > >> > I've filed a bug for this here: >> > >> > https://bugs.openjdk.java.net/browse/JDK-8073139 >> > >> > Thanks, >> > -- >> > Andrew :) >> > >> > 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 >> > >> > PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) >> > Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 >> > >> >> Hi Andrew, >> >> I don't have a problem with your change and it doesn't affect the >> ppc64 big endian build. >> >> I've prepared a patch which applies cleanly to jdk9-hs-rt here: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2015/8073139/ >> > > Thanks. I see OpenJDK 9 still doesn't have aarch64; that seems to be > the only difference. > >> Let's here some other opinions as well (you'll need a sponsor from >> Oracle anyway and it would also be interesting to here from Alexander >> if they already rely on os.arch being ppc64) but from my side thumbs >> up. > > Thanks. I thought arch-specific changes were now able to go through > without Oracle sponsorship? Anyway, if David is willing to shepherd > it through, it's not a problem. > It's not arch-specific changes which external committers can push on their own it's just changes which only touch arch-specific files of non-Oracle architectures :) >> >> Regards, >> Volker >> > > -- > Andrew :) > > 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 > > PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) > Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 > From volker.simonis at gmail.com Mon Feb 16 17:59:11 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 16 Feb 2015 18:59:11 +0100 Subject: RFE: JDK-8073249: Fix all files to contain exactly one newline at the end of file (and enhance 'jcheck' to enforce this policy) Message-ID: Hi, I've just filed "JDK-8073249: Fix all files to contain exactly one newline at the end of file (and enhance 'jcheck' to enforce this policy)" and "CODETOOLS-7901298 jcheck should check that every file ends with exactly one newline". Is there a mutual consent that this is something worth doing? I.e. should I start to prepare a webrev which fixes all hotspot files which contain more than one newline at the end of the file and send it out for review? I'd need a sponsor anyway :) What's your opinion? Regards, Volker PS: from my understanding of how jcheck is working we'll have to clean up the files in the other repositories as well, before we can enable the new jcheck filter, so this is just a starter. From anthony.scarpino at oracle.com Mon Feb 16 21:11:31 2015 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Mon, 16 Feb 2015 13:11:31 -0800 Subject: RFR: 8073108: GHASH Intrinsics Message-ID: <54E25D03.7090705@oracle.com> Hi, I'm requesting a code review to intrinsify the GHASH operations for both x86 and SPARC platforms. This greatly increases performance over software for AES/GCM crypto operations, details are in the bug. The review is for two repos, hotspot and jdk: http://cr.openjdk.java.net/~ascarpino/8073108/hotspot/webrev/ http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev/ thanks Tony From david.holmes at oracle.com Tue Feb 17 01:23:57 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 17 Feb 2015 11:23:57 +1000 Subject: RFR: 8073108: GHASH Intrinsics In-Reply-To: <54E25D03.7090705@oracle.com> References: <54E25D03.7090705@oracle.com> Message-ID: <54E2982D.9020902@oracle.com> Hi Tony, Not a review as hotspot compiler folk need to review this. On 17/02/2015 7:11 AM, Anthony Scarpino wrote: > Hi, > > I'm requesting a code review to intrinsify the GHASH operations for both > x86 and SPARC platforms. This greatly increases performance over > software for AES/GCM crypto operations, details are in the bug. This may be normal for intrinsics but there seems to be a large amount of shared code being updated to support these platform specific enhancements. What happens on other platforms if the user sets UseGHASHIntrinsics? Shouldn't there be a guard against this in arguments.cpp? Thanks, David > The review is for two repos, hotspot and jdk: > > http://cr.openjdk.java.net/~ascarpino/8073108/hotspot/webrev/ > > http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev/ > > thanks > > Tony From vladimir.kozlov at oracle.com Tue Feb 17 02:01:46 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 16 Feb 2015 18:01:46 -0800 Subject: RFR: 8073108: GHASH Intrinsics In-Reply-To: <54E2982D.9020902@oracle.com> References: <54E25D03.7090705@oracle.com> <54E2982D.9020902@oracle.com> Message-ID: <54E2A10A.6090007@oracle.com> On 2/16/15 5:23 PM, David Holmes wrote: > Hi Tony, > > Not a review as hotspot compiler folk need to review this. > > On 17/02/2015 7:11 AM, Anthony Scarpino wrote: >> Hi, >> >> I'm requesting a code review to intrinsify the GHASH operations for both >> x86 and SPARC platforms. This greatly increases performance over >> software for AES/GCM crypto operations, details are in the bug. > > This may be normal for intrinsics but there seems to be a large amount > of shared code being updated to support these platform specific > enhancements. What happens on other platforms if the user sets > UseGHASHIntrinsics? Shouldn't there be a guard against this in > arguments.cpp? Code in vm_version_.cpp does the check. vm_version_sparc.cpp and vm_version_x86.cpp do that. Tony, please, fix other vm_version_.cpp files (including closed) to set corresponding flag to false. See UseAES as example. Also code in vm_version_sparc.cpp should be similar to one in vm_version_x86.cpp. Something like: // GHASH/GCM intrinsics if (has_vis3() && (UseVIS > 2)) { if (FLAG_IS_DEFAULT(UseGHASHIntrinsics)) { UseGHASHIntrinsics = true; } } else if (UseGHASHIntrinsics) { if (!FLAG_IS_DEFAULT(UseGHASHIntrinsics)) warning("GHASH intrinsics require VIS3 insructions support. Intriniscs will be disabled"); FLAG_SET_DEFAULT(UseGHASHIntrinsics, false); } There is #ifdef _WIN64 in stubGenerator_x86_32.cpp. It is not needed since it is 32-bit code. I see you switched off -DcheckOutput=false for GCM testing and return from compareArrays() after length compare. Is it because it can't be done or you did not have time to add needed code? Otherwise Hotspot code looks good. Thanks, Vladimir > > Thanks, > David > >> The review is for two repos, hotspot and jdk: >> >> http://cr.openjdk.java.net/~ascarpino/8073108/hotspot/webrev/ >> >> http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev/ >> >> thanks >> >> Tony From john.r.rose at oracle.com Tue Feb 17 02:47:14 2015 From: john.r.rose at oracle.com (John Rose) Date: Mon, 16 Feb 2015 18:47:14 -0800 Subject: RFR: 8073108: GHASH Intrinsics In-Reply-To: <54E25D03.7090705@oracle.com> References: <54E25D03.7090705@oracle.com> Message-ID: <31E530B4-B880-4630-A830-663145817AC1@oracle.com> Cool stuff. I'm glad to see SPARC xmulx getting some play. This is not a review, but I have a small and a big comment. You don't need the argument vmIntrinsics::ID id unless you are going to do something with it, such as expand one of a family of intrinsics covered by the same LCK::inline* routine. You probably don't have enough parameter verification on the inputs to processBlocks. A robust range check for a subsequence indexing operation requires three comparison operations, not just one. The Java code uses getLong which includes additional range checks, but your intrinsic replacement code might not do that correctly; in any case, it's better to have all the subsequence range checks in one place, and in Java code. (Oh, and watch out for 32-bit integer overflow: That causes surprises sometimes, when a value that is too large wraps to negative, and then can seem to be in range relative to a <= check.) In fact, I don't believe the existing parameter verification is very helpful at all: if (inLen - inOfs > in.length) throw... This appears to allow a ridiculously large inLen as long as inOfs is also ridiculously large. All of the "heavy lifting" is done by intrinisic array range checks triggered by getLong, and those are the checks that the assembly code does *not* do. ? John P.S. We should have a library API to do these parameter checks. See: https://bugs.openjdk.java.net/browse/JDK-8042997#comment-13610181 On Feb 16, 2015, at 1:11 PM, Anthony Scarpino wrote: > > Hi, > > I'm requesting a code review to intrinsify the GHASH operations for both x86 and SPARC platforms. This greatly increases performance over software for AES/GCM crypto operations, details are in the bug. > > The review is for two repos, hotspot and jdk: > > http://cr.openjdk.java.net/~ascarpino/8073108/hotspot/webrev/ > > http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev/ > > thanks > > Tony From john.r.rose at oracle.com Tue Feb 17 03:35:46 2015 From: john.r.rose at oracle.com (John Rose) Date: Mon, 16 Feb 2015 19:35:46 -0800 Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses In-Reply-To: <54DF00C4.7030308@redhat.com> References: <20150213230416.5E7B617FDAA@rebar.astron.com> <54DE8BB7.5050801@oracle.com> <54DE9140.3040604@oracle.com> <54DF00C4.7030308@redhat.com> Message-ID: On Feb 14, 2015, at 12:01 AM, Andrew Haley wrote: > > On 02/14/2015 12:09 AM, John Rose wrote: >> We also need Unsafe.getIntMisaligned, etc., which wire through to whatever second-best mechanism the platform offers. > > Indeed. I'm intending to prototype a design for those next week. OK? Yes, please. ? John From fweimer at redhat.com Tue Feb 17 08:57:46 2015 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 17 Feb 2015 09:57:46 +0100 Subject: RFR: 8073108: GHASH Intrinsics In-Reply-To: <54E25D03.7090705@oracle.com> References: <54E25D03.7090705@oracle.com> Message-ID: <54E3028A.7040102@redhat.com> On 02/16/2015 10:11 PM, Anthony Scarpino wrote: > http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev/ I think the ?state? field in GHASH should be final. Is C2 able to eliminate the array bounds checks? (Although it's not in the inner loop and thus probably not relevant for performance.) The comment on processBlock(byte[], int, int) is confusing. I don't understand what it is trying to say. -- Florian Weimer / Red Hat Product Security From fweimer at redhat.com Tue Feb 17 09:39:04 2015 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 17 Feb 2015 10:39:04 +0100 Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses In-Reply-To: References: <20150213230416.5E7B617FDAA@rebar.astron.com> <54DE8BB7.5050801@oracle.com> <54DE9140.3040604@oracle.com> Message-ID: <54E30C38.8000303@redhat.com> On 02/14/2015 01:09 AM, John Rose wrote: > These queries need to go into Unsafe. > We also need Unsafe.getIntMisaligned, etc., which wire through to whatever second-best mechanism the platform offers. The safe variants should go into the java.lang.Integer etc. classes IMHO. Even the JDK has quite a few uses for them (particularly the big endian variant). Putting that into Unsafe only encourages further use of Unsafe from application code. -- Florian Weimer / Red Hat Product Security From fweimer at redhat.com Tue Feb 17 09:41:34 2015 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 17 Feb 2015 10:41:34 +0100 Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses In-Reply-To: <54DFC7F3.9050309@oracle.com> References: <54DDFE72.1050306@redhat.com> <54DE8017.6080608@oracle.com> <54DF022A.9080707@redhat.com> <54DFC7F3.9050309@oracle.com> Message-ID: <54E30CCE.8030608@redhat.com> On 02/14/2015 11:10 PM, Dean Long wrote: > Even if linux-aarch64 always allows unaligned, checking only for > "aarch64" is not future-proof > because it doesn't take the OS into account. Surely a simple test case is sufficient to ensure that the platform supports misaligned accesses? Then new ports will see the failure immediately and can tweak the code. -- Florian Weimer / Red Hat Product Security From aph at redhat.com Tue Feb 17 10:00:36 2015 From: aph at redhat.com (Andrew Haley) Date: Tue, 17 Feb 2015 10:00:36 +0000 Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses In-Reply-To: <54E30C38.8000303@redhat.com> References: <20150213230416.5E7B617FDAA@rebar.astron.com> <54DE8BB7.5050801@oracle.com> <54DE9140.3040604@oracle.com> <54E30C38.8000303@redhat.com> Message-ID: <54E31144.3040504@redhat.com> On 02/17/2015 09:39 AM, Florian Weimer wrote: > On 02/14/2015 01:09 AM, John Rose wrote: >> These queries need to go into Unsafe. >> We also need Unsafe.getIntMisaligned, etc., which wire through to whatever second-best mechanism the platform offers. > > The safe variants should go into the java.lang.Integer etc. classes > IMHO. Even the JDK has quite a few uses for them (particularly the > big endian variant). Putting that into Unsafe only encourages > further use of Unsafe from application code. They'll all be visible as ByteBuffer methods, which should be enough for application code, shouldn't it? I'm not sure how much sense it makes to put them into java.lang.Integer etc. Andrew. From fweimer at redhat.com Tue Feb 17 10:15:27 2015 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 17 Feb 2015 11:15:27 +0100 Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses In-Reply-To: <54E31144.3040504@redhat.com> References: <20150213230416.5E7B617FDAA@rebar.astron.com> <54DE8BB7.5050801@oracle.com> <54DE9140.3040604@oracle.com> <54E30C38.8000303@redhat.com> <54E31144.3040504@redhat.com> Message-ID: <54E314BF.3010205@redhat.com> On 02/17/2015 11:00 AM, Andrew Haley wrote: > On 02/17/2015 09:39 AM, Florian Weimer wrote: >> On 02/14/2015 01:09 AM, John Rose wrote: >>> These queries need to go into Unsafe. >>> We also need Unsafe.getIntMisaligned, etc., which wire through to whatever second-best mechanism the platform offers. >> >> The safe variants should go into the java.lang.Integer etc. classes >> IMHO. Even the JDK has quite a few uses for them (particularly the >> big endian variant). Putting that into Unsafe only encourages >> further use of Unsafe from application code. > > They'll all be visible as ByteBuffer methods, which should be enough > for application code, shouldn't it? I'm not sure how much sense it > makes to put them into java.lang.Integer etc. You'll still have to allocate a wrapping ByteBuffer object to use them. I expect that makes them unattractive in many cases. Hmm, maybe I should propose a patch for DataInputStream and see how it's received. :-) -- Florian Weimer / Red Hat Product Security From aph at redhat.com Tue Feb 17 10:22:47 2015 From: aph at redhat.com (Andrew Haley) Date: Tue, 17 Feb 2015 10:22:47 +0000 Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses In-Reply-To: <54E314BF.3010205@redhat.com> References: <20150213230416.5E7B617FDAA@rebar.astron.com> <54DE8BB7.5050801@oracle.com> <54DE9140.3040604@oracle.com> <54E30C38.8000303@redhat.com> <54E31144.3040504@redhat.com> <54E314BF.3010205@redhat.com> Message-ID: <54E31677.1050209@redhat.com> On 02/17/2015 10:15 AM, Florian Weimer wrote: > On 02/17/2015 11:00 AM, Andrew Haley wrote: >> On 02/17/2015 09:39 AM, Florian Weimer wrote: >>> On 02/14/2015 01:09 AM, John Rose wrote: >>>> These queries need to go into Unsafe. >>>> We also need Unsafe.getIntMisaligned, etc., which wire through to whatever second-best mechanism the platform offers. >>> >>> The safe variants should go into the java.lang.Integer etc. classes >>> IMHO. Even the JDK has quite a few uses for them (particularly the >>> big endian variant). Putting that into Unsafe only encourages >>> further use of Unsafe from application code. >> >> They'll all be visible as ByteBuffer methods, which should be enough >> for application code, shouldn't it? I'm not sure how much sense it >> makes to put them into java.lang.Integer etc. > > You'll still have to allocate a wrapping ByteBuffer object to use them. > I expect that makes them unattractive in many cases. Hmm. I'm having a hard time trying to understand why. If you need to do a lot of accesses the allocation of the ByteBuffer won't be significant; if you don't need to do a lot of accesses it won't matter either. Andrew. From fweimer at redhat.com Tue Feb 17 10:49:10 2015 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 17 Feb 2015 11:49:10 +0100 Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses In-Reply-To: <54E31677.1050209@redhat.com> References: <20150213230416.5E7B617FDAA@rebar.astron.com> <54DE8BB7.5050801@oracle.com> <54DE9140.3040604@oracle.com> <54E30C38.8000303@redhat.com> <54E31144.3040504@redhat.com> <54E314BF.3010205@redhat.com> <54E31677.1050209@redhat.com> Message-ID: <54E31CA6.6030609@redhat.com> On 02/17/2015 11:22 AM, Andrew Haley wrote: >> You'll still have to allocate a wrapping ByteBuffer object to use them. >> I expect that makes them unattractive in many cases. > > Hmm. I'm having a hard time trying to understand why. If you need to > do a lot of accesses the allocation of the ByteBuffer won't be > significant; if you don't need to do a lot of accesses it won't > matter either. The typical use case I have in mind is exemplified by com.sun.crypto.provider.GHASH(processBlock(byte[] data, int ofs): 174 private void processBlock(byte[] data, int ofs) { 175 if (data.length - ofs < AES_BLOCK_SIZE) { 176 throw new RuntimeException("need complete block"); 177 } 178 state0 ^= getLong(data, ofs); 179 state1 ^= getLong(data, ofs + 8); 180 blockMult(subkeyH0, subkeyH1); 181 } That is, the byte array is supplied by the caller, and if we wanted to use a ByteBuffer, we would have to allocate a fresh one on every iteration. In this case, neither of the two alternatives you list apply. -- Florian Weimer / Red Hat Product Security From aph at redhat.com Tue Feb 17 10:53:20 2015 From: aph at redhat.com (Andrew Haley) Date: Tue, 17 Feb 2015 10:53:20 +0000 Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses In-Reply-To: <54E31CA6.6030609@redhat.com> References: <20150213230416.5E7B617FDAA@rebar.astron.com> <54DE8BB7.5050801@oracle.com> <54DE9140.3040604@oracle.com> <54E30C38.8000303@redhat.com> <54E31144.3040504@redhat.com> <54E314BF.3010205@redhat.com> <54E31677.1050209@redhat.com> <54E31CA6.6030609@redhat.com> Message-ID: <54E31DA0.2040901@redhat.com> On 02/17/2015 10:49 AM, Florian Weimer wrote: > On 02/17/2015 11:22 AM, Andrew Haley wrote: >>> You'll still have to allocate a wrapping ByteBuffer object to use them. >>> I expect that makes them unattractive in many cases. >> >> Hmm. I'm having a hard time trying to understand why. If you need to >> do a lot of accesses the allocation of the ByteBuffer won't be >> significant; if you don't need to do a lot of accesses it won't >> matter either. > > The typical use case I have in mind is exemplified by > com.sun.crypto.provider.GHASH(processBlock(byte[] data, int ofs): > > 174 private void processBlock(byte[] data, int ofs) { > 175 if (data.length - ofs < AES_BLOCK_SIZE) { > 176 throw new RuntimeException("need complete block"); > 177 } > 178 state0 ^= getLong(data, ofs); > 179 state1 ^= getLong(data, ofs + 8); > 180 blockMult(subkeyH0, subkeyH1); > 181 } > > That is, the byte array is supplied by the caller, and if we wanted to > use a ByteBuffer, we would have to allocate a fresh one on every > iteration. In this case, neither of the two alternatives you list apply. I see. So the question could also be whether escape analysis would notice that a ByteBuffer does not escape. I hope to know that soon. Andrew. From fweimer at redhat.com Tue Feb 17 10:59:17 2015 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 17 Feb 2015 11:59:17 +0100 Subject: RFR: 8073108: GHASH Intrinsics In-Reply-To: <54E25D03.7090705@oracle.com> References: <54E25D03.7090705@oracle.com> Message-ID: <54E31F05.2020805@redhat.com> On 02/16/2015 10:11 PM, Anthony Scarpino wrote: > Hi, > > I'm requesting a code review to intrinsify the GHASH operations for both > x86 and SPARC platforms. This greatly increases performance over > software for AES/GCM crypto operations, details are in the bug. > > The review is for two repos, hotspot and jdk: > > http://cr.openjdk.java.net/~ascarpino/8073108/hotspot/webrev/ Sorry for double-posting. I looked at generate_ghash_processBlocks() and wonder if the loop needs to be split to introduce occasional safepoints. The TLS record size should limit the number bytes per invocation to 16000, so perhaps this isn't issue for the current application. -- Florian Weimer / Red Hat Product Security From goetz.lindenmaier at sap.com Tue Feb 17 11:42:48 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 17 Feb 2015 11:42:48 +0000 Subject: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. Message-ID: <4295855A5C1DE049A61835A1887419CC2CF9615F@DEWDFEMB12A.global.corp.sap> Hi, We fixed all the warnings showing with -Wtype-limits and gcc in our VM. I would like to contribute these small changes. This warning detects unnecessary compares for >= 0 of unsigned values. At least one warning unveils a real bug. In memory/blockOffsetTable.cpp, BlockOffsetArrayContigSpace::last_active_index(), the compare to >=0 tries to prevent an underflow, but the value is unsigned. Further useless compares in real code are in os_linux.cpp, opto/graphKit.cpp, prims/jvmtiRedefineClasses.cpp In some places debug code with constant debug flags caused warnings in the opt build (g1/concurrentMark.cpp, classfile/systemDictionary.cpp) The remaining warnings occur in asserts, which is also the biggest part. The change also removes an empty #ifdef ASSERT . Please review this change. I please need a sponsor. https://bugs.openjdk.java.net/browse/JDK-8073315 http://cr.openjdk.java.net/~goetz/webrevs/8073315-wUnsign/webrev.01/ I tested this on linuxx86_64 with gcc 4.1.2, 4.3 and 4.8. Further I ran the patch with our nightly builds and tests of jdk9,see http://cr.openjdk.java.net/~simonis/ppc-aix-port/index.html Best regards, Goetz. From vitalyd at gmail.com Tue Feb 17 13:52:51 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 17 Feb 2015 08:52:51 -0500 Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses In-Reply-To: <54E31DA0.2040901@redhat.com> References: <20150213230416.5E7B617FDAA@rebar.astron.com> <54DE8BB7.5050801@oracle.com> <54DE9140.3040604@oracle.com> <54E30C38.8000303@redhat.com> <54E31144.3040504@redhat.com> <54E314BF.3010205@redhat.com> <54E31677.1050209@redhat.com> <54E31CA6.6030609@redhat.com> <54E31DA0.2040901@redhat.com> Message-ID: FWIW, when I checked, ByteBuffer.wrap(...).getXXX() type of code didn't EA out the BB; it seems the call chain is too complex for EA. I checked 7u60 though, so maybe newer versions are different. sent from my phone On Feb 17, 2015 5:53 AM, "Andrew Haley" wrote: > On 02/17/2015 10:49 AM, Florian Weimer wrote: > > On 02/17/2015 11:22 AM, Andrew Haley wrote: > >>> You'll still have to allocate a wrapping ByteBuffer object to use them. > >>> I expect that makes them unattractive in many cases. > >> > >> Hmm. I'm having a hard time trying to understand why. If you need to > >> do a lot of accesses the allocation of the ByteBuffer won't be > >> significant; if you don't need to do a lot of accesses it won't > >> matter either. > > > > The typical use case I have in mind is exemplified by > > com.sun.crypto.provider.GHASH(processBlock(byte[] data, int ofs): > > > > 174 private void processBlock(byte[] data, int ofs) { > > 175 if (data.length - ofs < AES_BLOCK_SIZE) { > > 176 throw new RuntimeException("need complete block"); > > 177 } > > 178 state0 ^= getLong(data, ofs); > > 179 state1 ^= getLong(data, ofs + 8); > > 180 blockMult(subkeyH0, subkeyH1); > > 181 } > > > > That is, the byte array is supplied by the caller, and if we wanted to > > use a ByteBuffer, we would have to allocate a fresh one on every > > iteration. In this case, neither of the two alternatives you list apply. > > I see. So the question could also be whether escape analysis would > notice that a ByteBuffer does not escape. I hope to know that soon. > > Andrew. > > > From aph at redhat.com Tue Feb 17 14:22:39 2015 From: aph at redhat.com (Andrew Haley) Date: Tue, 17 Feb 2015 14:22:39 +0000 Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses In-Reply-To: <54E31DA0.2040901@redhat.com> References: <20150213230416.5E7B617FDAA@rebar.astron.com> <54DE8BB7.5050801@oracle.com> <54DE9140.3040604@oracle.com> <54E30C38.8000303@redhat.com> <54E31144.3040504@redhat.com> <54E314BF.3010205@redhat.com> <54E31677.1050209@redhat.com> <54E31CA6.6030609@redhat.com> <54E31DA0.2040901@redhat.com> Message-ID: <54E34EAF.6000802@redhat.com> On 02/17/2015 10:53 AM, Andrew Haley wrote: > I see. So the question could also be whether escape analysis would > notice that a ByteBuffer does not escape. I hope to know that soon. Close but no cigar. long getLong(byte[] bytes, int i) { return ByteBuffer.wrap(bytes).getLong(i); } Everything gets inlined nicely and the ByteBuffer is not created, but a store fence remains because of the final fields in HeapByteBuffer. So the resulting code for getLong (minus the prologue and epilogue) looks like this: 0x000003ff7426dc34: ldr w11, [x2,#12] ;*arraylength ; - java.nio.ByteBuffer::wrap at 3 (line 396) ; - bytebuffertests.ByteBufferTests3::getLong at 1 (line 23) ; implicit exception: dispatches to 0x000003ff7426dca4 ;; B2: # B5 B3 <- B1 Freq: 0.999999 0x000003ff7426dc38: dmb ish ;*synchronization entry ; - java.nio.HeapByteBuffer::@-1 (line 84) ; - java.nio.ByteBuffer::wrap at 7 (line 373) ; - java.nio.ByteBuffer::wrap at 4 (line 396) ; - bytebuffertests.ByteBufferTests3::getLong at 1 (line 23) 0x000003ff7426dc3c: sub w12, w11, w3 ;*isub ; - java.nio.Buffer::checkIndex at 10 (line 545) ; - java.nio.HeapByteBuffer::getLong at 18 (line 465) ; - bytebuffertests.ByteBufferTests3::getLong at 5 (line 23) 0x000003ff7426dc40: cmp w3, #0x0 0x000003ff7426dc44: b.lt 0x000003ff7426dc70 ;*iflt ; - java.nio.Buffer::checkIndex at 1 (line 545) ; - java.nio.HeapByteBuffer::getLong at 18 (line 465) ; - bytebuffertests.ByteBufferTests3::getLong at 5 (line 23) ;; B3: # B6 B4 <- B2 Freq: 0.999999 0x000003ff7426dc48: cmp w12, #0x8 0x000003ff7426dc4c: b.lt 0x000003ff7426dc88 ;*if_icmple ; - java.nio.Buffer::checkIndex at 11 (line 545) ; - java.nio.HeapByteBuffer::getLong at 18 (line 465) ; - bytebuffertests.ByteBufferTests3::getLong at 5 (line 23) ;; B4: # N92 <- B3 Freq: 0.999998 0x000003ff7426dc50: add x10, x2, w3, sxtw 0x000003ff7426dc54: ldr x10, [x10,#16] 0x000003ff7426dc58: rev x0, x10 ;*invokestatic reverseBytes ; - java.nio.Bits::swap at 1 (line 61) ; - java.nio.HeapByteBuffer::getLong at 41 (line 466) ; - bytebuffertests.ByteBufferTests3::getLong at 5 (line 23) If it weren't for the stray DMB ISH it'd be almost perfect. Andrew. From stefan.johansson at oracle.com Tue Feb 17 14:50:29 2015 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Tue, 17 Feb 2015 15:50:29 +0100 Subject: Request for approval [8u60]: 8062672: JVM crashes during GC on various asserts which checks that HeapWord ptr is an oop In-Reply-To: <54DC9799.80509@oracle.com> References: <54DC9799.80509@oracle.com> Message-ID: <54E35535.8070705@oracle.com> Hi again, Since no one objected and there is no real need for a re-review because the patch applied clean I have pushed it to 8u. Stay tuned for the updated patch for 9. Cheers, Stefan On 2015-02-12 13:07, Stefan Johansson wrote: > Hi all, > > The linux-sparc specific issue described in [1] was fixed directly in > 7u80 to ensure it got in in time. The fix has not yet been forward > ported to 8u, but now it is time. The fix for 7u80 applies clean and > for more information please refer to the old review thread [2]. After > this fix is in 8u, I plan to move it into 9. There is a small conflict > for 9 so I will send out a proper review for that patch. > > I've created a new webrev for 8u, it's available here: > http://cr.openjdk.java.net/~sjohanss/8062672/8u/hotspot.00/ > > Thanks, > Stefan > > [1] https://bugs.openjdk.java.net/browse/JDK-8062672 > [2] > http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-December/016324.html > From denis.kononenko at oracle.com Tue Feb 17 15:58:09 2015 From: denis.kononenko at oracle.com (denis kononenko) Date: Tue, 17 Feb 2015 18:58:09 +0300 Subject: RFR (S): 8072687: Update OutputAnalyzer to work with files Message-ID: <54E36511.7010608@oracle.com> Hi All, Could you please review a small change of OutputAnalyzer class from testlibrary. Webrev link: http://cr.openjdk.java.net/~dfazunen/dkononen/8072687/webrev.00/ Bug id: https://bugs.openjdk.java.net/browse/JDK-8072687 Testing: automated Description: The purpose of this change is to extend the functionality of OutputAnalyzer by adding ability to read output from a file. Sometimes we have to analyze output written to a file (test data, logs, etc.). In that case we have to read it as a string and pass it into OutputAnalyzer's constructor (it could be done in several different ways). It would be very convenient to put this code directly into OutputAnalyzer. This would allow to make further tests code more cleaner and less error prone. The change consist of two parts: 1) The change: OutputAnalyzer.java, added a new constructor that accepts File; 2) The tests: FileOutputAnalyzerTests.java, very basic tests on reading functionality. Thank you, Denis. From staffan.larsen at oracle.com Tue Feb 17 17:39:23 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 17 Feb 2015 18:39:23 +0100 Subject: RFR (S): 8072687: Update OutputAnalyzer to work with files In-Reply-To: <54E36511.7010608@oracle.com> References: <54E36511.7010608@oracle.com> Message-ID: <65BF10CE-582D-448E-B5DA-5544276C0E16@oracle.com> There is constructor that takes a String argument. That constructor sets both stderr and stdout to that same String. Your constructor behaves differently and only sets stdout to the contents of the file. I have no idea why the existing constructor does what it does, but it would be good if the new and old had the same behavior. I haven?t looked at the use cases for the existing constructor. /S > On 17 feb 2015, at 16:58, denis kononenko wrote: > > Hi All, > > Could you please review a small change of OutputAnalyzer class from testlibrary. > > Webrev link: http://cr.openjdk.java.net/~dfazunen/dkononen/8072687/webrev.00/ > Bug id: https://bugs.openjdk.java.net/browse/JDK-8072687 > Testing: automated > Description: > > The purpose of this change is to extend the functionality of OutputAnalyzer by adding ability to read output from a file. Sometimes we have to analyze output written to a file (test data, logs, etc.). In that case we have to read it as a string and pass it into OutputAnalyzer's constructor (it could be done in several different ways). It would be very convenient to put this code directly into OutputAnalyzer. This would allow to make further tests code more cleaner and less error prone. > > The change consist of two parts: > 1) The change: OutputAnalyzer.java, added a new constructor that accepts File; > 2) The tests: FileOutputAnalyzerTests.java, very basic tests on reading functionality. > > Thank you, > Denis. > > From anthony.scarpino at oracle.com Tue Feb 17 18:31:37 2015 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 17 Feb 2015 10:31:37 -0800 Subject: RFR: 8073108: GHASH Intrinsics In-Reply-To: <54E2A10A.6090007@oracle.com> References: <54E25D03.7090705@oracle.com> <54E2982D.9020902@oracle.com> <54E2A10A.6090007@oracle.com> Message-ID: <54E38909.5070800@oracle.com> On 02/16/2015 06:01 PM, Vladimir Kozlov wrote: > On 2/16/15 5:23 PM, David Holmes wrote: >> Hi Tony, >> >> Not a review as hotspot compiler folk need to review this. >> >> On 17/02/2015 7:11 AM, Anthony Scarpino wrote: >>> Hi, >>> >>> I'm requesting a code review to intrinsify the GHASH operations for both >>> x86 and SPARC platforms. This greatly increases performance over >>> software for AES/GCM crypto operations, details are in the bug. >> >> This may be normal for intrinsics but there seems to be a large amount >> of shared code being updated to support these platform specific >> enhancements. What happens on other platforms if the user sets >> UseGHASHIntrinsics? Shouldn't there be a guard against this in >> arguments.cpp? > > Code in vm_version_.cpp does the check. vm_version_sparc.cpp and > vm_version_x86.cpp do that. > > Tony, please, fix other vm_version_.cpp files (including closed) > to set corresponding flag to false. See UseAES as example. Ok.. thanks Dave & Vladimir for bring that up.. I fix that.. > Also code in vm_version_sparc.cpp should be similar to one in > vm_version_x86.cpp. Something like: > > // GHASH/GCM intrinsics > if (has_vis3() && (UseVIS > 2)) { > if (FLAG_IS_DEFAULT(UseGHASHIntrinsics)) { > UseGHASHIntrinsics = true; > } > } else if (UseGHASHIntrinsics) { > if (!FLAG_IS_DEFAULT(UseGHASHIntrinsics)) > warning("GHASH intrinsics require VIS3 insructions support. > Intriniscs will be disabled"); > FLAG_SET_DEFAULT(UseGHASHIntrinsics, false); > } > Sure.. > There is #ifdef _WIN64 in stubGenerator_x86_32.cpp. It is not needed > since it is 32-bit code. Sure.. Do I still need to save the xmm6 and xmm7 on 32bit code, or is all of the register saving only for Windows 64bit? > > I see you switched off -DcheckOutput=false for GCM testing and return > from compareArrays() after length compare. Is it because it can't be > done or you did not have time to add needed code? I'll have to double check, but I believe -DcheckOutput can be turned back on. I suspect I never updated the @run lines after I changed compareArrays() > Otherwise Hotspot code looks good. > > Thanks, > Vladimir > >> >> Thanks, >> David >> >>> The review is for two repos, hotspot and jdk: >>> >>> http://cr.openjdk.java.net/~ascarpino/8073108/hotspot/webrev/ >>> >>> http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev/ >>> >>> thanks >>> >>> Tony From vladimir.kozlov at oracle.com Tue Feb 17 18:41:51 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 17 Feb 2015 10:41:51 -0800 Subject: RFR: 8073108: GHASH Intrinsics In-Reply-To: <54E38909.5070800@oracle.com> References: <54E25D03.7090705@oracle.com> <54E2982D.9020902@oracle.com> <54E2A10A.6090007@oracle.com> <54E38909.5070800@oracle.com> Message-ID: <54E38B6F.9050106@oracle.com> On 2/17/15 10:31 AM, Anthony Scarpino wrote: > On 02/16/2015 06:01 PM, Vladimir Kozlov wrote: >> On 2/16/15 5:23 PM, David Holmes wrote: >>> Hi Tony, >>> >>> Not a review as hotspot compiler folk need to review this. >>> >>> On 17/02/2015 7:11 AM, Anthony Scarpino wrote: >>>> Hi, >>>> >>>> I'm requesting a code review to intrinsify the GHASH operations for >>>> both >>>> x86 and SPARC platforms. This greatly increases performance over >>>> software for AES/GCM crypto operations, details are in the bug. >>> >>> This may be normal for intrinsics but there seems to be a large amount >>> of shared code being updated to support these platform specific >>> enhancements. What happens on other platforms if the user sets >>> UseGHASHIntrinsics? Shouldn't there be a guard against this in >>> arguments.cpp? >> >> Code in vm_version_.cpp does the check. vm_version_sparc.cpp and >> vm_version_x86.cpp do that. >> >> Tony, please, fix other vm_version_.cpp files (including closed) >> to set corresponding flag to false. See UseAES as example. > > Ok.. thanks Dave & Vladimir for bring that up.. I fix that.. > > >> Also code in vm_version_sparc.cpp should be similar to one in >> vm_version_x86.cpp. Something like: >> >> // GHASH/GCM intrinsics >> if (has_vis3() && (UseVIS > 2)) { >> if (FLAG_IS_DEFAULT(UseGHASHIntrinsics)) { >> UseGHASHIntrinsics = true; >> } >> } else if (UseGHASHIntrinsics) { >> if (!FLAG_IS_DEFAULT(UseGHASHIntrinsics)) >> warning("GHASH intrinsics require VIS3 insructions support. >> Intriniscs will be disabled"); >> FLAG_SET_DEFAULT(UseGHASHIntrinsics, false); >> } >> > > Sure.. > >> There is #ifdef _WIN64 in stubGenerator_x86_32.cpp. It is not needed >> since it is 32-bit code. > > Sure.. Do I still need to save the xmm6 and xmm7 on 32bit code, or is > all of the register saving only for Windows 64bit? No, in 32-bit you don't need to save xmm6 and xmm7. > >> >> I see you switched off -DcheckOutput=false for GCM testing and return >> from compareArrays() after length compare. Is it because it can't be >> done or you did not have time to add needed code? > > I'll have to double check, but I believe -DcheckOutput can be turned > back on. I suspect I never updated the @run lines after I changed > compareArrays() In void compareArrays(byte b[], byte exp[]) { You have: + if (mode.equals("GCM")) + return; for (int i=0; i< exp.length; i++) { if (b[i] != exp[i]) { So current changes do not compare arrays elements for GCM. That is why I asked. Thanks, Vladimir > >> Otherwise Hotspot code looks good. >> >> Thanks, >> Vladimir >> >>> >>> Thanks, >>> David >>> >>>> The review is for two repos, hotspot and jdk: >>>> >>>> http://cr.openjdk.java.net/~ascarpino/8073108/hotspot/webrev/ >>>> >>>> http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev/ >>>> >>>> thanks >>>> >>>> Tony > From john.r.rose at oracle.com Tue Feb 17 18:42:00 2015 From: john.r.rose at oracle.com (John Rose) Date: Tue, 17 Feb 2015 10:42:00 -0800 Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses In-Reply-To: <54E34EAF.6000802@redhat.com> References: <20150213230416.5E7B617FDAA@rebar.astron.com> <54DE8BB7.5050801@oracle.com> <54DE9140.3040604@oracle.com> <54E30C38.8000303@redhat.com> <54E31144.3040504@redhat.com> <54E314BF.3010205@redhat.com> <54E31677.1050209@redhat.com> <54E31CA6.6030609@redhat.com> <54E31DA0.2040901@redhat.com> <54E34EAF.6000802@redhat.com> Message-ID: <0457F01A-9DE1-4049-BFA2-66C7F6CCAA0B@oracle.com> On Feb 17, 2015, at 6:22 AM, Andrew Haley wrote: > > Everything gets inlined nicely and the ByteBuffer is not created, but > a store fence remains because of the final fields in HeapByteBuffer. Wow, that got closer to the goal than I expected. In general, the EA analysis can fail "at random" because of vagaries of inlining policy. The remaining store fence is probably a bug. A store fence for scalarized (lifted-out-of-memory) final fields should go away, since the fields are not actually stored in heap memory. I filed JDK-8073358 to track. BTW, we already elide synch. ops on scalarized (non-stored) objects. Fence elision is a similar optimization. ? John P.S. Value types will come with scalarization "always-on", so even if a call goes out of line, the value's fields can be kept out of the heap. One of the projected use cases of values is safe encapsulation for complex pointers (native or in-object). From anthony.scarpino at oracle.com Tue Feb 17 18:49:12 2015 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 17 Feb 2015 10:49:12 -0800 Subject: RFR: 8073108: GHASH Intrinsics In-Reply-To: <31E530B4-B880-4630-A830-663145817AC1@oracle.com> References: <54E25D03.7090705@oracle.com> <31E530B4-B880-4630-A830-663145817AC1@oracle.com> Message-ID: <54E38D28.2070305@oracle.com> On 02/16/2015 06:47 PM, John Rose wrote: > Cool stuff. I'm glad to see SPARC xmulx getting some play. > > This is not a review, but I have a small and a big comment. > > You don't need the argument vmIntrinsics::ID id unless you are going > to do something with it, such as expand one of a family of intrinsics > covered by the same LCK::inline* routine. Sure.. In my following the AES intrinsics as an example, I didn't catch 'id' pointlessness.. > You probably don't have enough parameter verification on the inputs > to processBlocks. A robust range check for a subsequence indexing > operation requires three comparison operations, not just one. The > Java code uses getLong which includes additional range checks, but > your intrinsic replacement code might not do that correctly; in any > case, it's better to have all the subsequence range checks in one > place, and in Java code. (Oh, and watch out for 32-bit integer > overflow: That causes surprises sometimes, when a value that is too > large wraps to negative, and then can seem to be in range relative to > a <= check.) > > In fact, I don't believe the existing parameter verification is very > helpful at all: > > if (inLen - inOfs > in.length) throw... > > This appears to allow a ridiculously large inLen as long as inOfs is > also ridiculously large. All of the "heavy lifting" is done by > intrinisic array range checks triggered by getLong, and those are the > checks that the assembly code does *not* do. Ok.. thanks.. I'll double check the range checking code.. > > ? John > > P.S. We should have a library API to do these parameter checks. > See: > https://bugs.openjdk.java.net/browse/JDK-8042997#comment-13610181 > > On Feb 16, 2015, at 1:11 PM, Anthony Scarpino > wrote: >> >> Hi, >> >> I'm requesting a code review to intrinsify the GHASH operations for >> both x86 and SPARC platforms. This greatly increases performance >> over software for AES/GCM crypto operations, details are in the >> bug. >> >> The review is for two repos, hotspot and jdk: >> >> http://cr.openjdk.java.net/~ascarpino/8073108/hotspot/webrev/ >> >> http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev/ >> >> thanks >> >> Tony > From dmitry.fazunenko at oracle.com Tue Feb 17 18:56:44 2015 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Tue, 17 Feb 2015 21:56:44 +0300 Subject: RFR (S): 8072687: Update OutputAnalyzer to work with files In-Reply-To: <65BF10CE-582D-448E-B5DA-5544276C0E16@oracle.com> References: <54E36511.7010608@oracle.com> <65BF10CE-582D-448E-B5DA-5544276C0E16@oracle.com> Message-ID: <54E38EEC.9020001@oracle.com> Hi Staffan, For me it's not clear why the constructor taking a String argument sets both stderr and stdout to the same value... But I don't see any reason to update this behavior and break compatibility. So I would agree, that the new constructor should be consistent with the existing one and set both out and err to the same string. Thanks, Dima On 17.02.2015 20:39, Staffan Larsen wrote: > There is constructor that takes a String argument. That constructor sets both stderr and stdout to that same String. Your constructor behaves differently and only sets stdout to the contents of the file. I have no idea why the existing constructor does what it does, but it would be good if the new and old had the same behavior. I haven?t looked at the use cases for the existing constructor. > > /S > >> On 17 feb 2015, at 16:58, denis kononenko wrote: >> >> Hi All, >> >> Could you please review a small change of OutputAnalyzer class from testlibrary. >> >> Webrev link: http://cr.openjdk.java.net/~dfazunen/dkononen/8072687/webrev.00/ >> Bug id: https://bugs.openjdk.java.net/browse/JDK-8072687 >> Testing: automated >> Description: >> >> The purpose of this change is to extend the functionality of OutputAnalyzer by adding ability to read output from a file. Sometimes we have to analyze output written to a file (test data, logs, etc.). In that case we have to read it as a string and pass it into OutputAnalyzer's constructor (it could be done in several different ways). It would be very convenient to put this code directly into OutputAnalyzer. This would allow to make further tests code more cleaner and less error prone. >> >> The change consist of two parts: >> 1) The change: OutputAnalyzer.java, added a new constructor that accepts File; >> 2) The tests: FileOutputAnalyzerTests.java, very basic tests on reading functionality. >> >> Thank you, >> Denis. >> >> From aph at redhat.com Tue Feb 17 18:58:19 2015 From: aph at redhat.com (Andrew Haley) Date: Tue, 17 Feb 2015 18:58:19 +0000 Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses In-Reply-To: <0457F01A-9DE1-4049-BFA2-66C7F6CCAA0B@oracle.com> References: <20150213230416.5E7B617FDAA@rebar.astron.com> <54DE8BB7.5050801@oracle.com> <54DE9140.3040604@oracle.com> <54E30C38.8000303@redhat.com> <54E31144.3040504@redhat.com> <54E314BF.3010205@redhat.com> <54E31677.1050209@redhat.com> <54E31CA6.6030609@redhat.com> <54E31DA0.2040901@redhat.com> <54E34EAF.6000802@redhat.com> <0457F01A-9DE1-4049-BFA2-66C7F6CCAA0B@oracle.com> Message-ID: <54E38F4B.7060100@redhat.com> On 02/17/2015 06:42 PM, John Rose wrote: > The remaining store fence is probably a bug. A store fence for scalarized (lifted-out-of-memory) final fields should go away, since the fields are not actually stored in heap memory. After inlining how would escape analysis know that the store fence is associated with final fields rather than, say, an explicit Unsafe.storeFence() ? Andrew. From vitalyd at gmail.com Tue Feb 17 19:12:31 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 17 Feb 2015 14:12:31 -0500 Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses In-Reply-To: <54E38F4B.7060100@redhat.com> References: <20150213230416.5E7B617FDAA@rebar.astron.com> <54DE8BB7.5050801@oracle.com> <54DE9140.3040604@oracle.com> <54E30C38.8000303@redhat.com> <54E31144.3040504@redhat.com> <54E314BF.3010205@redhat.com> <54E31677.1050209@redhat.com> <54E31CA6.6030609@redhat.com> <54E31DA0.2040901@redhat.com> <54E34EAF.6000802@redhat.com> <0457F01A-9DE1-4049-BFA2-66C7F6CCAA0B@oracle.com> <54E38F4B.7060100@redhat.com> Message-ID: What do you mean exactly? I don't think inlining "hides" anything, so the explicit fence should still be there for EA to see (and preserve). sent from my phone On Feb 17, 2015 1:58 PM, "Andrew Haley" wrote: > On 02/17/2015 06:42 PM, John Rose wrote: > > The remaining store fence is probably a bug. A store fence for > scalarized (lifted-out-of-memory) final fields should go away, since the > fields are not actually stored in heap memory. > > After inlining how would escape analysis know that the store fence is > associated with final fields rather than, say, an explicit > Unsafe.storeFence() ? > > Andrew. > > From vladimir.kozlov at oracle.com Tue Feb 17 19:15:48 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 17 Feb 2015 11:15:48 -0800 Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses In-Reply-To: <54E38F4B.7060100@redhat.com> References: <20150213230416.5E7B617FDAA@rebar.astron.com> <54DE8BB7.5050801@oracle.com> <54DE9140.3040604@oracle.com> <54E30C38.8000303@redhat.com> <54E31144.3040504@redhat.com> <54E314BF.3010205@redhat.com> <54E31677.1050209@redhat.com> <54E31CA6.6030609@redhat.com> <54E31DA0.2040901@redhat.com> <54E34EAF.6000802@redhat.com> <0457F01A-9DE1-4049-BFA2-66C7F6CCAA0B@oracle.com> <54E38F4B.7060100@redhat.com> Message-ID: <54E39364.6030409@oracle.com> There was discussion should we remove such barriers or not because they create memory operations ordering which could be different if we remove them. To eliminate them we need to add 'precedent' edge to store's membar as we do, for example, for loads: if (field->is_volatile()) { // Memory barrier includes bogus read of value to force load BEFORE membar insert_mem_bar(Op_MemBarAcquire, ld); } MemBarNode::Ideal() will do elimination. Regards, Vladimir On 2/17/15 10:58 AM, Andrew Haley wrote: > On 02/17/2015 06:42 PM, John Rose wrote: >> The remaining store fence is probably a bug. A store fence for scalarized (lifted-out-of-memory) final fields should go away, since the fields are not actually stored in heap memory. > > After inlining how would escape analysis know that the store fence is > associated with final fields rather than, say, an explicit > Unsafe.storeFence() ? > > Andrew. > From vitalyd at gmail.com Tue Feb 17 19:21:13 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 17 Feb 2015 14:21:13 -0500 Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses In-Reply-To: <54E39364.6030409@oracle.com> References: <20150213230416.5E7B617FDAA@rebar.astron.com> <54DE8BB7.5050801@oracle.com> <54DE9140.3040604@oracle.com> <54E30C38.8000303@redhat.com> <54E31144.3040504@redhat.com> <54E314BF.3010205@redhat.com> <54E31677.1050209@redhat.com> <54E31CA6.6030609@redhat.com> <54E31DA0.2040901@redhat.com> <54E34EAF.6000802@redhat.com> <0457F01A-9DE1-4049-BFA2-66C7F6CCAA0B@oracle.com> <54E38F4B.7060100@redhat.com> <54E39364.6030409@oracle.com> Message-ID: IMO I don't think such barriers should be removed just because EA is able to elide the heap allocation. On Tue, Feb 17, 2015 at 2:15 PM, Vladimir Kozlov wrote: > There was discussion should we remove such barriers or not because they > create memory operations ordering which could be different if we remove > them. > > To eliminate them we need to add 'precedent' edge to store's membar as we > do, for example, for loads: > > if (field->is_volatile()) { > // Memory barrier includes bogus read of value to force load BEFORE > membar > insert_mem_bar(Op_MemBarAcquire, ld); > } > > MemBarNode::Ideal() will do elimination. > > Regards, > Vladimir > > > On 2/17/15 10:58 AM, Andrew Haley wrote: > >> On 02/17/2015 06:42 PM, John Rose wrote: >> >>> The remaining store fence is probably a bug. A store fence for >>> scalarized (lifted-out-of-memory) final fields should go away, since the >>> fields are not actually stored in heap memory. >>> >> >> After inlining how would escape analysis know that the store fence is >> associated with final fields rather than, say, an explicit >> Unsafe.storeFence() ? >> >> Andrew. >> >> From anthony.scarpino at oracle.com Tue Feb 17 19:46:31 2015 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 17 Feb 2015 11:46:31 -0800 Subject: RFR: 8073108: GHASH Intrinsics In-Reply-To: <54E38B6F.9050106@oracle.com> References: <54E25D03.7090705@oracle.com> <54E2982D.9020902@oracle.com> <54E2A10A.6090007@oracle.com> <54E38909.5070800@oracle.com> <54E38B6F.9050106@oracle.com> Message-ID: <54E39A97.3060206@oracle.com> On 02/17/2015 10:41 AM, Vladimir Kozlov wrote: > On 2/17/15 10:31 AM, Anthony Scarpino wrote: >> On 02/16/2015 06:01 PM, Vladimir Kozlov wrote: >>> There is #ifdef _WIN64 in stubGenerator_x86_32.cpp. It is not needed >>> since it is 32-bit code. >> >> Sure.. Do I still need to save the xmm6 and xmm7 on 32bit code, or is >> all of the register saving only for Windows 64bit? > > No, in 32-bit you don't need to save xmm6 and xmm7. Ok, thanks > >> >>> >>> I see you switched off -DcheckOutput=false for GCM testing and return >>> from compareArrays() after length compare. Is it because it can't be >>> done or you did not have time to add needed code? >> >> I'll have to double check, but I believe -DcheckOutput can be turned >> back on. I suspect I never updated the @run lines after I changed >> compareArrays() > > In void compareArrays(byte b[], byte exp[]) { > > You have: > > + if (mode.equals("GCM")) > + return; > for (int i=0; i< exp.length; i++) { > if (b[i] != exp[i]) { > > So current changes do not compare arrays elements for GCM. That is why I > asked. I did this because there are checks in GCM to prevent reusing IVs. The current design of the hotspot test reuses IVs so that the encrypted or decrypted result is returned o compare, which is ok for CBC and ECB. Since I wasn't able to get a reproducible result for GCM, I skipped the array checking. What I am depending on to test GCM is the TestGHASH test in the jdk repo, which is a Known Answer Test, to make sure the GHASH intrinsics are correct to the spec. All that being said, I will look at this again. I originally didn't want to completely redesign the hotspot tests when I had TestGHASH already, but I'll go back to see what changes I can do to hopefully get compareArrays working. Tony From anthony.scarpino at oracle.com Tue Feb 17 19:59:08 2015 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 17 Feb 2015 11:59:08 -0800 Subject: RFR: 8073108: GHASH Intrinsics In-Reply-To: <54E3028A.7040102@redhat.com> References: <54E25D03.7090705@oracle.com> <54E3028A.7040102@redhat.com> Message-ID: <54E39D8C.8050705@oracle.com> On 02/17/2015 12:57 AM, Florian Weimer wrote: > On 02/16/2015 10:11 PM, Anthony Scarpino wrote: >> http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev/ > > I think the ?state? field in GHASH should be final. Is C2 able to > eliminate the array bounds checks? (Although it's not in the inner loop > and thus probably not relevant for performance.) I'm not sure want you asking about in regard to the bounds checking? Are you asking about checking the bounds of "state"? > > The comment on processBlock(byte[], int, int) is confusing. I don't > understand what it is trying to say. That is why I can never proofread my own writing. :) I'll fix that up.. What means to say is the method arguments list and method name cannot be changed, along with some operations inside the method cannot occur or it can break intrinsics. From anthony.scarpino at oracle.com Tue Feb 17 20:03:52 2015 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 17 Feb 2015 12:03:52 -0800 Subject: RFR: 8073108: GHASH Intrinsics In-Reply-To: <54E31F05.2020805@redhat.com> References: <54E25D03.7090705@oracle.com> <54E31F05.2020805@redhat.com> Message-ID: <54E39EA8.6080004@oracle.com> On 02/17/2015 02:59 AM, Florian Weimer wrote: > On 02/16/2015 10:11 PM, Anthony Scarpino wrote: >> Hi, >> >> I'm requesting a code review to intrinsify the GHASH operations for both >> x86 and SPARC platforms. This greatly increases performance over >> software for AES/GCM crypto operations, details are in the bug. >> >> The review is for two repos, hotspot and jdk: >> >> http://cr.openjdk.java.net/~ascarpino/8073108/hotspot/webrev/ > > Sorry for double-posting. > > I looked at generate_ghash_processBlocks() and wonder if the loop needs > to be split to introduce occasional safepoints. The TLS record size > should limit the number bytes per invocation to 16000, so perhaps this > isn't issue for the current application. I would think TLS limits should be handled in a JSSE or other TLS area. I think GHASH should be the pure implementation. Tony From fweimer at redhat.com Tue Feb 17 20:05:14 2015 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 17 Feb 2015 21:05:14 +0100 Subject: RFR: 8073108: GHASH Intrinsics In-Reply-To: <54E39D8C.8050705@oracle.com> References: <54E25D03.7090705@oracle.com> <54E3028A.7040102@redhat.com> <54E39D8C.8050705@oracle.com> Message-ID: <54E39EFA.8060904@redhat.com> On 02/17/2015 08:59 PM, Anthony Scarpino wrote: > On 02/17/2015 12:57 AM, Florian Weimer wrote: >> On 02/16/2015 10:11 PM, Anthony Scarpino wrote: >>> http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev/ >> >> I think the ?state? field in GHASH should be final. Is C2 able to >> eliminate the array bounds checks? (Although it's not in the inner loop >> and thus probably not relevant for performance.) > > I'm not sure want you asking about in regard to the bounds checking? Are > you asking about checking the bounds of "state"? state[0] and state[1]?I wonder if those expressions need array bounds checks when compiled. >> The comment on processBlock(byte[], int, int) is confusing. I don't >> understand what it is trying to say. > > That is why I can never proofread my own writing. :) > I'll fix that up.. What means to say is the method arguments list and > method name cannot be changed, along with some operations inside the > method cannot occur or it can break intrinsics. Yes, that's certainly helpful. Usually, the JDK does not have hints pointing to Hotspot intrinsics. But most of them deal with public APIs which are frozen anyway. -- Florian Weimer / Red Hat Product Security From fweimer at redhat.com Tue Feb 17 20:06:19 2015 From: fweimer at redhat.com (Florian Weimer) Date: Tue, 17 Feb 2015 21:06:19 +0100 Subject: RFR: 8073108: GHASH Intrinsics In-Reply-To: <54E39EA8.6080004@oracle.com> References: <54E25D03.7090705@oracle.com> <54E31F05.2020805@redhat.com> <54E39EA8.6080004@oracle.com> Message-ID: <54E39F3B.2030006@redhat.com> On 02/17/2015 09:03 PM, Anthony Scarpino wrote: > On 02/17/2015 02:59 AM, Florian Weimer wrote: >> On 02/16/2015 10:11 PM, Anthony Scarpino wrote: >>> Hi, >>> >>> I'm requesting a code review to intrinsify the GHASH operations for both >>> x86 and SPARC platforms. This greatly increases performance over >>> software for AES/GCM crypto operations, details are in the bug. >>> >>> The review is for two repos, hotspot and jdk: >>> >>> http://cr.openjdk.java.net/~ascarpino/8073108/hotspot/webrev/ >> >> Sorry for double-posting. >> >> I looked at generate_ghash_processBlocks() and wonder if the loop needs >> to be split to introduce occasional safepoints. The TLS record size >> should limit the number bytes per invocation to 16000, so perhaps this >> isn't issue for the current application. > > I would think TLS limits should be handled in a JSSE or other TLS area. > I think GHASH should be the pure implementation. Sorry, what I'm trying to say is that TLS won't trigger this issue because its loops will be reasonably short. There might be other users for which this could be a problem, though. -- Florian Weimer / Red Hat Product Security From anthony.scarpino at oracle.com Tue Feb 17 21:00:41 2015 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 17 Feb 2015 13:00:41 -0800 Subject: RFR: 8073108: GHASH Intrinsics In-Reply-To: <54E39EFA.8060904@redhat.com> References: <54E25D03.7090705@oracle.com> <54E3028A.7040102@redhat.com> <54E39D8C.8050705@oracle.com> <54E39EFA.8060904@redhat.com> Message-ID: <54E3ABF9.3030706@oracle.com> On 02/17/2015 12:05 PM, Florian Weimer wrote: > On 02/17/2015 08:59 PM, Anthony Scarpino wrote: >> On 02/17/2015 12:57 AM, Florian Weimer wrote: >>> On 02/16/2015 10:11 PM, Anthony Scarpino wrote: >>>> http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev/ >>> >>> I think the ?state? field in GHASH should be final. Is C2 able to >>> eliminate the array bounds checks? (Although it's not in the inner loop >>> and thus probably not relevant for performance.) >> >> I'm not sure want you asking about in regard to the bounds checking? Are >> you asking about checking the bounds of "state"? > > state[0] and state[1]?I wonder if those expressions need array bounds > checks when compiled. The glossary says C2 eliminates array range checking. http://openjdk.java.net/groups/hotspot/docs/HotSpotGlossary.html Tony From vladimir.kozlov at oracle.com Tue Feb 17 21:14:49 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 17 Feb 2015 13:14:49 -0800 Subject: RFR: 8073108: GHASH Intrinsics In-Reply-To: <54E3ABF9.3030706@oracle.com> References: <54E25D03.7090705@oracle.com> <54E3028A.7040102@redhat.com> <54E39D8C.8050705@oracle.com> <54E39EFA.8060904@redhat.com> <54E3ABF9.3030706@oracle.com> Message-ID: <54E3AF49.6060102@oracle.com> Florian's concern is valid. "Range check elimination" means that C2 moves checks from a loop. Checks are still present. Since 'state' array is not final we can't eliminate range check. An other thing is an additional indirect load to access arrays elements. I would suggest to keep original code for 'subkey' and 'state' which use separate values instead of arrays. Regards, Vladimir On 2/17/15 1:00 PM, Anthony Scarpino wrote: > On 02/17/2015 12:05 PM, Florian Weimer wrote: >> On 02/17/2015 08:59 PM, Anthony Scarpino wrote: >>> On 02/17/2015 12:57 AM, Florian Weimer wrote: >>>> On 02/16/2015 10:11 PM, Anthony Scarpino wrote: >>>>> http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev/ >>>> >>>> I think the ?state? field in GHASH should be final. Is C2 able to >>>> eliminate the array bounds checks? (Although it's not in the inner >>>> loop >>>> and thus probably not relevant for performance.) >>> >>> I'm not sure want you asking about in regard to the bounds checking? Are >>> you asking about checking the bounds of "state"? >> >> state[0] and state[1]?I wonder if those expressions need array bounds >> checks when compiled. > > The glossary says C2 eliminates array range checking. > http://openjdk.java.net/groups/hotspot/docs/HotSpotGlossary.html > > Tony > From david.holmes at oracle.com Tue Feb 17 21:23:16 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 18 Feb 2015 07:23:16 +1000 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <54E183B8.5010301@oracle.com> References: <531E8309.2060206@oracle.com> <531ED06F.5040905@oracle.com> <107001365.11810418.1423839439509.JavaMail.zimbra@redhat.com> <54E183B8.5010301@oracle.com> Message-ID: <54E3B144.1090402@oracle.com> On 16/02/2015 3:44 PM, David Holmes wrote: > I have no issue with this minimal change for hotspot. > > I suppose I can also volunteer to sponsor it. :) > > Is the plan to also do the JDK changes under the same bug? That will > need build-dev involvement. Still waiting to see if this will these hotspot-only changes or whether there is more in the works. Thanks, David > David > > On 14/02/2015 2:37 AM, Volker Simonis wrote: >> On Fri, Feb 13, 2015 at 3:57 PM, Andrew Hughes >> wrote: >>> ----- Original Message ----- >>>> On 11/03/2014 6:36 PM, Volker Simonis wrote: >>>>> On Tue, Mar 11, 2014 at 4:29 AM, David Holmes >>>>> >>>>> wrote: >>>>>> I don't see anything that actually controls what is built. Is it >>>>>> the case >>>>>> that the new arch value will be reported by uname on the ppc64le >>>>>> system? >>>>>> >>>>>> (I cringe seeing a new top-level arch introduced for this.) >>>>>> >>>>> >>>>> I didn't liked this too much as well in my first review and I think we >>>>> can get along without a new top-level arch (see >>>>> http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2014-March/001790.html). >>>>> >>>>> >>>>> But in the end I can live with both approaches (and having two >>>>> top-level archs probably makes it slightly simpler to support them >>>>> both in parallel) so I think finally it is up to you which approach we >>>>> take. >>>> >>>> I agree with your initial review. I don't see a LE build as a distinct >>>> architecture but a variant of ppc64. >>>> >>>> Lets see what anyone else has to say. >>>> >>>> Thanks, >>>> David >>>> >>>> >>>> >>>> >>>> >>>>> Regards, >>>>> Volker >>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> >>>>>> On 7/03/2014 1:37 PM, Alexander Smundak wrote: >>>>>>> >>>>>>> This patch contains the changes to the build files to build JDK >>>>>>> on the >>>>>>> little endian PowerPC64 running Linux, and the changes to the source >>>>>>> files to support little endian mode. >>>>>>> This preceding related change >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8036767 added support >>>>>>> for the >>>>>>> ELFv2 ABi used on the little endian PowerPC64. >>>>>>> >>>>>>> Please review and test this change. I need a sponsor. >>>>>>> >>>>>>> The patch is at: >>>>>>> http://cr.openjdk.java.net/~martin/asmundak/8036767/webrev.00/ >>>>>>> >>>>>>> Sasha >>>>>>> >>>>>> >>>> >>> >>> We're now seeing problems with Java tools on ppc64le as a result of this >>> decision not to give it a distinct arch name. >>> >>> The os.arch property on both ppc64be and ppc64le builds of OpenJDK is >>> being >>> reported as the same; "ppc64". This leaves Java applications no way of >>> determining which of the two platforms the JDK is running on and, for >>> example, >>> means that Maven can't determine which native JNI binaries to download. >>> >>> There is a sun.cpu.endian property but this is non-standard and it seems >>> wrong to me that every Java tool should have to add a special case for >>> ppc64le using such a property. This value is traditionally not so much >>> just the architecture as a composite of the architecture, the bit size >>> and the endianness. The only difference with other platforms is that >>> they >>> only support one default endianness so the value is implied e.g. >>> little-endian for amd64, big-endian for sparc. We do distinguish between >>> ppc and ppc64 rather than expecting tools to check sun.arch.data.model, >>> so we should do the same with endianness. >>> >>> To add to the confusion, other JDKs are reporting it as ppc64le >>> (thanks to Tiago Sturmer Daitx for these results): >>> >>> IBM Java 2.7 SR1 >>> os.arch: ppc64le >>> sun.cpu.endian: little >>> >>> GCJ 4.8.2 (gij (GNU libgcj) version 4.8.2): >>> os.arch: ppc64le >>> sun.cpu.endian: null >>> >>> whereas OpenJDK gives: >>> >>> os.arch: ppc64 >>> sun.cpu.endian: little >>> >>> It also means that ppc64le is alone in not having a unique architecture >>> directory in jre/lib. I understand that a ppc64le machine is not going >>> to support ppc64be, but likewise amd64 is not going to support arm, >>> yet they have unique arch directories. >>> >>> I've prepared a webrev which fixes the external facing architecture >>> names, >>> LIBARCH and os.name, while leaving the HotSpot build architecture, >>> BUILDARCH, >>> as it is, to avoid the duplication mentioned as a problem in the >>> original >>> review. >>> >>> http://cr.openjdk.java.net/~andrew/rh1191652/webrev.01/ >>> >>> This is against our IcedTea OpenJDK7-based HotSpot where we've been >>> testing >>> but it should still be applicable to the 9 HotSpot repositories. The >>> JDK side >>> is another issue and I suspect we'll need a completely different >>> patch there >>> to the one we have for 7. >>> >>> Our builds of OpenJDK 7 with this fixed now give: >>> >>> java.library.path = >>> /usr/java/packages/lib/ppc64le:/usr/lib64:/lib64:/lib:/usr/lib >>> sun.boot.library.path = >>> /builddir/build/BUILD/java-1.7.0-openjdk-1.7.0.75-2.5.4.5.ael7b.ppc64le/openjdk/build/linux-ppc64le/j2sdk-image/jre/lib/ppc64le >>> >>> os.arch = ppc64le >>> >>> I've filed a bug for this here: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8073139 >>> >>> Thanks, >>> -- >>> Andrew :) >>> >>> 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 >>> >>> PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) >>> Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 >>> >> >> Hi Andrew, >> >> I don't have a problem with your change and it doesn't affect the >> ppc64 big endian build. >> >> I've prepared a patch which applies cleanly to jdk9-hs-rt here: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2015/8073139/ >> >> Let's here some other opinions as well (you'll need a sponsor from >> Oracle anyway and it would also be interesting to here from Alexander >> if they already rely on os.arch being ppc64) but from my side thumbs >> up. >> >> Regards, >> Volker >> From jesper.wilhelmsson at oracle.com Tue Feb 17 21:56:43 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 17 Feb 2015 22:56:43 +0100 Subject: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CF9615F@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CF9615F@DEWDFEMB12A.global.corp.sap> Message-ID: <54E3B91B.8010408@oracle.com> Hi Goetz, Thanks for doing this work! Overall I think it looks great! I only have a few minor comments. * In a many places you have removed the >=0 check with no further action. In most places this is clearly the right thing to do, but there are a few places where I'm thinking that the check may express a concern from the author of the code that some expression might overflow/underflow and the check is needed. Since the check is pointless as such the function of the code is unchanged when removing this check, but the author's gut feeling that something might go wrong is lost. I might be paranoid but I would prefer if we add asserts in these places to make sure the expressions are checked properly. The places where I think this could be motivated are in os_linux.cpp and parCardTableModRefBS.cpp * In heapRegionSet.cpp I would prefer if the condition was on one line now when the second part is so short. Thanks, /Jesper Lindenmaier, Goetz skrev den 17/2/15 12:42: > Hi, > > We fixed all the warnings showing with -Wtype-limits and gcc in our VM. > I would like to contribute these small changes. > > This warning detects unnecessary compares for >= 0 of unsigned values. > > At least one warning unveils a real bug. In memory/blockOffsetTable.cpp, > BlockOffsetArrayContigSpace::last_active_index(), the compare to >=0 > tries to prevent an underflow, but the value is unsigned. > > Further useless compares in real code are in os_linux.cpp, > opto/graphKit.cpp, prims/jvmtiRedefineClasses.cpp > > In some places debug code with constant debug flags caused > warnings in the opt build (g1/concurrentMark.cpp, classfile/systemDictionary.cpp) > > The remaining warnings occur in asserts, which is also the biggest part. > > The change also removes an empty #ifdef ASSERT . > > Please review this change. I please need a sponsor. > https://bugs.openjdk.java.net/browse/JDK-8073315 > http://cr.openjdk.java.net/~goetz/webrevs/8073315-wUnsign/webrev.01/ > > I tested this on linuxx86_64 with gcc 4.1.2, 4.3 and 4.8. Further I ran the patch > with our nightly builds and tests of jdk9,see > http://cr.openjdk.java.net/~simonis/ppc-aix-port/index.html > > Best regards, > Goetz. > From anthony.scarpino at oracle.com Tue Feb 17 22:03:33 2015 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 17 Feb 2015 14:03:33 -0800 Subject: RFR: 8073108: GHASH Intrinsics In-Reply-To: <54E3AF49.6060102@oracle.com> References: <54E25D03.7090705@oracle.com> <54E3028A.7040102@redhat.com> <54E39D8C.8050705@oracle.com> <54E39EFA.8060904@redhat.com> <54E3ABF9.3030706@oracle.com> <54E3AF49.6060102@oracle.com> Message-ID: <54E3BAB5.8090506@oracle.com> On 02/17/2015 01:14 PM, Vladimir Kozlov wrote: > Florian's concern is valid. > > "Range check elimination" means that C2 moves checks from a loop. Checks > are still present. Since 'state' array is not final we can't eliminate > range check. I don't understand the concern here. The arrays are private and are only used by math calculations either in the same GHASH object or by the intrinsics. What ranges check issues are we expecting to occur given they are inaccessible by an API? > An other thing is an additional indirect load to access > arrays elements. > > I would suggest to keep original code for 'subkey' and 'state' which use > separate values instead of arrays. By the indirect loading, you referring to the loading done by get_vars_from_ghash_object() in library_call.cpp? If so, I thought it would be faster to load the 128bit values directly into one register instead of loading one long from the class to a register, shift left, loading the second long and xor'ing into the register. The assembly code is doing the math on the whole 128bit value, while the GHASH.java side needs to split it into 2 values. Putting it into an array makes in easy, coding wise, to access the whole 128bit value at once. If the suggestion also is to put the 4 longs on the argument list, that would be 7 arguments for processBlocks, which would be ugly and not useful for the non-intrinsic side since GHASH.java would ignore the longs. > > Regards, > Vladimir > > > On 2/17/15 1:00 PM, Anthony Scarpino wrote: >> On 02/17/2015 12:05 PM, Florian Weimer wrote: >>> On 02/17/2015 08:59 PM, Anthony Scarpino wrote: >>>> On 02/17/2015 12:57 AM, Florian Weimer wrote: >>>>> On 02/16/2015 10:11 PM, Anthony Scarpino wrote: >>>>>> http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev/ >>>>> >>>>> I think the ?state? field in GHASH should be final. Is C2 able to >>>>> eliminate the array bounds checks? (Although it's not in the inner >>>>> loop >>>>> and thus probably not relevant for performance.) >>>> >>>> I'm not sure want you asking about in regard to the bounds checking? >>>> Are >>>> you asking about checking the bounds of "state"? >>> >>> state[0] and state[1]?I wonder if those expressions need array bounds >>> checks when compiled. >> >> The glossary says C2 eliminates array range checking. >> http://openjdk.java.net/groups/hotspot/docs/HotSpotGlossary.html >> >> Tony >> From dean.long at oracle.com Tue Feb 17 22:22:34 2015 From: dean.long at oracle.com (Dean Long) Date: Tue, 17 Feb 2015 14:22:34 -0800 Subject: RFR: JDK-8072904: building jdk9 with jdk9 boot jdk can cause failure or incorrect results In-Reply-To: <54DBB784.4030206@oracle.com> References: <54DB1F96.7080602@oracle.com> <54DB26A1.3030906@oracle.com> <54DB3E9E.4030407@oracle.com> <54DBB784.4030206@oracle.com> Message-ID: <54E3BF2A.80501@oracle.com> Looks good to me too. dl On 2/11/2015 12:11 PM, David Holmes wrote: > On 11/02/2015 9:35 PM, Erik Joelsson wrote: >> Hello, >> >> New webrev: http://cr.openjdk.java.net/~erikj/8072904/webrev.hotspot.02/ >> >> On 2015-02-11 10:53, David Holmes wrote: >>> Hi Erik, >>> >>> On 11/02/2015 7:23 PM, Erik Joelsson wrote: >>>> Hello, >>>> >>>> Please review this change to how javah is run on sa classes. Since the >>>> sa classes in JDK 9 are now in a module instead of sa-jdi.jar, they >>>> are >>>> (at least currently) available from the default bootclasspath. This >>>> means that just setting -classpath to javah will not properly override >>>> the versions of the classes found in the boot jdk with the versions >>>> currently being built. The fix is to change -classpath with >>>> -Xbootclasspath/p:. >>> >>> Seems like a temporary workaround. javah should have a way to indicate >>> which class to process without assuming it comes from the JVM used to >>> run javah. Also putting what was sa-jdi.jar on the bootclasspath seems >>> somewhat misplaced - these aren't "boot" classes. >>> >> It was also pointed out to me that -Xbootclasspath is not future proof. >> So instead I opted for a different solution, using the new javac flag -h >> and the @Native annotation to automatically generate header files during >> compilation. >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8072904 >>>> Webrev: http://cr.openjdk.java.net/~erikj/8072904/webrev.hotspot.01/ >>> >>> Were are the changes for all the other (non-linux) platforms? :) >>> >> Right, I forgot about that. *sigh* This time I made the changes in all >> the makefiles. > > :) Thanks Erik this looks good to me. I'd completely forgotten about > @Native - much cleaner solution! > > David > >> /Erik From vladimir.kozlov at oracle.com Tue Feb 17 22:30:08 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 17 Feb 2015 14:30:08 -0800 Subject: RFR: 8073108: GHASH Intrinsics In-Reply-To: <54E3BAB5.8090506@oracle.com> References: <54E25D03.7090705@oracle.com> <54E3028A.7040102@redhat.com> <54E39D8C.8050705@oracle.com> <54E39EFA.8060904@redhat.com> <54E3ABF9.3030706@oracle.com> <54E3AF49.6060102@oracle.com> <54E3BAB5.8090506@oracle.com> Message-ID: <54E3C0F0.5090203@oracle.com> The concern was about java code and not intrinsic. If intrinsic is not used we will get additional range checks which were not present before. By indirect load I mean object->array_oop->element instead of object->field. But in blockMult() you access them outside main loops. As result the code without intrinsic should not be affected much. So, please, ignore my suggestion about "keep 'subkey' and 'state' original values". You are right for intrinsic it is better to use arrays. Anyway, all is fine except you may need to check that size of arrays is at least 2 before calling processBlocks(). thanks, Vladimir On 2/17/15 2:03 PM, Anthony Scarpino wrote: > On 02/17/2015 01:14 PM, Vladimir Kozlov wrote: >> Florian's concern is valid. >> >> "Range check elimination" means that C2 moves checks from a loop. Checks >> are still present. Since 'state' array is not final we can't eliminate >> range check. > > I don't understand the concern here. The arrays are private and are > only used by math calculations either in the same GHASH object or by the > intrinsics. What ranges check issues are we expecting to occur given > they are inaccessible by an API? > >> An other thing is an additional indirect load to access >> arrays elements. >> >> I would suggest to keep original code for 'subkey' and 'state' which use >> separate values instead of arrays. > > By the indirect loading, you referring to the loading done by > get_vars_from_ghash_object() in library_call.cpp? If so, I thought it > would be faster to load the 128bit values directly into one register > instead of loading one long from the class to a register, shift left, > loading the second long and xor'ing into the register. The assembly > code is doing the math on the whole 128bit value, while the GHASH.java > side needs to split it into 2 values. Putting it into an array makes in > easy, coding wise, to access the whole 128bit value at once. > > If the suggestion also is to put the 4 longs on the argument list, that > would be 7 arguments for processBlocks, which would be ugly and not > useful for the non-intrinsic side since GHASH.java would ignore the longs. > > > >> Regards, >> Vladimir >> >> >> On 2/17/15 1:00 PM, Anthony Scarpino wrote: >>> On 02/17/2015 12:05 PM, Florian Weimer wrote: >>>> On 02/17/2015 08:59 PM, Anthony Scarpino wrote: >>>>> On 02/17/2015 12:57 AM, Florian Weimer wrote: >>>>>> On 02/16/2015 10:11 PM, Anthony Scarpino wrote: >>>>>>> http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev/ >>>>>> >>>>>> I think the ?state? field in GHASH should be final. Is C2 able to >>>>>> eliminate the array bounds checks? (Although it's not in the inner >>>>>> loop >>>>>> and thus probably not relevant for performance.) >>>>> >>>>> I'm not sure want you asking about in regard to the bounds checking? >>>>> Are >>>>> you asking about checking the bounds of "state"? >>>> >>>> state[0] and state[1]?I wonder if those expressions need array bounds >>>> checks when compiled. >>> >>> The glossary says C2 eliminates array range checking. >>> http://openjdk.java.net/groups/hotspot/docs/HotSpotGlossary.html >>> >>> Tony >>> > From kim.barrett at oracle.com Tue Feb 17 23:27:36 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 17 Feb 2015 18:27:36 -0500 Subject: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CF9615F@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CF9615F@DEWDFEMB12A.global.corp.sap> Message-ID: <70B02DBE-E246-45F9-89C7-898881B0C69A@oracle.com> On Feb 17, 2015, at 6:42 AM, Lindenmaier, Goetz wrote: > > We fixed all the warnings showing with -Wtype-limits and gcc in our VM. > I would like to contribute these small changes. > > This warning detects unnecessary compares for >= 0 of unsigned values. > > At least one warning unveils a real bug. In memory/blockOffsetTable.cpp, > BlockOffsetArrayContigSpace::last_active_index(), the compare to >=0 > tries to prevent an underflow, but the value is unsigned. > > Further useless compares in real code are in os_linux.cpp, > opto/graphKit.cpp, prims/jvmtiRedefineClasses.cpp > > In some places debug code with constant debug flags caused > warnings in the opt build (g1/concurrentMark.cpp, classfile/systemDictionary.cpp) > > The remaining warnings occur in asserts, which is also the biggest part. > > The change also removes an empty #ifdef ASSERT . > > Please review this change. I please need a sponsor. > https://bugs.openjdk.java.net/browse/JDK-8073315 > http://cr.openjdk.java.net/~goetz/webrevs/8073315-wUnsign/webrev.01/ > > I tested this on linuxx86_64 with gcc 4.1.2, 4.3 and 4.8. Further I ran the patch > with our nightly builds and tests of jdk9,see > http://cr.openjdk.java.net/~simonis/ppc-aix-port/index.html -Wtype-limits is one of those somewhat questionable warnings that are enabled by -Wextra. As Jesper noted, there are cases where, yes, the warning is correct today, but future maintenance might change that. And the information that one needs in order to make that determination might be far away from the expression generating the warning. This warning can also lead to serious ugliness with generic code (e.g. templates), where only some values of a type parameter trigger warnings. I've seen real code that used template metapogramming to select different expressions in order to dodge this specific warning. In other words, while this warning does sometimes find real bugs, it also tends to generate a lot of false positives. Because of that, I'm not sure it's actually a good idea to enable it. For the specific bug mentioned, I would like to just see that fixed, but not in the way that was done in the webrev, e.g. incorrect old: 794 size_t BlockOffsetArrayContigSpace::last_active_index() const { 795 size_t result = _next_offset_index - 1; 796 return result >= 0 ? result : 0; 797 } webrev: 794 size_t BlockOffsetArrayContigSpace::last_active_index() const { 795 size_t result = _next_offset_index - 1; 796 return ((intptr_t)result) >= 0 ? result : 0; 797 } better: size_t BlockOffsetArrayContigSpace::last_active_index() const { size_t next = _next_offset_index; return next == 0 ? 0 : next - 1; } Eschew unnecessary casts! From fweimer at redhat.com Tue Feb 17 23:52:11 2015 From: fweimer at redhat.com (Florian Weimer) Date: Wed, 18 Feb 2015 00:52:11 +0100 Subject: RFR: 8073108: GHASH Intrinsics In-Reply-To: <54E3C0F0.5090203@oracle.com> References: <54E25D03.7090705@oracle.com> <54E3028A.7040102@redhat.com> <54E39D8C.8050705@oracle.com> <54E39EFA.8060904@redhat.com> <54E3ABF9.3030706@oracle.com> <54E3AF49.6060102@oracle.com> <54E3BAB5.8090506@oracle.com> <54E3C0F0.5090203@oracle.com> Message-ID: <54E3D42B.2010202@redhat.com> On 02/17/2015 11:30 PM, Vladimir Kozlov wrote: > The concern was about java code and not intrinsic. If intrinsic is not > used we will get additional range checks which were not present before. > > By indirect load I mean object->array_oop->element instead of > object->field. > > But in blockMult() you access them outside main loops. As result the > code without intrinsic should not be affected much. Making the state field final is still a good idea, I think. -- Florian Weimer / Red Hat Product Security From anthony.scarpino at oracle.com Tue Feb 17 23:57:15 2015 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 17 Feb 2015 15:57:15 -0800 Subject: RFR: 8073108: GHASH Intrinsics In-Reply-To: <54E3C0F0.5090203@oracle.com> References: <54E25D03.7090705@oracle.com> <54E3028A.7040102@redhat.com> <54E39D8C.8050705@oracle.com> <54E39EFA.8060904@redhat.com> <54E3ABF9.3030706@oracle.com> <54E3AF49.6060102@oracle.com> <54E3BAB5.8090506@oracle.com> <54E3C0F0.5090203@oracle.com> Message-ID: <54E3D55B.60507@oracle.com> Ok, I'll add these checks.. Thanks for looking through this. Tony On 02/17/2015 02:30 PM, Vladimir Kozlov wrote: > The concern was about java code and not intrinsic. If intrinsic is not > used we will get additional range checks which were not present before. > > By indirect load I mean object->array_oop->element instead of > object->field. > > But in blockMult() you access them outside main loops. As result the > code without intrinsic should not be affected much. > > So, please, ignore my suggestion about "keep 'subkey' and 'state' > original values". You are right for intrinsic it is better to use arrays. > > Anyway, all is fine except you may need to check that size of arrays is > at least 2 before calling processBlocks(). > > thanks, > Vladimir > > On 2/17/15 2:03 PM, Anthony Scarpino wrote: >> On 02/17/2015 01:14 PM, Vladimir Kozlov wrote: >>> Florian's concern is valid. >>> >>> "Range check elimination" means that C2 moves checks from a loop. Checks >>> are still present. Since 'state' array is not final we can't eliminate >>> range check. >> >> I don't understand the concern here. The arrays are private and are >> only used by math calculations either in the same GHASH object or by the >> intrinsics. What ranges check issues are we expecting to occur given >> they are inaccessible by an API? >> >>> An other thing is an additional indirect load to access >>> arrays elements. >>> >>> I would suggest to keep original code for 'subkey' and 'state' which use >>> separate values instead of arrays. >> >> By the indirect loading, you referring to the loading done by >> get_vars_from_ghash_object() in library_call.cpp? If so, I thought it >> would be faster to load the 128bit values directly into one register >> instead of loading one long from the class to a register, shift left, >> loading the second long and xor'ing into the register. The assembly >> code is doing the math on the whole 128bit value, while the GHASH.java >> side needs to split it into 2 values. Putting it into an array makes in >> easy, coding wise, to access the whole 128bit value at once. >> >> If the suggestion also is to put the 4 longs on the argument list, that >> would be 7 arguments for processBlocks, which would be ugly and not >> useful for the non-intrinsic side since GHASH.java would ignore the >> longs. >> >> > >>> Regards, >>> Vladimir >>> >>> >>> On 2/17/15 1:00 PM, Anthony Scarpino wrote: >>>> On 02/17/2015 12:05 PM, Florian Weimer wrote: >>>>> On 02/17/2015 08:59 PM, Anthony Scarpino wrote: >>>>>> On 02/17/2015 12:57 AM, Florian Weimer wrote: >>>>>>> On 02/16/2015 10:11 PM, Anthony Scarpino wrote: >>>>>>>> http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev/ >>>>>>> >>>>>>> I think the ?state? field in GHASH should be final. Is C2 able to >>>>>>> eliminate the array bounds checks? (Although it's not in the inner >>>>>>> loop >>>>>>> and thus probably not relevant for performance.) >>>>>> >>>>>> I'm not sure want you asking about in regard to the bounds checking? >>>>>> Are >>>>>> you asking about checking the bounds of "state"? >>>>> >>>>> state[0] and state[1]?I wonder if those expressions need array bounds >>>>> checks when compiled. >>>> >>>> The glossary says C2 eliminates array range checking. >>>> http://openjdk.java.net/groups/hotspot/docs/HotSpotGlossary.html >>>> >>>> Tony >>>> >> From anthony.scarpino at oracle.com Tue Feb 17 23:59:47 2015 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Tue, 17 Feb 2015 15:59:47 -0800 Subject: RFR: 8073108: GHASH Intrinsics In-Reply-To: <54E3D42B.2010202@redhat.com> References: <54E25D03.7090705@oracle.com> <54E3028A.7040102@redhat.com> <54E39D8C.8050705@oracle.com> <54E39EFA.8060904@redhat.com> <54E3ABF9.3030706@oracle.com> <54E3AF49.6060102@oracle.com> <54E3BAB5.8090506@oracle.com> <54E3C0F0.5090203@oracle.com> <54E3D42B.2010202@redhat.com> Message-ID: <54E3D5F3.60201@oracle.com> On 02/17/2015 03:52 PM, Florian Weimer wrote: > On 02/17/2015 11:30 PM, Vladimir Kozlov wrote: >> The concern was about java code and not intrinsic. If intrinsic is not >> used we will get additional range checks which were not present before. >> >> By indirect load I mean object->array_oop->element instead of >> object->field. >> >> But in blockMult() you access them outside main loops. As result the >> code without intrinsic should not be affected much. > > Making the state field final is still a good idea, I think. > Sure.. I think it's reasonable to add that too.. thanks Tony From stefan.karlsson at oracle.com Wed Feb 18 08:10:02 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 18 Feb 2015 09:10:02 +0100 Subject: RFR: 8073387: Move VerifyOopClosures out from genOopClosures.hpp Message-ID: <54E448DA.4060406@oracle.com> Hi, Please review this patch to move VerifyOopClosures out from genOopClosures.hpp. This way users of VerifyOopClosures don't have to include genOopClosures.hpp anymore. The implementation of VerifyOopClosures::do_oop_work is placed in oop.cpp, where the other VerifyOopClosure functions are located. http://cr.openjdk.java.net/~stefank/8073387/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8073387 Thanks, StefanK From mikael.gerdin at oracle.com Wed Feb 18 08:25:55 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 18 Feb 2015 09:25:55 +0100 Subject: RFR: 8073387: Move VerifyOopClosures out from genOopClosures.hpp In-Reply-To: <54E448DA.4060406@oracle.com> References: <54E448DA.4060406@oracle.com> Message-ID: <54E44C93.8040402@oracle.com> Hi Stefan, On 2015-02-18 09:10, Stefan Karlsson wrote: > Hi, > > Please review this patch to move VerifyOopClosures out from > genOopClosures.hpp. This way users of VerifyOopClosures don't have to > include genOopClosures.hpp anymore. The implementation of > VerifyOopClosures::do_oop_work is placed in oop.cpp, where the other > VerifyOopClosure functions are located. > > http://cr.openjdk.java.net/~stefank/8073387/webrev.01/ Looks good to me. /Mikael > https://bugs.openjdk.java.net/browse/JDK-8073387 > > Thanks, > StefanK From bengt.rutisson at oracle.com Wed Feb 18 08:24:36 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 18 Feb 2015 09:24:36 +0100 Subject: RFR: 8073387: Move VerifyOopClosures out from genOopClosures.hpp In-Reply-To: <54E448DA.4060406@oracle.com> References: <54E448DA.4060406@oracle.com> Message-ID: <54E44C44.3020108@oracle.com> Hi Stefan, On 2015-02-18 09:10, Stefan Karlsson wrote: > Hi, > > Please review this patch to move VerifyOopClosures out from > genOopClosures.hpp. This way users of VerifyOopClosures don't have to > include genOopClosures.hpp anymore. The implementation of > VerifyOopClosures::do_oop_work is placed in oop.cpp, where the other > VerifyOopClosure functions are located. > > http://cr.openjdk.java.net/~stefank/8073387/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8073387 Looks good. Thanks, Bengt > > Thanks, > StefanK From stefan.karlsson at oracle.com Wed Feb 18 09:16:50 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 18 Feb 2015 10:16:50 +0100 Subject: RFR: 8073388: Get rid of the dependency from handles.hpp to klass.hpp Message-ID: <54E45882.5030609@oracle.com> Hi, Please review this patch to get rid of dependencies from handles.hpp to klass.hpp. This patch is extracted from a bigger patch to clean up some of our GC code dependencies in oop_iterate. http://cr.openjdk.java.net/~stefank/8073388/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8073388 Thanks, StefanK From staffan.larsen at oracle.com Wed Feb 18 09:34:53 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Wed, 18 Feb 2015 10:34:53 +0100 Subject: RFR (S): 8072687: Update OutputAnalyzer to work with files In-Reply-To: <54E38EEC.9020001@oracle.com> References: <54E36511.7010608@oracle.com> <65BF10CE-582D-448E-B5DA-5544276C0E16@oracle.com> <54E38EEC.9020001@oracle.com> Message-ID: I can only see one usage of the OutputAnalyzer(String) constructor and that is in test/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java. That usage does not require both stdout and stderr to be set. In fact, that usage would benefit from the new constructor that takes a File. I suggest we do: - Change OutputAnalyzer(String) to set stdout to the input string and stderr to the empty string "" - Update CompressedClassSpaceSizeInJmapHeap.java to use the new OutputAnalyzer(File) constructor Thanks, /Staffan > On 17 feb 2015, at 19:56, Dmitry Fazunenko wrote: > > Hi Staffan, > > For me it's not clear why the constructor taking a String argument sets both stderr and stdout to the same value... > But I don't see any reason to update this behavior and break compatibility. > So I would agree, that the new constructor should be consistent with the existing one and set both out and err to the same string. > > Thanks, > Dima > > > > On 17.02.2015 20:39, Staffan Larsen wrote: >> There is constructor that takes a String argument. That constructor sets both stderr and stdout to that same String. Your constructor behaves differently and only sets stdout to the contents of the file. I have no idea why the existing constructor does what it does, but it would be good if the new and old had the same behavior. I haven?t looked at the use cases for the existing constructor. >> >> /S >> >>> On 17 feb 2015, at 16:58, denis kononenko wrote: >>> >>> Hi All, >>> >>> Could you please review a small change of OutputAnalyzer class from testlibrary. >>> >>> Webrev link: http://cr.openjdk.java.net/~dfazunen/dkononen/8072687/webrev.00/ >>> Bug id: https://bugs.openjdk.java.net/browse/JDK-8072687 >>> Testing: automated >>> Description: >>> >>> The purpose of this change is to extend the functionality of OutputAnalyzer by adding ability to read output from a file. Sometimes we have to analyze output written to a file (test data, logs, etc.). In that case we have to read it as a string and pass it into OutputAnalyzer's constructor (it could be done in several different ways). It would be very convenient to put this code directly into OutputAnalyzer. This would allow to make further tests code more cleaner and less error prone. >>> >>> The change consist of two parts: >>> 1) The change: OutputAnalyzer.java, added a new constructor that accepts File; >>> 2) The tests: FileOutputAnalyzerTests.java, very basic tests on reading functionality. >>> >>> Thank you, >>> Denis. >>> >>> > From stefan.karlsson at oracle.com Wed Feb 18 09:35:46 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 18 Feb 2015 10:35:46 +0100 Subject: RFR: 8073389: Remove the include of resourceArea.hpp from classFileParser.hpp Message-ID: <54E45CF2.90208@oracle.com> Hi, Please review this patch to get rid of the inclusion of resourceArea.hpp from classFileParser.hpp. From the RFE: The inclusion of resourceArea.hpp in classFileParser.hpp is causing cyclic dependencies when I'm changing unrelated code. The main reason for this is that a lot of implementation is put inside the resourceArea.hpp file instead of a .cpp file. I've opted to go the easy route now and get rid of the the resourceArea.hpp dependency from classFileParser.hpp, but eventually it would be good to fix that file. This patch has to add explicit includes of resourceArea.hpp to other .hpp files, that used to get their include from classFileParser.hpp. I could have gotten rid of those dependencies as well, but I chose to not do that for this patch. http://cr.openjdk.java.net/~stefank/8073389/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8073389 Thanks, StefanK From stefan.johansson at oracle.com Wed Feb 18 09:46:09 2015 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Wed, 18 Feb 2015 10:46:09 +0100 Subject: RFR: 8062672: JVM crashes during GC on various asserts which checks that HeapWord ptr is an oop Message-ID: <54E45F61.2020806@oracle.com> Hi, The fix for 8062672 [1] has been pushed to 7u80 and 8u60 but the patch get a small conflict when applied to 9. A bugfix only present in 9 changed one of the patched lines, but the conflict is easy to solve. A diff between the original patch (present in 7 and 8) and the resolved one shows only this diff: > --- a/src/os_cpu/linux_sparc/vm/vm_version_linux_sparc.cpp > +++ b/src/os_cpu/linux_sparc/vm/vm_version_linux_sparc.cpp 30c30 < - if (fscanf(fp, "cpu\t\t: %100[^\n]", &cpu) == 1) { --- > - if (fscanf(fp, "cpu\t\t: %100[^\n]", cpu) == 1) { The full webrev is available at: http://cr.openjdk.java.net/~sjohanss/8062672/9/hotspot.00/ The original review thread can be seen here: http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-December/016324.html Thanks, Stefan [1] https://bugs.openjdk.java.net/browse/JDK-8062672 From stefan.karlsson at oracle.com Wed Feb 18 09:46:32 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 18 Feb 2015 10:46:32 +0100 Subject: RFR: 8073389: Remove the include of resourceArea.hpp from classFileParser.hpp In-Reply-To: <54E45CF2.90208@oracle.com> References: <54E45CF2.90208@oracle.com> Message-ID: <54E45F78.2020201@oracle.com> I've verified that assert_property still works by artificially inducing errors into the class file parser: # fatal error: Invalid field attribute index 5 in class file sun/security/x509/GeneralNameInterface # fatal error: Invalid ConstantValue field attribute length 2 in class file com/sun/org/apache/xerces/internal/parsers/XML11Configuration StefanK On 2015-02-18 10:35, Stefan Karlsson wrote: > Hi, > > Please review this patch to get rid of the inclusion of > resourceArea.hpp from classFileParser.hpp. > > From the RFE: > > The inclusion of resourceArea.hpp in classFileParser.hpp is causing > cyclic dependencies when I'm changing unrelated code. The main reason > for this is that a lot of implementation is put inside the > resourceArea.hpp file instead of a .cpp file. > > I've opted to go the easy route now and get rid of the the > resourceArea.hpp dependency from classFileParser.hpp, but eventually > it would be good to fix that file. > > This patch has to add explicit includes of resourceArea.hpp to other > .hpp files, that used to get their include from classFileParser.hpp. I > could have gotten rid of those dependencies as well, but I chose to > not do that for this patch. > > http://cr.openjdk.java.net/~stefank/8073389/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8073389 > > Thanks, > StefanK From dmitry.fazunenko at oracle.com Wed Feb 18 09:56:12 2015 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Wed, 18 Feb 2015 12:56:12 +0300 Subject: RFR (S): 8072687: Update OutputAnalyzer to work with files In-Reply-To: References: <54E36511.7010608@oracle.com> <65BF10CE-582D-448E-B5DA-5544276C0E16@oracle.com> <54E38EEC.9020001@oracle.com> Message-ID: <54E461BC.30104@oracle.com> On 18.02.2015 12:34, Staffan Larsen wrote: > I can only see one usage of the OutputAnalyzer(String) constructor and that is in test/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java. That usage does not require both stdout and stderr to be set. > > In fact, that usage would benefit from the new constructor that takes a File. > > I suggest we do: > > - Change OutputAnalyzer(String) to set stdout to the input string and stderr to the empty string "" > - Update CompressedClassSpaceSizeInJmapHeap.java to use the new OutputAnalyzer(File) constructor sounds good to me. -- Dima > > Thanks, > /Staffan > > >> On 17 feb 2015, at 19:56, Dmitry Fazunenko wrote: >> >> Hi Staffan, >> >> For me it's not clear why the constructor taking a String argument sets both stderr and stdout to the same value... >> But I don't see any reason to update this behavior and break compatibility. >> So I would agree, that the new constructor should be consistent with the existing one and set both out and err to the same string. >> >> Thanks, >> Dima >> >> >> >> On 17.02.2015 20:39, Staffan Larsen wrote: >>> There is constructor that takes a String argument. That constructor sets both stderr and stdout to that same String. Your constructor behaves differently and only sets stdout to the contents of the file. I have no idea why the existing constructor does what it does, but it would be good if the new and old had the same behavior. I haven?t looked at the use cases for the existing constructor. >>> >>> /S >>> >>>> On 17 feb 2015, at 16:58, denis kononenko wrote: >>>> >>>> Hi All, >>>> >>>> Could you please review a small change of OutputAnalyzer class from testlibrary. >>>> >>>> Webrev link: http://cr.openjdk.java.net/~dfazunen/dkononen/8072687/webrev.00/ >>>> Bug id: https://bugs.openjdk.java.net/browse/JDK-8072687 >>>> Testing: automated >>>> Description: >>>> >>>> The purpose of this change is to extend the functionality of OutputAnalyzer by adding ability to read output from a file. Sometimes we have to analyze output written to a file (test data, logs, etc.). In that case we have to read it as a string and pass it into OutputAnalyzer's constructor (it could be done in several different ways). It would be very convenient to put this code directly into OutputAnalyzer. This would allow to make further tests code more cleaner and less error prone. >>>> >>>> The change consist of two parts: >>>> 1) The change: OutputAnalyzer.java, added a new constructor that accepts File; >>>> 2) The tests: FileOutputAnalyzerTests.java, very basic tests on reading functionality. >>>> >>>> Thank you, >>>> Denis. >>>> >>>> From adinn at redhat.com Wed Feb 18 10:01:05 2015 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 18 Feb 2015 10:01:05 +0000 Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses In-Reply-To: References: <20150213230416.5E7B617FDAA@rebar.astron.com> <54DE8BB7.5050801@oracle.com> <54DE9140.3040604@oracle.com> <54E30C38.8000303@redhat.com> <54E31144.3040504@redhat.com> <54E314BF.3010205@redhat.com> <54E31677.1050209@redhat.com> <54E31CA6.6030609@redhat.com> <54E31DA0.2040901@redhat.com> <54E34EAF.6000802@redhat.com> <0457F01A-9DE1-4049-BFA2-66C7F6CCAA0B@oracle.com> <54E38F4B.7060100@redhat.com> <54E39364.6030409@oracle.com> Message-ID: <54E462E1.5080009@redhat.com> On 17/02/15 19:21, Vitaly Davidovich wrote: > IMO I don't think such barriers should be removed just because EA is able > to elide the heap allocation. Why not? Are you assuming that the programmer might be relying on a memory barrier being implied in interpreted/JITted code by the presence in the source of an allocation? If so then I am not sure the Java memory model justifies that assumption, especially so in the case EA optimises. As I recall, the arguments here and on the concurrency lists for the presence of a memory barrier at the end of allocation were only /for/ it as a heuristic to ensure that objects which might be shared would not be shared before all effects of construction were visible (I may be misstating that -- you might like to reread it as "the arguments on the concurrency lists I was convinced by" :-). In which case, if an object cannot be shared, indeed need not even be allocated, then there appears to be no need for such a heuristic. n.b. if a Java programmer really wants to enforce memory ordering wrt other threads then Java provides a very simple mechanism for that in volatile. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters (USA), Michael O'Neill (Ireland) From aph at redhat.com Wed Feb 18 10:10:55 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 18 Feb 2015 10:10:55 +0000 Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses In-Reply-To: <54E462E1.5080009@redhat.com> References: <20150213230416.5E7B617FDAA@rebar.astron.com> <54DE8BB7.5050801@oracle.com> <54DE9140.3040604@oracle.com> <54E30C38.8000303@redhat.com> <54E31144.3040504@redhat.com> <54E314BF.3010205@redhat.com> <54E31677.1050209@redhat.com> <54E31CA6.6030609@redhat.com> <54E31DA0.2040901@redhat.com> <54E34EAF.6000802@redhat.com> <0457F01A-9DE1-4049-BFA2-66C7F6CCAA0B@oracle.com> <54E38F4B.7060100@redhat.com> <54E39364.6030409@oracle.com> <54E462E1.5080009@redhat.com> Message-ID: <54E4652F.80600@redhat.com> On 02/18/2015 10:01 AM, Andrew Dinn wrote: > On 17/02/15 19:21, Vitaly Davidovich wrote: >> IMO I don't think such barriers should be removed just because EA is able >> to elide the heap allocation. > > Why not? Are you assuming that the programmer might be relying on a > memory barrier being implied in interpreted/JITted code by the presence > in the source of an allocation? If so then I am not sure the Java memory > model justifies that assumption, especially so in the case EA optimises. It doesn't. There are essentially two ways to prevent unsafe publication of objects with final fields: either emit a barrier at the end of the constructor or track the reference to the newly-constructed object until it is stored in memory. That store to memory can be a releasing store. If the object does not escape that releasing store can be eliminated. Andrew. From goetz.lindenmaier at sap.com Wed Feb 18 10:52:30 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 18 Feb 2015 10:52:30 +0000 Subject: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. In-Reply-To: <54E3B91B.8010408@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CF9615F@DEWDFEMB12A.global.corp.sap> <54E3B91B.8010408@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CF96457@DEWDFEMB12A.global.corp.sap> Hi Jesper, thanks for looking at this! You are right, at those places I should check for underflow. Also removed the line feed. See new webrev: http://cr.openjdk.java.net/~goetz/webrevs/8073315-wUnsign/webrev.02/ Best regards Goetz -----Original Message----- From: Jesper Wilhelmsson [mailto:jesper.wilhelmsson at oracle.com] Sent: Dienstag, 17. Februar 2015 22:57 To: Lindenmaier, Goetz; hotspot-dev Source Developers Subject: Re: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. Hi Goetz, Thanks for doing this work! Overall I think it looks great! I only have a few minor comments. * In a many places you have removed the >=0 check with no further action. In most places this is clearly the right thing to do, but there are a few places where I'm thinking that the check may express a concern from the author of the code that some expression might overflow/underflow and the check is needed. Since the check is pointless as such the function of the code is unchanged when removing this check, but the author's gut feeling that something might go wrong is lost. I might be paranoid but I would prefer if we add asserts in these places to make sure the expressions are checked properly. The places where I think this could be motivated are in os_linux.cpp and parCardTableModRefBS.cpp * In heapRegionSet.cpp I would prefer if the condition was on one line now when the second part is so short. Thanks, /Jesper Lindenmaier, Goetz skrev den 17/2/15 12:42: > Hi, > > We fixed all the warnings showing with -Wtype-limits and gcc in our VM. > I would like to contribute these small changes. > > This warning detects unnecessary compares for >= 0 of unsigned values. > > At least one warning unveils a real bug. In memory/blockOffsetTable.cpp, > BlockOffsetArrayContigSpace::last_active_index(), the compare to >=0 > tries to prevent an underflow, but the value is unsigned. > > Further useless compares in real code are in os_linux.cpp, > opto/graphKit.cpp, prims/jvmtiRedefineClasses.cpp > > In some places debug code with constant debug flags caused > warnings in the opt build (g1/concurrentMark.cpp, classfile/systemDictionary.cpp) > > The remaining warnings occur in asserts, which is also the biggest part. > > The change also removes an empty #ifdef ASSERT . > > Please review this change. I please need a sponsor. > https://bugs.openjdk.java.net/browse/JDK-8073315 > http://cr.openjdk.java.net/~goetz/webrevs/8073315-wUnsign/webrev.01/ > > I tested this on linuxx86_64 with gcc 4.1.2, 4.3 and 4.8. Further I ran the patch > with our nightly builds and tests of jdk9,see > http://cr.openjdk.java.net/~simonis/ppc-aix-port/index.html > > Best regards, > Goetz. > From goetz.lindenmaier at sap.com Wed Feb 18 10:53:24 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 18 Feb 2015 10:53:24 +0000 Subject: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. In-Reply-To: <70B02DBE-E246-45F9-89C7-898881B0C69A@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CF9615F@DEWDFEMB12A.global.corp.sap> <70B02DBE-E246-45F9-89C7-898881B0C69A@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CF96468@DEWDFEMB12A.global.corp.sap> Hi Kim, thanks for looking at this! > As Jesper noted, there are cases where, yes, the > warning is correct today, but future maintenance might change that. You mean, somebody could change the type to signed, and then again the assertion makes sense? I thought about that. One could add some function is_unsigned(uint64_t x) { return true; } is_unsigned(int64_t x) { return false; } in the assertions. It might even be possible to get a warning if the second is left out, so that it's a compile time error (-Werror). But it seemed a bit overengineered to me, as there's sure lots of cases where changing signedness would causes similar problems with current code, but there is no assertion to catch it. > This warning can also lead to serious ugliness with generic code > (e.g. templates), where only some values of a type parameter trigger > warnings. There is currently no such code in the VM. We could again remove the flag if such a case comes up. Until then, the warning will avoid future errors. And maybe, until then, openJDK uses a compiler with that issue fixed. Should I add a respective comment in the makefile? I fixed last_active_index() as you proposed. Yes, that's better. http://cr.openjdk.java.net/~goetz/webrevs/8073315-wUnsign/webrev.02/ Best regards, Goetz. -----Original Message----- From: Kim Barrett [mailto:kim.barrett at oracle.com] Sent: Mittwoch, 18. Februar 2015 00:28 To: Lindenmaier, Goetz Cc: hotspot-dev Source Developers Subject: Re: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. On Feb 17, 2015, at 6:42 AM, Lindenmaier, Goetz wrote: > > We fixed all the warnings showing with -Wtype-limits and gcc in our VM. > I would like to contribute these small changes. > > This warning detects unnecessary compares for >= 0 of unsigned values. > > At least one warning unveils a real bug. In memory/blockOffsetTable.cpp, > BlockOffsetArrayContigSpace::last_active_index(), the compare to >=0 > tries to prevent an underflow, but the value is unsigned. > > Further useless compares in real code are in os_linux.cpp, > opto/graphKit.cpp, prims/jvmtiRedefineClasses.cpp > > In some places debug code with constant debug flags caused > warnings in the opt build (g1/concurrentMark.cpp, classfile/systemDictionary.cpp) > > The remaining warnings occur in asserts, which is also the biggest part. > > The change also removes an empty #ifdef ASSERT . > > Please review this change. I please need a sponsor. > https://bugs.openjdk.java.net/browse/JDK-8073315 > http://cr.openjdk.java.net/~goetz/webrevs/8073315-wUnsign/webrev.01/ > > I tested this on linuxx86_64 with gcc 4.1.2, 4.3 and 4.8. Further I ran the patch > with our nightly builds and tests of jdk9,see > http://cr.openjdk.java.net/~simonis/ppc-aix-port/index.html -Wtype-limits is one of those somewhat questionable warnings that are enabled by -Wextra. As Jesper noted, there are cases where, yes, the warning is correct today, but future maintenance might change that. And the information that one needs in order to make that determination might be far away from the expression generating the warning. This warning can also lead to serious ugliness with generic code (e.g. templates), where only some values of a type parameter trigger warnings. I've seen real code that used template metapogramming to select different expressions in order to dodge this specific warning. In other words, while this warning does sometimes find real bugs, it also tends to generate a lot of false positives. Because of that, I'm not sure it's actually a good idea to enable it. For the specific bug mentioned, I would like to just see that fixed, but not in the way that was done in the webrev, e.g. incorrect old: 794 size_t BlockOffsetArrayContigSpace::last_active_index() const { 795 size_t result = _next_offset_index - 1; 796 return result >= 0 ? result : 0; 797 }mem webrev: 794 size_t BlockOffsetArrayContigSpace::last_active_index() const { 795 size_t result = _next_offset_index - 1; 796 return ((intptr_t)result) >= 0 ? result : 0; 797 } better: size_t BlockOffsetArrayContigSpace::last_active_index() const { size_t next = _next_offset_index; return next == 0 ? 0 : next - 1; } Eschew unnecessary casts! From denis.kononenko at oracle.com Wed Feb 18 11:09:47 2015 From: denis.kononenko at oracle.com (denis kononenko) Date: Wed, 18 Feb 2015 14:09:47 +0300 Subject: RFR (S): 8072687: Update OutputAnalyzer to work with files In-Reply-To: <54E461BC.30104@oracle.com> References: <54E36511.7010608@oracle.com> <65BF10CE-582D-448E-B5DA-5544276C0E16@oracle.com> <54E38EEC.9020001@oracle.com> <54E461BC.30104@oracle.com> Message-ID: <54E472FB.6050507@oracle.com> Hi Dima, Staffan, Thank you for taking time to have look at the change. On 18.02.2015 12:56, Dmitry Fazunenko wrote: > > On 18.02.2015 12:34, Staffan Larsen wrote: >> I can only see one usage of the OutputAnalyzer(String) constructor >> and that is in >> test/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java. That usage >> does not require both stdout and stderr to be set. >> >> In fact, that usage would benefit from the new constructor that takes >> a File. >> >> I suggest we do: >> >> - Change OutputAnalyzer(String) to set stdout to the input string and >> stderr to the empty string "" >> - Update CompressedClassSpaceSizeInJmapHeap.java to use the new >> OutputAnalyzer(File) constructor > > sounds good to me. I like this solution. I'll prepare all necessary changes soon. Thank you, Denis. > > -- Dima > >> >> Thanks, >> /Staffan >> >> >>> On 17 feb 2015, at 19:56, Dmitry Fazunenko >>> wrote: >>> >>> Hi Staffan, >>> >>> For me it's not clear why the constructor taking a String argument >>> sets both stderr and stdout to the same value... >>> But I don't see any reason to update this behavior and break >>> compatibility. >>> So I would agree, that the new constructor should be consistent with >>> the existing one and set both out and err to the same string. >>> >>> Thanks, >>> Dima >>> >>> >>> >>> On 17.02.2015 20:39, Staffan Larsen wrote: >>>> There is constructor that takes a String argument. That constructor >>>> sets both stderr and stdout to that same String. Your constructor >>>> behaves differently and only sets stdout to the contents of the >>>> file. I have no idea why the existing constructor does what it >>>> does, but it would be good if the new and old had the same >>>> behavior. I haven?t looked at the use cases for the existing >>>> constructor. >>>> >>>> /S >>>> >>>>> On 17 feb 2015, at 16:58, denis kononenko >>>>> wrote: >>>>> >>>>> Hi All, >>>>> >>>>> Could you please review a small change of OutputAnalyzer class >>>>> from testlibrary. >>>>> >>>>> Webrev link: >>>>> http://cr.openjdk.java.net/~dfazunen/dkononen/8072687/webrev.00/ >>>>> Bug id: https://bugs.openjdk.java.net/browse/JDK-8072687 >>>>> Testing: automated >>>>> Description: >>>>> >>>>> The purpose of this change is to extend the functionality of >>>>> OutputAnalyzer by adding ability to read output from a file. >>>>> Sometimes we have to analyze output written to a file (test data, >>>>> logs, etc.). In that case we have to read it as a string and pass >>>>> it into OutputAnalyzer's constructor (it could be done in several >>>>> different ways). It would be very convenient to put this code >>>>> directly into OutputAnalyzer. This would allow to make further >>>>> tests code more cleaner and less error prone. >>>>> >>>>> The change consist of two parts: >>>>> 1) The change: OutputAnalyzer.java, added a new constructor that >>>>> accepts File; >>>>> 2) The tests: FileOutputAnalyzerTests.java, very basic tests on >>>>> reading functionality. >>>>> >>>>> Thank you, >>>>> Denis. >>>>> >>>>> > From aph at redhat.com Wed Feb 18 11:13:21 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 18 Feb 2015 11:13:21 +0000 Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses In-Reply-To: <54E45842.9030102@redhat.com> References: <20150213230416.5E7B617FDAA@rebar.astron.com> <54DE8BB7.5050801@oracle.com> <54DE9140.3040604@oracle.com> <54E30C38.8000303@redhat.com> <54E31144.3040504@redhat.com> <54E314BF.3010205@redhat.com> <54E31677.1050209@redhat.com> <54E31CA6.6030609@redhat.com> <54E31DA0.2040901@redhat.com> <54E34EAF.6000802@redhat.com> <54E457E0.20408@redhat.com> <54E45842.9030102@redhat.com> Message-ID: <54E473D1.8000506@redhat.com> On 02/18/2015 09:15 AM, Andrew Haley wrote: > On 18/02/15 09:14, Florian Weimer wrote: >> Wow, looks nice. What OpenJDK build did you use? I want to see if this >> happens on x86_64, too. > > I'm working on JDK9. You don't have this code yet. I'll do an x86 > build. 0x00007f2948acbf8c: mov 0xc(%rdx),%r10d ;*synchronization entry ; - java.nio.HeapByteBuffer::@-1 (line 84) ; - java.nio.ByteBuffer::wrap at 7 (line 373) ; - java.nio.ByteBuffer::wrap at 4 (line 396) ; - bytebuffertests.ByteBufferTests3::getLong at 1 (line 23) ; implicit exception: dispatches to 0x00007f2948acbff5 ;; B2: # B5 B3 <- B1 Freq: 0.999999 ;; MEMBAR-release ! (empty encoding) 0x00007f2948acbf90: test %ecx,%ecx 0x00007f2948acbf92: jl 0x00007f2948acbfb5 ;*iflt ; - java.nio.Buffer::checkIndex at 1 (line 545) ; - java.nio.HeapByteBuffer::getLong at 18 (line 465) ; - bytebuffertests.ByteBufferTests3::getLong at 5 (line 23) ;; B3: # B6 B4 <- B2 Freq: 0.999999 0x00007f2948acbf94: mov %r10d,%ebp 0x00007f2948acbf97: sub %ecx,%ebp ;*isub ; - java.nio.Buffer::checkIndex at 10 (line 545) ; - java.nio.HeapByteBuffer::getLong at 18 (line 465) ; - bytebuffertests.ByteBufferTests3::getLong at 5 (line 23) 0x00007f2948acbf99: cmp $0x8,%ebp 0x00007f2948acbf9c: jl 0x00007f2948acbfd5 ;*if_icmple ; - java.nio.Buffer::checkIndex at 11 (line 545) ; - java.nio.HeapByteBuffer::getLong at 18 (line 465) ; - bytebuffertests.ByteBufferTests3::getLong at 5 (line 23) ;; B4: # N95 <- B3 Freq: 0.999998 0x00007f2948acbf9e: movslq %ecx,%r10 0x00007f2948acbfa1: mov 0x10(%rdx,%r10,1),%rax 0x00007f2948acbfa6: bswap %rax ;*invokestatic reverseBytes ; - java.nio.Bits::swap at 1 (line 61) ; - java.nio.HeapByteBuffer::getLong at 41 (line 466) ; - bytebuffertests.ByteBufferTests3::getLong at 5 (line 23) So, just the same except that there is no explicit fence instruction to remove. It's a shame for AArch64 because that fence really kills performance but it's bad for x86 too. Even on machines that don't emit fence instructions the fence still acts as a compiler barrier. Andrew. From david.holmes at oracle.com Wed Feb 18 11:36:17 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 18 Feb 2015 21:36:17 +1000 Subject: RFR: 8073389: Remove the include of resourceArea.hpp from classFileParser.hpp In-Reply-To: <54E45CF2.90208@oracle.com> References: <54E45CF2.90208@oracle.com> Message-ID: <54E47931.10101@oracle.com> On 18/02/2015 7:35 PM, Stefan Karlsson wrote: > Hi, > > Please review this patch to get rid of the inclusion of resourceArea.hpp > from classFileParser.hpp. > > From the RFE: > > The inclusion of resourceArea.hpp in classFileParser.hpp is causing > cyclic dependencies when I'm changing unrelated code. The main reason > for this is that a lot of implementation is put inside the > resourceArea.hpp file instead of a .cpp file. I must be missing something here - the implementation in the .hpp file is because all of the functions are implicitly inline. No guarantee they will be inlined of course but at least in product mode many of them should be. So assuming this is a good thing and we want to keep that for performance then the fix would be to introduce a .inline.hpp file, not to move stuff to a .cpp file. > I've opted to go the easy route now and get rid of the the > resourceArea.hpp dependency from classFileParser.hpp, but eventually it > would be good to fix that file. > > This patch has to add explicit includes of resourceArea.hpp to other > .hpp files, that used to get their include from classFileParser.hpp. I > could have gotten rid of those dependencies as well, but I chose to not > do that for this patch. > > http://cr.openjdk.java.net/~stefank/8073389/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8073389 What was classFileParser.hpp using from resourceArea.hpp ? How does the change to src/share/vm/services/runtimeService.cpp fit in ?? Seems okay - the proof is in the building as always. Need to check with and without precompiled headers. And copyright dates need updating. Cheers, David > Thanks, > StefanK From mikael.gerdin at oracle.com Wed Feb 18 12:12:54 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Wed, 18 Feb 2015 13:12:54 +0100 Subject: RFR: 8073388: Get rid of the dependency from handles.hpp to klass.hpp In-Reply-To: <54E45882.5030609@oracle.com> References: <54E45882.5030609@oracle.com> Message-ID: <54E481C6.9090408@oracle.com> Hi Stefan, On 2015-02-18 10:16, Stefan Karlsson wrote: > Hi, > > Please review this patch to get rid of dependencies from handles.hpp to > klass.hpp. This patch is extracted from a bigger patch to clean up some > of our GC code dependencies in oop_iterate. > > http://cr.openjdk.java.net/~stefank/8073388/webrev.01/ Looks good. /Mikael > https://bugs.openjdk.java.net/browse/JDK-8073388 > > Thanks, > StefanK From stefan.karlsson at oracle.com Wed Feb 18 12:17:35 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 18 Feb 2015 13:17:35 +0100 Subject: RFR: 8073389: Remove the include of resourceArea.hpp from classFileParser.hpp In-Reply-To: <54E47931.10101@oracle.com> References: <54E45CF2.90208@oracle.com> <54E47931.10101@oracle.com> Message-ID: <54E482DF.6010004@oracle.com> Hi David, On 2015-02-18 12:36, David Holmes wrote: > On 18/02/2015 7:35 PM, Stefan Karlsson wrote: >> Hi, >> >> Please review this patch to get rid of the inclusion of resourceArea.hpp >> from classFileParser.hpp. >> >> From the RFE: >> >> The inclusion of resourceArea.hpp in classFileParser.hpp is causing >> cyclic dependencies when I'm changing unrelated code. The main reason >> for this is that a lot of implementation is put inside the >> resourceArea.hpp file instead of a .cpp file. > > I must be missing something here - the implementation in the .hpp file > is because all of the functions are implicitly inline. No guarantee > they will be inlined of course but at least in product mode many of > them should be. So assuming this is a good thing and we want to keep > that for performance then the fix would be to introduce a .inline.hpp > file, not to move stuff to a .cpp file. Yes, you're right, if we assume that these functions are performance critical. Personally, I'm not so sure that they were put in the header file for performance reasons. But since I'm not changing resourceArea.hpp I don't have to figure it out at this point. > > >> I've opted to go the easy route now and get rid of the the >> resourceArea.hpp dependency from classFileParser.hpp, but eventually it >> would be good to fix that file. >> >> This patch has to add explicit includes of resourceArea.hpp to other >> .hpp files, that used to get their include from classFileParser.hpp. I >> could have gotten rid of those dependencies as well, but I chose to not >> do that for this patch. >> >> http://cr.openjdk.java.net/~stefank/8073389/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8073389 > > What was classFileParser.hpp using from resourceArea.hpp ? > > How does the change to src/share/vm/services/runtimeService.cpp fit in ?? There is an include path that was removed when I cleaned up classFileParser.hpp: runtimeServices.cpp classLoader.hpp classFileParser.hpp --- The following branch was pruned --- resourceArea.hpp thread.inline.hpp thread.hpp threadLocalAllocBuffer.hpp vm_version.hpp So, I added vm_version.hpp to runtimeService.cpp since it uses Abstract_VM_Version in vm_version.hpp. > > Seems okay - the proof is in the building as always. Need to check > with and without precompiled headers. It passes JPRT, which runs without PCH on Solaris. I've compiled with and without PCH on Linux x64. > And copyright dates need updating. Sure. Thanks, StefanK > > Cheers, > David > >> Thanks, >> StefanK From stefan.karlsson at oracle.com Wed Feb 18 12:17:51 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 18 Feb 2015 13:17:51 +0100 Subject: RFR: 8073388: Get rid of the dependency from handles.hpp to klass.hpp In-Reply-To: <54E481C6.9090408@oracle.com> References: <54E45882.5030609@oracle.com> <54E481C6.9090408@oracle.com> Message-ID: <54E482EF.5010709@oracle.com> On 2015-02-18 13:12, Mikael Gerdin wrote: > Hi Stefan, > > On 2015-02-18 10:16, Stefan Karlsson wrote: >> Hi, >> >> Please review this patch to get rid of dependencies from handles.hpp to >> klass.hpp. This patch is extracted from a bigger patch to clean up some >> of our GC code dependencies in oop_iterate. >> >> http://cr.openjdk.java.net/~stefank/8073388/webrev.01/ > > Looks good. Thanks, StefanK > > /Mikael > >> https://bugs.openjdk.java.net/browse/JDK-8073388 >> >> Thanks, >> StefanK From stefan.karlsson at oracle.com Wed Feb 18 12:19:35 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 18 Feb 2015 13:19:35 +0100 Subject: RFR: 8073387: Move VerifyOopClosures out from genOopClosures.hpp In-Reply-To: <54E44C44.3020108@oracle.com> References: <54E448DA.4060406@oracle.com> <54E44C44.3020108@oracle.com> Message-ID: <54E48357.9070700@oracle.com> On 2015-02-18 09:24, Bengt Rutisson wrote: > > Hi Stefan, > > On 2015-02-18 09:10, Stefan Karlsson wrote: >> Hi, >> >> Please review this patch to move VerifyOopClosures out from >> genOopClosures.hpp. This way users of VerifyOopClosures don't have to >> include genOopClosures.hpp anymore. The implementation of >> VerifyOopClosures::do_oop_work is placed in oop.cpp, where the other >> VerifyOopClosure functions are located. >> >> http://cr.openjdk.java.net/~stefank/8073387/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8073387 > > Looks good. Thanks, StefanK > > Thanks, > Bengt > >> >> Thanks, >> StefanK > From stefan.karlsson at oracle.com Wed Feb 18 12:19:47 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 18 Feb 2015 13:19:47 +0100 Subject: RFR: 8073387: Move VerifyOopClosures out from genOopClosures.hpp In-Reply-To: <54E44C93.8040402@oracle.com> References: <54E448DA.4060406@oracle.com> <54E44C93.8040402@oracle.com> Message-ID: <54E48363.1060106@oracle.com> On 2015-02-18 09:25, Mikael Gerdin wrote: > Hi Stefan, > > On 2015-02-18 09:10, Stefan Karlsson wrote: >> Hi, >> >> Please review this patch to move VerifyOopClosures out from >> genOopClosures.hpp. This way users of VerifyOopClosures don't have to >> include genOopClosures.hpp anymore. The implementation of >> VerifyOopClosures::do_oop_work is placed in oop.cpp, where the other >> VerifyOopClosure functions are located. >> >> http://cr.openjdk.java.net/~stefank/8073387/webrev.01/ > > Looks good to me. Thanks, StefanK > > /Mikael > >> https://bugs.openjdk.java.net/browse/JDK-8073387 >> >> Thanks, >> StefanK > From gnu.andrew at redhat.com Wed Feb 18 12:33:25 2015 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 18 Feb 2015 07:33:25 -0500 (EST) Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <54E3B144.1090402@oracle.com> References: <531E8309.2060206@oracle.com> <531ED06F.5040905@oracle.com> <107001365.11810418.1423839439509.JavaMail.zimbra@redhat.com> <54E183B8.5010301@oracle.com> <54E3B144.1090402@oracle.com> Message-ID: <958867570.14123662.1424262805099.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 16/02/2015 3:44 PM, David Holmes wrote: > > I have no issue with this minimal change for hotspot. > > > > I suppose I can also volunteer to sponsor it. :) > > > > Is the plan to also do the JDK changes under the same bug? That will > > need build-dev involvement. > > Still waiting to see if this will these hotspot-only changes or whether > there is more in the works. > [ccing build-dev] Yes, as I said here: http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-February/017175.html there are JDK changes but what I had to begin with was for 7 as that's where the bug was reported. While the HotSpot changes are pretty much the same on 7, 8 and 9, doing the JDK side has basically been a complete re-write, especially as, unlike 7, 8 has very little recognition of ppc64le. I now have these changes working on 8u31: http://cr.openjdk.java.net/~andrew/rh1191652/root http://cr.openjdk.java.net/~andrew/rh1191652/jdk I can re-base these onto whichever OpenJDK 9 tree is appropriate and push when reviewed under the same bug as used for the HotSpot side. > Thanks, > David > -- Andrew :) 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 PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From coleen.phillimore at oracle.com Wed Feb 18 13:17:03 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 18 Feb 2015 08:17:03 -0500 Subject: RFR: 8073387: Move VerifyOopClosures out from genOopClosures.hpp In-Reply-To: <54E44C93.8040402@oracle.com> References: <54E448DA.4060406@oracle.com> <54E44C93.8040402@oracle.com> Message-ID: <54E490CF.1030003@oracle.com> I have a request - can you name the file verifyOopClosure.hpp There's a different JVM option that we use that is -XX:+VerifyOops which is completely different than this. The name of the class in verifyOop.hpp is VerifyOopClosure also. Coleen On 2/18/15, 3:25 AM, Mikael Gerdin wrote: > Hi Stefan, > > On 2015-02-18 09:10, Stefan Karlsson wrote: >> Hi, >> >> Please review this patch to move VerifyOopClosures out from >> genOopClosures.hpp. This way users of VerifyOopClosures don't have to >> include genOopClosures.hpp anymore. The implementation of >> VerifyOopClosures::do_oop_work is placed in oop.cpp, where the other >> VerifyOopClosure functions are located. >> >> http://cr.openjdk.java.net/~stefank/8073387/webrev.01/ > > Looks good to me. > > /Mikael > >> https://bugs.openjdk.java.net/browse/JDK-8073387 >> >> Thanks, >> StefanK > From coleen.phillimore at oracle.com Wed Feb 18 13:18:35 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 18 Feb 2015 08:18:35 -0500 Subject: RFR: 8073388: Get rid of the dependency from handles.hpp to klass.hpp In-Reply-To: <54E45882.5030609@oracle.com> References: <54E45882.5030609@oracle.com> Message-ID: <54E4912B.4000201@oracle.com> Looks fine. Coleen On 2/18/15, 4:16 AM, Stefan Karlsson wrote: > Hi, > > Please review this patch to get rid of dependencies from handles.hpp > to klass.hpp. This patch is extracted from a bigger patch to clean up > some of our GC code dependencies in oop_iterate. > > http://cr.openjdk.java.net/~stefank/8073388/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8073388 > > Thanks, > StefanK From coleen.phillimore at oracle.com Wed Feb 18 13:20:51 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 18 Feb 2015 08:20:51 -0500 Subject: RFR: 8073389: Remove the include of resourceArea.hpp from classFileParser.hpp In-Reply-To: <54E45CF2.90208@oracle.com> References: <54E45CF2.90208@oracle.com> Message-ID: <54E491B3.9000708@oracle.com> Seems good. Coleen On 2/18/15, 4:35 AM, Stefan Karlsson wrote: > Hi, > > Please review this patch to get rid of the inclusion of > resourceArea.hpp from classFileParser.hpp. > > From the RFE: > > The inclusion of resourceArea.hpp in classFileParser.hpp is causing > cyclic dependencies when I'm changing unrelated code. The main reason > for this is that a lot of implementation is put inside the > resourceArea.hpp file instead of a .cpp file. > > I've opted to go the easy route now and get rid of the the > resourceArea.hpp dependency from classFileParser.hpp, but eventually > it would be good to fix that file. > > This patch has to add explicit includes of resourceArea.hpp to other > .hpp files, that used to get their include from classFileParser.hpp. I > could have gotten rid of those dependencies as well, but I chose to > not do that for this patch. > > http://cr.openjdk.java.net/~stefank/8073389/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8073389 > > Thanks, > StefanK From coleen.phillimore at oracle.com Wed Feb 18 13:25:31 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 18 Feb 2015 08:25:31 -0500 Subject: RFR: 8073389: Remove the include of resourceArea.hpp from classFileParser.hpp In-Reply-To: <54E482DF.6010004@oracle.com> References: <54E45CF2.90208@oracle.com> <54E47931.10101@oracle.com> <54E482DF.6010004@oracle.com> Message-ID: <54E492CB.70004@oracle.com> On 2/18/15, 7:17 AM, Stefan Karlsson wrote: > Hi David, > > On 2015-02-18 12:36, David Holmes wrote: >> On 18/02/2015 7:35 PM, Stefan Karlsson wrote: >>> Hi, >>> >>> Please review this patch to get rid of the inclusion of >>> resourceArea.hpp >>> from classFileParser.hpp. >>> >>> From the RFE: >>> >>> The inclusion of resourceArea.hpp in classFileParser.hpp is causing >>> cyclic dependencies when I'm changing unrelated code. The main reason >>> for this is that a lot of implementation is put inside the >>> resourceArea.hpp file instead of a .cpp file. >> >> I must be missing something here - the implementation in the .hpp >> file is because all of the functions are implicitly inline. No >> guarantee they will be inlined of course but at least in product mode >> many of them should be. So assuming this is a good thing and we want >> to keep that for performance then the fix would be to introduce a >> .inline.hpp file, not to move stuff to a .cpp file. I don't see how error reporting functions should be performance critical. I think they're better off in the .cpp file. > > Yes, you're right, if we assume that these functions are performance > critical. Personally, I'm not so sure that they were put in the header > file for performance reasons. But since I'm not changing > resourceArea.hpp I don't have to figure it out at this point. > >> >> >>> I've opted to go the easy route now and get rid of the the >>> resourceArea.hpp dependency from classFileParser.hpp, but eventually it >>> would be good to fix that file. >>> >>> This patch has to add explicit includes of resourceArea.hpp to other >>> .hpp files, that used to get their include from classFileParser.hpp. I >>> could have gotten rid of those dependencies as well, but I chose to not >>> do that for this patch. >>> >>> http://cr.openjdk.java.net/~stefank/8073389/webrev.01/ >>> https://bugs.openjdk.java.net/browse/JDK-8073389 >> >> What was classFileParser.hpp using from resourceArea.hpp ? >> >> How does the change to src/share/vm/services/runtimeService.cpp fit >> in ?? > > There is an include path that was removed when I cleaned up > classFileParser.hpp: > > runtimeServices.cpp > classLoader.hpp > classFileParser.hpp > --- The following branch was pruned --- > resourceArea.hpp > thread.inline.hpp > thread.hpp > threadLocalAllocBuffer.hpp > vm_version.hpp > > So, I added vm_version.hpp to runtimeService.cpp since it uses > Abstract_VM_Version in vm_version.hpp. > >> >> Seems okay - the proof is in the building as always. Need to check >> with and without precompiled headers. > > It passes JPRT, which runs without PCH on Solaris. I've compiled with > and without PCH on Linux x64. > >> And copyright dates need updating. > > Sure. Thanks for doing the copyrights. Coleen > > Thanks, > StefanK > >> >> Cheers, >> David >> >>> Thanks, >>> StefanK > From jesper.wilhelmsson at oracle.com Wed Feb 18 13:38:20 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 18 Feb 2015 14:38:20 +0100 Subject: RFR: 8062672: JVM crashes during GC on various asserts which checks that HeapWord ptr is an oop In-Reply-To: <54E45F61.2020806@oracle.com> References: <54E45F61.2020806@oracle.com> Message-ID: <54E495CC.9030200@oracle.com> Looks good! /Jesper Stefan Johansson skrev den 18/2/15 10:46: > Hi, > > The fix for 8062672 [1] has been pushed to 7u80 and 8u60 but the patch get a > small conflict when applied to 9. A bugfix only present in 9 changed one of the > patched lines, but the conflict is easy to solve. A diff between the original > patch (present in 7 and 8) and the resolved one shows only this diff: > > --- a/src/os_cpu/linux_sparc/vm/vm_version_linux_sparc.cpp > > +++ b/src/os_cpu/linux_sparc/vm/vm_version_linux_sparc.cpp > 30c30 > < - if (fscanf(fp, "cpu\t\t: %100[^\n]", &cpu) == 1) { > --- > > - if (fscanf(fp, "cpu\t\t: %100[^\n]", cpu) == 1) { > > The full webrev is available at: > http://cr.openjdk.java.net/~sjohanss/8062672/9/hotspot.00/ > > The original review thread can be seen here: > http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-December/016324.html > > Thanks, > Stefan > > [1] https://bugs.openjdk.java.net/browse/JDK-8062672 > > From vitalyd at gmail.com Wed Feb 18 14:16:59 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 18 Feb 2015 09:16:59 -0500 Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses In-Reply-To: <54E4652F.80600@redhat.com> References: <20150213230416.5E7B617FDAA@rebar.astron.com> <54DE8BB7.5050801@oracle.com> <54DE9140.3040604@oracle.com> <54E30C38.8000303@redhat.com> <54E31144.3040504@redhat.com> <54E314BF.3010205@redhat.com> <54E31677.1050209@redhat.com> <54E31CA6.6030609@redhat.com> <54E31DA0.2040901@redhat.com> <54E34EAF.6000802@redhat.com> <0457F01A-9DE1-4049-BFA2-66C7F6CCAA0B@oracle.com> <54E38F4B.7060100@redhat.com> <54E39364.6030409@oracle.com> <54E462E1.5080009@redhat.com> <54E4652F.80600@redhat.com> Message-ID: I don't think explicit barriers (i.e. Unsafe.xxxFence) should be removed as I don't think compiler can prove that it's safe to do so. When value types come to be and get scalarized, it may be possible to create cheap synchronization types that are stack allocated yet are used for synchronization control. For example, C# has a SpinLock struct ( https://msdn.microsoft.com/en-us/library/system.threading.spinlock%28v=vs.110%29.aspx ). Also, I don't think Unsafe induced fences are part of JMM, current or future (at least I haven't heard that to be the case). sent from my phone On Feb 18, 2015 5:11 AM, "Andrew Haley" wrote: > On 02/18/2015 10:01 AM, Andrew Dinn wrote: > > On 17/02/15 19:21, Vitaly Davidovich wrote: > >> IMO I don't think such barriers should be removed just because EA is > able > >> to elide the heap allocation. > > > > Why not? Are you assuming that the programmer might be relying on a > > memory barrier being implied in interpreted/JITted code by the presence > > in the source of an allocation? If so then I am not sure the Java memory > > model justifies that assumption, especially so in the case EA optimises. > > It doesn't. > > There are essentially two ways to prevent unsafe publication of > objects with final fields: either emit a barrier at the end of the > constructor or track the reference to the newly-constructed object > until it is stored in memory. That store to memory can be a releasing > store. If the object does not escape that releasing store can be > eliminated. > > Andrew. > From vitalyd at gmail.com Wed Feb 18 14:27:21 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 18 Feb 2015 09:27:21 -0500 Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses In-Reply-To: <54E473D1.8000506@redhat.com> References: <20150213230416.5E7B617FDAA@rebar.astron.com> <54DE8BB7.5050801@oracle.com> <54DE9140.3040604@oracle.com> <54E30C38.8000303@redhat.com> <54E31144.3040504@redhat.com> <54E314BF.3010205@redhat.com> <54E31677.1050209@redhat.com> <54E31CA6.6030609@redhat.com> <54E31DA0.2040901@redhat.com> <54E34EAF.6000802@redhat.com> <54E457E0.20408@redhat.com> <54E45842.9030102@redhat.com> <54E473D1.8000506@redhat.com> Message-ID: Indeed, that's quite nice and not what I saw in java 7 so good to see that this case is EA'd out. Does anyone know if there was EA work done in java 9 or is this simply inlining policy change that makes EA work (as John alluded to)? sent from my phone On Feb 18, 2015 6:13 AM, "Andrew Haley" wrote: > On 02/18/2015 09:15 AM, Andrew Haley wrote: > > On 18/02/15 09:14, Florian Weimer wrote: > >> Wow, looks nice. What OpenJDK build did you use? I want to see if this > >> happens on x86_64, too. > > > > I'm working on JDK9. You don't have this code yet. I'll do an x86 > > build. > > 0x00007f2948acbf8c: mov 0xc(%rdx),%r10d ;*synchronization entry > ; - > java.nio.HeapByteBuffer::@-1 (line 84) > ; - > java.nio.ByteBuffer::wrap at 7 (line 373) > ; - > java.nio.ByteBuffer::wrap at 4 (line 396) > ; - > bytebuffertests.ByteBufferTests3::getLong at 1 (line 23) > ; implicit exception: > dispatches to 0x00007f2948acbff5 > ;; B2: # B5 B3 <- B1 Freq: 0.999999 > > ;; MEMBAR-release ! (empty encoding) > > 0x00007f2948acbf90: test %ecx,%ecx > 0x00007f2948acbf92: jl 0x00007f2948acbfb5 ;*iflt > ; - > java.nio.Buffer::checkIndex at 1 (line 545) > ; - > java.nio.HeapByteBuffer::getLong at 18 (line 465) > ; - > bytebuffertests.ByteBufferTests3::getLong at 5 (line 23) > > ;; B3: # B6 B4 <- B2 Freq: 0.999999 > > 0x00007f2948acbf94: mov %r10d,%ebp > 0x00007f2948acbf97: sub %ecx,%ebp ;*isub > ; - > java.nio.Buffer::checkIndex at 10 (line 545) > ; - > java.nio.HeapByteBuffer::getLong at 18 (line 465) > ; - > bytebuffertests.ByteBufferTests3::getLong at 5 (line 23) > > 0x00007f2948acbf99: cmp $0x8,%ebp > 0x00007f2948acbf9c: jl 0x00007f2948acbfd5 ;*if_icmple > ; - > java.nio.Buffer::checkIndex at 11 (line 545) > ; - > java.nio.HeapByteBuffer::getLong at 18 (line 465) > ; - > bytebuffertests.ByteBufferTests3::getLong at 5 (line 23) > > ;; B4: # N95 <- B3 Freq: 0.999998 > > 0x00007f2948acbf9e: movslq %ecx,%r10 > 0x00007f2948acbfa1: mov 0x10(%rdx,%r10,1),%rax > 0x00007f2948acbfa6: bswap %rax ;*invokestatic reverseBytes > ; - java.nio.Bits::swap at 1 > (line 61) > ; - > java.nio.HeapByteBuffer::getLong at 41 (line 466) > ; - > bytebuffertests.ByteBufferTests3::getLong at 5 (line 23) > > So, just the same except that there is no explicit fence instruction > to remove. It's a shame for AArch64 because that fence really kills > performance but it's bad for x86 too. Even on machines that don't > emit fence instructions the fence still acts as a compiler barrier. > > Andrew. > From aph at redhat.com Wed Feb 18 15:26:00 2015 From: aph at redhat.com (Andrew Haley) Date: Wed, 18 Feb 2015 15:26:00 +0000 Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses In-Reply-To: References: <20150213230416.5E7B617FDAA@rebar.astron.com> <54DE8BB7.5050801@oracle.com> <54DE9140.3040604@oracle.com> <54E30C38.8000303@redhat.com> <54E31144.3040504@redhat.com> <54E314BF.3010205@redhat.com> <54E31677.1050209@redhat.com> <54E31CA6.6030609@redhat.com> <54E31DA0.2040901@redhat.com> <54E34EAF.6000802@redhat.com> <0457F01A-9DE1-4049-BFA2-66C7F6CCAA0B@oracle.com> <54E38F4B.7060100@redhat.com> <54E39364.6030409@oracle.com> <54E462E1.5080009@redhat.com> <54E4652F.80600@redhat.com> Message-ID: <54E4AF08.5030100@redhat.com> On 02/18/2015 02:16 PM, Vitaly Davidovich wrote: > I don't think explicit barriers (i.e. Unsafe.xxxFence) should be removed as > I don't think compiler can prove that it's safe to do so. Nobody thinks that explicit barriers (i.e. Unsafe.xxxFence) should be removed. We're talking about fences at the end of constructors which have final fields. These should be removed if the object does not escape. Andrew. From vitalyd at gmail.com Wed Feb 18 15:32:40 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 18 Feb 2015 10:32:40 -0500 Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses In-Reply-To: <54E4AF08.5030100@redhat.com> References: <20150213230416.5E7B617FDAA@rebar.astron.com> <54DE8BB7.5050801@oracle.com> <54DE9140.3040604@oracle.com> <54E30C38.8000303@redhat.com> <54E31144.3040504@redhat.com> <54E314BF.3010205@redhat.com> <54E31677.1050209@redhat.com> <54E31CA6.6030609@redhat.com> <54E31DA0.2040901@redhat.com> <54E34EAF.6000802@redhat.com> <0457F01A-9DE1-4049-BFA2-66C7F6CCAA0B@oracle.com> <54E38F4B.7060100@redhat.com> <54E39364.6030409@oracle.com> <54E462E1.5080009@redhat.com> <54E4652F.80600@redhat.com> <54E4AF08.5030100@redhat.com> Message-ID: Ok, perhaps I misunderstood then since you mentioned Unsafe.storeFence() in your earlier post and Vladimir said they were debating whether these fences should be removed. If you guys were talking only about the final field fence, then my bad, I don't disagree with removing those if the object doesn't escape. On Wed, Feb 18, 2015 at 10:26 AM, Andrew Haley wrote: > On 02/18/2015 02:16 PM, Vitaly Davidovich wrote: > > I don't think explicit barriers (i.e. Unsafe.xxxFence) should be removed > as > > I don't think compiler can prove that it's safe to do so. > > Nobody thinks that explicit barriers (i.e. Unsafe.xxxFence) should be > removed. > > We're talking about fences at the end of constructors which have final > fields. These should be removed if the object does not escape. > > Andrew. > > From goetz.lindenmaier at sap.com Wed Feb 18 15:36:30 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 18 Feb 2015 15:36:30 +0000 Subject: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. References: <4295855A5C1DE049A61835A1887419CC2CF9615F@DEWDFEMB12A.global.corp.sap> <70B02DBE-E246-45F9-89C7-898881B0C69A@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CF965AF@DEWDFEMB12A.global.corp.sap> Hi, I additionally updated the copyrights in this webrev ;) Best regards, Goetz. -----Original Message----- From: Lindenmaier, Goetz Sent: Mittwoch, 18. Februar 2015 11:53 To: 'Kim Barrett' Cc: hotspot-dev Source Developers Subject: RE: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. Hi Kim, thanks for looking at this! > As Jesper noted, there are cases where, yes, the > warning is correct today, but future maintenance might change that. You mean, somebody could change the type to signed, and then again the assertion makes sense? I thought about that. One could add some function is_unsigned(uint64_t x) { return true; } is_unsigned(int64_t x) { return false; } in the assertions. It might even be possible to get a warning if the second is left out, so that it's a compile time error (-Werror). But it seemed a bit overengineered to me, as there's sure lots of cases where changing signedness would causes similar problems with current code, but there is no assertion to catch it. > This warning can also lead to serious ugliness with generic code > (e.g. templates), where only some values of a type parameter trigger > warnings. There is currently no such code in the VM. We could again remove the flag if such a case comes up. Until then, the warning will avoid future errors. And maybe, until then, openJDK uses a compiler with that issue fixed. Should I add a respective comment in the makefile? I fixed last_active_index() as you proposed. Yes, that's better. http://cr.openjdk.java.net/~goetz/webrevs/8073315-wUnsign/webrev.02/ Best regards, Goetz. -----Original Message----- From: Kim Barrett [mailto:kim.barrett at oracle.com] Sent: Mittwoch, 18. Februar 2015 00:28 To: Lindenmaier, Goetz Cc: hotspot-dev Source Developers Subject: Re: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. On Feb 17, 2015, at 6:42 AM, Lindenmaier, Goetz wrote: > > We fixed all the warnings showing with -Wtype-limits and gcc in our VM. > I would like to contribute these small changes. > > This warning detects unnecessary compares for >= 0 of unsigned values. > > At least one warning unveils a real bug. In memory/blockOffsetTable.cpp, > BlockOffsetArrayContigSpace::last_active_index(), the compare to >=0 > tries to prevent an underflow, but the value is unsigned. > > Further useless compares in real code are in os_linux.cpp, > opto/graphKit.cpp, prims/jvmtiRedefineClasses.cpp > > In some places debug code with constant debug flags caused > warnings in the opt build (g1/concurrentMark.cpp, classfile/systemDictionary.cpp) > > The remaining warnings occur in asserts, which is also the biggest part. > > The change also removes an empty #ifdef ASSERT . > > Please review this change. I please need a sponsor. > https://bugs.openjdk.java.net/browse/JDK-8073315 > http://cr.openjdk.java.net/~goetz/webrevs/8073315-wUnsign/webrev.01/ > > I tested this on linuxx86_64 with gcc 4.1.2, 4.3 and 4.8. Further I ran the patch > with our nightly builds and tests of jdk9,see > http://cr.openjdk.java.net/~simonis/ppc-aix-port/index.html -Wtype-limits is one of those somewhat questionable warnings that are enabled by -Wextra. As Jesper noted, there are cases where, yes, the warning is correct today, but future maintenance might change that. And the information that one needs in order to make that determination might be far away from the expression generating the warning. This warning can also lead to serious ugliness with generic code (e.g. templates), where only some values of a type parameter trigger warnings. I've seen real code that used template metapogramming to select different expressions in order to dodge this specific warning. In other words, while this warning does sometimes find real bugs, it also tends to generate a lot of false positives. Because of that, I'm not sure it's actually a good idea to enable it. For the specific bug mentioned, I would like to just see that fixed, but not in the way that was done in the webrev, e.g. incorrect old: 794 size_t BlockOffsetArrayContigSpace::last_active_index() const { 795 size_t result = _next_offset_index - 1; 796 return result >= 0 ? result : 0; 797 }mem webrev: 794 size_t BlockOffsetArrayContigSpace::last_active_index() const { 795 size_t result = _next_offset_index - 1; 796 return ((intptr_t)result) >= 0 ? result : 0; 797 } better: size_t BlockOffsetArrayContigSpace::last_active_index() const { size_t next = _next_offset_index; return next == 0 ? 0 : next - 1; } Eschew unnecessary casts! From stefan.karlsson at oracle.com Wed Feb 18 15:54:14 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 18 Feb 2015 16:54:14 +0100 Subject: RFR: 8073389: Remove the include of resourceArea.hpp from classFileParser.hpp In-Reply-To: <54E491B3.9000708@oracle.com> References: <54E45CF2.90208@oracle.com> <54E491B3.9000708@oracle.com> Message-ID: <54E4B5A6.60502@oracle.com> On 2015-02-18 14:20, Coleen Phillimore wrote: > > Seems good. Thanks, StefanK > > Coleen > > On 2/18/15, 4:35 AM, Stefan Karlsson wrote: >> Hi, >> >> Please review this patch to get rid of the inclusion of >> resourceArea.hpp from classFileParser.hpp. >> >> From the RFE: >> >> The inclusion of resourceArea.hpp in classFileParser.hpp is causing >> cyclic dependencies when I'm changing unrelated code. The main reason >> for this is that a lot of implementation is put inside the >> resourceArea.hpp file instead of a .cpp file. >> >> I've opted to go the easy route now and get rid of the the >> resourceArea.hpp dependency from classFileParser.hpp, but eventually >> it would be good to fix that file. >> >> This patch has to add explicit includes of resourceArea.hpp to other >> .hpp files, that used to get their include from classFileParser.hpp. >> I could have gotten rid of those dependencies as well, but I chose to >> not do that for this patch. >> >> http://cr.openjdk.java.net/~stefank/8073389/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8073389 >> >> Thanks, >> StefanK > From stefan.karlsson at oracle.com Wed Feb 18 15:54:30 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 18 Feb 2015 16:54:30 +0100 Subject: RFR: 8073388: Get rid of the dependency from handles.hpp to klass.hpp In-Reply-To: <54E4912B.4000201@oracle.com> References: <54E45882.5030609@oracle.com> <54E4912B.4000201@oracle.com> Message-ID: <54E4B5B6.4000002@oracle.com> On 2015-02-18 14:18, Coleen Phillimore wrote: > > Looks fine. Thanks, StefanK > Coleen > > On 2/18/15, 4:16 AM, Stefan Karlsson wrote: >> Hi, >> >> Please review this patch to get rid of dependencies from handles.hpp >> to klass.hpp. This patch is extracted from a bigger patch to clean up >> some of our GC code dependencies in oop_iterate. >> >> http://cr.openjdk.java.net/~stefank/8073388/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8073388 >> >> Thanks, >> StefanK > From stefan.karlsson at oracle.com Wed Feb 18 16:04:06 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 18 Feb 2015 17:04:06 +0100 Subject: RFR: 8073387: Move VerifyOopClosures out from genOopClosures.hpp In-Reply-To: <54E490CF.1030003@oracle.com> References: <54E448DA.4060406@oracle.com> <54E44C93.8040402@oracle.com> <54E490CF.1030003@oracle.com> Message-ID: <54E4B7F6.9050605@oracle.com> On 2015-02-18 14:17, Coleen Phillimore wrote: > > I have a request - can you name the file verifyOopClosure.hpp There's > a different JVM option that we use that is -XX:+VerifyOops which is > completely different than this. The name of the class in > verifyOop.hpp is VerifyOopClosure also. Sure. StefanK > > Coleen > > On 2/18/15, 3:25 AM, Mikael Gerdin wrote: >> Hi Stefan, >> >> On 2015-02-18 09:10, Stefan Karlsson wrote: >>> Hi, >>> >>> Please review this patch to move VerifyOopClosures out from >>> genOopClosures.hpp. This way users of VerifyOopClosures don't have to >>> include genOopClosures.hpp anymore. The implementation of >>> VerifyOopClosures::do_oop_work is placed in oop.cpp, where the other >>> VerifyOopClosure functions are located. >>> >>> http://cr.openjdk.java.net/~stefank/8073387/webrev.01/ >> >> Looks good to me. >> >> /Mikael >> >>> https://bugs.openjdk.java.net/browse/JDK-8073387 >>> >>> Thanks, >>> StefanK >> > From jesper.wilhelmsson at oracle.com Wed Feb 18 16:28:45 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 18 Feb 2015 17:28:45 +0100 Subject: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CF96468@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CF9615F@DEWDFEMB12A.global.corp.sap> <70B02DBE-E246-45F9-89C7-898881B0C69A@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF96468@DEWDFEMB12A.global.corp.sap> Message-ID: <54E4BDBD.6000206@oracle.com> Hi Goetz, Lindenmaier, Goetz skrev den 18/2/15 11:53: > Hi Kim, > > thanks for looking at this! > >> As Jesper noted, there are cases where, yes, the >> warning is correct today, but future maintenance might change that. > You mean, somebody could change the type to signed, and then again > the assertion makes sense? > I thought about that. One could add some function > is_unsigned(uint64_t x) { return true; } > is_unsigned(int64_t x) { return false; } > in the assertions. It might even be possible to get a warning if the > second is left out, so that it's a compile time error (-Werror). > But it seemed a bit overengineered to me, as there's sure lots of > cases where changing signedness would causes similar problems > with current code, but there is no assertion to catch it. This approach seems, as you say, over engineered. If someone wants to change the type of a variable all usages of that variable should be examined anyway. There are several things that can go wrong with a change like that. Things the developers never even thought about since they had a reason to choose the type they used in the first place. Anyway, I think the latest webrev looks good. I can sponsor the change if Kim agrees that this is an OK change to do. Please note that you need a Reviewer as well. Both me and Kim are committers only. /Jesper > >> This warning can also lead to serious ugliness with generic code >> (e.g. templates), where only some values of a type parameter trigger >> warnings. > There is currently no such code in the VM. We could again remove > the flag if such a case comes up. Until then, the warning will avoid > future errors. And maybe, until then, openJDK uses a compiler with > that issue fixed. > Should I add a respective comment in the makefile? > > I fixed last_active_index() as you proposed. Yes, that's better. > http://cr.openjdk.java.net/~goetz/webrevs/8073315-wUnsign/webrev.02/ > > Best regards, > Goetz. > > > -----Original Message----- > From: Kim Barrett [mailto:kim.barrett at oracle.com] > Sent: Mittwoch, 18. Februar 2015 00:28 > To: Lindenmaier, Goetz > Cc: hotspot-dev Source Developers > Subject: Re: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. > > On Feb 17, 2015, at 6:42 AM, Lindenmaier, Goetz wrote: >> >> We fixed all the warnings showing with -Wtype-limits and gcc in our VM. >> I would like to contribute these small changes. >> >> This warning detects unnecessary compares for >= 0 of unsigned values. >> >> At least one warning unveils a real bug. In memory/blockOffsetTable.cpp, >> BlockOffsetArrayContigSpace::last_active_index(), the compare to >=0 >> tries to prevent an underflow, but the value is unsigned. >> >> Further useless compares in real code are in os_linux.cpp, >> opto/graphKit.cpp, prims/jvmtiRedefineClasses.cpp >> >> In some places debug code with constant debug flags caused >> warnings in the opt build (g1/concurrentMark.cpp, classfile/systemDictionary.cpp) >> >> The remaining warnings occur in asserts, which is also the biggest part. >> >> The change also removes an empty #ifdef ASSERT . >> >> Please review this change. I please need a sponsor. >> https://bugs.openjdk.java.net/browse/JDK-8073315 >> http://cr.openjdk.java.net/~goetz/webrevs/8073315-wUnsign/webrev.01/ >> >> I tested this on linuxx86_64 with gcc 4.1.2, 4.3 and 4.8. Further I ran the patch >> with our nightly builds and tests of jdk9,see >> http://cr.openjdk.java.net/~simonis/ppc-aix-port/index.html > > -Wtype-limits is one of those somewhat questionable warnings that are > enabled by -Wextra. As Jesper noted, there are cases where, yes, the > warning is correct today, but future maintenance might change that. > And the information that one needs in order to make that determination > might be far away from the expression generating the warning. > > This warning can also lead to serious ugliness with generic code > (e.g. templates), where only some values of a type parameter trigger > warnings. I've seen real code that used template metapogramming to > select different expressions in order to dodge this specific warning. > > In other words, while this warning does sometimes find real bugs, it > also tends to generate a lot of false positives. Because of that, I'm > not sure it's actually a good idea to enable it. > > For the specific bug mentioned, I would like to just see that fixed, > but not in the way that was done in the webrev, e.g. > > incorrect old: > 794 size_t BlockOffsetArrayContigSpace::last_active_index() const { > 795 size_t result = _next_offset_index - 1; > 796 return result >= 0 ? result : 0; > 797 }mem > > webrev: > 794 size_t BlockOffsetArrayContigSpace::last_active_index() const { > 795 size_t result = _next_offset_index - 1; > 796 return ((intptr_t)result) >= 0 ? result : 0; > 797 } > > better: > size_t BlockOffsetArrayContigSpace::last_active_index() const { > size_t next = _next_offset_index; > return next == 0 ? 0 : next - 1; > } > > Eschew unnecessary casts! > From coleen.phillimore at oracle.com Wed Feb 18 16:36:25 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 18 Feb 2015 11:36:25 -0500 Subject: RFR: 8073387: Move VerifyOopClosures out from genOopClosures.hpp In-Reply-To: <54E4B7F6.9050605@oracle.com> References: <54E448DA.4060406@oracle.com> <54E44C93.8040402@oracle.com> <54E490CF.1030003@oracle.com> <54E4B7F6.9050605@oracle.com> Message-ID: <54E4BF89.9090906@oracle.com> It's a minor comment so I don't need to see another webrev. thanks! Coleen On 2/18/15, 11:04 AM, Stefan Karlsson wrote: > On 2015-02-18 14:17, Coleen Phillimore wrote: >> >> I have a request - can you name the file verifyOopClosure.hpp There's >> a different JVM option that we use that is -XX:+VerifyOops which is >> completely different than this. The name of the class in >> verifyOop.hpp is VerifyOopClosure also. > > Sure. > > StefanK > >> >> Coleen >> >> On 2/18/15, 3:25 AM, Mikael Gerdin wrote: >>> Hi Stefan, >>> >>> On 2015-02-18 09:10, Stefan Karlsson wrote: >>>> Hi, >>>> >>>> Please review this patch to move VerifyOopClosures out from >>>> genOopClosures.hpp. This way users of VerifyOopClosures don't have to >>>> include genOopClosures.hpp anymore. The implementation of >>>> VerifyOopClosures::do_oop_work is placed in oop.cpp, where the other >>>> VerifyOopClosure functions are located. >>>> >>>> http://cr.openjdk.java.net/~stefank/8073387/webrev.01/ >>> >>> Looks good to me. >>> >>> /Mikael >>> >>>> https://bugs.openjdk.java.net/browse/JDK-8073387 >>>> >>>> Thanks, >>>> StefanK >>> >> > From bengt.rutisson at oracle.com Wed Feb 18 18:20:13 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 18 Feb 2015 19:20:13 +0100 Subject: RFR: 8062672: JVM crashes during GC on various asserts which checks that HeapWord ptr is an oop In-Reply-To: <54E45F61.2020806@oracle.com> References: <54E45F61.2020806@oracle.com> Message-ID: <54E4D7DD.60701@oracle.com> Hi Stefan, On 18/02/15 10:46, Stefan Johansson wrote: > Hi, > > The fix for 8062672 [1] has been pushed to 7u80 and 8u60 but the patch > get a small conflict when applied to 9. A bugfix only present in 9 > changed one of the patched lines, but the conflict is easy to solve. A > diff between the original patch (present in 7 and 8) and the resolved > one shows only this diff: > > --- a/src/os_cpu/linux_sparc/vm/vm_version_linux_sparc.cpp > > +++ b/src/os_cpu/linux_sparc/vm/vm_version_linux_sparc.cpp > 30c30 > < - if (fscanf(fp, "cpu\t\t: %100[^\n]", &cpu) == 1) { > --- > > - if (fscanf(fp, "cpu\t\t: %100[^\n]", cpu) == 1) { Hm. Your forward port looks good. So, consider it reviewed by me. But the diff above kind of looks like a bug in the 7 and 8 branches to me. The change from passing &cpu to pass cpu was made by this change: JDK-8044071: Print format/argument warnings https://bugs.openjdk.java.net/browse/JDK-8044071 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/cb5694166a39 But this does not look like just a simple "getting rid of a warning" change. It looks to me like we will not detect Niagara correctly on Linux Sparc in JDK 7 and 8. Or am I missing something? Bengt > > The full webrev is available at: > http://cr.openjdk.java.net/~sjohanss/8062672/9/hotspot.00/ > > The original review thread can be seen here: > http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-December/016324.html > > > Thanks, > Stefan > > [1] https://bugs.openjdk.java.net/browse/JDK-8062672 > > From bengt.rutisson at oracle.com Wed Feb 18 18:38:30 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 18 Feb 2015 19:38:30 +0100 Subject: RFR: 8062672: JVM crashes during GC on various asserts which checks that HeapWord ptr is an oop In-Reply-To: <54E4D7DD.60701@oracle.com> References: <54E45F61.2020806@oracle.com> <54E4D7DD.60701@oracle.com> Message-ID: <54E4DC26.2080503@oracle.com> Hi again, On 18/02/15 19:20, Bengt Rutisson wrote: > > Hi Stefan, > > On 18/02/15 10:46, Stefan Johansson wrote: >> Hi, >> >> The fix for 8062672 [1] has been pushed to 7u80 and 8u60 but the >> patch get a small conflict when applied to 9. A bugfix only present >> in 9 changed one of the patched lines, but the conflict is easy to >> solve. A diff between the original patch (present in 7 and 8) and the >> resolved one shows only this diff: >> > --- a/src/os_cpu/linux_sparc/vm/vm_version_linux_sparc.cpp >> > +++ b/src/os_cpu/linux_sparc/vm/vm_version_linux_sparc.cpp >> 30c30 >> < - if (fscanf(fp, "cpu\t\t: %100[^\n]", &cpu) == 1) { >> --- >> > - if (fscanf(fp, "cpu\t\t: %100[^\n]", cpu) == 1) { > > Hm. Your forward port looks good. So, consider it reviewed by me. But > the diff above kind of looks like a bug in the 7 and 8 branches to me. > > The change from passing &cpu to pass cpu was made by this change: > > JDK-8044071: Print format/argument warnings > https://bugs.openjdk.java.net/browse/JDK-8044071 > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/cb5694166a39 > > But this does not look like just a simple "getting rid of a warning" > change. It looks to me like we will not detect Niagara correctly on > Linux Sparc in JDK 7 and 8. Or am I missing something? Yes, I was missing something. The conflict is because you are completely replacing this code. It did not matter that the old code had a bug in it in JDK 7 and 8. You had replaced the buggy code there with completely new code. So, the bug fix made in JDK 9 is not needed in JDK 7 and 8. Sorry, should have looked at the webrev and not just the diff in the email. Thanks to Mikael Vidstedt for an offline chat to discuss this. :) Forward port looks good. Ship it! Bengt > > Bengt > >> >> The full webrev is available at: >> http://cr.openjdk.java.net/~sjohanss/8062672/9/hotspot.00/ >> >> The original review thread can be seen here: >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2014-December/016324.html >> >> >> Thanks, >> Stefan >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8062672 >> >> > From vladimir.kozlov at oracle.com Wed Feb 18 20:59:49 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 18 Feb 2015 12:59:49 -0800 Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses In-Reply-To: References: <20150213230416.5E7B617FDAA@rebar.astron.com> <54DE8BB7.5050801@oracle.com> <54DE9140.3040604@oracle.com> <54E30C38.8000303@redhat.com> <54E31144.3040504@redhat.com> <54E314BF.3010205@redhat.com> <54E31677.1050209@redhat.com> <54E31CA6.6030609@redhat.com> <54E31DA0.2040901@redhat.com> <54E34EAF.6000802@redhat.com> <54E457E0.20408@redhat.com> <54E45842.9030102@redhat.com> <54E473D1.8000506@redhat.com> Message-ID: <54E4FD45.5090106@oracle.com> The code which eliminates MemBars for scalarized objects was added in jdk8: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/6f3fd5150b67 An other store barrier change was also pushed into jdk8: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/fcf521c3fbc6 I don't remember we did anything special with membars in jdk9. Regards, Vladimir On 2/18/15 6:27 AM, Vitaly Davidovich wrote: > Indeed, that's quite nice and not what I saw in java 7 so good to see that > this case is EA'd out. Does anyone know if there was EA work done in java > 9 or is this simply inlining policy change that makes EA work (as John > alluded to)? > > sent from my phone > On Feb 18, 2015 6:13 AM, "Andrew Haley" wrote: > >> On 02/18/2015 09:15 AM, Andrew Haley wrote: >>> On 18/02/15 09:14, Florian Weimer wrote: >>>> Wow, looks nice. What OpenJDK build did you use? I want to see if this >>>> happens on x86_64, too. >>> >>> I'm working on JDK9. You don't have this code yet. I'll do an x86 >>> build. >> >> 0x00007f2948acbf8c: mov 0xc(%rdx),%r10d ;*synchronization entry >> ; - >> java.nio.HeapByteBuffer::@-1 (line 84) >> ; - >> java.nio.ByteBuffer::wrap at 7 (line 373) >> ; - >> java.nio.ByteBuffer::wrap at 4 (line 396) >> ; - >> bytebuffertests.ByteBufferTests3::getLong at 1 (line 23) >> ; implicit exception: >> dispatches to 0x00007f2948acbff5 >> ;; B2: # B5 B3 <- B1 Freq: 0.999999 >> >> ;; MEMBAR-release ! (empty encoding) >> >> 0x00007f2948acbf90: test %ecx,%ecx >> 0x00007f2948acbf92: jl 0x00007f2948acbfb5 ;*iflt >> ; - >> java.nio.Buffer::checkIndex at 1 (line 545) >> ; - >> java.nio.HeapByteBuffer::getLong at 18 (line 465) >> ; - >> bytebuffertests.ByteBufferTests3::getLong at 5 (line 23) >> >> ;; B3: # B6 B4 <- B2 Freq: 0.999999 >> >> 0x00007f2948acbf94: mov %r10d,%ebp >> 0x00007f2948acbf97: sub %ecx,%ebp ;*isub >> ; - >> java.nio.Buffer::checkIndex at 10 (line 545) >> ; - >> java.nio.HeapByteBuffer::getLong at 18 (line 465) >> ; - >> bytebuffertests.ByteBufferTests3::getLong at 5 (line 23) >> >> 0x00007f2948acbf99: cmp $0x8,%ebp >> 0x00007f2948acbf9c: jl 0x00007f2948acbfd5 ;*if_icmple >> ; - >> java.nio.Buffer::checkIndex at 11 (line 545) >> ; - >> java.nio.HeapByteBuffer::getLong at 18 (line 465) >> ; - >> bytebuffertests.ByteBufferTests3::getLong at 5 (line 23) >> >> ;; B4: # N95 <- B3 Freq: 0.999998 >> >> 0x00007f2948acbf9e: movslq %ecx,%r10 >> 0x00007f2948acbfa1: mov 0x10(%rdx,%r10,1),%rax >> 0x00007f2948acbfa6: bswap %rax ;*invokestatic reverseBytes >> ; - java.nio.Bits::swap at 1 >> (line 61) >> ; - >> java.nio.HeapByteBuffer::getLong at 41 (line 466) >> ; - >> bytebuffertests.ByteBufferTests3::getLong at 5 (line 23) >> >> So, just the same except that there is no explicit fence instruction >> to remove. It's a shame for AArch64 because that fence really kills >> performance but it's bad for x86 too. Even on machines that don't >> emit fence instructions the fence still acts as a compiler barrier. >> >> Andrew. >> From vitalyd at gmail.com Wed Feb 18 21:03:51 2015 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Wed, 18 Feb 2015 16:03:51 -0500 Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses In-Reply-To: <54E4FD45.5090106@oracle.com> References: <20150213230416.5E7B617FDAA@rebar.astron.com> <54DE8BB7.5050801@oracle.com> <54DE9140.3040604@oracle.com> <54E30C38.8000303@redhat.com> <54E31144.3040504@redhat.com> <54E314BF.3010205@redhat.com> <54E31677.1050209@redhat.com> <54E31CA6.6030609@redhat.com> <54E31DA0.2040901@redhat.com> <54E34EAF.6000802@redhat.com> <54E457E0.20408@redhat.com> <54E45842.9030102@redhat.com> <54E473D1.8000506@redhat.com> <54E4FD45.5090106@oracle.com> Message-ID: Thanks Vladimir. I was actually asking about the ByteBuffer elimination itself; when I tried Andrew's example on 7u60 (i.e. a single method with a ByteBuffer.wrap(...).getLong(...)), the ByteBuffer allocation was not removed. On Wed, Feb 18, 2015 at 3:59 PM, Vladimir Kozlov wrote: > The code which eliminates MemBars for scalarized objects was added in jdk8: > > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/6f3fd5150b67 > > An other store barrier change was also pushed into jdk8: > > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/fcf521c3fbc6 > > I don't remember we did anything special with membars in jdk9. > > Regards, > Vladimir > > > On 2/18/15 6:27 AM, Vitaly Davidovich wrote: > >> Indeed, that's quite nice and not what I saw in java 7 so good to see that >> this case is EA'd out. Does anyone know if there was EA work done in java >> 9 or is this simply inlining policy change that makes EA work (as John >> alluded to)? >> >> sent from my phone >> On Feb 18, 2015 6:13 AM, "Andrew Haley" wrote: >> >> On 02/18/2015 09:15 AM, Andrew Haley wrote: >>> >>>> On 18/02/15 09:14, Florian Weimer wrote: >>>> >>>>> Wow, looks nice. What OpenJDK build did you use? I want to see if >>>>> this >>>>> happens on x86_64, too. >>>>> >>>> >>>> I'm working on JDK9. You don't have this code yet. I'll do an x86 >>>> build. >>>> >>> >>> 0x00007f2948acbf8c: mov 0xc(%rdx),%r10d ;*synchronization entry >>> ; - >>> java.nio.HeapByteBuffer::@-1 (line 84) >>> ; - >>> java.nio.ByteBuffer::wrap at 7 (line 373) >>> ; - >>> java.nio.ByteBuffer::wrap at 4 (line 396) >>> ; - >>> bytebuffertests.ByteBufferTests3::getLong at 1 (line 23) >>> ; implicit exception: >>> dispatches to 0x00007f2948acbff5 >>> ;; B2: # B5 B3 <- B1 Freq: 0.999999 >>> >>> ;; MEMBAR-release ! (empty encoding) >>> >>> 0x00007f2948acbf90: test %ecx,%ecx >>> 0x00007f2948acbf92: jl 0x00007f2948acbfb5 ;*iflt >>> ; - >>> java.nio.Buffer::checkIndex at 1 (line 545) >>> ; - >>> java.nio.HeapByteBuffer::getLong at 18 (line 465) >>> ; - >>> bytebuffertests.ByteBufferTests3::getLong at 5 (line 23) >>> >>> ;; B3: # B6 B4 <- B2 Freq: 0.999999 >>> >>> 0x00007f2948acbf94: mov %r10d,%ebp >>> 0x00007f2948acbf97: sub %ecx,%ebp ;*isub >>> ; - >>> java.nio.Buffer::checkIndex at 10 (line 545) >>> ; - >>> java.nio.HeapByteBuffer::getLong at 18 (line 465) >>> ; - >>> bytebuffertests.ByteBufferTests3::getLong at 5 (line 23) >>> >>> 0x00007f2948acbf99: cmp $0x8,%ebp >>> 0x00007f2948acbf9c: jl 0x00007f2948acbfd5 ;*if_icmple >>> ; - >>> java.nio.Buffer::checkIndex at 11 (line 545) >>> ; - >>> java.nio.HeapByteBuffer::getLong at 18 (line 465) >>> ; - >>> bytebuffertests.ByteBufferTests3::getLong at 5 (line 23) >>> >>> ;; B4: # N95 <- B3 Freq: 0.999998 >>> >>> 0x00007f2948acbf9e: movslq %ecx,%r10 >>> 0x00007f2948acbfa1: mov 0x10(%rdx,%r10,1),%rax >>> 0x00007f2948acbfa6: bswap %rax ;*invokestatic >>> reverseBytes >>> ; - >>> java.nio.Bits::swap at 1 >>> (line 61) >>> ; - >>> java.nio.HeapByteBuffer::getLong at 41 (line 466) >>> ; - >>> bytebuffertests.ByteBufferTests3::getLong at 5 (line 23) >>> >>> So, just the same except that there is no explicit fence instruction >>> to remove. It's a shame for AArch64 because that fence really kills >>> performance but it's bad for x86 too. Even on machines that don't >>> emit fence instructions the fence still acts as a compiler barrier. >>> >>> Andrew. >>> >>> From kim.barrett at oracle.com Wed Feb 18 22:22:01 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 18 Feb 2015 17:22:01 -0500 Subject: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CF96468@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CF9615F@DEWDFEMB12A.global.corp.sap> <70B02DBE-E246-45F9-89C7-898881B0C69A@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF96468@DEWDFEMB12A.global.corp.sap> Message-ID: On Feb 18, 2015, at 5:53 AM, Lindenmaier, Goetz wrote: > You mean, somebody could change the type to signed, and then again > the assertion makes sense? Yes. That sort of thing happens. In my experience it happens more frequently in the signed to unsigned direction, e.g. the original code "casually" used int but later changed to use size_t. Such a change could trip the warning in lots of otherwise uninteresting far away code that isn't actually broken at all; it just contains expressions that any competent compiler (particularly one capable of generating this warning) will now optimize away. > I thought about that. One could add some function > is_unsigned(uint64_t x) { return true; } > is_unsigned(int64_t x) { return false; } > in the assertions. That doesn't work except for uint64_t or int64_t argument types. For any other argument type, this will fail to compile due to ambiguous overloads. For complete coverage, portability, and correctness, this kind of thing is generally done using template metaprogramming, typically using std::numeric_limits<>. > It might even be possible to get a warning if the > second is left out, so that it's a compile time error (-Werror). That doesn't work, due to integer conversion rules. >> This warning can also lead to serious ugliness with generic code >> (e.g. templates), where only some values of a type parameter trigger >> warnings. > > There is currently no such code in the VM. We could again remove > the flag if such a case comes up. Until then, the warning will avoid > future errors. The VM code barely uses templates at all at present, though that seems to be changing. This situation also arises in certain kinds of macros. It might also arise with code dealing with enums. And as it happens, I have a change set out for review right now that should have exactly this problem. [It presently doesn't because I had to tweak and uglify the code because the code I wanted failed to compile on MacOSX in a way that looks like (some part of?) -Wtype-limits is turned on? I should probably try harder to figure out what's really going wrong, but that changeset has been hanging around for a while and is blocking other work.] > And maybe, until then, openJDK uses a compiler with > that issue fixed. What compiler issue? There's no compiler issue here. The warning does exactly what it says, which is warn about code that is correct according to the language but is going to be optimized away, because *sometimes* that indicates the code is not doing what the programmer thought it was doing. I'm a big fan of warning flags that pick up a significant number of real mistakes with few false positives. I really wish hotspot could be built with -Wall, and think it would be worth some effort to get there. But there are good reasons why -Wtype-limits is in the -Wextra set rather than the -Wall set. From kim.barrett at oracle.com Thu Feb 19 01:20:33 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 18 Feb 2015 20:20:33 -0500 Subject: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CF96468@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CF9615F@DEWDFEMB12A.global.corp.sap> <70B02DBE-E246-45F9-89C7-898881B0C69A@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF96468@DEWDFEMB12A.global.corp.sap> Message-ID: <65A32AAF-F514-4E10-AF4A-DA04F41F57BF@oracle.com> On Feb 18, 2015, at 5:53 AM, Lindenmaier, Goetz wrote: > > http://cr.openjdk.java.net/~goetz/webrevs/8073315-wUnsign/webrev.02/ I wonder how many of the changes being made here are the result of code that originally used int for some counters, indices, or size values, and was later changed to use an appropriate unsigned type. ------------------------------------------------------------------------------ src/os/linux/vm/os_linux.cpp 3751 size_t top_overlap = requested_addr + (bytes + gap) - base[i]; 3752 if (top_overlap >= 0 && top_overlap < bytes) { => 3751 size_t top_overlap = requested_addr + (bytes + gap) - base[i]; 3752 if (requested_addr + (bytes + gap) >= base[i] && // Check underflow. 3753 top_overlap < bytes) { I believe the real problem here is the type of top_overlap, which should be ptrdiff_t rather than size_t. I *think* that if just that type change was made, that the rest would be fine. Similarly a few lines later for bottom_overlap. ------------------------------------------------------------------------------ src/os/linux/vm/os_linux.cpp 6028 int written; ... 6050 if ((written >= 0) && ((size_t)written < bufferSize) && 6051 (pid_pos == NULL) && (core_pattern[0] != '|')) { The real problem here is the value of "written", which is the result of a call to jio_snprintf, is not being checked for failure. Clearly "written" should be of signed type because of its value, but the other changes here just continue to mask the lack of error checking. ------------------------------------------------------------------------------ src/share/vm/classfile/systemDictionary.cpp 1371 for (uintx it = 0; it < GCExpandToAllocateDelayMillis; it++){} I'll grant you that one as a nice find and deletion. (Although the code is "harmless", since the compiler should optimize it away.) ------------------------------------------------------------------------------ src/share/vm/gc_implementation/g1/concurrentMark.cpp 2173 #ifndef PRODUCT 2174 if (G1StressConcRegionFreeing) { 2175 for (uintx i = 0; i < G1StressConcRegionFreeingDelayMillis; ++i) { 2176 os::sleep(Thread::current(), (jlong) 1, false); 2177 } 2178 } 2179 #endif The #ifndef here is the kind of workaround for the warning that I really dislike. But why isn't this just if (G1StressConcRegionFreeing) { os::sleep(Thread::current(), G1StressConcRegionFreeingDelayMillis, false); } or maybe even "true" for the third argument to sleep, to allow it to be interruptable. ----------------------------------------------------------------------------- src/share/vm/prims/jvmtiRedefineClasses.cpp 2908 if (frame_type >= 0 && frame_type <= 63) { => 2908 if (frame_type <= 63) { There is a comment a few lines back: 2897 // The Linux compiler does not like frame_type to be u1 or u2. It 2898 // issues the following warning for the first if-statement below: 2899 // 2900 // "warning: comparison is always true due to limited range of data type" It looks like someone got that warning and tried to work around it in a different way, without really understanding what was going on. Eliminating the (frame >= 0) expression is ok, but the comment should be eliminated and perhaps consider changing the type for frame_type to u1? I'm less sure about the type change. ------------------------------------------------------------------------------ From tdaitx at br.ibm.com Thu Feb 19 03:02:05 2015 From: tdaitx at br.ibm.com (Tiago Sturmer Daitx) Date: Thu, 19 Feb 2015 01:02:05 -0200 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <958867570.14123662.1424262805099.JavaMail.zimbra@redhat.com> References: <531E8309.2060206@oracle.com> <531ED06F.5040905@oracle.com> <107001365.11810418.1423839439509.JavaMail.zimbra@redhat.com> <54E183B8.5010301@oracle.com> <54E3B144.1090402@oracle.com> <958867570.14123662.1424262805099.JavaMail.zimbra@redhat.com> Message-ID: <1424314925.5112.149.camel@ocdc> On Wed, 2015-02-18 at 07:33 -0500, Andrew Hughes wrote: > I now have these changes working on 8u31: > > http://cr.openjdk.java.net/~andrew/rh1191652/root > http://cr.openjdk.java.net/~andrew/rh1191652/jdk > > I can re-base these onto whichever OpenJDK 9 tree is appropriate and push when > reviewed under the same bug as used for the HotSpot side. Concurrently to Andrew I also worked on a fix for JDK9 and came up with a somewhat different approach (based on jdk9/dev): http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/webrev.00/hotspot/ http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/webrev.00/root To make it easy I already rebased Andrew's JDK8u31 patches to jdk9/dev (due to that the webrev ended up with my username). http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/ahughes-webrev.00/hotspot/ http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/ahughes-webrev.00/jdk http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/ahughes-webrev.00/root I tested both approaches by building Hadoop (which triggered some interesting bugs on various projects due to Jigsaw). Sorry for the github links, but I don't have an account at cr.openjdk.java.net that I can use. I can provide tar files if anyone is willing to host those webrevs. Regards, Tiago Daitx From david.holmes at oracle.com Thu Feb 19 03:35:29 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 19 Feb 2015 13:35:29 +1000 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <1424314925.5112.149.camel@ocdc> References: <531E8309.2060206@oracle.com> <531ED06F.5040905@oracle.com> <107001365.11810418.1423839439509.JavaMail.zimbra@redhat.com> <54E183B8.5010301@oracle.com> <54E3B144.1090402@oracle.com> <958867570.14123662.1424262805099.JavaMail.zimbra@redhat.com> <1424314925.5112.149.camel@ocdc> Message-ID: <54E55A01.5020700@oracle.com> Hi Tiago, Please email me the tar files and I will host it for you. Thanks, David On 19/02/2015 1:02 PM, Tiago Sturmer Daitx wrote: > On Wed, 2015-02-18 at 07:33 -0500, Andrew Hughes wrote: >> I now have these changes working on 8u31: >> >> http://cr.openjdk.java.net/~andrew/rh1191652/root >> http://cr.openjdk.java.net/~andrew/rh1191652/jdk >> >> I can re-base these onto whichever OpenJDK 9 tree is appropriate and push when >> reviewed under the same bug as used for the HotSpot side. > > Concurrently to Andrew I also worked on a fix for JDK9 and came up with > a somewhat different approach (based on jdk9/dev): > > http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/webrev.00/hotspot/ > http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/webrev.00/root > > To make it easy I already rebased Andrew's JDK8u31 patches to jdk9/dev > (due to that the webrev ended up with my username). > > http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/ahughes-webrev.00/hotspot/ > http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/ahughes-webrev.00/jdk > http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/ahughes-webrev.00/root > > I tested both approaches by building Hadoop (which triggered some > interesting bugs on various projects due to Jigsaw). > > Sorry for the github links, but I don't have an account at > cr.openjdk.java.net that I can use. I can provide tar files if anyone is > willing to host those webrevs. > > Regards, > Tiago Daitx > From david.holmes at oracle.com Thu Feb 19 04:22:27 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 19 Feb 2015 14:22:27 +1000 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <54E55A01.5020700@oracle.com> References: <531E8309.2060206@oracle.com> <531ED06F.5040905@oracle.com> <107001365.11810418.1423839439509.JavaMail.zimbra@redhat.com> <54E183B8.5010301@oracle.com> <54E3B144.1090402@oracle.com> <958867570.14123662.1424262805099.JavaMail.zimbra@redhat.com> <1424314925.5112.149.camel@ocdc> <54E55A01.5020700@oracle.com> Message-ID: <54E56503.4090704@oracle.com> Now hosted at: http://cr.openjdk.java.net/~dholmes/ahughes-rh1191652-jdk9-webrev/ David On 19/02/2015 1:35 PM, David Holmes wrote: > Hi Tiago, > > Please email me the tar files and I will host it for you. > > Thanks, > David > > On 19/02/2015 1:02 PM, Tiago Sturmer Daitx wrote: >> On Wed, 2015-02-18 at 07:33 -0500, Andrew Hughes wrote: >>> I now have these changes working on 8u31: >>> >>> http://cr.openjdk.java.net/~andrew/rh1191652/root >>> http://cr.openjdk.java.net/~andrew/rh1191652/jdk >>> >>> I can re-base these onto whichever OpenJDK 9 tree is appropriate and >>> push when >>> reviewed under the same bug as used for the HotSpot side. >> >> Concurrently to Andrew I also worked on a fix for JDK9 and came up with >> a somewhat different approach (based on jdk9/dev): >> >> http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/webrev.00/hotspot/ >> http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/webrev.00/root >> >> To make it easy I already rebased Andrew's JDK8u31 patches to jdk9/dev >> (due to that the webrev ended up with my username). >> >> http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/ahughes-webrev.00/hotspot/ >> >> http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/ahughes-webrev.00/jdk >> >> http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/ahughes-webrev.00/root >> >> >> I tested both approaches by building Hadoop (which triggered some >> interesting bugs on various projects due to Jigsaw). >> >> Sorry for the github links, but I don't have an account at >> cr.openjdk.java.net that I can use. I can provide tar files if anyone is >> willing to host those webrevs. >> >> Regards, >> Tiago Daitx >> From serguei.spitsyn at oracle.com Thu Feb 19 05:45:40 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 18 Feb 2015 21:45:40 -0800 Subject: RFR (M) 8046246: the constantPoolCacheOopDesc::adjust_method_entries() used in RedefineClasses does not scale Message-ID: <54E57884.8030200@oracle.com> Please, review the fix for: https://bugs.openjdk.java.net/browse/JDK-8046246 Open hotspot webrevs: http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.1/ Open jdk (new unit test) webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8046246-JVMTI-manymethods.1/ Summary: This performance/scalability issue in class redefinition was reported by HP and the Enterprise Manager team. The following variants of the adjust_method_entries() functions do not scale: ConstantPoolCache::adjust_method_entries() klassVtable::adjust_method_entries() klassItable::adjust_method_entries() InstanceKlass::adjust_default_methods() The ConstantPoolCache::adjust_method_entries() is the most important. The approach is to use the holder->method_with_idnum() like this: Method* new_method = holder->method_with_idnum(old_method->orig_method_idnum()); if (old_method != new_method) { } New algorithm has effectiveness O(M) instead of original O(M^2), where M is count of methods in the class. The new test (see webrev above) was used to mesure CPU time consumed by the ConstantPoolCache::adjust_method_entries() in both original and new approach. The performance numbers are: --------------------------------------------------------------------------------------- Methods: ------ 1,000 --------------- 10,000 ----------------- 20,000 --------------------------------------------------------------------------------------- Orig: 600,000 nsec (1x) 60,500,000 nsec (~100x) 243,000,000 nsec (~400x) New: 16,000 nsec (1x) 178,000 nsec (~10x) 355,000 nsec (~20x) --------------------------------------------------------------------------------------- Testing: In progress: VM SQE RedefineClasses tests, JTREG java/lang/instrument, com/sun/jdi tests Thanks, Serguei From david.holmes at oracle.com Thu Feb 19 07:46:56 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 19 Feb 2015 17:46:56 +1000 Subject: RFR: 8073389: Remove the include of resourceArea.hpp from classFileParser.hpp In-Reply-To: <54E492CB.70004@oracle.com> References: <54E45CF2.90208@oracle.com> <54E47931.10101@oracle.com> <54E482DF.6010004@oracle.com> <54E492CB.70004@oracle.com> Message-ID: <54E594F0.1060908@oracle.com> On 18/02/2015 11:25 PM, Coleen Phillimore wrote: > > On 2/18/15, 7:17 AM, Stefan Karlsson wrote: >> Hi David, >> >> On 2015-02-18 12:36, David Holmes wrote: >>> On 18/02/2015 7:35 PM, Stefan Karlsson wrote: >>>> Hi, >>>> >>>> Please review this patch to get rid of the inclusion of >>>> resourceArea.hpp >>>> from classFileParser.hpp. >>>> >>>> From the RFE: >>>> >>>> The inclusion of resourceArea.hpp in classFileParser.hpp is causing >>>> cyclic dependencies when I'm changing unrelated code. The main reason >>>> for this is that a lot of implementation is put inside the >>>> resourceArea.hpp file instead of a .cpp file. >>> >>> I must be missing something here - the implementation in the .hpp >>> file is because all of the functions are implicitly inline. No >>> guarantee they will be inlined of course but at least in product mode >>> many of them should be. So assuming this is a good thing and we want >>> to keep that for performance then the fix would be to introduce a >>> .inline.hpp file, not to move stuff to a .cpp file. > > I don't see how error reporting functions should be performance > critical. I think they're better off in the .cpp file. We're talking about the implementations in resourceArea.hpp. David >> >> Yes, you're right, if we assume that these functions are performance >> critical. Personally, I'm not so sure that they were put in the header >> file for performance reasons. But since I'm not changing >> resourceArea.hpp I don't have to figure it out at this point. >> >>> >>> >>>> I've opted to go the easy route now and get rid of the the >>>> resourceArea.hpp dependency from classFileParser.hpp, but eventually it >>>> would be good to fix that file. >>>> >>>> This patch has to add explicit includes of resourceArea.hpp to other >>>> .hpp files, that used to get their include from classFileParser.hpp. I >>>> could have gotten rid of those dependencies as well, but I chose to not >>>> do that for this patch. >>>> >>>> http://cr.openjdk.java.net/~stefank/8073389/webrev.01/ >>>> https://bugs.openjdk.java.net/browse/JDK-8073389 >>> >>> What was classFileParser.hpp using from resourceArea.hpp ? >>> >>> How does the change to src/share/vm/services/runtimeService.cpp fit >>> in ?? >> >> There is an include path that was removed when I cleaned up >> classFileParser.hpp: >> >> runtimeServices.cpp >> classLoader.hpp >> classFileParser.hpp >> --- The following branch was pruned --- >> resourceArea.hpp >> thread.inline.hpp >> thread.hpp >> threadLocalAllocBuffer.hpp >> vm_version.hpp >> >> So, I added vm_version.hpp to runtimeService.cpp since it uses >> Abstract_VM_Version in vm_version.hpp. >> >>> >>> Seems okay - the proof is in the building as always. Need to check >>> with and without precompiled headers. >> >> It passes JPRT, which runs without PCH on Solaris. I've compiled with >> and without PCH on Linux x64. >> >>> And copyright dates need updating. >> >> Sure. > > Thanks for doing the copyrights. > Coleen > >> >> Thanks, >> StefanK >> >>> >>> Cheers, >>> David >>> >>>> Thanks, >>>> StefanK >> > From david.holmes at oracle.com Thu Feb 19 07:49:39 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 19 Feb 2015 17:49:39 +1000 Subject: RFR: 8073388: Get rid of the dependency from handles.hpp to klass.hpp In-Reply-To: <54E45882.5030609@oracle.com> References: <54E45882.5030609@oracle.com> Message-ID: <54E59593.6040904@oracle.com> On 18/02/2015 7:16 PM, Stefan Karlsson wrote: > Hi, > > Please review this patch to get rid of dependencies from handles.hpp to > klass.hpp. This patch is extracted from a bigger patch to clean up some > of our GC code dependencies in oop_iterate. > > http://cr.openjdk.java.net/~stefank/8073388/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8073388 Has the change from an inline definition to a non-inline definition been cleared from a performance perspective? David > Thanks, > StefanK From goetz.lindenmaier at sap.com Thu Feb 19 08:09:36 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 19 Feb 2015 08:09:36 +0000 Subject: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. In-Reply-To: References: <4295855A5C1DE049A61835A1887419CC2CF9615F@DEWDFEMB12A.global.corp.sap> <70B02DBE-E246-45F9-89C7-898881B0C69A@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF96468@DEWDFEMB12A.global.corp.sap> Message-ID: <4295855A5C1DE049A61835A1887419CC2CF96774@DEWDFEMB12A.global.corp.sap> Hi Kim, I can follow your argumentation about problems that could arise. Nevertheless I think this already unveiled a sufficient number of problematic compares to legitimate enabling the warning. And there is no false positive in the code. If so, the warning still can be disabled again. Best regards, Goetz. -----Original Message----- From: Kim Barrett [mailto:kim.barrett at oracle.com] Sent: Mittwoch, 18. Februar 2015 23:22 To: Lindenmaier, Goetz Cc: hotspot-dev Source Developers Subject: Re: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. On Feb 18, 2015, at 5:53 AM, Lindenmaier, Goetz wrote: > You mean, somebody could change the type to signed, and then again > the assertion makes sense? Yes. That sort of thing happens. In my experience it happens more frequently in the signed to unsigned direction, e.g. the original code "casually" used int but later changed to use size_t. Such a change could trip the warning in lots of otherwise uninteresting far away code that isn't actually broken at all; it just contains expressions that any competent compiler (particularly one capable of generating this warning) will now optimize away. > I thought about that. One could add some function > is_unsigned(uint64_t x) { return true; } > is_unsigned(int64_t x) { return false; } > in the assertions. That doesn't work except for uint64_t or int64_t argument types. For any other argument type, this will fail to compile due to ambiguous overloads. For complete coverage, portability, and correctness, this kind of thing is generally done using template metaprogramming, typically using std::numeric_limits<>. > It might even be possible to get a warning if the > second is left out, so that it's a compile time error (-Werror). That doesn't work, due to integer conversion rules. >> This warning can also lead to serious ugliness with generic code >> (e.g. templates), where only some values of a type parameter trigger >> warnings. > > There is currently no such code in the VM. We could again remove > the flag if such a case comes up. Until then, the warning will avoid > future errors. The VM code barely uses templates at all at present, though that seems to be changing. This situation also arises in certain kinds of macros. It might also arise with code dealing with enums. And as it happens, I have a change set out for review right now that should have exactly this problem. [It presently doesn't because I had to tweak and uglify the code because the code I wanted failed to compile on MacOSX in a way that looks like (some part of?) -Wtype-limits is turned on? I should probably try harder to figure out what's really going wrong, but that changeset has been hanging around for a while and is blocking other work.] > And maybe, until then, openJDK uses a compiler with > that issue fixed. What compiler issue? There's no compiler issue here. The warning does exactly what it says, which is warn about code that is correct according to the language but is going to be optimized away, because *sometimes* that indicates the code is not doing what the programmer thought it was doing. I'm a big fan of warning flags that pick up a significant number of real mistakes with few false positives. I really wish hotspot could be built with -Wall, and think it would be worth some effort to get there. But there are good reasons why -Wtype-limits is in the -Wextra set rather than the -Wall set. From kirk at kodewerk.com Thu Feb 19 08:10:14 2015 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Thu, 19 Feb 2015 09:10:14 +0100 Subject: Strange safe-point banding behavior In-Reply-To: References: <20150213230416.5E7B617FDAA@rebar.astron.com> <54DE8BB7.5050801@oracle.com> <54DE9140.3040604@oracle.com> <54E30C38.8000303@redhat.com> <54E31144.3040504@redhat.com> <54E314BF.3010205@redhat.com> <54E31677.1050209@redhat.com> <54E31CA6.6030609@redhat.com> <54E31DA0.2040901@redhat.com> <54E34EAF.6000802@redhat.com> <0457F01A-9DE1-4049-BFA2-66C7F6CCAA0B@oracle.com> <54E38F4B.7060100@redhat.com> <54E39364.6030409@oracle.com> <54E462E1.5080009@redhat.com> <54E4652F.80600@redhat.com> Message-ID: Hi all, I can?t say that I?ve taken this as far as I could as of yet but I think I can start to ask questions. I?ve seen what I call a banding artifact in a number of GC logs. The latest prompted me to investigate further. In the latest case Application runtime is being reported very frequently a ~1 second. It is being reported some what less frequently every ~2 seconds. So that means a safe point is being called for very frequently at these times so in amongst all of the other application runtime data points these points from a solid line in the chart. Now there are intermixed runtimes that go longer than 2 seconds and of course they are shorter than 1 second. When we looked at PrintSafepointStatistics we get ?no vm operation? which means sstats->_vmop_type == -1 which implies that the VM_Operation has not been set. Question is; why would a safepoint be called for with no VM_Operation? Looking at the code I would say it?s quite common. I?ve turned on safepoint tracing for other applications and have seen other even more bizarre banding patterns which all appear to be due to some regular behavior. This happens on all recent (and most likely older) versions of the JVM. Kind regards, Kirk From david.holmes at oracle.com Thu Feb 19 08:25:04 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 19 Feb 2015 18:25:04 +1000 Subject: Strange safe-point banding behavior In-Reply-To: References: <20150213230416.5E7B617FDAA@rebar.astron.com> <54DE8BB7.5050801@oracle.com> <54DE9140.3040604@oracle.com> <54E30C38.8000303@redhat.com> <54E31144.3040504@redhat.com> <54E314BF.3010205@redhat.com> <54E31677.1050209@redhat.com> <54E31CA6.6030609@redhat.com> <54E31DA0.2040901@redhat.com> <54E34EAF.6000802@redhat.com> <0457F01A-9DE1-4049-BFA2-66C7F6CCAA0B@oracle.com> <54E38F4B.7060100@redhat.com> <54E39364.6030409@oracle.com> <54E462E1.5080009@redhat.com> <54E4652F.80600@redhat.com> Message-ID: <54E59DE0.9030506@oracle.com> Hi Kirk, GuaranteedSafepointInterval has a default value of 1000ms. It's a diagnostic flag so you can try changing it. The reason for this is to ensure certain housekeeping tasks that must occur at a safepoint happen with some regularity eg monitor scavenging. David On 19/02/2015 6:10 PM, Kirk Pepperdine wrote: > Hi all, > > I can?t say that I?ve taken this as far as I could as of yet but I think I can start to ask questions. > > I?ve seen what I call a banding artifact in a number of GC logs. The latest prompted me to investigate further. In the latest case Application runtime is being reported very frequently a ~1 second. It is being reported some what less frequently every ~2 seconds. So that means a safe point is being called for very frequently at these times so in amongst all of the other application runtime data points these points from a solid line in the chart. Now there are intermixed runtimes that go longer than 2 seconds and of course they are shorter than 1 second. > > When we looked at PrintSafepointStatistics we get ?no vm operation? which means sstats->_vmop_type == -1 which implies that the VM_Operation has not been set. > > Question is; why would a safepoint be called for with no VM_Operation? Looking at the code I would say it?s quite common. I?ve turned on safepoint tracing for other applications and have seen other even more bizarre banding patterns which all appear to be due to some regular behavior. > > This happens on all recent (and most likely older) versions of the JVM. > > Kind regards, > Kirk > From erik.joelsson at oracle.com Thu Feb 19 08:26:36 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 19 Feb 2015 09:26:36 +0100 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <958867570.14123662.1424262805099.JavaMail.zimbra@redhat.com> References: <531E8309.2060206@oracle.com> <531ED06F.5040905@oracle.com> <107001365.11810418.1423839439509.JavaMail.zimbra@redhat.com> <54E183B8.5010301@oracle.com> <54E3B144.1090402@oracle.com> <958867570.14123662.1424262805099.JavaMail.zimbra@redhat.com> Message-ID: <54E59E3C.9080801@oracle.com> The 8u changes look ok to me. /Erik On 2015-02-18 13:33, Andrew Hughes wrote: > ----- Original Message ----- >> On 16/02/2015 3:44 PM, David Holmes wrote: >>> I have no issue with this minimal change for hotspot. >>> >>> I suppose I can also volunteer to sponsor it. :) >>> >>> Is the plan to also do the JDK changes under the same bug? That will >>> need build-dev involvement. >> Still waiting to see if this will these hotspot-only changes or whether >> there is more in the works. >> > [ccing build-dev] > > Yes, as I said here: > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2015-February/017175.html > > there are JDK changes but what I had to begin with was for 7 as that's where > the bug was reported. While the HotSpot changes are pretty much the same on 7, > 8 and 9, doing the JDK side has basically been a complete re-write, especially > as, unlike 7, 8 has very little recognition of ppc64le. > > I now have these changes working on 8u31: > > http://cr.openjdk.java.net/~andrew/rh1191652/root > http://cr.openjdk.java.net/~andrew/rh1191652/jdk > > I can re-base these onto whichever OpenJDK 9 tree is appropriate and push when > reviewed under the same bug as used for the HotSpot side. > >> Thanks, >> David From erik.joelsson at oracle.com Thu Feb 19 08:32:31 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 19 Feb 2015 09:32:31 +0100 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <54E56503.4090704@oracle.com> References: <531E8309.2060206@oracle.com> <531ED06F.5040905@oracle.com> <107001365.11810418.1423839439509.JavaMail.zimbra@redhat.com> <54E183B8.5010301@oracle.com> <54E3B144.1090402@oracle.com> <958867570.14123662.1424262805099.JavaMail.zimbra@redhat.com> <1424314925.5112.149.camel@ocdc> <54E55A01.5020700@oracle.com> <54E56503.4090704@oracle.com> Message-ID: <54E59F9F.4040604@oracle.com> Hello, The differences to the 8u patch: * -DABI_ELFv2 is not added to CFLAGS. * Setting of INCLUDE_SA is not changed in jdk-options.m4. Is this because it's already covered by other conditionals in jdk 9? I do not know if this is significant, but would appreciate a comment on the reasoning. /Erik On 2015-02-19 05:22, David Holmes wrote: > Now hosted at: > > http://cr.openjdk.java.net/~dholmes/ahughes-rh1191652-jdk9-webrev/ > > David > > On 19/02/2015 1:35 PM, David Holmes wrote: >> Hi Tiago, >> >> Please email me the tar files and I will host it for you. >> >> Thanks, >> David >> >> On 19/02/2015 1:02 PM, Tiago Sturmer Daitx wrote: >>> On Wed, 2015-02-18 at 07:33 -0500, Andrew Hughes wrote: >>>> I now have these changes working on 8u31: >>>> >>>> http://cr.openjdk.java.net/~andrew/rh1191652/root >>>> http://cr.openjdk.java.net/~andrew/rh1191652/jdk >>>> >>>> I can re-base these onto whichever OpenJDK 9 tree is appropriate and >>>> push when >>>> reviewed under the same bug as used for the HotSpot side. >>> >>> Concurrently to Andrew I also worked on a fix for JDK9 and came up with >>> a somewhat different approach (based on jdk9/dev): >>> >>> http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/webrev.00/hotspot/ >>> >>> http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/webrev.00/root >>> >>> To make it easy I already rebased Andrew's JDK8u31 patches to jdk9/dev >>> (due to that the webrev ended up with my username). >>> >>> http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/ahughes-webrev.00/hotspot/ >>> >>> >>> http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/ahughes-webrev.00/jdk >>> >>> >>> http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/ahughes-webrev.00/root >>> >>> >>> >>> I tested both approaches by building Hadoop (which triggered some >>> interesting bugs on various projects due to Jigsaw). >>> >>> Sorry for the github links, but I don't have an account at >>> cr.openjdk.java.net that I can use. I can provide tar files if >>> anyone is >>> willing to host those webrevs. >>> >>> Regards, >>> Tiago Daitx >>> From stefan.karlsson at oracle.com Thu Feb 19 08:56:35 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 19 Feb 2015 09:56:35 +0100 Subject: RFR: 8073388: Get rid of the dependency from handles.hpp to klass.hpp In-Reply-To: <54E59593.6040904@oracle.com> References: <54E45882.5030609@oracle.com> <54E59593.6040904@oracle.com> Message-ID: <54E5A543.5060508@oracle.com> On 2015-02-19 08:49, David Holmes wrote: > On 18/02/2015 7:16 PM, Stefan Karlsson wrote: >> Hi, >> >> Please review this patch to get rid of dependencies from handles.hpp to >> klass.hpp. This patch is extracted from a bigger patch to clean up some >> of our GC code dependencies in oop_iterate. >> >> http://cr.openjdk.java.net/~stefank/8073388/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8073388 > > Has the change from an inline definition to a non-inline definition > been cleared from a performance perspective? Do you mean the code in the assert? StefanK > > David > >> Thanks, >> StefanK From aph at redhat.com Thu Feb 19 08:58:13 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 19 Feb 2015 08:58:13 +0000 Subject: RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses In-Reply-To: <54E4FD45.5090106@oracle.com> References: <20150213230416.5E7B617FDAA@rebar.astron.com> <54DE8BB7.5050801@oracle.com> <54DE9140.3040604@oracle.com> <54E30C38.8000303@redhat.com> <54E31144.3040504@redhat.com> <54E314BF.3010205@redhat.com> <54E31677.1050209@redhat.com> <54E31CA6.6030609@redhat.com> <54E31DA0.2040901@redhat.com> <54E34EAF.6000802@redhat.com> <54E457E0.20408@redhat.com> <54E45842.9030102@redhat.com> <54E473D1.8000506@redhat.com> <54E4FD45.5090106@oracle.com> Message-ID: <54E5A5A5.1090305@redhat.com> On 18/02/15 20:59, Vladimir Kozlov wrote: > The code which eliminates MemBars for scalarized objects was added in jdk8: > > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/6f3fd5150b67 > > An other store barrier change was also pushed into jdk8: > > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/fcf521c3fbc6 > > I don't remember we did anything special with membars in jdk9. OK, so the question of why it isn't being removed in this case is interesting. We can look at that later. Andrew. From kirk at kodewerk.com Thu Feb 19 09:11:59 2015 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Thu, 19 Feb 2015 10:11:59 +0100 Subject: Strange safe-point banding behavior In-Reply-To: <54E59DE0.9030506@oracle.com> References: <20150213230416.5E7B617FDAA@rebar.astron.com> <54DE8BB7.5050801@oracle.com> <54DE9140.3040604@oracle.com> <54E30C38.8000303@redhat.com> <54E31144.3040504@redhat.com> <54E314BF.3010205@redhat.com> <54E31677.1050209@redhat.com> <54E31CA6.6030609@redhat.com> <54E31DA0.2040901@redhat.com> <54E34EAF.6000802@redhat.com> <0457F01A-9DE1-4049-BFA2-66C7F6CCAA0B@oracle.com> <54E38F4B.7060100@redhat.com> <54E39364.6030409@oracle.com> <54E462E1.5080009@redhat.com> <54E4652F.80600@redhat.com> <54E59DE0.9030506@oracle.com> Message-ID: <2F8DF5F9-6F0A-40A5-B389-3081449A0818@kodewerk.com> Hi David, Thanks, not sure how I missed this one. However, if GuaranteedSafepointInterval=1000ms, then how can we see application runtimes that are far greater than 1000ms? Regards, Kirk On Feb 19, 2015, at 9:25 AM, David Holmes wrote: > Hi Kirk, > > GuaranteedSafepointInterval has a default value of 1000ms. It's a diagnostic flag so you can try changing it. > > The reason for this is to ensure certain housekeeping tasks that must occur at a safepoint happen with some regularity eg monitor scavenging. > > David > > On 19/02/2015 6:10 PM, Kirk Pepperdine wrote: >> Hi all, >> >> I can?t say that I?ve taken this as far as I could as of yet but I think I can start to ask questions. >> >> I?ve seen what I call a banding artifact in a number of GC logs. The latest prompted me to investigate further. In the latest case Application runtime is being reported very frequently a ~1 second. It is being reported some what less frequently every ~2 seconds. So that means a safe point is being called for very frequently at these times so in amongst all of the other application runtime data points these points from a solid line in the chart. Now there are intermixed runtimes that go longer than 2 seconds and of course they are shorter than 1 second. >> >> When we looked at PrintSafepointStatistics we get ?no vm operation? which means sstats->_vmop_type == -1 which implies that the VM_Operation has not been set. >> >> Question is; why would a safepoint be called for with no VM_Operation? Looking at the code I would say it?s quite common. I?ve turned on safepoint tracing for other applications and have seen other even more bizarre banding patterns which all appear to be due to some regular behavior. >> >> This happens on all recent (and most likely older) versions of the JVM. >> >> Kind regards, >> Kirk >> From volker.simonis at gmail.com Thu Feb 19 09:54:27 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 19 Feb 2015 10:54:27 +0100 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <54E59F9F.4040604@oracle.com> References: <531E8309.2060206@oracle.com> <531ED06F.5040905@oracle.com> <107001365.11810418.1423839439509.JavaMail.zimbra@redhat.com> <54E183B8.5010301@oracle.com> <54E3B144.1090402@oracle.com> <958867570.14123662.1424262805099.JavaMail.zimbra@redhat.com> <1424314925.5112.149.camel@ocdc> <54E55A01.5020700@oracle.com> <54E56503.4090704@oracle.com> <54E59F9F.4040604@oracle.com> Message-ID: On Thu, Feb 19, 2015 at 9:32 AM, Erik Joelsson wrote: > Hello, > > The differences to the 8u patch: > > * -DABI_ELFv2 is not added to CFLAGS. I'm even not sure why we need this in 8. As far as I can see it is not used in the jdk sources. As far as I know we only use it in the hotspot sources, but for hotspot we already set it in make/linux/makefiles/ppc64.make > * Setting of INCLUDE_SA is not changed in jdk-options.m4. Is this because > it's already covered by other conditionals in jdk 9? > That's because we now have the SA for ppc64 in jdk9. Tiago is currently working on a downport to jdk8u. > I do not know if this is significant, but would appreciate a comment on the > reasoning. > > /Erik > > > On 2015-02-19 05:22, David Holmes wrote: >> >> Now hosted at: >> >> http://cr.openjdk.java.net/~dholmes/ahughes-rh1191652-jdk9-webrev/ >> >> David >> >> On 19/02/2015 1:35 PM, David Holmes wrote: >>> >>> Hi Tiago, >>> >>> Please email me the tar files and I will host it for you. >>> >>> Thanks, >>> David >>> >>> On 19/02/2015 1:02 PM, Tiago Sturmer Daitx wrote: >>>> >>>> On Wed, 2015-02-18 at 07:33 -0500, Andrew Hughes wrote: >>>>> >>>>> I now have these changes working on 8u31: >>>>> >>>>> http://cr.openjdk.java.net/~andrew/rh1191652/root >>>>> http://cr.openjdk.java.net/~andrew/rh1191652/jdk >>>>> >>>>> I can re-base these onto whichever OpenJDK 9 tree is appropriate and >>>>> push when >>>>> reviewed under the same bug as used for the HotSpot side. >>>> >>>> >>>> Concurrently to Andrew I also worked on a fix for JDK9 and came up with >>>> a somewhat different approach (based on jdk9/dev): >>>> >>>> >>>> http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/webrev.00/hotspot/ >>>> http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/webrev.00/root >>>> >>>> To make it easy I already rebased Andrew's JDK8u31 patches to jdk9/dev >>>> (due to that the webrev ended up with my username). >>>> >>>> >>>> http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/ahughes-webrev.00/hotspot/ >>>> >>>> >>>> http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/ahughes-webrev.00/jdk >>>> >>>> >>>> http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/ahughes-webrev.00/root >>>> >>>> >>>> I tested both approaches by building Hadoop (which triggered some >>>> interesting bugs on various projects due to Jigsaw). >>>> >>>> Sorry for the github links, but I don't have an account at >>>> cr.openjdk.java.net that I can use. I can provide tar files if anyone is >>>> willing to host those webrevs. >>>> >>>> Regards, >>>> Tiago Daitx >>>> > From goetz.lindenmaier at sap.com Thu Feb 19 10:34:41 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 19 Feb 2015 10:34:41 +0000 Subject: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. In-Reply-To: <65A32AAF-F514-4E10-AF4A-DA04F41F57BF@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CF9615F@DEWDFEMB12A.global.corp.sap> <70B02DBE-E246-45F9-89C7-898881B0C69A@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF96468@DEWDFEMB12A.global.corp.sap> <65A32AAF-F514-4E10-AF4A-DA04F41F57BF@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CF967DF@DEWDFEMB12A.global.corp.sap> Hi Kim, os_linux.cpp: - I adapted the type to ptrdiff_t. - I implemented error handling as where current directory can not be read. g1/concurrentMark.cpp You're right, that #define is not nice. And yes, the code you propose is better. But here I don't feel like changing it, as I don't know what was intended by the code. Is it used at all? Does Oracle have a test that depends on it? Anyways, if the default is 0, it's off per default if somebody enables G1StressConcRegionFreeing, which I also consider a strange behaviour. The code was added with 6977804: G1: remove the zero-filling thread: http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/0fa27f37d4d4 I can't find the review thread in the gc mail archive. There is only the submit: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2011-January/002243.html jvmtiRedefineClasses.cpp Changed to u1 and removed comment. The value never exceeds 255. u1 is used at other places for frame_type, too. So I think it's good to change it to u1. The new webrev is here: http://cr.openjdk.java.net/~goetz/webrevs/8073315-wUnsign/webrev.03/ Thanks for the detailed review! Best regards, Goetz. -----Original Message----- From: Kim Barrett [mailto:kim.barrett at oracle.com] Sent: Donnerstag, 19. Februar 2015 02:21 To: Lindenmaier, Goetz Cc: hotspot-dev Source Developers Subject: Re: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. On Feb 18, 2015, at 5:53 AM, Lindenmaier, Goetz wrote: > > http://cr.openjdk.java.net/~goetz/webrevs/8073315-wUnsign/webrev.02/ I wonder how many of the changes being made here are the result of code that originally used int for some counters, indices, or size values, and was later changed to use an appropriate unsigned type. ------------------------------------------------------------------------------ src/os/linux/vm/os_linux.cpp 3751 size_t top_overlap = requested_addr + (bytes + gap) - base[i]; 3752 if (top_overlap >= 0 && top_overlap < bytes) { => 3751 size_t top_overlap = requested_addr + (bytes + gap) - base[i]; 3752 if (requested_addr + (bytes + gap) >= base[i] && // Check underflow. 3753 top_overlap < bytes) { I believe the real problem here is the type of top_overlap, which should be ptrdiff_t rather than size_t. I *think* that if just that type change was made, that the rest would be fine. Similarly a few lines later for bottom_overlap. ------------------------------------------------------------------------------ src/os/linux/vm/os_linux.cpp 6028 int written; ... 6050 if ((written >= 0) && ((size_t)written < bufferSize) && 6051 (pid_pos == NULL) && (core_pattern[0] != '|')) { The real problem here is the value of "written", which is the result of a call to jio_snprintf, is not being checked for failure. Clearly "written" should be of signed type because of its value, but the other changes here just continue to mask the lack of error checking. ------------------------------------------------------------------------------ src/share/vm/classfile/systemDictionary.cpp 1371 for (uintx it = 0; it < GCExpandToAllocateDelayMillis; it++){} I'll grant you that one as a nice find and deletion. (Although the code is "harmless", since the compiler should optimize it away.) ------------------------------------------------------------------------------ src/share/vm/gc_implementation/g1/concurrentMark.cpp 2173 #ifndef PRODUCT 2174 if (G1StressConcRegionFreeing) { 2175 for (uintx i = 0; i < G1StressConcRegionFreeingDelayMillis; ++i) { 2176 os::sleep(Thread::current(), (jlong) 1, false); 2177 } 2178 } 2179 #endif The #ifndef here is the kind of workaround for the warning that I really dislike. But why isn't this just if (G1StressConcRegionFreeing) { os::sleep(Thread::current(), G1StressConcRegionFreeingDelayMillis, false); } or maybe even "true" for the third argument to sleep, to allow it to be interruptable. ----------------------------------------------------------------------------- src/share/vm/prims/jvmtiRedefineClasses.cpp 2908 if (frame_type >= 0 && frame_type <= 63) { => 2908 if (frame_type <= 63) { There is a comment a few lines back: 2897 // The Linux compiler does not like frame_type to be u1 or u2. It 2898 // issues the following warning for the first if-statement below: 2899 // 2900 // "warning: comparison is always true due to limited range of data type" It looks like someone got that warning and tried to work around it in a different way, without really understanding what was going on. Eliminating the (frame >= 0) expression is ok, but the comment should be eliminated and perhaps consider changing the type for frame_type to u1? I'm less sure about the type change. ------------------------------------------------------------------------------ From david.holmes at oracle.com Thu Feb 19 10:38:13 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 19 Feb 2015 20:38:13 +1000 Subject: Strange safe-point banding behavior In-Reply-To: <2F8DF5F9-6F0A-40A5-B389-3081449A0818@kodewerk.com> References: <20150213230416.5E7B617FDAA@rebar.astron.com> <54DE8BB7.5050801@oracle.com> <54DE9140.3040604@oracle.com> <54E30C38.8000303@redhat.com> <54E31144.3040504@redhat.com> <54E314BF.3010205@redhat.com> <54E31677.1050209@redhat.com> <54E31CA6.6030609@redhat.com> <54E31DA0.2040901@redhat.com> <54E34EAF.6000802@redhat.com> <0457F01A-9DE1-4049-BFA2-66C7F6CCAA0B@oracle.com> <54E38F4B.7060100@redhat.com> <54E39364.6030409@oracle.com> <54E462E1.5080009@redhat.com> <54E4652F.80600@redhat.com> <54E59DE0.9030506@oracle.com> <2F8DF5F9-6F0A-40A5-B389-3081449A0818@kodewerk.com> Message-ID: <54E5BD15.8050802@oracle.com> On 19/02/2015 7:11 PM, Kirk Pepperdine wrote: > Hi David, > > Thanks, not sure how I missed this one. However, if GuaranteedSafepointInterval=1000ms, then how can we see application runtimes that are far greater than 1000ms? You need to look at exactly what those timers actually measure - it's been a while since I have done so - I'm not sure what "application run time" actually is. David > Regards, > Kirk > > On Feb 19, 2015, at 9:25 AM, David Holmes wrote: > >> Hi Kirk, >> >> GuaranteedSafepointInterval has a default value of 1000ms. It's a diagnostic flag so you can try changing it. >> >> The reason for this is to ensure certain housekeeping tasks that must occur at a safepoint happen with some regularity eg monitor scavenging. >> >> David >> >> On 19/02/2015 6:10 PM, Kirk Pepperdine wrote: >>> Hi all, >>> >>> I can?t say that I?ve taken this as far as I could as of yet but I think I can start to ask questions. >>> >>> I?ve seen what I call a banding artifact in a number of GC logs. The latest prompted me to investigate further. In the latest case Application runtime is being reported very frequently a ~1 second. It is being reported some what less frequently every ~2 seconds. So that means a safe point is being called for very frequently at these times so in amongst all of the other application runtime data points these points from a solid line in the chart. Now there are intermixed runtimes that go longer than 2 seconds and of course they are shorter than 1 second. >>> >>> When we looked at PrintSafepointStatistics we get ?no vm operation? which means sstats->_vmop_type == -1 which implies that the VM_Operation has not been set. >>> >>> Question is; why would a safepoint be called for with no VM_Operation? Looking at the code I would say it?s quite common. I?ve turned on safepoint tracing for other applications and have seen other even more bizarre banding patterns which all appear to be due to some regular behavior. >>> >>> This happens on all recent (and most likely older) versions of the JVM. >>> >>> Kind regards, >>> Kirk >>> > From david.holmes at oracle.com Thu Feb 19 10:39:34 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 19 Feb 2015 20:39:34 +1000 Subject: RFR: 8073388: Get rid of the dependency from handles.hpp to klass.hpp In-Reply-To: <54E5A543.5060508@oracle.com> References: <54E45882.5030609@oracle.com> <54E59593.6040904@oracle.com> <54E5A543.5060508@oracle.com> Message-ID: <54E5BD66.3020904@oracle.com> On 19/02/2015 6:56 PM, Stefan Karlsson wrote: > > On 2015-02-19 08:49, David Holmes wrote: >> On 18/02/2015 7:16 PM, Stefan Karlsson wrote: >>> Hi, >>> >>> Please review this patch to get rid of dependencies from handles.hpp to >>> klass.hpp. This patch is extracted from a bigger patch to clean up some >>> of our GC code dependencies in oop_iterate. >>> >>> http://cr.openjdk.java.net/~stefank/8073388/webrev.01/ >>> https://bugs.openjdk.java.net/browse/JDK-8073388 >> >> Has the change from an inline definition to a non-inline definition >> been cleared from a performance perspective? > > Do you mean the code in the assert? No, sorry, replied to the wrong thread by mistake. David > StefanK > >> >> David >> >>> Thanks, >>> StefanK > From david.holmes at oracle.com Thu Feb 19 10:42:42 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 19 Feb 2015 20:42:42 +1000 Subject: RFR: 8073387: Move VerifyOopClosures out from genOopClosures.hpp In-Reply-To: <54E448DA.4060406@oracle.com> References: <54E448DA.4060406@oracle.com> Message-ID: <54E5BE22.2030307@oracle.com> On 18/02/2015 6:10 PM, Stefan Karlsson wrote: > Hi, > > Please review this patch to move VerifyOopClosures out from > genOopClosures.hpp. This way users of VerifyOopClosures don't have to > include genOopClosures.hpp anymore. The implementation of > VerifyOopClosures::do_oop_work is placed in oop.cpp, where the other > VerifyOopClosure functions are located. > > http://cr.openjdk.java.net/~stefank/8073387/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8073387 This is the thread in which I intended to say: >> Has the change from an inline definition to a non-inline definition >> been cleared from a performance perspective? Thanks, David > Thanks, > StefanK From stefan.karlsson at oracle.com Thu Feb 19 11:59:36 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 19 Feb 2015 12:59:36 +0100 Subject: RFR: 8073387: Move VerifyOopClosures out from genOopClosures.hpp In-Reply-To: <54E5BE22.2030307@oracle.com> References: <54E448DA.4060406@oracle.com> <54E5BE22.2030307@oracle.com> Message-ID: <54E5D028.7050507@oracle.com> On 2015-02-19 11:42, David Holmes wrote: > On 18/02/2015 6:10 PM, Stefan Karlsson wrote: >> Hi, >> >> Please review this patch to move VerifyOopClosures out from >> genOopClosures.hpp. This way users of VerifyOopClosures don't have to >> include genOopClosures.hpp anymore. The implementation of >> VerifyOopClosures::do_oop_work is placed in oop.cpp, where the other >> VerifyOopClosure functions are located. >> >> http://cr.openjdk.java.net/~stefank/8073387/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8073387 > > This is the thread in which I intended to say: > > >> Has the change from an inline definition to a non-inline definition > >> been cleared from a performance perspective? The code is setup so that the compiler would be able to inline the function: template void VerifyOopClosure::do_oop_work(T* p) { oop obj = oopDesc::load_decode_heap_oop(p); guarantee(obj->is_oop_or_null(), err_msg("invalid oop: " INTPTR_FORMAT, p2i((oopDesc*) obj))); } void VerifyOopClosure::do_oop(oop* p) { VerifyOopClosure::do_oop_work(p); } void VerifyOopClosure::do_oop(narrowOop* p) { VerifyOopClosure::do_oop_work(p); } and since this is verification code I don't think we need to worry too much about a potential extra call. StefanK > > Thanks, > David > >> Thanks, >> StefanK From denis.kononenko at oracle.com Thu Feb 19 12:42:37 2015 From: denis.kononenko at oracle.com (denis kononenko) Date: Thu, 19 Feb 2015 15:42:37 +0300 Subject: RFR (S): 8072687: Update OutputAnalyzer to work with files In-Reply-To: <54E461BC.30104@oracle.com> References: <54E36511.7010608@oracle.com> <65BF10CE-582D-448E-B5DA-5544276C0E16@oracle.com> <54E38EEC.9020001@oracle.com> <54E461BC.30104@oracle.com> Message-ID: <54E5DA3D.6010909@oracle.com> Hi Dima, Staffan, I've fixed the review findings, here's a new webrev link: http://cr.openjdk.java.net/~dfazunen/dkononen/8072687/webrev.01/ I found that CompressedClassSpaceSizeInJmapHeap.java could be improved without use of the new proposed functionality. The OutputAnalyzer works perfectly with Process objects and there's no need to capture stderr/stdout into two separate files as it's already done by the OutputAnalyzer. So I simply removed all stuff which duplicated this functionality. All necessary tests were performed. Thank you, Denis. On 18.02.2015 12:56, Dmitry Fazunenko wrote: > > On 18.02.2015 12:34, Staffan Larsen wrote: >> I can only see one usage of the OutputAnalyzer(String) constructor >> and that is in >> test/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java. That usage >> does not require both stdout and stderr to be set. >> >> In fact, that usage would benefit from the new constructor that takes >> a File. >> >> I suggest we do: >> >> - Change OutputAnalyzer(String) to set stdout to the input string and >> stderr to the empty string "" >> - Update CompressedClassSpaceSizeInJmapHeap.java to use the new >> OutputAnalyzer(File) constructor > > sounds good to me. > > -- Dima > >> >> Thanks, >> /Staffan >> >> >>> On 17 feb 2015, at 19:56, Dmitry Fazunenko >>> wrote: >>> >>> Hi Staffan, >>> >>> For me it's not clear why the constructor taking a String argument >>> sets both stderr and stdout to the same value... >>> But I don't see any reason to update this behavior and break >>> compatibility. >>> So I would agree, that the new constructor should be consistent with >>> the existing one and set both out and err to the same string. >>> >>> Thanks, >>> Dima >>> >>> >>> >>> On 17.02.2015 20:39, Staffan Larsen wrote: >>>> There is constructor that takes a String argument. That constructor >>>> sets both stderr and stdout to that same String. Your constructor >>>> behaves differently and only sets stdout to the contents of the >>>> file. I have no idea why the existing constructor does what it >>>> does, but it would be good if the new and old had the same >>>> behavior. I haven?t looked at the use cases for the existing >>>> constructor. >>>> >>>> /S >>>> >>>>> On 17 feb 2015, at 16:58, denis kononenko >>>>> wrote: >>>>> >>>>> Hi All, >>>>> >>>>> Could you please review a small change of OutputAnalyzer class >>>>> from testlibrary. >>>>> >>>>> Webrev link: >>>>> http://cr.openjdk.java.net/~dfazunen/dkononen/8072687/webrev.00/ >>>>> Bug id: https://bugs.openjdk.java.net/browse/JDK-8072687 >>>>> Testing: automated >>>>> Description: >>>>> >>>>> The purpose of this change is to extend the functionality of >>>>> OutputAnalyzer by adding ability to read output from a file. >>>>> Sometimes we have to analyze output written to a file (test data, >>>>> logs, etc.). In that case we have to read it as a string and pass >>>>> it into OutputAnalyzer's constructor (it could be done in several >>>>> different ways). It would be very convenient to put this code >>>>> directly into OutputAnalyzer. This would allow to make further >>>>> tests code more cleaner and less error prone. >>>>> >>>>> The change consist of two parts: >>>>> 1) The change: OutputAnalyzer.java, added a new constructor that >>>>> accepts File; >>>>> 2) The tests: FileOutputAnalyzerTests.java, very basic tests on >>>>> reading functionality. >>>>> >>>>> Thank you, >>>>> Denis. >>>>> >>>>> > From kirk at kodewerk.com Thu Feb 19 12:46:27 2015 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Thu, 19 Feb 2015 13:46:27 +0100 Subject: Strange safe-point banding behavior In-Reply-To: <54E5BD15.8050802@oracle.com> References: <20150213230416.5E7B617FDAA@rebar.astron.com> <54DE8BB7.5050801@oracle.com> <54DE9140.3040604@oracle.com> <54E30C38.8000303@redhat.com> <54E31144.3040504@redhat.com> <54E314BF.3010205@redhat.com> <54E31677.1050209@redhat.com> <54E31CA6.6030609@redhat.com> <54E31DA0.2040901@redhat.com> <54E34EAF.6000802@redhat.com> <0457F01A-9DE1-4049-BFA2-66C7F6CCAA0B@oracle.com> <54E38F4B.7060100@redhat.com> <54E39364.6030409@oracle.com> <54E462E1.5080009@redhat.com> <54E4652F.80600@redhat.com> <54E59DE0.9030506@oracle.com> <2F8DF5F9-6F0A-40A5-B389-3081449A0818@kodewerk.com> <54E5BD15.8050802@oracle.com> Message-ID: <1E803311-D142-48F8-AD19-2E115160EC27@kodewerk.com> Hi David, >> >> Thanks, not sure how I missed this one. However, if GuaranteedSafepointInterval=1000ms, then how can we see application runtimes that are far greater than 1000ms? > > You need to look at exactly what those timers actually measure - it's been a while since I have done so - I'm not sure what "application run time" actually is. Indeed, I will look. What I can say is; these timings are perfectly interwoven with safepoints and not all of the measurements are cut off at ~1000ms, just enough of them to make pretty pictures of the charts. Thanks, Kirk > > David > >> Regards, >> Kirk >> >> On Feb 19, 2015, at 9:25 AM, David Holmes wrote: >> >>> Hi Kirk, >>> >>> GuaranteedSafepointInterval has a default value of 1000ms. It's a diagnostic flag so you can try changing it. >>> >>> The reason for this is to ensure certain housekeeping tasks that must occur at a safepoint happen with some regularity eg monitor scavenging. >>> >>> David >>> >>> On 19/02/2015 6:10 PM, Kirk Pepperdine wrote: >>>> Hi all, >>>> >>>> I can?t say that I?ve taken this as far as I could as of yet but I think I can start to ask questions. >>>> >>>> I?ve seen what I call a banding artifact in a number of GC logs. The latest prompted me to investigate further. In the latest case Application runtime is being reported very frequently a ~1 second. It is being reported some what less frequently every ~2 seconds. So that means a safe point is being called for very frequently at these times so in amongst all of the other application runtime data points these points from a solid line in the chart. Now there are intermixed runtimes that go longer than 2 seconds and of course they are shorter than 1 second. >>>> >>>> When we looked at PrintSafepointStatistics we get ?no vm operation? which means sstats->_vmop_type == -1 which implies that the VM_Operation has not been set. >>>> >>>> Question is; why would a safepoint be called for with no VM_Operation? Looking at the code I would say it?s quite common. I?ve turned on safepoint tracing for other applications and have seen other even more bizarre banding patterns which all appear to be due to some regular behavior. >>>> >>>> This happens on all recent (and most likely older) versions of the JVM. >>>> >>>> Kind regards, >>>> Kirk >>>> >> From staffan.larsen at oracle.com Thu Feb 19 14:17:06 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 19 Feb 2015 15:17:06 +0100 Subject: RFR (S): 8072687: Update OutputAnalyzer to work with files In-Reply-To: <54E5DA3D.6010909@oracle.com> References: <54E36511.7010608@oracle.com> <65BF10CE-582D-448E-B5DA-5544276C0E16@oracle.com> <54E38EEC.9020001@oracle.com> <54E461BC.30104@oracle.com> <54E5DA3D.6010909@oracle.com> Message-ID: <802FB5B7-FC9F-47DE-B8DD-69225BE4FCE3@oracle.com> Looks good! Thanks, /Staffan > On 19 feb 2015, at 13:42, denis kononenko wrote: > > > Hi Dima, Staffan, > > I've fixed the review findings, here's a new webrev link: > > http://cr.openjdk.java.net/~dfazunen/dkononen/8072687/webrev.01/ > > I found that CompressedClassSpaceSizeInJmapHeap.java could be improved without use of the new proposed functionality. The OutputAnalyzer works perfectly with Process objects and there's no need to capture stderr/stdout into two separate files as it's already done by the OutputAnalyzer. So I simply removed all stuff which duplicated this functionality. > All necessary tests were performed. > > Thank you, > Denis. > > On 18.02.2015 12:56, Dmitry Fazunenko wrote: >> >> On 18.02.2015 12:34, Staffan Larsen wrote: >>> I can only see one usage of the OutputAnalyzer(String) constructor and that is in test/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java. That usage does not require both stdout and stderr to be set. >>> >>> In fact, that usage would benefit from the new constructor that takes a File. >>> >>> I suggest we do: >>> >>> - Change OutputAnalyzer(String) to set stdout to the input string and stderr to the empty string "" >>> - Update CompressedClassSpaceSizeInJmapHeap.java to use the new OutputAnalyzer(File) constructor >> >> sounds good to me. >> >> -- Dima >> >>> >>> Thanks, >>> /Staffan >>> >>> >>>> On 17 feb 2015, at 19:56, Dmitry Fazunenko wrote: >>>> >>>> Hi Staffan, >>>> >>>> For me it's not clear why the constructor taking a String argument sets both stderr and stdout to the same value... >>>> But I don't see any reason to update this behavior and break compatibility. >>>> So I would agree, that the new constructor should be consistent with the existing one and set both out and err to the same string. >>>> >>>> Thanks, >>>> Dima >>>> >>>> >>>> >>>> On 17.02.2015 20:39, Staffan Larsen wrote: >>>>> There is constructor that takes a String argument. That constructor sets both stderr and stdout to that same String. Your constructor behaves differently and only sets stdout to the contents of the file. I have no idea why the existing constructor does what it does, but it would be good if the new and old had the same behavior. I haven?t looked at the use cases for the existing constructor. >>>>> >>>>> /S >>>>> >>>>>> On 17 feb 2015, at 16:58, denis kononenko wrote: >>>>>> >>>>>> Hi All, >>>>>> >>>>>> Could you please review a small change of OutputAnalyzer class from testlibrary. >>>>>> >>>>>> Webrev link: http://cr.openjdk.java.net/~dfazunen/dkononen/8072687/webrev.00/ >>>>>> Bug id: https://bugs.openjdk.java.net/browse/JDK-8072687 >>>>>> Testing: automated >>>>>> Description: >>>>>> >>>>>> The purpose of this change is to extend the functionality of OutputAnalyzer by adding ability to read output from a file. Sometimes we have to analyze output written to a file (test data, logs, etc.). In that case we have to read it as a string and pass it into OutputAnalyzer's constructor (it could be done in several different ways). It would be very convenient to put this code directly into OutputAnalyzer. This would allow to make further tests code more cleaner and less error prone. >>>>>> >>>>>> The change consist of two parts: >>>>>> 1) The change: OutputAnalyzer.java, added a new constructor that accepts File; >>>>>> 2) The tests: FileOutputAnalyzerTests.java, very basic tests on reading functionality. >>>>>> >>>>>> Thank you, >>>>>> Denis. >>>>>> >>>>>> >> > From gnu.andrew at redhat.com Thu Feb 19 15:51:37 2015 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 19 Feb 2015 10:51:37 -0500 (EST) Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: References: <54E3B144.1090402@oracle.com> <958867570.14123662.1424262805099.JavaMail.zimbra@redhat.com> <1424314925.5112.149.camel@ocdc> <54E55A01.5020700@oracle.com> <54E56503.4090704@oracle.com> <54E59F9F.4040604@oracle.com> Message-ID: <30414160.15239570.1424361097941.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On Thu, Feb 19, 2015 at 9:32 AM, Erik Joelsson > wrote: > > Hello, > > > > The differences to the 8u patch: > > > > * -DABI_ELFv2 is not added to CFLAGS. > > I'm even not sure why we need this in 8. As far as I can see it is not > used in the jdk sources. > As far as I know we only use it in the hotspot sources, but for > hotspot we already set it in make/linux/makefiles/ppc64.make > It's in the 7 JDK build, which is currently: ifeq ($(ARCH),ppc64) ifeq ($(OPENJDK_TARGET_CPU_ENDIAN),big) CFLAGS_REQUIRED_ppc64 += -m64 -D_BIG_ENDIAN LDFLAGS_COMMON_ppc64 += -m64 -L/lib64 -Wl,-melf64ppc else ifeq ($(OPENJDK_TARGET_CPU_ENDIAN),little) CFLAGS_REQUIRED_ppc64 += -D_LITTLE_ENDIAN -DABI_ELFv2 else $(error Expected big/little for ARCH=ppc64, got OPENJDK_TARGET_CPU_ENDIAN=$(OPENJDK_TARGET_CPU_ENDIAN)) endif endif in jdk/make/common/Defs-linux.gmk. My 7 patch simplifies it to: CFLAGS_REQUIRED_ppc64 += -m64 -D_BIG_ENDIAN LDFLAGS_COMMON_ppc64 += -m64 -L/lib64 -Wl,-melf64ppc CFLAGS_REQUIRED_ppc64le += -D_LITTLE_ENDIAN -DABI_ELFv2 I was wondering why it wasn't used in 8 so far and assumed it might be an unintentional omission in 8. But, if not, it should be removed from both to keep them in sync. Is it possible that it is relevant to system headers rather than JDK code? > > * Setting of INCLUDE_SA is not changed in jdk-options.m4. Is this because > > it's already covered by other conditionals in jdk 9? > > > > That's because we now have the SA for ppc64 in jdk9. Tiago is > currently working on a downport to jdk8u. > Yeah, this was simply an extension of the if clause to make sure ppc64le was still included. Previously, it would have been handled by the ppc64 test. > > I do not know if this is significant, but would appreciate a comment on the > > reasoning. > > > > /Erik > > > > > > On 2015-02-19 05:22, David Holmes wrote: > >> > >> Now hosted at: > >> > >> http://cr.openjdk.java.net/~dholmes/ahughes-rh1191652-jdk9-webrev/ > >> > >> David > >> > >> On 19/02/2015 1:35 PM, David Holmes wrote: > >>> > >>> Hi Tiago, > >>> > >>> Please email me the tar files and I will host it for you. > >>> > >>> Thanks, > >>> David > >>> > >>> On 19/02/2015 1:02 PM, Tiago Sturmer Daitx wrote: > >>>> > >>>> On Wed, 2015-02-18 at 07:33 -0500, Andrew Hughes wrote: > >>>>> > >>>>> I now have these changes working on 8u31: > >>>>> > >>>>> http://cr.openjdk.java.net/~andrew/rh1191652/root > >>>>> http://cr.openjdk.java.net/~andrew/rh1191652/jdk > >>>>> > >>>>> I can re-base these onto whichever OpenJDK 9 tree is appropriate and > >>>>> push when > >>>>> reviewed under the same bug as used for the HotSpot side. > >>>> > >>>> > >>>> Concurrently to Andrew I also worked on a fix for JDK9 and came up with > >>>> a somewhat different approach (based on jdk9/dev): > >>>> > >>>> > >>>> http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/webrev.00/hotspot/ > >>>> http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/webrev.00/root > >>>> > >>>> To make it easy I already rebased Andrew's JDK8u31 patches to jdk9/dev > >>>> (due to that the webrev ended up with my username). > >>>> > >>>> > >>>> http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/ahughes-webrev.00/hotspot/ > >>>> > >>>> > >>>> http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/ahughes-webrev.00/jdk > >>>> > >>>> > >>>> http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/ahughes-webrev.00/root > >>>> > >>>> > >>>> I tested both approaches by building Hadoop (which triggered some > >>>> interesting bugs on various projects due to Jigsaw). > >>>> > >>>> Sorry for the github links, but I don't have an account at > >>>> cr.openjdk.java.net that I can use. I can provide tar files if anyone is > >>>> willing to host those webrevs. > >>>> > >>>> Regards, > >>>> Tiago Daitx > >>>> > > > -- Andrew :) 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 PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From gnu.andrew at redhat.com Thu Feb 19 16:30:37 2015 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 19 Feb 2015 11:30:37 -0500 (EST) Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <1424314925.5112.149.camel@ocdc> References: <531ED06F.5040905@oracle.com> <107001365.11810418.1423839439509.JavaMail.zimbra@redhat.com> <54E183B8.5010301@oracle.com> <54E3B144.1090402@oracle.com> <958867570.14123662.1424262805099.JavaMail.zimbra@redhat.com> <1424314925.5112.149.camel@ocdc> Message-ID: <1335332673.15280032.1424363437716.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On Wed, 2015-02-18 at 07:33 -0500, Andrew Hughes wrote: > > I now have these changes working on 8u31: > > > > http://cr.openjdk.java.net/~andrew/rh1191652/root > > http://cr.openjdk.java.net/~andrew/rh1191652/jdk > > > > I can re-base these onto whichever OpenJDK 9 tree is appropriate and push > > when > > reviewed under the same bug as used for the HotSpot side. > > Concurrently to Andrew I also worked on a fix for JDK9 and came up with > a somewhat different approach (based on jdk9/dev): > > http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/webrev.00/hotspot/ > http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/webrev.00/root > Ah, I see you took a more conservative approach. I prefer to make ppc64le explicit in the JDK to future-proof us from any further problems. The main reason for re-using ppc64 in HotSpot is just to avoid duplicating makefiles. > To make it easy I already rebased Andrew's JDK8u31 patches to jdk9/dev > (due to that the webrev ended up with my username). > > http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/ahughes-webrev.00/hotspot/ > http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/ahughes-webrev.00/jdk > http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/ahughes-webrev.00/root > Thanks for this. I got some way to getting a 9 build going, but not there yet :( > I tested both approaches by building Hadoop (which triggered some > interesting bugs on various projects due to Jigsaw). > > Sorry for the github links, but I don't have an account at > cr.openjdk.java.net that I can use. I can provide tar files if anyone is > willing to host those webrevs. > > Regards, > Tiago Daitx > > -- Andrew :) 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 PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From igor.veresov at oracle.com Thu Feb 19 20:41:17 2015 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 19 Feb 2015 12:41:17 -0800 Subject: [8u] 8072753 Nondeterministic wrong answer on arithmetic Message-ID: <19C53D5F-1BC9-4006-826D-543747D64746@oracle.com> Webrev: http://cr.openjdk.java.net/~iveresov/8072753/webrev.00/ JDK9 changeset: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/f1b92b73e6aa JBS: https://bugs.openjdk.java.net/browse/JDK-8072753 The change imports cleanly. Thanks, igor From vladimir.kozlov at oracle.com Thu Feb 19 20:45:52 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 19 Feb 2015 12:45:52 -0800 Subject: [8u] 8072753 Nondeterministic wrong answer on arithmetic In-Reply-To: <19C53D5F-1BC9-4006-826D-543747D64746@oracle.com> References: <19C53D5F-1BC9-4006-826D-543747D64746@oracle.com> Message-ID: <54E64B80.1080901@oracle.com> Good. Thanks, Vladimir On 2/19/15 12:41 PM, Igor Veresov wrote: > Webrev: http://cr.openjdk.java.net/~iveresov/8072753/webrev.00/ > JDK9 changeset: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/f1b92b73e6aa > JBS: https://bugs.openjdk.java.net/browse/JDK-8072753 > > The change imports cleanly. > > Thanks, > igor > From igor.ignatyev at oracle.com Thu Feb 19 21:07:24 2015 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 20 Feb 2015 00:07:24 +0300 Subject: RFR (S): 8072687: Update OutputAnalyzer to work with files In-Reply-To: <802FB5B7-FC9F-47DE-B8DD-69225BE4FCE3@oracle.com> References: <54E36511.7010608@oracle.com> <65BF10CE-582D-448E-B5DA-5544276C0E16@oracle.com> <54E38EEC.9020001@oracle.com> <54E461BC.30104@oracle.com> <54E5DA3D.6010909@oracle.com> <802FB5B7-FC9F-47DE-B8DD-69225BE4FCE3@oracle.com> Message-ID: <54E6508C.70703@oracle.com> Hi Denis, FileOutputAnalyzerTest: 0. why don't you use Utils.NEW_LINE or String.format(...%n...) instead of > 46 String expected = > 47 "line1" + System.lineSeparator() > 48 + "line2" + System.lineSeparator() > 49 + "line3"; 1. wrong indent on 53. 2. could you pleas use Asserts.assertEquals to replace lines 56--61, 67--71? lines 63--66 could be also replaced by Asserts.assertTrue 3. since you expect FileNotFoundException, shouldn't you use it in catch clause? 4. what if 'non-existing.file' exists? could you please check it in the very begging of test case? OutputAnalyzerTest: 0. the same as FileOutputAnalyzerTest#2 Thanks, Igor On 02/19/2015 05:17 PM, Staffan Larsen wrote: > Looks good! > > Thanks, > /Staffan > >> On 19 feb 2015, at 13:42, denis kononenko wrote: >> >> >> Hi Dima, Staffan, >> >> I've fixed the review findings, here's a new webrev link: >> >> http://cr.openjdk.java.net/~dfazunen/dkononen/8072687/webrev.01/ >> >> I found that CompressedClassSpaceSizeInJmapHeap.java could be improved without use of the new proposed functionality. The OutputAnalyzer works perfectly with Process objects and there's no need to capture stderr/stdout into two separate files as it's already done by the OutputAnalyzer. So I simply removed all stuff which duplicated this functionality. >> All necessary tests were performed. >> >> Thank you, >> Denis. >> >> On 18.02.2015 12:56, Dmitry Fazunenko wrote: >>> >>> On 18.02.2015 12:34, Staffan Larsen wrote: >>>> I can only see one usage of the OutputAnalyzer(String) constructor and that is in test/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java. That usage does not require both stdout and stderr to be set. >>>> >>>> In fact, that usage would benefit from the new constructor that takes a File. >>>> >>>> I suggest we do: >>>> >>>> - Change OutputAnalyzer(String) to set stdout to the input string and stderr to the empty string "" >>>> - Update CompressedClassSpaceSizeInJmapHeap.java to use the new OutputAnalyzer(File) constructor >>> >>> sounds good to me. >>> >>> -- Dima >>> >>>> >>>> Thanks, >>>> /Staffan >>>> >>>> >>>>> On 17 feb 2015, at 19:56, Dmitry Fazunenko wrote: >>>>> >>>>> Hi Staffan, >>>>> >>>>> For me it's not clear why the constructor taking a String argument sets both stderr and stdout to the same value... >>>>> But I don't see any reason to update this behavior and break compatibility. >>>>> So I would agree, that the new constructor should be consistent with the existing one and set both out and err to the same string. >>>>> >>>>> Thanks, >>>>> Dima >>>>> >>>>> >>>>> >>>>> On 17.02.2015 20:39, Staffan Larsen wrote: >>>>>> There is constructor that takes a String argument. That constructor sets both stderr and stdout to that same String. Your constructor behaves differently and only sets stdout to the contents of the file. I have no idea why the existing constructor does what it does, but it would be good if the new and old had the same behavior. I haven?t looked at the use cases for the existing constructor. >>>>>> >>>>>> /S >>>>>> >>>>>>> On 17 feb 2015, at 16:58, denis kononenko wrote: >>>>>>> >>>>>>> Hi All, >>>>>>> >>>>>>> Could you please review a small change of OutputAnalyzer class from testlibrary. >>>>>>> >>>>>>> Webrev link: http://cr.openjdk.java.net/~dfazunen/dkononen/8072687/webrev.00/ >>>>>>> Bug id: https://bugs.openjdk.java.net/browse/JDK-8072687 >>>>>>> Testing: automated >>>>>>> Description: >>>>>>> >>>>>>> The purpose of this change is to extend the functionality of OutputAnalyzer by adding ability to read output from a file. Sometimes we have to analyze output written to a file (test data, logs, etc.). In that case we have to read it as a string and pass it into OutputAnalyzer's constructor (it could be done in several different ways). It would be very convenient to put this code directly into OutputAnalyzer. This would allow to make further tests code more cleaner and less error prone. >>>>>>> >>>>>>> The change consist of two parts: >>>>>>> 1) The change: OutputAnalyzer.java, added a new constructor that accepts File; >>>>>>> 2) The tests: FileOutputAnalyzerTests.java, very basic tests on reading functionality. >>>>>>> >>>>>>> Thank you, >>>>>>> Denis. >>>>>>> >>>>>>> >>> >> > From daniel.daugherty at oracle.com Thu Feb 19 21:51:32 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 19 Feb 2015 14:51:32 -0700 Subject: RFR: 7143664: Clean up OrderAccess implementations and usage In-Reply-To: <54DD3C91.3030404@oracle.com> References: <54C1EBD3.1000905@oracle.com> <54C1F3D8.5040507@oracle.com> <54C2C1EA.5020507@oracle.com> <54C87D16.40601@oracle.com> <54C9674C.2080600@oracle.com> <54D85E4F.5020305@oracle.com> <54DC0416.5070105@oracle.com> <54DD3C91.3030404@oracle.com> Message-ID: <54E65AE4.50004@oracle.com> On 2/12/15 4:51 PM, David Holmes wrote: > Updated webrev: > > http://cr.openjdk.java.net/~dholmes/7143664/webrev.v3/ src/share/vm/runtime/orderAccess.hpp line 74: // used in such a pair, it is adviced to use a membar instead: Typo: 'adviced' -> 'advised' line 256: // the methods of its superclass using superclass? Perhaps subclass? line 318: // Give platforms a varation point to specialize. Typo: 'varation' -> 'variation' src/share/vm/runtime/orderAccess.inline.hpp No comments. src/cpu/x86/vm/c1_LIRAssembler_x86.cpp No comments. src/os_cpu/bsd_x86/vm/orderAccess_bsd_x86.inline.hpp Do we know if the compiler_barrier() construct works with official MacOS X compilers we're using for JDK9? Update: I couldn't figure out if there was a clear answer about the MacOS X compilers. src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp No comments. src/os_cpu/solaris_x86/vm/orderAccess_solaris_x86.inline.hpp Do we know if the compiler_barrier() construct works with official Solaris compilers we're using for JDK9? Update: Based on other e-mails in this thread, it sounds like this has been tested. src/os_cpu/solaris_x86/vm/solaris_x86_32.il No comments. src/os_cpu/solaris_x86/vm/solaris_x86_64.il No comments. src/os_cpu/windows_x86/vm/orderAccess_windows_x86.inline.hpp No comments. src/os_cpu/bsd_zero/vm/orderAccess_bsd_zero.inline.hpp No comments. src/os_cpu/linux_zero/vm/orderAccess_linux_zero.inline.hpp No comments. src/os_cpu/linux_sparc/vm/orderAccess_linux_sparc.inline.hpp No comments. src/os_cpu/solaris_sparc/vm/orderAccess_solaris_sparc.inline.hpp No comments. src/os_cpu/solaris_sparc/vm/solaris_sparc.il No comments. src/os_cpu/aix_ppc/vm/orderAccess_aix_ppc.inline.hpp No comments. src/os_cpu/linux_ppc/vm/orderAccess_linux_ppc.inline.hpp No comments. This all looks good and reads well to me. IMHO, the best example of the value of the generalization is how much the SPARC files have shrunk... :-) Dan > > Incremental webrev from v2: > > http://cr.openjdk.java.net/~dholmes/7143664/webrev.v3-incr/ > > One response inlined below ... > > On 13/02/2015 2:50 AM, Erik ?sterlund wrote: >> Hi David, >> >> On 12/02/15 01:38, David Holmes wrote: >> >>>>> I still think we need to say something about C++ volatile and about >>>>> compiler barriers in general. >>>> >>>> How about something like: >>>> >>>> C++ volatile semantics prevent compiler re-ordering between volatile >>>> memory accesses. However, reordering between non-volatile and volatile >>>> memory accesses is in general undefined. For compiler reordering >>>> constraints taking non-volatile memory accesses into consideration, a >>>> compiler barrier has to be used instead. Note also that both volatile >>>> semantics and compiler barrier do not prevent hardware reordering. >>> >>> Sounds great! Though perhaps add "Some compiler implementations may >>> choose to enforce additional constraints beyond those required by the >>> language." ( a reference to MVSC) >> >> Sounds good, fixed! >> >>>> But since this is nowadays supported by solaris studio too, I joined >>>> them into one. Not only because it's nicer to unify, but because I >>>> need >>>> the compiler barrier constraints that inline asm can give us. I don't >>>> know the compiler reordering constraints are guaranteed when calling >>>> external assembly. So better make it explicit and safe. >>> >>> Totally fine with making use of Solaris Studio's modern capabilities, >>> only minor concern is no way to test gcc on Solaris. But unless someone >>> else screams about this I'm happy to assume that gcc will still be >>> okay. >> >> Since solaris studio is now actually using GCC syntax of inline asm >> which worked well (on all other GCC variants as well), I just took for >> granted that GCC would handle its own syntax on solaris too. ;) >> But it never hurts to verify! >> >>>> How do you mean they are different? To me they look quite equivalent. >>>> xchg is always implicitly locked on x86, and they both use xchg to get >>>> the wanted fence semantics. >>> >>> Windows: >>> >>> 89 template<> >>> 90 inline void OrderAccess::specialized_release_store_fence >>> (volatile jint* p, jint v) { >>> 91 __asm { >>> 92 mov edx, p; >>> 93 mov eax, v; >>> 94 xchg eax, dword ptr [edx]; >>> 95 } >>> >>> Linux: >>> >>> ! template<> >>> ! inline void OrderAccess::specialized_release_store_fence >>> (volatile jint* p, jint v) { >>> __asm__ volatile ( "xchgl (%2),%0" >>> : "=r" (v) >>> : "0" (v), "r" (p) >>> : "memory"); >>> } >>> >>> but I'm guessing the MVSC inline assembler doesn't have the same >>> capabilities as gcc hence we have to write the code to load the >>> registers needed by the xchg. >> >> Yeah pretty sure the xchg instruction assumes operands are in certain >> registers. GCC is clever enough to know the constraints of the operands >> and I'm guessing MSVC inline assembly is not, so it's made explicit. >> Although who knows, maybe it's smarter nowadays. Add that on the list of >> things to find out about windows and modern compiler support! ;) >> >>>>> Not clear about your change to the float version of >>>>> release_store_fence: >>>>> a) do we need to change it? >>>>> b) given what we changed it to isn't that the default ? >>>> >>>> I didn't want to have default specializations of jfloat/jdouble >>>> equalling jint/jlong. I thought maybe some architecture might want to >>>> put it in different registers or something, making a default >>>> conversion >>>> to int/long maybe undesirable. So the default for jfloat/jdouble is to >>>> use acquire()/release() paired with an atomic memory access. So you >>>> have >>>> to explicitly specialize them to be the same as jint/jlong if wanted, >>>> which I believe is what is done in the code you refer to. >>> >>> Okay. It was the difference between the jfloat and jdouble versions in >>> the original code that threw me. But the jdouble needs to delegate >>> so we >>> end up doing an Atomic::load. >> >> jdouble and jlong is delegated to Atomic::* in orderAccess.inline.hpp as >> they should be. It would perhaps be preferrable to eventually forward >> all atomic accesses to Atomic since it's really a different concern and >> would be good to have in one place. But the methods we need are not >> there yet, so I elected not to for now. >> >> But yeah some jfloat vs jdouble stuff in the original code is very >> strange and inconsistent. Notably, release_store_fence on linux_x86 >> properly uses compiler barriers for release for all variants except the >> awkward jfloat, meaning it does not have the protection it needs. Looks >> to me like this was a human mistake due to the high redundancy of the >> code. > > You mean this: > > OrderAccess::release_store_fence(volatile jfloat* p, jfloat v) { > *p = v; fence(); > } > > technically should be: compiler_barrier(); *p =v; fence(); > > That's an artifact of the assumption that volatile writes are sequence > points and hence a compiler-barrier (something we now know is not the > case with respect to preceding non-volatile accesses). > > Cheers, > David > > > > >>>> If you think I'm paranoid about floats, I can of course make it a >>>> default behaviour to use jint/jlong even if it isn't explicit, in the >>>> same way I handled unsigned variants. >>> >>> No I think that is okay. >> >> Then we keep it that way. :) >> >>> If you can send me an incremental patch I will update the webrev. >> >> Will do, thanks for uploading! >> >> Thanks, >> /Erik >> From igor.veresov at oracle.com Thu Feb 19 21:59:50 2015 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 19 Feb 2015 13:59:50 -0800 Subject: [8u] 8072753 Nondeterministic wrong answer on arithmetic In-Reply-To: <54E64B80.1080901@oracle.com> References: <19C53D5F-1BC9-4006-826D-543747D64746@oracle.com> <54E64B80.1080901@oracle.com> Message-ID: <1CB8212C-441F-4DFA-8DA4-37077B12987C@oracle.com> Thanks! igor > On Feb 19, 2015, at 12:45 PM, Vladimir Kozlov wrote: > > Good. > > Thanks, > Vladimir > > On 2/19/15 12:41 PM, Igor Veresov wrote: >> Webrev: http://cr.openjdk.java.net/~iveresov/8072753/webrev.00/ >> JDK9 changeset: http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/f1b92b73e6aa >> JBS: https://bugs.openjdk.java.net/browse/JDK-8072753 >> >> The change imports cleanly. >> >> Thanks, >> igor >> From david.holmes at oracle.com Thu Feb 19 22:01:11 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 20 Feb 2015 08:01:11 +1000 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <54E56503.4090704@oracle.com> References: <531E8309.2060206@oracle.com> <531ED06F.5040905@oracle.com> <107001365.11810418.1423839439509.JavaMail.zimbra@redhat.com> <54E183B8.5010301@oracle.com> <54E3B144.1090402@oracle.com> <958867570.14123662.1424262805099.JavaMail.zimbra@redhat.com> <1424314925.5112.149.camel@ocdc> <54E55A01.5020700@oracle.com> <54E56503.4090704@oracle.com> Message-ID: <54E65D27.3070107@oracle.com> Apologies to Tiago as there were two webrevs and one got stripped from the email. Here's Tiago's webrev: http://cr.openjdk.java.net/~dholmes/rh1191652-jdk9/webrev.00/ David On 19/02/2015 2:22 PM, David Holmes wrote: > Now hosted at: > > http://cr.openjdk.java.net/~dholmes/ahughes-rh1191652-jdk9-webrev/ > > David > > On 19/02/2015 1:35 PM, David Holmes wrote: >> Hi Tiago, >> >> Please email me the tar files and I will host it for you. >> >> Thanks, >> David >> >> On 19/02/2015 1:02 PM, Tiago Sturmer Daitx wrote: >>> On Wed, 2015-02-18 at 07:33 -0500, Andrew Hughes wrote: >>>> I now have these changes working on 8u31: >>>> >>>> http://cr.openjdk.java.net/~andrew/rh1191652/root >>>> http://cr.openjdk.java.net/~andrew/rh1191652/jdk >>>> >>>> I can re-base these onto whichever OpenJDK 9 tree is appropriate and >>>> push when >>>> reviewed under the same bug as used for the HotSpot side. >>> >>> Concurrently to Andrew I also worked on a fix for JDK9 and came up with >>> a somewhat different approach (based on jdk9/dev): >>> >>> http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/webrev.00/hotspot/ >>> >>> http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/webrev.00/root >>> >>> To make it easy I already rebased Andrew's JDK8u31 patches to jdk9/dev >>> (due to that the webrev ended up with my username). >>> >>> http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/ahughes-webrev.00/hotspot/ >>> >>> >>> http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/ahughes-webrev.00/jdk >>> >>> >>> http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/ahughes-webrev.00/root >>> >>> >>> >>> I tested both approaches by building Hadoop (which triggered some >>> interesting bugs on various projects due to Jigsaw). >>> >>> Sorry for the github links, but I don't have an account at >>> cr.openjdk.java.net that I can use. I can provide tar files if anyone is >>> willing to host those webrevs. >>> >>> Regards, >>> Tiago Daitx >>> From erik.osterlund at lnu.se Thu Feb 19 23:26:13 2015 From: erik.osterlund at lnu.se (=?iso-8859-1?Q?Erik_=D6sterlund?=) Date: Thu, 19 Feb 2015 23:26:13 +0000 Subject: RFR: 7143664: Clean up OrderAccess implementations and usage References: <54C1EBD3.1000905@oracle.com> <54C1F3D8.5040507@oracle.com> <54C2C1EA.5020507@oracle.com> <54C87D16.40601@oracle.com> <54C9674C.2080600@oracle.com> <54D85E4F.5020305@oracle.com> <54DC0416.5070105@oracle.com> <54DD3C91.3030404@oracle.com> <54E65AE4.50004@oracle.com> Message-ID: Hi Daniel, On 19/02/15 22:51, Daniel D. Daugherty wrote: > On 2/12/15 4:51 PM, David Holmes wrote: >> Updated webrev: >> >> http://cr.openjdk.java.net/~dholmes/7143664/webrev.v3/ > > src/share/vm/runtime/orderAccess.hpp > line 74: // used in such a pair, it is adviced to use a membar instead: > Typo: 'adviced' -> 'advised' Fixed. > line 256: // the methods of its superclass using > superclass? Perhaps subclass? Actually, this comment is a relic from when I first implemented generalization using inheritance. I later found it was unnecessary and a bit overengineered, and removed the unnecessary superclasses - but the comment apparently stuck, sorry about that. Thank you for spotting this! I will remove this comment. > line 318: // Give platforms a varation point to specialize. > Typo: 'varation' -> 'variation' Fixed. > src/share/vm/runtime/orderAccess.inline.hpp > No comments. > > > src/cpu/x86/vm/c1_LIRAssembler_x86.cpp > No comments. > > src/os_cpu/bsd_x86/vm/orderAccess_bsd_x86.inline.hpp > Do we know if the compiler_barrier() construct works with > official MacOS X compilers we're using for JDK9? > > Update: I couldn't figure out if there was a clear > answer about the MacOS X compilers. It works. I've been using compiler barriers in my own code (and primarily use Mac OS X) since jdk8 where I used that certain old horrible apple patch of gcc42. And I can confirm that it did save me from reorderings where OrderAccess was not enough (my code is pretty sensitive to reorderings he he). Now I use clang for jdk9 and it works fine too. > src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp > No comments. > > src/os_cpu/solaris_x86/vm/orderAccess_solaris_x86.inline.hpp > Do we know if the compiler_barrier() construct works with > official Solaris compilers we're using for JDK9? > > Update: Based on other e-mails in this thread, it sounds > like this has been tested. Yes this has been tested, except the GCC-variant of Solaris if memory serves right. I think I recall David said Oracle doesn't support GCC on solaris x86, correct me if I'm wrong. Background: Solaris studio previously did not support GCC-style inline assembly syntax so there was a GCC variant with inline assembly and a solaris variant with .il-files. I found out solaris studio now supports gcc-style inline asm (with explicit compiler barriers that I need). Therefore I joined them to use the same GCC-style inline assembly code both when using solaris studio and GCC. And it would be very strange if the GCC-style inline asm worked on solaris studio but not GCC. But as I said then, if anyone cares to try it, I guess it would be good. > src/os_cpu/solaris_x86/vm/solaris_x86_32.il > No comments. > > src/os_cpu/solaris_x86/vm/solaris_x86_64.il > No comments. > > src/os_cpu/windows_x86/vm/orderAccess_windows_x86.inline.hpp > No comments. > > > src/os_cpu/bsd_zero/vm/orderAccess_bsd_zero.inline.hpp > No comments. > > src/os_cpu/linux_zero/vm/orderAccess_linux_zero.inline.hpp > No comments. > > > src/os_cpu/linux_sparc/vm/orderAccess_linux_sparc.inline.hpp > No comments. > > src/os_cpu/solaris_sparc/vm/orderAccess_solaris_sparc.inline.hpp > No comments. > > src/os_cpu/solaris_sparc/vm/solaris_sparc.il > No comments. > > > src/os_cpu/aix_ppc/vm/orderAccess_aix_ppc.inline.hpp > No comments. > > src/os_cpu/linux_ppc/vm/orderAccess_linux_ppc.inline.hpp > No comments. > > > This all looks good and reads well to me. IMHO, the best example > of the value of the generalization is how much the SPARC files > have shrunk... :-) Yeah and the zero files. There is almost zero code left. (he-he) Thanks a lot Daniel for reviewing my changes! :) /Erik > > Dan > > >> >> Incremental webrev from v2: >> >> http://cr.openjdk.java.net/~dholmes/7143664/webrev.v3-incr/ >> >> One response inlined below ... >> >> On 13/02/2015 2:50 AM, Erik ?sterlund wrote: >>> Hi David, >>> >>> On 12/02/15 01:38, David Holmes wrote: >>> >>>>>> I still think we need to say something about C++ volatile and about >>>>>> compiler barriers in general. >>>>> >>>>> How about something like: >>>>> >>>>> C++ volatile semantics prevent compiler re-ordering between volatile >>>>> memory accesses. However, reordering between non-volatile and volatile >>>>> memory accesses is in general undefined. For compiler reordering >>>>> constraints taking non-volatile memory accesses into consideration, a >>>>> compiler barrier has to be used instead. Note also that both volatile >>>>> semantics and compiler barrier do not prevent hardware reordering. >>>> >>>> Sounds great! Though perhaps add "Some compiler implementations may >>>> choose to enforce additional constraints beyond those required by the >>>> language." ( a reference to MVSC) >>> >>> Sounds good, fixed! >>> >>>>> But since this is nowadays supported by solaris studio too, I joined >>>>> them into one. Not only because it's nicer to unify, but because I >>>>> need >>>>> the compiler barrier constraints that inline asm can give us. I don't >>>>> know the compiler reordering constraints are guaranteed when calling >>>>> external assembly. So better make it explicit and safe. >>>> >>>> Totally fine with making use of Solaris Studio's modern capabilities, >>>> only minor concern is no way to test gcc on Solaris. But unless someone >>>> else screams about this I'm happy to assume that gcc will still be >>>> okay. >>> >>> Since solaris studio is now actually using GCC syntax of inline asm >>> which worked well (on all other GCC variants as well), I just took for >>> granted that GCC would handle its own syntax on solaris too. ;) >>> But it never hurts to verify! >>> >>>>> How do you mean they are different? To me they look quite equivalent. >>>>> xchg is always implicitly locked on x86, and they both use xchg to get >>>>> the wanted fence semantics. >>>> >>>> Windows: >>>> >>>> 89 template<> >>>> 90 inline void OrderAccess::specialized_release_store_fence >>>> (volatile jint* p, jint v) { >>>> 91 __asm { >>>> 92 mov edx, p; >>>> 93 mov eax, v; >>>> 94 xchg eax, dword ptr [edx]; >>>> 95 } >>>> >>>> Linux: >>>> >>>> ! template<> >>>> ! inline void OrderAccess::specialized_release_store_fence >>>> (volatile jint* p, jint v) { >>>> __asm__ volatile ( "xchgl (%2),%0" >>>> : "=r" (v) >>>> : "0" (v), "r" (p) >>>> : "memory"); >>>> } >>>> >>>> but I'm guessing the MVSC inline assembler doesn't have the same >>>> capabilities as gcc hence we have to write the code to load the >>>> registers needed by the xchg. >>> >>> Yeah pretty sure the xchg instruction assumes operands are in certain >>> registers. GCC is clever enough to know the constraints of the operands >>> and I'm guessing MSVC inline assembly is not, so it's made explicit. >>> Although who knows, maybe it's smarter nowadays. Add that on the list of >>> things to find out about windows and modern compiler support! ;) >>> >>>>>> Not clear about your change to the float version of >>>>>> release_store_fence: >>>>>> a) do we need to change it? >>>>>> b) given what we changed it to isn't that the default ? >>>>> >>>>> I didn't want to have default specializations of jfloat/jdouble >>>>> equalling jint/jlong. I thought maybe some architecture might want to >>>>> put it in different registers or something, making a default >>>>> conversion >>>>> to int/long maybe undesirable. So the default for jfloat/jdouble is to >>>>> use acquire()/release() paired with an atomic memory access. So you >>>>> have >>>>> to explicitly specialize them to be the same as jint/jlong if wanted, >>>>> which I believe is what is done in the code you refer to. >>>> >>>> Okay. It was the difference between the jfloat and jdouble versions in >>>> the original code that threw me. But the jdouble needs to delegate >>>> so we >>>> end up doing an Atomic::load. >>> >>> jdouble and jlong is delegated to Atomic::* in orderAccess.inline.hpp as >>> they should be. It would perhaps be preferrable to eventually forward >>> all atomic accesses to Atomic since it's really a different concern and >>> would be good to have in one place. But the methods we need are not >>> there yet, so I elected not to for now. >>> >>> But yeah some jfloat vs jdouble stuff in the original code is very >>> strange and inconsistent. Notably, release_store_fence on linux_x86 >>> properly uses compiler barriers for release for all variants except the >>> awkward jfloat, meaning it does not have the protection it needs. Looks >>> to me like this was a human mistake due to the high redundancy of the >>> code. >> >> You mean this: >> >> OrderAccess::release_store_fence(volatile jfloat* p, jfloat v) { >> *p = v; fence(); >> } >> >> technically should be: compiler_barrier(); *p =v; fence(); >> >> That's an artifact of the assumption that volatile writes are sequence >> points and hence a compiler-barrier (something we now know is not the >> case with respect to preceding non-volatile accesses). >> >> Cheers, >> David >> >> >> >> >>>>> If you think I'm paranoid about floats, I can of course make it a >>>>> default behaviour to use jint/jlong even if it isn't explicit, in the >>>>> same way I handled unsigned variants. >>>> >>>> No I think that is okay. >>> >>> Then we keep it that way. :) >>> >>>> If you can send me an incremental patch I will update the webrev. >>> >>> Will do, thanks for uploading! >>> >>> Thanks, >>> /Erik >>> > > From anthony.scarpino at oracle.com Fri Feb 20 00:52:47 2015 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 19 Feb 2015 16:52:47 -0800 Subject: RFR: 8073108: GHASH Intrinsics In-Reply-To: <54E25D03.7090705@oracle.com> References: <54E25D03.7090705@oracle.com> Message-ID: <54E6855F.4050308@oracle.com> I've updated the webrevs. I believe I've added everyone's comments. - Changed GHASHIntrinsics and disabled for non-supported platforms - removing WIN64 ifdef in 32bit x86 - fixed hotspot test so it can use compareArray() - modified the range checking - fixed processBlocks comment http://cr.openjdk.java.net/~ascarpino/8073108/hotspot/webrev.01/ http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev.01/ thanks Tony From vladimir.kozlov at oracle.com Fri Feb 20 01:36:58 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 19 Feb 2015 17:36:58 -0800 Subject: RFR: 8073108: GHASH Intrinsics In-Reply-To: <54E6855F.4050308@oracle.com> References: <54E25D03.7090705@oracle.com> <54E6855F.4050308@oracle.com> Message-ID: <54E68FBA.1090904@oracle.com> JDK changes review. ------------------- All exceptions should print invalid value as you did for state and subkeyH checks. It would greatly help debugging. Please, split first check into 3 separate checks and print invalid value to know which condition failed. Missing space after 'length': "invalid length"+subkeyH.length Hotspot review. --------------- Everything seems fine. Thank you for fixing the test. What do you mean "Changed GHASHIntrinsics"? Don't pass intrinsic_id or something else? Thanks, Vladimir On 2/19/15 4:52 PM, Anthony Scarpino wrote: > I've updated the webrevs. I believe I've added everyone's comments. > - Changed GHASHIntrinsics and disabled for non-supported platforms > - removing WIN64 ifdef in 32bit x86 > - fixed hotspot test so it can use compareArray() > - modified the range checking > - fixed processBlocks comment > > http://cr.openjdk.java.net/~ascarpino/8073108/hotspot/webrev.01/ > > http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev.01/ > > thanks > > Tony > From david.holmes at oracle.com Fri Feb 20 03:31:26 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 20 Feb 2015 13:31:26 +1000 Subject: RFR: 7143664: Clean up OrderAccess implementations and usage In-Reply-To: References: <54C1EBD3.1000905@oracle.com> <54C1F3D8.5040507@oracle.com> <54C2C1EA.5020507@oracle.com> <54C87D16.40601@oracle.com> <54C9674C.2080600@oracle.com> <54D85E4F.5020305@oracle.com> <54DC0416.5070105@oracle.com> <54DD3C91.3030404@oracle.com> <54E65AE4.50004@oracle.com> Message-ID: <54E6AA8E.40808@oracle.com> Updated webrev: http://cr.openjdk.java.net/~dholmes/7143664/webrev.v4/ Thanks, David On 20/02/2015 9:26 AM, Erik ?sterlund wrote: > Hi Daniel, > > On 19/02/15 22:51, Daniel D. Daugherty wrote: >> On 2/12/15 4:51 PM, David Holmes wrote: >>> Updated webrev: >>> >>> http://cr.openjdk.java.net/~dholmes/7143664/webrev.v3/ >> >> src/share/vm/runtime/orderAccess.hpp >> line 74: // used in such a pair, it is adviced to use a membar instead: >> Typo: 'adviced' -> 'advised' > > Fixed. > >> line 256: // the methods of its superclass using >> superclass? Perhaps subclass? > > Actually, this comment is a relic from when I first implemented > generalization using inheritance. I later found it was unnecessary and a > bit overengineered, and removed the unnecessary superclasses - but the > comment apparently stuck, sorry about that. > Thank you for spotting this! I will remove this comment. > >> line 318: // Give platforms a varation point to specialize. >> Typo: 'varation' -> 'variation' > > Fixed. > >> src/share/vm/runtime/orderAccess.inline.hpp >> No comments. >> >> >> src/cpu/x86/vm/c1_LIRAssembler_x86.cpp >> No comments. >> >> src/os_cpu/bsd_x86/vm/orderAccess_bsd_x86.inline.hpp >> Do we know if the compiler_barrier() construct works with >> official MacOS X compilers we're using for JDK9? >> >> Update: I couldn't figure out if there was a clear >> answer about the MacOS X compilers. > > It works. > > I've been using compiler barriers in my own code (and primarily use Mac > OS X) since jdk8 where I used that certain old horrible apple patch of > gcc42. And I can confirm that it did save me from reorderings where > OrderAccess was not enough (my code is pretty sensitive to reorderings > he he). > Now I use clang for jdk9 and it works fine too. > >> src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp >> No comments. >> >> src/os_cpu/solaris_x86/vm/orderAccess_solaris_x86.inline.hpp >> Do we know if the compiler_barrier() construct works with >> official Solaris compilers we're using for JDK9? >> >> Update: Based on other e-mails in this thread, it sounds >> like this has been tested. > > Yes this has been tested, except the GCC-variant of Solaris if memory > serves right. I think I recall David said Oracle doesn't support GCC on > solaris x86, correct me if I'm wrong. > > Background: Solaris studio previously did not support GCC-style inline > assembly syntax so there was a GCC variant with inline assembly and a > solaris variant with .il-files. I found out solaris studio now supports > gcc-style inline asm (with explicit compiler barriers that I need). > Therefore I joined them to use the same GCC-style inline assembly code > both when using solaris studio and GCC. And it would be very strange if > the GCC-style inline asm worked on solaris studio but not GCC. But as I > said then, if anyone cares to try it, I guess it would be good. > >> src/os_cpu/solaris_x86/vm/solaris_x86_32.il >> No comments. >> >> src/os_cpu/solaris_x86/vm/solaris_x86_64.il >> No comments. >> >> src/os_cpu/windows_x86/vm/orderAccess_windows_x86.inline.hpp >> No comments. >> >> >> src/os_cpu/bsd_zero/vm/orderAccess_bsd_zero.inline.hpp >> No comments. >> >> src/os_cpu/linux_zero/vm/orderAccess_linux_zero.inline.hpp >> No comments. >> >> >> src/os_cpu/linux_sparc/vm/orderAccess_linux_sparc.inline.hpp >> No comments. >> >> src/os_cpu/solaris_sparc/vm/orderAccess_solaris_sparc.inline.hpp >> No comments. >> >> src/os_cpu/solaris_sparc/vm/solaris_sparc.il >> No comments. >> >> >> src/os_cpu/aix_ppc/vm/orderAccess_aix_ppc.inline.hpp >> No comments. >> >> src/os_cpu/linux_ppc/vm/orderAccess_linux_ppc.inline.hpp >> No comments. >> >> >> This all looks good and reads well to me. IMHO, the best example >> of the value of the generalization is how much the SPARC files >> have shrunk... :-) > > Yeah and the zero files. There is almost zero code left. (he-he) > > Thanks a lot Daniel for reviewing my changes! :) > > /Erik > >> >> Dan >> >> >>> >>> Incremental webrev from v2: >>> >>> http://cr.openjdk.java.net/~dholmes/7143664/webrev.v3-incr/ >>> >>> One response inlined below ... >>> >>> On 13/02/2015 2:50 AM, Erik ?sterlund wrote: >>>> Hi David, >>>> >>>> On 12/02/15 01:38, David Holmes wrote: >>>> >>>>>>> I still think we need to say something about C++ volatile and about >>>>>>> compiler barriers in general. >>>>>> >>>>>> How about something like: >>>>>> >>>>>> C++ volatile semantics prevent compiler re-ordering between volatile >>>>>> memory accesses. However, reordering between non-volatile and volatile >>>>>> memory accesses is in general undefined. For compiler reordering >>>>>> constraints taking non-volatile memory accesses into consideration, a >>>>>> compiler barrier has to be used instead. Note also that both volatile >>>>>> semantics and compiler barrier do not prevent hardware reordering. >>>>> >>>>> Sounds great! Though perhaps add "Some compiler implementations may >>>>> choose to enforce additional constraints beyond those required by the >>>>> language." ( a reference to MVSC) >>>> >>>> Sounds good, fixed! >>>> >>>>>> But since this is nowadays supported by solaris studio too, I joined >>>>>> them into one. Not only because it's nicer to unify, but because I >>>>>> need >>>>>> the compiler barrier constraints that inline asm can give us. I don't >>>>>> know the compiler reordering constraints are guaranteed when calling >>>>>> external assembly. So better make it explicit and safe. >>>>> >>>>> Totally fine with making use of Solaris Studio's modern capabilities, >>>>> only minor concern is no way to test gcc on Solaris. But unless someone >>>>> else screams about this I'm happy to assume that gcc will still be >>>>> okay. >>>> >>>> Since solaris studio is now actually using GCC syntax of inline asm >>>> which worked well (on all other GCC variants as well), I just took for >>>> granted that GCC would handle its own syntax on solaris too. ;) >>>> But it never hurts to verify! >>>> >>>>>> How do you mean they are different? To me they look quite equivalent. >>>>>> xchg is always implicitly locked on x86, and they both use xchg to get >>>>>> the wanted fence semantics. >>>>> >>>>> Windows: >>>>> >>>>> 89 template<> >>>>> 90 inline void OrderAccess::specialized_release_store_fence >>>>> (volatile jint* p, jint v) { >>>>> 91 __asm { >>>>> 92 mov edx, p; >>>>> 93 mov eax, v; >>>>> 94 xchg eax, dword ptr [edx]; >>>>> 95 } >>>>> >>>>> Linux: >>>>> >>>>> ! template<> >>>>> ! inline void OrderAccess::specialized_release_store_fence >>>>> (volatile jint* p, jint v) { >>>>> __asm__ volatile ( "xchgl (%2),%0" >>>>> : "=r" (v) >>>>> : "0" (v), "r" (p) >>>>> : "memory"); >>>>> } >>>>> >>>>> but I'm guessing the MVSC inline assembler doesn't have the same >>>>> capabilities as gcc hence we have to write the code to load the >>>>> registers needed by the xchg. >>>> >>>> Yeah pretty sure the xchg instruction assumes operands are in certain >>>> registers. GCC is clever enough to know the constraints of the operands >>>> and I'm guessing MSVC inline assembly is not, so it's made explicit. >>>> Although who knows, maybe it's smarter nowadays. Add that on the list of >>>> things to find out about windows and modern compiler support! ;) >>>> >>>>>>> Not clear about your change to the float version of >>>>>>> release_store_fence: >>>>>>> a) do we need to change it? >>>>>>> b) given what we changed it to isn't that the default ? >>>>>> >>>>>> I didn't want to have default specializations of jfloat/jdouble >>>>>> equalling jint/jlong. I thought maybe some architecture might want to >>>>>> put it in different registers or something, making a default >>>>>> conversion >>>>>> to int/long maybe undesirable. So the default for jfloat/jdouble is to >>>>>> use acquire()/release() paired with an atomic memory access. So you >>>>>> have >>>>>> to explicitly specialize them to be the same as jint/jlong if wanted, >>>>>> which I believe is what is done in the code you refer to. >>>>> >>>>> Okay. It was the difference between the jfloat and jdouble versions in >>>>> the original code that threw me. But the jdouble needs to delegate >>>>> so we >>>>> end up doing an Atomic::load. >>>> >>>> jdouble and jlong is delegated to Atomic::* in orderAccess.inline.hpp as >>>> they should be. It would perhaps be preferrable to eventually forward >>>> all atomic accesses to Atomic since it's really a different concern and >>>> would be good to have in one place. But the methods we need are not >>>> there yet, so I elected not to for now. >>>> >>>> But yeah some jfloat vs jdouble stuff in the original code is very >>>> strange and inconsistent. Notably, release_store_fence on linux_x86 >>>> properly uses compiler barriers for release for all variants except the >>>> awkward jfloat, meaning it does not have the protection it needs. Looks >>>> to me like this was a human mistake due to the high redundancy of the >>>> code. >>> >>> You mean this: >>> >>> OrderAccess::release_store_fence(volatile jfloat* p, jfloat v) { >>> *p = v; fence(); >>> } >>> >>> technically should be: compiler_barrier(); *p =v; fence(); >>> >>> That's an artifact of the assumption that volatile writes are sequence >>> points and hence a compiler-barrier (something we now know is not the >>> case with respect to preceding non-volatile accesses). >>> >>> Cheers, >>> David >>> >>> >>> >>> >>>>>> If you think I'm paranoid about floats, I can of course make it a >>>>>> default behaviour to use jint/jlong even if it isn't explicit, in the >>>>>> same way I handled unsigned variants. >>>>> >>>>> No I think that is okay. >>>> >>>> Then we keep it that way. :) >>>> >>>>> If you can send me an incremental patch I will update the webrev. >>>> >>>> Will do, thanks for uploading! >>>> >>>> Thanks, >>>> /Erik >>>> >> >> From david.holmes at oracle.com Fri Feb 20 03:42:32 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 20 Feb 2015 13:42:32 +1000 Subject: Strange safe-point banding behavior In-Reply-To: <1E803311-D142-48F8-AD19-2E115160EC27@kodewerk.com> References: <20150213230416.5E7B617FDAA@rebar.astron.com> <54DE8BB7.5050801@oracle.com> <54DE9140.3040604@oracle.com> <54E30C38.8000303@redhat.com> <54E31144.3040504@redhat.com> <54E314BF.3010205@redhat.com> <54E31677.1050209@redhat.com> <54E31CA6.6030609@redhat.com> <54E31DA0.2040901@redhat.com> <54E34EAF.6000802@redhat.com> <0457F01A-9DE1-4049-BFA2-66C7F6CCAA0B@oracle.com> <54E38F4B.7060100@redhat.com> <54E39364.6030409@oracle.com> <54E462E1.5080009@redhat.com> <54E4652F.80600@redhat.com> <54E59DE0.9030506@oracle.com> <2F8DF5F9-6F0A-40A5-B389-3081449A0818@kodewerk.com> <54E5BD15.8050802@oracle.com> <1E803311-D142-48F8-AD19-2E115160EC27@kodewerk.com> Message-ID: <54E6AD28.10001@oracle.com> On 19/02/2015 10:46 PM, Kirk Pepperdine wrote: > Hi David, > >>> >>> Thanks, not sure how I missed this one. However, if GuaranteedSafepointInterval=1000ms, then how can we see application runtimes that are far greater than 1000ms? >> >> You need to look at exactly what those timers actually measure - it's been a while since I have done so - I'm not sure what "application run time" actually is. > > Indeed, I will look. What I can say is; these timings are perfectly interwoven with safepoints and not all of the measurements are cut off at ~1000ms, just enough of them to make pretty pictures of the charts. I can't find these "application run time" timers/counters - can you point me to them please. Thanks, David > Thanks, > Kirk > >> >> David >> >>> Regards, >>> Kirk >>> >>> On Feb 19, 2015, at 9:25 AM, David Holmes wrote: >>> >>>> Hi Kirk, >>>> >>>> GuaranteedSafepointInterval has a default value of 1000ms. It's a diagnostic flag so you can try changing it. >>>> >>>> The reason for this is to ensure certain housekeeping tasks that must occur at a safepoint happen with some regularity eg monitor scavenging. >>>> >>>> David >>>> >>>> On 19/02/2015 6:10 PM, Kirk Pepperdine wrote: >>>>> Hi all, >>>>> >>>>> I can?t say that I?ve taken this as far as I could as of yet but I think I can start to ask questions. >>>>> >>>>> I?ve seen what I call a banding artifact in a number of GC logs. The latest prompted me to investigate further. In the latest case Application runtime is being reported very frequently a ~1 second. It is being reported some what less frequently every ~2 seconds. So that means a safe point is being called for very frequently at these times so in amongst all of the other application runtime data points these points from a solid line in the chart. Now there are intermixed runtimes that go longer than 2 seconds and of course they are shorter than 1 second. >>>>> >>>>> When we looked at PrintSafepointStatistics we get ?no vm operation? which means sstats->_vmop_type == -1 which implies that the VM_Operation has not been set. >>>>> >>>>> Question is; why would a safepoint be called for with no VM_Operation? Looking at the code I would say it?s quite common. I?ve turned on safepoint tracing for other applications and have seen other even more bizarre banding patterns which all appear to be due to some regular behavior. >>>>> >>>>> This happens on all recent (and most likely older) versions of the JVM. >>>>> >>>>> Kind regards, >>>>> Kirk >>>>> >>> > From anthony.scarpino at oracle.com Fri Feb 20 05:22:50 2015 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Thu, 19 Feb 2015 21:22:50 -0800 Subject: RFR: 8073108: GHASH Intrinsics In-Reply-To: <54E68FBA.1090904@oracle.com> References: <54E25D03.7090705@oracle.com> <54E6855F.4050308@oracle.com> <54E68FBA.1090904@oracle.com> Message-ID: On Feb 19, 2015, at 5:36 PM, Vladimir Kozlov wrote: > JDK changes review. > ------------------- > All exceptions should print invalid value as you did for state and subkeyH checks. It would greatly help debugging. > > Please, split first check into 3 separate checks and print invalid value to know which condition failed. > > Missing space after 'length': "invalid length?+subkeyH.length Ok.. I?ll make those changes > > Hotspot review. > --------------- > Everything seems fine. Thank you for fixing the test. > > What do you mean "Changed GHASHIntrinsics"? Don't pass intrinsic_id or something else? I combined the two change into one bullet point. Your comment about merging has_vis3() and UseVIS into one if() in vm_version_sparc.cpp and the addition code to prevent other platforms from using the flag. Both involved GHASHIntrinsics. Tony > Thanks, > Vladimir > > On 2/19/15 4:52 PM, Anthony Scarpino wrote: >> I've updated the webrevs. I believe I've added everyone's comments. >> - Changed GHASHIntrinsics and disabled for non-supported platforms >> - removing WIN64 ifdef in 32bit x86 >> - fixed hotspot test so it can use compareArray() >> - modified the range checking >> - fixed processBlocks comment >> >> http://cr.openjdk.java.net/~ascarpino/8073108/hotspot/webrev.01/ >> >> http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev.01/ >> >> thanks >> >> Tony >> From denis.kononenko at oracle.com Fri Feb 20 12:27:19 2015 From: denis.kononenko at oracle.com (denis kononenko) Date: Fri, 20 Feb 2015 15:27:19 +0300 Subject: RFR (S): 8072687: Update OutputAnalyzer to work with files In-Reply-To: <54E6508C.70703@oracle.com> References: <54E36511.7010608@oracle.com> <65BF10CE-582D-448E-B5DA-5544276C0E16@oracle.com> <54E38EEC.9020001@oracle.com> <54E461BC.30104@oracle.com> <54E5DA3D.6010909@oracle.com> <802FB5B7-FC9F-47DE-B8DD-69225BE4FCE3@oracle.com> <54E6508C.70703@oracle.com> Message-ID: <54E72827.7080201@oracle.com> Hi Igor, On 20.02.2015 0:07, Igor Ignatyev wrote: > Hi Denis, > > FileOutputAnalyzerTest: > 0. why don't you use Utils.NEW_LINE or String.format(...%n...) instead of >> 46 String expected = >> 47 "line1" + System.lineSeparator() >> 48 + "line2" + System.lineSeparator() >> 49 + "line3"; It has more clear visual representation of the expected content. In contrast to Utils.NEW_LINE the System.lineSeparator is a standard library method. Ideally I'd prefer to generate random content but Dima told me this would complicate the test. > > 1. wrong indent on 53. Thanks. > 2. could you pleas use Asserts.assertEquals to replace lines 56--61, > 67--71? lines 63--66 could be also replaced by Asserts.assertTrue It makes sense. > 3. since you expect FileNotFoundException, shouldn't you use it in > catch clause? In such case I should have two catch clauses, one for FileNotFoundException and another for IOException. For purpose of simplicity I'd prefer to catch more generic exception. > 4. what if 'non-existing.file' exists? could you please check it in > the very begging of test case? It shouldn't be possible as Jtreg ensures that the test is running in a newly created and clean scratch directory. > > OutputAnalyzerTest: > 0. the same as FileOutputAnalyzerTest#2 Thank you, Denis. > > Thanks, > Igor > > On 02/19/2015 05:17 PM, Staffan Larsen wrote: >> Looks good! >> >> Thanks, >> /Staffan >> >>> On 19 feb 2015, at 13:42, denis kononenko >>> wrote: >>> >>> >>> Hi Dima, Staffan, >>> >>> I've fixed the review findings, here's a new webrev link: >>> >>> http://cr.openjdk.java.net/~dfazunen/dkononen/8072687/webrev.01/ >>> >>> I found that CompressedClassSpaceSizeInJmapHeap.java could be >>> improved without use of the new proposed functionality. The >>> OutputAnalyzer works perfectly with Process objects and there's no >>> need to capture stderr/stdout into two separate files as it's >>> already done by the OutputAnalyzer. So I simply removed all stuff >>> which duplicated this functionality. >>> All necessary tests were performed. >>> >>> Thank you, >>> Denis. >>> >>> On 18.02.2015 12:56, Dmitry Fazunenko wrote: >>>> >>>> On 18.02.2015 12:34, Staffan Larsen wrote: >>>>> I can only see one usage of the OutputAnalyzer(String) constructor >>>>> and that is in >>>>> test/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java. That >>>>> usage does not require both stdout and stderr to be set. >>>>> >>>>> In fact, that usage would benefit from the new constructor that >>>>> takes a File. >>>>> >>>>> I suggest we do: >>>>> >>>>> - Change OutputAnalyzer(String) to set stdout to the input string >>>>> and stderr to the empty string "" >>>>> - Update CompressedClassSpaceSizeInJmapHeap.java to use the new >>>>> OutputAnalyzer(File) constructor >>>> >>>> sounds good to me. >>>> >>>> -- Dima >>>> >>>>> >>>>> Thanks, >>>>> /Staffan >>>>> >>>>> >>>>>> On 17 feb 2015, at 19:56, Dmitry Fazunenko >>>>>> wrote: >>>>>> >>>>>> Hi Staffan, >>>>>> >>>>>> For me it's not clear why the constructor taking a String >>>>>> argument sets both stderr and stdout to the same value... >>>>>> But I don't see any reason to update this behavior and break >>>>>> compatibility. >>>>>> So I would agree, that the new constructor should be consistent >>>>>> with the existing one and set both out and err to the same string. >>>>>> >>>>>> Thanks, >>>>>> Dima >>>>>> >>>>>> >>>>>> >>>>>> On 17.02.2015 20:39, Staffan Larsen wrote: >>>>>>> There is constructor that takes a String argument. That >>>>>>> constructor sets both stderr and stdout to that same String. >>>>>>> Your constructor behaves differently and only sets stdout to the >>>>>>> contents of the file. I have no idea why the existing >>>>>>> constructor does what it does, but it would be good if the new >>>>>>> and old had the same behavior. I haven?t looked at the use cases >>>>>>> for the existing constructor. >>>>>>> >>>>>>> /S >>>>>>> >>>>>>>> On 17 feb 2015, at 16:58, denis kononenko >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hi All, >>>>>>>> >>>>>>>> Could you please review a small change of OutputAnalyzer class >>>>>>>> from testlibrary. >>>>>>>> >>>>>>>> Webrev link: >>>>>>>> http://cr.openjdk.java.net/~dfazunen/dkononen/8072687/webrev.00/ >>>>>>>> Bug id: https://bugs.openjdk.java.net/browse/JDK-8072687 >>>>>>>> Testing: automated >>>>>>>> Description: >>>>>>>> >>>>>>>> The purpose of this change is to extend the functionality of >>>>>>>> OutputAnalyzer by adding ability to read output from a file. >>>>>>>> Sometimes we have to analyze output written to a file (test >>>>>>>> data, logs, etc.). In that case we have to read it as a string >>>>>>>> and pass it into OutputAnalyzer's constructor (it could be done >>>>>>>> in several different ways). It would be very convenient to put >>>>>>>> this code directly into OutputAnalyzer. This would allow to >>>>>>>> make further tests code more cleaner and less error prone. >>>>>>>> >>>>>>>> The change consist of two parts: >>>>>>>> 1) The change: OutputAnalyzer.java, added a new constructor >>>>>>>> that accepts File; >>>>>>>> 2) The tests: FileOutputAnalyzerTests.java, very basic tests on >>>>>>>> reading functionality. >>>>>>>> >>>>>>>> Thank you, >>>>>>>> Denis. >>>>>>>> >>>>>>>> >>>> >>> >> From igor.ignatyev at oracle.com Fri Feb 20 12:39:05 2015 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 20 Feb 2015 15:39:05 +0300 Subject: RFR (S): 8072687: Update OutputAnalyzer to work with files In-Reply-To: <54E72827.7080201@oracle.com> References: <54E36511.7010608@oracle.com> <65BF10CE-582D-448E-B5DA-5544276C0E16@oracle.com> <54E38EEC.9020001@oracle.com> <54E461BC.30104@oracle.com> <54E5DA3D.6010909@oracle.com> <802FB5B7-FC9F-47DE-B8DD-69225BE4FCE3@oracle.com> <54E6508C.70703@oracle.com> <54E72827.7080201@oracle.com> Message-ID: <54E72AE9.1070507@oracle.com> On 02/20/2015 03:27 PM, denis kononenko wrote: > > Hi Igor, > > On 20.02.2015 0:07, Igor Ignatyev wrote: >> Hi Denis, >> >> FileOutputAnalyzerTest: >> 0. why don't you use Utils.NEW_LINE or String.format(...%n...) instead of >>> 46 String expected = >>> 47 "line1" + System.lineSeparator() >>> 48 + "line2" + System.lineSeparator() >>> 49 + "line3"; > > It has more clear visual representation of the expected content. In > contrast to Utils.NEW_LINE the System.lineSeparator is a standard > library method. Ideally I'd prefer to generate random content but Dima > told me this would complicate the test. well, it's arguable; in my opinion, String.format(...) is better. > >> >> 1. wrong indent on 53. > > Thanks. > >> 2. could you pleas use Asserts.assertEquals to replace lines 56--61, >> 67--71? lines 63--66 could be also replaced by Asserts.assertTrue > > It makes sense. > >> 3. since you expect FileNotFoundException, shouldn't you use it in >> catch clause? > > In such case I should have two catch clauses, one for > FileNotFoundException and another for IOException. For purpose of > simplicity I'd prefer to catch more generic exception. it's not a simplification, it's an incorrect test. you don't expect any exceptions except FileNotFoundException, but catch IOException. so I'd recommend you to have additional catch block for IOException w/ rethrowing the exception as an unchecked one. > >> 4. what if 'non-existing.file' exists? could you please check it in >> the very begging of test case? > > It shouldn't be possible as Jtreg ensures that the test is running in a > newly created and clean scratch directory. well, I can say the almost same about the whole test. the thing is that your test relays on a particular behavior of jtreg and an exception (line 93) won't contain any useful details. so it will be very hard to investigate in case bugs in jtreg. > >> >> OutputAnalyzerTest: >> 0. the same as FileOutputAnalyzerTest#2 > > Thank you, > Denis. > >> >> Thanks, >> Igor >> >> On 02/19/2015 05:17 PM, Staffan Larsen wrote: >>> Looks good! >>> >>> Thanks, >>> /Staffan >>> >>>> On 19 feb 2015, at 13:42, denis kononenko >>>> wrote: >>>> >>>> >>>> Hi Dima, Staffan, >>>> >>>> I've fixed the review findings, here's a new webrev link: >>>> >>>> http://cr.openjdk.java.net/~dfazunen/dkononen/8072687/webrev.01/ >>>> >>>> I found that CompressedClassSpaceSizeInJmapHeap.java could be >>>> improved without use of the new proposed functionality. The >>>> OutputAnalyzer works perfectly with Process objects and there's no >>>> need to capture stderr/stdout into two separate files as it's >>>> already done by the OutputAnalyzer. So I simply removed all stuff >>>> which duplicated this functionality. >>>> All necessary tests were performed. >>>> >>>> Thank you, >>>> Denis. >>>> >>>> On 18.02.2015 12:56, Dmitry Fazunenko wrote: >>>>> >>>>> On 18.02.2015 12:34, Staffan Larsen wrote: >>>>>> I can only see one usage of the OutputAnalyzer(String) constructor >>>>>> and that is in >>>>>> test/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java. That >>>>>> usage does not require both stdout and stderr to be set. >>>>>> >>>>>> In fact, that usage would benefit from the new constructor that >>>>>> takes a File. >>>>>> >>>>>> I suggest we do: >>>>>> >>>>>> - Change OutputAnalyzer(String) to set stdout to the input string >>>>>> and stderr to the empty string "" >>>>>> - Update CompressedClassSpaceSizeInJmapHeap.java to use the new >>>>>> OutputAnalyzer(File) constructor >>>>> >>>>> sounds good to me. >>>>> >>>>> -- Dima >>>>> >>>>>> >>>>>> Thanks, >>>>>> /Staffan >>>>>> >>>>>> >>>>>>> On 17 feb 2015, at 19:56, Dmitry Fazunenko >>>>>>> wrote: >>>>>>> >>>>>>> Hi Staffan, >>>>>>> >>>>>>> For me it's not clear why the constructor taking a String >>>>>>> argument sets both stderr and stdout to the same value... >>>>>>> But I don't see any reason to update this behavior and break >>>>>>> compatibility. >>>>>>> So I would agree, that the new constructor should be consistent >>>>>>> with the existing one and set both out and err to the same string. >>>>>>> >>>>>>> Thanks, >>>>>>> Dima >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 17.02.2015 20:39, Staffan Larsen wrote: >>>>>>>> There is constructor that takes a String argument. That >>>>>>>> constructor sets both stderr and stdout to that same String. >>>>>>>> Your constructor behaves differently and only sets stdout to the >>>>>>>> contents of the file. I have no idea why the existing >>>>>>>> constructor does what it does, but it would be good if the new >>>>>>>> and old had the same behavior. I haven?t looked at the use cases >>>>>>>> for the existing constructor. >>>>>>>> >>>>>>>> /S >>>>>>>> >>>>>>>>> On 17 feb 2015, at 16:58, denis kononenko >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi All, >>>>>>>>> >>>>>>>>> Could you please review a small change of OutputAnalyzer class >>>>>>>>> from testlibrary. >>>>>>>>> >>>>>>>>> Webrev link: >>>>>>>>> http://cr.openjdk.java.net/~dfazunen/dkononen/8072687/webrev.00/ >>>>>>>>> Bug id: https://bugs.openjdk.java.net/browse/JDK-8072687 >>>>>>>>> Testing: automated >>>>>>>>> Description: >>>>>>>>> >>>>>>>>> The purpose of this change is to extend the functionality of >>>>>>>>> OutputAnalyzer by adding ability to read output from a file. >>>>>>>>> Sometimes we have to analyze output written to a file (test >>>>>>>>> data, logs, etc.). In that case we have to read it as a string >>>>>>>>> and pass it into OutputAnalyzer's constructor (it could be done >>>>>>>>> in several different ways). It would be very convenient to put >>>>>>>>> this code directly into OutputAnalyzer. This would allow to >>>>>>>>> make further tests code more cleaner and less error prone. >>>>>>>>> >>>>>>>>> The change consist of two parts: >>>>>>>>> 1) The change: OutputAnalyzer.java, added a new constructor >>>>>>>>> that accepts File; >>>>>>>>> 2) The tests: FileOutputAnalyzerTests.java, very basic tests on >>>>>>>>> reading functionality. >>>>>>>>> >>>>>>>>> Thank you, >>>>>>>>> Denis. >>>>>>>>> >>>>>>>>> >>>>> >>>> >>> > From denis.kononenko at oracle.com Fri Feb 20 13:26:10 2015 From: denis.kononenko at oracle.com (denis kononenko) Date: Fri, 20 Feb 2015 16:26:10 +0300 Subject: RFR (S): 8072687: Update OutputAnalyzer to work with files In-Reply-To: <54E72AE9.1070507@oracle.com> References: <54E36511.7010608@oracle.com> <65BF10CE-582D-448E-B5DA-5544276C0E16@oracle.com> <54E38EEC.9020001@oracle.com> <54E461BC.30104@oracle.com> <54E5DA3D.6010909@oracle.com> <802FB5B7-FC9F-47DE-B8DD-69225BE4FCE3@oracle.com> <54E6508C.70703@oracle.com> <54E72827.7080201@oracle.com> <54E72AE9.1070507@oracle.com> Message-ID: <54E735F2.7010905@oracle.com> Igor, The conversation becomes too long, so I snipped the part where we have no disagreement. >> >>> 3. since you expect FileNotFoundException, shouldn't you use it in >>> catch clause? >> >> In such case I should have two catch clauses, one for >> FileNotFoundException and another for IOException. For purpose of >> simplicity I'd prefer to catch more generic exception. > it's not a simplification, it's an incorrect test. you don't expect > any exceptions except FileNotFoundException, but catch IOException. so > I'd recommend you to have additional catch block for IOException w/ > rethrowing the exception as an unchecked one. Ok, I got your point. The problem is in the test's name, I'd propose to rename it to testFileNotFoundException and catch the FileNotFoundException only. Another option is to simply remove this test due its complexity and small benefit. >> >>> 4. what if 'non-existing.file' exists? could you please check it in >>> the very begging of test case? >> >> It shouldn't be possible as Jtreg ensures that the test is running in a >> newly created and clean scratch directory. > well, I can say the almost same about the whole test. the thing is > that your test relays on a particular behavior of jtreg and an > exception (line 93) won't contain any useful details. so it will be > very hard to investigate in case bugs in jtreg. I think you dramatize the situation, many tests depends on jtreg's behavior, in particular, on its cleanup procedure. If it fail we will see a lot of errors in our tests. Moreover, you cannot guarantee that a file doesn't exist in a multiprocess environment. There always will be a slight chance of collision. My favorite approach to generate "non-existing" files is: new File(UUID.randomUUID().toString()). It could improve the test's reliability. Thank you, Denis. From sgehwolf at redhat.com Fri Feb 20 13:37:35 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 20 Feb 2015 14:37:35 +0100 Subject: RFR(M) 8072383: resolve conflicts between open and closed ports In-Reply-To: <1424360668.3641.62.camel@redhat.com> References: <54E52803.3030606@oracle.com> <54E52D9E.5050706@oracle.com> <54E53235.3030800@oracle.com> <54E562B9.1060302@oracle.com> <1424360668.3641.62.camel@redhat.com> Message-ID: <1424439455.3408.15.camel@redhat.com> On Thu, 2015-02-19 at 16:44 +0100, Severin Gehwolf wrote: > On Wed, 2015-02-18 at 20:12 -0800, Dean Long wrote: > > Yes, good catch. I've update the webrev to webrev.8u60.01. Thanks for > > the review. > > Has anyone tested those changes with a Zero build > (--with-jvm-variants=zero)? Specifically on arm/ppc? I'm testing it now > and get back to you. Disclaimer: Not a reviewer. I've only tested the 8 webrev. It seems to be fine for Zero on arm/ppc/x86_64. Thumbs up from me. FWIW, the 9 patch didn't apply for me. Not sure which forest you were using. I was trying jdk9/hs-comp. Cheers, Severin > Thanks, > Severin > > > dl > > > > On 2/18/2015 4:45 PM, Vladimir Kozlov wrote: > > > Did you missed to remove #elif ppc_32 in 8u60 changes in > > > src/share/vm/interpreter/templateTable.hpp? > > > > > > Otherwise both versions look good. > > > > > > Thanks, > > > Vlaidmir > > > > > > On 2/18/15 4:26 PM, Dean Long wrote: > > >> Just to avoid confusion, let me clarify that the jdk9 changes below > > >> can't be pushed until after the open aarch64 port is merged into the > > >> main jdk9, as they are based on the staging repo. > > >> > > >> dl > > >> > > >> On 2/18/2015 4:02 PM, Dean Long wrote: > > >>> These changes resolve some issues with references to closed ports in > > >>> open hotspot code, > > >>> primarily by removing those references completely. I have included > > >>> the 8u60 backport > > >>> as well because it won't apply cleanly, and I may push it first > > >>> because the 9 changes are > > >>> blocked by JEP 237: Linux/AArch64 Port. > > >>> > > >>> http://cr.openjdk.java.net/~dlong/8072383/webrev.8u60.00/ > > >>> http://cr.openjdk.java.net/~dlong/8072383/webrev.9.00/ > > >>> > > >>> dl > > >> > > > > > From volker.simonis at gmail.com Fri Feb 20 13:51:16 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 20 Feb 2015 14:51:16 +0100 Subject: RFR(M) 8072383: resolve conflicts between open and closed ports In-Reply-To: <1424439455.3408.15.camel@redhat.com> References: <54E52803.3030606@oracle.com> <54E52D9E.5050706@oracle.com> <54E53235.3030800@oracle.com> <54E562B9.1060302@oracle.com> <1424360668.3641.62.camel@redhat.com> <1424439455.3408.15.camel@redhat.com> Message-ID: The 9 patch is against http://hg.openjdk.java.net/aarch64-port/stage On Fri, Feb 20, 2015 at 2:37 PM, Severin Gehwolf wrote: > On Thu, 2015-02-19 at 16:44 +0100, Severin Gehwolf wrote: >> On Wed, 2015-02-18 at 20:12 -0800, Dean Long wrote: >> > Yes, good catch. I've update the webrev to webrev.8u60.01. Thanks for >> > the review. >> >> Has anyone tested those changes with a Zero build >> (--with-jvm-variants=zero)? Specifically on arm/ppc? I'm testing it now >> and get back to you. > > Disclaimer: Not a reviewer. > > I've only tested the 8 webrev. It seems to be fine for Zero on > arm/ppc/x86_64. Thumbs up from me. > > FWIW, the 9 patch didn't apply for me. Not sure which forest you were > using. I was trying jdk9/hs-comp. > > Cheers, > Severin > >> Thanks, >> Severin >> >> > dl >> > >> > On 2/18/2015 4:45 PM, Vladimir Kozlov wrote: >> > > Did you missed to remove #elif ppc_32 in 8u60 changes in >> > > src/share/vm/interpreter/templateTable.hpp? >> > > >> > > Otherwise both versions look good. >> > > >> > > Thanks, >> > > Vlaidmir >> > > >> > > On 2/18/15 4:26 PM, Dean Long wrote: >> > >> Just to avoid confusion, let me clarify that the jdk9 changes below >> > >> can't be pushed until after the open aarch64 port is merged into the >> > >> main jdk9, as they are based on the staging repo. >> > >> >> > >> dl >> > >> >> > >> On 2/18/2015 4:02 PM, Dean Long wrote: >> > >>> These changes resolve some issues with references to closed ports in >> > >>> open hotspot code, >> > >>> primarily by removing those references completely. I have included >> > >>> the 8u60 backport >> > >>> as well because it won't apply cleanly, and I may push it first >> > >>> because the 9 changes are >> > >>> blocked by JEP 237: Linux/AArch64 Port. >> > >>> >> > >>> http://cr.openjdk.java.net/~dlong/8072383/webrev.8u60.00/ >> > >>> http://cr.openjdk.java.net/~dlong/8072383/webrev.9.00/ >> > >>> >> > >>> dl >> > >> >> > >> >> >> > > > From stefan.karlsson at oracle.com Fri Feb 20 14:28:31 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 20 Feb 2015 15:28:31 +0100 Subject: RFR: 8073554: Remove unnecessary includes of markSweep[.inline].hpp Message-ID: <54E7448F.6060907@oracle.com> Hi, Please review the removal of some unnecessary includes of MarkSweep files from non-GC code. http://cr.openjdk.java.net/~stefank/8073554/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8073554 Thanks, StefanK From thomas.schatzl at oracle.com Fri Feb 20 14:43:42 2015 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 20 Feb 2015 15:43:42 +0100 Subject: RFR: 8073554: Remove unnecessary includes of markSweep[.inline].hpp In-Reply-To: <54E7448F.6060907@oracle.com> References: <54E7448F.6060907@oracle.com> Message-ID: <1424443422.3267.9.camel@oracle.com> Hi, On Fri, 2015-02-20 at 15:28 +0100, Stefan Karlsson wrote: > Hi, > > Please review the removal of some unnecessary includes of MarkSweep > files from non-GC code. > > http://cr.openjdk.java.net/~stefank/8073554/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8073554 > looks good. Thomas From stefan.karlsson at oracle.com Fri Feb 20 14:51:40 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 20 Feb 2015 15:51:40 +0100 Subject: RFR: 8073554: Remove unnecessary includes of markSweep[.inline].hpp In-Reply-To: <1424443422.3267.9.camel@oracle.com> References: <54E7448F.6060907@oracle.com> <1424443422.3267.9.camel@oracle.com> Message-ID: <54E749FC.9010807@oracle.com> On 2015-02-20 15:43, Thomas Schatzl wrote: > Hi, > > On Fri, 2015-02-20 at 15:28 +0100, Stefan Karlsson wrote: >> Hi, >> >> Please review the removal of some unnecessary includes of MarkSweep >> files from non-GC code. >> >> http://cr.openjdk.java.net/~stefank/8073554/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8073554 >> > looks good. Thanks, StefanK > > Thomas > > From coleen.phillimore at oracle.com Fri Feb 20 15:22:51 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 20 Feb 2015 10:22:51 -0500 Subject: RFR: 8073554: Remove unnecessary includes of markSweep[.inline].hpp In-Reply-To: <54E7448F.6060907@oracle.com> References: <54E7448F.6060907@oracle.com> Message-ID: <54E7514B.5000600@oracle.com> Looks great. I don't think this needs 24 hr turnaround. Coleen On 2/20/15, 9:28 AM, Stefan Karlsson wrote: > Hi, > > Please review the removal of some unnecessary includes of MarkSweep > files from non-GC code. > > http://cr.openjdk.java.net/~stefank/8073554/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8073554 > > Thanks, > StefanK From stefan.karlsson at oracle.com Fri Feb 20 15:29:29 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 20 Feb 2015 16:29:29 +0100 Subject: RFR: 8073554: Remove unnecessary includes of markSweep[.inline].hpp In-Reply-To: <54E7514B.5000600@oracle.com> References: <54E7448F.6060907@oracle.com> <54E7514B.5000600@oracle.com> Message-ID: <54E752D9.2000002@oracle.com> On 2015-02-20 16:22, Coleen Phillimore wrote: > Looks great. I don't think this needs 24 hr turnaround. Great. Thanks! StefanK > Coleen > > On 2/20/15, 9:28 AM, Stefan Karlsson wrote: >> Hi, >> >> Please review the removal of some unnecessary includes of MarkSweep >> files from non-GC code. >> >> http://cr.openjdk.java.net/~stefank/8073554/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8073554 >> >> Thanks, >> StefanK > From karen.kinnear at oracle.com Fri Feb 20 16:04:35 2015 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 20 Feb 2015 11:04:35 -0500 Subject: RFR: 7143664: Clean up OrderAccess implementations and usage In-Reply-To: References: Message-ID: <91056808-A32B-4713-A061-0E9AED4A5157@oracle.com> Erik, I am so grateful you tackled this problem I very much appreciate the additional potential stability with the fixes. Thank you to you and David for walking through the compiler and platform details, and for checking that the generated code here makes sense. Comments/questions on webrev.v3 open 0. orderAccess.hpp Thank you for the updated comments and table - very helpful! 1. orderAccess.hpp Were you going to add a comment about MSVC assumptions under C++ Volatile Semantics? Is it worth documenting in source somewhere what minimal versions of compilers are assumed? Or which versions of compilers were tested? I think that would help us in future please. Maybe in the platform-specific files? 2. orderAccess_windows_x86.inline.hpp Could you possibly add to the comment about MSVC, that this assumes all of the Scoped templates explicitly cast the addresses to volatiles? (In case someone changes that some day?) 3. orderAccess_windows_x86.inline.hpp So I looked up _ReadWriteBarrier and VS2012 and VS2013 say this is deprecated. JDK8 builds on VS2010, so ok. JDK9 appears to be planning to move to VS2013, so we may need to change this. It appears that the recommendation is volatile (with default on x86 of /volatile:ms). Can we use __asm__volatile("" : : : "memory"; compiler _barrier for VS2013 or is there an equivalent you know about? 4. orderAccess_windows_x86.inline.hpp, OrderAccess_bsd_x86.inline.hpp specialized_release_store_fence gets turned into a jint*? I have avoided FP all my life, so I had assumed that the old *p = v when declared jfloat*/jfloat would use floating point and the new one would cast to an int? Or does this work in the debugger? If so, a comment would be helpful. So - do you have plans to do additional changes to the OrderAccess logic? Beyond getting rid of the obsolete entries when all platforms are ok with it? Looks like we have a couple of follow-up exercises: 1) check our is_MP usage to ensure we get the compiler_barriers in both paths if we are not using volatile declarations for all compiler ordering 2) try applying these templates to any other platforms to see how well they work for us as maintainers 3) figure out why we use StubRoutines::fence on amd64 Windows but on linux we just use lock; addl 0(sp), MSVC limitation? I did not review ppc, zero, arm. thanks! Karen On Jan 22, 2015, at 8:19 PM, Erik ?sterlund wrote: > Hi all, > > == Summary of Changes == > > This changeset fixes issues in OrderAccess on multiple levels from the > memory model semantics to compiler reorderings, to addressing > maintainability/portability issues which (almost) had to be fixed in > order to fix the correctness issues. It is the result of discussions > found in the previous "OrderAccess Refactoring" thread: > http://openjdk.5641.n7.nabble.com/OrderAccess-Refactoring-td212050.html > > Bug ID: > https://bugs.openjdk.java.net/browse/JDK-7143664 > (updated to reflect these related changes) > > Webrev: > http://cr.openjdk.java.net/~dholmes/7143664/webrev/ > > Before I describe more I would like to give special thanks to David > Holmes for long discussions leading up to the currently proposed > changes. I would also like to thank Jesper Wilhelmsson for helping me > run my changes through JPRT. > > == Motivation == > > This change directly fixes a reported OrderAccess bug due to compiler > reorderings which is still a vulnerability on almost all TSO platforms: > https://bugs.openjdk.java.net/browse/JDK-806196 > > And directly fixes confusions like release_store() != release() store() > due to memory model issues previously described in this bug ID. > > At the same time it provides clearer design with separation of concerns > and generalization/specialization, removing a whole bunch of platform > specific code which could be generalized. The platform specific files > now only have a few LoC requirements (~7) to conform to the memory model > by specifying what the stand alone barriers do. Then optionally > optimizations to the general approach are possible if platforms support > it. This also makes it much easier to port to new platforms. > > == Memory Model == > > The current definitions of acquire/release semantics are a bit fishy > leading to problems previously described in the bug ID (release_store() > != release() store()) and some other correctness issues. It has > therefore been replaced with a new model. I would like to thank David > Holmes for the long discussions leading up to the newly proposed model. > > The new model is formally defined like this: > > // T1: access_shared_data > // T1: ]release > // T1: (...) > // T1: store(X) > // > // T2: load(X) > // T2: (...) > // T2: acquire[ > // T2: access_shared_data > // > // It is guaranteed that if T2: load(X) synchronizes with (observes the > // value written by) T1: store(X), then the memory accesses before the > // T1: ]release happen before the memory accesses after the T2: acquire[. > > The orderAccess.hpp file and bug ID also has a few additional > explanations making it more intuitive to the user when to use > acquire/release and the resemblance to TSO abstract machines. Big thanks > goes to David Holmes for discussing the memory model with me, which > helped a lot in deriving it. > > Now it holds that release() store() == release_store(), and the other > correctness issues are fixed as well. > > The new model is also closer to C++11 definitions which could give us > more relaxed compiler reordering constraints in the future when compiler > support for C++11 is there and ready. > > == Reliance on C++ Volatile Semantics == > > The C++ standard section 1.9 "Program Execution" is very vague about > what the keyword volatile can actually do for us. It gives clear > constraints in terms of volatile-volatile accesses but says little about > nonvolatile-volatile accesses. Yet the current implementation heavily > relies upon volatile to in terms of compiler reordering. But GCC > explicitly declares that volatiles and non-volatiles may reorder freely > ( https://gcc.gnu.org/onlinedocs/gcc/Volatiles.html ). The only compiler > known to explicitly provide the wanted semantics with volatile is MSVC > 2010 for windows ( > https://msdn.microsoft.com/en-us/library/12a04hfd(v=vs.100).aspx ). > Compilers not giving explicit guarantees, must be considered unsafe and > revert to conservative behaviour. > > This was brought to attention after causing bugs, but was only fixed for > x86 linux. This is a fundamental issue inherent to all TSO platforms > except windows, and has to be fixed on all of them. > > Several barriers are unsafe to use because they lack compiler reordering > constraints (e.g. fence and acquire on linux_SPARC). For TSO platforms > they are typically implemented using dummy loads and stores. This seems > to be another old volatile reliance that I fixed. These barriers > sometimes have omitted compiler barriers (which is what we really want). > This seems to be another example on incorrect reliance on the volatile > semantics to help us. Therefore dummy loads/stores have been replaced > with compiler barriers on TSO platforms. > > It is also worth noting that compilers like sun studio did previously > not support inline asm syntax. Therefore, barriers were implemented in > .il-files. However, using them does not give explicit compiler > constraints for reordering AFAIK. Therefore, they have been > reimplemented using inline asm with explicit compiler reordering > constraints, as even sun (solaris?) studio now supports this. > > The windows variants have added a windows-style _ReadWriteBarrier() > compiler barrier similarly. > > == Strange Hardware Reorderings == > > Fixed a weird inconsistency where acquire, loadstore and loadlaod would > use isync instead of lwsync for PPC on linux_zero, but not in any other > PPC platform in the repo. I assumed this is wrong and changed it to > lwsync instead. > > == Code Redundancy and Refactoring == > > The OrderAccess code looks like it has been developed over a long period > of time, with small incremental changes. This seems to have led to a lot > of code duplication over time. For example, store_fence variants are not > referenced from anywhere, yet contribute to a lot of the code base and a > lot of awkwardness (such as being the one only exception not using > volatiles for some reason). Moreover, store_fence is not used anywhere > in hotspot because it is not a good fit for either the acquire/release > semantics or the Java volatile semantics, leaving a big question mark on > when it should ever be used. I took the liberty of removing it. > > Another redundancy issue is that most of the semantics is exactly the > same for all platforms, yet all that default boilerplate such as how to > make atomic accesses, where acquire/release is supposed to be placed > w.r.t. the memory access, what the different barriers should do etc. is > copied in redundantly for each os_cpu and each type of memory access for > each os_cpu. This makes it extremely painful 1) to understand what > actually defines a certain platform compared to the defaults and 2) to > correct bugs like those discovered here 3) prevent silly mistakes and > bugs, by simply having a lot less code defining the behaviour of > OrderAccess that could go wrong. > > A new architecture/design for OrderAccess is proposed, using a > generalization/specialization approach. > > A general implementation in /share/ defines how things work and splits > into different concerns: 1) how to make an atomic memory access, 2) > where to but barriers w.r.t. the memory access for things like > load_acquire, release_store and release_store_fence, 3) how these > barriers are defined. > > This allows a clear split between what is required for following the > specifications, and optimizations, which become much more readable and > only optimizations need to be reviewed in depth as the defaults can > always be trusted given correct standalone barriers. > > The only thing a platform is required to specify, is what an > implementation of acquire(), release() and fence() should do. If they > are implemented properly, everything in OrderAccess is guaranteed to > work according to specification using the generalized code. This makes > it very easy to support new ports. ALL the other code in the os_cpu > files is used /only/ for optimization purposes offered for specific > configurations. > > However, it is highly customizable so that specific platform can perform > any desired optimizations. For instance this load_acquire on PPC is > optimized: > > template<> inline jbyte OrderAccess::specialized_load_acquire > (volatile jbyte* p) { register jbyte t = load(p); > inlasm_acquire_reg(t); return t; } > > This overrides the whole load_acquire implementation to do something > custom. Platforms like x86 extensively use this for joined fencing > variants to optimize. > > The default implementation of load_acquire() will make an atomic load() > followed by acquire() since the semantics is generalized. The > generalized semantics are defined using inlined postfix/prefix calls > after/before the atomic access, as defined here: > > template<> inline void ScopedFenceGeneral::postfix() { > OrderAccess::acquire(); } > template<> inline void ScopedFenceGeneral::prefix() { > OrderAccess::release(); } > template<> inline void ScopedFenceGeneral::prefix() { > OrderAccess::release(); } > template<> inline void ScopedFenceGeneral::postfix() { > OrderAccess::fence(); } > > For platforms that simply wish to override what e.g. acquire means for a > joined ordered memory access in general, as different to calling stand > alone acquire(), the semantics can be easily overridden for a platform > such as windows like on windows: > > template<> inline void ScopedFence::postfix() { } > template<> inline void ScopedFence::prefix() { } > template<> inline void ScopedFence::prefix() { } > template<> inline void ScopedFence::postfix() { > OrderAccess::fence(); } > > In this example, since Windows (now) has a compiler barrier for acquire, > but does not need it for joined accesses since volatile has stronger > guarantees on windows, this is enough to specialize that for joined > memory accesses, no extra protection is needed. > > == Backward Compatibility and Transitioning == > > Since the newly proposed code is structured differently to before, a > #define was added for backward compatibility so that external > repositories not adhering to this new architecture do not break. > Furthermore, store_release was declared private and marked as > deprecated. This allows for a smooth transition into the new style of > OrderAccess. When the full transition is made in all known repos, the > #define and store_fence may be safely removed, eventually. > > == Documentation == > > The documentation seems old and outdated, describing how it works on > SPARC RMO and IA64, which are nowhere to be found in the repository. It > also describes things about C++ volatiles which cannot be relied upon. > The documentation has been cleaned up to match the current state of the > implementation better, with architectures actually found in the repository. > > == Testing == > > JPRT. Big thanks to Jesper Wilhelmsson for helping me test these changes. > Ran some DaCapo benchmarks (I know okay :p) for performance regression > and there was no perceivable difference. > > Looking forward to feedback on this, and hope to get some reviews. :) > > Thanks, > Erik From coleen.phillimore at oracle.com Fri Feb 20 17:56:00 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 20 Feb 2015 12:56:00 -0500 Subject: RFR (M) 8046246: the constantPoolCacheOopDesc::adjust_method_entries() used in RedefineClasses does not scale In-Reply-To: <54E57884.8030200@oracle.com> References: <54E57884.8030200@oracle.com> Message-ID: <54E77530.5060104@oracle.com> Hi Serguei, This looks good but I have some comments: http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.1/src/share/vm/oops/klassVtable.cpp.udiff.html How can (old_method == new_method) in adjust_method_entries? If old_method->is_old() then you're not updating the vtables or the itable? It should assert with check_no_old_or_obsolete_entries() at the end. http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.1/src/share/vm/oops/cpCache.cpp.udiff.html It looks like is_interesting_method_entry and get_interesting_method_entry are the same code only one returns bool and the other returns the Method*. Can you call is_interesting_method_entry and check for null return so there are not two copies of this code? thanks, Coleen On 2/19/15, 12:45 AM, serguei.spitsyn at oracle.com wrote: > Please, review the fix for: > https://bugs.openjdk.java.net/browse/JDK-8046246 > > > Open hotspot webrevs: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.1/ > > > Open jdk (new unit test) webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8046246-JVMTI-manymethods.1/ > > > > Summary: > > This performance/scalability issue in class redefinition was > reported by HP and the Enterprise Manager team. > The following variants of the adjust_method_entries() functions do > not scale: > ConstantPoolCache::adjust_method_entries() > klassVtable::adjust_method_entries() > klassItable::adjust_method_entries() > InstanceKlass::adjust_default_methods() > > The ConstantPoolCache::adjust_method_entries() is the most important. > > The approach is to use the holder->method_with_idnum() like this: > Method* new_method = > holder->method_with_idnum(old_method->orig_method_idnum()); > if (old_method != new_method) { > > } > > New algorithm has effectiveness O(M) instead of original O(M^2), > where M is count of methods in the class. > The new test (see webrev above) was used to mesure CPU time > consumed by the > ConstantPoolCache::adjust_method_entries() in both original and > new approach. > > The performance numbers are: > > --------------------------------------------------------------------------------------- > > Methods: ------ 1,000 --------------- 10,000 ----------------- > 20,000 > --------------------------------------------------------------------------------------- > > Orig: 600,000 nsec (1x) 60,500,000 nsec (~100x) > 243,000,000 nsec (~400x) > New: 16,000 nsec (1x) 178,000 nsec (~10x) 355,000 > nsec (~20x) > --------------------------------------------------------------------------------------- > > > > > Testing: > In progress: VM SQE RedefineClasses tests, JTREG > java/lang/instrument, com/sun/jdi tests > > > Thanks, > Serguei > From erik.osterlund at lnu.se Fri Feb 20 18:24:00 2015 From: erik.osterlund at lnu.se (=?iso-8859-1?Q?Erik_=D6sterlund?=) Date: Fri, 20 Feb 2015 18:24:00 +0000 Subject: RFR: 7143664: Clean up OrderAccess implementations and usage References: <91056808-A32B-4713-A061-0E9AED4A5157@oracle.com> Message-ID: Hi Karen, On 20/02/15 17:04, Karen Kinnear wrote: > Erik, > > I am so grateful you tackled this problem I very much appreciate the additional potential > stability with the fixes. > > Thank you to you and David for walking through the compiler and platform details, and > for checking that the generated code here makes sense. No problem! :) > Comments/questions on webrev.v3 open > 0. orderAccess.hpp > Thank you for the updated comments and table - very helpful! > > 1. orderAccess.hpp > Were you going to add a comment about MSVC assumptions under C++ Volatile Semantics? > > Is it worth documenting in source somewhere what minimal versions of compilers are assumed? > Or which versions of compilers were tested? I think that would help us in future please. > Maybe in the platform-specific files? I did not intend to add this comment to shared. I thought that it would be enough to say that non-volatile to volatile constraints can not be trusted in general. Instead there is a comment explaining this anomaly in orderAccess_windows_x86.inline.hpp where it is exploited, since it is the only documented exception I know of. If we start picking certain examples, it feels like we should rather have either 1) a comprehensive table of what volatile actually means for different compilers with references or question marks where we don't know (and hence need to be conservative assuming the worst), or 2) putting such comments in platform specific files (like MSVC currently). Do you agree? In that case, which one do you prefer? As for documenting compiler versions assumed, would it be enough to stamp the code with the currently used compilers we used now, even though it might actually have worked with earlier versions? The reasoning is that it's unlikely we will go back to using earlier compilers anyway, so finding out when exactly certain compilers started doing what we want them to could possibly be unnecessary, while still having enough information to allow checking if future compilers have provided improved functionality from this version of OrderAccess? > 2. orderAccess_windows_x86.inline.hpp > Could you possibly add to the comment about MSVC, that this assumes all of the Scoped templates explicitly cast the addresses to volatiles? > (In case someone changes that some day?) Sure! But is this not clear given the comment in orderAccess_windows_x86.inline.hpp where this is exploited next to the scope template specialization: // Note that in MSVC, volatile memory accesses are explicitly // guaranteed to have acquire release semantics (w.r.t. compiler // reordering) and therefore does not even need a compiler barrier // for normal acquire release accesses. template<> inline void ScopedFence::postfix() { } template<> inline void ScopedFence::prefix() { } template<> inline void ScopedFence::prefix() { } template<> inline void ScopedFence::postfix() { OrderAccess::fence(); } If you don't think this is clear enough, I would happily improve the description. > 3. orderAccess_windows_x86.inline.hpp > So I looked up _ReadWriteBarrier and VS2012 and VS2013 say this is deprecated. > JDK8 builds on VS2010, so ok. JDK9 appears to be planning to move to VS2013, so we may need to change this. > It appears that the recommendation is volatile (with default on x86 of /volatile:ms). Can we use __asm__volatile("" : : : "memory"; > compiler _barrier for VS2013 or is there an equivalent you know about? Unfortunately I currently have no access to windows platforms so I can't experiment around. But I did some research when I looked into it and it seems like _ReadWriteBarrier is all we got for now until we adopt C++11 std::atomic that Microsoft in the deprecation message on their website suggests we should use instead. It seems to have been deprecated because programmers found it confusing - the name does not suggest it's a compiler-only ordering constraint. But that's fine for our purposes. I just assumed that for now we probably don't want to make such a radical move to C++11, right? Since it was deprecation or C++11 I intentionally used _ReadWriteBarrier anyway even though it is deprecated. Is this a problem? When we need to switch, I believe we will be forced to use C++11 on windows whether we like it or not. It has std::atomic_signal_fence which should work as a drop-in replacement for _ReadWriteBarrier AFAIK. But then again, we might as well just map all calls to std::atomic if we gotta use C++11 anyway... > 4. orderAccess_windows_x86.inline.hpp, OrderAccess_bsd_x86.inline.hpp > specialized_release_store_fence gets turned into a jint*? > I have avoided FP all my life, so I had assumed that the old *p = v when declared jfloat*/jfloat would use floating point > and the new one would cast to an int? Or does this work in the debugger? If so, a comment would be helpful. Sorry I'm not sure I understand what you mean here. The code casts jfloat to jint in the same way that it always casted jdouble to jlong. Is this a problem? > So - do you have plans to do additional changes to the OrderAccess logic? Beyond getting rid of the obsolete entries > when all platforms are ok with it? My biggest concern was correctness and I felt it really had to be done. I use OrderAccess for my own GC code a lot, and needed to tame it a bit to work, and thought I might as well contribute the fixes too. ;) Having looked into the code a bit I know there is still room improvements in places if you would like me to look into it. Some examples: 1) x86_64 windows - I suspect this can be improved a /lot/. It seems like compilers were broken when the code was written at the very transition point to 64 bit. I believe this can be optimized to use compiler support I expect is in place today. 2) x86 on solaris: solaris studio was also crippled in the past with no inline assembly. I believe these optimizations we see on other platforms could now be ported to solaris as well. 3) _volatile variants of acquire/release/fence/membars: Now we are conservative, taking volatile to non-volatile reordering into account using compiler barriers. If the programmer knows this is not needed since all data published is volatile, maybe it could be good to have variants explicitly stating it won't be necessary. 4) Joining more store(); release(); pairs to store_release() since some platforms like ARM can then use stlr instead of full dmb fence which seems like a good thing in general anyway. All previous suggestions revolve around performance (and I don't know how much we need it). But could also do other things. Testing: 5) Testing code: it is possible using some light template metaprogramming to test if the expected specializations of OrderAccess are indeed used, a bit like @Override in Java - asserting that the generalized behaviour is indeed specialized as expected for all types we expect them to be specialized for. Further refactoring: 6) Forwarding all atomic memory accesses to Atomic:: since it's really a separate concern. Atomic:: should know how to make atomic accesses for types used by OrderAccess, and OrderAccess should in shared code just forward it. Currently Atomic supports all stores but only load of jlong, making assumptions the rest can use volatile only - an assumption I'm not willing to make and spread around in the JVM. The main problem though is that OrderAcces changes are often inherently platform specific, and I have very limited access as an outsider to the platforms. This time, Jesper has been very kind to me, running JPRT for me which made these changes possible, and I'm very happy about that. But maybe I should do less platform specific things when I can't run JPRT. I don't want to bother people with compiling code for me too much, especially not if experimenting with what new compiler features have been added over the years. :) > Looks like we have a couple of follow-up exercises: > 1) check our is_MP usage to ensure we get the compiler_barriers in both paths if we are not using volatile declarations for > all compiler ordering > 2) try applying these templates to any other platforms to see how well they work for us as maintainers > 3) figure out why we use StubRoutines::fence on amd64 Windows but on linux we just use lock; addl 0(sp), MSVC limitation? Yes I could volunteer to do 2 (only open variants of course) and 3 if anyone would be kind to run JPRT for me and/or provide me with machines I can try things out on (which I suspect is impossible?). > I did not review ppc, zero, arm. I should mention Zero changes were reviewed by Severin Gehwolf in the zero-dev list. He did not have any problem with my changes. Thanks for the review Karen! :) /Erik > > thanks! > Karen > On Jan 22, 2015, at 8:19 PM, Erik ?sterlund wrote: > >> Hi all, >> >> == Summary of Changes == >> >> This changeset fixes issues in OrderAccess on multiple levels from the >> memory model semantics to compiler reorderings, to addressing >> maintainability/portability issues which (almost) had to be fixed in >> order to fix the correctness issues. It is the result of discussions >> found in the previous "OrderAccess Refactoring" thread: >> http://openjdk.5641.n7.nabble.com/OrderAccess-Refactoring-td212050.html >> >> Bug ID: >> https://bugs.openjdk.java.net/browse/JDK-7143664 >> (updated to reflect these related changes) >> >> Webrev: >> http://cr.openjdk.java.net/~dholmes/7143664/webrev/ >> >> Before I describe more I would like to give special thanks to David >> Holmes for long discussions leading up to the currently proposed >> changes. I would also like to thank Jesper Wilhelmsson for helping me >> run my changes through JPRT. >> >> == Motivation == >> >> This change directly fixes a reported OrderAccess bug due to compiler >> reorderings which is still a vulnerability on almost all TSO platforms: >> https://bugs.openjdk.java.net/browse/JDK-806196 >> >> And directly fixes confusions like release_store() != release() store() >> due to memory model issues previously described in this bug ID. >> >> At the same time it provides clearer design with separation of concerns >> and generalization/specialization, removing a whole bunch of platform >> specific code which could be generalized. The platform specific files >> now only have a few LoC requirements (~7) to conform to the memory model >> by specifying what the stand alone barriers do. Then optionally >> optimizations to the general approach are possible if platforms support >> it. This also makes it much easier to port to new platforms. >> >> == Memory Model == >> >> The current definitions of acquire/release semantics are a bit fishy >> leading to problems previously described in the bug ID (release_store() >> != release() store()) and some other correctness issues. It has >> therefore been replaced with a new model. I would like to thank David >> Holmes for the long discussions leading up to the newly proposed model. >> >> The new model is formally defined like this: >> >> // T1: access_shared_data >> // T1: ]release >> // T1: (...) >> // T1: store(X) >> // >> // T2: load(X) >> // T2: (...) >> // T2: acquire[ >> // T2: access_shared_data >> // >> // It is guaranteed that if T2: load(X) synchronizes with (observes the >> // value written by) T1: store(X), then the memory accesses before the >> // T1: ]release happen before the memory accesses after the T2: acquire[. >> >> The orderAccess.hpp file and bug ID also has a few additional >> explanations making it more intuitive to the user when to use >> acquire/release and the resemblance to TSO abstract machines. Big thanks >> goes to David Holmes for discussing the memory model with me, which >> helped a lot in deriving it. >> >> Now it holds that release() store() == release_store(), and the other >> correctness issues are fixed as well. >> >> The new model is also closer to C++11 definitions which could give us >> more relaxed compiler reordering constraints in the future when compiler >> support for C++11 is there and ready. >> >> == Reliance on C++ Volatile Semantics == >> >> The C++ standard section 1.9 "Program Execution" is very vague about >> what the keyword volatile can actually do for us. It gives clear >> constraints in terms of volatile-volatile accesses but says little about >> nonvolatile-volatile accesses. Yet the current implementation heavily >> relies upon volatile to in terms of compiler reordering. But GCC >> explicitly declares that volatiles and non-volatiles may reorder freely >> ( https://gcc.gnu.org/onlinedocs/gcc/Volatiles.html ). The only compiler >> known to explicitly provide the wanted semantics with volatile is MSVC >> 2010 for windows ( >> https://msdn.microsoft.com/en-us/library/12a04hfd(v=vs.100).aspx ). >> Compilers not giving explicit guarantees, must be considered unsafe and >> revert to conservative behaviour. >> >> This was brought to attention after causing bugs, but was only fixed for >> x86 linux. This is a fundamental issue inherent to all TSO platforms >> except windows, and has to be fixed on all of them. >> >> Several barriers are unsafe to use because they lack compiler reordering >> constraints (e.g. fence and acquire on linux_SPARC). For TSO platforms >> they are typically implemented using dummy loads and stores. This seems >> to be another old volatile reliance that I fixed. These barriers >> sometimes have omitted compiler barriers (which is what we really want). >> This seems to be another example on incorrect reliance on the volatile >> semantics to help us. Therefore dummy loads/stores have been replaced >> with compiler barriers on TSO platforms. >> >> It is also worth noting that compilers like sun studio did previously >> not support inline asm syntax. Therefore, barriers were implemented in >> .il-files. However, using them does not give explicit compiler >> constraints for reordering AFAIK. Therefore, they have been >> reimplemented using inline asm with explicit compiler reordering >> constraints, as even sun (solaris?) studio now supports this. >> >> The windows variants have added a windows-style _ReadWriteBarrier() >> compiler barrier similarly. >> >> == Strange Hardware Reorderings == >> >> Fixed a weird inconsistency where acquire, loadstore and loadlaod would >> use isync instead of lwsync for PPC on linux_zero, but not in any other >> PPC platform in the repo. I assumed this is wrong and changed it to >> lwsync instead. >> >> == Code Redundancy and Refactoring == >> >> The OrderAccess code looks like it has been developed over a long period >> of time, with small incremental changes. This seems to have led to a lot >> of code duplication over time. For example, store_fence variants are not >> referenced from anywhere, yet contribute to a lot of the code base and a >> lot of awkwardness (such as being the one only exception not using >> volatiles for some reason). Moreover, store_fence is not used anywhere >> in hotspot because it is not a good fit for either the acquire/release >> semantics or the Java volatile semantics, leaving a big question mark on >> when it should ever be used. I took the liberty of removing it. >> >> Another redundancy issue is that most of the semantics is exactly the >> same for all platforms, yet all that default boilerplate such as how to >> make atomic accesses, where acquire/release is supposed to be placed >> w.r.t. the memory access, what the different barriers should do etc. is >> copied in redundantly for each os_cpu and each type of memory access for >> each os_cpu. This makes it extremely painful 1) to understand what >> actually defines a certain platform compared to the defaults and 2) to >> correct bugs like those discovered here 3) prevent silly mistakes and >> bugs, by simply having a lot less code defining the behaviour of >> OrderAccess that could go wrong. >> >> A new architecture/design for OrderAccess is proposed, using a >> generalization/specialization approach. >> >> A general implementation in /share/ defines how things work and splits >> into different concerns: 1) how to make an atomic memory access, 2) >> where to but barriers w.r.t. the memory access for things like >> load_acquire, release_store and release_store_fence, 3) how these >> barriers are defined. >> >> This allows a clear split between what is required for following the >> specifications, and optimizations, which become much more readable and >> only optimizations need to be reviewed in depth as the defaults can >> always be trusted given correct standalone barriers. >> >> The only thing a platform is required to specify, is what an >> implementation of acquire(), release() and fence() should do. If they >> are implemented properly, everything in OrderAccess is guaranteed to >> work according to specification using the generalized code. This makes >> it very easy to support new ports. ALL the other code in the os_cpu >> files is used /only/ for optimization purposes offered for specific >> configurations. >> >> However, it is highly customizable so that specific platform can perform >> any desired optimizations. For instance this load_acquire on PPC is >> optimized: >> >> template<> inline jbyte OrderAccess::specialized_load_acquire >> (volatile jbyte* p) { register jbyte t = load(p); >> inlasm_acquire_reg(t); return t; } >> >> This overrides the whole load_acquire implementation to do something >> custom. Platforms like x86 extensively use this for joined fencing >> variants to optimize. >> >> The default implementation of load_acquire() will make an atomic load() >> followed by acquire() since the semantics is generalized. The >> generalized semantics are defined using inlined postfix/prefix calls >> after/before the atomic access, as defined here: >> >> template<> inline void ScopedFenceGeneral::postfix() { >> OrderAccess::acquire(); } >> template<> inline void ScopedFenceGeneral::prefix() { >> OrderAccess::release(); } >> template<> inline void ScopedFenceGeneral::prefix() { >> OrderAccess::release(); } >> template<> inline void ScopedFenceGeneral::postfix() { >> OrderAccess::fence(); } >> >> For platforms that simply wish to override what e.g. acquire means for a >> joined ordered memory access in general, as different to calling stand >> alone acquire(), the semantics can be easily overridden for a platform >> such as windows like on windows: >> >> template<> inline void ScopedFence::postfix() { } >> template<> inline void ScopedFence::prefix() { } >> template<> inline void ScopedFence::prefix() { } >> template<> inline void ScopedFence::postfix() { >> OrderAccess::fence(); } >> >> In this example, since Windows (now) has a compiler barrier for acquire, >> but does not need it for joined accesses since volatile has stronger >> guarantees on windows, this is enough to specialize that for joined >> memory accesses, no extra protection is needed. >> >> == Backward Compatibility and Transitioning == >> >> Since the newly proposed code is structured differently to before, a >> #define was added for backward compatibility so that external >> repositories not adhering to this new architecture do not break. >> Furthermore, store_release was declared private and marked as >> deprecated. This allows for a smooth transition into the new style of >> OrderAccess. When the full transition is made in all known repos, the >> #define and store_fence may be safely removed, eventually. >> >> == Documentation == >> >> The documentation seems old and outdated, describing how it works on >> SPARC RMO and IA64, which are nowhere to be found in the repository. It >> also describes things about C++ volatiles which cannot be relied upon. >> The documentation has been cleaned up to match the current state of the >> implementation better, with architectures actually found in the repository. >> >> == Testing == >> >> JPRT. Big thanks to Jesper Wilhelmsson for helping me test these changes. >> Ran some DaCapo benchmarks (I know okay :p) for performance regression >> and there was no perceivable difference. >> >> Looking forward to feedback on this, and hope to get some reviews. :) >> >> Thanks, >> Erik > > From serguei.spitsyn at oracle.com Fri Feb 20 19:19:03 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 20 Feb 2015 11:19:03 -0800 Subject: RFR (M) 8046246: the constantPoolCacheOopDesc::adjust_method_entries() used in RedefineClasses does not scale In-Reply-To: <54E77530.5060104@oracle.com> References: <54E57884.8030200@oracle.com> <54E77530.5060104@oracle.com> Message-ID: <54E788A7.1000103@oracle.com> Hi Coleen, On 2/20/15 9:56 AM, Coleen Phillimore wrote: > > Hi Serguei, This looks good but I have some comments: Thanks a lot for good suggestions and help in the internal review! > > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.1/src/share/vm/oops/klassVtable.cpp.udiff.html > > > How can (old_method == new_method) in adjust_method_entries? If > old_method->is_old() then you're not updating the vtables or the > itable? It should assert with check_no_old_or_obsolete_entries() at > the end. Nice catch, fixed in all 4 places. > > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.1/src/share/vm/oops/cpCache.cpp.udiff.html > > > It looks like is_interesting_method_entry and > get_interesting_method_entry are the same code only one returns bool > and the other returns the Method*. Can you call > is_interesting_method_entry and check for null return so there are not > two copies of this code? Nice catch as well, fixed. I'll post the updated webrev after some testing. Thanks, Serguei > > thanks, > Coleen > > On 2/19/15, 12:45 AM, serguei.spitsyn at oracle.com wrote: >> Please, review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-8046246 >> >> >> Open hotspot webrevs: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.1/ >> >> >> Open jdk (new unit test) webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8046246-JVMTI-manymethods.1/ >> >> >> >> Summary: >> >> This performance/scalability issue in class redefinition was >> reported by HP and the Enterprise Manager team. >> The following variants of the adjust_method_entries() functions do >> not scale: >> ConstantPoolCache::adjust_method_entries() >> klassVtable::adjust_method_entries() >> klassItable::adjust_method_entries() >> InstanceKlass::adjust_default_methods() >> >> The ConstantPoolCache::adjust_method_entries() is the most important. >> >> The approach is to use the holder->method_with_idnum() like this: >> Method* new_method = >> holder->method_with_idnum(old_method->orig_method_idnum()); >> if (old_method != new_method) { >> >> } >> >> New algorithm has effectiveness O(M) instead of original O(M^2), >> where M is count of methods in the class. >> The new test (see webrev above) was used to mesure CPU time >> consumed by the >> ConstantPoolCache::adjust_method_entries() in both original and >> new approach. >> >> The performance numbers are: >> >> --------------------------------------------------------------------------------------- >> >> Methods: ------ 1,000 --------------- 10,000 ----------------- >> 20,000 >> --------------------------------------------------------------------------------------- >> >> Orig: 600,000 nsec (1x) 60,500,000 nsec (~100x) >> 243,000,000 nsec (~400x) >> New: 16,000 nsec (1x) 178,000 nsec (~10x) 355,000 >> nsec (~20x) >> --------------------------------------------------------------------------------------- >> >> >> >> >> Testing: >> In progress: VM SQE RedefineClasses tests, JTREG >> java/lang/instrument, com/sun/jdi tests >> >> >> Thanks, >> Serguei >> > From anthony.scarpino at oracle.com Fri Feb 20 20:58:31 2015 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 20 Feb 2015 12:58:31 -0800 Subject: RFR: 8073108: GHASH Intrinsics In-Reply-To: <54E68FBA.1090904@oracle.com> References: <54E25D03.7090705@oracle.com> <54E6855F.4050308@oracle.com> <54E68FBA.1090904@oracle.com> Message-ID: <54E79FF7.1040800@oracle.com> On 02/19/2015 05:36 PM, Vladimir Kozlov wrote: > JDK changes review. > ------------------- > All exceptions should print invalid value as you did for state and > subkeyH checks. It would greatly help debugging. > > Please, split first check into 3 separate checks and print invalid value > to know which condition failed. > > Missing space after 'length': "invalid length"+subkeyH.length webrev updated: http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev.02/ Tony From serguei.spitsyn at oracle.com Fri Feb 20 21:32:44 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 20 Feb 2015 13:32:44 -0800 Subject: 2-nd round RFR (M) 8046246: the constantPoolCacheOopDesc::adjust_method_entries() used in RedefineClasses does not scale In-Reply-To: <54E57884.8030200@oracle.com> References: <54E57884.8030200@oracle.com> Message-ID: <54E7A7FC.9090709@oracle.com> The hotspot webrev below addresses the Coleen's comments from the 1-st review round. Open hotspot webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.2/ Open jdk (new unit test) webrev: http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8046246-JVMTI-manymethods.1/ Thanks, Serguei On 2/18/15 9:45 PM, serguei.spitsyn at oracle.com wrote: > Please, review the fix for: > https://bugs.openjdk.java.net/browse/JDK-8046246 > > > Open hotspot webrevs: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.1/ > > > Open jdk (new unit test) webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8046246-JVMTI-manymethods.1/ > > > > Summary: > > This performance/scalability issue in class redefinition was > reported by HP and the Enterprise Manager team. > The following variants of the adjust_method_entries() functions do > not scale: > ConstantPoolCache::adjust_method_entries() > klassVtable::adjust_method_entries() > klassItable::adjust_method_entries() > InstanceKlass::adjust_default_methods() > > The ConstantPoolCache::adjust_method_entries() is the most important. > > The approach is to use the holder->method_with_idnum() like this: > Method* new_method = > holder->method_with_idnum(old_method->orig_method_idnum()); > if (old_method != new_method) { > > } > > New algorithm has effectiveness O(M) instead of original O(M^2), > where M is count of methods in the class. > The new test (see webrev above) was used to mesure CPU time > consumed by the > ConstantPoolCache::adjust_method_entries() in both original and > new approach. > > The performance numbers are: > > --------------------------------------------------------------------------------------- > > Methods: ------ 1,000 --------------- 10,000 ----------------- > 20,000 > --------------------------------------------------------------------------------------- > > Orig: 600,000 nsec (1x) 60,500,000 nsec (~100x) > 243,000,000 nsec (~400x) > New: 16,000 nsec (1x) 178,000 nsec (~10x) 355,000 > nsec (~20x) > --------------------------------------------------------------------------------------- > > > > > Testing: > In progress: VM SQE RedefineClasses tests, JTREG > java/lang/instrument, com/sun/jdi tests > > > Thanks, > Serguei > From kim.barrett at oracle.com Fri Feb 20 22:40:48 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 20 Feb 2015 17:40:48 -0500 Subject: RFR: 7143664: Clean up OrderAccess implementations and usage In-Reply-To: References: <91056808-A32B-4713-A061-0E9AED4A5157@oracle.com> Message-ID: <90AA856F-0340-4E58-BBCE-901700144E57@oracle.com> > http://cr.openjdk.java.net/~dholmes/7143664/webrev.v4/ I haven't reviewed all of the changes, instead focusing on the structure and use of templates. That generally looks fine; I have a few stylistic comments below, but nothing earth shaking. Some of the remaining comments, even if technically correct and acceptable, might not be appropriate for this change set, but should instead be dealt with in follow-on changes. ------------------------------------------------------------------------------ Throughout: I would probably have used some simple macros to avoid near duplication of a lot of groups of related functions that differ only in a type parameter. The present approach of making the groups of related functions "obviously" similar by putting the entire definition on one line so there are several nearly identical lines in a row makes me look at each of the lines carefully to make sure the several parallel differences are what's expected. It has the additional defect of involving very long lines, which makes them harder to review in side-by-side views. YMMV. ------------------------------------------------------------------------------ The ordered access operations are defined on jbyte ... jlong. The problem is that there is a type in that sequence that is the same size as two distinct C/C++ types. And as a result, one of those C/C++ types is missing atomic support. This can lead to problems with types like size_t on some platforms I also don't see atomic support for char*. This might be something to consider for a separate change. ------------------------------------------------------------------------------ An observation: If OrderAccess was a real namespace instead of a pseudo-namespace class, the specialized versions of the specialized_xxx functions could be ordinary function overloads rather than function template specializations. OTOH, namespaces don't provide private access control. I often find myself wishing for such a feature. No actual change needed here, just pointing out an interesting variation from the approach taken. ------------------------------------------------------------------------------ An observation: load_ptr_acquire isn't strictly necessary, and could be replaced by load_acquire with some additional work. But it might be the "_ptr_" in the name is considered useful documentation. Given that, load_ptr_acquire can be generalized to support any type of pointer, not just intptr_t* and void*. This would eliminate the need for casting result types in some places, and for some strange value types in others. For example MetaspaceGC::_capacity_until_gc is declared intptr_t rather than size_t. This might be something to consider for a separate change. ------------------------------------------------------------------------------ src/share/vm/runtime/orderAccess.hpp I don't see the point of having ScopedFence derive from ScopedFenceGeneral. It seems to me that ScopedFenceGeneral could derive from AllStatic (with corresponding changes to functions) and ScopedFence could instead derive from StackObj. ------------------------------------------------------------------------------ src/share/vm/runtime/orderAccess.hpp Why are ScopedFenceType, ScopedFenceGeneral, and ScopedFence defined at global scope rather than nested in OrderAccess? ------------------------------------------------------------------------------ src/share/vm/runtime/orderAccess.hpp For all load_acquire variants, why (volatile T* p) rather than (const volatile* p)? ------------------------------------------------------------------------------ src/share/vm/runtime/orderAccess.inline.hpp 75 #ifdef VM_HAS_GENERALIZED_ORDER_ACCESS I'm not sure what the point of this is. Is this just to allow some (perhaps third-party?) platforms to continue to use an old implementation? Or is it for incremental development of this set of changes? Is the plan that it will eventually go away? ------------------------------------------------------------------------------ src/share/vm/runtime/orderAccess.inline.hpp I think there needs to be some documentation here about which specialized_xxx functions can/should be considered for specialization. ------------------------------------------------------------------------------ src/share/vm/runtime/orderAccess.inline.hpp 138 // The following methods can be specialized using simple template specialization 139 // in the platform specific files for optimization purposes. Otherwise the 140 // generalized variant is used. 141 template inline T OrderAccess::specialized_load_acquire (volatile T* p) { return ordered_load(p); } 142 template inline void OrderAccess::specialized_release_store (volatile T* p, T v) { ordered_store(p, v); } 143 template inline void OrderAccess::specialized_release_store_fence(volatile T* p, T v) { ordered_store(p, v); } I *think* it doesn't matter in practice, but I would put these definitions before the potential instantiations. The relevant declarations are obviously in scope where those instantiations occur, and everything is declared inline, but I worry that some insufficiently clever compiler might end up generating out of line code in some cases because the definition was after use. ------------------------------------------------------------------------------ src/share/vm/runtime/orderAccess.inline.hpp 101 inline jubyte OrderAccess::load_acquire(volatile jubyte* p) { return (jubyte) specialized_load_acquire((volatile jbyte*)p); } 102 inline jushort OrderAccess::load_acquire(volatile jushort* p) { return (jushort)specialized_load_acquire((volatile jshort*)p); } 103 inline juint OrderAccess::load_acquire(volatile juint* p) { return (juint) specialized_load_acquire((volatile jint*)p); } 104 inline julong OrderAccess::load_acquire(volatile julong* p) { return (julong) specialized_load_acquire((volatile jlong*)p); } I would probably define these as calling load_acquire with casts, rather than directly calling specialized_load_acquire. Similarly for store_release and load_ptr_acquire variants. This would make it easier to fiddle with the how the specializations are implemented, and shorten the line lengths by a dozen characters. I would probably also have used some simple macrology to avoid near duplication of code. ------------------------------------------------------------------------------ src/os_cpu/linux_ppc/vm/orderAccess_linux_ppc.inline.hpp I see no uses of the inlasm_eieio macro. I see no uses of the inlasm_isync macro. From erik.osterlund at lnu.se Sat Feb 21 01:08:46 2015 From: erik.osterlund at lnu.se (=?iso-8859-1?Q?Erik_=D6sterlund?=) Date: Sat, 21 Feb 2015 01:08:46 +0000 Subject: RFR: 7143664: Clean up OrderAccess implementations and usage References: <91056808-A32B-4713-A061-0E9AED4A5157@oracle.com> <90AA856F-0340-4E58-BBCE-901700144E57@oracle.com> Message-ID: Hi Kim, Thanks for the review! :) In general: I might be a bit biased against the use of macros in general and avoid it whenever it can be avoided as you know. :) To me it seems a bit over engineered and unnecessarily complex to reduce the already quite small (84 LoC) code size of OrderAccess.inline.hpp with macros. And for me it's unclear what the benefit of such code size decrease would be. A means to reduce complexity, increase understandability? Probably not. A means to increase maintainability? Perhaps possible but not sure! But in matters where it's really up to personal taste, I'd like to not decide. Kim I will let you call the shots! Comments: On 20/02/15 23:41, Kim Barrett wrote: >> http://cr.openjdk.java.net/~dholmes/7143664/webrev.v4/ > > I haven't reviewed all of the changes, instead focusing on the > structure and use of templates. That generally looks fine; I have a > few stylistic comments below, but nothing earth shaking. > > Some of the remaining comments, even if technically correct and > acceptable, might not be appropriate for this change set, but should > instead be dealt with in follow-on changes. > > ------------------------------------------------------------------------------ > Throughout: > > I would probably have used some simple macros to avoid near > duplication of a lot of groups of related functions that differ only > in a type parameter. > > The present approach of making the groups of related functions > "obviously" similar by putting the entire definition on one line so > there are several nearly identical lines in a row makes me look at > each of the lines carefully to make sure the several parallel > differences are what's expected. It has the additional defect of > involving very long lines, which makes them harder to review in > side-by-side views. > > YMMV. If I get you right, you would like to use macros to generate code lines that are now instead aligned but longish, in order to make the lines shorter? Hmm, it would indeed become shorter lines then. I think it would make it harder to read and understand though as a consequence. Do you think it's worth macroing it up to reduce code size? I mean the motivation/point of reducing code size is often to decrease complexity, but I feel like here it would on the contrary induce unnecessary complexity just for the sake of having shorter lines. Hmm! I don't know, what is the policy in general for sticking to 80 characters BTW? Personally I was never a fan of this, especially not for C++ out of all languages because it sometimes requires long types, qualified scopes etc. All lines fit on my screen, so I never considered it a problem. I guess it's a matter of taste (and screen size haha). Personally I would rank readability in this order (which explains why it looks this way now): 1. Long aligned lines 2. Shorter split but not aligned lines 3. Macros > ------------------------------------------------------------------------------ > > The ordered access operations are defined on jbyte ... jlong. The > problem is that there is a type in that sequence that is the same size > as two distinct C/C++ types. And as a result, one of those C/C++ > types is missing atomic support. This can lead to problems with types > like size_t on some platforms > > I also don't see atomic support for char*. > > This might be something to consider for a separate change. Sorry I don't think I understand what you mean here. :( If I get you right, you want more responsibilities to move to Atomic regarding making atomic accesses? In that case I agree. :) > ------------------------------------------------------------------------------ > An observation: > > If OrderAccess was a real namespace instead of a pseudo-namespace > class, the specialized versions of the specialized_xxx functions could > be ordinary function overloads rather than function template > specializations. > > OTOH, namespaces don't provide private access control. I often find > myself wishing for such a feature. > > No actual change needed here, just pointing out an interesting > variation from the approach taken. The neat thing about template specializations that I wanted to exploit here is that the definition is the declaration. For overloads, you have to somehow declare the function overloads to be specialized somewhere (which would be different for every platform as there are different sets of specializations). I think it would have been a bit more awkward because of that. With the template specializations on the other hand, you just stick the definition in there and the compiler will automatically know it is available too without any need for a declaration of available template specializations. I don't think you could do that with the namespace+overload approach, right? > ------------------------------------------------------------------------------ > An observation: > > load_ptr_acquire isn't strictly necessary, and could be replaced by > load_acquire with some additional work. But it might be the "_ptr_" > in the name is considered useful documentation. > > Given that, load_ptr_acquire can be generalized to support any type of > pointer, not just intptr_t* and void*. This would eliminate the need > for casting result types in some places, and for some strange value > types in others. For example MetaspaceGC::_capacity_until_gc is > declared intptr_t rather than size_t. > > This might be something to consider for a separate change. Interesting you mention this! I had similar thoughts. My analysis about _ptr_: The _ptr_ is required because both some kind of pointer type (like void*) and also intptr_t was wanted. Now intptr_t will be the same as either jint or jlong, which already has overloads. Therefore, this would lead to compiler moaning about ambiguity. I have no problem with leaving it like that though. My analysis about generic pointer types: Ideally we would want generic/parameterized pointer types, like: release_store(T *volatile *addr, T *value) And it looks very strange that it is instead release_store(volatile void *addr, void *value) The reason it looks like this is because any pointer is implicitly casted to void* which has been abused all over the place. So you find actual usages like: OrderAccess::release_store_ptr((Klass* volatile *)obj_at_addr_raw(which), k); Here the user gave an exact pointer type. But there is no such overload, so it is implicitly casted to void* like any other pointer. The same does *not* work for void**, and that's why void* is there even though it seems very wrong. I tried making a generalized pointer version in pretty much exactly the way you suggest using templates. And it didn't work, because since everything has been just implicitly casted to void* all over the place regardless of actual pointer type, the code is split between sometimes giving good exact pointer types and sometimes bad ones not following the intended pattern. So while this ideally would be nicer, I gave up on that for this change - we need to clean up the actual usage of OrderAccess too in order to do this. :( > ------------------------------------------------------------------------------ > src/share/vm/runtime/orderAccess.hpp > > I don't see the point of having ScopedFence derive from > ScopedFenceGeneral. It seems to me that ScopedFenceGeneral could > derive from AllStatic (with corresponding changes to functions) and > ScopedFence could instead derive from StackObj. It does have a point to me. The reason is simple: ScopedFence is-a ScopedFenceGeneral - and that's the point. Whether the inheritance is technically needed or could be removed is IMO not important. Because it's more intuitive for my understanding that if it's used like inheritance and ScopedFence is-a ScopedFenceGeneral, then they should be related by inheritance whether required for the code to compile or not. It's like AllStatic classes with inheritance: they might not technically need the inheritance because calls to super are qualified anyway, but they should use inheritance anyway if they are conceptually related by inheritance IMO. If A is-a B, then A should inherit from B. Would you agree with this? > ------------------------------------------------------------------------------ > src/share/vm/runtime/orderAccess.hpp > > Why are ScopedFenceType, ScopedFenceGeneral, and ScopedFence defined > at global scope rather than nested in OrderAccess? I actually had them nested at first. But eh, the lines in definitions became pretty long then because of the long nested names and I thought I'd make the lines a bit tighter. I think I just contradicted myself haha! Anyway, if you prefer them to be nested I'm fine with that: I do not feel strongly about this. :) > ------------------------------------------------------------------------------ > src/share/vm/runtime/orderAccess.hpp > > For all load_acquire variants, why (volatile T* p) rather than > (const volatile* p)? Did you mean (const T * volatile *p)? I assume so. And yes I had the same question. And like before, I tried it and ran into a lot of compiler errors because of implicit void* casts abused and incompatible with void** throughout hotspot, and gave up on it. ;) > ------------------------------------------------------------------------------ > src/share/vm/runtime/orderAccess.inline.hpp > 75 #ifdef VM_HAS_GENERALIZED_ORDER_ACCESS > > I'm not sure what the point of this is. Is this just to allow some > (perhaps third-party?) platforms to continue to use an old > implementation? > > Or is it for incremental development of this set of changes? > > Is the plan that it will eventually go away? Yeah it's only here while adapting other platforms and smoothly transitioning to the new architecture. Then it will be removed (together with the store_fence declarations now made private meanhile). > ------------------------------------------------------------------------------ > src/share/vm/runtime/orderAccess.inline.hpp > > I think there needs to be some documentation here about which > specialized_xxx functions can/should be considered for specialization. Yes in OrderAccess.inline.hpp I wrote next to the OrderAccess::store definitions: // Generalized atomic volatile accesses valid in OrderAccess // All other types can be expressed in terms of these. inline void OrderAccess::store(volatile jbyte* p, jbyte v) { *p = v; } inline void OrderAccess::store(volatile jshort* p, jshort v) { *p = v; } inline void OrderAccess::store(volatile jint* p, jint v) { *p = v; } inline void OrderAccess::store(volatile jlong* p, jlong v) { Atomic::store(v, p); } inline void OrderAccess::store(volatile jdouble* p, jdouble v) { Atomic::store(jlong_cast(v), (volatile jlong*)p); } inline void OrderAccess::store(volatile jfloat* p, jfloat v) { *p = v; } ...and these are the exact types you can specialize. If you do not think this is clear enough or would like to move the comment somewhere else I'm fine with that. What do you think? > ------------------------------------------------------------------------------ > src/share/vm/runtime/orderAccess.inline.hpp > 138 // The following methods can be specialized using simple template specialization > 139 // in the platform specific files for optimization purposes. Otherwise the > 140 // generalized variant is used. > 141 template inline T OrderAccess::specialized_load_acquire (volatile T* p) { return ordered_load(p); } > 142 template inline void OrderAccess::specialized_release_store (volatile T* p, T v) { ordered_store(p, v); } > 143 template inline void OrderAccess::specialized_release_store_fence(volatile T* p, T v) { ordered_store(p, v); } > > I *think* it doesn't matter in practice, but I would put these > definitions before the potential instantiations. The relevant > declarations are obviously in scope where those instantiations occur, > and everything is declared inline, but I worry that some > insufficiently clever compiler might end up generating out of line > code in some cases because the definition was after use. As your initial intuition said - it doesn't matter in practice: inline function definitions are not instantiations. Instantiation will happen when the user actually calls e.g. OrderAccess::load_acquire, at which point all template definitions/inline definitions are known and used for instantiating them. Why? Because inlined functions are instantiated when called, not when defined. So it won't be a problem. I'm pretty sure any compiler not doing this wouldn't work. ;) > ------------------------------------------------------------------------------ > src/share/vm/runtime/orderAccess.inline.hpp > 101 inline jubyte OrderAccess::load_acquire(volatile jubyte* p) { return (jubyte) specialized_load_acquire((volatile jbyte*)p); } > 102 inline jushort OrderAccess::load_acquire(volatile jushort* p) { return (jushort)specialized_load_acquire((volatile jshort*)p); } > 103 inline juint OrderAccess::load_acquire(volatile juint* p) { return (juint) specialized_load_acquire((volatile jint*)p); } > 104 inline julong OrderAccess::load_acquire(volatile julong* p) { return (julong) specialized_load_acquire((volatile jlong*)p); } > > I would probably define these as calling load_acquire with casts, > rather than directly calling specialized_load_acquire. Similarly for > store_release and load_ptr_acquire variants. This would make it > easier to fiddle with the how the specializations are implemented, and > shorten the line lengths by a dozen characters. I agree it would undoubtably be 12 characters smaller, but consistency seems more important to me. I think it's nice they all call the same function with different types instead of introducing exceptions to the rule in order to save 12 characters of line width for some specific overloads. Would you agree? > I would probably also have used some simple macrology to avoid near > duplication of code. Again, not convinced macros would improve readability/understandability here as argued before. ;) > ------------------------------------------------------------------------------ > src/os_cpu/linux_ppc/vm/orderAccess_linux_ppc.inline.hpp > > I see no uses of the inlasm_eieio macro. > I see no uses of the inlasm_isync macro. No I thought they were there as available tools for the future if they will then be wanted as well as to comprehensively list the available fences. I don't think eieio was ever used. If you want me to though, I will remove them. Many thanks for reviewing these changes Kim! :) Cheers, /Erik From vladimir.kozlov at oracle.com Sat Feb 21 01:42:47 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 20 Feb 2015 17:42:47 -0800 Subject: RFR: 8073108: GHASH Intrinsics In-Reply-To: <54E79FF7.1040800@oracle.com> References: <54E25D03.7090705@oracle.com> <54E6855F.4050308@oracle.com> <54E68FBA.1090904@oracle.com> <54E79FF7.1040800@oracle.com> Message-ID: <54E7E297.4010501@oracle.com> Perfect. No more comments from me. Thanks, Vladimir On 2/20/15 12:58 PM, Anthony Scarpino wrote: > On 02/19/2015 05:36 PM, Vladimir Kozlov wrote: >> JDK changes review. >> ------------------- >> All exceptions should print invalid value as you did for state and >> subkeyH checks. It would greatly help debugging. >> >> Please, split first check into 3 separate checks and print invalid value >> to know which condition failed. >> >> Missing space after 'length': "invalid length"+subkeyH.length > > webrev updated: > http://cr.openjdk.java.net/~ascarpino/8073108/jdk/webrev.02/ > > Tony > From coleen.phillimore at oracle.com Sat Feb 21 02:08:43 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 20 Feb 2015 21:08:43 -0500 Subject: 2-nd round RFR (M) 8046246: the constantPoolCacheOopDesc::adjust_method_entries() used in RedefineClasses does not scale In-Reply-To: <54E7A7FC.9090709@oracle.com> References: <54E57884.8030200@oracle.com> <54E7A7FC.9090709@oracle.com> Message-ID: <54E7E8AB.6000704@oracle.com> Serguei, Looks great. Thanks, Coleen On 2/20/15, 4:32 PM, serguei.spitsyn at oracle.com wrote: > The hotspot webrev below addresses the Coleen's comments from the 1-st > review round. > > Open hotspot webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.2/ > > > Open jdk (new unit test) webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8046246-JVMTI-manymethods.1/ > > > Thanks, > Serguei > > > On 2/18/15 9:45 PM, serguei.spitsyn at oracle.com wrote: >> Please, review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-8046246 >> >> >> Open hotspot webrevs: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.1/ >> >> >> Open jdk (new unit test) webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8046246-JVMTI-manymethods.1/ >> >> >> >> Summary: >> >> This performance/scalability issue in class redefinition was >> reported by HP and the Enterprise Manager team. >> The following variants of the adjust_method_entries() functions do >> not scale: >> ConstantPoolCache::adjust_method_entries() >> klassVtable::adjust_method_entries() >> klassItable::adjust_method_entries() >> InstanceKlass::adjust_default_methods() >> >> The ConstantPoolCache::adjust_method_entries() is the most important. >> >> The approach is to use the holder->method_with_idnum() like this: >> Method* new_method = >> holder->method_with_idnum(old_method->orig_method_idnum()); >> if (old_method != new_method) { >> >> } >> >> New algorithm has effectiveness O(M) instead of original O(M^2), >> where M is count of methods in the class. >> The new test (see webrev above) was used to mesure CPU time >> consumed by the >> ConstantPoolCache::adjust_method_entries() in both original and >> new approach. >> >> The performance numbers are: >> >> --------------------------------------------------------------------------------------- >> >> Methods: ------ 1,000 --------------- 10,000 ----------------- >> 20,000 >> --------------------------------------------------------------------------------------- >> >> Orig: 600,000 nsec (1x) 60,500,000 nsec (~100x) >> 243,000,000 nsec (~400x) >> New: 16,000 nsec (1x) 178,000 nsec (~10x) 355,000 >> nsec (~20x) >> --------------------------------------------------------------------------------------- >> >> >> >> >> Testing: >> In progress: VM SQE RedefineClasses tests, JTREG >> java/lang/instrument, com/sun/jdi tests >> >> >> Thanks, >> Serguei >> > From serguei.spitsyn at oracle.com Sat Feb 21 06:27:54 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 20 Feb 2015 22:27:54 -0800 Subject: 2-nd round RFR (M) 8046246: the constantPoolCacheOopDesc::adjust_method_entries() used in RedefineClasses does not scale In-Reply-To: <54E7E8AB.6000704@oracle.com> References: <54E57884.8030200@oracle.com> <54E7A7FC.9090709@oracle.com> <54E7E8AB.6000704@oracle.com> Message-ID: <54E8256A.9060206@oracle.com> Thanks a lot, Coleen! Serguei On 2/20/15 6:08 PM, Coleen Phillimore wrote: > > Serguei, Looks great. > > Thanks, > Coleen > > On 2/20/15, 4:32 PM, serguei.spitsyn at oracle.com wrote: >> The hotspot webrev below addresses the Coleen's comments from the >> 1-st review round. >> >> Open hotspot webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.2/ >> >> >> Open jdk (new unit test) webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8046246-JVMTI-manymethods.1/ >> >> >> Thanks, >> Serguei >> >> >> On 2/18/15 9:45 PM, serguei.spitsyn at oracle.com wrote: >>> Please, review the fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8046246 >>> >>> >>> Open hotspot webrevs: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.1/ >>> >>> >>> Open jdk (new unit test) webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8046246-JVMTI-manymethods.1/ >>> >>> >>> >>> Summary: >>> >>> This performance/scalability issue in class redefinition was >>> reported by HP and the Enterprise Manager team. >>> The following variants of the adjust_method_entries() functions >>> do not scale: >>> ConstantPoolCache::adjust_method_entries() >>> klassVtable::adjust_method_entries() >>> klassItable::adjust_method_entries() >>> InstanceKlass::adjust_default_methods() >>> >>> The ConstantPoolCache::adjust_method_entries() is the most >>> important. >>> >>> The approach is to use the holder->method_with_idnum() like this: >>> Method* new_method = >>> holder->method_with_idnum(old_method->orig_method_idnum()); >>> if (old_method != new_method) { >>> >>> } >>> >>> New algorithm has effectiveness O(M) instead of original O(M^2), >>> where M is count of methods in the class. >>> The new test (see webrev above) was used to mesure CPU time >>> consumed by the >>> ConstantPoolCache::adjust_method_entries() in both original and >>> new approach. >>> >>> The performance numbers are: >>> >>> --------------------------------------------------------------------------------------- >>> >>> Methods: ------ 1,000 --------------- 10,000 ----------------- >>> 20,000 >>> --------------------------------------------------------------------------------------- >>> >>> Orig: 600,000 nsec (1x) 60,500,000 nsec (~100x) >>> 243,000,000 nsec (~400x) >>> New: 16,000 nsec (1x) 178,000 nsec (~10x) >>> 355,000 nsec (~20x) >>> --------------------------------------------------------------------------------------- >>> >>> >>> >>> >>> Testing: >>> In progress: VM SQE RedefineClasses tests, JTREG >>> java/lang/instrument, com/sun/jdi tests >>> >>> >>> Thanks, >>> Serguei >>> >> > From david.holmes at oracle.com Sun Feb 22 04:51:46 2015 From: david.holmes at oracle.com (David Holmes) Date: Sun, 22 Feb 2015 14:51:46 +1000 Subject: RFR: 7143664: Clean up OrderAccess implementations and usage In-Reply-To: References: <91056808-A32B-4713-A061-0E9AED4A5157@oracle.com> <90AA856F-0340-4E58-BBCE-901700144E57@oracle.com> Message-ID: <54E96062.5030301@oracle.com> My 2c as the sponsor here. If we get into matters of style then we can debate endlessly, so lets not do that :) (or at least lets not have that hold up getting this pushed through - we can debate and refine later if needed). As far as macros are concerned I'd need to see a concrete example of what is proposed to evaluate its utility with regard to understandability or maintainability - but as a template novice I find the current structure quite readable and understandable. Re Atomics ... seems to be a separate issue. For a while people overlooked the fact that 64-bit loads/stores needed special handling on 32-bit systems. Hence we need specific Atomic handling for jlong and jdouble. For all other types (regardless of whether there is an Atomic::store variant) we already assume accesses are atomic (which may only be true if alignment constraints are met). Re: > ------------------------------------------------------------------------------ > src/os_cpu/linux_ppc/vm/orderAccess_linux_ppc.inline.hpp > > I see no uses of the inlasm_eieio macro. > I see no uses of the inlasm_isync macro. This was put there by the ppc64 folk. It is up to them whether it is removed or left in place for potential future use. Thanks, David On 21/02/2015 11:08 AM, Erik ?sterlund wrote: > Hi Kim, > > Thanks for the review! :) > > In general: I might be a bit biased against the use of macros in general > and avoid it whenever it can be avoided as you know. :) > To me it seems a bit over engineered and unnecessarily complex to reduce > the already quite small (84 LoC) code size of OrderAccess.inline.hpp > with macros. And for me it's unclear what the benefit of such code size > decrease would be. A means to reduce complexity, increase > understandability? Probably not. A means to increase maintainability? > Perhaps possible but not sure! > > But in matters where it's really up to personal taste, I'd like to not > decide. Kim I will let you call the shots! > > Comments: > > On 20/02/15 23:41, Kim Barrett wrote: >>> http://cr.openjdk.java.net/~dholmes/7143664/webrev.v4/ >> >> I haven't reviewed all of the changes, instead focusing on the >> structure and use of templates. That generally looks fine; I have a >> few stylistic comments below, but nothing earth shaking. >> >> Some of the remaining comments, even if technically correct and >> acceptable, might not be appropriate for this change set, but should >> instead be dealt with in follow-on changes. >> >> ------------------------------------------------------------------------------ >> Throughout: >> >> I would probably have used some simple macros to avoid near >> duplication of a lot of groups of related functions that differ only >> in a type parameter. >> >> The present approach of making the groups of related functions >> "obviously" similar by putting the entire definition on one line so >> there are several nearly identical lines in a row makes me look at >> each of the lines carefully to make sure the several parallel >> differences are what's expected. It has the additional defect of >> involving very long lines, which makes them harder to review in >> side-by-side views. >> >> YMMV. > > If I get you right, you would like to use macros to generate code lines > that are now instead aligned but longish, in order to make the lines > shorter? > > Hmm, it would indeed become shorter lines then. I think it would make it > harder to read and understand though as a consequence. Do you think it's > worth macroing it up to reduce code size? I mean the motivation/point of > reducing code size is often to decrease complexity, but I feel like here > it would on the contrary induce unnecessary complexity just for the sake > of having shorter lines. Hmm! > > I don't know, what is the policy in general for sticking to 80 > characters BTW? Personally I was never a fan of this, especially not for > C++ out of all languages because it sometimes requires long types, > qualified scopes etc. All lines fit on my screen, so I never considered > it a problem. I guess it's a matter of taste (and screen size haha). > Personally I would rank readability in this order (which explains why it > looks this way now): > > 1. Long aligned lines > 2. Shorter split but not aligned lines > 3. Macros > >> ------------------------------------------------------------------------------ >> >> The ordered access operations are defined on jbyte ... jlong. The >> problem is that there is a type in that sequence that is the same size >> as two distinct C/C++ types. And as a result, one of those C/C++ >> types is missing atomic support. This can lead to problems with types >> like size_t on some platforms >> >> I also don't see atomic support for char*. >> >> This might be something to consider for a separate change. > > Sorry I don't think I understand what you mean here. :( > If I get you right, you want more responsibilities to move to Atomic > regarding making atomic accesses? In that case I agree. :) > >> ------------------------------------------------------------------------------ >> An observation: >> >> If OrderAccess was a real namespace instead of a pseudo-namespace >> class, the specialized versions of the specialized_xxx functions could >> be ordinary function overloads rather than function template >> specializations. >> >> OTOH, namespaces don't provide private access control. I often find >> myself wishing for such a feature. >> >> No actual change needed here, just pointing out an interesting >> variation from the approach taken. > > The neat thing about template specializations that I wanted to exploit > here is that the definition is the declaration. For overloads, you have > to somehow declare the function overloads to be specialized somewhere > (which would be different for every platform as there are different sets > of specializations). I think it would have been a bit more awkward > because of that. With the template specializations on the other hand, > you just stick the definition in there and the compiler will > automatically know it is available too without any need for a > declaration of available template specializations. > > I don't think you could do that with the namespace+overload approach, right? > >> ------------------------------------------------------------------------------ >> An observation: >> >> load_ptr_acquire isn't strictly necessary, and could be replaced by >> load_acquire with some additional work. But it might be the "_ptr_" >> in the name is considered useful documentation. >> >> Given that, load_ptr_acquire can be generalized to support any type of >> pointer, not just intptr_t* and void*. This would eliminate the need >> for casting result types in some places, and for some strange value >> types in others. For example MetaspaceGC::_capacity_until_gc is >> declared intptr_t rather than size_t. >> >> This might be something to consider for a separate change. > > Interesting you mention this! I had similar thoughts. > > My analysis about _ptr_: > > The _ptr_ is required because both some kind of pointer type (like > void*) and also intptr_t was wanted. Now intptr_t will be the same as > either jint or jlong, which already has overloads. Therefore, this would > lead to compiler moaning about ambiguity. I have no problem with leaving > it like that though. > > My analysis about generic pointer types: > > Ideally we would want generic/parameterized pointer types, like: > release_store(T *volatile *addr, T *value) > And it looks very strange that it is instead > release_store(volatile void *addr, void *value) > > The reason it looks like this is because any pointer is implicitly > casted to void* which has been abused all over the place. So you find > actual usages like: > OrderAccess::release_store_ptr((Klass* volatile > *)obj_at_addr_raw(which), k); > > Here the user gave an exact pointer type. But there is no such overload, > so it is implicitly casted to void* like any other pointer. The same > does *not* work for void**, and that's why void* is there even though it > seems very wrong. > > I tried making a generalized pointer version in pretty much exactly the > way you suggest using templates. And it didn't work, because since > everything has been just implicitly casted to void* all over the place > regardless of actual pointer type, the code is split between sometimes > giving good exact pointer types and sometimes bad ones not following the > intended pattern. So while this ideally would be nicer, I gave up on > that for this change - we need to clean up the actual usage of > OrderAccess too in order to do this. :( > >> ------------------------------------------------------------------------------ >> src/share/vm/runtime/orderAccess.hpp >> >> I don't see the point of having ScopedFence derive from >> ScopedFenceGeneral. It seems to me that ScopedFenceGeneral could >> derive from AllStatic (with corresponding changes to functions) and >> ScopedFence could instead derive from StackObj. > > It does have a point to me. The reason is simple: ScopedFence is-a > ScopedFenceGeneral - and that's the point. Whether the inheritance is > technically needed or could be removed is IMO not important. Because > it's more intuitive for my understanding that if it's used like > inheritance and ScopedFence is-a ScopedFenceGeneral, then they should be > related by inheritance whether required for the code to compile or not. > > It's like AllStatic classes with inheritance: they might not technically > need the inheritance because calls to super are qualified anyway, but > they should use inheritance anyway if they are conceptually related by > inheritance IMO. > > If A is-a B, then A should inherit from B. > > Would you agree with this? > >> ------------------------------------------------------------------------------ >> src/share/vm/runtime/orderAccess.hpp >> >> Why are ScopedFenceType, ScopedFenceGeneral, and ScopedFence defined >> at global scope rather than nested in OrderAccess? > > I actually had them nested at first. But eh, the lines in definitions > became pretty long then because of the long nested names and I thought > I'd make the lines a bit tighter. I think I just contradicted myself > haha! Anyway, if you prefer them to be nested I'm fine with that: I do > not feel strongly about this. :) > >> ------------------------------------------------------------------------------ >> src/share/vm/runtime/orderAccess.hpp >> >> For all load_acquire variants, why (volatile T* p) rather than >> (const volatile* p)? > > Did you mean (const T * volatile *p)? I assume so. And yes I had the > same question. And like before, I tried it and ran into a lot of > compiler errors because of implicit void* casts abused and incompatible > with void** throughout hotspot, and gave up on it. ;) > >> ------------------------------------------------------------------------------ >> src/share/vm/runtime/orderAccess.inline.hpp >> 75 #ifdef VM_HAS_GENERALIZED_ORDER_ACCESS >> >> I'm not sure what the point of this is. Is this just to allow some >> (perhaps third-party?) platforms to continue to use an old >> implementation? >> >> Or is it for incremental development of this set of changes? >> >> Is the plan that it will eventually go away? > > Yeah it's only here while adapting other platforms and smoothly > transitioning to the new architecture. Then it will be removed (together > with the store_fence declarations now made private meanhile). > >> ------------------------------------------------------------------------------ >> src/share/vm/runtime/orderAccess.inline.hpp >> >> I think there needs to be some documentation here about which >> specialized_xxx functions can/should be considered for specialization. > > Yes in OrderAccess.inline.hpp I wrote next to the OrderAccess::store > definitions: > // Generalized atomic volatile accesses valid in OrderAccess > // All other types can be expressed in terms of these. > inline void OrderAccess::store(volatile jbyte* p, jbyte v) { *p = v; } > inline void OrderAccess::store(volatile jshort* p, jshort v) { *p = v; } > inline void OrderAccess::store(volatile jint* p, jint v) { *p = v; } > inline void OrderAccess::store(volatile jlong* p, jlong v) { > Atomic::store(v, p); } > inline void OrderAccess::store(volatile jdouble* p, jdouble v) { > Atomic::store(jlong_cast(v), (volatile jlong*)p); } > inline void OrderAccess::store(volatile jfloat* p, jfloat v) { *p = v; } > > ...and these are the exact types you can specialize. > > If you do not think this is clear enough or would like to move the > comment somewhere else I'm fine with that. What do you think? > >> ------------------------------------------------------------------------------ >> src/share/vm/runtime/orderAccess.inline.hpp >> 138 // The following methods can be specialized using simple template specialization >> 139 // in the platform specific files for optimization purposes. Otherwise the >> 140 // generalized variant is used. >> 141 template inline T OrderAccess::specialized_load_acquire (volatile T* p) { return ordered_load(p); } >> 142 template inline void OrderAccess::specialized_release_store (volatile T* p, T v) { ordered_store(p, v); } >> 143 template inline void OrderAccess::specialized_release_store_fence(volatile T* p, T v) { ordered_store(p, v); } >> >> I *think* it doesn't matter in practice, but I would put these >> definitions before the potential instantiations. The relevant >> declarations are obviously in scope where those instantiations occur, >> and everything is declared inline, but I worry that some >> insufficiently clever compiler might end up generating out of line >> code in some cases because the definition was after use. > > As your initial intuition said - it doesn't matter in practice: inline > function definitions are not instantiations. Instantiation will happen > when the user actually calls e.g. OrderAccess::load_acquire, at which > point all template definitions/inline definitions are known and used for > instantiating them. Why? Because inlined functions are instantiated when > called, not when defined. > > So it won't be a problem. I'm pretty sure any compiler not doing this > wouldn't work. ;) > >> ------------------------------------------------------------------------------ >> src/share/vm/runtime/orderAccess.inline.hpp >> 101 inline jubyte OrderAccess::load_acquire(volatile jubyte* p) { return (jubyte) specialized_load_acquire((volatile jbyte*)p); } >> 102 inline jushort OrderAccess::load_acquire(volatile jushort* p) { return (jushort)specialized_load_acquire((volatile jshort*)p); } >> 103 inline juint OrderAccess::load_acquire(volatile juint* p) { return (juint) specialized_load_acquire((volatile jint*)p); } >> 104 inline julong OrderAccess::load_acquire(volatile julong* p) { return (julong) specialized_load_acquire((volatile jlong*)p); } >> >> I would probably define these as calling load_acquire with casts, >> rather than directly calling specialized_load_acquire. Similarly for >> store_release and load_ptr_acquire variants. This would make it >> easier to fiddle with the how the specializations are implemented, and >> shorten the line lengths by a dozen characters. > > I agree it would undoubtably be 12 characters smaller, but consistency > seems more important to me. I think it's nice they all call the same > function with different types instead of introducing exceptions to the > rule in order to save 12 characters of line width for some specific > overloads. Would you agree? > >> I would probably also have used some simple macrology to avoid near >> duplication of code. > > Again, not convinced macros would improve readability/understandability > here as argued before. ;) > >> ------------------------------------------------------------------------------ >> src/os_cpu/linux_ppc/vm/orderAccess_linux_ppc.inline.hpp >> >> I see no uses of the inlasm_eieio macro. >> I see no uses of the inlasm_isync macro. > > No I thought they were there as available tools for the future if they > will then be wanted as well as to comprehensively list the available > fences. I don't think eieio was ever used. If you want me to though, I > will remove them. > > Many thanks for reviewing these changes Kim! :) > > Cheers, > /Erik > From kim.barrett at oracle.com Sun Feb 22 06:44:48 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 22 Feb 2015 01:44:48 -0500 Subject: RFR: 7143664: Clean up OrderAccess implementations and usage In-Reply-To: <54E96062.5030301@oracle.com> References: <91056808-A32B-4713-A061-0E9AED4A5157@oracle.com> <90AA856F-0340-4E58-BBCE-901700144E57@oracle.com> <54E96062.5030301@oracle.com> Message-ID: On Feb 21, 2015, at 11:51 PM, David Holmes wrote: > > My 2c as the sponsor here. If we get into matters of style then we can debate endlessly, so lets not do that :) (or at least lets not have that hold up getting this pushed through - we can debate and refine later if needed). As far as macros are concerned I'd need to see a concrete example of what is proposed to evaluate its utility with regard to understandability or maintainability - but as a template novice I find the current structure quite readable and understandable. Since I was in the process of drafting a message suggesting essentially this, well, I agree. I think this change set is a significant improvement. While I think there are some issues, as well as some things that I would have done differently, I haven?t found anything that I think should prevent acceptance. We can discuss further issues and stylistic questions as followups. From kim.barrett at oracle.com Sun Feb 22 07:42:59 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 22 Feb 2015 02:42:59 -0500 Subject: RFR: 7143664: Clean up OrderAccess implementations and usage In-Reply-To: References: <91056808-A32B-4713-A061-0E9AED4A5157@oracle.com> <90AA856F-0340-4E58-BBCE-901700144E57@oracle.com> Message-ID: <729B22CD-38E7-405C-9F2E-5C440D899108@oracle.com> I?m breaking up some of the issue discussions into separate emails, mostly so that I don?t feel like I need to address all of them before sending any reply. On Feb 20, 2015, at 8:08 PM, Erik ?sterlund wrote: > > On 20/02/15 23:41, Kim Barrett wrote: >>> http://cr.openjdk.java.net/~dholmes/7143664/webrev.v4/ >> > src/share/vm/runtime/orderAccess.hpp > > I don't see the point of having ScopedFence derive from > ScopedFenceGeneral. It seems to me that ScopedFenceGeneral could > derive from AllStatic (with corresponding changes to functions) and > ScopedFence could instead derive from StackObj. > >> It does have a point to me. The reason is simple: ScopedFence is-a >> ScopedFenceGeneral - and that's the point. Whether the inheritance is >> technically needed or could be removed is IMO not important. Because >> it's more intuitive for my understanding that if it's used like >> inheritance and ScopedFence is-a ScopedFenceGeneral, then they should be >> related by inheritance whether required for the code to compile or not. >> >> It's like AllStatic classes with inheritance: they might not technically >> need the inheritance because calls to super are qualified anyway, but >> they should use inheritance anyway if they are conceptually related by >> inheritance IMO. >> >> If A is-a B, then A should inherit from B. >> >> Would you agree with this? No, I don't agree. I don't see ScopedFence as being is-a ScopedFenceGeneral. Rather, I see ScopedFenceGeneral as an implementation strategy for ScopedFence. No client code should ever deal with ScopedFenceGeneral. It's purely an implementation detail providing the extra indirection needed for the default implementation of ScopedFence, while still allowing the latter to be specialized by a platform. As such, exposing it as a public base class is inappropriate. ScopedFenceGeneral is also poorly written as a base class. It allows trivial accidental slicing in various ways. To prevent that, none of it's API ought to be public. This includes not just the explicit explicit prefix() and postfix(), but also the automatically generated ctor/dtor/copy/assign operations. But once it has no public API it ceases to be interesting as a public base class. Below is a sketch of how I think ScopedFence should be done. Note that the public ScopedFenceGeneral has been replaced with the private ScopedFence::Impl. ---------- #include enum ScopedFenceType { X_ACQUIRE , RELEASE_X , RELEASE_X_FENCE }; template class ScopedFence /* : public ScopedObj */ { class Impl; public: ScopedFence() { prefix(); } ~ScopedFence() { postfix(); } void prefix() { Impl::prefix(); } void postfix() { Impl::postfix(); } }; template struct ScopedFence::Impl /* : public AllStatic */ { static void prefix() { } static void postfix() { } }; // Default implementations for specific fence types template<> inline void ScopedFence::Impl::postfix() { std::cout << "ScopedFence::postfix() => Impl\n"; } template<> inline void ScopedFence::Impl::prefix() { std::cout << "ScopedFence::prefix() => Impl\n"; } // platform-specific override template<> inline void ScopedFence::postfix() { std::cout << "ScopedFence::postfix() => override\n"; } int main(int argc, char* argv[]) { ScopedFence a; ScopedFence r; return 0; } From erik.osterlund at lnu.se Sun Feb 22 10:09:06 2015 From: erik.osterlund at lnu.se (=?iso-8859-1?Q?Erik_=D6sterlund?=) Date: Sun, 22 Feb 2015 10:09:06 +0000 Subject: RFR: 7143664: Clean up OrderAccess implementations and usage References: <91056808-A32B-4713-A061-0E9AED4A5157@oracle.com> <90AA856F-0340-4E58-BBCE-901700144E57@oracle.com> <729B22CD-38E7-405C-9F2E-5C440D899108@oracle.com> Message-ID: Hi Kim, Thank you for your feedback. On 22/02/15 08:43, Kim Barrett wrote: >>> If A is-a B, then A should inherit from B. >>> >>> Would you agree with this? > > No, I don't agree. > > I don't see ScopedFence as being is-a ScopedFenceGeneral. Rather, I > see ScopedFenceGeneral as an implementation strategy for ScopedFence. Hmm, isn't this yet another stylistic preference thing though? When I read just the names ScopedFence and ScopedFenceGeneral, I don't understand how the is-a relationship is not clear. Looking how it's used even more so (generalization/specialization). And the lack of such a relationship is the basis for your argument. My opinion: Both their names and use make sense with inheritance and maybe we might want more levels in the hierarchy later, for instance for generalizing cpus so it does not have to be redefined in the same way for every operating system with the same cpu with a CPUScopedFence or something. Who knows... ;) > No client code should ever deal with ScopedFenceGeneral. It's purely > an implementation detail providing the extra indirection needed for > the default implementation of ScopedFence, while still allowing the > latter to be specialized by a platform. As such, exposing it as a > public base class is inappropriate. > > ScopedFenceGeneral is also poorly written as a base class. It allows > trivial accidental slicing in various ways. To prevent that, none of > it's API ought to be public. This includes not just the explicit > explicit prefix() and postfix(), but also the automatically generated > ctor/dtor/copy/assign operations. But once it has no public API it > ceases to be interesting as a public base class. I think there is a misconception here that one of these scoped fences should be used by client code and the other not. This is not the case. As a matter of fact, neither one of them should be used. All client code should use OrderAccess::* and none should use ScopedFence*. If it bugs you that they are public which I can somehow understand, how about moving them both to private? Seems to immediately solve the permission problem in a pretty straight forward way. In the end, this is what I first did but then moved them out to get smaller lines haha! :) If you agree with this you can stop reading here. If not, and you would prefer your variant instead, I have some comments about it: > Below is a sketch of how I think ScopedFence should be done. Note > that the public ScopedFenceGeneral has been replaced with the private > ScopedFence::Impl. I think that by reading the names ScopedFence and ScopedFenceGeneral (and their inheritance relationship), it was easy to understand which one is the generalized variant and which one is not. To me the name ScopedFence::Impl implies this is /the one/ implementation of ScopedFence. But it is in fact the generalized implementation, which does not seem obvious. To me this is unintuitive and makes it harder to read. Let's compare the two solutions. My solution: template<> inline void ScopedFenceGeneral::postfix() { OrderAccess::acquire(); } template<> inline void ScopedFence::postfix() { } Your solution: template<> inline void ScopedFence::Impl::postfix(){ OrderAccess::acquire(); } template<> inline void ScopedFence::postfix() { } Would you agree it's harder to work out which one is the generalized behavior in your solution when just reading the code? I would prefer at least something like Impl -> DefaultImpl to make it more readable in that case. Thank you for the comments! :) /Erik > ---------- > #include > > enum ScopedFenceType { > X_ACQUIRE > , RELEASE_X > , RELEASE_X_FENCE > }; > > template > class ScopedFence /* : public ScopedObj */ { > class Impl; > > public: > ScopedFence() { prefix(); } > ~ScopedFence() { postfix(); } > void prefix() { Impl::prefix(); } > void postfix() { Impl::postfix(); } > }; > > template > struct ScopedFence::Impl /* : public AllStatic */ { > static void prefix() { } > static void postfix() { } > }; > > // Default implementations for specific fence types > template<> inline void ScopedFence::Impl::postfix() { > std::cout << "ScopedFence::postfix() => Impl\n"; > } > > template<> inline void ScopedFence::Impl::prefix() { > std::cout << "ScopedFence::prefix() => Impl\n"; > } > > // platform-specific override > template<> inline void ScopedFence::postfix() { > std::cout << "ScopedFence::postfix() => override\n"; > } > > int main(int argc, char* argv[]) { > ScopedFence a; > ScopedFence r; > return 0; > } > > > > From gnu.andrew at redhat.com Mon Feb 23 14:16:44 2015 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 23 Feb 2015 09:16:44 -0500 (EST) Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <54E65D27.3070107@oracle.com> References: <54E183B8.5010301@oracle.com> <54E3B144.1090402@oracle.com> <958867570.14123662.1424262805099.JavaMail.zimbra@redhat.com> <1424314925.5112.149.camel@ocdc> <54E55A01.5020700@oracle.com> <54E56503.4090704@oracle.com> <54E65D27.3070107@oracle.com> Message-ID: <1747776645.16967635.1424701004513.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Apologies to Tiago as there were two webrevs and one got stripped from > the email. Here's Tiago's webrev: > > http://cr.openjdk.java.net/~dholmes/rh1191652-jdk9/webrev.00/ > > David > > On 19/02/2015 2:22 PM, David Holmes wrote: > > Now hosted at: > > > > http://cr.openjdk.java.net/~dholmes/ahughes-rh1191652-jdk9-webrev/ > > > > David > > > > On 19/02/2015 1:35 PM, David Holmes wrote: > >> Hi Tiago, > >> > >> Please email me the tar files and I will host it for you. > >> > >> Thanks, > >> David > >> > >> On 19/02/2015 1:02 PM, Tiago Sturmer Daitx wrote: > >>> On Wed, 2015-02-18 at 07:33 -0500, Andrew Hughes wrote: > >>>> I now have these changes working on 8u31: > >>>> > >>>> http://cr.openjdk.java.net/~andrew/rh1191652/root > >>>> http://cr.openjdk.java.net/~andrew/rh1191652/jdk > >>>> > >>>> I can re-base these onto whichever OpenJDK 9 tree is appropriate and > >>>> push when > >>>> reviewed under the same bug as used for the HotSpot side. > >>> > >>> Concurrently to Andrew I also worked on a fix for JDK9 and came up with > >>> a somewhat different approach (based on jdk9/dev): > >>> > >>> http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/webrev.00/hotspot/ > >>> > >>> http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/webrev.00/root > >>> > >>> To make it easy I already rebased Andrew's JDK8u31 patches to jdk9/dev > >>> (due to that the webrev ended up with my username). > >>> > >>> http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/ahughes-webrev.00/hotspot/ > >>> > >>> > >>> http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/ahughes-webrev.00/jdk > >>> > >>> > >>> http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/ahughes-webrev.00/root > >>> > >>> > >>> > >>> I tested both approaches by building Hadoop (which triggered some > >>> interesting bugs on various projects due to Jigsaw). > >>> > >>> Sorry for the github links, but I don't have an account at > >>> cr.openjdk.java.net that I can use. I can provide tar files if anyone is > >>> willing to host those webrevs. > >>> > >>> Regards, > >>> Tiago Daitx > >>> > Where do we go with this next? I'm still in favour of my own patches on the JDK side, as I think hiding the architecture there is just asking for problems further down the line. -- Andrew :) 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 PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From erik.joelsson at oracle.com Mon Feb 23 14:57:31 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 23 Feb 2015 15:57:31 +0100 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <1747776645.16967635.1424701004513.JavaMail.zimbra@redhat.com> References: <54E183B8.5010301@oracle.com> <54E3B144.1090402@oracle.com> <958867570.14123662.1424262805099.JavaMail.zimbra@redhat.com> <1424314925.5112.149.camel@ocdc> <54E55A01.5020700@oracle.com> <54E56503.4090704@oracle.com> <54E65D27.3070107@oracle.com> <1747776645.16967635.1424701004513.JavaMail.zimbra@redhat.com> Message-ID: <54EB3FDB.1060609@oracle.com> I think the jdk changes with ppc64le as CPU make sense. Note that the changes to SoundDefs.h and SoundLibraries.gmk will be obsolete with JDK-8072665 which is currently in the client forest. /Erik On 2015-02-23 15:16, Andrew Hughes wrote: > ----- Original Message ----- >> Apologies to Tiago as there were two webrevs and one got stripped from >> the email. Here's Tiago's webrev: >> >> http://cr.openjdk.java.net/~dholmes/rh1191652-jdk9/webrev.00/ >> >> David >> >> On 19/02/2015 2:22 PM, David Holmes wrote: >>> Now hosted at: >>> >>> http://cr.openjdk.java.net/~dholmes/ahughes-rh1191652-jdk9-webrev/ >>> >>> David >>> >>> On 19/02/2015 1:35 PM, David Holmes wrote: >>>> Hi Tiago, >>>> >>>> Please email me the tar files and I will host it for you. >>>> >>>> Thanks, >>>> David >>>> >>>> On 19/02/2015 1:02 PM, Tiago Sturmer Daitx wrote: >>>>> On Wed, 2015-02-18 at 07:33 -0500, Andrew Hughes wrote: >>>>>> I now have these changes working on 8u31: >>>>>> >>>>>> http://cr.openjdk.java.net/~andrew/rh1191652/root >>>>>> http://cr.openjdk.java.net/~andrew/rh1191652/jdk >>>>>> >>>>>> I can re-base these onto whichever OpenJDK 9 tree is appropriate and >>>>>> push when >>>>>> reviewed under the same bug as used for the HotSpot side. >>>>> Concurrently to Andrew I also worked on a fix for JDK9 and came up with >>>>> a somewhat different approach (based on jdk9/dev): >>>>> >>>>> http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/webrev.00/hotspot/ >>>>> >>>>> http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/webrev.00/root >>>>> >>>>> To make it easy I already rebased Andrew's JDK8u31 patches to jdk9/dev >>>>> (due to that the webrev ended up with my username). >>>>> >>>>> http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/ahughes-webrev.00/hotspot/ >>>>> >>>>> >>>>> http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/ahughes-webrev.00/jdk >>>>> >>>>> >>>>> http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/ahughes-webrev.00/root >>>>> >>>>> >>>>> >>>>> I tested both approaches by building Hadoop (which triggered some >>>>> interesting bugs on various projects due to Jigsaw). >>>>> >>>>> Sorry for the github links, but I don't have an account at >>>>> cr.openjdk.java.net that I can use. I can provide tar files if anyone is >>>>> willing to host those webrevs. >>>>> >>>>> Regards, >>>>> Tiago Daitx >>>>> > Where do we go with this next? > > I'm still in favour of my own patches on the JDK side, as I think hiding the > architecture there is just asking for problems further down the line. From karen.kinnear at oracle.com Mon Feb 23 18:45:38 2015 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Mon, 23 Feb 2015 13:45:38 -0500 Subject: RFR: 7143664: Clean up OrderAccess implementations and usage In-Reply-To: References: <91056808-A32B-4713-A061-0E9AED4A5157@oracle.com> Message-ID: <18C0D6B6-B28B-461A-A59E-6984114B37B6@oracle.com> On Feb 20, 2015, at 1:24 PM, Erik ?sterlund wrote: And truly many thanks - in my mind you have made this much more conceptually clean and safer. I am good with your checking in the parts I have reviewed. > Hi Karen, > > On 20/02/15 17:04, Karen Kinnear wrote: >> Erik, >> >> 1. orderAccess.hpp >> Were you going to add a comment about MSVC assumptions under C++ Volatile Semantics? >> >> Is it worth documenting in source somewhere what minimal versions of compilers are assumed? >> Or which versions of compilers were tested? I think that would help us in future please. >> Maybe in the platform-specific files? > > I did not intend to add this comment to shared. I thought that it would > be enough to say that non-volatile to volatile constraints can not be > trusted in general. Instead there is a comment explaining this anomaly > in orderAccess_windows_x86.inline.hpp where it is exploited, since it is > the only documented exception I know of. > > If we start picking certain examples, it feels like we should rather > have either 1) a comprehensive table of what volatile actually means for > different compilers with references or question marks where we don't > know (and hence need to be conservative assuming the worst), or 2) > putting such comments in platform specific files (like MSVC currently). > > Do you agree? In that case, which one do you prefer? > > As for documenting compiler versions assumed, would it be enough to > stamp the code with the currently used compilers we used now, even > though it might actually have worked with earlier versions? The > reasoning is that it's unlikely we will go back to using earlier > compilers anyway, so finding out when exactly certain compilers started > doing what we want them to could possibly be unnecessary, while still > having enough information to allow checking if future compilers have > provided improved functionality from this version of OrderAccess? It would make more sense to document for the individual platforms. I'm trying to prevent future "what were they thinking" questions by recording for each platform the specific compiler version tested. Not all versions that should work, just the ones we tested it with. > >> 2. orderAccess_windows_x86.inline.hpp >> Could you possibly add to the comment about MSVC, that this assumes all of the Scoped templates explicitly cast the addresses to volatiles? >> (In case someone changes that some day?) > > Sure! But is this not clear given the comment in > orderAccess_windows_x86.inline.hpp where this is exploited next to the > scope template specialization: > > // Note that in MSVC, volatile memory accesses are explicitly > // guaranteed to have acquire release semantics (w.r.t. compiler > // reordering) and therefore does not even need a compiler barrier > // for normal acquire release accesses. > template<> inline void ScopedFence::postfix() { } > template<> inline void ScopedFence::prefix() { } > template<> inline void ScopedFence::prefix() { } > template<> inline void ScopedFence::postfix() { > OrderAccess::fence(); } > > If you don't think this is clear enough, I would happily improve the > description. Perhaps I am being extra cautious since the very original set of calls all assumed the passed in arguments were already volatile, I wanted to save us this problem in 10 years by stating that this assumes that the Scoped templates explicitly cast the addresses to volatiles (which is different than the caller passing in volatiles). So to me there were two ways to get there and I thought it would be valuable to specify this is the assumption. Not a big deal. > >> 3. orderAccess_windows_x86.inline.hpp >> So I looked up _ReadWriteBarrier and VS2012 and VS2013 say this is deprecated. >> JDK8 builds on VS2010, so ok. JDK9 appears to be planning to move to VS2013, so we may need to change this. >> It appears that the recommendation is volatile (with default on x86 of /volatile:ms). Can we use __asm__volatile("" : : : "memory"; >> compiler _barrier for VS2013 or is there an equivalent you know about? > > Unfortunately I currently have no access to windows platforms so I can't > experiment around. But I did some research when I looked into it and it > seems like _ReadWriteBarrier is all we got for now until we adopt C++11 > std::atomic that Microsoft in the deprecation message on their website > suggests we should use instead. > > It seems to have been deprecated because programmers found it confusing > - the name does not suggest it's a compiler-only ordering constraint. > But that's fine for our purposes. > > I just assumed that for now we probably don't want to make such a > radical move to C++11, right? Since it was deprecation or C++11 I > intentionally used _ReadWriteBarrier anyway even though it is > deprecated. Is this a problem? > > When we need to switch, I believe we will be forced to use C++11 on > windows whether we like it or not. It has std::atomic_signal_fence which > should work as a drop-in replacement for _ReadWriteBarrier AFAIK. But > then again, we might as well just map all calls to std::atomic if we > gotta use C++11 anyway... Thank you. Looks like an area we will need to follow-up on. The C++ documentation says atomic_signal_fence just does atomic reordering. The Visual Studio 2012 documentation is not clear on whether it also adds hardware fences. So - go ahead and leave this as is and we will need to switch later. > >> So - do you have plans to do additional changes to the OrderAccess logic? Beyond getting rid of the obsolete entries >> when all platforms are ok with it? > > My biggest concern was correctness and I felt it really had to be done. > I use OrderAccess for my own GC code a lot, and needed to tame it a bit > to work, and thought I might as well contribute the fixes too. ;) Thank you. > > Having looked into the code a bit I know there is still room > improvements in places if you would like me to look into it. Some examples: > > > > 1) x86_64 windows - I suspect this can be improved a /lot/. It seems > like compilers were broken when the code was written at the very > transition point to 64 bit. I believe this can be optimized to use > compiler support I expect is in place today. Yes. > > 2) x86 on solaris: solaris studio was also crippled in the past with no > inline assembly. I believe these optimizations we see on other platforms > could now be ported to solaris as well. Yes. yay! > > 3) _volatile variants of acquire/release/fence/membars: Now we are > conservative, taking volatile to non-volatile reordering into account > using compiler barriers. If the programmer knows this is not needed > since all data published is volatile, maybe it could be good to have > variants explicitly stating it won't be necessary. Yes. > > 4) Joining more store(); release(); pairs to store_release() since some > platforms like ARM can then use stlr instead of full dmb fence which > seems like a good thing in general anyway. > > All previous suggestions revolve around performance (and I don't know > how much we need it). But could also do other things. > > Testing: > > 5) Testing code: it is possible using some light template > metaprogramming to test if the expected specializations of OrderAccess > are indeed used, a bit like @Override in Java - asserting that the > generalized behaviour is indeed specialized as expected for all types we > expect them to be specialized for. > > Further refactoring: > > 6) Forwarding all atomic memory accesses to Atomic:: since it's really a > separate concern. Atomic:: should know how to make atomic accesses for > types used by OrderAccess, and OrderAccess should in shared code just > forward it. Currently Atomic supports all stores but only load of jlong, > making assumptions the rest can use volatile only - an assumption I'm > not willing to make and spread around in the JVM. I share your concerns. > > > > The main problem though is that OrderAcces changes are often inherently > platform specific, and I have very limited access as an outsider to the > platforms. > This time, Jesper has been very kind to me, running JPRT for me which > made these changes possible, and I'm very happy about that. But maybe I > should do less platform specific things when I can't run JPRT. I don't > want to bother people with compiling code for me too much, especially > not if experimenting with what new compiler features have been added > over the years. :) > >> Looks like we have a couple of follow-up exercises: >> 1) check our is_MP usage to ensure we get the compiler_barriers in both paths if we are not using volatile declarations for >> all compiler ordering >> 2) try applying these templates to any other platforms to see how well they work for us as maintainers >> 3) figure out why we use StubRoutines::fence on amd64 Windows but on linux we just use lock; addl 0(sp), MSVC limitation? > > Yes I could volunteer to do 2 (only open variants of course) and 3 if > anyone would be kind to run JPRT for me and/or provide me with machines > I can try things out on (which I suspect is impossible?). I wasn't asking you to do this work - I was suggesting work we should do. No worries. > >> I did not review ppc, zero, arm. > > I should mention Zero changes were reviewed by Severin Gehwolf in the > zero-dev list. He did not have any problem with my changes. Glad to hear that. Thank you. > > Thanks for the review Karen! :) > > /Erik thanks, Karen > >> >> thanks! >> Karen >> On Jan 22, 2015, at 8:19 PM, Erik ?sterlund wrote: >> >>> Hi all, >>> >>> == Summary of Changes == >>> >>> This changeset fixes issues in OrderAccess on multiple levels from the >>> memory model semantics to compiler reorderings, to addressing >>> maintainability/portability issues which (almost) had to be fixed in >>> order to fix the correctness issues. It is the result of discussions >>> found in the previous "OrderAccess Refactoring" thread: >>> http://openjdk.5641.n7.nabble.com/OrderAccess-Refactoring-td212050.html >>> >>> Bug ID: >>> https://bugs.openjdk.java.net/browse/JDK-7143664 >>> (updated to reflect these related changes) >>> >>> Webrev: >>> http://cr.openjdk.java.net/~dholmes/7143664/webrev/ >>> >>> Before I describe more I would like to give special thanks to David >>> Holmes for long discussions leading up to the currently proposed >>> changes. I would also like to thank Jesper Wilhelmsson for helping me >>> run my changes through JPRT. >>> >>> == Motivation == >>> >>> This change directly fixes a reported OrderAccess bug due to compiler >>> reorderings which is still a vulnerability on almost all TSO platforms: >>> https://bugs.openjdk.java.net/browse/JDK-806196 >>> >>> And directly fixes confusions like release_store() != release() store() >>> due to memory model issues previously described in this bug ID. >>> >>> At the same time it provides clearer design with separation of concerns >>> and generalization/specialization, removing a whole bunch of platform >>> specific code which could be generalized. The platform specific files >>> now only have a few LoC requirements (~7) to conform to the memory model >>> by specifying what the stand alone barriers do. Then optionally >>> optimizations to the general approach are possible if platforms support >>> it. This also makes it much easier to port to new platforms. >>> >>> == Memory Model == >>> >>> The current definitions of acquire/release semantics are a bit fishy >>> leading to problems previously described in the bug ID (release_store() >>> != release() store()) and some other correctness issues. It has >>> therefore been replaced with a new model. I would like to thank David >>> Holmes for the long discussions leading up to the newly proposed model. >>> >>> The new model is formally defined like this: >>> >>> // T1: access_shared_data >>> // T1: ]release >>> // T1: (...) >>> // T1: store(X) >>> // >>> // T2: load(X) >>> // T2: (...) >>> // T2: acquire[ >>> // T2: access_shared_data >>> // >>> // It is guaranteed that if T2: load(X) synchronizes with (observes the >>> // value written by) T1: store(X), then the memory accesses before the >>> // T1: ]release happen before the memory accesses after the T2: acquire[. >>> >>> The orderAccess.hpp file and bug ID also has a few additional >>> explanations making it more intuitive to the user when to use >>> acquire/release and the resemblance to TSO abstract machines. Big thanks >>> goes to David Holmes for discussing the memory model with me, which >>> helped a lot in deriving it. >>> >>> Now it holds that release() store() == release_store(), and the other >>> correctness issues are fixed as well. >>> >>> The new model is also closer to C++11 definitions which could give us >>> more relaxed compiler reordering constraints in the future when compiler >>> support for C++11 is there and ready. >>> >>> == Reliance on C++ Volatile Semantics == >>> >>> The C++ standard section 1.9 "Program Execution" is very vague about >>> what the keyword volatile can actually do for us. It gives clear >>> constraints in terms of volatile-volatile accesses but says little about >>> nonvolatile-volatile accesses. Yet the current implementation heavily >>> relies upon volatile to in terms of compiler reordering. But GCC >>> explicitly declares that volatiles and non-volatiles may reorder freely >>> ( https://gcc.gnu.org/onlinedocs/gcc/Volatiles.html ). The only compiler >>> known to explicitly provide the wanted semantics with volatile is MSVC >>> 2010 for windows ( >>> https://msdn.microsoft.com/en-us/library/12a04hfd(v=vs.100).aspx ). >>> Compilers not giving explicit guarantees, must be considered unsafe and >>> revert to conservative behaviour. >>> >>> This was brought to attention after causing bugs, but was only fixed for >>> x86 linux. This is a fundamental issue inherent to all TSO platforms >>> except windows, and has to be fixed on all of them. >>> >>> Several barriers are unsafe to use because they lack compiler reordering >>> constraints (e.g. fence and acquire on linux_SPARC). For TSO platforms >>> they are typically implemented using dummy loads and stores. This seems >>> to be another old volatile reliance that I fixed. These barriers >>> sometimes have omitted compiler barriers (which is what we really want). >>> This seems to be another example on incorrect reliance on the volatile >>> semantics to help us. Therefore dummy loads/stores have been replaced >>> with compiler barriers on TSO platforms. >>> >>> It is also worth noting that compilers like sun studio did previously >>> not support inline asm syntax. Therefore, barriers were implemented in >>> .il-files. However, using them does not give explicit compiler >>> constraints for reordering AFAIK. Therefore, they have been >>> reimplemented using inline asm with explicit compiler reordering >>> constraints, as even sun (solaris?) studio now supports this. >>> >>> The windows variants have added a windows-style _ReadWriteBarrier() >>> compiler barrier similarly. >>> >>> == Strange Hardware Reorderings == >>> >>> Fixed a weird inconsistency where acquire, loadstore and loadlaod would >>> use isync instead of lwsync for PPC on linux_zero, but not in any other >>> PPC platform in the repo. I assumed this is wrong and changed it to >>> lwsync instead. >>> >>> == Code Redundancy and Refactoring == >>> >>> The OrderAccess code looks like it has been developed over a long period >>> of time, with small incremental changes. This seems to have led to a lot >>> of code duplication over time. For example, store_fence variants are not >>> referenced from anywhere, yet contribute to a lot of the code base and a >>> lot of awkwardness (such as being the one only exception not using >>> volatiles for some reason). Moreover, store_fence is not used anywhere >>> in hotspot because it is not a good fit for either the acquire/release >>> semantics or the Java volatile semantics, leaving a big question mark on >>> when it should ever be used. I took the liberty of removing it. >>> >>> Another redundancy issue is that most of the semantics is exactly the >>> same for all platforms, yet all that default boilerplate such as how to >>> make atomic accesses, where acquire/release is supposed to be placed >>> w.r.t. the memory access, what the different barriers should do etc. is >>> copied in redundantly for each os_cpu and each type of memory access for >>> each os_cpu. This makes it extremely painful 1) to understand what >>> actually defines a certain platform compared to the defaults and 2) to >>> correct bugs like those discovered here 3) prevent silly mistakes and >>> bugs, by simply having a lot less code defining the behaviour of >>> OrderAccess that could go wrong. >>> >>> A new architecture/design for OrderAccess is proposed, using a >>> generalization/specialization approach. >>> >>> A general implementation in /share/ defines how things work and splits >>> into different concerns: 1) how to make an atomic memory access, 2) >>> where to but barriers w.r.t. the memory access for things like >>> load_acquire, release_store and release_store_fence, 3) how these >>> barriers are defined. >>> >>> This allows a clear split between what is required for following the >>> specifications, and optimizations, which become much more readable and >>> only optimizations need to be reviewed in depth as the defaults can >>> always be trusted given correct standalone barriers. >>> >>> The only thing a platform is required to specify, is what an >>> implementation of acquire(), release() and fence() should do. If they >>> are implemented properly, everything in OrderAccess is guaranteed to >>> work according to specification using the generalized code. This makes >>> it very easy to support new ports. ALL the other code in the os_cpu >>> files is used /only/ for optimization purposes offered for specific >>> configurations. >>> >>> However, it is highly customizable so that specific platform can perform >>> any desired optimizations. For instance this load_acquire on PPC is >>> optimized: >>> >>> template<> inline jbyte OrderAccess::specialized_load_acquire >>> (volatile jbyte* p) { register jbyte t = load(p); >>> inlasm_acquire_reg(t); return t; } >>> >>> This overrides the whole load_acquire implementation to do something >>> custom. Platforms like x86 extensively use this for joined fencing >>> variants to optimize. >>> >>> The default implementation of load_acquire() will make an atomic load() >>> followed by acquire() since the semantics is generalized. The >>> generalized semantics are defined using inlined postfix/prefix calls >>> after/before the atomic access, as defined here: >>> >>> template<> inline void ScopedFenceGeneral::postfix() { >>> OrderAccess::acquire(); } >>> template<> inline void ScopedFenceGeneral::prefix() { >>> OrderAccess::release(); } >>> template<> inline void ScopedFenceGeneral::prefix() { >>> OrderAccess::release(); } >>> template<> inline void ScopedFenceGeneral::postfix() { >>> OrderAccess::fence(); } >>> >>> For platforms that simply wish to override what e.g. acquire means for a >>> joined ordered memory access in general, as different to calling stand >>> alone acquire(), the semantics can be easily overridden for a platform >>> such as windows like on windows: >>> >>> template<> inline void ScopedFence::postfix() { } >>> template<> inline void ScopedFence::prefix() { } >>> template<> inline void ScopedFence::prefix() { } >>> template<> inline void ScopedFence::postfix() { >>> OrderAccess::fence(); } >>> >>> In this example, since Windows (now) has a compiler barrier for acquire, >>> but does not need it for joined accesses since volatile has stronger >>> guarantees on windows, this is enough to specialize that for joined >>> memory accesses, no extra protection is needed. >>> >>> == Backward Compatibility and Transitioning == >>> >>> Since the newly proposed code is structured differently to before, a >>> #define was added for backward compatibility so that external >>> repositories not adhering to this new architecture do not break. >>> Furthermore, store_release was declared private and marked as >>> deprecated. This allows for a smooth transition into the new style of >>> OrderAccess. When the full transition is made in all known repos, the >>> #define and store_fence may be safely removed, eventually. >>> >>> == Documentation == >>> >>> The documentation seems old and outdated, describing how it works on >>> SPARC RMO and IA64, which are nowhere to be found in the repository. It >>> also describes things about C++ volatiles which cannot be relied upon. >>> The documentation has been cleaned up to match the current state of the >>> implementation better, with architectures actually found in the repository. >>> >>> == Testing == >>> >>> JPRT. Big thanks to Jesper Wilhelmsson for helping me test these changes. >>> Ran some DaCapo benchmarks (I know okay :p) for performance regression >>> and there was no perceivable difference. >>> >>> Looking forward to feedback on this, and hope to get some reviews. :) >>> >>> Thanks, >>> Erik >> >> From gnu.andrew at redhat.com Mon Feb 23 18:57:17 2015 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 23 Feb 2015 13:57:17 -0500 (EST) Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <54EB3FDB.1060609@oracle.com> References: <958867570.14123662.1424262805099.JavaMail.zimbra@redhat.com> <1424314925.5112.149.camel@ocdc> <54E55A01.5020700@oracle.com> <54E56503.4090704@oracle.com> <54E65D27.3070107@oracle.com> <1747776645.16967635.1424701004513.JavaMail.zimbra@redhat.com> <54EB3FDB.1060609@oracle.com> Message-ID: <1106037034.17263798.1424717837816.JavaMail.zimbra@redhat.com> ----- Original Message ----- > I think the jdk changes with ppc64le as CPU make sense. > > Note that the changes to SoundDefs.h and SoundLibraries.gmk will be > obsolete with JDK-8072665 which is currently in the client forest. > Is it worth waiting on this to be promoted to jdk9 then? The change is rather silly in the existing code. X_ARCH doesn't seem to be actually used anywhere, and we've been building fine without a definition for PPC64 (big-endian)... If 8072665 finally gets rid of them, that's one barrier gone for introducing new arch and os ports. > /Erik > > On 2015-02-23 15:16, Andrew Hughes wrote: > > ----- Original Message ----- > >> Apologies to Tiago as there were two webrevs and one got stripped from > >> the email. Here's Tiago's webrev: > >> > >> http://cr.openjdk.java.net/~dholmes/rh1191652-jdk9/webrev.00/ > >> > >> David > >> > >> On 19/02/2015 2:22 PM, David Holmes wrote: > >>> Now hosted at: > >>> > >>> http://cr.openjdk.java.net/~dholmes/ahughes-rh1191652-jdk9-webrev/ > >>> > >>> David > >>> > >>> On 19/02/2015 1:35 PM, David Holmes wrote: > >>>> Hi Tiago, > >>>> > >>>> Please email me the tar files and I will host it for you. > >>>> > >>>> Thanks, > >>>> David > >>>> > >>>> On 19/02/2015 1:02 PM, Tiago Sturmer Daitx wrote: > >>>>> On Wed, 2015-02-18 at 07:33 -0500, Andrew Hughes wrote: > >>>>>> I now have these changes working on 8u31: > >>>>>> > >>>>>> http://cr.openjdk.java.net/~andrew/rh1191652/root > >>>>>> http://cr.openjdk.java.net/~andrew/rh1191652/jdk > >>>>>> > >>>>>> I can re-base these onto whichever OpenJDK 9 tree is appropriate and > >>>>>> push when > >>>>>> reviewed under the same bug as used for the HotSpot side. > >>>>> Concurrently to Andrew I also worked on a fix for JDK9 and came up with > >>>>> a somewhat different approach (based on jdk9/dev): > >>>>> > >>>>> http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/webrev.00/hotspot/ > >>>>> > >>>>> http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/webrev.00/root > >>>>> > >>>>> To make it easy I already rebased Andrew's JDK8u31 patches to jdk9/dev > >>>>> (due to that the webrev ended up with my username). > >>>>> > >>>>> http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/ahughes-webrev.00/hotspot/ > >>>>> > >>>>> > >>>>> http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/ahughes-webrev.00/jdk > >>>>> > >>>>> > >>>>> http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/ahughes-webrev.00/root > >>>>> > >>>>> > >>>>> > >>>>> I tested both approaches by building Hadoop (which triggered some > >>>>> interesting bugs on various projects due to Jigsaw). > >>>>> > >>>>> Sorry for the github links, but I don't have an account at > >>>>> cr.openjdk.java.net that I can use. I can provide tar files if anyone > >>>>> is > >>>>> willing to host those webrevs. > >>>>> > >>>>> Regards, > >>>>> Tiago Daitx > >>>>> > > Where do we go with this next? > > > > I'm still in favour of my own patches on the JDK side, as I think hiding > > the > > architecture there is just asking for problems further down the line. > > -- Andrew :) 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 PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From david.holmes at oracle.com Tue Feb 24 02:30:54 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 24 Feb 2015 12:30:54 +1000 Subject: RFR: 7143664: Clean up OrderAccess implementations and usage In-Reply-To: <18C0D6B6-B28B-461A-A59E-6984114B37B6@oracle.com> References: <91056808-A32B-4713-A061-0E9AED4A5157@oracle.com> <18C0D6B6-B28B-461A-A59E-6984114B37B6@oracle.com> Message-ID: <54EBE25E.2080905@oracle.com> On 24/02/2015 4:45 AM, Karen Kinnear wrote: > > On Feb 20, 2015, at 1:24 PM, Erik ?sterlund wrote: > > And truly many thanks - in my mind you have made this much more conceptually clean and safer. > I am good with your checking in the parts I have reviewed. Thanks Karen! So unless someone has something they really want to be changed now (and I think everyone has so far said there are no strOng objections to anything) then I will push this version: http://cr.openjdk.java.net/~dholmes/7143664/webrev.v4/ in a couple of days. Oh wait - we still haven't heard anything from ppc64 folk - pinging Volker (cc'd :) ). Thanks, David >> Hi Karen, >> >> On 20/02/15 17:04, Karen Kinnear wrote: >>> Erik, >>> >>> 1. orderAccess.hpp >>> Were you going to add a comment about MSVC assumptions under C++ Volatile Semantics? >>> >>> Is it worth documenting in source somewhere what minimal versions of compilers are assumed? >>> Or which versions of compilers were tested? I think that would help us in future please. >>> Maybe in the platform-specific files? >> >> I did not intend to add this comment to shared. I thought that it would >> be enough to say that non-volatile to volatile constraints can not be >> trusted in general. Instead there is a comment explaining this anomaly >> in orderAccess_windows_x86.inline.hpp where it is exploited, since it is >> the only documented exception I know of. >> >> If we start picking certain examples, it feels like we should rather >> have either 1) a comprehensive table of what volatile actually means for >> different compilers with references or question marks where we don't >> know (and hence need to be conservative assuming the worst), or 2) >> putting such comments in platform specific files (like MSVC currently). >> >> Do you agree? In that case, which one do you prefer? >> >> As for documenting compiler versions assumed, would it be enough to >> stamp the code with the currently used compilers we used now, even >> though it might actually have worked with earlier versions? The >> reasoning is that it's unlikely we will go back to using earlier >> compilers anyway, so finding out when exactly certain compilers started >> doing what we want them to could possibly be unnecessary, while still >> having enough information to allow checking if future compilers have >> provided improved functionality from this version of OrderAccess? > It would make more sense to document for the individual platforms. > I'm trying to prevent future "what were they thinking" questions by recording > for each platform the specific compiler version tested. Not all versions that > should work, just the ones we tested it with. >> >>> 2. orderAccess_windows_x86.inline.hpp >>> Could you possibly add to the comment about MSVC, that this assumes all of the Scoped templates explicitly cast the addresses to volatiles? >>> (In case someone changes that some day?) >> >> Sure! But is this not clear given the comment in >> orderAccess_windows_x86.inline.hpp where this is exploited next to the >> scope template specialization: >> >> // Note that in MSVC, volatile memory accesses are explicitly >> // guaranteed to have acquire release semantics (w.r.t. compiler >> // reordering) and therefore does not even need a compiler barrier >> // for normal acquire release accesses. >> template<> inline void ScopedFence::postfix() { } >> template<> inline void ScopedFence::prefix() { } >> template<> inline void ScopedFence::prefix() { } >> template<> inline void ScopedFence::postfix() { >> OrderAccess::fence(); } >> >> If you don't think this is clear enough, I would happily improve the >> description. > Perhaps I am being extra cautious since the very original set of calls all assumed the passed in arguments were > already volatile, I wanted to save us this problem in 10 years by stating that this assumes that the Scoped templates explicitly > cast the addresses to volatiles (which is different than the caller passing in volatiles). So to me there were two ways to get there > and I thought it would be valuable to specify this is the assumption. Not a big deal. >> >>> 3. orderAccess_windows_x86.inline.hpp >>> So I looked up _ReadWriteBarrier and VS2012 and VS2013 say this is deprecated. >>> JDK8 builds on VS2010, so ok. JDK9 appears to be planning to move to VS2013, so we may need to change this. >>> It appears that the recommendation is volatile (with default on x86 of /volatile:ms). Can we use __asm__volatile("" : : : "memory"; >>> compiler _barrier for VS2013 or is there an equivalent you know about? >> >> Unfortunately I currently have no access to windows platforms so I can't >> experiment around. But I did some research when I looked into it and it >> seems like _ReadWriteBarrier is all we got for now until we adopt C++11 >> std::atomic that Microsoft in the deprecation message on their website >> suggests we should use instead. >> >> It seems to have been deprecated because programmers found it confusing >> - the name does not suggest it's a compiler-only ordering constraint. >> But that's fine for our purposes. >> >> I just assumed that for now we probably don't want to make such a >> radical move to C++11, right? Since it was deprecation or C++11 I >> intentionally used _ReadWriteBarrier anyway even though it is >> deprecated. Is this a problem? >> >> When we need to switch, I believe we will be forced to use C++11 on >> windows whether we like it or not. It has std::atomic_signal_fence which >> should work as a drop-in replacement for _ReadWriteBarrier AFAIK. But >> then again, we might as well just map all calls to std::atomic if we >> gotta use C++11 anyway... > Thank you. Looks like an area we will need to follow-up on. > The C++ documentation says atomic_signal_fence just does atomic reordering. > The Visual Studio 2012 documentation is not clear on whether it also adds hardware fences. > > So - go ahead and leave this as is and we will need to switch later. >> >>> So - do you have plans to do additional changes to the OrderAccess logic? Beyond getting rid of the obsolete entries >>> when all platforms are ok with it? >> >> My biggest concern was correctness and I felt it really had to be done. >> I use OrderAccess for my own GC code a lot, and needed to tame it a bit >> to work, and thought I might as well contribute the fixes too. ;) > > Thank you. >> >> Having looked into the code a bit I know there is still room >> improvements in places if you would like me to look into it. Some examples: >> >> >> >> 1) x86_64 windows - I suspect this can be improved a /lot/. It seems >> like compilers were broken when the code was written at the very >> transition point to 64 bit. I believe this can be optimized to use >> compiler support I expect is in place today. > Yes. >> >> 2) x86 on solaris: solaris studio was also crippled in the past with no >> inline assembly. I believe these optimizations we see on other platforms >> could now be ported to solaris as well. > Yes. yay! >> >> 3) _volatile variants of acquire/release/fence/membars: Now we are >> conservative, taking volatile to non-volatile reordering into account >> using compiler barriers. If the programmer knows this is not needed >> since all data published is volatile, maybe it could be good to have >> variants explicitly stating it won't be necessary. > Yes. >> >> 4) Joining more store(); release(); pairs to store_release() since some >> platforms like ARM can then use stlr instead of full dmb fence which >> seems like a good thing in general anyway. >> >> All previous suggestions revolve around performance (and I don't know >> how much we need it). But could also do other things. >> >> Testing: >> >> 5) Testing code: it is possible using some light template >> metaprogramming to test if the expected specializations of OrderAccess >> are indeed used, a bit like @Override in Java - asserting that the >> generalized behaviour is indeed specialized as expected for all types we >> expect them to be specialized for. >> >> Further refactoring: >> >> 6) Forwarding all atomic memory accesses to Atomic:: since it's really a >> separate concern. Atomic:: should know how to make atomic accesses for >> types used by OrderAccess, and OrderAccess should in shared code just >> forward it. Currently Atomic supports all stores but only load of jlong, >> making assumptions the rest can use volatile only - an assumption I'm >> not willing to make and spread around in the JVM. > I share your concerns. >> >> >> >> The main problem though is that OrderAcces changes are often inherently >> platform specific, and I have very limited access as an outsider to the >> platforms. >> This time, Jesper has been very kind to me, running JPRT for me which >> made these changes possible, and I'm very happy about that. But maybe I >> should do less platform specific things when I can't run JPRT. I don't >> want to bother people with compiling code for me too much, especially >> not if experimenting with what new compiler features have been added >> over the years. :) >> >>> Looks like we have a couple of follow-up exercises: >>> 1) check our is_MP usage to ensure we get the compiler_barriers in both paths if we are not using volatile declarations for >>> all compiler ordering >>> 2) try applying these templates to any other platforms to see how well they work for us as maintainers >>> 3) figure out why we use StubRoutines::fence on amd64 Windows but on linux we just use lock; addl 0(sp), MSVC limitation? >> >> Yes I could volunteer to do 2 (only open variants of course) and 3 if >> anyone would be kind to run JPRT for me and/or provide me with machines >> I can try things out on (which I suspect is impossible?). > I wasn't asking you to do this work - I was suggesting work we should do. No worries. >> >>> I did not review ppc, zero, arm. >> >> I should mention Zero changes were reviewed by Severin Gehwolf in the >> zero-dev list. He did not have any problem with my changes. > Glad to hear that. Thank you. >> >> Thanks for the review Karen! :) >> >> /Erik > > > thanks, > Karen >> >>> >>> thanks! >>> Karen >>> On Jan 22, 2015, at 8:19 PM, Erik ?sterlund wrote: >>> >>>> Hi all, >>>> >>>> == Summary of Changes == >>>> >>>> This changeset fixes issues in OrderAccess on multiple levels from the >>>> memory model semantics to compiler reorderings, to addressing >>>> maintainability/portability issues which (almost) had to be fixed in >>>> order to fix the correctness issues. It is the result of discussions >>>> found in the previous "OrderAccess Refactoring" thread: >>>> http://openjdk.5641.n7.nabble.com/OrderAccess-Refactoring-td212050.html >>>> >>>> Bug ID: >>>> https://bugs.openjdk.java.net/browse/JDK-7143664 >>>> (updated to reflect these related changes) >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~dholmes/7143664/webrev/ >>>> >>>> Before I describe more I would like to give special thanks to David >>>> Holmes for long discussions leading up to the currently proposed >>>> changes. I would also like to thank Jesper Wilhelmsson for helping me >>>> run my changes through JPRT. >>>> >>>> == Motivation == >>>> >>>> This change directly fixes a reported OrderAccess bug due to compiler >>>> reorderings which is still a vulnerability on almost all TSO platforms: >>>> https://bugs.openjdk.java.net/browse/JDK-806196 >>>> >>>> And directly fixes confusions like release_store() != release() store() >>>> due to memory model issues previously described in this bug ID. >>>> >>>> At the same time it provides clearer design with separation of concerns >>>> and generalization/specialization, removing a whole bunch of platform >>>> specific code which could be generalized. The platform specific files >>>> now only have a few LoC requirements (~7) to conform to the memory model >>>> by specifying what the stand alone barriers do. Then optionally >>>> optimizations to the general approach are possible if platforms support >>>> it. This also makes it much easier to port to new platforms. >>>> >>>> == Memory Model == >>>> >>>> The current definitions of acquire/release semantics are a bit fishy >>>> leading to problems previously described in the bug ID (release_store() >>>> != release() store()) and some other correctness issues. It has >>>> therefore been replaced with a new model. I would like to thank David >>>> Holmes for the long discussions leading up to the newly proposed model. >>>> >>>> The new model is formally defined like this: >>>> >>>> // T1: access_shared_data >>>> // T1: ]release >>>> // T1: (...) >>>> // T1: store(X) >>>> // >>>> // T2: load(X) >>>> // T2: (...) >>>> // T2: acquire[ >>>> // T2: access_shared_data >>>> // >>>> // It is guaranteed that if T2: load(X) synchronizes with (observes the >>>> // value written by) T1: store(X), then the memory accesses before the >>>> // T1: ]release happen before the memory accesses after the T2: acquire[. >>>> >>>> The orderAccess.hpp file and bug ID also has a few additional >>>> explanations making it more intuitive to the user when to use >>>> acquire/release and the resemblance to TSO abstract machines. Big thanks >>>> goes to David Holmes for discussing the memory model with me, which >>>> helped a lot in deriving it. >>>> >>>> Now it holds that release() store() == release_store(), and the other >>>> correctness issues are fixed as well. >>>> >>>> The new model is also closer to C++11 definitions which could give us >>>> more relaxed compiler reordering constraints in the future when compiler >>>> support for C++11 is there and ready. >>>> >>>> == Reliance on C++ Volatile Semantics == >>>> >>>> The C++ standard section 1.9 "Program Execution" is very vague about >>>> what the keyword volatile can actually do for us. It gives clear >>>> constraints in terms of volatile-volatile accesses but says little about >>>> nonvolatile-volatile accesses. Yet the current implementation heavily >>>> relies upon volatile to in terms of compiler reordering. But GCC >>>> explicitly declares that volatiles and non-volatiles may reorder freely >>>> ( https://gcc.gnu.org/onlinedocs/gcc/Volatiles.html ). The only compiler >>>> known to explicitly provide the wanted semantics with volatile is MSVC >>>> 2010 for windows ( >>>> https://msdn.microsoft.com/en-us/library/12a04hfd(v=vs.100).aspx ). >>>> Compilers not giving explicit guarantees, must be considered unsafe and >>>> revert to conservative behaviour. >>>> >>>> This was brought to attention after causing bugs, but was only fixed for >>>> x86 linux. This is a fundamental issue inherent to all TSO platforms >>>> except windows, and has to be fixed on all of them. >>>> >>>> Several barriers are unsafe to use because they lack compiler reordering >>>> constraints (e.g. fence and acquire on linux_SPARC). For TSO platforms >>>> they are typically implemented using dummy loads and stores. This seems >>>> to be another old volatile reliance that I fixed. These barriers >>>> sometimes have omitted compiler barriers (which is what we really want). >>>> This seems to be another example on incorrect reliance on the volatile >>>> semantics to help us. Therefore dummy loads/stores have been replaced >>>> with compiler barriers on TSO platforms. >>>> >>>> It is also worth noting that compilers like sun studio did previously >>>> not support inline asm syntax. Therefore, barriers were implemented in >>>> .il-files. However, using them does not give explicit compiler >>>> constraints for reordering AFAIK. Therefore, they have been >>>> reimplemented using inline asm with explicit compiler reordering >>>> constraints, as even sun (solaris?) studio now supports this. >>>> >>>> The windows variants have added a windows-style _ReadWriteBarrier() >>>> compiler barrier similarly. >>>> >>>> == Strange Hardware Reorderings == >>>> >>>> Fixed a weird inconsistency where acquire, loadstore and loadlaod would >>>> use isync instead of lwsync for PPC on linux_zero, but not in any other >>>> PPC platform in the repo. I assumed this is wrong and changed it to >>>> lwsync instead. >>>> >>>> == Code Redundancy and Refactoring == >>>> >>>> The OrderAccess code looks like it has been developed over a long period >>>> of time, with small incremental changes. This seems to have led to a lot >>>> of code duplication over time. For example, store_fence variants are not >>>> referenced from anywhere, yet contribute to a lot of the code base and a >>>> lot of awkwardness (such as being the one only exception not using >>>> volatiles for some reason). Moreover, store_fence is not used anywhere >>>> in hotspot because it is not a good fit for either the acquire/release >>>> semantics or the Java volatile semantics, leaving a big question mark on >>>> when it should ever be used. I took the liberty of removing it. >>>> >>>> Another redundancy issue is that most of the semantics is exactly the >>>> same for all platforms, yet all that default boilerplate such as how to >>>> make atomic accesses, where acquire/release is supposed to be placed >>>> w.r.t. the memory access, what the different barriers should do etc. is >>>> copied in redundantly for each os_cpu and each type of memory access for >>>> each os_cpu. This makes it extremely painful 1) to understand what >>>> actually defines a certain platform compared to the defaults and 2) to >>>> correct bugs like those discovered here 3) prevent silly mistakes and >>>> bugs, by simply having a lot less code defining the behaviour of >>>> OrderAccess that could go wrong. >>>> >>>> A new architecture/design for OrderAccess is proposed, using a >>>> generalization/specialization approach. >>>> >>>> A general implementation in /share/ defines how things work and splits >>>> into different concerns: 1) how to make an atomic memory access, 2) >>>> where to but barriers w.r.t. the memory access for things like >>>> load_acquire, release_store and release_store_fence, 3) how these >>>> barriers are defined. >>>> >>>> This allows a clear split between what is required for following the >>>> specifications, and optimizations, which become much more readable and >>>> only optimizations need to be reviewed in depth as the defaults can >>>> always be trusted given correct standalone barriers. >>>> >>>> The only thing a platform is required to specify, is what an >>>> implementation of acquire(), release() and fence() should do. If they >>>> are implemented properly, everything in OrderAccess is guaranteed to >>>> work according to specification using the generalized code. This makes >>>> it very easy to support new ports. ALL the other code in the os_cpu >>>> files is used /only/ for optimization purposes offered for specific >>>> configurations. >>>> >>>> However, it is highly customizable so that specific platform can perform >>>> any desired optimizations. For instance this load_acquire on PPC is >>>> optimized: >>>> >>>> template<> inline jbyte OrderAccess::specialized_load_acquire >>>> (volatile jbyte* p) { register jbyte t = load(p); >>>> inlasm_acquire_reg(t); return t; } >>>> >>>> This overrides the whole load_acquire implementation to do something >>>> custom. Platforms like x86 extensively use this for joined fencing >>>> variants to optimize. >>>> >>>> The default implementation of load_acquire() will make an atomic load() >>>> followed by acquire() since the semantics is generalized. The >>>> generalized semantics are defined using inlined postfix/prefix calls >>>> after/before the atomic access, as defined here: >>>> >>>> template<> inline void ScopedFenceGeneral::postfix() { >>>> OrderAccess::acquire(); } >>>> template<> inline void ScopedFenceGeneral::prefix() { >>>> OrderAccess::release(); } >>>> template<> inline void ScopedFenceGeneral::prefix() { >>>> OrderAccess::release(); } >>>> template<> inline void ScopedFenceGeneral::postfix() { >>>> OrderAccess::fence(); } >>>> >>>> For platforms that simply wish to override what e.g. acquire means for a >>>> joined ordered memory access in general, as different to calling stand >>>> alone acquire(), the semantics can be easily overridden for a platform >>>> such as windows like on windows: >>>> >>>> template<> inline void ScopedFence::postfix() { } >>>> template<> inline void ScopedFence::prefix() { } >>>> template<> inline void ScopedFence::prefix() { } >>>> template<> inline void ScopedFence::postfix() { >>>> OrderAccess::fence(); } >>>> >>>> In this example, since Windows (now) has a compiler barrier for acquire, >>>> but does not need it for joined accesses since volatile has stronger >>>> guarantees on windows, this is enough to specialize that for joined >>>> memory accesses, no extra protection is needed. >>>> >>>> == Backward Compatibility and Transitioning == >>>> >>>> Since the newly proposed code is structured differently to before, a >>>> #define was added for backward compatibility so that external >>>> repositories not adhering to this new architecture do not break. >>>> Furthermore, store_release was declared private and marked as >>>> deprecated. This allows for a smooth transition into the new style of >>>> OrderAccess. When the full transition is made in all known repos, the >>>> #define and store_fence may be safely removed, eventually. >>>> >>>> == Documentation == >>>> >>>> The documentation seems old and outdated, describing how it works on >>>> SPARC RMO and IA64, which are nowhere to be found in the repository. It >>>> also describes things about C++ volatiles which cannot be relied upon. >>>> The documentation has been cleaned up to match the current state of the >>>> implementation better, with architectures actually found in the repository. >>>> >>>> == Testing == >>>> >>>> JPRT. Big thanks to Jesper Wilhelmsson for helping me test these changes. >>>> Ran some DaCapo benchmarks (I know okay :p) for performance regression >>>> and there was no perceivable difference. >>>> >>>> Looking forward to feedback on this, and hope to get some reviews. :) >>>> >>>> Thanks, >>>> Erik >>> >>> > From serguei.spitsyn at oracle.com Tue Feb 24 08:13:13 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 24 Feb 2015 00:13:13 -0800 Subject: 2-nd round RFR (M) 8046246: the constantPoolCacheOopDesc::adjust_method_entries() used in RedefineClasses does not scale In-Reply-To: <54E7E8AB.6000704@oracle.com> References: <54E57884.8030200@oracle.com> <54E7A7FC.9090709@oracle.com> <54E7E8AB.6000704@oracle.com> Message-ID: <54EC3299.8060203@oracle.com> Hi Coleen, This is a new performance bug that targets another round of performance improvements per our discussion: https://bugs.openjdk.java.net/browse/JDK-8073705: more performance issues in class redefinition Feel free to update it if necessary. Hi Dan, I'd be happy if you have a chance to find cycles to look at the webrev below. Your opinion is always very valuable! No time pressure, just let me know about your intention. :) Thanks, Serguei On 2/20/15 6:08 PM, Coleen Phillimore wrote: > > Serguei, Looks great. > > Thanks, > Coleen > > On 2/20/15, 4:32 PM, serguei.spitsyn at oracle.com wrote: >> The hotspot webrev below addresses the Coleen's comments from the >> 1-st review round. >> >> Open hotspot webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.2/ >> >> >> Open jdk (new unit test) webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8046246-JVMTI-manymethods.1/ >> >> >> Thanks, >> Serguei >> >> >> On 2/18/15 9:45 PM, serguei.spitsyn at oracle.com wrote: >>> Please, review the fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8046246 >>> >>> >>> Open hotspot webrevs: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.1/ >>> >>> >>> Open jdk (new unit test) webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8046246-JVMTI-manymethods.1/ >>> >>> >>> >>> Summary: >>> >>> This performance/scalability issue in class redefinition was >>> reported by HP and the Enterprise Manager team. >>> The following variants of the adjust_method_entries() functions >>> do not scale: >>> ConstantPoolCache::adjust_method_entries() >>> klassVtable::adjust_method_entries() >>> klassItable::adjust_method_entries() >>> InstanceKlass::adjust_default_methods() >>> >>> The ConstantPoolCache::adjust_method_entries() is the most >>> important. >>> >>> The approach is to use the holder->method_with_idnum() like this: >>> Method* new_method = >>> holder->method_with_idnum(old_method->orig_method_idnum()); >>> if (old_method != new_method) { >>> >>> } >>> >>> New algorithm has effectiveness O(M) instead of original O(M^2), >>> where M is count of methods in the class. >>> The new test (see webrev above) was used to mesure CPU time >>> consumed by the >>> ConstantPoolCache::adjust_method_entries() in both original and >>> new approach. >>> >>> The performance numbers are: >>> >>> --------------------------------------------------------------------------------------- >>> >>> Methods: ------ 1,000 --------------- 10,000 ----------------- >>> 20,000 >>> --------------------------------------------------------------------------------------- >>> >>> Orig: 600,000 nsec (1x) 60,500,000 nsec (~100x) >>> 243,000,000 nsec (~400x) >>> New: 16,000 nsec (1x) 178,000 nsec (~10x) >>> 355,000 nsec (~20x) >>> --------------------------------------------------------------------------------------- >>> >>> >>> >>> >>> Testing: >>> In progress: VM SQE RedefineClasses tests, JTREG >>> java/lang/instrument, com/sun/jdi tests >>> >>> >>> Thanks, >>> Serguei >>> >> > From erik.joelsson at oracle.com Tue Feb 24 08:21:23 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 24 Feb 2015 09:21:23 +0100 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <1106037034.17263798.1424717837816.JavaMail.zimbra@redhat.com> References: <958867570.14123662.1424262805099.JavaMail.zimbra@redhat.com> <1424314925.5112.149.camel@ocdc> <54E55A01.5020700@oracle.com> <54E56503.4090704@oracle.com> <54E65D27.3070107@oracle.com> <1747776645.16967635.1424701004513.JavaMail.zimbra@redhat.com> <54EB3FDB.1060609@oracle.com> <1106037034.17263798.1424717837816.JavaMail.zimbra@redhat.com> Message-ID: <54EC3483.1040808@oracle.com> On 2015-02-23 19:57, Andrew Hughes wrote: > ----- Original Message ----- >> I think the jdk changes with ppc64le as CPU make sense. >> >> Note that the changes to SoundDefs.h and SoundLibraries.gmk will be >> obsolete with JDK-8072665 which is currently in the client forest. >> > Is it worth waiting on this to be promoted to jdk9 then? Actually, I think the client people would prefer if a change to those files went through the client forest, but if you rebase there, then there is no change to client files. If it's alright with you, I would recommend either waiting or perhaps just skip out on that change and push early, as we expect it to go away in jdk9/dev in a week or so. /Erik > The change is rather silly in the existing code. X_ARCH doesn't seem > to be actually used anywhere, and we've been building fine without > a definition for PPC64 (big-endian)... If 8072665 finally gets rid of > them, that's one barrier gone for introducing new arch and os ports. > >> /Erik >> >> On 2015-02-23 15:16, Andrew Hughes wrote: >>> ----- Original Message ----- >>>> Apologies to Tiago as there were two webrevs and one got stripped from >>>> the email. Here's Tiago's webrev: >>>> >>>> http://cr.openjdk.java.net/~dholmes/rh1191652-jdk9/webrev.00/ >>>> >>>> David >>>> >>>> On 19/02/2015 2:22 PM, David Holmes wrote: >>>>> Now hosted at: >>>>> >>>>> http://cr.openjdk.java.net/~dholmes/ahughes-rh1191652-jdk9-webrev/ >>>>> >>>>> David >>>>> >>>>> On 19/02/2015 1:35 PM, David Holmes wrote: >>>>>> Hi Tiago, >>>>>> >>>>>> Please email me the tar files and I will host it for you. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> On 19/02/2015 1:02 PM, Tiago Sturmer Daitx wrote: >>>>>>> On Wed, 2015-02-18 at 07:33 -0500, Andrew Hughes wrote: >>>>>>>> I now have these changes working on 8u31: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~andrew/rh1191652/root >>>>>>>> http://cr.openjdk.java.net/~andrew/rh1191652/jdk >>>>>>>> >>>>>>>> I can re-base these onto whichever OpenJDK 9 tree is appropriate and >>>>>>>> push when >>>>>>>> reviewed under the same bug as used for the HotSpot side. >>>>>>> Concurrently to Andrew I also worked on a fix for JDK9 and came up with >>>>>>> a somewhat different approach (based on jdk9/dev): >>>>>>> >>>>>>> http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/webrev.00/hotspot/ >>>>>>> >>>>>>> http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/webrev.00/root >>>>>>> >>>>>>> To make it easy I already rebased Andrew's JDK8u31 patches to jdk9/dev >>>>>>> (due to that the webrev ended up with my username). >>>>>>> >>>>>>> http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/ahughes-webrev.00/hotspot/ >>>>>>> >>>>>>> >>>>>>> http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/ahughes-webrev.00/jdk >>>>>>> >>>>>>> >>>>>>> http://tdaitx.github.com/openjdk-webrev/rh1191652-jdk9/ahughes-webrev.00/root >>>>>>> >>>>>>> >>>>>>> >>>>>>> I tested both approaches by building Hadoop (which triggered some >>>>>>> interesting bugs on various projects due to Jigsaw). >>>>>>> >>>>>>> Sorry for the github links, but I don't have an account at >>>>>>> cr.openjdk.java.net that I can use. I can provide tar files if anyone >>>>>>> is >>>>>>> willing to host those webrevs. >>>>>>> >>>>>>> Regards, >>>>>>> Tiago Daitx >>>>>>> >>> Where do we go with this next? >>> >>> I'm still in favour of my own patches on the JDK side, as I think hiding >>> the >>> architecture there is just asking for problems further down the line. >> From gnu.andrew at redhat.com Tue Feb 24 14:21:07 2015 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 24 Feb 2015 09:21:07 -0500 (EST) Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <54EC3483.1040808@oracle.com> References: <54E55A01.5020700@oracle.com> <54E56503.4090704@oracle.com> <54E65D27.3070107@oracle.com> <1747776645.16967635.1424701004513.JavaMail.zimbra@redhat.com> <54EB3FDB.1060609@oracle.com> <1106037034.17263798.1424717837816.JavaMail.zimbra@redhat.com> <54EC3483.1040808@oracle.com> Message-ID: <817540395.17755484.1424787667774.JavaMail.zimbra@redhat.com> ----- Original Message ----- > > On 2015-02-23 19:57, Andrew Hughes wrote: > > ----- Original Message ----- > >> I think the jdk changes with ppc64le as CPU make sense. > >> > >> Note that the changes to SoundDefs.h and SoundLibraries.gmk will be > >> obsolete with JDK-8072665 which is currently in the client forest. > >> > > Is it worth waiting on this to be promoted to jdk9 then? > Actually, I think the client people would prefer if a change to those > files went through the client forest, but if you rebase there, then > there is no change to client files. If it's alright with you, I would > recommend either waiting or perhaps just skip out on that change and > push early, as we expect it to go away in jdk9/dev in a week or so. > Sure, I can reduce the changes in the jdk tree to just adding the jvm.cfg. Did we decide whether -DABI_ELFv2 was needed or not? If it isn't, then I'll drop this from the webrev too, and also from our version of the ppc64le port on OpenJDK 7. I take it jdk9/dev would be fine for that? Thanks, -- Andrew :) 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 PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From goetz.lindenmaier at sap.com Tue Feb 24 14:39:36 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 24 Feb 2015 14:39:36 +0000 Subject: RFR: 7143664: Clean up OrderAccess implementations and usage In-Reply-To: <54EBE25E.2080905@oracle.com> References: <91056808-A32B-4713-A061-0E9AED4A5157@oracle.com> <18C0D6B6-B28B-461A-A59E-6984114B37B6@oracle.com> <54EBE25E.2080905@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CF98F00@DEWDFEMB12A.global.corp.sap> Hi, we had a look at the changes and are fine with them. I tested the build, it works on aix and linux, and simple tests are fine. I'll run the patch tonight with our nightly tests, but I don't expect any problems. Thanks for pinging us! Best regards, Goetz. -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of David Holmes Sent: Dienstag, 24. Februar 2015 03:31 To: Karen Kinnear; Erik ?sterlund Cc: hotspot-dev developers Subject: Re: RFR: 7143664: Clean up OrderAccess implementations and usage On 24/02/2015 4:45 AM, Karen Kinnear wrote: > > On Feb 20, 2015, at 1:24 PM, Erik ?sterlund wrote: > > And truly many thanks - in my mind you have made this much more conceptually clean and safer. > I am good with your checking in the parts I have reviewed. Thanks Karen! So unless someone has something they really want to be changed now (and I think everyone has so far said there are no strOng objections to anything) then I will push this version: http://cr.openjdk.java.net/~dholmes/7143664/webrev.v4/ in a couple of days. Oh wait - we still haven't heard anything from ppc64 folk - pinging Volker (cc'd :) ). Thanks, David >> Hi Karen, >> >> On 20/02/15 17:04, Karen Kinnear wrote: >>> Erik, >>> >>> 1. orderAccess.hpp >>> Were you going to add a comment about MSVC assumptions under C++ Volatile Semantics? >>> >>> Is it worth documenting in source somewhere what minimal versions of compilers are assumed? >>> Or which versions of compilers were tested? I think that would help us in future please. >>> Maybe in the platform-specific files? >> >> I did not intend to add this comment to shared. I thought that it would >> be enough to say that non-volatile to volatile constraints can not be >> trusted in general. Instead there is a comment explaining this anomaly >> in orderAccess_windows_x86.inline.hpp where it is exploited, since it is >> the only documented exception I know of. >> >> If we start picking certain examples, it feels like we should rather >> have either 1) a comprehensive table of what volatile actually means for >> different compilers with references or question marks where we don't >> know (and hence need to be conservative assuming the worst), or 2) >> putting such comments in platform specific files (like MSVC currently). >> >> Do you agree? In that case, which one do you prefer? >> >> As for documenting compiler versions assumed, would it be enough to >> stamp the code with the currently used compilers we used now, even >> though it might actually have worked with earlier versions? The >> reasoning is that it's unlikely we will go back to using earlier >> compilers anyway, so finding out when exactly certain compilers started >> doing what we want them to could possibly be unnecessary, while still >> having enough information to allow checking if future compilers have >> provided improved functionality from this version of OrderAccess? > It would make more sense to document for the individual platforms. > I'm trying to prevent future "what were they thinking" questions by recording > for each platform the specific compiler version tested. Not all versions that > should work, just the ones we tested it with. >> >>> 2. orderAccess_windows_x86.inline.hpp >>> Could you possibly add to the comment about MSVC, that this assumes all of the Scoped templates explicitly cast the addresses to volatiles? >>> (In case someone changes that some day?) >> >> Sure! But is this not clear given the comment in >> orderAccess_windows_x86.inline.hpp where this is exploited next to the >> scope template specialization: >> >> // Note that in MSVC, volatile memory accesses are explicitly >> // guaranteed to have acquire release semantics (w.r.t. compiler >> // reordering) and therefore does not even need a compiler barrier >> // for normal acquire release accesses. >> template<> inline void ScopedFence::postfix() { } >> template<> inline void ScopedFence::prefix() { } >> template<> inline void ScopedFence::prefix() { } >> template<> inline void ScopedFence::postfix() { >> OrderAccess::fence(); } >> >> If you don't think this is clear enough, I would happily improve the >> description. > Perhaps I am being extra cautious since the very original set of calls all assumed the passed in arguments were > already volatile, I wanted to save us this problem in 10 years by stating that this assumes that the Scoped templates explicitly > cast the addresses to volatiles (which is different than the caller passing in volatiles). So to me there were two ways to get there > and I thought it would be valuable to specify this is the assumption. Not a big deal. >> >>> 3. orderAccess_windows_x86.inline.hpp >>> So I looked up _ReadWriteBarrier and VS2012 and VS2013 say this is deprecated. >>> JDK8 builds on VS2010, so ok. JDK9 appears to be planning to move to VS2013, so we may need to change this. >>> It appears that the recommendation is volatile (with default on x86 of /volatile:ms). Can we use __asm__volatile("" : : : "memory"; >>> compiler _barrier for VS2013 or is there an equivalent you know about? >> >> Unfortunately I currently have no access to windows platforms so I can't >> experiment around. But I did some research when I looked into it and it >> seems like _ReadWriteBarrier is all we got for now until we adopt C++11 >> std::atomic that Microsoft in the deprecation message on their website >> suggests we should use instead. >> >> It seems to have been deprecated because programmers found it confusing >> - the name does not suggest it's a compiler-only ordering constraint. >> But that's fine for our purposes. >> >> I just assumed that for now we probably don't want to make such a >> radical move to C++11, right? Since it was deprecation or C++11 I >> intentionally used _ReadWriteBarrier anyway even though it is >> deprecated. Is this a problem? >> >> When we need to switch, I believe we will be forced to use C++11 on >> windows whether we like it or not. It has std::atomic_signal_fence which >> should work as a drop-in replacement for _ReadWriteBarrier AFAIK. But >> then again, we might as well just map all calls to std::atomic if we >> gotta use C++11 anyway... > Thank you. Looks like an area we will need to follow-up on. > The C++ documentation says atomic_signal_fence just does atomic reordering. > The Visual Studio 2012 documentation is not clear on whether it also adds hardware fences. > > So - go ahead and leave this as is and we will need to switch later. >> >>> So - do you have plans to do additional changes to the OrderAccess logic? Beyond getting rid of the obsolete entries >>> when all platforms are ok with it? >> >> My biggest concern was correctness and I felt it really had to be done. >> I use OrderAccess for my own GC code a lot, and needed to tame it a bit >> to work, and thought I might as well contribute the fixes too. ;) > > Thank you. >> >> Having looked into the code a bit I know there is still room >> improvements in places if you would like me to look into it. Some examples: >> >> >> >> 1) x86_64 windows - I suspect this can be improved a /lot/. It seems >> like compilers were broken when the code was written at the very >> transition point to 64 bit. I believe this can be optimized to use >> compiler support I expect is in place today. > Yes. >> >> 2) x86 on solaris: solaris studio was also crippled in the past with no >> inline assembly. I believe these optimizations we see on other platforms >> could now be ported to solaris as well. > Yes. yay! >> >> 3) _volatile variants of acquire/release/fence/membars: Now we are >> conservative, taking volatile to non-volatile reordering into account >> using compiler barriers. If the programmer knows this is not needed >> since all data published is volatile, maybe it could be good to have >> variants explicitly stating it won't be necessary. > Yes. >> >> 4) Joining more store(); release(); pairs to store_release() since some >> platforms like ARM can then use stlr instead of full dmb fence which >> seems like a good thing in general anyway. >> >> All previous suggestions revolve around performance (and I don't know >> how much we need it). But could also do other things. >> >> Testing: >> >> 5) Testing code: it is possible using some light template >> metaprogramming to test if the expected specializations of OrderAccess >> are indeed used, a bit like @Override in Java - asserting that the >> generalized behaviour is indeed specialized as expected for all types we >> expect them to be specialized for. >> >> Further refactoring: >> >> 6) Forwarding all atomic memory accesses to Atomic:: since it's really a >> separate concern. Atomic:: should know how to make atomic accesses for >> types used by OrderAccess, and OrderAccess should in shared code just >> forward it. Currently Atomic supports all stores but only load of jlong, >> making assumptions the rest can use volatile only - an assumption I'm >> not willing to make and spread around in the JVM. > I share your concerns. >> >> >> >> The main problem though is that OrderAcces changes are often inherently >> platform specific, and I have very limited access as an outsider to the >> platforms. >> This time, Jesper has been very kind to me, running JPRT for me which >> made these changes possible, and I'm very happy about that. But maybe I >> should do less platform specific things when I can't run JPRT. I don't >> want to bother people with compiling code for me too much, especially >> not if experimenting with what new compiler features have been added >> over the years. :) >> >>> Looks like we have a couple of follow-up exercises: >>> 1) check our is_MP usage to ensure we get the compiler_barriers in both paths if we are not using volatile declarations for >>> all compiler ordering >>> 2) try applying these templates to any other platforms to see how well they work for us as maintainers >>> 3) figure out why we use StubRoutines::fence on amd64 Windows but on linux we just use lock; addl 0(sp), MSVC limitation? >> >> Yes I could volunteer to do 2 (only open variants of course) and 3 if >> anyone would be kind to run JPRT for me and/or provide me with machines >> I can try things out on (which I suspect is impossible?). > I wasn't asking you to do this work - I was suggesting work we should do. No worries. >> >>> I did not review ppc, zero, arm. >> >> I should mention Zero changes were reviewed by Severin Gehwolf in the >> zero-dev list. He did not have any problem with my changes. > Glad to hear that. Thank you. >> >> Thanks for the review Karen! :) >> >> /Erik > > > thanks, > Karen >> >>> >>> thanks! >>> Karen >>> On Jan 22, 2015, at 8:19 PM, Erik ?sterlund wrote: >>> >>>> Hi all, >>>> >>>> == Summary of Changes == >>>> >>>> This changeset fixes issues in OrderAccess on multiple levels from the >>>> memory model semantics to compiler reorderings, to addressing >>>> maintainability/portability issues which (almost) had to be fixed in >>>> order to fix the correctness issues. It is the result of discussions >>>> found in the previous "OrderAccess Refactoring" thread: >>>> http://openjdk.5641.n7.nabble.com/OrderAccess-Refactoring-td212050.html >>>> >>>> Bug ID: >>>> https://bugs.openjdk.java.net/browse/JDK-7143664 >>>> (updated to reflect these related changes) >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~dholmes/7143664/webrev/ >>>> >>>> Before I describe more I would like to give special thanks to David >>>> Holmes for long discussions leading up to the currently proposed >>>> changes. I would also like to thank Jesper Wilhelmsson for helping me >>>> run my changes through JPRT. >>>> >>>> == Motivation == >>>> >>>> This change directly fixes a reported OrderAccess bug due to compiler >>>> reorderings which is still a vulnerability on almost all TSO platforms: >>>> https://bugs.openjdk.java.net/browse/JDK-806196 >>>> >>>> And directly fixes confusions like release_store() != release() store() >>>> due to memory model issues previously described in this bug ID. >>>> >>>> At the same time it provides clearer design with separation of concerns >>>> and generalization/specialization, removing a whole bunch of platform >>>> specific code which could be generalized. The platform specific files >>>> now only have a few LoC requirements (~7) to conform to the memory model >>>> by specifying what the stand alone barriers do. Then optionally >>>> optimizations to the general approach are possible if platforms support >>>> it. This also makes it much easier to port to new platforms. >>>> >>>> == Memory Model == >>>> >>>> The current definitions of acquire/release semantics are a bit fishy >>>> leading to problems previously described in the bug ID (release_store() >>>> != release() store()) and some other correctness issues. It has >>>> therefore been replaced with a new model. I would like to thank David >>>> Holmes for the long discussions leading up to the newly proposed model. >>>> >>>> The new model is formally defined like this: >>>> >>>> // T1: access_shared_data >>>> // T1: ]release >>>> // T1: (...) >>>> // T1: store(X) >>>> // >>>> // T2: load(X) >>>> // T2: (...) >>>> // T2: acquire[ >>>> // T2: access_shared_data >>>> // >>>> // It is guaranteed that if T2: load(X) synchronizes with (observes the >>>> // value written by) T1: store(X), then the memory accesses before the >>>> // T1: ]release happen before the memory accesses after the T2: acquire[. >>>> >>>> The orderAccess.hpp file and bug ID also has a few additional >>>> explanations making it more intuitive to the user when to use >>>> acquire/release and the resemblance to TSO abstract machines. Big thanks >>>> goes to David Holmes for discussing the memory model with me, which >>>> helped a lot in deriving it. >>>> >>>> Now it holds that release() store() == release_store(), and the other >>>> correctness issues are fixed as well. >>>> >>>> The new model is also closer to C++11 definitions which could give us >>>> more relaxed compiler reordering constraints in the future when compiler >>>> support for C++11 is there and ready. >>>> >>>> == Reliance on C++ Volatile Semantics == >>>> >>>> The C++ standard section 1.9 "Program Execution" is very vague about >>>> what the keyword volatile can actually do for us. It gives clear >>>> constraints in terms of volatile-volatile accesses but says little about >>>> nonvolatile-volatile accesses. Yet the current implementation heavily >>>> relies upon volatile to in terms of compiler reordering. But GCC >>>> explicitly declares that volatiles and non-volatiles may reorder freely >>>> ( https://gcc.gnu.org/onlinedocs/gcc/Volatiles.html ). The only compiler >>>> known to explicitly provide the wanted semantics with volatile is MSVC >>>> 2010 for windows ( >>>> https://msdn.microsoft.com/en-us/library/12a04hfd(v=vs.100).aspx ). >>>> Compilers not giving explicit guarantees, must be considered unsafe and >>>> revert to conservative behaviour. >>>> >>>> This was brought to attention after causing bugs, but was only fixed for >>>> x86 linux. This is a fundamental issue inherent to all TSO platforms >>>> except windows, and has to be fixed on all of them. >>>> >>>> Several barriers are unsafe to use because they lack compiler reordering >>>> constraints (e.g. fence and acquire on linux_SPARC). For TSO platforms >>>> they are typically implemented using dummy loads and stores. This seems >>>> to be another old volatile reliance that I fixed. These barriers >>>> sometimes have omitted compiler barriers (which is what we really want). >>>> This seems to be another example on incorrect reliance on the volatile >>>> semantics to help us. Therefore dummy loads/stores have been replaced >>>> with compiler barriers on TSO platforms. >>>> >>>> It is also worth noting that compilers like sun studio did previously >>>> not support inline asm syntax. Therefore, barriers were implemented in >>>> .il-files. However, using them does not give explicit compiler >>>> constraints for reordering AFAIK. Therefore, they have been >>>> reimplemented using inline asm with explicit compiler reordering >>>> constraints, as even sun (solaris?) studio now supports this. >>>> >>>> The windows variants have added a windows-style _ReadWriteBarrier() >>>> compiler barrier similarly. >>>> >>>> == Strange Hardware Reorderings == >>>> >>>> Fixed a weird inconsistency where acquire, loadstore and loadlaod would >>>> use isync instead of lwsync for PPC on linux_zero, but not in any other >>>> PPC platform in the repo. I assumed this is wrong and changed it to >>>> lwsync instead. >>>> >>>> == Code Redundancy and Refactoring == >>>> >>>> The OrderAccess code looks like it has been developed over a long period >>>> of time, with small incremental changes. This seems to have led to a lot >>>> of code duplication over time. For example, store_fence variants are not >>>> referenced from anywhere, yet contribute to a lot of the code base and a >>>> lot of awkwardness (such as being the one only exception not using >>>> volatiles for some reason). Moreover, store_fence is not used anywhere >>>> in hotspot because it is not a good fit for either the acquire/release >>>> semantics or the Java volatile semantics, leaving a big question mark on >>>> when it should ever be used. I took the liberty of removing it. >>>> >>>> Another redundancy issue is that most of the semantics is exactly the >>>> same for all platforms, yet all that default boilerplate such as how to >>>> make atomic accesses, where acquire/release is supposed to be placed >>>> w.r.t. the memory access, what the different barriers should do etc. is >>>> copied in redundantly for each os_cpu and each type of memory access for >>>> each os_cpu. This makes it extremely painful 1) to understand what >>>> actually defines a certain platform compared to the defaults and 2) to >>>> correct bugs like those discovered here 3) prevent silly mistakes and >>>> bugs, by simply having a lot less code defining the behaviour of >>>> OrderAccess that could go wrong. >>>> >>>> A new architecture/design for OrderAccess is proposed, using a >>>> generalization/specialization approach. >>>> >>>> A general implementation in /share/ defines how things work and splits >>>> into different concerns: 1) how to make an atomic memory access, 2) >>>> where to but barriers w.r.t. the memory access for things like >>>> load_acquire, release_store and release_store_fence, 3) how these >>>> barriers are defined. >>>> >>>> This allows a clear split between what is required for following the >>>> specifications, and optimizations, which become much more readable and >>>> only optimizations need to be reviewed in depth as the defaults can >>>> always be trusted given correct standalone barriers. >>>> >>>> The only thing a platform is required to specify, is what an >>>> implementation of acquire(), release() and fence() should do. If they >>>> are implemented properly, everything in OrderAccess is guaranteed to >>>> work according to specification using the generalized code. This makes >>>> it very easy to support new ports. ALL the other code in the os_cpu >>>> files is used /only/ for optimization purposes offered for specific >>>> configurations. >>>> >>>> However, it is highly customizable so that specific platform can perform >>>> any desired optimizations. For instance this load_acquire on PPC is >>>> optimized: >>>> >>>> template<> inline jbyte OrderAccess::specialized_load_acquire >>>> (volatile jbyte* p) { register jbyte t = load(p); >>>> inlasm_acquire_reg(t); return t; } >>>> >>>> This overrides the whole load_acquire implementation to do something >>>> custom. Platforms like x86 extensively use this for joined fencing >>>> variants to optimize. >>>> >>>> The default implementation of load_acquire() will make an atomic load() >>>> followed by acquire() since the semantics is generalized. The >>>> generalized semantics are defined using inlined postfix/prefix calls >>>> after/before the atomic access, as defined here: >>>> >>>> template<> inline void ScopedFenceGeneral::postfix() { >>>> OrderAccess::acquire(); } >>>> template<> inline void ScopedFenceGeneral::prefix() { >>>> OrderAccess::release(); } >>>> template<> inline void ScopedFenceGeneral::prefix() { >>>> OrderAccess::release(); } >>>> template<> inline void ScopedFenceGeneral::postfix() { >>>> OrderAccess::fence(); } >>>> >>>> For platforms that simply wish to override what e.g. acquire means for a >>>> joined ordered memory access in general, as different to calling stand >>>> alone acquire(), the semantics can be easily overridden for a platform >>>> such as windows like on windows: >>>> >>>> template<> inline void ScopedFence::postfix() { } >>>> template<> inline void ScopedFence::prefix() { } >>>> template<> inline void ScopedFence::prefix() { } >>>> template<> inline void ScopedFence::postfix() { >>>> OrderAccess::fence(); } >>>> >>>> In this example, since Windows (now) has a compiler barrier for acquire, >>>> but does not need it for joined accesses since volatile has stronger >>>> guarantees on windows, this is enough to specialize that for joined >>>> memory accesses, no extra protection is needed. >>>> >>>> == Backward Compatibility and Transitioning == >>>> >>>> Since the newly proposed code is structured differently to before, a >>>> #define was added for backward compatibility so that external >>>> repositories not adhering to this new architecture do not break. >>>> Furthermore, store_release was declared private and marked as >>>> deprecated. This allows for a smooth transition into the new style of >>>> OrderAccess. When the full transition is made in all known repos, the >>>> #define and store_fence may be safely removed, eventually. >>>> >>>> == Documentation == >>>> >>>> The documentation seems old and outdated, describing how it works on >>>> SPARC RMO and IA64, which are nowhere to be found in the repository. It >>>> also describes things about C++ volatiles which cannot be relied upon. >>>> The documentation has been cleaned up to match the current state of the >>>> implementation better, with architectures actually found in the repository. >>>> >>>> == Testing == >>>> >>>> JPRT. Big thanks to Jesper Wilhelmsson for helping me test these changes. >>>> Ran some DaCapo benchmarks (I know okay :p) for performance regression >>>> and there was no perceivable difference. >>>> >>>> Looking forward to feedback on this, and hope to get some reviews. :) >>>> >>>> Thanks, >>>> Erik >>> >>> > From erik.joelsson at oracle.com Tue Feb 24 14:39:43 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 24 Feb 2015 15:39:43 +0100 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <817540395.17755484.1424787667774.JavaMail.zimbra@redhat.com> References: <54E55A01.5020700@oracle.com> <54E56503.4090704@oracle.com> <54E65D27.3070107@oracle.com> <1747776645.16967635.1424701004513.JavaMail.zimbra@redhat.com> <54EB3FDB.1060609@oracle.com> <1106037034.17263798.1424717837816.JavaMail.zimbra@redhat.com> <54EC3483.1040808@oracle.com> <817540395.17755484.1424787667774.JavaMail.zimbra@redhat.com> Message-ID: <54EC8D2F.6010707@oracle.com> On 2015-02-24 15:21, Andrew Hughes wrote: > > ----- Original Message ----- >> On 2015-02-23 19:57, Andrew Hughes wrote: >>> ----- Original Message ----- >>>> I think the jdk changes with ppc64le as CPU make sense. >>>> >>>> Note that the changes to SoundDefs.h and SoundLibraries.gmk will be >>>> obsolete with JDK-8072665 which is currently in the client forest. >>>> >>> Is it worth waiting on this to be promoted to jdk9 then? >> Actually, I think the client people would prefer if a change to those >> files went through the client forest, but if you rebase there, then >> there is no change to client files. If it's alright with you, I would >> recommend either waiting or perhaps just skip out on that change and >> push early, as we expect it to go away in jdk9/dev in a week or so. >> > Sure, I can reduce the changes in the jdk tree to just adding the jvm.cfg. Sounds good to me. > Did we decide whether -DABI_ELFv2 was needed or not? If it isn't, then I'll > drop this from the webrev too, and also from our version of the ppc64le port > on OpenJDK 7. I don't know the answer to that I'm afraid. > I take it jdk9/dev would be fine for that? That would be the correct forest in that case. /Erik From sgehwolf at redhat.com Tue Feb 24 16:30:06 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 24 Feb 2015 17:30:06 +0100 Subject: [8u60] RFR(S): Bulk backports of Zero fixes Message-ID: <1424795406.3440.66.camel@redhat.com> Hi, Would it be possible to push the following 3 small Zero fixes to JDK 8u dev forest? Patches are the same as for JDK 9 modulo some copyright changes. Original JDK 9 Bugs: https://bugs.openjdk.java.net/browse/JDK-8064815 https://bugs.openjdk.java.net/browse/JDK-8067331 https://bugs.openjdk.java.net/browse/JDK-8067231 Webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/zero-fixes-jdk8u/ JDK-8064815: src/cpu/zero/vm/stack_zero.cpp src/cpu/zero/vm/stack_zero.inline.hpp JDK-8067331: src/os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp src/os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp JDK-8067231: src/share/vm/interpreter/interpreterRuntime.cpp Without those fixes a checkout of jdk8u doesn't even compile (--with-jvm-variants=zero). With them Zero is able to build itself on x86_64 and ppc64. I'd need a sponsor in order to get those fixes pushed. Thanks, Severin From asmundak at google.com Tue Feb 24 17:58:07 2015 From: asmundak at google.com (Alexander Smundak) Date: Tue, 24 Feb 2015 09:58:07 -0800 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <817540395.17755484.1424787667774.JavaMail.zimbra@redhat.com> References: <54E55A01.5020700@oracle.com> <54E56503.4090704@oracle.com> <54E65D27.3070107@oracle.com> <1747776645.16967635.1424701004513.JavaMail.zimbra@redhat.com> <54EB3FDB.1060609@oracle.com> <1106037034.17263798.1424717837816.JavaMail.zimbra@redhat.com> <54EC3483.1040808@oracle.com> <817540395.17755484.1424787667774.JavaMail.zimbra@redhat.com> Message-ID: On Tue, Feb 24, 2015 at 6:21 AM, Andrew Hughes wrote: > Did we decide whether -DABI_ELFv2 was needed or not? If it isn't, then I'll > drop this from the webrev too, and also from our version of the ppc64le port > on OpenJDK 7. I think only hotspot needs it. From erik.osterlund at lnu.se Tue Feb 24 20:39:05 2015 From: erik.osterlund at lnu.se (=?iso-8859-1?Q?Erik_=D6sterlund?=) Date: Tue, 24 Feb 2015 20:39:05 +0000 Subject: RFR: 7143664: Clean up OrderAccess implementations and usage References: <91056808-A32B-4713-A061-0E9AED4A5157@oracle.com> <18C0D6B6-B28B-461A-A59E-6984114B37B6@oracle.com> Message-ID: Hi Karen, On 23/02/15 19:46, Karen Kinnear wrote: > > On Feb 20, 2015, at 1:24 PM, Erik ?sterlund wrote: > > And truly many thanks - in my mind you have made this much more conceptually clean and safer. > I am good with your checking in the parts I have reviewed. Thank you for reviewing this! >> Hi Karen, >> >> On 20/02/15 17:04, Karen Kinnear wrote: >>> Erik, >>> >>> 1. orderAccess.hpp >>> Were you going to add a comment about MSVC assumptions under C++ Volatile Semantics? >>> >>> Is it worth documenting in source somewhere what minimal versions of compilers are assumed? >>> Or which versions of compilers were tested? I think that would help us in future please. >>> Maybe in the platform-specific files? >> >> I did not intend to add this comment to shared. I thought that it would >> be enough to say that non-volatile to volatile constraints can not be >> trusted in general. Instead there is a comment explaining this anomaly >> in orderAccess_windows_x86.inline.hpp where it is exploited, since it is >> the only documented exception I know of. >> >> If we start picking certain examples, it feels like we should rather >> have either 1) a comprehensive table of what volatile actually means for >> different compilers with references or question marks where we don't >> know (and hence need to be conservative assuming the worst), or 2) >> putting such comments in platform specific files (like MSVC currently). >> >> Do you agree? In that case, which one do you prefer? >> >> As for documenting compiler versions assumed, would it be enough to >> stamp the code with the currently used compilers we used now, even >> though it might actually have worked with earlier versions? The >> reasoning is that it's unlikely we will go back to using earlier >> compilers anyway, so finding out when exactly certain compilers started >> doing what we want them to could possibly be unnecessary, while still >> having enough information to allow checking if future compilers have >> provided improved functionality from this version of OrderAccess? > It would make more sense to document for the individual platforms. > I'm trying to prevent future "what were they thinking" questions by recording > for each platform the specific compiler version tested. Not all versions that > should work, just the ones we tested it with. I agree this would be nice. I spoke to David who knows better than me which compiler versions were used. Big thanks for that! I updated comments in the platform specific files to reflect this. >> >>> 2. orderAccess_windows_x86.inline.hpp >>> Could you possibly add to the comment about MSVC, that this assumes all of the Scoped templates explicitly cast the addresses to volatiles? >>> (In case someone changes that some day?) >> >> Sure! But is this not clear given the comment in >> orderAccess_windows_x86.inline.hpp where this is exploited next to the >> scope template specialization: >> >> // Note that in MSVC, volatile memory accesses are explicitly >> // guaranteed to have acquire release semantics (w.r.t. compiler >> // reordering) and therefore does not even need a compiler barrier >> // for normal acquire release accesses. >> template<> inline void ScopedFence::postfix() { } >> template<> inline void ScopedFence::prefix() { } >> template<> inline void ScopedFence::prefix() { } >> template<> inline void ScopedFence::postfix() { >> OrderAccess::fence(); } >> >> If you don't think this is clear enough, I would happily improve the >> description. > Perhaps I am being extra cautious since the very original set of calls all assumed the passed in arguments were > already volatile, I wanted to save us this problem in 10 years by stating that this assumes that the Scoped templates explicitly > cast the addresses to volatiles (which is different than the caller passing in volatiles). So to me there were two ways to get there > and I thought it would be valuable to specify this is the assumption. Not a big deal. Agreed, made it even more explicit in the comment now. >> >>> 3. orderAccess_windows_x86.inline.hpp >>> So I looked up _ReadWriteBarrier and VS2012 and VS2013 say this is deprecated. >>> JDK8 builds on VS2010, so ok. JDK9 appears to be planning to move to VS2013, so we may need to change this. >>> It appears that the recommendation is volatile (with default on x86 of /volatile:ms). Can we use __asm__volatile("" : : : "memory"; >>> compiler _barrier for VS2013 or is there an equivalent you know about? >> >> Unfortunately I currently have no access to windows platforms so I can't >> experiment around. But I did some research when I looked into it and it >> seems like _ReadWriteBarrier is all we got for now until we adopt C++11 >> std::atomic that Microsoft in the deprecation message on their website >> suggests we should use instead. >> >> It seems to have been deprecated because programmers found it confusing >> - the name does not suggest it's a compiler-only ordering constraint. >> But that's fine for our purposes. >> >> I just assumed that for now we probably don't want to make such a >> radical move to C++11, right? Since it was deprecation or C++11 I >> intentionally used _ReadWriteBarrier anyway even though it is >> deprecated. Is this a problem? >> >> When we need to switch, I believe we will be forced to use C++11 on >> windows whether we like it or not. It has std::atomic_signal_fence which >> should work as a drop-in replacement for _ReadWriteBarrier AFAIK. But >> then again, we might as well just map all calls to std::atomic if we >> gotta use C++11 anyway... > Thank you. Looks like an area we will need to follow-up on. > The C++ documentation says atomic_signal_fence just does atomic reordering. > The Visual Studio 2012 documentation is not clear on whether it also adds hardware fences. > > So - go ahead and leave this as is and we will need to switch later. Really? Hmm that's too bad. :/ Oh well the problem can probably be solved (in the future) directly by simply forwarding things to atomic using std::memory_order_acquire etc. I intentionally updated the memory model acquire/release definitions to make this easier in the future. Big thanks for the review! /Erik From erik.osterlund at lnu.se Tue Feb 24 20:44:20 2015 From: erik.osterlund at lnu.se (=?iso-8859-1?Q?Erik_=D6sterlund?=) Date: Tue, 24 Feb 2015 20:44:20 +0000 Subject: RFR: 7143664: Clean up OrderAccess implementations and usage References: <91056808-A32B-4713-A061-0E9AED4A5157@oracle.com> <18C0D6B6-B28B-461A-A59E-6984114B37B6@oracle.com> <54EBE25E.2080905@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF98F00@DEWDFEMB12A.global.corp.sap> Message-ID: Thanks for the review! Do you happen to know the compiler versions used to try this so I can document the platform specific files with that information? /Erik On 24/02/15 15:40, Lindenmaier, Goetz wrote: > Hi, > > we had a look at the changes and are fine with them. > I tested the build, it works on aix and linux, and simple tests > are fine. I'll run the patch tonight with our nightly tests, but I don't > expect any problems. > > Thanks for pinging us! > > Best regards, > Goetz. > > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of David Holmes > Sent: Dienstag, 24. Februar 2015 03:31 > To: Karen Kinnear; Erik ?sterlund > Cc: hotspot-dev developers > Subject: Re: RFR: 7143664: Clean up OrderAccess implementations and usage > > On 24/02/2015 4:45 AM, Karen Kinnear wrote: >> >> On Feb 20, 2015, at 1:24 PM, Erik ?sterlund wrote: >> >> And truly many thanks - in my mind you have made this much more conceptually clean and safer. >> I am good with your checking in the parts I have reviewed. > > Thanks Karen! So unless someone has something they really want to be > changed now (and I think everyone has so far said there are no strOng > objections to anything) then I will push this version: > > http://cr.openjdk.java.net/~dholmes/7143664/webrev.v4/ > > in a couple of days. > > Oh wait - we still haven't heard anything from ppc64 folk - pinging > Volker (cc'd :) ). > > Thanks, > David > > >>> Hi Karen, >>> >>> On 20/02/15 17:04, Karen Kinnear wrote: >>>> Erik, >>>> >>>> 1. orderAccess.hpp >>>> Were you going to add a comment about MSVC assumptions under C++ Volatile Semantics? >>>> >>>> Is it worth documenting in source somewhere what minimal versions of compilers are assumed? >>>> Or which versions of compilers were tested? I think that would help us in future please. >>>> Maybe in the platform-specific files? >>> >>> I did not intend to add this comment to shared. I thought that it would >>> be enough to say that non-volatile to volatile constraints can not be >>> trusted in general. Instead there is a comment explaining this anomaly >>> in orderAccess_windows_x86.inline.hpp where it is exploited, since it is >>> the only documented exception I know of. >>> >>> If we start picking certain examples, it feels like we should rather >>> have either 1) a comprehensive table of what volatile actually means for >>> different compilers with references or question marks where we don't >>> know (and hence need to be conservative assuming the worst), or 2) >>> putting such comments in platform specific files (like MSVC currently). >>> >>> Do you agree? In that case, which one do you prefer? >>> >>> As for documenting compiler versions assumed, would it be enough to >>> stamp the code with the currently used compilers we used now, even >>> though it might actually have worked with earlier versions? The >>> reasoning is that it's unlikely we will go back to using earlier >>> compilers anyway, so finding out when exactly certain compilers started >>> doing what we want them to could possibly be unnecessary, while still >>> having enough information to allow checking if future compilers have >>> provided improved functionality from this version of OrderAccess? >> It would make more sense to document for the individual platforms. >> I'm trying to prevent future "what were they thinking" questions by recording >> for each platform the specific compiler version tested. Not all versions that >> should work, just the ones we tested it with. >>> >>>> 2. orderAccess_windows_x86.inline.hpp >>>> Could you possibly add to the comment about MSVC, that this assumes all of the Scoped templates explicitly cast the addresses to volatiles? >>>> (In case someone changes that some day?) >>> >>> Sure! But is this not clear given the comment in >>> orderAccess_windows_x86.inline.hpp where this is exploited next to the >>> scope template specialization: >>> >>> // Note that in MSVC, volatile memory accesses are explicitly >>> // guaranteed to have acquire release semantics (w.r.t. compiler >>> // reordering) and therefore does not even need a compiler barrier >>> // for normal acquire release accesses. >>> template<> inline void ScopedFence::postfix() { } >>> template<> inline void ScopedFence::prefix() { } >>> template<> inline void ScopedFence::prefix() { } >>> template<> inline void ScopedFence::postfix() { >>> OrderAccess::fence(); } >>> >>> If you don't think this is clear enough, I would happily improve the >>> description. >> Perhaps I am being extra cautious since the very original set of calls all assumed the passed in arguments were >> already volatile, I wanted to save us this problem in 10 years by stating that this assumes that the Scoped templates explicitly >> cast the addresses to volatiles (which is different than the caller passing in volatiles). So to me there were two ways to get there >> and I thought it would be valuable to specify this is the assumption. Not a big deal. >>> >>>> 3. orderAccess_windows_x86.inline.hpp >>>> So I looked up _ReadWriteBarrier and VS2012 and VS2013 say this is deprecated. >>>> JDK8 builds on VS2010, so ok. JDK9 appears to be planning to move to VS2013, so we may need to change this. >>>> It appears that the recommendation is volatile (with default on x86 of /volatile:ms). Can we use __asm__volatile("" : : : "memory"; >>>> compiler _barrier for VS2013 or is there an equivalent you know about? >>> >>> Unfortunately I currently have no access to windows platforms so I can't >>> experiment around. But I did some research when I looked into it and it >>> seems like _ReadWriteBarrier is all we got for now until we adopt C++11 >>> std::atomic that Microsoft in the deprecation message on their website >>> suggests we should use instead. >>> >>> It seems to have been deprecated because programmers found it confusing >>> - the name does not suggest it's a compiler-only ordering constraint. >>> But that's fine for our purposes. >>> >>> I just assumed that for now we probably don't want to make such a >>> radical move to C++11, right? Since it was deprecation or C++11 I >>> intentionally used _ReadWriteBarrier anyway even though it is >>> deprecated. Is this a problem? >>> >>> When we need to switch, I believe we will be forced to use C++11 on >>> windows whether we like it or not. It has std::atomic_signal_fence which >>> should work as a drop-in replacement for _ReadWriteBarrier AFAIK. But >>> then again, we might as well just map all calls to std::atomic if we >>> gotta use C++11 anyway... >> Thank you. Looks like an area we will need to follow-up on. >> The C++ documentation says atomic_signal_fence just does atomic reordering. >> The Visual Studio 2012 documentation is not clear on whether it also adds hardware fences. >> >> So - go ahead and leave this as is and we will need to switch later. >>> >>>> So - do you have plans to do additional changes to the OrderAccess logic? Beyond getting rid of the obsolete entries >>>> when all platforms are ok with it? >>> >>> My biggest concern was correctness and I felt it really had to be done. >>> I use OrderAccess for my own GC code a lot, and needed to tame it a bit >>> to work, and thought I might as well contribute the fixes too. ;) >> >> Thank you. >>> >>> Having looked into the code a bit I know there is still room >>> improvements in places if you would like me to look into it. Some examples: >>> >>> >>> >>> 1) x86_64 windows - I suspect this can be improved a /lot/. It seems >>> like compilers were broken when the code was written at the very >>> transition point to 64 bit. I believe this can be optimized to use >>> compiler support I expect is in place today. >> Yes. >>> >>> 2) x86 on solaris: solaris studio was also crippled in the past with no >>> inline assembly. I believe these optimizations we see on other platforms >>> could now be ported to solaris as well. >> Yes. yay! >>> >>> 3) _volatile variants of acquire/release/fence/membars: Now we are >>> conservative, taking volatile to non-volatile reordering into account >>> using compiler barriers. If the programmer knows this is not needed >>> since all data published is volatile, maybe it could be good to have >>> variants explicitly stating it won't be necessary. >> Yes. >>> >>> 4) Joining more store(); release(); pairs to store_release() since some >>> platforms like ARM can then use stlr instead of full dmb fence which >>> seems like a good thing in general anyway. >>> >>> All previous suggestions revolve around performance (and I don't know >>> how much we need it). But could also do other things. >>> >>> Testing: >>> >>> 5) Testing code: it is possible using some light template >>> metaprogramming to test if the expected specializations of OrderAccess >>> are indeed used, a bit like @Override in Java - asserting that the >>> generalized behaviour is indeed specialized as expected for all types we >>> expect them to be specialized for. >>> >>> Further refactoring: >>> >>> 6) Forwarding all atomic memory accesses to Atomic:: since it's really a >>> separate concern. Atomic:: should know how to make atomic accesses for >>> types used by OrderAccess, and OrderAccess should in shared code just >>> forward it. Currently Atomic supports all stores but only load of jlong, >>> making assumptions the rest can use volatile only - an assumption I'm >>> not willing to make and spread around in the JVM. >> I share your concerns. >>> >>> >>> >>> The main problem though is that OrderAcces changes are often inherently >>> platform specific, and I have very limited access as an outsider to the >>> platforms. >>> This time, Jesper has been very kind to me, running JPRT for me which >>> made these changes possible, and I'm very happy about that. But maybe I >>> should do less platform specific things when I can't run JPRT. I don't >>> want to bother people with compiling code for me too much, especially >>> not if experimenting with what new compiler features have been added >>> over the years. :) >>> >>>> Looks like we have a couple of follow-up exercises: >>>> 1) check our is_MP usage to ensure we get the compiler_barriers in both paths if we are not using volatile declarations for >>>> all compiler ordering >>>> 2) try applying these templates to any other platforms to see how well they work for us as maintainers >>>> 3) figure out why we use StubRoutines::fence on amd64 Windows but on linux we just use lock; addl 0(sp), MSVC limitation? >>> >>> Yes I could volunteer to do 2 (only open variants of course) and 3 if >>> anyone would be kind to run JPRT for me and/or provide me with machines >>> I can try things out on (which I suspect is impossible?). >> I wasn't asking you to do this work - I was suggesting work we should do. No worries. >>> >>>> I did not review ppc, zero, arm. >>> >>> I should mention Zero changes were reviewed by Severin Gehwolf in the >>> zero-dev list. He did not have any problem with my changes. >> Glad to hear that. Thank you. >>> >>> Thanks for the review Karen! :) >>> >>> /Erik >> >> >> thanks, >> Karen >>> >>>> >>>> thanks! >>>> Karen >>>> On Jan 22, 2015, at 8:19 PM, Erik ?sterlund wrote: >>>> >>>>> Hi all, >>>>> >>>>> == Summary of Changes == >>>>> >>>>> This changeset fixes issues in OrderAccess on multiple levels from the >>>>> memory model semantics to compiler reorderings, to addressing >>>>> maintainability/portability issues which (almost) had to be fixed in >>>>> order to fix the correctness issues. It is the result of discussions >>>>> found in the previous "OrderAccess Refactoring" thread: >>>>> http://openjdk.5641.n7.nabble.com/OrderAccess-Refactoring-td212050.html >>>>> >>>>> Bug ID: >>>>> https://bugs.openjdk.java.net/browse/JDK-7143664 >>>>> (updated to reflect these related changes) >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~dholmes/7143664/webrev/ >>>>> >>>>> Before I describe more I would like to give special thanks to David >>>>> Holmes for long discussions leading up to the currently proposed >>>>> changes. I would also like to thank Jesper Wilhelmsson for helping me >>>>> run my changes through JPRT. >>>>> >>>>> == Motivation == >>>>> >>>>> This change directly fixes a reported OrderAccess bug due to compiler >>>>> reorderings which is still a vulnerability on almost all TSO platforms: >>>>> https://bugs.openjdk.java.net/browse/JDK-806196 >>>>> >>>>> And directly fixes confusions like release_store() != release() store() >>>>> due to memory model issues previously described in this bug ID. >>>>> >>>>> At the same time it provides clearer design with separation of concerns >>>>> and generalization/specialization, removing a whole bunch of platform >>>>> specific code which could be generalized. The platform specific files >>>>> now only have a few LoC requirements (~7) to conform to the memory model >>>>> by specifying what the stand alone barriers do. Then optionally >>>>> optimizations to the general approach are possible if platforms support >>>>> it. This also makes it much easier to port to new platforms. >>>>> >>>>> == Memory Model == >>>>> >>>>> The current definitions of acquire/release semantics are a bit fishy >>>>> leading to problems previously described in the bug ID (release_store() >>>>> != release() store()) and some other correctness issues. It has >>>>> therefore been replaced with a new model. I would like to thank David >>>>> Holmes for the long discussions leading up to the newly proposed model. >>>>> >>>>> The new model is formally defined like this: >>>>> >>>>> // T1: access_shared_data >>>>> // T1: ]release >>>>> // T1: (...) >>>>> // T1: store(X) >>>>> // >>>>> // T2: load(X) >>>>> // T2: (...) >>>>> // T2: acquire[ >>>>> // T2: access_shared_data >>>>> // >>>>> // It is guaranteed that if T2: load(X) synchronizes with (observes the >>>>> // value written by) T1: store(X), then the memory accesses before the >>>>> // T1: ]release happen before the memory accesses after the T2: acquire[. >>>>> >>>>> The orderAccess.hpp file and bug ID also has a few additional >>>>> explanations making it more intuitive to the user when to use >>>>> acquire/release and the resemblance to TSO abstract machines. Big thanks >>>>> goes to David Holmes for discussing the memory model with me, which >>>>> helped a lot in deriving it. >>>>> >>>>> Now it holds that release() store() == release_store(), and the other >>>>> correctness issues are fixed as well. >>>>> >>>>> The new model is also closer to C++11 definitions which could give us >>>>> more relaxed compiler reordering constraints in the future when compiler >>>>> support for C++11 is there and ready. >>>>> >>>>> == Reliance on C++ Volatile Semantics == >>>>> >>>>> The C++ standard section 1.9 "Program Execution" is very vague about >>>>> what the keyword volatile can actually do for us. It gives clear >>>>> constraints in terms of volatile-volatile accesses but says little about >>>>> nonvolatile-volatile accesses. Yet the current implementation heavily >>>>> relies upon volatile to in terms of compiler reordering. But GCC >>>>> explicitly declares that volatiles and non-volatiles may reorder freely >>>>> ( https://gcc.gnu.org/onlinedocs/gcc/Volatiles.html ). The only compiler >>>>> known to explicitly provide the wanted semantics with volatile is MSVC >>>>> 2010 for windows ( >>>>> https://msdn.microsoft.com/en-us/library/12a04hfd(v=vs.100).aspx ). >>>>> Compilers not giving explicit guarantees, must be considered unsafe and >>>>> revert to conservative behaviour. >>>>> >>>>> This was brought to attention after causing bugs, but was only fixed for >>>>> x86 linux. This is a fundamental issue inherent to all TSO platforms >>>>> except windows, and has to be fixed on all of them. >>>>> >>>>> Several barriers are unsafe to use because they lack compiler reordering >>>>> constraints (e.g. fence and acquire on linux_SPARC). For TSO platforms >>>>> they are typically implemented using dummy loads and stores. This seems >>>>> to be another old volatile reliance that I fixed. These barriers >>>>> sometimes have omitted compiler barriers (which is what we really want). >>>>> This seems to be another example on incorrect reliance on the volatile >>>>> semantics to help us. Therefore dummy loads/stores have been replaced >>>>> with compiler barriers on TSO platforms. >>>>> >>>>> It is also worth noting that compilers like sun studio did previously >>>>> not support inline asm syntax. Therefore, barriers were implemented in >>>>> .il-files. However, using them does not give explicit compiler >>>>> constraints for reordering AFAIK. Therefore, they have been >>>>> reimplemented using inline asm with explicit compiler reordering >>>>> constraints, as even sun (solaris?) studio now supports this. >>>>> >>>>> The windows variants have added a windows-style _ReadWriteBarrier() >>>>> compiler barrier similarly. >>>>> >>>>> == Strange Hardware Reorderings == >>>>> >>>>> Fixed a weird inconsistency where acquire, loadstore and loadlaod would >>>>> use isync instead of lwsync for PPC on linux_zero, but not in any other >>>>> PPC platform in the repo. I assumed this is wrong and changed it to >>>>> lwsync instead. >>>>> >>>>> == Code Redundancy and Refactoring == >>>>> >>>>> The OrderAccess code looks like it has been developed over a long period >>>>> of time, with small incremental changes. This seems to have led to a lot >>>>> of code duplication over time. For example, store_fence variants are not >>>>> referenced from anywhere, yet contribute to a lot of the code base and a >>>>> lot of awkwardness (such as being the one only exception not using >>>>> volatiles for some reason). Moreover, store_fence is not used anywhere >>>>> in hotspot because it is not a good fit for either the acquire/release >>>>> semantics or the Java volatile semantics, leaving a big question mark on >>>>> when it should ever be used. I took the liberty of removing it. >>>>> >>>>> Another redundancy issue is that most of the semantics is exactly the >>>>> same for all platforms, yet all that default boilerplate such as how to >>>>> make atomic accesses, where acquire/release is supposed to be placed >>>>> w.r.t. the memory access, what the different barriers should do etc. is >>>>> copied in redundantly for each os_cpu and each type of memory access for >>>>> each os_cpu. This makes it extremely painful 1) to understand what >>>>> actually defines a certain platform compared to the defaults and 2) to >>>>> correct bugs like those discovered here 3) prevent silly mistakes and >>>>> bugs, by simply having a lot less code defining the behaviour of >>>>> OrderAccess that could go wrong. >>>>> >>>>> A new architecture/design for OrderAccess is proposed, using a >>>>> generalization/specialization approach. >>>>> >>>>> A general implementation in /share/ defines how things work and splits >>>>> into different concerns: 1) how to make an atomic memory access, 2) >>>>> where to but barriers w.r.t. the memory access for things like >>>>> load_acquire, release_store and release_store_fence, 3) how these >>>>> barriers are defined. >>>>> >>>>> This allows a clear split between what is required for following the >>>>> specifications, and optimizations, which become much more readable and >>>>> only optimizations need to be reviewed in depth as the defaults can >>>>> always be trusted given correct standalone barriers. >>>>> >>>>> The only thing a platform is required to specify, is what an >>>>> implementation of acquire(), release() and fence() should do. If they >>>>> are implemented properly, everything in OrderAccess is guaranteed to >>>>> work according to specification using the generalized code. This makes >>>>> it very easy to support new ports. ALL the other code in the os_cpu >>>>> files is used /only/ for optimization purposes offered for specific >>>>> configurations. >>>>> >>>>> However, it is highly customizable so that specific platform can perform >>>>> any desired optimizations. For instance this load_acquire on PPC is >>>>> optimized: >>>>> >>>>> template<> inline jbyte OrderAccess::specialized_load_acquire >>>>> (volatile jbyte* p) { register jbyte t = load(p); >>>>> inlasm_acquire_reg(t); return t; } >>>>> >>>>> This overrides the whole load_acquire implementation to do something >>>>> custom. Platforms like x86 extensively use this for joined fencing >>>>> variants to optimize. >>>>> >>>>> The default implementation of load_acquire() will make an atomic load() >>>>> followed by acquire() since the semantics is generalized. The >>>>> generalized semantics are defined using inlined postfix/prefix calls >>>>> after/before the atomic access, as defined here: >>>>> >>>>> template<> inline void ScopedFenceGeneral::postfix() { >>>>> OrderAccess::acquire(); } >>>>> template<> inline void ScopedFenceGeneral::prefix() { >>>>> OrderAccess::release(); } >>>>> template<> inline void ScopedFenceGeneral::prefix() { >>>>> OrderAccess::release(); } >>>>> template<> inline void ScopedFenceGeneral::postfix() { >>>>> OrderAccess::fence(); } >>>>> >>>>> For platforms that simply wish to override what e.g. acquire means for a >>>>> joined ordered memory access in general, as different to calling stand >>>>> alone acquire(), the semantics can be easily overridden for a platform >>>>> such as windows like on windows: >>>>> >>>>> template<> inline void ScopedFence::postfix() { } >>>>> template<> inline void ScopedFence::prefix() { } >>>>> template<> inline void ScopedFence::prefix() { } >>>>> template<> inline void ScopedFence::postfix() { >>>>> OrderAccess::fence(); } >>>>> >>>>> In this example, since Windows (now) has a compiler barrier for acquire, >>>>> but does not need it for joined accesses since volatile has stronger >>>>> guarantees on windows, this is enough to specialize that for joined >>>>> memory accesses, no extra protection is needed. >>>>> >>>>> == Backward Compatibility and Transitioning == >>>>> >>>>> Since the newly proposed code is structured differently to before, a >>>>> #define was added for backward compatibility so that external >>>>> repositories not adhering to this new architecture do not break. >>>>> Furthermore, store_release was declared private and marked as >>>>> deprecated. This allows for a smooth transition into the new style of >>>>> OrderAccess. When the full transition is made in all known repos, the >>>>> #define and store_fence may be safely removed, eventually. >>>>> >>>>> == Documentation == >>>>> >>>>> The documentation seems old and outdated, describing how it works on >>>>> SPARC RMO and IA64, which are nowhere to be found in the repository. It >>>>> also describes things about C++ volatiles which cannot be relied upon. >>>>> The documentation has been cleaned up to match the current state of the >>>>> implementation better, with architectures actually found in the repository. >>>>> >>>>> == Testing == >>>>> >>>>> JPRT. Big thanks to Jesper Wilhelmsson for helping me test these changes. >>>>> Ran some DaCapo benchmarks (I know okay :p) for performance regression >>>>> and there was no perceivable difference. >>>>> >>>>> Looking forward to feedback on this, and hope to get some reviews. :) >>>>> >>>>> Thanks, >>>>> Erik >>>> >>>> >> > From david.holmes at oracle.com Wed Feb 25 02:08:49 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 25 Feb 2015 12:08:49 +1000 Subject: [8u60] RFR(S): Bulk backports of Zero fixes In-Reply-To: <1424795406.3440.66.camel@redhat.com> References: <1424795406.3440.66.camel@redhat.com> Message-ID: <54ED2EB1.6040104@oracle.com> Hi Severin, On 25/02/2015 2:30 AM, Severin Gehwolf wrote: > Hi, > > Would it be possible to push the following 3 small Zero fixes to JDK 8u > dev forest? Patches are the same as for JDK 9 modulo some copyright > changes. > > Original JDK 9 Bugs: > https://bugs.openjdk.java.net/browse/JDK-8064815 > https://bugs.openjdk.java.net/browse/JDK-8067331 > https://bugs.openjdk.java.net/browse/JDK-8067231 > > Webrev: > http://cr.openjdk.java.net/~sgehwolf/webrevs/zero-fixes-jdk8u/ > > JDK-8064815: > src/cpu/zero/vm/stack_zero.cpp > src/cpu/zero/vm/stack_zero.inline.hpp > > JDK-8067331: > src/os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp > src/os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp > > JDK-8067231: > src/share/vm/interpreter/interpreterRuntime.cpp > > Without those fixes a checkout of jdk8u doesn't even compile > (--with-jvm-variants=zero). With them Zero is able to build itself on > x86_64 and ppc64. > > I'd need a sponsor in order to get those fixes pushed. I can do this for you. There's only one non-zero file touched. David > Thanks, > Severin > From daniel.daugherty at oracle.com Wed Feb 25 02:59:18 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 24 Feb 2015 19:59:18 -0700 Subject: 2-nd round RFR (M) 8046246: the constantPoolCacheOopDesc::adjust_method_entries() used in RedefineClasses does not scale In-Reply-To: <54E7A7FC.9090709@oracle.com> References: <54E57884.8030200@oracle.com> <54E7A7FC.9090709@oracle.com> Message-ID: <54ED3A86.1050301@oracle.com> On 2/20/15 2:32 PM, serguei.spitsyn at oracle.com wrote: > The hotspot webrev below addresses the Coleen's comments from the 1-st > review round. > > Open hotspot webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.2/ Thumbs up! src/share/vm/oops/instanceKlass.hpp No comments. src/share/vm/oops/instanceKlass.cpp InstanceKlass::adjust_default_methods() - so you drop the outer level of for-loop here by switching from parallel old_methods/new_methods arrays to looping on the target array (default methods) and only fetching the old_method candidate that's in parallel with the current default method _and_ only fetching the new method when you need it. So you've squashed a nested for-loop and you're only fetching the new method when you know you need it. Nicely done. src/share/vm/oops/cpCache.hpp line 482: void adjust_method_entries(InstanceKlass* holder, bool * trace_name_printed); Nit - this line (and the previous) one have a space between 'bool' and '*'. The other pointer params do not. Seems to be a common format difference in 'bool *' params. :-) src/share/vm/oops/cpCache.cpp No comments. src/share/vm/oops/klassVtable.hpp No comments. src/share/vm/oops/klassVtable.cpp klassVtable::adjust_method_entries() and klassItable::adjust_method_entries() have similar loop squashing. Again, nicely done. src/share/vm/prims/jvmtiRedefineClasses.cpp No comments. src/share/vm/classfile/defaultMethods.cpp No comments. src/share/vm/oops/constMethod.hpp Cool way of using a little bit of space to squash some loops. Surprised Coleen let you have a u2 though :-) src/share/vm/oops/method.hpp No comments. src/share/vm/oops/method.cpp No comments. Nit - double check copyright updates before you commit. Dan > Open jdk (new unit test) webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8046246-JVMTI-manymethods.1/ > > > Thanks, > Serguei > > > On 2/18/15 9:45 PM, serguei.spitsyn at oracle.com wrote: >> Please, review the fix for: >> https://bugs.openjdk.java.net/browse/JDK-8046246 >> >> >> Open hotspot webrevs: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.1/ >> >> >> Open jdk (new unit test) webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8046246-JVMTI-manymethods.1/ >> >> >> >> Summary: >> >> This performance/scalability issue in class redefinition was >> reported by HP and the Enterprise Manager team. >> The following variants of the adjust_method_entries() functions do >> not scale: >> ConstantPoolCache::adjust_method_entries() >> klassVtable::adjust_method_entries() >> klassItable::adjust_method_entries() >> InstanceKlass::adjust_default_methods() >> >> The ConstantPoolCache::adjust_method_entries() is the most important. >> >> The approach is to use the holder->method_with_idnum() like this: >> Method* new_method = >> holder->method_with_idnum(old_method->orig_method_idnum()); >> if (old_method != new_method) { >> >> } >> >> New algorithm has effectiveness O(M) instead of original O(M^2), >> where M is count of methods in the class. >> The new test (see webrev above) was used to mesure CPU time >> consumed by the >> ConstantPoolCache::adjust_method_entries() in both original and >> new approach. >> >> The performance numbers are: >> >> --------------------------------------------------------------------------------------- >> >> Methods: ------ 1,000 --------------- 10,000 ----------------- >> 20,000 >> --------------------------------------------------------------------------------------- >> >> Orig: 600,000 nsec (1x) 60,500,000 nsec (~100x) >> 243,000,000 nsec (~400x) >> New: 16,000 nsec (1x) 178,000 nsec (~10x) 355,000 >> nsec (~20x) >> --------------------------------------------------------------------------------------- >> >> >> >> >> Testing: >> In progress: VM SQE RedefineClasses tests, JTREG >> java/lang/instrument, com/sun/jdi tests >> >> >> Thanks, >> Serguei >> > From serguei.spitsyn at oracle.com Wed Feb 25 03:15:42 2015 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 24 Feb 2015 19:15:42 -0800 Subject: 2-nd round RFR (M) 8046246: the constantPoolCacheOopDesc::adjust_method_entries() used in RedefineClasses does not scale In-Reply-To: <54ED3A86.1050301@oracle.com> References: <54E57884.8030200@oracle.com> <54E7A7FC.9090709@oracle.com> <54ED3A86.1050301@oracle.com> Message-ID: <54ED3E5E.90807@oracle.com> Dan, On 2/24/15 6:59 PM, Daniel D. Daugherty wrote: > On 2/20/15 2:32 PM, serguei.spitsyn at oracle.com wrote: >> The hotspot webrev below addresses the Coleen's comments from the >> 1-st review round. >> >> Open hotspot webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.2/ >> > > Thumbs up! Thanks a lot! > > src/share/vm/oops/instanceKlass.hpp > No comments. > > src/share/vm/oops/instanceKlass.cpp > InstanceKlass::adjust_default_methods() - so you drop the outer level > of for-loop here by switching from parallel old_methods/new_methods > arrays to looping on the target array (default methods) and only > fetching the old_method candidate that's in parallel with the > current default method _and_ only fetching the new method when you > need it. > > So you've squashed a nested for-loop and you're only fetching the > new method when you know you need it. Nicely done. Thanks > > src/share/vm/oops/cpCache.hpp > line 482: void adjust_method_entries(InstanceKlass* holder, bool * > trace_name_printed); > Nit - this line (and the previous) one have a space between > 'bool' and '*'. The other pointer params do not. Seems to be > a common format difference in 'bool *' params. :-) I agree, it is better to fix it as the line is touched anyway. > > src/share/vm/oops/cpCache.cpp > No comments. > > src/share/vm/oops/klassVtable.hpp > No comments. > > src/share/vm/oops/klassVtable.cpp > klassVtable::adjust_method_entries() and > klassItable::adjust_method_entries() have similar > loop squashing. Again, nicely done. > > src/share/vm/prims/jvmtiRedefineClasses.cpp > No comments. I'm also thinking how to optimize this call: 3438 for (InstanceKlass* pv_node = ik->previous_versions(); 3439 pv_node != NULL; 3440 pv_node = pv_node->previous_versions()) { 3441 cp_cache = pv_node->constants()->cache(); 3442 if (cp_cache != NULL) { 3443 cp_cache->adjust_method_entries(_matching_old_methods, 3444 _matching_new_methods, 3445 _matching_methods_length, 3446 &trace_name_printed); 3447 } 3448 } But I left it for possible future improvement that is covered by new bug: https://bugs.openjdk.java.net/browse/JDK-8073705 > > src/share/vm/classfile/defaultMethods.cpp > No comments. > > src/share/vm/oops/constMethod.hpp > Cool way of using a little bit of space to squash > some loops. Surprised Coleen let you have a u2 though :-) Yes, I'm grateful to Coleen that she suggested it! :) > > src/share/vm/oops/method.hpp > No comments. > > src/share/vm/oops/method.cpp > No comments. > > Nit - double check copyright updates before you commit. Sure, that was my plan. Thanks! Serguei > > Dan > > > > >> Open jdk (new unit test) webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8046246-JVMTI-manymethods.1/ >> >> >> Thanks, >> Serguei >> >> >> On 2/18/15 9:45 PM, serguei.spitsyn at oracle.com wrote: >>> Please, review the fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8046246 >>> >>> >>> Open hotspot webrevs: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.1/ >>> >>> >>> Open jdk (new unit test) webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8046246-JVMTI-manymethods.1/ >>> >>> >>> >>> Summary: >>> >>> This performance/scalability issue in class redefinition was >>> reported by HP and the Enterprise Manager team. >>> The following variants of the adjust_method_entries() functions >>> do not scale: >>> ConstantPoolCache::adjust_method_entries() >>> klassVtable::adjust_method_entries() >>> klassItable::adjust_method_entries() >>> InstanceKlass::adjust_default_methods() >>> >>> The ConstantPoolCache::adjust_method_entries() is the most >>> important. >>> >>> The approach is to use the holder->method_with_idnum() like this: >>> Method* new_method = >>> holder->method_with_idnum(old_method->orig_method_idnum()); >>> if (old_method != new_method) { >>> >>> } >>> >>> New algorithm has effectiveness O(M) instead of original O(M^2), >>> where M is count of methods in the class. >>> The new test (see webrev above) was used to mesure CPU time >>> consumed by the >>> ConstantPoolCache::adjust_method_entries() in both original and >>> new approach. >>> >>> The performance numbers are: >>> >>> --------------------------------------------------------------------------------------- >>> >>> Methods: ------ 1,000 --------------- 10,000 ----------------- >>> 20,000 >>> --------------------------------------------------------------------------------------- >>> >>> Orig: 600,000 nsec (1x) 60,500,000 nsec (~100x) >>> 243,000,000 nsec (~400x) >>> New: 16,000 nsec (1x) 178,000 nsec (~10x) >>> 355,000 nsec (~20x) >>> --------------------------------------------------------------------------------------- >>> >>> >>> >>> >>> Testing: >>> In progress: VM SQE RedefineClasses tests, JTREG >>> java/lang/instrument, com/sun/jdi tests >>> >>> >>> Thanks, >>> Serguei >>> >> > From sgehwolf at redhat.com Wed Feb 25 09:33:43 2015 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 25 Feb 2015 10:33:43 +0100 Subject: [8u60] RFR(S): Bulk backports of Zero fixes In-Reply-To: <54ED2EB1.6040104@oracle.com> References: <1424795406.3440.66.camel@redhat.com> <54ED2EB1.6040104@oracle.com> Message-ID: <1424856823.3327.1.camel@redhat.com> On Wed, 2015-02-25 at 12:08 +1000, David Holmes wrote: > Hi Severin, > > On 25/02/2015 2:30 AM, Severin Gehwolf wrote: > > Hi, > > > > Would it be possible to push the following 3 small Zero fixes to JDK 8u > > dev forest? Patches are the same as for JDK 9 modulo some copyright > > changes. > > > > Original JDK 9 Bugs: > > https://bugs.openjdk.java.net/browse/JDK-8064815 > > https://bugs.openjdk.java.net/browse/JDK-8067331 > > https://bugs.openjdk.java.net/browse/JDK-8067231 > > > > Webrev: > > http://cr.openjdk.java.net/~sgehwolf/webrevs/zero-fixes-jdk8u/ > > > > JDK-8064815: > > src/cpu/zero/vm/stack_zero.cpp > > src/cpu/zero/vm/stack_zero.inline.hpp > > > > JDK-8067331: > > src/os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp > > src/os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp > > > > JDK-8067231: > > src/share/vm/interpreter/interpreterRuntime.cpp > > > > Without those fixes a checkout of jdk8u doesn't even compile > > (--with-jvm-variants=zero). With them Zero is able to build itself on > > x86_64 and ppc64. > > > > I'd need a sponsor in order to get those fixes pushed. > > I can do this for you. There's only one non-zero file touched. Thank you, David! Please let me know if there is anything more you need from me. Cheers, Severin > David > > > > Thanks, > > Severin > > From goetz.lindenmaier at sap.com Wed Feb 25 10:11:52 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 25 Feb 2015 10:11:52 +0000 Subject: RFR: 7143664: Clean up OrderAccess implementations and usage In-Reply-To: References: <91056808-A32B-4713-A061-0E9AED4A5157@oracle.com> <18C0D6B6-B28B-461A-A59E-6984114B37B6@oracle.com> <54EBE25E.2080905@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF98F00@DEWDFEMB12A.global.corp.sap> Message-ID: <4295855A5C1DE049A61835A1887419CC2CF99102@DEWDFEMB12A.global.corp.sap> Hi Eric, we compile with gcc 4.1.2 and xlc 12. Our nightly tests are all green. Best regards, Goetz IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72) Version: 12.01.0000.0008 g++ (GCC) 4.1.2 20070115 (SUSE Linux) -----Original Message----- From: Erik ?sterlund [mailto:erik.osterlund at lnu.se] Sent: Dienstag, 24. Februar 2015 21:44 To: Lindenmaier, Goetz; David Holmes; Karen Kinnear Cc: hotspot-dev developers; Doerr, Martin Subject: Re: RFR: 7143664: Clean up OrderAccess implementations and usage Thanks for the review! Do you happen to know the compiler versions used to try this so I can document the platform specific files with that information? /Erik On 24/02/15 15:40, Lindenmaier, Goetz wrote: > Hi, > > we had a look at the changes and are fine with them. > I tested the build, it works on aix and linux, and simple tests > are fine. I'll run the patch tonight with our nightly tests, but I don't > expect any problems. > > Thanks for pinging us! > > Best regards, > Goetz. > > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of David Holmes > Sent: Dienstag, 24. Februar 2015 03:31 > To: Karen Kinnear; Erik ?sterlund > Cc: hotspot-dev developers > Subject: Re: RFR: 7143664: Clean up OrderAccess implementations and usage > > On 24/02/2015 4:45 AM, Karen Kinnear wrote: >> >> On Feb 20, 2015, at 1:24 PM, Erik ?sterlund wrote: >> >> And truly many thanks - in my mind you have made this much more conceptually clean and safer. >> I am good with your checking in the parts I have reviewed. > > Thanks Karen! So unless someone has something they really want to be > changed now (and I think everyone has so far said there are no strOng > objections to anything) then I will push this version: > > http://cr.openjdk.java.net/~dholmes/7143664/webrev.v4/ > > in a couple of days. > > Oh wait - we still haven't heard anything from ppc64 folk - pinging > Volker (cc'd :) ). > > Thanks, > David > > >>> Hi Karen, >>> >>> On 20/02/15 17:04, Karen Kinnear wrote: >>>> Erik, >>>> >>>> 1. orderAccess.hpp >>>> Were you going to add a comment about MSVC assumptions under C++ Volatile Semantics? >>>> >>>> Is it worth documenting in source somewhere what minimal versions of compilers are assumed? >>>> Or which versions of compilers were tested? I think that would help us in future please. >>>> Maybe in the platform-specific files? >>> >>> I did not intend to add this comment to shared. I thought that it would >>> be enough to say that non-volatile to volatile constraints can not be >>> trusted in general. Instead there is a comment explaining this anomaly >>> in orderAccess_windows_x86.inline.hpp where it is exploited, since it is >>> the only documented exception I know of. >>> >>> If we start picking certain examples, it feels like we should rather >>> have either 1) a comprehensive table of what volatile actually means for >>> different compilers with references or question marks where we don't >>> know (and hence need to be conservative assuming the worst), or 2) >>> putting such comments in platform specific files (like MSVC currently). >>> >>> Do you agree? In that case, which one do you prefer? >>> >>> As for documenting compiler versions assumed, would it be enough to >>> stamp the code with the currently used compilers we used now, even >>> though it might actually have worked with earlier versions? The >>> reasoning is that it's unlikely we will go back to using earlier >>> compilers anyway, so finding out when exactly certain compilers started >>> doing what we want them to could possibly be unnecessary, while still >>> having enough information to allow checking if future compilers have >>> provided improved functionality from this version of OrderAccess? >> It would make more sense to document for the individual platforms. >> I'm trying to prevent future "what were they thinking" questions by recording >> for each platform the specific compiler version tested. Not all versions that >> should work, just the ones we tested it with. >>> >>>> 2. orderAccess_windows_x86.inline.hpp >>>> Could you possibly add to the comment about MSVC, that this assumes all of the Scoped templates explicitly cast the addresses to volatiles? >>>> (In case someone changes that some day?) >>> >>> Sure! But is this not clear given the comment in >>> orderAccess_windows_x86.inline.hpp where this is exploited next to the >>> scope template specialization: >>> >>> // Note that in MSVC, volatile memory accesses are explicitly >>> // guaranteed to have acquire release semantics (w.r.t. compiler >>> // reordering) and therefore does not even need a compiler barrier >>> // for normal acquire release accesses. >>> template<> inline void ScopedFence::postfix() { } >>> template<> inline void ScopedFence::prefix() { } >>> template<> inline void ScopedFence::prefix() { } >>> template<> inline void ScopedFence::postfix() { >>> OrderAccess::fence(); } >>> >>> If you don't think this is clear enough, I would happily improve the >>> description. >> Perhaps I am being extra cautious since the very original set of calls all assumed the passed in arguments were >> already volatile, I wanted to save us this problem in 10 years by stating that this assumes that the Scoped templates explicitly >> cast the addresses to volatiles (which is different than the caller passing in volatiles). So to me there were two ways to get there >> and I thought it would be valuable to specify this is the assumption. Not a big deal. >>> >>>> 3. orderAccess_windows_x86.inline.hpp >>>> So I looked up _ReadWriteBarrier and VS2012 and VS2013 say this is deprecated. >>>> JDK8 builds on VS2010, so ok. JDK9 appears to be planning to move to VS2013, so we may need to change this. >>>> It appears that the recommendation is volatile (with default on x86 of /volatile:ms). Can we use __asm__volatile("" : : : "memory"; >>>> compiler _barrier for VS2013 or is there an equivalent you know about? >>> >>> Unfortunately I currently have no access to windows platforms so I can't >>> experiment around. But I did some research when I looked into it and it >>> seems like _ReadWriteBarrier is all we got for now until we adopt C++11 >>> std::atomic that Microsoft in the deprecation message on their website >>> suggests we should use instead. >>> >>> It seems to have been deprecated because programmers found it confusing >>> - the name does not suggest it's a compiler-only ordering constraint. >>> But that's fine for our purposes. >>> >>> I just assumed that for now we probably don't want to make such a >>> radical move to C++11, right? Since it was deprecation or C++11 I >>> intentionally used _ReadWriteBarrier anyway even though it is >>> deprecated. Is this a problem? >>> >>> When we need to switch, I believe we will be forced to use C++11 on >>> windows whether we like it or not. It has std::atomic_signal_fence which >>> should work as a drop-in replacement for _ReadWriteBarrier AFAIK. But >>> then again, we might as well just map all calls to std::atomic if we >>> gotta use C++11 anyway... >> Thank you. Looks like an area we will need to follow-up on. >> The C++ documentation says atomic_signal_fence just does atomic reordering. >> The Visual Studio 2012 documentation is not clear on whether it also adds hardware fences. >> >> So - go ahead and leave this as is and we will need to switch later. >>> >>>> So - do you have plans to do additional changes to the OrderAccess logic? Beyond getting rid of the obsolete entries >>>> when all platforms are ok with it? >>> >>> My biggest concern was correctness and I felt it really had to be done. >>> I use OrderAccess for my own GC code a lot, and needed to tame it a bit >>> to work, and thought I might as well contribute the fixes too. ;) >> >> Thank you. >>> >>> Having looked into the code a bit I know there is still room >>> improvements in places if you would like me to look into it. Some examples: >>> >>> >>> >>> 1) x86_64 windows - I suspect this can be improved a /lot/. It seems >>> like compilers were broken when the code was written at the very >>> transition point to 64 bit. I believe this can be optimized to use >>> compiler support I expect is in place today. >> Yes. >>> >>> 2) x86 on solaris: solaris studio was also crippled in the past with no >>> inline assembly. I believe these optimizations we see on other platforms >>> could now be ported to solaris as well. >> Yes. yay! >>> >>> 3) _volatile variants of acquire/release/fence/membars: Now we are >>> conservative, taking volatile to non-volatile reordering into account >>> using compiler barriers. If the programmer knows this is not needed >>> since all data published is volatile, maybe it could be good to have >>> variants explicitly stating it won't be necessary. >> Yes. >>> >>> 4) Joining more store(); release(); pairs to store_release() since some >>> platforms like ARM can then use stlr instead of full dmb fence which >>> seems like a good thing in general anyway. >>> >>> All previous suggestions revolve around performance (and I don't know >>> how much we need it). But could also do other things. >>> >>> Testing: >>> >>> 5) Testing code: it is possible using some light template >>> metaprogramming to test if the expected specializations of OrderAccess >>> are indeed used, a bit like @Override in Java - asserting that the >>> generalized behaviour is indeed specialized as expected for all types we >>> expect them to be specialized for. >>> >>> Further refactoring: >>> >>> 6) Forwarding all atomic memory accesses to Atomic:: since it's really a >>> separate concern. Atomic:: should know how to make atomic accesses for >>> types used by OrderAccess, and OrderAccess should in shared code just >>> forward it. Currently Atomic supports all stores but only load of jlong, >>> making assumptions the rest can use volatile only - an assumption I'm >>> not willing to make and spread around in the JVM. >> I share your concerns. >>> >>> >>> >>> The main problem though is that OrderAcces changes are often inherently >>> platform specific, and I have very limited access as an outsider to the >>> platforms. >>> This time, Jesper has been very kind to me, running JPRT for me which >>> made these changes possible, and I'm very happy about that. But maybe I >>> should do less platform specific things when I can't run JPRT. I don't >>> want to bother people with compiling code for me too much, especially >>> not if experimenting with what new compiler features have been added >>> over the years. :) >>> >>>> Looks like we have a couple of follow-up exercises: >>>> 1) check our is_MP usage to ensure we get the compiler_barriers in both paths if we are not using volatile declarations for >>>> all compiler ordering >>>> 2) try applying these templates to any other platforms to see how well they work for us as maintainers >>>> 3) figure out why we use StubRoutines::fence on amd64 Windows but on linux we just use lock; addl 0(sp), MSVC limitation? >>> >>> Yes I could volunteer to do 2 (only open variants of course) and 3 if >>> anyone would be kind to run JPRT for me and/or provide me with machines >>> I can try things out on (which I suspect is impossible?). >> I wasn't asking you to do this work - I was suggesting work we should do. No worries. >>> >>>> I did not review ppc, zero, arm. >>> >>> I should mention Zero changes were reviewed by Severin Gehwolf in the >>> zero-dev list. He did not have any problem with my changes. >> Glad to hear that. Thank you. >>> >>> Thanks for the review Karen! :) >>> >>> /Erik >> >> >> thanks, >> Karen >>> >>>> >>>> thanks! >>>> Karen >>>> On Jan 22, 2015, at 8:19 PM, Erik ?sterlund wrote: >>>> >>>>> Hi all, >>>>> >>>>> == Summary of Changes == >>>>> >>>>> This changeset fixes issues in OrderAccess on multiple levels from the >>>>> memory model semantics to compiler reorderings, to addressing >>>>> maintainability/portability issues which (almost) had to be fixed in >>>>> order to fix the correctness issues. It is the result of discussions >>>>> found in the previous "OrderAccess Refactoring" thread: >>>>> http://openjdk.5641.n7.nabble.com/OrderAccess-Refactoring-td212050.html >>>>> >>>>> Bug ID: >>>>> https://bugs.openjdk.java.net/browse/JDK-7143664 >>>>> (updated to reflect these related changes) >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~dholmes/7143664/webrev/ >>>>> >>>>> Before I describe more I would like to give special thanks to David >>>>> Holmes for long discussions leading up to the currently proposed >>>>> changes. I would also like to thank Jesper Wilhelmsson for helping me >>>>> run my changes through JPRT. >>>>> >>>>> == Motivation == >>>>> >>>>> This change directly fixes a reported OrderAccess bug due to compiler >>>>> reorderings which is still a vulnerability on almost all TSO platforms: >>>>> https://bugs.openjdk.java.net/browse/JDK-806196 >>>>> >>>>> And directly fixes confusions like release_store() != release() store() >>>>> due to memory model issues previously described in this bug ID. >>>>> >>>>> At the same time it provides clearer design with separation of concerns >>>>> and generalization/specialization, removing a whole bunch of platform >>>>> specific code which could be generalized. The platform specific files >>>>> now only have a few LoC requirements (~7) to conform to the memory model >>>>> by specifying what the stand alone barriers do. Then optionally >>>>> optimizations to the general approach are possible if platforms support >>>>> it. This also makes it much easier to port to new platforms. >>>>> >>>>> == Memory Model == >>>>> >>>>> The current definitions of acquire/release semantics are a bit fishy >>>>> leading to problems previously described in the bug ID (release_store() >>>>> != release() store()) and some other correctness issues. It has >>>>> therefore been replaced with a new model. I would like to thank David >>>>> Holmes for the long discussions leading up to the newly proposed model. >>>>> >>>>> The new model is formally defined like this: >>>>> >>>>> // T1: access_shared_data >>>>> // T1: ]release >>>>> // T1: (...) >>>>> // T1: store(X) >>>>> // >>>>> // T2: load(X) >>>>> // T2: (...) >>>>> // T2: acquire[ >>>>> // T2: access_shared_data >>>>> // >>>>> // It is guaranteed that if T2: load(X) synchronizes with (observes the >>>>> // value written by) T1: store(X), then the memory accesses before the >>>>> // T1: ]release happen before the memory accesses after the T2: acquire[. >>>>> >>>>> The orderAccess.hpp file and bug ID also has a few additional >>>>> explanations making it more intuitive to the user when to use >>>>> acquire/release and the resemblance to TSO abstract machines. Big thanks >>>>> goes to David Holmes for discussing the memory model with me, which >>>>> helped a lot in deriving it. >>>>> >>>>> Now it holds that release() store() == release_store(), and the other >>>>> correctness issues are fixed as well. >>>>> >>>>> The new model is also closer to C++11 definitions which could give us >>>>> more relaxed compiler reordering constraints in the future when compiler >>>>> support for C++11 is there and ready. >>>>> >>>>> == Reliance on C++ Volatile Semantics == >>>>> >>>>> The C++ standard section 1.9 "Program Execution" is very vague about >>>>> what the keyword volatile can actually do for us. It gives clear >>>>> constraints in terms of volatile-volatile accesses but says little about >>>>> nonvolatile-volatile accesses. Yet the current implementation heavily >>>>> relies upon volatile to in terms of compiler reordering. But GCC >>>>> explicitly declares that volatiles and non-volatiles may reorder freely >>>>> ( https://gcc.gnu.org/onlinedocs/gcc/Volatiles.html ). The only compiler >>>>> known to explicitly provide the wanted semantics with volatile is MSVC >>>>> 2010 for windows ( >>>>> https://msdn.microsoft.com/en-us/library/12a04hfd(v=vs.100).aspx ). >>>>> Compilers not giving explicit guarantees, must be considered unsafe and >>>>> revert to conservative behaviour. >>>>> >>>>> This was brought to attention after causing bugs, but was only fixed for >>>>> x86 linux. This is a fundamental issue inherent to all TSO platforms >>>>> except windows, and has to be fixed on all of them. >>>>> >>>>> Several barriers are unsafe to use because they lack compiler reordering >>>>> constraints (e.g. fence and acquire on linux_SPARC). For TSO platforms >>>>> they are typically implemented using dummy loads and stores. This seems >>>>> to be another old volatile reliance that I fixed. These barriers >>>>> sometimes have omitted compiler barriers (which is what we really want). >>>>> This seems to be another example on incorrect reliance on the volatile >>>>> semantics to help us. Therefore dummy loads/stores have been replaced >>>>> with compiler barriers on TSO platforms. >>>>> >>>>> It is also worth noting that compilers like sun studio did previously >>>>> not support inline asm syntax. Therefore, barriers were implemented in >>>>> .il-files. However, using them does not give explicit compiler >>>>> constraints for reordering AFAIK. Therefore, they have been >>>>> reimplemented using inline asm with explicit compiler reordering >>>>> constraints, as even sun (solaris?) studio now supports this. >>>>> >>>>> The windows variants have added a windows-style _ReadWriteBarrier() >>>>> compiler barrier similarly. >>>>> >>>>> == Strange Hardware Reorderings == >>>>> >>>>> Fixed a weird inconsistency where acquire, loadstore and loadlaod would >>>>> use isync instead of lwsync for PPC on linux_zero, but not in any other >>>>> PPC platform in the repo. I assumed this is wrong and changed it to >>>>> lwsync instead. >>>>> >>>>> == Code Redundancy and Refactoring == >>>>> >>>>> The OrderAccess code looks like it has been developed over a long period >>>>> of time, with small incremental changes. This seems to have led to a lot >>>>> of code duplication over time. For example, store_fence variants are not >>>>> referenced from anywhere, yet contribute to a lot of the code base and a >>>>> lot of awkwardness (such as being the one only exception not using >>>>> volatiles for some reason). Moreover, store_fence is not used anywhere >>>>> in hotspot because it is not a good fit for either the acquire/release >>>>> semantics or the Java volatile semantics, leaving a big question mark on >>>>> when it should ever be used. I took the liberty of removing it. >>>>> >>>>> Another redundancy issue is that most of the semantics is exactly the >>>>> same for all platforms, yet all that default boilerplate such as how to >>>>> make atomic accesses, where acquire/release is supposed to be placed >>>>> w.r.t. the memory access, what the different barriers should do etc. is >>>>> copied in redundantly for each os_cpu and each type of memory access for >>>>> each os_cpu. This makes it extremely painful 1) to understand what >>>>> actually defines a certain platform compared to the defaults and 2) to >>>>> correct bugs like those discovered here 3) prevent silly mistakes and >>>>> bugs, by simply having a lot less code defining the behaviour of >>>>> OrderAccess that could go wrong. >>>>> >>>>> A new architecture/design for OrderAccess is proposed, using a >>>>> generalization/specialization approach. >>>>> >>>>> A general implementation in /share/ defines how things work and splits >>>>> into different concerns: 1) how to make an atomic memory access, 2) >>>>> where to but barriers w.r.t. the memory access for things like >>>>> load_acquire, release_store and release_store_fence, 3) how these >>>>> barriers are defined. >>>>> >>>>> This allows a clear split between what is required for following the >>>>> specifications, and optimizations, which become much more readable and >>>>> only optimizations need to be reviewed in depth as the defaults can >>>>> always be trusted given correct standalone barriers. >>>>> >>>>> The only thing a platform is required to specify, is what an >>>>> implementation of acquire(), release() and fence() should do. If they >>>>> are implemented properly, everything in OrderAccess is guaranteed to >>>>> work according to specification using the generalized code. This makes >>>>> it very easy to support new ports. ALL the other code in the os_cpu >>>>> files is used /only/ for optimization purposes offered for specific >>>>> configurations. >>>>> >>>>> However, it is highly customizable so that specific platform can perform >>>>> any desired optimizations. For instance this load_acquire on PPC is >>>>> optimized: >>>>> >>>>> template<> inline jbyte OrderAccess::specialized_load_acquire >>>>> (volatile jbyte* p) { register jbyte t = load(p); >>>>> inlasm_acquire_reg(t); return t; } >>>>> >>>>> This overrides the whole load_acquire implementation to do something >>>>> custom. Platforms like x86 extensively use this for joined fencing >>>>> variants to optimize. >>>>> >>>>> The default implementation of load_acquire() will make an atomic load() >>>>> followed by acquire() since the semantics is generalized. The >>>>> generalized semantics are defined using inlined postfix/prefix calls >>>>> after/before the atomic access, as defined here: >>>>> >>>>> template<> inline void ScopedFenceGeneral::postfix() { >>>>> OrderAccess::acquire(); } >>>>> template<> inline void ScopedFenceGeneral::prefix() { >>>>> OrderAccess::release(); } >>>>> template<> inline void ScopedFenceGeneral::prefix() { >>>>> OrderAccess::release(); } >>>>> template<> inline void ScopedFenceGeneral::postfix() { >>>>> OrderAccess::fence(); } >>>>> >>>>> For platforms that simply wish to override what e.g. acquire means for a >>>>> joined ordered memory access in general, as different to calling stand >>>>> alone acquire(), the semantics can be easily overridden for a platform >>>>> such as windows like on windows: >>>>> >>>>> template<> inline void ScopedFence::postfix() { } >>>>> template<> inline void ScopedFence::prefix() { } >>>>> template<> inline void ScopedFence::prefix() { } >>>>> template<> inline void ScopedFence::postfix() { >>>>> OrderAccess::fence(); } >>>>> >>>>> In this example, since Windows (now) has a compiler barrier for acquire, >>>>> but does not need it for joined accesses since volatile has stronger >>>>> guarantees on windows, this is enough to specialize that for joined >>>>> memory accesses, no extra protection is needed. >>>>> >>>>> == Backward Compatibility and Transitioning == >>>>> >>>>> Since the newly proposed code is structured differently to before, a >>>>> #define was added for backward compatibility so that external >>>>> repositories not adhering to this new architecture do not break. >>>>> Furthermore, store_release was declared private and marked as >>>>> deprecated. This allows for a smooth transition into the new style of >>>>> OrderAccess. When the full transition is made in all known repos, the >>>>> #define and store_fence may be safely removed, eventually. >>>>> >>>>> == Documentation == >>>>> >>>>> The documentation seems old and outdated, describing how it works on >>>>> SPARC RMO and IA64, which are nowhere to be found in the repository. It >>>>> also describes things about C++ volatiles which cannot be relied upon. >>>>> The documentation has been cleaned up to match the current state of the >>>>> implementation better, with architectures actually found in the repository. >>>>> >>>>> == Testing == >>>>> >>>>> JPRT. Big thanks to Jesper Wilhelmsson for helping me test these changes. >>>>> Ran some DaCapo benchmarks (I know okay :p) for performance regression >>>>> and there was no perceivable difference. >>>>> >>>>> Looking forward to feedback on this, and hope to get some reviews. :) >>>>> >>>>> Thanks, >>>>> Erik >>>> >>>> >> > From goetz.lindenmaier at sap.com Wed Feb 25 10:52:23 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 25 Feb 2015 10:52:23 +0000 Subject: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CF967DF@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CF9615F@DEWDFEMB12A.global.corp.sap> <70B02DBE-E246-45F9-89C7-898881B0C69A@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF96468@DEWDFEMB12A.global.corp.sap> <65A32AAF-F514-4E10-AF4A-DA04F41F57BF@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF967DF@DEWDFEMB12A.global.corp.sap> Message-ID: <4295855A5C1DE049A61835A1887419CC2CF99127@DEWDFEMB12A.global.corp.sap> Hi Kim, Do you have any more comments on this? Best regards, Goetz. -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz Sent: Donnerstag, 19. Februar 2015 11:35 To: Kim Barrett Cc: hotspot-dev Source Developers Subject: RE: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. Hi Kim, os_linux.cpp: - I adapted the type to ptrdiff_t. - I implemented error handling as where current directory can not be read. g1/concurrentMark.cpp You're right, that #define is not nice. And yes, the code you propose is better. But here I don't feel like changing it, as I don't know what was intended by the code. Is it used at all? Does Oracle have a test that depends on it? Anyways, if the default is 0, it's off per default if somebody enables G1StressConcRegionFreeing, which I also consider a strange behaviour. The code was added with 6977804: G1: remove the zero-filling thread: http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/0fa27f37d4d4 I can't find the review thread in the gc mail archive. There is only the submit: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2011-January/002243.html jvmtiRedefineClasses.cpp Changed to u1 and removed comment. The value never exceeds 255. u1 is used at other places for frame_type, too. So I think it's good to change it to u1. The new webrev is here: http://cr.openjdk.java.net/~goetz/webrevs/8073315-wUnsign/webrev.03/ Thanks for the detailed review! Best regards, Goetz. -----Original Message----- From: Kim Barrett [mailto:kim.barrett at oracle.com] Sent: Donnerstag, 19. Februar 2015 02:21 To: Lindenmaier, Goetz Cc: hotspot-dev Source Developers Subject: Re: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. On Feb 18, 2015, at 5:53 AM, Lindenmaier, Goetz wrote: > > http://cr.openjdk.java.net/~goetz/webrevs/8073315-wUnsign/webrev.02/ I wonder how many of the changes being made here are the result of code that originally used int for some counters, indices, or size values, and was later changed to use an appropriate unsigned type. ------------------------------------------------------------------------------ src/os/linux/vm/os_linux.cpp 3751 size_t top_overlap = requested_addr + (bytes + gap) - base[i]; 3752 if (top_overlap >= 0 && top_overlap < bytes) { => 3751 size_t top_overlap = requested_addr + (bytes + gap) - base[i]; 3752 if (requested_addr + (bytes + gap) >= base[i] && // Check underflow. 3753 top_overlap < bytes) { I believe the real problem here is the type of top_overlap, which should be ptrdiff_t rather than size_t. I *think* that if just that type change was made, that the rest would be fine. Similarly a few lines later for bottom_overlap. ------------------------------------------------------------------------------ src/os/linux/vm/os_linux.cpp 6028 int written; ... 6050 if ((written >= 0) && ((size_t)written < bufferSize) && 6051 (pid_pos == NULL) && (core_pattern[0] != '|')) { The real problem here is the value of "written", which is the result of a call to jio_snprintf, is not being checked for failure. Clearly "written" should be of signed type because of its value, but the other changes here just continue to mask the lack of error checking. ------------------------------------------------------------------------------ src/share/vm/classfile/systemDictionary.cpp 1371 for (uintx it = 0; it < GCExpandToAllocateDelayMillis; it++){} I'll grant you that one as a nice find and deletion. (Although the code is "harmless", since the compiler should optimize it away.) ------------------------------------------------------------------------------ src/share/vm/gc_implementation/g1/concurrentMark.cpp 2173 #ifndef PRODUCT 2174 if (G1StressConcRegionFreeing) { 2175 for (uintx i = 0; i < G1StressConcRegionFreeingDelayMillis; ++i) { 2176 os::sleep(Thread::current(), (jlong) 1, false); 2177 } 2178 } 2179 #endif The #ifndef here is the kind of workaround for the warning that I really dislike. But why isn't this just if (G1StressConcRegionFreeing) { os::sleep(Thread::current(), G1StressConcRegionFreeingDelayMillis, false); } or maybe even "true" for the third argument to sleep, to allow it to be interruptable. ----------------------------------------------------------------------------- src/share/vm/prims/jvmtiRedefineClasses.cpp 2908 if (frame_type >= 0 && frame_type <= 63) { => 2908 if (frame_type <= 63) { There is a comment a few lines back: 2897 // The Linux compiler does not like frame_type to be u1 or u2. It 2898 // issues the following warning for the first if-statement below: 2899 // 2900 // "warning: comparison is always true due to limited range of data type" It looks like someone got that warning and tried to work around it in a different way, without really understanding what was going on. Eliminating the (frame >= 0) expression is ok, but the comment should be eliminated and perhaps consider changing the type for frame_type to u1? I'm less sure about the type change. ------------------------------------------------------------------------------ From magnus.ihse.bursie at oracle.com Wed Feb 25 11:21:28 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 25 Feb 2015 12:21:28 +0100 Subject: RFR: JDK-8072842 Add support for building native JTReg tests In-Reply-To: <31B825DC-DFD2-4EC2-81AD-9BF0FC3364CC@oracle.com> References: <54DA146D.3060904@oracle.com> <54DAB1CE.70506@oracle.com> <54DB0E31.3010201@oracle.com> <54DB1175.6030700@oracle.com> <54DB125D.2070706@oracle.com> <54DB1528.4030708@oracle.com> <324EF37C-3FD2-4B8A-A509-D7315889D8DE@oracle.com> <54DB39C2.5010607@oracle.com> <31B825DC-DFD2-4EC2-81AD-9BF0FC3364CC@oracle.com> Message-ID: <54EDB038.4000502@oracle.com> On 2015-02-11 13:08, Staffan Larsen wrote: > >>>>>>> Okay so if I just cd into hotspot/test and use the Makefile to try >>>>>>> and run some jtreg tests it looks to me that it will define an >>>>>>> invalid -nativepath >>>>>> >>>>>> I'm not sure if that is a supported use case. David or Staffan will >>>>>> have to answer to that. I have not tested that, only the "whole >>>>>> forest" approach. >>>>> >>>>> I?ve never done that. I?m always running all make commands from >>>>> the top >>>>> level. Is there a problem with that? >>>> >>>> I must confess I also haven't done that - though I often run jtreg >>>> directly from there. Other hotspot engineers may use it. If nothing >>>> else it would be a way to test out what you expect JPRT to be running. >>>> >>>> But perhaps we just don't add the -nativepath component if >>>> TESTNATIVE_DIR remains unset? >>> >>> Not adding -nativepath or adding it with an empty path will lead to >>> the same errors I think: tests that need native code will fail. So >>> it does not really matter. >> >> If you add it with an invalid path (won't be empty as the variable is >> only a prefix) then tests that don't need native code may also fail. >> Though I don't know how jtreg responds to a non-existent nativepath. > > You are right. Jtreg validates the that the path is a directory. So > better not to specify it. Ok. I have updated the webrev, so the -nativepath: argument is only specified if we indeed have been given a valid path to the native libraries. The only changes between this and the previous webrev is in hotspot/test/Makefile and jdk/test/Makefile. http://cr.openjdk.java.net/~ihse/JDK-8072842-build-native-jtreg-tests/webrev.02 /Magnus From magnus.ihse.bursie at oracle.com Wed Feb 25 11:43:38 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 25 Feb 2015 12:43:38 +0100 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <54EB3FDB.1060609@oracle.com> References: <54E183B8.5010301@oracle.com> <54E3B144.1090402@oracle.com> <958867570.14123662.1424262805099.JavaMail.zimbra@redhat.com> <1424314925.5112.149.camel@ocdc> <54E55A01.5020700@oracle.com> <54E56503.4090704@oracle.com> <54E65D27.3070107@oracle.com> <1747776645.16967635.1424701004513.JavaMail.zimbra@redhat.com> <54EB3FDB.1060609@oracle.com> Message-ID: <54EDB56A.7010007@oracle.com> On 2015-02-23 15:57, Erik Joelsson wrote: > I think the jdk changes with ppc64le as CPU make sense. Jumping in a bit late in the discussion... I agree with Erik, having ppc64le as CPU seems the right way to go. I'm just wondering if you have checked the makefiles if there are tests for ppc64 elsewhere that will now fail for ppc64le. I noticed that there was one such change in the configure script, but there might be more in the makefiles themselves. /Magnus From erik.helin at oracle.com Wed Feb 25 11:52:05 2015 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 25 Feb 2015 12:52:05 +0100 Subject: CFV: New hotspot Group Member: Igor Ignatyev Message-ID: <20150225115205.GB6837@ehelin.jrpg.bea.com> I hereby nominate Igor Ignatyev to Membership in the hotspot Group. Igor is the technical lead of the HotSpot Compiler SQE group and is a Reviewer in the jdk9 project and a committer in the hsx and jdk8u projects. He has been working actively in the HotSpot project for 2.5 years. Igor is key contributor to the testability of the JIT compilers in HotSpot: he is the author of much of the WhiteBox compiler API and has written many of the additional tests for the JIT compilers. Igor's additional contributions include several product bug fixes, test development for JSR292 and being part of the test stabilization effort. Igor also mentors other engineers from the HotSpot SQE and STT team. Votes are due by March 11, 13:00 CET. Only current Members of the hotspot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list For Lazy Consensus voting instructions, see [2]. Erik Helin [1] http://openjdk.java.net/census [2] http://openjdk.java.net/groups/#member-vote From jesper.wilhelmsson at oracle.com Wed Feb 25 12:29:55 2015 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 25 Feb 2015 13:29:55 +0100 Subject: CFV: New hotspot Group Member: Igor Ignatyev In-Reply-To: <20150225115205.GB6837@ehelin.jrpg.bea.com> References: <20150225115205.GB6837@ehelin.jrpg.bea.com> Message-ID: <54EDC043.9030301@oracle.com> Vote: Yes. /Jesper Erik Helin skrev den 25/2/15 12:52: > I hereby nominate Igor Ignatyev to Membership in the hotspot Group. > > Igor is the technical lead of the HotSpot Compiler SQE group and is a > Reviewer in the jdk9 project and a committer in the hsx and jdk8u > projects. He has been working actively in the HotSpot project for 2.5 > years. > > Igor is key contributor to the testability of the JIT compilers in > HotSpot: he is the author of much of the WhiteBox compiler API and has > written many of the additional tests for the JIT compilers. Igor's > additional contributions include several product bug fixes, test > development for JSR292 and being part of the test stabilization effort. > Igor also mentors other engineers from the HotSpot SQE and STT team. > > Votes are due by March 11, 13:00 CET. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list > > For Lazy Consensus voting instructions, see [2]. > > Erik Helin > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/groups/#member-vote > From bengt.rutisson at oracle.com Wed Feb 25 13:05:51 2015 From: bengt.rutisson at oracle.com (Bengt Rutisson) Date: Wed, 25 Feb 2015 14:05:51 +0100 Subject: CFV: New hotspot Group Member: Igor Ignatyev In-Reply-To: <20150225115205.GB6837@ehelin.jrpg.bea.com> References: <20150225115205.GB6837@ehelin.jrpg.bea.com> Message-ID: <54EDC8AF.4020802@oracle.com> Vote: yes Bengt On 2015-02-25 12:52, Erik Helin wrote: > I hereby nominate Igor Ignatyev to Membership in the hotspot Group. > > Igor is the technical lead of the HotSpot Compiler SQE group and is a > Reviewer in the jdk9 project and a committer in the hsx and jdk8u > projects. He has been working actively in the HotSpot project for 2.5 > years. > > Igor is key contributor to the testability of the JIT compilers in > HotSpot: he is the author of much of the WhiteBox compiler API and has > written many of the additional tests for the JIT compilers. Igor's > additional contributions include several product bug fixes, test > development for JSR292 and being part of the test stabilization effort. > Igor also mentors other engineers from the HotSpot SQE and STT team. > > Votes are due by March 11, 13:00 CET. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list > > For Lazy Consensus voting instructions, see [2]. > > Erik Helin > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/groups/#member-vote From gnu.andrew at redhat.com Wed Feb 25 13:50:25 2015 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 25 Feb 2015 08:50:25 -0500 (EST) Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <54EDB56A.7010007@oracle.com> References: <1424314925.5112.149.camel@ocdc> <54E55A01.5020700@oracle.com> <54E56503.4090704@oracle.com> <54E65D27.3070107@oracle.com> <1747776645.16967635.1424701004513.JavaMail.zimbra@redhat.com> <54EB3FDB.1060609@oracle.com> <54EDB56A.7010007@oracle.com> Message-ID: <1046475406.18554532.1424872225779.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 2015-02-23 15:57, Erik Joelsson wrote: > > I think the jdk changes with ppc64le as CPU make sense. > > Jumping in a bit late in the discussion... > > I agree with Erik, having ppc64le as CPU seems the right way to go. I'm > just wondering if you have checked the makefiles if there are tests for > ppc64 elsewhere that will now fail for ppc64le. I noticed that there was > one such change in the configure script, but there might be more in the > makefiles themselves. > > /Magnus > These are the revised versions of the webrevs: http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/root/ http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/jdk/ http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/hotspot/ (HotSpot is unchanged, dropped the sound changes from JDK) The only other ppc64 block I found is specifically AIX/ppc64 to exclude the serviceability agent: make/gensrc/Gensrc-jdk.jdi.gmk:ifeq (, $(filter $(OPENJDK_TARGET_OS)-$(OPENJDK_TARGET_CPU), aix-ppc64)) make/Import.gmk:ifeq (, $(filter $(OPENJDK_TARGET_OS)-$(OPENJDK_TARGET_CPU), aix-ppc64)) Does AIX support ppc64le? Thanks, -- Andrew :) 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 PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From coleen.phillimore at oracle.com Wed Feb 25 14:31:23 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 25 Feb 2015 09:31:23 -0500 Subject: 2-nd round RFR (M) 8046246: the constantPoolCacheOopDesc::adjust_method_entries() used in RedefineClasses does not scale In-Reply-To: <54ED3A86.1050301@oracle.com> References: <54E57884.8030200@oracle.com> <54E7A7FC.9090709@oracle.com> <54ED3A86.1050301@oracle.com> Message-ID: <54EDDCBB.6070405@oracle.com> On 2/24/15, 9:59 PM, Daniel D. Daugherty wrote: > On 2/20/15 2:32 PM, serguei.spitsyn at oracle.com wrote: >> The hotspot webrev below addresses the Coleen's comments from the >> 1-st review round. >> >> Open hotspot webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.2/ >> > > Thumbs up! > > src/share/vm/oops/instanceKlass.hpp > No comments. > > src/share/vm/oops/instanceKlass.cpp > InstanceKlass::adjust_default_methods() - so you drop the outer level > of for-loop here by switching from parallel old_methods/new_methods > arrays to looping on the target array (default methods) and only > fetching the old_method candidate that's in parallel with the > current default method _and_ only fetching the new method when you > need it. > > So you've squashed a nested for-loop and you're only fetching the > new method when you know you need it. Nicely done. > > src/share/vm/oops/cpCache.hpp > line 482: void adjust_method_entries(InstanceKlass* holder, bool * > trace_name_printed); > Nit - this line (and the previous) one have a space between > 'bool' and '*'. The other pointer params do not. Seems to be > a common format difference in 'bool *' params. :-) > > src/share/vm/oops/cpCache.cpp > No comments. > > src/share/vm/oops/klassVtable.hpp > No comments. > > src/share/vm/oops/klassVtable.cpp > klassVtable::adjust_method_entries() and > klassItable::adjust_method_entries() have similar > loop squashing. Again, nicely done. > > src/share/vm/prims/jvmtiRedefineClasses.cpp > No comments. > > src/share/vm/classfile/defaultMethods.cpp > No comments. > > src/share/vm/oops/constMethod.hpp > Cool way of using a little bit of space to squash > some loops. Surprised Coleen let you have a u2 though :-) I'm pretty sure it was an alignment gap on 64 bits and it needs to be u2. Coleen > > src/share/vm/oops/method.hpp > No comments. > > src/share/vm/oops/method.cpp > No comments. > > Nit - double check copyright updates before you commit. > > Dan > > > > >> Open jdk (new unit test) webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8046246-JVMTI-manymethods.1/ >> >> >> Thanks, >> Serguei >> >> >> On 2/18/15 9:45 PM, serguei.spitsyn at oracle.com wrote: >>> Please, review the fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8046246 >>> >>> >>> Open hotspot webrevs: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/hotspot/8046246-JVMTI-redefscale.1/ >>> >>> >>> Open jdk (new unit test) webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2015/jdk/8046246-JVMTI-manymethods.1/ >>> >>> >>> >>> Summary: >>> >>> This performance/scalability issue in class redefinition was >>> reported by HP and the Enterprise Manager team. >>> The following variants of the adjust_method_entries() functions >>> do not scale: >>> ConstantPoolCache::adjust_method_entries() >>> klassVtable::adjust_method_entries() >>> klassItable::adjust_method_entries() >>> InstanceKlass::adjust_default_methods() >>> >>> The ConstantPoolCache::adjust_method_entries() is the most >>> important. >>> >>> The approach is to use the holder->method_with_idnum() like this: >>> Method* new_method = >>> holder->method_with_idnum(old_method->orig_method_idnum()); >>> if (old_method != new_method) { >>> >>> } >>> >>> New algorithm has effectiveness O(M) instead of original O(M^2), >>> where M is count of methods in the class. >>> The new test (see webrev above) was used to mesure CPU time >>> consumed by the >>> ConstantPoolCache::adjust_method_entries() in both original and >>> new approach. >>> >>> The performance numbers are: >>> >>> --------------------------------------------------------------------------------------- >>> >>> Methods: ------ 1,000 --------------- 10,000 ----------------- >>> 20,000 >>> --------------------------------------------------------------------------------------- >>> >>> Orig: 600,000 nsec (1x) 60,500,000 nsec (~100x) >>> 243,000,000 nsec (~400x) >>> New: 16,000 nsec (1x) 178,000 nsec (~10x) >>> 355,000 nsec (~20x) >>> --------------------------------------------------------------------------------------- >>> >>> >>> >>> >>> Testing: >>> In progress: VM SQE RedefineClasses tests, JTREG >>> java/lang/instrument, com/sun/jdi tests >>> >>> >>> Thanks, >>> Serguei >>> >> > From vladimir.kozlov at oracle.com Wed Feb 25 14:54:23 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 25 Feb 2015 06:54:23 -0800 Subject: CFV: New hotspot Group Member: Igor Ignatyev In-Reply-To: <20150225115205.GB6837@ehelin.jrpg.bea.com> References: <20150225115205.GB6837@ehelin.jrpg.bea.com> Message-ID: <54EDE21F.8000506@oracle.com> Vote: yes On 2/25/15 3:52 AM, Erik Helin wrote: > I hereby nominate Igor Ignatyev to Membership in the hotspot Group. > > Igor is the technical lead of the HotSpot Compiler SQE group and is a > Reviewer in the jdk9 project and a committer in the hsx and jdk8u > projects. He has been working actively in the HotSpot project for 2.5 > years. > > Igor is key contributor to the testability of the JIT compilers in > HotSpot: he is the author of much of the WhiteBox compiler API and has > written many of the additional tests for the JIT compilers. Igor's > additional contributions include several product bug fixes, test > development for JSR292 and being part of the test stabilization effort. > Igor also mentors other engineers from the HotSpot SQE and STT team. > > Votes are due by March 11, 13:00 CET. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list > > For Lazy Consensus voting instructions, see [2]. > > Erik Helin > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/groups/#member-vote > From roland.westrelin at oracle.com Wed Feb 25 15:21:51 2015 From: roland.westrelin at oracle.com (Roland Westrelin) Date: Wed, 25 Feb 2015 16:21:51 +0100 Subject: CFV: New hotspot Group Member: Igor Ignatyev In-Reply-To: <20150225115205.GB6837@ehelin.jrpg.bea.com> References: <20150225115205.GB6837@ehelin.jrpg.bea.com> Message-ID: Vote: Yes. Roland. > On Feb 25, 2015, at 12:52 PM, Erik Helin wrote: > > I hereby nominate Igor Ignatyev to Membership in the hotspot Group. > > Igor is the technical lead of the HotSpot Compiler SQE group and is a > Reviewer in the jdk9 project and a committer in the hsx and jdk8u > projects. He has been working actively in the HotSpot project for 2.5 > years. > > Igor is key contributor to the testability of the JIT compilers in > HotSpot: he is the author of much of the WhiteBox compiler API and has > written many of the additional tests for the JIT compilers. Igor's > additional contributions include several product bug fixes, test > development for JSR292 and being part of the test stabilization effort. > Igor also mentors other engineers from the HotSpot SQE and STT team. > > Votes are due by March 11, 13:00 CET. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list > > For Lazy Consensus voting instructions, see [2]. > > Erik Helin > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/groups/#member-vote From volker.simonis at gmail.com Wed Feb 25 15:25:15 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 25 Feb 2015 16:25:15 +0100 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <1046475406.18554532.1424872225779.JavaMail.zimbra@redhat.com> References: <1424314925.5112.149.camel@ocdc> <54E55A01.5020700@oracle.com> <54E56503.4090704@oracle.com> <54E65D27.3070107@oracle.com> <1747776645.16967635.1424701004513.JavaMail.zimbra@redhat.com> <54EB3FDB.1060609@oracle.com> <54EDB56A.7010007@oracle.com> <1046475406.18554532.1424872225779.JavaMail.zimbra@redhat.com> Message-ID: On Wed, Feb 25, 2015 at 2:50 PM, Andrew Hughes wrote: > ----- Original Message ----- >> On 2015-02-23 15:57, Erik Joelsson wrote: >> > I think the jdk changes with ppc64le as CPU make sense. >> >> Jumping in a bit late in the discussion... >> >> I agree with Erik, having ppc64le as CPU seems the right way to go. I'm >> just wondering if you have checked the makefiles if there are tests for >> ppc64 elsewhere that will now fail for ppc64le. I noticed that there was >> one such change in the configure script, but there might be more in the >> makefiles themselves. >> >> /Magnus >> > > These are the revised versions of the webrevs: > > http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/root/ > http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/jdk/ > http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/hotspot/ > > (HotSpot is unchanged, dropped the sound changes from JDK) > > The only other ppc64 block I found is specifically AIX/ppc64 to exclude > the serviceability agent: > > make/gensrc/Gensrc-jdk.jdi.gmk:ifeq (, $(filter $(OPENJDK_TARGET_OS)-$(OPENJDK_TARGET_CPU), aix-ppc64)) > make/Import.gmk:ifeq (, $(filter $(OPENJDK_TARGET_OS)-$(OPENJDK_TARGET_CPU), aix-ppc64)) > > Does AIX support ppc64le? > To my best knowledge AIX neither supports ppc64le at the moment nor are there any plans to support it in the future. Regards, Volker > Thanks, > -- > Andrew :) > > 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 > > PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) > Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 > From volker.simonis at gmail.com Wed Feb 25 15:27:35 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 25 Feb 2015 16:27:35 +0100 Subject: CFV: New hotspot Group Member: Igor Ignatyev In-Reply-To: <20150225115205.GB6837@ehelin.jrpg.bea.com> References: <20150225115205.GB6837@ehelin.jrpg.bea.com> Message-ID: Vote: Yes On Wed, Feb 25, 2015 at 12:52 PM, Erik Helin wrote: > I hereby nominate Igor Ignatyev to Membership in the hotspot Group. > > Igor is the technical lead of the HotSpot Compiler SQE group and is a > Reviewer in the jdk9 project and a committer in the hsx and jdk8u > projects. He has been working actively in the HotSpot project for 2.5 > years. > > Igor is key contributor to the testability of the JIT compilers in > HotSpot: he is the author of much of the WhiteBox compiler API and has > written many of the additional tests for the JIT compilers. Igor's > additional contributions include several product bug fixes, test > development for JSR292 and being part of the test stabilization effort. > Igor also mentors other engineers from the HotSpot SQE and STT team. > > Votes are due by March 11, 13:00 CET. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list > > For Lazy Consensus voting instructions, see [2]. > > Erik Helin > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/groups/#member-vote From daniel.daugherty at oracle.com Wed Feb 25 15:48:27 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 25 Feb 2015 08:48:27 -0700 Subject: CFV: New hotspot Group Member: Igor Ignatyev In-Reply-To: <20150225115205.GB6837@ehelin.jrpg.bea.com> References: <20150225115205.GB6837@ehelin.jrpg.bea.com> Message-ID: <54EDEECB.30904@oracle.com> Vote: yes Dan On 2/25/15 4:52 AM, Erik Helin wrote: > I hereby nominate Igor Ignatyev to Membership in the hotspot Group. > > Igor is the technical lead of the HotSpot Compiler SQE group and is a > Reviewer in the jdk9 project and a committer in the hsx and jdk8u > projects. He has been working actively in the HotSpot project for 2.5 > years. > > Igor is key contributor to the testability of the JIT compilers in > HotSpot: he is the author of much of the WhiteBox compiler API and has > written many of the additional tests for the JIT compilers. Igor's > additional contributions include several product bug fixes, test > development for JSR292 and being part of the test stabilization effort. > Igor also mentors other engineers from the HotSpot SQE and STT team. > > Votes are due by March 11, 13:00 CET. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list > > For Lazy Consensus voting instructions, see [2]. > > Erik Helin > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/groups/#member-vote > > From george.triantafillou at oracle.com Wed Feb 25 16:40:21 2015 From: george.triantafillou at oracle.com (George Triantafillou) Date: Wed, 25 Feb 2015 11:40:21 -0500 Subject: RFR (L): 8068685 - [TESTBUG] Ensure @library works in jtreg -agentvm mode In-Reply-To: <54ECE2EF.4040805@oracle.com> References: <54ECE2EF.4040805@oracle.com> Message-ID: <54EDFAF5.2030503@oracle.com> Adding hotspot-dev at openjdk.java.net . -George On 2/24/2015 3:45 PM, George Triantafillou wrote: > Please review this fix for JDK-8068685: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8068685 > webrev: http://cr.openjdk.java.net/~gtriantafill/8068685/webrev.00 > > > "@build com.oracle.java.testlibrary.*" was added to all relevant > tests, which resulted in longer test execution times. In order to > offset these longer test execution times and to support running jtreg > in -agentvm mode, the following changes were made: > > test/Makefile: added -agentvm option > > test/testlibrary/com/oracle/java/testlibrary/ProcessTools.java: added > -classpath since -agentvm passes the classpath differently than -othervm > > *Testing shows an 11% speed improvement for JPRT execution of the > hotspot testset, and a 48% speed improvement for > hotspot_runtime*/gc*/compiler*/serviceability* tests.** > > *Note that some tests required the explicit addition of -othervm in > order for the tests to pass. In addition, a number of gc, compiler > and runtime tests were modified with @run so they would run > successfully with -agentvm. Consequently, reviews from members of the > compiler, gc, runtime, and serviceability teams would be very helpful. > > Thanks to Erik Helin for providing a solution for passing classpath > with -agentvm. > > The fix was tested locally on Linux with jtreg and on all platforms > with the JPRT hotspot testset.* > * > Thanks. > > -George > From tdaitx at br.ibm.com Wed Feb 25 16:53:28 2015 From: tdaitx at br.ibm.com (Tiago Sturmer Daitx) Date: Wed, 25 Feb 2015 13:53:28 -0300 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: References: <1424314925.5112.149.camel@ocdc> <54E55A01.5020700@oracle.com> <54E56503.4090704@oracle.com> <54E65D27.3070107@oracle.com> <1747776645.16967635.1424701004513.JavaMail.zimbra@redhat.com> <54EB3FDB.1060609@oracle.com> <54EDB56A.7010007@oracle.com> <1046475406.18554532.1424872225779.JavaMail.zimbra@redhat.com> Message-ID: <1424883208.5112.287.camel@ocdc> I agreed with Volker, to the best of my knowledge AIX is Big Endian only and I know of no plan to change that. Regards, Tiago On Wed, 2015-02-25 at 16:25 +0100, Volker Simonis wrote: > On Wed, Feb 25, 2015 at 2:50 PM, Andrew Hughes wrote: > > ----- Original Message ----- > >> On 2015-02-23 15:57, Erik Joelsson wrote: > >> > I think the jdk changes with ppc64le as CPU make sense. > >> > >> Jumping in a bit late in the discussion... > >> > >> I agree with Erik, having ppc64le as CPU seems the right way to go. I'm > >> just wondering if you have checked the makefiles if there are tests for > >> ppc64 elsewhere that will now fail for ppc64le. I noticed that there was > >> one such change in the configure script, but there might be more in the > >> makefiles themselves. > >> > >> /Magnus > >> > > > > These are the revised versions of the webrevs: > > > > http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/root/ > > http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/jdk/ > > http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/hotspot/ > > > > (HotSpot is unchanged, dropped the sound changes from JDK) > > > > The only other ppc64 block I found is specifically AIX/ppc64 to exclude > > the serviceability agent: > > > > make/gensrc/Gensrc-jdk.jdi.gmk:ifeq (, $(filter $(OPENJDK_TARGET_OS)-$(OPENJDK_TARGET_CPU), aix-ppc64)) > > make/Import.gmk:ifeq (, $(filter $(OPENJDK_TARGET_OS)-$(OPENJDK_TARGET_CPU), aix-ppc64)) > > > > Does AIX support ppc64le? > > > > To my best knowledge AIX neither supports ppc64le at the moment nor > are there any plans to support it in the future. > > Regards, > Volker > > > Thanks, > > -- > > Andrew :) > > > > 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 > > > > PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) > > Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 > > > From gnu.andrew at redhat.com Wed Feb 25 16:57:05 2015 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 25 Feb 2015 11:57:05 -0500 (EST) Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <1424883208.5112.287.camel@ocdc> References: <54E65D27.3070107@oracle.com> <1747776645.16967635.1424701004513.JavaMail.zimbra@redhat.com> <54EB3FDB.1060609@oracle.com> <54EDB56A.7010007@oracle.com> <1046475406.18554532.1424872225779.JavaMail.zimbra@redhat.com> <1424883208.5112.287.camel@ocdc> Message-ID: <1739722263.18761313.1424883425179.JavaMail.zimbra@redhat.com> ----- Original Message ----- > I agreed with Volker, to the best of my knowledge AIX is Big Endian only > and I know of no plan to change that. > > Regards, > Tiago > > On Wed, 2015-02-25 at 16:25 +0100, Volker Simonis wrote: > > On Wed, Feb 25, 2015 at 2:50 PM, Andrew Hughes > > wrote: > > > ----- Original Message ----- > > >> On 2015-02-23 15:57, Erik Joelsson wrote: > > >> > I think the jdk changes with ppc64le as CPU make sense. > > >> > > >> Jumping in a bit late in the discussion... > > >> > > >> I agree with Erik, having ppc64le as CPU seems the right way to go. I'm > > >> just wondering if you have checked the makefiles if there are tests for > > >> ppc64 elsewhere that will now fail for ppc64le. I noticed that there was > > >> one such change in the configure script, but there might be more in the > > >> makefiles themselves. > > >> > > >> /Magnus > > >> > > > > > > These are the revised versions of the webrevs: > > > > > > http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/root/ > > > http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/jdk/ > > > http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/hotspot/ > > > > > > (HotSpot is unchanged, dropped the sound changes from JDK) > > > > > > The only other ppc64 block I found is specifically AIX/ppc64 to exclude > > > the serviceability agent: > > > > > > make/gensrc/Gensrc-jdk.jdi.gmk:ifeq (, $(filter > > > $(OPENJDK_TARGET_OS)-$(OPENJDK_TARGET_CPU), aix-ppc64)) > > > make/Import.gmk:ifeq (, $(filter > > > $(OPENJDK_TARGET_OS)-$(OPENJDK_TARGET_CPU), aix-ppc64)) > > > > > > Does AIX support ppc64le? > > > > > > > To my best knowledge AIX neither supports ppc64le at the moment nor > > are there any plans to support it in the future. > > > > Regards, > > Volker > > > > > Thanks, > > > -- > > > Andrew :) > > > > > > 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 > > > > > > PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) > > > Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 > > > > > > > > Thanks, that was my assumption. I did wonder if the lack of SA was AIX rather than AIX+PPC-specific and whether we could just drop the arch test altogether... But if someone does start building ppc64le+AIX, they'd find this issue straight away anyway. Ok if I push the jdk and root parts then? I think someone on the Oracle HS team (David?) needs to push the HotSpot bit. Thanks, -- Andrew :) 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 PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From kim.barrett at oracle.com Wed Feb 25 20:35:59 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 25 Feb 2015 15:35:59 -0500 Subject: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CF99127@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CF9615F@DEWDFEMB12A.global.corp.sap> <70B02DBE-E246-45F9-89C7-898881B0C69A@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF96468@DEWDFEMB12A.global.corp.sap> <65A32AAF-F514-4E10-AF4A-DA04F41F57BF@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF967DF@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CF99127@DEWDFEMB12A.global.corp.sap> Message-ID: On Feb 25, 2015, at 5:52 AM, Lindenmaier, Goetz wrote: > > Hi Kim, > > Do you have any more comments on this? Sorry for the delay. I do, but am swamped with other things just now. I hope to get back to this for real in the next couple of days. Short answer is that I?m fine with most of the changes, except the warning enable. However, it appears the relevant gcc bug was fixed in gcc4.8 (not sure which patch version): https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11856 [Note there are quite a few duplicates of that bug too; roughly 10 in total.] If the warning were enabled conditionally on the gcc version, that would satisfy me. From david.holmes at oracle.com Thu Feb 26 01:09:34 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 26 Feb 2015 11:09:34 +1000 Subject: [8u60] RFR(S): Bulk backports of Zero fixes In-Reply-To: <1424856823.3327.1.camel@redhat.com> References: <1424795406.3440.66.camel@redhat.com> <54ED2EB1.6040104@oracle.com> <1424856823.3327.1.camel@redhat.com> Message-ID: <54EE724E.1060104@oracle.com> All changes pushed to jdk8u-hs-dev/hotspot ready for bulk integration. One patch didn't import directly but it was just a copyright date mismatch that I fixed manually. David On 25/02/2015 7:33 PM, Severin Gehwolf wrote: > On Wed, 2015-02-25 at 12:08 +1000, David Holmes wrote: >> Hi Severin, >> >> On 25/02/2015 2:30 AM, Severin Gehwolf wrote: >>> Hi, >>> >>> Would it be possible to push the following 3 small Zero fixes to JDK 8u >>> dev forest? Patches are the same as for JDK 9 modulo some copyright >>> changes. >>> >>> Original JDK 9 Bugs: >>> https://bugs.openjdk.java.net/browse/JDK-8064815 >>> https://bugs.openjdk.java.net/browse/JDK-8067331 >>> https://bugs.openjdk.java.net/browse/JDK-8067231 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~sgehwolf/webrevs/zero-fixes-jdk8u/ >>> >>> JDK-8064815: >>> src/cpu/zero/vm/stack_zero.cpp >>> src/cpu/zero/vm/stack_zero.inline.hpp >>> >>> JDK-8067331: >>> src/os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp >>> src/os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp >>> >>> JDK-8067231: >>> src/share/vm/interpreter/interpreterRuntime.cpp >>> >>> Without those fixes a checkout of jdk8u doesn't even compile >>> (--with-jvm-variants=zero). With them Zero is able to build itself on >>> x86_64 and ppc64. >>> >>> I'd need a sponsor in order to get those fixes pushed. >> >> I can do this for you. There's only one non-zero file touched. > > Thank you, David! Please let me know if there is anything more you need > from me. > > Cheers, > Severin > >> David >> >> >>> Thanks, >>> Severin >>> > > > From david.holmes at oracle.com Thu Feb 26 01:15:29 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 26 Feb 2015 11:15:29 +1000 Subject: CFV: New hotspot Group Member: Igor Ignatyev In-Reply-To: <20150225115205.GB6837@ehelin.jrpg.bea.com> References: <20150225115205.GB6837@ehelin.jrpg.bea.com> Message-ID: <54EE73B1.20104@oracle.com> Vote: yes David On 25/02/2015 9:52 PM, Erik Helin wrote: > I hereby nominate Igor Ignatyev to Membership in the hotspot Group. > > Igor is the technical lead of the HotSpot Compiler SQE group and is a > Reviewer in the jdk9 project and a committer in the hsx and jdk8u > projects. He has been working actively in the HotSpot project for 2.5 > years. > > Igor is key contributor to the testability of the JIT compilers in > HotSpot: he is the author of much of the WhiteBox compiler API and has > written many of the additional tests for the JIT compilers. Igor's > additional contributions include several product bug fixes, test > development for JSR292 and being part of the test stabilization effort. > Igor also mentors other engineers from the HotSpot SQE and STT team. > > Votes are due by March 11, 13:00 CET. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list > > For Lazy Consensus voting instructions, see [2]. > > Erik Helin > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/groups/#member-vote > From john.r.rose at oracle.com Thu Feb 26 01:45:40 2015 From: john.r.rose at oracle.com (John Rose) Date: Wed, 25 Feb 2015 17:45:40 -0800 Subject: CFV: New hotspot Group Member: Igor Ignatyev In-Reply-To: <20150225115205.GB6837@ehelin.jrpg.bea.com> References: <20150225115205.GB6837@ehelin.jrpg.bea.com> Message-ID: <17F89F55-4877-4FE1-9E28-40D9BE42EE38@oracle.com> Vote: yes (emphatically) From karen.kinnear at oracle.com Thu Feb 26 01:47:00 2015 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 25 Feb 2015 20:47:00 -0500 Subject: CFV: New hotspot Group Member: Igor Ignatyev In-Reply-To: <54EDC043.9030301@oracle.com> References: <20150225115205.GB6837@ehelin.jrpg.bea.com> <54EDC043.9030301@oracle.com> Message-ID: <34A0D1C7-35C8-482E-BC5C-EB31F8C2F55F@oracle.com> Vote: Yes Karen > > Erik Helin skrev den 25/2/15 12:52: >> I hereby nominate Igor Ignatyev to Membership in the hotspot Group. >> >> Igor is the technical lead of the HotSpot Compiler SQE group and is a >> Reviewer in the jdk9 project and a committer in the hsx and jdk8u >> projects. He has been working actively in the HotSpot project for 2.5 >> years. >> >> Igor is key contributor to the testability of the JIT compilers in >> HotSpot: he is the author of much of the WhiteBox compiler API and has >> written many of the additional tests for the JIT compilers. Igor's >> additional contributions include several product bug fixes, test >> development for JSR292 and being part of the test stabilization effort. >> Igor also mentors other engineers from the HotSpot SQE and STT team. >> >> Votes are due by March 11, 13:00 CET. >> >> Only current Members of the hotspot Group [1] are eligible to vote on >> this nomination. Votes must be cast in the open by replying to this >> mailing list >> >> For Lazy Consensus voting instructions, see [2]. >> >> Erik Helin >> >> [1] http://openjdk.java.net/census >> [2] http://openjdk.java.net/groups/#member-vote >> From coleen.phillimore at oracle.com Thu Feb 26 01:57:56 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 25 Feb 2015 20:57:56 -0500 Subject: CFV: New hotspot Group Member: Igor Ignatyev In-Reply-To: <20150225115205.GB6837@ehelin.jrpg.bea.com> References: <20150225115205.GB6837@ehelin.jrpg.bea.com> Message-ID: <54EE7DA4.7020409@oracle.com> Vote: yes On 2/25/15, 6:52 AM, Erik Helin wrote: > I hereby nominate Igor Ignatyev to Membership in the hotspot Group. > > Igor is the technical lead of the HotSpot Compiler SQE group and is a > Reviewer in the jdk9 project and a committer in the hsx and jdk8u > projects. He has been working actively in the HotSpot project for 2.5 > years. > > Igor is key contributor to the testability of the JIT compilers in > HotSpot: he is the author of much of the WhiteBox compiler API and has > written many of the additional tests for the JIT compilers. Igor's > additional contributions include several product bug fixes, test > development for JSR292 and being part of the test stabilization effort. > Igor also mentors other engineers from the HotSpot SQE and STT team. > > Votes are due by March 11, 13:00 CET. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list > > For Lazy Consensus voting instructions, see [2]. > > Erik Helin > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/groups/#member-vote From david.holmes at oracle.com Thu Feb 26 02:16:23 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 26 Feb 2015 12:16:23 +1000 Subject: RFR (L): 8068685 - [TESTBUG] Ensure @library works in jtreg -agentvm mode In-Reply-To: <54EDD15F.9030506@oracle.com> References: <54ECE2EF.4040805@oracle.com> <54ED55C8.9030602@oracle.com> <54EDD15F.9030506@oracle.com> Message-ID: <54EE81F7.6050608@oracle.com> Hi George, On 25/02/2015 11:42 PM, George Triantafillou wrote: > Hi David, > > Thanks for your review. Comments inline: > > On 2/24/2015 11:55 PM, David Holmes wrote: >> On 25/02/2015 6:45 AM, George Triantafillou wrote: >>> Please review this fix for JDK-8068685: >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8068685 >>> webrev: http://cr.openjdk.java.net/~gtriantafill/8068685/webrev.00 >>> >>> >>> "@build com.oracle.java.testlibrary.*" was added to all relevant tests, >> >> I thought we had an RFE open against jtreg to avoid the need to do >> this, but it seems I was mistaken. :( >> >> Most of the additions to @build seem okay. A few minor issues: >> >> --- old/test/compiler/whitebox/ForceNMethodSweepTest.java 2015-02-24 >> 10:31:03.991071066 -0800 >> +++ new/test/compiler/whitebox/ForceNMethodSweepTest.java 2015-02-24 >> 10:31:03.617052982 -0800 >> @@ -35,6 +35,9 @@ >> * @test >> * @bug 8059624 8064669 >> * @library /testlibrary /../../test/lib >> + * @build com.oracle.java.testlibrary.* ForceNMethodSweepTest >> + * @ignore 8066998 >> + * @library /testlibrary /../../test/lib >> * @build ForceNMethodSweepTest >> >> The second @library shouldn't have been added. > Good catch, thanks. Changed. > >> >> --- old/test/gc/g1/TestStringSymbolTableStats.java 2015-02-24 >> 10:32:28.209143019 -0800 >> +++ new/test/gc/g1/TestStringSymbolTableStats.java 2015-02-24 >> 10:32:27.855125901 -0800 >> @@ -22,11 +22,13 @@ >> */ >> >> /* >> - * @test TestStringSymbolTableStats.java >> + * @test TestStringSymbolTableStats >> >> Why did you change the @test? I see a lot of unchanged @test foo.java. > According to the jtreg tag spec > http://openjdk.java.net/jtreg/tag-spec.html, either way is correct. The > only tests that were considered for this change included "@library > /testlibrary", so I changed this one for consistency with other tests > that I've written. I'll change it back if it's a concern. No big deal but caused confusion when reviewing. >>> which resulted in longer test execution times. In order to offset these >>> longer test execution times and to support running jtreg in -agentvm >>> mode, the following changes were made: >>> >>> test/Makefile: added -agentvm option >> >> I'm unclear exactly what this buys us - do we just save on the startup >> costs of new vms running jtreg? I thought the default was samevm anyway? >> >> Also does this mean that all VMs will share a single copy of the >> testlibrary or will we still have a copy per test that gets built each >> time? > The jtreg command help http://openjdk.java.net/jtreg/command-help.html > doc states: > > -agentvm "Run tests using a pool of reusable JVMs." > -samevm "If possible, run each test in the same JVM as the JavaTest" > > I'm not really sure how samevm decides "if possible", but the intent of > this change was to explicitly add "@build com.oracle.java.testlibrary.*" > to relevant jtreg runtime tests without increasing test execution > times. The analysis below shows decreased test execution times using > agentvm. Yes but I'd like to understand why that is the case, and whether we are still being inefficient in this even if better than the initial attempt. It is very unclear to me how the addition of agentvm is influencing the building of the testlibrary. >> >>> test/testlibrary/com/oracle/java/testlibrary/ProcessTools.java: added >>> -classpath since -agentvm passes the classpath differently than -othervm >>> >>> *Testing shows an 11% speed improvement for JPRT execution of the >>> hotspot testset, and a 48% speed improvement for >>> hotspot_runtime*/gc*/compiler*/serviceability* tests.** >>> >>> *Note that some tests required the explicit addition of -othervm in >>> order for the tests to pass. In addition, a number of gc, compiler and >>> runtime tests were modified with @run so they would run successfully >>> with -agentvm. Consequently, reviews from members of the compiler, gc, >>> runtime, and serviceability teams would be very helpful. >> >> I'm unclear about the need for some of the othervm changes. I would >> only expect othervm to be needed if passing -XX options via @run ?? > I added @run to some tests, and some of them failed with -agentvm until > I added -othervm. This is a puzzle - perhaps a jtreg bug. Without the @build for the testlibrary you can use -agentvm without a problem based on a few experiments I did. Once you add the @build you then also have to add @run, but the simple: @run test fails with e.g.: test result: Error. Bad action for script: CdsSameObjectAlignment However it suffices to add "main" in the @run: @run main CdsDifferentObjectAlignment without needing to add /othervm Cheers, David > -George >> >> Thanks, >> David >> >>> Thanks to Erik Helin for providing a solution for passing classpath with >>> -agentvm. >>> >>> The fix was tested locally on Linux with jtreg and on all platforms with >>> the JPRT hotspot testset.* >>> * >>> Thanks. >>> >>> -George >>> > From david.holmes at oracle.com Thu Feb 26 02:31:36 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 26 Feb 2015 12:31:36 +1000 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <1739722263.18761313.1424883425179.JavaMail.zimbra@redhat.com> References: <54E65D27.3070107@oracle.com> <1747776645.16967635.1424701004513.JavaMail.zimbra@redhat.com> <54EB3FDB.1060609@oracle.com> <54EDB56A.7010007@oracle.com> <1046475406.18554532.1424872225779.JavaMail.zimbra@redhat.com> <1424883208.5112.287.camel@ocdc> <1739722263.18761313.1424883425179.JavaMail.zimbra@redhat.com> Message-ID: <54EE8588.8060209@oracle.com> On 26/02/2015 2:57 AM, Andrew Hughes wrote: > ----- Original Message ----- >> I agreed with Volker, to the best of my knowledge AIX is Big Endian only >> and I know of no plan to change that. >> >> Regards, >> Tiago >> >> On Wed, 2015-02-25 at 16:25 +0100, Volker Simonis wrote: >>> On Wed, Feb 25, 2015 at 2:50 PM, Andrew Hughes >>> wrote: >>>> ----- Original Message ----- >>>>> On 2015-02-23 15:57, Erik Joelsson wrote: >>>>>> I think the jdk changes with ppc64le as CPU make sense. >>>>> >>>>> Jumping in a bit late in the discussion... >>>>> >>>>> I agree with Erik, having ppc64le as CPU seems the right way to go. I'm >>>>> just wondering if you have checked the makefiles if there are tests for >>>>> ppc64 elsewhere that will now fail for ppc64le. I noticed that there was >>>>> one such change in the configure script, but there might be more in the >>>>> makefiles themselves. >>>>> >>>>> /Magnus >>>>> >>>> >>>> These are the revised versions of the webrevs: >>>> >>>> http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/root/ >>>> http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/jdk/ >>>> http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/hotspot/ >>>> >>>> (HotSpot is unchanged, dropped the sound changes from JDK) >>>> >>>> The only other ppc64 block I found is specifically AIX/ppc64 to exclude >>>> the serviceability agent: >>>> >>>> make/gensrc/Gensrc-jdk.jdi.gmk:ifeq (, $(filter >>>> $(OPENJDK_TARGET_OS)-$(OPENJDK_TARGET_CPU), aix-ppc64)) >>>> make/Import.gmk:ifeq (, $(filter >>>> $(OPENJDK_TARGET_OS)-$(OPENJDK_TARGET_CPU), aix-ppc64)) >>>> >>>> Does AIX support ppc64le? >>>> >>> >>> To my best knowledge AIX neither supports ppc64le at the moment nor >>> are there any plans to support it in the future. >>> >>> Regards, >>> Volker >>> >>>> Thanks, >>>> -- >>>> Andrew :) >>>> >>>> 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 >>>> >>>> PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) >>>> Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 >>>> >>> >> >> >> > > Thanks, that was my assumption. I did wonder if the lack of SA was > AIX rather than AIX+PPC-specific and whether we could just drop the > arch test altogether... But if someone does start building ppc64le+AIX, > they'd find this issue straight away anyway. > > Ok if I push the jdk and root parts then? I think someone on the Oracle > HS team (David?) needs to push the HotSpot bit. Best to push it all together I think, which I can do through the hs-rt forest. But first I need to see where things settled with all this :) I was quite confused by some of the initial suggestions. Will try to get to this today. David ----- > Thanks, > From tdaitx at br.ibm.com Thu Feb 26 03:41:01 2015 From: tdaitx at br.ibm.com (Tiago Sturmer Daitx) Date: Thu, 26 Feb 2015 00:41:01 -0300 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: References: <54E55A01.5020700@oracle.com> <54E56503.4090704@oracle.com> <54E65D27.3070107@oracle.com> <1747776645.16967635.1424701004513.JavaMail.zimbra@redhat.com> <54EB3FDB.1060609@oracle.com> <1106037034.17263798.1424717837816.JavaMail.zimbra@redhat.com> <54EC3483.1040808@oracle.com> <817540395.17755484.1424787667774.JavaMail.zimbra@redhat.com> Message-ID: <1424922061.5112.297.camel@ocdc> On Tue, 2015-02-24 at 09:58 -0800, Alexander Smundak wrote: > On Tue, Feb 24, 2015 at 6:21 AM, Andrew Hughes wrote: > > Did we decide whether -DABI_ELFv2 was needed or not? If it isn't, then I'll > > drop this from the webrev too, and also from our version of the ppc64le port > > on OpenJDK 7. > > I think only hotspot needs it. That macro is only used by hotspot - there's no single reference to it outside the hotspot for JDK8 and JDK9. I see it being defined in jdk/make/common/Defs-linux.gmk for IcedTea 2.5 (JDK7) and since it is also defined by hotspot/make/linux/makefiles/ppc64.make I believe it is not actually required in Defs-linux.gmk (haven't tried to build without it though). Regards, Tiago From david.holmes at oracle.com Thu Feb 26 03:50:17 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 26 Feb 2015 13:50:17 +1000 Subject: RFR (L): 8068685 - [TESTBUG] Ensure @library works in jtreg -agentvm mode In-Reply-To: <54EE81F7.6050608@oracle.com> References: <54ECE2EF.4040805@oracle.com> <54ED55C8.9030602@oracle.com> <54EDD15F.9030506@oracle.com> <54EE81F7.6050608@oracle.com> Message-ID: <54EE97F9.5010102@oracle.com> One correction ... On 26/02/2015 12:16 PM, David Holmes wrote: > Hi George, > > On 25/02/2015 11:42 PM, George Triantafillou wrote: >> Hi David, >> >> Thanks for your review. Comments inline: >> >> On 2/24/2015 11:55 PM, David Holmes wrote: >>> On 25/02/2015 6:45 AM, George Triantafillou wrote: >>>> Please review this fix for JDK-8068685: >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8068685 >>>> webrev: http://cr.openjdk.java.net/~gtriantafill/8068685/webrev.00 >>>> >>>> >>>> "@build com.oracle.java.testlibrary.*" was added to all relevant tests, >>> >>> I thought we had an RFE open against jtreg to avoid the need to do >>> this, but it seems I was mistaken. :( >>> >>> Most of the additions to @build seem okay. A few minor issues: >>> >>> --- old/test/compiler/whitebox/ForceNMethodSweepTest.java 2015-02-24 >>> 10:31:03.991071066 -0800 >>> +++ new/test/compiler/whitebox/ForceNMethodSweepTest.java 2015-02-24 >>> 10:31:03.617052982 -0800 >>> @@ -35,6 +35,9 @@ >>> * @test >>> * @bug 8059624 8064669 >>> * @library /testlibrary /../../test/lib >>> + * @build com.oracle.java.testlibrary.* ForceNMethodSweepTest >>> + * @ignore 8066998 >>> + * @library /testlibrary /../../test/lib >>> * @build ForceNMethodSweepTest >>> >>> The second @library shouldn't have been added. >> Good catch, thanks. Changed. >> >>> >>> --- old/test/gc/g1/TestStringSymbolTableStats.java 2015-02-24 >>> 10:32:28.209143019 -0800 >>> +++ new/test/gc/g1/TestStringSymbolTableStats.java 2015-02-24 >>> 10:32:27.855125901 -0800 >>> @@ -22,11 +22,13 @@ >>> */ >>> >>> /* >>> - * @test TestStringSymbolTableStats.java >>> + * @test TestStringSymbolTableStats >>> >>> Why did you change the @test? I see a lot of unchanged @test foo.java. >> According to the jtreg tag spec >> http://openjdk.java.net/jtreg/tag-spec.html, either way is correct. The >> only tests that were considered for this change included "@library >> /testlibrary", so I changed this one for consistency with other tests >> that I've written. I'll change it back if it's a concern. > > No big deal but caused confusion when reviewing. > >>>> which resulted in longer test execution times. In order to offset >>>> these >>>> longer test execution times and to support running jtreg in -agentvm >>>> mode, the following changes were made: >>>> >>>> test/Makefile: added -agentvm option >>> >>> I'm unclear exactly what this buys us - do we just save on the startup >>> costs of new vms running jtreg? I thought the default was samevm anyway? >>> >>> Also does this mean that all VMs will share a single copy of the >>> testlibrary or will we still have a copy per test that gets built each >>> time? >> The jtreg command help http://openjdk.java.net/jtreg/command-help.html >> doc states: >> >> -agentvm "Run tests using a pool of reusable JVMs." >> -samevm "If possible, run each test in the same JVM as the JavaTest" >> >> I'm not really sure how samevm decides "if possible", but the intent of >> this change was to explicitly add "@build com.oracle.java.testlibrary.*" >> to relevant jtreg runtime tests without increasing test execution >> times. The analysis below shows decreased test execution times using >> agentvm. > > Yes but I'd like to understand why that is the case, and whether we are > still being inefficient in this even if better than the initial attempt. > It is very unclear to me how the addition of agentvm is influencing the > building of the testlibrary. > >>> >>>> test/testlibrary/com/oracle/java/testlibrary/ProcessTools.java: added >>>> -classpath since -agentvm passes the classpath differently than >>>> -othervm >>>> >>>> *Testing shows an 11% speed improvement for JPRT execution of the >>>> hotspot testset, and a 48% speed improvement for >>>> hotspot_runtime*/gc*/compiler*/serviceability* tests.** >>>> >>>> *Note that some tests required the explicit addition of -othervm in >>>> order for the tests to pass. In addition, a number of gc, compiler and >>>> runtime tests were modified with @run so they would run successfully >>>> with -agentvm. Consequently, reviews from members of the compiler, gc, >>>> runtime, and serviceability teams would be very helpful. >>> >>> I'm unclear about the need for some of the othervm changes. I would >>> only expect othervm to be needed if passing -XX options via @run ?? >> I added @run to some tests, and some of them failed with -agentvm until >> I added -othervm. > > This is a puzzle - perhaps a jtreg bug. Without the @build for the > testlibrary you can use -agentvm without a problem based on a few > experiments I did. Once you add the @build you then also have to add > @run, but the simple: @run test fails with e.g.: > > test result: Error. Bad action for script: CdsSameObjectAlignment User error. You must have an action, such as main, after @run. David > However it suffices to add "main" in the @run: > > @run main CdsDifferentObjectAlignment > > without needing to add /othervm > > Cheers, > David > > >> -George >>> >>> Thanks, >>> David >>> >>>> Thanks to Erik Helin for providing a solution for passing classpath >>>> with >>>> -agentvm. >>>> >>>> The fix was tested locally on Linux with jtreg and on all platforms >>>> with >>>> the JPRT hotspot testset.* >>>> * >>>> Thanks. >>>> >>>> -George >>>> >> From stefan.karlsson at oracle.com Thu Feb 26 07:31:32 2015 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 26 Feb 2015 08:31:32 +0100 Subject: CFV: New hotspot Group Member: Igor Ignatyev In-Reply-To: <20150225115205.GB6837@ehelin.jrpg.bea.com> References: <20150225115205.GB6837@ehelin.jrpg.bea.com> Message-ID: <54EECBD4.7050707@oracle.com> Vote: yes StefanK On 2015-02-25 12:52, Erik Helin wrote: > I hereby nominate Igor Ignatyev to Membership in the hotspot Group. > > Igor is the technical lead of the HotSpot Compiler SQE group and is a > Reviewer in the jdk9 project and a committer in the hsx and jdk8u > projects. He has been working actively in the HotSpot project for 2.5 > years. > > Igor is key contributor to the testability of the JIT compilers in > HotSpot: he is the author of much of the WhiteBox compiler API and has > written many of the additional tests for the JIT compilers. Igor's > additional contributions include several product bug fixes, test > development for JSR292 and being part of the test stabilization effort. > Igor also mentors other engineers from the HotSpot SQE and STT team. > > Votes are due by March 11, 13:00 CET. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list > > For Lazy Consensus voting instructions, see [2]. > > Erik Helin > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/groups/#member-vote From david.holmes at oracle.com Thu Feb 26 07:58:11 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 26 Feb 2015 17:58:11 +1000 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <54EE8588.8060209@oracle.com> References: <54E65D27.3070107@oracle.com> <1747776645.16967635.1424701004513.JavaMail.zimbra@redhat.com> <54EB3FDB.1060609@oracle.com> <54EDB56A.7010007@oracle.com> <1046475406.18554532.1424872225779.JavaMail.zimbra@redhat.com> <1424883208.5112.287.camel@ocdc> <1739722263.18761313.1424883425179.JavaMail.zimbra@redhat.com> <54EE8588.8060209@oracle.com> Message-ID: <54EED213.5010006@oracle.com> On 26/02/2015 12:31 PM, David Holmes wrote: > On 26/02/2015 2:57 AM, Andrew Hughes wrote: >>>>> These are the revised versions of the webrevs: >>>>> >>>>> http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/root/ >>>>> http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/jdk/ >>>>> http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/hotspot/ >>>>> >>>>> (HotSpot is unchanged, dropped the sound changes from JDK) >> >> Ok if I push the jdk and root parts then? I think someone on the Oracle >> HS team (David?) needs to push the HotSpot bit. > > Best to push it all together I think, which I can do through the hs-rt > forest. But first I need to see where things settled with all this :) I > was quite confused by some of the initial suggestions. Will try to get > to this today. I'm still very confused by these changes and have trouble tracking the values of the various "arch" related variables. If I follow this right presently the only distinction between ppc64 and ppc64le is the value of OPENJDK_TARGET_CPU_ENDIAN. In particular they both use ppc64 as the hotspot LIBARCH value and ppc as the ARCH value. (Aside: so ARCH/ppc64 is either unused or only used by a hotspot-only build?) The desired change is that the top-level architecture (VAR_CPU which becomes OPENJDK_TARGET_CPU) should now be ppc64le not ppc64, but that for hotspot the only difference is LIBARCH becomes ppc64le. So to achieve this hotspot-spec.gmk switches ARCH to be ppc64 instead of the current ppc; and then hotspot's def.make uses that combined with being lttle-endian to reset the LIBARCH to ppc64le. This all seems very convoluted! Why can you not simply check the value of BUILD_ARCH for ppc64 and then check the endianess to redefine LIBARCH? That way you don't need to change ARCH as set by hotspot-spec.gmk. Does "uname -m" return ppc64le ? I'm unclear whether either your proposal or mine actually works correctly for a hotspot-only build. But maybe we just don't care about builds not done via configure any more. Thanks, David Given the LIBARCH switcheroo that happens in hotspot/make/def.make, why bother also doing the switcheroo in /common/autoconf/hotspot-spec.gmk.in when you could just do everything in hotspot/make/defs > David > ----- > > >> Thanks, >> From goetz.lindenmaier at sap.com Thu Feb 26 08:29:20 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 26 Feb 2015 08:29:20 +0000 Subject: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. In-Reply-To: References: <4295855A5C1DE049A61835A1887419CC2CF9615F@DEWDFEMB12A.global.corp.sap> <70B02DBE-E246-45F9-89C7-898881B0C69A@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF96468@DEWDFEMB12A.global.corp.sap> <65A32AAF-F514-4E10-AF4A-DA04F41F57BF@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF967DF@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CF99127@DEWDFEMB12A.global.corp.sap> Message-ID: <4295855A5C1DE049A61835A1887419CC2CF99324@DEWDFEMB12A.global.corp.sap> Hi Kim, that's OK, take your time. I'll eventually ping again. There is no hurry with this. Jep, that's the fix to gcc one wants to have. I'm fine with enabling the warning only for gcc 4.8. That's the version Oracle is using for the jprt build, right? Best regards, Goetz. -----Original Message----- From: Kim Barrett [mailto:kim.barrett at oracle.com] Sent: Mittwoch, 25. Februar 2015 21:36 To: Lindenmaier, Goetz Cc: hotspot-dev Source Developers Subject: Re: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. On Feb 25, 2015, at 5:52 AM, Lindenmaier, Goetz wrote: > > Hi Kim, > > Do you have any more comments on this? Sorry for the delay. I do, but am swamped with other things just now. I hope to get back to this for real in the next couple of days. Short answer is that I'm fine with most of the changes, except the warning enable. However, it appears the relevant gcc bug was fixed in gcc4.8 (not sure which patch version): https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11856 [Note there are quite a few duplicates of that bug too; roughly 10 in total.] If the warning were enabled conditionally on the gcc version, that would satisfy me. From staffan.larsen at oracle.com Thu Feb 26 09:08:01 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 26 Feb 2015 10:08:01 +0100 Subject: RFR: JDK-8072842 Add support for building native JTReg tests In-Reply-To: <54EDB038.4000502@oracle.com> References: <54DA146D.3060904@oracle.com> <54DAB1CE.70506@oracle.com> <54DB0E31.3010201@oracle.com> <54DB1175.6030700@oracle.com> <54DB125D.2070706@oracle.com> <54DB1528.4030708@oracle.com> <324EF37C-3FD2-4B8A-A509-D7315889D8DE@oracle.com> <54DB39C2.5010607@oracle.com> <31B825DC-DFD2-4EC2-81AD-9BF0FC3364CC@oracle.com> <54EDB038.4000502@oracle.com> Message-ID: As far as I can tell (I?m not a makefile expert) this looks good. Thanks, /Staffan > On 25 feb 2015, at 12:21, Magnus Ihse Bursie wrote: > > On 2015-02-11 13:08, Staffan Larsen wrote: >> >>>>>>>> Okay so if I just cd into hotspot/test and use the Makefile to try >>>>>>>> and run some jtreg tests it looks to me that it will define an >>>>>>>> invalid -nativepath >>>>>>> >>>>>>> I'm not sure if that is a supported use case. David or Staffan will >>>>>>> have to answer to that. I have not tested that, only the "whole >>>>>>> forest" approach. >>>>>> >>>>>> I?ve never done that. I?m always running all make commands from the top >>>>>> level. Is there a problem with that? >>>>> >>>>> I must confess I also haven't done that - though I often run jtreg directly from there. Other hotspot engineers may use it. If nothing else it would be a way to test out what you expect JPRT to be running. >>>>> >>>>> But perhaps we just don't add the -nativepath component if TESTNATIVE_DIR remains unset? >>>> >>>> Not adding -nativepath or adding it with an empty path will lead to the same errors I think: tests that need native code will fail. So it does not really matter. >>> >>> If you add it with an invalid path (won't be empty as the variable is only a prefix) then tests that don't need native code may also fail. Though I don't know how jtreg responds to a non-existent nativepath. >> >> You are right. Jtreg validates the that the path is a directory. So better not to specify it. > > Ok. I have updated the webrev, so the -nativepath: argument is only specified if we indeed have been given a valid path to the native libraries. > > The only changes between this and the previous webrev is in hotspot/test/Makefile and jdk/test/Makefile. > > http://cr.openjdk.java.net/~ihse/JDK-8072842-build-native-jtreg-tests/webrev.02 > > /Magnus From erik.joelsson at oracle.com Thu Feb 26 09:25:58 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 26 Feb 2015 10:25:58 +0100 Subject: RFR: JDK-8072842 Add support for building native JTReg tests In-Reply-To: <54EDB038.4000502@oracle.com> References: <54DA146D.3060904@oracle.com> <54DAB1CE.70506@oracle.com> <54DB0E31.3010201@oracle.com> <54DB1175.6030700@oracle.com> <54DB125D.2070706@oracle.com> <54DB1528.4030708@oracle.com> <324EF37C-3FD2-4B8A-A509-D7315889D8DE@oracle.com> <54DB39C2.5010607@oracle.com> <31B825DC-DFD2-4EC2-81AD-9BF0FC3364CC@oracle.com> <54EDB038.4000502@oracle.com> Message-ID: <54EEE6A6.8050103@oracle.com> Hello Magnus, Overall looks good. I would prefer if some of the longer lines in Main.gmk were split as it's a file I often need to read. In MakeBase, the definition of dups, I thought we (informally) agreed to start such macro definitions with a newline to make them stand out more from normal variable declarations? /Erik On 2015-02-25 12:21, Magnus Ihse Bursie wrote: > On 2015-02-11 13:08, Staffan Larsen wrote: >> >>>>>>>> Okay so if I just cd into hotspot/test and use the Makefile to try >>>>>>>> and run some jtreg tests it looks to me that it will define an >>>>>>>> invalid -nativepath >>>>>>> >>>>>>> I'm not sure if that is a supported use case. David or Staffan will >>>>>>> have to answer to that. I have not tested that, only the "whole >>>>>>> forest" approach. >>>>>> >>>>>> I?ve never done that. I?m always running all make commands from >>>>>> the top >>>>>> level. Is there a problem with that? >>>>> >>>>> I must confess I also haven't done that - though I often run jtreg >>>>> directly from there. Other hotspot engineers may use it. If >>>>> nothing else it would be a way to test out what you expect JPRT to >>>>> be running. >>>>> >>>>> But perhaps we just don't add the -nativepath component if >>>>> TESTNATIVE_DIR remains unset? >>>> >>>> Not adding -nativepath or adding it with an empty path will lead to >>>> the same errors I think: tests that need native code will fail. So >>>> it does not really matter. >>> >>> If you add it with an invalid path (won't be empty as the variable >>> is only a prefix) then tests that don't need native code may also >>> fail. Though I don't know how jtreg responds to a non-existent >>> nativepath. >> >> You are right. Jtreg validates the that the path is a directory. So >> better not to specify it. > > Ok. I have updated the webrev, so the -nativepath: argument is only > specified if we indeed have been given a valid path to the native > libraries. > > The only changes between this and the previous webrev is in > hotspot/test/Makefile and jdk/test/Makefile. > > http://cr.openjdk.java.net/~ihse/JDK-8072842-build-native-jtreg-tests/webrev.02 > > > /Magnus From volker.simonis at gmail.com Thu Feb 26 11:06:28 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 26 Feb 2015 12:06:28 +0100 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <54EED213.5010006@oracle.com> References: <54E65D27.3070107@oracle.com> <1747776645.16967635.1424701004513.JavaMail.zimbra@redhat.com> <54EB3FDB.1060609@oracle.com> <54EDB56A.7010007@oracle.com> <1046475406.18554532.1424872225779.JavaMail.zimbra@redhat.com> <1424883208.5112.287.camel@ocdc> <1739722263.18761313.1424883425179.JavaMail.zimbra@redhat.com> <54EE8588.8060209@oracle.com> <54EED213.5010006@oracle.com> Message-ID: On Thu, Feb 26, 2015 at 8:58 AM, David Holmes wrote: > > On 26/02/2015 12:31 PM, David Holmes wrote: >> >> On 26/02/2015 2:57 AM, Andrew Hughes wrote: >>>>>> >>>>>> These are the revised versions of the webrevs: >>>>>> >>>>>> http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/root/ >>>>>> http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/jdk/ >>>>>> http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/hotspot/ >>>>>> >>>>>> (HotSpot is unchanged, dropped the sound changes from JDK) >>> >>> >>> Ok if I push the jdk and root parts then? I think someone on the Oracle >>> HS team (David?) needs to push the HotSpot bit. >> >> >> Best to push it all together I think, which I can do through the hs-rt >> forest. But first I need to see where things settled with all this :) I >> was quite confused by some of the initial suggestions. Will try to get >> to this today. > > > I'm still very confused by these changes and have trouble tracking the > values of the various "arch" related variables. If I follow this right > presently the only distinction between ppc64 and ppc64le is the value of > OPENJDK_TARGET_CPU_ENDIAN. In particular they both use ppc64 as the hotspot > LIBARCH value and ppc as the ARCH value. (Aside: so ARCH/ppc64 is either > unused or only used by a hotspot-only build?) Yes, ARCH/ppc64 is only used by hotspot-only builds. ARCH is explicitly set to 'uname -m' in hotspot/make/linux/makefiles/defs.make if it isn't already defined: # ARCH can be set explicitly in spec.gmk ifndef ARCH ARCH := $(shell uname -m) # Fold little endian PowerPC64 into big-endian (if ARCH is set in # hotspot-spec.gmk, this will be done by the configure script). ifeq ($(ARCH),ppc64le) ARCH := ppc64 endif endif And that's because of 8046471 (we've just discussed that before in the thread for "8072383: resolve conflicts between open and closed ports" :) We still use hotspot-only builds (e.g. for the nightly build of all the different hotspot repositories but I don't know if that will be still possible after the big HotSpot make rework (see this thread http://mail.openjdk.java.net/pipermail/build-infra-dev/2013-December/003339.html). > > The desired change is that the top-level architecture (VAR_CPU which becomes > OPENJDK_TARGET_CPU) should now be ppc64le not ppc64, but that for hotspot > the only difference is LIBARCH becomes ppc64le. So to achieve this > hotspot-spec.gmk switches ARCH to be ppc64 instead of the current ppc; and > then hotspot's def.make uses that combined with being lttle-endian to reset > the LIBARCH to ppc64le. > > This all seems very convoluted! Why can you not simply check the value of > BUILD_ARCH for ppc64 and then check the endianess to redefine LIBARCH? That > way you don't need to change ARCH as set by hotspot-spec.gmk. > That sounds good. I would support this approach. > Does "uname -m" return ppc64le ? I'm unclear whether either your proposal or > mine actually works correctly for a hotspot-only build. But maybe we just > don't care about builds not done via configure any more. > Yes, as far as I know "uname -m" returns ppc64le on little endian machines. But the case of hotspot-only builds which don't have ARCH defined is anyway handled specially in hotspot/make/linux/makefiles/defs.make (see the code snipped above). I think if we would change that to: # ARCH can be set explicitly in spec.gmk ifndef ARCH ARCH := $(shell uname -m) # Fold little endian PowerPC64 into big-endian (if ARCH is set in # hotspot-spec.gmk, this will be done by the configure script). ifeq ($(ARCH),ppc64le) ARCH := ppc endif ifeq ($(ARCH),ppc64) ARCH := ppc endif endif It should be also possible to get rid of the ARCH/ppc64 case and unify the hotspot-only with the top-level build. One more observation: the changes in src/os/linux/vm/os_linux.cpp collide with the changes Dean (put him on CC) has done for 8072383. Dean's change handles this more general (which is good) but nevertheless the one who pushes his changes later will have to fix his patch. Regards, Volker > Thanks, > David > > > Given the LIBARCH switcheroo that happens in hotspot/make/def.make, why > bother also doing the switcheroo in > /common/autoconf/hotspot-spec.gmk.in when you could just do everything > in hotspot/make/defs > >> David >> ----- >> >> >>> Thanks, >>> > From stefan.johansson at oracle.com Thu Feb 26 11:13:22 2015 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Thu, 26 Feb 2015 12:13:22 +0100 Subject: RFR [8u60]: 8073944: Simplify ArgumentsExt and remove unneeded functionallity Message-ID: <54EEFFD2.6040806@oracle.com> Hi, Please review this small changes for: https://bugs.openjdk.java.net/browse/JDK-8073944 Webrev: http://cr.openjdk.java.net/~sjohanss/8073944/hotspot.00/ Summary: The removed functionality was added as part of JDK-8057623, but is no longer needed. Thanks, Stefan From goetz.lindenmaier at sap.com Thu Feb 26 11:48:35 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 26 Feb 2015 11:48:35 +0000 Subject: RFR(XS): 8073954: Initialize _replaced_nodes in SafePoints. Message-ID: <4295855A5C1DE049A61835A1887419CC2CF993F5@DEWDFEMB12A.global.corp.sap> Hi, please review this tiny fix in the C2 compiler. I please need a sponsor. The field _replaced_node added to SafePoints in "8026796: Make replace_in_map() on parent maps generic" is not initialized to NULL. As the memory is pre-set to 0, this doesn't cause immediate problems. But we saw lots of sporadic failures in our nightly tests of SAP JVM with the debug build, where memory in Arenas is zapped to 0xab. We also saw rare failures with the opt builds. https://bugs.openjdk.java.net/browse/JDK-8073954 http://cr.openjdk.java.net/~goetz/webrevs/8073954-replNd/webrev/ 8026796 was downported to 8u40, so it's wrong there, too. Best regards, Goetz. From christian.thalinger at oracle.com Thu Feb 26 17:18:18 2015 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 26 Feb 2015 09:18:18 -0800 Subject: CFV: New hotspot Group Member: Igor Ignatyev In-Reply-To: <20150225115205.GB6837@ehelin.jrpg.bea.com> References: <20150225115205.GB6837@ehelin.jrpg.bea.com> Message-ID: Vote: yes > On Feb 25, 2015, at 3:52 AM, Erik Helin wrote: > > I hereby nominate Igor Ignatyev to Membership in the hotspot Group. > > Igor is the technical lead of the HotSpot Compiler SQE group and is a > Reviewer in the jdk9 project and a committer in the hsx and jdk8u > projects. He has been working actively in the HotSpot project for 2.5 > years. > > Igor is key contributor to the testability of the JIT compilers in > HotSpot: he is the author of much of the WhiteBox compiler API and has > written many of the additional tests for the JIT compilers. Igor's > additional contributions include several product bug fixes, test > development for JSR292 and being part of the test stabilization effort. > Igor also mentors other engineers from the HotSpot SQE and STT team. > > Votes are due by March 11, 13:00 CET. > > Only current Members of the hotspot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list > > For Lazy Consensus voting instructions, see [2]. > > Erik Helin > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/groups/#member-vote From kim.barrett at oracle.com Thu Feb 26 18:15:19 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 26 Feb 2015 13:15:19 -0500 Subject: RFR(XS): 8073954: Initialize _replaced_nodes in SafePoints. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CF993F5@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CF993F5@DEWDFEMB12A.global.corp.sap> Message-ID: <58809E49-E3AF-4F40-B93E-E8A116539A33@oracle.com> On Feb 26, 2015, at 6:48 AM, Lindenmaier, Goetz wrote: > > please review this tiny fix in the C2 compiler. I please need a sponsor. > > The field _replaced_node added to SafePoints in "8026796: Make replace_in_map() on parent maps generic" > is not initialized to NULL. As the memory is pre-set to 0, this doesn't cause immediate problems. > But we saw lots of sporadic failures in our nightly tests of SAP JVM with the debug build, where memory > in Arenas is zapped to 0xab. We also saw rare failures with the opt builds. > > https://bugs.openjdk.java.net/browse/JDK-8073954 > http://cr.openjdk.java.net/~goetz/webrevs/8073954-replNd/webrev/ > > 8026796 was downported to 8u40, so it's wrong there, too. I've no problem with the change, per se. However, I don't understand the motivation for the change. "The field _replaced_node added to SafePoints in "8026796: Make replace_in_map() on parent maps generic" is not initialized to NULL." _replaced_nodes is of type ReplacedNodes, which is a class type with user-defined constructors (in this case, only a default constructor). Note that it is not a pointer type, it is a nested object. Not mentioning _replaced_nodes in the ctor-initializer (old code) causes it to be default initialized. (C++03 12.6.2/4) Including _replaced_nodes with an empty initializer list (proposed change) causes it to be value initialized. (C++03 12.6.2/3) For a class type with a user-defined constructor, value initialization and default initialization are the same; both forms of initialization call the class's default constructor. (C++03 8.5/5) So with or without this change, _replaced_nodes should be initialized via a call to its default constructor. And that default constructor directly initializes the pointer member to NULL. In other words, I don't think this code change leads to any program execution change. From david.holmes at oracle.com Thu Feb 26 20:17:57 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 27 Feb 2015 06:17:57 +1000 Subject: RFR (L): 8068685 - [TESTBUG] Ensure @library works in jtreg -agentvm mode In-Reply-To: <54EED5E5.6040706@oracle.com> References: <54ECE2EF.4040805@oracle.com> <54ED55C8.9030602@oracle.com> <54EDD15F.9030506@oracle.com> <62229346-9E4F-4F0E-880F-E99ED6A64EFB@oracle.com> <54EED5E5.6040706@oracle.com> Message-ID: <54EF7F75.7030808@oracle.com> I've been thinking more about this change based on Staffan's clarification of how "othervm" is the current default for testing. I think the move to agentvm is very risky and may result in very unpredictable test results. The problem being that tests no longer start out in a clean VM with a pristine state - this can impact many things that might affect how some of the tests execute. And the problems may vary depending on exactly how the tests are run, the concurrency level and number of agent VMs in use. There may not be any guarantee that the same jtreg command line will result in the same tests being executed in the same sequence on the same agent VMs. It may be that the introduction of "main/othervm" in some tests was already an indication of this problem. But the real problem may be the interaction between tests. David On 26/02/2015 6:14 PM, David Holmes wrote: > Hi Staffan, > > On 26/02/2015 6:00 PM, Staffan Larsen wrote: >> >>> On 25 feb 2015, at 14:42, George Triantafillou >>> >> > wrote: >>> >>> Hi David, >>> >>> Thanks for your review. Comments inline: >>> >>> On 2/24/2015 11:55 PM, David Holmes wrote: >>>> On 25/02/2015 6:45 AM, George Triantafillou wrote: >>>>> Please review this fix for JDK-8068685: >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8068685 >>>>> webrev: http://cr.openjdk.java.net/~gtriantafill/8068685/webrev.00 >>>>> >>>>> >>>>> "@build com.oracle.java.testlibrary.*" was added to all relevant >>>>> tests, >>>> >>>> I thought we had an RFE open against jtreg to avoid the need to do >>>> this, but it seems I was mistaken. :( >>>> >>>> Most of the additions to @build seem okay. A few minor issues: >>>> >>>> --- old/test/compiler/whitebox/ForceNMethodSweepTest.java 2015-02-24 >>>> 10:31:03.991071066 -0800 >>>> +++ new/test/compiler/whitebox/ForceNMethodSweepTest.java 2015-02-24 >>>> 10:31:03.617052982 -0800 >>>> @@ -35,6 +35,9 @@ >>>> * @test >>>> * @bug 8059624 8064669 >>>> * @library /testlibrary /../../test/lib >>>> + * @build com.oracle.java.testlibrary.* ForceNMethodSweepTest >>>> + * @ignore 8066998 >>>> + * @library /testlibrary /../../test/lib >>>> * @build ForceNMethodSweepTest >>>> >>>> The second @library shouldn't have been added. >>> Good catch, thanks. Changed. >>> >>>> >>>> --- old/test/gc/g1/TestStringSymbolTableStats.java 2015-02-24 >>>> 10:32:28.209143019 -0800 >>>> +++ new/test/gc/g1/TestStringSymbolTableStats.java 2015-02-24 >>>> 10:32:27.855125901 -0800 >>>> @@ -22,11 +22,13 @@ >>>> */ >>>> >>>> /* >>>> - * @test TestStringSymbolTableStats.java >>>> + * @test TestStringSymbolTableStats >>>> >>>> Why did you change the @test? I see a lot of unchanged @test foo.java. >>> According to the jtreg tag >>> spechttp://openjdk.java.net/jtreg/tag-spec.html, either way is >>> correct. The only tests that were considered for this change included >>> "@library /testlibrary", so I changed this one for consistency with >>> other tests that I've written. I'll change it back if it's a concern. >>>> >>>> >>>>> which resulted in longer test execution times. In order to offset >>>>> these >>>>> longer test execution times and to support running jtreg in -agentvm >>>>> mode, the following changes were made: >>>>> >>>>> test/Makefile: added -agentvm option >>>> >>>> I'm unclear exactly what this buys us - do we just save on the >>>> startup costs of new vms running jtreg? I thought the default was >>>> samevm anyway? >>>> >>>> Also does this mean that all VMs will share a single copy of the >>>> testlibrary or will we still have a copy per test that gets built >>>> each time? >>> The jtreg command >>> helphttp://openjdk.java.net/jtreg/command-help.htmldoc states: >>> >>> -agentvm "Run tests using a pool of reusable JVMs." >>> -samevm "If possible, run each test in the same JVM as the JavaTest" >>> >>> I'm not really sure how samevm decides "if possible", but the intent >>> of this change was to explicitly add "@build >>> com.oracle.java.testlibrary.*" to relevant jtreg runtime tests without >>> increasing test execution times. The analysis below shows decreased >>> test execution times using agentvm. >> >> Re-reading the documentation, checking the sources and running some >> experiments show that the default mode for jtreg is not samevm, but >> othervm. In othervm mode, jtreg will create a new JVM for each test >> /and/ for each javac invocation. In agentvm mode a pool of JVMs will be >> reused for both javac and for the tests. When running in agentmode, even >> if a test says ?main/othervm?, the javac invocation of the test will >> happen in the agent. So running in agentvm mode saves time even if all >> tests say ?main/othervm?. > > Thanks for clarifying that. It would seem main/othervm is only ever > needed to override -agentvm or -samevm. That makes sense. > > I still wonder how many times the test library gets built per set of > tests ? :) > >> The following passage from the documentation is confusing: >> >> ---- >> Test Mode Options >> >> When the JavaTest harness is used to run tests, two possibly different >> versions of the JDK are used: the JDK version used to run the harness >> and the JDK version used to run the test(s). The following options >> provide a means to specify the JDK version used to run the tests. The >> default is to use the same JDK version (provided by JAVA_HOME) for both >> the harness and the tests, and for each test to run in its own JVM. >> ---- >> >> Notice how the last sentence seems to begin by saying samevm mode is the >> default, but its really just talking about the version of the JDK used >> to for running the tests. The sentence ends by saying (not very >> explicitly) that othervm is the default mode. I?ll see if we can clarify >> that. > > It is even more confusing if you take into account that with samevm it > uses the testjdk, but you can also set compilejdk to a different jdk, > which suggests it will run the tests in the same vm as the harness but > launch separate vms to do the compilation. > > Well now I've said that perhaps not so confusing after all :) > > Thanks, > David > >> >> /Staffan >> >> >>>> >>>>> test/testlibrary/com/oracle/java/testlibrary/ProcessTools.java: added >>>>> -classpath since -agentvm passes the classpath differently than >>>>> -othervm >>>>> >>>>> *Testing shows an 11% speed improvement for JPRT execution of the >>>>> hotspot testset, and a 48% speed improvement for >>>>> hotspot_runtime*/gc*/compiler*/serviceability* tests.** >>>>> >>>>> *Note that some tests required the explicit addition of -othervm in >>>>> order for the tests to pass. In addition, a number of gc, compiler >>>>> and >>>>> runtime tests were modified with @run so they would run successfully >>>>> with -agentvm. Consequently, reviews from members of the compiler, >>>>> gc, >>>>> runtime, and serviceability teams would be very helpful. >>>> >>>> I'm unclear about the need for some of the othervm changes. I would >>>> only expect othervm to be needed if passing -XX options via @run ?? >>> I added @run to some tests, and some of them failed with -agentvm >>> until I added -othervm. >>> >>> -George >>>> >>>> Thanks, >>>> David >>>> >>>>> Thanks to Erik Helin for providing a solution for passing classpath >>>>> with >>>>> -agentvm. >>>>> >>>>> The fix was tested locally on Linux with jtreg and on all platforms >>>>> with >>>>> the JPRT hotspot testset.* >>>>> * >>>>> Thanks. >>>>> >>>>> -George >> From kim.barrett at oracle.com Thu Feb 26 21:00:28 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 26 Feb 2015 16:00:28 -0500 Subject: RFR [8u60]: 8073944: Simplify ArgumentsExt and remove unneeded functionallity In-Reply-To: <54EEFFD2.6040806@oracle.com> References: <54EEFFD2.6040806@oracle.com> Message-ID: On Feb 26, 2015, at 6:13 AM, Stefan Johansson wrote: > > Hi, > > Please review this small changes for: > https://bugs.openjdk.java.net/browse/JDK-8073944 > > Webrev: > http://cr.openjdk.java.net/~sjohanss/8073944/hotspot.00/ > > Summary: > The removed functionality was added as part of JDK-8057623, but is no longer needed. > > Thanks, > Stefan Looks good. From vladimir.kozlov at oracle.com Thu Feb 26 21:25:30 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 26 Feb 2015 13:25:30 -0800 Subject: Notification about AARCH64 open port merge to jdk9/dev Message-ID: <54EF8F4A.40006@oracle.com> Hi, We are finishing Oracle's internal testing of AARCH64 open port [1]. I synced staging repo [2] with latest jdk9/dev sources today. The plan is to merge AARCH64 sources into jdk9/dev next week. I was asked to send this notice to let people test sources in stage repository before I push them into jdk9. Regards, Vladimir 1. JEP 237: Linux/AArch64 Port https://bugs.openjdk.java.net/browse/JDK-8044552 2. http://hg.openjdk.java.net/aarch64-port/stage From kim.barrett at oracle.com Thu Feb 26 22:19:25 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 26 Feb 2015 17:19:25 -0500 Subject: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CF99324@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CF9615F@DEWDFEMB12A.global.corp.sap> <70B02DBE-E246-45F9-89C7-898881B0C69A@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF96468@DEWDFEMB12A.global.corp.sap> <65A32AAF-F514-4E10-AF4A-DA04F41F57BF@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF967DF@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CF99127@DEWDFEMB12A.global.corp.sap> <4295855A5C1DE049A61835A1887419CC2CF99324@DEWDFEMB12A.global.corp.sap> Message-ID: On Feb 26, 2015, at 3:29 AM, Lindenmaier, Goetz wrote: > > Jep, that's the fix to gcc one wants to have. > I'm fine with enabling the warning only for gcc 4.8. That's the > version Oracle is using for the jprt build, right? Looks like it is. From kim.barrett at oracle.com Thu Feb 26 22:24:32 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 26 Feb 2015 17:24:32 -0500 Subject: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CF967DF@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CF9615F@DEWDFEMB12A.global.corp.sap> <70B02DBE-E246-45F9-89C7-898881B0C69A@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF96468@DEWDFEMB12A.global.corp.sap> <65A32AAF-F514-4E10-AF4A-DA04F41F57BF@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF967DF@DEWDFEMB12A.global.corp.sap> Message-ID: <5FA0520E-B67D-413F-A08F-5CE6BD8FE45F@oracle.com> On Feb 19, 2015, at 5:34 AM, Lindenmaier, Goetz wrote: >> src/os/linux/vm/os_linux.cpp >> 6028 int written; >> ... >> 6050 if ((written >= 0) && ((size_t)written < bufferSize) && >> 6051 (pid_pos == NULL) && (core_pattern[0] != '|')) { >> >> The real problem here is the value of "written", which is the result >> of a call to jio_snprintf, is not being checked for failure. Clearly >> "written" should be of signed type because of its value, but the other >> changes here just continue to mask the lack of error checking. > > os_linux.cpp: > - I adapted the type to ptrdiff_t. Thanks, that looks good. > - I implemented error handling as where current directory can not be read. 5999 // Returns 0 and sets buffer to the empty string in case of failure. 6000 int os::get_core_path(char* buffer, size_t bufferSize) { ... 6008 if (bufferSize == 0) { return 0; } ... 6052 if (written < 0) { 6053 assert(false, "Could not write core_pattern to buffer"); 6054 buffer[0] = '\0'; 6055 return 0; 6056 } Based on the API, I think the intent (or at least the stylistically consistent behavior) is to have get_core_path return -1 to indicate failure, with the buffer contents unspecified in that case. The one caller of this function would operate correctly with that behavior. So rather than documenting this variant's error behavior, I think the declaration in runtime/os.hpp should be augmented with error behavior, and I think it ought to return -1 for errors. The assert(false, ...) is inappropriate. asserts should not be used for reporting external issues of this sort. Similarly for the earlier pre-existing assert on the result of get_current_directory. Just return the error flag. There are more pre-existing error checking bugs here that I'm going to suggest you not try to fix as part of this change set, but instead report as a new bug. Specific things I noticed - Result of final jio_snprintf is not checked. - Result of ::close() is not checked. Consider EINTR. - Result of ::read() is not checked. I suspect the last two are endemic in this code base. And every platform-specific implementation of get_core_path has similar error checking issues in varying degrees. (I looked at all of them and quickly spotted bugs in each one.) ------------------------------------------------------------------------------ src/share/vm/opto/graphKit.cpp 3048 if (spec_obj_type != NULL || (data != NULL)) { Please use consistent parenthesization for the two sides of the ||. >> --------------------------------------------------------------------------- >> src/share/vm/gc_implementation/g1/concurrentMark.cpp >> 2173 #ifndef PRODUCT >> 2174 if (G1StressConcRegionFreeing) { >> 2175 for (uintx i = 0; i < G1StressConcRegionFreeingDelayMillis; ++i) { >> 2176 os::sleep(Thread::current(), (jlong) 1, false); >> 2177 } >> 2178 } >> 2179 #endif >> >> The #ifndef here is the kind of workaround for the warning that I >> really dislike. > > You're right, that #define is not nice. And yes, the code you propose > is better. But here I don't feel like changing it, as I don't know > what was intended by the code. Is it used at all? Does Oracle have a > test that depends on it? Anyways, if the default is 0, it's off per > default if somebody enables G1StressConcRegionFreeing, which I also > consider a strange behaviour. The code was added with 6977804: G1: > remove the zero-filling thread: > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/0fa27f37d4d4 I can't > find the review thread in the gc mail archive. There is only the > submit: > http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2011-January/002243.html I still don't like it, but agree the #ifndef is the appropriate change for this changeset. Maybe a followup RFE suggesting cleanup of the loop? From david.holmes at oracle.com Fri Feb 27 00:15:53 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 27 Feb 2015 10:15:53 +1000 Subject: RFR [8u60]: 8073944: Simplify ArgumentsExt and remove unneeded functionallity In-Reply-To: <54EEFFD2.6040806@oracle.com> References: <54EEFFD2.6040806@oracle.com> Message-ID: <54EFB739.1030702@oracle.com> On 26/02/2015 9:13 PM, Stefan Johansson wrote: > Hi, > > Please review this small changes for: > https://bugs.openjdk.java.net/browse/JDK-8073944 > > Webrev: > http://cr.openjdk.java.net/~sjohanss/8073944/hotspot.00/ > > Summary: > The removed functionality was added as part of JDK-8057623, but is no > longer needed. Given it hasn't been in long, removing it should not be an issue - particularly for 8u - but it suggests we need to give more thought to the form of these extension points when we add them. Reviewed. Thanks, David > Thanks, > Stefan From gnu.andrew at redhat.com Fri Feb 27 01:25:02 2015 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 26 Feb 2015 20:25:02 -0500 (EST) Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <54EED213.5010006@oracle.com> References: <54EDB56A.7010007@oracle.com> <1046475406.18554532.1424872225779.JavaMail.zimbra@redhat.com> <1424883208.5112.287.camel@ocdc> <1739722263.18761313.1424883425179.JavaMail.zimbra@redhat.com> <54EE8588.8060209@oracle.com> <54EED213.5010006@oracle.com> Message-ID: <128547706.19763273.1425000302044.JavaMail.zimbra@redhat.com> ----- Original Message ----- > > On 26/02/2015 12:31 PM, David Holmes wrote: > > On 26/02/2015 2:57 AM, Andrew Hughes wrote: > >>>>> These are the revised versions of the webrevs: > >>>>> > >>>>> http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/root/ > >>>>> http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/jdk/ > >>>>> http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/hotspot/ > >>>>> > >>>>> (HotSpot is unchanged, dropped the sound changes from JDK) > >> > >> Ok if I push the jdk and root parts then? I think someone on the Oracle > >> HS team (David?) needs to push the HotSpot bit. > > > > Best to push it all together I think, which I can do through the hs-rt > > forest. But first I need to see where things settled with all this :) I > > was quite confused by some of the initial suggestions. Will try to get > > to this today. Well, I'd push it all myself if there weren't still restrictions on pushing to HotSpot... > > I'm still very confused by these changes and have trouble tracking the > values of the various "arch" related variables. If I follow this right > presently the only distinction between ppc64 and ppc64le is the value of > OPENJDK_TARGET_CPU_ENDIAN. In particular they both use ppc64 as the > hotspot LIBARCH value and ppc as the ARCH value. (Aside: so ARCH/ppc64 > is either unused or only used by a hotspot-only build?) > > The desired change is that the top-level architecture (VAR_CPU which > becomes OPENJDK_TARGET_CPU) should now be ppc64le not ppc64, but that > for hotspot the only difference is LIBARCH becomes ppc64le. So to > achieve this hotspot-spec.gmk switches ARCH to be ppc64 instead of the > current ppc; and then hotspot's def.make uses that combined with being > lttle-endian to reset the LIBARCH to ppc64le. >From ppc64le. Without the override in hotspot-spec.gmk, the HotSpot build will get called with ARCH=ppc64le and fail, because make/defs.make will set SRCARCH to x86 > > This all seems very convoluted! Why can you not simply check the value > of BUILD_ARCH for ppc64 and then check the endianess to redefine > LIBARCH? That way you don't need to change ARCH as set by hotspot-spec.gmk. > How is this different to what we are doing? + # Override LIBARCH for ppc64le + ifeq ($(ARCH), ppc64) + ifeq ($(OPENJDK_TARGET_CPU_ENDIAN), little) + LIBARCH = ppc64le + endif + endif Right there; we're checking the endianness to redefine LIBARCH. > Does "uname -m" return ppc64le ? I'm unclear whether either your > proposal or mine actually works correctly for a hotspot-only build. But > maybe we just don't care about builds not done via configure any more. > It does. Different logic is employed for a configure build (which sets various variables, including ARCH, in hotspot-spec.gmk) and a HotSpot-only build which just use makefiles. If ARCH is not set when we get to the HotSpot build, as in the latter, this block in make/linux/makefiles/defs.make is used: ifndef ARCH ARCH := $(shell uname -m) # Fold little endian PowerPC64 into big-endian (if ARCH is set in # hotspot-spec.gmk, this will be done by the configure script). ifeq ($(ARCH),ppc64le) ARCH := ppc64 endif endif This was added as part of: 8036767: PPC64: Support for little endian execution model so our addition to hotspot-spec.gmk is just to do the same as this block for configure builds. It was unneeded before because configure would just set the arch to ppc64 for the entire build, not just HotSpot. > Thanks, > David > > > Given the LIBARCH switcheroo that happens in hotspot/make/def.make, why > bother also doing the switcheroo in > /common/autoconf/hotspot-spec.gmk.in when you could just do > everything in hotspot/make/defs > > > David > > ----- > > > > > >> Thanks, > >> > -- Andrew :) 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 PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From david.holmes at oracle.com Fri Feb 27 02:04:02 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 27 Feb 2015 12:04:02 +1000 Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <128547706.19763273.1425000302044.JavaMail.zimbra@redhat.com> References: <54EDB56A.7010007@oracle.com> <1046475406.18554532.1424872225779.JavaMail.zimbra@redhat.com> <1424883208.5112.287.camel@ocdc> <1739722263.18761313.1424883425179.JavaMail.zimbra@redhat.com> <54EE8588.8060209@oracle.com> <54EED213.5010006@oracle.com> <128547706.19763273.1425000302044.JavaMail.zimbra@redhat.com> Message-ID: <54EFD092.5090007@oracle.com> On 27/02/2015 11:25 AM, Andrew Hughes wrote: > ----- Original Message ----- >> >> On 26/02/2015 12:31 PM, David Holmes wrote: >>> On 26/02/2015 2:57 AM, Andrew Hughes wrote: >>>>>>> These are the revised versions of the webrevs: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/root/ >>>>>>> http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/jdk/ >>>>>>> http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/hotspot/ >>>>>>> >>>>>>> (HotSpot is unchanged, dropped the sound changes from JDK) >>>> >>>> Ok if I push the jdk and root parts then? I think someone on the Oracle >>>> HS team (David?) needs to push the HotSpot bit. >>> >>> Best to push it all together I think, which I can do through the hs-rt >>> forest. But first I need to see where things settled with all this :) I >>> was quite confused by some of the initial suggestions. Will try to get >>> to this today. > > Well, I'd push it all myself if there weren't still restrictions on pushing > to HotSpot... > >> >> I'm still very confused by these changes and have trouble tracking the >> values of the various "arch" related variables. If I follow this right >> presently the only distinction between ppc64 and ppc64le is the value of >> OPENJDK_TARGET_CPU_ENDIAN. In particular they both use ppc64 as the >> hotspot LIBARCH value and ppc as the ARCH value. (Aside: so ARCH/ppc64 >> is either unused or only used by a hotspot-only build?) >> >> The desired change is that the top-level architecture (VAR_CPU which >> becomes OPENJDK_TARGET_CPU) should now be ppc64le not ppc64, but that >> for hotspot the only difference is LIBARCH becomes ppc64le. So to >> achieve this hotspot-spec.gmk switches ARCH to be ppc64 instead of the >> current ppc; and then hotspot's def.make uses that combined with being >> lttle-endian to reset the LIBARCH to ppc64le. > > From ppc64le. Without the override in hotspot-spec.gmk, the HotSpot build > will get called with ARCH=ppc64le and fail, because make/defs.make will > set SRCARCH to x86 No, ARCH comes from $(OPENJDK_TARGET_CPU_ARCH) which comes from $VAR_CPU_ARCH which is still ppc, not ppc64le. So SRCARCH will be set to ppc as per current code. Then BUILDARCH will check LP64 and so become ppc64. Then you can check endian-ness to define LIBARCH to ppc64le. >> This all seems very convoluted! Why can you not simply check the value >> of BUILD_ARCH for ppc64 and then check the endianess to redefine >> LIBARCH? That way you don't need to change ARCH as set by hotspot-spec.gmk. >> > > How is this different to what we are doing? Because it doesn't require the switcheroo in the hotspot-spec.gmk.in file > + # Override LIBARCH for ppc64le > + ifeq ($(ARCH), ppc64) > + ifeq ($(OPENJDK_TARGET_CPU_ENDIAN), little) > + LIBARCH = ppc64le > + endif > + endif > > Right there; we're checking the endianness to redefine LIBARCH. Yes but you can do it based on the value of LIBARCH rather than a modified ARCH. >> Does "uname -m" return ppc64le ? I'm unclear whether either your >> proposal or mine actually works correctly for a hotspot-only build. But >> maybe we just don't care about builds not done via configure any more. >> > > It does. Different logic is employed for a configure build (which > sets various variables, including ARCH, in hotspot-spec.gmk) and > a HotSpot-only build which just use makefiles. If ARCH is not set > when we get to the HotSpot build, as in the latter, this block > in make/linux/makefiles/defs.make is used: > > ifndef ARCH > ARCH := $(shell uname -m) > # Fold little endian PowerPC64 into big-endian (if ARCH is set in > # hotspot-spec.gmk, this will be done by the configure script). > ifeq ($(ARCH),ppc64le) > ARCH := ppc64 > endif > endif > > This was added as part of: > > 8036767: PPC64: Support for little endian execution model I don't know if I already had this conversation but it strikes me as really bizarre that the PPC64 port uses two different ARCH values depending on whether it is a configure-based build or not! ??? That aside if ARCH == ppc64 from uname then: - SRCARCH = ARCH/ppc64 = ppc - BUILDARCH = ppc64 and so the same fix as above would work for this case. > so our addition to hotspot-spec.gmk is just to do the same as this > block for configure builds. > > It was unneeded before because configure would just set the arch > to ppc64 for the entire build, not just HotSpot. AFAICS it set it to ppc not ppc64. David ----- >> Thanks, >> David >> >> >> Given the LIBARCH switcheroo that happens in hotspot/make/def.make, why >> bother also doing the switcheroo in >> /common/autoconf/hotspot-spec.gmk.in when you could just do >> everything in hotspot/make/defs >> >>> David >>> ----- >>> >>> >>>> Thanks, >>>> >> > From staffan.larsen at oracle.com Fri Feb 27 09:15:27 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 27 Feb 2015 10:15:27 +0100 Subject: RFR (L): 8068685 - [TESTBUG] Ensure @library works in jtreg -agentvm mode In-Reply-To: <54EF7F75.7030808@oracle.com> References: <54ECE2EF.4040805@oracle.com> <54ED55C8.9030602@oracle.com> <54EDD15F.9030506@oracle.com> <62229346-9E4F-4F0E-880F-E99ED6A64EFB@oracle.com> <54EED5E5.6040706@oracle.com> <54EF7F75.7030808@oracle.com> Message-ID: You are right that this is a risk we are taking. Tests that leave the JVM in an un-clean state should be running in main/othervm mode to isolate them. It should be noted that if a test fails, then jtreg will /not/ reuse that JVM since it can be an unknown state. Still, I?m guessing that we will see some initial problems with tests that need to be isolated. It would be good to run through the tests in agent mode a fair amount of times on all platforms (say 20? - easy to do with Remote Build and Test) before we do this change to shake out any obvious problems. I think the increased speed of the tests is still worth the effort to clean up and isolate some of the tests. /Staffan > On 26 feb 2015, at 21:17, David Holmes wrote: > > I've been thinking more about this change based on Staffan's clarification of how "othervm" is the current default for testing. I think the move to agentvm is very risky and may result in very unpredictable test results. The problem being that tests no longer start out in a clean VM with a pristine state - this can impact many things that might affect how some of the tests execute. And the problems may vary depending on exactly how the tests are run, the concurrency level and number of agent VMs in use. There may not be any guarantee that the same jtreg command line will result in the same tests being executed in the same sequence on the same agent VMs. > > It may be that the introduction of "main/othervm" in some tests was already an indication of this problem. But the real problem may be the interaction between tests. > > David > > On 26/02/2015 6:14 PM, David Holmes wrote: >> Hi Staffan, >> >> On 26/02/2015 6:00 PM, Staffan Larsen wrote: >>> >>>> On 25 feb 2015, at 14:42, George Triantafillou >>>> >>> > wrote: >>>> >>>> Hi David, >>>> >>>> Thanks for your review. Comments inline: >>>> >>>> On 2/24/2015 11:55 PM, David Holmes wrote: >>>>> On 25/02/2015 6:45 AM, George Triantafillou wrote: >>>>>> Please review this fix for JDK-8068685: >>>>>> >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8068685 >>>>>> webrev: http://cr.openjdk.java.net/~gtriantafill/8068685/webrev.00 >>>>>> >>>>>> >>>>>> "@build com.oracle.java.testlibrary.*" was added to all relevant >>>>>> tests, >>>>> >>>>> I thought we had an RFE open against jtreg to avoid the need to do >>>>> this, but it seems I was mistaken. :( >>>>> >>>>> Most of the additions to @build seem okay. A few minor issues: >>>>> >>>>> --- old/test/compiler/whitebox/ForceNMethodSweepTest.java 2015-02-24 >>>>> 10:31:03.991071066 -0800 >>>>> +++ new/test/compiler/whitebox/ForceNMethodSweepTest.java 2015-02-24 >>>>> 10:31:03.617052982 -0800 >>>>> @@ -35,6 +35,9 @@ >>>>> * @test >>>>> * @bug 8059624 8064669 >>>>> * @library /testlibrary /../../test/lib >>>>> + * @build com.oracle.java.testlibrary.* ForceNMethodSweepTest >>>>> + * @ignore 8066998 >>>>> + * @library /testlibrary /../../test/lib >>>>> * @build ForceNMethodSweepTest >>>>> >>>>> The second @library shouldn't have been added. >>>> Good catch, thanks. Changed. >>>> >>>>> >>>>> --- old/test/gc/g1/TestStringSymbolTableStats.java 2015-02-24 >>>>> 10:32:28.209143019 -0800 >>>>> +++ new/test/gc/g1/TestStringSymbolTableStats.java 2015-02-24 >>>>> 10:32:27.855125901 -0800 >>>>> @@ -22,11 +22,13 @@ >>>>> */ >>>>> >>>>> /* >>>>> - * @test TestStringSymbolTableStats.java >>>>> + * @test TestStringSymbolTableStats >>>>> >>>>> Why did you change the @test? I see a lot of unchanged @test foo.java. >>>> According to the jtreg tag >>>> spechttp://openjdk.java.net/jtreg/tag-spec.html, either way is >>>> correct. The only tests that were considered for this change included >>>> "@library /testlibrary", so I changed this one for consistency with >>>> other tests that I've written. I'll change it back if it's a concern. >>>>> >>>>> >>>>>> which resulted in longer test execution times. In order to offset >>>>>> these >>>>>> longer test execution times and to support running jtreg in -agentvm >>>>>> mode, the following changes were made: >>>>>> >>>>>> test/Makefile: added -agentvm option >>>>> >>>>> I'm unclear exactly what this buys us - do we just save on the >>>>> startup costs of new vms running jtreg? I thought the default was >>>>> samevm anyway? >>>>> >>>>> Also does this mean that all VMs will share a single copy of the >>>>> testlibrary or will we still have a copy per test that gets built >>>>> each time? >>>> The jtreg command >>>> helphttp://openjdk.java.net/jtreg/command-help.htmldoc states: >>>> >>>> -agentvm "Run tests using a pool of reusable JVMs." >>>> -samevm "If possible, run each test in the same JVM as the JavaTest" >>>> >>>> I'm not really sure how samevm decides "if possible", but the intent >>>> of this change was to explicitly add "@build >>>> com.oracle.java.testlibrary.*" to relevant jtreg runtime tests without >>>> increasing test execution times. The analysis below shows decreased >>>> test execution times using agentvm. >>> >>> Re-reading the documentation, checking the sources and running some >>> experiments show that the default mode for jtreg is not samevm, but >>> othervm. In othervm mode, jtreg will create a new JVM for each test >>> /and/ for each javac invocation. In agentvm mode a pool of JVMs will be >>> reused for both javac and for the tests. When running in agentmode, even >>> if a test says ?main/othervm?, the javac invocation of the test will >>> happen in the agent. So running in agentvm mode saves time even if all >>> tests say ?main/othervm?. >> >> Thanks for clarifying that. It would seem main/othervm is only ever >> needed to override -agentvm or -samevm. That makes sense. >> >> I still wonder how many times the test library gets built per set of >> tests ? :) >> >>> The following passage from the documentation is confusing: >>> >>> ---- >>> Test Mode Options >>> >>> When the JavaTest harness is used to run tests, two possibly different >>> versions of the JDK are used: the JDK version used to run the harness >>> and the JDK version used to run the test(s). The following options >>> provide a means to specify the JDK version used to run the tests. The >>> default is to use the same JDK version (provided by JAVA_HOME) for both >>> the harness and the tests, and for each test to run in its own JVM. >>> ---- >>> >>> Notice how the last sentence seems to begin by saying samevm mode is the >>> default, but its really just talking about the version of the JDK used >>> to for running the tests. The sentence ends by saying (not very >>> explicitly) that othervm is the default mode. I?ll see if we can clarify >>> that. >> >> It is even more confusing if you take into account that with samevm it >> uses the testjdk, but you can also set compilejdk to a different jdk, >> which suggests it will run the tests in the same vm as the harness but >> launch separate vms to do the compilation. >> >> Well now I've said that perhaps not so confusing after all :) >> >> Thanks, >> David >> >>> >>> /Staffan >>> >>> >>>>> >>>>>> test/testlibrary/com/oracle/java/testlibrary/ProcessTools.java: added >>>>>> -classpath since -agentvm passes the classpath differently than >>>>>> -othervm >>>>>> >>>>>> *Testing shows an 11% speed improvement for JPRT execution of the >>>>>> hotspot testset, and a 48% speed improvement for >>>>>> hotspot_runtime*/gc*/compiler*/serviceability* tests.** >>>>>> >>>>>> *Note that some tests required the explicit addition of -othervm in >>>>>> order for the tests to pass. In addition, a number of gc, compiler >>>>>> and >>>>>> runtime tests were modified with @run so they would run successfully >>>>>> with -agentvm. Consequently, reviews from members of the compiler, >>>>>> gc, >>>>>> runtime, and serviceability teams would be very helpful. >>>>> >>>>> I'm unclear about the need for some of the othervm changes. I would >>>>> only expect othervm to be needed if passing -XX options via @run ?? >>>> I added @run to some tests, and some of them failed with -agentvm >>>> until I added -othervm. >>>> >>>> -George >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Thanks to Erik Helin for providing a solution for passing classpath >>>>>> with >>>>>> -agentvm. >>>>>> >>>>>> The fix was tested locally on Linux with jtreg and on all platforms >>>>>> with >>>>>> the JPRT hotspot testset.* >>>>>> * >>>>>> Thanks. >>>>>> >>>>>> -George >>> From adinn at redhat.com Fri Feb 27 09:21:38 2015 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 27 Feb 2015 09:21:38 +0000 Subject: Notification about AARCH64 open port merge to jdk9/dev In-Reply-To: <54EF8F4A.40006@oracle.com> References: <54EF8F4A.40006@oracle.com> Message-ID: <54F03722.1040609@redhat.com> On 26/02/15 21:25, Vladimir Kozlov wrote: > We are finishing Oracle's internal testing of AARCH64 open port [1]. > I synced staging repo [2] with latest jdk9/dev sources today. The plan > is to merge AARCH64 sources into jdk9/dev next week. > > I was asked to send this notice to let people test sources in stage > repository before I push them into jdk9. I tried rebuilding on AArch64 and immediately encountered a problem with the AArch64 ad file. This appears to be caused by: 8068977: Remove unused sun.misc.Unsafe prefetch intrinsic support which (amongst other things) removed PrefetchRead/Write nodes. However AArch64 still includes a rule for PrefetchRead/Write. I'm still looking at how to fix both this problem and whatever else may be broken once it is fixed (no doubt there /will be/ other breakages). Previously when pulling upstream changes down into the aarch64-port repo we had to trawl through the change sets identifying and reapplying x86_64-specific updates to the AArch64 tree. The same action will be required with this merge upstream. I don't suppose this requires us to delay the merge if x86 builds and passes all tests -- Andrew Haley may have more to say on that front. regards, Andrew Dinn ----------- From magnus.ihse.bursie at oracle.com Fri Feb 27 09:43:44 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 27 Feb 2015 10:43:44 +0100 Subject: RFR: JDK-8072842 Add support for building native JTReg tests In-Reply-To: <54EEE6A6.8050103@oracle.com> References: <54DA146D.3060904@oracle.com> <54DAB1CE.70506@oracle.com> <54DB0E31.3010201@oracle.com> <54DB1175.6030700@oracle.com> <54DB125D.2070706@oracle.com> <54DB1528.4030708@oracle.com> <324EF37C-3FD2-4B8A-A509-D7315889D8DE@oracle.com> <54DB39C2.5010607@oracle.com> <31B825DC-DFD2-4EC2-81AD-9BF0FC3364CC@oracle.com> <54EDB038.4000502@oracle.com> <54EEE6A6.8050103@oracle.com> Message-ID: <54F03C50.7040001@oracle.com> On 2015-02-26 10:25, Erik Joelsson wrote: > Hello Magnus, > > Overall looks good. I would prefer if some of the longer lines in > Main.gmk were split as it's a file I often need to read. In MakeBase, > the definition of dups, I thought we (informally) agreed to start such > macro definitions with a newline to make them stand out more from > normal variable declarations? I had forgot about that; I just copied the pattern of the macros that was already in place. I have now updated dups to use the newline format. I also updated the old macros to follow this rule. All the new lines in MakeBase should now be shorter than 80 chars. New webrev: http://cr.openjdk.java.net/~ihse/JDK-8072842-build-native-jtreg-tests/webrev.03 /Magnus From aph at redhat.com Fri Feb 27 10:32:59 2015 From: aph at redhat.com (Andrew Haley) Date: Fri, 27 Feb 2015 10:32:59 +0000 Subject: [aarch64-port-dev ] Notification about AARCH64 open port merge to jdk9/dev In-Reply-To: <54F03722.1040609@redhat.com> References: <54EF8F4A.40006@oracle.com> <54F03722.1040609@redhat.com> Message-ID: <54F047DB.3060706@redhat.com> On 27/02/15 09:21, Andrew Dinn wrote: > On 26/02/15 21:25, Vladimir Kozlov wrote: >> We are finishing Oracle's internal testing of AARCH64 open port [1]. >> I synced staging repo [2] with latest jdk9/dev sources today. The plan >> is to merge AARCH64 sources into jdk9/dev next week. >> >> I was asked to send this notice to let people test sources in stage >> repository before I push them into jdk9. > > I tried rebuilding on AArch64 and immediately encountered a problem with > the AArch64 ad file. This appears to be caused by: > > 8068977: Remove unused sun.misc.Unsafe prefetch intrinsic support > > which (amongst other things) removed PrefetchRead/Write nodes. However > AArch64 still includes a rule for PrefetchRead/Write. > > I'm still looking at how to fix both this problem and whatever else may > be broken once it is fixed (no doubt there /will be/ other breakages). > > Previously when pulling upstream changes down into the aarch64-port repo > we had to trawl through the change sets identifying and reapplying > x86_64-specific updates to the AArch64 tree. The same action will be > required with this merge upstream. I don't suppose this requires us to > delay the merge if x86 builds and passes all tests -- Andrew Haley may > have more to say on that front. I'm happy to take advice. Will it really require Oracle to start all their testing again if we fix the AArch64 build by touching only the AArch64- specific directories? Andrew. From volker.simonis at gmail.com Fri Feb 27 10:47:07 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 27 Feb 2015 11:47:07 +0100 Subject: Notification about AARCH64 open port merge to jdk9/dev In-Reply-To: <54EF8F4A.40006@oracle.com> References: <54EF8F4A.40006@oracle.com> Message-ID: Hi Vladimir, thanks for the heads-up. The aarch64-port/stage repository currently builds cleanly on Linux/ppc64 and AIX. Regards, Volker On Thu, Feb 26, 2015 at 10:25 PM, Vladimir Kozlov wrote: > Hi, > > We are finishing Oracle's internal testing of AARCH64 open port [1]. > I synced staging repo [2] with latest jdk9/dev sources today. The plan is to > merge AARCH64 sources into jdk9/dev next week. > > I was asked to send this notice to let people test sources in stage > repository before I push them into jdk9. > > Regards, > Vladimir > > 1. JEP 237: Linux/AArch64 Port > https://bugs.openjdk.java.net/browse/JDK-8044552 > > 2. http://hg.openjdk.java.net/aarch64-port/stage From goetz.lindenmaier at sap.com Fri Feb 27 11:59:29 2015 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 27 Feb 2015 11:59:29 +0000 Subject: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. In-Reply-To: <5FA0520E-B67D-413F-A08F-5CE6BD8FE45F@oracle.com> References: <4295855A5C1DE049A61835A1887419CC2CF9615F@DEWDFEMB12A.global.corp.sap> <70B02DBE-E246-45F9-89C7-898881B0C69A@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF96468@DEWDFEMB12A.global.corp.sap> <65A32AAF-F514-4E10-AF4A-DA04F41F57BF@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF967DF@DEWDFEMB12A.global.corp.sap> <5FA0520E-B67D-413F-A08F-5CE6BD8FE45F@oracle.com> Message-ID: <4295855A5C1DE049A61835A1887419CC2CF99AFD@DEWDFEMB12A.global.corp.sap> Hi Kim, I started to fix the issues you noted, but I'm not sure about this one: > - Result of final jio_snprintf is not checked. I think it's on purpose that the result is not checked. In case of an error of the VM, one wants to see as much information as possible. The result of get_core_path is only used for printing, and printing a truncated path still might help to find the core. That's also the reason to return strlen and not the result of jio_snprintf. Note that jio_snprintf always terminates strings and returns -1 on error. Best regards, Goetz. -----Original Message----- From: Kim Barrett [mailto:kim.barrett at oracle.com] Sent: Thursday, February 26, 2015 11:25 PM To: Lindenmaier, Goetz Cc: hotspot-dev Source Developers Subject: Re: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. On Feb 19, 2015, at 5:34 AM, Lindenmaier, Goetz wrote: >> src/os/linux/vm/os_linux.cpp >> 6028 int written; >> ... >> 6050 if ((written >= 0) && ((size_t)written < bufferSize) && >> 6051 (pid_pos == NULL) && (core_pattern[0] != '|')) { >> >> The real problem here is the value of "written", which is the result >> of a call to jio_snprintf, is not being checked for failure. Clearly >> "written" should be of signed type because of its value, but the other >> changes here just continue to mask the lack of error checking. > > os_linux.cpp: > - I adapted the type to ptrdiff_t. Thanks, that looks good. > - I implemented error handling as where current directory can not be read. 5999 // Returns 0 and sets buffer to the empty string in case of failure. 6000 int os::get_core_path(char* buffer, size_t bufferSize) { ... 6008 if (bufferSize == 0) { return 0; } ... 6052 if (written < 0) { 6053 assert(false, "Could not write core_pattern to buffer"); 6054 buffer[0] = '\0'; 6055 return 0; 6056 } Based on the API, I think the intent (or at least the stylistically consistent behavior) is to have get_core_path return -1 to indicate failure, with the buffer contents unspecified in that case. The one caller of this function would operate correctly with that behavior. So rather than documenting this variant's error behavior, I think the declaration in runtime/os.hpp should be augmented with error behavior, and I think it ought to return -1 for errors. The assert(false, ...) is inappropriate. asserts should not be used for reporting external issues of this sort. Similarly for the earlier pre-existing assert on the result of get_current_directory. Just return the error flag. There are more pre-existing error checking bugs here that I'm going to suggest you not try to fix as part of this change set, but instead report as a new bug. Specific things I noticed - Result of final jio_snprintf is not checked. - Result of ::close() is not checked. Consider EINTR. - Result of ::read() is not checked. I suspect the last two are endemic in this code base. And every platform-specific implementation of get_core_path has similar error checking issues in varying degrees. (I looked at all of them and quickly spotted bugs in each one.) ------------------------------------------------------------------------------ src/share/vm/opto/graphKit.cpp 3048 if (spec_obj_type != NULL || (data != NULL)) { Please use consistent parenthesization for the two sides of the ||. >> --------------------------------------------------------------------------- >> src/share/vm/gc_implementation/g1/concurrentMark.cpp >> 2173 #ifndef PRODUCT >> 2174 if (G1StressConcRegionFreeing) { >> 2175 for (uintx i = 0; i < G1StressConcRegionFreeingDelayMillis; ++i) { >> 2176 os::sleep(Thread::current(), (jlong) 1, false); >> 2177 } >> 2178 } >> 2179 #endif >> >> The #ifndef here is the kind of workaround for the warning that I >> really dislike. > > You're right, that #define is not nice. And yes, the code you propose > is better. But here I don't feel like changing it, as I don't know > what was intended by the code. Is it used at all? Does Oracle have a > test that depends on it? Anyways, if the default is 0, it's off per > default if somebody enables G1StressConcRegionFreeing, which I also > consider a strange behaviour. The code was added with 6977804: G1: > remove the zero-filling thread: > http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/rev/0fa27f37d4d4 I can't > find the review thread in the gc mail archive. There is only the > submit: > http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2011-January/002243.html I still don't like it, but agree the #ifndef is the appropriate change for this changeset. Maybe a followup RFE suggesting cleanup of the loop? From vladimir.kozlov at oracle.com Fri Feb 27 16:58:17 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 27 Feb 2015 08:58:17 -0800 Subject: Notification about AARCH64 open port merge to jdk9/dev In-Reply-To: References: <54EF8F4A.40006@oracle.com> Message-ID: <54F0A229.40706@oracle.com> Thank you, Volker Vladimir On 2/27/15 2:47 AM, Volker Simonis wrote: > Hi Vladimir, > > thanks for the heads-up. > > The aarch64-port/stage repository currently builds cleanly on > Linux/ppc64 and AIX. > > Regards, > Volker > > > On Thu, Feb 26, 2015 at 10:25 PM, Vladimir Kozlov > wrote: >> Hi, >> >> We are finishing Oracle's internal testing of AARCH64 open port [1]. >> I synced staging repo [2] with latest jdk9/dev sources today. The plan is to >> merge AARCH64 sources into jdk9/dev next week. >> >> I was asked to send this notice to let people test sources in stage >> repository before I push them into jdk9. >> >> Regards, >> Vladimir >> >> 1. JEP 237: Linux/AArch64 Port >> https://bugs.openjdk.java.net/browse/JDK-8044552 >> >> 2. http://hg.openjdk.java.net/aarch64-port/stage From vladimir.kozlov at oracle.com Fri Feb 27 16:59:28 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 27 Feb 2015 08:59:28 -0800 Subject: Notification about AARCH64 open port merge to jdk9/dev In-Reply-To: <54F03722.1040609@redhat.com> References: <54EF8F4A.40006@oracle.com> <54F03722.1040609@redhat.com> Message-ID: <54F0A270.8080708@oracle.com> Thank you for letting us know, Andrew. I will file a bug and will fix it before push. Thanks, Vladimir On 2/27/15 1:21 AM, Andrew Dinn wrote: > On 26/02/15 21:25, Vladimir Kozlov wrote: >> We are finishing Oracle's internal testing of AARCH64 open port [1]. >> I synced staging repo [2] with latest jdk9/dev sources today. The plan >> is to merge AARCH64 sources into jdk9/dev next week. >> >> I was asked to send this notice to let people test sources in stage >> repository before I push them into jdk9. > > I tried rebuilding on AArch64 and immediately encountered a problem with > the AArch64 ad file. This appears to be caused by: > > 8068977: Remove unused sun.misc.Unsafe prefetch intrinsic support > > which (amongst other things) removed PrefetchRead/Write nodes. However > AArch64 still includes a rule for PrefetchRead/Write. > > I'm still looking at how to fix both this problem and whatever else may > be broken once it is fixed (no doubt there /will be/ other breakages). > > Previously when pulling upstream changes down into the aarch64-port repo > we had to trawl through the change sets identifying and reapplying > x86_64-specific updates to the AArch64 tree. The same action will be > required with this merge upstream. I don't suppose this requires us to > delay the merge if x86 builds and passes all tests -- Andrew Haley may > have more to say on that front. > > regards, > > > Andrew Dinn > ----------- > From mikhailo.seledtsov at oracle.com Fri Feb 27 17:03:14 2015 From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov) Date: Fri, 27 Feb 2015 09:03:14 -0800 Subject: RFR (L): 8068685 - [TESTBUG] Ensure @library works in jtreg -agentvm mode In-Reply-To: References: <54ECE2EF.4040805@oracle.com> <54ED55C8.9030602@oracle.com> <54EDD15F.9030506@oracle.com> <62229346-9E4F-4F0E-880F-E99ED6A64EFB@oracle.com> <54EED5E5.6040706@oracle.com> <54EF7F75.7030808@oracle.com> Message-ID: <54F0A352.3050809@oracle.com> I agree with Staffan that the kind of increase in text execution speed is worth the effort and risk. Also, the reversal of this change is only a single line of code: test/Makefile JTREG_BASIC_OPTIONS += -agentvm The rest of the changes will not harm in any way, and will still be helpful for people or systems that explicitly specify "-agentvm" option when running the tests. Perhaps, George could first push all the changes except for the "-agentvm" change; then run the RBT tests as Staffan recommends; if that is fine and additional issues resolved, include "JTREG_BASIC_OPTIONS += -agentvm" in a separate changeset. Thank you, Misha On 2/27/2015 1:15 AM, Staffan Larsen wrote: > You are right that this is a risk we are taking. Tests that leave the JVM in an un-clean state should be running in main/othervm mode to isolate them. It should be noted that if a test fails, then jtreg will /not/ reuse that JVM since it can be an unknown state. Still, I?m guessing that we will see some initial problems with tests that need to be isolated. It would be good to run through the tests in agent mode a fair amount of times on all platforms (say 20? - easy to do with Remote Build and Test) before we do this change to shake out any obvious problems. I think the increased speed of the tests is still worth the effort to clean up and isolate some of the tests. > > /Staffan > >> On 26 feb 2015, at 21:17, David Holmes wrote: >> >> I've been thinking more about this change based on Staffan's clarification of how "othervm" is the current default for testing. I think the move to agentvm is very risky and may result in very unpredictable test results. The problem being that tests no longer start out in a clean VM with a pristine state - this can impact many things that might affect how some of the tests execute. And the problems may vary depending on exactly how the tests are run, the concurrency level and number of agent VMs in use. There may not be any guarantee that the same jtreg command line will result in the same tests being executed in the same sequence on the same agent VMs. >> >> It may be that the introduction of "main/othervm" in some tests was already an indication of this problem. But the real problem may be the interaction between tests. >> >> David >> >> On 26/02/2015 6:14 PM, David Holmes wrote: >>> Hi Staffan, >>> >>> On 26/02/2015 6:00 PM, Staffan Larsen wrote: >>>>> On 25 feb 2015, at 14:42, George Triantafillou >>>>> >>>> > wrote: >>>>> >>>>> Hi David, >>>>> >>>>> Thanks for your review. Comments inline: >>>>> >>>>> On 2/24/2015 11:55 PM, David Holmes wrote: >>>>>> On 25/02/2015 6:45 AM, George Triantafillou wrote: >>>>>>> Please review this fix for JDK-8068685: >>>>>>> >>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8068685 >>>>>>> webrev: http://cr.openjdk.java.net/~gtriantafill/8068685/webrev.00 >>>>>>> >>>>>>> >>>>>>> "@build com.oracle.java.testlibrary.*" was added to all relevant >>>>>>> tests, >>>>>> I thought we had an RFE open against jtreg to avoid the need to do >>>>>> this, but it seems I was mistaken. :( >>>>>> >>>>>> Most of the additions to @build seem okay. A few minor issues: >>>>>> >>>>>> --- old/test/compiler/whitebox/ForceNMethodSweepTest.java 2015-02-24 >>>>>> 10:31:03.991071066 -0800 >>>>>> +++ new/test/compiler/whitebox/ForceNMethodSweepTest.java 2015-02-24 >>>>>> 10:31:03.617052982 -0800 >>>>>> @@ -35,6 +35,9 @@ >>>>>> * @test >>>>>> * @bug 8059624 8064669 >>>>>> * @library /testlibrary /../../test/lib >>>>>> + * @build com.oracle.java.testlibrary.* ForceNMethodSweepTest >>>>>> + * @ignore 8066998 >>>>>> + * @library /testlibrary /../../test/lib >>>>>> * @build ForceNMethodSweepTest >>>>>> >>>>>> The second @library shouldn't have been added. >>>>> Good catch, thanks. Changed. >>>>> >>>>>> --- old/test/gc/g1/TestStringSymbolTableStats.java 2015-02-24 >>>>>> 10:32:28.209143019 -0800 >>>>>> +++ new/test/gc/g1/TestStringSymbolTableStats.java 2015-02-24 >>>>>> 10:32:27.855125901 -0800 >>>>>> @@ -22,11 +22,13 @@ >>>>>> */ >>>>>> >>>>>> /* >>>>>> - * @test TestStringSymbolTableStats.java >>>>>> + * @test TestStringSymbolTableStats >>>>>> >>>>>> Why did you change the @test? I see a lot of unchanged @test foo.java. >>>>> According to the jtreg tag >>>>> spechttp://openjdk.java.net/jtreg/tag-spec.html, either way is >>>>> correct. The only tests that were considered for this change included >>>>> "@library /testlibrary", so I changed this one for consistency with >>>>> other tests that I've written. I'll change it back if it's a concern. >>>>>> >>>>>>> which resulted in longer test execution times. In order to offset >>>>>>> these >>>>>>> longer test execution times and to support running jtreg in -agentvm >>>>>>> mode, the following changes were made: >>>>>>> >>>>>>> test/Makefile: added -agentvm option >>>>>> I'm unclear exactly what this buys us - do we just save on the >>>>>> startup costs of new vms running jtreg? I thought the default was >>>>>> samevm anyway? >>>>>> >>>>>> Also does this mean that all VMs will share a single copy of the >>>>>> testlibrary or will we still have a copy per test that gets built >>>>>> each time? >>>>> The jtreg command >>>>> helphttp://openjdk.java.net/jtreg/command-help.htmldoc states: >>>>> >>>>> -agentvm "Run tests using a pool of reusable JVMs." >>>>> -samevm "If possible, run each test in the same JVM as the JavaTest" >>>>> >>>>> I'm not really sure how samevm decides "if possible", but the intent >>>>> of this change was to explicitly add "@build >>>>> com.oracle.java.testlibrary.*" to relevant jtreg runtime tests without >>>>> increasing test execution times. The analysis below shows decreased >>>>> test execution times using agentvm. >>>> Re-reading the documentation, checking the sources and running some >>>> experiments show that the default mode for jtreg is not samevm, but >>>> othervm. In othervm mode, jtreg will create a new JVM for each test >>>> /and/ for each javac invocation. In agentvm mode a pool of JVMs will be >>>> reused for both javac and for the tests. When running in agentmode, even >>>> if a test says ?main/othervm?, the javac invocation of the test will >>>> happen in the agent. So running in agentvm mode saves time even if all >>>> tests say ?main/othervm?. >>> Thanks for clarifying that. It would seem main/othervm is only ever >>> needed to override -agentvm or -samevm. That makes sense. >>> >>> I still wonder how many times the test library gets built per set of >>> tests ? :) >>> >>>> The following passage from the documentation is confusing: >>>> >>>> ---- >>>> Test Mode Options >>>> >>>> When the JavaTest harness is used to run tests, two possibly different >>>> versions of the JDK are used: the JDK version used to run the harness >>>> and the JDK version used to run the test(s). The following options >>>> provide a means to specify the JDK version used to run the tests. The >>>> default is to use the same JDK version (provided by JAVA_HOME) for both >>>> the harness and the tests, and for each test to run in its own JVM. >>>> ---- >>>> >>>> Notice how the last sentence seems to begin by saying samevm mode is the >>>> default, but its really just talking about the version of the JDK used >>>> to for running the tests. The sentence ends by saying (not very >>>> explicitly) that othervm is the default mode. I?ll see if we can clarify >>>> that. >>> It is even more confusing if you take into account that with samevm it >>> uses the testjdk, but you can also set compilejdk to a different jdk, >>> which suggests it will run the tests in the same vm as the harness but >>> launch separate vms to do the compilation. >>> >>> Well now I've said that perhaps not so confusing after all :) >>> >>> Thanks, >>> David >>> >>>> /Staffan >>>> >>>> >>>>>>> test/testlibrary/com/oracle/java/testlibrary/ProcessTools.java: added >>>>>>> -classpath since -agentvm passes the classpath differently than >>>>>>> -othervm >>>>>>> >>>>>>> *Testing shows an 11% speed improvement for JPRT execution of the >>>>>>> hotspot testset, and a 48% speed improvement for >>>>>>> hotspot_runtime*/gc*/compiler*/serviceability* tests.** >>>>>>> >>>>>>> *Note that some tests required the explicit addition of -othervm in >>>>>>> order for the tests to pass. In addition, a number of gc, compiler >>>>>>> and >>>>>>> runtime tests were modified with @run so they would run successfully >>>>>>> with -agentvm. Consequently, reviews from members of the compiler, >>>>>>> gc, >>>>>>> runtime, and serviceability teams would be very helpful. >>>>>> I'm unclear about the need for some of the othervm changes. I would >>>>>> only expect othervm to be needed if passing -XX options via @run ?? >>>>> I added @run to some tests, and some of them failed with -agentvm >>>>> until I added -othervm. >>>>> >>>>> -George >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> Thanks to Erik Helin for providing a solution for passing classpath >>>>>>> with >>>>>>> -agentvm. >>>>>>> >>>>>>> The fix was tested locally on Linux with jtreg and on all platforms >>>>>>> with >>>>>>> the JPRT hotspot testset.* >>>>>>> * >>>>>>> Thanks. >>>>>>> >>>>>>> -George From adinn at redhat.com Fri Feb 27 17:10:47 2015 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 27 Feb 2015 17:10:47 +0000 Subject: Notification about AARCH64 open port merge to jdk9/dev In-Reply-To: <54F0A270.8080708@oracle.com> References: <54EF8F4A.40006@oracle.com> <54F03722.1040609@redhat.com> <54F0A270.8080708@oracle.com> Message-ID: <54F0A517.9030101@redhat.com> Hi Vladimir, On 27/02/15 16:59, Vladimir Kozlov wrote: > Thank you for letting us know, Andrew. > I will file a bug and will fix it before push. Well, before you do that -- as Andrew suggested -- sibce x86 and ppc are ok we could always push now and then fix the AArch64 code once it is in JDK9. What do you think is best? I have now worked through all the upstream change sets. There are only appear to be a small number of relevant ones (with the following ids): 8059606 8069230 8068976 8068977 8072911 8071805 I have updated hotspot/src/cpu/aarch64 accordingly but am seeing errors when I run the resulting image. I'll post the patches when I get it working -- probably on Monday. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters (USA), Michael O'Neill (Ireland) From max.ockner at oracle.com Fri Feb 27 17:36:11 2015 From: max.ockner at oracle.com (Max Ockner) Date: Fri, 27 Feb 2015 12:36:11 -0500 Subject: RFR: 8013393: Merge templateTable_x86 32 and 64 bit files into one file. Message-ID: <54F0AB0B.5090904@oracle.com> Hello all, Please review this change which involves merging 32 and 64 bit interpreter files. Bug ID: 8013393 Webrev: cr.openjdk.java.net/~coleenp/8013393 Summary: templateTable_x86_64.cpp and templateTable_x86_32.cpp have been merged into one file*. These files originally shared thousands of lines of duplicate code. There were also many nearly identical sections of code which differed only in register usage (example: rsi vs. r13) or in the usage of nearly identical functions (example: movptr vs. movq/movl). Given that (1) new bytecodes could be added soon, and (2) these files have been tormenting Coleen for years, this change seems overdue. *There are currently two files. The updated templateTable_x86.cpp is copied into both templateTable_x86_32.cpp and templateTable_x86_64.cpp to make it easier to review (so the diff is not the entire file). This will be changed back to one file after review. For functions that could be merged, one copy was kept. In some cases, files were merged by factoring out small differences such as register usage (example: rbcp equals r13 or rsi depending on the platform). For functions that could not be merged, the 32 and 64 bit versions are adjacent and are defined conditionally using #ifdef based on the platform. There are still improvements to be made, but they are small and can be filed seperately. Tested with: JPRT UTE nsk.jvmti.testlist Thanks, Max Ockner From vladimir.kozlov at oracle.com Fri Feb 27 17:58:57 2015 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 27 Feb 2015 09:58:57 -0800 Subject: Notification about AARCH64 open port merge to jdk9/dev In-Reply-To: <54F0A517.9030101@redhat.com> References: <54EF8F4A.40006@oracle.com> <54F03722.1040609@redhat.com> <54F0A270.8080708@oracle.com> <54F0A517.9030101@redhat.com> Message-ID: <54F0B061.6080802@oracle.com> Thank you, Andrew Okay, I am making executive :) decision to merge on Monday (unless someone strongly objects until then). Note, I am pushing to jdk9/dev and it will take time before the code will propagate to Hotspot groups repos (could be next Friday or even later). We need the code to be in those repos to push any changes for Hotspot. Best regards, Vladimir On 2/27/15 9:10 AM, Andrew Dinn wrote: > Hi Vladimir, > > On 27/02/15 16:59, Vladimir Kozlov wrote: >> Thank you for letting us know, Andrew. >> I will file a bug and will fix it before push. > > Well, before you do that -- as Andrew suggested -- sibce x86 and ppc are > ok we could always push now and then fix the AArch64 code once it is in > JDK9. What do you think is best? > > I have now worked through all the upstream change sets. There are only > appear to be a small number of relevant ones (with the following ids): > > 8059606 > 8069230 > 8068976 > 8068977 > 8072911 > 8071805 > > I have updated hotspot/src/cpu/aarch64 accordingly but am seeing errors > when I run the resulting image. I'll post the patches when I get it > working -- probably on Monday. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in UK and Wales under Company Registration No. 3798903 > Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters > (USA), Michael O'Neill (Ireland) > From dean.long at oracle.com Fri Feb 27 18:39:43 2015 From: dean.long at oracle.com (Dean Long) Date: Fri, 27 Feb 2015 10:39:43 -0800 Subject: RFR: 8013393: Merge templateTable_x86 32 and 64 bit files into one file. In-Reply-To: <54F0AB0B.5090904@oracle.com> References: <54F0AB0B.5090904@oracle.com> Message-ID: <54F0B9EF.4090800@oracle.com> Hi Max. You could do an automatic merge using something like "diff -w -D LP64 templateTable_x86_32.cpp and templateTable_x86_64.cpp", then compare your improvements to that. That way all the changes would show up in a single diff. Or you could even check in the automatic merge first, to reduce risk, then break up the improvements into smaller pieces. dl On 2/27/2015 9:36 AM, Max Ockner wrote: > Hello all, > Please review this change which involves merging 32 and 64 bit > interpreter files. > > Bug ID: 8013393 > Webrev: cr.openjdk.java.net/~coleenp/8013393 > > Summary: templateTable_x86_64.cpp and templateTable_x86_32.cpp have > been merged into one file*. These files originally shared thousands of > lines of duplicate code. > There were also many nearly identical sections of code which differed > only in register usage (example: rsi vs. r13) or in the usage of > nearly identical functions (example: movptr vs. movq/movl). > Given that (1) new bytecodes could be added soon, and (2) these files > have been tormenting Coleen for years, this change seems overdue. > > *There are currently two files. The updated templateTable_x86.cpp is > copied into both templateTable_x86_32.cpp and templateTable_x86_64.cpp > to make it easier to review (so the diff is not the entire file). This > will be changed back to one file after review. > > For functions that could be merged, one copy was kept. In some cases, > files were merged by factoring out small differences such as register > usage (example: rbcp equals r13 or rsi depending on the platform). For > functions that could not be merged, the 32 and 64 bit versions are > adjacent and are defined conditionally using #ifdef based on the > platform. > > There are still improvements to be made, but they are small and can be > filed seperately. > > Tested with: > JPRT > UTE nsk.jvmti.testlist > > > Thanks, > Max Ockner From gnu.andrew at redhat.com Fri Feb 27 19:06:00 2015 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 27 Feb 2015 14:06:00 -0500 (EST) Subject: RFR (M): 8036767 PPC64: Support for little endian execution model In-Reply-To: <54EFD092.5090007@oracle.com> References: <1424883208.5112.287.camel@ocdc> <1739722263.18761313.1424883425179.JavaMail.zimbra@redhat.com> <54EE8588.8060209@oracle.com> <54EED213.5010006@oracle.com> <128547706.19763273.1425000302044.JavaMail.zimbra@redhat.com> <54EFD092.5090007@oracle.com> Message-ID: <1798541240.20403783.1425063960818.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 27/02/2015 11:25 AM, Andrew Hughes wrote: > > ----- Original Message ----- > >> > >> On 26/02/2015 12:31 PM, David Holmes wrote: > >>> On 26/02/2015 2:57 AM, Andrew Hughes wrote: > >>>>>>> These are the revised versions of the webrevs: > >>>>>>> > >>>>>>> http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/root/ > >>>>>>> http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/jdk/ > >>>>>>> http://cr.openjdk.java.net/~andrew/rh1191652/webrev.02/hotspot/ > >>>>>>> > >>>>>>> (HotSpot is unchanged, dropped the sound changes from JDK) > >>>> > >>>> Ok if I push the jdk and root parts then? I think someone on the Oracle > >>>> HS team (David?) needs to push the HotSpot bit. > >>> > >>> Best to push it all together I think, which I can do through the hs-rt > >>> forest. But first I need to see where things settled with all this :) I > >>> was quite confused by some of the initial suggestions. Will try to get > >>> to this today. > > > > Well, I'd push it all myself if there weren't still restrictions on pushing > > to HotSpot... > > > >> > >> I'm still very confused by these changes and have trouble tracking the > >> values of the various "arch" related variables. If I follow this right > >> presently the only distinction between ppc64 and ppc64le is the value of > >> OPENJDK_TARGET_CPU_ENDIAN. In particular they both use ppc64 as the > >> hotspot LIBARCH value and ppc as the ARCH value. (Aside: so ARCH/ppc64 > >> is either unused or only used by a hotspot-only build?) > >> > >> The desired change is that the top-level architecture (VAR_CPU which > >> becomes OPENJDK_TARGET_CPU) should now be ppc64le not ppc64, but that > >> for hotspot the only difference is LIBARCH becomes ppc64le. So to > >> achieve this hotspot-spec.gmk switches ARCH to be ppc64 instead of the > >> current ppc; and then hotspot's def.make uses that combined with being > >> lttle-endian to reset the LIBARCH to ppc64le. > > > > From ppc64le. Without the override in hotspot-spec.gmk, the HotSpot build > > will get called with ARCH=ppc64le and fail, because make/defs.make will > > set SRCARCH to x86 > > No, ARCH comes from $(OPENJDK_TARGET_CPU_ARCH) which comes from > $VAR_CPU_ARCH which is still ppc, not ppc64le. So SRCARCH will be set to > ppc as per current code. Then BUILDARCH will check LP64 and so become > ppc64. Then you can check endian-ness to define LIBARCH to ppc64le. > Ah, not in 8 where this was tested: ARCH=$(OPENJDK_TARGET_CPU_LEGACY) +# ppc64le uses the HotSpot ppc64 build +ifeq ($(OPENJDK_TARGET_CPU), ppc64le) + ARCH=ppc64 +endif OPENJDK_TARGET_CPU_LEGACY is set to OPENJDK_TARGET_CPU which is ppc64le in this case. 9 changed this with: 8046471: Use OPENJDK_TARGET_CPU_ARCH instead of legacy value for hotspot ARCH So it looks like we're going to end up with three different patches for this issue. > >> This all seems very convoluted! Why can you not simply check the value > >> of BUILD_ARCH for ppc64 and then check the endianess to redefine > >> LIBARCH? That way you don't need to change ARCH as set by > >> hotspot-spec.gmk. > >> > > > > How is this different to what we are doing? > > Because it doesn't require the switcheroo in the hotspot-spec.gmk.in file > So yes, it's not needed on 9. ARCH will be passed to HotSpot as ppc there and then BUILDARCH set to ppc64, then LIBARCH can be changed as: ifeq ($(LIBARCH), ppc64) ifeq ($(OPENJDK_TARGET_CPU_ENDIAN), little) LIBARCH = ppc64le endif endif I don't see this as a huge difference though, and now someone will need to re-test this. > > + # Override LIBARCH for ppc64le > > + ifeq ($(ARCH), ppc64) > > + ifeq ($(OPENJDK_TARGET_CPU_ENDIAN), little) > > + LIBARCH = ppc64le > > + endif > > + endif > > > > Right there; we're checking the endianness to redefine LIBARCH. > > Yes but you can do it based on the value of LIBARCH rather than a > modified ARCH. Yes, with 8046471 in place. Hardly a huge difference though. > > >> Does "uname -m" return ppc64le ? I'm unclear whether either your > >> proposal or mine actually works correctly for a hotspot-only build. But > >> maybe we just don't care about builds not done via configure any more. > >> > > > > It does. Different logic is employed for a configure build (which > > sets various variables, including ARCH, in hotspot-spec.gmk) and > > a HotSpot-only build which just use makefiles. If ARCH is not set > > when we get to the HotSpot build, as in the latter, this block > > in make/linux/makefiles/defs.make is used: > > > > ifndef ARCH > > ARCH := $(shell uname -m) > > # Fold little endian PowerPC64 into big-endian (if ARCH is set in > > # hotspot-spec.gmk, this will be done by the configure script). > > ifeq ($(ARCH),ppc64le) > > ARCH := ppc64 > > endif > > endif > > > > This was added as part of: > > > > 8036767: PPC64: Support for little endian execution model > > I don't know if I already had this conversation but it strikes me as > really bizarre that the PPC64 port uses two different ARCH values > depending on whether it is a configure-based build or not! ??? > It's not just that port. Every build either gets ARCH set by hotspot-spec.gmk (by way of configure) or by uname -m in make/linux/makefiles/defs.make. This is necessary if you're going to allow someone to skip configure and just build HotSpot. If no-one does that any more, then the old stuff that was needed for 7 builds (no configure) could be culled. > That aside if ARCH == ppc64 from uname then: > - SRCARCH = ARCH/ppc64 = ppc > - BUILDARCH = ppc64 > > and so the same fix as above would work for this case. > It doesn't, as I said. It's ppc64le. So the uname override is necessary. For consistency, it probably should now be overridden to be ppc, not ppc64, given the value passed in from configure changed to that in 8046471. > > so our addition to hotspot-spec.gmk is just to do the same as this > > block for configure builds. > > > > It was unneeded before because configure would just set the arch > > to ppc64 for the entire build, not just HotSpot. > > AFAICS it set it to ppc not ppc64. I was referring to: - VAR_CPU=ppc64 + VAR_CPU=ppc64le and in turn OPENJDK_TARGET_CPU_LEGACY, not VAR_CPU_ARCH/OPENJDK_TARGET_CPU_ARCH. > > David > ----- > > > >> Thanks, > >> David > >> > >> > >> Given the LIBARCH switcheroo that happens in hotspot/make/def.make, why > >> bother also doing the switcheroo in > >> /common/autoconf/hotspot-spec.gmk.in when you could just do > >> everything in hotspot/make/defs > >> > >>> David > >>> ----- > >>> > >>> > >>>> Thanks, > >>>> > >> > > > -- Andrew :) 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 PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From coleen.phillimore at oracle.com Fri Feb 27 20:06:56 2015 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 27 Feb 2015 15:06:56 -0500 Subject: RFR: 8013393: Merge templateTable_x86 32 and 64 bit files into one file. In-Reply-To: <54F0B9EF.4090800@oracle.com> References: <54F0AB0B.5090904@oracle.com> <54F0B9EF.4090800@oracle.com> Message-ID: <54F0CE60.9070505@oracle.com> Dean, This merge wasn't automatic in any way, so I don't think what you're proposing makes sense. I think if you look at the webrev you'll see what Max has done. Thanks, Coleen On 2/27/15, 1:39 PM, Dean Long wrote: > Hi Max. You could do an automatic merge using something like "diff -w > -D LP64 templateTable_x86_32.cpp and templateTable_x86_64.cpp", then > compare > your improvements to that. That way all the changes would show up in > a single diff. Or you could even check in the automatic merge first, > to reduce > risk, then break up the improvements into smaller pieces. > > dl > > On 2/27/2015 9:36 AM, Max Ockner wrote: >> Hello all, >> Please review this change which involves merging 32 and 64 bit >> interpreter files. >> >> Bug ID: 8013393 >> Webrev: cr.openjdk.java.net/~coleenp/8013393 >> >> Summary: templateTable_x86_64.cpp and templateTable_x86_32.cpp have >> been merged into one file*. These files originally shared thousands >> of lines of duplicate code. >> There were also many nearly identical sections of code which differed >> only in register usage (example: rsi vs. r13) or in the usage of >> nearly identical functions (example: movptr vs. movq/movl). >> Given that (1) new bytecodes could be added soon, and (2) these files >> have been tormenting Coleen for years, this change seems overdue. >> >> *There are currently two files. The updated templateTable_x86.cpp is >> copied into both templateTable_x86_32.cpp and >> templateTable_x86_64.cpp to make it easier to review (so the diff is >> not the entire file). This will be changed back to one file after >> review. >> >> For functions that could be merged, one copy was kept. In some cases, >> files were merged by factoring out small differences such as register >> usage (example: rbcp equals r13 or rsi depending on the platform). >> For functions that could not be merged, the 32 and 64 bit versions >> are adjacent and are defined conditionally using #ifdef based on the >> platform. >> >> There are still improvements to be made, but they are small and can >> be filed seperately. >> >> Tested with: >> JPRT >> UTE nsk.jvmti.testlist >> >> >> Thanks, >> Max Ockner > From kim.barrett at oracle.com Fri Feb 27 20:34:10 2015 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 27 Feb 2015 15:34:10 -0500 Subject: RFR(M): 8073315: Enable gcc -Wtype-limits and fix upcoming issues. In-Reply-To: <4295855A5C1DE049A61835A1887419CC2CF99AFD@DEWDFEMB12A.global.corp.sap> References: <4295855A5C1DE049A61835A1887419CC2CF9615F@DEWDFEMB12A.global.corp.sap> <70B02DBE-E246-45F9-89C7-898881B0C69A@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF96468@DEWDFEMB12A.global.corp.sap> <65A32AAF-F514-4E10-AF4A-DA04F41F57BF@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF967DF@DEWDFEMB12A.global.corp.sap> <5FA0520E-B67D-413F-A08F-5CE6BD8FE45F@oracle.com> <4295855A5C1DE049A61835A1887419CC2CF99AFD@DEWDFEMB12A.global.corp.sap> Message-ID: <553AC8DA-D454-49AE-9C18-7475F09732FC@oracle.com> On Feb 27, 2015, at 6:59 AM, Lindenmaier, Goetz wrote: > > I started to fix the issues you noted, but I'm not sure about this one: >> - Result of final jio_snprintf is not checked. That was one of the issues I recommended not be fixed as part of this changeset, in part to avoid questions like this. > I think it's on purpose that the result is not checked. In case of an error > of the VM, one wants to see as much information as possible. The result > of get_core_path is only used for printing, and printing a truncated path > still might help to find the core. > That's also the reason to return strlen and not the result of jio_snprintf. > > Note that jio_snprintf always terminates strings and returns -1 on error. jio_snprintf also returns -1 for things other than for truncation. So I disagree with that rationale for not checking the final jio_snprintf result. But as I said, I would prefer to not delay / derail this change set with this largely unrelated discussion. From dean.long at oracle.com Fri Feb 27 23:13:21 2015 From: dean.long at oracle.com (Dean Long) Date: Fri, 27 Feb 2015 15:13:21 -0800 Subject: RFR: 8013393: Merge templateTable_x86 32 and 64 bit files into one file. In-Reply-To: <54F0CE60.9070505@oracle.com> References: <54F0AB0B.5090904@oracle.com> <54F0B9EF.4090800@oracle.com> <54F0CE60.9070505@oracle.com> Message-ID: <54F0FA11.3030903@oracle.com> Hi Coleen. I believe I understand what Max did, and that it was not an automated merge, which to me says that properly reviewing the change requires looking at all 2851 changed lines and mentally deciding if the result is equivalent to the original. What I was suggesting was essentially two things. First, an aid to the reviewer, and second, a way to reduce risk. In the end it's up to the reviewers. If they prefer to see the changes in a single diff, they can compare a single-file automated merge with the single-file result of Max's merge. It doesn't matter if the reviewer does it or Max does it as a convenience. Regarding risk, if the reviewers aren't comfortable deciding that all 2851 are correct, the changes could be staged into several pieces, and the first piece could be an automated merge that would be cleaned up later, on the assumption that an automated merge could be considered trivially correct and therefore not risky. I hope that clears up my somewhat terse comments below. dl On 2/27/2015 12:06 PM, Coleen Phillimore wrote: > > Dean, This merge wasn't automatic in any way, so I don't think what > you're proposing makes sense. I think if you look at the webrev > you'll see what Max has done. > Thanks, > Coleen > > On 2/27/15, 1:39 PM, Dean Long wrote: >> Hi Max. You could do an automatic merge using something like "diff >> -w -D LP64 templateTable_x86_32.cpp and templateTable_x86_64.cpp", >> then compare >> your improvements to that. That way all the changes would show up in >> a single diff. Or you could even check in the automatic merge first, >> to reduce >> risk, then break up the improvements into smaller pieces. >> >> dl >> >> On 2/27/2015 9:36 AM, Max Ockner wrote: >>> Hello all, >>> Please review this change which involves merging 32 and 64 bit >>> interpreter files. >>> >>> Bug ID: 8013393 >>> Webrev: cr.openjdk.java.net/~coleenp/8013393 >>> >>> Summary: templateTable_x86_64.cpp and templateTable_x86_32.cpp have >>> been merged into one file*. These files originally shared thousands >>> of lines of duplicate code. >>> There were also many nearly identical sections of code which >>> differed only in register usage (example: rsi vs. r13) or in the >>> usage of nearly identical functions (example: movptr vs. movq/movl). >>> Given that (1) new bytecodes could be added soon, and (2) these >>> files have been tormenting Coleen for years, this change seems overdue. >>> >>> *There are currently two files. The updated templateTable_x86.cpp is >>> copied into both templateTable_x86_32.cpp and >>> templateTable_x86_64.cpp to make it easier to review (so the diff is >>> not the entire file). This will be changed back to one file after >>> review. >>> >>> For functions that could be merged, one copy was kept. In some >>> cases, files were merged by factoring out small differences such as >>> register usage (example: rbcp equals r13 or rsi depending on the >>> platform). For functions that could not be merged, the 32 and 64 bit >>> versions are adjacent and are defined conditionally using #ifdef >>> based on the platform. >>> >>> There are still improvements to be made, but they are small and can >>> be filed seperately. >>> >>> Tested with: >>> JPRT >>> UTE nsk.jvmti.testlist >>> >>> >>> Thanks, >>> Max Ockner >> > From jonathan.gibbons at oracle.com Sat Feb 28 03:32:14 2015 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 27 Feb 2015 19:32:14 -0800 Subject: RFR: JDK-8072842 Add support for building native JTReg tests In-Reply-To: References: <54DA146D.3060904@oracle.com> Message-ID: <54F136BE.9070304@oracle.com> On 02/10/2015 07:10 AM, Staffan Larsen wrote: > To clarify: The restriction in jtreg is that all tests are loaded in separate class loaders (when running in samevm mode). A native library can only be loaded in one class loader at a time. So if two tests tries to load the same library we get errors. It would be possible to change this if samevm mode is removed from jtreg. > > /Staffan Staffan, The restriction to use separate class loaders exists in agentvm mode as well. I don't think it would be advisable to change this, partly because different tests may define the same class, and partly because you want to be able to get rid of classes that are no longer required. -- Jon