From vladimir.kozlov at oracle.com Wed Aug 1 04:27:26 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 31 Jul 2018 21:27:26 -0700 Subject: RFR: 8208582: Introduce native oop barriers in C1 for OopHandle In-Reply-To: References: <1533049674.local-48cfadc1-4a64-v1.3.0-fd741eb7@getmailspring.com> Message-ID: Seems fine. Thanks, Vladimir On 7/31/18 8:44 AM, Erik Osterlund wrote: > +hotspot-dev by popular demand > >> On 31 Jul 2018, at 17:35, Erik ?sterlund wrote: >> >> Hi, >> >> There is currently no way of doing IN_NATIVE accesses in C1 using its access API. These are required to properly access OopHandle, used to access the Java class mirrors (because they will now start requiring load barriers). In order to support concurrent class unloading in ZGC, this support must be added. >> >> This webrev adds C1 support for this: >> http://cr.openjdk.java.net/~eosterlund/8208582/webrev.00/ >> Bug URL: >> https://bugs.openjdk.java.net/browse/JDK-8208582 >> >> Thanks, >> /Erik From igor.ignatyev at oracle.com Wed Aug 1 05:53:44 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 31 Jul 2018 22:53:44 -0700 Subject: RFR(S) : [TESTBUG] A number of native hotspot unit tests fail when executed in stand-alone mode Message-ID: <121409FE-A50F-4C73-8857-7386F0B00FEE@oracle.com> http://cr.openjdk.java.net/~iignatyev//8174691/webrev.00/index.html > 21 lines changed: 4 ins; 0 del; 17 mod; Hi all, could you please review this small fix for native unit tests? these tests require JVM to be initialized, so they should be declared as TEST_VM and not as TEST. webrev: http://cr.openjdk.java.net/~iignatyev//8174691/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8174691 Thanks, -- Igor From thomas.schatzl at oracle.com Wed Aug 1 08:23:40 2018 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 01 Aug 2018 10:23:40 +0200 Subject: RFR(S) : [TESTBUG] A number of native hotspot unit tests fail when executed in stand-alone mode In-Reply-To: <121409FE-A50F-4C73-8857-7386F0B00FEE@oracle.com> References: <121409FE-A50F-4C73-8857-7386F0B00FEE@oracle.com> Message-ID: Hi, On Tue, 2018-07-31 at 22:53 -0700, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8174691/webrev.00/index.html > > 21 lines changed: 4 ins; 0 del; 17 mod; > > Hi all, > > could you please review this small fix for native unit tests? these > tests require JVM to be initialized, so they should be declared as > TEST_VM and not as TEST. > > webrev: http://cr.openjdk.java.net/~iignatyev//8174691/webrev.00/inde > x.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8174691 > > Thanks, > -- Igor looks good. Thomas From erik.osterlund at oracle.com Wed Aug 1 11:17:30 2018 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Wed, 1 Aug 2018 13:17:30 +0200 Subject: RFR: 8208601: Introduce native oop barriers in C2 for OopHandle Message-ID: <5B6196CA.7080201@oracle.com> Hi, There is currently no way of doing IN_NATIVE accesses in C2 using its access API. These are required to properly access OopHandle, used to access the Java class mirrors (because they will now start requiring load barriers). In order to support (concurrent) class unloading in ZGC, this support must be added. In this patch, I add an access_load API for loading IN_NATIVE oops, and use it to load class mirrors (which is logically an OopHandle::resolve, which happened to have been an indirect load before as nobody had load barriers on it). In the various code recognizing the shape of a mirror load to optimize the code, I have added a check if a node is a GC barrier and to then step over it in order to match the mirror load. In order to recognize and step over the load barriers in ZGC properly, I added support for recognizing the barrier shapes not just before macro expansion (LoadBarrierNode), but also after macro expansion (as required by the matching code), which involves checking for phi nodes with with LoadBarrierSlowRegNode phi->in(1), and then stepping over to phi->in(2), as well as recognizing projections to such shapes. LoadBarrierSlowRegNode is used in all barrier expansions except for atomic xchg, but that is fine as we don't use that on class mirrors. I have checked that the shapes are recognized and that no regressions are introduced with these changes through a bunch of benchmarks in gc-test-suite. Webrev: http://cr.openjdk.java.net/~eosterlund/8208601/webrev.00/ Bug URL: https://bugs.openjdk.java.net/browse/JDK-8208601 Thanks, /Erik Open Tracking From coleen.phillimore at oracle.com Wed Aug 1 11:21:31 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 1 Aug 2018 07:21:31 -0400 Subject: RFR: 8208582: Introduce native oop barriers in C1 for OopHandle In-Reply-To: References: <1533049674.local-48cfadc1-4a64-v1.3.0-fd741eb7@getmailspring.com> Message-ID: <47ba3722-1cee-5c0e-891b-4f98b0dc17aa@oracle.com> Erik, pattern matching with the macroAssembler the C1 code looks good. http://cr.openjdk.java.net/~eosterlund/8208582/webrev.00/src/hotspot/share/c1/c1_LIRGenerator.cpp.udiff.html Did you pass BasicType to access_load rather than hard-code T_OBJECT to support shenandoah? (same question for the MacroAssembler version). Is this access ever a raw access? Thanks, Coleen On 7/31/18 11:44 AM, Erik Osterlund wrote: > +hotspot-dev by popular demand > >> On 31 Jul 2018, at 17:35, Erik ?sterlund wrote: >> >> Hi, >> >> There is currently no way of doing IN_NATIVE accesses in C1 using its access API. These are required to properly access OopHandle, used to access the Java class mirrors (because they will now start requiring load barriers). In order to support concurrent class unloading in ZGC, this support must be added. >> >> This webrev adds C1 support for this: >> http://cr.openjdk.java.net/~eosterlund/8208582/webrev.00/ >> Bug URL: >> https://bugs.openjdk.java.net/browse/JDK-8208582 >> >> Thanks, >> /Erik From erik.osterlund at oracle.com Wed Aug 1 13:37:23 2018 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Wed, 1 Aug 2018 15:37:23 +0200 Subject: RFR: 8208582: Introduce native oop barriers in C1 for OopHandle In-Reply-To: <47ba3722-1cee-5c0e-891b-4f98b0dc17aa@oracle.com> References: <1533049674.local-48cfadc1-4a64-v1.3.0-fd741eb7@getmailspring.com> <47ba3722-1cee-5c0e-891b-4f98b0dc17aa@oracle.com> Message-ID: <5B61B792.4080707@oracle.com> Hi Coleen, Thank you for the review. On 2018-08-01 13:21, coleen.phillimore at oracle.com wrote: > > Erik, pattern matching with the macroAssembler the C1 code looks good. > > http://cr.openjdk.java.net/~eosterlund/8208582/webrev.00/src/hotspot/share/c1/c1_LIRGenerator.cpp.udiff.html > > > Did you pass BasicType to access_load rather than hard-code T_OBJECT > to support shenandoah? (same question for the MacroAssembler version). No I did it for consistency with the other access_load_at API. Shenandoah will not need special support for off-heap primitives; only on-heap primitives. > Is this access ever a raw access? Not at the moment, but who knows what the future might hold. I support it for consistency to reduce surprises for future users of the API, as it is trivial enough to do so. Thanks, /Erik > Thanks, > Coleen > > On 7/31/18 11:44 AM, Erik Osterlund wrote: >> +hotspot-dev by popular demand >> >>> On 31 Jul 2018, at 17:35, Erik ?sterlund >>> wrote: >>> >>> Hi, >>> >>> There is currently no way of doing IN_NATIVE accesses in C1 using >>> its access API. These are required to properly access OopHandle, >>> used to access the Java class mirrors (because they will now start >>> requiring load barriers). In order to support concurrent class >>> unloading in ZGC, this support must be added. >>> >>> This webrev adds C1 support for this: >>> http://cr.openjdk.java.net/~eosterlund/8208582/webrev.00/ >>> Bug URL: >>> https://bugs.openjdk.java.net/browse/JDK-8208582 >>> >>> Thanks, >>> /Erik > From daniel.daugherty at oracle.com Wed Aug 1 13:55:31 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 1 Aug 2018 09:55:31 -0400 Subject: RFR 8199868: Support JNI critical functions in object pinning API In-Reply-To: <7d17b6f0-4bc9-111b-ede8-d16f5ac240d3@oracle.com> References: <931060af-b44d-f348-92ba-e98d623d4c84@redhat.com> <19c791e7-1bf8-69ef-7090-b7da800f2021@redhat.com> <16c60f53-d835-29f1-981f-4f70537ceb62@oracle.com> <43e5c158-1c5c-892b-9bb4-775bd29ad96d@redhat.com> <0e08dabe-44e5-099f-f1c3-f16f41784fca@redhat.com> <4766c62d-962b-4748-a910-fd848da3d89a@redhat.com> <1ec11e08-f17c-7ad9-3c23-3b02055fc579@redhat.com> <3c5fd1f4-c55c-43e0-8b79-11ebd75ad762@oracle.com> <7d17b6f0-4bc9-111b-ede8-d16f5ac240d3@oracle.com> Message-ID: <7dafc26c-591d-28ea-3dbc-d81dc415acb1@oracle.com> On 7/31/18 5:10 PM, Daniel D. Daugherty wrote: > On 7/31/18 4:56 PM, Zhengyu Gu wrote: >> On 07/31/2018 04:54 PM, Daniel D. Daugherty wrote: >>> On 7/31/18 4:50 PM, Zhengyu Gu wrote: >>>> Hi Dan, >>>> >>>> On 07/31/2018 03:12 PM, Daniel D. Daugherty wrote: >>>>> This fix has broken the JDK12 CI tier1 builds: >>>>> >>>>> JDK-8208605 Fix for 8199868 breaks tier1 build >>>>> https://bugs.openjdk.java.net/browse/JDK-8208605 >>>>> >>>>> Zhengyu, let me know how quickly you can have this fixed or >>>>> if you prefer I back out the fix. I'm guessing this was not >>>>> tested using jdk-submit... >>>> >>>> I did run through submit repo. >>> >>> Then the submit repo must not be doing Solaris SPARC builds... >>> Or something else... I dunno... > > Apparently the jdk-submit repo does not do Solaris SPARC builds. > I do not know why not, but I'll rattle some cages on this end. > > I apologize for assuming that you did not use that jdk-submit repo. Just to close the loop on this adventure... Solaris SPARC is included in the jdk-submit machine matrix. I was told it wasn't, but Christian chased down Zhengyu's jdk-submit job and it did pass Solaris SPARC builds and tests... The reason that it passed is the new test wasn't in the source bundle: $ ls open/test/hotspot/jtreg/gc/epsilon/ TestAlwaysPretouch.java??? ??? TestLogTrace.java TestByteArrays.java??? ??? TestManyThreads.java TestDieDefault.java??? ??? TestMemoryMXBeans.java TestDieWithHeapDump.java??? TestMemoryPools.java TestDieWithOnError.java??? ??? TestObjects.java TestElasticTLAB.java??? ??? TestPrintHeapSteps.java TestElasticTLABDecay.java??? TestRefArrays.java TestEpsilonEnabled.java??? ??? TestUpdateCountersSteps.java So these three files are not there: + test/hotspot/jtreg/gc/epsilon/CriticalNativeArgs.java + test/hotspot/jtreg/gc/epsilon/CriticalNativeStress.java + test/hotspot/jtreg/gc/epsilon/libCriticalNative.c which is why the jdk-submit job passed, but the CI job for the actual push failed. It should all be fixed as of last night. I just wanted to close the loop on this mystery... Dan > > Dan > > >>> >>> I have a fix reviewed and I'm waiting for the mach5 tier1 >>> builds to finish... >> >> Thank you, Dan. >> >> -Zhengyu >> >>> >>> Dan >>> >>> >>> >>>> >>>> http://mail.openjdk.java.net/pipermail/jdk-submit-changes/2018-July/002535.html >>>> >>>> >>>> And results I got: >>>> >>>> Build Details: 2018-07-31-1535425.zgu.source >>>> 0 Failed Tests >>>> Mach5 Tasks Results Summary >>>> >>>> ??? PASSED: 75 >>>> ??? FAILED: 0 >>>> ??? KILLED: 0 >>>> ??? NA: 0 >>>> ??? UNABLE_TO_RUN: 0 >>>> ??? EXECUTED_WITH_FAILURE: 0 >>>> >>>> I will fix this right now. >>>> >>>> Thanks, >>>> >>>> -Zhengyu >>>> >>>> >>>> >>>>> >>>>> Dan >>>>> >>>>> >>>>> On 7/31/18 10:37 AM, Andrew Dinn wrote: >>>>>> Hi Zhengyu, >>>>>> >>>>>> On 31/07/18 14:25, Zhengyu Gu wrote: >>>>>>> I added comments as you suggested. >>>>>>> >>>>>>> Updated webrev: http://cr.openjdk.java.net/~zgu/8199868/webrev.04/ >>>>>> Ok, thanks. >>>>>> >>>>>> The above patch is reviewed modulo two misspellings of 'critical' as >>>>>> 'ciritical' in CriticalNativeStress.java. >>>>>> >>>>>> No need for another webrev. >>>>>> >>>>>> 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 rkennke at redhat.com Wed Aug 1 14:18:37 2018 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 1 Aug 2018 16:18:37 +0200 Subject: Ping: RFR: JDK-8205523: Explicit barriers for interpreter In-Reply-To: <5B59E222.1080208@oracle.com> References: <3aae894d-dae1-f4b3-7702-d99621382864@redhat.com> <75ea0ba0-6990-9e18-c724-355aad788cb6@redhat.com> <9904470c-4a10-48c3-2533-c5f8c3fe94e0@oracle.com> <0a85ec44-5487-c11f-1436-8912958dc9ad@redhat.com> <1e211420-7f77-f0d3-8e08-3b499ff66899@redhat.com> <38724390-8f6b-45ac-8654-e79082e820c6@redhat.com> <735140fb-83f5-ca1f-df3d-fc3af4bf31bc@redhat.com> <5B58800F.1050603@oracle.com> <5B59E222.1080208@oracle.com> Message-ID: <3d192cda-3115-abc1-c86c-94e88f2ac5a2@redhat.com> >> thanks for the review. I agree defaulting to READ|WRITE is even better. >> >> Updated webrevs (for other reviewers): >> Incremental: >> http://cr.openjdk.java.net/~rkennke/JDK-8205523/webrev.02.diff/ >> Full: >> http://cr.openjdk.java.net/~rkennke/JDK-8205523/webrev.02/ >> >> Would you agree that we could/should make this consistent across >> runtime/interpreter/c1/c2 ? It certainly would make me happier in >> runtime land, and seems required in compiler land. > > Yes, agreed. I only introduced decorators for this in compilers because > they were not needed in the interpreter and runtime. But now they are > needed there too, having different decorators for the same thing will > only be confusing. I will file followup RFEs for those. Can I consider the change reviewed by you? Also, I need one more reviewer. Any takers, please? Thanks! Roman > > Thanks, > /Erik > >> Andrew: are you ok with this final patch? >> >> Roman >> >>> I gotta say I like this a lot better. With the safe defaults for the >>> non-expert, yet allowing you guys to be more precise where you know it >>> is okay, I am okay with this. >>> Just a small thing though: >>> >>> 6290 void MacroAssembler::resolve(DecoratorSet decorators, Register >>> obj) { >>> 6291?? // Use stronger ACCESS_WRITE by default. >>> 6292?? if ((decorators & ACCESS_READ) == 0) { >>> 6293???? decorators |= ACCESS_WRITE; >>> 6294?? } >>> 6295?? BarrierSetAssembler* bs = >>> BarrierSet::barrier_set()->barrier_set_assembler(); >>> 6296?? return bs->resolve(this, decorators, obj); >>> 6297 } >>> >>> Just in terms of semantics, I think you should really change these >>> defaults to: >>> >>> 6292?? if ((decorators & (ACCESS_READ | ACCESS_WRITE)) == 0) { >>> 6293???? decorators |= ACCESS_READ | ACCESS_WRITE; >>> 6294?? } >>> >>> In other words, the default resolve unless specified is for ACCESS_READ >>> | ACCESS_WRITE - you may read or write primitives on the resolved oop. I >>> don't think it is necesarily intuitive that being allowed to write >>> implicitly means that you are allowed to read too; that is just an >>> implementation detail of relocating on writes as Shenandoah does things. >>> So if you just change that, you have looks good from me. And I don't >>> need another webrev for that. >>> >>> Thanks, >>> /Erik >>> >>> On 2018-07-02 13:56, Roman Kennke wrote: >>>>>> I am a fan of profile guided optimization. I would definitely not >>>>>> mind >>>>>> introducing these concepts in the compilers where they are with no >>>>>> doubt >>>>>> necessary (and we also have the right tools for dealing with this >>>>>> better). In fact, they already have read/write decorators that >>>>>> could be >>>>>> used for resolve barriers in our compilers, and can use algorithms to >>>>>> safely elide barriers where provably correct, so it makes perfect >>>>>> sense >>>>>> for me to use such concepts there. >>>>>> I'm just not sure that the interpreter needs to be polluted with this >>>>>> conceptual overhead, unless there is at least one benchmark that can >>>>>> show that we are solving an actual problem with this. Remember, >>>>>> premature optimizations are the root of all evil. >>>>> but efficient systems are made from thousands of tiny optimizations, >>>>> each >>>>> one too small to be measured above the noise on its own. >>>>> >>>> After some offline discussion with Erik, I want to propose a solution >>>> that 1. keeps the API simple to use, even if not sure if it's a >>>> read- or >>>> write-access (defaulting to stronger write, 2. remains flexible enough >>>> to optimize for read-only acces. >>>> >>>> This changeset introduces an API BarrierSetAssembler::resolve() which >>>> takes the 'hint' about read- vs write-access via a Decorator >>>> ACCESS_READ >>>> and ACCESS_WRITE. The API frontend in MacroAssembler::resolve() sets >>>> ACCESS_WRITE if ACCESS_READ is not explicitely set. >>>> >>>> Incremental webrev: >>>> http://cr.openjdk.java.net/~rkennke/JDK-8205523/webrev.01.diff/ >>>> Full webrev: >>>> http://cr.openjdk.java.net/~rkennke/JDK-8205523/webrev.01/ >>>> >>>> If this proposal gets accepted, I'd take this further (in separate >>>> RFEs): >>>> 1. make C1 use ACCESS_READ and ACCESS_WRITE instead of C1_READ_ACCESS >>>> and C1_WRITE_ACCESS. Those uses are currently no good anyway (as they >>>> are currently passed into Access API that 'knows' what it is, e.g. >>>> store_at/load_at, etc). >>>> 2. introduce same pattern for resolve() in runtime (and later, c1 and >>>> c2). >>>> >>>> What do you think? >>>> >>>> Roman >>>> >> > From vladimir.kozlov at oracle.com Wed Aug 1 14:23:57 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 1 Aug 2018 07:23:57 -0700 Subject: RFR(S) : [TESTBUG] A number of native hotspot unit tests fail when executed in stand-alone mode In-Reply-To: <121409FE-A50F-4C73-8857-7386F0B00FEE@oracle.com> References: <121409FE-A50F-4C73-8857-7386F0B00FEE@oracle.com> Message-ID: <355ed0f6-79f3-8aec-382a-433b7d8ff355@oracle.com> Good. Thanks, Vladimir On 7/31/18 10:53 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8174691/webrev.00/index.html >> 21 lines changed: 4 ins; 0 del; 17 mod; > > Hi all, > > could you please review this small fix for native unit tests? these tests require JVM to be initialized, so they should be declared as TEST_VM and not as TEST. > > webrev: http://cr.openjdk.java.net/~iignatyev//8174691/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8174691 > > Thanks, > -- Igor > From zgu at redhat.com Wed Aug 1 14:27:47 2018 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 1 Aug 2018 10:27:47 -0400 Subject: RFR 8199868: Support JNI critical functions in object pinning API In-Reply-To: <7dafc26c-591d-28ea-3dbc-d81dc415acb1@oracle.com> References: <931060af-b44d-f348-92ba-e98d623d4c84@redhat.com> <19c791e7-1bf8-69ef-7090-b7da800f2021@redhat.com> <16c60f53-d835-29f1-981f-4f70537ceb62@oracle.com> <43e5c158-1c5c-892b-9bb4-775bd29ad96d@redhat.com> <0e08dabe-44e5-099f-f1c3-f16f41784fca@redhat.com> <4766c62d-962b-4748-a910-fd848da3d89a@redhat.com> <1ec11e08-f17c-7ad9-3c23-3b02055fc579@redhat.com> <3c5fd1f4-c55c-43e0-8b79-11ebd75ad762@oracle.com> <7d17b6f0-4bc9-111b-ede8-d16f5ac240d3@oracle.com> <7dafc26c-591d-28ea-3dbc-d81dc415acb1@oracle.com> Message-ID: > > Just to close the loop on this adventure... Solaris SPARC is > included in the jdk-submit machine matrix. I was told it wasn't, > but Christian chased down Zhengyu's jdk-submit job and it did > pass Solaris SPARC builds and tests... > > The reason that it passed is the new test wasn't in the source > bundle: > > $ ls open/test/hotspot/jtreg/gc/epsilon/ > TestAlwaysPretouch.java??? ??? TestLogTrace.java > TestByteArrays.java??? ??? TestManyThreads.java > TestDieDefault.java??? ??? TestMemoryMXBeans.java > TestDieWithHeapDump.java??? TestMemoryPools.java > TestDieWithOnError.java??? ??? TestObjects.java > TestElasticTLAB.java??? ??? TestPrintHeapSteps.java > TestElasticTLABDecay.java??? TestRefArrays.java > TestEpsilonEnabled.java??? ??? TestUpdateCountersSteps.java > > So these three files are not there: > > + test/hotspot/jtreg/gc/epsilon/CriticalNativeArgs.java > + test/hotspot/jtreg/gc/epsilon/CriticalNativeStress.java > + test/hotspot/jtreg/gc/epsilon/libCriticalNative.c > > which is why the jdk-submit job passed, but the CI job for > the actual push failed. > > It should all be fixed as of last night. I just wanted to > close the loop on this mystery... Hummm .. I am really confused here. I did submit twice. The first submit did miss tests: http://mail.openjdk.java.net/pipermail/jdk-submit-changes/2018-July/002532.html but, it came back as unstable. Then I did the second submit, which included tests: http://mail.openjdk.java.net/pipermail/jdk-submit-changes/2018-July/002535.html and got all clear results. so, you mean that the all clear results were from the first submit? did it get reran? but I did not receive any new results after that ... Is it possible to generate link in test results, that points to the submit job? -Zhengyu > > Dan > > > >> >> Dan >> >> >>>> >>>> I have a fix reviewed and I'm waiting for the mach5 tier1 >>>> builds to finish... >>> >>> Thank you, Dan. >>> >>> -Zhengyu >>> >>>> >>>> Dan >>>> >>>> >>>> >>>>> >>>>> http://mail.openjdk.java.net/pipermail/jdk-submit-changes/2018-July/002535.html >>>>> >>>>> >>>>> And results I got: >>>>> >>>>> Build Details: 2018-07-31-1535425.zgu.source >>>>> 0 Failed Tests >>>>> Mach5 Tasks Results Summary >>>>> >>>>> ??? PASSED: 75 >>>>> ??? FAILED: 0 >>>>> ??? KILLED: 0 >>>>> ??? NA: 0 >>>>> ??? UNABLE_TO_RUN: 0 >>>>> ??? EXECUTED_WITH_FAILURE: 0 >>>>> >>>>> I will fix this right now. >>>>> >>>>> Thanks, >>>>> >>>>> -Zhengyu >>>>> >>>>> >>>>> >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>> On 7/31/18 10:37 AM, Andrew Dinn wrote: >>>>>>> Hi Zhengyu, >>>>>>> >>>>>>> On 31/07/18 14:25, Zhengyu Gu wrote: >>>>>>>> I added comments as you suggested. >>>>>>>> >>>>>>>> Updated webrev: http://cr.openjdk.java.net/~zgu/8199868/webrev.04/ >>>>>>> Ok, thanks. >>>>>>> >>>>>>> The above patch is reviewed modulo two misspellings of 'critical' as >>>>>>> 'ciritical' in CriticalNativeStress.java. >>>>>>> >>>>>>> No need for another webrev. >>>>>>> >>>>>>> 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 kevin.walls at oracle.com Wed Aug 1 14:47:25 2018 From: kevin.walls at oracle.com (Kevin Walls) Date: Wed, 1 Aug 2018 15:47:25 +0100 Subject: [8u] RFR: 8196882: VS2017 Hotspot Defined vsnprintf Function Causes C2084 Already Defined Compilation Error In-Reply-To: <04810989-7A14-4F19-A6DE-AAEA96847278@oracle.com> References: <0886e5e6-ab76-1b98-4047-ea86d860116b@oracle.com> <1775028E-BA4E-475C-BB6E-ED19CBF93ED1@oracle.com> <447ac3cc-68da-d1a5-b58e-35445c642728@oracle.com> <04810989-7A14-4F19-A6DE-AAEA96847278@oracle.com> Message-ID: <03da2c36-7650-9fde-79b2-ac1de2fd7f79@oracle.com> Hi Kim, Yes we can try that way.? I can reword the intention to be less particular about keeping old windows behaviour. A new change is that in 8u I found g1GCPhaseTimes.cpp has a vsnprintf which was checking for -1 to mean buffer too small. http://cr.openjdk.java.net/~kevinw/8196882/webrev.02/ Thanks! Kevin On 31/07/2018 23:15, Kim Barrett wrote: >> On Jul 31, 2018, at 5:14 PM, Kevin Walls wrote: >> >> Great, thanks Kim, >> Not being an 8 Reviewer is fine, I'm very happy to get your comments here, and when we're happy with it I do a specific 8u approval email. >> >> src/os/windows/vm/os_windows.cpp / os::vsnprintf() oops yes, should not check the result and call _vscprintf(). >> src/share/vm/prims/jvm.cpp / jio_vsnprintf() should not force the null-terminator in the result. >> >> Making Windows retain its different behaviour also means the tests need to be different for Windows, so in ostream.cpp in test_snprintf() I change the boolean passed to the test depending on the platform. On Windows, expect_count is false. >> >> Updated webrev: >> http://cr.openjdk.java.net/~kevinw/8196882/webrev.01/ >> Thanks >> Kevin > I think that trying this hard to retain the different Windows behavior is a mistake. > > There aren?t that many callers of vsnprint / os::vsnprintf, and most of them don?t care > (don?t examine the return value). We can see all of them, since this is a function inside > of hotspot, and not something exposed (unlike jio_vsnprintf and friends, which are in > a ?public? header). > > We *are* retaining the old behavior for jio_vsnprintf. > > One of the few (the only?) other callers that cares is the one in ostream.cpp, and it is > at least arguable that it has always been somewhat wrong, and was fixed by the > jdk11 change. > From daniel.daugherty at oracle.com Wed Aug 1 15:01:56 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 1 Aug 2018 11:01:56 -0400 Subject: RFR 8199868: Support JNI critical functions in object pinning API In-Reply-To: References: <931060af-b44d-f348-92ba-e98d623d4c84@redhat.com> <19c791e7-1bf8-69ef-7090-b7da800f2021@redhat.com> <16c60f53-d835-29f1-981f-4f70537ceb62@oracle.com> <43e5c158-1c5c-892b-9bb4-775bd29ad96d@redhat.com> <0e08dabe-44e5-099f-f1c3-f16f41784fca@redhat.com> <4766c62d-962b-4748-a910-fd848da3d89a@redhat.com> <1ec11e08-f17c-7ad9-3c23-3b02055fc579@redhat.com> <3c5fd1f4-c55c-43e0-8b79-11ebd75ad762@oracle.com> <7d17b6f0-4bc9-111b-ede8-d16f5ac240d3@oracle.com> <7dafc26c-591d-28ea-3dbc-d81dc415acb1@oracle.com> Message-ID: <20521b46-654e-9702-804b-3d0458b64800@oracle.com> On 8/1/18 10:27 AM, Zhengyu Gu wrote: > >> >> Just to close the loop on this adventure... Solaris SPARC is >> included in the jdk-submit machine matrix. I was told it wasn't, >> but Christian chased down Zhengyu's jdk-submit job and it did >> pass Solaris SPARC builds and tests... >> >> The reason that it passed is the new test wasn't in the source >> bundle: >> >> $ ls open/test/hotspot/jtreg/gc/epsilon/ >> TestAlwaysPretouch.java??? ??? TestLogTrace.java >> TestByteArrays.java??? ??? TestManyThreads.java >> TestDieDefault.java??? ??? TestMemoryMXBeans.java >> TestDieWithHeapDump.java??? TestMemoryPools.java >> TestDieWithOnError.java??? ??? TestObjects.java >> TestElasticTLAB.java??? ??? TestPrintHeapSteps.java >> TestElasticTLABDecay.java??? TestRefArrays.java >> TestEpsilonEnabled.java??? ??? TestUpdateCountersSteps.java >> >> So these three files are not there: >> >> + test/hotspot/jtreg/gc/epsilon/CriticalNativeArgs.java >> + test/hotspot/jtreg/gc/epsilon/CriticalNativeStress.java >> + test/hotspot/jtreg/gc/epsilon/libCriticalNative.c >> >> which is why the jdk-submit job passed, but the CI job for >> the actual push failed. >> >> It should all be fixed as of last night. I just wanted to >> close the loop on this mystery... > > Hummm .. I am really confused here. > > I did submit twice. Hmmm... When I search Mach5 with 'id:*JDK-8199868*', I see only one recent Mach5 job: mach5-one-zgu-JDK-8199868-20180731-1538-33107 The others are back in May and April... > The first submit did miss tests: > > http://mail.openjdk.java.net/pipermail/jdk-submit-changes/2018-July/002532.html > > > but, it came back as unstable. This email lists the changeset ID as: 630c90079d38 And Mach5 shows the verbose changeset id for mach5-one-zgu-JDK-8199868-20180731-1538-33107 as: hg -R open update -c -r 630c90079d38795aa44a506320df1b950392d26c so we have a match. So the Mach5 job that Christian found (and that I found just now) matches the one without the test. > Then I did the second submit, which included tests: > > http://mail.openjdk.java.net/pipermail/jdk-submit-changes/2018-July/002535.html > > > and got all clear results. This email lists the changeset ID as: 2cd8bbccbd2d I did another Mach5 search using 'userEmail:zgu at redhat.com*' and it shows only one job for you on 07.31: mach5-one-zgu-JDK-8199868-20180731-1538-33107 and one job for you running right now (for 8208635). In other words, I can't find any trace that your second jdk-submit job for 8199868 actually ran in Mach5. > so, you mean that the all clear results were from the first submit? That's what it looks like to me. > did it get reran? I don't know. Looking at your first job for 8199868 in Mach5, I don't see any failures. All 75 tasks passed and no test failures are reported. I think it's possible that the "unstable" indicator you got was from your second job? I really don't know for sure... > but I did not receive any new results after that ... > > Is it possible to generate link in test results, that points to the > submit job? I don't think so because that would be an Oracle internal link. However, I'm not all that familiar with the jdk-submit system. In fact this is my first time poking around it... Dan > > -Zhengyu > >> >> Dan >> >> >> >>> >>> Dan >>> >>> >>>>> >>>>> I have a fix reviewed and I'm waiting for the mach5 tier1 >>>>> builds to finish... >>>> >>>> Thank you, Dan. >>>> >>>> -Zhengyu >>>> >>>>> >>>>> Dan >>>>> >>>>> >>>>> >>>>>> >>>>>> http://mail.openjdk.java.net/pipermail/jdk-submit-changes/2018-July/002535.html >>>>>> >>>>>> >>>>>> And results I got: >>>>>> >>>>>> Build Details: 2018-07-31-1535425.zgu.source >>>>>> 0 Failed Tests >>>>>> Mach5 Tasks Results Summary >>>>>> >>>>>> ??? PASSED: 75 >>>>>> ??? FAILED: 0 >>>>>> ??? KILLED: 0 >>>>>> ??? NA: 0 >>>>>> ??? UNABLE_TO_RUN: 0 >>>>>> ??? EXECUTED_WITH_FAILURE: 0 >>>>>> >>>>>> I will fix this right now. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> -Zhengyu >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Dan >>>>>>> >>>>>>> >>>>>>> On 7/31/18 10:37 AM, Andrew Dinn wrote: >>>>>>>> Hi Zhengyu, >>>>>>>> >>>>>>>> On 31/07/18 14:25, Zhengyu Gu wrote: >>>>>>>>> I added comments as you suggested. >>>>>>>>> >>>>>>>>> Updated webrev: >>>>>>>>> http://cr.openjdk.java.net/~zgu/8199868/webrev.04/ >>>>>>>> Ok, thanks. >>>>>>>> >>>>>>>> The above patch is reviewed modulo two misspellings of >>>>>>>> 'critical' as >>>>>>>> 'ciritical' in CriticalNativeStress.java. >>>>>>>> >>>>>>>> No need for another webrev. >>>>>>>> >>>>>>>> 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 erik.osterlund at oracle.com Wed Aug 1 16:33:28 2018 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Wed, 1 Aug 2018 18:33:28 +0200 Subject: Ping: RFR: JDK-8205523: Explicit barriers for interpreter In-Reply-To: <3d192cda-3115-abc1-c86c-94e88f2ac5a2@redhat.com> References: <3aae894d-dae1-f4b3-7702-d99621382864@redhat.com> <75ea0ba0-6990-9e18-c724-355aad788cb6@redhat.com> <9904470c-4a10-48c3-2533-c5f8c3fe94e0@oracle.com> <0a85ec44-5487-c11f-1436-8912958dc9ad@redhat.com> <1e211420-7f77-f0d3-8e08-3b499ff66899@redhat.com> <38724390-8f6b-45ac-8654-e79082e820c6@redhat.com> <735140fb-83f5-ca1f-df3d-fc3af4bf31bc@redhat.com> <5B58800F.1050603@oracle.com> <5B59E222.1080208@oracle.com> <3d192cda-3115-abc1-c86c-94e88f2ac5a2@redhat.com> Message-ID: Hi Roman, Yes. Reviewed. Thanks, /Erik On 1 Aug 2018, at 16:18, Roman Kennke wrote: >>> thanks for the review. I agree defaulting to READ|WRITE is even better. >>> >>> Updated webrevs (for other reviewers): >>> Incremental: >>> http://cr.openjdk.java.net/~rkennke/JDK-8205523/webrev.02.diff/ >>> Full: >>> http://cr.openjdk.java.net/~rkennke/JDK-8205523/webrev.02/ >>> >>> Would you agree that we could/should make this consistent across >>> runtime/interpreter/c1/c2 ? It certainly would make me happier in >>> runtime land, and seems required in compiler land. >> >> Yes, agreed. I only introduced decorators for this in compilers because >> they were not needed in the interpreter and runtime. But now they are >> needed there too, having different decorators for the same thing will >> only be confusing. > > I will file followup RFEs for those. > > Can I consider the change reviewed by you? > > Also, I need one more reviewer. Any takers, please? > > Thanks! > Roman > >> >> Thanks, >> /Erik >> >>> Andrew: are you ok with this final patch? >>> >>> Roman >>> >>>> I gotta say I like this a lot better. With the safe defaults for the >>>> non-expert, yet allowing you guys to be more precise where you know it >>>> is okay, I am okay with this. >>>> Just a small thing though: >>>> >>>> 6290 void MacroAssembler::resolve(DecoratorSet decorators, Register >>>> obj) { >>>> 6291 // Use stronger ACCESS_WRITE by default. >>>> 6292 if ((decorators & ACCESS_READ) == 0) { >>>> 6293 decorators |= ACCESS_WRITE; >>>> 6294 } >>>> 6295 BarrierSetAssembler* bs = >>>> BarrierSet::barrier_set()->barrier_set_assembler(); >>>> 6296 return bs->resolve(this, decorators, obj); >>>> 6297 } >>>> >>>> Just in terms of semantics, I think you should really change these >>>> defaults to: >>>> >>>> 6292 if ((decorators & (ACCESS_READ | ACCESS_WRITE)) == 0) { >>>> 6293 decorators |= ACCESS_READ | ACCESS_WRITE; >>>> 6294 } >>>> >>>> In other words, the default resolve unless specified is for ACCESS_READ >>>> | ACCESS_WRITE - you may read or write primitives on the resolved oop. I >>>> don't think it is necesarily intuitive that being allowed to write >>>> implicitly means that you are allowed to read too; that is just an >>>> implementation detail of relocating on writes as Shenandoah does things. >>>> So if you just change that, you have looks good from me. And I don't >>>> need another webrev for that. >>>> >>>> Thanks, >>>> /Erik >>>> >>>> On 2018-07-02 13:56, Roman Kennke wrote: >>>>>>> I am a fan of profile guided optimization. I would definitely not >>>>>>> mind >>>>>>> introducing these concepts in the compilers where they are with no >>>>>>> doubt >>>>>>> necessary (and we also have the right tools for dealing with this >>>>>>> better). In fact, they already have read/write decorators that >>>>>>> could be >>>>>>> used for resolve barriers in our compilers, and can use algorithms to >>>>>>> safely elide barriers where provably correct, so it makes perfect >>>>>>> sense >>>>>>> for me to use such concepts there. >>>>>>> I'm just not sure that the interpreter needs to be polluted with this >>>>>>> conceptual overhead, unless there is at least one benchmark that can >>>>>>> show that we are solving an actual problem with this. Remember, >>>>>>> premature optimizations are the root of all evil. >>>>>> but efficient systems are made from thousands of tiny optimizations, >>>>>> each >>>>>> one too small to be measured above the noise on its own. >>>>>> >>>>> After some offline discussion with Erik, I want to propose a solution >>>>> that 1. keeps the API simple to use, even if not sure if it's a >>>>> read- or >>>>> write-access (defaulting to stronger write, 2. remains flexible enough >>>>> to optimize for read-only acces. >>>>> >>>>> This changeset introduces an API BarrierSetAssembler::resolve() which >>>>> takes the 'hint' about read- vs write-access via a Decorator >>>>> ACCESS_READ >>>>> and ACCESS_WRITE. The API frontend in MacroAssembler::resolve() sets >>>>> ACCESS_WRITE if ACCESS_READ is not explicitely set. >>>>> >>>>> Incremental webrev: >>>>> http://cr.openjdk.java.net/~rkennke/JDK-8205523/webrev.01.diff/ >>>>> Full webrev: >>>>> http://cr.openjdk.java.net/~rkennke/JDK-8205523/webrev.01/ >>>>> >>>>> If this proposal gets accepted, I'd take this further (in separate >>>>> RFEs): >>>>> 1. make C1 use ACCESS_READ and ACCESS_WRITE instead of C1_READ_ACCESS >>>>> and C1_WRITE_ACCESS. Those uses are currently no good anyway (as they >>>>> are currently passed into Access API that 'knows' what it is, e.g. >>>>> store_at/load_at, etc). >>>>> 2. introduce same pattern for resolve() in runtime (and later, c1 and >>>>> c2). >>>>> >>>>> What do you think? >>>>> >>>>> Roman >>>>> >>> >> > > From igor.ignatyev at oracle.com Wed Aug 1 17:06:01 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 1 Aug 2018 10:06:01 -0700 Subject: RFR(S) : [TESTBUG] A number of native hotspot unit tests fail when executed in stand-alone mode In-Reply-To: <355ed0f6-79f3-8aec-382a-433b7d8ff355@oracle.com> References: <121409FE-A50F-4C73-8857-7386F0B00FEE@oracle.com> <355ed0f6-79f3-8aec-382a-433b7d8ff355@oracle.com> Message-ID: <6A53E2E8-69DE-4F3A-9D47-907D03061490@oracle.com> Vladimir, Thomas, thank you both for review. -- Igor > On Aug 1, 2018, at 7:23 AM, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > On Aug 1, 2018, at 1:23 AM, Thomas Schatzl wrote: > Hi, > > looks good. > > Thomas > On 7/31/18 10:53 PM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8174691/webrev.00/index.html >>> 21 lines changed: 4 ins; 0 del; 17 mod; >> Hi all, >> could you please review this small fix for native unit tests? these tests require JVM to be initialized, so they should be declared as TEST_VM and not as TEST. >> webrev: http://cr.openjdk.java.net/~iignatyev//8174691/webrev.00/index.html >> JBS: https://bugs.openjdk.java.net/browse/JDK-8174691 >> Thanks, >> -- Igor From vladimir.kozlov at oracle.com Wed Aug 1 18:03:44 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 1 Aug 2018 11:03:44 -0700 Subject: RFR: 8208601: Introduce native oop barriers in C2 for OopHandle In-Reply-To: <5B6196CA.7080201@oracle.com> References: <5B6196CA.7080201@oracle.com> Message-ID: <51231d8e-e2ed-3d95-2cb2-c8cb61cbe512@oracle.com> Hi, Erik 1. is_gc_barrier_node(b) is virtual so even if it return 'false' I am not sure C++ will collapse new search loops in phaseX.cpp and checks in other cases. Can we use some static check to allow C++ collapse that code in case there is no load barriers? 2. Can you explain Phi case more. I would like to see an assert which verify cush shape of code to avoid cases when Phi come from loop, for example. Thanks, Vladimir On 8/1/18 4:17 AM, Erik ?sterlund wrote: > Hi, > > There is currently no way of doing IN_NATIVE accesses in C2 using its > access API. These are required to properly access OopHandle, used to > access the Java class mirrors (because they will now start requiring > load barriers). In order to support (concurrent) class unloading in ZGC, > this support must be added. > > In this patch, I add an access_load API for loading IN_NATIVE oops, and > use it to load class mirrors (which is logically an OopHandle::resolve, > which happened to have been an indirect load before as nobody had load > barriers on it). In the various code recognizing the shape of a mirror > load to optimize the code, I have added a check if a node is a GC > barrier and to then step over it in order to match the mirror load. > > In order to recognize and step over the load barriers in ZGC properly, I > added support for recognizing the barrier shapes not just before macro > expansion (LoadBarrierNode), but also after macro expansion (as required > by the matching code), which involves checking for phi nodes with with > LoadBarrierSlowRegNode phi->in(1), and then stepping over to phi->in(2), > as well as recognizing projections to such shapes. > LoadBarrierSlowRegNode is used in all barrier expansions except for > atomic xchg, but that is fine as we don't use that on class mirrors. > > I have checked that the shapes are recognized and that no regressions > are introduced with these changes through a bunch of benchmarks in > gc-test-suite. > > Webrev: > http://cr.openjdk.java.net/~eosterlund/8208601/webrev.00/ > > > Bug URL: > https://bugs.openjdk.java.net/browse/JDK-8208601 > > > > Thanks, > /Erik > Open Tracking From igor.ignatyev at oracle.com Wed Aug 1 19:42:11 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 1 Aug 2018 12:42:11 -0700 Subject: RFR(XXS) : 8208647 : switch jtreg to 4.2b13 Message-ID: <362F2CE5-9DB1-4598-9ED2-742F66E170CB@oracle.com> http://cr.openjdk.java.net/~iignatyev/8208647/webrev.00/index.html > 5 lines changed: 0 ins; 0 del; 5 mod; Hi all, could you please review this small fix which switches jtreg to the latest available build? due to changes in javatest API, failure_handler had to be slightly updated. webrev: http://cr.openjdk.java.net/~iignatyev//8208647/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8208647 testing: tier1-2 Thanks, -- Igor From magnus.ihse.bursie at oracle.com Wed Aug 1 20:06:44 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 1 Aug 2018 13:06:44 -0700 Subject: RFR(XXS) : 8208647 : switch jtreg to 4.2b13 In-Reply-To: <362F2CE5-9DB1-4598-9ED2-742F66E170CB@oracle.com> References: <362F2CE5-9DB1-4598-9ED2-742F66E170CB@oracle.com> Message-ID: <99f1666e-8db8-fc1e-58ed-80df493dc533@oracle.com> On 2018-08-01 12:42, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev/8208647/webrev.00/index.html >> 5 lines changed: 0 ins; 0 del; 5 mod; > Hi all, > > could you please review this small fix which switches jtreg to the latest available build? due to changes in javatest API, failure_handler had to be slightly updated. > > webrev: http://cr.openjdk.java.net/~iignatyev//8208647/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8208647 Build changes look good. /Magnus > testing: tier1-2 > > Thanks, > -- Igor > > From kim.barrett at oracle.com Wed Aug 1 20:17:28 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 1 Aug 2018 16:17:28 -0400 Subject: [8u] RFR: 8196882: VS2017 Hotspot Defined vsnprintf Function Causes C2084 Already Defined Compilation Error In-Reply-To: <03da2c36-7650-9fde-79b2-ac1de2fd7f79@oracle.com> References: <0886e5e6-ab76-1b98-4047-ea86d860116b@oracle.com> <1775028E-BA4E-475C-BB6E-ED19CBF93ED1@oracle.com> <447ac3cc-68da-d1a5-b58e-35445c642728@oracle.com> <04810989-7A14-4F19-A6DE-AAEA96847278@oracle.com> <03da2c36-7650-9fde-79b2-ac1de2fd7f79@oracle.com> Message-ID: <2A634131-EC3F-45C6-87AC-F8C01F8E440C@oracle.com> > On Aug 1, 2018, at 10:47 AM, Kevin Walls wrote: > > Hi Kim, > > Yes we can try that way. I can reword the intention to be less particular about keeping old windows behaviour. > > A new change is that in 8u I found g1GCPhaseTimes.cpp has a vsnprintf which was checking for -1 to mean buffer too small. Yikes! That's a pretty bad pre-existing bug! This code doesn't seem to exist in later versions, having been replaced with UL. > http://cr.openjdk.java.net/~kevinw/8196882/webrev.02/ Looks good to me. From kevin.walls at oracle.com Wed Aug 1 21:53:28 2018 From: kevin.walls at oracle.com (Kevin Walls) Date: Wed, 1 Aug 2018 22:53:28 +0100 Subject: [8u] RFR: 8196882: VS2017 Hotspot Defined vsnprintf Function Causes C2084 Already Defined Compilation Error In-Reply-To: <2A634131-EC3F-45C6-87AC-F8C01F8E440C@oracle.com> References: <0886e5e6-ab76-1b98-4047-ea86d860116b@oracle.com> <1775028E-BA4E-475C-BB6E-ED19CBF93ED1@oracle.com> <447ac3cc-68da-d1a5-b58e-35445c642728@oracle.com> <04810989-7A14-4F19-A6DE-AAEA96847278@oracle.com> <03da2c36-7650-9fde-79b2-ac1de2fd7f79@oracle.com> <2A634131-EC3F-45C6-87AC-F8C01F8E440C@oracle.com> Message-ID: <57ac845b-294e-0a1d-0397-b5ad6afc9ee3@oracle.com> Great, thanks Kim! Yes, the g1GCPhaseTimes.cpp code went away in jdk9 with 8150068 (Log the main G1 phases at info level). Thanks Kevin On 01/08/2018 21:17, Kim Barrett wrote: >> On Aug 1, 2018, at 10:47 AM, Kevin Walls wrote: >> >> Hi Kim, >> >> Yes we can try that way. I can reword the intention to be less particular about keeping old windows behaviour. >> >> A new change is that in 8u I found g1GCPhaseTimes.cpp has a vsnprintf which was checking for -1 to mean buffer too small. > Yikes! That's a pretty bad pre-existing bug! This code doesn't seem > to exist in later versions, having been replaced with UL. > >> http://cr.openjdk.java.net/~kevinw/8196882/webrev.02/ > Looks good to me. > From vladimir.kozlov at oracle.com Wed Aug 1 22:32:21 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 1 Aug 2018 15:32:21 -0700 Subject: RFR(XXS) : 8208647 : switch jtreg to 4.2b13 In-Reply-To: <362F2CE5-9DB1-4598-9ED2-742F66E170CB@oracle.com> References: <362F2CE5-9DB1-4598-9ED2-742F66E170CB@oracle.com> Message-ID: Good. Vladimir On 8/1/18 12:42 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev/8208647/webrev.00/index.html >> 5 lines changed: 0 ins; 0 del; 5 mod; > > Hi all, > > could you please review this small fix which switches jtreg to the latest available build? due to changes in javatest API, failure_handler had to be slightly updated. > > webrev: http://cr.openjdk.java.net/~iignatyev//8208647/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8208647 > testing: tier1-2 > > Thanks, > -- Igor > > From david.holmes at oracle.com Thu Aug 2 05:33:34 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 2 Aug 2018 15:33:34 +1000 Subject: RFR(XXS) : 8208647 : switch jtreg to 4.2b13 In-Reply-To: <362F2CE5-9DB1-4598-9ED2-742F66E170CB@oracle.com> References: <362F2CE5-9DB1-4598-9ED2-742F66E170CB@oracle.com> Message-ID: <3b8b4352-61aa-c606-7495-c8c377e5d5ce@oracle.com> Hi Igor, On 2/08/2018 5:42 AM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev/8208647/webrev.00/index.html >> 5 lines changed: 0 ins; 0 del; 5 mod; > > Hi all, > > could you please review this small fix which switches jtreg to the latest available build? Okay. > due to changes in javatest API, failure_handler had to be slightly updated. Don't understand how anything in javatest affected the code you changed, but it's cleaner to specify its a Map and avoid the casts. Thanks, David > webrev: http://cr.openjdk.java.net/~iignatyev//8208647/webrev.00/index.html > JBS: https://bugs.openjdk.java.net/browse/JDK-8208647 > testing: tier1-2 > > Thanks, > -- Igor > > From igor.ignatyev at oracle.com Thu Aug 2 05:39:11 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 1 Aug 2018 22:39:11 -0700 Subject: RFR(XXS) : 8208647 : switch jtreg to 4.2b13 In-Reply-To: <3b8b4352-61aa-c606-7495-c8c377e5d5ce@oracle.com> References: <362F2CE5-9DB1-4598-9ED2-742F66E170CB@oracle.com> <3b8b4352-61aa-c606-7495-c8c377e5d5ce@oracle.com> Message-ID: <7DE61EE8-55B0-473B-9DB7-90394963084E@oracle.com> > On Aug 1, 2018, at 10:33 PM, David Holmes wrote: > > Hi Igor, > > On 2/08/2018 5:42 AM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev/8208647/webrev.00/index.html >>> 5 lines changed: 0 ins; 0 del; 5 mod; >> Hi all, >> could you please review this small fix which switches jtreg to the latest available build? > > Okay. > >> due to changes in javatest API, failure_handler had to be slightly updated. > > Don't understand how anything in javatest affected the code you changed, but it's cleaner to specify its a Map and avoid the casts. com.sun.javatest.InterviewParameters::save used to be 'save(Map)', and now it's 'save(Map)', so w/o changing 'map' local, we would get compile-time error. -- Igor > Thanks, > David > >> webrev: http://cr.openjdk.java.net/~iignatyev//8208647/webrev.00/index.html >> JBS: https://bugs.openjdk.java.net/browse/JDK-8208647 >> testing: tier1-2 >> Thanks, >> -- Igor From david.holmes at oracle.com Thu Aug 2 06:07:31 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 2 Aug 2018 16:07:31 +1000 Subject: RFR(XXS) : 8208647 : switch jtreg to 4.2b13 In-Reply-To: <7DE61EE8-55B0-473B-9DB7-90394963084E@oracle.com> References: <362F2CE5-9DB1-4598-9ED2-742F66E170CB@oracle.com> <3b8b4352-61aa-c606-7495-c8c377e5d5ce@oracle.com> <7DE61EE8-55B0-473B-9DB7-90394963084E@oracle.com> Message-ID: <7c6d3fcf-5eb9-e65b-5d7c-589ba66c5dcd@oracle.com> On 2/08/2018 3:39 PM, Igor Ignatyev wrote: > > >> On Aug 1, 2018, at 10:33 PM, David Holmes wrote: >> >> Hi Igor, >> >> On 2/08/2018 5:42 AM, Igor Ignatyev wrote: >>> http://cr.openjdk.java.net/~iignatyev/8208647/webrev.00/index.html >>>> 5 lines changed: 0 ins; 0 del; 5 mod; >>> Hi all, >>> could you please review this small fix which switches jtreg to the latest available build? >> >> Okay. >> >>> due to changes in javatest API, failure_handler had to be slightly updated. >> >> Don't understand how anything in javatest affected the code you changed, but it's cleaner to specify its a Map and avoid the casts. > > com.sun.javatest.InterviewParameters::save used to be 'save(Map)', and now it's 'save(Map)', so w/o changing 'map' local, we would get compile-time error. Ah! Of course. Thanks, David > -- Igor >> Thanks, >> David >> >>> webrev: http://cr.openjdk.java.net/~iignatyev//8208647/webrev.00/index.html >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8208647 >>> testing: tier1-2 >>> Thanks, >>> -- Igor > From thomas.schatzl at oracle.com Thu Aug 2 09:07:21 2018 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 02 Aug 2018 11:07:21 +0200 Subject: RFR (XL): 8208669: GC changes to allow enabling -Wreorder Message-ID: <1fe17e13a5aeb583f05061c1cab6b55b7bdd4279.camel@oracle.com> Hi all, there have been several suggestions to try to fix the Hotspot code to allow us to enable -Wreorder in the Hotspot sources. This should make problems due to use-before-initialization much more obvious. This change fixes initializer lists for the GC directories. There should be no change in code behavior, except for that there is iirc one minor change that fixes the memory type of one initialization from mtInternal to mtGC. A later follow-up will enable -Wreorder in the makefiles. CR: https://bugs.openjdk.java.net/browse/JDK-8208669 Webrev: http://cr.openjdk.java.net/~tschatzl/8208669/webrev/ Testing: hs-tier1-4,jdk-tier1-3 Thanks, Thomas From thomas.schatzl at oracle.com Thu Aug 2 09:08:36 2018 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 02 Aug 2018 11:08:36 +0200 Subject: RFR (L): 8208670: Compiler changes to allow enabling -Wreorder Message-ID: <98c2eaaf111cee13dbe4470b98a22c0c08ed4b17.camel@oracle.com> Hi all, there have been several suggestions to try to fix the Hotspot code to allow us to enable -Wreorder in the Hotspot sources. This should make problems due to use-before-initialization much more obvious. This change fixes initializer lists for the compiler directories. There should be no change in code behavior. A later follow-up will enable -Wreorder in the makefiles. CR: https://bugs.openjdk.java.net/browse/JDK-8208670 Webrev: http://cr.openjdk.java.net/~tschatzl/8208670/webrev/ Testing: hs-tier1-4,jdk-tier1-3 Thanks, Thomas From thomas.schatzl at oracle.com Thu Aug 2 09:09:47 2018 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 02 Aug 2018 11:09:47 +0200 Subject: RFR (L): 8208671: Runtime, JFR, Serviceability changes to allow enabling -Wreorder Message-ID: Hi all, there have been several suggestions to try to fix the Hotspot code to allow us to enable -Wreorder in the Hotspot sources. This should make problems due to use-before-initialization much more obvious. This change fixes initializer lists for the runtime, jfr and serviceability directories. There should be no change in code behavior. A later follow-up will enable -Wreorder in the makefiles. CR: https://bugs.openjdk.java.net/browse/JDK-8208671 Webrev: http://cr.openjdk.java.net/~tschatzl/8208671/webrev/ Testing: hs-tier1-4,jdk-tier1-3 Thanks, Thomas From thomas.schatzl at oracle.com Thu Aug 2 09:14:08 2018 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 02 Aug 2018 11:14:08 +0200 Subject: RFR (XXS): 8208672: Enable -Wreorder in make files Message-ID: Hi all, there have been several suggestions to try to fix the Hotspot code to allow us to enable -Wreorder in the Hotspot sources. This should make problems due to use-before-initialization much more obvious. This change enables -Wreorder for gcc and clang. Of course it needs all previous RFRs sent to hotspot-dev to be checked in first to result in successful compilation of the code. Also checked by looking at the generated spec.gmk file which seems to result in the flag in the I think "right" flag, but I am not very knowledgable in this area. build-dev is CC'ed. CR: https://bugs.openjdk.java.net/browse/JDK-8208672 Webrev: http://cr.openjdk.java.net/~tschatzl/8208672/webrev/ Testing: hs-tier1-4,jdk-tier1-3 Thanks, Thomas From thomas.schatzl at oracle.com Thu Aug 2 09:20:26 2018 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 02 Aug 2018 11:20:26 +0200 Subject: RFR (XXS): 8208672: Enable -Wreorder in make files In-Reply-To: References: Message-ID: Hi, note: I have only been able to build Oracle platforms (x64-linux, osx, sparc-solaris, win64) with this enabled. It would be nice to get confirmation that other platforms will not break. Thanks, Thomas On Thu, 2018-08-02 at 11:14 +0200, Thomas Schatzl wrote: > Hi all, > > there have been several suggestions to try to fix the Hotspot code > to > allow us to enable -Wreorder in the Hotspot sources. > This should make problems due to use-before-initialization much more > obvious. > > This change enables -Wreorder for gcc and clang. > > Of course it needs all previous RFRs sent to hotspot-dev to be > checked > in first to result in successful compilation of the code. > > Also checked by looking at the generated spec.gmk file which seems to > result in the flag in the I think "right" flag, but I am not very > knowledgable in this area. > > build-dev is CC'ed. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8208672 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8208672/webrev/ > Testing: > hs-tier1-4,jdk-tier1-3 > > Thanks, > Thomas From erik.osterlund at oracle.com Thu Aug 2 09:39:50 2018 From: erik.osterlund at oracle.com (=?utf-8?Q?Erik_=C3=96sterlund?=) Date: Thu, 2 Aug 2018 11:39:50 +0200 Subject: RFR: 8208601: Introduce native oop barriers in C2 for OopHandle In-Reply-To: <51231d8e-e2ed-3d95-2cb2-c8cb61cbe512@oracle.com> References: <5B6196CA.7080201@oracle.com> <51231d8e-e2ed-3d95-2cb2-c8cb61cbe512@oracle.com> Message-ID: <1C90F3B1-AB57-44AF-9030-26238CD42B1B@oracle.com> Hi Vladimir, Thank you for reviewing. Incremental: http://cr.openjdk.java.net/~eosterlund/8208601/webrev.00_01/ Full: http://cr.openjdk.java.net/~eosterlund/8208601/webrev.01/ > On 01 Aug 2018, at 20:03, Vladimir Kozlov wrote: > > Hi, Erik > > 1. is_gc_barrier_node(b) is virtual so even if it return 'false' I am not sure C++ will collapse new search loops in phaseX.cpp and checks in other cases. Can we use some static check to allow C++ collapse that code in case there is no load barriers? I see your point. I introduced a has_load_barrier() function in BarrierSetC2 that I can check outside of the loop, to make the extra load barrier search conditional. Was it something like this you had in mind? > 2. Can you explain Phi case more. I would like to see an assert which verify cush shape of code to avoid cases when Phi come from loop, for example. Sure. The load barrier has different shapes before and after macro expansion. Before macro expansion it is just a LoadBarrierNode. After expanding the barrier, the pseudo code for the inflated barrier looks something like this: value = is_bad(some_oop) ? slowpath_load : some_oop. The value in that pseudo code is the particular phi I am matching. What is unique about this phi (corresponding to the barrier region node depicting the good_or_null vs bad control flows), compared to an arbitrary phi, is that in(1) is the slowpath_load (LoadBarrierSlowPathRegNode) taken if the oop is bad. A phi in e.g. a loop would point to another phi with this property inside e.g. the loop body, never directly to a slowpath_load (LoadBarrierSlowPathRegNode). Note that there is a basic and optimized macro expansion of the load barrier. The matching I use catches the optimized variant only (which uses the LoadBarrierSlowPathRegNode for the slow path). The basic barrier expansion is only used for atomic xchg (because self-healing the pointer would be an error in that path). In the new version, I added some assertions right where load barriers are produced and expanded, to assert that it matches and can be stepped over reliably. That way, if we change the barriers, the matching code will not silently stop working. To make these asserts work, I added support for matching barriers on weak barriers as well, that use LoadBarrierWeakSlowPathRegNode. While that isn?t needed for my purposes for loading the mirror, it is better to be more complete. Now you can see at the assertions in ZBarrierSetC2::expand_loadbarrier_optimized the exact phi that I am matching. I have still intentionally left matching of the ?basic? load barrier used by atomic xchg for another day, as nobody has any need for that yet, and it is trickier to match. BTW, it would be nice if in C2 the Node class had a Node* _expanded_from member that could track the node that macro expanded a node, and remember that through cloning of nodes, so that things like this would reduce to simply node->expanded_from()->is_LoadBarrier(), rather than trying to recognize the shape of the expanded barriers. Perhaps that would be useful for others? I did try something like that originally (but tracked with a hashtable), but unfortunately ran into trouble with cloned nodes not retaining the information, and made the decision to go for the shape recognition solution instead. But perhaps it could be generally useful for other shape recognition problems as well? But that might be outside the scope of this RFE. Thanks, /Erik > Thanks, > Vladimir > > On 8/1/18 4:17 AM, Erik ?sterlund wrote: >> Hi, >> There is currently no way of doing IN_NATIVE accesses in C2 using its access API. These are required to properly access OopHandle, used to access the Java class mirrors (because they will now start requiring load barriers). In order to support (concurrent) class unloading in ZGC, this support must be added. >> In this patch, I add an access_load API for loading IN_NATIVE oops, and use it to load class mirrors (which is logically an OopHandle::resolve, which happened to have been an indirect load before as nobody had load barriers on it). In the various code recognizing the shape of a mirror load to optimize the code, I have added a check if a node is a GC barrier and to then step over it in order to match the mirror load. >> In order to recognize and step over the load barriers in ZGC properly, I added support for recognizing the barrier shapes not just before macro expansion (LoadBarrierNode), but also after macro expansion (as required by the matching code), which involves checking for phi nodes with with LoadBarrierSlowRegNode phi->in(1), and then stepping over to phi->in(2), as well as recognizing projections to such shapes. LoadBarrierSlowRegNode is used in all barrier expansions except for atomic xchg, but that is fine as we don't use that on class mirrors. >> I have checked that the shapes are recognized and that no regressions are introduced with these changes through a bunch of benchmarks in gc-test-suite. >> Webrev: >> http://cr.openjdk.java.net/~eosterlund/8208601/webrev.00/ Bug URL: >> https://bugs.openjdk.java.net/browse/JDK-8208601 Thanks, >> /Erik >> Open Tracking From erik.osterlund at oracle.com Thu Aug 2 09:39:50 2018 From: erik.osterlund at oracle.com (=?utf-8?Q?Erik_=C3=96sterlund?=) Date: Thu, 2 Aug 2018 11:39:50 +0200 Subject: RFR: 8208601: Introduce native oop barriers in C2 for OopHandle In-Reply-To: <51231d8e-e2ed-3d95-2cb2-c8cb61cbe512@oracle.com> References: <5B6196CA.7080201@oracle.com> <51231d8e-e2ed-3d95-2cb2-c8cb61cbe512@oracle.com> Message-ID: <1C90F3B1-AB57-44AF-9030-26238CD42B1B@oracle.com> Hi Vladimir, Thank you for reviewing. Incremental: http://cr.openjdk.java.net/~eosterlund/8208601/webrev.00_01/ Full: http://cr.openjdk.java.net/~eosterlund/8208601/webrev.01/ > On 01 Aug 2018, at 20:03, Vladimir Kozlov wrote: > > Hi, Erik > > 1. is_gc_barrier_node(b) is virtual so even if it return 'false' I am not sure C++ will collapse new search loops in phaseX.cpp and checks in other cases. Can we use some static check to allow C++ collapse that code in case there is no load barriers? I see your point. I introduced a has_load_barrier() function in BarrierSetC2 that I can check outside of the loop, to make the extra load barrier search conditional. Was it something like this you had in mind? > 2. Can you explain Phi case more. I would like to see an assert which verify cush shape of code to avoid cases when Phi come from loop, for example. Sure. The load barrier has different shapes before and after macro expansion. Before macro expansion it is just a LoadBarrierNode. After expanding the barrier, the pseudo code for the inflated barrier looks something like this: value = is_bad(some_oop) ? slowpath_load : some_oop. The value in that pseudo code is the particular phi I am matching. What is unique about this phi (corresponding to the barrier region node depicting the good_or_null vs bad control flows), compared to an arbitrary phi, is that in(1) is the slowpath_load (LoadBarrierSlowPathRegNode) taken if the oop is bad. A phi in e.g. a loop would point to another phi with this property inside e.g. the loop body, never directly to a slowpath_load (LoadBarrierSlowPathRegNode). Note that there is a basic and optimized macro expansion of the load barrier. The matching I use catches the optimized variant only (which uses the LoadBarrierSlowPathRegNode for the slow path). The basic barrier expansion is only used for atomic xchg (because self-healing the pointer would be an error in that path). In the new version, I added some assertions right where load barriers are produced and expanded, to assert that it matches and can be stepped over reliably. That way, if we change the barriers, the matching code will not silently stop working. To make these asserts work, I added support for matching barriers on weak barriers as well, that use LoadBarrierWeakSlowPathRegNode. While that isn?t needed for my purposes for loading the mirror, it is better to be more complete. Now you can see at the assertions in ZBarrierSetC2::expand_loadbarrier_optimized the exact phi that I am matching. I have still intentionally left matching of the ?basic? load barrier used by atomic xchg for another day, as nobody has any need for that yet, and it is trickier to match. BTW, it would be nice if in C2 the Node class had a Node* _expanded_from member that could track the node that macro expanded a node, and remember that through cloning of nodes, so that things like this would reduce to simply node->expanded_from()->is_LoadBarrier(), rather than trying to recognize the shape of the expanded barriers. Perhaps that would be useful for others? I did try something like that originally (but tracked with a hashtable), but unfortunately ran into trouble with cloned nodes not retaining the information, and made the decision to go for the shape recognition solution instead. But perhaps it could be generally useful for other shape recognition problems as well? But that might be outside the scope of this RFE. Thanks, /Erik > Thanks, > Vladimir > > On 8/1/18 4:17 AM, Erik ?sterlund wrote: >> Hi, >> There is currently no way of doing IN_NATIVE accesses in C2 using its access API. These are required to properly access OopHandle, used to access the Java class mirrors (because they will now start requiring load barriers). In order to support (concurrent) class unloading in ZGC, this support must be added. >> In this patch, I add an access_load API for loading IN_NATIVE oops, and use it to load class mirrors (which is logically an OopHandle::resolve, which happened to have been an indirect load before as nobody had load barriers on it). In the various code recognizing the shape of a mirror load to optimize the code, I have added a check if a node is a GC barrier and to then step over it in order to match the mirror load. >> In order to recognize and step over the load barriers in ZGC properly, I added support for recognizing the barrier shapes not just before macro expansion (LoadBarrierNode), but also after macro expansion (as required by the matching code), which involves checking for phi nodes with with LoadBarrierSlowRegNode phi->in(1), and then stepping over to phi->in(2), as well as recognizing projections to such shapes. LoadBarrierSlowRegNode is used in all barrier expansions except for atomic xchg, but that is fine as we don't use that on class mirrors. >> I have checked that the shapes are recognized and that no regressions are introduced with these changes through a bunch of benchmarks in gc-test-suite. >> Webrev: >> http://cr.openjdk.java.net/~eosterlund/8208601/webrev.00/ Bug URL: >> https://bugs.openjdk.java.net/browse/JDK-8208601 Thanks, >> /Erik >> Open Tracking From erik.osterlund at oracle.com Thu Aug 2 09:39:50 2018 From: erik.osterlund at oracle.com (=?utf-8?Q?Erik_=C3=96sterlund?=) Date: Thu, 2 Aug 2018 11:39:50 +0200 Subject: RFR: 8208601: Introduce native oop barriers in C2 for OopHandle In-Reply-To: <51231d8e-e2ed-3d95-2cb2-c8cb61cbe512@oracle.com> References: <5B6196CA.7080201@oracle.com> <51231d8e-e2ed-3d95-2cb2-c8cb61cbe512@oracle.com> Message-ID: <1C90F3B1-AB57-44AF-9030-26238CD42B1B@oracle.com> Hi Vladimir, Thank you for reviewing. Incremental: http://cr.openjdk.java.net/~eosterlund/8208601/webrev.00_01/ Full: http://cr.openjdk.java.net/~eosterlund/8208601/webrev.01/ > On 01 Aug 2018, at 20:03, Vladimir Kozlov wrote: > > Hi, Erik > > 1. is_gc_barrier_node(b) is virtual so even if it return 'false' I am not sure C++ will collapse new search loops in phaseX.cpp and checks in other cases. Can we use some static check to allow C++ collapse that code in case there is no load barriers? I see your point. I introduced a has_load_barrier() function in BarrierSetC2 that I can check outside of the loop, to make the extra load barrier search conditional. Was it something like this you had in mind? > 2. Can you explain Phi case more. I would like to see an assert which verify cush shape of code to avoid cases when Phi come from loop, for example. Sure. The load barrier has different shapes before and after macro expansion. Before macro expansion it is just a LoadBarrierNode. After expanding the barrier, the pseudo code for the inflated barrier looks something like this: value = is_bad(some_oop) ? slowpath_load : some_oop. The value in that pseudo code is the particular phi I am matching. What is unique about this phi (corresponding to the barrier region node depicting the good_or_null vs bad control flows), compared to an arbitrary phi, is that in(1) is the slowpath_load (LoadBarrierSlowPathRegNode) taken if the oop is bad. A phi in e.g. a loop would point to another phi with this property inside e.g. the loop body, never directly to a slowpath_load (LoadBarrierSlowPathRegNode). Note that there is a basic and optimized macro expansion of the load barrier. The matching I use catches the optimized variant only (which uses the LoadBarrierSlowPathRegNode for the slow path). The basic barrier expansion is only used for atomic xchg (because self-healing the pointer would be an error in that path). In the new version, I added some assertions right where load barriers are produced and expanded, to assert that it matches and can be stepped over reliably. That way, if we change the barriers, the matching code will not silently stop working. To make these asserts work, I added support for matching barriers on weak barriers as well, that use LoadBarrierWeakSlowPathRegNode. While that isn?t needed for my purposes for loading the mirror, it is better to be more complete. Now you can see at the assertions in ZBarrierSetC2::expand_loadbarrier_optimized the exact phi that I am matching. I have still intentionally left matching of the ?basic? load barrier used by atomic xchg for another day, as nobody has any need for that yet, and it is trickier to match. BTW, it would be nice if in C2 the Node class had a Node* _expanded_from member that could track the node that macro expanded a node, and remember that through cloning of nodes, so that things like this would reduce to simply node->expanded_from()->is_LoadBarrier(), rather than trying to recognize the shape of the expanded barriers. Perhaps that would be useful for others? I did try something like that originally (but tracked with a hashtable), but unfortunately ran into trouble with cloned nodes not retaining the information, and made the decision to go for the shape recognition solution instead. But perhaps it could be generally useful for other shape recognition problems as well? But that might be outside the scope of this RFE. Thanks, /Erik > Thanks, > Vladimir > > On 8/1/18 4:17 AM, Erik ?sterlund wrote: >> Hi, >> There is currently no way of doing IN_NATIVE accesses in C2 using its access API. These are required to properly access OopHandle, used to access the Java class mirrors (because they will now start requiring load barriers). In order to support (concurrent) class unloading in ZGC, this support must be added. >> In this patch, I add an access_load API for loading IN_NATIVE oops, and use it to load class mirrors (which is logically an OopHandle::resolve, which happened to have been an indirect load before as nobody had load barriers on it). In the various code recognizing the shape of a mirror load to optimize the code, I have added a check if a node is a GC barrier and to then step over it in order to match the mirror load. >> In order to recognize and step over the load barriers in ZGC properly, I added support for recognizing the barrier shapes not just before macro expansion (LoadBarrierNode), but also after macro expansion (as required by the matching code), which involves checking for phi nodes with with LoadBarrierSlowRegNode phi->in(1), and then stepping over to phi->in(2), as well as recognizing projections to such shapes. LoadBarrierSlowRegNode is used in all barrier expansions except for atomic xchg, but that is fine as we don't use that on class mirrors. >> I have checked that the shapes are recognized and that no regressions are introduced with these changes through a bunch of benchmarks in gc-test-suite. >> Webrev: >> http://cr.openjdk.java.net/~eosterlund/8208601/webrev.00/ Bug URL: >> https://bugs.openjdk.java.net/browse/JDK-8208601 Thanks, >> /Erik >> Open Tracking From erik.osterlund at oracle.com Thu Aug 2 09:39:50 2018 From: erik.osterlund at oracle.com (=?utf-8?Q?Erik_=C3=96sterlund?=) Date: Thu, 2 Aug 2018 11:39:50 +0200 Subject: RFR: 8208601: Introduce native oop barriers in C2 for OopHandle In-Reply-To: <51231d8e-e2ed-3d95-2cb2-c8cb61cbe512@oracle.com> References: <5B6196CA.7080201@oracle.com> <51231d8e-e2ed-3d95-2cb2-c8cb61cbe512@oracle.com> Message-ID: <1C90F3B1-AB57-44AF-9030-26238CD42B1B@oracle.com> Hi Vladimir, Thank you for reviewing. Incremental: http://cr.openjdk.java.net/~eosterlund/8208601/webrev.00_01/ Full: http://cr.openjdk.java.net/~eosterlund/8208601/webrev.01/ > On 01 Aug 2018, at 20:03, Vladimir Kozlov wrote: > > Hi, Erik > > 1. is_gc_barrier_node(b) is virtual so even if it return 'false' I am not sure C++ will collapse new search loops in phaseX.cpp and checks in other cases. Can we use some static check to allow C++ collapse that code in case there is no load barriers? I see your point. I introduced a has_load_barrier() function in BarrierSetC2 that I can check outside of the loop, to make the extra load barrier search conditional. Was it something like this you had in mind? > 2. Can you explain Phi case more. I would like to see an assert which verify cush shape of code to avoid cases when Phi come from loop, for example. Sure. The load barrier has different shapes before and after macro expansion. Before macro expansion it is just a LoadBarrierNode. After expanding the barrier, the pseudo code for the inflated barrier looks something like this: value = is_bad(some_oop) ? slowpath_load : some_oop. The value in that pseudo code is the particular phi I am matching. What is unique about this phi (corresponding to the barrier region node depicting the good_or_null vs bad control flows), compared to an arbitrary phi, is that in(1) is the slowpath_load (LoadBarrierSlowPathRegNode) taken if the oop is bad. A phi in e.g. a loop would point to another phi with this property inside e.g. the loop body, never directly to a slowpath_load (LoadBarrierSlowPathRegNode). Note that there is a basic and optimized macro expansion of the load barrier. The matching I use catches the optimized variant only (which uses the LoadBarrierSlowPathRegNode for the slow path). The basic barrier expansion is only used for atomic xchg (because self-healing the pointer would be an error in that path). In the new version, I added some assertions right where load barriers are produced and expanded, to assert that it matches and can be stepped over reliably. That way, if we change the barriers, the matching code will not silently stop working. To make these asserts work, I added support for matching barriers on weak barriers as well, that use LoadBarrierWeakSlowPathRegNode. While that isn?t needed for my purposes for loading the mirror, it is better to be more complete. Now you can see at the assertions in ZBarrierSetC2::expand_loadbarrier_optimized the exact phi that I am matching. I have still intentionally left matching of the ?basic? load barrier used by atomic xchg for another day, as nobody has any need for that yet, and it is trickier to match. BTW, it would be nice if in C2 the Node class had a Node* _expanded_from member that could track the node that macro expanded a node, and remember that through cloning of nodes, so that things like this would reduce to simply node->expanded_from()->is_LoadBarrier(), rather than trying to recognize the shape of the expanded barriers. Perhaps that would be useful for others? I did try something like that originally (but tracked with a hashtable), but unfortunately ran into trouble with cloned nodes not retaining the information, and made the decision to go for the shape recognition solution instead. But perhaps it could be generally useful for other shape recognition problems as well? But that might be outside the scope of this RFE. Thanks, /Erik > Thanks, > Vladimir > > On 8/1/18 4:17 AM, Erik ?sterlund wrote: >> Hi, >> There is currently no way of doing IN_NATIVE accesses in C2 using its access API. These are required to properly access OopHandle, used to access the Java class mirrors (because they will now start requiring load barriers). In order to support (concurrent) class unloading in ZGC, this support must be added. >> In this patch, I add an access_load API for loading IN_NATIVE oops, and use it to load class mirrors (which is logically an OopHandle::resolve, which happened to have been an indirect load before as nobody had load barriers on it). In the various code recognizing the shape of a mirror load to optimize the code, I have added a check if a node is a GC barrier and to then step over it in order to match the mirror load. >> In order to recognize and step over the load barriers in ZGC properly, I added support for recognizing the barrier shapes not just before macro expansion (LoadBarrierNode), but also after macro expansion (as required by the matching code), which involves checking for phi nodes with with LoadBarrierSlowRegNode phi->in(1), and then stepping over to phi->in(2), as well as recognizing projections to such shapes. LoadBarrierSlowRegNode is used in all barrier expansions except for atomic xchg, but that is fine as we don't use that on class mirrors. >> I have checked that the shapes are recognized and that no regressions are introduced with these changes through a bunch of benchmarks in gc-test-suite. >> Webrev: >> http://cr.openjdk.java.net/~eosterlund/8208601/webrev.00/ Bug URL: >> https://bugs.openjdk.java.net/browse/JDK-8208601 Thanks, >> /Erik >> Open Tracking From erik.osterlund at oracle.com Thu Aug 2 10:51:53 2018 From: erik.osterlund at oracle.com (=?utf-8?Q?Erik_=C3=96sterlund?=) Date: Thu, 2 Aug 2018 12:51:53 +0200 Subject: RFR: 8208601: Introduce native oop barriers in C2 for OopHandle In-Reply-To: <51231d8e-e2ed-3d95-2cb2-c8cb61cbe512@oracle.com> References: <5B6196CA.7080201@oracle.com> <51231d8e-e2ed-3d95-2cb2-c8cb61cbe512@oracle.com> Message-ID: <2AA0B2F2-0EE3-4AFF-8D01-815AE2A04081@oracle.com> Hi Vladimir, Thank you for reviewing. Incremental: http://cr.openjdk.java.net/~eosterlund/8208601/webrev.00_01/ Full: http://cr.openjdk.java.net/~eosterlund/8208601/webrev.01/ > On 01 Aug 2018, at 20:03, Vladimir Kozlov > wrote: > > Hi, Erik > > 1. is_gc_barrier_node(b) is virtual so even if it return 'false' I am not sure C++ will collapse new search loops in phaseX.cpp and checks in other cases. Can we use some static check to allow C++ collapse that code in case there is no load barriers? I see your point. I introduced a has_load_barrier() function in BarrierSetC2 that I can check outside of the loop, to make the extra load barrier search conditional. Was it something like this you had in mind? > 2. Can you explain Phi case more. I would like to see an assert which verify cush shape of code to avoid cases when Phi come from loop, for example. Sure. The load barrier has different shapes before and after macro expansion. Before macro expansion it is just a LoadBarrierNode. After expanding the barrier, the pseudo code for the inflated barrier looks something like this: value = is_bad(some_oop) ? slowpath_load : some_oop. The value in that pseudo code is the particular phi I am matching. What is unique about this phi (corresponding to the barrier region node depicting the good_or_null vs bad control flows), compared to an arbitrary phi, is that in(1) is the slowpath_load (LoadBarrierSlowPathRegNode) taken if the oop is bad. A phi in e.g. a loop would point to another phi with this property inside e.g. the loop body, never directly to a slowpath_load (LoadBarrierSlowPathRegNode). Note that there is a basic and optimized macro expansion of the load barrier. The matching I use catches the optimized variant only (which uses the LoadBarrierSlowPathRegNode for the slow path). The basic barrier expansion is only used for atomic xchg (because self-healing the pointer would be an error in that path). In the new version, I added some assertions right where load barriers are produced and expanded, to assert that it matches and can be stepped over reliably. That way, if we change the barriers, the matching code will not silently stop working. To make these asserts work, I added support for matching barriers on weak barriers as well, that use LoadBarrierWeakSlowPathRegNode. While that isn?t needed for my purposes for loading the mirror, it is better to be more complete. Now you can see at the assertions in ZBarrierSetC2::expand_loadbarrier_optimized the exact phi that I am matching. I have still intentionally left matching of the ?basic? load barrier used by atomic xchg for another day, as nobody has any need for that yet, and it is trickier to match. BTW, it would be nice if in C2 the Node class had a Node* _expanded_from member that could track the node that macro expanded a node, and remember that through cloning of nodes, so that things like this would reduce to simply node->expanded_from()->is_LoadBarrier(), rather than trying to recognize the shape of the expanded barriers. Perhaps that would be useful for others? I did try something like that originally (but tracked with a hashtable), but unfortunately ran into trouble with cloned nodes not retaining the information, and made the decision to go for the shape recognition solution instead. But perhaps it could be generally useful for other shape recognition problems as well? But that might be outside the scope of this RFE. Thanks, /Erik From erik.osterlund at oracle.com Thu Aug 2 10:58:10 2018 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Thu, 2 Aug 2018 12:58:10 +0200 Subject: RFR: 8208601: Introduce native oop barriers in C2 for OopHandle In-Reply-To: <51231d8e-e2ed-3d95-2cb2-c8cb61cbe512@oracle.com> References: <5B6196CA.7080201@oracle.com> <51231d8e-e2ed-3d95-2cb2-c8cb61cbe512@oracle.com> Message-ID: <08E51C4E-F72C-4C43-AD71-DBA6791E1482@oracle.com> Hi Vladimir, Thank you for reviewing. Incremental: http://cr.openjdk.java.net/~eosterlund/8208601/webrev.00_01/ Full: http://cr.openjdk.java.net/~eosterlund/8208601/webrev.01/ > On 01 Aug 2018, at 20:03, Vladimir Kozlov wrote: > > Hi, Erik > > 1. is_gc_barrier_node(b) is virtual so even if it return 'false' I am not sure C++ will collapse new search loops in phaseX.cpp and checks in other cases. Can we use some static check to allow C++ collapse that code in case there is no load barriers? I see your point. I introduced a has_load_barrier() function in BarrierSetC2 that I can check outside of the loop, to make the extra load barrier search conditional. Was it something like this you had in mind? > 2. Can you explain Phi case more. I would like to see an assert which verify cush shape of code to avoid cases when Phi come from loop, for example. Sure. The load barrier has different shapes before and after macro expansion. Before macro expansion it is just a LoadBarrierNode. After expanding the barrier, the pseudo code for the inflated barrier looks something like this: value = is_bad(some_oop) ? slowpath_load : some_oop. The value in that pseudo code is the particular phi I am matching. What is unique about this phi (corresponding to the barrier region node depicting the good_or_null vs bad control flows), compared to an arbitrary phi, is that in(1) is the slowpath_load (LoadBarrierSlowPathRegNode) taken if the oop is bad. A phi in e.g. a loop would point to another phi with this property inside e.g. the loop body, never directly to a slowpath_load (LoadBarrierSlowPathRegNode). Note that there is a basic and optimized macro expansion of the load barrier. The matching I use catches the optimized variant only (which uses the LoadBarrierSlowPathRegNode for the slow path). The basic barrier expansion is only used for atomic xchg (because self-healing the pointer would be an error in that path). In the new version, I added some assertions right where load barriers are produced and expanded, to assert that it matches and can be stepped over reliably. That way, if we change the barriers, the matching code will not silently stop working. To make these asserts work, I added support for matching barriers on weak barriers as well, that use LoadBarrierWeakSlowPathRegNode. While that isn?t needed for my purposes for loading the mirror, it is better to be more complete. Now you can see at the assertions in ZBarrierSetC2::expand_loadbarrier_optimized the exact phi that I am matching. I have still intentionally left matching of the ?basic? load barrier used by atomic xchg for another day, as nobody has any need for that yet, and it is trickier to match. BTW, it would be nice if in C2 the Node class had a Node* _expanded_from member that could track the node that macro expanded a node, and remember that through cloning of nodes, so that things like this would reduce to simply node->expanded_from()->is_LoadBarrier(), rather than trying to recognize the shape of the expanded barriers. Perhaps that would be useful for others? I did try something like that originally (but tracked with a hashtable), but unfortunately ran into trouble with cloned nodes not retaining the information, and made the decision to go for the shape recognition solution instead. But perhaps it could be generally useful for other shape recognition problems as well? But that might be outside the scope of this RFE. Thanks, /Erik From erik.osterlund at oracle.com Thu Aug 2 11:52:23 2018 From: erik.osterlund at oracle.com (=?utf-8?Q?Erik_=C3=96sterlund?=) Date: Thu, 2 Aug 2018 13:52:23 +0200 Subject: RFR: 8208582: Introduce native oop barriers in C1 for OopHandle In-Reply-To: References: <1533049674.local-48cfadc1-4a64-v1.3.0-fd741eb7@getmailspring.com> Message-ID: Hi Vladimir, Thanks for the review. /Erik > On 01 Aug 2018, at 06:27, Vladimir Kozlov wrote: > > Seems fine. > > Thanks, > Vladimir > > On 7/31/18 8:44 AM, Erik Osterlund wrote: >> +hotspot-dev by popular demand >>> On 31 Jul 2018, at 17:35, Erik ?sterlund wrote: >>> >>> Hi, >>> >>> There is currently no way of doing IN_NATIVE accesses in C1 using its access API. These are required to properly access OopHandle, used to access the Java class mirrors (because they will now start requiring load barriers). In order to support concurrent class unloading in ZGC, this support must be added. >>> >>> This webrev adds C1 support for this: >>> http://cr.openjdk.java.net/~eosterlund/8208582/webrev.00/ >>> Bug URL: >>> https://bugs.openjdk.java.net/browse/JDK-8208582 >>> >>> Thanks, >>> /Erik From david.holmes at oracle.com Thu Aug 2 12:34:02 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 2 Aug 2018 22:34:02 +1000 Subject: RFR (L): 8208671: Runtime, JFR, Serviceability changes to allow enabling -Wreorder In-Reply-To: References: Message-ID: <2497c761-d4aa-12a7-cc41-6ac342cbf8da@oracle.com> Hi Thomas, On 2/08/2018 7:09 PM, Thomas Schatzl wrote: > Hi all, > > there have been several suggestions to try to fix the Hotspot code to > allow us to enable -Wreorder in the Hotspot sources. Can you enlighten us on what -Wreorder is/does and so what changes you are making please. Thanks, David > This should make problems due to use-before-initialization much more > obvious. > > This change fixes initializer lists for the runtime, jfr and > serviceability directories. > > There should be no change in code behavior. > > A later follow-up will enable -Wreorder in the makefiles. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8208671 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8208671/webrev/ > Testing: > hs-tier1-4,jdk-tier1-3 > > Thanks, > Thomas > From thomas.schatzl at oracle.com Thu Aug 2 12:51:44 2018 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 02 Aug 2018 14:51:44 +0200 Subject: RFR (L): 8208671: Runtime, JFR, Serviceability changes to allow enabling -Wreorder In-Reply-To: <2497c761-d4aa-12a7-cc41-6ac342cbf8da@oracle.com> References: <2497c761-d4aa-12a7-cc41-6ac342cbf8da@oracle.com> Message-ID: Hi, On Thu, 2018-08-02 at 22:34 +1000, David Holmes wrote: > Hi Thomas, > > On 2/08/2018 7:09 PM, Thomas Schatzl wrote: > > Hi all, > > > > there have been several suggestions to try to fix the Hotspot > > code to > > allow us to enable -Wreorder in the Hotspot sources. > > Can you enlighten us on what -Wreorder is/does and so what changes > you are making please. oh, sorry, my fault. -Wreorder is a compiler switch that checks that the order of declaration of members in the initializer lists of constructors match the order of declaration in the class. C++ always initializes members in the initializer list in the order of the declaration in the class, it does not matter whether you specify it differently in the initializer list or not. An often overseen error is that you accidentally use other members in the initializer list that actually have not been initialized yet, although you did the right ordering in the initializer list. E.g. class X { int b; int a; X() : a(5), b(a) { // actually the content of b is undefined here. As per standard // your program will always initialize b before a. } } These are somewhat hard to detect errors that might go unnoticed for a while otherwise. -Wreorder forces you to have b before a in above example in your initializer list by giving a warning otherwise, which causes compilation failure. Thanks, Thomas > > Thanks, > David > > > This should make problems due to use-before-initialization much > > more > > obvious. > > > > This change fixes initializer lists for the runtime, jfr and > > serviceability directories. > > > > There should be no change in code behavior. > > > > A later follow-up will enable -Wreorder in the makefiles. > > > > CR: > > https://bugs.openjdk.java.net/browse/JDK-8208671 > > Webrev: > > http://cr.openjdk.java.net/~tschatzl/8208671/webrev/ > > Testing: > > hs-tier1-4,jdk-tier1-3 > > > > Thanks, > > Thomas > > From thomas.schatzl at oracle.com Thu Aug 2 15:08:34 2018 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 02 Aug 2018 17:08:34 +0200 Subject: RFR (L): 8208671: Runtime, JFR, Serviceability changes to allow enabling -Wreorder In-Reply-To: References: <2497c761-d4aa-12a7-cc41-6ac342cbf8da@oracle.com> Message-ID: <574dd38f0014e5cd58bc2aea2f3e082f7788e3f6.camel@oracle.com> Hi again, On Thu, 2018-08-02 at 14:51 +0200, Thomas Schatzl wrote: > Hi, > > On Thu, 2018-08-02 at 22:34 +1000, David Holmes wrote: > > Hi Thomas, > > > > On 2/08/2018 7:09 PM, Thomas Schatzl wrote: > > > Hi all, > > > > > > there have been several suggestions to try to fix the Hotspot > > > code to allow us to enable -Wreorder in the Hotspot sources. > > > > Can you enlighten us on what -Wreorder is/does and so what changes > > you are making please. > ... and answering the second part of the question: the changes reorder the entries in the initialization lists to have them written down in order of actual execution. This helps spotting mistakes due to dependencies in these lists: while this is not common, we have had such issues in the past (with G1). It is very easy to spot these problems with a properly ordered initialization list. Thanks, Thomas From vladimir.kozlov at oracle.com Thu Aug 2 16:31:17 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 2 Aug 2018 09:31:17 -0700 Subject: RFR (L): 8208670: Compiler changes to allow enabling -Wreorder In-Reply-To: <98c2eaaf111cee13dbe4470b98a22c0c08ed4b17.camel@oracle.com> References: <98c2eaaf111cee13dbe4470b98a22c0c08ed4b17.camel@oracle.com> Message-ID: <07538e77-b327-8c60-34d1-6e998e41a688@oracle.com> Looks good to me. Thanks, Vladimir On 8/2/18 2:08 AM, Thomas Schatzl wrote: > Hi all, > > there have been several suggestions to try to fix the Hotspot code to > allow us to enable -Wreorder in the Hotspot sources. > This should make problems due to use-before-initialization much more > obvious. > > This change fixes initializer lists for the compiler directories. > > There should be no change in code behavior. > > A later follow-up will enable -Wreorder in the makefiles. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8208670 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8208670/webrev/ > Testing: > hs-tier1-4,jdk-tier1-3 > > Thanks, > Thomas > From vladimir.kozlov at oracle.com Thu Aug 2 17:03:17 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 2 Aug 2018 10:03:17 -0700 Subject: RFR: 8208601: Introduce native oop barriers in C2 for OopHandle In-Reply-To: <1C90F3B1-AB57-44AF-9030-26238CD42B1B@oracle.com> References: <5B6196CA.7080201@oracle.com> <51231d8e-e2ed-3d95-2cb2-c8cb61cbe512@oracle.com> <1C90F3B1-AB57-44AF-9030-26238CD42B1B@oracle.com> Message-ID: <349c262f-3fa3-db22-dd65-87a31e9314fc@oracle.com> Thanks Erik Wow! I got 18 copies of your response ;) On 8/2/18 2:39 AM, Erik ?sterlund wrote: > Hi Vladimir, > > Thank you for reviewing. > > Incremental: > http://cr.openjdk.java.net/~eosterlund/8208601/webrev.00_01/ > > Full: > http://cr.openjdk.java.net/~eosterlund/8208601/webrev.01/ > >> On 01 Aug 2018, at 20:03, Vladimir Kozlov wrote: >> >> Hi, Erik >> >> 1. is_gc_barrier_node(b) is virtual so even if it return 'false' I am not sure C++ will collapse new search loops in phaseX.cpp and checks in other cases. Can we use some static check to allow C++ collapse that code in case there is no load barriers? > > I see your point. I introduced a has_load_barrier() function in BarrierSetC2 that I can check outside of the loop, to make the extra load barrier search conditional. Was it something like this you had in mind? Yes, thanks. > >> 2. Can you explain Phi case more. I would like to see an assert which verify cush shape of code to avoid cases when Phi come from loop, for example. > > Sure. The load barrier has different shapes before and after macro expansion. Before macro expansion it is just a LoadBarrierNode. After expanding the barrier, the pseudo code for the inflated barrier looks something like this: value = is_bad(some_oop) ? slowpath_load : some_oop. The value in that pseudo code is the particular phi I am matching. What is unique about this phi (corresponding to the barrier region node depicting the good_or_null vs bad control flows), compared to an arbitrary phi, is that in(1) is the slowpath_load (LoadBarrierSlowPathRegNode) taken if the oop is bad. A phi in e.g. a loop would point to another phi with this property inside e.g. the loop body, never directly to a slowpath_load (LoadBarrierSlowPathRegNode). Thank you for explanation. My confusion come that you phi->in(2) is points to a value on one of branches which is inside original macro node. But looking on your pseud code it is some_oop which is what you want. One suggesting I would give is to add comments to each of 3 cases in step_over_gc_barrier() to be clear what function is looking for. Also for first case (Proj node) it would be nice to have assert to check node you expect this Proj is connected to. > > Note that there is a basic and optimized macro expansion of the load barrier. The matching I use catches the optimized variant only (which uses the LoadBarrierSlowPathRegNode for the slow path). The basic barrier expansion is only used for atomic xchg (because self-healing the pointer would be an error in that path). > > In the new version, I added some assertions right where load barriers are produced and expanded, to assert that it matches and can be stepped over reliably. That way, if we change the barriers, the matching code will not silently stop working. To make these asserts work, I added support for matching barriers on weak barriers as well, that use LoadBarrierWeakSlowPathRegNode. While that isn?t needed for my purposes for loading the mirror, it is better to be more complete. Now you can see at the assertions in ZBarrierSetC2::expand_loadbarrier_optimized the exact phi that I am matching. > > I have still intentionally left matching of the ?basic? load barrier used by atomic xchg for another day, as nobody has any need for that yet, and it is trickier to match. > > BTW, it would be nice if in C2 the Node class had a Node* _expanded_from member that could track the node that macro expanded a node, and remember that through cloning of nodes, so that things like this would reduce to simply node->expanded_from()->is_LoadBarrier(), rather than trying to recognize the shape of the expanded barriers. Perhaps that would be useful for others? I did try something like that originally (but tracked with a hashtable), but unfortunately ran into trouble with cloned nodes not retaining the information, and made the decision to go for the shape recognition solution instead. But perhaps it could be generally useful for other shape recognition problems as well? But that might be outside the scope of this RFE. Yes, it is different and not hard to do. Nobody asked it before. Thanks, Vladimir > > Thanks, > /Erik > >> Thanks, >> Vladimir >> >> On 8/1/18 4:17 AM, Erik ?sterlund wrote: >>> Hi, >>> There is currently no way of doing IN_NATIVE accesses in C2 using its access API. These are required to properly access OopHandle, used to access the Java class mirrors (because they will now start requiring load barriers). In order to support (concurrent) class unloading in ZGC, this support must be added. >>> In this patch, I add an access_load API for loading IN_NATIVE oops, and use it to load class mirrors (which is logically an OopHandle::resolve, which happened to have been an indirect load before as nobody had load barriers on it). In the various code recognizing the shape of a mirror load to optimize the code, I have added a check if a node is a GC barrier and to then step over it in order to match the mirror load. >>> In order to recognize and step over the load barriers in ZGC properly, I added support for recognizing the barrier shapes not just before macro expansion (LoadBarrierNode), but also after macro expansion (as required by the matching code), which involves checking for phi nodes with with LoadBarrierSlowRegNode phi->in(1), and then stepping over to phi->in(2), as well as recognizing projections to such shapes. LoadBarrierSlowRegNode is used in all barrier expansions except for atomic xchg, but that is fine as we don't use that on class mirrors. >>> I have checked that the shapes are recognized and that no regressions are introduced with these changes through a bunch of benchmarks in gc-test-suite. >>> Webrev: >>> http://cr.openjdk.java.net/~eosterlund/8208601/webrev.00/ Bug URL: >>> https://bugs.openjdk.java.net/browse/JDK-8208601 Thanks, >>> /Erik >>> Open Tracking > From harold.seigel at oracle.com Thu Aug 2 17:18:57 2018 From: harold.seigel at oracle.com (Harold David Seigel) Date: Thu, 2 Aug 2018 13:18:57 -0400 Subject: RFR (L): 8208671: Runtime, JFR, Serviceability changes to allow enabling -Wreorder In-Reply-To: References: Message-ID: <833bd65a-ac8f-2da9-3a8a-ced57b68ff66@oracle.com> Hi Thomas, The change looks good!? Just a few comments. In vm_operations.hpp, there an added call to _setter() in VM_FindDeadlocks(outputStream* st).? Is that call needed to initialize _setter() properly? - VM_FindDeadlocks(bool concurrent_locks) : _concurrent_locks(concurrent_locks), _out(NULL), _deadlocks(NULL), _setter() {}; - VM_FindDeadlocks(outputStream* st) : _concurrent_locks(true), _out(st), _deadlocks(NULL) {}; + VM_FindDeadlocks(bool concurrent_locks) : _concurrent_locks(concurrent_locks), _deadlocks(NULL), _out(NULL), _setter() {}; + VM_FindDeadlocks(outputStream* st) : _concurrent_locks(true), _deadlocks(NULL), _out(st), _setter() {}; In elfFuncDescTable.cpp, there an added call to _status(), is that call needed to initialize _status properly? - _file(file), _index(index), _section(file, shdr) { + _section(file, shdr), _file(file), _index(index), _status() { Thanks, Harold On 8/2/2018 5:09 AM, Thomas Schatzl wrote: > Hi all, > > there have been several suggestions to try to fix the Hotspot code to > allow us to enable -Wreorder in the Hotspot sources. > This should make problems due to use-before-initialization much more > obvious. > > This change fixes initializer lists for the runtime, jfr and > serviceability directories. > > There should be no change in code behavior. > > A later follow-up will enable -Wreorder in the makefiles. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8208671 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8208671/webrev/ > Testing: > hs-tier1-4,jdk-tier1-3 > > Thanks, > Thomas From thomas.schatzl at oracle.com Thu Aug 2 17:25:18 2018 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 02 Aug 2018 19:25:18 +0200 Subject: RFR (L): 8208671: Runtime, JFR, Serviceability changes to allow enabling -Wreorder In-Reply-To: <833bd65a-ac8f-2da9-3a8a-ced57b68ff66@oracle.com> References: <833bd65a-ac8f-2da9-3a8a-ced57b68ff66@oracle.com> Message-ID: <3a3af85971515faf72081773a1e7621a15d03a58.camel@oracle.com> Hi Harold, On Thu, 2018-08-02 at 13:18 -0400, Harold David Seigel wrote: > Hi Thomas, > > The change looks good! Just a few comments. > > In vm_operations.hpp, there an added call to _setter() in > VM_FindDeadlocks(outputStream* st). Is that call needed to > initialize > _setter() properly? > > - VM_FindDeadlocks(bool concurrent_locks) : > _concurrent_locks(concurrent_locks), _out(NULL), > _deadlocks(NULL), > _setter() {}; > - VM_FindDeadlocks(outputStream* st) : _concurrent_locks(true), > _out(st), _deadlocks(NULL) {}; > + VM_FindDeadlocks(bool concurrent_locks) : > _concurrent_locks(concurrent_locks), _deadlocks(NULL), > _out(NULL), > _setter() {}; > + VM_FindDeadlocks(outputStream* st) : _concurrent_locks(true), > _deadlocks(NULL), _out(st), _setter() {}; > > In elfFuncDescTable.cpp, there an added call to _status(), is that > call > needed to initialize _status properly? > > - _file(file), _index(index), _section(file, shdr) { > + _section(file, shdr), _file(file), _index(index), _status() { the reason they are still there because I initially started to add "missing" initialization code because I believe it is nice to have them, but later reversed course. The compiler will automatically add default initialization anyway, and I later felt this out of scope for this change anyway. I forgot to change these constructors back in these cases. I will remove them again, they are unnecessary. Sorry. Thanks, Thomas From magnus.ihse.bursie at oracle.com Thu Aug 2 17:42:02 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 2 Aug 2018 10:42:02 -0700 Subject: RFR (XXS): 8208672: Enable -Wreorder in make files In-Reply-To: References: Message-ID: <682FE819-F0FA-4965-94CF-B2702298FEB8@oracle.com> Looks good to me. /Magnus > 2 aug. 2018 kl. 02:14 skrev Thomas Schatzl : > > Hi all, > > there have been several suggestions to try to fix the Hotspot code to > allow us to enable -Wreorder in the Hotspot sources. > This should make problems due to use-before-initialization much more > obvious. > > This change enables -Wreorder for gcc and clang. > > Of course it needs all previous RFRs sent to hotspot-dev to be checked > in first to result in successful compilation of the code. > > Also checked by looking at the generated spec.gmk file which seems to > result in the flag in the I think "right" flag, but I am not very > knowledgable in this area. > > build-dev is CC'ed. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8208672 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8208672/webrev/ > Testing: > hs-tier1-4,jdk-tier1-3 > > Thanks, > Thomas From coleen.phillimore at oracle.com Thu Aug 2 18:03:45 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 2 Aug 2018 14:03:45 -0400 Subject: RFR: 8208601: Introduce native oop barriers in C2 for OopHandle In-Reply-To: <349c262f-3fa3-db22-dd65-87a31e9314fc@oracle.com> References: <5B6196CA.7080201@oracle.com> <51231d8e-e2ed-3d95-2cb2-c8cb61cbe512@oracle.com> <1C90F3B1-AB57-44AF-9030-26238CD42B1B@oracle.com> <349c262f-3fa3-db22-dd65-87a31e9314fc@oracle.com> Message-ID: <80311e46-b4e1-d9e0-cbea-94d8e023c4e8@oracle.com> On 8/2/18 1:03 PM, Vladimir Kozlov wrote: > Thanks Erik > > Wow! I got 18 copies of your response ;) Does it count as 18 code reviews? Coleen > > On 8/2/18 2:39 AM, Erik ?sterlund wrote: >> Hi Vladimir, >> >> Thank you for reviewing. >> >> Incremental: >> http://cr.openjdk.java.net/~eosterlund/8208601/webrev.00_01/ >> >> Full: >> http://cr.openjdk.java.net/~eosterlund/8208601/webrev.01/ >> >>> On 01 Aug 2018, at 20:03, Vladimir Kozlov >>> wrote: >>> >>> Hi, Erik >>> >>> 1. is_gc_barrier_node(b) is virtual so even if it return 'false' I >>> am not sure C++ will collapse new search loops in phaseX.cpp and >>> checks in other cases. Can we use some static check to allow C++ >>> collapse that code in case there is no load barriers? >> >> I see your point. I introduced a has_load_barrier() function in >> BarrierSetC2 that I can check outside of the loop, to make the extra >> load barrier search conditional. Was it something like this you had >> in mind? > > Yes, thanks. > >> >>> 2. Can you explain Phi case more. I would like to see an assert >>> which verify cush shape of code to avoid cases when Phi come from >>> loop, for example. >> >> Sure. The load barrier has different shapes before and after macro >> expansion. Before macro expansion it is just a LoadBarrierNode. After >> expanding the barrier, the pseudo code for the inflated barrier looks >> something like this: value = is_bad(some_oop) ? slowpath_load : >> some_oop. The value in that pseudo code is the particular phi I am >> matching. What is unique about this phi (corresponding to the barrier >> region node depicting the good_or_null vs bad control flows), >> compared to an arbitrary phi, is that in(1) is the slowpath_load >> (LoadBarrierSlowPathRegNode) taken if the oop is bad. A phi in e.g. a >> loop would point to another phi with this property inside e.g. the >> loop body, never directly to a slowpath_load >> (LoadBarrierSlowPathRegNode). > > Thank you for explanation. My confusion come that you phi->in(2) is > points to a value on one of branches which is inside original macro > node.? But looking on your pseud code it is some_oop which is what you > want. > > One suggesting I would give is to add comments to each of 3 cases in > step_over_gc_barrier() to be clear what function is looking for. > > Also for first case (Proj node) it would be nice to have assert to > check ?node you expect this Proj is connected to. > >> >> Note that there is a basic and optimized macro expansion of the load >> barrier. The matching I use catches the optimized variant only (which >> uses the LoadBarrierSlowPathRegNode for the slow path). The basic >> barrier expansion is only used for atomic xchg (because self-healing >> the pointer would be an error in that path). >> >> In the new version, I added some assertions right where load barriers >> are produced and expanded, to assert that it matches and can be >> stepped over reliably. That way, if we change the barriers, the >> matching code will not silently stop working. To make these asserts >> work, I added support for matching barriers on weak barriers as well, >> that use LoadBarrierWeakSlowPathRegNode. While that isn?t needed for >> my purposes for loading the mirror, it is better to be more complete. >> Now you can see at the assertions in >> ZBarrierSetC2::expand_loadbarrier_optimized the exact phi that I am >> matching. >> >> I have still intentionally left matching of the ?basic? load barrier >> used by atomic xchg for another day, as nobody has any need for that >> yet, and it is trickier to match. >> >> BTW, it would be nice if in C2 the Node class had a Node* >> _expanded_from member that could track the node that macro expanded a >> node, and remember that through cloning of nodes, so that things like >> this would reduce to simply node->expanded_from()->is_LoadBarrier(), >> rather than trying to recognize the shape of the expanded barriers. >> Perhaps that would be useful for others? I did try something like >> that originally (but tracked with a hashtable), but unfortunately ran >> into trouble with cloned nodes not retaining the information, and >> made the decision to go for the shape recognition solution instead. >> But perhaps it could be generally useful for other shape recognition >> problems as well? But that might be outside the scope of this RFE. > > Yes, it is different and not hard to do. Nobody asked it before. > > Thanks, > Vladimir > >> >> Thanks, >> /Erik >> >>> Thanks, >>> Vladimir >>> >>> On 8/1/18 4:17 AM, Erik ?sterlund wrote: >>>> Hi, >>>> There is currently no way of doing IN_NATIVE accesses in C2 using >>>> its access API. These are required to properly access OopHandle, >>>> used to access the Java class mirrors (because they will now start >>>> requiring load barriers). In order to support (concurrent) class >>>> unloading in ZGC, this support must be added. >>>> In this patch, I add an access_load API for loading IN_NATIVE oops, >>>> and use it to load class mirrors (which is logically an >>>> OopHandle::resolve, which happened to have been an indirect load >>>> before as nobody had load barriers on it). In the various code >>>> recognizing the shape of a mirror load to optimize the code, I have >>>> added a check if a node is a GC barrier and to then step over it in >>>> order to match the mirror load. >>>> In order to recognize and step over the load barriers in ZGC >>>> properly, I added support for recognizing the barrier shapes not >>>> just before macro expansion (LoadBarrierNode), but also after macro >>>> expansion (as required by the matching code), which involves >>>> checking for phi nodes with with LoadBarrierSlowRegNode phi->in(1), >>>> and then stepping over to phi->in(2), as well as recognizing >>>> projections to such shapes. LoadBarrierSlowRegNode is used in all >>>> barrier expansions except for atomic xchg, but that is fine as we >>>> don't use that on class mirrors. >>>> I have checked that the shapes are recognized and that no >>>> regressions are introduced with these changes through a bunch of >>>> benchmarks in gc-test-suite. >>>> Webrev: >>>> http://cr.openjdk.java.net/~eosterlund/8208601/webrev.00/ >>>> >>>> Bug URL: >>>> https://bugs.openjdk.java.net/browse/JDK-8208601 >>>> >>>> Thanks, >>>> /Erik >>>> Open Tracking >> From igor.ignatyev at oracle.com Thu Aug 2 20:32:50 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 2 Aug 2018 13:32:50 -0700 Subject: RFR(M) : 8208655 : use JTreg skipped status in hotspot tests Message-ID: <8C91061B-9C60-4B38-AA0B-DD4D75B164C4@oracle.com> http://cr.openjdk.java.net/~iignatyev//8208655/webrev.00/index.html > 481 lines changed: 202 ins; 185 del; 94 mod; Hi all, could you please review this clean up of some hotspot tests? these tests are inapplicable in some of configurations, in some cases this can be expressed by @requiers, in others it can not be due to a dynamic nature. the latter cases are addressed by using new functionality added to jtreg 4.2 b13[1] -- throwing jtreg.SkippedException exception, which is known by jtreg and if jtreg catches this exception from a test, the test's will be marked as skipped. webrev: http://cr.openjdk.java.net/~iignatyev//8208655/webrev.00/index.html testing: hotspot tests JBS: https://bugs.openjdk.java.net/browse/JDK-8208655 Thanks, -- Igor [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7901596 From harold.seigel at oracle.com Thu Aug 2 20:41:20 2018 From: harold.seigel at oracle.com (Harold David Seigel) Date: Thu, 2 Aug 2018 16:41:20 -0400 Subject: RFR(M) : 8208655 : use JTreg skipped status in hotspot tests In-Reply-To: <8C91061B-9C60-4B38-AA0B-DD4D75B164C4@oracle.com> References: <8C91061B-9C60-4B38-AA0B-DD4D75B164C4@oracle.com> Message-ID: <7ddfd5b3-9cd0-2dfc-5fa6-3ebb51db69a0@oracle.com> Hi Igor, In TestBootNativeLibraryPath.java should this: + * @requiers vm.bits != 32 be @requires vm.bits == 32 Thanks, Harold On 8/2/2018 4:32 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8208655/webrev.00/index.html >> 481 lines changed: 202 ins; 185 del; 94 mod; > Hi all, > > could you please review this clean up of some hotspot tests? these tests are inapplicable in some of configurations, in some cases this can be expressed by @requiers, in others it can not be due to a dynamic nature. the latter cases are addressed by using new functionality added to jtreg 4.2 b13[1] -- throwing jtreg.SkippedException exception, which is known by jtreg and if jtreg catches this exception from a test, the test's will be marked as skipped. > > webrev: http://cr.openjdk.java.net/~iignatyev//8208655/webrev.00/index.html > testing: hotspot tests > JBS: https://bugs.openjdk.java.net/browse/JDK-8208655 > > Thanks, > -- Igor > > [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7901596 From igor.ignatyev at oracle.com Thu Aug 2 20:44:31 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 2 Aug 2018 13:44:31 -0700 Subject: RFR(M) : 8208655 : use JTreg skipped status in hotspot tests In-Reply-To: <7ddfd5b3-9cd0-2dfc-5fa6-3ebb51db69a0@oracle.com> References: <8C91061B-9C60-4B38-AA0B-DD4D75B164C4@oracle.com> <7ddfd5b3-9cd0-2dfc-5fa6-3ebb51db69a0@oracle.com> Message-ID: <2E274B69-6105-4779-A54C-3DE2DCAD2C7A@oracle.com> Hi Harold, you are right, thanks for catching this. -- Igor > On Aug 2, 2018, at 1:41 PM, Harold David Seigel wrote: > > Hi Igor, > > In TestBootNativeLibraryPath.java should this: > > + * @requiers vm.bits != 32 > > be > > @requires vm.bits == 32 > > Thanks, Harold > > On 8/2/2018 4:32 PM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8208655/webrev.00/index.html >>> 481 lines changed: 202 ins; 185 del; 94 mod; >> Hi all, >> >> could you please review this clean up of some hotspot tests? these tests are inapplicable in some of configurations, in some cases this can be expressed by @requiers, in others it can not be due to a dynamic nature. the latter cases are addressed by using new functionality added to jtreg 4.2 b13[1] -- throwing jtreg.SkippedException exception, which is known by jtreg and if jtreg catches this exception from a test, the test's will be marked as skipped. >> >> webrev: http://cr.openjdk.java.net/~iignatyev//8208655/webrev.00/index.html >> testing: hotspot tests >> JBS: https://bugs.openjdk.java.net/browse/JDK-8208655 >> >> Thanks, >> -- Igor >> >> [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7901596 > From vladimir.kozlov at oracle.com Thu Aug 2 20:55:01 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 2 Aug 2018 13:55:01 -0700 Subject: JEP: https://bugs.openjdk.java.net/browse/JDK-8203832 In-Reply-To: References: <0ca282db-5b4f-607d-512a-a2183dbd4b73@oracle.com> Message-ID: <96806b1f-6fce-83e0-0ffb-02f7a19e8301@oracle.com> Thank you, Yumin, for answers. I added this conversation to JEP's comment. I talked with Yumin, Mikael V. and Gil (Azul) about this JEP and decided to move forward with this JEP. Tobias, can you review JEP and add new comments, questions if you have them. I will also ask Mikael V. to review and endorse it. Thanks, Vladimir On 5/31/18 8:01 PM, yumin qi wrote: > Hi, Tobias > > > Thanks for your review/questions. First I would introduce some > background of JWarmup application on use scenario and how we implement the > interaction between application and scheduling (dispatch system, DS). > > The load of each application is controlled by DS. The profiling data is > collected against real input data (so it mostly matches the application run > in production environments, thus reduce the deoptimization chance). When > run with profiling data, application gets notification from DS when > compiling should start, application then calls API to notify JVM the hot > methods recorded in file can be compiled, after the compilations, a > message sent out to DS so DS will dispatch load into this application. > > Now answer your questions: > > > Here are some questions more detailed questions: > > - How is it implemented? Is it based on the replay compilation framework? > > A: No, it does not base on replay compilation framework. The data structure > for recording profile is newly designed. > > - How do you handle dynamically generated code (for example, lambda forms)? > > A: Not handled for any dynamically generated methods. Since name are > generated different some time for different runs. > > - What information is stored/re-used and which profile is cached? > > A: class/method/init order/bci method data etc.. > > - Does it work for C1 and C2? > > A: C2 only, can make it work on C1. > > - How is the tiered compilation policy affected? > > A: Currently disabled. > > - When do we compile (if method is first used or are there still > thresholds)? > > A: see introduction above. No check for threshhold when compiling. > > - How do you avoid overloading the compile queue? > > A: In real application run, we did not find compile queue overloaded. This > also can be controlled since we know how many compiler threads configured, > and the size of recorded methods. > > - Is re-profiling/re-compilation supported? > > A: No. This answer also see answer for below question. > > - What if a method is deoptimized? Is the cached profile update and re-used? > > A: During run with pre-compiled methods, deoptimization is only seen with > null-check elimination so it is not eliminated. The profile data is not > updated and re-used. That is, after deoptimized, it starts from interpreter > mode like freshly loaded. > > > Thanks > > Yumin > > On Wed, May 30, 2018 at 11:38 PM, Tobias Hartmann < > tobias.hartmann at oracle.com> wrote: > >> Hi Yumin, >> >> This reminds me of a project we did for a student's bachelor thesis in >> 2015: >> https://github.com/mohlerm/hotspot/blob/master/report/ >> profile_caching_mohlerm.pdf >> >> We also published a paper on that topic: >> https://dl.acm.org/citation.cfm?id=3132210 >> >> Thanks for submitting the JEP, very interesting! Here are the things we've >> learned from the "cached >> profiles" project, maybe you can correct this from your experience with >> JWarmup: >> - Startup: We were seeing great improvements for some benchmarks but also >> large regressions for >> others. Problems like the overhead of reading the profiles, overloading >> the compile queue and >> increased compile time due to more optimizations affect the startup time. >> - Peak performance: Using profile information from a previous run might >> cause significant >> performance regressions in early stages of the execution. This is because >> a "late" profile is >> usually also the one with the fewest optimistic assumptions. For example, >> the latest profile from a >> previous run might have been updated right when the application was about >> to shut down. If this >> triggered class loading or has other side effects, we might not be able to >> inline some methods or >> perform other optimistic optimizations. Using this profile right from the >> beginning in a subsequent >> run limits peak performance significantly. >> >> Here are some questions more detailed questions: >> - How is it implemented? Is it based on the replay compilation framework? >> - How do you handle dynamically generated code (for example, lambda forms)? >> - What information is stored/re-used and which profile is cached? >> - Does it work for C1 and C2? >> - How is the tiered compilation policy affected? >> - When do we compile (if method is first used or are there still >> thresholds)? >> - How do you avoid overloading the compile queue? >> - Is re-profiling/re-compilation supported? >> - What if a method is deoptimized? Is the cached profile update and >> re-used? >> >> Best regards, >> Tobias >> >> On 29.05.2018 06:09, yumin qi wrote: >>> Hi? Experts >>> >>> This is a newly filed JEP (JWarmup) for working on resolving java >>> performance issue caused by both application load peaking up and JIT >>> threads compiling java hot methods happen at same time. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8203832 >>> >>> For a large java application, the load comes in short period of time, >>> like the 'Single Day' sale on Alibaba's e-commerce application, this >>> massive load comes in and makes many java methods ready for JIT >> compilation >>> to convert them into native methods. The compiler threads will kick in to >>> do the complication work and take system resource from mutator java >>> threads which are busy on processing requests thus lead to peak time >>> performance degradation. >>> >>> The JWarmup technique was proposed to avoid such issue by precompiling >>> the hot methods at application startup and it has been successfully >> applied >>> to Alibaba's e-commerce applications. We would like to contribute it to >>> OpenJDK and wish it can help java developers overcome the same issue. >>> >>> Please review and give your feedback. >>> >>> Thanks >>> Yumin >>> >>> (Alibaba Group Inc) >>> >> > From vladimir.kozlov at oracle.com Thu Aug 2 21:03:59 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 2 Aug 2018 14:03:59 -0700 Subject: RFR(M) : 8208655 : use JTreg skipped status in hotspot tests In-Reply-To: <8C91061B-9C60-4B38-AA0B-DD4D75B164C4@oracle.com> References: <8C91061B-9C60-4B38-AA0B-DD4D75B164C4@oracle.com> Message-ID: <2a55eac3-1511-4c7a-6d74-7b3779a1c239@oracle.com> Hmm, this look like overlap work done for https://bugs.openjdk.java.net/browse/JDK-8207965: http://cr.openjdk.java.net/~phh/8207965/webrev.02/ I was looking for mechanism to skip tests when Tiered compilation is not available. Reviewed. Thanks, Vladimir On 8/2/18 1:32 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8208655/webrev.00/index.html >> 481 lines changed: 202 ins; 185 del; 94 mod; > > Hi all, > > could you please review this clean up of some hotspot tests? these tests are inapplicable in some of configurations, in some cases this can be expressed by @requiers, in others it can not be due to a dynamic nature. the latter cases are addressed by using new functionality added to jtreg 4.2 b13[1] -- throwing jtreg.SkippedException exception, which is known by jtreg and if jtreg catches this exception from a test, the test's will be marked as skipped. > > webrev: http://cr.openjdk.java.net/~iignatyev//8208655/webrev.00/index.html > testing: hotspot tests > JBS: https://bugs.openjdk.java.net/browse/JDK-8208655 > > Thanks, > -- Igor > > [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7901596 > From ioi.lam at oracle.com Thu Aug 2 21:05:28 2018 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 2 Aug 2018 14:05:28 -0700 Subject: RFR(M) : 8208655 : use JTreg skipped status in hotspot tests In-Reply-To: <8C91061B-9C60-4B38-AA0B-DD4D75B164C4@oracle.com> References: <8C91061B-9C60-4B38-AA0B-DD4D75B164C4@oracle.com> Message-ID: Hi Igor, I looked at the 2 CDS tests: CdsSameObjectAlignment.java? -> this line is not needed: import jtreg.SkippedException; Also, the two tests didn't actually get run before??? Thanks for adding the @run lines :-) Thanks - ioi On 8/2/18 1:32 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8208655/webrev.00/index.html >> 481 lines changed: 202 ins; 185 del; 94 mod; > Hi all, > > could you please review this clean up of some hotspot tests? these tests are inapplicable in some of configurations, in some cases this can be expressed by @requiers, in others it can not be due to a dynamic nature. the latter cases are addressed by using new functionality added to jtreg 4.2 b13[1] -- throwing jtreg.SkippedException exception, which is known by jtreg and if jtreg catches this exception from a test, the test's will be marked as skipped. > > webrev: http://cr.openjdk.java.net/~iignatyev//8208655/webrev.00/index.html > testing: hotspot tests > JBS: https://bugs.openjdk.java.net/browse/JDK-8208655 > > Thanks, > -- Igor > > [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7901596 From igor.ignatyev at oracle.com Thu Aug 2 21:33:25 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 2 Aug 2018 14:33:25 -0700 Subject: RFR(M) : 8208655 : use JTreg skipped status in hotspot tests In-Reply-To: References: <8C91061B-9C60-4B38-AA0B-DD4D75B164C4@oracle.com> Message-ID: <350FBAEB-4669-4F3D-B74B-300FC3A1F3EA@oracle.com> Hi Ioi, thanks for looking at it. please see my answers inline. -- Igor > On Aug 2, 2018, at 2:05 PM, Ioi Lam wrote: > > Hi Igor, > > I looked at the 2 CDS tests: > > CdsSameObjectAlignment.java -> this line is not needed: import jtreg.SkippedException; thx, I started the patch w/ adding jtreg.SkippedException in all these tests and later decided to use @requiers if possible. will remove the line before pushing. > > > Also, the two tests didn't actually get run before??? Thanks for adding the @run lines :-) they were run, if there is are @run tags (incl. build, compile, ignore), jtreg adds implicit '@run main' > > Thanks > > - ioi > > > > On 8/2/18 1:32 PM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8208655/webrev.00/index.html >>> 481 lines changed: 202 ins; 185 del; 94 mod; >> Hi all, >> >> could you please review this clean up of some hotspot tests? these tests are inapplicable in some of configurations, in some cases this can be expressed by @requiers, in others it can not be due to a dynamic nature. the latter cases are addressed by using new functionality added to jtreg 4.2 b13[1] -- throwing jtreg.SkippedException exception, which is known by jtreg and if jtreg catches this exception from a test, the test's will be marked as skipped. >> >> webrev: http://cr.openjdk.java.net/~iignatyev//8208655/webrev.00/index.html >> testing: hotspot tests >> JBS: https://bugs.openjdk.java.net/browse/JDK-8208655 >> >> Thanks, >> -- Igor >> >> [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7901596 > From igor.ignatyev at oracle.com Thu Aug 2 21:37:28 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 2 Aug 2018 14:37:28 -0700 Subject: RFR(M) : 8208655 : use JTreg skipped status in hotspot tests In-Reply-To: <2a55eac3-1511-4c7a-6d74-7b3779a1c239@oracle.com> References: <8C91061B-9C60-4B38-AA0B-DD4D75B164C4@oracle.com> <2a55eac3-1511-4c7a-6d74-7b3779a1c239@oracle.com> Message-ID: Hi Vladimir, will you or Paul (or Xin?) take care about updating 8207965 patch? or do you want me to wait till it's integrated and update mine? -- Igor > On Aug 2, 2018, at 2:03 PM, Vladimir Kozlov wrote: > > Hmm, this look like overlap work done for https://bugs.openjdk.java.net/browse/JDK-8207965: > > http://cr.openjdk.java.net/~phh/8207965/webrev.02/ > > I was looking for mechanism to skip tests when Tiered compilation is not available. > > Reviewed. > > Thanks, > Vladimir > > On 8/2/18 1:32 PM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8208655/webrev.00/index.html >>> 481 lines changed: 202 ins; 185 del; 94 mod; >> Hi all, >> could you please review this clean up of some hotspot tests? these tests are inapplicable in some of configurations, in some cases this can be expressed by @requiers, in others it can not be due to a dynamic nature. the latter cases are addressed by using new functionality added to jtreg 4.2 b13[1] -- throwing jtreg.SkippedException exception, which is known by jtreg and if jtreg catches this exception from a test, the test's will be marked as skipped. >> webrev: http://cr.openjdk.java.net/~iignatyev//8208655/webrev.00/index.html >> testing: hotspot tests >> JBS: https://bugs.openjdk.java.net/browse/JDK-8208655 >> Thanks, >> -- Igor >> [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7901596 From vladimir.kozlov at oracle.com Thu Aug 2 21:39:18 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 2 Aug 2018 14:39:18 -0700 Subject: RFR(M) : 8208655 : use JTreg skipped status in hotspot tests In-Reply-To: References: <8C91061B-9C60-4B38-AA0B-DD4D75B164C4@oracle.com> <2a55eac3-1511-4c7a-6d74-7b3779a1c239@oracle.com> Message-ID: Igor, Push your changes first. I want to use your new SkippedException. Thanks, Vladimir On 8/2/18 2:37 PM, Igor Ignatyev wrote: > Hi Vladimir, > > will you or Paul (or Xin?) take care about updating 8207965 patch? or do you want me to wait till it's integrated and update mine? > > -- Igor > >> On Aug 2, 2018, at 2:03 PM, Vladimir Kozlov wrote: >> >> Hmm, this look like overlap work done for https://bugs.openjdk.java.net/browse/JDK-8207965: >> >> http://cr.openjdk.java.net/~phh/8207965/webrev.02/ >> >> I was looking for mechanism to skip tests when Tiered compilation is not available. >> >> Reviewed. >> >> Thanks, >> Vladimir >> >> On 8/2/18 1:32 PM, Igor Ignatyev wrote: >>> http://cr.openjdk.java.net/~iignatyev//8208655/webrev.00/index.html >>>> 481 lines changed: 202 ins; 185 del; 94 mod; >>> Hi all, >>> could you please review this clean up of some hotspot tests? these tests are inapplicable in some of configurations, in some cases this can be expressed by @requiers, in others it can not be due to a dynamic nature. the latter cases are addressed by using new functionality added to jtreg 4.2 b13[1] -- throwing jtreg.SkippedException exception, which is known by jtreg and if jtreg catches this exception from a test, the test's will be marked as skipped. >>> webrev: http://cr.openjdk.java.net/~iignatyev//8208655/webrev.00/index.html >>> testing: hotspot tests >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8208655 >>> Thanks, >>> -- Igor >>> [1] https://bugs.openjdk.java.net/browse/CODETOOLS-7901596 > From david.holmes at oracle.com Thu Aug 2 22:45:45 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 3 Aug 2018 08:45:45 +1000 Subject: RFR (L): 8208671: Runtime, JFR, Serviceability changes to allow enabling -Wreorder In-Reply-To: References: <2497c761-d4aa-12a7-cc41-6ac342cbf8da@oracle.com> Message-ID: <21c5b7c4-2225-b1c5-5490-abd9e6daf216@oracle.com> Hi Thomas, On 2/08/2018 10:51 PM, Thomas Schatzl wrote: > Hi, > > On Thu, 2018-08-02 at 22:34 +1000, David Holmes wrote: >> Hi Thomas, >> >> On 2/08/2018 7:09 PM, Thomas Schatzl wrote: >>> Hi all, >>> >>> there have been several suggestions to try to fix the Hotspot >>> code to >>> allow us to enable -Wreorder in the Hotspot sources. >> >> Can you enlighten us on what -Wreorder is/does and so what changes >> you are making please. > > oh, sorry, my fault. -Wreorder is a compiler switch that checks that > the order of declaration of members in the initializer lists of > constructors match the order of declaration in the class. > > C++ always initializes members in the initializer list in the order of > the declaration in the class, it does not matter whether you specify it > differently in the initializer list or not. Wow! is that considered a "feature"??? I can't think why the compiler would not simply execute the code in the order you write it. :( If it's going to do that then the language should have made it an error to write the initializer list any other way. No wonder people just use constructor bodies in preference to initializer lists. > An often overseen error is that you accidentally use other members in > the initializer list that actually have not been initialized yet, > although you did the right ordering in the initializer list. > > > E.g. > > class X { > int b; > int a; > > X() : a(5), b(a) { > // actually the content of b is undefined here. As per standard > // your program will always initialize b before a. > } > } > > These are somewhat hard to detect errors that might go unnoticed for a > while otherwise. > > -Wreorder forces you to have b before a in above example in your > initializer list by giving a warning otherwise, which causes > compilation failure. Got it. Thanks. Please add this basic info to the bug report too. src/hotspot/share/classfile/dictionary.cpp This looks like leftover code you used to check the order: + + static bool _some_dictionary_needs_resizing; + bool _resizable; + bool _needs_resizing; + void check_if_needs_resize(); + + ClassLoaderData* _loader_data; // backpointer to owning loader + Dictionary::Dictionary(ClassLoaderData* loader_data, int table_size, bool resizable) Otherwise it all seems okay. In some cases it may have been cleaner to reorder the variable declarations in the class to have related variables adjacent - for example following _name by _name_len, rather than having them split by other variables - but that's just a stylistic thing. Thanks, David > Thanks, > Thomas > >> >> Thanks, >> David >> >>> This should make problems due to use-before-initialization much >>> more >>> obvious. >>> >>> This change fixes initializer lists for the runtime, jfr and >>> serviceability directories. >>> >>> There should be no change in code behavior. >>> >>> A later follow-up will enable -Wreorder in the makefiles. >>> >>> CR: >>> https://bugs.openjdk.java.net/browse/JDK-8208671 >>> Webrev: >>> http://cr.openjdk.java.net/~tschatzl/8208671/webrev/ >>> Testing: >>> hs-tier1-4,jdk-tier1-3 >>> >>> Thanks, >>> Thomas >>> > From igor.ignatyev at oracle.com Thu Aug 2 23:07:28 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 2 Aug 2018 16:07:28 -0700 Subject: RFR(XS) : 8208701 : Fix for JDK-8208655 causes test failures in CI tier1 Message-ID: <3BCC4248-4787-419A-9347-7389B21B81B7@oracle.com> http://cr.openjdk.java.net/~iignatyev//8208701/webrev.00/index.html > 4 lines changed: 0 ins; 0 del; 4 mod; Hi all, could you please review this small patch? I made a couple of typos, which were missed during testing (b/c it seems I was testing old version of the patch). JBS: https://bugs.openjdk.java.net/browse/JDK-8208701 webrev: http://cr.openjdk.java.net/~iignatyev//8208701/webrev.00/index.html testing: - grep -e vm.family -e requiers - changed tests locally Thanks, -- Igor From daniel.daugherty at oracle.com Thu Aug 2 23:11:27 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 2 Aug 2018 19:11:27 -0400 Subject: RFR(XS) : 8208701 : Fix for JDK-8208655 causes test failures in CI tier1 In-Reply-To: <3BCC4248-4787-419A-9347-7389B21B81B7@oracle.com> References: <3BCC4248-4787-419A-9347-7389B21B81B7@oracle.com> Message-ID: On 8/2/18 7:07 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8208701/webrev.00/index.html test/hotspot/jtreg/runtime/6819213/TestBootNativeLibraryPath.java test/hotspot/jtreg/runtime/CompressedOops/CompressedKlassPointerAndOops.java test/hotspot/jtreg/runtime/XCheckJniJsig/XCheckJSig.java test/hotspot/jtreg/runtime/memory/LargePages/TestLargePagesFlags.java ??? No comments. >> 4 lines changed: 0 ins; 0 del; 4 mod; > Hi all, > > could you please review this small patch? I made a couple of typos, which were missed during testing (b/c it seems I was testing old version of the patch). > > JBS: https://bugs.openjdk.java.net/browse/JDK-8208701 > webrev: http://cr.openjdk.java.net/~iignatyev//8208701/webrev.00/index.html > testing: > - grep -e vm.family -e requiers > - changed tests locally Thumbs up! Thanks for doing the greps and the local testing. Dan > > Thanks, > -- Igor > From david.holmes at oracle.com Thu Aug 2 23:11:53 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 3 Aug 2018 09:11:53 +1000 Subject: RFR(XS) : 8208701 : Fix for JDK-8208655 causes test failures in CI tier1 In-Reply-To: <3BCC4248-4787-419A-9347-7389B21B81B7@oracle.com> References: <3BCC4248-4787-419A-9347-7389B21B81B7@oracle.com> Message-ID: Looks good - and trivial. Ship it! Thanks, David On 3/08/2018 9:07 AM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8208701/webrev.00/index.html >> 4 lines changed: 0 ins; 0 del; 4 mod; > > Hi all, > > could you please review this small patch? I made a couple of typos, which were missed during testing (b/c it seems I was testing old version of the patch). > > JBS: https://bugs.openjdk.java.net/browse/JDK-8208701 > webrev: http://cr.openjdk.java.net/~iignatyev//8208701/webrev.00/index.html > testing: > - grep -e vm.family -e requiers > - changed tests locally > > Thanks, > -- Igor > From kim.barrett at oracle.com Thu Aug 2 23:38:29 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 2 Aug 2018 19:38:29 -0400 Subject: RFR (L): 8208671: Runtime, JFR, Serviceability changes to allow enabling -Wreorder In-Reply-To: <21c5b7c4-2225-b1c5-5490-abd9e6daf216@oracle.com> References: <2497c761-d4aa-12a7-cc41-6ac342cbf8da@oracle.com> <21c5b7c4-2225-b1c5-5490-abd9e6daf216@oracle.com> Message-ID: > On Aug 2, 2018, at 6:45 PM, David Holmes wrote: > > Hi Thomas, > > On 2/08/2018 10:51 PM, Thomas Schatzl wrote: >> Hi, >> On Thu, 2018-08-02 at 22:34 +1000, David Holmes wrote: >>> Hi Thomas, >>> >>> On 2/08/2018 7:09 PM, Thomas Schatzl wrote: >>>> Hi all, >>>> >>>> there have been several suggestions to try to fix the Hotspot >>>> code to >>>> allow us to enable -Wreorder in the Hotspot sources. >>> >>> Can you enlighten us on what -Wreorder is/does and so what changes >>> you are making please. >> oh, sorry, my fault. -Wreorder is a compiler switch that checks that >> the order of declaration of members in the initializer lists of >> constructors match the order of declaration in the class. >> C++ always initializes members in the initializer list in the order of >> the declaration in the class, it does not matter whether you specify it >> differently in the initializer list or not. > > Wow! is that considered a "feature"??? I can't think why the compiler would not simply execute the code in the order you write it. :( If it's going to do that then the language should have made it an error to write the initializer list any other way. No wonder people just use constructor bodies in preference to initializer lists. There needs to be a well-defined order for initialization of members (and base classes) that aren't mentioned in the initializer list. Declaration order is a reasonable choice for those not mentioned in the initializer list. Also, the destruction order is in reverse declaration order, as there's nothing corresponding to the initializer list in a destructor, and some order needs to be chosen. This goes all the way back to the very beginnings of C++. For example, C++ ARM p292 says about the initialization order "The declaration order is used to ensure that sub-objects and members are destroyed in reverse order of initialization." Using order in the initialization list rather than declaration order would likely require some complicated rules and complex implementation for things like an exception being thrown during the execution of one of the initializers. I'm inclined to agree it should have been an error to have out-of-order initializers; I have no idea why that wasn't done. -Wreorder + -Wfatal makes it an error for us. But we first need to fix lots of code that has out-of-order initializers. And there are lots of reasons to still prefer initializer lists to in-body assignment. [Thomas - This isn't a review. If I have time I?ll look at some of these changes, but don?t wait for me if you have other reviewers. And thank you for doing this; I?ve been wanting to get this done for a while.] From david.holmes at oracle.com Fri Aug 3 00:20:14 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 3 Aug 2018 10:20:14 +1000 Subject: RFR (XXS): 8208672: Enable -Wreorder in make files In-Reply-To: References: Message-ID: Hi Thomas, On 2/08/2018 7:14 PM, Thomas Schatzl wrote: > Hi all, > > there have been several suggestions to try to fix the Hotspot code to > allow us to enable -Wreorder in the Hotspot sources. > This should make problems due to use-before-initialization much more > obvious. > > This change enables -Wreorder for gcc and clang. For Windows (VS2017+) see: https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings/c5038 Otherwise change seems okay. Thanks, David > Of course it needs all previous RFRs sent to hotspot-dev to be checked > in first to result in successful compilation of the code. > > Also checked by looking at the generated spec.gmk file which seems to > result in the flag in the I think "right" flag, but I am not very > knowledgable in this area. > > build-dev is CC'ed. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8208672 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8208672/webrev/ > Testing: > hs-tier1-4,jdk-tier1-3 > > Thanks, > Thomas > From daniel.daugherty at oracle.com Fri Aug 3 02:06:17 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 2 Aug 2018 22:06:17 -0400 Subject: RFR(XXXS): 8208706 compiler/tiered/ConstantGettersTransitionsTest.java fails to compile Message-ID: <43d64dac-0f9f-ed4e-3aeb-efb889c7939b@oracle.com> Greetings, One more tweak needed to the fix for: ??? JDK-8208655 use JTreg skipped status in hotspot tests ??? https://bugs.openjdk.java.net/browse/JDK-8208655 I am looking for a single (R)eviewer for this trivial fix. This one is tracked by the following: ??? JDK-8208706 compiler/tiered/ConstantGettersTransitionsTest.java fails to compile ??? https://bugs.openjdk.java.net/browse/JDK-8208706 The fix is simple: $ hg diff diff -r 531de4cbaa4f test/hotspot/jtreg/compiler/tiered/ConstantGettersTransitionsTest.java --- a/test/hotspot/jtreg/compiler/tiered/ConstantGettersTransitionsTest.java Thu Aug 02 16:16:02 2018 -0700 +++ b/test/hotspot/jtreg/compiler/tiered/ConstantGettersTransitionsTest.java Thu Aug 02 22:02:04 2018 -0400 @@ -40,6 +40,7 @@ ?package compiler.tiered; ?import compiler.whitebox.CompilerWhiteBoxTest; +import jtreg.SkippedException; ?import java.lang.reflect.Executable; ?import java.util.concurrent.Callable; I verified that the test failed to compile via: ??? make CONF=linux-x86_64-normal-server-release run-test TEST=open/test/hotspot/jtreg/compiler/tiered/ConstantGettersTransitionsTest.java on my Linux server, applied the change and verified that the test now compiles and passes. Thanks, in advance, for any questions, comments or suggestions. Dan From david.holmes at oracle.com Fri Aug 3 02:09:20 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 3 Aug 2018 12:09:20 +1000 Subject: RFR(XXXS): 8208706 compiler/tiered/ConstantGettersTransitionsTest.java fails to compile In-Reply-To: <43d64dac-0f9f-ed4e-3aeb-efb889c7939b@oracle.com> References: <43d64dac-0f9f-ed4e-3aeb-efb889c7939b@oracle.com> Message-ID: <833ee610-a919-f3e7-f184-0a844fa2da0b@oracle.com> Reviewed. Thanks, David On 3/08/2018 12:06 PM, Daniel D. Daugherty wrote: > Greetings, > > One more tweak needed to the fix for: > > ??? JDK-8208655 use JTreg skipped status in hotspot tests > ??? https://bugs.openjdk.java.net/browse/JDK-8208655 > > I am looking for a single (R)eviewer for this trivial fix. > > This one is tracked by the following: > > ??? JDK-8208706 compiler/tiered/ConstantGettersTransitionsTest.java > fails to compile > ??? https://bugs.openjdk.java.net/browse/JDK-8208706 > > The fix is simple: > > $ hg diff > diff -r 531de4cbaa4f > test/hotspot/jtreg/compiler/tiered/ConstantGettersTransitionsTest.java > --- > a/test/hotspot/jtreg/compiler/tiered/ConstantGettersTransitionsTest.java > Thu Aug 02 16:16:02 2018 -0700 > +++ > b/test/hotspot/jtreg/compiler/tiered/ConstantGettersTransitionsTest.java > Thu Aug 02 22:02:04 2018 -0400 > @@ -40,6 +40,7 @@ > ?package compiler.tiered; > > ?import compiler.whitebox.CompilerWhiteBoxTest; > +import jtreg.SkippedException; > > ?import java.lang.reflect.Executable; > ?import java.util.concurrent.Callable; > > > I verified that the test failed to compile via: > > ??? make CONF=linux-x86_64-normal-server-release run-test > TEST=open/test/hotspot/jtreg/compiler/tiered/ConstantGettersTransitionsTest.java > > > on my Linux server, applied the change and verified that > the test now compiles and passes. > > Thanks, in advance, for any questions, comments or suggestions. > > Dan > From daniel.daugherty at oracle.com Fri Aug 3 02:09:57 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 2 Aug 2018 22:09:57 -0400 Subject: RFR(XXXS): 8208706 compiler/tiered/ConstantGettersTransitionsTest.java fails to compile In-Reply-To: <833ee610-a919-f3e7-f184-0a844fa2da0b@oracle.com> References: <43d64dac-0f9f-ed4e-3aeb-efb889c7939b@oracle.com> <833ee610-a919-f3e7-f184-0a844fa2da0b@oracle.com> Message-ID: Thanks! Dan On 8/2/18 10:09 PM, David Holmes wrote: > Reviewed. > > Thanks, > David > > On 3/08/2018 12:06 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> One more tweak needed to the fix for: >> >> ???? JDK-8208655 use JTreg skipped status in hotspot tests >> ???? https://bugs.openjdk.java.net/browse/JDK-8208655 >> >> I am looking for a single (R)eviewer for this trivial fix. >> >> This one is tracked by the following: >> >> ???? JDK-8208706 compiler/tiered/ConstantGettersTransitionsTest.java >> fails to compile >> ???? https://bugs.openjdk.java.net/browse/JDK-8208706 >> >> The fix is simple: >> >> $ hg diff >> diff -r 531de4cbaa4f >> test/hotspot/jtreg/compiler/tiered/ConstantGettersTransitionsTest.java >> --- >> a/test/hotspot/jtreg/compiler/tiered/ConstantGettersTransitionsTest.java >> Thu Aug 02 16:16:02 2018 -0700 >> +++ >> b/test/hotspot/jtreg/compiler/tiered/ConstantGettersTransitionsTest.java >> Thu Aug 02 22:02:04 2018 -0400 >> @@ -40,6 +40,7 @@ >> ??package compiler.tiered; >> >> ??import compiler.whitebox.CompilerWhiteBoxTest; >> +import jtreg.SkippedException; >> >> ??import java.lang.reflect.Executable; >> ??import java.util.concurrent.Callable; >> >> >> I verified that the test failed to compile via: >> >> ???? make CONF=linux-x86_64-normal-server-release run-test >> TEST=open/test/hotspot/jtreg/compiler/tiered/ConstantGettersTransitionsTest.java >> >> >> on my Linux server, applied the change and verified that >> the test now compiles and passes. >> >> Thanks, in advance, for any questions, comments or suggestions. >> >> Dan >> From thomas.schatzl at oracle.com Fri Aug 3 08:55:34 2018 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 03 Aug 2018 10:55:34 +0200 Subject: RFR (L): 8208671: Runtime, JFR, Serviceability changes to allow enabling -Wreorder In-Reply-To: <833bd65a-ac8f-2da9-3a8a-ced57b68ff66@oracle.com> References: <833bd65a-ac8f-2da9-3a8a-ced57b68ff66@oracle.com> Message-ID: Hi Harold, thanks for your review. On Thu, 2018-08-02 at 13:18 -0400, Harold David Seigel wrote: > Hi Thomas, > > The change looks good! Just a few comments. > > In vm_operations.hpp, there an added call to _setter() in > VM_FindDeadlocks(outputStream* st). Is that call needed to > initialize > _setter() properly? > > - VM_FindDeadlocks(bool concurrent_locks) : > _concurrent_locks(concurrent_locks), _out(NULL), > _deadlocks(NULL), > _setter() {}; > - VM_FindDeadlocks(outputStream* st) : _concurrent_locks(true), > _out(st), _deadlocks(NULL) {}; > + VM_FindDeadlocks(bool concurrent_locks) : > _concurrent_locks(concurrent_locks), _deadlocks(NULL), > _out(NULL), > _setter() {}; > + VM_FindDeadlocks(outputStream* st) : _concurrent_locks(true), > _deadlocks(NULL), _out(st), _setter() {}; > > In elfFuncDescTable.cpp, there an added call to _status(), is that > call > needed to initialize _status properly? > > - _file(file), _index(index), _section(file, shdr) { > + _section(file, shdr), _file(file), _index(index), _status() { fixed (including David's findings) in http://cr.openjdk.java.net/~tschatzl/8208671/webrev.1 (full) http://cr.openjdk.java.net/~tschatzl/8208671/webrev.0_to_1 (diff) Thanks, Thomas From thomas.schatzl at oracle.com Fri Aug 3 09:00:35 2018 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 03 Aug 2018 11:00:35 +0200 Subject: RFR (L): 8208671: Runtime, JFR, Serviceability changes to allow enabling -Wreorder In-Reply-To: <21c5b7c4-2225-b1c5-5490-abd9e6daf216@oracle.com> References: <2497c761-d4aa-12a7-cc41-6ac342cbf8da@oracle.com> <21c5b7c4-2225-b1c5-5490-abd9e6daf216@oracle.com> Message-ID: Hi David, On Fri, 2018-08-03 at 08:45 +1000, David Holmes wrote: > Hi Thomas, > > On 2/08/2018 10:51 PM, Thomas Schatzl wrote: > > Hi, > > > > On Thu, 2018-08-02 at 22:34 +1000, David Holmes wrote: > > > Hi Thomas, > > > > > > On 2/08/2018 7:09 PM, Thomas Schatzl wrote: > > > > Hi all, > > > > > > > > there have been several suggestions to try to fix the > > > > Hotspot code to allow us to enable -Wreorder in the Hotspot > > > > sources. > > > > > > Can you enlighten us on what -Wreorder is/does and so what > > > changes you are making please. > > > > oh, sorry, my fault. -Wreorder is a compiler switch that checks > > that the order of declaration of members in the initializer lists > > of constructors match the order of declaration in the class. > > > > C++ always initializes members in the initializer list in the order > > of the declaration in the class, it does not matter whether you > > specify it differently in the initializer list or not. > [...] > > -Wreorder forces you to have b before a in above example in your > > initializer list by giving a warning otherwise, which causes > > compilation failure. > > Got it. Thanks. Please add this basic info to the bug report too. Added. > > src/hotspot/share/classfile/dictionary.cpp > > This looks like leftover code you used to check the order: > > + > + static bool _some_dictionary_needs_resizing; > + bool _resizable; > + bool _needs_resizing; > + void check_if_needs_resize(); > + > + ClassLoaderData* _loader_data; // backpointer to owning loader > + > Dictionary::Dictionary(ClassLoaderData* loader_data, int > table_size, > bool resizable) > Thanks for catching this. Fixed in http://cr.openjdk.java.net/~tschatzl/8208671/webrev.1 (full) http://cr.openjdk.java.net/~tschatzl/8208671/webrev.0_to_1 (diff) > > Otherwise it all seems okay. In some cases it may have been cleaner > to reorder the variable declarations in the class to have related > variables adjacent - for example following _name by _name_len, rather > than having them split by other variables - but that's just a > stylistic thing. I think this should be done by the respective maintainers as cleanups as preferred - it is beyond my knowledge to know the best order for every class there is in hotspot, also it would have complicated this change a lot :) Thanks, Thomas From tobias.hartmann at oracle.com Fri Aug 3 09:59:13 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 3 Aug 2018 11:59:13 +0200 Subject: JEP: https://bugs.openjdk.java.net/browse/JDK-8203832 In-Reply-To: <96806b1f-6fce-83e0-0ffb-02f7a19e8301@oracle.com> References: <0ca282db-5b4f-607d-512a-a2183dbd4b73@oracle.com> <96806b1f-6fce-83e0-0ffb-02f7a19e8301@oracle.com> Message-ID: <0e05aeee-6d80-c8a8-bece-3533fa561110@oracle.com> Hi Vladimir, On 02.08.2018 22:55, Vladimir Kozlov wrote: > Tobias, can you review JEP and add new comments, questions if you have them. Looks good to me. I've fixed some typos in the description (I think some of the wording should still be improved). Best regards, Tobias From harold.seigel at oracle.com Fri Aug 3 12:03:37 2018 From: harold.seigel at oracle.com (Harold David Seigel) Date: Fri, 3 Aug 2018 08:03:37 -0400 Subject: RFR (L): 8208671: Runtime, JFR, Serviceability changes to allow enabling -Wreorder In-Reply-To: References: <833bd65a-ac8f-2da9-3a8a-ced57b68ff66@oracle.com> Message-ID: Hi Thomas, Thanks for the new webrev. The original vm_operations.hpp had a call to _setter() for VM_FindDeadlocks(bool concurrent_locks) that got? removed.? (The first VM_FindDeadlocks() had a call to _setter().? The second VM_FindDeadlocks() did not.) - VM_FindDeadlocks(bool concurrent_locks) : _concurrent_locks(concurrent_locks), _out(NULL), _deadlocks(NULL), _setter() {}; - VM_FindDeadlocks(outputStream* st) : _concurrent_locks(true), _out(st), _deadlocks(NULL) {}; + VM_FindDeadlocks(bool concurrent_locks) : _concurrent_locks(concurrent_locks), _deadlocks(NULL), _out(NULL) {}; + VM_FindDeadlocks(outputStream* st) : _concurrent_locks(true), _deadlocks(NULL), _out(st) {}; Also, in elfFile.cpp there is an added call to _elfHdr(): - _string_tables(NULL), _symbol_tables(NULL), _funcDesc_table(NULL), - _next(NULL), _status(NullDecoder::no_error), - _shdr_string_table(NULL), _file(NULL), _filepath(NULL) { + _next(NULL), _filepath(NULL), _file(NULL), _elfHdr(), + _symbol_tables(NULL), _string_tables(NULL), _shdr_string_table(NULL), _funcDesc_table(NULL), + _status(NullDecoder::no_error) { I don't need to see a new webrev. Thanks, Harold On 8/3/2018 4:55 AM, Thomas Schatzl wrote: > Hi Harold, > > thanks for your review. > > On Thu, 2018-08-02 at 13:18 -0400, Harold David Seigel wrote: >> Hi Thomas, >> >> The change looks good! Just a few comments. >> >> In vm_operations.hpp, there an added call to _setter() in >> VM_FindDeadlocks(outputStream* st). Is that call needed to >> initialize >> _setter() properly? >> >> - VM_FindDeadlocks(bool concurrent_locks) : >> _concurrent_locks(concurrent_locks), _out(NULL), >> _deadlocks(NULL), >> _setter() {}; >> - VM_FindDeadlocks(outputStream* st) : _concurrent_locks(true), >> _out(st), _deadlocks(NULL) {}; >> + VM_FindDeadlocks(bool concurrent_locks) : >> _concurrent_locks(concurrent_locks), _deadlocks(NULL), >> _out(NULL), >> _setter() {}; >> + VM_FindDeadlocks(outputStream* st) : _concurrent_locks(true), >> _deadlocks(NULL), _out(st), _setter() {}; >> >> In elfFuncDescTable.cpp, there an added call to _status(), is that >> call >> needed to initialize _status properly? >> >> - _file(file), _index(index), _section(file, shdr) { >> + _section(file, shdr), _file(file), _index(index), _status() { > fixed (including David's findings) in > http://cr.openjdk.java.net/~tschatzl/8208671/webrev.1 (full) > http://cr.openjdk.java.net/~tschatzl/8208671/webrev.0_to_1 (diff) > > Thanks, > Thomas > From thomas.schatzl at oracle.com Fri Aug 3 13:30:25 2018 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 03 Aug 2018 15:30:25 +0200 Subject: RFR (L): 8208671: Runtime, JFR, Serviceability changes to allow enabling -Wreorder In-Reply-To: References: <833bd65a-ac8f-2da9-3a8a-ced57b68ff66@oracle.com> Message-ID: Hi Harold, On Fri, 2018-08-03 at 08:03 -0400, Harold David Seigel wrote: > Hi Thomas, > Thanks for the new webrev. > The original vm_operations.hpp had a call to _setter() for > VM_FindDeadlocks(bool concurrent_locks) that got removed. (The > first VM_FindDeadlocks() had a call to _setter(). The second > VM_FindDeadlocks() did not.) > > - VM_FindDeadlocks(bool concurrent_locks) > > : _concurrent_locks(concurrent_locks), _out(NULL), > > _deadlocks(NULL), _setter() {}; > > - VM_FindDeadlocks(outputStream* st) : _concurrent_locks(true), > > _out(st), _deadlocks(NULL) {}; > > + VM_FindDeadlocks(bool concurrent_locks) > > : _concurrent_locks(concurrent_locks), _deadlocks(NULL), > > _out(NULL) {}; > > + VM_FindDeadlocks(outputStream* st) : _concurrent_locks(true), > > _deadlocks(NULL), _out(st) {}; So the original code had the call to the (default) initializer and the other did not... I changed it to as before. > > Also, in elfFile.cpp there is an added call to _elfHdr(): > > - _string_tables(NULL), _symbol_tables(NULL), > > _funcDesc_table(NULL), > > - _next(NULL), _status(NullDecoder::no_error), > > - _shdr_string_table(NULL), _file(NULL), _filepath(NULL) { > > + _next(NULL), _filepath(NULL), _file(NULL), _elfHdr(), > > + _symbol_tables(NULL), _string_tables(NULL), > > _shdr_string_table(NULL), _funcDesc_table(NULL), > > + _status(NullDecoder::no_error) { > I don't need to see a new webrev. Removed. I updated the .0_to_1 and .1 webrevs. Thanks, Thomas > > Thanks, Harold > On 8/3/2018 4:55 AM, Thomas Schatzl wrote: > > Hi Harold, > > > > thanks for your review. > > > > On Thu, 2018-08-02 at 13:18 -0400, Harold David Seigel wrote: > > > Hi Thomas, > > > > > > The change looks good! Just a few comments. > > > > > > In vm_operations.hpp, there an added call to _setter() in > > > VM_FindDeadlocks(outputStream* st). Is that call needed to > > > initialize > > > _setter() properly? > > > > > > - VM_FindDeadlocks(bool concurrent_locks) : > > > _concurrent_locks(concurrent_locks), _out(NULL), > > > _deadlocks(NULL), > > > _setter() {}; > > > - VM_FindDeadlocks(outputStream* st) : > > > _concurrent_locks(true), > > > _out(st), _deadlocks(NULL) {}; > > > + VM_FindDeadlocks(bool concurrent_locks) : > > > _concurrent_locks(concurrent_locks), _deadlocks(NULL), > > > _out(NULL), > > > _setter() {}; > > > + VM_FindDeadlocks(outputStream* st) : > > > _concurrent_locks(true), > > > _deadlocks(NULL), _out(st), _setter() {}; > > > > > > In elfFuncDescTable.cpp, there an added call to _status(), is > > > that > > > call > > > needed to initialize _status properly? > > > > > > - _file(file), _index(index), _section(file, shdr) { > > > + _section(file, shdr), _file(file), _index(index), _status() > > > { > > > > fixed (including David's findings) in > > http://cr.openjdk.java.net/~tschatzl/8208671/webrev.1 (full) > > http://cr.openjdk.java.net/~tschatzl/8208671/webrev.0_to_1 (diff) > > > > Thanks, > > Thomas > > > From harold.seigel at oracle.com Fri Aug 3 13:33:47 2018 From: harold.seigel at oracle.com (Harold David Seigel) Date: Fri, 3 Aug 2018 09:33:47 -0400 Subject: RFR (L): 8208671: Runtime, JFR, Serviceability changes to allow enabling -Wreorder In-Reply-To: References: <833bd65a-ac8f-2da9-3a8a-ced57b68ff66@oracle.com> Message-ID: <26591fe5-f6fd-b9bb-2e40-c62925c1f85a@oracle.com> Looks good! Thanks, Harold On 8/3/2018 9:30 AM, Thomas Schatzl wrote: > Hi Harold, > > On Fri, 2018-08-03 at 08:03 -0400, Harold David Seigel wrote: >> Hi Thomas, >> Thanks for the new webrev. >> The original vm_operations.hpp had a call to _setter() for >> VM_FindDeadlocks(bool concurrent_locks) that got removed. (The >> first VM_FindDeadlocks() had a call to _setter(). The second >> VM_FindDeadlocks() did not.) >>> - VM_FindDeadlocks(bool concurrent_locks) >>> : _concurrent_locks(concurrent_locks), _out(NULL), >>> _deadlocks(NULL), _setter() {}; >>> - VM_FindDeadlocks(outputStream* st) : _concurrent_locks(true), >>> _out(st), _deadlocks(NULL) {}; >>> + VM_FindDeadlocks(bool concurrent_locks) >>> : _concurrent_locks(concurrent_locks), _deadlocks(NULL), >>> _out(NULL) {}; >>> + VM_FindDeadlocks(outputStream* st) : _concurrent_locks(true), >>> _deadlocks(NULL), _out(st) {}; > So the original code had the call to the (default) initializer and the > other did not... I changed it to as before. > >> Also, in elfFile.cpp there is an added call to _elfHdr(): >>> - _string_tables(NULL), _symbol_tables(NULL), >>> _funcDesc_table(NULL), >>> - _next(NULL), _status(NullDecoder::no_error), >>> - _shdr_string_table(NULL), _file(NULL), _filepath(NULL) { >>> + _next(NULL), _filepath(NULL), _file(NULL), _elfHdr(), >>> + _symbol_tables(NULL), _string_tables(NULL), >>> _shdr_string_table(NULL), _funcDesc_table(NULL), >>> + _status(NullDecoder::no_error) { >> I don't need to see a new webrev. > Removed. I updated the .0_to_1 and .1 webrevs. > > Thanks, > Thomas > >> Thanks, Harold >> On 8/3/2018 4:55 AM, Thomas Schatzl wrote: >>> Hi Harold, >>> >>> thanks for your review. >>> >>> On Thu, 2018-08-02 at 13:18 -0400, Harold David Seigel wrote: >>>> Hi Thomas, >>>> >>>> The change looks good! Just a few comments. >>>> >>>> In vm_operations.hpp, there an added call to _setter() in >>>> VM_FindDeadlocks(outputStream* st). Is that call needed to >>>> initialize >>>> _setter() properly? >>>> >>>> - VM_FindDeadlocks(bool concurrent_locks) : >>>> _concurrent_locks(concurrent_locks), _out(NULL), >>>> _deadlocks(NULL), >>>> _setter() {}; >>>> - VM_FindDeadlocks(outputStream* st) : >>>> _concurrent_locks(true), >>>> _out(st), _deadlocks(NULL) {}; >>>> + VM_FindDeadlocks(bool concurrent_locks) : >>>> _concurrent_locks(concurrent_locks), _deadlocks(NULL), >>>> _out(NULL), >>>> _setter() {}; >>>> + VM_FindDeadlocks(outputStream* st) : >>>> _concurrent_locks(true), >>>> _deadlocks(NULL), _out(st), _setter() {}; >>>> >>>> In elfFuncDescTable.cpp, there an added call to _status(), is >>>> that >>>> call >>>> needed to initialize _status properly? >>>> >>>> - _file(file), _index(index), _section(file, shdr) { >>>> + _section(file, shdr), _file(file), _index(index), _status() >>>> { >>> fixed (including David's findings) in >>> http://cr.openjdk.java.net/~tschatzl/8208671/webrev.1 (full) >>> http://cr.openjdk.java.net/~tschatzl/8208671/webrev.0_to_1 (diff) >>> >>> Thanks, >>> Thomas >>> >> From erik.osterlund at oracle.com Fri Aug 3 16:01:51 2018 From: erik.osterlund at oracle.com (=?utf-8?Q?Erik_=C3=96sterlund?=) Date: Fri, 3 Aug 2018 18:01:51 +0200 Subject: RFR: 8208601: Introduce native oop barriers in C2 for OopHandle In-Reply-To: <349c262f-3fa3-db22-dd65-87a31e9314fc@oracle.com> References: <5B6196CA.7080201@oracle.com> <51231d8e-e2ed-3d95-2cb2-c8cb61cbe512@oracle.com> <1C90F3B1-AB57-44AF-9030-26238CD42B1B@oracle.com> <349c262f-3fa3-db22-dd65-87a31e9314fc@oracle.com> Message-ID: <3BAEF861-3F74-4D47-AE9A-39C020CC445B@oracle.com> Hi Vladimir, Thanks for reviewing. Full webrev: http://cr.openjdk.java.net/~eosterlund/8208601/webrev.02/ Incremental: http://cr.openjdk.java.net/~eosterlund/8208601/webrev.01_02/ > On 02 Aug 2018, at 19:03, Vladimir Kozlov wrote: > > Thanks Erik > > Wow! I got 18 copies of your response ;) Oops, sorry about that. My mail client said it didn?t send - so I pressed send a few times more. Looks like they were all sent in the end. >_< > On 8/2/18 2:39 AM, Erik ?sterlund wrote: >> Hi Vladimir, >> Thank you for reviewing. >> Incremental: >> http://cr.openjdk.java.net/~eosterlund/8208601/webrev.00_01/ >> Full: >> http://cr.openjdk.java.net/~eosterlund/8208601/webrev.01/ >>> On 01 Aug 2018, at 20:03, Vladimir Kozlov wrote: >>> >>> Hi, Erik >>> >>> 1. is_gc_barrier_node(b) is virtual so even if it return 'false' I am not sure C++ will collapse new search loops in phaseX.cpp and checks in other cases. Can we use some static check to allow C++ collapse that code in case there is no load barriers? >> I see your point. I introduced a has_load_barrier() function in BarrierSetC2 that I can check outside of the loop, to make the extra load barrier search conditional. Was it something like this you had in mind? > > Yes, thanks. > >>> 2. Can you explain Phi case more. I would like to see an assert which verify cush shape of code to avoid cases when Phi come from loop, for example. >> Sure. The load barrier has different shapes before and after macro expansion. Before macro expansion it is just a LoadBarrierNode. After expanding the barrier, the pseudo code for the inflated barrier looks something like this: value = is_bad(some_oop) ? slowpath_load : some_oop. The value in that pseudo code is the particular phi I am matching. What is unique about this phi (corresponding to the barrier region node depicting the good_or_null vs bad control flows), compared to an arbitrary phi, is that in(1) is the slowpath_load (LoadBarrierSlowPathRegNode) taken if the oop is bad. A phi in e.g. a loop would point to another phi with this property inside e.g. the loop body, never directly to a slowpath_load (LoadBarrierSlowPathRegNode). > > Thank you for explanation. My confusion come that you phi->in(2) is points to a value on one of branches which is inside original macro node. But looking on your pseud code it is some_oop which is what you want. :) > One suggesting I would give is to add comments to each of 3 cases in step_over_gc_barrier() to be clear what function is looking for. Fixed. > Also for first case (Proj node) it would be nice to have assert to check node you expect this Proj is connected to. I added an assert checking that we only find oop projs of the load barrier (before getting macro expanded). I guess finding an expanded load barrier through a proj should be fine as well. But I haven?t found any in my testing, so I thought having this stronger assert is good so we get the chance to reflect on that if surprising things happen, even though it is possibly harmless. Thanks, /Erik > >> Note that there is a basic and optimized macro expansion of the load barrier. The matching I use catches the optimized variant only (which uses the LoadBarrierSlowPathRegNode for the slow path). The basic barrier expansion is only used for atomic xchg (because self-healing the pointer would be an error in that path). >> In the new version, I added some assertions right where load barriers are produced and expanded, to assert that it matches and can be stepped over reliably. That way, if we change the barriers, the matching code will not silently stop working. To make these asserts work, I added support for matching barriers on weak barriers as well, that use LoadBarrierWeakSlowPathRegNode. While that isn?t needed for my purposes for loading the mirror, it is better to be more complete. Now you can see at the assertions in ZBarrierSetC2::expand_loadbarrier_optimized the exact phi that I am matching. >> I have still intentionally left matching of the ?basic? load barrier used by atomic xchg for another day, as nobody has any need for that yet, and it is trickier to match. >> BTW, it would be nice if in C2 the Node class had a Node* _expanded_from member that could track the node that macro expanded a node, and remember that through cloning of nodes, so that things like this would reduce to simply node->expanded_from()->is_LoadBarrier(), rather than trying to recognize the shape of the expanded barriers. Perhaps that would be useful for others? I did try something like that originally (but tracked with a hashtable), but unfortunately ran into trouble with cloned nodes not retaining the information, and made the decision to go for the shape recognition solution instead. But perhaps it could be generally useful for other shape recognition problems as well? But that might be outside the scope of this RFE. > > Yes, it is different and not hard to do. Nobody asked it before. > > Thanks, > Vladimir > >> Thanks, >> /Erik >>> Thanks, >>> Vladimir >>> >>> On 8/1/18 4:17 AM, Erik ?sterlund wrote: >>>> Hi, >>>> There is currently no way of doing IN_NATIVE accesses in C2 using its access API. These are required to properly access OopHandle, used to access the Java class mirrors (because they will now start requiring load barriers). In order to support (concurrent) class unloading in ZGC, this support must be added. >>>> In this patch, I add an access_load API for loading IN_NATIVE oops, and use it to load class mirrors (which is logically an OopHandle::resolve, which happened to have been an indirect load before as nobody had load barriers on it). In the various code recognizing the shape of a mirror load to optimize the code, I have added a check if a node is a GC barrier and to then step over it in order to match the mirror load. >>>> In order to recognize and step over the load barriers in ZGC properly, I added support for recognizing the barrier shapes not just before macro expansion (LoadBarrierNode), but also after macro expansion (as required by the matching code), which involves checking for phi nodes with with LoadBarrierSlowRegNode phi->in(1), and then stepping over to phi->in(2), as well as recognizing projections to such shapes. LoadBarrierSlowRegNode is used in all barrier expansions except for atomic xchg, but that is fine as we don't use that on class mirrors. >>>> I have checked that the shapes are recognized and that no regressions are introduced with these changes through a bunch of benchmarks in gc-test-suite. >>>> Webrev: >>>> http://cr.openjdk.java.net/~eosterlund/8208601/webrev.00/ Bug URL: >>>> https://bugs.openjdk.java.net/browse/JDK-8208601 Thanks, >>>> /Erik >>>> Open Tracking From vladimir.kozlov at oracle.com Fri Aug 3 17:54:08 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 3 Aug 2018 10:54:08 -0700 Subject: JEP: https://bugs.openjdk.java.net/browse/JDK-8203832 In-Reply-To: <0e05aeee-6d80-c8a8-bece-3533fa561110@oracle.com> References: <0ca282db-5b4f-607d-512a-a2183dbd4b73@oracle.com> <96806b1f-6fce-83e0-0ffb-02f7a19e8301@oracle.com> <0e05aeee-6d80-c8a8-bece-3533fa561110@oracle.com> Message-ID: Thank you very much, Tobias Vladimir On 8/3/18 2:59 AM, Tobias Hartmann wrote: > Hi Vladimir, > > On 02.08.2018 22:55, Vladimir Kozlov wrote: >> Tobias, can you review JEP and add new comments, questions if you have them. > > Looks good to me. I've fixed some typos in the description (I think some of the wording should still > be improved). > > Best regards, > Tobias > From vladimir.kozlov at oracle.com Fri Aug 3 17:58:04 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 3 Aug 2018 10:58:04 -0700 Subject: RFR: 8208601: Introduce native oop barriers in C2 for OopHandle In-Reply-To: <3BAEF861-3F74-4D47-AE9A-39C020CC445B@oracle.com> References: <5B6196CA.7080201@oracle.com> <51231d8e-e2ed-3d95-2cb2-c8cb61cbe512@oracle.com> <1C90F3B1-AB57-44AF-9030-26238CD42B1B@oracle.com> <349c262f-3fa3-db22-dd65-87a31e9314fc@oracle.com> <3BAEF861-3F74-4D47-AE9A-39C020CC445B@oracle.com> Message-ID: This version looks good to me. I think you need second review. Thanks, Vladimir On 8/3/18 9:01 AM, Erik ?sterlund wrote: > Hi Vladimir, > > Thanks for reviewing. > > Full webrev: > http://cr.openjdk.java.net/~eosterlund/8208601/webrev.02/ > > Incremental: > http://cr.openjdk.java.net/~eosterlund/8208601/webrev.01_02/ > >> On 02 Aug 2018, at 19:03, Vladimir Kozlov wrote: >> >> Thanks Erik >> >> Wow! I got 18 copies of your response ;) > > Oops, sorry about that. My mail client said it didn?t send - so I pressed send a few times more. Looks like they were all sent in the end. >_< > >> On 8/2/18 2:39 AM, Erik ?sterlund wrote: >>> Hi Vladimir, >>> Thank you for reviewing. >>> Incremental: >>> http://cr.openjdk.java.net/~eosterlund/8208601/webrev.00_01/ >>> Full: >>> http://cr.openjdk.java.net/~eosterlund/8208601/webrev.01/ >>>> On 01 Aug 2018, at 20:03, Vladimir Kozlov wrote: >>>> >>>> Hi, Erik >>>> >>>> 1. is_gc_barrier_node(b) is virtual so even if it return 'false' I am not sure C++ will collapse new search loops in phaseX.cpp and checks in other cases. Can we use some static check to allow C++ collapse that code in case there is no load barriers? >>> I see your point. I introduced a has_load_barrier() function in BarrierSetC2 that I can check outside of the loop, to make the extra load barrier search conditional. Was it something like this you had in mind? >> >> Yes, thanks. >> >>>> 2. Can you explain Phi case more. I would like to see an assert which verify cush shape of code to avoid cases when Phi come from loop, for example. >>> Sure. The load barrier has different shapes before and after macro expansion. Before macro expansion it is just a LoadBarrierNode. After expanding the barrier, the pseudo code for the inflated barrier looks something like this: value = is_bad(some_oop) ? slowpath_load : some_oop. The value in that pseudo code is the particular phi I am matching. What is unique about this phi (corresponding to the barrier region node depicting the good_or_null vs bad control flows), compared to an arbitrary phi, is that in(1) is the slowpath_load (LoadBarrierSlowPathRegNode) taken if the oop is bad. A phi in e.g. a loop would point to another phi with this property inside e.g. the loop body, never directly to a slowpath_load (LoadBarrierSlowPathRegNode). >> >> Thank you for explanation. My confusion come that you phi->in(2) is points to a value on one of branches which is inside original macro node. But looking on your pseud code it is some_oop which is what you want. > > :) > >> One suggesting I would give is to add comments to each of 3 cases in step_over_gc_barrier() to be clear what function is looking for. > > Fixed. > >> Also for first case (Proj node) it would be nice to have assert to check node you expect this Proj is connected to. > > I added an assert checking that we only find oop projs of the load barrier (before getting macro expanded). I guess finding an expanded load barrier through a proj should be fine as well. But I haven?t found any in my testing, so I thought having this stronger assert is good so we get the chance to reflect on that if surprising things happen, even though it is possibly harmless. > > Thanks, > /Erik > >> >>> Note that there is a basic and optimized macro expansion of the load barrier. The matching I use catches the optimized variant only (which uses the LoadBarrierSlowPathRegNode for the slow path). The basic barrier expansion is only used for atomic xchg (because self-healing the pointer would be an error in that path). >>> In the new version, I added some assertions right where load barriers are produced and expanded, to assert that it matches and can be stepped over reliably. That way, if we change the barriers, the matching code will not silently stop working. To make these asserts work, I added support for matching barriers on weak barriers as well, that use LoadBarrierWeakSlowPathRegNode. While that isn?t needed for my purposes for loading the mirror, it is better to be more complete. Now you can see at the assertions in ZBarrierSetC2::expand_loadbarrier_optimized the exact phi that I am matching. >>> I have still intentionally left matching of the ?basic? load barrier used by atomic xchg for another day, as nobody has any need for that yet, and it is trickier to match. >>> BTW, it would be nice if in C2 the Node class had a Node* _expanded_from member that could track the node that macro expanded a node, and remember that through cloning of nodes, so that things like this would reduce to simply node->expanded_from()->is_LoadBarrier(), rather than trying to recognize the shape of the expanded barriers. Perhaps that would be useful for others? I did try something like that originally (but tracked with a hashtable), but unfortunately ran into trouble with cloned nodes not retaining the information, and made the decision to go for the shape recognition solution instead. But perhaps it could be generally useful for other shape recognition problems as well? But that might be outside the scope of this RFE. >> >> Yes, it is different and not hard to do. Nobody asked it before. >> >> Thanks, >> Vladimir >> >>> Thanks, >>> /Erik >>>> Thanks, >>>> Vladimir >>>> >>>> On 8/1/18 4:17 AM, Erik ?sterlund wrote: >>>>> Hi, >>>>> There is currently no way of doing IN_NATIVE accesses in C2 using its access API. These are required to properly access OopHandle, used to access the Java class mirrors (because they will now start requiring load barriers). In order to support (concurrent) class unloading in ZGC, this support must be added. >>>>> In this patch, I add an access_load API for loading IN_NATIVE oops, and use it to load class mirrors (which is logically an OopHandle::resolve, which happened to have been an indirect load before as nobody had load barriers on it). In the various code recognizing the shape of a mirror load to optimize the code, I have added a check if a node is a GC barrier and to then step over it in order to match the mirror load. >>>>> In order to recognize and step over the load barriers in ZGC properly, I added support for recognizing the barrier shapes not just before macro expansion (LoadBarrierNode), but also after macro expansion (as required by the matching code), which involves checking for phi nodes with with LoadBarrierSlowRegNode phi->in(1), and then stepping over to phi->in(2), as well as recognizing projections to such shapes. LoadBarrierSlowRegNode is used in all barrier expansions except for atomic xchg, but that is fine as we don't use that on class mirrors. >>>>> I have checked that the shapes are recognized and that no regressions are introduced with these changes through a bunch of benchmarks in gc-test-suite. >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~eosterlund/8208601/webrev.00/ Bug URL: >>>>> https://bugs.openjdk.java.net/browse/JDK-8208601 Thanks, >>>>> /Erik >>>>> Open Tracking > From erik.osterlund at oracle.com Fri Aug 3 18:10:47 2018 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Fri, 3 Aug 2018 20:10:47 +0200 Subject: RFR: 8208601: Introduce native oop barriers in C2 for OopHandle In-Reply-To: References: <5B6196CA.7080201@oracle.com> <51231d8e-e2ed-3d95-2cb2-c8cb61cbe512@oracle.com> <1C90F3B1-AB57-44AF-9030-26238CD42B1B@oracle.com> <349c262f-3fa3-db22-dd65-87a31e9314fc@oracle.com> <3BAEF861-3F74-4D47-AE9A-39C020CC445B@oracle.com> Message-ID: <7BD289F1-E161-41F4-8C23-32464250555E@oracle.com> Hi Vladimir, Thanks for the review. /Erik > On 3 Aug 2018, at 19:58, Vladimir Kozlov wrote: > > This version looks good to me. I think you need second review. > > Thanks, > Vladimir > >> On 8/3/18 9:01 AM, Erik ?sterlund wrote: >> Hi Vladimir, >> Thanks for reviewing. >> Full webrev: >> http://cr.openjdk.java.net/~eosterlund/8208601/webrev.02/ >> Incremental: >> http://cr.openjdk.java.net/~eosterlund/8208601/webrev.01_02/ >>> On 02 Aug 2018, at 19:03, Vladimir Kozlov wrote: >>> >>> Thanks Erik >>> >>> Wow! I got 18 copies of your response ;) >> Oops, sorry about that. My mail client said it didn?t send - so I pressed send a few times more. Looks like they were all sent in the end. >_< >>>> On 8/2/18 2:39 AM, Erik ?sterlund wrote: >>>> Hi Vladimir, >>>> Thank you for reviewing. >>>> Incremental: >>>> http://cr.openjdk.java.net/~eosterlund/8208601/webrev.00_01/ >>>> Full: >>>> http://cr.openjdk.java.net/~eosterlund/8208601/webrev.01/ >>>>> On 01 Aug 2018, at 20:03, Vladimir Kozlov wrote: >>>>> >>>>> Hi, Erik >>>>> >>>>> 1. is_gc_barrier_node(b) is virtual so even if it return 'false' I am not sure C++ will collapse new search loops in phaseX.cpp and checks in other cases. Can we use some static check to allow C++ collapse that code in case there is no load barriers? >>>> I see your point. I introduced a has_load_barrier() function in BarrierSetC2 that I can check outside of the loop, to make the extra load barrier search conditional. Was it something like this you had in mind? >>> >>> Yes, thanks. >>> >>>>> 2. Can you explain Phi case more. I would like to see an assert which verify cush shape of code to avoid cases when Phi come from loop, for example. >>>> Sure. The load barrier has different shapes before and after macro expansion. Before macro expansion it is just a LoadBarrierNode. After expanding the barrier, the pseudo code for the inflated barrier looks something like this: value = is_bad(some_oop) ? slowpath_load : some_oop. The value in that pseudo code is the particular phi I am matching. What is unique about this phi (corresponding to the barrier region node depicting the good_or_null vs bad control flows), compared to an arbitrary phi, is that in(1) is the slowpath_load (LoadBarrierSlowPathRegNode) taken if the oop is bad. A phi in e.g. a loop would point to another phi with this property inside e.g. the loop body, never directly to a slowpath_load (LoadBarrierSlowPathRegNode). >>> >>> Thank you for explanation. My confusion come that you phi->in(2) is points to a value on one of branches which is inside original macro node. But looking on your pseud code it is some_oop which is what you want. >> :) >>> One suggesting I would give is to add comments to each of 3 cases in step_over_gc_barrier() to be clear what function is looking for. >> Fixed. >>> Also for first case (Proj node) it would be nice to have assert to check node you expect this Proj is connected to. >> I added an assert checking that we only find oop projs of the load barrier (before getting macro expanded). I guess finding an expanded load barrier through a proj should be fine as well. But I haven?t found any in my testing, so I thought having this stronger assert is good so we get the chance to reflect on that if surprising things happen, even though it is possibly harmless. >> Thanks, >> /Erik >>> >>>> Note that there is a basic and optimized macro expansion of the load barrier. The matching I use catches the optimized variant only (which uses the LoadBarrierSlowPathRegNode for the slow path). The basic barrier expansion is only used for atomic xchg (because self-healing the pointer would be an error in that path). >>>> In the new version, I added some assertions right where load barriers are produced and expanded, to assert that it matches and can be stepped over reliably. That way, if we change the barriers, the matching code will not silently stop working. To make these asserts work, I added support for matching barriers on weak barriers as well, that use LoadBarrierWeakSlowPathRegNode. While that isn?t needed for my purposes for loading the mirror, it is better to be more complete. Now you can see at the assertions in ZBarrierSetC2::expand_loadbarrier_optimized the exact phi that I am matching. >>>> I have still intentionally left matching of the ?basic? load barrier used by atomic xchg for another day, as nobody has any need for that yet, and it is trickier to match. >>>> BTW, it would be nice if in C2 the Node class had a Node* _expanded_from member that could track the node that macro expanded a node, and remember that through cloning of nodes, so that things like this would reduce to simply node->expanded_from()->is_LoadBarrier(), rather than trying to recognize the shape of the expanded barriers. Perhaps that would be useful for others? I did try something like that originally (but tracked with a hashtable), but unfortunately ran into trouble with cloned nodes not retaining the information, and made the decision to go for the shape recognition solution instead. But perhaps it could be generally useful for other shape recognition problems as well? But that might be outside the scope of this RFE. >>> >>> Yes, it is different and not hard to do. Nobody asked it before. >>> >>> Thanks, >>> Vladimir >>> >>>> Thanks, >>>> /Erik >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> On 8/1/18 4:17 AM, Erik ?sterlund wrote: >>>>>> Hi, >>>>>> There is currently no way of doing IN_NATIVE accesses in C2 using its access API. These are required to properly access OopHandle, used to access the Java class mirrors (because they will now start requiring load barriers). In order to support (concurrent) class unloading in ZGC, this support must be added. >>>>>> In this patch, I add an access_load API for loading IN_NATIVE oops, and use it to load class mirrors (which is logically an OopHandle::resolve, which happened to have been an indirect load before as nobody had load barriers on it). In the various code recognizing the shape of a mirror load to optimize the code, I have added a check if a node is a GC barrier and to then step over it in order to match the mirror load. >>>>>> In order to recognize and step over the load barriers in ZGC properly, I added support for recognizing the barrier shapes not just before macro expansion (LoadBarrierNode), but also after macro expansion (as required by the matching code), which involves checking for phi nodes with with LoadBarrierSlowRegNode phi->in(1), and then stepping over to phi->in(2), as well as recognizing projections to such shapes. LoadBarrierSlowRegNode is used in all barrier expansions except for atomic xchg, but that is fine as we don't use that on class mirrors. >>>>>> I have checked that the shapes are recognized and that no regressions are introduced with these changes through a bunch of benchmarks in gc-test-suite. >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~eosterlund/8208601/webrev.00/ Bug URL: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8208601 Thanks, >>>>>> /Erik >>>>>> Open Tracking From kim.barrett at oracle.com Fri Aug 3 20:41:36 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 3 Aug 2018 16:41:36 -0400 Subject: RFR (XL): 8208669: GC changes to allow enabling -Wreorder In-Reply-To: <1fe17e13a5aeb583f05061c1cab6b55b7bdd4279.camel@oracle.com> References: <1fe17e13a5aeb583f05061c1cab6b55b7bdd4279.camel@oracle.com> Message-ID: > On Aug 2, 2018, at 5:07 AM, Thomas Schatzl wrote: > > Hi all, > > there have been several suggestions to try to fix the Hotspot code to > allow us to enable -Wreorder in the Hotspot sources. > This should make problems due to use-before-initialization much more > obvious. > > This change fixes initializer lists for the GC directories. > > There should be no change in code behavior, except for that there is > iirc one minor change that fixes the memory type of one initialization > from mtInternal to mtGC. > > A later follow-up will enable -Wreorder in the makefiles. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8208669 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8208669/webrev/ > Testing: > hs-tier1-4,jdk-tier1-3 > > Thanks, > Thomas Looks good. A few comments and minor things for which I don't need a new webrev. There were some additions of explicit initialization in the initializer list, that didn't seem associated with -Wreorder. I'm okay with them. ------------------------------------------------------------------------------ src/hotspot/share/gc/g1/g1BlockOffsetTable.cpp 80 #ifdef ASSERT 81 _object_can_span(false), 82 #endif FYI, this can also be written as DEBUG_ONLY(_object_can_span(false) COMMA) ------------------------------------------------------------------------------ src/hotspot/share/gc/g1/g1CollectedHeap.cpp 1423 _expansion_regions(0), This is an additional explicit initialization. However, this member is never used. ------------------------------------------------------------------------------ src/hotspot/share/gc/g1/g1CollectedHeap.cpp 1455 _evacuation_failed(false), This is adding an explicit initialization in the initializer list, where there wasn't even an initialization assignment in the constructor body. It was okay before because it is assigned in pre_evacuate_collection_set. I'm okay with this, just confirming intent. ------------------------------------------------------------------------------ src/hotspot/share/gc/cms/parNewGeneration.cpp 97 _hash_seed(0), src/hotspot/share/gc/g1/g1RegionMarkStatsCache.cpp 36 _num_cache_entries_mask(0) { src/hotspot/share/gc/shared/workerDataArray.inline.hpp 35 _length(0), Rather than initializing to a dummy value here and keeping the later in-body assignment, move the in-body value to the initializer. ------------------------------------------------------------------------------ src/hotspot/share/gc/shared/workgroup.cpp 190 MutexGangTaskDispatcher() I don't really like how this one ended up being re-formated, especially having the (empty) constructor body way far over to the right. Also, aligning the colon with the constructor name seems pretty unusual. ------------------------------------------------------------------------------ From yumin.qi at gmail.com Sat Aug 4 16:54:35 2018 From: yumin.qi at gmail.com (yumin qi) Date: Sat, 4 Aug 2018 09:54:35 -0700 Subject: JEP: https://bugs.openjdk.java.net/browse/JDK-8203832 In-Reply-To: References: <0ca282db-5b4f-607d-512a-a2183dbd4b73@oracle.com> <96806b1f-6fce-83e0-0ffb-02f7a19e8301@oracle.com> <0e05aeee-6d80-c8a8-bece-3533fa561110@oracle.com> Message-ID: Vladimir and Tobias, Thank you and those people who spent time and move this forward! I will submit patch for codereivew soon. Thanks Yumin On Fri, Aug 3, 2018 at 10:54 AM Vladimir Kozlov wrote: > Thank you very much, Tobias > > Vladimir > > On 8/3/18 2:59 AM, Tobias Hartmann wrote: > > Hi Vladimir, > > > > On 02.08.2018 22:55, Vladimir Kozlov wrote: > >> Tobias, can you review JEP and add new comments, questions if you have > them. > > > > Looks good to me. I've fixed some typos in the description (I think some > of the wording should still > > be improved). > > > > Best regards, > > Tobias > > > From yumin.qi at gmail.com Sat Aug 4 16:56:16 2018 From: yumin.qi at gmail.com (yumin qi) Date: Sat, 4 Aug 2018 09:56:16 -0700 Subject: JEP: https://bugs.openjdk.java.net/browse/JDK-8203832 In-Reply-To: References: <0ca282db-5b4f-607d-512a-a2183dbd4b73@oracle.com> <96806b1f-6fce-83e0-0ffb-02f7a19e8301@oracle.com> <0e05aeee-6d80-c8a8-bece-3533fa561110@oracle.com> Message-ID: Oops, I mean submit RFR after it is approved. Thanks Yumin On Sat, Aug 4, 2018 at 9:54 AM yumin qi wrote: > Vladimir and Tobias, > > Thank you and those people who spent time and move this forward! I will > submit patch for codereivew soon. > > Thanks > Yumin > > On Fri, Aug 3, 2018 at 10:54 AM Vladimir Kozlov < > vladimir.kozlov at oracle.com> wrote: > >> Thank you very much, Tobias >> >> Vladimir >> >> On 8/3/18 2:59 AM, Tobias Hartmann wrote: >> > Hi Vladimir, >> > >> > On 02.08.2018 22:55, Vladimir Kozlov wrote: >> >> Tobias, can you review JEP and add new comments, questions if you have >> them. >> > >> > Looks good to me. I've fixed some typos in the description (I think >> some of the wording should still >> > be improved). >> > >> > Best regards, >> > Tobias >> > >> > From martinrb at google.com Sun Aug 5 15:30:27 2018 From: martinrb at google.com (Martin Buchholz) Date: Sun, 5 Aug 2018 08:30:27 -0700 Subject: Using C++11+ in hotspot In-Reply-To: <6D166068-9FA9-4B0B-A157-0CB109753F4C@oracle.com> References: <6D166068-9FA9-4B0B-A157-0CB109753F4C@oracle.com> Message-ID: On Fri, Aug 3, 2018 at 3:14 PM, Mikael Vidstedt wrote: > > Martin Buchholz suggested the topic and Mikael signed up to lead the > session. Martin gave an introduction. He had observed some issues recently > (?impossible null pointer exceptions?) which after investigation turned out > to be caused by a toolchain upgrade and in turn revealed the fact that some > code in hotspot requires atomicity but does not make this requirement very > explicit and in the end assumes that the C++ compiler will produce suitable > code to guarantee atomicity. Martin also observed that (on linux) hotspot > is compiled targeting the c++98 standard, which is old enough to not even > mention the concept of threads. Mikael also added that for extra fun the > story is different on different platforms and toolchains. > I was surprised to hear that IBM AIX xlc compilers might not support C++11 - it's not the IBM way. But from reading the tea leaves at https://www-01.ibm.com/support/docview.wss?uid=swg27007322&aid=1 I concluded that IBM is a Linux company now! Even for IBM, AIX is a niche legacy platform and they just couldn't keep up with the evolution of C++ (who can blame them?). Meanwhile gcc is available for AIX and can/should be used to build openjdk. Has anyone tried? Here's one example of code that actually did go wrong with Google's latest internal toolchain, because the copy was not in fact word-atomic. Thanks to whoever added the comment long ago. static inline void copy_table(address* from, address* to, int size) { // Copy non-overlapping tables. The copy has to occur word wise for MT safety. while (size-- > 0) *to++ = *from++; } Recommendation: target C++11 for jdk12; use gcc to build openjdk on AIX. From aph at redhat.com Mon Aug 6 08:16:13 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 6 Aug 2018 09:16:13 +0100 Subject: Using C++11+ in hotspot In-Reply-To: References: <6D166068-9FA9-4B0B-A157-0CB109753F4C@oracle.com> Message-ID: On 08/05/2018 04:30 PM, Martin Buchholz wrote: > Here's one example of code that actually did go wrong with Google's latest > internal toolchain, because the copy was not in fact word-atomic. Thanks > to whoever added the comment long ago. > > static inline void copy_table(address* from, address* to, int size) { > // Copy non-overlapping tables. The copy has to occur word wise for MT > safety. > while (size-- > 0) *to++ = *from++; > } > > Recommendation: target C++11 for jdk12; I don't think that helps. There's no legal way AFAICS to force an atomic access to non-atomic types in C++11. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From thomas.schatzl at oracle.com Mon Aug 6 12:35:24 2018 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 06 Aug 2018 14:35:24 +0200 Subject: RFR (XL): 8208669: GC changes to allow enabling -Wreorder In-Reply-To: References: <1fe17e13a5aeb583f05061c1cab6b55b7bdd4279.camel@oracle.com> Message-ID: Hi Kim, thanks for your review. On Fri, 2018-08-03 at 16:41 -0400, Kim Barrett wrote: > > On Aug 2, 2018, at 5:07 AM, Thomas Schatzl > om> wrote: > > > > Hi all, > > > > there have been several suggestions to try to fix the Hotspot code > > to allow us to enable -Wreorder in the Hotspot sources. > > This should make problems due to use-before-initialization much > > more > > obvious. > > [...] > Looks good. > > A few comments and minor things for which I don't need a new webrev. > > There were some additions of explicit initialization in the > initializer list, that didn't seem associated with -Wreorder. I'm > okay with them. > > ------------------------------------------------------------------- > ----------- > src/hotspot/share/gc/g1/g1BlockOffsetTable.cpp > 80 #ifdef ASSERT > 81 _object_can_span(false), > 82 #endif > > FYI, this can also be written as > DEBUG_ONLY(_object_can_span(false) COMMA) I knew there was some way to do it like this... thanks! > ------------------------------------------------------------------- > ----------- > src/hotspot/share/gc/g1/g1CollectedHeap.cpp > 1423 _expansion_regions(0), > > This is an additional explicit initialization. However, this member > is never used. I simply removed the member. > ------------------------------------------------------------------- > ----------- > src/hotspot/share/gc/g1/g1CollectedHeap.cpp > 1455 _evacuation_failed(false), > > This is adding an explicit initialization in the initializer list, > where there wasn't even an initialization assignment in the > constructor body. It was okay before because it is assigned in > pre_evacuate_collection_set. I'm okay with this, just confirming > intent. > Yes, for GC code I did that. > ------------------------------------------------------------------- > ----------- > src/hotspot/share/gc/cms/parNewGeneration.cpp > 97 _hash_seed(0), > > src/hotspot/share/gc/g1/g1RegionMarkStatsCache.cpp > 36 _num_cache_entries_mask(0) { > > src/hotspot/share/gc/shared/workerDataArray.inline.hpp > 35 _length(0), > > Rather than initializing to a dummy value here and keeping the later > in-body assignment, move the in-body value to the initializer. Fixed. > > ------------------------------------------------------------------- > ----------- > src/hotspot/share/gc/shared/workgroup.cpp > 190 MutexGangTaskDispatcher() > > I don't really like how this one ended up being re-formated, > especially having the (empty) constructor body way far over to the > right. Also, aligning the colon with the constructor name seems > pretty unusual. You don't believe how many styles I observed in these set of patches... I tried to improve it. http://cr.openjdk.java.net/~tschatzl/8208669/webrev.1 (full) http://cr.openjdk.java.net/~tschatzl/8208669/webrev.0_to_1 (diff) Thanks, Thomas From thomas.schatzl at oracle.com Mon Aug 6 12:38:09 2018 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 06 Aug 2018 14:38:09 +0200 Subject: RFR (XXS): 8208672: Enable -Wreorder in make files In-Reply-To: References: Message-ID: Hi David, On Fri, 2018-08-03 at 10:20 +1000, David Holmes wrote: > Hi Thomas, > > On 2/08/2018 7:14 PM, Thomas Schatzl wrote: > > Hi all, > > > > there have been several suggestions to try to fix the Hotspot > > code to allow us to enable -Wreorder in the Hotspot sources. > > This should make problems due to use-before-initialization much > > more obvious. > > > > This change enables -Wreorder for gcc and clang. > > For Windows (VS2017+) see: > > https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings > /c5038 > > Otherwise change seems okay. > Thanks! http://cr.openjdk.java.net/~tschatzl/8208672/webrev.0_to_1 (diff) http://cr.openjdk.java.net/~tschatzl/8208672/webrev.1 (full) I verified that all our platforms (including Windows) still build. Thanks, Thomas From thomas.schatzl at oracle.com Mon Aug 6 13:42:46 2018 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 06 Aug 2018 15:42:46 +0200 Subject: RFR (L): 8208670: Compiler changes to allow enabling -Wreorder In-Reply-To: <07538e77-b327-8c60-34d1-6e998e41a688@oracle.com> References: <98c2eaaf111cee13dbe4470b98a22c0c08ed4b17.camel@oracle.com> <07538e77-b327-8c60-34d1-6e998e41a688@oracle.com> Message-ID: Hi Vladimir, On Thu, 2018-08-02 at 09:31 -0700, Vladimir Kozlov wrote: > Looks good to me. > thanks for your review. Thomas From daniel.daugherty at oracle.com Mon Aug 6 16:49:47 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 6 Aug 2018 12:49:47 -0400 Subject: RFR(XXS): 8209018 ProblemList tests affected by JDK-8208690 Message-ID: Greetings, I'm in the process of reducing the noise in the JDK12 CI so I need a single (R)eviewer for the following fix: ??? JDK-8209018 ProblemList tests affected by JDK-8208690 ??? https://bugs.openjdk.java.net/browse/JDK-8209018 Here's the diff: $ hg diff diff -r c00451b67854 test/hotspot/jtreg/ProblemList.txt --- a/test/hotspot/jtreg/ProblemList.txt??? Mon Aug 06 04:31:50 2018 -0400 +++ b/test/hotspot/jtreg/ProblemList.txt??? Mon Aug 06 12:40:20 2018 -0400 @@ -59,6 +59,9 @@ ?compiler/cpuflags/TestAESIntrinsicsOnSupportedConfig.java 8190680 generic-all +compiler/c1/Test4917709.java 8208690 generic-all +compiler/runtime/cr6891750/Test6891750.java 8208690 generic-all + ?############################################################################# ?# :hotspot_gc diff -r c00451b67854 test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt??? Mon Aug 06 04:31:50 2018 -0400 +++ b/test/jdk/ProblemList.txt??? Mon Aug 06 12:40:20 2018 -0400 @@ -559,6 +559,9 @@ ?java/net/DatagramSocket/SendDatagramToBadAddress.java 7143960 macosx-all +java/net/Socket/LingerTest.java 8208690 generic-all +sun/net/www/http/HttpClient/MultiThreadTest.java 8208690 generic-all + ?############################################################################ ?# jdk_nio Thanks, in advance, for any questions, comments or suggestions. Dan From vladimir.kozlov at oracle.com Mon Aug 6 16:59:17 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 6 Aug 2018 09:59:17 -0700 Subject: RFR(XXS): 8209018 ProblemList tests affected by JDK-8208690 In-Reply-To: References: Message-ID: <1a0be5f3-b5b5-f843-d99e-8539e5cd9f6a@oracle.com> Hi Dan, 8208690 lists only next 2 tests: sun/net/www/http/HttpClient/MultiThreadTest.java (4 instances) java/net/Socket/LingerTest.java (2 instances) Why you also added 2 compiler tests? Thanks, Vladimir On 8/6/18 9:49 AM, Daniel D. Daugherty wrote: > Greetings, > > I'm in the process of reducing the noise in the JDK12 CI so > I need a single (R)eviewer for the following fix: > > ??? JDK-8209018 ProblemList tests affected by JDK-8208690 > ??? https://bugs.openjdk.java.net/browse/JDK-8209018 > > Here's the diff: > > $ hg diff > diff -r c00451b67854 test/hotspot/jtreg/ProblemList.txt > --- a/test/hotspot/jtreg/ProblemList.txt??? Mon Aug 06 04:31:50 2018 -0400 > +++ b/test/hotspot/jtreg/ProblemList.txt??? Mon Aug 06 12:40:20 2018 -0400 > @@ -59,6 +59,9 @@ > > ?compiler/cpuflags/TestAESIntrinsicsOnSupportedConfig.java 8190680 generic-all > > +compiler/c1/Test4917709.java 8208690 generic-all > +compiler/runtime/cr6891750/Test6891750.java 8208690 generic-all > + > ?############################################################################# > > ?# :hotspot_gc > diff -r c00451b67854 test/jdk/ProblemList.txt > --- a/test/jdk/ProblemList.txt??? Mon Aug 06 04:31:50 2018 -0400 > +++ b/test/jdk/ProblemList.txt??? Mon Aug 06 12:40:20 2018 -0400 > @@ -559,6 +559,9 @@ > > ?java/net/DatagramSocket/SendDatagramToBadAddress.java 7143960 macosx-all > > +java/net/Socket/LingerTest.java 8208690 generic-all > +sun/net/www/http/HttpClient/MultiThreadTest.java 8208690 generic-all > + > ?############################################################################ > > ?# jdk_nio > > > Thanks, in advance, for any questions, comments or suggestions. > > Dan From daniel.daugherty at oracle.com Mon Aug 6 17:01:18 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 6 Aug 2018 13:01:18 -0400 Subject: RFR(XXS): 8209018 ProblemList tests affected by JDK-8208690 In-Reply-To: <1a0be5f3-b5b5-f843-d99e-8539e5cd9f6a@oracle.com> References: <1a0be5f3-b5b5-f843-d99e-8539e5cd9f6a@oracle.com> Message-ID: On 8/6/18 12:59 PM, Vladimir Kozlov wrote: > Hi Dan, > > 8208690 lists only next 2 tests: > > sun/net/www/http/HttpClient/MultiThreadTest.java (4 instances) > java/net/Socket/LingerTest.java (2 instances) > > Why you also added 2 compiler tests? If you look at all the sightings in the bug report, you'll see the two compiler tests listed in different entries. The compiler test failures are intermittent, but the other two happen in every tier2... Dan > > Thanks, > Vladimir > > On 8/6/18 9:49 AM, Daniel D. Daugherty wrote: >> Greetings, >> >> I'm in the process of reducing the noise in the JDK12 CI so >> I need a single (R)eviewer for the following fix: >> >> ???? JDK-8209018 ProblemList tests affected by JDK-8208690 >> ???? https://bugs.openjdk.java.net/browse/JDK-8209018 >> >> Here's the diff: >> >> $ hg diff >> diff -r c00451b67854 test/hotspot/jtreg/ProblemList.txt >> --- a/test/hotspot/jtreg/ProblemList.txt??? Mon Aug 06 04:31:50 2018 >> -0400 >> +++ b/test/hotspot/jtreg/ProblemList.txt??? Mon Aug 06 12:40:20 2018 >> -0400 >> @@ -59,6 +59,9 @@ >> >> ??compiler/cpuflags/TestAESIntrinsicsOnSupportedConfig.java 8190680 >> generic-all >> >> +compiler/c1/Test4917709.java 8208690 generic-all >> +compiler/runtime/cr6891750/Test6891750.java 8208690 generic-all >> + >> ??############################################################################# >> >> >> ??# :hotspot_gc >> diff -r c00451b67854 test/jdk/ProblemList.txt >> --- a/test/jdk/ProblemList.txt??? Mon Aug 06 04:31:50 2018 -0400 >> +++ b/test/jdk/ProblemList.txt??? Mon Aug 06 12:40:20 2018 -0400 >> @@ -559,6 +559,9 @@ >> >> ??java/net/DatagramSocket/SendDatagramToBadAddress.java 7143960 >> macosx-all >> >> +java/net/Socket/LingerTest.java 8208690 generic-all >> +sun/net/www/http/HttpClient/MultiThreadTest.java 8208690 generic-all >> + >> ??############################################################################ >> >> >> ??# jdk_nio >> >> >> Thanks, in advance, for any questions, comments or suggestions. >> >> Dan From vladimir.kozlov at oracle.com Mon Aug 6 17:14:46 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 6 Aug 2018 10:14:46 -0700 Subject: RFR(XXS): 8209018 ProblemList tests affected by JDK-8208690 In-Reply-To: References: <1a0be5f3-b5b5-f843-d99e-8539e5cd9f6a@oracle.com> Message-ID: Okay, I read more about what happened. I think compiler tests should be modified as David Holmes suggested (use /othervm): "Tests that don't manage their threads properly (ie ensure they terminate at test end) should be run in othervm mode. jtreg can't know how to make these threads terminate." Test4917709.java is closed test, not open. File a separate bug and I will fix these 2 tests. Regards, Vladimir On 8/6/18 10:01 AM, Daniel D. Daugherty wrote: > On 8/6/18 12:59 PM, Vladimir Kozlov wrote: >> Hi Dan, >> >> 8208690 lists only next 2 tests: >> >> sun/net/www/http/HttpClient/MultiThreadTest.java (4 instances) >> java/net/Socket/LingerTest.java (2 instances) >> >> Why you also added 2 compiler tests? > > If you look at all the sightings in the bug report, you'll > see the two compiler tests listed in different entries. > The compiler test failures are intermittent, but the other > two happen in every tier2... > > Dan > > >> >> Thanks, >> Vladimir >> >> On 8/6/18 9:49 AM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I'm in the process of reducing the noise in the JDK12 CI so >>> I need a single (R)eviewer for the following fix: >>> >>> ???? JDK-8209018 ProblemList tests affected by JDK-8208690 >>> ???? https://bugs.openjdk.java.net/browse/JDK-8209018 >>> >>> Here's the diff: >>> >>> $ hg diff >>> diff -r c00451b67854 test/hotspot/jtreg/ProblemList.txt >>> --- a/test/hotspot/jtreg/ProblemList.txt??? Mon Aug 06 04:31:50 2018 -0400 >>> +++ b/test/hotspot/jtreg/ProblemList.txt??? Mon Aug 06 12:40:20 2018 -0400 >>> @@ -59,6 +59,9 @@ >>> >>> ??compiler/cpuflags/TestAESIntrinsicsOnSupportedConfig.java 8190680 generic-all >>> >>> +compiler/c1/Test4917709.java 8208690 generic-all >>> +compiler/runtime/cr6891750/Test6891750.java 8208690 generic-all >>> + >>> ??############################################################################# >>> >>> ??# :hotspot_gc >>> diff -r c00451b67854 test/jdk/ProblemList.txt >>> --- a/test/jdk/ProblemList.txt??? Mon Aug 06 04:31:50 2018 -0400 >>> +++ b/test/jdk/ProblemList.txt??? Mon Aug 06 12:40:20 2018 -0400 >>> @@ -559,6 +559,9 @@ >>> >>> ??java/net/DatagramSocket/SendDatagramToBadAddress.java 7143960 macosx-all >>> >>> +java/net/Socket/LingerTest.java 8208690 generic-all >>> +sun/net/www/http/HttpClient/MultiThreadTest.java 8208690 generic-all >>> + >>> ??############################################################################ >>> >>> ??# jdk_nio >>> >>> >>> Thanks, in advance, for any questions, comments or suggestions. >>> >>> Dan > From daniel.daugherty at oracle.com Mon Aug 6 17:25:34 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 6 Aug 2018 13:25:34 -0400 Subject: RFR(XXS): 8209018 ProblemList tests affected by JDK-8208690 In-Reply-To: References: <1a0be5f3-b5b5-f843-d99e-8539e5cd9f6a@oracle.com> Message-ID: On 8/6/18 1:14 PM, Vladimir Kozlov wrote: > Okay, I read more about what happened. I think compiler tests should > be modified as David Holmes suggested (use /othervm): > > "Tests that don't manage their threads properly (ie ensure they > terminate at test end) should be run in othervm mode. jtreg can't know > how to make these threads terminate." > > Test4917709.java is closed test, not open. Oops. I'll have to clean that up. > File a separate bug and I will fix these 2 tests. So are you saying not to ProblemList these two tests and that I should file a new bug and you'll take care of it? Dan > > Regards, > Vladimir > > On 8/6/18 10:01 AM, Daniel D. Daugherty wrote: >> On 8/6/18 12:59 PM, Vladimir Kozlov wrote: >>> Hi Dan, >>> >>> 8208690 lists only next 2 tests: >>> >>> sun/net/www/http/HttpClient/MultiThreadTest.java (4 instances) >>> java/net/Socket/LingerTest.java (2 instances) >>> >>> Why you also added 2 compiler tests? >> >> If you look at all the sightings in the bug report, you'll >> see the two compiler tests listed in different entries. >> The compiler test failures are intermittent, but the other >> two happen in every tier2... >> >> Dan >> >> >>> >>> Thanks, >>> Vladimir >>> >>> On 8/6/18 9:49 AM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> I'm in the process of reducing the noise in the JDK12 CI so >>>> I need a single (R)eviewer for the following fix: >>>> >>>> ???? JDK-8209018 ProblemList tests affected by JDK-8208690 >>>> ???? https://bugs.openjdk.java.net/browse/JDK-8209018 >>>> >>>> Here's the diff: >>>> >>>> $ hg diff >>>> diff -r c00451b67854 test/hotspot/jtreg/ProblemList.txt >>>> --- a/test/hotspot/jtreg/ProblemList.txt??? Mon Aug 06 04:31:50 >>>> 2018 -0400 >>>> +++ b/test/hotspot/jtreg/ProblemList.txt??? Mon Aug 06 12:40:20 >>>> 2018 -0400 >>>> @@ -59,6 +59,9 @@ >>>> >>>> ??compiler/cpuflags/TestAESIntrinsicsOnSupportedConfig.java 8190680 >>>> generic-all >>>> >>>> +compiler/c1/Test4917709.java 8208690 generic-all >>>> +compiler/runtime/cr6891750/Test6891750.java 8208690 generic-all >>>> + >>>> ??############################################################################# >>>> >>>> >>>> ??# :hotspot_gc >>>> diff -r c00451b67854 test/jdk/ProblemList.txt >>>> --- a/test/jdk/ProblemList.txt??? Mon Aug 06 04:31:50 2018 -0400 >>>> +++ b/test/jdk/ProblemList.txt??? Mon Aug 06 12:40:20 2018 -0400 >>>> @@ -559,6 +559,9 @@ >>>> >>>> ??java/net/DatagramSocket/SendDatagramToBadAddress.java 7143960 >>>> macosx-all >>>> >>>> +java/net/Socket/LingerTest.java 8208690 generic-all >>>> +sun/net/www/http/HttpClient/MultiThreadTest.java 8208690 generic-all >>>> + >>>> ??############################################################################ >>>> >>>> >>>> ??# jdk_nio >>>> >>>> >>>> Thanks, in advance, for any questions, comments or suggestions. >>>> >>>> Dan >> From vladimir.kozlov at oracle.com Mon Aug 6 17:41:19 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 6 Aug 2018 10:41:19 -0700 Subject: RFR(XXS): 8209018 ProblemList tests affected by JDK-8208690 In-Reply-To: References: <1a0be5f3-b5b5-f843-d99e-8539e5cd9f6a@oracle.com> Message-ID: <1ca06153-2545-4438-8e7b-b3381b5b0e51@oracle.com> On 8/6/18 10:25 AM, Daniel D. Daugherty wrote: > On 8/6/18 1:14 PM, Vladimir Kozlov wrote: >> Okay, I read more about what happened. I think compiler tests should be modified as David Holmes suggested (use >> /othervm): >> >> "Tests that don't manage their threads properly (ie ensure they terminate at test end) should be run in othervm mode. >> jtreg can't know how to make these threads terminate." >> >> Test4917709.java is closed test, not open. > > Oops. I'll have to clean that up. > > >> File a separate bug and I will fix these 2 tests. > > So are you saying not to ProblemList these two tests and > that I should file a new bug and you'll take care of it? Yes. Vladimir > > Dan > > >> >> Regards, >> Vladimir >> >> On 8/6/18 10:01 AM, Daniel D. Daugherty wrote: >>> On 8/6/18 12:59 PM, Vladimir Kozlov wrote: >>>> Hi Dan, >>>> >>>> 8208690 lists only next 2 tests: >>>> >>>> sun/net/www/http/HttpClient/MultiThreadTest.java (4 instances) >>>> java/net/Socket/LingerTest.java (2 instances) >>>> >>>> Why you also added 2 compiler tests? >>> >>> If you look at all the sightings in the bug report, you'll >>> see the two compiler tests listed in different entries. >>> The compiler test failures are intermittent, but the other >>> two happen in every tier2... >>> >>> Dan >>> >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 8/6/18 9:49 AM, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> I'm in the process of reducing the noise in the JDK12 CI so >>>>> I need a single (R)eviewer for the following fix: >>>>> >>>>> ???? JDK-8209018 ProblemList tests affected by JDK-8208690 >>>>> ???? https://bugs.openjdk.java.net/browse/JDK-8209018 >>>>> >>>>> Here's the diff: >>>>> >>>>> $ hg diff >>>>> diff -r c00451b67854 test/hotspot/jtreg/ProblemList.txt >>>>> --- a/test/hotspot/jtreg/ProblemList.txt??? Mon Aug 06 04:31:50 2018 -0400 >>>>> +++ b/test/hotspot/jtreg/ProblemList.txt??? Mon Aug 06 12:40:20 2018 -0400 >>>>> @@ -59,6 +59,9 @@ >>>>> >>>>> ??compiler/cpuflags/TestAESIntrinsicsOnSupportedConfig.java 8190680 generic-all >>>>> >>>>> +compiler/c1/Test4917709.java 8208690 generic-all >>>>> +compiler/runtime/cr6891750/Test6891750.java 8208690 generic-all >>>>> + >>>>> ??############################################################################# >>>>> >>>>> ??# :hotspot_gc >>>>> diff -r c00451b67854 test/jdk/ProblemList.txt >>>>> --- a/test/jdk/ProblemList.txt??? Mon Aug 06 04:31:50 2018 -0400 >>>>> +++ b/test/jdk/ProblemList.txt??? Mon Aug 06 12:40:20 2018 -0400 >>>>> @@ -559,6 +559,9 @@ >>>>> >>>>> ??java/net/DatagramSocket/SendDatagramToBadAddress.java 7143960 macosx-all >>>>> >>>>> +java/net/Socket/LingerTest.java 8208690 generic-all >>>>> +sun/net/www/http/HttpClient/MultiThreadTest.java 8208690 generic-all >>>>> + >>>>> ??############################################################################ >>>>> >>>>> ??# jdk_nio >>>>> >>>>> >>>>> Thanks, in advance, for any questions, comments or suggestions. >>>>> >>>>> Dan >>> > From daniel.daugherty at oracle.com Mon Aug 6 17:43:59 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 6 Aug 2018 13:43:59 -0400 Subject: RFR(XXS): 8209018 ProblemList tests affected by JDK-8208690 In-Reply-To: <1ca06153-2545-4438-8e7b-b3381b5b0e51@oracle.com> References: <1a0be5f3-b5b5-f843-d99e-8539e5cd9f6a@oracle.com> <1ca06153-2545-4438-8e7b-b3381b5b0e51@oracle.com> Message-ID: <183bd7ae-313b-36ee-0da0-9f85c57f68b8@oracle.com> On 8/6/18 1:41 PM, Vladimir Kozlov wrote: > On 8/6/18 10:25 AM, Daniel D. Daugherty wrote: >> On 8/6/18 1:14 PM, Vladimir Kozlov wrote: >>> Okay, I read more about what happened. I think compiler tests should >>> be modified as David Holmes suggested (use /othervm): >>> >>> "Tests that don't manage their threads properly (ie ensure they >>> terminate at test end) should be run in othervm mode. jtreg can't >>> know how to make these threads terminate." >>> >>> Test4917709.java is closed test, not open. >> >> Oops. I'll have to clean that up. >> >> >>> File a separate bug and I will fix these 2 tests. >> >> So are you saying not to ProblemList these two tests and >> that I should file a new bug and you'll take care of it? > > Yes. Okay I'll do that. Can I list you as the (R)eviewer for ProblemListing these two tests? sun/net/www/http/HttpClient/MultiThreadTest.java java/net/Socket/LingerTest.java Dan > > Vladimir > >> >> Dan >> >> >>> >>> Regards, >>> Vladimir >>> >>> On 8/6/18 10:01 AM, Daniel D. Daugherty wrote: >>>> On 8/6/18 12:59 PM, Vladimir Kozlov wrote: >>>>> Hi Dan, >>>>> >>>>> 8208690 lists only next 2 tests: >>>>> >>>>> sun/net/www/http/HttpClient/MultiThreadTest.java (4 instances) >>>>> java/net/Socket/LingerTest.java (2 instances) >>>>> >>>>> Why you also added 2 compiler tests? >>>> >>>> If you look at all the sightings in the bug report, you'll >>>> see the two compiler tests listed in different entries. >>>> The compiler test failures are intermittent, but the other >>>> two happen in every tier2... >>>> >>>> Dan >>>> >>>> >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 8/6/18 9:49 AM, Daniel D. Daugherty wrote: >>>>>> Greetings, >>>>>> >>>>>> I'm in the process of reducing the noise in the JDK12 CI so >>>>>> I need a single (R)eviewer for the following fix: >>>>>> >>>>>> ???? JDK-8209018 ProblemList tests affected by JDK-8208690 >>>>>> ???? https://bugs.openjdk.java.net/browse/JDK-8209018 >>>>>> >>>>>> Here's the diff: >>>>>> >>>>>> $ hg diff >>>>>> diff -r c00451b67854 test/hotspot/jtreg/ProblemList.txt >>>>>> --- a/test/hotspot/jtreg/ProblemList.txt??? Mon Aug 06 04:31:50 >>>>>> 2018 -0400 >>>>>> +++ b/test/hotspot/jtreg/ProblemList.txt??? Mon Aug 06 12:40:20 >>>>>> 2018 -0400 >>>>>> @@ -59,6 +59,9 @@ >>>>>> >>>>>> ??compiler/cpuflags/TestAESIntrinsicsOnSupportedConfig.java >>>>>> 8190680 generic-all >>>>>> >>>>>> +compiler/c1/Test4917709.java 8208690 generic-all >>>>>> +compiler/runtime/cr6891750/Test6891750.java 8208690 generic-all >>>>>> + >>>>>> ??############################################################################# >>>>>> >>>>>> >>>>>> ??# :hotspot_gc >>>>>> diff -r c00451b67854 test/jdk/ProblemList.txt >>>>>> --- a/test/jdk/ProblemList.txt??? Mon Aug 06 04:31:50 2018 -0400 >>>>>> +++ b/test/jdk/ProblemList.txt??? Mon Aug 06 12:40:20 2018 -0400 >>>>>> @@ -559,6 +559,9 @@ >>>>>> >>>>>> ??java/net/DatagramSocket/SendDatagramToBadAddress.java 7143960 >>>>>> macosx-all >>>>>> >>>>>> +java/net/Socket/LingerTest.java 8208690 generic-all >>>>>> +sun/net/www/http/HttpClient/MultiThreadTest.java 8208690 >>>>>> generic-all >>>>>> + >>>>>> ??############################################################################ >>>>>> >>>>>> >>>>>> ??# jdk_nio >>>>>> >>>>>> >>>>>> Thanks, in advance, for any questions, comments or suggestions. >>>>>> >>>>>> Dan >>>> >> From vladimir.kozlov at oracle.com Mon Aug 6 17:52:41 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 6 Aug 2018 10:52:41 -0700 Subject: RFR(XXS): 8209018 ProblemList tests affected by JDK-8208690 In-Reply-To: <183bd7ae-313b-36ee-0da0-9f85c57f68b8@oracle.com> References: <1a0be5f3-b5b5-f843-d99e-8539e5cd9f6a@oracle.com> <1ca06153-2545-4438-8e7b-b3381b5b0e51@oracle.com> <183bd7ae-313b-36ee-0da0-9f85c57f68b8@oracle.com> Message-ID: <64ddc169-1cb1-4a31-c191-a2fc2c3b3945@oracle.com> On 8/6/18 10:43 AM, Daniel D. Daugherty wrote: > On 8/6/18 1:41 PM, Vladimir Kozlov wrote: >> On 8/6/18 10:25 AM, Daniel D. Daugherty wrote: >>> On 8/6/18 1:14 PM, Vladimir Kozlov wrote: >>>> Okay, I read more about what happened. I think compiler tests should be modified as David Holmes suggested (use >>>> /othervm): >>>> >>>> "Tests that don't manage their threads properly (ie ensure they terminate at test end) should be run in othervm >>>> mode. jtreg can't know how to make these threads terminate." >>>> >>>> Test4917709.java is closed test, not open. >>> >>> Oops. I'll have to clean that up. >>> >>> >>>> File a separate bug and I will fix these 2 tests. >>> >>> So are you saying not to ProblemList these two tests and >>> that I should file a new bug and you'll take care of it? >> >> Yes. > > Okay I'll do that. > > Can I list you as the (R)eviewer for ProblemListing these two tests? yes. > > sun/net/www/http/HttpClient/MultiThreadTest.java > java/net/Socket/LingerTest.java > > Dan > > >> >> Vladimir >> >>> >>> Dan >>> >>> >>>> >>>> Regards, >>>> Vladimir >>>> >>>> On 8/6/18 10:01 AM, Daniel D. Daugherty wrote: >>>>> On 8/6/18 12:59 PM, Vladimir Kozlov wrote: >>>>>> Hi Dan, >>>>>> >>>>>> 8208690 lists only next 2 tests: >>>>>> >>>>>> sun/net/www/http/HttpClient/MultiThreadTest.java (4 instances) >>>>>> java/net/Socket/LingerTest.java (2 instances) >>>>>> >>>>>> Why you also added 2 compiler tests? >>>>> >>>>> If you look at all the sightings in the bug report, you'll >>>>> see the two compiler tests listed in different entries. >>>>> The compiler test failures are intermittent, but the other >>>>> two happen in every tier2... >>>>> >>>>> Dan >>>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 8/6/18 9:49 AM, Daniel D. Daugherty wrote: >>>>>>> Greetings, >>>>>>> >>>>>>> I'm in the process of reducing the noise in the JDK12 CI so >>>>>>> I need a single (R)eviewer for the following fix: >>>>>>> >>>>>>> ???? JDK-8209018 ProblemList tests affected by JDK-8208690 >>>>>>> ???? https://bugs.openjdk.java.net/browse/JDK-8209018 >>>>>>> >>>>>>> Here's the diff: >>>>>>> >>>>>>> $ hg diff >>>>>>> diff -r c00451b67854 test/hotspot/jtreg/ProblemList.txt >>>>>>> --- a/test/hotspot/jtreg/ProblemList.txt??? Mon Aug 06 04:31:50 2018 -0400 >>>>>>> +++ b/test/hotspot/jtreg/ProblemList.txt??? Mon Aug 06 12:40:20 2018 -0400 >>>>>>> @@ -59,6 +59,9 @@ >>>>>>> >>>>>>> ??compiler/cpuflags/TestAESIntrinsicsOnSupportedConfig.java 8190680 generic-all >>>>>>> >>>>>>> +compiler/c1/Test4917709.java 8208690 generic-all >>>>>>> +compiler/runtime/cr6891750/Test6891750.java 8208690 generic-all >>>>>>> + >>>>>>> ??############################################################################# >>>>>>> >>>>>>> ??# :hotspot_gc >>>>>>> diff -r c00451b67854 test/jdk/ProblemList.txt >>>>>>> --- a/test/jdk/ProblemList.txt??? Mon Aug 06 04:31:50 2018 -0400 >>>>>>> +++ b/test/jdk/ProblemList.txt??? Mon Aug 06 12:40:20 2018 -0400 >>>>>>> @@ -559,6 +559,9 @@ >>>>>>> >>>>>>> ??java/net/DatagramSocket/SendDatagramToBadAddress.java 7143960 macosx-all >>>>>>> >>>>>>> +java/net/Socket/LingerTest.java 8208690 generic-all >>>>>>> +sun/net/www/http/HttpClient/MultiThreadTest.java 8208690 generic-all >>>>>>> + >>>>>>> ??############################################################################ >>>>>>> >>>>>>> ??# jdk_nio >>>>>>> >>>>>>> >>>>>>> Thanks, in advance, for any questions, comments or suggestions. >>>>>>> >>>>>>> Dan >>>>> >>> > From daniel.daugherty at oracle.com Mon Aug 6 17:55:14 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 6 Aug 2018 13:55:14 -0400 Subject: RFR(XXS): 8209018 ProblemList tests affected by JDK-8208690 In-Reply-To: <64ddc169-1cb1-4a31-c191-a2fc2c3b3945@oracle.com> References: <1a0be5f3-b5b5-f843-d99e-8539e5cd9f6a@oracle.com> <1ca06153-2545-4438-8e7b-b3381b5b0e51@oracle.com> <183bd7ae-313b-36ee-0da0-9f85c57f68b8@oracle.com> <64ddc169-1cb1-4a31-c191-a2fc2c3b3945@oracle.com> Message-ID: On 8/6/18 1:52 PM, Vladimir Kozlov wrote: > On 8/6/18 10:43 AM, Daniel D. Daugherty wrote: >> On 8/6/18 1:41 PM, Vladimir Kozlov wrote: >>> On 8/6/18 10:25 AM, Daniel D. Daugherty wrote: >>>> On 8/6/18 1:14 PM, Vladimir Kozlov wrote: >>>>> Okay, I read more about what happened. I think compiler tests >>>>> should be modified as David Holmes suggested (use /othervm): >>>>> >>>>> "Tests that don't manage their threads properly (ie ensure they >>>>> terminate at test end) should be run in othervm mode. jtreg can't >>>>> know how to make these threads terminate." >>>>> >>>>> Test4917709.java is closed test, not open. >>>> >>>> Oops. I'll have to clean that up. >>>> >>>> >>>>> File a separate bug and I will fix these 2 tests. >>>> >>>> So are you saying not to ProblemList these two tests and >>>> that I should file a new bug and you'll take care of it? >>> >>> Yes. >> >> Okay I'll do that. >> >> Can I list you as the (R)eviewer for ProblemListing these two tests? > > yes. Thanks! Dan > >> >> sun/net/www/http/HttpClient/MultiThreadTest.java >> java/net/Socket/LingerTest.java >> >> Dan >> >> >>> >>> Vladimir >>> >>>> >>>> Dan >>>> >>>> >>>>> >>>>> Regards, >>>>> Vladimir >>>>> >>>>> On 8/6/18 10:01 AM, Daniel D. Daugherty wrote: >>>>>> On 8/6/18 12:59 PM, Vladimir Kozlov wrote: >>>>>>> Hi Dan, >>>>>>> >>>>>>> 8208690 lists only next 2 tests: >>>>>>> >>>>>>> sun/net/www/http/HttpClient/MultiThreadTest.java (4 instances) >>>>>>> java/net/Socket/LingerTest.java (2 instances) >>>>>>> >>>>>>> Why you also added 2 compiler tests? >>>>>> >>>>>> If you look at all the sightings in the bug report, you'll >>>>>> see the two compiler tests listed in different entries. >>>>>> The compiler test failures are intermittent, but the other >>>>>> two happen in every tier2... >>>>>> >>>>>> Dan >>>>>> >>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 8/6/18 9:49 AM, Daniel D. Daugherty wrote: >>>>>>>> Greetings, >>>>>>>> >>>>>>>> I'm in the process of reducing the noise in the JDK12 CI so >>>>>>>> I need a single (R)eviewer for the following fix: >>>>>>>> >>>>>>>> ???? JDK-8209018 ProblemList tests affected by JDK-8208690 >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8209018 >>>>>>>> >>>>>>>> Here's the diff: >>>>>>>> >>>>>>>> $ hg diff >>>>>>>> diff -r c00451b67854 test/hotspot/jtreg/ProblemList.txt >>>>>>>> --- a/test/hotspot/jtreg/ProblemList.txt??? Mon Aug 06 04:31:50 >>>>>>>> 2018 -0400 >>>>>>>> +++ b/test/hotspot/jtreg/ProblemList.txt??? Mon Aug 06 12:40:20 >>>>>>>> 2018 -0400 >>>>>>>> @@ -59,6 +59,9 @@ >>>>>>>> >>>>>>>> ??compiler/cpuflags/TestAESIntrinsicsOnSupportedConfig.java >>>>>>>> 8190680 generic-all >>>>>>>> >>>>>>>> +compiler/c1/Test4917709.java 8208690 generic-all >>>>>>>> +compiler/runtime/cr6891750/Test6891750.java 8208690 generic-all >>>>>>>> + >>>>>>>> ??############################################################################# >>>>>>>> >>>>>>>> >>>>>>>> ??# :hotspot_gc >>>>>>>> diff -r c00451b67854 test/jdk/ProblemList.txt >>>>>>>> --- a/test/jdk/ProblemList.txt??? Mon Aug 06 04:31:50 2018 -0400 >>>>>>>> +++ b/test/jdk/ProblemList.txt??? Mon Aug 06 12:40:20 2018 -0400 >>>>>>>> @@ -559,6 +559,9 @@ >>>>>>>> >>>>>>>> ??java/net/DatagramSocket/SendDatagramToBadAddress.java 7143960 >>>>>>>> macosx-all >>>>>>>> >>>>>>>> +java/net/Socket/LingerTest.java 8208690 generic-all >>>>>>>> +sun/net/www/http/HttpClient/MultiThreadTest.java 8208690 >>>>>>>> generic-all >>>>>>>> + >>>>>>>> ??############################################################################ >>>>>>>> >>>>>>>> >>>>>>>> ??# jdk_nio >>>>>>>> >>>>>>>> >>>>>>>> Thanks, in advance, for any questions, comments or suggestions. >>>>>>>> >>>>>>>> Dan >>>>>> >>>> >> From daniel.daugherty at oracle.com Mon Aug 6 18:09:04 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 6 Aug 2018 14:09:04 -0400 Subject: RFR(XXS): 8209018 ProblemList tests affected by JDK-8208690 In-Reply-To: <1ca06153-2545-4438-8e7b-b3381b5b0e51@oracle.com> References: <1a0be5f3-b5b5-f843-d99e-8539e5cd9f6a@oracle.com> <1ca06153-2545-4438-8e7b-b3381b5b0e51@oracle.com> Message-ID: <48fad0d2-7d41-f621-d25a-570a357455f4@oracle.com> On 8/6/18 1:41 PM, Vladimir Kozlov wrote: > On 8/6/18 10:25 AM, Daniel D. Daugherty wrote: >> On 8/6/18 1:14 PM, Vladimir Kozlov wrote: >>> Okay, I read more about what happened. I think compiler tests should >>> be modified as David Holmes suggested (use /othervm): >>> >>> "Tests that don't manage their threads properly (ie ensure they >>> terminate at test end) should be run in othervm mode. jtreg can't >>> know how to make these threads terminate." >>> >>> Test4917709.java is closed test, not open. >> >> Oops. I'll have to clean that up. >> >> >>> File a separate bug and I will fix these 2 tests. >> >> So are you saying not to ProblemList these two tests and >> that I should file a new bug and you'll take care of it? > > Yes. New bug has been filed: ??? JDK-8209023 fix 2 compiler tests to avoid JDK-8208690 ??? https://bugs.openjdk.java.net/browse/JDK-8209023 and I have assigned it to you. Dan > > Vladimir > >> >> Dan >> >> >>> >>> Regards, >>> Vladimir >>> >>> On 8/6/18 10:01 AM, Daniel D. Daugherty wrote: >>>> On 8/6/18 12:59 PM, Vladimir Kozlov wrote: >>>>> Hi Dan, >>>>> >>>>> 8208690 lists only next 2 tests: >>>>> >>>>> sun/net/www/http/HttpClient/MultiThreadTest.java (4 instances) >>>>> java/net/Socket/LingerTest.java (2 instances) >>>>> >>>>> Why you also added 2 compiler tests? >>>> >>>> If you look at all the sightings in the bug report, you'll >>>> see the two compiler tests listed in different entries. >>>> The compiler test failures are intermittent, but the other >>>> two happen in every tier2... >>>> >>>> Dan >>>> >>>> >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 8/6/18 9:49 AM, Daniel D. Daugherty wrote: >>>>>> Greetings, >>>>>> >>>>>> I'm in the process of reducing the noise in the JDK12 CI so >>>>>> I need a single (R)eviewer for the following fix: >>>>>> >>>>>> ???? JDK-8209018 ProblemList tests affected by JDK-8208690 >>>>>> ???? https://bugs.openjdk.java.net/browse/JDK-8209018 >>>>>> >>>>>> Here's the diff: >>>>>> >>>>>> $ hg diff >>>>>> diff -r c00451b67854 test/hotspot/jtreg/ProblemList.txt >>>>>> --- a/test/hotspot/jtreg/ProblemList.txt??? Mon Aug 06 04:31:50 >>>>>> 2018 -0400 >>>>>> +++ b/test/hotspot/jtreg/ProblemList.txt??? Mon Aug 06 12:40:20 >>>>>> 2018 -0400 >>>>>> @@ -59,6 +59,9 @@ >>>>>> >>>>>> ??compiler/cpuflags/TestAESIntrinsicsOnSupportedConfig.java >>>>>> 8190680 generic-all >>>>>> >>>>>> +compiler/c1/Test4917709.java 8208690 generic-all >>>>>> +compiler/runtime/cr6891750/Test6891750.java 8208690 generic-all >>>>>> + >>>>>> ??############################################################################# >>>>>> >>>>>> >>>>>> ??# :hotspot_gc >>>>>> diff -r c00451b67854 test/jdk/ProblemList.txt >>>>>> --- a/test/jdk/ProblemList.txt??? Mon Aug 06 04:31:50 2018 -0400 >>>>>> +++ b/test/jdk/ProblemList.txt??? Mon Aug 06 12:40:20 2018 -0400 >>>>>> @@ -559,6 +559,9 @@ >>>>>> >>>>>> ??java/net/DatagramSocket/SendDatagramToBadAddress.java 7143960 >>>>>> macosx-all >>>>>> >>>>>> +java/net/Socket/LingerTest.java 8208690 generic-all >>>>>> +sun/net/www/http/HttpClient/MultiThreadTest.java 8208690 >>>>>> generic-all >>>>>> + >>>>>> ??############################################################################ >>>>>> >>>>>> >>>>>> ??# jdk_nio >>>>>> >>>>>> >>>>>> Thanks, in advance, for any questions, comments or suggestions. >>>>>> >>>>>> Dan >>>> >> From john.r.rose at oracle.com Mon Aug 6 18:12:55 2018 From: john.r.rose at oracle.com (John Rose) Date: Mon, 6 Aug 2018 11:12:55 -0700 Subject: Using C++11+ in hotspot In-Reply-To: References: <6D166068-9FA9-4B0B-A157-0CB109753F4C@oracle.com> Message-ID: <3959BC8E-F755-48B4-BE05-9BA13BC3E575@oracle.com> On Aug 5, 2018, at 8:30 AM, Martin Buchholz wrote: > > Thanks to whoever added the comment long ago. FTR I think it was Steffen Grarup. We were just learning about MT safety at the time. The copy conjoint/disjoint APIs were not yet in existence. I think they came around 2003, and Paul Hohensee's name is all over the SCCS history there. s 00008/00002/00762 d D 1.147 99/02/17 10:14:36 steffen 235 233 ? I 235 static inline void copy_table(address* from, address* to, int size) { // Copy non-overlapping tables. The copy has to occur word wise for MT safety. while (size-- > 0) *to++ = *from++; } Today, that loop should be recoded to use copy, and copy in turn needs to do whatever magic is required to force word-atomic access on non-atomic data. ? John From daniel.daugherty at oracle.com Mon Aug 6 19:45:26 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 6 Aug 2018 15:45:26 -0400 Subject: RFR(XXS): 8209020 ProblemList tests affected by JDK-8208778 In-Reply-To: <5e8af231-737b-2c48-cdce-f96e8f6d75c8@oracle.com> References: <30cbf1f5-39b1-2678-3580-ede678bb8568@oracle.com> <5e8af231-737b-2c48-cdce-f96e8f6d75c8@oracle.com> Message-ID: <8ab31d59-7a0d-9bab-3f0a-d0dd725f3c2b@oracle.com> Resending to a wider audience... I need a single (R)eviewer here... Dan On 8/6/18 1:51 PM, Daniel D. Daugherty wrote: > Greetings, > > Ioi spotted another test failing due to JDK-8208778 so > here's an updated diff: > > $ diff -c test/hotspot/jtreg/ProblemList.txt > test/hotspot/jtreg/ProblemList.txt.8209020 > *** test/hotspot/jtreg/ProblemList.txt??? 2018-08-06 > 12:34:55.483575758 -0400 > --- test/hotspot/jtreg/ProblemList.txt.8209020??? 2018-08-06 > 13:48:40.327951958 -0400 > *************** > *** 74,85 **** > --- 74,89 ---- > ? gc/stress/gclocker/TestGCLockerWithG1.java 8180622 generic-all > gc/survivorAlignment/TestPromotionFromSurvivorToTenuredAfterMinorGC.java > 8177765 generic-all > ? gc/stress/TestJNIBlockFullGC/TestJNIBlockFullGC.java 8192647 > generic-all > + gc/logging/TestUnifiedLoggingSwitchStress.java 8208778 macosx-x64 > > ############################################################################# > > > ? # :hotspot_runtime > > + runtime/appcds/javaldr/GCSharedStringsDuringDump.java 8208778 > macosx-x64 > + runtime/appcds/javaldr/GCDuringDump.java 8208778 macosx-x64 > ? runtime/CompressedOops/UseCompressedOops.java 8079353 generic-all > + runtime/RedefineTests/RedefineRunningMethods.java 8208778 macosx-x64 > ? runtime/SharedArchiveFile/SASymbolTableTest.java 8193639 solaris > > ############################################################################# > > > > Dan > > > On 8/6/18 12:59 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> I'm in the process of reducing the noise in the JDK12 CI so >> I need a single (R)eviewer for the following fix: >> >> ??? JDK-8209020 ProblemList tests affected by JDK-8208778 >> ??? https://bugs.openjdk.java.net/browse/JDK-8209020 >> >> Here's the diff: >> >> $ diff -c test/hotspot/jtreg/ProblemList.txt >> test/hotspot/jtreg/ProblemList.txt.8209020 >> *** test/hotspot/jtreg/ProblemList.txt??? 2018-08-06 >> 12:34:55.483575758 -0400 >> --- test/hotspot/jtreg/ProblemList.txt.8209020??? 2018-08-06 >> 12:58:22.518958677 -0400 >> *************** >> *** 79,85 **** >> --- 79,88 ---- >> >> ? # :hotspot_runtime >> >> + runtime/appcds/javaldr/GCSharedStringsDuringDump.java 8208778 >> macosx-x64 >> + runtime/appcds/javaldr/GCDuringDump.java 8208778 macosx-x64 >> ? runtime/CompressedOops/UseCompressedOops.java 8079353 generic-all >> + runtime/RedefineTests/RedefineRunningMethods.java 8208778 macosx-x64 >> ? runtime/SharedArchiveFile/SASymbolTableTest.java 8193639 solaris >> >> ############################################################################# >> >> >> >> Thanks, in advance, for any questions, comments or suggestions. >> >> Dan > From harold.seigel at oracle.com Mon Aug 6 20:08:30 2018 From: harold.seigel at oracle.com (Harold David Seigel) Date: Mon, 6 Aug 2018 16:08:30 -0400 Subject: RFR(XXS): 8209020 ProblemList tests affected by JDK-8208778 In-Reply-To: <8ab31d59-7a0d-9bab-3f0a-d0dd725f3c2b@oracle.com> References: <30cbf1f5-39b1-2678-3580-ede678bb8568@oracle.com> <5e8af231-737b-2c48-cdce-f96e8f6d75c8@oracle.com> <8ab31d59-7a0d-9bab-3f0a-d0dd725f3c2b@oracle.com> Message-ID: Looks good! Harold On 8/6/2018 3:45 PM, Daniel D. Daugherty wrote: > Resending to a wider audience... > > I need a single (R)eviewer here... > > Dan > > > On 8/6/18 1:51 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> Ioi spotted another test failing due to JDK-8208778 so >> here's an updated diff: >> >> $ diff -c test/hotspot/jtreg/ProblemList.txt >> test/hotspot/jtreg/ProblemList.txt.8209020 >> *** test/hotspot/jtreg/ProblemList.txt??? 2018-08-06 >> 12:34:55.483575758 -0400 >> --- test/hotspot/jtreg/ProblemList.txt.8209020??? 2018-08-06 >> 13:48:40.327951958 -0400 >> *************** >> *** 74,85 **** >> --- 74,89 ---- >> ? gc/stress/gclocker/TestGCLockerWithG1.java 8180622 generic-all >> gc/survivorAlignment/TestPromotionFromSurvivorToTenuredAfterMinorGC.java >> 8177765 generic-all >> ? gc/stress/TestJNIBlockFullGC/TestJNIBlockFullGC.java 8192647 >> generic-all >> + gc/logging/TestUnifiedLoggingSwitchStress.java 8208778 macosx-x64 >> >> ############################################################################# >> >> >> ? # :hotspot_runtime >> >> + runtime/appcds/javaldr/GCSharedStringsDuringDump.java 8208778 >> macosx-x64 >> + runtime/appcds/javaldr/GCDuringDump.java 8208778 macosx-x64 >> ? runtime/CompressedOops/UseCompressedOops.java 8079353 generic-all >> + runtime/RedefineTests/RedefineRunningMethods.java 8208778 macosx-x64 >> ? runtime/SharedArchiveFile/SASymbolTableTest.java 8193639 solaris >> >> ############################################################################# >> >> >> >> Dan >> >> >> On 8/6/18 12:59 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I'm in the process of reducing the noise in the JDK12 CI so >>> I need a single (R)eviewer for the following fix: >>> >>> ??? JDK-8209020 ProblemList tests affected by JDK-8208778 >>> ??? https://bugs.openjdk.java.net/browse/JDK-8209020 >>> >>> Here's the diff: >>> >>> $ diff -c test/hotspot/jtreg/ProblemList.txt >>> test/hotspot/jtreg/ProblemList.txt.8209020 >>> *** test/hotspot/jtreg/ProblemList.txt??? 2018-08-06 >>> 12:34:55.483575758 -0400 >>> --- test/hotspot/jtreg/ProblemList.txt.8209020??? 2018-08-06 >>> 12:58:22.518958677 -0400 >>> *************** >>> *** 79,85 **** >>> --- 79,88 ---- >>> >>> ? # :hotspot_runtime >>> >>> + runtime/appcds/javaldr/GCSharedStringsDuringDump.java 8208778 >>> macosx-x64 >>> + runtime/appcds/javaldr/GCDuringDump.java 8208778 macosx-x64 >>> ? runtime/CompressedOops/UseCompressedOops.java 8079353 generic-all >>> + runtime/RedefineTests/RedefineRunningMethods.java 8208778 macosx-x64 >>> ? runtime/SharedArchiveFile/SASymbolTableTest.java 8193639 solaris >>> >>> ############################################################################# >>> >>> >>> >>> Thanks, in advance, for any questions, comments or suggestions. >>> >>> Dan >> > From daniel.daugherty at oracle.com Mon Aug 6 20:09:32 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 6 Aug 2018 16:09:32 -0400 Subject: RFR(XXS): 8209020 ProblemList tests affected by JDK-8208778 In-Reply-To: References: <30cbf1f5-39b1-2678-3580-ede678bb8568@oracle.com> <5e8af231-737b-2c48-cdce-f96e8f6d75c8@oracle.com> <8ab31d59-7a0d-9bab-3f0a-d0dd725f3c2b@oracle.com> Message-ID: Thanks Harold! Dan On 8/6/18 4:08 PM, Harold David Seigel wrote: > Looks good! > > Harold > > > On 8/6/2018 3:45 PM, Daniel D. Daugherty wrote: >> Resending to a wider audience... >> >> I need a single (R)eviewer here... >> >> Dan >> >> >> On 8/6/18 1:51 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> Ioi spotted another test failing due to JDK-8208778 so >>> here's an updated diff: >>> >>> $ diff -c test/hotspot/jtreg/ProblemList.txt >>> test/hotspot/jtreg/ProblemList.txt.8209020 >>> *** test/hotspot/jtreg/ProblemList.txt??? 2018-08-06 >>> 12:34:55.483575758 -0400 >>> --- test/hotspot/jtreg/ProblemList.txt.8209020??? 2018-08-06 >>> 13:48:40.327951958 -0400 >>> *************** >>> *** 74,85 **** >>> --- 74,89 ---- >>> ? gc/stress/gclocker/TestGCLockerWithG1.java 8180622 generic-all >>> gc/survivorAlignment/TestPromotionFromSurvivorToTenuredAfterMinorGC.java >>> 8177765 generic-all >>> ? gc/stress/TestJNIBlockFullGC/TestJNIBlockFullGC.java 8192647 >>> generic-all >>> + gc/logging/TestUnifiedLoggingSwitchStress.java 8208778 macosx-x64 >>> >>> ############################################################################# >>> >>> >>> ? # :hotspot_runtime >>> >>> + runtime/appcds/javaldr/GCSharedStringsDuringDump.java 8208778 >>> macosx-x64 >>> + runtime/appcds/javaldr/GCDuringDump.java 8208778 macosx-x64 >>> ? runtime/CompressedOops/UseCompressedOops.java 8079353 generic-all >>> + runtime/RedefineTests/RedefineRunningMethods.java 8208778 macosx-x64 >>> ? runtime/SharedArchiveFile/SASymbolTableTest.java 8193639 solaris >>> >>> ############################################################################# >>> >>> >>> >>> Dan >>> >>> >>> On 8/6/18 12:59 PM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> I'm in the process of reducing the noise in the JDK12 CI so >>>> I need a single (R)eviewer for the following fix: >>>> >>>> ??? JDK-8209020 ProblemList tests affected by JDK-8208778 >>>> ??? https://bugs.openjdk.java.net/browse/JDK-8209020 >>>> >>>> Here's the diff: >>>> >>>> $ diff -c test/hotspot/jtreg/ProblemList.txt >>>> test/hotspot/jtreg/ProblemList.txt.8209020 >>>> *** test/hotspot/jtreg/ProblemList.txt??? 2018-08-06 >>>> 12:34:55.483575758 -0400 >>>> --- test/hotspot/jtreg/ProblemList.txt.8209020??? 2018-08-06 >>>> 12:58:22.518958677 -0400 >>>> *************** >>>> *** 79,85 **** >>>> --- 79,88 ---- >>>> >>>> ? # :hotspot_runtime >>>> >>>> + runtime/appcds/javaldr/GCSharedStringsDuringDump.java 8208778 >>>> macosx-x64 >>>> + runtime/appcds/javaldr/GCDuringDump.java 8208778 macosx-x64 >>>> ? runtime/CompressedOops/UseCompressedOops.java 8079353 generic-all >>>> + runtime/RedefineTests/RedefineRunningMethods.java 8208778 macosx-x64 >>>> ? runtime/SharedArchiveFile/SASymbolTableTest.java 8193639 solaris >>>> >>>> ############################################################################# >>>> >>>> >>>> >>>> Thanks, in advance, for any questions, comments or suggestions. >>>> >>>> Dan >>> >> > From david.holmes at oracle.com Mon Aug 6 21:17:01 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 7 Aug 2018 07:17:01 +1000 Subject: RFR (XXS): 8208672: Enable -Wreorder in make files In-Reply-To: References: Message-ID: Hi Thomas, On 6/08/2018 10:38 PM, Thomas Schatzl wrote: > Hi David, > > On Fri, 2018-08-03 at 10:20 +1000, David Holmes wrote: >> Hi Thomas, >> >> On 2/08/2018 7:14 PM, Thomas Schatzl wrote: >>> Hi all, >>> >>> there have been several suggestions to try to fix the Hotspot >>> code to allow us to enable -Wreorder in the Hotspot sources. >>> This should make problems due to use-before-initialization much >>> more obvious. >>> >>> This change enables -Wreorder for gcc and clang. >> >> For Windows (VS2017+) see: >> >> https://docs.microsoft.com/en-us/cpp/error-messages/compiler-warnings >> /c5038 >> >> Otherwise change seems okay. >> > > Thanks! > > http://cr.openjdk.java.net/~tschatzl/8208672/webrev.0_to_1 (diff) > http://cr.openjdk.java.net/~tschatzl/8208672/webrev.1 (full) > > I verified that all our platforms (including Windows) still build. I think the Windows change needs to be based on the compiler version used as, from what I read, the flag only exists in VS2017. David > Thanks, > Thomas > From david.holmes at oracle.com Tue Aug 7 00:45:57 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 7 Aug 2018 10:45:57 +1000 Subject: Using C++11+ in hotspot In-Reply-To: References: <6D166068-9FA9-4B0B-A157-0CB109753F4C@oracle.com> Message-ID: On 6/08/2018 6:16 PM, Andrew Haley wrote: > On 08/05/2018 04:30 PM, Martin Buchholz wrote: >> Here's one example of code that actually did go wrong with Google's latest >> internal toolchain, because the copy was not in fact word-atomic. Thanks >> to whoever added the comment long ago. >> >> static inline void copy_table(address* from, address* to, int size) { >> // Copy non-overlapping tables. The copy has to occur word wise for MT >> safety. >> while (size-- > 0) *to++ = *from++; >> } >> >> Recommendation: target C++11 for jdk12; > I don't think that helps. There's no legal way AFAICS to force an atomic > access to non-atomic types in C++11. I would agree. We implicitly rely on compilers doing the obvious/natural thing as long as the variables are suitable aligned. We're outside the language here with regards to "atomic access".** David From martinrb at google.com Tue Aug 7 04:54:11 2018 From: martinrb at google.com (Martin Buchholz) Date: Mon, 6 Aug 2018 21:54:11 -0700 Subject: Using C++11+ in hotspot In-Reply-To: References: <6D166068-9FA9-4B0B-A157-0CB109753F4C@oracle.com> Message-ID: On Mon, Aug 6, 2018 at 1:16 AM, Andrew Haley wrote: > On 08/05/2018 04:30 PM, Martin Buchholz wrote: > > Here's one example of code that actually did go wrong with Google's > latest > > internal toolchain, because the copy was not in fact word-atomic. Thanks > > to whoever added the comment long ago. > > > > static inline void copy_table(address* from, address* to, int size) { > > // Copy non-overlapping tables. The copy has to occur word wise for MT > > safety. > > while (size-- > 0) *to++ = *from++; > > } > > > > Recommendation: target C++11 for jdk12; > I don't think that helps. There's no legal way AFAICS to force an atomic > access to non-atomic types in C++11. > Ohh... perhaps that's the idea behind atomic_ref https://en.cppreference.com/w/cpp/atomic/atomic_ref we only have to wait one more decade for that to become available. I don't know what is actually being copied here, but can't the underlying type be atomic ? From john.r.rose at oracle.com Tue Aug 7 05:48:46 2018 From: john.r.rose at oracle.com (John Rose) Date: Mon, 6 Aug 2018 22:48:46 -0700 Subject: Using C++11+ in hotspot In-Reply-To: References: <6D166068-9FA9-4B0B-A157-0CB109753F4C@oracle.com> Message-ID: On Aug 6, 2018, at 9:54 PM, Martin Buchholz wrote: > > I don't know what is actually being copied here, but can't the underlying > type be atomic ? Yes, if we are allowed to cast some random sequence of metadata words to atomic[]. If that's the magic incantation to get to the hardware's atomicity primitives, OK. I suspect a more direct technique may be needed, such as assembly code stubs. ? John From martinrb at google.com Tue Aug 7 06:26:48 2018 From: martinrb at google.com (Martin Buchholz) Date: Mon, 6 Aug 2018 23:26:48 -0700 Subject: Using C++11+ in hotspot In-Reply-To: <3959BC8E-F755-48B4-BE05-9BA13BC3E575@oracle.com> References: <6D166068-9FA9-4B0B-A157-0CB109753F4C@oracle.com> <3959BC8E-F755-48B4-BE05-9BA13BC3E575@oracle.com> Message-ID: On Mon, Aug 6, 2018 at 11:12 AM, John Rose wrote: > On Aug 5, 2018, at 8:30 AM, Martin Buchholz wrote: > > > Thanks to whoever added the comment long ago. > > > FTR I think it was Steffen Grarup. We were just learning about MT safety > at the time. > The copy conjoint/disjoint APIs were not yet in existence. I think they > came around > 2003, and Paul Hohensee's name is all over the SCCS history there. > > s 00008/00002/00762 > d D 1.147 99/02/17 10:14:36 steffen 235 233 > ? > I 235 > static inline void copy_table(address* from, address* to, int size) { > // Copy non-overlapping tables. The copy has to occur word wise for MT > safety. > while (size-- > 0) *to++ = *from++; > } > > Today, that loop should be recoded to use copy, and copy in turn needs to > do whatever magic is required to force word-atomic access on non-atomic > data. > > That loop copies address*, while pd_disjoint_words_atomic copies HeapWord, so these are not compatible out of the box. We could have atomic relaxed copies like below. Using compiler builtins also avoids the problem of the underlying type not being declared atomic<>, and is ISA-independent. OTOH maybe we always want that loop compiled to REP MOVSQ on x64. template static ALWAYSINLINE void copy_atomic_relaxed(const T* from, T* to) { T val; __atomic_load(from, &val, __ATOMIC_RELAXED); __atomic_store(to, &val, __ATOMIC_RELAXED); } static void pd_disjoint_words_atomic(const HeapWord* from, HeapWord* to, size_t count) { #ifdef AMD64 switch (count) { case 8: copy_atomic_relaxed(from + 7, to + 7); case 7: copy_atomic_relaxed(from + 6, to + 6); case 6: copy_atomic_relaxed(from + 5, to + 5); case 5: copy_atomic_relaxed(from + 4, to + 4); case 4: copy_atomic_relaxed(from + 3, to + 3); case 3: copy_atomic_relaxed(from + 2, to + 2); case 2: copy_atomic_relaxed(from + 1, to + 1); case 1: copy_atomic_relaxed(from + 0, to + 0); case 0: break; default: while (count-- > 0) { copy_atomic_relaxed(from++, to++); } break; } From Alan.Bateman at oracle.com Tue Aug 7 06:29:14 2018 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 7 Aug 2018 07:29:14 +0100 Subject: RFR(XXS): 8209018 ProblemList tests affected by JDK-8208690 In-Reply-To: References: Message-ID: <7c11bed4-e23d-abe2-b9ba-27fb6777d062@oracle.com> On 06/08/2018 17:49, Daniel D. Daugherty wrote: > : > > +java/net/Socket/LingerTest.java 8208690 generic-all > +sun/net/www/http/HttpClient/MultiThreadTest.java 8208690 generic-all > + > ?############################################################################ > Can these tests be changed to /othervm instead of excluding them? -Alan From thomas.schatzl at oracle.com Tue Aug 7 09:34:58 2018 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 07 Aug 2018 11:34:58 +0200 Subject: RFR (XXS): 8208672: Enable -Wreorder in make files In-Reply-To: References: Message-ID: <54931f694a70d0c215859697eb4083019ae7a3fb.camel@oracle.com> Hi David, On Tue, 2018-08-07 at 07:17 +1000, David Holmes wrote: > Hi Thomas, > > On 6/08/2018 10:38 PM, Thomas Schatzl wrote: > > Hi David, > > > > On Fri, 2018-08-03 at 10:20 +1000, David Holmes wrote: > > > Hi Thomas, > > > > > > On 2/08/2018 7:14 PM, Thomas Schatzl wrote: > > > > Hi all, > > > > > > > > there have been several suggestions to try to fix the > > > > Hotspot code to allow us to enable -Wreorder in the Hotspot > > > > sources. > > > > This should make problems due to use-before-initialization much > > > > more obvious. > > > > > > > > This change enables -Wreorder for gcc and clang. > > > > > > For Windows (VS2017+) see: > > > > > > https://docs.microsoft.com/en-us/cpp/error-messages/compiler- > > > warnings /c5038 > > > > > > Otherwise change seems okay. > > > > > > > Thanks! > > > > http://cr.openjdk.java.net/~tschatzl/8208672/webrev.0_to_1 (diff) > > http://cr.openjdk.java.net/~tschatzl/8208672/webrev.1 (full) > > > > I verified that all our platforms (including Windows) still build. > > I think the Windows change needs to be based on the compiler version > used as, from what I read, the flag only exists in VS2017. jdk11 official compiler is VS2017 so I figured it would not be that much of a problem. Another reason for my thinking is that MSVC 2013 does not implement some interesting C++11 features anyway so we might be forced to drop support for it soon (and the situation is of course worse if we upgrade to C++14). I looked a bit at the makefile and conditionalizing this on VS2017 (or checking only whether VS2013 let it slide, i.e. give an "unsupported option" warning but continue anyway because I would need to setup a Windows dev environment somewhere) would take me a lot of time. Would it be possible to skip -Werror support for Visual Studio now and try to fix this in a later enhancement? Thanks, Thomas From david.holmes at oracle.com Tue Aug 7 10:08:43 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 7 Aug 2018 20:08:43 +1000 Subject: RFR (XXS): 8208672: Enable -Wreorder in make files In-Reply-To: <54931f694a70d0c215859697eb4083019ae7a3fb.camel@oracle.com> References: <54931f694a70d0c215859697eb4083019ae7a3fb.camel@oracle.com> Message-ID: <3a6b32f3-e4d9-9804-23f4-cfb5515a0ce9@oracle.com> Hi Thomas, On 7/08/2018 7:34 PM, Thomas Schatzl wrote: > Hi David, > > On Tue, 2018-08-07 at 07:17 +1000, David Holmes wrote: >> Hi Thomas, >> >> On 6/08/2018 10:38 PM, Thomas Schatzl wrote: >>> Hi David, >>> >>> On Fri, 2018-08-03 at 10:20 +1000, David Holmes wrote: >>>> Hi Thomas, >>>> >>>> On 2/08/2018 7:14 PM, Thomas Schatzl wrote: >>>>> Hi all, >>>>> >>>>> there have been several suggestions to try to fix the >>>>> Hotspot code to allow us to enable -Wreorder in the Hotspot >>>>> sources. >>>>> This should make problems due to use-before-initialization much >>>>> more obvious. >>>>> >>>>> This change enables -Wreorder for gcc and clang. >>>> >>>> For Windows (VS2017+) see: >>>> >>>> https://docs.microsoft.com/en-us/cpp/error-messages/compiler- >>>> warnings /c5038 >>>> >>>> Otherwise change seems okay. >>>> >>> >>> Thanks! >>> >>> http://cr.openjdk.java.net/~tschatzl/8208672/webrev.0_to_1 (diff) >>> http://cr.openjdk.java.net/~tschatzl/8208672/webrev.1 (full) >>> >>> I verified that all our platforms (including Windows) still build. >> >> I think the Windows change needs to be based on the compiler version >> used as, from what I read, the flag only exists in VS2017. > > jdk11 official compiler is VS2017 so I figured it would not be that > much of a problem. Right now the build supports a range of compilers for the community: ################################################################################ # The order of these defines the priority by which we try to find them. VALID_VS_VERSIONS="2017 2013 2015 2012 2010" > Another reason for my thinking is that MSVC 2013 does not implement > some interesting C++11 features anyway so we might be forced to drop > support for it soon (and the situation is of course worse if we upgrade > to C++14). If that happens we'd have to deal with it sure ... > I looked a bit at the makefile and conditionalizing this on VS2017 (or > checking only whether VS2013 let it slide, i.e. give an "unsupported > option" warning but continue anyway because I would need to setup a > Windows dev environment somewhere) would take me a lot of time. Hoping the build folk will jump in as this should be pretty straight-forward I think - just a question of knowing what VERSION variable to test. > Would it be possible to skip -Werror support for Visual Studio now and > try to fix this in a later enhancement? Sure. Just a pity as it will be 10x as much work to add later by itself. Thanks, David ----- > Thanks, > Thomas > From matthias.baesken at sap.com Tue Aug 7 10:46:34 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 7 Aug 2018 10:46:34 +0000 Subject: comparing this to NULL in HS - code - was : 8208604: Metadata::print_value_string() compares 'this' to NULL Message-ID: <4195e713e8c44b9c86e4f99180471a04@sap.com> Hello, seems we have still quite a few places in the HS C++ codebase where "this" is compared to NULL. Recently 8208604: Metadata::print_value_string() compares 'this' to NULL : https://bugs.openjdk.java.net/browse/JDK-8208604 fixed one place and stated : "The compiler is free to elide this test, since (this == NULL) can never be true; applying an ordinary member function to NULL invokes undefined behavior. " Should we change the other checks as well ? Thanks, Matthias I found these checks : jdk/src/hotspot/share/adlc/formssel.cpp 1727bool Opcode::print_opcode(FILE *fp, Opcode::opcode_type desired_opcode) { 1728 // Default values previously provided by MachNode::primary()... 1729 const char *description = NULL; 1730 const char *value = NULL; 1731 // Check if user provided any opcode definitions 1732 if( this != NULL ) { 3417void MatchNode::count_instr_names( Dict &names ) { 3418 if( this == NULL ) return; jdk/src/hotspot/share/opto/chaitin.cpp 2147char *PhaseChaitin::dump_register( const Node *n, char *buf ) const { 2148 if( this == NULL ) { // Not got anything? 2149 sprintf(buf,"N%d",n->_idx); // Then use Node index 2150 } else if( _node_regs ) { jdk/src/hotspot/share/asm/codeBuffer.cpp 1241void CodeBuffer::print() { 1242 if (this == NULL) { 1243 tty->print_cr("NULL CodeBuffer pointer"); jdk/src/hotspot/share/runtime/perfData.cpp 593PerfData* PerfDataList::find_by_name(const char* name) { 594 595 // if add_item hasn't been called the list won't be initialized 596 if (this == NULL) 597 return NULL; jdk/src/hotspot/share/libadt/set.cpp 58char *Set::setstr() const 59{ 60 if( this == NULL ) return os::strdup("{no set}"); jdk/src/hotspot/share/oops/symbol.cpp 295void Symbol::print_on(outputStream* st) const { 296 if (this == NULL) { 297 st->print_cr("NULL"); 308void Symbol::print_value_on(outputStream* st) const { 309 if (this == NULL) { 310 st->print("NULL"); From daniel.daugherty at oracle.com Tue Aug 7 12:22:35 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 7 Aug 2018 08:22:35 -0400 Subject: RFR(XXS): 8209018 ProblemList tests affected by JDK-8208690 In-Reply-To: <7c11bed4-e23d-abe2-b9ba-27fb6777d062@oracle.com> References: <7c11bed4-e23d-abe2-b9ba-27fb6777d062@oracle.com> Message-ID: <903c8fbc-9a0b-f9e3-1f91-b3448e552b92@oracle.com> On 8/7/18 2:29 AM, Alan Bateman wrote: > On 06/08/2018 17:49, Daniel D. Daugherty wrote: >> : >> >> +java/net/Socket/LingerTest.java 8208690 generic-all >> +sun/net/www/http/HttpClient/MultiThreadTest.java 8208690 generic-all >> + >> ?############################################################################ >> > Can these tests be changed to /othervm instead of excluding them? > > -Alan Maybe... I don't know if that would keep the tests from failing or not. With 100+ of these failures in Mach5, you can see why I was getting tired of it. This is only until Jon's fix for: ??? https://bugs.openjdk.java.net/browse/CODETOOLS-7902259 gets promoted and we switch JDK12 to use it. I have a sub-task to re-enable the tests when that happens. Dan From aph at redhat.com Tue Aug 7 14:00:02 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 7 Aug 2018 15:00:02 +0100 Subject: Using C++11+ in hotspot In-Reply-To: References: <6D166068-9FA9-4B0B-A157-0CB109753F4C@oracle.com> Message-ID: <347ce2b1-550b-112c-6a76-3c1657f48a7b@redhat.com> On 08/07/2018 06:48 AM, John Rose wrote: > On Aug 6, 2018, at 9:54 PM, Martin Buchholz wrote: >> >> I don't know what is actually being copied here, but can't the underlying >> type be atomic ? > > Yes, if we are allowed to cast some random sequence of metadata > words to atomic[]. We're not. Well, we sort-of are because we use -fno-strict-aliasing, but that's not standard C++11. Do we care? :-) GCC builtins do what we need when we're using GCC, but then we don't need C++11. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From harold.seigel at oracle.com Tue Aug 7 14:02:55 2018 From: harold.seigel at oracle.com (Harold David Seigel) Date: Tue, 7 Aug 2018 10:02:55 -0400 Subject: comparing this to NULL in HS - code - was : 8208604: Metadata::print_value_string() compares 'this' to NULL In-Reply-To: <4195e713e8c44b9c86e4f99180471a04@sap.com> References: <4195e713e8c44b9c86e4f99180471a04@sap.com> Message-ID: <6e964aa7-20b9-c614-2d4a-9db5aeb7bcf6@oracle.com> Hi Matthias, I created https://bugs.openjdk.java.net/browse/JDK-8209079 to track this issue. Thanks, Harold On 8/7/2018 6:46 AM, Baesken, Matthias wrote: > Hello, > > seems we have still quite a few places in the HS C++ codebase where "this" is compared to NULL. > > Recently 8208604: Metadata::print_value_string() compares 'this' to NULL : > https://bugs.openjdk.java.net/browse/JDK-8208604 > fixed one place and stated : > "The compiler is free to elide this test, since (this == NULL) can never be true; applying an ordinary member function to NULL invokes undefined behavior." > > > Should we change the other checks as well ? > > Thanks, Matthias > > I found these checks : > > > jdk/src/hotspot/share/adlc/formssel.cpp > > 1727bool Opcode::print_opcode(FILE *fp, Opcode::opcode_type desired_opcode) { > 1728 // Default values previously provided by MachNode::primary()... > 1729 const char *description = NULL; > 1730 const char *value = NULL; > 1731 // Check if user provided any opcode definitions > 1732 if( this != NULL ) { > > > 3417void MatchNode::count_instr_names( Dict &names ) { > 3418 if( this == NULL ) return; > > > jdk/src/hotspot/share/opto/chaitin.cpp > > 2147char *PhaseChaitin::dump_register( const Node *n, char *buf ) const { > 2148 if( this == NULL ) { // Not got anything? > 2149 sprintf(buf,"N%d",n->_idx); // Then use Node index > 2150 } else if( _node_regs ) { > > > jdk/src/hotspot/share/asm/codeBuffer.cpp > > 1241void CodeBuffer::print() { > 1242 if (this == NULL) { > 1243 tty->print_cr("NULL CodeBuffer pointer"); > > jdk/src/hotspot/share/runtime/perfData.cpp > > 593PerfData* PerfDataList::find_by_name(const char* name) { > 594 > 595 // if add_item hasn't been called the list won't be initialized > 596 if (this == NULL) > 597 return NULL; > > jdk/src/hotspot/share/libadt/set.cpp > > 58char *Set::setstr() const > 59{ > 60 if( this == NULL ) return os::strdup("{no set}"); > > > jdk/src/hotspot/share/oops/symbol.cpp > > 295void Symbol::print_on(outputStream* st) const { > 296 if (this == NULL) { > 297 st->print_cr("NULL"); > > 308void Symbol::print_value_on(outputStream* st) const { > 309 if (this == NULL) { > 310 st->print("NULL"); From mikael.vidstedt at oracle.com Tue Aug 7 18:36:40 2018 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 7 Aug 2018 11:36:40 -0700 Subject: Using C++11+ in hotspot In-Reply-To: References: <6D166068-9FA9-4B0B-A157-0CB109753F4C@oracle.com> <3959BC8E-F755-48B4-BE05-9BA13BC3E575@oracle.com> Message-ID: In utilities/copy.[ch]pp there?s Copy::conjoint_copy and its close friends which does support different element sizes, and which promises to not tear the words/elements (if the underlying implementation doesn?t do the right thing it needs to be fixed). It doesn?t currently allow for configuring/customizing memory ordering requirements though, and If ?extreme? performance is required there may well be some additional specialization needed as well. Cheers, Mikael > On Aug 6, 2018, at 11:26 PM, Martin Buchholz wrote: > > > > On Mon, Aug 6, 2018 at 11:12 AM, John Rose > wrote: > On Aug 5, 2018, at 8:30 AM, Martin Buchholz > wrote: >> >> Thanks to whoever added the comment long ago. > > FTR I think it was Steffen Grarup. We were just learning about MT safety at the time. > The copy conjoint/disjoint APIs were not yet in existence. I think they came around > 2003, and Paul Hohensee's name is all over the SCCS history there. > > s 00008/00002/00762 > d D 1.147 99/02/17 10:14:36 steffen 235 233 > ? > I 235 > static inline void copy_table(address* from, address* to, int size) { > // Copy non-overlapping tables. The copy has to occur word wise for MT safety. > while (size-- > 0) *to++ = *from++; > } > > Today, that loop should be recoded to use copy, and copy in turn needs to > do whatever magic is required to force word-atomic access on non-atomic data. > > > That loop copies address*, while pd_disjoint_words_atomic copies HeapWord, so these are not compatible out of the box. > > We could have atomic relaxed copies like below. Using compiler builtins also avoids the problem of the underlying type not being declared atomic<>, and is ISA-independent. OTOH maybe we always want that loop compiled to REP MOVSQ on x64. > > > template > static ALWAYSINLINE void copy_atomic_relaxed(const T* from, T* to) { > T val; > __atomic_load(from, &val, __ATOMIC_RELAXED); > __atomic_store(to, &val, __ATOMIC_RELAXED); > } > > static void pd_disjoint_words_atomic(const HeapWord* from, HeapWord* to, size_t count) { > #ifdef AMD64 > switch (count) { > case 8: copy_atomic_relaxed(from + 7, to + 7); > case 7: copy_atomic_relaxed(from + 6, to + 6); > case 6: copy_atomic_relaxed(from + 5, to + 5); > case 5: copy_atomic_relaxed(from + 4, to + 4); > case 4: copy_atomic_relaxed(from + 3, to + 3); > case 3: copy_atomic_relaxed(from + 2, to + 2); > case 2: copy_atomic_relaxed(from + 1, to + 1); > case 1: copy_atomic_relaxed(from + 0, to + 0); > case 0: break; > default: > while (count-- > 0) { > copy_atomic_relaxed(from++, to++); > } > break; > } From kim.barrett at oracle.com Tue Aug 7 20:28:14 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 7 Aug 2018 16:28:14 -0400 Subject: RFR (XL): 8208669: GC changes to allow enabling -Wreorder In-Reply-To: References: <1fe17e13a5aeb583f05061c1cab6b55b7bdd4279.camel@oracle.com> Message-ID: <4F61B584-219F-4EDE-8009-B2C5BBBD6460@oracle.com> > On Aug 6, 2018, at 8:35 AM, Thomas Schatzl wrote: >> src/hotspot/share/gc/shared/workgroup.cpp >> 190 MutexGangTaskDispatcher() >> >> I don't really like how this one ended up being re-formated, >> especially having the (empty) constructor body way far over to the >> right. Also, aligning the colon with the constructor name seems >> pretty unusual. > > You don't believe how many styles I observed in these set of patches? I know! > I tried to improve it. > > http://cr.openjdk.java.net/~tschatzl/8208669/webrev.1 (full) > http://cr.openjdk.java.net/~tschatzl/8208669/webrev.0_to_1 (diff) Looks good. From igor.ignatyev at oracle.com Tue Aug 7 21:19:03 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 7 Aug 2018 14:19:03 -0700 Subject: [11] RFR(S) : 8205687 : TimeoutHandler generates huge core files Message-ID: <4FA256FB-11DE-4C41-B4EE-4FCE3B7B1353@oracle.com> http://cr.openjdk.java.net/~iignatyev//8205687/webrev.00/index.html > 18 lines changed: 3 ins; 5 del; 10 mod; Hi all, could you please review this small fix for TimeoutHandler? gcore dumps non committed memory, which is a problem when JVM is run w/ ZGC or in other configurations where memory is reserved but not committed. the fix replaces invocation of gcore w/ 'kill -ABRT'. as kill has to be the last command run by TimeoutHandler, I've changed jdk.test.failurehandler.ToolKit to run action after we get a list of the process's children and also changed GathererFactory to run "common" part before os-specific part. NB 'kill' will generate core file only if a host has appropriate core file limit and core file handling settings, therefore you might observe that core files aren't generated if your hosts aren't set up correspondingly. JBS: https://bugs.openjdk.java.net/browse/JDK-8205687 webrev: http://cr.openjdk.java.net/~iignatyev//8205687/webrev.00/index.html Thanks, -- Igor From david.holmes at oracle.com Wed Aug 8 04:00:26 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 8 Aug 2018 14:00:26 +1000 Subject: [11] RFR(S) : 8205687 : TimeoutHandler generates huge core files In-Reply-To: <4FA256FB-11DE-4C41-B4EE-4FCE3B7B1353@oracle.com> References: <4FA256FB-11DE-4C41-B4EE-4FCE3B7B1353@oracle.com> Message-ID: Hi Igor, This all seems okay. However we probably need to check that the people operating their own build/test farms are okay with this change. Don't forget to update copyright years. Minor comment below ... On 8/08/2018 7:19 AM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8205687/webrev.00/index.html >> 18 lines changed: 3 ins; 5 del; 10 mod; > > Hi all, > > could you please review this small fix for TimeoutHandler? gcore dumps non committed memory, which is a problem when JVM is run w/ ZGC or in other configurations where memory is reserved but not committed. the fix replaces invocation of gcore w/ 'kill -ABRT'. as kill has to be the last command run by TimeoutHandler, I've changed jdk.test.failurehandler.ToolKit to run action after we get a list of the process's children and also changed GathererFactory to run "common" part before os-specific part. Can you add a comment in GathererFactory to explain that as well please. Thanks, David > > NB 'kill' will generate core file only if a host has appropriate core file limit and core file handling settings, therefore you might observe that core files aren't generated if your hosts aren't set up correspondingly. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8205687 > webrev: http://cr.openjdk.java.net/~iignatyev//8205687/webrev.00/index.html > > Thanks, > -- Igor > From erik.osterlund at oracle.com Wed Aug 8 06:51:06 2018 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Wed, 8 Aug 2018 08:51:06 +0200 Subject: Using C++11+ in hotspot In-Reply-To: <347ce2b1-550b-112c-6a76-3c1657f48a7b@redhat.com> References: <6D166068-9FA9-4B0B-A157-0CB109753F4C@oracle.com> <347ce2b1-550b-112c-6a76-3c1657f48a7b@redhat.com> Message-ID: Hi Andrew, This question is very important and deserves highlighting. I have been thinking for some time that there ought to be a document describing ?allowed C++ sins in HotSpot?. And I would put aliasing rules at the top of said document. Today we rely on compilers being tamed not to be tempted to exploit aliasing rules (e.g. -fno-strict-aliasing). The reliance on this in our code base goes so deep that we will arguably never be able to stop relying on it. And why would we want to, more than to find more interesting ways of tormenting ourselves? This is something we should embrace. By embracing this and putting it in a document that this is allowed, we would have the following benefits: 1) All reoccuring discussions whether we should or should not care about aliasing would come to quick ends, and decisions would not have to be taken (inconsistently) over and over again on a case by case basis. 2) Porters would know what requirements HotSpot has on compiler taming to safely run HotSpot. If they can not tame the compiler to ignore aliasing rules, then they can not use HotSpot. 3) By embracing aliasing violations as an allowed C++ sin, time will be saved for everyone involved, not having to invent complicated solutions circumventing it. Spending time honoring these rules seems like a waste of time and resources unless we fully commit to removing all such behaviour and hence can flip the compiler switches and hence remove our reliance on this. And we will never be able to do that. Nor should we if we could. 4) It seems like the problem being discussed in this thread before I hijacked it would have simple solutions. So basically, my answer to your question is: no we do not and should not care. And that message ought to be documented somewhere to remove all uncertainty and inconsistency around that reoccuring question. Thanks, /Erik > On 7 Aug 2018, at 16:00, Andrew Haley wrote: > >> On 08/07/2018 06:48 AM, John Rose wrote: >>> On Aug 6, 2018, at 9:54 PM, Martin Buchholz wrote: >>> >>> I don't know what is actually being copied here, but can't the underlying >>> type be atomic ? >> >> Yes, if we are allowed to cast some random sequence of metadata >> words to atomic[]. > > We're not. Well, we sort-of are because we use -fno-strict-aliasing, but that's > not standard C++11. Do we care? :-) > > GCC builtins do what we need when we're using GCC, but then we don't need C++11. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rkennke at redhat.com Wed Aug 8 09:40:09 2018 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 8 Aug 2018 11:40:09 +0200 Subject: Ping: RFR: JDK-8205523: Explicit barriers for interpreter In-Reply-To: References: <3aae894d-dae1-f4b3-7702-d99621382864@redhat.com> <75ea0ba0-6990-9e18-c724-355aad788cb6@redhat.com> <9904470c-4a10-48c3-2533-c5f8c3fe94e0@oracle.com> <0a85ec44-5487-c11f-1436-8912958dc9ad@redhat.com> <1e211420-7f77-f0d3-8e08-3b499ff66899@redhat.com> <38724390-8f6b-45ac-8654-e79082e820c6@redhat.com> <735140fb-83f5-ca1f-df3d-fc3af4bf31bc@redhat.com> <5B58800F.1050603@oracle.com> <5B59E222.1080208@oracle.com> <3d192cda-3115-abc1-c86c-94e88f2ac5a2@redhat.com> Message-ID: <3e37aab9-6df6-a406-b6e0-8eecbca2abb6@redhat.com> Hi Erik, thank you! This needs one more review. Andrew H: can you please take a look at it? Updated webrevs (for other reviewers): Incremental: http://cr.openjdk.java.net/~rkennke/JDK-8205523/webrev.02.diff/ Full: http://cr.openjdk.java.net/~rkennke/JDK-8205523/webrev.02/ Thanks, Roman > Hi Roman, > > Yes. Reviewed. > > Thanks, > /Erik > > On 1 Aug 2018, at 16:18, Roman Kennke wrote: > >>>> thanks for the review. I agree defaulting to READ|WRITE is even better. >>>> >>>> Updated webrevs (for other reviewers): >>>> Incremental: >>>> http://cr.openjdk.java.net/~rkennke/JDK-8205523/webrev.02.diff/ >>>> Full: >>>> http://cr.openjdk.java.net/~rkennke/JDK-8205523/webrev.02/ >>>> >>>> Would you agree that we could/should make this consistent across >>>> runtime/interpreter/c1/c2 ? It certainly would make me happier in >>>> runtime land, and seems required in compiler land. >>> >>> Yes, agreed. I only introduced decorators for this in compilers because >>> they were not needed in the interpreter and runtime. But now they are >>> needed there too, having different decorators for the same thing will >>> only be confusing. >> >> I will file followup RFEs for those. >> >> Can I consider the change reviewed by you? >> >> Also, I need one more reviewer. Any takers, please? >> >> Thanks! >> Roman >> >>> >>> Thanks, >>> /Erik >>> >>>> Andrew: are you ok with this final patch? >>>> >>>> Roman >>>> >>>>> I gotta say I like this a lot better. With the safe defaults for the >>>>> non-expert, yet allowing you guys to be more precise where you know it >>>>> is okay, I am okay with this. >>>>> Just a small thing though: >>>>> >>>>> 6290 void MacroAssembler::resolve(DecoratorSet decorators, Register >>>>> obj) { >>>>> 6291 // Use stronger ACCESS_WRITE by default. >>>>> 6292 if ((decorators & ACCESS_READ) == 0) { >>>>> 6293 decorators |= ACCESS_WRITE; >>>>> 6294 } >>>>> 6295 BarrierSetAssembler* bs = >>>>> BarrierSet::barrier_set()->barrier_set_assembler(); >>>>> 6296 return bs->resolve(this, decorators, obj); >>>>> 6297 } >>>>> >>>>> Just in terms of semantics, I think you should really change these >>>>> defaults to: >>>>> >>>>> 6292 if ((decorators & (ACCESS_READ | ACCESS_WRITE)) == 0) { >>>>> 6293 decorators |= ACCESS_READ | ACCESS_WRITE; >>>>> 6294 } >>>>> >>>>> In other words, the default resolve unless specified is for ACCESS_READ >>>>> | ACCESS_WRITE - you may read or write primitives on the resolved oop. I >>>>> don't think it is necesarily intuitive that being allowed to write >>>>> implicitly means that you are allowed to read too; that is just an >>>>> implementation detail of relocating on writes as Shenandoah does things. >>>>> So if you just change that, you have looks good from me. And I don't >>>>> need another webrev for that. >>>>> >>>>> Thanks, >>>>> /Erik >>>>> >>>>> On 2018-07-02 13:56, Roman Kennke wrote: >>>>>>>> I am a fan of profile guided optimization. I would definitely not >>>>>>>> mind >>>>>>>> introducing these concepts in the compilers where they are with no >>>>>>>> doubt >>>>>>>> necessary (and we also have the right tools for dealing with this >>>>>>>> better). In fact, they already have read/write decorators that >>>>>>>> could be >>>>>>>> used for resolve barriers in our compilers, and can use algorithms to >>>>>>>> safely elide barriers where provably correct, so it makes perfect >>>>>>>> sense >>>>>>>> for me to use such concepts there. >>>>>>>> I'm just not sure that the interpreter needs to be polluted with this >>>>>>>> conceptual overhead, unless there is at least one benchmark that can >>>>>>>> show that we are solving an actual problem with this. Remember, >>>>>>>> premature optimizations are the root of all evil. >>>>>>> but efficient systems are made from thousands of tiny optimizations, >>>>>>> each >>>>>>> one too small to be measured above the noise on its own. >>>>>>> >>>>>> After some offline discussion with Erik, I want to propose a solution >>>>>> that 1. keeps the API simple to use, even if not sure if it's a >>>>>> read- or >>>>>> write-access (defaulting to stronger write, 2. remains flexible enough >>>>>> to optimize for read-only acces. >>>>>> >>>>>> This changeset introduces an API BarrierSetAssembler::resolve() which >>>>>> takes the 'hint' about read- vs write-access via a Decorator >>>>>> ACCESS_READ >>>>>> and ACCESS_WRITE. The API frontend in MacroAssembler::resolve() sets >>>>>> ACCESS_WRITE if ACCESS_READ is not explicitely set. >>>>>> >>>>>> Incremental webrev: >>>>>> http://cr.openjdk.java.net/~rkennke/JDK-8205523/webrev.01.diff/ >>>>>> Full webrev: >>>>>> http://cr.openjdk.java.net/~rkennke/JDK-8205523/webrev.01/ >>>>>> >>>>>> If this proposal gets accepted, I'd take this further (in separate >>>>>> RFEs): >>>>>> 1. make C1 use ACCESS_READ and ACCESS_WRITE instead of C1_READ_ACCESS >>>>>> and C1_WRITE_ACCESS. Those uses are currently no good anyway (as they >>>>>> are currently passed into Access API that 'knows' what it is, e.g. >>>>>> store_at/load_at, etc). >>>>>> 2. introduce same pattern for resolve() in runtime (and later, c1 and >>>>>> c2). >>>>>> >>>>>> What do you think? >>>>>> >>>>>> Roman >>>>>> >>>> >>> >> >> From aph at redhat.com Wed Aug 8 14:02:28 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 8 Aug 2018 15:02:28 +0100 Subject: Using C++11+ in hotspot In-Reply-To: References: <6D166068-9FA9-4B0B-A157-0CB109753F4C@oracle.com> <347ce2b1-550b-112c-6a76-3c1657f48a7b@redhat.com> Message-ID: On 08/08/2018 07:51 AM, Erik Osterlund wrote: > So basically, my answer to your question is: no we do not and should > not care. And that message ought to be documented somewhere to > remove all uncertainty and inconsistency around that reoccuring > question. That sounds sensible. I guess that if we use -fno-strict-aliasing then we can cast *T to *atomic. I can ask on gcc@ to be sure. Having said that, I wouldn't. gcc builtins do what we need anyway, at least for platform-specific code. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From per.liden at oracle.com Wed Aug 8 13:59:37 2018 From: per.liden at oracle.com (Per Liden) Date: Wed, 8 Aug 2018 15:59:37 +0200 Subject: RFR (XL): 8208669: GC changes to allow enabling -Wreorder In-Reply-To: References: <1fe17e13a5aeb583f05061c1cab6b55b7bdd4279.camel@oracle.com> Message-ID: <40bda6fa-ba22-160f-bbb2-0a04d1a6e797@oracle.com> Hi Thomas, On 08/06/2018 02:35 PM, Thomas Schatzl wrote: > > http://cr.openjdk.java.net/~tschatzl/8208669/webrev.1 (full) > http://cr.openjdk.java.net/~tschatzl/8208669/webrev.0_to_1 (diff) > Looks good. Thanks for fixing this. /Per From coleen.phillimore at oracle.com Wed Aug 8 16:03:37 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 8 Aug 2018 12:03:37 -0400 Subject: Ping: RFR: JDK-8205523: Explicit barriers for interpreter In-Reply-To: <3e37aab9-6df6-a406-b6e0-8eecbca2abb6@redhat.com> References: <3aae894d-dae1-f4b3-7702-d99621382864@redhat.com> <75ea0ba0-6990-9e18-c724-355aad788cb6@redhat.com> <9904470c-4a10-48c3-2533-c5f8c3fe94e0@oracle.com> <0a85ec44-5487-c11f-1436-8912958dc9ad@redhat.com> <1e211420-7f77-f0d3-8e08-3b499ff66899@redhat.com> <38724390-8f6b-45ac-8654-e79082e820c6@redhat.com> <735140fb-83f5-ca1f-df3d-fc3af4bf31bc@redhat.com> <5B58800F.1050603@oracle.com> <5B59E222.1080208@oracle.com> <3d192cda-3115-abc1-c86c-94e88f2ac5a2@redhat.com> <3e37aab9-6df6-a406-b6e0-8eecbca2abb6@redhat.com> Message-ID: I've looked at this and I think it looks good to me.? Sorry for the delay in reviewing it. Coleen On 8/8/18 5:40 AM, Roman Kennke wrote: > Hi Erik, > > thank you! > > This needs one more review. Andrew H: can you please take a look at it? > > Updated webrevs (for other reviewers): > Incremental: > http://cr.openjdk.java.net/~rkennke/JDK-8205523/webrev.02.diff/ > Full: > http://cr.openjdk.java.net/~rkennke/JDK-8205523/webrev.02/ > > Thanks, > Roman > >> Hi Roman, >> >> Yes. Reviewed. >> >> Thanks, >> /Erik >> >> On 1 Aug 2018, at 16:18, Roman Kennke wrote: >> >>>>> thanks for the review. I agree defaulting to READ|WRITE is even better. >>>>> >>>>> Updated webrevs (for other reviewers): >>>>> Incremental: >>>>> http://cr.openjdk.java.net/~rkennke/JDK-8205523/webrev.02.diff/ >>>>> Full: >>>>> http://cr.openjdk.java.net/~rkennke/JDK-8205523/webrev.02/ >>>>> >>>>> Would you agree that we could/should make this consistent across >>>>> runtime/interpreter/c1/c2 ? It certainly would make me happier in >>>>> runtime land, and seems required in compiler land. >>>> Yes, agreed. I only introduced decorators for this in compilers because >>>> they were not needed in the interpreter and runtime. But now they are >>>> needed there too, having different decorators for the same thing will >>>> only be confusing. >>> I will file followup RFEs for those. >>> >>> Can I consider the change reviewed by you? >>> >>> Also, I need one more reviewer. Any takers, please? >>> >>> Thanks! >>> Roman >>> >>>> Thanks, >>>> /Erik >>>> >>>>> Andrew: are you ok with this final patch? >>>>> >>>>> Roman >>>>> >>>>>> I gotta say I like this a lot better. With the safe defaults for the >>>>>> non-expert, yet allowing you guys to be more precise where you know it >>>>>> is okay, I am okay with this. >>>>>> Just a small thing though: >>>>>> >>>>>> 6290 void MacroAssembler::resolve(DecoratorSet decorators, Register >>>>>> obj) { >>>>>> 6291 // Use stronger ACCESS_WRITE by default. >>>>>> 6292 if ((decorators & ACCESS_READ) == 0) { >>>>>> 6293 decorators |= ACCESS_WRITE; >>>>>> 6294 } >>>>>> 6295 BarrierSetAssembler* bs = >>>>>> BarrierSet::barrier_set()->barrier_set_assembler(); >>>>>> 6296 return bs->resolve(this, decorators, obj); >>>>>> 6297 } >>>>>> >>>>>> Just in terms of semantics, I think you should really change these >>>>>> defaults to: >>>>>> >>>>>> 6292 if ((decorators & (ACCESS_READ | ACCESS_WRITE)) == 0) { >>>>>> 6293 decorators |= ACCESS_READ | ACCESS_WRITE; >>>>>> 6294 } >>>>>> >>>>>> In other words, the default resolve unless specified is for ACCESS_READ >>>>>> | ACCESS_WRITE - you may read or write primitives on the resolved oop. I >>>>>> don't think it is necesarily intuitive that being allowed to write >>>>>> implicitly means that you are allowed to read too; that is just an >>>>>> implementation detail of relocating on writes as Shenandoah does things. >>>>>> So if you just change that, you have looks good from me. And I don't >>>>>> need another webrev for that. >>>>>> >>>>>> Thanks, >>>>>> /Erik >>>>>> >>>>>> On 2018-07-02 13:56, Roman Kennke wrote: >>>>>>>>> I am a fan of profile guided optimization. I would definitely not >>>>>>>>> mind >>>>>>>>> introducing these concepts in the compilers where they are with no >>>>>>>>> doubt >>>>>>>>> necessary (and we also have the right tools for dealing with this >>>>>>>>> better). In fact, they already have read/write decorators that >>>>>>>>> could be >>>>>>>>> used for resolve barriers in our compilers, and can use algorithms to >>>>>>>>> safely elide barriers where provably correct, so it makes perfect >>>>>>>>> sense >>>>>>>>> for me to use such concepts there. >>>>>>>>> I'm just not sure that the interpreter needs to be polluted with this >>>>>>>>> conceptual overhead, unless there is at least one benchmark that can >>>>>>>>> show that we are solving an actual problem with this. Remember, >>>>>>>>> premature optimizations are the root of all evil. >>>>>>>> but efficient systems are made from thousands of tiny optimizations, >>>>>>>> each >>>>>>>> one too small to be measured above the noise on its own. >>>>>>>> >>>>>>> After some offline discussion with Erik, I want to propose a solution >>>>>>> that 1. keeps the API simple to use, even if not sure if it's a >>>>>>> read- or >>>>>>> write-access (defaulting to stronger write, 2. remains flexible enough >>>>>>> to optimize for read-only acces. >>>>>>> >>>>>>> This changeset introduces an API BarrierSetAssembler::resolve() which >>>>>>> takes the 'hint' about read- vs write-access via a Decorator >>>>>>> ACCESS_READ >>>>>>> and ACCESS_WRITE. The API frontend in MacroAssembler::resolve() sets >>>>>>> ACCESS_WRITE if ACCESS_READ is not explicitely set. >>>>>>> >>>>>>> Incremental webrev: >>>>>>> http://cr.openjdk.java.net/~rkennke/JDK-8205523/webrev.01.diff/ >>>>>>> Full webrev: >>>>>>> http://cr.openjdk.java.net/~rkennke/JDK-8205523/webrev.01/ >>>>>>> >>>>>>> If this proposal gets accepted, I'd take this further (in separate >>>>>>> RFEs): >>>>>>> 1. make C1 use ACCESS_READ and ACCESS_WRITE instead of C1_READ_ACCESS >>>>>>> and C1_WRITE_ACCESS. Those uses are currently no good anyway (as they >>>>>>> are currently passed into Access API that 'knows' what it is, e.g. >>>>>>> store_at/load_at, etc). >>>>>>> 2. introduce same pattern for resolve() in runtime (and later, c1 and >>>>>>> c2). >>>>>>> >>>>>>> What do you think? >>>>>>> >>>>>>> Roman >>>>>>> >>> From magnus.ihse.bursie at oracle.com Wed Aug 8 18:53:12 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 8 Aug 2018 20:53:12 +0200 Subject: RFR (XXS): 8208672: Enable -Wreorder in make files In-Reply-To: <3a6b32f3-e4d9-9804-23f4-cfb5515a0ce9@oracle.com> References: <54931f694a70d0c215859697eb4083019ae7a3fb.camel@oracle.com> <3a6b32f3-e4d9-9804-23f4-cfb5515a0ce9@oracle.com> Message-ID: <9A4346E1-0A29-4584-98E1-EF1B3AAFD44D@oracle.com> Quick reply from my vacation... there's a macro that tests if a compiler option is valid. We've only used it for gcc so far, but I see no reason for why it should not work with VS. Maybe you can use that instead of checking version? I'm a bit hesitant at adding options that will produce warnings for older but still supported versions. If it's just a single compiler at the end of the list, that's one thing, but if we're talking everything but VS2017, that's another. If there's a problem adding the VS option, I'd rather see you just add the gcc one. /Magnus > 7 aug. 2018 kl. 12:08 skrev David Holmes : > > Hi Thomas, > >> On 7/08/2018 7:34 PM, Thomas Schatzl wrote: >> Hi David, >>> On Tue, 2018-08-07 at 07:17 +1000, David Holmes wrote: >>> Hi Thomas, >>> >>>> On 6/08/2018 10:38 PM, Thomas Schatzl wrote: >>>> Hi David, >>>> >>>>> On Fri, 2018-08-03 at 10:20 +1000, David Holmes wrote: >>>>> Hi Thomas, >>>>> >>>>>> On 2/08/2018 7:14 PM, Thomas Schatzl wrote: >>>>>> Hi all, >>>>>> >>>>>> there have been several suggestions to try to fix the >>>>>> Hotspot code to allow us to enable -Wreorder in the Hotspot >>>>>> sources. >>>>>> This should make problems due to use-before-initialization much >>>>>> more obvious. >>>>>> >>>>>> This change enables -Wreorder for gcc and clang. >>>>> >>>>> For Windows (VS2017+) see: >>>>> >>>>> https://docs.microsoft.com/en-us/cpp/error-messages/compiler- >>>>> warnings /c5038 >>>>> >>>>> Otherwise change seems okay. >>>>> >>>> >>>> Thanks! >>>> >>>> http://cr.openjdk.java.net/~tschatzl/8208672/webrev.0_to_1 (diff) >>>> http://cr.openjdk.java.net/~tschatzl/8208672/webrev.1 (full) >>>> >>>> I verified that all our platforms (including Windows) still build. >>> >>> I think the Windows change needs to be based on the compiler version >>> used as, from what I read, the flag only exists in VS2017. >> jdk11 official compiler is VS2017 so I figured it would not be that >> much of a problem. > > Right now the build supports a range of compilers for the community: > > ################################################################################ > # The order of these defines the priority by which we try to find them. > VALID_VS_VERSIONS="2017 2013 2015 2012 2010" > >> Another reason for my thinking is that MSVC 2013 does not implement >> some interesting C++11 features anyway so we might be forced to drop >> support for it soon (and the situation is of course worse if we upgrade >> to C++14). > > If that happens we'd have to deal with it sure ... > >> I looked a bit at the makefile and conditionalizing this on VS2017 (or >> checking only whether VS2013 let it slide, i.e. give an "unsupported >> option" warning but continue anyway because I would need to setup a >> Windows dev environment somewhere) would take me a lot of time. > > Hoping the build folk will jump in as this should be pretty straight-forward I think - just a question of knowing what VERSION variable to test. > >> Would it be possible to skip -Werror support for Visual Studio now and >> try to fix this in a later enhancement? > > Sure. Just a pity as it will be 10x as much work to add later by itself. > > Thanks, > David > ----- > >> Thanks, >> Thomas From martinrb at google.com Wed Aug 8 19:51:39 2018 From: martinrb at google.com (Martin Buchholz) Date: Wed, 8 Aug 2018 12:51:39 -0700 Subject: Using C++11+ in hotspot In-Reply-To: References: <6D166068-9FA9-4B0B-A157-0CB109753F4C@oracle.com> <347ce2b1-550b-112c-6a76-3c1657f48a7b@redhat.com> Message-ID: I agree getting to a hotspot without C++ undefined behavior is very hard. Organizations like Google like to have control over all their software, including the toolchain, and want both high performance and standards compliance, enforced via tools like ubsan https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html. Full employment for engineers like me who try to bridge the 2 worlds. I'd like to see hotspot stop using the -fno-strict-aliasing curtch, replacing it with union and/or may_alias, but this is a serious investment. Here are my type-punning notes: #---------------------------------------------------------------- # -fstrict-aliasing, union, memcpy, C99, C++. #---------------------------------------------------------------- https://blog.regehr.org/archives/959 http://dbp-consulting.com/tutorials/StrictAliasing.html C99 allows type punning via members of a union, and all known C++ compilers allow it, but strictly speaking not permitted by the C++ standard. 85. If the member used to access the contents of a union object is not the same as the member last used to store a value in the object, the appropriate part of the object representation of the value is reinterpreted as an object representation in the new type as described in 6.2.6 (a process sometimes called type punning). This might be a trap representation. Doing type punning via memcpy really goes against low-level programmer instinct - we really have to trust the compiler to optimize away the memcpy library call! gcc (what about clang?) has the may_alias attribute https://gcc.gnu.org/onlinedocs/gcc/Common-Type-Attributes.html From martinrb at google.com Wed Aug 8 20:05:01 2018 From: martinrb at google.com (Martin Buchholz) Date: Wed, 8 Aug 2018 13:05:01 -0700 Subject: Using C++11+ in hotspot In-Reply-To: References: <6D166068-9FA9-4B0B-A157-0CB109753F4C@oracle.com> <347ce2b1-550b-112c-6a76-3c1657f48a7b@redhat.com> Message-ID: On Wed, Aug 8, 2018 at 7:02 AM, Andrew Haley wrote: > On 08/08/2018 07:51 AM, Erik Osterlund wrote: > > > So basically, my answer to your question is: no we do not and should > > not care. And that message ought to be documented somewhere to > > remove all uncertainty and inconsistency around that reoccuring > > question. > > That sounds sensible. I guess that if we use -fno-strict-aliasing > then we can cast *T to *atomic. I can ask on gcc@ to be sure. > A difficulty might arise if the representation of atomic is different from T, as might happen if the arch has no atomic instructions for a type of that size and so a lock must be allocated somewhere. I don't know how gcc's atomic builtins deal with that problem. From john.r.rose at oracle.com Wed Aug 8 21:16:07 2018 From: john.r.rose at oracle.com (John Rose) Date: Wed, 8 Aug 2018 14:16:07 -0700 Subject: Using C++11+ in hotspot In-Reply-To: References: <6D166068-9FA9-4B0B-A157-0CB109753F4C@oracle.com> <347ce2b1-550b-112c-6a76-3c1657f48a7b@redhat.com> Message-ID: On Aug 8, 2018, at 1:05 PM, Martin Buchholz wrote: > > > That sounds sensible. I guess that if we use -fno-strict-aliasing > then we can cast *T to *atomic. I can ask on gcc@ to be sure. > > A difficulty might arise if the representation of atomic is different from T, as might happen if the arch has no atomic instructions for a type of that size and so a lock must be allocated somewhere. I don't know how gcc's atomic builtins deal with that problem. A CPU/memory architecture which requires STM to for atomic storage of machine words would be a prime example of such a platform. It's also a prime example of a platform which HotSpot would not be portable to without deep refactoring along the lines of the access API but for all data. I think the two properties would be correlated, in practice. HotSpot makes pervasive assumptions that machine word data is routinely atomic (non-tearable, with valid race-winners in all cases), and it will be hard to break it of those assumptions in all cases. We've started to do that with things like the atomic, copy, and access APIs, but there's lots more to do, if we need to go down that road. ? John From martinrb at google.com Thu Aug 9 02:24:15 2018 From: martinrb at google.com (Martin Buchholz) Date: Wed, 8 Aug 2018 19:24:15 -0700 Subject: Using C++11+ in hotspot In-Reply-To: <3959BC8E-F755-48B4-BE05-9BA13BC3E575@oracle.com> References: <6D166068-9FA9-4B0B-A157-0CB109753F4C@oracle.com> <3959BC8E-F755-48B4-BE05-9BA13BC3E575@oracle.com> Message-ID: On Mon, Aug 6, 2018 at 11:12 AM, John Rose wrote: > On Aug 5, 2018, at 8:30 AM, Martin Buchholz wrote: > > > static inline void copy_table(address* from, address* to, int size) { > // Copy non-overlapping tables. The copy has to occur word wise for MT > safety. > while (size-- > 0) *to++ = *from++; > } > > Today, that loop should be recoded to use copy, and copy in turn needs to > do whatever magic is required to force word-atomic access on non-atomic > data. > I now see the many variants of copy in share/utilities/copy.hpp but there is none that makes copies of the type "address". Maybe you could make an atomic copy template that takes any type T with sizeof(T) <= 8 ? --- At the type system level, HeapWord is a struct, so C++ will not be happy with our other traditional trick of reading a pointer to a volatile HeapWord to "force" atomicity. From david.holmes at oracle.com Thu Aug 9 03:10:56 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 9 Aug 2018 13:10:56 +1000 Subject: RFR (XXS): 8208672: Enable -Wreorder in make files In-Reply-To: <9A4346E1-0A29-4584-98E1-EF1B3AAFD44D@oracle.com> References: <54931f694a70d0c215859697eb4083019ae7a3fb.camel@oracle.com> <3a6b32f3-e4d9-9804-23f4-cfb5515a0ce9@oracle.com> <9A4346E1-0A29-4584-98E1-EF1B3AAFD44D@oracle.com> Message-ID: <29d5f075-8656-3d05-dbb0-fe872b93b927@oracle.com> On 9/08/2018 4:53 AM, Magnus Ihse Bursie wrote: > Quick reply from my vacation... there's a macro that tests if a compiler option is valid. We've only used it for gcc so far, but I see no reason for why it should not work with VS. Maybe you can use that instead of checking version? Thanks for the response Magnus. I think your suggestion will involve being able to locally verify with different versions of VS to ensure the macro test actually works as expected. And neither Thomas nor I are able to do that, so ... > I'm a bit hesitant at adding options that will produce warnings for older but still supported versions. If it's just a single compiler at the end of the list, that's one thing, but if we're talking everything but VS2017, that's another. If there's a problem adding the VS option, I'd rather see you just add the gcc one. ... looks like we're just skipping Windows. Thanks, David > > /Magnus > >> 7 aug. 2018 kl. 12:08 skrev David Holmes : >> >> Hi Thomas, >> >>> On 7/08/2018 7:34 PM, Thomas Schatzl wrote: >>> Hi David, >>>> On Tue, 2018-08-07 at 07:17 +1000, David Holmes wrote: >>>> Hi Thomas, >>>> >>>>> On 6/08/2018 10:38 PM, Thomas Schatzl wrote: >>>>> Hi David, >>>>> >>>>>> On Fri, 2018-08-03 at 10:20 +1000, David Holmes wrote: >>>>>> Hi Thomas, >>>>>> >>>>>>> On 2/08/2018 7:14 PM, Thomas Schatzl wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> there have been several suggestions to try to fix the >>>>>>> Hotspot code to allow us to enable -Wreorder in the Hotspot >>>>>>> sources. >>>>>>> This should make problems due to use-before-initialization much >>>>>>> more obvious. >>>>>>> >>>>>>> This change enables -Wreorder for gcc and clang. >>>>>> >>>>>> For Windows (VS2017+) see: >>>>>> >>>>>> https://docs.microsoft.com/en-us/cpp/error-messages/compiler- >>>>>> warnings /c5038 >>>>>> >>>>>> Otherwise change seems okay. >>>>>> >>>>> >>>>> Thanks! >>>>> >>>>> http://cr.openjdk.java.net/~tschatzl/8208672/webrev.0_to_1 (diff) >>>>> http://cr.openjdk.java.net/~tschatzl/8208672/webrev.1 (full) >>>>> >>>>> I verified that all our platforms (including Windows) still build. >>>> >>>> I think the Windows change needs to be based on the compiler version >>>> used as, from what I read, the flag only exists in VS2017. >>> jdk11 official compiler is VS2017 so I figured it would not be that >>> much of a problem. >> >> Right now the build supports a range of compilers for the community: >> >> ################################################################################ >> # The order of these defines the priority by which we try to find them. >> VALID_VS_VERSIONS="2017 2013 2015 2012 2010" >> >>> Another reason for my thinking is that MSVC 2013 does not implement >>> some interesting C++11 features anyway so we might be forced to drop >>> support for it soon (and the situation is of course worse if we upgrade >>> to C++14). >> >> If that happens we'd have to deal with it sure ... >> >>> I looked a bit at the makefile and conditionalizing this on VS2017 (or >>> checking only whether VS2013 let it slide, i.e. give an "unsupported >>> option" warning but continue anyway because I would need to setup a >>> Windows dev environment somewhere) would take me a lot of time. >> >> Hoping the build folk will jump in as this should be pretty straight-forward I think - just a question of knowing what VERSION variable to test. >> >>> Would it be possible to skip -Werror support for Visual Studio now and >>> try to fix this in a later enhancement? >> >> Sure. Just a pity as it will be 10x as much work to add later by itself. >> >> Thanks, >> David >> ----- >> >>> Thanks, >>> Thomas > From vladimir.kozlov at oracle.com Thu Aug 9 05:22:50 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 8 Aug 2018 22:22:50 -0700 Subject: [12] RFR(S) 8209165: [GRAAL] Skip Graal build if C1 is not present Message-ID: <49e14f86-c399-f469-2150-e9ac248647c9@oracle.com> http://cr.openjdk.java.net/~kvn/8209165/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8209165 Graal Java JIT requires C1 compiler to compile Graal's methods. Otherwise it takes long time to compile application's hot methods because Graal have to compile itself and run in Interpreter until then. Some tests timeout in such configuration. I assume when people build Hotspot without C1 they want to have only C2 and don't care about Graal. I suggest to not build Graal's module in such case (it save space). We will enable Graal build later when libgraal.so is available regardless C1 presence because it will not depend on it. Also generation of graalunit libraries should be guarded by presence of Graal. Currently Hotspot VM features setup done after libraries are set: http://hg.openjdk.java.net/jdk/jdk/file/554bb4e2d10d/make/autoconf/configure.ac#l219 But we can fix it by reverting changes done by JDK-8171008 when AOT was dependent on presence of libelf: http://hg.openjdk.java.net/jdk/jdk/rev/4780f4130eb0 Currently I don't see any dependencies on libraries in hotspot.m4 Testing by running tier1-3 tests without C1. -- Thanks, Vladimir From rkennke at redhat.com Thu Aug 9 07:55:11 2018 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 9 Aug 2018 09:55:11 +0200 Subject: Ping: RFR: JDK-8205523: Explicit barriers for interpreter In-Reply-To: References: <3aae894d-dae1-f4b3-7702-d99621382864@redhat.com> <75ea0ba0-6990-9e18-c724-355aad788cb6@redhat.com> <9904470c-4a10-48c3-2533-c5f8c3fe94e0@oracle.com> <0a85ec44-5487-c11f-1436-8912958dc9ad@redhat.com> <1e211420-7f77-f0d3-8e08-3b499ff66899@redhat.com> <38724390-8f6b-45ac-8654-e79082e820c6@redhat.com> <735140fb-83f5-ca1f-df3d-fc3af4bf31bc@redhat.com> <5B58800F.1050603@oracle.com> <5B59E222.1080208@oracle.com> <3d192cda-3115-abc1-c86c-94e88f2ac5a2@redhat.com> <3e37aab9-6df6-a406-b6e0-8eecbca2abb6@redhat.com> Message-ID: <6f1825b0-6245-21ed-9cc6-83f9e20bb239@redhat.com> Thanks Coleen! No problem, it's what we call 'summer hole' here ;-) I've pushed it into submit-repo. Thanks, Roman > I've looked at this and I think it looks good to me.? Sorry for the > delay in reviewing it. > > Coleen > > On 8/8/18 5:40 AM, Roman Kennke wrote: >> Hi Erik, >> >> thank you! >> >> This needs one more review. Andrew H: can you please take a look at it? >> >> Updated webrevs (for other reviewers): >> Incremental: >> http://cr.openjdk.java.net/~rkennke/JDK-8205523/webrev.02.diff/ >> Full: >> http://cr.openjdk.java.net/~rkennke/JDK-8205523/webrev.02/ >> >> Thanks, >> Roman >> >>> Hi Roman, >>> >>> Yes. Reviewed. >>> >>> Thanks, >>> /Erik >>> >>> On 1 Aug 2018, at 16:18, Roman Kennke wrote: >>> >>>>>> thanks for the review. I agree defaulting to READ|WRITE is even >>>>>> better. >>>>>> >>>>>> Updated webrevs (for other reviewers): >>>>>> Incremental: >>>>>> http://cr.openjdk.java.net/~rkennke/JDK-8205523/webrev.02.diff/ >>>>>> Full: >>>>>> http://cr.openjdk.java.net/~rkennke/JDK-8205523/webrev.02/ >>>>>> >>>>>> Would you agree that we could/should make this consistent across >>>>>> runtime/interpreter/c1/c2 ? It certainly would make me happier in >>>>>> runtime land, and seems required in compiler land. >>>>> Yes, agreed. I only introduced decorators for this in compilers >>>>> because >>>>> they were not needed in the interpreter and runtime. But now they are >>>>> needed there too, having different decorators for the same thing will >>>>> only be confusing. >>>> I will file followup RFEs for those. >>>> >>>> Can I consider the change reviewed by you? >>>> >>>> Also, I need one more reviewer. Any takers, please? >>>> >>>> Thanks! >>>> Roman >>>> >>>>> Thanks, >>>>> /Erik >>>>> >>>>>> Andrew: are you ok with this final patch? >>>>>> >>>>>> Roman >>>>>> >>>>>>> I gotta say I like this a lot better. With the safe defaults for the >>>>>>> non-expert, yet allowing you guys to be more precise where you >>>>>>> know it >>>>>>> is okay, I am okay with this. >>>>>>> Just a small thing though: >>>>>>> >>>>>>> 6290 void MacroAssembler::resolve(DecoratorSet decorators, Register >>>>>>> obj) { >>>>>>> 6291?? // Use stronger ACCESS_WRITE by default. >>>>>>> 6292?? if ((decorators & ACCESS_READ) == 0) { >>>>>>> 6293???? decorators |= ACCESS_WRITE; >>>>>>> 6294?? } >>>>>>> 6295?? BarrierSetAssembler* bs = >>>>>>> BarrierSet::barrier_set()->barrier_set_assembler(); >>>>>>> 6296?? return bs->resolve(this, decorators, obj); >>>>>>> 6297 } >>>>>>> >>>>>>> Just in terms of semantics, I think you should really change these >>>>>>> defaults to: >>>>>>> >>>>>>> 6292?? if ((decorators & (ACCESS_READ | ACCESS_WRITE)) == 0) { >>>>>>> 6293???? decorators |= ACCESS_READ | ACCESS_WRITE; >>>>>>> 6294?? } >>>>>>> >>>>>>> In other words, the default resolve unless specified is for >>>>>>> ACCESS_READ >>>>>>> | ACCESS_WRITE - you may read or write primitives on the resolved >>>>>>> oop. I >>>>>>> don't think it is necesarily intuitive that being allowed to write >>>>>>> implicitly means that you are allowed to read too; that is just an >>>>>>> implementation detail of relocating on writes as Shenandoah does >>>>>>> things. >>>>>>> So if you just change that, you have looks good from me. And I don't >>>>>>> need another webrev for that. >>>>>>> >>>>>>> Thanks, >>>>>>> /Erik >>>>>>> >>>>>>> On 2018-07-02 13:56, Roman Kennke wrote: >>>>>>>>>> I am a fan of profile guided optimization. I would definitely not >>>>>>>>>> mind >>>>>>>>>> introducing these concepts in the compilers where they are >>>>>>>>>> with no >>>>>>>>>> doubt >>>>>>>>>> necessary (and we also have the right tools for dealing with this >>>>>>>>>> better). In fact, they already have read/write decorators that >>>>>>>>>> could be >>>>>>>>>> used for resolve barriers in our compilers, and can use >>>>>>>>>> algorithms to >>>>>>>>>> safely elide barriers where provably correct, so it makes perfect >>>>>>>>>> sense >>>>>>>>>> for me to use such concepts there. >>>>>>>>>> I'm just not sure that the interpreter needs to be polluted >>>>>>>>>> with this >>>>>>>>>> conceptual overhead, unless there is at least one benchmark >>>>>>>>>> that can >>>>>>>>>> show that we are solving an actual problem with this. Remember, >>>>>>>>>> premature optimizations are the root of all evil. >>>>>>>>> but efficient systems are made from thousands of tiny >>>>>>>>> optimizations, >>>>>>>>> each >>>>>>>>> one too small to be measured above the noise on its own. >>>>>>>>> >>>>>>>> After some offline discussion with Erik, I want to propose a >>>>>>>> solution >>>>>>>> that 1. keeps the API simple to use, even if not sure if it's a >>>>>>>> read- or >>>>>>>> write-access (defaulting to stronger write, 2. remains flexible >>>>>>>> enough >>>>>>>> to optimize for read-only acces. >>>>>>>> >>>>>>>> This changeset introduces an API BarrierSetAssembler::resolve() >>>>>>>> which >>>>>>>> takes the 'hint' about read- vs write-access via a Decorator >>>>>>>> ACCESS_READ >>>>>>>> and ACCESS_WRITE. The API frontend in MacroAssembler::resolve() >>>>>>>> sets >>>>>>>> ACCESS_WRITE if ACCESS_READ is not explicitely set. >>>>>>>> >>>>>>>> Incremental webrev: >>>>>>>> http://cr.openjdk.java.net/~rkennke/JDK-8205523/webrev.01.diff/ >>>>>>>> Full webrev: >>>>>>>> http://cr.openjdk.java.net/~rkennke/JDK-8205523/webrev.01/ >>>>>>>> >>>>>>>> If this proposal gets accepted, I'd take this further (in separate >>>>>>>> RFEs): >>>>>>>> 1. make C1 use ACCESS_READ and ACCESS_WRITE instead of >>>>>>>> C1_READ_ACCESS >>>>>>>> and C1_WRITE_ACCESS. Those uses are currently no good anyway (as >>>>>>>> they >>>>>>>> are currently passed into Access API that 'knows' what it is, e.g. >>>>>>>> store_at/load_at, etc). >>>>>>>> 2. introduce same pattern for resolve() in runtime (and later, >>>>>>>> c1 and >>>>>>>> c2). >>>>>>>> >>>>>>>> What do you think? >>>>>>>> >>>>>>>> Roman >>>>>>>> >>>> > From george at georgeluiz.com Thu Aug 9 13:18:43 2018 From: george at georgeluiz.com (George Luiz Bittencourt) Date: Thu, 9 Aug 2018 10:18:43 -0300 Subject: Hello Message-ID: Hello! I am new to OpenJDK and I would like to help the project. I have already built it on Windows. My question is: what tools do you use to develop and debug OpenJDK on Windows? Are you guys using Visual Studio to edit and using its debugging capabilites? Or are you using a simple editor, like VS Code, building it manually and debugging using WinDBG? Thanks. -- -George From martijnverburg at gmail.com Thu Aug 9 15:22:51 2018 From: martijnverburg at gmail.com (Martijn Verburg) Date: Thu, 9 Aug 2018 16:22:51 +0100 Subject: Hello In-Reply-To: References: Message-ID: Hi George, I'm not sure there are many hotspot developers on windows! The toolchain for build though is to use visual studio (2011/13/17 depending on your JDK build version), so I'd recommend trying that and/or IntelliJ IDEA (which some committers have managed to wrangle OpenJDK source code into). Cheers, Martijn On Thu, 9 Aug 2018 at 14:19, George Luiz Bittencourt wrote: > Hello! > > I am new to OpenJDK and I would like to help the project. > I have already built it on Windows. > > My question is: what tools do you use to develop and debug OpenJDK on > Windows? > Are you guys using Visual Studio to edit and using its debugging > capabilites? > > Or are you using a simple editor, like VS Code, building it manually and > debugging using WinDBG? > > Thanks. > > -- > -George > From erik.gahlin at oracle.com Thu Aug 9 16:01:44 2018 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Thu, 9 Aug 2018 18:01:44 +0200 Subject: Hello In-Reply-To: References: Message-ID: <5B6C6568.8030303@oracle.com> Hi, I use Visual Studio for editing and debugging, others use WinDbg. I build the Visual Studio project with make hotspot-ide-project For Java code, I use Eclipse. I typically only change code in a few modules and I have preconfigured Eclipse projects for them (with project relative links). I build Java code manually. A few years back, I tried to build inside Eclipse using ANT-scripts, but it was a pain to maintain. Erik > Hello! > > I am new to OpenJDK and I would like to help the project. > I have already built it on Windows. > > My question is: what tools do you use to develop and debug OpenJDK on > Windows? > Are you guys using Visual Studio to edit and using its debugging > capabilites? > > Or are you using a simple editor, like VS Code, building it manually and > debugging using WinDBG? > > Thanks. > From navy.xliu at gmail.com Thu Aug 9 17:12:43 2018 From: navy.xliu at gmail.com (Liu Xin) Date: Thu, 9 Aug 2018 10:12:43 -0700 Subject: [12] RFR(S) 8209165: [GRAAL] Skip Graal build if C1 is not present In-Reply-To: <49e14f86-c399-f469-2150-e9ac248647c9@oracle.com> References: <49e14f86-c399-f469-2150-e9ac248647c9@oracle.com> Message-ID: <538BEF87-5114-4AD3-BC00-7B5B0983BC6C@gmail.com> Hi, Vladimir, I think that one single JIT is good to pinpoint the problem. Why not just allow Graal-only there. You don?t need to run all tests for Graal-only hotspot. I understand that Graal itself needs to JIT itself. libgraal.so is AOT result of Graal itself, right? Is it easy to do that? I can take a shot. If you have the compiled graal, you will revert this commit. Thanks, ?lx > On Aug 8, 2018, at 10:22 PM, Vladimir Kozlov wrote: > > http://cr.openjdk.java.net/~kvn/8209165/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8209165 > > Graal Java JIT requires C1 compiler to compile Graal's methods. Otherwise it takes long time to compile application's hot methods because Graal have to compile itself and run in Interpreter until then. Some tests timeout in such configuration. > > I assume when people build Hotspot without C1 they want to have only C2 and don't care about Graal. > I suggest to not build Graal's module in such case (it save space). We will enable Graal build later when libgraal.so is available regardless C1 presence because it will not depend on it. > > Also generation of graalunit libraries should be guarded by presence of Graal. Currently Hotspot VM features setup done after libraries are set: > http://hg.openjdk.java.net/jdk/jdk/file/554bb4e2d10d/make/autoconf/configure.ac#l219 > > But we can fix it by reverting changes done by JDK-8171008 when AOT was dependent on presence of libelf: > http://hg.openjdk.java.net/jdk/jdk/rev/4780f4130eb0 > > Currently I don't see any dependencies on libraries in hotspot.m4 > > Testing by running tier1-3 tests without C1. > > -- > Thanks, > Vladimir From vladimir.kozlov at oracle.com Thu Aug 9 18:26:06 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 9 Aug 2018 11:26:06 -0700 Subject: [12] RFR(S) 8209165: [GRAAL] Skip Graal build if C1 is not present In-Reply-To: <538BEF87-5114-4AD3-BC00-7B5B0983BC6C@gmail.com> References: <49e14f86-c399-f469-2150-e9ac248647c9@oracle.com> <538BEF87-5114-4AD3-BC00-7B5B0983BC6C@gmail.com> Message-ID: Hi Liu, On 8/9/18 10:12 AM, Liu Xin wrote: > Hi, Vladimir, > > I think that one single JIT is good to pinpoint the problem. > Why not just allow Graal-only there. You don?t need to run all tests for Graal-only hotspot. My main motivation is that it is not supported configuration for us. And if you don't use Graal you waste space with Graal module. But if people object to this change I can drop it. You can specify configure --with-jvm-features=-compiler1,-graal to remove Graal together with C1. > > I understand that Graal itself needs to JIT itself. libgraal.so is AOT result of Graal itself, right? > Is it easy to do that? I can take a shot. If you have the compiled graal, you will revert this commit. Yes, it is AOTed Graal with own GC, heap and small runtime. We are working on to use Substrate VM native-image tool (which is similar to JDK jaotc but target "closed world" app) to generate this library and avoid issues current Java Graal JIT has (slow compilation startup, shared Java heap, polluted profiles). It is not simple issue because we have to modify heavily JVMCI to allow communication between two libraries (hotspot and graal). I hope soon we can publish this work in Metropolis project. If you want to learn about Graal and SVM here are starting points: https://github.com/oracle/graal/tree/master/compiler https://github.com/oracle/graal/tree/master/substratevm Regards, Vladimir > > Thanks, > ?lx > > >> On Aug 8, 2018, at 10:22 PM, Vladimir Kozlov wrote: >> >> http://cr.openjdk.java.net/~kvn/8209165/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8209165 >> >> Graal Java JIT requires C1 compiler to compile Graal's methods. Otherwise it takes long time to compile application's hot methods because Graal have to compile itself and run in Interpreter until then. Some tests timeout in such configuration. >> >> I assume when people build Hotspot without C1 they want to have only C2 and don't care about Graal. >> I suggest to not build Graal's module in such case (it save space). We will enable Graal build later when libgraal.so is available regardless C1 presence because it will not depend on it. >> >> Also generation of graalunit libraries should be guarded by presence of Graal. Currently Hotspot VM features setup done after libraries are set: >> http://hg.openjdk.java.net/jdk/jdk/file/554bb4e2d10d/make/autoconf/configure.ac#l219 >> >> But we can fix it by reverting changes done by JDK-8171008 when AOT was dependent on presence of libelf: >> http://hg.openjdk.java.net/jdk/jdk/rev/4780f4130eb0 >> >> Currently I don't see any dependencies on libraries in hotspot.m4 >> >> Testing by running tier1-3 tests without C1. >> >> -- >> Thanks, >> Vladimir > From igor.ignatyev at oracle.com Thu Aug 9 23:24:24 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 9 Aug 2018 16:24:24 -0700 Subject: [11] RFR(S) : 8205687 : TimeoutHandler generates huge core files In-Reply-To: References: <4FA256FB-11DE-4C41-B4EE-4FCE3B7B1353@oracle.com> Message-ID: <2D832B3E-851B-44ED-970C-24E77B74E967@oracle.com> Hi David, thanks for your review. I've updated copyright years and added the next comment in GathererFactory.java: > + // os-specific action set must be last, b/c they can kill the process regarding checking w/ the people operating their own farms, I agree it'd be nice to do for changes like this one, but I don't know a better channel to do other than an email to dev alias, which wouldn't be much different from this RFR. In this particular case, I expect the hosts in all test farms to have core dumping enabled and core dumps from crashes are, from my observations, used more frequently than dumps from timeouts, so it shouldn't cause big issues. Thanks, -- Igor > On Aug 7, 2018, at 9:00 PM, David Holmes wrote: > > Hi Igor, > > This all seems okay. However we probably need to check that the people operating their own build/test farms are okay with this change. > > Don't forget to update copyright years. > > Minor comment below ... > > On 8/08/2018 7:19 AM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8205687/webrev.00/index.html >>> 18 lines changed: 3 ins; 5 del; 10 mod; >> Hi all, >> could you please review this small fix for TimeoutHandler? gcore dumps non committed memory, which is a problem when JVM is run w/ ZGC or in other configurations where memory is reserved but not committed. the fix replaces invocation of gcore w/ 'kill -ABRT'. as kill has to be the last command run by TimeoutHandler, I've changed jdk.test.failurehandler.ToolKit to run action after we get a list of the process's children and also changed GathererFactory to run "common" part before os-specific part. > > Can you add a comment in GathererFactory to explain that as well please. > > Thanks, > David > >> NB 'kill' will generate core file only if a host has appropriate core file limit and core file handling settings, therefore you might observe that core files aren't generated if your hosts aren't set up correspondingly. >> JBS: https://bugs.openjdk.java.net/browse/JDK-8205687 >> webrev: http://cr.openjdk.java.net/~iignatyev//8205687/webrev.00/index.html >> Thanks, >> -- Igor From aph at redhat.com Fri Aug 10 12:59:23 2018 From: aph at redhat.com (Andrew Haley) Date: Fri, 10 Aug 2018 13:59:23 +0100 Subject: Using C++11+ in hotspot In-Reply-To: References: <6D166068-9FA9-4B0B-A157-0CB109753F4C@oracle.com> <347ce2b1-550b-112c-6a76-3c1657f48a7b@redhat.com> Message-ID: On 08/08/2018 08:51 PM, Martin Buchholz wrote: > I'd like to see hotspot stop using the -fno-strict-aliasing curtch, > replacing it with union and/or may_alias, but this is a serious investment. It's a serious investment, and we'd risk breaking stuff. At least the entire heap would have to be an array with elements which are a union of all of the possible types, and there'd be a byte array overlaid on top of that. It would not be pretty. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gunter.haug at sap.com Fri Aug 10 13:04:53 2018 From: gunter.haug at sap.com (Haug, Gunter) Date: Fri, 10 Aug 2018 13:04:53 +0000 Subject: RFR (XXS): 820935: PPC64: fix build with -Wreorder introduced with 8208672 Message-ID: <946137C1-1F23-4B63-A783-BDFE595DE497@sap.com> Hi all, -Wreorder introduced with 8208672 required a few changes in PPC64 platform files to fix the build. Can I please have a review and a sponsor for the following change: https://bugs.openjdk.java.net/projects/JDK/issues/JDK-8209357?filter=reportedbyme http://cr.openjdk.java.net/~ghaug/webrevs/820935/ Thanks a lot and have a nice weekend, Gunter From matthias.baesken at sap.com Fri Aug 10 13:14:10 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 10 Aug 2018 13:14:10 +0000 Subject: RFR (XXS): 820935: PPC64: fix build with -Wreorder introduced with 8208672 In-Reply-To: <946137C1-1F23-4B63-A783-BDFE595DE497@sap.com> References: <946137C1-1F23-4B63-A783-BDFE595DE497@sap.com> Message-ID: Hi Gunter , thanks for fixing this . Looks good to me (not a Reviewer however). But I can confirm that the ppc64(le) builds work after this change has been added . Best regards, Matthias From: Haug, Gunter Sent: Freitag, 10. August 2018 15:05 To: hotspot-dev Source Developers ; hotspot-dev at openjdk.java.net Cc: Thomas Schatzl ; Baesken, Matthias Subject: RFR (XXS): 820935: PPC64: fix build with -Wreorder introduced with 8208672 Hi all, -Wreorder introduced with 8208672 required a few changes in PPC64 platform files to fix the build. Can I please have a review and a sponsor for the following change: https://bugs.openjdk.java.net/projects/JDK/issues/JDK-8209357?filter=reportedbyme http://cr.openjdk.java.net/~ghaug/webrevs/820935/ Thanks a lot and have a nice weekend, Gunter From thomas.schatzl at oracle.com Fri Aug 10 13:20:43 2018 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 10 Aug 2018 15:20:43 +0200 Subject: RFR (XXS): 8209357: PPC64: fix build with -Wreorder introduced with 8208672 In-Reply-To: <946137C1-1F23-4B63-A783-BDFE595DE497@sap.com> References: <946137C1-1F23-4B63-A783-BDFE595DE497@sap.com> Message-ID: Hi, On Fri, 2018-08-10 at 13:04 +0000, Haug, Gunter wrote: > Hi all, > > -Wreorder introduced with 8208672 required a few changes in PPC64 > platform files to fix the build. Can I please have a review and a > sponsor for the following change: > > https://bugs.openjdk.java.net/projects/JDK/issues/JDK-8209357?filter= > reportedbyme > http://cr.openjdk.java.net/~ghaug/webrevs/820935/ > > Thanks a lot and have a nice weekend, > Gunter looks good. I can sponsor. Thanks, Thomas From thomas.schatzl at oracle.com Fri Aug 10 13:32:32 2018 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 10 Aug 2018 15:32:32 +0200 Subject: RFR (S): 8209193: Fix aarch64-linux compilation after -Wreorder changes Message-ID: Hi, when crosscompiling to aarch64-linux I found the following errors caused by latest -Wreorder changes. It would be nice if aarch64 devs could verify; I cc'ed aarch64 port dev ml, but I do not know if this is the right list for this. Aarch32 is probably still broken. CR: https://bugs.openjdk.java.net/browse/JDK-8209193 Webrev: http://cr.openjdk.java.net/~tschatzl/8209193/webrev/ Testing: successfully crosscompiled from amd64-linux to aarch64-linux Thanks, Thomas From shade at redhat.com Fri Aug 10 13:56:15 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 10 Aug 2018 15:56:15 +0200 Subject: RFR (S): 8209193: Fix aarch64-linux compilation after -Wreorder changes In-Reply-To: References: Message-ID: Hi Thomas, On 08/10/2018 03:32 PM, Thomas Schatzl wrote: > when crosscompiling to aarch64-linux I found the following errors > caused by latest -Wreorder changes. Oh yes, many build configs appear broken, see build logs here: https://builds.shipilev.net/openjdk-jdk/ > It would be nice if aarch64 devs could verify; I cc'ed aarch64 port dev > ml, but I do not know if this is the right list for this. It is! Red Hat AArch64 people are off this week. > CR: > https://bugs.openjdk.java.net/browse/JDK-8209193 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8209193/webrev/ This patch seems to resolve aarch64 build issues for me. I have only minor stylistic comments, these can be fixed before the push without another review. *) assembler_aarch64.hpp, L403, indenting if a bit off: 401 : _base(r), _index(noreg), _offset(0), _mode(base_plus_offset), _target(0) { } 402 Address(Register r, int o) 403 : _base(r), _index(noreg), _offset(o), _mode(base_plus_offset), _target(0) { } 404 Address(Register r, long o) 405 : _base(r), _index(noreg), _offset(o), _mode(base_plus_offset), _target(0) { } 406 Address(Register r, unsigned long o) 407 : _base(r), _index(noreg), _offset(o), _mode(base_plus_offset), _target(0) { } *) assembler_aarch64.hpp, L414, L419 -- indenting a bit off, the initializer list should start with a few additional spaces, like L422 does it: 412 Address(Register r, Register r1, extend ext = lsl()) 413 : _base(r), _index(r1), _offset(0), _mode(base_plus_offset_reg), 414 _ext(ext), _target(0) { } 415 Address(Pre p) 416 : _base(p.reg()), _offset(p.offset()), _mode(pre) { } 417 Address(Post p) 418 : _base(p.reg()), _index(p.idx_reg()), _offset(p.offset()), 419 _mode(p.idx_reg() == NULL ? post : post_reg), _target(0) { } 420 Address(address target, RelocationHolder const& rspec) 421 : _mode(literal), 422 _rspec(rspec), 423 _is_lval(false), 424 _target(target) { } *) assembler_aarch64.hpp: stray whitespace before _target, _offset, _index: 413 : _base(r), _index(r1), _offset(0), _mode(base_plus_offset_reg), ... 418 : _base(p.reg()), _index(p.idx_reg()), _offset(p.offset()), 419 _mode(p.idx_reg() == NULL ? post : post_reg), _target(0) { } Thanks, -Aleksey From gunter.haug at sap.com Fri Aug 10 14:10:35 2018 From: gunter.haug at sap.com (Haug, Gunter) Date: Fri, 10 Aug 2018 14:10:35 +0000 Subject: RFR (XXS): 8209357: PPC64: fix build with -Wreorder introduced with 8208672 In-Reply-To: References: <946137C1-1F23-4B63-A783-BDFE595DE497@sap.com> Message-ID: > looks good. I can sponsor. That would be very kind. Thanks, Gunter ?On 10.08.18, 15:21, "Thomas Schatzl" wrote: Hi, On Fri, 2018-08-10 at 13:04 +0000, Haug, Gunter wrote: > Hi all, > > -Wreorder introduced with 8208672 required a few changes in PPC64 > platform files to fix the build. Can I please have a review and a > sponsor for the following change: > > https://bugs.openjdk.java.net/projects/JDK/issues/JDK-8209357?filter= > reportedbyme > http://cr.openjdk.java.net/~ghaug/webrevs/820935/ > > Thanks a lot and have a nice weekend, > Gunter looks good. I can sponsor. Thanks, Thomas From coleen.phillimore at oracle.com Fri Aug 10 14:20:48 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 10 Aug 2018 10:20:48 -0400 Subject: RFR 8207924: serviceability/sa/TestUniverse.java#id0 intermittently fails with assert(get_instanceKlass()->is_loaded()) failed: must be at least loaded Message-ID: Summary: InstanceKlass::implementors() needs the Compile_lock open webrev at http://cr.openjdk.java.net/~coleenp/8207924.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8207924 Tested with mach5 hs-tier 1-5. Thanks, Coleen From tobias.hartmann at oracle.com Fri Aug 10 15:02:13 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 10 Aug 2018 17:02:13 +0200 Subject: RFR 8207924: serviceability/sa/TestUniverse.java#id0 intermittently fails with assert(get_instanceKlass()->is_loaded()) failed: must be at least loaded In-Reply-To: References: Message-ID: Hi Coleen, this looks good to me. Thanks for fixing! Best regards, Tobias On 10.08.2018 16:20, coleen.phillimore at oracle.com wrote: > Summary: InstanceKlass::implementors() needs the Compile_lock > > open webrev at http://cr.openjdk.java.net/~coleenp/8207924.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8207924 > > Tested with mach5 hs-tier 1-5. > > Thanks, > Coleen From coleen.phillimore at oracle.com Fri Aug 10 15:13:11 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 10 Aug 2018 11:13:11 -0400 Subject: RFR 8207924: serviceability/sa/TestUniverse.java#id0 intermittently fails with assert(get_instanceKlass()->is_loaded()) failed: must be at least loaded In-Reply-To: References: Message-ID: <3021f825-26e4-c521-a165-af82596c9b7f@oracle.com> Thanks, Tobias! Coleen On 8/10/18 11:02 AM, Tobias Hartmann wrote: > Hi Coleen, > > this looks good to me. Thanks for fixing! > > Best regards, > Tobias > > On 10.08.2018 16:20, coleen.phillimore at oracle.com wrote: >> Summary: InstanceKlass::implementors() needs the Compile_lock >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8207924.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8207924 >> >> Tested with mach5 hs-tier 1-5. >> >> Thanks, >> Coleen From Derek.White at cavium.com Fri Aug 10 15:34:05 2018 From: Derek.White at cavium.com (White, Derek) Date: Fri, 10 Aug 2018 15:34:05 +0000 Subject: [aarch64-port-dev ] RFR (S): 8209193: Fix aarch64-linux compilation after -Wreorder changes In-Reply-To: References: Message-ID: Looks good. Thanks for tackling this Thomas! - Derek > -----Original Message----- > From: aarch64-port-dev [mailto:aarch64-port-dev- > bounces at openjdk.java.net] On Behalf Of Thomas Schatzl > Sent: Friday, August 10, 2018 9:33 AM > To: hotspot-dev at openjdk.java.net > Cc: aarch64-port-dev at openjdk.java.net > Subject: [aarch64-port-dev ] RFR (S): 8209193: Fix aarch64-linux compilation > after -Wreorder changes > > External Email > > Hi, > > when crosscompiling to aarch64-linux I found the following errors caused > by latest -Wreorder changes. > > It would be nice if aarch64 devs could verify; I cc'ed aarch64 port dev ml, but > I do not know if this is the right list for this. > > Aarch32 is probably still broken. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8209193 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8209193/webrev/ > Testing: > successfully crosscompiled from amd64-linux to aarch64-linux > > Thanks, > Thomas From adam.farley at uk.ibm.com Fri Aug 10 15:58:30 2018 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Fri, 10 Aug 2018 16:58:30 +0100 Subject: RFR Bug-pending: Enable Hotspot to Track Native Memory Usage for Direct Byte Buffers Message-ID: -- Bump -- Hi Folks, > Zhengyu Gu wrote on 06/06/2018 01:58:18: > From: Zhengyu Gu > To: "Thomas St?fe" , Adam Farley8 > > Cc: "hotspot-dev at openjdk.java.net developers" dev at openjdk.java.net>, core-libs-dev > Date: 06/06/2018 01:58 > Subject: Re: RFR Bug-pending: Enable Hotspot to Track Native Memory > Usage for Direct Byte Buffers > > On 06/05/2018 12:10 PM, Thomas St?fe wrote:> On Tue, Jun 5, 2018 at 3:46 > PM, Adam Farley8 wrote: > >> Hi All, > >> > >> Native memory allocation for DBBs is tracked in java.nio.Bits, but that > >> only includes what the user thinks they are allocating. > >> > > > > Which is exactly what I would expect as a user... A debugger poring over the values in the file may prefer total accuracy in at least one of the variables, so they can find out where all their memory went in the event of a leak. Even if this variable is not accessible via a getter method, and is only readable via a system core. > > > > I agree with Thomas, there is no point for a user to aware of tracking > overhead, and the overhead only incurs when native memory tracking is > on. As a matter of fact, it can really confuse user that values can be > varied, depending on whether native memory tracking is on. > > Thanks, > > -Zhengyu I agree that the casual user shouldn't have to worry. This accuracy would be for analysis after the fact, via system cores. The standard variables can stay as they are. I suggest the addition of a single AtomicLong that shows an accurate value for the sole purpose of aiding debugging. > > > >> When the VM adds extra memory to the allocation amount this extra bit is > >> not represented in the Bits total. A cursory glance > >> shows, minimum, that we round the requested memory quantity up to the heap > >> word size in the Unsafe.allocateMemory code > > > > which I do not understand either - why do we do this? After all, > > normal allocations from inside hotspot do not get aligned up in size, > > and the java doc to Unsafe allocateMemory does not state anything > > about the size being aligned. > > > > In addition to questioning the align up of the user requested size, I > > would be in favor of adding a new NMT tag for these, maybe "mtUnsafe"? > > That would be an easy fix. > > > >> , and > >> something to do with nmt_header_size in os:malloc() (os.cpp) too. > > > > That is mighty unspecific and also wrong. The align-up mentioned above > > goes into the size reported by Bits; the nmt header size does not. > > I believe we agree here too. My point is that, for the sake of accuracy, we *should* have this information in Bits. This is part of the debugger-aid change that I am suggesting. > >> > >> On its own, and in small quantities, align_up(sz, HeapWordSize) isn't that > >> big of an issue. But when you allocate a lot of DBBs, > >> and coupled with the nmt_header_size business, it makes the Bits values > >> wrong. The more DBB allocations, the more inaccurate those > >> numbers will be. > > > > To be annoyingly precise, it will never be more wrong than 1:7 on > > 64bit machines :) - if all memory requested via Unsafe.allocateMemory > > would be of size 1 byte. Sounds like the sort of thing I'd do. Once a stress tester, always a stress tester. :) > > > >> > >> To get the "+X", it seems to me that the best option would be to introduce > >> an native method in Bits that fetches "X" directly > >> from Hotspot, using the same code that Hotspot uses (so we'd have to > >> abstract-out the Hotspot logic that adds X to the memory > >> quantity). This way, anyone modifying the Hotspot logic won't risk > >> rendering the Bits logic wrong again. > > > > I don't follow that. I was trying to describe one method to enable the VM to tell Bits how much memory will actually be reserved for a given amount of DBB. E.g. Bits says it has a DBB 7 bytes in size, and it tells the VM. The VM replies with "OK, if you came to me and asked for 7 bytes, I'd reserve 8.", and then Bits can update that debugging variable I mentioned. If we abstract out the logic, then Bits and the VM would be using the exact same code when telling Bits how much memory will *hypothetically* be added, as we do when the VM is determining how much overhead it needs when actually reserving the memory. Is that clearer? > > > >> > >> That's only one way to fix the accuracy problem here though. Suggestions > >> welcome. > > > > You are throwing two effects together: > > > > - As mentioned above, I consider the align-up of the user requested > > size to be at least questionable. It shows up as user size in NMT > > which should not be. I also fail to see a compelling reason for it, > > but maybe someone else can enlighten me. Well, if we got rid of it then that's one way to make the Bits variables accurate. :) > > > > - But anything else - NMT headers, overwriter guards, etc added by the > > VM I consider in the same class as any other overhead incurred e.g. by > > the CRT or the OS when calling malloc (e.g. malloc allocator bucket > > size). Basically, rss will go up by more than size requested by > > malloc. Something maybe worth noting, but IMHO not as part of the > > numbers returned by java.nio.Bits. We agree again. No need to confuse things by altering the return values. Simply store the accurate information internally as a debugging aid. > > > > Just my 2 cents. And they are appreciated. Apologies for the delay in my response. - Adam > > > > Best Regards, Thomas > > > >> > >> Best Regards > >> > >> Adam Farley > >> Unless stated otherwise above: > >> IBM United Kingdom Limited - Registered in England and Wales with number > >> 741598. > >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From navy.xliu at gmail.com Fri Aug 10 16:22:53 2018 From: navy.xliu at gmail.com (Liu Xin) Date: Fri, 10 Aug 2018 09:22:53 -0700 Subject: [12] RFR(S) 8209165: [GRAAL] Skip Graal build if C1 is not present In-Reply-To: References: <49e14f86-c399-f469-2150-e9ac248647c9@oracle.com> <538BEF87-5114-4AD3-BC00-7B5B0983BC6C@gmail.com> Message-ID: Vladimir, I am quite new area. Why Graal needs its own GC and small runtime? Theoretically, jaotc compiles some Java classes. It doesn?t need to know that those classes are themselves. My original thought is straight-forward. Compile Graal classes using JOT, load them to avoid from warming-up. I compiled both modules: ./jdk/bin/jaotc --module jdk.internal.vm.ci --output libHotspotCI.dylib ./jdk/bin/jaotc --module jdk.internal.vm.compiler --output libHotspotCompiler.dylib And I loaded them to run. ./jdk/bin/java -XX:+PrintCompilation \ -XX:+UnlockExperimentalVMOptions \ -XX:+EnableJVMCI \ -XX:+UseJVMCICompiler -XX:AOTLibrary=./libHotspotCI.dylib:./libHotSpotCompiler.dylib -cp . Demo |& tee jvmci_with_aot_graal.output Does it work? I took a look the output of PrintCompilation. I found many methods are marked 'made not entrant?. It means that hotspot deoptimize them right? > On Aug 9, 2018, at 11:26 AM, Vladimir Kozlov wrote: > > > My main motivation is that it is not supported configuration for us. And if you don't use Graal you waste space with Graal module. From erik.osterlund at oracle.com Fri Aug 10 16:57:23 2018 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Fri, 10 Aug 2018 18:57:23 +0200 Subject: RFR 8207924: serviceability/sa/TestUniverse.java#id0 intermittently fails with assert(get_instanceKlass()->is_loaded()) failed: must be at least loaded In-Reply-To: References: Message-ID: <7A928D87-E5D9-4E83-AFC9-04DBFF06BF0C@oracle.com> Hi Coleen, Looks good. Thanks, /Erik > On 10 Aug 2018, at 16:20, coleen.phillimore at oracle.com wrote: > > Summary: InstanceKlass::implementors() needs the Compile_lock > > open webrev at http://cr.openjdk.java.net/~coleenp/8207924.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8207924 > > Tested with mach5 hs-tier 1-5. > > Thanks, > Coleen From coleen.phillimore at oracle.com Fri Aug 10 17:11:53 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 10 Aug 2018 13:11:53 -0400 Subject: RFR 8207924: serviceability/sa/TestUniverse.java#id0 intermittently fails with assert(get_instanceKlass()->is_loaded()) failed: must be at least loaded In-Reply-To: <7A928D87-E5D9-4E83-AFC9-04DBFF06BF0C@oracle.com> References: <7A928D87-E5D9-4E83-AFC9-04DBFF06BF0C@oracle.com> Message-ID: <7a5f8e67-2b8a-cbd9-7817-e71706686d82@oracle.com> Thanks, Erik! Coleen On 8/10/18 12:57 PM, Erik Osterlund wrote: > Hi Coleen, > > Looks good. > > Thanks, > /Erik > >> On 10 Aug 2018, at 16:20, coleen.phillimore at oracle.com wrote: >> >> Summary: InstanceKlass::implementors() needs the Compile_lock >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8207924.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8207924 >> >> Tested with mach5 hs-tier 1-5. >> >> Thanks, >> Coleen From aleksei.voitylov at bell-sw.com Fri Aug 10 17:34:03 2018 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Fri, 10 Aug 2018 20:34:03 +0300 Subject: [12] RFR(XS): 8209378: Fix Minimal VM after JDK-8208677 Message-ID: <18c2cbbe-ce31-68b5-93fd-b31e6cce9636@bell-sw.com> Hi, JDK-8208677 introduced a new include dependency which caused the Minimal VM builds to fail. Please review the following patch to fix this problem: Bug: https://bugs.openjdk.java.net/browse/JDK-8209378 Webrev: http://cr.openjdk.java.net/~avoitylov/8209378/ With this fix, Minimal VM runs fine. Thanks, -Aleksei From aleksei.voitylov at bell-sw.com Fri Aug 10 17:40:38 2018 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Fri, 10 Aug 2018 20:40:38 +0300 Subject: RFR (S): 8209193: Fix aarch64-linux compilation after -Wreorder changes In-Reply-To: References: Message-ID: <703fcd41-ccaa-413d-6fdf-aa053b74011c@bell-sw.com> On 10/08/2018 16:32, Thomas Schatzl wrote: > Hi, > > when crosscompiling to aarch64-linux I found the following errors > caused by latest -Wreorder changes. > > It would be nice if aarch64 devs could verify; I cc'ed aarch64 port dev > ml, but I do not know if this is the right list for this. > > Aarch32 is probably still broken. Thanks for reminding. I'll take care of this together with some other -W issues on ARM 32: https://bugs.openjdk.java.net/browse/JDK-8209380 > > CR: > https://bugs.openjdk.java.net/browse/JDK-8209193 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8209193/webrev/ > Testing: > successfully crosscompiled from amd64-linux to aarch64-linux > > Thanks, > Thomas From aleksei.voitylov at bell-sw.com Fri Aug 10 17:53:49 2018 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Fri, 10 Aug 2018 20:53:49 +0300 Subject: [12] RFR(S): ARM: cleanup maybe-uninitialized and reorder compiler warnings Message-ID: <5ac447e1-0be8-e446-c5e3-660718704a83@bell-sw.com> Hi, please review this patch to cleanup -Wreorder and -Wmaybe-uninitialized gcc warnings on ARM32: Webrev: http://cr.openjdk.java.net/~avoitylov/8209380/ Bug: https://bugs.openjdk.java.net/browse/JDK-8209380 With this patch, ARM32 builds without warnings. Thanks, -Aleksei From vladimir.kozlov at oracle.com Fri Aug 10 17:58:15 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 10 Aug 2018 10:58:15 -0700 Subject: [12] RFR(S) 8209165: [GRAAL] Skip Graal build if C1 is not present In-Reply-To: References: <49e14f86-c399-f469-2150-e9ac248647c9@oracle.com> <538BEF87-5114-4AD3-BC00-7B5B0983BC6C@gmail.com> Message-ID: <3738a2e8-5936-350b-2ddb-dd40c304481e@oracle.com> Yes, you can do that to avoid missing C1 issue with Graal. But it is "too complicated" for end user ;) User have to generate these libraries himself. On other hand we are planning to ship libgraal.so with JDK. And with this you solve only startup problem. Even that is questionable based on our experiments. If AOT library is big (like when you compile whole module), its load time and symbols resolution offsets benefit of pre-compilation. Also produced like that AOT code is just extension from existing code in CodeCache. It still shares Java heap with application during compilation and have other side effects. It could be deoptimized as you noticed and go into Interpreter polluting profiling again. It happens because we make very conservative assumptions during AOT compilation. Yes, there are different ways to solve GRaal's issues and we decided to go with libgraal.so as we think it will solve most of these issues. Regards, Vladimir On 8/10/18 9:22 AM, Liu Xin wrote: > Vladimir, > > I am quite new area. Why Graal needs its own GC and small runtime? Theoretically, jaotc compiles some Java classes. It doesn?t need to know that those classes are themselves. > My original thought is straight-forward. Compile Graal classes using JOT, load them to avoid from warming-up. > > I compiled both modules: > ./jdk/bin/jaotc --module jdk.internal.vm.ci --output libHotspotCI.dylib > ./jdk/bin/jaotc --module jdk.internal.vm.compiler --output libHotspotCompiler.dylib > > And I loaded them to run. > ./jdk/bin/java -XX:+PrintCompilation \ > -XX:+UnlockExperimentalVMOptions \ > -XX:+EnableJVMCI \ > -XX:+UseJVMCICompiler -XX:AOTLibrary=./libHotspotCI.dylib:./libHotSpotCompiler.dylib -cp . Demo |& tee jvmci_with_aot_graal.output > > Does it work? I took a look the output of PrintCompilation. > I found many methods are marked 'made not entrant?. It means that hotspot deoptimize them right? > > >> On Aug 9, 2018, at 11:26 AM, Vladimir Kozlov wrote: >> >> >> My main motivation is that it is not supported configuration for us. And if you don't use Graal you waste space with Graal module. > From navy.xliu at gmail.com Fri Aug 10 18:35:31 2018 From: navy.xliu at gmail.com (Liu Xin) Date: Fri, 10 Aug 2018 11:35:31 -0700 Subject: [12] RFR(S) 8209165: [GRAAL] Skip Graal build if C1 is not present In-Reply-To: <3738a2e8-5936-350b-2ddb-dd40c304481e@oracle.com> References: <49e14f86-c399-f469-2150-e9ac248647c9@oracle.com> <538BEF87-5114-4AD3-BC00-7B5B0983BC6C@gmail.com> <3738a2e8-5936-350b-2ddb-dd40c304481e@oracle.com> Message-ID: thank you. I got it. I will take a closer look at project Metropolis and substratevm . thanks, --lx On Fri, Aug 10, 2018 at 10:58 AM Vladimir Kozlov wrote: > Yes, you can do that to avoid missing C1 issue with Graal. But it is "too > complicated" for end user ;) > User have to generate these libraries himself. On other hand we are > planning to ship libgraal.so with JDK. > > And with this you solve only startup problem. Even that is questionable > based on our experiments. If AOT library is big > (like when you compile whole module), its load time and symbols resolution > offsets benefit of pre-compilation. > > Also produced like that AOT code is just extension from existing code in > CodeCache. It still shares Java heap with > application during compilation and have other side effects. It could be > deoptimized as you noticed and go into > Interpreter polluting profiling again. It happens because we make very > conservative assumptions during AOT compilation. > > Yes, there are different ways to solve GRaal's issues and we decided to go > with libgraal.so as we think it will solve > most of these issues. > > Regards, > Vladimir > > On 8/10/18 9:22 AM, Liu Xin wrote: > > Vladimir, > > > > I am quite new area. Why Graal needs its own GC and small runtime? > Theoretically, jaotc compiles some Java classes. It doesn?t need to know > that those classes are themselves. > > My original thought is straight-forward. Compile Graal classes using > JOT, load them to avoid from warming-up. > > > > I compiled both modules: > > ./jdk/bin/jaotc --module jdk.internal.vm.ci --output > libHotspotCI.dylib > > ./jdk/bin/jaotc --module jdk.internal.vm.compiler --output > libHotspotCompiler.dylib > > > > And I loaded them to run. > > ./jdk/bin/java -XX:+PrintCompilation \ > > -XX:+UnlockExperimentalVMOptions \ > > -XX:+EnableJVMCI \ > > -XX:+UseJVMCICompiler > -XX:AOTLibrary=./libHotspotCI.dylib:./libHotSpotCompiler.dylib -cp . Demo > |& tee jvmci_with_aot_graal.output > > > > Does it work? I took a look the output of PrintCompilation. > > I found many methods are marked 'made not entrant?. It means that > hotspot deoptimize them right? > > > > > >> On Aug 9, 2018, at 11:26 AM, Vladimir Kozlov < > vladimir.kozlov at oracle.com> wrote: > >> > >> > >> My main motivation is that it is not supported configuration for us. > And if you don't use Graal you waste space with Graal module. > > > From coleen.phillimore at oracle.com Fri Aug 10 18:41:44 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 10 Aug 2018 14:41:44 -0400 Subject: [12] RFR(XS): 8209378: Fix Minimal VM after JDK-8208677 In-Reply-To: <18c2cbbe-ce31-68b5-93fd-b31e6cce9636@bell-sw.com> References: <18c2cbbe-ce31-68b5-93fd-b31e6cce9636@bell-sw.com> Message-ID: <6b2e82a5-984e-c345-6b96-80e7bbf247bd@oracle.com> This seems fine and trivial.? Thank you for fixing it.? I thought redefinition was included in the minimal vm? Coleen On 8/10/18 1:34 PM, Aleksei Voitylov wrote: > Hi, > > JDK-8208677 introduced a new include dependency which caused the > Minimal VM builds to fail. Please review the following patch to fix > this problem: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8209378 > Webrev: http://cr.openjdk.java.net/~avoitylov/8209378/ > > With this fix, Minimal VM runs fine. > > Thanks, > > -Aleksei > From Derek.White at cavium.com Fri Aug 10 19:05:32 2018 From: Derek.White at cavium.com (White, Derek) Date: Fri, 10 Aug 2018 19:05:32 +0000 Subject: [12] RFR(S): ARM: cleanup maybe-uninitialized and reorder compiler warnings In-Reply-To: <5ac447e1-0be8-e446-c5e3-660718704a83@bell-sw.com> References: <5ac447e1-0be8-e446-c5e3-660718704a83@bell-sw.com> Message-ID: Looks good! - Derek > -----Original Message----- > From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On > Behalf Of Aleksei Voitylov > Sent: Friday, August 10, 2018 1:54 PM > To: hotspot-dev at openjdk.java.net > Subject: [12] RFR(S): ARM: cleanup maybe-uninitialized and reorder compiler > warnings > > External Email > > Hi, > > please review this patch to cleanup -Wreorder and -Wmaybe-uninitialized > gcc warnings on ARM32: > > Webrev: http://cr.openjdk.java.net/~avoitylov/8209380/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8209380 > > With this patch, ARM32 builds without warnings. > > Thanks, > > -Aleksei From aleksei.voitylov at bell-sw.com Fri Aug 10 21:11:30 2018 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Sat, 11 Aug 2018 00:11:30 +0300 Subject: [12] RFR(XS): 8209378: Fix Minimal VM after JDK-8208677 In-Reply-To: <6b2e82a5-984e-c345-6b96-80e7bbf247bd@oracle.com> References: <18c2cbbe-ce31-68b5-93fd-b31e6cce9636@bell-sw.com> <6b2e82a5-984e-c345-6b96-80e7bbf247bd@oracle.com> Message-ID: <7b686c56-b50c-d2ed-7c86-6f5f23bf2165@bell-sw.com> Hi Coleen, Minimal VM does not support JVMTI, Instrumentation and JMX. Appreciate if you could sponsor this. -Aleksei On 10/08/2018 21:41, coleen.phillimore at oracle.com wrote: > > This seems fine and trivial.? Thank you for fixing it.? I thought > redefinition was included in the minimal vm? > > Coleen > > On 8/10/18 1:34 PM, Aleksei Voitylov wrote: >> Hi, >> >> JDK-8208677 introduced a new include dependency which caused the >> Minimal VM builds to fail. Please review the following patch to fix >> this problem: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8209378 >> Webrev: http://cr.openjdk.java.net/~avoitylov/8209378/ >> >> With this fix, Minimal VM runs fine. >> >> Thanks, >> >> -Aleksei >> > From martinrb at google.com Sat Aug 11 00:41:27 2018 From: martinrb at google.com (Martin Buchholz) Date: Fri, 10 Aug 2018 17:41:27 -0700 Subject: Using C++11+ in hotspot In-Reply-To: References: <6D166068-9FA9-4B0B-A157-0CB109753F4C@oracle.com> <347ce2b1-550b-112c-6a76-3c1657f48a7b@redhat.com> Message-ID: OK, it looks like -fno-strict-aliasing is here to stay. Casting freely between pointers to different types is pervasive in the source code, and there's insufficient discipline in the culture to try to fix it. And I'm not volunteering. static void pd_arrayof_conjoint_jlongs(const HeapWord* from, HeapWord* to, size_t count) { #ifdef AMD64 _Copy_arrayof_conjoint_jlongs(from, to, count); #else pd_conjoint_jlongs_atomic((const jlong*)from, (jlong*)to, count); #endif // AMD64 } static void pd_arrayof_conjoint_oops(const HeapWord* from, HeapWord* to, size_t count) { #ifdef AMD64 assert(BytesPerLong == BytesPerOop, "jlongs and oops must be the same size"); _Copy_arrayof_conjoint_jlongs(from, to, count); #else pd_conjoint_oops_atomic((const oop*)from, (oop*)to, count); #endif // AMD64 } On Fri, Aug 10, 2018 at 5:59 AM, Andrew Haley wrote: > On 08/08/2018 08:51 PM, Martin Buchholz wrote: > > I'd like to see hotspot stop using the -fno-strict-aliasing curtch, > > replacing it with union and/or may_alias, but this is a serious > investment. > > It's a serious investment, and we'd risk breaking stuff. At least the > entire > heap would have to be an array with elements which are a union of all of > the > possible types, and there'd be a byte array overlaid on top of that. It > would > not be pretty. From david.holmes at oracle.com Sun Aug 12 22:32:53 2018 From: david.holmes at oracle.com (David Holmes) Date: Mon, 13 Aug 2018 08:32:53 +1000 Subject: [12] RFR(S): ARM: cleanup maybe-uninitialized and reorder compiler warnings In-Reply-To: <5ac447e1-0be8-e446-c5e3-660718704a83@bell-sw.com> References: <5ac447e1-0be8-e446-c5e3-660718704a83@bell-sw.com> Message-ID: Looks good. Please include the bug id in the RFR synopsis in future. Thanks, David On 11/08/2018 3:53 AM, Aleksei Voitylov wrote: > Hi, > > please review this patch to cleanup -Wreorder and -Wmaybe-uninitialized > gcc warnings on ARM32: > > Webrev: http://cr.openjdk.java.net/~avoitylov/8209380/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8209380 > > With this patch, ARM32 builds without warnings. > > Thanks, > > -Aleksei > From aleksei.voitylov at bell-sw.com Mon Aug 13 05:14:21 2018 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Mon, 13 Aug 2018 08:14:21 +0300 Subject: [12] RFR(S): ARM: cleanup maybe-uninitialized and reorder compiler warnings In-Reply-To: References: <5ac447e1-0be8-e446-c5e3-660718704a83@bell-sw.com> Message-ID: <24848a97-ff8d-c7c6-ad66-2c86e6ee4404@bell-sw.com> Derek, David, thank you for review and sorry I forgot to include the bug id in the synopsis. -Aleksei On 13/08/2018 01:32, David Holmes wrote: > Looks good. > > Please include the bug id in the RFR synopsis in future. > > Thanks, > David > > On 11/08/2018 3:53 AM, Aleksei Voitylov wrote: >> Hi, >> >> please review this patch to cleanup -Wreorder and >> -Wmaybe-uninitialized gcc warnings on ARM32: >> >> Webrev: http://cr.openjdk.java.net/~avoitylov/8209380/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8209380 >> >> With this patch, ARM32 builds without warnings. >> >> Thanks, >> >> -Aleksei >> From thomas.schatzl at oracle.com Mon Aug 13 07:57:14 2018 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 13 Aug 2018 09:57:14 +0200 Subject: [12] RFR(S): ARM: cleanup maybe-uninitialized and reorder compiler warnings In-Reply-To: <5ac447e1-0be8-e446-c5e3-660718704a83@bell-sw.com> References: <5ac447e1-0be8-e446-c5e3-660718704a83@bell-sw.com> Message-ID: Hi, On Fri, 2018-08-10 at 20:53 +0300, Aleksei Voitylov wrote: > Hi, > > please review this patch to cleanup -Wreorder and -Wmaybe- > uninitialized > gcc warnings on ARM32: > > Webrev: http://cr.openjdk.java.net/~avoitylov/8209380/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8209380 > > With this patch, ARM32 builds without warnings. looks good. I can sponsor. Thomas From aleksei.voitylov at bell-sw.com Mon Aug 13 08:02:57 2018 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Mon, 13 Aug 2018 11:02:57 +0300 Subject: [12] RFR(S): ARM: cleanup maybe-uninitialized and reorder compiler warnings In-Reply-To: References: <5ac447e1-0be8-e446-c5e3-660718704a83@bell-sw.com> Message-ID: <16238183-1fb8-6742-3e32-98123bea77fc@bell-sw.com> Thank you Thomas for review and appreciate if you could sponsor! On 13/08/2018 10:57, Thomas Schatzl wrote: > Hi, > > On Fri, 2018-08-10 at 20:53 +0300, Aleksei Voitylov wrote: >> Hi, >> >> please review this patch to cleanup -Wreorder and -Wmaybe- >> uninitialized >> gcc warnings on ARM32: >> >> Webrev: http://cr.openjdk.java.net/~avoitylov/8209380/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8209380 >> >> With this patch, ARM32 builds without warnings. > looks good. > > I can sponsor. > > Thomas From shade at redhat.com Mon Aug 13 08:10:34 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 13 Aug 2018 10:10:34 +0200 Subject: [12] RFR(XS): 8209378: Fix Minimal VM after JDK-8208677 In-Reply-To: <7b686c56-b50c-d2ed-7c86-6f5f23bf2165@bell-sw.com> References: <18c2cbbe-ce31-68b5-93fd-b31e6cce9636@bell-sw.com> <6b2e82a5-984e-c345-6b96-80e7bbf247bd@oracle.com> <7b686c56-b50c-d2ed-7c86-6f5f23bf2165@bell-sw.com> Message-ID: <2e08d4bf-374e-d822-ddc2-61c23112dac7@redhat.com> On 08/10/2018 11:11 PM, Aleksei Voitylov wrote: >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8209378 >>> Webrev: http://cr.openjdk.java.net/~avoitylov/8209378/ Looks good. I will sponsor this. -Aleksey From thomas.schatzl at oracle.com Mon Aug 13 08:11:32 2018 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 13 Aug 2018 10:11:32 +0200 Subject: [aarch64-port-dev ] RFR (S): 8209193: Fix aarch64-linux compilation after -Wreorder changes In-Reply-To: References: Message-ID: <2b5ad3d5fbf746f653c4ec13dd111628a358cd31.camel@oracle.com> Hi Derek, On Fri, 2018-08-10 at 15:34 +0000, White, Derek wrote: > Looks good. Thanks for tackling this Thomas! thanks for your review. Thomas From thomas.schatzl at oracle.com Mon Aug 13 08:12:13 2018 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 13 Aug 2018 10:12:13 +0200 Subject: RFR (S): 8209193: Fix aarch64-linux compilation after -Wreorder changes In-Reply-To: References: Message-ID: Hi, On Fri, 2018-08-10 at 15:56 +0200, Aleksey Shipilev wrote: > Hi Thomas, > > On 08/10/2018 03:32 PM, Thomas Schatzl wrote: > > when crosscompiling to aarch64-linux I found the following errors > > caused by latest -Wreorder changes. > > Oh yes, many build configs appear broken, see build logs here: > https://builds.shipilev.net/openjdk-jdk/ > I think ppc64 has been fixed, and the minimal builds are another issue. Arm32 is fixed too. The only remaining is s390 it seems. > > It would be nice if aarch64 devs could verify; I cc'ed aarch64 port > > dev ml, but I do not know if this is the right list for this. > > It is! Red Hat AArch64 people are off this week. > > > CR: > > https://bugs.openjdk.java.net/browse/JDK-8209193 > > Webrev: > > http://cr.openjdk.java.net/~tschatzl/8209193/webrev/ > > This patch seems to resolve aarch64 build issues for me. > > I have only minor stylistic comments, these can be fixed before the > push without another review. > [...] All fixed. Thanks for your review. Thomas From stuart.monteith at linaro.org Mon Aug 13 08:38:46 2018 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Mon, 13 Aug 2018 09:38:46 +0100 Subject: [aarch64-port-dev ] RFR (S): 8209193: Fix aarch64-linux compilation after -Wreorder changes In-Reply-To: References: Message-ID: Hi, The changes look good to me - they are identical to the patch I was writing. The results from a jtreg test run look satisfactory. Thanks, Stuart On Fri, 10 Aug 2018 at 14:32, Thomas Schatzl wrote: > > Hi, > > when crosscompiling to aarch64-linux I found the following errors > caused by latest -Wreorder changes. > > It would be nice if aarch64 devs could verify; I cc'ed aarch64 port dev > ml, but I do not know if this is the right list for this. > > Aarch32 is probably still broken. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8209193 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8209193/webrev/ > Testing: > successfully crosscompiled from amd64-linux to aarch64-linux > > Thanks, > Thomas From aph at redhat.com Mon Aug 13 09:09:48 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 13 Aug 2018 10:09:48 +0100 Subject: [aarch64-port-dev ] RFR (S): 8209193: Fix aarch64-linux compilation after -Wreorder changes In-Reply-To: <703fcd41-ccaa-413d-6fdf-aa053b74011c@bell-sw.com> References: <703fcd41-ccaa-413d-6fdf-aa053b74011c@bell-sw.com> Message-ID: On 08/10/2018 06:40 PM, Aleksei Voitylov wrote: > > > On 10/08/2018 16:32, Thomas Schatzl wrote: >> Hi, >> >> when crosscompiling to aarch64-linux I found the following errors >> caused by latest -Wreorder changes. >> >> It would be nice if aarch64 devs could verify; I cc'ed aarch64 port dev >> ml, but I do not know if this is the right list for this. >> >> Aarch32 is probably still broken. > Thanks for reminding. I'll take care of this together with some other -W But there are other very important issues: I can't see the ARM32 code for 8203172: Primitive heap access for interpreter BarrierSetAssembler/aarch64 -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aleksei.voitylov at bell-sw.com Mon Aug 13 09:34:54 2018 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Mon, 13 Aug 2018 12:34:54 +0300 Subject: [aarch64-port-dev ] RFR (S): 8209193: Fix aarch64-linux compilation after -Wreorder changes In-Reply-To: References: <703fcd41-ccaa-413d-6fdf-aa053b74011c@bell-sw.com> Message-ID: <3ad48d77-b896-cae0-d908-0c60f2b4dbfb@bell-sw.com> Thanks, this will also be dealt with: https://bugs.openjdk.java.net/browse/JDK-8209408 . Anything else you might have spotted that is missing in ARM port? -Aleksei On 13/08/2018 12:09, Andrew Haley wrote: > On 08/10/2018 06:40 PM, Aleksei Voitylov wrote: >> >> On 10/08/2018 16:32, Thomas Schatzl wrote: >>> Hi, >>> >>> when crosscompiling to aarch64-linux I found the following errors >>> caused by latest -Wreorder changes. >>> >>> It would be nice if aarch64 devs could verify; I cc'ed aarch64 port dev >>> ml, but I do not know if this is the right list for this. >>> >>> Aarch32 is probably still broken. >> Thanks for reminding. I'll take care of this together with some other -W > But there are other very important issues: I can't see the ARM32 code for > > 8203172: Primitive heap access for interpreter BarrierSetAssembler/aarch64 > From aleksei.voitylov at bell-sw.com Mon Aug 13 10:06:30 2018 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Mon, 13 Aug 2018 13:06:30 +0300 Subject: [12] RFR(XS): 8209378: Fix Minimal VM after JDK-8208677 In-Reply-To: <2e08d4bf-374e-d822-ddc2-61c23112dac7@redhat.com> References: <18c2cbbe-ce31-68b5-93fd-b31e6cce9636@bell-sw.com> <6b2e82a5-984e-c345-6b96-80e7bbf247bd@oracle.com> <7b686c56-b50c-d2ed-7c86-6f5f23bf2165@bell-sw.com> <2e08d4bf-374e-d822-ddc2-61c23112dac7@redhat.com> Message-ID: Thank you for review and sponsorship Aleksey! On 13/08/2018 11:10, Aleksey Shipilev wrote: > On 08/10/2018 11:11 PM, Aleksei Voitylov wrote: >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8209378 >>>> Webrev: http://cr.openjdk.java.net/~avoitylov/8209378/ > Looks good. I will sponsor this. > > -Aleksey > From aph at redhat.com Mon Aug 13 10:59:46 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 13 Aug 2018 11:59:46 +0100 Subject: [aarch64-port-dev ] RFR (S): 8209193: Fix aarch64-linux compilation after -Wreorder changes In-Reply-To: <3ad48d77-b896-cae0-d908-0c60f2b4dbfb@bell-sw.com> References: <703fcd41-ccaa-413d-6fdf-aa053b74011c@bell-sw.com> <3ad48d77-b896-cae0-d908-0c60f2b4dbfb@bell-sw.com> Message-ID: <2d3a05c1-3a28-f76d-df0d-ea586fc3c837@redhat.com> On 08/13/2018 10:34 AM, Aleksei Voitylov wrote: > Thanks, this will also be dealt with: > https://bugs.openjdk.java.net/browse/JDK-8209408 . Anything else you > might have spotted that is missing in ARM port? It must have been unmaintained for some time. I think you'll just have to go through all of the AArch64 updates and check they're all done. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From lutz.schmidt at sap.com Tue Aug 14 11:16:02 2018 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Tue, 14 Aug 2018 11:16:02 +0000 Subject: RFR(XS): 8209433: [s390] Fix build, broken by 8208672 (Enable -Wreorder) Message-ID: <6406C730-4774-4B47-A031-AC1866B2975C@sap.com> Dear all, I?d like to request reviews for this tiny, s390x only change. The fix is quite similar to JDK-8209357 (ppc). The issue was not immediately detected because -Werror was not active in our build for some reason. Here we go: Bug: https://bugs.openjdk.java.net/browse/JDK-8209433 Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8209433.00/ Thank you! Lutz From shade at redhat.com Tue Aug 14 11:24:23 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 14 Aug 2018 13:24:23 +0200 Subject: RFR(XS): 8209433: [s390] Fix build, broken by 8208672 (Enable -Wreorder) In-Reply-To: <6406C730-4774-4B47-A031-AC1866B2975C@sap.com> References: <6406C730-4774-4B47-A031-AC1866B2975C@sap.com> Message-ID: On 08/14/2018 01:16 PM, Schmidt, Lutz wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8209433 > Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8209433.00/ Looks good and trivial. Thanks, that would fix the only remaining trouble with building jdk/jdk. -Aleksey From thomas.schatzl at oracle.com Tue Aug 14 11:43:47 2018 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 14 Aug 2018 13:43:47 +0200 Subject: RFR(XS): 8209433: [s390] Fix build, broken by 8208672 (Enable -Wreorder) In-Reply-To: <6406C730-4774-4B47-A031-AC1866B2975C@sap.com> References: <6406C730-4774-4B47-A031-AC1866B2975C@sap.com> Message-ID: <1e2c75ea8a41f9366539a41b17a7c36f32d5cb5e.camel@oracle.com> Hi, On Tue, 2018-08-14 at 11:16 +0000, Schmidt, Lutz wrote: > Dear all, > > I?d like to request reviews for this tiny, s390x only change. The fix > is quite similar to JDK-8209357 (ppc). The issue was not immediately > detected because -Werror was not active in our build for some reason. > Here we go: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8209433 > Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8209433.00/ > looks good. Thank you. Thomas From lutz.schmidt at sap.com Tue Aug 14 12:12:10 2018 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Tue, 14 Aug 2018 12:12:10 +0000 Subject: RFR(XS): 8209433: [s390] Fix build, broken by 8208672 (Enable -Wreorder) In-Reply-To: References: <6406C730-4774-4B47-A031-AC1866B2975C@sap.com> Message-ID: <35AF54D2-A398-48F4-B8F5-3417B1804A07@sap.com> Thank you, Aleksey! Regards, Lutz ?On 14.08.18, 13:24, "Aleksey Shipilev" wrote: On 08/14/2018 01:16 PM, Schmidt, Lutz wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8209433 > Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8209433.00/ Looks good and trivial. Thanks, that would fix the only remaining trouble with building jdk/jdk. -Aleksey From lutz.schmidt at sap.com Tue Aug 14 12:12:48 2018 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Tue, 14 Aug 2018 12:12:48 +0000 Subject: RFR(XS): 8209433: [s390] Fix build, broken by 8208672 (Enable -Wreorder) In-Reply-To: <1e2c75ea8a41f9366539a41b17a7c36f32d5cb5e.camel@oracle.com> References: <6406C730-4774-4B47-A031-AC1866B2975C@sap.com> <1e2c75ea8a41f9366539a41b17a7c36f32d5cb5e.camel@oracle.com> Message-ID: <16847A06-15C5-4BBB-A922-18DABC398A2F@sap.com> Thank you, Thomas! Regards, Lutz ?On 14.08.18, 13:43, "Thomas Schatzl" wrote: Hi, On Tue, 2018-08-14 at 11:16 +0000, Schmidt, Lutz wrote: > Dear all, > > I?d like to request reviews for this tiny, s390x only change. The fix > is quite similar to JDK-8209357 (ppc). The issue was not immediately > detected because -Werror was not active in our build for some reason. > Here we go: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8209433 > Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8209433.00/ > looks good. Thank you. Thomas From aph at redhat.com Tue Aug 14 12:47:37 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 14 Aug 2018 13:47:37 +0100 Subject: RFR [11] 8207838: AArch64: Float registers incorrectly resture in JNI call Message-ID: When we make a JNI call with several floating-point args they are pushed and then popped in the reverse order. The fix it trivial and obvious and affects AArch64 only. The patch also affects non-AArch64 targets only in that it adds a test for this case. OK for 11? https://bugs.openjdk.java.net/browse/JDK-8207838 http://cr.openjdk.java.net/~fyang/8207838/webrev.00/ -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From david.buck at oracle.com Tue Aug 14 13:29:06 2018 From: david.buck at oracle.com (David Buck) Date: Tue, 14 Aug 2018 22:29:06 +0900 Subject: [8] RFR (S) 8033251: Use DWARF debug symbols for Linux 32-bit as default Message-ID: <56cfd727-4833-8b8c-34c3-d8454bfb74ae@oracle.com> Hi! May I please get a review of this simple backport to replace stabs with DWARF for 32-bit Linux builds. This is needed as newer toolchains no longer support stabs. bug report: https://bugs.openjdk.java.net/browse/JDK-8033251 JDK 9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/2750fb4ad9ac JDK 8 webrev for review: http://cr.openjdk.java.net/~dbuck/8033251.0/ Cheers, -Buck From adinn at redhat.com Tue Aug 14 13:30:55 2018 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 14 Aug 2018 14:30:55 +0100 Subject: RFR [11] 8207838: AArch64: Float registers incorrectly resture in JNI call In-Reply-To: References: Message-ID: On 14/08/18 13:47, Andrew Haley wrote: > When we make a JNI call with several floating-point args they are > pushed and then popped in the reverse order. The fix it trivial and > obvious and affects AArch64 only. > > The patch also affects non-AArch64 targets only in that it adds a test > for this case. > > OK for 11? > > https://bugs.openjdk.java.net/browse/JDK-8207838 > > http://cr.openjdk.java.net/~fyang/8207838/webrev.00/ The fix looks good to me. However, since we are in rampdown phase two [1] and about to enter release candidate phase [2] I believe you need to justify getting it into 11 as per the Late-Enhancement Request Process [3]. So, it needs to be P1 or p2 and have a suitable justification provided in the JIRA. [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-July/001669.html [2] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-August/001803.html [3] http://openjdk.java.net/jeps/3 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 shade at redhat.com Tue Aug 14 13:32:41 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 14 Aug 2018 15:32:41 +0200 Subject: RFR [11] 8207838: AArch64: Float registers incorrectly resture in JNI call In-Reply-To: References: Message-ID: <10d5c14e-2aaf-7c15-062f-fba0bb313299@redhat.com> On 08/14/2018 02:47 PM, Andrew Haley wrote: > When we make a JNI call with several floating-point args they are > pushed and then popped in the reverse order. The fix it trivial and > obvious and affects AArch64 only. > > The patch also affects non-AArch64 targets only in that it adds a test > for this case. > > OK for 11? > > https://bugs.openjdk.java.net/browse/JDK-8207838 > http://cr.openjdk.java.net/~fyang/8207838/webrev.00/ Whoops. The fix looks good for 11, but I am not the actual approver :) In the test, why do we need to call the test in separate threads? AFAIU, throwing Error from those threads would print them out to stderr, but it would not have other effects, e.g. changing the exit code of the test itself, so failures may go unnoticed. Might be better to use ExecutorService, get the Future-s, and rethrow ExecutionExceptions. -Aleksey From tim.bell at oracle.com Tue Aug 14 13:56:18 2018 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 14 Aug 2018 06:56:18 -0700 Subject: [8] RFR (S) 8033251: Use DWARF debug symbols for Linux 32-bit as default In-Reply-To: <56cfd727-4833-8b8c-34c3-d8454bfb74ae@oracle.com> References: <56cfd727-4833-8b8c-34c3-d8454bfb74ae@oracle.com> Message-ID: <5B72DF82.4050906@oracle.com> Buck: > May I please get a review of this simple backport to replace stabs with > DWARF for 32-bit Linux builds. This is needed as newer toolchains no > longer support stabs. > > bug report: > https://bugs.openjdk.java.net/browse/JDK-8033251 > > JDK 9 changeset: > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/2750fb4ad9ac > > JDK 8 webrev for review: > http://cr.openjdk.java.net/~dbuck/8033251.0/ Looks good. Your changes are in line with what JDK 9 did, only a bit more specific to the ARCH that is building. In JDK 9 I see a check for $(FASTDEBUG_CFLAGS/$(BUILDARCH) but setting: FASTDEBUG_CFLAGS += -g In JDK 8 you check $(FASTDEBUG_CFLAGS/$(BUILDARCH)) and set: FASTDEBUG_CFLAGS/$(BUILDARCH) = -g and the same for $(OPT_CFLAGS/$(BUILDARCH) Tim From aph at redhat.com Tue Aug 14 15:05:32 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 14 Aug 2018 16:05:32 +0100 Subject: RFR [11] 8207838: AArch64: Float registers incorrectly resture in JNI call In-Reply-To: <10d5c14e-2aaf-7c15-062f-fba0bb313299@redhat.com> References: <10d5c14e-2aaf-7c15-062f-fba0bb313299@redhat.com> Message-ID: <3140f273-f608-e34e-1410-d18073a278d7@redhat.com> On 08/14/2018 02:32 PM, Aleksey Shipilev wrote: > On 08/14/2018 02:47 PM, Andrew Haley wrote: >> When we make a JNI call with several floating-point args they are >> pushed and then popped in the reverse order. The fix it trivial and >> obvious and affects AArch64 only. >> >> The patch also affects non-AArch64 targets only in that it adds a test >> for this case. >> >> OK for 11? >> >> https://bugs.openjdk.java.net/browse/JDK-8207838 >> http://cr.openjdk.java.net/~fyang/8207838/webrev.00/ > > Whoops. The fix looks good for 11, but I am not the actual approver :) > > In the test, why do we need to call the test in separate threads? AFAIU, throwing Error from those > threads would print them out to stderr, but it would not have other effects, e.g. changing the exit > code of the test itself, so failures may go unnoticed. Might be better to use ExecutorService, get > the Future-s, and rethrow ExecutionExceptions. Because the bad push/pop is only on the slow path when a lock has to be inflated. That's why we never noticed it before. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Tue Aug 14 15:08:33 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 14 Aug 2018 16:08:33 +0100 Subject: RFR [11] 8207838: AArch64: Float registers incorrectly resture in JNI call In-Reply-To: References: Message-ID: On 08/14/2018 02:30 PM, Andrew Dinn wrote: > The fix looks good to me. However, since we are in rampdown phase two > [1] and about to enter release candidate phase [2] I believe you need to > justify getting it into 11 as per the Late-Enhancement Request Process > [3]. So, it needs to be P1 or p2 and have a suitable justification > provided in the JIRA. I've done both. Please have allok to make sure it's right. Please feel free to add any commentary. https://bugs.openjdk.java.net/browse/JDK-8207838 -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From adinn at redhat.com Tue Aug 14 15:57:29 2018 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 14 Aug 2018 16:57:29 +0100 Subject: RFR [11] 8207838: AArch64: Float registers incorrectly resture in JNI call In-Reply-To: References: Message-ID: <2649730f-2d2b-c23c-c893-f4c83687a098@redhat.com> On 14/08/18 16:08, Andrew Haley wrote: > On 08/14/2018 02:30 PM, Andrew Dinn wrote: >> The fix looks good to me. However, since we are in rampdown phase two >> [1] and about to enter release candidate phase [2] I believe you need to >> justify getting it into 11 as per the Late-Enhancement Request Process >> [3]. So, it needs to be P1 or p2 and have a suitable justification >> provided in the JIRA. > > I've done both. Please have allok to make sure it's right. > Please feel free to add any commentary. > > https://bugs.openjdk.java.net/browse/JDK-8207838 Two more tweaks required: "Update the JBS issue to add a comment whose first line is ?Late Enhancement Request?. In that comment describe . . ." So, your comment needs the correct first line. "Add the label jdk$N-enhancement-request to the issue ..." The JIRA label field currently has rt-triage-12. So, you need to click in the JIRA label field and start typing jdk11-enhancement-request -- it should auto-complete. You can leave the existing label as is and add this as a second one. 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 vladimir.kozlov at oracle.com Tue Aug 14 16:07:19 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 14 Aug 2018 09:07:19 -0700 Subject: RFR [11] 8207838: AArch64: Float registers incorrectly resture in JNI call In-Reply-To: <2649730f-2d2b-c23c-c893-f4c83687a098@redhat.com> References: <2649730f-2d2b-c23c-c893-f4c83687a098@redhat.com> Message-ID: Andrew it is wrong. This is Bug not 'Enchantment'. You need to follow next instructions for fix request approval: http://openjdk.java.net/jeps/3#Fix-Request-Process In short: 1. Add label jdk11-fix-request 2. Add comment with first line is ?Fix Request?. 3. Add link to webrev. I will have to run changed tests on our platforms before approving it. Regards, Vladimir On 8/14/18 8:57 AM, Andrew Dinn wrote: > > > On 14/08/18 16:08, Andrew Haley wrote: >> On 08/14/2018 02:30 PM, Andrew Dinn wrote: >>> The fix looks good to me. However, since we are in rampdown phase two >>> [1] and about to enter release candidate phase [2] I believe you need to >>> justify getting it into 11 as per the Late-Enhancement Request Process >>> [3]. So, it needs to be P1 or p2 and have a suitable justification >>> provided in the JIRA. >> >> I've done both. Please have allok to make sure it's right. >> Please feel free to add any commentary. >> >> https://bugs.openjdk.java.net/browse/JDK-8207838 > Two more tweaks required: > > "Update the JBS issue to add a comment whose first line is ?Late > Enhancement Request?. In that comment describe . . ." > > So, your comment needs the correct first line. > > "Add the label jdk$N-enhancement-request to the issue ..." > > The JIRA label field currently has rt-triage-12. So, you need to click > in the JIRA label field and start typing jdk11-enhancement-request -- it > should auto-complete. You can leave the existing label as is and add > this as a second one. > > 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 Aug 14 16:07:30 2018 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 14 Aug 2018 17:07:30 +0100 Subject: RFR [11] 8207838: AArch64: Float registers incorrectly resture in JNI call In-Reply-To: <3140f273-f608-e34e-1410-d18073a278d7@redhat.com> References: <10d5c14e-2aaf-7c15-062f-fba0bb313299@redhat.com> <3140f273-f608-e34e-1410-d18073a278d7@redhat.com> Message-ID: <388180df-2b86-3b28-3c70-b6f07ba6fdd6@redhat.com> On 14/08/18 16:05, Andrew Haley wrote: > On 08/14/2018 02:32 PM, Aleksey Shipilev wrote: >> In the test, why do we need to call the test in separate threads? AFAIU, throwing Error from those >> threads would print them out to stderr, but it would not have other effects, e.g. changing the exit >> code of the test itself, so failures may go unnoticed. Might be better to use ExecutorService, get >> the Future-s, and rethrow ExecutionExceptions. > > Because the bad push/pop is only on the slow path when a lock has to > be inflated. That's why we never noticed it before. That answers Aleksey's question as to why use all those threads. However, it does not address (what I think is) his point that the test may give false positives because exceptions will not happen in the main thread and hence not derail the test. An ExecutorService is the Rolls-Royce option. A simpler solution is to set a static flag before starting the threads then if any of them enters the block where the throw happens have it clear the flag. The test can assert on the flag being set after all the joins complete (finesse is all very well, Aleksey, but brute force is so cheap and easy ;-). 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 Aug 14 16:09:06 2018 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 14 Aug 2018 17:09:06 +0100 Subject: RFR [11] 8207838: AArch64: Float registers incorrectly resture in JNI call In-Reply-To: References: <2649730f-2d2b-c23c-c893-f4c83687a098@redhat.com> Message-ID: On 14/08/18 17:07, Vladimir Kozlov wrote: > Andrew it is wrong. > > This is Bug not 'Enchantment'. You need to follow next instructions for > fix request approval: > http://openjdk.java.net/jeps/3#Fix-Request-Process > > In short: > > 1. Add label jdk11-fix-request > 2. Add comment with first line is ?Fix Request?. > 3. Add link to webrev. > > I will have to run changed tests on our platforms before approving it. Yes, of course. Thanks for the correction Vladimir! 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 Aug 14 16:42:22 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 14 Aug 2018 17:42:22 +0100 Subject: RFR [11] 8207838: AArch64: Float registers incorrectly resture in JNI call In-Reply-To: <388180df-2b86-3b28-3c70-b6f07ba6fdd6@redhat.com> References: <10d5c14e-2aaf-7c15-062f-fba0bb313299@redhat.com> <3140f273-f608-e34e-1410-d18073a278d7@redhat.com> <388180df-2b86-3b28-3c70-b6f07ba6fdd6@redhat.com> Message-ID: On 08/14/2018 05:07 PM, Andrew Dinn wrote: > That answers Aleksey's question as to why use all those threads. > However, it does not address (what I think is) his point that the test > may give false positives because exceptions will not happen in the main > thread and hence not derail the test. > > An ExecutorService is the Rolls-Royce option. A simpler solution is to > set a static flag before starting the threads then if any of them enters > the block where the throw happens have it clear the flag. The test can > assert on the flag being set after all the joins complete (finesse is > all very well, Aleksey, but brute force is so cheap and easy ;-). I get that, but with plenty of threads all of them are likely to be blocked at some point. However, I'll have a look at changing the test. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Tue Aug 14 18:03:07 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 14 Aug 2018 19:03:07 +0100 Subject: RFR [11] 8207838: AArch64: Float registers incorrectly resture in JNI call In-Reply-To: References: <10d5c14e-2aaf-7c15-062f-fba0bb313299@redhat.com> <3140f273-f608-e34e-1410-d18073a278d7@redhat.com> <388180df-2b86-3b28-3c70-b6f07ba6fdd6@redhat.com> Message-ID: <613fd55b-9fad-d7e3-1c72-eaf029ba2d15@redhat.com> On 08/14/2018 05:42 PM, Andrew Haley wrote: > On 08/14/2018 05:07 PM, Andrew Dinn wrote: >> That answers Aleksey's question as to why use all those threads. >> However, it does not address (what I think is) his point that the test >> may give false positives because exceptions will not happen in the main >> thread and hence not derail the test. >> >> An ExecutorService is the Rolls-Royce option. A simpler solution is to >> set a static flag before starting the threads then if any of them enters >> the block where the throw happens have it clear the flag. The test can >> assert on the flag being set after all the joins complete (finesse is >> all very well, Aleksey, but brute force is so cheap and easy ;-). > > I get that, but with plenty of threads all of them are likely to be > blocked at some point. However, I'll have a look at changing the test. Your suggestion works fine, but the test runs very slowly. Tomorrow I'll submit a new version of the test which fails more quickly. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From david.buck at oracle.com Wed Aug 15 10:57:00 2018 From: david.buck at oracle.com (David Buck) Date: Wed, 15 Aug 2018 19:57:00 +0900 Subject: [8] RFR (S) 8033251: Use DWARF debug symbols for Linux 32-bit as default In-Reply-To: <5B72DF82.4050906@oracle.com> References: <56cfd727-4833-8b8c-34c3-d8454bfb74ae@oracle.com> <5B72DF82.4050906@oracle.com> Message-ID: <0e88a325-0213-6533-0575-21c059ad2e79@oracle.com> Hi, Tim, thank you for the review! > Looks good. Your changes are in line with what JDK 9 did, only a bit > more specific to the ARCH that is building. > > In JDK 9 I see a check for $(FASTDEBUG_CFLAGS/$(BUILDARCH) but setting: > FASTDEBUG_CFLAGS += -g > > In JDK 8 you check $(FASTDEBUG_CFLAGS/$(BUILDARCH)) and set: > FASTDEBUG_CFLAGS/$(BUILDARCH) = -g > > and the same for $(OPT_CFLAGS/$(BUILDARCH) Yes, these differences are in keeping with some 8-specific changes done by Dean [0]. Cheers, -Buck [0] https://bugs.openjdk.java.net/browse/JDK-8074010 On 2018/08/14 22:56, Tim Bell wrote: > Buck: > >> May I please get a review of this simple backport to replace stabs with >> DWARF for 32-bit Linux builds. This is needed as newer toolchains no >> longer support stabs. >> >> bug report: >> https://bugs.openjdk.java.net/browse/JDK-8033251 >> >> JDK 9 changeset: >> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/2750fb4ad9ac >> >> JDK 8 webrev for review: >> http://cr.openjdk.java.net/~dbuck/8033251.0/ > > Looks good.? Your changes are in line with what JDK 9 did, only a bit > more specific to the ARCH that is building. > > In JDK 9 I see a check for $(FASTDEBUG_CFLAGS/$(BUILDARCH) but setting: > ?? FASTDEBUG_CFLAGS += -g > > In JDK 8 you check $(FASTDEBUG_CFLAGS/$(BUILDARCH)) and set: > ?? FASTDEBUG_CFLAGS/$(BUILDARCH) = -g > > and the same for $(OPT_CFLAGS/$(BUILDARCH) > > Tim > From coleen.phillimore at oracle.com Wed Aug 15 13:36:09 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 15 Aug 2018 09:36:09 -0400 Subject: RFR (S) 8209447: vmTestbase/vm/mlvm/indy/func/jvmti/mergeCP_none2indy_b/TestDescription.java timed out Message-ID: Summary: was walking code cache for every safepoint because redefined methods take a long time to clear out of the code cache See comments in bug for more details. open webrev at http://cr.openjdk.java.net/~coleenp/8209447.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8209447 Tested with mach5 hs tier1-5 and tier 7 where the failures occurred. thanks, Coleen From aph at redhat.com Wed Aug 15 14:57:29 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 15 Aug 2018 15:57:29 +0100 Subject: RFR [11] 8207838: AArch64: Float registers incorrectly resture in JNI call In-Reply-To: <613fd55b-9fad-d7e3-1c72-eaf029ba2d15@redhat.com> References: <10d5c14e-2aaf-7c15-062f-fba0bb313299@redhat.com> <3140f273-f608-e34e-1410-d18073a278d7@redhat.com> <388180df-2b86-3b28-3c70-b6f07ba6fdd6@redhat.com> <613fd55b-9fad-d7e3-1c72-eaf029ba2d15@redhat.com> Message-ID: I rewrote the test case. It runs much faster. It detects exceptions thrown by any thread. The previous test simply summed the arguments, which does not detect arguments passed in the wrong order, so I replaced the summation with a nonlinear combining function. New version at http://cr.openjdk.java.net/~aph/8207838-1/ -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From shade at redhat.com Wed Aug 15 15:02:03 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 15 Aug 2018 17:02:03 +0200 Subject: RFR [11] 8207838: AArch64: Float registers incorrectly resture in JNI call In-Reply-To: References: <10d5c14e-2aaf-7c15-062f-fba0bb313299@redhat.com> <3140f273-f608-e34e-1410-d18073a278d7@redhat.com> <388180df-2b86-3b28-3c70-b6f07ba6fdd6@redhat.com> <613fd55b-9fad-d7e3-1c72-eaf029ba2d15@redhat.com> Message-ID: <96b6dc90-fd94-5682-fdbc-3f950bb2e473@redhat.com> On 08/15/2018 04:57 PM, Andrew Haley wrote: > I rewrote the test case. It runs much faster. It detects exceptions > thrown by any thread. The previous test simply summed the arguments, > which does not detect arguments passed in the wrong order, so I > replaced the summation with a nonlinear combining function. > > New version at http://cr.openjdk.java.net/~aph/8207838-1/ Thumbs up. -Aleksey From adinn at redhat.com Wed Aug 15 15:14:32 2018 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 15 Aug 2018 16:14:32 +0100 Subject: RFR [11] 8207838: AArch64: Float registers incorrectly resture in JNI call In-Reply-To: References: <10d5c14e-2aaf-7c15-062f-fba0bb313299@redhat.com> <3140f273-f608-e34e-1410-d18073a278d7@redhat.com> <388180df-2b86-3b28-3c70-b6f07ba6fdd6@redhat.com> <613fd55b-9fad-d7e3-1c72-eaf029ba2d15@redhat.com> Message-ID: <378dae46-aaec-5c8d-d40b-c343e1d7956a@redhat.com> On 15/08/18 15:57, Andrew Haley wrote: > I rewrote the test case. It runs much faster. It detects exceptions > thrown by any thread. The previous test simply summed the arguments, > which does not detect arguments passed in the wrong order, so I > replaced the summation with a nonlinear combining function. > > New version at http://cr.openjdk.java.net/~aph/8207838-1/ Yes, that's good! 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 erik.osterlund at oracle.com Wed Aug 15 17:09:25 2018 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Wed, 15 Aug 2018 19:09:25 +0200 Subject: RFR (S) 8209447: vmTestbase/vm/mlvm/indy/func/jvmti/mergeCP_none2indy_b/TestDescription.java timed out In-Reply-To: References: Message-ID: <79B5A01F-BBA9-412B-B495-CAA10148406B@oracle.com> Hi Coleen, Looks fantastic, and should perhaps be pushed to stop test failures. Thanks, /Erik > On 15 Aug 2018, at 15:36, coleen.phillimore at oracle.com wrote: > > Summary: was walking code cache for every safepoint because redefined methods take a long time to clear out of the code cache > > See comments in bug for more details. > > open webrev at http://cr.openjdk.java.net/~coleenp/8209447.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8209447 > > Tested with mach5 hs tier1-5 and tier 7 where the failures occurred. > > thanks, > Coleen From coleen.phillimore at oracle.com Wed Aug 15 17:15:04 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 15 Aug 2018 13:15:04 -0400 Subject: RFR (S) 8209447: vmTestbase/vm/mlvm/indy/func/jvmti/mergeCP_none2indy_b/TestDescription.java timed out In-Reply-To: <79B5A01F-BBA9-412B-B495-CAA10148406B@oracle.com> References: <79B5A01F-BBA9-412B-B495-CAA10148406B@oracle.com> Message-ID: <3c47be3f-892c-844b-a74c-aa8a527d1ab7@oracle.com> Thanks, Erik! Coleen On 8/15/18 1:09 PM, Erik Osterlund wrote: > Hi Coleen, > > Looks fantastic, and should perhaps be pushed to stop test failures. > > Thanks, > /Erik > >> On 15 Aug 2018, at 15:36, coleen.phillimore at oracle.com wrote: >> >> Summary: was walking code cache for every safepoint because redefined methods take a long time to clear out of the code cache >> >> See comments in bug for more details. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8209447.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8209447 >> >> Tested with mach5 hs tier1-5 and tier 7 where the failures occurred. >> >> thanks, >> Coleen From robbin.ehn at oracle.com Wed Aug 15 19:55:37 2018 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 15 Aug 2018 21:55:37 +0200 Subject: RFR (S) 8209447: vmTestbase/vm/mlvm/indy/func/jvmti/mergeCP_none2indy_b/TestDescription.java timed out In-Reply-To: <79B5A01F-BBA9-412B-B495-CAA10148406B@oracle.com> References: <79B5A01F-BBA9-412B-B495-CAA10148406B@oracle.com> Message-ID: <543f110d-c06d-a48b-1794-2416e1a6625d@oracle.com> On 2018-08-15 19:09, Erik Osterlund wrote: > Hi Coleen, > > Looks fantastic, and should perhaps be pushed to stop test failures. +1 /Robbin > > Thanks, > /Erik > >> On 15 Aug 2018, at 15:36, coleen.phillimore at oracle.com wrote: >> >> Summary: was walking code cache for every safepoint because redefined methods take a long time to clear out of the code cache >> >> See comments in bug for more details. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8209447.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8209447 >> >> Tested with mach5 hs tier1-5 and tier 7 where the failures occurred. >> >> thanks, >> Coleen > From coleen.phillimore at oracle.com Wed Aug 15 20:17:45 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 15 Aug 2018 16:17:45 -0400 Subject: RFR (S) 8209447: vmTestbase/vm/mlvm/indy/func/jvmti/mergeCP_none2indy_b/TestDescription.java timed out In-Reply-To: <543f110d-c06d-a48b-1794-2416e1a6625d@oracle.com> References: <79B5A01F-BBA9-412B-B495-CAA10148406B@oracle.com> <543f110d-c06d-a48b-1794-2416e1a6625d@oracle.com> Message-ID: <10448746-e765-315a-f20e-ebe99843bb22@oracle.com> Thanks Robbin! Coleen On 8/15/18 3:55 PM, Robbin Ehn wrote: > On 2018-08-15 19:09, Erik Osterlund wrote: >> Hi Coleen, >> >> Looks fantastic, and should perhaps be pushed to stop test failures. > > +1 > > /Robbin > >> >> Thanks, >> /Erik >> >>> On 15 Aug 2018, at 15:36, coleen.phillimore at oracle.com wrote: >>> >>> Summary: was walking code cache for every safepoint because >>> redefined methods take a long time to clear out of the code cache >>> >>> See comments in bug for more details. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8209447.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8209447 >>> >>> Tested with mach5 hs tier1-5 and tier 7 where the failures occurred. >>> >>> thanks, >>> Coleen >> From lois.foltan at oracle.com Thu Aug 16 20:17:47 2018 From: lois.foltan at oracle.com (Lois Foltan) Date: Thu, 16 Aug 2018 16:17:47 -0400 Subject: RFR (L) JDK-8209301: JVM rename is_anonymous, host_klass to unsafe specific terminology ahead of Unsafe.defineAnonymousClass deprecation Message-ID: Ahead of the work to support a new MethodHandle.Lookup functionality to define an anonymous or other class within the context of a hosted class, (see JDK-8171335), please review this clean up to use the terminology of "is_unsafe_anonymous" instead of "is_anonymous" for classes defined to the VM via Unsafe.defineAnonymousClass.? InstanceKlass' "host_klass" method has also been renamed to "unsafe_anonymous_host" in order to avoid confusion with "nest_host".? It is not anticipated that JDK-8171335 work will use the same "anonymous" terminology. open webrev at http://cr.openjdk.java.net/~lfoltan/bug_jdk8209301/webrev/ bug link at https://bugs.openjdk.java.net/browse/JDK-8209301 Testing: hs-tier1-4, jdk-tier1-3 (complete) ?????????????? hs-tier4-5 (in progress) Thanks, Lois From mandy.chung at oracle.com Thu Aug 16 20:41:38 2018 From: mandy.chung at oracle.com (mandy chung) Date: Thu, 16 Aug 2018 13:41:38 -0700 Subject: RFR (L) JDK-8209301: JVM rename is_anonymous, host_klass to unsafe specific terminology ahead of Unsafe.defineAnonymousClass deprecation In-Reply-To: References: Message-ID: Hi Lois, This looks good to me. It's good to see the renaming that will help clear any confusion in the future. Mandy On 8/16/18 1:17 PM, Lois Foltan wrote: > Ahead of the work to support a new MethodHandle.Lookup functionality to > define an anonymous or other class within the context of a hosted class, > (see JDK-8171335), please review this clean up to use the terminology of > "is_unsafe_anonymous" instead of "is_anonymous" for classes defined to > the VM via Unsafe.defineAnonymousClass.? InstanceKlass' "host_klass" > method has also been renamed to "unsafe_anonymous_host" in order to > avoid confusion with "nest_host".? It is not anticipated that > JDK-8171335 work will use the same "anonymous" terminology. > > open webrev at http://cr.openjdk.java.net/~lfoltan/bug_jdk8209301/webrev/ > bug link at https://bugs.openjdk.java.net/browse/JDK-8209301 > > Testing: hs-tier1-4, jdk-tier1-3 (complete) > ?????????????? hs-tier4-5 (in progress) > > Thanks, > Lois From kim.barrett at oracle.com Thu Aug 16 22:14:50 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 16 Aug 2018 18:14:50 -0400 Subject: RFR: 8209607: Remove stale comment for JNI mutexes Message-ID: <1076CD06-3C35-4C2E-A60F-3916202C0497@oracle.com> Please review this trivial change to remove a stale comment. CR: https://bugs.openjdk.java.net/browse/JDK-8209607 Webrev: http://cr.openjdk.java.net/~kbarrett/8209607/open.00/ Testing: Built locally (linux-x64). From david.holmes at oracle.com Thu Aug 16 22:26:43 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 17 Aug 2018 08:26:43 +1000 Subject: RFR: 8209607: Remove stale comment for JNI mutexes In-Reply-To: <1076CD06-3C35-4C2E-A60F-3916202C0497@oracle.com> References: <1076CD06-3C35-4C2E-A60F-3916202C0497@oracle.com> Message-ID: Ok. Thanks, David On 17/08/2018 8:14 AM, Kim Barrett wrote: > Please review this trivial change to remove a stale comment. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8209607 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8209607/open.00/ > > Testing: > Built locally (linux-x64). > From kim.barrett at oracle.com Thu Aug 16 22:55:30 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 16 Aug 2018 18:55:30 -0400 Subject: RFR: 8209607: Remove stale comment for JNI mutexes In-Reply-To: References: <1076CD06-3C35-4C2E-A60F-3916202C0497@oracle.com> Message-ID: > On Aug 16, 2018, at 6:26 PM, David Holmes wrote: > > Ok. > > Thanks, > David > > On 17/08/2018 8:14 AM, Kim Barrett wrote: >> Please review this trivial change to remove a stale comment. >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8209607 >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8209607/open.00/ >> Testing: >> Built locally (linux-x64). Thanks. From david.holmes at oracle.com Thu Aug 16 23:13:54 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 17 Aug 2018 09:13:54 +1000 Subject: RFR (L) JDK-8209301: JVM rename is_anonymous, host_klass to unsafe specific terminology ahead of Unsafe.defineAnonymousClass deprecation In-Reply-To: References: Message-ID: Hi Lois, On 17/08/2018 6:17 AM, Lois Foltan wrote: > Ahead of the work to support a new MethodHandle.Lookup functionality to > define an anonymous or other class within the context of a hosted class, > (see JDK-8171335), please review this clean up to use the terminology of > "is_unsafe_anonymous" instead of "is_anonymous" for classes defined to > the VM via Unsafe.defineAnonymousClass.? InstanceKlass' "host_klass" > method has also been renamed to "unsafe_anonymous_host" in order to > avoid confusion with "nest_host".? It is not anticipated that > JDK-8171335 work will use the same "anonymous" terminology. This generally seems okay. Reading through this we seem to have some loose wording in places. For example in classloaderData.cpp we have: // Returns true if this class loader data is a class loader data // that is not ever freed by a GC. It must be one of the builtin -// class loaders and not anonymous. +// class loaders and not unsafe anonymous. which I think should read something like: "It must be [the CLD] for one of the builtin class loaders and not the CLD for an unsafe anonymous class." More generally we seem to refer to just "anonymous" or "anonymous class loader" when I think we mean the CLD for an anonymous class. At least I don't think we have "anonymous class loaders" do we? Anyway that's somewhat distinct from the renaming exercise. Thanks, David > open webrev at http://cr.openjdk.java.net/~lfoltan/bug_jdk8209301/webrev/ > bug link at https://bugs.openjdk.java.net/browse/JDK-8209301 > > Testing: hs-tier1-4, jdk-tier1-3 (complete) > ?????????????? hs-tier4-5 (in progress) > > Thanks, > Lois From lois.foltan at oracle.com Thu Aug 16 23:35:50 2018 From: lois.foltan at oracle.com (Lois Foltan) Date: Thu, 16 Aug 2018 19:35:50 -0400 Subject: RFR (L) JDK-8209301: JVM rename is_anonymous, host_klass to unsafe specific terminology ahead of Unsafe.defineAnonymousClass deprecation In-Reply-To: References: Message-ID: Thank you Mandy for the review! Lois On 8/16/2018 4:41 PM, mandy chung wrote: > Hi Lois, > > This looks good to me.? It's good to see the renaming that will help > clear any confusion in the future. > > Mandy > > On 8/16/18 1:17 PM, Lois Foltan wrote: >> Ahead of the work to support a new MethodHandle.Lookup functionality >> to define an anonymous or other class within the context of a hosted >> class, (see JDK-8171335), please review this clean up to use the >> terminology of "is_unsafe_anonymous" instead of "is_anonymous" for >> classes defined to the VM via Unsafe.defineAnonymousClass. >> InstanceKlass' "host_klass" method has also been renamed to >> "unsafe_anonymous_host" in order to avoid confusion with >> "nest_host".? It is not anticipated that JDK-8171335 work will use >> the same "anonymous" terminology. >> >> open webrev at >> http://cr.openjdk.java.net/~lfoltan/bug_jdk8209301/webrev/ >> bug link at https://bugs.openjdk.java.net/browse/JDK-8209301 >> >> Testing: hs-tier1-4, jdk-tier1-3 (complete) >> ??????????????? hs-tier4-5 (in progress) >> >> Thanks, >> Lois From lois.foltan at oracle.com Thu Aug 16 23:44:37 2018 From: lois.foltan at oracle.com (Lois Foltan) Date: Thu, 16 Aug 2018 19:44:37 -0400 Subject: RFR (L) JDK-8209301: JVM rename is_anonymous, host_klass to unsafe specific terminology ahead of Unsafe.defineAnonymousClass deprecation In-Reply-To: References: Message-ID: On 8/16/2018 7:13 PM, David Holmes wrote: > Hi Lois, > > On 17/08/2018 6:17 AM, Lois Foltan wrote: >> Ahead of the work to support a new MethodHandle.Lookup functionality >> to define an anonymous or other class within the context of a hosted >> class, (see JDK-8171335), please review this clean up to use the >> terminology of "is_unsafe_anonymous" instead of "is_anonymous" for >> classes defined to the VM via Unsafe.defineAnonymousClass. >> InstanceKlass' "host_klass" method has also been renamed to >> "unsafe_anonymous_host" in order to avoid confusion with >> "nest_host".? It is not anticipated that JDK-8171335 work will use >> the same "anonymous" terminology. > > This generally seems okay. Thanks David for reviewing! > > Reading through this we seem to have some loose wording in places. For > example in classloaderData.cpp we have: > > ?// Returns true if this class loader data is a class loader data > ?// that is not ever freed by a GC.? It must be one of the builtin > -// class loaders and not anonymous. > +// class loaders and not unsafe anonymous. > > which I think should read something like: > > "It must be [the CLD] for one of the builtin class loaders and not the > CLD for an unsafe anonymous class." I like your rewording, will update the comment. > > More generally we seem to refer to just "anonymous" or "anonymous > class loader" when I think we mean the CLD for an anonymous class. At > least I don't think we have "anonymous class loaders" do we? No we do not.? I debated for awhile as what exactly to do with specifically ClassLoaderData's _is_unsafe_anonymous field indicating that the CLD is currently dedicated to containing one VM unsafe anonymous class whose lifecycle is controlled by its class' java mirror, not its class loader.? I wanted to rename it to "_has_class_lifecycle", but decided to postpone this decision until the work to support JDK-8171335 is flushed out.? I anticipate that the concept of a singleton ClassLoaderData will be shared by Unsafe.defineAnonymousClass and the new Lookup.defineClass functionality. Thanks, Lois > > Anyway that's somewhat distinct from the renaming exercise. > > Thanks, > David > >> open webrev at >> http://cr.openjdk.java.net/~lfoltan/bug_jdk8209301/webrev/ >> bug link at https://bugs.openjdk.java.net/browse/JDK-8209301 >> >> Testing: hs-tier1-4, jdk-tier1-3 (complete) >> ??????????????? hs-tier4-5 (in progress) >> >> Thanks, >> Lois From coleen.phillimore at oracle.com Fri Aug 17 14:02:41 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 17 Aug 2018 10:02:41 -0400 Subject: RFR (L) JDK-8209301: JVM rename is_anonymous, host_klass to unsafe specific terminology ahead of Unsafe.defineAnonymousClass deprecation In-Reply-To: References: Message-ID: <527f243d-bf1e-95c2-ee3a-198ed3a2430e@oracle.com> Hi Lois, this looks good, in case you haven't checked it in yet.? A couple of minor comments. http://cr.openjdk.java.net/~lfoltan/bug_jdk8209301/webrev/src/hotspot/share/ci/ciField.cpp.udiff.html + // Trust VM unsafe anonymous classes. They are private API (sun.misc.Unsafe) Isn't it now jdk.internal.misc.Unsafe ? Scary how this is all over the place. thanks, Coleen On 8/16/18 4:17 PM, Lois Foltan wrote: > Ahead of the work to support a new MethodHandle.Lookup functionality > to define an anonymous or other class within the context of a hosted > class, (see JDK-8171335), please review this clean up to use the > terminology of "is_unsafe_anonymous" instead of "is_anonymous" for > classes defined to the VM via Unsafe.defineAnonymousClass. > InstanceKlass' "host_klass" method has also been renamed to > "unsafe_anonymous_host" in order to avoid confusion with "nest_host".? > It is not anticipated that JDK-8171335 work will use the same > "anonymous" terminology. > > open webrev at http://cr.openjdk.java.net/~lfoltan/bug_jdk8209301/webrev/ > bug link at https://bugs.openjdk.java.net/browse/JDK-8209301 > > Testing: hs-tier1-4, jdk-tier1-3 (complete) > ?????????????? hs-tier4-5 (in progress) > > Thanks, > Lois From volker.simonis at gmail.com Fri Aug 17 14:03:31 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 17 Aug 2018 16:03:31 +0200 Subject: [11] RFR(S): 8209637: [s390x] Interpreter doesn't call result handler after native calls Message-ID: Hi, can I please have a review for this small, s390x only bug fix which I'd like to bring to jdk11: http://cr.openjdk.java.net/~simonis/webrevs/2018/8209637/ https://bugs.openjdk.java.net/browse/JDK-8209637 The problem is that the template interpreter for s390x doesn't call the result handler in the native entry. This can lead to wrong results being passed as return values from native calls which return a jboolean if the value is not exactly '1' or '0' (i.e. a return value of '2' will be interpreted as 'false'). The result handler usually normalizes such results and maps any value > 0 to 'true'. I'd like to bring this to jdk11 because the bug can lead to incorrect results for calls to JNI functions with jboolean results. This can affect not only user coding but also core library functions like java.io.Console.echo() (which is called from Console.readPassword()). The malfunction of these methods triggered the discovery of this bug. The fix is low risk and only affects the s390x port (except the regression test - but that shouldn't be harmful either). Thank you and best regards, Volker From lois.foltan at oracle.com Fri Aug 17 15:13:28 2018 From: lois.foltan at oracle.com (Lois Foltan) Date: Fri, 17 Aug 2018 11:13:28 -0400 Subject: RFR (L) JDK-8209301: JVM rename is_anonymous, host_klass to unsafe specific terminology ahead of Unsafe.defineAnonymousClass deprecation In-Reply-To: <527f243d-bf1e-95c2-ee3a-198ed3a2430e@oracle.com> References: <527f243d-bf1e-95c2-ee3a-198ed3a2430e@oracle.com> Message-ID: <9f79d693-a738-ebdd-705c-e4137dd2579c@oracle.com> On 8/17/2018 10:02 AM, coleen.phillimore at oracle.com wrote: > > Hi Lois, this looks good, in case you haven't checked it in yet. A > couple of minor comments. > > http://cr.openjdk.java.net/~lfoltan/bug_jdk8209301/webrev/src/hotspot/share/ci/ciField.cpp.udiff.html > > > + // Trust VM unsafe anonymous classes. They are private API > (sun.misc.Unsafe) > > > Isn't it now jdk.internal.misc.Unsafe ? Yes it is, will update the comment.? Thanks for the review! Lois > > Scary how this is all over the place. > > thanks, > Coleen > > On 8/16/18 4:17 PM, Lois Foltan wrote: >> Ahead of the work to support a new MethodHandle.Lookup functionality >> to define an anonymous or other class within the context of a hosted >> class, (see JDK-8171335), please review this clean up to use the >> terminology of "is_unsafe_anonymous" instead of "is_anonymous" for >> classes defined to the VM via Unsafe.defineAnonymousClass. >> InstanceKlass' "host_klass" method has also been renamed to >> "unsafe_anonymous_host" in order to avoid confusion with >> "nest_host".? It is not anticipated that JDK-8171335 work will use >> the same "anonymous" terminology. >> >> open webrev at >> http://cr.openjdk.java.net/~lfoltan/bug_jdk8209301/webrev/ >> bug link at https://bugs.openjdk.java.net/browse/JDK-8209301 >> >> Testing: hs-tier1-4, jdk-tier1-3 (complete) >> ?????????????? hs-tier4-5 (in progress) >> >> Thanks, >> Lois > From vladimir.kozlov at oracle.com Fri Aug 17 20:32:32 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 17 Aug 2018 13:32:32 -0700 Subject: [11] RFR(S): 8209637: [s390x] Interpreter doesn't call result handler after native calls In-Reply-To: References: Message-ID: <06592a59-7d99-254f-632d-225a51c36b5f@oracle.com> Hi Volker, Someone who is familiar with this s390 code should review it before we can judge if it acceptable fro JDK 11. Regards, Vladimir On 8/17/18 7:03 AM, Volker Simonis wrote: > Hi, > > can I please have a review for this small, s390x only bug fix which > I'd like to bring to jdk11: > > http://cr.openjdk.java.net/~simonis/webrevs/2018/8209637/ > https://bugs.openjdk.java.net/browse/JDK-8209637 > > The problem is that the template interpreter for s390x doesn't call > the result handler in the native entry. This can lead to wrong results > being passed as return values from native calls which return a > jboolean if the value is not exactly '1' or '0' (i.e. a return value > of '2' will be interpreted as 'false'). The result handler usually > normalizes such results and maps any value > 0 to 'true'. > > I'd like to bring this to jdk11 because the bug can lead to incorrect > results for calls to JNI functions with jboolean results. This can > affect not only user coding but also core library functions like > java.io.Console.echo() (which is called from Console.readPassword()). > The malfunction of these methods triggered the discovery of this bug. > > The fix is low risk and only affects the s390x port (except the > regression test - but that shouldn't be harmful either). > > Thank you and best regards, > Volker > From yingsu at fb.com Fri Aug 17 22:51:23 2018 From: yingsu at fb.com (Ying Su) Date: Fri, 17 Aug 2018 22:51:23 +0000 Subject: custom/fast heap dumper Message-ID: <025D08AD-4ADD-410F-A346-FB4D1EB037C9@contoso.com> Hi, We want to implement a custom fast heap dumper that should work on Java 9 and 10, because we often need to dump huge heaps (~200GB), and it takes 20-30 minutes with jmap (e.g. we thought about zeroing out the large arrays and compressing the output, etc.) We?ve been looking at the following 2 options: 1. Modify the JVMTI demo hprof implementation in JDK8 2. Reuse/modify jdk9-dev/hotspot/src/share/vm/services/heapDumper.cpp We?ve tried the first option but it?s very slow due to some shared hash tables causing high lock contention. And the second option is more complicated because we need to access internal JVM classes, and we don?t know how we can deploy it to production. We?d appreciate if we can get some expert opinion on how to best solve this problem. Thank you very much, Ying From rednaxelafx at gmail.com Fri Aug 17 23:26:23 2018 From: rednaxelafx at gmail.com (Krystal Mok) Date: Fri, 17 Aug 2018 16:26:23 -0700 Subject: custom/fast heap dumper In-Reply-To: <025D08AD-4ADD-410F-A346-FB4D1EB037C9@contoso.com> References: <025D08AD-4ADD-410F-A346-FB4D1EB037C9@contoso.com> Message-ID: Hi Ying, Side-stepping from your question a bit: is it absolutely necessary to take a full heap dump for your use case? Or would it be more feasible to do some of the analysis that you want online instead of taking a heap dump and then do offline analysis? Some analysis that people used to do on heap dump snapshots could be done with JFR or the new Low-overhead heap profiling feature. Would those be sufficient, or perhaps would extending those a bit be sufficient for your use case? At Azul Systems, the Zing JVM supports some of the analysis piggybacking on the GC. Since the C4 GC is fully concurrent (*), these operations are not interruptive at all and has very low overhead. For OpenJDK, with ZGC on the horizon, this kind of feature piggybacking on a fully concurrent GC would also be possible. My two cents, Kris * C4 GC can concurrently mark and compact the heap, albeit it does still do a few very short pauses during the whole concurrent GC cycle. Similar story with ZGC. On Fri, Aug 17, 2018 at 3:51 PM, Ying Su wrote: > Hi, > > We want to implement a custom fast heap dumper that should work on Java 9 > and 10, because we often need to dump huge heaps (~200GB), and it takes > 20-30 minutes with jmap (e.g. we thought about zeroing out the large arrays > and compressing the output, etc.) We?ve been looking at the following 2 > options: > > > 1. Modify the JVMTI demo hprof implementation in JDK8 > 2. Reuse/modify jdk9-dev/hotspot< > https://github.com/netroby/jdk9-dev/tree/master/hotspot>/src ttps://github.com/netroby/jdk9-dev/tree/master/hotspot/src>/share< > https://github.com/netroby/jdk9-dev/tree/master/hotspot/src/share>/vm< > https://github.com/netroby/jdk9-dev/tree/master/hotspot/src/share/vm > >/services master/hotspot/src/share/vm/services>/heapDumper.cpp > > We?ve tried the first option but it?s very slow due to some shared hash > tables causing high lock contention. And the second option is more > complicated because we need to access internal JVM classes, and we don?t > know how we can deploy it to production. We?d appreciate if we can get some > expert opinion on how to best solve this problem. > > > Thank you very much, > Ying > > > > > > > > From volker.simonis at gmail.com Mon Aug 20 10:22:16 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 20 Aug 2018 12:22:16 +0200 Subject: Is returning a value != '0' or '1' as jboolean from a JNI function legal? In-Reply-To: <130e0b86-e41f-fda7-5a6f-03b2135a9a60@redhat.com> References: <130e0b86-e41f-fda7-5a6f-03b2135a9a60@redhat.com> Message-ID: On Fri, Aug 17, 2018 at 7:25 PM, Aleksey Shipilev wrote: > On 08/17/2018 05:12 PM, Volker Simonis wrote: >> The offending code in Console_md.c looks as follows: >> >> #define ECHO 8 >> >> JNIEXPORT jboolean JNICALL >> Java_java_io_Console_echo(...) { >> >> jboolean old; >> ... >> old = (tio.c_lflag & ECHO); >> ... >> return old; >> } >> >> The intention of this code is to return "true" if the ECHO flag was >> set but it really returns the value of ECHO (which is defined as '8' >> in a system header). >> >> The question now is, if a Java SE compatible VM guarantees that any >> arbitrary, non-zero valued jboolean will be interpreted as "JNI_TRUE" >> and only a zero valued jboolean will be interpreted as "JNI_FALSE"? >> >> Or, the other way round, is the normalization performed by the HotSpot >> result handlers necessary (i.e. enforced by the specification) or just >> a convenience to fix broken code like the above from Console.echo()? > > I think this is intentional aftermath of boolean value normalization: > https://bugs.openjdk.java.net/browse/JDK-8161720 > OMG - I'm getting old :) Thanks for the link to JDK-8161720! Funny enough I was one of the reviewers of JDK-8161720 and almost exactly two years ago I already asked the exactly same question [1]: "And I have a question about JNI: is it only a convention that JNI functions should return JNI_TRUE/JNI_FALSE or is this required by the specification?" Zoltan answered to that question by citing an excerpt from the JNI Programmer's Guide & Specification [2]: "A |jboolean| is an 8-bit unsigned C type that can store values from 0 to 255. The value 0 corresponds to the constant |JNI_FALSE|, and the values from 1 to 255 correspond to |JNI_TRUE|." But the "JNI Programmer's Guide & Specification" is from 1999 and it only contains the cited sentence in its "Traps and Pitfalls" section and not in the "Specification" part. The latest JNI Specification [3] doesn't seem to contain such a rule. So to summarize, my current view on this topic is: - JNI functions returning a jboolean are only allowed to return JNI_TRUE/JNI_FALSE (or 1/0) according to the current JNI spcification. - to code in Java_java_io_Console_echo() should be fixed (as confirmed by Sherman later in this thread) - normalization of native, off-heap 8-bit values to Java booleans as currently implemented in the HotSpot (and fixed by JDK-8161720) is (1) only for convenience to simply access to off-heap data in Unsafe, (2) to implement better Java/Native integration in projects like Panama and (3) to fix legacy JNI code which was developed under the assumption that the advice in the "JNI Programmer's Guide & Specification" book is specification relevant. Do you agree? Thank you and best regards, Volker [1] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-August/024192.html [2] https://web.archive.org/web/20120626012047/http://java.sun.com/docs/books/jni/html/pitfalls.html#30066 [3] https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/jniTOC.html > So, Java_java_io_Console_echo looks broken and needs to be fixed, by e.g.: > > - old = (tio.c_lflag & ECHO); > + old = (tio.c_lflag & ECHO) != 0; > > Thanks, > -Aleksey > From goetz.lindenmaier at sap.com Mon Aug 20 14:24:43 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 20 Aug 2018 14:24:43 +0000 Subject: [11] RFR(S): 8209637: [s390x] Interpreter doesn't call result handler after native calls In-Reply-To: <06592a59-7d99-254f-632d-225a51c36b5f@oracle.com> References: <06592a59-7d99-254f-632d-225a51c36b5f@oracle.com> Message-ID: <5ffada18fdcd4905816fbed29a6bb5dc@sap.com> Hi Volker, the fix looks good to me, but please use mem2reg_opt instead of load_and_test_long. The test result is not used. Maybe you can fix comment in line 1684: "Bandle exception" --> "Handle exception". Don't need a new webrev. Thanks and best regards, Goetz. > -----Original Message----- > From: hotspot-dev On Behalf Of > Vladimir Kozlov > Sent: Freitag, 17. August 2018 22:33 > To: Volker Simonis ; HotSpot Open Source > Developers > Subject: Re: [11] RFR(S): 8209637: [s390x] Interpreter doesn't call result > handler after native calls > > Hi Volker, > > Someone who is familiar with this s390 code should review it before we can > judge if it acceptable fro JDK 11. > > Regards, > Vladimir > > On 8/17/18 7:03 AM, Volker Simonis wrote: > > Hi, > > > > can I please have a review for this small, s390x only bug fix which > > I'd like to bring to jdk11: > > > > http://cr.openjdk.java.net/~simonis/webrevs/2018/8209637/ > > https://bugs.openjdk.java.net/browse/JDK-8209637 > > > > The problem is that the template interpreter for s390x doesn't call > > the result handler in the native entry. This can lead to wrong results > > being passed as return values from native calls which return a > > jboolean if the value is not exactly '1' or '0' (i.e. a return value > > of '2' will be interpreted as 'false'). The result handler usually > > normalizes such results and maps any value > 0 to 'true'. > > > > I'd like to bring this to jdk11 because the bug can lead to incorrect > > results for calls to JNI functions with jboolean results. This can > > affect not only user coding but also core library functions like > > java.io.Console.echo() (which is called from Console.readPassword()). > > The malfunction of these methods triggered the discovery of this bug. > > > > The fix is low risk and only affects the s390x port (except the > > regression test - but that shouldn't be harmful either). > > > > Thank you and best regards, > > Volker > > From lutz.schmidt at sap.com Mon Aug 20 14:44:38 2018 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Mon, 20 Aug 2018 14:44:38 +0000 Subject: [11] RFR(S): 8209637: [s390x] Interpreter doesn't call result handler after native calls In-Reply-To: <5ffada18fdcd4905816fbed29a6bb5dc@sap.com> References: <06592a59-7d99-254f-632d-225a51c36b5f@oracle.com> <5ffada18fdcd4905816fbed29a6bb5dc@sap.com> Message-ID: Hi Volker, I agree with Goetz's judgement. He was just a bit quicker than me. __ Thanks for tracking this down and fixing it. Regards, Lutz ?On 20.08.18, 16:24, "hotspot-dev on behalf of Lindenmaier, Goetz" wrote: Hi Volker, the fix looks good to me, but please use mem2reg_opt instead of load_and_test_long. The test result is not used. Maybe you can fix comment in line 1684: "Bandle exception" --> "Handle exception". Don't need a new webrev. Thanks and best regards, Goetz. > -----Original Message----- > From: hotspot-dev On Behalf Of > Vladimir Kozlov > Sent: Freitag, 17. August 2018 22:33 > To: Volker Simonis ; HotSpot Open Source > Developers > Subject: Re: [11] RFR(S): 8209637: [s390x] Interpreter doesn't call result > handler after native calls > > Hi Volker, > > Someone who is familiar with this s390 code should review it before we can > judge if it acceptable fro JDK 11. > > Regards, > Vladimir > > On 8/17/18 7:03 AM, Volker Simonis wrote: > > Hi, > > > > can I please have a review for this small, s390x only bug fix which > > I'd like to bring to jdk11: > > > > http://cr.openjdk.java.net/~simonis/webrevs/2018/8209637/ > > https://bugs.openjdk.java.net/browse/JDK-8209637 > > > > The problem is that the template interpreter for s390x doesn't call > > the result handler in the native entry. This can lead to wrong results > > being passed as return values from native calls which return a > > jboolean if the value is not exactly '1' or '0' (i.e. a return value > > of '2' will be interpreted as 'false'). The result handler usually > > normalizes such results and maps any value > 0 to 'true'. > > > > I'd like to bring this to jdk11 because the bug can lead to incorrect > > results for calls to JNI functions with jboolean results. This can > > affect not only user coding but also core library functions like > > java.io.Console.echo() (which is called from Console.readPassword()). > > The malfunction of these methods triggered the discovery of this bug. > > > > The fix is low risk and only affects the s390x port (except the > > regression test - but that shouldn't be harmful either). > > > > Thank you and best regards, > > Volker > > From shade at redhat.com Mon Aug 20 14:55:19 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 20 Aug 2018 16:55:19 +0200 Subject: Is returning a value != '0' or '1' as jboolean from a JNI function legal? In-Reply-To: References: <130e0b86-e41f-fda7-5a6f-03b2135a9a60@redhat.com> Message-ID: On 08/20/2018 12:22 PM, Volker Simonis wrote: > So to summarize, my current view on this topic is: > - JNI functions returning a jboolean are only allowed to return > JNI_TRUE/JNI_FALSE (or 1/0) according to the current JNI spcification. Now *I* am having trouble seeing where exactly the JNI spec says the domain of jboolean is (JNI_FALSE, JNI_TRUE). In "Primitive Types" [1] it says "The following definition is provided for convenience: JNI_FALSE, JNI_TRUE", but that does not restrict the domain, because those are "convenience" defines. And "Description" in the table says jboolean is "unsigned 8 bits", which seems to invite interpretation that all 8 bits are usable. John says [2]: "The JNI documents specify that, at least for returning values from native methods, a Java boolean (T_BOOLEAN) value is converted to the value-set 0..1 by first truncating to a byte (0..255 or maybe -128..127) and then testing against zero." ...which is what I am looking for, but I cannot find the "JNI document" that actually says that. I can see the idea of that in JVMS [3], but that seems to only apply to on-heap booleans, does that also extend to jboolean's? Maybe John can point out the JNI document where it is said explicitly? > - to code in Java_java_io_Console_echo() should be fixed (as > confirmed by Sherman later in this thread) Yes, that's a bug waiting to happen anyway. > - normalization of native, off-heap 8-bit values to Java booleans as > currently implemented in the HotSpot (and fixed by JDK-8161720) is (1) > only for convenience to simply access to off-heap data in Unsafe, (2) > to implement better Java/Native integration in projects like Panama > and (3) to fix legacy JNI code which was developed under the > assumption that the advice in the "JNI Programmer's Guide & > Specification" book is specification relevant. Yes, the intent seems to be what you describe. But see above about the spec. -Aleksey [1] https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/types.html#primitive_types [2] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-August/024263.html [3] https://docs.oracle.com/javase/specs/jvms/se10/html/jvms-2.html#jvms-2.3.4 From volker.simonis at gmail.com Mon Aug 20 15:37:47 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 20 Aug 2018 17:37:47 +0200 Subject: Is returning a value != '0' or '1' as jboolean from a JNI function legal? In-Reply-To: References: <130e0b86-e41f-fda7-5a6f-03b2135a9a60@redhat.com> Message-ID: On Mon, Aug 20, 2018 at 4:55 PM, Aleksey Shipilev wrote: > On 08/20/2018 12:22 PM, Volker Simonis wrote: >> So to summarize, my current view on this topic is: >> - JNI functions returning a jboolean are only allowed to return >> JNI_TRUE/JNI_FALSE (or 1/0) according to the current JNI spcification. > > Now *I* am having trouble seeing where exactly the JNI spec says the domain of jboolean is > (JNI_FALSE, JNI_TRUE). In "Primitive Types" [1] it says "The following definition is provided for > convenience: JNI_FALSE, JNI_TRUE", but that does not restrict the domain, because those are > "convenience" defines. And "Description" in the table says jboolean is "unsigned 8 bits", which > seems to invite interpretation that all 8 bits are usable. > > John says [2]: > > "The JNI documents specify that, at least for returning values from native methods, a Java boolean > (T_BOOLEAN) value is converted to the value-set 0..1 by first truncating to a byte (0..255 or maybe > -128..127) and then testing against zero." > > ...which is what I am looking for, but I cannot find the "JNI document" that actually says that. I > can see the idea of that in JVMS [3], but that seems to only apply to on-heap booleans, does that > also extend to jboolean's? Maybe John can point out the JNI document where it is said explicitly? > Yes, you're right - there's no exact documentation for neither of the two possible interpretations. A colleague just pointed me to the definition of invokestatic in the JVMS [4] which has the following sentence: "If the native method returns a value, the return value of the platform-dependent code is converted in an implementation-dependent way to the return type of the native method and pushed onto the operand stack." But then again, it has this unfortunate "implementation-dependent" which can be interpreted either way :( [4] https://docs.oracle.com/javase/specs/jvms/se10/html/jvms-6.html#jvms-6.5.invokestatic > >> - to code in Java_java_io_Console_echo() should be fixed (as >> confirmed by Sherman later in this thread) > > Yes, that's a bug waiting to happen anyway. > > >> - normalization of native, off-heap 8-bit values to Java booleans as >> currently implemented in the HotSpot (and fixed by JDK-8161720) is (1) >> only for convenience to simply access to off-heap data in Unsafe, (2) >> to implement better Java/Native integration in projects like Panama >> and (3) to fix legacy JNI code which was developed under the >> assumption that the advice in the "JNI Programmer's Guide & >> Specification" book is specification relevant. > > Yes, the intent seems to be what you describe. But see above about the spec. > > > -Aleksey > > [1] https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/types.html#primitive_types > [2] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-August/024263.html > [3] https://docs.oracle.com/javase/specs/jvms/se10/html/jvms-2.html#jvms-2.3.4 > From volker.simonis at gmail.com Mon Aug 20 16:08:21 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 20 Aug 2018 18:08:21 +0200 Subject: [11] RFR(S): 8209637: [s390x] Interpreter doesn't call result handler after native calls In-Reply-To: <5ffada18fdcd4905816fbed29a6bb5dc@sap.com> References: <06592a59-7d99-254f-632d-225a51c36b5f@oracle.com> <5ffada18fdcd4905816fbed29a6bb5dc@sap.com> Message-ID: On Mon, Aug 20, 2018 at 4:24 PM, Lindenmaier, Goetz wrote: > Hi Volker, > > the fix looks good to me, but please use mem2reg_opt instead of load_and_test_long. > The test result is not used. > Good catch! I've updated the patch and placed it into our nightly build and test queue. If the results are still OK (what I expect) and Vladimir gives us his OK, I'll push it tomorrow. For reference (and Vladimir :), I've also created a new webrev: http://cr.openjdk.java.net/~simonis/webrevs/2018/8209637.v1/ > Maybe you can fix comment in line 1684: "Bandle exception" --> "Handle exception". > Done. > Don't need a new webrev. > > Thanks and best regards, > Goetz. > > >> -----Original Message----- >> From: hotspot-dev On Behalf Of >> Vladimir Kozlov >> Sent: Freitag, 17. August 2018 22:33 >> To: Volker Simonis ; HotSpot Open Source >> Developers >> Subject: Re: [11] RFR(S): 8209637: [s390x] Interpreter doesn't call result >> handler after native calls >> >> Hi Volker, >> >> Someone who is familiar with this s390 code should review it before we can >> judge if it acceptable fro JDK 11. >> >> Regards, >> Vladimir >> >> On 8/17/18 7:03 AM, Volker Simonis wrote: >> > Hi, >> > >> > can I please have a review for this small, s390x only bug fix which >> > I'd like to bring to jdk11: >> > >> > http://cr.openjdk.java.net/~simonis/webrevs/2018/8209637/ >> > https://bugs.openjdk.java.net/browse/JDK-8209637 >> > >> > The problem is that the template interpreter for s390x doesn't call >> > the result handler in the native entry. This can lead to wrong results >> > being passed as return values from native calls which return a >> > jboolean if the value is not exactly '1' or '0' (i.e. a return value >> > of '2' will be interpreted as 'false'). The result handler usually >> > normalizes such results and maps any value > 0 to 'true'. >> > >> > I'd like to bring this to jdk11 because the bug can lead to incorrect >> > results for calls to JNI functions with jboolean results. This can >> > affect not only user coding but also core library functions like >> > java.io.Console.echo() (which is called from Console.readPassword()). >> > The malfunction of these methods triggered the discovery of this bug. >> > >> > The fix is low risk and only affects the s390x port (except the >> > regression test - but that shouldn't be harmful either). >> > >> > Thank you and best regards, >> > Volker >> > From volker.simonis at gmail.com Mon Aug 20 16:08:46 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 20 Aug 2018 18:08:46 +0200 Subject: [11] RFR(S): 8209637: [s390x] Interpreter doesn't call result handler after native calls In-Reply-To: References: <06592a59-7d99-254f-632d-225a51c36b5f@oracle.com> <5ffada18fdcd4905816fbed29a6bb5dc@sap.com> Message-ID: Thanks for looking at the change! Regards, Volker On Mon, Aug 20, 2018 at 4:44 PM, Schmidt, Lutz wrote: > Hi Volker, > > I agree with Goetz's judgement. He was just a bit quicker than me. __ Thanks for tracking this down and fixing it. > > Regards, > Lutz > > ?On 20.08.18, 16:24, "hotspot-dev on behalf of Lindenmaier, Goetz" wrote: > > Hi Volker, > > the fix looks good to me, but please use mem2reg_opt instead of load_and_test_long. > The test result is not used. > > Maybe you can fix comment in line 1684: "Bandle exception" --> "Handle exception". > > Don't need a new webrev. > > Thanks and best regards, > Goetz. > > > > -----Original Message----- > > From: hotspot-dev On Behalf Of > > Vladimir Kozlov > > Sent: Freitag, 17. August 2018 22:33 > > To: Volker Simonis ; HotSpot Open Source > > Developers > > Subject: Re: [11] RFR(S): 8209637: [s390x] Interpreter doesn't call result > > handler after native calls > > > > Hi Volker, > > > > Someone who is familiar with this s390 code should review it before we can > > judge if it acceptable fro JDK 11. > > > > Regards, > > Vladimir > > > > On 8/17/18 7:03 AM, Volker Simonis wrote: > > > Hi, > > > > > > can I please have a review for this small, s390x only bug fix which > > > I'd like to bring to jdk11: > > > > > > http://cr.openjdk.java.net/~simonis/webrevs/2018/8209637/ > > > https://bugs.openjdk.java.net/browse/JDK-8209637 > > > > > > The problem is that the template interpreter for s390x doesn't call > > > the result handler in the native entry. This can lead to wrong results > > > being passed as return values from native calls which return a > > > jboolean if the value is not exactly '1' or '0' (i.e. a return value > > > of '2' will be interpreted as 'false'). The result handler usually > > > normalizes such results and maps any value > 0 to 'true'. > > > > > > I'd like to bring this to jdk11 because the bug can lead to incorrect > > > results for calls to JNI functions with jboolean results. This can > > > affect not only user coding but also core library functions like > > > java.io.Console.echo() (which is called from Console.readPassword()). > > > The malfunction of these methods triggered the discovery of this bug. > > > > > > The fix is low risk and only affects the s390x port (except the > > > regression test - but that shouldn't be harmful either). > > > > > > Thank you and best regards, > > > Volker > > > > > From rednaxelafx at gmail.com Mon Aug 20 16:09:48 2018 From: rednaxelafx at gmail.com (Krystal Mok) Date: Mon, 20 Aug 2018 09:09:48 -0700 Subject: Is returning a value != '0' or '1' as jboolean from a JNI function legal? In-Reply-To: References: <130e0b86-e41f-fda7-5a6f-03b2135a9a60@redhat.com> Message-ID: Hi guys, Haha this is fun. I actually hit this issue the hard way and had to tweak a bit of my code to accommodate that: I had to return a jint from a function that I wanted to return a jbool at first: http://hg.openjdk.java.net/hsx/hsx25/hotspot/diff/8f37087fc13f/src/share/vm/c1/c1_Runtime1.cpp - Kris On Mon, Aug 20, 2018 at 8:38 AM Volker Simonis wrote: > On Mon, Aug 20, 2018 at 4:55 PM, Aleksey Shipilev > wrote: > > On 08/20/2018 12:22 PM, Volker Simonis wrote: > >> So to summarize, my current view on this topic is: > >> - JNI functions returning a jboolean are only allowed to return > >> JNI_TRUE/JNI_FALSE (or 1/0) according to the current JNI spcification. > > > > Now *I* am having trouble seeing where exactly the JNI spec says the > domain of jboolean is > > (JNI_FALSE, JNI_TRUE). In "Primitive Types" [1] it says "The following > definition is provided for > > convenience: JNI_FALSE, JNI_TRUE", but that does not restrict the > domain, because those are > > "convenience" defines. And "Description" in the table says jboolean is > "unsigned 8 bits", which > > seems to invite interpretation that all 8 bits are usable. > > > > John says [2]: > > > > "The JNI documents specify that, at least for returning values from > native methods, a Java boolean > > (T_BOOLEAN) value is converted to the value-set 0..1 by first truncating > to a byte (0..255 or maybe > > -128..127) and then testing against zero." > > > > ...which is what I am looking for, but I cannot find the "JNI document" > that actually says that. I > > can see the idea of that in JVMS [3], but that seems to only apply to > on-heap booleans, does that > > also extend to jboolean's? Maybe John can point out the JNI document > where it is said explicitly? > > > > Yes, you're right - there's no exact documentation for neither of the > two possible interpretations. A colleague just pointed me to the > definition of invokestatic in the JVMS [4] which has the following > sentence: > > "If the native method returns a value, the return value of the > platform-dependent code is converted in an implementation-dependent > way to the return type of the native method and pushed onto the > operand stack." > > But then again, it has this unfortunate "implementation-dependent" > which can be interpreted either way :( > > [4] > https://docs.oracle.com/javase/specs/jvms/se10/html/jvms-6.html#jvms-6.5.invokestatic > > > > >> - to code in Java_java_io_Console_echo() should be fixed (as > >> confirmed by Sherman later in this thread) > > > > Yes, that's a bug waiting to happen anyway. > > > > > >> - normalization of native, off-heap 8-bit values to Java booleans as > >> currently implemented in the HotSpot (and fixed by JDK-8161720) is (1) > >> only for convenience to simply access to off-heap data in Unsafe, (2) > >> to implement better Java/Native integration in projects like Panama > >> and (3) to fix legacy JNI code which was developed under the > >> assumption that the advice in the "JNI Programmer's Guide & > >> Specification" book is specification relevant. > > > > Yes, the intent seems to be what you describe. But see above about the > spec. > > > > > > -Aleksey > > > > [1] > https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/types.html#primitive_types > > [2] > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-August/024263.html > > [3] > https://docs.oracle.com/javase/specs/jvms/se10/html/jvms-2.html#jvms-2.3.4 > > > From volker.simonis at gmail.com Mon Aug 20 16:28:48 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 20 Aug 2018 18:28:48 +0200 Subject: Is returning a value != '0' or '1' as jboolean from a JNI function legal? In-Reply-To: References: <130e0b86-e41f-fda7-5a6f-03b2135a9a60@redhat.com> Message-ID: On Mon, Aug 20, 2018 at 6:09 PM, Krystal Mok wrote: > Hi guys, > > Haha this is fun. I actually hit this issue the hard way and had to tweak a > bit of my code to accommodate that: I had to return a jint from a function > that I wanted to return a jbool at first: > http://hg.openjdk.java.net/hsx/hsx25/hotspot/diff/8f37087fc13f/src/share/vm/c1/c1_Runtime1.cpp > Interesting, but I think that mis-behavior should have been fixed meanwhile by the infamous "Better byte behavior" change [1] (which was a security fix, so you won't find too much information about it). So maybe you can remove your workaround and comment now :) [1] http://hg.openjdk.java.net/jdk/jdk/rev/291ee208fb72 > - Kris > > On Mon, Aug 20, 2018 at 8:38 AM Volker Simonis > wrote: >> >> On Mon, Aug 20, 2018 at 4:55 PM, Aleksey Shipilev >> wrote: >> > On 08/20/2018 12:22 PM, Volker Simonis wrote: >> >> So to summarize, my current view on this topic is: >> >> - JNI functions returning a jboolean are only allowed to return >> >> JNI_TRUE/JNI_FALSE (or 1/0) according to the current JNI spcification. >> > >> > Now *I* am having trouble seeing where exactly the JNI spec says the >> > domain of jboolean is >> > (JNI_FALSE, JNI_TRUE). In "Primitive Types" [1] it says "The following >> > definition is provided for >> > convenience: JNI_FALSE, JNI_TRUE", but that does not restrict the >> > domain, because those are >> > "convenience" defines. And "Description" in the table says jboolean is >> > "unsigned 8 bits", which >> > seems to invite interpretation that all 8 bits are usable. >> > >> > John says [2]: >> > >> > "The JNI documents specify that, at least for returning values from >> > native methods, a Java boolean >> > (T_BOOLEAN) value is converted to the value-set 0..1 by first truncating >> > to a byte (0..255 or maybe >> > -128..127) and then testing against zero." >> > >> > ...which is what I am looking for, but I cannot find the "JNI document" >> > that actually says that. I >> > can see the idea of that in JVMS [3], but that seems to only apply to >> > on-heap booleans, does that >> > also extend to jboolean's? Maybe John can point out the JNI document >> > where it is said explicitly? >> > >> >> Yes, you're right - there's no exact documentation for neither of the >> two possible interpretations. A colleague just pointed me to the >> definition of invokestatic in the JVMS [4] which has the following >> sentence: >> >> "If the native method returns a value, the return value of the >> platform-dependent code is converted in an implementation-dependent >> way to the return type of the native method and pushed onto the >> operand stack." >> >> But then again, it has this unfortunate "implementation-dependent" >> which can be interpreted either way :( >> >> [4] >> https://docs.oracle.com/javase/specs/jvms/se10/html/jvms-6.html#jvms-6.5.invokestatic >> >> > >> >> - to code in Java_java_io_Console_echo() should be fixed (as >> >> confirmed by Sherman later in this thread) >> > >> > Yes, that's a bug waiting to happen anyway. >> > >> > >> >> - normalization of native, off-heap 8-bit values to Java booleans as >> >> currently implemented in the HotSpot (and fixed by JDK-8161720) is (1) >> >> only for convenience to simply access to off-heap data in Unsafe, (2) >> >> to implement better Java/Native integration in projects like Panama >> >> and (3) to fix legacy JNI code which was developed under the >> >> assumption that the advice in the "JNI Programmer's Guide & >> >> Specification" book is specification relevant. >> > >> > Yes, the intent seems to be what you describe. But see above about the >> > spec. >> > >> > >> > -Aleksey >> > >> > [1] >> > https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/types.html#primitive_types >> > [2] >> > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-August/024263.html >> > [3] >> > https://docs.oracle.com/javase/specs/jvms/se10/html/jvms-2.html#jvms-2.3.4 >> > From aeubanks at google.com Mon Aug 20 17:11:11 2018 From: aeubanks at google.com (Arthur Eubanks) Date: Mon, 20 Aug 2018 10:11:11 -0700 Subject: Linux + Clang + execstack Message-ID: Hi, At Google we're trying to build hotspot on Linux with clang. One thing that happens is that the resulting libjvm.so is stack executable. When running hotspot we get warnings about the stack being executable. Compiling an assembly file into the final .so results in the stack being executable. In this case the file is linux_x86_64.s. This doesn't happen with gcc because "-Wl,-z,noexecstack" is passed as a hotspot linker flag with gcc in flags-ldflags.m4. When using clang that linker flag isn't passed. Doing something like the solution in https://wiki.ubuntu.com/SecurityTeam/Roadmap/ExecutableStacks fixes the problem without the use of linker flags. The jtreg test test/hotspot/jtreg/runtime/execstack/TestCheckJDK.java checks for the stack being executable. Any thoughts? If there are no objections, I can propose a patch that works for both gcc and clang on Linux. Also, I'm not sure how/if macOS handles this problem given that it uses clang. From aph at redhat.com Mon Aug 20 17:23:49 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 20 Aug 2018 18:23:49 +0100 Subject: Is returning a value != '0' or '1' as jboolean from a JNI function legal? In-Reply-To: <478E59AB-0EF6-4954-9A10-E3A742A0A081@redhat.com> References: <130e0b86-e41f-fda7-5a6f-03b2135a9a60@redhat.com> <478E59AB-0EF6-4954-9A10-E3A742A0A081@redhat.com> Message-ID: <1c20ca62-f26f-6b69-d5ec-9f9a862efaad@redhat.com> On 08/20/2018 04:14 PM, Jason Greene wrote: > IMO departing from C semantics (non-zero = TRUE, zero = false) > offers little gain and will likely just lead to hard to catch > bugs. Even if the JNI developer knows the rules, it will be quite > easy for surprises to show up. For example, a developer might assume > a library call always returns 1, and wire it straight to a > boolean. If this assumption is broken (a condition not taken into > account, or future behavioral differences), then it could quickly > turn into a lot of wasted time and effort. It's tricky, though: a C implementation could silently truncate a value of 0xff00_0000 to (jboolean) 0x00, and there's not a damn thing that a JVM can do about it: there's literally no way to know. It's pretty much unfixable from our end. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From coleen.phillimore at oracle.com Mon Aug 20 17:29:33 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 20 Aug 2018 13:29:33 -0400 Subject: RFR (XS) 8209738: Remove ClassLoaderDataGraph::*oops_do functions Message-ID: Summary: Make walking CLDG more consistent. Affects ParallelGC and jvmtiTagMap. open webrev at http://cr.openjdk.java.net/~coleenp/8209738.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8209738 Tested with mach5 tier1-7 and with runThese with all GCs. Thanks, Coleen From rednaxelafx at gmail.com Mon Aug 20 18:16:34 2018 From: rednaxelafx at gmail.com (Krystal Mok) Date: Mon, 20 Aug 2018 11:16:34 -0700 Subject: Is returning a value != '0' or '1' as jboolean from a JNI function legal? In-Reply-To: References: <130e0b86-e41f-fda7-5a6f-03b2135a9a60@redhat.com> Message-ID: Thanks Volker! I hadn't been following new development much and this is great! I just checked the latest HS sources [1] and my old code is still there. I'll prepare a webrev to remove that workaround code. Thanks, Kris [1]: http://hg.openjdk.java.net/jdk/jdk/file/8dfed4387312/src/hotspot/share/c1/c1_Runtime1.cpp#l1380 On Mon, Aug 20, 2018 at 9:28 AM, Volker Simonis wrote: > On Mon, Aug 20, 2018 at 6:09 PM, Krystal Mok > wrote: > > Hi guys, > > > > Haha this is fun. I actually hit this issue the hard way and had to > tweak a > > bit of my code to accommodate that: I had to return a jint from a > function > > that I wanted to return a jbool at first: > > http://hg.openjdk.java.net/hsx/hsx25/hotspot/diff/ > 8f37087fc13f/src/share/vm/c1/c1_Runtime1.cpp > > > > Interesting, but I think that mis-behavior should have been fixed > meanwhile by the infamous "Better byte behavior" change [1] (which was > a security fix, so you won't find too much information about it). > > So maybe you can remove your workaround and comment now :) > > [1] http://hg.openjdk.java.net/jdk/jdk/rev/291ee208fb72 > > > - Kris > > > > On Mon, Aug 20, 2018 at 8:38 AM Volker Simonis > > > wrote: > >> > >> On Mon, Aug 20, 2018 at 4:55 PM, Aleksey Shipilev > >> wrote: > >> > On 08/20/2018 12:22 PM, Volker Simonis wrote: > >> >> So to summarize, my current view on this topic is: > >> >> - JNI functions returning a jboolean are only allowed to return > >> >> JNI_TRUE/JNI_FALSE (or 1/0) according to the current JNI > spcification. > >> > > >> > Now *I* am having trouble seeing where exactly the JNI spec says the > >> > domain of jboolean is > >> > (JNI_FALSE, JNI_TRUE). In "Primitive Types" [1] it says "The following > >> > definition is provided for > >> > convenience: JNI_FALSE, JNI_TRUE", but that does not restrict the > >> > domain, because those are > >> > "convenience" defines. And "Description" in the table says jboolean is > >> > "unsigned 8 bits", which > >> > seems to invite interpretation that all 8 bits are usable. > >> > > >> > John says [2]: > >> > > >> > "The JNI documents specify that, at least for returning values from > >> > native methods, a Java boolean > >> > (T_BOOLEAN) value is converted to the value-set 0..1 by first > truncating > >> > to a byte (0..255 or maybe > >> > -128..127) and then testing against zero." > >> > > >> > ...which is what I am looking for, but I cannot find the "JNI > document" > >> > that actually says that. I > >> > can see the idea of that in JVMS [3], but that seems to only apply to > >> > on-heap booleans, does that > >> > also extend to jboolean's? Maybe John can point out the JNI document > >> > where it is said explicitly? > >> > > >> > >> Yes, you're right - there's no exact documentation for neither of the > >> two possible interpretations. A colleague just pointed me to the > >> definition of invokestatic in the JVMS [4] which has the following > >> sentence: > >> > >> "If the native method returns a value, the return value of the > >> platform-dependent code is converted in an implementation-dependent > >> way to the return type of the native method and pushed onto the > >> operand stack." > >> > >> But then again, it has this unfortunate "implementation-dependent" > >> which can be interpreted either way :( > >> > >> [4] > >> https://docs.oracle.com/javase/specs/jvms/se10/html/ > jvms-6.html#jvms-6.5.invokestatic > >> > >> > > >> >> - to code in Java_java_io_Console_echo() should be fixed (as > >> >> confirmed by Sherman later in this thread) > >> > > >> > Yes, that's a bug waiting to happen anyway. > >> > > >> > > >> >> - normalization of native, off-heap 8-bit values to Java booleans as > >> >> currently implemented in the HotSpot (and fixed by JDK-8161720) is > (1) > >> >> only for convenience to simply access to off-heap data in Unsafe, (2) > >> >> to implement better Java/Native integration in projects like Panama > >> >> and (3) to fix legacy JNI code which was developed under the > >> >> assumption that the advice in the "JNI Programmer's Guide & > >> >> Specification" book is specification relevant. > >> > > >> > Yes, the intent seems to be what you describe. But see above about the > >> > spec. > >> > > >> > > >> > -Aleksey > >> > > >> > [1] > >> > https://docs.oracle.com/javase/8/docs/technotes/ > guides/jni/spec/types.html#primitive_types > >> > [2] > >> > http://mail.openjdk.java.net/pipermail/hotspot-compiler- > dev/2016-August/024263.html > >> > [3] > >> > https://docs.oracle.com/javase/specs/jvms/se10/html/ > jvms-2.html#jvms-2.3.4 > >> > > From igor.ignatyev at oracle.com Mon Aug 20 18:29:58 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 20 Aug 2018 11:29:58 -0700 Subject: RFR(XXS) : 8209740 : typo in test/lib/jtreg/SkippedException.java Message-ID: <462E525B-3997-48FA-AD87-BB803FF63FE4@oracle.com> http://cr.openjdk.java.net/~iignatyev//8209740/webrev.00/index.html > 1 line changed: 0 ins; 0 del; 1 mod; Hi all, could you please review this trivial fix for the typo in SkippedException.java ? Thank Martin B for reporting the typo. JBS: https://bugs.openjdk.java.net/browse/JDK-8209740 webrev: http://cr.openjdk.java.net/~iignatyev//8209740/webrev.00/index.html Thanks, -- Igor From vladimir.kozlov at oracle.com Mon Aug 20 18:33:22 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 20 Aug 2018 11:33:22 -0700 Subject: RFR(XXS) : 8209740 : typo in test/lib/jtreg/SkippedException.java In-Reply-To: <462E525B-3997-48FA-AD87-BB803FF63FE4@oracle.com> References: <462E525B-3997-48FA-AD87-BB803FF63FE4@oracle.com> Message-ID: <1a6bd277-5d1a-49da-6794-13ee46958d12@oracle.com> Good. Thanks, Vladimir On 8/20/18 11:29 AM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8209740/webrev.00/index.html >> 1 line changed: 0 ins; 0 del; 1 mod; > > Hi all, > > could you please review this trivial fix for the typo in SkippedException.java ? Thank Martin B for reporting the typo. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8209740 > webrev: http://cr.openjdk.java.net/~iignatyev//8209740/webrev.00/index.html > > Thanks, > -- Igor > > > > > From mikhailo.seledtsov at oracle.com Mon Aug 20 19:10:57 2018 From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov) Date: Mon, 20 Aug 2018 12:10:57 -0700 Subject: RFR(XXS) : 8209740 : typo in test/lib/jtreg/SkippedException.java In-Reply-To: <1a6bd277-5d1a-49da-6794-13ee46958d12@oracle.com> References: <462E525B-3997-48FA-AD87-BB803FF63FE4@oracle.com> <1a6bd277-5d1a-49da-6794-13ee46958d12@oracle.com> Message-ID: <5B7B1241.90702@oracle.com> +1 On 8/20/18, 11:33 AM, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 8/20/18 11:29 AM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8209740/webrev.00/index.html >>> 1 line changed: 0 ins; 0 del; 1 mod; >> >> Hi all, >> >> could you please review this trivial fix for the typo in >> SkippedException.java ? Thank Martin B for reporting the typo. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8209740 >> webrev: >> http://cr.openjdk.java.net/~iignatyev//8209740/webrev.00/index.html >> >> Thanks, >> -- Igor >> >> >> >> From jason.greene at redhat.com Mon Aug 20 19:25:32 2018 From: jason.greene at redhat.com (Jason Greene) Date: Mon, 20 Aug 2018 14:25:32 -0500 Subject: Is returning a value != '0' or '1' as jboolean from a JNI function legal? In-Reply-To: <1c20ca62-f26f-6b69-d5ec-9f9a862efaad@redhat.com> References: <130e0b86-e41f-fda7-5a6f-03b2135a9a60@redhat.com> <478E59AB-0EF6-4954-9A10-E3A742A0A081@redhat.com> <1c20ca62-f26f-6b69-d5ec-9f9a862efaad@redhat.com> Message-ID: <85BA0604-C712-436C-9C97-F4476D0D0797@redhat.com> > On Aug 20, 2018, at 12:23 PM, Andrew Haley wrote: > > On 08/20/2018 04:14 PM, Jason Greene wrote: > >> IMO departing from C semantics (non-zero = TRUE, zero = false) >> offers little gain and will likely just lead to hard to catch >> bugs. Even if the JNI developer knows the rules, it will be quite >> easy for surprises to show up. For example, a developer might assume >> a library call always returns 1, and wire it straight to a >> boolean. If this assumption is broken (a condition not taken into >> account, or future behavioral differences), then it could quickly >> turn into a lot of wasted time and effort. > > It's tricky, though: a C implementation could silently truncate a > value of 0xff00_0000 to (jboolean) 0x00, and there's not a damn thing > that a JVM can do about it: there's literally no way to know. It's > pretty much unfixable from our end. OK but in that case the C developer can see its an unsigned char, and their compiler is likely to throw an overflow warning. Granted, it?s also true that int is a more common return value than unsigned char. -Jason From vladimir.kozlov at oracle.com Mon Aug 20 22:01:37 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 20 Aug 2018 15:01:37 -0700 Subject: [11] RFR(S): 8209637: [s390x] Interpreter doesn't call result handler after native calls In-Reply-To: References: <06592a59-7d99-254f-632d-225a51c36b5f@oracle.com> <5ffada18fdcd4905816fbed29a6bb5dc@sap.com> Message-ID: <865fdfe5-8a5a-41e5-0f32-07b79636e61e@oracle.com> Testing passed and I approved it. Please, push fix into jdk11 ASAP - we have one day left. Thanks, Vladimir On 8/20/18 9:08 AM, Volker Simonis wrote: > On Mon, Aug 20, 2018 at 4:24 PM, Lindenmaier, Goetz > wrote: >> Hi Volker, >> >> the fix looks good to me, but please use mem2reg_opt instead of load_and_test_long. >> The test result is not used. >> > > Good catch! I've updated the patch and placed it into our nightly > build and test queue. If the results are still OK (what I expect) and > Vladimir gives us his OK, I'll push it tomorrow. > > For reference (and Vladimir :), I've also created a new webrev: > > http://cr.openjdk.java.net/~simonis/webrevs/2018/8209637.v1/ > >> Maybe you can fix comment in line 1684: "Bandle exception" --> "Handle exception". >> > > Done. > >> Don't need a new webrev. >> >> Thanks and best regards, >> Goetz. >> >> >>> -----Original Message----- >>> From: hotspot-dev On Behalf Of >>> Vladimir Kozlov >>> Sent: Freitag, 17. August 2018 22:33 >>> To: Volker Simonis ; HotSpot Open Source >>> Developers >>> Subject: Re: [11] RFR(S): 8209637: [s390x] Interpreter doesn't call result >>> handler after native calls >>> >>> Hi Volker, >>> >>> Someone who is familiar with this s390 code should review it before we can >>> judge if it acceptable fro JDK 11. >>> >>> Regards, >>> Vladimir >>> >>> On 8/17/18 7:03 AM, Volker Simonis wrote: >>>> Hi, >>>> >>>> can I please have a review for this small, s390x only bug fix which >>>> I'd like to bring to jdk11: >>>> >>>> http://cr.openjdk.java.net/~simonis/webrevs/2018/8209637/ >>>> https://bugs.openjdk.java.net/browse/JDK-8209637 >>>> >>>> The problem is that the template interpreter for s390x doesn't call >>>> the result handler in the native entry. This can lead to wrong results >>>> being passed as return values from native calls which return a >>>> jboolean if the value is not exactly '1' or '0' (i.e. a return value >>>> of '2' will be interpreted as 'false'). The result handler usually >>>> normalizes such results and maps any value > 0 to 'true'. >>>> >>>> I'd like to bring this to jdk11 because the bug can lead to incorrect >>>> results for calls to JNI functions with jboolean results. This can >>>> affect not only user coding but also core library functions like >>>> java.io.Console.echo() (which is called from Console.readPassword()). >>>> The malfunction of these methods triggered the discovery of this bug. >>>> >>>> The fix is low risk and only affects the s390x port (except the >>>> regression test - but that shouldn't be harmful either). >>>> >>>> Thank you and best regards, >>>> Volker >>>> From igor.ignatyev at oracle.com Mon Aug 20 22:59:18 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 20 Aug 2018 15:59:18 -0700 Subject: RFR(M/L) : 8209611 : use C++ compiler for hotspot tests Message-ID: <92CD42CC-568A-4972-A35E-469B1532B103@oracle.com> http://cr.openjdk.java.net/~iignatyev//8209611/webrev.01/index.html > 11160 lines changed: 879 ins; 61 del; 10220 mod; Hi all, could you please review the patch which moves all hotspot native test code to C++? this will guarantee that we always use C++ compilers for them (as an opposite to either C or C++ compiler depending on configuration), as a result we will be able to get rid of JNI_ENV_ARG[1] macros, perform other clean ups and improve overall quality of the test code. the patch consists of two parts: - automatic: renaming .c files to .cpp, updating #include, changing JNI/JVMTI calls - semi-manual: adding extern "C" , fixing a number of compiler warnings (mostly types inconsistency), updating makefiles JBS: https://bugs.openjdk.java.net/browse/JDK-8209611 webrevs: - automatic: http://cr.openjdk.java.net/~iignatyev//8209611/webrev.00/index.html > 9394 lines changed: 0 ins; 0 del; 9394 mod; - semi-manual: http://cr.openjdk.java.net/~iignatyev//8209611/webrev.0-1/index.html > 1899 lines changed: 879 ins; 61 del; 959 mod - whole: http://cr.openjdk.java.net/~iignatyev//8209611/webrev.01/index.html > 11160 lines changed: 879 ins; 61 del; 10220 mod; testing: all hotspot tests + tier[1-3] [1] https://bugs.openjdk.java.net/browse/JDK-8209547 Thanks, -- Igor From david.holmes at oracle.com Mon Aug 20 23:18:05 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 Aug 2018 09:18:05 +1000 Subject: Linux + Clang + execstack In-Reply-To: References: Message-ID: <26c39a87-9db0-d62a-e026-e4075e3237fb@oracle.com> Hi Arthur, cc'ing build-dev as this is currently a build issue. On 21/08/2018 3:11 AM, Arthur Eubanks wrote: > Hi, > > At Google we're trying to build hotspot on Linux with clang. One thing that > happens is that the resulting libjvm.so is stack executable. When running > hotspot we get warnings about the stack being executable. > > Compiling an assembly file into the final .so results in the stack being > executable. In this case the file is linux_x86_64.s. This doesn't happen > with gcc because "-Wl,-z,noexecstack" is passed as a hotspot linker flag > with gcc in flags-ldflags.m4. When using clang that linker flag isn't > passed. > > Doing something like the solution in > https://wiki.ubuntu.com/SecurityTeam/Roadmap/ExecutableStacks > fixes the problem without the use of linker flags. You mean the source code directives for the linker? I think I prefer to see this handled explicitly in the build as is currently done. Can we just adjust ./make/autoconf/flags-ldflags.m4 to pass the linker flags for gcc and clang? > The jtreg test test/hotspot/jtreg/runtime/execstack/TestCheckJDK.java > checks for the stack being executable. > > Any thoughts? If there are no objections, I can propose a patch that works > for both gcc and clang on Linux. Also, I'm not sure how/if macOS handles > this problem given that it uses clang. We don't seem to handle it at all on OS X. Does OS X prevent executable stacks itself? David From aeubanks at google.com Mon Aug 20 23:39:55 2018 From: aeubanks at google.com (Arthur Eubanks) Date: Mon, 20 Aug 2018 16:39:55 -0700 Subject: Linux + Clang + execstack In-Reply-To: <26c39a87-9db0-d62a-e026-e4075e3237fb@oracle.com> References: <26c39a87-9db0-d62a-e026-e4075e3237fb@oracle.com> Message-ID: On Mon, Aug 20, 2018 at 4:18 PM David Holmes wrote: > Hi Arthur, > > cc'ing build-dev as this is currently a build issue. > > On 21/08/2018 3:11 AM, Arthur Eubanks wrote: > > Hi, > > > > At Google we're trying to build hotspot on Linux with clang. One thing > that > > happens is that the resulting libjvm.so is stack executable. When running > > hotspot we get warnings about the stack being executable. > > > > Compiling an assembly file into the final .so results in the stack being > > executable. In this case the file is linux_x86_64.s. This doesn't happen > > with gcc because "-Wl,-z,noexecstack" is passed as a hotspot linker flag > > with gcc in flags-ldflags.m4. When using clang that linker flag isn't > > passed. > > > > Doing something like the solution in > > https://wiki.ubuntu.com/SecurityTeam/Roadmap/ExecutableStacks > > fixes the problem without the use of linker flags. > > You mean the source code directives for the linker? > Sorry, I wasn't specific enough, I meant the flags for the assembler. #if defined(__linux__) && defined(__ELF__) .section .note.GNU-stack, "", %progbits #endif > > I think I prefer to see this handled explicitly in the build as is > currently done. Can we just adjust ./make/autoconf/flags-ldflags.m4 to > pass the linker flags for gcc and clang? > I don't mind this solution, but it seems like the right thing to do is to fix things at the source level and remove extra unnecessary linker flags. I removed "-Wl,-z,noexecstack" from the flags after adding the above assembler flags and libjvm.so is still correctly not stack executable. I don't really mind either way though. Maybe it's good to have an extra safeguard in the linker flags. > > > The jtreg test test/hotspot/jtreg/runtime/execstack/TestCheckJDK.java > > checks for the stack being executable. > > > > Any thoughts? If there are no objections, I can propose a patch that > works > > for both gcc and clang on Linux. Also, I'm not sure how/if macOS handles > > this problem given that it uses clang. > > We don't seem to handle it at all on OS X. Does OS X prevent executable > stacks itself? > A quick search, according to Wikipedia ( https://en.wikipedia.org/wiki/Executable_space_protection#macOS), 64-bit executables on macOS aren't stack or heap executable. Not sure if that information is accurate though. > > David > > From david.holmes at oracle.com Tue Aug 21 00:03:36 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 Aug 2018 10:03:36 +1000 Subject: Linux + Clang + execstack In-Reply-To: References: <26c39a87-9db0-d62a-e026-e4075e3237fb@oracle.com> Message-ID: On 21/08/2018 9:39 AM, Arthur Eubanks wrote: > On Mon, Aug 20, 2018 at 4:18 PM David Holmes > wrote: > > Hi Arthur, > > cc'ing build-dev as this is currently a build issue. > > On 21/08/2018 3:11 AM, Arthur Eubanks wrote: > > Hi, > > > > At Google we're trying to build hotspot on Linux with clang. One > thing that > > happens is that the resulting libjvm.so is stack executable. When > running > > hotspot we get warnings about the stack being executable. > > > > Compiling an assembly file into the final .so results in the > stack being > > executable. In this case the file is linux_x86_64.s. This doesn't > happen > > with gcc because "-Wl,-z,noexecstack" is passed as a hotspot > linker flag > > with gcc in flags-ldflags.m4. When using clang that linker flag isn't > > passed. > > > > Doing something like the solution in > > https://wiki.ubuntu.com/SecurityTeam/Roadmap/ExecutableStacks > > fixes the problem without the use of linker flags. > > You mean the source code directives for the linker? > > Sorry, I wasn't specific enough, I meant the flags for the assembler. > #if defined(__linux__) && defined(__ELF__) > .section? ? ? ? .note.GNU-stack, "", %progbits > #endif > > > I think I prefer to see this handled explicitly in the build as is > currently done. Can we just adjust ./make/autoconf/flags-ldflags.m4 to > pass the linker flags for gcc and clang? > > I don't mind this solution, but it seems like the right thing to do is > to fix things at the source level and remove extra unnecessary linker > flags. Personally I see this as source code pollution. The concept of executable stacks has nothing to do with what is being expressed by the source code, or the language used for it. Just my 2c. I'll defer to build folk ... though they are still on vacation at the moment. > I removed?"-Wl,-z,noexecstack" from the flags after adding the > above assembler flags and libjvm.so is still correctly not stack > executable. I don't really mind either way though. Maybe it's good to > have an extra safeguard in the linker flags. > > > > The jtreg test test/hotspot/jtreg/runtime/execstack/TestCheckJDK.java > > checks for the stack being executable. > > > > Any thoughts? If there are no objections, I can propose a patch > that works > > for both gcc and clang on Linux. Also, I'm not sure how/if macOS > handles > > this problem given that it uses clang. > > We don't seem to handle it at all on OS X. Does OS X prevent executable > stacks itself? > > A quick search, according to Wikipedia > (https://en.wikipedia.org/wiki/Executable_space_protection#macOS), > 64-bit executables on macOS aren't stack or heap executable. Not sure if > that information is accurate though. Seems to be: https://developer.apple.com/library/archive/documentation/Security/Conceptual/SecureCodingGuide/Articles/BufferOverflows.html "macOS and iOS provide two features that can make it harder to exploit stack and buffer overflows: address space layout randomization (ASLR) and a non-executable stack and heap." Cheers, David > > David > From david.holmes at oracle.com Tue Aug 21 00:18:30 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 Aug 2018 10:18:30 +1000 Subject: RFR (XS) 8209738: Remove ClassLoaderDataGraph::*oops_do functions In-Reply-To: References: Message-ID: <35d9a02c-1499-2a5a-99f6-7b3feaf5943a@oracle.com> Hi Coleen, This looks fine. Thanks, David On 21/08/2018 3:29 AM, coleen.phillimore at oracle.com wrote: > Summary: Make walking CLDG more consistent. > > Affects ParallelGC and jvmtiTagMap. > > open webrev at http://cr.openjdk.java.net/~coleenp/8209738.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8209738 > > Tested with mach5 tier1-7 and with runThese with all GCs. > > Thanks, > Coleen From coleen.phillimore at oracle.com Tue Aug 21 00:31:10 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 20 Aug 2018 20:31:10 -0400 Subject: RFR (XS) 8209738: Remove ClassLoaderDataGraph::*oops_do functions In-Reply-To: <35d9a02c-1499-2a5a-99f6-7b3feaf5943a@oracle.com> References: <35d9a02c-1499-2a5a-99f6-7b3feaf5943a@oracle.com> Message-ID: Thank you for the code review!? (and thank you for the other one too). Coleen On 8/20/18 8:18 PM, David Holmes wrote: > Hi Coleen, > > This looks fine. > > Thanks, > David > > On 21/08/2018 3:29 AM, coleen.phillimore at oracle.com wrote: >> Summary: Make walking CLDG more consistent. >> >> Affects ParallelGC and jvmtiTagMap. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8209738.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8209738 >> >> Tested with mach5 tier1-7 and with runThese with all GCs. >> >> Thanks, >> Coleen From david.holmes at oracle.com Tue Aug 21 01:43:34 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 Aug 2018 11:43:34 +1000 Subject: RFR(M/L) : 8209611 : use C++ compiler for hotspot tests In-Reply-To: <92CD42CC-568A-4972-A35E-469B1532B103@oracle.com> References: <92CD42CC-568A-4972-A35E-469B1532B103@oracle.com> Message-ID: <9f172999-2e45-8ebd-dba6-5d2d8927309b@oracle.com> Hi Igor, On 21/08/2018 8:59 AM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8209611/webrev.01/index.html >> 11160 lines changed: 879 ins; 61 del; 10220 mod; > > Hi all, > > could you please review the patch which moves all hotspot native test code to C++? this will guarantee that we always use C++ compilers for them (as an opposite to either C or C++ compiler depending on configuration), as a result we will be able to get rid of JNI_ENV_ARG[1] macros, perform other clean ups and improve overall quality of the test code. Sorry but I don't see why this is necessary. If people want to be able to write C++ tests then we should enable that if not currently enabled, but I don't see why everything should be forced to C++. What if we did something that broke the C linkage and we didn't detect it because we only ever tested C++? Was the motivation previously discussed somewhere? Thanks, David > the patch consists of two parts: > - automatic: renaming .c files to .cpp, updating #include, changing JNI/JVMTI calls > - semi-manual: adding extern "C" , fixing a number of compiler warnings (mostly types inconsistency), updating makefiles > > JBS: https://bugs.openjdk.java.net/browse/JDK-8209611 > webrevs: > - automatic: http://cr.openjdk.java.net/~iignatyev//8209611/webrev.00/index.html >> 9394 lines changed: 0 ins; 0 del; 9394 mod; > > - semi-manual: http://cr.openjdk.java.net/~iignatyev//8209611/webrev.0-1/index.html >> 1899 lines changed: 879 ins; 61 del; 959 mod > > - whole: http://cr.openjdk.java.net/~iignatyev//8209611/webrev.01/index.html >> 11160 lines changed: 879 ins; 61 del; 10220 mod; > > testing: all hotspot tests + tier[1-3] > > [1] https://bugs.openjdk.java.net/browse/JDK-8209547 > > Thanks, > -- Igor > From weijun.wang at oracle.com Tue Aug 21 02:53:36 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 21 Aug 2018 10:53:36 +0800 Subject: [test] RFR 8209771: jdk.test.lib.Utils::runAndCheckException error Message-ID: <1C55A939-D937-4BC3-8AEB-F8C3F54FD4D8@oracle.com> Please take a review at https://bugs.openjdk.java.net/browse/JDK-8209771 http://cr.openjdk.java.net/~weijun/8209771/webrev.00/ There is an error in the implementation of the method, and I also think ThrowingRunnable is more developer friendly here. The methods are only used in hotspot so I'm asking for the code review here. I also think in filterException(), filter.apply(null) should be called if test.run() has not thrown any exception, but this is a behavior change and I cannot be sure. Please include my name in the recipient list as I'm not in the mail list. This will be a noreg-self. Thanks Max From igor.ignatyev at oracle.com Tue Aug 21 03:58:39 2018 From: igor.ignatyev at oracle.com (Igor Ignatev) Date: Mon, 20 Aug 2018 20:58:39 -0700 Subject: RFR(M/L) : 8209611 : use C++ compiler for hotspot tests In-Reply-To: <9f172999-2e45-8ebd-dba6-5d2d8927309b@oracle.com> References: <92CD42CC-568A-4972-A35E-469B1532B103@oracle.com> <9f172999-2e45-8ebd-dba6-5d2d8927309b@oracle.com> Message-ID: Hi David, It is necessary for vmTestbase tests (if we of course want to clean them up) as they are coupled, and moving only part of them will require (non trivial) updates in the rest of code (or at least in the shared part) to properly serve both compilers. It absolutely not necessary for other tests, but I?d prefer to have some level of unification in the test base. That being said, I agree I might went too far and moved all the tests which might or might not compromise their purpose. I personally don?t think we should relay on our jtreg testbase to verify if C linked libraries can be used with hotspot. it must be verified by JCK which should be compiled/linked with carefully chosen compilers/linkers and their flags. It has been discussed (not widely enough and I accept that) in 8209547 and the related email thread b/w JC(cc'ed) and myself. as I said, I might went a way too far, so I'll revert changes in the non-vmTestbase tests and made appropriate changes in makefiles. what do you think? Thanks, ? Igor On Aug 20, 2018, at 6:43 PM, David Holmes > wrote: > Hi Igor, > > On 21/08/2018 8:59 AM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8209611/webrev.01/index.html >>> 11160 lines changed: 879 ins; 61 del; 10220 mod; >> Hi all, >> could you please review the patch which moves all hotspot native test code to C++? this will guarantee that we always use C++ compilers for them (as an opposite to either C or C++ compiler depending on configuration), as a result we will be able to get rid of JNI_ENV_ARG[1] macros, perform other clean ups and improve overall quality of the test code. > > Sorry but I don't see why this is necessary. If people want to be able to write C++ tests then we should enable that if not currently enabled, but I don't see why everything should be forced to C++. What if we did something that broke the C linkage and we didn't detect it because we only ever tested C++? > > Was the motivation previously discussed somewhere? > > Thanks, > David > >> the patch consists of two parts: >> - automatic: renaming .c files to .cpp, updating #include, changing JNI/JVMTI calls >> - semi-manual: adding extern "C" , fixing a number of compiler warnings (mostly types inconsistency), updating makefiles >> JBS: https://bugs.openjdk.java.net/browse/JDK-8209611 >> webrevs: >> - automatic: http://cr.openjdk.java.net/~iignatyev//8209611/webrev.00/index.html >>> 9394 lines changed: 0 ins; 0 del; 9394 mod; >> - semi-manual: http://cr.openjdk.java.net/~iignatyev//8209611/webrev.0-1/index.html >>> 1899 lines changed: 879 ins; 61 del; 959 mod >> - whole: http://cr.openjdk.java.net/~iignatyev//8209611/webrev.01/index.html >>> 11160 lines changed: 879 ins; 61 del; 10220 mod; >> testing: all hotspot tests + tier[1-3] >> [1] https://bugs.openjdk.java.net/browse/JDK-8209547 >> Thanks, >> -- Igor From david.holmes at oracle.com Tue Aug 21 05:02:45 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 Aug 2018 15:02:45 +1000 Subject: [test] RFR 8209771: jdk.test.lib.Utils::runAndCheckException error In-Reply-To: <1C55A939-D937-4BC3-8AEB-F8C3F54FD4D8@oracle.com> References: <1C55A939-D937-4BC3-8AEB-F8C3F54FD4D8@oracle.com> Message-ID: <89f7acc5-5731-526d-6fd4-bcaa0da3ffaa@oracle.com> Hi Max, On 21/08/2018 12:53 PM, Weijun Wang wrote: > Please take a review at > > https://bugs.openjdk.java.net/browse/JDK-8209771 > http://cr.openjdk.java.net/~weijun/8209771/webrev.00/ > > There is an error in the implementation of the method, and I also think ThrowingRunnable is more developer friendly here. ThrowingRunnable is really only needed for a Runnable that might throw checked exceptions. It really doesn't make any difference here. The actual logic fix seems okay. You could initialize throwable to null and avoid the assignment in the try block. > The methods are only used in hotspot so I'm asking for the code review here. Mostly by the JVMCI compiler folk too. I didn't even know these utilities existed. I've written tons of test code that checks for expected and unexpected exceptions. :) > I also think in filterException(), filter.apply(null) should be called if test.run() has not thrown any exception, but this is a behavior change and I cannot be sure. That would be a different function I think. filterException seems to me just to be a generalized catch clause to detect if a specific kind of exception occurred - not to check that some specific exception should have occurred. Thanks, David > Please include my name in the recipient list as I'm not in the mail list. > > This will be a noreg-self. > > Thanks > Max > > > From david.holmes at oracle.com Tue Aug 21 05:06:54 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 Aug 2018 15:06:54 +1000 Subject: RFR(M/L) : 8209611 : use C++ compiler for hotspot tests In-Reply-To: References: <92CD42CC-568A-4972-A35E-469B1532B103@oracle.com> <9f172999-2e45-8ebd-dba6-5d2d8927309b@oracle.com> Message-ID: <7d0ea30f-19c7-8a43-0616-fffb56bc5840@oracle.com> Hi Igor, On 21/08/2018 1:58 PM, Igor Ignatev wrote: > Hi David, > > It is necessary for vmTestbase tests (if we of course want to clean them > up) as they are coupled, and moving only part of them will require (non > trivial) updates in the rest of code (or at least in the shared part) to > properly serve both compilers. Can you elaborate on the problem please as I don't see why the vmTestbase tests are special here. I would expect a .c file to be compiled as C and a .cpp to be compiled as C++. > It absolutely not necessary for other > tests, but I?d prefer to have some level of unification in the test > base. That being said, I agree I might went too far and moved all the > tests which might or might not compromise their purpose. I personally > don?t think we should relay on our jtreg testbase to verify if C linked > libraries can be used with hotspot. it must be verified by JCK which > should be compiled/linked with carefully chosen compilers/linkers and > their flags. Sure but JCK comes into play much later and I'd rather spot issues during developer testing than promotion testing. > It has been discussed (not widely enough and I accept that) in 8209547 > and the related email thread b/w JC(cc'ed) and myself. > > as I said, I might went a way too far, so I'll revert changes in the > non-vmTestbase tests and made appropriate changes in makefiles. what do > you think? I think I need to see what you mean exactly :) Thanks, David > Thanks, > ? Igor > > On Aug 20, 2018, at 6:43 PM, David Holmes > wrote: > >> Hi Igor, >> >> On 21/08/2018 8:59 AM, Igor Ignatyev wrote: >>> http://cr.openjdk.java.net/~iignatyev//8209611/webrev.01/index.html >>> >>>> 11160 lines changed: 879 ins; 61 del; 10220 mod; >>> Hi all, >>> could you please review the patch which moves all hotspot native test >>> code to C++? this will guarantee that we always use C++ compilers for >>> them (as an opposite to either C or C++ compiler depending on >>> configuration), as a result we will be able to get rid of >>> JNI_ENV_ARG[1] macros, perform other clean ups and improve overall >>> quality of the test code. >> >> Sorry but I don't see why this is necessary. If people want to be able >> to write C++ tests then we should enable that if not currently >> enabled, but I don't see why everything should be forced to C++. What >> if we did something that broke the C linkage and we didn't detect it >> because we only ever tested C++? >> >> Was the motivation previously discussed somewhere? >> >> Thanks, >> David >> >>> the patch consists of two parts: >>> ?- automatic: renaming .c files to .cpp, updating #include, changing >>> JNI/JVMTI calls >>> ?- semi-manual: adding extern "C" , fixing a number of compiler >>> warnings (mostly types inconsistency), updating makefiles >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8209611 >>> webrevs: >>> ?- automatic: >>> http://cr.openjdk.java.net/~iignatyev//8209611/webrev.00/index.html >>> >>>> 9394 lines changed: 0 ins; 0 del; 9394 mod; >>> ?- semi-manual: >>> http://cr.openjdk.java.net/~iignatyev//8209611/webrev.0-1/index.html >>> >>>> 1899 lines changed: 879 ins; 61 del; 959 mod >>> ?- whole: >>> http://cr.openjdk.java.net/~iignatyev//8209611/webrev.01/index.html >>> >>>> 11160 lines changed: 879 ins; 61 del; 10220 mod; >>> testing: all hotspot tests + tier[1-3] >>> [1] https://bugs.openjdk.java.net/browse/JDK-8209547 >>> Thanks, >>> -- Igor From igor.ignatyev at oracle.com Tue Aug 21 06:07:25 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 20 Aug 2018 23:07:25 -0700 Subject: RFR(M/L) : 8209611 : use C++ compiler for hotspot tests In-Reply-To: <7d0ea30f-19c7-8a43-0616-fffb56bc5840@oracle.com> References: <92CD42CC-568A-4972-A35E-469B1532B103@oracle.com> <9f172999-2e45-8ebd-dba6-5d2d8927309b@oracle.com> <7d0ea30f-19c7-8a43-0616-fffb56bc5840@oracle.com> Message-ID: <29AD64D9-A86E-4105-8D07-F8EEC6B2B56E@oracle.com> > On Aug 20, 2018, at 10:06 PM, David Holmes wrote: > > Hi Igor, > > On 21/08/2018 1:58 PM, Igor Ignatev wrote: >> Hi David, >> It is necessary for vmTestbase tests (if we of course want to clean them up) as they are coupled, and moving only part of them will require (non trivial) updates in the rest of code (or at least in the shared part) to properly serve both compilers. > > Can you elaborate on the problem please as I don't see why the vmTestbase tests are special here. > > I would expect a .c file to be compiled as C and a .cpp to be compiled as C++. currently our build system supports only 1-1 relation b/w tests lib/exec and source file; most of native libraries in vmTestbase have more than one source file. to work that around, we introduced a .c file for each library and theses .c files include all other required .c files. yes, a .c file will be compiled as C and a .cpp file as C++, but as we have .c files which include .c files, moving only part of .c files, we will end up w/ .c files being included into both .c and .cpp files and thus compiled as both C and C++. let's take test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS301/hs301t004, if we want its native part to be compiled as C++, we rename libhs301t004.c to libhs301t004.cpp, but libhs301t004.c includes 11 other files, there only one is a test specific fill and all the other are used by other tests and included by their .c files. so we have 10 files which now will be compiled by both C and C++ compilers. > >> It absolutely not necessary for other tests, but I?d prefer to have some level of unification in the test base. That being said, I agree I might went too far and moved all the tests which might or might not compromise their purpose. I personally don?t think we should relay on our jtreg testbase to verify if C linked libraries can be used with hotspot. it must be verified by JCK which should be compiled/linked with carefully chosen compilers/linkers and their flags. > > Sure but JCK comes into play much later and I'd rather spot issues during developer testing than promotion testing. agree, but if we want to verify how C/C++ linked libraries work w/ hotspot, it should be done by the tests specifically written for that purpose rather that relaying on indirect coverage from other tests, and I guess it hasn't been done as we always relied on JCK to test that. > >> It has been discussed (not widely enough and I accept that) in 8209547 and the related email thread b/w JC(cc'ed) and myself. >> as I said, I might went a way too far, so I'll revert changes in the non-vmTestbase tests and made appropriate changes in makefiles. what do you think? > > I think I need to see what you mean exactly :) sure, it will take some time for me to do that, hopefully will upload new webrevs tomorrow morning PT. but the basic idea is to leave files in test/hotspot/jtreg/compiler, runtime, gc, native_sanity, serviceability, testlibrary as .c files, exactly as they were before, and restore corresponding filenames in make/test/JtregNativeHotspot.gmk. Cheers, -- Igor > > Thanks, > David > >> Thanks, >> ? Igor >> On Aug 20, 2018, at 6:43 PM, David Holmes > wrote: >>> Hi Igor, >>> >>> On 21/08/2018 8:59 AM, Igor Ignatyev wrote: >>>> http://cr.openjdk.java.net/~iignatyev//8209611/webrev.01/index.html >>>>> 11160 lines changed: 879 ins; 61 del; 10220 mod; >>>> Hi all, >>>> could you please review the patch which moves all hotspot native test code to C++? this will guarantee that we always use C++ compilers for them (as an opposite to either C or C++ compiler depending on configuration), as a result we will be able to get rid of JNI_ENV_ARG[1] macros, perform other clean ups and improve overall quality of the test code. >>> >>> Sorry but I don't see why this is necessary. If people want to be able to write C++ tests then we should enable that if not currently enabled, but I don't see why everything should be forced to C++. What if we did something that broke the C linkage and we didn't detect it because we only ever tested C++? >>> >>> Was the motivation previously discussed somewhere? >>> >>> Thanks, >>> David >>> >>>> the patch consists of two parts: >>>> - automatic: renaming .c files to .cpp, updating #include, changing JNI/JVMTI calls >>>> - semi-manual: adding extern "C" , fixing a number of compiler warnings (mostly types inconsistency), updating makefiles >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8209611 >>>> webrevs: >>>> - automatic: http://cr.openjdk.java.net/~iignatyev//8209611/webrev.00/index.html >>>>> 9394 lines changed: 0 ins; 0 del; 9394 mod; >>>> - semi-manual: http://cr.openjdk.java.net/~iignatyev//8209611/webrev.0-1/index.html >>>>> 1899 lines changed: 879 ins; 61 del; 959 mod >>>> - whole: http://cr.openjdk.java.net/~iignatyev//8209611/webrev.01/index.html >>>>> 11160 lines changed: 879 ins; 61 del; 10220 mod; >>>> testing: all hotspot tests + tier[1-3] >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8209547 >>>> Thanks, >>>> -- Igor From mikael.vidstedt at oracle.com Tue Aug 21 06:29:17 2018 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Mon, 20 Aug 2018 23:29:17 -0700 Subject: Linux + Clang + execstack In-Reply-To: References: <26c39a87-9db0-d62a-e026-e4075e3237fb@oracle.com> Message-ID: <1DC3B041-5D9B-4C46-B83F-25AA0B7DE0A7@oracle.com> > On Aug 20, 2018, at 5:03 PM, David Holmes wrote: > > On 21/08/2018 9:39 AM, Arthur Eubanks wrote: >> On Mon, Aug 20, 2018 at 4:18 PM David Holmes > wrote: >> Hi Arthur, >> cc'ing build-dev as this is currently a build issue. >> On 21/08/2018 3:11 AM, Arthur Eubanks wrote: >> > Hi, >> > >> > At Google we're trying to build hotspot on Linux with clang. One >> thing that >> > happens is that the resulting libjvm.so is stack executable. When >> running >> > hotspot we get warnings about the stack being executable. >> > >> > Compiling an assembly file into the final .so results in the >> stack being >> > executable. In this case the file is linux_x86_64.s. This doesn't >> happen >> > with gcc because "-Wl,-z,noexecstack" is passed as a hotspot >> linker flag >> > with gcc in flags-ldflags.m4. When using clang that linker flag isn't >> > passed. >> > >> > Doing something like the solution in >> > https://wiki.ubuntu.com/SecurityTeam/Roadmap/ExecutableStacks >> > fixes the problem without the use of linker flags. >> You mean the source code directives for the linker? >> Sorry, I wasn't specific enough, I meant the flags for the assembler. >> #if defined(__linux__) && defined(__ELF__) >> .section .note.GNU-stack, "", %progbits >> #endif >> I think I prefer to see this handled explicitly in the build as is >> currently done. Can we just adjust ./make/autoconf/flags-ldflags.m4 to >> pass the linker flags for gcc and clang? >> I don't mind this solution, but it seems like the right thing to do is to fix things at the source level and remove extra unnecessary linker flags. > > Personally I see this as source code pollution. The concept of executable stacks has nothing to do with what is being expressed by the source code, or the language used for it. > > Just my 2c. I'll defer to build folk ... though they are still on vacation at the moment. Control question: why doesn?t the compiled .cpp files provoke the executable stack problem? After all, they?re also an assembly file somewhere on the way from .cpp to object file. I?m guessing it?s because gcc does insert the .note.GNU-stack directive. If so, it seems reasonable to me to require/expect our assembly files to include that directive as well? Cheers, Mikael > >> I removed "-Wl,-z,noexecstack" from the flags after adding the above assembler flags and libjvm.so is still correctly not stack executable. I don't really mind either way though. Maybe it's good to have an extra safeguard in the linker flags. >> > The jtreg test test/hotspot/jtreg/runtime/execstack/TestCheckJDK.java >> > checks for the stack being executable. >> > >> > Any thoughts? If there are no objections, I can propose a patch >> that works >> > for both gcc and clang on Linux. Also, I'm not sure how/if macOS >> handles >> > this problem given that it uses clang. >> We don't seem to handle it at all on OS X. Does OS X prevent executable >> stacks itself? >> A quick search, according to Wikipedia (https://en.wikipedia.org/wiki/Executable_space_protection#macOS ), 64-bit executables on macOS aren't stack or heap executable. Not sure if that information is accurate though. > > Seems to be: > > https://developer.apple.com/library/archive/documentation/Security/Conceptual/SecureCodingGuide/Articles/BufferOverflows.html > > "macOS and iOS provide two features that can make it harder to exploit stack and buffer overflows: address space layout randomization (ASLR) and a non-executable stack and heap." > > Cheers, > David > >> David From weijun.wang at oracle.com Tue Aug 21 06:33:22 2018 From: weijun.wang at oracle.com (Weijun Wang) Date: Tue, 21 Aug 2018 14:33:22 +0800 Subject: [test] RFR 8209771: jdk.test.lib.Utils::runAndCheckException error In-Reply-To: <89f7acc5-5731-526d-6fd4-bcaa0da3ffaa@oracle.com> References: <1C55A939-D937-4BC3-8AEB-F8C3F54FD4D8@oracle.com> <89f7acc5-5731-526d-6fd4-bcaa0da3ffaa@oracle.com> Message-ID: <9FA9117F-5E9A-495B-A4A7-A79AD837C1A7@oracle.com> Hi David > On Aug 21, 2018, at 1:02 PM, David Holmes wrote: > > Hi Max, > > On 21/08/2018 12:53 PM, Weijun Wang wrote: >> Please take a review at >> https://bugs.openjdk.java.net/browse/JDK-8209771 >> http://cr.openjdk.java.net/~weijun/8209771/webrev.00/ >> There is an error in the implementation of the method, and I also think ThrowingRunnable is more developer friendly here. > > ThrowingRunnable is really only needed for a Runnable that might throw checked exceptions. It really doesn't make any difference here. By using ThrowingRunnable I can put a one-line lambda expression that might throw a checked exception, otherwise I'll have to wrap it into a RuntimeException. That's what I meant developer-friendly. > > The actual logic fix seems okay. You could initialize throwable to null and avoid the assignment in the try block. Sure. > >> The methods are only used in hotspot so I'm asking for the code review here. > > Mostly by the JVMCI compiler folk too. In fact, mostly by tests in hotspot/jtreg/compiler/jvmci. I thought it's a part of hotspot. Anyway, I've added hotspot-compiler-dev at . > I didn't even know these utilities existed. I've written tons of test code that checks for expected and unexpected exceptions. :) Me too. This morning I had a little free time to wander around jdk.test.lib and notice these. > >> I also think in filterException(), filter.apply(null) should be called if test.run() has not thrown any exception, but this is a behavior change and I cannot be sure. > > That would be a different function I think. filterException seems to me just to be a generalized catch clause to detect if a specific kind of exception occurred - not to check that some specific exception should have occurred. Maybe. I won't touch it. Thanks Max > > Thanks, > David > >> Please include my name in the recipient list as I'm not in the mail list. >> This will be a noreg-self. >> Thanks >> Max >> From david.holmes at oracle.com Tue Aug 21 06:35:50 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 Aug 2018 16:35:50 +1000 Subject: Linux + Clang + execstack In-Reply-To: <1DC3B041-5D9B-4C46-B83F-25AA0B7DE0A7@oracle.com> References: <26c39a87-9db0-d62a-e026-e4075e3237fb@oracle.com> <1DC3B041-5D9B-4C46-B83F-25AA0B7DE0A7@oracle.com> Message-ID: <069887da-9901-74ec-5b23-8e45543af061@oracle.com> On 21/08/2018 4:29 PM, Mikael Vidstedt wrote: >> On Aug 20, 2018, at 5:03 PM, David Holmes > > wrote: >> >> On 21/08/2018 9:39 AM, Arthur Eubanks wrote: >>> On Mon, Aug 20, 2018 at 4:18 PM David Holmes >> > wrote: >>> ???Hi Arthur, >>> ???cc'ing build-dev as this is currently a build issue. >>> ???On 21/08/2018 3:11 AM, Arthur Eubanks wrote: >>> ????> Hi, >>> ????> >>> ????> At Google we're trying to build hotspot on Linux with clang. One >>> ???thing that >>> ????> happens is that the resulting libjvm.so is stack executable. When >>> ???running >>> ????> hotspot we get warnings about the stack being executable. >>> ????> >>> ????> Compiling an assembly file into the final .so results in the >>> ???stack being >>> ????> executable. In this case the file is linux_x86_64.s. This doesn't >>> ???happen >>> ????> with gcc because "-Wl,-z,noexecstack" is passed as a hotspot >>> ???linker flag >>> ????> with gcc in flags-ldflags.m4. When using clang that linker flag >>> isn't >>> ????> passed. >>> ????> >>> ????> Doing something like the solution in >>> ????> https://wiki.ubuntu.com/SecurityTeam/Roadmap/ExecutableStacks >>> ????> fixes the problem without the use of linker flags. >>> ???You mean the source code directives for the linker? >>> Sorry, I wasn't specific enough, I meant the flags for the assembler. >>> #if defined(__linux__) && defined(__ELF__) >>> .section? ? ? ? .note.GNU-stack, "", %progbits >>> #endif >>> ???I think I prefer to see this handled explicitly in the build as is >>> ???currently done. Can we just adjust ./make/autoconf/flags-ldflags.m4 to >>> ???pass the linker flags for gcc and clang? >>> I don't mind this solution, but it seems like the right thing to do >>> is to fix things at the source level and remove extra unnecessary >>> linker flags. >> >> Personally I see this as source code pollution. The concept of >> executable stacks has nothing to do with what is being expressed by >> the source code, or the language used for it. >> >> Just my 2c. I'll defer to build folk ... though they are still on >> vacation at the moment. > > Control question: why doesn?t the compiled .cpp files provoke the > executable stack problem? After all, they?re also an assembly file > somewhere on the way from .cpp to object file. Either gcc does something or else ld does something based on the noexecstack build flags we use. > I?m guessing it?s because gcc does insert the .note.GNU-stack directive. > If so, it seems reasonable to me to require/expect our assembly files to > include that directive as well? If gcc inserts something in a .o from a .cpp file then I would expect the assembler (gas? or still gcc?) to insert something in a .o from a .s file. David > Cheers, > Mikael > >> >>> I removed?"-Wl,-z,noexecstack" from the flags after adding the above >>> assembler flags and libjvm.so is still correctly not stack >>> executable. I don't really mind either way though. Maybe it's good to >>> have an extra safeguard in the linker flags. >>> ????> The jtreg test >>> test/hotspot/jtreg/runtime/execstack/TestCheckJDK.java >>> ????> checks for the stack being executable. >>> ????> >>> ????> Any thoughts? If there are no objections, I can propose a patch >>> ???that works >>> ????> for both gcc and clang on Linux. Also, I'm not sure how/if macOS >>> ???handles >>> ????> this problem given that it uses clang. >>> ???We don't seem to handle it at all on OS X. Does OS X prevent >>> executable >>> ???stacks itself? >>> A quick search, according to Wikipedia >>> (https://en.wikipedia.org/wiki/Executable_space_protection#macOS), >>> 64-bit executables on macOS aren't stack or heap executable. Not sure >>> if that information is accurate though. >> >> Seems to be: >> >> https://developer.apple.com/library/archive/documentation/Security/Conceptual/SecureCodingGuide/Articles/BufferOverflows.html >> >> "macOS and iOS provide two features that can make it harder to exploit >> stack and buffer overflows: address space layout randomization (ASLR) >> and a non-executable stack and heap." >> >> Cheers, >> David >> >>> ???David > From david.holmes at oracle.com Tue Aug 21 06:39:04 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 Aug 2018 16:39:04 +1000 Subject: RFR(M/L) : 8209611 : use C++ compiler for hotspot tests In-Reply-To: <29AD64D9-A86E-4105-8D07-F8EEC6B2B56E@oracle.com> References: <92CD42CC-568A-4972-A35E-469B1532B103@oracle.com> <9f172999-2e45-8ebd-dba6-5d2d8927309b@oracle.com> <7d0ea30f-19c7-8a43-0616-fffb56bc5840@oracle.com> <29AD64D9-A86E-4105-8D07-F8EEC6B2B56E@oracle.com> Message-ID: <5a1ce9b3-4e06-ce5b-6d1d-08d4d92eceef@oracle.com> On 21/08/2018 4:07 PM, Igor Ignatyev wrote: >> On Aug 20, 2018, at 10:06 PM, David Holmes wrote: >> >> Hi Igor, >> >> On 21/08/2018 1:58 PM, Igor Ignatev wrote: >>> Hi David, >>> It is necessary for vmTestbase tests (if we of course want to clean them up) as they are coupled, and moving only part of them will require (non trivial) updates in the rest of code (or at least in the shared part) to properly serve both compilers. >> >> Can you elaborate on the problem please as I don't see why the vmTestbase tests are special here. >> >> I would expect a .c file to be compiled as C and a .cpp to be compiled as C++. > > currently our build system supports only 1-1 relation b/w tests lib/exec and source file; most of native libraries in vmTestbase have more than one source file. to work that around, we introduced a .c file for each library and theses .c files include all other required .c files. > > yes, a .c file will be compiled as C and a .cpp file as C++, but as we have .c files which include .c files, moving only part of .c files, we will end up w/ .c files being included into both .c and .cpp files and thus compiled as both C and C++. let's take test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS301/hs301t004, if we want its native part to be compiled as C++, we rename libhs301t004.c to libhs301t004.cpp, but libhs301t004.c includes 11 other files, there only one is a test specific fill and all the other are used by other tests and included by their .c files. so we have 10 files which now will be compiled by both C and C++ compilers. Okay, but why do we need to change any of these existing tests to be compiled as C++? David ------ >> >>> It absolutely not necessary for other tests, but I?d prefer to have some level of unification in the test base. That being said, I agree I might went too far and moved all the tests which might or might not compromise their purpose. I personally don?t think we should relay on our jtreg testbase to verify if C linked libraries can be used with hotspot. it must be verified by JCK which should be compiled/linked with carefully chosen compilers/linkers and their flags. >> >> Sure but JCK comes into play much later and I'd rather spot issues during developer testing than promotion testing. > > agree, but if we want to verify how C/C++ linked libraries work w/ hotspot, it should be done by the tests specifically written for that purpose rather that relaying on indirect coverage from other tests, and I guess it hasn't been done as we always relied on JCK to test that. > >> >>> It has been discussed (not widely enough and I accept that) in 8209547 and the related email thread b/w JC(cc'ed) and myself. >>> as I said, I might went a way too far, so I'll revert changes in the non-vmTestbase tests and made appropriate changes in makefiles. what do you think? >> >> I think I need to see what you mean exactly :) > sure, it will take some time for me to do that, hopefully will upload new webrevs tomorrow morning PT. but the basic idea is to leave files in test/hotspot/jtreg/compiler, runtime, gc, native_sanity, serviceability, testlibrary as .c files, exactly as they were before, and restore corresponding filenames in make/test/JtregNativeHotspot.gmk. > > Cheers, > -- Igor > >> >> Thanks, >> David >> >>> Thanks, >>> ? Igor >>> On Aug 20, 2018, at 6:43 PM, David Holmes > wrote: >>>> Hi Igor, >>>> >>>> On 21/08/2018 8:59 AM, Igor Ignatyev wrote: >>>>> http://cr.openjdk.java.net/~iignatyev//8209611/webrev.01/index.html >>>>>> 11160 lines changed: 879 ins; 61 del; 10220 mod; >>>>> Hi all, >>>>> could you please review the patch which moves all hotspot native test code to C++? this will guarantee that we always use C++ compilers for them (as an opposite to either C or C++ compiler depending on configuration), as a result we will be able to get rid of JNI_ENV_ARG[1] macros, perform other clean ups and improve overall quality of the test code. >>>> >>>> Sorry but I don't see why this is necessary. If people want to be able to write C++ tests then we should enable that if not currently enabled, but I don't see why everything should be forced to C++. What if we did something that broke the C linkage and we didn't detect it because we only ever tested C++? >>>> >>>> Was the motivation previously discussed somewhere? >>>> >>>> Thanks, >>>> David >>>> >>>>> the patch consists of two parts: >>>>> - automatic: renaming .c files to .cpp, updating #include, changing JNI/JVMTI calls >>>>> - semi-manual: adding extern "C" , fixing a number of compiler warnings (mostly types inconsistency), updating makefiles >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8209611 >>>>> webrevs: >>>>> - automatic: http://cr.openjdk.java.net/~iignatyev//8209611/webrev.00/index.html >>>>>> 9394 lines changed: 0 ins; 0 del; 9394 mod; >>>>> - semi-manual: http://cr.openjdk.java.net/~iignatyev//8209611/webrev.0-1/index.html >>>>>> 1899 lines changed: 879 ins; 61 del; 959 mod >>>>> - whole: http://cr.openjdk.java.net/~iignatyev//8209611/webrev.01/index.html >>>>>> 11160 lines changed: 879 ins; 61 del; 10220 mod; >>>>> testing: all hotspot tests + tier[1-3] >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8209547 >>>>> Thanks, >>>>> -- Igor > From igor.ignatyev at oracle.com Tue Aug 21 06:42:49 2018 From: igor.ignatyev at oracle.com (Igor Ignatev) Date: Mon, 20 Aug 2018 23:42:49 -0700 Subject: RFR(M/L) : 8209611 : use C++ compiler for hotspot tests In-Reply-To: <5a1ce9b3-4e06-ce5b-6d1d-08d4d92eceef@oracle.com> References: <92CD42CC-568A-4972-A35E-469B1532B103@oracle.com> <9f172999-2e45-8ebd-dba6-5d2d8927309b@oracle.com> <7d0ea30f-19c7-8a43-0616-fffb56bc5840@oracle.com> <29AD64D9-A86E-4105-8D07-F8EEC6B2B56E@oracle.com> <5a1ce9b3-4e06-ce5b-6d1d-08d4d92eceef@oracle.com> Message-ID: <8BDC5215-1C10-4FC2-A1CB-D6F5B15B6230@oracle.com> Because we would like to clean them up, which includes , but not limited to, removing JNI_ENV* and the like macros, other instances of ifndef __cplusplus. ? Igor > On Aug 20, 2018, at 11:39 PM, David Holmes wrote: > > Okay, but why do we need to change any of these existing tests to be compiled as C++? From volker.simonis at gmail.com Tue Aug 21 07:30:08 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 21 Aug 2018 09:30:08 +0200 Subject: [11] RFR(S): 8209637: [s390x] Interpreter doesn't call result handler after native calls In-Reply-To: <865fdfe5-8a5a-41e5-0f32-07b79636e61e@oracle.com> References: <06592a59-7d99-254f-632d-225a51c36b5f@oracle.com> <5ffada18fdcd4905816fbed29a6bb5dc@sap.com> <865fdfe5-8a5a-41e5-0f32-07b79636e61e@oracle.com> Message-ID: Hi Vladimir, thanks a lot for the quick testing and approval. Internal tests look good as well so I've just pushed to jdk11. Best regards, Volker On Tue, Aug 21, 2018 at 12:01 AM, Vladimir Kozlov wrote: > Testing passed and I approved it. > > Please, push fix into jdk11 ASAP - we have one day left. > > Thanks, > Vladimir > > > On 8/20/18 9:08 AM, Volker Simonis wrote: >> >> On Mon, Aug 20, 2018 at 4:24 PM, Lindenmaier, Goetz >> wrote: >>> >>> Hi Volker, >>> >>> the fix looks good to me, but please use mem2reg_opt instead of >>> load_and_test_long. >>> The test result is not used. >>> >> >> Good catch! I've updated the patch and placed it into our nightly >> build and test queue. If the results are still OK (what I expect) and >> Vladimir gives us his OK, I'll push it tomorrow. >> >> For reference (and Vladimir :), I've also created a new webrev: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2018/8209637.v1/ >> >>> Maybe you can fix comment in line 1684: "Bandle exception" --> "Handle >>> exception". >>> >> >> Done. >> >>> Don't need a new webrev. >>> >>> Thanks and best regards, >>> Goetz. >>> >>> >>>> -----Original Message----- >>>> From: hotspot-dev On Behalf Of >>>> Vladimir Kozlov >>>> Sent: Freitag, 17. August 2018 22:33 >>>> To: Volker Simonis ; HotSpot Open Source >>>> Developers >>>> Subject: Re: [11] RFR(S): 8209637: [s390x] Interpreter doesn't call >>>> result >>>> handler after native calls >>>> >>>> Hi Volker, >>>> >>>> Someone who is familiar with this s390 code should review it before we >>>> can >>>> judge if it acceptable fro JDK 11. >>>> >>>> Regards, >>>> Vladimir >>>> >>>> On 8/17/18 7:03 AM, Volker Simonis wrote: >>>>> >>>>> Hi, >>>>> >>>>> can I please have a review for this small, s390x only bug fix which >>>>> I'd like to bring to jdk11: >>>>> >>>>> http://cr.openjdk.java.net/~simonis/webrevs/2018/8209637/ >>>>> https://bugs.openjdk.java.net/browse/JDK-8209637 >>>>> >>>>> The problem is that the template interpreter for s390x doesn't call >>>>> the result handler in the native entry. This can lead to wrong results >>>>> being passed as return values from native calls which return a >>>>> jboolean if the value is not exactly '1' or '0' (i.e. a return value >>>>> of '2' will be interpreted as 'false'). The result handler usually >>>>> normalizes such results and maps any value > 0 to 'true'. >>>>> >>>>> I'd like to bring this to jdk11 because the bug can lead to incorrect >>>>> results for calls to JNI functions with jboolean results. This can >>>>> affect not only user coding but also core library functions like >>>>> java.io.Console.echo() (which is called from Console.readPassword()). >>>>> The malfunction of these methods triggered the discovery of this bug. >>>>> >>>>> The fix is low risk and only affects the s390x port (except the >>>>> regression test - but that shouldn't be harmful either). >>>>> >>>>> Thank you and best regards, >>>>> Volker >>>>> > From thomas.schatzl at oracle.com Tue Aug 21 09:31:42 2018 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 21 Aug 2018 11:31:42 +0200 Subject: RFR (XS) 8209738: Remove ClassLoaderDataGraph::*oops_do functions In-Reply-To: References: Message-ID: <15e07d2d684187adcb2ca3128dece665f54399ca.camel@oracle.com> Hi, On Mon, 2018-08-20 at 13:29 -0400, coleen.phillimore at oracle.com wrote: > Summary: Make walking CLDG more consistent. > > Affects ParallelGC and jvmtiTagMap. > > open webrev at http://cr.openjdk.java.net/~coleenp/8209738.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8209738 > > Tested with mach5 tier1-7 and with runThese with all GCs. looks good. Thomas From nils.eliasson at oracle.com Tue Aug 21 09:46:31 2018 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Tue, 21 Aug 2018 11:46:31 +0200 Subject: RFR: 8208601: Introduce native oop barriers in C2 for OopHandle In-Reply-To: <5B6196CA.7080201@oracle.com> References: <5B6196CA.7080201@oracle.com> Message-ID: <2fd76c3a-2363-f7fe-d4a4-5b7dcbb6a2e8@oracle.com> Looks good. // Nils On 2018-08-01 13:17, Erik ?sterlund wrote: > Hi, > > There is currently no way of doing IN_NATIVE accesses in C2 using its > access API. These are required to properly access OopHandle, used to > access the Java class mirrors (because they will now start requiring > load barriers). In order to support (concurrent) class unloading in > ZGC, this support must be added. > > In this patch, I add an access_load API for loading IN_NATIVE oops, > and use it to load class mirrors (which is logically an > OopHandle::resolve, which happened to have been an indirect load > before as nobody had load barriers on it). In the various code > recognizing the shape of a mirror load to optimize the code, I have > added a check if a node is a GC barrier and to then step over it in > order to match the mirror load. > > In order to recognize and step over the load barriers in ZGC properly, > I added support for recognizing the barrier shapes not just before > macro expansion (LoadBarrierNode), but also after macro expansion (as > required by the matching code), which involves checking for phi nodes > with with LoadBarrierSlowRegNode phi->in(1), and then stepping over to > phi->in(2), as well as recognizing projections to such shapes. > LoadBarrierSlowRegNode is used in all barrier expansions except for > atomic xchg, but that is fine as we don't use that on class mirrors. > > I have checked that the shapes are recognized and that no regressions > are introduced with these changes through a bunch of benchmarks in > gc-test-suite. > > Webrev: > http://cr.openjdk.java.net/~eosterlund/8208601/webrev.00/ > > Bug URL: > https://bugs.openjdk.java.net/browse/JDK-8208601 > > > Thanks, > /Erik > Open Tracking From magnus.ihse.bursie at oracle.com Tue Aug 21 11:14:23 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 21 Aug 2018 13:14:23 +0200 Subject: Linux + Clang + execstack In-Reply-To: References: <26c39a87-9db0-d62a-e026-e4075e3237fb@oracle.com> Message-ID: <4f753eb3-dc20-c69e-dbb8-752b74f2aa55@oracle.com> On 2018-08-21 02:03, David Holmes wrote: > On 21/08/2018 9:39 AM, Arthur Eubanks wrote: >> On Mon, Aug 20, 2018 at 4:18 PM David Holmes > > wrote: >> >> ??? Hi Arthur, >> >> ??? cc'ing build-dev as this is currently a build issue. >> >> ??? On 21/08/2018 3:11 AM, Arthur Eubanks wrote: >> ???? > Hi, >> ???? > >> ???? > At Google we're trying to build hotspot on Linux with clang. One >> ??? thing that >> ???? > happens is that the resulting libjvm.so is stack executable. When >> ??? running >> ???? > hotspot we get warnings about the stack being executable. >> ???? > >> ???? > Compiling an assembly file into the final .so results in the >> ??? stack being >> ???? > executable. In this case the file is linux_x86_64.s. This doesn't >> ??? happen >> ???? > with gcc because "-Wl,-z,noexecstack" is passed as a hotspot >> ??? linker flag >> ???? > with gcc in flags-ldflags.m4. When using clang that linker >> flag isn't >> ???? > passed. >> ???? > >> ???? > Doing something like the solution in >> ???? > https://wiki.ubuntu.com/SecurityTeam/Roadmap/ExecutableStacks >> ???? > fixes the problem without the use of linker flags. >> >> ??? You mean the source code directives for the linker? >> >> Sorry, I wasn't specific enough, I meant the flags for the assembler. >> #if defined(__linux__) && defined(__ELF__) >> .section? ? ? ? .note.GNU-stack, "", %progbits >> #endif >> >> >> ??? I think I prefer to see this handled explicitly in the build as is >> ??? currently done. Can we just adjust >> ./make/autoconf/flags-ldflags.m4 to >> ??? pass the linker flags for gcc and clang? >> >> I don't mind this solution, but it seems like the right thing to do >> is to fix things at the source level and remove extra unnecessary >> linker flags. > > Personally I see this as source code pollution. The concept of > executable stacks has nothing to do with what is being expressed by > the source code, or the language used for it. > > Just my 2c. I'll defer to build folk ... though they are still on > vacation at the moment. I agree with David. The executable stack is a build option. Even if you change the source code so the compiler/assember does the right thing, we would still want to keep the compiler option. (Otherwise one day you'll end up with executable stacks due to someone adding a new asm file and forgetting the "magic incantation".) And, since we will keep the compiler option, there seems little point in also adding this stuff to the asm files. To address your concerns on clang: we should reasonably be giving the same options to clang. There is no good reason, except for oversight, that this is not done already. (Cleaning up and unifying the compiler flags is an ongoing, but slowly moving, process.) So the correct fix is to update flags-ldflags.m4. /Magnus > >> I removed?"-Wl,-z,noexecstack" from the flags after adding the above >> assembler flags and libjvm.so is still correctly not stack >> executable. I don't really mind either way though. Maybe it's good to >> have an extra safeguard in the linker flags. >> >> >> ???? > The jtreg test >> test/hotspot/jtreg/runtime/execstack/TestCheckJDK.java >> ???? > checks for the stack being executable. >> ???? > >> ???? > Any thoughts? If there are no objections, I can propose a patch >> ??? that works >> ???? > for both gcc and clang on Linux. Also, I'm not sure how/if macOS >> ??? handles >> ???? > this problem given that it uses clang. >> >> ??? We don't seem to handle it at all on OS X. Does OS X prevent >> executable >> ??? stacks itself? >> >> A quick search, according to Wikipedia >> (https://en.wikipedia.org/wiki/Executable_space_protection#macOS), >> 64-bit executables on macOS aren't stack or heap executable. Not sure >> if that information is accurate though. > > Seems to be: > > https://developer.apple.com/library/archive/documentation/Security/Conceptual/SecureCodingGuide/Articles/BufferOverflows.html > > > "macOS and iOS provide two features that can make it harder to exploit > stack and buffer overflows: address space layout randomization (ASLR) > and a non-executable stack and heap." > > Cheers, > David > >> >> ??? David >> From boris.ulasevich at bell-sw.com Tue Aug 21 11:18:04 2018 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Tue, 21 Aug 2018 14:18:04 +0300 Subject: Primitive heap access for interpreter BarrierSetAssembler/arm32 Message-ID: Hi, Please review the primitive heap access changes for arm32: https://bugs.openjdk.java.net/browse/JDK-8209408 http://cr.openjdk.java.net/~bulasevich/8209408/webrev.00/ The patch replicates recent changes in aarch64. Thanks, Boris From aph at redhat.com Tue Aug 21 12:49:44 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 21 Aug 2018 13:49:44 +0100 Subject: RFR [11] 8207838: AArch64: Float registers incorrectly resture in JNI call In-Reply-To: <378dae46-aaec-5c8d-d40b-c343e1d7956a@redhat.com> References: <10d5c14e-2aaf-7c15-062f-fba0bb313299@redhat.com> <3140f273-f608-e34e-1410-d18073a278d7@redhat.com> <388180df-2b86-3b28-3c70-b6f07ba6fdd6@redhat.com> <613fd55b-9fad-d7e3-1c72-eaf029ba2d15@redhat.com> <378dae46-aaec-5c8d-d40b-c343e1d7956a@redhat.com> Message-ID: http://cr.openjdk.java.net/~aph/8207838-2/ The patch failed testing because some arches use very old C compilers. The only way I could duplicate the problem was with --std=c90 -Wall -Wextra -pedantic Maybe we should fix the OpenJDK build system to use such options. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From boris.ulasevich at bell-sw.com Tue Aug 21 13:14:18 2018 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Tue, 21 Aug 2018 16:14:18 +0300 Subject: RFR: 8209408: Primitive heap access for interpreter BarrierSetAssembler/arm32 In-Reply-To: References: Message-ID: Just correcting wrong Subject. Sorry. On 21.08.2018 14:18, Boris Ulasevich wrote: > Hi, > > Please review the primitive heap access changes for arm32: > ? https://bugs.openjdk.java.net/browse/JDK-8209408 > ? http://cr.openjdk.java.net/~bulasevich/8209408/webrev.00/ > > The patch replicates recent changes in aarch64. > > Thanks, > Boris From aph at redhat.com Tue Aug 21 13:23:32 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 21 Aug 2018 14:23:32 +0100 Subject: Is returning a value != '0' or '1' as jboolean from a JNI function legal? In-Reply-To: <85BA0604-C712-436C-9C97-F4476D0D0797@redhat.com> References: <130e0b86-e41f-fda7-5a6f-03b2135a9a60@redhat.com> <478E59AB-0EF6-4954-9A10-E3A742A0A081@redhat.com> <1c20ca62-f26f-6b69-d5ec-9f9a862efaad@redhat.com> <85BA0604-C712-436C-9C97-F4476D0D0797@redhat.com> Message-ID: On 08/20/2018 08:25 PM, Jason Greene wrote: > >> On Aug 20, 2018, at 12:23 PM, Andrew Haley wrote: >> >> On 08/20/2018 04:14 PM, Jason Greene wrote: >> >>> IMO departing from C semantics (non-zero = TRUE, zero = false) >>> offers little gain and will likely just lead to hard to catch >>> bugs. Even if the JNI developer knows the rules, it will be quite >>> easy for surprises to show up. For example, a developer might assume >>> a library call always returns 1, and wire it straight to a >>> boolean. If this assumption is broken (a condition not taken into >>> account, or future behavioral differences), then it could quickly >>> turn into a lot of wasted time and effort. >> >> It's tricky, though: a C implementation could silently truncate a >> value of 0xff00_0000 to (jboolean) 0x00, and there's not a damn thing >> that a JVM can do about it: there's literally no way to know. It's >> pretty much unfixable from our end. > > OK but in that case the C developer can see its an unsigned char, It's a jboolean. > and their compiler is likely to throw an overflow warning. Mmm, but GCC desn't. > Granted, it?s also true that int is a more common return value than > unsigned char. The function in question is *defined* as returning a jboolean: there's no doubt about that. The question is whether a C implementation truncates return values, and you can only see that by reading the system ABI specification. Not every system documents it: the only way until recently to find out what GCC on x86 did was to look at the generated code. The system ABI is different on different systems: on AArch64 a jboolean return value is silently truncated, on x86 it isn't. The only solution is to do what's suggested: make sure that you return JNI_TRUE/JNI_FALSE (or 1/0). It's all too horrible even to think about. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rkennke at redhat.com Tue Aug 21 13:45:03 2018 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 21 Aug 2018 15:45:03 +0200 Subject: RFR: 8209408: Primitive heap access for interpreter BarrierSetAssembler/arm32 In-Reply-To: References: Message-ID: Am 21.08.2018 um 15:14 schrieb Boris Ulasevich: > Just correcting wrong Subject. Sorry. > > On 21.08.2018 14:18, Boris Ulasevich wrote: >> Hi, >> >> Please review the primitive heap access changes for arm32: >> ?? https://bugs.openjdk.java.net/browse/JDK-8209408 >> ?? http://cr.openjdk.java.net/~bulasevich/8209408/webrev.00/ >> >> The patch replicates recent changes in aarch64. >> >> Thanks, >> Boris Hi Boris, this looks good to me! Thanks, Roman From coleen.phillimore at oracle.com Tue Aug 21 14:03:19 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 21 Aug 2018 10:03:19 -0400 Subject: RFR (XS) 8209738: Remove ClassLoaderDataGraph::*oops_do functions In-Reply-To: <15e07d2d684187adcb2ca3128dece665f54399ca.camel@oracle.com> References: <15e07d2d684187adcb2ca3128dece665f54399ca.camel@oracle.com> Message-ID: <135dd559-cb81-9355-0766-a1e69a5275c9@oracle.com> Thanks, Thomas! Coleen On 8/21/18 5:31 AM, Thomas Schatzl wrote: > Hi, > > On Mon, 2018-08-20 at 13:29 -0400, coleen.phillimore at oracle.com wrote: >> Summary: Make walking CLDG more consistent. >> >> Affects ParallelGC and jvmtiTagMap. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8209738.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8209738 >> >> Tested with mach5 tier1-7 and with runThese with all GCs. > looks good. > > Thomas > From vladimir.kozlov at oracle.com Tue Aug 21 16:44:46 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 21 Aug 2018 09:44:46 -0700 Subject: RFR [11] 8207838: AArch64: Float registers incorrectly resture in JNI call In-Reply-To: References: <10d5c14e-2aaf-7c15-062f-fba0bb313299@redhat.com> <3140f273-f608-e34e-1410-d18073a278d7@redhat.com> <388180df-2b86-3b28-3c70-b6f07ba6fdd6@redhat.com> <613fd55b-9fad-d7e3-1c72-eaf029ba2d15@redhat.com> <378dae46-aaec-5c8d-d40b-c343e1d7956a@redhat.com> Message-ID: I ran builds and stress tested new test on our platforms. All passed with this version. I approved it for JDK11 push. Please, push ASAP today. Andrew, I noticed that patch was based on jdk/jdk. Please, don't forget to switch to jdk/jdk11 for push. Regards, Vladimir On 8/21/18 5:49 AM, Andrew Haley wrote: > http://cr.openjdk.java.net/~aph/8207838-2/ > > The patch failed testing because some arches use very old C compilers. > The only way I could duplicate the problem was with > --std=c90 -Wall -Wextra -pedantic > > Maybe we should fix the OpenJDK build system to use such options. > From aph at redhat.com Tue Aug 21 17:55:24 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 21 Aug 2018 18:55:24 +0100 Subject: RFR [11] 8207838: AArch64: Float registers incorrectly resture in JNI call In-Reply-To: References: <10d5c14e-2aaf-7c15-062f-fba0bb313299@redhat.com> <3140f273-f608-e34e-1410-d18073a278d7@redhat.com> <388180df-2b86-3b28-3c70-b6f07ba6fdd6@redhat.com> <613fd55b-9fad-d7e3-1c72-eaf029ba2d15@redhat.com> <378dae46-aaec-5c8d-d40b-c343e1d7956a@redhat.com> Message-ID: On 08/21/2018 05:44 PM, Vladimir Kozlov wrote: > Please, push ASAP today. Andrew, I noticed that patch was based on jdk/jdk. Please, don't forget to switch to jdk/jdk11 > for push. Done. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aeubanks at google.com Tue Aug 21 21:10:26 2018 From: aeubanks at google.com (Arthur Eubanks) Date: Tue, 21 Aug 2018 14:10:26 -0700 Subject: Linux + Clang + execstack In-Reply-To: <4f753eb3-dc20-c69e-dbb8-752b74f2aa55@oracle.com> References: <26c39a87-9db0-d62a-e026-e4075e3237fb@oracle.com> <4f753eb3-dc20-c69e-dbb8-752b74f2aa55@oracle.com> Message-ID: Adding the linker flag sounds good. Opened JDK-8209817. webrev coming soon. On Tue, Aug 21, 2018 at 4:14 AM Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > On 2018-08-21 02:03, David Holmes wrote: > > On 21/08/2018 9:39 AM, Arthur Eubanks wrote: > >> On Mon, Aug 20, 2018 at 4:18 PM David Holmes >> > wrote: > >> > >> Hi Arthur, > >> > >> cc'ing build-dev as this is currently a build issue. > >> > >> On 21/08/2018 3:11 AM, Arthur Eubanks wrote: > >> > Hi, > >> > > >> > At Google we're trying to build hotspot on Linux with clang. One > >> thing that > >> > happens is that the resulting libjvm.so is stack executable. When > >> running > >> > hotspot we get warnings about the stack being executable. > >> > > >> > Compiling an assembly file into the final .so results in the > >> stack being > >> > executable. In this case the file is linux_x86_64.s. This doesn't > >> happen > >> > with gcc because "-Wl,-z,noexecstack" is passed as a hotspot > >> linker flag > >> > with gcc in flags-ldflags.m4. When using clang that linker > >> flag isn't > >> > passed. > >> > > >> > Doing something like the solution in > >> > https://wiki.ubuntu.com/SecurityTeam/Roadmap/ExecutableStacks > >> > fixes the problem without the use of linker flags. > >> > >> You mean the source code directives for the linker? > >> > >> Sorry, I wasn't specific enough, I meant the flags for the assembler. > >> #if defined(__linux__) && defined(__ELF__) > >> .section .note.GNU-stack, "", %progbits > >> #endif > >> > >> > >> I think I prefer to see this handled explicitly in the build as is > >> currently done. Can we just adjust > >> ./make/autoconf/flags-ldflags.m4 to > >> pass the linker flags for gcc and clang? > >> > >> I don't mind this solution, but it seems like the right thing to do > >> is to fix things at the source level and remove extra unnecessary > >> linker flags. > > > > Personally I see this as source code pollution. The concept of > > executable stacks has nothing to do with what is being expressed by > > the source code, or the language used for it. > > > > Just my 2c. I'll defer to build folk ... though they are still on > > vacation at the moment. > > I agree with David. The executable stack is a build option. Even if you > change the source code so the compiler/assember does the right thing, we > would still want to keep the compiler option. (Otherwise one day you'll > end up with executable stacks due to someone adding a new asm file and > forgetting the "magic incantation".) > > And, since we will keep the compiler option, there seems little point in > also adding this stuff to the asm files. > > To address your concerns on clang: we should reasonably be giving the > same options to clang. There is no good reason, except for oversight, > that this is not done already. (Cleaning up and unifying the compiler > flags is an ongoing, but slowly moving, process.) So the correct fix is > to update flags-ldflags.m4. > > /Magnus > > > > > > >> I removed "-Wl,-z,noexecstack" from the flags after adding the above > >> assembler flags and libjvm.so is still correctly not stack > >> executable. I don't really mind either way though. Maybe it's good to > >> have an extra safeguard in the linker flags. > >> > >> > >> > The jtreg test > >> test/hotspot/jtreg/runtime/execstack/TestCheckJDK.java > >> > checks for the stack being executable. > >> > > >> > Any thoughts? If there are no objections, I can propose a patch > >> that works > >> > for both gcc and clang on Linux. Also, I'm not sure how/if macOS > >> handles > >> > this problem given that it uses clang. > >> > >> We don't seem to handle it at all on OS X. Does OS X prevent > >> executable > >> stacks itself? > >> > >> A quick search, according to Wikipedia > >> (https://en.wikipedia.org/wiki/Executable_space_protection#macOS), > >> 64-bit executables on macOS aren't stack or heap executable. Not sure > >> if that information is accurate though. > > > > Seems to be: > > > > > https://developer.apple.com/library/archive/documentation/Security/Conceptual/SecureCodingGuide/Articles/BufferOverflows.html > > > > > > "macOS and iOS provide two features that can make it harder to exploit > > stack and buffer overflows: address space layout randomization (ASLR) > > and a non-executable stack and heap." > > > > Cheers, > > David > > > >> > >> David > >> > > From igor.ignatyev at oracle.com Tue Aug 21 23:04:33 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 21 Aug 2018 16:04:33 -0700 Subject: RFR(M/L) : 8209611 : use C++ compiler for hotspot tests In-Reply-To: <29AD64D9-A86E-4105-8D07-F8EEC6B2B56E@oracle.com> References: <92CD42CC-568A-4972-A35E-469B1532B103@oracle.com> <9f172999-2e45-8ebd-dba6-5d2d8927309b@oracle.com> <7d0ea30f-19c7-8a43-0616-fffb56bc5840@oracle.com> <29AD64D9-A86E-4105-8D07-F8EEC6B2B56E@oracle.com> Message-ID: <9759A264-829B-4A3D-A739-F8443150B57D@oracle.com> http://cr.openjdk.java.net/~iignatyev//8209611/webrev.02/index.html is a new version of patch, which moves only vmTestbase tests. Thanks, -- Igor > On Aug 20, 2018, at 11:07 PM, Igor Ignatyev wrote: > >>> It has been discussed (not widely enough and I accept that) in 8209547 and the related email thread b/w JC(cc'ed) and myself. >>> as I said, I might went a way too far, so I'll revert changes in the non-vmTestbase tests and made appropriate changes in makefiles. what do you think? >> >> I think I need to see what you mean exactly :) > sure, it will take some time for me to do that, hopefully will upload new webrevs tomorrow morning PT. but the basic idea is to leave files in test/hotspot/jtreg/compiler, runtime, gc, native_sanity, serviceability, testlibrary as .c files, exactly as they were before, and restore corresponding filenames in make/test/JtregNativeHotspot.gmk. From david.holmes at oracle.com Wed Aug 22 04:28:05 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Aug 2018 14:28:05 +1000 Subject: RFR(M/L) : 8209611 : use C++ compiler for hotspot tests In-Reply-To: <9759A264-829B-4A3D-A739-F8443150B57D@oracle.com> References: <92CD42CC-568A-4972-A35E-469B1532B103@oracle.com> <9f172999-2e45-8ebd-dba6-5d2d8927309b@oracle.com> <7d0ea30f-19c7-8a43-0616-fffb56bc5840@oracle.com> <29AD64D9-A86E-4105-8D07-F8EEC6B2B56E@oracle.com> <9759A264-829B-4A3D-A739-F8443150B57D@oracle.com> Message-ID: Hi Igor, On 22/08/2018 9:04 AM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8209611/webrev.02/index.html > ?is > a new version of patch, which moves only vmTestbase tests. This seems okay in principle. I didn't verify all the mechanical changes individually. make/common/TestFilesCompilation.gmk I suspect you can just find all .c and .cpp files and process them together, rather than duplicate all the logic. But I'll leave that to Magnus to comment on. make/test/JtregNativeHotspot.gmk + BUILD_HOTSPOT_JTREG_LIBRARIES_CFLAGS := -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS Just a note that defining these is obsolete once we use C11/C++11 - which I think is an intent for JDK 12 if possible. --- test/hotspot/jtreg/vmTestbase/gc/g1/unloading/libdefine.cpp #ifdef __cplusplus ! #define JNI_ENV_ARG(x, y) y #define JNI_ENV_PTR(x) x #else #define JNI_ENV_ARG(x, y) x , y #define JNI_ENV_PTR(x) (*x) #endif If this is now a C++ source file why do you a still have the code that allows for either C or C++? Is this stuff that will be cleaned up in the later RFE? --- The switch to C++ means a lot of code now needs: + #ifdef __cplusplus + extern "C" { + #endif I still have to wonder whether it better to leave these as C tests and only convert to C++ as and when needed ... seems like so much work. Anyway I'm off on vacation after today so I'll leave it to others to take this up. Thanks, David > Thanks, > -- Igor > >> On Aug 20, 2018, at 11:07 PM, Igor Ignatyev > > wrote: >> >>>> It has been discussed (not widely enough and I accept that) in >>>> 8209547 and the related email thread b/w JC(cc'ed) and myself. >>>> as I said, I might went a way too far, so I'll revert changes in the >>>> non-vmTestbase tests and made appropriate changes in makefiles. what >>>> do you think? >>> >>> I think I need to see what you mean exactly :) >> sure, it will take some time for me to do that, hopefully will upload >> new webrevs tomorrow morning PT. but the basic idea is to leave files >> in test/hotspot/jtreg/compiler, runtime, gc, native_sanity, >> serviceability, testlibrary as .c files, exactly as they were before, >> and restore corresponding filenames in make/test/JtregNativeHotspot.gmk. > From igor.ignatyev at oracle.com Wed Aug 22 04:57:28 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 21 Aug 2018 21:57:28 -0700 Subject: RFR(M/L) : 8209611 : use C++ compiler for hotspot tests In-Reply-To: References: <92CD42CC-568A-4972-A35E-469B1532B103@oracle.com> <9f172999-2e45-8ebd-dba6-5d2d8927309b@oracle.com> <7d0ea30f-19c7-8a43-0616-fffb56bc5840@oracle.com> <29AD64D9-A86E-4105-8D07-F8EEC6B2B56E@oracle.com> <9759A264-829B-4A3D-A739-F8443150B57D@oracle.com> Message-ID: <3C20AC1D-2D72-4B72-B6C9-CC659A6BF1C3@oracle.com> Hi David, thanks for looking at the webrev and all your comments. my answers are inlined. enjoy your vacation! -- Igor > On Aug 21, 2018, at 9:28 PM, David Holmes wrote: > > Hi Igor, > > On 22/08/2018 9:04 AM, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8209611/webrev.02/index.html is a new version of patch, which moves only vmTestbase tests. > > This seems okay in principle. I didn't verify all the mechanical changes individually. > > make/common/TestFilesCompilation.gmk > > I suspect you can just find all .c and .cpp files and process them together, rather than duplicate all the logic. But I'll leave that to Magnus to comment on. I had to duplicate this foreach cycle to specify a correct TOOLCHAIN, w/o it linking fails on linux-slowdebug. > > make/test/JtregNativeHotspot.gmk > > + BUILD_HOTSPOT_JTREG_LIBRARIES_CFLAGS := -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS > > Just a note that defining these is obsolete once we use C11/C++11 - which I think is an intent for JDK 12 if possible. initially I wanted to use instead of + -D__STDC_FORMAT_MACROS, but solaris studio apparently doesn't have cinttypes header file. hotspot makefiles also use -D__STDC_, so I hope both places will be fixed together. > > test/hotspot/jtreg/vmTestbase/gc/g1/unloading/libdefine.cpp > > #ifdef __cplusplus > ! #define JNI_ENV_ARG(x, y) y > #define JNI_ENV_PTR(x) x > #else > #define JNI_ENV_ARG(x, y) x , y > #define JNI_ENV_PTR(x) (*x) > #endif > > If this is now a C++ source file why do you a still have the code that allows for either C or C++? Is this stuff that will be cleaned up in the later RFE? yes, 8209547 will clean up JNI_ENV_ARG macros. > > --- > > The switch to C++ means a lot of code now needs: > > + #ifdef __cplusplus > + extern "C" { > + #endif that's true, and this patch adds 'extern "C"' very conservatively (basically to everywhere). this, if needed, can be cleaned up later. > > I still have to wonder whether it better to leave these as C tests and only convert to C++ as and when needed ... seems like so much work. > > Anyway I'm off on vacation after today so I'll leave it to others to take this up. > > Thanks, > David > >> Thanks, >> -- Igor >>> On Aug 20, 2018, at 11:07 PM, Igor Ignatyev > wrote: >>> >>>>> It has been discussed (not widely enough and I accept that) in 8209547 and the related email thread b/w JC(cc'ed) and myself. >>>>> as I said, I might went a way too far, so I'll revert changes in the non-vmTestbase tests and made appropriate changes in makefiles. what do you think? >>>> >>>> I think I need to see what you mean exactly :) >>> sure, it will take some time for me to do that, hopefully will upload new webrevs tomorrow morning PT. but the basic idea is to leave files in test/hotspot/jtreg/compiler, runtime, gc, native_sanity, serviceability, testlibrary as .c files, exactly as they were before, and restore corresponding filenames in make/test/JtregNativeHotspot.gmk. From erik.osterlund at oracle.com Wed Aug 22 08:44:50 2018 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Wed, 22 Aug 2018 10:44:50 +0200 Subject: RFR: 8208601: Introduce native oop barriers in C2 for OopHandle In-Reply-To: <2fd76c3a-2363-f7fe-d4a4-5b7dcbb6a2e8@oracle.com> References: <5B6196CA.7080201@oracle.com> <2fd76c3a-2363-f7fe-d4a4-5b7dcbb6a2e8@oracle.com> Message-ID: <5B7D2282.3020402@oracle.com> Hi Nils, Thanks for the review! /Erik On 2018-08-21 11:46, Nils Eliasson wrote: > Looks good. > > // Nils > > > On 2018-08-01 13:17, Erik ?sterlund wrote: >> Hi, >> >> There is currently no way of doing IN_NATIVE accesses in C2 using its >> access API. These are required to properly access OopHandle, used to >> access the Java class mirrors (because they will now start requiring >> load barriers). In order to support (concurrent) class unloading in >> ZGC, this support must be added. >> >> In this patch, I add an access_load API for loading IN_NATIVE oops, >> and use it to load class mirrors (which is logically an >> OopHandle::resolve, which happened to have been an indirect load >> before as nobody had load barriers on it). In the various code >> recognizing the shape of a mirror load to optimize the code, I have >> added a check if a node is a GC barrier and to then step over it in >> order to match the mirror load. >> >> In order to recognize and step over the load barriers in ZGC >> properly, I added support for recognizing the barrier shapes not just >> before macro expansion (LoadBarrierNode), but also after macro >> expansion (as required by the matching code), which involves checking >> for phi nodes with with LoadBarrierSlowRegNode phi->in(1), and then >> stepping over to phi->in(2), as well as recognizing projections to >> such shapes. LoadBarrierSlowRegNode is used in all barrier expansions >> except for atomic xchg, but that is fine as we don't use that on >> class mirrors. >> >> I have checked that the shapes are recognized and that no regressions >> are introduced with these changes through a bunch of benchmarks in >> gc-test-suite. >> >> Webrev: >> http://cr.openjdk.java.net/~eosterlund/8208601/webrev.00/ >> >> Bug URL: >> https://bugs.openjdk.java.net/browse/JDK-8208601 >> >> >> Thanks, >> /Erik >> Open Tracking > From jcbeyler at google.com Wed Aug 22 18:53:42 2018 From: jcbeyler at google.com (JC Beyler) Date: Wed, 22 Aug 2018 11:53:42 -0700 Subject: RFR(M/L) : 8209611 : use C++ compiler for hotspot tests In-Reply-To: <3C20AC1D-2D72-4B72-B6C9-CC659A6BF1C3@oracle.com> References: <92CD42CC-568A-4972-A35E-469B1532B103@oracle.com> <9f172999-2e45-8ebd-dba6-5d2d8927309b@oracle.com> <7d0ea30f-19c7-8a43-0616-fffb56bc5840@oracle.com> <29AD64D9-A86E-4105-8D07-F8EEC6B2B56E@oracle.com> <9759A264-829B-4A3D-A739-F8443150B57D@oracle.com> <3C20AC1D-2D72-4B72-B6C9-CC659A6BF1C3@oracle.com> Message-ID: Hi Igor, I looked over the changes and tried to pay attention to all the mechanical changes done. They look good to me as they are the step in the direction of getting it all in C++. I will be happy to start on 8209547 once this goes in. (As always, not an official reviewer) Two nits: - We could use static_cast? + *new_bytes = (u1*) realloc(gen, *new_length); - Add a space since we are doing the change (this is one example)? - arrayOrig[i]=env->GetObjectArrayElement(orig,i); CE - arrayClone[i]=env->GetObjectArrayElement(clone,i); CE + arrayOrig[i]=(jarray) env->GetObjectArrayElement(orig,i); CE + arrayClone[i]=(jarray) env->GetObjectArrayElement(clone,i); CE On the other hand, we could just clean this up later once this big move to C++ happens, so I'd be happy to see us tackle it in a second/third step. So looks good to me and thanks for doing it! Jc On Tue, Aug 21, 2018 at 9:58 PM Igor Ignatyev wrote: > Hi David, > > thanks for looking at the webrev and all your comments. my answers are > inlined. > > enjoy your vacation! > > -- Igor > > > On Aug 21, 2018, at 9:28 PM, David Holmes > wrote: > > > > Hi Igor, > > > > On 22/08/2018 9:04 AM, Igor Ignatyev wrote: > >> http://cr.openjdk.java.net/~iignatyev//8209611/webrev.02/index.html < > http://cr.openjdk.java.net/%7Eiignatyev//8209611/webrev.02/index.html> is > a new version of patch, which moves only vmTestbase tests. > > > > This seems okay in principle. I didn't verify all the mechanical changes > individually. > > > > make/common/TestFilesCompilation.gmk > > > > I suspect you can just find all .c and .cpp files and process them > together, rather than duplicate all the logic. But I'll leave that to > Magnus to comment on. > I had to duplicate this foreach cycle to specify a correct TOOLCHAIN, w/o > it linking fails on linux-slowdebug. > > > > make/test/JtregNativeHotspot.gmk > > > > + BUILD_HOTSPOT_JTREG_LIBRARIES_CFLAGS := -D__STDC_FORMAT_MACROS > -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS > > > > Just a note that defining these is obsolete once we use C11/C++11 - > which I think is an intent for JDK 12 if possible. > initially I wanted to use instead of + > -D__STDC_FORMAT_MACROS, but solaris studio apparently doesn't have > cinttypes header file. > > hotspot makefiles also use -D__STDC_, so I hope both places will be fixed > together. > > > > > test/hotspot/jtreg/vmTestbase/gc/g1/unloading/libdefine.cpp > > > > #ifdef __cplusplus > > ! #define JNI_ENV_ARG(x, y) y > > #define JNI_ENV_PTR(x) x > > #else > > #define JNI_ENV_ARG(x, y) x , y > > #define JNI_ENV_PTR(x) (*x) > > #endif > > > > If this is now a C++ source file why do you a still have the code that > allows for either C or C++? Is this stuff that will be cleaned up in the > later RFE? > yes, 8209547 will clean up JNI_ENV_ARG macros. > > > > > --- > > > > The switch to C++ means a lot of code now needs: > > > > + #ifdef __cplusplus > > + extern "C" { > > + #endif > > that's true, and this patch adds 'extern "C"' very conservatively > (basically to everywhere). this, if needed, can be cleaned up later. > > > > > I still have to wonder whether it better to leave these as C tests and > only convert to C++ as and when needed ... seems like so much work. > > > > Anyway I'm off on vacation after today so I'll leave it to others to > take this up. > > > > Thanks, > > David > > > >> Thanks, > >> -- Igor > >>> On Aug 20, 2018, at 11:07 PM, Igor Ignatyev > wrote: > >>> > >>>>> It has been discussed (not widely enough and I accept that) in > 8209547 and the related email thread b/w JC(cc'ed) and myself. > >>>>> as I said, I might went a way too far, so I'll revert changes in the > non-vmTestbase tests and made appropriate changes in makefiles. what do you > think? > >>>> > >>>> I think I need to see what you mean exactly :) > >>> sure, it will take some time for me to do that, hopefully will upload > new webrevs tomorrow morning PT. but the basic idea is to leave files in > test/hotspot/jtreg/compiler, runtime, gc, native_sanity, serviceability, > testlibrary as .c files, exactly as they were before, and restore > corresponding filenames in make/test/JtregNativeHotspot.gmk. > > -- Thanks, Jc From kim.barrett at oracle.com Wed Aug 22 19:18:36 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 22 Aug 2018 15:18:36 -0400 Subject: RFR: 8209850: Allow NamedThreads to use GlobalCounter critical sections Message-ID: <52917853-9C79-4C3D-8811-389DB3A4CD6C@oracle.com> Please review this change to GlobalCounter, permitting NamedThreads to enter a critical section. To accomplish this, we add a new RCU-inspired synchronization utility, SingleWriterSynchronizer. This has some similarities to GlobalCounter, but the latter should be preferred except where it can't be used (such as in the implementation of GlobalCounter!). This utility is based on a private utility embedded in OopStorage. That private utility is being replaced by the new public one. Using this new synchronization utility, we provide lock-free iteration over the list of NamedThreads that is safe against creation and deletion of such threads. That iteration is used by GlobalCounter to examine all NamedThreads, rather than only the VMThread. CR: https://bugs.openjdk.java.net/browse/JDK-8209850 Webrev: http://cr.openjdk.java.net/~kbarrett/8209850/open.00/ Testing: mach5 tier1-3, hs-tier4-5. New synchronization utility includes a gtest. From yingsu at fb.com Wed Aug 22 19:58:21 2018 From: yingsu at fb.com (Ying Su) Date: Wed, 22 Aug 2018 19:58:21 +0000 Subject: custom/fast heap dumper In-Reply-To: References: <025D08AD-4ADD-410F-A346-FB4D1EB037C9@contoso.com> Message-ID: <6B055461-54E3-4E48-8FF1-FA1FB640C839@fb.com> Hi Krystal, Thank you very much for your valuable input! The online analysis would definitely help in a lot of cases. However there are still some cases getting a heap dump would help or ease the way of investigation: 1. When there is slow memory leak; 2. When there is OOM on heap. Getting a full dump at OOM greatly helped us in finding the problem; 3. When full GCs happen. The occurrences of 2) and 3) are hard to predict and online analysis usually requires to be taken before these events happen for a period of time and could create lots of false positive data collections. So taking a heap dump still helps us in a lot of ways. That being said, we are still looking for expert opinions on the best way to implement such fast heap dumper. Your suggestions are highly appreciated! Thank you, Ying From: Krystal Mok Date: Friday, August 17, 2018 at 4:26 PM To: Ying Su Cc: "hotspot-dev at openjdk.java.net" Subject: Re: custom/fast heap dumper Hi Ying, Side-stepping from your question a bit: is it absolutely necessary to take a full heap dump for your use case? Or would it be more feasible to do some of the analysis that you want online instead of taking a heap dump and then do offline analysis? Some analysis that people used to do on heap dump snapshots could be done with JFR or the new Low-overhead heap profiling feature. Would those be sufficient, or perhaps would extending those a bit be sufficient for your use case? At Azul Systems, the Zing JVM supports some of the analysis piggybacking on the GC. Since the C4 GC is fully concurrent (*), these operations are not interruptive at all and has very low overhead. For OpenJDK, with ZGC on the horizon, this kind of feature piggybacking on a fully concurrent GC would also be possible. My two cents, Kris * C4 GC can concurrently mark and compact the heap, albeit it does still do a few very short pauses during the whole concurrent GC cycle. Similar story with ZGC. On Fri, Aug 17, 2018 at 3:51 PM, Ying Su > wrote: Hi, We want to implement a custom fast heap dumper that should work on Java 9 and 10, because we often need to dump huge heaps (~200GB), and it takes 20-30 minutes with jmap (e.g. we thought about zeroing out the large arrays and compressing the output, etc.) We?ve been looking at the following 2 options: 1. Modify the JVMTI demo hprof implementation in JDK8 2. Reuse/modify jdk9-dev/hotspot/src/share/vm/services/heapDumper.cpp We?ve tried the first option but it?s very slow due to some shared hash tables causing high lock contention. And the second option is more complicated because we need to access internal JVM classes, and we don?t know how we can deploy it to production. We?d appreciate if we can get some expert opinion on how to best solve this problem. Thank you very much, Ying From david.holmes at oracle.com Wed Aug 22 20:44:16 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 23 Aug 2018 06:44:16 +1000 Subject: custom/fast heap dumper In-Reply-To: <6B055461-54E3-4E48-8FF1-FA1FB640C839@fb.com> References: <025D08AD-4ADD-410F-A346-FB4D1EB037C9@contoso.com> <6B055461-54E3-4E48-8FF1-FA1FB640C839@fb.com> Message-ID: <8d9017b6-a85b-350c-bda5-2a7534050fc7@oracle.com> Adding serviceability-dev to get more input. Cheers, David On 23/08/2018 5:58 AM, Ying Su wrote: > Hi Krystal, > > Thank you very much for your valuable input! The online analysis would definitely help in a lot of cases. However there are still some cases getting a heap dump would help or ease the way of investigation: > > 1. When there is slow memory leak; > 2. When there is OOM on heap. Getting a full dump at OOM greatly helped us in finding the problem; > 3. When full GCs happen. > The occurrences of 2) and 3) are hard to predict and online analysis usually requires to be taken before these events happen for a period of time and could create lots of false positive data collections. So taking a heap dump still helps us in a lot of ways. > > That being said, we are still looking for expert opinions on the best way to implement such fast heap dumper. Your suggestions are highly appreciated! > > Thank you, > Ying > > From: Krystal Mok > Date: Friday, August 17, 2018 at 4:26 PM > To: Ying Su > Cc: "hotspot-dev at openjdk.java.net" > Subject: Re: custom/fast heap dumper > > Hi Ying, > > Side-stepping from your question a bit: is it absolutely necessary to take a full heap dump for your use case? Or would it be more feasible to do some of the analysis that you want online instead of taking a heap dump and then do offline analysis? > > Some analysis that people used to do on heap dump snapshots could be done with JFR or the new Low-overhead heap profiling feature. Would those be sufficient, or perhaps would extending those a bit be sufficient for your use case? > > At Azul Systems, the Zing JVM supports some of the analysis piggybacking on the GC. Since the C4 GC is fully concurrent (*), these operations are not interruptive at all and has very low overhead. > For OpenJDK, with ZGC on the horizon, this kind of feature piggybacking on a fully concurrent GC would also be possible. > > My two cents, > Kris > > * C4 GC can concurrently mark and compact the heap, albeit it does still do a few very short pauses during the whole concurrent GC cycle. Similar story with ZGC. > > On Fri, Aug 17, 2018 at 3:51 PM, Ying Su > wrote: > Hi, > > We want to implement a custom fast heap dumper that should work on Java 9 and 10, because we often need to dump huge heaps (~200GB), and it takes 20-30 minutes with jmap (e.g. we thought about zeroing out the large arrays and compressing the output, etc.) We?ve been looking at the following 2 options: > > > 1. Modify the JVMTI demo hprof implementation in JDK8 > 2. Reuse/modify jdk9-dev/hotspot/src/share/vm/services/heapDumper.cpp > > We?ve tried the first option but it?s very slow due to some shared hash tables causing high lock contention. And the second option is more complicated because we need to access internal JVM classes, and we don?t know how we can deploy it to production. We?d appreciate if we can get some expert opinion on how to best solve this problem. > > > Thank you very much, > Ying > > > > > > > From rbruno at gsd.inesc-id.pt Wed Aug 22 21:05:46 2018 From: rbruno at gsd.inesc-id.pt (Rodrigo Bruno) Date: Wed, 22 Aug 2018 23:05:46 +0200 Subject: custom/fast heap dumper Message-ID: Hi Ying, some time ago I worked on using CRIU [1] to snapshot JVMs running workloads such as Cassandra after each GC [2]. CRIU is able to take raw incremental memory snapshots very fast which enabled us to do further extensive offline processing with close to zero application disruption. We didn't go beyong 12~16 GB heaps but it might be worth trying. CRIU support for snapshotting process resources is continuously improving. Compared to jmap our fast dumper (simply JVMTI agent to request CRIU to checkpoint the JVM) was more than 90% faster than jmap and used 60% less disk space to store dumps. With CRIU snapshots you can re-create the JVM and do a proper object graph dump or analyze the memory directly. cheers, rodrigo bruno [1] criu.org [2] http://www.gsd.inesc-id.pt/~rbruno/publications/rbruno-middleware17.pdf ------------------------------ Message: 3 Date: Wed, 22 Aug 2018 19:58:21 +0000 From: Ying Su To: Krystal Mok Cc: "hotspot-dev at openjdk.java.net" Subject: Re: custom/fast heap dumper Message-ID: <6B055461-54E3-4E48-8FF1-FA1FB640C839 at fb.com> Content-Type: text/plain; charset="utf-8" Hi Krystal, Thank you very much for your valuable input! The online analysis would definitely help in a lot of cases. However there are still some cases getting a heap dump would help or ease the way of investigation: 1. When there is slow memory leak; 2. When there is OOM on heap. Getting a full dump at OOM greatly helped us in finding the problem; 3. When full GCs happen. The occurrences of 2) and 3) are hard to predict and online analysis usually requires to be taken before these events happen for a period of time and could create lots of false positive data collections. So taking a heap dump still helps us in a lot of ways. That being said, we are still looking for expert opinions on the best way to implement such fast heap dumper. Your suggestions are highly appreciated! Thank you, Ying From igor.ignatyev at oracle.com Wed Aug 22 21:15:54 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 22 Aug 2018 14:15:54 -0700 Subject: RFR(M/L) : 8209611 : use C++ compiler for hotspot tests In-Reply-To: References: <92CD42CC-568A-4972-A35E-469B1532B103@oracle.com> <9f172999-2e45-8ebd-dba6-5d2d8927309b@oracle.com> <7d0ea30f-19c7-8a43-0616-fffb56bc5840@oracle.com> <29AD64D9-A86E-4105-8D07-F8EEC6B2B56E@oracle.com> <9759A264-829B-4A3D-A739-F8443150B57D@oracle.com> <3C20AC1D-2D72-4B72-B6C9-CC659A6BF1C3@oracle.com> Message-ID: <6B138771-07DC-4338-9524-89CE50C085F2@oracle.com> Hi JC, thanks for looking at it and even paying attention to the changes;) regarding your nits. a space before comma is straightforward and must be done for test code to be aligned w/ regular hotspot code style, static_case<> is more controversial, it's not used much by hotspot. I do recall some discussion around it 3-4 years ago, but I can't recall the outcome. anyhow, I'd prefer to clean it up later, as these editorial/style fixes can be done more gradually, and this patch kinda blocks your work on 8209547. Thanks, -- Igor > On Aug 22, 2018, at 11:53 AM, JC Beyler wrote: > > Hi Igor, > > I looked over the changes and tried to pay attention to all the mechanical changes done. They look good to me as they are the step in the direction of getting it all in C++. I will be happy to start on 8209547 once this goes in. > > (As always, not an official reviewer) > > Two nits: > > - We could use static_cast? > + *new_bytes = (u1*) realloc(gen, *new_length); > > - Add a space since we are doing the change (this is one example)? > - arrayOrig[i]=env->GetObjectArrayElement(orig,i); CE > - arrayClone[i]=env->GetObjectArrayElement(clone,i); CE > + arrayOrig[i]=(jarray) env->GetObjectArrayElement(orig,i); CE > + arrayClone[i]=(jarray) env->GetObjectArrayElement(clone,i); CE > > On the other hand, we could just clean this up later once this big move to C++ happens, so I'd be happy to see us tackle it in a second/third step. > > So looks good to me and thanks for doing it! > Jc > > On Tue, Aug 21, 2018 at 9:58 PM Igor Ignatyev > wrote: > Hi David, > > thanks for looking at the webrev and all your comments. my answers are inlined. > > enjoy your vacation! > > -- Igor > > > On Aug 21, 2018, at 9:28 PM, David Holmes > wrote: > > > > Hi Igor, > > > > On 22/08/2018 9:04 AM, Igor Ignatyev wrote: > >> http://cr.openjdk.java.net/~iignatyev//8209611/webrev.02/index.html > is a new version of patch, which moves only vmTestbase tests. > > > > This seems okay in principle. I didn't verify all the mechanical changes individually. > > > > make/common/TestFilesCompilation.gmk > > > > I suspect you can just find all .c and .cpp files and process them together, rather than duplicate all the logic. But I'll leave that to Magnus to comment on. > I had to duplicate this foreach cycle to specify a correct TOOLCHAIN, w/o it linking fails on linux-slowdebug. > > > > make/test/JtregNativeHotspot.gmk > > > > + BUILD_HOTSPOT_JTREG_LIBRARIES_CFLAGS := -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS > > > > Just a note that defining these is obsolete once we use C11/C++11 - which I think is an intent for JDK 12 if possible. > initially I wanted to use instead of + -D__STDC_FORMAT_MACROS, but solaris studio apparently doesn't have cinttypes header file. > > hotspot makefiles also use -D__STDC_, so I hope both places will be fixed together. > > > > > test/hotspot/jtreg/vmTestbase/gc/g1/unloading/libdefine.cpp > > > > #ifdef __cplusplus > > ! #define JNI_ENV_ARG(x, y) y > > #define JNI_ENV_PTR(x) x > > #else > > #define JNI_ENV_ARG(x, y) x , y > > #define JNI_ENV_PTR(x) (*x) > > #endif > > > > If this is now a C++ source file why do you a still have the code that allows for either C or C++? Is this stuff that will be cleaned up in the later RFE? > yes, 8209547 will clean up JNI_ENV_ARG macros. > > > > > --- > > > > The switch to C++ means a lot of code now needs: > > > > + #ifdef __cplusplus > > + extern "C" { > > + #endif > > that's true, and this patch adds 'extern "C"' very conservatively (basically to everywhere). this, if needed, can be cleaned up later. > > > > > I still have to wonder whether it better to leave these as C tests and only convert to C++ as and when needed ... seems like so much work. > > > > Anyway I'm off on vacation after today so I'll leave it to others to take this up. > > > > Thanks, > > David > > > >> Thanks, > >> -- Igor > >>> On Aug 20, 2018, at 11:07 PM, Igor Ignatyev >> wrote: > >>> > >>>>> It has been discussed (not widely enough and I accept that) in 8209547 and the related email thread b/w JC(cc'ed) and myself. > >>>>> as I said, I might went a way too far, so I'll revert changes in the non-vmTestbase tests and made appropriate changes in makefiles. what do you think? > >>>> > >>>> I think I need to see what you mean exactly :) > >>> sure, it will take some time for me to do that, hopefully will upload new webrevs tomorrow morning PT. but the basic idea is to leave files in test/hotspot/jtreg/compiler, runtime, gc, native_sanity, serviceability, testlibrary as .c files, exactly as they were before, and restore corresponding filenames in make/test/JtregNativeHotspot.gmk. > > > > -- > > Thanks, > Jc From jcbeyler at google.com Wed Aug 22 21:39:43 2018 From: jcbeyler at google.com (JC Beyler) Date: Wed, 22 Aug 2018 14:39:43 -0700 Subject: RFR(M/L) : 8209611 : use C++ compiler for hotspot tests In-Reply-To: <6B138771-07DC-4338-9524-89CE50C085F2@oracle.com> References: <92CD42CC-568A-4972-A35E-469B1532B103@oracle.com> <9f172999-2e45-8ebd-dba6-5d2d8927309b@oracle.com> <7d0ea30f-19c7-8a43-0616-fffb56bc5840@oracle.com> <29AD64D9-A86E-4105-8D07-F8EEC6B2B56E@oracle.com> <9759A264-829B-4A3D-A739-F8443150B57D@oracle.com> <3C20AC1D-2D72-4B72-B6C9-CC659A6BF1C3@oracle.com> <6B138771-07DC-4338-9524-89CE50C085F2@oracle.com> Message-ID: Sounds good to me, thanks for doing it. Let's push the question about static_cast to future clean-up/conversations then. Still looks good to me ;-) Jc On Wed, Aug 22, 2018 at 2:15 PM Igor Ignatyev wrote: > Hi JC, > > thanks for looking at it and even paying attention to the changes;) > > regarding your nits. a space before comma is straightforward and must be > done for test code to be aligned w/ regular hotspot code style, > static_case<> is more controversial, it's not used much by hotspot. I do > recall some discussion around it 3-4 years ago, but I can't recall the > outcome. anyhow, I'd prefer to clean it up later, as these editorial/style > fixes can be done more gradually, and this patch kinda blocks your work on > 8209547. > > Thanks, > -- Igor > > > On Aug 22, 2018, at 11:53 AM, JC Beyler wrote: > > Hi Igor, > > I looked over the changes and tried to pay attention to all the mechanical > changes done. They look good to me as they are the step in the direction of > getting it all in C++. I will be happy to start on 8209547 once this goes > in. > > (As always, not an official reviewer) > > Two nits: > > - We could use static_cast? > + *new_bytes = (u1*) realloc(gen, *new_length); > > - Add a space since we are doing the change (this is one example)? > > - arrayOrig[i]=env->GetObjectArrayElement(orig,i); CE > - arrayClone[i]=env->GetObjectArrayElement(clone,i); CE > + arrayOrig[i]=(jarray) env->GetObjectArrayElement(orig,i); CE > + arrayClone[i]=(jarray) env->GetObjectArrayElement(clone,i); CE > > > On the other hand, we could just clean this up later once this big move to > C++ happens, so I'd be happy to see us tackle it in a second/third step. > > So looks good to me and thanks for doing it! > Jc > > On Tue, Aug 21, 2018 at 9:58 PM Igor Ignatyev > wrote: > >> Hi David, >> >> thanks for looking at the webrev and all your comments. my answers are >> inlined. >> >> enjoy your vacation! >> >> -- Igor >> >> > On Aug 21, 2018, at 9:28 PM, David Holmes >> wrote: >> > >> > Hi Igor, >> > >> > On 22/08/2018 9:04 AM, Igor Ignatyev wrote: >> >> http://cr.openjdk.java.net/~iignatyev//8209611/webrev.02/index.html < >> http://cr.openjdk.java.net/%7Eiignatyev//8209611/webrev.02/index.html> >> is a new version of patch, which moves only vmTestbase tests. >> > >> > This seems okay in principle. I didn't verify all the mechanical >> changes individually. >> > >> > make/common/TestFilesCompilation.gmk >> > >> > I suspect you can just find all .c and .cpp files and process them >> together, rather than duplicate all the logic. But I'll leave that to >> Magnus to comment on. >> I had to duplicate this foreach cycle to specify a correct TOOLCHAIN, w/o >> it linking fails on linux-slowdebug. >> > >> > make/test/JtregNativeHotspot.gmk >> > >> > + BUILD_HOTSPOT_JTREG_LIBRARIES_CFLAGS := -D__STDC_FORMAT_MACROS >> -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS >> > >> > Just a note that defining these is obsolete once we use C11/C++11 - >> which I think is an intent for JDK 12 if possible. >> initially I wanted to use instead of + >> -D__STDC_FORMAT_MACROS, but solaris studio apparently doesn't have >> cinttypes header file. >> >> hotspot makefiles also use -D__STDC_, so I hope both places will be fixed >> together. >> >> > >> > test/hotspot/jtreg/vmTestbase/gc/g1/unloading/libdefine.cpp >> > >> > #ifdef __cplusplus >> > ! #define JNI_ENV_ARG(x, y) y >> > #define JNI_ENV_PTR(x) x >> > #else >> > #define JNI_ENV_ARG(x, y) x , y >> > #define JNI_ENV_PTR(x) (*x) >> > #endif >> > >> > If this is now a C++ source file why do you a still have the code that >> allows for either C or C++? Is this stuff that will be cleaned up in the >> later RFE? >> yes, 8209547 will clean up JNI_ENV_ARG macros. >> >> > >> > --- >> > >> > The switch to C++ means a lot of code now needs: >> > >> > + #ifdef __cplusplus >> > + extern "C" { >> > + #endif >> >> that's true, and this patch adds 'extern "C"' very conservatively >> (basically to everywhere). this, if needed, can be cleaned up later. >> >> > >> > I still have to wonder whether it better to leave these as C tests and >> only convert to C++ as and when needed ... seems like so much work. >> > >> > Anyway I'm off on vacation after today so I'll leave it to others to >> take this up. >> > >> > Thanks, >> > David >> > >> >> Thanks, >> >> -- Igor >> >>> On Aug 20, 2018, at 11:07 PM, Igor Ignatyev > > wrote: >> >>> >> >>>>> It has been discussed (not widely enough and I accept that) in >> 8209547 and the related email thread b/w JC(cc'ed) and myself. >> >>>>> as I said, I might went a way too far, so I'll revert changes in >> the non-vmTestbase tests and made appropriate changes in makefiles. what do >> you think? >> >>>> >> >>>> I think I need to see what you mean exactly :) >> >>> sure, it will take some time for me to do that, hopefully will upload >> new webrevs tomorrow morning PT. but the basic idea is to leave files in >> test/hotspot/jtreg/compiler, runtime, gc, native_sanity, serviceability, >> testlibrary as .c files, exactly as they were before, and restore >> corresponding filenames in make/test/JtregNativeHotspot.gmk. >> >> > > -- > > Thanks, > Jc > > > -- Thanks, Jc From Zhongwei.Yao at arm.com Thu Aug 23 01:39:27 2018 From: Zhongwei.Yao at arm.com (Zhongwei Yao) Date: Thu, 23 Aug 2018 01:39:27 +0000 Subject: Fw: Where to find the 3rd party libraries used by --with-graalunit-lib In-Reply-To: References: Message-ID: Hi, all, could you point out where to find the graalunit-lib path? -- Best regards, Zhongwei ________________________________________ From: Zhongwei Yao Sent: Tuesday, August 21, 2018 6:56 PM To: build-dev at openjdk.java.net Cc: nd Subject: Where to find the 3rd party libraries used by --with-graalunit-lib Hi, all, To run Graal unit test included in OpenJDK's jtreg tests, I need to add "-with-graalunit-lib" to specify the graalunit-lib path. But I can't find where I can get such libs. Could you point me to where or how to get them? Thanks! -- Best regards, Zhongwei From ekaterina.pavlova at oracle.com Thu Aug 23 05:49:56 2018 From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova) Date: Wed, 22 Aug 2018 22:49:56 -0700 Subject: Fw: Where to find the 3rd party libraries used by --with-graalunit-lib In-Reply-To: References: Message-ID: Hi Zhongwei, Please see test/hotspot/jtreg/compiler/graalunit/README.md Regards, -katya On 8/22/18 6:39 PM, Zhongwei Yao wrote: > Hi, all, could you point out where to find the graalunit-lib path? > > -- > Best regards, > Zhongwei > > ________________________________________ > From: Zhongwei Yao > Sent: Tuesday, August 21, 2018 6:56 PM > To: build-dev at openjdk.java.net > Cc: nd > Subject: Where to find the 3rd party libraries used by --with-graalunit-lib > > Hi, all, > > To run Graal unit test included in OpenJDK's jtreg tests, I need to add "-with-graalunit-lib" to specify the graalunit-lib path. But I can't find where I can get such libs. Could you point me to where or how to get them? Thanks! > > -- > Best regards, > Zhongwei > From Zhongwei.Yao at arm.com Thu Aug 23 07:04:39 2018 From: Zhongwei.Yao at arm.com (Zhongwei Yao) Date: Thu, 23 Aug 2018 07:04:39 +0000 Subject: Fw: Where to find the 3rd party libraries used by --with-graalunit-lib In-Reply-To: References: , Message-ID: Ekaterina, Thanks! -- Best regards, Zhongwei ________________________________________ From: Ekaterina Pavlova Sent: Thursday, August 23, 2018 1:49:56 PM To: Zhongwei Yao; hotspot-dev; graal-dev at openjdk.java.net Cc: nd Subject: Re: Fw: Where to find the 3rd party libraries used by --with-graalunit-lib Hi Zhongwei, Please see test/hotspot/jtreg/compiler/graalunit/README.md Regards, -katya On 8/22/18 6:39 PM, Zhongwei Yao wrote: > Hi, all, could you point out where to find the graalunit-lib path? > > -- > Best regards, > Zhongwei > > ________________________________________ > From: Zhongwei Yao > Sent: Tuesday, August 21, 2018 6:56 PM > To: build-dev at openjdk.java.net > Cc: nd > Subject: Where to find the 3rd party libraries used by --with-graalunit-lib > > Hi, all, > > To run Graal unit test included in OpenJDK's jtreg tests, I need to add "-with-graalunit-lib" to specify the graalunit-lib path. But I can't find where I can get such libs. Could you point me to where or how to get them? Thanks! > > -- > Best regards, > Zhongwei > From robbin.ehn at oracle.com Thu Aug 23 07:17:13 2018 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Thu, 23 Aug 2018 09:17:13 +0200 Subject: RFR: 8209850: Allow NamedThreads to use GlobalCounter critical sections In-Reply-To: <52917853-9C79-4C3D-8811-389DB3A4CD6C@oracle.com> References: <52917853-9C79-4C3D-8811-389DB3A4CD6C@oracle.com> Message-ID: <31b313e2-54d5-2a0a-a91d-b0f3b81924a2@oracle.com> Great stuff, thanks Kim! But I strongly suggest keeping the three volatiles in SingleWriterSynchronizer on separate cache-lines. Specially _enter and _exit. I don't expect many of these and so I don't care about footprint. Am I wrong? Thanks, Robbin On 2018-08-22 21:18, Kim Barrett wrote: > Please review this change to GlobalCounter, permitting NamedThreads to > enter a critical section. > > To accomplish this, we add a new RCU-inspired synchronization utility, > SingleWriterSynchronizer. This has some similarities to > GlobalCounter, but the latter should be preferred except where it > can't be used (such as in the implementation of GlobalCounter!). This > utility is based on a private utility embedded in OopStorage. That > private utility is being replaced by the new public one. > > Using this new synchronization utility, we provide lock-free iteration > over the list of NamedThreads that is safe against creation and > deletion of such threads. That iteration is used by GlobalCounter to > examine all NamedThreads, rather than only the VMThread. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8209850 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8209850/open.00/ > > Testing: > mach5 tier1-3, hs-tier4-5. > New synchronization utility includes a gtest. > From erik.osterlund at oracle.com Thu Aug 23 10:22:00 2018 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Thu, 23 Aug 2018 12:22:00 +0200 Subject: RFR: 8209850: Allow NamedThreads to use GlobalCounter critical sections In-Reply-To: <52917853-9C79-4C3D-8811-389DB3A4CD6C@oracle.com> References: <52917853-9C79-4C3D-8811-389DB3A4CD6C@oracle.com> Message-ID: <5B7E8AC8.3040205@oracle.com> Hi Kim, Looks good for me. Thank you for sorting this out. /Erik On 2018-08-22 21:18, Kim Barrett wrote: > Please review this change to GlobalCounter, permitting NamedThreads to > enter a critical section. > > To accomplish this, we add a new RCU-inspired synchronization utility, > SingleWriterSynchronizer. This has some similarities to > GlobalCounter, but the latter should be preferred except where it > can't be used (such as in the implementation of GlobalCounter!). This > utility is based on a private utility embedded in OopStorage. That > private utility is being replaced by the new public one. > > Using this new synchronization utility, we provide lock-free iteration > over the list of NamedThreads that is safe against creation and > deletion of such threads. That iteration is used by GlobalCounter to > examine all NamedThreads, rather than only the VMThread. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8209850 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8209850/open.00/ > > Testing: > mach5 tier1-3, hs-tier4-5. > New synchronization utility includes a gtest. > From aleksei.voitylov at bell-sw.com Thu Aug 23 14:30:14 2018 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Thu, 23 Aug 2018 17:30:14 +0300 Subject: [12] RFR(S): 8209695: ARM: Explicit barriers for interpreter Message-ID: <3075f116-73cd-deb1-bb75-287101a3e5eb@bell-sw.com> Hi, please review this patch which adds explicit barriers for interpreter on ARM similar to how it was done on x86 and Aarch64: webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8209695.01/ issue: https://bugs.openjdk.java.net/browse/JDK-8209695 here is the issue where this functionality was added on x86 and Aarch64: https://bugs.openjdk.java.net/browse/JDK-8205523 Tested by running hotspot tests. Thanks, -Aleksei From aleksei.voitylov at bell-sw.com Thu Aug 23 14:30:16 2018 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Thu, 23 Aug 2018 17:30:16 +0300 Subject: [12] RFR(S): 8209697: ARM: Explicit barriers for C1/assembler Message-ID: <0654c3fc-213c-a06f-d28e-7be1d1fcbe0b@bell-sw.com> Hi, please review this patch which adds explicit barriers for C1/assembler on ARM similar to how it was done on x86 and Aarch64: webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8209697.01/ issue: https://bugs.openjdk.java.net/browse/JDK-8209697 here is the issue where this functionality was added on x86 and Aarch64: https://bugs.openjdk.java.net/browse/JDK-8209668 Tested by running hotspot tests. Thanks, -Aleksei From bob.vandette at oracle.com Thu Aug 23 15:13:30 2018 From: bob.vandette at oracle.com (Bob Vandette) Date: Thu, 23 Aug 2018 11:13:30 -0400 Subject: RFC: JEP - One AArch64 Port, Not Two Message-ID: As a follow-on to the previous thread "ARM port consolidation? [1], please review and comment on this newly filed JEP that removes one of the two AArch64 ports from the JDK. JEP: https://bugs.openjdk.java.net/browse/JDK-8209093 Here?s a prototype of the changes that would be done under this JEP. http://cr.openjdk.java.net/~bobv/8209093/webrev.00 [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-June/032756.html Bob. From kim.barrett at oracle.com Thu Aug 23 18:27:51 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 23 Aug 2018 14:27:51 -0400 Subject: RFR: 8209850: Allow NamedThreads to use GlobalCounter critical sections In-Reply-To: <5B7E8AC8.3040205@oracle.com> References: <52917853-9C79-4C3D-8811-389DB3A4CD6C@oracle.com> <5B7E8AC8.3040205@oracle.com> Message-ID: <36D94085-439B-4194-A929-D2002FEDD7AA@oracle.com> > On Aug 23, 2018, at 6:22 AM, Erik ?sterlund wrote: > > Hi Kim, > > Looks good for me. Thank you for sorting this out. Thanks. > > /Erik > > On 2018-08-22 21:18, Kim Barrett wrote: >> Please review this change to GlobalCounter, permitting NamedThreads to >> enter a critical section. >> >> To accomplish this, we add a new RCU-inspired synchronization utility, >> SingleWriterSynchronizer. This has some similarities to >> GlobalCounter, but the latter should be preferred except where it >> can't be used (such as in the implementation of GlobalCounter!). This >> utility is based on a private utility embedded in OopStorage. That >> private utility is being replaced by the new public one. >> >> Using this new synchronization utility, we provide lock-free iteration >> over the list of NamedThreads that is safe against creation and >> deletion of such threads. That iteration is used by GlobalCounter to >> examine all NamedThreads, rather than only the VMThread. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8209850 >> >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8209850/open.00/ >> >> Testing: >> mach5 tier1-3, hs-tier4-5. >> New synchronization utility includes a gtest. From kim.barrett at oracle.com Thu Aug 23 18:39:24 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 23 Aug 2018 14:39:24 -0400 Subject: RFR: 8209850: Allow NamedThreads to use GlobalCounter critical sections In-Reply-To: <31b313e2-54d5-2a0a-a91d-b0f3b81924a2@oracle.com> References: <52917853-9C79-4C3D-8811-389DB3A4CD6C@oracle.com> <31b313e2-54d5-2a0a-a91d-b0f3b81924a2@oracle.com> Message-ID: > On Aug 23, 2018, at 3:17 AM, Robbin Ehn wrote: > > Great stuff, thanks Kim! > > But I strongly suggest keeping the three volatiles in SingleWriterSynchronizer on separate cache-lines. Specially _enter and _exit. I don't expect many of these and so I don't care about footprint. Am I wrong? I agree there aren't expected to be many of these. OTOH, those that we know about are not ultra performance critical either. So the uglification of the code to microoptimize it seems unnecessary to me. This can be revisited if present assumptions change and we have measurements to show it matters. > Thanks, Robbin > > On 2018-08-22 21:18, Kim Barrett wrote: >> Please review this change to GlobalCounter, permitting NamedThreads to >> enter a critical section. >> To accomplish this, we add a new RCU-inspired synchronization utility, >> SingleWriterSynchronizer. This has some similarities to >> GlobalCounter, but the latter should be preferred except where it >> can't be used (such as in the implementation of GlobalCounter!). This >> utility is based on a private utility embedded in OopStorage. That >> private utility is being replaced by the new public one. >> Using this new synchronization utility, we provide lock-free iteration >> over the list of NamedThreads that is safe against creation and >> deletion of such threads. That iteration is used by GlobalCounter to >> examine all NamedThreads, rather than only the VMThread. >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8209850 >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8209850/open.00/ >> Testing: >> mach5 tier1-3, hs-tier4-5. >> New synchronization utility includes a gtest. From shade at redhat.com Thu Aug 23 18:42:21 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 23 Aug 2018 20:42:21 +0200 Subject: RFR (XS) 8209911: More blob types in hs_err printout Message-ID: <0662874d-280c-03a0-fd06-b088dcb4df43@redhat.com> RFE: https://bugs.openjdk.java.net/browse/JDK-8209911 Patch: http://cr.openjdk.java.net/~shade/8209911/8209911.patch Little debugging/post-mortem convenience. These are all blob types that have is_*_blob() tests. These blobs do not seem to have too much useful metadata to print from them, printing out the blob type is enough for now. Testing: Linux/x86_64 build only Thanks, -Aleksey From mikael.vidstedt at oracle.com Thu Aug 23 21:34:29 2018 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 23 Aug 2018 14:34:29 -0700 Subject: RFR(XS): 8209915: Fix license headers Message-ID: Please review this small change which fixes the license headers in three files: src/hotspot/share/memory/metaspace/virtualSpaceList.cpp src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMethodDataAccessor.java src/jdk.jfr/share/classes/jdk/jfr/internal/OldObjectSample.java Bug: https://bugs.openjdk.java.net/browse/JDK-8209915 Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8209915/webrev.00/open/webrev/ Cheers, Mikael From vladimir.kozlov at oracle.com Thu Aug 23 21:41:24 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 23 Aug 2018 14:41:24 -0700 Subject: RFR(XS): 8209915: Fix license headers In-Reply-To: References: Message-ID: <5e9c6af8-fdb3-68eb-5e63-3ed8582de64f@oracle.com> Looks good. Thanks, Vladimir On 8/23/18 2:34 PM, Mikael Vidstedt wrote: > > Please review this small change which fixes the license headers in three files: > > src/hotspot/share/memory/metaspace/virtualSpaceList.cpp > src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMethodDataAccessor.java > src/jdk.jfr/share/classes/jdk/jfr/internal/OldObjectSample.java > > Bug: https://bugs.openjdk.java.net/browse/JDK-8209915 > Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8209915/webrev.00/open/webrev/ > > Cheers, > Mikael > From jason.greene at redhat.com Mon Aug 20 15:14:11 2018 From: jason.greene at redhat.com (Jason Greene) Date: Mon, 20 Aug 2018 10:14:11 -0500 Subject: Is returning a value != '0' or '1' as jboolean from a JNI function legal? In-Reply-To: References: <130e0b86-e41f-fda7-5a6f-03b2135a9a60@redhat.com> Message-ID: <478E59AB-0EF6-4954-9A10-E3A742A0A081@redhat.com> > On Aug 20, 2018, at 9:55 AM, Aleksey Shipilev wrote: > > On 08/20/2018 12:22 PM, Volker Simonis wrote: >> So to summarize, my current view on this topic is: >> - JNI functions returning a jboolean are only allowed to return >> JNI_TRUE/JNI_FALSE (or 1/0) according to the current JNI spcification. > > Now *I* am having trouble seeing where exactly the JNI spec says the domain of jboolean is > (JNI_FALSE, JNI_TRUE). In "Primitive Types" [1] it says "The following definition is provided for > convenience: JNI_FALSE, JNI_TRUE", but that does not restrict the domain, because those are > "convenience" defines. And "Description" in the table says jboolean is "unsigned 8 bits", which > seems to invite interpretation that all 8 bits are usable. > > John says [2]: > > "The JNI documents specify that, at least for returning values from native methods, a Java boolean > (T_BOOLEAN) value is converted to the value-set 0..1 by first truncating to a byte (0..255 or maybe > -128..127) and then testing against zero." > > ...which is what I am looking for, but I cannot find the "JNI document" that actually says that. I > can see the idea of that in JVMS [3], but that seems to only apply to on-heap booleans, does that > also extend to jboolean's? Maybe John can point out the JNI document where it is said explicitly? IMO departing from C semantics (non-zero = TRUE, zero = false) offers little gain and will likely just lead to hard to catch bugs. Even if the JNI developer knows the rules, it will be quite easy for surprises to show up. For example, a developer might assume a library call always returns 1, and wire it straight to a boolean. If this assumption is broken (a condition not taken into account, or future behavioral differences), then it could quickly turn into a lot of wasted time and effort. The only way to deal with it is to safeguard every call with a conversion macro/function, and it?s easy to envision that being forgotten. -Jason From erik.joelsson at oracle.com Fri Aug 24 06:31:25 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 23 Aug 2018 23:31:25 -0700 Subject: RFR(M/L) : 8209611 : use C++ compiler for hotspot tests In-Reply-To: <92CD42CC-568A-4972-A35E-469B1532B103@oracle.com> References: <92CD42CC-568A-4972-A35E-469B1532B103@oracle.com> Message-ID: Hello Igor, In TestFilesCompilation.gmk, there is no need to duplicate the whole macro call. If you want to find .cpp as well as .c files, just add that to the one list of files. The SetupNativeCompilation macro will automatically treat .c and .cpp correctly. Regarding the .c/.cpp files for your vmtestbase tests that include all the other files, this is an unfortunate solution, but I guess OK if it works. We certainly didn't intend it that way. The macro SetupTestFilesCompilation was intended for easily writing single file native exe and lib binaries without having to modify any makefile. The expectation was that if anything more complicated was needed (like multiple files per binary), we would just write explicit SetupNativeCompilation calls for them in JtregNativeHotspot.gmk. It now looks like we have a new pattern of source files/directories that turns into native libraries, and we could of course create a new macro that automatically generates compilation setups for them as well (given that file or directory names makes it possible to automatically determine everything needed). Of course, that change would be a separate cleanup possible if you want to. /Erik On 2018-08-20 15:59, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8209611/webrev.01/index.html >> 11160 lines changed: 879 ins; 61 del; 10220 mod; > Hi all, > > could you please review the patch which moves all hotspot native test code to C++? this will guarantee that we always use C++ compilers for them (as an opposite to either C or C++ compiler depending on configuration), as a result we will be able to get rid of JNI_ENV_ARG[1] macros, perform other clean ups and improve overall quality of the test code. > > the patch consists of two parts: > - automatic: renaming .c files to .cpp, updating #include, changing JNI/JVMTI calls > - semi-manual: adding extern "C" , fixing a number of compiler warnings (mostly types inconsistency), updating makefiles > > JBS: https://bugs.openjdk.java.net/browse/JDK-8209611 > webrevs: > - automatic: http://cr.openjdk.java.net/~iignatyev//8209611/webrev.00/index.html >> 9394 lines changed: 0 ins; 0 del; 9394 mod; > - semi-manual: http://cr.openjdk.java.net/~iignatyev//8209611/webrev.0-1/index.html >> 1899 lines changed: 879 ins; 61 del; 959 mod > - whole: http://cr.openjdk.java.net/~iignatyev//8209611/webrev.01/index.html >> 11160 lines changed: 879 ins; 61 del; 10220 mod; > testing: all hotspot tests + tier[1-3] > > [1] https://bugs.openjdk.java.net/browse/JDK-8209547 > > Thanks, > -- Igor From per.liden at oracle.com Fri Aug 24 06:34:38 2018 From: per.liden at oracle.com (Per Liden) Date: Fri, 24 Aug 2018 08:34:38 +0200 Subject: RFR(XS): 8209915: Fix license headers In-Reply-To: References: Message-ID: <74d13d70-09ae-357b-9ba9-3feb5ddac924@oracle.com> On 08/23/2018 11:34 PM, Mikael Vidstedt wrote: > > Please review this small change which fixes the license headers in three files: > > src/hotspot/share/memory/metaspace/virtualSpaceList.cpp > src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMethodDataAccessor.java > src/jdk.jfr/share/classes/jdk/jfr/internal/OldObjectSample.java > > Bug: https://bugs.openjdk.java.net/browse/JDK-8209915 > Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8209915/webrev.00/open/webrev/ Looks good. I guess it a space between line 22 and 23 in HotSpotMethodDataAccessor.java wouldn't hurt, but I don't need to see a new webrev for that. /Per From robbin.ehn at oracle.com Fri Aug 24 09:33:49 2018 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Fri, 24 Aug 2018 11:33:49 +0200 Subject: RFR: 8209850: Allow NamedThreads to use GlobalCounter critical sections In-Reply-To: References: <52917853-9C79-4C3D-8811-389DB3A4CD6C@oracle.com> <31b313e2-54d5-2a0a-a91d-b0f3b81924a2@oracle.com> Message-ID: <4c88fb70-466f-638e-5f54-ba8c33d49477@oracle.com> On 08/23/2018 08:39 PM, Kim Barrett wrote: >> On Aug 23, 2018, at 3:17 AM, Robbin Ehn wrote: >> >> Great stuff, thanks Kim! >> >> But I strongly suggest keeping the three volatiles in SingleWriterSynchronizer on separate cache-lines. Specially _enter and _exit. I don't expect many of these and so I don't care about footprint. Am I wrong? > > I agree there aren't expected to be many of these. OTOH, those that > we know about are not ultra performance critical either. So the > uglification of the code to microoptimize it seems unnecessary to me. > This can be revisited if present assumptions change and we have > measurements to show it matters. Ok /Robbin > >> Thanks, Robbin >> >> On 2018-08-22 21:18, Kim Barrett wrote: >>> Please review this change to GlobalCounter, permitting NamedThreads to >>> enter a critical section. >>> To accomplish this, we add a new RCU-inspired synchronization utility, >>> SingleWriterSynchronizer. This has some similarities to >>> GlobalCounter, but the latter should be preferred except where it >>> can't be used (such as in the implementation of GlobalCounter!). This >>> utility is based on a private utility embedded in OopStorage. That >>> private utility is being replaced by the new public one. >>> Using this new synchronization utility, we provide lock-free iteration >>> over the list of NamedThreads that is safe against creation and >>> deletion of such threads. That iteration is used by GlobalCounter to >>> examine all NamedThreads, rather than only the VMThread. >>> CR: >>> https://bugs.openjdk.java.net/browse/JDK-8209850 >>> Webrev: >>> http://cr.openjdk.java.net/~kbarrett/8209850/open.00/ >>> Testing: >>> mach5 tier1-3, hs-tier4-5. >>> New synchronization utility includes a gtest. > > From volker.simonis at gmail.com Fri Aug 24 13:31:00 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 24 Aug 2018 15:31:00 +0200 Subject: RFR (XS) 8209911: More blob types in hs_err printout In-Reply-To: <0662874d-280c-03a0-fd06-b088dcb4df43@redhat.com> References: <0662874d-280c-03a0-fd06-b088dcb4df43@redhat.com> Message-ID: Hi Aleksey, looks good! We already had some of your extensions in SAP JVM and it's good too finally see this fixed up-stream :) Regards, Volker On Thu, Aug 23, 2018 at 8:42 PM, Aleksey Shipilev wrote: > RFE: > https://bugs.openjdk.java.net/browse/JDK-8209911 > > Patch: > http://cr.openjdk.java.net/~shade/8209911/8209911.patch > > Little debugging/post-mortem convenience. These are all blob types that have is_*_blob() tests. > These blobs do not seem to have too much useful metadata to print from them, printing out the blob > type is enough for now. > > Testing: Linux/x86_64 build only > > Thanks, > -Aleksey > From shade at redhat.com Fri Aug 24 16:52:29 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 24 Aug 2018 18:52:29 +0200 Subject: RFR (XS) 8209911: More blob types in hs_err printout In-Reply-To: References: <0662874d-280c-03a0-fd06-b088dcb4df43@redhat.com> Message-ID: On 08/24/2018 03:31 PM, Volker Simonis wrote: > looks good! We already had some of your extensions in SAP JVM and it's > good too finally see this fixed up-stream :) Thanks for review! Do you have anything printing from those blobs in SAP JVM? -Aleksey From vladimir.kozlov at oracle.com Fri Aug 24 17:06:32 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 24 Aug 2018 10:06:32 -0700 Subject: RFR (XS) 8209911: More blob types in hs_err printout In-Reply-To: <0662874d-280c-03a0-fd06-b088dcb4df43@redhat.com> References: <0662874d-280c-03a0-fd06-b088dcb4df43@redhat.com> Message-ID: Looks good. thanks, Vladimir On 8/23/18 11:42 AM, Aleksey Shipilev wrote: > RFE: > https://bugs.openjdk.java.net/browse/JDK-8209911 > > Patch: > http://cr.openjdk.java.net/~shade/8209911/8209911.patch > > Little debugging/post-mortem convenience. These are all blob types that have is_*_blob() tests. > These blobs do not seem to have too much useful metadata to print from them, printing out the blob > type is enough for now. > > Testing: Linux/x86_64 build only > > Thanks, > -Aleksey > From shade at redhat.com Fri Aug 24 17:18:06 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 24 Aug 2018 19:18:06 +0200 Subject: RFR (XS) 8209911: More blob types in hs_err printout In-Reply-To: References: <0662874d-280c-03a0-fd06-b088dcb4df43@redhat.com> Message-ID: <4bd8cdbc-0057-03ed-8286-7a0e0d566967@redhat.com> Thanks! Actually, I looked at it again and wondered why the COMPILER2 block there. The UncommonTrapBlob itself is ifdef-ed by COMPILER2, but the is_uncommon_trap_blob() is pretty much available. So we can simplify this to: diff -r 76a51e26d0ac src/hotspot/share/runtime/frame.cpp --- a/src/hotspot/share/runtime/frame.cpp Fri Aug 17 17:13:12 2018 +0200 +++ b/src/hotspot/share/runtime/frame.cpp Fri Aug 24 19:15:45 2018 +0200 @@ -719,10 +719,18 @@ st->print("v ~DeoptimizationBlob"); } else if (_cb->is_exception_stub()) { st->print("v ~ExceptionBlob"); } else if (_cb->is_safepoint_stub()) { st->print("v ~SafepointBlob"); + } else if (_cb->is_adapter_blob()) { + st->print("v ~AdapterBlob"); + } else if (_cb->is_vtable_blob()) { + st->print("v ~VtableBlob"); + } else if (_cb->is_method_handles_adapter_blob()) { + st->print("v ~MethodHandlesAdapterBlob"); + } else if (_cb->is_uncommon_trap_stub()) { + st->print("v ~UncommonTrapBlob"); } else { st->print("v blob " PTR_FORMAT, p2i(pc())); } } else { print_C_frame(st, buf, buflen, pc()); Thanks, -Aleksey On 08/24/2018 07:06 PM, Vladimir Kozlov wrote: > Looks good. > > thanks, > Vladimir > > On 8/23/18 11:42 AM, Aleksey Shipilev wrote: >> RFE: >> ?? https://bugs.openjdk.java.net/browse/JDK-8209911 >> >> Patch: >> ?? http://cr.openjdk.java.net/~shade/8209911/8209911.patch >> >> Little debugging/post-mortem convenience. These are all blob types that have is_*_blob() tests. >> These blobs do not seem to have too much useful metadata to print from them, printing out the blob >> type is enough for now. >> >> Testing: Linux/x86_64 build only >> >> Thanks, >> -Aleksey >> From igor.ignatyev at oracle.com Fri Aug 24 17:36:50 2018 From: igor.ignatyev at oracle.com (Igor Ignatev) Date: Fri, 24 Aug 2018 10:36:50 -0700 Subject: RFR(M/L) : 8209611 : use C++ compiler for hotspot tests In-Reply-To: References: <92CD42CC-568A-4972-A35E-469B1532B103@oracle.com> Message-ID: <90CA133B-CD6E-4F08-9A37-BA716092CD2A@oracle.com> Hi Erik, Unfortunately, just adding .cpp files to file list isn?t enough, as I mentioned in one of my previous emails[1], initially I did exactly that and linux-slowdebug build fails b/c c-linker was be used for .o files produced by cpp-compiler. I guess something like [2] might work. I'll play w/ this idea and send final patch latch. ? Igor [1] http://mail.openjdk.java.net/pipermail/build-dev/2018-August/022922.html [2] TOOLCHAIN := $(if $$(filter %.cpp, $$(file)), TOOLCHAIN_LINK_CXX, TOOLCHAIN_DEFAULT) > On Aug 23, 2018, at 11:31 PM, Erik Joelsson wrote: > > Hello Igor, > > In TestFilesCompilation.gmk, there is no need to duplicate the whole macro call. If you want to find .cpp as well as .c files, just add that to the one list of files. The SetupNativeCompilation macro will automatically treat .c and .cpp correctly. > > Regarding the .c/.cpp files for your vmtestbase tests that include all the other files, this is an unfortunate solution, but I guess OK if it works. We certainly didn't intend it that way. The macro SetupTestFilesCompilation was intended for easily writing single file native exe and lib binaries without having to modify any makefile. The expectation was that if anything more complicated was needed (like multiple files per binary), we would just write explicit SetupNativeCompilation calls for them in JtregNativeHotspot.gmk. It now looks like we have a new pattern of source files/directories that turns into native libraries, and we could of course create a new macro that automatically generates compilation setups for them as well (given that file or directory names makes it possible to automatically determine everything needed). Of course, that change would be a separate cleanup possible if you want to. > > /Erik > >> On 2018-08-20 15:59, Igor Ignatyev wrote: >> http://cr.openjdk.java.net/~iignatyev//8209611/webrev.01/index.html >>> 11160 lines changed: 879 ins; 61 del; 10220 mod; >> Hi all, >> >> could you please review the patch which moves all hotspot native test code to C++? this will guarantee that we always use C++ compilers for them (as an opposite to either C or C++ compiler depending on configuration), as a result we will be able to get rid of JNI_ENV_ARG[1] macros, perform other clean ups and improve overall quality of the test code. >> >> the patch consists of two parts: >> - automatic: renaming .c files to .cpp, updating #include, changing JNI/JVMTI calls >> - semi-manual: adding extern "C" , fixing a number of compiler warnings (mostly types inconsistency), updating makefiles >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8209611 >> webrevs: >> - automatic: http://cr.openjdk.java.net/~iignatyev//8209611/webrev.00/index.html >>> 9394 lines changed: 0 ins; 0 del; 9394 mod; >> - semi-manual: http://cr.openjdk.java.net/~iignatyev//8209611/webrev.0-1/index.html >>> 1899 lines changed: 879 ins; 61 del; 959 mod >> - whole: http://cr.openjdk.java.net/~iignatyev//8209611/webrev.01/index.html >>> 11160 lines changed: 879 ins; 61 del; 10220 mod; >> testing: all hotspot tests + tier[1-3] >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8209547 >> >> Thanks, >> -- Igor > From mikael.vidstedt at oracle.com Fri Aug 24 18:15:21 2018 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 24 Aug 2018 11:15:21 -0700 Subject: RFR(XS): 8209915: Fix license headers In-Reply-To: <74d13d70-09ae-357b-9ba9-3feb5ddac924@oracle.com> References: <74d13d70-09ae-357b-9ba9-3feb5ddac924@oracle.com> Message-ID: > On Aug 23, 2018, at 11:34 PM, Per Liden wrote: > > On 08/23/2018 11:34 PM, Mikael Vidstedt wrote: >> Please review this small change which fixes the license headers in three files: >> src/hotspot/share/memory/metaspace/virtualSpaceList.cpp >> src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMethodDataAccessor.java >> src/jdk.jfr/share/classes/jdk/jfr/internal/OldObjectSample.java >> Bug: https://bugs.openjdk.java.net/browse/JDK-8209915 >> Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8209915/webrev.00/open/webrev/ > > Looks good. > > I guess it a space between line 22 and 23 in HotSpotMethodDataAccessor.java wouldn't hurt, but I don't need to see a new webrev for that. Vladimir/Per, thanks for the reviews! I actually did add en empty line after the license header in HotSpotMethodDataAccessor.java at first, but then I noticed that all the other files in that directory except one (src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/CompilerToVM.java) lack that empty line, so for consistency reasons I decided to not add it after all. Cheers, Mikael From vladimir.kozlov at oracle.com Fri Aug 24 18:33:34 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 24 Aug 2018 11:33:34 -0700 Subject: RFR(XS): 8209915: Fix license headers In-Reply-To: References: <74d13d70-09ae-357b-9ba9-3feb5ddac924@oracle.com> Message-ID: <85bf407e-44f7-d369-9c28-5824f689ab47@oracle.com> I don't know why this JVMCI file in OpenJDK don't have license header. Lab's version has it: https://github.com/graalvm/graal-jvmci-8/blob/master/jvmci/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMethodDataAccessor.java Doug, do you know? It also don't have empty line. Regards, Vladimir On 8/24/18 11:15 AM, Mikael Vidstedt wrote: > > >> On Aug 23, 2018, at 11:34 PM, Per Liden wrote: >> >> On 08/23/2018 11:34 PM, Mikael Vidstedt wrote: >>> Please review this small change which fixes the license headers in three files: >>> src/hotspot/share/memory/metaspace/virtualSpaceList.cpp >>> src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMethodDataAccessor.java >>> src/jdk.jfr/share/classes/jdk/jfr/internal/OldObjectSample.java >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8209915 >>> Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8209915/webrev.00/open/webrev/ >> >> Looks good. >> >> I guess it a space between line 22 and 23 in HotSpotMethodDataAccessor.java wouldn't hurt, but I don't need to see a new webrev for that. > > Vladimir/Per, thanks for the reviews! > > I actually did add en empty line after the license header in HotSpotMethodDataAccessor.java at first, but then I noticed that all the other files in that directory except one (src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/CompilerToVM.java) lack that empty line, so for consistency reasons I decided to not add it after all. > > Cheers, > Mikael > From igor.ignatyev at oracle.com Fri Aug 24 21:20:43 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 24 Aug 2018 14:20:43 -0700 Subject: RFR(M/L) : 8209611 : use C++ compiler for hotspot tests In-Reply-To: <90CA133B-CD6E-4F08-9A37-BA716092CD2A@oracle.com> References: <92CD42CC-568A-4972-A35E-469B1532B103@oracle.com> <90CA133B-CD6E-4F08-9A37-BA716092CD2A@oracle.com> Message-ID: <541E57B0-F215-4591-8991-93AF34956F4B@oracle.com> ok, it worked just fine, here is the final diff for TestFilesCompilation.gmk: > diff -r 028076b2832a -r caca95a834e3 make/common/TestFilesCompilation.gmk > --- a/make/common/TestFilesCompilation.gmk Thu Aug 16 16:28:03 2018 -0700 > +++ b/make/common/TestFilesCompilation.gmk Fri Aug 24 14:12:37 2018 -0700 > @@ -60,13 +60,13 @@ > ifeq ($$($1_TYPE), LIBRARY) > $1_PREFIX = lib > $1_OUTPUT_SUBDIR := lib > - $1_CFLAGS := $(CFLAGS_TESTLIB) > + $1_CFLAGS += $(CFLAGS_TESTLIB) > $1_LDFLAGS := $(LDFLAGS_TESTLIB) $(call SET_SHARED_LIBRARY_ORIGIN) > $1_COMPILATION_TYPE := LIBRARY > else ifeq ($$($1_TYPE), PROGRAM) > $1_PREFIX = exe > $1_OUTPUT_SUBDIR := bin > - $1_CFLAGS := $(CFLAGS_TESTEXE) > + $1_CFLAGS += $(CFLAGS_TESTEXE) > $1_LDFLAGS := $(LDFLAGS_TESTEXE) > $1_COMPILATION_TYPE := EXECUTABLE > else > @@ -75,12 +75,12 @@ > > # Locate all files with the matching prefix > $1_FILE_LIST := \ > - $$(shell $$(FIND) $$($1_SOURCE_DIRS) -type f -name "$$($1_PREFIX)*.c") > + $$(shell $$(FIND) $$($1_SOURCE_DIRS) -type f \( -name "$$($1_PREFIX)*.c" \ > + -o -name "$$($1_PREFIX)*.cpp" \)) > > $1_EXCLUDE_PATTERN := $$(addprefix %/, $$($1_EXCLUDE)) > $1_FILTERED_FILE_LIST := $$(filter-out $$($1_EXCLUDE_PATTERN), $$($1_FILE_LIST)) > > - # Setup a compilation for each and every one of them > $$(foreach file, $$($1_FILTERED_FILE_LIST),\ > $$(eval name := $$(strip $$(basename $$(notdir $$(file))))) \ > $$(eval unprefixed_name := $$(patsubst $$($1_PREFIX)%, %, $$(name))) \ > @@ -94,6 +94,7 @@ > CFLAGS := $$($1_CFLAGS) $$($1_CFLAGS_$$(name)), \ > LDFLAGS := $$($1_LDFLAGS) $$($1_LDFLAGS_$$(name)), \ > LIBS := $$($1_LIBS_$$(name)), \ > + TOOLCHAIN := $(if $$(filter %.cpp, $$(file)), TOOLCHAIN_LINK_CXX, TOOLCHAIN_DEFAULT), \ > OPTIMIZATION := LOW, \ > COPY_DEBUG_SYMBOLS := false, \ > STRIP_SYMBOLS := false, \ Thanks, -- Igor > On Aug 24, 2018, at 10:36 AM, Igor Ignatev wrote: > > Hi Erik, > > Unfortunately, just adding .cpp files to file list isn?t enough, as I mentioned in one of my previous emails[1], initially I did exactly that and linux-slowdebug build fails b/c c-linker was be used for .o files produced by cpp-compiler. > > I guess something like [2] might work. I'll play w/ this idea and send final patch latch. > > ? Igor > > [1] http://mail.openjdk.java.net/pipermail/build-dev/2018-August/022922.html > [2] TOOLCHAIN := $(if $$(filter %.cpp, $$(file)), TOOLCHAIN_LINK_CXX, TOOLCHAIN_DEFAULT) > >> On Aug 23, 2018, at 11:31 PM, Erik Joelsson wrote: >> >> Hello Igor, >> >> In TestFilesCompilation.gmk, there is no need to duplicate the whole macro call. If you want to find .cpp as well as .c files, just add that to the one list of files. The SetupNativeCompilation macro will automatically treat .c and .cpp correctly. >> >> Regarding the .c/.cpp files for your vmtestbase tests that include all the other files, this is an unfortunate solution, but I guess OK if it works. We certainly didn't intend it that way. The macro SetupTestFilesCompilation was intended for easily writing single file native exe and lib binaries without having to modify any makefile. The expectation was that if anything more complicated was needed (like multiple files per binary), we would just write explicit SetupNativeCompilation calls for them in JtregNativeHotspot.gmk. It now looks like we have a new pattern of source files/directories that turns into native libraries, and we could of course create a new macro that automatically generates compilation setups for them as well (given that file or directory names makes it possible to automatically determine everything needed). Of course, that change would be a separate cleanup possible if you want to. >> >> /Erik >> >>> On 2018-08-20 15:59, Igor Ignatyev wrote: >>> http://cr.openjdk.java.net/~iignatyev//8209611/webrev.01/index.html >>>> 11160 lines changed: 879 ins; 61 del; 10220 mod; >>> Hi all, >>> >>> could you please review the patch which moves all hotspot native test code to C++? this will guarantee that we always use C++ compilers for them (as an opposite to either C or C++ compiler depending on configuration), as a result we will be able to get rid of JNI_ENV_ARG[1] macros, perform other clean ups and improve overall quality of the test code. >>> >>> the patch consists of two parts: >>> - automatic: renaming .c files to .cpp, updating #include, changing JNI/JVMTI calls >>> - semi-manual: adding extern "C" , fixing a number of compiler warnings (mostly types inconsistency), updating makefiles >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8209611 >>> webrevs: >>> - automatic: http://cr.openjdk.java.net/~iignatyev//8209611/webrev.00/index.html >>>> 9394 lines changed: 0 ins; 0 del; 9394 mod; >>> - semi-manual: http://cr.openjdk.java.net/~iignatyev//8209611/webrev.0-1/index.html >>>> 1899 lines changed: 879 ins; 61 del; 959 mod >>> - whole: http://cr.openjdk.java.net/~iignatyev//8209611/webrev.01/index.html >>>> 11160 lines changed: 879 ins; 61 del; 10220 mod; >>> testing: all hotspot tests + tier[1-3] >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8209547 >>> >>> Thanks, >>> -- Igor >> From mikael.vidstedt at oracle.com Fri Aug 24 22:56:13 2018 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Fri, 24 Aug 2018 15:56:13 -0700 Subject: RFR(S): 8209856: Obsolete error reporter Message-ID: <3B34B6D9-C878-4E08-AD35-0459DD245755@oracle.com> Please review this change which removes the (stub, not-implemented) error reporter from hotspot, and obsoletes two flags which were meant to control its behavior: Bug: https://bugs.openjdk.java.net/browse/JDK-8209856 CSR: https://bugs.openjdk.java.net/browse/JDK-8209857 Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8209856/webrev.00/open/webrev/ Cheers, Mikael From volker.simonis at gmail.com Sat Aug 25 06:19:47 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Sat, 25 Aug 2018 08:19:47 +0200 Subject: RFR (XS) 8209911: More blob types in hs_err printout In-Reply-To: <4bd8cdbc-0057-03ed-8286-7a0e0d566967@redhat.com> References: <0662874d-280c-03a0-fd06-b088dcb4df43@redhat.com> <4bd8cdbc-0057-03ed-8286-7a0e0d566967@redhat.com> Message-ID: Still OK! As far as I can see we only printed the UncommonTraoBlob without the COMPILER2 block. Thanks, Volker Aleksey Shipilev schrieb am Fr. 24. Aug. 2018 um 19:18: > Thanks! > > Actually, I looked at it again and wondered why the COMPILER2 block there. > The UncommonTrapBlob > itself is ifdef-ed by COMPILER2, but the is_uncommon_trap_blob() is pretty > much available. So we can > simplify this to: > > diff -r 76a51e26d0ac src/hotspot/share/runtime/frame.cpp > --- a/src/hotspot/share/runtime/frame.cpp Fri Aug 17 17:13:12 2018 > +0200 > +++ b/src/hotspot/share/runtime/frame.cpp Fri Aug 24 19:15:45 2018 > +0200 > @@ -719,10 +719,18 @@ > st->print("v ~DeoptimizationBlob"); > } else if (_cb->is_exception_stub()) { > st->print("v ~ExceptionBlob"); > } else if (_cb->is_safepoint_stub()) { > st->print("v ~SafepointBlob"); > + } else if (_cb->is_adapter_blob()) { > + st->print("v ~AdapterBlob"); > + } else if (_cb->is_vtable_blob()) { > + st->print("v ~VtableBlob"); > + } else if (_cb->is_method_handles_adapter_blob()) { > + st->print("v ~MethodHandlesAdapterBlob"); > + } else if (_cb->is_uncommon_trap_stub()) { > + st->print("v ~UncommonTrapBlob"); > } else { > st->print("v blob " PTR_FORMAT, p2i(pc())); > } > } else { > print_C_frame(st, buf, buflen, pc()); > > Thanks, > -Aleksey > > On 08/24/2018 07:06 PM, Vladimir Kozlov wrote: > > Looks good. > > > > thanks, > > Vladimir > > > > On 8/23/18 11:42 AM, Aleksey Shipilev wrote: > >> RFE: > >> https://bugs.openjdk.java.net/browse/JDK-8209911 > >> > >> Patch: > >> http://cr.openjdk.java.net/~shade/8209911/8209911.patch > >> > >> Little debugging/post-mortem convenience. These are all blob types that > have is_*_blob() tests. > >> These blobs do not seem to have too much useful metadata to print from > them, printing out the blob > >> type is enough for now. > >> > >> Testing: Linux/x86_64 build only > >> > >> Thanks, > >> -Aleksey > >> > > > From doug.simon at oracle.com Sat Aug 25 06:28:26 2018 From: doug.simon at oracle.com (Doug Simon) Date: Sat, 25 Aug 2018 08:28:26 +0200 Subject: RFR(XS): 8209915: Fix license headers In-Reply-To: <85bf407e-44f7-d369-9c28-5824f689ab47@oracle.com> References: <74d13d70-09ae-357b-9ba9-3feb5ddac924@oracle.com> <85bf407e-44f7-d369-9c28-5824f689ab47@oracle.com> Message-ID: <68945E72-154F-495F-BC21-218DFA59F207@oracle.com> > On 24 Aug 2018, at 20:33, Vladimir Kozlov wrote: > > I don't know why this JVMCI file in OpenJDK don't have license header. Lab's version has it: > > https://github.com/graalvm/graal-jvmci-8/blob/master/jvmci/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMethodDataAccessor.java > > Doug, do you know? No, sorry. -Doug > > It also don't have empty line. > > Regards, > Vladimir > > On 8/24/18 11:15 AM, Mikael Vidstedt wrote: >>> On Aug 23, 2018, at 11:34 PM, Per Liden wrote: >>> >>> On 08/23/2018 11:34 PM, Mikael Vidstedt wrote: >>>> Please review this small change which fixes the license headers in three files: >>>> src/hotspot/share/memory/metaspace/virtualSpaceList.cpp >>>> src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotMethodDataAccessor.java >>>> src/jdk.jfr/share/classes/jdk/jfr/internal/OldObjectSample.java >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8209915 >>>> Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8209915/webrev.00/open/webrev/ >>> >>> Looks good. >>> >>> I guess it a space between line 22 and 23 in HotSpotMethodDataAccessor.java wouldn't hurt, but I don't need to see a new webrev for that. >> Vladimir/Per, thanks for the reviews! >> I actually did add en empty line after the license header in HotSpotMethodDataAccessor.java at first, but then I noticed that all the other files in that directory except one (src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/CompilerToVM.java) lack that empty line, so for consistency reasons I decided to not add it after all. >> Cheers, >> Mikael From coleen.phillimore at oracle.com Sat Aug 25 15:33:26 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Sat, 25 Aug 2018 11:33:26 -0400 Subject: RFR(S): 8209856: Obsolete error reporter In-Reply-To: <3B34B6D9-C878-4E08-AD35-0459DD245755@oracle.com> References: <3B34B6D9-C878-4E08-AD35-0459DD245755@oracle.com> Message-ID: <4a93e2e1-3ecc-3f76-a3c4-316a3ac072fd@oracle.com> This looks good to me. Coleen On 8/24/18 6:56 PM, Mikael Vidstedt wrote: > Please review this change which removes the (stub, not-implemented) error reporter from hotspot, and obsoletes two flags which were meant to control its behavior: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8209856 > CSR: https://bugs.openjdk.java.net/browse/JDK-8209857 > Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8209856/webrev.00/open/webrev/ > > Cheers, > Mikael > From vladimir.kozlov at oracle.com Sat Aug 25 20:05:32 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Sat, 25 Aug 2018 13:05:32 -0700 Subject: [12] RFR(M) 8209594: guarantee(this->is8bit(imm8)) failed: Short forward jump exceeds 8-bit offset Message-ID: http://cr.openjdk.java.net/~kvn/8209594/webrev.05/ https://bugs.openjdk.java.net/browse/JDK-8209594 All platforms are affected. Please, test. I instrumented code to generated biggest code and find all possible incorrect short jumps. This is the result. Changed jump instruction patching API to added jump's source location in debug build but implemented it only on x86. I tired to search instructions by code offsets. I used very simple macro: #define jmpb(L) jmpb_0(L, __FILE__, __LINE__) 'do {} while(0)' does not work here because I need to replace non-static method. I will be glad if someone can give better suggestion how implement this macro. Fixed incorrect avx512 code in macroAssembler_x86.cpp and x86.ad file. There were missing instructions and incorrect instructions (copy-paste typos). Fixed C2 scratch buffer sizing. It did not take into account everything and as result from MAX_inst_size=1024 only 700 bytes were available. I hit this issue when RTM locking was generated for FastLock node. Tested tier1-3 on all our platforms. And also running these tiers on avx512 machine. -- Thanks, Vladimir From thomas.stuefe at gmail.com Sun Aug 26 06:22:10 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sun, 26 Aug 2018 08:22:10 +0200 Subject: RFR(S): 8209856: Obsolete error reporter In-Reply-To: <3B34B6D9-C878-4E08-AD35-0459DD245755@oracle.com> References: <3B34B6D9-C878-4E08-AD35-0459DD245755@oracle.com> Message-ID: Hi Mikael, this looks good to me too. I always wondered who was using it. Good to see it removed. Best Regards, Thomas On Sat, Aug 25, 2018 at 12:56 AM, Mikael Vidstedt wrote: > > Please review this change which removes the (stub, not-implemented) error reporter from hotspot, and obsoletes two flags which were meant to control its behavior: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8209856 > CSR: https://bugs.openjdk.java.net/browse/JDK-8209857 > Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8209856/webrev.00/open/webrev/ > > Cheers, > Mikael > From kim.barrett at oracle.com Sun Aug 26 23:09:29 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 26 Aug 2018 19:09:29 -0400 Subject: RFR: 8209976: Improve iteration over non-JavaThreads Message-ID: <5936CC9F-20A4-40CA-8256-3A52643899F5@oracle.com> Please review this change to improve the iteration over non-JavaThreads. This change introduces a new base class NonJavaThread, which should be a base for any Thread class that isn't a JavaThread. The recently introduced iteration over NamedThreads (JDK-8209850) is moved to this new class. This allows the re-implementation of Threads::non_java_threads_do using that list. Note: Perhaps CollectedHeap::gc_threads_do could be replaced by a Threads::gc_threads_do that is implemented as an iteration over the non-JavaThreads with a filter to select GC-related thread types. That isn't being done as part of this change though. CR: https://bugs.openjdk.java.net/browse/JDK-8209850 Webrev: http://cr.openjdk.java.net/~kbarrett/8209976/open.00/ Testing: mach5 tier1-3, hs-tier4-5 in conjunction with a fix for JDK-8209975. Local testing of just this change. From magnus.ihse.bursie at oracle.com Mon Aug 27 06:30:37 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 27 Aug 2018 08:30:37 +0200 Subject: [aarch64-port-dev ] RFC: JEP - One AArch64 Port, Not Two In-Reply-To: References: Message-ID: <8cb976e5-80f7-8905-63aa-c658454a8673@oracle.com> On 2018-08-23 17:13, Bob Vandette wrote: > As a follow-on to the previous thread "ARM port consolidation? [1], > please review and comment on this newly filed JEP that removes > one of the two AArch64 ports from the JDK. > > JEP: > > https://bugs.openjdk.java.net/browse/JDK-8209093 Looks good! (Or as we say in Sweden: ?ntligen! :-)) One question: I remember there were some guys from Linaro who compared aarch64 vs arm64 in microbenchmarks, and found that while aarch64 had the superior performance most of the time, there were some benchmarks where arm64 was fastest. Has these been analyzed, and the performance on aarch64 brought in line with arm64? > Here?s a prototype of the changes that would be done under this JEP. > > http://cr.openjdk.java.net/~bobv/8209093/webrev.00 Generally looks good. I have not looked at too much detail since it's just a prototype, but I noted that you just removed --with-cpu-port, instead of deprecating it. That needs to be fixed for the real deal. /Magnus > > > [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-June/032756.html > > Bob. > > > > From erik.osterlund at oracle.com Mon Aug 27 08:01:16 2018 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Mon, 27 Aug 2018 10:01:16 +0200 Subject: RFR: 8209976: Improve iteration over non-JavaThreads In-Reply-To: <5936CC9F-20A4-40CA-8256-3A52643899F5@oracle.com> References: <5936CC9F-20A4-40CA-8256-3A52643899F5@oracle.com> Message-ID: <5B83AFCC.3070003@oracle.com> Hi Kim, Nice. Looks good. Thanks, /Erik On 2018-08-27 01:09, Kim Barrett wrote: > Please review this change to improve the iteration over > non-JavaThreads. This change introduces a new base class > NonJavaThread, which should be a base for any Thread class that isn't > a JavaThread. The recently introduced iteration over NamedThreads > (JDK-8209850) is moved to this new class. This allows the > re-implementation of Threads::non_java_threads_do using that list. > > Note: Perhaps CollectedHeap::gc_threads_do could be replaced by a > Threads::gc_threads_do that is implemented as an iteration over the > non-JavaThreads with a filter to select GC-related thread types. That > isn't being done as part of this change though. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8209850 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8209976/open.00/ > > Testing: > mach5 tier1-3, hs-tier4-5 in conjunction with a fix for JDK-8209975. > Local testing of just this change. > From aph at redhat.com Mon Aug 27 08:13:30 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 27 Aug 2018 09:13:30 +0100 Subject: [aarch64-port-dev ] RFC: JEP - One AArch64 Port, Not Two In-Reply-To: <8cb976e5-80f7-8905-63aa-c658454a8673@oracle.com> References: <8cb976e5-80f7-8905-63aa-c658454a8673@oracle.com> Message-ID: On 08/27/2018 07:30 AM, Magnus Ihse Bursie wrote: > One question: I remember there were some guys from Linaro who compared > aarch64 vs arm64 in microbenchmarks, and found that while aarch64 had > the superior performance most of the time, there were some benchmarks > where arm64 was fastest. > > Has these been analyzed, and the performance on aarch64 brought in line > with arm64? I doubt that's possible. As we know, JIT heuristics can sometimes go one way and then the other, and it can be just a matter of luck. I haven't seen any optimizations in the arm64 port that were absent in the aarch64 port. If anyone can find anything we'll port it over. Looking here https://docs.google.com/spreadsheets/d/18iklOrbaL67i46XHsPTrdTObWqUJJK8EO4-k0eqdLKM/edit#gid=909743165 we see that tradebeans is faster on one implementation, slower on another. sunflow is spectacularly better on arm64, but it failed to converge most of the time on one implementation, so I don't believe the result. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From kim.barrett at oracle.com Mon Aug 27 08:28:21 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 27 Aug 2018 04:28:21 -0400 Subject: RFR: 8209976: Improve iteration over non-JavaThreads In-Reply-To: <5B83AFCC.3070003@oracle.com> References: <5936CC9F-20A4-40CA-8256-3A52643899F5@oracle.com> <5B83AFCC.3070003@oracle.com> Message-ID: <128CBF8E-5E24-47E4-BAE6-E1FFF168182C@oracle.com> > On Aug 27, 2018, at 4:01 AM, Erik ?sterlund wrote: > > Hi Kim, > > Nice. Looks good. Thanks. > Thanks, > /Erik > > On 2018-08-27 01:09, Kim Barrett wrote: >> Please review this change to improve the iteration over >> non-JavaThreads. This change introduces a new base class >> NonJavaThread, which should be a base for any Thread class that isn't >> a JavaThread. The recently introduced iteration over NamedThreads >> (JDK-8209850) is moved to this new class. This allows the >> re-implementation of Threads::non_java_threads_do using that list. >> >> Note: Perhaps CollectedHeap::gc_threads_do could be replaced by a >> Threads::gc_threads_do that is implemented as an iteration over the >> non-JavaThreads with a filter to select GC-related thread types. That >> isn't being done as part of this change though. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8209850 >> >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8209976/open.00/ >> >> Testing: >> mach5 tier1-3, hs-tier4-5 in conjunction with a fix for JDK-8209975. >> Local testing of just this change. From ningsheng.jian at linaro.org Mon Aug 27 08:49:34 2018 From: ningsheng.jian at linaro.org (Ningsheng Jian) Date: Mon, 27 Aug 2018 16:49:34 +0800 Subject: [aarch64-port-dev ] RFC: JEP - One AArch64 Port, Not Two In-Reply-To: References: <8cb976e5-80f7-8905-63aa-c658454a8673@oracle.com> Message-ID: Hi, On 27 August 2018 at 16:13, Andrew Haley wrote: > On 08/27/2018 07:30 AM, Magnus Ihse Bursie wrote: >> One question: I remember there were some guys from Linaro who compared >> aarch64 vs arm64 in microbenchmarks, and found that while aarch64 had >> the superior performance most of the time, there were some benchmarks >> where arm64 was fastest. >> >> Has these been analyzed, and the performance on aarch64 brought in line >> with arm64? > > I doubt that's possible. As we know, JIT heuristics can sometimes go one > way and then the other, and it can be just a matter of luck. I haven't > seen any optimizations in the arm64 port that were absent in the aarch64 > port. If anyone can find anything we'll port it over. > > Looking here > > https://docs.google.com/spreadsheets/d/18iklOrbaL67i46XHsPTrdTObWqUJJK8EO4-k0eqdLKM/edit#gid=909743165 > > we see that tradebeans is faster on one implementation, slower on another. > sunflow is spectacularly better on arm64, but it failed to converge most > of the time on one implementation, so I don't believe the result. > Yes, some benchmark data is unstable. We did analyze the arm64 and aarch64 codegen difference with microbenchmarks. AArch64 backend generates better code on most cases, and I believe that we have addressed those minor worse cases we found. E.g. JDK-8183533, JDK-8185786, JDK-8187601. Thanks, Ningsheng From aph at redhat.com Mon Aug 27 09:00:03 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 27 Aug 2018 10:00:03 +0100 Subject: [aarch64-port-dev ] RFC: JEP - One AArch64 Port, Not Two In-Reply-To: References: <8cb976e5-80f7-8905-63aa-c658454a8673@oracle.com> Message-ID: On 08/27/2018 09:49 AM, Ningsheng Jian wrote: > Yes, some benchmark data is unstable. We did analyze the arm64 and > aarch64 codegen difference with microbenchmarks. AArch64 backend > generates better code on most cases, and I believe that we have > addressed those minor worse cases we found. E.g. JDK-8183533, > JDK-8185786, JDK-8187601. Mmm, and it's not really possible to show for sure that changes generalize well. I'm still not convinced by tweaks to unrolling, but they work spectacularly well in some small benchmarks. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rkennke at redhat.com Mon Aug 27 09:22:11 2018 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 27 Aug 2018 11:22:11 +0200 Subject: RFR: 8209976: Improve iteration over non-JavaThreads In-Reply-To: <5936CC9F-20A4-40CA-8256-3A52643899F5@oracle.com> References: <5936CC9F-20A4-40CA-8256-3A52643899F5@oracle.com> Message-ID: <17d9a7d5-0e1c-3413-7ffc-116b5b8103dd@redhat.com> Hi Kim, may I ask what is the motivation for this? How does it improve the situation? Thanks, Roman > Please review this change to improve the iteration over > non-JavaThreads. This change introduces a new base class > NonJavaThread, which should be a base for any Thread class that isn't > a JavaThread. The recently introduced iteration over NamedThreads > (JDK-8209850) is moved to this new class. This allows the > re-implementation of Threads::non_java_threads_do using that list. > > Note: Perhaps CollectedHeap::gc_threads_do could be replaced by a > Threads::gc_threads_do that is implemented as an iteration over the > non-JavaThreads with a filter to select GC-related thread types. That > isn't being done as part of this change though. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8209850 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8209976/open.00/ > > Testing: > mach5 tier1-3, hs-tier4-5 in conjunction with a fix for JDK-8209975. > Local testing of just this change. > From ningsheng.jian at linaro.org Mon Aug 27 09:24:31 2018 From: ningsheng.jian at linaro.org (Ningsheng Jian) Date: Mon, 27 Aug 2018 17:24:31 +0800 Subject: [aarch64-port-dev ] RFC: JEP - One AArch64 Port, Not Two In-Reply-To: References: <8cb976e5-80f7-8905-63aa-c658454a8673@oracle.com> Message-ID: On 27 August 2018 at 17:00, Andrew Haley wrote: > On 08/27/2018 09:49 AM, Ningsheng Jian wrote: >> Yes, some benchmark data is unstable. We did analyze the arm64 and >> aarch64 codegen difference with microbenchmarks. AArch64 backend >> generates better code on most cases, and I believe that we have >> addressed those minor worse cases we found. E.g. JDK-8183533, >> JDK-8185786, JDK-8187601. > > Mmm, and it's not really possible to show for sure that changes > generalize well. I'm still not convinced by tweaks to unrolling, > but they work spectacularly well in some small benchmarks. > I just searched our work log and found those items. At least they were exposed by microbenchmarks [1] we analyzed where arm64 performed better than AArch64. Yes, they are just small benchmarks. :-) [1] https://git.linaro.org/leg/openjdk/jmh-linaro-org.git Thanks, Ningsheng From swatibits14 at gmail.com Mon Aug 27 12:10:41 2018 From: swatibits14 at gmail.com (Swati Sharma) Date: Mon, 27 Aug 2018 17:40:41 +0530 Subject: JEP 163: Enable NUMA Mode by Default When Appropriate Message-ID: Hi All, I was going through this JEP 163: Enable NUMA Mode by Default When Appropriate(http://openjdk.java.net/jeps/163). Can we make UseNUMA flag by default ON after detecting that if process runs on multiple NUMA nodes.So after that user don't need to specify the UseNUMA flag and JVM will auto detect and switch ON the flag. Note : If we can then I can provide the implementaion for this JEP. Thanks and Regards, Swati Sharma Software Engineer -2 at AMD From bob.vandette at oracle.com Mon Aug 27 14:00:44 2018 From: bob.vandette at oracle.com (Bob Vandette) Date: Mon, 27 Aug 2018 10:00:44 -0400 Subject: [aarch64-port-dev ] RFC: JEP - One AArch64 Port, Not Two In-Reply-To: <8cb976e5-80f7-8905-63aa-c658454a8673@oracle.com> References: <8cb976e5-80f7-8905-63aa-c658454a8673@oracle.com> Message-ID: > On Aug 27, 2018, at 2:30 AM, Magnus Ihse Bursie wrote: > > On 2018-08-23 17:13, Bob Vandette wrote: >> As a follow-on to the previous thread "ARM port consolidation? [1], >> please review and comment on this newly filed JEP that removes >> one of the two AArch64 ports from the JDK. >> >> JEP: >> >> https://bugs.openjdk.java.net/browse/JDK-8209093 > Looks good! (Or as we say in Sweden: ?ntligen! :-)) > > One question: I remember there were some guys from Linaro who compared aarch64 vs arm64 in microbenchmarks, and found that while aarch64 had the superior performance most of the time, there were some benchmarks where arm64 was fastest. > > Has these been analyzed, and the performance on aarch64 brought in line with arm64? It looks like this question has been answered. > >> Here?s a prototype of the changes that would be done under this JEP. >> >> http://cr.openjdk.java.net/~bobv/8209093/webrev.00 > > Generally looks good. I have not looked at too much detail since it's just a prototype, but I noted that you just removed --with-cpu-port, instead of deprecating it. That needs to be fixed for the real deal. What?s the process for deprecation of build options? Do I just change the help text and have the arm64 option select the aarch64 port? Thanks, Bob. > > /Magnus > > > >> >> >> [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-June/032756.html >> >> Bob. >> >> >> >> > From gromero at linux.vnet.ibm.com Mon Aug 27 15:55:50 2018 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Mon, 27 Aug 2018 12:55:50 -0300 Subject: JEP 163: Enable NUMA Mode by Default When Appropriate In-Reply-To: References: Message-ID: Hi Swati, On 08/27/2018 09:10 AM, Swati Sharma wrote: > I was going through this JEP 163: Enable NUMA Mode by Default When Appropriate(http://openjdk.java.net/jeps/163). > > Can we make UseNUMA flag by default ON after detecting that if process runs on multiple NUMA nodes.So after that user don't need to specify the UseNUMA flag and JVM will auto detect and switch ON the flag. The last time I tested SPECjvm with +UseNUMA I recall a slight better performance on PPC64 and no regressions. However I recall that IBM performance team reported at least one regression when using +UseNUMA for a Apache Hadoop YARN workload. They also reported that they were able to get better results when manually tuning the JVM using a numactl approach, for instance. At that occasion they recorded ~24% of numa misses when using +UseNUMA whilst only ~4% when using their numactl approach. That was on OpenJDK 8, but I understand based on changes from 8 to 12 that it didn't change much. So I'm not convinced that the currently +UseNUMA will help in the majority of cases and won't hurt badly some important workload for us. That JEP was create a long time ago (2012) and was updated on 2016, so _maybe_ community lost interest on that as the OS NUMA balancers evolved over the years, helping most workloads / scenarios. So in summing up, at least from a PPC64 perspective, I vouch for not enabling -XX:+UseNUMA by default at the moment without further investigation. I also see the JEP as "draft" so I CC:ed Jesper in case he has any insights about the history and the current / future state of that JEP. Anyway, others might want to comment on that, so let's wait for further comments. > Note : If we can then I can provide the implementaion for this JEP. BTW, https://bugs.openjdk.java.net/browse/JDK-7179517 mentions a patch contributed by Eric, probably the one discussed in this thread: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2012-July/004691.html but it looks like that change never got pushed to 8. Best regards, Gustavo From kim.barrett at oracle.com Mon Aug 27 16:09:09 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 27 Aug 2018 12:09:09 -0400 Subject: RFR: 8209976: Improve iteration over non-JavaThreads In-Reply-To: <17d9a7d5-0e1c-3413-7ffc-116b5b8103dd@redhat.com> References: <5936CC9F-20A4-40CA-8256-3A52643899F5@oracle.com> <17d9a7d5-0e1c-3413-7ffc-116b5b8103dd@redhat.com> Message-ID: <78AD4F37-8673-4BDD-9B46-CD29A861C64E@oracle.com> > On Aug 27, 2018, at 5:22 AM, Roman Kennke wrote: > > Hi Kim, > > may I ask what is the motivation for this? How does it improve the > situation? I got here from JDK-8209850, and from JDK-8209974 by way of JDK-8209975. (There are already links and some comments in JIRA to indicate the connections.) For JDK-8209974 I want to make use of the per-thread SATB and dirty card queues for which space is already allocated in non-JavaThreads. While working on that I discovered there can be non-JavaThreads created before the the barrier set, so don't currently have BarrierSet::on_thread_created applied to them, leaving the GCThreadLocalData uninitialized. That's JDK-8209975. To solve JDK-8209975 I want to iterate over all the non-JavaThreads that exist when set_barrier_set is called, applying the (now deferred rather than plain missing) on_thread_created calls. But the current implementation of Threads::non_java_threads_do doesn't work yet at that time (there are multiple places where it crashes), and not all non-JavaThreads are NamedThreads (the other available iterator). (For JDK-8209974 there is some additional work to be done for non-JavaThreads around BarrierSet::on_thread_attach/detach.) We already have iteration over all JavaThreads. Several use-cases for iterating over the others (or some selected subsets) exist and are not presently well supported. Hence this. This also eliminates some possibly awkward special cases from GlobalCounter. Hm, except that I seem to have forgotten to remove the now obsolete asserts from GlobalCounter::critical_section_begin/end. > > Thanks, > Roman > >> Please review this change to improve the iteration over >> non-JavaThreads. [?] >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8209850 >> >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8209976/open.00/ >> >> Testing: >> mach5 tier1-3, hs-tier4-5 in conjunction with a fix for JDK-8209975. >> Local testing of just this change. From dean.long at oracle.com Mon Aug 27 17:21:16 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 27 Aug 2018 10:21:16 -0700 Subject: [12] RFR(M) 8209594: guarantee(this->is8bit(imm8)) failed: Short forward jump exceeds 8-bit offset In-Reply-To: References: Message-ID: <067e065e-fe7f-c56b-a16a-1f67b18451f6@oracle.com> Looks good.? I did not review avx changes. A couple questions: Did you consider adding "const char* file = NULL, int line = 0" for x86 only instead of all platforms? Are _file[] and _line[] arrays every used? dl On 8/25/18 1:05 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/8209594/webrev.05/ > https://bugs.openjdk.java.net/browse/JDK-8209594 > > All platforms are affected. Please, test. > > I instrumented code to generated biggest code and find all possible > incorrect short jumps. This is the result. > > Changed jump instruction patching API to added jump's source location > in debug build but implemented it only on x86. I tired to search > instructions by code offsets. I used very simple macro: > > #define jmpb(L) jmpb_0(L, __FILE__, __LINE__) > > 'do {} while(0)' does not work here because I need to replace > non-static method. I will be glad if someone can give better > suggestion how implement this macro. > > Fixed incorrect avx512 code in macroAssembler_x86.cpp and x86.ad file. > There were missing instructions and incorrect instructions (copy-paste > typos). > > Fixed C2 scratch buffer sizing. It did not take into account > everything and as result from MAX_inst_size=1024 only 700 bytes were > available. I hit this issue when RTM locking was generated for > FastLock node. > > Tested tier1-3 on all our platforms. And also running these tiers on > avx512 machine. > From kim.barrett at oracle.com Mon Aug 27 17:34:22 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 27 Aug 2018 13:34:22 -0400 Subject: RFR: 8209976: Improve iteration over non-JavaThreads In-Reply-To: <78AD4F37-8673-4BDD-9B46-CD29A861C64E@oracle.com> References: <5936CC9F-20A4-40CA-8256-3A52643899F5@oracle.com> <17d9a7d5-0e1c-3413-7ffc-116b5b8103dd@redhat.com> <78AD4F37-8673-4BDD-9B46-CD29A861C64E@oracle.com> Message-ID: > On Aug 27, 2018, at 12:09 PM, Kim Barrett wrote: > Hm, except that I seem to have forgotten to remove the > now obsolete asserts from GlobalCounter::critical_section_begin/end. New webrevs: full: http://cr.openjdk.java.net/~kbarrett/8209976/open.01/ incr: http://cr.openjdk.java.net/~kbarrett/8209976/open.01.inc/ From zgu at redhat.com Mon Aug 27 17:48:18 2018 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 27 Aug 2018 13:48:18 -0400 Subject: RFR(XXS) 8209852: Counters in StringCleaningTask should be type of size_t Message-ID: Hi, Please review this trivial change that converts counters from type int to size_t, it eliminates several unnecessary type casting. Bug: https://bugs.openjdk.java.net/browse/JDK-8209852 Webrev: http://cr.openjdk.java.net/~zgu/8209852/webrev.00/index.html Test: hotspot_gc on Linux 64 (fastdebug and release) Thanks, -Zhengyu From rasbold at google.com Mon Aug 27 18:00:57 2018 From: rasbold at google.com (Chuck Rasbold) Date: Mon, 27 Aug 2018 11:00:57 -0700 Subject: [12] RFR(M) 8209594: guarantee(this->is8bit(imm8)) failed: Short forward jump exceeds 8-bit offset In-Reply-To: References: Message-ID: Thanks, Vladimir. This looks good to me also. We also recently detected the failing guarantee for jmpb(CLEANUP) in MacroAssembler::string_indexof(). Your new diagnostics are better than the ones I was working on. How did you instrument the code to generate the largest possible code sequence? I found a couple of incorrect short jumps in vectorized_mismatch() which may be considered false positives; the xmm registers always are in the lower bank. On Sat, Aug 25, 2018 at 1:05 PM, Vladimir Kozlov wrote: > http://cr.openjdk.java.net/~kvn/8209594/webrev.05/ > https://bugs.openjdk.java.net/browse/JDK-8209594 > > All platforms are affected. Please, test. > > I instrumented code to generated biggest code and find all possible > incorrect short jumps. This is the result. > > Changed jump instruction patching API to added jump's source location in > debug build but implemented it only on x86. I tired to search instructions > by code offsets. I used very simple macro: > > #define jmpb(L) jmpb_0(L, __FILE__, __LINE__) > > 'do {} while(0)' does not work here because I need to replace non-static > method. I will be glad if someone can give better suggestion how implement > this macro. > > Fixed incorrect avx512 code in macroAssembler_x86.cpp and x86.ad file. > There were missing instructions and incorrect instructions (copy-paste > typos). > > Fixed C2 scratch buffer sizing. It did not take into account everything > and as result from MAX_inst_size=1024 only 700 bytes were available. I hit > this issue when RTM locking was generated for FastLock node. > > Tested tier1-3 on all our platforms. And also running these tiers on > avx512 machine. > > -- > Thanks, > Vladimir > From coleen.phillimore at oracle.com Mon Aug 27 18:08:43 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 27 Aug 2018 14:08:43 -0400 Subject: RFR: 8209976: Improve iteration over non-JavaThreads In-Reply-To: References: <5936CC9F-20A4-40CA-8256-3A52643899F5@oracle.com> <17d9a7d5-0e1c-3413-7ffc-116b5b8103dd@redhat.com> <78AD4F37-8673-4BDD-9B46-CD29A861C64E@oracle.com> Message-ID: This looks like a good improvement.? So there are either JavaThreads or NonJavaThreads but no Thread now??? Should Thread be made abstract so it cannot be instantiated? thanks, Coleen On 8/27/18 1:34 PM, Kim Barrett wrote: >> On Aug 27, 2018, at 12:09 PM, Kim Barrett wrote: >> Hm, except that I seem to have forgotten to remove the >> now obsolete asserts from GlobalCounter::critical_section_begin/end. > New webrevs: > full: http://cr.openjdk.java.net/~kbarrett/8209976/open.01/ > incr: http://cr.openjdk.java.net/~kbarrett/8209976/open.01.inc/ > > From coleen.phillimore at oracle.com Mon Aug 27 18:10:14 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 27 Aug 2018 14:10:14 -0400 Subject: RFR(XXS) 8209852: Counters in StringCleaningTask should be type of size_t In-Reply-To: References: Message-ID: Looks good and trivial.? Has it made it through the submit repo (just in case there's something my eyes did not catch)? thanks, Coleen On 8/27/18 1:48 PM, Zhengyu Gu wrote: > Hi, > > Please review this trivial change that converts counters from type int > to size_t, it eliminates several unnecessary type casting. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8209852 > Webrev: http://cr.openjdk.java.net/~zgu/8209852/webrev.00/index.html > > Test: > > ? hotspot_gc on Linux 64 (fastdebug and release) > > > Thanks, > > -Zhengyu From zgu at redhat.com Mon Aug 27 18:13:53 2018 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 27 Aug 2018 14:13:53 -0400 Subject: RFR(XXS) 8209852: Counters in StringCleaningTask should be type of size_t In-Reply-To: References: Message-ID: <0f7bc444-938c-00ae-fc25-5355ee606b84@redhat.com> Hi Coleen, Thanks for reviewing! I will run through the submit before push. -Zhengyu On 08/27/2018 02:10 PM, coleen.phillimore at oracle.com wrote: > Looks good and trivial.? Has it made it through the submit repo (just in > case there's something my eyes did not catch)? > thanks, > Coleen > > On 8/27/18 1:48 PM, Zhengyu Gu wrote: >> Hi, >> >> Please review this trivial change that converts counters from type int >> to size_t, it eliminates several unnecessary type casting. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8209852 >> Webrev: http://cr.openjdk.java.net/~zgu/8209852/webrev.00/index.html >> >> Test: >> >> ? hotspot_gc on Linux 64 (fastdebug and release) >> >> >> Thanks, >> >> -Zhengyu > From jiangli.zhou at oracle.com Mon Aug 27 20:33:23 2018 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Mon, 27 Aug 2018 13:33:23 -0700 Subject: RFR: JDK-8202951: Implementation of JEPJDK-8204247: Include default CDS (Class Data Sharing) archive in JDK binary Message-ID: Please review the implementation for JEP JDK-8204247 (https://bugs.openjdk.java.net/browse/JDK-8204247). The goal of the JEP is to include a default CDS archive in JDK 12 binary distribution (downloadable from http://jdk.java.net/12/). The default CDS archive is generated using the default classlist (resides in the lib/ directory) at JDK build time. Any comments/suggestions are highly appreciated. All makefile changes in the webrev are contributed by Erik Joelsson (many thanks!!). This is a combination of efforts from different teams and individuals. Thanks to everyone who has been involved in the JEP & implementation discussions, testing and bug fixing! ? JEP: https://bugs.openjdk.java.net/browse/JDK-8204247 ? RFE: https://bugs.openjdk.java.net/browse/JDK-8202951 ? webrev: http://cr.openjdk.java.net/~jiangli/8202951/webrev.00/ Two sanity test cases for the default CDS archive are included test/hotspot/jtreg/runtime/SharedArchiveFile. They are not intended for in-depth CDS functional testing, which is already covered by the existing cds/appcds tests and all tiered tests executing with the default CDS archive enabled. As part of the webrev, test/jdk/javax/imageio/plugins/png/ItxtUtf8Test.java is also fixed to use larger java heap (JDK-8209739 , https://bugs.openjdk.java.net/browse/JDK-8209739). Tests executed: ?- several rounds of tier1 - tier8 via mach5 ?- JCK lang, api and vm tests via mach5 Thanks! Calvin, Ioi, Jiangli From kim.barrett at oracle.com Tue Aug 28 01:36:58 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 27 Aug 2018 21:36:58 -0400 Subject: RFR: 8209976: Improve iteration over non-JavaThreads In-Reply-To: References: <5936CC9F-20A4-40CA-8256-3A52643899F5@oracle.com> <17d9a7d5-0e1c-3413-7ffc-116b5b8103dd@redhat.com> <78AD4F37-8673-4BDD-9B46-CD29A861C64E@oracle.com> Message-ID: <905BEA47-ADB2-4437-8688-183457DD41A5@oracle.com> > On Aug 27, 2018, at 2:08 PM, coleen.phillimore at oracle.com wrote: > > > This looks like a good improvement. So there are either JavaThreads or NonJavaThreads but no Thread now? Should Thread be made abstract so it cannot be instantiated? Thanks for reviewing. We don?t ever directly instantiate Thread. I can make it abstract. The canonical way to make a class abstract if it isn't already seems to be to make the virtual destructor pure. Below is the diff from open.01 that I'm running through testing. diff -r 7587d014de95 src/hotspot/share/runtime/thread.hpp --- a/src/hotspot/share/runtime/thread.hpp Mon Aug 27 13:17:40 2018 -0400 +++ b/src/hotspot/share/runtime/thread.hpp Mon Aug 27 21:20:05 2018 -0400 @@ -385,7 +385,7 @@ // Constructor Thread(); - virtual ~Thread(); + virtual ~Thread() = 0; // Thread is abstract. // Manage Thread::current() void initialize_thread_current(); > thanks, > Coleen > > On 8/27/18 1:34 PM, Kim Barrett wrote: >>> On Aug 27, 2018, at 12:09 PM, Kim Barrett wrote: >>> Hm, except that I seem to have forgotten to remove the >>> now obsolete asserts from GlobalCounter::critical_section_begin/end. >> New webrevs: >> full: http://cr.openjdk.java.net/~kbarrett/8209976/open.01/ >> incr: http://cr.openjdk.java.net/~kbarrett/8209976/open.01.inc/ From magnus.ihse.bursie at oracle.com Tue Aug 28 06:21:49 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 28 Aug 2018 08:21:49 +0200 Subject: [aarch64-port-dev ] RFC: JEP - One AArch64 Port, Not Two In-Reply-To: References: <8cb976e5-80f7-8905-63aa-c658454a8673@oracle.com> Message-ID: <6c3740a4-dc14-5208-ba87-98afe591e13f@oracle.com> On 2018-08-27 16:00, Bob Vandette wrote: > >> On Aug 27, 2018, at 2:30 AM, Magnus Ihse Bursie wrote: >> >> On 2018-08-23 17:13, Bob Vandette wrote: >>> As a follow-on to the previous thread "ARM port consolidation? [1], >>> please review and comment on this newly filed JEP that removes >>> one of the two AArch64 ports from the JDK. >>> >>> JEP: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8209093 >> Looks good! (Or as we say in Sweden: ?ntligen! :-)) >> >> One question: I remember there were some guys from Linaro who compared aarch64 vs arm64 in microbenchmarks, and found that while aarch64 had the superior performance most of the time, there were some benchmarks where arm64 was fastest. >> >> Has these been analyzed, and the performance on aarch64 brought in line with arm64? > It looks like this question has been answered. Yes, thank you. > >>> Here?s a prototype of the changes that would be done under this JEP. >>> >>> http://cr.openjdk.java.net/~bobv/8209093/webrev.00 >> Generally looks good. I have not looked at too much detail since it's just a prototype, but I noted that you just removed --with-cpu-port, instead of deprecating it. That needs to be fixed for the real deal. > What?s the process for deprecation of build options? Do I just change the help text and have the arm64 option select the aarch64 port? You remove the old code, just as you have done, and then add: BASIC_DEPRECATED_ARG_WITH(cpu-port) I'd suggest you add next to "BASIC_DEPRECATED_ARG_WITH(jvm-interpreter)". This will activate code that makes sure --with-cpu-port does not break, but instead prints a warning. /Magnus > > Thanks, > Bob. > >> /Magnus >> >> >> >>> >>> [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-June/032756.html >>> >>> Bob. >>> >>> >>> >>> From aleksei.voitylov at bell-sw.com Tue Aug 28 06:50:39 2018 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Tue, 28 Aug 2018 09:50:39 +0300 Subject: RFC: JEP - One AArch64 Port, Not Two In-Reply-To: References: Message-ID: <60386fed-693e-ad47-4768-dd690b850f5a@bell-sw.com> Bob, I support this JEP. It is going to be easier to maintain the ARM 32-bit port with this effort as well. We are going to run some testing on the ARM 32-bit port and get back to you with the results in a couple of weeks. On a side note, I'm preparing a small patch to the AARCH64 port to enable Minimal VM there - with this all the functionality that was there in the ARM64 port will be present in AARCH64. Thanks, -Aleksei On 23/08/2018 18:13, Bob Vandette wrote: > As a follow-on to the previous thread "ARM port consolidation? [1], > please review and comment on this newly filed JEP that removes > one of the two AArch64 ports from the JDK. > > JEP: > > https://bugs.openjdk.java.net/browse/JDK-8209093 > > > Here?s a prototype of the changes that would be done under this JEP. > > http://cr.openjdk.java.net/~bobv/8209093/webrev.00 > > > [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-June/032756.html > > Bob. > > > > From aph at redhat.com Tue Aug 28 08:01:56 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 28 Aug 2018 09:01:56 +0100 Subject: [aarch64-port-dev ] RFC: JEP - One AArch64 Port, Not Two In-Reply-To: <60386fed-693e-ad47-4768-dd690b850f5a@bell-sw.com> References: <60386fed-693e-ad47-4768-dd690b850f5a@bell-sw.com> Message-ID: On 08/28/2018 07:50 AM, Aleksei Voitylov wrote: > I'm preparing a small patch to the AARCH64 port to > enable Minimal VM there - with this all the functionality that was there > in the ARM64 port will be present in AARCH64. Thanks, this is very useful. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From magnus.ihse.bursie at oracle.com Tue Aug 28 11:14:08 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 28 Aug 2018 13:14:08 +0200 Subject: RFR(M/L) : 8209611 : use C++ compiler for hotspot tests In-Reply-To: <541E57B0-F215-4591-8991-93AF34956F4B@oracle.com> References: <92CD42CC-568A-4972-A35E-469B1532B103@oracle.com> <90CA133B-CD6E-4F08-9A37-BA716092CD2A@oracle.com> <541E57B0-F215-4591-8991-93AF34956F4B@oracle.com> Message-ID: Hi Igor, Sorry for my late arrival to this discussion. I tried to figure out what the latest version of your patch is. My guess is that it is http://cr.openjdk.java.net/~iignatyev//8209611/webrev.02/ + the inlined patch from this mail? In JtregNativeHotspot.gmk, you are removing: ifeq ($(TOOLCHAIN_TYPE), solstudio) ?? BUILD_HOTSPOT_JTREG_LIBRARIES_CFLAGS_libji06t001 += -erroff=E_END_OF_LOOP_CODE_NOT_REACHED endif Is this related to the current fix? In the patch below, why are you removing the comment to the "$$(foreach file..." loop? I think it's still relevant. In this code: ????? $$(shell $$(FIND) $$($1_SOURCE_DIRS) -type f \( -name "$$($1_PREFIX)*.c" \ ?????????????????????????????????????????????????? -o -name "$$($1_PREFIX)*.cpp" \)) While I appreciate your concerns of aligning the "-name" arguments, this kind of padding is something we try to avoid in the build system. There are never any logical places to break the arguments, and this just leads to big reshufflings whenever a command line changes, with little gain in readability. Instead, just indent the line following the \ with four more spaces (and no tabs!). (See http://openjdk.java.net/groups/build/doc/code-conventions.html) Otherwise, this looks fine. /Magnus On 2018-08-24 23:20, Igor Ignatyev wrote: > ok, it worked just fine, here is the final diff for TestFilesCompilation.gmk: > >> diff -r 028076b2832a -r caca95a834e3 make/common/TestFilesCompilation.gmk >> --- a/make/common/TestFilesCompilation.gmk Thu Aug 16 16:28:03 2018 -0700 >> +++ b/make/common/TestFilesCompilation.gmk Fri Aug 24 14:12:37 2018 -0700 >> @@ -60,13 +60,13 @@ >> ifeq ($$($1_TYPE), LIBRARY) >> $1_PREFIX = lib >> $1_OUTPUT_SUBDIR := lib >> - $1_CFLAGS := $(CFLAGS_TESTLIB) >> + $1_CFLAGS += $(CFLAGS_TESTLIB) >> $1_LDFLAGS := $(LDFLAGS_TESTLIB) $(call SET_SHARED_LIBRARY_ORIGIN) >> $1_COMPILATION_TYPE := LIBRARY >> else ifeq ($$($1_TYPE), PROGRAM) >> $1_PREFIX = exe >> $1_OUTPUT_SUBDIR := bin >> - $1_CFLAGS := $(CFLAGS_TESTEXE) >> + $1_CFLAGS += $(CFLAGS_TESTEXE) >> $1_LDFLAGS := $(LDFLAGS_TESTEXE) >> $1_COMPILATION_TYPE := EXECUTABLE >> else >> @@ -75,12 +75,12 @@ >> >> # Locate all files with the matching prefix >> $1_FILE_LIST := \ >> - $$(shell $$(FIND) $$($1_SOURCE_DIRS) -type f -name "$$($1_PREFIX)*.c") >> + $$(shell $$(FIND) $$($1_SOURCE_DIRS) -type f \( -name "$$($1_PREFIX)*.c" \ >> + -o -name "$$($1_PREFIX)*.cpp" \)) >> >> $1_EXCLUDE_PATTERN := $$(addprefix %/, $$($1_EXCLUDE)) >> $1_FILTERED_FILE_LIST := $$(filter-out $$($1_EXCLUDE_PATTERN), $$($1_FILE_LIST)) >> >> - # Setup a compilation for each and every one of them >> $$(foreach file, $$($1_FILTERED_FILE_LIST),\ >> $$(eval name := $$(strip $$(basename $$(notdir $$(file))))) \ >> $$(eval unprefixed_name := $$(patsubst $$($1_PREFIX)%, %, $$(name))) \ >> @@ -94,6 +94,7 @@ >> CFLAGS := $$($1_CFLAGS) $$($1_CFLAGS_$$(name)), \ >> LDFLAGS := $$($1_LDFLAGS) $$($1_LDFLAGS_$$(name)), \ >> LIBS := $$($1_LIBS_$$(name)), \ >> + TOOLCHAIN := $(if $$(filter %.cpp, $$(file)), TOOLCHAIN_LINK_CXX, TOOLCHAIN_DEFAULT), \ >> OPTIMIZATION := LOW, \ >> COPY_DEBUG_SYMBOLS := false, \ >> STRIP_SYMBOLS := false, \ > Thanks, > -- Igor > > >> On Aug 24, 2018, at 10:36 AM, Igor Ignatev wrote: >> >> Hi Erik, >> >> Unfortunately, just adding .cpp files to file list isn?t enough, as I mentioned in one of my previous emails[1], initially I did exactly that and linux-slowdebug build fails b/c c-linker was be used for .o files produced by cpp-compiler. >> >> I guess something like [2] might work. I'll play w/ this idea and send final patch latch. >> >> ? Igor >> >> [1] http://mail.openjdk.java.net/pipermail/build-dev/2018-August/022922.html >> [2] TOOLCHAIN := $(if $$(filter %.cpp, $$(file)), TOOLCHAIN_LINK_CXX, TOOLCHAIN_DEFAULT) >> >>> On Aug 23, 2018, at 11:31 PM, Erik Joelsson wrote: >>> >>> Hello Igor, >>> >>> In TestFilesCompilation.gmk, there is no need to duplicate the whole macro call. If you want to find .cpp as well as .c files, just add that to the one list of files. The SetupNativeCompilation macro will automatically treat .c and .cpp correctly. >>> >>> Regarding the .c/.cpp files for your vmtestbase tests that include all the other files, this is an unfortunate solution, but I guess OK if it works. We certainly didn't intend it that way. The macro SetupTestFilesCompilation was intended for easily writing single file native exe and lib binaries without having to modify any makefile. The expectation was that if anything more complicated was needed (like multiple files per binary), we would just write explicit SetupNativeCompilation calls for them in JtregNativeHotspot.gmk. It now looks like we have a new pattern of source files/directories that turns into native libraries, and we could of course create a new macro that automatically generates compilation setups for them as well (given that file or directory names makes it possible to automatically determine everything needed). Of course, that change would be a separate cleanup possible if you want to. >>> >>> /Erik >>> >>>> On 2018-08-20 15:59, Igor Ignatyev wrote: >>>> http://cr.openjdk.java.net/~iignatyev//8209611/webrev.01/index.html >>>>> 11160 lines changed: 879 ins; 61 del; 10220 mod; >>>> Hi all, >>>> >>>> could you please review the patch which moves all hotspot native test code to C++? this will guarantee that we always use C++ compilers for them (as an opposite to either C or C++ compiler depending on configuration), as a result we will be able to get rid of JNI_ENV_ARG[1] macros, perform other clean ups and improve overall quality of the test code. >>>> >>>> the patch consists of two parts: >>>> - automatic: renaming .c files to .cpp, updating #include, changing JNI/JVMTI calls >>>> - semi-manual: adding extern "C" , fixing a number of compiler warnings (mostly types inconsistency), updating makefiles >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8209611 >>>> webrevs: >>>> - automatic: http://cr.openjdk.java.net/~iignatyev//8209611/webrev.00/index.html >>>>> 9394 lines changed: 0 ins; 0 del; 9394 mod; >>>> - semi-manual: http://cr.openjdk.java.net/~iignatyev//8209611/webrev.0-1/index.html >>>>> 1899 lines changed: 879 ins; 61 del; 959 mod >>>> - whole: http://cr.openjdk.java.net/~iignatyev//8209611/webrev.01/index.html >>>>> 11160 lines changed: 879 ins; 61 del; 10220 mod; >>>> testing: all hotspot tests + tier[1-3] >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8209547 >>>> >>>> Thanks, >>>> -- Igor From gunter.haug at sap.com Tue Aug 28 13:14:05 2018 From: gunter.haug at sap.com (Haug, Gunter) Date: Tue, 28 Aug 2018 13:14:05 +0000 Subject: RFR (XS): 8209996: [PPC64] Fix JFR profiling Message-ID: Hi all, There are two bugs in PPC64 platform code preventing a jtreg test (TestFullStackTrace.java) to complete successfully. Can I please have a review and a sponsor for the following change which fixes the issue: https://bugs.openjdk.java.net/browse/JDK-8209996 http://cr.openjdk.java.net/~ghaug/webrevs/8209996/ frame::safe_for_sender made two assertions which are two strict. First, unextended_sp may well be greater than sp due to frame resizing (compacting) for interpreter fames. Second, top_ijava_frame_abi is only included in the top frame, obviously. Thanks, Gunter From bob.vandette at oracle.com Tue Aug 28 13:48:13 2018 From: bob.vandette at oracle.com (Bob Vandette) Date: Tue, 28 Aug 2018 09:48:13 -0400 Subject: RFC: JEP - One AArch64 Port, Not Two In-Reply-To: <60386fed-693e-ad47-4768-dd690b850f5a@bell-sw.com> References: <60386fed-693e-ad47-4768-dd690b850f5a@bell-sw.com> Message-ID: <580F40F6-6B5C-4909-944F-FD891ADB2F08@oracle.com> Thanks so much Aleksei. Bob. > On Aug 28, 2018, at 2:50 AM, Aleksei Voitylov wrote: > > Bob, > > I support this JEP. It is going to be easier to maintain the ARM 32-bit port with this effort as well. We are going to run some testing on the ARM 32-bit port and get back to you with the results in a couple of weeks. > > On a side note, I'm preparing a small patch to the AARCH64 port to enable Minimal VM there - with this all the functionality that was there in the ARM64 port will be present in AARCH64. > > Thanks, > > -Aleksei > > > On 23/08/2018 18:13, Bob Vandette wrote: >> As a follow-on to the previous thread "ARM port consolidation? [1], >> please review and comment on this newly filed JEP that removes >> one of the two AArch64 ports from the JDK. >> >> JEP: >> >> https://bugs.openjdk.java.net/browse/JDK-8209093 >> >> >> Here?s a prototype of the changes that would be done under this JEP. >> >> http://cr.openjdk.java.net/~bobv/8209093/webrev.00 >> >> >> [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2018-June/032756.html >> >> Bob. >> >> >> >> > From volker.simonis at gmail.com Tue Aug 28 14:27:27 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 28 Aug 2018 16:27:27 +0200 Subject: RFR (XS): 8209996: [PPC64] Fix JFR profiling In-Reply-To: References: Message-ID: Looks good! Thanks, Volker On Tue, Aug 28, 2018 at 3:14 PM Haug, Gunter wrote: > > Hi all, > > There are two bugs in PPC64 platform code preventing a jtreg test (TestFullStackTrace.java) to complete successfully. Can I please have a review and a sponsor for the following change which fixes the issue: > > https://bugs.openjdk.java.net/browse/JDK-8209996 > http://cr.openjdk.java.net/~ghaug/webrevs/8209996/ > > frame::safe_for_sender made two assertions which are two strict. First, unextended_sp may well be greater than sp due to frame resizing (compacting) for interpreter fames. Second, top_ijava_frame_abi is only included in the top frame, obviously. > > Thanks, > Gunter > > From martin.doerr at sap.com Tue Aug 28 14:49:09 2018 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 28 Aug 2018 14:49:09 +0000 Subject: RFR (XS): 8209996: [PPC64] Fix JFR profiling In-Reply-To: References: Message-ID: Hi Gunter, thanks for removing the incorrect checks. "unextended_sp" could get checked against stack_end() or usable_stack_size. "(fp - sp)" could get checked against ijava_state_size + parent_ijava_frame_abi_size. In addition, "fp > sp" is redundant. But I guess these checks are not important for PPC64, so I could live with what you've proposed. Best regards, Martin -----Original Message----- From: hotspot-dev On Behalf Of Haug, Gunter Sent: Dienstag, 28. August 2018 15:14 To: hotspot-dev Source Developers Subject: RFR (XS): 8209996: [PPC64] Fix JFR profiling Hi all, There are two bugs in PPC64 platform code preventing a jtreg test (TestFullStackTrace.java) to complete successfully. Can I please have a review and a sponsor for the following change which fixes the issue: https://bugs.openjdk.java.net/browse/JDK-8209996 http://cr.openjdk.java.net/~ghaug/webrevs/8209996/ frame::safe_for_sender made two assertions which are two strict. First, unextended_sp may well be greater than sp due to frame resizing (compacting) for interpreter fames. Second, top_ijava_frame_abi is only included in the top frame, obviously. Thanks, Gunter From igor.ignatyev at oracle.com Tue Aug 28 14:51:53 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 28 Aug 2018 07:51:53 -0700 Subject: RFR(M/L) : 8209611 : use C++ compiler for hotspot tests In-Reply-To: References: <92CD42CC-568A-4972-A35E-469B1532B103@oracle.com> <90CA133B-CD6E-4F08-9A37-BA716092CD2A@oracle.com> <541E57B0-F215-4591-8991-93AF34956F4B@oracle.com> Message-ID: Hi Magnus, thanks for reviewing this. please see my answers inline. Cheers, -- Igor > On Aug 28, 2018, at 4:14 AM, Magnus Ihse Bursie wrote: > > Hi Igor, > > Sorry for my late arrival to this discussion. > > I tried to figure out what the latest version of your patch is. My guess is that it is http://cr.openjdk.java.net/~iignatyev//8209611/webrev.02/ + the inlined patch from this mail? yes, that's right > > In JtregNativeHotspot.gmk, you are removing: > ifeq ($(TOOLCHAIN_TYPE), solstudio) > BUILD_HOTSPOT_JTREG_LIBRARIES_CFLAGS_libji06t001 += -erroff=E_END_OF_LOOP_CODE_NOT_REACHED > endif > > Is this related to the current fix? y, C++ compiler of SS doesn't recognize E_END_OF_LOOP_CODE_NOT_REACHED as a valid tag, it seems this tag is only defined for C compiler > > In the patch below, why are you removing the comment to the "$$(foreach file..." loop? I think it's still relevant. no reason, will put it back. > In this code: > $$(shell $$(FIND) $$($1_SOURCE_DIRS) -type f \( -name "$$($1_PREFIX)*.c" \ > -o -name "$$($1_PREFIX)*.cpp" \)) > > While I appreciate your concerns of aligning the "-name" arguments, this kind of padding is something we try to avoid in the build system. There are never any logical places to break the arguments, and this just leads to big reshufflings whenever a command line changes, with little gain in readability. Instead, just indent the line following the \ with four more spaces (and no tabs!). (See http://openjdk.java.net/groups/build/doc/code-conventions.html) sure thing, I'll remove all redundant spaces. > > Otherwise, this looks fine. > > /Magnus > > > On 2018-08-24 23:20, Igor Ignatyev wrote: >> ok, it worked just fine, here is the final diff for TestFilesCompilation.gmk: >> >>> diff -r 028076b2832a -r caca95a834e3 make/common/TestFilesCompilation.gmk >>> --- a/make/common/TestFilesCompilation.gmk Thu Aug 16 16:28:03 2018 -0700 >>> +++ b/make/common/TestFilesCompilation.gmk Fri Aug 24 14:12:37 2018 -0700 >>> @@ -60,13 +60,13 @@ >>> ifeq ($$($1_TYPE), LIBRARY) >>> $1_PREFIX = lib >>> $1_OUTPUT_SUBDIR := lib >>> - $1_CFLAGS := $(CFLAGS_TESTLIB) >>> + $1_CFLAGS += $(CFLAGS_TESTLIB) >>> $1_LDFLAGS := $(LDFLAGS_TESTLIB) $(call SET_SHARED_LIBRARY_ORIGIN) >>> $1_COMPILATION_TYPE := LIBRARY >>> else ifeq ($$($1_TYPE), PROGRAM) >>> $1_PREFIX = exe >>> $1_OUTPUT_SUBDIR := bin >>> - $1_CFLAGS := $(CFLAGS_TESTEXE) >>> + $1_CFLAGS += $(CFLAGS_TESTEXE) >>> $1_LDFLAGS := $(LDFLAGS_TESTEXE) >>> $1_COMPILATION_TYPE := EXECUTABLE >>> else >>> @@ -75,12 +75,12 @@ >>> # Locate all files with the matching prefix >>> $1_FILE_LIST := \ >>> - $$(shell $$(FIND) $$($1_SOURCE_DIRS) -type f -name "$$($1_PREFIX)*.c") >>> + $$(shell $$(FIND) $$($1_SOURCE_DIRS) -type f \( -name "$$($1_PREFIX)*.c" \ >>> + -o -name "$$($1_PREFIX)*.cpp" \)) >>> $1_EXCLUDE_PATTERN := $$(addprefix %/, $$($1_EXCLUDE)) >>> $1_FILTERED_FILE_LIST := $$(filter-out $$($1_EXCLUDE_PATTERN), $$($1_FILE_LIST)) >>> - # Setup a compilation for each and every one of them >>> $$(foreach file, $$($1_FILTERED_FILE_LIST),\ >>> $$(eval name := $$(strip $$(basename $$(notdir $$(file))))) \ >>> $$(eval unprefixed_name := $$(patsubst $$($1_PREFIX)%, %, $$(name))) \ >>> @@ -94,6 +94,7 @@ >>> CFLAGS := $$($1_CFLAGS) $$($1_CFLAGS_$$(name)), \ >>> LDFLAGS := $$($1_LDFLAGS) $$($1_LDFLAGS_$$(name)), \ >>> LIBS := $$($1_LIBS_$$(name)), \ >>> + TOOLCHAIN := $(if $$(filter %.cpp, $$(file)), TOOLCHAIN_LINK_CXX, TOOLCHAIN_DEFAULT), \ >>> OPTIMIZATION := LOW, \ >>> COPY_DEBUG_SYMBOLS := false, \ >>> STRIP_SYMBOLS := false, \ >> Thanks, >> -- Igor >> >> >>> On Aug 24, 2018, at 10:36 AM, Igor Ignatev wrote: >>> >>> Hi Erik, >>> >>> Unfortunately, just adding .cpp files to file list isn?t enough, as I mentioned in one of my previous emails[1], initially I did exactly that and linux-slowdebug build fails b/c c-linker was be used for .o files produced by cpp-compiler. >>> >>> I guess something like [2] might work. I'll play w/ this idea and send final patch latch. >>> >>> ? Igor >>> >>> [1] http://mail.openjdk.java.net/pipermail/build-dev/2018-August/022922.html >>> [2] TOOLCHAIN := $(if $$(filter %.cpp, $$(file)), TOOLCHAIN_LINK_CXX, TOOLCHAIN_DEFAULT) >>> >>>> On Aug 23, 2018, at 11:31 PM, Erik Joelsson wrote: >>>> >>>> Hello Igor, >>>> >>>> In TestFilesCompilation.gmk, there is no need to duplicate the whole macro call. If you want to find .cpp as well as .c files, just add that to the one list of files. The SetupNativeCompilation macro will automatically treat .c and .cpp correctly. >>>> >>>> Regarding the .c/.cpp files for your vmtestbase tests that include all the other files, this is an unfortunate solution, but I guess OK if it works. We certainly didn't intend it that way. The macro SetupTestFilesCompilation was intended for easily writing single file native exe and lib binaries without having to modify any makefile. The expectation was that if anything more complicated was needed (like multiple files per binary), we would just write explicit SetupNativeCompilation calls for them in JtregNativeHotspot.gmk. It now looks like we have a new pattern of source files/directories that turns into native libraries, and we could of course create a new macro that automatically generates compilation setups for them as well (given that file or directory names makes it possible to automatically determine everything needed). Of course, that change would be a separate cleanup possible if you want to. >>>> >>>> /Erik >>>> >>>>> On 2018-08-20 15:59, Igor Ignatyev wrote: >>>>> http://cr.openjdk.java.net/~iignatyev//8209611/webrev.01/index.html >>>>>> 11160 lines changed: 879 ins; 61 del; 10220 mod; >>>>> Hi all, >>>>> >>>>> could you please review the patch which moves all hotspot native test code to C++? this will guarantee that we always use C++ compilers for them (as an opposite to either C or C++ compiler depending on configuration), as a result we will be able to get rid of JNI_ENV_ARG[1] macros, perform other clean ups and improve overall quality of the test code. >>>>> >>>>> the patch consists of two parts: >>>>> - automatic: renaming .c files to .cpp, updating #include, changing JNI/JVMTI calls >>>>> - semi-manual: adding extern "C" , fixing a number of compiler warnings (mostly types inconsistency), updating makefiles >>>>> >>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8209611 >>>>> webrevs: >>>>> - automatic: http://cr.openjdk.java.net/~iignatyev//8209611/webrev.00/index.html >>>>>> 9394 lines changed: 0 ins; 0 del; 9394 mod; >>>>> - semi-manual: http://cr.openjdk.java.net/~iignatyev//8209611/webrev.0-1/index.html >>>>>> 1899 lines changed: 879 ins; 61 del; 959 mod >>>>> - whole: http://cr.openjdk.java.net/~iignatyev//8209611/webrev.01/index.html >>>>>> 11160 lines changed: 879 ins; 61 del; 10220 mod; >>>>> testing: all hotspot tests + tier[1-3] >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8209547 >>>>> >>>>> Thanks, >>>>> -- Igor > From coleen.phillimore at oracle.com Tue Aug 28 15:38:36 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 28 Aug 2018 11:38:36 -0400 Subject: RFR: 8209976: Improve iteration over non-JavaThreads In-Reply-To: <905BEA47-ADB2-4437-8688-183457DD41A5@oracle.com> References: <5936CC9F-20A4-40CA-8256-3A52643899F5@oracle.com> <17d9a7d5-0e1c-3413-7ffc-116b5b8103dd@redhat.com> <78AD4F37-8673-4BDD-9B46-CD29A861C64E@oracle.com> <905BEA47-ADB2-4437-8688-183457DD41A5@oracle.com> Message-ID: This looks good.? Thank you for making Thread class abstract. Coleen On 8/27/18 9:36 PM, Kim Barrett wrote: >> On Aug 27, 2018, at 2:08 PM, coleen.phillimore at oracle.com wrote: >> >> >> This looks like a good improvement. So there are either JavaThreads or NonJavaThreads but no Thread now? Should Thread be made abstract so it cannot be instantiated? > Thanks for reviewing. > > We don?t ever directly instantiate Thread. I can make it abstract. > > The canonical way to make a class abstract if it isn't already seems > to be to make the virtual destructor pure. Below is the diff from > open.01 that I'm running through testing. > > diff -r 7587d014de95 src/hotspot/share/runtime/thread.hpp > --- a/src/hotspot/share/runtime/thread.hpp Mon Aug 27 13:17:40 2018 -0400 > +++ b/src/hotspot/share/runtime/thread.hpp Mon Aug 27 21:20:05 2018 -0400 > @@ -385,7 +385,7 @@ > > // Constructor > Thread(); > - virtual ~Thread(); > + virtual ~Thread() = 0; // Thread is abstract. > > // Manage Thread::current() > void initialize_thread_current(); > >> thanks, >> Coleen >> >> On 8/27/18 1:34 PM, Kim Barrett wrote: >>>> On Aug 27, 2018, at 12:09 PM, Kim Barrett wrote: >>>> Hm, except that I seem to have forgotten to remove the >>>> now obsolete asserts from GlobalCounter::critical_section_begin/end. >>> New webrevs: >>> full: http://cr.openjdk.java.net/~kbarrett/8209976/open.01/ >>> incr: http://cr.openjdk.java.net/~kbarrett/8209976/open.01.inc/ > From erik.joelsson at oracle.com Tue Aug 28 16:01:25 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 28 Aug 2018 09:01:25 -0700 Subject: RFR(M/L) : 8209611 : use C++ compiler for hotspot tests In-Reply-To: References: <92CD42CC-568A-4972-A35E-469B1532B103@oracle.com> <90CA133B-CD6E-4F08-9A37-BA716092CD2A@oracle.com> <541E57B0-F215-4591-8991-93AF34956F4B@oracle.com> Message-ID: <30ffdada-a093-3ecc-1de5-027c2d17000e@oracle.com> Hello, I have nothing to add in addition to Magnus' comments. If that is fixed, this looks good from a build point of view. /Erik On 2018-08-28 07:51, Igor Ignatyev wrote: > Hi Magnus, > > thanks for reviewing this. > > please see my answers inline. > > Cheers, > -- Igor > >> On Aug 28, 2018, at 4:14 AM, Magnus Ihse Bursie wrote: >> >> Hi Igor, >> >> Sorry for my late arrival to this discussion. >> >> I tried to figure out what the latest version of your patch is. My guess is that it is http://cr.openjdk.java.net/~iignatyev//8209611/webrev.02/ + the inlined patch from this mail? > yes, that's right >> In JtregNativeHotspot.gmk, you are removing: >> ifeq ($(TOOLCHAIN_TYPE), solstudio) >> BUILD_HOTSPOT_JTREG_LIBRARIES_CFLAGS_libji06t001 += -erroff=E_END_OF_LOOP_CODE_NOT_REACHED >> endif >> >> Is this related to the current fix? > y, C++ compiler of SS doesn't recognize E_END_OF_LOOP_CODE_NOT_REACHED as a valid tag, it seems this tag is only defined for C compiler > >> In the patch below, why are you removing the comment to the "$$(foreach file..." loop? I think it's still relevant. > no reason, will put it back. > >> In this code: >> $$(shell $$(FIND) $$($1_SOURCE_DIRS) -type f \( -name "$$($1_PREFIX)*.c" \ >> -o -name "$$($1_PREFIX)*.cpp" \)) >> >> While I appreciate your concerns of aligning the "-name" arguments, this kind of padding is something we try to avoid in the build system. There are never any logical places to break the arguments, and this just leads to big reshufflings whenever a command line changes, with little gain in readability. Instead, just indent the line following the \ with four more spaces (and no tabs!). (See http://openjdk.java.net/groups/build/doc/code-conventions.html) > sure thing, I'll remove all redundant spaces. >> Otherwise, this looks fine. >> >> /Magnus >> >> >> On 2018-08-24 23:20, Igor Ignatyev wrote: >>> ok, it worked just fine, here is the final diff for TestFilesCompilation.gmk: >>> >>>> diff -r 028076b2832a -r caca95a834e3 make/common/TestFilesCompilation.gmk >>>> --- a/make/common/TestFilesCompilation.gmk Thu Aug 16 16:28:03 2018 -0700 >>>> +++ b/make/common/TestFilesCompilation.gmk Fri Aug 24 14:12:37 2018 -0700 >>>> @@ -60,13 +60,13 @@ >>>> ifeq ($$($1_TYPE), LIBRARY) >>>> $1_PREFIX = lib >>>> $1_OUTPUT_SUBDIR := lib >>>> - $1_CFLAGS := $(CFLAGS_TESTLIB) >>>> + $1_CFLAGS += $(CFLAGS_TESTLIB) >>>> $1_LDFLAGS := $(LDFLAGS_TESTLIB) $(call SET_SHARED_LIBRARY_ORIGIN) >>>> $1_COMPILATION_TYPE := LIBRARY >>>> else ifeq ($$($1_TYPE), PROGRAM) >>>> $1_PREFIX = exe >>>> $1_OUTPUT_SUBDIR := bin >>>> - $1_CFLAGS := $(CFLAGS_TESTEXE) >>>> + $1_CFLAGS += $(CFLAGS_TESTEXE) >>>> $1_LDFLAGS := $(LDFLAGS_TESTEXE) >>>> $1_COMPILATION_TYPE := EXECUTABLE >>>> else >>>> @@ -75,12 +75,12 @@ >>>> # Locate all files with the matching prefix >>>> $1_FILE_LIST := \ >>>> - $$(shell $$(FIND) $$($1_SOURCE_DIRS) -type f -name "$$($1_PREFIX)*.c") >>>> + $$(shell $$(FIND) $$($1_SOURCE_DIRS) -type f \( -name "$$($1_PREFIX)*.c" \ >>>> + -o -name "$$($1_PREFIX)*.cpp" \)) >>>> $1_EXCLUDE_PATTERN := $$(addprefix %/, $$($1_EXCLUDE)) >>>> $1_FILTERED_FILE_LIST := $$(filter-out $$($1_EXCLUDE_PATTERN), $$($1_FILE_LIST)) >>>> - # Setup a compilation for each and every one of them >>>> $$(foreach file, $$($1_FILTERED_FILE_LIST),\ >>>> $$(eval name := $$(strip $$(basename $$(notdir $$(file))))) \ >>>> $$(eval unprefixed_name := $$(patsubst $$($1_PREFIX)%, %, $$(name))) \ >>>> @@ -94,6 +94,7 @@ >>>> CFLAGS := $$($1_CFLAGS) $$($1_CFLAGS_$$(name)), \ >>>> LDFLAGS := $$($1_LDFLAGS) $$($1_LDFLAGS_$$(name)), \ >>>> LIBS := $$($1_LIBS_$$(name)), \ >>>> + TOOLCHAIN := $(if $$(filter %.cpp, $$(file)), TOOLCHAIN_LINK_CXX, TOOLCHAIN_DEFAULT), \ >>>> OPTIMIZATION := LOW, \ >>>> COPY_DEBUG_SYMBOLS := false, \ >>>> STRIP_SYMBOLS := false, \ >>> Thanks, >>> -- Igor >>> >>> >>>> On Aug 24, 2018, at 10:36 AM, Igor Ignatev wrote: >>>> >>>> Hi Erik, >>>> >>>> Unfortunately, just adding .cpp files to file list isn?t enough, as I mentioned in one of my previous emails[1], initially I did exactly that and linux-slowdebug build fails b/c c-linker was be used for .o files produced by cpp-compiler. >>>> >>>> I guess something like [2] might work. I'll play w/ this idea and send final patch latch. >>>> >>>> ? Igor >>>> >>>> [1] http://mail.openjdk.java.net/pipermail/build-dev/2018-August/022922.html >>>> [2] TOOLCHAIN := $(if $$(filter %.cpp, $$(file)), TOOLCHAIN_LINK_CXX, TOOLCHAIN_DEFAULT) >>>> >>>>> On Aug 23, 2018, at 11:31 PM, Erik Joelsson wrote: >>>>> >>>>> Hello Igor, >>>>> >>>>> In TestFilesCompilation.gmk, there is no need to duplicate the whole macro call. If you want to find .cpp as well as .c files, just add that to the one list of files. The SetupNativeCompilation macro will automatically treat .c and .cpp correctly. >>>>> >>>>> Regarding the .c/.cpp files for your vmtestbase tests that include all the other files, this is an unfortunate solution, but I guess OK if it works. We certainly didn't intend it that way. The macro SetupTestFilesCompilation was intended for easily writing single file native exe and lib binaries without having to modify any makefile. The expectation was that if anything more complicated was needed (like multiple files per binary), we would just write explicit SetupNativeCompilation calls for them in JtregNativeHotspot.gmk. It now looks like we have a new pattern of source files/directories that turns into native libraries, and we could of course create a new macro that automatically generates compilation setups for them as well (given that file or directory names makes it possible to automatically determine everything needed). Of course, that change would be a separate cleanup possible if you want to. >>>>> >>>>> /Erik >>>>> >>>>>> On 2018-08-20 15:59, Igor Ignatyev wrote: >>>>>> http://cr.openjdk.java.net/~iignatyev//8209611/webrev.01/index.html >>>>>>> 11160 lines changed: 879 ins; 61 del; 10220 mod; >>>>>> Hi all, >>>>>> >>>>>> could you please review the patch which moves all hotspot native test code to C++? this will guarantee that we always use C++ compilers for them (as an opposite to either C or C++ compiler depending on configuration), as a result we will be able to get rid of JNI_ENV_ARG[1] macros, perform other clean ups and improve overall quality of the test code. >>>>>> >>>>>> the patch consists of two parts: >>>>>> - automatic: renaming .c files to .cpp, updating #include, changing JNI/JVMTI calls >>>>>> - semi-manual: adding extern "C" , fixing a number of compiler warnings (mostly types inconsistency), updating makefiles >>>>>> >>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8209611 >>>>>> webrevs: >>>>>> - automatic: http://cr.openjdk.java.net/~iignatyev//8209611/webrev.00/index.html >>>>>>> 9394 lines changed: 0 ins; 0 del; 9394 mod; >>>>>> - semi-manual: http://cr.openjdk.java.net/~iignatyev//8209611/webrev.0-1/index.html >>>>>>> 1899 lines changed: 879 ins; 61 del; 959 mod >>>>>> - whole: http://cr.openjdk.java.net/~iignatyev//8209611/webrev.01/index.html >>>>>>> 11160 lines changed: 879 ins; 61 del; 10220 mod; >>>>>> testing: all hotspot tests + tier[1-3] >>>>>> >>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8209547 >>>>>> >>>>>> Thanks, >>>>>> -- Igor From igor.ignatyev at oracle.com Tue Aug 28 16:08:28 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 28 Aug 2018 09:08:28 -0700 Subject: RFR(M/L) : 8209611 : use C++ compiler for hotspot tests In-Reply-To: <30ffdada-a093-3ecc-1de5-027c2d17000e@oracle.com> References: <92CD42CC-568A-4972-A35E-469B1532B103@oracle.com> <90CA133B-CD6E-4F08-9A37-BA716092CD2A@oracle.com> <541E57B0-F215-4591-8991-93AF34956F4B@oracle.com> <30ffdada-a093-3ecc-1de5-027c2d17000e@oracle.com> Message-ID: Hi Erik, thanks for your review! -- Igor > On Aug 28, 2018, at 9:01 AM, Erik Joelsson wrote: > > Hello, > > I have nothing to add in addition to Magnus' comments. If that is fixed, this looks good from a build point of view. > > /Erik > > > On 2018-08-28 07:51, Igor Ignatyev wrote: >> Hi Magnus, >> >> thanks for reviewing this. >> >> please see my answers inline. >> >> Cheers, >> -- Igor >> >>> On Aug 28, 2018, at 4:14 AM, Magnus Ihse Bursie wrote: >>> >>> Hi Igor, >>> >>> Sorry for my late arrival to this discussion. >>> >>> I tried to figure out what the latest version of your patch is. My guess is that it is http://cr.openjdk.java.net/~iignatyev//8209611/webrev.02/ + the inlined patch from this mail? >> yes, that's right >>> In JtregNativeHotspot.gmk, you are removing: >>> ifeq ($(TOOLCHAIN_TYPE), solstudio) >>> BUILD_HOTSPOT_JTREG_LIBRARIES_CFLAGS_libji06t001 += -erroff=E_END_OF_LOOP_CODE_NOT_REACHED >>> endif >>> >>> Is this related to the current fix? >> y, C++ compiler of SS doesn't recognize E_END_OF_LOOP_CODE_NOT_REACHED as a valid tag, it seems this tag is only defined for C compiler >> >>> In the patch below, why are you removing the comment to the "$$(foreach file..." loop? I think it's still relevant. >> no reason, will put it back. >> >>> In this code: >>> $$(shell $$(FIND) $$($1_SOURCE_DIRS) -type f \( -name "$$($1_PREFIX)*.c" \ >>> -o -name "$$($1_PREFIX)*.cpp" \)) >>> >>> While I appreciate your concerns of aligning the "-name" arguments, this kind of padding is something we try to avoid in the build system. There are never any logical places to break the arguments, and this just leads to big reshufflings whenever a command line changes, with little gain in readability. Instead, just indent the line following the \ with four more spaces (and no tabs!). (See http://openjdk.java.net/groups/build/doc/code-conventions.html) >> sure thing, I'll remove all redundant spaces. >>> Otherwise, this looks fine. >>> >>> /Magnus >>> >>> >>> On 2018-08-24 23:20, Igor Ignatyev wrote: >>>> ok, it worked just fine, here is the final diff for TestFilesCompilation.gmk: >>>> >>>>> diff -r 028076b2832a -r caca95a834e3 make/common/TestFilesCompilation.gmk >>>>> --- a/make/common/TestFilesCompilation.gmk Thu Aug 16 16:28:03 2018 -0700 >>>>> +++ b/make/common/TestFilesCompilation.gmk Fri Aug 24 14:12:37 2018 -0700 >>>>> @@ -60,13 +60,13 @@ >>>>> ifeq ($$($1_TYPE), LIBRARY) >>>>> $1_PREFIX = lib >>>>> $1_OUTPUT_SUBDIR := lib >>>>> - $1_CFLAGS := $(CFLAGS_TESTLIB) >>>>> + $1_CFLAGS += $(CFLAGS_TESTLIB) >>>>> $1_LDFLAGS := $(LDFLAGS_TESTLIB) $(call SET_SHARED_LIBRARY_ORIGIN) >>>>> $1_COMPILATION_TYPE := LIBRARY >>>>> else ifeq ($$($1_TYPE), PROGRAM) >>>>> $1_PREFIX = exe >>>>> $1_OUTPUT_SUBDIR := bin >>>>> - $1_CFLAGS := $(CFLAGS_TESTEXE) >>>>> + $1_CFLAGS += $(CFLAGS_TESTEXE) >>>>> $1_LDFLAGS := $(LDFLAGS_TESTEXE) >>>>> $1_COMPILATION_TYPE := EXECUTABLE >>>>> else >>>>> @@ -75,12 +75,12 @@ >>>>> # Locate all files with the matching prefix >>>>> $1_FILE_LIST := \ >>>>> - $$(shell $$(FIND) $$($1_SOURCE_DIRS) -type f -name "$$($1_PREFIX)*.c") >>>>> + $$(shell $$(FIND) $$($1_SOURCE_DIRS) -type f \( -name "$$($1_PREFIX)*.c" \ >>>>> + -o -name "$$($1_PREFIX)*.cpp" \)) >>>>> $1_EXCLUDE_PATTERN := $$(addprefix %/, $$($1_EXCLUDE)) >>>>> $1_FILTERED_FILE_LIST := $$(filter-out $$($1_EXCLUDE_PATTERN), $$($1_FILE_LIST)) >>>>> - # Setup a compilation for each and every one of them >>>>> $$(foreach file, $$($1_FILTERED_FILE_LIST),\ >>>>> $$(eval name := $$(strip $$(basename $$(notdir $$(file))))) \ >>>>> $$(eval unprefixed_name := $$(patsubst $$($1_PREFIX)%, %, $$(name))) \ >>>>> @@ -94,6 +94,7 @@ >>>>> CFLAGS := $$($1_CFLAGS) $$($1_CFLAGS_$$(name)), \ >>>>> LDFLAGS := $$($1_LDFLAGS) $$($1_LDFLAGS_$$(name)), \ >>>>> LIBS := $$($1_LIBS_$$(name)), \ >>>>> + TOOLCHAIN := $(if $$(filter %.cpp, $$(file)), TOOLCHAIN_LINK_CXX, TOOLCHAIN_DEFAULT), \ >>>>> OPTIMIZATION := LOW, \ >>>>> COPY_DEBUG_SYMBOLS := false, \ >>>>> STRIP_SYMBOLS := false, \ >>>> Thanks, >>>> -- Igor >>>> >>>> >>>>> On Aug 24, 2018, at 10:36 AM, Igor Ignatev wrote: >>>>> >>>>> Hi Erik, >>>>> >>>>> Unfortunately, just adding .cpp files to file list isn?t enough, as I mentioned in one of my previous emails[1], initially I did exactly that and linux-slowdebug build fails b/c c-linker was be used for .o files produced by cpp-compiler. >>>>> >>>>> I guess something like [2] might work. I'll play w/ this idea and send final patch latch. >>>>> >>>>> ? Igor >>>>> >>>>> [1] http://mail.openjdk.java.net/pipermail/build-dev/2018-August/022922.html >>>>> [2] TOOLCHAIN := $(if $$(filter %.cpp, $$(file)), TOOLCHAIN_LINK_CXX, TOOLCHAIN_DEFAULT) >>>>> >>>>>> On Aug 23, 2018, at 11:31 PM, Erik Joelsson wrote: >>>>>> >>>>>> Hello Igor, >>>>>> >>>>>> In TestFilesCompilation.gmk, there is no need to duplicate the whole macro call. If you want to find .cpp as well as .c files, just add that to the one list of files. The SetupNativeCompilation macro will automatically treat .c and .cpp correctly. >>>>>> >>>>>> Regarding the .c/.cpp files for your vmtestbase tests that include all the other files, this is an unfortunate solution, but I guess OK if it works. We certainly didn't intend it that way. The macro SetupTestFilesCompilation was intended for easily writing single file native exe and lib binaries without having to modify any makefile. The expectation was that if anything more complicated was needed (like multiple files per binary), we would just write explicit SetupNativeCompilation calls for them in JtregNativeHotspot.gmk. It now looks like we have a new pattern of source files/directories that turns into native libraries, and we could of course create a new macro that automatically generates compilation setups for them as well (given that file or directory names makes it possible to automatically determine everything needed). Of course, that change would be a separate cleanup possible if you want to. >>>>>> >>>>>> /Erik >>>>>> >>>>>>> On 2018-08-20 15:59, Igor Ignatyev wrote: >>>>>>> http://cr.openjdk.java.net/~iignatyev//8209611/webrev.01/index.html >>>>>>>> 11160 lines changed: 879 ins; 61 del; 10220 mod; >>>>>>> Hi all, >>>>>>> >>>>>>> could you please review the patch which moves all hotspot native test code to C++? this will guarantee that we always use C++ compilers for them (as an opposite to either C or C++ compiler depending on configuration), as a result we will be able to get rid of JNI_ENV_ARG[1] macros, perform other clean ups and improve overall quality of the test code. >>>>>>> >>>>>>> the patch consists of two parts: >>>>>>> - automatic: renaming .c files to .cpp, updating #include, changing JNI/JVMTI calls >>>>>>> - semi-manual: adding extern "C" , fixing a number of compiler warnings (mostly types inconsistency), updating makefiles >>>>>>> >>>>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8209611 >>>>>>> webrevs: >>>>>>> - automatic: http://cr.openjdk.java.net/~iignatyev//8209611/webrev.00/index.html >>>>>>>> 9394 lines changed: 0 ins; 0 del; 9394 mod; >>>>>>> - semi-manual: http://cr.openjdk.java.net/~iignatyev//8209611/webrev.0-1/index.html >>>>>>>> 1899 lines changed: 879 ins; 61 del; 959 mod >>>>>>> - whole: http://cr.openjdk.java.net/~iignatyev//8209611/webrev.01/index.html >>>>>>>> 11160 lines changed: 879 ins; 61 del; 10220 mod; >>>>>>> testing: all hotspot tests + tier[1-3] >>>>>>> >>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8209547 >>>>>>> >>>>>>> Thanks, >>>>>>> -- Igor > From coleen.phillimore at oracle.com Tue Aug 28 16:14:43 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 28 Aug 2018 12:14:43 -0400 Subject: RFR (trivial) 8210088: ProblemList gc/epsilon/TestMemoryMXBeans.java Message-ID: open webrev at http://cr.openjdk.java.net/~coleenp/8210088.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8210088 Ran the test with make run-test TEST=jtreg:gc/epsilon/TestMemoryMXBeans.java or rather didn't run the test: ============================== Test summary ============================== ?? TEST????????????????????????????????????????????? TOTAL? PASS FAIL ERROR ?? jtreg:open/test/hotspot/jtreg/gc/epsilon/TestMemoryMXBeans.java ???????????????????????????????????????????????????????? 0???? 0 0???? 0 ============================== TEST SUCCESS Thanks, Coleen From shade at redhat.com Tue Aug 28 16:18:16 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 28 Aug 2018 18:18:16 +0200 Subject: RFR (trivial) 8210088: ProblemList gc/epsilon/TestMemoryMXBeans.java In-Reply-To: References: Message-ID: <032ae293-1c1b-61d0-899f-9bcb9a2c1ec3@redhat.com> On 08/28/2018 06:14 PM, coleen.phillimore at oracle.com wrote: > open webrev at http://cr.openjdk.java.net/~coleenp/8210088.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8210088 Does it only happen with jdk/jdk11? Because jdk/jdk has the fix [1] that should make the test resistant to failures. -Aleksey [1] https://bugs.openjdk.java.net/browse/JDK-8209573 From erik.joelsson at oracle.com Tue Aug 28 16:25:32 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 28 Aug 2018 09:25:32 -0700 Subject: RFR: JDK-8202951: Implementation of JEPJDK-8204247: Include default CDS (Class Data Sharing) archive in JDK binary In-Reply-To: References: Message-ID: Build changes look good to me (but should probably get review from someone else). /Erik On 2018-08-27 13:33, Jiangli Zhou wrote: > Please review the implementation for JEP JDK-8204247 > (https://bugs.openjdk.java.net/browse/JDK-8204247). The goal of the > JEP is to include a default CDS archive in JDK 12 binary distribution > (downloadable from http://jdk.java.net/12/). The default CDS archive > is generated using the default classlist (resides in the lib/ > directory) at JDK build time. Any comments/suggestions are highly > appreciated. > > All makefile changes in the webrev are contributed by Erik Joelsson > (many thanks!!). > > This is a combination of efforts from different teams and individuals. > Thanks to everyone who has been involved in the JEP & implementation > discussions, testing and bug fixing! > > ? JEP: https://bugs.openjdk.java.net/browse/JDK-8204247 > ? RFE: https://bugs.openjdk.java.net/browse/JDK-8202951 > ? webrev: http://cr.openjdk.java.net/~jiangli/8202951/webrev.00/ > > Two sanity test cases for the default CDS archive are included > test/hotspot/jtreg/runtime/SharedArchiveFile. They are not intended > for in-depth CDS functional testing, which is already covered by the > existing cds/appcds tests and all tiered tests executing with the > default CDS archive enabled. > > As part of the webrev, > test/jdk/javax/imageio/plugins/png/ItxtUtf8Test.java is also fixed to > use larger java heap (JDK-8209739 > , https://bugs.openjdk.java.net/browse/JDK-8209739). > > Tests executed: > ?- several rounds of tier1 - tier8 via mach5 > ?- JCK lang, api and vm tests via mach5 > > > Thanks! > Calvin, Ioi, Jiangli > > From ioi.lam at oracle.com Tue Aug 28 16:33:17 2018 From: ioi.lam at oracle.com (Ioi Lam) Date: Tue, 28 Aug 2018 09:33:17 -0700 Subject: RFR: JDK-8202951: Implementation of JEPJDK-8204247: Include default CDS (Class Data Sharing) archive in JDK binary In-Reply-To: References: Message-ID: <979f56e4-07b4-8c52-c426-6ca5a839b6a3@oracle.com> The JVM and test changes look good. I just have one comment: CheckDefaultArchiveFile.java ? 51????? if (!Platform.isDefaultCDSArchiveSupported()) { ? 52???????????? if (Files.notExists(jsa)) { ? 53???????????????? System.out.println("Passed. " + vmString + ? 54??????????????????????????????????? ": no default classes.jsa file"); ? 55???????????? } else { ? 56???????????????? throw new RuntimeException(vmString + "contains " + jsaString); ? 57???????????? } People may manually do "java -Xshare:dump" on their own platforms and them run the hotspot tests. It seems too strict to treat this as an error. I think this block should be removed. Thanks - Ioi On 8/28/18 9:25 AM, Erik Joelsson wrote: > Build changes look good to me (but should probably get review from > someone else). > > /Erik > > > On 2018-08-27 13:33, Jiangli Zhou wrote: >> Please review the implementation for JEP JDK-8204247 >> (https://bugs.openjdk.java.net/browse/JDK-8204247). The goal of the >> JEP is to include a default CDS archive in JDK 12 binary distribution >> (downloadable from http://jdk.java.net/12/). The default CDS archive >> is generated using the default classlist (resides in the lib/ >> directory) at JDK build time. Any comments/suggestions are highly >> appreciated. >> >> All makefile changes in the webrev are contributed by Erik Joelsson >> (many thanks!!). >> >> This is a combination of efforts from different teams and >> individuals. Thanks to everyone who has been involved in the JEP & >> implementation discussions, testing and bug fixing! >> >> ? JEP: https://bugs.openjdk.java.net/browse/JDK-8204247 >> ? RFE: https://bugs.openjdk.java.net/browse/JDK-8202951 >> ? webrev: http://cr.openjdk.java.net/~jiangli/8202951/webrev.00/ >> >> Two sanity test cases for the default CDS archive are included >> test/hotspot/jtreg/runtime/SharedArchiveFile. They are not intended >> for in-depth CDS functional testing, which is already covered by the >> existing cds/appcds tests and all tiered tests executing with the >> default CDS archive enabled. >> >> As part of the webrev, >> test/jdk/javax/imageio/plugins/png/ItxtUtf8Test.java is also fixed to >> use larger java heap (JDK-8209739 >> , https://bugs.openjdk.java.net/browse/JDK-8209739). >> >> Tests executed: >> ?- several rounds of tier1 - tier8 via mach5 >> ?- JCK lang, api and vm tests via mach5 >> >> >> Thanks! >> Calvin, Ioi, Jiangli >> >> > From vladimir.x.ivanov at oracle.com Tue Aug 28 16:40:02 2018 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 28 Aug 2018 19:40:02 +0300 Subject: RFR(M/L) : 8209611 : use C++ compiler for hotspot tests In-Reply-To: <9759A264-829B-4A3D-A739-F8443150B57D@oracle.com> References: <92CD42CC-568A-4972-A35E-469B1532B103@oracle.com> <9f172999-2e45-8ebd-dba6-5d2d8927309b@oracle.com> <7d0ea30f-19c7-8a43-0616-fffb56bc5840@oracle.com> <29AD64D9-A86E-4105-8D07-F8EEC6B2B56E@oracle.com> <9759A264-829B-4A3D-A739-F8443150B57D@oracle.com> Message-ID: <01e66b66-1699-d3f9-5ebc-93b9d54526e8@oracle.com> > http://cr.openjdk.java.net/~iignatyev//8209611/webrev.02/index.html Reviewed. Best regards, Vladimir Ivanov >> On Aug 20, 2018, at 11:07 PM, Igor Ignatyev wrote: >> >>>> It has been discussed (not widely enough and I accept that) in 8209547 and the related email thread b/w JC(cc'ed) and myself. >>>> as I said, I might went a way too far, so I'll revert changes in the non-vmTestbase tests and made appropriate changes in makefiles. what do you think? >>> >>> I think I need to see what you mean exactly :) >> sure, it will take some time for me to do that, hopefully will upload new webrevs tomorrow morning PT. but the basic idea is to leave files in test/hotspot/jtreg/compiler, runtime, gc, native_sanity, serviceability, testlibrary as .c files, exactly as they were before, and restore corresponding filenames in make/test/JtregNativeHotspot.gmk. > From kim.barrett at oracle.com Tue Aug 28 17:29:03 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 28 Aug 2018 13:29:03 -0400 Subject: RFR: 8209976: Improve iteration over non-JavaThreads In-Reply-To: References: <5936CC9F-20A4-40CA-8256-3A52643899F5@oracle.com> <17d9a7d5-0e1c-3413-7ffc-116b5b8103dd@redhat.com> <78AD4F37-8673-4BDD-9B46-CD29A861C64E@oracle.com> <905BEA47-ADB2-4437-8688-183457DD41A5@oracle.com> Message-ID: <358BF3D3-61D8-4A23-BAF5-8F47E8CAD077@oracle.com> > On Aug 28, 2018, at 11:38 AM, coleen.phillimore at oracle.com wrote: > > > This looks good. Thank you for making Thread class abstract. Thanks for reviewing. > > Coleen > > On 8/27/18 9:36 PM, Kim Barrett wrote: >>> On Aug 27, 2018, at 2:08 PM, coleen.phillimore at oracle.com wrote: >>> >>> >>> This looks like a good improvement. So there are either JavaThreads or NonJavaThreads but no Thread now? Should Thread be made abstract so it cannot be instantiated? >> Thanks for reviewing. >> >> We don?t ever directly instantiate Thread. I can make it abstract. >> >> The canonical way to make a class abstract if it isn't already seems >> to be to make the virtual destructor pure. Below is the diff from >> open.01 that I'm running through testing. >> >> diff -r 7587d014de95 src/hotspot/share/runtime/thread.hpp >> --- a/src/hotspot/share/runtime/thread.hpp Mon Aug 27 13:17:40 2018 -0400 >> +++ b/src/hotspot/share/runtime/thread.hpp Mon Aug 27 21:20:05 2018 -0400 >> @@ -385,7 +385,7 @@ >> // Constructor >> Thread(); >> - virtual ~Thread(); >> + virtual ~Thread() = 0; // Thread is abstract. >> // Manage Thread::current() >> void initialize_thread_current(); >> >>> thanks, >>> Coleen >>> >>> On 8/27/18 1:34 PM, Kim Barrett wrote: >>>>> On Aug 27, 2018, at 12:09 PM, Kim Barrett wrote: >>>>> Hm, except that I seem to have forgotten to remove the >>>>> now obsolete asserts from GlobalCounter::critical_section_begin/end. >>>> New webrevs: >>>> full: http://cr.openjdk.java.net/~kbarrett/8209976/open.01/ >>>> incr: http://cr.openjdk.java.net/~kbarrett/8209976/open.01.inc/ From martin.doerr at sap.com Tue Aug 28 17:34:44 2018 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 28 Aug 2018 17:34:44 +0000 Subject: RFR: 8208171: PPC64: Enrich SLP support In-Reply-To: References: Message-ID: <346da54af45243c4bdaf475f118a450d@sap.com> Hi Michihiro, thank you for implementing it. I have just taken a first look at your webrev.01. It looks basically good. Only the Power version check seems to be incorrect. VM_Version::has_popcntb() checks for Power5. I believe most instructions are available with Power7. Some ones (vsubudm, ..., vmmuluwm, vpopcntw) were introduced with Power8? We should check this carefully. Also, indentation in register_ppc.hpp could get improved. Thanks and best regard, Martin -----Original Message----- From: Gustavo Romero Sent: Donnerstag, 26. Juli 2018 16:02 To: Michihiro Horie Cc: Lindenmaier, Goetz ; hotspot-dev at openjdk.java.net; Doerr, Martin ; ppc-aix-port-dev at openjdk.java.net; Simonis, Volker Subject: Re: RFR: 8208171: PPC64: Enrich SLP support Hi Michi, On 07/26/2018 01:43 AM, Michihiro Horie wrote: > I updated webrev: > http://cr.openjdk.java.net/~mhorie/8208171/webrev.01/ Thanks for providing an updated webrev and for fixing indentation and function order in assembler_ppc.inline.hpp as well. I have no further comments :) Best Regards, Gustavo > > Best regards, > -- > Michihiro, > IBM Research - Tokyo > > Inactive hide details for Gustavo Romero ---2018/07/25 23:05:32---Hi Michi, On 07/25/2018 02:43 AM, Michihiro Horie wrote:Gustavo Romero ---2018/07/25 23:05:32---Hi Michi, On 07/25/2018 02:43 AM, Michihiro Horie wrote: > > From: Gustavo Romero > To: Michihiro Horie/Japan/IBM at IBMJP, ppc-aix-port-dev at openjdk.java.net, hotspot-dev at openjdk.java.net > Cc: goetz.lindenmaier at sap.com, volker.simonis at sap.com, "Doerr, Martin" > Date: 2018/07/25 23:05 > Subject: Re: RFR: 8208171: PPC64: Enrich SLP support > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > > > > Hi Michi, > > On 07/25/2018 02:43 AM, Michihiro Horie wrote: > > Dear all, > > > > Would you review the following change? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8208171 > > Webrev: http://cr.openjdk.java.net/~mhorie/8208171/webrev.00 > > > > This change adds support for vectorized arithmetic calculation with SLP. > > > > The to_vr function is added to convert VSR to VR. Currently, vecX is associated with a VSR class vs_reg that only defines VSR32-51 in ppc.ad, which are exactly overlapped with VRs. Instruction APIs receiving VRs use the to_vr via vecX. Another thing is the change in sqrtF_reg to enable the matching with SqrtVF. I think the change in sqrtF_reg would be fine due to the ConvD2FNode::Value in convertnode.cpp. > > Looks good. Just a few comments: > > - In vmul4F_reg() would it be reasonable to use xvmulsp instead of vmaddfp in > order to avoid the splat? > > - Although all instructions added by your change where introduced in ISA 2.06, > so POWER7 and above are OK, as I see probes for PowerArchictecturePPC64=6|5 in > vm_version_ppc.cpp (line 64), I'm wondering if there is any control point to > guarantee that these instructions won't be emitted on a CPU that does not > support them. > > - I think that in general string in format %{} are in upper case. For instance, > this the current output on optoassembly for vmul4F: > > 2941835 5b4 ADDI R24, R24, #64 > 2941836 5b8 vmaddfp VSR32,VSR32,VSR36 ! mul packed4F > 2941837 5c0 STXVD2X [R17], VSR32 // store 16-byte Vector > > I think it would be better to be in upper case instead. I also think that if > the node match emits more than one instruction all instructions must be listed > in format %{}, since it's meant for detailed debugging. Finally I think it > would be better to replace \t! by \t// in that string (unless I'm missing any > special meaning for that char). So for vmul4F it would be something like: > > 2941835 5b4 ADDI R24, R24, #64 > VSPLTISW VSR34, 0 // Splat 0 imm in VSR34 > 2941836 5b8 VMADDFP VSR32,VSR32,VSR36,VSR34 // Mul packed4F > 2941837 5c0 STXVD2X [R17], VSR32 // store 16-byte Vector > > > But feel free to change anything just after you get additional reviews :) > > > > I confirmed this change with JTREG. In addition, I used attached micro benchmarks. > > /(See attached file: slp_microbench.zip)/ > > Thanks for sharing it. > Btw, another option to host it would be in the CR > server, in http://cr.openjdk.java.net/~mhorie/8208171 > > > Best regards, > Gustavo > > > > > Best regards, > > -- > > Michihiro, > > IBM Research - Tokyo > > > > > From rkennke at redhat.com Tue Aug 28 17:38:10 2018 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 28 Aug 2018 19:38:10 +0200 Subject: RFR: 8209976: Improve iteration over non-JavaThreads In-Reply-To: References: <5936CC9F-20A4-40CA-8256-3A52643899F5@oracle.com> <17d9a7d5-0e1c-3413-7ffc-116b5b8103dd@redhat.com> <78AD4F37-8673-4BDD-9B46-CD29A861C64E@oracle.com> <905BEA47-ADB2-4437-8688-183457DD41A5@oracle.com> Message-ID: <30951f44-8c29-f362-892b-f84d4274c9d1@redhat.com> Looks good to me too. Roman > > This looks good.? Thank you for making Thread class abstract. > > Coleen > > On 8/27/18 9:36 PM, Kim Barrett wrote: >>> On Aug 27, 2018, at 2:08 PM, coleen.phillimore at oracle.com wrote: >>> >>> >>> This looks like a good improvement.? So there are either JavaThreads >>> or NonJavaThreads but no Thread now??? Should Thread be made abstract >>> so it cannot be instantiated? >> Thanks for reviewing. >> >> We don?t ever directly instantiate Thread.? I can make it abstract. >> >> The canonical way to make a class abstract if it isn't already seems >> to be to make the virtual destructor pure. Below is the diff from >> open.01 that I'm running through testing. >> >> diff -r 7587d014de95 src/hotspot/share/runtime/thread.hpp >> --- a/src/hotspot/share/runtime/thread.hpp??? Mon Aug 27 13:17:40 2018 >> -0400 >> +++ b/src/hotspot/share/runtime/thread.hpp??? Mon Aug 27 21:20:05 2018 >> -0400 >> @@ -385,7 +385,7 @@ >> ? ??? // Constructor >> ??? Thread(); >> -? virtual ~Thread(); >> +? virtual ~Thread() = 0;??????? // Thread is abstract. >> ? ??? // Manage Thread::current() >> ??? void initialize_thread_current(); >> >>> thanks, >>> Coleen >>> >>> On 8/27/18 1:34 PM, Kim Barrett wrote: >>>>> On Aug 27, 2018, at 12:09 PM, Kim Barrett >>>>> wrote: >>>>> Hm, except that I seem to have forgotten to remove the >>>>> now obsolete asserts from GlobalCounter::critical_section_begin/end. >>>> New webrevs: >>>> full: http://cr.openjdk.java.net/~kbarrett/8209976/open.01/ >>>> incr: http://cr.openjdk.java.net/~kbarrett/8209976/open.01.inc/ >> > From jiangli.zhou at oracle.com Tue Aug 28 17:50:39 2018 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Tue, 28 Aug 2018 10:50:39 -0700 Subject: RFR: JDK-8202951: Implementation of JEPJDK-8204247: Include default CDS (Class Data Sharing) archive in JDK binary In-Reply-To: References: Message-ID: Thanks, Erik! Jiangli On 8/28/18 9:25 AM, Erik Joelsson wrote: > Build changes look good to me (but should probably get review from > someone else). > > /Erik > > > On 2018-08-27 13:33, Jiangli Zhou wrote: >> Please review the implementation for JEP JDK-8204247 >> (https://bugs.openjdk.java.net/browse/JDK-8204247). The goal of the >> JEP is to include a default CDS archive in JDK 12 binary distribution >> (downloadable from http://jdk.java.net/12/). The default CDS archive >> is generated using the default classlist (resides in the lib/ >> directory) at JDK build time. Any comments/suggestions are highly >> appreciated. >> >> All makefile changes in the webrev are contributed by Erik Joelsson >> (many thanks!!). >> >> This is a combination of efforts from different teams and >> individuals. Thanks to everyone who has been involved in the JEP & >> implementation discussions, testing and bug fixing! >> >> ? JEP: https://bugs.openjdk.java.net/browse/JDK-8204247 >> ? RFE: https://bugs.openjdk.java.net/browse/JDK-8202951 >> ? webrev: http://cr.openjdk.java.net/~jiangli/8202951/webrev.00/ >> >> Two sanity test cases for the default CDS archive are included >> test/hotspot/jtreg/runtime/SharedArchiveFile. They are not intended >> for in-depth CDS functional testing, which is already covered by the >> existing cds/appcds tests and all tiered tests executing with the >> default CDS archive enabled. >> >> As part of the webrev, >> test/jdk/javax/imageio/plugins/png/ItxtUtf8Test.java is also fixed to >> use larger java heap (JDK-8209739 >> , https://bugs.openjdk.java.net/browse/JDK-8209739). >> >> Tests executed: >> ?- several rounds of tier1 - tier8 via mach5 >> ?- JCK lang, api and vm tests via mach5 >> >> >> Thanks! >> Calvin, Ioi, Jiangli >> >> > From jiangli.zhou at oracle.com Tue Aug 28 18:09:30 2018 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Tue, 28 Aug 2018 11:09:30 -0700 Subject: RFR: JDK-8202951: Implementation of JEPJDK-8204247: Include default CDS (Class Data Sharing) archive in JDK binary In-Reply-To: <979f56e4-07b4-8c52-c426-6ca5a839b6a3@oracle.com> References: <979f56e4-07b4-8c52-c426-6ca5a839b6a3@oracle.com> Message-ID: <1af91463-05f5-30ed-7ef0-eeb558e12451@oracle.com> On 8/28/18 9:33 AM, Ioi Lam wrote: > The JVM and test changes look good. I just have one comment: > > > CheckDefaultArchiveFile.java > > ? 51????? if (!Platform.isDefaultCDSArchiveSupported()) { > ? 52???????????? if (Files.notExists(jsa)) { > ? 53???????????????? System.out.println("Passed. " + vmString + > ? 54??????????????????????????????????? ": no default classes.jsa file"); > ? 55???????????? } else { > ? 56???????????????? throw new RuntimeException(vmString + "contains " > + jsaString); > ? 57???????????? } > > > People may manually do "java -Xshare:dump" on their own platforms and > them run the hotspot tests. It seems too strict to treat this as an > error. > > I think this block should be removed. That's probably a common scenario. I agree, it is too strict. Will remove the block. Thanks! Jiangli > > Thanks > > - Ioi > > > On 8/28/18 9:25 AM, Erik Joelsson wrote: >> Build changes look good to me (but should probably get review from >> someone else). >> >> /Erik >> >> >> On 2018-08-27 13:33, Jiangli Zhou wrote: >>> Please review the implementation for JEP JDK-8204247 >>> (https://bugs.openjdk.java.net/browse/JDK-8204247). The goal of the >>> JEP is to include a default CDS archive in JDK 12 binary >>> distribution (downloadable from http://jdk.java.net/12/). The >>> default CDS archive is generated using the default classlist >>> (resides in the lib/ directory) at JDK build time. Any >>> comments/suggestions are highly appreciated. >>> >>> All makefile changes in the webrev are contributed by Erik Joelsson >>> (many thanks!!). >>> >>> This is a combination of efforts from different teams and >>> individuals. Thanks to everyone who has been involved in the JEP & >>> implementation discussions, testing and bug fixing! >>> >>> ? JEP: https://bugs.openjdk.java.net/browse/JDK-8204247 >>> ? RFE: https://bugs.openjdk.java.net/browse/JDK-8202951 >>> ? webrev: http://cr.openjdk.java.net/~jiangli/8202951/webrev.00/ >>> >>> Two sanity test cases for the default CDS archive are included >>> test/hotspot/jtreg/runtime/SharedArchiveFile. They are not intended >>> for in-depth CDS functional testing, which is already covered by the >>> existing cds/appcds tests and all tiered tests executing with the >>> default CDS archive enabled. >>> >>> As part of the webrev, >>> test/jdk/javax/imageio/plugins/png/ItxtUtf8Test.java is also fixed >>> to use larger java heap (JDK-8209739 >>> , https://bugs.openjdk.java.net/browse/JDK-8209739). >>> >>> Tests executed: >>> ?- several rounds of tier1 - tier8 via mach5 >>> ?- JCK lang, api and vm tests via mach5 >>> >>> >>> Thanks! >>> Calvin, Ioi, Jiangli >>> >>> >> > From coleen.phillimore at oracle.com Tue Aug 28 18:37:20 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 28 Aug 2018 14:37:20 -0400 Subject: RFR (trivial) 8210088: ProblemList gc/epsilon/TestMemoryMXBeans.java In-Reply-To: <032ae293-1c1b-61d0-899f-9bcb9a2c1ec3@redhat.com> References: <032ae293-1c1b-61d0-899f-9bcb9a2c1ec3@redhat.com> Message-ID: On 8/28/18 12:18 PM, Aleksey Shipilev wrote: > On 08/28/2018 06:14 PM, coleen.phillimore at oracle.com wrote: >> open webrev at http://cr.openjdk.java.net/~coleenp/8210088.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8210088 > Does it only happen with jdk/jdk11? Because jdk/jdk has the fix [1] that should make the test > resistant to failures. I'm getting this failure with all my tier7 testing with the main repo. Coleen > > -Aleksey > > [1] https://bugs.openjdk.java.net/browse/JDK-8209573 > From coleen.phillimore at oracle.com Tue Aug 28 18:46:11 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 28 Aug 2018 14:46:11 -0400 Subject: RFR (trivial) 8210088: ProblemList gc/epsilon/TestMemoryMXBeans.java In-Reply-To: References: <032ae293-1c1b-61d0-899f-9bcb9a2c1ec3@redhat.com> Message-ID: On 8/28/18 2:37 PM, coleen.phillimore at oracle.com wrote: > > > On 8/28/18 12:18 PM, Aleksey Shipilev wrote: >> On 08/28/2018 06:14 PM, coleen.phillimore at oracle.com wrote: >>> open webrev at http://cr.openjdk.java.net/~coleenp/8210088.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8210088 >> Does it only happen with jdk/jdk11? Because jdk/jdk has the fix [1] >> that should make the test >> resistant to failures. > > I'm getting this failure with all my tier7 testing with the main repo. I just did a view history command in mach5 and it's been failing for everybody. Coleen > > Coleen >> >> -Aleksey >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8209573 >> > From kim.barrett at oracle.com Tue Aug 28 20:02:34 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 28 Aug 2018 16:02:34 -0400 Subject: RFR: 8209976: Improve iteration over non-JavaThreads In-Reply-To: <30951f44-8c29-f362-892b-f84d4274c9d1@redhat.com> References: <5936CC9F-20A4-40CA-8256-3A52643899F5@oracle.com> <17d9a7d5-0e1c-3413-7ffc-116b5b8103dd@redhat.com> <78AD4F37-8673-4BDD-9B46-CD29A861C64E@oracle.com> <905BEA47-ADB2-4437-8688-183457DD41A5@oracle.com> <30951f44-8c29-f362-892b-f84d4274c9d1@redhat.com> Message-ID: > On Aug 28, 2018, at 1:38 PM, Roman Kennke wrote: > > Looks good to me too. Thanks. > > Roman > >> >> This looks good. Thank you for making Thread class abstract. >> >> Coleen >> >> On 8/27/18 9:36 PM, Kim Barrett wrote: >>>> On Aug 27, 2018, at 2:08 PM, coleen.phillimore at oracle.com wrote: >>>> >>>> >>>> This looks like a good improvement. So there are either JavaThreads >>>> or NonJavaThreads but no Thread now? Should Thread be made abstract >>>> so it cannot be instantiated? >>> Thanks for reviewing. >>> >>> We don?t ever directly instantiate Thread. I can make it abstract. >>> >>> The canonical way to make a class abstract if it isn't already seems >>> to be to make the virtual destructor pure. Below is the diff from >>> open.01 that I'm running through testing. >>> >>> diff -r 7587d014de95 src/hotspot/share/runtime/thread.hpp >>> --- a/src/hotspot/share/runtime/thread.hpp Mon Aug 27 13:17:40 2018 >>> -0400 >>> +++ b/src/hotspot/share/runtime/thread.hpp Mon Aug 27 21:20:05 2018 >>> -0400 >>> @@ -385,7 +385,7 @@ >>> // Constructor >>> Thread(); >>> - virtual ~Thread(); >>> + virtual ~Thread() = 0; // Thread is abstract. >>> // Manage Thread::current() >>> void initialize_thread_current(); >>> >>>> thanks, >>>> Coleen >>>> >>>> On 8/27/18 1:34 PM, Kim Barrett wrote: >>>>>> On Aug 27, 2018, at 12:09 PM, Kim Barrett >>>>>> wrote: >>>>>> Hm, except that I seem to have forgotten to remove the >>>>>> now obsolete asserts from GlobalCounter::critical_section_begin/end. >>>>> New webrevs: >>>>> full: http://cr.openjdk.java.net/~kbarrett/8209976/open.01/ >>>>> incr: http://cr.openjdk.java.net/~kbarrett/8209976/open.01.inc/ From Derek.White at cavium.com Tue Aug 28 20:16:48 2018 From: Derek.White at cavium.com (White, Derek) Date: Tue, 28 Aug 2018 20:16:48 +0000 Subject: [aarch64-port-dev ] RFC: JEP - One AArch64 Port, Not Two In-Reply-To: References: Message-ID: Hi Bob, I support this JEP as well. - Derek > -----Original Message----- > From: aarch64-port-dev [mailto:aarch64-port-dev- > bounces at openjdk.java.net] On Behalf Of Bob Vandette > Sent: Thursday, August 23, 2018 11:14 AM > To: HotSpot Open Source Developers > Cc: aarch64-port-dev at openjdk.java.net > Subject: [aarch64-port-dev ] RFC: JEP - One AArch64 Port, Not Two > > As a follow-on to the previous thread "ARM port consolidation? [1], please > review and comment on this newly filed JEP that removes one of the two > AArch64 ports from the JDK. > > JEP: > > https://bugs.openjdk.java.net/browse/JDK-8209093 > > > Here?s a prototype of the changes that would be done under this JEP. > > http://cr.openjdk.java.net/~bobv/8209093/webrev.00 > > > [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2018- > June/032756.html > > Bob. > > > From kim.barrett at oracle.com Tue Aug 28 20:59:45 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 28 Aug 2018 16:59:45 -0400 Subject: RFR (trivial) 8210088: ProblemList gc/epsilon/TestMemoryMXBeans.java In-Reply-To: References: Message-ID: > On Aug 28, 2018, at 12:14 PM, coleen.phillimore at oracle.com wrote: > > open webrev at http://cr.openjdk.java.net/~coleenp/8210088.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8210088 > > Ran the test with make run-test TEST=jtreg:gc/epsilon/TestMemoryMXBeans.java > or rather didn't run the test: > > ============================== > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR > jtreg:open/test/hotspot/jtreg/gc/epsilon/TestMemoryMXBeans.java > 0 0 0 0 > ============================== > TEST SUCCESS > > Thanks, > Coleen Looks good. From coleen.phillimore at oracle.com Tue Aug 28 21:09:59 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 28 Aug 2018 17:09:59 -0400 Subject: RFR (trivial) 8210088: ProblemList gc/epsilon/TestMemoryMXBeans.java In-Reply-To: References: Message-ID: Thanks, Kim. Coleen On 8/28/18 4:59 PM, Kim Barrett wrote: >> On Aug 28, 2018, at 12:14 PM, coleen.phillimore at oracle.com wrote: >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8210088.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8210088 >> >> Ran the test with make run-test TEST=jtreg:gc/epsilon/TestMemoryMXBeans.java >> or rather didn't run the test: >> >> ============================== >> Test summary >> ============================== >> TEST TOTAL PASS FAIL ERROR >> jtreg:open/test/hotspot/jtreg/gc/epsilon/TestMemoryMXBeans.java >> 0 0 0 0 >> ============================== >> TEST SUCCESS >> >> Thanks, >> Coleen > Looks good. > From jiangli.zhou at oracle.com Tue Aug 28 21:13:35 2018 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Tue, 28 Aug 2018 14:13:35 -0700 Subject: RFR (trivial) 8210088: ProblemList gc/epsilon/TestMemoryMXBeans.java In-Reply-To: References: Message-ID: Looks good. I've seen it in my jobs for the default CDS archive tests also. Looking at the failure history, it fails in multiple jobs almost everyday. Thanks, Jiangli On 8/28/18 9:14 AM, coleen.phillimore at oracle.com wrote: > open webrev at http://cr.openjdk.java.net/~coleenp/8210088.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8210088 > > Ran the test with make run-test > TEST=jtreg:gc/epsilon/TestMemoryMXBeans.java > or rather didn't run the test: > > ============================== > Test summary > ============================== > ?? TEST????????????????????????????????????????????? TOTAL? PASS FAIL > ERROR > ?? jtreg:open/test/hotspot/jtreg/gc/epsilon/TestMemoryMXBeans.java > ???????????????????????????????????????????????????????? 0???? 0 0???? 0 > ============================== > TEST SUCCESS > > Thanks, > Coleen From coleen.phillimore at oracle.com Tue Aug 28 21:15:08 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 28 Aug 2018 17:15:08 -0400 Subject: RFR (trivial) 8210088: ProblemList gc/epsilon/TestMemoryMXBeans.java In-Reply-To: References: Message-ID: Thanks, Jiangli! Coleen On 8/28/18 5:13 PM, Jiangli Zhou wrote: > Looks good. I've seen it in my jobs for the default CDS archive tests > also. Looking at the failure history, it fails in multiple jobs almost > everyday. > > Thanks, > > Jiangli > > > On 8/28/18 9:14 AM, coleen.phillimore at oracle.com wrote: >> open webrev at http://cr.openjdk.java.net/~coleenp/8210088.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8210088 >> >> Ran the test with make run-test >> TEST=jtreg:gc/epsilon/TestMemoryMXBeans.java >> or rather didn't run the test: >> >> ============================== >> Test summary >> ============================== >> ?? TEST????????????????????????????????????????????? TOTAL? PASS FAIL >> ERROR >> jtreg:open/test/hotspot/jtreg/gc/epsilon/TestMemoryMXBeans.java >> ???????????????????????????????????????????????????????? 0???? 0 0???? 0 >> ============================== >> TEST SUCCESS >> >> Thanks, >> Coleen > From vladimir.kozlov at oracle.com Tue Aug 28 22:48:17 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 28 Aug 2018 15:48:17 -0700 Subject: [12] RFR(M) 8209594: guarantee(this->is8bit(imm8)) failed: Short forward jump exceeds 8-bit offset In-Reply-To: <067e065e-fe7f-c56b-a16a-1f67b18451f6@oracle.com> References: <067e065e-fe7f-c56b-a16a-1f67b18451f6@oracle.com> Message-ID: Thank you, Dean On 8/27/18 10:21 AM, dean.long at oracle.com wrote: > Looks good.? I did not review avx changes. > > A couple questions: > > Did you consider adding "const char* file = NULL, int line = 0" for x86 only instead of all platforms? Unfortunately pd_patch_instruction() method which is called from shared Label::patch_instructions() is not virtual and is declared on all platforms. Also I think other platforms can implement this functionality using new API. > > Are _file[] and _line[] arrays every used? They are used in macroAssembler_x86.hpp in guarantee() in pd_patch_instruction() which is called when forward branches are processed in bind(Label): http://cr.openjdk.java.net/~kvn/8209594/webrev.05/src/hotspot/cpu/x86/macroAssembler_x86.hpp.udiff.html Thanks, Vladimir > > dl > > On 8/25/18 1:05 PM, Vladimir Kozlov wrote: >> http://cr.openjdk.java.net/~kvn/8209594/webrev.05/ >> https://bugs.openjdk.java.net/browse/JDK-8209594 >> >> All platforms are affected. Please, test. >> >> I instrumented code to generated biggest code and find all possible incorrect short jumps. This is >> the result. >> >> Changed jump instruction patching API to added jump's source location in debug build but >> implemented it only on x86. I tired to search instructions by code offsets. I used very simple macro: >> >> #define jmpb(L) jmpb_0(L, __FILE__, __LINE__) >> >> 'do {} while(0)' does not work here because I need to replace non-static method. I will be glad if >> someone can give better suggestion how implement this macro. >> >> Fixed incorrect avx512 code in macroAssembler_x86.cpp and x86.ad file. There were missing >> instructions and incorrect instructions (copy-paste typos). >> >> Fixed C2 scratch buffer sizing. It did not take into account everything and as result from >> MAX_inst_size=1024 only 700 bytes were available. I hit this issue when RTM locking was generated >> for FastLock node. >> >> Tested tier1-3 on all our platforms. And also running these tiers on avx512 machine. >> > From vladimir.kozlov at oracle.com Tue Aug 28 23:07:01 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 28 Aug 2018 16:07:01 -0700 Subject: [12] RFR(M) 8209594: guarantee(this->is8bit(imm8)) failed: Short forward jump exceeds 8-bit offset In-Reply-To: References: Message-ID: <3f5965f4-9281-3816-b2a8-76f2ed14535c@oracle.com> Thank you, Chuck On 8/27/18 11:00 AM, Chuck Rasbold wrote: > Thanks, Vladimir. This looks good to me also. > > We also recently detected the failing guarantee for jmpb(CLEANUP) in > MacroAssembler::string_indexof(). > Your new diagnostics are better than the ones I was working on. > > How did you instrument the code to generate the largest possible code > sequence? I found a couple of incorrect short jumps in > vectorized_mismatch() which may be considered false positives; the xmm > registers always are in the lower bank. Manual work :( http://cr.openjdk.java.net/~kvn/8209594/webrev.04/ I instrumented few methods which may generate different code in assembler_x86.cpp. And I found all avx512 macroAssembler instructions and faked upper bank usage to generate worse code. See changes which include instrumentation in macroAssembler_x86.cpp: I also disable AVX512BW and AVX512VL cpu features in vm_version_x86.cpp to execute .ad instructions guarded by supports_avx512nobw() and other changes. Unfortunately it failed several tests related to String intrinsics so I did not want to spent time on investigation and excluded instrumentation. You are right about false positive in vectorized_mismatch() but it is not guarantied that it will be used only in this one place in a future. Regards, Vladimir > > > > > On Sat, Aug 25, 2018 at 1:05 PM, Vladimir Kozlov > wrote: > >> http://cr.openjdk.java.net/~kvn/8209594/webrev.05/ >> https://bugs.openjdk.java.net/browse/JDK-8209594 >> >> All platforms are affected. Please, test. >> >> I instrumented code to generated biggest code and find all possible >> incorrect short jumps. This is the result. >> >> Changed jump instruction patching API to added jump's source location in >> debug build but implemented it only on x86. I tired to search instructions >> by code offsets. I used very simple macro: >> >> #define jmpb(L) jmpb_0(L, __FILE__, __LINE__) >> >> 'do {} while(0)' does not work here because I need to replace non-static >> method. I will be glad if someone can give better suggestion how implement >> this macro. >> >> Fixed incorrect avx512 code in macroAssembler_x86.cpp and x86.ad file. >> There were missing instructions and incorrect instructions (copy-paste >> typos). >> >> Fixed C2 scratch buffer sizing. It did not take into account everything >> and as result from MAX_inst_size=1024 only 700 bytes were available. I hit >> this issue when RTM locking was generated for FastLock node. >> >> Tested tier1-3 on all our platforms. And also running these tiers on >> avx512 machine. >> >> -- >> Thanks, >> Vladimir >> From dean.long at oracle.com Tue Aug 28 23:44:05 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 28 Aug 2018 16:44:05 -0700 Subject: [12] RFR(M) 8209594: guarantee(this->is8bit(imm8)) failed: Short forward jump exceeds 8-bit offset In-Reply-To: References: <067e065e-fe7f-c56b-a16a-1f67b18451f6@oracle.com> Message-ID: <46f3c107-5024-6f12-4809-d9dcdea9e4ca@oracle.com> On 8/28/18 3:48 PM, Vladimir Kozlov wrote: > Thank you, Dean > > On 8/27/18 10:21 AM, dean.long at oracle.com wrote: >> Looks good.? I did not review avx changes. >> >> A couple questions: >> >> Did you consider adding "const char* file = NULL, int line = 0" for >> x86 only instead of all platforms? > > Unfortunately pd_patch_instruction() method which is called from > shared Label::patch_instructions() is not virtual and is declared on > all platforms. > Also I think other platforms can implement this functionality using > new API. > OK. >> >> Are _file[] and _line[] arrays every used? > > They are used in macroAssembler_x86.hpp in guarantee() in > pd_patch_instruction() which is called when forward branches are > processed in bind(Label): > > http://cr.openjdk.java.net/~kvn/8209594/webrev.05/src/hotspot/cpu/x86/macroAssembler_x86.hpp.udiff.html > > Actually I was asking about these two: +#ifdef ASSERT + // Sourcre file and line location of jump instruction + int _lines[PatchCacheSize]; + const char* _files[PatchCacheSize]; +#endif but I see now the use in Label::patch_instructions(). dl > Thanks, > Vladimir > >> >> dl >> >> On 8/25/18 1:05 PM, Vladimir Kozlov wrote: >>> http://cr.openjdk.java.net/~kvn/8209594/webrev.05/ >>> https://bugs.openjdk.java.net/browse/JDK-8209594 >>> >>> All platforms are affected. Please, test. >>> >>> I instrumented code to generated biggest code and find all possible >>> incorrect short jumps. This is the result. >>> >>> Changed jump instruction patching API to added jump's source >>> location in debug build but implemented it only on x86. I tired to >>> search instructions by code offsets. I used very simple macro: >>> >>> #define jmpb(L) jmpb_0(L, __FILE__, __LINE__) >>> >>> 'do {} while(0)' does not work here because I need to replace >>> non-static method. I will be glad if someone can give better >>> suggestion how implement this macro. >>> >>> Fixed incorrect avx512 code in macroAssembler_x86.cpp and x86.ad >>> file. There were missing instructions and incorrect instructions >>> (copy-paste typos). >>> >>> Fixed C2 scratch buffer sizing. It did not take into account >>> everything and as result from MAX_inst_size=1024 only 700 bytes were >>> available. I hit this issue when RTM locking was generated for >>> FastLock node. >>> >>> Tested tier1-3 on all our platforms. And also running these tiers on >>> avx512 machine. >>> >> From kim.barrett at oracle.com Wed Aug 29 00:55:03 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 28 Aug 2018 20:55:03 -0400 Subject: RFR: 8210119: Rename SubTasksDone::is_task_claimed Message-ID: <6207B24F-BDB5-4AEF-BB38-DA361847C376@oracle.com> [Sending to hotspot-dev because, though this is a GC utility, it's also being used in runtime/safepoint.cpp.] Please review this small API naming cleanup. CR: https://bugs.openjdk.java.net/browse/JDK-8210119 Webrev: http://cr.openjdk.java.net/~kbarrett/8210119/open.00/ Testing: mach5 tier1-3 From jiangli.zhou at oracle.com Wed Aug 29 01:32:59 2018 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Tue, 28 Aug 2018 18:32:59 -0700 Subject: RFR: JDK-8202951: Implementation of JEPJDK-8204247: Include default CDS (Class Data Sharing) archive in JDK binary In-Reply-To: <1af91463-05f5-30ed-7ef0-eeb558e12451@oracle.com> References: <979f56e4-07b4-8c52-c426-6ca5a839b6a3@oracle.com> <1af91463-05f5-30ed-7ef0-eeb558e12451@oracle.com> Message-ID: Here is the updated webre with CheckDefaultArchiveFile.java changes. ? http://cr.openjdk.java.net/~jiangli/8202951/webrev.01/ Thanks, Jiangli On 8/28/18 11:09 AM, Jiangli Zhou wrote: > On 8/28/18 9:33 AM, Ioi Lam wrote: >> The JVM and test changes look good. I just have one comment: >> >> >> CheckDefaultArchiveFile.java >> >> ? 51????? if (!Platform.isDefaultCDSArchiveSupported()) { >> ? 52???????????? if (Files.notExists(jsa)) { >> ? 53???????????????? System.out.println("Passed. " + vmString + >> ? 54??????????????????????????????????? ": no default classes.jsa >> file"); >> ? 55???????????? } else { >> ? 56???????????????? throw new RuntimeException(vmString + "contains >> " + jsaString); >> ? 57???????????? } >> >> >> People may manually do "java -Xshare:dump" on their own platforms and >> them run the hotspot tests. It seems too strict to treat this as an >> error. >> >> I think this block should be removed. > That's probably a common scenario. I agree, it is too strict. Will > remove the block. > > Thanks! > > Jiangli > >> >> Thanks >> >> - Ioi >> >> >> On 8/28/18 9:25 AM, Erik Joelsson wrote: >>> Build changes look good to me (but should probably get review from >>> someone else). >>> >>> /Erik >>> >>> >>> On 2018-08-27 13:33, Jiangli Zhou wrote: >>>> Please review the implementation for JEP JDK-8204247 >>>> (https://bugs.openjdk.java.net/browse/JDK-8204247). The goal of the >>>> JEP is to include a default CDS archive in JDK 12 binary >>>> distribution (downloadable from http://jdk.java.net/12/). The >>>> default CDS archive is generated using the default classlist >>>> (resides in the lib/ directory) at JDK build time. Any >>>> comments/suggestions are highly appreciated. >>>> >>>> All makefile changes in the webrev are contributed by Erik Joelsson >>>> (many thanks!!). >>>> >>>> This is a combination of efforts from different teams and >>>> individuals. Thanks to everyone who has been involved in the JEP & >>>> implementation discussions, testing and bug fixing! >>>> >>>> ? JEP: https://bugs.openjdk.java.net/browse/JDK-8204247 >>>> ? RFE: https://bugs.openjdk.java.net/browse/JDK-8202951 >>>> ? webrev: http://cr.openjdk.java.net/~jiangli/8202951/webrev.00/ >>>> >>>> Two sanity test cases for the default CDS archive are included >>>> test/hotspot/jtreg/runtime/SharedArchiveFile. They are not intended >>>> for in-depth CDS functional testing, which is already covered by >>>> the existing cds/appcds tests and all tiered tests executing with >>>> the default CDS archive enabled. >>>> >>>> As part of the webrev, >>>> test/jdk/javax/imageio/plugins/png/ItxtUtf8Test.java is also fixed >>>> to use larger java heap (JDK-8209739 >>>> , https://bugs.openjdk.java.net/browse/JDK-8209739). >>>> >>>> Tests executed: >>>> ?- several rounds of tier1 - tier8 via mach5 >>>> ?- JCK lang, api and vm tests via mach5 >>>> >>>> >>>> Thanks! >>>> Calvin, Ioi, Jiangli >>>> >>>> >>> >> > From vladimir.kozlov at oracle.com Wed Aug 29 02:24:15 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 28 Aug 2018 19:24:15 -0700 Subject: [12] RFR(M) 8209594: guarantee(this->is8bit(imm8)) failed: Short forward jump exceeds 8-bit offset In-Reply-To: <46f3c107-5024-6f12-4809-d9dcdea9e4ca@oracle.com> References: <067e065e-fe7f-c56b-a16a-1f67b18451f6@oracle.com> <46f3c107-5024-6f12-4809-d9dcdea9e4ca@oracle.com> Message-ID: Thank you, Dean Vladimir On 8/28/18 4:44 PM, dean.long at oracle.com wrote: > On 8/28/18 3:48 PM, Vladimir Kozlov wrote: >> Thank you, Dean >> >> On 8/27/18 10:21 AM, dean.long at oracle.com wrote: >>> Looks good.? I did not review avx changes. >>> >>> A couple questions: >>> >>> Did you consider adding "const char* file = NULL, int line = 0" for x86 only instead of all platforms? >> >> Unfortunately pd_patch_instruction() method which is called from shared Label::patch_instructions() is not virtual and >> is declared on all platforms. >> Also I think other platforms can implement this functionality using new API. >> > > OK. > >>> >>> Are _file[] and _line[] arrays every used? >> >> They are used in macroAssembler_x86.hpp in guarantee() in pd_patch_instruction() which is called when forward branches >> are processed in bind(Label): >> >> http://cr.openjdk.java.net/~kvn/8209594/webrev.05/src/hotspot/cpu/x86/macroAssembler_x86.hpp.udiff.html >> > > Actually I was asking about these two: > > +#ifdef ASSERT > +? // Sourcre file and line location of jump instruction > +? int _lines[PatchCacheSize]; > +? const char* _files[PatchCacheSize]; > +#endif > > but I see now the use in Label::patch_instructions(). > > dl > >> Thanks, >> Vladimir >> >>> >>> dl >>> >>> On 8/25/18 1:05 PM, Vladimir Kozlov wrote: >>>> http://cr.openjdk.java.net/~kvn/8209594/webrev.05/ >>>> https://bugs.openjdk.java.net/browse/JDK-8209594 >>>> >>>> All platforms are affected. Please, test. >>>> >>>> I instrumented code to generated biggest code and find all possible incorrect short jumps. This is the result. >>>> >>>> Changed jump instruction patching API to added jump's source location in debug build but implemented it only on x86. >>>> I tired to search instructions by code offsets. I used very simple macro: >>>> >>>> #define jmpb(L) jmpb_0(L, __FILE__, __LINE__) >>>> >>>> 'do {} while(0)' does not work here because I need to replace non-static method. I will be glad if someone can give >>>> better suggestion how implement this macro. >>>> >>>> Fixed incorrect avx512 code in macroAssembler_x86.cpp and x86.ad file. There were missing instructions and incorrect >>>> instructions (copy-paste typos). >>>> >>>> Fixed C2 scratch buffer sizing. It did not take into account everything and as result from MAX_inst_size=1024 only >>>> 700 bytes were available. I hit this issue when RTM locking was generated for FastLock node. >>>> >>>> Tested tier1-3 on all our platforms. And also running these tiers on avx512 machine. >>>> >>> > From ioi.lam at oracle.com Wed Aug 29 04:17:04 2018 From: ioi.lam at oracle.com (Ioi Lam) Date: Tue, 28 Aug 2018 21:17:04 -0700 Subject: RFR: JDK-8202951: Implementation of JEPJDK-8204247: Include default CDS (Class Data Sharing) archive in JDK binary In-Reply-To: References: <979f56e4-07b4-8c52-c426-6ca5a839b6a3@oracle.com> <1af91463-05f5-30ed-7ef0-eeb558e12451@oracle.com> Message-ID: <3aee8562-5c41-fcf7-1565-5e45566c2e0a@oracle.com> Looks good. Thanks! - Ioi On 8/28/18 6:32 PM, Jiangli Zhou wrote: > Here is the updated webre with CheckDefaultArchiveFile.java changes. > > ? http://cr.openjdk.java.net/~jiangli/8202951/webrev.01/ > > Thanks, > Jiangli > > On 8/28/18 11:09 AM, Jiangli Zhou wrote: >> On 8/28/18 9:33 AM, Ioi Lam wrote: >>> The JVM and test changes look good. I just have one comment: >>> >>> >>> CheckDefaultArchiveFile.java >>> >>> ? 51????? if (!Platform.isDefaultCDSArchiveSupported()) { >>> ? 52???????????? if (Files.notExists(jsa)) { >>> ? 53???????????????? System.out.println("Passed. " + vmString + >>> ? 54??????????????????????????????????? ": no default classes.jsa >>> file"); >>> ? 55???????????? } else { >>> ? 56???????????????? throw new RuntimeException(vmString + "contains >>> " + jsaString); >>> ? 57???????????? } >>> >>> >>> People may manually do "java -Xshare:dump" on their own platforms >>> and them run the hotspot tests. It seems too strict to treat this as >>> an error. >>> >>> I think this block should be removed. >> That's probably a common scenario. I agree, it is too strict. Will >> remove the block. >> >> Thanks! >> >> Jiangli >> >>> >>> Thanks >>> >>> - Ioi >>> >>> >>> On 8/28/18 9:25 AM, Erik Joelsson wrote: >>>> Build changes look good to me (but should probably get review from >>>> someone else). >>>> >>>> /Erik >>>> >>>> >>>> On 2018-08-27 13:33, Jiangli Zhou wrote: >>>>> Please review the implementation for JEP JDK-8204247 >>>>> (https://bugs.openjdk.java.net/browse/JDK-8204247). The goal of >>>>> the JEP is to include a default CDS archive in JDK 12 binary >>>>> distribution (downloadable from http://jdk.java.net/12/). The >>>>> default CDS archive is generated using the default classlist >>>>> (resides in the lib/ directory) at JDK build time. Any >>>>> comments/suggestions are highly appreciated. >>>>> >>>>> All makefile changes in the webrev are contributed by Erik >>>>> Joelsson (many thanks!!). >>>>> >>>>> This is a combination of efforts from different teams and >>>>> individuals. Thanks to everyone who has been involved in the JEP & >>>>> implementation discussions, testing and bug fixing! >>>>> >>>>> ? JEP: https://bugs.openjdk.java.net/browse/JDK-8204247 >>>>> ? RFE: https://bugs.openjdk.java.net/browse/JDK-8202951 >>>>> ? webrev: http://cr.openjdk.java.net/~jiangli/8202951/webrev.00/ >>>>> >>>>> Two sanity test cases for the default CDS archive are included >>>>> test/hotspot/jtreg/runtime/SharedArchiveFile. They are not >>>>> intended for in-depth CDS functional testing, which is already >>>>> covered by the existing cds/appcds tests and all tiered tests >>>>> executing with the default CDS archive enabled. >>>>> >>>>> As part of the webrev, >>>>> test/jdk/javax/imageio/plugins/png/ItxtUtf8Test.java is also fixed >>>>> to use larger java heap (JDK-8209739 >>>>> , https://bugs.openjdk.java.net/browse/JDK-8209739). >>>>> >>>>> Tests executed: >>>>> ?- several rounds of tier1 - tier8 via mach5 >>>>> ?- JCK lang, api and vm tests via mach5 >>>>> >>>>> >>>>> Thanks! >>>>> Calvin, Ioi, Jiangli >>>>> >>>>> >>>> >>> >> > From Pengfei.Li at arm.com Wed Aug 29 10:21:12 2018 From: Pengfei.Li at arm.com (Pengfei Li) Date: Wed, 29 Aug 2018 10:21:12 +0000 Subject: RFR(S): 8210152: Optimize integer divisible by power-of-2 check Message-ID: Hi, Please help review this C2 compiler patch that optimize the integer divisible by 2^n (power-of-2) check. In original integer divisible by 2^n check, C2 compiler generates conditional negation instructions before the zero check. But actually the conditional negation is redundant since the negation of a zero (non-zero) is also a zero (non-zero). This patch adds an ideal transformation that change the IR pattern "bool eq/ne (cmp (phi (X -X) 0))" into "bool eq/ne (cmp X 0)". With this optimization, the divisible by 2^n check can be done with only 1 or 2 machine instructions. JBS: https://bugs.openjdk.java.net/browse/JDK-8210152 webrev: http://cr.openjdk.java.net/~zyao/8210152/webrev.00/ I've run jtreg full tests with this patch on an x86_64 and an aarch64 server respectively. No new failures were found. -- Thanks, Pengfei From coleen.phillimore at oracle.com Wed Aug 29 11:01:09 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 29 Aug 2018 07:01:09 -0400 Subject: RFR: 8210119: Rename SubTasksDone::is_task_claimed In-Reply-To: <6207B24F-BDB5-4AEF-BB38-DA361847C376@oracle.com> References: <6207B24F-BDB5-4AEF-BB38-DA361847C376@oracle.com> Message-ID: <4d25a5b3-cfe9-7f74-0bf2-292545adcfc9@oracle.com> Am I reading this right: -bool SequentialSubTasksDone::is_task_claimed(uint& t) { +bool SequentialSubTasksDone::try_claim_task(uint& t) { t = _n_claimed; while (t < _n_tasks) { uint res = Atomic::cmpxchg(t+1, &_n_claimed, t); if (res == t) { - return false; + return true; } t = res; } - return true; + return false; } is_task_claimed returned false if the task was claimed?? Oh, yeah, that's what the comment in workgroup.hpp says. wow. http://cr.openjdk.java.net/~kbarrett/8210119/open.00/src/hotspot/share/runtime/safepoint.cpp.udiff.html Yes, please, this makes much more sense! Looks good.? I tried to check all the reversals of sense and all there. Thanks, Coleen On 8/28/18 8:55 PM, Kim Barrett wrote: > [Sending to hotspot-dev because, though this is a GC utility, it's also > being used in runtime/safepoint.cpp.] > > Please review this small API naming cleanup. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8210119 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8210119/open.00/ > > Testing: > mach5 tier1-3 > From stefan.johansson at oracle.com Wed Aug 29 11:29:20 2018 From: stefan.johansson at oracle.com (Stefan Johansson) Date: Wed, 29 Aug 2018 13:29:20 +0200 Subject: RFR: 8210119: Rename SubTasksDone::is_task_claimed In-Reply-To: <6207B24F-BDB5-4AEF-BB38-DA361847C376@oracle.com> References: <6207B24F-BDB5-4AEF-BB38-DA361847C376@oracle.com> Message-ID: On 2018-08-29 02:55, Kim Barrett wrote: > [Sending to hotspot-dev because, though this is a GC utility, it's also > being used in runtime/safepoint.cpp.] > > Please review this small API naming cleanup. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8210119 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8210119/open.00/ Nice cleanup, looks good. Cheers, StefanJ > > Testing: > mach5 tier1-3 > From aleksei.voitylov at bell-sw.com Wed Aug 29 11:54:00 2018 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Wed, 29 Aug 2018 14:54:00 +0300 Subject: [12] RFR(S): 8207247 AARCH64: Enable Minimal and Client VM builds Message-ID: <3a18c72d-35e1-f7b3-6ea9-b37fd29b4834@bell-sw.com> Hi, please review this patch which adds Minimal and Client VM support to AARCH64 port. Enhancement: https://bugs.openjdk.java.net/browse/JDK-8207247 Webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8207247.01 Tested by running hotspot regression tests on Server, Client and Minimal on AARCH64. No new issues compared to other architectures were found. Please keep in mind Minimal VM includes C1 and Serial GC only, and does not include JMX. With that: du -b lib/minimal/libjvm.so 4091984?? ?lib/minimal/libjvm.so Thanks, -Aleksei From magnus.ihse.bursie at oracle.com Wed Aug 29 11:53:38 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 29 Aug 2018 13:53:38 +0200 Subject: RFR: JDK-8202951: Implementation of JEPJDK-8204247: Include default CDS (Class Data Sharing) archive in JDK binary In-Reply-To: References: Message-ID: On 2018-08-28 18:25, Erik Joelsson wrote: > Build changes look good to me (but should probably get review from > someone else). I'm (as usually) not as happy as Erik. ;-) In Images.gmk, you have added this rule: ????????? $@ -Xshare:dump -Xmx128M -Xms128M $(LOG_INFO) It took me a while to grasp. You are relying on $(JIMAGE_TARGET_FILE) to evaluate to bin/java. But that is only incidentally so. This file is just picked arbitrarily to represent when the entire image is done, for make. Please use $(JRE_IMAGE_DIR)/bin/java instead. The logic in jdk-options.m4 is broken. If indeed it is not possible to use cds archive with zero, then things will break since it will still be built if using --enable-cds-archive! What you should do is to set default to true unless using cross compilation or zero. If the user explicitly sets --enable-cds-archive, and it's not possible, a fatal error should be generated. Apart from this, I'm more on Erik's line. :-) /Magnus > > /Erik > > > On 2018-08-27 13:33, Jiangli Zhou wrote: >> Please review the implementation for JEP JDK-8204247 >> (https://bugs.openjdk.java.net/browse/JDK-8204247). The goal of the >> JEP is to include a default CDS archive in JDK 12 binary distribution >> (downloadable from http://jdk.java.net/12/). The default CDS archive >> is generated using the default classlist (resides in the lib/ >> directory) at JDK build time. Any comments/suggestions are highly >> appreciated. >> >> All makefile changes in the webrev are contributed by Erik Joelsson >> (many thanks!!). >> >> This is a combination of efforts from different teams and >> individuals. Thanks to everyone who has been involved in the JEP & >> implementation discussions, testing and bug fixing! >> >> ? JEP: https://bugs.openjdk.java.net/browse/JDK-8204247 >> ? RFE: https://bugs.openjdk.java.net/browse/JDK-8202951 >> ? webrev: http://cr.openjdk.java.net/~jiangli/8202951/webrev.00/ >> >> Two sanity test cases for the default CDS archive are included >> test/hotspot/jtreg/runtime/SharedArchiveFile. They are not intended >> for in-depth CDS functional testing, which is already covered by the >> existing cds/appcds tests and all tiered tests executing with the >> default CDS archive enabled. >> >> As part of the webrev, >> test/jdk/javax/imageio/plugins/png/ItxtUtf8Test.java is also fixed to >> use larger java heap (JDK-8209739 >> , https://bugs.openjdk.java.net/browse/JDK-8209739). >> >> Tests executed: >> ?- several rounds of tier1 - tier8 via mach5 >> ?- JCK lang, api and vm tests via mach5 >> >> >> Thanks! >> Calvin, Ioi, Jiangli >> >> > From aph at redhat.com Wed Aug 29 12:13:59 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 29 Aug 2018 13:13:59 +0100 Subject: [aarch64-port-dev ] [12] RFR(S): 8207247 AARCH64: Enable Minimal and Client VM builds In-Reply-To: <3a18c72d-35e1-f7b3-6ea9-b37fd29b4834@bell-sw.com> References: <3a18c72d-35e1-f7b3-6ea9-b37fd29b4834@bell-sw.com> Message-ID: <999091f1-186d-5087-2cfe-fbb161182191@redhat.com> On 08/29/2018 12:54 PM, Aleksei Voitylov wrote: > please review this patch which adds Minimal and Client VM support to > AARCH64 port. > > Enhancement: https://bugs.openjdk.java.net/browse/JDK-8207247 > Webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8207247.01 It looks fine, except for this: @@ -741,13 +746,17 @@ // We need a trampoline if branches are far. if (far_branches()) { + bool emit_trampoline = true; +#ifdef COMPILER2 // We don't want to emit a trampoline if C2 is generating dummy // code during its branch shortening phase. CompileTask* task = ciEnv::current()->task(); - bool in_scratch_emit_size = - (task != NULL && is_c2_compile(task->comp_level()) && - Compile::current()->in_scratch_emit_size()); - if (!in_scratch_emit_size) { + if (task != NULL && is_c2_compile(task->comp_level()) + && Compile::current()->in_scratch_emit_size()) { + emit_trampoline = false; + } +#endif + if(emit_trampoline) { address stub = emit_trampoline_stub(offset(), entry.target()); if (stub == NULL) { return NULL; // CodeCache is full Which changes too much code. All you need to do is hoist the declaration of in_scratch_emit_size out of the ifdef COMPILER2 region; the rest of the code is still valid. Thanks. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aleksei.voitylov at bell-sw.com Wed Aug 29 14:19:29 2018 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Wed, 29 Aug 2018 17:19:29 +0300 Subject: [aarch64-port-dev ] [12] RFR(S): 8207247 AARCH64: Enable Minimal and Client VM builds In-Reply-To: <999091f1-186d-5087-2cfe-fbb161182191@redhat.com> References: <3a18c72d-35e1-f7b3-6ea9-b37fd29b4834@bell-sw.com> <999091f1-186d-5087-2cfe-fbb161182191@redhat.com> Message-ID: <1afaf9af-38e9-8512-3553-d642b7df089f@bell-sw.com> Andrew, here is an updated webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8207247.02 I'm not sure it looks cleaner since in_scratch_emit_size is a C2-only concept, though. This was the reason I changed it. -Aleksei On 29/08/2018 15:13, Andrew Haley wrote: > On 08/29/2018 12:54 PM, Aleksei Voitylov wrote: > >> please review this patch which adds Minimal and Client VM support to >> AARCH64 port. >> >> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8207247 >> Webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8207247.01 > It looks fine, except for this: > > @@ -741,13 +746,17 @@ > > // We need a trampoline if branches are far. > if (far_branches()) { > + bool emit_trampoline = true; > +#ifdef COMPILER2 > // We don't want to emit a trampoline if C2 is generating dummy > // code during its branch shortening phase. > CompileTask* task = ciEnv::current()->task(); > - bool in_scratch_emit_size = > - (task != NULL && is_c2_compile(task->comp_level()) && > - Compile::current()->in_scratch_emit_size()); > - if (!in_scratch_emit_size) { > + if (task != NULL && is_c2_compile(task->comp_level()) > + && Compile::current()->in_scratch_emit_size()) { > + emit_trampoline = false; > + } > +#endif > + if(emit_trampoline) { > address stub = emit_trampoline_stub(offset(), entry.target()); > if (stub == NULL) { > return NULL; // CodeCache is full > > Which changes too much code. All you need to do is hoist the declaration > of in_scratch_emit_size out of the ifdef COMPILER2 region; the rest of > the code is still valid. > > Thanks. > From bob.vandette at oracle.com Wed Aug 29 15:00:19 2018 From: bob.vandette at oracle.com (Bob Vandette) Date: Wed, 29 Aug 2018 11:00:19 -0400 Subject: [aarch64-port-dev ] [12] RFR(S): 8207247 AARCH64: Enable Minimal and Client VM builds In-Reply-To: <1afaf9af-38e9-8512-3553-d642b7df089f@bell-sw.com> References: <3a18c72d-35e1-f7b3-6ea9-b37fd29b4834@bell-sw.com> <999091f1-186d-5087-2cfe-fbb161182191@redhat.com> <1afaf9af-38e9-8512-3553-d642b7df089f@bell-sw.com> Message-ID: <44262AA1-E527-48BC-8C0C-30213DCE3745@oracle.com> Changes look good to me. Bob. > On Aug 29, 2018, at 10:19 AM, Aleksei Voitylov wrote: > > Andrew, > > here is an updated webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8207247.02 > > I'm not sure it looks cleaner since in_scratch_emit_size is a C2-only concept, though. This was the reason I changed it. > > -Aleksei > > > On 29/08/2018 15:13, Andrew Haley wrote: >> On 08/29/2018 12:54 PM, Aleksei Voitylov wrote: >> >>> please review this patch which adds Minimal and Client VM support to >>> AARCH64 port. >>> >>> Enhancement: https://bugs.openjdk.java.net/browse/JDK-8207247 >>> Webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8207247.01 >> It looks fine, except for this: >> >> @@ -741,13 +746,17 @@ >> >> // We need a trampoline if branches are far. >> if (far_branches()) { >> + bool emit_trampoline = true; >> +#ifdef COMPILER2 >> // We don't want to emit a trampoline if C2 is generating dummy >> // code during its branch shortening phase. >> CompileTask* task = ciEnv::current()->task(); >> - bool in_scratch_emit_size = >> - (task != NULL && is_c2_compile(task->comp_level()) && >> - Compile::current()->in_scratch_emit_size()); >> - if (!in_scratch_emit_size) { >> + if (task != NULL && is_c2_compile(task->comp_level()) >> + && Compile::current()->in_scratch_emit_size()) { >> + emit_trampoline = false; >> + } >> +#endif >> + if(emit_trampoline) { >> address stub = emit_trampoline_stub(offset(), entry.target()); >> if (stub == NULL) { >> return NULL; // CodeCache is full >> >> Which changes too much code. All you need to do is hoist the declaration >> of in_scratch_emit_size out of the ifdef COMPILER2 region; the rest of >> the code is still valid. >> >> Thanks. >> > From kim.barrett at oracle.com Wed Aug 29 15:33:27 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 29 Aug 2018 11:33:27 -0400 Subject: RFR: 8210119: Rename SubTasksDone::is_task_claimed In-Reply-To: <4d25a5b3-cfe9-7f74-0bf2-292545adcfc9@oracle.com> References: <6207B24F-BDB5-4AEF-BB38-DA361847C376@oracle.com> <4d25a5b3-cfe9-7f74-0bf2-292545adcfc9@oracle.com> Message-ID: <4CFB818F-BB09-4749-8FDC-B92E065F52EE@oracle.com> > On Aug 29, 2018, at 7:01 AM, coleen.phillimore at oracle.com wrote: > > > Am I reading this right: > > -bool SequentialSubTasksDone::is_task_claimed(uint& t) { > +bool SequentialSubTasksDone::try_claim_task(uint& t) { > t = _n_claimed; > while (t < _n_tasks) { > uint res = Atomic::cmpxchg(t+1, &_n_claimed, t); > if (res == t) { > - return false; > + return true; > } > t = res; > } > - return true; > + return false; > } > > > is_task_claimed returned false if the task was claimed? Oh, yeah, that's what the comment in workgroup.hpp says. wow. > > http://cr.openjdk.java.net/~kbarrett/8210119/open.00/src/hotspot/share/runtime/safepoint.cpp.udiff.html > > Yes, please, this makes much more sense! Yes, is_task_claimed returned true if it was already claimed, false if it was newly claimed by the call. I think I?ve initially gotten it backward every time I?ve tried to use it. > Looks good. I tried to check all the reversals of sense and all there. Thanks, Thanks for reviewing. > Coleen > > On 8/28/18 8:55 PM, Kim Barrett wrote: >> [Sending to hotspot-dev because, though this is a GC utility, it's also >> being used in runtime/safepoint.cpp.] >> >> Please review this small API naming cleanup. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8210119 >> >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8210119/open.00/ >> >> Testing: >> mach5 tier1-3 From kim.barrett at oracle.com Wed Aug 29 15:33:42 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 29 Aug 2018 11:33:42 -0400 Subject: RFR: 8210119: Rename SubTasksDone::is_task_claimed In-Reply-To: References: <6207B24F-BDB5-4AEF-BB38-DA361847C376@oracle.com> Message-ID: <2CF37057-B9CB-4563-ACFA-CEFBE97B9F11@oracle.com> > On Aug 29, 2018, at 7:29 AM, Stefan Johansson wrote: > > > > On 2018-08-29 02:55, Kim Barrett wrote: >> [Sending to hotspot-dev because, though this is a GC utility, it's also >> being used in runtime/safepoint.cpp.] >> Please review this small API naming cleanup. >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8210119 >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8210119/open.00/ > Nice cleanup, looks good. Thanks. > > Cheers, > StefanJ > >> Testing: >> mach5 tier1-3 From aph at redhat.com Wed Aug 29 15:34:44 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 29 Aug 2018 16:34:44 +0100 Subject: [aarch64-port-dev ] [12] RFR(S): 8207247 AARCH64: Enable Minimal and Client VM builds In-Reply-To: <1afaf9af-38e9-8512-3553-d642b7df089f@bell-sw.com> References: <3a18c72d-35e1-f7b3-6ea9-b37fd29b4834@bell-sw.com> <999091f1-186d-5087-2cfe-fbb161182191@redhat.com> <1afaf9af-38e9-8512-3553-d642b7df089f@bell-sw.com> Message-ID: <0269b8c5-bef8-94c7-054a-09d342af2df0@redhat.com> On 08/29/2018 03:19 PM, Aleksei Voitylov wrote: > here is an updated webrev: > http://cr.openjdk.java.net/~avoitylov/webrev.8207247.02 > > I'm not sure it looks cleaner since in_scratch_emit_size is a C2-only > concept, though. This was the reason I changed it. Yeah, I get that, but I want to keep the code history as clean as possible. One other thing I noticed: the +#ifdef COMPILER2 + const int stub_size = Compile::MAX_stubs_size/2; +#else + const int stub_size = LIR_Assembler::call_stub_size(); +#endif + + address stub = start_a_stub(stub_size); is an unnecessary complication. I'm testing this: // Max stub size: alignment nop, ldr, br, emit_int64 address stub = start_a_stub(3 * NativeInstruction::instruction_size + wordSize); -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Wed Aug 29 15:39:42 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 29 Aug 2018 16:39:42 +0100 Subject: [aarch64-port-dev ] [12] RFR(S): 8207247 AARCH64: Enable Minimal and Client VM builds In-Reply-To: <0269b8c5-bef8-94c7-054a-09d342af2df0@redhat.com> References: <3a18c72d-35e1-f7b3-6ea9-b37fd29b4834@bell-sw.com> <999091f1-186d-5087-2cfe-fbb161182191@redhat.com> <1afaf9af-38e9-8512-3553-d642b7df089f@bell-sw.com> <0269b8c5-bef8-94c7-054a-09d342af2df0@redhat.com> Message-ID: On 08/29/2018 04:34 PM, Andrew Haley wrote: > I'm testing this: > > // Max stub size: alignment nop, ldr, br, emit_int64 > address stub = start_a_stub(3 * NativeInstruction::instruction_size + wordSize); Sorry, that was wrong. We already have a constant: // Max stub size: alignment nop, TrampolineStub. address stub = start_a_stub(NativeInstruction::instruction_size + NativeCallTrampolineStub::instruction_size); -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From erik.joelsson at oracle.com Wed Aug 29 15:45:43 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 29 Aug 2018 08:45:43 -0700 Subject: RFR: JDK-8202951: Implementation of JEPJDK-8204247: Include default CDS (Class Data Sharing) archive in JDK binary In-Reply-To: References: Message-ID: <8e17729f-9f5b-4d7c-a8cf-e0d3ffeeb694@oracle.com> Hello Magnus, As the author of the build changes I will answer this. On 2018-08-29 04:53, Magnus Ihse Bursie wrote: > On 2018-08-28 18:25, Erik Joelsson wrote: >> Build changes look good to me (but should probably get review from >> someone else). > > I'm (as usually) not as happy as Erik. ;-) > > In Images.gmk, you have added this rule: > ????????? $@ -Xshare:dump -Xmx128M -Xms128M $(LOG_INFO) > > It took me a while to grasp. You are relying on $(JIMAGE_TARGET_FILE) > to evaluate to bin/java. But that is only incidentally so. This file > is just picked arbitrarily to represent when the entire image is done, > for make. Please use $(JRE_IMAGE_DIR)/bin/java instead. > I can agree with this part. That was a bit of a hack done in a hurry. > The logic in jdk-options.m4 is broken. If indeed it is not possible to > use cds archive with zero, then things will break since it will still > be built if using --enable-cds-archive! > > What you should do is to set default to true unless using cross > compilation or zero. If the user explicitly sets --enable-cds-archive, > and it's not possible, a fatal error should be generated. > Here I'm not as sure. I deliberately let it be possible to override the default behavior for zero as someone might want to fix that at some point, you never know. For cross compilation it's just not possible ever so that's different. Maybe my reasoning is invalid. /Erik > Apart from this, I'm more on Erik's line. :-) > > /Magnus > > > >> >> /Erik >> >> >> On 2018-08-27 13:33, Jiangli Zhou wrote: >>> Please review the implementation for JEP JDK-8204247 >>> (https://bugs.openjdk.java.net/browse/JDK-8204247). The goal of the >>> JEP is to include a default CDS archive in JDK 12 binary >>> distribution (downloadable from http://jdk.java.net/12/). The >>> default CDS archive is generated using the default classlist >>> (resides in the lib/ directory) at JDK build time. Any >>> comments/suggestions are highly appreciated. >>> >>> All makefile changes in the webrev are contributed by Erik Joelsson >>> (many thanks!!). >>> >>> This is a combination of efforts from different teams and >>> individuals. Thanks to everyone who has been involved in the JEP & >>> implementation discussions, testing and bug fixing! >>> >>> ? JEP: https://bugs.openjdk.java.net/browse/JDK-8204247 >>> ? RFE: https://bugs.openjdk.java.net/browse/JDK-8202951 >>> ? webrev: http://cr.openjdk.java.net/~jiangli/8202951/webrev.00/ >>> >>> Two sanity test cases for the default CDS archive are included >>> test/hotspot/jtreg/runtime/SharedArchiveFile. They are not intended >>> for in-depth CDS functional testing, which is already covered by the >>> existing cds/appcds tests and all tiered tests executing with the >>> default CDS archive enabled. >>> >>> As part of the webrev, >>> test/jdk/javax/imageio/plugins/png/ItxtUtf8Test.java is also fixed >>> to use larger java heap (JDK-8209739 >>> , https://bugs.openjdk.java.net/browse/JDK-8209739). >>> >>> Tests executed: >>> ?- several rounds of tier1 - tier8 via mach5 >>> ?- JCK lang, api and vm tests via mach5 >>> >>> >>> Thanks! >>> Calvin, Ioi, Jiangli >>> >>> >> > From adinn at redhat.com Wed Aug 29 15:47:52 2018 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 29 Aug 2018 16:47:52 +0100 Subject: [aarch64-port-dev ] [12] RFR(S): 8207247 AARCH64: Enable Minimal and Client VM builds In-Reply-To: <0269b8c5-bef8-94c7-054a-09d342af2df0@redhat.com> References: <3a18c72d-35e1-f7b3-6ea9-b37fd29b4834@bell-sw.com> <999091f1-186d-5087-2cfe-fbb161182191@redhat.com> <1afaf9af-38e9-8512-3553-d642b7df089f@bell-sw.com> <0269b8c5-bef8-94c7-054a-09d342af2df0@redhat.com> Message-ID: On 29/08/18 16:34, Andrew Haley wrote: > On 08/29/2018 03:19 PM, Aleksei Voitylov wrote: >> here is an updated webrev: >> http://cr.openjdk.java.net/~avoitylov/webrev.8207247.02 >> >> I'm not sure it looks cleaner since in_scratch_emit_size is a C2-only >> concept, though. This was the reason I changed it. > > Yeah, I get that, but I want to keep the code history as clean as > possible. One minimal change which would clarify the code would be to rename in_scratch_emit_size to a name that does not drag in the C2-specific details: // We need a trampoline if branches are far. if (far_branches()) { + bool avoid_emit = false; +#ifdef COMPILER2 // We don't want to emit a trampoline if C2 is generating dummy // code during its branch shortening phase. CompileTask* task = ciEnv::current()->task(); - bool in_scratch_emit_size = + avoid_emit = (task != NULL && is_c2_compile(task->comp_level()) && Compile::current()->in_scratch_emit_size()); +#endif if (!avoid_emit) { address stub = emit_trampoline_stub(offset(), entry.target()); if (stub == NULL) { return NULL; // CodeCache is full } Even better would be to use do_emit and reverse the logic but that requires a slightly larger (but not much more complex) change: // We need a trampoline if branches are far. if (far_branches()) { + bool so_emit = true; +#ifdef COMPILER2 // We don't want to emit a trampoline if C2 is generating dummy // code during its branch shortening phase. CompileTask* task = ciEnv::current()->task(); - bool in_scratch_emit_size = - (task != NULL && is_c2_compile(task->comp_level()) && - Compile::current()->in_scratch_emit_size()); + do_emit = + !(task != NULL && is_c2_compile(task->comp_level()) && + Compile::current()->in_scratch_emit_size()); +#endif if (do_emit) { address stub = emit_trampoline_stub(offset(), entry.target()); if (stub == NULL) { return NULL; // CodeCache is full } 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 Wed Aug 29 15:49:22 2018 From: aph at redhat.com (Andrew Haley) Date: Wed, 29 Aug 2018 16:49:22 +0100 Subject: [aarch64-port-dev ] [12] RFR(S): 8207247 AARCH64: Enable Minimal and Client VM builds In-Reply-To: References: <3a18c72d-35e1-f7b3-6ea9-b37fd29b4834@bell-sw.com> <999091f1-186d-5087-2cfe-fbb161182191@redhat.com> <1afaf9af-38e9-8512-3553-d642b7df089f@bell-sw.com> <0269b8c5-bef8-94c7-054a-09d342af2df0@redhat.com> Message-ID: <1bdccda4-9a17-56c1-2eea-4d69b4a3003a@redhat.com> On 08/29/2018 04:47 PM, Andrew Dinn wrote: > Even better would be to use do_emit and reverse the logic but that > requires a slightly larger (but not much more complex) change: No. Let it stand. Referring to C2 is fine because it's only C2 that needs the logic. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aleksei.voitylov at bell-sw.com Wed Aug 29 15:53:46 2018 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Wed, 29 Aug 2018 18:53:46 +0300 Subject: [aarch64-port-dev ] [12] RFR(S): 8207247 AARCH64: Enable Minimal and Client VM builds In-Reply-To: References: <3a18c72d-35e1-f7b3-6ea9-b37fd29b4834@bell-sw.com> <999091f1-186d-5087-2cfe-fbb161182191@redhat.com> <1afaf9af-38e9-8512-3553-d642b7df089f@bell-sw.com> <0269b8c5-bef8-94c7-054a-09d342af2df0@redhat.com> Message-ID: <8f3bf4ae-6433-35d3-c869-64c5da469127@bell-sw.com> Your second proposal is almost what I proposed in v01. But since I don't consider this important I'll adhere to those who have an opinion :) -Aleksei On 29/08/2018 18:47, Andrew Dinn wrote: > On 29/08/18 16:34, Andrew Haley wrote: >> On 08/29/2018 03:19 PM, Aleksei Voitylov wrote: >>> here is an updated webrev: >>> http://cr.openjdk.java.net/~avoitylov/webrev.8207247.02 >>> >>> I'm not sure it looks cleaner since in_scratch_emit_size is a C2-only >>> concept, though. This was the reason I changed it. >> Yeah, I get that, but I want to keep the code history as clean as >> possible. > One minimal change which would clarify the code would be to rename > in_scratch_emit_size to a name that does not drag in the C2-specific > details: > > // We need a trampoline if branches are far. > if (far_branches()) { > + bool avoid_emit = false; > +#ifdef COMPILER2 > // We don't want to emit a trampoline if C2 is generating dummy > // code during its branch shortening phase. > CompileTask* task = ciEnv::current()->task(); > - bool in_scratch_emit_size = > + avoid_emit = > (task != NULL && is_c2_compile(task->comp_level()) && > Compile::current()->in_scratch_emit_size()); > +#endif > if (!avoid_emit) { > address stub = emit_trampoline_stub(offset(), entry.target()); > if (stub == NULL) { > return NULL; // CodeCache is full > } > > Even better would be to use do_emit and reverse the logic but that > requires a slightly larger (but not much more complex) change: > > // We need a trampoline if branches are far. > if (far_branches()) { > + bool so_emit = true; > +#ifdef COMPILER2 > // We don't want to emit a trampoline if C2 is generating dummy > // code during its branch shortening phase. > CompileTask* task = ciEnv::current()->task(); > - bool in_scratch_emit_size = > - (task != NULL && is_c2_compile(task->comp_level()) && > - Compile::current()->in_scratch_emit_size()); > + do_emit = > + !(task != NULL && is_c2_compile(task->comp_level()) && > + Compile::current()->in_scratch_emit_size()); > +#endif > if (do_emit) { > address stub = emit_trampoline_stub(offset(), entry.target()); > if (stub == NULL) { > return NULL; // CodeCache is full > } > > 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 coleen.phillimore at oracle.com Wed Aug 29 16:07:54 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 29 Aug 2018 12:07:54 -0400 Subject: RFR (M) 8210155: Lock ClassLoaderDataGraph Message-ID: Summary: In preparation for concurrent class unloading. open webrev at http://cr.openjdk.java.net/~coleenp/8210155.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8210155 Tested with mach5 hs-tier1-7, which tests JFR and JVMTI changes. Also tested with performance dev-submit testing with no regression. Thanks, Coleen From aleksei.voitylov at bell-sw.com Wed Aug 29 16:30:40 2018 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Wed, 29 Aug 2018 19:30:40 +0300 Subject: [aarch64-port-dev ] [12] RFR(S): 8207247 AARCH64: Enable Minimal and Client VM builds In-Reply-To: References: <3a18c72d-35e1-f7b3-6ea9-b37fd29b4834@bell-sw.com> <999091f1-186d-5087-2cfe-fbb161182191@redhat.com> <1afaf9af-38e9-8512-3553-d642b7df089f@bell-sw.com> <0269b8c5-bef8-94c7-054a-09d342af2df0@redhat.com> Message-ID: <8ac750b9-bd20-46da-1d7f-6214c0699861@bell-sw.com> I like that much better, thanks. Launched some testing and will get back with an updated webrev. Meanwhile, Minimal VM build got broken today by b9f6a4427da9 across all platforms. Testing a fix for that as well. -Aleksei On 29/08/2018 18:39, Andrew Haley wrote: > On 08/29/2018 04:34 PM, Andrew Haley wrote: >> I'm testing this: >> >> // Max stub size: alignment nop, ldr, br, emit_int64 >> address stub = start_a_stub(3 * NativeInstruction::instruction_size + wordSize); > Sorry, that was wrong. We already have a constant: > > // Max stub size: alignment nop, TrampolineStub. > address stub > = start_a_stub(NativeInstruction::instruction_size > + NativeCallTrampolineStub::instruction_size); > From mikael.vidstedt at oracle.com Wed Aug 29 16:39:06 2018 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Wed, 29 Aug 2018 09:39:06 -0700 Subject: RFR(XS): 8210167: ProblemList vmTestbase/nsk/jvmti/scenarios/allocation/AP10/ap10t001/TestDescription.java Message-ID: vmTestbase/nsk/jvmti/scenarios/allocation/AP10/ap10t001/TestDescription.java fails consistently in the tier4 compiler testing. Let?s problem list it while the fix is being worked on ProblemList bug (sub-task): https://bugs.openjdk.java.net/browse/JDK-8210167 (parent) bug: https://bugs.openjdk.java.net/browse/JDK-8210131 webrev: http://cr.openjdk.java.net/~mikael/webrevs/8210167/webrev.00/open/webrev/ Cheers, Mikael From coleen.phillimore at oracle.com Wed Aug 29 20:48:17 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 29 Aug 2018 16:48:17 -0400 Subject: RFR(XS): 8210167: ProblemList vmTestbase/nsk/jvmti/scenarios/allocation/AP10/ap10t001/TestDescription.java In-Reply-To: References: Message-ID: Looks good + trivial.? Ship it! Coleen On 8/29/18 12:39 PM, Mikael Vidstedt wrote: > vmTestbase/nsk/jvmti/scenarios/allocation/AP10/ap10t001/TestDescription.java fails consistently in the tier4 compiler testing. Let?s problem list it while the fix is being worked on > > ProblemList bug (sub-task): https://bugs.openjdk.java.net/browse/JDK-8210167 > (parent) bug: https://bugs.openjdk.java.net/browse/JDK-8210131 > webrev: http://cr.openjdk.java.net/~mikael/webrevs/8210167/webrev.00/open/webrev/ > > Cheers, > Mikael > From jiangli.zhou at oracle.com Wed Aug 29 21:45:14 2018 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 29 Aug 2018 14:45:14 -0700 Subject: RFR: JDK-8202951: Implementation of JEPJDK-8204247: Include default CDS (Class Data Sharing) archive in JDK binary In-Reply-To: <8e17729f-9f5b-4d7c-a8cf-e0d3ffeeb694@oracle.com> References: <8e17729f-9f5b-4d7c-a8cf-e0d3ffeeb694@oracle.com> Message-ID: Hi Erik and Magnus, I updated Images.gmk accordingly. Magnus, thanks for reviewing! http://cr.openjdk.java.net/~jiangli/8202951/webrev.02/make/Images.gmk.frames.html Complete webrev: http://cr.openjdk.java.net/~jiangli/8202951/webrev.02/ Please see comments below. On 8/29/18 8:45 AM, Erik Joelsson wrote: > > Hello Magnus, > > As the author of the build changes I will answer this. > > On 2018-08-29 04:53, Magnus Ihse Bursie wrote: >> On 2018-08-28 18:25, Erik Joelsson wrote: >>> Build changes look good to me (but should probably get review from >>> someone else). >> >> I'm (as usually) not as happy as Erik. ;-) >> >> In Images.gmk, you have added this rule: >> ????????? $@ -Xshare:dump -Xmx128M -Xms128M $(LOG_INFO) >> >> It took me a while to grasp. You are relying on $(JIMAGE_TARGET_FILE) >> to evaluate to bin/java. But that is only incidentally so. This file >> is just picked arbitrarily to represent when the entire image is >> done, for make. Please use $(JRE_IMAGE_DIR)/bin/java instead. >> > I can agree with this part. That was a bit of a hack done in a hurry. >> The logic in jdk-options.m4 is broken. If indeed it is not possible >> to use cds archive with zero, then things will break since it will >> still be built if using --enable-cds-archive! >> >> What you should do is to set default to true unless using cross >> compilation or zero. If the user explicitly sets >> --enable-cds-archive, and it's not possible, a fatal error should be >> generated. >> > Here I'm not as sure. I deliberately let it be possible to override > the default behavior for zero as someone might want to fix that at > some point, you never know. For cross compilation it's just not > possible ever so that's different. Maybe my reasoning is invalid. I think that's reasonable. Thanks! Jiangli > > /Erik >> Apart from this, I'm more on Erik's line. :-) >> >> /Magnus >> >> >> >>> >>> /Erik >>> >>> >>> On 2018-08-27 13:33, Jiangli Zhou wrote: >>>> Please review the implementation for JEP JDK-8204247 >>>> (https://bugs.openjdk.java.net/browse/JDK-8204247). The goal of the >>>> JEP is to include a default CDS archive in JDK 12 binary >>>> distribution (downloadable from http://jdk.java.net/12/). The >>>> default CDS archive is generated using the default classlist >>>> (resides in the lib/ directory) at JDK build time. Any >>>> comments/suggestions are highly appreciated. >>>> >>>> All makefile changes in the webrev are contributed by Erik Joelsson >>>> (many thanks!!). >>>> >>>> This is a combination of efforts from different teams and >>>> individuals. Thanks to everyone who has been involved in the JEP & >>>> implementation discussions, testing and bug fixing! >>>> >>>> ? JEP: https://bugs.openjdk.java.net/browse/JDK-8204247 >>>> ? RFE: https://bugs.openjdk.java.net/browse/JDK-8202951 >>>> ? webrev: http://cr.openjdk.java.net/~jiangli/8202951/webrev.00/ >>>> >>>> Two sanity test cases for the default CDS archive are included >>>> test/hotspot/jtreg/runtime/SharedArchiveFile. They are not intended >>>> for in-depth CDS functional testing, which is already covered by >>>> the existing cds/appcds tests and all tiered tests executing with >>>> the default CDS archive enabled. >>>> >>>> As part of the webrev, >>>> test/jdk/javax/imageio/plugins/png/ItxtUtf8Test.java is also fixed >>>> to use larger java heap (JDK-8209739 >>>> , https://bugs.openjdk.java.net/browse/JDK-8209739). >>>> >>>> Tests executed: >>>> ?- several rounds of tier1 - tier8 via mach5 >>>> ?- JCK lang, api and vm tests via mach5 >>>> >>>> >>>> Thanks! >>>> Calvin, Ioi, Jiangli >>>> >>>> >>> >> > From igor.ignatyev at oracle.com Wed Aug 29 23:34:57 2018 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 29 Aug 2018 16:34:57 -0700 Subject: Native/Unit Test Development Guidelines Message-ID: <2E158FF6-DEB5-4D0D-AF1D-D43E39E70B5D@oracle.com> Dear all, This is to inform you that the guidelines for hotspot test development with Google Test framework have been published on OpenJDK wiki[1]. I hope it will be useful for you and instrumental in getting more good tests and consequently higher quality of hotspot. I'd like to take this opportunity to thank Kim, Jesper, Kirill Z and Dmitry F (and some other who I might forget) for their helps w/ creating and editing this document. [1] https://wiki.openjdk.java.net/pages/viewpage.action?pageId=37584961 Thanks, -- Igor From mark.reinhold at oracle.com Thu Aug 30 00:13:21 2018 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 29 Aug 2018 17:13:21 -0700 (PDT) Subject: New candidate JEP: 340: One AArch64 Port, Not Two Message-ID: <20180830001321.B4D252081A0@eggemoggin.niobe.net> http://openjdk.java.net/jeps/340 - Mark From aleksei.voitylov at bell-sw.com Thu Aug 30 10:43:42 2018 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Thu, 30 Aug 2018 13:43:42 +0300 Subject: [12] RFR(XS): 8210164: building Minimal VM fails with error: comparison of unsigned expression < 0 is always false [-Werror=type-limits] Message-ID: Hi, please review this patch which fixes Minimal VM build error after b9f6a4427da9 was pushed. I'm suggesting to fix it explicitly as opposed to disabling the compiler warning. bug: https://bugs.openjdk.java.net/browse/JDK-8210164 webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8210164.02/ Tested by running hotspot regression tests. Thanks, -Aleksei From shade at redhat.com Thu Aug 30 10:53:56 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 30 Aug 2018 12:53:56 +0200 Subject: [12] RFR(XS): 8210164: building Minimal VM fails with error: comparison of unsigned expression < 0 is always false [-Werror=type-limits] In-Reply-To: References: Message-ID: <86331aac-5ab6-ebd1-9f9f-029b953bae9d@redhat.com> On 08/30/2018 12:43 PM, Aleksei Voitylov wrote: > please review this patch which fixes Minimal VM build error after b9f6a4427da9 was pushed. I'm > suggesting to fix it explicitly as opposed to disabling the compiler warning. > > bug: https://bugs.openjdk.java.net/browse/JDK-8210164 > webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8210164.02/ Looks good. Probably deserves a little comment why we are doing this, so we can later remove it if we can prove that serial_phase_count is never 0, by code inspection. Thanks, -Aleksey From magnus.ihse.bursie at oracle.com Thu Aug 30 10:56:04 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 30 Aug 2018 12:56:04 +0200 Subject: RFR: JDK-8202951: Implementation of JEPJDK-8204247: Include default CDS (Class Data Sharing) archive in JDK binary In-Reply-To: <8e17729f-9f5b-4d7c-a8cf-e0d3ffeeb694@oracle.com> References: <8e17729f-9f5b-4d7c-a8cf-e0d3ffeeb694@oracle.com> Message-ID: On 2018-08-29 17:45, Erik Joelsson wrote: > > Hello Magnus, > > As the author of the build changes I will answer this. > > On 2018-08-29 04:53, Magnus Ihse Bursie wrote: >> On 2018-08-28 18:25, Erik Joelsson wrote: >>> Build changes look good to me (but should probably get review from >>> someone else). >> >> I'm (as usually) not as happy as Erik. ;-) >> >> In Images.gmk, you have added this rule: >> ????????? $@ -Xshare:dump -Xmx128M -Xms128M $(LOG_INFO) >> >> It took me a while to grasp. You are relying on $(JIMAGE_TARGET_FILE) >> to evaluate to bin/java. But that is only incidentally so. This file >> is just picked arbitrarily to represent when the entire image is >> done, for make. Please use $(JRE_IMAGE_DIR)/bin/java instead. >> > I can agree with this part. That was a bit of a hack done in a hurry. >> The logic in jdk-options.m4 is broken. If indeed it is not possible >> to use cds archive with zero, then things will break since it will >> still be built if using --enable-cds-archive! >> >> What you should do is to set default to true unless using cross >> compilation or zero. If the user explicitly sets >> --enable-cds-archive, and it's not possible, a fatal error should be >> generated. >> > Here I'm not as sure. I deliberately let it be possible to override > the default behavior for zero as someone might want to fix that at > some point, you never know. For cross compilation it's just not > possible ever so that's different. Maybe my reasoning is invalid. I see. I still think it would have made more sense, in that case, to set the default to false if using zero, but allow override. But I'm not going to insist on that. However, if the problem with zero is not that it's technically impossible, just that it's not tested, I think the message should be changed from "[no, not possible with JVM variant zero]" to just "[no]" with a comment in the configure script that it's off by default since it's not tested. Apart from that, Jiangli's latest webrev looks good. Jiangli: If you fix it like I suggested, you do not need to respin the webrev. /Magnus > > /Erik >> Apart from this, I'm more on Erik's line. :-) >> >> /Magnus >> >> >> >>> >>> /Erik >>> >>> >>> On 2018-08-27 13:33, Jiangli Zhou wrote: >>>> Please review the implementation for JEP JDK-8204247 >>>> (https://bugs.openjdk.java.net/browse/JDK-8204247). The goal of the >>>> JEP is to include a default CDS archive in JDK 12 binary >>>> distribution (downloadable from http://jdk.java.net/12/). The >>>> default CDS archive is generated using the default classlist >>>> (resides in the lib/ directory) at JDK build time. Any >>>> comments/suggestions are highly appreciated. >>>> >>>> All makefile changes in the webrev are contributed by Erik Joelsson >>>> (many thanks!!). >>>> >>>> This is a combination of efforts from different teams and >>>> individuals. Thanks to everyone who has been involved in the JEP & >>>> implementation discussions, testing and bug fixing! >>>> >>>> ? JEP: https://bugs.openjdk.java.net/browse/JDK-8204247 >>>> ? RFE: https://bugs.openjdk.java.net/browse/JDK-8202951 >>>> ? webrev: http://cr.openjdk.java.net/~jiangli/8202951/webrev.00/ >>>> >>>> Two sanity test cases for the default CDS archive are included >>>> test/hotspot/jtreg/runtime/SharedArchiveFile. They are not intended >>>> for in-depth CDS functional testing, which is already covered by >>>> the existing cds/appcds tests and all tiered tests executing with >>>> the default CDS archive enabled. >>>> >>>> As part of the webrev, >>>> test/jdk/javax/imageio/plugins/png/ItxtUtf8Test.java is also fixed >>>> to use larger java heap (JDK-8209739 >>>> , https://bugs.openjdk.java.net/browse/JDK-8209739). >>>> >>>> Tests executed: >>>> ?- several rounds of tier1 - tier8 via mach5 >>>> ?- JCK lang, api and vm tests via mach5 >>>> >>>> >>>> Thanks! >>>> Calvin, Ioi, Jiangli >>>> >>>> >>> >> > From aleksei.voitylov at bell-sw.com Thu Aug 30 11:10:00 2018 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Thu, 30 Aug 2018 14:10:00 +0300 Subject: [12] RFR(XS): 8210164: building Minimal VM fails with error: comparison of unsigned expression < 0 is always false [-Werror=type-limits] In-Reply-To: <86331aac-5ab6-ebd1-9f9f-029b953bae9d@redhat.com> References: <86331aac-5ab6-ebd1-9f9f-029b953bae9d@redhat.com> Message-ID: Aleksey, thanks for checking in. Here is an updated webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8210164.03/ -Aleksei On 30/08/2018 13:53, Aleksey Shipilev wrote: > On 08/30/2018 12:43 PM, Aleksei Voitylov wrote: >> please review this patch which fixes Minimal VM build error after b9f6a4427da9 was pushed. I'm >> suggesting to fix it explicitly as opposed to disabling the compiler warning. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8210164 >> webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8210164.02/ > Looks good. Probably deserves a little comment why we are doing this, so we can later remove it if > we can prove that serial_phase_count is never 0, by code inspection. > > Thanks, > -Aleksey > From aleksei.voitylov at bell-sw.com Thu Aug 30 11:14:41 2018 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Thu, 30 Aug 2018 14:14:41 +0300 Subject: [aarch64-port-dev ] [12] RFR(S): 8207247 AARCH64: Enable Minimal and Client VM builds In-Reply-To: <8ac750b9-bd20-46da-1d7f-6214c0699861@bell-sw.com> References: <3a18c72d-35e1-f7b3-6ea9-b37fd29b4834@bell-sw.com> <999091f1-186d-5087-2cfe-fbb161182191@redhat.com> <1afaf9af-38e9-8512-3553-d642b7df089f@bell-sw.com> <0269b8c5-bef8-94c7-054a-09d342af2df0@redhat.com> <8ac750b9-bd20-46da-1d7f-6214c0699861@bell-sw.com> Message-ID: Hi, here is an updated webrev which addresses all comments: http://cr.openjdk.java.net/~avoitylov/webrev.8207247.03/ Thanks, -Aleksei On 29/08/2018 19:30, Aleksei Voitylov wrote: > I like that much better, thanks. Launched some testing and will get > back with an updated webrev. > > Meanwhile, Minimal VM build got broken today by b9f6a4427da9 across > all platforms. Testing a fix for that as well. > > -Aleksei > > > On 29/08/2018 18:39, Andrew Haley wrote: >> On 08/29/2018 04:34 PM, Andrew Haley wrote: >>> I'm testing this: >>> >>> ?? // Max stub size: alignment nop, ldr, br, emit_int64 >>> ?? address stub = start_a_stub(3 * >>> NativeInstruction::instruction_size + wordSize); >> Sorry, that was wrong.? We already have a constant: >> >> ?? // Max stub size: alignment nop, TrampolineStub. >> ?? address stub >> ???? = start_a_stub(NativeInstruction::instruction_size >> ??????????????????? + NativeCallTrampolineStub::instruction_size); >> > From matthias.baesken at sap.com Thu Aug 30 11:21:16 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 30 Aug 2018 11:21:16 +0000 Subject: RFR : 8210205 : build fails on AIX in hotspot cpp tests (for example getstacktr001.cpp) Message-ID: Hello, please review this small fix to repair our AIX build . Recent changes to jdk/jdk broke the build . We get clashes with defines from system headers in a few compilation units, for example : "/openjdk/nb/rs6000_64/nightly/jdk/test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetStackTrace/getstacktr001/getstacktr001.cpp", line 69.9: 1540-0848 (S) The macro name "NUMBER_OF_FRAMES" is already defined with a different definition. "/usr/include/sys/mstsave.h", line 260.9: 1540-0425 (I) "NUMBER_OF_FRAMES" is defined on line 260 of "/usr/include/sys/mstsave.h". Renaming NUMBER_OF_FRAMES fixes the issue. Bug : https://bugs.openjdk.java.net/browse/JDK-8210205 webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8210205/ Thanks, Matthias From goetz.lindenmaier at sap.com Thu Aug 30 12:17:28 2018 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 30 Aug 2018 12:17:28 +0000 Subject: RFR : 8210205 : build fails on AIX in hotspot cpp tests (for example getstacktr001.cpp) In-Reply-To: References: Message-ID: <2bbe23cb37044a7cb4ea405fde4adf36@sap.com> Hi Matthias, Aix is a nuisance. Thanks for fixing this. Looks good. As this is a build fix, and only changes tests, I think you don't need to follow the 24h rule, i.e., you can push it sooner. Best regards, Goetz. From: Baesken, Matthias Sent: Donnerstag, 30. August 2018 13:21 To: 'hotspot-dev at openjdk.java.net' ; 'build-dev at openjdk.java.net' Cc: Lindenmaier, Goetz ; Doerr, Martin Subject: RFR : 8210205 : build fails on AIX in hotspot cpp tests (for example getstacktr001.cpp) Hello, please review this small fix to repair our AIX build . Recent changes to jdk/jdk broke the build . We get clashes with defines from system headers in a few compilation units, for example : "/openjdk/nb/rs6000_64/nightly/jdk/test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetStackTrace/getstacktr001/getstacktr001.cpp", line 69.9: 1540-0848 (S) The macro name "NUMBER_OF_FRAMES" is already defined with a different definition. "/usr/include/sys/mstsave.h", line 260.9: 1540-0425 (I) "NUMBER_OF_FRAMES" is defined on line 260 of "/usr/include/sys/mstsave.h". Renaming NUMBER_OF_FRAMES fixes the issue. Bug : https://bugs.openjdk.java.net/browse/JDK-8210205 webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8210205/ Thanks, Matthias From magnus.ihse.bursie at oracle.com Thu Aug 30 12:36:37 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 30 Aug 2018 14:36:37 +0200 Subject: RFR: JDK-6657100 Rename sparcWorks to solstudio in HotSpot Message-ID: <4bd22bee-8d4c-8a1d-441b-03207355380c@oracle.com> Hi folks, This bug report goes all the way back to 2008. :-) So instead of just letting it go on to it's second decade of existence, I went about and fixed it. By now, not many references to sparcWorks exists anymore, so this is almost trivial. I've verified by grep that no more "sparcworks" are present in the repo, neither in hotspot nor anywhere else. Bug: https://bugs.openjdk.java.net/browse/JDK-6657100 WebRev: http://cr.openjdk.java.net/~ihse/JDK-6657100-rename-sparcWorks-to-solstudio/webrev.01 /Magnus From aph at redhat.com Thu Aug 30 13:08:06 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 30 Aug 2018 14:08:06 +0100 Subject: [aarch64-port-dev ] [12] RFR(S): 8207247 AARCH64: Enable Minimal and Client VM builds In-Reply-To: References: <3a18c72d-35e1-f7b3-6ea9-b37fd29b4834@bell-sw.com> <999091f1-186d-5087-2cfe-fbb161182191@redhat.com> <1afaf9af-38e9-8512-3553-d642b7df089f@bell-sw.com> <0269b8c5-bef8-94c7-054a-09d342af2df0@redhat.com> <8ac750b9-bd20-46da-1d7f-6214c0699861@bell-sw.com> Message-ID: On 08/30/2018 12:14 PM, Aleksei Voitylov wrote: > here is an updated webrev which addresses all comments: > http://cr.openjdk.java.net/~avoitylov/webrev.8207247.03/ Sweet! That's perfect, thanks. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From erik.joelsson at oracle.com Thu Aug 30 13:31:00 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 30 Aug 2018 06:31:00 -0700 Subject: RFR: JDK-6657100 Rename sparcWorks to solstudio in HotSpot In-Reply-To: <4bd22bee-8d4c-8a1d-441b-03207355380c@oracle.com> References: <4bd22bee-8d4c-8a1d-441b-03207355380c@oracle.com> Message-ID: Looks good to me. /Erik On 2018-08-30 05:36, Magnus Ihse Bursie wrote: > Hi folks, > > This bug report goes all the way back to 2008. :-) So instead of just > letting it go on to it's second decade of existence, I went about and > fixed it. > > By now, not many references to sparcWorks exists anymore, so this is > almost trivial. > > I've verified by grep that no more "sparcworks" are present in the > repo, neither in hotspot nor anywhere else. > > Bug: https://bugs.openjdk.java.net/browse/JDK-6657100 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-6657100-rename-sparcWorks-to-solstudio/webrev.01 > > /Magnus From daniel.daugherty at oracle.com Thu Aug 30 13:46:06 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 30 Aug 2018 09:46:06 -0400 Subject: RFR: JDK-6657100 Rename sparcWorks to solstudio in HotSpot In-Reply-To: <4bd22bee-8d4c-8a1d-441b-03207355380c@oracle.com> References: <4bd22bee-8d4c-8a1d-441b-03207355380c@oracle.com> Message-ID: On 8/30/18 8:36 AM, Magnus Ihse Bursie wrote: > Hi folks, > > This bug report goes all the way back to 2008. :-) So instead of just > letting it go on to it's second decade of existence, I went about and > fixed it. > > By now, not many references to sparcWorks exists anymore, so this is > almost trivial. > > I've verified by grep that no more "sparcworks" are present in the > repo, neither in hotspot nor anywhere else. > > Bug: https://bugs.openjdk.java.net/browse/JDK-6657100 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-6657100-rename-sparcWorks-to-solstudio/webrev.01 make/autoconf/toolchain.m4 ??? No comments. make/nb_native/nbproject/configurations.xml ??? No comments. src/hotspot/share/interpreter/bytecodeHistogram.hpp ??? No comments. src/hotspot/share/runtime/vmStructs.hpp ??? No comments. src/hotspot/share/utilities/count_trailing_zeros.hpp ??? No comments. src/java.base/solaris/native/libjvm_db/libjvm_db.c ??? No comments. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/types/basic/BasicTypeDataBase.java ??? No comments. src/hotspot/share/utilities/globalDefinitions_solstudio.hpp src/hotspot/share/utilities/globalDefinitions_sparcWorks.hpp ??? No comments. Thumbs up! It's nice to see this one get resolved. Thanks! Dan > > /Magnus > From matthias.baesken at sap.com Thu Aug 30 14:14:11 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 30 Aug 2018 14:14:11 +0000 Subject: RFR : 8210205 : build fails on AIX in hotspot cpp tests (for example getstacktr001.cpp) In-Reply-To: <2bbe23cb37044a7cb4ea405fde4adf36@sap.com> References: <2bbe23cb37044a7cb4ea405fde4adf36@sap.com> Message-ID: Thanks , can I have a second review please ? Best regards, Matthias From: Lindenmaier, Goetz Sent: Donnerstag, 30. August 2018 14:17 To: Baesken, Matthias ; 'hotspot-dev at openjdk.java.net' ; 'build-dev at openjdk.java.net' Cc: Doerr, Martin Subject: RE: RFR : 8210205 : build fails on AIX in hotspot cpp tests (for example getstacktr001.cpp) Hi Matthias, Aix is a nuisance. Thanks for fixing this. Looks good. As this is a build fix, and only changes tests, I think you don't need to follow the 24h rule, i.e., you can push it sooner. Best regards, Goetz. From: Baesken, Matthias Sent: Donnerstag, 30. August 2018 13:21 To: 'hotspot-dev at openjdk.java.net' >; 'build-dev at openjdk.java.net' > Cc: Lindenmaier, Goetz >; Doerr, Martin > Subject: RFR : 8210205 : build fails on AIX in hotspot cpp tests (for example getstacktr001.cpp) Hello, please review this small fix to repair our AIX build . Recent changes to jdk/jdk broke the build . We get clashes with defines from system headers in a few compilation units, for example : "/openjdk/nb/rs6000_64/nightly/jdk/test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetStackTrace/getstacktr001/getstacktr001.cpp", line 69.9: 1540-0848 (S) The macro name "NUMBER_OF_FRAMES" is already defined with a different definition. "/usr/include/sys/mstsave.h", line 260.9: 1540-0425 (I) "NUMBER_OF_FRAMES" is defined on line 260 of "/usr/include/sys/mstsave.h". Renaming NUMBER_OF_FRAMES fixes the issue. Bug : https://bugs.openjdk.java.net/browse/JDK-8210205 webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8210205/ Thanks, Matthias From martin.doerr at sap.com Thu Aug 30 14:18:43 2018 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 30 Aug 2018 14:18:43 +0000 Subject: RFR : 8210205 : build fails on AIX in hotspot cpp tests (for example getstacktr001.cpp) In-Reply-To: References: <2bbe23cb37044a7cb4ea405fde4adf36@sap.com> Message-ID: <60a0439d137346ebaf1fe66a73106ff8@sap.com> Hi Matthias, thanks for fixing the build. Looks good. I think it can be treated as trivial and pushed, because it just renames NUMBER_OF_FRAMES to avoid a conflict with AIX stuff. Best regards, Martin From: Baesken, Matthias Sent: Donnerstag, 30. August 2018 16:14 To: Lindenmaier, Goetz ; 'hotspot-dev at openjdk.java.net' ; 'build-dev at openjdk.java.net' Cc: Doerr, Martin Subject: RE: RFR : 8210205 : build fails on AIX in hotspot cpp tests (for example getstacktr001.cpp) Thanks , can I have a second review please ? Best regards, Matthias From: Lindenmaier, Goetz Sent: Donnerstag, 30. August 2018 14:17 To: Baesken, Matthias >; 'hotspot-dev at openjdk.java.net' >; 'build-dev at openjdk.java.net' > Cc: Doerr, Martin > Subject: RE: RFR : 8210205 : build fails on AIX in hotspot cpp tests (for example getstacktr001.cpp) Hi Matthias, Aix is a nuisance. Thanks for fixing this. Looks good. As this is a build fix, and only changes tests, I think you don't need to follow the 24h rule, i.e., you can push it sooner. Best regards, Goetz. From: Baesken, Matthias Sent: Donnerstag, 30. August 2018 13:21 To: 'hotspot-dev at openjdk.java.net' >; 'build-dev at openjdk.java.net' > Cc: Lindenmaier, Goetz >; Doerr, Martin > Subject: RFR : 8210205 : build fails on AIX in hotspot cpp tests (for example getstacktr001.cpp) Hello, please review this small fix to repair our AIX build . Recent changes to jdk/jdk broke the build . We get clashes with defines from system headers in a few compilation units, for example : "/openjdk/nb/rs6000_64/nightly/jdk/test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetStackTrace/getstacktr001/getstacktr001.cpp", line 69.9: 1540-0848 (S) The macro name "NUMBER_OF_FRAMES" is already defined with a different definition. "/usr/include/sys/mstsave.h", line 260.9: 1540-0425 (I) "NUMBER_OF_FRAMES" is defined on line 260 of "/usr/include/sys/mstsave.h". Renaming NUMBER_OF_FRAMES fixes the issue. Bug : https://bugs.openjdk.java.net/browse/JDK-8210205 webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8210205/ Thanks, Matthias From kim.barrett at oracle.com Thu Aug 30 15:30:46 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 30 Aug 2018 11:30:46 -0400 Subject: [12] RFR(XS): 8210164: building Minimal VM fails with error: comparison of unsigned expression < 0 is always false [-Werror=type-limits] In-Reply-To: References: <86331aac-5ab6-ebd1-9f9f-029b953bae9d@redhat.com> Message-ID: > On Aug 30, 2018, at 7:10 AM, Aleksei Voitylov wrote: > > Aleksey, > > thanks for checking in. Here is an updated webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8210164.03/ Consider adding to the #else branch STATIC_ASSERT(serial_phase_count == 0); Looks good to me. > -Aleksei > > > On 30/08/2018 13:53, Aleksey Shipilev wrote: >> On 08/30/2018 12:43 PM, Aleksei Voitylov wrote: >>> please review this patch which fixes Minimal VM build error after b9f6a4427da9 was pushed. I'm >>> suggesting to fix it explicitly as opposed to disabling the compiler warning. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8210164 >>> webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8210164.02/ >> Looks good. Probably deserves a little comment why we are doing this, so we can later remove it if >> we can prove that serial_phase_count is never 0, by code inspection. >> >> Thanks, >> -Aleksey From harold.seigel at oracle.com Thu Aug 30 17:13:59 2018 From: harold.seigel at oracle.com (Harold David Seigel) Date: Thu, 30 Aug 2018 13:13:59 -0400 Subject: RFR (M) 8210155: Lock ClassLoaderDataGraph In-Reply-To: References: Message-ID: Hi Coleen, This looks good.? Just a couple of small questions. In classLoaderData.cpp, can you get rid of line 1096 and change 1097 to cld->set_next(_head);? ? 1096?? ClassLoaderData* next = _head; 1097?? cld->set_next(next); 1098?? _head = cld; In some places, it's unclear when a ClassLoaderDatagraph_lock is needed.? For example, why does CLDG::methods_do() need the lock but CLDG::classes_do() doesn't ?? Can you add a few comments? In CMSCollector::preclean_cld(), do you need to hold the lock for the whole function or just until cld_do() is done?? Same question for compute() in klassVtable.cpp. Thanks! Harold On 8/29/2018 12:07 PM, coleen.phillimore at oracle.com wrote: > Summary: In preparation for concurrent class unloading. > > open webrev at http://cr.openjdk.java.net/~coleenp/8210155.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8210155 > > Tested with mach5 hs-tier1-7, which tests JFR and JVMTI changes. Also > tested with performance dev-submit testing with no regression. > > Thanks, > Coleen From erik.osterlund at oracle.com Thu Aug 30 17:31:57 2018 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Thu, 30 Aug 2018 19:31:57 +0200 Subject: RFR (M) 8210155: Lock ClassLoaderDataGraph In-Reply-To: References: Message-ID: Hi Coleen, This looks good to me. I cherry picked this into my concurrent class unloading branch (and added the new lock around do_unloading). It passed GC test suite unloading and deleting classes concurrently, and also scanning the CLD roots concurrently. So that seems all good. Thanks for making this code more concurrency friendly. Thanks, /Erik > On 29 Aug 2018, at 18:07, coleen.phillimore at oracle.com wrote: > > Summary: In preparation for concurrent class unloading. > > open webrev at http://cr.openjdk.java.net/~coleenp/8210155.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8210155 > > Tested with mach5 hs-tier1-7, which tests JFR and JVMTI changes. Also tested with performance dev-submit testing with no regression. > > Thanks, > Coleen From jiangli.zhou at oracle.com Thu Aug 30 18:26:42 2018 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Thu, 30 Aug 2018 11:26:42 -0700 Subject: RFR: JDK-8202951: Implementation of JEPJDK-8204247: Include default CDS (Class Data Sharing) archive in JDK binary In-Reply-To: References: <8e17729f-9f5b-4d7c-a8cf-e0d3ffeeb694@oracle.com> Message-ID: Hi Magnus, Sounds good. Will update the message. Thanks! Jiangli On 8/30/18 3:56 AM, Magnus Ihse Bursie wrote: > On 2018-08-29 17:45, Erik Joelsson wrote: >> >> Hello Magnus, >> >> As the author of the build changes I will answer this. >> >> On 2018-08-29 04:53, Magnus Ihse Bursie wrote: >>> On 2018-08-28 18:25, Erik Joelsson wrote: >>>> Build changes look good to me (but should probably get review from >>>> someone else). >>> >>> I'm (as usually) not as happy as Erik. ;-) >>> >>> In Images.gmk, you have added this rule: >>> ????????? $@ -Xshare:dump -Xmx128M -Xms128M $(LOG_INFO) >>> >>> It took me a while to grasp. You are relying on >>> $(JIMAGE_TARGET_FILE) to evaluate to bin/java. But that is only >>> incidentally so. This file is just picked arbitrarily to represent >>> when the entire image is done, for make. Please use >>> $(JRE_IMAGE_DIR)/bin/java instead. >>> >> I can agree with this part. That was a bit of a hack done in a hurry. >>> The logic in jdk-options.m4 is broken. If indeed it is not possible >>> to use cds archive with zero, then things will break since it will >>> still be built if using --enable-cds-archive! >>> >>> What you should do is to set default to true unless using cross >>> compilation or zero. If the user explicitly sets >>> --enable-cds-archive, and it's not possible, a fatal error should be >>> generated. >>> >> Here I'm not as sure. I deliberately let it be possible to override >> the default behavior for zero as someone might want to fix that at >> some point, you never know. For cross compilation it's just not >> possible ever so that's different. Maybe my reasoning is invalid. > > I see. I still think it would have made more sense, in that case, to > set the default to false if using zero, but allow override. But I'm > not going to insist on that. > > However, if the problem with zero is not that it's technically > impossible, just that it's not tested, I think the message should be > changed from "[no, not possible with JVM variant zero]" to just "[no]" > with a comment in the configure script that it's off by default since > it's not tested. > > Apart from that, Jiangli's latest webrev looks good. > > Jiangli: If you fix it like I suggested, you do not need to respin the > webrev. > > /Magnus > >> >> /Erik >>> Apart from this, I'm more on Erik's line. :-) >>> >>> /Magnus >>> >>> >>> >>>> >>>> /Erik >>>> >>>> >>>> On 2018-08-27 13:33, Jiangli Zhou wrote: >>>>> Please review the implementation for JEP JDK-8204247 >>>>> (https://bugs.openjdk.java.net/browse/JDK-8204247). The goal of >>>>> the JEP is to include a default CDS archive in JDK 12 binary >>>>> distribution (downloadable from http://jdk.java.net/12/). The >>>>> default CDS archive is generated using the default classlist >>>>> (resides in the lib/ directory) at JDK build time. Any >>>>> comments/suggestions are highly appreciated. >>>>> >>>>> All makefile changes in the webrev are contributed by Erik >>>>> Joelsson (many thanks!!). >>>>> >>>>> This is a combination of efforts from different teams and >>>>> individuals. Thanks to everyone who has been involved in the JEP & >>>>> implementation discussions, testing and bug fixing! >>>>> >>>>> ? JEP: https://bugs.openjdk.java.net/browse/JDK-8204247 >>>>> ? RFE: https://bugs.openjdk.java.net/browse/JDK-8202951 >>>>> ? webrev: http://cr.openjdk.java.net/~jiangli/8202951/webrev.00/ >>>>> >>>>> Two sanity test cases for the default CDS archive are included >>>>> test/hotspot/jtreg/runtime/SharedArchiveFile. They are not >>>>> intended for in-depth CDS functional testing, which is already >>>>> covered by the existing cds/appcds tests and all tiered tests >>>>> executing with the default CDS archive enabled. >>>>> >>>>> As part of the webrev, >>>>> test/jdk/javax/imageio/plugins/png/ItxtUtf8Test.java is also fixed >>>>> to use larger java heap (JDK-8209739 >>>>> , https://bugs.openjdk.java.net/browse/JDK-8209739). >>>>> >>>>> Tests executed: >>>>> ?- several rounds of tier1 - tier8 via mach5 >>>>> ?- JCK lang, api and vm tests via mach5 >>>>> >>>>> >>>>> Thanks! >>>>> Calvin, Ioi, Jiangli >>>>> >>>>> >>>> >>> >> > From aleksei.voitylov at bell-sw.com Thu Aug 30 19:00:12 2018 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Thu, 30 Aug 2018 22:00:12 +0300 Subject: [12] RFR(XS): 8210164: building Minimal VM fails with error: comparison of unsigned expression < 0 is always false [-Werror=type-limits] In-Reply-To: References: <86331aac-5ab6-ebd1-9f9f-029b953bae9d@redhat.com> Message-ID: <27f47951-e89f-1c39-b32b-759605799e55@bell-sw.com> Hi, added the assert. Thanks for the suggestion. Here is an updated webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8210164.04/ -Aleksei On 30/08/2018 18:30, Kim Barrett wrote: >> On Aug 30, 2018, at 7:10 AM, Aleksei Voitylov wrote: >> >> Aleksey, >> >> thanks for checking in. Here is an updated webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8210164.03/ > Consider adding to the #else branch > > STATIC_ASSERT(serial_phase_count == 0); > > Looks good to me. > >> -Aleksei >> >> >> On 30/08/2018 13:53, Aleksey Shipilev wrote: >>> On 08/30/2018 12:43 PM, Aleksei Voitylov wrote: >>>> please review this patch which fixes Minimal VM build error after b9f6a4427da9 was pushed. I'm >>>> suggesting to fix it explicitly as opposed to disabling the compiler warning. >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8210164 >>>> webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8210164.02/ >>> Looks good. Probably deserves a little comment why we are doing this, so we can later remove it if >>> we can prove that serial_phase_count is never 0, by code inspection. >>> >>> Thanks, >>> -Aleksey > From erik.osterlund at oracle.com Thu Aug 30 19:08:10 2018 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Thu, 30 Aug 2018 21:08:10 +0200 Subject: RFR: 8210236: Prepare ciReceiverTypeData::translate_receiver_data_from for concurrent class unloading Message-ID: Hi, When concurrently unloading classes, it is possible for MDOs to have stale metadata entries in them until the GC comes around to clean it up. That is fine, but there is one place where extra care needs to be taken: when the compiler interface fetches ReceiverTypeData. This is done by memcpy:ing the ReceiverTypeData to a new memory buffer, and walking the metadata, patching it with corresponding ci metadata classes in the new buffer. The metadata could be stale by now. In such scenarios, the rows should be lazily cleaned. Once the ci metadata handles are created, they are safe to use in the rest of the code. This patch builds on 8210233 which makes Klass::is_loader_alive() concurrency friendly using phantom loads. Webrev: http://cr.openjdk.java.net/~eosterlund/8210236/webrev.00 Bug: https://bugs.openjdk.java.net/browse/JDK-8210236 Thanks, /Erik From coleen.phillimore at oracle.com Thu Aug 30 19:59:05 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 30 Aug 2018 15:59:05 -0400 Subject: RFR (M) 8210155: Lock ClassLoaderDataGraph In-Reply-To: References: Message-ID: <9b18b09c-b558-d837-7b06-ff16884dd409@oracle.com> On 8/30/18 1:13 PM, Harold David Seigel wrote: > Hi Coleen, > > This looks good.? Just a couple of small questions. > > In classLoaderData.cpp, can you get rid of line 1096 and change 1097 > to cld->set_next(_head);? ? > > ?? 1096?? ClassLoaderData* next = _head; > ?? 1097?? cld->set_next(next); > ?? 1098?? _head = cld; Yes, fixed that. > > In some places, it's unclear when a ClassLoaderDatagraph_lock is > needed.? For example, why does CLDG::methods_do() need the lock but > CLDG::classes_do() doesn't ?? Can you add a few comments? I wanted to take out the lock in the CLDG::blah_do functions directly but they are called in various contexts, including during safepoint, so the caller needs to take the lock if it is outside a safepoint. CLDG::methods_do was inconsistent though.? I moved the lock into its one caller.?? I added the comment: // These functions assume that the caller has locked the ClassLoaderDataGraph_lock // if they are not calling the function from a safepoint. > > In CMSCollector::preclean_cld(), do you need to hold the lock for the > whole function or just until cld_do() is done?? Same question for > compute() in klassVtable.cpp. For the CMS function, the lock has to be held outside the CMSTokenSyncWithLocks because of rankings, so I can't change that. klassVtable.cpp compute does little after taking the lock, so it doesn't seem worth putting it into a scope by itself. Thank for reviewing! Coleen > > Thanks! Harold > > On 8/29/2018 12:07 PM, coleen.phillimore at oracle.com wrote: >> Summary: In preparation for concurrent class unloading. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8210155.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8210155 >> >> Tested with mach5 hs-tier1-7, which tests JFR and JVMTI changes. Also >> tested with performance dev-submit testing with no regression. >> >> Thanks, >> Coleen > From coleen.phillimore at oracle.com Thu Aug 30 20:02:04 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 30 Aug 2018 16:02:04 -0400 Subject: RFR (M) 8210155: Lock ClassLoaderDataGraph In-Reply-To: References: Message-ID: <30a2620d-acd4-cc55-a4a8-8a96efeca21e@oracle.com> On 8/30/18 1:31 PM, Erik Osterlund wrote: > Hi Coleen, > > This looks good to me. I cherry picked this into my concurrent class unloading branch (and added the new lock around do_unloading). It passed GC test suite unloading and deleting classes concurrently, and also scanning the CLD roots concurrently. So that seems all good. This is good!?? Thank you for reviewing and taking it for a test drive. Coleen > > Thanks for making this code more concurrency friendly. > > Thanks, > /Erik > >> On 29 Aug 2018, at 18:07, coleen.phillimore at oracle.com wrote: >> >> Summary: In preparation for concurrent class unloading. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8210155.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8210155 >> >> Tested with mach5 hs-tier1-7, which tests JFR and JVMTI changes. Also tested with performance dev-submit testing with no regression. >> >> Thanks, >> Coleen From kim.barrett at oracle.com Thu Aug 30 20:14:40 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 30 Aug 2018 16:14:40 -0400 Subject: [12] RFR(XS): 8210164: building Minimal VM fails with error: comparison of unsigned expression < 0 is always false [-Werror=type-limits] In-Reply-To: <27f47951-e89f-1c39-b32b-759605799e55@bell-sw.com> References: <86331aac-5ab6-ebd1-9f9f-029b953bae9d@redhat.com> <27f47951-e89f-1c39-b32b-759605799e55@bell-sw.com> Message-ID: <6902B6B6-C805-4A1B-BF0F-AC1717490B1F@oracle.com> > On Aug 30, 2018, at 3:00 PM, Aleksei Voitylov wrote: > > Hi, > > added the assert. Thanks for the suggestion. Here is an updated webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8210164.04/ > > -Aleksei Looks good. I think you aren?t a committer yet? If so, I can sponsor this change. From aleksei.voitylov at bell-sw.com Thu Aug 30 20:15:24 2018 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Thu, 30 Aug 2018 23:15:24 +0300 Subject: [12] RFR(XS): 8210164: building Minimal VM fails with error: comparison of unsigned expression < 0 is always false [-Werror=type-limits] In-Reply-To: <6902B6B6-C805-4A1B-BF0F-AC1717490B1F@oracle.com> References: <86331aac-5ab6-ebd1-9f9f-029b953bae9d@redhat.com> <27f47951-e89f-1c39-b32b-759605799e55@bell-sw.com> <6902B6B6-C805-4A1B-BF0F-AC1717490B1F@oracle.com> Message-ID: <2604f457-57e0-08f2-6c15-7fe95088ce3c@bell-sw.com> Kim, that would be much appreciated. Thanks for the review! -Aleksei On 30/08/2018 23:14, Kim Barrett wrote: >> On Aug 30, 2018, at 3:00 PM, Aleksei Voitylov wrote: >> >> Hi, >> >> added the assert. Thanks for the suggestion. Here is an updated webrev: http://cr.openjdk.java.net/~avoitylov/webrev.8210164.04/ >> >> -Aleksei > Looks good. > > I think you aren?t a committer yet? If so, I can sponsor this change. > From harold.seigel at oracle.com Thu Aug 30 20:25:48 2018 From: harold.seigel at oracle.com (Harold David Seigel) Date: Thu, 30 Aug 2018 16:25:48 -0400 Subject: RFR (M) 8210155: Lock ClassLoaderDataGraph In-Reply-To: <9b18b09c-b558-d837-7b06-ff16884dd409@oracle.com> References: <9b18b09c-b558-d837-7b06-ff16884dd409@oracle.com> Message-ID: <3441c881-e79f-1f26-49b5-b37459230861@oracle.com> That sounds good! Thanks, Harold On 8/30/2018 3:59 PM, coleen.phillimore at oracle.com wrote: > > > On 8/30/18 1:13 PM, Harold David Seigel wrote: >> Hi Coleen, >> >> This looks good.? Just a couple of small questions. >> >> In classLoaderData.cpp, can you get rid of line 1096 and change 1097 >> to cld->set_next(_head);? ? >> >> ?? 1096?? ClassLoaderData* next = _head; >> ?? 1097?? cld->set_next(next); >> ?? 1098?? _head = cld; > > Yes, fixed that. >> >> In some places, it's unclear when a ClassLoaderDatagraph_lock is >> needed.? For example, why does CLDG::methods_do() need the lock but >> CLDG::classes_do() doesn't ?? Can you add a few comments? > > I wanted to take out the lock in the CLDG::blah_do functions directly > but they are called in various contexts, including during safepoint, > so the caller needs to take the lock if it is outside a safepoint. > > CLDG::methods_do was inconsistent though.? I moved the lock into its > one caller.?? I added the comment: > > // These functions assume that the caller has locked the > ClassLoaderDataGraph_lock > // if they are not calling the function from a safepoint. > >> >> In CMSCollector::preclean_cld(), do you need to hold the lock for the >> whole function or just until cld_do() is done?? Same question for >> compute() in klassVtable.cpp. > > For the CMS function, the lock has to be held outside the > CMSTokenSyncWithLocks because of rankings, so I can't change that. > klassVtable.cpp compute does little after taking the lock, so it > doesn't seem worth putting it into a scope by itself. > > Thank for reviewing! > Coleen >> >> Thanks! Harold >> >> On 8/29/2018 12:07 PM, coleen.phillimore at oracle.com wrote: >>> Summary: In preparation for concurrent class unloading. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8210155.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8210155 >>> >>> Tested with mach5 hs-tier1-7, which tests JFR and JVMTI changes. >>> Also tested with performance dev-submit testing with no regression. >>> >>> Thanks, >>> Coleen >> > From coleen.phillimore at oracle.com Thu Aug 30 20:45:31 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 30 Aug 2018 16:45:31 -0400 Subject: RFR (M) 8210155: Lock ClassLoaderDataGraph In-Reply-To: <3441c881-e79f-1f26-49b5-b37459230861@oracle.com> References: <9b18b09c-b558-d837-7b06-ff16884dd409@oracle.com> <3441c881-e79f-1f26-49b5-b37459230861@oracle.com> Message-ID: On 8/30/18 4:25 PM, Harold David Seigel wrote: > That sounds good! Thanks, Harold.? I'll give it a last mach5 spin but I only changed these three small things. Coleen > > Thanks, Harold > > > On 8/30/2018 3:59 PM, coleen.phillimore at oracle.com wrote: >> >> >> On 8/30/18 1:13 PM, Harold David Seigel wrote: >>> Hi Coleen, >>> >>> This looks good.? Just a couple of small questions. >>> >>> In classLoaderData.cpp, can you get rid of line 1096 and change 1097 >>> to cld->set_next(_head);? ? >>> >>> ?? 1096?? ClassLoaderData* next = _head; >>> ?? 1097?? cld->set_next(next); >>> ?? 1098?? _head = cld; >> >> Yes, fixed that. >>> >>> In some places, it's unclear when a ClassLoaderDatagraph_lock is >>> needed.? For example, why does CLDG::methods_do() need the lock but >>> CLDG::classes_do() doesn't ?? Can you add a few comments? >> >> I wanted to take out the lock in the CLDG::blah_do functions directly >> but they are called in various contexts, including during safepoint, >> so the caller needs to take the lock if it is outside a safepoint. >> >> CLDG::methods_do was inconsistent though.? I moved the lock into its >> one caller.?? I added the comment: >> >> // These functions assume that the caller has locked the >> ClassLoaderDataGraph_lock >> // if they are not calling the function from a safepoint. >> >>> >>> In CMSCollector::preclean_cld(), do you need to hold the lock for >>> the whole function or just until cld_do() is done?? Same question >>> for compute() in klassVtable.cpp. >> >> For the CMS function, the lock has to be held outside the >> CMSTokenSyncWithLocks because of rankings, so I can't change that. >> klassVtable.cpp compute does little after taking the lock, so it >> doesn't seem worth putting it into a scope by itself. >> >> Thank for reviewing! >> Coleen >>> >>> Thanks! Harold >>> >>> On 8/29/2018 12:07 PM, coleen.phillimore at oracle.com wrote: >>>> Summary: In preparation for concurrent class unloading. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8210155.01/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8210155 >>>> >>>> Tested with mach5 hs-tier1-7, which tests JFR and JVMTI changes. >>>> Also tested with performance dev-submit testing with no regression. >>>> >>>> Thanks, >>>> Coleen >>> >> > From dean.long at oracle.com Fri Aug 31 00:20:56 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 30 Aug 2018 17:20:56 -0700 Subject: RFR(S) 8209361: [AOT] Unexpected number of references for JVMTI_HEAP_REFERENCE_CONSTANT_POOL [111-->111]: 0 (expected at least 1) Message-ID: <0068f831-ddff-5000-c7fc-7acefffc9756@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8209361 http://cr.openjdk.java.net/~dlong/8209361/webrev/ Some JCK vm/jvmti/FollowReferences tests fail with AOT.? This is because code generated by JIT and AOT compilers might not resolve constant pool entries.? Making the compiled code resolve constant pool entries would hurt performance.? As far as I can tell, the JVMTI FollowReferences API is the only place this is visible, so I went with a localized fix.? The fix looks at unresolved constant pool entries and treats them as resolved if the class is loaded and accessible.? Some entries can appear to be resolved early, but this is allowed by the JVM spec, and it meets all the requirements of a resolved symbolic reference (it will always return the same concrete class value, JVM spec section 5.4.3). dl From kim.barrett at oracle.com Fri Aug 31 02:15:48 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 30 Aug 2018 22:15:48 -0400 Subject: RFR: 8210131: vmTestbase/nsk/jvmti/scenarios/allocation/AP10/ap10t001/TestDescription.java failed with ObjectFree: GetCurrentThreadCpuTimerInfo returned unexpected error code Message-ID: <39905239-72B3-46A9-B31E-3B01FA5B9BAB@oracle.com> Please review this small change to GetCurrentThreadCpuTimerInfo and GetCurrentThreadCpuTime JVMTI operations, allowing them to be called from any NamedThread. This is consistent with the behavior from JDK-8203948; there is no obvious reason for these operations to have any thread context restriction. These functions are documented as being callable from heap callbacks like ObjectFree, which can be called from an "internal thread or the thread that called the [heap] iteration function". However, unlike other, similar functions, these two were requiring the current thread to be either a JavaThread or the VMThread. For other such functions, JDK-6278106 had added Concurrent GC threads, and JDK-8203948 generalized that to any NamedThread (or JavaThread). This change makes these functions behave similarly. This is needed to allow such callbacks to be invoked from a GC worker thread, such as is now done for G1 (JDK-8072498), and probably other collectors in the future. (See comments for JDK-8203948 for a discussion of why ZGC didn't run into this problem.) This change also removes the failing test from the problem list. CR: https://bugs.openjdk.java.net/browse/JDK-8210131 Webrev: http://cr.openjdk.java.net/~kbarrett/8210131/open.00/ Testing: mach5 tier1-3, hs-tier4-6. Local (linux-x64) jtreg:hotspot_gc, and manually ran the failing test. Examined the generated jvmtiEnter[Trace].cpp file and verified the change to the generated code was as expected. From aleksei.voitylov at bell-sw.com Fri Aug 31 05:07:39 2018 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Fri, 31 Aug 2018 08:07:39 +0300 Subject: [aarch64-port-dev ] [12] RFR(S): 8207247 AARCH64: Enable Minimal and Client VM builds In-Reply-To: References: <3a18c72d-35e1-f7b3-6ea9-b37fd29b4834@bell-sw.com> <999091f1-186d-5087-2cfe-fbb161182191@redhat.com> <1afaf9af-38e9-8512-3553-d642b7df089f@bell-sw.com> <0269b8c5-bef8-94c7-054a-09d342af2df0@redhat.com> <8ac750b9-bd20-46da-1d7f-6214c0699861@bell-sw.com> Message-ID: <874b5ef5-828c-a19d-1254-c9ab32180791@bell-sw.com> Thank you for review! On 30/08/2018 16:08, Andrew Haley wrote: > On 08/30/2018 12:14 PM, Aleksei Voitylov wrote: >> here is an updated webrev which addresses all comments: >> http://cr.openjdk.java.net/~avoitylov/webrev.8207247.03/ > Sweet! That's perfect, thanks. > From magnus.ihse.bursie at oracle.com Fri Aug 31 08:43:45 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 31 Aug 2018 10:43:45 +0200 Subject: [patch] add zero support for x86_64-linux-gnux32 target In-Reply-To: <490d3972-937f-893a-dd97-ae8759493e59@oracle.com> References: <44e0be8d-f78b-0143-ebf7-d23937becdfd@ubuntu.com> <1473077772.2884.11.camel@redhat.com> <490d3972-937f-893a-dd97-ae8759493e59@oracle.com> Message-ID: <387a38af-d5b0-432e-d3ab-185a31b58395@oracle.com> The necroposter strikes back! :-) I'm currently trying to fix or close all long standing bugs on infrastructure/build, and now the time has come to JDK-8165440. This patch had a bit of bad timing when it was posted, since it could not be accepted into mainline due to feature freeze, and there were no other repo to accept it. I adjusted the patch to the current code base (which means that most parts of it were not needed). What remains are two files. However, I can't test if this works. Matthias, can you verify that this is a working patch for jdk/jdk for the gnux32 target? If so, I'll sponsor this patch. diff --git a/make/autoconf/platform.m4 b/make/autoconf/platform.m4 --- a/make/autoconf/platform.m4 +++ b/make/autoconf/platform.m4 @@ -35,6 +35,10 @@ ?????? VAR_CPU_ARCH=x86 ?????? VAR_CPU_BITS=64 ?????? VAR_CPU_ENDIAN=little +????? case "$host" in *x32) +??????? VAR_CPU=x32 +??????? VAR_CPU_BITS=32 +????? esac ?????? ;; ???? i?86) ?????? VAR_CPU=x86 @@ -455,6 +459,8 @@ ???? HOTSPOT_$1_CPU_DEFINE=IA32 ?? elif test "x$OPENJDK_$1_CPU" = xx86_64; then ???? HOTSPOT_$1_CPU_DEFINE=AMD64 +? elif test "x$OPENJDK_$1_CPU" = xx32; then +??? HOTSPOT_$1_CPU_DEFINE=X32 ?? elif test "x$OPENJDK_$1_CPU" = xsparcv9; then ???? HOTSPOT_$1_CPU_DEFINE=SPARC ?? elif test "x$OPENJDK_$1_CPU" = xaarch64; then diff --git a/src/hotspot/os/linux/os_linux.cpp b/src/hotspot/os/linux/os_linux.cpp --- a/src/hotspot/os/linux/os_linux.cpp +++ b/src/hotspot/os/linux/os_linux.cpp @@ -1742,7 +1742,7 @@ ?#if? (defined IA32) ?? static? Elf32_Half running_arch_code=EM_386; -#elif?? (defined AMD64) +#elif?? (defined AMD64) || defined(X32) ?? static? Elf32_Half running_arch_code=EM_X86_64; ?#elif? (defined IA64) ?? static? Elf32_Half running_arch_code=EM_IA_64; /Magnus On 2016-09-06 01:01, David Holmes wrote: > Hi Severin, Matthias, > > On 5/09/2016 10:16 PM, Severin Gehwolf wrote: >> On Mon, 2016-09-05 at 14:03 +0200, Matthias Klose wrote: >>> The attached patch adds support for building zero for the x86_64- >>> linux-gnux32 >>> target, having changes in the build system, hotspot and jdk. >>> >>> ?- the build system currently only derives the target from >>> ?? the cpu in PLATFORM_EXTRACT_VARS_FROM_CPU; that is not enough >>> ?? for the new target, which only differs by the ending of the >>> ?? triplet. However the $host macro should be available anywhere. >>> >>> ?- the hotspot part just handles the new "cpu" >>> >>> ?- GensrcX11Wrappers.gmk assumes that there is a black/white >>> ?? decision about -m32/-m64. The patch works around it. However >>> ?? the real patch should be to get these flags from the build >>> ?? system, and not hardcode itself. >>> >>> ?- the sysctl system call is unsupported in the x32 kernel, and >>> ?? just the include leads to a build error.? From my point of view >>> ?? the header is not needed. I had successful builds on all other >>> ?? targets without including it. If you want to keep the include, >>> ?? then it should be guarded with >>> ?? #if !(defined(_ILP32) && defined(__x86_64__)) >>> >>> Matthias >> >> I've filed this bug for this: >> https://bugs.openjdk.java.net/browse/JDK-8165440 > > Please note that as a P4 issue this can not be fixed given we have hit > RDP1: > > http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-August/004777.html > > Further this is filed as "bug" but seems to clearly be an enhancement, > so you would need approval for it to come in post-Feature-Complete. > > Please consider if this is something that must be fixed for 9 or can > be deferred. Otherwise you will need to follow additional approval > processes. > > Sorry. > > David (just the messenger!) > >> Unfortunately, I have no way of testing it. >> >> Cheers, >> Severin >> From glaubitz at physik.fu-berlin.de Fri Aug 31 08:57:03 2018 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Fri, 31 Aug 2018 10:57:03 +0200 Subject: [patch] add zero support for x86_64-linux-gnux32 target In-Reply-To: <387a38af-d5b0-432e-d3ab-185a31b58395@oracle.com> References: <44e0be8d-f78b-0143-ebf7-d23937becdfd@ubuntu.com> <1473077772.2884.11.camel@redhat.com> <490d3972-937f-893a-dd97-ae8759493e59@oracle.com> <387a38af-d5b0-432e-d3ab-185a31b58395@oracle.com> Message-ID: On 08/31/2018 10:43 AM, Magnus Ihse Bursie wrote: > I adjusted the patch to the current code base (which means that most parts of it were not needed). What remains are two files. However, I can't test if this works. Matthias, can you verify that this is a working patch for jdk/jdk for the gnux32 target? If so, I'll sponsor this patch. I can test it. Didn't know that Matthias posted a patch for x32 support. The current patch that the Debian openjdk-11 package is using at the moment can be found in [1]. Adrian > [1] https://sources.debian.org/src/openjdk-11/11%7E27-1/debian/patches/zero-x32.diff/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From glaubitz at physik.fu-berlin.de Fri Aug 31 08:59:11 2018 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Fri, 31 Aug 2018 10:59:11 +0200 Subject: [patch] add zero support for x86_64-linux-gnux32 target In-Reply-To: References: <44e0be8d-f78b-0143-ebf7-d23937becdfd@ubuntu.com> <1473077772.2884.11.camel@redhat.com> <490d3972-937f-893a-dd97-ae8759493e59@oracle.com> <387a38af-d5b0-432e-d3ab-185a31b58395@oracle.com> Message-ID: On 08/31/2018 10:57 AM, John Paul Adrian Glaubitz wrote: > On 08/31/2018 10:43 AM, Magnus Ihse Bursie wrote: >> I adjusted the patch to the current code base (which means that most parts of it were not needed). What remains are two files. However, I can't test if this works. Matthias, can you verify that this is a working patch for jdk/jdk for the gnux32 target? If so, I'll sponsor this patch. > I can test it. Didn't know that Matthias posted a patch for x32 > support. The current patch that the Debian openjdk-11 package > is using at the moment can be found in [1]. Oh, and here's the build log of openjdk-11 in Debian with that patch [1]. Adrian > [1] https://buildd.debian.org/status/fetch.php?pkg=openjdk-11&arch=x32&ver=11%7E27-1&stamp=1534788109&raw=0 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From magnus.ihse.bursie at oracle.com Fri Aug 31 09:19:30 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 31 Aug 2018 11:19:30 +0200 Subject: [patch] add zero support for x86_64-linux-gnux32 target In-Reply-To: References: <44e0be8d-f78b-0143-ebf7-d23937becdfd@ubuntu.com> <1473077772.2884.11.camel@redhat.com> <490d3972-937f-893a-dd97-ae8759493e59@oracle.com> <387a38af-d5b0-432e-d3ab-185a31b58395@oracle.com> Message-ID: <99b81624-7d84-883e-2219-916a993fd723@oracle.com> On 2018-08-31 10:57, John Paul Adrian Glaubitz wrote: > On 08/31/2018 10:43 AM, Magnus Ihse Bursie wrote: >> I adjusted the patch to the current code base (which means that most parts of it were not needed). What remains are two files. However, I can't test if this works. Matthias, can you verify that this is a working patch for jdk/jdk for the gnux32 target? If so, I'll sponsor this patch. > I can test it. Didn't know that Matthias posted a patch for x32 > support. The current patch that the Debian openjdk-11 package > is using at the moment can be found in [1]. Hah! That's exactly the same patch as I derived. :-) So that means, I assume, that the patch has been tested properly? If so I'll just sponsor and push it. /Magnus > > Adrian > >> [1] https://sources.debian.org/src/openjdk-11/11%7E27-1/debian/patches/zero-x32.diff/ From glaubitz at physik.fu-berlin.de Fri Aug 31 09:24:29 2018 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Fri, 31 Aug 2018 11:24:29 +0200 Subject: [patch] add zero support for x86_64-linux-gnux32 target In-Reply-To: <99b81624-7d84-883e-2219-916a993fd723@oracle.com> References: <44e0be8d-f78b-0143-ebf7-d23937becdfd@ubuntu.com> <1473077772.2884.11.camel@redhat.com> <490d3972-937f-893a-dd97-ae8759493e59@oracle.com> <387a38af-d5b0-432e-d3ab-185a31b58395@oracle.com> <99b81624-7d84-883e-2219-916a993fd723@oracle.com> Message-ID: On 08/31/2018 11:19 AM, Magnus Ihse Bursie wrote: > Hah! That's exactly the same patch as I derived. :-) Great. > So that means, I assume, that the patch has been tested properly? If so I'll just sponsor and push it. (sid-x32-sbuild)root at epyc:/# file /usr/lib/jvm/java-11-openjdk-x32/bin/java /usr/lib/jvm/java-11-openjdk-x32/bin/java: ELF 32-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /libx32/ld-linux-x32.so.2, for GNU/Linux 3.4.0, BuildID[sha1]=feec974bc65365772119c032d534e49839f8df8f, stripped (sid-x32-sbuild)root at epyc:/# /usr/lib/jvm/java-11-openjdk-x32/bin/java --version openjdk 11 2018-09-25 OpenJDK Runtime Environment (build 11+27-Debian-1) OpenJDK Zero VM (build 11+27-Debian-1, interpreted mode) (sid-x32-sbuild)root at epyc:/# Yes. Go ahead, please :-). Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From glaubitz at physik.fu-berlin.de Fri Aug 31 11:25:49 2018 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Fri, 31 Aug 2018 13:25:49 +0200 Subject: [patch] add zero support for x86_64-linux-gnux32 target In-Reply-To: <387a38af-d5b0-432e-d3ab-185a31b58395@oracle.com> References: <44e0be8d-f78b-0143-ebf7-d23937becdfd@ubuntu.com> <1473077772.2884.11.camel@redhat.com> <490d3972-937f-893a-dd97-ae8759493e59@oracle.com> <387a38af-d5b0-432e-d3ab-185a31b58395@oracle.com> Message-ID: Hi Magnus! I just tested it and the following change in make/autoconf/flags.m4 is necessary as well so that gcc is not called with "-m64": diff -r 18afb2097ada -r 1f28530b1f46 make/autoconf/flags.m4 --- a/make/autoconf/flags.m4 Fri Aug 31 11:43:06 2018 +0200 +++ b/make/autoconf/flags.m4 Fri Aug 31 12:50:02 2018 +0200 @@ -241,7 +241,8 @@ elif test "x$TOOLCHAIN_TYPE" = xsolstudio; then MACHINE_FLAG="-m${OPENJDK_TARGET_CPU_BITS}" elif test "x$TOOLCHAIN_TYPE" = xgcc || test "x$TOOLCHAIN_TYPE" = xclang; then - if test "x$OPENJDK_TARGET_CPU_ARCH" = xx86 || + if test "x$OPENJDK_TARGET_CPU_ARCH" = xx86 && + test "x$OPENJDK_TARGET_CPU" != xx32 || test "x$OPENJDK_TARGET_CPU_ARCH" = xsparc || test "x$OPENJDK_TARGET_CPU_ARCH" = xppc; then MACHINE_FLAG="-m${OPENJDK_TARGET_CPU_BITS}" Adrian On 08/31/2018 10:43 AM, Magnus Ihse Bursie wrote: > The necroposter strikes back! :-) > > I'm currently trying to fix or close all long standing bugs on infrastructure/build, and now the time has come to JDK-8165440. > > This patch had a bit of bad timing when it was posted, since it could not be accepted into mainline due to feature freeze, and there were no other repo to accept it. > > I adjusted the patch to the current code base (which means that most parts of it were not needed). What remains are two files. However, I can't test if this works. Matthias, can you verify that this is a working patch for jdk/jdk for the gnux32 target? If so, I'll sponsor this patch. > > diff --git a/make/autoconf/platform.m4 b/make/autoconf/platform.m4 > --- a/make/autoconf/platform.m4 > +++ b/make/autoconf/platform.m4 > @@ -35,6 +35,10 @@ > ?????? VAR_CPU_ARCH=x86 > ?????? VAR_CPU_BITS=64 > ?????? VAR_CPU_ENDIAN=little > +????? case "$host" in *x32) > +??????? VAR_CPU=x32 > +??????? VAR_CPU_BITS=32 > +????? esac > ?????? ;; > ???? i?86) > ?????? VAR_CPU=x86 > @@ -455,6 +459,8 @@ > ???? HOTSPOT_$1_CPU_DEFINE=IA32 > ?? elif test "x$OPENJDK_$1_CPU" = xx86_64; then > ???? HOTSPOT_$1_CPU_DEFINE=AMD64 > +? elif test "x$OPENJDK_$1_CPU" = xx32; then > +??? HOTSPOT_$1_CPU_DEFINE=X32 > ?? elif test "x$OPENJDK_$1_CPU" = xsparcv9; then > ???? HOTSPOT_$1_CPU_DEFINE=SPARC > ?? elif test "x$OPENJDK_$1_CPU" = xaarch64; then > diff --git a/src/hotspot/os/linux/os_linux.cpp b/src/hotspot/os/linux/os_linux.cpp > --- a/src/hotspot/os/linux/os_linux.cpp > +++ b/src/hotspot/os/linux/os_linux.cpp > @@ -1742,7 +1742,7 @@ > > ?#if? (defined IA32) > ?? static? Elf32_Half running_arch_code=EM_386; > -#elif?? (defined AMD64) > +#elif?? (defined AMD64) || defined(X32) > ?? static? Elf32_Half running_arch_code=EM_X86_64; > ?#elif? (defined IA64) > ?? static? Elf32_Half running_arch_code=EM_IA_64; > > /Magnus > > On 2016-09-06 01:01, David Holmes wrote: >> Hi Severin, Matthias, >> >> On 5/09/2016 10:16 PM, Severin Gehwolf wrote: >>> On Mon, 2016-09-05 at 14:03 +0200, Matthias Klose wrote: >>>> The attached patch adds support for building zero for the x86_64- >>>> linux-gnux32 >>>> target, having changes in the build system, hotspot and jdk. >>>> >>>> ?- the build system currently only derives the target from >>>> ?? the cpu in PLATFORM_EXTRACT_VARS_FROM_CPU; that is not enough >>>> ?? for the new target, which only differs by the ending of the >>>> ?? triplet. However the $host macro should be available anywhere. >>>> >>>> ?- the hotspot part just handles the new "cpu" >>>> >>>> ?- GensrcX11Wrappers.gmk assumes that there is a black/white >>>> ?? decision about -m32/-m64. The patch works around it. However >>>> ?? the real patch should be to get these flags from the build >>>> ?? system, and not hardcode itself. >>>> >>>> ?- the sysctl system call is unsupported in the x32 kernel, and >>>> ?? just the include leads to a build error.? From my point of view >>>> ?? the header is not needed. I had successful builds on all other >>>> ?? targets without including it. If you want to keep the include, >>>> ?? then it should be guarded with >>>> ?? #if !(defined(_ILP32) && defined(__x86_64__)) >>>> >>>> Matthias >>> >>> I've filed this bug for this: >>> https://bugs.openjdk.java.net/browse/JDK-8165440 >> >> Please note that as a P4 issue this can not be fixed given we have hit RDP1: >> >> http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-August/004777.html >> >> Further this is filed as "bug" but seems to clearly be an enhancement, so you would need approval for it to come in post-Feature-Complete. >> >> Please consider if this is something that must be fixed for 9 or can be deferred. Otherwise you will need to follow additional approval processes. >> >> Sorry. >> >> David (just the messenger!) >> >>> Unfortunately, I have no way of testing it. >>> >>> Cheers, >>> Severin >>> -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From magnus.ihse.bursie at oracle.com Fri Aug 31 11:40:24 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 31 Aug 2018 13:40:24 +0200 Subject: [patch] add zero support for x86_64-linux-gnux32 target In-Reply-To: References: <44e0be8d-f78b-0143-ebf7-d23937becdfd@ubuntu.com> <1473077772.2884.11.camel@redhat.com> <490d3972-937f-893a-dd97-ae8759493e59@oracle.com> <387a38af-d5b0-432e-d3ab-185a31b58395@oracle.com> Message-ID: Yes, that looks reasonable! If you want to, you can push this + Klose's fix. /Magnus > 31 aug. 2018 kl. 13:25 skrev John Paul Adrian Glaubitz : > > Hi Magnus! > > I just tested it and the following change in make/autoconf/flags.m4 is > necessary as well so that gcc is not called with "-m64": > > diff -r 18afb2097ada -r 1f28530b1f46 make/autoconf/flags.m4 > --- a/make/autoconf/flags.m4 Fri Aug 31 11:43:06 2018 +0200 > +++ b/make/autoconf/flags.m4 Fri Aug 31 12:50:02 2018 +0200 > @@ -241,7 +241,8 @@ > elif test "x$TOOLCHAIN_TYPE" = xsolstudio; then > MACHINE_FLAG="-m${OPENJDK_TARGET_CPU_BITS}" > elif test "x$TOOLCHAIN_TYPE" = xgcc || test "x$TOOLCHAIN_TYPE" = xclang; then > - if test "x$OPENJDK_TARGET_CPU_ARCH" = xx86 || > + if test "x$OPENJDK_TARGET_CPU_ARCH" = xx86 && > + test "x$OPENJDK_TARGET_CPU" != xx32 || > test "x$OPENJDK_TARGET_CPU_ARCH" = xsparc || > test "x$OPENJDK_TARGET_CPU_ARCH" = xppc; then > MACHINE_FLAG="-m${OPENJDK_TARGET_CPU_BITS}" > > Adrian > >> On 08/31/2018 10:43 AM, Magnus Ihse Bursie wrote: >> The necroposter strikes back! :-) >> >> I'm currently trying to fix or close all long standing bugs on infrastructure/build, and now the time has come to JDK-8165440. >> >> This patch had a bit of bad timing when it was posted, since it could not be accepted into mainline due to feature freeze, and there were no other repo to accept it. >> >> I adjusted the patch to the current code base (which means that most parts of it were not needed). What remains are two files. However, I can't test if this works. Matthias, can you verify that this is a working patch for jdk/jdk for the gnux32 target? If so, I'll sponsor this patch. >> >> diff --git a/make/autoconf/platform.m4 b/make/autoconf/platform.m4 >> --- a/make/autoconf/platform.m4 >> +++ b/make/autoconf/platform.m4 >> @@ -35,6 +35,10 @@ >> VAR_CPU_ARCH=x86 >> VAR_CPU_BITS=64 >> VAR_CPU_ENDIAN=little >> + case "$host" in *x32) >> + VAR_CPU=x32 >> + VAR_CPU_BITS=32 >> + esac >> ;; >> i?86) >> VAR_CPU=x86 >> @@ -455,6 +459,8 @@ >> HOTSPOT_$1_CPU_DEFINE=IA32 >> elif test "x$OPENJDK_$1_CPU" = xx86_64; then >> HOTSPOT_$1_CPU_DEFINE=AMD64 >> + elif test "x$OPENJDK_$1_CPU" = xx32; then >> + HOTSPOT_$1_CPU_DEFINE=X32 >> elif test "x$OPENJDK_$1_CPU" = xsparcv9; then >> HOTSPOT_$1_CPU_DEFINE=SPARC >> elif test "x$OPENJDK_$1_CPU" = xaarch64; then >> diff --git a/src/hotspot/os/linux/os_linux.cpp b/src/hotspot/os/linux/os_linux.cpp >> --- a/src/hotspot/os/linux/os_linux.cpp >> +++ b/src/hotspot/os/linux/os_linux.cpp >> @@ -1742,7 +1742,7 @@ >> >> #if (defined IA32) >> static Elf32_Half running_arch_code=EM_386; >> -#elif (defined AMD64) >> +#elif (defined AMD64) || defined(X32) >> static Elf32_Half running_arch_code=EM_X86_64; >> #elif (defined IA64) >> static Elf32_Half running_arch_code=EM_IA_64; >> >> /Magnus >> >>> On 2016-09-06 01:01, David Holmes wrote: >>> Hi Severin, Matthias, >>> >>>> On 5/09/2016 10:16 PM, Severin Gehwolf wrote: >>>>> On Mon, 2016-09-05 at 14:03 +0200, Matthias Klose wrote: >>>>> The attached patch adds support for building zero for the x86_64- >>>>> linux-gnux32 >>>>> target, having changes in the build system, hotspot and jdk. >>>>> >>>>> - the build system currently only derives the target from >>>>> the cpu in PLATFORM_EXTRACT_VARS_FROM_CPU; that is not enough >>>>> for the new target, which only differs by the ending of the >>>>> triplet. However the $host macro should be available anywhere. >>>>> >>>>> - the hotspot part just handles the new "cpu" >>>>> >>>>> - GensrcX11Wrappers.gmk assumes that there is a black/white >>>>> decision about -m32/-m64. The patch works around it. However >>>>> the real patch should be to get these flags from the build >>>>> system, and not hardcode itself. >>>>> >>>>> - the sysctl system call is unsupported in the x32 kernel, and >>>>> just the include leads to a build error. From my point of view >>>>> the header is not needed. I had successful builds on all other >>>>> targets without including it. If you want to keep the include, >>>>> then it should be guarded with >>>>> #if !(defined(_ILP32) && defined(__x86_64__)) >>>>> >>>>> Matthias >>>> >>>> I've filed this bug for this: >>>> https://bugs.openjdk.java.net/browse/JDK-8165440 >>> >>> Please note that as a P4 issue this can not be fixed given we have hit RDP1: >>> >>> http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-August/004777.html >>> >>> Further this is filed as "bug" but seems to clearly be an enhancement, so you would need approval for it to come in post-Feature-Complete. >>> >>> Please consider if this is something that must be fixed for 9 or can be deferred. Otherwise you will need to follow additional approval processes. >>> >>> Sorry. >>> >>> David (just the messenger!) >>> >>>> Unfortunately, I have no way of testing it. >>>> >>>> Cheers, >>>> Severin >>>> > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaubitz at debian.org > `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From glaubitz at physik.fu-berlin.de Fri Aug 31 11:42:24 2018 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Fri, 31 Aug 2018 13:42:24 +0200 Subject: [patch] add zero support for x86_64-linux-gnux32 target In-Reply-To: References: <44e0be8d-f78b-0143-ebf7-d23937becdfd@ubuntu.com> <1473077772.2884.11.camel@redhat.com> <490d3972-937f-893a-dd97-ae8759493e59@oracle.com> <387a38af-d5b0-432e-d3ab-185a31b58395@oracle.com> Message-ID: On 08/31/2018 01:40 PM, Magnus Ihse Bursie wrote: > Yes, that looks reasonable! If you want to, you can push this + Klose's fix. Is there a bug in the JBS I can reference? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From rwestrel at redhat.com Fri Aug 31 12:48:25 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 31 Aug 2018 14:48:25 +0200 Subject: RFR: 8210236: Prepare ciReceiverTypeData::translate_receiver_data_from for concurrent class unloading In-Reply-To: References: Message-ID: > http://cr.openjdk.java.net/~eosterlund/8210236/webrev.00 That looks reasonable to me. Roland. From erik.osterlund at oracle.com Fri Aug 31 12:57:54 2018 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Fri, 31 Aug 2018 14:57:54 +0200 Subject: RFR: 8210236: Prepare ciReceiverTypeData::translate_receiver_data_from for concurrent class unloading In-Reply-To: References: Message-ID: Hi Roland, Thank you for the review. /Erik > On 31 Aug 2018, at 14:48, Roland Westrelin wrote: > > >> http://cr.openjdk.java.net/~eosterlund/8210236/webrev.00 > > That looks reasonable to me. > > Roland. From coleen.phillimore at oracle.com Fri Aug 31 13:12:27 2018 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 31 Aug 2018 09:12:27 -0400 Subject: RFR: 8210236: Prepare ciReceiverTypeData::translate_receiver_data_from for concurrent class unloading In-Reply-To: References: Message-ID: <37614f02-94d7-b576-5b2b-c50dd4e54e35@oracle.com> This looks good. Coleen On 8/30/18 3:08 PM, Erik ?sterlund wrote: > Hi, > > When concurrently unloading classes, it is possible for MDOs to have > stale metadata entries in them until the GC comes around to clean it > up. That is fine, but there is one place where extra care needs to be > taken: when the compiler interface fetches ReceiverTypeData. This is > done by memcpy:ing the ReceiverTypeData to a new memory buffer, and > walking the metadata, patching it with corresponding ci metadata > classes in the new buffer. The metadata could be stale by now. In such > scenarios, the rows should be lazily cleaned. Once the ci metadata > handles are created, they are safe to use in the rest of the code. > > This patch builds on 8210233 which makes Klass::is_loader_alive() > concurrency friendly using phantom loads. > > Webrev: > http://cr.openjdk.java.net/~eosterlund/8210236/webrev.00 > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8210236 > > Thanks, > /Erik From daniel.daugherty at oracle.com Fri Aug 31 14:19:46 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 31 Aug 2018 10:19:46 -0400 Subject: RFR: 8210131: vmTestbase/nsk/jvmti/scenarios/allocation/AP10/ap10t001/TestDescription.java failed with ObjectFree: GetCurrentThreadCpuTimerInfo returned unexpected error code In-Reply-To: <39905239-72B3-46A9-B31E-3B01FA5B9BAB@oracle.com> References: <39905239-72B3-46A9-B31E-3B01FA5B9BAB@oracle.com> Message-ID: <32b45126-1a31-1c60-e958-461fa1a6b6c3@oracle.com> On 8/30/18 10:15 PM, Kim Barrett wrote: > Please review this small change to GetCurrentThreadCpuTimerInfo and > GetCurrentThreadCpuTime JVMTI operations, allowing them to be called > from any NamedThread. This is consistent with the behavior from > JDK-8203948; there is no obvious reason for these operations to have > any thread context restriction. > > These functions are documented as being callable from heap callbacks > like ObjectFree, which can be called from an "internal thread or the > thread that called the [heap] iteration function". However, unlike > other, similar functions, these two were requiring the current thread > to be either a JavaThread or the VMThread. For other such functions, > JDK-6278106 had added Concurrent GC threads, and JDK-8203948 > generalized that to any NamedThread (or JavaThread). This change > makes these functions behave similarly. > > This is needed to allow such callbacks to be invoked from a GC worker > thread, such as is now done for G1 (JDK-8072498), and probably other > collectors in the future. (See comments for JDK-8203948 for a > discussion of why ZGC didn't run into this problem.) > > This change also removes the failing test from the problem list. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8210131 > > Webrev: > http://cr.openjdk.java.net/~kbarrett/8210131/open.00/ src/hotspot/share/prims/jvmtiEnter.xsl ??? No comments. test/hotspot/jtreg/ProblemList.txt ??? No comments. I verified that the XSL changes will only affect the two functions in question: jvmti_GetCurrentThreadCpuTimerInfo() and jvmti_GetCurrentThreadCpuTime(). Unfortunately, I can't remember why that bit of XSL code only applies to those two functions. In any case, thumbs up! Dan > > Testing: > mach5 tier1-3, hs-tier4-6. > Local (linux-x64) jtreg:hotspot_gc, and manually ran the failing test. > Examined the generated jvmtiEnter[Trace].cpp file and verified the > change to the generated code was as expected. > From sgehwolf at redhat.com Fri Aug 31 14:46:40 2018 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 31 Aug 2018 16:46:40 +0200 Subject: [patch] add zero support for x86_64-linux-gnux32 target In-Reply-To: References: <44e0be8d-f78b-0143-ebf7-d23937becdfd@ubuntu.com> <1473077772.2884.11.camel@redhat.com> <490d3972-937f-893a-dd97-ae8759493e59@oracle.com> <387a38af-d5b0-432e-d3ab-185a31b58395@oracle.com> Message-ID: <4fb19d68720371dbb8a84360c2fa6df52bc8955f.camel@redhat.com> On Fri, 2018-08-31 at 13:42 +0200, John Paul Adrian Glaubitz wrote: > On 08/31/2018 01:40 PM, Magnus Ihse Bursie wrote: > > Yes, that looks reasonable! If you want to, you can push this + Klose's fix. > > Is there a bug in the JBS I can reference? https://bugs.openjdk.java.net/browse/JDK-8165440 Thanks, Severin From kim.barrett at oracle.com Fri Aug 31 17:50:38 2018 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 31 Aug 2018 13:50:38 -0400 Subject: RFR: 8210131: vmTestbase/nsk/jvmti/scenarios/allocation/AP10/ap10t001/TestDescription.java failed with ObjectFree: GetCurrentThreadCpuTimerInfo returned unexpected error code In-Reply-To: <32b45126-1a31-1c60-e958-461fa1a6b6c3@oracle.com> References: <39905239-72B3-46A9-B31E-3B01FA5B9BAB@oracle.com> <32b45126-1a31-1c60-e958-461fa1a6b6c3@oracle.com> Message-ID: > On Aug 31, 2018, at 10:19 AM, Daniel D. Daugherty wrote: > > On 8/30/18 10:15 PM, Kim Barrett wrote: >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8210131 >> >> Webrev: >> http://cr.openjdk.java.net/~kbarrett/8210131/open.00/ > > src/hotspot/share/prims/jvmtiEnter.xsl > No comments. > > test/hotspot/jtreg/ProblemList.txt > No comments. > > > I verified that the XSL changes will only affect the two functions > in question: jvmti_GetCurrentThreadCpuTimerInfo() and > jvmti_GetCurrentThreadCpuTime(). Unfortunately, I can't remember > why that bit of XSL code only applies to those two functions. Yeah, the language and code generation here are all pretty opaque to me. Fortunately, I haven?t needed to do anything significant to this code. > In any case, thumbs up! Thanks. > Dan > > >> >> Testing: >> mach5 tier1-3, hs-tier4-6. >> Local (linux-x64) jtreg:hotspot_gc, and manually ran the failing test. >> Examined the generated jvmtiEnter[Trace].cpp file and verified the >> change to the generated code was as expected. From george at georgeluiz.com Fri Aug 31 20:32:58 2018 From: george at georgeluiz.com (George Luiz Bittencourt) Date: Fri, 31 Aug 2018 17:32:58 -0300 Subject: Hello In-Reply-To: <5B6C6568.8030303@oracle.com> References: <5B6C6568.8030303@oracle.com> Message-ID: Hello, What resources (books, articles, etc) do you recomend me to read to fully understand the JVM? I have already read the JVM spec and bought the garbage collection book. Thanks. -George On Thu, Aug 9, 2018 at 1:01 PM, Erik Gahlin wrote: > Hi, > > I use Visual Studio for editing and debugging, others use WinDbg. I build > the Visual Studio project with make hotspot-ide-project > > For Java code, I use Eclipse. I typically only change code in a few > modules and I have preconfigured Eclipse projects for them (with project > relative links). I build Java code manually. A few years back, I tried to > build inside Eclipse using ANT-scripts, but it was a pain to maintain. > > Erik > > Hello! >> >> I am new to OpenJDK and I would like to help the project. >> I have already built it on Windows. >> >> My question is: what tools do you use to develop and debug OpenJDK on >> Windows? >> Are you guys using Visual Studio to edit and using its debugging >> capabilites? >> >> Or are you using a simple editor, like VS Code, building it manually and >> debugging using WinDBG? >> >> Thanks. >> >> > -- -George From vladimir.kozlov at oracle.com Fri Aug 31 22:38:23 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 31 Aug 2018 15:38:23 -0700 Subject: RFR(S): 8210152: Optimize integer divisible by power-of-2 check In-Reply-To: References: Message-ID: <9c62516d-234c-83c7-97ec-3b339c781449@oracle.com> Hi Pengfei, I don't see where negation is coming from for 'X % 2 == 0' expression. It should be only 2 instructions: 'cmp (X and 1), 0' I will look on it next week. But it would be nice if you can provide small test to show this issue. Thanks, Vladimir On 8/29/18 3:21 AM, Pengfei Li wrote: > Hi, > > Please help review this C2 compiler patch that optimize the integer divisible by 2^n (power-of-2) check. > > In original integer divisible by 2^n check, C2 compiler generates conditional negation instructions before the zero check. But actually the conditional negation is redundant since the negation of a zero (non-zero) is also a zero (non-zero). This patch adds an ideal transformation that change the IR pattern "bool eq/ne (cmp (phi (X -X) 0))" into "bool eq/ne (cmp X 0)". With this optimization, the divisible by 2^n check can be done with only 1 or 2 machine instructions. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8210152 > webrev: http://cr.openjdk.java.net/~zyao/8210152/webrev.00/ > > I've run jtreg full tests with this patch on an x86_64 and an aarch64 server respectively. No new failures were found. > > -- > Thanks, > Pengfei > From dean.long at oracle.com Fri Aug 31 23:44:35 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 31 Aug 2018 16:44:35 -0700 Subject: RFR(S): 8210152: Optimize integer divisible by power-of-2 check In-Reply-To: References: Message-ID: <97407ba1-7aec-0893-b540-7e1472ce9529@oracle.com> Hi Pengfei.? It looks like your matching may allow more patterns than expected.? I was expecting it to look for < 0 or >= 0 for the conditional negation, but I don't see it.? The code in is_absolute() seems to be doing something similar to yours, but takes into account the kind of compare being done. dl On 8/29/18 3:21 AM, Pengfei Li wrote: > Hi, > > Please help review this C2 compiler patch that optimize the integer divisible by 2^n (power-of-2) check. > > In original integer divisible by 2^n check, C2 compiler generates conditional negation instructions before the zero check. But actually the conditional negation is redundant since the negation of a zero (non-zero) is also a zero (non-zero). This patch adds an ideal transformation that change the IR pattern "bool eq/ne (cmp (phi (X -X) 0))" into "bool eq/ne (cmp X 0)". With this optimization, the divisible by 2^n check can be done with only 1 or 2 machine instructions. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8210152 > webrev: http://cr.openjdk.java.net/~zyao/8210152/webrev.00/ > > I've run jtreg full tests with this patch on an x86_64 and an aarch64 server respectively. No new failures were found. > > -- > Thanks, > Pengfei >