From ioi.lam at oracle.com Sun May 1 08:11:51 2016 From: ioi.lam at oracle.com (Ioi Lam) Date: Sun, 01 May 2016 01:11:51 -0700 Subject: RFR [XS] 8155239 [TESTBUG] Simple test setup for JVMTI ClassFileLoadHook In-Reply-To: <57215281.1050304@oracle.com> References: <5720C248.6080902@oracle.com> <5720FF1A.3000907@oracle.com> <57215281.1050304@oracle.com> Message-ID: <5725BA47.70001@oracle.com> Hi, I've posted a new version: http://cr.openjdk.java.net/~iklam/jdk9/8155239_simple_classfileloadhook.v02/ [1] Moved libSimpleClassFileLoadHook.c to testlibrary/jvmti [2] Added comments in ClassFileLoadHook about what it does, with suggestions for good replacement strings ('cellphone'). [3] strdup of CLASS_NAME, FROM and TO I ran with RBT and it passed on all 8 test platforms. Thanks - Ioi On 4/27/16 5:00 PM, Ioi Lam wrote: > Hi Misha, > > Thanks for the review. I'll fix the code as you suggested and post a > new version. > > - Ioo > > On 4/27/16 11:04 AM, mikhailo wrote: >> Hi Ioi, >> >> Great. This is very helpful for the task at hand and more jvmti >> tests to come. >> Overall looks good, and I have couple of comments: >> >> - I recommend moving the libSimpleClassFileLoadHook.c to a >> sub-directory >> under hotpsot/test/testlibrary, such as >> hotpsot/test/testlibrary/jvmti >> >> - libSimpleClassFileLoadHook.c >> init_options(): >> - would it be safer to make a copy of "CLASS_NAME", "FROM" >> and "TO"; I am not sure of the convention >> of ownership of the arguments passed to Agent_Initialize(), >> and who is required to free them >> Just checking as a precaution >> >> ClassFileLoadHook(): >> - please add a brief comment, something like "this hook will >> match the class name to CLASS_NAME, and attempt >> to replace any occurrence of 'FROM' string to 'TO' string" >> >> Thank you, >> Misha >> >> >> On 04/27/2016 06:44 AM, Ioi Lam wrote: >>> Hi, >>> >>> Please review this simple test bug: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8155239 >>> http://cr.openjdk.java.net/~iklam/jdk9/8155239_simple_classfileloadhook.v01/ >>> >>> >>> Testing ClassFileLoadHook is a pain. In many cases, we are not >>> testing CFLH itself, but rather "how does my feature interact with >>> CFLH. One example is the interaction between CDS and CFLH. This RFE >>> makes it easy to write such tests. >>> >>> Please see SimpleClassFileLoadHookTest.java for an example. >>> >>> I've tested under Linux and I am now trying to test under all other >>> platforms. >>> >>> Thanks >>> - Ioi >> > From mikhailo.seledtsov at oracle.com Mon May 2 00:30:26 2016 From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov) Date: Sun, 1 May 2016 17:30:26 -0700 Subject: RFR [XS] 8155239 [TESTBUG] Simple test setup for JVMTI ClassFileLoadHook In-Reply-To: <5725BA47.70001@oracle.com> References: <5720C248.6080902@oracle.com> <5720FF1A.3000907@oracle.com> <57215281.1050304@oracle.com> <5725BA47.70001@oracle.com> Message-ID: Changes look good to me. Misha On 5/1/2016 1:11 AM, Ioi Lam wrote: > Hi, > > I've posted a new version: > > http://cr.openjdk.java.net/~iklam/jdk9/8155239_simple_classfileloadhook.v02/ > > > [1] Moved libSimpleClassFileLoadHook.c to testlibrary/jvmti > [2] Added comments in ClassFileLoadHook about what it does, with > suggestions > for good replacement strings ('cellphone'). > [3] strdup of CLASS_NAME, FROM and TO > > I ran with RBT and it passed on all 8 test platforms. > > Thanks > - Ioi > > On 4/27/16 5:00 PM, Ioi Lam wrote: >> Hi Misha, >> >> Thanks for the review. I'll fix the code as you suggested and post a >> new version. >> >> - Ioo >> >> On 4/27/16 11:04 AM, mikhailo wrote: >>> Hi Ioi, >>> >>> Great. This is very helpful for the task at hand and more jvmti >>> tests to come. >>> Overall looks good, and I have couple of comments: >>> >>> - I recommend moving the libSimpleClassFileLoadHook.c to a >>> sub-directory >>> under hotpsot/test/testlibrary, such as >>> hotpsot/test/testlibrary/jvmti >>> >>> - libSimpleClassFileLoadHook.c >>> init_options(): >>> - would it be safer to make a copy of "CLASS_NAME", "FROM" >>> and "TO"; I am not sure of the convention >>> of ownership of the arguments passed to >>> Agent_Initialize(), and who is required to free them >>> Just checking as a precaution >>> >>> ClassFileLoadHook(): >>> - please add a brief comment, something like "this hook will >>> match the class name to CLASS_NAME, and attempt >>> to replace any occurrence of 'FROM' string to 'TO' string" >>> >>> Thank you, >>> Misha >>> >>> >>> On 04/27/2016 06:44 AM, Ioi Lam wrote: >>>> Hi, >>>> >>>> Please review this simple test bug: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8155239 >>>> http://cr.openjdk.java.net/~iklam/jdk9/8155239_simple_classfileloadhook.v01/ >>>> >>>> >>>> Testing ClassFileLoadHook is a pain. In many cases, we are not >>>> testing CFLH itself, but rather "how does my feature interact with >>>> CFLH. One example is the interaction between CDS and CFLH. This RFE >>>> makes it easy to write such tests. >>>> >>>> Please see SimpleClassFileLoadHookTest.java for an example. >>>> >>>> I've tested under Linux and I am now trying to test under all other >>>> platforms. >>>> >>>> Thanks >>>> - Ioi >>> >> > From stefan.karlsson at oracle.com Mon May 2 08:32:03 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 2 May 2016 10:32:03 +0200 Subject: RFR (XXS): 8155754: Quarantine serviceability/tmtools/jstat/GcTest02.java In-Reply-To: <5723D0C5.6000104@oracle.com> References: <5723D0C5.6000104@oracle.com> Message-ID: <57271083.20001@oracle.com> Looks good. StefanK On 2016-04-29 23:23, Derek White wrote: > JDK-8155570 is a > test bug that is failing intermittently. It is probably an integration > blocker, so *this* issue (8155754) is quarantining the test for now. > > Bug (sub task): https://bugs.openjdk.java.net/browse/JDK-8155754 > Webrev: http://cr.openjdk.java.net/~drwhite/8155754/webrev.01/ > jprt in progress... > > - Derek > > > From stefan.karlsson at oracle.com Mon May 2 09:00:29 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 2 May 2016 11:00:29 +0200 Subject: RFR: 8141501: Problems with BitMap buffer management In-Reply-To: <2CE7A7C6-24BA-4A2D-8DE8-8C01E922EBD4@oracle.com> References: <5720A91A.1020809@oracle.com> <57220EE4.4080007@oracle.com> <2CE7A7C6-24BA-4A2D-8DE8-8C01E922EBD4@oracle.com> Message-ID: <5727172D.601@oracle.com> Hi Kim, Updated webrevs: http://cr.openjdk.java.net/~stefank/8141501/webrev.03.delta http://cr.openjdk.java.net/~stefank/8141501/webrev.03 Comments inlined: On 2016-04-30 19:01, Kim Barrett wrote: >> On Apr 28, 2016, at 9:23 AM, Stefan Karlsson wrote: >> >> Hi all, >> >> I decided to restructure the allocation code a bit to get better separation between the bitmap allocation logic and the actual bitmap memory allocators. >> >> http://cr.openjdk.java.net/~stefank/8141501/webrev.02.delta >> http://cr.openjdk.java.net/~stefank/8141501/webrev.02 > Generally looks good. Thanks. > > Just a few mostly minor comments or suggestions. The only really > important one is about ~G1RegionToSpaceMapper. > > ------------------------------------------------------------------------------ > src/share/vm/c1/c1_GraphBuilder.cpp > 355 void BlockListBuilder::mark_loops() { > 356 ResourceMark rm; > 357 > 358 _active.initialize(BlockBegin::number_of_blocks()); > 359 _visited.initialize(BlockBegin::number_of_blocks()); > > Consider (possibly debug-only) resizing _active and _visited to zero > at the end of the function, to avoid leaving dangling pointers when > the ResourceMark is exited. Done. > > ------------------------------------------------------------------------------ > src/share/vm/c1/c1_Instruction.hpp > 1721 void set_live_in (ResourceBitMap map) { _live_in = map; } > 1722 void set_live_out (ResourceBitMap map) { _live_out = map; } > 1723 void set_live_gen (ResourceBitMap map) { _live_gen = map; } > 1724 void set_live_kill (ResourceBitMap map) { _live_kill = map; } > 1725 void set_fpu_register_usage(ResourceBitMap map) { _fpu_register_usage = map; } > > By-value parameters seem like unnecessary (shallow) copies. Could > these be passed by const-ref? Done. > > ------------------------------------------------------------------------------ > src/share/vm/c1/c1_LinearScan.cpp > 718 block->set_live_in (ResourceBitMap(live_size)); block->live_in().clear(); > 719 block->set_live_out (ResourceBitMap(live_size)); block->live_out().clear(); > > Consider instead > > block->live_in().reinitialize(live_size); > block->live_out().reinitialize(live_size); I intend to remove the call to clear() with the fix for this bug: https://bugs.openjdk.java.net/browse/JDK-8155638 So, I'd like to do this suggestion as a part of that change. > > ------------------------------------------------------------------------------ > src/share/vm/gc/g1/g1CardLiveData.cpp > 400 G1ClearCardLiveDataTask(BitMapView bitmap, size_t num_tasks) : > > Pass bitmap by const-ref? Done. > > ------------------------------------------------------------------------------ > src/share/vm/gc/g1/g1RegionToSpaceMapper.hpp > [Removed] > 65 virtual ~G1RegionToSpaceMapper() { > 66 _commit_map.resize(0, /* in_resource_area */ false); > 67 } > > This changes this base class's destructor from public virtual to > public non-virtual, introducing risk of unintended slicing. Fixed. > > ------------------------------------------------------------------------------ > src/share/vm/utilities/bitMap.hpp > 182 idx_t size_in_bytes() const { return size_in_words() * BytesPerWord; } > > Perhaps instead use > > return calc_size_in_bytes(size()); Done. > > ------------------------------------------------------------------------------ > src/share/vm/utilities/bitMap.hpp > 163 // Protected constructor. > > Mention destructor too? Done. Thanks, StefanK > > ------------------------------------------------------------------------------ > From igor.ignatyev at oracle.com Mon May 2 11:21:09 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 2 May 2016 14:21:09 +0300 Subject: RFR(M) : 8148244 : Finalize and integrate GTest implementation Message-ID: <4E849CF5-6955-4240-BF4F-A104B188AADA@oracle.com> http://cr.openjdk.java.net/~iignatyev/8148244-hotspot/webrev.00 > 615 lines changed: 605 ins; 2 del; 8 mod; http://cr.openjdk.java.net/~iignatyev/8148244-root-wo-gtest/webrev.00/ > 218 lines changed: 209 ins; 0 del; 9 mod; http://cr.openjdk.java.net/~iignatyev/8148244-root/webrev.00/ > 32029 lines changed: 32018 ins; 0 del; 11 mod; Hi all, could you please review this patch which delivers core of JEP 281: HotSpot C++ Unit-Test Framework[1]? in more details, this patch - integrates sources of gtest-1.7.0[2] to /test/fmw/gtest (~32k LOC) - introduces TEST macros (/hotspot/test/native/unittest.hpp) - TEST ? a basic unit test, doesn?t require an inited JVM - TEST_VM ? a test which requires an inited JVM, but expected to leave JVM in a valid state - TEST_OTHER_VM ? a test which requires a clean inited JVM - TEST_VM_ASSERT/TEST_VM_ASSERT_MSG - tests to verify assert, ?death?[3] tests which require inited JVM - contains two tests as smoke tests for the project and examples. new tests should be added to /hotspot/test/native/ using the same directories layout as a corresponding product source files, and have prefix ?test_?, e.g. test/native/runtime/test_os.cpp w/ tests for runtime/test_os.cpp - updates makefiles to build/run tests : to run tests, one should use 'make test TEST=hotspot_gtest? - adds hotspot_gtest to jprt testset more information on the project can be found in JEP 281[1]. please be informed, that existing unit tests (aka internal tests) will be ported into new framework later, this activity is tracking by JDK-8077965[4]. PS This patch relies on JDK-8149591[5] which is under review[6]. Thanks, ? Igor JBS: https://bugs.openjdk.java.net/browse/JDK-8148244 webrevs: root : http://cr.openjdk.java.net/~iignatyev/8148244-root/webrev.00/ w/o gtest : http://cr.openjdk.java.net/~iignatyev/8148244-root-wo-gtest/webrev.00/ hotspot : http://cr.openjdk.java.net/~iignatyev/8148244-hotspot/webrev.00 [1] https://bugs.openjdk.java.net/browse/JDK-8047975 [2] https://github.com/google/googletest/releases/tag/release-1.7.0 [3] https://github.com/google/googletest/blob/master/googletest/docs/V1_7_AdvancedGuide.md#death-tests [4] https://bugs.openjdk.java.net/browse/JDK-8077965 [5] https://bugs.openjdk.java.net/browse/JDK-8149591 [6] http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-April/022937.html From sgehwolf at redhat.com Mon May 2 11:52:11 2016 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 02 May 2016 13:52:11 +0200 Subject: RFR(xs): 8155819: Support non-continuous CodeBlobs in HotSpot broke Zero Message-ID: <1462189931.5579.23.camel@redhat.com> Hi, Could somebody please review and sponsor this trivial Zero build fix. It currently fails to build :( Bug:?https://bugs.openjdk.java.net/browse/JDK-8155819 webrev:?http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8155819/webrev.01/ Once reviewed, I'd need somebody to sponsor this change for me. Thanks, Severin From erik.joelsson at oracle.com Mon May 2 12:04:19 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 2 May 2016 14:04:19 +0200 Subject: RFR(M) : 8148244 : Finalize and integrate GTest implementation In-Reply-To: <4E849CF5-6955-4240-BF4F-A104B188AADA@oracle.com> References: <4E849CF5-6955-4240-BF4F-A104B188AADA@oracle.com> Message-ID: <57274243.9050809@oracle.com> Hello, Build changes look good to me, but I also wrote most of them, except for makefiles/lib/JvmMapfile.gmk line 155. I could not have written that. Please remove. The webrevs seem to be generated against jdk9/hs without the removal of the old build system. I would recommend making that merge and generate new webrevs since makefiles moved around quite a bit. /Erik On 2016-05-02 13:21, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev/8148244-hotspot/webrev.00 >> 615 lines changed: 605 ins; 2 del; 8 mod; > http://cr.openjdk.java.net/~iignatyev/8148244-root-wo-gtest/webrev.00/ >> 218 lines changed: 209 ins; 0 del; 9 mod; > > http://cr.openjdk.java.net/~iignatyev/8148244-root/webrev.00/ >> 32029 lines changed: 32018 ins; 0 del; 11 mod; > Hi all, > > could you please review this patch which delivers core of JEP 281: HotSpot C++ Unit-Test Framework[1]? > in more details, this patch > - integrates sources of gtest-1.7.0[2] to /test/fmw/gtest (~32k LOC) > - introduces TEST macros (/hotspot/test/native/unittest.hpp) > - TEST ? a basic unit test, doesn?t require an inited JVM > - TEST_VM ? a test which requires an inited JVM, but expected to leave JVM in a valid state > - TEST_OTHER_VM ? a test which requires a clean inited JVM > - TEST_VM_ASSERT/TEST_VM_ASSERT_MSG - tests to verify assert, ?death?[3] tests which require inited JVM > - contains two tests as smoke tests for the project and examples. new tests should be added to /hotspot/test/native/ using the same directories layout as a corresponding product source files, and have prefix ?test_?, e.g. test/native/runtime/test_os.cpp w/ tests for runtime/test_os.cpp > - updates makefiles to build/run tests : to run tests, one should use 'make test TEST=hotspot_gtest? > - adds hotspot_gtest to jprt testset > > more information on the project can be found in JEP 281[1]. > > please be informed, that existing unit tests (aka internal tests) will be ported into new framework later, this activity is tracking by JDK-8077965[4]. > > PS This patch relies on JDK-8149591[5] which is under review[6]. > > Thanks, > ? Igor > > JBS: https://bugs.openjdk.java.net/browse/JDK-8148244 > webrevs: > root : http://cr.openjdk.java.net/~iignatyev/8148244-root/webrev.00/ > w/o gtest : http://cr.openjdk.java.net/~iignatyev/8148244-root-wo-gtest/webrev.00/ > hotspot : http://cr.openjdk.java.net/~iignatyev/8148244-hotspot/webrev.00 > > [1] https://bugs.openjdk.java.net/browse/JDK-8047975 > [2] https://github.com/google/googletest/releases/tag/release-1.7.0 > [3] https://github.com/google/googletest/blob/master/googletest/docs/V1_7_AdvancedGuide.md#death-tests > [4] https://bugs.openjdk.java.net/browse/JDK-8077965 > [5] https://bugs.openjdk.java.net/browse/JDK-8149591 > [6] http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-April/022937.html From jesper.wilhelmsson at oracle.com Mon May 2 12:55:06 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 2 May 2016 14:55:06 +0200 Subject: RFR(M) : 8148244 : Finalize and integrate GTest implementation In-Reply-To: <57274243.9050809@oracle.com> References: <4E849CF5-6955-4240-BF4F-A104B188AADA@oracle.com> <57274243.9050809@oracle.com> Message-ID: Even though the comment on line 155 in JvmMapfile.gmk is accurate I agree with removing it. Besides that the change looks good! /Jesper Den 2/5/16 kl. 14:04, skrev Erik Joelsson: > Hello, > > Build changes look good to me, but I also wrote most of them, except for > makefiles/lib/JvmMapfile.gmk line 155. I could not have written that. Please > remove. > > The webrevs seem to be generated against jdk9/hs without the removal of the old > build system. I would recommend making that merge and generate new webrevs since > makefiles moved around quite a bit. > > /Erik > > On 2016-05-02 13:21, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev/8148244-hotspot/webrev.00 >>> 615 lines changed: 605 ins; 2 del; 8 mod; >> http://cr.openjdk.java.net/~iignatyev/8148244-root-wo-gtest/webrev.00/ >>> 218 lines changed: 209 ins; 0 del; 9 mod; >> >> http://cr.openjdk.java.net/~iignatyev/8148244-root/webrev.00/ >>> 32029 lines changed: 32018 ins; 0 del; 11 mod; >> Hi all, >> >> could you please review this patch which delivers core of JEP 281: HotSpot C++ >> Unit-Test Framework[1]? >> in more details, this patch >> - integrates sources of gtest-1.7.0[2] to /test/fmw/gtest (~32k LOC) >> - introduces TEST macros (/hotspot/test/native/unittest.hpp) >> - TEST ? a basic unit test, doesn?t require an inited JVM >> - TEST_VM ? a test which requires an inited JVM, but expected to leave JVM >> in a valid state >> - TEST_OTHER_VM ? a test which requires a clean inited JVM >> - TEST_VM_ASSERT/TEST_VM_ASSERT_MSG - tests to verify assert, ?death?[3] >> tests which require inited JVM >> - contains two tests as smoke tests for the project and examples. new tests >> should be added to /hotspot/test/native/ using the same directories layout as >> a corresponding product source files, and have prefix ?test_?, e.g. >> test/native/runtime/test_os.cpp w/ tests for runtime/test_os.cpp >> - updates makefiles to build/run tests : to run tests, one should use 'make >> test TEST=hotspot_gtest? >> - adds hotspot_gtest to jprt testset >> >> more information on the project can be found in JEP 281[1]. >> >> please be informed, that existing unit tests (aka internal tests) will be >> ported into new framework later, this activity is tracking by JDK-8077965[4]. >> >> PS This patch relies on JDK-8149591[5] which is under review[6]. >> >> Thanks, >> ? Igor >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8148244 >> webrevs: >> root : http://cr.openjdk.java.net/~iignatyev/8148244-root/webrev.00/ >> w/o gtest : >> http://cr.openjdk.java.net/~iignatyev/8148244-root-wo-gtest/webrev.00/ >> hotspot : http://cr.openjdk.java.net/~iignatyev/8148244-hotspot/webrev.00 >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8047975 >> [2] https://github.com/google/googletest/releases/tag/release-1.7.0 >> [3] >> https://github.com/google/googletest/blob/master/googletest/docs/V1_7_AdvancedGuide.md#death-tests >> >> [4] https://bugs.openjdk.java.net/browse/JDK-8077965 >> [5] https://bugs.openjdk.java.net/browse/JDK-8149591 >> [6] http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-April/022937.html > From rickard.backman at oracle.com Mon May 2 13:06:00 2016 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Mon, 2 May 2016 15:06:00 +0200 Subject: RFR(xs): 8155819: Support non-continuous CodeBlobs in HotSpot broke Zero In-Reply-To: <1462189931.5579.23.camel@redhat.com> References: <1462189931.5579.23.camel@redhat.com> Message-ID: <20160502130600.GC22447@rbackman> Looks good. /R On 05/02, Severin Gehwolf wrote: > Hi, > > Could somebody please review and sponsor this trivial Zero build fix. > It currently fails to build :( > > Bug:?https://bugs.openjdk.java.net/browse/JDK-8155819 > webrev:?http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8155819/webrev.01/ > > Once reviewed, I'd need somebody to sponsor this change for me. > > Thanks, > Severin From jesper.wilhelmsson at oracle.com Mon May 2 13:18:24 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 2 May 2016 15:18:24 +0200 Subject: RFR: 8149591 - Prepare hotspot for GTest In-Reply-To: <2E67D611-36FF-4485-9468-7E7A1FC7819F@oracle.com> References: <56BB93D6.3000905@oracle.com> <56BC0BF1.7070506@oracle.com> <2E67D611-36FF-4485-9468-7E7A1FC7819F@oracle.com> Message-ID: Looks good! /Jesper Den 30/4/16 kl. 03:47, skrev Igor Ignatyev: > Hi, > > I?d like to renew this RFR. > > besides updated previous changes, new webrev contains two new things: > - new vm-flag ? ExecutingUnitTests, we use it in debug jvm to print a clean error message (w/o assert, line, file, etc). it is needed to simplify comparing error message in ?death? tests (the tests which intentionally cause crashes/asserts) > - if CreateCoredumpOnCrash is false, we don't determine default core path > > webrev: http://cr.openjdk.java.net/~iignatyev/8149591/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8149591 > > Thanks, > ? Igor > >> On Feb 11, 2016, at 7:20 AM, David Holmes wrote: >> >> Hi Jesper, >> >> On 11/02/2016 5:47 AM, Jesper Wilhelmsson wrote: >>> Hi, >>> >>> Please review this change to prepare the Hotspot code for the Google >>> unit test framework. From the RFE: >>> >>> A few changes are needed in the hotspot code to start using the Google >>> Test framework. >>> >>> 1. The new() operator as defined in allocation.cpp can not be used >>> together with GTest. This needs to be moved to a separate file so that >>> we can avoid compiling it when building the GTest enabled JVM. >> >> I presume that is because GTest will use the real global operator new? >> >> The name of the new file, given it contains new and delete, seems one-sided. But I can't think of anything better. :) >> >>> 2. In management.cpp there is a local variable called err_msg. This >>> variable is shadowing a global variable in debug.hpp. In the GTest work >>> the global err_msg variable is used in the vmassert macro and this >>> creates a conflict with the local variable in management.cpp. >> >> Renaming seems trivially fine. >> >>> 3. If SuppressFatalErrorMessage is set ALL error messages should be >>> suppressed, even the ones in error_is_suppressed() in debug.cpp. >> >> Took me a while to think this one through. Not sure what purpose SuppressFatalErrorMessages is intended to serve. The idea that the VM can just vanish without any kind of message to the user just seems like a bad idea. I wonder if there is a SuppressFatalErrorMessages test somewhere that actually relies on the output from error_is_suppressed to determine that a crash really did happen? ;-) >> >> Cheers, >> David >> >>> This is what is done by this change. >>> >>> RFE: https://bugs.openjdk.java.net/browse/JDK-8149591 >>> Webrev: http://cr.openjdk.java.net/~jwilhelm/8149591/webrev.00/index.html >>> >>> Thanks, >>> /Jesper > From sgehwolf at redhat.com Mon May 2 13:21:58 2016 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 02 May 2016 15:21:58 +0200 Subject: RFR(xs): 8155819: Support non-continuous CodeBlobs in HotSpot broke Zero In-Reply-To: <20160502130600.GC22447@rbackman> References: <1462189931.5579.23.camel@redhat.com> <20160502130600.GC22447@rbackman> Message-ID: <1462195318.5579.29.camel@redhat.com> On Mon, 2016-05-02 at 15:06 +0200, Rickard B?ckman wrote: > Looks good. > > /R Thanks, Rickard. I'd need somebody to sponsor this, please! Cheers, Severin? > On 05/02, Severin Gehwolf wrote: > > > > Hi, > > > > Could somebody please review and sponsor this trivial Zero build > > fix. > > It currently fails to build :( > > > > Bug:?https://bugs.openjdk.java.net/browse/JDK-8155819 > > webrev:?http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8155819/we > > brev.01/ > > > > Once reviewed, I'd need somebody to sponsor this change for me. > > > > Thanks, > > Severin From sgehwolf at redhat.com Mon May 2 14:27:59 2016 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 02 May 2016 16:27:59 +0200 Subject: fastdebug builds broken for jdk9/hs tree? In-Reply-To: <1461936647.3712.41.camel@redhat.com> References: <1461861323.25448.42.camel@redhat.com> <1461915583.3712.5.camel@redhat.com> <57231090.3020704@redhat.com> <1461916596.3712.7.camel@redhat.com> <57231986.9010106@redhat.com> <1461936647.3712.41.camel@redhat.com> Message-ID: <1462199279.5579.33.camel@redhat.com> On Fri, 2016-04-29 at 15:30 +0200, Severin Gehwolf wrote: > On Fri, 2016-04-29 at 09:21 +0100, Andrew Haley wrote: > > > > On 29/04/16 08:56, Severin Gehwolf wrote: > > > > > > > > > Here you go (DTRACE_CLASSLOAD_PROBE(loaded, k, shared_class); > > OK.??Now take that expansion, run indent on it, and paste it in > > to the program where the macro was.??Then we'll be able to get > > much better info about the reload failure. > For the curious, this is the bit that trips up GCC?4.4.7 and GCC?4.7.2 > and seems to work fine on GCC 5.3.1: > > --- /home/sgehwolf/openjdk9-hs-pristine/hotspot/src/share/vm/services/classLoadingService.cpp.fail_mini 2016-04-29 14:56:30.711924152 +0200 > +++ /home/sgehwolf/openjdk9-hs-pristine/hotspot/src/share/vm/services/classLoadingService.cpp 2016-04-29 14:57:00.102527106 +0200 > @@ -170,7 +170,7 @@ > ?????????????????????????????"\n":: > ?????????????????????????????[_SDT_S3] > ?????????????????????????????"n" ( 1 ), > -????????????????????????????[_SDT_A3] "nor" ( ((k)->class_loader ()))); > +????????????????????????????[_SDT_A3] "nor" ( 1 )); > ???????__asm__ __volatile__ (".ifndef _.stapsdt.base" "\n" > ?????????????????????????????".pushsection .stapsdt.base" "," "\"aG\"" "," > ?????????????????????????????"\"progbits\"" "," ".stapsdt.base" "," "comdat" > > Affected GCC versions choke on the "(k)->class_loader ()" bit with -O3 > :-( The real cause for this is the extra code compiled in when CHECK_UNHANDLED_OOPS is defined. That's the case for fastdebug builds only. I'm not sure why this shows up now, but I've filed this bug in any case: https://bugs.openjdk.java.net/browse/JDK-8155828 Cheers, Severin From derek.white at oracle.com Mon May 2 14:29:58 2016 From: derek.white at oracle.com (Derek White) Date: Mon, 2 May 2016 10:29:58 -0400 Subject: RFR (XXS): 8155754: Quarantine serviceability/tmtools/jstat/GcTest02.java In-Reply-To: <57271083.20001@oracle.com> References: <5723D0C5.6000104@oracle.com> <57271083.20001@oracle.com> Message-ID: <57276466.9010506@oracle.com> On 5/2/16 4:32 AM, Stefan Karlsson wrote: > Looks good. > > StefanK > > On 2016-04-29 23:23, Derek White wrote: >> JDK-8155570 is a >> test bug that is failing intermittently. It is probably an >> integration blocker, so *this* issue (8155754) is quarantining the >> test for now. >> >> Bug (sub task): https://bugs.openjdk.java.net/browse/JDK-8155754 >> Webrev: http://cr.openjdk.java.net/~drwhite/8155754/webrev.01/ >> jprt in progress... >> >> - Derek >> >> >> > Thanks Stefan! From coleen.phillimore at oracle.com Mon May 2 17:11:37 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 2 May 2016 13:11:37 -0400 Subject: RFR(xs): 8155819: Support non-continuous CodeBlobs in HotSpot broke Zero In-Reply-To: <1462195318.5579.29.camel@redhat.com> References: <1462189931.5579.23.camel@redhat.com> <20160502130600.GC22447@rbackman> <1462195318.5579.29.camel@redhat.com> Message-ID: <542d1a85-82f0-dfe7-f1b6-876b3747b9dc@oracle.com> On 5/2/16 9:21 AM, Severin Gehwolf wrote: > On Mon, 2016-05-02 at 15:06 +0200, Rickard B?ckman wrote: >> Looks good. >> >> /R > Thanks, Rickard. > > I'd need somebody to sponsor this, please! I can sponsor it. Coleen > > Cheers, > Severin > >> On 05/02, Severin Gehwolf wrote: >>> Hi, >>> >>> Could somebody please review and sponsor this trivial Zero build >>> fix. >>> It currently fails to build :( >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8155819 >>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8155819/we >>> brev.01/ >>> >>> Once reviewed, I'd need somebody to sponsor this change for me. >>> >>> Thanks, >>> Severin From coleen.phillimore at oracle.com Mon May 2 17:13:21 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Mon, 2 May 2016 13:13:21 -0400 Subject: RFR(xs): 8155819: Support non-continuous CodeBlobs in HotSpot broke Zero In-Reply-To: <542d1a85-82f0-dfe7-f1b6-876b3747b9dc@oracle.com> References: <1462189931.5579.23.camel@redhat.com> <20160502130600.GC22447@rbackman> <1462195318.5579.29.camel@redhat.com> <542d1a85-82f0-dfe7-f1b6-876b3747b9dc@oracle.com> Message-ID: <372d9834-2977-9e0a-7df1-36827234076e@oracle.com> On 5/2/16 1:11 PM, Coleen Phillimore wrote: > > > On 5/2/16 9:21 AM, Severin Gehwolf wrote: >> On Mon, 2016-05-02 at 15:06 +0200, Rickard B?ckman wrote: >>> Looks good. >>> >>> /R >> Thanks, Rickard. >> >> I'd need somebody to sponsor this, please! > > I can sponsor it. It also looks good - please send me an hg export of the patch. Coleen > > Coleen > >> >> Cheers, >> Severin >> >>> On 05/02, Severin Gehwolf wrote: >>>> Hi, >>>> >>>> Could somebody please review and sponsor this trivial Zero build >>>> fix. >>>> It currently fails to build :( >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8155819 >>>> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8155819/we >>>> brev.01/ >>>> >>>> Once reviewed, I'd need somebody to sponsor this change for me. >>>> >>>> Thanks, >>>> Severin > From sgehwolf at redhat.com Mon May 2 17:29:21 2016 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 02 May 2016 19:29:21 +0200 Subject: RFR(xs): 8155819: Support non-continuous CodeBlobs in HotSpot broke Zero In-Reply-To: <372d9834-2977-9e0a-7df1-36827234076e@oracle.com> References: <1462189931.5579.23.camel@redhat.com> <20160502130600.GC22447@rbackman> <1462195318.5579.29.camel@redhat.com> <542d1a85-82f0-dfe7-f1b6-876b3747b9dc@oracle.com> <372d9834-2977-9e0a-7df1-36827234076e@oracle.com> Message-ID: <1462210161.5579.52.camel@redhat.com> On Mon, 2016-05-02 at 13:13 -0400, Coleen Phillimore wrote: > > On 5/2/16 1:11 PM, Coleen Phillimore wrote: > > > > > > > > On 5/2/16 9:21 AM, Severin Gehwolf wrote: > > > > > > On Mon, 2016-05-02 at 15:06 +0200, Rickard B?ckman wrote: > > > > > > > > Looks good. > > > > > > > > /R > > > Thanks, Rickard. > > > > > > I'd need somebody to sponsor this, please! > > I can sponsor it. > It also looks good - please send me an hg export of the patch. Thanks for the review! Here you are: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8155819/JDK-8155819-jdk9-hotspot.export.patch Cheers, Severin > Coleen > > > > > > > Coleen > > > > > > > > > > > Cheers, > > > Severin > > > > > > > > > > > On 05/02, Severin Gehwolf wrote: > > > > > > > > > > Hi, > > > > > > > > > > Could somebody please review and sponsor this trivial Zero > > > > > build > > > > > fix. > > > > > It currently fails to build :( > > > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8155819 > > > > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8155 > > > > > 819/we > > > > > brev.01/ > > > > > > > > > > Once reviewed, I'd need somebody to sponsor this change for > > > > > me. > > > > > > > > > > Thanks, > > > > > Severin From Paul.Sandoz at oracle.com Mon May 2 22:18:06 2016 From: Paul.Sandoz at oracle.com (Paul Sandoz) Date: Mon, 2 May 2016 15:18:06 -0700 Subject: RFR 8155258: VarHandle implementation improvements Message-ID: <43CCC631-B8BA-40BF-A292-7F1ED00FDCDD@oracle.com> Hi, Please review: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155258-vhs-impl-improvements-jdk/webrev/ http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155258-vhs-impl-improvements-hotspot/webrev/ The hotspot changes are really small. Is there is precedent in such cases to push through jdk9-dev rather than hs, thus speeding up the integration? There are a bunch of improvements (mostly space/time): 1) By default a VarHandle does not hold its method types for access mode methods. Instead the erased types are held on VarForm (this shared across many VH instances) and are leveraged by the guard methods (see 4). 1.1) The non-erased method types are created on demand and cached (see 3). 2) Remove the use of ClassValue to hold VarForm instances. Each VarHandle implement holds its VarForm as a static instance. MemberNames to each access mode method implementation are still calculated on construction (this can be revisited to be lazy as a further issue). 3) A VarHandle caches invoker-based MethodHandles (access mode method type prefixed with VarHandle as the first parameter) to the corresponding MemberNames held on VarForm. Such handles are used by the VarHandle.toMethodHandle, by the guard methods (see 4), or general linkers/invokers. 4) The guard methods (on VarHandleGuards) were revamped to: 4.1) leverage the erased types in 1) 4.2) optimize for the void calling case (dropping the return value) when linking to a non-void access mode method. This is an edge case but avoids surprises (e.g. dropping the return value of a CompareAndExchange). This leverages a little known fact of invokehandle linking where it is safe to drop the return value (John assures me this is safe!), and required a slight tweak to hotspot for verification under fastdebug execution. 4.3) leverage the cached invoker method handle in 3) for the case where boxing/conversion is required, with an asType transformation. This is the non-optimal path, but is much better than before since the invoker method handle is a constant. JPRT core and hotspot tests pass. Paul. From Paul.Sandoz at oracle.com Mon May 2 22:37:36 2016 From: Paul.Sandoz at oracle.com (Paul Sandoz) Date: Mon, 2 May 2016 15:37:36 -0700 Subject: RFR 8155794 Move Objects.checkIndex BiFunction accepting methods to an internal package Message-ID: <9F2B1347-C76F-48A2-8433-8E9362CED4E8@oracle.com> Hi, Please review: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155794-checkIndex-bifunc-internal-jdk/webrev/ http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155794-checkIndex-bifunc-internal-hotspot/webrev/ This patch is based on that for 8155258 (VarHandle impl improvements) [1] sent previously. The hotspot changes are really small. Likewise for the 8155258 changes is there is precedent in such cases to push through jdk9-dev rather than hs? CCC reviewers strongly indicated for the advanced methods that can customise the exceptions: "You aren't gonna need it?. For expediency I propose to move such methods to an internal class jdk.internal.util.Preconditions. I would still like to sweep through java.base and leverage these methods while preserving exception reporting where possible. The hotspot changes are just for renaming of the intrinsic method signatures. Since the intrinsic method is now internal i have added an @ForceInline on the corresponding public method, given the potential for this to be used in performance sensitive code. JPRT core and hotspot tests pass. Paul. [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/040740.html From chris.hegarty at oracle.com Tue May 3 10:14:50 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 3 May 2016 11:14:50 +0100 Subject: RFR 8155794 Move Objects.checkIndex BiFunction accepting methods to an internal package In-Reply-To: <9F2B1347-C76F-48A2-8433-8E9362CED4E8@oracle.com> References: <9F2B1347-C76F-48A2-8433-8E9362CED4E8@oracle.com> Message-ID: On 2 May 2016, at 23:37, Paul Sandoz wrote: > Hi, > > Please review: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155794-checkIndex-bifunc-internal-jdk/webrev/ > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155794-checkIndex-bifunc-internal-hotspot/webrev/ The changes look fine to me Paul. -Chris. > This patch is based on that for 8155258 (VarHandle impl improvements) [1] sent previously. > > The hotspot changes are really small. Likewise for the 8155258 changes is there is precedent in such cases to push through jdk9-dev rather than hs? > > CCC reviewers strongly indicated for the advanced methods that can customise the exceptions: "You aren't gonna need it?. > > For expediency I propose to move such methods to an internal class jdk.internal.util.Preconditions. I would still like to sweep through java.base and leverage these methods while preserving exception reporting where possible. > > The hotspot changes are just for renaming of the intrinsic method signatures. Since the intrinsic method is now internal i have added an @ForceInline on the corresponding public method, given the potential for this to be used in performance sensitive code. > > > JPRT core and hotspot tests pass. > > Paul. > > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/040740.html From aleksey.shipilev at oracle.com Tue May 3 12:47:14 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 3 May 2016 15:47:14 +0300 Subject: RFR 8155794 Move Objects.checkIndex BiFunction accepting methods to an internal package In-Reply-To: <9F2B1347-C76F-48A2-8433-8E9362CED4E8@oracle.com> References: <9F2B1347-C76F-48A2-8433-8E9362CED4E8@oracle.com> Message-ID: <57289DD2.4020404@oracle.com> On 05/03/2016 01:37 AM, Paul Sandoz wrote: > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155794-checkIndex-bifunc-internal-jdk/webrev/ > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155794-checkIndex-bifunc-internal-hotspot/webrev/ Both JDK and HS changes look good to me. It's somewhat painful we need to hide these, but okay, let's do it. Thanks, -Aleksey From aleksey.shipilev at oracle.com Tue May 3 13:11:36 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 3 May 2016 16:11:36 +0300 Subject: RFR 8155258: VarHandle implementation improvements In-Reply-To: <43CCC631-B8BA-40BF-A292-7F1ED00FDCDD@oracle.com> References: <43CCC631-B8BA-40BF-A292-7F1ED00FDCDD@oracle.com> Message-ID: <5728A388.6050505@oracle.com> On 05/03/2016 01:18 AM, Paul Sandoz wrote: > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155258-vhs-impl-improvements-jdk/webrev/ > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155258-vhs-impl-improvements-hotspot/webrev/ I remember testing this before, so it definitely helps performance in pathological use cases for CompareAndExchange. MethodHandleNatives: *) Not sure I "dig" the change here (apart from old code apparently blows the capacity estimate): 469 static String getVarHandleMethodSignature(MethodType mt) { 470 char[] sig = new char[mt.parameterCount() + 2]; 471 472 int i = 0; 473 for (; i < mt.parameterCount(); i++) { 474 sig[i] = getCharType(mt.parameterType(i)); 475 } 476 sig[i] = '_'; 477 sig[i + 1] = getCharType(mt.returnType()); 478 479 return String.valueOf(sig); With Compact Strings, it's beneficial to use StringBuilder instead of char[], because StringBuilder will concat in Latin1 form. char[] code would need to re-compress to byte[] during String.valueOf(). MethodType: *) Only imports are changed. Revert? Otherwise next runner up would change the imports back, ad nauseam. X-VarHandle.java.template: *) There's compareAndExchangeVolatile_V, but there is no compareAndExchange{Acquire,Release}_V, etc. Shouldn't we have the "void" entries for every method that returns a value? Or, compareAndExchangeVolatile_V is redundant, and does not participate the new mechanics? Thanks, -Aleksey From forax at univ-mlv.fr Tue May 3 14:05:20 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 3 May 2016 16:05:20 +0200 (CEST) Subject: RFR 8155794 Move Objects.checkIndex BiFunction accepting methods to an internal package In-Reply-To: <9F2B1347-C76F-48A2-8433-8E9362CED4E8@oracle.com> References: <9F2B1347-C76F-48A2-8433-8E9362CED4E8@oracle.com> Message-ID: <1314424116.988033.1462284320182.JavaMail.zimbra@u-pem.fr> Looks good to me. minor nitpick, neither checkFromToIndex() nor checkFromIndexSize() are instrinsic (now !) but i think they also should be annotated with @ForceInline in j.u.Objects to avoid the code to be asymmetric or weird if one of these methods is intrinsinfied later. R?mi ----- Mail original ----- > De: "Paul Sandoz" > ?: "Core-Libs-Dev" , "hotspot-dev developers" > Envoy?: Mardi 3 Mai 2016 00:37:36 > Objet: RFR 8155794 Move Objects.checkIndex BiFunction accepting methods to an internal package > > Hi, > > Please review: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155794-checkIndex-bifunc-internal-jdk/webrev/ > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155794-checkIndex-bifunc-internal-hotspot/webrev/ > > This patch is based on that for 8155258 (VarHandle impl improvements) [1] > sent previously. > > The hotspot changes are really small. Likewise for the 8155258 changes is > there is precedent in such cases to push through jdk9-dev rather than hs? > > CCC reviewers strongly indicated for the advanced methods that can customise > the exceptions: "You aren't gonna need it?. > > For expediency I propose to move such methods to an internal class > jdk.internal.util.Preconditions. I would still like to sweep through > java.base and leverage these methods while preserving exception reporting > where possible. > > The hotspot changes are just for renaming of the intrinsic method signatures. > Since the intrinsic method is now internal i have added an @ForceInline on > the corresponding public method, given the potential for this to be used in > performance sensitive code. > > > JPRT core and hotspot tests pass. > > Paul. > > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/040740.html > > From paul.sandoz at oracle.com Tue May 3 18:35:06 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 3 May 2016 11:35:06 -0700 Subject: RFR 8155258: VarHandle implementation improvements In-Reply-To: <5728A388.6050505@oracle.com> References: <43CCC631-B8BA-40BF-A292-7F1ED00FDCDD@oracle.com> <5728A388.6050505@oracle.com> Message-ID: > On 3 May 2016, at 06:11, Aleksey Shipilev wrote: > > On 05/03/2016 01:18 AM, Paul Sandoz wrote: >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155258-vhs-impl-improvements-jdk/webrev/ >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155258-vhs-impl-improvements-hotspot/webrev/ > > I remember testing this before, so it definitely helps performance in > pathological use cases for CompareAndExchange. > > MethodHandleNatives: > > *) Not sure I "dig" the change here (apart from old code apparently > blows the capacity estimate): > Right, blows the estimate and i did some extra fiddling to remove the dependency on StringBuilder at the same time. > 469 static String getVarHandleMethodSignature(MethodType mt) { > 470 char[] sig = new char[mt.parameterCount() + 2]; > 471 > 472 int i = 0; > 473 for (; i < mt.parameterCount(); i++) { > 474 sig[i] = getCharType(mt.parameterType(i)); > 475 } > 476 sig[i] = '_'; > 477 sig[i + 1] = getCharType(mt.returnType()); > 478 > 479 return String.valueOf(sig); > > With Compact Strings, it's beneficial to use StringBuilder instead of > char[], because StringBuilder will concat in Latin1 form. char[] code > would need to re-compress to byte[] during String.valueOf(). > Good point, reverted. > MethodType: > > *) Only imports are changed. Revert? Otherwise next runner up would > change the imports back, ad nauseam. > Reverted. > X-VarHandle.java.template: > > *) There's compareAndExchangeVolatile_V, but there is no > compareAndExchange{Acquire,Release}_V, etc. Shouldn't we have the "void" > entries for every method that returns a value? Or, > compareAndExchangeVolatile_V is redundant, and does not participate the > new mechanics? > Ah, that is a left-over from a previous experiment, before i realised the return value can be dropped. Removed. http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155258-vhs-impl-improvements-jdk/webrev/ Thanks, Paul. From aleksey.shipilev at oracle.com Tue May 3 18:40:57 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 3 May 2016 21:40:57 +0300 Subject: RFR 8155258: VarHandle implementation improvements In-Reply-To: References: <43CCC631-B8BA-40BF-A292-7F1ED00FDCDD@oracle.com> <5728A388.6050505@oracle.com> Message-ID: <5728F0B9.8030602@oracle.com> On 05/03/2016 09:35 PM, Paul Sandoz wrote: > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155258-vhs-impl-improvements-jdk/webrev/ Okay then, looks good. -Aleksey From brent.christian at oracle.com Tue May 3 19:00:27 2016 From: brent.christian at oracle.com (Brent Christian) Date: Tue, 03 May 2016 12:00:27 -0700 Subject: RFR 8147039 : Incorrect locals and operands in compiled frames Message-ID: <5728F54B.8070007@oracle.com> Hi, Please review this change which fixes buggy behavior (including SEGV) in the experimental LiveStackFrame feature of StackWalker. Bug: https://bugs.openjdk.java.net/browse/JDK-8147039 Webrev: http://cr.openjdk.java.net/~bchristi/8147039/webrev.02/ As suggested in the bug report, stack walking is reimplemented using javaVFrame/vframe::java_sender. The native StackWalkerAnchor class is updated (and renamed) with a similar interface and function to vframeStream. I've also removed the now-unneeded vframeStreamCommon::java_frame() function, added by 8140450. Thanks, -Brent From kim.barrett at oracle.com Tue May 3 19:20:00 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 3 May 2016 15:20:00 -0400 Subject: RFR: 8149591 - Prepare hotspot for GTest In-Reply-To: <2E67D611-36FF-4485-9468-7E7A1FC7819F@oracle.com> References: <56BB93D6.3000905@oracle.com> <56BC0BF1.7070506@oracle.com> <2E67D611-36FF-4485-9468-7E7A1FC7819F@oracle.com> Message-ID: <1EE4DEDD-17F4-4893-B1FE-3C2C0A7E6F17@oracle.com> > On Apr 29, 2016, at 9:47 PM, Igor Ignatyev wrote: > > Hi, > > I?d like to renew this RFR. > > besides updated previous changes, new webrev contains two new things: > - new vm-flag ? ExecutingUnitTests, we use it in debug jvm to print a clean error message (w/o assert, line, file, etc). it is needed to simplify comparing error message in ?death? tests (the tests which intentionally cause crashes/asserts) > - if CreateCoredumpOnCrash is false, we don't determine default core path > > webrev: http://cr.openjdk.java.net/~iignatyev/8149591/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8149591 > > Thanks, > ? Igor Not a full review yet, but a question before I go on. I don?t understand the purpose of FormatBufferDummy. I?m guessing it is to disambiguate the new FormatBuffer constructor taking a va_list argument. But with these two overloads: FormatBuffer(const char* format, ?); FormatBuffer(const char* format, va_list ap); the latter should always be a better match when the second argument is a va_list, and should never be a match at all otherwise. (An overload containing ellipsis is always the least good match.) So I think we shouldn?t need FormatBufferDummy. From george.triantafillou at oracle.com Tue May 3 19:44:48 2016 From: george.triantafillou at oracle.com (George Triantafillou) Date: Tue, 3 May 2016 15:44:48 -0400 Subject: RFR(XS): 8154942 Remove ProcessTools.getVmInputArguments() from the hotspot test library, as it is not used by any of the hotspot tests In-Reply-To: References: <5720CF18.6000109@oracle.com> Message-ID: Hi Christian, As we discussed offline, there is definitely room for cleanup, but that warrants a separate RFE due to the extent of the changes required. So, is this minor fix ready to commit? -George On 4/27/2016 11:44 AM, Christian Tornqvist wrote: > Hi George, > > Are there any unnecessary @module tags we can remove as a result of this? > > Thanks, > Christian > > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of George Triantafillou > Sent: Wednesday, April 27, 2016 10:39 AM > To: hotspot-dev at openjdk.java.net > Subject: RFR(XS): 8154942 Remove ProcessTools.getVmInputArguments() from the hotspot test library, as it is not used by any of the hotspot tests > > Please review this very small change that removes the unused method > getVmInputArguments() from ProcessTools. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8154942 > Webrev: > http://cr.openjdk.java.net/~gtriantafill/bug-8154942/bug_8154942.patch/webrev/ > > > Thanks, > George > From kim.barrett at oracle.com Tue May 3 19:50:55 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 3 May 2016 15:50:55 -0400 Subject: RFR: 8149591 - Prepare hotspot for GTest In-Reply-To: <2E67D611-36FF-4485-9468-7E7A1FC7819F@oracle.com> References: <56BB93D6.3000905@oracle.com> <56BC0BF1.7070506@oracle.com> <2E67D611-36FF-4485-9468-7E7A1FC7819F@oracle.com> Message-ID: <746FAEA9-C394-4A2F-8A32-4F77D7F9D5AF@oracle.com> > On Apr 29, 2016, at 9:47 PM, Igor Ignatyev wrote: > > Hi, > > I?d like to renew this RFR. > > besides updated previous changes, new webrev contains two new things: > - new vm-flag ? ExecutingUnitTests, we use it in debug jvm to print a clean error message (w/o assert, line, file, etc). it is needed to simplify comparing error message in ?death? tests (the tests which intentionally cause crashes/asserts) > - if CreateCoredumpOnCrash is false, we don't determine default core path > > webrev: http://cr.openjdk.java.net/~iignatyev/8149591/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8149591 > > Thanks, > ? Igor In addition to the FormatBufferDummy question in earlier email, here are my comments: ------------------------------------------------------------------------------ src/share/vm/services/management.cpp 1612 FormatBuffer<80> error_msg("%s", ""); [renamed variable err_msg => error_msg.] I think this change should no longer be needed? But it is also harmless to keep. ------------------------------------------------------------------------------ src/share/vm/runtime/globals.hpp 2073 product(bool, ExecutingUnitTests, false, This flag appears to only be referenced in debug builds, so why is it a product flag rather than a develop flag? ------------------------------------------------------------------------------ From kim.barrett at oracle.com Tue May 3 19:53:21 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 3 May 2016 15:53:21 -0400 Subject: RFR: 8141501: Problems with BitMap buffer management In-Reply-To: <5727172D.601@oracle.com> References: <5720A91A.1020809@oracle.com> <57220EE4.4080007@oracle.com> <2CE7A7C6-24BA-4A2D-8DE8-8C01E922EBD4@oracle.com> <5727172D.601@oracle.com> Message-ID: <4E16B54E-614D-4B21-81D5-9ABE7D7894D9@oracle.com> > On May 2, 2016, at 5:00 AM, Stefan Karlsson wrote: > > Hi Kim, > > Updated webrevs: > http://cr.openjdk.java.net/~stefank/8141501/webrev.03.delta > http://cr.openjdk.java.net/~stefank/8141501/webrev.03 > > Comments inlined: > > On 2016-04-30 19:01, Kim Barrett wrote: [?] >> src/share/vm/c1/c1_LinearScan.cpp >> 718 block->set_live_in (ResourceBitMap(live_size)); block->live_in().clear(); >> 719 block->set_live_out (ResourceBitMap(live_size)); block->live_out().clear(); >> >> Consider instead >> >> block->live_in().reinitialize(live_size); >> block->live_out().reinitialize(live_size); > > I intend to remove the call to clear() with the fix for this bug: > https://bugs.openjdk.java.net/browse/JDK-8155638 > > So, I'd like to do this suggestion as a part of that change. OK. From stefan.karlsson at oracle.com Tue May 3 19:57:33 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 3 May 2016 21:57:33 +0200 Subject: RFR: 8149591 - Prepare hotspot for GTest In-Reply-To: <1EE4DEDD-17F4-4893-B1FE-3C2C0A7E6F17@oracle.com> References: <56BB93D6.3000905@oracle.com> <56BC0BF1.7070506@oracle.com> <2E67D611-36FF-4485-9468-7E7A1FC7819F@oracle.com> <1EE4DEDD-17F4-4893-B1FE-3C2C0A7E6F17@oracle.com> Message-ID: <572902AD.8020407@oracle.com> Hi Kim, On 2016-05-03 21:20, Kim Barrett wrote: >> On Apr 29, 2016, at 9:47 PM, Igor Ignatyev wrote: >> >> Hi, >> >> I?d like to renew this RFR. >> >> besides updated previous changes, new webrev contains two new things: >> - new vm-flag ? ExecutingUnitTests, we use it in debug jvm to print a clean error message (w/o assert, line, file, etc). it is needed to simplify comparing error message in ?death? tests (the tests which intentionally cause crashes/asserts) >> - if CreateCoredumpOnCrash is false, we don't determine default core path >> >> webrev: http://cr.openjdk.java.net/~iignatyev/8149591/webrev.00/ >> JBS: https://bugs.openjdk.java.net/browse/JDK-8149591 >> >> Thanks, >> ? Igor > Not a full review yet, but a question before I go on. > > I don?t understand the purpose of FormatBufferDummy. I?m guessing it is to disambiguate the new > FormatBuffer constructor taking a va_list argument. Yes, that was the purpose. > But with these two overloads: > > FormatBuffer(const char* format, ?); > FormatBuffer(const char* format, va_list ap); > > the latter should always be a better match when the second argument is a va_list, and should never > be a match at all otherwise. (An overload containing ellipsis is always the least good match.) So I > think we shouldn?t need FormatBufferDummy. > I started with that implementation but got the following error: src/share/vm/gc/shared/genCollectedHeap.cpp: In member function 'void GenCollectedHeap::do_collection(bool, bool, size_t, bool, GenCollectedHeap::GenerationType)': src/share/vm/gc/shared/genCollectedHeap.cpp:435:44: error: deprecated conversion from string constant to 'va_list {aka char*}' [-Werror=write-strings] FormatBuffer<> gc_string("%s", "Pause "); So, adding FormatBufferDummy was a quick-n-dirty solution to fix this. Thanks, StefanK From paul.sandoz at oracle.com Tue May 3 20:03:12 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 3 May 2016 13:03:12 -0700 Subject: RFR 8155794 Move Objects.checkIndex BiFunction accepting methods to an internal package In-Reply-To: <1314424116.988033.1462284320182.JavaMail.zimbra@u-pem.fr> References: <9F2B1347-C76F-48A2-8433-8E9362CED4E8@oracle.com> <1314424116.988033.1462284320182.JavaMail.zimbra@u-pem.fr> Message-ID: <0457D70E-7BA2-4A92-AC0E-0E56103F4DE5@oracle.com> > On 3 May 2016, at 07:05, Remi Forax wrote: > > Looks good to me. > minor nitpick, neither checkFromToIndex() nor checkFromIndexSize() are instrinsic (now !) but i think they also should be annotated with @ForceInline in j.u.Objects to avoid the code to be asymmetric or weird if one of these methods is intrinsinfied later. > I was tempted, but for the moment i am inclined to leave as is and revisit if/when necessary. Trying to be conservative when using those annotations. Thanks, Paul. From stefan.karlsson at oracle.com Tue May 3 20:18:12 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 3 May 2016 22:18:12 +0200 Subject: RFR: 8149591 - Prepare hotspot for GTest In-Reply-To: <746FAEA9-C394-4A2F-8A32-4F77D7F9D5AF@oracle.com> References: <56BB93D6.3000905@oracle.com> <56BC0BF1.7070506@oracle.com> <2E67D611-36FF-4485-9468-7E7A1FC7819F@oracle.com> <746FAEA9-C394-4A2F-8A32-4F77D7F9D5AF@oracle.com> Message-ID: <57290784.4030900@oracle.com> Hi Kim, On 2016-05-03 21:50, Kim Barrett wrote: >> On Apr 29, 2016, at 9:47 PM, Igor Ignatyev wrote: >> >> Hi, >> >> I?d like to renew this RFR. >> >> besides updated previous changes, new webrev contains two new things: >> - new vm-flag ? ExecutingUnitTests, we use it in debug jvm to print a clean error message (w/o assert, line, file, etc). it is needed to simplify comparing error message in ?death? tests (the tests which intentionally cause crashes/asserts) >> - if CreateCoredumpOnCrash is false, we don't determine default core path >> >> webrev: http://cr.openjdk.java.net/~iignatyev/8149591/webrev.00/ >> JBS: https://bugs.openjdk.java.net/browse/JDK-8149591 >> >> Thanks, >> ? Igor > In addition to the FormatBufferDummy question in earlier email, here > are my comments: > > ------------------------------------------------------------------------------ > src/share/vm/services/management.cpp > 1612 FormatBuffer<80> error_msg("%s", ""); > [renamed variable err_msg => error_msg.] > > I think this change should no longer be needed? But it is also > harmless to keep. > > ------------------------------------------------------------------------------ > src/share/vm/runtime/globals.hpp > 2073 product(bool, ExecutingUnitTests, false, > > This flag appears to only be referenced in debug builds, so why is it > a product flag rather than a develop flag? I changed it to a product flag since it's used by the gtestLauncher, in the gtest patch, in product builds. But maybe the correct change would be to fix the gtestLaucher? The tests can be run with product builds, so I don't think it's entirely wrong to have ExecutingUnitTests set to true for both debug and product builds. StefanK > > ------------------------------------------------------------------------------ > From stefan.karlsson at oracle.com Tue May 3 20:24:13 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 3 May 2016 22:24:13 +0200 Subject: RFR: 8141501: Problems with BitMap buffer management In-Reply-To: <4E16B54E-614D-4B21-81D5-9ABE7D7894D9@oracle.com> References: <5720A91A.1020809@oracle.com> <57220EE4.4080007@oracle.com> <2CE7A7C6-24BA-4A2D-8DE8-8C01E922EBD4@oracle.com> <5727172D.601@oracle.com> <4E16B54E-614D-4B21-81D5-9ABE7D7894D9@oracle.com> Message-ID: <572908ED.2010701@oracle.com> Hi Kim, Can I consider this patch Reviewed now? Thanks, StefanK On 2016-05-03 21:53, Kim Barrett wrote: >> On May 2, 2016, at 5:00 AM, Stefan Karlsson wrote: >> >> Hi Kim, >> >> Updated webrevs: >> http://cr.openjdk.java.net/~stefank/8141501/webrev.03.delta >> http://cr.openjdk.java.net/~stefank/8141501/webrev.03 >> >> Comments inlined: >> >> On 2016-04-30 19:01, Kim Barrett wrote: > [?] >>> src/share/vm/c1/c1_LinearScan.cpp >>> 718 block->set_live_in (ResourceBitMap(live_size)); block->live_in().clear(); >>> 719 block->set_live_out (ResourceBitMap(live_size)); block->live_out().clear(); >>> >>> Consider instead >>> >>> block->live_in().reinitialize(live_size); >>> block->live_out().reinitialize(live_size); >> I intend to remove the call to clear() with the fix for this bug: >> https://bugs.openjdk.java.net/browse/JDK-8155638 >> >> So, I'd like to do this suggestion as a part of that change. > OK. > From kim.barrett at oracle.com Tue May 3 20:31:29 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 3 May 2016 16:31:29 -0400 Subject: RFR: 8141501: Problems with BitMap buffer management In-Reply-To: <572908ED.2010701@oracle.com> References: <5720A91A.1020809@oracle.com> <57220EE4.4080007@oracle.com> <2CE7A7C6-24BA-4A2D-8DE8-8C01E922EBD4@oracle.com> <5727172D.601@oracle.com> <4E16B54E-614D-4B21-81D5-9ABE7D7894D9@oracle.com> <572908ED.2010701@oracle.com> Message-ID: <9DBA0353-103C-43C0-9D82-5AD1379C7499@oracle.com> > On May 3, 2016, at 4:24 PM, Stefan Karlsson wrote: > > Hi Kim, > > Can I consider this patch Reviewed now? Sorry, should have said so. Yes. From stefan.karlsson at oracle.com Tue May 3 20:35:24 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 3 May 2016 22:35:24 +0200 Subject: RFR: 8141501: Problems with BitMap buffer management In-Reply-To: <9DBA0353-103C-43C0-9D82-5AD1379C7499@oracle.com> References: <5720A91A.1020809@oracle.com> <57220EE4.4080007@oracle.com> <2CE7A7C6-24BA-4A2D-8DE8-8C01E922EBD4@oracle.com> <5727172D.601@oracle.com> <4E16B54E-614D-4B21-81D5-9ABE7D7894D9@oracle.com> <572908ED.2010701@oracle.com> <9DBA0353-103C-43C0-9D82-5AD1379C7499@oracle.com> Message-ID: <57290B8C.5080408@oracle.com> On 2016-05-03 22:31, Kim Barrett wrote: >> On May 3, 2016, at 4:24 PM, Stefan Karlsson wrote: >> >> Hi Kim, >> >> Can I consider this patch Reviewed now? > Sorry, should have said so. Yes. > Thanks, StefanK From mandy.chung at oracle.com Tue May 3 20:45:01 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 3 May 2016 13:45:01 -0700 Subject: RFR 8147039 : Incorrect locals and operands in compiled frames In-Reply-To: <5728F54B.8070007@oracle.com> References: <5728F54B.8070007@oracle.com> Message-ID: <7773B9CF-84F9-454D-8DCC-A2ED28DEEEBC@oracle.com> > On May 3, 2016, at 12:00 PM, Brent Christian wrote: > > Hi, > > Please review this change which fixes buggy behavior (including SEGV) in the experimental LiveStackFrame feature of StackWalker. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8147039 > Webrev: > http://cr.openjdk.java.net/~bchristi/8147039/webrev.02/ > > As suggested in the bug report, stack walking is reimplemented using javaVFrame/vframe::java_sender. The native StackWalkerAnchor class is updated (and renamed) with a similar interface and function to vframeStream. I've also removed the now-unneeded vframeStreamCommon::java_frame() function, added by 8140450. This patch looks good. I?m happy that the fix turns out to be very simple and clean. One minor nit: in stackwalk.cpp, the local variable ?anchor? used in a couple places should also be renamed. You can fix that up before you push (no need for a new webrev) thanks Mandy From kim.barrett at oracle.com Tue May 3 21:24:33 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 3 May 2016 17:24:33 -0400 Subject: RFR: 8149591 - Prepare hotspot for GTest In-Reply-To: <572902AD.8020407@oracle.com> References: <56BB93D6.3000905@oracle.com> <56BC0BF1.7070506@oracle.com> <2E67D611-36FF-4485-9468-7E7A1FC7819F@oracle.com> <1EE4DEDD-17F4-4893-B1FE-3C2C0A7E6F17@oracle.com> <572902AD.8020407@oracle.com> Message-ID: > On May 3, 2016, at 3:57 PM, Stefan Karlsson wrote: > > Hi Kim, > > On 2016-05-03 21:20, Kim Barrett wrote: >>> On Apr 29, 2016, at 9:47 PM, Igor Ignatyev wrote: >>> >>> Hi, >>> >>> I?d like to renew this RFR. >>> >>> besides updated previous changes, new webrev contains two new things: >>> - new vm-flag ? ExecutingUnitTests, we use it in debug jvm to print a clean error message (w/o assert, line, file, etc). it is needed to simplify comparing error message in ?death? tests (the tests which intentionally cause crashes/asserts) >>> - if CreateCoredumpOnCrash is false, we don't determine default core path >>> >>> webrev: http://cr.openjdk.java.net/~iignatyev/8149591/webrev.00/ >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8149591 >>> >>> Thanks, >>> ? Igor >> Not a full review yet, but a question before I go on. >> >> I don?t understand the purpose of FormatBufferDummy. I?m guessing it is to disambiguate the new >> FormatBuffer constructor taking a va_list argument. > > Yes, that was the purpose. > >> But with these two overloads: >> >> FormatBuffer(const char* format, ?); >> FormatBuffer(const char* format, va_list ap); >> >> the latter should always be a better match when the second argument is a va_list, and should never >> be a match at all otherwise. (An overload containing ellipsis is always the least good match.) So I >> think we shouldn?t need FormatBufferDummy. >> > I started with that implementation but got the following error: > > src/share/vm/gc/shared/genCollectedHeap.cpp: In member function 'void GenCollectedHeap::do_collection(bool, bool, size_t, bool, GenCollectedHeap::GenerationType)': > src/share/vm/gc/shared/genCollectedHeap.cpp:435:44: error: deprecated conversion from string constant to 'va_list {aka char*}' [-Werror=write-strings] > FormatBuffer<> gc_string("%s", "Pause "); > > So, adding FormatBufferDummy was a quick-n-dirty solution to fix this. va_list on this platform seems to be just a typedef for char*. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33588 which is ?won?t fix?. I hadn?t realized that overloading on va_list isn?t really useful; I guess that?s why there are lots of ?v?-prefixed/suffixed operations around. I can?t think of a better solution. A comment would be nice. From stefan.karlsson at oracle.com Tue May 3 21:43:26 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 3 May 2016 23:43:26 +0200 Subject: RFR: 8149591 - Prepare hotspot for GTest In-Reply-To: References: <56BB93D6.3000905@oracle.com> <56BC0BF1.7070506@oracle.com> <2E67D611-36FF-4485-9468-7E7A1FC7819F@oracle.com> <1EE4DEDD-17F4-4893-B1FE-3C2C0A7E6F17@oracle.com> <572902AD.8020407@oracle.com> Message-ID: <57291B7E.5020906@oracle.com> On 2016-05-03 23:24, Kim Barrett wrote: >> On May 3, 2016, at 3:57 PM, Stefan Karlsson wrote: >> >> Hi Kim, >> >> On 2016-05-03 21:20, Kim Barrett wrote: >>>> On Apr 29, 2016, at 9:47 PM, Igor Ignatyev wrote: >>>> >>>> Hi, >>>> >>>> I?d like to renew this RFR. >>>> >>>> besides updated previous changes, new webrev contains two new things: >>>> - new vm-flag ? ExecutingUnitTests, we use it in debug jvm to print a clean error message (w/o assert, line, file, etc). it is needed to simplify comparing error message in ?death? tests (the tests which intentionally cause crashes/asserts) >>>> - if CreateCoredumpOnCrash is false, we don't determine default core path >>>> >>>> webrev: http://cr.openjdk.java.net/~iignatyev/8149591/webrev.00/ >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8149591 >>>> >>>> Thanks, >>>> ? Igor >>> Not a full review yet, but a question before I go on. >>> >>> I don?t understand the purpose of FormatBufferDummy. I?m guessing it is to disambiguate the new >>> FormatBuffer constructor taking a va_list argument. >> Yes, that was the purpose. >> >>> But with these two overloads: >>> >>> FormatBuffer(const char* format, ?); >>> FormatBuffer(const char* format, va_list ap); >>> >>> the latter should always be a better match when the second argument is a va_list, and should never >>> be a match at all otherwise. (An overload containing ellipsis is always the least good match.) So I >>> think we shouldn?t need FormatBufferDummy. >>> >> I started with that implementation but got the following error: >> >> src/share/vm/gc/shared/genCollectedHeap.cpp: In member function 'void GenCollectedHeap::do_collection(bool, bool, size_t, bool, GenCollectedHeap::GenerationType)': >> src/share/vm/gc/shared/genCollectedHeap.cpp:435:44: error: deprecated conversion from string constant to 'va_list {aka char*}' [-Werror=write-strings] >> FormatBuffer<> gc_string("%s", "Pause "); >> >> So, adding FormatBufferDummy was a quick-n-dirty solution to fix this. > va_list on this platform seems to be just a typedef for char*. > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33588 > which is ?won?t fix?. I hadn?t realized that overloading on va_list isn?t really useful; > I guess that?s why there are lots of ?v?-prefixed/suffixed operations around. I can?t > think of a better solution. A comment would be nice. Yes. StefanK From coleen.phillimore at oracle.com Tue May 3 21:57:28 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 3 May 2016 17:57:28 -0400 Subject: RFR 8147039 : Incorrect locals and operands in compiled frames In-Reply-To: <5728F54B.8070007@oracle.com> References: <5728F54B.8070007@oracle.com> Message-ID: <57e058ab-46bb-3f76-03c9-76e4894d5820@oracle.com> This looks good to me. JavaFrameStream is a good name for this. Coleen On 5/3/16 3:00 PM, Brent Christian wrote: > Hi, > > Please review this change which fixes buggy behavior (including SEGV) > in the experimental LiveStackFrame feature of StackWalker. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8147039 > Webrev: > http://cr.openjdk.java.net/~bchristi/8147039/webrev.02/ > > As suggested in the bug report, stack walking is reimplemented using > javaVFrame/vframe::java_sender. The native StackWalkerAnchor class is > updated (and renamed) with a similar interface and function to > vframeStream. I've also removed the now-unneeded > vframeStreamCommon::java_frame() function, added by 8140450. > > Thanks, > -Brent From david.holmes at oracle.com Tue May 3 23:39:07 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 4 May 2016 09:39:07 +1000 Subject: RFR: 8154715: Missing destructor and/or TLS clearing calls for terminating threads Message-ID: This needs attention from GC and runtime folk please. bug: https://bugs.openjdk.java.net/browse/JDK-8154715 webrev: http://cr.openjdk.java.net/~dholmes/8154715/webrev/ tl;dr: ensure ThreadLocalStorage::set_thread(NULL) is always called before a thread terminates. Background: Most system-related threads do not expect to explicitly terminate, except sometimes as part of VM termination. Such threads don't have their destructors called, but should. This omission came to light due to the ThreadLocalStorage changes in JDK-8132510. As part of that change we deleted the following from the termination path of the VMThread: // Thread destructor usually does this. ThreadLocalStorage::set_thread(NULL); The clearing of TLS seemed irrelevant to the VMThread as it primarily is used to aid in JNI attach/detach. However Brian Gardner reported: http://mail.openjdk.java.net/pipermail/bsd-port-dev/2016-February/002788.html a problem on FreeBSD caused by this change and the interaction with the POSIX pthread TLS destructor use introduced by JDK-8033696. Because the VMThread terminated without clearing TLS, when the TLS-destructor was called it got into a loop which ran four times (as happens on Linux) and then prints a warning to the console (which doesn't happen on Linux). This indicates we need to restore the: ThreadLocalStorage::set_thread(NULL); but on further consideration it seems to me that this is not confined to the VMThread, and the most appropriate fix would be to always invoke the Thread destructor as a thread terminates. Solution: Further investigation shows that calling the Thread destructor in the thread as it terminates is not possible: - VMThread This is actually destroyed by the thread that terminates the VM, but that can happen after it terminates and so we still hit the TLS problem. The VMThread may be able to destroy itself today but in the past this was not possible (see existing code comment), and in the future it may also not be possible - the problem is that the Thread destructor can interact with other VM subsystems that are concurrently being torn down by the thread that is terminating the VM. In the past this was the CodeHeap. So rather than introduce something that is fragile we stick with the current scheme but restore the ThreadLocalStorage::set_thread(NULL); - note we can't access "this" at that time because it may already have been de-allocated. - WatcherThread The WatcherThread is never destroyed today but has the same problem as the VMThread. We can call the destructor from the VM termination thread (and have implemented that), but not from the WatcherThread itself. So again we just have to restore the ThreadLocalStorage::set_thread(NULL); to fix the potential TLS problem. - GC Threads There are two cases: a) GC threads that never terminate For these we don't need to do anything: we can't delete the thread as it never terminates and we don't hit the TLS problem because it never terminates. So all we will do here is add some logic to check (in NON_PRODUCT) that we do in fact never terminate. b) GC threads that can terminate Despite the fact the threads can terminate, references to those threads are stored elsewhere (WorkGangs and other places) and are not cleared as part of the termination process. Those references can be touched after the thread has terminated so we can not call the destructor at all. So again all we can do (without some major thread management reworking) is ensure that ThreadLocalStorage::set_thread(NULL); is called before the thread actually terminates Testing: JPRT RBT - runtime nightly tests Thanks, David From brent.christian at oracle.com Tue May 3 23:43:39 2016 From: brent.christian at oracle.com (Brent Christian) Date: Tue, 03 May 2016 16:43:39 -0700 Subject: RFR 8147039 : Incorrect locals and operands in compiled frames In-Reply-To: <7773B9CF-84F9-454D-8DCC-A2ED28DEEEBC@oracle.com> References: <5728F54B.8070007@oracle.com> <7773B9CF-84F9-454D-8DCC-A2ED28DEEEBC@oracle.com> Message-ID: <572937AB.3010508@oracle.com> Hi, Mandy On 05/03/2016 01:45 PM, Mandy Chung wrote: > > One minor nit: in stackwalk.cpp, the local variable ?anchor? used in > a couple places should also be renamed. You can fix that up before > you push (no need for a new webrev) Ah, looks like I missed JavaFrameStream::from_current(). Are you okay with _anchor as a field name in JavaFrameStream, or would you prefer, say, "_magic"? Thanks for having a look. -Brent From mandy.chung at oracle.com Wed May 4 00:24:35 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 3 May 2016 17:24:35 -0700 Subject: RFR 8147039 : Incorrect locals and operands in compiled frames In-Reply-To: <572937AB.3010508@oracle.com> References: <5728F54B.8070007@oracle.com> <7773B9CF-84F9-454D-8DCC-A2ED28DEEEBC@oracle.com> <572937AB.3010508@oracle.com> Message-ID: <84A0AE41-26DB-4D0B-B367-CAD5D5407FAF@oracle.com> > On May 3, 2016, at 4:43 PM, Brent Christian wrote: > > Hi, Mandy > >> On 05/03/2016 01:45 PM, Mandy Chung wrote: >> >> One minor nit: in stackwalk.cpp, the local variable ?anchor? used in >> a couple places should also be renamed. You can fix that up before >> you push (no need for a new webrev) > > Ah, looks like I missed JavaFrameStream::from_current(). > > Are you okay with _anchor as a field name in JavaFrameStream, or would you prefer, say, "_magic"? > _anchor as a field name is fine as that also serves as the purpose. Mandy > Thanks for having a look. > > -Brent From Leonid.Mesnik at oracle.com Wed May 4 06:43:39 2016 From: Leonid.Mesnik at oracle.com (Leonid Mesnik) Date: Wed, 4 May 2016 09:43:39 +0300 Subject: RFR(S): 8155950: Add minimal VM in JIB profile on linux-x86 Message-ID: <57299A1B.80709@oracle.com> Please review this small change which adds minimal VM as a part of default JIB profile on linux-x86. The fix also include quick workaround for bug JDK-8155946 . Bug: https://bugs.openjdk.java.net/browse/JDK-8155950 Webrev (top): http://cr.openjdk.java.net/~lmesnik/8155950/webrev.00/root/ Webrev(hotspot): http://cr.openjdk.java.net/~lmesnik/8155950/webrev.00/hotspot/ Testing: JPRT (with updated testing of minimal VM flags) Leonid From forax at univ-mlv.fr Wed May 4 06:58:13 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 4 May 2016 08:58:13 +0200 (CEST) Subject: RFR 8155794 Move Objects.checkIndex BiFunction accepting methods to an internal package In-Reply-To: <0457D70E-7BA2-4A92-AC0E-0E56103F4DE5@oracle.com> References: <9F2B1347-C76F-48A2-8433-8E9362CED4E8@oracle.com> <1314424116.988033.1462284320182.JavaMail.zimbra@u-pem.fr> <0457D70E-7BA2-4A92-AC0E-0E56103F4DE5@oracle.com> Message-ID: <1714212430.1187040.1462345093295.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Paul Sandoz" > Cc: "hotspot-dev developers" , "Core-Libs-Dev" > Envoy?: Mardi 3 Mai 2016 22:03:12 > Objet: Re: RFR 8155794 Move Objects.checkIndex BiFunction accepting methods to an internal package > > > > On 3 May 2016, at 07:05, Remi Forax wrote: > > > > Looks good to me. > > minor nitpick, neither checkFromToIndex() nor checkFromIndexSize() are > > instrinsic (now !) but i think they also should be annotated with > > @ForceInline in j.u.Objects to avoid the code to be asymmetric or weird if > > one of these methods is intrinsinfied later. > > > > I was tempted, but for the moment i am inclined to leave as is and revisit > if/when necessary. Trying to be conservative when using those annotations. Ok, in fact i wonder if @ForceInline on checkIndex is even useful because the VM considers the implementation as trivial, so it will be routinely inlined. > > Thanks, > Paul. > cheers, R?mi From erik.joelsson at oracle.com Wed May 4 08:15:51 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 4 May 2016 10:15:51 +0200 Subject: RFR(S): 8155950: Add minimal VM in JIB profile on linux-x86 In-Reply-To: <57299A1B.80709@oracle.com> References: <57299A1B.80709@oracle.com> Message-ID: <5729AFB7.3060007@oracle.com> Jib change looks good to me. /Erik On 2016-05-04 08:43, Leonid Mesnik wrote: > Please review this small change which adds minimal VM as a part of > default JIB profile on linux-x86. The fix also include quick > workaround for bug JDK-8155946 > . > > Bug: https://bugs.openjdk.java.net/browse/JDK-8155950 > Webrev (top): > http://cr.openjdk.java.net/~lmesnik/8155950/webrev.00/root/ > > Webrev(hotspot): > http://cr.openjdk.java.net/~lmesnik/8155950/webrev.00/hotspot/ > > > Testing: JPRT (with updated testing of minimal VM flags) > > Leonid From vladimir.x.ivanov at oracle.com Wed May 4 08:33:07 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 4 May 2016 11:33:07 +0300 Subject: RFR 8147039 : Incorrect locals and operands in compiled frames In-Reply-To: <5728F54B.8070007@oracle.com> References: <5728F54B.8070007@oracle.com> Message-ID: <5729B3C3.3040202@oracle.com> Looks good. Best regards, Vladimir Ivanov On 5/3/16 10:00 PM, Brent Christian wrote: > Hi, > > Please review this change which fixes buggy behavior (including SEGV) in > the experimental LiveStackFrame feature of StackWalker. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8147039 > Webrev: > http://cr.openjdk.java.net/~bchristi/8147039/webrev.02/ > > As suggested in the bug report, stack walking is reimplemented using > javaVFrame/vframe::java_sender. The native StackWalkerAnchor class is > updated (and renamed) with a similar interface and function to > vframeStream. I've also removed the now-unneeded > vframeStreamCommon::java_frame() function, added by 8140450. > > Thanks, > -Brent From david.holmes at oracle.com Wed May 4 08:40:14 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 4 May 2016 18:40:14 +1000 Subject: RFR(S): 8155950: Add minimal VM in JIB profile on linux-x86 In-Reply-To: <57299A1B.80709@oracle.com> References: <57299A1B.80709@oracle.com> Message-ID: <14aebb53-1580-4e71-f218-7793e80785aa@oracle.com> On 4/05/2016 4:43 PM, Leonid Mesnik wrote: > Please review this small change which adds minimal VM as a part of > default JIB profile on linux-x86. The fix also include quick workaround > for bug JDK-8155946 . > > Bug: https://bugs.openjdk.java.net/browse/JDK-8155950 > Webrev (top): > http://cr.openjdk.java.net/~lmesnik/8155950/webrev.00/root/ > I thought we should only be building minimal and server now? > Webrev(hotspot): > http://cr.openjdk.java.net/~lmesnik/8155950/webrev.00/hotspot/ > This needs a separate CR. I don't know how this breakage slipped in but it is a distinct issue. Thanks, David > Testing: JPRT (with updated testing of minimal VM flags) > > Leonid From Leonid.Mesnik at oracle.com Wed May 4 09:01:00 2016 From: Leonid.Mesnik at oracle.com (Leonid Mesnik) Date: Wed, 4 May 2016 12:01:00 +0300 Subject: RFR(S): 8155950: Add minimal VM in JIB profile on linux-x86 In-Reply-To: <14aebb53-1580-4e71-f218-7793e80785aa@oracle.com> References: <57299A1B.80709@oracle.com> <14aebb53-1580-4e71-f218-7793e80785aa@oracle.com> Message-ID: <5729BA4C.6040802@oracle.com> David On 04.05.2016 11:40, David Holmes wrote: > On 4/05/2016 4:43 PM, Leonid Mesnik wrote: >> Please review this small change which adds minimal VM as a part of >> default JIB profile on linux-x86. The fix also include quick workaround >> for bug JDK-8155946 . >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8155950 >> Webrev (top): >> http://cr.openjdk.java.net/~lmesnik/8155950/webrev.00/root/ >> > > I thought we should only be building minimal and server now? The client removal is covered by separate issue: 8154209: Remove client VM from default JIB profile on windows-x86 and linux-x86 The fix is ready (thanks to Mikael) however install bug JDK-8154410 jdk9 windows-i586 build fails on setting "--with-jvm-variants=server" is a blocker. So the plan is to push it later after JDK-8154410 is fixed or RE confirm that it is not a blocker anymore. > >> Webrev(hotspot): >> http://cr.openjdk.java.net/~lmesnik/8155950/webrev.00/hotspot/ >> > > This needs a separate CR. I don't know how this breakage slipped in > but it is a distinct issue. Ok, I will get a fix of JDK-8155946 first then and push only build changes in this fix. Leonid > > Thanks, > David > >> Testing: JPRT (with updated testing of minimal VM flags) >> >> Leonid From Leonid.Mesnik at oracle.com Wed May 4 09:17:00 2016 From: Leonid.Mesnik at oracle.com (Leonid Mesnik) Date: Wed, 4 May 2016 12:17:00 +0300 Subject: RFR(S): 8155950: Add minimal VM in JIB profile on linux-x86 In-Reply-To: <5729AFB7.3060007@oracle.com> References: <57299A1B.80709@oracle.com> <5729AFB7.3060007@oracle.com> Message-ID: <5729BE0C.2090602@oracle.com> Thank you for review. I will separate gc fix from this commit and push only build changes here . Leonid On 04.05.2016 11:15, Erik Joelsson wrote: > Jib change looks good to me. > > /Erik > > On 2016-05-04 08:43, Leonid Mesnik wrote: >> Please review this small change which adds minimal VM as a part of >> default JIB profile on linux-x86. The fix also include quick >> workaround for bug JDK-8155946 >> . >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8155950 >> Webrev (top): >> http://cr.openjdk.java.net/~lmesnik/8155950/webrev.00/root/ >> >> Webrev(hotspot): >> http://cr.openjdk.java.net/~lmesnik/8155950/webrev.00/hotspot/ >> >> >> Testing: JPRT (with updated testing of minimal VM flags) >> >> Leonid > From erik.joelsson at oracle.com Wed May 4 09:24:05 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 4 May 2016 11:24:05 +0200 Subject: RFR: JDK-8156018: Hotspot visual studio project generation broken Message-ID: <5729BFB5.7050201@oracle.com> With the new hotspot build, there was supposed to be support for creating a visual studio project, as was possible in the old build system. When creating the final changeset I missed including some of the files needed for that. Here are the changes as they were supposed to be, including removing the old version of the files since the old build has already been removed. These changes were made by Magnus Ihse Bursie. Christian T?rnqvist has verified that the generated project works. Bug: https://bugs.openjdk.java.net/browse/JDK-8156018 Webrev: http://cr.openjdk.java.net/~erikj/8156018/webrev.hotspot.01/ /Erik From marcus.larsson at oracle.com Wed May 4 09:38:40 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Wed, 4 May 2016 11:38:40 +0200 Subject: RFR: 8146948: Add help information to log tags In-Reply-To: <570F9F97.4060808@oracle.com> References: <570F9F97.4060808@oracle.com> Message-ID: <16e1097c-c6f3-dac3-f29b-ac3caba5f40b@oracle.com> Hi, Need a Review for this. Rebased the webrev to jdk9/hs in place. Thanks, Marcus On 04/14/2016 03:48 PM, Marcus Larsson wrote: > Hi, > > Please review the following patch to add descriptions to logging tagsets. > > Summary: > Tagsets may now be given a description in > logTagSetDescriptions.inline.hpp. All described tagsets are listed in > the -Xlog:help output as well as in the LogConfiguration::describe > output. The patch also adds trace level logging that lists *all* > tagsets in the VM (-Xlog:logging=trace). The previous 'logging=trace > logging' has been moved to 'logging=debug'. > > Example log output: > > ... > [0.544s][debug][logging] Described tag combinations: > [0.544s][debug][logging] logging: Logging for the log framework itself > ... > [0.544s][trace][logging] All available tag sets: arguments, > biasedlocking, classinit, classload, classload+constraints, > classload+preorder, classloaderdata, classpath, classresolve, > classunload, constraints, defaultmethods, ergo, exceptions, gc, > gc+age, gc+alloc, gc+alloc+region, gc+barrier, gc+bot, gc+classhisto, > gc+classhisto+start, gc+compaction, gc+cpu, gc+ergo, gc+ergo+cset, > gc+ergo+heap, gc+ergo+ihop, gc+ergo+refine, gc+freelist, > gc+freelist+census, gc+freelist+stats, gc+heap, gc+heap+coops, > gc+heap+exit, gc+heap+region, gc+humongous, gc+ihop, gc+jni, > gc+liveness, gc+marking, gc+marking+start, gc+metaspace, > gc+metaspace+alloc, gc+metaspace+freelist, gc+phases, gc+phases+start, > gc+phases+task, gc+phases+verify, gc+phases+verify+start, gc+plab, > gc+promotion, gc+ref, gc+ref+start, gc+refine, gc+region, gc+remset, > gc+remset+exit, gc+remset+scrub, gc+scavenge, gc+start, gc+state, > gc+stats, gc+stringdedup, gc+stringtable, gc+survivor, gc+sweep, > gc+task, gc+task+stats, gc+task+thread, gc+task+time, gc+tlab, > gc+verify, gc+verify+start, gc+workgang, heap+ergo, itables, jfr, > jfr+instrumentation, jfr+types, logging, logging+test, modules, > monitorinflation, monitormismatch, os, os+cpu, os+thread, pagesize, > protectiondomain, ref, safepoint, safepointcleanup, stacktrace, > startuptime, verification, vmoperation, vtables > > > Webrev: > http://cr.openjdk.java.net/~mlarsson/8146948/webrev.00/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8146948 > > Testing: > Internal VM tests through RBT > > Thanks, > Marcus > From ioi.lam at oracle.com Wed May 4 10:03:10 2016 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 04 May 2016 03:03:10 -0700 Subject: RFR: 8146948: Add help information to log tags In-Reply-To: <16e1097c-c6f3-dac3-f29b-ac3caba5f40b@oracle.com> References: <570F9F97.4060808@oracle.com> <16e1097c-c6f3-dac3-f29b-ac3caba5f40b@oracle.com> Message-ID: <5729C8DE.3020105@oracle.com> The changes look good to me, but maybe the bug title "Add help information to log tags" needs to changed? When I filed the bug, my main question was "what the heck is ihop", and the new output is "you can use ihop with gc+ergo", which doesn't really answer my question. Thanks - Ioi On 5/4/16 2:38 AM, Marcus Larsson wrote: > Hi, > > Need a Review for this. > > Rebased the webrev to jdk9/hs in place. > > > Thanks, > Marcus > > On 04/14/2016 03:48 PM, Marcus Larsson wrote: >> Hi, >> >> Please review the following patch to add descriptions to logging >> tagsets. >> >> Summary: >> Tagsets may now be given a description in >> logTagSetDescriptions.inline.hpp. All described tagsets are listed in >> the -Xlog:help output as well as in the LogConfiguration::describe >> output. The patch also adds trace level logging that lists *all* >> tagsets in the VM (-Xlog:logging=trace). The previous 'logging=trace >> logging' has been moved to 'logging=debug'. >> >> Example log output: >> >> ... >> [0.544s][debug][logging] Described tag combinations: >> [0.544s][debug][logging] logging: Logging for the log framework itself >> ... >> [0.544s][trace][logging] All available tag sets: arguments, >> biasedlocking, classinit, classload, classload+constraints, >> classload+preorder, classloaderdata, classpath, classresolve, >> classunload, constraints, defaultmethods, ergo, exceptions, gc, >> gc+age, gc+alloc, gc+alloc+region, gc+barrier, gc+bot, gc+classhisto, >> gc+classhisto+start, gc+compaction, gc+cpu, gc+ergo, gc+ergo+cset, >> gc+ergo+heap, gc+ergo+ihop, gc+ergo+refine, gc+freelist, >> gc+freelist+census, gc+freelist+stats, gc+heap, gc+heap+coops, >> gc+heap+exit, gc+heap+region, gc+humongous, gc+ihop, gc+jni, >> gc+liveness, gc+marking, gc+marking+start, gc+metaspace, >> gc+metaspace+alloc, gc+metaspace+freelist, gc+phases, >> gc+phases+start, gc+phases+task, gc+phases+verify, >> gc+phases+verify+start, gc+plab, gc+promotion, gc+ref, gc+ref+start, >> gc+refine, gc+region, gc+remset, gc+remset+exit, gc+remset+scrub, >> gc+scavenge, gc+start, gc+state, gc+stats, gc+stringdedup, >> gc+stringtable, gc+survivor, gc+sweep, gc+task, gc+task+stats, >> gc+task+thread, gc+task+time, gc+tlab, gc+verify, gc+verify+start, >> gc+workgang, heap+ergo, itables, jfr, jfr+instrumentation, jfr+types, >> logging, logging+test, modules, monitorinflation, monitormismatch, >> os, os+cpu, os+thread, pagesize, protectiondomain, ref, safepoint, >> safepointcleanup, stacktrace, startuptime, verification, vmoperation, >> vtables >> >> >> Webrev: >> http://cr.openjdk.java.net/~mlarsson/8146948/webrev.00/ >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8146948 >> >> Testing: >> Internal VM tests through RBT >> >> Thanks, >> Marcus >> > From david.holmes at oracle.com Wed May 4 10:23:51 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 4 May 2016 20:23:51 +1000 Subject: RFR(S): 8155950: Add minimal VM in JIB profile on linux-x86 In-Reply-To: <5729BA4C.6040802@oracle.com> References: <57299A1B.80709@oracle.com> <14aebb53-1580-4e71-f218-7793e80785aa@oracle.com> <5729BA4C.6040802@oracle.com> Message-ID: On 4/05/2016 7:01 PM, Leonid Mesnik wrote: > David > > On 04.05.2016 11:40, David Holmes wrote: >> On 4/05/2016 4:43 PM, Leonid Mesnik wrote: >>> Please review this small change which adds minimal VM as a part of >>> default JIB profile on linux-x86. The fix also include quick workaround >>> for bug JDK-8155946 . >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8155950 >>> Webrev (top): >>> http://cr.openjdk.java.net/~lmesnik/8155950/webrev.00/root/ >>> >> >> I thought we should only be building minimal and server now? > The client removal is covered by separate issue: > 8154209: Remove client VM from default JIB profile on windows-x86 and > linux-x86 > > The fix is ready (thanks to Mikael) however install bug JDK-8154410 > jdk9 windows-i586 build fails on setting "--with-jvm-variants=server" > > is a blocker. So the plan is to push it later after JDK-8154410 is fixed > or RE confirm that it is not a blocker anymore. Okay I suppose - seems like an awful lot of overhead to touch this code multiple times. >> >>> Webrev(hotspot): >>> http://cr.openjdk.java.net/~lmesnik/8155950/webrev.00/hotspot/ >>> >> >> This needs a separate CR. I don't know how this breakage slipped in >> but it is a distinct issue. > Ok, I will get a fix of JDK-8155946 first then and push only build > changes in this fix. OK. They can both be pushed together - just two separate changesets. Thanks, David > Leonid >> >> Thanks, >> David >> >>> Testing: JPRT (with updated testing of minimal VM flags) >>> >>> Leonid > From Leonid.Mesnik at oracle.com Wed May 4 10:27:59 2016 From: Leonid.Mesnik at oracle.com (Leonid Mesnik) Date: Wed, 4 May 2016 13:27:59 +0300 Subject: RFR(S): 8155950: Add minimal VM in JIB profile on linux-x86 In-Reply-To: References: <57299A1B.80709@oracle.com> <14aebb53-1580-4e71-f218-7793e80785aa@oracle.com> <5729BA4C.6040802@oracle.com> Message-ID: <5729CEAF.2060207@oracle.com> Hi On 04.05.2016 13:23, David Holmes wrote: > On 4/05/2016 7:01 PM, Leonid Mesnik wrote: >> David >> >> On 04.05.2016 11:40, David Holmes wrote: >>> On 4/05/2016 4:43 PM, Leonid Mesnik wrote: >>>> Please review this small change which adds minimal VM as a part of >>>> default JIB profile on linux-x86. The fix also include quick >>>> workaround >>>> for bug JDK-8155946 >>>> . >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8155950 >>>> Webrev (top): >>>> http://cr.openjdk.java.net/~lmesnik/8155950/webrev.00/root/ >>>> >>> >>> I thought we should only be building minimal and server now? >> The client removal is covered by separate issue: >> 8154209: Remove client VM from default JIB profile on windows-x86 and >> linux-x86 >> >> The fix is ready (thanks to Mikael) however install bug JDK-8154410 >> jdk9 windows-i586 build fails on setting "--with-jvm-variants=server" >> >> is a blocker. So the plan is to push it later after JDK-8154410 is fixed >> or RE confirm that it is not a blocker anymore. > > Okay I suppose - seems like an awful lot of overhead to touch this > code multiple times. Yes, it would be simple to have a single fix. However I don't really know when it will be possible to remove client and it is needed to add minimal testing ASAP. > >>> >>>> Webrev(hotspot): >>>> http://cr.openjdk.java.net/~lmesnik/8155950/webrev.00/hotspot/ >>>> >>> >>> This needs a separate CR. I don't know how this breakage slipped in >>> but it is a distinct issue. >> Ok, I will get a fix of JDK-8155946 first then and push only build >> changes in this fix. > > OK. They can both be pushed together - just two separate changesets. Thanks, I will send separate review for gc team. Leonid > > Thanks, > David > >> Leonid >>> >>> Thanks, >>> David >>> >>>> Testing: JPRT (with updated testing of minimal VM flags) >>>> >>>> Leonid >> From marcus.larsson at oracle.com Wed May 4 10:56:30 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Wed, 4 May 2016 12:56:30 +0200 Subject: RFR: 8146948: Add help information to log tags In-Reply-To: <5729C8DE.3020105@oracle.com> References: <570F9F97.4060808@oracle.com> <16e1097c-c6f3-dac3-f29b-ac3caba5f40b@oracle.com> <5729C8DE.3020105@oracle.com> Message-ID: <4ec8b959-e9ee-e169-10ee-afda08abb0b8@oracle.com> On 05/04/2016 12:03 PM, Ioi Lam wrote: > The changes look good to me, but maybe the bug title "Add help > information to log tags" needs to changed? > > When I filed the bug, my main question was "what the heck is ihop", > and the new output is "you can use ihop with gc+ergo", which doesn't > really answer my question. Fair point. I can update the title to "Enable listing of LogTagSets and add support for LogTagSet descriptions", if no one else has a better suggestion. As is mentioned in the bug, the meaning of each tag depends on the context it is used in, and so ideally there will be some tagset description explaining the meaning of non-obvious tags. Thanks, Marcus > > Thanks > - Ioi > > On 5/4/16 2:38 AM, Marcus Larsson wrote: >> Hi, >> >> Need a Review for this. >> >> Rebased the webrev to jdk9/hs in place. >> >> >> Thanks, >> Marcus >> >> On 04/14/2016 03:48 PM, Marcus Larsson wrote: >>> Hi, >>> >>> Please review the following patch to add descriptions to logging >>> tagsets. >>> >>> Summary: >>> Tagsets may now be given a description in >>> logTagSetDescriptions.inline.hpp. All described tagsets are listed >>> in the -Xlog:help output as well as in the >>> LogConfiguration::describe output. The patch also adds trace level >>> logging that lists *all* tagsets in the VM (-Xlog:logging=trace). >>> The previous 'logging=trace logging' has been moved to 'logging=debug'. >>> >>> Example log output: >>> >>> ... >>> [0.544s][debug][logging] Described tag combinations: >>> [0.544s][debug][logging] logging: Logging for the log framework itself >>> ... >>> [0.544s][trace][logging] All available tag sets: arguments, >>> biasedlocking, classinit, classload, classload+constraints, >>> classload+preorder, classloaderdata, classpath, classresolve, >>> classunload, constraints, defaultmethods, ergo, exceptions, gc, >>> gc+age, gc+alloc, gc+alloc+region, gc+barrier, gc+bot, >>> gc+classhisto, gc+classhisto+start, gc+compaction, gc+cpu, gc+ergo, >>> gc+ergo+cset, gc+ergo+heap, gc+ergo+ihop, gc+ergo+refine, >>> gc+freelist, gc+freelist+census, gc+freelist+stats, gc+heap, >>> gc+heap+coops, gc+heap+exit, gc+heap+region, gc+humongous, gc+ihop, >>> gc+jni, gc+liveness, gc+marking, gc+marking+start, gc+metaspace, >>> gc+metaspace+alloc, gc+metaspace+freelist, gc+phases, >>> gc+phases+start, gc+phases+task, gc+phases+verify, >>> gc+phases+verify+start, gc+plab, gc+promotion, gc+ref, gc+ref+start, >>> gc+refine, gc+region, gc+remset, gc+remset+exit, gc+remset+scrub, >>> gc+scavenge, gc+start, gc+state, gc+stats, gc+stringdedup, >>> gc+stringtable, gc+survivor, gc+sweep, gc+task, gc+task+stats, >>> gc+task+thread, gc+task+time, gc+tlab, gc+verify, gc+verify+start, >>> gc+workgang, heap+ergo, itables, jfr, jfr+instrumentation, >>> jfr+types, logging, logging+test, modules, monitorinflation, >>> monitormismatch, os, os+cpu, os+thread, pagesize, protectiondomain, >>> ref, safepoint, safepointcleanup, stacktrace, startuptime, >>> verification, vmoperation, vtables >>> >>> >>> Webrev: >>> http://cr.openjdk.java.net/~mlarsson/8146948/webrev.00/ >>> >>> Issue: >>> https://bugs.openjdk.java.net/browse/JDK-8146948 >>> >>> Testing: >>> Internal VM tests through RBT >>> >>> Thanks, >>> Marcus >>> >> > From ioi.lam at oracle.com Wed May 4 11:04:57 2016 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 04 May 2016 04:04:57 -0700 Subject: RFR: 8146948: Add help information to log tags In-Reply-To: <4ec8b959-e9ee-e169-10ee-afda08abb0b8@oracle.com> References: <570F9F97.4060808@oracle.com> <16e1097c-c6f3-dac3-f29b-ac3caba5f40b@oracle.com> <5729C8DE.3020105@oracle.com> <4ec8b959-e9ee-e169-10ee-afda08abb0b8@oracle.com> Message-ID: <5729D759.8050402@oracle.com> Sounds good to me. Thanks Marcus! - Ioi On 5/4/16 3:56 AM, Marcus Larsson wrote: > > On 05/04/2016 12:03 PM, Ioi Lam wrote: >> The changes look good to me, but maybe the bug title "Add help >> information to log tags" needs to changed? >> >> When I filed the bug, my main question was "what the heck is ihop", >> and the new output is "you can use ihop with gc+ergo", which doesn't >> really answer my question. > > Fair point. I can update the title to "Enable listing of LogTagSets > and add support for LogTagSet descriptions", if no one else has a > better suggestion. > > As is mentioned in the bug, the meaning of each tag depends on the > context it is used in, and so ideally there will be some tagset > description explaining the meaning of non-obvious tags. > > Thanks, > Marcus > >> >> Thanks >> - Ioi >> >> On 5/4/16 2:38 AM, Marcus Larsson wrote: >>> Hi, >>> >>> Need a Review for this. >>> >>> Rebased the webrev to jdk9/hs in place. >>> >>> >>> Thanks, >>> Marcus >>> >>> On 04/14/2016 03:48 PM, Marcus Larsson wrote: >>>> Hi, >>>> >>>> Please review the following patch to add descriptions to logging >>>> tagsets. >>>> >>>> Summary: >>>> Tagsets may now be given a description in >>>> logTagSetDescriptions.inline.hpp. All described tagsets are listed >>>> in the -Xlog:help output as well as in the >>>> LogConfiguration::describe output. The patch also adds trace level >>>> logging that lists *all* tagsets in the VM (-Xlog:logging=trace). >>>> The previous 'logging=trace logging' has been moved to >>>> 'logging=debug'. >>>> >>>> Example log output: >>>> >>>> ... >>>> [0.544s][debug][logging] Described tag combinations: >>>> [0.544s][debug][logging] logging: Logging for the log framework >>>> itself >>>> ... >>>> [0.544s][trace][logging] All available tag sets: arguments, >>>> biasedlocking, classinit, classload, classload+constraints, >>>> classload+preorder, classloaderdata, classpath, classresolve, >>>> classunload, constraints, defaultmethods, ergo, exceptions, gc, >>>> gc+age, gc+alloc, gc+alloc+region, gc+barrier, gc+bot, >>>> gc+classhisto, gc+classhisto+start, gc+compaction, gc+cpu, gc+ergo, >>>> gc+ergo+cset, gc+ergo+heap, gc+ergo+ihop, gc+ergo+refine, >>>> gc+freelist, gc+freelist+census, gc+freelist+stats, gc+heap, >>>> gc+heap+coops, gc+heap+exit, gc+heap+region, gc+humongous, gc+ihop, >>>> gc+jni, gc+liveness, gc+marking, gc+marking+start, gc+metaspace, >>>> gc+metaspace+alloc, gc+metaspace+freelist, gc+phases, >>>> gc+phases+start, gc+phases+task, gc+phases+verify, >>>> gc+phases+verify+start, gc+plab, gc+promotion, gc+ref, >>>> gc+ref+start, gc+refine, gc+region, gc+remset, gc+remset+exit, >>>> gc+remset+scrub, gc+scavenge, gc+start, gc+state, gc+stats, >>>> gc+stringdedup, gc+stringtable, gc+survivor, gc+sweep, gc+task, >>>> gc+task+stats, gc+task+thread, gc+task+time, gc+tlab, gc+verify, >>>> gc+verify+start, gc+workgang, heap+ergo, itables, jfr, >>>> jfr+instrumentation, jfr+types, logging, logging+test, modules, >>>> monitorinflation, monitormismatch, os, os+cpu, os+thread, pagesize, >>>> protectiondomain, ref, safepoint, safepointcleanup, stacktrace, >>>> startuptime, verification, vmoperation, vtables >>>> >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~mlarsson/8146948/webrev.00/ >>>> >>>> Issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8146948 >>>> >>>> Testing: >>>> Internal VM tests through RBT >>>> >>>> Thanks, >>>> Marcus >>>> >>> >> > From marcus.larsson at oracle.com Wed May 4 11:19:44 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Wed, 4 May 2016 13:19:44 +0200 Subject: RFR: 8146948: Enable listing of LogTagSets and add support for LogTagSet descriptions (was: Add help information to log tags) In-Reply-To: <5729D759.8050402@oracle.com> References: <570F9F97.4060808@oracle.com> <16e1097c-c6f3-dac3-f29b-ac3caba5f40b@oracle.com> <5729C8DE.3020105@oracle.com> <4ec8b959-e9ee-e169-10ee-afda08abb0b8@oracle.com> <5729D759.8050402@oracle.com> Message-ID: Great, thanks for reviewing! Marcus On 05/04/2016 01:04 PM, Ioi Lam wrote: > Sounds good to me. Thanks Marcus! > > - Ioi > > On 5/4/16 3:56 AM, Marcus Larsson wrote: >> >> On 05/04/2016 12:03 PM, Ioi Lam wrote: >>> The changes look good to me, but maybe the bug title "Add help >>> information to log tags" needs to changed? >>> >>> When I filed the bug, my main question was "what the heck is ihop", >>> and the new output is "you can use ihop with gc+ergo", which doesn't >>> really answer my question. >> >> Fair point. I can update the title to "Enable listing of LogTagSets >> and add support for LogTagSet descriptions", if no one else has a >> better suggestion. >> >> As is mentioned in the bug, the meaning of each tag depends on the >> context it is used in, and so ideally there will be some tagset >> description explaining the meaning of non-obvious tags. >> >> Thanks, >> Marcus >> >>> >>> Thanks >>> - Ioi >>> >>> On 5/4/16 2:38 AM, Marcus Larsson wrote: >>>> Hi, >>>> >>>> Need a Review for this. >>>> >>>> Rebased the webrev to jdk9/hs in place. >>>> >>>> >>>> Thanks, >>>> Marcus >>>> >>>> On 04/14/2016 03:48 PM, Marcus Larsson wrote: >>>>> Hi, >>>>> >>>>> Please review the following patch to add descriptions to logging >>>>> tagsets. >>>>> >>>>> Summary: >>>>> Tagsets may now be given a description in >>>>> logTagSetDescriptions.inline.hpp. All described tagsets are listed >>>>> in the -Xlog:help output as well as in the >>>>> LogConfiguration::describe output. The patch also adds trace level >>>>> logging that lists *all* tagsets in the VM (-Xlog:logging=trace). >>>>> The previous 'logging=trace logging' has been moved to >>>>> 'logging=debug'. >>>>> >>>>> Example log output: >>>>> >>>>> ... >>>>> [0.544s][debug][logging] Described tag combinations: >>>>> [0.544s][debug][logging] logging: Logging for the log framework >>>>> itself >>>>> ... >>>>> [0.544s][trace][logging] All available tag sets: arguments, >>>>> biasedlocking, classinit, classload, classload+constraints, >>>>> classload+preorder, classloaderdata, classpath, classresolve, >>>>> classunload, constraints, defaultmethods, ergo, exceptions, gc, >>>>> gc+age, gc+alloc, gc+alloc+region, gc+barrier, gc+bot, >>>>> gc+classhisto, gc+classhisto+start, gc+compaction, gc+cpu, >>>>> gc+ergo, gc+ergo+cset, gc+ergo+heap, gc+ergo+ihop, gc+ergo+refine, >>>>> gc+freelist, gc+freelist+census, gc+freelist+stats, gc+heap, >>>>> gc+heap+coops, gc+heap+exit, gc+heap+region, gc+humongous, >>>>> gc+ihop, gc+jni, gc+liveness, gc+marking, gc+marking+start, >>>>> gc+metaspace, gc+metaspace+alloc, gc+metaspace+freelist, >>>>> gc+phases, gc+phases+start, gc+phases+task, gc+phases+verify, >>>>> gc+phases+verify+start, gc+plab, gc+promotion, gc+ref, >>>>> gc+ref+start, gc+refine, gc+region, gc+remset, gc+remset+exit, >>>>> gc+remset+scrub, gc+scavenge, gc+start, gc+state, gc+stats, >>>>> gc+stringdedup, gc+stringtable, gc+survivor, gc+sweep, gc+task, >>>>> gc+task+stats, gc+task+thread, gc+task+time, gc+tlab, gc+verify, >>>>> gc+verify+start, gc+workgang, heap+ergo, itables, jfr, >>>>> jfr+instrumentation, jfr+types, logging, logging+test, modules, >>>>> monitorinflation, monitormismatch, os, os+cpu, os+thread, >>>>> pagesize, protectiondomain, ref, safepoint, safepointcleanup, >>>>> stacktrace, startuptime, verification, vmoperation, vtables >>>>> >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~mlarsson/8146948/webrev.00/ >>>>> >>>>> Issue: >>>>> https://bugs.openjdk.java.net/browse/JDK-8146948 >>>>> >>>>> Testing: >>>>> Internal VM tests through RBT >>>>> >>>>> Thanks, >>>>> Marcus >>>>> >>>> >>> >> > From marcus.larsson at oracle.com Wed May 4 11:26:05 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Wed, 4 May 2016 13:26:05 +0200 Subject: RFR: 8146948: Enable listing of LogTagSets and add support for LogTagSet descriptions In-Reply-To: References: <570F9F97.4060808@oracle.com> <16e1097c-c6f3-dac3-f29b-ac3caba5f40b@oracle.com> <5729C8DE.3020105@oracle.com> <4ec8b959-e9ee-e169-10ee-afda08abb0b8@oracle.com> <5729D759.8050402@oracle.com> Message-ID: <95efd59f-6cf6-b8ff-027d-33de2a80d8c1@oracle.com> Hmm, I still need a capital R reviewer to look at this. On 05/04/2016 01:19 PM, Marcus Larsson wrote: > Great, thanks for reviewing! > > Marcus > > > On 05/04/2016 01:04 PM, Ioi Lam wrote: >> Sounds good to me. Thanks Marcus! >> >> - Ioi >> >> On 5/4/16 3:56 AM, Marcus Larsson wrote: >>> >>> On 05/04/2016 12:03 PM, Ioi Lam wrote: >>>> The changes look good to me, but maybe the bug title "Add help >>>> information to log tags" needs to changed? >>>> >>>> When I filed the bug, my main question was "what the heck is ihop", >>>> and the new output is "you can use ihop with gc+ergo", which >>>> doesn't really answer my question. >>> >>> Fair point. I can update the title to "Enable listing of LogTagSets >>> and add support for LogTagSet descriptions", if no one else has a >>> better suggestion. >>> >>> As is mentioned in the bug, the meaning of each tag depends on the >>> context it is used in, and so ideally there will be some tagset >>> description explaining the meaning of non-obvious tags. >>> >>> Thanks, >>> Marcus >>> >>>> >>>> Thanks >>>> - Ioi >>>> >>>> On 5/4/16 2:38 AM, Marcus Larsson wrote: >>>>> Hi, >>>>> >>>>> Need a Review for this. >>>>> >>>>> Rebased the webrev to jdk9/hs in place. >>>>> >>>>> >>>>> Thanks, >>>>> Marcus >>>>> >>>>> On 04/14/2016 03:48 PM, Marcus Larsson wrote: >>>>>> Hi, >>>>>> >>>>>> Please review the following patch to add descriptions to logging >>>>>> tagsets. >>>>>> >>>>>> Summary: >>>>>> Tagsets may now be given a description in >>>>>> logTagSetDescriptions.inline.hpp. All described tagsets are >>>>>> listed in the -Xlog:help output as well as in the >>>>>> LogConfiguration::describe output. The patch also adds trace >>>>>> level logging that lists *all* tagsets in the VM >>>>>> (-Xlog:logging=trace). The previous 'logging=trace logging' has >>>>>> been moved to 'logging=debug'. >>>>>> >>>>>> Example log output: >>>>>> >>>>>> ... >>>>>> [0.544s][debug][logging] Described tag combinations: >>>>>> [0.544s][debug][logging] logging: Logging for the log framework >>>>>> itself >>>>>> ... >>>>>> [0.544s][trace][logging] All available tag sets: arguments, >>>>>> biasedlocking, classinit, classload, classload+constraints, >>>>>> classload+preorder, classloaderdata, classpath, classresolve, >>>>>> classunload, constraints, defaultmethods, ergo, exceptions, gc, >>>>>> gc+age, gc+alloc, gc+alloc+region, gc+barrier, gc+bot, >>>>>> gc+classhisto, gc+classhisto+start, gc+compaction, gc+cpu, >>>>>> gc+ergo, gc+ergo+cset, gc+ergo+heap, gc+ergo+ihop, >>>>>> gc+ergo+refine, gc+freelist, gc+freelist+census, >>>>>> gc+freelist+stats, gc+heap, gc+heap+coops, gc+heap+exit, >>>>>> gc+heap+region, gc+humongous, gc+ihop, gc+jni, gc+liveness, >>>>>> gc+marking, gc+marking+start, gc+metaspace, gc+metaspace+alloc, >>>>>> gc+metaspace+freelist, gc+phases, gc+phases+start, >>>>>> gc+phases+task, gc+phases+verify, gc+phases+verify+start, >>>>>> gc+plab, gc+promotion, gc+ref, gc+ref+start, gc+refine, >>>>>> gc+region, gc+remset, gc+remset+exit, gc+remset+scrub, >>>>>> gc+scavenge, gc+start, gc+state, gc+stats, gc+stringdedup, >>>>>> gc+stringtable, gc+survivor, gc+sweep, gc+task, gc+task+stats, >>>>>> gc+task+thread, gc+task+time, gc+tlab, gc+verify, >>>>>> gc+verify+start, gc+workgang, heap+ergo, itables, jfr, >>>>>> jfr+instrumentation, jfr+types, logging, logging+test, modules, >>>>>> monitorinflation, monitormismatch, os, os+cpu, os+thread, >>>>>> pagesize, protectiondomain, ref, safepoint, safepointcleanup, >>>>>> stacktrace, startuptime, verification, vmoperation, vtables >>>>>> >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~mlarsson/8146948/webrev.00/ >>>>>> >>>>>> Issue: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8146948 >>>>>> >>>>>> Testing: >>>>>> Internal VM tests through RBT >>>>>> >>>>>> Thanks, >>>>>> Marcus >>>>>> >>>>> >>>> >>> >> > From Leonid.Mesnik at oracle.com Wed May 4 14:10:52 2016 From: Leonid.Mesnik at oracle.com (Leonid Mesnik) Date: Wed, 4 May 2016 17:10:52 +0300 Subject: RFR(S): 8155950: Add minimal VM in JIB profile on linux-x86 In-Reply-To: References: <57299A1B.80709@oracle.com> <14aebb53-1580-4e71-f218-7793e80785aa@oracle.com> <5729BA4C.6040802@oracle.com> Message-ID: <572A02EC.3010806@oracle.com> The hotspot changes are fixed separately and the final fix is only changes in the root. It remains the same. http://cr.openjdk.java.net/~lmesnik/8155950/webrev.00/root/ Leonid On 04.05.2016 13:23, David Holmes wrote: > On 4/05/2016 7:01 PM, Leonid Mesnik wrote: >> David >> >> On 04.05.2016 11:40, David Holmes wrote: >>> On 4/05/2016 4:43 PM, Leonid Mesnik wrote: >>>> Please review this small change which adds minimal VM as a part of >>>> default JIB profile on linux-x86. The fix also include quick >>>> workaround >>>> for bug JDK-8155946 >>>> . >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8155950 >>>> Webrev (top): >>>> http://cr.openjdk.java.net/~lmesnik/8155950/webrev.00/root/ >>>> >>> >>> I thought we should only be building minimal and server now? >> The client removal is covered by separate issue: >> 8154209: Remove client VM from default JIB profile on windows-x86 and >> linux-x86 >> >> The fix is ready (thanks to Mikael) however install bug JDK-8154410 >> jdk9 windows-i586 build fails on setting "--with-jvm-variants=server" >> >> is a blocker. So the plan is to push it later after JDK-8154410 is fixed >> or RE confirm that it is not a blocker anymore. > > Okay I suppose - seems like an awful lot of overhead to touch this > code multiple times. > >>> >>>> Webrev(hotspot): >>>> http://cr.openjdk.java.net/~lmesnik/8155950/webrev.00/hotspot/ >>>> >>> >>> This needs a separate CR. I don't know how this breakage slipped in >>> but it is a distinct issue. >> Ok, I will get a fix of JDK-8155946 first then and push only build >> changes in this fix. > > OK. They can both be pushed together - just two separate changesets. > > Thanks, > David > >> Leonid >>> >>> Thanks, >>> David >>> >>>> Testing: JPRT (with updated testing of minimal VM flags) >>>> >>>> Leonid >> From vladimir.x.ivanov at oracle.com Wed May 4 15:16:31 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 4 May 2016 18:16:31 +0300 Subject: RFR 8155794 Move Objects.checkIndex BiFunction accepting methods to an internal package In-Reply-To: <9F2B1347-C76F-48A2-8433-8E9362CED4E8@oracle.com> References: <9F2B1347-C76F-48A2-8433-8E9362CED4E8@oracle.com> Message-ID: <572A124F.4000000@oracle.com> Looks good. Best regards, Vladimir Ivanov On 5/3/16 1:37 AM, Paul Sandoz wrote: > Hi, > > Please review: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155794-checkIndex-bifunc-internal-jdk/webrev/ > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155794-checkIndex-bifunc-internal-hotspot/webrev/ > > This patch is based on that for 8155258 (VarHandle impl improvements) [1] sent previously. > > The hotspot changes are really small. Likewise for the 8155258 changes is there is precedent in such cases to push through jdk9-dev rather than hs? > > CCC reviewers strongly indicated for the advanced methods that can customise the exceptions: "You aren't gonna need it?. > > For expediency I propose to move such methods to an internal class jdk.internal.util.Preconditions. I would still like to sweep through java.base and leverage these methods while preserving exception reporting where possible. > > The hotspot changes are just for renaming of the intrinsic method signatures. Since the intrinsic method is now internal i have added an @ForceInline on the corresponding public method, given the potential for this to be used in performance sensitive code. > > > JPRT core and hotspot tests pass. > > Paul. > > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/040740.html > From gerard.ziemski at oracle.com Wed May 4 16:02:00 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Wed, 4 May 2016 11:02:00 -0500 Subject: RFR (XS): rev3 8152856: Xcode 7.3 -Wshift-negative-value compile failure on Mac OS X In-Reply-To: <185B4145-0862-44AF-93F5-C75F81056195@oracle.com> References: <185B4145-0862-44AF-93F5-C75F81056195@oracle.com> Message-ID: PING Can I please have a review of this small fix? I have removed makefile change, which is no longer needed, so this should be non-controversial to review: bug: https://bugs.openjdk.java.net/browse/JDK-8152856 webrev: http://cr.openjdk.java.net/~gziemski/8152856_rev3 cheers > On Apr 6, 2016, at 11:35 AM, Gerard Ziemski wrote: > > hi all, > > I have implemented and tested out the new proposed fix using constant instead of casts. Please review this new fix: > > bug: https://bugs.openjdk.java.net/browse/JDK-8152856 > webrev: http://cr.openjdk.java.net/~gziemski/8152856_rev2 > > Passes JPRT hotspot and RBT hotspot/test/:hotspot_runtime > > > cheers > >> On Mar 31, 2016, at 9:08 AM, Gerard Ziemski wrote: >> >> hi all, >> >> Since no-one has reviewed this yet and in the meantime we changed https://wiki.openjdk.java.net/display/HotSpot/StyleGuide to discourage using enums in hotspot (see JDK-8153116 for more details) I?m going to withdraw this proposed fix and try doing it by replacing enums with constant literals instead of using casts on enums. >> >> I therefore withdraw this fix for now. >> >> >> cheers >> >>> On Mar 29, 2016, at 4:30 PM, Gerard Ziemski wrote: >>> >>> hi all, >>> >>> Please review this small fix that enables Xcde 7.3 support for building hotspot, which involved 2 things: >>> >>> - modify gcc.make to add support for 7.3 version of clang compiler >>> - modify src/cpu/x86/vm/stubGenerator_x86_64.cpp, src/share/vm/oops/klass.hpp and src/share/vm/opto/library_call.cpp to cast 4 instances of signed int to unsigned when using shift operator to avoid "-Wshift-negative-value" warning. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8152856 >>> http://cr.openjdk.java.net/~gziemski/8152856_rev1 >>> >>> Passes JPRT hotspot on all platforms >>> >> > From vladimir.x.ivanov at oracle.com Wed May 4 16:19:48 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 4 May 2016 19:19:48 +0300 Subject: RFR 8155258: VarHandle implementation improvements In-Reply-To: <43CCC631-B8BA-40BF-A292-7F1ED00FDCDD@oracle.com> References: <43CCC631-B8BA-40BF-A292-7F1ED00FDCDD@oracle.com> Message-ID: <572A2124.9030600@oracle.com> Looks good. I'm fine with pushing it directly into jdk9/dev, since the change just relaxes the assert and the risk of a merge conflict is very small. Best regards, Vladimir Ivanov PS: I wonder whether the MH cache in VarHandle (VarHandle.typesAndInvokers.methodHandle_table) should be idempotent or not. In the past, we had to make some caches in j.l.i idempotent (specifically, Invokers.invokers and MethodTypeForm.methodHandles). The problem was that the JVM can cache a method the MH points to (e.g., inline caches in generated code for MH invokers). If it happens, the JVM doesn't expect to observe 2 different instances of the MH, otherwise an assertion is fired. I can't say for sure it's not the case for VarHandles as well. On 5/3/16 1:18 AM, Paul Sandoz wrote: > Hi, > > Please review: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155258-vhs-impl-improvements-jdk/webrev/ > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8155258-vhs-impl-improvements-hotspot/webrev/ > > The hotspot changes are really small. Is there is precedent in such cases to push through jdk9-dev rather than hs, thus speeding up the integration? > > There are a bunch of improvements (mostly space/time): > > 1) By default a VarHandle does not hold its method types for access mode methods. Instead the erased types are held on VarForm (this shared across many VH instances) and are leveraged by the guard methods (see 4). > 1.1) The non-erased method types are created on demand and cached (see 3). > > 2) Remove the use of ClassValue to hold VarForm instances. Each VarHandle implement holds its VarForm as a static instance. MemberNames to each access mode method implementation are still calculated on construction (this can be revisited to be lazy as a further issue). > > 3) A VarHandle caches invoker-based MethodHandles (access mode method type prefixed with VarHandle as the first parameter) to the corresponding MemberNames held on VarForm. Such handles are used by the VarHandle.toMethodHandle, by the guard methods (see 4), or general linkers/invokers. > > 4) The guard methods (on VarHandleGuards) were revamped to: > 4.1) leverage the erased types in 1) > 4.2) optimize for the void calling case (dropping the return value) when linking to a non-void access mode method. This is an edge case but avoids surprises (e.g. dropping the return value of a CompareAndExchange). This leverages a little known fact of invokehandle linking where it is safe to drop the return value (John assures me this is safe!), and required a slight tweak to hotspot for verification under fastdebug execution. > 4.3) leverage the cached invoker method handle in 3) for the case where boxing/conversion is required, with an asType transformation. This is the non-optimal path, but is much better than before since the invoker method handle is a constant. > > > JPRT core and hotspot tests pass. > > Paul. > From vladimir.x.ivanov at oracle.com Wed May 4 16:20:34 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 4 May 2016 19:20:34 +0300 Subject: RFR (XS): rev3 8152856: Xcode 7.3 -Wshift-negative-value compile failure on Mac OS X In-Reply-To: References: <185B4145-0862-44AF-93F5-C75F81056195@oracle.com> Message-ID: <572A2152.1030909@oracle.com> Looks good. Best regards, Vladimir Ivanov On 5/4/16 7:02 PM, Gerard Ziemski wrote: > PING > > Can I please have a review of this small fix? I have removed makefile change, which is no longer needed, so this should be non-controversial to review: > > bug: https://bugs.openjdk.java.net/browse/JDK-8152856 > webrev: http://cr.openjdk.java.net/~gziemski/8152856_rev3 > > > cheers > >> On Apr 6, 2016, at 11:35 AM, Gerard Ziemski wrote: >> >> hi all, >> >> I have implemented and tested out the new proposed fix using constant instead of casts. Please review this new fix: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8152856 >> webrev: http://cr.openjdk.java.net/~gziemski/8152856_rev2 >> >> Passes JPRT hotspot and RBT hotspot/test/:hotspot_runtime >> >> >> cheers >> >>> On Mar 31, 2016, at 9:08 AM, Gerard Ziemski wrote: >>> >>> hi all, >>> >>> Since no-one has reviewed this yet and in the meantime we changed https://wiki.openjdk.java.net/display/HotSpot/StyleGuide to discourage using enums in hotspot (see JDK-8153116 for more details) I?m going to withdraw this proposed fix and try doing it by replacing enums with constant literals instead of using casts on enums. >>> >>> I therefore withdraw this fix for now. >>> >>> >>> cheers >>> >>>> On Mar 29, 2016, at 4:30 PM, Gerard Ziemski wrote: >>>> >>>> hi all, >>>> >>>> Please review this small fix that enables Xcde 7.3 support for building hotspot, which involved 2 things: >>>> >>>> - modify gcc.make to add support for 7.3 version of clang compiler >>>> - modify src/cpu/x86/vm/stubGenerator_x86_64.cpp, src/share/vm/oops/klass.hpp and src/share/vm/opto/library_call.cpp to cast 4 instances of signed int to unsigned when using shift operator to avoid "-Wshift-negative-value" warning. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8152856 >>>> http://cr.openjdk.java.net/~gziemski/8152856_rev1 >>>> >>>> Passes JPRT hotspot on all platforms >>>> >>> >> > From gerard.ziemski at oracle.com Wed May 4 16:27:00 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Wed, 4 May 2016 11:27:00 -0500 Subject: RFR (XS): rev3 8152856: Xcode 7.3 -Wshift-negative-value compile failure on Mac OS X In-Reply-To: <572A2152.1030909@oracle.com> References: <185B4145-0862-44AF-93F5-C75F81056195@oracle.com> <572A2152.1030909@oracle.com> Message-ID: <5A2F6F48-F984-40D0-BB0B-9742F4C1022E@oracle.com> Thank you Vladimir for the review. cheers > On May 4, 2016, at 11:20 AM, Vladimir Ivanov wrote: > > Looks good. > > Best regards, > Vladimir Ivanov > > On 5/4/16 7:02 PM, Gerard Ziemski wrote: >> PING >> >> Can I please have a review of this small fix? I have removed makefile change, which is no longer needed, so this should be non-controversial to review: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8152856 >> webrev: http://cr.openjdk.java.net/~gziemski/8152856_rev3 >> >> >> cheers >> >>> On Apr 6, 2016, at 11:35 AM, Gerard Ziemski wrote: >>> >>> hi all, >>> >>> I have implemented and tested out the new proposed fix using constant instead of casts. Please review this new fix: >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8152856 >>> webrev: http://cr.openjdk.java.net/~gziemski/8152856_rev2 >>> >>> Passes JPRT hotspot and RBT hotspot/test/:hotspot_runtime >>> >>> >>> cheers >>> >>>> On Mar 31, 2016, at 9:08 AM, Gerard Ziemski wrote: >>>> >>>> hi all, >>>> >>>> Since no-one has reviewed this yet and in the meantime we changed https://wiki.openjdk.java.net/display/HotSpot/StyleGuide to discourage using enums in hotspot (see JDK-8153116 for more details) I?m going to withdraw this proposed fix and try doing it by replacing enums with constant literals instead of using casts on enums. >>>> >>>> I therefore withdraw this fix for now. >>>> >>>> >>>> cheers >>>> >>>>> On Mar 29, 2016, at 4:30 PM, Gerard Ziemski wrote: >>>>> >>>>> hi all, >>>>> >>>>> Please review this small fix that enables Xcde 7.3 support for building hotspot, which involved 2 things: >>>>> >>>>> - modify gcc.make to add support for 7.3 version of clang compiler >>>>> - modify src/cpu/x86/vm/stubGenerator_x86_64.cpp, src/share/vm/oops/klass.hpp and src/share/vm/opto/library_call.cpp to cast 4 instances of signed int to unsigned when using shift operator to avoid "-Wshift-negative-value" warning. >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8152856 >>>>> http://cr.openjdk.java.net/~gziemski/8152856_rev1 >>>>> >>>>> Passes JPRT hotspot on all platforms >>>>> >>>> >>> >> From paul.sandoz at oracle.com Wed May 4 16:47:56 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 4 May 2016 09:47:56 -0700 Subject: RFR 8155258: VarHandle implementation improvements In-Reply-To: <572A2124.9030600@oracle.com> References: <43CCC631-B8BA-40BF-A292-7F1ED00FDCDD@oracle.com> <572A2124.9030600@oracle.com> Message-ID: <6EBE2FD8-C909-44A7-9ECE-5E0737BD023C@oracle.com> > On 4 May 2016, at 09:19, Vladimir Ivanov wrote: > > Looks good. > > I'm fine with pushing it directly into jdk9/dev, since the change just relaxes the assert and the risk of a merge conflict is very small. > Thanks! > Best regards, > Vladimir Ivanov > > PS: I wonder whether the MH cache in VarHandle (VarHandle.typesAndInvokers.methodHandle_table) should be idempotent or not. > I am guessing you mean in terms of the MH ref identity? > In the past, we had to make some caches in j.l.i idempotent (specifically, Invokers.invokers and MethodTypeForm.methodHandles). > > The problem was that the JVM can cache a method the MH points to (e.g., inline caches in generated code for MH invokers). If it happens, the JVM doesn't expect to observe 2 different instances of the MH, otherwise an assertion is fired. > > I can't say for sure it's not the case for VarHandles as well. > Ok, i will take a closer look at the existing caches (i did look at those for inspiration) and follow up. I might need to synchronise the update. FWIW there are also cases in MethodHandleImpl where MHs are cached without synchronization, perhaps such constraints don?t matter in these cases? Paul. From vladimir.x.ivanov at oracle.com Wed May 4 17:23:00 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 4 May 2016 20:23:00 +0300 Subject: RFR 8155258: VarHandle implementation improvements In-Reply-To: <6EBE2FD8-C909-44A7-9ECE-5E0737BD023C@oracle.com> References: <43CCC631-B8BA-40BF-A292-7F1ED00FDCDD@oracle.com> <572A2124.9030600@oracle.com> <6EBE2FD8-C909-44A7-9ECE-5E0737BD023C@oracle.com> Message-ID: <572A2FF4.60802@oracle.com> >> >> PS: I wonder whether the MH cache in VarHandle (VarHandle.typesAndInvokers.methodHandle_table) should be idempotent or not. >> > > I am guessing you mean in terms of the MH ref identity? Yes, but I think it matters only if bytecode spinning happens (it does for LambdaForms). What matters for the JVM is the method MH points to (through MH.form.vmentry.vmtarget). So, if a method handle always points to the same method, a race when publishing the handle should be benign. Best regards, Vladimir Ivanov > > >> In the past, we had to make some caches in j.l.i idempotent (specifically, Invokers.invokers and MethodTypeForm.methodHandles). >> >> The problem was that the JVM can cache a method the MH points to (e.g., inline caches in generated code for MH invokers). If it happens, the JVM doesn't expect to observe 2 different instances of the MH, otherwise an assertion is fired. >> >> I can't say for sure it's not the case for VarHandles as well. >> > > Ok, i will take a closer look at the existing caches (i did look at those for inspiration) and follow up. I might need to synchronise the update. > > FWIW there are also cases in MethodHandleImpl where MHs are cached without synchronization, perhaps such constraints don?t matter in these cases? > > Paul. > From kim.barrett at oracle.com Wed May 4 18:30:53 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 4 May 2016 14:30:53 -0400 Subject: RFR: 8146948: Add help information to log tags In-Reply-To: <570F9F97.4060808@oracle.com> References: <570F9F97.4060808@oracle.com> Message-ID: > On Apr 14, 2016, at 9:48 AM, Marcus Larsson wrote: > > Hi, > > Please review the following patch to add descriptions to logging tagsets. > > Summary: > Tagsets may now be given a description in logTagSetDescriptions.inline.hpp. All described tagsets are listed in the -Xlog:help output as well as in the LogConfiguration::describe output. The patch also adds trace level logging that lists *all* tagsets in the VM (-Xlog:logging=trace). The previous 'logging=trace logging' has been moved to 'logging=debug'. > > Example log output: > > ... > [0.544s][debug][logging] Described tag combinations: > [0.544s][debug][logging] logging: Logging for the log framework itself > ... > [0.544s][trace][logging] All available tag sets: arguments, biasedlocking, classinit, classload, classload+constraints, classload+preorder, classloaderdata, classpath, classresolve, classunload, constraints, defaultmethods, ergo, exceptions, gc, gc+age, gc+alloc, gc+alloc+region, gc+barrier, gc+bot, gc+classhisto, gc+classhisto+start, gc+compaction, gc+cpu, gc+ergo, gc+ergo+cset, gc+ergo+heap, gc+ergo+ihop, gc+ergo+refine, gc+freelist, gc+freelist+census, gc+freelist+stats, gc+heap, gc+heap+coops, gc+heap+exit, gc+heap+region, gc+humongous, gc+ihop, gc+jni, gc+liveness, gc+marking, gc+marking+start, gc+metaspace, gc+metaspace+alloc, gc+metaspace+freelist, gc+phases, gc+phases+start, gc+phases+task, gc+phases+verify, gc+phases+verify+start, gc+plab, gc+promotion, gc+ref, gc+ref+start, gc+refine, gc+region, gc+remset, gc+remset+exit, gc+remset+scrub, gc+scavenge, gc+start, gc+state, gc+stats, gc+stringdedup, gc+stringtable, gc+survivor, gc+sweep, gc+task, gc+task+stats, gc+task+thread, gc+task+time, gc+tlab, gc+verify, gc+verify+start, gc+workgang, heap+ergo, itables, jfr, jfr+instrumentation, jfr+types, logging, logging+test, modules, monitorinflation, monitormismatch, os, os+cpu, os+thread, pagesize, protectiondomain, ref, safepoint, safepointcleanup, stacktrace, startuptime, verification, vmoperation, vtables > > > Webrev: > http://cr.openjdk.java.net/~mlarsson/8146948/webrev.00/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8146948 > > Testing: > Internal VM tests through RBT > > Thanks, > Marcus ------------------------------------------------------------------------------ src/share/vm/logging/logTagSetDescriptions.inline.hpp 39 static struct LogTagSetDescription { 40 const LogTagSet* tagset; 41 const char* descr; 42 } tagset_descriptions[] = { 43 LOG_TAG_SET_DESCRIPTION_LIST 44 { NULL, NULL } 45 }; Won't this place a copy of the descriptions in each translation unit that includes this file, each in it's own file-scoped tagset_descriptions variable? I think better would be a class definition with a static const array member in the header, with the member definition (including the associated macrology) in a .cpp file. ------------------------------------------------------------------------------ From igor.ignatyev at oracle.com Wed May 4 19:29:17 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 4 May 2016 22:29:17 +0300 Subject: RFR: 8149591 - Prepare hotspot for GTest In-Reply-To: <57291B7E.5020906@oracle.com> References: <56BB93D6.3000905@oracle.com> <56BC0BF1.7070506@oracle.com> <2E67D611-36FF-4485-9468-7E7A1FC7819F@oracle.com> <1EE4DEDD-17F4-4893-B1FE-3C2C0A7E6F17@oracle.com> <572902AD.8020407@oracle.com> <57291B7E.5020906@oracle.com> Message-ID: <8D623C2F-AE66-4713-8C48-1C5E4FE7E59E@oracle.com> http://cr.openjdk.java.net/~iignatyev/8149591/webrev.02 Kim, thank you for review, I've added a comment. Working on the fix, I also noticed that there are platforms which use gcc < 4.8, and reports warnings ?cuz of 'report_assert_msg(??)?, so I guarded report_assert_msg w/ ATTRIBUTE_PRINTF with corresponding version check and added a declaration w/o ATTRIBUTE_PRINTF. Stefan, thanks for answering while I was out. Thanks, ? Igor > On May 4, 2016, at 12:43 AM, Stefan Karlsson wrote: > > On 2016-05-03 23:24, Kim Barrett wrote: >>> On May 3, 2016, at 3:57 PM, Stefan Karlsson wrote: >>> >>> Hi Kim, >>> >>> On 2016-05-03 21:20, Kim Barrett wrote: >>>>> On Apr 29, 2016, at 9:47 PM, Igor Ignatyev wrote: >>>>> >>>>> Hi, >>>>> >>>>> I?d like to renew this RFR. >>>>> >>>>> besides updated previous changes, new webrev contains two new things: >>>>> - new vm-flag ? ExecutingUnitTests, we use it in debug jvm to print a clean error message (w/o assert, line, file, etc). it is needed to simplify comparing error message in ?death? tests (the tests which intentionally cause crashes/asserts) >>>>> - if CreateCoredumpOnCrash is false, we don't determine default core path >>>>> >>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8149591/webrev.00/ >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8149591 >>>>> >>>>> Thanks, >>>>> ? Igor >>>> Not a full review yet, but a question before I go on. >>>> >>>> I don?t understand the purpose of FormatBufferDummy. I?m guessing it is to disambiguate the new >>>> FormatBuffer constructor taking a va_list argument. >>> Yes, that was the purpose. >>> >>>> But with these two overloads: >>>> >>>> FormatBuffer(const char* format, ?); >>>> FormatBuffer(const char* format, va_list ap); >>>> >>>> the latter should always be a better match when the second argument is a va_list, and should never >>>> be a match at all otherwise. (An overload containing ellipsis is always the least good match.) So I >>>> think we shouldn?t need FormatBufferDummy. >>>> >>> I started with that implementation but got the following error: >>> >>> src/share/vm/gc/shared/genCollectedHeap.cpp: In member function 'void GenCollectedHeap::do_collection(bool, bool, size_t, bool, GenCollectedHeap::GenerationType)': >>> src/share/vm/gc/shared/genCollectedHeap.cpp:435:44: error: deprecated conversion from string constant to 'va_list {aka char*}' [-Werror=write-strings] >>> FormatBuffer<> gc_string("%s", "Pause "); >>> >>> So, adding FormatBufferDummy was a quick-n-dirty solution to fix this. >> va_list on this platform seems to be just a typedef for char*. >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33588 >> which is ?won?t fix?. I hadn?t realized that overloading on va_list isn?t really useful; >> I guess that?s why there are lots of ?v?-prefixed/suffixed operations around. I can?t >> think of a better solution. A comment would be nice. > > Yes. > > StefanK From christian.tornqvist at oracle.com Wed May 4 20:01:11 2016 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Wed, 4 May 2016 16:01:11 -0400 Subject: RFR: 8156066 - Backout JDK-8153892 Message-ID: <39e901d1a63f$b52709c0$1f751d40$@oracle.com> Hi everyone, Please review this change that backs out JDK-8153892 since it crashed on ARMv7. hg backout was clean, also diffed the files to be sure. Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8156066/webrev.00/ Bug (parent bug is confidential, so unfortunately not visible): https://bugs.openjdk.java.net/browse/JDK-8156066 Thanks, Christian From mikael.vidstedt at oracle.com Wed May 4 20:24:05 2016 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 4 May 2016 13:24:05 -0700 Subject: RFR: 8156066 - Backout JDK-8153892 In-Reply-To: <39e901d1a63f$b52709c0$1f751d40$@oracle.com> References: <39e901d1a63f$b52709c0$1f751d40$@oracle.com> Message-ID: Looks good. Cheers, Mikael On 5/4/2016 1:01 PM, Christian Tornqvist wrote: > Hi everyone, > > > > Please review this change that backs out JDK-8153892 since it crashed on > ARMv7. hg backout was clean, also diffed the files to be sure. > > > > Webrev: > > http://cr.openjdk.java.net/~ctornqvi/webrev/8156066/webrev.00/ > > > > Bug (parent bug is confidential, so unfortunately not visible): > > https://bugs.openjdk.java.net/browse/JDK-8156066 > > > > Thanks, > > Christian > From coleen.phillimore at oracle.com Wed May 4 21:06:34 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 4 May 2016 17:06:34 -0400 Subject: RFR: 8156066 - Backout JDK-8153892 In-Reply-To: References: <39e901d1a63f$b52709c0$1f751d40$@oracle.com> Message-ID: Looks good. Coleen On 5/4/16 4:24 PM, Mikael Vidstedt wrote: > > Looks good. > > Cheers, > Mikael > > On 5/4/2016 1:01 PM, Christian Tornqvist wrote: >> Hi everyone, >> >> >> Please review this change that backs out JDK-8153892 since it crashed on >> ARMv7. hg backout was clean, also diffed the files to be sure. >> >> >> Webrev: >> >> http://cr.openjdk.java.net/~ctornqvi/webrev/8156066/webrev.00/ >> >> >> Bug (parent bug is confidential, so unfortunately not visible): >> >> https://bugs.openjdk.java.net/browse/JDK-8156066 >> >> >> Thanks, >> >> Christian >> > From david.holmes at oracle.com Wed May 4 21:42:21 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 5 May 2016 07:42:21 +1000 Subject: RFR(S): 8155950: Add minimal VM in JIB profile on linux-x86 In-Reply-To: <572A02EC.3010806@oracle.com> References: <57299A1B.80709@oracle.com> <14aebb53-1580-4e71-f218-7793e80785aa@oracle.com> <5729BA4C.6040802@oracle.com> <572A02EC.3010806@oracle.com> Message-ID: <8facc745-94da-5e41-a5d8-e4504c24253e@oracle.com> On 5/05/2016 12:10 AM, Leonid Mesnik wrote: > The hotspot changes are fixed separately and the final fix is only > changes in the root. It remains the same. > http://cr.openjdk.java.net/~lmesnik/8155950/webrev.00/root/ > Ok. Thanks, David > Leonid > > On 04.05.2016 13:23, David Holmes wrote: >> On 4/05/2016 7:01 PM, Leonid Mesnik wrote: >>> David >>> >>> On 04.05.2016 11:40, David Holmes wrote: >>>> On 4/05/2016 4:43 PM, Leonid Mesnik wrote: >>>>> Please review this small change which adds minimal VM as a part of >>>>> default JIB profile on linux-x86. The fix also include quick >>>>> workaround >>>>> for bug JDK-8155946 >>>>> . >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8155950 >>>>> Webrev (top): >>>>> http://cr.openjdk.java.net/~lmesnik/8155950/webrev.00/root/ >>>>> >>>> >>>> I thought we should only be building minimal and server now? >>> The client removal is covered by separate issue: >>> 8154209: Remove client VM from default JIB profile on windows-x86 and >>> linux-x86 >>> >>> The fix is ready (thanks to Mikael) however install bug JDK-8154410 >>> jdk9 windows-i586 build fails on setting "--with-jvm-variants=server" >>> >>> is a blocker. So the plan is to push it later after JDK-8154410 is fixed >>> or RE confirm that it is not a blocker anymore. >> >> Okay I suppose - seems like an awful lot of overhead to touch this >> code multiple times. >> >>>> >>>>> Webrev(hotspot): >>>>> http://cr.openjdk.java.net/~lmesnik/8155950/webrev.00/hotspot/ >>>>> >>>> >>>> This needs a separate CR. I don't know how this breakage slipped in >>>> but it is a distinct issue. >>> Ok, I will get a fix of JDK-8155946 first then and push only build >>> changes in this fix. >> >> OK. They can both be pushed together - just two separate changesets. >> >> Thanks, >> David >> >>> Leonid >>>> >>>> Thanks, >>>> David >>>> >>>>> Testing: JPRT (with updated testing of minimal VM flags) >>>>> >>>>> Leonid >>> > From brent.christian at oracle.com Wed May 4 23:47:01 2016 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 04 May 2016 16:47:01 -0700 Subject: RFR 8147039 : Incorrect locals and operands in compiled frames In-Reply-To: <5729B3C3.3040202@oracle.com> References: <5728F54B.8070007@oracle.com> <5729B3C3.3040202@oracle.com> Message-ID: <572A89F5.3010009@oracle.com> Thanks, Vladimir. BTW, automated build+test has revealed that my test's simple array of expected values doesn't cut it in the face of other [endian|bit]ness-es. For now, I need to skip checking of a couple of locals until something more robust can be added. Thanks, -Brent jdk/test/java/lang/StackWalker/LocalsAndOperands.java *************** *** 292,295 **** "0", ! "1000000", ! "0", "1293080650", --- 292,295 ---- "0", ! null, // skip, fix in 8156073 ! null, // skip, fix in 8156073 "1293080650", On 05/04/2016 01:33 AM, Vladimir Ivanov wrote: > Looks good. > > Best regards, > Vladimir Ivanov > > On 5/3/16 10:00 PM, Brent Christian wrote: >> Hi, >> >> Please review this change which fixes buggy behavior (including SEGV) in >> the experimental LiveStackFrame feature of StackWalker. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8147039 >> Webrev: >> http://cr.openjdk.java.net/~bchristi/8147039/webrev.02/ >> >> As suggested in the bug report, stack walking is reimplemented using >> javaVFrame/vframe::java_sender. The native StackWalkerAnchor class is >> updated (and renamed) with a similar interface and function to >> vframeStream. I've also removed the now-unneeded >> vframeStreamCommon::java_frame() function, added by 8140450. >> >> Thanks, >> -Brent From mikael.vidstedt at oracle.com Thu May 5 04:20:41 2016 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 4 May 2016 21:20:41 -0700 Subject: RFR(XS): 8156088: Reintegrate 8153892: Handle unsafe access error directly in signal handler instead of going through a stub Message-ID: <49d7c62d-9732-a0f0-83be-74a66163f03a@oracle.com> Please review the below changes - the reintegration of 8153892. Bug: https://bugs.openjdk.java.net/browse/JDK-8156088 Webrev (hotspot): http://cr.openjdk.java.net/~mikael/webrevs/8156088/webrev.01/hotspot/webrev/ * Summary The original change was broken. It turned out to be an ARMv7 specific problem, but since at the time the exact problem wasn't known the whole change was backed out by JDK-8156066. This change is a clean backout of the backout change. Cheers, Mikael From Leonid.Mesnik at oracle.com Thu May 5 05:56:00 2016 From: Leonid.Mesnik at oracle.com (Leonid Mesnik) Date: Thu, 5 May 2016 08:56:00 +0300 Subject: RFR(S): 8155950: Add minimal VM in JIB profile on linux-x86 In-Reply-To: <8facc745-94da-5e41-a5d8-e4504c24253e@oracle.com> References: <57299A1B.80709@oracle.com> <14aebb53-1580-4e71-f218-7793e80785aa@oracle.com> <5729BA4C.6040802@oracle.com> <572A02EC.3010806@oracle.com> <8facc745-94da-5e41-a5d8-e4504c24253e@oracle.com> Message-ID: <572AE070.6010406@oracle.com> Thank you for review. Leonid On 05.05.2016 00:42, David Holmes wrote: > On 5/05/2016 12:10 AM, Leonid Mesnik wrote: >> The hotspot changes are fixed separately and the final fix is only >> changes in the root. It remains the same. >> http://cr.openjdk.java.net/~lmesnik/8155950/webrev.00/root/ >> > > Ok. > > Thanks, > David > >> Leonid >> >> On 04.05.2016 13:23, David Holmes wrote: >>> On 4/05/2016 7:01 PM, Leonid Mesnik wrote: >>>> David >>>> >>>> On 04.05.2016 11:40, David Holmes wrote: >>>>> On 4/05/2016 4:43 PM, Leonid Mesnik wrote: >>>>>> Please review this small change which adds minimal VM as a part of >>>>>> default JIB profile on linux-x86. The fix also include quick >>>>>> workaround >>>>>> for bug JDK-8155946 >>>>>> . >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8155950 >>>>>> Webrev (top): >>>>>> http://cr.openjdk.java.net/~lmesnik/8155950/webrev.00/root/ >>>>>> >>>>> >>>>> I thought we should only be building minimal and server now? >>>> The client removal is covered by separate issue: >>>> 8154209: Remove client VM from default JIB profile on windows-x86 and >>>> linux-x86 >>>> >>>> The fix is ready (thanks to Mikael) however install bug JDK-8154410 >>>> jdk9 windows-i586 build fails on setting "--with-jvm-variants=server" >>>> >>>> is a blocker. So the plan is to push it later after JDK-8154410 is >>>> fixed >>>> or RE confirm that it is not a blocker anymore. >>> >>> Okay I suppose - seems like an awful lot of overhead to touch this >>> code multiple times. >>> >>>>> >>>>>> Webrev(hotspot): >>>>>> http://cr.openjdk.java.net/~lmesnik/8155950/webrev.00/hotspot/ >>>>>> >>>>> >>>>> This needs a separate CR. I don't know how this breakage slipped in >>>>> but it is a distinct issue. >>>> Ok, I will get a fix of JDK-8155946 first then and push only build >>>> changes in this fix. >>> >>> OK. They can both be pushed together - just two separate changesets. >>> >>> Thanks, >>> David >>> >>>> Leonid >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Testing: JPRT (with updated testing of minimal VM flags) >>>>>> >>>>>> Leonid >>>> >> From david.holmes at oracle.com Thu May 5 07:48:44 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 5 May 2016 17:48:44 +1000 Subject: RFR(XS): 8156088: Reintegrate 8153892: Handle unsafe access error directly in signal handler instead of going through a stub In-Reply-To: <49d7c62d-9732-a0f0-83be-74a66163f03a@oracle.com> References: <49d7c62d-9732-a0f0-83be-74a66163f03a@oracle.com> Message-ID: On 5/05/2016 2:20 PM, Mikael Vidstedt wrote: > > Please review the below changes - the reintegration of 8153892. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8156088 > Webrev (hotspot): > http://cr.openjdk.java.net/~mikael/webrevs/8156088/webrev.01/hotspot/webrev/ > > > * Summary > > The original change was broken. It turned out to be an ARMv7 specific > problem, but since at the time the exact problem wasn't known the whole > change was backed out by JDK-8156066. This change is a clean backout of > the backout change. So that makes it a backin? ;-) Looks good. Thanks, David > Cheers, > Mikael > From igor.ignatyev at oracle.com Thu May 5 14:58:55 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 5 May 2016 17:58:55 +0300 Subject: RFR(M) : 8148244 : Finalize and integrate GTest implementation In-Reply-To: References: <4E849CF5-6955-4240-BF4F-A104B188AADA@oracle.com> <57274243.9050809@oracle.com> Message-ID: Hi, I?ve rebased the changes to the latest jdk9/hs and removed the comment from JvmMapfile.gmk. Also I?ve guarded building gtest w/ if TEST_IN_BUILD != false (http://cr.openjdk.java.net/~iignatyev/8148244-hotspot/webrev.02/make/lib/CompileGtest.gmk.html), so we won?t build it when we compile build jdk in case of cross-compliation. new webrevs: http://cr.openjdk.java.net/~iignatyev/8148244-root/webrev.02 http://cr.openjdk.java.net/~iignatyev/8148244-hotspot/webrev.02/ Thanks, ? Igor > On May 2, 2016, at 3:55 PM, Jesper Wilhelmsson wrote: > > Even though the comment on line 155 in JvmMapfile.gmk is accurate I agree with removing it. > > Besides that the change looks good! > /Jesper > > > Den 2/5/16 kl. 14:04, skrev Erik Joelsson: >> Hello, >> >> Build changes look good to me, but I also wrote most of them, except for >> makefiles/lib/JvmMapfile.gmk line 155. I could not have written that. Please >> remove. >> >> The webrevs seem to be generated against jdk9/hs without the removal of the old >> build system. I would recommend making that merge and generate new webrevs since >> makefiles moved around quite a bit. >> >> /Erik >> >> On 2016-05-02 13:21, Igor Ignatyev wrote: >>> http://cr.openjdk.java.net/~iignatyev/8148244-hotspot/webrev.00 >>>> 615 lines changed: 605 ins; 2 del; 8 mod; >>> http://cr.openjdk.java.net/~iignatyev/8148244-root-wo-gtest/webrev.00/ >>>> 218 lines changed: 209 ins; 0 del; 9 mod; >>> >>> http://cr.openjdk.java.net/~iignatyev/8148244-root/webrev.00/ >>>> 32029 lines changed: 32018 ins; 0 del; 11 mod; >>> Hi all, >>> >>> could you please review this patch which delivers core of JEP 281: HotSpot C++ >>> Unit-Test Framework[1]? >>> in more details, this patch >>> - integrates sources of gtest-1.7.0[2] to /test/fmw/gtest (~32k LOC) >>> - introduces TEST macros (/hotspot/test/native/unittest.hpp) >>> - TEST ? a basic unit test, doesn?t require an inited JVM >>> - TEST_VM ? a test which requires an inited JVM, but expected to leave JVM >>> in a valid state >>> - TEST_OTHER_VM ? a test which requires a clean inited JVM >>> - TEST_VM_ASSERT/TEST_VM_ASSERT_MSG - tests to verify assert, ?death?[3] >>> tests which require inited JVM >>> - contains two tests as smoke tests for the project and examples. new tests >>> should be added to /hotspot/test/native/ using the same directories layout as >>> a corresponding product source files, and have prefix ?test_?, e.g. >>> test/native/runtime/test_os.cpp w/ tests for runtime/test_os.cpp >>> - updates makefiles to build/run tests : to run tests, one should use 'make >>> test TEST=hotspot_gtest? >>> - adds hotspot_gtest to jprt testset >>> >>> more information on the project can be found in JEP 281[1]. >>> >>> please be informed, that existing unit tests (aka internal tests) will be >>> ported into new framework later, this activity is tracking by JDK-8077965[4]. >>> >>> PS This patch relies on JDK-8149591[5] which is under review[6]. >>> >>> Thanks, >>> ? Igor >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8148244 >>> webrevs: >>> root : http://cr.openjdk.java.net/~iignatyev/8148244-root/webrev.00/ >>> w/o gtest : >>> http://cr.openjdk.java.net/~iignatyev/8148244-root-wo-gtest/webrev.00/ >>> hotspot : http://cr.openjdk.java.net/~iignatyev/8148244-hotspot/webrev.00 >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8047975 >>> [2] https://github.com/google/googletest/releases/tag/release-1.7.0 >>> [3] >>> https://github.com/google/googletest/blob/master/googletest/docs/V1_7_AdvancedGuide.md#death-tests >>> >>> [4] https://bugs.openjdk.java.net/browse/JDK-8077965 >>> [5] https://bugs.openjdk.java.net/browse/JDK-8149591 >>> [6] http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-April/022937.html >> From christian.tornqvist at oracle.com Thu May 5 16:20:34 2016 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Thu, 5 May 2016 12:20:34 -0400 Subject: RFR(XS): 8154942 Remove ProcessTools.getVmInputArguments() from the hotspot test library, as it is not used by any of the hotspot tests In-Reply-To: References: <5720CF18.6000109@oracle.com> Message-ID: <3d4301d1a6ea$0d76e9b0$2864bd10$@oracle.com> Hi George, Yes, I agree that the cleanup should be done as a separate change. Change looks good. Thanks, Christian -----Original Message----- From: George Triantafillou [mailto:george.triantafillou at oracle.com] Sent: Tuesday, May 3, 2016 3:45 PM To: Christian Tornqvist ; hotspot-dev at openjdk.java.net Subject: Re: RFR(XS): 8154942 Remove ProcessTools.getVmInputArguments() from the hotspot test library, as it is not used by any of the hotspot tests Hi Christian, As we discussed offline, there is definitely room for cleanup, but that warrants a separate RFE due to the extent of the changes required. So, is this minor fix ready to commit? -George On 4/27/2016 11:44 AM, Christian Tornqvist wrote: > Hi George, > > Are there any unnecessary @module tags we can remove as a result of this? > > Thanks, > Christian > > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On > Behalf Of George Triantafillou > Sent: Wednesday, April 27, 2016 10:39 AM > To: hotspot-dev at openjdk.java.net > Subject: RFR(XS): 8154942 Remove ProcessTools.getVmInputArguments() > from the hotspot test library, as it is not used by any of the hotspot > tests > > Please review this very small change that removes the unused method > getVmInputArguments() from ProcessTools. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8154942 > Webrev: > http://cr.openjdk.java.net/~gtriantafill/bug-8154942/bug_8154942.patch > /webrev/ > tch/webrev/> > > Thanks, > George > From george.triantafillou at oracle.com Thu May 5 18:19:32 2016 From: george.triantafillou at oracle.com (George Triantafillou) Date: Thu, 5 May 2016 14:19:32 -0400 Subject: RFR(XS): 8154942 Remove ProcessTools.getVmInputArguments() from the hotspot test library, as it is not used by any of the hotspot tests In-Reply-To: <3d4301d1a6ea$0d76e9b0$2864bd10$@oracle.com> References: <5720CF18.6000109@oracle.com> <3d4301d1a6ea$0d76e9b0$2864bd10$@oracle.com> Message-ID: <96f762eb-89b3-1b96-bdce-67bbc553bbae@oracle.com> Thanks Christian. -George On 5/5/2016 12:20 PM, Christian Tornqvist wrote: > Hi George, > > Yes, I agree that the cleanup should be done as a separate change. Change looks good. > > Thanks, > Christian > > -----Original Message----- > From: George Triantafillou [mailto:george.triantafillou at oracle.com] > Sent: Tuesday, May 3, 2016 3:45 PM > To: Christian Tornqvist ; hotspot-dev at openjdk.java.net > Subject: Re: RFR(XS): 8154942 Remove ProcessTools.getVmInputArguments() from the hotspot test library, as it is not used by any of the hotspot tests > > Hi Christian, > > As we discussed offline, there is definitely room for cleanup, but that warrants a separate RFE due to the extent of the changes required. > > So, is this minor fix ready to commit? > > -George > > On 4/27/2016 11:44 AM, Christian Tornqvist wrote: >> Hi George, >> >> Are there any unnecessary @module tags we can remove as a result of this? >> >> Thanks, >> Christian >> >> -----Original Message----- >> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On >> Behalf Of George Triantafillou >> Sent: Wednesday, April 27, 2016 10:39 AM >> To: hotspot-dev at openjdk.java.net >> Subject: RFR(XS): 8154942 Remove ProcessTools.getVmInputArguments() >> from the hotspot test library, as it is not used by any of the hotspot >> tests >> >> Please review this very small change that removes the unused method >> getVmInputArguments() from ProcessTools. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8154942 >> Webrev: >> http://cr.openjdk.java.net/~gtriantafill/bug-8154942/bug_8154942.patch >> /webrev/ >> > tch/webrev/> >> >> Thanks, >> George >> > From david.holmes at oracle.com Thu May 5 21:01:03 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 6 May 2016 07:01:03 +1000 Subject: RFR: 8154715: Missing destructor and/or TLS clearing calls for terminating threads In-Reply-To: References: Message-ID: <2e53b9e4-c2c5-2ead-224d-e5c36b6de39f@oracle.com> PING! David On 4/05/2016 9:39 AM, David Holmes wrote: > This needs attention from GC and runtime folk please. > > bug: https://bugs.openjdk.java.net/browse/JDK-8154715 > webrev: http://cr.openjdk.java.net/~dholmes/8154715/webrev/ > > tl;dr: ensure ThreadLocalStorage::set_thread(NULL) is always called > before a thread terminates. > > Background: > > Most system-related threads do not expect to explicitly terminate, > except sometimes as part of VM termination. Such threads don't have > their destructors called, but should. > > This omission came to light due to the ThreadLocalStorage changes in > JDK-8132510. As part of that change we deleted the following from the > termination path of the VMThread: > > // Thread destructor usually does this. > ThreadLocalStorage::set_thread(NULL); > > The clearing of TLS seemed irrelevant to the VMThread as it primarily is > used to aid in JNI attach/detach. However Brian Gardner reported: > > http://mail.openjdk.java.net/pipermail/bsd-port-dev/2016-February/002788.html > > > a problem on FreeBSD caused by this change and the interaction with the > POSIX pthread TLS destructor use introduced by JDK-8033696. Because the > VMThread terminated without clearing TLS, when the TLS-destructor was > called it got into a loop which ran four times (as happens on Linux) and > then prints a warning to the console (which doesn't happen on Linux). > > This indicates we need to restore the: > > ThreadLocalStorage::set_thread(NULL); > > but on further consideration it seems to me that this is not confined to > the VMThread, and the most appropriate fix would be to always invoke the > Thread destructor as a thread terminates. > > Solution: > > Further investigation shows that calling the Thread destructor in the > thread as it terminates is not possible: > > - VMThread > > This is actually destroyed by the thread that terminates the VM, but > that can happen after it terminates and so we still hit the TLS problem. > The VMThread may be able to destroy itself today but in the past this > was not possible (see existing code comment), and in the future it may > also not be possible - the problem is that the Thread destructor can > interact with other VM subsystems that are concurrently being torn down > by the thread that is terminating the VM. In the past this was the > CodeHeap. So rather than introduce something that is fragile we stick > with the current scheme but restore the > ThreadLocalStorage::set_thread(NULL); - note we can't access "this" at > that time because it may already have been de-allocated. > > - WatcherThread > > The WatcherThread is never destroyed today but has the same problem as > the VMThread. We can call the destructor from the VM termination thread > (and have implemented that), but not from the WatcherThread itself. So > again we just have to restore the ThreadLocalStorage::set_thread(NULL); > to fix the potential TLS problem. > > - GC Threads > > There are two cases: > > a) GC threads that never terminate > > For these we don't need to do anything: we can't delete the thread as it > never terminates and we don't hit the TLS problem because it never > terminates. So all we will do here is add some logic to check (in > NON_PRODUCT) that we do in fact never terminate. > > b) GC threads that can terminate > > Despite the fact the threads can terminate, references to those threads > are stored elsewhere (WorkGangs and other places) and are not cleared as > part of the termination process. Those references can be touched after > the thread has terminated so we can not call the destructor at all. So > again all we can do (without some major thread management reworking) is > ensure that ThreadLocalStorage::set_thread(NULL); is called before the > thread actually terminates > > Testing: JPRT > RBT - runtime nightly tests > > Thanks, > David From daniel.daugherty at oracle.com Thu May 5 22:03:57 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 5 May 2016 16:03:57 -0600 Subject: RFR: 8154715: Missing destructor and/or TLS clearing calls for terminating threads In-Reply-To: References: Message-ID: On 5/3/16 5:39 PM, David Holmes wrote: > This needs attention from GC and runtime folk please. > > bug: https://bugs.openjdk.java.net/browse/JDK-8154715 > webrev: http://cr.openjdk.java.net/~dholmes/8154715/webrev/ src/os/solaris/vm/os_solaris.cpp No comments. (I'm guessing you didn't want to expand the existing guarantee() to cover your additional discovery.) src/share/vm/gc/parallel/gcTaskThread.cpp No comments. src/share/vm/gc/shared/concurrentGCThread.cpp No comments. src/share/vm/gc/shared/workgroup.cpp No comments. src/share/vm/runtime/thread.cpp L1388: if (watcher != NULL) L1389: delete watcher; nit: Please add '{' and '}' or make it a single line if-statement. src/share/vm/runtime/vmThread.cpp No comments. Thumbs up. Only one nit so feel free to ignore it or fix it; I don't need another webrev if you fix it. Dan > > tl;dr: ensure ThreadLocalStorage::set_thread(NULL) is always called > before a thread terminates. > > Background: > > Most system-related threads do not expect to explicitly terminate, > except sometimes as part of VM termination. Such threads don't have > their destructors called, but should. > > This omission came to light due to the ThreadLocalStorage changes in > JDK-8132510. As part of that change we deleted the following from the > termination path of the VMThread: > > // Thread destructor usually does this. > ThreadLocalStorage::set_thread(NULL); > > The clearing of TLS seemed irrelevant to the VMThread as it primarily > is used to aid in JNI attach/detach. However Brian Gardner reported: > > http://mail.openjdk.java.net/pipermail/bsd-port-dev/2016-February/002788.html > > > a problem on FreeBSD caused by this change and the interaction with > the POSIX pthread TLS destructor use introduced by JDK-8033696. > Because the VMThread terminated without clearing TLS, when the > TLS-destructor was called it got into a loop which ran four times (as > happens on Linux) and then prints a warning to the console (which > doesn't happen on Linux). > > This indicates we need to restore the: > > ThreadLocalStorage::set_thread(NULL); > > but on further consideration it seems to me that this is not confined > to the VMThread, and the most appropriate fix would be to always > invoke the Thread destructor as a thread terminates. > > Solution: > > Further investigation shows that calling the Thread destructor in the > thread as it terminates is not possible: > > - VMThread > > This is actually destroyed by the thread that terminates the VM, but > that can happen after it terminates and so we still hit the TLS > problem. The VMThread may be able to destroy itself today but in the > past this was not possible (see existing code comment), and in the > future it may also not be possible - the problem is that the Thread > destructor can interact with other VM subsystems that are concurrently > being torn down by the thread that is terminating the VM. In the past > this was the CodeHeap. So rather than introduce something that is > fragile we stick with the current scheme but restore the > ThreadLocalStorage::set_thread(NULL); - note we can't access "this" at > that time because it may already have been de-allocated. > > - WatcherThread > > The WatcherThread is never destroyed today but has the same problem as > the VMThread. We can call the destructor from the VM termination > thread (and have implemented that), but not from the WatcherThread > itself. So again we just have to restore the > ThreadLocalStorage::set_thread(NULL); to fix the potential TLS problem. > > - GC Threads > > There are two cases: > > a) GC threads that never terminate > > For these we don't need to do anything: we can't delete the thread as > it never terminates and we don't hit the TLS problem because it never > terminates. So all we will do here is add some logic to check (in > NON_PRODUCT) that we do in fact never terminate. > > b) GC threads that can terminate > > Despite the fact the threads can terminate, references to those > threads are stored elsewhere (WorkGangs and other places) and are not > cleared as part of the termination process. Those references can be > touched after the thread has terminated so we can not call the > destructor at all. So again all we can do (without some major thread > management reworking) is ensure that > ThreadLocalStorage::set_thread(NULL); is called before the thread > actually terminates > > Testing: JPRT > RBT - runtime nightly tests > > Thanks, > David From david.holmes at oracle.com Thu May 5 23:42:51 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 6 May 2016 09:42:51 +1000 Subject: RFR: 8154715: Missing destructor and/or TLS clearing calls for terminating threads In-Reply-To: References: Message-ID: <407c0bf1-f4d3-adc8-9e86-a69d80a80b5a@oracle.com> Hi Dan, Thanks for the Review! On 6/05/2016 8:03 AM, Daniel D. Daugherty wrote: > On 5/3/16 5:39 PM, David Holmes wrote: >> This needs attention from GC and runtime folk please. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8154715 >> webrev: http://cr.openjdk.java.net/~dholmes/8154715/webrev/ > > src/os/solaris/vm/os_solaris.cpp > No comments. (I'm guessing you didn't want to expand the existing > guarantee() to cover your additional discovery.) There's no way to ask "did you use to be the WatcherThread?" because by this point watcherThread() has to return NULL. So simpler to just delete - plus this was the only OS that did this check. > src/share/vm/gc/parallel/gcTaskThread.cpp > No comments. > > src/share/vm/gc/shared/concurrentGCThread.cpp > No comments. > > src/share/vm/gc/shared/workgroup.cpp > No comments. > > src/share/vm/runtime/thread.cpp > L1388: if (watcher != NULL) > L1389: delete watcher; > nit: Please add '{' and '}' or make it a single line if-statement. Will add braces. > src/share/vm/runtime/vmThread.cpp > No comments. > > > Thumbs up. Only one nit so feel free to ignore it or fix it; I don't > need another webrev if you fix it. Thanks, David > Dan > > >> >> tl;dr: ensure ThreadLocalStorage::set_thread(NULL) is always called >> before a thread terminates. >> >> Background: >> >> Most system-related threads do not expect to explicitly terminate, >> except sometimes as part of VM termination. Such threads don't have >> their destructors called, but should. >> >> This omission came to light due to the ThreadLocalStorage changes in >> JDK-8132510. As part of that change we deleted the following from the >> termination path of the VMThread: >> >> // Thread destructor usually does this. >> ThreadLocalStorage::set_thread(NULL); >> >> The clearing of TLS seemed irrelevant to the VMThread as it primarily >> is used to aid in JNI attach/detach. However Brian Gardner reported: >> >> http://mail.openjdk.java.net/pipermail/bsd-port-dev/2016-February/002788.html >> >> >> a problem on FreeBSD caused by this change and the interaction with >> the POSIX pthread TLS destructor use introduced by JDK-8033696. >> Because the VMThread terminated without clearing TLS, when the >> TLS-destructor was called it got into a loop which ran four times (as >> happens on Linux) and then prints a warning to the console (which >> doesn't happen on Linux). >> >> This indicates we need to restore the: >> >> ThreadLocalStorage::set_thread(NULL); >> >> but on further consideration it seems to me that this is not confined >> to the VMThread, and the most appropriate fix would be to always >> invoke the Thread destructor as a thread terminates. >> >> Solution: >> >> Further investigation shows that calling the Thread destructor in the >> thread as it terminates is not possible: >> >> - VMThread >> >> This is actually destroyed by the thread that terminates the VM, but >> that can happen after it terminates and so we still hit the TLS >> problem. The VMThread may be able to destroy itself today but in the >> past this was not possible (see existing code comment), and in the >> future it may also not be possible - the problem is that the Thread >> destructor can interact with other VM subsystems that are concurrently >> being torn down by the thread that is terminating the VM. In the past >> this was the CodeHeap. So rather than introduce something that is >> fragile we stick with the current scheme but restore the >> ThreadLocalStorage::set_thread(NULL); - note we can't access "this" at >> that time because it may already have been de-allocated. >> >> - WatcherThread >> >> The WatcherThread is never destroyed today but has the same problem as >> the VMThread. We can call the destructor from the VM termination >> thread (and have implemented that), but not from the WatcherThread >> itself. So again we just have to restore the >> ThreadLocalStorage::set_thread(NULL); to fix the potential TLS problem. >> >> - GC Threads >> >> There are two cases: >> >> a) GC threads that never terminate >> >> For these we don't need to do anything: we can't delete the thread as >> it never terminates and we don't hit the TLS problem because it never >> terminates. So all we will do here is add some logic to check (in >> NON_PRODUCT) that we do in fact never terminate. >> >> b) GC threads that can terminate >> >> Despite the fact the threads can terminate, references to those >> threads are stored elsewhere (WorkGangs and other places) and are not >> cleared as part of the termination process. Those references can be >> touched after the thread has terminated so we can not call the >> destructor at all. So again all we can do (without some major thread >> management reworking) is ensure that >> ThreadLocalStorage::set_thread(NULL); is called before the thread >> actually terminates >> >> Testing: JPRT >> RBT - runtime nightly tests >> >> Thanks, >> David > From stefan.karlsson at oracle.com Fri May 6 07:02:48 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 6 May 2016 09:02:48 +0200 Subject: RFR: 8154715: Missing destructor and/or TLS clearing calls for terminating threads In-Reply-To: References: Message-ID: <572C4198.3090900@oracle.com> Hi David, I looked through the GC part of this webrev and I think the change is fine. However, it seems a bit error prone. If we decide to change the code to, for example, terminate the AbstractGangWorker threads, then we have to remember to insert a ThreadLocalStorage::set_thread(NULL) call. Could we instead add a call to ThreadLocalStorage::set_thread(NULL), or maybe even Thread::clear_thread_current(), in java_start? static void *java_start(Thread *thread) { [...] thread->initialize_thread_current(); [...] // call one more level start routine thread->run(); ////////// Could we call Thread::clear_thread_current(); here? log_info(os, thread)("Thread finished (tid: " UINTX_FORMAT ", pthread id: " UINTX_FORMAT ").", os::current_thread_id(), (uintx) pthread_self()); return 0; } And get rid of the explicit calls to ThreadLocalStorage::set_thread(NULL) you added? Thanks, StefanK On 04/05/16 01:39, David Holmes wrote: > This needs attention from GC and runtime folk please. > > bug: https://bugs.openjdk.java.net/browse/JDK-8154715 > webrev: http://cr.openjdk.java.net/~dholmes/8154715/webrev/ > > tl;dr: ensure ThreadLocalStorage::set_thread(NULL) is always called > before a thread terminates. > > Background: > > Most system-related threads do not expect to explicitly terminate, > except sometimes as part of VM termination. Such threads don't have > their destructors called, but should. > > This omission came to light due to the ThreadLocalStorage changes in > JDK-8132510. As part of that change we deleted the following from the > termination path of the VMThread: > > // Thread destructor usually does this. > ThreadLocalStorage::set_thread(NULL); > > The clearing of TLS seemed irrelevant to the VMThread as it primarily > is used to aid in JNI attach/detach. However Brian Gardner reported: > > http://mail.openjdk.java.net/pipermail/bsd-port-dev/2016-February/002788.html > > > a problem on FreeBSD caused by this change and the interaction with > the POSIX pthread TLS destructor use introduced by JDK-8033696. > Because the VMThread terminated without clearing TLS, when the > TLS-destructor was called it got into a loop which ran four times (as > happens on Linux) and then prints a warning to the console (which > doesn't happen on Linux). > > This indicates we need to restore the: > > ThreadLocalStorage::set_thread(NULL); > > but on further consideration it seems to me that this is not confined > to the VMThread, and the most appropriate fix would be to always > invoke the Thread destructor as a thread terminates. > > Solution: > > Further investigation shows that calling the Thread destructor in the > thread as it terminates is not possible: > > - VMThread > > This is actually destroyed by the thread that terminates the VM, but > that can happen after it terminates and so we still hit the TLS > problem. The VMThread may be able to destroy itself today but in the > past this was not possible (see existing code comment), and in the > future it may also not be possible - the problem is that the Thread > destructor can interact with other VM subsystems that are concurrently > being torn down by the thread that is terminating the VM. In the past > this was the CodeHeap. So rather than introduce something that is > fragile we stick with the current scheme but restore the > ThreadLocalStorage::set_thread(NULL); - note we can't access "this" at > that time because it may already have been de-allocated. > > - WatcherThread > > The WatcherThread is never destroyed today but has the same problem as > the VMThread. We can call the destructor from the VM termination > thread (and have implemented that), but not from the WatcherThread > itself. So again we just have to restore the > ThreadLocalStorage::set_thread(NULL); to fix the potential TLS problem. > > - GC Threads > > There are two cases: > > a) GC threads that never terminate > > For these we don't need to do anything: we can't delete the thread as > it never terminates and we don't hit the TLS problem because it never > terminates. So all we will do here is add some logic to check (in > NON_PRODUCT) that we do in fact never terminate. > > b) GC threads that can terminate > > Despite the fact the threads can terminate, references to those > threads are stored elsewhere (WorkGangs and other places) and are not > cleared as part of the termination process. Those references can be > touched after the thread has terminated so we can not call the > destructor at all. So again all we can do (without some major thread > management reworking) is ensure that > ThreadLocalStorage::set_thread(NULL); is called before the thread > actually terminates > > Testing: JPRT > RBT - runtime nightly tests > > Thanks, > David From erik.joelsson at oracle.com Fri May 6 07:05:21 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 6 May 2016 09:05:21 +0200 Subject: RFR(M) : 8148244 : Finalize and integrate GTest implementation In-Reply-To: References: <4E849CF5-6955-4240-BF4F-A104B188AADA@oracle.com> <57274243.9050809@oracle.com> Message-ID: <572C4231.6030001@oracle.com> Good catch with disabling gtest in the case of the "build jdk". I would prefer if you introduced a new variable for it, something more obvious like BUILD_GTEST. Default it to true in spec.gmk.in and override that value to false in buildjdk-spec.gmk.in. (The TEST_IN_BUILD variable had a different purpose and is now dead, so please also remove it from buildjdk-spec.gmk.in). I would also prefer if you put the whole inclusion of CompileGtest.gmk in a conditional in CompileLibraries.gmk instead, so we avoid all of the evaluation of building it when disabled. Also, please don't forget to indent anything inside a conditional. Like this: ifeq ($(BUILD_GTEST), true) include lib/CompileGtest.gmk endif For completeness, there should probably also be a conditional of BUILD_GTEST like this in Main.gmk: ifeq ($(BUILD_GTEST), true) test-image-hotspot-gtest: +($(CD) $(HOTSPOT_TOPDIR)/make/test && $(MAKE) $(MAKE_ARGS) -f GtestImage.gmk) endif /Erik On 2016-05-05 16:58, Igor Ignatyev wrote: > Hi, > > I?ve rebased the changes to the latest jdk9/hs and removed the comment from JvmMapfile.gmk. Also I?ve guarded building gtest w/ if TEST_IN_BUILD != false (http://cr.openjdk.java.net/~iignatyev/8148244-hotspot/webrev.02/make/lib/CompileGtest.gmk.html), so we won?t build it when we compile build jdk in case of cross-compliation. > > new webrevs: > http://cr.openjdk.java.net/~iignatyev/8148244-root/webrev.02 > http://cr.openjdk.java.net/~iignatyev/8148244-hotspot/webrev.02/ > > Thanks, > ? Igor > > >> On May 2, 2016, at 3:55 PM, Jesper Wilhelmsson wrote: >> >> Even though the comment on line 155 in JvmMapfile.gmk is accurate I agree with removing it. >> >> Besides that the change looks good! >> /Jesper >> >> >> Den 2/5/16 kl. 14:04, skrev Erik Joelsson: >>> Hello, >>> >>> Build changes look good to me, but I also wrote most of them, except for >>> makefiles/lib/JvmMapfile.gmk line 155. I could not have written that. Please >>> remove. >>> >>> The webrevs seem to be generated against jdk9/hs without the removal of the old >>> build system. I would recommend making that merge and generate new webrevs since >>> makefiles moved around quite a bit. >>> >>> /Erik >>> >>> On 2016-05-02 13:21, Igor Ignatyev wrote: >>>> http://cr.openjdk.java.net/~iignatyev/8148244-hotspot/webrev.00 >>>>> 615 lines changed: 605 ins; 2 del; 8 mod; >>>> http://cr.openjdk.java.net/~iignatyev/8148244-root-wo-gtest/webrev.00/ >>>>> 218 lines changed: 209 ins; 0 del; 9 mod; >>>> http://cr.openjdk.java.net/~iignatyev/8148244-root/webrev.00/ >>>>> 32029 lines changed: 32018 ins; 0 del; 11 mod; >>>> Hi all, >>>> >>>> could you please review this patch which delivers core of JEP 281: HotSpot C++ >>>> Unit-Test Framework[1]? >>>> in more details, this patch >>>> - integrates sources of gtest-1.7.0[2] to /test/fmw/gtest (~32k LOC) >>>> - introduces TEST macros (/hotspot/test/native/unittest.hpp) >>>> - TEST ? a basic unit test, doesn?t require an inited JVM >>>> - TEST_VM ? a test which requires an inited JVM, but expected to leave JVM >>>> in a valid state >>>> - TEST_OTHER_VM ? a test which requires a clean inited JVM >>>> - TEST_VM_ASSERT/TEST_VM_ASSERT_MSG - tests to verify assert, ?death?[3] >>>> tests which require inited JVM >>>> - contains two tests as smoke tests for the project and examples. new tests >>>> should be added to /hotspot/test/native/ using the same directories layout as >>>> a corresponding product source files, and have prefix ?test_?, e.g. >>>> test/native/runtime/test_os.cpp w/ tests for runtime/test_os.cpp >>>> - updates makefiles to build/run tests : to run tests, one should use 'make >>>> test TEST=hotspot_gtest? >>>> - adds hotspot_gtest to jprt testset >>>> >>>> more information on the project can be found in JEP 281[1]. >>>> >>>> please be informed, that existing unit tests (aka internal tests) will be >>>> ported into new framework later, this activity is tracking by JDK-8077965[4]. >>>> >>>> PS This patch relies on JDK-8149591[5] which is under review[6]. >>>> >>>> Thanks, >>>> ? Igor >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8148244 >>>> webrevs: >>>> root : http://cr.openjdk.java.net/~iignatyev/8148244-root/webrev.00/ >>>> w/o gtest : >>>> http://cr.openjdk.java.net/~iignatyev/8148244-root-wo-gtest/webrev.00/ >>>> hotspot : http://cr.openjdk.java.net/~iignatyev/8148244-hotspot/webrev.00 >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8047975 >>>> [2] https://github.com/google/googletest/releases/tag/release-1.7.0 >>>> [3] >>>> https://github.com/google/googletest/blob/master/googletest/docs/V1_7_AdvancedGuide.md#death-tests >>>> >>>> [4] https://bugs.openjdk.java.net/browse/JDK-8077965 >>>> [5] https://bugs.openjdk.java.net/browse/JDK-8149591 >>>> [6] http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-April/022937.html From david.holmes at oracle.com Fri May 6 13:38:07 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 6 May 2016 23:38:07 +1000 Subject: RFR: 8154715: Missing destructor and/or TLS clearing calls for terminating threads In-Reply-To: <572C4198.3090900@oracle.com> References: <572C4198.3090900@oracle.com> Message-ID: Hi Stefan, Thanks for taking a look at this. On 6/05/2016 5:02 PM, Stefan Karlsson wrote: > Hi David, > > I looked through the GC part of this webrev and I think the change is fine. > > However, it seems a bit error prone. If we decide to change the code to, > for example, terminate the AbstractGangWorker threads, then we have to > remember to insert a ThreadLocalStorage::set_thread(NULL) call. That's why I added the ShouldNotReachHere()'s - if those threads start terminating then we will see those hit. Perhaps a comment: ShouldNotReachHere(); // If thread terminates we have to do TLS cleanup ? > Could we instead add a call to ThreadLocalStorage::set_thread(NULL), or > maybe even Thread::clear_thread_current(), in java_start? > > static void *java_start(Thread *thread) { > [...] > thread->initialize_thread_current(); > > [...] > > // call one more level start routine > thread->run(); > > ////////// Could we call Thread::clear_thread_current(); here? Not easily. For JavaThreads we've already done "delete this" inside the run() method, so we'd have to move that into java_start as well, but we can only do the delete for JavaThreads not for other threads. And we'd also have to change the VMThread and WatcherThread termination logic because of the deletes that happen in the termination thread - the "this" pointer (thread above) may no longer be valid when we want to call clear_current_thread() - which is why we can only do the ThreadLocalStorage::set_thread(NULL). I agree it would be a lot cleaner to have java_start do: thread->common_initialization(); thread->run(); thread->common_cleanup(); delete thread; for all threads, but we'd need a lot of other changes to allow for that. Otherwise we would need to note that kind of thread before calling run() then switch on the thread type after run() to decide what kind of cleanup is necessary and possible. I don't think that would be better than just doing the "right" cleanup at the end of the run() methods. Thanks, David ------ > > log_info(os, thread)("Thread finished (tid: " UINTX_FORMAT ", pthread > id: " UINTX_FORMAT ").", > os::current_thread_id(), (uintx) pthread_self()); > > return 0; > } > > And get rid of the explicit calls to > ThreadLocalStorage::set_thread(NULL) you added? > > Thanks, > StefanK > > On 04/05/16 01:39, David Holmes wrote: >> This needs attention from GC and runtime folk please. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8154715 >> webrev: http://cr.openjdk.java.net/~dholmes/8154715/webrev/ >> >> tl;dr: ensure ThreadLocalStorage::set_thread(NULL) is always called >> before a thread terminates. >> >> Background: >> >> Most system-related threads do not expect to explicitly terminate, >> except sometimes as part of VM termination. Such threads don't have >> their destructors called, but should. >> >> This omission came to light due to the ThreadLocalStorage changes in >> JDK-8132510. As part of that change we deleted the following from the >> termination path of the VMThread: >> >> // Thread destructor usually does this. >> ThreadLocalStorage::set_thread(NULL); >> >> The clearing of TLS seemed irrelevant to the VMThread as it primarily >> is used to aid in JNI attach/detach. However Brian Gardner reported: >> >> http://mail.openjdk.java.net/pipermail/bsd-port-dev/2016-February/002788.html >> >> >> a problem on FreeBSD caused by this change and the interaction with >> the POSIX pthread TLS destructor use introduced by JDK-8033696. >> Because the VMThread terminated without clearing TLS, when the >> TLS-destructor was called it got into a loop which ran four times (as >> happens on Linux) and then prints a warning to the console (which >> doesn't happen on Linux). >> >> This indicates we need to restore the: >> >> ThreadLocalStorage::set_thread(NULL); >> >> but on further consideration it seems to me that this is not confined >> to the VMThread, and the most appropriate fix would be to always >> invoke the Thread destructor as a thread terminates. >> >> Solution: >> >> Further investigation shows that calling the Thread destructor in the >> thread as it terminates is not possible: >> >> - VMThread >> >> This is actually destroyed by the thread that terminates the VM, but >> that can happen after it terminates and so we still hit the TLS >> problem. The VMThread may be able to destroy itself today but in the >> past this was not possible (see existing code comment), and in the >> future it may also not be possible - the problem is that the Thread >> destructor can interact with other VM subsystems that are concurrently >> being torn down by the thread that is terminating the VM. In the past >> this was the CodeHeap. So rather than introduce something that is >> fragile we stick with the current scheme but restore the >> ThreadLocalStorage::set_thread(NULL); - note we can't access "this" at >> that time because it may already have been de-allocated. >> >> - WatcherThread >> >> The WatcherThread is never destroyed today but has the same problem as >> the VMThread. We can call the destructor from the VM termination >> thread (and have implemented that), but not from the WatcherThread >> itself. So again we just have to restore the >> ThreadLocalStorage::set_thread(NULL); to fix the potential TLS problem. >> >> - GC Threads >> >> There are two cases: >> >> a) GC threads that never terminate >> >> For these we don't need to do anything: we can't delete the thread as >> it never terminates and we don't hit the TLS problem because it never >> terminates. So all we will do here is add some logic to check (in >> NON_PRODUCT) that we do in fact never terminate. >> >> b) GC threads that can terminate >> >> Despite the fact the threads can terminate, references to those >> threads are stored elsewhere (WorkGangs and other places) and are not >> cleared as part of the termination process. Those references can be >> touched after the thread has terminated so we can not call the >> destructor at all. So again all we can do (without some major thread >> management reworking) is ensure that >> ThreadLocalStorage::set_thread(NULL); is called before the thread >> actually terminates >> >> Testing: JPRT >> RBT - runtime nightly tests >> >> Thanks, >> David > From stefan.karlsson at oracle.com Fri May 6 14:04:02 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 6 May 2016 16:04:02 +0200 Subject: RFR: 8154715: Missing destructor and/or TLS clearing calls for terminating threads In-Reply-To: References: <572C4198.3090900@oracle.com> Message-ID: <572CA452.70401@oracle.com> Hi David, On 06/05/16 15:38, David Holmes wrote: > Hi Stefan, > > Thanks for taking a look at this. > > On 6/05/2016 5:02 PM, Stefan Karlsson wrote: >> Hi David, >> >> I looked through the GC part of this webrev and I think the change is >> fine. >> >> However, it seems a bit error prone. If we decide to change the code to, >> for example, terminate the AbstractGangWorker threads, then we have to >> remember to insert a ThreadLocalStorage::set_thread(NULL) call. > > That's why I added the ShouldNotReachHere()'s - if those threads start > terminating then we will see those hit. Perhaps a comment: > > ShouldNotReachHere(); // If thread terminates we have to do TLS cleanup > > ? Yes, I would appreciate a comment. Though, when we add new threads, we need to remember to add the set_thread(NULL) call. > >> Could we instead add a call to ThreadLocalStorage::set_thread(NULL), or >> maybe even Thread::clear_thread_current(), in java_start? >> >> static void *java_start(Thread *thread) { >> [...] >> thread->initialize_thread_current(); >> >> [...] >> >> // call one more level start routine >> thread->run(); >> >> ////////// Could we call Thread::clear_thread_current(); here? > > Not easily. For JavaThreads we've already done "delete this" inside > the run() method, so we'd have to move that into java_start as well, > but we can only do the delete for JavaThreads not for other threads. > And we'd also have to change the VMThread and WatcherThread > termination logic because of the deletes that happen in the > termination thread - the "this" pointer (thread above) may no longer > be valid when we want to call clear_current_thread() - which is why we > can only do the ThreadLocalStorage::set_thread(NULL). > > I agree it would be a lot cleaner to have java_start do: > > thread->common_initialization(); > thread->run(); > thread->common_cleanup(); > delete thread; > > for all threads, but we'd need a lot of other changes to allow for > that. Otherwise we would need to note that kind of thread before > calling run() then switch on the thread type after run() to decide > what kind of cleanup is necessary and possible. I don't think that > would be better than just doing the "right" cleanup at the end of the > run() methods. I understand that this is a bit messy, and I won't insist that we change this in this RFR, but without looking at this in much detail it sounds weird to delete the thread in run(). Couldn't this be solved by introducing a virtual Thread::post_run() function and do: virtual void Thread::post_run() { clear_thread_current(); } virtual void JavaThread::post_run() { Thread::post_run(); delete this; } Thanks, StefanK > > Thanks, > David > ------ > >> >> log_info(os, thread)("Thread finished (tid: " UINTX_FORMAT ", pthread >> id: " UINTX_FORMAT ").", >> os::current_thread_id(), (uintx) pthread_self()); >> >> return 0; >> } >> >> And get rid of the explicit calls to >> ThreadLocalStorage::set_thread(NULL) you added? >> >> Thanks, >> StefanK >> >> On 04/05/16 01:39, David Holmes wrote: >>> This needs attention from GC and runtime folk please. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8154715 >>> webrev: http://cr.openjdk.java.net/~dholmes/8154715/webrev/ >>> >>> tl;dr: ensure ThreadLocalStorage::set_thread(NULL) is always called >>> before a thread terminates. >>> >>> Background: >>> >>> Most system-related threads do not expect to explicitly terminate, >>> except sometimes as part of VM termination. Such threads don't have >>> their destructors called, but should. >>> >>> This omission came to light due to the ThreadLocalStorage changes in >>> JDK-8132510. As part of that change we deleted the following from the >>> termination path of the VMThread: >>> >>> // Thread destructor usually does this. >>> ThreadLocalStorage::set_thread(NULL); >>> >>> The clearing of TLS seemed irrelevant to the VMThread as it primarily >>> is used to aid in JNI attach/detach. However Brian Gardner reported: >>> >>> http://mail.openjdk.java.net/pipermail/bsd-port-dev/2016-February/002788.html >>> >>> >>> >>> a problem on FreeBSD caused by this change and the interaction with >>> the POSIX pthread TLS destructor use introduced by JDK-8033696. >>> Because the VMThread terminated without clearing TLS, when the >>> TLS-destructor was called it got into a loop which ran four times (as >>> happens on Linux) and then prints a warning to the console (which >>> doesn't happen on Linux). >>> >>> This indicates we need to restore the: >>> >>> ThreadLocalStorage::set_thread(NULL); >>> >>> but on further consideration it seems to me that this is not confined >>> to the VMThread, and the most appropriate fix would be to always >>> invoke the Thread destructor as a thread terminates. >>> >>> Solution: >>> >>> Further investigation shows that calling the Thread destructor in the >>> thread as it terminates is not possible: >>> >>> - VMThread >>> >>> This is actually destroyed by the thread that terminates the VM, but >>> that can happen after it terminates and so we still hit the TLS >>> problem. The VMThread may be able to destroy itself today but in the >>> past this was not possible (see existing code comment), and in the >>> future it may also not be possible - the problem is that the Thread >>> destructor can interact with other VM subsystems that are concurrently >>> being torn down by the thread that is terminating the VM. In the past >>> this was the CodeHeap. So rather than introduce something that is >>> fragile we stick with the current scheme but restore the >>> ThreadLocalStorage::set_thread(NULL); - note we can't access "this" at >>> that time because it may already have been de-allocated. >>> >>> - WatcherThread >>> >>> The WatcherThread is never destroyed today but has the same problem as >>> the VMThread. We can call the destructor from the VM termination >>> thread (and have implemented that), but not from the WatcherThread >>> itself. So again we just have to restore the >>> ThreadLocalStorage::set_thread(NULL); to fix the potential TLS problem. >>> >>> - GC Threads >>> >>> There are two cases: >>> >>> a) GC threads that never terminate >>> >>> For these we don't need to do anything: we can't delete the thread as >>> it never terminates and we don't hit the TLS problem because it never >>> terminates. So all we will do here is add some logic to check (in >>> NON_PRODUCT) that we do in fact never terminate. >>> >>> b) GC threads that can terminate >>> >>> Despite the fact the threads can terminate, references to those >>> threads are stored elsewhere (WorkGangs and other places) and are not >>> cleared as part of the termination process. Those references can be >>> touched after the thread has terminated so we can not call the >>> destructor at all. So again all we can do (without some major thread >>> management reworking) is ensure that >>> ThreadLocalStorage::set_thread(NULL); is called before the thread >>> actually terminates >>> >>> Testing: JPRT >>> RBT - runtime nightly tests >>> >>> Thanks, >>> David >> From david.holmes at oracle.com Fri May 6 14:32:30 2016 From: david.holmes at oracle.com (David Holmes) Date: Sat, 7 May 2016 00:32:30 +1000 Subject: RFR: 8154715: Missing destructor and/or TLS clearing calls for terminating threads In-Reply-To: <572CA452.70401@oracle.com> References: <572C4198.3090900@oracle.com> <572CA452.70401@oracle.com> Message-ID: <19147ab9-2480-3ace-6eaf-611eccc29ebf@oracle.com> On 7/05/2016 12:04 AM, Stefan Karlsson wrote: > Hi David, > > On 06/05/16 15:38, David Holmes wrote: >> Hi Stefan, >> >> Thanks for taking a look at this. >> >> On 6/05/2016 5:02 PM, Stefan Karlsson wrote: >>> Hi David, >>> >>> I looked through the GC part of this webrev and I think the change is >>> fine. >>> >>> However, it seems a bit error prone. If we decide to change the code to, >>> for example, terminate the AbstractGangWorker threads, then we have to >>> remember to insert a ThreadLocalStorage::set_thread(NULL) call. >> >> That's why I added the ShouldNotReachHere()'s - if those threads start >> terminating then we will see those hit. Perhaps a comment: >> >> ShouldNotReachHere(); // If thread terminates we have to do TLS cleanup >> >> ? > > Yes, I would appreciate a comment. Though, when we add new threads, we > need to remember to add the set_thread(NULL) call. Well no, what you would do is manage your new threads in such a way that their run() method can do "delete this" as the last call. Only if you can't do that do you need to think about what termination logic is missing that needs to be done in lieu of the destructor. >> >>> Could we instead add a call to ThreadLocalStorage::set_thread(NULL), or >>> maybe even Thread::clear_thread_current(), in java_start? >>> >>> static void *java_start(Thread *thread) { >>> [...] >>> thread->initialize_thread_current(); >>> >>> [...] >>> >>> // call one more level start routine >>> thread->run(); >>> >>> ////////// Could we call Thread::clear_thread_current(); here? >> >> Not easily. For JavaThreads we've already done "delete this" inside >> the run() method, so we'd have to move that into java_start as well, >> but we can only do the delete for JavaThreads not for other threads. >> And we'd also have to change the VMThread and WatcherThread >> termination logic because of the deletes that happen in the >> termination thread - the "this" pointer (thread above) may no longer >> be valid when we want to call clear_current_thread() - which is why we >> can only do the ThreadLocalStorage::set_thread(NULL). >> >> I agree it would be a lot cleaner to have java_start do: >> >> thread->common_initialization(); >> thread->run(); >> thread->common_cleanup(); >> delete thread; >> >> for all threads, but we'd need a lot of other changes to allow for >> that. Otherwise we would need to note that kind of thread before >> calling run() then switch on the thread type after run() to decide >> what kind of cleanup is necessary and possible. I don't think that >> would be better than just doing the "right" cleanup at the end of the >> run() methods. > > I understand that this is a bit messy, and I won't insist that we change > this in this RFR, but without looking at this in much detail it sounds > weird to delete the thread in run(). Couldn't this be solved by > introducing a virtual Thread::post_run() function and do: > > virtual void Thread::post_run() { > clear_thread_current(); > } > > virtual void JavaThread::post_run() { > Thread::post_run(); > delete this; > } But again this can't work for the VMThread or WatcherThread as they are deleted from the termination thread and so thread->post_run() may SEGV.** Plus it is only after the fact that you realize not to put "delete this" in Thread::post_run(). ** Arguably the best solution to the "thread termination races with VM termination" problem is to not let the threads terminate. The code as it exists today can still have JavaThreads destroying themselves at the same that the VM is terminating and potentially hit the same errors that require us to not allow the VMThread (and now WatcherThread) to delete themselves. Thanks, David > Thanks, > StefanK > >> >> Thanks, >> David >> ------ >> >>> >>> log_info(os, thread)("Thread finished (tid: " UINTX_FORMAT ", pthread >>> id: " UINTX_FORMAT ").", >>> os::current_thread_id(), (uintx) pthread_self()); >>> >>> return 0; >>> } >>> >>> And get rid of the explicit calls to >>> ThreadLocalStorage::set_thread(NULL) you added? >>> >>> Thanks, >>> StefanK >>> >>> On 04/05/16 01:39, David Holmes wrote: >>>> This needs attention from GC and runtime folk please. >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8154715 >>>> webrev: http://cr.openjdk.java.net/~dholmes/8154715/webrev/ >>>> >>>> tl;dr: ensure ThreadLocalStorage::set_thread(NULL) is always called >>>> before a thread terminates. >>>> >>>> Background: >>>> >>>> Most system-related threads do not expect to explicitly terminate, >>>> except sometimes as part of VM termination. Such threads don't have >>>> their destructors called, but should. >>>> >>>> This omission came to light due to the ThreadLocalStorage changes in >>>> JDK-8132510. As part of that change we deleted the following from the >>>> termination path of the VMThread: >>>> >>>> // Thread destructor usually does this. >>>> ThreadLocalStorage::set_thread(NULL); >>>> >>>> The clearing of TLS seemed irrelevant to the VMThread as it primarily >>>> is used to aid in JNI attach/detach. However Brian Gardner reported: >>>> >>>> http://mail.openjdk.java.net/pipermail/bsd-port-dev/2016-February/002788.html >>>> >>>> >>>> >>>> a problem on FreeBSD caused by this change and the interaction with >>>> the POSIX pthread TLS destructor use introduced by JDK-8033696. >>>> Because the VMThread terminated without clearing TLS, when the >>>> TLS-destructor was called it got into a loop which ran four times (as >>>> happens on Linux) and then prints a warning to the console (which >>>> doesn't happen on Linux). >>>> >>>> This indicates we need to restore the: >>>> >>>> ThreadLocalStorage::set_thread(NULL); >>>> >>>> but on further consideration it seems to me that this is not confined >>>> to the VMThread, and the most appropriate fix would be to always >>>> invoke the Thread destructor as a thread terminates. >>>> >>>> Solution: >>>> >>>> Further investigation shows that calling the Thread destructor in the >>>> thread as it terminates is not possible: >>>> >>>> - VMThread >>>> >>>> This is actually destroyed by the thread that terminates the VM, but >>>> that can happen after it terminates and so we still hit the TLS >>>> problem. The VMThread may be able to destroy itself today but in the >>>> past this was not possible (see existing code comment), and in the >>>> future it may also not be possible - the problem is that the Thread >>>> destructor can interact with other VM subsystems that are concurrently >>>> being torn down by the thread that is terminating the VM. In the past >>>> this was the CodeHeap. So rather than introduce something that is >>>> fragile we stick with the current scheme but restore the >>>> ThreadLocalStorage::set_thread(NULL); - note we can't access "this" at >>>> that time because it may already have been de-allocated. >>>> >>>> - WatcherThread >>>> >>>> The WatcherThread is never destroyed today but has the same problem as >>>> the VMThread. We can call the destructor from the VM termination >>>> thread (and have implemented that), but not from the WatcherThread >>>> itself. So again we just have to restore the >>>> ThreadLocalStorage::set_thread(NULL); to fix the potential TLS problem. >>>> >>>> - GC Threads >>>> >>>> There are two cases: >>>> >>>> a) GC threads that never terminate >>>> >>>> For these we don't need to do anything: we can't delete the thread as >>>> it never terminates and we don't hit the TLS problem because it never >>>> terminates. So all we will do here is add some logic to check (in >>>> NON_PRODUCT) that we do in fact never terminate. >>>> >>>> b) GC threads that can terminate >>>> >>>> Despite the fact the threads can terminate, references to those >>>> threads are stored elsewhere (WorkGangs and other places) and are not >>>> cleared as part of the termination process. Those references can be >>>> touched after the thread has terminated so we can not call the >>>> destructor at all. So again all we can do (without some major thread >>>> management reworking) is ensure that >>>> ThreadLocalStorage::set_thread(NULL); is called before the thread >>>> actually terminates >>>> >>>> Testing: JPRT >>>> RBT - runtime nightly tests >>>> >>>> Thanks, >>>> David >>> > From stefan.karlsson at oracle.com Fri May 6 15:41:36 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 6 May 2016 17:41:36 +0200 Subject: RFR: 8154715: Missing destructor and/or TLS clearing calls for terminating threads In-Reply-To: <19147ab9-2480-3ace-6eaf-611eccc29ebf@oracle.com> References: <572C4198.3090900@oracle.com> <572CA452.70401@oracle.com> <19147ab9-2480-3ace-6eaf-611eccc29ebf@oracle.com> Message-ID: <572CBB30.1010801@oracle.com> On 06/05/16 16:32, David Holmes wrote: > On 7/05/2016 12:04 AM, Stefan Karlsson wrote: >> Hi David, >> >> On 06/05/16 15:38, David Holmes wrote: >>> Hi Stefan, >>> >>> Thanks for taking a look at this. >>> >>> On 6/05/2016 5:02 PM, Stefan Karlsson wrote: >>>> Hi David, >>>> >>>> I looked through the GC part of this webrev and I think the change is >>>> fine. >>>> >>>> However, it seems a bit error prone. If we decide to change the >>>> code to, >>>> for example, terminate the AbstractGangWorker threads, then we >>>> have to >>>> remember to insert a ThreadLocalStorage::set_thread(NULL) call. >>> >>> That's why I added the ShouldNotReachHere()'s - if those threads start >>> terminating then we will see those hit. Perhaps a comment: >>> >>> ShouldNotReachHere(); // If thread terminates we have to do TLS cleanup >>> >>> ? >> >> Yes, I would appreciate a comment. Though, when we add new threads, we >> need to remember to add the set_thread(NULL) call. > > Well no, what you would do is manage your new threads in such a way > that their run() method can do "delete this" as the last call. Only if > you can't do that do you need to think about what termination logic is > missing that needs to be done in lieu of the destructor. Yes, but this forces every implementer of a Thread:run() function to have to think about these kind of requirements. > >>> >>>> Could we instead add a call to >>>> ThreadLocalStorage::set_thread(NULL), or >>>> maybe even Thread::clear_thread_current(), in java_start? >>>> >>>> static void *java_start(Thread *thread) { >>>> [...] >>>> thread->initialize_thread_current(); >>>> >>>> [...] >>>> >>>> // call one more level start routine >>>> thread->run(); >>>> >>>> ////////// Could we call Thread::clear_thread_current(); here? >>> >>> Not easily. For JavaThreads we've already done "delete this" inside >>> the run() method, so we'd have to move that into java_start as well, >>> but we can only do the delete for JavaThreads not for other threads. >>> And we'd also have to change the VMThread and WatcherThread >>> termination logic because of the deletes that happen in the >>> termination thread - the "this" pointer (thread above) may no longer >>> be valid when we want to call clear_current_thread() - which is why we >>> can only do the ThreadLocalStorage::set_thread(NULL). >>> >>> I agree it would be a lot cleaner to have java_start do: >>> >>> thread->common_initialization(); >>> thread->run(); >>> thread->common_cleanup(); >>> delete thread; >>> >>> for all threads, but we'd need a lot of other changes to allow for >>> that. Otherwise we would need to note that kind of thread before >>> calling run() then switch on the thread type after run() to decide >>> what kind of cleanup is necessary and possible. I don't think that >>> would be better than just doing the "right" cleanup at the end of the >>> run() methods. >> >> I understand that this is a bit messy, and I won't insist that we change >> this in this RFR, but without looking at this in much detail it sounds >> weird to delete the thread in run(). Couldn't this be solved by >> introducing a virtual Thread::post_run() function and do: >> >> virtual void Thread::post_run() { >> clear_thread_current(); >> } >> >> virtual void JavaThread::post_run() { >> Thread::post_run(); >> delete this; >> } > > But again this can't work for the VMThread or WatcherThread as they > are deleted from the termination thread and so thread->post_run() may > SEGV.** Plus it is only after the fact that you realize not to put > "delete this" in Thread::post_run(). OK, I didn't understand what you meant with "termination thread", but I now see the call to VMThread::destroy(). With that said, I find it odd that VMThread::destroy() deletes the VM thread. We already handshake between the VMThread and the "termination thread", so why isn't that VMThread::post_run() implemented as: virtual void VMThread::post_run() { // signal other threads that VM process is gone { // Note: we must have the _no_safepoint_check_flag. Mutex::lock() allows // VM thread to enter any lock at Safepoint as long as its _owner is NULL. // If that happens after _terminate_lock->wait() has unset _owner // but before it actually drops the lock and waits, the notification below // may get lost and we will have a hang. To avoid this, we need to use // Mutex::lock_without_safepoint_check(). MutexLockerEx ml(_terminate_lock, Mutex::_no_safepoint_check_flag); _terminated = true; _terminate_lock->notify(); } Thread::post_run(); delete this; } And then we wouldn't get a SEGV ... I couldn't find the destructor for the WatchThread, but it seems easy to fix that as well. I'm probably missing something, but I find it a bit annoying that code that should belong to the *Thread:ing system leaks into the implementations of *Thread::run(). Thanks, StefanK > > ** Arguably the best solution to the "thread termination races with VM > termination" problem is to not let the threads terminate. The code as > it exists today can still have JavaThreads destroying themselves at > the same that the VM is terminating and potentially hit the same > errors that require us to not allow the VMThread (and now > WatcherThread) to delete themselves. > > Thanks, > David > >> Thanks, >> StefanK >> >>> >>> Thanks, >>> David >>> ------ >>> >>>> >>>> log_info(os, thread)("Thread finished (tid: " UINTX_FORMAT ", >>>> pthread >>>> id: " UINTX_FORMAT ").", >>>> os::current_thread_id(), (uintx) pthread_self()); >>>> >>>> return 0; >>>> } >>>> >>>> And get rid of the explicit calls to >>>> ThreadLocalStorage::set_thread(NULL) you added? >>>> >>>> Thanks, >>>> StefanK >>>> >>>> On 04/05/16 01:39, David Holmes wrote: >>>>> This needs attention from GC and runtime folk please. >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8154715 >>>>> webrev: http://cr.openjdk.java.net/~dholmes/8154715/webrev/ >>>>> >>>>> tl;dr: ensure ThreadLocalStorage::set_thread(NULL) is always called >>>>> before a thread terminates. >>>>> >>>>> Background: >>>>> >>>>> Most system-related threads do not expect to explicitly terminate, >>>>> except sometimes as part of VM termination. Such threads don't have >>>>> their destructors called, but should. >>>>> >>>>> This omission came to light due to the ThreadLocalStorage changes in >>>>> JDK-8132510. As part of that change we deleted the following from the >>>>> termination path of the VMThread: >>>>> >>>>> // Thread destructor usually does this. >>>>> ThreadLocalStorage::set_thread(NULL); >>>>> >>>>> The clearing of TLS seemed irrelevant to the VMThread as it primarily >>>>> is used to aid in JNI attach/detach. However Brian Gardner reported: >>>>> >>>>> http://mail.openjdk.java.net/pipermail/bsd-port-dev/2016-February/002788.html >>>>> >>>>> >>>>> >>>>> >>>>> a problem on FreeBSD caused by this change and the interaction with >>>>> the POSIX pthread TLS destructor use introduced by JDK-8033696. >>>>> Because the VMThread terminated without clearing TLS, when the >>>>> TLS-destructor was called it got into a loop which ran four times (as >>>>> happens on Linux) and then prints a warning to the console (which >>>>> doesn't happen on Linux). >>>>> >>>>> This indicates we need to restore the: >>>>> >>>>> ThreadLocalStorage::set_thread(NULL); >>>>> >>>>> but on further consideration it seems to me that this is not confined >>>>> to the VMThread, and the most appropriate fix would be to always >>>>> invoke the Thread destructor as a thread terminates. >>>>> >>>>> Solution: >>>>> >>>>> Further investigation shows that calling the Thread destructor in the >>>>> thread as it terminates is not possible: >>>>> >>>>> - VMThread >>>>> >>>>> This is actually destroyed by the thread that terminates the VM, but >>>>> that can happen after it terminates and so we still hit the TLS >>>>> problem. The VMThread may be able to destroy itself today but in the >>>>> past this was not possible (see existing code comment), and in the >>>>> future it may also not be possible - the problem is that the Thread >>>>> destructor can interact with other VM subsystems that are >>>>> concurrently >>>>> being torn down by the thread that is terminating the VM. In the past >>>>> this was the CodeHeap. So rather than introduce something that is >>>>> fragile we stick with the current scheme but restore the >>>>> ThreadLocalStorage::set_thread(NULL); - note we can't access >>>>> "this" at >>>>> that time because it may already have been de-allocated. >>>>> >>>>> - WatcherThread >>>>> >>>>> The WatcherThread is never destroyed today but has the same >>>>> problem as >>>>> the VMThread. We can call the destructor from the VM termination >>>>> thread (and have implemented that), but not from the WatcherThread >>>>> itself. So again we just have to restore the >>>>> ThreadLocalStorage::set_thread(NULL); to fix the potential TLS >>>>> problem. >>>>> >>>>> - GC Threads >>>>> >>>>> There are two cases: >>>>> >>>>> a) GC threads that never terminate >>>>> >>>>> For these we don't need to do anything: we can't delete the thread as >>>>> it never terminates and we don't hit the TLS problem because it never >>>>> terminates. So all we will do here is add some logic to check (in >>>>> NON_PRODUCT) that we do in fact never terminate. >>>>> >>>>> b) GC threads that can terminate >>>>> >>>>> Despite the fact the threads can terminate, references to those >>>>> threads are stored elsewhere (WorkGangs and other places) and are not >>>>> cleared as part of the termination process. Those references can be >>>>> touched after the thread has terminated so we can not call the >>>>> destructor at all. So again all we can do (without some major thread >>>>> management reworking) is ensure that >>>>> ThreadLocalStorage::set_thread(NULL); is called before the thread >>>>> actually terminates >>>>> >>>>> Testing: JPRT >>>>> RBT - runtime nightly tests >>>>> >>>>> Thanks, >>>>> David >>>> >> From aph at redhat.com Fri May 6 16:12:48 2016 From: aph at redhat.com (Andrew Haley) Date: Fri, 6 May 2016 17:12:48 +0100 Subject: RFR: 8155627: Enable SA on AArch64 In-Reply-To: <101be161-cfb4-b2d4-0b35-0d497d3dfa19@oracle.com> References: <57168C17.40307@oracle.com> <57185E31.9010705@oracle.com> <57235E1B.8080001@redhat.com> <57235F39.5080204@redhat.com> <101be161-cfb4-b2d4-0b35-0d497d3dfa19@oracle.com> Message-ID: <572CC280.3050308@redhat.com> Two fixes here. 1. SA is not enabled at all in the builds. I have no idea why; it used to work. 2. 8154580 broke the interpreter stack frame handling. http://cr.openjdk.java.net/~aph/8155627 Thanks, Andrew. From openjdk at getsnappy.com Fri May 6 19:36:24 2016 From: openjdk at getsnappy.com (Brian Gardner) Date: Fri, 6 May 2016 12:36:24 -0700 Subject: RFR: 8154715: Missing destructor and/or TLS clearing calls for terminating threads In-Reply-To: References: Message-ID: After applying your patches I still saw the cleanup messages from pthread. After comparing my original patch to yours and doing some testing it looks like we missed a couple spots. The warning went away after I applied the following patches: http://brian.timestudybuddy.com/webrev/hotspot__clear_thread_current/webrev/hotspot/src/share/vm/gc/shared/concurrentGCThread.cpp.cdiff.html http://brian.timestudybuddy.com/webrev/hotspot__clear_thread_current/webrev/hotspot/src/share/vm/gc/cms/concurrentMarkSweepThread.cpp.cdiff.html Brian > On May 3, 2016, at 4:39 PM, David Holmes wrote: > > This needs attention from GC and runtime folk please. > > bug: https://bugs.openjdk.java.net/browse/JDK-8154715 > webrev: http://cr.openjdk.java.net/~dholmes/8154715/webrev/ > > tl;dr: ensure ThreadLocalStorage::set_thread(NULL) is always called before a thread terminates. > > Background: > > Most system-related threads do not expect to explicitly terminate, except sometimes as part of VM termination. Such threads don't have their destructors called, but should. > > This omission came to light due to the ThreadLocalStorage changes in JDK-8132510. As part of that change we deleted the following from the termination path of the VMThread: > > // Thread destructor usually does this. > ThreadLocalStorage::set_thread(NULL); > > The clearing of TLS seemed irrelevant to the VMThread as it primarily is used to aid in JNI attach/detach. However Brian Gardner reported: > > http://mail.openjdk.java.net/pipermail/bsd-port-dev/2016-February/002788.html > > a problem on FreeBSD caused by this change and the interaction with the POSIX pthread TLS destructor use introduced by JDK-8033696. Because the VMThread terminated without clearing TLS, when the TLS-destructor was called it got into a loop which ran four times (as happens on Linux) and then prints a warning to the console (which doesn't happen on Linux). > > This indicates we need to restore the: > > ThreadLocalStorage::set_thread(NULL); > > but on further consideration it seems to me that this is not confined to the VMThread, and the most appropriate fix would be to always invoke the Thread destructor as a thread terminates. > > Solution: > > Further investigation shows that calling the Thread destructor in the thread as it terminates is not possible: > > - VMThread > > This is actually destroyed by the thread that terminates the VM, but that can happen after it terminates and so we still hit the TLS problem. The VMThread may be able to destroy itself today but in the past this was not possible (see existing code comment), and in the future it may also not be possible - the problem is that the Thread destructor can interact with other VM subsystems that are concurrently being torn down by the thread that is terminating the VM. In the past this was the CodeHeap. So rather than introduce something that is fragile we stick with the current scheme but restore the ThreadLocalStorage::set_thread(NULL); - note we can't access "this" at that time because it may already have been de-allocated. > > - WatcherThread > > The WatcherThread is never destroyed today but has the same problem as the VMThread. We can call the destructor from the VM termination thread (and have implemented that), but not from the WatcherThread itself. So again we just have to restore the ThreadLocalStorage::set_thread(NULL); to fix the potential TLS problem. > > - GC Threads > > There are two cases: > > a) GC threads that never terminate > > For these we don't need to do anything: we can't delete the thread as it never terminates and we don't hit the TLS problem because it never terminates. So all we will do here is add some logic to check (in NON_PRODUCT) that we do in fact never terminate. > > b) GC threads that can terminate > > Despite the fact the threads can terminate, references to those threads are stored elsewhere (WorkGangs and other places) and are not cleared as part of the termination process. Those references can be touched after the thread has terminated so we can not call the destructor at all. So again all we can do (without some major thread management reworking) is ensure that ThreadLocalStorage::set_thread(NULL); is called before the thread actually terminates > > Testing: JPRT > RBT - runtime nightly tests > > Thanks, > David > From openjdk at getsnappy.com Fri May 6 19:40:20 2016 From: openjdk at getsnappy.com (Brian Gardner) Date: Fri, 6 May 2016 12:40:20 -0700 Subject: RFR: 8154715: Missing destructor and/or TLS clearing calls for terminating threads In-Reply-To: <572CBB30.1010801@oracle.com> References: <572C4198.3090900@oracle.com> <572CA452.70401@oracle.com> <19147ab9-2480-3ace-6eaf-611eccc29ebf@oracle.com> <572CBB30.1010801@oracle.com> Message-ID: I agree with Stefan. When I initially ran into the problem I came up with the following changeset that solves my problem, by calling clear_thread_current at the end of java_start. http://brian.timestudybuddy.com/webrev/hotspot__clear_thread_current_alt/webrev/ Brian > On May 6, 2016, at 8:41 AM, Stefan Karlsson wrote: > > On 06/05/16 16:32, David Holmes wrote: >> On 7/05/2016 12:04 AM, Stefan Karlsson wrote: >>> Hi David, >>> >>> On 06/05/16 15:38, David Holmes wrote: >>>> Hi Stefan, >>>> >>>> Thanks for taking a look at this. >>>> >>>> On 6/05/2016 5:02 PM, Stefan Karlsson wrote: >>>>> Hi David, >>>>> >>>>> I looked through the GC part of this webrev and I think the change is >>>>> fine. >>>>> >>>>> However, it seems a bit error prone. If we decide to change the code to, >>>>> for example, terminate the AbstractGangWorker threads, then we have to >>>>> remember to insert a ThreadLocalStorage::set_thread(NULL) call. >>>> >>>> That's why I added the ShouldNotReachHere()'s - if those threads start >>>> terminating then we will see those hit. Perhaps a comment: >>>> >>>> ShouldNotReachHere(); // If thread terminates we have to do TLS cleanup >>>> >>>> ? >>> >>> Yes, I would appreciate a comment. Though, when we add new threads, we >>> need to remember to add the set_thread(NULL) call. >> >> Well no, what you would do is manage your new threads in such a way that their run() method can do "delete this" as the last call. Only if you can't do that do you need to think about what termination logic is missing that needs to be done in lieu of the destructor. > > Yes, but this forces every implementer of a Thread:run() function to have to think about these kind of requirements. > >> >>>> >>>>> Could we instead add a call to ThreadLocalStorage::set_thread(NULL), or >>>>> maybe even Thread::clear_thread_current(), in java_start? >>>>> >>>>> static void *java_start(Thread *thread) { >>>>> [...] >>>>> thread->initialize_thread_current(); >>>>> >>>>> [...] >>>>> >>>>> // call one more level start routine >>>>> thread->run(); >>>>> >>>>> ////////// Could we call Thread::clear_thread_current(); here? >>>> >>>> Not easily. For JavaThreads we've already done "delete this" inside >>>> the run() method, so we'd have to move that into java_start as well, >>>> but we can only do the delete for JavaThreads not for other threads. >>>> And we'd also have to change the VMThread and WatcherThread >>>> termination logic because of the deletes that happen in the >>>> termination thread - the "this" pointer (thread above) may no longer >>>> be valid when we want to call clear_current_thread() - which is why we >>>> can only do the ThreadLocalStorage::set_thread(NULL). >>>> >>>> I agree it would be a lot cleaner to have java_start do: >>>> >>>> thread->common_initialization(); >>>> thread->run(); >>>> thread->common_cleanup(); >>>> delete thread; >>>> >>>> for all threads, but we'd need a lot of other changes to allow for >>>> that. Otherwise we would need to note that kind of thread before >>>> calling run() then switch on the thread type after run() to decide >>>> what kind of cleanup is necessary and possible. I don't think that >>>> would be better than just doing the "right" cleanup at the end of the >>>> run() methods. >>> >>> I understand that this is a bit messy, and I won't insist that we change >>> this in this RFR, but without looking at this in much detail it sounds >>> weird to delete the thread in run(). Couldn't this be solved by >>> introducing a virtual Thread::post_run() function and do: >>> >>> virtual void Thread::post_run() { >>> clear_thread_current(); >>> } >>> >>> virtual void JavaThread::post_run() { >>> Thread::post_run(); >>> delete this; >>> } >> >> But again this can't work for the VMThread or WatcherThread as they are deleted from the termination thread and so thread->post_run() may SEGV.** Plus it is only after the fact that you realize not to put "delete this" in Thread::post_run(). > > OK, I didn't understand what you meant with "termination thread", but I now see the call to VMThread::destroy(). > > With that said, I find it odd that VMThread::destroy() deletes the VM thread. We already handshake between the VMThread and the "termination thread", so why isn't that VMThread::post_run() implemented as: > > virtual void VMThread::post_run() { > // signal other threads that VM process is gone > { > // Note: we must have the _no_safepoint_check_flag. Mutex::lock() allows > // VM thread to enter any lock at Safepoint as long as its _owner is NULL. > // If that happens after _terminate_lock->wait() has unset _owner > // but before it actually drops the lock and waits, the notification below > // may get lost and we will have a hang. To avoid this, we need to use > // Mutex::lock_without_safepoint_check(). > MutexLockerEx ml(_terminate_lock, Mutex::_no_safepoint_check_flag); > _terminated = true; > _terminate_lock->notify(); > } > > Thread::post_run(); > delete this; > } > > And then we wouldn't get a SEGV ... > > I couldn't find the destructor for the WatchThread, but it seems easy to fix that as well. > > I'm probably missing something, but I find it a bit annoying that code that should belong to the *Thread:ing system leaks into the implementations of *Thread::run(). > > Thanks, > StefanK >> >> ** Arguably the best solution to the "thread termination races with VM termination" problem is to not let the threads terminate. The code as it exists today can still have JavaThreads destroying themselves at the same that the VM is terminating and potentially hit the same errors that require us to not allow the VMThread (and now WatcherThread) to delete themselves. >> >> Thanks, >> David >> >>> Thanks, >>> StefanK >>> >>>> >>>> Thanks, >>>> David >>>> ------ >>>> >>>>> >>>>> log_info(os, thread)("Thread finished (tid: " UINTX_FORMAT ", pthread >>>>> id: " UINTX_FORMAT ").", >>>>> os::current_thread_id(), (uintx) pthread_self()); >>>>> >>>>> return 0; >>>>> } >>>>> >>>>> And get rid of the explicit calls to >>>>> ThreadLocalStorage::set_thread(NULL) you added? >>>>> >>>>> Thanks, >>>>> StefanK >>>>> >>>>> On 04/05/16 01:39, David Holmes wrote: >>>>>> This needs attention from GC and runtime folk please. >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8154715 >>>>>> webrev: http://cr.openjdk.java.net/~dholmes/8154715/webrev/ >>>>>> >>>>>> tl;dr: ensure ThreadLocalStorage::set_thread(NULL) is always called >>>>>> before a thread terminates. >>>>>> >>>>>> Background: >>>>>> >>>>>> Most system-related threads do not expect to explicitly terminate, >>>>>> except sometimes as part of VM termination. Such threads don't have >>>>>> their destructors called, but should. >>>>>> >>>>>> This omission came to light due to the ThreadLocalStorage changes in >>>>>> JDK-8132510. As part of that change we deleted the following from the >>>>>> termination path of the VMThread: >>>>>> >>>>>> // Thread destructor usually does this. >>>>>> ThreadLocalStorage::set_thread(NULL); >>>>>> >>>>>> The clearing of TLS seemed irrelevant to the VMThread as it primarily >>>>>> is used to aid in JNI attach/detach. However Brian Gardner reported: >>>>>> >>>>>> http://mail.openjdk.java.net/pipermail/bsd-port-dev/2016-February/002788.html >>>>>> >>>>>> >>>>>> >>>>>> a problem on FreeBSD caused by this change and the interaction with >>>>>> the POSIX pthread TLS destructor use introduced by JDK-8033696. >>>>>> Because the VMThread terminated without clearing TLS, when the >>>>>> TLS-destructor was called it got into a loop which ran four times (as >>>>>> happens on Linux) and then prints a warning to the console (which >>>>>> doesn't happen on Linux). >>>>>> >>>>>> This indicates we need to restore the: >>>>>> >>>>>> ThreadLocalStorage::set_thread(NULL); >>>>>> >>>>>> but on further consideration it seems to me that this is not confined >>>>>> to the VMThread, and the most appropriate fix would be to always >>>>>> invoke the Thread destructor as a thread terminates. >>>>>> >>>>>> Solution: >>>>>> >>>>>> Further investigation shows that calling the Thread destructor in the >>>>>> thread as it terminates is not possible: >>>>>> >>>>>> - VMThread >>>>>> >>>>>> This is actually destroyed by the thread that terminates the VM, but >>>>>> that can happen after it terminates and so we still hit the TLS >>>>>> problem. The VMThread may be able to destroy itself today but in the >>>>>> past this was not possible (see existing code comment), and in the >>>>>> future it may also not be possible - the problem is that the Thread >>>>>> destructor can interact with other VM subsystems that are concurrently >>>>>> being torn down by the thread that is terminating the VM. In the past >>>>>> this was the CodeHeap. So rather than introduce something that is >>>>>> fragile we stick with the current scheme but restore the >>>>>> ThreadLocalStorage::set_thread(NULL); - note we can't access "this" at >>>>>> that time because it may already have been de-allocated. >>>>>> >>>>>> - WatcherThread >>>>>> >>>>>> The WatcherThread is never destroyed today but has the same problem as >>>>>> the VMThread. We can call the destructor from the VM termination >>>>>> thread (and have implemented that), but not from the WatcherThread >>>>>> itself. So again we just have to restore the >>>>>> ThreadLocalStorage::set_thread(NULL); to fix the potential TLS problem. >>>>>> >>>>>> - GC Threads >>>>>> >>>>>> There are two cases: >>>>>> >>>>>> a) GC threads that never terminate >>>>>> >>>>>> For these we don't need to do anything: we can't delete the thread as >>>>>> it never terminates and we don't hit the TLS problem because it never >>>>>> terminates. So all we will do here is add some logic to check (in >>>>>> NON_PRODUCT) that we do in fact never terminate. >>>>>> >>>>>> b) GC threads that can terminate >>>>>> >>>>>> Despite the fact the threads can terminate, references to those >>>>>> threads are stored elsewhere (WorkGangs and other places) and are not >>>>>> cleared as part of the termination process. Those references can be >>>>>> touched after the thread has terminated so we can not call the >>>>>> destructor at all. So again all we can do (without some major thread >>>>>> management reworking) is ensure that >>>>>> ThreadLocalStorage::set_thread(NULL); is called before the thread >>>>>> actually terminates >>>>>> >>>>>> Testing: JPRT >>>>>> RBT - runtime nightly tests >>>>>> >>>>>> Thanks, >>>>>> David From vladimir.kozlov at oracle.com Fri May 6 22:19:47 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 6 May 2016 15:19:47 -0700 Subject: RFR(XS) 8156480: Quarantine compiler/jvmci/compilerToVM/ReadUncompressedOopTest.java Message-ID: Quarantine the test which cause failure [1] until RFE [2] is implemented which should resolve [1] issue. https://bugs.openjdk.java.net/browse/JDK-8156480 diff -r 481284d8ed27 test/compiler/jvmci/compilerToVM/ReadUncompressedOopTest.java --- a/test/compiler/jvmci/compilerToVM/ReadUncompressedOopTest.java +++ b/test/compiler/jvmci/compilerToVM/ReadUncompressedOopTest.java @@ -24,6 +24,7 @@ /* * @test * @bug 8136421 + * @ignore 8155216 * @requires (os.simpleArch == "x64" | os.simpleArch == "sparcv9" | os.simpleArch == "aarch64") * @library / /testlibrary /test/lib/ * @library ../common/patches [1] https://bugs.openjdk.java.net/browse/JDK-8155216 [2] https://bugs.openjdk.java.net/browse/JDK-8156159 Thanks, Vladimir From daniel.daugherty at oracle.com Fri May 6 22:22:17 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 6 May 2016 16:22:17 -0600 Subject: RFR(XS) 8156480: Quarantine compiler/jvmci/compilerToVM/ReadUncompressedOopTest.java In-Reply-To: References: Message-ID: <0aa467da-ae25-98df-5ae8-ba9fc25f737d@oracle.com> Thumbs up. HotSpot trivial change rule is appropriate. You only need one (R)eviewer and you don't have to wait 24 hours. Dan On 5/6/16 4:19 PM, Vladimir Kozlov wrote: > Quarantine the test which cause failure [1] until RFE [2] is > implemented which should resolve [1] issue. > > https://bugs.openjdk.java.net/browse/JDK-8156480 > > diff -r 481284d8ed27 > test/compiler/jvmci/compilerToVM/ReadUncompressedOopTest.java > --- a/test/compiler/jvmci/compilerToVM/ReadUncompressedOopTest.java > +++ b/test/compiler/jvmci/compilerToVM/ReadUncompressedOopTest.java > @@ -24,6 +24,7 @@ > /* > * @test > * @bug 8136421 > + * @ignore 8155216 > * @requires (os.simpleArch == "x64" | os.simpleArch == "sparcv9" | > os.simpleArch == "aarch64") > * @library / /testlibrary /test/lib/ > * @library ../common/patches > > [1] https://bugs.openjdk.java.net/browse/JDK-8155216 > [2] https://bugs.openjdk.java.net/browse/JDK-8156159 > > Thanks, > Vladimir > From vladimir.kozlov at oracle.com Fri May 6 22:32:36 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 6 May 2016 15:32:36 -0700 Subject: RFR(XS) 8156480: Quarantine compiler/jvmci/compilerToVM/ReadUncompressedOopTest.java In-Reply-To: <0aa467da-ae25-98df-5ae8-ba9fc25f737d@oracle.com> References: <0aa467da-ae25-98df-5ae8-ba9fc25f737d@oracle.com> Message-ID: <61b0adc8-0fb5-7ebc-da87-cd1987a68db1@oracle.com> Thanks, Dan Vladimir On 5/6/16 3:22 PM, Daniel D. Daugherty wrote: > Thumbs up. > > HotSpot trivial change rule is appropriate. You only need one (R)eviewer > and you don't have to wait 24 hours. > > Dan > > > On 5/6/16 4:19 PM, Vladimir Kozlov wrote: >> Quarantine the test which cause failure [1] until RFE [2] is implemented which should resolve [1] issue. >> >> https://bugs.openjdk.java.net/browse/JDK-8156480 >> >> diff -r 481284d8ed27 test/compiler/jvmci/compilerToVM/ReadUncompressedOopTest.java >> --- a/test/compiler/jvmci/compilerToVM/ReadUncompressedOopTest.java >> +++ b/test/compiler/jvmci/compilerToVM/ReadUncompressedOopTest.java >> @@ -24,6 +24,7 @@ >> /* >> * @test >> * @bug 8136421 >> + * @ignore 8155216 >> * @requires (os.simpleArch == "x64" | os.simpleArch == "sparcv9" | os.simpleArch == "aarch64") >> * @library / /testlibrary /test/lib/ >> * @library ../common/patches >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8155216 >> [2] https://bugs.openjdk.java.net/browse/JDK-8156159 >> >> Thanks, >> Vladimir >> > From david.holmes at oracle.com Fri May 6 23:38:49 2016 From: david.holmes at oracle.com (David Holmes) Date: Sat, 7 May 2016 09:38:49 +1000 Subject: RFR: 8154715: Missing destructor and/or TLS clearing calls for terminating threads In-Reply-To: <572CBB30.1010801@oracle.com> References: <572C4198.3090900@oracle.com> <572CA452.70401@oracle.com> <19147ab9-2480-3ace-6eaf-611eccc29ebf@oracle.com> <572CBB30.1010801@oracle.com> Message-ID: <479dacb5-e8eb-cc21-4200-277bc5773293@oracle.com> On 7/05/2016 1:41 AM, Stefan Karlsson wrote: > On 06/05/16 16:32, David Holmes wrote: >> On 7/05/2016 12:04 AM, Stefan Karlsson wrote: >>> Hi David, >>> >>> On 06/05/16 15:38, David Holmes wrote: >>>> Hi Stefan, >>>> >>>> Thanks for taking a look at this. >>>> >>>> On 6/05/2016 5:02 PM, Stefan Karlsson wrote: >>>>> Hi David, >>>>> >>>>> I looked through the GC part of this webrev and I think the change is >>>>> fine. >>>>> >>>>> However, it seems a bit error prone. If we decide to change the >>>>> code to, >>>>> for example, terminate the AbstractGangWorker threads, then we >>>>> have to >>>>> remember to insert a ThreadLocalStorage::set_thread(NULL) call. >>>> >>>> That's why I added the ShouldNotReachHere()'s - if those threads start >>>> terminating then we will see those hit. Perhaps a comment: >>>> >>>> ShouldNotReachHere(); // If thread terminates we have to do TLS cleanup >>>> >>>> ? >>> >>> Yes, I would appreciate a comment. Though, when we add new threads, we >>> need to remember to add the set_thread(NULL) call. >> >> Well no, what you would do is manage your new threads in such a way >> that their run() method can do "delete this" as the last call. Only if >> you can't do that do you need to think about what termination logic is >> missing that needs to be done in lieu of the destructor. > > Yes, but this forces every implementer of a Thread:run() function to > have to think about these kind of requirements. Absolutely! Everyone who creates a thread should be thinking about its lifecycle. It is, in my opinion, the lack of such thinking that has gotten things in a mess. >> >>>> >>>>> Could we instead add a call to >>>>> ThreadLocalStorage::set_thread(NULL), or >>>>> maybe even Thread::clear_thread_current(), in java_start? >>>>> >>>>> static void *java_start(Thread *thread) { >>>>> [...] >>>>> thread->initialize_thread_current(); >>>>> >>>>> [...] >>>>> >>>>> // call one more level start routine >>>>> thread->run(); >>>>> >>>>> ////////// Could we call Thread::clear_thread_current(); here? >>>> >>>> Not easily. For JavaThreads we've already done "delete this" inside >>>> the run() method, so we'd have to move that into java_start as well, >>>> but we can only do the delete for JavaThreads not for other threads. >>>> And we'd also have to change the VMThread and WatcherThread >>>> termination logic because of the deletes that happen in the >>>> termination thread - the "this" pointer (thread above) may no longer >>>> be valid when we want to call clear_current_thread() - which is why we >>>> can only do the ThreadLocalStorage::set_thread(NULL). >>>> >>>> I agree it would be a lot cleaner to have java_start do: >>>> >>>> thread->common_initialization(); >>>> thread->run(); >>>> thread->common_cleanup(); >>>> delete thread; >>>> >>>> for all threads, but we'd need a lot of other changes to allow for >>>> that. Otherwise we would need to note that kind of thread before >>>> calling run() then switch on the thread type after run() to decide >>>> what kind of cleanup is necessary and possible. I don't think that >>>> would be better than just doing the "right" cleanup at the end of the >>>> run() methods. >>> >>> I understand that this is a bit messy, and I won't insist that we change >>> this in this RFR, but without looking at this in much detail it sounds >>> weird to delete the thread in run(). Couldn't this be solved by >>> introducing a virtual Thread::post_run() function and do: >>> >>> virtual void Thread::post_run() { >>> clear_thread_current(); >>> } >>> >>> virtual void JavaThread::post_run() { >>> Thread::post_run(); >>> delete this; >>> } >> >> But again this can't work for the VMThread or WatcherThread as they >> are deleted from the termination thread and so thread->post_run() may >> SEGV.** Plus it is only after the fact that you realize not to put >> "delete this" in Thread::post_run(). > > OK, I didn't understand what you meant with "termination thread", but I > now see the call to VMThread::destroy(). > > With that said, I find it odd that VMThread::destroy() deletes the VM > thread. We already handshake between the VMThread and the "termination > thread", so why isn't that VMThread::post_run() implemented as: > > virtual void VMThread::post_run() { > // signal other threads that VM process is gone > { > // Note: we must have the _no_safepoint_check_flag. Mutex::lock() > allows > // VM thread to enter any lock at Safepoint as long as its _owner is > NULL. > // If that happens after _terminate_lock->wait() has unset _owner > // but before it actually drops the lock and waits, the notification > below > // may get lost and we will have a hang. To avoid this, we need to use > // Mutex::lock_without_safepoint_check(). > MutexLockerEx ml(_terminate_lock, Mutex::_no_safepoint_check_flag); > _terminated = true; > _terminate_lock->notify(); > } > > Thread::post_run(); > delete this; > } > > And then we wouldn't get a SEGV ... Not on the "delete this", no - but you're missing whole aspect of the potential race between the execution of the Thread destructors and the tearing down of the VM that happens in the termination thread. In the past there was an issue with ResourceMark cleanup that used a stub that existed in the CodeCache which was deleted by the terminating thread as part of VM shutdown. That particular issue no longer exists but there could be other issues. We either have to establish and enforce that nothing on the destructor path can encounter an error due to something happening on the termination path, or we maintain the current conservatism and have the terminating thread synchronously destroy the other threads. As I said upfront I chose the latter as the former is somewhat error prone and fragile. > I couldn't find the destructor for the WatchThread, but it seems easy to > fix that as well. > > I'm probably missing something, but I find it a bit annoying that code > that should belong to the *Thread:ing system leaks into the > implementations of *Thread::run(). Wouldn't be an issue if the "threading system" had complete lifecycle management of all threads - but it doesn't. Eg GC threads are stashed into workgangs and other shared variables that can reference the thread objects after they have terminated. Alas this isn't Java code. :) Cheers, David > Thanks, > StefanK >> >> ** Arguably the best solution to the "thread termination races with VM >> termination" problem is to not let the threads terminate. The code as >> it exists today can still have JavaThreads destroying themselves at >> the same that the VM is terminating and potentially hit the same >> errors that require us to not allow the VMThread (and now >> WatcherThread) to delete themselves. >> >> Thanks, >> David >> >>> Thanks, >>> StefanK >>> >>>> >>>> Thanks, >>>> David >>>> ------ >>>> >>>>> >>>>> log_info(os, thread)("Thread finished (tid: " UINTX_FORMAT ", >>>>> pthread >>>>> id: " UINTX_FORMAT ").", >>>>> os::current_thread_id(), (uintx) pthread_self()); >>>>> >>>>> return 0; >>>>> } >>>>> >>>>> And get rid of the explicit calls to >>>>> ThreadLocalStorage::set_thread(NULL) you added? >>>>> >>>>> Thanks, >>>>> StefanK >>>>> >>>>> On 04/05/16 01:39, David Holmes wrote: >>>>>> This needs attention from GC and runtime folk please. >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8154715 >>>>>> webrev: http://cr.openjdk.java.net/~dholmes/8154715/webrev/ >>>>>> >>>>>> tl;dr: ensure ThreadLocalStorage::set_thread(NULL) is always called >>>>>> before a thread terminates. >>>>>> >>>>>> Background: >>>>>> >>>>>> Most system-related threads do not expect to explicitly terminate, >>>>>> except sometimes as part of VM termination. Such threads don't have >>>>>> their destructors called, but should. >>>>>> >>>>>> This omission came to light due to the ThreadLocalStorage changes in >>>>>> JDK-8132510. As part of that change we deleted the following from the >>>>>> termination path of the VMThread: >>>>>> >>>>>> // Thread destructor usually does this. >>>>>> ThreadLocalStorage::set_thread(NULL); >>>>>> >>>>>> The clearing of TLS seemed irrelevant to the VMThread as it primarily >>>>>> is used to aid in JNI attach/detach. However Brian Gardner reported: >>>>>> >>>>>> http://mail.openjdk.java.net/pipermail/bsd-port-dev/2016-February/002788.html >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> a problem on FreeBSD caused by this change and the interaction with >>>>>> the POSIX pthread TLS destructor use introduced by JDK-8033696. >>>>>> Because the VMThread terminated without clearing TLS, when the >>>>>> TLS-destructor was called it got into a loop which ran four times (as >>>>>> happens on Linux) and then prints a warning to the console (which >>>>>> doesn't happen on Linux). >>>>>> >>>>>> This indicates we need to restore the: >>>>>> >>>>>> ThreadLocalStorage::set_thread(NULL); >>>>>> >>>>>> but on further consideration it seems to me that this is not confined >>>>>> to the VMThread, and the most appropriate fix would be to always >>>>>> invoke the Thread destructor as a thread terminates. >>>>>> >>>>>> Solution: >>>>>> >>>>>> Further investigation shows that calling the Thread destructor in the >>>>>> thread as it terminates is not possible: >>>>>> >>>>>> - VMThread >>>>>> >>>>>> This is actually destroyed by the thread that terminates the VM, but >>>>>> that can happen after it terminates and so we still hit the TLS >>>>>> problem. The VMThread may be able to destroy itself today but in the >>>>>> past this was not possible (see existing code comment), and in the >>>>>> future it may also not be possible - the problem is that the Thread >>>>>> destructor can interact with other VM subsystems that are >>>>>> concurrently >>>>>> being torn down by the thread that is terminating the VM. In the past >>>>>> this was the CodeHeap. So rather than introduce something that is >>>>>> fragile we stick with the current scheme but restore the >>>>>> ThreadLocalStorage::set_thread(NULL); - note we can't access >>>>>> "this" at >>>>>> that time because it may already have been de-allocated. >>>>>> >>>>>> - WatcherThread >>>>>> >>>>>> The WatcherThread is never destroyed today but has the same >>>>>> problem as >>>>>> the VMThread. We can call the destructor from the VM termination >>>>>> thread (and have implemented that), but not from the WatcherThread >>>>>> itself. So again we just have to restore the >>>>>> ThreadLocalStorage::set_thread(NULL); to fix the potential TLS >>>>>> problem. >>>>>> >>>>>> - GC Threads >>>>>> >>>>>> There are two cases: >>>>>> >>>>>> a) GC threads that never terminate >>>>>> >>>>>> For these we don't need to do anything: we can't delete the thread as >>>>>> it never terminates and we don't hit the TLS problem because it never >>>>>> terminates. So all we will do here is add some logic to check (in >>>>>> NON_PRODUCT) that we do in fact never terminate. >>>>>> >>>>>> b) GC threads that can terminate >>>>>> >>>>>> Despite the fact the threads can terminate, references to those >>>>>> threads are stored elsewhere (WorkGangs and other places) and are not >>>>>> cleared as part of the termination process. Those references can be >>>>>> touched after the thread has terminated so we can not call the >>>>>> destructor at all. So again all we can do (without some major thread >>>>>> management reworking) is ensure that >>>>>> ThreadLocalStorage::set_thread(NULL); is called before the thread >>>>>> actually terminates >>>>>> >>>>>> Testing: JPRT >>>>>> RBT - runtime nightly tests >>>>>> >>>>>> Thanks, >>>>>> David >>>>> >>> > From david.holmes at oracle.com Fri May 6 23:42:15 2016 From: david.holmes at oracle.com (David Holmes) Date: Sat, 7 May 2016 09:42:15 +1000 Subject: RFR: 8154715: Missing destructor and/or TLS clearing calls for terminating threads In-Reply-To: References: Message-ID: <21661ab6-aa98-423f-2589-c81ef361321d@oracle.com> On 7/05/2016 5:36 AM, Brian Gardner wrote: > After applying your patches I still saw the cleanup messages from > pthread. After comparing my original patch to yours and doing some > testing it looks like we missed a couple spots. > > The warning went away after I applied the following patches: > http://brian.timestudybuddy.com/webrev/hotspot__clear_thread_current/webrev/hotspot/src/share/vm/gc/shared/concurrentGCThread.cpp.cdiff.html http://brian.timestudybuddy.com/webrev/hotspot__clear_thread_current/webrev/hotspot/src/share/vm/gc/cms/concurrentMarkSweepThread.cpp.cdiff.html My patch moves that from inside terminate() to outside of it: 78 void ConcurrentGCThread::run() { 79 initialize_in_thread(); 80 wait_for_universe_init(); 81 82 run_service(); 83 84 terminate(); 85 86 // Can't "delete this" before we terminate as other code 87 // holds references to 'this', but we must do some cleanup 88 // ourselves before allowing the native thread to terminate 89 90 ThreadLocalStorage::set_thread(NULL); 91 } so you should not be seeing any issue because of that. ??? David > Brian > >> On May 3, 2016, at 4:39 PM, David Holmes > > wrote: >> >> This needs attention from GC and runtime folk please. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8154715 >> webrev: http://cr.openjdk.java.net/~dholmes/8154715/webrev/ >> >> tl;dr: ensure ThreadLocalStorage::set_thread(NULL) is always called >> before a thread terminates. >> >> Background: >> >> Most system-related threads do not expect to explicitly terminate, >> except sometimes as part of VM termination. Such threads don't have >> their destructors called, but should. >> >> This omission came to light due to the ThreadLocalStorage changes in >> JDK-8132510. As part of that change we deleted the following from the >> termination path of the VMThread: >> >> // Thread destructor usually does this. >> ThreadLocalStorage::set_thread(NULL); >> >> The clearing of TLS seemed irrelevant to the VMThread as it primarily >> is used to aid in JNI attach/detach. However Brian Gardner reported: >> >> http://mail.openjdk.java.net/pipermail/bsd-port-dev/2016-February/002788.html >> >> a problem on FreeBSD caused by this change and the interaction with >> the POSIX pthread TLS destructor use introduced by JDK-8033696. >> Because the VMThread terminated without clearing TLS, when the >> TLS-destructor was called it got into a loop which ran four times (as >> happens on Linux) and then prints a warning to the console (which >> doesn't happen on Linux). >> >> This indicates we need to restore the: >> >> ThreadLocalStorage::set_thread(NULL); >> >> but on further consideration it seems to me that this is not confined >> to the VMThread, and the most appropriate fix would be to always >> invoke the Thread destructor as a thread terminates. >> >> Solution: >> >> Further investigation shows that calling the Thread destructor in the >> thread as it terminates is not possible: >> >> - VMThread >> >> This is actually destroyed by the thread that terminates the VM, but >> that can happen after it terminates and so we still hit the TLS >> problem. The VMThread may be able to destroy itself today but in the >> past this was not possible (see existing code comment), and in the >> future it may also not be possible - the problem is that the Thread >> destructor can interact with other VM subsystems that are concurrently >> being torn down by the thread that is terminating the VM. In the past >> this was the CodeHeap. So rather than introduce something that is >> fragile we stick with the current scheme but restore the >> ThreadLocalStorage::set_thread(NULL); - note we can't access "this" at >> that time because it may already have been de-allocated. >> >> - WatcherThread >> >> The WatcherThread is never destroyed today but has the same problem as >> the VMThread. We can call the destructor from the VM termination >> thread (and have implemented that), but not from the WatcherThread >> itself. So again we just have to restore the >> ThreadLocalStorage::set_thread(NULL); to fix the potential TLS problem. >> >> - GC Threads >> >> There are two cases: >> >> a) GC threads that never terminate >> >> For these we don't need to do anything: we can't delete the thread as >> it never terminates and we don't hit the TLS problem because it never >> terminates. So all we will do here is add some logic to check (in >> NON_PRODUCT) that we do in fact never terminate. >> >> b) GC threads that can terminate >> >> Despite the fact the threads can terminate, references to those >> threads are stored elsewhere (WorkGangs and other places) and are not >> cleared as part of the termination process. Those references can be >> touched after the thread has terminated so we can not call the >> destructor at all. So again all we can do (without some major thread >> management reworking) is ensure that >> ThreadLocalStorage::set_thread(NULL); is called before the thread >> actually terminates >> >> Testing: JPRT >> RBT - runtime nightly tests >> >> Thanks, >> David >> > From david.holmes at oracle.com Fri May 6 23:50:28 2016 From: david.holmes at oracle.com (David Holmes) Date: Sat, 7 May 2016 09:50:28 +1000 Subject: RFR: 8154715: Missing destructor and/or TLS clearing calls for terminating threads In-Reply-To: References: <572C4198.3090900@oracle.com> <572CA452.70401@oracle.com> <19147ab9-2480-3ace-6eaf-611eccc29ebf@oracle.com> <572CBB30.1010801@oracle.com> Message-ID: <3fb637e4-0dbe-31d6-2202-574ad3256a95@oracle.com> On 7/05/2016 5:40 AM, Brian Gardner wrote: > I agree with Stefan. When I initially ran into the problem I came up > with the following changeset that solves my problem, by calling > clear_thread_current at the end of java_start. > > http://brian.timestudybuddy.com/webrev/hotspot__clear_thread_current_alt/webrev/ As I said I can see the appeal in doing this, but there is still a race for the threads destroyed at VM shutdown as current_or_null() can return non-NULL but the delete can happen before we call thread->clear_current_thread(). You would also want Thread::current_or_null_safe() I think, due to already deleted JavaThreads. And this all side-steps the real issue in my opinion that with clean thread lifecycle management we should always be able to delete the terminating thread. So to me it is a question of selecting which set of bandaids you want to apply. Thanks, David > Brian > >> On May 6, 2016, at 8:41 AM, Stefan Karlsson >> > wrote: >> >> On 06/05/16 16:32, David Holmes wrote: >>> On 7/05/2016 12:04 AM, Stefan Karlsson wrote: >>>> Hi David, >>>> >>>> On 06/05/16 15:38, David Holmes wrote: >>>>> Hi Stefan, >>>>> >>>>> Thanks for taking a look at this. >>>>> >>>>> On 6/05/2016 5:02 PM, Stefan Karlsson wrote: >>>>>> Hi David, >>>>>> >>>>>> I looked through the GC part of this webrev and I think the change is >>>>>> fine. >>>>>> >>>>>> However, it seems a bit error prone. If we decide to change the >>>>>> code to, >>>>>> for example, terminate the AbstractGangWorker threads, then we >>>>>> have to >>>>>> remember to insert a ThreadLocalStorage::set_thread(NULL) call. >>>>> >>>>> That's why I added the ShouldNotReachHere()'s - if those threads start >>>>> terminating then we will see those hit. Perhaps a comment: >>>>> >>>>> ShouldNotReachHere(); // If thread terminates we have to do TLS cleanup >>>>> >>>>> ? >>>> >>>> Yes, I would appreciate a comment. Though, when we add new threads, we >>>> need to remember to add the set_thread(NULL) call. >>> >>> Well no, what you would do is manage your new threads in such a way >>> that their run() method can do "delete this" as the last call. Only >>> if you can't do that do you need to think about what termination >>> logic is missing that needs to be done in lieu of the destructor. >> >> Yes, but this forces every implementer of a Thread:run() function to >> have to think about these kind of requirements. >> >>> >>>>> >>>>>> Could we instead add a call to >>>>>> ThreadLocalStorage::set_thread(NULL), or >>>>>> maybe even Thread::clear_thread_current(), in java_start? >>>>>> >>>>>> static void *java_start(Thread *thread) { >>>>>> [...] >>>>>> thread->initialize_thread_current(); >>>>>> >>>>>> [...] >>>>>> >>>>>> // call one more level start routine >>>>>> thread->run(); >>>>>> >>>>>> ////////// Could we call Thread::clear_thread_current(); here? >>>>> >>>>> Not easily. For JavaThreads we've already done "delete this" inside >>>>> the run() method, so we'd have to move that into java_start as well, >>>>> but we can only do the delete for JavaThreads not for other threads. >>>>> And we'd also have to change the VMThread and WatcherThread >>>>> termination logic because of the deletes that happen in the >>>>> termination thread - the "this" pointer (thread above) may no longer >>>>> be valid when we want to call clear_current_thread() - which is why we >>>>> can only do the ThreadLocalStorage::set_thread(NULL). >>>>> >>>>> I agree it would be a lot cleaner to have java_start do: >>>>> >>>>> thread->common_initialization(); >>>>> thread->run(); >>>>> thread->common_cleanup(); >>>>> delete thread; >>>>> >>>>> for all threads, but we'd need a lot of other changes to allow for >>>>> that. Otherwise we would need to note that kind of thread before >>>>> calling run() then switch on the thread type after run() to decide >>>>> what kind of cleanup is necessary and possible. I don't think that >>>>> would be better than just doing the "right" cleanup at the end of the >>>>> run() methods. >>>> >>>> I understand that this is a bit messy, and I won't insist that we change >>>> this in this RFR, but without looking at this in much detail it sounds >>>> weird to delete the thread in run(). Couldn't this be solved by >>>> introducing a virtual Thread::post_run() function and do: >>>> >>>> virtual void Thread::post_run() { >>>> clear_thread_current(); >>>> } >>>> >>>> virtual void JavaThread::post_run() { >>>> Thread::post_run(); >>>> delete this; >>>> } >>> >>> But again this can't work for the VMThread or WatcherThread as they >>> are deleted from the termination thread and so thread->post_run() may >>> SEGV.** Plus it is only after the fact that you realize not to put >>> "delete this" in Thread::post_run(). >> >> OK, I didn't understand what you meant with "termination thread", but >> I now see the call to VMThread::destroy(). >> >> With that said, I find it odd that VMThread::destroy() deletes the VM >> thread. We already handshake between the VMThread and the "termination >> thread", so why isn't that VMThread::post_run() implemented as: >> >> virtual void VMThread::post_run() { >> // signal other threads that VM process is gone >> { >> // Note: we must have the _no_safepoint_check_flag. Mutex::lock() >> allows >> // VM thread to enter any lock at Safepoint as long as its _owner >> is NULL. >> // If that happens after _terminate_lock->wait() has unset _owner >> // but before it actually drops the lock and waits, the >> notification below >> // may get lost and we will have a hang. To avoid this, we need to use >> // Mutex::lock_without_safepoint_check(). >> MutexLockerEx ml(_terminate_lock, Mutex::_no_safepoint_check_flag); >> _terminated = true; >> _terminate_lock->notify(); >> } >> >> Thread::post_run(); >> delete this; >> } >> >> And then we wouldn't get a SEGV ... >> >> I couldn't find the destructor for the WatchThread, but it seems easy >> to fix that as well. >> >> I'm probably missing something, but I find it a bit annoying that code >> that should belong to the *Thread:ing system leaks into the >> implementations of *Thread::run(). >> >> Thanks, >> StefanK >>> >>> ** Arguably the best solution to the "thread termination races with >>> VM termination" problem is to not let the threads terminate. The code >>> as it exists today can still have JavaThreads destroying themselves >>> at the same that the VM is terminating and potentially hit the same >>> errors that require us to not allow the VMThread (and now >>> WatcherThread) to delete themselves. >>> >>> Thanks, >>> David >>> >>>> Thanks, >>>> StefanK >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> ------ >>>>> >>>>>> >>>>>> log_info(os, thread)("Thread finished (tid: " UINTX_FORMAT ", pthread >>>>>> id: " UINTX_FORMAT ").", >>>>>> os::current_thread_id(), (uintx) pthread_self()); >>>>>> >>>>>> return 0; >>>>>> } >>>>>> >>>>>> And get rid of the explicit calls to >>>>>> ThreadLocalStorage::set_thread(NULL) you added? >>>>>> >>>>>> Thanks, >>>>>> StefanK >>>>>> >>>>>> On 04/05/16 01:39, David Holmes wrote: >>>>>>> This needs attention from GC and runtime folk please. >>>>>>> >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8154715 >>>>>>> webrev: http://cr.openjdk.java.net/~dholmes/8154715/webrev/ >>>>>>> >>>>>>> tl;dr: ensure ThreadLocalStorage::set_thread(NULL) is always called >>>>>>> before a thread terminates. >>>>>>> >>>>>>> Background: >>>>>>> >>>>>>> Most system-related threads do not expect to explicitly terminate, >>>>>>> except sometimes as part of VM termination. Such threads don't have >>>>>>> their destructors called, but should. >>>>>>> >>>>>>> This omission came to light due to the ThreadLocalStorage changes in >>>>>>> JDK-8132510. As part of that change we deleted the following from the >>>>>>> termination path of the VMThread: >>>>>>> >>>>>>> // Thread destructor usually does this. >>>>>>> ThreadLocalStorage::set_thread(NULL); >>>>>>> >>>>>>> The clearing of TLS seemed irrelevant to the VMThread as it primarily >>>>>>> is used to aid in JNI attach/detach. However Brian Gardner reported: >>>>>>> >>>>>>> http://mail.openjdk.java.net/pipermail/bsd-port-dev/2016-February/002788.html >>>>>>> >>>>>>> >>>>>>> >>>>>>> a problem on FreeBSD caused by this change and the interaction with >>>>>>> the POSIX pthread TLS destructor use introduced by JDK-8033696. >>>>>>> Because the VMThread terminated without clearing TLS, when the >>>>>>> TLS-destructor was called it got into a loop which ran four times (as >>>>>>> happens on Linux) and then prints a warning to the console (which >>>>>>> doesn't happen on Linux). >>>>>>> >>>>>>> This indicates we need to restore the: >>>>>>> >>>>>>> ThreadLocalStorage::set_thread(NULL); >>>>>>> >>>>>>> but on further consideration it seems to me that this is not confined >>>>>>> to the VMThread, and the most appropriate fix would be to always >>>>>>> invoke the Thread destructor as a thread terminates. >>>>>>> >>>>>>> Solution: >>>>>>> >>>>>>> Further investigation shows that calling the Thread destructor in the >>>>>>> thread as it terminates is not possible: >>>>>>> >>>>>>> - VMThread >>>>>>> >>>>>>> This is actually destroyed by the thread that terminates the VM, but >>>>>>> that can happen after it terminates and so we still hit the TLS >>>>>>> problem. The VMThread may be able to destroy itself today but in the >>>>>>> past this was not possible (see existing code comment), and in the >>>>>>> future it may also not be possible - the problem is that the Thread >>>>>>> destructor can interact with other VM subsystems that are >>>>>>> concurrently >>>>>>> being torn down by the thread that is terminating the VM. In the past >>>>>>> this was the CodeHeap. So rather than introduce something that is >>>>>>> fragile we stick with the current scheme but restore the >>>>>>> ThreadLocalStorage::set_thread(NULL); - note we can't access >>>>>>> "this" at >>>>>>> that time because it may already have been de-allocated. >>>>>>> >>>>>>> - WatcherThread >>>>>>> >>>>>>> The WatcherThread is never destroyed today but has the same >>>>>>> problem as >>>>>>> the VMThread. We can call the destructor from the VM termination >>>>>>> thread (and have implemented that), but not from the WatcherThread >>>>>>> itself. So again we just have to restore the >>>>>>> ThreadLocalStorage::set_thread(NULL); to fix the potential TLS >>>>>>> problem. >>>>>>> >>>>>>> - GC Threads >>>>>>> >>>>>>> There are two cases: >>>>>>> >>>>>>> a) GC threads that never terminate >>>>>>> >>>>>>> For these we don't need to do anything: we can't delete the thread as >>>>>>> it never terminates and we don't hit the TLS problem because it never >>>>>>> terminates. So all we will do here is add some logic to check (in >>>>>>> NON_PRODUCT) that we do in fact never terminate. >>>>>>> >>>>>>> b) GC threads that can terminate >>>>>>> >>>>>>> Despite the fact the threads can terminate, references to those >>>>>>> threads are stored elsewhere (WorkGangs and other places) and are not >>>>>>> cleared as part of the termination process. Those references can be >>>>>>> touched after the thread has terminated so we can not call the >>>>>>> destructor at all. So again all we can do (without some major thread >>>>>>> management reworking) is ensure that >>>>>>> ThreadLocalStorage::set_thread(NULL); is called before the thread >>>>>>> actually terminates >>>>>>> >>>>>>> Testing: JPRT >>>>>>> RBT - runtime nightly tests >>>>>>> >>>>>>> Thanks, >>>>>>> David > From david.holmes at oracle.com Sat May 7 05:45:24 2016 From: david.holmes at oracle.com (David Holmes) Date: Sat, 7 May 2016 15:45:24 +1000 Subject: RFR: 8154715: Missing destructor and/or TLS clearing calls for terminating threads In-Reply-To: <3fb637e4-0dbe-31d6-2202-574ad3256a95@oracle.com> References: <572C4198.3090900@oracle.com> <572CA452.70401@oracle.com> <19147ab9-2480-3ace-6eaf-611eccc29ebf@oracle.com> <572CBB30.1010801@oracle.com> <3fb637e4-0dbe-31d6-2202-574ad3256a95@oracle.com> Message-ID: <55edc3b5-bd68-0e06-8003-bb9bf8093851@oracle.com> Brian, Stefan, I've been giving this more thought and I think you are both right. While this can't be completely handled in java_start for all threads it can handle the most common cases. If I don't add the deletion of the WatcherThread then the problematic case reduces to that of the VMThread. I'll do a new version on Monday. I also need to double-check those threads that don't use java_start (which I am sorely tempted to rename). Thanks, David On 7/05/2016 9:50 AM, David Holmes wrote: > On 7/05/2016 5:40 AM, Brian Gardner wrote: >> I agree with Stefan. When I initially ran into the problem I came up >> with the following changeset that solves my problem, by calling >> clear_thread_current at the end of java_start. >> >> http://brian.timestudybuddy.com/webrev/hotspot__clear_thread_current_alt/webrev/ >> > > As I said I can see the appeal in doing this, but there is still a race > for the threads destroyed at VM shutdown as current_or_null() can return > non-NULL but the delete can happen before we call > thread->clear_current_thread(). > > You would also want Thread::current_or_null_safe() I think, due to > already deleted JavaThreads. > > And this all side-steps the real issue in my opinion that with clean > thread lifecycle management we should always be able to delete the > terminating thread. > > So to me it is a question of selecting which set of bandaids you want to > apply. > > Thanks, > David > >> Brian >> >>> On May 6, 2016, at 8:41 AM, Stefan Karlsson >>> > wrote: >>> >>> On 06/05/16 16:32, David Holmes wrote: >>>> On 7/05/2016 12:04 AM, Stefan Karlsson wrote: >>>>> Hi David, >>>>> >>>>> On 06/05/16 15:38, David Holmes wrote: >>>>>> Hi Stefan, >>>>>> >>>>>> Thanks for taking a look at this. >>>>>> >>>>>> On 6/05/2016 5:02 PM, Stefan Karlsson wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> I looked through the GC part of this webrev and I think the >>>>>>> change is >>>>>>> fine. >>>>>>> >>>>>>> However, it seems a bit error prone. If we decide to change the >>>>>>> code to, >>>>>>> for example, terminate the AbstractGangWorker threads, then we >>>>>>> have to >>>>>>> remember to insert a ThreadLocalStorage::set_thread(NULL) call. >>>>>> >>>>>> That's why I added the ShouldNotReachHere()'s - if those threads >>>>>> start >>>>>> terminating then we will see those hit. Perhaps a comment: >>>>>> >>>>>> ShouldNotReachHere(); // If thread terminates we have to do TLS >>>>>> cleanup >>>>>> >>>>>> ? >>>>> >>>>> Yes, I would appreciate a comment. Though, when we add new threads, we >>>>> need to remember to add the set_thread(NULL) call. >>>> >>>> Well no, what you would do is manage your new threads in such a way >>>> that their run() method can do "delete this" as the last call. Only >>>> if you can't do that do you need to think about what termination >>>> logic is missing that needs to be done in lieu of the destructor. >>> >>> Yes, but this forces every implementer of a Thread:run() function to >>> have to think about these kind of requirements. >>> >>>> >>>>>> >>>>>>> Could we instead add a call to >>>>>>> ThreadLocalStorage::set_thread(NULL), or >>>>>>> maybe even Thread::clear_thread_current(), in java_start? >>>>>>> >>>>>>> static void *java_start(Thread *thread) { >>>>>>> [...] >>>>>>> thread->initialize_thread_current(); >>>>>>> >>>>>>> [...] >>>>>>> >>>>>>> // call one more level start routine >>>>>>> thread->run(); >>>>>>> >>>>>>> ////////// Could we call Thread::clear_thread_current(); here? >>>>>> >>>>>> Not easily. For JavaThreads we've already done "delete this" inside >>>>>> the run() method, so we'd have to move that into java_start as well, >>>>>> but we can only do the delete for JavaThreads not for other threads. >>>>>> And we'd also have to change the VMThread and WatcherThread >>>>>> termination logic because of the deletes that happen in the >>>>>> termination thread - the "this" pointer (thread above) may no longer >>>>>> be valid when we want to call clear_current_thread() - which is >>>>>> why we >>>>>> can only do the ThreadLocalStorage::set_thread(NULL). >>>>>> >>>>>> I agree it would be a lot cleaner to have java_start do: >>>>>> >>>>>> thread->common_initialization(); >>>>>> thread->run(); >>>>>> thread->common_cleanup(); >>>>>> delete thread; >>>>>> >>>>>> for all threads, but we'd need a lot of other changes to allow for >>>>>> that. Otherwise we would need to note that kind of thread before >>>>>> calling run() then switch on the thread type after run() to decide >>>>>> what kind of cleanup is necessary and possible. I don't think that >>>>>> would be better than just doing the "right" cleanup at the end of the >>>>>> run() methods. >>>>> >>>>> I understand that this is a bit messy, and I won't insist that we >>>>> change >>>>> this in this RFR, but without looking at this in much detail it sounds >>>>> weird to delete the thread in run(). Couldn't this be solved by >>>>> introducing a virtual Thread::post_run() function and do: >>>>> >>>>> virtual void Thread::post_run() { >>>>> clear_thread_current(); >>>>> } >>>>> >>>>> virtual void JavaThread::post_run() { >>>>> Thread::post_run(); >>>>> delete this; >>>>> } >>>> >>>> But again this can't work for the VMThread or WatcherThread as they >>>> are deleted from the termination thread and so thread->post_run() may >>>> SEGV.** Plus it is only after the fact that you realize not to put >>>> "delete this" in Thread::post_run(). >>> >>> OK, I didn't understand what you meant with "termination thread", but >>> I now see the call to VMThread::destroy(). >>> >>> With that said, I find it odd that VMThread::destroy() deletes the VM >>> thread. We already handshake between the VMThread and the "termination >>> thread", so why isn't that VMThread::post_run() implemented as: >>> >>> virtual void VMThread::post_run() { >>> // signal other threads that VM process is gone >>> { >>> // Note: we must have the _no_safepoint_check_flag. Mutex::lock() >>> allows >>> // VM thread to enter any lock at Safepoint as long as its _owner >>> is NULL. >>> // If that happens after _terminate_lock->wait() has unset _owner >>> // but before it actually drops the lock and waits, the >>> notification below >>> // may get lost and we will have a hang. To avoid this, we need to >>> use >>> // Mutex::lock_without_safepoint_check(). >>> MutexLockerEx ml(_terminate_lock, Mutex::_no_safepoint_check_flag); >>> _terminated = true; >>> _terminate_lock->notify(); >>> } >>> >>> Thread::post_run(); >>> delete this; >>> } >>> >>> And then we wouldn't get a SEGV ... >>> >>> I couldn't find the destructor for the WatchThread, but it seems easy >>> to fix that as well. >>> >>> I'm probably missing something, but I find it a bit annoying that code >>> that should belong to the *Thread:ing system leaks into the >>> implementations of *Thread::run(). >>> >>> Thanks, >>> StefanK >>>> >>>> ** Arguably the best solution to the "thread termination races with >>>> VM termination" problem is to not let the threads terminate. The code >>>> as it exists today can still have JavaThreads destroying themselves >>>> at the same that the VM is terminating and potentially hit the same >>>> errors that require us to not allow the VMThread (and now >>>> WatcherThread) to delete themselves. >>>> >>>> Thanks, >>>> David >>>> >>>>> Thanks, >>>>> StefanK >>>>> >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> ------ >>>>>> >>>>>>> >>>>>>> log_info(os, thread)("Thread finished (tid: " UINTX_FORMAT ", >>>>>>> pthread >>>>>>> id: " UINTX_FORMAT ").", >>>>>>> os::current_thread_id(), (uintx) pthread_self()); >>>>>>> >>>>>>> return 0; >>>>>>> } >>>>>>> >>>>>>> And get rid of the explicit calls to >>>>>>> ThreadLocalStorage::set_thread(NULL) you added? >>>>>>> >>>>>>> Thanks, >>>>>>> StefanK >>>>>>> >>>>>>> On 04/05/16 01:39, David Holmes wrote: >>>>>>>> This needs attention from GC and runtime folk please. >>>>>>>> >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8154715 >>>>>>>> webrev: http://cr.openjdk.java.net/~dholmes/8154715/webrev/ >>>>>>>> >>>>>>>> tl;dr: ensure ThreadLocalStorage::set_thread(NULL) is always called >>>>>>>> before a thread terminates. >>>>>>>> >>>>>>>> Background: >>>>>>>> >>>>>>>> Most system-related threads do not expect to explicitly terminate, >>>>>>>> except sometimes as part of VM termination. Such threads don't have >>>>>>>> their destructors called, but should. >>>>>>>> >>>>>>>> This omission came to light due to the ThreadLocalStorage >>>>>>>> changes in >>>>>>>> JDK-8132510. As part of that change we deleted the following >>>>>>>> from the >>>>>>>> termination path of the VMThread: >>>>>>>> >>>>>>>> // Thread destructor usually does this. >>>>>>>> ThreadLocalStorage::set_thread(NULL); >>>>>>>> >>>>>>>> The clearing of TLS seemed irrelevant to the VMThread as it >>>>>>>> primarily >>>>>>>> is used to aid in JNI attach/detach. However Brian Gardner >>>>>>>> reported: >>>>>>>> >>>>>>>> http://mail.openjdk.java.net/pipermail/bsd-port-dev/2016-February/002788.html >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> a problem on FreeBSD caused by this change and the interaction with >>>>>>>> the POSIX pthread TLS destructor use introduced by JDK-8033696. >>>>>>>> Because the VMThread terminated without clearing TLS, when the >>>>>>>> TLS-destructor was called it got into a loop which ran four >>>>>>>> times (as >>>>>>>> happens on Linux) and then prints a warning to the console (which >>>>>>>> doesn't happen on Linux). >>>>>>>> >>>>>>>> This indicates we need to restore the: >>>>>>>> >>>>>>>> ThreadLocalStorage::set_thread(NULL); >>>>>>>> >>>>>>>> but on further consideration it seems to me that this is not >>>>>>>> confined >>>>>>>> to the VMThread, and the most appropriate fix would be to always >>>>>>>> invoke the Thread destructor as a thread terminates. >>>>>>>> >>>>>>>> Solution: >>>>>>>> >>>>>>>> Further investigation shows that calling the Thread destructor >>>>>>>> in the >>>>>>>> thread as it terminates is not possible: >>>>>>>> >>>>>>>> - VMThread >>>>>>>> >>>>>>>> This is actually destroyed by the thread that terminates the VM, >>>>>>>> but >>>>>>>> that can happen after it terminates and so we still hit the TLS >>>>>>>> problem. The VMThread may be able to destroy itself today but in >>>>>>>> the >>>>>>>> past this was not possible (see existing code comment), and in the >>>>>>>> future it may also not be possible - the problem is that the Thread >>>>>>>> destructor can interact with other VM subsystems that are >>>>>>>> concurrently >>>>>>>> being torn down by the thread that is terminating the VM. In the >>>>>>>> past >>>>>>>> this was the CodeHeap. So rather than introduce something that is >>>>>>>> fragile we stick with the current scheme but restore the >>>>>>>> ThreadLocalStorage::set_thread(NULL); - note we can't access >>>>>>>> "this" at >>>>>>>> that time because it may already have been de-allocated. >>>>>>>> >>>>>>>> - WatcherThread >>>>>>>> >>>>>>>> The WatcherThread is never destroyed today but has the same >>>>>>>> problem as >>>>>>>> the VMThread. We can call the destructor from the VM termination >>>>>>>> thread (and have implemented that), but not from the WatcherThread >>>>>>>> itself. So again we just have to restore the >>>>>>>> ThreadLocalStorage::set_thread(NULL); to fix the potential TLS >>>>>>>> problem. >>>>>>>> >>>>>>>> - GC Threads >>>>>>>> >>>>>>>> There are two cases: >>>>>>>> >>>>>>>> a) GC threads that never terminate >>>>>>>> >>>>>>>> For these we don't need to do anything: we can't delete the >>>>>>>> thread as >>>>>>>> it never terminates and we don't hit the TLS problem because it >>>>>>>> never >>>>>>>> terminates. So all we will do here is add some logic to check (in >>>>>>>> NON_PRODUCT) that we do in fact never terminate. >>>>>>>> >>>>>>>> b) GC threads that can terminate >>>>>>>> >>>>>>>> Despite the fact the threads can terminate, references to those >>>>>>>> threads are stored elsewhere (WorkGangs and other places) and >>>>>>>> are not >>>>>>>> cleared as part of the termination process. Those references can be >>>>>>>> touched after the thread has terminated so we can not call the >>>>>>>> destructor at all. So again all we can do (without some major >>>>>>>> thread >>>>>>>> management reworking) is ensure that >>>>>>>> ThreadLocalStorage::set_thread(NULL); is called before the thread >>>>>>>> actually terminates >>>>>>>> >>>>>>>> Testing: JPRT >>>>>>>> RBT - runtime nightly tests >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >> From marcus.larsson at oracle.com Mon May 9 07:36:11 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Mon, 9 May 2016 09:36:11 +0200 Subject: RFR: 8146948: Add help information to log tags In-Reply-To: References: <570F9F97.4060808@oracle.com> Message-ID: <313004cb-cc55-030f-61ac-abc05b56cc68@oracle.com> Hi Kim, On 05/04/2016 08:30 PM, Kim Barrett wrote: >> On Apr 14, 2016, at 9:48 AM, Marcus Larsson wrote: >> >> Hi, >> >> Please review the following patch to add descriptions to logging tagsets. >> >> Summary: >> Tagsets may now be given a description in logTagSetDescriptions.inline.hpp. All described tagsets are listed in the -Xlog:help output as well as in the LogConfiguration::describe output. The patch also adds trace level logging that lists *all* tagsets in the VM (-Xlog:logging=trace). The previous 'logging=trace logging' has been moved to 'logging=debug'. >> >> Example log output: >> >> ... >> [0.544s][debug][logging] Described tag combinations: >> [0.544s][debug][logging] logging: Logging for the log framework itself >> ... >> [0.544s][trace][logging] All available tag sets: arguments, biasedlocking, classinit, classload, classload+constraints, classload+preorder, classloaderdata, classpath, classresolve, classunload, constraints, defaultmethods, ergo, exceptions, gc, gc+age, gc+alloc, gc+alloc+region, gc+barrier, gc+bot, gc+classhisto, gc+classhisto+start, gc+compaction, gc+cpu, gc+ergo, gc+ergo+cset, gc+ergo+heap, gc+ergo+ihop, gc+ergo+refine, gc+freelist, gc+freelist+census, gc+freelist+stats, gc+heap, gc+heap+coops, gc+heap+exit, gc+heap+region, gc+humongous, gc+ihop, gc+jni, gc+liveness, gc+marking, gc+marking+start, gc+metaspace, gc+metaspace+alloc, gc+metaspace+freelist, gc+phases, gc+phases+start, gc+phases+task, gc+phases+verify, gc+phases+verify+start, gc+plab, gc+promotion, gc+ref, gc+ref+start, gc+refine, gc+region, gc+remset, gc+remset+exit, gc+remset+scrub, gc+scavenge, gc+start, gc+state, gc+stats, gc+stringdedup, gc+stringtable, gc+survivor, gc+sweep, gc+task, gc+task+stats, gc+task+thread, gc+task+time, gc+tlab, gc+verify, gc+verify+start, gc+workgang, heap+ergo, itables, jfr, jfr+instrumentation, jfr+types, logging, logging+test, modules, monitorinflation, monitormismatch, os, os+cpu, os+thread, pagesize, protectiondomain, ref, safepoint, safepointcleanup, stacktrace, startuptime, verification, vmoperation, vtables >> >> >> Webrev: >> http://cr.openjdk.java.net/~mlarsson/8146948/webrev.00/ >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8146948 >> >> Testing: >> Internal VM tests through RBT >> >> Thanks, >> Marcus > ------------------------------------------------------------------------------ > src/share/vm/logging/logTagSetDescriptions.inline.hpp > 39 static struct LogTagSetDescription { > 40 const LogTagSet* tagset; > 41 const char* descr; > 42 } tagset_descriptions[] = { > 43 LOG_TAG_SET_DESCRIPTION_LIST > 44 { NULL, NULL } > 45 }; > > Won't this place a copy of the descriptions in each translation unit > that includes this file, each in it's own file-scoped > tagset_descriptions variable? I think better would be a class > definition with a static const array member in the header, with the > member definition (including the associated macrology) in a .cpp file. The intention is that this file should only be included from logTagSet.cpp and therefore not cause any copying of the descriptions. The first approach was just to have them in logTagSet.cpp but I wanted an easy to find place for where to add/edit descriptions so I opted for a separate file. I didn't want to make a whole hpp/cpp pair for it, but if you still think that would be better I can do it; let me know. Thanks, Marcus From stefan.karlsson at oracle.com Mon May 9 09:29:58 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 9 May 2016 11:29:58 +0200 Subject: RFR: 8154715: Missing destructor and/or TLS clearing calls for terminating threads In-Reply-To: <55edc3b5-bd68-0e06-8003-bb9bf8093851@oracle.com> References: <572C4198.3090900@oracle.com> <572CA452.70401@oracle.com> <19147ab9-2480-3ace-6eaf-611eccc29ebf@oracle.com> <572CBB30.1010801@oracle.com> <3fb637e4-0dbe-31d6-2202-574ad3256a95@oracle.com> <55edc3b5-bd68-0e06-8003-bb9bf8093851@oracle.com> Message-ID: <57305896.8020306@oracle.com> Hi, For java_start, would it be enough to just, unconditionally, call ThreadLocalStorage::set_thread(NULL) after thread->run() ? StefanK On 2016-05-07 07:45, David Holmes wrote: > Brian, Stefan, > > I've been giving this more thought and I think you are both right. > While this can't be completely handled in java_start for all threads > it can handle the most common cases. If I don't add the deletion of > the WatcherThread then the problematic case reduces to that of the > VMThread. > > I'll do a new version on Monday. I also need to double-check those > threads that don't use java_start (which I am sorely tempted to rename). > > Thanks, > David > > On 7/05/2016 9:50 AM, David Holmes wrote: >> On 7/05/2016 5:40 AM, Brian Gardner wrote: >>> I agree with Stefan. When I initially ran into the problem I came up >>> with the following changeset that solves my problem, by calling >>> clear_thread_current at the end of java_start. >>> >>> http://brian.timestudybuddy.com/webrev/hotspot__clear_thread_current_alt/webrev/ >>> >>> >> >> As I said I can see the appeal in doing this, but there is still a race >> for the threads destroyed at VM shutdown as current_or_null() can return >> non-NULL but the delete can happen before we call >> thread->clear_current_thread(). >> >> You would also want Thread::current_or_null_safe() I think, due to >> already deleted JavaThreads. >> >> And this all side-steps the real issue in my opinion that with clean >> thread lifecycle management we should always be able to delete the >> terminating thread. >> >> So to me it is a question of selecting which set of bandaids you want to >> apply. >> >> Thanks, >> David >> >>> Brian >>> >>>> On May 6, 2016, at 8:41 AM, Stefan Karlsson >>>> > >>>> wrote: >>>> >>>> On 06/05/16 16:32, David Holmes wrote: >>>>> On 7/05/2016 12:04 AM, Stefan Karlsson wrote: >>>>>> Hi David, >>>>>> >>>>>> On 06/05/16 15:38, David Holmes wrote: >>>>>>> Hi Stefan, >>>>>>> >>>>>>> Thanks for taking a look at this. >>>>>>> >>>>>>> On 6/05/2016 5:02 PM, Stefan Karlsson wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>> I looked through the GC part of this webrev and I think the >>>>>>>> change is >>>>>>>> fine. >>>>>>>> >>>>>>>> However, it seems a bit error prone. If we decide to change the >>>>>>>> code to, >>>>>>>> for example, terminate the AbstractGangWorker threads, then we >>>>>>>> have to >>>>>>>> remember to insert a ThreadLocalStorage::set_thread(NULL) call. >>>>>>> >>>>>>> That's why I added the ShouldNotReachHere()'s - if those threads >>>>>>> start >>>>>>> terminating then we will see those hit. Perhaps a comment: >>>>>>> >>>>>>> ShouldNotReachHere(); // If thread terminates we have to do TLS >>>>>>> cleanup >>>>>>> >>>>>>> ? >>>>>> >>>>>> Yes, I would appreciate a comment. Though, when we add new >>>>>> threads, we >>>>>> need to remember to add the set_thread(NULL) call. >>>>> >>>>> Well no, what you would do is manage your new threads in such a way >>>>> that their run() method can do "delete this" as the last call. Only >>>>> if you can't do that do you need to think about what termination >>>>> logic is missing that needs to be done in lieu of the destructor. >>>> >>>> Yes, but this forces every implementer of a Thread:run() function to >>>> have to think about these kind of requirements. >>>> >>>>> >>>>>>> >>>>>>>> Could we instead add a call to >>>>>>>> ThreadLocalStorage::set_thread(NULL), or >>>>>>>> maybe even Thread::clear_thread_current(), in java_start? >>>>>>>> >>>>>>>> static void *java_start(Thread *thread) { >>>>>>>> [...] >>>>>>>> thread->initialize_thread_current(); >>>>>>>> >>>>>>>> [...] >>>>>>>> >>>>>>>> // call one more level start routine >>>>>>>> thread->run(); >>>>>>>> >>>>>>>> ////////// Could we call Thread::clear_thread_current(); here? >>>>>>> >>>>>>> Not easily. For JavaThreads we've already done "delete this" inside >>>>>>> the run() method, so we'd have to move that into java_start as >>>>>>> well, >>>>>>> but we can only do the delete for JavaThreads not for other >>>>>>> threads. >>>>>>> And we'd also have to change the VMThread and WatcherThread >>>>>>> termination logic because of the deletes that happen in the >>>>>>> termination thread - the "this" pointer (thread above) may no >>>>>>> longer >>>>>>> be valid when we want to call clear_current_thread() - which is >>>>>>> why we >>>>>>> can only do the ThreadLocalStorage::set_thread(NULL). >>>>>>> >>>>>>> I agree it would be a lot cleaner to have java_start do: >>>>>>> >>>>>>> thread->common_initialization(); >>>>>>> thread->run(); >>>>>>> thread->common_cleanup(); >>>>>>> delete thread; >>>>>>> >>>>>>> for all threads, but we'd need a lot of other changes to allow for >>>>>>> that. Otherwise we would need to note that kind of thread before >>>>>>> calling run() then switch on the thread type after run() to decide >>>>>>> what kind of cleanup is necessary and possible. I don't think that >>>>>>> would be better than just doing the "right" cleanup at the end >>>>>>> of the >>>>>>> run() methods. >>>>>> >>>>>> I understand that this is a bit messy, and I won't insist that we >>>>>> change >>>>>> this in this RFR, but without looking at this in much detail it >>>>>> sounds >>>>>> weird to delete the thread in run(). Couldn't this be solved by >>>>>> introducing a virtual Thread::post_run() function and do: >>>>>> >>>>>> virtual void Thread::post_run() { >>>>>> clear_thread_current(); >>>>>> } >>>>>> >>>>>> virtual void JavaThread::post_run() { >>>>>> Thread::post_run(); >>>>>> delete this; >>>>>> } >>>>> >>>>> But again this can't work for the VMThread or WatcherThread as they >>>>> are deleted from the termination thread and so thread->post_run() may >>>>> SEGV.** Plus it is only after the fact that you realize not to put >>>>> "delete this" in Thread::post_run(). >>>> >>>> OK, I didn't understand what you meant with "termination thread", but >>>> I now see the call to VMThread::destroy(). >>>> >>>> With that said, I find it odd that VMThread::destroy() deletes the VM >>>> thread. We already handshake between the VMThread and the "termination >>>> thread", so why isn't that VMThread::post_run() implemented as: >>>> >>>> virtual void VMThread::post_run() { >>>> // signal other threads that VM process is gone >>>> { >>>> // Note: we must have the _no_safepoint_check_flag. Mutex::lock() >>>> allows >>>> // VM thread to enter any lock at Safepoint as long as its _owner >>>> is NULL. >>>> // If that happens after _terminate_lock->wait() has unset _owner >>>> // but before it actually drops the lock and waits, the >>>> notification below >>>> // may get lost and we will have a hang. To avoid this, we need to >>>> use >>>> // Mutex::lock_without_safepoint_check(). >>>> MutexLockerEx ml(_terminate_lock, Mutex::_no_safepoint_check_flag); >>>> _terminated = true; >>>> _terminate_lock->notify(); >>>> } >>>> >>>> Thread::post_run(); >>>> delete this; >>>> } >>>> >>>> And then we wouldn't get a SEGV ... >>>> >>>> I couldn't find the destructor for the WatchThread, but it seems easy >>>> to fix that as well. >>>> >>>> I'm probably missing something, but I find it a bit annoying that code >>>> that should belong to the *Thread:ing system leaks into the >>>> implementations of *Thread::run(). >>>> >>>> Thanks, >>>> StefanK >>>>> >>>>> ** Arguably the best solution to the "thread termination races with >>>>> VM termination" problem is to not let the threads terminate. The code >>>>> as it exists today can still have JavaThreads destroying themselves >>>>> at the same that the VM is terminating and potentially hit the same >>>>> errors that require us to not allow the VMThread (and now >>>>> WatcherThread) to delete themselves. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Thanks, >>>>>> StefanK >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> ------ >>>>>>> >>>>>>>> >>>>>>>> log_info(os, thread)("Thread finished (tid: " UINTX_FORMAT ", >>>>>>>> pthread >>>>>>>> id: " UINTX_FORMAT ").", >>>>>>>> os::current_thread_id(), (uintx) pthread_self()); >>>>>>>> >>>>>>>> return 0; >>>>>>>> } >>>>>>>> >>>>>>>> And get rid of the explicit calls to >>>>>>>> ThreadLocalStorage::set_thread(NULL) you added? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> StefanK >>>>>>>> >>>>>>>> On 04/05/16 01:39, David Holmes wrote: >>>>>>>>> This needs attention from GC and runtime folk please. >>>>>>>>> >>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8154715 >>>>>>>>> webrev: http://cr.openjdk.java.net/~dholmes/8154715/webrev/ >>>>>>>>> >>>>>>>>> tl;dr: ensure ThreadLocalStorage::set_thread(NULL) is always >>>>>>>>> called >>>>>>>>> before a thread terminates. >>>>>>>>> >>>>>>>>> Background: >>>>>>>>> >>>>>>>>> Most system-related threads do not expect to explicitly >>>>>>>>> terminate, >>>>>>>>> except sometimes as part of VM termination. Such threads don't >>>>>>>>> have >>>>>>>>> their destructors called, but should. >>>>>>>>> >>>>>>>>> This omission came to light due to the ThreadLocalStorage >>>>>>>>> changes in >>>>>>>>> JDK-8132510. As part of that change we deleted the following >>>>>>>>> from the >>>>>>>>> termination path of the VMThread: >>>>>>>>> >>>>>>>>> // Thread destructor usually does this. >>>>>>>>> ThreadLocalStorage::set_thread(NULL); >>>>>>>>> >>>>>>>>> The clearing of TLS seemed irrelevant to the VMThread as it >>>>>>>>> primarily >>>>>>>>> is used to aid in JNI attach/detach. However Brian Gardner >>>>>>>>> reported: >>>>>>>>> >>>>>>>>> http://mail.openjdk.java.net/pipermail/bsd-port-dev/2016-February/002788.html >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> a problem on FreeBSD caused by this change and the interaction >>>>>>>>> with >>>>>>>>> the POSIX pthread TLS destructor use introduced by JDK-8033696. >>>>>>>>> Because the VMThread terminated without clearing TLS, when the >>>>>>>>> TLS-destructor was called it got into a loop which ran four >>>>>>>>> times (as >>>>>>>>> happens on Linux) and then prints a warning to the console (which >>>>>>>>> doesn't happen on Linux). >>>>>>>>> >>>>>>>>> This indicates we need to restore the: >>>>>>>>> >>>>>>>>> ThreadLocalStorage::set_thread(NULL); >>>>>>>>> >>>>>>>>> but on further consideration it seems to me that this is not >>>>>>>>> confined >>>>>>>>> to the VMThread, and the most appropriate fix would be to always >>>>>>>>> invoke the Thread destructor as a thread terminates. >>>>>>>>> >>>>>>>>> Solution: >>>>>>>>> >>>>>>>>> Further investigation shows that calling the Thread destructor >>>>>>>>> in the >>>>>>>>> thread as it terminates is not possible: >>>>>>>>> >>>>>>>>> - VMThread >>>>>>>>> >>>>>>>>> This is actually destroyed by the thread that terminates the VM, >>>>>>>>> but >>>>>>>>> that can happen after it terminates and so we still hit the TLS >>>>>>>>> problem. The VMThread may be able to destroy itself today but in >>>>>>>>> the >>>>>>>>> past this was not possible (see existing code comment), and in >>>>>>>>> the >>>>>>>>> future it may also not be possible - the problem is that the >>>>>>>>> Thread >>>>>>>>> destructor can interact with other VM subsystems that are >>>>>>>>> concurrently >>>>>>>>> being torn down by the thread that is terminating the VM. In the >>>>>>>>> past >>>>>>>>> this was the CodeHeap. So rather than introduce something that is >>>>>>>>> fragile we stick with the current scheme but restore the >>>>>>>>> ThreadLocalStorage::set_thread(NULL); - note we can't access >>>>>>>>> "this" at >>>>>>>>> that time because it may already have been de-allocated. >>>>>>>>> >>>>>>>>> - WatcherThread >>>>>>>>> >>>>>>>>> The WatcherThread is never destroyed today but has the same >>>>>>>>> problem as >>>>>>>>> the VMThread. We can call the destructor from the VM termination >>>>>>>>> thread (and have implemented that), but not from the >>>>>>>>> WatcherThread >>>>>>>>> itself. So again we just have to restore the >>>>>>>>> ThreadLocalStorage::set_thread(NULL); to fix the potential TLS >>>>>>>>> problem. >>>>>>>>> >>>>>>>>> - GC Threads >>>>>>>>> >>>>>>>>> There are two cases: >>>>>>>>> >>>>>>>>> a) GC threads that never terminate >>>>>>>>> >>>>>>>>> For these we don't need to do anything: we can't delete the >>>>>>>>> thread as >>>>>>>>> it never terminates and we don't hit the TLS problem because it >>>>>>>>> never >>>>>>>>> terminates. So all we will do here is add some logic to check (in >>>>>>>>> NON_PRODUCT) that we do in fact never terminate. >>>>>>>>> >>>>>>>>> b) GC threads that can terminate >>>>>>>>> >>>>>>>>> Despite the fact the threads can terminate, references to those >>>>>>>>> threads are stored elsewhere (WorkGangs and other places) and >>>>>>>>> are not >>>>>>>>> cleared as part of the termination process. Those references >>>>>>>>> can be >>>>>>>>> touched after the thread has terminated so we can not call the >>>>>>>>> destructor at all. So again all we can do (without some major >>>>>>>>> thread >>>>>>>>> management reworking) is ensure that >>>>>>>>> ThreadLocalStorage::set_thread(NULL); is called before the thread >>>>>>>>> actually terminates >>>>>>>>> >>>>>>>>> Testing: JPRT >>>>>>>>> RBT - runtime nightly tests >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>> From tobias.hartmann at oracle.com Mon May 9 09:31:27 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 9 May 2016 11:31:27 +0200 Subject: [9] RFR(S): 8155608: String intrinsic range checks are not strict enough In-Reply-To: References: <5721E9C4.7010208@oracle.com> <5722979C.1020904@oracle.com> <57231391.4010006@oracle.com> Message-ID: <573058EF.4050605@oracle.com> Thanks, Vladimir! Best regards, Tobias On 29.04.2016 16:48, Vladimir Kozlov wrote: > Thank you, Tobias, for answering my questions. > Changes looks good. > > Vladimir > > On 4/29/16 12:56 AM, Tobias Hartmann wrote: >> Hi Vladimir, >> >> On 29.04.2016 01:07, Vladimir Kozlov wrote: >>> In StringUTF16.java should getChars() throw when srcBegin > srcEnd? Or there is check in other place? >> >> Yes, there is another range check in String::getChars() that throws an exception if srcBegin > srcEnd but we don't want to throw an exception in this case if StringUTF16::getChars() is invoked directly. >> >>> Hotspot test changes seems fine but do you really need new helper methods? Why not allocate dst array in TestStringIntrinsicRangeChecks.java? >> >> StringUTF16 and StringLatin1 are package private classes in java.lang because they are part of the String internals. Therefore, the test (which is not part of the java.lang package) cannot invoke the intrinsified methods. To circumvent this, we use the "patch-library approach" to inject a wrapper class into java.lang that allows us to call the package private methods from the test: >> >> 26 package java.lang; >> 27 >> 28 /** >> 29 * A helper class to get access to package-private members >> 30 */ >> 31 public class Helper { >> >> We use the same approach for other compiler tests as well, for example the tests in test/compiler/jsr292/. >> >> Thanks, >> Tobias >> >>> Thanks, >>> Vladimir >>> >>> On 4/28/16 3:45 AM, Tobias Hartmann wrote: >>>> Hi >>>> >>>> please review the following patch: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8155608 >>>> http://cr.openjdk.java.net/~thartmann/8155608/jdk/webrev.00/ >>>> http://cr.openjdk.java.net/~thartmann/8155608/hotspot/webrev.00/ >>>> >>>> Some String API methods use StringUTF16.putChar/getChar to read a char value from a byte array. For performance reasons, putChar/getChar is intrinsified by C1/C2 without range checks (like the Unsafe counterparts). The Java callers are responsible for adding the corresponding explicit range checks if necessary. >>>> >>>> I noticed that the Java level range checks in StringUTF16::compress(), StringUTF16::getChars() and StringLatin1::inflate() are not strong enough. Offset and length need to be multiplied by two because they index a char value in a byte array. I added a regression test that triggers the problem and also checks the other relevant intrinsics by invoking the methods with different arguments. >>>> >>>> Tested with regression test (-Xint/-Xcomp) and RBT (running). >>>> >>>> Thanks, >>>> Tobias >>>> From erik.joelsson at oracle.com Mon May 9 10:09:21 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 9 May 2016 12:09:21 +0200 Subject: RFR: JDK-8156018: Hotspot visual studio project generation broken In-Reply-To: <5729BFB5.7050201@oracle.com> References: <5729BFB5.7050201@oracle.com> Message-ID: <573061D1.1050401@oracle.com> Friendly reminder. If at least someone who cares about VS projects could try it out and stamp this, that should be enough I think? /Erik On 2016-05-04 11:24, Erik Joelsson wrote: > With the new hotspot build, there was supposed to be support for > creating a visual studio project, as was possible in the old build > system. When creating the final changeset I missed including some of > the files needed for that. Here are the changes as they were supposed > to be, including removing the old version of the files since the old > build has already been removed. > > These changes were made by Magnus Ihse Bursie. Christian T?rnqvist has > verified that the generated project works. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8156018 > Webrev: http://cr.openjdk.java.net/~erikj/8156018/webrev.hotspot.01/ > > /Erik From markus.gronlund at oracle.com Mon May 9 10:13:50 2016 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Mon, 9 May 2016 03:13:50 -0700 (PDT) Subject: RFR: JDK-8156018: Hotspot visual studio project generation broken In-Reply-To: <573061D1.1050401@oracle.com> References: <5729BFB5.7050201@oracle.com> <573061D1.1050401@oracle.com> Message-ID: Hi Erik, I was just trying this out - end results looks good. Thanks for doing this! Markus -----Original Message----- From: Erik Joelsson Sent: den 9 maj 2016 12:09 To: build-dev; hotspot-dev developers Subject: Re: RFR: JDK-8156018: Hotspot visual studio project generation broken Friendly reminder. If at least someone who cares about VS projects could try it out and stamp this, that should be enough I think? /Erik On 2016-05-04 11:24, Erik Joelsson wrote: > With the new hotspot build, there was supposed to be support for > creating a visual studio project, as was possible in the old build > system. When creating the final changeset I missed including some of > the files needed for that. Here are the changes as they were supposed > to be, including removing the old version of the files since the old > build has already been removed. > > These changes were made by Magnus Ihse Bursie. Christian T?rnqvist has > verified that the generated project works. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8156018 > Webrev: http://cr.openjdk.java.net/~erikj/8156018/webrev.hotspot.01/ > > /Erik From christian.tornqvist at oracle.com Mon May 9 10:49:41 2016 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Mon, 9 May 2016 06:49:41 -0400 Subject: RFR: JDK-8156018: Hotspot visual studio project generation broken In-Reply-To: <573061D1.1050401@oracle.com> References: <5729BFB5.7050201@oracle.com> <573061D1.1050401@oracle.com> Message-ID: <2CED2C80-4222-4A00-813B-E0E54C9BBB57@oracle.com> Hi Erik, Looks good, thanks for fixing this! Thanks, Christian > On May 9, 2016, at 6:09 AM, Erik Joelsson wrote: > > Friendly reminder. If at least someone who cares about VS projects could > try it out and stamp this, that should be enough I think? > > /Erik > >> On 2016-05-04 11:24, Erik Joelsson wrote: >> With the new hotspot build, there was supposed to be support for >> creating a visual studio project, as was possible in the old build >> system. When creating the final changeset I missed including some of >> the files needed for that. Here are the changes as they were supposed >> to be, including removing the old version of the files since the old >> build has already been removed. >> >> These changes were made by Magnus Ihse Bursie. Christian T?rnqvist has >> verified that the generated project works. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8156018 >> Webrev: http://cr.openjdk.java.net/~erikj/8156018/webrev.hotspot.01/ >> >> /Erik > From david.holmes at oracle.com Mon May 9 11:03:29 2016 From: david.holmes at oracle.com (David Holmes) Date: Mon, 9 May 2016 21:03:29 +1000 Subject: RFR: 8154715: Missing destructor and/or TLS clearing calls for terminating threads In-Reply-To: <57305896.8020306@oracle.com> References: <572C4198.3090900@oracle.com> <572CA452.70401@oracle.com> <19147ab9-2480-3ace-6eaf-611eccc29ebf@oracle.com> <572CBB30.1010801@oracle.com> <3fb637e4-0dbe-31d6-2202-574ad3256a95@oracle.com> <55edc3b5-bd68-0e06-8003-bb9bf8093851@oracle.com> <57305896.8020306@oracle.com> Message-ID: On 9/05/2016 7:29 PM, Stefan Karlsson wrote: > Hi, > > For java_start, would it be enough to just, unconditionally, call > ThreadLocalStorage::set_thread(NULL) after thread->run() ? That would suffice for the current problem but seems a bit patchy to me - it's only a partial cleanup of TLS. What I am going to do is based On Brian's suggestion: if (Thread::current_or_null_safe() != NULL) { thread->clear_thread_current(); } with the addition that I not only undo the deletion of the WatcherThread, but I also remove the deletion of the VMThread. Was hoping to have a webrev ready but have run into a weird build problem. Thanks, David > StefanK > > On 2016-05-07 07:45, David Holmes wrote: >> Brian, Stefan, >> >> I've been giving this more thought and I think you are both right. >> While this can't be completely handled in java_start for all threads >> it can handle the most common cases. If I don't add the deletion of >> the WatcherThread then the problematic case reduces to that of the >> VMThread. >> >> I'll do a new version on Monday. I also need to double-check those >> threads that don't use java_start (which I am sorely tempted to rename). >> >> Thanks, >> David >> >> On 7/05/2016 9:50 AM, David Holmes wrote: >>> On 7/05/2016 5:40 AM, Brian Gardner wrote: >>>> I agree with Stefan. When I initially ran into the problem I came up >>>> with the following changeset that solves my problem, by calling >>>> clear_thread_current at the end of java_start. >>>> >>>> http://brian.timestudybuddy.com/webrev/hotspot__clear_thread_current_alt/webrev/ >>>> >>>> >>> >>> As I said I can see the appeal in doing this, but there is still a race >>> for the threads destroyed at VM shutdown as current_or_null() can return >>> non-NULL but the delete can happen before we call >>> thread->clear_current_thread(). >>> >>> You would also want Thread::current_or_null_safe() I think, due to >>> already deleted JavaThreads. >>> >>> And this all side-steps the real issue in my opinion that with clean >>> thread lifecycle management we should always be able to delete the >>> terminating thread. >>> >>> So to me it is a question of selecting which set of bandaids you want to >>> apply. >>> >>> Thanks, >>> David >>> >>>> Brian >>>> >>>>> On May 6, 2016, at 8:41 AM, Stefan Karlsson >>>>> > >>>>> wrote: >>>>> >>>>> On 06/05/16 16:32, David Holmes wrote: >>>>>> On 7/05/2016 12:04 AM, Stefan Karlsson wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> On 06/05/16 15:38, David Holmes wrote: >>>>>>>> Hi Stefan, >>>>>>>> >>>>>>>> Thanks for taking a look at this. >>>>>>>> >>>>>>>> On 6/05/2016 5:02 PM, Stefan Karlsson wrote: >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>> I looked through the GC part of this webrev and I think the >>>>>>>>> change is >>>>>>>>> fine. >>>>>>>>> >>>>>>>>> However, it seems a bit error prone. If we decide to change the >>>>>>>>> code to, >>>>>>>>> for example, terminate the AbstractGangWorker threads, then we >>>>>>>>> have to >>>>>>>>> remember to insert a ThreadLocalStorage::set_thread(NULL) call. >>>>>>>> >>>>>>>> That's why I added the ShouldNotReachHere()'s - if those threads >>>>>>>> start >>>>>>>> terminating then we will see those hit. Perhaps a comment: >>>>>>>> >>>>>>>> ShouldNotReachHere(); // If thread terminates we have to do TLS >>>>>>>> cleanup >>>>>>>> >>>>>>>> ? >>>>>>> >>>>>>> Yes, I would appreciate a comment. Though, when we add new >>>>>>> threads, we >>>>>>> need to remember to add the set_thread(NULL) call. >>>>>> >>>>>> Well no, what you would do is manage your new threads in such a way >>>>>> that their run() method can do "delete this" as the last call. Only >>>>>> if you can't do that do you need to think about what termination >>>>>> logic is missing that needs to be done in lieu of the destructor. >>>>> >>>>> Yes, but this forces every implementer of a Thread:run() function to >>>>> have to think about these kind of requirements. >>>>> >>>>>> >>>>>>>> >>>>>>>>> Could we instead add a call to >>>>>>>>> ThreadLocalStorage::set_thread(NULL), or >>>>>>>>> maybe even Thread::clear_thread_current(), in java_start? >>>>>>>>> >>>>>>>>> static void *java_start(Thread *thread) { >>>>>>>>> [...] >>>>>>>>> thread->initialize_thread_current(); >>>>>>>>> >>>>>>>>> [...] >>>>>>>>> >>>>>>>>> // call one more level start routine >>>>>>>>> thread->run(); >>>>>>>>> >>>>>>>>> ////////// Could we call Thread::clear_thread_current(); here? >>>>>>>> >>>>>>>> Not easily. For JavaThreads we've already done "delete this" inside >>>>>>>> the run() method, so we'd have to move that into java_start as >>>>>>>> well, >>>>>>>> but we can only do the delete for JavaThreads not for other >>>>>>>> threads. >>>>>>>> And we'd also have to change the VMThread and WatcherThread >>>>>>>> termination logic because of the deletes that happen in the >>>>>>>> termination thread - the "this" pointer (thread above) may no >>>>>>>> longer >>>>>>>> be valid when we want to call clear_current_thread() - which is >>>>>>>> why we >>>>>>>> can only do the ThreadLocalStorage::set_thread(NULL). >>>>>>>> >>>>>>>> I agree it would be a lot cleaner to have java_start do: >>>>>>>> >>>>>>>> thread->common_initialization(); >>>>>>>> thread->run(); >>>>>>>> thread->common_cleanup(); >>>>>>>> delete thread; >>>>>>>> >>>>>>>> for all threads, but we'd need a lot of other changes to allow for >>>>>>>> that. Otherwise we would need to note that kind of thread before >>>>>>>> calling run() then switch on the thread type after run() to decide >>>>>>>> what kind of cleanup is necessary and possible. I don't think that >>>>>>>> would be better than just doing the "right" cleanup at the end >>>>>>>> of the >>>>>>>> run() methods. >>>>>>> >>>>>>> I understand that this is a bit messy, and I won't insist that we >>>>>>> change >>>>>>> this in this RFR, but without looking at this in much detail it >>>>>>> sounds >>>>>>> weird to delete the thread in run(). Couldn't this be solved by >>>>>>> introducing a virtual Thread::post_run() function and do: >>>>>>> >>>>>>> virtual void Thread::post_run() { >>>>>>> clear_thread_current(); >>>>>>> } >>>>>>> >>>>>>> virtual void JavaThread::post_run() { >>>>>>> Thread::post_run(); >>>>>>> delete this; >>>>>>> } >>>>>> >>>>>> But again this can't work for the VMThread or WatcherThread as they >>>>>> are deleted from the termination thread and so thread->post_run() may >>>>>> SEGV.** Plus it is only after the fact that you realize not to put >>>>>> "delete this" in Thread::post_run(). >>>>> >>>>> OK, I didn't understand what you meant with "termination thread", but >>>>> I now see the call to VMThread::destroy(). >>>>> >>>>> With that said, I find it odd that VMThread::destroy() deletes the VM >>>>> thread. We already handshake between the VMThread and the "termination >>>>> thread", so why isn't that VMThread::post_run() implemented as: >>>>> >>>>> virtual void VMThread::post_run() { >>>>> // signal other threads that VM process is gone >>>>> { >>>>> // Note: we must have the _no_safepoint_check_flag. Mutex::lock() >>>>> allows >>>>> // VM thread to enter any lock at Safepoint as long as its _owner >>>>> is NULL. >>>>> // If that happens after _terminate_lock->wait() has unset _owner >>>>> // but before it actually drops the lock and waits, the >>>>> notification below >>>>> // may get lost and we will have a hang. To avoid this, we need to >>>>> use >>>>> // Mutex::lock_without_safepoint_check(). >>>>> MutexLockerEx ml(_terminate_lock, Mutex::_no_safepoint_check_flag); >>>>> _terminated = true; >>>>> _terminate_lock->notify(); >>>>> } >>>>> >>>>> Thread::post_run(); >>>>> delete this; >>>>> } >>>>> >>>>> And then we wouldn't get a SEGV ... >>>>> >>>>> I couldn't find the destructor for the WatchThread, but it seems easy >>>>> to fix that as well. >>>>> >>>>> I'm probably missing something, but I find it a bit annoying that code >>>>> that should belong to the *Thread:ing system leaks into the >>>>> implementations of *Thread::run(). >>>>> >>>>> Thanks, >>>>> StefanK >>>>>> >>>>>> ** Arguably the best solution to the "thread termination races with >>>>>> VM termination" problem is to not let the threads terminate. The code >>>>>> as it exists today can still have JavaThreads destroying themselves >>>>>> at the same that the VM is terminating and potentially hit the same >>>>>> errors that require us to not allow the VMThread (and now >>>>>> WatcherThread) to delete themselves. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> Thanks, >>>>>>> StefanK >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> ------ >>>>>>>> >>>>>>>>> >>>>>>>>> log_info(os, thread)("Thread finished (tid: " UINTX_FORMAT ", >>>>>>>>> pthread >>>>>>>>> id: " UINTX_FORMAT ").", >>>>>>>>> os::current_thread_id(), (uintx) pthread_self()); >>>>>>>>> >>>>>>>>> return 0; >>>>>>>>> } >>>>>>>>> >>>>>>>>> And get rid of the explicit calls to >>>>>>>>> ThreadLocalStorage::set_thread(NULL) you added? >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> StefanK >>>>>>>>> >>>>>>>>> On 04/05/16 01:39, David Holmes wrote: >>>>>>>>>> This needs attention from GC and runtime folk please. >>>>>>>>>> >>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8154715 >>>>>>>>>> webrev: http://cr.openjdk.java.net/~dholmes/8154715/webrev/ >>>>>>>>>> >>>>>>>>>> tl;dr: ensure ThreadLocalStorage::set_thread(NULL) is always >>>>>>>>>> called >>>>>>>>>> before a thread terminates. >>>>>>>>>> >>>>>>>>>> Background: >>>>>>>>>> >>>>>>>>>> Most system-related threads do not expect to explicitly >>>>>>>>>> terminate, >>>>>>>>>> except sometimes as part of VM termination. Such threads don't >>>>>>>>>> have >>>>>>>>>> their destructors called, but should. >>>>>>>>>> >>>>>>>>>> This omission came to light due to the ThreadLocalStorage >>>>>>>>>> changes in >>>>>>>>>> JDK-8132510. As part of that change we deleted the following >>>>>>>>>> from the >>>>>>>>>> termination path of the VMThread: >>>>>>>>>> >>>>>>>>>> // Thread destructor usually does this. >>>>>>>>>> ThreadLocalStorage::set_thread(NULL); >>>>>>>>>> >>>>>>>>>> The clearing of TLS seemed irrelevant to the VMThread as it >>>>>>>>>> primarily >>>>>>>>>> is used to aid in JNI attach/detach. However Brian Gardner >>>>>>>>>> reported: >>>>>>>>>> >>>>>>>>>> http://mail.openjdk.java.net/pipermail/bsd-port-dev/2016-February/002788.html >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> a problem on FreeBSD caused by this change and the interaction >>>>>>>>>> with >>>>>>>>>> the POSIX pthread TLS destructor use introduced by JDK-8033696. >>>>>>>>>> Because the VMThread terminated without clearing TLS, when the >>>>>>>>>> TLS-destructor was called it got into a loop which ran four >>>>>>>>>> times (as >>>>>>>>>> happens on Linux) and then prints a warning to the console (which >>>>>>>>>> doesn't happen on Linux). >>>>>>>>>> >>>>>>>>>> This indicates we need to restore the: >>>>>>>>>> >>>>>>>>>> ThreadLocalStorage::set_thread(NULL); >>>>>>>>>> >>>>>>>>>> but on further consideration it seems to me that this is not >>>>>>>>>> confined >>>>>>>>>> to the VMThread, and the most appropriate fix would be to always >>>>>>>>>> invoke the Thread destructor as a thread terminates. >>>>>>>>>> >>>>>>>>>> Solution: >>>>>>>>>> >>>>>>>>>> Further investigation shows that calling the Thread destructor >>>>>>>>>> in the >>>>>>>>>> thread as it terminates is not possible: >>>>>>>>>> >>>>>>>>>> - VMThread >>>>>>>>>> >>>>>>>>>> This is actually destroyed by the thread that terminates the VM, >>>>>>>>>> but >>>>>>>>>> that can happen after it terminates and so we still hit the TLS >>>>>>>>>> problem. The VMThread may be able to destroy itself today but in >>>>>>>>>> the >>>>>>>>>> past this was not possible (see existing code comment), and in >>>>>>>>>> the >>>>>>>>>> future it may also not be possible - the problem is that the >>>>>>>>>> Thread >>>>>>>>>> destructor can interact with other VM subsystems that are >>>>>>>>>> concurrently >>>>>>>>>> being torn down by the thread that is terminating the VM. In the >>>>>>>>>> past >>>>>>>>>> this was the CodeHeap. So rather than introduce something that is >>>>>>>>>> fragile we stick with the current scheme but restore the >>>>>>>>>> ThreadLocalStorage::set_thread(NULL); - note we can't access >>>>>>>>>> "this" at >>>>>>>>>> that time because it may already have been de-allocated. >>>>>>>>>> >>>>>>>>>> - WatcherThread >>>>>>>>>> >>>>>>>>>> The WatcherThread is never destroyed today but has the same >>>>>>>>>> problem as >>>>>>>>>> the VMThread. We can call the destructor from the VM termination >>>>>>>>>> thread (and have implemented that), but not from the >>>>>>>>>> WatcherThread >>>>>>>>>> itself. So again we just have to restore the >>>>>>>>>> ThreadLocalStorage::set_thread(NULL); to fix the potential TLS >>>>>>>>>> problem. >>>>>>>>>> >>>>>>>>>> - GC Threads >>>>>>>>>> >>>>>>>>>> There are two cases: >>>>>>>>>> >>>>>>>>>> a) GC threads that never terminate >>>>>>>>>> >>>>>>>>>> For these we don't need to do anything: we can't delete the >>>>>>>>>> thread as >>>>>>>>>> it never terminates and we don't hit the TLS problem because it >>>>>>>>>> never >>>>>>>>>> terminates. So all we will do here is add some logic to check (in >>>>>>>>>> NON_PRODUCT) that we do in fact never terminate. >>>>>>>>>> >>>>>>>>>> b) GC threads that can terminate >>>>>>>>>> >>>>>>>>>> Despite the fact the threads can terminate, references to those >>>>>>>>>> threads are stored elsewhere (WorkGangs and other places) and >>>>>>>>>> are not >>>>>>>>>> cleared as part of the termination process. Those references >>>>>>>>>> can be >>>>>>>>>> touched after the thread has terminated so we can not call the >>>>>>>>>> destructor at all. So again all we can do (without some major >>>>>>>>>> thread >>>>>>>>>> management reworking) is ensure that >>>>>>>>>> ThreadLocalStorage::set_thread(NULL); is called before the thread >>>>>>>>>> actually terminates >>>>>>>>>> >>>>>>>>>> Testing: JPRT >>>>>>>>>> RBT - runtime nightly tests >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>> > From igor.ignatyev at oracle.com Mon May 9 11:45:15 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 9 May 2016 14:45:15 +0300 Subject: RFR(M) : 8148244 : Finalize and integrate GTest implementation In-Reply-To: <572C4231.6030001@oracle.com> References: <4E849CF5-6955-4240-BF4F-A104B188AADA@oracle.com> <57274243.9050809@oracle.com> <572C4231.6030001@oracle.com> Message-ID: <713EC632-87C6-4693-B045-6DB5A9AD8CBB@oracle.com> http://cr.openjdk.java.net/~iignatyev///8148244-root/webrev.03 http://cr.openjdk.java.net/~iignatyev///8148244-hotspot/webrev.03 Hi Erik, I?ve update the changes according to your comments, could you please take a look? Thanks, ? Igor > On May 6, 2016, at 10:05 AM, Erik Joelsson wrote: > > Good catch with disabling gtest in the case of the "build jdk". > > I would prefer if you introduced a new variable for it, something more obvious like BUILD_GTEST. Default it to true in spec.gmk.in and override that value to false in buildjdk-spec.gmk.in. (The TEST_IN_BUILD variable had a different purpose and is now dead, so please also remove it from buildjdk-spec.gmk.in). I would also prefer if you put the whole inclusion of CompileGtest.gmk in a conditional in CompileLibraries.gmk instead, so we avoid all of the evaluation of building it when disabled. Also, please don't forget to indent anything inside a conditional. Like this: > > ifeq ($(BUILD_GTEST), true) > include lib/CompileGtest.gmk > endif > > > For completeness, there should probably also be a conditional of BUILD_GTEST like this in Main.gmk: > ifeq ($(BUILD_GTEST), true) > test-image-hotspot-gtest: > > +($(CD) $(HOTSPOT_TOPDIR)/make/test && $(MAKE) $(MAKE_ARGS) -f GtestImage.gmk) > endif > > > /Erik > > > On 2016-05-05 16:58, Igor Ignatyev wrote: >> Hi, >> >> I?ve rebased the changes to the latest jdk9/hs and removed the comment from JvmMapfile.gmk. Also I?ve guarded building gtest w/ if TEST_IN_BUILD != false ( >> http://cr.openjdk.java.net/~iignatyev/8148244-hotspot/webrev.02/make/lib/CompileGtest.gmk.html >> ), so we won?t build it when we compile build jdk in case of cross-compliation. >> >> new webrevs: >> >> http://cr.openjdk.java.net/~iignatyev/8148244-root/webrev.02 >> http://cr.openjdk.java.net/~iignatyev/8148244-hotspot/webrev.02/ >> >> >> Thanks, >> ? Igor >> >> >> >>> On May 2, 2016, at 3:55 PM, Jesper Wilhelmsson >>> wrote: >>> >>> Even though the comment on line 155 in JvmMapfile.gmk is accurate I agree with removing it. >>> >>> Besides that the change looks good! >>> /Jesper >>> >>> >>> Den 2/5/16 kl. 14:04, skrev Erik Joelsson: >>> >>>> Hello, >>>> >>>> Build changes look good to me, but I also wrote most of them, except for >>>> makefiles/lib/JvmMapfile.gmk line 155. I could not have written that. Please >>>> remove. >>>> >>>> The webrevs seem to be generated against jdk9/hs without the removal of the old >>>> build system. I would recommend making that merge and generate new webrevs since >>>> makefiles moved around quite a bit. >>>> >>>> /Erik >>>> >>>> On 2016-05-02 13:21, Igor Ignatyev wrote: >>>> >>>>> http://cr.openjdk.java.net/~iignatyev/8148244-hotspot/webrev.00 >>>>>> 615 lines changed: 605 ins; 2 del; 8 mod; >>>>>> >>>>> http://cr.openjdk.java.net/~iignatyev/8148244-root-wo-gtest/webrev.00/ >>>>>> 218 lines changed: 209 ins; 0 del; 9 mod; >>>>>> >>>>> http://cr.openjdk.java.net/~iignatyev/8148244-root/webrev.00/ >>>>>> 32029 lines changed: 32018 ins; 0 del; 11 mod; >>>>>> >>>>> Hi all, >>>>> >>>>> could you please review this patch which delivers core of JEP 281: HotSpot C++ >>>>> Unit-Test Framework[1]? >>>>> in more details, this patch >>>>> - integrates sources of gtest-1.7.0[2] to /test/fmw/gtest (~32k LOC) >>>>> - introduces TEST macros (/hotspot/test/native/unittest.hpp) >>>>> - TEST ? a basic unit test, doesn?t require an inited JVM >>>>> - TEST_VM ? a test which requires an inited JVM, but expected to leave JVM >>>>> in a valid state >>>>> - TEST_OTHER_VM ? a test which requires a clean inited JVM >>>>> - TEST_VM_ASSERT/TEST_VM_ASSERT_MSG - tests to verify assert, ?death?[3] >>>>> tests which require inited JVM >>>>> - contains two tests as smoke tests for the project and examples. new tests >>>>> should be added to /hotspot/test/native/ using the same directories layout as >>>>> a corresponding product source files, and have prefix ?test_?, e.g. >>>>> test/native/runtime/test_os.cpp w/ tests for runtime/test_os.cpp >>>>> - updates makefiles to build/run tests : to run tests, one should use 'make >>>>> test TEST=hotspot_gtest? >>>>> - adds hotspot_gtest to jprt testset >>>>> >>>>> more information on the project can be found in JEP 281[1]. >>>>> >>>>> please be informed, that existing unit tests (aka internal tests) will be >>>>> ported into new framework later, this activity is tracking by JDK-8077965[4]. >>>>> >>>>> PS This patch relies on JDK-8149591[5] which is under review[6]. >>>>> >>>>> Thanks, >>>>> ? Igor >>>>> >>>>> JBS: >>>>> https://bugs.openjdk.java.net/browse/JDK-8148244 >>>>> >>>>> webrevs: >>>>> root : >>>>> http://cr.openjdk.java.net/~iignatyev/8148244-root/webrev.00/ >>>>> >>>>> w/o gtest : >>>>> >>>>> http://cr.openjdk.java.net/~iignatyev/8148244-root-wo-gtest/webrev.00/ >>>>> >>>>> hotspot : >>>>> http://cr.openjdk.java.net/~iignatyev/8148244-hotspot/webrev.00 >>>>> >>>>> >>>>> [1] >>>>> https://bugs.openjdk.java.net/browse/JDK-8047975 >>>>> >>>>> [2] >>>>> https://github.com/google/googletest/releases/tag/release-1.7.0 >>>>> >>>>> [3] >>>>> >>>>> https://github.com/google/googletest/blob/master/googletest/docs/V1_7_AdvancedGuide.md#death-tests >>>>> >>>>> >>>>> [4] >>>>> https://bugs.openjdk.java.net/browse/JDK-8077965 >>>>> >>>>> [5] >>>>> https://bugs.openjdk.java.net/browse/JDK-8149591 >>>>> >>>>> [6] >>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-April/022937.html > From tobias.hartmann at oracle.com Mon May 9 11:49:10 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 9 May 2016 13:49:10 +0200 Subject: [9] RFR(S): 8155608: String intrinsic range checks are not strict enough In-Reply-To: References: <5721E9C4.7010208@oracle.com> <3E5A7A17-9D61-4C80-A19D-9F510BCAADCE@oracle.com> <57230C0F.7060702@oracle.com> Message-ID: <57307936.20609@oracle.com> Hi John, thanks for the feedback! On 30.04.2016 02:47, John Rose wrote: > >> On Apr 29, 2016, at 1:00 PM, Christian Thalinger wrote: >> >> >>> On Apr 28, 2016, at 9:23 PM, Tobias Hartmann wrote: >>> >>> Hi Chris, >>> >>> On 28.04.2016 22:11, Christian Thalinger wrote: >>>> >>>>> On Apr 28, 2016, at 12:45 AM, Tobias Hartmann > wrote: >>>>> >>>>> Hi >>>>> >>>>> please review the following patch: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8155608 >>>>> http://cr.openjdk.java.net/~thartmann/8155608/jdk/webrev.00/ >>>> + checkBoundsOffCount(dstOff << 1, len << 1, dst.length); >>>> >>>> It?s funny that we still do << 1 instead of * 2 when every compiler on this planet can optimize that. Yeah, yeah, I know, it?s because of the interpreter but does it really matter? >>> >>> I used it more for consistency because we use "<< 1" in all the other places in StringLatin1, StringUTF16 and String as well. I think this originated from the "value.length >> String.coder()" use case to get the length depending on the String encoding. Besides that, I'm not sure if interpreter speed really matters here but the String methods are executed a lot (especially during startup). >>> >>>> Actually, I would prefer: >>>> >>>> + checkBoundsOffCount(dstOff * Character.BYTES, len * Character.BYTES, dst.length); >>> >>> I agree that this is more readable but for consistency I would like to go with the "<< 1" approach. >> >> Again, a loss for maintainability versus consistency (a.k.a. ?we?ve always done it this way?). > > That '1' is an anti-pattern I call "naked constant". Which "1" is it, after all? > The maintainer of code needs to know which condition (of thousands of possibilities) dictates a "1" here. > In HotSpot we discourage such nakedness, in favor of named constants: > https://wiki.openjdk.java.net/display/HotSpot/StyleGuide#StyleGuide-NamedCons > > The Java code should follow this practice also. Right, I agree. I filed JDK-8156530 [1] to fix this. > Also, independently, I'm having a hard time figuring out how to prove that, between the Java code and the HotSpot intrinsic (and interpreter/C1/C2), the range checking logic is consistently applied. > > My best advice for this is, always, put the range checking logic in one place, in Java code. This makes me profoundly suspicious of *any* public method that is also marked @HSIC, if it takes any array arguments. If the public method is an intrinsic, it means we are trusting C++ IR-assembly code to securely check Java array bounds. That is unnatural, and (as history proves repeatedly) subject to errors. Yes, we had that initially but I had to move some of the checks from the Java code into the intrinsic because of JDK-8142303 (see [2]). I filed JDK-8156534 [3] to check if we can move the checks back into the Java code without problems similar to JDK-8142303. I will also change the implementation of some of the intrinsics with JDK-8139132 and JDK-8146547 and do some refactoring. > Instead, we should have a Java routine which checks bounds, and a *private* intrinsic which is provably called *only after* the Java checker is called. The problem is that some of the intrinsified String methods are heavily used and C2 is not always able to remove the range checks introduced by the public wrapper method. For example, StringUTF16::getChar() is used in places where we implicitly know that the access is in bounds (for example, because the array length is always a multiple of two) but C2 cannot prove this. Therefore, if we want to avoid a regression, we have to call the unchecked version of the intrinsic in some cases. Thanks, Tobias [1] https://bugs.openjdk.java.net/browse/JDK-8156530 [2] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-November/019834.html [3] https://bugs.openjdk.java.net/browse/JDK-8156534 From erik.joelsson at oracle.com Mon May 9 12:20:07 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 9 May 2016 14:20:07 +0200 Subject: RFR(M) : 8148244 : Finalize and integrate GTest implementation In-Reply-To: <713EC632-87C6-4693-B045-6DB5A9AD8CBB@oracle.com> References: <4E849CF5-6955-4240-BF4F-A104B188AADA@oracle.com> <57274243.9050809@oracle.com> <572C4231.6030001@oracle.com> <713EC632-87C6-4693-B045-6DB5A9AD8CBB@oracle.com> Message-ID: <57308077.2050907@oracle.com> Looks good! /Erik On 2016-05-09 13:45, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev///8148244-root/webrev.03 > http://cr.openjdk.java.net/~iignatyev///8148244-hotspot/webrev.03 > > Hi Erik, > > I?ve update the changes according to your comments, could you please take a look? > > Thanks, > ? Igor > >> On May 6, 2016, at 10:05 AM, Erik Joelsson wrote: >> >> Good catch with disabling gtest in the case of the "build jdk". >> >> I would prefer if you introduced a new variable for it, something more obvious like BUILD_GTEST. Default it to true in spec.gmk.in and override that value to false in buildjdk-spec.gmk.in. (The TEST_IN_BUILD variable had a different purpose and is now dead, so please also remove it from buildjdk-spec.gmk.in). I would also prefer if you put the whole inclusion of CompileGtest.gmk in a conditional in CompileLibraries.gmk instead, so we avoid all of the evaluation of building it when disabled. Also, please don't forget to indent anything inside a conditional. Like this: >> >> ifeq ($(BUILD_GTEST), true) >> include lib/CompileGtest.gmk >> endif >> >> >> For completeness, there should probably also be a conditional of BUILD_GTEST like this in Main.gmk: >> ifeq ($(BUILD_GTEST), true) >> test-image-hotspot-gtest: >> >> +($(CD) $(HOTSPOT_TOPDIR)/make/test && $(MAKE) $(MAKE_ARGS) -f GtestImage.gmk) >> endif >> >> >> /Erik >> >> >> On 2016-05-05 16:58, Igor Ignatyev wrote: >>> Hi, >>> >>> I?ve rebased the changes to the latest jdk9/hs and removed the comment from JvmMapfile.gmk. Also I?ve guarded building gtest w/ if TEST_IN_BUILD != false ( >>> http://cr.openjdk.java.net/~iignatyev/8148244-hotspot/webrev.02/make/lib/CompileGtest.gmk.html >>> ), so we won?t build it when we compile build jdk in case of cross-compliation. >>> >>> new webrevs: >>> >>> http://cr.openjdk.java.net/~iignatyev/8148244-root/webrev.02 >>> http://cr.openjdk.java.net/~iignatyev/8148244-hotspot/webrev.02/ >>> >>> >>> Thanks, >>> ? Igor >>> >>> >>> >>>> On May 2, 2016, at 3:55 PM, Jesper Wilhelmsson >>>> wrote: >>>> >>>> Even though the comment on line 155 in JvmMapfile.gmk is accurate I agree with removing it. >>>> >>>> Besides that the change looks good! >>>> /Jesper >>>> >>>> >>>> Den 2/5/16 kl. 14:04, skrev Erik Joelsson: >>>> >>>>> Hello, >>>>> >>>>> Build changes look good to me, but I also wrote most of them, except for >>>>> makefiles/lib/JvmMapfile.gmk line 155. I could not have written that. Please >>>>> remove. >>>>> >>>>> The webrevs seem to be generated against jdk9/hs without the removal of the old >>>>> build system. I would recommend making that merge and generate new webrevs since >>>>> makefiles moved around quite a bit. >>>>> >>>>> /Erik >>>>> >>>>> On 2016-05-02 13:21, Igor Ignatyev wrote: >>>>> >>>>>> http://cr.openjdk.java.net/~iignatyev/8148244-hotspot/webrev.00 >>>>>>> 615 lines changed: 605 ins; 2 del; 8 mod; >>>>>>> >>>>>> http://cr.openjdk.java.net/~iignatyev/8148244-root-wo-gtest/webrev.00/ >>>>>>> 218 lines changed: 209 ins; 0 del; 9 mod; >>>>>>> >>>>>> http://cr.openjdk.java.net/~iignatyev/8148244-root/webrev.00/ >>>>>>> 32029 lines changed: 32018 ins; 0 del; 11 mod; >>>>>>> >>>>>> Hi all, >>>>>> >>>>>> could you please review this patch which delivers core of JEP 281: HotSpot C++ >>>>>> Unit-Test Framework[1]? >>>>>> in more details, this patch >>>>>> - integrates sources of gtest-1.7.0[2] to /test/fmw/gtest (~32k LOC) >>>>>> - introduces TEST macros (/hotspot/test/native/unittest.hpp) >>>>>> - TEST ? a basic unit test, doesn?t require an inited JVM >>>>>> - TEST_VM ? a test which requires an inited JVM, but expected to leave JVM >>>>>> in a valid state >>>>>> - TEST_OTHER_VM ? a test which requires a clean inited JVM >>>>>> - TEST_VM_ASSERT/TEST_VM_ASSERT_MSG - tests to verify assert, ?death?[3] >>>>>> tests which require inited JVM >>>>>> - contains two tests as smoke tests for the project and examples. new tests >>>>>> should be added to /hotspot/test/native/ using the same directories layout as >>>>>> a corresponding product source files, and have prefix ?test_?, e.g. >>>>>> test/native/runtime/test_os.cpp w/ tests for runtime/test_os.cpp >>>>>> - updates makefiles to build/run tests : to run tests, one should use 'make >>>>>> test TEST=hotspot_gtest? >>>>>> - adds hotspot_gtest to jprt testset >>>>>> >>>>>> more information on the project can be found in JEP 281[1]. >>>>>> >>>>>> please be informed, that existing unit tests (aka internal tests) will be >>>>>> ported into new framework later, this activity is tracking by JDK-8077965[4]. >>>>>> >>>>>> PS This patch relies on JDK-8149591[5] which is under review[6]. >>>>>> >>>>>> Thanks, >>>>>> ? Igor >>>>>> >>>>>> JBS: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8148244 >>>>>> >>>>>> webrevs: >>>>>> root : >>>>>> http://cr.openjdk.java.net/~iignatyev/8148244-root/webrev.00/ >>>>>> >>>>>> w/o gtest : >>>>>> >>>>>> http://cr.openjdk.java.net/~iignatyev/8148244-root-wo-gtest/webrev.00/ >>>>>> >>>>>> hotspot : >>>>>> http://cr.openjdk.java.net/~iignatyev/8148244-hotspot/webrev.00 >>>>>> >>>>>> >>>>>> [1] >>>>>> https://bugs.openjdk.java.net/browse/JDK-8047975 >>>>>> >>>>>> [2] >>>>>> https://github.com/google/googletest/releases/tag/release-1.7.0 >>>>>> >>>>>> [3] >>>>>> >>>>>> https://github.com/google/googletest/blob/master/googletest/docs/V1_7_AdvancedGuide.md#death-tests >>>>>> >>>>>> >>>>>> [4] >>>>>> https://bugs.openjdk.java.net/browse/JDK-8077965 >>>>>> >>>>>> [5] >>>>>> https://bugs.openjdk.java.net/browse/JDK-8149591 >>>>>> >>>>>> [6] >>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-April/022937.html From jesper.wilhelmsson at oracle.com Mon May 9 14:26:18 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 9 May 2016 16:26:18 +0200 Subject: RFR(M) : 8148244 : Finalize and integrate GTest implementation In-Reply-To: <713EC632-87C6-4693-B045-6DB5A9AD8CBB@oracle.com> References: <4E849CF5-6955-4240-BF4F-A104B188AADA@oracle.com> <57274243.9050809@oracle.com> <572C4231.6030001@oracle.com> <713EC632-87C6-4693-B045-6DB5A9AD8CBB@oracle.com> Message-ID: <654d6ad4-5e8e-e43a-c454-123112447a82@oracle.com> Looks good! /Jesper Den 9/5/16 kl. 13:45, skrev Igor Ignatyev: > http://cr.openjdk.java.net/~iignatyev///8148244-root/webrev.03 > http://cr.openjdk.java.net/~iignatyev///8148244-hotspot/webrev.03 > > Hi Erik, > > I?ve update the changes according to your comments, could you please take a look? > > Thanks, > ? Igor > >> On May 6, 2016, at 10:05 AM, Erik Joelsson wrote: >> >> Good catch with disabling gtest in the case of the "build jdk". >> >> I would prefer if you introduced a new variable for it, something more obvious like BUILD_GTEST. Default it to true in spec.gmk.in and override that value to false in buildjdk-spec.gmk.in. (The TEST_IN_BUILD variable had a different purpose and is now dead, so please also remove it from buildjdk-spec.gmk.in). I would also prefer if you put the whole inclusion of CompileGtest.gmk in a conditional in CompileLibraries.gmk instead, so we avoid all of the evaluation of building it when disabled. Also, please don't forget to indent anything inside a conditional. Like this: >> >> ifeq ($(BUILD_GTEST), true) >> include lib/CompileGtest.gmk >> endif >> >> >> For completeness, there should probably also be a conditional of BUILD_GTEST like this in Main.gmk: >> ifeq ($(BUILD_GTEST), true) >> test-image-hotspot-gtest: >> >> +($(CD) $(HOTSPOT_TOPDIR)/make/test && $(MAKE) $(MAKE_ARGS) -f GtestImage.gmk) >> endif >> >> >> /Erik >> >> >> On 2016-05-05 16:58, Igor Ignatyev wrote: >>> Hi, >>> >>> I?ve rebased the changes to the latest jdk9/hs and removed the comment from JvmMapfile.gmk. Also I?ve guarded building gtest w/ if TEST_IN_BUILD != false ( >>> http://cr.openjdk.java.net/~iignatyev/8148244-hotspot/webrev.02/make/lib/CompileGtest.gmk.html >>> ), so we won?t build it when we compile build jdk in case of cross-compliation. >>> >>> new webrevs: >>> >>> http://cr.openjdk.java.net/~iignatyev/8148244-root/webrev.02 >>> http://cr.openjdk.java.net/~iignatyev/8148244-hotspot/webrev.02/ >>> >>> >>> Thanks, >>> ? Igor >>> >>> >>> >>>> On May 2, 2016, at 3:55 PM, Jesper Wilhelmsson >>>> wrote: >>>> >>>> Even though the comment on line 155 in JvmMapfile.gmk is accurate I agree with removing it. >>>> >>>> Besides that the change looks good! >>>> /Jesper >>>> >>>> >>>> Den 2/5/16 kl. 14:04, skrev Erik Joelsson: >>>> >>>>> Hello, >>>>> >>>>> Build changes look good to me, but I also wrote most of them, except for >>>>> makefiles/lib/JvmMapfile.gmk line 155. I could not have written that. Please >>>>> remove. >>>>> >>>>> The webrevs seem to be generated against jdk9/hs without the removal of the old >>>>> build system. I would recommend making that merge and generate new webrevs since >>>>> makefiles moved around quite a bit. >>>>> >>>>> /Erik >>>>> >>>>> On 2016-05-02 13:21, Igor Ignatyev wrote: >>>>> >>>>>> http://cr.openjdk.java.net/~iignatyev/8148244-hotspot/webrev.00 >>>>>>> 615 lines changed: 605 ins; 2 del; 8 mod; >>>>>>> >>>>>> http://cr.openjdk.java.net/~iignatyev/8148244-root-wo-gtest/webrev.00/ >>>>>>> 218 lines changed: 209 ins; 0 del; 9 mod; >>>>>>> >>>>>> http://cr.openjdk.java.net/~iignatyev/8148244-root/webrev.00/ >>>>>>> 32029 lines changed: 32018 ins; 0 del; 11 mod; >>>>>>> >>>>>> Hi all, >>>>>> >>>>>> could you please review this patch which delivers core of JEP 281: HotSpot C++ >>>>>> Unit-Test Framework[1]? >>>>>> in more details, this patch >>>>>> - integrates sources of gtest-1.7.0[2] to /test/fmw/gtest (~32k LOC) >>>>>> - introduces TEST macros (/hotspot/test/native/unittest.hpp) >>>>>> - TEST ? a basic unit test, doesn?t require an inited JVM >>>>>> - TEST_VM ? a test which requires an inited JVM, but expected to leave JVM >>>>>> in a valid state >>>>>> - TEST_OTHER_VM ? a test which requires a clean inited JVM >>>>>> - TEST_VM_ASSERT/TEST_VM_ASSERT_MSG - tests to verify assert, ?death?[3] >>>>>> tests which require inited JVM >>>>>> - contains two tests as smoke tests for the project and examples. new tests >>>>>> should be added to /hotspot/test/native/ using the same directories layout as >>>>>> a corresponding product source files, and have prefix ?test_?, e.g. >>>>>> test/native/runtime/test_os.cpp w/ tests for runtime/test_os.cpp >>>>>> - updates makefiles to build/run tests : to run tests, one should use 'make >>>>>> test TEST=hotspot_gtest? >>>>>> - adds hotspot_gtest to jprt testset >>>>>> >>>>>> more information on the project can be found in JEP 281[1]. >>>>>> >>>>>> please be informed, that existing unit tests (aka internal tests) will be >>>>>> ported into new framework later, this activity is tracking by JDK-8077965[4]. >>>>>> >>>>>> PS This patch relies on JDK-8149591[5] which is under review[6]. >>>>>> >>>>>> Thanks, >>>>>> ? Igor >>>>>> >>>>>> JBS: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8148244 >>>>>> >>>>>> webrevs: >>>>>> root : >>>>>> http://cr.openjdk.java.net/~iignatyev/8148244-root/webrev.00/ >>>>>> >>>>>> w/o gtest : >>>>>> >>>>>> http://cr.openjdk.java.net/~iignatyev/8148244-root-wo-gtest/webrev.00/ >>>>>> >>>>>> hotspot : >>>>>> http://cr.openjdk.java.net/~iignatyev/8148244-hotspot/webrev.00 >>>>>> >>>>>> >>>>>> [1] >>>>>> https://bugs.openjdk.java.net/browse/JDK-8047975 >>>>>> >>>>>> [2] >>>>>> https://github.com/google/googletest/releases/tag/release-1.7.0 >>>>>> >>>>>> [3] >>>>>> >>>>>> https://github.com/google/googletest/blob/master/googletest/docs/V1_7_AdvancedGuide.md#death-tests >>>>>> >>>>>> >>>>>> [4] >>>>>> https://bugs.openjdk.java.net/browse/JDK-8077965 >>>>>> >>>>>> [5] >>>>>> https://bugs.openjdk.java.net/browse/JDK-8149591 >>>>>> >>>>>> [6] >>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-April/022937.html >> > From gerard.ziemski at oracle.com Mon May 9 14:46:31 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Mon, 9 May 2016 09:46:31 -0500 Subject: RFR (XS): rev3 8152856: Xcode 7.3 -Wshift-negative-value compile failure on Mac OS X In-Reply-To: <572A2152.1030909@oracle.com> References: <185B4145-0862-44AF-93F5-C75F81056195@oracle.com> <572A2152.1030909@oracle.com> Message-ID: <21CDF055-B1DF-4DA6-9C2A-61E1450FDF4D@oracle.com> PING Can I ask for a second review please? cheers > On May 4, 2016, at 11:20 AM, Vladimir Ivanov wrote: > > Looks good. > > Best regards, > Vladimir Ivanov > > On 5/4/16 7:02 PM, Gerard Ziemski wrote: >> PING >> >> Can I please have a review of this small fix? I have removed makefile change, which is no longer needed, so this should be non-controversial to review: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8152856 >> webrev: http://cr.openjdk.java.net/~gziemski/8152856_rev3 >> >> >> cheers >> >>> On Apr 6, 2016, at 11:35 AM, Gerard Ziemski wrote: >>> >>> hi all, >>> >>> I have implemented and tested out the new proposed fix using constant instead of casts. Please review this new fix: >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8152856 >>> webrev: http://cr.openjdk.java.net/~gziemski/8152856_rev2 >>> >>> Passes JPRT hotspot and RBT hotspot/test/:hotspot_runtime >>> >>> >>> cheers >>> >>>> On Mar 31, 2016, at 9:08 AM, Gerard Ziemski wrote: >>>> >>>> hi all, >>>> >>>> Since no-one has reviewed this yet and in the meantime we changed https://wiki.openjdk.java.net/display/HotSpot/StyleGuide to discourage using enums in hotspot (see JDK-8153116 for more details) I?m going to withdraw this proposed fix and try doing it by replacing enums with constant literals instead of using casts on enums. >>>> >>>> I therefore withdraw this fix for now. >>>> >>>> >>>> cheers >>>> >>>>> On Mar 29, 2016, at 4:30 PM, Gerard Ziemski wrote: >>>>> >>>>> hi all, >>>>> >>>>> Please review this small fix that enables Xcde 7.3 support for building hotspot, which involved 2 things: >>>>> >>>>> - modify gcc.make to add support for 7.3 version of clang compiler >>>>> - modify src/cpu/x86/vm/stubGenerator_x86_64.cpp, src/share/vm/oops/klass.hpp and src/share/vm/opto/library_call.cpp to cast 4 instances of signed int to unsigned when using shift operator to avoid "-Wshift-negative-value" warning. >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8152856 >>>>> http://cr.openjdk.java.net/~gziemski/8152856_rev1 >>>>> >>>>> Passes JPRT hotspot on all platforms >>>>> >>>> >>> >> From marcelino.rodriguez-cancio at irisa.fr Mon May 9 14:52:20 2016 From: marcelino.rodriguez-cancio at irisa.fr (Marcelino Rodriguez cancio) Date: Mon, 9 May 2016 16:52:20 +0200 (CEST) Subject: Documentation on the Hostpot C++ Heap Management In-Reply-To: <992666810.4088936.1462803959178.JavaMail.zimbra@irisa.fr> Message-ID: <1656389951.4103084.1462805540733.JavaMail.zimbra@irisa.fr> Hello Community: I'm doing some modifications to the Server Compiler (C2) to test some ideas for my Ph.D. Anyway, I'm having some memory related errors which I believe are caused by my inability to properly manage memory. I see there a several types of objects (ResourceObj, StackObj, _ValueObj, etc.) (/hotspot/src/share/vm/memory/allocation.hpp). Also the Arena takes memory from three chunk pools ( http://openjdk.java.net/groups/hotspot/docs/RuntimeOverview.html#C++%20Heap%20Management|outline )... My point is that I have scattered pieces of information that I will have to digest and organize in my head before I'm able to properly use the allocation classes of Hotspot and I was thinking that perhaps someone has done this before and written something about it. Optimally, I'm looking for a comprehensive guide explaining the different classes, the usage rules, good and bad practices...or any resource you think may help me have a mental map of this topic. Thanks a lot for your time! Marcelino From kim.barrett at oracle.com Mon May 9 18:37:09 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 9 May 2016 14:37:09 -0400 Subject: RFR: 8146948: Add help information to log tags In-Reply-To: <313004cb-cc55-030f-61ac-abc05b56cc68@oracle.com> References: <570F9F97.4060808@oracle.com> <313004cb-cc55-030f-61ac-abc05b56cc68@oracle.com> Message-ID: > On May 9, 2016, at 3:36 AM, Marcus Larsson wrote: > On 05/04/2016 08:30 PM, Kim Barrett wrote: >> src/share/vm/logging/logTagSetDescriptions.inline.hpp >> 39 static struct LogTagSetDescription { >> 40 const LogTagSet* tagset; >> 41 const char* descr; >> 42 } tagset_descriptions[] = { >> 43 LOG_TAG_SET_DESCRIPTION_LIST >> 44 { NULL, NULL } >> 45 }; >> >> Won't this place a copy of the descriptions in each translation unit >> that includes this file, each in it's own file-scoped >> tagset_descriptions variable? I think better would be a class >> definition with a static const array member in the header, with the >> member definition (including the associated macrology) in a .cpp file. > > The intention is that this file should only be included from logTagSet.cpp and therefore not cause any copying of the descriptions. The first approach was just to have them in logTagSet.cpp but I wanted an easy to find place for where to add/edit descriptions so I opted for a separate file. I didn't want to make a whole hpp/cpp pair for it, but if you still think that would be better I can do it; let me know. logTagSetDescriptions.inline.hpp is included by both logTagSet.cpp and log.cpp. Even if that weren?t already a problem, it would be an accident waiting to happen in future development/maintenance. From christian.thalinger at oracle.com Mon May 9 19:52:54 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 9 May 2016 09:52:54 -1000 Subject: [9] RFR(S): 8155608: String intrinsic range checks are not strict enough In-Reply-To: <57307936.20609@oracle.com> References: <5721E9C4.7010208@oracle.com> <3E5A7A17-9D61-4C80-A19D-9F510BCAADCE@oracle.com> <57230C0F.7060702@oracle.com> <57307936.20609@oracle.com> Message-ID: > On May 9, 2016, at 1:49 AM, Tobias Hartmann wrote: > > Hi John, > > thanks for the feedback! > > On 30.04.2016 02:47, John Rose wrote: >> >>> On Apr 29, 2016, at 1:00 PM, Christian Thalinger wrote: >>> >>> >>>> On Apr 28, 2016, at 9:23 PM, Tobias Hartmann wrote: >>>> >>>> Hi Chris, >>>> >>>> On 28.04.2016 22:11, Christian Thalinger wrote: >>>>> >>>>>> On Apr 28, 2016, at 12:45 AM, Tobias Hartmann > wrote: >>>>>> >>>>>> Hi >>>>>> >>>>>> please review the following patch: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8155608 >>>>>> http://cr.openjdk.java.net/~thartmann/8155608/jdk/webrev.00/ >>>>> + checkBoundsOffCount(dstOff << 1, len << 1, dst.length); >>>>> >>>>> It?s funny that we still do << 1 instead of * 2 when every compiler on this planet can optimize that. Yeah, yeah, I know, it?s because of the interpreter but does it really matter? >>>> >>>> I used it more for consistency because we use "<< 1" in all the other places in StringLatin1, StringUTF16 and String as well. I think this originated from the "value.length >> String.coder()" use case to get the length depending on the String encoding. Besides that, I'm not sure if interpreter speed really matters here but the String methods are executed a lot (especially during startup). >>>> >>>>> Actually, I would prefer: >>>>> >>>>> + checkBoundsOffCount(dstOff * Character.BYTES, len * Character.BYTES, dst.length); >>>> >>>> I agree that this is more readable but for consistency I would like to go with the "<< 1" approach. >>> >>> Again, a loss for maintainability versus consistency (a.k.a. ?we?ve always done it this way?). >> >> That '1' is an anti-pattern I call "naked constant". Which "1" is it, after all? >> The maintainer of code needs to know which condition (of thousands of possibilities) dictates a "1" here. >> In HotSpot we discourage such nakedness, in favor of named constants: >> https://wiki.openjdk.java.net/display/HotSpot/StyleGuide#StyleGuide-NamedCons >> >> The Java code should follow this practice also. > > Right, I agree. I filed JDK-8156530 [1] to fix this. > >> Also, independently, I'm having a hard time figuring out how to prove that, between the Java code and the HotSpot intrinsic (and interpreter/C1/C2), the range checking logic is consistently applied. >> >> My best advice for this is, always, put the range checking logic in one place, in Java code. This makes me profoundly suspicious of *any* public method that is also marked @HSIC, if it takes any array arguments. If the public method is an intrinsic, it means we are trusting C++ IR-assembly code to securely check Java array bounds. That is unnatural, and (as history proves repeatedly) subject to errors. > > Yes, we had that initially but I had to move some of the checks from the Java code into the intrinsic because of JDK-8142303 (see [2]). > > I filed JDK-8156534 [3] to check if we can move the checks back into the Java code without problems similar to JDK-8142303. I will also change the implementation of some of the intrinsics with JDK-8139132 and JDK-8146547 and do some refactoring. > >> Instead, we should have a Java routine which checks bounds, and a *private* intrinsic which is provably called *only after* the Java checker is called. > > The problem is that some of the intrinsified String methods are heavily used and C2 is not always able to remove the range checks introduced by the public wrapper method. For example, StringUTF16::getChar() is used in places where we implicitly know that the access is in bounds (for example, because the array length is always a multiple of two) but C2 cannot prove this. Maybe we could sprinkle some Java code to help the compilers. > Therefore, if we want to avoid a regression, we have to call the unchecked version of the intrinsic in some cases. > > Thanks, > Tobias > > [1] https://bugs.openjdk.java.net/browse/JDK-8156530 > [2] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-November/019834.html > [3] https://bugs.openjdk.java.net/browse/JDK-8156534 From christian.thalinger at oracle.com Mon May 9 19:57:41 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Mon, 9 May 2016 09:57:41 -1000 Subject: Documentation on the Hostpot C++ Heap Management In-Reply-To: <1656389951.4103084.1462805540733.JavaMail.zimbra@irisa.fr> References: <1656389951.4103084.1462805540733.JavaMail.zimbra@irisa.fr> Message-ID: <372CD90C-9F4C-418D-ACBE-6BC21419CF07@oracle.com> > On May 9, 2016, at 4:52 AM, Marcelino Rodriguez cancio wrote: > > Hello Community: > > I'm doing some modifications to the Server Compiler (C2) to test some ideas for my Ph.D. Does it have to be C2? Graal is much better suited for academic research: http://openjdk.java.net/projects/graal/ > > Anyway, I'm having some memory related errors which I believe are caused by my inability to properly manage memory. > > I see there a several types of objects (ResourceObj, StackObj, _ValueObj, etc.) (/hotspot/src/share/vm/memory/allocation.hpp). Also the Arena takes memory from three chunk pools ( http://openjdk.java.net/groups/hotspot/docs/RuntimeOverview.html#C++%20Heap%20Management|outline )... > > My point is that I have scattered pieces of information that I will have to digest and organize in my head before I'm able to properly use the allocation classes of Hotspot and I was thinking that perhaps someone has done this before and written something about it. > > Optimally, I'm looking for a comprehensive guide explaining the different classes, the usage rules, good and bad practices...or any resource you think may help me have a mental map of this topic. > > Thanks a lot for your time! > Marcelino > > > From david.holmes at oracle.com Tue May 10 00:33:30 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 10 May 2016 10:33:30 +1000 Subject: RFR: 8154715: Missing destructor and/or TLS clearing calls for terminating threads In-Reply-To: References: <572C4198.3090900@oracle.com> <572CA452.70401@oracle.com> <19147ab9-2480-3ace-6eaf-611eccc29ebf@oracle.com> <572CBB30.1010801@oracle.com> <3fb637e4-0dbe-31d6-2202-574ad3256a95@oracle.com> <55edc3b5-bd68-0e06-8003-bb9bf8093851@oracle.com> <57305896.8020306@oracle.com> Message-ID: Okay here is version 2: http://cr.openjdk.java.net/~dholmes/8154715/webrev.v2/ Lots of cosmetic changes but only a couple of functional ones: - After thread->run() returns we clear the TLS by calling clear_thread_current(), but only for threads where it has not already been cleared - as those threads may already have been deleted so we can't dereference 'thread' - No asynchronous thread deletion is permitted, and we avoid races with VM termination. This means the VMThread no longer gets deleted - that should not be an issue as many threads do not get deleted when the VM terminates. I added destructors for the VMThread and WatcherThread so anyone introducing their deletion is informed by a guarantee(false) Cosmetic changes: - renamed java_start to thread_native_entry (it is used by all threads not just "java" ones, so this avoids potential confusion) - updated os::free_thread to always assume it works on the current thread (and add assert to verify that) Thanks, David From marcus.larsson at oracle.com Tue May 10 06:57:08 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Tue, 10 May 2016 08:57:08 +0200 Subject: RFR: 8146948: Add help information to log tags In-Reply-To: References: <570F9F97.4060808@oracle.com> <313004cb-cc55-030f-61ac-abc05b56cc68@oracle.com> Message-ID: <477fc3a7-85a8-664d-d7f7-796cc4d8c386@oracle.com> Updated webrev: http://cr.openjdk.java.net/~mlarsson/8146948/webrev.01/ Incremental: http://cr.openjdk.java.net/~mlarsson/8146948/webrev.00-01/ Thanks, Marcus On 05/09/2016 08:37 PM, Kim Barrett wrote: >> On May 9, 2016, at 3:36 AM, Marcus Larsson wrote: >> On 05/04/2016 08:30 PM, Kim Barrett wrote: >>> src/share/vm/logging/logTagSetDescriptions.inline.hpp >>> 39 static struct LogTagSetDescription { >>> 40 const LogTagSet* tagset; >>> 41 const char* descr; >>> 42 } tagset_descriptions[] = { >>> 43 LOG_TAG_SET_DESCRIPTION_LIST >>> 44 { NULL, NULL } >>> 45 }; >>> >>> Won't this place a copy of the descriptions in each translation unit >>> that includes this file, each in it's own file-scoped >>> tagset_descriptions variable? I think better would be a class >>> definition with a static const array member in the header, with the >>> member definition (including the associated macrology) in a .cpp file. >> The intention is that this file should only be included from logTagSet.cpp and therefore not cause any copying of the descriptions. The first approach was just to have them in logTagSet.cpp but I wanted an easy to find place for where to add/edit descriptions so I opted for a separate file. I didn't want to make a whole hpp/cpp pair for it, but if you still think that would be better I can do it; let me know. > logTagSetDescriptions.inline.hpp is included by both logTagSet.cpp and log.cpp. > Even if that weren?t already a problem, it would be an accident waiting to happen > in future development/maintenance. > > From stefan.karlsson at oracle.com Tue May 10 08:24:39 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 10 May 2016 10:24:39 +0200 Subject: RFR: 8154715: Missing destructor and/or TLS clearing calls for terminating threads In-Reply-To: References: <572C4198.3090900@oracle.com> <572CA452.70401@oracle.com> <19147ab9-2480-3ace-6eaf-611eccc29ebf@oracle.com> <572CBB30.1010801@oracle.com> <3fb637e4-0dbe-31d6-2202-574ad3256a95@oracle.com> <55edc3b5-bd68-0e06-8003-bb9bf8093851@oracle.com> <57305896.8020306@oracle.com> Message-ID: <57319AC7.4010601@oracle.com> Hi David, On 10/05/16 02:33, David Holmes wrote: > Okay here is version 2: > > http://cr.openjdk.java.net/~dholmes/8154715/webrev.v2/ > > Lots of cosmetic changes but only a couple of functional ones: > > - After thread->run() returns we clear the TLS by calling > clear_thread_current(), but only for threads where it has not already > been cleared - as those threads may already have been deleted so we > can't dereference 'thread' > > - No asynchronous thread deletion is permitted, and we avoid races > with VM termination. This means the VMThread no longer gets deleted - > that should not be an issue as many threads do not get deleted when > the VM terminates. I added destructors for the VMThread and > WatcherThread so anyone introducing their deletion is informed by a > guarantee(false) This makes the model easier to understand, IMHO. Either you delete the thread from the run() method, or you don't delete it at all. I's there a way to determine how much memory we leak by not deleting the memory owned by the VMThread instance? I'm a bit worried that the VMThread might use more resources than the other threads we don't delete. Thanks, StefanK > > > Cosmetic changes: > > - renamed java_start to thread_native_entry (it is used by all threads > not just "java" ones, so this avoids potential confusion) > > - updated os::free_thread to always assume it works on the current > thread (and add assert to verify that) > > Thanks, > David From tobias.hartmann at oracle.com Tue May 10 08:51:30 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 10 May 2016 10:51:30 +0200 Subject: [9] RFR(S): 8155608: String intrinsic range checks are not strict enough In-Reply-To: References: <5721E9C4.7010208@oracle.com> <3E5A7A17-9D61-4C80-A19D-9F510BCAADCE@oracle.com> <57230C0F.7060702@oracle.com> <57307936.20609@oracle.com> Message-ID: <5731A112.6000608@oracle.com> Hi Chris, On 09.05.2016 21:52, Christian Thalinger wrote: > >> On May 9, 2016, at 1:49 AM, Tobias Hartmann > wrote: >> >> Hi John, >> >> thanks for the feedback! >> >> On 30.04.2016 02:47, John Rose wrote: >>> >>>> On Apr 29, 2016, at 1:00 PM, Christian Thalinger > wrote: >>>> >>>> >>>>> On Apr 28, 2016, at 9:23 PM, Tobias Hartmann > wrote: >>>>> >>>>> Hi Chris, >>>>> >>>>> On 28.04.2016 22:11, Christian Thalinger wrote: >>>>>> >>>>>>> On Apr 28, 2016, at 12:45 AM, Tobias Hartmann > wrote: >>>>>>> >>>>>>> Hi >>>>>>> >>>>>>> please review the following patch: >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8155608 >>>>>>> http://cr.openjdk.java.net/~thartmann/8155608/jdk/webrev.00/ >>>>>> + checkBoundsOffCount(dstOff << 1, len << 1, dst.length); >>>>>> >>>>>> It?s funny that we still do << 1 instead of * 2 when every compiler on this planet can optimize that. Yeah, yeah, I know, it?s because of the interpreter but does it really matter? >>>>> >>>>> I used it more for consistency because we use "<< 1" in all the other places in StringLatin1, StringUTF16 and String as well. I think this originated from the "value.length >> String.coder()" use case to get the length depending on the String encoding. Besides that, I'm not sure if interpreter speed really matters here but the String methods are executed a lot (especially during startup). >>>>> >>>>>> Actually, I would prefer: >>>>>> >>>>>> + checkBoundsOffCount(dstOff * Character.BYTES, len * Character.BYTES, dst.length); >>>>> >>>>> I agree that this is more readable but for consistency I would like to go with the "<< 1" approach. >>>> >>>> Again, a loss for maintainability versus consistency (a.k.a. ?we?ve always done it this way?). >>> >>> That '1' is an anti-pattern I call "naked constant". Which "1" is it, after all? >>> The maintainer of code needs to know which condition (of thousands of possibilities) dictates a "1" here. >>> In HotSpot we discourage such nakedness, in favor of named constants: >>> https://wiki.openjdk.java.net/display/HotSpot/StyleGuide#StyleGuide-NamedCons >>> >>> The Java code should follow this practice also. >> >> Right, I agree. I filed JDK-8156530 [1] to fix this. >> >>> Also, independently, I'm having a hard time figuring out how to prove that, between the Java code and the HotSpot intrinsic (and interpreter/C1/C2), the range checking logic is consistently applied. >>> >>> My best advice for this is, always, put the range checking logic in one place, in Java code. This makes me profoundly suspicious of *any* public method that is also marked @HSIC, if it takes any array arguments. If the public method is an intrinsic, it means we are trusting C++ IR-assembly code to securely check Java array bounds. That is unnatural, and (as history proves repeatedly) subject to errors. >> >> Yes, we had that initially but I had to move some of the checks from the Java code into the intrinsic because of JDK-8142303 (see [2]). >> >> I filed JDK-8156534 [3] to check if we can move the checks back into the Java code without problems similar to JDK-8142303. I will also change the implementation of some of the intrinsics with JDK-8139132 and JDK-8146547 and do some refactoring. >> >>> Instead, we should have a Java routine which checks bounds, and a *private* intrinsic which is provably called *only after* the Java checker is called. >> >> The problem is that some of the intrinsified String methods are heavily used and C2 is not always able to remove the range checks introduced by the public wrapper method. For example, StringUTF16::getChar() is used in places where we implicitly know that the access is in bounds (for example, because the array length is always a multiple of two) but C2 cannot prove this. > > Maybe we could sprinkle some Java code to help the compilers. Yes, but that only helps if the Java code is compiled which may not be the case if the explicit Java range checks are for example in a different method that is not inlined. Otherwise, there is no way the compiler knows about them. Looking at the JDK-8142303 again, it may be sufficient to have the null checks in the intrinsic. Also, we can probably make use of the intrinsified Preconditions.checkIndex(). I'll investigate this with JDK-8156534. If there are no objections, I would like to push webrev.00. Thanks, Tobias >> Therefore, if we want to avoid a regression, we have to call the unchecked version of the intrinsic in some cases. >> >> Thanks, >> Tobias >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8156530 >> [2] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-November/019834.html >> [3] https://bugs.openjdk.java.net/browse/JDK-8156534 > From marcelino.rodriguez-cancio at irisa.fr Tue May 10 09:22:15 2016 From: marcelino.rodriguez-cancio at irisa.fr (Marcelino Rodriguez cancio) Date: Tue, 10 May 2016 11:22:15 +0200 (CEST) Subject: Documentation on the Hostpot C++ Heap Management In-Reply-To: <372CD90C-9F4C-418D-ACBE-6BC21419CF07@oracle.com> References: <1656389951.4103084.1462805540733.JavaMail.zimbra@irisa.fr> <372CD90C-9F4C-418D-ACBE-6BC21419CF07@oracle.com> Message-ID: <2013946574.4400512.1462872135192.JavaMail.zimbra@irisa.fr> Hi Christian Thanks a lot for the feedback! I will definitively take a look at the Graal compiler Best Marcelino ----- Mail original ----- > De: "Christian Thalinger" > ?: "Marcelino Rodriguez cancio" > Cc: adoption-discuss at openjdk.java.net, hotspot-dev at openjdk.java.net > Envoy?: Lundi 9 Mai 2016 21:57:41 > Objet: Re: Documentation on the Hostpot C++ Heap Management > > > > On May 9, 2016, at 4:52 AM, Marcelino Rodriguez cancio > > wrote: > > > > Hello Community: > > > > I'm doing some modifications to the Server Compiler (C2) to test some ideas > > for my Ph.D. > > Does it have to be C2? Graal is much better suited for academic research: > > http://openjdk.java.net/projects/graal/ > > > > > Anyway, I'm having some memory related errors which I believe are caused by > > my inability to properly manage memory. > > > > I see there a several types of objects (ResourceObj, StackObj, _ValueObj, > > etc.) (/hotspot/src/share/vm/memory/allocation.hpp). Also the Arena takes > > memory from three chunk pools ( > > http://openjdk.java.net/groups/hotspot/docs/RuntimeOverview.html#C++%20Heap%20Management|outline > > )... > > > > My point is that I have scattered pieces of information that I will have to > > digest and organize in my head before I'm able to properly use the > > allocation classes of Hotspot and I was thinking that perhaps someone has > > done this before and written something about it. > > > > Optimally, I'm looking for a comprehensive guide explaining the different > > classes, the usage rules, good and bad practices...or any resource you > > think may help me have a mental map of this topic. > > > > Thanks a lot for your time! > > Marcelino > > > > > > > > From david.holmes at oracle.com Tue May 10 10:17:49 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 10 May 2016 20:17:49 +1000 Subject: RFR: 8154715: Missing destructor and/or TLS clearing calls for terminating threads In-Reply-To: <57319AC7.4010601@oracle.com> References: <572C4198.3090900@oracle.com> <572CA452.70401@oracle.com> <19147ab9-2480-3ace-6eaf-611eccc29ebf@oracle.com> <572CBB30.1010801@oracle.com> <3fb637e4-0dbe-31d6-2202-574ad3256a95@oracle.com> <55edc3b5-bd68-0e06-8003-bb9bf8093851@oracle.com> <57305896.8020306@oracle.com> <57319AC7.4010601@oracle.com> Message-ID: Hi Stefan, Thanks for looking at this again. On 10/05/2016 6:24 PM, Stefan Karlsson wrote: > Hi David, > > On 10/05/16 02:33, David Holmes wrote: >> Okay here is version 2: >> >> http://cr.openjdk.java.net/~dholmes/8154715/webrev.v2/ >> >> Lots of cosmetic changes but only a couple of functional ones: >> >> - After thread->run() returns we clear the TLS by calling >> clear_thread_current(), but only for threads where it has not already >> been cleared - as those threads may already have been deleted so we >> can't dereference 'thread' >> >> - No asynchronous thread deletion is permitted, and we avoid races >> with VM termination. This means the VMThread no longer gets deleted - >> that should not be an issue as many threads do not get deleted when >> the VM terminates. I added destructors for the VMThread and >> WatcherThread so anyone introducing their deletion is informed by a >> guarantee(false) > > This makes the model easier to understand, IMHO. Either you delete the > thread from the run() method, or you don't delete it at all. > > I's there a way to determine how much memory we leak by not deleting the > memory owned by the VMThread instance? I'm a bit worried that the > VMThread might use more resources than the other threads we don't delete. There is nothing at all special about the VMThread instance, it is just a NamedThread with nothing being referenced by instance fields beyond the name. Any runtime resources are released as the thread terminates - and nothing special there either AFAICS. Thanks, David > Thanks, > StefanK > >> >> >> Cosmetic changes: >> >> - renamed java_start to thread_native_entry (it is used by all threads >> not just "java" ones, so this avoids potential confusion) >> >> - updated os::free_thread to always assume it works on the current >> thread (and add assert to verify that) >> >> Thanks, >> David > From rwestrel at redhat.com Tue May 10 12:48:54 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 10 May 2016 14:48:54 +0200 Subject: RFR: 8155627: Enable SA on AArch64 In-Reply-To: <572CC280.3050308@redhat.com> References: <57168C17.40307@oracle.com> <57185E31.9010705@oracle.com> <57235E1B.8080001@redhat.com> <57235F39.5080204@redhat.com> <101be161-cfb4-b2d4-0b35-0d497d3dfa19@oracle.com> <572CC280.3050308@redhat.com> Message-ID: > http://cr.openjdk.java.net/~aph/8155627 That looks good to me. Roland. From igor.ignatyev at oracle.com Tue May 10 16:13:12 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 10 May 2016 19:13:12 +0300 Subject: RFR(M) : 8148244 : Finalize and integrate GTest implementation In-Reply-To: <654d6ad4-5e8e-e43a-c454-123112447a82@oracle.com> References: <4E849CF5-6955-4240-BF4F-A104B188AADA@oracle.com> <57274243.9050809@oracle.com> <572C4231.6030001@oracle.com> <713EC632-87C6-4693-B045-6DB5A9AD8CBB@oracle.com> <654d6ad4-5e8e-e43a-c454-123112447a82@oracle.com> Message-ID: <5C5539BD-8F24-4AB6-8520-36D189FA36EC@oracle.com> Jesper, Erik, thank you both for review! ? Igor > On May 9, 2016, at 5:26 PM, Jesper Wilhelmsson wrote: > > Looks good! > /Jesper > > Den 9/5/16 kl. 13:45, skrev Igor Ignatyev: >> http://cr.openjdk.java.net/~iignatyev///8148244-root/webrev.03 >> http://cr.openjdk.java.net/~iignatyev///8148244-hotspot/webrev.03 >> >> Hi Erik, >> >> I?ve update the changes according to your comments, could you please take a look? >> >> Thanks, >> ? Igor >> >>> On May 6, 2016, at 10:05 AM, Erik Joelsson wrote: >>> >>> Good catch with disabling gtest in the case of the "build jdk". >>> >>> I would prefer if you introduced a new variable for it, something more obvious like BUILD_GTEST. Default it to true in spec.gmk.in and override that value to false in buildjdk-spec.gmk.in. (The TEST_IN_BUILD variable had a different purpose and is now dead, so please also remove it from buildjdk-spec.gmk.in). I would also prefer if you put the whole inclusion of CompileGtest.gmk in a conditional in CompileLibraries.gmk instead, so we avoid all of the evaluation of building it when disabled. Also, please don't forget to indent anything inside a conditional. Like this: >>> >>> ifeq ($(BUILD_GTEST), true) >>> include lib/CompileGtest.gmk >>> endif >>> >>> >>> For completeness, there should probably also be a conditional of BUILD_GTEST like this in Main.gmk: >>> ifeq ($(BUILD_GTEST), true) >>> test-image-hotspot-gtest: >>> >>> +($(CD) $(HOTSPOT_TOPDIR)/make/test && $(MAKE) $(MAKE_ARGS) -f GtestImage.gmk) >>> endif >>> >>> >>> /Erik >>> >>> >>> On 2016-05-05 16:58, Igor Ignatyev wrote: >>>> Hi, >>>> >>>> I?ve rebased the changes to the latest jdk9/hs and removed the comment from JvmMapfile.gmk. Also I?ve guarded building gtest w/ if TEST_IN_BUILD != false ( >>>> http://cr.openjdk.java.net/~iignatyev/8148244-hotspot/webrev.02/make/lib/CompileGtest.gmk.html >>>> ), so we won?t build it when we compile build jdk in case of cross-compliation. >>>> >>>> new webrevs: >>>> >>>> http://cr.openjdk.java.net/~iignatyev/8148244-root/webrev.02 >>>> http://cr.openjdk.java.net/~iignatyev/8148244-hotspot/webrev.02/ >>>> >>>> >>>> Thanks, >>>> ? Igor >>>> >>>> >>>> >>>>> On May 2, 2016, at 3:55 PM, Jesper Wilhelmsson >>>>> wrote: >>>>> >>>>> Even though the comment on line 155 in JvmMapfile.gmk is accurate I agree with removing it. >>>>> >>>>> Besides that the change looks good! >>>>> /Jesper >>>>> >>>>> >>>>> Den 2/5/16 kl. 14:04, skrev Erik Joelsson: >>>>> >>>>>> Hello, >>>>>> >>>>>> Build changes look good to me, but I also wrote most of them, except for >>>>>> makefiles/lib/JvmMapfile.gmk line 155. I could not have written that. Please >>>>>> remove. >>>>>> >>>>>> The webrevs seem to be generated against jdk9/hs without the removal of the old >>>>>> build system. I would recommend making that merge and generate new webrevs since >>>>>> makefiles moved around quite a bit. >>>>>> >>>>>> /Erik >>>>>> >>>>>> On 2016-05-02 13:21, Igor Ignatyev wrote: >>>>>> >>>>>>> http://cr.openjdk.java.net/~iignatyev/8148244-hotspot/webrev.00 >>>>>>>> 615 lines changed: 605 ins; 2 del; 8 mod; >>>>>>>> >>>>>>> http://cr.openjdk.java.net/~iignatyev/8148244-root-wo-gtest/webrev.00/ >>>>>>>> 218 lines changed: 209 ins; 0 del; 9 mod; >>>>>>>> >>>>>>> http://cr.openjdk.java.net/~iignatyev/8148244-root/webrev.00/ >>>>>>>> 32029 lines changed: 32018 ins; 0 del; 11 mod; >>>>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> could you please review this patch which delivers core of JEP 281: HotSpot C++ >>>>>>> Unit-Test Framework[1]? >>>>>>> in more details, this patch >>>>>>> - integrates sources of gtest-1.7.0[2] to /test/fmw/gtest (~32k LOC) >>>>>>> - introduces TEST macros (/hotspot/test/native/unittest.hpp) >>>>>>> - TEST ? a basic unit test, doesn?t require an inited JVM >>>>>>> - TEST_VM ? a test which requires an inited JVM, but expected to leave JVM >>>>>>> in a valid state >>>>>>> - TEST_OTHER_VM ? a test which requires a clean inited JVM >>>>>>> - TEST_VM_ASSERT/TEST_VM_ASSERT_MSG - tests to verify assert, ?death?[3] >>>>>>> tests which require inited JVM >>>>>>> - contains two tests as smoke tests for the project and examples. new tests >>>>>>> should be added to /hotspot/test/native/ using the same directories layout as >>>>>>> a corresponding product source files, and have prefix ?test_?, e.g. >>>>>>> test/native/runtime/test_os.cpp w/ tests for runtime/test_os.cpp >>>>>>> - updates makefiles to build/run tests : to run tests, one should use 'make >>>>>>> test TEST=hotspot_gtest? >>>>>>> - adds hotspot_gtest to jprt testset >>>>>>> >>>>>>> more information on the project can be found in JEP 281[1]. >>>>>>> >>>>>>> please be informed, that existing unit tests (aka internal tests) will be >>>>>>> ported into new framework later, this activity is tracking by JDK-8077965[4]. >>>>>>> >>>>>>> PS This patch relies on JDK-8149591[5] which is under review[6]. >>>>>>> >>>>>>> Thanks, >>>>>>> ? Igor >>>>>>> >>>>>>> JBS: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8148244 >>>>>>> >>>>>>> webrevs: >>>>>>> root : >>>>>>> http://cr.openjdk.java.net/~iignatyev/8148244-root/webrev.00/ >>>>>>> >>>>>>> w/o gtest : >>>>>>> >>>>>>> http://cr.openjdk.java.net/~iignatyev/8148244-root-wo-gtest/webrev.00/ >>>>>>> >>>>>>> hotspot : >>>>>>> http://cr.openjdk.java.net/~iignatyev/8148244-hotspot/webrev.00 >>>>>>> >>>>>>> >>>>>>> [1] >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8047975 >>>>>>> >>>>>>> [2] >>>>>>> https://github.com/google/googletest/releases/tag/release-1.7.0 >>>>>>> >>>>>>> [3] >>>>>>> >>>>>>> https://github.com/google/googletest/blob/master/googletest/docs/V1_7_AdvancedGuide.md#death-tests >>>>>>> >>>>>>> >>>>>>> [4] >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8077965 >>>>>>> >>>>>>> [5] >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8149591 >>>>>>> >>>>>>> [6] >>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-April/022937.html >>> >> From igor.ignatyev at oracle.com Tue May 10 16:31:09 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 10 May 2016 19:31:09 +0300 Subject: RFR(S) : 8156681 : Add jtreg wrapper for hotspot gtest tests Message-ID: http://cr.openjdk.java.net/~iignatyev/8156681/webrev.00/ > 71 lines changed: 71 ins; 0 del; 0 mod; Hi all, could you please integrate this small fix which adds a jtreg wrapper to run gtest tests? JBS: https://bugs.openjdk.java.net/browse/JDK-8156681 webrev: http://cr.openjdk.java.net/~iignatyev/8156681/webrev.00/ Thanks, ? Igor From jesper.wilhelmsson at oracle.com Tue May 10 17:32:47 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 10 May 2016 19:32:47 +0200 Subject: RFR(S) : 8156681 : Add jtreg wrapper for hotspot gtest tests In-Reply-To: References: Message-ID: <43534a4a-a132-292c-8333-64d45074ad62@oracle.com> Looks good! /Jesper Den 10/5/16 kl. 18:31, skrev Igor Ignatyev: > http://cr.openjdk.java.net/~iignatyev/8156681/webrev.00/ >> 71 lines changed: 71 ins; 0 del; 0 mod; > > Hi all, > > could you please integrate this small fix which adds a jtreg wrapper to run gtest tests? > > JBS: https://bugs.openjdk.java.net/browse/JDK-8156681 > webrev: http://cr.openjdk.java.net/~iignatyev/8156681/webrev.00/ > > Thanks, > ? Igor > From stefan.karlsson at oracle.com Tue May 10 18:59:48 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 10 May 2016 20:59:48 +0200 Subject: RFR: 8154715: Missing destructor and/or TLS clearing calls for terminating threads In-Reply-To: References: <572C4198.3090900@oracle.com> <572CA452.70401@oracle.com> <19147ab9-2480-3ace-6eaf-611eccc29ebf@oracle.com> <572CBB30.1010801@oracle.com> <3fb637e4-0dbe-31d6-2202-574ad3256a95@oracle.com> <55edc3b5-bd68-0e06-8003-bb9bf8093851@oracle.com> <57305896.8020306@oracle.com> <57319AC7.4010601@oracle.com> Message-ID: <57322FA4.6010700@oracle.com> Hi David, On 10/05/16 12:17, David Holmes wrote: > Hi Stefan, > > Thanks for looking at this again. > > On 10/05/2016 6:24 PM, Stefan Karlsson wrote: >> Hi David, >> >> On 10/05/16 02:33, David Holmes wrote: >>> Okay here is version 2: >>> >>> http://cr.openjdk.java.net/~dholmes/8154715/webrev.v2/ >>> >>> Lots of cosmetic changes but only a couple of functional ones: >>> >>> - After thread->run() returns we clear the TLS by calling >>> clear_thread_current(), but only for threads where it has not already >>> been cleared - as those threads may already have been deleted so we >>> can't dereference 'thread' >>> >>> - No asynchronous thread deletion is permitted, and we avoid races >>> with VM termination. This means the VMThread no longer gets deleted - >>> that should not be an issue as many threads do not get deleted when >>> the VM terminates. I added destructors for the VMThread and >>> WatcherThread so anyone introducing their deletion is informed by a >>> guarantee(false) >> >> This makes the model easier to understand, IMHO. Either you delete the >> thread from the run() method, or you don't delete it at all. >> >> I's there a way to determine how much memory we leak by not deleting the >> memory owned by the VMThread instance? I'm a bit worried that the >> VMThread might use more resources than the other threads we don't >> delete. > > There is nothing at all special about the VMThread instance, it is > just a NamedThread with nothing being referenced by instance fields > beyond the name. Any runtime resources are released as the thread > terminates - and nothing special there either AFAICS. I was more thinking about the contents of the following memory: Thread::~Thread() { ObjectSynchronizer::omFlush(this); [...] delete resource_area(); [...] delete handle_area(); delete metadata_handles(); The amount of memory that we don't hand back is about 1500 bytes for the VMThread. Most comes from the resource_area(), which is initialized to (init_size = 1*K - slack) in the Thread constructor. The amount of memory doesn't seem to be out-of-the ordinary, so leaking the VMThread doesn't seem to be worse than leaking the other threads, as you said. The patch looks good to me, but you probably want to get a Review by someone well-versed in the HotSpot threading system. Thanks, StefanK > > Thanks, > David > >> Thanks, >> StefanK >> >>> >>> >>> Cosmetic changes: >>> >>> - renamed java_start to thread_native_entry (it is used by all threads >>> not just "java" ones, so this avoids potential confusion) >>> >>> - updated os::free_thread to always assume it works on the current >>> thread (and add assert to verify that) >>> >>> Thanks, >>> David >> From christian.thalinger at oracle.com Tue May 10 19:14:54 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Tue, 10 May 2016 09:14:54 -1000 Subject: [9] RFR(S): 8155608: String intrinsic range checks are not strict enough In-Reply-To: <5731A112.6000608@oracle.com> References: <5721E9C4.7010208@oracle.com> <3E5A7A17-9D61-4C80-A19D-9F510BCAADCE@oracle.com> <57230C0F.7060702@oracle.com> <57307936.20609@oracle.com> <5731A112.6000608@oracle.com> Message-ID: > On May 9, 2016, at 10:51 PM, Tobias Hartmann wrote: > > Hi Chris, > > On 09.05.2016 21:52, Christian Thalinger wrote: >> >>> On May 9, 2016, at 1:49 AM, Tobias Hartmann > wrote: >>> >>> Hi John, >>> >>> thanks for the feedback! >>> >>> On 30.04.2016 02:47, John Rose wrote: >>>> >>>>> On Apr 29, 2016, at 1:00 PM, Christian Thalinger > wrote: >>>>> >>>>> >>>>>> On Apr 28, 2016, at 9:23 PM, Tobias Hartmann > wrote: >>>>>> >>>>>> Hi Chris, >>>>>> >>>>>> On 28.04.2016 22:11, Christian Thalinger wrote: >>>>>>> >>>>>>>> On Apr 28, 2016, at 12:45 AM, Tobias Hartmann > wrote: >>>>>>>> >>>>>>>> Hi >>>>>>>> >>>>>>>> please review the following patch: >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8155608 >>>>>>>> http://cr.openjdk.java.net/~thartmann/8155608/jdk/webrev.00/ >>>>>>> + checkBoundsOffCount(dstOff << 1, len << 1, dst.length); >>>>>>> >>>>>>> It?s funny that we still do << 1 instead of * 2 when every compiler on this planet can optimize that. Yeah, yeah, I know, it?s because of the interpreter but does it really matter? >>>>>> >>>>>> I used it more for consistency because we use "<< 1" in all the other places in StringLatin1, StringUTF16 and String as well. I think this originated from the "value.length >> String.coder()" use case to get the length depending on the String encoding. Besides that, I'm not sure if interpreter speed really matters here but the String methods are executed a lot (especially during startup). >>>>>> >>>>>>> Actually, I would prefer: >>>>>>> >>>>>>> + checkBoundsOffCount(dstOff * Character.BYTES, len * Character.BYTES, dst.length); >>>>>> >>>>>> I agree that this is more readable but for consistency I would like to go with the "<< 1" approach. >>>>> >>>>> Again, a loss for maintainability versus consistency (a.k.a. ?we?ve always done it this way?). >>>> >>>> That '1' is an anti-pattern I call "naked constant". Which "1" is it, after all? >>>> The maintainer of code needs to know which condition (of thousands of possibilities) dictates a "1" here. >>>> In HotSpot we discourage such nakedness, in favor of named constants: >>>> https://wiki.openjdk.java.net/display/HotSpot/StyleGuide#StyleGuide-NamedCons >>>> >>>> The Java code should follow this practice also. >>> >>> Right, I agree. I filed JDK-8156530 [1] to fix this. >>> >>>> Also, independently, I'm having a hard time figuring out how to prove that, between the Java code and the HotSpot intrinsic (and interpreter/C1/C2), the range checking logic is consistently applied. >>>> >>>> My best advice for this is, always, put the range checking logic in one place, in Java code. This makes me profoundly suspicious of *any* public method that is also marked @HSIC, if it takes any array arguments. If the public method is an intrinsic, it means we are trusting C++ IR-assembly code to securely check Java array bounds. That is unnatural, and (as history proves repeatedly) subject to errors. >>> >>> Yes, we had that initially but I had to move some of the checks from the Java code into the intrinsic because of JDK-8142303 (see [2]). >>> >>> I filed JDK-8156534 [3] to check if we can move the checks back into the Java code without problems similar to JDK-8142303. I will also change the implementation of some of the intrinsics with JDK-8139132 and JDK-8146547 and do some refactoring. >>> >>>> Instead, we should have a Java routine which checks bounds, and a *private* intrinsic which is provably called *only after* the Java checker is called. >>> >>> The problem is that some of the intrinsified String methods are heavily used and C2 is not always able to remove the range checks introduced by the public wrapper method. For example, StringUTF16::getChar() is used in places where we implicitly know that the access is in bounds (for example, because the array length is always a multiple of two) but C2 cannot prove this. >> >> Maybe we could sprinkle some Java code to help the compilers. > > Yes, but that only helps if the Java code is compiled which may not be the case if the explicit Java range checks are for example in a different method that is not inlined. Otherwise, there is no way the compiler knows about them. If it?s not compiled than it can?t matter for performance. Also, you have to start thinking in an AOT world. Methods like these are likely AOT compiled and should (almost) never run interpreted. > > Looking at the JDK-8142303 again, it may be sufficient to have the null checks in the intrinsic. Also, we can probably make use of the intrinsified Preconditions.checkIndex(). I'll investigate this with JDK-8156534. > > If there are no objections, I would like to push webrev.00. > > Thanks, > Tobias > >>> Therefore, if we want to avoid a regression, we have to call the unchecked version of the intrinsic in some cases. >>> >>> Thanks, >>> Tobias >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8156530 >>> [2] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-November/019834.html >>> [3] https://bugs.openjdk.java.net/browse/JDK-8156534 >> From kim.barrett at oracle.com Tue May 10 21:33:12 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 10 May 2016 17:33:12 -0400 Subject: RFR: 8146948: Add help information to log tags In-Reply-To: <477fc3a7-85a8-664d-d7f7-796cc4d8c386@oracle.com> References: <570F9F97.4060808@oracle.com> <313004cb-cc55-030f-61ac-abc05b56cc68@oracle.com> <477fc3a7-85a8-664d-d7f7-796cc4d8c386@oracle.com> Message-ID: <8A153A48-640F-495F-94E0-6377205D6BAC@oracle.com> > On May 10, 2016, at 2:57 AM, Marcus Larsson wrote: > > Updated webrev: > http://cr.openjdk.java.net/~mlarsson/8146948/webrev.01/ > > Incremental: > http://cr.openjdk.java.net/~mlarsson/8146948/webrev.00-01/ ------------------------------------------------------------------------------ src/share/vm/logging/logTagSetDescriptions.hpp I'm not sure why the macros are here rather than in the .cpp file. I don't think there's a technical reason to put the descriptions in the header. There might be a consistency of style reason, as other similar macrology in the logging code puts the lists in the headers, but I think in all of the other cases there is a technical necessity for that. If the macros (including the actual descriptions) were moved to the .cpp file, only a forward declaration of LogTagSet would be needed in the header; the include of logTagSet.hpp could be moved to the .cpp too. ------------------------------------------------------------------------------ I'm OK with this change as is, or with the description macros moved as suggested. I've a preference for the latter, assuming there isn't some issue with doing so that I've overlooked. Your call. I don't need a new webrev if you move the macros. From david.holmes at oracle.com Wed May 11 02:17:44 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 11 May 2016 12:17:44 +1000 Subject: RFR: 8154715: Missing destructor and/or TLS clearing calls for terminating threads In-Reply-To: <94D9AA1E-4819-4F99-80DE-C30176FEC926@getsnappy.com> References: <572C4198.3090900@oracle.com> <572CA452.70401@oracle.com> <19147ab9-2480-3ace-6eaf-611eccc29ebf@oracle.com> <572CBB30.1010801@oracle.com> <3fb637e4-0dbe-31d6-2202-574ad3256a95@oracle.com> <55edc3b5-bd68-0e06-8003-bb9bf8093851@oracle.com> <57305896.8020306@oracle.com> <94D9AA1E-4819-4F99-80DE-C30176FEC926@getsnappy.com> Message-ID: <8f72e402-95fa-41c3-e212-c2efeb0b7ce0@oracle.com> On 11/05/2016 6:28 AM, Brian Gardner wrote: > I really like the rename of java_start to native_thread_entry, it makes > things make more sense. It looks like os_bsd.cpp and os_linux.cpp are > both missing the clear_thread_current logic after thread->run(). Doh! Thanks. That's what I get for trying to multi-task :) Webrev updated in place. Can I get another review from someone in hotspot please. Dan is unfortunately (for me) away. Thanks, David > + // If a thread has not deleted itself ("delete this") as part of its > + // termination sequence, we have to ensure thread-local-storage is > + // cleared before we actually terminate. No threads should ever be > + // deleted asynchronously with respect to their termination. > + if (Thread::current_or_null_safe() != NULL) { > + assert(Thread::current_or_null_safe() == thread, "current thread is > wrong"); > + thread->clear_thread_current(); > + } > + > > >> On May 9, 2016, at 5:33 PM, David Holmes > > wrote: >> >> Okay here is version 2: >> >> http://cr.openjdk.java.net/~dholmes/8154715/webrev.v2/ >> >> Lots of cosmetic changes but only a couple of functional ones: >> >> - After thread->run() returns we clear the TLS by calling >> clear_thread_current(), but only for threads where it has not already >> been cleared - as those threads may already have been deleted so we >> can't dereference 'thread' >> >> - No asynchronous thread deletion is permitted, and we avoid races >> with VM termination. This means the VMThread no longer gets deleted - >> that should not be an issue as many threads do not get deleted when >> the VM terminates. I added destructors for the VMThread and >> WatcherThread so anyone introducing their deletion is informed by a >> guarantee(false) >> >> >> Cosmetic changes: >> >> - renamed java_start to thread_native_entry (it is used by all threads >> not just "java" ones, so this avoids potential confusion) >> >> - updated os::free_thread to always assume it works on the current >> thread (and add assert to verify that) >> >> Thanks, >> David > From serguei.spitsyn at oracle.com Wed May 11 03:42:47 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 10 May 2016 20:42:47 -0700 Subject: RFR: 8154715: Missing destructor and/or TLS clearing calls for terminating threads In-Reply-To: <8f72e402-95fa-41c3-e212-c2efeb0b7ce0@oracle.com> References: <572C4198.3090900@oracle.com> <572CA452.70401@oracle.com> <19147ab9-2480-3ace-6eaf-611eccc29ebf@oracle.com> <572CBB30.1010801@oracle.com> <3fb637e4-0dbe-31d6-2202-574ad3256a95@oracle.com> <55edc3b5-bd68-0e06-8003-bb9bf8093851@oracle.com> <57305896.8020306@oracle.com> <94D9AA1E-4819-4F99-80DE-C30176FEC926@getsnappy.com> <8f72e402-95fa-41c3-e212-c2efeb0b7ce0@oracle.com> Message-ID: <5732AA37.2020207@oracle.com> David, It looks good and safe. Is there anything to do for the closed code as well? Thanks, Serguei On 5/10/16 19:17, David Holmes wrote: > On 11/05/2016 6:28 AM, Brian Gardner wrote: >> I really like the rename of java_start to native_thread_entry, it makes >> things make more sense. It looks like os_bsd.cpp and os_linux.cpp are >> both missing the clear_thread_current logic after thread->run(). > > Doh! Thanks. That's what I get for trying to multi-task :) > > Webrev updated in place. > > Can I get another review from someone in hotspot please. Dan is > unfortunately (for me) away. > > Thanks, > David > >> + // If a thread has not deleted itself ("delete this") as part of its >> + // termination sequence, we have to ensure thread-local-storage is >> + // cleared before we actually terminate. No threads should ever be >> + // deleted asynchronously with respect to their termination. >> + if (Thread::current_or_null_safe() != NULL) { >> + assert(Thread::current_or_null_safe() == thread, "current thread is >> wrong"); >> + thread->clear_thread_current(); >> + } >> + >> >> >>> On May 9, 2016, at 5:33 PM, David Holmes >> > wrote: >>> >>> Okay here is version 2: >>> >>> http://cr.openjdk.java.net/~dholmes/8154715/webrev.v2/ >>> >>> Lots of cosmetic changes but only a couple of functional ones: >>> >>> - After thread->run() returns we clear the TLS by calling >>> clear_thread_current(), but only for threads where it has not already >>> been cleared - as those threads may already have been deleted so we >>> can't dereference 'thread' >>> >>> - No asynchronous thread deletion is permitted, and we avoid races >>> with VM termination. This means the VMThread no longer gets deleted - >>> that should not be an issue as many threads do not get deleted when >>> the VM terminates. I added destructors for the VMThread and >>> WatcherThread so anyone introducing their deletion is informed by a >>> guarantee(false) >>> >>> >>> Cosmetic changes: >>> >>> - renamed java_start to thread_native_entry (it is used by all threads >>> not just "java" ones, so this avoids potential confusion) >>> >>> - updated os::free_thread to always assume it works on the current >>> thread (and add assert to verify that) >>> >>> Thanks, >>> David >> From david.holmes at oracle.com Wed May 11 04:41:06 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 11 May 2016 14:41:06 +1000 Subject: RFR(M): 8155949: Support relaxed semantics in cmpxchg In-Reply-To: References: <201605101044.u4AAingb016922@d19av07.sagamino.japan.ibm.com> <8bc82016-81fd-b420-7d4e-1c31e615c218@oracle.com> <1f78facd-2872-2eda-23e2-fd5de0fd8c42@oracle.com> <201605101318.u4ADI0NW004604@d19av05.sagamino.japan.ibm.com> <7a0f80de7788484da6d93f03c3eddd19@DEWDFE13DE14.global.corp.sap> Message-ID: Adding hotspot-dev to cc to expand scope of reviewer pool :) On 11/05/2016 6:56 AM, David Holmes wrote: > On 11/05/2016 12:27 AM, Doerr, Martin wrote: >> Hello everybody, >> >> thanks for finding this issue. New webrev is here: >> >> http://cr.openjdk.java.net/~mdoerr/8155949_relaxed_cas/webrev.02/ > > Unfortunately my test run hit a crash on Solaris sparc: > > # Problematic frame: > # V [libjvm.so+0xcc35c4] > markOopDesc*markOopDesc::displaced_mark_helper()const+0x64 > > I'm going to have to do some more testing to see if that is actually > related to the change. I know it should not be, but given we CAS marks I > have to wonder if there's some subtle bad interaction here. :( Further testing has not shown any failures on Solaris sparc, and the same testing showed some spurious failures on other platforms even without these changes. So while I will file a bug for this crash I think it unlikely to be related to the current changes. So on that note we just need a second hotspot reviewer to sign off on this. Thanks, David > David > ----- > >> >> >> Best regards, >> >> Martin >> >> >> >> *From:*Hiroshi H Horii [mailto:HORII at jp.ibm.com] >> *Sent:* Dienstag, 10. Mai 2016 15:18 >> *To:* David Holmes >> *Cc:* hotspot-gc-dev at openjdk.java.net; >> hotspot-runtime-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; >> Tim Ellison ; Doerr, Martin >> >> *Subject:* Re: RFR(M): 8155949: Support relaxed semantics in cmpxchg >> >> >> >> Hi David, >> >>> Just need another reviewer to chime in - given you and Martin are both >>> contributors. Or are you the main contributor with Martin being a >>> reviewer? >> >> Martin and I are contributors of this change. >> >>> Still a problem on Solaris sparc: >> >> Martin, could you create a new change in webrev with the patch that >> David sent? >> >> Regards, >> Hiroshi >> ----------------------- >> Hiroshi Horii, Ph.D. >> IBM Research - Tokyo >> >> >> David Holmes > >> wrote on 05/10/2016 21:29:53: >> >>> From: David Holmes >> > >>> To: Hiroshi H Horii/Japan/IBM at IBMJP, "hotspot-runtime- >>> dev at openjdk.java.net " >> > > >>> Cc: Tim Ellison >> >, "ppc-aix-port- >>> dev at openjdk.java.net " >> > >, "hotspot- >>> gc-dev at openjdk.java.net " >> > > >>> Date: 05/10/2016 21:31 >>> Subject: Re: RFR(M): 8155949: Support relaxed semantics in cmpxchg >>> >>> On 10/05/2016 9:04 PM, David Holmes wrote: >>> > Hi Hiroshi, >>> > >>> > On 10/05/2016 8:44 PM, Hiroshi H Horii wrote: >>> >> Hi All, >>> >> >>> >> Can I please request reviews for the following change? >>> >> >>> >> Code change: >>> >> http://cr.openjdk.java.net/~mdoerr/8155949_relaxed_cas/webrev.01/ >>> > >>> > Changes look good. I'm currently running them through our internal >>> build >>> > system. I will sponsor this and push the change through JPRT. >>> >>> Still a problem on Solaris sparc: >>> >>> "/opt/jprt/T/P1/102505.daholme/s/hotspot/src/share/vm/runtime/ >>> atomic.inline.hpp", >>> line 96: Error: Could not find a match for static Atomic::cmpxchg(signed >>> char, volatile signed char*, signed char). >>> 1 Error(s) detected. >>> >>> Needs this patch: >>> >>> diff -r 68853ef19be9 src/share/vm/runtime/atomic.inline.hpp >>> --- a/src/share/vm/runtime/atomic.inline.hpp >>> +++ b/src/share/vm/runtime/atomic.inline.hpp >>> @@ -92,7 +92,7 @@ >>> >>> #ifndef VM_HAS_SPECIALIZED_CMPXCHG_BYTE >>> // See comment in atomic.cpp how to override. >>> -inline jbyte Atomic::cmpxchg(jbyte exchange_value, volatile jbyte >>> *dest, jbyte comparand) >>> +inline jbyte Atomic::cmpxchg(jbyte exchange_value, volatile jbyte >>> *dest, jbyte comparand, cmpxchg_memory_order order) >>> { >>> return cmpxchg_general(exchange_value, dest, comparand); >>> } >>> >>> David >>> ----- >>> >>> > Just need another reviewer to chime in - given you and Martin are both >>> > contributors. Or are you the main contributor with Martin being a >>> reviewer? >>> > >>> > Thanks, >>> > David >>> > >>> > PS. It's my night now so I'll be signing off and will pick this up in >>> > the morning. >>> > >>> >> This change follows the discussion started from these mails. >>> >> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016- >>> April/018960.html >>> >> >>> >> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016- >>> April/019148.html >>> >> >>> >> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016- >>> May/019320.html >>> >> >>> >> >>> >> Description: >>> >> This change provides relaxed compare-and-exchange by introducing >>> >> relaxed memory order. As described in atomic_linux_ppc.inline.hpp, >>> >> the current implementation of cmpxchg is fence_cmpxchg_acquire. >>> >> This implementation is useful for general purposes because twice >>> calls of >>> >> sync before and after cmpxchg will provide strict consistency. >>> >> However, they sometimes cause overheads because sync instructions are >>> >> very expensive in the current POWER chip design. >>> >> >>> >> We confirmed this change improves performance of copy_to_survivor >>> >> in the parallel GC. However, we will need more investigation of GC >>> >> by more experts. So, We would like to request a review of the change >>> >> of cmpxchg first (as Martin requested). >>> >> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016- >>> April/019188.html >>> >> >>> >> >>> >> Summary of source code changes: >>> >> >>> >> * src/share/vm/runtime/atomic.hpp >>> >> - Defines enum memory_order and adds a parameter to cmpxchg. >>> >> >>> >> * src/share/vm/runtime/atomic.cpp >>> >> * src/os_cpu/bsd_x86/vm/atomic_bsd_x86.inline.hpp >>> >> * src/os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp >>> >> * src/os_cpu/linux_aarch64/vm/atomic_linux_aarch64.inline.hpp >>> >> * src/os_cpu/linux_sparc/vm/atomic_linux_sparc.inline.hpp >>> >> * src/os_cpu/linux_x86/vm/atomic_linux_x86.inline.hpp >>> >> * src/os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp >>> >> * src/os_cpu/solaris_sparc/vm/atomic_solaris_sparc.inline.hpp >>> >> * src/os_cpu/solaris_x86/vm/atomic_solaris_x86.inline.hpp >>> >> * src/os_cpu/windows_x86/vm/atomic_windows_x86.inline.hpp >>> >> - Added a parameter for each cmpxchg function to follow >>> >> the change of atomic.hpp. Their implementations are not >>> changed. >>> >> >>> >> * src/os_cpu/aix_ppc/vm/atomic_aix_ppc.inline.hpp >>> >> * src/os_cpu/linux_ppc/vm/atomic_linux_ppc.inline.hpp >>> >> - Added a parameter for each cmpxchg function to follow >>> >> the change of atomic.hpp. In addition, implementations >>> >> are changed corresponding to the specified memory_order. >>> >> >>> >> Regards, >>> >> Hiroshi >>> >> ----------------------- >>> >> Hiroshi Horii, Ph.D. >>> >> IBM Research - Tokyo >>> >> >>> >> From david.holmes at oracle.com Wed May 11 04:47:24 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 11 May 2016 14:47:24 +1000 Subject: RFR: 8154715: Missing destructor and/or TLS clearing calls for terminating threads In-Reply-To: <5732AA37.2020207@oracle.com> References: <572C4198.3090900@oracle.com> <572CA452.70401@oracle.com> <19147ab9-2480-3ace-6eaf-611eccc29ebf@oracle.com> <572CBB30.1010801@oracle.com> <3fb637e4-0dbe-31d6-2202-574ad3256a95@oracle.com> <55edc3b5-bd68-0e06-8003-bb9bf8093851@oracle.com> <57305896.8020306@oracle.com> <94D9AA1E-4819-4F99-80DE-C30176FEC926@getsnappy.com> <8f72e402-95fa-41c3-e212-c2efeb0b7ce0@oracle.com> <5732AA37.2020207@oracle.com> Message-ID: On 11/05/2016 1:42 PM, serguei.spitsyn at oracle.com wrote: > David, > > It looks good and safe. Thanks Serguei! > Is there anything to do for the closed code as well? No. David > Thanks, > Serguei > > > On 5/10/16 19:17, David Holmes wrote: >> On 11/05/2016 6:28 AM, Brian Gardner wrote: >>> I really like the rename of java_start to native_thread_entry, it makes >>> things make more sense. It looks like os_bsd.cpp and os_linux.cpp are >>> both missing the clear_thread_current logic after thread->run(). >> >> Doh! Thanks. That's what I get for trying to multi-task :) >> >> Webrev updated in place. >> >> Can I get another review from someone in hotspot please. Dan is >> unfortunately (for me) away. >> >> Thanks, >> David >> >>> + // If a thread has not deleted itself ("delete this") as part of its >>> + // termination sequence, we have to ensure thread-local-storage is >>> + // cleared before we actually terminate. No threads should ever be >>> + // deleted asynchronously with respect to their termination. >>> + if (Thread::current_or_null_safe() != NULL) { >>> + assert(Thread::current_or_null_safe() == thread, "current thread is >>> wrong"); >>> + thread->clear_thread_current(); >>> + } >>> + >>> >>> >>>> On May 9, 2016, at 5:33 PM, David Holmes >>> > wrote: >>>> >>>> Okay here is version 2: >>>> >>>> http://cr.openjdk.java.net/~dholmes/8154715/webrev.v2/ >>>> >>>> Lots of cosmetic changes but only a couple of functional ones: >>>> >>>> - After thread->run() returns we clear the TLS by calling >>>> clear_thread_current(), but only for threads where it has not already >>>> been cleared - as those threads may already have been deleted so we >>>> can't dereference 'thread' >>>> >>>> - No asynchronous thread deletion is permitted, and we avoid races >>>> with VM termination. This means the VMThread no longer gets deleted - >>>> that should not be an issue as many threads do not get deleted when >>>> the VM terminates. I added destructors for the VMThread and >>>> WatcherThread so anyone introducing their deletion is informed by a >>>> guarantee(false) >>>> >>>> >>>> Cosmetic changes: >>>> >>>> - renamed java_start to thread_native_entry (it is used by all threads >>>> not just "java" ones, so this avoids potential confusion) >>>> >>>> - updated os::free_thread to always assume it works on the current >>>> thread (and add assert to verify that) >>>> >>>> Thanks, >>>> David >>> > From serguei.spitsyn at oracle.com Wed May 11 05:30:22 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 10 May 2016 22:30:22 -0700 Subject: RFR: 8154715: Missing destructor and/or TLS clearing calls for terminating threads In-Reply-To: References: <572C4198.3090900@oracle.com> <572CA452.70401@oracle.com> <19147ab9-2480-3ace-6eaf-611eccc29ebf@oracle.com> <572CBB30.1010801@oracle.com> <3fb637e4-0dbe-31d6-2202-574ad3256a95@oracle.com> <55edc3b5-bd68-0e06-8003-bb9bf8093851@oracle.com> <57305896.8020306@oracle.com> <94D9AA1E-4819-4F99-80DE-C30176FEC926@getsnappy.com> <8f72e402-95fa-41c3-e212-c2efeb0b7ce0@oracle.com> <5732AA37.2020207@oracle.com> Message-ID: <5732C36E.2010505@oracle.com> On 5/10/16 21:47, David Holmes wrote: > On 11/05/2016 1:42 PM, serguei.spitsyn at oracle.com wrote: >> David, >> >> It looks good and safe. > > Thanks Serguei! > >> Is there anything to do for the closed code as well? > > No. Ok. Thanks, Serguei > > David > >> Thanks, >> Serguei >> >> >> On 5/10/16 19:17, David Holmes wrote: >>> On 11/05/2016 6:28 AM, Brian Gardner wrote: >>>> I really like the rename of java_start to native_thread_entry, it >>>> makes >>>> things make more sense. It looks like os_bsd.cpp and os_linux.cpp are >>>> both missing the clear_thread_current logic after thread->run(). >>> >>> Doh! Thanks. That's what I get for trying to multi-task :) >>> >>> Webrev updated in place. >>> >>> Can I get another review from someone in hotspot please. Dan is >>> unfortunately (for me) away. >>> >>> Thanks, >>> David >>> >>>> + // If a thread has not deleted itself ("delete this") as part of its >>>> + // termination sequence, we have to ensure thread-local-storage is >>>> + // cleared before we actually terminate. No threads should ever be >>>> + // deleted asynchronously with respect to their termination. >>>> + if (Thread::current_or_null_safe() != NULL) { >>>> + assert(Thread::current_or_null_safe() == thread, "current thread is >>>> wrong"); >>>> + thread->clear_thread_current(); >>>> + } >>>> + >>>> >>>> >>>>> On May 9, 2016, at 5:33 PM, David Holmes >>>> > wrote: >>>>> >>>>> Okay here is version 2: >>>>> >>>>> http://cr.openjdk.java.net/~dholmes/8154715/webrev.v2/ >>>>> >>>>> Lots of cosmetic changes but only a couple of functional ones: >>>>> >>>>> - After thread->run() returns we clear the TLS by calling >>>>> clear_thread_current(), but only for threads where it has not already >>>>> been cleared - as those threads may already have been deleted so we >>>>> can't dereference 'thread' >>>>> >>>>> - No asynchronous thread deletion is permitted, and we avoid races >>>>> with VM termination. This means the VMThread no longer gets deleted - >>>>> that should not be an issue as many threads do not get deleted when >>>>> the VM terminates. I added destructors for the VMThread and >>>>> WatcherThread so anyone introducing their deletion is informed by a >>>>> guarantee(false) >>>>> >>>>> >>>>> Cosmetic changes: >>>>> >>>>> - renamed java_start to thread_native_entry (it is used by all >>>>> threads >>>>> not just "java" ones, so this avoids potential confusion) >>>>> >>>>> - updated os::free_thread to always assume it works on the current >>>>> thread (and add assert to verify that) >>>>> >>>>> Thanks, >>>>> David >>>> >> From david.holmes at oracle.com Wed May 11 05:50:09 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 11 May 2016 15:50:09 +1000 Subject: Urgent trivial RFR: 8156689: [TESTBUG] runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java disable range testing of Allocate*PrefetchLines Message-ID: <49f22e17-0c01-a58a-9fd3-1e791539373a@oracle.com> webrev: http://cr.openjdk.java.net/~dholmes/8156689/webrev/ and patch below. Bug is not public. JDK-8153340 has introduced failures in the range constraint checking for the Allocate*PrefetchLines flags on some platforms. So we exclude those flags from the range test until the underlying issue (JDK-8156679) is resolved. This will be pushed, under the "trivial change" rule as soon as I have one Reviewer. Thanks, David --- --- old/test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java Wed May 11 01:40:32 2016 +++ new/test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java Wed May 11 01:40:31 2016 @@ -90,6 +90,14 @@ excludeTestMaxRange("CICompilerCount"); /* + * JDK-8156679 + * Temporarily exclude from range testing as the range is not + * valid for all platforms + */ + excludeTestRange("AllocatePrefetchLines"); + excludeTestRange("AllocateInstancePrefetchLines"); + + /* From vladimir.kozlov at oracle.com Wed May 11 06:16:56 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 10 May 2016 23:16:56 -0700 Subject: Urgent trivial RFR: 8156689: [TESTBUG] runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java disable range testing of Allocate*PrefetchLines In-Reply-To: <49f22e17-0c01-a58a-9fd3-1e791539373a@oracle.com> References: <49f22e17-0c01-a58a-9fd3-1e791539373a@oracle.com> Message-ID: <82fc2224-8049-fcfc-4253-f70916d978f2@oracle.com> Looks good. Thanks, Vladimir On 5/10/16 10:50 PM, David Holmes wrote: > webrev: http://cr.openjdk.java.net/~dholmes/8156689/webrev/ > > and patch below. > > Bug is not public. > > JDK-8153340 has introduced failures in the range constraint checking for the Allocate*PrefetchLines flags on some > platforms. So we exclude those flags from the range test until the underlying issue (JDK-8156679) is resolved. > > This will be pushed, under the "trivial change" rule as soon as I have one Reviewer. > > Thanks, > David > --- > > --- old/test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java Wed May 11 01:40:32 2016 > +++ new/test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java Wed May 11 01:40:31 2016 > @@ -90,6 +90,14 @@ > excludeTestMaxRange("CICompilerCount"); > > /* > + * JDK-8156679 > + * Temporarily exclude from range testing as the range is not > + * valid for all platforms > + */ > + excludeTestRange("AllocatePrefetchLines"); > + excludeTestRange("AllocateInstancePrefetchLines"); > + > + /* From david.holmes at oracle.com Wed May 11 06:27:23 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 11 May 2016 16:27:23 +1000 Subject: Urgent trivial RFR: 8156689: [TESTBUG] runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java disable range testing of Allocate*PrefetchLines In-Reply-To: <82fc2224-8049-fcfc-4253-f70916d978f2@oracle.com> References: <49f22e17-0c01-a58a-9fd3-1e791539373a@oracle.com> <82fc2224-8049-fcfc-4253-f70916d978f2@oracle.com> Message-ID: Thanks Vladimir! David On 11/05/2016 4:16 PM, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 5/10/16 10:50 PM, David Holmes wrote: >> webrev: http://cr.openjdk.java.net/~dholmes/8156689/webrev/ >> >> and patch below. >> >> Bug is not public. >> >> JDK-8153340 has introduced failures in the range constraint checking >> for the Allocate*PrefetchLines flags on some >> platforms. So we exclude those flags from the range test until the >> underlying issue (JDK-8156679) is resolved. >> >> This will be pushed, under the "trivial change" rule as soon as I have >> one Reviewer. >> >> Thanks, >> David >> --- >> >> --- >> old/test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java >> Wed May 11 01:40:32 2016 >> +++ >> new/test/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java >> Wed May 11 01:40:31 2016 >> @@ -90,6 +90,14 @@ >> excludeTestMaxRange("CICompilerCount"); >> >> /* >> + * JDK-8156679 >> + * Temporarily exclude from range testing as the range is not >> + * valid for all platforms >> + */ >> + excludeTestRange("AllocatePrefetchLines"); >> + excludeTestRange("AllocateInstancePrefetchLines"); >> + >> + /* From tobias.hartmann at oracle.com Wed May 11 06:33:46 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 11 May 2016 08:33:46 +0200 Subject: [9] RFR(S): 8155608: String intrinsic range checks are not strict enough In-Reply-To: References: <5721E9C4.7010208@oracle.com> <3E5A7A17-9D61-4C80-A19D-9F510BCAADCE@oracle.com> <57230C0F.7060702@oracle.com> <57307936.20609@oracle.com> <5731A112.6000608@oracle.com> Message-ID: <5732D24A.9030201@oracle.com> On 10.05.2016 21:14, Christian Thalinger wrote: > >> On May 9, 2016, at 10:51 PM, Tobias Hartmann wrote: >> >> Hi Chris, >> >> On 09.05.2016 21:52, Christian Thalinger wrote: >>> >>>> On May 9, 2016, at 1:49 AM, Tobias Hartmann > wrote: >>>> >>>> Hi John, >>>> >>>> thanks for the feedback! >>>> >>>> On 30.04.2016 02:47, John Rose wrote: >>>>> >>>>>> On Apr 29, 2016, at 1:00 PM, Christian Thalinger > wrote: >>>>>> >>>>>> >>>>>>> On Apr 28, 2016, at 9:23 PM, Tobias Hartmann > wrote: >>>>>>> >>>>>>> Hi Chris, >>>>>>> >>>>>>> On 28.04.2016 22:11, Christian Thalinger wrote: >>>>>>>> >>>>>>>>> On Apr 28, 2016, at 12:45 AM, Tobias Hartmann > wrote: >>>>>>>>> >>>>>>>>> Hi >>>>>>>>> >>>>>>>>> please review the following patch: >>>>>>>>> >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8155608 >>>>>>>>> http://cr.openjdk.java.net/~thartmann/8155608/jdk/webrev.00/ >>>>>>>> + checkBoundsOffCount(dstOff << 1, len << 1, dst.length); >>>>>>>> >>>>>>>> It?s funny that we still do << 1 instead of * 2 when every compiler on this planet can optimize that. Yeah, yeah, I know, it?s because of the interpreter but does it really matter? >>>>>>> >>>>>>> I used it more for consistency because we use "<< 1" in all the other places in StringLatin1, StringUTF16 and String as well. I think this originated from the "value.length >> String.coder()" use case to get the length depending on the String encoding. Besides that, I'm not sure if interpreter speed really matters here but the String methods are executed a lot (especially during startup). >>>>>>> >>>>>>>> Actually, I would prefer: >>>>>>>> >>>>>>>> + checkBoundsOffCount(dstOff * Character.BYTES, len * Character.BYTES, dst.length); >>>>>>> >>>>>>> I agree that this is more readable but for consistency I would like to go with the "<< 1" approach. >>>>>> >>>>>> Again, a loss for maintainability versus consistency (a.k.a. ?we?ve always done it this way?). >>>>> >>>>> That '1' is an anti-pattern I call "naked constant". Which "1" is it, after all? >>>>> The maintainer of code needs to know which condition (of thousands of possibilities) dictates a "1" here. >>>>> In HotSpot we discourage such nakedness, in favor of named constants: >>>>> https://wiki.openjdk.java.net/display/HotSpot/StyleGuide#StyleGuide-NamedCons >>>>> >>>>> The Java code should follow this practice also. >>>> >>>> Right, I agree. I filed JDK-8156530 [1] to fix this. >>>> >>>>> Also, independently, I'm having a hard time figuring out how to prove that, between the Java code and the HotSpot intrinsic (and interpreter/C1/C2), the range checking logic is consistently applied. >>>>> >>>>> My best advice for this is, always, put the range checking logic in one place, in Java code. This makes me profoundly suspicious of *any* public method that is also marked @HSIC, if it takes any array arguments. If the public method is an intrinsic, it means we are trusting C++ IR-assembly code to securely check Java array bounds. That is unnatural, and (as history proves repeatedly) subject to errors. >>>> >>>> Yes, we had that initially but I had to move some of the checks from the Java code into the intrinsic because of JDK-8142303 (see [2]). >>>> >>>> I filed JDK-8156534 [3] to check if we can move the checks back into the Java code without problems similar to JDK-8142303. I will also change the implementation of some of the intrinsics with JDK-8139132 and JDK-8146547 and do some refactoring. >>>> >>>>> Instead, we should have a Java routine which checks bounds, and a *private* intrinsic which is provably called *only after* the Java checker is called. >>>> >>>> The problem is that some of the intrinsified String methods are heavily used and C2 is not always able to remove the range checks introduced by the public wrapper method. For example, StringUTF16::getChar() is used in places where we implicitly know that the access is in bounds (for example, because the array length is always a multiple of two) but C2 cannot prove this. >>> >>> Maybe we could sprinkle some Java code to help the compilers. >> >> Yes, but that only helps if the Java code is compiled which may not be the case if the explicit Java range checks are for example in a different method that is not inlined. Otherwise, there is no way the compiler knows about them. > > If it?s not compiled than it can?t matter for performance. Also, you have to start thinking in an AOT world. Methods like these are likely AOT compiled and should (almost) never run interpreted. Sorry, I thought you were referring to the "correctness case" mentioned above, where C2 does not know about a range check because it's not inlined. Yes, it may help for some cases to add additional Java code to guide C2's optimizations, I'll investigate this with JDK-8156534. Best regards, Tobias >> Looking at the JDK-8142303 again, it may be sufficient to have the null checks in the intrinsic. Also, we can probably make use of the intrinsified Preconditions.checkIndex(). I'll investigate this with JDK-8156534. >> >> If there are no objections, I would like to push webrev.00. >> >> Thanks, >> Tobias >> >>>> Therefore, if we want to avoid a regression, we have to call the unchecked version of the intrinsic in some cases. >>>> >>>> Thanks, >>>> Tobias >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8156530 >>>> [2] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-November/019834.html >>>> [3] https://bugs.openjdk.java.net/browse/JDK-8156534 >>> > From marcus.larsson at oracle.com Wed May 11 08:40:28 2016 From: marcus.larsson at oracle.com (Marcus Larsson) Date: Wed, 11 May 2016 10:40:28 +0200 Subject: RFR: 8146948: Add help information to log tags In-Reply-To: <8A153A48-640F-495F-94E0-6377205D6BAC@oracle.com> References: <570F9F97.4060808@oracle.com> <313004cb-cc55-030f-61ac-abc05b56cc68@oracle.com> <477fc3a7-85a8-664d-d7f7-796cc4d8c386@oracle.com> <8A153A48-640F-495F-94E0-6377205D6BAC@oracle.com> Message-ID: <6263e60c-a604-6597-6d2a-27965c85409f@oracle.com> On 05/10/2016 11:33 PM, Kim Barrett wrote: >> On May 10, 2016, at 2:57 AM, Marcus Larsson wrote: >> >> Updated webrev: >> http://cr.openjdk.java.net/~mlarsson/8146948/webrev.01/ >> >> Incremental: >> http://cr.openjdk.java.net/~mlarsson/8146948/webrev.00-01/ > ------------------------------------------------------------------------------ > src/share/vm/logging/logTagSetDescriptions.hpp > > I'm not sure why the macros are here rather than in the .cpp file. I > don't think there's a technical reason to put the descriptions in the > header. There might be a consistency of style reason, as other > similar macrology in the logging code puts the lists in the headers, > but I think in all of the other cases there is a technical necessity > for that. > > If the macros (including the actual descriptions) were moved to the > .cpp file, only a forward declaration of LogTagSet would be needed in > the header; the include of logTagSet.hpp could be moved to the .cpp > too. Good point. I just went with the pattern without really considering the alternative. I like your suggestion better. It also prevents the macros from leaking. > ------------------------------------------------------------------------------ > > I'm OK with this change as is, or with the description macros moved as > suggested. I've a preference for the latter, assuming there isn't > some issue with doing so that I've overlooked. Your call. I don't > need a new webrev if you move the macros. I'll move the macros. Thank you for reviewing! Marcus From coleen.phillimore at oracle.com Wed May 11 11:39:51 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 11 May 2016 07:39:51 -0400 Subject: RFR: 8154715: Missing destructor and/or TLS clearing calls for terminating threads In-Reply-To: <8f72e402-95fa-41c3-e212-c2efeb0b7ce0@oracle.com> References: <572C4198.3090900@oracle.com> <572CA452.70401@oracle.com> <19147ab9-2480-3ace-6eaf-611eccc29ebf@oracle.com> <572CBB30.1010801@oracle.com> <3fb637e4-0dbe-31d6-2202-574ad3256a95@oracle.com> <55edc3b5-bd68-0e06-8003-bb9bf8093851@oracle.com> <57305896.8020306@oracle.com> <94D9AA1E-4819-4F99-80DE-C30176FEC926@getsnappy.com> <8f72e402-95fa-41c3-e212-c2efeb0b7ce0@oracle.com> Message-ID: <676b04c3-e5d4-3e73-a393-db91b42f02ba@oracle.com> Hi David, I am not a reviewer because I haven't read the whole thread and you have enough reviewers, but is thread_native_entry duplicated on all the xnix platforms? Could this be a future cleanup? thanks, Coleen On 5/10/16 10:17 PM, David Holmes wrote: > On 11/05/2016 6:28 AM, Brian Gardner wrote: >> I really like the rename of java_start to native_thread_entry, it makes >> things make more sense. It looks like os_bsd.cpp and os_linux.cpp are >> both missing the clear_thread_current logic after thread->run(). > > Doh! Thanks. That's what I get for trying to multi-task :) > > Webrev updated in place. > > Can I get another review from someone in hotspot please. Dan is > unfortunately (for me) away. > > Thanks, > David > >> + // If a thread has not deleted itself ("delete this") as part of its >> + // termination sequence, we have to ensure thread-local-storage is >> + // cleared before we actually terminate. No threads should ever be >> + // deleted asynchronously with respect to their termination. >> + if (Thread::current_or_null_safe() != NULL) { >> + assert(Thread::current_or_null_safe() == thread, "current thread is >> wrong"); >> + thread->clear_thread_current(); >> + } >> + >> >> >>> On May 9, 2016, at 5:33 PM, David Holmes >> > wrote: >>> >>> Okay here is version 2: >>> >>> http://cr.openjdk.java.net/~dholmes/8154715/webrev.v2/ >>> >>> Lots of cosmetic changes but only a couple of functional ones: >>> >>> - After thread->run() returns we clear the TLS by calling >>> clear_thread_current(), but only for threads where it has not already >>> been cleared - as those threads may already have been deleted so we >>> can't dereference 'thread' >>> >>> - No asynchronous thread deletion is permitted, and we avoid races >>> with VM termination. This means the VMThread no longer gets deleted - >>> that should not be an issue as many threads do not get deleted when >>> the VM terminates. I added destructors for the VMThread and >>> WatcherThread so anyone introducing their deletion is informed by a >>> guarantee(false) >>> >>> >>> Cosmetic changes: >>> >>> - renamed java_start to thread_native_entry (it is used by all threads >>> not just "java" ones, so this avoids potential confusion) >>> >>> - updated os::free_thread to always assume it works on the current >>> thread (and add assert to verify that) >>> >>> Thanks, >>> David >> From openjdk at getsnappy.com Tue May 10 20:28:32 2016 From: openjdk at getsnappy.com (Brian Gardner) Date: Tue, 10 May 2016 13:28:32 -0700 Subject: RFR: 8154715: Missing destructor and/or TLS clearing calls for terminating threads In-Reply-To: References: <572C4198.3090900@oracle.com> <572CA452.70401@oracle.com> <19147ab9-2480-3ace-6eaf-611eccc29ebf@oracle.com> <572CBB30.1010801@oracle.com> <3fb637e4-0dbe-31d6-2202-574ad3256a95@oracle.com> <55edc3b5-bd68-0e06-8003-bb9bf8093851@oracle.com> <57305896.8020306@oracle.com> Message-ID: <94D9AA1E-4819-4F99-80DE-C30176FEC926@getsnappy.com> I really like the rename of java_start to native_thread_entry, it makes things make more sense. It looks like os_bsd.cpp and os_linux.cpp are both missing the clear_thread_current logic after thread->run(). + // If a thread has not deleted itself ("delete this") as part of its + // termination sequence, we have to ensure thread-local-storage is + // cleared before we actually terminate. No threads should ever be + // deleted asynchronously with respect to their termination. + if (Thread::current_or_null_safe() != NULL) { + assert(Thread::current_or_null_safe() == thread, "current thread is wrong"); + thread->clear_thread_current(); + } + > On May 9, 2016, at 5:33 PM, David Holmes wrote: > > Okay here is version 2: > > http://cr.openjdk.java.net/~dholmes/8154715/webrev.v2/ > > Lots of cosmetic changes but only a couple of functional ones: > > - After thread->run() returns we clear the TLS by calling clear_thread_current(), but only for threads where it has not already been cleared - as those threads may already have been deleted so we can't dereference 'thread' > > - No asynchronous thread deletion is permitted, and we avoid races with VM termination. This means the VMThread no longer gets deleted - that should not be an issue as many threads do not get deleted when the VM terminates. I added destructors for the VMThread and WatcherThread so anyone introducing their deletion is informed by a guarantee(false) > > > Cosmetic changes: > > - renamed java_start to thread_native_entry (it is used by all threads not just "java" ones, so this avoids potential confusion) > > - updated os::free_thread to always assume it works on the current thread (and add assert to verify that) > > Thanks, > David From david.holmes at oracle.com Wed May 11 21:00:40 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 12 May 2016 07:00:40 +1000 Subject: RFR: 8154715: Missing destructor and/or TLS clearing calls for terminating threads In-Reply-To: <676b04c3-e5d4-3e73-a393-db91b42f02ba@oracle.com> References: <572C4198.3090900@oracle.com> <572CA452.70401@oracle.com> <19147ab9-2480-3ace-6eaf-611eccc29ebf@oracle.com> <572CBB30.1010801@oracle.com> <3fb637e4-0dbe-31d6-2202-574ad3256a95@oracle.com> <55edc3b5-bd68-0e06-8003-bb9bf8093851@oracle.com> <57305896.8020306@oracle.com> <94D9AA1E-4819-4F99-80DE-C30176FEC926@getsnappy.com> <8f72e402-95fa-41c3-e212-c2efeb0b7ce0@oracle.com> <676b04c3-e5d4-3e73-a393-db91b42f02ba@oracle.com> Message-ID: <5fe5deed-5082-7133-dc76-fd81bd6e1c56@oracle.com> Hi Coleen, On 11/05/2016 9:39 PM, Coleen Phillimore wrote: > > Hi David, > I am not a reviewer because I haven't read the whole thread and you have > enough reviewers, but is thread_native_entry duplicated on all the xnix > platforms? Could this be a future cleanup? It is not exactly duplicated, but of course shares a great deal of commonality. The differences, if really needed, could be factored out. I would lump it in with the "great OS Posix refactoring" that never quite seems to happen (and the Solaris thr_* to pthread_* conversion that slowly happens). Cheers, David > thanks, > Coleen > > On 5/10/16 10:17 PM, David Holmes wrote: >> On 11/05/2016 6:28 AM, Brian Gardner wrote: >>> I really like the rename of java_start to native_thread_entry, it makes >>> things make more sense. It looks like os_bsd.cpp and os_linux.cpp are >>> both missing the clear_thread_current logic after thread->run(). >> >> Doh! Thanks. That's what I get for trying to multi-task :) >> >> Webrev updated in place. >> >> Can I get another review from someone in hotspot please. Dan is >> unfortunately (for me) away. >> >> Thanks, >> David >> >>> + // If a thread has not deleted itself ("delete this") as part of its >>> + // termination sequence, we have to ensure thread-local-storage is >>> + // cleared before we actually terminate. No threads should ever be >>> + // deleted asynchronously with respect to their termination. >>> + if (Thread::current_or_null_safe() != NULL) { >>> + assert(Thread::current_or_null_safe() == thread, "current thread is >>> wrong"); >>> + thread->clear_thread_current(); >>> + } >>> + >>> >>> >>>> On May 9, 2016, at 5:33 PM, David Holmes >>> > wrote: >>>> >>>> Okay here is version 2: >>>> >>>> http://cr.openjdk.java.net/~dholmes/8154715/webrev.v2/ >>>> >>>> Lots of cosmetic changes but only a couple of functional ones: >>>> >>>> - After thread->run() returns we clear the TLS by calling >>>> clear_thread_current(), but only for threads where it has not already >>>> been cleared - as those threads may already have been deleted so we >>>> can't dereference 'thread' >>>> >>>> - No asynchronous thread deletion is permitted, and we avoid races >>>> with VM termination. This means the VMThread no longer gets deleted - >>>> that should not be an issue as many threads do not get deleted when >>>> the VM terminates. I added destructors for the VMThread and >>>> WatcherThread so anyone introducing their deletion is informed by a >>>> guarantee(false) >>>> >>>> >>>> Cosmetic changes: >>>> >>>> - renamed java_start to thread_native_entry (it is used by all threads >>>> not just "java" ones, so this avoids potential confusion) >>>> >>>> - updated os::free_thread to always assume it works on the current >>>> thread (and add assert to verify that) >>>> >>>> Thanks, >>>> David >>> > From david.lloyd at redhat.com Wed May 11 21:05:51 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Wed, 11 May 2016 16:05:51 -0500 Subject: RFR: 8154715: Missing destructor and/or TLS clearing calls for terminating threads In-Reply-To: <5fe5deed-5082-7133-dc76-fd81bd6e1c56@oracle.com> References: <572C4198.3090900@oracle.com> <572CA452.70401@oracle.com> <19147ab9-2480-3ace-6eaf-611eccc29ebf@oracle.com> <572CBB30.1010801@oracle.com> <3fb637e4-0dbe-31d6-2202-574ad3256a95@oracle.com> <55edc3b5-bd68-0e06-8003-bb9bf8093851@oracle.com> <57305896.8020306@oracle.com> <94D9AA1E-4819-4F99-80DE-C30176FEC926@getsnappy.com> <8f72e402-95fa-41c3-e212-c2efeb0b7ce0@oracle.com> <676b04c3-e5d4-3e73-a393-db91b42f02ba@oracle.com> <5fe5deed-5082-7133-dc76-fd81bd6e1c56@oracle.com> Message-ID: <57339EAF.6070805@redhat.com> On 05/11/2016 04:00 PM, David Holmes wrote: > Hi Coleen, > > On 11/05/2016 9:39 PM, Coleen Phillimore wrote: >> >> Hi David, >> I am not a reviewer because I haven't read the whole thread and you have >> enough reviewers, but is thread_native_entry duplicated on all the xnix >> platforms? Could this be a future cleanup? > > It is not exactly duplicated, but of course shares a great deal of > commonality. The differences, if really needed, could be factored out. I > would lump it in with the "great OS Posix refactoring" that never quite > seems to happen (and the Solaris thr_* to pthread_* conversion that > slowly happens). It'll all be done just in time to start moving to C/C++11 threads. -- - DML From gromero at linux.vnet.ibm.com Wed May 11 21:06:41 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Wed, 11 May 2016 18:06:41 -0300 Subject: PPC64 VSX load/store instructions in stubs In-Reply-To: References: <56FEDBB3.5030106@linux.vnet.ibm.com> Message-ID: <57339EE1.2040500@linux.vnet.ibm.com> Hi Volker, Hi Martin Sincere apologies for the long delay. My initial approach to test the VSX load/store was from an extracted snippet regarding just the mass copy loop "grafted" inside an inline asm, performing isolated tests with "perf" tool focused only on aligned source and destination (best case). The extracted code, called "Original" in the plot below (black line), is here: https://github.com/gromero/arraycopy/blob/2pairs/arraycopy.c#L27-L36 That extracted, after some experiments, evolved into this one that employs VSX load/store, Data Stream deepest pre-fetch, d-cache touch, and backbranch aligned to 32-byte: https://github.com/gromero/arraycopy/blob/2pairs/arraycopy_vsx.c#L27-L41 All runs where "pinned" using `numactl --cpunodebind --membind` to avoid any scheduler decision that could add noise to the measure. VSX, deepest data pre-fetch, d-cache touch, and 32-bytes align proved to be better in the isolated code (red line) in comparison to the original extracted code (black line): http://gromero.github.io/openjdk/original_vsx_non_pf_vsx_pf_deepest.pdf So I proceeded to implement the VSX loop in OpenJDK based on the best case result (VSX, pre-fetch deepest, d-cache touch, and backbranch target align - goetz TODO note). OpenJDK 8 webrev: http://81.de.7a9f.ip4.static.sl-reverse.com/8154156/8/ OpenJDK 9 webrev: http://81.de.7a9f.ip4.static.sl-reverse.com/8154156/9/ I've tested the change on OpenJDK 8 using this script that calls System.arraycopy() on shorts: https://goo.gl/8UWtLm The results for all data alignment cases: http://gromero.github.io/openjdk/src_0_dst_0.pdf http://gromero.github.io/openjdk/src_1_dst_0.pdf http://gromero.github.io/openjdk/src_0_dst_1.pdf http://gromero.github.io/openjdk/src_1_dst_1.pdf Martin, I added the vsx test to the feature-string. Regarding the ABI, I'm just using two VSR: vsr0 and vsr1, both volatile. Volker, as the loop unrolling was removed now the loop copies 16 elemets a time, like the non-VSX loop, and not 32 elements. I just verified the change on Little endian. Sorry I didn't understand your question regarding "instructions for aligned load/stores". Did you mean instructions for unaligned load/stores? I think both fixed-point (ld/std) and VSX instructions will do load/store slower in unaligned scenario. However VMX load/store is different and expects aligned operands. Thank you very much for opening the bug https://bugs.openjdk.java.net/browse/JDK-8154156 I don't have the profiling per function for each SPEC{jbb,jvm} benchmark in order to determine which one would stress the proposed change better. Could I use a better benchmark? Thank you! Best regards, Gustavo On 05-04-2016 14:23, Volker Simonis wrote: > Hi Gustavo, > > thanks a lot for your contribution. > > Can you please describe if you've run benchmarks and which performance > improvements you saw? > > With your change if we're running on Power 8, we will only use the > fast path for arrays with at least 32 elements. For smaller arrays, we > will fall-back to copying only 2 elements at a time which will be > slower than the initial version which copied 4 at a time in that case. > > Did you verified your changes on both, little and big endian? > > And what about unaligned memory accesses? As far as I read, > lxvd2x/stxvd2x still work, but may be slower. I saw there also exist > instructions for aligned load/stores. Would it make sens > (performance-wise) to use them for the cases where we can be sure that > we have aligned memory accesses? > > Thank you and best regards, > Volker > > > On Fri, Apr 1, 2016 at 10:36 PM, Gustavo Romero > wrote: >> Hi Martin, Hi Volker >> >> Currently VSX load/store instructions are not being used in PPC64 stubs, >> particularly in arraycopy stubs inside generate_arraycopy_stubs() like, >> but not limited to, generate_disjoint_{byte,short,int,long}_copy. >> >> We can speed up mass copy using VSX (Vector-Scalar Extension) load/store >> instruction in processors >= POWER8, the same way it's already done for >> libc memcpy(). >> >> This is an initial patch just for jshort_disjoint_arraycopy() VSX vector >> load/store: >> >> http://81.de.7a9f.ip4.static.sl-reverse.com/202539/webrev >> >> What are your thoughts on that? Is there any impediment to use VSX >> instructions in OpenJDK at the moment? >> >> Thank you. >> >> Best regards, >> Gustavo >> > From coleen.phillimore at oracle.com Wed May 11 21:10:05 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Wed, 11 May 2016 17:10:05 -0400 Subject: RFR: 8154715: Missing destructor and/or TLS clearing calls for terminating threads In-Reply-To: <57339EAF.6070805@redhat.com> References: <572C4198.3090900@oracle.com> <572CA452.70401@oracle.com> <19147ab9-2480-3ace-6eaf-611eccc29ebf@oracle.com> <572CBB30.1010801@oracle.com> <3fb637e4-0dbe-31d6-2202-574ad3256a95@oracle.com> <55edc3b5-bd68-0e06-8003-bb9bf8093851@oracle.com> <57305896.8020306@oracle.com> <94D9AA1E-4819-4F99-80DE-C30176FEC926@getsnappy.com> <8f72e402-95fa-41c3-e212-c2efeb0b7ce0@oracle.com> <676b04c3-e5d4-3e73-a393-db91b42f02ba@oracle.com> <5fe5deed-5082-7133-dc76-fd81bd6e1c56@oracle.com> <57339EAF.6070805@redhat.com> Message-ID: <339e4246-e0c8-9aff-2cdb-672baac01d13@oracle.com> On 5/11/16 5:05 PM, David M. Lloyd wrote: > On 05/11/2016 04:00 PM, David Holmes wrote: >> Hi Coleen, >> >> On 11/05/2016 9:39 PM, Coleen Phillimore wrote: >>> >>> Hi David, >>> I am not a reviewer because I haven't read the whole thread and you >>> have >>> enough reviewers, but is thread_native_entry duplicated on all the xnix >>> platforms? Could this be a future cleanup? >> >> It is not exactly duplicated, but of course shares a great deal of >> commonality. The differences, if really needed, could be factored out. I >> would lump it in with the "great OS Posix refactoring" that never quite I looked at the os_ code and while there's commonality, there wasn't enough to lump it in one big task together. And that's the kind of thing that will never get done. Kim has filed some separate RFEs for duplication found, and I think we should do it piecemeal. It used to be that the whole os_unix files were duplicated but that's not the case anymore. There should be an RFE for this specific item to consolidate. Coleen >> seems to happen (and the Solaris thr_* to pthread_* conversion that >> slowly happens). > > It'll all be done just in time to start moving to C/C++11 threads. > From gromero at linux.vnet.ibm.com Wed May 11 22:32:45 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Wed, 11 May 2016 19:32:45 -0300 Subject: SIGILL crashes JVM on PPC64 LE Message-ID: <5733B30D.6010201@linux.vnet.ibm.com> Hi I'm getting a nasty SIGILL that crashes the JVM on PPC64 LE. hs_err log: http://hastebin.com/raw/fovagunaci The application employs methods from both java.nio.ByteBuffer and sun.misc.Unsafe classes in order to write and read from an allocated buffer. A interesting thing is that after debugging the instruction that caused the said SIGILL: 0x3fff902839a4: cmpwi cr6,r17,0 0x3fff902839a8: beq cr6,0x3fff90283ae4 0x3fff902839ac: .long 0xea2f0013 <============ illegal instruction 0x3fff902839b0: add r15,r15,r17 0x3fff902839b4: add r14,r17,r14 I found that when its endianness is changed it turns out to be a valid instruction: vsel v24,v0,v5,v31 However, I'm still unable to determine if it's an application issue, something with JVM unsafe interface code, or something else. Any clue on how to narrow down this SIGILL? Thank you! Regards, Gustavo From david.holmes at oracle.com Wed May 11 22:50:21 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 12 May 2016 08:50:21 +1000 Subject: RFR(M): 8155949: Support relaxed semantics in cmpxchg In-Reply-To: References: <201605101044.u4AAingb016922@d19av07.sagamino.japan.ibm.com> <8bc82016-81fd-b420-7d4e-1c31e615c218@oracle.com> <1f78facd-2872-2eda-23e2-fd5de0fd8c42@oracle.com> <201605101318.u4ADI0NW004604@d19av05.sagamino.japan.ibm.com> <7a0f80de7788484da6d93f03c3eddd19@DEWDFE13DE14.global.corp.sap> Message-ID: <53b7bb82-89f0-bac5-5e5a-3234ffecdb50@oracle.com> This has about 3 hours to be reviewed and pushed to make the FC deadline. David On 11/05/2016 2:41 PM, David Holmes wrote: > Adding hotspot-dev to cc to expand scope of reviewer pool :) > > On 11/05/2016 6:56 AM, David Holmes wrote: >> On 11/05/2016 12:27 AM, Doerr, Martin wrote: >>> Hello everybody, >>> >>> thanks for finding this issue. New webrev is here: >>> >>> http://cr.openjdk.java.net/~mdoerr/8155949_relaxed_cas/webrev.02/ >> >> Unfortunately my test run hit a crash on Solaris sparc: >> >> # Problematic frame: >> # V [libjvm.so+0xcc35c4] >> markOopDesc*markOopDesc::displaced_mark_helper()const+0x64 >> >> I'm going to have to do some more testing to see if that is actually >> related to the change. I know it should not be, but given we CAS marks I >> have to wonder if there's some subtle bad interaction here. :( > > Further testing has not shown any failures on Solaris sparc, and the > same testing showed some spurious failures on other platforms even > without these changes. So while I will file a bug for this crash I think > it unlikely to be related to the current changes. > > So on that note we just need a second hotspot reviewer to sign off on this. > > Thanks, > David > > >> David >> ----- >> >>> >>> >>> Best regards, >>> >>> Martin >>> >>> >>> >>> *From:*Hiroshi H Horii [mailto:HORII at jp.ibm.com] >>> *Sent:* Dienstag, 10. Mai 2016 15:18 >>> *To:* David Holmes >>> *Cc:* hotspot-gc-dev at openjdk.java.net; >>> hotspot-runtime-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; >>> Tim Ellison ; Doerr, Martin >>> >>> *Subject:* Re: RFR(M): 8155949: Support relaxed semantics in cmpxchg >>> >>> >>> >>> Hi David, >>> >>>> Just need another reviewer to chime in - given you and Martin are both >>>> contributors. Or are you the main contributor with Martin being a >>>> reviewer? >>> >>> Martin and I are contributors of this change. >>> >>>> Still a problem on Solaris sparc: >>> >>> Martin, could you create a new change in webrev with the patch that >>> David sent? >>> >>> Regards, >>> Hiroshi >>> ----------------------- >>> Hiroshi Horii, Ph.D. >>> IBM Research - Tokyo >>> >>> >>> David Holmes > >>> wrote on 05/10/2016 21:29:53: >>> >>>> From: David Holmes >>> > >>>> To: Hiroshi H Horii/Japan/IBM at IBMJP, "hotspot-runtime- >>>> dev at openjdk.java.net " >>> >> > >>>> Cc: Tim Ellison >>> >, "ppc-aix-port- >>>> dev at openjdk.java.net " >>> >> >, "hotspot- >>>> gc-dev at openjdk.java.net " >>> >> > >>>> Date: 05/10/2016 21:31 >>>> Subject: Re: RFR(M): 8155949: Support relaxed semantics in cmpxchg >>>> >>>> On 10/05/2016 9:04 PM, David Holmes wrote: >>>> > Hi Hiroshi, >>>> > >>>> > On 10/05/2016 8:44 PM, Hiroshi H Horii wrote: >>>> >> Hi All, >>>> >> >>>> >> Can I please request reviews for the following change? >>>> >> >>>> >> Code change: >>>> >> http://cr.openjdk.java.net/~mdoerr/8155949_relaxed_cas/webrev.01/ >>>> > >>>> > Changes look good. I'm currently running them through our internal >>>> build >>>> > system. I will sponsor this and push the change through JPRT. >>>> >>>> Still a problem on Solaris sparc: >>>> >>>> "/opt/jprt/T/P1/102505.daholme/s/hotspot/src/share/vm/runtime/ >>>> atomic.inline.hpp", >>>> line 96: Error: Could not find a match for static >>>> Atomic::cmpxchg(signed >>>> char, volatile signed char*, signed char). >>>> 1 Error(s) detected. >>>> >>>> Needs this patch: >>>> >>>> diff -r 68853ef19be9 src/share/vm/runtime/atomic.inline.hpp >>>> --- a/src/share/vm/runtime/atomic.inline.hpp >>>> +++ b/src/share/vm/runtime/atomic.inline.hpp >>>> @@ -92,7 +92,7 @@ >>>> >>>> #ifndef VM_HAS_SPECIALIZED_CMPXCHG_BYTE >>>> // See comment in atomic.cpp how to override. >>>> -inline jbyte Atomic::cmpxchg(jbyte exchange_value, volatile jbyte >>>> *dest, jbyte comparand) >>>> +inline jbyte Atomic::cmpxchg(jbyte exchange_value, volatile jbyte >>>> *dest, jbyte comparand, cmpxchg_memory_order order) >>>> { >>>> return cmpxchg_general(exchange_value, dest, comparand); >>>> } >>>> >>>> David >>>> ----- >>>> >>>> > Just need another reviewer to chime in - given you and Martin are >>>> both >>>> > contributors. Or are you the main contributor with Martin being a >>>> reviewer? >>>> > >>>> > Thanks, >>>> > David >>>> > >>>> > PS. It's my night now so I'll be signing off and will pick this up in >>>> > the morning. >>>> > >>>> >> This change follows the discussion started from these mails. >>>> >> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016- >>>> April/018960.html >>>> >> >>>> >> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016- >>>> April/019148.html >>>> >> >>>> >> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016- >>>> May/019320.html >>>> >> >>>> >> >>>> >> Description: >>>> >> This change provides relaxed compare-and-exchange by introducing >>>> >> relaxed memory order. As described in atomic_linux_ppc.inline.hpp, >>>> >> the current implementation of cmpxchg is fence_cmpxchg_acquire. >>>> >> This implementation is useful for general purposes because twice >>>> calls of >>>> >> sync before and after cmpxchg will provide strict consistency. >>>> >> However, they sometimes cause overheads because sync instructions >>>> are >>>> >> very expensive in the current POWER chip design. >>>> >> >>>> >> We confirmed this change improves performance of copy_to_survivor >>>> >> in the parallel GC. However, we will need more investigation of GC >>>> >> by more experts. So, We would like to request a review of the change >>>> >> of cmpxchg first (as Martin requested). >>>> >> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016- >>>> April/019188.html >>>> >> >>>> >> >>>> >> Summary of source code changes: >>>> >> >>>> >> * src/share/vm/runtime/atomic.hpp >>>> >> - Defines enum memory_order and adds a parameter to cmpxchg. >>>> >> >>>> >> * src/share/vm/runtime/atomic.cpp >>>> >> * src/os_cpu/bsd_x86/vm/atomic_bsd_x86.inline.hpp >>>> >> * src/os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp >>>> >> * src/os_cpu/linux_aarch64/vm/atomic_linux_aarch64.inline.hpp >>>> >> * src/os_cpu/linux_sparc/vm/atomic_linux_sparc.inline.hpp >>>> >> * src/os_cpu/linux_x86/vm/atomic_linux_x86.inline.hpp >>>> >> * src/os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp >>>> >> * src/os_cpu/solaris_sparc/vm/atomic_solaris_sparc.inline.hpp >>>> >> * src/os_cpu/solaris_x86/vm/atomic_solaris_x86.inline.hpp >>>> >> * src/os_cpu/windows_x86/vm/atomic_windows_x86.inline.hpp >>>> >> - Added a parameter for each cmpxchg function to follow >>>> >> the change of atomic.hpp. Their implementations are not >>>> changed. >>>> >> >>>> >> * src/os_cpu/aix_ppc/vm/atomic_aix_ppc.inline.hpp >>>> >> * src/os_cpu/linux_ppc/vm/atomic_linux_ppc.inline.hpp >>>> >> - Added a parameter for each cmpxchg function to follow >>>> >> the change of atomic.hpp. In addition, implementations >>>> >> are changed corresponding to the specified memory_order. >>>> >> >>>> >> Regards, >>>> >> Hiroshi >>>> >> ----------------------- >>>> >> Hiroshi Horii, Ph.D. >>>> >> IBM Research - Tokyo >>>> >> >>>> >>> From david.holmes at oracle.com Wed May 11 23:54:55 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 12 May 2016 09:54:55 +1000 Subject: RFR: 8155627: Enable SA on AArch64 In-Reply-To: <572CC280.3050308@redhat.com> References: <57168C17.40307@oracle.com> <57185E31.9010705@oracle.com> <57235E1B.8080001@redhat.com> <57235F39.5080204@redhat.com> <101be161-cfb4-b2d4-0b35-0d497d3dfa19@oracle.com> <572CC280.3050308@redhat.com> Message-ID: <9a6e92e9-a0d8-3e17-8e6e-b044b0b07361@oracle.com> This looks fine to me. I will sponsor this. David On 7/05/2016 2:12 AM, Andrew Haley wrote: > Two fixes here. > > 1. SA is not enabled at all in the builds. I have no idea why; it used > to work. > > 2. 8154580 broke the interpreter stack frame handling. > > http://cr.openjdk.java.net/~aph/8155627 > > Thanks, > > Andrew. > From tobias.hartmann at oracle.com Thu May 12 06:36:00 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 12 May 2016 08:36:00 +0200 Subject: JVM 24.95 SIGSEGV on C2 Compiler Thread In-Reply-To: <5733A393.8010005@linux.vnet.ibm.com> References: <56EAB89B.9050206@linux.vnet.ibm.com> <56EABF93.2070707@oracle.com> <56EAC8EB.9020609@linux.vnet.ibm.com> <5733A393.8010005@linux.vnet.ibm.com> Message-ID: <57342450.5050901@oracle.com> Hi Gustavo, On 11.05.2016 23:26, Gustavo Romero wrote: > Hi Tobias > > Your wild guess on > https://bugs.openjdk.java.net/browse/JDK-6675699 > was correct. Loop peeling issue was the culprit. > > Also I finally was able to test exhaustively the code on OpenJDK 8 > and could not reproduce it. Fixed on 8 as you said. Good, thanks for the update! [CC'ing hotspot-dev for the record] Best regards, Tobias > Thanks a lot. > > Best regards, > Gustavo > > > On 17-03-2016 12:10, Gustavo Romero wrote: >> Hi Tobias, >> >> I'll try to reproduce it with 8 on PPC64 and let you know about the >> result. >> >> Thank you. >> >> Regards, >> Gustavo >> >> On 17-03-2016 11:30, Tobias Hartmann wrote: >>> Hi Gustavo, >>> >>> just a wild guess, but this could be one of >>> https://bugs.openjdk.java.net/browse/JDK-6675699 >>> https://bugs.openjdk.java.net/browse/JDK-8027388 >>> >>> Both were not backported to 7. Did you try to reproduce this with 8? >>> >>> Best regards, >>> Tobias >>> >>> On 17.03.2016 15:00, Gustavo Romero wrote: >>>> Hi Martin, >>>> >>>> I'm facing a problem with a JVM 24.95 when running an application. >>>> However it's being hard to reproduce it, ie many times C2 will >>>> optimize the method fine and the application terminates fine. Just >>>> after many complete runs, one of them will crash. Apparently it is >>>> related to https://bugs.openjdk.java.net/browse/JDK-7068051 bug, >>>> but it was fixed in hs22 and as I could not isolate it on PPC64, >>>> I can't tell if it still exists upstream on PPC64. >>>> >>>> Do you have any clue on how to isolate/debug this problem? >>>> >>>> Hotspot error log: >>>> http://hastebin.com/raw/pepajuwepu >>>> >>>> Backtrace from the thread that caused the segfault: >>>> http://hastebin.com/raw/zirelokuto >>>> >>>> Thank you! >>>> >>>> Best regards, >>>> Gustavo >>>> >>> >> > From goetz.lindenmaier at sap.com Thu May 12 08:50:09 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 12 May 2016 08:50:09 +0000 Subject: RFR(M): 8155949: Support relaxed semantics in cmpxchg In-Reply-To: <53b7bb82-89f0-bac5-5e5a-3234ffecdb50@oracle.com> References: <201605101044.u4AAingb016922@d19av07.sagamino.japan.ibm.com> <8bc82016-81fd-b420-7d4e-1c31e615c218@oracle.com> <1f78facd-2872-2eda-23e2-fd5de0fd8c42@oracle.com> <201605101318.u4ADI0NW004604@d19av05.sagamino.japan.ibm.com> <7a0f80de7788484da6d93f03c3eddd19@DEWDFE13DE14.global.corp.sap> <53b7bb82-89f0-bac5-5e5a-3234ffecdb50@oracle.com> Message-ID: Hi, atomic_bsd_zero.inline.hpp:303 The order argument is not passed on to the inner cmpxchg_ptr call. But I guess this is not really relevant as the argument is not used anyways. (This method should be moved to the shared atomic.inline.hpp file, but not in this change.) Besides that the change looks good. Reviewed. In case this now really is too late (http://openjdk.java.net/projects/jdk9/ states 26.5. for dev close, but hs is more early?) will there be jdk10 repos soon, or jdk9u? Best regards, Goetz. > -----Original Message----- > From: hotspot-gc-dev [mailto:hotspot-gc-dev-bounces at openjdk.java.net] > On Behalf Of David Holmes > Sent: Donnerstag, 12. Mai 2016 00:50 > To: Doerr, Martin ; Hiroshi H Horii > > Cc: Tim Ellison ; ppc-aix-port- > dev at openjdk.java.net; hotspot-dev developers dev at openjdk.java.net>; hotspot-gc-dev at openjdk.java.net; hotspot- > runtime-dev at openjdk.java.net > Subject: Re: RFR(M): 8155949: Support relaxed semantics in cmpxchg > > This has about 3 hours to be reviewed and pushed to make the FC deadline. > > David > > On 11/05/2016 2:41 PM, David Holmes wrote: > > Adding hotspot-dev to cc to expand scope of reviewer pool :) > > > > On 11/05/2016 6:56 AM, David Holmes wrote: > >> On 11/05/2016 12:27 AM, Doerr, Martin wrote: > >>> Hello everybody, > >>> > >>> thanks for finding this issue. New webrev is here: > >>> > >>> http://cr.openjdk.java.net/~mdoerr/8155949_relaxed_cas/webrev.02/ > >> > >> Unfortunately my test run hit a crash on Solaris sparc: > >> > >> # Problematic frame: > >> # V [libjvm.so+0xcc35c4] > >> markOopDesc*markOopDesc::displaced_mark_helper()const+0x64 > >> > >> I'm going to have to do some more testing to see if that is actually > >> related to the change. I know it should not be, but given we CAS marks I > >> have to wonder if there's some subtle bad interaction here. :( > > > > Further testing has not shown any failures on Solaris sparc, and the > > same testing showed some spurious failures on other platforms even > > without these changes. So while I will file a bug for this crash I think > > it unlikely to be related to the current changes. > > > > So on that note we just need a second hotspot reviewer to sign off on this. > > > > Thanks, > > David > > > > > >> David > >> ----- > >> > >>> > >>> > >>> Best regards, > >>> > >>> Martin > >>> > >>> > >>> > >>> *From:*Hiroshi H Horii [mailto:HORII at jp.ibm.com] > >>> *Sent:* Dienstag, 10. Mai 2016 15:18 > >>> *To:* David Holmes > >>> *Cc:* hotspot-gc-dev at openjdk.java.net; > >>> hotspot-runtime-dev at openjdk.java.net; ppc-aix-port- > dev at openjdk.java.net; > >>> Tim Ellison ; Doerr, Martin > >>> > >>> *Subject:* Re: RFR(M): 8155949: Support relaxed semantics in cmpxchg > >>> > >>> > >>> > >>> Hi David, > >>> > >>>> Just need another reviewer to chime in - given you and Martin are both > >>>> contributors. Or are you the main contributor with Martin being a > >>>> reviewer? > >>> > >>> Martin and I are contributors of this change. > >>> > >>>> Still a problem on Solaris sparc: > >>> > >>> Martin, could you create a new change in webrev with the patch that > >>> David sent? > >>> > >>> Regards, > >>> Hiroshi > >>> ----------------------- > >>> Hiroshi Horii, Ph.D. > >>> IBM Research - Tokyo > >>> > >>> > >>> David Holmes > > >>> wrote on 05/10/2016 21:29:53: > >>> > >>>> From: David Holmes >>>> > > >>>> To: Hiroshi H Horii/Japan/IBM at IBMJP, "hotspot-runtime- > >>>> dev at openjdk.java.net " > >>> >>> > > >>>> Cc: Tim Ellison >>>> >, "ppc-aix-port- > >>>> dev at openjdk.java.net " > >>> >>> >, "hotspot- > >>>> gc-dev at openjdk.java.net " > >>> >>> > > >>>> Date: 05/10/2016 21:31 > >>>> Subject: Re: RFR(M): 8155949: Support relaxed semantics in cmpxchg > >>>> > >>>> On 10/05/2016 9:04 PM, David Holmes wrote: > >>>> > Hi Hiroshi, > >>>> > > >>>> > On 10/05/2016 8:44 PM, Hiroshi H Horii wrote: > >>>> >> Hi All, > >>>> >> > >>>> >> Can I please request reviews for the following change? > >>>> >> > >>>> >> Code change: > >>>> >> > http://cr.openjdk.java.net/~mdoerr/8155949_relaxed_cas/webrev.01/ > >>>> > > >>>> > Changes look good. I'm currently running them through our internal > >>>> build > >>>> > system. I will sponsor this and push the change through JPRT. > >>>> > >>>> Still a problem on Solaris sparc: > >>>> > >>>> "/opt/jprt/T/P1/102505.daholme/s/hotspot/src/share/vm/runtime/ > >>>> atomic.inline.hpp", > >>>> line 96: Error: Could not find a match for static > >>>> Atomic::cmpxchg(signed > >>>> char, volatile signed char*, signed char). > >>>> 1 Error(s) detected. > >>>> > >>>> Needs this patch: > >>>> > >>>> diff -r 68853ef19be9 src/share/vm/runtime/atomic.inline.hpp > >>>> --- a/src/share/vm/runtime/atomic.inline.hpp > >>>> +++ b/src/share/vm/runtime/atomic.inline.hpp > >>>> @@ -92,7 +92,7 @@ > >>>> > >>>> #ifndef VM_HAS_SPECIALIZED_CMPXCHG_BYTE > >>>> // See comment in atomic.cpp how to override. > >>>> -inline jbyte Atomic::cmpxchg(jbyte exchange_value, volatile jbyte > >>>> *dest, jbyte comparand) > >>>> +inline jbyte Atomic::cmpxchg(jbyte exchange_value, volatile jbyte > >>>> *dest, jbyte comparand, cmpxchg_memory_order order) > >>>> { > >>>> return cmpxchg_general(exchange_value, dest, comparand); > >>>> } > >>>> > >>>> David > >>>> ----- > >>>> > >>>> > Just need another reviewer to chime in - given you and Martin are > >>>> both > >>>> > contributors. Or are you the main contributor with Martin being a > >>>> reviewer? > >>>> > > >>>> > Thanks, > >>>> > David > >>>> > > >>>> > PS. It's my night now so I'll be signing off and will pick this up in > >>>> > the morning. > >>>> > > >>>> >> This change follows the discussion started from these mails. > >>>> >> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016- > >>>> April/018960.html > >>>> >> > >>>> >> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016- > >>>> April/019148.html > >>>> >> > >>>> >> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016- > >>>> May/019320.html > >>>> >> > >>>> >> > >>>> >> Description: > >>>> >> This change provides relaxed compare-and-exchange by introducing > >>>> >> relaxed memory order. As described in > atomic_linux_ppc.inline.hpp, > >>>> >> the current implementation of cmpxchg is fence_cmpxchg_acquire. > >>>> >> This implementation is useful for general purposes because twice > >>>> calls of > >>>> >> sync before and after cmpxchg will provide strict consistency. > >>>> >> However, they sometimes cause overheads because sync > instructions > >>>> are > >>>> >> very expensive in the current POWER chip design. > >>>> >> > >>>> >> We confirmed this change improves performance of > copy_to_survivor > >>>> >> in the parallel GC. However, we will need more investigation of GC > >>>> >> by more experts. So, We would like to request a review of the > change > >>>> >> of cmpxchg first (as Martin requested). > >>>> >> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016- > >>>> April/019188.html > >>>> >> > >>>> >> > >>>> >> Summary of source code changes: > >>>> >> > >>>> >> * src/share/vm/runtime/atomic.hpp > >>>> >> - Defines enum memory_order and adds a parameter to > cmpxchg. > >>>> >> > >>>> >> * src/share/vm/runtime/atomic.cpp > >>>> >> * src/os_cpu/bsd_x86/vm/atomic_bsd_x86.inline.hpp > >>>> >> * src/os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp > >>>> >> * src/os_cpu/linux_aarch64/vm/atomic_linux_aarch64.inline.hpp > >>>> >> * src/os_cpu/linux_sparc/vm/atomic_linux_sparc.inline.hpp > >>>> >> * src/os_cpu/linux_x86/vm/atomic_linux_x86.inline.hpp > >>>> >> * src/os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp > >>>> >> * src/os_cpu/solaris_sparc/vm/atomic_solaris_sparc.inline.hpp > >>>> >> * src/os_cpu/solaris_x86/vm/atomic_solaris_x86.inline.hpp > >>>> >> * src/os_cpu/windows_x86/vm/atomic_windows_x86.inline.hpp > >>>> >> - Added a parameter for each cmpxchg function to follow > >>>> >> the change of atomic.hpp. Their implementations are not > >>>> changed. > >>>> >> > >>>> >> * src/os_cpu/aix_ppc/vm/atomic_aix_ppc.inline.hpp > >>>> >> * src/os_cpu/linux_ppc/vm/atomic_linux_ppc.inline.hpp > >>>> >> - Added a parameter for each cmpxchg function to follow > >>>> >> the change of atomic.hpp. In addition, implementations > >>>> >> are changed corresponding to the specified memory_order. > >>>> >> > >>>> >> Regards, > >>>> >> Hiroshi > >>>> >> ----------------------- > >>>> >> Hiroshi Horii, Ph.D. > >>>> >> IBM Research - Tokyo > >>>> >> > >>>> > >>> From jesper.wilhelmsson at oracle.com Thu May 12 08:53:02 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 12 May 2016 10:53:02 +0200 Subject: jdk9/hs is CLOSED Message-ID: Hi, Just a reminder that jdk9/hs is now closed for any pushes not related to fixing integration blockers. There are currently two blockers: JDK-8156769 - gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java fails with java.lang.Exception JDK-8156223 - nsk/jvmti/IterateThroughHeap/filter-class-untagged fails with SIGSEGV There are also crashes in the Wednesday nightly that looks related to the fix for JDK-8156050 - ParallelCompact_test should skip test if UseParallelOldGC is off /Jesper From aph at redhat.com Thu May 12 09:00:27 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 12 May 2016 10:00:27 +0100 Subject: jdk9/hs is CLOSED In-Reply-To: References: Message-ID: <5734462B.7030108@redhat.com> On 12/05/16 09:53, Jesper Wilhelmsson wrote: > Just a reminder that jdk9/hs is now closed for any pushes not related to fixing > integration blockers. Can someone please explain that rule to me? I've been trying to follow what's going on but it's not clear to me outside Oracle's internal discussions. I have some AArch64 bug fixes already reviewed in my queue. Andrew. From martin.doerr at sap.com Thu May 12 09:33:03 2016 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 12 May 2016 09:33:03 +0000 Subject: PPC64 VSX load/store instructions in stubs In-Reply-To: <57339EE1.2040500@linux.vnet.ibm.com> References: <56FEDBB3.5030106@linux.vnet.ibm.com> <57339EE1.2040500@linux.vnet.ibm.com> Message-ID: Hi Gustavo, thanks for providing the webrevs. The change looks basically good. I only have the following concerns: - We basically support configuring dscr by various DSCR switches. Your code resets the value to hardware default instead of the possibly modified values. We're currently only using default DSCR values, but maybe we may want to play with them in the future. We could use a static variable for the default dscr value. It could be modified in VM_Version::config_dscr() and used by your restore code (load_const_optimized(tmp1, ...) instead of li(tmp1, 0)). - The PPC-elf64abi-1.9 says: "Functions must ensure that the appropriate bits in the vrsave register are set for any vector registers they use. ...". I think not touching vrsave is the right thing for AIX and ppc64le, but I think we will either have to skip the optimization on ppc64 big endian or handle vrsave. Do you agree? Best regards, Martin -----Original Message----- From: Gustavo Romero [mailto:gromero at linux.vnet.ibm.com] Sent: Mittwoch, 11. Mai 2016 23:07 To: Volker Simonis Cc: Doerr, Martin ; Simonis, Volker ; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; brenohl at br.ibm.com Subject: Re: PPC64 VSX load/store instructions in stubs Importance: High Hi Volker, Hi Martin Sincere apologies for the long delay. My initial approach to test the VSX load/store was from an extracted snippet regarding just the mass copy loop "grafted" inside an inline asm, performing isolated tests with "perf" tool focused only on aligned source and destination (best case). The extracted code, called "Original" in the plot below (black line), is here: https://github.com/gromero/arraycopy/blob/2pairs/arraycopy.c#L27-L36 That extracted, after some experiments, evolved into this one that employs VSX load/store, Data Stream deepest pre-fetch, d-cache touch, and backbranch aligned to 32-byte: https://github.com/gromero/arraycopy/blob/2pairs/arraycopy_vsx.c#L27-L41 All runs where "pinned" using `numactl --cpunodebind --membind` to avoid any scheduler decision that could add noise to the measure. VSX, deepest data pre-fetch, d-cache touch, and 32-bytes align proved to be better in the isolated code (red line) in comparison to the original extracted code (black line): http://gromero.github.io/openjdk/original_vsx_non_pf_vsx_pf_deepest.pdf So I proceeded to implement the VSX loop in OpenJDK based on the best case result (VSX, pre-fetch deepest, d-cache touch, and backbranch target align - goetz TODO note). OpenJDK 8 webrev: http://81.de.7a9f.ip4.static.sl-reverse.com/8154156/8/ OpenJDK 9 webrev: http://81.de.7a9f.ip4.static.sl-reverse.com/8154156/9/ I've tested the change on OpenJDK 8 using this script that calls System.arraycopy() on shorts: https://goo.gl/8UWtLm The results for all data alignment cases: http://gromero.github.io/openjdk/src_0_dst_0.pdf http://gromero.github.io/openjdk/src_1_dst_0.pdf http://gromero.github.io/openjdk/src_0_dst_1.pdf http://gromero.github.io/openjdk/src_1_dst_1.pdf Martin, I added the vsx test to the feature-string. Regarding the ABI, I'm just using two VSR: vsr0 and vsr1, both volatile. Volker, as the loop unrolling was removed now the loop copies 16 elemets a time, like the non-VSX loop, and not 32 elements. I just verified the change on Little endian. Sorry I didn't understand your question regarding "instructions for aligned load/stores". Did you mean instructions for unaligned load/stores? I think both fixed-point (ld/std) and VSX instructions will do load/store slower in unaligned scenario. However VMX load/store is different and expects aligned operands. Thank you very much for opening the bug https://bugs.openjdk.java.net/browse/JDK-8154156 I don't have the profiling per function for each SPEC{jbb,jvm} benchmark in order to determine which one would stress the proposed change better. Could I use a better benchmark? Thank you! Best regards, Gustavo On 05-04-2016 14:23, Volker Simonis wrote: > Hi Gustavo, > > thanks a lot for your contribution. > > Can you please describe if you've run benchmarks and which performance > improvements you saw? > > With your change if we're running on Power 8, we will only use the > fast path for arrays with at least 32 elements. For smaller arrays, we > will fall-back to copying only 2 elements at a time which will be > slower than the initial version which copied 4 at a time in that case. > > Did you verified your changes on both, little and big endian? > > And what about unaligned memory accesses? As far as I read, > lxvd2x/stxvd2x still work, but may be slower. I saw there also exist > instructions for aligned load/stores. Would it make sens > (performance-wise) to use them for the cases where we can be sure that > we have aligned memory accesses? > > Thank you and best regards, > Volker > > > On Fri, Apr 1, 2016 at 10:36 PM, Gustavo Romero > wrote: >> Hi Martin, Hi Volker >> >> Currently VSX load/store instructions are not being used in PPC64 stubs, >> particularly in arraycopy stubs inside generate_arraycopy_stubs() like, >> but not limited to, generate_disjoint_{byte,short,int,long}_copy. >> >> We can speed up mass copy using VSX (Vector-Scalar Extension) load/store >> instruction in processors >= POWER8, the same way it's already done for >> libc memcpy(). >> >> This is an initial patch just for jshort_disjoint_arraycopy() VSX vector >> load/store: >> >> http://81.de.7a9f.ip4.static.sl-reverse.com/202539/webrev >> >> What are your thoughts on that? Is there any impediment to use VSX >> instructions in OpenJDK at the moment? >> >> Thank you. >> >> Best regards, >> Gustavo >> > From david.holmes at oracle.com Thu May 12 09:52:14 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 12 May 2016 19:52:14 +1000 Subject: RFR(M): 8155949: Support relaxed semantics in cmpxchg In-Reply-To: References: <201605101044.u4AAingb016922@d19av07.sagamino.japan.ibm.com> <8bc82016-81fd-b420-7d4e-1c31e615c218@oracle.com> <1f78facd-2872-2eda-23e2-fd5de0fd8c42@oracle.com> <201605101318.u4ADI0NW004604@d19av05.sagamino.japan.ibm.com> <7a0f80de7788484da6d93f03c3eddd19@DEWDFE13DE14.global.corp.sap> <53b7bb82-89f0-bac5-5e5a-3234ffecdb50@oracle.com> Message-ID: <63c2519a-7909-804c-b30c-bd8ee814a328@oracle.com> On 12/05/2016 6:50 PM, Lindenmaier, Goetz wrote: > Hi, > > atomic_bsd_zero.inline.hpp:303 > The order argument is not passed on to the inner cmpxchg_ptr call. > But I guess this is not really relevant as the argument is not used Right - that pattern is used throughout the changes. > anyways. (This method should be moved to the shared atomic.inline.hpp > file, but not in this change.) > > Besides that the change looks good. Reviewed. > > In case this now really is too late (http://openjdk.java.net/projects/jdk9/ states 26.5. for dev close, but hs is more early?) > will there be jdk10 repos soon, or jdk9u? Yes hs has to finalize sooner as the FC date is for things to be in jdk9/jdk9 and it takes time for changes to get from hs to jdk9. There will be a process for requesting approval for changes post FC but that hasn't yet been announced either. No word yet on when jdk10 forests will open up. David ----- > Best regards, > Goetz. > > > > > >> -----Original Message----- >> From: hotspot-gc-dev [mailto:hotspot-gc-dev-bounces at openjdk.java.net] >> On Behalf Of David Holmes >> Sent: Donnerstag, 12. Mai 2016 00:50 >> To: Doerr, Martin ; Hiroshi H Horii >> >> Cc: Tim Ellison ; ppc-aix-port- >> dev at openjdk.java.net; hotspot-dev developers > dev at openjdk.java.net>; hotspot-gc-dev at openjdk.java.net; hotspot- >> runtime-dev at openjdk.java.net >> Subject: Re: RFR(M): 8155949: Support relaxed semantics in cmpxchg >> >> This has about 3 hours to be reviewed and pushed to make the FC deadline. >> >> David >> >> On 11/05/2016 2:41 PM, David Holmes wrote: >>> Adding hotspot-dev to cc to expand scope of reviewer pool :) >>> >>> On 11/05/2016 6:56 AM, David Holmes wrote: >>>> On 11/05/2016 12:27 AM, Doerr, Martin wrote: >>>>> Hello everybody, >>>>> >>>>> thanks for finding this issue. New webrev is here: >>>>> >>>>> http://cr.openjdk.java.net/~mdoerr/8155949_relaxed_cas/webrev.02/ >>>> >>>> Unfortunately my test run hit a crash on Solaris sparc: >>>> >>>> # Problematic frame: >>>> # V [libjvm.so+0xcc35c4] >>>> markOopDesc*markOopDesc::displaced_mark_helper()const+0x64 >>>> >>>> I'm going to have to do some more testing to see if that is actually >>>> related to the change. I know it should not be, but given we CAS marks I >>>> have to wonder if there's some subtle bad interaction here. :( >>> >>> Further testing has not shown any failures on Solaris sparc, and the >>> same testing showed some spurious failures on other platforms even >>> without these changes. So while I will file a bug for this crash I think >>> it unlikely to be related to the current changes. >>> >>> So on that note we just need a second hotspot reviewer to sign off on this. >>> >>> Thanks, >>> David >>> >>> >>>> David >>>> ----- >>>> >>>>> >>>>> >>>>> Best regards, >>>>> >>>>> Martin >>>>> >>>>> >>>>> >>>>> *From:*Hiroshi H Horii [mailto:HORII at jp.ibm.com] >>>>> *Sent:* Dienstag, 10. Mai 2016 15:18 >>>>> *To:* David Holmes >>>>> *Cc:* hotspot-gc-dev at openjdk.java.net; >>>>> hotspot-runtime-dev at openjdk.java.net; ppc-aix-port- >> dev at openjdk.java.net; >>>>> Tim Ellison ; Doerr, Martin >>>>> >>>>> *Subject:* Re: RFR(M): 8155949: Support relaxed semantics in cmpxchg >>>>> >>>>> >>>>> >>>>> Hi David, >>>>> >>>>>> Just need another reviewer to chime in - given you and Martin are both >>>>>> contributors. Or are you the main contributor with Martin being a >>>>>> reviewer? >>>>> >>>>> Martin and I are contributors of this change. >>>>> >>>>>> Still a problem on Solaris sparc: >>>>> >>>>> Martin, could you create a new change in webrev with the patch that >>>>> David sent? >>>>> >>>>> Regards, >>>>> Hiroshi >>>>> ----------------------- >>>>> Hiroshi Horii, Ph.D. >>>>> IBM Research - Tokyo >>>>> >>>>> >>>>> David Holmes > > >>>>> wrote on 05/10/2016 21:29:53: >>>>> >>>>>> From: David Holmes >>>>> > >>>>>> To: Hiroshi H Horii/Japan/IBM at IBMJP, "hotspot-runtime- >>>>>> dev at openjdk.java.net " >>>>> >>>> > >>>>>> Cc: Tim Ellison >>>>> >, "ppc-aix-port- >>>>>> dev at openjdk.java.net " >>>>> >>>> >, "hotspot- >>>>>> gc-dev at openjdk.java.net " >>>>> >>>> > >>>>>> Date: 05/10/2016 21:31 >>>>>> Subject: Re: RFR(M): 8155949: Support relaxed semantics in cmpxchg >>>>>> >>>>>> On 10/05/2016 9:04 PM, David Holmes wrote: >>>>>>> Hi Hiroshi, >>>>>>> >>>>>>> On 10/05/2016 8:44 PM, Hiroshi H Horii wrote: >>>>>>>> Hi All, >>>>>>>> >>>>>>>> Can I please request reviews for the following change? >>>>>>>> >>>>>>>> Code change: >>>>>>>> >> http://cr.openjdk.java.net/~mdoerr/8155949_relaxed_cas/webrev.01/ >>>>>>> >>>>>>> Changes look good. I'm currently running them through our internal >>>>>> build >>>>>>> system. I will sponsor this and push the change through JPRT. >>>>>> >>>>>> Still a problem on Solaris sparc: >>>>>> >>>>>> "/opt/jprt/T/P1/102505.daholme/s/hotspot/src/share/vm/runtime/ >>>>>> atomic.inline.hpp", >>>>>> line 96: Error: Could not find a match for static >>>>>> Atomic::cmpxchg(signed >>>>>> char, volatile signed char*, signed char). >>>>>> 1 Error(s) detected. >>>>>> >>>>>> Needs this patch: >>>>>> >>>>>> diff -r 68853ef19be9 src/share/vm/runtime/atomic.inline.hpp >>>>>> --- a/src/share/vm/runtime/atomic.inline.hpp >>>>>> +++ b/src/share/vm/runtime/atomic.inline.hpp >>>>>> @@ -92,7 +92,7 @@ >>>>>> >>>>>> #ifndef VM_HAS_SPECIALIZED_CMPXCHG_BYTE >>>>>> // See comment in atomic.cpp how to override. >>>>>> -inline jbyte Atomic::cmpxchg(jbyte exchange_value, volatile jbyte >>>>>> *dest, jbyte comparand) >>>>>> +inline jbyte Atomic::cmpxchg(jbyte exchange_value, volatile jbyte >>>>>> *dest, jbyte comparand, cmpxchg_memory_order order) >>>>>> { >>>>>> return cmpxchg_general(exchange_value, dest, comparand); >>>>>> } >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>>> Just need another reviewer to chime in - given you and Martin are >>>>>> both >>>>>>> contributors. Or are you the main contributor with Martin being a >>>>>> reviewer? >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> PS. It's my night now so I'll be signing off and will pick this up in >>>>>>> the morning. >>>>>>> >>>>>>>> This change follows the discussion started from these mails. >>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016- >>>>>> April/018960.html >>>>>>>> >>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016- >>>>>> April/019148.html >>>>>>>> >>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016- >>>>>> May/019320.html >>>>>>>> >>>>>>>> >>>>>>>> Description: >>>>>>>> This change provides relaxed compare-and-exchange by introducing >>>>>>>> relaxed memory order. As described in >> atomic_linux_ppc.inline.hpp, >>>>>>>> the current implementation of cmpxchg is fence_cmpxchg_acquire. >>>>>>>> This implementation is useful for general purposes because twice >>>>>> calls of >>>>>>>> sync before and after cmpxchg will provide strict consistency. >>>>>>>> However, they sometimes cause overheads because sync >> instructions >>>>>> are >>>>>>>> very expensive in the current POWER chip design. >>>>>>>> >>>>>>>> We confirmed this change improves performance of >> copy_to_survivor >>>>>>>> in the parallel GC. However, we will need more investigation of GC >>>>>>>> by more experts. So, We would like to request a review of the >> change >>>>>>>> of cmpxchg first (as Martin requested). >>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016- >>>>>> April/019188.html >>>>>>>> >>>>>>>> >>>>>>>> Summary of source code changes: >>>>>>>> >>>>>>>> * src/share/vm/runtime/atomic.hpp >>>>>>>> - Defines enum memory_order and adds a parameter to >> cmpxchg. >>>>>>>> >>>>>>>> * src/share/vm/runtime/atomic.cpp >>>>>>>> * src/os_cpu/bsd_x86/vm/atomic_bsd_x86.inline.hpp >>>>>>>> * src/os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp >>>>>>>> * src/os_cpu/linux_aarch64/vm/atomic_linux_aarch64.inline.hpp >>>>>>>> * src/os_cpu/linux_sparc/vm/atomic_linux_sparc.inline.hpp >>>>>>>> * src/os_cpu/linux_x86/vm/atomic_linux_x86.inline.hpp >>>>>>>> * src/os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp >>>>>>>> * src/os_cpu/solaris_sparc/vm/atomic_solaris_sparc.inline.hpp >>>>>>>> * src/os_cpu/solaris_x86/vm/atomic_solaris_x86.inline.hpp >>>>>>>> * src/os_cpu/windows_x86/vm/atomic_windows_x86.inline.hpp >>>>>>>> - Added a parameter for each cmpxchg function to follow >>>>>>>> the change of atomic.hpp. Their implementations are not >>>>>> changed. >>>>>>>> >>>>>>>> * src/os_cpu/aix_ppc/vm/atomic_aix_ppc.inline.hpp >>>>>>>> * src/os_cpu/linux_ppc/vm/atomic_linux_ppc.inline.hpp >>>>>>>> - Added a parameter for each cmpxchg function to follow >>>>>>>> the change of atomic.hpp. In addition, implementations >>>>>>>> are changed corresponding to the specified memory_order. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Hiroshi >>>>>>>> ----------------------- >>>>>>>> Hiroshi Horii, Ph.D. >>>>>>>> IBM Research - Tokyo >>>>>>>> >>>>>> >>>>> From jesper.wilhelmsson at oracle.com Thu May 12 09:54:19 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 12 May 2016 11:54:19 +0200 Subject: jdk9/hs is CLOSED In-Reply-To: <5734462B.7030108@redhat.com> References: <5734462B.7030108@redhat.com> Message-ID: Hi Andrew, Sorry, part of this discussion has taken place on internal lists. The background/summary is that in order to push jdk9/hs to jdk9/dev we need to have a "clean" snapshot of jdk9/hs. Our definition of clean is that it should pass through two nights of our nightly testing without any new test failures. (Two nights because we run slightly different testing every second night.) The clean snapshot should then go through PIT - Product Integration Testing - (another, bigger test suite) before being pushed to jdk9/dev. Changes in jdk9/dev are also run through PIT (and I'm actually not sure if this is the same tests or a different suite). The last PIT in jdk9/dev before FC is started on Friday next week. This date is difficult to change since it affects a lot of people. This is the last chance to get any changes into jdk9/jdk9 before FC. (And jdk9/jdk9 is where the changes needs to be to count as integrated before FC.) That means that our (jdk9/hs) PIT needs to be done, analyzed and fixed (if any problems should be found) before Friday next week. Usually this work takes about a week, so we estimated that the last day to start our PIT is on Friday. It could be started one or two days later but then some people would have to work over the weekend and we would like to avoid that if possible. Two nightlies before Friday means that the snapshot we took Wednesday night is the last one. To be on the safe side we decided to lock down jdk9/hs if there would be any remaining issues. This turned out to be a good decision since we have two integration blockers left and some new failures showed up in the Wednesday nightly. We will now have to fix these asap and run an adhoc nightly to get the two nightlies before Friday. Now, back to your changes. If you are changing code that is not supported by Oracle - i.e. code that we don't test in our internal testing, there should be no issues getting this code in to jdk9/hs. However, if you want the code to get into jdk9/jdk9 before FC you'd have to push asap. Once we take the snapshot to start PIT no more changes from jdk9/hs will make it to jdk9/jdk9 before FC. I don't know what your options are considering where to push your changes, but if you have the option to push directly to jdk9/dev you'd have another week before that PIT is started. Unfortunately I don't know who would be in a position to decide if you can push there or not. Maybe Lana Steuck knows? If your changes are in shared code and are considered enhancements it is unfortunately too late to get them in to jdk9/hs now. You'd have to get an FC exception to push it later. If your changes are high priority I don't think getting the exception will be very difficult. Please note that FC only concerns enhancements and new features. jdk9/hs will open again once we have a clean snapshot to push and then we can push bug fixes all the way up to ZBB (currently planned to late October) modulo low priority (p4-p5) bugs that can not go in after RDP1 (early September). Sorry for the long answer, but I hope it answered your question. /Jesper Den 12/5/16 kl. 11:00, skrev Andrew Haley: > On 12/05/16 09:53, Jesper Wilhelmsson wrote: >> Just a reminder that jdk9/hs is now closed for any pushes not related to fixing >> integration blockers. > > Can someone please explain that rule to me? I've been trying > to follow what's going on but it's not clear to me outside > Oracle's internal discussions. I have some AArch64 bug fixes > already reviewed in my queue. > > Andrew. > From david.holmes at oracle.com Thu May 12 09:54:46 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 12 May 2016 19:54:46 +1000 Subject: jdk9/hs is CLOSED In-Reply-To: <5734462B.7030108@redhat.com> References: <5734462B.7030108@redhat.com> Message-ID: <93fae4b7-9f3c-689c-52cd-af53628494e6@oracle.com> On 12/05/2016 7:00 PM, Andrew Haley wrote: > On 12/05/16 09:53, Jesper Wilhelmsson wrote: >> Just a reminder that jdk9/hs is now closed for any pushes not related to fixing >> integration blockers. > > Can someone please explain that rule to me? I've been trying > to follow what's going on but it's not clear to me outside > Oracle's internal discussions. I have some AArch64 bug fixes > already reviewed in my queue. It is just a temporary closure to get hs stable so it can be pushed up to jdk9/dev and then jdk9/jdk9 for the Feature Complete date. We haven't been able to push up since April 25 due to continual instability. David ----- > Andrew. > From kirk at kodewerk.com Thu May 12 09:57:23 2016 From: kirk at kodewerk.com (kirk at kodewerk.com) Date: Thu, 12 May 2016 11:57:23 +0200 Subject: jdk9/hs is CLOSED In-Reply-To: <5734462B.7030108@redhat.com> References: <5734462B.7030108@redhat.com> Message-ID: Hi, This is a very interesting point because these internal discussions lock out the rest of the community. Kind regards, Kirk Pepperdine > On May 12, 2016, at 11:00 AM, Andrew Haley wrote: > > On 12/05/16 09:53, Jesper Wilhelmsson wrote: >> Just a reminder that jdk9/hs is now closed for any pushes not related to fixing >> integration blockers. > > Can someone please explain that rule to me? I've been trying > to follow what's going on but it's not clear to me outside > Oracle's internal discussions. I have some AArch64 bug fixes > already reviewed in my queue. > > Andrew. > From aph at redhat.com Thu May 12 10:38:29 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 12 May 2016 11:38:29 +0100 Subject: jdk9/hs is CLOSED In-Reply-To: References: <5734462B.7030108@redhat.com> Message-ID: <57345D25.6020306@redhat.com> On 12/05/16 10:54, Jesper Wilhelmsson wrote: > Please note that FC only concerns enhancements and new features. jdk9/hs will > open again once we have a clean snapshot to push and then we can push bug fixes > all the way up to ZBB (currently planned to late October) modulo low priority > (p4-p5) bugs that can not go in after RDP1 (early September). > > Sorry for the long answer, but I hope it answered your question. Thank you. It was very helpful. It gives people outside Oracle a far better idea of what all this stuff means. Of course, any project has a schedule and I totally respect the right of the project leads to make such decisions. However, I have to make my (tedious, sorry) statement that this is a community project, and that important decisions which affect the whole community have to be discussed or at least explained. I have a responsibility as a member of the Governing Board who represents the wider OpenJDK community to keep reminding people of this. >From a more personal point of view, the AArch64 project is working on integrating intrinsics which are our versions of code in other ports, particularly x86. I don't know if simply adding these intrinsics to ports counts as a "new feature". In my opinion it does not. Andrew. From guido at trentalancia.net Thu May 12 11:37:41 2016 From: guido at trentalancia.net (Guido Trentalancia) Date: Thu, 12 May 2016 13:37:41 +0200 Subject: [PATCH 0/3] fix build errors with gcc6 Message-ID: <1463053061.12329.33.camel@trentalancia.net> Hello. The following set of three patches aims to fix the errors that currently occur during compilation of OpenJDK8U with gcc6 (version 6.1.0). Other two patches needed to build OpenJDK8U have been posted to the core-libs-dev with a similar message subject (for a total of five patches). I suppose most changes are trivial, except for 3/3, and therefore most of the patches can be applied easily. After applying the patchset, I can now build OpenJDK8 Update and it seems to be working fine (although it has not been extensively tested yet). The following build options have been used: --enable-unlimited-crypto --with-extra-cflags="-O3 -march=nehalem -mtune=nehalem -Wno-error -fpermissive -fno-delete-null-pointer-checks -fno-lifetime-dse" --with-extra-cxxflags="-O3 -march=nehalem -mtune=nehalem -Wno-error -fpermissive -fno-delete-null-pointer-checks -fno-lifetime-dse" --with-boot-jdk=/usr/lib64/jdk1.7.0_04 Thanks very much to Se?n Coffey and Erik Joelsson for pointing me to the right mailing list and to David Holmes for the initial review of patch 3/3. Regards, Guido From guido at trentalancia.net Thu May 12 11:38:45 2016 From: guido at trentalancia.net (Guido Trentalancia) Date: Thu, 12 May 2016 13:38:45 +0200 Subject: [PATCH 1/3] fix build errors with gcc6 Message-ID: <1463053125.12329.35.camel@trentalancia.net> The following (RFC) patch aims to fix the following build error with gcc6: /home/guido/new/jdk8u60/mercurial-rep/jdk8u60/hotspot/src/os/linux/vm/os_linux.cpp: In static member function ?static void* os::dll_load(const char*, char*, int)?: /home/guido/new/jdk8u60/mercurial-rep/jdk8u60/hotspot/src/os/linux/vm/os_linux.cpp:1939:66: warning: narrowing conversion of ?elf_head.Elf32_Ehdr::e_ident[4]? from ?unsigned char? to ?char? inside { } [-Wnarrowing] arch_t lib_arch={elf_head.e_machine,0,elf_head.e_ident[EI_CLASS], elf_head.e_ident[EI_DATA], NULL}; ~~~~~~~~~~~~~~~~~~~~~~~~~^ /home/guido/new/jdk8u60/mercurial-rep/jdk8u60/hotspot/src/os/linux/vm/os_linux.cpp:1939:93: warning: narrowing conversion of ?elf_head.Elf32_Ehdr::e_ident[5]? from ?unsigned char? to ?char? inside { } [-Wnarrowing] arch_t lib_arch={elf_head.e_machine,0,elf_head.e_ident[EI_CLASS], elf_head.e_ident[EI_DATA], NULL}; ~~~~~~~~~~~~~~~~~~~~~~~~^ /home/guido/new/jdk8u60/mercurial-rep/jdk8u60/hotspot/src/os/posix/vm/os_posix.cpp: In static member function ?static const char* os::Posix::describe_sa_flags(int, char*, size_t)?: /home/guido/new/jdk8u60/mercurial-rep/jdk8u60/hotspot/src/os/posix/vm/os_posix.cpp:612:3: error: narrowing conversion of ?2147483648u? from ?unsigned int? to ?int? inside { } [-Wnarrowing] }; ^ Signed-off-by: Guido Trentalancia --- hotspot/src/os/posix/vm/os_posix.cpp | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- jdk8u/hotspot/src/os/posix/vm/os_posix.cpp.orig 2016-05-11 00:43:47.586130518 +0200 +++ jdk8u/hotspot/src/os/posix/vm/os_posix.cpp 2016-05-11 00:29:51.359779693 +0200 @@ -594,7 +594,7 @@ const char* os::Posix::describe_sa_flags strncpy(buffer, "none", size); const struct { - int i; + unsigned int i; const char* s; } flaginfo [] = { { SA_NOCLDSTOP, "SA_NOCLDSTOP" }, @@ -612,7 +612,7 @@ const char* os::Posix::describe_sa_flags }; for (idx = 0; flaginfo[idx].s && remaining > 1; idx++) { - if (flags & flaginfo[idx].i) { + if (((unsigned int) flags) & flaginfo[idx].i) { if (first) { jio_snprintf(p, remaining, "%s", flaginfo[idx].s); first = false; From guido at trentalancia.net Thu May 12 11:41:58 2016 From: guido at trentalancia.net (Guido Trentalancia) Date: Thu, 12 May 2016 13:41:58 +0200 Subject: [PATCH 2/3] fix build errors with gcc6 Message-ID: <1463053318.12329.37.camel@trentalancia.net> The following (RFC) patch aims to fix the following build error with gcc6: /home/guido/new/jdk8u60/mercurial-rep/tmp/jdk8u/hotspot/src/share/vm/gc_implementation/g1/concurrentMark.cpp: In constructor ?G1PrintRegionLivenessInf oClosure::G1PrintRegionLivenessInfoClosure(outputStream*, const char*)?: /home/guido/new/jdk8u60/mercurial-rep/tmp/jdk8u/hotspot/src/share/vm/utilities/globalDefinitions.hpp:1384:37: error: unable to find string literal operator ?operator""tag? with ?const char [37]?, ?long unsigned int? arguments #define SIZE_FORMAT "%" PRIuPTR ^ /home/guido/new/jdk8u60/mercurial-rep/tmp/jdk8u/hotspot/src/share/vm/gc_implementation/g1/concurrentMark.cpp:4650:51: note: in expansion of macro ?SIZE_FORMAT? #define G1PPRL_SUM_BYTE_FORMAT(tag) " "tag": "SIZE_FORMAT ^~~~~~~~~~~ /home/guido/new/jdk8u60/mercurial-rep/tmp/jdk8u/hotspot/src/share/vm/gc_implementation/g1/concurrentMark.cpp:4671:18: note: in expansion of macro ?G1PPRL_SUM_BYTE_FORMAT? G1PPRL_SUM_BYTE_FORMAT("region-size"), ^~~~~~~~~~~~~~~~~~~~~~ /home/guido/new/jdk8u60/mercurial-rep/tmp/jdk8u/hotspot/src/share/vm/gc_implementation/g1/concurrentMark.cpp: In destructor ?G1PrintRegionLivenessInfoClosure::~G1PrintRegionLivenessInfoClosure()?: /home/guido/new/jdk8u60/mercurial-rep/tmp/jdk8u/hotspot/src/share/vm/gc_implementation/g1/concurrentMark.cpp:4651:47: error: unable to find string literal operator ?operator""tag? with ?const char [117]?, ?long unsigned int? arguments #define G1PPRL_SUM_MB_FORMAT(tag) " "tag": %1.2f MB" ^ /home/guido/new/jdk8u60/mercurial-rep/tmp/jdk8u/hotspot/src/share/vm/gc_implementation/g1/concurrentMark.cpp:4797:18: note: in expansion of macro ?G1PPRL_SUM_MB_FORMAT? G1PPRL_SUM_MB_FORMAT("code-roots"), ^~~~~~~~~~~~~~~~~~~~ Signed-off-by: Guido Trentalancia --- hotspot/src/share/vm/gc_implementation/g1/concurrentMark.cpp | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) --- jdk8u60/hotspot/src/share/vm/gc_implementation/g1/concurrentMark.cpp.orig 2016-05-10 22:03:20.470101554 +0200 +++ jdk8u60/hotspot/src/share/vm/gc_implementation/g1/concurrentMark.cpp 2016-05-10 22:04:53.681530187 +0200 @@ -4640,16 +4640,16 @@ CMTask::CMTask(uint worker_id, // For per-region info #define G1PPRL_TYPE_FORMAT " %-4s" #define G1PPRL_TYPE_H_FORMAT " %4s" -#define G1PPRL_BYTE_FORMAT " "SIZE_FORMAT_W(9) +#define G1PPRL_BYTE_FORMAT " " SIZE_FORMAT_W(9) #define G1PPRL_BYTE_H_FORMAT " %9s" #define G1PPRL_DOUBLE_FORMAT " %14.1f" #define G1PPRL_DOUBLE_H_FORMAT " %14s" // For summary info -#define G1PPRL_SUM_ADDR_FORMAT(tag) " "tag":"G1PPRL_ADDR_BASE_FORMAT -#define G1PPRL_SUM_BYTE_FORMAT(tag) " "tag": "SIZE_FORMAT -#define G1PPRL_SUM_MB_FORMAT(tag) " "tag": %1.2f MB" -#define G1PPRL_SUM_MB_PERC_FORMAT(tag) G1PPRL_SUM_MB_FORMAT(tag)" / %1.2f %%" +#define G1PPRL_SUM_ADDR_FORMAT(tag) " " tag ":" G1PPRL_ADDR_BASE_FORMAT +#define G1PPRL_SUM_BYTE_FORMAT(tag) " " tag ": " SIZE_FORMAT +#define G1PPRL_SUM_MB_FORMAT(tag) " " tag ": %1.2f MB" +#define G1PPRL_SUM_MB_PERC_FORMAT(tag) G1PPRL_SUM_MB_FORMAT(tag) " / %1.2f %%" G1PrintRegionLivenessInfoClosure:: G1PrintRegionLivenessInfoClosure(outputStream* out, const char* phase_name) From guido at trentalancia.net Thu May 12 11:45:38 2016 From: guido at trentalancia.net (Guido Trentalancia) Date: Thu, 12 May 2016 13:45:38 +0200 Subject: [PATCH 3/3] fix build errors with gcc6 Message-ID: <1463053538.12329.38.camel@trentalancia.net> The following (RFC) patch aims to fix the following build error with gcc6: /home/guido/new/openjdk/mercurial-rep/jdk8u-build1/hotspot/src/share/vm/prims/unsafe.cpp:1378:17: error: unable to find string literal operator ?operator""OBJ? with ?const char [40]?, ?long unsigned int? arguments #define CLS LANG"Class;" ^ /home/guido/new/openjdk/mercurial-rep/jdk8u-build1/hotspot/src/share/vm/prims/unsafe.cpp:1696:48: note: in expansion of macro ?CLS? {CC"defineAnonymousClass", CC"("DAC_Args")"CLS, FN_PTR(Unsafe_DefineAnonymousClass)}, ^~~ It includes backported bits from the following changeset of openjdk9: changeset: 8638:767f36deb0dc parent: 8599:3ebc4f430a74 user: bpittore date: Wed Jun 24 12:12:25 2015 -0400 summary: 8081202: Hotspot compile warning: "Invalid suffix on literal; C++11 requires a space between literal and identifier" Signed-off-by: Guido Trentalancia --- hotspot/src/share/vm/prims/unsafe.cpp | 350 +++++++++++++++++----------------- 1 file changed, 175 insertions(+), 175 deletions(-) --- jdk8u-build1/hotspot/src/share/vm/prims/unsafe.cpp.orig 2016-05-11 00:11:14.578791627 +0200 +++ jdk8u-build1/hotspot/src/share/vm/prims/unsafe.cpp 2016-05-11 14:28:02.122385186 +0200 @@ -1009,7 +1009,7 @@ UNSAFE_ENTRY(jclass, Unsafe_DefineClass0 UNSAFE_END -#define DAC_Args CLS"[B["OBJ +#define DAC_Args CLS "[B[" OBJ // define a class but do not make it known to the class loader or system dictionary // - host_class: supplies context for linkage, access control, protection domain, and class loader // - data: bytes of a class file, a raw memory address (length gives the number of bytes) @@ -1374,47 +1374,47 @@ UNSAFE_END #define LANG "Ljava/lang/" -#define OBJ LANG"Object;" -#define CLS LANG"Class;" -#define CTR LANG"reflect/Constructor;" -#define FLD LANG"reflect/Field;" -#define MTH LANG"reflect/Method;" -#define THR LANG"Throwable;" +#define OBJ LANG "Object;" +#define CLS LANG "Class;" +#define CTR LANG "reflect/Constructor;" +#define FLD LANG "reflect/Field;" +#define MTH LANG "reflect/Method;" +#define THR LANG "Throwable;" -#define DC0_Args LANG"String;[BII" -#define DC_Args DC0_Args LANG"ClassLoader;" "Ljava/security/ProtectionDomain;" +#define DC0_Args LANG "String;[BII" +#define DC_Args LANG "String;[BII" LANG "ClassLoader;" "Ljava/security/ProtectionDomain;" #define CC (char*) /*cast a literal from (const char*)*/ #define FN_PTR(f) CAST_FROM_FN_PTR(void*, &f) // define deprecated accessors for compabitility with 1.4.0 #define DECLARE_GETSETOOP_140(Boolean, Z) \ - {CC"get"#Boolean, CC"("OBJ"I)"#Z, FN_PTR(Unsafe_Get##Boolean##140)}, \ - {CC"put"#Boolean, CC"("OBJ"I"#Z")V", FN_PTR(Unsafe_Set##Boolean##140)} + {CC "get" #Boolean, CC "(" OBJ "I)" #Z, FN_PTR(Unsafe_Get##Boolean##140)}, \ + {CC "put" #Boolean, CC "(" OBJ "I" #Z ")V", FN_PTR(Unsafe_Set##Boolean##140)} // Note: In 1.4.1, getObject and kin take both int and long offsets. #define DECLARE_GETSETOOP_141(Boolean, Z) \ - {CC"get"#Boolean, CC"("OBJ"J)"#Z, FN_PTR(Unsafe_Get##Boolean)}, \ - {CC"put"#Boolean, CC"("OBJ"J"#Z")V", FN_PTR(Unsafe_Set##Boolean)} + {CC "get" #Boolean, CC "(" OBJ "J)" #Z, FN_PTR(Unsafe_Get##Boolean)}, \ + {CC "put" #Boolean, CC "(" OBJ "J" #Z ")V", FN_PTR(Unsafe_Set##Boolean)} // Note: In 1.5.0, there are volatile versions too #define DECLARE_GETSETOOP(Boolean, Z) \ - {CC"get"#Boolean, CC"("OBJ"J)"#Z, FN_PTR(Unsafe_Get##Boolean)}, \ - {CC"put"#Boolean, CC"("OBJ"J"#Z")V", FN_PTR(Unsafe_Set##Boolean)}, \ - {CC"get"#Boolean"Volatile", CC"("OBJ"J)"#Z, FN_PTR(Unsafe_Get##Boolean##Volatile)}, \ - {CC"put"#Boolean"Volatile", CC"("OBJ"J"#Z")V", FN_PTR(Unsafe_Set##Boolean##Volatile)} + {CC "get" #Boolean, CC "(" OBJ "J)" #Z, FN_PTR(Unsafe_Get##Boolean)}, \ + {CC "put" #Boolean, CC "(" OBJ "J" #Z ")V", FN_PTR(Unsafe_Set##Boolean)}, \ + {CC "get" #Boolean"Volatile", CC "(" OBJ "J)" #Z, FN_PTR(Unsafe_Get##Boolean##Volatile)}, \ + {CC "put" #Boolean"Volatile", CC "(" OBJ "J" #Z ")V", FN_PTR(Unsafe_Set##Boolean##Volatile)} #define DECLARE_GETSETNATIVE(Byte, B) \ - {CC"get"#Byte, CC"("ADR")"#B, FN_PTR(Unsafe_GetNative##Byte)}, \ - {CC"put"#Byte, CC"("ADR#B")V", FN_PTR(Unsafe_SetNative##Byte)} + {CC "get" #Byte, CC "(" ADR ")" #B, FN_PTR(Unsafe_GetNative##Byte)}, \ + {CC "put" #Byte, CC "(" ADR#B ")V", FN_PTR(Unsafe_SetNative##Byte)} // These are the methods for 1.4.0 static JNINativeMethod methods_140[] = { - {CC"getObject", CC"("OBJ"I)"OBJ"", FN_PTR(Unsafe_GetObject140)}, - {CC"putObject", CC"("OBJ"I"OBJ")V", FN_PTR(Unsafe_SetObject140)}, + {CC "getObject", CC "(" OBJ "I)" OBJ "", FN_PTR(Unsafe_GetObject140)}, + {CC "putObject", CC "(" OBJ "I" OBJ ")V", FN_PTR(Unsafe_SetObject140)}, DECLARE_GETSETOOP_140(Boolean, Z), DECLARE_GETSETOOP_140(Byte, B), @@ -1433,33 +1433,33 @@ static JNINativeMethod methods_140[] = { DECLARE_GETSETNATIVE(Float, F), DECLARE_GETSETNATIVE(Double, D), - {CC"getAddress", CC"("ADR")"ADR, FN_PTR(Unsafe_GetNativeAddress)}, - {CC"putAddress", CC"("ADR""ADR")V", FN_PTR(Unsafe_SetNativeAddress)}, + {CC "getAddress", CC "(" ADR ")" ADR, FN_PTR(Unsafe_GetNativeAddress)}, + {CC "putAddress", CC "(" ADR "" ADR ")V", FN_PTR(Unsafe_SetNativeAddress)}, - {CC"allocateMemory", CC"(J)"ADR, FN_PTR(Unsafe_AllocateMemory)}, - {CC"reallocateMemory", CC"("ADR"J)"ADR, FN_PTR(Unsafe_ReallocateMemory)}, - {CC"freeMemory", CC"("ADR")V", FN_PTR(Unsafe_FreeMemory)}, - - {CC"fieldOffset", CC"("FLD")I", FN_PTR(Unsafe_FieldOffset)}, - {CC"staticFieldBase", CC"("CLS")"OBJ, FN_PTR(Unsafe_StaticFieldBaseFromClass)}, - {CC"ensureClassInitialized",CC"("CLS")V", FN_PTR(Unsafe_EnsureClassInitialized)}, - {CC"arrayBaseOffset", CC"("CLS")I", FN_PTR(Unsafe_ArrayBaseOffset)}, - {CC"arrayIndexScale", CC"("CLS")I", FN_PTR(Unsafe_ArrayIndexScale)}, - {CC"addressSize", CC"()I", FN_PTR(Unsafe_AddressSize)}, - {CC"pageSize", CC"()I", FN_PTR(Unsafe_PageSize)}, - - {CC"defineClass", CC"("DC0_Args")"CLS, FN_PTR(Unsafe_DefineClass0)}, - {CC"defineClass", CC"("DC_Args")"CLS, FN_PTR(Unsafe_DefineClass)}, - {CC"allocateInstance", CC"("CLS")"OBJ, FN_PTR(Unsafe_AllocateInstance)}, - {CC"monitorEnter", CC"("OBJ")V", FN_PTR(Unsafe_MonitorEnter)}, - {CC"monitorExit", CC"("OBJ")V", FN_PTR(Unsafe_MonitorExit)}, - {CC"throwException", CC"("THR")V", FN_PTR(Unsafe_ThrowException)} + {CC "allocateMemory", CC "(J)" ADR, FN_PTR(Unsafe_AllocateMemory)}, + {CC "reallocateMemory", CC "(" ADR "J)" ADR, FN_PTR(Unsafe_ReallocateMemory)}, + {CC "freeMemory", CC "(" ADR ")V", FN_PTR(Unsafe_FreeMemory)}, + + {CC "fieldOffset", CC "(" FLD ")I", FN_PTR(Unsafe_FieldOffset)}, + {CC "staticFieldBase", CC "(" CLS ")" OBJ, FN_PTR(Unsafe_StaticFieldBaseFromClass)}, + {CC "ensureClassInitialized",CC "(" CLS ")V", FN_PTR(Unsafe_EnsureClassInitialized)}, + {CC "arrayBaseOffset", CC "(" CLS ")I", FN_PTR(Unsafe_ArrayBaseOffset)}, + {CC "arrayIndexScale", CC "(" CLS ")I", FN_PTR(Unsafe_ArrayIndexScale)}, + {CC "addressSize", CC "()I", FN_PTR(Unsafe_AddressSize)}, + {CC "pageSize", CC "()I", FN_PTR(Unsafe_PageSize)}, + + {CC "defineClass", CC "(" DC0_Args ")" CLS, FN_PTR(Unsafe_DefineClass0)}, + {CC "defineClass", CC "(" DC_Args ")" CLS, FN_PTR(Unsafe_DefineClass)}, + {CC "allocateInstance", CC "(" CLS ")" OBJ, FN_PTR(Unsafe_AllocateInstance)}, + {CC "monitorEnter", CC "(" OBJ ")V", FN_PTR(Unsafe_MonitorEnter)}, + {CC "monitorExit", CC "(" OBJ ")V", FN_PTR(Unsafe_MonitorExit)}, + {CC "throwException", CC "(" THR ")V", FN_PTR(Unsafe_ThrowException)} }; // These are the methods prior to the JSR 166 changes in 1.5.0 static JNINativeMethod methods_141[] = { - {CC"getObject", CC"("OBJ"J)"OBJ"", FN_PTR(Unsafe_GetObject)}, - {CC"putObject", CC"("OBJ"J"OBJ")V", FN_PTR(Unsafe_SetObject)}, + {CC "getObject", CC "(" OBJ "J)" OBJ"", FN_PTR(Unsafe_GetObject)}, + {CC "putObject", CC "(" OBJ "J" OBJ ")V", FN_PTR(Unsafe_SetObject)}, DECLARE_GETSETOOP_141(Boolean, Z), DECLARE_GETSETOOP_141(Byte, B), @@ -1478,37 +1478,37 @@ static JNINativeMethod methods_141[] = { DECLARE_GETSETNATIVE(Float, F), DECLARE_GETSETNATIVE(Double, D), - {CC"getAddress", CC"("ADR")"ADR, FN_PTR(Unsafe_GetNativeAddress)}, - {CC"putAddress", CC"("ADR""ADR")V", FN_PTR(Unsafe_SetNativeAddress)}, + {CC "getAddress", CC "(" ADR ")" ADR, FN_PTR(Unsafe_GetNativeAddress)}, + {CC "putAddress", CC "(" ADR "" ADR ")V", FN_PTR(Unsafe_SetNativeAddress)}, - {CC"allocateMemory", CC"(J)"ADR, FN_PTR(Unsafe_AllocateMemory)}, - {CC"reallocateMemory", CC"("ADR"J)"ADR, FN_PTR(Unsafe_ReallocateMemory)}, - {CC"freeMemory", CC"("ADR")V", FN_PTR(Unsafe_FreeMemory)}, - - {CC"objectFieldOffset", CC"("FLD")J", FN_PTR(Unsafe_ObjectFieldOffset)}, - {CC"staticFieldOffset", CC"("FLD")J", FN_PTR(Unsafe_StaticFieldOffset)}, - {CC"staticFieldBase", CC"("FLD")"OBJ, FN_PTR(Unsafe_StaticFieldBaseFromField)}, - {CC"ensureClassInitialized",CC"("CLS")V", FN_PTR(Unsafe_EnsureClassInitialized)}, - {CC"arrayBaseOffset", CC"("CLS")I", FN_PTR(Unsafe_ArrayBaseOffset)}, - {CC"arrayIndexScale", CC"("CLS")I", FN_PTR(Unsafe_ArrayIndexScale)}, - {CC"addressSize", CC"()I", FN_PTR(Unsafe_AddressSize)}, - {CC"pageSize", CC"()I", FN_PTR(Unsafe_PageSize)}, - - {CC"defineClass", CC"("DC0_Args")"CLS, FN_PTR(Unsafe_DefineClass0)}, - {CC"defineClass", CC"("DC_Args")"CLS, FN_PTR(Unsafe_DefineClass)}, - {CC"allocateInstance", CC"("CLS")"OBJ, FN_PTR(Unsafe_AllocateInstance)}, - {CC"monitorEnter", CC"("OBJ")V", FN_PTR(Unsafe_MonitorEnter)}, - {CC"monitorExit", CC"("OBJ")V", FN_PTR(Unsafe_MonitorExit)}, - {CC"throwException", CC"("THR")V", FN_PTR(Unsafe_ThrowException)} + {CC "allocateMemory", CC "(J)" ADR, FN_PTR(Unsafe_AllocateMemory)}, + {CC "reallocateMemory", CC "(" ADR "J)" ADR, FN_PTR(Unsafe_ReallocateMemory)}, + {CC "freeMemory", CC "(" ADR ")V", FN_PTR(Unsafe_FreeMemory)}, + + {CC "objectFieldOffset", CC "(" FLD ")J", FN_PTR(Unsafe_ObjectFieldOffset)}, + {CC "staticFieldOffset", CC "(" FLD ")J", FN_PTR(Unsafe_StaticFieldOffset)}, + {CC "staticFieldBase", CC "(" FLD ")" OBJ, FN_PTR(Unsafe_StaticFieldBaseFromField)}, + {CC "ensureClassInitialized",CC "(" CLS ")V", FN_PTR(Unsafe_EnsureClassInitialized)}, + {CC "arrayBaseOffset", CC "(" CLS ")I", FN_PTR(Unsafe_ArrayBaseOffset)}, + {CC "arrayIndexScale", CC "(" CLS ")I", FN_PTR(Unsafe_ArrayIndexScale)}, + {CC "addressSize", CC "()I", FN_PTR(Unsafe_AddressSize)}, + {CC "pageSize", CC "()I", FN_PTR(Unsafe_PageSize)}, + + {CC "defineClass", CC "(" DC0_Args ")" CLS, FN_PTR(Unsafe_DefineClass0)}, + {CC "defineClass", CC "(" DC_Args ")" CLS, FN_PTR(Unsafe_DefineClass)}, + {CC "allocateInstance", CC "(" CLS ")" OBJ, FN_PTR(Unsafe_AllocateInstance)}, + {CC "monitorEnter", CC "(" OBJ ")V", FN_PTR(Unsafe_MonitorEnter)}, + {CC "monitorExit", CC "(" OBJ ")V", FN_PTR(Unsafe_MonitorExit)}, + {CC "throwException", CC "(" THR ")V", FN_PTR(Unsafe_ThrowException)} }; // These are the methods prior to the JSR 166 changes in 1.6.0 static JNINativeMethod methods_15[] = { - {CC"getObject", CC"("OBJ"J)"OBJ"", FN_PTR(Unsafe_GetObject)}, - {CC"putObject", CC"("OBJ"J"OBJ")V", FN_PTR(Unsafe_SetObject)}, - {CC"getObjectVolatile",CC"("OBJ"J)"OBJ"", FN_PTR(Unsafe_GetObjectVolatile)}, - {CC"putObjectVolatile",CC"("OBJ"J"OBJ")V", FN_PTR(Unsafe_SetObjectVolatile)}, + {CC "getObject", CC "(" OBJ "J)" OBJ"", FN_PTR(Unsafe_GetObject)}, + {CC "putObject", CC "(" OBJ "J" OBJ ")V", FN_PTR(Unsafe_SetObject)}, + {CC "getObjectVolatile",CC "(" OBJ "J)" OBJ"", FN_PTR(Unsafe_GetObjectVolatile)}, + {CC "putObjectVolatile",CC "(" OBJ "J" OBJ ")V", FN_PTR(Unsafe_SetObjectVolatile)}, DECLARE_GETSETOOP(Boolean, Z), @@ -1528,42 +1528,42 @@ static JNINativeMethod methods_15[] = { DECLARE_GETSETNATIVE(Float, F), DECLARE_GETSETNATIVE(Double, D), - {CC"getAddress", CC"("ADR")"ADR, FN_PTR(Unsafe_GetNativeAddress)}, - {CC"putAddress", CC"("ADR""ADR")V", FN_PTR(Unsafe_SetNativeAddress)}, + {CC "getAddress", CC "(" ADR ")" ADR, FN_PTR(Unsafe_GetNativeAddress)}, + {CC "putAddress", CC "(" ADR "" ADR ")V", FN_PTR(Unsafe_SetNativeAddress)}, - {CC"allocateMemory", CC"(J)"ADR, FN_PTR(Unsafe_AllocateMemory)}, - {CC"reallocateMemory", CC"("ADR"J)"ADR, FN_PTR(Unsafe_ReallocateMemory)}, - {CC"freeMemory", CC"("ADR")V", FN_PTR(Unsafe_FreeMemory)}, - - {CC"objectFieldOffset", CC"("FLD")J", FN_PTR(Unsafe_ObjectFieldOffset)}, - {CC"staticFieldOffset", CC"("FLD")J", FN_PTR(Unsafe_StaticFieldOffset)}, - {CC"staticFieldBase", CC"("FLD")"OBJ, FN_PTR(Unsafe_StaticFieldBaseFromField)}, - {CC"ensureClassInitialized",CC"("CLS")V", FN_PTR(Unsafe_EnsureClassInitialized)}, - {CC"arrayBaseOffset", CC"("CLS")I", FN_PTR(Unsafe_ArrayBaseOffset)}, - {CC"arrayIndexScale", CC"("CLS")I", FN_PTR(Unsafe_ArrayIndexScale)}, - {CC"addressSize", CC"()I", FN_PTR(Unsafe_AddressSize)}, - {CC"pageSize", CC"()I", FN_PTR(Unsafe_PageSize)}, - - {CC"defineClass", CC"("DC0_Args")"CLS, FN_PTR(Unsafe_DefineClass0)}, - {CC"defineClass", CC"("DC_Args")"CLS, FN_PTR(Unsafe_DefineClass)}, - {CC"allocateInstance", CC"("CLS")"OBJ, FN_PTR(Unsafe_AllocateInstance)}, - {CC"monitorEnter", CC"("OBJ")V", FN_PTR(Unsafe_MonitorEnter)}, - {CC"monitorExit", CC"("OBJ")V", FN_PTR(Unsafe_MonitorExit)}, - {CC"throwException", CC"("THR")V", FN_PTR(Unsafe_ThrowException)}, - {CC"compareAndSwapObject", CC"("OBJ"J"OBJ""OBJ")Z", FN_PTR(Unsafe_CompareAndSwapObject)}, - {CC"compareAndSwapInt", CC"("OBJ"J""I""I"")Z", FN_PTR(Unsafe_CompareAndSwapInt)}, - {CC"compareAndSwapLong", CC"("OBJ"J""J""J"")Z", FN_PTR(Unsafe_CompareAndSwapLong)}, - {CC"park", CC"(ZJ)V", FN_PTR(Unsafe_Park)}, - {CC"unpark", CC"("OBJ")V", FN_PTR(Unsafe_Unpark)} + {CC "allocateMemory", CC "(J)" ADR, FN_PTR(Unsafe_AllocateMemory)}, + {CC "reallocateMemory", CC "(" ADR "J)" ADR, FN_PTR(Unsafe_ReallocateMemory)}, + {CC "freeMemory", CC "(" ADR ")V", FN_PTR(Unsafe_FreeMemory)}, + + {CC "objectFieldOffset", CC "(" FLD ")J", FN_PTR(Unsafe_ObjectFieldOffset)}, + {CC "staticFieldOffset", CC "(" FLD ")J", FN_PTR(Unsafe_StaticFieldOffset)}, + {CC "staticFieldBase", CC "(" FLD ")" OBJ, FN_PTR(Unsafe_StaticFieldBaseFromField)}, + {CC "ensureClassInitialized",CC "(" CLS ")V", FN_PTR(Unsafe_EnsureClassInitialized)}, + {CC "arrayBaseOffset", CC "(" CLS ")I", FN_PTR(Unsafe_ArrayBaseOffset)}, + {CC "arrayIndexScale", CC "(" CLS ")I", FN_PTR(Unsafe_ArrayIndexScale)}, + {CC "addressSize", CC "()I", FN_PTR(Unsafe_AddressSize)}, + {CC "pageSize", CC "()I", FN_PTR(Unsafe_PageSize)}, + + {CC "defineClass", CC "(" DC0_Args ")" CLS, FN_PTR(Unsafe_DefineClass0)}, + {CC "defineClass", CC "(" DC_Args ")" CLS, FN_PTR(Unsafe_DefineClass)}, + {CC "allocateInstance", CC "(" CLS ")" OBJ, FN_PTR(Unsafe_AllocateInstance)}, + {CC "monitorEnter", CC "(" OBJ ")V", FN_PTR(Unsafe_MonitorEnter)}, + {CC "monitorExit", CC "(" OBJ ")V", FN_PTR(Unsafe_MonitorExit)}, + {CC "throwException", CC "(" THR ")V", FN_PTR(Unsafe_ThrowException)}, + {CC "compareAndSwapObject", CC "(" OBJ "J" OBJ "" OBJ ")Z", FN_PTR(Unsafe_CompareAndSwapObject)}, + {CC "compareAndSwapInt", CC "(" OBJ "J""I""I"")Z", FN_PTR(Unsafe_CompareAndSwapInt)}, + {CC "compareAndSwapLong", CC "(" OBJ "J""J""J"")Z", FN_PTR(Unsafe_CompareAndSwapLong)}, + {CC "park", CC "(ZJ)V", FN_PTR(Unsafe_Park)}, + {CC "unpark", CC "(" OBJ ")V", FN_PTR(Unsafe_Unpark)} }; // These are the methods for 1.6.0 and 1.7.0 static JNINativeMethod methods_16[] = { - {CC"getObject", CC"("OBJ"J)"OBJ"", FN_PTR(Unsafe_GetObject)}, - {CC"putObject", CC"("OBJ"J"OBJ")V", FN_PTR(Unsafe_SetObject)}, - {CC"getObjectVolatile",CC"("OBJ"J)"OBJ"", FN_PTR(Unsafe_GetObjectVolatile)}, - {CC"putObjectVolatile",CC"("OBJ"J"OBJ")V", FN_PTR(Unsafe_SetObjectVolatile)}, + {CC "getObject", CC "(" OBJ "J)" OBJ"", FN_PTR(Unsafe_GetObject)}, + {CC "putObject", CC "(" OBJ "J" OBJ ")V", FN_PTR(Unsafe_SetObject)}, + {CC "getObjectVolatile",CC "(" OBJ "J)" OBJ"", FN_PTR(Unsafe_GetObjectVolatile)}, + {CC "putObjectVolatile",CC "(" OBJ "J" OBJ ")V", FN_PTR(Unsafe_SetObjectVolatile)}, DECLARE_GETSETOOP(Boolean, Z), DECLARE_GETSETOOP(Byte, B), @@ -1582,45 +1582,45 @@ static JNINativeMethod methods_16[] = { DECLARE_GETSETNATIVE(Float, F), DECLARE_GETSETNATIVE(Double, D), - {CC"getAddress", CC"("ADR")"ADR, FN_PTR(Unsafe_GetNativeAddress)}, - {CC"putAddress", CC"("ADR""ADR")V", FN_PTR(Unsafe_SetNativeAddress)}, + {CC "getAddress", CC "(" ADR ")" ADR, FN_PTR(Unsafe_GetNativeAddress)}, + {CC "putAddress", CC "(" ADR "" ADR ")V", FN_PTR(Unsafe_SetNativeAddress)}, - {CC"allocateMemory", CC"(J)"ADR, FN_PTR(Unsafe_AllocateMemory)}, - {CC"reallocateMemory", CC"("ADR"J)"ADR, FN_PTR(Unsafe_ReallocateMemory)}, - {CC"freeMemory", CC"("ADR")V", FN_PTR(Unsafe_FreeMemory)}, - - {CC"objectFieldOffset", CC"("FLD")J", FN_PTR(Unsafe_ObjectFieldOffset)}, - {CC"staticFieldOffset", CC"("FLD")J", FN_PTR(Unsafe_StaticFieldOffset)}, - {CC"staticFieldBase", CC"("FLD")"OBJ, FN_PTR(Unsafe_StaticFieldBaseFromField)}, - {CC"ensureClassInitialized",CC"("CLS")V", FN_PTR(Unsafe_EnsureClassInitialized)}, - {CC"arrayBaseOffset", CC"("CLS")I", FN_PTR(Unsafe_ArrayBaseOffset)}, - {CC"arrayIndexScale", CC"("CLS")I", FN_PTR(Unsafe_ArrayIndexScale)}, - {CC"addressSize", CC"()I", FN_PTR(Unsafe_AddressSize)}, - {CC"pageSize", CC"()I", FN_PTR(Unsafe_PageSize)}, - - {CC"defineClass", CC"("DC0_Args")"CLS, FN_PTR(Unsafe_DefineClass0)}, - {CC"defineClass", CC"("DC_Args")"CLS, FN_PTR(Unsafe_DefineClass)}, - {CC"allocateInstance", CC"("CLS")"OBJ, FN_PTR(Unsafe_AllocateInstance)}, - {CC"monitorEnter", CC"("OBJ")V", FN_PTR(Unsafe_MonitorEnter)}, - {CC"monitorExit", CC"("OBJ")V", FN_PTR(Unsafe_MonitorExit)}, - {CC"tryMonitorEnter", CC"("OBJ")Z", FN_PTR(Unsafe_TryMonitorEnter)}, - {CC"throwException", CC"("THR")V", FN_PTR(Unsafe_ThrowException)}, - {CC"compareAndSwapObject", CC"("OBJ"J"OBJ""OBJ")Z", FN_PTR(Unsafe_CompareAndSwapObject)}, - {CC"compareAndSwapInt", CC"("OBJ"J""I""I"")Z", FN_PTR(Unsafe_CompareAndSwapInt)}, - {CC"compareAndSwapLong", CC"("OBJ"J""J""J"")Z", FN_PTR(Unsafe_CompareAndSwapLong)}, - {CC"putOrderedObject", CC"("OBJ"J"OBJ")V", FN_PTR(Unsafe_SetOrderedObject)}, - {CC"putOrderedInt", CC"("OBJ"JI)V", FN_PTR(Unsafe_SetOrderedInt)}, - {CC"putOrderedLong", CC"("OBJ"JJ)V", FN_PTR(Unsafe_SetOrderedLong)}, - {CC"park", CC"(ZJ)V", FN_PTR(Unsafe_Park)}, - {CC"unpark", CC"("OBJ")V", FN_PTR(Unsafe_Unpark)} + {CC "allocateMemory", CC "(J)" ADR, FN_PTR(Unsafe_AllocateMemory)}, + {CC "reallocateMemory", CC "(" ADR "J)" ADR, FN_PTR(Unsafe_ReallocateMemory)}, + {CC "freeMemory", CC "(" ADR ")V", FN_PTR(Unsafe_FreeMemory)}, + + {CC "objectFieldOffset", CC "(" FLD ")J", FN_PTR(Unsafe_ObjectFieldOffset)}, + {CC "staticFieldOffset", CC "(" FLD ")J", FN_PTR(Unsafe_StaticFieldOffset)}, + {CC "staticFieldBase", CC "(" FLD ")" OBJ, FN_PTR(Unsafe_StaticFieldBaseFromField)}, + {CC "ensureClassInitialized",CC "(" CLS ")V", FN_PTR(Unsafe_EnsureClassInitialized)}, + {CC "arrayBaseOffset", CC "(" CLS ")I", FN_PTR(Unsafe_ArrayBaseOffset)}, + {CC "arrayIndexScale", CC "(" CLS ")I", FN_PTR(Unsafe_ArrayIndexScale)}, + {CC "addressSize", CC "()I", FN_PTR(Unsafe_AddressSize)}, + {CC "pageSize", CC "()I", FN_PTR(Unsafe_PageSize)}, + + {CC "defineClass", CC "(" DC0_Args ")" CLS, FN_PTR(Unsafe_DefineClass0)}, + {CC "defineClass", CC "(" DC_Args ")" CLS, FN_PTR(Unsafe_DefineClass)}, + {CC "allocateInstance", CC "(" CLS ")" OBJ, FN_PTR(Unsafe_AllocateInstance)}, + {CC "monitorEnter", CC "(" OBJ ")V", FN_PTR(Unsafe_MonitorEnter)}, + {CC "monitorExit", CC "(" OBJ ")V", FN_PTR(Unsafe_MonitorExit)}, + {CC "tryMonitorEnter", CC "(" OBJ ")Z", FN_PTR(Unsafe_TryMonitorEnter)}, + {CC "throwException", CC "(" THR ")V", FN_PTR(Unsafe_ThrowException)}, + {CC "compareAndSwapObject", CC "(" OBJ "J" OBJ "" OBJ ")Z", FN_PTR(Unsafe_CompareAndSwapObject)}, + {CC "compareAndSwapInt", CC "(" OBJ "J""I""I"")Z", FN_PTR(Unsafe_CompareAndSwapInt)}, + {CC "compareAndSwapLong", CC "(" OBJ "J""J""J"")Z", FN_PTR(Unsafe_CompareAndSwapLong)}, + {CC "putOrderedObject", CC "(" OBJ "J" OBJ ")V", FN_PTR(Unsafe_SetOrderedObject)}, + {CC "putOrderedInt", CC "(" OBJ "JI)V", FN_PTR(Unsafe_SetOrderedInt)}, + {CC "putOrderedLong", CC "(" OBJ "JJ)V", FN_PTR(Unsafe_SetOrderedLong)}, + {CC "park", CC "(ZJ)V", FN_PTR(Unsafe_Park)}, + {CC "unpark", CC "(" OBJ ")V", FN_PTR(Unsafe_Unpark)} }; // These are the methods for 1.8.0 static JNINativeMethod methods_18[] = { - {CC"getObject", CC"("OBJ"J)"OBJ"", FN_PTR(Unsafe_GetObject)}, - {CC"putObject", CC"("OBJ"J"OBJ")V", FN_PTR(Unsafe_SetObject)}, - {CC"getObjectVolatile",CC"("OBJ"J)"OBJ"", FN_PTR(Unsafe_GetObjectVolatile)}, - {CC"putObjectVolatile",CC"("OBJ"J"OBJ")V", FN_PTR(Unsafe_SetObjectVolatile)}, + {CC "getObject", CC "(" OBJ "J)" OBJ"", FN_PTR(Unsafe_GetObject)}, + {CC "putObject", CC "(" OBJ "J" OBJ ")V", FN_PTR(Unsafe_SetObject)}, + {CC "getObjectVolatile",CC "(" OBJ "J)" OBJ"", FN_PTR(Unsafe_GetObjectVolatile)}, + {CC "putObjectVolatile",CC "(" OBJ "J" OBJ ")V", FN_PTR(Unsafe_SetObjectVolatile)}, DECLARE_GETSETOOP(Boolean, Z), DECLARE_GETSETOOP(Byte, B), @@ -1639,71 +1639,71 @@ static JNINativeMethod methods_18[] = { DECLARE_GETSETNATIVE(Float, F), DECLARE_GETSETNATIVE(Double, D), - {CC"getAddress", CC"("ADR")"ADR, FN_PTR(Unsafe_GetNativeAddress)}, - {CC"putAddress", CC"("ADR""ADR")V", FN_PTR(Unsafe_SetNativeAddress)}, + {CC "getAddress", CC "(" ADR ")" ADR, FN_PTR(Unsafe_GetNativeAddress)}, + {CC "putAddress", CC "(" ADR "" ADR ")V", FN_PTR(Unsafe_SetNativeAddress)}, - {CC"allocateMemory", CC"(J)"ADR, FN_PTR(Unsafe_AllocateMemory)}, - {CC"reallocateMemory", CC"("ADR"J)"ADR, FN_PTR(Unsafe_ReallocateMemory)}, - {CC"freeMemory", CC"("ADR")V", FN_PTR(Unsafe_FreeMemory)}, - - {CC"objectFieldOffset", CC"("FLD")J", FN_PTR(Unsafe_ObjectFieldOffset)}, - {CC"staticFieldOffset", CC"("FLD")J", FN_PTR(Unsafe_StaticFieldOffset)}, - {CC"staticFieldBase", CC"("FLD")"OBJ, FN_PTR(Unsafe_StaticFieldBaseFromField)}, - {CC"ensureClassInitialized",CC"("CLS")V", FN_PTR(Unsafe_EnsureClassInitialized)}, - {CC"arrayBaseOffset", CC"("CLS")I", FN_PTR(Unsafe_ArrayBaseOffset)}, - {CC"arrayIndexScale", CC"("CLS")I", FN_PTR(Unsafe_ArrayIndexScale)}, - {CC"addressSize", CC"()I", FN_PTR(Unsafe_AddressSize)}, - {CC"pageSize", CC"()I", FN_PTR(Unsafe_PageSize)}, - - {CC"defineClass", CC"("DC_Args")"CLS, FN_PTR(Unsafe_DefineClass)}, - {CC"allocateInstance", CC"("CLS")"OBJ, FN_PTR(Unsafe_AllocateInstance)}, - {CC"monitorEnter", CC"("OBJ")V", FN_PTR(Unsafe_MonitorEnter)}, - {CC"monitorExit", CC"("OBJ")V", FN_PTR(Unsafe_MonitorExit)}, - {CC"tryMonitorEnter", CC"("OBJ")Z", FN_PTR(Unsafe_TryMonitorEnter)}, - {CC"throwException", CC"("THR")V", FN_PTR(Unsafe_ThrowException)}, - {CC"compareAndSwapObject", CC"("OBJ"J"OBJ""OBJ")Z", FN_PTR(Unsafe_CompareAndSwapObject)}, - {CC"compareAndSwapInt", CC"("OBJ"J""I""I"")Z", FN_PTR(Unsafe_CompareAndSwapInt)}, - {CC"compareAndSwapLong", CC"("OBJ"J""J""J"")Z", FN_PTR(Unsafe_CompareAndSwapLong)}, - {CC"putOrderedObject", CC"("OBJ"J"OBJ")V", FN_PTR(Unsafe_SetOrderedObject)}, - {CC"putOrderedInt", CC"("OBJ"JI)V", FN_PTR(Unsafe_SetOrderedInt)}, - {CC"putOrderedLong", CC"("OBJ"JJ)V", FN_PTR(Unsafe_SetOrderedLong)}, - {CC"park", CC"(ZJ)V", FN_PTR(Unsafe_Park)}, - {CC"unpark", CC"("OBJ")V", FN_PTR(Unsafe_Unpark)} + {CC "allocateMemory", CC "(J)" ADR, FN_PTR(Unsafe_AllocateMemory)}, + {CC "reallocateMemory", CC "(" ADR "J)" ADR, FN_PTR(Unsafe_ReallocateMemory)}, + {CC "freeMemory", CC "(" ADR ")V", FN_PTR(Unsafe_FreeMemory)}, + + {CC "objectFieldOffset", CC "(" FLD ")J", FN_PTR(Unsafe_ObjectFieldOffset)}, + {CC "staticFieldOffset", CC "(" FLD ")J", FN_PTR(Unsafe_StaticFieldOffset)}, + {CC "staticFieldBase", CC "(" FLD ")" OBJ, FN_PTR(Unsafe_StaticFieldBaseFromField)}, + {CC "ensureClassInitialized",CC "(" CLS ")V", FN_PTR(Unsafe_EnsureClassInitialized)}, + {CC "arrayBaseOffset", CC "(" CLS ")I", FN_PTR(Unsafe_ArrayBaseOffset)}, + {CC "arrayIndexScale", CC "(" CLS ")I", FN_PTR(Unsafe_ArrayIndexScale)}, + {CC "addressSize", CC "()I", FN_PTR(Unsafe_AddressSize)}, + {CC "pageSize", CC "()I", FN_PTR(Unsafe_PageSize)}, + + {CC "defineClass", CC "(" DC_Args ")" CLS, FN_PTR(Unsafe_DefineClass)}, + {CC "allocateInstance", CC "(" CLS ")" OBJ, FN_PTR(Unsafe_AllocateInstance)}, + {CC "monitorEnter", CC "(" OBJ ")V", FN_PTR(Unsafe_MonitorEnter)}, + {CC "monitorExit", CC "(" OBJ ")V", FN_PTR(Unsafe_MonitorExit)}, + {CC "tryMonitorEnter", CC "(" OBJ ")Z", FN_PTR(Unsafe_TryMonitorEnter)}, + {CC "throwException", CC "(" THR ")V", FN_PTR(Unsafe_ThrowException)}, + {CC "compareAndSwapObject", CC "(" OBJ "J" OBJ "" OBJ ")Z", FN_PTR(Unsafe_CompareAndSwapObject)}, + {CC "compareAndSwapInt", CC "(" OBJ "J""I""I"")Z", FN_PTR(Unsafe_CompareAndSwapInt)}, + {CC "compareAndSwapLong", CC "(" OBJ "J""J""J"")Z", FN_PTR(Unsafe_CompareAndSwapLong)}, + {CC "putOrderedObject", CC "(" OBJ "J" OBJ ")V", FN_PTR(Unsafe_SetOrderedObject)}, + {CC "putOrderedInt", CC "(" OBJ "JI)V", FN_PTR(Unsafe_SetOrderedInt)}, + {CC "putOrderedLong", CC "(" OBJ "JJ)V", FN_PTR(Unsafe_SetOrderedLong)}, + {CC "park", CC "(ZJ)V", FN_PTR(Unsafe_Park)}, + {CC "unpark", CC "(" OBJ ")V", FN_PTR(Unsafe_Unpark)} }; JNINativeMethod loadavg_method[] = { - {CC"getLoadAverage", CC"([DI)I", FN_PTR(Unsafe_Loadavg)} + {CC "getLoadAverage", CC "([DI)I", FN_PTR(Unsafe_Loadavg)} }; JNINativeMethod prefetch_methods[] = { - {CC"prefetchRead", CC"("OBJ"J)V", FN_PTR(Unsafe_PrefetchRead)}, - {CC"prefetchWrite", CC"("OBJ"J)V", FN_PTR(Unsafe_PrefetchWrite)}, - {CC"prefetchReadStatic", CC"("OBJ"J)V", FN_PTR(Unsafe_PrefetchRead)}, - {CC"prefetchWriteStatic",CC"("OBJ"J)V", FN_PTR(Unsafe_PrefetchWrite)} + {CC "prefetchRead", CC "(" OBJ "J)V", FN_PTR(Unsafe_PrefetchRead)}, + {CC "prefetchWrite", CC "(" OBJ "J)V", FN_PTR(Unsafe_PrefetchWrite)}, + {CC "prefetchReadStatic", CC "(" OBJ "J)V", FN_PTR(Unsafe_PrefetchRead)}, + {CC "prefetchWriteStatic",CC "(" OBJ "J)V", FN_PTR(Unsafe_PrefetchWrite)} }; JNINativeMethod memcopy_methods_17[] = { - {CC"copyMemory", CC"("OBJ"J"OBJ"JJ)V", FN_PTR(Unsafe_CopyMemory2)}, - {CC"setMemory", CC"("OBJ"JJB)V", FN_PTR(Unsafe_SetMemory2)} + {CC "copyMemory", CC "(" OBJ "J" OBJ "JJ)V", FN_PTR(Unsafe_CopyMemory2)}, + {CC "setMemory", CC "(" OBJ "JJB)V", FN_PTR(Unsafe_SetMemory2)} }; JNINativeMethod memcopy_methods_15[] = { - {CC"setMemory", CC"("ADR"JB)V", FN_PTR(Unsafe_SetMemory)}, - {CC"copyMemory", CC"("ADR ADR"J)V", FN_PTR(Unsafe_CopyMemory)} + {CC "setMemory", CC "(" ADR "JB)V", FN_PTR(Unsafe_SetMemory)}, + {CC "copyMemory", CC "(" ADR ADR "J)V", FN_PTR(Unsafe_CopyMemory)} }; JNINativeMethod anonk_methods[] = { - {CC"defineAnonymousClass", CC"("DAC_Args")"CLS, FN_PTR(Unsafe_DefineAnonymousClass)}, + {CC "defineAnonymousClass", CC "(" DAC_Args ")" CLS, FN_PTR(Unsafe_DefineAnonymousClass)}, }; JNINativeMethod lform_methods[] = { - {CC"shouldBeInitialized",CC"("CLS")Z", FN_PTR(Unsafe_ShouldBeInitialized)}, + {CC "shouldBeInitialized", CC "(" CLS ")Z", FN_PTR(Unsafe_ShouldBeInitialized)}, }; JNINativeMethod fence_methods[] = { - {CC"loadFence", CC"()V", FN_PTR(Unsafe_LoadFence)}, - {CC"storeFence", CC"()V", FN_PTR(Unsafe_StoreFence)}, - {CC"fullFence", CC"()V", FN_PTR(Unsafe_FullFence)}, + {CC "loadFence", CC "()V", FN_PTR(Unsafe_LoadFence)}, + {CC "storeFence", CC "()V", FN_PTR(Unsafe_StoreFence)}, + {CC "fullFence", CC "()V", FN_PTR(Unsafe_FullFence)}, }; #undef CC From volker.simonis at gmail.com Thu May 12 12:26:59 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 12 May 2016 14:26:59 +0200 Subject: SIGILL crashes JVM on PPC64 LE In-Reply-To: <5733B30D.6010201@linux.vnet.ibm.com> References: <5733B30D.6010201@linux.vnet.ibm.com> Message-ID: Hi Gustavo, thanks for the bug report. The hs_err file you provided indicates that this crash happened with Ubuntu's openjdk 8 version. Can you still reproduce this with the the newest jdk9 builds? Also, I can see from the hs_err file that the crash happened in the C2 compiled method java.util.TimSort.countRunAndMakeAscending which doesn't seem to be related to nio and unsafe. Ideally, you could post an easy test case to reproduce the problem. If that's not possible, it would be helpful if you could post the output of a failing run with "-XX:CompileCommand=print,java.util.TimSort::countRunAndMakeAscending -XX:CompileCommand=option,java.util.TimSort::countRunAndMakeAscending,PrintOptoAssembly". In order to get the disassembly output for compiled methods you have to build the hsdis library from hotspot/src/share/tools/hsdis (it has a README with build instructions). Regards, Volker On Thu, May 12, 2016 at 12:32 AM, Gustavo Romero wrote: > Hi > > I'm getting a nasty SIGILL that crashes the JVM on PPC64 LE. > > hs_err log: > http://hastebin.com/raw/fovagunaci > > The application employs methods from both java.nio.ByteBuffer and > sun.misc.Unsafe classes in order to write and read from an allocated buffer. > > A interesting thing is that after debugging the instruction that caused the > said SIGILL: > > 0x3fff902839a4: cmpwi cr6,r17,0 > 0x3fff902839a8: beq cr6,0x3fff90283ae4 > 0x3fff902839ac: .long 0xea2f0013 <============ illegal instruction > 0x3fff902839b0: add r15,r15,r17 > 0x3fff902839b4: add r14,r17,r14 > > I found that when its endianness is changed it turns out to be a valid > instruction: vsel v24,v0,v5,v31 > > However, I'm still unable to determine if it's an application issue, something > with JVM unsafe interface code, or something else. > > Any clue on how to narrow down this SIGILL? > > Thank you! > > Regards, > Gustavo > From volker.simonis at gmail.com Thu May 12 12:39:41 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 12 May 2016 14:39:41 +0200 Subject: SIGILL crashes JVM on PPC64 LE In-Reply-To: References: <5733B30D.6010201@linux.vnet.ibm.com> Message-ID: And I forgot to mention: I've checked and we don't emit vsel instructions in jdk8 on ppc. So it must be a coincidence that changing the endianess of the offending instruction yields a valid 'vsel' instruction. On Thu, May 12, 2016 at 2:26 PM, Volker Simonis wrote: > Hi Gustavo, > > thanks for the bug report. The hs_err file you provided indicates that > this crash happened with Ubuntu's openjdk 8 version. Can you still > reproduce this with the the newest jdk9 builds? > > Also, I can see from the hs_err file that the crash happened in the C2 > compiled method java.util.TimSort.countRunAndMakeAscending which > doesn't seem to be related to nio and unsafe. > > Ideally, you could post an easy test case to reproduce the problem. If > that's not possible, it would be helpful if you could post the output > of a failing run with > "-XX:CompileCommand=print,java.util.TimSort::countRunAndMakeAscending > -XX:CompileCommand=option,java.util.TimSort::countRunAndMakeAscending,PrintOptoAssembly". > In order to get the disassembly output for compiled methods you have > to build the hsdis library from hotspot/src/share/tools/hsdis (it has > a README with build instructions). > > Regards, > Volker > > > On Thu, May 12, 2016 at 12:32 AM, Gustavo Romero > wrote: >> Hi >> >> I'm getting a nasty SIGILL that crashes the JVM on PPC64 LE. >> >> hs_err log: >> http://hastebin.com/raw/fovagunaci >> >> The application employs methods from both java.nio.ByteBuffer and >> sun.misc.Unsafe classes in order to write and read from an allocated buffer. >> >> A interesting thing is that after debugging the instruction that caused the >> said SIGILL: >> >> 0x3fff902839a4: cmpwi cr6,r17,0 >> 0x3fff902839a8: beq cr6,0x3fff90283ae4 >> 0x3fff902839ac: .long 0xea2f0013 <============ illegal instruction >> 0x3fff902839b0: add r15,r15,r17 >> 0x3fff902839b4: add r14,r17,r14 >> >> I found that when its endianness is changed it turns out to be a valid >> instruction: vsel v24,v0,v5,v31 >> >> However, I'm still unable to determine if it's an application issue, something >> with JVM unsafe interface code, or something else. >> >> Any clue on how to narrow down this SIGILL? >> >> Thank you! >> >> Regards, >> Gustavo >> From christian.tornqvist at oracle.com Thu May 12 14:06:34 2016 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Thu, 12 May 2016 10:06:34 -0400 Subject: jdk9/hs is CLOSED In-Reply-To: <57345D25.6020306@redhat.com> References: <5734462B.7030108@redhat.com> <57345D25.6020306@redhat.com> Message-ID: <0c8501d1ac57$7e9d3820$7bd7a860$@oracle.com> Hi Andrew, FC means that no RFE/Features can be pushed without approval from the JDK 9 Release Team. The updated schedule was published to the OpenJDK community in December last year by Mark Reinhold. Thanks, Christian -----Original Message----- From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On Behalf Of Andrew Haley Sent: Thursday, May 12, 2016 6:38 AM To: hotspot-dev at openjdk.java.net Developers Subject: Re: jdk9/hs is CLOSED On 12/05/16 10:54, Jesper Wilhelmsson wrote: > Please note that FC only concerns enhancements and new features. > jdk9/hs will open again once we have a clean snapshot to push and then > we can push bug fixes all the way up to ZBB (currently planned to late > October) modulo low priority > (p4-p5) bugs that can not go in after RDP1 (early September). > > Sorry for the long answer, but I hope it answered your question. Thank you. It was very helpful. It gives people outside Oracle a far better idea of what all this stuff means. Of course, any project has a schedule and I totally respect the right of the project leads to make such decisions. However, I have to make my (tedious, sorry) statement that this is a community project, and that important decisions which affect the whole community have to be discussed or at least explained. I have a responsibility as a member of the Governing Board who represents the wider OpenJDK community to keep reminding people of this. >From a more personal point of view, the AArch64 project is working on integrating intrinsics which are our versions of code in other ports, particularly x86. I don't know if simply adding these intrinsics to ports counts as a "new feature". In my opinion it does not. Andrew. From aph at redhat.com Thu May 12 14:10:47 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 12 May 2016 15:10:47 +0100 Subject: jdk9/hs is CLOSED In-Reply-To: <0c8501d1ac57$7e9d3820$7bd7a860$@oracle.com> References: <5734462B.7030108@redhat.com> <57345D25.6020306@redhat.com> <0c8501d1ac57$7e9d3820$7bd7a860$@oracle.com> Message-ID: <57348EE7.4030608@redhat.com> On 05/12/2016 03:06 PM, Christian Tornqvist wrote: > FC means that no RFE/Features can be pushed without approval from the JDK 9 > Release Team. The updated schedule was published to the OpenJDK community in > December last year by Mark Reinhold. You're not helping very much. Or rather, you're restating what I've heard already but I don't know what that means. Is finishing off the compact string intrinsics for AArch64 a RFE/Feature or not? I don't know. As far as I'm concerned it's a work in progress, which started some time ago. Andrew. From jesper.wilhelmsson at oracle.com Thu May 12 14:12:51 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 12 May 2016 16:12:51 +0200 Subject: jdk9/hs is CLOSED In-Reply-To: <57348EE7.4030608@redhat.com> References: <5734462B.7030108@redhat.com> <57345D25.6020306@redhat.com> <0c8501d1ac57$7e9d3820$7bd7a860$@oracle.com> <57348EE7.4030608@redhat.com> Message-ID: <93697210-ae23-dd59-6efd-29549e7ab676@oracle.com> Den 12/5/16 kl. 16:10, skrev Andrew Haley: > On 05/12/2016 03:06 PM, Christian Tornqvist wrote: >> FC means that no RFE/Features can be pushed without approval from the JDK 9 >> Release Team. The updated schedule was published to the OpenJDK community in >> December last year by Mark Reinhold. > > You're not helping very much. Or rather, you're restating what I've > heard already but I don't know what that means. Is finishing off the > compact string intrinsics for AArch64 a RFE/Feature or not? I don't > know. As far as I'm concerned it's a work in progress, which started > some time ago. Do you have a JBS ID for this work? /Jesper > > Andrew. > From aph at redhat.com Thu May 12 14:52:32 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 12 May 2016 15:52:32 +0100 Subject: jdk9/hs is CLOSED In-Reply-To: <93697210-ae23-dd59-6efd-29549e7ab676@oracle.com> References: <5734462B.7030108@redhat.com> <57345D25.6020306@redhat.com> <0c8501d1ac57$7e9d3820$7bd7a860$@oracle.com> <57348EE7.4030608@redhat.com> <93697210-ae23-dd59-6efd-29549e7ab676@oracle.com> Message-ID: <573498B0.5080304@redhat.com> On 05/12/2016 03:12 PM, Jesper Wilhelmsson wrote: > Den 12/5/16 kl. 16:10, skrev Andrew Haley: >> On 05/12/2016 03:06 PM, Christian Tornqvist wrote: >>> FC means that no RFE/Features can be pushed without approval from the JDK 9 >>> Release Team. The updated schedule was published to the OpenJDK community in >>> December last year by Mark Reinhold. >> >> You're not helping very much. Or rather, you're restating what I've >> heard already but I don't know what that means. Is finishing off the >> compact string intrinsics for AArch64 a RFE/Feature or not? I don't >> know. As far as I'm concerned it's a work in progress, which started >> some time ago. > > Do you have a JBS ID for this work? I thought so, but I can't see it. I've been tending to create ad-hoc bugs for each part of the work. But the need for it is implied by JEP 254: Compact Strings. So you're perhaps telling me that if I had known that it was necessary to get this done, I should have created one? Andrew. From joseph.provino at oracle.com Thu May 12 15:10:10 2016 From: joseph.provino at oracle.com (Joseph Provino) Date: Thu, 12 May 2016 11:10:10 -0400 Subject: RFR (XXS) JDK-8156851 Compilation error compiling XpatchDupModule.java and XpatchDupJavaBase.java Message-ID: <57349CD2.3010207@oracle.com> Please review this tiny change. Webrev: http://cr.openjdk.java.net/~jprovino/8156851/webrev.00/ CR: JDK-8156851 Compilation error compiling XpatchDupModule.java and XpatchDupJavaBase.java Thanks. joe From derek.white at oracle.com Thu May 12 15:17:17 2016 From: derek.white at oracle.com (Derek White) Date: Thu, 12 May 2016 11:17:17 -0400 Subject: RFR (XXS) JDK-8156851 Compilation error compiling XpatchDupModule.java and XpatchDupJavaBase.java In-Reply-To: <57349CD2.3010207@oracle.com> References: <57349CD2.3010207@oracle.com> Message-ID: On 5/12/16 11:10 AM, Joseph Provino wrote: > Please review this tiny change. > > Webrev: http://cr.openjdk.java.net/~jprovino/8156851/webrev.00/ > > CR: JDK-8156851 Compilation error compiling XpatchDupModule.java and > XpatchDupJavaBase.java > > Thanks. > > joe Looks good! - Derek From jesper.wilhelmsson at oracle.com Thu May 12 15:17:59 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 12 May 2016 17:17:59 +0200 Subject: jdk9/hs is CLOSED In-Reply-To: <573498B0.5080304@redhat.com> References: <5734462B.7030108@redhat.com> <57345D25.6020306@redhat.com> <0c8501d1ac57$7e9d3820$7bd7a860$@oracle.com> <57348EE7.4030608@redhat.com> <93697210-ae23-dd59-6efd-29549e7ab676@oracle.com> <573498B0.5080304@redhat.com> Message-ID: Den 12/5/16 kl. 16:52, skrev Andrew Haley: > On 05/12/2016 03:12 PM, Jesper Wilhelmsson wrote: >> Den 12/5/16 kl. 16:10, skrev Andrew Haley: >>> On 05/12/2016 03:06 PM, Christian Tornqvist wrote: >>>> FC means that no RFE/Features can be pushed without approval from the JDK 9 >>>> Release Team. The updated schedule was published to the OpenJDK community in >>>> December last year by Mark Reinhold. >>> >>> You're not helping very much. Or rather, you're restating what I've >>> heard already but I don't know what that means. Is finishing off the >>> compact string intrinsics for AArch64 a RFE/Feature or not? I don't >>> know. As far as I'm concerned it's a work in progress, which started >>> some time ago. >> >> Do you have a JBS ID for this work? > > I thought so, but I can't see it. I've been tending to create ad-hoc > bugs for each part of the work. But the need for it is implied by JEP > 254: Compact Strings. So you're perhaps telling me that if I had > known that it was necessary to get this done, I should have created > one? I was mainly looking for something to read to try to figure out if this is an enhancement or a bug. From your description it could be either. JEP 254 is clearly a new feature and as such should be integrated before FC. It was integrated in November 2015. Is it a bug that the parts you are fixing now doesn't work..? I don't know. You will need a JBS ID to push your changes anyway so I suggest you create a bug for this (and make it a "Bug"). If no-one complains and it passes triage as a bug I guess it is a bug and then you can push it when the repo opens again. /Jesper From jesper.wilhelmsson at oracle.com Thu May 12 15:20:14 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 12 May 2016 17:20:14 +0200 Subject: RFR (XXS) JDK-8156851 Compilation error compiling XpatchDupModule.java and XpatchDupJavaBase.java In-Reply-To: <57349CD2.3010207@oracle.com> References: <57349CD2.3010207@oracle.com> Message-ID: Looks good! /Jesper Den 12/5/16 kl. 17:10, skrev Joseph Provino: > Please review this tiny change. > > Webrev: http://cr.openjdk.java.net/~jprovino/8156851/webrev.00/ > > CR: JDK-8156851 Compilation error compiling XpatchDupModule.java and > XpatchDupJavaBase.java > > Thanks. > > joe From igor.ignatyev at oracle.com Thu May 12 15:30:38 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 12 May 2016 18:30:38 +0300 Subject: RFR(S) : 8156681 : Add jtreg wrapper for hotspot gtest tests In-Reply-To: <43534a4a-a132-292c-8333-64d45074ad62@oracle.com> References: <43534a4a-a132-292c-8333-64d45074ad62@oracle.com> Message-ID: <4E7A2108-8DF2-418F-A3D4-708FCD1FCC9F@oracle.com> Jesper, 1st of all, thank you for review. unfortunately, testing in our infra reveled some problems w/ the wrapper: - gtest test library can be located right in ?test.nativepath? or in ?test.nativepath?/../../gtest - the wrapper pass all flags to gtestLauncher including flags which are not JVM flags, gtestLauncher pass all these args to JNI_CreateJavaVM, so we fail w/ 'Unrecognized option' I have updated the webrev : http://cr.openjdk.java.net/~iignatyev/8156681/webrev.01/ could you please review the updated version? Thanks, ? Igor > On May 10, 2016, at 8:32 PM, Jesper Wilhelmsson wrote: > > Looks good! > /Jesper > > Den 10/5/16 kl. 18:31, skrev Igor Ignatyev: >> http://cr.openjdk.java.net/~iignatyev/8156681/webrev.00/ >>> 71 lines changed: 71 ins; 0 del; 0 mod; >> >> Hi all, >> >> could you please integrate this small fix which adds a jtreg wrapper to run gtest tests? >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8156681 >> webrev: http://cr.openjdk.java.net/~iignatyev/8156681/webrev.00/ >> >> Thanks, >> ? Igor >> From jesper.wilhelmsson at oracle.com Thu May 12 15:35:51 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 12 May 2016 17:35:51 +0200 Subject: RFR(S) : 8156681 : Add jtreg wrapper for hotspot gtest tests In-Reply-To: <4E7A2108-8DF2-418F-A3D4-708FCD1FCC9F@oracle.com> References: <43534a4a-a132-292c-8333-64d45074ad62@oracle.com> <4E7A2108-8DF2-418F-A3D4-708FCD1FCC9F@oracle.com> Message-ID: <1ec58b19-6f3e-b2e1-b249-bf15a8599892@oracle.com> Igor, Do you mind creating a diff between the previous version and this new version? Thanks, /Jesper Den 12/5/16 kl. 17:30, skrev Igor Ignatyev: > Jesper, > > 1st of all, thank you for review. > > unfortunately, testing in our infra reveled some problems w/ the wrapper: > - gtest test library can be located right in ?test.nativepath? or in ?test.nativepath?/../../gtest > - the wrapper pass all flags to gtestLauncher including flags which are not JVM flags, gtestLauncher pass all these args to JNI_CreateJavaVM, so we fail w/ 'Unrecognized option' > > I have updated the webrev : http://cr.openjdk.java.net/~iignatyev/8156681/webrev.01/ > > could you please review the updated version? > > Thanks, > ? Igor > >> On May 10, 2016, at 8:32 PM, Jesper Wilhelmsson wrote: >> >> Looks good! >> /Jesper >> >> Den 10/5/16 kl. 18:31, skrev Igor Ignatyev: >>> http://cr.openjdk.java.net/~iignatyev/8156681/webrev.00/ >>>> 71 lines changed: 71 ins; 0 del; 0 mod; >>> >>> Hi all, >>> >>> could you please integrate this small fix which adds a jtreg wrapper to run gtest tests? >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8156681 >>> webrev: http://cr.openjdk.java.net/~iignatyev/8156681/webrev.00/ >>> >>> Thanks, >>> ? Igor >>> > From igor.ignatyev at oracle.com Thu May 12 15:41:49 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 12 May 2016 18:41:49 +0300 Subject: RFR(S) : 8156681 : Add jtreg wrapper for hotspot gtest tests In-Reply-To: <1ec58b19-6f3e-b2e1-b249-bf15a8599892@oracle.com> References: <43534a4a-a132-292c-8333-64d45074ad62@oracle.com> <4E7A2108-8DF2-418F-A3D4-708FCD1FCC9F@oracle.com> <1ec58b19-6f3e-b2e1-b249-bf15a8599892@oracle.com> Message-ID: here it is http://cr.openjdk.java.net/~iignatyev/8156681-diif/webrev.00/ ? Igor > On May 12, 2016, at 6:35 PM, Jesper Wilhelmsson wrote: > > Igor, > > Do you mind creating a diff between the previous version and this new version? > > Thanks, > /Jesper > > Den 12/5/16 kl. 17:30, skrev Igor Ignatyev: >> Jesper, >> >> 1st of all, thank you for review. >> >> unfortunately, testing in our infra reveled some problems w/ the wrapper: >> - gtest test library can be located right in ?test.nativepath? or in ?test.nativepath?/../../gtest >> - the wrapper pass all flags to gtestLauncher including flags which are not JVM flags, gtestLauncher pass all these args to JNI_CreateJavaVM, so we fail w/ 'Unrecognized option' >> >> I have updated the webrev : http://cr.openjdk.java.net/~iignatyev/8156681/webrev.01/ >> >> could you please review the updated version? >> >> Thanks, >> ? Igor >> >>> On May 10, 2016, at 8:32 PM, Jesper Wilhelmsson wrote: >>> >>> Looks good! >>> /Jesper >>> >>> Den 10/5/16 kl. 18:31, skrev Igor Ignatyev: >>>> http://cr.openjdk.java.net/~iignatyev/8156681/webrev.00/ >>>>> 71 lines changed: 71 ins; 0 del; 0 mod; >>>> >>>> Hi all, >>>> >>>> could you please integrate this small fix which adds a jtreg wrapper to run gtest tests? >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8156681 >>>> webrev: http://cr.openjdk.java.net/~iignatyev/8156681/webrev.00/ >>>> >>>> Thanks, >>>> ? Igor >>>> >> From lois.foltan at oracle.com Thu May 12 16:17:43 2016 From: lois.foltan at oracle.com (Lois Foltan) Date: Thu, 12 May 2016 12:17:43 -0400 Subject: RFR (XXS) JDK-8156851 Compilation error compiling XpatchDupModule.java and XpatchDupJavaBase.java In-Reply-To: <57349CD2.3010207@oracle.com> References: <57349CD2.3010207@oracle.com> Message-ID: <5734ACA7.105@oracle.com> Looks good. Lois On 5/12/2016 11:10 AM, Joseph Provino wrote: > Please review this tiny change. > > Webrev: http://cr.openjdk.java.net/~jprovino/8156851/webrev.00/ > > CR: JDK-8156851 Compilation error compiling XpatchDupModule.java and > XpatchDupJavaBase.java > > Thanks. > > joe From jesper.wilhelmsson at oracle.com Thu May 12 17:22:01 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 12 May 2016 19:22:01 +0200 Subject: RFR(S) : 8156681 : Add jtreg wrapper for hotspot gtest tests In-Reply-To: References: <43534a4a-a132-292c-8333-64d45074ad62@oracle.com> <4E7A2108-8DF2-418F-A3D4-708FCD1FCC9F@oracle.com> <1ec58b19-6f3e-b2e1-b249-bf15a8599892@oracle.com> Message-ID: Thanks! Looks good! /Jesper Den 12/5/16 kl. 17:41, skrev Igor Ignatyev: > here it is http://cr.openjdk.java.net/~iignatyev/8156681-diif/webrev.00/ > > ? Igor > >> On May 12, 2016, at 6:35 PM, Jesper Wilhelmsson wrote: >> >> Igor, >> >> Do you mind creating a diff between the previous version and this new version? >> >> Thanks, >> /Jesper >> >> Den 12/5/16 kl. 17:30, skrev Igor Ignatyev: >>> Jesper, >>> >>> 1st of all, thank you for review. >>> >>> unfortunately, testing in our infra reveled some problems w/ the wrapper: >>> - gtest test library can be located right in ?test.nativepath? or in ?test.nativepath?/../../gtest >>> - the wrapper pass all flags to gtestLauncher including flags which are not JVM flags, gtestLauncher pass all these args to JNI_CreateJavaVM, so we fail w/ 'Unrecognized option' >>> >>> I have updated the webrev : http://cr.openjdk.java.net/~iignatyev/8156681/webrev.01/ >>> >>> could you please review the updated version? >>> >>> Thanks, >>> ? Igor >>> >>>> On May 10, 2016, at 8:32 PM, Jesper Wilhelmsson wrote: >>>> >>>> Looks good! >>>> /Jesper >>>> >>>> Den 10/5/16 kl. 18:31, skrev Igor Ignatyev: >>>>> http://cr.openjdk.java.net/~iignatyev/8156681/webrev.00/ >>>>>> 71 lines changed: 71 ins; 0 del; 0 mod; >>>>> >>>>> Hi all, >>>>> >>>>> could you please integrate this small fix which adds a jtreg wrapper to run gtest tests? >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8156681 >>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8156681/webrev.00/ >>>>> >>>>> Thanks, >>>>> ? Igor >>>>> >>> > From joseph.provino at oracle.com Thu May 12 17:47:07 2016 From: joseph.provino at oracle.com (Joseph Provino) Date: Thu, 12 May 2016 13:47:07 -0400 Subject: RFR (XS) JDK-8153582 Logging of ConcGCThreads is done too early Message-ID: <5734C19B.5030303@oracle.com> Please review this very small change to log ConcGCThreads and ParallelGCThreads correctly. Webrev: http://cr.openjdk.java.net/~jprovino/8153582/webrev.00 CR: JDK-8153582Logging of ConcGCThreads is done too early Messages look like below. java -Xlog:gc=trace -XX:+PrintFlagsFinal -version [0.002s][trace][gc] MarkStackSize: 4096k MarkStackSizeMax: 16384k [0.038s][trace][gc] ConcGCThreads: 5 [0.039s][trace][gc] ParallelGCThreads: 18 [0.056s][info ][gc] Using G1 java -Xlog:gc=trace -XX:+PrintFlagsFinal -XX:+UseConcMarkSweepGC -version [0.002s][trace][gc] MarkStackSize: 4096k MarkStackSizeMax: 524288k [1.001s][trace][gc] ConcGCThreads: 5 [1.001s][trace][gc] ParallelGCThreads: 18 [1.015s][info ][gc] Using Concurrent Mark Sweep From derek.white at oracle.com Thu May 12 19:06:22 2016 From: derek.white at oracle.com (Derek White) Date: Thu, 12 May 2016 15:06:22 -0400 Subject: RFR (XS) JDK-8153582 Logging of ConcGCThreads is done too early In-Reply-To: <5734C19B.5030303@oracle.com> References: <5734C19B.5030303@oracle.com> Message-ID: Hi Joe, Looks good! - Derek On 5/12/16 1:47 PM, Joseph Provino wrote: > Please review this very small change to log ConcGCThreads > and ParallelGCThreads correctly. > > Webrev: http://cr.openjdk.java.net/~jprovino/8153582/webrev.00 > > CR: JDK-8153582Logging of ConcGCThreads is done too early > > > Messages look like below. > > java -Xlog:gc=trace -XX:+PrintFlagsFinal -version > > [0.002s][trace][gc] MarkStackSize: 4096k MarkStackSizeMax: 16384k > [0.038s][trace][gc] ConcGCThreads: 5 > [0.039s][trace][gc] ParallelGCThreads: 18 > [0.056s][info ][gc] Using G1 > > java -Xlog:gc=trace -XX:+PrintFlagsFinal -XX:+UseConcMarkSweepGC > -version > > [0.002s][trace][gc] MarkStackSize: 4096k MarkStackSizeMax: 524288k > [1.001s][trace][gc] ConcGCThreads: 5 > [1.001s][trace][gc] ParallelGCThreads: 18 > [1.015s][info ][gc] Using Concurrent Mark Sweep > > > From christian.thalinger at oracle.com Thu May 12 19:39:13 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 12 May 2016 09:39:13 -1000 Subject: jdk9/hs is CLOSED In-Reply-To: References: <5734462B.7030108@redhat.com> <57345D25.6020306@redhat.com> <0c8501d1ac57$7e9d3820$7bd7a860$@oracle.com> <57348EE7.4030608@redhat.com> <93697210-ae23-dd59-6efd-29549e7ab676@oracle.com> <573498B0.5080304@redhat.com> Message-ID: > On May 12, 2016, at 5:17 AM, Jesper Wilhelmsson wrote: > > Den 12/5/16 kl. 16:52, skrev Andrew Haley: >> On 05/12/2016 03:12 PM, Jesper Wilhelmsson wrote: >>> Den 12/5/16 kl. 16:10, skrev Andrew Haley: >>>> On 05/12/2016 03:06 PM, Christian Tornqvist wrote: >>>>> FC means that no RFE/Features can be pushed without approval from the JDK 9 >>>>> Release Team. The updated schedule was published to the OpenJDK community in >>>>> December last year by Mark Reinhold. >>>> >>>> You're not helping very much. Or rather, you're restating what I've >>>> heard already but I don't know what that means. Is finishing off the >>>> compact string intrinsics for AArch64 a RFE/Feature or not? I don't >>>> know. As far as I'm concerned it's a work in progress, which started >>>> some time ago. >>> >>> Do you have a JBS ID for this work? >> >> I thought so, but I can't see it. I've been tending to create ad-hoc >> bugs for each part of the work. But the need for it is implied by JEP >> 254: Compact Strings. So you're perhaps telling me that if I had >> known that it was necessary to get this done, I should have created >> one? > > I was mainly looking for something to read to try to figure out if this is an enhancement or a bug. From your description it could be either. It?s an enhancement. As far as I know Compact Strings works fine without compiler intrinsics; it?s just slow. The more interesting question is if Oracle?s rules should also apply to non-shared code changes to ports that Oracle does not maintain. > > JEP 254 is clearly a new feature and as such should be integrated before FC. It was integrated in November 2015. Is it a bug that the parts you are fixing now doesn't work..? I don't know. > > You will need a JBS ID to push your changes anyway so I suggest you create a bug for this (and make it a "Bug"). If no-one complains and it passes triage as a bug I guess it is a bug and then you can push it when the repo opens again. > > /Jesper From jesper.wilhelmsson at oracle.com Thu May 12 21:08:56 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 12 May 2016 23:08:56 +0200 Subject: jdk9/hs is CLOSED In-Reply-To: References: <5734462B.7030108@redhat.com> <57345D25.6020306@redhat.com> <0c8501d1ac57$7e9d3820$7bd7a860$@oracle.com> <57348EE7.4030608@redhat.com> <93697210-ae23-dd59-6efd-29549e7ab676@oracle.com> <573498B0.5080304@redhat.com> Message-ID: <406537a4-64d7-9fc2-720f-237c5ca0892e@oracle.com> Den 12/5/16 kl. 21:39, skrev Christian Thalinger: > >> On May 12, 2016, at 5:17 AM, Jesper Wilhelmsson > > wrote: >> >> Den 12/5/16 kl. 16:52, skrev Andrew Haley: >>> On 05/12/2016 03:12 PM, Jesper Wilhelmsson wrote: >>>> Den 12/5/16 kl. 16:10, skrev Andrew Haley: >>>>> On 05/12/2016 03:06 PM, Christian Tornqvist wrote: >>>>>> FC means that no RFE/Features can be pushed without approval from the JDK 9 >>>>>> Release Team. The updated schedule was published to the OpenJDK community in >>>>>> December last year by Mark Reinhold. >>>>> >>>>> You're not helping very much. Or rather, you're restating what I've >>>>> heard already but I don't know what that means. Is finishing off the >>>>> compact string intrinsics for AArch64 a RFE/Feature or not? I don't >>>>> know. As far as I'm concerned it's a work in progress, which started >>>>> some time ago. >>>> >>>> Do you have a JBS ID for this work? >>> >>> I thought so, but I can't see it. I've been tending to create ad-hoc >>> bugs for each part of the work. But the need for it is implied by JEP >>> 254: Compact Strings. So you're perhaps telling me that if I had >>> known that it was necessary to get this done, I should have created >>> one? >> >> I was mainly looking for something to read to try to figure out if this is an >> enhancement or a bug. From your description it could be either. > > It?s an enhancement. As far as I know Compact Strings works fine without > compiler intrinsics; it?s just slow. Thanks for clarifying that! > The more interesting question is if Oracle?s rules should also apply to > non-shared code changes to ports that Oracle does not maintain. That's a very interesting question indeed! Part of the answer needs to be a definition of what is Oracle's rules and what is OpenJDK rules. As far as I know there are very little (if anything) defined on the OpenJDK web regarding rules around pushes and how to work with bugs in JBS. I don't think the fact that we have a triage process is even mentioned anywhere. Is the lack of documentation the same as no rules? FC, RDP, ZBB etc? Are these defined outside Oracle? Do we expect OpenJDK contributors to respect these? Anyhow, the fact remains that changes pushed to jdk9/hs after we have taken the snapshot will not get into jdk9/jdk9 before FC simply because we will not be able to integrate them in time. If this matters or not, I don't know. As I wrote in my first response: "If you are changing code that is not supported by Oracle - i.e. code that we don't test in our internal testing, there should be no issues getting this code into jdk9/hs. However, if you want the code to get into jdk9/jdk9 before FC you'd have to push asap. Once we take the snapshot to start PIT no more changes from jdk9/hs will make it to jdk9/jdk9 before FC." /Jesper > >> >> JEP 254 is clearly a new feature and as such should be integrated before FC. >> It was integrated in November 2015. Is it a bug that the parts you are fixing >> now doesn't work..? I don't know. >> >> You will need a JBS ID to push your changes anyway so I suggest you create a >> bug for this (and make it a "Bug"). If no-one complains and it passes triage >> as a bug I guess it is a bug and then you can push it when the repo opens again. >> >> /Jesper > From vladimir.kozlov at oracle.com Thu May 12 21:34:17 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 12 May 2016 14:34:17 -0700 Subject: jdk9/hs is CLOSED In-Reply-To: <406537a4-64d7-9fc2-720f-237c5ca0892e@oracle.com> References: <5734462B.7030108@redhat.com> <57345D25.6020306@redhat.com> <0c8501d1ac57$7e9d3820$7bd7a860$@oracle.com> <57348EE7.4030608@redhat.com> <93697210-ae23-dd59-6efd-29549e7ab676@oracle.com> <573498B0.5080304@redhat.com> <406537a4-64d7-9fc2-720f-237c5ca0892e@oracle.com> Message-ID: <5734F6D9.1020405@oracle.com> >> The more interesting question is if Oracle?s rules should also apply to >> non-shared code changes to ports that Oracle does not maintain. No, it does not apply to not-shared code. Jesper's statement is correct. It is internal Oracle's process related only to produces we support. We discussed this issue at the end of last year (for original FC date): "One question is whether changes to platforms we do not build and test (specifically, aix/ppc and the open aarch64 port) must abide strictly by the FC rules, or if we can be more lenient in accepting and integrating such changes. General consensus is that given that we're not building/testing them, clean changes which do not impact us can be integrated." Regards, Vladimir On 5/12/16 2:08 PM, Jesper Wilhelmsson wrote: > Den 12/5/16 kl. 21:39, skrev Christian Thalinger: >> >>> On May 12, 2016, at 5:17 AM, Jesper Wilhelmsson >> > wrote: >>> >>> Den 12/5/16 kl. 16:52, skrev Andrew Haley: >>>> On 05/12/2016 03:12 PM, Jesper Wilhelmsson wrote: >>>>> Den 12/5/16 kl. 16:10, skrev Andrew Haley: >>>>>> On 05/12/2016 03:06 PM, Christian Tornqvist wrote: >>>>>>> FC means that no RFE/Features can be pushed without approval from the JDK 9 >>>>>>> Release Team. The updated schedule was published to the OpenJDK community in >>>>>>> December last year by Mark Reinhold. >>>>>> >>>>>> You're not helping very much. Or rather, you're restating what I've >>>>>> heard already but I don't know what that means. Is finishing off the >>>>>> compact string intrinsics for AArch64 a RFE/Feature or not? I don't >>>>>> know. As far as I'm concerned it's a work in progress, which started >>>>>> some time ago. >>>>> >>>>> Do you have a JBS ID for this work? >>>> >>>> I thought so, but I can't see it. I've been tending to create ad-hoc >>>> bugs for each part of the work. But the need for it is implied by JEP >>>> 254: Compact Strings. So you're perhaps telling me that if I had >>>> known that it was necessary to get this done, I should have created >>>> one? >>> >>> I was mainly looking for something to read to try to figure out if this is an >>> enhancement or a bug. From your description it could be either. >> >> It?s an enhancement. As far as I know Compact Strings works fine without >> compiler intrinsics; it?s just slow. > > Thanks for clarifying that! > >> The more interesting question is if Oracle?s rules should also apply to >> non-shared code changes to ports that Oracle does not maintain. > > That's a very interesting question indeed! Part of the answer needs to be a definition of what is Oracle's rules and what is OpenJDK rules. As far as I know there are very little (if anything) defined > on the OpenJDK web regarding rules around pushes and how to work with bugs in JBS. I don't think the fact that we have a triage process is even mentioned anywhere. > > Is the lack of documentation the same as no rules? > > FC, RDP, ZBB etc? Are these defined outside Oracle? Do we expect OpenJDK contributors to respect these? > > Anyhow, the fact remains that changes pushed to jdk9/hs after we have taken the snapshot will not get into jdk9/jdk9 before FC simply because we will not be able to integrate them in time. If this > matters or not, I don't know. > > As I wrote in my first response: > > "If you are changing code that is not supported by Oracle - i.e. code that we don't test in our internal testing, there should be no issues getting this code into jdk9/hs. However, if you want the > code to get into jdk9/jdk9 before FC you'd have to push asap. Once we take the snapshot to start PIT no more changes from jdk9/hs will make it to jdk9/jdk9 before FC." > > /Jesper > >> >>> >>> JEP 254 is clearly a new feature and as such should be integrated before FC. >>> It was integrated in November 2015. Is it a bug that the parts you are fixing >>> now doesn't work..? I don't know. >>> >>> You will need a JBS ID to push your changes anyway so I suggest you create a >>> bug for this (and make it a "Bug"). If no-one complains and it passes triage >>> as a bug I guess it is a bug and then you can push it when the repo opens again. >>> >>> /Jesper >> From christian.thalinger at oracle.com Thu May 12 22:32:43 2016 From: christian.thalinger at oracle.com (Christian Thalinger) Date: Thu, 12 May 2016 12:32:43 -1000 Subject: jdk9/hs is CLOSED In-Reply-To: <5734F6D9.1020405@oracle.com> References: <5734462B.7030108@redhat.com> <57345D25.6020306@redhat.com> <0c8501d1ac57$7e9d3820$7bd7a860$@oracle.com> <57348EE7.4030608@redhat.com> <93697210-ae23-dd59-6efd-29549e7ab676@oracle.com> <573498B0.5080304@redhat.com> <406537a4-64d7-9fc2-720f-237c5ca0892e@oracle.com> <5734F6D9.1020405@oracle.com> Message-ID: <6A1C62B3-74B8-4F32-83FA-90361ED386A0@oracle.com> > On May 12, 2016, at 11:34 AM, Vladimir Kozlov wrote: > >>> The more interesting question is if Oracle?s rules should also apply to >>> non-shared code changes to ports that Oracle does not maintain. > > No, it does not apply to not-shared code. Jesper's statement is correct. > It is internal Oracle's process related only to produces we support. > We discussed this issue at the end of last year (for original FC date): > > "One question is whether changes to platforms we do not build and test (specifically, aix/ppc and the open aarch64 port) must abide strictly by the FC rules, or if we can be more lenient in accepting and integrating such changes. General consensus is that given that we're not building/testing them, clean changes which do not impact us can be integrated.? I vaguely remembered that. Thanks for digging it up. > > Regards, > Vladimir > > On 5/12/16 2:08 PM, Jesper Wilhelmsson wrote: >> Den 12/5/16 kl. 21:39, skrev Christian Thalinger: >>> >>>> On May 12, 2016, at 5:17 AM, Jesper Wilhelmsson >>> > wrote: >>>> >>>> Den 12/5/16 kl. 16:52, skrev Andrew Haley: >>>>> On 05/12/2016 03:12 PM, Jesper Wilhelmsson wrote: >>>>>> Den 12/5/16 kl. 16:10, skrev Andrew Haley: >>>>>>> On 05/12/2016 03:06 PM, Christian Tornqvist wrote: >>>>>>>> FC means that no RFE/Features can be pushed without approval from the JDK 9 >>>>>>>> Release Team. The updated schedule was published to the OpenJDK community in >>>>>>>> December last year by Mark Reinhold. >>>>>>> >>>>>>> You're not helping very much. Or rather, you're restating what I've >>>>>>> heard already but I don't know what that means. Is finishing off the >>>>>>> compact string intrinsics for AArch64 a RFE/Feature or not? I don't >>>>>>> know. As far as I'm concerned it's a work in progress, which started >>>>>>> some time ago. >>>>>> >>>>>> Do you have a JBS ID for this work? >>>>> >>>>> I thought so, but I can't see it. I've been tending to create ad-hoc >>>>> bugs for each part of the work. But the need for it is implied by JEP >>>>> 254: Compact Strings. So you're perhaps telling me that if I had >>>>> known that it was necessary to get this done, I should have created >>>>> one? >>>> >>>> I was mainly looking for something to read to try to figure out if this is an >>>> enhancement or a bug. From your description it could be either. >>> >>> It?s an enhancement. As far as I know Compact Strings works fine without >>> compiler intrinsics; it?s just slow. >> >> Thanks for clarifying that! >> >>> The more interesting question is if Oracle?s rules should also apply to >>> non-shared code changes to ports that Oracle does not maintain. >> >> That's a very interesting question indeed! Part of the answer needs to be a definition of what is Oracle's rules and what is OpenJDK rules. As far as I know there are very little (if anything) defined >> on the OpenJDK web regarding rules around pushes and how to work with bugs in JBS. I don't think the fact that we have a triage process is even mentioned anywhere. >> >> Is the lack of documentation the same as no rules? >> >> FC, RDP, ZBB etc? Are these defined outside Oracle? Do we expect OpenJDK contributors to respect these? >> >> Anyhow, the fact remains that changes pushed to jdk9/hs after we have taken the snapshot will not get into jdk9/jdk9 before FC simply because we will not be able to integrate them in time. If this >> matters or not, I don't know. >> >> As I wrote in my first response: >> >> "If you are changing code that is not supported by Oracle - i.e. code that we don't test in our internal testing, there should be no issues getting this code into jdk9/hs. However, if you want the >> code to get into jdk9/jdk9 before FC you'd have to push asap. Once we take the snapshot to start PIT no more changes from jdk9/hs will make it to jdk9/jdk9 before FC." >> >> /Jesper >> >>> >>>> >>>> JEP 254 is clearly a new feature and as such should be integrated before FC. >>>> It was integrated in November 2015. Is it a bug that the parts you are fixing >>>> now doesn't work..? I don't know. >>>> >>>> You will need a JBS ID to push your changes anyway so I suggest you create a >>>> bug for this (and make it a "Bug"). If no-one complains and it passes triage >>>> as a bug I guess it is a bug and then you can push it when the repo opens again. >>>> >>>> /Jesper >>> From david.holmes at oracle.com Fri May 13 00:44:21 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 13 May 2016 10:44:21 +1000 Subject: jdk9/hs is CLOSED In-Reply-To: <5734F6D9.1020405@oracle.com> References: <5734462B.7030108@redhat.com> <57345D25.6020306@redhat.com> <0c8501d1ac57$7e9d3820$7bd7a860$@oracle.com> <57348EE7.4030608@redhat.com> <93697210-ae23-dd59-6efd-29549e7ab676@oracle.com> <573498B0.5080304@redhat.com> <406537a4-64d7-9fc2-720f-237c5ca0892e@oracle.com> <5734F6D9.1020405@oracle.com> Message-ID: I think a few things need clarifying here! On 13/05/2016 7:34 AM, Vladimir Kozlov wrote: >>> The more interesting question is if Oracle?s rules should also apply to >>> non-shared code changes to ports that Oracle does not maintain. > > No, it does not apply to not-shared code. Jesper's statement is correct. > It is internal Oracle's process related only to produces we support. The OpenJDK JDK 9 project defines its schedule and milestones: http://openjdk.java.net/projects/jdk9/ Schedule 2016/05/26 Feature Complete 2016/08/11 All Tests Run 2016/09/01 Rampdown Start 2016/10/20 Zero Bug Bounce 2016/12/01 Rampdown Phase 2 2017/01/26 Final Release Candidate 2017/03/23 General Availability and the definition of FC is: Feature Complete ? All features have been implemented and integrated into the master forest, together with unit tests. So these are OpenJDK rules _not_ Oracle internal rules. However, it is unclear what set of platforms/ports the "Java SE 9 Platform" consists of. The JEP process, as far as I can see, makes no mention of whether completion/integration of a JEP requires it to be done for all platforms: http://cr.openjdk.java.net/~mr/jep/jep-2.0-02.html If it is not a requirement (which to me it seems not to be) then it is very unclear where the "porting" of a JEP to other platforms fits in the overall scheme of things. Even less clear if considering only a performance related aspect of the JEP, such as support for intrinsic operations. Where things are also less well-defined is how the schedule is managed in relation to the non-master forests. The fact that jdk9/hs exists and pushes up to jdk9/dev, which in turn pushes up to jd9/jdk9 Master is not visible in the schedule (nor anywhere on the OpenJDK site AFAICS) - so the forest "operators" have to work backwards to determine how the ad-hoc rules of each forest have to be adjusted to meet the overall project deadlines. On that front I was sure I had seen some earlier announcement about the need for all FC changes to be into jdk9/hs by May 10 (which actually became May 11). The closure of jdk9/hs temporarily is not directly related to FC or the FC processes other than we have a deadline we need to meet. AFAICS this is the third time, in recent history, we have closed the hotspot forests (was hs-rt previously) while we stabilize things ready for pushing up. > We discussed this issue at the end of last year (for original FC date): > > "One question is whether changes to platforms we do not build and test > (specifically, aix/ppc and the open aarch64 port) must abide strictly by > the FC rules, or if we can be more lenient in accepting and integrating > such changes. General consensus is that given that we're not > building/testing them, clean changes which do not impact us can be > integrated." To me that's more of a "we can rubber stamp post FC integration requests for that kind of work", not a "the rules don't apply to that kind of work". But that said, the post FC approval process, as with all the milestone related approval processes, does seem to be an Oracle internal process, as it is not mentioned anywhere in relation to the OpenJDK JDK 9 project that I can see. So some clear information on that process and its scope/applicability would be beneficial for everyone. Thanks, David ----- > Regards, > Vladimir > > On 5/12/16 2:08 PM, Jesper Wilhelmsson wrote: >> Den 12/5/16 kl. 21:39, skrev Christian Thalinger: >>> >>>> On May 12, 2016, at 5:17 AM, Jesper Wilhelmsson >>>> >>> > wrote: >>>> >>>> Den 12/5/16 kl. 16:52, skrev Andrew Haley: >>>>> On 05/12/2016 03:12 PM, Jesper Wilhelmsson wrote: >>>>>> Den 12/5/16 kl. 16:10, skrev Andrew Haley: >>>>>>> On 05/12/2016 03:06 PM, Christian Tornqvist wrote: >>>>>>>> FC means that no RFE/Features can be pushed without approval >>>>>>>> from the JDK 9 >>>>>>>> Release Team. The updated schedule was published to the OpenJDK >>>>>>>> community in >>>>>>>> December last year by Mark Reinhold. >>>>>>> >>>>>>> You're not helping very much. Or rather, you're restating what I've >>>>>>> heard already but I don't know what that means. Is finishing off >>>>>>> the >>>>>>> compact string intrinsics for AArch64 a RFE/Feature or not? I don't >>>>>>> know. As far as I'm concerned it's a work in progress, which >>>>>>> started >>>>>>> some time ago. >>>>>> >>>>>> Do you have a JBS ID for this work? >>>>> >>>>> I thought so, but I can't see it. I've been tending to create ad-hoc >>>>> bugs for each part of the work. But the need for it is implied by JEP >>>>> 254: Compact Strings. So you're perhaps telling me that if I had >>>>> known that it was necessary to get this done, I should have created >>>>> one? >>>> >>>> I was mainly looking for something to read to try to figure out if >>>> this is an >>>> enhancement or a bug. From your description it could be either. >>> >>> It?s an enhancement. As far as I know Compact Strings works fine >>> without >>> compiler intrinsics; it?s just slow. >> >> Thanks for clarifying that! >> >>> The more interesting question is if Oracle?s rules should also apply to >>> non-shared code changes to ports that Oracle does not maintain. >> >> That's a very interesting question indeed! Part of the answer needs to >> be a definition of what is Oracle's rules and what is OpenJDK rules. >> As far as I know there are very little (if anything) defined >> on the OpenJDK web regarding rules around pushes and how to work with >> bugs in JBS. I don't think the fact that we have a triage process is >> even mentioned anywhere. >> >> Is the lack of documentation the same as no rules? >> >> FC, RDP, ZBB etc? Are these defined outside Oracle? Do we expect >> OpenJDK contributors to respect these? >> >> Anyhow, the fact remains that changes pushed to jdk9/hs after we have >> taken the snapshot will not get into jdk9/jdk9 before FC simply >> because we will not be able to integrate them in time. If this >> matters or not, I don't know. >> >> As I wrote in my first response: >> >> "If you are changing code that is not supported by Oracle - i.e. code >> that we don't test in our internal testing, there should be no issues >> getting this code into jdk9/hs. However, if you want the >> code to get into jdk9/jdk9 before FC you'd have to push asap. Once we >> take the snapshot to start PIT no more changes from jdk9/hs will make >> it to jdk9/jdk9 before FC." >> >> /Jesper >> >>> >>>> >>>> JEP 254 is clearly a new feature and as such should be integrated >>>> before FC. >>>> It was integrated in November 2015. Is it a bug that the parts you >>>> are fixing >>>> now doesn't work..? I don't know. >>>> >>>> You will need a JBS ID to push your changes anyway so I suggest you >>>> create a >>>> bug for this (and make it a "Bug"). If no-one complains and it >>>> passes triage >>>> as a bug I guess it is a bug and then you can push it when the repo >>>> opens again. >>>> >>>> /Jesper >>> From erik.helin at oracle.com Fri May 13 07:36:07 2016 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 13 May 2016 09:36:07 +0200 Subject: RFR(S) : 8156681 : Add jtreg wrapper for hotspot gtest tests In-Reply-To: <4E7A2108-8DF2-418F-A3D4-708FCD1FCC9F@oracle.com> References: <43534a4a-a132-292c-8333-64d45074ad62@oracle.com> <4E7A2108-8DF2-418F-A3D4-708FCD1FCC9F@oracle.com> Message-ID: <20160513073607.GA25871@ehelin.jrpg.bea.com> On 2016-05-12, Igor Ignatyev wrote: > Jesper, > > 1st of all, thank you for review. > > unfortunately, testing in our infra reveled some problems w/ the wrapper: > - gtest test library can be located right in ?test.nativepath? or in ?test.nativepath?/../../gtest > - the wrapper pass all flags to gtestLauncher including flags which are not JVM flags, gtestLauncher pass all these args to JNI_CreateJavaVM, so we fail w/ 'Unrecognized option' > > I have updated the webrev : http://cr.openjdk.java.net/~iignatyev/8156681/webrev.01/ I don't understand the first path. Is System.getProperty("test.nativepath") either "/hotspot/jtreg/native" or "/hotspot/gtest"? Or is it something else? What do you want the final path to be? Is the indentation a bit off here? 62 Stream.of( 63 path.toString(), 64 "-jdk", 65 System.getProperty("test.jdk")), 66 Arrays.stream(Utils.getTestJavaOpts()) 67 .filter(s -> s.startsWith("-X") || s.startsWith("-D"))) since you always want the first three arguments, is the following a bit easier to understand? List options = Arrays.stream(Utils.getTestJavaOpts()) .filter(s -> s.startsWith("-X") || s.startsWith("-D")) .collect(Collectors.toList()); List cmd = Arrays.asList(path.toString(), "-jdk", System.getProperty("test.jdk")); cmd.addAll(options); The following 70 OutputAnalyzer oa = ProcessTools.executeProcess(builder); 71 oa.shouldHaveExitValue(0); could also be shortened to one line if you prefer that: ProcessTools.executeProcess(builder).shouldHaveExitValue(0); Thanks, Erik > > could you please review the updated version? > > Thanks, > ? Igor > > > On May 10, 2016, at 8:32 PM, Jesper Wilhelmsson wrote: > > > > Looks good! > > /Jesper > > > > Den 10/5/16 kl. 18:31, skrev Igor Ignatyev: > >> http://cr.openjdk.java.net/~iignatyev/8156681/webrev.00/ > >>> 71 lines changed: 71 ins; 0 del; 0 mod; > >> > >> Hi all, > >> > >> could you please integrate this small fix which adds a jtreg wrapper to run gtest tests? > >> > >> JBS: https://bugs.openjdk.java.net/browse/JDK-8156681 > >> webrev: http://cr.openjdk.java.net/~iignatyev/8156681/webrev.00/ > >> > >> Thanks, > >> ? Igor > >> > From thomas.schatzl at oracle.com Fri May 13 10:55:01 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 13 May 2016 12:55:01 +0200 Subject: RFR (XS) JDK-8153582 Logging of ConcGCThreads is done too early In-Reply-To: <5734C19B.5030303@oracle.com> References: <5734C19B.5030303@oracle.com> Message-ID: <1463136901.2392.5.camel@oracle.com> Hi, On Thu, 2016-05-12 at 13:47 -0400, Joseph Provino wrote: > Please review this very small change to log ConcGCThreads > and ParallelGCThreads correctly. > > Webrev:??http://cr.openjdk.java.net/~jprovino/8153582/webrev.00 > > CR: JDK-8153582Logging of ConcGCThreads is done too early? > > > Messages look like below. > > java -Xlog:gc=trace -XX:+PrintFlagsFinal -version > > [0.002s][trace][gc] MarkStackSize: 4096k??MarkStackSizeMax: 16384k > [0.038s][trace][gc] ConcGCThreads: 5 > [0.039s][trace][gc] ParallelGCThreads: 18 > [0.056s][info ][gc] Using G1 > > java??-Xlog:gc=trace -XX:+PrintFlagsFinal -XX:+UseConcMarkSweepGC > -version > > [0.002s][trace][gc] MarkStackSize: 4096k??MarkStackSizeMax: 524288k > [1.001s][trace][gc] ConcGCThreads: 5 > [1.001s][trace][gc] ParallelGCThreads: 18 > [1.015s][info ][gc] Using Concurrent Mark Sweep ? - not sure if this is "trace" level worthy, maybe debug level would be more appropriate. Not opposed to using trace level, just questioning the reason for using trace level here. It does not look too detailed yet. ? - could you please use the latest webrev script available on?http://o penjdk.java.net/guide/webrevHelp.html?in the future? The added links to the next/pref changed file are a great addition. ? - please add a small test case that checks the output. Thanks, ? THomas From christian.tornqvist at oracle.com Fri May 13 15:05:22 2016 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Fri, 13 May 2016 11:05:22 -0400 Subject: RFR(XS): 8156882 - Remove hotspot/test/testlibrary/whitebox Message-ID: <0c5001d1ad28$dfcff520$9f6fdf60$@oracle.com> Hi everyone, Please review this small change that removes the unused hotspot/test/testlibrary/whitebox . This should've been removed when WhiteBox.java was moved to /test, it has caused hours of troubleshooting when changes has been made in the wrong file. Note, this is an RFE and will need a RT approval to get into JDK9. Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8156882/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8156882 Thanks, Christian From dmitry.fazunenko at oracle.com Fri May 13 15:17:38 2016 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Fri, 13 May 2016 18:17:38 +0300 Subject: RFR(XS): 8156882 - Remove hotspot/test/testlibrary/whitebox In-Reply-To: <0c5001d1ad28$dfcff520$9f6fdf60$@oracle.com> References: <0c5001d1ad28$dfcff520$9f6fdf60$@oracle.com> Message-ID: Hi Christian, Looks good. Thanks, Dima On 13.05.2016 18:05, Christian Tornqvist wrote: > Hi everyone, > > > > Please review this small change that removes the unused > hotspot/test/testlibrary/whitebox . This should've been removed when > WhiteBox.java was moved to /test, it has caused hours of troubleshooting > when changes has been made in the wrong file. > > > > Note, this is an RFE and will need a RT approval to get into JDK9. > > > > Webrev: > > http://cr.openjdk.java.net/~ctornqvi/webrev/8156882/webrev.00/ > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8156882 > > > > Thanks, > > Christian > > > > > > > From max.ockner at oracle.com Fri May 13 16:03:12 2016 From: max.ockner at oracle.com (Max Ockner) Date: Fri, 13 May 2016 12:03:12 -0400 Subject: RFR(XS): 8156882 - Remove hotspot/test/testlibrary/whitebox In-Reply-To: <0c5001d1ad28$dfcff520$9f6fdf60$@oracle.com> References: <0c5001d1ad28$dfcff520$9f6fdf60$@oracle.com> Message-ID: <5735FAC0.30503@oracle.com> Looks good to me. Thanks for taking care of this. Max On 5/13/2016 11:05 AM, Christian Tornqvist wrote: > Hi everyone, > > > > Please review this small change that removes the unused > hotspot/test/testlibrary/whitebox . This should've been removed when > WhiteBox.java was moved to /test, it has caused hours of troubleshooting > when changes has been made in the wrong file. > > > > Note, this is an RFE and will need a RT approval to get into JDK9. > > > > Webrev: > > http://cr.openjdk.java.net/~ctornqvi/webrev/8156882/webrev.00/ > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8156882 > > > > Thanks, > > Christian > > > > > > > From igor.ignatyev at oracle.com Fri May 13 16:09:02 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 13 May 2016 19:09:02 +0300 Subject: RFR(S) : 8156681 : Add jtreg wrapper for hotspot gtest tests In-Reply-To: <20160513073607.GA25871@ehelin.jrpg.bea.com> References: <43534a4a-a132-292c-8333-64d45074ad62@oracle.com> <4E7A2108-8DF2-418F-A3D4-708FCD1FCC9F@oracle.com> <20160513073607.GA25871@ehelin.jrpg.bea.com> Message-ID: <22445A65-BB80-45F0-B371-C87D585AE2F2@oracle.com> Hey Erik, I've updated the fix to be more readable. webrev: http://cr.openjdk.java.net/~iignatyev/8156681/webrev.02/ diff b/w webrev.02 and webrev.01 : http://cr.openjdk.java.net/~iignatyev/8156681-diif/webrev.01/ ? Igor > On May 13, 2016, at 10:36 AM, Erik Helin wrote: > > On 2016-05-12, Igor Ignatyev wrote: >> Jesper, >> >> 1st of all, thank you for review. >> >> unfortunately, testing in our infra reveled some problems w/ the wrapper: >> - gtest test library can be located right in ?test.nativepath? or in ?test.nativepath?/../../gtest >> - the wrapper pass all flags to gtestLauncher including flags which are not JVM flags, gtestLauncher pass all these args to JNI_CreateJavaVM, so we fail w/ 'Unrecognized option' >> >> I have updated the webrev : http://cr.openjdk.java.net/~iignatyev/8156681/webrev.01/ > > I don't understand the first path. Is System.getProperty("test.nativepath") either > "/hotspot/jtreg/native" or "/hotspot/gtest"? Or > is it something else? What do you want the final path to be? the final path should be /hotspot/gtest/ > > > Is the indentation a bit off here? > 62 Stream.of( > 63 path.toString(), > 64 "-jdk", > 65 System.getProperty("test.jdk")), > 66 Arrays.stream(Utils.getTestJavaOpts()) > 67 .filter(s -> s.startsWith("-X") || s.startsWith("-D"))) > > since you always want the first three arguments, is the following a bit easier to understand? I split that into 3 statements. > > List options = Arrays.stream(Utils.getTestJavaOpts()) > .filter(s -> s.startsWith("-X") || s.startsWith("-D")) > .collect(Collectors.toList()); > List cmd = Arrays.asList(path.toString(), "-jdk", System.getProperty("test.jdk")); > cmd.addAll(options); > > The following > 70 OutputAnalyzer oa = ProcessTools.executeProcess(builder); > 71 oa.shouldHaveExitValue(0); > > could also be shortened to one line if you prefer that: > > ProcessTools.executeProcess(builder).shouldHaveExitValue(0); > > Thanks, > Erik > >> >> could you please review the updated version? >> >> Thanks, >> ? Igor >> >>> On May 10, 2016, at 8:32 PM, Jesper Wilhelmsson wrote: >>> >>> Looks good! >>> /Jesper >>> >>> Den 10/5/16 kl. 18:31, skrev Igor Ignatyev: >>>> http://cr.openjdk.java.net/~iignatyev/8156681/webrev.00/ >>>>> 71 lines changed: 71 ins; 0 del; 0 mod; >>>> >>>> Hi all, >>>> >>>> could you please integrate this small fix which adds a jtreg wrapper to run gtest tests? >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8156681 >>>> webrev: http://cr.openjdk.java.net/~iignatyev/8156681/webrev.00/ >>>> >>>> Thanks, >>>> ? Igor >>>> >> From joseph.provino at oracle.com Fri May 13 16:10:58 2016 From: joseph.provino at oracle.com (Joseph Provino) Date: Fri, 13 May 2016 12:10:58 -0400 Subject: RFR (XS) JDK-8153582 Logging of ConcGCThreads is done too early In-Reply-To: <1463136901.2392.5.camel@oracle.com> References: <5734C19B.5030303@oracle.com> <1463136901.2392.5.camel@oracle.com> Message-ID: <5735FC92.8000405@oracle.com> On 5/13/2016 6:55 AM, Thomas Schatzl wrote: > Hi, > > On Thu, 2016-05-12 at 13:47 -0400, Joseph Provino wrote: >> Please review this very small change to log ConcGCThreads >> and ParallelGCThreads correctly. >> >> Webrev: http://cr.openjdk.java.net/~jprovino/8153582/webrev.00 >> >> CR: JDK-8153582Logging of ConcGCThreads is done too early >> >> >> Messages look like below. >> >> java -Xlog:gc=trace -XX:+PrintFlagsFinal -version >> >> [0.002s][trace][gc] MarkStackSize: 4096k MarkStackSizeMax: 16384k >> [0.038s][trace][gc] ConcGCThreads: 5 >> [0.039s][trace][gc] ParallelGCThreads: 18 >> [0.056s][info ][gc] Using G1 >> >> java -Xlog:gc=trace -XX:+PrintFlagsFinal -XX:+UseConcMarkSweepGC >> -version >> >> [0.002s][trace][gc] MarkStackSize: 4096k MarkStackSizeMax: 524288k >> [1.001s][trace][gc] ConcGCThreads: 5 >> [1.001s][trace][gc] ParallelGCThreads: 18 >> [1.015s][info ][gc] Using Concurrent Mark Sweep > - not sure if this is "trace" level worthy, maybe debug level would > be more appropriate. Not opposed to using trace level, just questioning > the reason for using trace level here. > It does not look too detailed yet. The original log message used trace so I kept it the same. If you'd rather debug, I'll change it. > > - could you please use the latest webrev script available on http://o > penjdk.java.net/guide/webrevHelp.html in the future? The added links to > the next/pref changed file are a great addition. will do. - please add a small test case that checks the output. How do I do this? Who should I ask? joe Thanks, THomas From coleen.phillimore at oracle.com Fri May 13 18:26:48 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 13 May 2016 14:26:48 -0400 Subject: RFR(XS): 8156882 - Remove hotspot/test/testlibrary/whitebox In-Reply-To: <0c5001d1ad28$dfcff520$9f6fdf60$@oracle.com> References: <0c5001d1ad28$dfcff520$9f6fdf60$@oracle.com> Message-ID: <5c38325c-b6b0-09cf-5eac-dac00205b863@oracle.com> Looks good, thanks for doing this. I don't know. I consider it a bug that we have a wrong WhiteBox.java file lying around. Coleen On 5/13/16 11:05 AM, Christian Tornqvist wrote: > Hi everyone, > > > > Please review this small change that removes the unused > hotspot/test/testlibrary/whitebox . This should've been removed when > WhiteBox.java was moved to /test, it has caused hours of troubleshooting > when changes has been made in the wrong file. > > > > Note, this is an RFE and will need a RT approval to get into JDK9. > > > > Webrev: > > http://cr.openjdk.java.net/~ctornqvi/webrev/8156882/webrev.00/ > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8156882 > > > > Thanks, > > Christian > > > > > > > From joseph.provino at oracle.com Fri May 13 19:29:39 2016 From: joseph.provino at oracle.com (Joseph Provino) Date: Fri, 13 May 2016 15:29:39 -0400 Subject: RFR (XXS) JDK-8156964, gc/logging/TestUnifiedLoggingSwitchStress.java hits assert Message-ID: <57362B23.6090400@oracle.com> CR: JDK-8156964 gc/logging/TestUnifiedLoggingSwitchStress.java hits assert Webrev: http://cr.openjdk.java.net/~jprovino/8156964/webrev.00 From joseph.provino at oracle.com Fri May 13 19:40:58 2016 From: joseph.provino at oracle.com (Joseph Provino) Date: Fri, 13 May 2016 15:40:58 -0400 Subject: RFR (XXS) JDK-8156964, gc/logging/TestUnifiedLoggingSwitchStress.java hits assert In-Reply-To: <57362B23.6090400@oracle.com> References: <57362B23.6090400@oracle.com> Message-ID: <57362DCA.8020405@oracle.com> Hi Jesper, if you and Stefan review this change, I'll push it ASAP. Then I think I can remove the subtasks for the CR. On 5/13/2016 3:29 PM, Joseph Provino wrote: > CR: JDK-8156964 > gc/logging/TestUnifiedLoggingSwitchStress.java > hits assert > > Webrev: http://cr.openjdk.java.net/~jprovino/8156964/webrev.00 From stefan.karlsson at oracle.com Fri May 13 19:43:31 2016 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 13 May 2016 21:43:31 +0200 Subject: RFR (XXS) JDK-8156964, gc/logging/TestUnifiedLoggingSwitchStress.java hits assert In-Reply-To: <57362B23.6090400@oracle.com> References: <57362B23.6090400@oracle.com> Message-ID: <57362E63.5060402@oracle.com> Looks good. Thanks for removing this old debugging code. StefanK On 13/05/16 21:29, Joseph Provino wrote: > CR: JDK-8156964 > gc/logging/TestUnifiedLoggingSwitchStress.java > hits assert > > Webrev: http://cr.openjdk.java.net/~jprovino/8156964/webrev.00 From jesper.wilhelmsson at oracle.com Fri May 13 19:48:35 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Fri, 13 May 2016 21:48:35 +0200 Subject: RFR (XXS) JDK-8156964, gc/logging/TestUnifiedLoggingSwitchStress.java hits assert In-Reply-To: <57362DCA.8020405@oracle.com> References: <57362B23.6090400@oracle.com> <57362DCA.8020405@oracle.com> Message-ID: <0aa5e38e-464b-82af-c58b-9a441beff59b@oracle.com> Looks good! /Jesper Den 13/5/16 kl. 21:40, skrev Joseph Provino: > Hi Jesper, if you and Stefan review this change, I'll push it ASAP. > > Then I think I can remove the subtasks for the CR. > > On 5/13/2016 3:29 PM, Joseph Provino wrote: >> CR: JDK-8156964 >> gc/logging/TestUnifiedLoggingSwitchStress.java >> hits assert >> >> Webrev: http://cr.openjdk.java.net/~jprovino/8156964/webrev.00 > From igor.ignatyev at oracle.com Fri May 13 20:13:01 2016 From: igor.ignatyev at oracle.com (=?utf-8?B?aWdvci5pZ25hdHlldkBvcmFjbGUuY29t?=) Date: Fri, 13 May 2016 23:13:01 +0300 Subject: =?utf-8?B?UmU6IFJGUihYUyk6IDgxNTY4ODIgLSBSZW1vdmUgaG90c3BvdC90ZXN0L3Rlc3Rs?= =?utf-8?B?aWJyYXJ5L3doaXRlYm94?= Message-ID: <201605132013.u4DKD74f006198@aserv0121.oracle.com> Christian, Looks good to me. I also think it is a bug, so I don't think we need a FC exception, we just need to change a type of the issues. -- II ----- Reply message ----- From: "Coleen Phillimore" To: Subject: RFR(XS): 8156882 - Remove hotspot/test/testlibrary/whitebox Date: Fri, May 13, 2016 21:26 Looks good, thanks for doing this. I don't know. I consider it a bug that we have a wrong WhiteBox.java file lying around. Coleen On 5/13/16 11:05 AM, Christian Tornqvist wrote: > Hi everyone, > > > > Please review this small change that removes the unused > hotspot/test/testlibrary/whitebox . This should've been removed when > WhiteBox.java was moved to /test, it has caused hours of troubleshooting > when changes has been made in the wrong file. > > > > Note, this is an RFE and will need a RT approval to get into JDK9. > > > > Webrev: > > http://cr.openjdk.java.net/~ctornqvi/webrev/8156882/webrev.00/ > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8156882 > > > > Thanks, > > Christian > > > > > > > From erik.helin at oracle.com Mon May 16 12:44:02 2016 From: erik.helin at oracle.com (Erik Helin) Date: Mon, 16 May 2016 14:44:02 +0200 Subject: Submitted JEP 189: Shenandoah: An Ultra-Low-Pause-Time Garbage Collector In-Reply-To: <729617618.2672396.1463148140398.JavaMail.zimbra@redhat.com> References: <20160504075621.450403951eggemoggin.niobe.net> <729617618.2672396.1463148140398.JavaMail.zimbra@redhat.com> Message-ID: <20160516124402.GG32434@ehelin.jrpg.bea.com> I'm moving this thread to hotspot-dev since this JEP affects all of hotspot. I guess that the members from the runtime team and compiler team will want to comment on the changes to the interpreter, C1 and C2. On 2016-05-13, Christine Flood wrote: > OK, I've put together a pdf document which summarizes our changes. Thank you for writing this up. Will you incorporate most of this document into the JEP? > I'm happy to go into more detail or answer questions. Reading through the document, I have a few initial high-level questions: - Which platforms does Shenandoah run on (CPUs/OSs)? Which platforms do you intend Shenandoah to run on? - For the goal of the JEP, do you have any particular benchmark in mind for determining when you have reached the goal? You have stated less than 100 ms pauses on 100 GB, but variables such as allocation rate, live set, etc. also tend to affect the GC. It might be easier to determine that you have reached your goal if you have a specific setup (OS, CPU, RAM) and a specific benchmark in mind. - When you state "most" GCs will be below 100 ms, do you have any number in mind? 99% of all GCs? 99.9%? - Who will maintain the Shenadoah code? Reading through the JEP, I noticed the line "...as opposed to G1 which focuses on young generation collection to help limit remembered-set size." The main reason for the young collections in G1 is to improve throughput, not to limit the size of the remembered sets. If an application follows the generational hypothesis, then a young generation can be quite a boost to throughput. We still have a remembered set per young region, but it only keeps track of pointers from old regions to young regions (not pointers between young regions). Would you please remove this statement from the JEP? Thanks, Erik > > Christine > > > ----- Original Message ----- > > From: "mark reinhold" > > To: hotspot-gc-dev at openjdk.java.net, "Christine Flood" , "Roman Kennke" > > Sent: Wednesday, May 4, 2016 10:56:21 AM > > Subject: Submitted JEP 189: Shenandoah: An Ultra-Low-Pause-Time Garbage Collector > > > > HotSpot GC developers -- Christine recently moved this JEP [1] to the > > Submitted state. Roman has made point proposals for some preparatory > > changes but there's been little response, so far, from anyone else on > > this list. As noted in JEP 1 [2], having consensus around a proposal > > is an essential part of moving a JEP forward. I'd therefore like to > > hear your views, not just on Roman's first proposals but on Shenandoah > > as a whole, especially with regard to the additional read and write > > barriers that would be needed and the potential for those to affect > > the existing collectors and also the run-time system. > > > > Christine and Roman -- I think it'd help for you to post a detailed > > plan of all that you'd want to change outside of Shenandoah itself, so > > that others can understand its potential impact. Such a plan would be > > easier to evaluate than a series of point changes, and can eventually > > be merged into the text of the JEP for the record. > > > > - Mark > > > > > > [1] http://openjdk.java.net/jeps/189 > > [2] http://openjdk.java.net/jeps/1 > > From daniel.daugherty at oracle.com Mon May 16 14:15:00 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 16 May 2016 08:15:00 -0600 Subject: RFR: 8154715: Missing destructor and/or TLS clearing calls for terminating threads In-Reply-To: <8f72e402-95fa-41c3-e212-c2efeb0b7ce0@oracle.com> References: <572C4198.3090900@oracle.com> <572CA452.70401@oracle.com> <19147ab9-2480-3ace-6eaf-611eccc29ebf@oracle.com> <572CBB30.1010801@oracle.com> <3fb637e4-0dbe-31d6-2202-574ad3256a95@oracle.com> <55edc3b5-bd68-0e06-8003-bb9bf8093851@oracle.com> <57305896.8020306@oracle.com> <94D9AA1E-4819-4F99-80DE-C30176FEC926@getsnappy.com> <8f72e402-95fa-41c3-e212-c2efeb0b7ce0@oracle.com> Message-ID: <58d6c018-3753-5e45-26ed-5769421ddc35@oracle.com> On 5/10/16 8:17 PM, David Holmes wrote: > On 11/05/2016 6:28 AM, Brian Gardner wrote: >> I really like the rename of java_start to native_thread_entry, it makes >> things make more sense. It looks like os_bsd.cpp and os_linux.cpp are >> both missing the clear_thread_current logic after thread->run(). > > Doh! Thanks. That's what I get for trying to multi-task :) > > Webrev updated in place. > > Can I get another review from someone in hotspot please. Dan is > unfortunately (for me) away. Sorry about that. Had end of year choir and graduation things to take care of... :-) > so anyone introducing their deletion is informed by a guarantee(false) In recent reviews, folks have been asking that we use fatal("my message"); instead of: guarantee(false, "my message"); I see the changeset is already pushed so don't worry about it for this one. Dan > > Thanks, > David > >> + // If a thread has not deleted itself ("delete this") as part of its >> + // termination sequence, we have to ensure thread-local-storage is >> + // cleared before we actually terminate. No threads should ever be >> + // deleted asynchronously with respect to their termination. >> + if (Thread::current_or_null_safe() != NULL) { >> + assert(Thread::current_or_null_safe() == thread, "current thread is >> wrong"); >> + thread->clear_thread_current(); >> + } >> + >> >> >>> On May 9, 2016, at 5:33 PM, David Holmes >> > wrote: >>> >>> Okay here is version 2: >>> >>> http://cr.openjdk.java.net/~dholmes/8154715/webrev.v2/ >>> >>> Lots of cosmetic changes but only a couple of functional ones: >>> >>> - After thread->run() returns we clear the TLS by calling >>> clear_thread_current(), but only for threads where it has not already >>> been cleared - as those threads may already have been deleted so we >>> can't dereference 'thread' >>> >>> - No asynchronous thread deletion is permitted, and we avoid races >>> with VM termination. This means the VMThread no longer gets deleted - >>> that should not be an issue as many threads do not get deleted when >>> the VM terminates. I added destructors for the VMThread and >>> WatcherThread so anyone introducing their deletion is informed by a >>> guarantee(false) >>> >>> >>> Cosmetic changes: >>> >>> - renamed java_start to thread_native_entry (it is used by all threads >>> not just "java" ones, so this avoids potential confusion) >>> >>> - updated os::free_thread to always assume it works on the current >>> thread (and add assert to verify that) >>> >>> Thanks, >>> David >> From ENOMIKI at jp.ibm.com Mon May 16 05:53:48 2016 From: ENOMIKI at jp.ibm.com (Miki M Enoki) Date: Mon, 16 May 2016 14:53:48 +0900 Subject: PPC64 VSX load/store instructions in stubs In-Reply-To: References: <56FEDBB3.5030106@linux.vnet.ibm.com><57339EE1.2040500@linux.vnet.ibm.com> Message-ID: <201605160553.u4G5rvIm027656@d19av06.sagamino.japan.ibm.com> Dear Gustavo, Volker, and Martin I also implemented VSX disjoint long arraycopy. I appreciate it if it is applied to OpenJDK, too. The performance was almost better than the original code. VSX(max) means aligned case, while VSX(min) is unaligned case. In addition, VMX can be better if unaligned. http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160417/fb12037e/result-0001.jpg The benchmark code is here. http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160417/fb12037e/ArrayCopyTest1-0001.java Server: 8247-22L (POWER8 (3.3GHz 12 cores) x2, 512GB memory), Ubuntu Linux 15.04 ppc64LE (kernel: 3.19.0-18-generic), OpenJDK (build based on 1.9), JVMARGS: ?-Xmx40g ?Xms40g -Xmn20g" created patches are for Java9. http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160417/fb12037e/ppc64le_vsx-0001.diff http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20160417/fb12037e/ppc64le_vmx-0001.diff I would appreciate your comments. Best regards, Miki "ppc-aix-port-dev" wrote on 2016/05/12 18:33:03: > From: "Doerr, Martin" > To: Gustavo Romero , Volker Simonis > > Cc: "Simonis, Volker" , "ppc-aix-port- > dev at openjdk.java.net" , "hotspot- > dev at openjdk.java.net" , > "brenohl at br.ibm.com" > Date: 2016/05/12 18:34 > Subject: RE: PPC64 VSX load/store instructions in stubs > Sent by: "ppc-aix-port-dev" > > Hi Gustavo, > > thanks for providing the webrevs. The change looks basically good. > > I only have the following concerns: > - We basically support configuring dscr by various DSCR switches. > Your code resets the value to hardware default instead of the > possibly modified values. We're currently only using default DSCR > values, but maybe we may want to play with them in the future. > We could use a static variable for the default dscr value. It could > be modified in VM_Version::config_dscr() and used by your restore > code (load_const_optimized(tmp1, ...) instead of li(tmp1, 0)). > > - The PPC-elf64abi-1.9 says: "Functions must ensure that the > appropriate bits in the vrsave register are set for any vector > registers they use. ...". I think not touching vrsave is the right > thing for AIX and ppc64le, but I think we will either have to skip > the optimization on ppc64 big endian or handle vrsave. Do you agree? > > Best regards, > Martin > > > -----Original Message----- > From: Gustavo Romero [mailto:gromero at linux.vnet.ibm.com] > Sent: Mittwoch, 11. Mai 2016 23:07 > To: Volker Simonis > Cc: Doerr, Martin ; Simonis, Volker > ; ppc-aix-port-dev at openjdk.java.net; > hotspot-dev at openjdk.java.net; brenohl at br.ibm.com > Subject: Re: PPC64 VSX load/store instructions in stubs > Importance: High > > Hi Volker, Hi Martin > > Sincere apologies for the long delay. > > My initial approach to test the VSX load/store was from an > extracted snippet regarding just the mass copy loop "grafted" insidean inline > asm, performing isolated tests with "perf" tool focused only on > aligned source and > destination (best case). > > The extracted code, called "Original" in the plot below (black line), is here: > https://github.com/gromero/arraycopy/blob/2pairs/arraycopy.c#L27-L36 > > That extracted, after some experiments, evolved into this one that employs VSX > load/store, Data Stream deepest pre-fetch, d-cache touch, and > backbranch aligned > to 32-byte: > https://github.com/gromero/arraycopy/blob/2pairs/arraycopy_vsx.c#L27-L41 > > All runs where "pinned" using `numactl --cpunodebind --membind` to avoid any > scheduler decision that could add noise to the measure. > > VSX, deepest data pre-fetch, d-cache touch, and 32-bytes align > proved to be better > in the isolated code (red line) in comparison to the original extracted code > (black line): > http://gromero.github.io/openjdk/original_vsx_non_pf_vsx_pf_deepest.pdf > > So I proceeded to implement the VSX loop in OpenJDK based on the best case > result (VSX, pre-fetch deepest, d-cache touch, and backbranch target align - > goetz TODO note). > > OpenJDK 8 webrev: > http://81.de.7a9f.ip4.static.sl-reverse.com/8154156/8/ > > OpenJDK 9 webrev: > http://81.de.7a9f.ip4.static.sl-reverse.com/8154156/9/ > > I've tested the change on OpenJDK 8 using this script that calls > System.arraycopy() on shorts: > https://goo.gl/8UWtLm > > The results for all data alignment cases: > http://gromero.github.io/openjdk/src_0_dst_0.pdf > http://gromero.github.io/openjdk/src_1_dst_0.pdf > http://gromero.github.io/openjdk/src_0_dst_1.pdf > http://gromero.github.io/openjdk/src_1_dst_1.pdf > > Martin, I added the vsx test to the feature-string. Regarding the > ABI, I'm just > using two VSR: vsr0 and vsr1, both volatile. > > Volker, as the loop unrolling was removed now the loop copies 16 > elemets a time, > like the non-VSX loop, and not 32 elements. I just verified the > change on Little > endian. Sorry I didn't understand your question regarding "instructions for > aligned load/stores". Did you mean instructions for unaligned load/ > stores? I think > both fixed-point (ld/std) and VSX instructions will do load/store slower in > unaligned scenario. However VMX load/store is different and expects aligned > operands. Thank you very much for opening the bug > https://bugs.openjdk.java.net/browse/JDK-8154156 > > I don't have the profiling per function for each SPEC{jbb,jvm} benchmark > in order to determine which one would stress the proposed change better. > Could I use a better benchmark? > > Thank you! > > Best regards, > Gustavo > > On 05-04-2016 14:23, Volker Simonis wrote: > > Hi Gustavo, > > > > thanks a lot for your contribution. > > > > Can you please describe if you've run benchmarks and which performance > > improvements you saw? > > > > With your change if we're running on Power 8, we will only use the > > fast path for arrays with at least 32 elements. For smaller arrays, we > > will fall-back to copying only 2 elements at a time which will be > > slower than the initial version which copied 4 at a time in that case. > > > > Did you verified your changes on both, little and big endian? > > > > And what about unaligned memory accesses? As far as I read, > > lxvd2x/stxvd2x still work, but may be slower. I saw there also exist > > instructions for aligned load/stores. Would it make sens > > (performance-wise) to use them for the cases where we can be sure that > > we have aligned memory accesses? > > > > Thank you and best regards, > > Volker > > > > > > On Fri, Apr 1, 2016 at 10:36 PM, Gustavo Romero > > wrote: > >> Hi Martin, Hi Volker > >> > >> Currently VSX load/store instructions are not being used in PPC64 stubs, > >> particularly in arraycopy stubs inside generate_arraycopy_stubs() like, > >> but not limited to, generate_disjoint_{byte,short,int,long}_copy. > >> > >> We can speed up mass copy using VSX (Vector-Scalar Extension) load/store > >> instruction in processors >= POWER8, the same way it's already done for > >> libc memcpy(). > >> > >> This is an initial patch just for jshort_disjoint_arraycopy() VSX vector > >> load/store: > >> > >> http://81.de.7a9f.ip4.static.sl-reverse.com/202539/webrev > >> > >> What are your thoughts on that? Is there any impediment to use VSX > >> instructions in OpenJDK at the moment? > >> > >> Thank you. > >> > >> Best regards, > >> Gustavo > >> > > > From brenohl at br.ibm.com Mon May 16 17:28:44 2016 From: brenohl at br.ibm.com (Breno Leitao) Date: Mon, 16 May 2016 14:28:44 -0300 Subject: PPC64 VSX load/store instructions in stubs In-Reply-To: References: <56FEDBB3.5030106@linux.vnet.ibm.com><57339EE1.2040500@linux.vnet.ibm.com> Message-ID: <573A034C.9060602@br.ibm.com> Hi Miki, On 05/16/2016 02:53 AM, Miki M Enoki wrote: > I also implemented VSX disjoint long arraycopy. > I appreciate it if it is applied to OpenJDK, too. Thanks for the summarized information, this is helpful. Based on your plot, I understand we can split the whole scenario in two: * Array size smaller than 4k, and then use VSX instructions to perform copy * Array size bigger than 4k, and then use VMX instructions to perform copy The same mechanism could be used to copy arrays of short elements, as Gustavo was working on. Do you agree? That said, I understand that a new patch should be generated that contemplates both cases on a single patch, ready to be applied on OpenJDK 9 source code. Hence a webrev should be generated mapping to bug id https://bugs.openjdk.java.net/browse/JDK-8154156 If you need any help on the webrev[1] creation and hosting, Gustavo might help, since he did this process already. [1] http://openjdk.java.net/guide/webrevHelp.html From gromero at linux.vnet.ibm.com Mon May 16 18:25:10 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Mon, 16 May 2016 15:25:10 -0300 Subject: SIGILL crashes JVM on PPC64 LE In-Reply-To: References: <5733B30D.6010201@linux.vnet.ibm.com> Message-ID: <201605161825.u4GIO8g8023200@mx0a-001b2d01.pphosted.com> Hi Volker Thanks for inspecting the Hotspot crash log. At the moment it's no possible, AFIAK - and as I could try - to run Cassandra on OpenJDK 9. It will hit another missing class issue before it runs into the SIGILL issue. I'm still trying to reproduce it with an easy test case. However, I provide the C2 compiled method disasm: hs_err log: http://hastebin.com/raw/orufukacos hs_err method disasm: http://hastebin.com/raw/owoxamodok Source for one of the four problematic classes that will crash JVM when compiled (we can see them in hs_err method disasm comments): java/org/apache/cassandra/db/rows/NativeCell.java#L133 https://goo.gl/Uefq8Y Thanks for letting me know that `isel` is never emitted. Thank you! Best regards, Gustavo On 12-05-2016 09:39, Volker Simonis wrote: > And I forgot to mention: I've checked and we don't emit vsel > instructions in jdk8 on ppc. So it must be a coincidence that changing > the endianess of the offending instruction yields a valid 'vsel' > instruction. > > > > On Thu, May 12, 2016 at 2:26 PM, Volker Simonis > wrote: >> Hi Gustavo, >> >> thanks for the bug report. The hs_err file you provided indicates that >> this crash happened with Ubuntu's openjdk 8 version. Can you still >> reproduce this with the the newest jdk9 builds? >> >> Also, I can see from the hs_err file that the crash happened in the C2 >> compiled method java.util.TimSort.countRunAndMakeAscending which >> doesn't seem to be related to nio and unsafe. >> >> Ideally, you could post an easy test case to reproduce the problem. If >> that's not possible, it would be helpful if you could post the output >> of a failing run with >> "-XX:CompileCommand=print,java.util.TimSort::countRunAndMakeAscending >> -XX:CompileCommand=option,java.util.TimSort::countRunAndMakeAscending,PrintOptoAssembly". >> In order to get the disassembly output for compiled methods you have >> to build the hsdis library from hotspot/src/share/tools/hsdis (it has >> a README with build instructions). >> >> Regards, >> Volker >> >> >> On Thu, May 12, 2016 at 12:32 AM, Gustavo Romero >> wrote: >>> Hi >>> >>> I'm getting a nasty SIGILL that crashes the JVM on PPC64 LE. >>> >>> hs_err log: >>> http://hastebin.com/raw/fovagunaci >>> >>> The application employs methods from both java.nio.ByteBuffer and >>> sun.misc.Unsafe classes in order to write and read from an allocated buffer. >>> >>> A interesting thing is that after debugging the instruction that caused the >>> said SIGILL: >>> >>> 0x3fff902839a4: cmpwi cr6,r17,0 >>> 0x3fff902839a8: beq cr6,0x3fff90283ae4 >>> 0x3fff902839ac: .long 0xea2f0013 <============ illegal instruction >>> 0x3fff902839b0: add r15,r15,r17 >>> 0x3fff902839b4: add r14,r17,r14 >>> >>> I found that when its endianness is changed it turns out to be a valid >>> instruction: vsel v24,v0,v5,v31 >>> >>> However, I'm still unable to determine if it's an application issue, something >>> with JVM unsafe interface code, or something else. >>> >>> Any clue on how to narrow down this SIGILL? >>> >>> Thank you! >>> >>> Regards, >>> Gustavo >>> > From gromero at linux.vnet.ibm.com Mon May 16 22:09:40 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Mon, 16 May 2016 19:09:40 -0300 Subject: SIGILL crashes JVM on PPC64 LE In-Reply-To: <201605161825.u4GIO8g8023200@mx0a-001b2d01.pphosted.com> References: <5733B30D.6010201@linux.vnet.ibm.com> <201605161825.u4GIO8g8023200@mx0a-001b2d01.pphosted.com> Message-ID: <201605162209.u4GM9WC4008256@mx0b-001b2d01.pphosted.com> Hi Volker I'm not sure, but it seems that the bytecode i2l is wrong for some reason. It should be mapped to extsw asm instruction I think. Is there just one code path that controls this mapping on PPC? Thank you. Regards, Gustavo On 16-05-2016 15:25, Gustavo Romero wrote: > Hi Volker > > Thanks for inspecting the Hotspot crash log. > > At the moment it's no possible, AFIAK - and as I could try - to run > Cassandra on OpenJDK 9. It will hit another missing class issue before > it runs into the SIGILL issue. > > I'm still trying to reproduce it with an easy test case. > > However, I provide the C2 compiled method disasm: > > hs_err log: > http://hastebin.com/raw/orufukacos > > hs_err method disasm: > http://hastebin.com/raw/owoxamodok > > Source for one of the four problematic classes that will crash JVM when > compiled (we can see them in hs_err method disasm comments): > java/org/apache/cassandra/db/rows/NativeCell.java#L133 > https://goo.gl/Uefq8Y > > Thanks for letting me know that `isel` is never emitted. > > Thank you! > > Best regards, > Gustavo > > On 12-05-2016 09:39, Volker Simonis wrote: >> And I forgot to mention: I've checked and we don't emit vsel >> instructions in jdk8 on ppc. So it must be a coincidence that changing >> the endianess of the offending instruction yields a valid 'vsel' >> instruction. >> >> >> >> On Thu, May 12, 2016 at 2:26 PM, Volker Simonis >> wrote: >>> Hi Gustavo, >>> >>> thanks for the bug report. The hs_err file you provided indicates that >>> this crash happened with Ubuntu's openjdk 8 version. Can you still >>> reproduce this with the the newest jdk9 builds? >>> >>> Also, I can see from the hs_err file that the crash happened in the C2 >>> compiled method java.util.TimSort.countRunAndMakeAscending which >>> doesn't seem to be related to nio and unsafe. >>> >>> Ideally, you could post an easy test case to reproduce the problem. If >>> that's not possible, it would be helpful if you could post the output >>> of a failing run with >>> "-XX:CompileCommand=print,java.util.TimSort::countRunAndMakeAscending >>> -XX:CompileCommand=option,java.util.TimSort::countRunAndMakeAscending,PrintOptoAssembly". >>> In order to get the disassembly output for compiled methods you have >>> to build the hsdis library from hotspot/src/share/tools/hsdis (it has >>> a README with build instructions). >>> >>> Regards, >>> Volker >>> >>> >>> On Thu, May 12, 2016 at 12:32 AM, Gustavo Romero >>> wrote: >>>> Hi >>>> >>>> I'm getting a nasty SIGILL that crashes the JVM on PPC64 LE. >>>> >>>> hs_err log: >>>> http://hastebin.com/raw/fovagunaci >>>> >>>> The application employs methods from both java.nio.ByteBuffer and >>>> sun.misc.Unsafe classes in order to write and read from an allocated buffer. >>>> >>>> A interesting thing is that after debugging the instruction that caused the >>>> said SIGILL: >>>> >>>> 0x3fff902839a4: cmpwi cr6,r17,0 >>>> 0x3fff902839a8: beq cr6,0x3fff90283ae4 >>>> 0x3fff902839ac: .long 0xea2f0013 <============ illegal instruction >>>> 0x3fff902839b0: add r15,r15,r17 >>>> 0x3fff902839b4: add r14,r17,r14 >>>> >>>> I found that when its endianness is changed it turns out to be a valid >>>> instruction: vsel v24,v0,v5,v31 >>>> >>>> However, I'm still unable to determine if it's an application issue, something >>>> with JVM unsafe interface code, or something else. >>>> >>>> Any clue on how to narrow down this SIGILL? >>>> >>>> Thank you! >>>> >>>> Regards, >>>> Gustavo >>>> >> > From david.holmes at oracle.com Tue May 17 02:04:07 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 17 May 2016 12:04:07 +1000 Subject: Submitted JEP 189: Shenandoah: An Ultra-Low-Pause-Time Garbage Collector In-Reply-To: <20160516124402.GG32434@ehelin.jrpg.bea.com> References: <20160504075621.450403951eggemoggin.niobe.net> <729617618.2672396.1463148140398.JavaMail.zimbra@redhat.com> <20160516124402.GG32434@ehelin.jrpg.bea.com> Message-ID: <8cc7b57c-aa73-2fe2-30a8-91260974067d@oracle.com> Hi, On 16/05/2016 10:44 PM, Erik Helin wrote: > I'm moving this thread to hotspot-dev since this JEP affects all of > hotspot. I guess that the members from the runtime team and compiler > team will want to comment on the changes to the interpreter, C1 and C2. > > On 2016-05-13, Christine Flood wrote: >> OK, I've put together a pdf document which summarizes our changes. For the benefit of others: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20160513/cde124dd/ShenandoahProposal-0001.pdf David ----- > Thank you for writing this up. Will you incorporate most of this > document into the JEP? > >> I'm happy to go into more detail or answer questions. > > Reading through the document, I have a few initial high-level questions: > - Which platforms does Shenandoah run on (CPUs/OSs)? Which platforms do > you intend Shenandoah to run on? > - For the goal of the JEP, do you have any particular benchmark in mind > for determining when you have reached the goal? You have stated less > than 100 ms pauses on 100 GB, but variables such as allocation rate, > live set, etc. also tend to affect the GC. It might be easier to > determine that you have reached your goal if you have a specific setup > (OS, CPU, RAM) and a specific benchmark in mind. > - When you state "most" GCs will be below 100 ms, do you have any number > in mind? 99% of all GCs? 99.9%? > - Who will maintain the Shenadoah code? > > Reading through the JEP, I noticed the line "...as opposed to G1 which > focuses on young generation collection to help limit remembered-set > size." The main reason for the young collections in G1 is to improve > throughput, not to limit the size of the remembered sets. If an > application follows the generational hypothesis, then a young generation > can be quite a boost to throughput. We still have a remembered set per > young region, but it only keeps track of pointers from old regions to > young regions (not pointers between young regions). Would you please > remove this statement from the JEP? > > Thanks, > Erik > >> >> Christine >> >> >> ----- Original Message ----- >>> From: "mark reinhold" >>> To: hotspot-gc-dev at openjdk.java.net, "Christine Flood" , "Roman Kennke" >>> Sent: Wednesday, May 4, 2016 10:56:21 AM >>> Subject: Submitted JEP 189: Shenandoah: An Ultra-Low-Pause-Time Garbage Collector >>> >>> HotSpot GC developers -- Christine recently moved this JEP [1] to the >>> Submitted state. Roman has made point proposals for some preparatory >>> changes but there's been little response, so far, from anyone else on >>> this list. As noted in JEP 1 [2], having consensus around a proposal >>> is an essential part of moving a JEP forward. I'd therefore like to >>> hear your views, not just on Roman's first proposals but on Shenandoah >>> as a whole, especially with regard to the additional read and write >>> barriers that would be needed and the potential for those to affect >>> the existing collectors and also the run-time system. >>> >>> Christine and Roman -- I think it'd help for you to post a detailed >>> plan of all that you'd want to change outside of Shenandoah itself, so >>> that others can understand its potential impact. Such a plan would be >>> easier to evaluate than a series of point changes, and can eventually >>> be merged into the text of the JEP for the record. >>> >>> - Mark >>> >>> >>> [1] http://openjdk.java.net/jeps/189 >>> [2] http://openjdk.java.net/jeps/1 >>> > > From jesper.wilhelmsson at oracle.com Tue May 17 07:26:30 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 17 May 2016 09:26:30 +0200 Subject: jdk9/hs is OPEN for pushes Message-ID: Hi, After a few emergency fixes we now have a snapshot worthy of pushing to jdk9/dev. This means that we can open jdk9/hs for normal work again. Thank you for your patience! /Jesper From jesper.wilhelmsson at oracle.com Tue May 17 07:31:07 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 17 May 2016 09:31:07 +0200 Subject: jdk9/hs is OPEN for pushes In-Reply-To: References: Message-ID: <2dcd2f41-e640-9aed-16af-7528ddd8e32f@oracle.com> Please note that we are now passed FC so only bugfixes should be pushed. /Jesper Den 17/5/16 kl. 09:26, skrev Jesper Wilhelmsson: > Hi, > > After a few emergency fixes we now have a snapshot worthy of pushing to > jdk9/dev. This means that we can open jdk9/hs for normal work again. > > Thank you for your patience! > /Jesper From erik.helin at oracle.com Tue May 17 08:16:54 2016 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 17 May 2016 10:16:54 +0200 Subject: Add top-level Makefile target for running gtest Message-ID: <20160517081654.GH32434@ehelin.jrpg.bea.com> Hi all, this small patch adds a top-level Makefile target for conveniently running the gtest unit tests. Bug: https://bugs.openjdk.java.net/browse/JDK-8157028 Webrev: http://cr.openjdk.java.net/~ehelin/8157028/webrev.00/ Testing: - Running locally on Linux x86-64 Thanks, Erik From erik.helin at oracle.com Tue May 17 09:33:37 2016 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 17 May 2016 11:33:37 +0200 Subject: RFR(S) : 8156681 : Add jtreg wrapper for hotspot gtest tests In-Reply-To: <22445A65-BB80-45F0-B371-C87D585AE2F2@oracle.com> References: <43534a4a-a132-292c-8333-64d45074ad62@oracle.com> <4E7A2108-8DF2-418F-A3D4-708FCD1FCC9F@oracle.com> <20160513073607.GA25871@ehelin.jrpg.bea.com> <22445A65-BB80-45F0-B371-C87D585AE2F2@oracle.com> Message-ID: <20160517093337.GI32434@ehelin.jrpg.bea.com> On 2016-05-13, Igor Ignatyev wrote: > Hey Erik, > > I've updated the fix to be more readable. > > webrev: http://cr.openjdk.java.net/~iignatyev/8156681/webrev.02/ Looks good, Reviewed. Thanks, Erik > diff b/w webrev.02 and webrev.01 : http://cr.openjdk.java.net/~iignatyev/8156681-diif/webrev.01/ > > ? Igor > > > On May 13, 2016, at 10:36 AM, Erik Helin wrote: > > > > On 2016-05-12, Igor Ignatyev wrote: > >> Jesper, > >> > >> 1st of all, thank you for review. > >> > >> unfortunately, testing in our infra reveled some problems w/ the wrapper: > >> - gtest test library can be located right in ?test.nativepath? or in ?test.nativepath?/../../gtest > >> - the wrapper pass all flags to gtestLauncher including flags which are not JVM flags, gtestLauncher pass all these args to JNI_CreateJavaVM, so we fail w/ 'Unrecognized option' > >> > >> I have updated the webrev : http://cr.openjdk.java.net/~iignatyev/8156681/webrev.01/ > > > > I don't understand the first path. Is System.getProperty("test.nativepath") either > > "/hotspot/jtreg/native" or "/hotspot/gtest"? Or > > is it something else? What do you want the final path to be? > the final path should be /hotspot/gtest/ > > > > > > Is the indentation a bit off here? > > 62 Stream.of( > > 63 path.toString(), > > 64 "-jdk", > > 65 System.getProperty("test.jdk")), > > 66 Arrays.stream(Utils.getTestJavaOpts()) > > 67 .filter(s -> s.startsWith("-X") || s.startsWith("-D"))) > > > > since you always want the first three arguments, is the following a bit easier to understand? > I split that into 3 statements. > > > > List options = Arrays.stream(Utils.getTestJavaOpts()) > > .filter(s -> s.startsWith("-X") || s.startsWith("-D")) > > .collect(Collectors.toList()); > > List cmd = Arrays.asList(path.toString(), "-jdk", System.getProperty("test.jdk")); > > cmd.addAll(options); > > > > The following > > 70 OutputAnalyzer oa = ProcessTools.executeProcess(builder); > > 71 oa.shouldHaveExitValue(0); > > > > could also be shortened to one line if you prefer that: > > > > ProcessTools.executeProcess(builder).shouldHaveExitValue(0); > > > > Thanks, > > Erik > > > >> > >> could you please review the updated version? > >> > >> Thanks, > >> ? Igor > >> > >>> On May 10, 2016, at 8:32 PM, Jesper Wilhelmsson wrote: > >>> > >>> Looks good! > >>> /Jesper > >>> > >>> Den 10/5/16 kl. 18:31, skrev Igor Ignatyev: > >>>> http://cr.openjdk.java.net/~iignatyev/8156681/webrev.00/ > >>>>> 71 lines changed: 71 ins; 0 del; 0 mod; > >>>> > >>>> Hi all, > >>>> > >>>> could you please integrate this small fix which adds a jtreg wrapper to run gtest tests? > >>>> > >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8156681 > >>>> webrev: http://cr.openjdk.java.net/~iignatyev/8156681/webrev.00/ > >>>> > >>>> Thanks, > >>>> ? Igor > >>>> > >> > From erik.joelsson at oracle.com Tue May 17 09:49:49 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 17 May 2016 11:49:49 +0200 Subject: Add top-level Makefile target for running gtest In-Reply-To: <20160517081654.GH32434@ehelin.jrpg.bea.com> References: <20160517081654.GH32434@ehelin.jrpg.bea.com> Message-ID: <573AE93D.9040004@oracle.com> Looks good! /Erik On 2016-05-17 10:16, Erik Helin wrote: > Hi all, > > this small patch adds a top-level Makefile target for conveniently > running the gtest unit tests. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8157028 > > Webrev: > http://cr.openjdk.java.net/~ehelin/8157028/webrev.00/ > > Testing: > - Running locally on Linux x86-64 > > Thanks, > Erik From stuart.monteith at linaro.org Tue May 17 09:50:30 2016 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Tue, 17 May 2016 10:50:30 +0100 Subject: JEP 230 Status Message-ID: Hellol, It appears that "JEP 230: Microbenchmark Suite"[1] is currently dormant. However, there has been some activity in terms of the JIRA task [2] and Mikael Vidsted has been assigned as the owner. I'm sure I won't be the only interested to know the intention behind JEP 230, and subsequently to contribute benchmarks to it. Is there an expected time frame for when the JEP will be completed? Thanks, Stuart [1] http://openjdk.java.net/jeps/230 [2] https://bugs.openjdk.java.net/browse/JDK-8050952 From jesper.wilhelmsson at oracle.com Tue May 17 09:53:58 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 17 May 2016 11:53:58 +0200 Subject: Add top-level Makefile target for running gtest In-Reply-To: <20160517081654.GH32434@ehelin.jrpg.bea.com> References: <20160517081654.GH32434@ehelin.jrpg.bea.com> Message-ID: Looks good! /Jesper Den 17/5/16 kl. 10:16, skrev Erik Helin: > Hi all, > > this small patch adds a top-level Makefile target for conveniently > running the gtest unit tests. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8157028 > > Webrev: > http://cr.openjdk.java.net/~ehelin/8157028/webrev.00/ > > Testing: > - Running locally on Linux x86-64 > > Thanks, > Erik > From jesper.wilhelmsson at oracle.com Tue May 17 09:55:01 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 17 May 2016 11:55:01 +0200 Subject: RFR(S) : 8156681 : Add jtreg wrapper for hotspot gtest tests In-Reply-To: <22445A65-BB80-45F0-B371-C87D585AE2F2@oracle.com> References: <43534a4a-a132-292c-8333-64d45074ad62@oracle.com> <4E7A2108-8DF2-418F-A3D4-708FCD1FCC9F@oracle.com> <20160513073607.GA25871@ehelin.jrpg.bea.com> <22445A65-BB80-45F0-B371-C87D585AE2F2@oracle.com> Message-ID: <2bdf271e-31ed-df0b-912a-4d8a62f374b9@oracle.com> Looks good! /Jesper Den 13/5/16 kl. 18:09, skrev Igor Ignatyev: > Hey Erik, > > I've updated the fix to be more readable. > > webrev: http://cr.openjdk.java.net/~iignatyev/8156681/webrev.02/ > diff b/w webrev.02 and webrev.01 : http://cr.openjdk.java.net/~iignatyev/8156681-diif/webrev.01/ > > ? Igor > >> On May 13, 2016, at 10:36 AM, Erik Helin wrote: >> >> On 2016-05-12, Igor Ignatyev wrote: >>> Jesper, >>> >>> 1st of all, thank you for review. >>> >>> unfortunately, testing in our infra reveled some problems w/ the wrapper: >>> - gtest test library can be located right in ?test.nativepath? or in ?test.nativepath?/../../gtest >>> - the wrapper pass all flags to gtestLauncher including flags which are not JVM flags, gtestLauncher pass all these args to JNI_CreateJavaVM, so we fail w/ 'Unrecognized option' >>> >>> I have updated the webrev : http://cr.openjdk.java.net/~iignatyev/8156681/webrev.01/ >> >> I don't understand the first path. Is System.getProperty("test.nativepath") either >> "/hotspot/jtreg/native" or "/hotspot/gtest"? Or >> is it something else? What do you want the final path to be? > the final path should be /hotspot/gtest/ >> >> >> Is the indentation a bit off here? >> 62 Stream.of( >> 63 path.toString(), >> 64 "-jdk", >> 65 System.getProperty("test.jdk")), >> 66 Arrays.stream(Utils.getTestJavaOpts()) >> 67 .filter(s -> s.startsWith("-X") || s.startsWith("-D"))) >> >> since you always want the first three arguments, is the following a bit easier to understand? > I split that into 3 statements. >> >> List options = Arrays.stream(Utils.getTestJavaOpts()) >> .filter(s -> s.startsWith("-X") || s.startsWith("-D")) >> .collect(Collectors.toList()); >> List cmd = Arrays.asList(path.toString(), "-jdk", System.getProperty("test.jdk")); >> cmd.addAll(options); >> >> The following >> 70 OutputAnalyzer oa = ProcessTools.executeProcess(builder); >> 71 oa.shouldHaveExitValue(0); >> >> could also be shortened to one line if you prefer that: >> >> ProcessTools.executeProcess(builder).shouldHaveExitValue(0); >> >> Thanks, >> Erik >> >>> >>> could you please review the updated version? >>> >>> Thanks, >>> ? Igor >>> >>>> On May 10, 2016, at 8:32 PM, Jesper Wilhelmsson wrote: >>>> >>>> Looks good! >>>> /Jesper >>>> >>>> Den 10/5/16 kl. 18:31, skrev Igor Ignatyev: >>>>> http://cr.openjdk.java.net/~iignatyev/8156681/webrev.00/ >>>>>> 71 lines changed: 71 ins; 0 del; 0 mod; >>>>> >>>>> Hi all, >>>>> >>>>> could you please integrate this small fix which adds a jtreg wrapper to run gtest tests? >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8156681 >>>>> webrev: http://cr.openjdk.java.net/~iignatyev/8156681/webrev.00/ >>>>> >>>>> Thanks, >>>>> ? Igor >>>>> >>> > From ivankrylov.java at gmail.com Tue May 17 15:06:23 2016 From: ivankrylov.java at gmail.com (Ivan Krylov) Date: Tue, 17 May 2016 18:06:23 +0300 Subject: JEP 230 Status In-Reply-To: References: Message-ID: Hi Stuart, Just for the reference, 2 months ago Mikael wrote about why JEP-230 was dropped from Java 9. http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-March/003879.html Thanks, Ivan On 17/05/2016 12:50, Stuart Monteith wrote: > Hellol, > It appears that "JEP 230: Microbenchmark Suite"[1] is currently > dormant. However, there has been some activity in terms of the JIRA > task [2] and Mikael Vidsted has been assigned as the owner. > > I'm sure I won't be the only interested to know the intention behind > JEP 230, and subsequently to contribute benchmarks to it. Is there an > expected time frame for when the JEP will be completed? > > > Thanks, > Stuart > > > [1] http://openjdk.java.net/jeps/230 > [2] https://bugs.openjdk.java.net/browse/JDK-8050952 From alexhenrie24 at gmail.com Tue May 17 18:17:35 2016 From: alexhenrie24 at gmail.com (Alex Henrie) Date: Tue, 17 May 2016 12:17:35 -0600 Subject: [PATCH] 8156036: Enable building of arm targets in default JPRT testset Message-ID: <23d5fbcd76fcea2b8c8a.1463509055@wolverine> # HG changeset patch # User erikj # Date 1463501898 -7200 # Tue May 17 18:18:18 2016 +0200 # Node ID 23d5fbcd76fcea2b8c8a35d046495ed2dea06a6d # Parent 21f1aa535d11d9a38409c30ffbd01f8acf9f645a 8156036: Enable building of arm targets in default JPRT testset Reviewed-by: tbell, chegar diff --git a/make/jprt.properties b/make/jprt.properties --- a/make/jprt.properties +++ b/make/jprt.properties @@ -189,24 +189,25 @@ jprt.build.configure.args= \ # # Build targets and options (default/jdk) # # The default build flavors my.build.flavors.default=fastdebug,product # Standard list of jprt build targets for this source tree -my.build.targets.default= \ - solaris_sparcv9_5.11-{product|fastdebug}, \ - solaris_x64_5.11-{product|fastdebug}, \ - linux_i586_3.8-{product|fastdebug}, \ - linux_x64_3.8-{product|fastdebug}, \ - macosx_x64_10.9-{product|fastdebug}, \ - windows_i586_6.3-{product|fastdebug}, \ - windows_x64_6.3-{product|fastdebug} +my.build.targets.default= \ + solaris_sparcv9_5.11-{product|fastdebug}, \ + solaris_x64_5.11-{product|fastdebug}, \ + linux_i586_3.8-{product|fastdebug}, \ + linux_x64_3.8-{product|fastdebug}, \ + macosx_x64_10.9-{product|fastdebug}, \ + windows_i586_6.3-{product|fastdebug}, \ + windows_x64_6.3-{product|fastdebug}, \ + ${my.additional.build.targets.default} # Test target list (no fastdebug & limited c2 testing) my.test.target.set= \ solaris_sparcv9_5.11-product-c2-TESTNAME, \ solaris_x64_5.11-product-c2-TESTNAME, \ linux_i586_3.8-product-{c1|c2}-TESTNAME, \ linux_x64_3.8-product-c2-TESTNAME, \ macosx_x64_10.9-product-c2-TESTNAME, \ From alexhenrie24 at gmail.com Tue May 17 18:19:24 2016 From: alexhenrie24 at gmail.com (Alex Henrie) Date: Tue, 17 May 2016 12:19:24 -0600 Subject: [PATCH] 8156036: Enable building of arm targets in default JPRT testset In-Reply-To: <23d5fbcd76fcea2b8c8a.1463509055@wolverine> References: <23d5fbcd76fcea2b8c8a.1463509055@wolverine> Message-ID: Wrong patch, sorry...I ran `hg email tip` from the wrong directory and it didn't warn me. -Alex From alexhenrie24 at gmail.com Tue May 17 18:19:34 2016 From: alexhenrie24 at gmail.com (Alex Henrie) Date: Tue, 17 May 2016 12:19:34 -0600 Subject: [PATCH] 8152856: Use (~0u) instead of (-1) when left-shifting Message-ID: # HG changeset patch # User ahenrie # Date 1463507859 21600 # Tue May 17 11:57:39 2016 -0600 # Node ID b0c4b67a1a4789171f30a1986110bbf20345f060 # Parent 1691ffd6dab4901f2ecedbab11c7f9b2b8719919 8152856: Use (~0u) instead of (-1) when left-shifting diff --git a/src/share/vm/code/dependencies.hpp b/src/share/vm/code/dependencies.hpp --- a/src/share/vm/code/dependencies.hpp +++ b/src/share/vm/code/dependencies.hpp @@ -163,17 +163,17 @@ class Dependencies: public ResourceObj { call_site_target_value, TYPE_LIMIT }; enum { LG2_TYPE_LIMIT = 4, // assert(TYPE_LIMIT <= (1< References: <5734C19B.5030303@oracle.com> <1463136901.2392.5.camel@oracle.com> Message-ID: <573B6E3F.2080301@oracle.com> I changed the log level to debug and added created a test. Webrev: http://cr.openjdk.java.net/~jprovino/8153582/webrev.01 thanks. joe On 5/13/2016 6:55 AM, Thomas Schatzl wrote: > Hi, > > On Thu, 2016-05-12 at 13:47 -0400, Joseph Provino wrote: >> Please review this very small change to log ConcGCThreads >> and ParallelGCThreads correctly. >> >> Webrev: http://cr.openjdk.java.net/~jprovino/8153582/webrev.00 >> >> CR: JDK-8153582Logging of ConcGCThreads is done too early >> >> >> Messages look like below. >> >> java -Xlog:gc=trace -XX:+PrintFlagsFinal -version >> >> [0.002s][trace][gc] MarkStackSize: 4096k MarkStackSizeMax: 16384k >> [0.038s][trace][gc] ConcGCThreads: 5 >> [0.039s][trace][gc] ParallelGCThreads: 18 >> [0.056s][info ][gc] Using G1 >> >> java -Xlog:gc=trace -XX:+PrintFlagsFinal -XX:+UseConcMarkSweepGC >> -version >> >> [0.002s][trace][gc] MarkStackSize: 4096k MarkStackSizeMax: 524288k >> [1.001s][trace][gc] ConcGCThreads: 5 >> [1.001s][trace][gc] ParallelGCThreads: 18 >> [1.015s][info ][gc] Using Concurrent Mark Sweep > - not sure if this is "trace" level worthy, maybe debug level would > be more appropriate. Not opposed to using trace level, just questioning > the reason for using trace level here. > It does not look too detailed yet. > > - could you please use the latest webrev script available on http://o > penjdk.java.net/guide/webrevHelp.html in the future? The added links to > the next/pref changed file are a great addition. > > - please add a small test case that checks the output. > > Thanks, > THomas > From derek.white at oracle.com Tue May 17 20:43:34 2016 From: derek.white at oracle.com (Derek White) Date: Tue, 17 May 2016 16:43:34 -0400 Subject: RFR (XS) JDK-8153582 Logging of ConcGCThreads is done too early In-Reply-To: <573B6E3F.2080301@oracle.com> References: <5734C19B.5030303@oracle.com> <1463136901.2392.5.camel@oracle.com> <573B6E3F.2080301@oracle.com> Message-ID: <9834b0c8-9557-42da-a255-30f6a50d1664@oracle.com> Hi Joe, Looks good! - Derek On 5/17/16 3:17 PM, Joseph Provino wrote: > I changed the log level to debug and added created a test. > > Webrev: http://cr.openjdk.java.net/~jprovino/8153582/webrev.01 > > thanks. > > joe > > On 5/13/2016 6:55 AM, Thomas Schatzl wrote: >> Hi, >> >> On Thu, 2016-05-12 at 13:47 -0400, Joseph Provino wrote: >>> Please review this very small change to log ConcGCThreads >>> and ParallelGCThreads correctly. >>> >>> Webrev: http://cr.openjdk.java.net/~jprovino/8153582/webrev.00 >>> >>> CR: JDK-8153582Logging of ConcGCThreads is done too early >>> >>> >>> Messages look like below. >>> >>> java -Xlog:gc=trace -XX:+PrintFlagsFinal -version >>> >>> [0.002s][trace][gc] MarkStackSize: 4096k MarkStackSizeMax: 16384k >>> [0.038s][trace][gc] ConcGCThreads: 5 >>> [0.039s][trace][gc] ParallelGCThreads: 18 >>> [0.056s][info ][gc] Using G1 >>> >>> java -Xlog:gc=trace -XX:+PrintFlagsFinal -XX:+UseConcMarkSweepGC >>> -version >>> >>> [0.002s][trace][gc] MarkStackSize: 4096k MarkStackSizeMax: 524288k >>> [1.001s][trace][gc] ConcGCThreads: 5 >>> [1.001s][trace][gc] ParallelGCThreads: 18 >>> [1.015s][info ][gc] Using Concurrent Mark Sweep >> - not sure if this is "trace" level worthy, maybe debug level would >> be more appropriate. Not opposed to using trace level, just questioning >> the reason for using trace level here. >> It does not look too detailed yet. >> >> - could you please use the latest webrev script available on http://o >> penjdk.java.net/guide/webrevHelp.html in the future? The added links to >> the next/pref changed file are a great addition. >> >> - please add a small test case that checks the output. >> >> Thanks, >> THomas >> > From joseph.provino at oracle.com Wed May 18 01:38:06 2016 From: joseph.provino at oracle.com (Joseph Provino) Date: Tue, 17 May 2016 21:38:06 -0400 Subject: RFR (XS) JDK-8153582 Logging of ConcGCThreads is done too early In-Reply-To: <9834b0c8-9557-42da-a255-30f6a50d1664@oracle.com> References: <5734C19B.5030303@oracle.com> <1463136901.2392.5.camel@oracle.com> <573B6E3F.2080301@oracle.com> <9834b0c8-9557-42da-a255-30f6a50d1664@oracle.com> Message-ID: <573BC77E.2020609@oracle.com> Derek, thanks! joe On 5/17/2016 4:43 PM, Derek White wrote: > Hi Joe, > > Looks good! > > - Derek > > On 5/17/16 3:17 PM, Joseph Provino wrote: >> I changed the log level to debug and added created a test. >> >> Webrev: http://cr.openjdk.java.net/~jprovino/8153582/webrev.01 >> >> thanks. >> >> joe >> >> On 5/13/2016 6:55 AM, Thomas Schatzl wrote: >>> Hi, >>> >>> On Thu, 2016-05-12 at 13:47 -0400, Joseph Provino wrote: >>>> Please review this very small change to log ConcGCThreads >>>> and ParallelGCThreads correctly. >>>> >>>> Webrev: http://cr.openjdk.java.net/~jprovino/8153582/webrev.00 >>>> >>>> CR: JDK-8153582Logging of ConcGCThreads is done too early >>>> >>>> >>>> Messages look like below. >>>> >>>> java -Xlog:gc=trace -XX:+PrintFlagsFinal -version >>>> >>>> [0.002s][trace][gc] MarkStackSize: 4096k MarkStackSizeMax: 16384k >>>> [0.038s][trace][gc] ConcGCThreads: 5 >>>> [0.039s][trace][gc] ParallelGCThreads: 18 >>>> [0.056s][info ][gc] Using G1 >>>> >>>> java -Xlog:gc=trace -XX:+PrintFlagsFinal -XX:+UseConcMarkSweepGC >>>> -version >>>> >>>> [0.002s][trace][gc] MarkStackSize: 4096k MarkStackSizeMax: 524288k >>>> [1.001s][trace][gc] ConcGCThreads: 5 >>>> [1.001s][trace][gc] ParallelGCThreads: 18 >>>> [1.015s][info ][gc] Using Concurrent Mark Sweep >>> - not sure if this is "trace" level worthy, maybe debug level would >>> be more appropriate. Not opposed to using trace level, just questioning >>> the reason for using trace level here. >>> It does not look too detailed yet. >>> >>> - could you please use the latest webrev script available on >>> http://o >>> penjdk.java.net/guide/webrevHelp.html in the future? The added links to >>> the next/pref changed file are a great addition. >>> >>> - please add a small test case that checks the output. >>> >>> Thanks, >>> THomas >>> >> > From thomas.schatzl at oracle.com Wed May 18 08:09:55 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 18 May 2016 10:09:55 +0200 Subject: RFR (XS) JDK-8153582 Logging of ConcGCThreads is done too early In-Reply-To: <573B6E3F.2080301@oracle.com> References: <5734C19B.5030303@oracle.com> <1463136901.2392.5.camel@oracle.com> <573B6E3F.2080301@oracle.com> Message-ID: <1463558995.2431.16.camel@oracle.com> Hi Joe, On Tue, 2016-05-17 at 15:17 -0400, Joseph Provino wrote: > I changed the log level to debug and added created a test. > > Webrev:??http://cr.openjdk.java.net/~jprovino/8153582/webrev.01 > ? in the test, please limit the allowable GCs to CMS and G1. I do not think it makes sense to call the test with other GCs. Like @requires vm.gc=="ConcMarkSweep" | vm.gc=="G1" | vm.gc=="null" I do not need a re-review for this change. Thanks, ? Thomas From thomas.schatzl at oracle.com Wed May 18 08:12:39 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 18 May 2016 10:12:39 +0200 Subject: RFR (XS) JDK-8153582 Logging of ConcGCThreads is done too early In-Reply-To: <1463558995.2431.16.camel@oracle.com> References: <5734C19B.5030303@oracle.com> <1463136901.2392.5.camel@oracle.com> <573B6E3F.2080301@oracle.com> <1463558995.2431.16.camel@oracle.com> Message-ID: <1463559159.2431.17.camel@oracle.com> Hi again, On Wed, 2016-05-18 at 10:09 +0200, Thomas Schatzl wrote: > Hi Joe, > > On Tue, 2016-05-17 at 15:17 -0400, Joseph Provino wrote: > > > > I changed the log level to debug and added created a test. > > > > Webrev:??http://cr.openjdk.java.net/~jprovino/8153582/webrev.01 > > > ? in the test, please limit the allowable GCs to CMS and G1. I do not > think it makes sense to call the test with other GCs. > > Like > > @requires vm.gc=="ConcMarkSweep" | vm.gc=="G1" | vm.gc=="null" Also the copyright date should be 2016 only. > I do not need a re-review for this change. Still applies. Thanks, ? Thomas From george.triantafillou at oracle.com Wed May 18 10:48:35 2016 From: george.triantafillou at oracle.com (George Triantafillou) Date: Wed, 18 May 2016 06:48:35 -0400 Subject: RFR (XS) JDK-8153582 Logging of ConcGCThreads is done too early In-Reply-To: <573B6E3F.2080301@oracle.com> References: <5734C19B.5030303@oracle.com> <1463136901.2392.5.camel@oracle.com> <573B6E3F.2080301@oracle.com> Message-ID: Joe, Looks good. -George On 5/17/2016 3:17 PM, Joseph Provino wrote: > I changed the log level to debug and added created a test. > > Webrev: http://cr.openjdk.java.net/~jprovino/8153582/webrev.01 > > thanks. > > joe > > On 5/13/2016 6:55 AM, Thomas Schatzl wrote: >> Hi, >> >> On Thu, 2016-05-12 at 13:47 -0400, Joseph Provino wrote: >>> Please review this very small change to log ConcGCThreads >>> and ParallelGCThreads correctly. >>> >>> Webrev: http://cr.openjdk.java.net/~jprovino/8153582/webrev.00 >>> >>> CR: JDK-8153582Logging of ConcGCThreads is done too early >>> >>> >>> Messages look like below. >>> >>> java -Xlog:gc=trace -XX:+PrintFlagsFinal -version >>> >>> [0.002s][trace][gc] MarkStackSize: 4096k MarkStackSizeMax: 16384k >>> [0.038s][trace][gc] ConcGCThreads: 5 >>> [0.039s][trace][gc] ParallelGCThreads: 18 >>> [0.056s][info ][gc] Using G1 >>> >>> java -Xlog:gc=trace -XX:+PrintFlagsFinal -XX:+UseConcMarkSweepGC >>> -version >>> >>> [0.002s][trace][gc] MarkStackSize: 4096k MarkStackSizeMax: 524288k >>> [1.001s][trace][gc] ConcGCThreads: 5 >>> [1.001s][trace][gc] ParallelGCThreads: 18 >>> [1.015s][info ][gc] Using Concurrent Mark Sweep >> - not sure if this is "trace" level worthy, maybe debug level would >> be more appropriate. Not opposed to using trace level, just questioning >> the reason for using trace level here. >> It does not look too detailed yet. >> >> - could you please use the latest webrev script available on http://o >> penjdk.java.net/guide/webrevHelp.html in the future? The added links to >> the next/pref changed file are a great addition. >> >> - please add a small test case that checks the output. >> >> Thanks, >> THomas >> > From dmitry.fazunenko at oracle.com Wed May 18 11:33:39 2016 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Wed, 18 May 2016 14:33:39 +0300 Subject: RFR (XS) JDK-8153582 Logging of ConcGCThreads is done too early In-Reply-To: <1463559159.2431.17.camel@oracle.com> References: <5734C19B.5030303@oracle.com> <1463136901.2392.5.camel@oracle.com> <573B6E3F.2080301@oracle.com> <1463558995.2431.16.camel@oracle.com> <1463559159.2431.17.camel@oracle.com> Message-ID: <85dae564-874b-50da-95f5-21a1306818ad@oracle.com> Hi Joe, > @requires vm.gc=="ConcMarkSweep" | vm.gc=="G1" | vm.gc=="null" Will not help unfortunately :( This test will fail on minimal VM where serial is always selected You need: @requires vm.flavor != "minimal" The way you spawn a new VM ignores external flags: pb = ProcessTools.createJavaProcessBuilder("-XX:+" + gcFlag, "-Xlog:gc=debug", "-version"); It's recommended to NOT ignore external flags: pb = ProcessTools.createJavaProcessBuilder(*true, *"-XX:+" + gcFlag, "-Xlog:gc=debug", "-version"); But in this case the test will not work if either G1 or CMS is set explicitly: verifyNumberOfConcurrentAndParallelGCThreads(null); verifyNumberOfConcurrentAndParallelGCThreads("UseG1GC"); verifyNumberOfConcurrentAndParallelGCThreads("UseConcMarkSweepGC"); either second or third case will fail because of collector conflict. To avoid collector conflicts you need: @requires vm.gc=="null" But in this case, verifyNumberOfConcurrentAndParallelGCThreads(null); will fail if ergonomics will select Serial or Parallel... What I suggest add: @requires vm.flavor != "minimal" @requires vm.gc=="null" get rid of the null case 40 verifyNumberOfConcurrentAndParallelGCThreads(null); 41 42 verifyNumberOfConcurrentAndParallelGCThreads("UseG1GC"); 43 44 verifyNumberOfConcurrentAndParallelGCThreads("UseConcMarkSweepGC"); -> verifyNumberOfConcurrentAndParallelGCThreads("UseG1GC"); verifyNumberOfConcurrentAndParallelGCThreads("UseConcMarkSweepGC"); don't ignore external flags: 50 if (gcFlag != null) { 51 pb = ProcessTools.createJavaProcessBuilder("-XX:+" + gcFlag, "-Xlog:gc=debug", "-version"); 52 } else { 53 pb = ProcessTools.createJavaProcessBuilder("-Xlog:gc=debug", "-version"); 54 } --> pb = ProcessTools.createJavaProcessBuilder(*true*, "-XX:+" + gcFlag, "-Xlog:gc=debug", "-version"); Thanks, Dima On 18.05.2016 11:12, Thomas Schatzl wrote: > Hi again, > > On Wed, 2016-05-18 at 10:09 +0200, Thomas Schatzl wrote: >> Hi Joe, >> >> On Tue, 2016-05-17 at 15:17 -0400, Joseph Provino wrote: >>> I changed the log level to debug and added created a test. >>> >>> Webrev: http://cr.openjdk.java.net/~jprovino/8153582/webrev.01 >>> >> in the test, please limit the allowable GCs to CMS and G1. I do not >> think it makes sense to call the test with other GCs. >> >> Like >> >> @requires vm.gc=="ConcMarkSweep" | vm.gc=="G1" | vm.gc=="null" > Also the copyright date should be 2016 only. > >> I do not need a re-review for this change. > Still applies. > > Thanks, > Thomas From joseph.provino at oracle.com Wed May 18 13:09:37 2016 From: joseph.provino at oracle.com (Joseph Provino) Date: Wed, 18 May 2016 09:09:37 -0400 Subject: RFR (XS) JDK-8153582 Logging of ConcGCThreads is done too early In-Reply-To: <85dae564-874b-50da-95f5-21a1306818ad@oracle.com> References: <5734C19B.5030303@oracle.com> <1463136901.2392.5.camel@oracle.com> <573B6E3F.2080301@oracle.com> <1463558995.2431.16.camel@oracle.com> <1463559159.2431.17.camel@oracle.com> <85dae564-874b-50da-95f5-21a1306818ad@oracle.com> Message-ID: <573C6991.3070804@oracle.com> On 5/18/2016 7:33 AM, Dmitry Fazunenko wrote: > Hi Joe, > > > @requires vm.gc=="ConcMarkSweep" | vm.gc=="G1" | vm.gc=="null" > > Will not help unfortunately :( > > This test will fail on minimal VM where serial is always selected > You need: > @requires vm.flavor != "minimal" > > > The way you spawn a new VM ignores external flags: > > pb = ProcessTools.createJavaProcessBuilder("-XX:+" + gcFlag, "-Xlog:gc=debug", "-version"); > > It's recommended to NOT ignore external flags: > pb = ProcessTools.createJavaProcessBuilder(*true, *"-XX:+" + gcFlag, "-Xlog:gc=debug", "-version"); > > But in this case the test will not work if either G1 or CMS is set explicitly: > verifyNumberOfConcurrentAndParallelGCThreads(null); > verifyNumberOfConcurrentAndParallelGCThreads("UseG1GC"); > verifyNumberOfConcurrentAndParallelGCThreads("UseConcMarkSweepGC"); > either second or third case will fail because of collector conflict. > To avoid collector conflicts you need: > @requires vm.gc=="null" > But in this case, > verifyNumberOfConcurrentAndParallelGCThreads(null); > will fail if ergonomics will select Serial or Parallel... > > > What I suggest > > add: > @requires vm.flavor != "minimal" > @requires vm.gc=="null" > > get rid of the null case > 40 verifyNumberOfConcurrentAndParallelGCThreads(null); > 41 > 42 verifyNumberOfConcurrentAndParallelGCThreads("UseG1GC"); > 43 > 44 verifyNumberOfConcurrentAndParallelGCThreads("UseConcMarkSweepGC"); > > -> > verifyNumberOfConcurrentAndParallelGCThreads("UseG1GC"); > verifyNumberOfConcurrentAndParallelGCThreads("UseConcMarkSweepGC"); > > > don't ignore external flags: > 50 if (gcFlag != null) { > 51 pb = ProcessTools.createJavaProcessBuilder("-XX:+" + gcFlag, "-Xlog:gc=debug", "-version"); > 52 } else { > 53 pb = ProcessTools.createJavaProcessBuilder("-Xlog:gc=debug", "-version"); > 54 } > --> > pb = ProcessTools.createJavaProcessBuilder(*true*, "-XX:+" + gcFlag, "-Xlog:gc=debug", "-version"); If I understand, this will just test with -XX:+UseG1GC and -XX:+UseConcMarkSweepGC but will not test with default GC which is also G1. Thanks. joe > > Thanks, > Dima > > > On 18.05.2016 11:12, Thomas Schatzl wrote: >> Hi again, >> >> On Wed, 2016-05-18 at 10:09 +0200, Thomas Schatzl wrote: >>> Hi Joe, >>> >>> On Tue, 2016-05-17 at 15:17 -0400, Joseph Provino wrote: >>>> I changed the log level to debug and added created a test. >>>> >>>> Webrev:http://cr.openjdk.java.net/~jprovino/8153582/webrev.01 >>>> >>> in the test, please limit the allowable GCs to CMS and G1. I do not >>> think it makes sense to call the test with other GCs. >>> >>> Like >>> >>> @requires vm.gc=="ConcMarkSweep" | vm.gc=="G1" | vm.gc=="null" >> Also the copyright date should be 2016 only. >> >>> I do not need a re-review for this change. >> Still applies. >> >> Thanks, >> Thomas > From joseph.provino at oracle.com Wed May 18 14:24:00 2016 From: joseph.provino at oracle.com (Joseph Provino) Date: Wed, 18 May 2016 10:24:00 -0400 Subject: RFR (XS) JDK-8153582 Logging of ConcGCThreads is done too early In-Reply-To: <85dae564-874b-50da-95f5-21a1306818ad@oracle.com> References: <5734C19B.5030303@oracle.com> <1463136901.2392.5.camel@oracle.com> <573B6E3F.2080301@oracle.com> <1463558995.2431.16.camel@oracle.com> <1463559159.2431.17.camel@oracle.com> <85dae564-874b-50da-95f5-21a1306818ad@oracle.com> Message-ID: <573C7B00.703@oracle.com> Latest webrev with Dima's suggestions: http://cr.openjdk.java.net/~jprovino/8153582/webrev.02 joe On 5/18/2016 7:33 AM, Dmitry Fazunenko wrote: > Hi Joe, > > > @requires vm.gc=="ConcMarkSweep" | vm.gc=="G1" | vm.gc=="null" > > Will not help unfortunately :( > > This test will fail on minimal VM where serial is always selected > You need: > @requires vm.flavor != "minimal" > > > The way you spawn a new VM ignores external flags: > > pb = ProcessTools.createJavaProcessBuilder("-XX:+" + gcFlag, "-Xlog:gc=debug", "-version"); > > It's recommended to NOT ignore external flags: > pb = ProcessTools.createJavaProcessBuilder(*true, *"-XX:+" + gcFlag, "-Xlog:gc=debug", "-version"); > > But in this case the test will not work if either G1 or CMS is set explicitly: > verifyNumberOfConcurrentAndParallelGCThreads(null); > verifyNumberOfConcurrentAndParallelGCThreads("UseG1GC"); > verifyNumberOfConcurrentAndParallelGCThreads("UseConcMarkSweepGC"); > either second or third case will fail because of collector conflict. > To avoid collector conflicts you need: > @requires vm.gc=="null" > But in this case, > verifyNumberOfConcurrentAndParallelGCThreads(null); > will fail if ergonomics will select Serial or Parallel... > > > What I suggest > > add: > @requires vm.flavor != "minimal" > @requires vm.gc=="null" > > get rid of the null case > 40 verifyNumberOfConcurrentAndParallelGCThreads(null); > 41 > 42 verifyNumberOfConcurrentAndParallelGCThreads("UseG1GC"); > 43 > 44 verifyNumberOfConcurrentAndParallelGCThreads("UseConcMarkSweepGC"); > > -> > verifyNumberOfConcurrentAndParallelGCThreads("UseG1GC"); > verifyNumberOfConcurrentAndParallelGCThreads("UseConcMarkSweepGC"); > > > don't ignore external flags: > 50 if (gcFlag != null) { > 51 pb = ProcessTools.createJavaProcessBuilder("-XX:+" + gcFlag, "-Xlog:gc=debug", "-version"); > 52 } else { > 53 pb = ProcessTools.createJavaProcessBuilder("-Xlog:gc=debug", "-version"); > 54 } > --> > pb = ProcessTools.createJavaProcessBuilder(*true*, "-XX:+" + gcFlag, "-Xlog:gc=debug", "-version"); > > Thanks, > Dima > > > On 18.05.2016 11:12, Thomas Schatzl wrote: >> Hi again, >> >> On Wed, 2016-05-18 at 10:09 +0200, Thomas Schatzl wrote: >>> Hi Joe, >>> >>> On Tue, 2016-05-17 at 15:17 -0400, Joseph Provino wrote: >>>> I changed the log level to debug and added created a test. >>>> >>>> Webrev:http://cr.openjdk.java.net/~jprovino/8153582/webrev.01 >>>> >>> in the test, please limit the allowable GCs to CMS and G1. I do not >>> think it makes sense to call the test with other GCs. >>> >>> Like >>> >>> @requires vm.gc=="ConcMarkSweep" | vm.gc=="G1" | vm.gc=="null" >> Also the copyright date should be 2016 only. >> >>> I do not need a re-review for this change. >> Still applies. >> >> Thanks, >> Thomas > From dmitry.fazunenko at oracle.com Wed May 18 14:41:01 2016 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Wed, 18 May 2016 17:41:01 +0300 Subject: RFR (XS) JDK-8153582 Logging of ConcGCThreads is done too early In-Reply-To: <573C7B00.703@oracle.com> References: <5734C19B.5030303@oracle.com> <1463136901.2392.5.camel@oracle.com> <573B6E3F.2080301@oracle.com> <1463558995.2431.16.camel@oracle.com> <1463559159.2431.17.camel@oracle.com> <85dae564-874b-50da-95f5-21a1306818ad@oracle.com> <573C7B00.703@oracle.com> Message-ID: <0a5d9e0e-819b-b051-fc5b-f3524566f925@oracle.com> On 18.05.2016 17:24, Joseph Provino wrote: > Latest webrev with Dima's suggestions: > > http://cr.openjdk.java.net/~jprovino/8153582/webrev.02 Looks good! Thanks Dima > > joe > > On 5/18/2016 7:33 AM, Dmitry Fazunenko wrote: >> Hi Joe, >> >> > @requires vm.gc=="ConcMarkSweep" | vm.gc=="G1" | vm.gc=="null" >> >> Will not help unfortunately :( >> >> This test will fail on minimal VM where serial is always selected >> You need: >> @requires vm.flavor != "minimal" >> >> >> The way you spawn a new VM ignores external flags: >> >> pb = ProcessTools.createJavaProcessBuilder("-XX:+" + gcFlag, >> "-Xlog:gc=debug", "-version"); >> >> It's recommended to NOT ignore external flags: >> pb = ProcessTools.createJavaProcessBuilder(*true, *"-XX:+" + >> gcFlag, "-Xlog:gc=debug", "-version"); >> >> But in this case the test will not work if either G1 or CMS is set >> explicitly: >> verifyNumberOfConcurrentAndParallelGCThreads(null); >> verifyNumberOfConcurrentAndParallelGCThreads("UseG1GC"); >> verifyNumberOfConcurrentAndParallelGCThreads("UseConcMarkSweepGC"); >> either second or third case will fail because of collector conflict. >> To avoid collector conflicts you need: >> @requires vm.gc=="null" >> But in this case, >> verifyNumberOfConcurrentAndParallelGCThreads(null); >> will fail if ergonomics will select Serial or Parallel... >> >> >> What I suggest >> >> add: >> @requires vm.flavor != "minimal" >> @requires vm.gc=="null" >> >> get rid of the null case >> 40 verifyNumberOfConcurrentAndParallelGCThreads(null); >> 41 >> 42 verifyNumberOfConcurrentAndParallelGCThreads("UseG1GC"); >> 43 >> 44 >> verifyNumberOfConcurrentAndParallelGCThreads("UseConcMarkSweepGC"); >> >> -> >> verifyNumberOfConcurrentAndParallelGCThreads("UseG1GC"); >> verifyNumberOfConcurrentAndParallelGCThreads("UseConcMarkSweepGC"); >> >> >> don't ignore external flags: >> 50 if (gcFlag != null) { >> 51 pb = ProcessTools.createJavaProcessBuilder("-XX:+" >> + gcFlag, "-Xlog:gc=debug", "-version"); >> 52 } else { >> 53 pb = >> ProcessTools.createJavaProcessBuilder("-Xlog:gc=debug", "-version"); >> 54 } >> --> >> pb = ProcessTools.createJavaProcessBuilder(*true*, >> "-XX:+" + gcFlag, "-Xlog:gc=debug", "-version"); >> Thanks, >> Dima >> >> >> On 18.05.2016 11:12, Thomas Schatzl wrote: >>> Hi again, >>> >>> On Wed, 2016-05-18 at 10:09 +0200, Thomas Schatzl wrote: >>>> Hi Joe, >>>> >>>> On Tue, 2016-05-17 at 15:17 -0400, Joseph Provino wrote: >>>>> I changed the log level to debug and added created a test. >>>>> >>>>> Webrev:http://cr.openjdk.java.net/~jprovino/8153582/webrev.01 >>>>> >>>> in the test, please limit the allowable GCs to CMS and G1. I do not >>>> think it makes sense to call the test with other GCs. >>>> >>>> Like >>>> >>>> @requires vm.gc=="ConcMarkSweep" | vm.gc=="G1" | vm.gc=="null" >>> Also the copyright date should be 2016 only. >>> >>>> I do not need a re-review for this change. >>> Still applies. >>> >>> Thanks, >>> Thomas >> > From michail.chernov at oracle.com Wed May 18 14:59:35 2016 From: michail.chernov at oracle.com (Michail Chernov) Date: Wed, 18 May 2016 07:59:35 -0700 (PDT) Subject: RFR (XS) JDK-8153582 Logging of ConcGCThreads is done too early Message-ID: <38204e90-af00-412c-8ad3-ddc0426aaef4@default> Hi Joe, Looks good to me. Could you please update the copyright year in test/gc/TestNumberOfConcurrentAndParallelGCThreads.java. No need additional webrev for this. Thanks Michail ----- Original Message ----- From: joseph.provino at oracle.com To: hotspot-dev at openjdk.java.net Sent: Wednesday, May 18, 2016 5:24:23 PM GMT +03:00 Iraq Subject: Re: RFR (XS) JDK-8153582 Logging of ConcGCThreads is done too early Latest webrev with Dima's suggestions: http://cr.openjdk.java.net/~jprovino/8153582/webrev.02 joe From stefan.johansson at oracle.com Wed May 18 15:02:03 2016 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Wed, 18 May 2016 17:02:03 +0200 Subject: RFR: 8157243: JMap heap test fail when used with external heap Message-ID: <573C83EB.5090804@oracle.com> Hi, Please review this small change for: https://bugs.openjdk.java.net/browse/JDK-8157243 Webrev: http://cr.openjdk.java.net/~sjohanss/8157243/hotspot.00/ Summary: This change is needed to fix a failing test when a non-standard heap is used. The change adds a way to declare such heaps. Since this was considered an enhancement rather then a bug-fix, I'm currently waiting for approval to push this even though FC has passed. Testing: * JPRT * RBT Thanks, Stefan From erik.helin at oracle.com Thu May 19 10:44:08 2016 From: erik.helin at oracle.com (Erik Helin) Date: Thu, 19 May 2016 12:44:08 +0200 Subject: RFR: 8157325: gtest tests are not excluded for minimal builds Message-ID: <20160519104408.GA22743@ehelin.jrpg.bea.com> Hi all, this small patch ensures that the Makefiles correctly excludes gtest unit tests for a minimal build. Right now, if you add a test to e.g. hotspot/native/gc/g1, the test will be included in a minimal build, which will fail. Thanks to Erik Joelsson for helping out with this patch! Bug: https://bugs.openjdk.java.net/browse/JDK-8157325 Webrev: http://cr.openjdk.java.net/~ehelin/8157325/webrev.00/ Testing: - JPRT (with test in hotspot/native/gc/g1) - Locally on Linux x86-64, both with and without a test in hotspot/native/gc/g1, both minimal and full build Thanks, Erik From erik.joelsson at oracle.com Thu May 19 11:21:23 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 19 May 2016 13:21:23 +0200 Subject: RFR: 8157325: gtest tests are not excluded for minimal builds In-Reply-To: <20160519104408.GA22743@ehelin.jrpg.bea.com> References: <20160519104408.GA22743@ehelin.jrpg.bea.com> Message-ID: <573DA1B3.6020209@oracle.com> Naturally, I think it looks good. It might need some further tweaking down the line, but this should work for now. /Erik On 2016-05-19 12:44, Erik Helin wrote: > Hi all, > > this small patch ensures that the Makefiles correctly excludes gtest > unit tests for a minimal build. Right now, if you add a test to e.g. > hotspot/native/gc/g1, the test will be included in a minimal build, > which will fail. > > Thanks to Erik Joelsson for helping out with this patch! > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8157325 > > Webrev: > http://cr.openjdk.java.net/~ehelin/8157325/webrev.00/ > > Testing: > - JPRT (with test in hotspot/native/gc/g1) > - Locally on Linux x86-64, both with and without a test in > hotspot/native/gc/g1, both minimal and full build > > Thanks, > Erik From david.holmes at oracle.com Thu May 19 12:03:11 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 19 May 2016 22:03:11 +1000 Subject: RFR: 8157325: gtest tests are not excluded for minimal builds In-Reply-To: <20160519104408.GA22743@ehelin.jrpg.bea.com> References: <20160519104408.GA22743@ehelin.jrpg.bea.com> Message-ID: <3fec9522-c99e-87d4-9617-6dd21a703e29@oracle.com> Sorry Erik but I don't follow what this patch is doing - not familiar with how gtest actually works. Where does the minimal build come into what has been changed? This seems to be changing how GTEST_LIBJVM is built, not when it is built ?? Thanks, David On 19/05/2016 8:44 PM, Erik Helin wrote: > Hi all, > > this small patch ensures that the Makefiles correctly excludes gtest > unit tests for a minimal build. Right now, if you add a test to e.g. > hotspot/native/gc/g1, the test will be included in a minimal build, > which will fail. > > Thanks to Erik Joelsson for helping out with this patch! > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8157325 > > Webrev: > http://cr.openjdk.java.net/~ehelin/8157325/webrev.00/ > > Testing: > - JPRT (with test in hotspot/native/gc/g1) > - Locally on Linux x86-64, both with and without a test in > hotspot/native/gc/g1, both minimal and full build > > Thanks, > Erik > From erik.joelsson at oracle.com Thu May 19 12:18:46 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 19 May 2016 14:18:46 +0200 Subject: RFR: 8157325: gtest tests are not excluded for minimal builds In-Reply-To: <3fec9522-c99e-87d4-9617-6dd21a703e29@oracle.com> References: <20160519104408.GA22743@ehelin.jrpg.bea.com> <3fec9522-c99e-87d4-9617-6dd21a703e29@oracle.com> Message-ID: <573DAF26.2030107@oracle.com> Hello, I will try to explain. The GTEST_LIBJVM consists of 3 things: 1. All the objects of libjvm.so 2. The gtest framework 3. The actual test objects This patch changes how the sources for 3 are found. Before this patch, the tests were found by searching hotspot/test/native for test*.cpp, which is very similar to how jtreg native files are found. There is however a very significant difference between native jtreg tests and gtest. The native jtreg tests are each linked into a separate lib or executable, while the gtest tests are all linked together in one lib. For this reason, there really is no point in putting a .cpp file in hotspot/test/native if it's not to be included in GTEST_LIBJVM. There is also no reason to name the files test*.cpp to signal that they contain tests. The test framework does not care about the names of the objects. My understanding is that the intention with hotspot/test/native is to mimic the structure of hotspot/src/share/vm. This also means that the same exclude/include patterns should apply. This patch replaces the find and instead sets the SRC_DIR to hotspot/test/native and exclude parameters to the same as for LIBJVM. So for the minimal jvm case, we exclude gc/g1 when the jvm feature all-gcs isn't enabled, and with this patch that also applies to the unit tests. /Erik On 2016-05-19 14:03, David Holmes wrote: > Sorry Erik but I don't follow what this patch is doing - not familiar > with how gtest actually works. Where does the minimal build come into > what has been changed? This seems to be changing how GTEST_LIBJVM is > built, not when it is built ?? > > Thanks, > David > > On 19/05/2016 8:44 PM, Erik Helin wrote: >> Hi all, >> >> this small patch ensures that the Makefiles correctly excludes gtest >> unit tests for a minimal build. Right now, if you add a test to e.g. >> hotspot/native/gc/g1, the test will be included in a minimal build, >> which will fail. >> >> Thanks to Erik Joelsson for helping out with this patch! >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8157325 >> >> Webrev: >> http://cr.openjdk.java.net/~ehelin/8157325/webrev.00/ >> >> Testing: >> - JPRT (with test in hotspot/native/gc/g1) >> - Locally on Linux x86-64, both with and without a test in >> hotspot/native/gc/g1, both minimal and full build >> >> Thanks, >> Erik >> From david.holmes at oracle.com Thu May 19 12:24:36 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 19 May 2016 22:24:36 +1000 Subject: RFR: 8157325: gtest tests are not excluded for minimal builds In-Reply-To: <573DAF26.2030107@oracle.com> References: <20160519104408.GA22743@ehelin.jrpg.bea.com> <3fec9522-c99e-87d4-9617-6dd21a703e29@oracle.com> <573DAF26.2030107@oracle.com> Message-ID: <1b25ca1d-2763-4436-d117-e4f660e7f0c9@oracle.com> Thanks Erik - Erik H just explained that to me via IM. I'm afraid I'm a still on unfamiliar ground with the new hotspot build. Cheers, David On 19/05/2016 10:18 PM, Erik Joelsson wrote: > Hello, > > I will try to explain. > > The GTEST_LIBJVM consists of 3 things: > > 1. All the objects of libjvm.so > 2. The gtest framework > 3. The actual test objects > > This patch changes how the sources for 3 are found. Before this patch, > the tests were found by searching hotspot/test/native for test*.cpp, > which is very similar to how jtreg native files are found. There is > however a very significant difference between native jtreg tests and > gtest. The native jtreg tests are each linked into a separate lib or > executable, while the gtest tests are all linked together in one lib. > For this reason, there really is no point in putting a .cpp file in > hotspot/test/native if it's not to be included in GTEST_LIBJVM. There is > also no reason to name the files test*.cpp to signal that they contain > tests. The test framework does not care about the names of the objects. > > My understanding is that the intention with hotspot/test/native is to > mimic the structure of hotspot/src/share/vm. This also means that the > same exclude/include patterns should apply. This patch replaces the find > and instead sets the SRC_DIR to hotspot/test/native and exclude > parameters to the same as for LIBJVM. > > So for the minimal jvm case, we exclude gc/g1 when the jvm feature > all-gcs isn't enabled, and with this patch that also applies to the unit > tests. > > /Erik > > On 2016-05-19 14:03, David Holmes wrote: >> Sorry Erik but I don't follow what this patch is doing - not familiar >> with how gtest actually works. Where does the minimal build come into >> what has been changed? This seems to be changing how GTEST_LIBJVM is >> built, not when it is built ?? >> >> Thanks, >> David >> >> On 19/05/2016 8:44 PM, Erik Helin wrote: >>> Hi all, >>> >>> this small patch ensures that the Makefiles correctly excludes gtest >>> unit tests for a minimal build. Right now, if you add a test to e.g. >>> hotspot/native/gc/g1, the test will be included in a minimal build, >>> which will fail. >>> >>> Thanks to Erik Joelsson for helping out with this patch! >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8157325 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~ehelin/8157325/webrev.00/ >>> >>> Testing: >>> - JPRT (with test in hotspot/native/gc/g1) >>> - Locally on Linux x86-64, both with and without a test in >>> hotspot/native/gc/g1, both minimal and full build >>> >>> Thanks, >>> Erik >>> > From jesper.wilhelmsson at oracle.com Thu May 19 13:06:37 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Thu, 19 May 2016 15:06:37 +0200 Subject: RFR: 8157325: gtest tests are not excluded for minimal builds In-Reply-To: <20160519104408.GA22743@ehelin.jrpg.bea.com> References: <20160519104408.GA22743@ehelin.jrpg.bea.com> Message-ID: <8537f56d-4581-6a12-8e9b-602f05cb9f15@oracle.com> Looks good! /Jesper Den 19/5/16 kl. 12:44, skrev Erik Helin: > Hi all, > > this small patch ensures that the Makefiles correctly excludes gtest > unit tests for a minimal build. Right now, if you add a test to e.g. > hotspot/native/gc/g1, the test will be included in a minimal build, > which will fail. > > Thanks to Erik Joelsson for helping out with this patch! > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8157325 > > Webrev: > http://cr.openjdk.java.net/~ehelin/8157325/webrev.00/ > > Testing: > - JPRT (with test in hotspot/native/gc/g1) > - Locally on Linux x86-64, both with and without a test in > hotspot/native/gc/g1, both minimal and full build > > Thanks, > Erik > From aph at redhat.com Thu May 19 09:53:36 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 19 May 2016 10:53:36 +0100 Subject: enhancement of cmpxchg and copy_to_survivor for ppc64 In-Reply-To: <571577EB.1080907@oracle.com> References: <201604081054.u38As2K6014953@d19av07.sagamino.japan.ibm.com> <5711ED18.7000706@oracle.com> <201604180215.u3I2FUZi001650@d19av07.sagamino.japan.ibm.com> <571464DF.3070706@oracle.com> <5714E416.6030300@redhat.com> <571577EB.1080907@oracle.com> Message-ID: <573D8D20.3080008@redhat.com> The AArch64 code for this isn't ideal, of course. I'll submit an AArch64 version as soon as this goes in. Do I need a different bug ID? Andrew. From david.holmes at oracle.com Thu May 19 11:56:58 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 19 May 2016 21:56:58 +1000 Subject: enhancement of cmpxchg and copy_to_survivor for ppc64 In-Reply-To: <573D8D20.3080008@redhat.com> References: <201604081054.u38As2K6014953@d19av07.sagamino.japan.ibm.com> <5711ED18.7000706@oracle.com> <201604180215.u3I2FUZi001650@d19av07.sagamino.japan.ibm.com> <571464DF.3070706@oracle.com> <5714E416.6030300@redhat.com> <571577EB.1080907@oracle.com> <573D8D20.3080008@redhat.com> Message-ID: <95abf1f5-0464-0df1-7de2-c8f7c493703e@oracle.com> On 19/05/2016 7:53 PM, Andrew Haley wrote: > The AArch64 code for this isn't ideal, of course. I'll submit > an AArch64 version as soon as this goes in. Do I need a different > bug ID? There are now two bugs for this: 8155949: Support relaxed semantics in cmpxchg is adding the new API, with a relaxed implementation for PPC. 8154736: enhancement of cmpxchg and copy_to_survivor for ppc64 is for the actual GC code changes to use the relaxed cmpxchg API. I will be shepherding 8155949 through the post FC process (once we know what it is). If you can provide the Aarch64 code before that completes then it can go in with the other changes under this bug. Otherwise it will need a separate bug. Cheers, David > Andrew. > From aph at redhat.com Thu May 19 16:35:56 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 19 May 2016 17:35:56 +0100 Subject: enhancement of cmpxchg and copy_to_survivor for ppc64 In-Reply-To: <95abf1f5-0464-0df1-7de2-c8f7c493703e@oracle.com> References: <201604081054.u38As2K6014953@d19av07.sagamino.japan.ibm.com> <5711ED18.7000706@oracle.com> <201604180215.u3I2FUZi001650@d19av07.sagamino.japan.ibm.com> <571464DF.3070706@oracle.com> <5714E416.6030300@redhat.com> <571577EB.1080907@oracle.com> <573D8D20.3080008@redhat.com> <95abf1f5-0464-0df1-7de2-c8f7c493703e@oracle.com> Message-ID: <573DEB6C.2000909@redhat.com> On 05/19/2016 12:56 PM, David Holmes wrote: > I will be shepherding 8155949 through the post FC process (once we know > what it is). If you can provide the Aarch64 code before that completes > then it can go in with the other changes under this bug. Otherwise it > will need a separate bug. AArch64 code at http://cr.openjdk.java.net/~aph/8154736 Thanks, Andrew. From vladimir.kozlov at oracle.com Thu May 19 17:18:29 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 19 May 2016 10:18:29 -0700 Subject: [9] RFR (S) 8157184: java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java failed with a fatal error Message-ID: <8e775401-04cd-b48f-ac78-18cc9f34c6ab@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8157184 http://cr.openjdk.java.net/~kvn/8157184/webrev.00/ Here is possible failure scenario: PICL is not installed on the failed SPARC machine as result _L2_data_cache_line_size is 0 (unknown). In such situation we should not use BIS instructions. But AllocatePrefetchInstr setting is not guarded by cache_line_size > 0 check and BIS instruction is selected: The default value for AllocatePrefetchStepSize is 16 when cache_line_size is 0 which is smaller then real cache line size (32). Flags values on crashing T5 machine: Reserve for allocation: 24 AllocatePrefetchLines: 6 AllocateInstancePrefetchLines: 2 AllocatePrefetchDistance: 64 AllocatePrefetchStepSize: 16 AllocatePrefetchInstr: 1 AllocatePrefetchStyle: 3 _reserve_for_allocation_prefetch = (AllocatePrefetchDistance + AllocatePrefetchStepSize * lines) It is not multiply of real cache line size since AllocatePrefetchStepSize =16 < 32 bytes cache line on T5. And since we are using BIS instruction it can clean whole cache line if it is executed for address aligned to the start of cache line and at the end of reserved space: _reserve_for_allocation_prefetch -16. As result it may clear values after reserved space (in following TLAB). Solution: add missing cache_line_size > 0 checks. Tested comp and jdk:tier1+tier2 RBT and forced _L2_data_cache_line_size = 0. Thanks, Vladimir From vladimir.x.ivanov at oracle.com Thu May 19 17:21:56 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 19 May 2016 20:21:56 +0300 Subject: [9] RFR (S) 8157184: java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java failed with a fatal error In-Reply-To: <8e775401-04cd-b48f-ac78-18cc9f34c6ab@oracle.com> References: <8e775401-04cd-b48f-ac78-18cc9f34c6ab@oracle.com> Message-ID: <19dc9114-b20c-5f66-4af1-bc7b87c3b3a7@oracle.com> Reviewed. Best regards, Vladimir Ivanov On 5/19/16 8:18 PM, Vladimir Kozlov wrote: > https://bugs.openjdk.java.net/browse/JDK-8157184 > > http://cr.openjdk.java.net/~kvn/8157184/webrev.00/ > > Here is possible failure scenario: > > PICL is not installed on the failed SPARC machine as result > _L2_data_cache_line_size is 0 (unknown). In such situation we should not > use BIS instructions. But AllocatePrefetchInstr setting is not guarded > by cache_line_size > 0 check and BIS instruction is selected: > > The default value for AllocatePrefetchStepSize is 16 when > cache_line_size is 0 which is smaller then real cache line size (32). > > Flags values on crashing T5 machine: > Reserve for allocation: 24 > AllocatePrefetchLines: 6 > AllocateInstancePrefetchLines: 2 > AllocatePrefetchDistance: 64 > AllocatePrefetchStepSize: 16 > AllocatePrefetchInstr: 1 > AllocatePrefetchStyle: 3 > > > _reserve_for_allocation_prefetch = (AllocatePrefetchDistance + > AllocatePrefetchStepSize * lines) > > It is not multiply of real cache line size since > AllocatePrefetchStepSize =16 < 32 bytes cache line on T5. > > And since we are using BIS instruction it can clean whole cache line if > it is executed for address aligned to the start of cache line and at the > end of reserved space: _reserve_for_allocation_prefetch -16. As result > it may clear values after reserved space (in following TLAB). > > Solution: add missing cache_line_size > 0 checks. > > Tested comp and jdk:tier1+tier2 RBT and forced _L2_data_cache_line_size > = 0. > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Thu May 19 17:24:28 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 19 May 2016 10:24:28 -0700 Subject: [9] RFR (S) 8157184: java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java failed with a fatal error In-Reply-To: <19dc9114-b20c-5f66-4af1-bc7b87c3b3a7@oracle.com> References: <8e775401-04cd-b48f-ac78-18cc9f34c6ab@oracle.com> <19dc9114-b20c-5f66-4af1-bc7b87c3b3a7@oracle.com> Message-ID: Thank you! Vladimir K On 5/19/16 10:21 AM, Vladimir Ivanov wrote: > Reviewed. > > Best regards, > Vladimir Ivanov > > On 5/19/16 8:18 PM, Vladimir Kozlov wrote: >> https://bugs.openjdk.java.net/browse/JDK-8157184 >> >> http://cr.openjdk.java.net/~kvn/8157184/webrev.00/ >> >> Here is possible failure scenario: >> >> PICL is not installed on the failed SPARC machine as result >> _L2_data_cache_line_size is 0 (unknown). In such situation we should not >> use BIS instructions. But AllocatePrefetchInstr setting is not guarded >> by cache_line_size > 0 check and BIS instruction is selected: >> >> The default value for AllocatePrefetchStepSize is 16 when >> cache_line_size is 0 which is smaller then real cache line size (32). >> >> Flags values on crashing T5 machine: >> Reserve for allocation: 24 >> AllocatePrefetchLines: 6 >> AllocateInstancePrefetchLines: 2 >> AllocatePrefetchDistance: 64 >> AllocatePrefetchStepSize: 16 >> AllocatePrefetchInstr: 1 >> AllocatePrefetchStyle: 3 >> >> >> _reserve_for_allocation_prefetch = (AllocatePrefetchDistance + >> AllocatePrefetchStepSize * lines) >> >> It is not multiply of real cache line size since >> AllocatePrefetchStepSize =16 < 32 bytes cache line on T5. >> >> And since we are using BIS instruction it can clean whole cache line if >> it is executed for address aligned to the start of cache line and at the >> end of reserved space: _reserve_for_allocation_prefetch -16. As result >> it may clear values after reserved space (in following TLAB). >> >> Solution: add missing cache_line_size > 0 checks. >> >> Tested comp and jdk:tier1+tier2 RBT and forced _L2_data_cache_line_size >> = 0. >> >> Thanks, >> Vladimir From kim.barrett at oracle.com Thu May 19 17:38:45 2016 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 19 May 2016 13:38:45 -0400 Subject: [9] RFR (S) 8157184: java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java failed with a fatal error In-Reply-To: <8e775401-04cd-b48f-ac78-18cc9f34c6ab@oracle.com> References: <8e775401-04cd-b48f-ac78-18cc9f34c6ab@oracle.com> Message-ID: <3D6782C6-1F04-4D82-88C7-EBE723A22DDB@oracle.com> > On May 19, 2016, at 1:18 PM, Vladimir Kozlov wrote: > > https://bugs.openjdk.java.net/browse/JDK-8157184 > > http://cr.openjdk.java.net/~kvn/8157184/webrev.00/ Looks good. From vladimir.kozlov at oracle.com Thu May 19 17:51:06 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 19 May 2016 10:51:06 -0700 Subject: [9] RFR (S) 8157184: java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java failed with a fatal error In-Reply-To: <3D6782C6-1F04-4D82-88C7-EBE723A22DDB@oracle.com> References: <8e775401-04cd-b48f-ac78-18cc9f34c6ab@oracle.com> <3D6782C6-1F04-4D82-88C7-EBE723A22DDB@oracle.com> Message-ID: <4028f067-6ece-fcb4-3688-d6c516f2fe01@oracle.com> Thank you, Kim Vladimir On 5/19/16 10:38 AM, Kim Barrett wrote: >> On May 19, 2016, at 1:18 PM, Vladimir Kozlov wrote: >> >> https://bugs.openjdk.java.net/browse/JDK-8157184 >> >> http://cr.openjdk.java.net/~kvn/8157184/webrev.00/ > > Looks good. > From gromero at linux.vnet.ibm.com Thu May 19 23:46:05 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Thu, 19 May 2016 20:46:05 -0300 Subject: PPC64 VSX load/store instructions in stubs In-Reply-To: References: <56FEDBB3.5030106@linux.vnet.ibm.com> <57339EE1.2040500@linux.vnet.ibm.com> Message-ID: <201605192346.u4JNhdUm028414@mx0a-001b2d01.pphosted.com> Hi Martin Thank you for reviewing the webrev. > We could use a static variable for the default dscr value. It could be modified in VM_Version::config_dscr() and used by your restore code (load_const_optimized(tmp1, ...) instead of li(tmp1, 0)). Absolutely, resetting DSCR to the default value (zero) is not right. I did as you suggested and created a static variable modified and initialized from VM_Version::config_dscr(). Then I used it to get the current value of DSCR, set only the pre-fetch as deepest, and restore its previous value. > - The PPC-elf64abi-1.9 says: "Functions must ensure that the appropriate bits in the vrsave register are set for any vector registers they use. ...". I think not touching vrsave is the right thing for AIX and ppc64le, but I think we will either have to skip the optimization on ppc64 big endian or handle vrsave. Do you agree? About the VRSAVE register, you are right, but there is a confusing here and it's my fault: I'm not using the VMX registers. In my code I've used the VSX load/store instructions with a VectorRegister type, i.e. VR0 and VR1. It's OK if we look at the assembled instructions because, in the end, VR0 and VR1 will be converted to target (or source) registers number 0 and 1. But it's VSX registers 0 and 1 (VSR0 and VSR1) and not VMX (aka Altivec) registers 0 and 1 (VR0 and VR1). There is indeed a relationship between VSR and VR registers, as we can see in the following diagram adapted from [1]: .---------------------------------. VSR( 0)| FPR(0) | | VSR( 1)| FPR(1) | | ... | ... | | ... | ... | | VSR(30)| FPR(30) | | VSR(31)| FPR(31) | | VSR(32)| VR(0) | VSR(33)| VR(1) | ... | ... | ... | ... | VSR(62)| VR(30) | VSR(63)| VR(31) | '---------------------------------' 0 127 However VMX registers VR0-31 are mapped to VSX VSR32-63 registers, and so we can use VSR0 and VSR1 (although they are also mapped to FPR, FPR0-13 are volatile). Thus actually in my code I was using VSR0 and VSR1 and not VR0 and VR1. Thus as VRSAVE only corresponds to VMX/Altivec registers (VR0-VR31), there is not need to take care of VRSAVE. I fixed the registers names/types in this new webrev. I noted that the VSR registers were not implemented and thus I implemented them. Now VSX load/store instruction use VectorSRegister type. I'm using VSR0 and VSR1 registers in the stub, respecting the ABI. Webrev: http://81.de.7a9f.ip4.static.sl-reverse.com./8154156/9/v2/ Best regards, Gustavo [1] Power Architecture 64-Bit ELF V2 ABI https://goo.gl/LLXRwN, p. 43-44 > -----Original Message----- > From: Gustavo Romero [mailto:gromero at linux.vnet.ibm.com] > Sent: Mittwoch, 11. Mai 2016 23:07 > To: Volker Simonis > Cc: Doerr, Martin ; Simonis, Volker ; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; brenohl at br.ibm.com > Subject: Re: PPC64 VSX load/store instructions in stubs > Importance: High > > Hi Volker, Hi Martin > > Sincere apologies for the long delay. > > My initial approach to test the VSX load/store was from an > extracted snippet regarding just the mass copy loop "grafted" inside an inline > asm, performing isolated tests with "perf" tool focused only on aligned source and > destination (best case). > > The extracted code, called "Original" in the plot below (black line), is here: > https://github.com/gromero/arraycopy/blob/2pairs/arraycopy.c#L27-L36 > > That extracted, after some experiments, evolved into this one that employs VSX > load/store, Data Stream deepest pre-fetch, d-cache touch, and backbranch aligned > to 32-byte: > https://github.com/gromero/arraycopy/blob/2pairs/arraycopy_vsx.c#L27-L41 > > All runs where "pinned" using `numactl --cpunodebind --membind` to avoid any > scheduler decision that could add noise to the measure. > > VSX, deepest data pre-fetch, d-cache touch, and 32-bytes align proved to be better > in the isolated code (red line) in comparison to the original extracted code > (black line): > http://gromero.github.io/openjdk/original_vsx_non_pf_vsx_pf_deepest.pdf > > So I proceeded to implement the VSX loop in OpenJDK based on the best case > result (VSX, pre-fetch deepest, d-cache touch, and backbranch target align - > goetz TODO note). > > OpenJDK 8 webrev: > http://81.de.7a9f.ip4.static.sl-reverse.com/8154156/8/ > > OpenJDK 9 webrev: > http://81.de.7a9f.ip4.static.sl-reverse.com/8154156/9/ > > I've tested the change on OpenJDK 8 using this script that calls > System.arraycopy() on shorts: > https://goo.gl/8UWtLm > > The results for all data alignment cases: > http://gromero.github.io/openjdk/src_0_dst_0.pdf > http://gromero.github.io/openjdk/src_1_dst_0.pdf > http://gromero.github.io/openjdk/src_0_dst_1.pdf > http://gromero.github.io/openjdk/src_1_dst_1.pdf > > Martin, I added the vsx test to the feature-string. Regarding the ABI, I'm just > using two VSR: vsr0 and vsr1, both volatile. > > Volker, as the loop unrolling was removed now the loop copies 16 elemets a time, > like the non-VSX loop, and not 32 elements. I just verified the change on Little > endian. Sorry I didn't understand your question regarding "instructions for > aligned load/stores". Did you mean instructions for unaligned load/stores? I think > both fixed-point (ld/std) and VSX instructions will do load/store slower in > unaligned scenario. However VMX load/store is different and expects aligned > operands. Thank you very much for opening the bug > https://bugs.openjdk.java.net/browse/JDK-8154156 > > I don't have the profiling per function for each SPEC{jbb,jvm} benchmark > in order to determine which one would stress the proposed change better. > Could I use a better benchmark? > > Thank you! > > Best regards, > Gustavo > > On 05-04-2016 14:23, Volker Simonis wrote: >> Hi Gustavo, >> >> thanks a lot for your contribution. >> >> Can you please describe if you've run benchmarks and which performance >> improvements you saw? >> >> With your change if we're running on Power 8, we will only use the >> fast path for arrays with at least 32 elements. For smaller arrays, we >> will fall-back to copying only 2 elements at a time which will be >> slower than the initial version which copied 4 at a time in that case. >> >> Did you verified your changes on both, little and big endian? >> >> And what about unaligned memory accesses? As far as I read, >> lxvd2x/stxvd2x still work, but may be slower. I saw there also exist >> instructions for aligned load/stores. Would it make sens >> (performance-wise) to use them for the cases where we can be sure that >> we have aligned memory accesses? >> >> Thank you and best regards, >> Volker >> >> >> On Fri, Apr 1, 2016 at 10:36 PM, Gustavo Romero >> wrote: >>> Hi Martin, Hi Volker >>> >>> Currently VSX load/store instructions are not being used in PPC64 stubs, >>> particularly in arraycopy stubs inside generate_arraycopy_stubs() like, >>> but not limited to, generate_disjoint_{byte,short,int,long}_copy. >>> >>> We can speed up mass copy using VSX (Vector-Scalar Extension) load/store >>> instruction in processors >= POWER8, the same way it's already done for >>> libc memcpy(). >>> >>> This is an initial patch just for jshort_disjoint_arraycopy() VSX vector >>> load/store: >>> >>> http://81.de.7a9f.ip4.static.sl-reverse.com/202539/webrev >>> >>> What are your thoughts on that? Is there any impediment to use VSX >>> instructions in OpenJDK at the moment? >>> >>> Thank you. >>> >>> Best regards, >>> Gustavo >>> >> > From aph at redhat.com Thu May 19 16:33:41 2016 From: aph at redhat.com (Andrew Haley) Date: Thu, 19 May 2016 17:33:41 +0100 Subject: enhancement of cmpxchg and copy_to_survivor for ppc64 In-Reply-To: <95abf1f5-0464-0df1-7de2-c8f7c493703e@oracle.com> References: <201604081054.u38As2K6014953@d19av07.sagamino.japan.ibm.com> <5711ED18.7000706@oracle.com> <201604180215.u3I2FUZi001650@d19av07.sagamino.japan.ibm.com> <571464DF.3070706@oracle.com> <5714E416.6030300@redhat.com> <571577EB.1080907@oracle.com> <573D8D20.3080008@redhat.com> <95abf1f5-0464-0df1-7de2-c8f7c493703e@oracle.com> Message-ID: <573DEAE5.3000107@redhat.com> On 05/19/2016 12:56 PM, David Holmes wrote: > I will be shepherding 8155949 through the post FC process (once we know > what it is). If you can provide the Aarch64 code before that completes > then it can go in with the other changes under this bug. Otherwise it > will need a separate bug. AArch64 code at http://cr.openjdk.java.net/~aph/8154736 Thanks, Andrew. From gromero at linux.vnet.ibm.com Fri May 20 16:20:05 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Fri, 20 May 2016 13:20:05 -0300 Subject: PPC64 VSX load/store instructions in stubs In-Reply-To: <201605192346.u4JNhdUm028414@mx0a-001b2d01.pphosted.com> References: <56FEDBB3.5030106@linux.vnet.ibm.com> <57339EE1.2040500@linux.vnet.ibm.com> <201605192346.u4JNhdUm028414@mx0a-001b2d01.pphosted.com> Message-ID: <201605201620.u4KGEUO9039690@mx0a-001b2d01.pphosted.com> > Hi Martin > > Thank you for reviewing the webrev. > >> We could use a static variable for the default dscr value. It could be modified in VM_Version::config_dscr() and used by your restore code (load_const_optimized(tmp1, ...) instead of li(tmp1, 0)). > > Absolutely, resetting DSCR to the default value (zero) is not right. > > I did as you suggested and created a static variable modified and > initialized from VM_Version::config_dscr(). Then I used it to get the > current value of DSCR, set only the pre-fetch as deepest, and restore > its previous value. > > >> - The PPC-elf64abi-1.9 says: "Functions must ensure that the appropriate bits in the vrsave register are set for any vector registers they use. ...". I think not touching vrsave is the right thing for AIX and ppc64le, but I think we will either have to skip the optimization on ppc64 big endian or handle vrsave. Do you agree? > > About the VRSAVE register, you are right, but there is a confusing here > and it's my fault: I'm not using the VMX registers. > > In my code I've used the VSX load/store instructions with a > VectorRegister type, i.e. VR0 and VR1. It's OK if we look at the > assembled instructions because, in the end, VR0 and VR1 will be > converted to target (or source) registers number 0 and 1. But it's VSX > registers 0 and 1 (VSR0 and VSR1) and not VMX (aka Altivec) registers > 0 and 1 (VR0 and VR1). > > There is indeed a relationship between VSR and VR registers, as > we can see in the following diagram adapted from [1]: > > .---------------------------------. > VSR( 0)| FPR(0) | | > VSR( 1)| FPR(1) | | > ... | ... | | > ... | ... | | > VSR(30)| FPR(30) | | > VSR(31)| FPR(31) | | > VSR(32)| VR(0) | > VSR(33)| VR(1) | > ... | ... | > ... | ... | > VSR(62)| VR(30) | > VSR(63)| VR(31) | > '---------------------------------' > 0 127 > > However VMX registers VR0-31 are mapped to VSX VSR32-63 registers, > and so we can use VSR0 and VSR1 (although they are also mapped to FPR, > FPR0-13 are volatile). Thus actually in my code I was using VSR0 and > VSR1 and not VR0 and VR1. Thus as VRSAVE only corresponds to > VMX/Altivec registers (VR0-VR31), there is not need to take care of > VRSAVE. I fixed the registers names/types in this new webrev. > > I noted that the VSR registers were not implemented and thus I > implemented them. Now VSX load/store instruction use VectorSRegister > type. I'm using VSR0 and VSR1 registers in the stub, respecting the > ABI. > > Webrev: > http://81.de.7a9f.ip4.static.sl-reverse.com./8154156/9/v2/ > > Best regards, > Gustavo > > [1] Power Architecture 64-Bit ELF V2 ABI https://goo.gl/LLXRwN, p. 43-44 > Hi Martin The previous change was not restoring the DSCR value. Here is the webwev with the fix included: http://81.de.7a9f.ip4.static.sl-reverse.com./8154156/9/v3/ Thank you! Best regards, Gustavo From tobias.hartmann at oracle.com Mon May 23 09:25:19 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 23 May 2016 11:25:19 +0200 Subject: [9] RFR(S): 8156760: VM crashes if -XX:-ReduceInitialCardMarks is set Message-ID: <5742CC7F.4050309@oracle.com> Hi, please review the following patch: https://bugs.openjdk.java.net/browse/JDK-8156760 http://cr.openjdk.java.net/~thartmann/8156760/webrev.00/ While working on JDK-8155643, I found several problems when running tests with -XX:-ReduceInitialCardMarks: Problem 1: C2 crashes with "missing G1 post barrier" while trying to eliminate the card mark emitted by the Object.clone() intrinsic (after removing the allocation of the destination object) [1]. The problem is that the shape of the card mark code is different for the Object.clone() intrinsic because we don't emit any checks (see [4]). However, PhaseMacroExpand::eliminate_card_mark() tries to find and collapse a region check. Usually, this is not a problem because with ReduceInitialCardMarks we don't emit a post barrier for Object.clone(). Problem 2: The VM crashes during GC verification in G1SATBCardTableModRefBS::verify_g1_young_region() with "there should not have been any failures" because we expect cards for the young generation to be always set to 'g1_young_gen' [2]: [1.478s][error][gc,verify] == CT verification failed: [0x00007f097c167800,0x00007f097c167fff] [1.478s][error][gc,verify] == expecting value: 32 [1.478s][error][gc,verify] == card 0x00007f097c167800 [0x00000006d8900000,0x00000006d8900200], val: 0 [1.478s][error][gc,verify] == card 0x00007f097c167801 [0x00000006d8900200,0x00000006d8900400], val: 0 ... With !ReduceInitialCardMarks, the Object.clone() intrinsic emits card marks that set the cards of the newly allocated destination object to 'dirty' (!= 'g1_young_gen') and thus causing the verification to fail. I fixed problems 1 and 2 by removing the card marking code for the Object.clone() intrinsic with G1. This should be fine because the destination object is always in Eden and we therefore don't need to mark the cards. Problem 3: C2 crashes with SIGSEGV in ArrayCopyNode::prepare_array_copy() because we expect an array clone/copy and dereference 'src_type->isa_aryptr()' but actually have a non-array Object.clone() [3]. This is because with !ReduceInitialCardMarks, ArrayCopyNode::try_clone_instance() does not capture the Object.clone() intrinsic because we emit card marking code (we bail out in 'ArrayCopyNode::finish_transform()'). We continue assuming that the array copy is a non-instance copy. I added an additional check to bail out in this case. I changed 'TestInstanceCloneAsLoadsStores' to be also executed with -XX:-ReduceInitialCardMarks. This triggers problem 1 and 2. Problem 3 can be reproduced by running the modified test with XX:+UseConcMarkSweepGC. Tested with failing tests, JPRT and RBT (running). Thanks, Tobias [1] https://bugs.openjdk.java.net/secure/attachment/59410/hs_err_pid28313.log [2] https://bugs.openjdk.java.net/secure/attachment/59661/hs_err_pid30301.log [3] https://bugs.openjdk.java.net/secure/attachment/59660/hs_err_pid22570.log [4] https://bugs.openjdk.java.net/secure/attachment/59564/graph.png From rwestrel at redhat.com Mon May 23 09:34:30 2016 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 23 May 2016 11:34:30 +0200 Subject: [9] RFR(S): 8156760: VM crashes if -XX:-ReduceInitialCardMarks is set In-Reply-To: <5742CC7F.4050309@oracle.com> References: <5742CC7F.4050309@oracle.com> Message-ID: <5742CEA6.3040907@redhat.com> Hi Tobias, > Problem 3: C2 crashes with SIGSEGV in > ArrayCopyNode::prepare_array_copy() because we expect an array > clone/copy and dereference 'src_type->isa_aryptr()' but actually have > a non-array Object.clone() [3]. This is because with > !ReduceInitialCardMarks, ArrayCopyNode::try_clone_instance() does not > capture the Object.clone() intrinsic because we emit card marking > code (we bail out in 'ArrayCopyNode::finish_transform()'). We > continue assuming that the array copy is a non-instance copy. I added > an additional check to bail out in this case. One problem I noticed in this code is that ArrayCopyNode::try_clone_instance() returns NULL to mean both this is not a basic clone: if (!is_clonebasic()) { return NULL; } and the clone failed: if (!finish_transform(phase, can_reshape, ctl, mem)) { return NULL; } ArrayCopyNode::finish_transform() would fail with !ReduceInitialCardMarks. The way I fixed this locally is to return NodeSentinel when the clone fails so the caller can distinguish not a clone from a failure. And then ArrayCopyNode::finish_transform(): Node* mem = try_clone_instance(phase, can_reshape, count); if (mem != NULL) { return mem == NodeSentinel ? NULL: mem; } Does that solve the same problem you're seeing? Roland. From tobias.hartmann at oracle.com Mon May 23 10:29:14 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 23 May 2016 12:29:14 +0200 Subject: [9] RFR(S): 8156760: VM crashes if -XX:-ReduceInitialCardMarks is set In-Reply-To: <5742CEA6.3040907@redhat.com> References: <5742CC7F.4050309@oracle.com> <5742CEA6.3040907@redhat.com> Message-ID: <5742DB7A.7070605@oracle.com> Hi Roland, thanks for the review! Please see comments below. On 23.05.2016 11:34, Roland Westrelin wrote: > > Hi Tobias, > >> Problem 3: C2 crashes with SIGSEGV in >> ArrayCopyNode::prepare_array_copy() because we expect an array >> clone/copy and dereference 'src_type->isa_aryptr()' but actually have >> a non-array Object.clone() [3]. This is because with >> !ReduceInitialCardMarks, ArrayCopyNode::try_clone_instance() does not >> capture the Object.clone() intrinsic because we emit card marking >> code (we bail out in 'ArrayCopyNode::finish_transform()'). We >> continue assuming that the array copy is a non-instance copy. I added >> an additional check to bail out in this case. > > One problem I noticed in this code is that > ArrayCopyNode::try_clone_instance() returns NULL to mean both this is > not a basic clone: > > if (!is_clonebasic()) { > return NULL; > } > > and the clone failed: > > if (!finish_transform(phase, can_reshape, ctl, mem)) { > return NULL; > } > > ArrayCopyNode::finish_transform() would fail with > !ReduceInitialCardMarks. The way I fixed this locally is to return > NodeSentinel when the clone fails so the caller can distinguish not a > clone from a failure. And then ArrayCopyNode::finish_transform(): > > Node* mem = try_clone_instance(phase, can_reshape, count); > if (mem != NULL) { > return mem == NodeSentinel ? NULL: mem; > } > > Does that solve the same problem you're seeing? Yes, that's a better solution and solves the problem as well. Here is the updated webrev: http://cr.openjdk.java.net/~thartmann/8156760/webrev.01/ Thanks, Tobias > > Roland. > From aph at redhat.com Mon May 23 14:18:33 2016 From: aph at redhat.com (Andrew Haley) Date: Mon, 23 May 2016 15:18:33 +0100 Subject: Code flow post-FC Message-ID: <57431139.7000509@redhat.com> I'm a little mystified by how updates between repositories flow from now on. For example, is it still correct to post hotspot fixes) (once properly approved) to jdk9/hs ? And it'll still get periodically merged to jdk9/jdk9 ? Thanks, Andrew. From gromero at linux.vnet.ibm.com Mon May 23 14:22:16 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Mon, 23 May 2016 11:22:16 -0300 Subject: RFR(M): PPC64: improve array copy stubs by using vector instructions Message-ID: <201605231422.u4NEIbhU013920@mx0a-001b2d01.pphosted.com> Hi Martin Could you please host and review this webrev? Summary: * Add VSR registers to be used with VSX instruction set; * Add VSX load/store instructions (lxvd2x/stxvd2x) to mass copy in the stub for disjoint short copy in order to improve it. http://81.de.7a9f.ip4.static.sl-reverse.com./8154156/9/v4/ Thank you! Best regards, Gustavo From jesper.wilhelmsson at oracle.com Mon May 23 14:56:57 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Mon, 23 May 2016 16:56:57 +0200 Subject: Code flow post-FC In-Reply-To: <57431139.7000509@redhat.com> References: <57431139.7000509@redhat.com> Message-ID: <19d3e25c-4ec7-ed0b-2433-63f263453cd4@oracle.com> Hi Andrew, Yes, integrations will continue as before. jdk9/hs is the place to be :) /Jesper Den 23/5/16 kl. 16:18, skrev Andrew Haley: > I'm a little mystified by how updates between repositories flow from > now on. For example, is it still correct to post hotspot fixes) > (once properly approved) to jdk9/hs ? And it'll still get > periodically merged to jdk9/jdk9 ? > > Thanks, > > Andrew. > From martin.doerr at sap.com Mon May 23 15:51:41 2016 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 23 May 2016 15:51:41 +0000 Subject: RFR(M): PPC64: improve array copy stubs by using vector instructions In-Reply-To: <201605231422.u4NEIb1g013944@mx0a-001b2d01.pphosted.com> References: <201605231422.u4NEIb1g013944@mx0a-001b2d01.pphosted.com> Message-ID: <25cb11dfe7624a4a8848d049626413e7@DEWDFE13DE14.global.corp.sap> Hi Gustavo, thanks for implementing it and taking care of my concerns. Looks good, now. I will run tests and I can sponsor it after it was reviewed. Best regards, Martin -----Original Message----- From: Gustavo Romero [mailto:gromero at linux.vnet.ibm.com] Sent: Montag, 23. Mai 2016 16:22 To: Doerr, Martin ; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net Cc: Simonis, Volker ; brenohl at br.ibm.com Subject: RFR(M): PPC64: improve array copy stubs by using vector instructions Hi Martin Could you please host and review this webrev? Summary: * Add VSR registers to be used with VSX instruction set; * Add VSX load/store instructions (lxvd2x/stxvd2x) to mass copy in the stub for disjoint short copy in order to improve it. http://81.de.7a9f.ip4.static.sl-reverse.com./8154156/9/v4/ Thank you! Best regards, Gustavo From gromero at linux.vnet.ibm.com Mon May 23 15:53:45 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Mon, 23 May 2016 12:53:45 -0300 Subject: RFR(M): PPC64: improve array copy stubs by using vector instructions In-Reply-To: <25cb11dfe7624a4a8848d049626413e7@DEWDFE13DE14.global.corp.sap> References: <201605231422.u4NEIb1g013944@mx0a-001b2d01.pphosted.com> <25cb11dfe7624a4a8848d049626413e7@DEWDFE13DE14.global.corp.sap> Message-ID: <201605231553.u4NFn96A017225@mx0a-001b2d01.pphosted.com> Hi Martin Thank you for reviewing the change. Best regards, Gustavo On 23-05-2016 12:51, Doerr, Martin wrote: > Hi Gustavo, > > thanks for implementing it and taking care of my concerns. Looks good, now. > I will run tests and I can sponsor it after it was reviewed. > > Best regards, > Martin > > -----Original Message----- > From: Gustavo Romero [mailto:gromero at linux.vnet.ibm.com] > Sent: Montag, 23. Mai 2016 16:22 > To: Doerr, Martin ; ppc-aix-port-dev at openjdk.java.net; hotspot-dev at openjdk.java.net > Cc: Simonis, Volker ; brenohl at br.ibm.com > Subject: RFR(M): PPC64: improve array copy stubs by using vector instructions > > Hi Martin > > Could you please host and review this webrev? > > Summary: > > * Add VSR registers to be used with VSX instruction set; > * Add VSX load/store instructions (lxvd2x/stxvd2x) to mass copy in > the stub for disjoint short copy in order to improve it. > > http://81.de.7a9f.ip4.static.sl-reverse.com./8154156/9/v4/ > > Thank you! > > Best regards, > Gustavo > From vladimir.kozlov at oracle.com Mon May 23 17:27:26 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 23 May 2016 10:27:26 -0700 Subject: [9] RFR(S): 8156760: VM crashes if -XX:-ReduceInitialCardMarks is set In-Reply-To: <5742DB7A.7070605@oracle.com> References: <5742CC7F.4050309@oracle.com> <5742CEA6.3040907@redhat.com> <5742DB7A.7070605@oracle.com> Message-ID: <567e211f-9237-7474-4683-48f759f5a71c@oracle.com> Looks good to me. I don't see RBT link in bug report. Thanks, Vladimir On 5/23/16 3:29 AM, Tobias Hartmann wrote: > Hi Roland, > > thanks for the review! Please see comments below. > > On 23.05.2016 11:34, Roland Westrelin wrote: >> >> Hi Tobias, >> >>> Problem 3: C2 crashes with SIGSEGV in >>> ArrayCopyNode::prepare_array_copy() because we expect an array >>> clone/copy and dereference 'src_type->isa_aryptr()' but actually have >>> a non-array Object.clone() [3]. This is because with >>> !ReduceInitialCardMarks, ArrayCopyNode::try_clone_instance() does not >>> capture the Object.clone() intrinsic because we emit card marking >>> code (we bail out in 'ArrayCopyNode::finish_transform()'). We >>> continue assuming that the array copy is a non-instance copy. I added >>> an additional check to bail out in this case. >> >> One problem I noticed in this code is that >> ArrayCopyNode::try_clone_instance() returns NULL to mean both this is >> not a basic clone: >> >> if (!is_clonebasic()) { >> return NULL; >> } >> >> and the clone failed: >> >> if (!finish_transform(phase, can_reshape, ctl, mem)) { >> return NULL; >> } >> >> ArrayCopyNode::finish_transform() would fail with >> !ReduceInitialCardMarks. The way I fixed this locally is to return >> NodeSentinel when the clone fails so the caller can distinguish not a >> clone from a failure. And then ArrayCopyNode::finish_transform(): >> >> Node* mem = try_clone_instance(phase, can_reshape, count); >> if (mem != NULL) { >> return mem == NodeSentinel ? NULL: mem; >> } >> >> Does that solve the same problem you're seeing? > > Yes, that's a better solution and solves the problem as well. > > Here is the updated webrev: > http://cr.openjdk.java.net/~thartmann/8156760/webrev.01/ > > Thanks, > Tobias > >> >> Roland. >> From yumin.qi at gmail.com Mon May 23 17:43:02 2016 From: yumin.qi at gmail.com (yumin qi) Date: Mon, 23 May 2016 10:43:02 -0700 Subject: [9] RFR(S): 8156760: VM crashes if -XX:-ReduceInitialCardMarks is set In-Reply-To: <5742DB7A.7070605@oracle.com> References: <5742CC7F.4050309@oracle.com> <5742CEA6.3040907@redhat.com> <5742DB7A.7070605@oracle.com> Message-ID: Hi, Tobias src/share/vm/opto/graphKit.cpp: 4210 // If we are writing a NULL then we need no post barrier 4211 if (val != NULL && val->is_Con() && val->bottom_type() == TypePtr::NULL_PTR) { val is valid now so val != NULL can be removed I think. I'm not a Reviewer Thanks Yumin On Mon, May 23, 2016 at 3:29 AM, Tobias Hartmann wrote: > Hi Roland, > > thanks for the review! Please see comments below. > > On 23.05.2016 11:34, Roland Westrelin wrote: > > > > Hi Tobias, > > > >> Problem 3: C2 crashes with SIGSEGV in > >> ArrayCopyNode::prepare_array_copy() because we expect an array > >> clone/copy and dereference 'src_type->isa_aryptr()' but actually have > >> a non-array Object.clone() [3]. This is because with > >> !ReduceInitialCardMarks, ArrayCopyNode::try_clone_instance() does not > >> capture the Object.clone() intrinsic because we emit card marking > >> code (we bail out in 'ArrayCopyNode::finish_transform()'). We > >> continue assuming that the array copy is a non-instance copy. I added > >> an additional check to bail out in this case. > > > > One problem I noticed in this code is that > > ArrayCopyNode::try_clone_instance() returns NULL to mean both this is > > not a basic clone: > > > > if (!is_clonebasic()) { > > return NULL; > > } > > > > and the clone failed: > > > > if (!finish_transform(phase, can_reshape, ctl, mem)) { > > return NULL; > > } > > > > ArrayCopyNode::finish_transform() would fail with > > !ReduceInitialCardMarks. The way I fixed this locally is to return > > NodeSentinel when the clone fails so the caller can distinguish not a > > clone from a failure. And then ArrayCopyNode::finish_transform(): > > > > Node* mem = try_clone_instance(phase, can_reshape, count); > > if (mem != NULL) { > > return mem == NodeSentinel ? NULL: mem; > > } > > > > Does that solve the same problem you're seeing? > > Yes, that's a better solution and solves the problem as well. > > Here is the updated webrev: > http://cr.openjdk.java.net/~thartmann/8156760/webrev.01/ > > Thanks, > Tobias > > > > > Roland. > > > From dean.long at oracle.com Mon May 23 18:09:49 2016 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 23 May 2016 11:09:49 -0700 Subject: [9] RFR(S): 8156760: VM crashes if -XX:-ReduceInitialCardMarks is set In-Reply-To: <5742CC7F.4050309@oracle.com> References: <5742CC7F.4050309@oracle.com> Message-ID: <88436ef0-e133-843c-3183-db310edc7148@oracle.com> Hi Tobias. I was just wondering, how do we know that the destination object is in Eden, both now and in the future, and what would happen if it wasn't? Would we get a nice assert somewhere, or would we end up with a hard-to-find bug? dl On 5/23/16 2:25 AM, Tobias Hartmann wrote: > Hi, > > please review the following patch: > > https://bugs.openjdk.java.net/browse/JDK-8156760 > http://cr.openjdk.java.net/~thartmann/8156760/webrev.00/ > > While working on JDK-8155643, I found several problems when running tests with -XX:-ReduceInitialCardMarks: > > Problem 1: > C2 crashes with "missing G1 post barrier" while trying to eliminate the card mark emitted by the Object.clone() intrinsic (after removing the allocation of the destination object) [1]. The problem is that the shape of the card mark code is different for the Object.clone() intrinsic because we don't emit any checks (see [4]). However, PhaseMacroExpand::eliminate_card_mark() tries to find and collapse a region check. Usually, this is not a problem because with ReduceInitialCardMarks we don't emit a post barrier for Object.clone(). > > Problem 2: > The VM crashes during GC verification in G1SATBCardTableModRefBS::verify_g1_young_region() with "there should not have been any failures" because we expect cards for the young generation to be always set to 'g1_young_gen' [2]: > > [1.478s][error][gc,verify] == CT verification failed: [0x00007f097c167800,0x00007f097c167fff] > [1.478s][error][gc,verify] == expecting value: 32 > [1.478s][error][gc,verify] == card 0x00007f097c167800 [0x00000006d8900000,0x00000006d8900200], val: 0 > [1.478s][error][gc,verify] == card 0x00007f097c167801 [0x00000006d8900200,0x00000006d8900400], val: 0 > ... > > With !ReduceInitialCardMarks, the Object.clone() intrinsic emits card marks that set the cards of the newly allocated destination object to 'dirty' (!= 'g1_young_gen') and thus causing the verification to fail. > > I fixed problems 1 and 2 by removing the card marking code for the Object.clone() intrinsic with G1. This should be fine because the destination object is always in Eden and we therefore don't need to mark the cards. > > Problem 3: > C2 crashes with SIGSEGV in ArrayCopyNode::prepare_array_copy() because we expect an array clone/copy and dereference 'src_type->isa_aryptr()' but actually have a non-array Object.clone() [3]. This is because with !ReduceInitialCardMarks, ArrayCopyNode::try_clone_instance() does not capture the Object.clone() intrinsic because we emit card marking code (we bail out in 'ArrayCopyNode::finish_transform()'). We continue assuming that the array copy is a non-instance copy. I added an additional check to bail out in this case. > > I changed 'TestInstanceCloneAsLoadsStores' to be also executed with -XX:-ReduceInitialCardMarks. This triggers problem 1 and 2. Problem 3 can be reproduced by running the modified test with XX:+UseConcMarkSweepGC. > > Tested with failing tests, JPRT and RBT (running). > > Thanks, > Tobias > > [1] https://bugs.openjdk.java.net/secure/attachment/59410/hs_err_pid28313.log > [2] https://bugs.openjdk.java.net/secure/attachment/59661/hs_err_pid30301.log > [3] https://bugs.openjdk.java.net/secure/attachment/59660/hs_err_pid22570.log > [4] https://bugs.openjdk.java.net/secure/attachment/59564/graph.png From gerard.ziemski at oracle.com Mon May 23 20:44:16 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Mon, 23 May 2016 15:44:16 -0500 Subject: RFR (XS): rev3 8152856: Xcode 7.3 -Wshift-negative-value compile failure on Mac OS X In-Reply-To: References: <185B4145-0862-44AF-93F5-C75F81056195@oracle.com> Message-ID: <48E5B4E2-0A0E-45F7-8DA8-3493F98B338C@oracle.com> PING I still need 2nd Reviewer. cheers > On May 4, 2016, at 11:02 AM, Gerard Ziemski wrote: > > PING > > Can I please have a review of this small fix? I have removed makefile change, which is no longer needed, so this should be non-controversial to review: > > bug: https://bugs.openjdk.java.net/browse/JDK-8152856 > webrev: http://cr.openjdk.java.net/~gziemski/8152856_rev3 > > > cheers > >> On Apr 6, 2016, at 11:35 AM, Gerard Ziemski wrote: >> >> hi all, >> >> I have implemented and tested out the new proposed fix using constant instead of casts. Please review this new fix: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8152856 >> webrev: http://cr.openjdk.java.net/~gziemski/8152856_rev2 >> >> Passes JPRT hotspot and RBT hotspot/test/:hotspot_runtime >> >> >> cheers >> >>> On Mar 31, 2016, at 9:08 AM, Gerard Ziemski wrote: >>> >>> hi all, >>> >>> Since no-one has reviewed this yet and in the meantime we changed https://wiki.openjdk.java.net/display/HotSpot/StyleGuide to discourage using enums in hotspot (see JDK-8153116 for more details) I?m going to withdraw this proposed fix and try doing it by replacing enums with constant literals instead of using casts on enums. >>> >>> I therefore withdraw this fix for now. >>> >>> >>> cheers >>> >>>> On Mar 29, 2016, at 4:30 PM, Gerard Ziemski wrote: >>>> >>>> hi all, >>>> >>>> Please review this small fix that enables Xcde 7.3 support for building hotspot, which involved 2 things: >>>> >>>> - modify gcc.make to add support for 7.3 version of clang compiler >>>> - modify src/cpu/x86/vm/stubGenerator_x86_64.cpp, src/share/vm/oops/klass.hpp and src/share/vm/opto/library_call.cpp to cast 4 instances of signed int to unsigned when using shift operator to avoid "-Wshift-negative-value" warning. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8152856 >>>> http://cr.openjdk.java.net/~gziemski/8152856_rev1 >>>> >>>> Passes JPRT hotspot on all platforms >>>> >>> >> > From yumin.qi at gmail.com Mon May 23 20:48:45 2016 From: yumin.qi at gmail.com (yumin qi) Date: Mon, 23 May 2016 13:48:45 -0700 Subject: RFR (XS): rev3 8152856: Xcode 7.3 -Wshift-negative-value compile failure on Mac OS X In-Reply-To: <48E5B4E2-0A0E-45F7-8DA8-3493F98B338C@oracle.com> References: <185B4145-0862-44AF-93F5-C75F81056195@oracle.com> <48E5B4E2-0A0E-45F7-8DA8-3493F98B338C@oracle.com> Message-ID: It looks good (I also tried to build on mac, before your fix, I have to use workaround), thanks! Yumin On Mon, May 23, 2016 at 1:44 PM, Gerard Ziemski wrote: > PING > > I still need 2nd Reviewer. > > > cheers > > > On May 4, 2016, at 11:02 AM, Gerard Ziemski > wrote: > > > > PING > > > > Can I please have a review of this small fix? I have removed makefile > change, which is no longer needed, so this should be non-controversial to > review: > > > > bug: https://bugs.openjdk.java.net/browse/JDK-8152856 > > webrev: http://cr.openjdk.java.net/~gziemski/8152856_rev3 > > > > > > cheers > > > >> On Apr 6, 2016, at 11:35 AM, Gerard Ziemski > wrote: > >> > >> hi all, > >> > >> I have implemented and tested out the new proposed fix using constant > instead of casts. Please review this new fix: > >> > >> bug: https://bugs.openjdk.java.net/browse/JDK-8152856 > >> webrev: http://cr.openjdk.java.net/~gziemski/8152856_rev2 > >> > >> Passes JPRT hotspot and RBT hotspot/test/:hotspot_runtime > >> > >> > >> cheers > >> > >>> On Mar 31, 2016, at 9:08 AM, Gerard Ziemski > wrote: > >>> > >>> hi all, > >>> > >>> Since no-one has reviewed this yet and in the meantime we changed > https://wiki.openjdk.java.net/display/HotSpot/StyleGuide to discourage > using enums in hotspot (see JDK-8153116 for more details) I?m going to > withdraw this proposed fix and try doing it by replacing enums with > constant literals instead of using casts on enums. > >>> > >>> I therefore withdraw this fix for now. > >>> > >>> > >>> cheers > >>> > >>>> On Mar 29, 2016, at 4:30 PM, Gerard Ziemski < > gerard.ziemski at oracle.com> wrote: > >>>> > >>>> hi all, > >>>> > >>>> Please review this small fix that enables Xcde 7.3 support for > building hotspot, which involved 2 things: > >>>> > >>>> - modify gcc.make to add support for 7.3 version of clang compiler > >>>> - modify src/cpu/x86/vm/stubGenerator_x86_64.cpp, > src/share/vm/oops/klass.hpp and src/share/vm/opto/library_call.cpp to cast > 4 instances of signed int to unsigned when using shift operator to avoid > "-Wshift-negative-value" warning. > >>>> > >>>> https://bugs.openjdk.java.net/browse/JDK-8152856 > >>>> http://cr.openjdk.java.net/~gziemski/8152856_rev1 > >>>> > >>>> Passes JPRT hotspot on all platforms > >>>> > >>> > >> > > > > From david.holmes at oracle.com Mon May 23 20:49:19 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 24 May 2016 06:49:19 +1000 Subject: Code flow post-FC In-Reply-To: <57431139.7000509@redhat.com> References: <57431139.7000509@redhat.com> Message-ID: <8bbc688b-0e09-502a-8c31-01f13012efc6@oracle.com> On 24/05/2016 12:18 AM, Andrew Haley wrote: > I'm a little mystified by how updates between repositories flow from > now on. For example, is it still correct to post hotspot fixes) > (once properly approved) to jdk9/hs ? And it'll still get > periodically merged to jdk9/jdk9 ? Note fixes don't need approvals only enhancements. We can keep fixing without approvals until we hit RDP1. David > Thanks, > > Andrew. > From tobias.hartmann at oracle.com Tue May 24 06:08:02 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 24 May 2016 08:08:02 +0200 Subject: [9] RFR(S): 8156760: VM crashes if -XX:-ReduceInitialCardMarks is set In-Reply-To: References: <5742CC7F.4050309@oracle.com> <5742CEA6.3040907@redhat.com> <5742DB7A.7070605@oracle.com> Message-ID: <5743EFC2.80100@oracle.com> Hi Yumin, On 23.05.2016 19:43, yumin qi wrote: > Hi, Tobias > > src/share/vm/opto/graphKit.cpp: > > 4210 // If we are writing a NULL then we need no post barrier > 4211 if (val != NULL && val->is_Con() && val->bottom_type() == TypePtr::NULL_PTR) { > > val is valid now so val != NULL can be removed I think. Thanks, you are right. I updated the webrev in-place. Best regards, Tobias > > I'm not a Reviewer > > > Thanks > > Yumin > > > > On Mon, May 23, 2016 at 3:29 AM, Tobias Hartmann > wrote: > > Hi Roland, > > thanks for the review! Please see comments below. > > On 23.05.2016 11:34, Roland Westrelin wrote: > > > > Hi Tobias, > > > >> Problem 3: C2 crashes with SIGSEGV in > >> ArrayCopyNode::prepare_array_copy() because we expect an array > >> clone/copy and dereference 'src_type->isa_aryptr()' but actually have > >> a non-array Object.clone() [3]. This is because with > >> !ReduceInitialCardMarks, ArrayCopyNode::try_clone_instance() does not > >> capture the Object.clone() intrinsic because we emit card marking > >> code (we bail out in 'ArrayCopyNode::finish_transform()'). We > >> continue assuming that the array copy is a non-instance copy. I added > >> an additional check to bail out in this case. > > > > One problem I noticed in this code is that > > ArrayCopyNode::try_clone_instance() returns NULL to mean both this is > > not a basic clone: > > > > if (!is_clonebasic()) { > > return NULL; > > } > > > > and the clone failed: > > > > if (!finish_transform(phase, can_reshape, ctl, mem)) { > > return NULL; > > } > > > > ArrayCopyNode::finish_transform() would fail with > > !ReduceInitialCardMarks. The way I fixed this locally is to return > > NodeSentinel when the clone fails so the caller can distinguish not a > > clone from a failure. And then ArrayCopyNode::finish_transform(): > > > > Node* mem = try_clone_instance(phase, can_reshape, count); > > if (mem != NULL) { > > return mem == NodeSentinel ? NULL: mem; > > } > > > > Does that solve the same problem you're seeing? > > Yes, that's a better solution and solves the problem as well. > > Here is the updated webrev: > http://cr.openjdk.java.net/~thartmann/8156760/webrev.01/ > > Thanks, > Tobias > > > > > Roland. > > > > From tobias.hartmann at oracle.com Tue May 24 06:16:36 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 24 May 2016 08:16:36 +0200 Subject: [9] RFR(S): 8156760: VM crashes if -XX:-ReduceInitialCardMarks is set In-Reply-To: <567e211f-9237-7474-4683-48f759f5a71c@oracle.com> References: <5742CC7F.4050309@oracle.com> <5742CEA6.3040907@redhat.com> <5742DB7A.7070605@oracle.com> <567e211f-9237-7474-4683-48f759f5a71c@oracle.com> Message-ID: <5743F1C4.8080304@oracle.com> Thanks, Vladimir! I attached the RBT link to the bug report. Best regards, Tobias On 23.05.2016 19:27, Vladimir Kozlov wrote: > Looks good to me. > I don't see RBT link in bug report. > > Thanks, > Vladimir > > On 5/23/16 3:29 AM, Tobias Hartmann wrote: >> Hi Roland, >> >> thanks for the review! Please see comments below. >> >> On 23.05.2016 11:34, Roland Westrelin wrote: >>> >>> Hi Tobias, >>> >>>> Problem 3: C2 crashes with SIGSEGV in >>>> ArrayCopyNode::prepare_array_copy() because we expect an array >>>> clone/copy and dereference 'src_type->isa_aryptr()' but actually have >>>> a non-array Object.clone() [3]. This is because with >>>> !ReduceInitialCardMarks, ArrayCopyNode::try_clone_instance() does not >>>> capture the Object.clone() intrinsic because we emit card marking >>>> code (we bail out in 'ArrayCopyNode::finish_transform()'). We >>>> continue assuming that the array copy is a non-instance copy. I added >>>> an additional check to bail out in this case. >>> >>> One problem I noticed in this code is that >>> ArrayCopyNode::try_clone_instance() returns NULL to mean both this is >>> not a basic clone: >>> >>> if (!is_clonebasic()) { >>> return NULL; >>> } >>> >>> and the clone failed: >>> >>> if (!finish_transform(phase, can_reshape, ctl, mem)) { >>> return NULL; >>> } >>> >>> ArrayCopyNode::finish_transform() would fail with >>> !ReduceInitialCardMarks. The way I fixed this locally is to return >>> NodeSentinel when the clone fails so the caller can distinguish not a >>> clone from a failure. And then ArrayCopyNode::finish_transform(): >>> >>> Node* mem = try_clone_instance(phase, can_reshape, count); >>> if (mem != NULL) { >>> return mem == NodeSentinel ? NULL: mem; >>> } >>> >>> Does that solve the same problem you're seeing? >> >> Yes, that's a better solution and solves the problem as well. >> >> Here is the updated webrev: >> http://cr.openjdk.java.net/~thartmann/8156760/webrev.01/ >> >> Thanks, >> Tobias >> >>> >>> Roland. >>> From dmitry.samersoff at oracle.com Tue May 24 08:27:40 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 24 May 2016 11:27:40 +0300 Subject: RFR: 8157243: JMap heap test fail when used with external heap In-Reply-To: <573C83EB.5090804@oracle.com> References: <573C83EB.5090804@oracle.com> Message-ID: <5744107C.5050802@oracle.com> Stefan, Looks good for me. -Dmitry On 2016-05-18 18:02, Stefan Johansson wrote: > Hi, > > Please review this small change for: > https://bugs.openjdk.java.net/browse/JDK-8157243 > > Webrev: > http://cr.openjdk.java.net/~sjohanss/8157243/hotspot.00/ > > Summary: > This change is needed to fix a failing test when a non-standard heap is > used. The change adds a way to declare such heaps. > > Since this was considered an enhancement rather then a bug-fix, I'm > currently waiting for approval to push this even though FC has passed. > > Testing: > * JPRT > * RBT > > Thanks, > Stefan > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From goetz.lindenmaier at sap.com Tue May 24 08:29:41 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 24 May 2016 08:29:41 +0000 Subject: RFR(M): PPC64: improve array copy stubs by using vector instructions In-Reply-To: <201605231553.u4NFq1Rr022712@mx0a-001b2d01.pphosted.com> References: <201605231422.u4NEIb1g013944@mx0a-001b2d01.pphosted.com> <25cb11dfe7624a4a8848d049626413e7@DEWDFE13DE14.global.corp.sap> <201605231553.u4NFq1Rr022712@mx0a-001b2d01.pphosted.com> Message-ID: <8b32b8882e964fd0b2ac0f22c94e389a@DEWDFE13DE09.global.corp.sap> Hi Gustavo, thanks for contributing this optimization to the ppc port! The change looks good, nice work. Next time, please use correct subject in the RFR mail, the bugID is missing. Also, address the RFR to everybody. This one you addressed to Martin. In general, you need several reviews. Martin, thanks for reviewing though! Martin, I think you can push this as it's ppc-only. Best regards, Goetz. > -----Original Message----- > From: Gustavo Romero [mailto:gromero at linux.vnet.ibm.com] > Sent: Montag, 23. Mai 2016 17:54 > To: Doerr, Martin ; ppc-aix-port- > dev at openjdk.java.net; hotspot-dev at openjdk.java.net > Cc: Simonis, Volker ; brenohl at br.ibm.com; > Lindenmaier, Goetz > Subject: Re: RFR(M): PPC64: improve array copy stubs by using vector > instructions > > Hi Martin > > Thank you for reviewing the change. > > Best regards, > Gustavo > > On 23-05-2016 12:51, Doerr, Martin wrote: > > Hi Gustavo, > > > > thanks for implementing it and taking care of my concerns. Looks good, > now. > > I will run tests and I can sponsor it after it was reviewed. > > > > Best regards, > > Martin > > > > -----Original Message----- > > From: Gustavo Romero [mailto:gromero at linux.vnet.ibm.com] > > Sent: Montag, 23. Mai 2016 16:22 > > To: Doerr, Martin ; ppc-aix-port- > dev at openjdk.java.net; hotspot-dev at openjdk.java.net > > Cc: Simonis, Volker ; brenohl at br.ibm.com > > Subject: RFR(M): PPC64: improve array copy stubs by using vector > instructions > > > > Hi Martin > > > > Could you please host and review this webrev? > > > > Summary: > > > > * Add VSR registers to be used with VSX instruction set; > > * Add VSX load/store instructions (lxvd2x/stxvd2x) to mass copy in > > the stub for disjoint short copy in order to improve it. > > > > http://81.de.7a9f.ip4.static.sl-reverse.com./8154156/9/v4/ > > > > Thank you! > > > > Best regards, > > Gustavo > > From tobias.hartmann at oracle.com Tue May 24 08:54:42 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 24 May 2016 10:54:42 +0200 Subject: [9] RFR(S): 8156760: VM crashes if -XX:-ReduceInitialCardMarks is set In-Reply-To: <88436ef0-e133-843c-3183-db310edc7148@oracle.com> References: <5742CC7F.4050309@oracle.com> <88436ef0-e133-843c-3183-db310edc7148@oracle.com> Message-ID: <574416D2.9080803@oracle.com> Hi Dean, On 23.05.2016 20:09, dean.long at oracle.com wrote: > Hi Tobias. I was just wondering, how do we know that the destination object is in Eden, both now and in the future, and what would happen if it wasn't? Would we get a nice assert somewhere, or would we end up with a hard-to-find bug? Thanks for the feedback! From reading the G1 code, I assumed that a newly allocated object is always in Eden. Looking at the code again, I'm not sure what happens if the Eden space is full. If allocations may happen in the old generation as well, we need a runtime check for the card value. I don't think we have an assert/verification that checks this. Could someone from GC please verify this? Thanks, Tobias > dl > > > On 5/23/16 2:25 AM, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch: >> >> https://bugs.openjdk.java.net/browse/JDK-8156760 >> http://cr.openjdk.java.net/~thartmann/8156760/webrev.00/ >> >> While working on JDK-8155643, I found several problems when running tests with -XX:-ReduceInitialCardMarks: >> >> Problem 1: >> C2 crashes with "missing G1 post barrier" while trying to eliminate the card mark emitted by the Object.clone() intrinsic (after removing the allocation of the destination object) [1]. The problem is that the shape of the card mark code is different for the Object.clone() intrinsic because we don't emit any checks (see [4]). However, PhaseMacroExpand::eliminate_card_mark() tries to find and collapse a region check. Usually, this is not a problem because with ReduceInitialCardMarks we don't emit a post barrier for Object.clone(). >> >> Problem 2: >> The VM crashes during GC verification in G1SATBCardTableModRefBS::verify_g1_young_region() with "there should not have been any failures" because we expect cards for the young generation to be always set to 'g1_young_gen' [2]: >> >> [1.478s][error][gc,verify] == CT verification failed: [0x00007f097c167800,0x00007f097c167fff] >> [1.478s][error][gc,verify] == expecting value: 32 >> [1.478s][error][gc,verify] == card 0x00007f097c167800 [0x00000006d8900000,0x00000006d8900200], val: 0 >> [1.478s][error][gc,verify] == card 0x00007f097c167801 [0x00000006d8900200,0x00000006d8900400], val: 0 >> ... >> >> With !ReduceInitialCardMarks, the Object.clone() intrinsic emits card marks that set the cards of the newly allocated destination object to 'dirty' (!= 'g1_young_gen') and thus causing the verification to fail. >> >> I fixed problems 1 and 2 by removing the card marking code for the Object.clone() intrinsic with G1. This should be fine because the destination object is always in Eden and we therefore don't need to mark the cards. >> >> Problem 3: >> C2 crashes with SIGSEGV in ArrayCopyNode::prepare_array_copy() because we expect an array clone/copy and dereference 'src_type->isa_aryptr()' but actually have a non-array Object.clone() [3]. This is because with !ReduceInitialCardMarks, ArrayCopyNode::try_clone_instance() does not capture the Object.clone() intrinsic because we emit card marking code (we bail out in 'ArrayCopyNode::finish_transform()'). We continue assuming that the array copy is a non-instance copy. I added an additional check to bail out in this case. >> >> I changed 'TestInstanceCloneAsLoadsStores' to be also executed with -XX:-ReduceInitialCardMarks. This triggers problem 1 and 2. Problem 3 can be reproduced by running the modified test with XX:+UseConcMarkSweepGC. >> >> Tested with failing tests, JPRT and RBT (running). >> >> Thanks, >> Tobias >> >> [1] https://bugs.openjdk.java.net/secure/attachment/59410/hs_err_pid28313.log >> [2] https://bugs.openjdk.java.net/secure/attachment/59661/hs_err_pid30301.log >> [3] https://bugs.openjdk.java.net/secure/attachment/59660/hs_err_pid22570.log >> [4] https://bugs.openjdk.java.net/secure/attachment/59564/graph.png > From thomas.schatzl at oracle.com Tue May 24 07:13:50 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 24 May 2016 09:13:50 +0200 Subject: [9] RFR(S): 8156760: VM crashes if -XX:-ReduceInitialCardMarks is set In-Reply-To: <574416D2.9080803@oracle.com> References: <5742CC7F.4050309@oracle.com> <88436ef0-e133-843c-3183-db310edc7148@oracle.com> <574416D2.9080803@oracle.com> Message-ID: <1464074030.4740.15.camel@oracle.com> Hi Tobias, On Di, 2016-05-24 at 10:54 +0200, Tobias Hartmann wrote: > Hi Dean, > > On 23.05.2016 20:09, dean.long at oracle.com wrote: > > Hi Tobias. I was just wondering, how do we know that the destination > > object is in Eden, both now and in the future, and what would happen if >> it wasn't? Would we get a nice assert somewhere, or would we end up >> with a hard-to-find bug? Hard-to-find bug. Please add an assertion. > > Thanks for the feedback! From reading the G1 code, I assumed that a > newly allocated object is always in Eden. Looking at the code again, > I'm not sure what happens if the Eden space is full. If allocations > may happen in the old generation as well, we need a runtime check for > the card value. I don't think we have an assert/verification that > checks this. > > Could someone from GC please verify this? all "small" object allocations go into eden. If eden is exhausted, we either issue a GC, or if we can't, expand eden. The only exceptions are large objects ("humongous", > half a region size). These always go into old gen directly. Thanks, Thomas From tobias.hartmann at oracle.com Tue May 24 09:26:12 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 24 May 2016 11:26:12 +0200 Subject: [9] RFR(S): 8156760: VM crashes if -XX:-ReduceInitialCardMarks is set In-Reply-To: <1464074030.4740.15.camel@oracle.com> References: <5742CC7F.4050309@oracle.com> <88436ef0-e133-843c-3183-db310edc7148@oracle.com> <574416D2.9080803@oracle.com> <1464074030.4740.15.camel@oracle.com> Message-ID: <57441E34.5030101@oracle.com> Hi Thomas, thanks for looking at this! On 24.05.2016 09:13, Thomas Schatzl wrote: > Hi Tobias, > > On Di, 2016-05-24 at 10:54 +0200, Tobias Hartmann wrote: >> Hi Dean, >> >> On 23.05.2016 20:09, dean.long at oracle.com wrote: >>> Hi Tobias. I was just wondering, how do we know that the destination >>> object is in Eden, both now and in the future, and what would happen if >>> it wasn't? Would we get a nice assert somewhere, or would we end up >>> with a hard-to-find bug? > > Hard-to-find bug. Please add an assertion. > >> >> Thanks for the feedback! From reading the G1 code, I assumed that a >> newly allocated object is always in Eden. Looking at the code again, >> I'm not sure what happens if the Eden space is full. If allocations >> may happen in the old generation as well, we need a runtime check for >> the card value. I don't think we have an assert/verification that >> checks this. >> >> Could someone from GC please verify this? > > all "small" object allocations go into eden. > > If eden is exhausted, we either issue a GC, or if we can't, expand eden. > > The only exceptions are large objects ("humongous", > half a region > size). These always go into old gen directly. Okay, then we need to check the card value for the object to determine if it is "humongous" and allocated in the old generation. If so, we need to emit a post-write barrier. How does the GC handle this if ReduceInitialCardMarks is *enabled* and the compiler never emits card marks for newly allocated objects (even if they are allocated in old gen)? I'll prepare a new webrev. Thanks, Tobias > > Thanks, > Thomas > > From tobias.hartmann at oracle.com Tue May 24 11:35:55 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 24 May 2016 13:35:55 +0200 Subject: [9] RFR(S): 8156760: VM crashes if -XX:-ReduceInitialCardMarks is set In-Reply-To: <57442FDC.1050603@oracle.com> References: <5742CC7F.4050309@oracle.com> <88436ef0-e133-843c-3183-db310edc7148@oracle.com> <574416D2.9080803@oracle.com> <1464074030.4740.15.camel@oracle.com> <57441E34.5030101@oracle.com> <57442FDC.1050603@oracle.com> Message-ID: <57443C9B.3070601@oracle.com> Hi Thomas, [putting hotspot-dev back on CC] On 24.05.2016 12:41, thomas schatzl wrote: > Hi, > > On 24.05.2016 11:26, Tobias Hartmann wrote: >> Hi Thomas, > >> >> thanks for looking at this! >> >> On 24.05.2016 09:13, Thomas Schatzl wrote: >>> Hi Tobias, >>> >>> On Di, 2016-05-24 at 10:54 +0200, Tobias Hartmann wrote: >>>> Hi Dean, > [...] >>>> Thanks for the feedback! From reading the G1 code, I assumed that a >>>> newly allocated object is always in Eden. Looking at the code again, >>>> I'm not sure what happens if the Eden space is full. If allocations >>>> may happen in the old generation as well, we need a runtime check for >>>> the card value. I don't think we have an assert/verification that >>>> checks this. >>>> >>>> Could someone from GC please verify this? >>> >>> all "small" object allocations go into eden. >>> >>> If eden is exhausted, we either issue a GC, or if we can't, expand eden. >>> >>> The only exceptions are large objects ("humongous", > half a region >>> size). These always go into old gen directly. >> >> Okay, then we need to check the card value for the object to determine >> if it is "humongous" and allocated in the old generation. If so, we need >>to emit a post-write barrier. > > Humongous allocations always go through the runtime. I do not think the compiler needs to emit code for this case. Okay, but isn't this only the case if ReduceInitialCardMarks is enabled? See this comment in library_call.cpp: // (We can dispense with card marks if we know the allocation // comes out of eden (TLAB)... In fact, ReduceInitialCardMarks // causes the non-eden paths to take compensating steps to // simulate a fresh allocation, so that no further // card marks are required in compiled code to initialize // the object.) Looking at the comments around CollectedHeap::can_elide_tlab_store_barriers(), it seems that the compiler has to notify the runtime when eliding card-marks. The question is if compiled code that emits an AllocateNode can rely on the runtime taking such compensating steps even if ReduceInitialCardMarks is *disabled*? Because I think in this case, the compiler does not notify the runtime. If not, the compiler needs to emit card marks if the object is not in eden, right? Thanks, Tobias >> How does the GC handle this if ReduceInitialCardMarks is *enabled* and >> the compiler never emits card marks for newly allocated objects (even >> if they are allocated in old gen)? > > Compiled code never allocates into the old gen directly - humongous allocations require a runtime call. So I do not think this needs a change in the compiler after all. > > Sorry for not being specific enough in the first place. > >> I'll prepare a new webrev. > > Thanks, > Thomas > From gromero at linux.vnet.ibm.com Tue May 24 13:59:58 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Tue, 24 May 2016 10:59:58 -0300 Subject: RFR(M): PPC64: improve array copy stubs by using vector instructions In-Reply-To: <8b32b8882e964fd0b2ac0f22c94e389a@DEWDFE13DE09.global.corp.sap> References: <201605231422.u4NEIb1g013944@mx0a-001b2d01.pphosted.com> <25cb11dfe7624a4a8848d049626413e7@DEWDFE13DE14.global.corp.sap> <201605231553.u4NFq1Rr022712@mx0a-001b2d01.pphosted.com> <8b32b8882e964fd0b2ac0f22c94e389a@DEWDFE13DE09.global.corp.sap> Message-ID: <201605241400.u4ODtMgm033322@mx0a-001b2d01.pphosted.com> Hi Goetz I'm happy to be contributing to the ppc port! Sorry, I didn't realize that bugID was missing in the subject. Next time I'll pay attention on that and also address the RFR to everybody, sure. Thanks for point that out. Thanks a lot for reviewing the change. Best regards, Gustavo On 24-05-2016 05:29, Lindenmaier, Goetz wrote: > Hi Gustavo, > > thanks for contributing this optimization to the ppc port! > > The change looks good, nice work. > > Next time, please use correct subject in the RFR mail, the bugID is missing. > Also, address the RFR to everybody. This one you addressed to Martin. > In general, you need several reviews. > Martin, thanks for reviewing though! > > Martin, I think you can push this as it's ppc-only. > > Best regards, > Goetz. > > > >> -----Original Message----- >> From: Gustavo Romero [mailto:gromero at linux.vnet.ibm.com] >> Sent: Montag, 23. Mai 2016 17:54 >> To: Doerr, Martin ; ppc-aix-port- >> dev at openjdk.java.net; hotspot-dev at openjdk.java.net >> Cc: Simonis, Volker ; brenohl at br.ibm.com; >> Lindenmaier, Goetz >> Subject: Re: RFR(M): PPC64: improve array copy stubs by using vector >> instructions >> >> Hi Martin >> >> Thank you for reviewing the change. >> >> Best regards, >> Gustavo >> >> On 23-05-2016 12:51, Doerr, Martin wrote: >>> Hi Gustavo, >>> >>> thanks for implementing it and taking care of my concerns. Looks good, >> now. >>> I will run tests and I can sponsor it after it was reviewed. >>> >>> Best regards, >>> Martin >>> >>> -----Original Message----- >>> From: Gustavo Romero [mailto:gromero at linux.vnet.ibm.com] >>> Sent: Montag, 23. Mai 2016 16:22 >>> To: Doerr, Martin ; ppc-aix-port- >> dev at openjdk.java.net; hotspot-dev at openjdk.java.net >>> Cc: Simonis, Volker ; brenohl at br.ibm.com >>> Subject: RFR(M): PPC64: improve array copy stubs by using vector >> instructions >>> >>> Hi Martin >>> >>> Could you please host and review this webrev? >>> >>> Summary: >>> >>> * Add VSR registers to be used with VSX instruction set; >>> * Add VSX load/store instructions (lxvd2x/stxvd2x) to mass copy in >>> the stub for disjoint short copy in order to improve it. >>> >>> http://81.de.7a9f.ip4.static.sl-reverse.com./8154156/9/v4/ >>> >>> Thank you! >>> >>> Best regards, >>> Gustavo >>> > From thomas.schatzl at oracle.com Tue May 24 14:33:11 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 24 May 2016 16:33:11 +0200 Subject: [9] RFR(S): 8156760: VM crashes if -XX:-ReduceInitialCardMarks is set In-Reply-To: <57443C9B.3070601@oracle.com> References: <5742CC7F.4050309@oracle.com> <88436ef0-e133-843c-3183-db310edc7148@oracle.com> <574416D2.9080803@oracle.com> <1464074030.4740.15.camel@oracle.com> <57441E34.5030101@oracle.com> <57442FDC.1050603@oracle.com> <57443C9B.3070601@oracle.com> Message-ID: <1464100391.10697.5.camel@oracle.com> Hi Tobias, On Di, 2016-05-24 at 13:35 +0200, Tobias Hartmann wrote: > Hi Thomas, > > [putting hotspot-dev back on CC] > sorry for messing up this... > On 24.05.2016 12:41, thomas schatzl wrote: > > Hi, > > > > On 24.05.2016 11:26, Tobias Hartmann wrote: > >> Hi Thomas, > > > >> > >> thanks for looking at this! > >> > >> On 24.05.2016 09:13, Thomas Schatzl wrote: > >>> Hi Tobias, > >>> > >>> On Di, 2016-05-24 at 10:54 +0200, Tobias Hartmann wrote: > >>>> Hi Dean, > > [...] > >>>> Thanks for the feedback! From reading the G1 code, I assumed that a > >>>> newly allocated object is always in Eden. Looking at the code again, > >>>> I'm not sure what happens if the Eden space is full. If allocations > >>>> may happen in the old generation as well, we need a runtime check for > >>>> the card value. I don't think we have an assert/verification that > >>>> checks this. > >>>> > >>>> Could someone from GC please verify this? > >>> > >>> all "small" object allocations go into eden. > >>> > >>> If eden is exhausted, we either issue a GC, or if we can't, expand eden. > >>> > >>> The only exceptions are large objects ("humongous", > half a region > >>> size). These always go into old gen directly. > >> > >> Okay, then we need to check the card value for the object to determine > >> if it is "humongous" and allocated in the old generation. If so, we need > >>to emit a post-write barrier. > > > > Humongous allocations always go through the runtime. I do not think the >> compiler needs to emit code for this case. > > Okay, but isn't this only the case if ReduceInitialCardMarks is enabled? > > See this comment in library_call.cpp: > > // (We can dispense with card marks if we know the allocation > // comes out of eden (TLAB)... In fact, ReduceInitialCardMarks > // causes the non-eden paths to take compensating steps to > // simulate a fresh allocation, so that no further > // card marks are required in compiled code to initialize > // the object.) > > Looking at the comments around CollectedHeap::can_elide_tlab_store_barriers(), > it seems that the compiler has to notify the runtime when eliding card-marks. > The question is if compiled code that emits an AllocateNode can rely on the > runtime taking such compensating steps even if ReduceInitialCardMarks is > *disabled*? Because I think in this case, the compiler does not notify the > runtime. > > If not, the compiler needs to emit card marks if the object is not in eden, >right? Okay, I think I got it. Yes, in case ReduceInitialCardMarks is false, the compiler needs to emit the card marks for humongous object allocations. Thanks, Thomas From gerard.ziemski at oracle.com Tue May 24 15:05:20 2016 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Tue, 24 May 2016 10:05:20 -0500 Subject: RFR (XS): rev3 8152856: Xcode 7.3 -Wshift-negative-value compile failure on Mac OS X In-Reply-To: References: <185B4145-0862-44AF-93F5-C75F81056195@oracle.com> <48E5B4E2-0A0E-45F7-8DA8-3493F98B338C@oracle.com> Message-ID: <8FA69A95-F929-4845-8C6C-A879664A280E@oracle.com> Thank you Yumin. cheers > On May 23, 2016, at 3:48 PM, yumin qi wrote: > > It looks good (I also tried to build on mac, before your fix, I have to use workaround), thanks! > > Yumin > > On Mon, May 23, 2016 at 1:44 PM, Gerard Ziemski wrote: > PING > > I still need 2nd Reviewer. > > > cheers > > > On May 4, 2016, at 11:02 AM, Gerard Ziemski wrote: > > > > PING > > > > Can I please have a review of this small fix? I have removed makefile change, which is no longer needed, so this should be non-controversial to review: > > > > bug: https://bugs.openjdk.java.net/browse/JDK-8152856 > > webrev: http://cr.openjdk.java.net/~gziemski/8152856_rev3 > > > > > > cheers > > > >> On Apr 6, 2016, at 11:35 AM, Gerard Ziemski wrote: > >> > >> hi all, > >> > >> I have implemented and tested out the new proposed fix using constant instead of casts. Please review this new fix: > >> > >> bug: https://bugs.openjdk.java.net/browse/JDK-8152856 > >> webrev: http://cr.openjdk.java.net/~gziemski/8152856_rev2 > >> > >> Passes JPRT hotspot and RBT hotspot/test/:hotspot_runtime > >> > >> > >> cheers > >> > >>> On Mar 31, 2016, at 9:08 AM, Gerard Ziemski wrote: > >>> > >>> hi all, > >>> > >>> Since no-one has reviewed this yet and in the meantime we changed https://wiki.openjdk.java.net/display/HotSpot/StyleGuide to discourage using enums in hotspot (see JDK-8153116 for more details) I?m going to withdraw this proposed fix and try doing it by replacing enums with constant literals instead of using casts on enums. > >>> > >>> I therefore withdraw this fix for now. > >>> > >>> > >>> cheers > >>> > >>>> On Mar 29, 2016, at 4:30 PM, Gerard Ziemski wrote: > >>>> > >>>> hi all, > >>>> > >>>> Please review this small fix that enables Xcde 7.3 support for building hotspot, which involved 2 things: > >>>> > >>>> - modify gcc.make to add support for 7.3 version of clang compiler > >>>> - modify src/cpu/x86/vm/stubGenerator_x86_64.cpp, src/share/vm/oops/klass.hpp and src/share/vm/opto/library_call.cpp to cast 4 instances of signed int to unsigned when using shift operator to avoid "-Wshift-negative-value" warning. > >>>> > >>>> https://bugs.openjdk.java.net/browse/JDK-8152856 > >>>> http://cr.openjdk.java.net/~gziemski/8152856_rev1 > >>>> > >>>> Passes JPRT hotspot on all platforms > >>>> > >>> > >> > > > > From alexhenrie24 at gmail.com Tue May 24 18:27:54 2016 From: alexhenrie24 at gmail.com (Alex Henrie) Date: Tue, 24 May 2016 12:27:54 -0600 Subject: [PATCH resend] 8152856: Use (~0u) instead of (-1) when left-shifting Message-ID: # HG changeset patch # User ahenrie # Date 1463507859 21600 # Tue May 17 11:57:39 2016 -0600 # Node ID b7b02a758a39c9dab702c3b14c773fd601951384 # Parent d2e2a5306fed8dd9bce3d81e8fe15cf465eabb05 8152856: Use (~0u) instead of (-1) when left-shifting diff --git a/src/share/vm/code/dependencies.hpp b/src/share/vm/code/dependencies.hpp --- a/src/share/vm/code/dependencies.hpp +++ b/src/share/vm/code/dependencies.hpp @@ -163,17 +163,17 @@ class Dependencies: public ResourceObj { call_site_target_value, TYPE_LIMIT }; enum { LG2_TYPE_LIMIT = 4, // assert(TYPE_LIMIT <= (1< References: Message-ID: <80574B2A-8EC4-43D4-BF35-11C0186E8D3D@oracle.com> hi Alex, Thank you for the patch. I know it?s a bit of a hassle, but could you please file a new issue to cover your proposed fix and why you want it in? cheers > On May 24, 2016, at 1:27 PM, Alex Henrie wrote: > > # HG changeset patch > # User ahenrie > # Date 1463507859 21600 > # Tue May 17 11:57:39 2016 -0600 > # Node ID b7b02a758a39c9dab702c3b14c773fd601951384 > # Parent d2e2a5306fed8dd9bce3d81e8fe15cf465eabb05 > 8152856: Use (~0u) instead of (-1) when left-shifting > > diff --git a/src/share/vm/code/dependencies.hpp b/src/share/vm/code/dependencies.hpp > --- a/src/share/vm/code/dependencies.hpp > +++ b/src/share/vm/code/dependencies.hpp > @@ -163,17 +163,17 @@ class Dependencies: public ResourceObj { > call_site_target_value, > > TYPE_LIMIT > }; > enum { > LG2_TYPE_LIMIT = 4, // assert(TYPE_LIMIT <= (1< > // handy categorizations of dependency types: > - all_types = ((1 << TYPE_LIMIT) - 1) & ((-1) << FIRST_TYPE), > + all_types = ((1 << TYPE_LIMIT) - 1) & ((~0u) << FIRST_TYPE), > > non_klass_types = (1 << call_site_target_value), > klass_types = all_types & ~non_klass_types, > > non_ctxk_types = (1 << evol_method) | (1 << call_site_target_value), > implicit_ctxk_types = 0, > explicit_ctxk_types = all_types & ~(non_ctxk_types | implicit_ctxk_types), > > diff --git a/src/share/vm/oops/cpCache.hpp b/src/share/vm/oops/cpCache.hpp > --- a/src/share/vm/oops/cpCache.hpp > +++ b/src/share/vm/oops/cpCache.hpp > @@ -188,17 +188,17 @@ class ConstantPoolCacheEntry VALUE_OBJ_C > is_final_shift = 22, // (f) is the field or method final? > is_volatile_shift = 21, // (v) is the field volatile? > is_vfinal_shift = 20, // (vf) did the call resolve to a final method? > // low order bits give field index (for FieldInfo) or method parameter size: > field_index_bits = 16, > field_index_mask = right_n_bits(field_index_bits), > parameter_size_bits = 8, // subset of field_index_mask, range is 0..255 > parameter_size_mask = right_n_bits(parameter_size_bits), > - option_bits_mask = ~(((-1) << tos_state_shift) | (field_index_mask | parameter_size_mask)) > + option_bits_mask = ~(((~0u) << tos_state_shift) | (field_index_mask | parameter_size_mask)) > }; > > // specific bit definitions for the indices field: > enum { > cp_index_bits = 2*BitsPerByte, > cp_index_mask = right_n_bits(cp_index_bits), > bytecode_1_shift = cp_index_bits, > bytecode_1_mask = right_n_bits(BitsPerByte), // == (u1)0xFF From alexhenrie24 at gmail.com Tue May 24 22:52:20 2016 From: alexhenrie24 at gmail.com (Alex Henrie) Date: Tue, 24 May 2016 16:52:20 -0600 Subject: [PATCH] 8157758: Use (~0u) instead of (-1) when left-shifting Message-ID: # HG changeset patch # User ahenrie # Date 1464130244 21600 # Tue May 24 16:50:44 2016 -0600 # Node ID eb8bcb6a4c189276a9b718305565a6aad4d9285d # Parent 50b6bc2ac9e5ab3a249e0496a7718ab920a52a66 8157758: Use (~0u) instead of (-1) when left-shifting diff --git a/src/share/vm/code/dependencies.hpp b/src/share/vm/code/dependencies.hpp --- a/src/share/vm/code/dependencies.hpp +++ b/src/share/vm/code/dependencies.hpp @@ -163,17 +163,17 @@ class Dependencies: public ResourceObj { call_site_target_value, TYPE_LIMIT }; enum { LG2_TYPE_LIMIT = 4, // assert(TYPE_LIMIT <= (1< References: <570F53B1.90809@oracle.com> Message-ID: <0d89333b-8534-ae3c-ee85-86c5ab3e85d9@oracle.com> > Testing: > Altered the nsk.jvmti co-located test nsk/jvmti/ClassFileLoadHook/classfloadhk002 > to enable the can_generate_early_class_hook_events and checked that new CFLH events > are posted in the primordial phase and also they are not posted otherwise. Sorry for looping back on this... I've been re-reading this thread off and on for a while now... I'm okay with this part of the testing statement: > checked that new CFLH events are posted in the primordial phase but this part bothers me: > and also they are not posted otherwise I'm not sure what that last part means exactly. I think it might be saying that there are certain CFLH events that the test expects to be posted in the primordial phase and the test verifies that those CFLH events are posted in the primordial phase and not in the next phase (the start phase). I'm hoping that the testable assertion is more clear than the above text. One other possible issue: if the primordial phase is still single threaded, then there is no race between a thread doing this early class loading (and posting of the CFLH events) and the thread that is changing the JVM/TI phase from "primordial phase" to "start phase". However, if the primordial phase is now multi-threaded, then there might be a race between the thread posting the CFLH event and JVM/TI phase switch... Dan On 4/14/16 2:24 AM, serguei.spitsyn at oracle.com wrote: > Please, review the Jigsaw-related fix for: > https://bugs.openjdk.java.net/browse/JDK-8153749 > > > Hotspot webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8153749-Jigsaw-newcap.hs1/ > > > Jdk webrev: > http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/jdk/8153749-Jigsaw-newcap.jdk1/ > > > > Summary: > > This is a Jigsaw related enhancement. > Some agents need to get a CFLH event for classes loaded in the > primordial phase. > This is not possible in JDK 9 because existing agents may > instrument code in the > primordial or start phase before the module system has completed > initialization. > > We introduce a new capability: can_generate_early_class_hook_events. > If this capability and can_generate_all_class_hook_events are > enabled then > the CFLH event could be posted for classes loaded in the primordial > phase. > We leave can_generate_early_vmstart as is, no changes. > > This enhancement needs a CCC request filed. > I will file it once the JVMTI spec changes are reviewed. > > > Testing: > Altered the nsk.jvmti co-located test > nsk/jvmti/ClassFileLoadHook/classfloadhk002 > to enable the can_generate_early_class_hook_events and checked that > new CFLH events > are posted in the primordial phase and also they are not posted > otherwise. > > > Thanks, > Serguei > From david.holmes at oracle.com Tue May 24 23:29:49 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 25 May 2016 09:29:49 +1000 Subject: Atomic::add(jlong) broken? In-Reply-To: <56B19ADA.8030406@oracle.com> References: <1454446535.3676.17.camel@redhat.com> <56B19ADA.8030406@oracle.com> Message-ID: <05ed439c-12f6-5590-77f8-55a22de175cc@oracle.com> Following up ... On 3/02/2016 4:14 PM, David Holmes wrote: > On 3/02/2016 6:55 AM, Roman Kennke wrote: >> Hello, >> >> I believe Atomic::add(jlong) is broken. The comment above it says: >> >> // Atomically add to a location, return updated value >> >> Except in atomic.cpp, add(jlong) returns the old value. > > Yes that seems broken. > >> It causes quite some headscratching on my side :-) >> >> Fixing this seems easy. I am wonder if any code uses this though, maybe >> it should be removed altogether? > > It was added here: > > http://hg.openjdk.java.net/jdk8/jdk8/hotspot//rev/2a241e764894 > > for the GC log file rotation code back in 2011. But then removed here: > > http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/0598674c0056 > > because it was unnecessary and because of the missing Atomic:load(jlong) > support it required. > > I think it can be deleted now and probably should be. Note when I say "removed here" I meant its use was removed. Unfortunately at some point memoryTracker.hpp also started to use it, but we can fix that too and this will be handled under: https://bugs.openjdk.java.net/browse/JDK-8157709 David ----- >> On the other hand, the implementation there uses a CAS-based loop. I >> think an easier fix would be to cast to size_t or intptr_t and use the >> atomic impl of that. >> >> What do you think? > > Delete it. > > Thanks, > David > >> Roman >> From serguei.spitsyn at oracle.com Wed May 25 00:03:18 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 24 May 2016 17:03:18 -0700 Subject: RFR: 8153749 - New capability can_generate_early_class_hook_events In-Reply-To: <0d89333b-8534-ae3c-ee85-86c5ab3e85d9@oracle.com> References: <570F53B1.90809@oracle.com> <0d89333b-8534-ae3c-ee85-86c5ab3e85d9@oracle.com> Message-ID: <5744EBC6.9070105@oracle.com> On 5/24/16 16:23, Daniel D. Daugherty wrote: > > Testing: > > Altered the nsk.jvmti co-located test > nsk/jvmti/ClassFileLoadHook/classfloadhk002 > > to enable the can_generate_early_class_hook_events and checked > that new CFLH events > > are posted in the primordial phase and also they are not posted > otherwise. > > Sorry for looping back on this... > > I've been re-reading this thread off and on for a while now... > > I'm okay with this part of the testing statement: > > > checked that new CFLH events are posted in the primordial phase > > but this part bothers me: > > > and also they are not posted otherwise > > I'm not sure what that last part means exactly. I think it might > be saying that there are certain CFLH events that the test expects > to be posted in the primordial phase and the test verifies that > those CFLH events are posted in the primordial phase and not in > the next phase (the start phase). I'm hoping that the testable > assertion is more clear than the above text. Dan, sorry that my statement above is not clear. The 'otherwise' means the same test but unaltered. Unaltered test does not enable new capability and so, the CFLH events should not be posted in the primordial phase. > > One other possible issue: if the primordial phase is still > single threaded, then there is no race between a thread doing > this early class loading (and posting of the CFLH events) and > the thread that is changing the JVM/TI phase from "primordial > phase" to "start phase". However, if the primordial phase is > now multi-threaded, then there might be a race between the > thread posting the CFLH event and JVM/TI phase switch... This is interesting observation, thanks. Why do you think the primordial thread is multi-threaded now? We have this kind of race problem in general, especially with the JVM/TI phase switch to the DEAD phase. The phase can be switched even in the middle of the event post. I'm currently looking at several bugs related to JVMTI_ERROR_WRONG_PHASE(112). This problem needs a good solution, at least to make the nightly testing stable. Thanks, Serguei > > Dan > > > On 4/14/16 2:24 AM, serguei.spitsyn at oracle.com wrote: >> Please, review the Jigsaw-related fix for: >> https://bugs.openjdk.java.net/browse/JDK-8153749 >> >> >> Hotspot webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8153749-Jigsaw-newcap.hs1/ >> >> >> Jdk webrev: >> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/jdk/8153749-Jigsaw-newcap.jdk1/ >> >> >> >> Summary: >> >> This is a Jigsaw related enhancement. >> Some agents need to get a CFLH event for classes loaded in the >> primordial phase. >> This is not possible in JDK 9 because existing agents may >> instrument code in the >> primordial or start phase before the module system has completed >> initialization. >> >> We introduce a new capability: can_generate_early_class_hook_events. >> If this capability and can_generate_all_class_hook_events are >> enabled then >> the CFLH event could be posted for classes loaded in the >> primordial phase. >> We leave can_generate_early_vmstart as is, no changes. >> >> This enhancement needs a CCC request filed. >> I will file it once the JVMTI spec changes are reviewed. >> >> >> Testing: >> Altered the nsk.jvmti co-located test >> nsk/jvmti/ClassFileLoadHook/classfloadhk002 >> to enable the can_generate_early_class_hook_events and checked >> that new CFLH events >> are posted in the primordial phase and also they are not posted >> otherwise. >> >> >> Thanks, >> Serguei >> > From daniel.daugherty at oracle.com Wed May 25 00:24:59 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 24 May 2016 18:24:59 -0600 Subject: RFR: 8153749 - New capability can_generate_early_class_hook_events In-Reply-To: <5744EBC6.9070105@oracle.com> References: <570F53B1.90809@oracle.com> <0d89333b-8534-ae3c-ee85-86c5ab3e85d9@oracle.com> <5744EBC6.9070105@oracle.com> Message-ID: On 5/24/16 6:03 PM, serguei.spitsyn at oracle.com wrote: > On 5/24/16 16:23, Daniel D. Daugherty wrote: >> > Testing: >> > Altered the nsk.jvmti co-located test >> nsk/jvmti/ClassFileLoadHook/classfloadhk002 >> > to enable the can_generate_early_class_hook_events and checked >> that new CFLH events >> > are posted in the primordial phase and also they are not posted >> otherwise. >> >> Sorry for looping back on this... >> >> I've been re-reading this thread off and on for a while now... >> >> I'm okay with this part of the testing statement: >> >> > checked that new CFLH events are posted in the primordial phase >> >> but this part bothers me: >> >> > and also they are not posted otherwise >> >> I'm not sure what that last part means exactly. I think it might >> be saying that there are certain CFLH events that the test expects >> to be posted in the primordial phase and the test verifies that >> those CFLH events are posted in the primordial phase and not in >> the next phase (the start phase). I'm hoping that the testable >> assertion is more clear than the above text. > > Dan, sorry that my statement above is not clear. > The 'otherwise' means the same test but unaltered. > Unaltered test does not enable new capability and so, the CFLH events > should not be posted in the primordial phase. Got it. I'm good with a test to verify that the older JVM/TI behavior works as expected along with a test for the newer behavior. > >> >> One other possible issue: if the primordial phase is still >> single threaded, then there is no race between a thread doing >> this early class loading (and posting of the CFLH events) and >> the thread that is changing the JVM/TI phase from "primordial >> phase" to "start phase". However, if the primordial phase is >> now multi-threaded, then there might be a race between the >> thread posting the CFLH event and JVM/TI phase switch... > > This is interesting observation, thanks. > Why do you think the primordial thread is multi-threaded now? I haven't been paying close attention to Jigsaw so I'm not sure if primordial phase is multi-threaded or not... > We have this kind of race problem in general, especially > with the JVM/TI phase switch to the DEAD phase. > The phase can be switched even in the middle of the event post. > I'm currently looking at several bugs related to > JVMTI_ERROR_WRONG_PHASE(112). > This problem needs a good solution, at least to make the nightly > testing stable. Yes, I'm well aware of that problem. I believe I've made a number of comments on various JVMTI_ERROR_WRONG_PHASE bugs over the years. It's going to need some sort of handshake to solve it. Much like the suspend/resume dance that we do on thread exit... We'll have to brainstorm on how to make things more robust... Dan > > > Thanks, > Serguei > > >> >> Dan >> >> >> On 4/14/16 2:24 AM, serguei.spitsyn at oracle.com wrote: >>> Please, review the Jigsaw-related fix for: >>> https://bugs.openjdk.java.net/browse/JDK-8153749 >>> >>> >>> Hotspot webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8153749-Jigsaw-newcap.hs1/ >>> >>> >>> Jdk webrev: >>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/jdk/8153749-Jigsaw-newcap.jdk1/ >>> >>> >>> >>> Summary: >>> >>> This is a Jigsaw related enhancement. >>> Some agents need to get a CFLH event for classes loaded in the >>> primordial phase. >>> This is not possible in JDK 9 because existing agents may >>> instrument code in the >>> primordial or start phase before the module system has completed >>> initialization. >>> >>> We introduce a new capability: can_generate_early_class_hook_events. >>> If this capability and can_generate_all_class_hook_events are >>> enabled then >>> the CFLH event could be posted for classes loaded in the >>> primordial phase. >>> We leave can_generate_early_vmstart as is, no changes. >>> >>> This enhancement needs a CCC request filed. >>> I will file it once the JVMTI spec changes are reviewed. >>> >>> >>> Testing: >>> Altered the nsk.jvmti co-located test >>> nsk/jvmti/ClassFileLoadHook/classfloadhk002 >>> to enable the can_generate_early_class_hook_events and checked >>> that new CFLH events >>> are posted in the primordial phase and also they are not posted >>> otherwise. >>> >>> >>> Thanks, >>> Serguei >>> >> > From serguei.spitsyn at oracle.com Wed May 25 01:09:20 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 24 May 2016 18:09:20 -0700 Subject: RFR: 8153749 - New capability can_generate_early_class_hook_events In-Reply-To: References: <570F53B1.90809@oracle.com> <0d89333b-8534-ae3c-ee85-86c5ab3e85d9@oracle.com> <5744EBC6.9070105@oracle.com> Message-ID: <5744FB40.1020708@oracle.com> On 5/24/16 17:24, Daniel D. Daugherty wrote: > On 5/24/16 6:03 PM, serguei.spitsyn at oracle.com wrote: >> On 5/24/16 16:23, Daniel D. Daugherty wrote: >>> > Testing: >>> > Altered the nsk.jvmti co-located test >>> nsk/jvmti/ClassFileLoadHook/classfloadhk002 >>> > to enable the can_generate_early_class_hook_events and checked >>> that new CFLH events >>> > are posted in the primordial phase and also they are not posted >>> otherwise. >>> >>> Sorry for looping back on this... >>> >>> I've been re-reading this thread off and on for a while now... >>> >>> I'm okay with this part of the testing statement: >>> >>> > checked that new CFLH events are posted in the primordial phase >>> >>> but this part bothers me: >>> >>> > and also they are not posted otherwise >>> >>> I'm not sure what that last part means exactly. I think it might >>> be saying that there are certain CFLH events that the test expects >>> to be posted in the primordial phase and the test verifies that >>> those CFLH events are posted in the primordial phase and not in >>> the next phase (the start phase). I'm hoping that the testable >>> assertion is more clear than the above text. >> >> Dan, sorry that my statement above is not clear. >> The 'otherwise' means the same test but unaltered. >> Unaltered test does not enable new capability and so, the CFLH events >> should not be posted in the primordial phase. > > Got it. I'm good with a test to verify that the older JVM/TI > behavior works as expected along with a test for the newer > behavior. > > >> >>> >>> One other possible issue: if the primordial phase is still >>> single threaded, then there is no race between a thread doing >>> this early class loading (and posting of the CFLH events) and >>> the thread that is changing the JVM/TI phase from "primordial >>> phase" to "start phase". However, if the primordial phase is >>> now multi-threaded, then there might be a race between the >>> thread posting the CFLH event and JVM/TI phase switch... >> >> This is interesting observation, thanks. >> Why do you think the primordial thread is multi-threaded now? > > I haven't been paying close attention to Jigsaw so I'm not sure > if primordial phase is multi-threaded or not... I can be wrong but ... My current understanding is that it is still single-threaded as I did not see any discussions or related changes in the code. > > >> We have this kind of race problem in general, especially >> with the JVM/TI phase switch to the DEAD phase. >> The phase can be switched even in the middle of the event post. >> I'm currently looking at several bugs related to >> JVMTI_ERROR_WRONG_PHASE(112). >> This problem needs a good solution, at least to make the nightly >> testing stable. > > Yes, I'm well aware of that problem. I believe I've made a number > of comments on various JVMTI_ERROR_WRONG_PHASE bugs over the years. > It's going to need some sort of handshake to solve it. Much like > the suspend/resume dance that we do on thread exit... > > We'll have to brainstorm on how to make things more robust... Great, thanks! I've already started thinking on this. :) Thanks, Serguei > > Dan > > >> >> >> Thanks, >> Serguei >> >> >>> >>> Dan >>> >>> >>> On 4/14/16 2:24 AM, serguei.spitsyn at oracle.com wrote: >>>> Please, review the Jigsaw-related fix for: >>>> https://bugs.openjdk.java.net/browse/JDK-8153749 >>>> >>>> >>>> Hotspot webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/hotspot/8153749-Jigsaw-newcap.hs1/ >>>> >>>> >>>> Jdk webrev: >>>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2016/jdk/8153749-Jigsaw-newcap.jdk1/ >>>> >>>> >>>> >>>> Summary: >>>> >>>> This is a Jigsaw related enhancement. >>>> Some agents need to get a CFLH event for classes loaded in the >>>> primordial phase. >>>> This is not possible in JDK 9 because existing agents may >>>> instrument code in the >>>> primordial or start phase before the module system has completed >>>> initialization. >>>> >>>> We introduce a new capability: >>>> can_generate_early_class_hook_events. >>>> If this capability and can_generate_all_class_hook_events are >>>> enabled then >>>> the CFLH event could be posted for classes loaded in the >>>> primordial phase. >>>> We leave can_generate_early_vmstart as is, no changes. >>>> >>>> This enhancement needs a CCC request filed. >>>> I will file it once the JVMTI spec changes are reviewed. >>>> >>>> >>>> Testing: >>>> Altered the nsk.jvmti co-located test >>>> nsk/jvmti/ClassFileLoadHook/classfloadhk002 >>>> to enable the can_generate_early_class_hook_events and checked >>>> that new CFLH events >>>> are posted in the primordial phase and also they are not posted >>>> otherwise. >>>> >>>> >>>> Thanks, >>>> Serguei >>>> >>> >> > From erik.helin at oracle.com Wed May 25 09:33:08 2016 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 25 May 2016 11:33:08 +0200 Subject: Submitted JEP 189: Shenandoah: An Ultra-Low-Pause-Time Garbage Collector In-Reply-To: <545560389.4790998.1464037461928.JavaMail.zimbra@redhat.com> References: <20160504075621.450403951eggemoggin.niobe.net> <729617618.2672396.1463148140398.JavaMail.zimbra@redhat.com> <20160516124402.GG32434@ehelin.jrpg.bea.com> <545560389.4790998.1464037461928.JavaMail.zimbra@redhat.com> Message-ID: <20160525093308.GB23701@ehelin.jrpg.bea.com> On 2016-05-23, Christine Flood wrote: > Hi > > I'm sorry I didn't respond sooner. Answers are inline. > > ----- Original Message ----- > > From: "Erik Helin" > > To: "Christine Flood" > > Cc: "mark reinhold" , hotspot-dev at openjdk.java.net > > Sent: Monday, May 16, 2016 8:44:02 AM > > Subject: Re: Submitted JEP 189: Shenandoah: An Ultra-Low-Pause-Time Garbage Collector > > > > I'm moving this thread to hotspot-dev since this JEP affects all of > > hotspot. I guess that the members from the runtime team and compiler > > team will want to comment on the changes to the interpreter, C1 and C2. > > > > On 2016-05-13, Christine Flood wrote: > > > OK, I've put together a pdf document which summarizes our changes. > > > > Thank you for writing this up. Will you incorporate most of this > > document into the JEP? > > Yes, I'm going to make a second pass over the document incorporating > all of the comments and answering any questions. Thanks! > > > > > I'm happy to go into more detail or answer questions. > > > > Reading through the document, I have a few initial high-level questions: > > - Which platforms does Shenandoah run on (CPUs/OSs)? Which platforms do > > you intend Shenandoah to run on? > > For now we are implementing it on 64 bit Intel and AARCH64. It doesn't make > very much sense for 32 bit architectures since their heaps are smaller. > > > - For the goal of the JEP, do you have any particular benchmark in mind > > for determining when you have reached the goal? You have stated less > > than 100 ms pauses on 100 GB, but variables such as allocation rate, > > live set, etc. also tend to affect the GC. It might be easier to > > determine that you have reached your goal if you have a specific setup > > (OS, CPU, RAM) and a specific benchmark in mind. > > I'm somewhat regretting the original 10ms on 100GB heaps goal. The reality > is that our pause times are proportional to the size of the thread stacks. > We are working on keeping them as small as possible but you are correct > that it's benchmark, OS, and CPU specific. > > The only concrete goal we have is for SpecJBB 2015. No worse than 10% decrease > in max j-ops (throughput) and significantly better critical j-ops (response time). 10% decrease in max j-ops compared to which configuration? ParallelGC? G1? A highly tuned G1? > > - When you state "most" GCs will be below 100 ms, do you have any number > > in mind? 99% of all GCs? 99.9%? I have another question related to this: what will Shenandoah do when it can't keep up? What happens if the concurrent copying can't free enough memory in time (because the allocation rate is too high)? A full GC? > > - Who will maintain the Shenadoah code? > > Red Hat will maintain the Shenandoah code. Ok, then I would like you to make sure that compiling the Shenandoah code is controlled with a configure variable, similar to jvmci, shark, dtrace, vm-structs, etc: sh configure --with-jvm-features=shenandoah > > Reading through the JEP, I noticed the line "...as opposed to G1 which > > focuses on young generation collection to help limit remembered-set > > size." The main reason for the young collections in G1 is to improve > > throughput, not to limit the size of the remembered sets. If an > > application follows the generational hypothesis, then a young generation > > can be quite a boost to throughput. We still have a remembered set per > > young region, but it only keeps track of pointers from old regions to > > young regions (not pointers between young regions). Would you please > > remove this statement from the JEP? > > I will fix the comment. I didn't mean to imply that young generation collections > were only about remembered set overhead, I just meant to say that not keeping track > of young to old pointers aids in keeping remembered set sizes manageable. The initial > (non-generational) G1 implementation had embarrassingly large remembered sets. Sure, I understand. And yes, not keeping track of young to young pointers reduces the size of the rem sets, but the main purpose of the young gen is to increase throughput. > Thank you for your thoughtful comments. Thanks, Erik > Christine > From aph at redhat.com Wed May 25 10:12:20 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 25 May 2016 11:12:20 +0100 Subject: x86: StrIndexOfChar and UseSSE Message-ID: <57457A84.9050007@redhat.com> In x86.ad we have: const bool Matcher::match_rule_supported(int opcode) { if (!has_match_rule(opcode)) return false; bool ret_value = true; switch (opcode) { ... case Op_StrIndexOfChar: if (!(UseSSE > 4)) ret_value = false; break; ... } return ret_value; // Per default match rules are supported. } So we won't use the StrIndexOfChar intrinsic unless UseSSE > 4. In vm_version_x86.cpp we have: // UseSSE is set to the smaller of what hardware supports and what // the command line requires. I.e., you cannot set UseSSE to 2 on // older Pentiums which do not support it. if (UseSSE > 4) UseSSE=4; So, UseSSE can never be > 4. So we will never use the StrIndexOfChar intrinsic. What gives? What is the intrinsic for? Andrew. From tobias.hartmann at oracle.com Wed May 25 12:43:46 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 25 May 2016 14:43:46 +0200 Subject: [9] RFR(S): 8156760: VM crashes if -XX:-ReduceInitialCardMarks is set In-Reply-To: <1464100391.10697.5.camel@oracle.com> References: <5742CC7F.4050309@oracle.com> <88436ef0-e133-843c-3183-db310edc7148@oracle.com> <574416D2.9080803@oracle.com> <1464074030.4740.15.camel@oracle.com> <57441E34.5030101@oracle.com> <57442FDC.1050603@oracle.com> <57443C9B.3070601@oracle.com> <1464100391.10697.5.camel@oracle.com> Message-ID: <57459E02.5030404@oracle.com> Hi Thomas, On 24.05.2016 16:33, Thomas Schatzl wrote: > Hi Tobias, > > On Di, 2016-05-24 at 13:35 +0200, Tobias Hartmann wrote: >> Hi Thomas, >> >> [putting hotspot-dev back on CC] >> > > sorry for messing up this... > >> On 24.05.2016 12:41, thomas schatzl wrote: >>> Hi, >>> >>> On 24.05.2016 11:26, Tobias Hartmann wrote: >>>> Hi Thomas, >>> >>>> >>>> thanks for looking at this! >>>> >>>> On 24.05.2016 09:13, Thomas Schatzl wrote: >>>>> Hi Tobias, >>>>> >>>>> On Di, 2016-05-24 at 10:54 +0200, Tobias Hartmann wrote: >>>>>> Hi Dean, >>> [...] >>>>>> Thanks for the feedback! From reading the G1 code, I assumed that a >>>>>> newly allocated object is always in Eden. Looking at the code again, >>>>>> I'm not sure what happens if the Eden space is full. If allocations >>>>>> may happen in the old generation as well, we need a runtime check for >>>>>> the card value. I don't think we have an assert/verification that >>>>>> checks this. >>>>>> >>>>>> Could someone from GC please verify this? >>>>> >>>>> all "small" object allocations go into eden. >>>>> >>>>> If eden is exhausted, we either issue a GC, or if we can't, expand eden. >>>>> >>>>> The only exceptions are large objects ("humongous", > half a region >>>>> size). These always go into old gen directly. >>>> >>>> Okay, then we need to check the card value for the object to determine >>>> if it is "humongous" and allocated in the old generation. If so, we need >>>> to emit a post-write barrier. >>> >>> Humongous allocations always go through the runtime. I do not think the >>> compiler needs to emit code for this case. >> >> Okay, but isn't this only the case if ReduceInitialCardMarks is enabled? >> >> See this comment in library_call.cpp: >> >> // (We can dispense with card marks if we know the allocation >> // comes out of eden (TLAB)... In fact, ReduceInitialCardMarks >> // causes the non-eden paths to take compensating steps to >> // simulate a fresh allocation, so that no further >> // card marks are required in compiled code to initialize >> // the object.) >> >> Looking at the comments around CollectedHeap::can_elide_tlab_store_barriers(), >> it seems that the compiler has to notify the runtime when eliding card-marks. >> The question is if compiled code that emits an AllocateNode can rely on the >> runtime taking such compensating steps even if ReduceInitialCardMarks is >> *disabled*? Because I think in this case, the compiler does not notify the >> runtime. >> >> If not, the compiler needs to emit card marks if the object is not in eden, >> right? > > Okay, I think I got it. Yes, in case ReduceInitialCardMarks is false, > the compiler needs to emit the card marks for humongous object > allocations. Okay, thanks for clarifying. I'll send out a new webrev soon. Best regards, Tobias > > Thanks, > Thomas > > From edward.nevill at gmail.com Wed May 25 13:41:16 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Wed, 25 May 2016 14:41:16 +0100 Subject: RFR: 8157841: aarch64: prefetch ignores cache line size Message-ID: <1464183676.30703.23.camel@mylittlepony.linaroharston> Hi, Please review the following webrev http://cr.openjdk.java.net/~enevill/8157841/webrev The aarch64 implementation ignores the actual dcache line size and sets the various prefetch variables based on an assumed cache line size of 64. One of our partners has a cache line size of 128. The above patch reads the cache line size from the ctr_el0 register and sets the prefetch variables based on multiples of that instead. Regards, Ed. From tobias.hartmann at oracle.com Wed May 25 13:53:40 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 25 May 2016 15:53:40 +0200 Subject: x86: StrIndexOfChar and UseSSE In-Reply-To: <57457A84.9050007@redhat.com> References: <57457A84.9050007@redhat.com> Message-ID: <5745AE64.5080300@oracle.com> Hi Andrew, On 25.05.2016 12:12, Andrew Haley wrote: > In x86.ad we have: > > const bool Matcher::match_rule_supported(int opcode) { > if (!has_match_rule(opcode)) > return false; > > bool ret_value = true; > switch (opcode) { > ... > > case Op_StrIndexOfChar: > if (!(UseSSE > 4)) > ret_value = false; > break; > > ... > } > > return ret_value; // Per default match rules are supported. > } > > So we won't use the StrIndexOfChar intrinsic unless UseSSE > 4. > > In vm_version_x86.cpp we have: > > // UseSSE is set to the smaller of what hardware supports and what > // the command line requires. I.e., you cannot set UseSSE to 2 on > // older Pentiums which do not support it. > if (UseSSE > 4) UseSSE=4; > > So, UseSSE can never be > 4. So we will never use the StrIndexOfChar > intrinsic. > > What gives? What is the intrinsic for? Thanks for reporting this! Yes, as in MacroAssembler::string_indexof_char() this should be UseSSE >= 4. Not sure how this slipped through unnoticed. I filed JDK-8157842 [1] and will take care of it. Thanks, Tobias [1] https://bugs.openjdk.java.net/browse/JDK-8157842 > > Andrew. > From edward.nevill at gmail.com Wed May 25 15:16:55 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Wed, 25 May 2016 16:16:55 +0100 Subject: RFR: 8157834: aarch64: Hello World crashes with fastdebug build Message-ID: <1464189415.2400.4.camel@mylittlepony.linaroharston> Hi, Please review the following webrev http://cr.openjdk.java.net/~enevill/8157834/webrev/ jira issue: https://bugs.openjdk.java.net/browse/JDK-8157834 This crash is caused by StrIndexOf being called with argument encoding != UU even though CompactStrings is disabled. Fix is to implement LL, UL and LU encodings for StrIndexOf. All the best, Ed. From tobias.hartmann at oracle.com Wed May 25 15:40:12 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 25 May 2016 17:40:12 +0200 Subject: [9] RFR(S): 8156760: VM crashes if -XX:-ReduceInitialCardMarks is set In-Reply-To: <5742CC7F.4050309@oracle.com> References: <5742CC7F.4050309@oracle.com> Message-ID: <5745C75C.80208@oracle.com> Hi, On 23.05.2016 11:25, Tobias Hartmann wrote: > Hi, > > please review the following patch: > > https://bugs.openjdk.java.net/browse/JDK-8156760 > http://cr.openjdk.java.net/~thartmann/8156760/webrev.00/ > > While working on JDK-8155643, I found several problems when running tests with -XX:-ReduceInitialCardMarks: > > Problem 1: > C2 crashes with "missing G1 post barrier" while trying to eliminate the card mark emitted by the Object.clone() intrinsic (after removing the allocation of the destination object) [1]. The problem is that the shape of the card mark code is different for the Object.clone() intrinsic because we don't emit any checks (see [4]). However, PhaseMacroExpand::eliminate_card_mark() tries to find and collapse a region check. Usually, this is not a problem because with ReduceInitialCardMarks we don't emit a post barrier for Object.clone(). > > Problem 2: > The VM crashes during GC verification in G1SATBCardTableModRefBS::verify_g1_young_region() with "there should not have been any failures" because we expect cards for the young generation to be always set to 'g1_young_gen' [2]: > > [1.478s][error][gc,verify] == CT verification failed: [0x00007f097c167800,0x00007f097c167fff] > [1.478s][error][gc,verify] == expecting value: 32 > [1.478s][error][gc,verify] == card 0x00007f097c167800 [0x00000006d8900000,0x00000006d8900200], val: 0 > [1.478s][error][gc,verify] == card 0x00007f097c167801 [0x00000006d8900200,0x00000006d8900400], val: 0 > ... > > With !ReduceInitialCardMarks, the Object.clone() intrinsic emits card marks that set the cards of the newly allocated destination object to 'dirty' (!= 'g1_young_gen') and thus causing the verification to fail. > > I fixed problems 1 and 2 by removing the card marking code for the Object.clone() intrinsic with G1. This should be fine because the destination object is always in Eden and we therefore don't need to mark the cards. As Dean and Thomas pointed out, if ReduceInitialCardsMarks is disabled, the GC relies on the compiler always emitting card marks after object allocation because very large objects may not be allocated in Eden. To fix problem 2, we need to add a runtime check for the card value to make sure that we only emit card marks if the object is 'humongous' and therefore allocated in the old generation. Problem 1 is fixed by adapting PhaseMacroExpand::eliminate_card_mark() to handle the graph shape of the card marking code for the Object.clone() intrinsic (we simply fold the new card value check). > Problem 3: > C2 crashes with SIGSEGV in ArrayCopyNode::prepare_array_copy() because we expect an array clone/copy and dereference 'src_type->isa_aryptr()' but actually have a non-array Object.clone() [3]. This is because with !ReduceInitialCardMarks, ArrayCopyNode::try_clone_instance() does not capture the Object.clone() intrinsic because we emit card marking code (we bail out in 'ArrayCopyNode::finish_transform()'). We continue assuming that the array copy is a non-instance copy. I added an additional check to bail out in this case. > > I changed 'TestInstanceCloneAsLoadsStores' to be also executed with -XX:-ReduceInitialCardMarks. This triggers problem 1 and 2. Problem 3 can be reproduced by running the modified test with XX:+UseConcMarkSweepGC. While testing, I found a 4th issue with -XX:-ReduceInitialCardMarks: TestEliminatedArrayCopyDeopt fails because the result of a read from an eliminated object allocation returns the wrong result after deoptimization. This is similar to JDK-8130847 but the problem is that the fix does not expect clones to write to objects that are allocated with card marks. As a result, the clone is treated as independent and not taken into account when eliminating the allocation of the destination object. I adapted ArrayCopyNode::may_modify() to skip card marks and correctly return the dependent clone ArrayCopyNode. Here is the new webrev: http://cr.openjdk.java.net/~thartmann/8156760/webrev.02/ I'll re-run the tests. Thanks, Tobias > Tested with failing tests, JPRT and RBT (running). > > Thanks, > Tobias > > [1] https://bugs.openjdk.java.net/secure/attachment/59410/hs_err_pid28313.log > [2] https://bugs.openjdk.java.net/secure/attachment/59661/hs_err_pid30301.log > [3] https://bugs.openjdk.java.net/secure/attachment/59660/hs_err_pid22570.log > [4] https://bugs.openjdk.java.net/secure/attachment/59564/graph.png > From joseph.provino at oracle.com Wed May 25 16:19:22 2016 From: joseph.provino at oracle.com (Joseph Provino) Date: Wed, 25 May 2016 12:19:22 -0400 Subject: RFR (S) JDK-8153578,Default NewRatio is ignored when UseConcMarkSweepGC is used as GC algorithm In-Reply-To: <571802CF.7010000@oracle.com> References: <5717C5A9.1060406@oracle.com> <5717D9ED.2070907@oracle.com> <571802CF.7010000@oracle.com> Message-ID: <5745D089.8090003@oracle.com> This is a simple change from MIN2 to MAX2 suggested by Jesper. The code now matches the comment and seems to fix the problem. Webrev: http://cr.openjdk.java.net/~jprovino/8153578/webrev.01 thanks. joe On 4/20/2016 6:29 PM, Jon Masamitsu wrote: > > > On 04/20/2016 12:35 PM, Jesper Wilhelmsson wrote: >> Hi Joe, >> >> If I understand the bug description correctly the problem is that >> NewSize becomes too small. According to the bug the VM ignores the >> NewRatio setting. >> >> Your change removes the setting of MaxNewSize in the case where >> NewSize has the default value. It's not obvious to me how that is >> related to the bug. >> >> There is an if statement enclosing the code you are changing. It has >> a comment that I find interesting: >> >> 1755 // If either MaxNewSize or NewRatio is set on the command line, >> 1756 // assume the user is trying to set the size of the young gen. >> 1757 if (FLAG_IS_DEFAULT(MaxNewSize) && FLAG_IS_DEFAULT(NewRatio)) { >> >> The interesting part is that the comment says "MaxNewSize OR >> NewRatio" but the code says "MaxNewSize AND NewRatio". This could be >> a typo in the comment, or it could be related to your bug. >> >> I don't think the fix here is to ignore the calculated >> preferred_max_new_size, but rather to figure out why it has the wrong >> value. preferred_max_new_size is calculated a few lines up, and it is >> based on NewRatio. The number of threads seems to be involved as >> well. Should it be? Usually things based on the number of threads >> tend to be wrong... > > The intent of this code was to control the young pause times by > limiting the size of > the young gen. The preferred size scaling with > > young_gen_per_worker * ParallelGCThreads > > was meant to take into account the fact you could have approximately the > same pauses with larger heaps as the number of GC workers increases. > I didn't add this code but I'm pretty sure it was added as a result of > customer interaction. > > Jon > >> >> 1748 MIN2(max_heap/(NewRatio+1), >> ScaleForWordSize(young_gen_per_worker * ParallelGCThreads)); >> >> young_gen_per_worker is CMSYoungGenPerWorker which defaults to things >> like 16M or 64M. ParallelGCThreads is usually just a handful, 8 on my >> machine. Since we take the smallest number of this thread based thing >> and the NewRatio calculation, I would guess the threads will limit >> the MaxNewSize quite a lot. I wonder if this isn't the bug you are >> looking for. It would make more sense to me if it was MAX of the two >> instead of MIN. You should probably consult whoever wrote this code. >> >> /Jesper >> >> >> Den 20/4/16 kl. 20:08, skrev Joseph Provino: >>> Please review this tiny change. It only affects ParNew. Are there any >>> unintended consequences? >>> >>> Passes JPRT. >>> >>> CR: JDK-8153578 Default NewRatio is ignored when UseConcMarkSweepGC >>> is used as >>> GC algorithm >>> >>> Webrev: http://cr.openjdk.java.net/~jprovino/8153578/webrev.00 >>> >>> > From edward.nevill at gmail.com Wed May 25 16:41:17 2016 From: edward.nevill at gmail.com (Edward Nevill) Date: Wed, 25 May 2016 17:41:17 +0100 Subject: Request for clarification: hs or hs-comp Message-ID: <1464194477.3492.9.camel@mylittlepony.linaroharston> Hi, Could someone please clarify which repo we should be pushing aarch64 compiler specific bug fixes to now that we are post FC. Should we continue pushing to hs-comp as before FC, or should we now be pushing to hs? Thanks, Ed. From jesper.wilhelmsson at oracle.com Wed May 25 16:44:36 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 25 May 2016 18:44:36 +0200 Subject: Request for clarification: hs or hs-comp In-Reply-To: <1464194477.3492.9.camel@mylittlepony.linaroharston> References: <1464194477.3492.9.camel@mylittlepony.linaroharston> Message-ID: <14bfc2cb-14be-c180-8094-e21abe3e2527@oracle.com> You can continue to push to hs-comp. Integrations are done between all repos in the same way as before FC. /Jesper Den 25/5/16 kl. 18:41, skrev Edward Nevill: > Hi, > > Could someone please clarify which repo we should be pushing aarch64 compiler specific bug fixes to now that we are post FC. > > Should we continue pushing to hs-comp as before FC, or should we now be pushing to hs? > > Thanks, > Ed. > > From vladimir.kozlov at oracle.com Wed May 25 16:58:56 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 25 May 2016 09:58:56 -0700 Subject: Request for clarification: hs or hs-comp In-Reply-To: <14bfc2cb-14be-c180-8094-e21abe3e2527@oracle.com> References: <1464194477.3492.9.camel@mylittlepony.linaroharston> <14bfc2cb-14be-c180-8094-e21abe3e2527@oracle.com> Message-ID: <8b680967-4244-6b81-2231-5628c0b743ab@oracle.com> You can continue push *Bugs* fixes (like 8157841 and 8157834) into hs-comp after FC. But you should wait with 'Enhancement' changes (like 8156943) until approval process is finalized. Thanks, Vladimir On 5/25/16 9:44 AM, Jesper Wilhelmsson wrote: > You can continue to push to hs-comp. Integrations are done between all repos in the same way as before FC. > /Jesper > > Den 25/5/16 kl. 18:41, skrev Edward Nevill: >> Hi, >> >> Could someone please clarify which repo we should be pushing aarch64 compiler specific bug fixes to now that we are >> post FC. >> >> Should we continue pushing to hs-comp as before FC, or should we now be pushing to hs? >> >> Thanks, >> Ed. >> >> From aph at redhat.com Wed May 25 17:01:24 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 25 May 2016 18:01:24 +0100 Subject: Request for clarification: hs or hs-comp In-Reply-To: <8b680967-4244-6b81-2231-5628c0b743ab@oracle.com> References: <1464194477.3492.9.camel@mylittlepony.linaroharston> <14bfc2cb-14be-c180-8094-e21abe3e2527@oracle.com> <8b680967-4244-6b81-2231-5628c0b743ab@oracle.com> Message-ID: <5745DA64.1060107@redhat.com> On 05/25/2016 05:58 PM, Vladimir Kozlov wrote: > But you should wait with 'Enhancement' changes (like 8156943) until approval process is finalized. Have you got any more info about the approval process? Thanks, Andrew. From jesper.wilhelmsson at oracle.com Wed May 25 17:12:17 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 25 May 2016 19:12:17 +0200 Subject: RFR (S) JDK-8153578,Default NewRatio is ignored when UseConcMarkSweepGC is used as GC algorithm In-Reply-To: <5745D089.8090003@oracle.com> References: <5717C5A9.1060406@oracle.com> <5717D9ED.2070907@oracle.com> <571802CF.7010000@oracle.com> <5745D089.8090003@oracle.com> Message-ID: <16244ead-6f88-dc3b-44d2-37173a47d482@oracle.com> The change looks good to me but you should verify with Jon that we are not breaking any customer assumptions by doing this change. /Jesper Den 25/5/16 kl. 18:19, skrev Joseph Provino: > This is a simple change from MIN2 to MAX2 suggested by Jesper. > The code now matches the comment and seems to fix the problem. > > Webrev: http://cr.openjdk.java.net/~jprovino/8153578/webrev.01 > > thanks. > > joe > > On 4/20/2016 6:29 PM, Jon Masamitsu wrote: >> >> >> On 04/20/2016 12:35 PM, Jesper Wilhelmsson wrote: >>> Hi Joe, >>> >>> If I understand the bug description correctly the problem is that NewSize >>> becomes too small. According to the bug the VM ignores the NewRatio setting. >>> >>> Your change removes the setting of MaxNewSize in the case where NewSize has >>> the default value. It's not obvious to me how that is related to the bug. >>> >>> There is an if statement enclosing the code you are changing. It has a >>> comment that I find interesting: >>> >>> 1755 // If either MaxNewSize or NewRatio is set on the command line, >>> 1756 // assume the user is trying to set the size of the young gen. >>> 1757 if (FLAG_IS_DEFAULT(MaxNewSize) && FLAG_IS_DEFAULT(NewRatio)) { >>> >>> The interesting part is that the comment says "MaxNewSize OR NewRatio" but >>> the code says "MaxNewSize AND NewRatio". This could be a typo in the comment, >>> or it could be related to your bug. >>> >>> I don't think the fix here is to ignore the calculated >>> preferred_max_new_size, but rather to figure out why it has the wrong value. >>> preferred_max_new_size is calculated a few lines up, and it is based on >>> NewRatio. The number of threads seems to be involved as well. Should it be? >>> Usually things based on the number of threads tend to be wrong... >> >> The intent of this code was to control the young pause times by limiting the >> size of >> the young gen. The preferred size scaling with >> >> young_gen_per_worker * ParallelGCThreads >> >> was meant to take into account the fact you could have approximately the >> same pauses with larger heaps as the number of GC workers increases. >> I didn't add this code but I'm pretty sure it was added as a result of >> customer interaction. >> >> Jon >> >>> >>> 1748 MIN2(max_heap/(NewRatio+1), ScaleForWordSize(young_gen_per_worker * >>> ParallelGCThreads)); >>> >>> young_gen_per_worker is CMSYoungGenPerWorker which defaults to things like >>> 16M or 64M. ParallelGCThreads is usually just a handful, 8 on my machine. >>> Since we take the smallest number of this thread based thing and the NewRatio >>> calculation, I would guess the threads will limit the MaxNewSize quite a lot. >>> I wonder if this isn't the bug you are looking for. It would make more sense >>> to me if it was MAX of the two instead of MIN. You should probably consult >>> whoever wrote this code. >>> >>> /Jesper >>> >>> >>> Den 20/4/16 kl. 20:08, skrev Joseph Provino: >>>> Please review this tiny change. It only affects ParNew. Are there any >>>> unintended consequences? >>>> >>>> Passes JPRT. >>>> >>>> CR: JDK-8153578 Default NewRatio is ignored when UseConcMarkSweepGC is used as >>>> GC algorithm >>>> >>>> Webrev: http://cr.openjdk.java.net/~jprovino/8153578/webrev.00 >>>> >>>> >> > From vladimir.kozlov at oracle.com Wed May 25 17:20:02 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 25 May 2016 10:20:02 -0700 Subject: Request for clarification: hs or hs-comp In-Reply-To: <5745DA64.1060107@redhat.com> References: <1464194477.3492.9.camel@mylittlepony.linaroharston> <14bfc2cb-14be-c180-8094-e21abe3e2527@oracle.com> <8b680967-4244-6b81-2231-5628c0b743ab@oracle.com> <5745DA64.1060107@redhat.com> Message-ID: <5c6a227f-a6fa-f7ce-a2d7-9ef7cae91b65@oracle.com> On 5/25/16 10:01 AM, Andrew Haley wrote: > On 05/25/2016 05:58 PM, Vladimir Kozlov wrote: >> But you should wait with 'Enhancement' changes (like 8156943) until approval process is finalized. > > Have you got any more info about the approval process? Not yet. Vladimir > > Thanks, > > Andrew. > From jlent at tivo.com Wed May 25 14:33:25 2016 From: jlent at tivo.com (James Lent) Date: Wed, 25 May 2016 10:33:25 -0400 Subject: Unexplained Jumps In Response Time "Fixed" By Disabling Tiered Compilation Message-ID: <5745B7B5.7040707@tivo.com> A few weeks ago I was assigned a production bug related to a sudden jump in response times for a service built on Solr-Lucene. A restart of the service would restore the normal response times for about 4 to 5 hours and then the response times would suddenly jump up again (often to a different level). I was able to recreate this issue dozens of times in a dev environment using a complete clone of the production environment (EC2 node types, configuration, etc). In the dev case the only traffic was a background warming query that ran once per minute. There was also some background core replication work. The warming query was expensive. It typically took about 2 seconds to run. After 4 to 5 hours it would suddenly jump to somewhere between 2.5 to 5 seconds and then hold steady at that new value for as long as I let it run (as much as 12 hours since I would sometimes restart the service at the end of the day and let it run overnight). In production this query would suddenly jump (along with the rest of the traffic) to a higher value and then hold steady at that new value for as long as one week before a restart temporarily fixed it. Two services running on two different nodes would typically jump to a different steady state value for the warming query. I tried attaching jprofiler, but, as soon as the tool instrumented the code (and before actually running it) the transformation of the classes would "fix" the problem. When I ran jprofiler in sampling mode it just looked like "everything" was running slow. I tried manually instrumenting the code with only limited success (hot swapping in timing code at the high level). I pursued many avenues of investigation (application logs, heap, linux page cache) until I found: http://stackoverflow.com/questions/14876447/what-could-cause-global-tomcat-jvm-slowdown This post suggested bumping up Code Cache size: -XX:ReservedCodeCacheSize=256m We are running: openjdk version "1.8.0_91" OpenJDK Runtime Environment (build 1.8.0_91-b14) OpenJDK 64-Bit Server VM (build 25.91-b14, mixed mode) and by default (according to jconsole) we already have a very large Code Cache size (240m) and bumping it up to 256m had no impact on the issue. I monitored the Code Cache usage and noted that the problem seem to occur when Code Cache usage reached about 70m. This may not be important. I also played with increasing the initial Code Cache size, but, got very unstable results. The initial (pre-jump) steady state for the warming query varied a lot from restart to restart (it was like the "jump" occurred immediately): -XX:InitialCodeCacheSize=128m -XX:ReservedCodeCacheSize=256m Run Time(ms) 1 2197 2 2584 3 2365 4 2145 5 3202 6 5152 7 2218 8 4680 I then tried turning off Tiered Compilation (without changing the default Code Cache size) in dev and the problem went away. Of course it is hard to prove a negative. We are now testing in production with good results (over 40 hours of good performance). Any thoughts? I realize this is not much to go on, but, I thought I would report my issue just in case you get other reports like this and you start to see a pattern. ________________________________ This email and any attachments may contain confidential and privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments) by others is prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete this email and any attachments. No employee or agent of TiVo Inc. is authorized to conclude any binding agreement on behalf of TiVo Inc. by email. Binding agreements with TiVo Inc. may only be made by a signed written agreement. From max.ockner at oracle.com Thu May 26 18:07:43 2016 From: max.ockner at oracle.com (Max Ockner) Date: Thu, 26 May 2016 14:07:43 -0400 Subject: RFR: 8157490: null stream->source() no longer causes error with -Xlog:class+load Message-ID: <57473B6F.2010806@oracle.com> Hello, Please review this very small fix for class+load logging with modules. Bug: https://bugs.openjdk.java.net/browse/JDK-8157490 Webrev: http://cr.openjdk.java.net/~mockner/8157490/ Summary: The JCK test vm/jni/DefineClass/dfcl001/dfcl00101m1/dfcl00101m1 hit a SIGSEGV in the logging section at the end of ClassFileParser::fill_instance_klass(). With the addition of modules, this logging section now uses strlen(stream->source()) to compute some of the module related parameters that it needs. This SIGSEGV originated from the above line being executed with a null stream source. Tested with vm/jni/DefineClass/dfcl001/dfcl00101m1/dfcl00101m1 Thanks, Max From Leonid.Mesnik at oracle.com Thu May 26 19:00:27 2016 From: Leonid.Mesnik at oracle.com (Leonid Mesnik) Date: Thu, 26 May 2016 22:00:27 +0300 Subject: RFR(S): 8154209: Remove client VM from default JIB profile on windows-x86 and linux-x86 In-Reply-To: <571871E6.5050306@oracle.com> References: <570FC852.10808@oracle.com> <57149250.10008@oracle.com> <5717F77D.6080308@oracle.com> <571871E6.5050306@oracle.com> Message-ID: <574747CB.8000103@oracle.com> Dear All Please find updated webrev for this fix here: http://cr.openjdk.java.net/~lmesnik/8154209/webrev.00/hotspot/ http://cr.openjdk.java.net/~lmesnik/8154209/webrev.00/root/ The client jvm is removed from linux-x86 and windows-x86 profiles. The linux-x86 currently includes minimal and server VM. The server VM is used by default. The test targets has been updated to test server for this profiles. Leonid On 21.04.2016 09:23, Leonid Mesnik wrote: > Mikael > > On 21.04.2016 00:41, Mikael Vidstedt wrote: >> >> Good catch. Updated webrevs here: >> >> top: >> http://cr.openjdk.java.net/~mikael/webrevs/8154209/webrev.02/webrev/ > http://cr.openjdk.java.net/~mikael/webrevs/8154209/webrev.02/webrev/common/conf/jib-profiles.js.udiff.html > > > > Couldn't be > > *"--with-jvm-variants=client,server"* > > just completely removed now as for all 64bit profiles? > > http://cr.openjdk.java.net/~mikael/webrevs/8154209/webrev.02/webrev/make/jprt.properties.sdiff.html > > > > 213 windows_i586_6.3-product-c1-TESTNAME, \ > > I see that you just remove C1 testing. Wouldn't be better to replace > it with c2? (Same for line 298) > > Leonid >> hotspot: >> http://cr.openjdk.java.net/~mikael/webrevs/8154209/webrev.02/hotspot/webrev/ >> >> Incremental webrevs (from webrev.01): >> >> top: >> http://cr.openjdk.java.net/~mikael/webrevs/8154209/webrev.02.incr/webrev/ >> hotspot: N/A (same as webrev.01) >> >> Cheers, >> Mikael >> >> On 4/18/2016 12:52 AM, Leonid Mesnik wrote: >>> Hi >>> >>> >>> Shouldn't be jprt targets in jprt.properties updates to stop using >>> client also? >>> >>> http://hg.openjdk.java.net/jdk9/hs/file/645c48292130/make/jprt.properties >>> >>> >>> line 206 - 214 >>> # Test target list (no fastdebug & limited c2 testing) >>> my.test.target.set= \ >>> solaris_sparcv9_5.11-product-c2-TESTNAME, \ >>> solaris_x64_5.11-product-c2-TESTNAME, \ >>> linux_i586_3.8-product-{c1|c2}-TESTNAME, \ >>> linux_x64_3.8-product-c2-TESTNAME, \ >>> macosx_x64_10.9-product-c2-TESTNAME, \ >>> windows_i586_6.3-product-c1-TESTNAME, \ >>> windows_x64_6.3-product-c2-TESTNAME >>> >>> and >>> line 294-299 >>> # JCK test targets in test/Makefile (no windows) >>> my.test.target.set.jck= \ >>> solaris_sparcv9_5.11-product-c2-JCK7TESTRULE, \ >>> solaris_x64_5.11-product-c2-JCK7TESTRULE, \ >>> linux_i586_3.8-product-c1-JCK7TESTRULE, \ >>> linux_x64_3.8-product-c2-JCK7TESTRULE >>> >>> Leonid >>> >>> On 14.04.2016 19:41, Mikael Vidstedt wrote: >>>> >>>> Please review the following change which removes the "client" VM >>>> from the default JIB build profile on windows-x86 and linux-x86: >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8154209 >>>> Webrev (top): >>>> http://cr.openjdk.java.net/~mikael/webrevs/8154209/webrev.01/ >>>> Webrev (hotspot): >>>> http://cr.openjdk.java.net/~mikael/webrevs/8154209/webrev.01/hotspot/webrev/ >>>> >>>> >>>> When not including the client VM, the build system automatically >>>> creates a jvm.cfg which makes -client an alias for -server. At some >>>> point in the future we may choose to output a warning and/or refuse >>>> to start up if -client is specified, but at least for now silently >>>> falling back on the -server VM seems appropriate. >>>> >>>> The test/runtime/SharedArchiveFile/DefaultUseWithClient.java test >>>> assumes that CDS is always compiled in and enabled in the -client >>>> VM on windows-x86. Since -client will fall back on -server that is >>>> no longer true, so the test needs to be updated. I added an @ignore >>>> and filed the following issue to track fixing the test: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8154204 >>>> >>>> >>>> Testing: >>>> >>>> In addition to a standard JPRT push job, Christian Tornqvist helped >>>> me run the runtime nightly tests and apart from the above mentioned >>>> test all tests were successful. >>>> >>>> Cheers, >>>> Mikael >>>> >>> >> > From lois.foltan at oracle.com Thu May 26 19:12:49 2016 From: lois.foltan at oracle.com (Lois Foltan) Date: Thu, 26 May 2016 15:12:49 -0400 Subject: RFR: 8157490: null stream->source() no longer causes error with -Xlog:class+load In-Reply-To: <57473B6F.2010806@oracle.com> References: <57473B6F.2010806@oracle.com> Message-ID: <57474AB1.6030407@oracle.com> On 5/26/2016 2:07 PM, Max Ockner wrote: > Hello, > > Please review this very small fix for class+load logging with modules. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8157490 > Webrev: http://cr.openjdk.java.net/~mockner/8157490/ > > Summary: The JCK test > vm/jni/DefineClass/dfcl001/dfcl00101m1/dfcl00101m1 hit a SIGSEGV in > the logging section at the end of > ClassFileParser::fill_instance_klass(). With the addition of modules, > this logging section now uses > > strlen(stream->source()) > > to compute some of the module related parameters that it needs. This > SIGSEGV originated from the above line being executed with a null > stream source. Hi Max, I think you change is correct, but I would like to suggest changing the code even further. Currently the code between line #5352-5360 does a complicated check to see if the module's name is part of the java runtime image file and only sets the local variable "module_name" if it is. So, only module names that are defined within the java runtime image file are printed out in the logging. We should print out all modules' names, not just the ones in the jimage file. So please try removing lines #5352-5360 and set the local variable to: const char* module_name = (module_entry->name() == NULL) ? UNNAMED_MODULE : module_entry->name()->as_C_string(); The local variable "module_entry" is already checked at line #5310 to make sure it is set to a non-NULL value. Thanks, Lois > > Tested with vm/jni/DefineClass/dfcl001/dfcl00101m1/dfcl00101m1 > > Thanks, > Max From david.holmes at oracle.com Thu May 26 22:09:07 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 27 May 2016 08:09:07 +1000 Subject: RFR(S): 8154209: Remove client VM from default JIB profile on windows-x86 and linux-x86 In-Reply-To: <574747CB.8000103@oracle.com> References: <570FC852.10808@oracle.com> <57149250.10008@oracle.com> <5717F77D.6080308@oracle.com> <571871E6.5050306@oracle.com> <574747CB.8000103@oracle.com> Message-ID: <2fdb4a87-54e6-5fce-8feb-f093cb3f24d2@oracle.com> Hi Leonid, On 27/05/2016 5:00 AM, Leonid Mesnik wrote: > Dear All > > Please find updated webrev for this fix here: > http://cr.openjdk.java.net/~lmesnik/8154209/webrev.00/hotspot/ > > http://cr.openjdk.java.net/~lmesnik/8154209/webrev.00/root/ > > The client jvm is removed from linux-x86 and windows-x86 profiles. The > linux-x86 currently includes minimal and server VM. The server VM is > used by default. > The test targets has been updated to test server for this profiles. The changes look to do what they intended. However I have a couple of concerns. In places we are now testing with C2 on 32-bit rather than C1 - do we know how that might affect the test runs in terms of execution time and resource usage? I don't want to see a swag of new OOM failures or timeouts. I'm doubly concerned by the windows changes as we previously only focussed on client for 32-bit, and now we only do server. Thanks, David > Leonid > > On 21.04.2016 09:23, Leonid Mesnik wrote: >> Mikael >> >> On 21.04.2016 00:41, Mikael Vidstedt wrote: >>> >>> Good catch. Updated webrevs here: >>> >>> top: >>> http://cr.openjdk.java.net/~mikael/webrevs/8154209/webrev.02/webrev/ >> http://cr.openjdk.java.net/~mikael/webrevs/8154209/webrev.02/webrev/common/conf/jib-profiles.js.udiff.html >> >> >> >> Couldn't be >> >> *"--with-jvm-variants=client,server"* >> >> just completely removed now as for all 64bit profiles? >> >> http://cr.openjdk.java.net/~mikael/webrevs/8154209/webrev.02/webrev/make/jprt.properties.sdiff.html >> >> >> >> 213 windows_i586_6.3-product-c1-TESTNAME, \ >> >> I see that you just remove C1 testing. Wouldn't be better to replace >> it with c2? (Same for line 298) >> >> Leonid >>> hotspot: >>> http://cr.openjdk.java.net/~mikael/webrevs/8154209/webrev.02/hotspot/webrev/ >>> >>> >>> Incremental webrevs (from webrev.01): >>> >>> top: >>> http://cr.openjdk.java.net/~mikael/webrevs/8154209/webrev.02.incr/webrev/ >>> >>> hotspot: N/A (same as webrev.01) >>> >>> Cheers, >>> Mikael >>> >>> On 4/18/2016 12:52 AM, Leonid Mesnik wrote: >>>> Hi >>>> >>>> >>>> Shouldn't be jprt targets in jprt.properties updates to stop using >>>> client also? >>>> >>>> http://hg.openjdk.java.net/jdk9/hs/file/645c48292130/make/jprt.properties >>>> >>>> >>>> line 206 - 214 >>>> # Test target list (no fastdebug & limited c2 testing) >>>> my.test.target.set= \ >>>> solaris_sparcv9_5.11-product-c2-TESTNAME, \ >>>> solaris_x64_5.11-product-c2-TESTNAME, \ >>>> linux_i586_3.8-product-{c1|c2}-TESTNAME, \ >>>> linux_x64_3.8-product-c2-TESTNAME, \ >>>> macosx_x64_10.9-product-c2-TESTNAME, \ >>>> windows_i586_6.3-product-c1-TESTNAME, \ >>>> windows_x64_6.3-product-c2-TESTNAME >>>> >>>> and >>>> line 294-299 >>>> # JCK test targets in test/Makefile (no windows) >>>> my.test.target.set.jck= \ >>>> solaris_sparcv9_5.11-product-c2-JCK7TESTRULE, \ >>>> solaris_x64_5.11-product-c2-JCK7TESTRULE, \ >>>> linux_i586_3.8-product-c1-JCK7TESTRULE, \ >>>> linux_x64_3.8-product-c2-JCK7TESTRULE >>>> >>>> Leonid >>>> >>>> On 14.04.2016 19:41, Mikael Vidstedt wrote: >>>>> >>>>> Please review the following change which removes the "client" VM >>>>> from the default JIB build profile on windows-x86 and linux-x86: >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8154209 >>>>> Webrev (top): >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8154209/webrev.01/ >>>>> Webrev (hotspot): >>>>> http://cr.openjdk.java.net/~mikael/webrevs/8154209/webrev.01/hotspot/webrev/ >>>>> >>>>> >>>>> >>>>> When not including the client VM, the build system automatically >>>>> creates a jvm.cfg which makes -client an alias for -server. At some >>>>> point in the future we may choose to output a warning and/or refuse >>>>> to start up if -client is specified, but at least for now silently >>>>> falling back on the -server VM seems appropriate. >>>>> >>>>> The test/runtime/SharedArchiveFile/DefaultUseWithClient.java test >>>>> assumes that CDS is always compiled in and enabled in the -client >>>>> VM on windows-x86. Since -client will fall back on -server that is >>>>> no longer true, so the test needs to be updated. I added an @ignore >>>>> and filed the following issue to track fixing the test: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8154204 >>>>> >>>>> >>>>> Testing: >>>>> >>>>> In addition to a standard JPRT push job, Christian Tornqvist helped >>>>> me run the runtime nightly tests and apart from the above mentioned >>>>> test all tests were successful. >>>>> >>>>> Cheers, >>>>> Mikael >>>>> >>>> >>> >> > From adinn at redhat.com Fri May 27 09:39:36 2016 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 27 May 2016 10:39:36 +0100 Subject: Unexplained Jumps In Response Time "Fixed" By Disabling Tiered Compilation In-Reply-To: <5745B7B5.7040707@tivo.com> References: <5745B7B5.7040707@tivo.com> Message-ID: <574815D8.7050500@redhat.com> On 25/05/16 15:33, James Lent wrote: . . . > I then tried turning off Tiered Compilation (without changing the > default Code Cache size) in dev and the problem went away. Of course it > is hard to prove a negative. We are now testing in production with good > results (over 40 hours of good performance). > > Any thoughts? I realize this is not much to go on, but, I thought I > would report my issue just in case you get other reports like this and > you start to see a pattern. Have you tried turning on listing compiles with -XX:+PrintCompilation? It would be very interesting to see what sort of compile activity is going on around the time that the jumps in response times occur. A comparison between +TieredCompilation and -ToetredCompilation might be very informative. regards, Andrew Dinn ----------- From adinn at redhat.com Fri May 27 09:41:13 2016 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 27 May 2016 10:41:13 +0100 Subject: Unexplained Jumps In Response Time "Fixed" By Disabling Tiered Compilation In-Reply-To: <574815D8.7050500@redhat.com> References: <5745B7B5.7040707@tivo.com> <574815D8.7050500@redhat.com> Message-ID: <57481639.2040902@redhat.com> On 27/05/16 10:39, Andrew Dinn wrote: > On 25/05/16 15:33, James Lent wrote: > . . . >> I then tried turning off Tiered Compilation (without changing the >> default Code Cache size) in dev and the problem went away. Of course it >> is hard to prove a negative. We are now testing in production with good >> results (over 40 hours of good performance). >> >> Any thoughts? I realize this is not much to go on, but, I thought I >> would report my issue just in case you get other reports like this and >> you start to see a pattern. > > Have you tried turning on listing compiles with -XX:+PrintCompilation? > > It would be very interesting to see what sort of compile activity is > going on around the time that the jumps in response times occur. A > comparison between +TieredCompilation and -ToetredCompilation might be -Toetred? Hmm, I meant -Tiered of course :-) > very informative. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From aph at redhat.com Fri May 27 10:30:39 2016 From: aph at redhat.com (Andrew Haley) Date: Fri, 27 May 2016 11:30:39 +0100 Subject: Unexplained Jumps In Response Time "Fixed" By Disabling Tiered Compilation In-Reply-To: <5745B7B5.7040707@tivo.com> References: <5745B7B5.7040707@tivo.com> Message-ID: <574821CF.6020200@redhat.com> On 25/05/16 15:33, James Lent wrote: > Two services running on two different nodes would typically jump to a > different steady state value for the warming query. I tried attaching > jprofiler, but, as soon as the tool instrumented the code (and before > actually running it) the transformation of the classes would "fix" the > problem. When I ran jprofiler in sampling mode it just looked like > "everything" was running slow. I tried manually instrumenting the code > with only limited success (hot swapping in timing code at the high level). If you're running on Linux, operf (with the Java JIT code) is the tool of choice for profiling. Andrew. From aleksey.shipilev at oracle.com Fri May 27 13:52:02 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Fri, 27 May 2016 16:52:02 +0300 Subject: RFR (M) 8157726: VarHandles/Unsafe should support sub-word atomic ops [RESEND] Message-ID: <57485102.7030702@oracle.com> (Please note this work is covered with FC exception) (If you receive a previous version without [RESEND], please ignore) Hi, Please review the VarHandles/Unsafe support for sub-word atomic ops: https://bugs.openjdk.java.net/browse/JDK-8157726 Webrevs: http://cr.openjdk.java.net/~shade/8157726/webrev.hs.03/ http://cr.openjdk.java.net/~shade/8157726/webrev.jdk.03/ It *looks* like a lot of changes, but the bulk of changes are in tests, and the rest of product code is mostly duplicating the existing cases for the new code. Tour of the changes: Unsafe.java: *) Implements the baseline implementation for subword CASes, which does the CAS loop within an aligned integer word. While we could potentially detect 64-bit platform and do aligned long word instead, this complicates implementation for no reason. 32-bit CASes are ubiquitous. *) Provides the entry points for VarHandles implementation. While Unsafe provides the implementation for byte/short atomic ops only, it also provides the boolean/char versions that are trivially implementable with byte/short ops. While we could instead make VarHandles do this conversion, it proved harder to do this in VarHandle templates, rather than in Unsafe. *) Consistently uses weakCompareAndSetVolatile for CAS loops, in both new and old code, which is important for a fallback implementation to work well on non-x86 platforms. VarHandles*: *) Now mentions subword atomic ops are available in method spec. We have submitted CCC for this. *) VarHandle templates are slightly modified to do narrowing conversions for shorter-than-int types. This keeps us from putting the entire family of addAndGet methods to Unsafe. *) Test templates are changed to accommodate new code shapes, and also change the bit patterns we use to detect endianness issues. ----- everything above does functionally complete subword ops ---- -- ------- everything below is the key performance optimization ------- Platform-independent changes: *) vmSymbols.hpp, library_call.cpp and other changes: the usual set of scaffolding for Unsafe intrinsics. We reuse most of the infrastructure, adding new nodes/cases in the existing code. *) Unsafe tests are are changed to accommodate new code shapes, and also change the bit patterns we use to detect endianness issues. x86-specific changes: *) Full set of new x86_{32|64} intrinsics are provided in .ad files. Supporting 8-byte and 16-byte ops required introducing new operations in x86 assembler. These are tested by new compiler/unsafe tests. Performance data justifies the change, and highlights pitfalls: http://cr.openjdk.java.net/~shade/8157726/notes.txt Testing: eyeballing x86 assembly; targeted benchmarks; {java/lang/invoke/VarHandles, compiler/unsafe} tests on x86_{32|64}, POWER; RBT hs-comp-tier0. Thanks, -Aleksey From tobias.hartmann at oracle.com Mon May 30 07:23:40 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 30 May 2016 09:23:40 +0200 Subject: [9] RFR(S): 8156760: VM crashes if -XX:-ReduceInitialCardMarks is set In-Reply-To: <5745C75C.80208@oracle.com> References: <5742CC7F.4050309@oracle.com> <5745C75C.80208@oracle.com> Message-ID: <574BEA7C.3040000@oracle.com> Hi, all tests passed (link is attached to the bug). Is everyone fine with the latest webrev? http://cr.openjdk.java.net/~thartmann/8156760/webrev.02/ Thanks, Tobias On 25.05.2016 17:40, Tobias Hartmann wrote: > Hi, > > On 23.05.2016 11:25, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch: >> >> https://bugs.openjdk.java.net/browse/JDK-8156760 >> http://cr.openjdk.java.net/~thartmann/8156760/webrev.00/ >> >> While working on JDK-8155643, I found several problems when running tests with -XX:-ReduceInitialCardMarks: >> >> Problem 1: >> C2 crashes with "missing G1 post barrier" while trying to eliminate the card mark emitted by the Object.clone() intrinsic (after removing the allocation of the destination object) [1]. The problem is that the shape of the card mark code is different for the Object.clone() intrinsic because we don't emit any checks (see [4]). However, PhaseMacroExpand::eliminate_card_mark() tries to find and collapse a region check. Usually, this is not a problem because with ReduceInitialCardMarks we don't emit a post barrier for Object.clone(). >> >> Problem 2: >> The VM crashes during GC verification in G1SATBCardTableModRefBS::verify_g1_young_region() with "there should not have been any failures" because we expect cards for the young generation to be always set to 'g1_young_gen' [2]: >> >> [1.478s][error][gc,verify] == CT verification failed: [0x00007f097c167800,0x00007f097c167fff] >> [1.478s][error][gc,verify] == expecting value: 32 >> [1.478s][error][gc,verify] == card 0x00007f097c167800 [0x00000006d8900000,0x00000006d8900200], val: 0 >> [1.478s][error][gc,verify] == card 0x00007f097c167801 [0x00000006d8900200,0x00000006d8900400], val: 0 >> ... >> >> With !ReduceInitialCardMarks, the Object.clone() intrinsic emits card marks that set the cards of the newly allocated destination object to 'dirty' (!= 'g1_young_gen') and thus causing the verification to fail. >> >> I fixed problems 1 and 2 by removing the card marking code for the Object.clone() intrinsic with G1. This should be fine because the destination object is always in Eden and we therefore don't need to mark the cards. > > As Dean and Thomas pointed out, if ReduceInitialCardsMarks is disabled, the GC relies on the compiler always emitting card marks after object allocation because very large objects may not be allocated in Eden. To fix problem 2, we need to add a runtime check for the card value to make sure that we only emit card marks if the object is 'humongous' and therefore allocated in the old generation. > > Problem 1 is fixed by adapting PhaseMacroExpand::eliminate_card_mark() to handle the graph shape of the card marking code for the Object.clone() intrinsic (we simply fold the new card value check). > >> Problem 3: >> C2 crashes with SIGSEGV in ArrayCopyNode::prepare_array_copy() because we expect an array clone/copy and dereference 'src_type->isa_aryptr()' but actually have a non-array Object.clone() [3]. This is because with !ReduceInitialCardMarks, ArrayCopyNode::try_clone_instance() does not capture the Object.clone() intrinsic because we emit card marking code (we bail out in 'ArrayCopyNode::finish_transform()'). We continue assuming that the array copy is a non-instance copy. I added an additional check to bail out in this case. >> >> I changed 'TestInstanceCloneAsLoadsStores' to be also executed with -XX:-ReduceInitialCardMarks. This triggers problem 1 and 2. Problem 3 can be reproduced by running the modified test with XX:+UseConcMarkSweepGC. > > While testing, I found a 4th issue with -XX:-ReduceInitialCardMarks: > TestEliminatedArrayCopyDeopt fails because the result of a read from an eliminated object allocation returns the wrong result after deoptimization. This is similar to JDK-8130847 but the problem is that the fix does not expect clones to write to objects that are allocated with card marks. As a result, the clone is treated as independent and not taken into account when eliminating the allocation of the destination object. I adapted ArrayCopyNode::may_modify() to skip card marks and correctly return the dependent clone ArrayCopyNode. > > Here is the new webrev: > http://cr.openjdk.java.net/~thartmann/8156760/webrev.02/ > > I'll re-run the tests. > > Thanks, > Tobias > >> Tested with failing tests, JPRT and RBT (running). >> >> Thanks, >> Tobias >> >> [1] https://bugs.openjdk.java.net/secure/attachment/59410/hs_err_pid28313.log >> [2] https://bugs.openjdk.java.net/secure/attachment/59661/hs_err_pid30301.log >> [3] https://bugs.openjdk.java.net/secure/attachment/59660/hs_err_pid22570.log >> [4] https://bugs.openjdk.java.net/secure/attachment/59564/graph.png >> From paul.sandoz at oracle.com Mon May 30 09:37:01 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 30 May 2016 11:37:01 +0200 Subject: RFR (M) 8157726: VarHandles/Unsafe should support sub-word atomic ops [RESEND] In-Reply-To: <57485102.7030702@oracle.com> References: <57485102.7030702@oracle.com> Message-ID: <15C9035C-5FC5-4EDB-ADE3-F7240BB2E0B6@oracle.com> Hi, This looks good to me. Nice work, and done in a short time-frame. I like the fact that minimal changes were required to the VH implementations and tests, since it just a tweak to the relevant templates. Paul. > On 27 May 2016, at 15:52, Aleksey Shipilev wrote: > > (Please note this work is covered with FC exception) > > > (If you receive a previous version without [RESEND], please ignore) > > Hi, > > > > Please review the VarHandles/Unsafe support for sub-word atomic ops: > > https://bugs.openjdk.java.net/browse/JDK-8157726 > > > > Webrevs: > > http://cr.openjdk.java.net/~shade/8157726/webrev.hs.03/ > > http://cr.openjdk.java.net/~shade/8157726/webrev.jdk.03/ > > > > It *looks* like a lot of changes, but the bulk of changes are in tests, > and the rest of product code is mostly duplicating the existing cases > for the new code. > > > > Tour of the changes: > > > > Unsafe.java: > > > > *) Implements the baseline implementation for subword CASes, which > does the CAS loop within an aligned integer word. While we could > potentially detect 64-bit platform and do aligned long word instead, > this complicates implementation for no reason. 32-bit CASes are ubiquitous. > > > > *) Provides the entry points for VarHandles implementation. While > Unsafe provides the implementation for byte/short atomic ops only, it > also provides the boolean/char versions that are trivially implementable > with byte/short ops. While we could instead make VarHandles do this > conversion, it proved harder to do this in VarHandle templates, rather > than in Unsafe. > > > > *) Consistently uses weakCompareAndSetVolatile for CAS loops, in both > new and old code, which is important for a fallback implementation to > work well on non-x86 platforms. > > > > VarHandles*: > > > > *) Now mentions subword atomic ops are available in method spec. We > have submitted CCC for this. > > > *) VarHandle templates are slightly modified to do narrowing > conversions for shorter-than-int types. This keeps us from putting the > entire family of addAndGet methods to Unsafe. > > > > *) Test templates are changed to accommodate new code shapes, and also > change the bit patterns we use to detect endianness issues. > > > > ----- everything above does functionally complete subword ops ---- > -- > ------- everything below is the key performance optimization ------- > > > > Platform-independent changes: > > > > *) vmSymbols.hpp, library_call.cpp and other changes: the usual set of > scaffolding for Unsafe intrinsics. We reuse most of the infrastructure, > adding new nodes/cases in the existing code. > > > > *) Unsafe tests are are changed to accommodate new code shapes, and > also change the bit patterns we use to detect endianness issues. > > > > x86-specific changes: > > > > *) Full set of new x86_{32|64} intrinsics are provided in .ad files. > Supporting 8-byte and 16-byte ops required introducing new operations in > x86 assembler. These are tested by new compiler/unsafe tests. > > > > > > Performance data justifies the change, and highlights pitfalls: > > http://cr.openjdk.java.net/~shade/8157726/notes.txt > > > > > Testing: eyeballing x86 assembly; targeted benchmarks; > {java/lang/invoke/VarHandles, compiler/unsafe} tests on x86_{32|64}, > POWER; RBT hs-comp-tier0. > > > > Thanks, > > -Aleksey > From marcus at lagergren.net Mon May 30 10:11:39 2016 From: marcus at lagergren.net (Marcus Lagergren) Date: Mon, 30 May 2016 12:11:39 +0200 Subject: RFR (M) 8157726: VarHandles/Unsafe should support sub-word atomic ops [RESEND] In-Reply-To: <57485102.7030702@oracle.com> References: <57485102.7030702@oracle.com> Message-ID: <733F9D1A-94B1-40A1-9A0B-EF60FD31EDD0@lagergren.net> Looks good to me. +1 > On 27 May 2016, at 15:52, Aleksey Shipilev wrote: > > (Please note this work is covered with FC exception) > > > (If you receive a previous version without [RESEND], please ignore) > > Hi, > > > > Please review the VarHandles/Unsafe support for sub-word atomic ops: > > https://bugs.openjdk.java.net/browse/JDK-8157726 > > > > Webrevs: > > http://cr.openjdk.java.net/~shade/8157726/webrev.hs.03/ > > http://cr.openjdk.java.net/~shade/8157726/webrev.jdk.03/ > > > > It *looks* like a lot of changes, but the bulk of changes are in tests, > and the rest of product code is mostly duplicating the existing cases > for the new code. > > > > Tour of the changes: > > > > Unsafe.java: > > > > *) Implements the baseline implementation for subword CASes, which > does the CAS loop within an aligned integer word. While we could > potentially detect 64-bit platform and do aligned long word instead, > this complicates implementation for no reason. 32-bit CASes are ubiquitous. > > > > *) Provides the entry points for VarHandles implementation. While > Unsafe provides the implementation for byte/short atomic ops only, it > also provides the boolean/char versions that are trivially implementable > with byte/short ops. While we could instead make VarHandles do this > conversion, it proved harder to do this in VarHandle templates, rather > than in Unsafe. > > > > *) Consistently uses weakCompareAndSetVolatile for CAS loops, in both > new and old code, which is important for a fallback implementation to > work well on non-x86 platforms. > > > > VarHandles*: > > > > *) Now mentions subword atomic ops are available in method spec. We > have submitted CCC for this. > > > *) VarHandle templates are slightly modified to do narrowing > conversions for shorter-than-int types. This keeps us from putting the > entire family of addAndGet methods to Unsafe. > > > > *) Test templates are changed to accommodate new code shapes, and also > change the bit patterns we use to detect endianness issues. > > > > ----- everything above does functionally complete subword ops ---- > -- > ------- everything below is the key performance optimization ------- > > > > Platform-independent changes: > > > > *) vmSymbols.hpp, library_call.cpp and other changes: the usual set of > scaffolding for Unsafe intrinsics. We reuse most of the infrastructure, > adding new nodes/cases in the existing code. > > > > *) Unsafe tests are are changed to accommodate new code shapes, and > also change the bit patterns we use to detect endianness issues. > > > > x86-specific changes: > > > > *) Full set of new x86_{32|64} intrinsics are provided in .ad files. > Supporting 8-byte and 16-byte ops required introducing new operations in > x86 assembler. These are tested by new compiler/unsafe tests. > > > > > > Performance data justifies the change, and highlights pitfalls: > > http://cr.openjdk.java.net/~shade/8157726/notes.txt > > > > > Testing: eyeballing x86 assembly; targeted benchmarks; > {java/lang/invoke/VarHandles, compiler/unsafe} tests on x86_{32|64}, > POWER; RBT hs-comp-tier0. > > > > Thanks, > > -Aleksey > From vladimir.x.ivanov at oracle.com Mon May 30 10:32:23 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 30 May 2016 13:32:23 +0300 Subject: RFR (M) 8157726: VarHandles/Unsafe should support sub-word atomic ops [RESEND] In-Reply-To: <57485102.7030702@oracle.com> References: <57485102.7030702@oracle.com> Message-ID: Looks good. src/share/vm/opto/c2compiler.cpp: + case vmIntrinsics::_weakCompareAndSwapObjectVolatile: + case vmIntrinsics::_weakCompareAndSwapLongVolatile: + case vmIntrinsics::_weakCompareAndSwapIntVolatile: Was it overlooked in one of previous VH-related changes? Best regards, Vladimir Ivanov On 5/27/16 4:52 PM, Aleksey Shipilev wrote: > (Please note this work is covered with FC exception) > > > (If you receive a previous version without [RESEND], please ignore) > > Hi, > > > > Please review the VarHandles/Unsafe support for sub-word atomic ops: > > https://bugs.openjdk.java.net/browse/JDK-8157726 > > > > Webrevs: > > http://cr.openjdk.java.net/~shade/8157726/webrev.hs.03/ > > http://cr.openjdk.java.net/~shade/8157726/webrev.jdk.03/ > > > > It *looks* like a lot of changes, but the bulk of changes are in tests, > and the rest of product code is mostly duplicating the existing cases > for the new code. > > > > Tour of the changes: > > > > Unsafe.java: > > > > *) Implements the baseline implementation for subword CASes, which > does the CAS loop within an aligned integer word. While we could > potentially detect 64-bit platform and do aligned long word instead, > this complicates implementation for no reason. 32-bit CASes are ubiquitous. > > > > *) Provides the entry points for VarHandles implementation. While > Unsafe provides the implementation for byte/short atomic ops only, it > also provides the boolean/char versions that are trivially implementable > with byte/short ops. While we could instead make VarHandles do this > conversion, it proved harder to do this in VarHandle templates, rather > than in Unsafe. > > > > *) Consistently uses weakCompareAndSetVolatile for CAS loops, in both > new and old code, which is important for a fallback implementation to > work well on non-x86 platforms. > > > > VarHandles*: > > > > *) Now mentions subword atomic ops are available in method spec. We > have submitted CCC for this. > > > *) VarHandle templates are slightly modified to do narrowing > conversions for shorter-than-int types. This keeps us from putting the > entire family of addAndGet methods to Unsafe. > > > > *) Test templates are changed to accommodate new code shapes, and also > change the bit patterns we use to detect endianness issues. > > > > ----- everything above does functionally complete subword ops ---- > -- > ------- everything below is the key performance optimization ------- > > > > Platform-independent changes: > > > > *) vmSymbols.hpp, library_call.cpp and other changes: the usual set of > scaffolding for Unsafe intrinsics. We reuse most of the infrastructure, > adding new nodes/cases in the existing code. > > > > *) Unsafe tests are are changed to accommodate new code shapes, and > also change the bit patterns we use to detect endianness issues. > > > > x86-specific changes: > > > > *) Full set of new x86_{32|64} intrinsics are provided in .ad files. > Supporting 8-byte and 16-byte ops required introducing new operations in > x86 assembler. These are tested by new compiler/unsafe tests. > > > > > > Performance data justifies the change, and highlights pitfalls: > > http://cr.openjdk.java.net/~shade/8157726/notes.txt > > > > > Testing: eyeballing x86 assembly; targeted benchmarks; > {java/lang/invoke/VarHandles, compiler/unsafe} tests on x86_{32|64}, > POWER; RBT hs-comp-tier0. > > > > Thanks, > > -Aleksey > From aleksey.shipilev at oracle.com Mon May 30 10:38:46 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 30 May 2016 13:38:46 +0300 Subject: RFR (M) 8157726: VarHandles/Unsafe should support sub-word atomic ops [RESEND] In-Reply-To: References: <57485102.7030702@oracle.com> Message-ID: <574C1836.5050405@oracle.com> On 05/30/2016 01:32 PM, Vladimir Ivanov wrote: > Looks good. Thanks! > src/share/vm/opto/c2compiler.cpp: > > + case vmIntrinsics::_weakCompareAndSwapObjectVolatile: > > + case vmIntrinsics::_weakCompareAndSwapLongVolatile: > > + case vmIntrinsics::_weakCompareAndSwapIntVolatile: > > Was it overlooked in one of previous VH-related changes? Yes, we apparently missed that in JDK-8155965, added here for consistency reasons. It is a bug waiting to happen: while we currently "fail" the compilation when C2 cannot match the nodes, we should check it routinely in c2compiler.cpp. Thanks, -Aleksey From igor.ignatyev at oracle.com Tue May 31 00:08:01 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 31 May 2016 03:08:01 +0300 Subject: RFR(XXS) : 8158185 : jdk/test/lib/FileInstaller throws NPE if dst is in current directory Message-ID: <6631E47C-2183-4642-9553-85172DADB936@oracle.com> http://cr.openjdk.java.net/~iignatyev/8158185/webrev.00/ > 2 lines changed: 0 ins; 0 del; 2 mod; Hi all, could you please review this small changeset which fixes FileInstaller? FileInstaller throws NPE if 2nd argument (dst) is in current directory, this happens because Path::getParent returns null if Path doesn?t have a parent. to prevent this, I added Path::toAbsolutePath call. JBS: https://bugs.openjdk.java.net/browse/JDK-8158185 webrev: http://cr.openjdk.java.net/~iignatyev/8158185/webrev.00/ Thanks, ? Igor From gromero at linux.vnet.ibm.com Tue May 31 01:31:10 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Mon, 30 May 2016 22:31:10 -0300 Subject: SIGILL crashes JVM on PPC64 LE In-Reply-To: References: <5733B30D.6010201@linux.vnet.ibm.com> Message-ID: <201605310131.u4V1T6HM033728@mx0a-001b2d01.pphosted.com> Hi Volker The following test case has been isolated by Hiroshi Horii and generates the illegal instruction, crashing the JVM on PPC64 LE: UnalignedUnsafeAccess.java: http://hastebin.com/raw/uqegukific $ javac UnalignedUnsafeAccess.java $ java -Xcomp -Xbatch UnalignedUnsafeAccess The issue can be reproduced on OpenJDK 8 downstream, OpenJDK 8, and OpenJDK 9 - hs_err logs: OpenJDK 9, tag 0be6f4f5d186 jdk-9+120: http://hastebin.com/raw/ecuhukutur OpenJDK 8, tag 5aaa43d91c73 tip: http://hastebin.com/raw/ipohoyafos OpenJDK 8 downstream: Ubuntu 16.04 LTS build 1.8.0_91-8u91-b14-0ubuntu4~16.04.1-b14 http://hastebin.com/raw/yetizebofo RHEL 7.2: build 1.8.0_91-b14 http://hastebin.com/raw/irequfawaw The crash happens when an illegal instruction - 0xea2f0013 - is executed. The backtrace shows: Stack: [0x00003fff56030000,0x00003fff56430000], sp=0x00003fff5642b8d0, free space=4078k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0x162104] loadI2LNode::emit(CodeBuffer&, PhaseRegAlloc*) const+0x194 V [libjvm.so+0x8ece28] Compile::fill_buffer(CodeBuffer*, unsigned int*)+0x4e8 V [libjvm.so+0x368e08] Compile::Code_Gen()+0x3c8 V [libjvm.so+0x369e04] Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool)+0xf64 V [libjvm.so+0x271380] C2Compiler::compile_method(ciEnv*, ciMethod*, int)+0x1f0 V [libjvm.so+0x3785a4] CompileBroker::invoke_compiler_on_method(CompileTask*)+0xd54 V [libjvm.so+0x379dc8] CompileBroker::compiler_thread_loop()+0x488 V [libjvm.so+0xa5de90] compiler_thread_entry(JavaThread*, Thread*)+0x20 V [libjvm.so+0xa690c8] JavaThread::thread_main_inner()+0x178 V [libjvm.so+0x8c8c10] java_start(Thread*)+0x170 C [libpthread.so.0+0x833c] start_thread+0xfc C [libc.so.6+0x12b014] clone+0xe4 loadI2LNode class is generated according to the following ADL code in ppc.ad file: instruct loadI2L(iRegLdst dst, memory mem) %{ match(Set dst (ConvI2L (LoadI mem))); predicate(_kids[0]->_leaf->as_Load()->is_unordered()); ins_cost(MEMORY_REF_COST); format %{ "LWA $dst, $mem \t// loadI2L" %} size(4); ins_encode %{ // TODO: PPC port $archOpcode(ppc64Opcode_lwa); int Idisp = $mem$$disp + frame_slots_bias($mem$$base, ra_); __ lwa($dst$$Register, Idisp, $mem$$base$$Register); %} ins_pipe(pipe_class_memory); %} So the generated illegal instruction comes from: lwa 17,17,15 (DS-form: lwa RT, DS, RA) As DS field must always be 4-byte aligned (i.e. DS field is always concatenated with 0b00), 17 as DS (middle 17 value) is illegal, generating the illegal instruction in question: 11101010000000000000000000000010: LWA 00000010001000000000000000000000: 17 00000000000000000000000000010001: 17 00000000000011110000000000000000: 15 -------------------------------- 11101010001011110000000000010011: 0xEA2F0013 => Illegal instruction The following change is proposed to fix the issue and deals with the unaligned displacements: OpenJDK 9 webrev: 81.de.7a9f.ip4.static.sl-reverse.com./illegal/9 OpenJDK 8 webrev: 81.de.7a9f.ip4.static.sl-reverse.com./illegal/8 Could we open a JIRA ticket regarding this issue in order to include it in the webrev? Thank you! Best regards, Gustavo On 12-05-2016 09:39, Volker Simonis wrote: > And I forgot to mention: I've checked and we don't emit vsel > instructions in jdk8 on ppc. So it must be a coincidence that changing > the endianess of the offending instruction yields a valid 'vsel' > instruction. > > > > On Thu, May 12, 2016 at 2:26 PM, Volker Simonis > wrote: >> Hi Gustavo, >> >> thanks for the bug report. The hs_err file you provided indicates that >> this crash happened with Ubuntu's openjdk 8 version. Can you still >> reproduce this with the the newest jdk9 builds? >> >> Also, I can see from the hs_err file that the crash happened in the C2 >> compiled method java.util.TimSort.countRunAndMakeAscending which >> doesn't seem to be related to nio and unsafe. >> >> Ideally, you could post an easy test case to reproduce the problem. If >> that's not possible, it would be helpful if you could post the output >> of a failing run with >> "-XX:CompileCommand=print,java.util.TimSort::countRunAndMakeAscending >> -XX:CompileCommand=option,java.util.TimSort::countRunAndMakeAscending,PrintOptoAssembly". >> In order to get the disassembly output for compiled methods you have >> to build the hsdis library from hotspot/src/share/tools/hsdis (it has >> a README with build instructions). >> >> Regards, >> Volker >> >> >> On Thu, May 12, 2016 at 12:32 AM, Gustavo Romero >> wrote: >>> Hi >>> >>> I'm getting a nasty SIGILL that crashes the JVM on PPC64 LE. >>> >>> hs_err log: >>> http://hastebin.com/raw/fovagunaci >>> >>> The application employs methods from both java.nio.ByteBuffer and >>> sun.misc.Unsafe classes in order to write and read from an allocated buffer. >>> >>> A interesting thing is that after debugging the instruction that caused the >>> said SIGILL: >>> >>> 0x3fff902839a4: cmpwi cr6,r17,0 >>> 0x3fff902839a8: beq cr6,0x3fff90283ae4 >>> 0x3fff902839ac: .long 0xea2f0013 <============ illegal instruction >>> 0x3fff902839b0: add r15,r15,r17 >>> 0x3fff902839b4: add r14,r17,r14 >>> >>> I found that when its endianness is changed it turns out to be a valid >>> instruction: vsel v24,v0,v5,v31 >>> >>> However, I'm still unable to determine if it's an application issue, something >>> with JVM unsafe interface code, or something else. >>> >>> Any clue on how to narrow down this SIGILL? >>> >>> Thank you! >>> >>> Regards, >>> Gustavo >>> > From gromero at linux.vnet.ibm.com Tue May 31 01:49:34 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Mon, 30 May 2016 22:49:34 -0300 Subject: PPC64 VSX load/store instructions in stubs In-Reply-To: <4a58b7d611db4b3c944f47eb03f5df24@DEWDFE13DE14.global.corp.sap> References: <56FEDBB3.5030106@linux.vnet.ibm.com> <57339EE1.2040500@linux.vnet.ibm.com> <573A034C.9060602@br.ibm.com> <201605300143.u4U1cXX8003600@mx0a-001b2d01.pphosted.com> <4a58b7d611db4b3c944f47eb03f5df24@DEWDFE13DE14.global.corp.sap> Message-ID: <201605310149.u4V1mlQY025021@mx0a-001b2d01.pphosted.com> Hi Michihiro Thanks a lot for providing a result summary for byte, short, int, and long. Using VSR0, 1, 2, and 3 (instead of the VR registers) will not violate the ABI, so you can use them as Martin suggested. Martin, should we use the same BugID (8154156: https://goo.gl/z2eGLi) for byte, short, int, and long webrevs or open a new one? Thank you. Best regards, Gustavo On 30-05-2016 06:56, Doerr, Martin wrote: > Hi Michihiro, > > thanks for implementing the VSX versions. > > Gustavo's change "8154156: PPC64: improve array copy stubs by using vector instructions" is pushed into hs-comp. > Your change needs to get adapted: > > - The vm_version and assembler parts are already there. > > - Vector-scalar load/store instructions use VectorSRegisters, now. > > The byte and int version look good to me. I think the long version should be implemented in a similar way: check for has_vsx() is necessary, the length comparison should be done inside of the block. > > Best regards, > Martin > > > From: Michihiro Horie [mailto:HORIE at jp.ibm.com] > Sent: Montag, 30. Mai 2016 03:43 > To: Miki M Enoki > Cc: Breno Leitao ; Gustavo Romero ; hotspot-dev at openjdk.java.net; Doerr, Martin ; ppc-aix-port-dev at openjdk.java.net; Simonis, Volker ; Volker Simonis > Subject: Re: PPC64 VSX load/store instructions in stubs > > > Dear Breno, Gustavo, Voker, and Martin, > I am a cowoker of Miki. > > I implemented VSX disjoint arraycopy functions for byte, int, and long. Although Miki had implemented VSX disjoint long arraycopy, we found a couple of bugs so I fixed it. Would you please review them? > > Micro benchmarks for byte and int are as follows. (The one for long is the same as Miki's, which was attached before by Miki) > (See attached file: ArrayCopyTest_byte.java)(See attached file: ArrayCopyTest_int.java) > > Results are as follows. (For the short result, I used Gustavo's code.) > (See attached file: result_disjoint-arraycopy_vsx-max.jpg) > > Patch for Java8: > (See attached file: hotspot_jdk8.diff) > > Patch for Java9: > (See attached file: hotspot_jdk9.diff) > > Best regards, > -- > Michihiro Horie, > IBM Research - Tokyo > > [Inactive hide details for Miki M Enoki---2016/05/25 00:15:19---Hi Breno, Thank you for your reply.]Miki M Enoki---2016/05/25 00:15:19---Hi Breno, Thank you for your reply. > > From: Miki M Enoki/Japan/IBM > To: Breno Leitao > > Cc: Gustavo Romero >, "hotspot-dev at openjdk.java.net" >, "Doerr, Martin" >, "ppc-aix-port-dev at openjdk.java.net" >, "Simonis, Volker" >, Volker Simonis > > Date: 2016/05/25 00:15 > Subject: Re: PPC64 VSX load/store instructions in stubs > > ________________________________ > > > Hi Breno, > > Thank you for your reply. > >> The same mechanism could be used to copy arrays of short elements, as Gustavo was >> working on. Do you agree? > > I think the mechanism is different with type (byte, short, int, long...). > Gustavo will apply a pach with VSX for short array copy, so it would be reasonable to use VSX instruction for long array copy, too. > > My coworker is also creating byte and int arraycopy with VSX. He will post an email to this mailing list. > I appreciate it if our patch for byte, int and long copy is applied to OpenJDK. > > > Best regards, > Miki > > > > > [Inactive hide details for Breno Leitao ---2016/05/17 02:29:32---Hi Miki, On 05/16/2016 02:53 AM, Miki M Enoki wrote:]Breno Leitao ---2016/05/17 02:29:32---Hi Miki, On 05/16/2016 02:53 AM, Miki M Enoki wrote: > > From: Breno Leitao > > To: Miki M Enoki/Japan/IBM at IBMJP, "Doerr, Martin" >, > Cc: Gustavo Romero >, Volker Simonis >, "Simonis, Volker" >, "ppc-aix-port-dev at openjdk.java.net" >, "hotspot-dev at openjdk.java.net" > > Date: 2016/05/17 02:29 > Subject: Re: PPC64 VSX load/store instructions in stubs > ________________________________ > > > > Hi Miki, > > On 05/16/2016 02:53 AM, Miki M Enoki wrote: >> I also implemented VSX disjoint long arraycopy. >> I appreciate it if it is applied to OpenJDK, too. > > Thanks for the summarized information, this is helpful. Based on your plot, I > understand we can split the whole scenario in two: > > * Array size smaller than 4k, and then use VSX instructions to perform copy > * Array size bigger than 4k, and then use VMX instructions to perform copy > > The same mechanism could be used to copy arrays of short elements, as Gustavo was > working on. Do you agree? > > That said, I understand that a new patch should be generated that contemplates > both cases on a single patch, ready to be applied on OpenJDK 9 source code. Hence > a webrev should be generated mapping to bug id > https://bugs.openjdk.java.net/browse/JDK-8154156 > > If you need any help on the webrev[1] creation and hosting, Gustavo might help, > since he did this process already. > > [1] http://openjdk.java.net/guide/webrevHelp.html > > From vladimir.kozlov at oracle.com Tue May 31 02:14:59 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 30 May 2016 19:14:59 -0700 Subject: RFR(XXS) : 8158185 : jdk/test/lib/FileInstaller throws NPE if dst is in current directory In-Reply-To: <6631E47C-2183-4642-9553-85172DADB936@oracle.com> References: <6631E47C-2183-4642-9553-85172DADB936@oracle.com> Message-ID: <75237a6f-6688-9a3d-7c39-2debd2850271@oracle.com> Looks good. Igor, how are you testing all these tests fixes? Thanks, Vladimir On 5/30/16 5:08 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev/8158185/webrev.00/ >> 2 lines changed: 0 ins; 0 del; 2 mod; > > Hi all, > > could you please review this small changeset which fixes FileInstaller? FileInstaller throws NPE if 2nd argument (dst) is in current directory, this happens because Path::getParent returns null if Path doesn?t have a parent. to prevent this, I added Path::toAbsolutePath call. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8158185 > webrev: http://cr.openjdk.java.net/~iignatyev/8158185/webrev.00/ > > Thanks, > ? Igor > From goetz.lindenmaier at sap.com Tue May 31 07:24:58 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 31 May 2016 07:24:58 +0000 Subject: PPC64 VSX load/store instructions in stubs In-Reply-To: <201605310149.u4V1mmv5012147@mx0a-001b2d01.pphosted.com> References: <56FEDBB3.5030106@linux.vnet.ibm.com> <57339EE1.2040500@linux.vnet.ibm.com> <573A034C.9060602@br.ibm.com> <201605300143.u4U1cXX8003600@mx0a-001b2d01.pphosted.com> <4a58b7d611db4b3c944f47eb03f5df24@DEWDFE13DE14.global.corp.sap> <201605310149.u4V1mmv5012147@mx0a-001b2d01.pphosted.com> Message-ID: Hi Gustavo, you need a new bugId, as the change with the other one has been pushed by Martin. You can't have the same bugId on two different changes. http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/f8f067457966 Best regards, Goetz. > -----Original Message----- > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > bounces at openjdk.java.net] On Behalf Of Gustavo Romero > Sent: Dienstag, 31. Mai 2016 03:50 > To: Doerr, Martin ; Michihiro Horie > ; Miki M Enoki > Cc: Simonis, Volker ; ppc-aix-port- > dev at openjdk.java.net; hotspot-dev at openjdk.java.net; Breno Leitao > > Subject: Re: PPC64 VSX load/store instructions in stubs > > Hi Michihiro > > Thanks a lot for providing a result summary for byte, short, int, and > long. > > Using VSR0, 1, 2, and 3 (instead of the VR registers) will not violate > the ABI, so you can use them as Martin suggested. > > Martin, should we use the same BugID (8154156: https://goo.gl/z2eGLi) > for byte, short, int, and long webrevs or open a new one? > > Thank you. > > Best regards, > Gustavo > > On 30-05-2016 06:56, Doerr, Martin wrote: > > Hi Michihiro, > > > > thanks for implementing the VSX versions. > > > > Gustavo's change "8154156: PPC64: improve array copy stubs by using > vector instructions" is pushed into hs-comp. > > Your change needs to get adapted: > > > > - The vm_version and assembler parts are already there. > > > > - Vector-scalar load/store instructions use VectorSRegisters, now. > > > > The byte and int version look good to me. I think the long version should be > implemented in a similar way: check for has_vsx() is necessary, the length > comparison should be done inside of the block. > > > > Best regards, > > Martin > > > > > > From: Michihiro Horie [mailto:HORIE at jp.ibm.com] > > Sent: Montag, 30. Mai 2016 03:43 > > To: Miki M Enoki > > Cc: Breno Leitao ; Gustavo Romero > ; hotspot-dev at openjdk.java.net; Doerr, > Martin ; ppc-aix-port-dev at openjdk.java.net; > Simonis, Volker ; Volker Simonis > > > Subject: Re: PPC64 VSX load/store instructions in stubs > > > > > > Dear Breno, Gustavo, Voker, and Martin, > > I am a cowoker of Miki. > > > > I implemented VSX disjoint arraycopy functions for byte, int, and long. > Although Miki had implemented VSX disjoint long arraycopy, we found a > couple of bugs so I fixed it. Would you please review them? > > > > Micro benchmarks for byte and int are as follows. (The one for long is the > same as Miki's, which was attached before by Miki) > > (See attached file: ArrayCopyTest_byte.java)(See attached file: > ArrayCopyTest_int.java) > > > > Results are as follows. (For the short result, I used Gustavo's code.) > > (See attached file: result_disjoint-arraycopy_vsx-max.jpg) > > > > Patch for Java8: > > (See attached file: hotspot_jdk8.diff) > > > > Patch for Java9: > > (See attached file: hotspot_jdk9.diff) > > > > Best regards, > > -- > > Michihiro Horie, > > IBM Research - Tokyo > > > > [Inactive hide details for Miki M Enoki---2016/05/25 00:15:19---Hi Breno, > Thank you for your reply.]Miki M Enoki---2016/05/25 00:15:19---Hi Breno, > Thank you for your reply. > > > > From: Miki M Enoki/Japan/IBM > > To: Breno Leitao > > > Cc: Gustavo Romero > >, > "hotspot-dev at openjdk.java.net" > >, > "Doerr, Martin" >, > "ppc-aix-port-dev at openjdk.java.net dev at openjdk.java.net>" aix-port-dev at openjdk.java.net>>, "Simonis, Volker" > >, Volker > Simonis > > > Date: 2016/05/25 00:15 > > Subject: Re: PPC64 VSX load/store instructions in stubs > > > > ________________________________ > > > > > > Hi Breno, > > > > Thank you for your reply. > > > >> The same mechanism could be used to copy arrays of short elements, as > Gustavo was > >> working on. Do you agree? > > > > I think the mechanism is different with type (byte, short, int, long...). > > Gustavo will apply a pach with VSX for short array copy, so it would be > reasonable to use VSX instruction for long array copy, too. > > > > My coworker is also creating byte and int arraycopy with VSX. He will post > an email to this mailing list. > > I appreciate it if our patch for byte, int and long copy is applied to OpenJDK. > > > > > > Best regards, > > Miki > > > > > > > > > > [Inactive hide details for Breno Leitao ---2016/05/17 02:29:32---Hi Miki, On > 05/16/2016 02:53 AM, Miki M Enoki wrote:]Breno Leitao ---2016/05/17 > 02:29:32---Hi Miki, On 05/16/2016 02:53 AM, Miki M Enoki wrote: > > > > From: Breno Leitao > > > To: Miki M Enoki/Japan/IBM at IBMJP, "Doerr, Martin" > >, > > Cc: Gustavo Romero > >, > Volker Simonis > >, "Simonis, > Volker" >, "ppc- > aix-port-dev at openjdk.java.net dev at openjdk.java.net>" aix-port-dev at openjdk.java.net>>, "hotspot- > dev at openjdk.java.net" dev at openjdk.java.net> > > Date: 2016/05/17 02:29 > > Subject: Re: PPC64 VSX load/store instructions in stubs > > ________________________________ > > > > > > > > Hi Miki, > > > > On 05/16/2016 02:53 AM, Miki M Enoki wrote: > >> I also implemented VSX disjoint long arraycopy. > >> I appreciate it if it is applied to OpenJDK, too. > > > > Thanks for the summarized information, this is helpful. Based on your plot, > I > > understand we can split the whole scenario in two: > > > > * Array size smaller than 4k, and then use VSX instructions to perform copy > > * Array size bigger than 4k, and then use VMX instructions to perform copy > > > > The same mechanism could be used to copy arrays of short elements, as > Gustavo was > > working on. Do you agree? > > > > That said, I understand that a new patch should be generated that > contemplates > > both cases on a single patch, ready to be applied on OpenJDK 9 source > code. Hence > > a webrev should be generated mapping to bug id > > https://bugs.openjdk.java.net/browse/JDK-8154156 > > > > If you need any help on the webrev[1] creation and hosting, Gustavo might > help, > > since he did this process already. > > > > [1] http://openjdk.java.net/guide/webrevHelp.html > > > > From martin.doerr at sap.com Tue May 31 10:17:28 2016 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 31 May 2016 10:17:28 +0000 Subject: PPC64 VSX load/store instructions in stubs In-Reply-To: <201605310149.u4V1mlAA012138@mx0a-001b2d01.pphosted.com> References: <56FEDBB3.5030106@linux.vnet.ibm.com> <57339EE1.2040500@linux.vnet.ibm.com> <573A034C.9060602@br.ibm.com> <201605300143.u4U1cXX8003600@mx0a-001b2d01.pphosted.com> <4a58b7d611db4b3c944f47eb03f5df24@DEWDFE13DE14.global.corp.sap> <201605310149.u4V1mlAA012138@mx0a-001b2d01.pphosted.com> Message-ID: Hello everybody, I have created a new bug: JDK-8158232 We will need a webrev and a request for review mail to hotspot-dev: "RFR(M): 8158232: PPC64: improve byte, int and long array copy stubs by using VSX instructions" Thanks and best regards, Martin -----Original Message----- From: Gustavo Romero [mailto:gromero at linux.vnet.ibm.com] Sent: Dienstag, 31. Mai 2016 03:50 To: Doerr, Martin ; Michihiro Horie ; Miki M Enoki Cc: Breno Leitao ; hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; Simonis, Volker ; Volker Simonis ; Breno Leitao Subject: Re: PPC64 VSX load/store instructions in stubs Hi Michihiro Thanks a lot for providing a result summary for byte, short, int, and long. Using VSR0, 1, 2, and 3 (instead of the VR registers) will not violate the ABI, so you can use them as Martin suggested. Martin, should we use the same BugID (8154156: https://goo.gl/z2eGLi) for byte, short, int, and long webrevs or open a new one? Thank you. Best regards, Gustavo On 30-05-2016 06:56, Doerr, Martin wrote: > Hi Michihiro, > > thanks for implementing the VSX versions. > > Gustavo's change "8154156: PPC64: improve array copy stubs by using vector instructions" is pushed into hs-comp. > Your change needs to get adapted: > > - The vm_version and assembler parts are already there. > > - Vector-scalar load/store instructions use VectorSRegisters, now. > > The byte and int version look good to me. I think the long version should be implemented in a similar way: check for has_vsx() is necessary, the length comparison should be done inside of the block. > > Best regards, > Martin > > > From: Michihiro Horie [mailto:HORIE at jp.ibm.com] > Sent: Montag, 30. Mai 2016 03:43 > To: Miki M Enoki > Cc: Breno Leitao ; Gustavo Romero ; hotspot-dev at openjdk.java.net; Doerr, Martin ; ppc-aix-port-dev at openjdk.java.net; Simonis, Volker ; Volker Simonis > Subject: Re: PPC64 VSX load/store instructions in stubs > > > Dear Breno, Gustavo, Voker, and Martin, > I am a cowoker of Miki. > > I implemented VSX disjoint arraycopy functions for byte, int, and long. Although Miki had implemented VSX disjoint long arraycopy, we found a couple of bugs so I fixed it. Would you please review them? > > Micro benchmarks for byte and int are as follows. (The one for long is the same as Miki's, which was attached before by Miki) > (See attached file: ArrayCopyTest_byte.java)(See attached file: ArrayCopyTest_int.java) > > Results are as follows. (For the short result, I used Gustavo's code.) > (See attached file: result_disjoint-arraycopy_vsx-max.jpg) > > Patch for Java8: > (See attached file: hotspot_jdk8.diff) > > Patch for Java9: > (See attached file: hotspot_jdk9.diff) > > Best regards, > -- > Michihiro Horie, > IBM Research - Tokyo > > [Inactive hide details for Miki M Enoki---2016/05/25 00:15:19---Hi Breno, Thank you for your reply.]Miki M Enoki---2016/05/25 00:15:19---Hi Breno, Thank you for your reply. > > From: Miki M Enoki/Japan/IBM > To: Breno Leitao > > Cc: Gustavo Romero >, "hotspot-dev at openjdk.java.net" >, "Doerr, Martin" >, "ppc-aix-port-dev at openjdk.java.net" >, "Simonis, Volker" >, Volker Simonis > > Date: 2016/05/25 00:15 > Subject: Re: PPC64 VSX load/store instructions in stubs > > ________________________________ > > > Hi Breno, > > Thank you for your reply. > >> The same mechanism could be used to copy arrays of short elements, as Gustavo was >> working on. Do you agree? > > I think the mechanism is different with type (byte, short, int, long...). > Gustavo will apply a pach with VSX for short array copy, so it would be reasonable to use VSX instruction for long array copy, too. > > My coworker is also creating byte and int arraycopy with VSX. He will post an email to this mailing list. > I appreciate it if our patch for byte, int and long copy is applied to OpenJDK. > > > Best regards, > Miki > > > > > [Inactive hide details for Breno Leitao ---2016/05/17 02:29:32---Hi Miki, On 05/16/2016 02:53 AM, Miki M Enoki wrote:]Breno Leitao ---2016/05/17 02:29:32---Hi Miki, On 05/16/2016 02:53 AM, Miki M Enoki wrote: > > From: Breno Leitao > > To: Miki M Enoki/Japan/IBM at IBMJP, "Doerr, Martin" >, > Cc: Gustavo Romero >, Volker Simonis >, "Simonis, Volker" >, "ppc-aix-port-dev at openjdk.java.net" >, "hotspot-dev at openjdk.java.net" > > Date: 2016/05/17 02:29 > Subject: Re: PPC64 VSX load/store instructions in stubs > ________________________________ > > > > Hi Miki, > > On 05/16/2016 02:53 AM, Miki M Enoki wrote: >> I also implemented VSX disjoint long arraycopy. >> I appreciate it if it is applied to OpenJDK, too. > > Thanks for the summarized information, this is helpful. Based on your plot, I > understand we can split the whole scenario in two: > > * Array size smaller than 4k, and then use VSX instructions to perform copy > * Array size bigger than 4k, and then use VMX instructions to perform copy > > The same mechanism could be used to copy arrays of short elements, as Gustavo was > working on. Do you agree? > > That said, I understand that a new patch should be generated that contemplates > both cases on a single patch, ready to be applied on OpenJDK 9 source code. Hence > a webrev should be generated mapping to bug id > https://bugs.openjdk.java.net/browse/JDK-8154156 > > If you need any help on the webrev[1] creation and hosting, Gustavo might help, > since he did this process already. > > [1] http://openjdk.java.net/guide/webrevHelp.html > > From thomas.schatzl at oracle.com Tue May 31 11:08:38 2016 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 31 May 2016 13:08:38 +0200 Subject: [9] RFR(S): 8156760: VM crashes if -XX:-ReduceInitialCardMarks is set In-Reply-To: <574BEA7C.3040000@oracle.com> References: <5742CC7F.4050309@oracle.com> <5745C75C.80208@oracle.com> <574BEA7C.3040000@oracle.com> Message-ID: <1464692918.2464.20.camel@oracle.com> Hi Tobias, On Mon, 2016-05-30 at 09:23 +0200, Tobias Hartmann wrote: > Hi, > > all tests passed (link is attached to the bug). Is everyone fine with > the latest webrev? > http://cr.openjdk.java.net/~thartmann/8156760/webrev.02/ > ? I would think it is good. I believe the necessary actions (card marking) are taken with -XX:-ReduceInitialCardMarks from the comments, in the places I would expect them. However my C2-fu is limited to hacking together barriers, so I am honestly unable to verify that the code in detail is correct. Somebody more knowledgable in C2 in general needs to look at this. If you have time, copyrights may need to be fixed up. I do not need a re-review for that. Thanks, ? Thomas From tobias.hartmann at oracle.com Tue May 31 11:27:01 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 31 May 2016 13:27:01 +0200 Subject: [9] RFR(S): 8156760: VM crashes if -XX:-ReduceInitialCardMarks is set In-Reply-To: <1464692918.2464.20.camel@oracle.com> References: <5742CC7F.4050309@oracle.com> <5745C75C.80208@oracle.com> <574BEA7C.3040000@oracle.com> <1464692918.2464.20.camel@oracle.com> Message-ID: <574D7505.9090005@oracle.com> Hi Thomas, On 31.05.2016 13:08, Thomas Schatzl wrote: > Hi Tobias, > > On Mon, 2016-05-30 at 09:23 +0200, Tobias Hartmann wrote: >> Hi, >> >> all tests passed (link is attached to the bug). Is everyone fine with >> the latest webrev? >> http://cr.openjdk.java.net/~thartmann/8156760/webrev.02/ >> > > I would think it is good. I believe the necessary actions (card > marking) are taken with -XX:-ReduceInitialCardMarks from the comments, > in the places I would expect them. However my C2-fu is limited to > hacking together barriers, so I am honestly unable to verify that the > code in detail is correct. Thanks for looking at this again! > Somebody more knowledgable in C2 in general needs to look at this. > > If you have time, copyrights may need to be fixed up. I do not need a > re-review for that. Right, I updated the copyright dates in-place. Thanks, Tobias > > Thanks, > Thomas > From gromero at linux.vnet.ibm.com Tue May 31 12:53:44 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Tue, 31 May 2016 09:53:44 -0300 Subject: PPC64 VSX load/store instructions in stubs In-Reply-To: References: <56FEDBB3.5030106@linux.vnet.ibm.com> <57339EE1.2040500@linux.vnet.ibm.com> <573A034C.9060602@br.ibm.com> <201605300143.u4U1cXX8003600@mx0a-001b2d01.pphosted.com> <4a58b7d611db4b3c944f47eb03f5df24@DEWDFE13DE14.global.corp.sap> <201605310149.u4V1mmv5012147@mx0a-001b2d01.pphosted.com> Message-ID: <201605311253.u4VCne3v025612@mx0a-001b2d01.pphosted.com> Hi Goetz Got it. Thanks for clarifying it. Best regards, Gustavo On 31-05-2016 04:24, Lindenmaier, Goetz wrote: > Hi Gustavo, > > you need a new bugId, as the change with the other one has been > pushed by Martin. You can't have the same bugId on two different > changes. > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/rev/f8f067457966 > > Best regards, > Goetz. > > > >> -----Original Message----- >> From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- >> bounces at openjdk.java.net] On Behalf Of Gustavo Romero >> Sent: Dienstag, 31. Mai 2016 03:50 >> To: Doerr, Martin ; Michihiro Horie >> ; Miki M Enoki >> Cc: Simonis, Volker ; ppc-aix-port- >> dev at openjdk.java.net; hotspot-dev at openjdk.java.net; Breno Leitao >> >> Subject: Re: PPC64 VSX load/store instructions in stubs >> >> Hi Michihiro >> >> Thanks a lot for providing a result summary for byte, short, int, and >> long. >> >> Using VSR0, 1, 2, and 3 (instead of the VR registers) will not violate >> the ABI, so you can use them as Martin suggested. >> >> Martin, should we use the same BugID (8154156: https://goo.gl/z2eGLi) >> for byte, short, int, and long webrevs or open a new one? >> >> Thank you. >> >> Best regards, >> Gustavo >> >> On 30-05-2016 06:56, Doerr, Martin wrote: >>> Hi Michihiro, >>> >>> thanks for implementing the VSX versions. >>> >>> Gustavo's change "8154156: PPC64: improve array copy stubs by using >> vector instructions" is pushed into hs-comp. >>> Your change needs to get adapted: >>> >>> - The vm_version and assembler parts are already there. >>> >>> - Vector-scalar load/store instructions use VectorSRegisters, now. >>> >>> The byte and int version look good to me. I think the long version should be >> implemented in a similar way: check for has_vsx() is necessary, the length >> comparison should be done inside of the block. >>> >>> Best regards, >>> Martin >>> >>> >>> From: Michihiro Horie [mailto:HORIE at jp.ibm.com] >>> Sent: Montag, 30. Mai 2016 03:43 >>> To: Miki M Enoki >>> Cc: Breno Leitao ; Gustavo Romero >> ; hotspot-dev at openjdk.java.net; Doerr, >> Martin ; ppc-aix-port-dev at openjdk.java.net; >> Simonis, Volker ; Volker Simonis >> >>> Subject: Re: PPC64 VSX load/store instructions in stubs >>> >>> >>> Dear Breno, Gustavo, Voker, and Martin, >>> I am a cowoker of Miki. >>> >>> I implemented VSX disjoint arraycopy functions for byte, int, and long. >> Although Miki had implemented VSX disjoint long arraycopy, we found a >> couple of bugs so I fixed it. Would you please review them? >>> >>> Micro benchmarks for byte and int are as follows. (The one for long is the >> same as Miki's, which was attached before by Miki) >>> (See attached file: ArrayCopyTest_byte.java)(See attached file: >> ArrayCopyTest_int.java) >>> >>> Results are as follows. (For the short result, I used Gustavo's code.) >>> (See attached file: result_disjoint-arraycopy_vsx-max.jpg) >>> >>> Patch for Java8: >>> (See attached file: hotspot_jdk8.diff) >>> >>> Patch for Java9: >>> (See attached file: hotspot_jdk9.diff) >>> >>> Best regards, >>> -- >>> Michihiro Horie, >>> IBM Research - Tokyo >>> >>> [Inactive hide details for Miki M Enoki---2016/05/25 00:15:19---Hi Breno, >> Thank you for your reply.]Miki M Enoki---2016/05/25 00:15:19---Hi Breno, >> Thank you for your reply. >>> >>> From: Miki M Enoki/Japan/IBM >>> To: Breno Leitao > >>> Cc: Gustavo Romero >> >, >> "hotspot-dev at openjdk.java.net" >> >, >> "Doerr, Martin" >, >> "ppc-aix-port-dev at openjdk.java.net> dev at openjdk.java.net>" > aix-port-dev at openjdk.java.net>>, "Simonis, Volker" >> >, Volker >> Simonis > >>> Date: 2016/05/25 00:15 >>> Subject: Re: PPC64 VSX load/store instructions in stubs >>> >>> ________________________________ >>> >>> >>> Hi Breno, >>> >>> Thank you for your reply. >>> >>>> The same mechanism could be used to copy arrays of short elements, as >> Gustavo was >>>> working on. Do you agree? >>> >>> I think the mechanism is different with type (byte, short, int, long...). >>> Gustavo will apply a pach with VSX for short array copy, so it would be >> reasonable to use VSX instruction for long array copy, too. >>> >>> My coworker is also creating byte and int arraycopy with VSX. He will post >> an email to this mailing list. >>> I appreciate it if our patch for byte, int and long copy is applied to OpenJDK. >>> >>> >>> Best regards, >>> Miki >>> >>> >>> >>> >>> [Inactive hide details for Breno Leitao ---2016/05/17 02:29:32---Hi Miki, On >> 05/16/2016 02:53 AM, Miki M Enoki wrote:]Breno Leitao ---2016/05/17 >> 02:29:32---Hi Miki, On 05/16/2016 02:53 AM, Miki M Enoki wrote: >>> >>> From: Breno Leitao > >>> To: Miki M Enoki/Japan/IBM at IBMJP, "Doerr, Martin" >> >, >>> Cc: Gustavo Romero >> >, >> Volker Simonis >> >, "Simonis, >> Volker" >, "ppc- >> aix-port-dev at openjdk.java.net> dev at openjdk.java.net>" > aix-port-dev at openjdk.java.net>>, "hotspot- >> dev at openjdk.java.net" > dev at openjdk.java.net> >>> Date: 2016/05/17 02:29 >>> Subject: Re: PPC64 VSX load/store instructions in stubs >>> ________________________________ >>> >>> >>> >>> Hi Miki, >>> >>> On 05/16/2016 02:53 AM, Miki M Enoki wrote: >>>> I also implemented VSX disjoint long arraycopy. >>>> I appreciate it if it is applied to OpenJDK, too. >>> >>> Thanks for the summarized information, this is helpful. Based on your plot, >> I >>> understand we can split the whole scenario in two: >>> >>> * Array size smaller than 4k, and then use VSX instructions to perform copy >>> * Array size bigger than 4k, and then use VMX instructions to perform copy >>> >>> The same mechanism could be used to copy arrays of short elements, as >> Gustavo was >>> working on. Do you agree? >>> >>> That said, I understand that a new patch should be generated that >> contemplates >>> both cases on a single patch, ready to be applied on OpenJDK 9 source >> code. Hence >>> a webrev should be generated mapping to bug id >>> https://bugs.openjdk.java.net/browse/JDK-8154156 >>> >>> If you need any help on the webrev[1] creation and hosting, Gustavo might >> help, >>> since he did this process already. >>> >>> [1] http://openjdk.java.net/guide/webrevHelp.html >>> >>> > From gromero at linux.vnet.ibm.com Tue May 31 12:57:14 2016 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Tue, 31 May 2016 09:57:14 -0300 Subject: PPC64 VSX load/store instructions in stubs In-Reply-To: References: <56FEDBB3.5030106@linux.vnet.ibm.com> <57339EE1.2040500@linux.vnet.ibm.com> <573A034C.9060602@br.ibm.com> <201605300143.u4U1cXX8003600@mx0a-001b2d01.pphosted.com> <4a58b7d611db4b3c944f47eb03f5df24@DEWDFE13DE14.global.corp.sap> <201605310149.u4V1mlAA012138@mx0a-001b2d01.pphosted.com> Message-ID: <201605311257.u4VCsWrK044978@mx0a-001b2d01.pphosted.com> Hi Martin! Thanks for creating a new BugID. Regards, Gustavo On 31-05-2016 07:17, Doerr, Martin wrote: > Hello everybody, > > I have created a new bug: JDK-8158232 > > We will need a webrev and a request for review mail to hotspot-dev: > "RFR(M): 8158232: PPC64: improve byte, int and long array copy stubs by using VSX instructions" > > Thanks and best regards, > Martin > > -----Original Message----- > From: Gustavo Romero [mailto:gromero at linux.vnet.ibm.com] > Sent: Dienstag, 31. Mai 2016 03:50 > To: Doerr, Martin ; Michihiro Horie ; Miki M Enoki > Cc: Breno Leitao ; hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; Simonis, Volker ; Volker Simonis ; Breno Leitao > Subject: Re: PPC64 VSX load/store instructions in stubs > > Hi Michihiro > > Thanks a lot for providing a result summary for byte, short, int, and > long. > > Using VSR0, 1, 2, and 3 (instead of the VR registers) will not violate > the ABI, so you can use them as Martin suggested. > > Martin, should we use the same BugID (8154156: https://goo.gl/z2eGLi) > for byte, short, int, and long webrevs or open a new one? > > Thank you. > > Best regards, > Gustavo > > On 30-05-2016 06:56, Doerr, Martin wrote: >> Hi Michihiro, >> >> thanks for implementing the VSX versions. >> >> Gustavo's change "8154156: PPC64: improve array copy stubs by using vector instructions" is pushed into hs-comp. >> Your change needs to get adapted: >> >> - The vm_version and assembler parts are already there. >> >> - Vector-scalar load/store instructions use VectorSRegisters, now. >> >> The byte and int version look good to me. I think the long version should be implemented in a similar way: check for has_vsx() is necessary, the length comparison should be done inside of the block. >> >> Best regards, >> Martin >> >> >> From: Michihiro Horie [mailto:HORIE at jp.ibm.com] >> Sent: Montag, 30. Mai 2016 03:43 >> To: Miki M Enoki >> Cc: Breno Leitao ; Gustavo Romero ; hotspot-dev at openjdk.java.net; Doerr, Martin ; ppc-aix-port-dev at openjdk.java.net; Simonis, Volker ; Volker Simonis >> Subject: Re: PPC64 VSX load/store instructions in stubs >> >> >> Dear Breno, Gustavo, Voker, and Martin, >> I am a cowoker of Miki. >> >> I implemented VSX disjoint arraycopy functions for byte, int, and long. Although Miki had implemented VSX disjoint long arraycopy, we found a couple of bugs so I fixed it. Would you please review them? >> >> Micro benchmarks for byte and int are as follows. (The one for long is the same as Miki's, which was attached before by Miki) >> (See attached file: ArrayCopyTest_byte.java)(See attached file: ArrayCopyTest_int.java) >> >> Results are as follows. (For the short result, I used Gustavo's code.) >> (See attached file: result_disjoint-arraycopy_vsx-max.jpg) >> >> Patch for Java8: >> (See attached file: hotspot_jdk8.diff) >> >> Patch for Java9: >> (See attached file: hotspot_jdk9.diff) >> >> Best regards, >> -- >> Michihiro Horie, >> IBM Research - Tokyo >> >> [Inactive hide details for Miki M Enoki---2016/05/25 00:15:19---Hi Breno, Thank you for your reply.]Miki M Enoki---2016/05/25 00:15:19---Hi Breno, Thank you for your reply. >> >> From: Miki M Enoki/Japan/IBM >> To: Breno Leitao > >> Cc: Gustavo Romero >, "hotspot-dev at openjdk.java.net" >, "Doerr, Martin" >, "ppc-aix-port-dev at openjdk.java.net" >, "Simonis, Volker" >, Volker Simonis > >> Date: 2016/05/25 00:15 >> Subject: Re: PPC64 VSX load/store instructions in stubs >> >> ________________________________ >> >> >> Hi Breno, >> >> Thank you for your reply. >> >>> The same mechanism could be used to copy arrays of short elements, as Gustavo was >>> working on. Do you agree? >> >> I think the mechanism is different with type (byte, short, int, long...). >> Gustavo will apply a pach with VSX for short array copy, so it would be reasonable to use VSX instruction for long array copy, too. >> >> My coworker is also creating byte and int arraycopy with VSX. He will post an email to this mailing list. >> I appreciate it if our patch for byte, int and long copy is applied to OpenJDK. >> >> >> Best regards, >> Miki >> >> >> >> >> [Inactive hide details for Breno Leitao ---2016/05/17 02:29:32---Hi Miki, On 05/16/2016 02:53 AM, Miki M Enoki wrote:]Breno Leitao ---2016/05/17 02:29:32---Hi Miki, On 05/16/2016 02:53 AM, Miki M Enoki wrote: >> >> From: Breno Leitao > >> To: Miki M Enoki/Japan/IBM at IBMJP, "Doerr, Martin" >, >> Cc: Gustavo Romero >, Volker Simonis >, "Simonis, Volker" >, "ppc-aix-port-dev at openjdk.java.net" >, "hotspot-dev at openjdk.java.net" > >> Date: 2016/05/17 02:29 >> Subject: Re: PPC64 VSX load/store instructions in stubs >> ________________________________ >> >> >> >> Hi Miki, >> >> On 05/16/2016 02:53 AM, Miki M Enoki wrote: >>> I also implemented VSX disjoint long arraycopy. >>> I appreciate it if it is applied to OpenJDK, too. >> >> Thanks for the summarized information, this is helpful. Based on your plot, I >> understand we can split the whole scenario in two: >> >> * Array size smaller than 4k, and then use VSX instructions to perform copy >> * Array size bigger than 4k, and then use VMX instructions to perform copy >> >> The same mechanism could be used to copy arrays of short elements, as Gustavo was >> working on. Do you agree? >> >> That said, I understand that a new patch should be generated that contemplates >> both cases on a single patch, ready to be applied on OpenJDK 9 source code. Hence >> a webrev should be generated mapping to bug id >> https://bugs.openjdk.java.net/browse/JDK-8154156 >> >> If you need any help on the webrev[1] creation and hosting, Gustavo might help, >> since he did this process already. >> >> [1] http://openjdk.java.net/guide/webrevHelp.html >> >> > From adinn at redhat.com Tue May 31 13:09:47 2016 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 31 May 2016 14:09:47 +0100 Subject: Fwd: Java stack unwinder for Linux + gdb7.10+ In-Reply-To: <574D6F5A.1090206@redhat.com> References: <574D6F5A.1090206@redhat.com> Message-ID: <574D8D1B.1040408@redhat.com> I probably should have sent this here initially rather than to jdk9-dev. Anyway, I hope subscribers to this list will find this interesting. regards, Andrew Dinn ----------- -------- Forwarded Message -------- Subject: Java stack unwinder for Linux + gdb7.10+ Date: Tue, 31 May 2016 12:02:50 +0100 From: Andrew Dinn To: jdk9-dev at openjdk.java.net CC: code-tools-dev at openjdk.java.net What's this all about? ---------------------- Recently, I have been working on implementing support for unwinding Java stacks in gdb using the new python stack unwinder API provided from gdb 7.10.1 onwards. I have managed to provide a pure python solution i.e. one that that needs no modifications to the VM itself. So, if you use gdb to debug operation of the JVM then this implementation will allow you to use the bt command as $DEITY (and, indeed, the gdb team) intended. Attached at the bottom of this note is a before and after showing how backtraces look without/with this package installed. Note that the unwinder works when using gdb to debug either a live process or a core file. Also, note that at present gdb only uses python unwinders to display frame info underneath the bt command. I am working with the gdb devs to see if they can extend the use of the unwinder to other situations e.g. to display the current frame when single-stepping. Can I try it out? ----------------- Yes, please do! Indeed, I am posting this to jdk9-dev because I want as many people as possible to try out the unwinder and provide feedback on how it works. So, please use it and respond -- positive or negative I would love to hear what you think. I'm happy to hear offline or on this list. You choose whether or not you think others on this list might want to hear your comments. How do I obtain/use it? ----------------------- The unwinder code is available from the following hg repo http://icedtea.classpath.org/people/adinn/unwinder See the README in that repo for details of how to install and use it (gdb will auto-load it once you have configured things correctly) To summarize some important details: The extension requires gdb 7.10+ and you there are two unwinder implementations, one for jdk8 and one for jdk9. The jdk8 unwinder should work for any jdk8 built from the jdk8u repo. In particular, it will work for /product releases/ available with your Linux distro so long as the distro supports installation of minimal debuginfo for those releases. For example, if you are using RHEL or fedora then you can simply debuginfo-install the debug info corresponding to your jdk8 java package and then install the uinwinder under /etc/alternatives/java_sdk_1.8.0. If you want to use it with your own jdk8 build then you need to build a debug release which includes a libjvm.debuginfo product (well, I guess you could always hack the product make process so it generates libjvm.debuginfo ). The jdk9 unwinder will only work for your own debug builds and even then only for builds which include the b119 tag. It doesn't work for product builds because ... well, there are no product builds available from any distros just yet which, a fortiori, means there are no product builds where you can install minimal debug info. Unfortunately, that includes the currently available early access program builds which don't ship libjvm.debuginfo. Ok, so why also the b119 restriction? That's because between b118 and b119 the stack and code heap layouts changed and this required the unwinder code to change accordingly. An older version of the unwinder did work with b118 and earlier builds but tempus fugit, hey ho .... How does it do that? -------------------- For those who are curious the python code is your friend (apologies for my python noobness -- I mean, eeeuurrrggghhh, python :-). Basically, the unwinder works without change to the JVM because it understands a few details of how: the code cache is laid out code blobs/methods are organised bci-to-line number maps are organized code address-to-bci maps are organized So, essentially, it uses the gdb inferior access functions to poke around in JVM memory, allowing it to work out what the state of the stack is and what method, file, bci and line number a specific instruction address corresponds to. That includes using gdb to resolve a few symbols in order to identify memory layouts and a few important global addresses. This dependency has been kept to a bare minimum so that the unwinder will be as resilient as possible to changes in the JVM. Can we have this in OpenJDK? ---------------------------- The current code is LGPL licensed. I'd be very happy to contribute it to OpenJDK as part of the code tools set for JDK developers to use and Red Hat would be very happy to maintain it once included. Ideally, Red Hat would like to ship the tool as part of OpenJDK product releases for use in any distro where minimal debug info is available with the product release. We see great benefit in the opportunity it provides for support staff to print stack traces from core files (clearly, shipping with OpenJDK would help to ensure that changes in the JVM and required changes in the python code were able to be kept in sync). I have copied this note to the code-tools-dev list on the assumption that it is the correct place to open up discussion of whether it could/should be provided as part of OpenJDK. If not can someone please let me know where else I should start that discussion. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander ----- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< --- Normal gdb backtrace for java thread fails ot unwind through Java frames (gdb) thread 16 [Switching to thread 16 (Thread 0x7fffa1fff700 (LWP 4930))] #0 0x00007fffe1113484 in ?? () (gdb) bt 3 #0 0x00007fffe1113484 in ?? () #1 0x00007fffd3c00c18 in ?? () #2 0x0000000000000000 in ?? () Backtrace with the unwinder installed (gdb) thread 2 [Switching to thread 2 (Thread 0x7ffff7fcc700 (LWP 4906))] #0 0x00007ffff79b6540 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 (gdb) bt 10 #0 0x00007ffff79b6540 in pthread_cond_wait@@GLIBC_2.3.2 () at /lib64/libpthread.so.0 #1 0x00007ffff64ae82d in os::PlatformEvent::park() (this=0x7ffff0019700) at /home/adinn/redhat/openjdk/jdk9/hs/hotspot/src/os/linux/vm/os_linux.cpp:5582 #2 0x00007ffff6486f59 in ObjectMonitor::wait(long, bool, Thread*) (this=0x7fff90008b80, millis=0, interruptible=true, __the_thread__=0x7ffff0018800) at /home/adinn/redhat/openjdk/jdk9/hs/hotspot/src/share/vm/runtime/objectMonitor.cpp:1490 #3 0x00007ffff66518cb in ObjectSynchronizer::wait(Handle, long, Thread*) (obj=..., millis=0, __the_thread__=0x7ffff0018800) at /home/adinn/redhat/openjdk/jdk9/hs/hotspot/src/share/vm/runtime/synchronizer.cpp:496 #4 0x00007ffff618fa54 in JVM_MonitorWait(JNIEnv*, jobject, jlong) (env=0x7ffff0018a28, handle=0x7ffff7fcb738, ms=0) at /home/adinn/redhat/openjdk/jdk9/hs/hotspot/src/share/vm/prims/jvm.cpp:614 #5 0x00007fffd8924f7d in [interpreted: bc = 0] java.lang.Object.wait(long) () at java/lang/Object.java #6 0x00007fffd89034a3 in [interpreted: bc = 38] java.lang.Thread.join(long) () at java/lang/Thread.java:1352 #7 0x00007fffd89034a3 in [interpreted: bc = 2] java.lang.Thread.join() () at java/lang/Thread.java:1426 #8 0x00007fffd89034a3 in [interpreted: bc = 35] HelloV.main(java.lang.String) () at HelloV.java:80 #9 0x00007fffd88f89f1 in StubRoutines (1) () #10 0x00007ffff6109bb3 in JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*) (result=0x7ffff7fcbd30, method=..., args=0x7ffff7fcbc10, __the_thread__=0x7ffff0018800) at /home/adinn/redhat/openjdk/jdk9/hs/hotspot/src/share/vm/runtime/javaCalls.cpp:409 (gdb) thread 26 [Switching to thread 26 (Thread 0x7fffa1fff700 (LWP 4930))] #0 0x00007fffe03cb664 in ?? () (gdb) bt 5 #0 0x00007fffe03cb664 in [compiled offset = 0x3a4] HelloV$1.run() () at HelloV.java:63 #1 0x00007fffd88f89f1 in StubRoutines (1) () #2 0x00007ffff6109bb3 in JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*) (result=0x7fffa1ffecc0, method=..., args=0x7fffa1ffec00, __the_thread__=0x7ffff0471800) at /home/adinn/redhat/openjdk/jdk9/hs/hotspot/src/share/vm/runtime/javaCalls.cpp:409 #3 0x00007ffff64ad409 in os::os_exception_wrapper(void (*)(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*), JavaValue*, methodHandle const&, JavaCallArguments*, Thread*) (f=0x7ffff610951a , value=0x7fffa1ffecc0, method=..., args=0x7fffa1ffec00, thread=0x7ffff0471800) at /home/adinn/redhat/openjdk/jdk9/hs/hotspot/src/os/linux/vm/os_linux.cpp:5128 #4 0x00007ffff6109502 in JavaCalls::call(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*) (result=0x7fffa1ffecc0, method=..., args=0x7fffa1ffec00, __the_thread__=0x7ffff0471800) at /home/adinn/redhat/openjdk/jdk9/hs/hotspot/src/share/vm/runtime/javaCalls.cpp:298 #5 0x00007ffff610877b in JavaCalls::call_virtual(JavaValue*, KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) (result=0x7fffa1ffecc0, spec_klass=..., name=0x7ffff4031338, signature=0x7ffff4033220, args=0x7fffa1ffec00, __the_thread__=0x7ffff0471800) at /home/adinn/redhat/openjdk/jdk9/hs/hotspot/src/share/vm/runtime/javaCalls.cpp:193 (gdb) From mikael.gerdin at oracle.com Tue May 31 13:13:55 2016 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 31 May 2016 15:13:55 +0200 Subject: Fwd: Java stack unwinder for Linux + gdb7.10+ In-Reply-To: <574D8D1B.1040408@redhat.com> References: <574D6F5A.1090206@redhat.com> <574D8D1B.1040408@redhat.com> Message-ID: <574D8E13.1040404@oracle.com> Hi Andrew, On 2016-05-31 15:09, Andrew Dinn wrote: > I probably should have sent this here initially rather than to jdk9-dev. > Anyway, I hope subscribers to this list will find this interesting. I saw it, tried it and it worked after replacing a bunch of - except Exception, arg: + except Exception as arg: and adjusting the sources to account for jdk 9 changes which I don't yet have in my project workspace. I think it might make more sense to put this in the hotspot repo, similar to the serviceability agent, since it's functionality is tied to a particular revision of the sources. /Mikael > > regards, > > > Andrew Dinn > ----------- > > -------- Forwarded Message -------- > Subject: Java stack unwinder for Linux + gdb7.10+ > Date: Tue, 31 May 2016 12:02:50 +0100 > From: Andrew Dinn > To: jdk9-dev at openjdk.java.net > CC: code-tools-dev at openjdk.java.net > > What's this all about? > ---------------------- > > Recently, I have been working on implementing support for unwinding Java > stacks in gdb using the new python stack unwinder API provided from gdb > 7.10.1 onwards. I have managed to provide a pure python solution i.e. > one that that needs no modifications to the VM itself. So, if you use > gdb to debug operation of the JVM then this implementation will allow > you to use the bt command as $DEITY (and, indeed, the gdb team) intended. > > Attached at the bottom of this note is a before and after showing how > backtraces look without/with this package installed. > > Note that the unwinder works when using gdb to debug either a live > process or a core file. > > Also, note that at present gdb only uses python unwinders to display > frame info underneath the bt command. I am working with the gdb devs to > see if they can extend the use of the unwinder to other situations e.g. > to display the current frame when single-stepping. > > Can I try it out? > ----------------- > > Yes, please do! > > Indeed, I am posting this to jdk9-dev because I want as many people as > possible to try out the unwinder and provide feedback on how it works. > So, please use it and respond -- positive or negative I would love to > hear what you think. I'm happy to hear offline or on this list. You > choose whether or not you think others on this list might want to hear > your comments. > > How do I obtain/use it? > ----------------------- > > The unwinder code is available from the following hg repo > > http://icedtea.classpath.org/people/adinn/unwinder > > See the README in that repo for details of how to install and use it > (gdb will auto-load it once you have configured things correctly) > > To summarize some important details: > > The extension requires gdb 7.10+ and you there are two unwinder > implementations, one for jdk8 and one for jdk9. > > The jdk8 unwinder should work for any jdk8 built from the jdk8u repo. > In particular, it will work for /product releases/ available with your > Linux distro so long as the distro supports installation of minimal > debuginfo for those releases. For example, if you are using RHEL or > fedora then you can simply debuginfo-install the debug info > corresponding to your jdk8 java package and then install the uinwinder > under /etc/alternatives/java_sdk_1.8.0. If you want to use it with your > own jdk8 build then you need to build a debug release which includes a > libjvm.debuginfo product (well, I guess you could always hack the > product make process so it generates libjvm.debuginfo ). > > The jdk9 unwinder will only work for your own debug builds and even > then only for builds which include the b119 tag. It doesn't work for > product builds because ... well, there are no product builds available > from any distros just yet which, a fortiori, means there are no product > builds where you can install minimal debug info. Unfortunately, that > includes the currently available early access program builds which don't > ship libjvm.debuginfo. > > Ok, so why also the b119 restriction? That's because between b118 and > b119 the stack and code heap layouts changed and this required the > unwinder code to change accordingly. An older version of the unwinder > did work with b118 and earlier builds but tempus fugit, hey ho .... > > > How does it do that? > -------------------- > > For those who are curious the python code is your friend (apologies for > my python noobness -- I mean, eeeuurrrggghhh, python :-). Basically, the > unwinder works without change to the JVM because it understands a few > details of how: > > the code cache is laid out > code blobs/methods are organised > bci-to-line number maps are organized > code address-to-bci maps are organized > > So, essentially, it uses the gdb inferior access functions to poke > around in JVM memory, allowing it to work out what the state of the > stack is and what method, file, bci and line number a specific > instruction address corresponds to. That includes using gdb to resolve a > few symbols in order to identify memory layouts and a few important > global addresses. > > This dependency has been kept to a bare minimum so that the unwinder > will be as resilient as possible to changes in the JVM. > > Can we have this in OpenJDK? > ---------------------------- > > The current code is LGPL licensed. I'd be very happy to contribute it to > OpenJDK as part of the code tools set for JDK developers to use and Red > Hat would be very happy to maintain it once included. Ideally, Red Hat > would like to ship the tool as part of OpenJDK product releases for use > in any distro where minimal debug info is available with the product > release. We see great benefit in the opportunity it provides for support > staff to print stack traces from core files (clearly, shipping with > OpenJDK would help to ensure that changes in the JVM and required > changes in the python code were able to be kept in sync). > > I have copied this note to the code-tools-dev list on the assumption > that it is the correct place to open up discussion of whether it > could/should be provided as part of OpenJDK. If not can someone please > let me know where else I should start that discussion. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander > > ----- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< --- > > Normal gdb backtrace for java thread fails ot unwind through Java frames > > (gdb) thread 16 > [Switching to thread 16 (Thread 0x7fffa1fff700 (LWP 4930))] > #0 0x00007fffe1113484 in ?? () > (gdb) bt 3 > #0 0x00007fffe1113484 in ?? () > #1 0x00007fffd3c00c18 in ?? () > #2 0x0000000000000000 in ?? () > > Backtrace with the unwinder installed > > (gdb) thread 2 > [Switching to thread 2 (Thread 0x7ffff7fcc700 (LWP 4906))] > #0 0x00007ffff79b6540 in pthread_cond_wait@@GLIBC_2.3.2 () > from /lib64/libpthread.so.0 > (gdb) bt 10 > #0 0x00007ffff79b6540 in pthread_cond_wait@@GLIBC_2.3.2 () > at /lib64/libpthread.so.0 > #1 0x00007ffff64ae82d in os::PlatformEvent::park() (this=0x7ffff0019700) > at > /home/adinn/redhat/openjdk/jdk9/hs/hotspot/src/os/linux/vm/os_linux.cpp:5582 > #2 0x00007ffff6486f59 in ObjectMonitor::wait(long, bool, Thread*) > (this=0x7fff90008b80, millis=0, interruptible=true, > __the_thread__=0x7ffff0018800) > at > /home/adinn/redhat/openjdk/jdk9/hs/hotspot/src/share/vm/runtime/objectMonitor.cpp:1490 > #3 0x00007ffff66518cb in ObjectSynchronizer::wait(Handle, long, > Thread*) (obj=..., millis=0, __the_thread__=0x7ffff0018800) > at > /home/adinn/redhat/openjdk/jdk9/hs/hotspot/src/share/vm/runtime/synchronizer.cpp:496 > #4 0x00007ffff618fa54 in JVM_MonitorWait(JNIEnv*, jobject, jlong) > (env=0x7ffff0018a28, handle=0x7ffff7fcb738, ms=0) > at > /home/adinn/redhat/openjdk/jdk9/hs/hotspot/src/share/vm/prims/jvm.cpp:614 > #5 0x00007fffd8924f7d in [interpreted: bc = 0] > java.lang.Object.wait(long) () > at java/lang/Object.java > #6 0x00007fffd89034a3 in [interpreted: bc = 38] > java.lang.Thread.join(long) () at java/lang/Thread.java:1352 > #7 0x00007fffd89034a3 in [interpreted: bc = 2] java.lang.Thread.join() () > at java/lang/Thread.java:1426 > #8 0x00007fffd89034a3 in [interpreted: bc = 35] > HelloV.main(java.lang.String) () at HelloV.java:80 > #9 0x00007fffd88f89f1 in StubRoutines (1) () > #10 0x00007ffff6109bb3 in JavaCalls::call_helper(JavaValue*, > methodHandle const&, JavaCallArguments*, Thread*) > (result=0x7ffff7fcbd30, method=..., args=0x7ffff7fcbc10, > __the_thread__=0x7ffff0018800) > at > /home/adinn/redhat/openjdk/jdk9/hs/hotspot/src/share/vm/runtime/javaCalls.cpp:409 > (gdb) thread 26 > [Switching to thread 26 (Thread 0x7fffa1fff700 (LWP 4930))] > #0 0x00007fffe03cb664 in ?? () > (gdb) bt 5 > #0 0x00007fffe03cb664 in [compiled offset = 0x3a4] HelloV$1.run() () > at HelloV.java:63 > #1 0x00007fffd88f89f1 in StubRoutines (1) () > #2 0x00007ffff6109bb3 in JavaCalls::call_helper(JavaValue*, > methodHandle const&, JavaCallArguments*, Thread*) > (result=0x7fffa1ffecc0, method=..., args=0x7fffa1ffec00, > __the_thread__=0x7ffff0471800) > at > /home/adinn/redhat/openjdk/jdk9/hs/hotspot/src/share/vm/runtime/javaCalls.cpp:409 > #3 0x00007ffff64ad409 in os::os_exception_wrapper(void (*)(JavaValue*, > methodHandle const&, JavaCallArguments*, Thread*), JavaValue*, > methodHandle const&, JavaCallArguments*, Thread*) (f=0x7ffff610951a > JavaCallArguments*, Thread*)>, value=0x7fffa1ffecc0, method=..., > args=0x7fffa1ffec00, thread=0x7ffff0471800) > at > /home/adinn/redhat/openjdk/jdk9/hs/hotspot/src/os/linux/vm/os_linux.cpp:5128 > #4 0x00007ffff6109502 in JavaCalls::call(JavaValue*, methodHandle > const&, JavaCallArguments*, Thread*) (result=0x7fffa1ffecc0, method=..., > args=0x7fffa1ffec00, __the_thread__=0x7ffff0471800) > at > /home/adinn/redhat/openjdk/jdk9/hs/hotspot/src/share/vm/runtime/javaCalls.cpp:298 > #5 0x00007ffff610877b in JavaCalls::call_virtual(JavaValue*, > KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) > (result=0x7fffa1ffecc0, spec_klass=..., name=0x7ffff4031338, > signature=0x7ffff4033220, args=0x7fffa1ffec00, > __the_thread__=0x7ffff0471800) > at > /home/adinn/redhat/openjdk/jdk9/hs/hotspot/src/share/vm/runtime/javaCalls.cpp:193 > (gdb) > > > > From staffan.larsen at oracle.com Tue May 31 13:20:00 2016 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Tue, 31 May 2016 15:20:00 +0200 Subject: Java stack unwinder for Linux + gdb7.10+ In-Reply-To: <574D8E13.1040404@oracle.com> References: <574D6F5A.1090206@redhat.com> <574D8D1B.1040408@redhat.com> <574D8E13.1040404@oracle.com> Message-ID: Adding this to the hotspot repo sounds like the way to go. I would suggest, though, that the scripts come with a comprehensive set of tests so that we find out when changes break the scripts. This would avoid the sad state that the serviceability agent is currently in. /Staffan > On 31 maj 2016, at 15:13, Mikael Gerdin wrote: > > Hi Andrew, > > On 2016-05-31 15:09, Andrew Dinn wrote: >> I probably should have sent this here initially rather than to jdk9-dev. >> Anyway, I hope subscribers to this list will find this interesting. > > I saw it, tried it and it worked after replacing a bunch of > - except Exception, arg: > + except Exception as arg: > > and adjusting the sources to account for jdk 9 changes which I don't yet have in my project workspace. > > I think it might make more sense to put this in the hotspot repo, similar to the serviceability agent, since it's functionality is tied to a particular revision of the sources. > > /Mikael > >> >> regards, >> >> >> Andrew Dinn >> ----------- >> >> -------- Forwarded Message -------- >> Subject: Java stack unwinder for Linux + gdb7.10+ >> Date: Tue, 31 May 2016 12:02:50 +0100 >> From: Andrew Dinn >> To: jdk9-dev at openjdk.java.net >> CC: code-tools-dev at openjdk.java.net >> >> What's this all about? >> ---------------------- >> >> Recently, I have been working on implementing support for unwinding Java >> stacks in gdb using the new python stack unwinder API provided from gdb >> 7.10.1 onwards. I have managed to provide a pure python solution i.e. >> one that that needs no modifications to the VM itself. So, if you use >> gdb to debug operation of the JVM then this implementation will allow >> you to use the bt command as $DEITY (and, indeed, the gdb team) intended. >> >> Attached at the bottom of this note is a before and after showing how >> backtraces look without/with this package installed. >> >> Note that the unwinder works when using gdb to debug either a live >> process or a core file. >> >> Also, note that at present gdb only uses python unwinders to display >> frame info underneath the bt command. I am working with the gdb devs to >> see if they can extend the use of the unwinder to other situations e.g. >> to display the current frame when single-stepping. >> >> Can I try it out? >> ----------------- >> >> Yes, please do! >> >> Indeed, I am posting this to jdk9-dev because I want as many people as >> possible to try out the unwinder and provide feedback on how it works. >> So, please use it and respond -- positive or negative I would love to >> hear what you think. I'm happy to hear offline or on this list. You >> choose whether or not you think others on this list might want to hear >> your comments. >> >> How do I obtain/use it? >> ----------------------- >> >> The unwinder code is available from the following hg repo >> >> http://icedtea.classpath.org/people/adinn/unwinder >> >> See the README in that repo for details of how to install and use it >> (gdb will auto-load it once you have configured things correctly) >> >> To summarize some important details: >> >> The extension requires gdb 7.10+ and you there are two unwinder >> implementations, one for jdk8 and one for jdk9. >> >> The jdk8 unwinder should work for any jdk8 built from the jdk8u repo. >> In particular, it will work for /product releases/ available with your >> Linux distro so long as the distro supports installation of minimal >> debuginfo for those releases. For example, if you are using RHEL or >> fedora then you can simply debuginfo-install the debug info >> corresponding to your jdk8 java package and then install the uinwinder >> under /etc/alternatives/java_sdk_1.8.0. If you want to use it with your >> own jdk8 build then you need to build a debug release which includes a >> libjvm.debuginfo product (well, I guess you could always hack the >> product make process so it generates libjvm.debuginfo ). >> >> The jdk9 unwinder will only work for your own debug builds and even >> then only for builds which include the b119 tag. It doesn't work for >> product builds because ... well, there are no product builds available >> from any distros just yet which, a fortiori, means there are no product >> builds where you can install minimal debug info. Unfortunately, that >> includes the currently available early access program builds which don't >> ship libjvm.debuginfo. >> >> Ok, so why also the b119 restriction? That's because between b118 and >> b119 the stack and code heap layouts changed and this required the >> unwinder code to change accordingly. An older version of the unwinder >> did work with b118 and earlier builds but tempus fugit, hey ho .... >> >> >> How does it do that? >> -------------------- >> >> For those who are curious the python code is your friend (apologies for >> my python noobness -- I mean, eeeuurrrggghhh, python :-). Basically, the >> unwinder works without change to the JVM because it understands a few >> details of how: >> >> the code cache is laid out >> code blobs/methods are organised >> bci-to-line number maps are organized >> code address-to-bci maps are organized >> >> So, essentially, it uses the gdb inferior access functions to poke >> around in JVM memory, allowing it to work out what the state of the >> stack is and what method, file, bci and line number a specific >> instruction address corresponds to. That includes using gdb to resolve a >> few symbols in order to identify memory layouts and a few important >> global addresses. >> >> This dependency has been kept to a bare minimum so that the unwinder >> will be as resilient as possible to changes in the JVM. >> >> Can we have this in OpenJDK? >> ---------------------------- >> >> The current code is LGPL licensed. I'd be very happy to contribute it to >> OpenJDK as part of the code tools set for JDK developers to use and Red >> Hat would be very happy to maintain it once included. Ideally, Red Hat >> would like to ship the tool as part of OpenJDK product releases for use >> in any distro where minimal debug info is available with the product >> release. We see great benefit in the opportunity it provides for support >> staff to print stack traces from core files (clearly, shipping with >> OpenJDK would help to ensure that changes in the JVM and required >> changes in the python code were able to be kept in sync). >> >> I have copied this note to the code-tools-dev list on the assumption >> that it is the correct place to open up discussion of whether it >> could/should be provided as part of OpenJDK. If not can someone please >> let me know where else I should start that discussion. >> >> regards, >> >> >> Andrew Dinn >> ----------- >> Senior Principal Software Engineer >> Red Hat UK Ltd >> Registered in England and Wales under Company Registration No. 03798903 >> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander >> >> ----- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< --- >> >> Normal gdb backtrace for java thread fails ot unwind through Java frames >> >> (gdb) thread 16 >> [Switching to thread 16 (Thread 0x7fffa1fff700 (LWP 4930))] >> #0 0x00007fffe1113484 in ?? () >> (gdb) bt 3 >> #0 0x00007fffe1113484 in ?? () >> #1 0x00007fffd3c00c18 in ?? () >> #2 0x0000000000000000 in ?? () >> >> Backtrace with the unwinder installed >> >> (gdb) thread 2 >> [Switching to thread 2 (Thread 0x7ffff7fcc700 (LWP 4906))] >> #0 0x00007ffff79b6540 in pthread_cond_wait@@GLIBC_2.3.2 () >> from /lib64/libpthread.so.0 >> (gdb) bt 10 >> #0 0x00007ffff79b6540 in pthread_cond_wait@@GLIBC_2.3.2 () >> at /lib64/libpthread.so.0 >> #1 0x00007ffff64ae82d in os::PlatformEvent::park() (this=0x7ffff0019700) >> at >> /home/adinn/redhat/openjdk/jdk9/hs/hotspot/src/os/linux/vm/os_linux.cpp:5582 >> #2 0x00007ffff6486f59 in ObjectMonitor::wait(long, bool, Thread*) >> (this=0x7fff90008b80, millis=0, interruptible=true, >> __the_thread__=0x7ffff0018800) >> at >> /home/adinn/redhat/openjdk/jdk9/hs/hotspot/src/share/vm/runtime/objectMonitor.cpp:1490 >> #3 0x00007ffff66518cb in ObjectSynchronizer::wait(Handle, long, >> Thread*) (obj=..., millis=0, __the_thread__=0x7ffff0018800) >> at >> /home/adinn/redhat/openjdk/jdk9/hs/hotspot/src/share/vm/runtime/synchronizer.cpp:496 >> #4 0x00007ffff618fa54 in JVM_MonitorWait(JNIEnv*, jobject, jlong) >> (env=0x7ffff0018a28, handle=0x7ffff7fcb738, ms=0) >> at >> /home/adinn/redhat/openjdk/jdk9/hs/hotspot/src/share/vm/prims/jvm.cpp:614 >> #5 0x00007fffd8924f7d in [interpreted: bc = 0] >> java.lang.Object.wait(long) () >> at java/lang/Object.java >> #6 0x00007fffd89034a3 in [interpreted: bc = 38] >> java.lang.Thread.join(long) () at java/lang/Thread.java:1352 >> #7 0x00007fffd89034a3 in [interpreted: bc = 2] java.lang.Thread.join() () >> at java/lang/Thread.java:1426 >> #8 0x00007fffd89034a3 in [interpreted: bc = 35] >> HelloV.main(java.lang.String) () at HelloV.java:80 >> #9 0x00007fffd88f89f1 in StubRoutines (1) () >> #10 0x00007ffff6109bb3 in JavaCalls::call_helper(JavaValue*, >> methodHandle const&, JavaCallArguments*, Thread*) >> (result=0x7ffff7fcbd30, method=..., args=0x7ffff7fcbc10, >> __the_thread__=0x7ffff0018800) >> at >> /home/adinn/redhat/openjdk/jdk9/hs/hotspot/src/share/vm/runtime/javaCalls.cpp:409 >> (gdb) thread 26 >> [Switching to thread 26 (Thread 0x7fffa1fff700 (LWP 4930))] >> #0 0x00007fffe03cb664 in ?? () >> (gdb) bt 5 >> #0 0x00007fffe03cb664 in [compiled offset = 0x3a4] HelloV$1.run() () >> at HelloV.java:63 >> #1 0x00007fffd88f89f1 in StubRoutines (1) () >> #2 0x00007ffff6109bb3 in JavaCalls::call_helper(JavaValue*, >> methodHandle const&, JavaCallArguments*, Thread*) >> (result=0x7fffa1ffecc0, method=..., args=0x7fffa1ffec00, >> __the_thread__=0x7ffff0471800) >> at >> /home/adinn/redhat/openjdk/jdk9/hs/hotspot/src/share/vm/runtime/javaCalls.cpp:409 >> #3 0x00007ffff64ad409 in os::os_exception_wrapper(void (*)(JavaValue*, >> methodHandle const&, JavaCallArguments*, Thread*), JavaValue*, >> methodHandle const&, JavaCallArguments*, Thread*) (f=0x7ffff610951a >> > JavaCallArguments*, Thread*)>, value=0x7fffa1ffecc0, method=..., >> args=0x7fffa1ffec00, thread=0x7ffff0471800) >> at >> /home/adinn/redhat/openjdk/jdk9/hs/hotspot/src/os/linux/vm/os_linux.cpp:5128 >> #4 0x00007ffff6109502 in JavaCalls::call(JavaValue*, methodHandle >> const&, JavaCallArguments*, Thread*) (result=0x7fffa1ffecc0, method=..., >> args=0x7fffa1ffec00, __the_thread__=0x7ffff0471800) >> at >> /home/adinn/redhat/openjdk/jdk9/hs/hotspot/src/share/vm/runtime/javaCalls.cpp:298 >> #5 0x00007ffff610877b in JavaCalls::call_virtual(JavaValue*, >> KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) >> (result=0x7fffa1ffecc0, spec_klass=..., name=0x7ffff4031338, >> signature=0x7ffff4033220, args=0x7fffa1ffec00, >> __the_thread__=0x7ffff0471800) >> at >> /home/adinn/redhat/openjdk/jdk9/hs/hotspot/src/share/vm/runtime/javaCalls.cpp:193 >> (gdb) >> >> >> >> From igor.ignatyev at oracle.com Tue May 31 13:29:59 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 31 May 2016 16:29:59 +0300 Subject: RFR(XXS) : 8158185 : jdk/test/lib/FileInstaller throws NPE if dst is in current directory In-Reply-To: <75237a6f-6688-9a3d-7c39-2debd2850271@oracle.com> References: <6631E47C-2183-4642-9553-85172DADB936@oracle.com> <75237a6f-6688-9a3d-7c39-2debd2850271@oracle.com> Message-ID: Hi Vladimir, 1st of all, thank you for reviewing all these changes! regarding testing, I run all changed tests locally on mac and run all hotspot/compiler tests remotely on all supported platforms in fastdebug, product variant w/ Xcomp,Xmixed. this particular fix was tested as a part of JDK-8158184 testing. Thanks, ? Igor > On May 31, 2016, at 5:14 AM, Vladimir Kozlov wrote: > > Looks good. > > Igor, how are you testing all these tests fixes? > > Thanks, > Vladimir > > On 5/30/16 5:08 PM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev/8158185/webrev.00/ >>> 2 lines changed: 0 ins; 0 del; 2 mod; >> >> Hi all, >> >> could you please review this small changeset which fixes FileInstaller? FileInstaller throws NPE if 2nd argument (dst) is in current directory, this happens because Path::getParent returns null if Path doesn?t have a parent. to prevent this, I added Path::toAbsolutePath call. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8158185 >> webrev: http://cr.openjdk.java.net/~iignatyev/8158185/webrev.00/ >> >> Thanks, >> ? Igor >> From christian.tornqvist at oracle.com Tue May 31 14:16:15 2016 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Tue, 31 May 2016 10:16:15 -0400 Subject: RFR(S): 8158106 - native/GTestWrapper.java gets SIGABRT Message-ID: <27a001d1bb46$fe3d2560$fab77020$@oracle.com> Hi everyone, Please review this small change that fixes the native/GTestWrapper.java test, it incorrectly passes on external VM options to the unit test launcher. Removed the code that passes on the arguments. Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8158106/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8158106 Thanks, Christian From adinn at redhat.com Tue May 31 14:46:14 2016 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 31 May 2016 15:46:14 +0100 Subject: Fwd: Java stack unwinder for Linux + gdb7.10+ In-Reply-To: <574D8E13.1040404@oracle.com> References: <574D6F5A.1090206@redhat.com> <574D8D1B.1040408@redhat.com> <574D8E13.1040404@oracle.com> Message-ID: <574DA3B6.10807@redhat.com> On 31/05/16 14:13, Mikael Gerdin wrote: > On 2016-05-31 15:09, Andrew Dinn wrote: >> I probably should have sent this here initially rather than to jdk9-dev. >> Anyway, I hope subscribers to this list will find this interesting. > > I saw it, tried it and it worked after replacing a bunch of > - except Exception, arg: > + except Exception as arg: Hmm, this one's python fu is strong ... well, stronger than mine (doesn't take too much :-) Thanks for trying it and reporting back. I'm not really sure why that change works for you and the original does not. Could you provide info as to what error occurred before the change? and/or explain why the change is needed? > and adjusting the sources to account for jdk 9 changes which I don't yet > have in my project workspace. Yes, sorry for that. n.b. if you wind my hg repo back a bit a few commits you get a jdk9 version of dbg.py that works with b118 and predecessors (if you fixed it /without/ doing that I'm even more impressed :). > I think it might make more sense to put this in the hotspot repo, > similar to the serviceability agent, since it's functionality is tied to > a particular revision of the sources. Yes, that would be the preferred option. It should mean we will always have compatible versions modulo, worst case, minor breakages should the odd JVM change inadvertently break it. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From adinn at redhat.com Tue May 31 14:52:53 2016 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 31 May 2016 15:52:53 +0100 Subject: Java stack unwinder for Linux + gdb7.10+ In-Reply-To: References: <574D6F5A.1090206@redhat.com> <574D8D1B.1040408@redhat.com> <574D8E13.1040404@oracle.com> Message-ID: <574DA545.5040602@redhat.com> On 31/05/16 14:20, Staffan Larsen wrote: > Adding this to the hotspot repo sounds like the way to go. > > I would suggest, though, that the scripts come with a comprehensive > set of tests so that we find out when changes break the scripts. This > would avoid the sad state that the serviceability agent is currently > in. Thanks for also trying it, Steffan. I am glad to hear you think it is worth including in the repo. I doubt that changes which break this tool will occur with any great frequency. Even so I think an automated test suite is a necessity. gdb does provide support for scripting automatic tests of debugger functionality. I'll look into this to see if I can find some way of automatically testing at least the basic functionality. However, I think I'm probably going to need some help from the build team shoe-horning any such tests into the build system. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From mikael.gerdin at oracle.com Tue May 31 14:55:46 2016 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 31 May 2016 16:55:46 +0200 Subject: Fwd: Java stack unwinder for Linux + gdb7.10+ In-Reply-To: <574DA3B6.10807@redhat.com> References: <574D6F5A.1090206@redhat.com> <574D8D1B.1040408@redhat.com> <574D8E13.1040404@oracle.com> <574DA3B6.10807@redhat.com> Message-ID: <574DA5F2.40309@oracle.com> On 2016-05-31 16:46, Andrew Dinn wrote: > On 31/05/16 14:13, Mikael Gerdin wrote: >> On 2016-05-31 15:09, Andrew Dinn wrote: >>> I probably should have sent this here initially rather than to jdk9-dev. >>> Anyway, I hope subscribers to this list will find this interesting. >> >> I saw it, tried it and it worked after replacing a bunch of >> - except Exception, arg: >> + except Exception as arg: > > Hmm, this one's python fu is strong ... well, stronger than mine > (doesn't take too much :-) I doubt that :) > > Thanks for trying it and reporting back. I'm not really sure why that > change works for you and the original does not. Could you provide info > as to what error occurred before the change? and/or explain why the > change is needed? I tried it on the default gdb/python combo shipping on Ubuntu 15.10. My approach to solving it was to google "python try except", noticing that the official Python 3.5 docs contain code like "except Exception as foo" and applying the fix. I have no idea why or how it's supposed to work. > >> and adjusting the sources to account for jdk 9 changes which I don't yet >> have in my project workspace. > > Yes, sorry for that. n.b. if you wind my hg repo back a bit a few > commits you get a jdk9 version of dbg.py that works with b118 and > predecessors (if you fixed it /without/ doing that I'm even more > impressed :). I just did a vimdiff of dbg.py and dbg8.py and replaced all the references to CompiledMethod and CodeBlob related stuff with the ones from the dbg8.py where it seemed appropriate. /Mikael > >> I think it might make more sense to put this in the hotspot repo, >> similar to the serviceability agent, since it's functionality is tied to >> a particular revision of the sources. > > Yes, that would be the preferred option. It should mean we will always > have compatible versions modulo, worst case, minor breakages should the > odd JVM change inadvertently break it. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander > From aleksey.shipilev at gmail.com Fri May 27 13:34:13 2016 From: aleksey.shipilev at gmail.com (Aleksey Shipilev) Date: Fri, 27 May 2016 16:34:13 +0300 Subject: RFR (M) 8157726: VarHandles/Unsafe should support sub-word atomic ops Message-ID: <57484CD5.3050706@gmail.com> (Please note this work is covered with FC exception) Hi, Please review the VarHandles/Unsafe support for sub-word atomic ops: https://bugs.openjdk.java.net/browse/JDK-8157726 Webrevs: http://cr.openjdk.java.net/~shade/8157726/webrev.hs.03/ http://cr.openjdk.java.net/~shade/8157726/webrev.jdk.03/ It *looks* like a lot of changes, but the bulk of changes are in tests, and the rest of product code is mostly duplicating the existing cases for the new code. Tour of the changes: Unsafe.java: *) Implements the baseline implementation for subword CASes, which does the CAS loop within an aligned integer word. While we could potentially detect 64-bit platform and do aligned long word instead, this complicates implementation for no reason. 32-bit CASes are ubiquitous. *) Provides the entry points for VarHandles implementation. While Unsafe provides the implementation for byte/short atomic ops only, it also provides the boolean/char versions that are trivially implementable with byte/short ops. While we could instead make VarHandles do this conversion, it proved harder to do this in VarHandle templates, rather than in Unsafe. *) Consistently uses weakCompareAndSetVolatile for CAS loops, in both new and old code, which is important for a fallback implementation to work well on non-x86 platforms. VarHandles*: *) Now mentions subword atomic ops are available in method spec. CCC is in progress. *) VarHandle templates are slightly modified to do narrowing conversions for shorter-than-int types. This keeps us from putting the entire family of addAndGet methods to Unsafe. *) Test templates are changed to accommodate new code shapes, and also change the bit patterns we use to detect endianness issues. ------ everything above does functionally complete subword ops ------ ------- everything below is the key performance optimization -------- Platform-independent changes: *) vmSymbols.hpp, library_call.cpp and other changes: the usual set of scaffolding for Unsafe intrinsics. We reuse most of the infrastructure, adding new nodes/cases in the existing code. *) Unsafe tests are changed to accommodate new code shapes, and also change the bit patterns we use to detect endianness issues. x86-specific changes: *) Full set of new x86_{32|64} intrinsics are provided in .ad/assembler_x86 files. Supporting 8-byte and 16-byte ops required introducing new operations in x86 assembler. These are tested by compiler/unsafe tests, which are designed to test int/C1/C2 implementations. Performance data justifies the change, and highlights pitfalls: http://cr.openjdk.java.net/~shade/8157726/notes.txt Testing: eyeballing assembly; targeted microbenchmarks; {java/lang/invoke/VarHandles, compiler/unsafe} tests on x86_{32|64}, POWER7; RBT hs-comp-tier0. Thanks, -Aleksey From jlent at tivo.com Fri May 27 13:21:45 2016 From: jlent at tivo.com (James Lent) Date: Fri, 27 May 2016 09:21:45 -0400 Subject: Unexplained Jumps In Response Time "Fixed" By Disabling Tiered Compilation In-Reply-To: <574815D8.7050500@redhat.com> References: <5745B7B5.7040707@tivo.com> <574815D8.7050500@redhat.com> Message-ID: <574849E9.9020702@tivo.com> Thanks for the suggestion. I did turn that option on. I should have mentioned it in my original post. There is typically some JIT activity at the time of the jump, but, no more or less than "usual" (as far as I could tell). I was hoping to see either a lot of activity or some low level Lucene method get recompiled or made not entrant in the minute between the last "good" response time and the first "bad" response time. I could not see a pattern. On 25/05/16 15:33, James Lent wrote: . . . I then tried turning off Tiered Compilation (without changing the default Code Cache size) in dev and the problem went away. Of course it is hard to prove a negative. We are now testing in production with good results (over 40 hours of good performance). Any thoughts? I realize this is not much to go on, but, I thought I would report my issue just in case you get other reports like this and you start to see a pattern. Have you tried turning on listing compiles with -XX:+PrintCompilation? It would be very interesting to see what sort of compile activity is going on around the time that the jumps in response times occur. A comparison between +TieredCompilation and -ToetredCompilation might be very informative. regards, Andrew Dinn ----------- James Lent Senior Software Engineer Digitalsmiths A TiVo Company www.digitalsmiths.com jlent at digitalsmiths.com | office 919.460.4747 ________________________________ This email and any attachments may contain confidential and privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments) by others is prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete this email and any attachments. No employee or agent of TiVo Inc. is authorized to conclude any binding agreement on behalf of TiVo Inc. by email. Binding agreements with TiVo Inc. may only be made by a signed written agreement. From jlent at tivo.com Mon May 30 18:30:34 2016 From: jlent at tivo.com (James Lent) Date: Mon, 30 May 2016 14:30:34 -0400 Subject: Unexplained Jumps In Response Time "Fixed" By Disabling Tiered Compilation In-Reply-To: <574815D8.7050500@redhat.com> References: <5745B7B5.7040707@tivo.com> <574815D8.7050500@redhat.com> Message-ID: <574C86CA.6030505@tivo.com> One update. In my original email I noted that we had tried turning off Tiered Compilation in production and had experienced 40 hours of good results. I spoke 20 hours too early. At about 60 hours the response time spiked to levels much higher than before (2 sec response times became 20 second response times) yet from a heap and CPU point of view the service appeared OK (heap usage actually slowed as more traffic switched to the other node, CPU usage went up but there was still plenty of capacity left). Code Cache usage had levelled off at about 25mb out of the 48mb limit. A restart fixed the issue (after turning Tiered Compilation back on). I was able to reproduce the same symptoms in a dev environment after running light traffic for about 71 hours (slow replay of production queries). The big spike in response time occurred at the same time I started to see HotSpot logs like the following: made not compilable on levels 0 1 2 3 4 java.lang.String::equals (81 bytes) decompile_count > PerMethodRecompilationCutoff made not compilable on levels 0 1 2 3 4 org.apache.lucene.util.OpenBitSetIterator::nextDoc (136 bytes) decompile_count > PerMethodRecompilationCutoff made not compilable on levels 0 1 2 3 4 org.apache.lucene.index.TermInfosReader$CloneableTerm::hashCode (8 bytes) decompile_count > PerMethodRecompilationCutoff made not compilable on levels 0 1 2 3 4 org.apache.solr.search.SolrConstantScoreQuery$ConstantScorer::score (5 bytes) decompile_count > PerMethodRecompilationCutoff made not compilable on levels 0 1 2 3 4 org.roaringbitmap.Util::fillArrayAND (92 bytes) decompile_count > PerMethodRecompilationCutoff They continued to come out for several hours: * Before 2PM - 0 logs * 2PM to 3PM - 1 log * 3PM to 4PM - 38 logs * 4PM to 5PM - 30 logs * 5PM to 6PM - 22 logs * 6PM to 7PM - 64 logs Many were related to low level (high usage) Java, Solr, Lucene, and RoaringBitMap methods. I think this log means that the HotSpot compiler has recompiled these methods 400 times and has now given up and left them in byte code. This is strange, but, would certainly explain the spike in response time. Given all that my questions are: 1) Is my interpretation of these logs correct? 2) What would trigger the HotSpot compiler to keep recompiling these methods over and over? 3) Would increasing the Code Cache size help (it seems to revert to its old max of 48m when Tiered Compilation is disabled)? I doubt it, but, I am giving it try in my dev environment. 4) Is it worth considering setting PerMethodRecompilationCutoff to '-1' (disable it)? Thanks in advance for any help you can provide. Jim > On 25/05/16 15:33, James Lent wrote: > . . . >> I then tried turning off Tiered Compilation (without changing the >> default Code Cache size) in dev and the problem went away. Of course it >> is hard to prove a negative. We are now testing in production with good >> results (over 40 hours of good performance). >> >> Any thoughts? I realize this is not much to go on, but, I thought I >> would report my issue just in case you get other reports like this and >> you start to see a pattern. > Have you tried turning on listing compiles with -XX:+PrintCompilation? > > It would be very interesting to see what sort of compile activity is > going on around the time that the jumps in response times occur. A > comparison between +TieredCompilation and -ToetredCompilation might be > very informative. > > regards, > > > Andrew Dinn > ----------- > James Lent Senior Software Engineer *Digitalsmiths* A TiVo Company www.digitalsmiths.com jlent at digitalsmiths.com | office 919.460.4747 From jlent at tivo.com Tue May 31 00:22:12 2016 From: jlent at tivo.com (James Lent) Date: Mon, 30 May 2016 20:22:12 -0400 Subject: Unexplained Jumps In Response Time "Fixed" By Disabling Tiered Compilation In-Reply-To: <574C86CA.6030505@tivo.com> References: <5745B7B5.7040707@tivo.com> <574815D8.7050500@redhat.com> <574C86CA.6030505@tivo.com> Message-ID: <574CD934.9080206@tivo.com> On more observation. On Flex Node 1 (the one with the smaller/default Code Cache max) the Code Cache usage graph is very erratic (lots up ups and downs). On Flex Node 0 the graph is much smoother. Speculation: Perhaps there is some rule that tries to uncompile some methods when the Code Cache usage is high (close to max), but, the the problem is that all the compiled code is important and the compiler ends up thrashing. Uncompile a method and then decide to compile it again. This continues until the max decompiles is reached. At that point the response time starts to spike. Just a theory based on no knowledge of the actual code. On 05/30/2016 02:30 PM, James Lent wrote: One update. In my original email I noted that we had tried turning off Tiered Compilation in production and had experienced 40 hours of good results. I spoke 20 hours too early. At about 60 hours the response time spiked to levels much higher than before (2 sec response times became 20 second response times) yet from a heap and CPU point of view the service appeared OK (heap usage actually slowed as more traffic switched to the other node, CPU usage went up but there was still plenty of capacity left). Code Cache usage had levelled off at about 25mb out of the 48mb limit. A restart fixed the issue (after turning Tiered Compilation back on). I was able to reproduce the same symptoms in a dev environment after running light traffic for about 71 hours (slow replay of production queries). The big spike in response time occurred at the same time I started to see HotSpot logs like the following: made not compilable on levels 0 1 2 3 4 java.lang.String::equals (81 bytes) decompile_count > PerMethodRecompilationCutoff made not compilable on levels 0 1 2 3 4 org.apache.lucene.util.OpenBitSetIterator::nextDoc (136 bytes) decompile_count > PerMethodRecompilationCutoff made not compilable on levels 0 1 2 3 4 org.apache.lucene.index.TermInfosReader$CloneableTerm::hashCode (8 bytes) decompile_count > PerMethodRecompilationCutoff made not compilable on levels 0 1 2 3 4 org.apache.solr.search.SolrConstantScoreQuery$ConstantScorer::score (5 bytes) decompile_count > PerMethodRecompilationCutoff made not compilable on levels 0 1 2 3 4 org.roaringbitmap.Util::fillArrayAND (92 bytes) decompile_count > PerMethodRecompilationCutoff They continued to come out for several hours: * Before 2PM - 0 logs * 2PM to 3PM - 1 log * 3PM to 4PM - 38 logs * 4PM to 5PM - 30 logs * 5PM to 6PM - 22 logs * 6PM to 7PM - 64 logs Many were related to low level (high usage) Java, Solr, Lucene, and RoaringBitMap methods. I think this log means that the HotSpot compiler has recompiled these methods 400 times and has now given up and left them in byte code. This is strange, but, would certainly explain the spike in response time. Given all that my questions are: 1) Is my interpretation of these logs correct? 2) What would trigger the HotSpot compiler to keep recompiling these methods over and over? 3) Would increasing the Code Cache size help (it seems to revert to its old max of 48m when Tiered Compilation is disabled)? I doubt it, but, I am giving it try in my dev environment. 4) Is it worth considering setting PerMethodRecompilationCutoff to '-1' (disable it)? Thanks in advance for any help you can provide. Jim On 25/05/16 15:33, James Lent wrote: . . . I then tried turning off Tiered Compilation (without changing the default Code Cache size) in dev and the problem went away. Of course it is hard to prove a negative. We are now testing in production with good results (over 40 hours of good performance). Any thoughts? I realize this is not much to go on, but, I thought I would report my issue just in case you get other reports like this and you start to see a pattern. Have you tried turning on listing compiles with -XX:+PrintCompilation? It would be very interesting to see what sort of compile activity is going on around the time that the jumps in response times occur. A comparison between +TieredCompilation and -ToetredCompilation might be very informative. regards, Andrew Dinn ----------- James Lent Senior Software Engineer Digitalsmiths A TiVo Company www.digitalsmiths.com jlent at digitalsmiths.com | office 919.460.4747 James Lent Senior Software Engineer Digitalsmiths A TiVo Company www.digitalsmiths.com jlent at digitalsmiths.com | office 919.460.4747 ________________________________ This email and any attachments may contain confidential and privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments) by others is prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete this email and any attachments. No employee or agent of TiVo Inc. is authorized to conclude any binding agreement on behalf of TiVo Inc. by email. Binding agreements with TiVo Inc. may only be made by a signed written agreement. From aleksey.shipilev at oracle.com Tue May 31 15:17:24 2016 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Tue, 31 May 2016 18:17:24 +0300 Subject: RFR (M) 8157726: VarHandles/Unsafe should support sub-word atomic ops In-Reply-To: <57484CD5.3050706@gmail.com> References: <57484CD5.3050706@gmail.com> Message-ID: <574DAB04.8040009@oracle.com> Mail glitch: this is an old duplicate, please ignore, use the thread with "[RESEND]" in it. Sorry about this. -Aleksey On 05/27/2016 04:34 PM, Aleksey Shipilev wrote: > (Please note this work is covered with FC exception) > > Hi, > > Please review the VarHandles/Unsafe support for sub-word atomic ops: > https://bugs.openjdk.java.net/browse/JDK-8157726 > > Webrevs: > http://cr.openjdk.java.net/~shade/8157726/webrev.hs.03/ > http://cr.openjdk.java.net/~shade/8157726/webrev.jdk.03/ > > It *looks* like a lot of changes, but the bulk of changes are in tests, > and the rest of product code is mostly duplicating the existing cases > for the new code. > > Tour of the changes: > > Unsafe.java: > > *) Implements the baseline implementation for subword CASes, which > does the CAS loop within an aligned integer word. While we could > potentially detect 64-bit platform and do aligned long word instead, > this complicates implementation for no reason. 32-bit CASes are ubiquitous. > > *) Provides the entry points for VarHandles implementation. While > Unsafe provides the implementation for byte/short atomic ops only, it > also provides the boolean/char versions that are trivially implementable > with byte/short ops. While we could instead make VarHandles do this > conversion, it proved harder to do this in VarHandle templates, rather > than in Unsafe. > > *) Consistently uses weakCompareAndSetVolatile for CAS loops, in both > new and old code, which is important for a fallback implementation to > work well on non-x86 platforms. > > VarHandles*: > > *) Now mentions subword atomic ops are available in method spec. CCC > is in progress. > > *) VarHandle templates are slightly modified to do narrowing > conversions for shorter-than-int types. This keeps us from putting the > entire family of addAndGet methods to Unsafe. > > *) Test templates are changed to accommodate new code shapes, and also > change the bit patterns we use to detect endianness issues. > > ------ everything above does functionally complete subword ops ------ > ------- everything below is the key performance optimization -------- > > Platform-independent changes: > > *) vmSymbols.hpp, library_call.cpp and other changes: the usual set of > scaffolding for Unsafe intrinsics. We reuse most of the infrastructure, > adding new nodes/cases in the existing code. > > *) Unsafe tests are changed to accommodate new code shapes, and also > change the bit patterns we use to detect endianness issues. > > x86-specific changes: > > *) Full set of new x86_{32|64} intrinsics are provided in > .ad/assembler_x86 files. Supporting 8-byte and 16-byte ops required > introducing new operations in x86 assembler. These are tested by > compiler/unsafe tests, which are designed to test int/C1/C2 implementations. > > > Performance data justifies the change, and highlights pitfalls: > http://cr.openjdk.java.net/~shade/8157726/notes.txt > > > Testing: eyeballing assembly; targeted microbenchmarks; > {java/lang/invoke/VarHandles, compiler/unsafe} tests on x86_{32|64}, > POWER7; RBT hs-comp-tier0. > > Thanks, > -Aleksey > From adinn at redhat.com Tue May 31 15:24:53 2016 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 31 May 2016 16:24:53 +0100 Subject: Fwd: Java stack unwinder for Linux + gdb7.10+ In-Reply-To: <574DA5F2.40309@oracle.com> References: <574D6F5A.1090206@redhat.com> <574D8D1B.1040408@redhat.com> <574D8E13.1040404@oracle.com> <574DA3B6.10807@redhat.com> <574DA5F2.40309@oracle.com> Message-ID: <574DACC5.6060905@redhat.com> On 31/05/16 15:55, Mikael Gerdin wrote: > > > On 2016-05-31 16:46, Andrew Dinn wrote: >> Hmm, this one's python fu is strong ... well, stronger than mine >> (doesn't take too much :-) > > I doubt that :) Ha, bluffed again! >> Thanks for trying it and reporting back. I'm not really sure why that >> change works for you and the original does not. Could you provide info >> as to what error occurred before the change? and/or explain why the >> change is needed? > > I tried it on the default gdb/python combo shipping on Ubuntu 15.10. > > My approach to solving it was to google "python try except", noticing > that the official Python 3.5 docs contain code like "except Exception as > foo" and applying the fix. > > I have no idea why or how it's supposed to work. Ok. The syntax I used was an attempt to catch a value string provided as argument to the caught exception (see http://www.tutorialspoint.com/python/python_exceptions.htm if you want to know how it is supposed to work). I suppose it fails because on Ubuntu you can see exceptions created without a value arg. I think that usage was only needed when I was seeing some weird exceptions gdb was throwing up in an early version of the unwinder which would not auto-convert to a string at print time. Those have been avoided by making the unwinder resilient to recursive entry (something gdb ought to guarantee but doesn't yet). So, I'm happy to adopt your patch -- it seems to work fine on Fedora too. I'll push the patch into my repo asap. >> Yes, sorry for that. n.b. if you wind my hg repo back a bit a few >> commits you get a jdk9 version of dbg.py that works with b118 and >> predecessors (if you fixed it /without/ doing that I'm even more >> impressed :). > > I just did a vimdiff of dbg.py and dbg8.py and replaced all the > references to CompiledMethod and CodeBlob related stuff with the ones > from the dbg8.py where it seemed appropriate. Ok, so now I choose to be impressed by your pragmatic empiricism :-) regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From aph at redhat.com Tue May 31 15:25:29 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 31 May 2016 16:25:29 +0100 Subject: Unexplained Jumps In Response Time "Fixed" By Disabling Tiered Compilation In-Reply-To: <574C86CA.6030505@tivo.com> References: <5745B7B5.7040707@tivo.com> <574815D8.7050500@redhat.com> <574C86CA.6030505@tivo.com> Message-ID: <574DACE9.9020704@redhat.com> On 05/30/2016 07:30 PM, James Lent wrote: > 1) Is my interpretation of these logs correct? I think so. > 2) What would trigger the HotSpot compiler to keep recompiling these > methods over and over? Code cache is full. Either that, or there is a nasty bug in the compiler. > 3) Would increasing the Code Cache size help (it seems to revert to its > old max of 48m when Tiered Compilation is disabled)? I doubt it, but, I > am giving it try in my dev environment. Yes. > 4) Is it worth considering setting PerMethodRecompilationCutoff to '-1' > (disable it)? Probably not. Andrew. From kirk.pepperdine at gmail.com Tue May 31 15:30:36 2016 From: kirk.pepperdine at gmail.com (kirk.pepperdine at gmail.com) Date: Tue, 31 May 2016 17:30:36 +0200 Subject: Unexplained Jumps In Response Time "Fixed" By Disabling Tiered Compilation In-Reply-To: <574DACE9.9020704@redhat.com> References: <5745B7B5.7040707@tivo.com> <574815D8.7050500@redhat.com> <574C86CA.6030505@tivo.com> <574DACE9.9020704@redhat.com> Message-ID: <4922BE10-4F6D-4123-BF53-102797BD5AB1@gmail.com> Hi, Mostly lurking? > > >> 2) What would trigger the HotSpot compiler to keep recompiling these >> methods over and over? > > Code cache is full. Either that, or there is a nasty bug in the > compiler. or not full but fragmentated. Code cache full should induce aggressive code cache cleaning but it shouldn?t be cleaning methods that are actually being used. That said, if you?re not seeing methods being made non-entrant/zombie... > >> 3) Would increasing the Code Cache size help (it seems to revert to its >> old max of 48m when Tiered Compilation is disabled)? I doubt it, but, I >> am giving it try in my dev environment. > > Yes. > >> Regards, Kirk From vitalyd at gmail.com Tue May 31 15:40:58 2016 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Tue, 31 May 2016 11:40:58 -0400 Subject: Unexplained Jumps In Response Time "Fixed" By Disabling Tiered Compilation In-Reply-To: <4922BE10-4F6D-4123-BF53-102797BD5AB1@gmail.com> References: <5745B7B5.7040707@tivo.com> <574815D8.7050500@redhat.com> <574C86CA.6030505@tivo.com> <574DACE9.9020704@redhat.com> <4922BE10-4F6D-4123-BF53-102797BD5AB1@gmail.com> Message-ID: IIRC, Tiered compilation tracks method warmth/hotness using a decayed counter (sampled at safepoints). A method may become temporarily cold, get evicted, then become hot again -- rinse & repeat. Given that some traffic shifted away from the server that experienced the perf degradation, that may make these methods go cold. I would try bumping the code cache size more aggressively (and possibly disable tiered compilation -- I believe C2 does not track method warmth at safepoints so assuming a sufficiently large code cache to accommodate all hot methods for the duration of the service, it should not experience code cache churn). On Tue, May 31, 2016 at 11:30 AM, kirk.pepperdine at gmail.com < kirk.pepperdine at gmail.com> wrote: > Hi, > > Mostly lurking? > > > > > > >> 2) What would trigger the HotSpot compiler to keep recompiling these > >> methods over and over? > > > > Code cache is full. Either that, or there is a nasty bug in the > > compiler. > > or not full but fragmentated. Code cache full should induce aggressive > code cache cleaning but it shouldn?t be cleaning methods that are actually > being used. That said, if you?re not seeing methods being made > non-entrant/zombie... > > > >> 3) Would increasing the Code Cache size help (it seems to revert to its > >> old max of 48m when Tiered Compilation is disabled)? I doubt it, but, I > >> am giving it try in my dev environment. > > > > Yes. > > > >> > > Regards, > Kirk > > From dmitry.samersoff at oracle.com Tue May 31 16:25:31 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 31 May 2016 19:25:31 +0300 Subject: Fwd: Java stack unwinder for Linux + gdb7.10+ In-Reply-To: <574D8E13.1040404@oracle.com> References: <574D6F5A.1090206@redhat.com> <574D8D1B.1040408@redhat.com> <574D8E13.1040404@oracle.com> Message-ID: <574DBAFB.1070308@oracle.com> Mikael, > I saw it, tried it and it worked after replacing a bunch of > - except Exception, arg: > + except Exception as arg: Python 2.x (pre 2.7) requires Exception, arg Python 3.x requires Exception as arg Python 2.7 allow both syntax. -Dmitry On 2016-05-31 16:13, Mikael Gerdin wrote: > Hi Andrew, > > On 2016-05-31 15:09, Andrew Dinn wrote: >> I probably should have sent this here initially rather than to jdk9-dev. >> Anyway, I hope subscribers to this list will find this interesting. > > I saw it, tried it and it worked after replacing a bunch of > - except Exception, arg: > + except Exception as arg: > > and adjusting the sources to account for jdk 9 changes which I don't yet > have in my project workspace. > > I think it might make more sense to put this in the hotspot repo, > similar to the serviceability agent, since it's functionality is tied to > a particular revision of the sources. > > /Mikael > >> >> regards, >> >> >> Andrew Dinn >> ----------- >> >> -------- Forwarded Message -------- >> Subject: Java stack unwinder for Linux + gdb7.10+ >> Date: Tue, 31 May 2016 12:02:50 +0100 >> From: Andrew Dinn >> To: jdk9-dev at openjdk.java.net >> CC: code-tools-dev at openjdk.java.net >> >> What's this all about? >> ---------------------- >> >> Recently, I have been working on implementing support for unwinding Java >> stacks in gdb using the new python stack unwinder API provided from gdb >> 7.10.1 onwards. I have managed to provide a pure python solution i.e. >> one that that needs no modifications to the VM itself. So, if you use >> gdb to debug operation of the JVM then this implementation will allow >> you to use the bt command as $DEITY (and, indeed, the gdb team) intended. >> >> Attached at the bottom of this note is a before and after showing how >> backtraces look without/with this package installed. >> >> Note that the unwinder works when using gdb to debug either a live >> process or a core file. >> >> Also, note that at present gdb only uses python unwinders to display >> frame info underneath the bt command. I am working with the gdb devs to >> see if they can extend the use of the unwinder to other situations e.g. >> to display the current frame when single-stepping. >> >> Can I try it out? >> ----------------- >> >> Yes, please do! >> >> Indeed, I am posting this to jdk9-dev because I want as many people as >> possible to try out the unwinder and provide feedback on how it works. >> So, please use it and respond -- positive or negative I would love to >> hear what you think. I'm happy to hear offline or on this list. You >> choose whether or not you think others on this list might want to hear >> your comments. >> >> How do I obtain/use it? >> ----------------------- >> >> The unwinder code is available from the following hg repo >> >> http://icedtea.classpath.org/people/adinn/unwinder >> >> See the README in that repo for details of how to install and use it >> (gdb will auto-load it once you have configured things correctly) >> >> To summarize some important details: >> >> The extension requires gdb 7.10+ and you there are two unwinder >> implementations, one for jdk8 and one for jdk9. >> >> The jdk8 unwinder should work for any jdk8 built from the jdk8u repo. >> In particular, it will work for /product releases/ available with your >> Linux distro so long as the distro supports installation of minimal >> debuginfo for those releases. For example, if you are using RHEL or >> fedora then you can simply debuginfo-install the debug info >> corresponding to your jdk8 java package and then install the uinwinder >> under /etc/alternatives/java_sdk_1.8.0. If you want to use it with your >> own jdk8 build then you need to build a debug release which includes a >> libjvm.debuginfo product (well, I guess you could always hack the >> product make process so it generates libjvm.debuginfo ). >> >> The jdk9 unwinder will only work for your own debug builds and even >> then only for builds which include the b119 tag. It doesn't work for >> product builds because ... well, there are no product builds available >> from any distros just yet which, a fortiori, means there are no product >> builds where you can install minimal debug info. Unfortunately, that >> includes the currently available early access program builds which don't >> ship libjvm.debuginfo. >> >> Ok, so why also the b119 restriction? That's because between b118 and >> b119 the stack and code heap layouts changed and this required the >> unwinder code to change accordingly. An older version of the unwinder >> did work with b118 and earlier builds but tempus fugit, hey ho .... >> >> >> How does it do that? >> -------------------- >> >> For those who are curious the python code is your friend (apologies for >> my python noobness -- I mean, eeeuurrrggghhh, python :-). Basically, the >> unwinder works without change to the JVM because it understands a few >> details of how: >> >> the code cache is laid out >> code blobs/methods are organised >> bci-to-line number maps are organized >> code address-to-bci maps are organized >> >> So, essentially, it uses the gdb inferior access functions to poke >> around in JVM memory, allowing it to work out what the state of the >> stack is and what method, file, bci and line number a specific >> instruction address corresponds to. That includes using gdb to resolve a >> few symbols in order to identify memory layouts and a few important >> global addresses. >> >> This dependency has been kept to a bare minimum so that the unwinder >> will be as resilient as possible to changes in the JVM. >> >> Can we have this in OpenJDK? >> ---------------------------- >> >> The current code is LGPL licensed. I'd be very happy to contribute it to >> OpenJDK as part of the code tools set for JDK developers to use and Red >> Hat would be very happy to maintain it once included. Ideally, Red Hat >> would like to ship the tool as part of OpenJDK product releases for use >> in any distro where minimal debug info is available with the product >> release. We see great benefit in the opportunity it provides for support >> staff to print stack traces from core files (clearly, shipping with >> OpenJDK would help to ensure that changes in the JVM and required >> changes in the python code were able to be kept in sync). >> >> I have copied this note to the code-tools-dev list on the assumption >> that it is the correct place to open up discussion of whether it >> could/should be provided as part of OpenJDK. If not can someone please >> let me know where else I should start that discussion. >> >> regards, >> >> >> Andrew Dinn >> ----------- >> Senior Principal Software Engineer >> Red Hat UK Ltd >> Registered in England and Wales under Company Registration No. 03798903 >> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander >> >> ----- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< --- >> >> Normal gdb backtrace for java thread fails ot unwind through Java frames >> >> (gdb) thread 16 >> [Switching to thread 16 (Thread 0x7fffa1fff700 (LWP 4930))] >> #0 0x00007fffe1113484 in ?? () >> (gdb) bt 3 >> #0 0x00007fffe1113484 in ?? () >> #1 0x00007fffd3c00c18 in ?? () >> #2 0x0000000000000000 in ?? () >> >> Backtrace with the unwinder installed >> >> (gdb) thread 2 >> [Switching to thread 2 (Thread 0x7ffff7fcc700 (LWP 4906))] >> #0 0x00007ffff79b6540 in pthread_cond_wait@@GLIBC_2.3.2 () >> from /lib64/libpthread.so.0 >> (gdb) bt 10 >> #0 0x00007ffff79b6540 in pthread_cond_wait@@GLIBC_2.3.2 () >> at /lib64/libpthread.so.0 >> #1 0x00007ffff64ae82d in os::PlatformEvent::park() (this=0x7ffff0019700) >> at >> /home/adinn/redhat/openjdk/jdk9/hs/hotspot/src/os/linux/vm/os_linux.cpp:5582 >> >> #2 0x00007ffff6486f59 in ObjectMonitor::wait(long, bool, Thread*) >> (this=0x7fff90008b80, millis=0, interruptible=true, >> __the_thread__=0x7ffff0018800) >> at >> /home/adinn/redhat/openjdk/jdk9/hs/hotspot/src/share/vm/runtime/objectMonitor.cpp:1490 >> >> #3 0x00007ffff66518cb in ObjectSynchronizer::wait(Handle, long, >> Thread*) (obj=..., millis=0, __the_thread__=0x7ffff0018800) >> at >> /home/adinn/redhat/openjdk/jdk9/hs/hotspot/src/share/vm/runtime/synchronizer.cpp:496 >> >> #4 0x00007ffff618fa54 in JVM_MonitorWait(JNIEnv*, jobject, jlong) >> (env=0x7ffff0018a28, handle=0x7ffff7fcb738, ms=0) >> at >> /home/adinn/redhat/openjdk/jdk9/hs/hotspot/src/share/vm/prims/jvm.cpp:614 >> #5 0x00007fffd8924f7d in [interpreted: bc = 0] >> java.lang.Object.wait(long) () >> at java/lang/Object.java >> #6 0x00007fffd89034a3 in [interpreted: bc = 38] >> java.lang.Thread.join(long) () at java/lang/Thread.java:1352 >> #7 0x00007fffd89034a3 in [interpreted: bc = 2] >> java.lang.Thread.join() () >> at java/lang/Thread.java:1426 >> #8 0x00007fffd89034a3 in [interpreted: bc = 35] >> HelloV.main(java.lang.String) () at HelloV.java:80 >> #9 0x00007fffd88f89f1 in StubRoutines (1) () >> #10 0x00007ffff6109bb3 in JavaCalls::call_helper(JavaValue*, >> methodHandle const&, JavaCallArguments*, Thread*) >> (result=0x7ffff7fcbd30, method=..., args=0x7ffff7fcbc10, >> __the_thread__=0x7ffff0018800) >> at >> /home/adinn/redhat/openjdk/jdk9/hs/hotspot/src/share/vm/runtime/javaCalls.cpp:409 >> >> (gdb) thread 26 >> [Switching to thread 26 (Thread 0x7fffa1fff700 (LWP 4930))] >> #0 0x00007fffe03cb664 in ?? () >> (gdb) bt 5 >> #0 0x00007fffe03cb664 in [compiled offset = 0x3a4] HelloV$1.run() () >> at HelloV.java:63 >> #1 0x00007fffd88f89f1 in StubRoutines (1) () >> #2 0x00007ffff6109bb3 in JavaCalls::call_helper(JavaValue*, >> methodHandle const&, JavaCallArguments*, Thread*) >> (result=0x7fffa1ffecc0, method=..., args=0x7fffa1ffec00, >> __the_thread__=0x7ffff0471800) >> at >> /home/adinn/redhat/openjdk/jdk9/hs/hotspot/src/share/vm/runtime/javaCalls.cpp:409 >> >> #3 0x00007ffff64ad409 in os::os_exception_wrapper(void (*)(JavaValue*, >> methodHandle const&, JavaCallArguments*, Thread*), JavaValue*, >> methodHandle const&, JavaCallArguments*, Thread*) (f=0x7ffff610951a >> > JavaCallArguments*, Thread*)>, value=0x7fffa1ffecc0, method=..., >> args=0x7fffa1ffec00, thread=0x7ffff0471800) >> at >> /home/adinn/redhat/openjdk/jdk9/hs/hotspot/src/os/linux/vm/os_linux.cpp:5128 >> >> #4 0x00007ffff6109502 in JavaCalls::call(JavaValue*, methodHandle >> const&, JavaCallArguments*, Thread*) (result=0x7fffa1ffecc0, method=..., >> args=0x7fffa1ffec00, __the_thread__=0x7ffff0471800) >> at >> /home/adinn/redhat/openjdk/jdk9/hs/hotspot/src/share/vm/runtime/javaCalls.cpp:298 >> >> #5 0x00007ffff610877b in JavaCalls::call_virtual(JavaValue*, >> KlassHandle, Symbol*, Symbol*, JavaCallArguments*, Thread*) >> (result=0x7fffa1ffecc0, spec_klass=..., name=0x7ffff4031338, >> signature=0x7ffff4033220, args=0x7fffa1ffec00, >> __the_thread__=0x7ffff0471800) >> at >> /home/adinn/redhat/openjdk/jdk9/hs/hotspot/src/share/vm/runtime/javaCalls.cpp:193 >> >> (gdb) >> >> >> >> -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the source code. From aph at redhat.com Tue May 31 16:28:58 2016 From: aph at redhat.com (Andrew Haley) Date: Tue, 31 May 2016 17:28:58 +0100 Subject: Fwd: Java stack unwinder for Linux + gdb7.10+ In-Reply-To: <574DBAFB.1070308@oracle.com> References: <574D6F5A.1090206@redhat.com> <574D8D1B.1040408@redhat.com> <574D8E13.1040404@oracle.com> <574DBAFB.1070308@oracle.com> Message-ID: <574DBBCA.10303@redhat.com> On 05/31/2016 05:25 PM, Dmitry Samersoff wrote: > Python 2.x (pre 2.7) requires Exception, arg > Python 3.x requires Exception as arg > > Python 2.7 allow both syntax. Aiieeee! This reminds me of how great we are in Java about backwards compatibility. Andrew. From HORIE at jp.ibm.com Tue May 31 15:36:38 2016 From: HORIE at jp.ibm.com (Michihiro Horie) Date: Wed, 1 Jun 2016 00:36:38 +0900 Subject: RFR(M): 8158232: PPC64: improve byte, int and long array copy stubs by using VSX instructions Message-ID: <201605311537.u4VFYV1Q029540@mx0a-001b2d01.pphosted.com> Dear all, Could you please review the following webrev? http://cr.openjdk.java.net/~mdoerr/8158232_PPC_vsx_copy/webrev.00/ This change improves performance of disjoint arraycopy of byte, int, and long by using VSX load/store instructions. Discussion started from: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016-May/002483.html Performance improvement with micro benchmarks is shown in: http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2016-May/002531.html Thank you very much, Best regards, -- Michihiro Horie, IBM Research - Tokyo From adinn at redhat.com Tue May 31 16:57:00 2016 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 31 May 2016 17:57:00 +0100 Subject: Fwd: Java stack unwinder for Linux + gdb7.10+ In-Reply-To: <574DBAFB.1070308@oracle.com> References: <574D6F5A.1090206@redhat.com> <574D8D1B.1040408@redhat.com> <574D8E13.1040404@oracle.com> <574DBAFB.1070308@oracle.com> Message-ID: <574DC25C.2070903@redhat.com> On 31/05/16 17:25, Dmitry Samersoff wrote: > Mikael, > >> I saw it, tried it and it worked after replacing a bunch of >> - except Exception, arg: >> + except Exception as arg: > > Python 2.x (pre 2.7) requires Exception, arg > Python 3.x requires Exception as arg > > Python 2.7 allow both syntax. Thanks very much for the clarification, Dmitry. I thought my gdb 7.10.1 was already using python 3 but it seems not. I have been using my own local gdb 7.10 build (my distro package is 7.9) and I expected the build to use the installed python3. However, I think it picked up the (also installed) python 2.7.10 default version when I ran autoconfig on my machine. So, the unwinder scripts definitely need to be changed to employ the later (3.x) syntax. I will also document that you need a gdb version 7.10+ built to use python version 2.7+ and preferably 3.0. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From lois.foltan at oracle.com Tue May 31 17:23:08 2016 From: lois.foltan at oracle.com (Lois Foltan) Date: Tue, 31 May 2016 13:23:08 -0400 Subject: RFR(S): 8158106 - native/GTestWrapper.java gets SIGABRT In-Reply-To: <27a001d1bb46$fe3d2560$fab77020$@oracle.com> References: <27a001d1bb46$fe3d2560$fab77020$@oracle.com> Message-ID: <574DC87C.3040706@oracle.com> Looks good. Lois On 5/31/2016 10:16 AM, Christian Tornqvist wrote: > Hi everyone, > > > > Please review this small change that fixes the native/GTestWrapper.java > test, it incorrectly passes on external VM options to the unit test > launcher. Removed the code that passes on the arguments. > > > > Webrev: > > http://cr.openjdk.java.net/~ctornqvi/webrev/8158106/webrev.00/ > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8158106 > > > > Thanks, > > Christian > From max.ockner at oracle.com Tue May 31 17:39:57 2016 From: max.ockner at oracle.com (Max Ockner) Date: Tue, 31 May 2016 13:39:57 -0400 Subject: RFR: 8157490: null stream->source() no longer causes error with -Xlog:class+load In-Reply-To: <57474AB1.6030407@oracle.com> References: <57473B6F.2010806@oracle.com> <57474AB1.6030407@oracle.com> Message-ID: <574DCC6D.1080208@oracle.com> I like this suggestion and I have updated my fix with it. webrev: http://cr.openjdk.java.net/~mockner/8157490.02/ Thanks, Max On 5/26/2016 3:12 PM, Lois Foltan wrote: > > On 5/26/2016 2:07 PM, Max Ockner wrote: >> Hello, >> >> Please review this very small fix for class+load logging with modules. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8157490 >> Webrev: http://cr.openjdk.java.net/~mockner/8157490/ >> >> Summary: The JCK test >> vm/jni/DefineClass/dfcl001/dfcl00101m1/dfcl00101m1 hit a SIGSEGV in >> the logging section at the end of >> ClassFileParser::fill_instance_klass(). With the addition of modules, >> this logging section now uses >> >> strlen(stream->source()) >> >> to compute some of the module related parameters that it needs. This >> SIGSEGV originated from the above line being executed with a null >> stream source. > > Hi Max, > > I think you change is correct, but I would like to suggest changing > the code even further. Currently the code between line #5352-5360 > does a complicated check to see if the module's name is part of the > java runtime image file and only sets the local variable "module_name" > if it is. So, only module names that are defined within the java > runtime image file are printed out in the logging. We should print out > all modules' names, not just the ones in the jimage file. So please > try removing lines #5352-5360 and set the local variable to: > > const char* module_name = (module_entry->name() == NULL) ? > UNNAMED_MODULE : module_entry->name()->as_C_string(); > > The local variable "module_entry" is already checked at line #5310 to > make sure it is set to a non-NULL value. > > Thanks, > Lois > >> >> Tested with vm/jni/DefineClass/dfcl001/dfcl00101m1/dfcl00101m1 >> >> Thanks, >> Max > From vladimir.kozlov at oracle.com Tue May 31 18:14:55 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 31 May 2016 11:14:55 -0700 Subject: [9] RFR(S): 8156760: VM crashes if -XX:-ReduceInitialCardMarks is set In-Reply-To: <574D7505.9090005@oracle.com> References: <5742CC7F.4050309@oracle.com> <5745C75C.80208@oracle.com> <574BEA7C.3040000@oracle.com> <1464692918.2464.20.camel@oracle.com> <574D7505.9090005@oracle.com> Message-ID: <6d45938b-c7d9-6ea2-7821-4a6344de32f4@oracle.com> Looks good to me. Thanks, Vladimir On 5/31/16 4:27 AM, Tobias Hartmann wrote: > Hi Thomas, > > On 31.05.2016 13:08, Thomas Schatzl wrote: >> Hi Tobias, >> >> On Mon, 2016-05-30 at 09:23 +0200, Tobias Hartmann wrote: >>> Hi, >>> >>> all tests passed (link is attached to the bug). Is everyone fine with >>> the latest webrev? >>> http://cr.openjdk.java.net/~thartmann/8156760/webrev.02/ >>> >> >> I would think it is good. I believe the necessary actions (card >> marking) are taken with -XX:-ReduceInitialCardMarks from the comments, >> in the places I would expect them. However my C2-fu is limited to >> hacking together barriers, so I am honestly unable to verify that the >> code in detail is correct. > > Thanks for looking at this again! > >> Somebody more knowledgable in C2 in general needs to look at this. >> >> If you have time, copyrights may need to be fixed up. I do not need a >> re-review for that. > > Right, I updated the copyright dates in-place. > > Thanks, > Tobias > >> >> Thanks, >> Thomas >> From vladimir.kozlov at oracle.com Tue May 31 18:17:12 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 31 May 2016 11:17:12 -0700 Subject: RFR(XXS) : 8158185 : jdk/test/lib/FileInstaller throws NPE if dst is in current directory In-Reply-To: References: <6631E47C-2183-4642-9553-85172DADB936@oracle.com> <75237a6f-6688-9a3d-7c39-2debd2850271@oracle.com> Message-ID: Good. Thank you. Vladimir On 5/31/16 6:29 AM, Igor Ignatyev wrote: > Hi Vladimir, > > 1st of all, thank you for reviewing all these changes! > > regarding testing, I run all changed tests locally on mac and run all hotspot/compiler tests remotely on all supported platforms in fastdebug, product variant w/ Xcomp,Xmixed. > this particular fix was tested as a part of JDK-8158184 testing. > > Thanks, > ? Igor >> On May 31, 2016, at 5:14 AM, Vladimir Kozlov wrote: >> >> Looks good. >> >> Igor, how are you testing all these tests fixes? >> >> Thanks, >> Vladimir >> >> On 5/30/16 5:08 PM, Igor Ignatyev wrote: >>> http://cr.openjdk.java.net/~iignatyev/8158185/webrev.00/ >>>> 2 lines changed: 0 ins; 0 del; 2 mod; >>> >>> Hi all, >>> >>> could you please review this small changeset which fixes FileInstaller? FileInstaller throws NPE if 2nd argument (dst) is in current directory, this happens because Path::getParent returns null if Path doesn?t have a parent. to prevent this, I added Path::toAbsolutePath call. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8158185 >>> webrev: http://cr.openjdk.java.net/~iignatyev/8158185/webrev.00/ >>> >>> Thanks, >>> ? Igor >>> > From george.triantafillou at oracle.com Tue May 31 18:55:47 2016 From: george.triantafillou at oracle.com (George Triantafillou) Date: Tue, 31 May 2016 14:55:47 -0400 Subject: RFR(S): 8158106 - native/GTestWrapper.java gets SIGABRT In-Reply-To: <574DC87C.3040706@oracle.com> References: <27a001d1bb46$fe3d2560$fab77020$@oracle.com> <574DC87C.3040706@oracle.com> Message-ID: <37be9114-8456-d8c1-5588-0f217f2cd615@oracle.com> +1 -George On 5/31/2016 1:23 PM, Lois Foltan wrote: > Looks good. > Lois > > On 5/31/2016 10:16 AM, Christian Tornqvist wrote: >> Hi everyone, >> >> >> Please review this small change that fixes the native/GTestWrapper.java >> test, it incorrectly passes on external VM options to the unit test >> launcher. Removed the code that passes on the arguments. >> >> >> Webrev: >> >> http://cr.openjdk.java.net/~ctornqvi/webrev/8158106/webrev.00/ >> >> >> Bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8158106 >> >> >> Thanks, >> >> Christian >> > From george.triantafillou at oracle.com Tue May 31 19:02:55 2016 From: george.triantafillou at oracle.com (George Triantafillou) Date: Tue, 31 May 2016 15:02:55 -0400 Subject: RFR(XXS) : 8158185 : jdk/test/lib/FileInstaller throws NPE if dst is in current directory In-Reply-To: <6631E47C-2183-4642-9553-85172DADB936@oracle.com> References: <6631E47C-2183-4642-9553-85172DADB936@oracle.com> Message-ID: <626822b2-31f0-1734-1934-ace8d9441ce6@oracle.com> Hi Igor, Looks good. -George On 5/30/2016 8:08 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev/8158185/webrev.00/ >> 2 lines changed: 0 ins; 0 del; 2 mod; > Hi all, > > could you please review this small changeset which fixes FileInstaller? FileInstaller throws NPE if 2nd argument (dst) is in current directory, this happens because Path::getParent returns null if Path doesn?t have a parent. to prevent this, I added Path::toAbsolutePath call. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8158185 > webrev: http://cr.openjdk.java.net/~iignatyev/8158185/webrev.00/ > > Thanks, > ? Igor From coleen.phillimore at oracle.com Tue May 31 20:19:15 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Tue, 31 May 2016 16:19:15 -0400 Subject: RFR: 8157490: null stream->source() no longer causes error with -Xlog:class+load In-Reply-To: <574DCC6D.1080208@oracle.com> References: <57473B6F.2010806@oracle.com> <57474AB1.6030407@oracle.com> <574DCC6D.1080208@oracle.com> Message-ID: <473fbc4d-e188-08df-a81a-ee1af657d492@oracle.com> This looks good. Coleen On 5/31/16 1:39 PM, Max Ockner wrote: > I like this suggestion and I have updated my fix with it. > webrev: http://cr.openjdk.java.net/~mockner/8157490.02/ > Thanks, > Max > > On 5/26/2016 3:12 PM, Lois Foltan wrote: >> >> On 5/26/2016 2:07 PM, Max Ockner wrote: >>> Hello, >>> >>> Please review this very small fix for class+load logging with modules. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8157490 >>> Webrev: http://cr.openjdk.java.net/~mockner/8157490/ >>> >>> Summary: The JCK test >>> vm/jni/DefineClass/dfcl001/dfcl00101m1/dfcl00101m1 hit a SIGSEGV in >>> the logging section at the end of >>> ClassFileParser::fill_instance_klass(). With the addition of >>> modules, this logging section now uses >>> >>> strlen(stream->source()) >>> >>> to compute some of the module related parameters that it needs. This >>> SIGSEGV originated from the above line being executed with a null >>> stream source. >> >> Hi Max, >> >> I think you change is correct, but I would like to suggest changing >> the code even further. Currently the code between line #5352-5360 >> does a complicated check to see if the module's name is part of the >> java runtime image file and only sets the local variable >> "module_name" if it is. So, only module names that are defined >> within the java runtime image file are printed out in the logging. We >> should print out all modules' names, not just the ones in the jimage >> file. So please try removing lines #5352-5360 and set the local >> variable to: >> >> const char* module_name = (module_entry->name() == NULL) ? >> UNNAMED_MODULE : module_entry->name()->as_C_string(); >> >> The local variable "module_entry" is already checked at line #5310 to >> make sure it is set to a non-NULL value. >> >> Thanks, >> Lois >> >>> >>> Tested with vm/jni/DefineClass/dfcl001/dfcl00101m1/dfcl00101m1 >>> >>> Thanks, >>> Max >> > From lois.foltan at oracle.com Tue May 31 20:34:53 2016 From: lois.foltan at oracle.com (Lois Foltan) Date: Tue, 31 May 2016 16:34:53 -0400 Subject: RFR: 8157490: null stream->source() no longer causes error with -Xlog:class+load In-Reply-To: <574DCC6D.1080208@oracle.com> References: <57473B6F.2010806@oracle.com> <57474AB1.6030407@oracle.com> <574DCC6D.1080208@oracle.com> Message-ID: <574DF56D.8050503@oracle.com> Thanks Max for implementing the suggestion. Looks good. Lois On 5/31/2016 1:39 PM, Max Ockner wrote: > I like this suggestion and I have updated my fix with it. > webrev: http://cr.openjdk.java.net/~mockner/8157490.02/ > Thanks, > Max > > On 5/26/2016 3:12 PM, Lois Foltan wrote: >> >> On 5/26/2016 2:07 PM, Max Ockner wrote: >>> Hello, >>> >>> Please review this very small fix for class+load logging with modules. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8157490 >>> Webrev: http://cr.openjdk.java.net/~mockner/8157490/ >>> >>> Summary: The JCK test >>> vm/jni/DefineClass/dfcl001/dfcl00101m1/dfcl00101m1 hit a SIGSEGV in >>> the logging section at the end of >>> ClassFileParser::fill_instance_klass(). With the addition of >>> modules, this logging section now uses >>> >>> strlen(stream->source()) >>> >>> to compute some of the module related parameters that it needs. This >>> SIGSEGV originated from the above line being executed with a null >>> stream source. >> >> Hi Max, >> >> I think you change is correct, but I would like to suggest changing >> the code even further. Currently the code between line #5352-5360 >> does a complicated check to see if the module's name is part of the >> java runtime image file and only sets the local variable >> "module_name" if it is. So, only module names that are defined >> within the java runtime image file are printed out in the logging. We >> should print out all modules' names, not just the ones in the jimage >> file. So please try removing lines #5352-5360 and set the local >> variable to: >> >> const char* module_name = (module_entry->name() == NULL) ? >> UNNAMED_MODULE : module_entry->name()->as_C_string(); >> >> The local variable "module_entry" is already checked at line #5310 to >> make sure it is set to a non-NULL value. >> >> Thanks, >> Lois >> >>> >>> Tested with vm/jni/DefineClass/dfcl001/dfcl00101m1/dfcl00101m1 >>> >>> Thanks, >>> Max >> >