From matthias.baesken at sap.com Thu Aug 1 07:13:08 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 1 Aug 2019 07:13:08 +0000 Subject: RFR: [XS] 8228658: test GetTotalSafepointTime.java fails on fast Linux machines with Total safepoint time 0 ms In-Reply-To: <9868e92d-398b-be7c-5d45-020c19a61052@oracle.com> References: <82938477-ce6d-fdeb-02ab-60809541d9e4@oracle.com> <1e303f06-3933-ba73-f34b-081b827a725d@oracle.com> <470c58c5-c364-aca0-62fe-ef469c5cb390@oracle.com> <9868e92d-398b-be7c-5d45-020c19a61052@oracle.com> Message-ID: Hi David + JC , thanks for the reviews . David - I added the suggested print-outputs , and also the parameter to executeThreadDumps . Best regards, Matthias > -----Original Message----- > From: David Holmes > Sent: Mittwoch, 31. Juli 2019 23:57 > To: Baesken, Matthias ; Jean Christophe > Beyler > Cc: hotspot-dev at openjdk.java.net; serviceability-dev dev at openjdk.java.net> > Subject: Re: RFR: [XS] 8228658: test GetTotalSafepointTime.java fails on fast > Linux machines with Total safepoint time 0 ms > > On 1/08/2019 12:01 am, Baesken, Matthias wrote: > > > > Hi upload works again, now with webrev : > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8228658.2/ > > Could you please add, for diagnostic purposes: > > System.out.println("Total safepoint time (ms): " + value); > > after: > > 60 long value = executeThreadDumps(); > > and > > 68 long value2 = executeThreadDumps(); > > that way if the test fails we can check logs to see what kind of > safepoint times have been observed previously. No need to see an updated > webrev just for that. > > I have one further suggestion, take it or leave it, that > executeThreadDumps() takes a parameter to specify the initial value, so > we'd have: > > 60 long value = executeThreadDumps(0); > > and > > 68 long value2 = executeThreadDumps(value); > > This might help detect getTotalSafepointTime() going backwards slightly > better than current code. > > Thanks, > David > > > Best regards, Matthias > > > > > >> -----Original Message----- > >> From: Baesken, Matthias > >> Sent: Mittwoch, 31. Juli 2019 14:05 > >> To: 'David Holmes' ; Jean Christophe Beyler > >> > >> Cc: hotspot-dev at openjdk.java.net; serviceability-dev >> dev at openjdk.java.net> > >> Subject: RE: RFR: [XS] 8228658: test GetTotalSafepointTime.java fails on > fast > >> Linux machines with Total safepoint time 0 ms > >> > >> Hello, here is a version following the latest proposal of JC . > >> > >> Unfortunately attached as patch, sorry for that - the uploads / pushes > >> currently do not work from here . > >> > >> Best regards, Matthias > >> > >> > >>> -----Original Message----- > >>> From: David Holmes > >>> Sent: Mittwoch, 31. Juli 2019 05:04 > >>> To: Jean Christophe Beyler > >>> Cc: Baesken, Matthias ; hotspot- > >>> dev at openjdk.java.net; serviceability-dev >>> dev at openjdk.java.net> > >>> Subject: Re: RFR: [XS] 8228658: test GetTotalSafepointTime.java fails on > >> fast > >>> Linux machines with Total safepoint time 0 ms > >>> > >>> On 31/07/2019 9:08 am, Jean Christophe Beyler wrote: > >>>> FWIW, I would have done something like what David was suggesting, > just > >>>> slightly tweaked: > >>>> > >>>> public static long executeThreadDumps() { > >>>> ?long value; > >>>> ?long initial_value = mbean.getTotalSafepointTime(); > >>>> ?do { > >>>> ? ? ?Thread.getAllStackTraces(); > >>>> ? ? ?value = mbean.getTotalSafepointTime(); > >>>> ?} while (value == initial_value); > >>>> ?return value; > >>>> } > >>>> > >>>> This ensures that the value is a new value as opposed to the current > >>>> value and if something goes wrong, as David said, it will timeout; which > >>>> is ok. > >>> > >>> Works for me. > >>> > >>>> But I come back to not really understanding why we are doing this at > >>>> this point of relaxing (just get a new value of safepoint time). > >>>> Because, if we accept timeouts now as a failure here, then really the > >>>> whole test becomes: > >>>> > >>>> executeThreadDumps(); > >>>> executeThreadDumps(); > >>>> > >>>> Since?the first call will return when value > 0 and the second call will > >>>> return when value2 > value (I still wonder why we want to ensure it > >>>> works twice...). > >>> > >>> The test is trying to sanity check that we are actually recording the > >>> time used by safepoints. So first check is that we can get a non-zero > >>> value; second check is we get a greater non-zero value. It's just a > >>> sanity test to try and catch if something gets unexpectedly broken in > >>> the time tracking code. > >>> > >>>> So both failures and even testing for it is kind of redundant, once you > >>>> have a do/while until a change? > >>> > >>> Yes - the problem with the tests that try to check internal VM behaviour > >>> is that we have no specified way to do something, in this case execute > >>> safepoints, that relates to internal VM behaviour, so we have to do > >>> something we know will currently work even if not specified to do so - > >>> e.g. dumping all thread stacks uses a global safepoint. The second > >>> problem is that the timer granularity is so coarse that we then have to > >>> guess how many times we need to do that something before seeing a > >>> change. To make the test robust we can keep doing stuff until we see a > >>> change and so the only way that will fail is if the overall timeout of > >>> the test kicks in. Or we can try and second guess how long it should > >>> take by introducing our own internal timeout - either directly or by > >>> limiting the number of loops in this case. That has its own problems and > >>> in general we have tried to reduce internal test timeouts (by removing > >>> them) and let overall timeouts take charge. > >>> > >>> No ideal solution. And this has already consumed way too much of > >>> everyone's time. > >>> > >>> Cheers, > >>> David > >>> > >>>> Thanks, > >>>> Jc > >>>> > >>>> > >>>> On Tue, Jul 30, 2019 at 2:35 PM David Holmes > >>>> > wrote: > >>>> > >>>> On 30/07/2019 10:39 pm, Baesken, Matthias wrote: > >>>> > Hi David,? ?"put that whole code (the while loop) in a helper > >>>> method."? ?was JC's idea,? and I like the idea . > >>>> > >>>> Regardless I think the way you are using NUM_THREAD_DUMPS is > >> really > >>>> confusing. As an all-caps static you'd expect it to be a constant. > >>>> > >>>> Thanks, > >>>> David > >>>> > >>>> > Let's see what others think . > >>>> > > >>>> >> > >>>> >> Overall tests like this are not very useful, yet very fragile. > >>>> >> > >>>> > > >>>> > I am also? fine with putting the test on the exclude list. > >>>> > > >>>> > Best regards, Matthias > >>>> > > >>>> > > >>>> >> -----Original Message----- > >>>> >> From: David Holmes >>>> > > >>>> >> Sent: Dienstag, 30. Juli 2019 14:12 > >>>> >> To: Baesken, Matthias >>>> >; Jean Christophe > >>>> >> Beyler > > >>>> >> Cc: hotspot-dev at openjdk.java.net > >>>> ; serviceability-dev > >>>> >>>> >> dev at openjdk.java.net > > >>>> >> Subject: Re: RFR: [XS] 8228658: test GetTotalSafepointTime.java > >>>> fails on fast > >>>> >> Linux machines with Total safepoint time 0 ms > >>>> >> > >>>> >> Hi Matthias, > >>>> >> > >>>> >> On 30/07/2019 9:25 pm, Baesken, Matthias wrote: > >>>> >>> Hello? JC / David,?? here is a second webrev? : > >>>> >>> > >>>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8228658.1/ > >>>> >>> > >>>> >>> It moves?? the? thread dump execution into a? method > >>>> >>> executeThreadDumps(long)?? ??, and also adds? while loops > >>>> (but with a > >>>> >>> limitation? for the number of thread dumps, really don?t > >>>> >>> want to cause timeouts etc.).??? I removed a check for > >>>> >>> MAX_VALUE_FOR_PASS?? because we cannot go over > >>> Long.MAX_VALUE . > >>>> >> > >>>> >> I don't think executeThreadDumps is worth factoring out like out. > >>>> >> > >>>> >> The handling of NUM_THREAD_DUMPS is a bit confusing. I'd > rather > >> it > >>>> >> remains a constant 100, and then you set a simple loop iteration > >>>> count > >>>> >> limit. Further with the proposed code when you get here: > >>>> >> > >>>> >>? ? 85? ? ? ? ?NUM_THREAD_DUMPS = NUM_THREAD_DUMPS * 2; > >>>> >> > >>>> >> you don't even know what value you may be starting with. > >>>> >> > >>>> >> But I was thinking of simply: > >>>> >> > >>>> >> long value = 0; > >>>> >> do { > >>>> >>? ? ? ?Thread.getAllStackTraces(); > >>>> >>? ? ? ?value = mbean.getTotalSafepointTime(); > >>>> >> } while (value == 0); > >>>> >> > >>>> >> We'd only hit a timeout if something is completely broken - > >>>> which is fine. > >>>> >> > >>>> >> Overall tests like this are not very useful, yet very fragile. > >>>> >> > >>>> >> Thanks, > >>>> >> David > >>>> >> > >>>> >>> Hope you like this version ?better. > >>>> >>> > >>>> >>> Best regards, Matthias > >>>> >>> > >>>> >>> *From:*Jean Christophe Beyler >>>> > > >>>> >>> *Sent:* Dienstag, 30. Juli 2019 05:39 > >>>> >>> *To:* David Holmes >>>> > > >>>> >>> *Cc:* Baesken, Matthias >>>> >; > >>>> >>> hotspot-dev at openjdk.java.net > >>>> ; serviceability-dev > >>>> >>> >>>> > > >>>> >>> *Subject:* Re: RFR: [XS] 8228658: test > >>>> GetTotalSafepointTime.java fails > >>>> >>> on fast Linux machines with Total safepoint time 0 ms > >>>> >>> > >>>> >>> Hi Matthias, > >>>> >>> > >>>> >>> I wonder if you should not do what David is suggesting and then > >>>> put that > >>>> >>> whole code (the while loop) in a helper method. Below you > have a > >>>> >>> calculation again using value2 (which I wonder what the added > >>>> value of > >>>> >>> it is though) but anyway, that value2 could also be 0 at some > >>>> point, no? > >>>> >>> > >>>> >>> So would it not be best to just refactor the getAllStackTraces > and > >>>> >>> calculate safepoint time in a helper method for both value / > value2 > >>>> >>> variables? > >>>> >>> > >>>> >>> Thanks, > >>>> >>> > >>>> >>> Jc > >>>> >>> > >>>> >>> On Mon, Jul 29, 2019 at 7:50 PM David Holmes > >>>> > >>>> >>> >>>> >> wrote: > >>>> >>> > >>>> >>>? ? ? Hi Matthias, > >>>> >>> > >>>> >>>? ? ? On 29/07/2019 8:20 pm, Baesken, Matthias wrote: > >>>> >>>? ? ? ?> Hello , please review this small test fix . > >>>> >>>? ? ? ?> > >>>> >>>? ? ? ?> The test > >>>> >>> > >>>> >> > >>> > >> > test/jdk/sun/management/HotspotRuntimeMBean/GetTotalSafepointTime. > >>>> >> java > >>>> >>>? ? ? fails sometimes on fast Linux machines with this error > >>>> message : > >>>> >>>? ? ? ?> > >>>> >>>? ? ? ?> java.lang.RuntimeException: Total safepoint time > >>>> illegal value: 0 > >>>> >>>? ? ? ms (MIN = 1; MAX = 9223372036854775807) > >>>> >>>? ? ? ?> > >>>> >>>? ? ? ?> looks like the total safepoint time is too low > >>>> currently on these > >>>> >>>? ? ? machines, it is < 1 ms. > >>>> >>>? ? ? ?> > >>>> >>>? ? ? ?> There might be several ways to handle this : > >>>> >>>? ? ? ?> > >>>> >>>? ? ? ?>? ? *? ?Change the test? in a way that it might generate > >>>> nigher > >>>> >>>? ? ? safepoint times > >>>> >>>? ? ? ?>? ? *? ?Allow? safepoint time? == 0 ms > >>>> >>>? ? ? ?>? ? *? ?Offer an additional interface that gives > >>>> safepoint times > >>>> >>>? ? ? with finer granularity ( currently the HS has safepoint > >>>> time values > >>>> >>>? ? ? in ns , see? jdk/src/hotspot/share/runtime/safepoint.cpp > >>>> >>>? ? ? ??SafepointTracing::end > >>>> >>>? ? ? ?> > >>>> >>>? ? ? ?> But it is converted on ms in this code > >>>> >>>? ? ? ?> > >>>> >>>? ? ? ?> 114jlong RuntimeService::safepoint_time_ms() { > >>>> >>>? ? ? ?> 115? return UsePerfData ? > >>>> >>>? ? ? ?> 116 > >>>> >>> > >>>> Management::ticks_to_ms(_safepoint_time_ticks->get_value()) : - > 1; > >>>> >>>? ? ? ?> 117} > >>>> >>>? ? ? ?> > >>>> >>>? ? ? ?> 064jlong Management::ticks_to_ms(jlong ticks) { > >>>> >>>? ? ? ?> 2065? assert(os::elapsed_frequency() > 0, "Must be > >>>> non-zero"); > >>>> >>>? ? ? ?> 2066? return (jlong)(((double)ticks / > >>>> >>>? ? ? (double)os::elapsed_frequency()) > >>>> >>>? ? ? ?> 2067? ? ? ? ? ? ? ? ?* (double)1000.0); > >>>> >>>? ? ? ?> 2068} > >>>> >>>? ? ? ?> > >>>> >>>? ? ? ?> > >>>> >>>? ? ? ?> > >>>> >>>? ? ? ?> Currently I go for? the first attempt (and try to generate > >>>> >>>? ? ? higher safepoint times in my patch) . > >>>> >>> > >>>> >>>? ? ? Yes that's probably best. Coarse-grained timing on very > >>>> fast machines > >>>> >>>? ? ? was bound to eventually lead to problems. > >>>> >>> > >>>> >>>? ? ? But perhaps a more future-proof approach is to just add a > >>>> do-while loop > >>>> >>>? ? ? around the stack dumps and only exit when we have a non- > zero > >>>> >> safepoint > >>>> >>>? ? ? time? > >>>> >>> > >>>> >>>? ? ? Thanks, > >>>> >>>? ? ? David > >>>> >>>? ? ? ----- > >>>> >>> > >>>> >>>? ? ? ?> Bug/webrev : > >>>> >>>? ? ? ?> > >>>> >>>? ? ? ?> https://bugs.openjdk.java.net/browse/JDK-8228658 > >>>> >>>? ? ? ?> > >>>> >>>? ? ? ?> > http://cr.openjdk.java.net/~mbaesken/webrevs/8228658.0/ > >>>> >>>? ? ? ?> > >>>> >>>? ? ? ?> > >>>> >>>? ? ? ?> Thanks, Matthias > >>>> >>>? ? ? ?> > >>>> >>> > >>>> >>> > >>>> >>> -- > >>>> >>> > >>>> >>> Thanks, > >>>> >>> > >>>> >>> Jc > >>>> >>> > >>>> > >>>> > >>>> > >>>> -- > >>>> > >>>> Thanks, > >>>> Jc From david.holmes at oracle.com Thu Aug 1 07:56:21 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 1 Aug 2019 17:56:21 +1000 Subject: RFR: [XS] 8228658: test GetTotalSafepointTime.java fails on fast Linux machines with Total safepoint time 0 ms In-Reply-To: References: <82938477-ce6d-fdeb-02ab-60809541d9e4@oracle.com> <1e303f06-3933-ba73-f34b-081b827a725d@oracle.com> <470c58c5-c364-aca0-62fe-ef469c5cb390@oracle.com> <9868e92d-398b-be7c-5d45-020c19a61052@oracle.com> Message-ID: <852abeab-7c91-69d3-53d6-57da71c8ccf6@oracle.com> On 1/08/2019 5:13 pm, Baesken, Matthias wrote: > Hi David + JC , thanks for the reviews . > > David - I added the suggested print-outputs , and also the parameter to executeThreadDumps . Okay - thanks for that. David ----- > Best regards, Matthias > > > >> -----Original Message----- >> From: David Holmes >> Sent: Mittwoch, 31. Juli 2019 23:57 >> To: Baesken, Matthias ; Jean Christophe >> Beyler >> Cc: hotspot-dev at openjdk.java.net; serviceability-dev > dev at openjdk.java.net> >> Subject: Re: RFR: [XS] 8228658: test GetTotalSafepointTime.java fails on fast >> Linux machines with Total safepoint time 0 ms >> >> On 1/08/2019 12:01 am, Baesken, Matthias wrote: >>> >>> Hi upload works again, now with webrev : >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8228658.2/ >> >> Could you please add, for diagnostic purposes: >> >> System.out.println("Total safepoint time (ms): " + value); >> >> after: >> >> 60 long value = executeThreadDumps(); >> >> and >> >> 68 long value2 = executeThreadDumps(); >> >> that way if the test fails we can check logs to see what kind of >> safepoint times have been observed previously. No need to see an updated >> webrev just for that. >> >> I have one further suggestion, take it or leave it, that >> executeThreadDumps() takes a parameter to specify the initial value, so >> we'd have: >> >> 60 long value = executeThreadDumps(0); >> >> and >> >> 68 long value2 = executeThreadDumps(value); >> >> This might help detect getTotalSafepointTime() going backwards slightly >> better than current code. >> >> Thanks, >> David >> >>> Best regards, Matthias >>> >>> >>>> -----Original Message----- >>>> From: Baesken, Matthias >>>> Sent: Mittwoch, 31. Juli 2019 14:05 >>>> To: 'David Holmes' ; Jean Christophe Beyler >>>> >>>> Cc: hotspot-dev at openjdk.java.net; serviceability-dev >>> dev at openjdk.java.net> >>>> Subject: RE: RFR: [XS] 8228658: test GetTotalSafepointTime.java fails on >> fast >>>> Linux machines with Total safepoint time 0 ms >>>> >>>> Hello, here is a version following the latest proposal of JC . >>>> >>>> Unfortunately attached as patch, sorry for that - the uploads / pushes >>>> currently do not work from here . >>>> >>>> Best regards, Matthias >>>> >>>> >>>>> -----Original Message----- >>>>> From: David Holmes >>>>> Sent: Mittwoch, 31. Juli 2019 05:04 >>>>> To: Jean Christophe Beyler >>>>> Cc: Baesken, Matthias ; hotspot- >>>>> dev at openjdk.java.net; serviceability-dev >>>> dev at openjdk.java.net> >>>>> Subject: Re: RFR: [XS] 8228658: test GetTotalSafepointTime.java fails on >>>> fast >>>>> Linux machines with Total safepoint time 0 ms >>>>> >>>>> On 31/07/2019 9:08 am, Jean Christophe Beyler wrote: >>>>>> FWIW, I would have done something like what David was suggesting, >> just >>>>>> slightly tweaked: >>>>>> >>>>>> public static long executeThreadDumps() { >>>>>> ?long value; >>>>>> ?long initial_value = mbean.getTotalSafepointTime(); >>>>>> ?do { >>>>>> ? ? ?Thread.getAllStackTraces(); >>>>>> ? ? ?value = mbean.getTotalSafepointTime(); >>>>>> ?} while (value == initial_value); >>>>>> ?return value; >>>>>> } >>>>>> >>>>>> This ensures that the value is a new value as opposed to the current >>>>>> value and if something goes wrong, as David said, it will timeout; which >>>>>> is ok. >>>>> >>>>> Works for me. >>>>> >>>>>> But I come back to not really understanding why we are doing this at >>>>>> this point of relaxing (just get a new value of safepoint time). >>>>>> Because, if we accept timeouts now as a failure here, then really the >>>>>> whole test becomes: >>>>>> >>>>>> executeThreadDumps(); >>>>>> executeThreadDumps(); >>>>>> >>>>>> Since?the first call will return when value > 0 and the second call will >>>>>> return when value2 > value (I still wonder why we want to ensure it >>>>>> works twice...). >>>>> >>>>> The test is trying to sanity check that we are actually recording the >>>>> time used by safepoints. So first check is that we can get a non-zero >>>>> value; second check is we get a greater non-zero value. It's just a >>>>> sanity test to try and catch if something gets unexpectedly broken in >>>>> the time tracking code. >>>>> >>>>>> So both failures and even testing for it is kind of redundant, once you >>>>>> have a do/while until a change? >>>>> >>>>> Yes - the problem with the tests that try to check internal VM behaviour >>>>> is that we have no specified way to do something, in this case execute >>>>> safepoints, that relates to internal VM behaviour, so we have to do >>>>> something we know will currently work even if not specified to do so - >>>>> e.g. dumping all thread stacks uses a global safepoint. The second >>>>> problem is that the timer granularity is so coarse that we then have to >>>>> guess how many times we need to do that something before seeing a >>>>> change. To make the test robust we can keep doing stuff until we see a >>>>> change and so the only way that will fail is if the overall timeout of >>>>> the test kicks in. Or we can try and second guess how long it should >>>>> take by introducing our own internal timeout - either directly or by >>>>> limiting the number of loops in this case. That has its own problems and >>>>> in general we have tried to reduce internal test timeouts (by removing >>>>> them) and let overall timeouts take charge. >>>>> >>>>> No ideal solution. And this has already consumed way too much of >>>>> everyone's time. >>>>> >>>>> Cheers, >>>>> David >>>>> >>>>>> Thanks, >>>>>> Jc >>>>>> >>>>>> >>>>>> On Tue, Jul 30, 2019 at 2:35 PM David Holmes >> >>>>> > wrote: >>>>>> >>>>>> On 30/07/2019 10:39 pm, Baesken, Matthias wrote: >>>>>> > Hi David,? ?"put that whole code (the while loop) in a helper >>>>>> method."? ?was JC's idea,? and I like the idea . >>>>>> >>>>>> Regardless I think the way you are using NUM_THREAD_DUMPS is >>>> really >>>>>> confusing. As an all-caps static you'd expect it to be a constant. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> > Let's see what others think . >>>>>> > >>>>>> >> >>>>>> >> Overall tests like this are not very useful, yet very fragile. >>>>>> >> >>>>>> > >>>>>> > I am also? fine with putting the test on the exclude list. >>>>>> > >>>>>> > Best regards, Matthias >>>>>> > >>>>>> > >>>>>> >> -----Original Message----- >>>>>> >> From: David Holmes >>>>> > >>>>>> >> Sent: Dienstag, 30. Juli 2019 14:12 >>>>>> >> To: Baesken, Matthias >>>>> >; Jean Christophe >>>>>> >> Beyler > >>>>>> >> Cc: hotspot-dev at openjdk.java.net >>>>>> ; serviceability-dev >>>>>> >>>>> >> dev at openjdk.java.net > >>>>>> >> Subject: Re: RFR: [XS] 8228658: test GetTotalSafepointTime.java >>>>>> fails on fast >>>>>> >> Linux machines with Total safepoint time 0 ms >>>>>> >> >>>>>> >> Hi Matthias, >>>>>> >> >>>>>> >> On 30/07/2019 9:25 pm, Baesken, Matthias wrote: >>>>>> >>> Hello? JC / David,?? here is a second webrev? : >>>>>> >>> >>>>>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8228658.1/ >>>>>> >>> >>>>>> >>> It moves?? the? thread dump execution into a? method >>>>>> >>> executeThreadDumps(long)?? ??, and also adds? while loops >>>>>> (but with a >>>>>> >>> limitation? for the number of thread dumps, really don?t >>>>>> >>> want to cause timeouts etc.).??? I removed a check for >>>>>> >>> MAX_VALUE_FOR_PASS?? because we cannot go over >>>>> Long.MAX_VALUE . >>>>>> >> >>>>>> >> I don't think executeThreadDumps is worth factoring out like out. >>>>>> >> >>>>>> >> The handling of NUM_THREAD_DUMPS is a bit confusing. I'd >> rather >>>> it >>>>>> >> remains a constant 100, and then you set a simple loop iteration >>>>>> count >>>>>> >> limit. Further with the proposed code when you get here: >>>>>> >> >>>>>> >>? ? 85? ? ? ? ?NUM_THREAD_DUMPS = NUM_THREAD_DUMPS * 2; >>>>>> >> >>>>>> >> you don't even know what value you may be starting with. >>>>>> >> >>>>>> >> But I was thinking of simply: >>>>>> >> >>>>>> >> long value = 0; >>>>>> >> do { >>>>>> >>? ? ? ?Thread.getAllStackTraces(); >>>>>> >>? ? ? ?value = mbean.getTotalSafepointTime(); >>>>>> >> } while (value == 0); >>>>>> >> >>>>>> >> We'd only hit a timeout if something is completely broken - >>>>>> which is fine. >>>>>> >> >>>>>> >> Overall tests like this are not very useful, yet very fragile. >>>>>> >> >>>>>> >> Thanks, >>>>>> >> David >>>>>> >> >>>>>> >>> Hope you like this version ?better. >>>>>> >>> >>>>>> >>> Best regards, Matthias >>>>>> >>> >>>>>> >>> *From:*Jean Christophe Beyler >>>>> > >>>>>> >>> *Sent:* Dienstag, 30. Juli 2019 05:39 >>>>>> >>> *To:* David Holmes >>>>> > >>>>>> >>> *Cc:* Baesken, Matthias >>>>> >; >>>>>> >>> hotspot-dev at openjdk.java.net >>>>>> ; serviceability-dev >>>>>> >>> >>>>> > >>>>>> >>> *Subject:* Re: RFR: [XS] 8228658: test >>>>>> GetTotalSafepointTime.java fails >>>>>> >>> on fast Linux machines with Total safepoint time 0 ms >>>>>> >>> >>>>>> >>> Hi Matthias, >>>>>> >>> >>>>>> >>> I wonder if you should not do what David is suggesting and then >>>>>> put that >>>>>> >>> whole code (the while loop) in a helper method. Below you >> have a >>>>>> >>> calculation again using value2 (which I wonder what the added >>>>>> value of >>>>>> >>> it is though) but anyway, that value2 could also be 0 at some >>>>>> point, no? >>>>>> >>> >>>>>> >>> So would it not be best to just refactor the getAllStackTraces >> and >>>>>> >>> calculate safepoint time in a helper method for both value / >> value2 >>>>>> >>> variables? >>>>>> >>> >>>>>> >>> Thanks, >>>>>> >>> >>>>>> >>> Jc >>>>>> >>> >>>>>> >>> On Mon, Jul 29, 2019 at 7:50 PM David Holmes >>>>>> >>>>>> >>> >>>>> >> wrote: >>>>>> >>> >>>>>> >>>? ? ? Hi Matthias, >>>>>> >>> >>>>>> >>>? ? ? On 29/07/2019 8:20 pm, Baesken, Matthias wrote: >>>>>> >>>? ? ? ?> Hello , please review this small test fix . >>>>>> >>>? ? ? ?> >>>>>> >>>? ? ? ?> The test >>>>>> >>> >>>>>> >> >>>>> >>>> >> test/jdk/sun/management/HotspotRuntimeMBean/GetTotalSafepointTime. >>>>>> >> java >>>>>> >>>? ? ? fails sometimes on fast Linux machines with this error >>>>>> message : >>>>>> >>>? ? ? ?> >>>>>> >>>? ? ? ?> java.lang.RuntimeException: Total safepoint time >>>>>> illegal value: 0 >>>>>> >>>? ? ? ms (MIN = 1; MAX = 9223372036854775807) >>>>>> >>>? ? ? ?> >>>>>> >>>? ? ? ?> looks like the total safepoint time is too low >>>>>> currently on these >>>>>> >>>? ? ? machines, it is < 1 ms. >>>>>> >>>? ? ? ?> >>>>>> >>>? ? ? ?> There might be several ways to handle this : >>>>>> >>>? ? ? ?> >>>>>> >>>? ? ? ?>? ? *? ?Change the test? in a way that it might generate >>>>>> nigher >>>>>> >>>? ? ? safepoint times >>>>>> >>>? ? ? ?>? ? *? ?Allow? safepoint time? == 0 ms >>>>>> >>>? ? ? ?>? ? *? ?Offer an additional interface that gives >>>>>> safepoint times >>>>>> >>>? ? ? with finer granularity ( currently the HS has safepoint >>>>>> time values >>>>>> >>>? ? ? in ns , see? jdk/src/hotspot/share/runtime/safepoint.cpp >>>>>> >>>? ? ? ??SafepointTracing::end >>>>>> >>>? ? ? ?> >>>>>> >>>? ? ? ?> But it is converted on ms in this code >>>>>> >>>? ? ? ?> >>>>>> >>>? ? ? ?> 114jlong RuntimeService::safepoint_time_ms() { >>>>>> >>>? ? ? ?> 115? return UsePerfData ? >>>>>> >>>? ? ? ?> 116 >>>>>> >>> >>>>>> Management::ticks_to_ms(_safepoint_time_ticks->get_value()) : - >> 1; >>>>>> >>>? ? ? ?> 117} >>>>>> >>>? ? ? ?> >>>>>> >>>? ? ? ?> 064jlong Management::ticks_to_ms(jlong ticks) { >>>>>> >>>? ? ? ?> 2065? assert(os::elapsed_frequency() > 0, "Must be >>>>>> non-zero"); >>>>>> >>>? ? ? ?> 2066? return (jlong)(((double)ticks / >>>>>> >>>? ? ? (double)os::elapsed_frequency()) >>>>>> >>>? ? ? ?> 2067? ? ? ? ? ? ? ? ?* (double)1000.0); >>>>>> >>>? ? ? ?> 2068} >>>>>> >>>? ? ? ?> >>>>>> >>>? ? ? ?> >>>>>> >>>? ? ? ?> >>>>>> >>>? ? ? ?> Currently I go for? the first attempt (and try to generate >>>>>> >>>? ? ? higher safepoint times in my patch) . >>>>>> >>> >>>>>> >>>? ? ? Yes that's probably best. Coarse-grained timing on very >>>>>> fast machines >>>>>> >>>? ? ? was bound to eventually lead to problems. >>>>>> >>> >>>>>> >>>? ? ? But perhaps a more future-proof approach is to just add a >>>>>> do-while loop >>>>>> >>>? ? ? around the stack dumps and only exit when we have a non- >> zero >>>>>> >> safepoint >>>>>> >>>? ? ? time? >>>>>> >>> >>>>>> >>>? ? ? Thanks, >>>>>> >>>? ? ? David >>>>>> >>>? ? ? ----- >>>>>> >>> >>>>>> >>>? ? ? ?> Bug/webrev : >>>>>> >>>? ? ? ?> >>>>>> >>>? ? ? ?> https://bugs.openjdk.java.net/browse/JDK-8228658 >>>>>> >>>? ? ? ?> >>>>>> >>>? ? ? ?> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8228658.0/ >>>>>> >>>? ? ? ?> >>>>>> >>>? ? ? ?> >>>>>> >>>? ? ? ?> Thanks, Matthias >>>>>> >>>? ? ? ?> >>>>>> >>> >>>>>> >>> >>>>>> >>> -- >>>>>> >>> >>>>>> >>> Thanks, >>>>>> >>> >>>>>> >>> Jc >>>>>> >>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Thanks, >>>>>> Jc From daniel.daugherty at oracle.com Thu Aug 1 19:26:22 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 1 Aug 2019 15:26:22 -0400 Subject: RFR(T): 8226899 Problemlist compiler/rtm tests Message-ID: <7335f76d-5359-3a17-0dcf-2b2849c3cfd9@oracle.com> Greetings, There are a number of Compiler RTM tests failing the JDK14 CI. I'm tired of the noise so I'm going to ProblemList all of the sightings that I have found: $ hg diff diff -r 9afbcd27f26f test/hotspot/jtreg/ProblemList.txt --- a/test/hotspot/jtreg/ProblemList.txt Thu Aug 01 09:29:13 2019 -0700 +++ b/test/hotspot/jtreg/ProblemList.txt Thu Aug 01 15:09:59 2019 -0400 @@ -59,6 +59,16 @@ ?compiler/runtime/Test8168712.java 8211769,8211771 generic-ppc64,generic-ppc64le,linux-s390x +compiler/rtm/locking/TestRTMAbortRatio.java 8183263 generic-x64 +compiler/rtm/locking/TestRTMAbortThreshold.java 8183263 generic-x64 +compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java 8183263 generic-x64 +compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java 8183263 generic-x64 +compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java 8183263 generic-x64 +compiler/rtm/locking/TestRTMLockingCalculationDelay.java 8183263 generic-x64 +compiler/rtm/locking/TestRTMLockingThreshold.java 8183263 generic-x64 +compiler/rtm/locking/TestUseRTMDeopt.java 8183263 generic-x64 +compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java 8183263 generic-x64 + I don't know or care if this is Skylake related or not. The tests are failing. They need to be ProblemListed. Thanks, in advance, for any questions, comments, or suggestions. Dan From vladimir.kozlov at oracle.com Thu Aug 1 19:51:22 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 1 Aug 2019 12:51:22 -0700 Subject: RFR(T): 8226899 Problemlist compiler/rtm tests In-Reply-To: <7335f76d-5359-3a17-0dcf-2b2849c3cfd9@oracle.com> References: <7335f76d-5359-3a17-0dcf-2b2849c3cfd9@oracle.com> Message-ID: <5d5afbba-7596-6ca8-3233-081bb88cb6aa@oracle.com> Agree. Thanks, Vladimir On 8/1/19 12:26 PM, Daniel D. Daugherty wrote: > Greetings, > > There are a number of Compiler RTM tests failing the JDK14 CI. I'm tired > of the noise so I'm going to ProblemList all of the sightings that I > have found: > > $ hg diff > diff -r 9afbcd27f26f test/hotspot/jtreg/ProblemList.txt > --- a/test/hotspot/jtreg/ProblemList.txt Thu Aug 01 09:29:13 2019 -0700 > +++ b/test/hotspot/jtreg/ProblemList.txt Thu Aug 01 15:09:59 2019 -0400 > @@ -59,6 +59,16 @@ > > ?compiler/runtime/Test8168712.java 8211769,8211771 > generic-ppc64,generic-ppc64le,linux-s390x > > +compiler/rtm/locking/TestRTMAbortRatio.java 8183263 generic-x64 > +compiler/rtm/locking/TestRTMAbortThreshold.java 8183263 generic-x64 > +compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java 8183263 generic-x64 > +compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java 8183263 generic-x64 > +compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java 8183263 generic-x64 > +compiler/rtm/locking/TestRTMLockingCalculationDelay.java 8183263 > generic-x64 > +compiler/rtm/locking/TestRTMLockingThreshold.java 8183263 generic-x64 > +compiler/rtm/locking/TestUseRTMDeopt.java 8183263 generic-x64 > +compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java 8183263 > generic-x64 > + > > I don't know or care if this is Skylake related or not. The tests > are failing. They need to be ProblemListed. > > Thanks, in advance, for any questions, comments, or suggestions. > > Dan > From daniel.daugherty at oracle.com Thu Aug 1 19:52:58 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 1 Aug 2019 15:52:58 -0400 Subject: RFR(T): 8226899 Problemlist compiler/rtm tests In-Reply-To: <5d5afbba-7596-6ca8-3233-081bb88cb6aa@oracle.com> References: <7335f76d-5359-3a17-0dcf-2b2849c3cfd9@oracle.com> <5d5afbba-7596-6ca8-3233-081bb88cb6aa@oracle.com> Message-ID: Thanks for the fast review! Dan On 8/1/19 3:51 PM, Vladimir Kozlov wrote: > Agree. > > Thanks, > Vladimir > > On 8/1/19 12:26 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> There are a number of Compiler RTM tests failing the JDK14 CI. I'm tired >> of the noise so I'm going to ProblemList all of the sightings that I >> have found: >> >> $ hg diff >> diff -r 9afbcd27f26f test/hotspot/jtreg/ProblemList.txt >> --- a/test/hotspot/jtreg/ProblemList.txt Thu Aug 01 09:29:13 2019 -0700 >> +++ b/test/hotspot/jtreg/ProblemList.txt Thu Aug 01 15:09:59 2019 -0400 >> @@ -59,6 +59,16 @@ >> >> ??compiler/runtime/Test8168712.java 8211769,8211771 >> generic-ppc64,generic-ppc64le,linux-s390x >> >> +compiler/rtm/locking/TestRTMAbortRatio.java 8183263 generic-x64 >> +compiler/rtm/locking/TestRTMAbortThreshold.java 8183263 generic-x64 >> +compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java 8183263 generic-x64 >> +compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java 8183263 >> generic-x64 >> +compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java 8183263 >> generic-x64 >> +compiler/rtm/locking/TestRTMLockingCalculationDelay.java 8183263 >> generic-x64 >> +compiler/rtm/locking/TestRTMLockingThreshold.java 8183263 generic-x64 >> +compiler/rtm/locking/TestUseRTMDeopt.java 8183263 generic-x64 >> +compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java 8183263 >> generic-x64 >> + >> >> I don't know or care if this is Skylake related or not. The tests >> are failing. They need to be ProblemListed. >> >> Thanks, in advance, for any questions, comments, or suggestions. >> >> Dan >> From gromero at linux.vnet.ibm.com Thu Aug 1 19:57:09 2019 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Thu, 1 Aug 2019 16:57:09 -0300 Subject: RFR(T): 8226899 Problemlist compiler/rtm tests In-Reply-To: <7335f76d-5359-3a17-0dcf-2b2849c3cfd9@oracle.com> References: <7335f76d-5359-3a17-0dcf-2b2849c3cfd9@oracle.com> Message-ID: <22cfd2ae-c012-0738-d373-ea32831cd0ef@linux.vnet.ibm.com> Hi Dan, On 08/01/2019 04:26 PM, Daniel D. Daugherty wrote: > Greetings, > > There are a number of Compiler RTM tests failing the JDK14 CI. I'm tired > of the noise so I'm going to ProblemList all of the sightings that I > have found: > > $ hg diff > diff -r 9afbcd27f26f test/hotspot/jtreg/ProblemList.txt > --- a/test/hotspot/jtreg/ProblemList.txt Thu Aug 01 09:29:13 2019 -0700 > +++ b/test/hotspot/jtreg/ProblemList.txt Thu Aug 01 15:09:59 2019 -0400 > @@ -59,6 +59,16 @@ > > compiler/runtime/Test8168712.java 8211769,8211771 generic-ppc64,generic-ppc64le,linux-s390x > > +compiler/rtm/locking/TestRTMAbortRatio.java 8183263 generic-x64 > +compiler/rtm/locking/TestRTMAbortThreshold.java 8183263 generic-x64 > +compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java 8183263 generic-x64 > +compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java 8183263 generic-x64 > +compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java 8183263 generic-x64 > +compiler/rtm/locking/TestRTMLockingCalculationDelay.java 8183263 generic-x64 > +compiler/rtm/locking/TestRTMLockingThreshold.java 8183263 generic-x64 > +compiler/rtm/locking/TestUseRTMDeopt.java 8183263 generic-x64 > +compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java 8183263 generic-x64 > + > > I don't know or care if this is Skylake related or not. The tests > are failing. They need to be ProblemListed. > > Thanks, in advance, for any questions, comments, or suggestions. As someone that spent a lot of time fixing these tests on Power and x86_64 I'm really interested in why in essence these tests are failing at your side. Previously I mentioned they were working on Skylake for me and I provided details on how I'm running the tests (please see [0]), but never got a reply on it. I do understand that RTM tests can be sometimes brittle in some environments, like when there are a few CPUs available and jtreg runs them in parallel. This is not the ideal scenario to test them since the rely on counting RTM abortions in some cases. So I'm wondering if they executed correctly by the CI. Maybe if you provide the output for the failure I could spot something obvious. I do see your list includes now only x86_64. In either case, I don't want to be a hindrance on problemlisting them, but I do think it would be good to at least have a look if something simple is being missed when running the tests. I tried the tests again on Skylake (because it's only machine I have access atm with RTM) and, again, all tests pass fine. I don't think that the CPU, provided it's newer than Skylake would change the result. Best regards, Gustavo [0] https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-June/038609.html -- $ make test JTREG="OPTIONS=-nativepath:/home/gromero/hg/jdk/jdk/build/linux-x86_64-server-release/support/test/hotspot/jtreg/native/lib" TEST=./test/hotspot/jtreg/compiler/rtm Test selection './test/hotspot/jtreg/compiler/rtm', will run: * jtreg:./test/hotspot/jtreg/compiler/rtm Running test 'jtreg:./test/hotspot/jtreg/compiler/rtm' Passed: compiler/rtm/cli/TestRTMLockingThresholdOption.java Passed: compiler/rtm/cli/TestRTMLockingCalculationDelayOption.java Passed: compiler/rtm/cli/TestRTMAbortThresholdOption.java Passed: compiler/rtm/cli/TestRTMRetryCountOption.java Passed: compiler/rtm/cli/TestPrintPreciseRTMLockingStatisticsOptionOnSupportedConfig.java Passed: compiler/rtm/cli/TestRTMSpinLoopCountOption.java Passed: compiler/rtm/cli/TestUseRTMDeoptOptionOnSupportedConfig.java Passed: compiler/rtm/cli/TestUseRTMForStackLocksOptionOnSupportedConfig.java Passed: compiler/rtm/cli/TestUseRTMLockingOptionOnSupportedConfig.java Passed: compiler/rtm/cli/TestUseRTMXendForLockBusyOption.java Passed: compiler/rtm/cli/TestUseRTMLockingOptionWithBiasedLocking.java Passed: compiler/rtm/locking/TestRTMAbortThreshold.java Passed: compiler/rtm/locking/TestRTMAbortRatio.java Passed: compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java Passed: compiler/rtm/cli/TestRTMTotalCountIncrRateOptionOnSupportedConfig.java Passed: compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java Passed: compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java Passed: compiler/rtm/locking/TestRTMLockingThreshold.java Passed: compiler/rtm/locking/TestRTMLockingCalculationDelay.java Passed: compiler/rtm/locking/TestUseRTMAfterLockInflation.java Passed: compiler/rtm/locking/TestRTMTotalCountIncrRate.java Passed: compiler/rtm/locking/TestUseRTMDeopt.java Passed: compiler/rtm/locking/TestUseRTMForInflatedLocks.java Passed: compiler/rtm/locking/TestUseRTMForStackLocks.java Passed: compiler/rtm/method_options/TestNoRTMLockElidingOption.java Passed: compiler/rtm/method_options/TestUseRTMLockElidingOption.java Passed: compiler/rtm/locking/TestRTMSpinLoopCount.java Passed: compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java Passed: compiler/rtm/locking/TestRTMRetryCount.java Passed: compiler/rtm/locking/TestUseRTMXendForLockBusy.java Test results: passed: 30 Report written to /home/gromero/hg/jdk/jdk/build/linux-x86_64-server-release/test-results/jtreg_test_hotspot_jtreg_compiler_rtm/html/report.html Results written to /home/gromero/hg/jdk/jdk/build/linux-x86_64-server-release/test-support/jtreg_test_hotspot_jtreg_compiler_rtm Finished running test 'jtreg:./test/hotspot/jtreg/compiler/rtm' Test report is stored in build/linux-x86_64-server-release/test-results/jtreg_test_hotspot_jtreg_compiler_rtm ============================== Test summary ============================== TEST TOTAL PASS FAIL ERROR jtreg:./test/hotspot/jtreg/compiler/rtm 30 30 0 0 ============================== TEST SUCCESS Finished building target 'test' in configuration 'linux-x86_64-server-release' gromero at moog:~/hg/jdk/jdk$ hg path default = http://hg.openjdk.java.net/jdk/jdk/ gromero at moog:~/hg/jdk/jdk$ hg id 9afbcd27f26f tip gromero at moog:~/hg/jdk/jdk$ hg log -vr. changeset: 55883:9afbcd27f26f tag: tip user: mikael date: Thu Aug 01 09:29:13 2019 -0700 files: .hgtags description: Added tag jdk-14+8 for changeset c0023e364b6f From daniel.daugherty at oracle.com Thu Aug 1 20:03:03 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 1 Aug 2019 16:03:03 -0400 Subject: RFR(T): 8226899 Problemlist compiler/rtm tests In-Reply-To: <22cfd2ae-c012-0738-d373-ea32831cd0ef@linux.vnet.ibm.com> References: <7335f76d-5359-3a17-0dcf-2b2849c3cfd9@oracle.com> <22cfd2ae-c012-0738-d373-ea32831cd0ef@linux.vnet.ibm.com> Message-ID: <78fbe881-b1e4-c438-ebb6-a3c4bf22a610@oracle.com> Hi Gustavo! Please take up the discussion with the Compiler team relative to: ??? JDK-8183263 compiler/rtm tests fail on SKL hosts ??? https://bugs.openjdk.java.net/browse/JDK-8183263 and you folks can figure out the underlying cause of what might be going wrong with these tests. For today, I have my Gatekeeping hat on and I'm just trying to reduce the number of failures that I have to sift through in the various Mach5 tiers... :-) Dan On 8/1/19 3:57 PM, Gustavo Romero wrote: > Hi Dan, > > On 08/01/2019 04:26 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> There are a number of Compiler RTM tests failing the JDK14 CI. I'm tired >> of the noise so I'm going to ProblemList all of the sightings that I >> have found: >> >> $ hg diff >> diff -r 9afbcd27f26f test/hotspot/jtreg/ProblemList.txt >> --- a/test/hotspot/jtreg/ProblemList.txt Thu Aug 01 09:29:13 2019 -0700 >> +++ b/test/hotspot/jtreg/ProblemList.txt Thu Aug 01 15:09:59 2019 -0400 >> @@ -59,6 +59,16 @@ >> >> ? compiler/runtime/Test8168712.java 8211769,8211771 >> generic-ppc64,generic-ppc64le,linux-s390x >> >> +compiler/rtm/locking/TestRTMAbortRatio.java 8183263 generic-x64 >> +compiler/rtm/locking/TestRTMAbortThreshold.java 8183263 generic-x64 >> +compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java 8183263 generic-x64 >> +compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java 8183263 >> generic-x64 >> +compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java 8183263 >> generic-x64 >> +compiler/rtm/locking/TestRTMLockingCalculationDelay.java 8183263 >> generic-x64 >> +compiler/rtm/locking/TestRTMLockingThreshold.java 8183263 generic-x64 >> +compiler/rtm/locking/TestUseRTMDeopt.java 8183263 generic-x64 >> +compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java 8183263 >> generic-x64 >> + >> >> I don't know or care if this is Skylake related or not. The tests >> are failing. They need to be ProblemListed. >> >> Thanks, in advance, for any questions, comments, or suggestions. > > As someone that spent a lot of time fixing these tests on Power and > x86_64 I'm > really interested in why in essence these tests are failing at your side. > > Previously I mentioned they were working on Skylake for me and I provided > details on how I'm running the tests (please see [0]), but never got a > reply on > it. > > I do understand that RTM tests can be sometimes brittle in some > environments, > like when there are a few CPUs available and jtreg runs them in > parallel. This > is not the ideal scenario to test them since the rely on counting RTM > abortions > in some cases. So I'm wondering if they executed correctly by the CI. > Maybe if > you provide the output for the failure I could spot something obvious. > I do see > your list includes now only x86_64. > > In either case, I don't want to be a hindrance on problemlisting them, > but I do > think it would be good to at least have a look if something simple is > being > missed when running the tests. > > I tried the tests again on Skylake (because it's only machine I have > access atm > with RTM) and, again, all tests pass fine. I don't think that the CPU, > provided > it's newer than Skylake would change the result. > > Best regards, > Gustavo > > [0] > https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-June/038609.html > > -- > > $ make test > JTREG="OPTIONS=-nativepath:/home/gromero/hg/jdk/jdk/build/linux-x86_64-server-release/support/test/hotspot/jtreg/native/lib" > TEST=./test/hotspot/jtreg/compiler/rtm > > Test selection './test/hotspot/jtreg/compiler/rtm', will run: > * jtreg:./test/hotspot/jtreg/compiler/rtm > > Running test 'jtreg:./test/hotspot/jtreg/compiler/rtm' > Passed: compiler/rtm/cli/TestRTMLockingThresholdOption.java > Passed: compiler/rtm/cli/TestRTMLockingCalculationDelayOption.java > Passed: compiler/rtm/cli/TestRTMAbortThresholdOption.java > Passed: compiler/rtm/cli/TestRTMRetryCountOption.java > Passed: > compiler/rtm/cli/TestPrintPreciseRTMLockingStatisticsOptionOnSupportedConfig.java > Passed: compiler/rtm/cli/TestRTMSpinLoopCountOption.java > Passed: compiler/rtm/cli/TestUseRTMDeoptOptionOnSupportedConfig.java > Passed: > compiler/rtm/cli/TestUseRTMForStackLocksOptionOnSupportedConfig.java > Passed: compiler/rtm/cli/TestUseRTMLockingOptionOnSupportedConfig.java > Passed: compiler/rtm/cli/TestUseRTMXendForLockBusyOption.java > Passed: compiler/rtm/cli/TestUseRTMLockingOptionWithBiasedLocking.java > Passed: compiler/rtm/locking/TestRTMAbortThreshold.java > Passed: compiler/rtm/locking/TestRTMAbortRatio.java > Passed: compiler/rtm/locking/TestRTMAfterNonRTMDeopt.java > Passed: > compiler/rtm/cli/TestRTMTotalCountIncrRateOptionOnSupportedConfig.java > Passed: compiler/rtm/locking/TestRTMDeoptOnHighAbortRatio.java > Passed: compiler/rtm/locking/TestRTMDeoptOnLowAbortRatio.java > Passed: compiler/rtm/locking/TestRTMLockingThreshold.java > Passed: compiler/rtm/locking/TestRTMLockingCalculationDelay.java > Passed: compiler/rtm/locking/TestUseRTMAfterLockInflation.java > Passed: compiler/rtm/locking/TestRTMTotalCountIncrRate.java > Passed: compiler/rtm/locking/TestUseRTMDeopt.java > Passed: compiler/rtm/locking/TestUseRTMForInflatedLocks.java > Passed: compiler/rtm/locking/TestUseRTMForStackLocks.java > Passed: compiler/rtm/method_options/TestNoRTMLockElidingOption.java > Passed: compiler/rtm/method_options/TestUseRTMLockElidingOption.java > Passed: compiler/rtm/locking/TestRTMSpinLoopCount.java > Passed: compiler/rtm/print/TestPrintPreciseRTMLockingStatistics.java > Passed: compiler/rtm/locking/TestRTMRetryCount.java > Passed: compiler/rtm/locking/TestUseRTMXendForLockBusy.java > Test results: passed: 30 > Report written to > /home/gromero/hg/jdk/jdk/build/linux-x86_64-server-release/test-results/jtreg_test_hotspot_jtreg_compiler_rtm/html/report.html > Results written to > /home/gromero/hg/jdk/jdk/build/linux-x86_64-server-release/test-support/jtreg_test_hotspot_jtreg_compiler_rtm > Finished running test 'jtreg:./test/hotspot/jtreg/compiler/rtm' > Test report is stored in > build/linux-x86_64-server-release/test-results/jtreg_test_hotspot_jtreg_compiler_rtm > > ============================== > Test summary > ============================== > ?? TEST????????????????????????????????????????????? TOTAL? PASS FAIL > ERROR > ?? jtreg:./test/hotspot/jtreg/compiler/rtm????????????? 30 30???? 0???? 0 > ============================== > TEST SUCCESS > > Finished building target 'test' in configuration > 'linux-x86_64-server-release' > gromero at moog:~/hg/jdk/jdk$ hg path > default = http://hg.openjdk.java.net/jdk/jdk/ > gromero at moog:~/hg/jdk/jdk$ hg id > 9afbcd27f26f tip > gromero at moog:~/hg/jdk/jdk$ hg log -vr. > changeset:?? 55883:9afbcd27f26f > tag:???????? tip > user:??????? mikael > date:??????? Thu Aug 01 09:29:13 2019 -0700 > files:?????? .hgtags > description: > Added tag jdk-14+8 for changeset c0023e364b6f > From gromero at linux.vnet.ibm.com Thu Aug 1 20:16:51 2019 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Thu, 1 Aug 2019 17:16:51 -0300 Subject: RFR(T): 8226899 Problemlist compiler/rtm tests In-Reply-To: <78fbe881-b1e4-c438-ebb6-a3c4bf22a610@oracle.com> References: <7335f76d-5359-3a17-0dcf-2b2849c3cfd9@oracle.com> <22cfd2ae-c012-0738-d373-ea32831cd0ef@linux.vnet.ibm.com> <78fbe881-b1e4-c438-ebb6-a3c4bf22a610@oracle.com> Message-ID: Hi Dan, On 08/01/2019 05:03 PM, Daniel D. Daugherty wrote: > Hi Gustavo! > > Please take up the discussion with the Compiler team relative to: > > JDK-8183263 compiler/rtm tests fail on SKL hosts > https://bugs.openjdk.java.net/browse/JDK-8183263 yep, I did see that bug. All comments predate my refactor (they are from 2017). Only the last one from Robert Mckenna looks new, but I can't access the link (it's Oracle internal only) and the comment is too short to be meaningful for me. > and you folks can figure out the underlying cause of what might > be going wrong with these tests. > > For today, I have my Gatekeeping hat on and I'm just trying to > reduce the number of failures that I have to sift through in > the various Mach5 tiers... :-) Well, that's life. It's sad that TM/RTM defeated me again. Go for it ;) Cheers, Gustavo From vladimir.kozlov at oracle.com Thu Aug 1 20:42:24 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 1 Aug 2019 13:42:24 -0700 Subject: RFR(T): 8226899 Problemlist compiler/rtm tests In-Reply-To: References: <7335f76d-5359-3a17-0dcf-2b2849c3cfd9@oracle.com> <22cfd2ae-c012-0738-d373-ea32831cd0ef@linux.vnet.ibm.com> <78fbe881-b1e4-c438-ebb6-a3c4bf22a610@oracle.com> Message-ID: <0436af29-9c84-aa8b-1bea-0520d023f78d@oracle.com> Hi Gustavo Most new failures links are in closed comments. I just added test output for latest failure from yesterday. Vladimir On 8/1/19 1:16 PM, Gustavo Romero wrote: > Hi Dan, > > On 08/01/2019 05:03 PM, Daniel D. Daugherty wrote: >> Hi Gustavo! >> >> Please take up the discussion with the Compiler team relative to: >> >> ???? JDK-8183263 compiler/rtm tests fail on SKL hosts >> ???? https://bugs.openjdk.java.net/browse/JDK-8183263 > > yep, I did see that bug. All comments predate my refactor (they are from > 2017). > Only the last one from Robert Mckenna looks new, but I can't access the > link > (it's Oracle internal only) and the comment is too short to be > meaningful for > me. > > >> and you folks can figure out the underlying cause of what might >> be going wrong with these tests. >> >> For today, I have my Gatekeeping hat on and I'm just trying to >> reduce the number of failures that I have to sift through in >> the various Mach5 tiers... :-) > > Well, that's life. It's sad that TM/RTM defeated me again. > > Go for it ;) > > Cheers, > Gustavo > From david.holmes at oracle.com Thu Aug 1 23:03:37 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 2 Aug 2019 09:03:37 +1000 Subject: RFR (S): 8228857: Refactor PlatformMonitor into PlatformMutex and PlatformMonitor Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8228857 webrev: http://cr.openjdk.java.net/~dholmes/8228857/webrev/ As suggested by Per Liden when PlatformMonitor was introduced by JDK-8210832 we should refactor PlatformMonitor into a simpler PlatformMutex extended by PlatformMonitor. That would potentially allow other synchronization objects e.g. Zlocks, to be replaced by a suitable PlatformX class, and allows us to redefine JVM_RawMonitor support to use it (forthcoming change). The refactoring would be obvious and simple if not for the macOS PThread allocation bug workaround. I had to change the Posix variant so that we only use the Impl helper class on macOS, so that we can separate the allocation of the pthread_mutex_t and pthread_cond_t. For macOS both get allocated in the PlatformMutex. There are not actual usage changes in this RFE. Testing: mach5 tiers 1-3 Thanks, David ----- From matthias.baesken at sap.com Fri Aug 2 08:22:43 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 2 Aug 2019 08:22:43 +0000 Subject: RFR: 8228902: add os::dll_load to the unified logging os category Message-ID: Hello, I missed the shared library loads in the UL (os category) . So I created a small webrev and added the info . Please review ! Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8228902 http://cr.openjdk.java.net/~mbaesken/webrevs/8228902.0/ Thanks, Matthias From erik.osterlund at oracle.com Fri Aug 2 13:29:35 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Fri, 2 Aug 2019 15:29:35 +0200 Subject: RFR: 8227054: ServiceThread needs to know about all OopStorage objects In-Reply-To: <8181924C-36E6-4B91-9567-150F00286241@oracle.com> References: <8181924C-36E6-4B91-9567-150F00286241@oracle.com> Message-ID: Hi Kim, I had a look at the patch. Personally I'm not a big fan of using macro tricks. Perhaps because it's in caps, which makes me read the code in my head with a loud screaming voice, with a slightly angry italian accent. And I don't even know italian - it is crazy. Anyway, I have come up with an alternative solution that is worth considering, I think, due to its simplicity. Step 1: Move all oop storages to a new file, and add a utility for iterating over them: webrev: http://cr.openjdk.java.net/~eosterlund/8227054/webrev.00/ This is quite straight forward. A new OopStorageSet AllStatic class has all oop storages, and offers some iterators. Step 2: Change weak processor to automatically process oop storages: webrev:http://cr.openjdk.java.net/~eosterlund/8227054/webrev.01/ incremental: http://cr.openjdk.java.net/~eosterlund/8227054/webrev.00_01/ I noticed that the weak processor has an enum with all phases, but pretty much always dealt with oop storage phases differently, with various checks if it is an oop storage phase, do something different, or assert that things are only done in an oop storage phase. So I made processing of oop storages use the new iterators instead, and opt out from the enum macro dance. To add a new OopStorage, you add it to the OopStorageSet by plugging in a declaration in OopStorageSet::StrongOopStorageSet or OopStorageSet::WeakOopStorageSet depending on strength, stick in a getter if you need direct access, and create an instance in OopStorageSet::initialize() - 3 lines in total. This is 2 lines less than your approach, but I think that is okay for the added simplicity. In total, this patch removes more code than it introduces. Thoughts? Thanks, /Erik On 2019-07-26 22:39, Kim Barrett wrote: >> On Jul 26, 2019, at 10:38 AM, coleen.phillimore at oracle.com wrote: >> >> >> I like this change! >> >> http://cr.openjdk.java.net/~kbarrett/8227054/open.00/src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp.udiff.html >> >> Can you remove some #include directives from the GC code since the oop storages are coming from oopStorages? >> >> http://cr.openjdk.java.net/~kbarrett/8227054/open.00/src/hotspot/share/prims/resolvedMethodTable.cpp.udiff.html >> >> Does this still need to #include oopStorage.inline.hpp ? >> >> http://cr.openjdk.java.net/~kbarrett/8227054/open.00/src/hotspot/share/prims/resolvedMethodTable.hpp.frames.html >> >> This doesn't seem to need to include oopStorage.hpp. Might be others too. > Thanks for suggesting some #include trimming. I did some cleanup. > >> http://cr.openjdk.java.net/~kbarrett/8227054/open.00/src/hotspot/share/gc/shared/oopStorages.hpp.html >> >> I thought our compilers were tolerant of a trailing comma in enumerations? > Solaris Studio doesn't like trailing commas in enums. > >> The macros aren't bad though. It seems like it would be easy to add a new OopStorage if we wanted to, but it would be better to use an existing vm weak or vm strong oop storage, if we wanted to move more oops into an oop storage (say for JFR). > Right. Also easy to remove one. (Someone told me there are ideas > afloat that might remove the need for the ResolvedMethodTableWeak > storage object.) > > I don't expect the set to be changing frequently. But it's a bit of a > pain to track down all the right places. (Even still, because the GCs > still have explicit knowledge of the full set, though this change > provides tools to address that.) > >> This change looks great apart from trying to remove more #includes. > Thanks. > > New webrevs: > full: http://cr.openjdk.java.net/~kbarrett/8227054/open.01/ > incr: http://cr.openjdk.java.net/~kbarrett/8227054/open.01.inc/ > > From gromero at linux.vnet.ibm.com Fri Aug 2 13:36:18 2019 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Fri, 2 Aug 2019 10:36:18 -0300 Subject: RFR(T): 8226899 Problemlist compiler/rtm tests In-Reply-To: <0436af29-9c84-aa8b-1bea-0520d023f78d@oracle.com> References: <7335f76d-5359-3a17-0dcf-2b2849c3cfd9@oracle.com> <22cfd2ae-c012-0738-d373-ea32831cd0ef@linux.vnet.ibm.com> <78fbe881-b1e4-c438-ebb6-a3c4bf22a610@oracle.com> <0436af29-9c84-aa8b-1bea-0520d023f78d@oracle.com> Message-ID: <8af7e80a-db10-6b2d-86e1-ed2d86d9b724@linux.vnet.ibm.com> Hi Vladimir! Thanks a lot. Hastily eyeballing I see I'm not testing with XX:+UseZGC. Basically the expected transaction are not being aborted so the tests fail in Oracle's CI. I'll have a closer look next week hopefully. Best regards, Gustavo On 08/01/2019 05:42 PM, Vladimir Kozlov wrote: > Hi Gustavo > > Most new failures links are in closed comments. > > I just added test output for latest failure from yesterday. > > Vladimir > > On 8/1/19 1:16 PM, Gustavo Romero wrote: >> Hi Dan, >> >> On 08/01/2019 05:03 PM, Daniel D. Daugherty wrote: >>> Hi Gustavo! >>> >>> Please take up the discussion with the Compiler team relative to: >>> >>> JDK-8183263 compiler/rtm tests fail on SKL hosts >>> https://bugs.openjdk.java.net/browse/JDK-8183263 >> >> yep, I did see that bug. All comments predate my refactor (they are from 2017). >> Only the last one from Robert Mckenna looks new, but I can't access the link >> (it's Oracle internal only) and the comment is too short to be meaningful for >> me. >> >> >>> and you folks can figure out the underlying cause of what might >>> be going wrong with these tests. >>> >>> For today, I have my Gatekeeping hat on and I'm just trying to >>> reduce the number of failures that I have to sift through in >>> the various Mach5 tiers... :-) >> >> Well, that's life. It's sad that TM/RTM defeated me again. >> >> Go for it ;) >> >> Cheers, >> Gustavo >> > From per.liden at oracle.com Fri Aug 2 15:09:51 2019 From: per.liden at oracle.com (Per Liden) Date: Fri, 2 Aug 2019 17:09:51 +0200 Subject: RFR: 8227054: ServiceThread needs to know about all OopStorage objects In-Reply-To: References: <8181924C-36E6-4B91-9567-150F00286241@oracle.com> Message-ID: <46ef6d59-f431-fff3-3abd-f3cc935db9d6@oracle.com> Hi Erik & Kim, On 8/2/19 3:29 PM, Erik ?sterlund wrote: > Hi Kim, > > I had a look at the patch. Personally I'm not a big fan of using macro > tricks. Perhaps because it's in caps, which makes me read the code in my > head with a loud screaming voice, with a slightly angry italian accent. > And I don't even know italian - it is crazy. I kind of had the same reaction. I stared at the initial patch for a good 30 minutes and then gave up. That x-macros makes this very difficult to read and follow, and it doesn't look like they actually solve anything important. > > Anyway, I have come up with an alternative solution that is worth > considering, I think, due to its simplicity. > > Step 1: Move all oop storages to a new file, and add a utility for > iterating over them: > > webrev: http://cr.openjdk.java.net/~eosterlund/8227054/webrev.00/ > > This is quite straight forward. A new OopStorageSet AllStatic class has > all oop storages, and offers some iterators. > > Step 2: Change weak processor to automatically process oop storages: > > webrev:http://cr.openjdk.java.net/~eosterlund/8227054/webrev.01/ > incremental: http://cr.openjdk.java.net/~eosterlund/8227054/webrev.00_01/ > > I noticed that the weak processor has an enum with all phases, but > pretty much always dealt with oop storage phases differently, with > various checks if it is an oop storage phase, do something different, or > assert that things are only done in an oop storage phase. > So I made processing of oop storages use the new iterators instead, and > opt out from the enum macro dance. > > To add a new OopStorage, you add it to the OopStorageSet by plugging in > a declaration in OopStorageSet::StrongOopStorageSet or > OopStorageSet::WeakOopStorageSet depending on strength, stick in a > getter if you need direct access, and create an instance in > OopStorageSet::initialize() - 3 lines in total. This is 2 lines less > than your approach, but I think that is okay for the added simplicity. > > In total, this patch removes more code than it introduces. > > Thoughts? Thanks a lot Erik, for taking the time to do this proposal. This looks a lot more straight forward and sane to me. src/hotspot/share/runtime/jniHandles.cpp ---------------------------------------- 186 void JNIHandles::weak_oops_do(OopClosure* f) { 187 OopStorageSet::weak_jni(); 188 } Missing "->weak_oops_do(f)" there. Other than than that, I'd be happy with this proposal. cheers, Per > > Thanks, > /Erik > > > On 2019-07-26 22:39, Kim Barrett wrote: >>> On Jul 26, 2019, at 10:38 AM, coleen.phillimore at oracle.com wrote: >>> >>> >>> I like this change! >>> >>> http://cr.openjdk.java.net/~kbarrett/8227054/open.00/src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp.udiff.html >>> >>> >>> Can you remove some #include directives from the GC code since the >>> oop storages are coming from oopStorages? >>> >>> http://cr.openjdk.java.net/~kbarrett/8227054/open.00/src/hotspot/share/prims/resolvedMethodTable.cpp.udiff.html >>> >>> >>> Does this still need to #include oopStorage.inline.hpp ? >>> >>> http://cr.openjdk.java.net/~kbarrett/8227054/open.00/src/hotspot/share/prims/resolvedMethodTable.hpp.frames.html >>> >>> >>> This doesn't seem to need to include oopStorage.hpp.? Might be others >>> too. >> Thanks for suggesting some #include trimming.? I did some cleanup. >> >>> http://cr.openjdk.java.net/~kbarrett/8227054/open.00/src/hotspot/share/gc/shared/oopStorages.hpp.html >>> >>> >>> I thought our compilers were tolerant of a trailing comma in >>> enumerations? >> Solaris Studio doesn't like trailing commas in enums. >> >>> The macros aren't bad though.? It seems like it would be easy to add >>> a new OopStorage if we wanted to, but it would be better to use an >>> existing vm weak or vm strong oop storage, if we wanted to move more >>> oops into an oop storage (say for JFR). >> Right.? Also easy to remove one.? (Someone told me there are ideas >> afloat that might remove the need for the ResolvedMethodTableWeak >> storage object.) >> >> I don't expect the set to be changing frequently.? But it's a bit of a >> pain to track down all the right places.? (Even still, because the GCs >> still have explicit knowledge of the full set, though this change >> provides tools to address that.) >> >>> This change looks great apart from trying to remove more #includes. >> Thanks. >> >> New webrevs: >> full: http://cr.openjdk.java.net/~kbarrett/8227054/open.01/ >> incr: http://cr.openjdk.java.net/~kbarrett/8227054/open.01.inc/ >> >> > From erik.osterlund at oracle.com Fri Aug 2 16:41:27 2019 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Fri, 2 Aug 2019 18:41:27 +0200 Subject: RFR: 8227054: ServiceThread needs to know about all OopStorage objects In-Reply-To: <46ef6d59-f431-fff3-3abd-f3cc935db9d6@oracle.com> References: <8181924C-36E6-4B91-9567-150F00286241@oracle.com> <46ef6d59-f431-fff3-3abd-f3cc935db9d6@oracle.com> Message-ID: Hi Per, > On 2 Aug 2019, at 17:09, Per Liden wrote: > > Thanks a lot Erik, for taking the time to do this proposal. This looks a lot more straight forward and sane to me. Glad you liked it! > src/hotspot/share/runtime/jniHandles.cpp > ---------------------------------------- > 186 void JNIHandles::weak_oops_do(OopClosure* f) { > 187 OopStorageSet::weak_jni(); > 188 } > > Missing "->weak_oops_do(f)" there. Nice catch. Looks like that function is dead code. Will fix. > Other than than that, I'd be happy with this proposal. Thanks for having a look, and glad you liked it. /Erik > cheers, > Per > >> Thanks, >> /Erik >> On 2019-07-26 22:39, Kim Barrett wrote: >>>> On Jul 26, 2019, at 10:38 AM, coleen.phillimore at oracle.com wrote: >>>> >>>> >>>> I like this change! >>>> >>>> http://cr.openjdk.java.net/~kbarrett/8227054/open.00/src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp.udiff.html >>>> >>>> Can you remove some #include directives from the GC code since the oop storages are coming from oopStorages? >>>> >>>> http://cr.openjdk.java.net/~kbarrett/8227054/open.00/src/hotspot/share/prims/resolvedMethodTable.cpp.udiff.html >>>> >>>> Does this still need to #include oopStorage.inline.hpp ? >>>> >>>> http://cr.openjdk.java.net/~kbarrett/8227054/open.00/src/hotspot/share/prims/resolvedMethodTable.hpp.frames.html >>>> >>>> This doesn't seem to need to include oopStorage.hpp. Might be others too. >>> Thanks for suggesting some #include trimming. I did some cleanup. >>> >>>> http://cr.openjdk.java.net/~kbarrett/8227054/open.00/src/hotspot/share/gc/shared/oopStorages.hpp.html >>>> >>>> I thought our compilers were tolerant of a trailing comma in enumerations? >>> Solaris Studio doesn't like trailing commas in enums. >>> >>>> The macros aren't bad though. It seems like it would be easy to add a new OopStorage if we wanted to, but it would be better to use an existing vm weak or vm strong oop storage, if we wanted to move more oops into an oop storage (say for JFR). >>> Right. Also easy to remove one. (Someone told me there are ideas >>> afloat that might remove the need for the ResolvedMethodTableWeak >>> storage object.) >>> >>> I don't expect the set to be changing frequently. But it's a bit of a >>> pain to track down all the right places. (Even still, because the GCs >>> still have explicit knowledge of the full set, though this change >>> provides tools to address that.) >>> >>>> This change looks great apart from trying to remove more #includes. >>> Thanks. >>> >>> New webrevs: >>> full: http://cr.openjdk.java.net/~kbarrett/8227054/open.01/ >>> incr: http://cr.openjdk.java.net/~kbarrett/8227054/open.01.inc/ >>> >>> From igor.ignatyev at oracle.com Fri Aug 2 17:05:36 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 2 Aug 2019 10:05:36 -0700 Subject: RFR(T): 8226899 Problemlist compiler/rtm tests In-Reply-To: <8af7e80a-db10-6b2d-86e1-ed2d86d9b724@linux.vnet.ibm.com> References: <7335f76d-5359-3a17-0dcf-2b2849c3cfd9@oracle.com> <22cfd2ae-c012-0738-d373-ea32831cd0ef@linux.vnet.ibm.com> <78fbe881-b1e4-c438-ebb6-a3c4bf22a610@oracle.com> <0436af29-9c84-aa8b-1bea-0520d023f78d@oracle.com> <8af7e80a-db10-6b2d-86e1-ed2d86d9b724@linux.vnet.ibm.com> Message-ID: Hi Gustavo, it happens not only w/ zgc, I've added the excerpt from .jtr to 8183263. -- Igor > On Aug 2, 2019, at 6:36 AM, Gustavo Romero wrote: > > Hi Vladimir! > > Thanks a lot. Hastily eyeballing I see I'm not testing with XX:+UseZGC. > Basically the expected transaction are not being aborted so the tests fail > in Oracle's CI. I'll have a closer look next week hopefully. > > Best regards, > Gustavo > > On 08/01/2019 05:42 PM, Vladimir Kozlov wrote: >> Hi Gustavo >> Most new failures links are in closed comments. >> I just added test output for latest failure from yesterday. >> Vladimir >> On 8/1/19 1:16 PM, Gustavo Romero wrote: >>> Hi Dan, >>> >>> On 08/01/2019 05:03 PM, Daniel D. Daugherty wrote: >>>> Hi Gustavo! >>>> >>>> Please take up the discussion with the Compiler team relative to: >>>> >>>> JDK-8183263 compiler/rtm tests fail on SKL hosts >>>> https://bugs.openjdk.java.net/browse/JDK-8183263 >>> >>> yep, I did see that bug. All comments predate my refactor (they are from 2017). >>> Only the last one from Robert Mckenna looks new, but I can't access the link >>> (it's Oracle internal only) and the comment is too short to be meaningful for >>> me. >>> >>> >>>> and you folks can figure out the underlying cause of what might >>>> be going wrong with these tests. >>>> >>>> For today, I have my Gatekeeping hat on and I'm just trying to >>>> reduce the number of failures that I have to sift through in >>>> the various Mach5 tiers... :-) >>> >>> Well, that's life. It's sad that TM/RTM defeated me again. >>> >>> Go for it ;) >>> >>> Cheers, >>> Gustavo >>> > From yumin.qi at gmail.com Fri Aug 2 17:37:27 2019 From: yumin.qi at gmail.com (yumin qi) Date: Fri, 2 Aug 2019 10:37:27 -0700 Subject: CFV: New HotSpot Group Member: Jiangli Zhou In-Reply-To: <30c09194-6557-5ff6-caa0-37f976e75618@oracle.com> References: <30c09194-6557-5ff6-caa0-37f976e75618@oracle.com> Message-ID: vote: yes On Tue, Jul 30, 2019, 2:49 PM Calvin Cheung wrote: > Greetings, > > I hereby nominate Jiangli Zhou (OpenJDK user name: jiangli) to > Membership in the HotSpot Group. > > Jiangli is a JDK project and JDK update project reviewer. She is > currently a member of Google Java Platform team and has contributed over > 100 changesets[3] to Hotspot JVM in various areas since 2011. In recent > years, she has been mainly focusing on the runtime memory footprint > reduction and Class Data Sharing. > > Votes are due by August 13, 2019, 15:00 PDT. > > Only current Members of the HotSpot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thanks! > > Calvin > > [1] http://openjdk.java.net/census#hotspot > > [2] http://openjdk.java.net/groups/#member-vote > > [3] > > http://hg.openjdk.java.net/jdk/jdk/log?revcount=300&rev=(author(jiangli))+and+not+merge() > > From thomas.schatzl at oracle.com Fri Aug 2 19:29:41 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Fri, 2 Aug 2019 12:29:41 -0700 Subject: CFV: New HotSpot Group Member: Jiangli Zhou In-Reply-To: <30c09194-6557-5ff6-caa0-37f976e75618@oracle.com> References: <30c09194-6557-5ff6-caa0-37f976e75618@oracle.com> Message-ID: <73de4d0a-377c-b154-3915-75845ab19f5d@oracle.com> Vote: yes On 30.07.19 14:48, Calvin Cheung wrote: > Greetings, > > I hereby nominate Jiangli Zhou (OpenJDK user name: jiangli) to > Membership in the HotSpot Group. > > Jiangli is a JDK project and JDK update project reviewer. She is > currently a member of Google Java Platform team and has contributed over > 100 changesets[3] to Hotspot JVM in various areas since 2011. In recent > years, she has been mainly focusing on the runtime memory footprint > reduction and Class Data Sharing. > > Votes are due by August 13, 2019, 15:00 PDT. > > Only current Members of the HotSpot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thanks! > > Calvin > > [1] http://openjdk.java.net/census#hotspot > > [2] http://openjdk.java.net/groups/#member-vote > > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=300&rev=(author(jiangli))+and+not+merge() > > From kim.barrett at oracle.com Fri Aug 2 20:01:21 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 2 Aug 2019 16:01:21 -0400 Subject: RFR: 8227054: ServiceThread needs to know about all OopStorage objects In-Reply-To: References: <8181924C-36E6-4B91-9567-150F00286241@oracle.com> Message-ID: <74C738E7-CBDD-4891-ABD6-F8E023372508@oracle.com> > On Aug 2, 2019, at 9:29 AM, Erik ?sterlund wrote: > > Hi Kim, > > I had a look at the patch. Personally I'm not a big fan of using macro tricks. Perhaps because it's in caps, which makes me read the code in my head with a loud screaming voice, with a slightly angry italian accent. And I don't even know italian - it is crazy. > > Anyway, I have come up with an alternative solution that is worth considering, I think, due to its simplicity. > > Step 1: Move all oop storages to a new file, and add a utility for iterating over them: > > webrev: http://cr.openjdk.java.net/~eosterlund/8227054/webrev.00/ > > This is quite straight forward. A new OopStorageSet AllStatic class has all oop storages, and offers some iterators. > > Step 2: Change weak processor to automatically process oop storages: > > webrev:http://cr.openjdk.java.net/~eosterlund/8227054/webrev.01/ > incremental: http://cr.openjdk.java.net/~eosterlund/8227054/webrev.00_01/ > > I noticed that the weak processor has an enum with all phases, but pretty much always dealt with oop storage phases differently, with various checks if it is an oop storage phase, do something different, or assert that things are only done in an oop storage phase. > So I made processing of oop storages use the new iterators instead, and opt out from the enum macro dance. > > To add a new OopStorage, you add it to the OopStorageSet by plugging in a declaration in OopStorageSet::StrongOopStorageSet or OopStorageSet::WeakOopStorageSet depending on strength, stick in a getter if you need direct access, and create an instance in OopStorageSet::initialize() - 3 lines in total. This is 2 lines less than your approach, but I think that is okay for the added simplicity. > > In total, this patch removes more code than it introduces. > > Thoughts? I prefer code that doesn't invoke undefined behavior, even if it might work (or even probably works) in practice. And an iterator whose initial "current" is invalid? You think *macros* are confusing? Separating the oopstorages from the serial weak phases is interesting. I think I like that idea. From erik.osterlund at oracle.com Sat Aug 3 10:36:39 2019 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Sat, 3 Aug 2019 12:36:39 +0200 Subject: RFR: 8227054: ServiceThread needs to know about all OopStorage objects In-Reply-To: <74C738E7-CBDD-4891-ABD6-F8E023372508@oracle.com> References: <8181924C-36E6-4B91-9567-150F00286241@oracle.com> <74C738E7-CBDD-4891-ABD6-F8E023372508@oracle.com> Message-ID: <60099477-9AD4-4EFC-AA6F-6EF19D840E67@oracle.com> Hi Kim, On 2 Aug 2019, at 22:01, Kim Barrett wrote: >> On Aug 2, 2019, at 9:29 AM, Erik ?sterlund wrote: >> >> Hi Kim, >> >> I had a look at the patch. Personally I'm not a big fan of using macro tricks. Perhaps because it's in caps, which makes me read the code in my head with a loud screaming voice, with a slightly angry italian accent. And I don't even know italian - it is crazy. >> >> Anyway, I have come up with an alternative solution that is worth considering, I think, due to its simplicity. >> >> Step 1: Move all oop storages to a new file, and add a utility for iterating over them: >> >> webrev: http://cr.openjdk.java.net/~eosterlund/8227054/webrev.00/ >> >> This is quite straight forward. A new OopStorageSet AllStatic class has all oop storages, and offers some iterators. >> >> Step 2: Change weak processor to automatically process oop storages: >> >> webrev:http://cr.openjdk.java.net/~eosterlund/8227054/webrev.01/ >> incremental: http://cr.openjdk.java.net/~eosterlund/8227054/webrev.00_01/ >> >> I noticed that the weak processor has an enum with all phases, but pretty much always dealt with oop storage phases differently, with various checks if it is an oop storage phase, do something different, or assert that things are only done in an oop storage phase. >> So I made processing of oop storages use the new iterators instead, and opt out from the enum macro dance. >> >> To add a new OopStorage, you add it to the OopStorageSet by plugging in a declaration in OopStorageSet::StrongOopStorageSet or OopStorageSet::WeakOopStorageSet depending on strength, stick in a getter if you need direct access, and create an instance in OopStorageSet::initialize() - 3 lines in total. This is 2 lines less than your approach, but I think that is okay for the added simplicity. >> >> In total, this patch removes more code than it introduces. >> >> Thoughts? > > I prefer code that doesn't invoke undefined behavior, even if it > might work (or even probably works) in practice. Me too, unless it?s aliasing rules, which I don?t mind violating given the chance. Mind elaborating what you think I missed? > And an iterator whose initial "current" is invalid? You think > *macros* are confusing? That?s Java style iterators I guess. You call next until you can?t. Before you called next the first time, there is no current element that has been handed out. I don?t mind changing the iterator style though if you think that is confusing. It is my preferred style for simple linear iteration. > Separating the oopstorages from the serial weak phases is interesting. > I think I like that idea. Glad you liked that part! Thanks, /Erik From kim.barrett at oracle.com Mon Aug 5 02:35:31 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 4 Aug 2019 22:35:31 -0400 Subject: RFR: 8227054: ServiceThread needs to know about all OopStorage objects In-Reply-To: <60099477-9AD4-4EFC-AA6F-6EF19D840E67@oracle.com> References: <8181924C-36E6-4B91-9567-150F00286241@oracle.com> <74C738E7-CBDD-4891-ABD6-F8E023372508@oracle.com> <60099477-9AD4-4EFC-AA6F-6EF19D840E67@oracle.com> Message-ID: > On Aug 3, 2019, at 6:36 AM, Erik Osterlund wrote: > On 2 Aug 2019, at 22:01, Kim Barrett wrote: >> [?] >> I prefer code that doesn't invoke undefined behavior, even if it >> might work (or even probably works) in practice. > > Me too, unless it?s aliasing rules, which I don?t mind violating given the chance. Mind elaborating what you think I missed? "... unless it?s aliasing rules, which I don?t mind violating given the chance." "... worth considering, I think, due to its simplicity." Those two phrases cannot legitimately be used to describe the same code. Code that uses (and indeed fundamentally relies on) casts, especially reinterpret_casts, is never simple. Please don't casually violate the aliasing rules, and carefully document when it's being done and why. reinterpret_casts (by whatever spelling) are a huge punch in the nose for the type system. A multitude of sins can be hidden, sometimes unintentionally and to our significant detriment. We resort to them *way* too often. The problem being dealt with here doesn't even come close to being one of those necessary evils where we (think we) must break the rules, so no, I don't like or accept that proposal. Also, when looking at that code the disreputable casts so drew my eye that I very nearly missed another problem: 47 static StrongOopStorageSet _strong; 48 static WeakOopStorageSet _weak; Nothing requires those objects be placed in memory in such a way that the "all" iterator will work. > >> And an iterator whose initial "current" is invalid? You think >> *macros* are confusing? > > That?s Java style iterators I guess. You call next until you can?t. Before you called next the first time, there is no current element that has been handed out. I don?t mind changing the iterator style though if you think that is confusing. It is my preferred style for simple linear iteration. In this case that idiom seems like it expends additional effort to potentially hide bugs. It also seems less convenient to use, though if one uses implicit booleans (as the proposed code does), that disadvantage is nullified. (I've had many occasions to want to use the declaration form of a condition, but haven't because there were strong complaints when I first tried doing so, and I've since seen it objected to when others tried. But I found some recently added, so maybe that's no longer true? Or maybe the previous complainers didn't notice.) I have another version in progress that doesn't use x-macros and uses somewhat fewer macros (though not none, since I really dislike boiler-plate). It isn't finished because of a power shutdown in the office over the weekend. From erik.osterlund at oracle.com Mon Aug 5 07:33:08 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Mon, 5 Aug 2019 09:33:08 +0200 Subject: RFR: 8227054: ServiceThread needs to know about all OopStorage objects In-Reply-To: References: <8181924C-36E6-4B91-9567-150F00286241@oracle.com> <74C738E7-CBDD-4891-ABD6-F8E023372508@oracle.com> <60099477-9AD4-4EFC-AA6F-6EF19D840E67@oracle.com> Message-ID: Hi Kim, On 2019-08-05 04:35, Kim Barrett wrote: > "... unless it?s aliasing rules, which I don?t mind violating given > the chance." > > "... worth considering, I think, due to its simplicity." > > Those two phrases cannot legitimately be used to describe the same > code. Code that uses (and indeed fundamentally relies on) casts, > especially reinterpret_casts, is never simple. > > Please don't casually violate the aliasing rules, and carefully > document when it's being done and why. reinterpret_casts (by whatever > spelling) are a huge punch in the nose for the type system. A > multitude of sins can be hidden, sometimes unintentionally and to our > significant detriment. We resort to them *way* too often. > > The problem being dealt with here doesn't even come close to being one > of those necessary evils where we (think we) must break the rules, so > no, I don't like or accept that proposal. This conversation whether we should or should not care about the aliasing rules has been repeated many times. And the answer is always the same: we should not care about aliasing rules. Summary of why: * HotSpot inherently can't comply to the aliasing rules, as those rules are only defined in terms of C++ accesses interacting with each other. Since we JIT code performing accesses on the same memory as the C++ code, the aliasing rules can inherently never be trusted, as our interactions cross language barriers. * Compilers used to compile HotSpot have all been told to ignore aliasing rules, and hence the behaviour of doing so is well defined. Because it has to be. If a compiler can't ignore aliasing, it can't compile HotSpot. * Even if we were not inherently tied to ignore these aliasing rules, a significantly large part of HotSpot relies on it, and we can't realistically get rid of that reliance to turn the flags off. At least not by taking huge risk that we think we caught all the places, which would be rather irresponsible. * Even if we could magically get rid of this reliance and somehow rewrite all code to conform with the aliasing rules, verify that we solved it all, and switch the compiler flags ignoring aliasing off, which would be a crazy amount of work, and be very risky, the benefits are seemingly unclear. They were introduced to allow compiler optimizations. I have not seen studies with numbers showing that it improves things. I have heard vague statements that it does, but not with numbers. I have found one study - a paper from Purdue where they had run with and without -fstrict-aliasing on a number of benchmarks, and observed no benefit. And most our time is spent in JIT:ed code, so I would expect even less if anything. * Given the above, HotSpot does not, can not, and never will care about aliasing. They doe not make sense in our context, and the rules simply don't apply. Therefore, we can and should ignore the aliasing rules. Caring about them "sometimes" makes no sense to me. That's why I say I don't mind violating the aliasing rules, because they simply don't apply to HotSpot. > Also, when looking at that code the disreputable casts so drew my eye > that I very nearly missed another problem: > > 47 static StrongOopStorageSet _strong; > 48 static WeakOopStorageSet _weak; > > Nothing requires those objects be placed in memory in such a way that > the "all" iterator will work. I agree that reliance is unnecessary, and was not fond of that myself either. Solved by wrapping _strong and _weak in a struct. Incremental: http://cr.openjdk.java.net/~eosterlund/8227054/webrev.01_02/ Full: http://cr.openjdk.java.net/~eosterlund/8227054/webrev.02/ >> >>> And an iterator whose initial "current" is invalid? You think >>> *macros* are confusing? >> >> That?s Java style iterators I guess. You call next until you can?t. Before you called next the first time, there is no current element that has been handed out. I don?t mind changing the iterator style though if you think that is confusing. It is my preferred style for simple linear iteration. > > In this case that idiom seems like it expends additional effort to > potentially hide bugs. I don't know what you mean by that. > It also seems less convenient to use, though if one uses implicit > booleans (as the proposed code does), that disadvantage is nullified. > (I've had many occasions to want to use the declaration form of a > condition, but haven't because there were strong complaints when I > first tried doing so, and I've since seen it objected to when others > tried. But I found some recently added, so maybe that's no longer > true? Or maybe the previous complainers didn't notice.) Yeah this style is indeed only nice when using the declaration form of a condition. If anyone thinks that should not be allowed for some reason, I don't have strong opinions about having a different iterator style. > I have another version in progress that doesn't use x-macros and uses > somewhat fewer macros (though not none, since I really dislike > boiler-plate). It isn't finished because of a power shutdown in the > office over the weekend. Okay. I'm looking forward to seeing what you have cooked up. Thanks, /Erik From coleen.phillimore at oracle.com Mon Aug 5 13:23:26 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 5 Aug 2019 09:23:26 -0400 Subject: RFR: 8227054: ServiceThread needs to know about all OopStorage objects In-Reply-To: References: <8181924C-36E6-4B91-9567-150F00286241@oracle.com> <74C738E7-CBDD-4891-ABD6-F8E023372508@oracle.com> <60099477-9AD4-4EFC-AA6F-6EF19D840E67@oracle.com> Message-ID: Hi, Both versions of this change has the part that I like, ie removing oopStorage initialization and most knowledge from the client code. While I don't like capital letters either, X macros make sense and we have them everywhere.?? I have to admit that this threw me and I was not happy that it was going to take me time to puzzle out this trick, which now I see is something that runs off the end of a struct.? please dont. 47 static StrongOopStorageSet _strong; 48 static WeakOopStorageSet _weak; 49 50 static OopStorage** strong_oopstorage_set() { return reinterpret_cast(&_strong); } 51 static OopStorage** weak_oopstorage_set() { return reinterpret_cast(&_weak); } 52 static OopStorage** all_oopstorage_set() { return strong_oopstorage_set(); } 53 The new version of this isn't that much nicer to look at and still has the reinterpret cast. The iterator and cpp file changes are nicer though. This seems to be a lot of effort to not repeat listing any of the 6 total oop storages that we have, which could be done in the .hpp file alongside the weak/strong classifications. I look forward to seeing Kim's next version. Coleen On 8/5/19 3:33 AM, Erik ?sterlund wrote: > Hi Kim, > > On 2019-08-05 04:35, Kim Barrett wrote: >> "... unless it?s aliasing rules, which I don?t mind violating given >> the chance." >> >> "... worth considering, I think, due to its simplicity." >> >> Those two phrases cannot legitimately be used to describe the same >> code.? Code that uses (and indeed fundamentally relies on) casts, >> especially reinterpret_casts, is never simple. >> >> Please don't casually violate the aliasing rules, and carefully >> document when it's being done and why.? reinterpret_casts (by whatever >> spelling) are a huge punch in the nose for the type system.? A >> multitude of sins can be hidden, sometimes unintentionally and to our >> significant detriment.? We resort to them *way* too often. >> >> The problem being dealt with here doesn't even come close to being one >> of those necessary evils where we (think we) must break the rules, so >> no, I don't like or accept that proposal. > > This conversation whether we should or should not care about the > aliasing rules has been repeated many times. And the answer is always > the same: we should not care about aliasing rules. Summary of why: > > * HotSpot inherently can't comply to the aliasing rules, as those > rules are only defined in terms of C++ accesses interacting with each > other. Since we JIT code performing accesses on the same memory as the > C++ code, the aliasing rules can inherently never be trusted, as our > interactions cross language barriers. > * Compilers used to compile HotSpot have all been told to ignore > aliasing rules, and hence the behaviour of doing so is well defined. > Because it has to be. If a compiler can't ignore aliasing, it can't > compile HotSpot. > * Even if we were not inherently tied to ignore these aliasing rules, > a significantly large part of HotSpot relies on it, and we can't > realistically get rid of that reliance to turn the flags off. At least > not by taking huge risk that we think we caught all the places, which > would be rather irresponsible. > * Even if we could magically get rid of this reliance and somehow > rewrite all code to conform with the aliasing rules, verify that we > solved it all, and switch the compiler flags ignoring aliasing off, > which would be a crazy amount of work, and be very risky, the benefits > are seemingly unclear. They were introduced to allow compiler > optimizations. I have not seen studies with numbers showing that it > improves things. I have heard vague statements that it does, but not > with numbers. I have found one study - a paper from Purdue where they > had run with and without -fstrict-aliasing on a number of benchmarks, > and observed no benefit. And most our time is spent in JIT:ed code, so > I would expect even less if anything. > * Given the above, HotSpot does not, can not, and never will care > about aliasing. They doe not make sense in our context, and the rules > simply don't apply. Therefore, we can and should ignore the aliasing > rules. Caring about them "sometimes" makes no sense to me. That's why > I say I don't mind violating the aliasing rules, because they simply > don't apply to HotSpot. > >> Also, when looking at that code the disreputable casts so drew my eye >> that I very nearly missed another problem: >> >> ?? 47?? static StrongOopStorageSet _strong; >> ?? 48?? static WeakOopStorageSet _weak; >> >> Nothing requires those objects be placed in memory in such a way that >> the "all" iterator will work. > > I agree that reliance is unnecessary, and was not fond of that myself > either. Solved by wrapping _strong and _weak in a struct. > > Incremental: > http://cr.openjdk.java.net/~eosterlund/8227054/webrev.01_02/ > > Full: > http://cr.openjdk.java.net/~eosterlund/8227054/webrev.02/ > >>> >>>> And an iterator whose initial "current" is invalid?? You think >>>> *macros* are confusing? >>> >>> That?s Java style iterators I guess. You call next until you can?t. >>> Before you called next the first time, there is no current element >>> that has been handed out. I don?t mind changing the iterator style >>> though if you think that is confusing. It is my preferred style for >>> simple linear iteration. >> >> In this case that idiom seems like it expends additional effort to >> potentially hide bugs. > > I don't know what you mean by that. > >> It also seems less convenient to use, though if one uses implicit >> booleans (as the proposed code does), that disadvantage is nullified. >> (I've had many occasions to want to use the declaration form of a >> condition, but haven't because there were strong complaints when I >> first tried doing so, and I've since seen it objected to when others >> tried.? But I found some recently added, so maybe that's no longer >> true?? Or maybe the previous complainers didn't notice.) > > Yeah this style is indeed only nice when using the declaration form of > a condition. If anyone thinks that should not be allowed for some > reason, I don't have strong opinions about having a different iterator > style. > >> I have another version in progress that doesn't use x-macros and uses >> somewhat fewer macros (though not none, since I really dislike >> boiler-plate).? It isn't finished because of a power shutdown in the >> office over the weekend. > > Okay. I'm looking forward to seeing what you have cooked up. > > Thanks, > /Erik From erik.osterlund at oracle.com Mon Aug 5 13:48:44 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Mon, 5 Aug 2019 15:48:44 +0200 Subject: RFR: 8227054: ServiceThread needs to know about all OopStorage objects In-Reply-To: References: <8181924C-36E6-4B91-9567-150F00286241@oracle.com> <74C738E7-CBDD-4891-ABD6-F8E023372508@oracle.com> <60099477-9AD4-4EFC-AA6F-6EF19D840E67@oracle.com> Message-ID: <164151e7-fec4-8c61-f247-3d5a41c910c1@oracle.com> Hi Coleen, On 2019-08-05 15:23, coleen.phillimore at oracle.com wrote: > > Hi, > > Both versions of this change has the part that I like, ie removing > oopStorage initialization and most knowledge from the client code. > > While I don't like capital letters either, X macros make sense and we > have them everywhere.?? I have to admit that this threw me and I was > not happy that it was going to take me time to puzzle out this trick, > which now I see is something that runs off the end of a struct.? > please dont. > > 47 static StrongOopStorageSet _strong; > 48 static WeakOopStorageSet _weak; > 49 > 50 static OopStorage** strong_oopstorage_set() { return reinterpret_cast(&_strong); } > 51 static OopStorage** weak_oopstorage_set() { return reinterpret_cast(&_weak); } > 52 static OopStorage** all_oopstorage_set() { return strong_oopstorage_set(); } > 53 > The new version of this isn't that much nicer to look at and still has > the reinterpret cast. > > The iterator and cpp file changes are nicer though. > > This seems to be a lot of effort to not repeat listing any of the 6 > total oop storages that we have, which could be done in the .hpp file > alongside the weak/strong classifications. Thanks for having a look. I agree I would be happier if this could be done without reinterpret_cast. It's obviously possible with some extra boiler plate, but I know Kim doesn't like boilerplate. But yeah, as you say, there are very few of these OopStorage instances, so I have no strong opinions about adding that boilerplate (with an assert so you can't miss it). I was mostly trying to show that there are alternatives to the macro metaprogramming? + enum approach, as a direction. > I look forward to seeing Kim's next version. Me too! Thanks, /Erik > Coleen > > On 8/5/19 3:33 AM, Erik ?sterlund wrote: >> Hi Kim, >> >> On 2019-08-05 04:35, Kim Barrett wrote: >>> "... unless it?s aliasing rules, which I don?t mind violating given >>> the chance." >>> >>> "... worth considering, I think, due to its simplicity." >>> >>> Those two phrases cannot legitimately be used to describe the same >>> code.? Code that uses (and indeed fundamentally relies on) casts, >>> especially reinterpret_casts, is never simple. >>> >>> Please don't casually violate the aliasing rules, and carefully >>> document when it's being done and why.? reinterpret_casts (by whatever >>> spelling) are a huge punch in the nose for the type system.? A >>> multitude of sins can be hidden, sometimes unintentionally and to our >>> significant detriment.? We resort to them *way* too often. >>> >>> The problem being dealt with here doesn't even come close to being one >>> of those necessary evils where we (think we) must break the rules, so >>> no, I don't like or accept that proposal. >> >> This conversation whether we should or should not care about the >> aliasing rules has been repeated many times. And the answer is always >> the same: we should not care about aliasing rules. Summary of why: >> >> * HotSpot inherently can't comply to the aliasing rules, as those >> rules are only defined in terms of C++ accesses interacting with each >> other. Since we JIT code performing accesses on the same memory as >> the C++ code, the aliasing rules can inherently never be trusted, as >> our interactions cross language barriers. >> * Compilers used to compile HotSpot have all been told to ignore >> aliasing rules, and hence the behaviour of doing so is well defined. >> Because it has to be. If a compiler can't ignore aliasing, it can't >> compile HotSpot. >> * Even if we were not inherently tied to ignore these aliasing rules, >> a significantly large part of HotSpot relies on it, and we can't >> realistically get rid of that reliance to turn the flags off. At >> least not by taking huge risk that we think we caught all the places, >> which would be rather irresponsible. >> * Even if we could magically get rid of this reliance and somehow >> rewrite all code to conform with the aliasing rules, verify that we >> solved it all, and switch the compiler flags ignoring aliasing off, >> which would be a crazy amount of work, and be very risky, the >> benefits are seemingly unclear. They were introduced to allow >> compiler optimizations. I have not seen studies with numbers showing >> that it improves things. I have heard vague statements that it does, >> but not with numbers. I have found one study - a paper from Purdue >> where they had run with and without -fstrict-aliasing on a number of >> benchmarks, and observed no benefit. And most our time is spent in >> JIT:ed code, so I would expect even less if anything. >> * Given the above, HotSpot does not, can not, and never will care >> about aliasing. They doe not make sense in our context, and the rules >> simply don't apply. Therefore, we can and should ignore the aliasing >> rules. Caring about them "sometimes" makes no sense to me. That's why >> I say I don't mind violating the aliasing rules, because they simply >> don't apply to HotSpot. >> >>> Also, when looking at that code the disreputable casts so drew my eye >>> that I very nearly missed another problem: >>> >>> ?? 47?? static StrongOopStorageSet _strong; >>> ?? 48?? static WeakOopStorageSet _weak; >>> >>> Nothing requires those objects be placed in memory in such a way that >>> the "all" iterator will work. >> >> I agree that reliance is unnecessary, and was not fond of that myself >> either. Solved by wrapping _strong and _weak in a struct. >> >> Incremental: >> http://cr.openjdk.java.net/~eosterlund/8227054/webrev.01_02/ >> >> Full: >> http://cr.openjdk.java.net/~eosterlund/8227054/webrev.02/ >> >>>> >>>>> And an iterator whose initial "current" is invalid?? You think >>>>> *macros* are confusing? >>>> >>>> That?s Java style iterators I guess. You call next until you can?t. >>>> Before you called next the first time, there is no current element >>>> that has been handed out. I don?t mind changing the iterator style >>>> though if you think that is confusing. It is my preferred style for >>>> simple linear iteration. >>> >>> In this case that idiom seems like it expends additional effort to >>> potentially hide bugs. >> >> I don't know what you mean by that. >> >>> It also seems less convenient to use, though if one uses implicit >>> booleans (as the proposed code does), that disadvantage is nullified. >>> (I've had many occasions to want to use the declaration form of a >>> condition, but haven't because there were strong complaints when I >>> first tried doing so, and I've since seen it objected to when others >>> tried.? But I found some recently added, so maybe that's no longer >>> true?? Or maybe the previous complainers didn't notice.) >> >> Yeah this style is indeed only nice when using the declaration form >> of a condition. If anyone thinks that should not be allowed for some >> reason, I don't have strong opinions about having a different >> iterator style. >> >>> I have another version in progress that doesn't use x-macros and uses >>> somewhat fewer macros (though not none, since I really dislike >>> boiler-plate).? It isn't finished because of a power shutdown in the >>> office over the weekend. >> >> Okay. I'm looking forward to seeing what you have cooked up. >> >> Thanks, >> /Erik > From coleen.phillimore at oracle.com Mon Aug 5 17:56:19 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 5 Aug 2019 13:56:19 -0400 Subject: RFR (S) 8228753: Deprecate -XX:FieldsAllocationStyle product option and CompactiFields Message-ID: <67d75ea2-42a9-a4d3-01a0-8efa816d96d5@oracle.com> 8228753: Deprecate -XX:FieldsAllocationStyle product option 8228749: Deprecate product flag -XX:CompactFields CSRs approved.? See bug and link for more details.? Ran tier1-3 on linux-x64-debug. open webrev at http://cr.openjdk.java.net/~coleenp/2019/8228753.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8228753 Thanks, Coleen From vladimir.kozlov at oracle.com Mon Aug 5 18:03:00 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 5 Aug 2019 11:03:00 -0700 Subject: RFR (S) 8228753: Deprecate -XX:FieldsAllocationStyle product option and CompactiFields In-Reply-To: <67d75ea2-42a9-a4d3-01a0-8efa816d96d5@oracle.com> References: <67d75ea2-42a9-a4d3-01a0-8efa816d96d5@oracle.com> Message-ID: Good Thanks Vladimir > On Aug 5, 2019, at 10:56 AM, coleen.phillimore at oracle.com wrote: > > 8228753: Deprecate -XX:FieldsAllocationStyle product option > 8228749: Deprecate product flag -XX:CompactFields > > CSRs approved. See bug and link for more details. Ran tier1-3 on linux-x64-debug. > > open webrev at http://cr.openjdk.java.net/~coleenp/2019/8228753.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8228753 > > Thanks, > Coleen From shade at redhat.com Mon Aug 5 18:10:54 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 5 Aug 2019 20:10:54 +0200 Subject: RFR (S) 8228753: Deprecate -XX:FieldsAllocationStyle product option and CompactiFields In-Reply-To: <67d75ea2-42a9-a4d3-01a0-8efa816d96d5@oracle.com> References: <67d75ea2-42a9-a4d3-01a0-8efa816d96d5@oracle.com> Message-ID: <2d25259b-f88a-4fa7-d52a-15bdedb08420@redhat.com> On 8/5/19 7:56 PM, coleen.phillimore at oracle.com wrote: > 8228753: Deprecate -XX:FieldsAllocationStyle product option > 8228749: Deprecate product flag -XX:CompactFields > > CSRs approved.? See bug and link for more details.? Ran tier1-3 on linux-x64-debug. > > open webrev at http://cr.openjdk.java.net/~coleenp/2019/8228753.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8228753 Yes, please. -- Thanks, -Aleksey From coleen.phillimore at oracle.com Mon Aug 5 18:14:13 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 5 Aug 2019 14:14:13 -0400 Subject: RFR (S) 8228753: Deprecate -XX:FieldsAllocationStyle product option and CompactiFields In-Reply-To: <2d25259b-f88a-4fa7-d52a-15bdedb08420@redhat.com> References: <67d75ea2-42a9-a4d3-01a0-8efa816d96d5@oracle.com> <2d25259b-f88a-4fa7-d52a-15bdedb08420@redhat.com> Message-ID: Thanks Vladimir and Aleksey! Coleen On 8/5/19 2:10 PM, Aleksey Shipilev wrote: > On 8/5/19 7:56 PM, coleen.phillimore at oracle.com wrote: >> 8228753: Deprecate -XX:FieldsAllocationStyle product option >> 8228749: Deprecate product flag -XX:CompactFields >> >> CSRs approved.? See bug and link for more details.? Ran tier1-3 on linux-x64-debug. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/2019/8228753.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8228753 > Yes, please. > From coleen.phillimore at oracle.com Mon Aug 5 22:38:40 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 5 Aug 2019 18:38:40 -0400 Subject: RFR: JDK-8227021: VM fails if any sun.boot.library.path paths are longer than JVM_MAXPATHLEN In-Reply-To: References: <25234969-2215-57e9-d8c5-d97b5669ebb1@oracle.com> <5ba808b0-ae52-0d0a-b84b-fc34df35475d@oracle.com> Message-ID: <7d80b0e1-1950-b502-dd24-f9522e869641@oracle.com> http://cr.openjdk.java.net/~afarley/8227021.2/webrev/src/hotspot/share/runtime/os.cpp.frames.html This is code is unnecessarily hard to read and understand: 1329 char** os::split_path(const char* path, size_t* n) { 1330 size_t pathmod = (size_t)0; 1331 if (n != NULL) { 1332 pathmod = *n; 1333 } 1334 *n = (size_t)0; It appears that 'n' is both an input and output parameter of this function.? Can you just make it another input parameter with some descriptive name.? Is it the length of the library name that you're looking for?? "pathmod" is huh? Then you don't have to check if someone has passed NULL.? There's only one caller to this from what I see. 1352 char** opath = (char**) NEW_C_HEAP_ARRAY(char*, count, mtInternal); 1353 if (opath == NULL) { 1354 return NULL; 1355 } Not your change but this calls vm_exit_out_of_memory() if NEW_C_HEAP_ARRAY fails.? It doesn't return NULL so you don't have to check. 1375 char* s = (char*)NEW_C_HEAP_ARRAY(char, len + 1, mtInternal); Here you want to use NEW_C_HEAP_ARRAY_RETURN_NULL so you can check for null and free memory. The rest seems okay. thanks, Coleen On 7/31/19 5:01 AM, Adam Farley8 wrote: > Hi All, > > Reviewers requested for the change below. > > @David - Agreed. Would you be prepared to sponsor the change? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8227021 > Webrev: http://cr.openjdk.java.net/~afarley/8227021.2/webrev/ > > Best Regards > > Adam Farley > IBM Runtimes > > P.S. Remembered to add the links this time. :) > > > David Holmes wrote on 30/07/2019 03:37:53: > >> From: David Holmes >> To: Adam Farley8 >> Cc: hotspot-dev at openjdk.java.net, serviceability-dev >> >> Date: 30/07/2019 03:38 >> Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path >> paths are longer than JVM_MAXPATHLEN >> >> Hi Adam, >> >> On 25/07/2019 3:57 am, Adam Farley8 wrote: >>> Hi David, >>> >>> Welcome back. :) >> Thanks. Sorry for the delay in getting back to this. >> >> I like .v2 as it is much simpler (notwithstanding freeing the already >> allocated arrays adds some complexity - thanks for fixing that). >> >> I'm still not sure we can't optimise things better for unchangeable >> properties like the boot libary path, but that's another RFE. >> >> Thanks, >> David >> > 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 coleen.phillimore at oracle.com Mon Aug 5 22:51:23 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 5 Aug 2019 15:51:23 -0700 (PDT) Subject: RFR: 8228902: add os::dll_load to the unified logging os category In-Reply-To: References: Message-ID: <08131940-52e2-6470-4b56-c7df4eec38a6@oracle.com> This looks good. Coleen On 8/2/19 4:22 AM, Baesken, Matthias wrote: > Hello, I missed the shared library loads in the UL (os category) . > So I created a small webrev and added the info . > > Please review ! > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8228902 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8228902.0/ > > > Thanks, Matthias From jesper.wilhelmsson at oracle.com Tue Aug 6 01:15:00 2019 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Tue, 6 Aug 2019 03:15:00 +0200 Subject: CFV: New HotSpot Group Member: Jiangli Zhou In-Reply-To: <30c09194-6557-5ff6-caa0-37f976e75618@oracle.com> References: <30c09194-6557-5ff6-caa0-37f976e75618@oracle.com> Message-ID: <2F497E4C-1E88-4541-8F7E-06109035457B@oracle.com> Vote: Yes /Jesper > On 30 Jul 2019, at 23:48, Calvin Cheung wrote: > > Greetings, > > I hereby nominate Jiangli Zhou (OpenJDK user name: jiangli) to Membership in the HotSpot Group. > > Jiangli is a JDK project and JDK update project reviewer. She is currently a member of Google Java Platform team and has contributed over 100 changesets[3] to Hotspot JVM in various areas since 2011. In recent years, she has been mainly focusing on the runtime memory footprint reduction and Class Data Sharing. > > Votes are due by August 13, 2019, 15:00 PDT. > > Only current Members of the HotSpot Group [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thanks! > > Calvin > > [1] http://openjdk.java.net/census#hotspot > > [2] http://openjdk.java.net/groups/#member-vote > > [3] http://hg.openjdk.java.net/jdk/jdk/log?revcount=300&rev=(author(jiangli))+and+not+merge() > From david.holmes at oracle.com Tue Aug 6 01:49:47 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 6 Aug 2019 11:49:47 +1000 Subject: RFR (S): 8228857: Refactor PlatformMonitor into PlatformMutex and PlatformMonitor In-Reply-To: References: Message-ID: Ping! On 2/08/2019 9:03 am, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8228857 > webrev: http://cr.openjdk.java.net/~dholmes/8228857/webrev/ > > As suggested by Per Liden when PlatformMonitor was introduced by > JDK-8210832 we should refactor PlatformMonitor into a simpler > PlatformMutex extended by PlatformMonitor. That would potentially allow > other synchronization objects e.g. Zlocks, to be replaced by a suitable > PlatformX class, and allows us to redefine JVM_RawMonitor support to use > it (forthcoming change). > > The refactoring would be obvious and simple if not for the macOS PThread > allocation bug workaround. I had to change the Posix variant so that we > only use the Impl helper class on macOS, so that we can separate the > allocation of the pthread_mutex_t and pthread_cond_t. For macOS both get > allocated in the PlatformMutex. > > There are not actual usage changes in this RFE. > > Testing: mach5 tiers 1-3 > > Thanks, > David > ----- From dean.long at oracle.com Tue Aug 6 02:32:07 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 5 Aug 2019 19:32:07 -0700 Subject: RFR (S): 8228857: Refactor PlatformMonitor into PlatformMutex and PlatformMonitor In-Reply-To: References: Message-ID: <19b16402-dc69-a3c5-a413-77478b7bde3e@oracle.com> Looks good to me. dl On 8/5/19 6:49 PM, David Holmes wrote: > Ping! > > On 2/08/2019 9:03 am, David Holmes wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8228857 >> webrev: http://cr.openjdk.java.net/~dholmes/8228857/webrev/ >> >> As suggested by Per Liden when PlatformMonitor was introduced by >> JDK-8210832 we should refactor PlatformMonitor into a simpler >> PlatformMutex extended by PlatformMonitor. That would potentially >> allow other synchronization objects e.g. Zlocks, to be replaced by a >> suitable PlatformX class, and allows us to redefine JVM_RawMonitor >> support to use it (forthcoming change). >> >> The refactoring would be obvious and simple if not for the macOS >> PThread allocation bug workaround. I had to change the Posix variant >> so that we only use the Impl helper class on macOS, so that we can >> separate the allocation of the pthread_mutex_t and pthread_cond_t. >> For macOS both get allocated in the PlatformMutex. >> >> There are not actual usage changes in this RFE. >> >> Testing: mach5 tiers 1-3 >> >> Thanks, >> David >> ----- From david.holmes at oracle.com Tue Aug 6 03:00:33 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 6 Aug 2019 13:00:33 +1000 Subject: RFR (S): 8228857: Refactor PlatformMonitor into PlatformMutex and PlatformMonitor In-Reply-To: <19b16402-dc69-a3c5-a413-77478b7bde3e@oracle.com> References: <19b16402-dc69-a3c5-a413-77478b7bde3e@oracle.com> Message-ID: <3540721b-4edb-f216-1c97-226ea7f9bd57@oracle.com> Thanks Dean! David On 6/08/2019 12:32 pm, dean.long at oracle.com wrote: > Looks good to me. > > dl > > On 8/5/19 6:49 PM, David Holmes wrote: >> Ping! >> >> On 2/08/2019 9:03 am, David Holmes wrote: >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8228857 >>> webrev: http://cr.openjdk.java.net/~dholmes/8228857/webrev/ >>> >>> As suggested by Per Liden when PlatformMonitor was introduced by >>> JDK-8210832 we should refactor PlatformMonitor into a simpler >>> PlatformMutex extended by PlatformMonitor. That would potentially >>> allow other synchronization objects e.g. Zlocks, to be replaced by a >>> suitable PlatformX class, and allows us to redefine JVM_RawMonitor >>> support to use it (forthcoming change). >>> >>> The refactoring would be obvious and simple if not for the macOS >>> PThread allocation bug workaround. I had to change the Posix variant >>> so that we only use the Impl helper class on macOS, so that we can >>> separate the allocation of the pthread_mutex_t and pthread_cond_t. >>> For macOS both get allocated in the PlatformMutex. >>> >>> There are not actual usage changes in this RFE. >>> >>> Testing: mach5 tiers 1-3 >>> >>> Thanks, >>> David >>> ----- > From ivankrylov.java at gmail.com Tue Aug 6 06:14:16 2019 From: ivankrylov.java at gmail.com (Ivan Krylov) Date: Tue, 6 Aug 2019 09:14:16 +0300 Subject: RFC: JWarmup precompile java hot methods at application startup In-Reply-To: References: Message-ID: <7e8aeb89-f03f-6736-a687-58bdc84e4440@gmail.com> Dear all, I would like to summarize discussions around JWarmup at JVMLS 2019. There were many so I will try to collapse into a smaller email. For the purposes of this discussion I don't represent neither my previous employer Azul Systems, maker of ReadyNow, nor my current employer. The great java warmup problem is a well understood one. This year there is probably not a single java conference without a talk on this subject. Multiple approaches have been developed to tackle this issue, at different layers, in the vanilla OpenJDK and in the alternative JDKs. These include but not limited to CDS/AppCDS, OpenJ9's JIT Cache / Zing Compile Stashing, JWarmUp / ReadyNow, jaotc / graalvm native images, etc. etc. Some of this technologies tackle additional aspects like memory footprint. There is an excellent talk [1] at #JVMLS2019 from Mark Stoodly from IBM with an overview of a landscape of technologies. There seems to be an understanding that there is no 1-size-fits-all solution. This thread is specifically about an approach of saving and using recorded application profiles in subsequent runs of the same application. There are two working solutions that I am aware of: JWarmup in the AlibabaJDK and ReadyNow in Zing. There is nothing in the OpenJDK master of this variety. At this point there is enough evidence, enough production data to say that the approach is beneficial for many large applications and microservices. Alibaba folks have proposed a JEP [2] and a patch [3] to add this functionality. The discussion seems to indicate (and correct me if I am wrong) that as it stands now this patch has a low chance of being accepted. First, reviewers miss a detailed description. What is the user story? Can profiles be uses across multiple jvm version? Across multiple platforms and ISAs? Across changing library code? Is it a self-updating profile or write once kind of? In case of profile on a NFS who's responsibility is to ensure proper locking on a profile? Looking at the internals - there are even more questions? Are compiles conservative or speculative? How method profile data is decoded and populated to the structures consumes by ci layer /jit ? Are class loads infused by a profile reader or done entirely by the application? What about class linking and initialization? What is a success metric? What statistics or monitoring can be used? What would constitute regression testing? On the implementation side It seems to me that the main problem is that the protocol between JVM and a profile provider isn't specified. We need an API perhaps similar in its spirit to the GC Interface [4]. This would allow not to multiplex the regular runtime business and the logic of the profile provider. The file format for persisted data also need some specification including versioning. In my view a feature like JWarmup is much bigger than a one patch. Bigger than one JEP. As for the logistics: I have been away from the hotspot aliases for so long that I am not sure what is the current practice now. May be starting a thread with design discussions is good enough or may be we need a dedicated openjdk project and a dedicated mail list. From my side I can share my experience and knowledge from building such an assisted warmup machinery. There are many lessons that we learned. Some are outlined at this excellent talk from Douglas Hawkins[5]. If you scroll to the end you'll see why we ended doing essentially two passes of the persisted profile application. Thanks, Ivan 1 - https://www.youtube.com/watch?v=gx8DVVFPkcQ 2 - https://openjdk.java.net/jeps/8203832 3 - http://cr.openjdk.java.net/~minqi/8220692/webrev-03/ 4 - https://openjdk.java.net/jeps/304 5 - https://www.youtube.com/watch?v=AGyctnc1DTA&t=1027s On 25/04/2019 19:07, yumin qi wrote: > Hi, > > Apart from comments from compiler professionals can I have comments from > runtime either? The changes mostly land in runtime area. > > Thanks > Yumin > > On Tue, Apr 16, 2019 at 11:27 AM yumin qi wrote: > >> HI, >> >> Did anyone have comments for this version? >> >> Thanks >> Yumin >> >> On Tue, Apr 9, 2019 at 10:36 AM yumin qi wrote: >> >>> Alan, >>> Thanks! Updated in same link: >>> http://cr.openjdk.java.net/~minqi/8220692/webrev-02/ >>> >>> Removed non-boot loader branch in nativeLookup.cpp. >>> Added jdk.jwarmup to boot loader list in make/common/Modules.gmk. >>> Tested again to make sure the new changes. >>> >>> Thanks >>> Yumin >>> >>> >>> On Tue, Apr 9, 2019 at 4:48 AM Alan Bateman >>> wrote: >>> >>>> On 09/04/2019 07:10, yumin qi wrote: >>>>> Now the registerNatives is found when it looks up for native entry >>>>> in lookupNative.cpp. I thought the class JWarmUp will be loaded by >>>>> boot loader like Unsafe or WhiteBox, but I was wrong, it is loaded by >>>>> app class loader so logic for obtaining its native entry put in both >>>>> cases, boot loader and non boot loaders. >>>>> >>>> make/common/Modules.gmk is where BOOT_MODULES is defined with the list >>>> of modules mapped to the boot loader. >>>> >>>> -Alan >>>> From per.liden at oracle.com Tue Aug 6 07:42:46 2019 From: per.liden at oracle.com (Per Liden) Date: Tue, 6 Aug 2019 09:42:46 +0200 Subject: RFR (S): 8228857: Refactor PlatformMonitor into PlatformMutex and PlatformMonitor In-Reply-To: References: Message-ID: <03a9ed9b-b11d-dbdd-d785-76951c3748ab@oracle.com> Hi David, On 8/2/19 1:03 AM, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8228857 > webrev: http://cr.openjdk.java.net/~dholmes/8228857/webrev/ src/hotspot/os/posix/os_posix.hpp --------------------------------- As far as I recall, the macos bug is only related to the lifecycle of condvars (not mutexes). Is that correct? If so, PlatformMutex could just always own a plain pthread_mutex_t, and the PLATFORM_MONITOR_IMPL_INDIRECT stuff could be moved to PlatformMonitor to and only deal with the lifecycle of the pthread_cond_t. That way the PlatformMutex would not carry the burden/cost for working around the condvar bug, which would make PlatformMutex even more attractive as a replacement/backing for ZLocks. How does that sound? cheers, Per > > As suggested by Per Liden when PlatformMonitor was introduced by > JDK-8210832 we should refactor PlatformMonitor into a simpler > PlatformMutex extended by PlatformMonitor. That would potentially allow > other synchronization objects e.g. Zlocks, to be replaced by a suitable > PlatformX class, and allows us to redefine JVM_RawMonitor support to use > it (forthcoming change). > > The refactoring would be obvious and simple if not for the macOS PThread > allocation bug workaround. I had to change the Posix variant so that we > only use the Impl helper class on macOS, so that we can separate the > allocation of the pthread_mutex_t and pthread_cond_t. For macOS both get > allocated in the PlatformMutex. > > There are not actual usage changes in this RFE. > > Testing: mach5 tiers 1-3 > > Thanks, > David > ----- From david.holmes at oracle.com Tue Aug 6 08:06:41 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 6 Aug 2019 18:06:41 +1000 Subject: RFR (S): 8228857: Refactor PlatformMonitor into PlatformMutex and PlatformMonitor In-Reply-To: <03a9ed9b-b11d-dbdd-d785-76951c3748ab@oracle.com> References: <03a9ed9b-b11d-dbdd-d785-76951c3748ab@oracle.com> Message-ID: <6bc5807b-53ed-f103-6477-6162ba5a14a3@oracle.com> Hi Per, On 6/08/2019 5:42 pm, Per Liden wrote: > Hi David, > > On 8/2/19 1:03 AM, David Holmes wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8228857 >> webrev: http://cr.openjdk.java.net/~dholmes/8228857/webrev/ > > src/hotspot/os/posix/os_posix.hpp > --------------------------------- > As far as I recall, the macos bug is only related to the lifecycle of > condvars (not mutexes). Is that correct? Not quite. The issue is the allocation of a pthread_mutex_t at an address that previously held a pthread_condvar_t. > If so, PlatformMutex could just always own a plain pthread_mutex_t, and > the PLATFORM_MONITOR_IMPL_INDIRECT stuff could be moved to > PlatformMonitor to and only deal with the lifecycle of the > pthread_cond_t. That way the PlatformMutex would not carry the > burden/cost for working around the condvar bug, which would make > PlatformMutex even more attractive as a replacement/backing for ZLocks. > How does that sound? I deliberately took the simplest path to just leave the macOS workaround as is, knowing it means we still pay for the condvar slot on that platform. :) Because the bug involves both types I don't think I can constrain the workaround to only the PlatformMonitor class, as I'd need to control the allocation in the PlatformMutex as well. I could do that with defining and instantiating a different Impl type in PlatformMonitor to be installed by PlatformMutex, but the overall complexity increase doesn't seem like a good trade off to me. Perhaps I've missed a simple way to deal with this? Thanks, David > cheers, > Per > >> >> As suggested by Per Liden when PlatformMonitor was introduced by >> JDK-8210832 we should refactor PlatformMonitor into a simpler >> PlatformMutex extended by PlatformMonitor. That would potentially >> allow other synchronization objects e.g. Zlocks, to be replaced by a >> suitable PlatformX class, and allows us to redefine JVM_RawMonitor >> support to use it (forthcoming change). >> >> The refactoring would be obvious and simple if not for the macOS >> PThread allocation bug workaround. I had to change the Posix variant >> so that we only use the Impl helper class on macOS, so that we can >> separate the allocation of the pthread_mutex_t and pthread_cond_t. For >> macOS both get allocated in the PlatformMutex. >> >> There are not actual usage changes in this RFE. >> >> Testing: mach5 tiers 1-3 >> >> Thanks, >> David >> ----- From martin.doerr at sap.com Tue Aug 6 08:14:44 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 6 Aug 2019 08:14:44 +0000 Subject: RFR: 8228902: add os::dll_load to the unified logging os category In-Reply-To: <08131940-52e2-6470-4b56-c7df4eec38a6@oracle.com> References: <08131940-52e2-6470-4b56-c7df4eec38a6@oracle.com> Message-ID: Hi Matthias, looks good to me, too. Best regards, Martin > -----Original Message----- > From: hotspot-dev On Behalf Of > coleen.phillimore at oracle.com > Sent: Dienstag, 6. August 2019 00:51 > To: hotspot-dev at openjdk.java.net > Subject: Re: RFR: 8228902: add os::dll_load to the unified logging os category > > > This looks good. > Coleen > > On 8/2/19 4:22 AM, Baesken, Matthias wrote: > > Hello, I missed the shared library loads in the UL (os category) . > > So I created a small webrev and added the info . > > > > Please review ! > > > > Bug/webrev : > > > > https://bugs.openjdk.java.net/browse/JDK-8228902 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8228902.0/ > > > > > > Thanks, Matthias From per.liden at oracle.com Tue Aug 6 09:12:41 2019 From: per.liden at oracle.com (Per Liden) Date: Tue, 6 Aug 2019 11:12:41 +0200 Subject: RFR (S): 8228857: Refactor PlatformMonitor into PlatformMutex and PlatformMonitor In-Reply-To: <6bc5807b-53ed-f103-6477-6162ba5a14a3@oracle.com> References: <03a9ed9b-b11d-dbdd-d785-76951c3748ab@oracle.com> <6bc5807b-53ed-f103-6477-6162ba5a14a3@oracle.com> Message-ID: <3c83dc0b-e001-71f2-c42a-8c9f7e793764@oracle.com> Hi David, On 8/6/19 10:06 AM, David Holmes wrote: > Hi Per, > > On 6/08/2019 5:42 pm, Per Liden wrote: >> Hi David, >> >> On 8/2/19 1:03 AM, David Holmes wrote: >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8228857 >>> webrev: http://cr.openjdk.java.net/~dholmes/8228857/webrev/ >> >> src/hotspot/os/posix/os_posix.hpp >> --------------------------------- >> As far as I recall, the macos bug is only related to the lifecycle of >> condvars (not mutexes). Is that correct? > > Not quite. The issue is the allocation of a pthread_mutex_t at an > address that previously held a pthread_condvar_t. > >> If so, PlatformMutex could just always own a plain pthread_mutex_t, >> and the PLATFORM_MONITOR_IMPL_INDIRECT stuff could be moved to >> PlatformMonitor to and only deal with the lifecycle of the >> pthread_cond_t. That way the PlatformMutex would not carry the >> burden/cost for working around the condvar bug, which would make >> PlatformMutex even more attractive as a replacement/backing for ZLocks. >> How does that sound? > > I deliberately took the simplest path to just leave the macOS workaround > as is, knowing it means we still pay for the condvar slot on that > platform. :) > > Because the bug involves both types I don't think I can constrain the > workaround to only the PlatformMonitor class, as I'd need to control the > allocation in the PlatformMutex as well. I could do that with defining > and instantiating a different Impl type in PlatformMonitor to be > installed by PlatformMutex, but the overall complexity increase doesn't > seem like a good trade off to me. Perhaps I've missed a simple way to > deal with this? Ok. So we can't have a mutex_t at an address where a cond_t has lived in the past. We guarantee that this can not happen by never actually deallocating any cond_t and instead have our own freelist, essentially protecting those cond_t addresses from ever being reused for any other type. Even if this bug involves both types, just constraining cond_t should be enough to solve the problem, right? Just to illustrate what I'm thinking, I adjusted your patch: http://cr.openjdk.java.net/~pliden/8228857/webrev.0 And here's just the diff against your patch: http://cr.openjdk.java.net/~pliden/8228857/webrev.0-diff This keeps the code pretty similar, but puts the cost on PlatforMonitor. Can you spot a problem with this? cheers, Per > > Thanks, > David > >> cheers, >> Per >> >>> >>> As suggested by Per Liden when PlatformMonitor was introduced by >>> JDK-8210832 we should refactor PlatformMonitor into a simpler >>> PlatformMutex extended by PlatformMonitor. That would potentially >>> allow other synchronization objects e.g. Zlocks, to be replaced by a >>> suitable PlatformX class, and allows us to redefine JVM_RawMonitor >>> support to use it (forthcoming change). >>> >>> The refactoring would be obvious and simple if not for the macOS >>> PThread allocation bug workaround. I had to change the Posix variant >>> so that we only use the Impl helper class on macOS, so that we can >>> separate the allocation of the pthread_mutex_t and pthread_cond_t. >>> For macOS both get allocated in the PlatformMutex. >>> >>> There are not actual usage changes in this RFE. >>> >>> Testing: mach5 tiers 1-3 >>> >>> Thanks, >>> David >>> ----- From matthias.baesken at sap.com Tue Aug 6 10:04:54 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 6 Aug 2019 10:04:54 +0000 Subject: hs_c* files in the /tmp directory Message-ID: Hello, recently we were running into issues with some hs jtreg tests (from ctw = "compile the world"). Those jtreg tests fill (at least when they are running) the /tmp dir with hs_c* files . This can for a while lead to a full /tmp on the test machines (which influences other processes on the machine in a bad way). In some (hopefully seldom) bad cases (hangups/unexpected test ends) the hs_c* files even stay on the machine in the /tmp dir and fill it over time. Reason is the coding in CompileBroker::init_compiler_thread_log() https://hg.openjdk.java.net/jdk/jdk/file/ddae2da329ed/src/hotspot/share/compiler/compileBroker.cpp#l1819 where the /tmp dir is used to store the hs_c* files. Should there be an option to set an alternative directory for the storage of these files (e.g. java.io.tmpdir or something similar) ? Best regards, Matthias From matthias.baesken at sap.com Tue Aug 6 10:09:11 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 6 Aug 2019 10:09:11 +0000 Subject: RFR: 8228902: add os::dll_load to the unified logging os category In-Reply-To: References: <08131940-52e2-6470-4b56-c7df4eec38a6@oracle.com> Message-ID: Hi Martin and Coleen, thanks for the reviews ! Best regards, Matthias > -----Original Message----- > From: Doerr, Martin > Sent: Dienstag, 6. August 2019 10:15 > To: Baesken, Matthias ; hotspot- > dev at openjdk.java.net > Subject: RE: RFR: 8228902: add os::dll_load to the unified logging os category > > Hi Matthias, > > looks good to me, too. > > Best regards, > Martin > > > -----Original Message----- > > From: hotspot-dev On Behalf > Of > > coleen.phillimore at oracle.com > > Sent: Dienstag, 6. August 2019 00:51 > > To: hotspot-dev at openjdk.java.net > > Subject: Re: RFR: 8228902: add os::dll_load to the unified logging os > category > > > > > > This looks good. > > Coleen > > > > On 8/2/19 4:22 AM, Baesken, Matthias wrote: > > > Hello, I missed the shared library loads in the UL (os category) . > > > So I created a small webrev and added the info . > > > > > > Please review ! > > > > > > Bug/webrev : > > > > > > https://bugs.openjdk.java.net/browse/JDK-8228902 > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8228902.0/ > > > > > > > > > Thanks, Matthias From christian.hagedorn at oracle.com Tue Aug 6 10:28:01 2019 From: christian.hagedorn at oracle.com (Christian Hagedorn) Date: Tue, 6 Aug 2019 12:28:01 +0200 Subject: [14] RFR(XS): 8229158: make UseSwitchProfiling non-experimental or false by-default Message-ID: <3eda5642-17f2-75d5-62b7-e118eaed2e90@oracle.com> Hi Please review the following enhancement: https://bugs.openjdk.java.net/browse/JDK-8229158 http://cr.openjdk.java.net/~thartmann/8229158/webrev.00/ This just changes the flag UseSwitchProfiling from experimental to diagnostic. Thanks! Best regards, Christian From tobias.hartmann at oracle.com Tue Aug 6 10:52:52 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 6 Aug 2019 12:52:52 +0200 Subject: [14] RFR(XS): 8229158: make UseSwitchProfiling non-experimental or false by-default In-Reply-To: <3eda5642-17f2-75d5-62b7-e118eaed2e90@oracle.com> References: <3eda5642-17f2-75d5-62b7-e118eaed2e90@oracle.com> Message-ID: <73ddb76b-f167-6ce4-f085-814d8258e634@oracle.com> Hi Christian, looks good to me. Best regards, Tobias On 06.08.19 12:28, Christian Hagedorn wrote: > Hi > > Please review the following enhancement: > https://bugs.openjdk.java.net/browse/JDK-8229158 > http://cr.openjdk.java.net/~thartmann/8229158/webrev.00/ > > This just changes the flag UseSwitchProfiling from experimental to diagnostic. > > Thanks! > > Best regards, > Christian From david.holmes at oracle.com Tue Aug 6 11:06:30 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 6 Aug 2019 21:06:30 +1000 Subject: RFR (S): 8228857: Refactor PlatformMonitor into PlatformMutex and PlatformMonitor In-Reply-To: <3c83dc0b-e001-71f2-c42a-8c9f7e793764@oracle.com> References: <03a9ed9b-b11d-dbdd-d785-76951c3748ab@oracle.com> <6bc5807b-53ed-f103-6477-6162ba5a14a3@oracle.com> <3c83dc0b-e001-71f2-c42a-8c9f7e793764@oracle.com> Message-ID: <07f195ed-cd45-2a7e-30d4-5e63f01edbae@oracle.com> Hi Per, On 6/08/2019 7:12 pm, Per Liden wrote: > Hi David, > > On 8/6/19 10:06 AM, David Holmes wrote: >> Hi Per, >> >> On 6/08/2019 5:42 pm, Per Liden wrote: >>> Hi David, >>> >>> On 8/2/19 1:03 AM, David Holmes wrote: >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8228857 >>>> webrev: http://cr.openjdk.java.net/~dholmes/8228857/webrev/ >>> >>> src/hotspot/os/posix/os_posix.hpp >>> --------------------------------- >>> As far as I recall, the macos bug is only related to the lifecycle of >>> condvars (not mutexes). Is that correct? >> >> Not quite. The issue is the allocation of a pthread_mutex_t at an >> address that previously held a pthread_condvar_t. >> >>> If so, PlatformMutex could just always own a plain pthread_mutex_t, >>> and the PLATFORM_MONITOR_IMPL_INDIRECT stuff could be moved to >>> PlatformMonitor to and only deal with the lifecycle of the >>> pthread_cond_t. That way the PlatformMutex would not carry the >>> burden/cost for working around the condvar bug, which would make >>> PlatformMutex even more attractive as a replacement/backing for ZLocks. >>> How does that sound? >> >> I deliberately took the simplest path to just leave the macOS >> workaround as is, knowing it means we still pay for the condvar slot >> on that platform. :) >> >> Because the bug involves both types I don't think I can constrain the >> workaround to only the PlatformMonitor class, as I'd need to control >> the allocation in the PlatformMutex as well. I could do that with >> defining and instantiating a different Impl type in PlatformMonitor to >> be installed by PlatformMutex, but the overall complexity increase >> doesn't seem like a good trade off to me. Perhaps I've missed a simple >> way to deal with this? > > Ok. So we can't have a mutex_t at an address where a cond_t has lived in > the past. We guarantee that this can not happen by never actually > deallocating any cond_t and instead have our own freelist, essentially > protecting those cond_t addresses from ever being reused for any other > type. Even if this bug involves both types, just constraining cond_t > should be enough to solve the problem, right? > > Just to illustrate what I'm thinking, I adjusted your patch: > http://cr.openjdk.java.net/~pliden/8228857/webrev.0 > > And here's just the diff against your patch: > http://cr.openjdk.java.net/~pliden/8228857/webrev.0-diff > > This keeps the code pretty similar, but puts the cost on PlatforMonitor. > Can you spot a problem with this? First thanks for taking the time to do this - much appreciated. I had considered doing something like this, but then was concerned as to whether the pthread_mutex_t could by chance end up in a location that had once been a pthread_cond_t and so still hit the bug. But I think I was overthinking this as the same could be true for the allocation of the Impl instances. I'll take your proposed changes for a test run and in particular see if I can re-run the tests that demonstrated the kernel bug. Thanks again, David ----- > cheers, > Per > >> >> Thanks, >> David >> >>> cheers, >>> Per >>> >>>> >>>> As suggested by Per Liden when PlatformMonitor was introduced by >>>> JDK-8210832 we should refactor PlatformMonitor into a simpler >>>> PlatformMutex extended by PlatformMonitor. That would potentially >>>> allow other synchronization objects e.g. Zlocks, to be replaced by a >>>> suitable PlatformX class, and allows us to redefine JVM_RawMonitor >>>> support to use it (forthcoming change). >>>> >>>> The refactoring would be obvious and simple if not for the macOS >>>> PThread allocation bug workaround. I had to change the Posix variant >>>> so that we only use the Impl helper class on macOS, so that we can >>>> separate the allocation of the pthread_mutex_t and pthread_cond_t. >>>> For macOS both get allocated in the PlatformMutex. >>>> >>>> There are not actual usage changes in this RFE. >>>> >>>> Testing: mach5 tiers 1-3 >>>> >>>> Thanks, >>>> David >>>> ----- From david.holmes at oracle.com Tue Aug 6 11:17:14 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 6 Aug 2019 21:17:14 +1000 Subject: [14] RFR(XS): 8229158: make UseSwitchProfiling non-experimental or false by-default In-Reply-To: <3eda5642-17f2-75d5-62b7-e118eaed2e90@oracle.com> References: <3eda5642-17f2-75d5-62b7-e118eaed2e90@oracle.com> Message-ID: <39490af4-3fcf-7849-b8a7-a394a3ee5c61@oracle.com> Hi Christian, On 6/08/2019 8:28 pm, Christian Hagedorn wrote: > Hi > > Please review the following enhancement: > https://bugs.openjdk.java.net/browse/JDK-8229158 > http://cr.openjdk.java.net/~thartmann/8229158/webrev.00/ > > This just changes the flag UseSwitchProfiling from experimental to > diagnostic. hotspot-compiler-dev seems like a better list for this change as that is where the original code was reviewed. In particular I think you need to get buy-in from the people that provided this code in the first place - who would be Aleksey Shipilev and Roland Westrelin. http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2018-March/028595.html To be clear, the rationale for this change is that there is a general expectation that an experimental flag of the form UseX is used to turn on an experimental feature X (that would be off by default). Here we appear to have functionality that should always be on but we want a flag to allow it to be turned off "just in case". Such a flag (if not product) would therefore be better as diagnostic. Thanks, David > Thanks! > > Best regards, > Christian From christian.hagedorn at oracle.com Tue Aug 6 12:04:18 2019 From: christian.hagedorn at oracle.com (Christian Hagedorn) Date: Tue, 6 Aug 2019 14:04:18 +0200 Subject: [14] RFR(XS): 8229158: make UseSwitchProfiling non-experimental or false by-default In-Reply-To: <39490af4-3fcf-7849-b8a7-a394a3ee5c61@oracle.com> References: <3eda5642-17f2-75d5-62b7-e118eaed2e90@oracle.com> <39490af4-3fcf-7849-b8a7-a394a3ee5c61@oracle.com> Message-ID: <67fe2238-66bb-3464-32c3-685571b18be4@oracle.com> Hi David On 06.08.19 13:17, David Holmes wrote: > Hi Christian, > > On 6/08/2019 8:28 pm, Christian Hagedorn wrote: >> Hi >> >> Please review the following enhancement: >> https://bugs.openjdk.java.net/browse/JDK-8229158 >> http://cr.openjdk.java.net/~thartmann/8229158/webrev.00/ >> >> This just changes the flag UseSwitchProfiling from experimental to >> diagnostic. > > hotspot-compiler-dev seems like a better list for this change as that is > where the original code was reviewed. In particular I think you need to > get buy-in from the people that provided this code in the first place - > who would be Aleksey Shipilev and Roland Westrelin. > > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2018-March/028595.html Yes, you are right, would have been the better list! > To be clear, the rationale for this change is that there is a general > expectation that an experimental flag of the form UseX is used to turn > on an experimental feature X (that would be off by default). Here we > appear to have functionality that should always be on but we want a flag > to allow it to be turned off "just in case". Such a flag (if not > product) would therefore be better as diagnostic. This sounds reasonable, thanks for the detailed explanation! Best regards, Christian From kim.barrett at oracle.com Tue Aug 6 21:20:56 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 6 Aug 2019 17:20:56 -0400 Subject: RFR (S): 8228857: Refactor PlatformMonitor into PlatformMutex and PlatformMonitor In-Reply-To: <07f195ed-cd45-2a7e-30d4-5e63f01edbae@oracle.com> References: <03a9ed9b-b11d-dbdd-d785-76951c3748ab@oracle.com> <6bc5807b-53ed-f103-6477-6162ba5a14a3@oracle.com> <3c83dc0b-e001-71f2-c42a-8c9f7e793764@oracle.com> <07f195ed-cd45-2a7e-30d4-5e63f01edbae@oracle.com> Message-ID: <6D502C87-B9F0-476B-ACC4-E406A7F0DF8E@oracle.com> > On Aug 6, 2019, at 7:06 AM, David Holmes wrote: > > Hi Per, > > On 6/08/2019 7:12 pm, Per Liden wrote: >> Hi David, >> On 8/6/19 10:06 AM, David Holmes wrote: >>> Hi Per, >>> >>> On 6/08/2019 5:42 pm, Per Liden wrote: >>>> Hi David, >>>> >>>> On 8/2/19 1:03 AM, David Holmes wrote: >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8228857 >>>>> webrev: http://cr.openjdk.java.net/~dholmes/8228857/webrev/ >>>> >>>> src/hotspot/os/posix/os_posix.hpp >>>> --------------------------------- >>>> As far as I recall, the macos bug is only related to the lifecycle of condvars (not mutexes). Is that correct? >>> >>> Not quite. The issue is the allocation of a pthread_mutex_t at an address that previously held a pthread_condvar_t. >>> >>>> If so, PlatformMutex could just always own a plain pthread_mutex_t, and the PLATFORM_MONITOR_IMPL_INDIRECT stuff could be moved to PlatformMonitor to and only deal with the lifecycle of the pthread_cond_t. That way the PlatformMutex would not carry the burden/cost for working around the condvar bug, which would make PlatformMutex even more attractive as a replacement/backing for ZLocks. >>>> How does that sound? >>> >>> I deliberately took the simplest path to just leave the macOS workaround as is, knowing it means we still pay for the condvar slot on that platform. :) >>> >>> Because the bug involves both types I don't think I can constrain the workaround to only the PlatformMonitor class, as I'd need to control the allocation in the PlatformMutex as well. I could do that with defining and instantiating a different Impl type in PlatformMonitor to be installed by PlatformMutex, but the overall complexity increase doesn't seem like a good trade off to me. Perhaps I've missed a simple way to deal with this? >> Ok. So we can't have a mutex_t at an address where a cond_t has lived in the past. We guarantee that this can not happen by never actually deallocating any cond_t and instead have our own freelist, essentially protecting those cond_t addresses from ever being reused for any other type. Even if this bug involves both types, just constraining cond_t should be enough to solve the problem, right? >> Just to illustrate what I'm thinking, I adjusted your patch: >> http://cr.openjdk.java.net/~pliden/8228857/webrev.0 >> And here's just the diff against your patch: >> http://cr.openjdk.java.net/~pliden/8228857/webrev.0-diff >> This keeps the code pretty similar, but puts the cost on PlatforMonitor. Can you spot a problem with this? > > First thanks for taking the time to do this - much appreciated. > > I had considered doing something like this, but then was concerned as to whether the pthread_mutex_t could by chance end up in a location that had once been a pthread_cond_t and so still hit the bug. But I think I was overthinking this as the same could be true for the allocation of the Impl instances. > > I'll take your proposed changes for a test run and in particular see if I can re-run the tests that demonstrated the kernel bug. I was planning to review this, but haven't gotten to it yet. I initially had the same thought as Per. However, I changed my mind about it, with the following reasoning. It is true that only a pthread_cond_t that has been allocated and later destroyed can cause problems. However, we (the VM) might not be the only place doing such. Native code, library code, &etc might also do that. Even the current mechanism doesn't fully protect us from that. This was something that Patricio and I recognized when we did the MacOSX workaround; it's not completely bullet proof. However, with the current mechanism of allocating pthread_mutex/cond_t pairs and freelisting them, we highwater pretty quickly. We don't have many places that actually release them. (I don't remember whether there's anything other than the task terminator mechanism.) And once we've highwatered, the VM is safe from any further condvar destructions by non-VM code. So the only risk is from native code using pthread_cond_t's before that highwater mark is reached. If the VM only freelists its pthread_cond_t's and not its pthread_mutex_t's, instead allocating and deleting the latter normally (as Per suggested and I had originally intended to suggest), then the VM's pthread_mutex_t's are subject to getting scrambled by ongoing non-VM pthread_cond_t usage. From david.holmes at oracle.com Tue Aug 6 22:10:18 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 7 Aug 2019 08:10:18 +1000 Subject: RFR (S): 8228857: Refactor PlatformMonitor into PlatformMutex and PlatformMonitor In-Reply-To: <6D502C87-B9F0-476B-ACC4-E406A7F0DF8E@oracle.com> References: <03a9ed9b-b11d-dbdd-d785-76951c3748ab@oracle.com> <6bc5807b-53ed-f103-6477-6162ba5a14a3@oracle.com> <3c83dc0b-e001-71f2-c42a-8c9f7e793764@oracle.com> <07f195ed-cd45-2a7e-30d4-5e63f01edbae@oracle.com> <6D502C87-B9F0-476B-ACC4-E406A7F0DF8E@oracle.com> Message-ID: Hi Kim, On 7/08/2019 7:20 am, Kim Barrett wrote: >> On Aug 6, 2019, at 7:06 AM, David Holmes wrote: >> >> Hi Per, >> >> On 6/08/2019 7:12 pm, Per Liden wrote: >>> Hi David, >>> On 8/6/19 10:06 AM, David Holmes wrote: >>>> Hi Per, >>>> >>>> On 6/08/2019 5:42 pm, Per Liden wrote: >>>>> Hi David, >>>>> >>>>> On 8/2/19 1:03 AM, David Holmes wrote: >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8228857 >>>>>> webrev: http://cr.openjdk.java.net/~dholmes/8228857/webrev/ >>>>> >>>>> src/hotspot/os/posix/os_posix.hpp >>>>> --------------------------------- >>>>> As far as I recall, the macos bug is only related to the lifecycle of condvars (not mutexes). Is that correct? >>>> >>>> Not quite. The issue is the allocation of a pthread_mutex_t at an address that previously held a pthread_condvar_t. >>>> >>>>> If so, PlatformMutex could just always own a plain pthread_mutex_t, and the PLATFORM_MONITOR_IMPL_INDIRECT stuff could be moved to PlatformMonitor to and only deal with the lifecycle of the pthread_cond_t. That way the PlatformMutex would not carry the burden/cost for working around the condvar bug, which would make PlatformMutex even more attractive as a replacement/backing for ZLocks. >>>>> How does that sound? >>>> >>>> I deliberately took the simplest path to just leave the macOS workaround as is, knowing it means we still pay for the condvar slot on that platform. :) >>>> >>>> Because the bug involves both types I don't think I can constrain the workaround to only the PlatformMonitor class, as I'd need to control the allocation in the PlatformMutex as well. I could do that with defining and instantiating a different Impl type in PlatformMonitor to be installed by PlatformMutex, but the overall complexity increase doesn't seem like a good trade off to me. Perhaps I've missed a simple way to deal with this? >>> Ok. So we can't have a mutex_t at an address where a cond_t has lived in the past. We guarantee that this can not happen by never actually deallocating any cond_t and instead have our own freelist, essentially protecting those cond_t addresses from ever being reused for any other type. Even if this bug involves both types, just constraining cond_t should be enough to solve the problem, right? >>> Just to illustrate what I'm thinking, I adjusted your patch: >>> http://cr.openjdk.java.net/~pliden/8228857/webrev.0 >>> And here's just the diff against your patch: >>> http://cr.openjdk.java.net/~pliden/8228857/webrev.0-diff >>> This keeps the code pretty similar, but puts the cost on PlatforMonitor. Can you spot a problem with this? >> >> First thanks for taking the time to do this - much appreciated. >> >> I had considered doing something like this, but then was concerned as to whether the pthread_mutex_t could by chance end up in a location that had once been a pthread_cond_t and so still hit the bug. But I think I was overthinking this as the same could be true for the allocation of the Impl instances. >> >> I'll take your proposed changes for a test run and in particular see if I can re-run the tests that demonstrated the kernel bug. > > I was planning to review this, but haven't gotten to it yet. I > initially had the same thought as Per. However, I changed my mind > about it, with the following reasoning. > > It is true that only a pthread_cond_t that has been allocated and > later destroyed can cause problems. However, we (the VM) might not be > the only place doing such. Native code, library code, &etc might also > do that. Even the current mechanism doesn't fully protect us from > that. This was something that Patricio and I recognized when we did > the MacOSX workaround; it's not completely bullet proof. > > However, with the current mechanism of allocating pthread_mutex/cond_t > pairs and freelisting them, we highwater pretty quickly. We don't have > many places that actually release them. (I don't remember whether > there's anything other than the task terminator mechanism.) And once > we've highwatered, the VM is safe from any further condvar > destructions by non-VM code. So the only risk is from native code > using pthread_cond_t's before that highwater mark is reached. > > If the VM only freelists its pthread_cond_t's and not its > pthread_mutex_t's, instead allocating and deleting the latter normally > (as Per suggested and I had originally intended to suggest), then the > VM's pthread_mutex_t's are subject to getting scrambled by ongoing > non-VM pthread_cond_t usage. Yes you are right. I was only thinking about VM usage, but if the VM is hosted then mutex/condvar could be being used a lot and not using the freelist for the mutex would greatly increase the risk of reintroducing the bug. As you say the freelist approach itself is not bullet-proof and I'm now worried about what complex hosting applications may encounter! :( I think we may need to try and engage with Apple to get the full details on this bug so that we know what our exposure may be. I hope they fixed it with an interim patch and not only with a full release update! So in terms of this RFE I leave things as they stand, with the mutex/cond freelist being used in PlatformMutex. I hope the slight space wastage is not significant enough to mean that Zlocks will not consider using PlatformMutex. Thanks, David From volker.simonis at gmail.com Wed Aug 7 07:14:37 2019 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 7 Aug 2019 10:14:37 +0300 Subject: CFV: New HotSpot Group Member: Jiangli Zhou In-Reply-To: <30c09194-6557-5ff6-caa0-37f976e75618@oracle.com> References: <30c09194-6557-5ff6-caa0-37f976e75618@oracle.com> Message-ID: Vote: yes Calvin Cheung schrieb am Mi., 31. Juli 2019, 00:49: > Greetings, > > I hereby nominate Jiangli Zhou (OpenJDK user name: jiangli) to > Membership in the HotSpot Group. > > Jiangli is a JDK project and JDK update project reviewer. She is > currently a member of Google Java Platform team and has contributed over > 100 changesets[3] to Hotspot JVM in various areas since 2011. In recent > years, she has been mainly focusing on the runtime memory footprint > reduction and Class Data Sharing. > > Votes are due by August 13, 2019, 15:00 PDT. > > Only current Members of the HotSpot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thanks! > > Calvin > > [1] http://openjdk.java.net/census#hotspot > > [2] http://openjdk.java.net/groups/#member-vote > > [3] > > http://hg.openjdk.java.net/jdk/jdk/log?revcount=300&rev=(author(jiangli))+and+not+merge() > > From matthias.baesken at sap.com Wed Aug 7 07:23:01 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 7 Aug 2019 07:23:01 +0000 Subject: RFR [XS] : 8229182: runtime/containers/docker/TestMemoryAwareness.java test fails on SLES12 Message-ID: Hello, please review the following small change . The docker test TestMemoryAwareness.java failed on our ppc64le SLES12 Linux machine . It could not successfully trigger the expected OOM , error message is : java.lang.RuntimeException: Expected to get exit value of [1] at jdk.test.lib.process.OutputAnalyzer.shouldHaveExitValue(OutputAnalyzer.java:396) at TestMemoryAwareness.testOOM(TestMemoryAwareness.java:106) at TestMemoryAwareness.main(TestMemoryAwareness.java:63) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:834) After some discussion with Bob Vandette how to make the test more robust , we looked into additionally setting -memory-swappiness to 0 to disable anonymous page swapping. https://docs.docker.com/config/containers/resource_constraints/#--memory-swappiness-details The test passes with this added setting. Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8229182 http://cr.openjdk.java.net/~mbaesken/webrevs/8229182.0/ Thanks, Matthias From sgehwolf at redhat.com Wed Aug 7 09:37:50 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 07 Aug 2019 11:37:50 +0200 Subject: RFR [XS] : 8229182: runtime/containers/docker/TestMemoryAwareness.java test fails on SLES12 In-Reply-To: References: Message-ID: <6563ed4bd315281320e11755597fec24f4092ded.camel@redhat.com> Hi Matthias, On Wed, 2019-08-07 at 07:23 +0000, Baesken, Matthias wrote: > Hello, please review the following small change . > > The docker test TestMemoryAwareness.java failed on our ppc64le SLES12 Linux machine . > It could not successfully trigger the expected OOM , error message is : > > java.lang.RuntimeException: Expected to get exit value of [1] > > at jdk.test.lib.process.OutputAnalyzer.shouldHaveExitValue(OutputAnalyzer.java:396) > at TestMemoryAwareness.testOOM(TestMemoryAwareness.java:106) > at TestMemoryAwareness.main(TestMemoryAwareness.java:63) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:834) > > > After some discussion with Bob Vandette how to make the test more robust , > > we looked into additionally setting -memory-swappiness to 0 to disable anonymous page swapping. > > > > https://docs.docker.com/config/containers/resource_constraints/#--memory-swappiness-details > > > The test passes with this added setting. > > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8229182 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8229182.0/ This looks OK. Could you please add a comment for the memory-swappiness addition. Suggestion: """ Add "--memory-swappiness 0" so as to disable anonymous page swapping. """ Thanks, Severin From per.liden at oracle.com Wed Aug 7 13:50:01 2019 From: per.liden at oracle.com (Per Liden) Date: Wed, 7 Aug 2019 15:50:01 +0200 Subject: RFR (S): 8228857: Refactor PlatformMonitor into PlatformMutex and PlatformMonitor In-Reply-To: References: <03a9ed9b-b11d-dbdd-d785-76951c3748ab@oracle.com> <6bc5807b-53ed-f103-6477-6162ba5a14a3@oracle.com> <3c83dc0b-e001-71f2-c42a-8c9f7e793764@oracle.com> <07f195ed-cd45-2a7e-30d4-5e63f01edbae@oracle.com> <6D502C87-B9F0-476B-ACC4-E406A7F0DF8E@oracle.com> Message-ID: <1cfbd3a0-cc22-726d-dbcf-636697216292@oracle.com> Hi Kim/David, On 8/7/19 12:10 AM, David Holmes wrote: [...] >> It is true that only a pthread_cond_t that has been allocated and >> later destroyed can cause problems. However, we (the VM) might not be >> the only place doing such. Native code, library code, &etc might also >> do that. Even the current mechanism doesn't fully protect us from >> that. This was something that Patricio and I recognized when we did >> the MacOSX workaround; it's not completely bullet proof. >> >> However, with the current mechanism of allocating pthread_mutex/cond_t >> pairs and freelisting them, we highwater pretty quickly. We don't have >> many places that actually release them. (I don't remember whether >> there's anything other than the task terminator mechanism.) And once >> we've highwatered, the VM is safe from any further condvar >> destructions by non-VM code. So the only risk is from native code >> using pthread_cond_t's before that highwater mark is reached. >> >> If the VM only freelists its pthread_cond_t's and not its >> pthread_mutex_t's, instead allocating and deleting the latter normally >> (as Per suggested and I had originally intended to suggest), then the >> VM's pthread_mutex_t's are subject to getting scrambled by ongoing >> non-VM pthread_cond_t usage. > > Yes you are right. I was only thinking about VM usage, but if the VM is > hosted then mutex/condvar could be being used a lot and not using the > freelist for the mutex would greatly increase the risk of reintroducing > the bug. > > As you say the freelist approach itself is not bullet-proof and I'm now > worried about what complex hosting applications may encounter! :( I > think we may need to try and engage with Apple to get the full details > on this bug so that we know what our exposure may be. I hope they fixed > it with an interim patch and not only with a full release update! > > So in terms of this RFE I leave things as they stand, with the > mutex/cond freelist being used in PlatformMutex. I hope the slight space > wastage is not significant enough to mean that Zlocks will not consider > using PlatformMutex. It would be really interesting to know if this has been fixed by Apple, and hopefully also backported to the macos versions we support. On systems that has this bug, we could have all kinds of random VM memory corruption (caused by e.g. native code/library using condvars), which we can't fix. Right? May I propose a third alternative, which keeps the best of both worlds: Don't mix the two types, i.e. don't let PlatforMonitor inherit from PlatformMutex. So, we'd just keep exactly what we have and just add a PlatformMutex type, which for posix would be just: class PlatformMutex : public CHeapObj { protected: pthread_mutex_t _mutex; public: PlatformMutex(); ~PlatformMutex(); void lock(); void unlock(); bool try_lock(); }; os::PlatformMutex::PlatformMutex() { int status = pthread_mutex_init(&_mutex, _mutexAttr); assert_status(status == 0, status, "mutex_init"); } os::PlatformMutex::~PlatformMutex() { int status = pthread_mutex_destroy(&_mutex); assert_status(status == 0, status, "mutex_destroy"); } inline void os::PlatformMutex::lock() { int status = pthread_mutex_lock(&_mutex); assert_status(status == 0, status, "mutex_lock"); } inline void os::PlatformMutex::unlock() { int status = pthread_mutex_unlock(&_mutex); assert_status(status == 0, status, "mutex_unlock"); } inline bool os::PlatformMutex::try_lock() { int status = pthread_mutex_trylock(&_mutex); assert_status(status == 0 || status == EBUSY, status, "mutex_trylock"); return status == 0; } cheers, Per From matthias.baesken at sap.com Wed Aug 7 13:55:48 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 7 Aug 2019 13:55:48 +0000 Subject: RFR [XS] : 8229182: runtime/containers/docker/TestMemoryAwareness.java test fails on SLES12 In-Reply-To: <6563ed4bd315281320e11755597fec24f4092ded.camel@redhat.com> References: <6563ed4bd315281320e11755597fec24f4092ded.camel@redhat.com> Message-ID: Hi Severin, sure I'll add the comment . Btw we noticed that on some machines we (even with this patch) get an exit value of 137 and not 1 . Do you think this can be seen as a successful test end (means - we could test for exit value 137 too ?) or not ? It look similar to what people saw here : https://stackoverflow.com/questions/38967991/why-are-my-gradle-builds-dying-with-exit-code-137 "In cases where virtual memory is running short the kernel OOM (Out of Memory) killer may forcibly kill Jenkins or individual builds. If this occurs on Linux you may see builds terminate with exit code 137 (128 + signal number for SIGKILL)." Best regards, Matthias > -----Original Message----- > From: Severin Gehwolf > Sent: Mittwoch, 7. August 2019 11:38 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' > Subject: Re: RFR [XS] : 8229182: > runtime/containers/docker/TestMemoryAwareness.java test fails on SLES12 > > Hi Matthias, > > On Wed, 2019-08-07 at 07:23 +0000, Baesken, Matthias wrote: > > Hello, please review the following small change . > > > > The docker test TestMemoryAwareness.java failed on our ppc64le SLES12 > Linux machine . > > It could not successfully trigger the expected OOM , error message is : > > > > java.lang.RuntimeException: Expected to get exit value of [1] > > > > at > jdk.test.lib.process.OutputAnalyzer.shouldHaveExitValue(OutputAnalyzer.ja > va:396) > > at TestMemoryAwareness.testOOM(TestMemoryAwareness.java:106) > > at TestMemoryAwareness.main(TestMemoryAwareness.java:63) > > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMet > hodAccessorImpl.java:62) > > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Delega > tingMethodAccessorImpl.java:43) > > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > > at > com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapp > er.java:127) > > at java.base/java.lang.Thread.run(Thread.java:834) > > > > > > After some discussion with Bob Vandette how to make the test more > robust , > > > > we looked into additionally setting -memory-swappiness to 0 to > disable anonymous page swapping. > > > > > > > > https://docs.docker.com/config/containers/resource_constraints/#-- > memory-swappiness-details > > > > > > The test passes with this added setting. > > > > > > Bug/webrev : > > > > https://bugs.openjdk.java.net/browse/JDK-8229182 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8229182.0/ > > This looks OK. Could you please add a comment for the memory-swappiness > addition. Suggestion: > > """ > Add "--memory-swappiness 0" so as to disable anonymous page swapping. > """ > > Thanks, > Severin From sgehwolf at redhat.com Wed Aug 7 14:18:21 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 07 Aug 2019 16:18:21 +0200 Subject: RFR [XS] : 8229182: runtime/containers/docker/TestMemoryAwareness.java test fails on SLES12 In-Reply-To: References: <6563ed4bd315281320e11755597fec24f4092ded.camel@redhat.com> Message-ID: Hi Matthias, On Wed, 2019-08-07 at 13:55 +0000, Baesken, Matthias wrote: > Hi Severin, sure I'll add the comment . > > Btw we noticed that on some machines we (even with this patch) get an exit value of 137 and not 1 . > Do you think this can be seen as a successful test end (means - we could test for exit value 137 too ?) or not ? > It look similar to what people saw here : Yes, I've seen this before (137 exit code). Non-zero is a successful test if other output matches. So perhaps this? OutputAnalyzer out = DockerTestUtils.dockerRunJava(opts); if (out.getExitValue() == 0) { throw RuntimeException("OOM not triggered?"); } out.shouldContain("Entering AttemptOOM main") .shouldNotContain("AttemptOOM allocation successful") .shouldContain("java.lang.OutOfMemoryError"); Thanks, Severin > > https://stackoverflow.com/questions/38967991/why-are-my-gradle-builds-dying-with-exit-code-137 > > "In cases where virtual memory is running short the kernel OOM (Out of Memory) killer may forcibly kill Jenkins or individual builds. > If this occurs on Linux you may see builds terminate with exit code 137 (128 + signal number for SIGKILL)." > > > Best regards, Matthias > > > > -----Original Message----- > > From: Severin Gehwolf > > Sent: Mittwoch, 7. August 2019 11:38 > > To: Baesken, Matthias ; 'hotspot- > > dev at openjdk.java.net' > > Subject: Re: RFR [XS] : 8229182: > > runtime/containers/docker/TestMemoryAwareness.java test fails on SLES12 > > > > Hi Matthias, > > > > On Wed, 2019-08-07 at 07:23 +0000, Baesken, Matthias wrote: > > > Hello, please review the following small change . > > > > > > The docker test TestMemoryAwareness.java failed on our ppc64le SLES12 > > Linux machine . > > > It could not successfully trigger the expected OOM , error message is : > > > > > > java.lang.RuntimeException: Expected to get exit value of [1] > > > > > > at > > jdk.test.lib.process.OutputAnalyzer.shouldHaveExitValue(OutputAnalyzer.ja > > va:396) > > > at TestMemoryAwareness.testOOM(TestMemoryAwareness.java:106) > > > at TestMemoryAwareness.main(TestMemoryAwareness.java:63) > > > at > > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > > Method) > > > at > > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMet > > hodAccessorImpl.java:62) > > > at > > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Delega > > tingMethodAccessorImpl.java:43) > > > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > > > at > > com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapp > > er.java:127) > > > at java.base/java.lang.Thread.run(Thread.java:834) > > > > > > > > > After some discussion with Bob Vandette how to make the test more > > robust , > > > we looked into additionally setting -memory-swappiness to 0 to > > disable anonymous page swapping. > > > > > > > > > https://docs.docker.com/config/containers/resource_constraints/#-- > > memory-swappiness-details > > > > > > The test passes with this added setting. > > > > > > > > > Bug/webrev : > > > > > > https://bugs.openjdk.java.net/browse/JDK-8229182 > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8229182.0/ > > > > This looks OK. Could you please add a comment for the memory-swappiness > > addition. Suggestion: > > > > """ > > Add "--memory-swappiness 0" so as to disable anonymous page swapping. > > """ > > > > Thanks, > > Severin From bob.vandette at oracle.com Wed Aug 7 15:12:24 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Wed, 7 Aug 2019 11:12:24 -0400 Subject: RFR [XS] : 8229182: runtime/containers/docker/TestMemoryAwareness.java test fails on SLES12 In-Reply-To: References: Message-ID: Matthias, I added some background to the bug. Your fix looks fine to me although you?ll still need an ?R? Reviewer. As for the other issue of dealing with insufficient resources (-137), I don?t think the test should have to deal with that. There are lots of ways to get tests to fail if the system you are running on doesn?t have sufficient resources. Bob. > On Aug 7, 2019, at 3:23 AM, Baesken, Matthias wrote: > > Hello, please review the following small change . > > The docker test TestMemoryAwareness.java failed on our ppc64le SLES12 Linux machine . > It could not successfully trigger the expected OOM , error message is : > > java.lang.RuntimeException: Expected to get exit value of [1] > > at jdk.test.lib.process.OutputAnalyzer.shouldHaveExitValue(OutputAnalyzer.java:396) > at TestMemoryAwareness.testOOM(TestMemoryAwareness.java:106) > at TestMemoryAwareness.main(TestMemoryAwareness.java:63) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:834) > > > After some discussion with Bob Vandette how to make the test more robust , > we looked into additionally setting ?memory-swappiness to 0 to disable anonymous page swapping. > > https://docs.docker.com/config/containers/resource_constraints/#--memory-swappiness-details > > The test passes with this added setting. > > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8229182 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8229182.0/ > > Thanks, Matthias From daniel.daugherty at oracle.com Wed Aug 7 15:37:20 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 7 Aug 2019 11:37:20 -0400 Subject: RFR (S): 8228857: Refactor PlatformMonitor into PlatformMutex and PlatformMonitor In-Reply-To: References: Message-ID: <936e9ed0-d75c-1b73-a9da-5b15f94f7d06@oracle.com> On 8/1/19 7:03 PM, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8228857 > webrev: http://cr.openjdk.java.net/~dholmes/8228857/webrev/ src/hotspot/os/posix/os_posix.hpp ??? L245: // Platform specific implementations that underpin VM Monitor/Mutex classes ??????? Perhaps "Mutex/Monitor" instead of "Monitor/Mutex" now that ??????? Mutex is the base class. And it will be consistent with the ??????? new comments that you've added. src/hotspot/os/posix/os_posix.inline.hpp ??? No comments. src/hotspot/os/posix/os_posix.cpp ??? L2277: // Platform Monitor implementation ??????? Perhaps: // Platform Mutex/Monitor implementation ??????? like you do in other places. src/hotspot/os/solaris/os_solaris.hpp ??? L338: // Platform specific implementations that underpin VM Monitor/Mutex classes ??????? Perhaps "Mutex/Monitor" instead of "Monitor/Mutex" now that ??????? Mutex is the base class. src/hotspot/os/solaris/os_solaris.cpp ??? No comments. src/hotspot/os/windows/os_windows.hpp ??? L190: // Platform specific implementations that underpin VM Monitor/Mutex classes ??????? Perhaps "Mutex/Monitor" instead of "Monitor/Mutex" now that ??????? Mutex is the base class. src/hotspot/os/windows/os_windows.inline.hpp ??? L98: inline os::PlatformMonitor::~PlatformMonitor() { ??????? I don't remember why there is no 'DeleteConditionVariable()' ??????? call here. It might be worth a comment to remind the reader. Thumbs up. If you choose to make the comment tweaks above, I don't need to see another webrev. Dan > > As suggested by Per Liden when PlatformMonitor was introduced by > JDK-8210832 we should refactor PlatformMonitor into a simpler > PlatformMutex extended by PlatformMonitor. That would potentially > allow other synchronization objects e.g. Zlocks, to be replaced by a > suitable PlatformX class, and allows us to redefine JVM_RawMonitor > support to use it (forthcoming change). > > The refactoring would be obvious and simple if not for the macOS > PThread allocation bug workaround. I had to change the Posix variant > so that we only use the Impl helper class on macOS, so that we can > separate the allocation of the pthread_mutex_t and pthread_cond_t. For > macOS both get allocated in the PlatformMutex. > > There are not actual usage changes in this RFE. > > Testing: mach5 tiers 1-3 > > Thanks, > David > ----- > From matthias.baesken at sap.com Wed Aug 7 15:44:24 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 7 Aug 2019 15:44:24 +0000 Subject: RFR [XS] : 8229182: runtime/containers/docker/TestMemoryAwareness.java test fails on SLES12 In-Reply-To: References: Message-ID: Thanks for adding more info to the bug . Best regards, Matthias > -----Original Message----- > From: Bob Vandette > Sent: Mittwoch, 7. August 2019 17:12 > To: Baesken, Matthias > Cc: hotspot-dev at openjdk.java.net; Severin Gehwolf > > Subject: Re: RFR [XS] : 8229182: > runtime/containers/docker/TestMemoryAwareness.java test fails on SLES12 > > Matthias, > > I added some background to the bug. > > Your fix looks fine to me although you?ll still need an ?R? Reviewer. > > As for the other issue of dealing with insufficient resources (-137), I don?t > think the test should have to > deal with that. There are lots of ways to get tests to fail if the system you are > running on doesn?t have sufficient resources. > > > Bob. > > > > On Aug 7, 2019, at 3:23 AM, Baesken, Matthias > wrote: > > > > Hello, please review the following small change . > > > > The docker test TestMemoryAwareness.java failed on our ppc64le SLES12 > Linux machine . > > It could not successfully trigger the expected OOM , error message is : > > > > java.lang.RuntimeException: Expected to get exit value of [1] > > > > at > jdk.test.lib.process.OutputAnalyzer.shouldHaveExitValue(OutputAnalyzer.ja > va:396) > > at TestMemoryAwareness.testOOM(TestMemoryAwareness.java:106) > > at TestMemoryAwareness.main(TestMemoryAwareness.java:63) > > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMet > hodAccessorImpl.java:62) > > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Delega > tingMethodAccessorImpl.java:43) > > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > > at > com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapp > er.java:127) > > at java.base/java.lang.Thread.run(Thread.java:834) > > > > > > After some discussion with Bob Vandette how to make the test more > robust , > > we looked into additionally setting ?memory-swappiness to 0 to > disable anonymous page swapping. > > > > https://docs.docker.com/config/containers/resource_constraints/#-- > memory-swappiness-details > > > > The test passes with this added setting. > > > > > > Bug/webrev : > > > > https://bugs.openjdk.java.net/browse/JDK-8229182 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8229182.0/ > > > > Thanks, Matthias From matthias.baesken at sap.com Wed Aug 7 15:46:32 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 7 Aug 2019 15:46:32 +0000 Subject: RFR [XS] : 8229182: runtime/containers/docker/TestMemoryAwareness.java test fails on SLES12 In-Reply-To: References: <6563ed4bd315281320e11755597fec24f4092ded.camel@redhat.com> Message-ID: Hello, here is a new webrev, it adds the comment and follows Severins proposal . http://cr.openjdk.java.net/~mbaesken/webrevs/8229182.1/ Best regards, Matthias > -----Original Message----- > From: Severin Gehwolf > Sent: Mittwoch, 7. August 2019 16:18 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' > Cc: Bob Vandette > Subject: Re: RFR [XS] : 8229182: > runtime/containers/docker/TestMemoryAwareness.java test fails on SLES12 > > Hi Matthias, > > On Wed, 2019-08-07 at 13:55 +0000, Baesken, Matthias wrote: > > Hi Severin, sure I'll add the comment . > > > > Btw we noticed that on some machines we (even with this patch) get > an exit value of 137 and not 1 . > > Do you think this can be seen as a successful test end (means - we could > test for exit value 137 too ?) or not ? > > It look similar to what people saw here : > > Yes, I've seen this before (137 exit code). Non-zero is a successful > test if other output matches. So perhaps this? > > OutputAnalyzer out = DockerTestUtils.dockerRunJava(opts); > if (out.getExitValue() == 0) { > throw RuntimeException("OOM not triggered?"); > } > out.shouldContain("Entering AttemptOOM main") > .shouldNotContain("AttemptOOM allocation successful") > .shouldContain("java.lang.OutOfMemoryError"); > > Thanks, > Severin > > > > > https://stackoverflow.com/questions/38967991/why-are-my-gradle- > builds-dying-with-exit-code-137 > > > > "In cases where virtual memory is running short the kernel OOM (Out of > Memory) killer may forcibly kill Jenkins or individual builds. > > If this occurs on Linux you may see builds terminate with exit code 137 (128 > + signal number for SIGKILL)." > > > > > > Best regards, Matthias > > > > > > > -----Original Message----- > > > From: Severin Gehwolf > > > Sent: Mittwoch, 7. August 2019 11:38 > > > To: Baesken, Matthias ; 'hotspot- > > > dev at openjdk.java.net' > > > Subject: Re: RFR [XS] : 8229182: > > > runtime/containers/docker/TestMemoryAwareness.java test fails on > SLES12 > > > > > > Hi Matthias, > > > > > > On Wed, 2019-08-07 at 07:23 +0000, Baesken, Matthias wrote: > > > > Hello, please review the following small change . > > > > > > > > The docker test TestMemoryAwareness.java failed on our ppc64le > SLES12 > > > Linux machine . > > > > It could not successfully trigger the expected OOM , error message is > : > > > > > > > > java.lang.RuntimeException: Expected to get exit value of [1] > > > > > > > > at > > > > jdk.test.lib.process.OutputAnalyzer.shouldHaveExitValue(OutputAnalyzer.ja > > > va:396) > > > > at TestMemoryAwareness.testOOM(TestMemoryAwareness.java:106) > > > > at TestMemoryAwareness.main(TestMemoryAwareness.java:63) > > > > at > > > > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > > > Method) > > > > at > > > > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMet > > > hodAccessorImpl.java:62) > > > > at > > > > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Delega > > > tingMethodAccessorImpl.java:43) > > > > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > > > > at > > > > com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapp > > > er.java:127) > > > > at java.base/java.lang.Thread.run(Thread.java:834) > > > > > > > > > > > > After some discussion with Bob Vandette how to make the test more > > > robust , > > > > we looked into additionally setting -memory-swappiness to 0 to > > > disable anonymous page swapping. > > > > > > > > > > > > https://docs.docker.com/config/containers/resource_constraints/#-- > > > memory-swappiness-details > > > > > > > > The test passes with this added setting. > > > > > > > > > > > > Bug/webrev : > > > > > > > > https://bugs.openjdk.java.net/browse/JDK-8229182 > > > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8229182.0/ > > > > > > This looks OK. Could you please add a comment for the memory- > swappiness > > > addition. Suggestion: > > > > > > """ > > > Add "--memory-swappiness 0" so as to disable anonymous page > swapping. > > > """ > > > > > > Thanks, > > > Severin From sgehwolf at redhat.com Wed Aug 7 16:55:14 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 07 Aug 2019 18:55:14 +0200 Subject: RFR [XS] : 8229182: runtime/containers/docker/TestMemoryAwareness.java test fails on SLES12 In-Reply-To: References: <6563ed4bd315281320e11755597fec24f4092ded.camel@redhat.com> Message-ID: <0924470c2bac638fa1feab7d63ee71a57904e408.camel@redhat.com> On Wed, 2019-08-07 at 15:46 +0000, Baesken, Matthias wrote: > http://cr.openjdk.java.net/~mbaesken/webrevs/8229182.1/ Looks good to me. Thanks, Severin From stefan.karlsson at oracle.com Wed Aug 7 19:58:46 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 7 Aug 2019 21:58:46 +0200 Subject: RFR: 8229258: Make markOopDesc AllStatic Message-ID: Hi all, Please review this patch to make markOopDesc AllStatic. https://cr.openjdk.java.net/~stefank/8229258/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8229258 From the RFE: I want to change/rename markOop and markOopDesc Today markOopDescs inherits from oopDesc even though they are not oopDescs (Java objects): ?`class markOopDesc : public oopDesc {` This is very confusing to new-comers (and probably to old-timers as well). A simple fix would be to break the inheritance and do the following rename: markOopDesc -> MarkWord markOop -> markWord However, there are more dubious code in this area. markOopDescs are created and used like this: ``` class oopDesc { ... ? volatile markOop _mark; ... markOop? oopDesc::mark_raw()? const { return _mark; } ... // Usage obj->mark_raw()->is_marked() ... // Implementation ? bool is_marked()?? const { ??? return (mask_bits(value(), lock_mask_in_place) == marked_value); ? } ... // Implementation ? bool is_being_inflated() const { return (value() == 0); } ... // Implementation of markOopDesc::value() ? uintptr_t value() const { return (uintptr_t) this; } ``` Remember, _mark is an arbitrary bit pattern describing the object. We treat it as if it were a pointer to a markOopDesc object, but it's not pointing to such an object. While using that (weird) pointer we call value() and extract it's bit pattern to be used for further bit pattern checking functions. AFAICT, this is also undefined behavior. At least is_being_inflated() const is effectively 'return (uintptr_t) this == NULL'. This UB was recently discussed here: ?https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-July/038704.html ?https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-July/038712.html I propose that we change MarkWord (markOopDesc) to be an AllStatic class instead and get rid of this (ab)use of the markWord (markOop) pointer. The patch is large but mostly straight forward. However, there is some Java code that would need some extra scrutiny: SA and JVMCI. Tested with tier1-3. Coleen has asked for file rename from markOop.hpp to markWord.hpp. I'd like to do that as a separate RFE when/if this patch gets accepted. Thanks, StefanK From kim.barrett at oracle.com Wed Aug 7 20:18:20 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 7 Aug 2019 16:18:20 -0400 Subject: RFR (S): 8228857: Refactor PlatformMonitor into PlatformMutex and PlatformMonitor In-Reply-To: <1cfbd3a0-cc22-726d-dbcf-636697216292@oracle.com> References: <03a9ed9b-b11d-dbdd-d785-76951c3748ab@oracle.com> <6bc5807b-53ed-f103-6477-6162ba5a14a3@oracle.com> <3c83dc0b-e001-71f2-c42a-8c9f7e793764@oracle.com> <07f195ed-cd45-2a7e-30d4-5e63f01edbae@oracle.com> <6D502C87-B9F0-476B-ACC4-E406A7F0DF8E@oracle.com> <1cfbd3a0-cc22-726d-dbcf-636697216292@oracle.com> Message-ID: > On Aug 7, 2019, at 9:50 AM, Per Liden wrote: > > Hi Kim/David, > > On 8/7/19 12:10 AM, David Holmes wrote: > [...] >>> It is true that only a pthread_cond_t that has been allocated and >>> later destroyed can cause problems. However, we (the VM) might not be >>> the only place doing such. Native code, library code, &etc might also >>> do that. Even the current mechanism doesn't fully protect us from >>> that. This was something that Patricio and I recognized when we did >>> the MacOSX workaround; it's not completely bullet proof. >>> >>> However, with the current mechanism of allocating pthread_mutex/cond_t >>> pairs and freelisting them, we highwater pretty quickly. We don't have >>> many places that actually release them. (I don't remember whether >>> there's anything other than the task terminator mechanism.) And once >>> we've highwatered, the VM is safe from any further condvar >>> destructions by non-VM code. So the only risk is from native code >>> using pthread_cond_t's before that highwater mark is reached. >>> >>> If the VM only freelists its pthread_cond_t's and not its >>> pthread_mutex_t's, instead allocating and deleting the latter normally >>> (as Per suggested and I had originally intended to suggest), then the >>> VM's pthread_mutex_t's are subject to getting scrambled by ongoing >>> non-VM pthread_cond_t usage. >> Yes you are right. I was only thinking about VM usage, but if the VM is hosted then mutex/condvar could be being used a lot and not using the freelist for the mutex would greatly increase the risk of reintroducing the bug. >> As you say the freelist approach itself is not bullet-proof and I'm now worried about what complex hosting applications may encounter! :( I think we may need to try and engage with Apple to get the full details on this bug so that we know what our exposure may be. I hope they fixed it with an interim patch and not only with a full release update! >> So in terms of this RFE I leave things as they stand, with the mutex/cond freelist being used in PlatformMutex. I hope the slight space wastage is not significant enough to mean that Zlocks will not consider using PlatformMutex. > > It would be really interesting to know if this has been fixed by Apple, and hopefully also backported to the macos versions we support. On systems that has this bug, we could have all kinds of random VM memory corruption (caused by e.g. native code/library using condvars), which we can't fix. Right? The symptoms of the bug are (1) mutex_unlock aborts, or (2) mutex_lock hangs. Both quite bad, but neither is random memory corruption. Patricio created a standalone reproducer and attached it to JDK-8218975 (stale_entry_test.c). (It was also included in the bug report Patricio filed with Apple. It seems only the person filing a bug has external visibility on its status.) There were some possibly relevant code changes in Mojave, but I don't know if anyone has tried running that test on Mojave. > May I propose a third alternative, which keeps the best of both worlds: Don't mix the two types, i.e. don't let PlatforMonitor inherit from PlatformMutex. So, we'd just keep exactly what we have and just add a PlatformMutex type, which for posix would be just: > > class PlatformMutex : public CHeapObj { This doesn't help, if PlatformMutex's get dynamically allocated on an ongoing basis. The pthread_mutex_t might end up being at the same address as some problematic pthread_cond_t that was allocated, used, and freed by 3rd party code. We could forbid such usage. Or perhaps we could use arena allocation for PlatformMutex? Fixed arena size, allocated up front, would prevent later 3rd party condvar releases from clobbering our mutexes. It still doesn't help against an already bad destroyed condvar existing when the VM is started. But that's not new; we don't have any way to protect against that. From christoph.langer at sap.com Wed Aug 7 21:30:55 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 7 Aug 2019 21:30:55 +0000 Subject: RFR [XS] : 8229182: runtime/containers/docker/TestMemoryAwareness.java test fails on SLES12 In-Reply-To: <0924470c2bac638fa1feab7d63ee71a57904e408.camel@redhat.com> References: <6563ed4bd315281320e11755597fec24f4092ded.camel@redhat.com> <0924470c2bac638fa1feab7d63ee71a57904e408.camel@redhat.com> Message-ID: Hi Matthias, looks good to me in general. However, I'm not convinced that line 114 ".shouldContain("java.lang.OutOfMemoryError");" won't provoke a test error in case the child process was killed by the container, e.g. exited with exit code 137. We should at least run this patch for several days in our system to see if it catches all variations of the problem. Best regards Christoph > -----Original Message----- > From: Severin Gehwolf > Sent: Mittwoch, 7. August 2019 18:55 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' > Cc: Bob Vandette ; Langer, Christoph > > Subject: Re: RFR [XS] : 8229182: > runtime/containers/docker/TestMemoryAwareness.java test fails on SLES12 > > On Wed, 2019-08-07 at 15:46 +0000, Baesken, Matthias wrote: > > http://cr.openjdk.java.net/~mbaesken/webrevs/8229182.1/ > > Looks good to me. > > Thanks, > Severin From coleen.phillimore at oracle.com Wed Aug 7 21:33:18 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 7 Aug 2019 17:33:18 -0400 Subject: RFR: 8229258: Make markOopDesc AllStatic In-Reply-To: References: Message-ID: <8d1e372a-2b4f-b573-c73f-22065333b2ef@oracle.com> I clicked through the cpu, oops, prims, runtime and sa directories. All changes as expected.? Went through synchronizer.cpp too fast though, somebody else should read that more carefully. https://cr.openjdk.java.net/~stefank/8229258/webrev.01/src/hotspot/share/oops/oop.inline.hpp.udiff.html -markOop oopDesc::mark() const { +markWord oopDesc::mark() const { return HeapAccess::load_at(as_oop(), mark_offset_in_bytes()); } -markOop oopDesc::mark_raw() const { +markWord oopDesc::mark_raw() const { return _mark; } Nit, can you take out these blanks before 'const' while you're editing these lines.? They don't line up with anything. Removing the commented out SA code makes sense to me.? There are two test directories for the SA.? One is here: open/test/jdk/sun/tools/jhsdb This looks great!? Thank you! Coleen On 8/7/19 3:58 PM, Stefan Karlsson wrote: > Hi all, > > Please review this patch to make markOopDesc AllStatic. > > https://cr.openjdk.java.net/~stefank/8229258/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8229258 > > From the RFE: > > I want to change/rename markOop and markOopDesc > > Today markOopDescs inherits from oopDesc even though they are not > oopDescs (Java objects): > ?`class markOopDesc : public oopDesc {` > > This is very confusing to new-comers (and probably to old-timers as > well). > > A simple fix would be to break the inheritance and do the following > rename: > markOopDesc -> MarkWord > markOop -> markWord > > However, there are more dubious code in this area. markOopDescs are > created and used like this: > > ``` > class oopDesc { > ... > ? volatile markOop _mark; > ... > markOop? oopDesc::mark_raw()? const { return _mark; } > ... > // Usage > obj->mark_raw()->is_marked() > ... > // Implementation > ? bool is_marked()?? const { > ??? return (mask_bits(value(), lock_mask_in_place) == marked_value); > ? } > ... > // Implementation > ? bool is_being_inflated() const { return (value() == 0); } > ... > // Implementation of markOopDesc::value() > ? uintptr_t value() const { return (uintptr_t) this; } > ``` > > Remember, _mark is an arbitrary bit pattern describing the object. We > treat it as if it were a pointer to a markOopDesc object, but it's not > pointing to such an object. While using that (weird) pointer we call > value() and extract it's bit pattern to be used for further bit > pattern checking functions. AFAICT, this is also undefined behavior. > At least is_being_inflated() const is effectively 'return (uintptr_t) > this == NULL'. This UB was recently discussed here: > ?https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-July/038704.html > > ?https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-July/038712.html > > > I propose that we change MarkWord (markOopDesc) to be an AllStatic > class instead and get rid of this (ab)use of the markWord (markOop) > pointer. > > The patch is large but mostly straight forward. However, there is some > Java code that would need some extra scrutiny: SA and JVMCI. > > Tested with tier1-3. > > Coleen has asked for file rename from markOop.hpp to markWord.hpp. I'd > like to do that as a separate RFE when/if this patch gets accepted. > > Thanks, > StefanK > From rkennke at redhat.com Wed Aug 7 21:59:35 2019 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 7 Aug 2019 23:59:35 +0200 Subject: RFR: 8229258: Make markOopDesc AllStatic In-Reply-To: References: Message-ID: Oh yeah! My IDE completed some operation on markOopDesc to something that is actually in oopDesc (and would map to something else in markOopDesc) more than once and left me wondering. E.g. oopDesc::is_forwarded() which would be markOopDesc::is_marked(). Calling mark->is_forwarded() seems the obvious thing, but is totally foobared. So yeah, this is *very* welcome. I guess the changes are alright and mostly mechanical, but I'll take a deeper look tomorrow, when I'm not tired ;-) Thanks & cheers, Roman > Hi all, > > Please review this patch to make markOopDesc AllStatic. > > https://cr.openjdk.java.net/~stefank/8229258/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8229258 > > From the RFE: > > I want to change/rename markOop and markOopDesc > > Today markOopDescs inherits from oopDesc even though they are not > oopDescs (Java objects): > ?`class markOopDesc : public oopDesc {` > > This is very confusing to new-comers (and probably to old-timers as well). > > A simple fix would be to break the inheritance and do the following rename: > markOopDesc -> MarkWord > markOop -> markWord > > However, there are more dubious code in this area. markOopDescs are > created and used like this: > > ``` > class oopDesc { > ... > ? volatile markOop _mark; > ... > markOop? oopDesc::mark_raw()? const { return _mark; } > ... > // Usage > obj->mark_raw()->is_marked() > ... > // Implementation > ? bool is_marked()?? const { > ??? return (mask_bits(value(), lock_mask_in_place) == marked_value); > ? } > ... > // Implementation > ? bool is_being_inflated() const { return (value() == 0); } > ... > // Implementation of markOopDesc::value() > ? uintptr_t value() const { return (uintptr_t) this; } > ``` > > Remember, _mark is an arbitrary bit pattern describing the object. We > treat it as if it were a pointer to a markOopDesc object, but it's not > pointing to such an object. While using that (weird) pointer we call > value() and extract it's bit pattern to be used for further bit pattern > checking functions. AFAICT, this is also undefined behavior. At least > is_being_inflated() const is effectively 'return (uintptr_t) this == > NULL'. This UB was recently discussed here: > ?https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-July/038704.html > ?https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-July/038712.html > > I propose that we change MarkWord (markOopDesc) to be an AllStatic class > instead and get rid of this (ab)use of the markWord (markOop) pointer. > > The patch is large but mostly straight forward. However, there is some > Java code that would need some extra scrutiny: SA and JVMCI. > > Tested with tier1-3. > > Coleen has asked for file rename from markOop.hpp to markWord.hpp. I'd > like to do that as a separate RFE when/if this patch gets accepted. > > Thanks, > StefanK > From david.holmes at oracle.com Wed Aug 7 23:39:30 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 8 Aug 2019 09:39:30 +1000 Subject: RFR (S): 8228857: Refactor PlatformMonitor into PlatformMutex and PlatformMonitor In-Reply-To: <1cfbd3a0-cc22-726d-dbcf-636697216292@oracle.com> References: <03a9ed9b-b11d-dbdd-d785-76951c3748ab@oracle.com> <6bc5807b-53ed-f103-6477-6162ba5a14a3@oracle.com> <3c83dc0b-e001-71f2-c42a-8c9f7e793764@oracle.com> <07f195ed-cd45-2a7e-30d4-5e63f01edbae@oracle.com> <6D502C87-B9F0-476B-ACC4-E406A7F0DF8E@oracle.com> <1cfbd3a0-cc22-726d-dbcf-636697216292@oracle.com> Message-ID: Hi Per, As Kim stated your suggestion doesn't really help as this is about allocation not inheritance/subtyping. To avoid the bug as much as possible we need to be able to maintain control over allocation of the pthread_mutex_t. But if we do that independent of the allocation of the pthread_cond_t then we are still exposed. Perhaps two freelists ... My main concern with the freelists is that if we use PlatformMutex for something dynamic like Zlocks then we may hit allocation pathologies. Thanks, David On 7/08/2019 11:50 pm, Per Liden wrote: > Hi Kim/David, > > On 8/7/19 12:10 AM, David Holmes wrote: > [...] >>> It is true that only a pthread_cond_t that has been allocated and >>> later destroyed can cause problems. However, we (the VM) might not be >>> the only place doing such. Native code, library code, &etc might also >>> do that. Even the current mechanism doesn't fully protect us from >>> that. This was something that Patricio and I recognized when we did >>> the MacOSX workaround; it's not completely bullet proof. >>> >>> However, with the current mechanism of allocating pthread_mutex/cond_t >>> pairs and freelisting them, we highwater pretty quickly. We don't have >>> many places that actually release them. (I don't remember whether >>> there's anything other than the task terminator mechanism.) And once >>> we've highwatered, the VM is safe from any further condvar >>> destructions by non-VM code. So the only risk is from native code >>> using pthread_cond_t's before that highwater mark is reached. >>> >>> If the VM only freelists its pthread_cond_t's and not its >>> pthread_mutex_t's, instead allocating and deleting the latter normally >>> (as Per suggested and I had originally intended to suggest), then the >>> VM's pthread_mutex_t's are subject to getting scrambled by ongoing >>> non-VM pthread_cond_t usage. >> >> Yes you are right. I was only thinking about VM usage, but if the VM >> is hosted then mutex/condvar could be being used a lot and not using >> the freelist for the mutex would greatly increase the risk of >> reintroducing the bug. >> >> As you say the freelist approach itself is not bullet-proof and I'm >> now worried about what complex hosting applications may encounter! :( >> I think we may need to try and engage with Apple to get the full >> details on this bug so that we know what our exposure may be. I hope >> they fixed it with an interim patch and not only with a full release >> update! >> >> So in terms of this RFE I leave things as they stand, with the >> mutex/cond freelist being used in PlatformMutex. I hope the slight >> space wastage is not significant enough to mean that Zlocks will not >> consider using PlatformMutex. > > It would be really interesting to know if this has been fixed by Apple, > and hopefully also backported to the macos versions we support. On > systems that has this bug, we could have all kinds of random VM memory > corruption (caused by e.g. native code/library using condvars), which we > can't fix. Right? > > May I propose a third alternative, which keeps the best of both worlds: > Don't mix the two types, i.e. don't let PlatforMonitor inherit from > PlatformMutex. So, we'd just keep exactly what we have and just add a > PlatformMutex type, which for posix would be just: > > class PlatformMutex : public CHeapObj { > ?protected: > ? pthread_mutex_t _mutex; > > ?public: > ? PlatformMutex(); > ? ~PlatformMutex(); > > ? void lock(); > ? void unlock(); > ? bool try_lock(); > }; > > os::PlatformMutex::PlatformMutex() { > ? int status = pthread_mutex_init(&_mutex, _mutexAttr); > ? assert_status(status == 0, status, "mutex_init"); > } > > os::PlatformMutex::~PlatformMutex() { > ? int status = pthread_mutex_destroy(&_mutex); > ? assert_status(status == 0, status, "mutex_destroy"); > } > > inline void os::PlatformMutex::lock() { > ? int status = pthread_mutex_lock(&_mutex); > ? assert_status(status == 0, status, "mutex_lock"); > } > > inline void os::PlatformMutex::unlock() { > ? int status = pthread_mutex_unlock(&_mutex); > ? assert_status(status == 0, status, "mutex_unlock"); > } > > inline bool os::PlatformMutex::try_lock() { > ? int status = pthread_mutex_trylock(&_mutex); > ? assert_status(status == 0 || status == EBUSY, status, "mutex_trylock"); > ? return status == 0; > } > > cheers, > Per From jwkozaczuk at gmail.com Thu Aug 8 01:48:31 2019 From: jwkozaczuk at gmail.com (Waldek Kozaczuk) Date: Wed, 7 Aug 2019 21:48:31 -0400 Subject: Jetty hangs early on Java 12 on OSv with Threadlocal Handshakes ON - shorter version Message-ID: Hi, I am one of the committers to the OSv project (http://osv.io/). OSv is is a Linux-compatible unikernel. OSv has been able to run unmodified Linux version of Java very well since early on including Java 7 all the way to Java 11. However, I have discovered some problems with the latest version of Java 12. I essence when I try to start a demo version of Jetty app on Java 12 (specifically jdk-zulu12.3.11-ca-*jdk12.0.2*-linux_x64) on OSv it hangs after printing a single log message (once I saw it print 3-4 lines and hang after) which looks like this: OSv v0.53.0-73-gd7054e0b eth0: 192.168.122.15 Booted up in 135.69 ms fpathconf() stubbed 2019-08-07 19:04:13.758:INFO::main: Logging initialized @797ms Please note the last line from Jetty. When I run the exact same app on Java 11 (jdk-zulu11.33.15-ca*-jdk11.0.4*-linux_x64) on OSv, it starts just fine: OSv v0.53.0-73-gd7054e0b eth0: 192.168.122.15 Booted up in 138.25 ms fpathconf() stubbed 2019-08-07 22:28:50.284:INFO::main: Logging initialized @726ms 2019-08-07 22:28:50.536:WARN::main: demo test-realm is deployed. DO NOT USE IN PRODUCTION! 2019-08-07 22:28:50.539:INFO:oejs.Server:main: jetty-9.2.11.v20150529 2019-08-07 22:28:50.552:INFO:oejdp.ScanningAppProvider:main: Deployment monitor [file:/jetty/demo-base/webapps/] at interval 1 2019-08-07 22:28:50.879:WARN::main: test webapp is deployed. DO NOT USE IN PRODUCTION! 2019-08-07 22:28:51.279:INFO:oejsh.ContextHandler:main: Started o.e.j.w.WebAppContext at 1ffaf86 {/test,file:/tmp/jetty-0.0.0.0-8080-test.war-_test-any-5466198194536157666.dir/webapp/,AVAILABLE}{/test.war} 2019-08-07 22:28:51.392:WARN::main: test-spec webapp is deployed. DO NOT USE IN PRODUCTION! Calling TestListener.contextInitialized 2019-08-07 22:28:51.466:INFO:oejsh.ContextHandler:main: Started o.e.j.w.WebAppContext at 4bef0fe3{/test-spec,[file:/tmp/jetty-0.0.0.0-8080-test-spec.war-_test-spec-any-17979710061364402379.dir/webapp/, jar:file:/tmp/jetty-0.0.0.0-8080-test-spec.war-_test-spec-any-17979710061364402379.dir/webapp/WEB-INF/lib/test-web-fragment-9.2.11.v20150529.jar!/META-INF/resources],AVAILABLE}{/test-spec.war} 2019-08-07 22:28:51.480:INFO:oejsh.ContextHandler:main: Started o.e.j.s.h.MovedContextHandler at 18245eb0{/oldContextPath,null,AVAILABLE} 2019-08-07 22:28:51.517:WARN::main: test-jaas webapp is deployed. DO NOT USE IN PRODUCTION! 2019-08-07 22:28:51.563:INFO:oejsh.ContextHandler:main: Started o.e.j.w.WebAppContext at 6d0b5baf {/test-jaas,file:/tmp/jetty-0.0.0.0-8080-test-jaas.war-_test-jaas-any-4900956465487745831.dir/webapp/,AVAILABLE}{/test-jaas.war} 2019-08-07 22:28:51.618:INFO:oejsh.ContextHandler:main: Started o.e.j.w.WebAppContext at 36b0fcd5 {/,file:/jetty/demo-base/webapps/ROOT/,AVAILABLE}{/ROOT} 2019-08-07 22:28:51.678:WARN::main: test-jndi webapp is deployed. DO NOT USE IN PRODUCTION! 2019-08-07 22:28:51.712:INFO:oejsh.ContextHandler:main: Started o.e.j.w.WebAppContext at 89ff02e {/test-jndi,file:/tmp/jetty-0.0.0.0-8080-test-jndi.war-_test-jndi-any-5186649427965161663.dir/webapp/,AVAILABLE}{/test-jndi.war} 2019-08-07 22:28:51.853:INFO:oejsh.ContextHandler:main: Started o.e.j.w.WebAppContext at 12cd9150 {/proxy,file:/tmp/jetty-0.0.0.0-8080-xref-proxy.war-_xref-proxy-any-18424004387378155009.dir/webapp/,AVAILABLE}{/xref-proxy.war} 2019-08-07 22:28:51.953:WARN::main: async-rest webapp is deployed. DO NOT USE IN PRODUCTION! 2019-08-07 22:28:51.970:INFO:oejsh.ContextHandler:main: Started o.e.j.w.WebAppContext at 473b3b7a{/async-rest,[file:/tmp/jetty-0.0.0.0-8080-async-rest.war-_async-rest-any-18053166809886382856.dir/webapp/, jar:file:/tmp/jetty-0.0.0.0-8080-async-rest.war-_async-rest-any-18053166809886382856.dir/webapp/WEB-INF/lib/example-async-rest-jar-9.2.11.v20150529.jar!/META-INF/resources],AVAILABLE}{/async-rest.war} 2019-08-07 22:28:51.984:INFO:oejs.ServerConnector:main: Started ServerConnector at 2b1a1fd{HTTP/1.1}{0.0.0.0:8080} 2019-08-07 22:28:51.991:INFO:oejs.ServerConnector:main: Started ServerConnector at ad47a4a{SSL-http/1.1}{0.0.0.0:8443} 2019-08-07 22:28:51.993:INFO:oejs.Server:main: Started @2434ms After connecting with gdb I have discovered that one of the JVM threads hangs in a loop while actively calling *sem_trywait*() - see full thread-dump for all Java threads in the bottom of the email): thread 0xffff800004691040 VM Thread #0 0x0000100000c86370 in sem_trywait at plt () #1 0x0000100001702bf2 in PosixSemaphore::trywait() () #2 0x000010000121aab4 in VM_HandshakeAllThreads::doit() () #3 0x000010000198a8d7 in VM_Operation::evaluate() () #4 0x0000100001990706 in VMThread::evaluate_operation(VM_Operation*) [clone .constprop.64] () #5 0x0000100001990e7a in VMThread::loop() () #6 0x0000100001991073 in VMThread::run() () #7 0x00001000019186ff in Thread::call_run() () #8 0x000010000162e1be in thread_native_entry(Thread*) () #9 0x000000004045eeb6 in pthread_private::pthread::::operator() (__closure=0xffffa00003d6d400) at libc/pthread.cc:114 #10 std::_Function_handler >::_M_invoke(const std::_Any_data &) (__functor=...) at /usr/include/c++/8/bits/std_function.h:297 #11 0x0000000040401117 in sched::thread_main_c (t=0xffff800004691040) at arch/x64/arch-switch.hh:271 #12 0x00000000403a71d3 in thread_main () at arch/x64/entry.S:113 (note that frames 9 and above are from OSv as the libc calls are handled as local function calls on OSv). After more research around VM_HandshakeAllThreads (in https://github.com/openjdk/jdk/blob/0fe0312f416add1536a45ecfb292c887ef7e02bd/src/hotspot/share/runtime/handshake.cpp#L152-L208) I have stumbled across this JEP https://openjdk.java.net/jeps/312 - Thread-Local Handshakes) where I realized new cross-threads callback mechanism has been introduced starting in Java 10 to replace "stop-the-world" mechanism (as I understand). I have also found a switch to disable it using the -XX:-ThreadLocalHandshakes switch. So now when I run Jetty app on Java 12 with such command line and disbale TLH: /usr/lib/jvm/jdk-zulu12.3.11-ca-jdk12.0.2-linux_x64/bin/java -Xrs -XX:-ThreadLocalHandshakes -Djetty.base=/jetty/demo-base -jar /jetty/start.jar *it works and does not hang any more:* when this one hangs (TLH explicitly enabled): /usr/lib/jvm/jdk-zulu12.3.11-ca-jdk12.0.2-linux_x64/bin/java -Xrs -XX:+ThreadLocalHandshakes -Djetty.base=/jetty/demo-base -jar /jetty/start.jar When I explicitly enable thread local handshakes on Java 11 it works as well: /usr/lib/jvm/jdk-zulu11.33.15-ca-jdk11.0.4-linux_x64/bin/java -Xrs -XX:+ThreadLocalHandshakes -Djetty.base=/jetty/demo-base -jar /jetty/start.jar Note I am limiting signals usage by JVM in all cases just to narrow down my research. One more datapoint - I am able to run a simple Hello World java app on Java 12 on OSv with thread-local handshakes on so it looks like this problem appears on more complicated apps. *Lastly, the exact same app works fine on Java 12 on Linux.* So given all that could you please point me to what the problem might be? What has changed in the implementation of thread local handshakes between Java 11 and 12 that may have caused this issue (I see many changes made to https://github.com/openjdk/jdk/blob/0fe0312f416add1536a45ecfb292c887ef7e02bd/src/hotspot/share/runtime/handshake.cpp but I am not even sure which commit matches the version of Java 12 or Java 11 I am using)? I am thinking this has to do with some subtle differences between relevant ABI implementation between OSv and Linux. Signals related? Thanks for your help in advance, Waldek Thread dump of all Java threads (in other email that was to big) From kim.barrett at oracle.com Thu Aug 8 01:59:09 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 7 Aug 2019 21:59:09 -0400 Subject: RFR (S): 8228857: Refactor PlatformMonitor into PlatformMutex and PlatformMonitor In-Reply-To: References: Message-ID: <32C9F58D-FA84-4A18-9A43-86DE2F8AD88E@oracle.com> > On Aug 1, 2019, at 7:03 PM, David Holmes wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8228857 > webrev: http://cr.openjdk.java.net/~dholmes/8228857/webrev/ > > As suggested by Per Liden when PlatformMonitor was introduced by JDK-8210832 we should refactor PlatformMonitor into a simpler PlatformMutex extended by PlatformMonitor. That would potentially allow other synchronization objects e.g. Zlocks, to be replaced by a suitable PlatformX class, and allows us to redefine JVM_RawMonitor support to use it (forthcoming change). > > The refactoring would be obvious and simple if not for the macOS PThread allocation bug workaround. I had to change the Posix variant so that we only use the Impl helper class on macOS, so that we can separate the allocation of the pthread_mutex_t and pthread_cond_t. For macOS both get allocated in the PlatformMutex. > > There are not actual usage changes in this RFE. > > Testing: mach5 tiers 1-3 > > Thanks, > David > ----- PlatformMutex should be noncopyable on all platforms. The inheritance runs the risk of destructor slicing, because the PlatformMutex base class has a public non-virtual destructor. I don't think we want to introduce a virtual destructor here. I don't know of a solution that doesn't lose the inheritance relationship between the classes. I don't know if that relationship is considered important. From david.holmes at oracle.com Thu Aug 8 02:40:49 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 8 Aug 2019 12:40:49 +1000 Subject: Jetty hangs early on Java 12 on OSv with Threadlocal Handshakes ON - shorter version In-Reply-To: References: Message-ID: <91340eda-1777-779b-3231-a58823bb5b8c@oracle.com> Hi Waldek, The full thread dump is missing (not surprisingly on the mailing lists). Can you please send it directly to me. I will open a bug with the information below and add the full thread-dump when I receive it. Thanks, David On 8/08/2019 11:48 am, Waldek Kozaczuk wrote: > Hi, > > I am one of the committers to the OSv project (http://osv.io/). OSv is is a > Linux-compatible unikernel. OSv has been able to run unmodified Linux > version of Java very well since early on including Java 7 all the way to > Java 11. However, I have discovered some problems with the latest version > of Java 12. > > I essence when I try to start a demo version of Jetty app on Java 12 > (specifically jdk-zulu12.3.11-ca-*jdk12.0.2*-linux_x64) on OSv it hangs > after printing a single log message (once I saw it print 3-4 lines and hang > after) which looks like this: > > OSv v0.53.0-73-gd7054e0b > > eth0: 192.168.122.15 > > Booted up in 135.69 ms > > fpathconf() stubbed > > 2019-08-07 19:04:13.758:INFO::main: Logging initialized @797ms > > Please note the last line from Jetty. When I run the exact same app on Java > 11 (jdk-zulu11.33.15-ca*-jdk11.0.4*-linux_x64) on OSv, it starts just fine: > > OSv v0.53.0-73-gd7054e0b > > eth0: 192.168.122.15 > > Booted up in 138.25 ms > > fpathconf() stubbed > > 2019-08-07 22:28:50.284:INFO::main: Logging initialized @726ms > > 2019-08-07 22:28:50.536:WARN::main: demo test-realm is deployed. DO NOT USE > IN PRODUCTION! > > 2019-08-07 22:28:50.539:INFO:oejs.Server:main: jetty-9.2.11.v20150529 > > 2019-08-07 22:28:50.552:INFO:oejdp.ScanningAppProvider:main: Deployment > monitor [file:/jetty/demo-base/webapps/] at interval 1 > > 2019-08-07 22:28:50.879:WARN::main: test webapp is deployed. DO NOT USE IN > PRODUCTION! > > 2019-08-07 22:28:51.279:INFO:oejsh.ContextHandler:main: Started > o.e.j.w.WebAppContext at 1ffaf86 > {/test,file:/tmp/jetty-0.0.0.0-8080-test.war-_test-any-5466198194536157666.dir/webapp/,AVAILABLE}{/test.war} > > 2019-08-07 22:28:51.392:WARN::main: test-spec webapp is deployed. DO NOT > USE IN PRODUCTION! > > Calling TestListener.contextInitialized > > 2019-08-07 22:28:51.466:INFO:oejsh.ContextHandler:main: Started > o.e.j.w.WebAppContext at 4bef0fe3{/test-spec,[file:/tmp/jetty-0.0.0.0-8080-test-spec.war-_test-spec-any-17979710061364402379.dir/webapp/, > jar:file:/tmp/jetty-0.0.0.0-8080-test-spec.war-_test-spec-any-17979710061364402379.dir/webapp/WEB-INF/lib/test-web-fragment-9.2.11.v20150529.jar!/META-INF/resources],AVAILABLE}{/test-spec.war} > > 2019-08-07 22:28:51.480:INFO:oejsh.ContextHandler:main: Started > o.e.j.s.h.MovedContextHandler at 18245eb0{/oldContextPath,null,AVAILABLE} > > 2019-08-07 22:28:51.517:WARN::main: test-jaas webapp is deployed. DO NOT > USE IN PRODUCTION! > > 2019-08-07 22:28:51.563:INFO:oejsh.ContextHandler:main: Started > o.e.j.w.WebAppContext at 6d0b5baf > {/test-jaas,file:/tmp/jetty-0.0.0.0-8080-test-jaas.war-_test-jaas-any-4900956465487745831.dir/webapp/,AVAILABLE}{/test-jaas.war} > > 2019-08-07 22:28:51.618:INFO:oejsh.ContextHandler:main: Started > o.e.j.w.WebAppContext at 36b0fcd5 > {/,file:/jetty/demo-base/webapps/ROOT/,AVAILABLE}{/ROOT} > > 2019-08-07 22:28:51.678:WARN::main: test-jndi webapp is deployed. DO NOT > USE IN PRODUCTION! > > 2019-08-07 22:28:51.712:INFO:oejsh.ContextHandler:main: Started > o.e.j.w.WebAppContext at 89ff02e > {/test-jndi,file:/tmp/jetty-0.0.0.0-8080-test-jndi.war-_test-jndi-any-5186649427965161663.dir/webapp/,AVAILABLE}{/test-jndi.war} > > 2019-08-07 22:28:51.853:INFO:oejsh.ContextHandler:main: Started > o.e.j.w.WebAppContext at 12cd9150 > {/proxy,file:/tmp/jetty-0.0.0.0-8080-xref-proxy.war-_xref-proxy-any-18424004387378155009.dir/webapp/,AVAILABLE}{/xref-proxy.war} > > 2019-08-07 22:28:51.953:WARN::main: async-rest webapp is deployed. DO NOT > USE IN PRODUCTION! > > 2019-08-07 22:28:51.970:INFO:oejsh.ContextHandler:main: Started > o.e.j.w.WebAppContext at 473b3b7a{/async-rest,[file:/tmp/jetty-0.0.0.0-8080-async-rest.war-_async-rest-any-18053166809886382856.dir/webapp/, > jar:file:/tmp/jetty-0.0.0.0-8080-async-rest.war-_async-rest-any-18053166809886382856.dir/webapp/WEB-INF/lib/example-async-rest-jar-9.2.11.v20150529.jar!/META-INF/resources],AVAILABLE}{/async-rest.war} > > 2019-08-07 22:28:51.984:INFO:oejs.ServerConnector:main: Started > ServerConnector at 2b1a1fd{HTTP/1.1}{0.0.0.0:8080} > > 2019-08-07 22:28:51.991:INFO:oejs.ServerConnector:main: Started > ServerConnector at ad47a4a{SSL-http/1.1}{0.0.0.0:8443} > > 2019-08-07 22:28:51.993:INFO:oejs.Server:main: Started @2434ms > > After connecting with gdb I have discovered that one of the JVM threads > hangs in a loop while actively calling *sem_trywait*() - see full > thread-dump for all Java threads in the bottom of the email): > > thread 0xffff800004691040 VM Thread > > > #0 0x0000100000c86370 in sem_trywait at plt () > > #1 0x0000100001702bf2 in PosixSemaphore::trywait() () > > #2 0x000010000121aab4 in VM_HandshakeAllThreads::doit() () > > #3 0x000010000198a8d7 in VM_Operation::evaluate() () > > #4 0x0000100001990706 in VMThread::evaluate_operation(VM_Operation*) > [clone .constprop.64] () > > #5 0x0000100001990e7a in VMThread::loop() () > > #6 0x0000100001991073 in VMThread::run() () > > #7 0x00001000019186ff in Thread::call_run() () > > #8 0x000010000162e1be in thread_native_entry(Thread*) () > > #9 0x000000004045eeb6 in pthread_private::pthread::::operator() > (__closure=0xffffa00003d6d400) at libc/pthread.cc:114 > > #10 std::_Function_handler (*)(void*), void*, sigset_t, const > pthread_private::thread_attr*):: >::_M_invoke(const > std::_Any_data &) (__functor=...) > > at /usr/include/c++/8/bits/std_function.h:297 > > #11 0x0000000040401117 in sched::thread_main_c (t=0xffff800004691040) at > arch/x64/arch-switch.hh:271 > > #12 0x00000000403a71d3 in thread_main () at arch/x64/entry.S:113 > > (note that frames 9 and above are from OSv as the libc calls are handled as > local function calls on OSv). > > After more research around VM_HandshakeAllThreads (in > https://github.com/openjdk/jdk/blob/0fe0312f416add1536a45ecfb292c887ef7e02bd/src/hotspot/share/runtime/handshake.cpp#L152-L208) > I have stumbled across this JEP https://openjdk.java.net/jeps/312 - > Thread-Local Handshakes) where I realized new cross-threads callback > mechanism has been introduced starting in Java 10 to replace > "stop-the-world" mechanism (as I understand). I have also found a switch to > disable it using the -XX:-ThreadLocalHandshakes switch. > > So now when I run Jetty app on Java 12 with such command line and disbale > TLH: > > /usr/lib/jvm/jdk-zulu12.3.11-ca-jdk12.0.2-linux_x64/bin/java -Xrs > -XX:-ThreadLocalHandshakes -Djetty.base=/jetty/demo-base -jar > /jetty/start.jar > *it works and does not hang any more:* > > when this one hangs (TLH explicitly enabled): > > /usr/lib/jvm/jdk-zulu12.3.11-ca-jdk12.0.2-linux_x64/bin/java -Xrs > -XX:+ThreadLocalHandshakes -Djetty.base=/jetty/demo-base -jar > /jetty/start.jar > > When I explicitly enable thread local handshakes on Java 11 it works as > well: > > /usr/lib/jvm/jdk-zulu11.33.15-ca-jdk11.0.4-linux_x64/bin/java -Xrs > -XX:+ThreadLocalHandshakes -Djetty.base=/jetty/demo-base -jar > /jetty/start.jar > > Note I am limiting signals usage by JVM in all cases just to narrow down my > research. > > One more datapoint - I am able to run a simple Hello World java app on Java > 12 on OSv with thread-local handshakes on so it looks like this problem > appears on more complicated apps. > > *Lastly, the exact same app works fine on Java 12 on Linux.* > > So given all that could you please point me to what the problem might be? > What has changed in the implementation of thread local handshakes between > Java 11 and 12 that may have caused this issue (I see many changes made to > https://github.com/openjdk/jdk/blob/0fe0312f416add1536a45ecfb292c887ef7e02bd/src/hotspot/share/runtime/handshake.cpp > but > I am not even sure which commit matches the version of Java 12 or Java 11 I > am using)? I am thinking this has to do with some subtle differences > between relevant ABI implementation between OSv and Linux. Signals related? > > Thanks for your help in advance, > > Waldek > > Thread dump of all Java threads (in other email that was to big) > From david.holmes at oracle.com Thu Aug 8 02:51:41 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 8 Aug 2019 12:51:41 +1000 Subject: RFR (S): 8228857: Refactor PlatformMonitor into PlatformMutex and PlatformMonitor In-Reply-To: <32C9F58D-FA84-4A18-9A43-86DE2F8AD88E@oracle.com> References: <32C9F58D-FA84-4A18-9A43-86DE2F8AD88E@oracle.com> Message-ID: <85649d80-f85e-4da0-dd4c-db148b33d5e8@oracle.com> Hi Kim, On 8/08/2019 11:59 am, Kim Barrett wrote: >> On Aug 1, 2019, at 7:03 PM, David Holmes wrote: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8228857 >> webrev: http://cr.openjdk.java.net/~dholmes/8228857/webrev/ >> >> As suggested by Per Liden when PlatformMonitor was introduced by JDK-8210832 we should refactor PlatformMonitor into a simpler PlatformMutex extended by PlatformMonitor. That would potentially allow other synchronization objects e.g. Zlocks, to be replaced by a suitable PlatformX class, and allows us to redefine JVM_RawMonitor support to use it (forthcoming change). >> >> The refactoring would be obvious and simple if not for the macOS PThread allocation bug workaround. I had to change the Posix variant so that we only use the Impl helper class on macOS, so that we can separate the allocation of the pthread_mutex_t and pthread_cond_t. For macOS both get allocated in the PlatformMutex. >> >> There are not actual usage changes in this RFE. >> >> Testing: mach5 tiers 1-3 >> >> Thanks, >> David >> ----- > > PlatformMutex should be noncopyable on all platforms. I presume that is something PlatformMonitor should already be doing but is not? What is involved in making something non-copyable? (Sorry my basic C++ is pretty basic.) > The inheritance runs the risk of destructor slicing, because the > PlatformMutex base class has a public non-virtual destructor. I don't > think we want to introduce a virtual destructor here. I don't know of > a solution that doesn't lose the inheritance relationship between the > classes. I don't know if that relationship is considered important. Semantically a Monitor (as we define it) is a Mutex with a condition variable, so the inheritance seems quite appropriate, even if not essential. IIUC the issue is when we have a PlatformMutex* that happens to point to a PlatformMonitor - if we delete it then we only call the PlatformMutex destructor. Why would we not just declare the destructor as virtual? What will it cost us? It seems the natural/right way to deal with inheritance in C++. Thanks, David ----- From david.holmes at oracle.com Thu Aug 8 04:05:27 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 8 Aug 2019 14:05:27 +1000 Subject: Jetty hangs early on Java 12 on OSv with Threadlocal Handshakes ON - shorter version In-Reply-To: <91340eda-1777-779b-3231-a58823bb5b8c@oracle.com> References: <91340eda-1777-779b-3231-a58823bb5b8c@oracle.com> Message-ID: Hi Waldek, I have filed: https://bugs.openjdk.java.net/browse/JDK-8229263 but I would have to suspect something OSv specific here. Can you test on latest JDK 13 EA available here: https://jdk.java.net/13/ Are you able to download and build a fastdebug JVM locally? Thanks, David ----- On 8/08/2019 12:40 pm, David Holmes wrote: > Hi Waldek, > > The full thread dump is missing (not surprisingly on the mailing lists). > Can you please send it directly to me. I will open a bug with the > information below and add the full thread-dump when I receive it. > > Thanks, > David > > On 8/08/2019 11:48 am, Waldek Kozaczuk wrote: >> Hi, >> >> I am one of the committers to the OSv project (http://osv.io/). OSv is >> is a >> Linux-compatible unikernel. OSv has been able to run unmodified Linux >> version of Java very well since early on including Java 7 all the way to >> Java 11. However, I have discovered some problems with the latest version >> of Java 12. >> >> I essence when I try to start a demo version of Jetty app on Java 12 >> (specifically jdk-zulu12.3.11-ca-*jdk12.0.2*-linux_x64) on OSv it hangs >> after printing a single log message (once I saw it print 3-4 lines and >> hang >> after) which looks like this: >> >> OSv v0.53.0-73-gd7054e0b >> >> eth0: 192.168.122.15 >> >> Booted up in 135.69 ms >> >> fpathconf() stubbed >> >> 2019-08-07 19:04:13.758:INFO::main: Logging initialized @797ms >> >> Please note the last line from Jetty. When I run the exact same app on >> Java >> 11 (jdk-zulu11.33.15-ca*-jdk11.0.4*-linux_x64) on OSv, it starts just >> fine: >> >> OSv v0.53.0-73-gd7054e0b >> >> eth0: 192.168.122.15 >> >> Booted up in 138.25 ms >> >> fpathconf() stubbed >> >> 2019-08-07 22:28:50.284:INFO::main: Logging initialized @726ms >> >> 2019-08-07 22:28:50.536:WARN::main: demo test-realm is deployed. DO >> NOT USE >> IN PRODUCTION! >> >> 2019-08-07 22:28:50.539:INFO:oejs.Server:main: jetty-9.2.11.v20150529 >> >> 2019-08-07 22:28:50.552:INFO:oejdp.ScanningAppProvider:main: Deployment >> monitor [file:/jetty/demo-base/webapps/] at interval 1 >> >> 2019-08-07 22:28:50.879:WARN::main: test webapp is deployed. DO NOT >> USE IN >> PRODUCTION! >> >> 2019-08-07 22:28:51.279:INFO:oejsh.ContextHandler:main: Started >> o.e.j.w.WebAppContext at 1ffaf86 >> {/test,file:/tmp/jetty-0.0.0.0-8080-test.war-_test-any-5466198194536157666.dir/webapp/,AVAILABLE}{/test.war} >> >> >> 2019-08-07 22:28:51.392:WARN::main: test-spec webapp is deployed. DO NOT >> USE IN PRODUCTION! >> >> Calling TestListener.contextInitialized >> >> 2019-08-07 22:28:51.466:INFO:oejsh.ContextHandler:main: Started >> o.e.j.w.WebAppContext at 4bef0fe3{/test-spec,[file:/tmp/jetty-0.0.0.0-8080-test-spec.war-_test-spec-any-17979710061364402379.dir/webapp/, >> >> jar:file:/tmp/jetty-0.0.0.0-8080-test-spec.war-_test-spec-any-17979710061364402379.dir/webapp/WEB-INF/lib/test-web-fragment-9.2.11.v20150529.jar!/META-INF/resources],AVAILABLE}{/test-spec.war} >> >> >> 2019-08-07 22:28:51.480:INFO:oejsh.ContextHandler:main: Started >> o.e.j.s.h.MovedContextHandler at 18245eb0{/oldContextPath,null,AVAILABLE} >> >> 2019-08-07 22:28:51.517:WARN::main: test-jaas webapp is deployed. DO NOT >> USE IN PRODUCTION! >> >> 2019-08-07 22:28:51.563:INFO:oejsh.ContextHandler:main: Started >> o.e.j.w.WebAppContext at 6d0b5baf >> {/test-jaas,file:/tmp/jetty-0.0.0.0-8080-test-jaas.war-_test-jaas-any-4900956465487745831.dir/webapp/,AVAILABLE}{/test-jaas.war} >> >> >> 2019-08-07 22:28:51.618:INFO:oejsh.ContextHandler:main: Started >> o.e.j.w.WebAppContext at 36b0fcd5 >> {/,file:/jetty/demo-base/webapps/ROOT/,AVAILABLE}{/ROOT} >> >> 2019-08-07 22:28:51.678:WARN::main: test-jndi webapp is deployed. DO NOT >> USE IN PRODUCTION! >> >> 2019-08-07 22:28:51.712:INFO:oejsh.ContextHandler:main: Started >> o.e.j.w.WebAppContext at 89ff02e >> {/test-jndi,file:/tmp/jetty-0.0.0.0-8080-test-jndi.war-_test-jndi-any-5186649427965161663.dir/webapp/,AVAILABLE}{/test-jndi.war} >> >> >> 2019-08-07 22:28:51.853:INFO:oejsh.ContextHandler:main: Started >> o.e.j.w.WebAppContext at 12cd9150 >> {/proxy,file:/tmp/jetty-0.0.0.0-8080-xref-proxy.war-_xref-proxy-any-18424004387378155009.dir/webapp/,AVAILABLE}{/xref-proxy.war} >> >> >> 2019-08-07 22:28:51.953:WARN::main: async-rest webapp is deployed. DO NOT >> USE IN PRODUCTION! >> >> 2019-08-07 22:28:51.970:INFO:oejsh.ContextHandler:main: Started >> o.e.j.w.WebAppContext at 473b3b7a{/async-rest,[file:/tmp/jetty-0.0.0.0-8080-async-rest.war-_async-rest-any-18053166809886382856.dir/webapp/, >> >> jar:file:/tmp/jetty-0.0.0.0-8080-async-rest.war-_async-rest-any-18053166809886382856.dir/webapp/WEB-INF/lib/example-async-rest-jar-9.2.11.v20150529.jar!/META-INF/resources],AVAILABLE}{/async-rest.war} >> >> >> 2019-08-07 22:28:51.984:INFO:oejs.ServerConnector:main: Started >> ServerConnector at 2b1a1fd{HTTP/1.1}{0.0.0.0:8080} >> >> 2019-08-07 22:28:51.991:INFO:oejs.ServerConnector:main: Started >> ServerConnector at ad47a4a{SSL-http/1.1}{0.0.0.0:8443} >> >> 2019-08-07 22:28:51.993:INFO:oejs.Server:main: Started @2434ms >> >> After connecting with gdb I have discovered that one of the JVM threads >> hangs in a loop while actively calling *sem_trywait*() - see full >> thread-dump for all Java threads in the bottom of the email): >> >> thread 0xffff800004691040 VM Thread >> >> >> #0? 0x0000100000c86370 in sem_trywait at plt () >> >> #1? 0x0000100001702bf2 in PosixSemaphore::trywait() () >> >> #2? 0x000010000121aab4 in VM_HandshakeAllThreads::doit() () >> >> #3? 0x000010000198a8d7 in VM_Operation::evaluate() () >> >> #4? 0x0000100001990706 in VMThread::evaluate_operation(VM_Operation*) >> [clone .constprop.64] () >> >> #5? 0x0000100001990e7a in VMThread::loop() () >> >> #6? 0x0000100001991073 in VMThread::run() () >> >> #7? 0x00001000019186ff in Thread::call_run() () >> >> #8? 0x000010000162e1be in thread_native_entry(Thread*) () >> >> #9? 0x000000004045eeb6 in >> pthread_private::pthread::::operator() >> (__closure=0xffffa00003d6d400) at libc/pthread.cc:114 >> >> #10 std::_Function_handler> pthread_private::pthread::pthread(void* >> (*)(void*), void*, sigset_t, const >> pthread_private::thread_attr*):: >::_M_invoke(const >> std::_Any_data &) (__functor=...) >> >> ???? at /usr/include/c++/8/bits/std_function.h:297 >> >> #11 0x0000000040401117 in sched::thread_main_c (t=0xffff800004691040) at >> arch/x64/arch-switch.hh:271 >> >> #12 0x00000000403a71d3 in thread_main () at arch/x64/entry.S:113 >> >> (note that frames 9 and above are from OSv as the libc calls are >> handled as >> local function calls on OSv). >> >> After more research around VM_HandshakeAllThreads (in >> https://github.com/openjdk/jdk/blob/0fe0312f416add1536a45ecfb292c887ef7e02bd/src/hotspot/share/runtime/handshake.cpp#L152-L208) >> >> I have stumbled across this JEP https://openjdk.java.net/jeps/312 - >> Thread-Local Handshakes) where I realized new cross-threads callback >> mechanism has been introduced starting in Java 10 to replace >> "stop-the-world" mechanism (as I understand). I have also found a >> switch to >> disable it using the -XX:-ThreadLocalHandshakes switch. >> >> So now when I run Jetty app on Java 12 with such command line and disbale >> TLH: >> >> /usr/lib/jvm/jdk-zulu12.3.11-ca-jdk12.0.2-linux_x64/bin/java -Xrs >> -XX:-ThreadLocalHandshakes -Djetty.base=/jetty/demo-base -jar >> /jetty/start.jar >> *it works and does not hang any more:* >> >> when this one hangs (TLH explicitly enabled): >> >> /usr/lib/jvm/jdk-zulu12.3.11-ca-jdk12.0.2-linux_x64/bin/java -Xrs >> -XX:+ThreadLocalHandshakes -Djetty.base=/jetty/demo-base -jar >> /jetty/start.jar >> >> When I explicitly enable thread local handshakes on Java 11 it works as >> well: >> >> /usr/lib/jvm/jdk-zulu11.33.15-ca-jdk11.0.4-linux_x64/bin/java -Xrs >> -XX:+ThreadLocalHandshakes -Djetty.base=/jetty/demo-base -jar >> /jetty/start.jar >> >> Note I am limiting signals usage by JVM in all cases just to narrow >> down my >> research. >> >> One more datapoint - I am able to run a simple Hello World java app on >> Java >> 12 on OSv with thread-local handshakes on so it looks like this problem >> appears on more complicated apps. >> >> *Lastly, the exact same app works fine on Java 12 on Linux.* >> >> So given all that could you please point me to what the problem might be? >> What has changed in the implementation of thread local handshakes between >> Java 11 and 12 that may have caused this issue (I see many changes >> made to >> https://github.com/openjdk/jdk/blob/0fe0312f416add1536a45ecfb292c887ef7e02bd/src/hotspot/share/runtime/handshake.cpp >> >> but >> I am not even sure which commit matches the version of Java 12 or Java >> 11 I >> am using)? I am thinking this has to do with some subtle differences >> between relevant ABI implementation between OSv and Linux. Signals >> related? >> >> Thanks for your help in advance, >> >> Waldek >> >> Thread dump of all Java threads (in other email that was to big) >> From shade at redhat.com Thu Aug 8 06:44:30 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 8 Aug 2019 08:44:30 +0200 Subject: Jetty hangs early on Java 12 on OSv with Threadlocal Handshakes ON - shorter version In-Reply-To: References: <91340eda-1777-779b-3231-a58823bb5b8c@oracle.com> Message-ID: <0a1f26a2-0998-ff5b-6b68-4ed0e12ff529@redhat.com> On 8/8/19 6:05 AM, David Holmes wrote: > Can you test on latest JDK 13 EA available here: > https://jdk.java.net/13/ > > Are you able to download and build a fastdebug JVM locally? Or pick one here: https://builds.shipilev.net/openjdk-jdk12/ https://builds.shipilev.net/openjdk-jdk/ -Aleksey From sanhong.lsh at alibaba-inc.com Thu Aug 8 07:31:03 2019 From: sanhong.lsh at alibaba-inc.com (=?UTF-8?B?5p2O5LiJ57qiKOS4iee6oik=?=) Date: Thu, 08 Aug 2019 15:31:03 +0800 Subject: =?UTF-8?B?562U5aSNOiBSRkM6IEpXYXJtdXAgcHJlY29tcGlsZSBqYXZhIGhvdCBtZXRob2RzIGF0IGFw?= =?UTF-8?B?cGxpY2F0aW9uIHN0YXJ0dXA=?= In-Reply-To: <7e8aeb89-f03f-6736-a687-58bdc84e4440@gmail.com> References: <7e8aeb89-f03f-6736-a687-58bdc84e4440@gmail.com> Message-ID: <009101d54dbb$3c3f1d50$b4bd57f0$@alibaba-inc.com> HI, Thanks Ivan for summary for what we had discussed at JVMLS'19. I agree we have enough evidence at this point many applications, especially those run in 'medium' size of cluster, can benefit from the 'record-and-replay' approach taken by JWarmup/ReadyNow - we got many feedbacks from inside/outside Alibaba who used/tried JWarmup via [1]. In addition to the tiered compilation, profiling-based compilation should be good complementary technology to OpenJDK. We are willing to make JWarmup more general enough, not our own specific, to push to OpenJDK master. As we had discussed during meeting, let's(Alibaba) detail/solid the current JEP [2] to include: comprehensive user story, profiling format, much more detailed internal implementation(how we consider the class initialization order, why we need disable some speculative optimizations etc...), the contract between application and warmup compilation(via trigger API), etc. Hopefully all above should be good start for design discussion(need separate project/mailing list? welcome comments here) [1] https://github.com/alibaba/dragonwell8 [2] https://openjdk.java.net/jeps/8203832 Thanks! Sanhong -----????----- ???: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] ?? Ivan Krylov ????: 2019?8?6? 14:14 ???: hotspot-dev at openjdk.java.net ??: Re: RFC: JWarmup precompile java hot methods at application startup Dear all, I would like to summarize discussions around JWarmup at JVMLS 2019. There were many so I will try to collapse into a smaller email. For the purposes of this discussion I don't represent neither my previous employer Azul Systems, maker of ReadyNow, nor my current employer. The great java warmup problem is a well understood one. This year there is probably not a single java conference without a talk on this subject. Multiple approaches have been developed to tackle this issue, at different layers, in the vanilla OpenJDK and in the alternative JDKs. These include but not limited to CDS/AppCDS, OpenJ9's JIT Cache / Zing Compile Stashing, JWarmUp / ReadyNow, jaotc / graalvm native images, etc. etc. Some of this technologies tackle additional aspects like memory footprint. There is an excellent talk [1] at #JVMLS2019 from Mark Stoodly from IBM with an overview of a landscape of technologies. There seems to be an understanding that there is no 1-size-fits-all solution. This thread is specifically about an approach of saving and using recorded application profiles in subsequent runs of the same application. There are two working solutions that I am aware of: JWarmup in the AlibabaJDK and ReadyNow in Zing. There is nothing in the OpenJDK master of this variety. At this point there is enough evidence, enough production data to say that the approach is beneficial for many large applications and microservices. Alibaba folks have proposed a JEP [2] and a patch [3] to add this functionality. The discussion seems to indicate (and correct me if I am wrong) that as it stands now this patch has a low chance of being accepted. First, reviewers miss a detailed description. What is the user story? Can profiles be uses across multiple jvm version? Across multiple platforms and ISAs? Across changing library code? Is it a self-updating profile or write once kind of? In case of profile on a NFS who's responsibility is to ensure proper locking on a profile? Looking at the internals - there are even more questions? Are compiles conservative or speculative? How method profile data is decoded and populated to the structures consumes by ci layer /jit ? Are class loads infused by a profile reader or done entirely by the application? What about class linking and initialization? What is a success metric? What statistics or monitoring can be used? What would constitute regression testing? On the implementation side It seems to me that the main problem is that the protocol between JVM and a profile provider isn't specified. We need an API perhaps similar in its spirit to the GC Interface [4]. This would allow not to multiplex the regular runtime business and the logic of the profile provider. The file format for persisted data also need some specification including versioning. In my view a feature like JWarmup is much bigger than a one patch. Bigger than one JEP. As for the logistics: I have been away from the hotspot aliases for so long that I am not sure what is the current practice now. May be starting a thread with design discussions is good enough or may be we need a dedicated openjdk project and a dedicated mail list. From my side I can share my experience and knowledge from building such an assisted warmup machinery. There are many lessons that we learned. Some are outlined at this excellent talk from Douglas Hawkins[5]. If you scroll to the end you'll see why we ended doing essentially two passes of the persisted profile application. Thanks, Ivan 1 - https://www.youtube.com/watch?v=gx8DVVFPkcQ 2 - https://openjdk.java.net/jeps/8203832 3 - http://cr.openjdk.java.net/~minqi/8220692/webrev-03/ 4 - https://openjdk.java.net/jeps/304 5 - https://www.youtube.com/watch?v=AGyctnc1DTA&t=1027s On 25/04/2019 19:07, yumin qi wrote: > Hi, > > Apart from comments from compiler professionals can I have comments from > runtime either? The changes mostly land in runtime area. > > Thanks > Yumin > > On Tue, Apr 16, 2019 at 11:27 AM yumin qi wrote: > >> HI, >> >> Did anyone have comments for this version? >> >> Thanks >> Yumin >> >> On Tue, Apr 9, 2019 at 10:36 AM yumin qi wrote: >> >>> Alan, >>> Thanks! Updated in same link: >>> http://cr.openjdk.java.net/~minqi/8220692/webrev-02/ >>> >>> Removed non-boot loader branch in nativeLookup.cpp. >>> Added jdk.jwarmup to boot loader list in make/common/Modules.gmk. >>> Tested again to make sure the new changes. >>> >>> Thanks >>> Yumin >>> >>> >>> On Tue, Apr 9, 2019 at 4:48 AM Alan Bateman >>> wrote: >>> >>>> On 09/04/2019 07:10, yumin qi wrote: >>>>> Now the registerNatives is found when it looks up for native entry >>>>> in lookupNative.cpp. I thought the class JWarmUp will be loaded by >>>>> boot loader like Unsafe or WhiteBox, but I was wrong, it is loaded by >>>>> app class loader so logic for obtaining its native entry put in both >>>>> cases, boot loader and non boot loaders. >>>>> >>>> make/common/Modules.gmk is where BOOT_MODULES is defined with the list >>>> of modules mapped to the boot loader. >>>> >>>> -Alan >>>> From matthias.baesken at sap.com Thu Aug 8 07:43:09 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 8 Aug 2019 07:43:09 +0000 Subject: RFR [XS] : 8229182: runtime/containers/docker/TestMemoryAwareness.java test fails on SLES12 In-Reply-To: References: <6563ed4bd315281320e11755597fec24f4092ded.camel@redhat.com> <0924470c2bac638fa1feab7d63ee71a57904e408.camel@redhat.com> Message-ID: Hi Christoph, > > Hi Matthias, > > looks good to me in general. > > However, I'm not convinced that line 114 > ".shouldContain("java.lang.OutOfMemoryError");" won't provoke a test > error in case the child process was killed by the container, e.g. exited with > exit code 137. We should at least run this patch for several days in our system > to see if it catches all variations of the problem. > Unfortunately we do not see the expected "java.lang.OutOfMemoryError" in the nightly test runs . When I execute the jtreg test locally on the same (!) ppc64le machine , under the same user but not from the test framework we use nightly the "java.lang.OutOfMemoryError" shows up. Best regards, Matthias > Best regards > Christoph > > > -----Original Message----- > > From: Severin Gehwolf > > Sent: Mittwoch, 7. August 2019 18:55 > > To: Baesken, Matthias ; 'hotspot- > > dev at openjdk.java.net' > > Cc: Bob Vandette ; Langer, Christoph > > > > Subject: Re: RFR [XS] : 8229182: > > runtime/containers/docker/TestMemoryAwareness.java test fails on > SLES12 > > > > On Wed, 2019-08-07 at 15:46 +0000, Baesken, Matthias wrote: > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8229182.1/ > > > > Looks good to me. > > > > Thanks, > > Severin From per.liden at oracle.com Thu Aug 8 08:10:04 2019 From: per.liden at oracle.com (Per Liden) Date: Thu, 8 Aug 2019 10:10:04 +0200 Subject: RFR (S): 8228857: Refactor PlatformMonitor into PlatformMutex and PlatformMonitor In-Reply-To: References: <03a9ed9b-b11d-dbdd-d785-76951c3748ab@oracle.com> <6bc5807b-53ed-f103-6477-6162ba5a14a3@oracle.com> <3c83dc0b-e001-71f2-c42a-8c9f7e793764@oracle.com> <07f195ed-cd45-2a7e-30d4-5e63f01edbae@oracle.com> <6D502C87-B9F0-476B-ACC4-E406A7F0DF8E@oracle.com> <1cfbd3a0-cc22-726d-dbcf-636697216292@oracle.com> Message-ID: <59cfcdd0-3c2c-84e6-fb03-842d75876eab@oracle.com> Hi David/Kim, On 8/8/19 1:39 AM, David Holmes wrote: > Hi Per, > > As Kim stated your suggestion doesn't really help as this is about > allocation not inheritance/subtyping. To avoid the bug as much as > possible we need to be able to maintain control over allocation of the > pthread_mutex_t. But if we do that independent of the allocation of the > pthread_cond_t then we are still exposed. Perhaps two freelists ... Thanks. I had the impression a condvar could corrupt the pthread_mutex_t struct if it was allocated in a place where a condvar used to be, which lead me to believe we could have random memory corruption as there could be any kind of data structure there now. But after reading apple_bugreport.txt in JDK-8218975 I see that's not really the nature of this bug. > > My main concern with the freelists is that if we use PlatformMutex for > something dynamic like Zlocks then we may hit allocation pathologies. That's was my concern too, but of course, it remains to be seen if this is actually problem. cheers, Per > > Thanks, > David > > On 7/08/2019 11:50 pm, Per Liden wrote: >> Hi Kim/David, >> >> On 8/7/19 12:10 AM, David Holmes wrote: >> [...] >>>> It is true that only a pthread_cond_t that has been allocated and >>>> later destroyed can cause problems. However, we (the VM) might not be >>>> the only place doing such. Native code, library code, &etc might also >>>> do that. Even the current mechanism doesn't fully protect us from >>>> that. This was something that Patricio and I recognized when we did >>>> the MacOSX workaround; it's not completely bullet proof. >>>> >>>> However, with the current mechanism of allocating pthread_mutex/cond_t >>>> pairs and freelisting them, we highwater pretty quickly. We don't have >>>> many places that actually release them. (I don't remember whether >>>> there's anything other than the task terminator mechanism.) And once >>>> we've highwatered, the VM is safe from any further condvar >>>> destructions by non-VM code. So the only risk is from native code >>>> using pthread_cond_t's before that highwater mark is reached. >>>> >>>> If the VM only freelists its pthread_cond_t's and not its >>>> pthread_mutex_t's, instead allocating and deleting the latter normally >>>> (as Per suggested and I had originally intended to suggest), then the >>>> VM's pthread_mutex_t's are subject to getting scrambled by ongoing >>>> non-VM pthread_cond_t usage. >>> >>> Yes you are right. I was only thinking about VM usage, but if the VM >>> is hosted then mutex/condvar could be being used a lot and not using >>> the freelist for the mutex would greatly increase the risk of >>> reintroducing the bug. >>> >>> As you say the freelist approach itself is not bullet-proof and I'm >>> now worried about what complex hosting applications may encounter! :( >>> I think we may need to try and engage with Apple to get the full >>> details on this bug so that we know what our exposure may be. I hope >>> they fixed it with an interim patch and not only with a full release >>> update! >>> >>> So in terms of this RFE I leave things as they stand, with the >>> mutex/cond freelist being used in PlatformMutex. I hope the slight >>> space wastage is not significant enough to mean that Zlocks will not >>> consider using PlatformMutex. >> >> It would be really interesting to know if this has been fixed by >> Apple, and hopefully also backported to the macos versions we support. >> On systems that has this bug, we could have all kinds of random VM >> memory corruption (caused by e.g. native code/library using condvars), >> which we can't fix. Right? >> >> May I propose a third alternative, which keeps the best of both >> worlds: Don't mix the two types, i.e. don't let PlatforMonitor inherit >> from PlatformMutex. So, we'd just keep exactly what we have and just >> add a PlatformMutex type, which for posix would be just: >> >> class PlatformMutex : public CHeapObj { >> ??protected: >> ?? pthread_mutex_t _mutex; >> >> ??public: >> ?? PlatformMutex(); >> ?? ~PlatformMutex(); >> >> ?? void lock(); >> ?? void unlock(); >> ?? bool try_lock(); >> }; >> >> os::PlatformMutex::PlatformMutex() { >> ?? int status = pthread_mutex_init(&_mutex, _mutexAttr); >> ?? assert_status(status == 0, status, "mutex_init"); >> } >> >> os::PlatformMutex::~PlatformMutex() { >> ?? int status = pthread_mutex_destroy(&_mutex); >> ?? assert_status(status == 0, status, "mutex_destroy"); >> } >> >> inline void os::PlatformMutex::lock() { >> ?? int status = pthread_mutex_lock(&_mutex); >> ?? assert_status(status == 0, status, "mutex_lock"); >> } >> >> inline void os::PlatformMutex::unlock() { >> ?? int status = pthread_mutex_unlock(&_mutex); >> ?? assert_status(status == 0, status, "mutex_unlock"); >> } >> >> inline bool os::PlatformMutex::try_lock() { >> ?? int status = pthread_mutex_trylock(&_mutex); >> ?? assert_status(status == 0 || status == EBUSY, status, >> "mutex_trylock"); >> ?? return status == 0; >> } >> >> cheers, >> Per From stefan.karlsson at oracle.com Thu Aug 8 08:54:33 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 8 Aug 2019 10:54:33 +0200 Subject: RFR: 8229258: Make markOopDesc AllStatic In-Reply-To: <8d1e372a-2b4f-b573-c73f-22065333b2ef@oracle.com> References: <8d1e372a-2b4f-b573-c73f-22065333b2ef@oracle.com> Message-ID: <62440e94-d1eb-4afd-7b6d-62354465dadb@oracle.com> On 2019-08-07 23:33, coleen.phillimore at oracle.com wrote: > > I clicked through the cpu, oops, prims, runtime and sa directories. All > changes as expected.? Went through synchronizer.cpp too fast though, > somebody else should read that more carefully. > > https://cr.openjdk.java.net/~stefank/8229258/webrev.01/src/hotspot/share/oops/oop.inline.hpp.udiff.html > > > -markOop oopDesc::mark() const { > +markWord oopDesc::mark() const { > ?? return HeapAccess::load_at(as_oop(), > mark_offset_in_bytes()); > ?} > > -markOop oopDesc::mark_raw() const { > +markWord oopDesc::mark_raw() const { > ?? return _mark; > ?} > > Nit, can you take out these blanks before 'const' while you're editing > these lines.? They don't line up with anything. Done. > > Removing the commented out SA code makes sense to me.? There are two > test directories for the SA.? One is here: open/test/jdk/sun/tools/jhsdb Thanks. I tested both. > > This looks great!? Thank you! Thanks for reviewing! StefanK > Coleen > > On 8/7/19 3:58 PM, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch to make markOopDesc AllStatic. >> >> https://cr.openjdk.java.net/~stefank/8229258/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8229258 >> >> From the RFE: >> >> I want to change/rename markOop and markOopDesc >> >> Today markOopDescs inherits from oopDesc even though they are not >> oopDescs (Java objects): >> ?`class markOopDesc : public oopDesc {` >> >> This is very confusing to new-comers (and probably to old-timers as >> well). >> >> A simple fix would be to break the inheritance and do the following >> rename: >> markOopDesc -> MarkWord >> markOop -> markWord >> >> However, there are more dubious code in this area. markOopDescs are >> created and used like this: >> >> ``` >> class oopDesc { >> ... >> ? volatile markOop _mark; >> ... >> markOop? oopDesc::mark_raw()? const { return _mark; } >> ... >> // Usage >> obj->mark_raw()->is_marked() >> ... >> // Implementation >> ? bool is_marked()?? const { >> ??? return (mask_bits(value(), lock_mask_in_place) == marked_value); >> ? } >> ... >> // Implementation >> ? bool is_being_inflated() const { return (value() == 0); } >> ... >> // Implementation of markOopDesc::value() >> ? uintptr_t value() const { return (uintptr_t) this; } >> ``` >> >> Remember, _mark is an arbitrary bit pattern describing the object. We >> treat it as if it were a pointer to a markOopDesc object, but it's not >> pointing to such an object. While using that (weird) pointer we call >> value() and extract it's bit pattern to be used for further bit >> pattern checking functions. AFAICT, this is also undefined behavior. >> At least is_being_inflated() const is effectively 'return (uintptr_t) >> this == NULL'. This UB was recently discussed here: >> ?https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-July/038704.html >> >> ?https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-July/038712.html >> >> >> I propose that we change MarkWord (markOopDesc) to be an AllStatic >> class instead and get rid of this (ab)use of the markWord (markOop) >> pointer. >> >> The patch is large but mostly straight forward. However, there is some >> Java code that would need some extra scrutiny: SA and JVMCI. >> >> Tested with tier1-3. >> >> Coleen has asked for file rename from markOop.hpp to markWord.hpp. I'd >> like to do that as a separate RFE when/if this patch gets accepted. >> >> Thanks, >> StefanK >> > From stefan.karlsson at oracle.com Thu Aug 8 08:59:22 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 8 Aug 2019 10:59:22 +0200 Subject: RFR: 8229258: Make markOopDesc AllStatic In-Reply-To: References: Message-ID: <6c0d6051-0fef-7167-5d99-472180eff6b5@oracle.com> On 2019-08-07 23:59, Roman Kennke wrote: > Oh yeah! My IDE completed some operation on markOopDesc to something > that is actually in oopDesc (and would map to something else in > markOopDesc) more than once and left me wondering. E.g. > oopDesc::is_forwarded() which would be markOopDesc::is_marked(). Calling > mark->is_forwarded() seems the obvious thing, but is totally foobared. > > So yeah, this is *very* welcome. I guess the changes are alright and > mostly mechanical, but I'll take a deeper look tomorrow, when I'm not > tired ;-) :) Thanks for taking a look at this. I'll await your review. Cheers, StefanK > > Thanks & cheers, > Roman > >> Hi all, >> >> Please review this patch to make markOopDesc AllStatic. >> >> https://cr.openjdk.java.net/~stefank/8229258/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8229258 >> >> From the RFE: >> >> I want to change/rename markOop and markOopDesc >> >> Today markOopDescs inherits from oopDesc even though they are not >> oopDescs (Java objects): >> ?`class markOopDesc : public oopDesc {` >> >> This is very confusing to new-comers (and probably to old-timers as well). >> >> A simple fix would be to break the inheritance and do the following rename: >> markOopDesc -> MarkWord >> markOop -> markWord >> >> However, there are more dubious code in this area. markOopDescs are >> created and used like this: >> >> ``` >> class oopDesc { >> ... >> ? volatile markOop _mark; >> ... >> markOop? oopDesc::mark_raw()? const { return _mark; } >> ... >> // Usage >> obj->mark_raw()->is_marked() >> ... >> // Implementation >> ? bool is_marked()?? const { >> ??? return (mask_bits(value(), lock_mask_in_place) == marked_value); >> ? } >> ... >> // Implementation >> ? bool is_being_inflated() const { return (value() == 0); } >> ... >> // Implementation of markOopDesc::value() >> ? uintptr_t value() const { return (uintptr_t) this; } >> ``` >> >> Remember, _mark is an arbitrary bit pattern describing the object. We >> treat it as if it were a pointer to a markOopDesc object, but it's not >> pointing to such an object. While using that (weird) pointer we call >> value() and extract it's bit pattern to be used for further bit pattern >> checking functions. AFAICT, this is also undefined behavior. At least >> is_being_inflated() const is effectively 'return (uintptr_t) this == >> NULL'. This UB was recently discussed here: >> ?https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-July/038704.html >> ?https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-July/038712.html >> >> I propose that we change MarkWord (markOopDesc) to be an AllStatic class >> instead and get rid of this (ab)use of the markWord (markOop) pointer. >> >> The patch is large but mostly straight forward. However, there is some >> Java code that would need some extra scrutiny: SA and JVMCI. >> >> Tested with tier1-3. >> >> Coleen has asked for file rename from markOop.hpp to markWord.hpp. I'd >> like to do that as a separate RFE when/if this patch gets accepted. >> >> Thanks, >> StefanK >> > From rkennke at redhat.com Thu Aug 8 10:22:24 2019 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 8 Aug 2019 12:22:24 +0200 Subject: RFR: 8229258: Make markOopDesc AllStatic In-Reply-To: References: Message-ID: <9bc8722a-8009-aa30-23ae-9fa0146aa630@redhat.com> First glance. Instead of making it AllStatic, I'd probably have made it a plain object: class markWord { } and instead of changing e.g.: obj->mark().set_unlocked(); to MarkWord::set_unlocked(obj->mark()); leave it like it is. Looks/feels better to me. Have you tried that? Is this too tricky to do? Or what is the reason to use static accessors there? Roman > Hi all, > > Please review this patch to make markOopDesc AllStatic. > > https://cr.openjdk.java.net/~stefank/8229258/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8229258 > > From the RFE: > > I want to change/rename markOop and markOopDesc > > Today markOopDescs inherits from oopDesc even though they are not > oopDescs (Java objects): > ?`class markOopDesc : public oopDesc {` > > This is very confusing to new-comers (and probably to old-timers as well). > > A simple fix would be to break the inheritance and do the following rename: > markOopDesc -> MarkWord > markOop -> markWord > > However, there are more dubious code in this area. markOopDescs are > created and used like this: > > ``` > class oopDesc { > ... > ? volatile markOop _mark; > ... > markOop? oopDesc::mark_raw()? const { return _mark; } > ... > // Usage > obj->mark_raw()->is_marked() > ... > // Implementation > ? bool is_marked()?? const { > ??? return (mask_bits(value(), lock_mask_in_place) == marked_value); > ? } > ... > // Implementation > ? bool is_being_inflated() const { return (value() == 0); } > ... > // Implementation of markOopDesc::value() > ? uintptr_t value() const { return (uintptr_t) this; } > ``` > > Remember, _mark is an arbitrary bit pattern describing the object. We > treat it as if it were a pointer to a markOopDesc object, but it's not > pointing to such an object. While using that (weird) pointer we call > value() and extract it's bit pattern to be used for further bit pattern > checking functions. AFAICT, this is also undefined behavior. At least > is_being_inflated() const is effectively 'return (uintptr_t) this == > NULL'. This UB was recently discussed here: > ?https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-July/038704.html > ?https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-July/038712.html > > I propose that we change MarkWord (markOopDesc) to be an AllStatic class > instead and get rid of this (ab)use of the markWord (markOop) pointer. > > The patch is large but mostly straight forward. However, there is some > Java code that would need some extra scrutiny: SA and JVMCI. > > Tested with tier1-3. > > Coleen has asked for file rename from markOop.hpp to markWord.hpp. I'd > like to do that as a separate RFE when/if this patch gets accepted. > > Thanks, > StefanK > From robbin.ehn at oracle.com Thu Aug 8 10:53:18 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Thu, 8 Aug 2019 12:53:18 +0200 Subject: Jetty hangs early on Java 12 on OSv with Threadlocal Handshakes ON - shorter version In-Reply-To: References: Message-ID: <01d12413-dfda-d2ad-0e17-6e9f3d0f4f0d@oracle.com> Hi Waldek, > #0 0x0000100000c86370 in sem_trywait at plt () > #1 0x0000100001702bf2 in PosixSemaphore::trywait() () > #2 0x000010000121aab4 in VM_HandshakeAllThreads::doit() () VMThread is trying to figure out which threads have not executed their handshake operation and possible execute it for them (e.g. JavaThread in native). If you attach gdb and step around in VM_HandshakeAllThreads::doit while looping there, you can figure out why we never finish. > When I explicitly enable thread local handshakes on Java 11 it works as > well: In 11 it is only used by ZGC, but in 12 it is used for stack-scanning after nmethods. Sweeper thread: #12 0x0000100001219a48 in Handshake::execute(ThreadClosure*) () #13 0x00001000018b4a0c in NMethodSweeper::possibly_sweep() () > One more datapoint - I am able to run a simple Hello World java app on Java > 12 on OSv with thread-local handshakes on so it looks like this problem > appears on more complicated apps. If you never get to needing to sweep nmethod, you will have never executed a handshake. (but you will execute safepoints using the handshake poll) If you can easily reprod, take a slowdebug and when the process hang, attach gdb switch to VMThread and step around, you will see a count which decrease once for every thread which have executed it's handshake. To figure out if a thread have executed it's handshake, VMThread will take a per thread semaphore (decrease it), which serialize access to the per thread handshake operation, and then look if the operation is completed, return the semaphore (increase it), and look at next thread. /Robbin > > *Lastly, the exact same app works fine on Java 12 on Linux.* > > So given all that could you please point me to what the problem might be? > What has changed in the implementation of thread local handshakes between > Java 11 and 12 that may have caused this issue (I see many changes made to > https://github.com/openjdk/jdk/blob/0fe0312f416add1536a45ecfb292c887ef7e02bd/src/hotspot/share/runtime/handshake.cpp > but > I am not even sure which commit matches the version of Java 12 or Java 11 I > am using)? I am thinking this has to do with some subtle differences > between relevant ABI implementation between OSv and Linux. Signals related? > > Thanks for your help in advance, > > Waldek > > Thread dump of all Java threads (in other email that was to big) > From stefan.karlsson at oracle.com Thu Aug 8 11:01:16 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 8 Aug 2019 13:01:16 +0200 Subject: RFR: 8229258: Make markOopDesc AllStatic In-Reply-To: <9bc8722a-8009-aa30-23ae-9fa0146aa630@redhat.com> References: <9bc8722a-8009-aa30-23ae-9fa0146aa630@redhat.com> Message-ID: <736a16a8-bc21-9338-59ce-9f3f7e093b7a@oracle.com> On 2019-08-08 12:22, Roman Kennke wrote: > First glance. > > Instead of making it AllStatic, I'd probably have made it a plain object: > > class markWord { > } > > and instead of changing e.g.: > > obj->mark().set_unlocked(); > > to > > MarkWord::set_unlocked(obj->mark()); > > leave it like it is. Looks/feels better to me. > > Have you tried that? Is this too tricky to do? Or what is the reason to > use static accessors there? Not sure if you mean that we should still play tricks with the this pointer. If that's the case then, that would retain the undefined behavior that this patch removes (by using the static accessors). One example given below is: bool is_being_inflated() const { return (value() == 0); } which ends up comparing this to NULL. But maybe you suggests adding the mark word bits as a value in MarkWord? Something like this: class MarkWord { uintptr_t _value; // and keep the functions as non-static functions bool is_being_inflated() const { return (_value == 0); } } then, yes, I tried that because I also felt that it was unfortunate that I had to retransform the code in this way. However, I backed off because of different hurdles that I couldn't trivially solve. For example: class oopDesc { volatile markWord _mark; } ... _mark = prototype(); <-- complains here that the assignment operator discards volatile qualifier I'm unsure what performance effects it will have if I provide a hand-written assignment operator, since the class will not be a trivial class anymore. Because of that, I backed away from such a change. I'm not at all opposed to wait with this patch if someone wants to take the time to retry that experiment. Thanks, StefanK > > Roman > >> Hi all, >> >> Please review this patch to make markOopDesc AllStatic. >> >> https://cr.openjdk.java.net/~stefank/8229258/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8229258 >> >> From the RFE: >> >> I want to change/rename markOop and markOopDesc >> >> Today markOopDescs inherits from oopDesc even though they are not >> oopDescs (Java objects): >> ?`class markOopDesc : public oopDesc {` >> >> This is very confusing to new-comers (and probably to old-timers as well). >> >> A simple fix would be to break the inheritance and do the following rename: >> markOopDesc -> MarkWord >> markOop -> markWord >> >> However, there are more dubious code in this area. markOopDescs are >> created and used like this: >> >> ``` >> class oopDesc { >> ... >> ? volatile markOop _mark; >> ... >> markOop? oopDesc::mark_raw()? const { return _mark; } >> ... >> // Usage >> obj->mark_raw()->is_marked() >> ... >> // Implementation >> ? bool is_marked()?? const { >> ??? return (mask_bits(value(), lock_mask_in_place) == marked_value); >> ? } >> ... >> // Implementation >> ? bool is_being_inflated() const { return (value() == 0); } >> ... >> // Implementation of markOopDesc::value() >> ? uintptr_t value() const { return (uintptr_t) this; } >> ``` >> >> Remember, _mark is an arbitrary bit pattern describing the object. We >> treat it as if it were a pointer to a markOopDesc object, but it's not >> pointing to such an object. While using that (weird) pointer we call >> value() and extract it's bit pattern to be used for further bit pattern >> checking functions. AFAICT, this is also undefined behavior. At least >> is_being_inflated() const is effectively 'return (uintptr_t) this == >> NULL'. This UB was recently discussed here: >> ?https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-July/038704.html >> ?https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-July/038712.html >> >> I propose that we change MarkWord (markOopDesc) to be an AllStatic class >> instead and get rid of this (ab)use of the markWord (markOop) pointer. >> >> The patch is large but mostly straight forward. However, there is some >> Java code that would need some extra scrutiny: SA and JVMCI. >> >> Tested with tier1-3. >> >> Coleen has asked for file rename from markOop.hpp to markWord.hpp. I'd >> like to do that as a separate RFE when/if this patch gets accepted. >> >> Thanks, >> StefanK >> > From coleen.phillimore at oracle.com Thu Aug 8 12:18:35 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 8 Aug 2019 08:18:35 -0400 Subject: RFR: 8229258: Make markOopDesc AllStatic In-Reply-To: <736a16a8-bc21-9338-59ce-9f3f7e093b7a@oracle.com> References: <9bc8722a-8009-aa30-23ae-9fa0146aa630@redhat.com> <736a16a8-bc21-9338-59ce-9f3f7e093b7a@oracle.com> Message-ID: Is this patch based off another in your queue?? It looks like MarkWord has already been introduced. https://cr.openjdk.java.net/~stefank/8229258/webrev.01/src/hotspot/cpu/aarch64/aarch64.ad.udiff.html - // Set tmp to be (markOop of object | UNLOCK_VALUE). + // Set tmp to be (markWord of object | UNLOCK_VALUE). __ orr(tmp, disp_hdr, MarkWord::unlocked_value); I was trying to see how many lines were changed to static function calls on MarkWord, vs obj->mark()->something(). My thought was it was not enough to try to make MarkWord contain markWord to enable this simpler syntax.? There are 543 MarkWord:: in your patch but some are constant references, which would still be there if you made MarkWord contain markWord. I do have one request to think about.? Could MarkWord be a longer name like MarkWord{Impl}?? Don't like "Impl" though.? I don't want to bikeshed but it took me a while to spot that the 'm's were different in markWord and MarkWord.? Maybe that's the point but there's going to be a lot of mistyping. Coleen On 8/8/19 7:01 AM, Stefan Karlsson wrote: > > > On 2019-08-08 12:22, Roman Kennke wrote: >> First glance. >> >> Instead of making it AllStatic, I'd probably have made it a plain >> object: >> >> class markWord { >> } >> >> and instead of changing e.g.: >> >> obj->mark().set_unlocked(); >> >> ? to >> >> MarkWord::set_unlocked(obj->mark()); >> >> leave it like it is. Looks/feels better to me. >> >> Have you tried that? Is this too tricky to do? Or what is the reason to >> use static accessors there? > > Not sure if you mean that we should still play tricks with the this > pointer. If that's the case then, that would retain the undefined > behavior that this patch removes (by using the static accessors). One > example given below is: > > bool is_being_inflated() const { return (value() == 0); } > > which ends up comparing this to NULL. > > But maybe you suggests adding the mark word bits as a value in > MarkWord? Something like this: > > class MarkWord { > ? uintptr_t _value; > > ? // and keep the functions as non-static functions > ? bool is_being_inflated() const { return (_value == 0); } > } > > then, yes, I tried that because I also felt that it was unfortunate > that I had to retransform the code in this way. However, I backed off > because of different hurdles that I couldn't trivially solve. For > example: > > class oopDesc { > ? volatile markWord _mark; > } > ... > _mark = prototype(); <-- complains here that the assignment operator > discards volatile qualifier > > I'm unsure what performance effects it will have if I provide a > hand-written assignment operator, since the class will not be a > trivial class anymore. Because of that, I backed away from such a change. > > I'm not at all opposed to wait with this patch if someone wants to > take the time to retry that experiment. > > Thanks, > StefanK > >> >> Roman >> >>> Hi all, >>> >>> Please review this patch to make markOopDesc AllStatic. >>> >>> https://cr.openjdk.java.net/~stefank/8229258/webrev.01/ >>> https://bugs.openjdk.java.net/browse/JDK-8229258 >>> >>> ?From the RFE: >>> >>> I want to change/rename markOop and markOopDesc >>> >>> Today markOopDescs inherits from oopDesc even though they are not >>> oopDescs (Java objects): >>> ??`class markOopDesc : public oopDesc {` >>> >>> This is very confusing to new-comers (and probably to old-timers as >>> well). >>> >>> A simple fix would be to break the inheritance and do the following >>> rename: >>> markOopDesc -> MarkWord >>> markOop -> markWord >>> >>> However, there are more dubious code in this area. markOopDescs are >>> created and used like this: >>> >>> ``` >>> class oopDesc { >>> ... >>> ?? volatile markOop _mark; >>> ... >>> markOop? oopDesc::mark_raw()? const { return _mark; } >>> ... >>> // Usage >>> obj->mark_raw()->is_marked() >>> ... >>> // Implementation >>> ?? bool is_marked()?? const { >>> ???? return (mask_bits(value(), lock_mask_in_place) == marked_value); >>> ?? } >>> ... >>> // Implementation >>> ?? bool is_being_inflated() const { return (value() == 0); } >>> ... >>> // Implementation of markOopDesc::value() >>> ?? uintptr_t value() const { return (uintptr_t) this; } >>> ``` >>> >>> Remember, _mark is an arbitrary bit pattern describing the object. We >>> treat it as if it were a pointer to a markOopDesc object, but it's not >>> pointing to such an object. While using that (weird) pointer we call >>> value() and extract it's bit pattern to be used for further bit pattern >>> checking functions. AFAICT, this is also undefined behavior. At least >>> is_being_inflated() const is effectively 'return (uintptr_t) this == >>> NULL'. This UB was recently discussed here: >>> ??https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-July/038704.html >>> >>> ??https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-July/038712.html >>> >>> >>> I propose that we change MarkWord (markOopDesc) to be an AllStatic >>> class >>> instead and get rid of this (ab)use of the markWord (markOop) pointer. >>> >>> The patch is large but mostly straight forward. However, there is some >>> Java code that would need some extra scrutiny: SA and JVMCI. >>> >>> Tested with tier1-3. >>> >>> Coleen has asked for file rename from markOop.hpp to markWord.hpp. I'd >>> like to do that as a separate RFE when/if this patch gets accepted. >>> >>> Thanks, >>> StefanK >>> >> From stefan.karlsson at oracle.com Thu Aug 8 12:35:19 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 8 Aug 2019 14:35:19 +0200 Subject: RFR: 8229258: Make markOopDesc AllStatic In-Reply-To: References: <9bc8722a-8009-aa30-23ae-9fa0146aa630@redhat.com> <736a16a8-bc21-9338-59ce-9f3f7e093b7a@oracle.com> Message-ID: <356a1abe-c2fc-1a5e-d6ff-c31edd7aa916@oracle.com> On 2019-08-08 14:18, coleen.phillimore at oracle.com wrote: > Is this patch based off another in your queue?? It looks like MarkWord > has already been introduced. > > https://cr.openjdk.java.net/~stefank/8229258/webrev.01/src/hotspot/cpu/aarch64/aarch64.ad.udiff.html > > > - // Set tmp to be (markOop of object | UNLOCK_VALUE). > + // Set tmp to be (markWord of object | UNLOCK_VALUE). > ???? __ orr(tmp, disp_hdr, MarkWord::unlocked_value); > > > I was trying to see how many lines were changed to static function calls > on MarkWord, vs obj->mark()->something(). > > My thought was it was not enough to try to make MarkWord contain > markWord to enable this simpler syntax.? There are 543 MarkWord:: in > your patch but some are constant references, which would still be there > if you made MarkWord contain markWord. Hmm. You are right. I generated an incorrect webrev. I reran webrev with -r qparent and now have this: http://cr.openjdk.java.net/~stefank/8229258/webrev.02/ > > I do have one request to think about.? Could MarkWord be a longer name > like MarkWord{Impl}?? Don't like "Impl" though.? I don't want to > bikeshed but it took me a while to spot that the 'm's were different in > markWord and MarkWord.? Maybe that's the point but there's going to be a > lot of mistyping. I got the same feedback from Kim but I'm personally not keen on making the name any longer. Specially now when MarkWord:: is being appended to all mark word operations. If enough reviewers push back on this, then I guess I have to change this. Thanks, StefanK > > Coleen > > On 8/8/19 7:01 AM, Stefan Karlsson wrote: >> >> >> On 2019-08-08 12:22, Roman Kennke wrote: >>> First glance. >>> >>> Instead of making it AllStatic, I'd probably have made it a plain >>> object: >>> >>> class markWord { >>> } >>> >>> and instead of changing e.g.: >>> >>> obj->mark().set_unlocked(); >>> >>> ? to >>> >>> MarkWord::set_unlocked(obj->mark()); >>> >>> leave it like it is. Looks/feels better to me. >>> >>> Have you tried that? Is this too tricky to do? Or what is the reason to >>> use static accessors there? >> >> Not sure if you mean that we should still play tricks with the this >> pointer. If that's the case then, that would retain the undefined >> behavior that this patch removes (by using the static accessors). One >> example given below is: >> >> bool is_being_inflated() const { return (value() == 0); } >> >> which ends up comparing this to NULL. >> >> But maybe you suggests adding the mark word bits as a value in >> MarkWord? Something like this: >> >> class MarkWord { >> ? uintptr_t _value; >> >> ? // and keep the functions as non-static functions >> ? bool is_being_inflated() const { return (_value == 0); } >> } >> >> then, yes, I tried that because I also felt that it was unfortunate >> that I had to retransform the code in this way. However, I backed off >> because of different hurdles that I couldn't trivially solve. For >> example: >> >> class oopDesc { >> ? volatile markWord _mark; >> } >> ... >> _mark = prototype(); <-- complains here that the assignment operator >> discards volatile qualifier >> >> I'm unsure what performance effects it will have if I provide a >> hand-written assignment operator, since the class will not be a >> trivial class anymore. Because of that, I backed away from such a change. >> >> I'm not at all opposed to wait with this patch if someone wants to >> take the time to retry that experiment. >> >> Thanks, >> StefanK >> >>> >>> Roman >>> >>>> Hi all, >>>> >>>> Please review this patch to make markOopDesc AllStatic. >>>> >>>> https://cr.openjdk.java.net/~stefank/8229258/webrev.01/ >>>> https://bugs.openjdk.java.net/browse/JDK-8229258 >>>> >>>> ?From the RFE: >>>> >>>> I want to change/rename markOop and markOopDesc >>>> >>>> Today markOopDescs inherits from oopDesc even though they are not >>>> oopDescs (Java objects): >>>> ??`class markOopDesc : public oopDesc {` >>>> >>>> This is very confusing to new-comers (and probably to old-timers as >>>> well). >>>> >>>> A simple fix would be to break the inheritance and do the following >>>> rename: >>>> markOopDesc -> MarkWord >>>> markOop -> markWord >>>> >>>> However, there are more dubious code in this area. markOopDescs are >>>> created and used like this: >>>> >>>> ``` >>>> class oopDesc { >>>> ... >>>> ?? volatile markOop _mark; >>>> ... >>>> markOop? oopDesc::mark_raw()? const { return _mark; } >>>> ... >>>> // Usage >>>> obj->mark_raw()->is_marked() >>>> ... >>>> // Implementation >>>> ?? bool is_marked()?? const { >>>> ???? return (mask_bits(value(), lock_mask_in_place) == marked_value); >>>> ?? } >>>> ... >>>> // Implementation >>>> ?? bool is_being_inflated() const { return (value() == 0); } >>>> ... >>>> // Implementation of markOopDesc::value() >>>> ?? uintptr_t value() const { return (uintptr_t) this; } >>>> ``` >>>> >>>> Remember, _mark is an arbitrary bit pattern describing the object. We >>>> treat it as if it were a pointer to a markOopDesc object, but it's not >>>> pointing to such an object. While using that (weird) pointer we call >>>> value() and extract it's bit pattern to be used for further bit pattern >>>> checking functions. AFAICT, this is also undefined behavior. At least >>>> is_being_inflated() const is effectively 'return (uintptr_t) this == >>>> NULL'. This UB was recently discussed here: >>>> ??https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-July/038704.html >>>> >>>> ??https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-July/038712.html >>>> >>>> >>>> I propose that we change MarkWord (markOopDesc) to be an AllStatic >>>> class >>>> instead and get rid of this (ab)use of the markWord (markOop) pointer. >>>> >>>> The patch is large but mostly straight forward. However, there is some >>>> Java code that would need some extra scrutiny: SA and JVMCI. >>>> >>>> Tested with tier1-3. >>>> >>>> Coleen has asked for file rename from markOop.hpp to markWord.hpp. I'd >>>> like to do that as a separate RFE when/if this patch gets accepted. >>>> >>>> Thanks, >>>> StefanK >>>> >>> > From rkennke at redhat.com Thu Aug 8 12:45:30 2019 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 8 Aug 2019 14:45:30 +0200 Subject: RFR: 8229258: Make markOopDesc AllStatic In-Reply-To: <736a16a8-bc21-9338-59ce-9f3f7e093b7a@oracle.com> References: <9bc8722a-8009-aa30-23ae-9fa0146aa630@redhat.com> <736a16a8-bc21-9338-59ce-9f3f7e093b7a@oracle.com> Message-ID: <84eefcbd-a687-6389-a236-36fb09cf44e8@redhat.com> > On 2019-08-08 12:22, Roman Kennke wrote: >> First glance. >> >> Instead of making it AllStatic, I'd probably have made it a plain object: >> >> class markWord { >> } >> >> and instead of changing e.g.: >> >> obj->mark().set_unlocked(); >> >> ? to >> >> MarkWord::set_unlocked(obj->mark()); >> >> leave it like it is. Looks/feels better to me. >> >> Have you tried that? Is this too tricky to do? Or what is the reason to >> use static accessors there? > > Not sure if you mean that we should still play tricks with the this > pointer. If that's the case then, that would retain the undefined > behavior that this patch removes (by using the static accessors). One > example given below is: > > bool is_being_inflated() const { return (value() == 0); } > > which ends up comparing this to NULL. Eww, no, this doesn't seem right. > But maybe you suggests adding the mark word bits as a value in MarkWord? > Something like this: > > class MarkWord { > ? uintptr_t _value; > > ? // and keep the functions as non-static functions > ? bool is_being_inflated() const { return (_value == 0); } > }??? > > then, yes, I tried that because I also felt that it was unfortunate that > I had to retransform the code in this way. However, I backed off because > of different hurdles that I couldn't trivially solve. For example: > > class oopDesc { > ? volatile markWord _mark; > } > ... > _mark = prototype(); <-- complains here that the assignment operator > discards volatile qualifier > > I'm unsure what performance effects it will have if I provide a > hand-written assignment operator, since the class will not be a trivial > class anymore. Because of that, I backed away from such a change. > > I'm not at all opposed to wait with this patch if someone wants to take > the time to retry that experiment. Yeah, that was what I had in mind, but if it's too complicated then it's ok to do AllStatic access. Give me some time to review the rest of the patch. Thanks Roman From kim.barrett at oracle.com Thu Aug 8 17:20:31 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 8 Aug 2019 13:20:31 -0400 Subject: RFR: 8229258: Make markOopDesc AllStatic In-Reply-To: <736a16a8-bc21-9338-59ce-9f3f7e093b7a@oracle.com> References: <9bc8722a-8009-aa30-23ae-9fa0146aa630@redhat.com> <736a16a8-bc21-9338-59ce-9f3f7e093b7a@oracle.com> Message-ID: <8AFD0151-38B2-41C8-8BC9-4705BD9F7C75@oracle.com> > On Aug 8, 2019, at 7:01 AM, Stefan Karlsson wrote: > class oopDesc { > volatile markWord _mark; > } > ... > _mark = prototype(); <-- complains here that the assignment operator discards volatile qualifier > > I'm unsure what performance effects it will have if I provide a hand-written assignment operator, since the class will not be a trivial class anymore. Because of that, I backed away from such a change. [Not a review, just a comment about the above.] There are some other places where that problem arises in our code base. They?ve been dealt with by casting away the volatile, e.g. here would be // discard volatile post-assignment read. (void)const_cast(_mark = prototype()); To find some other examples (with some false positives): egrep ?const_cast<[^>]+&>? taskqueue has several, with others scattered here and there. There are enough of them (more than I expected, over a dozen), and they are long and ugly and obscure enough, that maybe there should be a helper function for this. I think something like (completely untested) template ALWAYSINLINE void discard_volatile(T volatile& x) { static_cast(const_cast(x)); } From calvin.cheung at oracle.com Thu Aug 8 17:53:48 2019 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Thu, 8 Aug 2019 10:53:48 -0700 Subject: CFV: New HotSpot Group Member: Jiangli Zhou In-Reply-To: <30c09194-6557-5ff6-caa0-37f976e75618@oracle.com> References: <30c09194-6557-5ff6-caa0-37f976e75618@oracle.com> Message-ID: <17030f37-fe94-f076-5a8e-7a3e1e8109c9@oracle.com> Vote: yes On 7/30/19 2:48 PM, Calvin Cheung wrote: > Greetings, > > I hereby nominate Jiangli Zhou (OpenJDK user name: jiangli) to > Membership in the HotSpot Group. > > Jiangli is a JDK project and JDK update project reviewer. She is > currently a member of Google Java Platform team and has contributed > over 100 changesets[3] to Hotspot JVM in various areas since 2011. In > recent years, she has been mainly focusing on the runtime memory > footprint reduction and Class Data Sharing. > > Votes are due by August 13, 2019, 15:00 PDT. > > Only current Members of the HotSpot Group [1] are eligible to vote on > this nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [2]. > > Thanks! > > Calvin > > [1] http://openjdk.java.net/census#hotspot > > [2] http://openjdk.java.net/groups/#member-vote > > [3] > http://hg.openjdk.java.net/jdk/jdk/log?revcount=300&rev=(author(jiangli))+and+not+merge() > From daniel.daugherty at oracle.com Thu Aug 8 20:16:50 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 8 Aug 2019 16:16:50 -0400 Subject: RFR: 8229258: Make markOopDesc AllStatic In-Reply-To: <356a1abe-c2fc-1a5e-d6ff-c31edd7aa916@oracle.com> References: <9bc8722a-8009-aa30-23ae-9fa0146aa630@redhat.com> <736a16a8-bc21-9338-59ce-9f3f7e093b7a@oracle.com> <356a1abe-c2fc-1a5e-d6ff-c31edd7aa916@oracle.com> Message-ID: <8ddc7474-7d69-b0be-0400-4c2edd2a2b98@oracle.com> > http://cr.openjdk.java.net/~stefank/8229258/webrev.02/ I reviewed the following files via the Udiffs links: ? src/hotspot/share/oops/markOop.cpp ? src/hotspot/share/oops/markOop.hpp ? src/hotspot/share/oops/markOop.inline.hpp ? src/hotspot/share/runtime/basicLock.cpp ? src/hotspot/share/runtime/basicLock.hpp ? src/hotspot/share/runtime/biasedLocking.cpp ? src/hotspot/share/runtime/biasedLocking.hpp ? src/hotspot/share/runtime/objectMonitor.cpp ? src/hotspot/share/runtime/objectMonitor.hpp ? src/hotspot/share/runtime/objectMonitor.inline.hpp ? src/hotspot/share/runtime/synchronizer.cpp ? src/hotspot/share/runtime/thread.cpp ? src/hotspot/share/runtime/vframe.cpp and the changes look fine. This is a massive amount of work, but it is a necessary cleanup. Thanks for tackling it! Thumbs up (on the above files)! Dan On 8/8/19 8:35 AM, Stefan Karlsson wrote: > On 2019-08-08 14:18, coleen.phillimore at oracle.com wrote: >> Is this patch based off another in your queue?? It looks like >> MarkWord has already been introduced. >> >> https://cr.openjdk.java.net/~stefank/8229258/webrev.01/src/hotspot/cpu/aarch64/aarch64.ad.udiff.html >> >> >> - // Set tmp to be (markOop of object | UNLOCK_VALUE). >> + // Set tmp to be (markWord of object | UNLOCK_VALUE). >> ????? __ orr(tmp, disp_hdr, MarkWord::unlocked_value); >> >> >> I was trying to see how many lines were changed to static function >> calls on MarkWord, vs obj->mark()->something(). >> >> My thought was it was not enough to try to make MarkWord contain >> markWord to enable this simpler syntax.? There are 543 MarkWord:: in >> your patch but some are constant references, which would still be >> there if you made MarkWord contain markWord. > > Hmm. You are right. I generated an incorrect webrev. I reran webrev > with -r qparent and now have this: > http://cr.openjdk.java.net/~stefank/8229258/webrev.02/ > >> >> I do have one request to think about.? Could MarkWord be a longer >> name like MarkWord{Impl}?? Don't like "Impl" though.? I don't want to >> bikeshed but it took me a while to spot that the 'm's were different >> in markWord and MarkWord.? Maybe that's the point but there's going >> to be a lot of mistyping. > > I got the same feedback from Kim but I'm personally not keen on making > the name any longer. Specially now when MarkWord:: is being appended > to all mark word operations. > > If enough reviewers push back on this, then I guess I have to change > this. > > Thanks, > StefanK > > >> >> Coleen >> >> On 8/8/19 7:01 AM, Stefan Karlsson wrote: >>> >>> >>> On 2019-08-08 12:22, Roman Kennke wrote: >>>> First glance. >>>> >>>> Instead of making it AllStatic, I'd probably have made it a plain >>>> object: >>>> >>>> class markWord { >>>> } >>>> >>>> and instead of changing e.g.: >>>> >>>> obj->mark().set_unlocked(); >>>> >>>> ? to >>>> >>>> MarkWord::set_unlocked(obj->mark()); >>>> >>>> leave it like it is. Looks/feels better to me. >>>> >>>> Have you tried that? Is this too tricky to do? Or what is the >>>> reason to >>>> use static accessors there? >>> >>> Not sure if you mean that we should still play tricks with the this >>> pointer. If that's the case then, that would retain the undefined >>> behavior that this patch removes (by using the static accessors). >>> One example given below is: >>> >>> bool is_being_inflated() const { return (value() == 0); } >>> >>> which ends up comparing this to NULL. >>> >>> But maybe you suggests adding the mark word bits as a value in >>> MarkWord? Something like this: >>> >>> class MarkWord { >>> ? uintptr_t _value; >>> >>> ? // and keep the functions as non-static functions >>> ? bool is_being_inflated() const { return (_value == 0); } >>> } >>> >>> then, yes, I tried that because I also felt that it was unfortunate >>> that I had to retransform the code in this way. However, I backed >>> off because of different hurdles that I couldn't trivially solve. >>> For example: >>> >>> class oopDesc { >>> ? volatile markWord _mark; >>> } >>> ... >>> _mark = prototype(); <-- complains here that the assignment operator >>> discards volatile qualifier >>> >>> I'm unsure what performance effects it will have if I provide a >>> hand-written assignment operator, since the class will not be a >>> trivial class anymore. Because of that, I backed away from such a >>> change. >>> >>> I'm not at all opposed to wait with this patch if someone wants to >>> take the time to retry that experiment. >>> >>> Thanks, >>> StefanK >>> >>>> >>>> Roman >>>> >>>>> Hi all, >>>>> >>>>> Please review this patch to make markOopDesc AllStatic. >>>>> >>>>> https://cr.openjdk.java.net/~stefank/8229258/webrev.01/ >>>>> https://bugs.openjdk.java.net/browse/JDK-8229258 >>>>> >>>>> ?From the RFE: >>>>> >>>>> I want to change/rename markOop and markOopDesc >>>>> >>>>> Today markOopDescs inherits from oopDesc even though they are not >>>>> oopDescs (Java objects): >>>>> ??`class markOopDesc : public oopDesc {` >>>>> >>>>> This is very confusing to new-comers (and probably to old-timers >>>>> as well). >>>>> >>>>> A simple fix would be to break the inheritance and do the >>>>> following rename: >>>>> markOopDesc -> MarkWord >>>>> markOop -> markWord >>>>> >>>>> However, there are more dubious code in this area. markOopDescs are >>>>> created and used like this: >>>>> >>>>> ``` >>>>> class oopDesc { >>>>> ... >>>>> ?? volatile markOop _mark; >>>>> ... >>>>> markOop? oopDesc::mark_raw()? const { return _mark; } >>>>> ... >>>>> // Usage >>>>> obj->mark_raw()->is_marked() >>>>> ... >>>>> // Implementation >>>>> ?? bool is_marked()?? const { >>>>> ???? return (mask_bits(value(), lock_mask_in_place) == marked_value); >>>>> ?? } >>>>> ... >>>>> // Implementation >>>>> ?? bool is_being_inflated() const { return (value() == 0); } >>>>> ... >>>>> // Implementation of markOopDesc::value() >>>>> ?? uintptr_t value() const { return (uintptr_t) this; } >>>>> ``` >>>>> >>>>> Remember, _mark is an arbitrary bit pattern describing the object. We >>>>> treat it as if it were a pointer to a markOopDesc object, but it's >>>>> not >>>>> pointing to such an object. While using that (weird) pointer we call >>>>> value() and extract it's bit pattern to be used for further bit >>>>> pattern >>>>> checking functions. AFAICT, this is also undefined behavior. At least >>>>> is_being_inflated() const is effectively 'return (uintptr_t) this == >>>>> NULL'. This UB was recently discussed here: >>>>> ??https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-July/038704.html >>>>> >>>>> ??https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-July/038712.html >>>>> >>>>> >>>>> I propose that we change MarkWord (markOopDesc) to be an AllStatic >>>>> class >>>>> instead and get rid of this (ab)use of the markWord (markOop) >>>>> pointer. >>>>> >>>>> The patch is large but mostly straight forward. However, there is >>>>> some >>>>> Java code that would need some extra scrutiny: SA and JVMCI. >>>>> >>>>> Tested with tier1-3. >>>>> >>>>> Coleen has asked for file rename from markOop.hpp to markWord.hpp. >>>>> I'd >>>>> like to do that as a separate RFE when/if this patch gets accepted. >>>>> >>>>> Thanks, >>>>> StefanK >>>>> >>>> >> From rkennke at redhat.com Thu Aug 8 22:57:52 2019 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 9 Aug 2019 00:57:52 +0200 Subject: RFR: 8229258: Make markOopDesc AllStatic In-Reply-To: References: Message-ID: <72567e47-3b52-8e30-ea6f-9a64fa043c07@redhat.com> Hi Stefan, Awesome work! I have a few comments: - You're going to need this patch on top of yours to keep Shenandoah in shape: :-) http://cr.openjdk.java.net/~rkennke/8229258-shenandoah/webrev.00/ - Would be good to get as many affected platforms tested as possible. There are changes like the ones in Shenandoah above that are not easy to catch by grepping. Maybe reach out to folks who are known to regularily build fancy platforms like SAP, Bellsoft,.. ? - There are a few places where alignment of comments get messed up, e.g.: src/hotspot/cpu/ppc/macroAssembler_ppc.cpp: ld(mark_word, oopDesc::mark_offset_in_bytes(), obj); // Reload in transaction, conflicts need to be tracked. - andi(R0, mark_word, markOopDesc::biased_lock_mask_in_place); // look at 3 lock bits - cmpwi(flag, R0, markOopDesc::unlocked_value); // bits = 001 unlocked + andi(R0, mark_word, MarkWord::biased_lock_mask_in_place); // look at 3 lock bits + cmpwi(flag, R0, MarkWord::unlocked_value); // bits = 001 unlocked beq(flag, DONE_LABEL); // all done if unlocked I haven't collected all those places (if any more), but would be good if you could sweep over the patch and fix those. - I agree with Coleen that markWord vs. MarkWord is a bit confusing. Not sure what to do though. - I know it would probably disturb even more code, but shouldn't the files markOop.* be renamed to markWord.* ? - The changes concerning SA, Graal and JRF *look* ok to me, but I don't feel qualified to ack them. Thanks, Roman > Hi all, > > Please review this patch to make markOopDesc AllStatic. > > https://cr.openjdk.java.net/~stefank/8229258/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8229258 > > From the RFE: > > I want to change/rename markOop and markOopDesc > > Today markOopDescs inherits from oopDesc even though they are not > oopDescs (Java objects): > ?`class markOopDesc : public oopDesc {` > > This is very confusing to new-comers (and probably to old-timers as well). > > A simple fix would be to break the inheritance and do the following rename: > markOopDesc -> MarkWord > markOop -> markWord > > However, there are more dubious code in this area. markOopDescs are > created and used like this: > > ``` > class oopDesc { > ... > ? volatile markOop _mark; > ... > markOop? oopDesc::mark_raw()? const { return _mark; } > ... > // Usage > obj->mark_raw()->is_marked() > ... > // Implementation > ? bool is_marked()?? const { > ??? return (mask_bits(value(), lock_mask_in_place) == marked_value); > ? } > ... > // Implementation > ? bool is_being_inflated() const { return (value() == 0); } > ... > // Implementation of markOopDesc::value() > ? uintptr_t value() const { return (uintptr_t) this; } > ``` > > Remember, _mark is an arbitrary bit pattern describing the object. We > treat it as if it were a pointer to a markOopDesc object, but it's not > pointing to such an object. While using that (weird) pointer we call > value() and extract it's bit pattern to be used for further bit pattern > checking functions. AFAICT, this is also undefined behavior. At least > is_being_inflated() const is effectively 'return (uintptr_t) this == > NULL'. This UB was recently discussed here: > ?https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-July/038704.html > ?https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-July/038712.html > > I propose that we change MarkWord (markOopDesc) to be an AllStatic class > instead and get rid of this (ab)use of the markWord (markOop) pointer. > > The patch is large but mostly straight forward. However, there is some > Java code that would need some extra scrutiny: SA and JVMCI. > > Tested with tier1-3. > > Coleen has asked for file rename from markOop.hpp to markWord.hpp. I'd > like to do that as a separate RFE when/if this patch gets accepted. > > Thanks, > StefanK > From kim.barrett at oracle.com Thu Aug 8 23:17:46 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 8 Aug 2019 19:17:46 -0400 Subject: RFR (S): 8228857: Refactor PlatformMonitor into PlatformMutex and PlatformMonitor In-Reply-To: <85649d80-f85e-4da0-dd4c-db148b33d5e8@oracle.com> References: <32C9F58D-FA84-4A18-9A43-86DE2F8AD88E@oracle.com> <85649d80-f85e-4da0-dd4c-db148b33d5e8@oracle.com> Message-ID: > On Aug 7, 2019, at 10:51 PM, David Holmes wrote: > > Hi Kim, > > On 8/08/2019 11:59 am, Kim Barrett wrote: >> PlatformMutex should be noncopyable on all platforms. > > I presume that is something PlatformMonitor should already be doing but is not? What is involved in making something non-copyable? (Sorry my basic C++ is pretty basic.) Yes, PlatformMonitor ought to already be doing that. We don't have any explicit support for declaring a class noncopyable. One idiom that's being used is to declare the copy constructor and copy assignment operator private and don't provide a definition for either. Then one gets a compile time error if anything outside the class attempts to copy, and a link time error if the copy is from inside the class (or by a friend). So in the private part of the class PlatformMutex(const PlatformMutex&); PlatformMutex& operator=(const PlatformMutex&); Maybe we should have a helper macro for that, but nobody has proposed adding one. For C++11 it's PlatformMutex(const PlatformMutex&) = delete; PlatformMutex& operator=(const PlatformMutex&) = delete; anywhere in the class (public is best, to get a reference to deleted function error message rather than possibly an access error message). This is a "good hygiene" thing; many of our classes "ought" to have this but don't bother. >> The inheritance runs the risk of destructor slicing, because the >> PlatformMutex base class has a public non-virtual destructor. I don't >> think we want to introduce a virtual destructor here. I don't know of >> a solution that doesn't lose the inheritance relationship between the >> classes. I don't know if that relationship is considered important. > > Semantically a Monitor (as we define it) is a Mutex with a condition variable, so the inheritance seems quite appropriate, even if not essential. > > IIUC the issue is when we have a PlatformMutex* that happens to point to a PlatformMonitor - if we delete it then we only call the PlatformMutex destructor. Why would we not just declare the destructor as virtual? What will it cost us? It seems the natural/right way to deal with inheritance in C++. It imposes virtual function overheads (class vtable, per-object vtable entries, &etc) on what is intended to be simple, low-overhead classes. Do we care? One option is to ignore the problem; there's certainly precedent for that in Hotspot! As a result, we can't enable some associated gcc warnings (and have to actually turn some off), though as I've mentioned elsewhere some of those warnings have other problems: https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2019-July/026480.html Fixing without taking on virtual function costs involves losing the base/derived relationship between these classes. I don't know if we care about that relationship. To do this one would introduce a new helper base class, with each deriving separately from it. class PlatformMutexBase ... ... same definition as proposed PlatformMutex, except with protected constructor and destructor ... }; class PlatformMutex : public PlatformMutexBase {}; class PlatformMonitor : public PlatformMutexBase { ... same definition as proposed PlatformMonitor, adjusting for base class name change ... }; It amounts to one more line of code, the new PlatformMutex class definition. From kim.barrett at oracle.com Thu Aug 8 23:27:27 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 8 Aug 2019 19:27:27 -0400 Subject: RFR: 8229258: Make markOopDesc AllStatic In-Reply-To: <72567e47-3b52-8e30-ea6f-9a64fa043c07@redhat.com> References: <72567e47-3b52-8e30-ea6f-9a64fa043c07@redhat.com> Message-ID: > On Aug 8, 2019, at 6:57 PM, Roman Kennke wrote: > - I know it would probably disturb even more code, but shouldn't the > files markOop.* be renamed to markWord.* ? Somewhere in this thread (or maybe offline or in an earlier thread?) Stefan discussed this point and preferred to do the file renaming as a separate followup pass to avoid making this patch harder to maintain and review. That seems like a good plan to me. From kim.barrett at oracle.com Thu Aug 8 23:32:32 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 8 Aug 2019 19:32:32 -0400 Subject: RFR: 8229258: Make markOopDesc AllStatic In-Reply-To: <72567e47-3b52-8e30-ea6f-9a64fa043c07@redhat.com> References: <72567e47-3b52-8e30-ea6f-9a64fa043c07@redhat.com> Message-ID: > On Aug 8, 2019, at 6:57 PM, Roman Kennke wrote: > - I agree with Coleen that markWord vs. MarkWord is a bit confusing. Not > sure what to do though. Stefan has a prototype that attempts to address this, but it has some problems. I?m currently playing with it to see if I can fix them; some of the ideas are pretty ugly though right now, and might not work anyway. But I?m motivated to try, because I really dislike those homonyms. From david.holmes at oracle.com Fri Aug 9 05:16:39 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 9 Aug 2019 15:16:39 +1000 Subject: RFR (S): 8228857: Refactor PlatformMonitor into PlatformMutex and PlatformMonitor In-Reply-To: References: <32C9F58D-FA84-4A18-9A43-86DE2F8AD88E@oracle.com> <85649d80-f85e-4da0-dd4c-db148b33d5e8@oracle.com> Message-ID: Hi Kim, On 9/08/2019 9:17 am, Kim Barrett wrote: >> On Aug 7, 2019, at 10:51 PM, David Holmes wrote: >> >> Hi Kim, >> >> On 8/08/2019 11:59 am, Kim Barrett wrote: >>> PlatformMutex should be noncopyable on all platforms. >> >> I presume that is something PlatformMonitor should already be doing but is not? What is involved in making something non-copyable? (Sorry my basic C++ is pretty basic.) > > Yes, PlatformMonitor ought to already be doing that. > > We don't have any explicit support for declaring a class noncopyable. One > idiom that's being used is to declare the copy constructor and copy assignment > operator private and don't provide a definition for either. Then one gets a > compile time error if anything outside the class attempts to copy, and a link > time error if the copy is from inside the class (or by a friend). So in the > private part of the class > > PlatformMutex(const PlatformMutex&); > PlatformMutex& operator=(const PlatformMutex&); Okay I can add those. > Maybe we should have a helper macro for that, but nobody has proposed adding > one. For C++11 it's > > PlatformMutex(const PlatformMutex&) = delete; > PlatformMutex& operator=(const PlatformMutex&) = delete; > > anywhere in the class (public is best, to get a reference to deleted function > error message rather than possibly an access error message). > > This is a "good hygiene" thing; many of our classes "ought" to have this but > don't bother. In my limited experience it seems C++ got it backwards by providing these by default - copying and assignment should be opt-in. > >>> The inheritance runs the risk of destructor slicing, because the >>> PlatformMutex base class has a public non-virtual destructor. I don't >>> think we want to introduce a virtual destructor here. I don't know of >>> a solution that doesn't lose the inheritance relationship between the >>> classes. I don't know if that relationship is considered important. >> >> Semantically a Monitor (as we define it) is a Mutex with a condition variable, so the inheritance seems quite appropriate, even if not essential. >> >> IIUC the issue is when we have a PlatformMutex* that happens to point to a PlatformMonitor - if we delete it then we only call the PlatformMutex destructor. Why would we not just declare the destructor as virtual? What will it cost us? It seems the natural/right way to deal with inheritance in C++. > > It imposes virtual function overheads (class vtable, per-object vtable > entries, &etc) on what is intended to be simple, low-overhead classes. Okay ... > Do we care? One option is to ignore the problem; there's certainly precedent Seems like the path of least resistance, and it's relatively easy to check that we don't assign a PlatformMonitor to a PlatformMutex field. > for that in Hotspot! As a result, we can't enable some associated gcc warnings > (and have to actually turn some off), though as I've mentioned elsewhere some > of those warnings have other problems: > https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2019-July/026480.html > > Fixing without taking on virtual function costs involves losing the > base/derived relationship between these classes. I don't know if we care about > that relationship. To do this one would introduce a new helper base class, > with each deriving separately from it. > > class PlatformMutexBase ... > ... same definition as proposed PlatformMutex, except with > protected constructor and destructor ... > }; > > class PlatformMutex : public PlatformMutexBase {}; > class PlatformMonitor : public PlatformMutexBase { > ... same definition as proposed PlatformMonitor, adjusting for > base class name change ... > }; > > It amounts to one more line of code, the new PlatformMutex class definition. Okay so this supposes that we never declare variables of type PlatformMutexBase (which we shouldn't), but only PlatformMutex and PlatformMonitor, and those two are not assignment compatible and so we avoid the problem. That's not a terrible solution, but if you don't object strongly I'll stick with the current arrangement. Thanks, David From kim.barrett at oracle.com Fri Aug 9 06:03:25 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 9 Aug 2019 02:03:25 -0400 Subject: RFR (S): 8228857: Refactor PlatformMonitor into PlatformMutex and PlatformMonitor In-Reply-To: References: <32C9F58D-FA84-4A18-9A43-86DE2F8AD88E@oracle.com> <85649d80-f85e-4da0-dd4c-db148b33d5e8@oracle.com> Message-ID: <537CA04C-6956-42F6-995A-A188676343CA@oracle.com> > On Aug 9, 2019, at 1:16 AM, David Holmes wrote: > > Hi Kim, > > On 9/08/2019 9:17 am, Kim Barrett wrote: >> Maybe we should have a helper macro for that, but nobody has proposed adding >> one. For C++11 it's >> PlatformMutex(const PlatformMutex&) = delete; >> PlatformMutex& operator=(const PlatformMutex&) = delete; >> anywhere in the class (public is best, to get a reference to deleted function >> error message rather than possibly an access error message). >> This is a "good hygiene" thing; many of our classes "ought" to have this but >> don't bother. > > In my limited experience it seems C++ got it backwards by providing these by default - copying and assignment should be opt-in. You won?t get an argument from me on that. At least the syntax has improved in the newer versions, and one can now do things like changing the accessibility without affecting POD-ness and the like. >> It imposes virtual function overheads (class vtable, per-object vtable >> entries, &etc) on what is intended to be simple, low-overhead classes. > > Okay ... > >> Do we care? One option is to ignore the problem; there's certainly precedent > > Seems like the path of least resistance, and it's relatively easy to check that we don't assign a PlatformMonitor to a PlatformMutex field. Being noncopyable takes care of that. >> class PlatformMutexBase ... >> ... same definition as proposed PlatformMutex, except with >> protected constructor and destructor ... >> }; >> class PlatformMutex : public PlatformMutexBase {}; >> class PlatformMonitor : public PlatformMutexBase { >> ... same definition as proposed PlatformMonitor, adjusting for >> base class name change ... >> }; >> It amounts to one more line of code, the new PlatformMutex class definition. > > Okay so this supposes that we never declare variables of type PlatformMutexBase (which we shouldn't), [?] No ?shouldn?t? about it; the above scheme actively prevents that. PlatformMutexBase my_thing; will compile time error because neither the constructor nor the destructor are accessible. It is possible to have PlatformMutexBase* values, you just can?t call delete on them. You have to delete or destroy the derived object, which is the point. > but only PlatformMutex and PlatformMonitor, and those two are not assignment compatible and so we avoid the problem. > > That's not a terrible solution, but if you don't object strongly I'll stick with the current arrangement. I don?t think I can object strongly to things that are already pretty endemic in our code. From david.holmes at oracle.com Fri Aug 9 06:21:31 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 9 Aug 2019 16:21:31 +1000 Subject: RFR (S): 8228857: Refactor PlatformMonitor into PlatformMutex and PlatformMonitor In-Reply-To: <936e9ed0-d75c-1b73-a9da-5b15f94f7d06@oracle.com> References: <936e9ed0-d75c-1b73-a9da-5b15f94f7d06@oracle.com> Message-ID: <73463a0c-84b4-a330-4c80-dff2a4fbf442@oracle.com> Hi Dan, Sorry I forgot to reply to you - thanks for looking at this. On 8/08/2019 1:37 am, Daniel D. Daugherty wrote: > On 8/1/19 7:03 PM, David Holmes wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8228857 >> webrev: http://cr.openjdk.java.net/~dholmes/8228857/webrev/ > > src/hotspot/os/posix/os_posix.hpp > ??? L245: // Platform specific implementations that underpin VM > Monitor/Mutex classes > ??????? Perhaps "Mutex/Monitor" instead of "Monitor/Mutex" now that > ??????? Mutex is the base class. And it will be consistent with the > ??????? new comments that you've added. Changed. > src/hotspot/os/posix/os_posix.inline.hpp > ??? No comments. > > src/hotspot/os/posix/os_posix.cpp > ??? L2277: // Platform Monitor implementation > ??????? Perhaps: // Platform Mutex/Monitor implementation > ??????? like you do in other places. Changed. > src/hotspot/os/solaris/os_solaris.hpp > ??? L338: // Platform specific implementations that underpin VM > Monitor/Mutex classes > ??????? Perhaps "Mutex/Monitor" instead of "Monitor/Mutex" now that > ??????? Mutex is the base class. Changed. > src/hotspot/os/solaris/os_solaris.cpp > ??? No comments. > > src/hotspot/os/windows/os_windows.hpp > ??? L190: // Platform specific implementations that underpin VM > Monitor/Mutex classes > ??????? Perhaps "Mutex/Monitor" instead of "Monitor/Mutex" now that > ??????? Mutex is the base class. Changed. > src/hotspot/os/windows/os_windows.inline.hpp > ??? L98: inline os::PlatformMonitor::~PlatformMonitor() { > ??????? I don't remember why there is no 'DeleteConditionVariable()' > ??????? call here. It might be worth a comment to remind the reader. Comment added - there is no DeleteConditionVariable function. :) > Thumbs up. If you choose to make the comment tweaks above, I don't > need to see another webrev. v2 coming real soon due to the macOS stuff. Thanks, David > Dan > > > >> >> As suggested by Per Liden when PlatformMonitor was introduced by >> JDK-8210832 we should refactor PlatformMonitor into a simpler >> PlatformMutex extended by PlatformMonitor. That would potentially >> allow other synchronization objects e.g. Zlocks, to be replaced by a >> suitable PlatformX class, and allows us to redefine JVM_RawMonitor >> support to use it (forthcoming change). >> >> The refactoring would be obvious and simple if not for the macOS >> PThread allocation bug workaround. I had to change the Posix variant >> so that we only use the Impl helper class on macOS, so that we can >> separate the allocation of the pthread_mutex_t and pthread_cond_t. For >> macOS both get allocated in the PlatformMutex. >> >> There are not actual usage changes in this RFE. >> >> Testing: mach5 tiers 1-3 >> >> Thanks, >> David >> ----- >> > From david.holmes at oracle.com Fri Aug 9 06:25:21 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 9 Aug 2019 16:25:21 +1000 Subject: RFR (S): 8228857: Refactor PlatformMonitor into PlatformMutex and PlatformMonitor In-Reply-To: References: <32C9F58D-FA84-4A18-9A43-86DE2F8AD88E@oracle.com> <85649d80-f85e-4da0-dd4c-db148b33d5e8@oracle.com> Message-ID: <9c8ea98c-a2cd-a832-d977-678a4de379b1@oracle.com> Okay here is v2 with Kim's non-copyable adjustments and an alternate approach to the "impl" class so that the PlatformMutex doesn't have to pay for the unused pthread_cond_t. Trade-off in this scheme is that PlatformMonitor now has two "impl" pointers so consumes more space. Also made comment changes suggested by Dan. http://cr.openjdk.java.net/~dholmes/8228857/webrev.v2/ Thanks, David ----- From david.holmes at oracle.com Fri Aug 9 06:29:51 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 9 Aug 2019 16:29:51 +1000 Subject: RFR (S): 8228857: Refactor PlatformMonitor into PlatformMutex and PlatformMonitor In-Reply-To: <537CA04C-6956-42F6-995A-A188676343CA@oracle.com> References: <32C9F58D-FA84-4A18-9A43-86DE2F8AD88E@oracle.com> <85649d80-f85e-4da0-dd4c-db148b33d5e8@oracle.com> <537CA04C-6956-42F6-995A-A188676343CA@oracle.com> Message-ID: <938edb04-04fc-cef9-c883-26b084536bd4@oracle.com> Hi Kim, On 9/08/2019 4:03 pm, Kim Barrett wrote: >> On Aug 9, 2019, at 1:16 AM, David Holmes wrote: >> >> Hi Kim, >> >> On 9/08/2019 9:17 am, Kim Barrett wrote: >>> Maybe we should have a helper macro for that, but nobody has proposed adding >>> one. For C++11 it's >>> PlatformMutex(const PlatformMutex&) = delete; >>> PlatformMutex& operator=(const PlatformMutex&) = delete; >>> anywhere in the class (public is best, to get a reference to deleted function >>> error message rather than possibly an access error message). >>> This is a "good hygiene" thing; many of our classes "ought" to have this but >>> don't bother. >> >> In my limited experience it seems C++ got it backwards by providing these by default - copying and assignment should be opt-in. > > You won?t get an argument from me on that. At least the syntax has improved in the newer versions, > and one can now do things like changing the accessibility without affecting POD-ness and the like. > >>> It imposes virtual function overheads (class vtable, per-object vtable >>> entries, &etc) on what is intended to be simple, low-overhead classes. >> >> Okay ... >> >>> Do we care? One option is to ignore the problem; there's certainly precedent >> >> Seems like the path of least resistance, and it's relatively easy to check that we don't assign a PlatformMonitor to a PlatformMutex field. > > Being noncopyable takes care of that. Noncopyable doesn't stop us from doing PlatformMutex m = new PlatformMonitor(); though, does it? >>> class PlatformMutexBase ... >>> ... same definition as proposed PlatformMutex, except with >>> protected constructor and destructor ... >>> }; >>> class PlatformMutex : public PlatformMutexBase {}; >>> class PlatformMonitor : public PlatformMutexBase { >>> ... same definition as proposed PlatformMonitor, adjusting for >>> base class name change ... >>> }; >>> It amounts to one more line of code, the new PlatformMutex class definition. >> >> Okay so this supposes that we never declare variables of type PlatformMutexBase (which we shouldn't), [?] > > No ?shouldn?t? about it; the above scheme actively prevents that. > > PlatformMutexBase my_thing; > > will compile time error because neither the constructor nor the > destructor are accessible. > > It is possible to have PlatformMutexBase* values, you just can?t call > delete on them. You have to delete or destroy the derived object, > which is the point. Okay. >> but only PlatformMutex and PlatformMonitor, and those two are not assignment compatible and so we avoid the problem. >> >> That's not a terrible solution, but if you don't object strongly I'll stick with the current arrangement. > > I don?t think I can object strongly to things that are already pretty endemic in our code. I believe you can object strongly if you think we should be setting new standards of code cleanliness in new code. Though in that case we should get them codified in the style guide ASAP. Thanks, David From kim.barrett at oracle.com Fri Aug 9 06:56:39 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 9 Aug 2019 02:56:39 -0400 Subject: RFR (S): 8228857: Refactor PlatformMonitor into PlatformMutex and PlatformMonitor In-Reply-To: <938edb04-04fc-cef9-c883-26b084536bd4@oracle.com> References: <32C9F58D-FA84-4A18-9A43-86DE2F8AD88E@oracle.com> <85649d80-f85e-4da0-dd4c-db148b33d5e8@oracle.com> <537CA04C-6956-42F6-995A-A188676343CA@oracle.com> <938edb04-04fc-cef9-c883-26b084536bd4@oracle.com> Message-ID: > On Aug 9, 2019, at 2:29 AM, David Holmes wrote: > On 9/08/2019 4:03 pm, Kim Barrett wrote: >>> >>> Seems like the path of least resistance, and it's relatively easy to check that we don't assign a PlatformMonitor to a PlatformMutex field. >> Being noncopyable takes care of that. > > Noncopyable doesn't stop us from doing > > PlatformMutex m = new PlatformMonitor(); > > though, does it? I?m not sure what potential problem you are trying to describe. That?s obviously not going to compile (unless PlatformMutex provided strange conversion constructors taking pointers, but there aren?t any of those). One can do PlatformMutex* m = new PlatformMonitor(); (unless the PlatformMutexBase approach is taken, in which case that doesn?t work). >>> but only PlatformMutex and PlatformMonitor, and those two are not assignment compatible and so we avoid the problem. >>> >>> That's not a terrible solution, but if you don't object strongly I'll stick with the current arrangement. >> I don?t think I can object strongly to things that are already pretty endemic in our code. > > I believe you can object strongly if you think we should be setting new standards of code cleanliness in new code. Though in that case we should get them codified in the style guide ASAP. Don?t really feel like taking that on right now. From david.holmes at oracle.com Fri Aug 9 06:59:36 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 9 Aug 2019 16:59:36 +1000 Subject: RFR (S): 8228857: Refactor PlatformMonitor into PlatformMutex and PlatformMonitor In-Reply-To: References: <32C9F58D-FA84-4A18-9A43-86DE2F8AD88E@oracle.com> <85649d80-f85e-4da0-dd4c-db148b33d5e8@oracle.com> <537CA04C-6956-42F6-995A-A188676343CA@oracle.com> <938edb04-04fc-cef9-c883-26b084536bd4@oracle.com> Message-ID: On 9/08/2019 4:56 pm, Kim Barrett wrote: >> On Aug 9, 2019, at 2:29 AM, David Holmes wrote: >> On 9/08/2019 4:03 pm, Kim Barrett wrote: >>>> >>>> Seems like the path of least resistance, and it's relatively easy to check that we don't assign a PlatformMonitor to a PlatformMutex field. >>> Being noncopyable takes care of that. >> >> Noncopyable doesn't stop us from doing >> >> PlatformMutex m = new PlatformMonitor(); >> >> though, does it? > > I?m not sure what potential problem you are trying to describe. > > That?s obviously not going to compile (unless PlatformMutex provided strange conversion > constructors taking pointers, but there aren?t any of those). > > One can do > > PlatformMutex* m = new PlatformMonitor(); Yes sorry that is what I meant. :) Do the above then: delete m; and we get the destructor problem. David ----- > (unless the PlatformMutexBase approach is taken, in which case that doesn?t work). > >>>> but only PlatformMutex and PlatformMonitor, and those two are not assignment compatible and so we avoid the problem. >>>> >>>> That's not a terrible solution, but if you don't object strongly I'll stick with the current arrangement. >>> I don?t think I can object strongly to things that are already pretty endemic in our code. >> >> I believe you can object strongly if you think we should be setting new standards of code cleanliness in new code. Though in that case we should get them codified in the style guide ASAP. > > Don?t really feel like taking that on right now. > From erik.osterlund at oracle.com Fri Aug 9 07:43:42 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Fri, 9 Aug 2019 09:43:42 +0200 Subject: RFR: 8224815: Remove non-GC uses of CollectedHeap::is_in_reserved() Message-ID: <510179ba-415d-a615-e08d-2899a7225f50@oracle.com> Hi, The CollectedHeap::is_in_reserved() function assumes the GC has a contiguous heap. This might not be the case, and hence the shared code should not make assumptions about that. It should use CollectedHeap::is_in() instead. However, CompressedOops inherently assumes the heap is contiguous, so I let it know about the reserved region. This patch depends on 8229278 and 8229189, which are both out for review right now. Bug: https://bugs.openjdk.java.net/browse/JDK-8224815 Webrev: http://cr.openjdk.java.net/~eosterlund/8224815/webrev.00/ Thanks, /Erik From rkennke at redhat.com Fri Aug 9 08:52:59 2019 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 9 Aug 2019 10:52:59 +0200 Subject: RFR: 8229258: Make markOopDesc AllStatic In-Reply-To: References: <72567e47-3b52-8e30-ea6f-9a64fa043c07@redhat.com> Message-ID: <009a6d2b-62ba-cc86-d6f9-265db6d555ff@redhat.com> >> - I know it would probably disturb even more code, but shouldn't the >> files markOop.* be renamed to markWord.* ? > > Somewhere in this thread (or maybe offline or in an earlier thread?) Stefan discussed > this point and preferred to do the file renaming as a separate followup pass to avoid > making this patch harder to maintain and review. That seems like a good plan to me. Good with me! :-) Roman From christoph.goettschkes at microdoc.com Fri Aug 9 10:05:01 2019 From: christoph.goettschkes at microdoc.com (christoph.goettschkes at microdoc.com) Date: Fri, 9 Aug 2019 12:05:01 +0200 Subject: Advice on how to push changes back for ARMv7-A softfp platforms Message-ID: Hello, while working with the OpenJDK 11 on an ARMv7-A soft-fp linux based platform, we found some issues in the template interpreter and in the C1 JIT compiler. I already send an email to this mailing list some time ago with a patch for one of the issues, but did not receive any feedback. Could you please advice on how to proceed to push these changes back to you? Thanks, Christoph From boris.ulasevich at bell-sw.com Fri Aug 9 10:38:33 2019 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Fri, 9 Aug 2019 13:38:33 +0300 Subject: Advice on how to push changes back for ARMv7-A softfp platforms In-Reply-To: <20190809100656.E5593308169@aojmv0009> References: <20190809100656.E5593308169@aojmv0009> Message-ID: Hi Christoph, Let me create bug record for you. Here it is: https://bugs.openjdk.java.net/browse/JDK-8229352 Please provide more details on the issue and come up with webrev (I can help you). Here are some details on the process: https://openjdk.java.net/contribute thanks, Boris On 09.08.2019 13:05, christoph.goettschkes at microdoc.com wrote: > Hello, > > while working with the OpenJDK 11 on an ARMv7-A soft-fp linux based > platform, we found some issues in the template interpreter and in the C1 > JIT compiler. I already send an email to this mailing list some time ago > with a patch for one of the issues, but did not receive any feedback. > > Could you please advice on how to proceed to push these changes back to > you? > > Thanks, > Christoph From christoph.goettschkes at microdoc.com Fri Aug 9 11:04:01 2019 From: christoph.goettschkes at microdoc.com (christoph.goettschkes at microdoc.com) Date: Fri, 9 Aug 2019 13:04:01 +0200 Subject: Advice on how to push changes back for ARMv7-A softfp platforms In-Reply-To: References: <20190809100656.E5593308169@aojmv0009> Message-ID: Hi Boris, thanks a lot for the bug report. I can send my patches and the description again to the mailing list using this bug ID now. Since I do not have any accounts in your infrastructure, I think I am not able to create and share webrevs with you. Should I request accounts for cr.openjdk.java.net, or are patches send to this mailing list fine as well? -- Christoph From: Boris Ulasevich To: christoph.goettschkes at microdoc.com Cc: hotspot-dev at openjdk.java.net Date: 2019-08-09 12:38 Subject: Re: Advice on how to push changes back for ARMv7-A softfp platforms Hi Christoph, Let me create bug record for you. Here it is: https://bugs.openjdk.java.net/browse/JDK-8229352 Please provide more details on the issue and come up with webrev (I can help you). Here are some details on the process: https://openjdk.java.net/contribute thanks, Boris On 09.08.2019 13:05, christoph.goettschkes at microdoc.com wrote: > Hello, > > while working with the OpenJDK 11 on an ARMv7-A soft-fp linux based > platform, we found some issues in the template interpreter and in the C1 > JIT compiler. I already send an email to this mailing list some time ago > with a patch for one of the issues, but did not receive any feedback. > > Could you please advice on how to proceed to push these changes back to > you? > > Thanks, > Christoph From boris.ulasevich at bell-sw.com Fri Aug 9 11:49:00 2019 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Fri, 9 Aug 2019 14:49:00 +0300 Subject: Advice on how to push changes back for ARMv7-A softfp platforms In-Reply-To: <20190809140536.5ZjSsbrc@mxfront2o.mail.yandex.net> References: <20190809100656.E5593308169@aojmv0009> <20190809140536.5ZjSsbrc@mxfront2o.mail.yandex.net> Message-ID: <6ef8da8c-64bd-d2b5-8a16-2c4d50510c38@bell-sw.com> Hi Christoph, I can create webrev for you. Please note that we should not directly patch jdk11u. We should push the fix to jdk-jdk, and then backport the change to jdk11u. Your patch is not applied cleanly to the upstream because of a minor change around exit label. I think for jdk-jdk the change can be like this: http://cr.openjdk.java.net/~bulasevich/8229352/webrev.00 A good practice for review is to add a test to reproduce the problem. Did your company (or you personally) signed OCA? thanks, Boris On 09.08.2019 14:04, christoph.goettschkes at microdoc.com wrote: > Hi Boris, > > thanks a lot for the bug report. I can send my patches and the description > again to the mailing list using this bug ID now. Since I do not have any > accounts in your infrastructure, I think I am not able to create and share > webrevs with you. > > Should I request accounts for cr.openjdk.java.net, or are patches send to > this mailing list fine as well? > > -- Christoph > > > > > From: Boris Ulasevich > To: christoph.goettschkes at microdoc.com > Cc: hotspot-dev at openjdk.java.net > Date: 2019-08-09 12:38 > Subject: Re: Advice on how to push changes back for ARMv7-A softfp > platforms > > > > Hi Christoph, > > Let me create bug record for you. Here it is: > https://bugs.openjdk.java.net/browse/JDK-8229352 > > Please provide more details on the issue and come up with webrev (I can > help you). Here are some details on the process: > https://openjdk.java.net/contribute > > thanks, > Boris > > On 09.08.2019 13:05, christoph.goettschkes at microdoc.com wrote: >> Hello, >> >> while working with the OpenJDK 11 on an ARMv7-A soft-fp linux based >> platform, we found some issues in the template interpreter and in the C1 >> JIT compiler. I already send an email to this mailing list some time ago >> with a patch for one of the issues, but did not receive any feedback. >> >> Could you please advice on how to proceed to push these changes back to >> you? >> >> Thanks, >> Christoph > > > From jwkozaczuk at gmail.com Fri Aug 9 12:23:33 2019 From: jwkozaczuk at gmail.com (Waldek Kozaczuk) Date: Fri, 9 Aug 2019 08:23:33 -0400 Subject: Jetty hangs early on Java 12 on OSv with Threadlocal Handshakes ON - shorter version In-Reply-To: <01d12413-dfda-d2ad-0e17-6e9f3d0f4f0d@oracle.com> References: <01d12413-dfda-d2ad-0e17-6e9f3d0f4f0d@oracle.com> Message-ID: Hi, Thanks for your suggestions. I have tried against openjdk-jdk12-latest-linux-x86_64-release.tar.xz from https://builds.shipilev.net/openjdk-jdk12/ and openjdk-jdk13-latest-linux-x86_64-release.tar.xz (Java 13) from https://builds.shipilev.net/openjdk-jdk13/ and I am seeing same symptoms - hanging. I have also tried to use the fast-debug distribution - openjdk-jdk12-latest-linux-x86_64-fastdebug.tar.xz - but unfortunately I hit this snag per gdb: (gdb) bt #0 0x00000000403ad582 in processor::cli_hlt () at arch/x64/processor.hh:247 #1 arch::halt_no_interrupts () at arch/x64/arch.hh:48 #2 osv::halt () at arch/x64/power.cc:26 #3 0x0000000040241ac4 in abort (fmt=fmt at entry=0x406666d9 "general protection fault\n") at runtime.cc:132 #4 0x00000000403a8a25 in general_protection (ef=0xffff8000022cf068) at arch/x64/exceptions.cc:322 #5 #6 0x0000200008cf9c6a in ?? () *#7 0x000010000264087f in SafeFetch32 (errValue=2748, adr=0xabc0000000000abc) at /home/buildbot/worker/jdk12u-linux/build/src/hotspot/share/runtime/stubRoutines.hpp:461*#8 test_safefetch32 () at /home/buildbot/worker/jdk12u-linux/build/src/hotspot/share/runtime/stubRoutines.cpp:245 #9 StubRoutines::initialize2 () at /home/buildbot/worker/jdk12u-linux/build/src/hotspot/share/runtime/stubRoutines.cpp:366 #10 0x00001000026410ba in stubRoutines_init2 () at /home/buildbot/worker/jdk12u-linux/build/src/hotspot/share/runtime/stubRoutines.cpp:375 #11 0x0000100001c6c944 in init_globals () at /home/buildbot/worker/jdk12u-linux/build/src/hotspot/share/runtime/init.cpp:146 #12 0x000010000270c1c4 in Threads::create_vm (args=args at entry=0x2000002fff50, canTryAgain=canTryAgain at entry=0x2000002ffe8f) at /home/buildbot/worker/jdk12u-linux/build/src/hotspot/share/runtime/thread.cpp:3729 #13 0x0000100001de5ac5 in JNI_CreateJavaVM_inner (args=0x2000002fff50, penv=0x2000002fff48, vm=0x2000002fff40) at /home/buildbot/worker/jdk12u-linux/build/src/hotspot/share/prims/jni.cpp:3935 #14 JNI_CreateJavaVM (vm=0x2000002fff40, penv=0x2000002fff48, args=0x2000002fff50) at /home/buildbot/worker/jdk12u-linux/build/src/hotspot/share/prims/jni.cpp:4021 #15 0x0000100000a04144 in InitializeJVM (ifn=, penv=0x2000002fff48, pvm=0x2000002fff40) at /home/buildbot/worker/jdk12u-linux/build/src/java.base/share/native/libjli/java.c:1529 #16 JavaMain (_args=) at /home/buildbot/worker/jdk12u-linux/build/src/java.base/share/native/libjli/java.c:414 #17 0x000000004045eec6 in pthread_private::pthread::::operator() (__closure=0xffffa000012d9d00) at libc/pthread.cc:114 #18 std::_Function_handler >::_M_invoke(const std::_Any_data &) (__functor=...) at /usr/include/c++/8/bits/std_function.h:297 #19 0x0000000040401117 in sched::thread_main_c (t=0xffff8000022ca040) at arch/x64/arch-switch.hh:271 #20 0x00000000403a71d3 in thread_main () at arch/x64/entry.S:113 which has to do with SafeFetch32 which seems on purpose to read data from invalid address ( https://github.com/openjdk/jdk/blob/1e5a1997b0bbe4fa9f746338283d2f325324cdf4/src/hotspot/share/runtime/stubRoutines.cpp#L262-L273). I am guessing some code in JDK (where?) sets up a SIGSEGV handler to catch it. I am not sure why OSv handles it as general protection fault. Either way I was wondering how critical that SafeFetch32 mechanism is and can it be disabled? Should I simply build JDK frm source and comment those relevant lines out? Meanwhile, I managed to enable some logging with the original release Zulu version of OpenJDK 12 but and here is the log info I am getting: OSv v0.53.0-74-gef56fde7 eth0: 192.168.122.15 Booted up in 134.50 ms [0.068s][debug][gc] ConcGCThreads: 1 offset 8 [0.070s][debug][gc] ParallelGCThreads: 4 [0.071s][debug][gc] Initialize mark stack with 4096 chunks, maximum 16384 [0.078s][info ][gc] Using G1 [0.204s][info ][gc] Periodic GC disabled [0.267s][debug][vmthread] Adding VM operation: EnableBiasedLocking [0.268s][debug][vmthread] Evaluating safepoint VM operation: EnableBiasedLocking [0.277s][debug][vmthread] Adding VM operation: RevokeBias [0.278s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [0.301s][debug][vmthread] Adding VM operation: Deoptimize [0.302s][debug][vmthread] Evaluating safepoint VM operation: Deoptimize [0.513s][debug][vmthread] Adding VM operation: Deoptimize [0.514s][debug][vmthread] Evaluating safepoint VM operation: Deoptimize [0.584s][debug][vmthread] Adding VM operation: Deoptimize [0.585s][debug][vmthread] Evaluating safepoint VM operation: Deoptimize fpathconf() stubbed 2019-08-09 11:29:28.235:INFO::main: Logging initialized @691ms [0.761s][debug][vmthread] Adding VM operation: Deoptimize [0.762s][debug][vmthread] Evaluating safepoint VM operation: Deoptimize [0.776s][debug][vmthread] Adding VM operation: Deoptimize [0.777s][debug][vmthread] Evaluating safepoint VM operation: Deoptimize [0.890s][debug][vmthread] Adding VM operation: G1CollectForAllocation [0.891s][debug][vmthread] Evaluating safepoint VM operation: G1CollectForAllocation [0.900s][info ][gc ] GC(0) Pause Young (Normal) (G1 Evacuation Pause) 14M->2M(32M) 7.546ms [0.901s][debug][vmthread] Adding VM operation: RevokeBias [0.902s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [0.904s][debug][vmthread] Adding VM operation: RevokeBias [0.905s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [0.906s][debug][vmthread] Adding VM operation: RevokeBias [0.907s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [0.909s][debug][vmthread] Adding VM operation: RevokeBias [0.909s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [0.911s][debug][vmthread] Adding VM operation: RevokeBias [0.911s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [0.912s][debug][vmthread] Adding VM operation: RevokeBias [0.913s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [0.914s][debug][vmthread] Adding VM operation: RevokeBias [0.915s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [0.921s][debug][vmthread] Adding VM operation: RevokeBias [0.921s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [0.922s][debug][vmthread] Adding VM operation: RevokeBias [0.923s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [0.926s][debug][vmthread] Adding VM operation: RevokeBias [0.927s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [0.928s][debug][vmthread] Adding VM operation: RevokeBias [0.929s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [0.931s][debug][vmthread] Adding VM operation: RevokeBias [0.932s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [0.934s][debug][vmthread] Adding VM operation: RevokeBias [0.936s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [0.948s][debug][vmthread] Adding VM operation: RevokeBias [0.949s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.050s][debug][vmthread] Adding VM operation: Deoptimize [1.051s][debug][vmthread] Evaluating safepoint VM operation: Deoptimize [1.066s][debug][vmthread] Adding VM operation: Deoptimize [1.067s][debug][vmthread] Evaluating safepoint VM operation: Deoptimize 2019-08-09 11:29:28.637:WARN::main: demo test-realm is deployed. DO NOT USE IN PRODUCTION! [1.096s][debug][vmthread] Adding VM operation: RevokeBias [1.097s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias2019-08-09 11:29:28.641:INFO:oejs.Server:main: jetty-9.2.11.v20150529 [1.105s][debug][vmthread] Adding VM operation: Deoptimize [1.106s][debug][vmthread] Evaluating safepoint VM operation: Deoptimize 2019-08-09 11:29:28.658:INFO:oejdp.ScanningAppProvider:main: Deployment monitor [file:/jetty/demo-base/webapps/] at interval 1 [1.157s][debug][vmthread] Adding VM operation: Deoptimize [1.158s][debug][vmthread] Evaluating safepoint VM operation: Deoptimize [1.184s][debug][vmthread] Adding VM operation: Deoptimize [1.185s][debug][vmthread] Evaluating safepoint VM operation: Deoptimize [1.226s][debug][vmthread] Adding VM operation: G1CollectForAllocation [1.227s][debug][vmthread] Evaluating safepoint VM operation: G1CollectForAllocation [1.243s][info ][gc ] GC(1) Pause Young (Normal) (G1 Evacuation Pause) 15M->3M(32M) 14.143ms [1.244s][debug][vmthread] Adding VM operation: RevokeBias [1.245s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.246s][debug][vmthread] Adding VM operation: RevokeBias [1.247s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.248s][debug][vmthread] Adding VM operation: RevokeBias [1.248s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.249s][debug][vmthread] Adding VM operation: RevokeBias [1.250s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.251s][debug][vmthread] Adding VM operation: RevokeBias [1.252s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.253s][debug][vmthread] Adding VM operation: RevokeBias [1.254s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.255s][debug][vmthread] Adding VM operation: RevokeBias [1.256s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.257s][debug][vmthread] Adding VM operation: RevokeBias [1.258s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.260s][debug][vmthread] Adding VM operation: RevokeBias [1.261s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.263s][debug][vmthread] Adding VM operation: RevokeBias [1.263s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.264s][debug][vmthread] Adding VM operation: RevokeBias [1.265s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.266s][debug][vmthread] Adding VM operation: RevokeBias [1.267s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.269s][debug][vmthread] Adding VM operation: RevokeBias [1.269s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.271s][debug][vmthread] Adding VM operation: RevokeBias [1.272s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.273s][debug][vmthread] Adding VM operation: RevokeBias [1.274s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.275s][debug][vmthread] Adding VM operation: RevokeBias [1.276s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.277s][debug][vmthread] Adding VM operation: RevokeBias [1.278s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.279s][debug][vmthread] Adding VM operation: RevokeBias [1.280s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.373s][debug][vmthread] Adding VM operation: RevokeBias [1.374s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.411s][debug][vmthread] Adding VM operation: RevokeBias [1.412s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.413s][debug][vmthread] Adding VM operation: RevokeBias [1.414s][debug][vmthread] Evaluating coalesced safepoint VM operation: RevokeBias [1.416s][debug][vmthread] Adding VM operation: RevokeBias [1.417s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.418s][debug][vmthread] Adding VM operation: RevokeBias [1.419s][debug][vmthread] Evaluating coalesced safepoint VM operation: RevokeBias [1.420s][debug][vmthread] Adding VM operation: RevokeBias [1.421s][debug][vmthread] Adding VM operation: BulkRevokeBias [1.422s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.423s][debug][vmthread] Evaluating coalesced safepoint VM operation: BulkRevokeBias [1.424s][debug][vmthread] Adding VM operation: RevokeBias [1.425s][debug][vmthread] Adding VM operation: RevokeBias [1.426s][debug][vmthread] Adding VM operation: RevokeBias [1.427s][debug][vmthread] Adding VM operation: RevokeBias [1.427s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.429s][debug][vmthread] Evaluating coalesced safepoint VM operation: RevokeBias [1.430s][debug][vmthread] Evaluating coalesced safepoint VM operation: RevokeBias [1.431s][debug][vmthread] Evaluating coalesced safepoint VM operation: RevokeBias [1.432s][debug][vmthread] Adding VM operation: RevokeBias [1.433s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.434s][debug][vmthread] Adding VM operation: RevokeBias [1.434s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.435s][debug][vmthread] Adding VM operation: RevokeBias [1.436s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.437s][debug][vmthread] Adding VM operation: RevokeBias [1.438s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.439s][debug][vmthread] Adding VM operation: RevokeBias [1.440s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.441s][debug][vmthread] Adding VM operation: RevokeBias [1.442s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.443s][debug][vmthread] Adding VM operation: RevokeBias [1.443s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.445s][debug][vmthread] Adding VM operation: RevokeBias [1.445s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.446s][debug][vmthread] Adding VM operation: RevokeBias [1.447s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.448s][debug][vmthread] Adding VM operation: RevokeBias [1.449s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.450s][debug][vmthread] Adding VM operation: RevokeBias [1.451s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.452s][debug][vmthread] Adding VM operation: RevokeBias [1.453s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.454s][debug][vmthread] Adding VM operation: RevokeBias [1.454s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.456s][debug][vmthread] Adding VM operation: RevokeBias [1.456s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.457s][debug][vmthread] Adding VM operation: RevokeBias [1.458s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.459s][debug][vmthread] Adding VM operation: RevokeBias [1.460s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.461s][debug][vmthread] Adding VM operation: RevokeBias [1.462s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.464s][debug][vmthread] Adding VM operation: BulkRevokeBias [1.464s][debug][vmthread] Evaluating safepoint VM operation: BulkRevokeBias [1.466s][debug][vmthread] Adding VM operation: RevokeBias [1.466s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.467s][debug][vmthread] Adding VM operation: RevokeBias [1.468s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.469s][debug][vmthread] Adding VM operation: RevokeBias [1.470s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.472s][debug][vmthread] Adding VM operation: RevokeBias [1.473s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.474s][debug][vmthread] Adding VM operation: RevokeBias [1.475s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.476s][debug][vmthread] Adding VM operation: RevokeBias [1.477s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.479s][debug][vmthread] Adding VM operation: RevokeBias [1.480s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.481s][debug][vmthread] Adding VM operation: RevokeBias [1.482s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.484s][debug][vmthread] Adding VM operation: RevokeBias [1.485s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.490s][debug][vmthread] Adding VM operation: RevokeBias [1.491s][debug][vmthread] Adding VM operation: RevokeBias [1.492s][debug][vmthread] Adding VM operation: BulkRevokeBias [1.493s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.493s][debug][vmthread] Adding VM operation: RevokeBias [1.496s][debug][vmthread] Evaluating coalesced safepoint VM operation: RevokeBias [1.502s][debug][vmthread] Evaluating coalesced safepoint VM operation: BulkRevokeBias [1.504s][debug][vmthread] Evaluating coalesced safepoint VM operation: RevokeBias [1.506s][debug][vmthread] Adding VM operation: RevokeBias [1.507s][debug][vmthread] Adding VM operation: RevokeBias [1.508s][debug][vmthread] Adding VM operation: RevokeBias [1.510s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.510s][debug][vmthread] Adding VM operation: RevokeBias [1.513s][debug][vmthread] Evaluating coalesced safepoint VM operation: RevokeBias [1.514s][debug][vmthread] Evaluating coalesced safepoint VM operation: RevokeBias [1.516s][debug][vmthread] Evaluating coalesced safepoint VM operation: RevokeBias [1.518s][debug][vmthread] Adding VM operation: RevokeBias [1.519s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.520s][debug][vmthread] Adding VM operation: RevokeBias [1.521s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.522s][debug][vmthread] Adding VM operation: RevokeBias [1.524s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.526s][debug][vmthread] Adding VM operation: RevokeBias [1.528s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.529s][debug][vmthread] Adding VM operation: RevokeBias [1.530s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.532s][debug][vmthread] Adding VM operation: RevokeBias [1.533s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.534s][debug][vmthread] Adding VM operation: RevokeBias [1.536s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.537s][debug][vmthread] Adding VM operation: RevokeBias [1.539s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.540s][debug][vmthread] Adding VM operation: RevokeBias [1.542s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.543s][debug][vmthread] Adding VM operation: RevokeBias [1.545s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.546s][debug][vmthread] Adding VM operation: RevokeBias [1.547s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.549s][debug][vmthread] Adding VM operation: RevokeBias [1.551s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.552s][debug][vmthread] Adding VM operation: RevokeBias [1.554s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.555s][debug][vmthread] Adding VM operation: RevokeBias [1.556s][debug][vmthread] Evaluating safepoint VM operation: RevokeBias [1.559s][debug][vmthread] Adding VM operation: HandshakeAllThreads *[1.560s][debug][vmthread] Adding VM operation: RevokeBias[1.561s][debug][vmthread] Evaluating non-safepoint VM operation: HandshakeAllThreads[1.563s][debug][handshake] Threads signaled, begin processing blocked threads by VMThtread* And it always stops like that and gdb shows similar state as I originally posted. Now I have tried to analyze the code in handshakes.cpp (I think this version applied to me - https://github.com/openjdk/jdk/blob/jdk-12%2B12/src/hotspot/share/runtime/handshake.cpp) and here is my reasoning about why this hanging in active loop happens: 1. VM Thread executes VM_HandshakeAllThreads::doit() ( https://github.com/openjdk/jdk/blob/jdk-12%2B12/src/hotspot/share/runtime/handshake.cpp#L178 ). 2. It iterates through all JavaThread instances from the jtiwh collection (what exactly is this?) and SHOULD end up calling HandshakeState::process_by_vmthread ( https://github.com/openjdk/jdk/blob/jdk-12%2B12/src/hotspot/share/runtime/handshake.cpp#L361) which eventually should call HandshakeThreadsOperation::do_handshake(JavaThread* thread) for each JavaThread and increment the _done semaphore BUT only if the process_by_vmthread() calls _operation->do_handshake(target), right? But there are at least 3 IFs which may cause this method to return and the critical 4th IF ( https://github.com/openjdk/jdk/blob/jdk-12%2B12/src/hotspot/share/runtime/handshake.cpp#L379-L389) which only executes its body if vmthread_can_process_handshake returns true. What could make these first 3 IF be true and make process_by_vmthread to return BEFORE the last if? When would last IF be false? 3. VM_HandshakeAllThreads::doit() loops by calling poll_for_completed_thread() which NEVER completes. Correct me where I made any mistake in my thinking. Thanks in advance for your support, Waldek On Thu, Aug 8, 2019 at 6:53 AM Robbin Ehn wrote: > Hi Waldek, > > > > #0 0x0000100000c86370 in sem_trywait at plt () > > #1 0x0000100001702bf2 in PosixSemaphore::trywait() () > > #2 0x000010000121aab4 in VM_HandshakeAllThreads::doit() () > > VMThread is trying to figure out which threads have not executed their > handshake > operation and possible execute it for them (e.g. JavaThread in native). > > If you attach gdb and step around in VM_HandshakeAllThreads::doit while > looping > there, you can figure out why we never finish. > > > When I explicitly enable thread local handshakes on Java 11 it works as > > well: > > In 11 it is only used by ZGC, but in 12 it is used for stack-scanning > after > nmethods. > > Sweeper thread: > > #12 0x0000100001219a48 in Handshake::execute(ThreadClosure*) () > #13 0x00001000018b4a0c in NMethodSweeper::possibly_sweep() () > > > One more datapoint - I am able to run a simple Hello World java app on > Java > > 12 on OSv with thread-local handshakes on so it looks like this problem > > appears on more complicated apps. > > If you never get to needing to sweep nmethod, you will have never executed > a > handshake. (but you will execute safepoints using the handshake poll) > > If you can easily reprod, take a slowdebug and when the process hang, > attach gdb > switch to VMThread and step around, you will see a count which decrease > once for > every thread which have executed it's handshake. To figure out if a thread > have > executed it's handshake, VMThread will take a per thread semaphore > (decrease > it), which serialize access to the per thread handshake operation, and > then look > if the operation is completed, return the semaphore (increase it), and > look at > next thread. > > /Robbin > > > > > *Lastly, the exact same app works fine on Java 12 on Linux.* > > > > So given all that could you please point me to what the problem might be? > > What has changed in the implementation of thread local handshakes between > > Java 11 and 12 that may have caused this issue (I see many changes made > to > > > https://github.com/openjdk/jdk/blob/0fe0312f416add1536a45ecfb292c887ef7e02bd/src/hotspot/share/runtime/handshake.cpp > > but > > I am not even sure which commit matches the version of Java 12 or Java > 11 I > > am using)? I am thinking this has to do with some subtle differences > > between relevant ABI implementation between OSv and Linux. Signals > related? > > > > Thanks for your help in advance, > > > > Waldek > > > > Thread dump of all Java threads (in other email that was to big) > > > From christoph.goettschkes at microdoc.com Fri Aug 9 12:49:52 2019 From: christoph.goettschkes at microdoc.com (christoph.goettschkes at microdoc.com) Date: Fri, 9 Aug 2019 14:49:52 +0200 Subject: Advice on how to push changes back for ARMv7-A softfp platforms In-Reply-To: <6ef8da8c-64bd-d2b5-8a16-2c4d50510c38@bell-sw.com> References: <20190809100656.E5593308169@aojmv0009> <20190809140536.5ZjSsbrc@mxfront2o.mail.yandex.net> <6ef8da8c-64bd-d2b5-8a16-2c4d50510c38@bell-sw.com> Message-ID: Hi Boris, thank you for the webrev. I checked jdk/jdk and you are right, there are differences in the file, but not regarding this issue. Some of the differences are because the AArch64 code has been removed from the cpu/arm port in jdk/jdk. In jdk-updates/jdk11u, the cpu/arm source base also includes an AArch64 port. The patch looks good to me. I did not create a test case for this issue, because I don't know if one is able to check if the template interpreter calls the interpreter runtime or not. Resolving this issue makes the template interpreter faster, because it does not call the interpreter runtime (using the condy_helper function), but is able to load in the constant in the generated code. A simple test case (which I used and checked using a debugger, back when I patched our source base) is something like the following (It is not the test I used, but should work as well): class Test { public static void main(String... args) { long x = 12345678910L; } } Also, since the Rtemp is not initialized in the code generated by this template, it could be, that the path for loading a long constant is used, even if the type is of double, but I don't know if this is only a theoretical bug or if it might appear in practice as well. I never saw it happening. Yes, there is an OCA signed for MicroDoc Software GmbH. Thanks, Christoph Boris Ulasevich wrote on 2019-08-09 13:49:00: > From: Boris Ulasevich > To: christoph.goettschkes at microdoc.com > Cc: hotspot-dev at openjdk.java.net > Date: 2019-08-09 13:49 > Subject: Re: Advice on how to push changes back for ARMv7-A softfp platforms > > Hi Christoph, > > I can create webrev for you. Please note that we should not directly > patch jdk11u. We should push the fix to jdk-jdk, and then backport the > change to jdk11u. Your patch is not applied cleanly to the upstream > because of a minor change around exit label. I think for jdk-jdk the > change can be like this: > http://cr.openjdk.java.net/~bulasevich/8229352/webrev.00 > > A good practice for review is to add a test to reproduce the problem. > > Did your company (or you personally) signed OCA? > > thanks, > Boris > From robbin.ehn at oracle.com Fri Aug 9 13:05:35 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Fri, 9 Aug 2019 15:05:35 +0200 Subject: Jetty hangs early on Java 12 on OSv with Threadlocal Handshakes ON - shorter version In-Reply-To: References: <01d12413-dfda-d2ad-0e17-6e9f3d0f4f0d@oracle.com> Message-ID: <6e41d3f6-bbdc-c1f6-a278-bb031ddb90e6@oracle.com> Hi, On 2019-08-09 14:23, Waldek Kozaczuk wrote: > Hi, > > Thanks for your suggestions. > > I have tried against??openjdk-jdk12-latest-linux-x86_64-release.tar.xz from > https://builds.shipilev.net/openjdk-jdk12/?and?openjdk-jdk13-latest-linux-x86_64-release.tar.xz > (Java 13) from https://builds.shipilev.net/openjdk-jdk13/? and I am seeing same > symptoms - hanging. Pickup a slowdebug jdk/jdk, I think Shipilev calls that openjdk-jdk. > > I have also tried to use the fast-debug distribution > -?openjdk-jdk12-latest-linux-x86_64-fastdebug.tar.xz - but unfortunately I hit > this snag per gdb: Either just start the process with >java -cp . MyHang & pid is printed wait until hang >gdb -p gdb>i thread note the VMThread number gdb>t VMThreadNumber gdb>step ... until you see what thread is not completed if all threads are completed but we are still not reached zero a thread wrongfully elided the handshake Alternative you can also do: >gdb --args java -cp . MyHang >handle all nostop noprint pass gdb will now ignore signals gdb>run wait for hang, do what I describe above > > 2. It iterates through all JavaThread instances from the jtiwh collection (what > exactly is this?) We use hazard pointers for lock-free JavaThread accesses. jtiwh is a iterator for looping over this lock-free data-structure. and SHOULD end up calling HandshakeState::process_by_vmthread > (https://github.com/openjdk/jdk/blob/jdk-12%2B12/src/hotspot/share/runtime/handshake.cpp#L361) > which eventually should call HandshakeThreadsOperation::do_handshake(JavaThread* > thread) for each JavaThread and increment the _done semaphore BUT only if the > process_by_vmthread() calls _operation->do_handshake(target), right? But there > are at least 3 IFs which may cause this method to return and the critical 4th IF > (https://github.com/openjdk/jdk/blob/jdk-12%2B12/src/hotspot/share/runtime/handshake.cpp#L379-L389) > which only executes its body if vmthread_can_process_handshake returns true. > What could make these first 3 IF be true and make > process_by_vmthread to return BEFORE the last if? When would last IF be false? Either the JavaThread itself process the handshake, if it has not done so VMThread checks is it would be safe to processes it on behalf of the JavaThread. > > 3. VM_HandshakeAllThreads::doit()?loops by calling poll_for_completed_thread() > which NEVER completes. It do that just fine on Linux/Windows/OSX. I'm guessing there is a bug in one of the OS primitives used. Since the uses of semaphores is new in hotspot, that would be my first candidate. There are one per thread semaphore and one operation semaphore. For every post on the operation semaphore number_of_threads_completed is increased. If VMThread never leaves means he did get all the posts he wanted. Instead of gdb, it may be easier to start with adding: -XX:HandshakeTimeout=1000 That should give some valuable output. /Robbin > > Correct me where I made any mistake in my thinking. > > Thanks in advance for your support, > Waldek > > > > > > > On Thu, Aug 8, 2019 at 6:53 AM Robbin Ehn > wrote: > > Hi Waldek, > > > > #0? 0x0000100000c86370 in sem_trywait at plt () > > #1? 0x0000100001702bf2 in PosixSemaphore::trywait() () > > #2? 0x000010000121aab4 in VM_HandshakeAllThreads::doit() () > > VMThread is trying to figure out which threads have not executed their > handshake > operation and possible execute it for them (e.g. JavaThread in native). > > If you attach gdb and step around in VM_HandshakeAllThreads::doit while looping > there, you can figure out why we never finish. > > > When I explicitly enable thread local handshakes on Java 11 it works as > > well: > > In 11 it is only used by ZGC, but in 12 it is used for stack-scanning after > nmethods. > > Sweeper thread: > > #12 0x0000100001219a48 in Handshake::execute(ThreadClosure*) () > #13 0x00001000018b4a0c in NMethodSweeper::possibly_sweep() () > > > One more datapoint - I am able to run a simple Hello World java app on Java > > 12 on OSv with thread-local handshakes on so it looks like this problem > > appears on more complicated apps. > > If you never get to needing to sweep nmethod, you will have never executed a > handshake. (but you will execute safepoints using the handshake poll) > > If you can easily reprod, take a slowdebug and when the process hang, attach > gdb > switch to VMThread and step around, you will see a count which decrease once > for > every thread which have executed it's handshake. To figure out if a thread have > executed it's handshake, VMThread will take a per thread semaphore (decrease > it), which serialize access to the per thread handshake operation, and then > look > if the operation is completed, return the semaphore (increase it), and look at > next thread. > > /Robbin > > > > > *Lastly, the exact same app works fine on Java 12 on Linux.* > > > > So given all that could you please point me to what the problem might be? > > What has changed in the implementation of thread local handshakes between > > Java 11 and 12 that may have caused this issue (I see many changes made to > > > https://github.com/openjdk/jdk/blob/0fe0312f416add1536a45ecfb292c887ef7e02bd/src/hotspot/share/runtime/handshake.cpp > > but > > I am not even sure which commit matches the version of Java 12 or Java 11 I > > am using)? I am thinking this has to do with some subtle differences > > between relevant ABI implementation between OSv and Linux. Signals related? > > > > Thanks for your help in advance, > > > > Waldek > > > > Thread dump of all Java threads (in other email that was to big) > > > From boris.ulasevich at bell-sw.com Fri Aug 9 13:14:51 2019 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Fri, 9 Aug 2019 16:14:51 +0300 Subject: RFR(S): 8229254: solaris_x64 build fails Message-ID: <9a371ec1-e125-4945-521b-90bb2b4c6984@bell-sw.com> Hi, Please review the following simple change to make solaris_x64 build compilable. Syntax error was brought by JDK-8191278 [1]. The fix is evident. Missing constant issue occurred after JDK-8226238 [2]. I copied workaround for the case of missing EM_AARCH64 constant in system elf.h header from os_linux.cpp implementation. http://cr.openjdk.java.net/~bulasevich/8229254/webrev.00 http://bugs.openjdk.java.net/browse/JDK-8229254 Testing done: tier1,tier2. thanks, Boris [1] MappedByteBuffer bulk access memory failures are not handled gracefully http://mail.openjdk.java.net/pipermail/hotspot-dev/2019-June/038352.html [2] Improve error output and fix elf issues in os::dll_load http://mail.openjdk.java.net/pipermail/hotspot-dev/2019-June/038597.html From boris.ulasevich at bell-sw.com Fri Aug 9 13:50:34 2019 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Fri, 9 Aug 2019 16:50:34 +0300 Subject: Advice on how to push changes back for ARMv7-A softfp platforms In-Reply-To: <20190809155127.pRUO0wtp@mxfront8o.mail.yandex.net> References: <20190809100656.E5593308169@aojmv0009> <20190809140536.5ZjSsbrc@mxfront2o.mail.yandex.net> <6ef8da8c-64bd-d2b5-8a16-2c4d50510c38@bell-sw.com> <20190809155127.pRUO0wtp@mxfront8o.mail.yandex.net> Message-ID: Hi Christoph, I see. I do not know how to write test for the issue too. By the way, current implementation can (1) make unnecessary call to interpreter runtime and (2) can make wrong load when Rtemp is equal to JVM_CONSTANT_Long by chance. So the change is critical for arm32-sflt. Did you run jtreg tests? Please proceed with review. I can update webrev and bug report and help you with pushing the change when it is accepted (I am not a reviewer). regards, Boris On 09.08.2019 15:49, christoph.goettschkes at microdoc.com wrote: > Hi Boris, > > thank you for the webrev. > > I checked jdk/jdk and you are right, there are differences in the file, > but not regarding this issue. Some of the differences are because the > AArch64 code has been removed from the cpu/arm port in jdk/jdk. In > jdk-updates/jdk11u, the cpu/arm source base also includes an AArch64 port. > The patch looks good to me. > > I did not create a test case for this issue, because I don't know if one > is able to check if the template interpreter calls the interpreter runtime > or not. > Resolving this issue makes the template interpreter faster, because it > does not call the interpreter runtime (using the condy_helper function), > but is able to load in the constant in the generated code. A simple test > case (which I used and checked using a debugger, back when I patched our > source base) is something like the following (It is not the test I used, > but should work as well): > > class Test { > public static void main(String... args) { > long x = 12345678910L; > } > } > > Also, since the Rtemp is not initialized in the code generated by this > template, it could be, that the path for loading a long constant is used, > even if the type is of double, but I don't know if this is only a > theoretical bug or if it might appear in practice as well. I never saw it > happening. > > Yes, there is an OCA signed for MicroDoc Software GmbH. > > Thanks, Christoph > > Boris Ulasevich wrote on 2019-08-09 > 13:49:00: > >> From: Boris Ulasevich >> To: christoph.goettschkes at microdoc.com >> Cc: hotspot-dev at openjdk.java.net >> Date: 2019-08-09 13:49 >> Subject: Re: Advice on how to push changes back for ARMv7-A softfp > platforms >> >> Hi Christoph, >> >> I can create webrev for you. Please note that we should not directly >> patch jdk11u. We should push the fix to jdk-jdk, and then backport the >> change to jdk11u. Your patch is not applied cleanly to the upstream >> because of a minor change around exit label. I think for jdk-jdk the >> change can be like this: >> http://cr.openjdk.java.net/~bulasevich/8229352/webrev.00 >> >> A good practice for review is to add a test to reproduce the problem. >> >> Did your company (or you personally) signed OCA? >> >> thanks, >> Boris >> > From matthias.baesken at sap.com Fri Aug 9 13:56:58 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 9 Aug 2019 13:56:58 +0000 Subject: RFR : [XS] 8219082 : jdk/jfr/event/runtime/TestShutdownEvent.java failed in validateStackTrace() Message-ID: Hello, please review this small test adjustment . The TestShutdownEvent.java JFR test fails now and then in the sub-test "TestVMCrash" . Error is in the stack validation , it finds sometimes a stack with no frames . at jdk.jfr.event.runtime.TestShutdownEvent.validateStackTrace(TestShutdownEvent.java:128) at jdk.jfr.event.runtime.TestShutdownEvent$TestVMCrash.verifyEvents(TestShutdownEvent.java:172) Our conclusion so far is that it is currently not 100% reliable to get a stack trace in this case using vframeStream in jfrStackTraceRepository.cpp (forced crash with Unsafe + event generation using EventShutdown late in VMError.cpp ) . Reason is that we might get compiled frames on the stack and then the vframeStream - based solution does not work ( when running with -Xcomp it always fails). See also the comments of our JIT expert Martin in the bug : "JfrStackTrace uses vframeStream to retrieve the stack frames. This works fine if a native frame is on top (because we have the last Java frame linked in the JavaThread object). That's why the tests works when executed with -Xint. The crashing method is native in this case. The situation is different when there's a compiled frame on top. JIT compilers usually inline Unsafe accesses as instrinsics. So the crashing instruction is just in the middle of a compiled method. The vframeStream API would require a PC for which additional information is available (see CodeEmitInfo for C1 or JVMState for C2). That's not the case for an illegal Unsafe access which simply yields undefined behavior. Vframes are not supported in this case so the stack trace is empty. It is possible to get a native stack trace (see VMError::print_native_stack which doesn't use vframes) for hs_err files. Compiled frames are only shown as single frames even if multiple Java frames are included due to inlining. Note that the test always fails when using -Xcomp. So it doesn't make any sense to expect a non-empty vframe based stack trace when a compiled frame is on top. " My first idea was to run the test with -Xint but its probably not such a good idea ; so better for now remove the unreliable check ( + add a comment ). Thanks, Matthias Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8219082 http://cr.openjdk.java.net/~mbaesken/webrevs/8219082.1/ From christoph.goettschkes at microdoc.com Fri Aug 9 14:05:21 2019 From: christoph.goettschkes at microdoc.com (christoph.goettschkes at microdoc.com) Date: Fri, 9 Aug 2019 16:05:21 +0200 Subject: Advice on how to push changes back for ARMv7-A softfp platforms In-Reply-To: References: <20190809100656.E5593308169@aojmv0009> <20190809140536.5ZjSsbrc@mxfront2o.mail.yandex.net> <6ef8da8c-64bd-d2b5-8a16-2c4d50510c38@bell-sw.com> <20190809155127.pRUO0wtp@mxfront8o.mail.yandex.net> Message-ID: Hi Boris, No, I did not run JTreg, the OpenJDK 11 is not completely ported to the target platform. Since it is a linux based system which does not use the glibc, but a different libc implementation, we only have a subset of the java modules ported to the target system. We used the OpenJDK JCK to verify the compliance of the created Java runtime. Since not all modules have been ported, we only tested the following modules: - java.base - java.logging - java.naming In addition, we executed the "vm" and "lang" test. The JCK went fine (all for the OpenJDK 11 code base). Since JTreg requires more modules to be ported, I might need make the port more complete. Are there any requirements of which parts of the jtreg test suite needs to be passed on the target platform? Porting all java modules might be a major task and we might not want to do that, since the change is inside HotSpot and we already verified the VM using the JCK. How should I proceed with getting the change reviewed someone. Just keep this conversation open, or should I post an additional message with the bug ID and the webrev link and ask for a review? Thanks, Christoph Boris Ulasevich wrote on 2019-08-09 15:50:34: > From: Boris Ulasevich > To: christoph.goettschkes at microdoc.com > Cc: hotspot-dev at openjdk.java.net > Date: 2019-08-09 15:50 > Subject: Re: Advice on how to push changes back for ARMv7-A softfp platforms > > Hi Christoph, > > I see. I do not know how to write test for the issue too. By the way, > current implementation can (1) make unnecessary call to interpreter > runtime and (2) can make wrong load when Rtemp is equal to > JVM_CONSTANT_Long by chance. So the change is critical for arm32-sflt. > > Did you run jtreg tests? > > Please proceed with review. I can update webrev and bug report and > help you with pushing the change when it is accepted (I am not a reviewer). > > regards, > Boris > > On 09.08.2019 15:49, christoph.goettschkes at microdoc.com wrote: > > Hi Boris, > > > > thank you for the webrev. > > > > I checked jdk/jdk and you are right, there are differences in the file, > > but not regarding this issue. Some of the differences are because the > > AArch64 code has been removed from the cpu/arm port in jdk/jdk. In > > jdk-updates/jdk11u, the cpu/arm source base also includes an AArch64 port. > > The patch looks good to me. > > > > I did not create a test case for this issue, because I don't know if one > > is able to check if the template interpreter calls the interpreter runtime > > or not. > > Resolving this issue makes the template interpreter faster, because it > > does not call the interpreter runtime (using the condy_helper function), > > but is able to load in the constant in the generated code. A simple test > > case (which I used and checked using a debugger, back when I patched our > > source base) is something like the following (It is not the test I used, > > but should work as well): > > > > class Test { > > public static void main(String... args) { > > long x = 12345678910L; > > } > > } > > > > Also, since the Rtemp is not initialized in the code generated by this > > template, it could be, that the path for loading a long constant is used, > > even if the type is of double, but I don't know if this is only a > > theoretical bug or if it might appear in practice as well. I never saw it > > happening. > > > > Yes, there is an OCA signed for MicroDoc Software GmbH. > > > > Thanks, Christoph > > > > Boris Ulasevich wrote on 2019-08-09 > > 13:49:00: > > > >> From: Boris Ulasevich > >> To: christoph.goettschkes at microdoc.com > >> Cc: hotspot-dev at openjdk.java.net > >> Date: 2019-08-09 13:49 > >> Subject: Re: Advice on how to push changes back for ARMv7-A softfp > > platforms > >> > >> Hi Christoph, > >> > >> I can create webrev for you. Please note that we should not directly > >> patch jdk11u. We should push the fix to jdk-jdk, and then backport the > >> change to jdk11u. Your patch is not applied cleanly to the upstream > >> because of a minor change around exit label. I think for jdk-jdk the > >> change can be like this: > >> http://cr.openjdk.java.net/~bulasevich/8229352/webrev.00 > >> > >> A good practice for review is to add a test to reproduce the problem. > >> > >> Did your company (or you personally) signed OCA? > >> > >> thanks, > >> Boris > >> > > > From boris.ulasevich at bell-sw.com Fri Aug 9 14:42:04 2019 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Fri, 9 Aug 2019 17:42:04 +0300 Subject: Advice on how to push changes back for ARMv7-A softfp platforms In-Reply-To: <20190809170657.6v3Wxhvl@mxfront13g.mail.yandex.net> References: <20190809100656.E5593308169@aojmv0009> <20190809140536.5ZjSsbrc@mxfront2o.mail.yandex.net> <6ef8da8c-64bd-d2b5-8a16-2c4d50510c38@bell-sw.com> <20190809155127.pRUO0wtp@mxfront8o.mail.yandex.net> <20190809170657.6v3Wxhvl@mxfront13g.mail.yandex.net> Message-ID: <5f12a99b-acd8-c970-7e48-c0a56b1fb136@bell-sw.com> Hi Christoph, Ok. I think you can use jtreg at least for regression testing. No need to pass it all, just check that your change does not make new fails. I would proceed with your first mail replying to it with usual Subject (RFR: 8229352: Use of an uninitialised register in 32-bit ARM template interpreter) and content including links to webrev and bugdb and description. thanks, Boris On 09.08.2019 17:05, christoph.goettschkes at microdoc.com wrote: > Hi Boris, > > No, I did not run JTreg, the OpenJDK 11 is not completely ported to the > target platform. Since it is a linux based system which does not use the > glibc, but a different libc implementation, we only have a subset of the > java modules ported to the target system. We used the OpenJDK JCK to > verify the compliance of the created Java runtime. Since not all modules > have been ported, we only tested the following modules: > > - java.base > - java.logging > - java.naming > > In addition, we executed the "vm" and "lang" test. The JCK went fine (all > for the OpenJDK 11 code base). Since JTreg requires more modules to be > ported, I might need make the port more complete. Are there any > requirements of which parts of the jtreg test suite needs to be passed on > the target platform? Porting all java modules might be a major task and we > might not want to do that, since the change is inside HotSpot and we > already verified the VM using the JCK. > > How should I proceed with getting the change reviewed someone. Just keep > this conversation open, or should I post an additional message with the > bug ID and the webrev link and ask for a review? > > Thanks, > Christoph > > Boris Ulasevich wrote on 2019-08-09 > 15:50:34: > >> From: Boris Ulasevich >> To: christoph.goettschkes at microdoc.com >> Cc: hotspot-dev at openjdk.java.net >> Date: 2019-08-09 15:50 >> Subject: Re: Advice on how to push changes back for ARMv7-A softfp > platforms >> >> Hi Christoph, >> >> I see. I do not know how to write test for the issue too. By the way, > >> current implementation can (1) make unnecessary call to interpreter >> runtime and (2) can make wrong load when Rtemp is equal to >> JVM_CONSTANT_Long by chance. So the change is critical for arm32-sflt. >> >> Did you run jtreg tests? >> >> Please proceed with review. I can update webrev and bug report and >> help you with pushing the change when it is accepted (I am not a > reviewer). >> >> regards, >> Boris >> >> On 09.08.2019 15:49, christoph.goettschkes at microdoc.com wrote: >>> Hi Boris, >>> >>> thank you for the webrev. >>> >>> I checked jdk/jdk and you are right, there are differences in the > file, >>> but not regarding this issue. Some of the differences are because the >>> AArch64 code has been removed from the cpu/arm port in jdk/jdk. In >>> jdk-updates/jdk11u, the cpu/arm source base also includes an AArch64 > port. >>> The patch looks good to me. >>> >>> I did not create a test case for this issue, because I don't know if > one >>> is able to check if the template interpreter calls the interpreter > runtime >>> or not. >>> Resolving this issue makes the template interpreter faster, because it >>> does not call the interpreter runtime (using the condy_helper > function), >>> but is able to load in the constant in the generated code. A simple > test >>> case (which I used and checked using a debugger, back when I patched > our >>> source base) is something like the following (It is not the test I > used, >>> but should work as well): >>> >>> class Test { >>> public static void main(String... args) { >>> long x = 12345678910L; >>> } >>> } >>> >>> Also, since the Rtemp is not initialized in the code generated by this >>> template, it could be, that the path for loading a long constant is > used, >>> even if the type is of double, but I don't know if this is only a >>> theoretical bug or if it might appear in practice as well. I never saw > it >>> happening. >>> >>> Yes, there is an OCA signed for MicroDoc Software GmbH. >>> >>> Thanks, Christoph >>> >>> Boris Ulasevich wrote on 2019-08-09 >>> 13:49:00: >>> >>>> From: Boris Ulasevich >>>> To: christoph.goettschkes at microdoc.com >>>> Cc: hotspot-dev at openjdk.java.net >>>> Date: 2019-08-09 13:49 >>>> Subject: Re: Advice on how to push changes back for ARMv7-A softfp >>> platforms >>>> >>>> Hi Christoph, >>>> >>>> I can create webrev for you. Please note that we should not directly >>>> patch jdk11u. We should push the fix to jdk-jdk, and then backport > the >>>> change to jdk11u. Your patch is not applied cleanly to the upstream >>>> because of a minor change around exit label. I think for jdk-jdk the >>>> change can be like this: >>>> http://cr.openjdk.java.net/~bulasevich/8229352/webrev.00 >>>> >>>> A good practice for review is to add a test to reproduce the problem. >>>> >>>> Did your company (or you personally) signed OCA? >>>> >>>> thanks, >>>> Boris >>>> >>> >> > From adam.farley at uk.ibm.com Fri Aug 9 16:47:13 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Fri, 9 Aug 2019 17:47:13 +0100 Subject: RFR: JDK-8227021: VM fails if any sun.boot.library.path paths are longer than JVM_MAXPATHLEN In-Reply-To: <025da83a-6569-f6ac-7590-5b200ed2344f@oracle.com> References: <25234969-2215-57e9-d8c5-d97b5669ebb1@oracle.com> <5ba808b0-ae52-0d0a-b84b-fc34df35475d@oracle.com> <025da83a-6569-f6ac-7590-5b200ed2344f@oracle.com> Message-ID: Hi Serguei, David, My turn to apologise for the delay. :) I've modified the code as per Serguei's request. Take a look and let me know if this is the sort of thing you were thinking of. Webrev: http://cr.openjdk.java.net/~afarley/8227021.3/webrev/ Best Regards Adam Farley IBM Runtimes "serguei.spitsyn at oracle.com" wrote on 31/07/2019 17:18:05: > From: "serguei.spitsyn at oracle.com" > To: Adam Farley8 , David Holmes > > Cc: serviceability-dev , > hotspot-dev at openjdk.java.net > Date: 31/07/2019 17:18 > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > paths are longer than JVM_MAXPATHLEN > > Hi Adam, > > It looks Okay to me. > > A couple of minor comments. > > http://cr.openjdk.java.net/~afarley/8227021.2/webrev/src/hotspot/ > share/runtime/os.cpp.frames.html > 1362 //release allocated storage before exiting the vm > 1363 while (i > 0) { > 1364 i--; > 1365 if (opath[i] != NULL) { > 1366 FREE_C_HEAP_ARRAY(char, opath[i]); > 1367 } > 1368 } > 1369 FREE_C_HEAP_ARRAY(char*, opath); > > 1377 //release allocated storage before returning null > 1378 while (i > 0) { > 1379 i--; > 1380 if (opath[i] != NULL) { > 1381 FREE_C_HEAP_ARRAY(char, opath[i]); > 1382 } > 1383 } > 1384 FREE_C_HEAP_ARRAY(char*, opath); > > This duplicated fragments is worth to refactor to a function. > Also a space is missed at the beginning of the comment. > > > Thanks, > Serguei > > > > On 7/31/19 02:01, Adam Farley8 wrote: > Hi All, > > Reviewers requested for the change below. > > @David - Agreed. Would you be prepared to sponsor the change? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8227021 > Webrev: http://cr.openjdk.java.net/~afarley/8227021.2/webrev/ > > Best Regards > > Adam Farley > IBM Runtimes > > P.S. Remembered to add the links this time. :) > > > David Holmes wrote on 30/07/2019 03:37:53: > > > From: David Holmes > > To: Adam Farley8 > > Cc: hotspot-dev at openjdk.java.net, serviceability-dev > > > > Date: 30/07/2019 03:38 > > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > > paths are longer than JVM_MAXPATHLEN > > > > Hi Adam, > > > > On 25/07/2019 3:57 am, Adam Farley8 wrote: > > > Hi David, > > > > > > Welcome back. :) > > > > Thanks. Sorry for the delay in getting back to this. > > > > I like .v2 as it is much simpler (notwithstanding freeing the already > > allocated arrays adds some complexity - thanks for fixing that). > > > > I'm still not sure we can't optimise things better for unchangeable > > properties like the boot libary path, but that's another RFE. > > > > Thanks, > > David > > > 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 serguei.spitsyn at oracle.com Fri Aug 9 19:22:29 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 9 Aug 2019 12:22:29 -0700 Subject: RFR: JDK-8227021: VM fails if any sun.boot.library.path paths are longer than JVM_MAXPATHLEN In-Reply-To: References: <25234969-2215-57e9-d8c5-d97b5669ebb1@oracle.com> <5ba808b0-ae52-0d0a-b84b-fc34df35475d@oracle.com> <025da83a-6569-f6ac-7590-5b200ed2344f@oracle.com> Message-ID: <3c77633f-46f8-0522-26ba-98d28835d503@oracle.com> Hi Adam, It looks good. Thank you for the update! Thanks, Serguei On 8/9/19 9:47 AM, Adam Farley8 wrote: > Hi Serguei, David, > > My turn to apologise for the delay. :) > > I've modified the code as per Serguei's request. Take a look and let > me know if this is the sort of thing you were thinking of. > > Webrev: http://cr.openjdk.java.net/~afarley/8227021.3/webrev/ > > > Best Regards > > Adam Farley > IBM Runtimes > > > "serguei.spitsyn at oracle.com" wrote on > 31/07/2019 17:18:05: > > > From: "serguei.spitsyn at oracle.com" > > To: Adam Farley8 , David Holmes > > > > Cc: serviceability-dev , > > hotspot-dev at openjdk.java.net > > Date: 31/07/2019 17:18 > > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > > paths are longer than JVM_MAXPATHLEN > > > > Hi Adam, > > > > It looks Okay to me. > > > > A couple of minor comments. > > > > http://cr.openjdk.java.net/~afarley/8227021.2/webrev/src/hotspot/ > > > share/runtime/os.cpp.frames.html > > > 1362 ? ? ? //release allocated storage before exiting the vm > > 1363 ? ? ? while (i > 0) { > > 1364 ? ? ? ? ? i--; > > 1365 ? ? ? ? ? if (opath[i] != NULL) { > > 1366 ? ? ? ? ? ? FREE_C_HEAP_ARRAY(char, opath[i]); > > 1367 ? ? ? ? ? } > > 1368 ? ? ? } > > 1369 ? ? ? FREE_C_HEAP_ARRAY(char*, opath); > > > > 1377 ? ? ? //release allocated storage before returning null > > 1378 ? ? ? while (i > 0) { > > 1379 ? ? ? ? ? i--; > > 1380 ? ? ? ? ? if (opath[i] != NULL) { > > 1381 ? ? ? ? ? ? FREE_C_HEAP_ARRAY(char, opath[i]); > > 1382 ? ? ? ? ? } > > 1383 ? ? ? } > > 1384 ? ? ? FREE_C_HEAP_ARRAY(char*, opath); > > > > This duplicated fragments is worth to refactor to a function. > > Also a space is missed at the beginning of the comment. > > > > > > Thanks, > > Serguei > > > > > > > > On 7/31/19 02:01, Adam Farley8 wrote: > > Hi All, > > > > Reviewers requested for the change below. > > > > @David - Agreed. Would you be prepared to sponsor the change? > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8227021 > > Webrev: http://cr.openjdk.java.net/~afarley/8227021.2/webrev/ > > > > > Best Regards > > > > Adam Farley > > IBM Runtimes > > > > P.S. Remembered to add the links this time. :) > > > > > > David Holmes wrote on 30/07/2019 03:37:53: > > > > > From: David Holmes > > > To: Adam Farley8 > > > Cc: hotspot-dev at openjdk.java.net, serviceability-dev > > > > > > Date: 30/07/2019 03:38 > > > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > > > paths are longer than JVM_MAXPATHLEN > > > > > > Hi Adam, > > > > > > On 25/07/2019 3:57 am, Adam Farley8 wrote: > > > > Hi David, > > > > > > > > Welcome back. :) > > > > > > Thanks. Sorry for the delay in getting back to this. > > > > > > I like .v2 as it is much simpler (notwithstanding freeing the already > > > allocated arrays adds some complexity - thanks for fixing that). > > > > > > I'm still not sure we can't optimise things better for unchangeable > > > properties like the boot libary path, but that's another RFE. > > > > > > Thanks, > > > David > > > > > 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 mikhailo.seledtsov at oracle.com Fri Aug 9 21:00:44 2019 From: mikhailo.seledtsov at oracle.com (mikhailo.seledtsov at oracle.com) Date: Fri, 9 Aug 2019 14:00:44 -0700 Subject: RFR : [XS] 8219082 : jdk/jfr/event/runtime/TestShutdownEvent.java failed in validateStackTrace() In-Reply-To: References: Message-ID: Looks good to me, Thank you, Misha On 8/9/19 6:56 AM, Baesken, Matthias wrote: > > Hello, please review this small? test adjustment . > > The TestShutdownEvent.java? JFR test? fails now and then? in the? > sub-test?? ?TestVMCrash? . > > Error? is in the stack validation , it ?finds sometimes a stack with > no frames . > > at > jdk.jfr.event.runtime.TestShutdownEvent.validateStackTrace(TestShutdownEvent.java:128) > > at > jdk.jfr.event.runtime.TestShutdownEvent$TestVMCrash.verifyEvents(TestShutdownEvent.java:172) > > > Our conclusion so far is that it is currently not 100% reliable to get > a stack trace in this case using vframeStream in > jfrStackTraceRepository.cpp > > (forced crash with Unsafe + event generation using EventShutdown late > in VMError.cpp ) . > Reason is that? we might? get? compiled frames? on the stack? and?? > then? the? vframeStream ? based ?solution ?does not work?? ( when? > running with -Xcomp? it always fails). > > See also? the comments of our JIT expert Martin? in the? bug : > > ?JfrStackTrace uses vframeStream to retrieve the stack frames. > This works fine if a native frame is on top (because we have the last > Java frame linked in the JavaThread object). > That's why the tests works when executed with -Xint. The crashing > method is native in this case. > > The situation is different when there's a compiled frame on top. > JIT compilers usually inline Unsafe accesses as instrinsics. So the > crashing instruction is just in the middle of a compiled method. > The vframeStream API would require a PC for which additional > information is available (see CodeEmitInfo for C1 or JVMState for C2). > That's not the case for an illegal Unsafe access which simply yields > undefined behavior. Vframes are not supported in this case so the > stack trace is empty. > > It is possible to get a native stack trace (see > VMError::print_native_stack which doesn't use vframes) for hs_err > files. Compiled frames are only shown as single > > frames even if multiple Java frames are included due to inlining. > > Note that the test always fails when using -Xcomp. So it doesn't make > any sense to expect a non-empty vframe based stack trace when a > compiled frame is on top.?? > > My first idea?? was to run the? test? with -Xint? but its probably not > such a good idea ; so better? for now? ?remove ?the? unreliable check > ?(? + add a comment ). > > Thanks, Matthias > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8219082 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8219082.1/ > From mikhailo.seledtsov at oracle.com Fri Aug 9 21:09:17 2019 From: mikhailo.seledtsov at oracle.com (mikhailo.seledtsov at oracle.com) Date: Fri, 9 Aug 2019 14:09:17 -0700 Subject: RFR : [XS] 8219082 : jdk/jfr/event/runtime/TestShutdownEvent.java failed in validateStackTrace() In-Reply-To: References: Message-ID: <4d2d96f9-7f4b-dcfc-4e0d-3903fd8374da@oracle.com> Also, adding jfr-dev list. On 8/9/19 2:00 PM, mikhailo.seledtsov at oracle.com wrote: > Looks good to me, > > Thank you, > > Misha > > On 8/9/19 6:56 AM, Baesken, Matthias wrote: >> >> Hello, please review this small? test adjustment . >> >> The TestShutdownEvent.java? JFR test? fails now and then? in the? >> sub-test?? ?TestVMCrash? . >> >> Error? is in the stack validation , it ?finds sometimes a stack with >> no frames . >> >> at >> jdk.jfr.event.runtime.TestShutdownEvent.validateStackTrace(TestShutdownEvent.java:128) >> >> at >> jdk.jfr.event.runtime.TestShutdownEvent$TestVMCrash.verifyEvents(TestShutdownEvent.java:172) >> >> >> Our conclusion so far is that it is currently not 100% reliable to >> get a stack trace in this case using vframeStream in >> jfrStackTraceRepository.cpp >> >> (forced crash with Unsafe + event generation using EventShutdown late >> in VMError.cpp ) . >> Reason is that? we might? get? compiled frames? on the stack and?? >> then? the? vframeStream ? based ?solution ?does not work ( when? >> running with -Xcomp? it always fails). >> >> See also? the comments of our JIT expert Martin? in the? bug : >> >> ?JfrStackTrace uses vframeStream to retrieve the stack frames. >> This works fine if a native frame is on top (because we have the last >> Java frame linked in the JavaThread object). >> That's why the tests works when executed with -Xint. The crashing >> method is native in this case. >> >> The situation is different when there's a compiled frame on top. >> JIT compilers usually inline Unsafe accesses as instrinsics. So the >> crashing instruction is just in the middle of a compiled method. >> The vframeStream API would require a PC for which additional >> information is available (see CodeEmitInfo for C1 or JVMState for C2). >> That's not the case for an illegal Unsafe access which simply yields >> undefined behavior. Vframes are not supported in this case so the >> stack trace is empty. >> >> It is possible to get a native stack trace (see >> VMError::print_native_stack which doesn't use vframes) for hs_err >> files. Compiled frames are only shown as single >> >> frames even if multiple Java frames are included due to inlining. >> >> Note that the test always fails when using -Xcomp. So it doesn't make >> any sense to expect a non-empty vframe based stack trace when a >> compiled frame is on top.?? >> >> My first idea?? was to run the? test? with -Xint? but its probably >> not such a good idea ; so better? for now? ?remove ?the? unreliable >> check ?(? + add a comment ). >> >> Thanks, Matthias >> >> Bug/webrev : >> >> https://bugs.openjdk.java.net/browse/JDK-8219082 >> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8219082.1/ >> From kim.barrett at oracle.com Fri Aug 9 22:18:36 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 9 Aug 2019 18:18:36 -0400 Subject: RFR: 8227054: ServiceThread needs to know about all OopStorage objects In-Reply-To: <164151e7-fec4-8c61-f247-3d5a41c910c1@oracle.com> References: <8181924C-36E6-4B91-9567-150F00286241@oracle.com> <74C738E7-CBDD-4891-ABD6-F8E023372508@oracle.com> <60099477-9AD4-4EFC-AA6F-6EF19D840E67@oracle.com> <164151e7-fec4-8c61-f247-3d5a41c910c1@oracle.com> Message-ID: > On Aug 5, 2019, at 9:48 AM, Erik ?sterlund wrote: > > Hi Coleen, > > On 2019-08-05 15:23, coleen.phillimore at oracle.com wrote: >> I look forward to seeing Kim's next version. > > Me too! Here is a new revision, taking into account the feedback that fewer macros (and in particular no x-macros) would be appreciated. OopStorageSet (was OopStorages) now uses an internal enum (no longer public) to define indexes and ranges of indexes into the global array of OopStorage objects. WeakProcessorPhases no longer has named enumerators for OopStorage phases, though the range of values is still allocated. Various other changes in WeakProcessor and friends to account for and make use of OopStorageSet. I've also taken Erik's suggestion of using iterator objects to package up the iteration, rather than using FOR_EACH_xxx macros. That also got applied to the WeakProcessorPhases. For extra credit (or perhaps a bridge too far), the new iterators provide begin/end functions, so they support range-based-for as soon as it becomes available, allowing some syntactic improvements. Webrev (no incremental, the changes from the previous version are pretty substantial and not really worth comparing): http://cr.openjdk.java.net/~kbarrett/8227054/open.02/ Testing: mach5 tier1-3 From dean.long at oracle.com Fri Aug 9 22:18:49 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 9 Aug 2019 15:18:49 -0700 Subject: RFR (S): 8228857: Refactor PlatformMonitor into PlatformMutex and PlatformMonitor In-Reply-To: <9c8ea98c-a2cd-a832-d977-678a4de379b1@oracle.com> References: <32C9F58D-FA84-4A18-9A43-86DE2F8AD88E@oracle.com> <85649d80-f85e-4da0-dd4c-db148b33d5e8@oracle.com> <9c8ea98c-a2cd-a832-d977-678a4de379b1@oracle.com> Message-ID: <83bd67b3-f301-62d7-f94f-ef4c00b83c9d@oracle.com> Did you set PLATFORM_MONITOR_IMPL_INDIRECT to 1 for debugging non-apple builds and forgot to revert it? dl On 8/8/19 11:25 PM, David Holmes wrote: > Okay here is v2 with Kim's non-copyable adjustments and an alternate > approach to the "impl" class so that the PlatformMutex doesn't have to > pay for the unused pthread_cond_t. Trade-off in this scheme is that > PlatformMonitor now has two "impl" pointers so consumes more space. > > Also made comment changes suggested by Dan. > > http://cr.openjdk.java.net/~dholmes/8228857/webrev.v2/ > > Thanks, > David > ----- From kim.barrett at oracle.com Fri Aug 9 22:50:11 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 9 Aug 2019 18:50:11 -0400 Subject: RFR: 8227054: ServiceThread needs to know about all OopStorage objects In-Reply-To: References: <8181924C-36E6-4B91-9567-150F00286241@oracle.com> <74C738E7-CBDD-4891-ABD6-F8E023372508@oracle.com> <60099477-9AD4-4EFC-AA6F-6EF19D840E67@oracle.com> Message-ID: <1750F48C-F378-4254-945F-2F2A42085FF2@oracle.com> > On Aug 5, 2019, at 3:33 AM, Erik ?sterlund wrote: > > Hi Kim, > > On 2019-08-05 04:35, Kim Barrett wrote: > > This conversation whether we should or should not care about the aliasing rules has been repeated many times. And the answer is always the same: we should not care about aliasing rules. Summary of why: > > * HotSpot inherently can't comply to the aliasing rules, as those rules are only defined in terms of C++ accesses interacting with each other. Since we JIT code performing accesses on the same memory as the C++ code, the aliasing rules can inherently never be trusted, as our interactions cross language barriers. > * Compilers used to compile HotSpot have all been told to ignore aliasing rules, and hence the behaviour of doing so is well defined. Because it has to be. If a compiler can't ignore aliasing, it can't compile HotSpot. > * Even if we were not inherently tied to ignore these aliasing rules, a significantly large part of HotSpot relies on it, and we can't realistically get rid of that reliance to turn the flags off. At least not by taking huge risk that we think we caught all the places, which would be rather irresponsible. > * Even if we could magically get rid of this reliance and somehow rewrite all code to conform with the aliasing rules, verify that we solved it all, and switch the compiler flags ignoring aliasing off, which would be a crazy amount of work, and be very risky, the benefits are seemingly unclear. They were introduced to allow compiler optimizations. I have not seen studies with numbers showing that it improves things. I have heard vague statements that it does, but not with numbers. I have found one study - a paper from Purdue where they had run with and without -fstrict-aliasing on a number of benchmarks, and observed no benefit. And most our time is spent in JIT:ed code, so I would expect even less if anything. > * Given the above, HotSpot does not, can not, and never will care about aliasing. They doe not make sense in our context, and the rules simply don't apply. Therefore, we can and should ignore the aliasing rules. Caring about them "sometimes" makes no sense to me. That's why I say I don't mind violating the aliasing rules, because they simply don't apply to HotSpot. Those arguments are the rationale we use for breaking the rules at all. But they aren't good reasons for breaking the rules casually. reinterpret_cast (however spelled) takes a big hammer to the type system. It should only be used when there aren't other options. Besides ignoring aliasing rules, it can have other knock-on effects and generally makes review and later maintenance more difficult. You feel haranged in Italian when you see macros. When I see a reinterpret_cast I hear furtive incantations in the language of R'lyeh, and fear for my sanity! >>>> And an iterator whose initial "current" is invalid? You think >>>> *macros* are confusing? >>> >>> That?s Java style iterators I guess. You call next until you can?t. Before you called next the first time, there is no current element that has been handed out. I don?t mind changing the iterator style though if you think that is confusing. It is my preferred style for simple linear iteration. >> In this case that idiom seems like it expends additional effort to >> potentially hide bugs. > > I don't know what you mean by that. That form of iterator does the range check in the iterator to decide whether to dereference or return NULL. The caller must then check for NULL, even though it's a postcondition that if the range check passed then the value is never NULL (because it's a precondition that all the OopStorage* slots have been filled in, else iteration could face early termination unexpectedly, which would be a bug). But we have no way to communicate those pre/postconditions to the compiler, so the NULL check must dutifully be done on the dereference case, even though it's a complete waste and could hide a bug of using it too soon. >> It also seems less convenient to use, though if one uses implicit >> booleans (as the proposed code does), that disadvantage is nullified. >> (I've had many occasions to want to use the declaration form of a >> condition, but haven't because there were strong complaints when I >> first tried doing so, and I've since seen it objected to when others >> tried. But I found some recently added, so maybe that's no longer >> true? Or maybe the previous complainers didn't notice.) > > Yeah this style is indeed only nice when using the declaration form of a condition. If anyone thinks that should not be allowed for some reason, I don't have strong opinions about having a different iterator style. As I said, I like the feature, but it *is* a violation of the no-implicit-bools style guide rule, and there were definite opinions expressed the one time I attempted to use it. From kim.barrett at oracle.com Fri Aug 9 22:57:03 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 9 Aug 2019 18:57:03 -0400 Subject: RFR: 8227054: ServiceThread needs to know about all OopStorage objects In-Reply-To: References: <8181924C-36E6-4B91-9567-150F00286241@oracle.com> <74C738E7-CBDD-4891-ABD6-F8E023372508@oracle.com> <60099477-9AD4-4EFC-AA6F-6EF19D840E67@oracle.com> <164151e7-fec4-8c61-f247-3d5a41c910c1@oracle.com> Message-ID: <79F4B73B-B161-4197-A9A7-FD1B6B741A5F@oracle.com> > On Aug 9, 2019, at 6:18 PM, Kim Barrett wrote: > > Webrev (no incremental, the changes from the previous version are > pretty substantial and not really worth comparing): > http://cr.openjdk.java.net/~kbarrett/8227054/open.02/ I forgot to do the Shenandoah updates for this. I?ll post those later. From erik.osterlund at oracle.com Sat Aug 10 07:52:33 2019 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Sat, 10 Aug 2019 09:52:33 +0200 Subject: RFR: 8227054: ServiceThread needs to know about all OopStorage objects In-Reply-To: References: <8181924C-36E6-4B91-9567-150F00286241@oracle.com> <74C738E7-CBDD-4891-ABD6-F8E023372508@oracle.com> <60099477-9AD4-4EFC-AA6F-6EF19D840E67@oracle.com> <164151e7-fec4-8c61-f247-3d5a41c910c1@oracle.com> Message-ID: <96EE9BB8-9EE5-4FBB-B266-785C563BFC2E@oracle.com> Hi Kim, Thank you for taking this for another spin. I like the new version a lot better. I think you convinced me on using the private enum being a better idea than my reinterpret_cast. I only have two questions left: 1) How would you feel about not using the macro for generating the getters? It looks like 1 short line for the getter vs 1 short line for the macro. In other words, not much typing is saved using the X macro here. But it will confuse IDEs. So I would have preferred the explicit getters. 2) Similar thought for the initialization of OopStorages where the name is generated from the macro. I thought the name was meant to be in more human readable form as we print them out in logs. So again, I would have loved explicit initialization, which is still just 1 trivial line per OopStorage. If you have strong opinions about keeping those macros, I will not oppose it. But maybe you agree that retaining that IDE awareness of the code and nice printouts in the logs is worth doing those one liners without X macros? Apart from those two things, I really liked the approach! Thanks, /Erik On 10 Aug 2019, at 00:18, Kim Barrett wrote: >> On Aug 5, 2019, at 9:48 AM, Erik ?sterlund wrote: >> >> Hi Coleen, >> >>> On 2019-08-05 15:23, coleen.phillimore at oracle.com wrote: >>> I look forward to seeing Kim's next version. >> >> Me too! > > Here is a new revision, taking into account the feedback that fewer > macros (and in particular no x-macros) would be appreciated. > > OopStorageSet (was OopStorages) now uses an internal enum (no longer > public) to define indexes and ranges of indexes into the global array > of OopStorage objects. > > WeakProcessorPhases no longer has named enumerators for OopStorage > phases, though the range of values is still allocated. Various other > changes in WeakProcessor and friends to account for and make use of > OopStorageSet. > > I've also taken Erik's suggestion of using iterator objects to package > up the iteration, rather than using FOR_EACH_xxx macros. That also > got applied to the WeakProcessorPhases. > > For extra credit (or perhaps a bridge too far), the new iterators > provide begin/end functions, so they support range-based-for as soon > as it becomes available, allowing some syntactic improvements. > > Webrev (no incremental, the changes from the previous version are > pretty substantial and not really worth comparing): > http://cr.openjdk.java.net/~kbarrett/8227054/open.02/ > > Testing: > mach5 tier1-3 > From christoph.goettschkes at microdoc.com Sun Aug 11 06:54:08 2019 From: christoph.goettschkes at microdoc.com (christoph.goettschkes at microdoc.com) Date: Sun, 11 Aug 2019 08:54:08 +0200 Subject: RFR: 8229352: Use of an unitialized register in 32-bit ARM template interpreter In-Reply-To: <20190716100738.EFA3E2E2022@aojmv0009> References: <20190716100738.EFA3E2E2022@aojmv0009> Message-ID: Hello, could someone please review the changes for https://bugs.openjdk.java.net/browse/JDK-8229352 webrev: http://cr.openjdk.java.net/~bulasevich/8229352/webrev.00/ The template interpreter for 32-bit arm generates code which accesses the uninitialized register Rtemp if the platform is softfp for the ldc2_w bytecode. Because of that, loading a long constant might take the slow path and call into the runtime. In addition, loading a double constant might take the wrong path and not call into the runtime, but load it as if it would be of type long (never seen in real life). I executed the tier1 tests of the hotspot JTreg test group and could not identify any regressions. Some tests were failing because of insufficient memory on the target platform. Thanks, Christoph "hotspot-dev" wrote on 2019-07-16 12:05:59: > From: christoph.goettschkes at microdoc.com > To: hotspot-dev at openjdk.java.net > Date: 2019-07-16 12:08 > Subject: [PATCH] Use of an unitialized register in 32-bit ARM template interpreter > Sent by: "hotspot-dev" > > Hello, > > while working with the OpenJDK 11 on a 32-bit ARMv7-A platform, I noticed > something weird in the template interpreter, regarding the template for > the bytecode instruction ldc2_w. > > The type check for the operand is only done correctly if the ABI is a > hard-float one. For soft-float, the check is done wrong, using an > uninitialized register Rtemp. Please see the following diff: > > diff -r 327d5994b2fb src/hotspot/cpu/arm/templateTable_arm.cpp > --- a/src/hotspot/cpu/arm/templateTable_arm.cpp Tue Mar 12 11:13:39 2019 -0400 > +++ b/src/hotspot/cpu/arm/templateTable_arm.cpp Tue Jul 16 11:22:14 2019 +0200 > @@ -515,36 +515,37 @@ > void TemplateTable::ldc2_w() { > transition(vtos, vtos); > const Register Rtags = R2_tmp; > const Register Rindex = R3_tmp; > const Register Rcpool = R4_tmp; > const Register Rbase = R5_tmp; > > __ get_unsigned_2_byte_index_at_bcp(Rindex, 1); > > __ get_cpool_and_tags(Rcpool, Rtags); > const int base_offset = ConstantPool::header_size() * wordSize; > const int tags_offset = Array::base_offset_in_bytes(); > > __ add(Rbase, Rcpool, AsmOperand(Rindex, lsl, LogBytesPerWord)); > > + // get type from tags > + __ add(Rtemp, Rtags, tags_offset); > + __ ldrb(Rtemp, Address(Rtemp, Rindex)); > + > Label Condy, exit; > #ifdef __ABI_HARD__ > Label Long; > - // get type from tags > - __ add(Rtemp, Rtags, tags_offset); > - __ ldrb(Rtemp, Address(Rtemp, Rindex)); > __ cmp(Rtemp, JVM_CONSTANT_Double); > __ b(Long, ne); > __ ldr_double(D0_tos, Address(Rbase, base_offset)); > > __ push(dtos); > __ b(exit); > __ bind(Long); > #endif > > __ cmp(Rtemp, JVM_CONSTANT_Long); > __ b(Condy, ne); > #ifdef AARCH64 > __ ldr(R0_tos, Address(Rbase, base_offset)); > #else > __ ldr(R0_tos_lo, Address(Rbase, base_offset + 0 * wordSize)); > > If the check for the type of the operand is done correctly, the call to > InterpreterRuntime::resolve_ldc should never happen. Currently, for 32-bit > soft-float arm, InterpreterRuntime::resolve_ldc is called if the operand > for ldc2_w is of type long. > > Also, I find it weird that the "condy_helper" code is genarted for the > ldc2_w bytecode instruction on 32-bit hard-float arm (and also on x86). > Aren't the only two valid types for ldc2_w long and double? > > -- Christoph > From daniel.daugherty at oracle.com Sun Aug 11 12:57:34 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Sun, 11 Aug 2019 08:57:34 -0400 Subject: RFR (S): 8228857: Refactor PlatformMonitor into PlatformMutex and PlatformMonitor In-Reply-To: <9c8ea98c-a2cd-a832-d977-678a4de379b1@oracle.com> References: <32C9F58D-FA84-4A18-9A43-86DE2F8AD88E@oracle.com> <85649d80-f85e-4da0-dd4c-db148b33d5e8@oracle.com> <9c8ea98c-a2cd-a832-d977-678a4de379b1@oracle.com> Message-ID: <9f76aa54-ce08-4fbd-bb63-65a88dc0db0d@oracle.com> On 8/9/19 2:25 AM, David Holmes wrote: > Okay here is v2 with Kim's non-copyable adjustments and an alternate > approach to the "impl" class so that the PlatformMutex doesn't have to > pay for the unused pthread_cond_t. Trade-off in this scheme is that > PlatformMonitor now has two "impl" pointers so consumes more space. > > Also made comment changes suggested by Dan. > > http://cr.openjdk.java.net/~dholmes/8228857/webrev.v2/ src/hotspot/os/posix/os_posix.cpp ??? No comments. src/hotspot/os/posix/os_posix.hpp ??? L237: // former pthread_cond_t, by using a freelist of mutex/condvar pairs. ??????? You aren't allocating pairs anymore right? ??? L239: #ifdef __APPLE__ ??? L240: #define PLATFORM_MONITOR_IMPL_INDIRECT 1 ??? L241: #else ??? L242: #define PLATFORM_MONITOR_IMPL_INDIRECT 1 ??? L243: #endif ??????? Leftover from compile testing on a non Apple platform? ??????? Update: Same comment as Dean. ??? L268: ? PlatformMutex();??????????? // Use freelist allocation of impl. ??????? nit - comment was previously aligned with L271. src/hotspot/os/posix/os_posix.inline.hpp ??? No comments. src/hotspot/os/solaris/os_solaris.cpp ??? No comments. src/hotspot/os/solaris/os_solaris.hpp ??? No comments. src/hotspot/os/windows/os_windows.hpp ??? No comments. src/hotspot/os/windows/os_windows.inline.hpp ??? No comments. Thumbs up. Dan > > Thanks, > David > ----- From david.holmes at oracle.com Sun Aug 11 22:25:24 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 12 Aug 2019 08:25:24 +1000 Subject: RFR (S): 8228857: Refactor PlatformMonitor into PlatformMutex and PlatformMonitor In-Reply-To: <83bd67b3-f301-62d7-f94f-ef4c00b83c9d@oracle.com> References: <32C9F58D-FA84-4A18-9A43-86DE2F8AD88E@oracle.com> <85649d80-f85e-4da0-dd4c-db148b33d5e8@oracle.com> <9c8ea98c-a2cd-a832-d977-678a4de379b1@oracle.com> <83bd67b3-f301-62d7-f94f-ef4c00b83c9d@oracle.com> Message-ID: <844d4a9e-ad76-f9d1-44a2-0be87854c944@oracle.com> On 10/08/2019 8:18 am, dean.long at oracle.com wrote: > Did you set PLATFORM_MONITOR_IMPL_INDIRECT to 1 for debugging non-apple > builds and forgot to revert it? Oops! Yes that was just for testing. David > dl > > On 8/8/19 11:25 PM, David Holmes wrote: >> Okay here is v2 with Kim's non-copyable adjustments and an alternate >> approach to the "impl" class so that the PlatformMutex doesn't have to >> pay for the unused pthread_cond_t. Trade-off in this scheme is that >> PlatformMonitor now has two "impl" pointers so consumes more space. >> >> Also made comment changes suggested by Dan. >> >> http://cr.openjdk.java.net/~dholmes/8228857/webrev.v2/ >> >> Thanks, >> David >> ----- > From david.holmes at oracle.com Sun Aug 11 22:31:11 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 12 Aug 2019 08:31:11 +1000 Subject: RFR (S): 8228857: Refactor PlatformMonitor into PlatformMutex and PlatformMonitor In-Reply-To: <9f76aa54-ce08-4fbd-bb63-65a88dc0db0d@oracle.com> References: <32C9F58D-FA84-4A18-9A43-86DE2F8AD88E@oracle.com> <85649d80-f85e-4da0-dd4c-db148b33d5e8@oracle.com> <9c8ea98c-a2cd-a832-d977-678a4de379b1@oracle.com> <9f76aa54-ce08-4fbd-bb63-65a88dc0db0d@oracle.com> Message-ID: Hi Dan, On 11/08/2019 10:57 pm, Daniel D. Daugherty wrote: > On 8/9/19 2:25 AM, David Holmes wrote: >> Okay here is v2 with Kim's non-copyable adjustments and an alternate >> approach to the "impl" class so that the PlatformMutex doesn't have to >> pay for the unused pthread_cond_t. Trade-off in this scheme is that >> PlatformMonitor now has two "impl" pointers so consumes more space. >> >> Also made comment changes suggested by Dan. >> >> http://cr.openjdk.java.net/~dholmes/8228857/webrev.v2/ > > src/hotspot/os/posix/os_posix.cpp > ??? No comments. > > src/hotspot/os/posix/os_posix.hpp > ??? L237: // former pthread_cond_t, by using a freelist of > mutex/condvar pairs. > ??????? You aren't allocating pairs anymore right? Fixed: // former pthread_cond_t, by using freelists of mutexes and condvars. > ??? L239: #ifdef __APPLE__ > ??? L240: #define PLATFORM_MONITOR_IMPL_INDIRECT 1 > ??? L241: #else > ??? L242: #define PLATFORM_MONITOR_IMPL_INDIRECT 1 > ??? L243: #endif > ??????? Leftover from compile testing on a non Apple platform? > ??????? Update: Same comment as Dean. Fixed. > ??? L268: ? PlatformMutex();??????????? // Use freelist allocation of > impl. > ??????? nit - comment was previously aligned with L271. Fixed. > src/hotspot/os/posix/os_posix.inline.hpp > ??? No comments. > > src/hotspot/os/solaris/os_solaris.cpp > ??? No comments. > > src/hotspot/os/solaris/os_solaris.hpp > ??? No comments. > > src/hotspot/os/windows/os_windows.hpp > ??? No comments. > > src/hotspot/os/windows/os_windows.inline.hpp > ??? No comments. > > Thumbs up. Thanks Dan. Webrev updated in place. David > Dan > > >> >> Thanks, >> David >> ----- > From david.holmes at oracle.com Mon Aug 12 02:47:17 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 12 Aug 2019 12:47:17 +1000 Subject: RFR(S): 8229254: solaris_x64 build fails In-Reply-To: <9a371ec1-e125-4945-521b-90bb2b4c6984@bell-sw.com> References: <9a371ec1-e125-4945-521b-90bb2b4c6984@bell-sw.com> Message-ID: Hi Boris, On 9/08/2019 11:14 pm, Boris Ulasevich wrote: > Hi, > > Please review the following simple change to make solaris_x64 build > compilable. > > Syntax error was brought by JDK-8191278 [1]. The fix is evident. Yes looks good. > Missing constant issue occurred after JDK-8226238 [2]. I copied > workaround for the case of missing EM_AARCH64 constant in system elf.h > header from os_linux.cpp implementation. I'm really not sure why we keep expanding a Solaris specific structure with entries for architectures the OS does not run on ... That aside the fix seems fine - the value is somewhat arbitrary but doesn't conflict with anything AFAICS. Thanks, David ----- > http://cr.openjdk.java.net/~bulasevich/8229254/webrev.00 > http://bugs.openjdk.java.net/browse/JDK-8229254 > > Testing done: tier1,tier2. > > thanks, > Boris > > [1] MappedByteBuffer bulk access memory failures are not handled gracefully > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2019-June/038352.html > [2] Improve error output and fix elf issues in os::dll_load > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2019-June/038597.html From kim.barrett at oracle.com Mon Aug 12 03:26:16 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 11 Aug 2019 23:26:16 -0400 Subject: RFR: 8227054: ServiceThread needs to know about all OopStorage objects In-Reply-To: <96EE9BB8-9EE5-4FBB-B266-785C563BFC2E@oracle.com> References: <8181924C-36E6-4B91-9567-150F00286241@oracle.com> <74C738E7-CBDD-4891-ABD6-F8E023372508@oracle.com> <60099477-9AD4-4EFC-AA6F-6EF19D840E67@oracle.com> <164151e7-fec4-8c61-f247-3d5a41c910c1@oracle.com> <96EE9BB8-9EE5-4FBB-B266-785C563BFC2E@oracle.com> Message-ID: > On Aug 10, 2019, at 3:52 AM, Erik Osterlund wrote: > > Hi Kim, > > Thank you for taking this for another spin. I like the new version a lot better. I think you convinced me on using the private enum being a better idea than my reinterpret_cast. > > I only have two questions left: > > 1) How would you feel about not using the macro for generating the getters? It looks like 1 short line for the getter vs 1 short line for the macro. In other words, not much typing is saved using the X macro here. But it will confuse IDEs. So I would have preferred the explicit getters. > > 2) Similar thought for the initialization of OopStorages where the name is generated from the macro. I thought the name was meant to be in more human readable form as we print them out in logs. So again, I would have loved explicit initialization, which is still just 1 trivial line per OopStorage. > > If you have strong opinions about keeping those macros, I will not oppose it. But maybe you agree that retaining that IDE awareness of the code and nice printouts in the logs is worth doing those one liners without X macros? Just to be clear, there are no x-macros here, just a couple very simple macros. Using x-macros would have reduced those blocks of macro invocations to one-liners. Can you describe the IDE confusion? I can think of lots of potential issues, depending on how smart/not-so-smart a given IDE might be, but I don't know what actual problems you might be worried about. For me, the macros improve readability by emphasizing the parts that are different (the interesting parts) and deemphasizing the parts that are the same (the boring parts). I looked at the logging of OopStorage processing; the use of the stringized identifiers rather than bespoke strings looked fine to me. Indeed, it has the small additional benefit for someone who is a developer that the name exactly matches the associated getter. (Of course, that doesn't matter to a non-developer log user.) > Apart from those two things, I really liked the approach! Thanks. Hopefully we?re approaching a conclusion on this change. From kim.barrett at oracle.com Mon Aug 12 03:43:17 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 11 Aug 2019 23:43:17 -0400 Subject: RFR(S): 8229254: solaris_x64 build fails In-Reply-To: References: <9a371ec1-e125-4945-521b-90bb2b4c6984@bell-sw.com> Message-ID: <3B3BDAA9-A9A1-42DF-A8C1-419D70EBD89C@oracle.com> > On Aug 11, 2019, at 10:47 PM, David Holmes wrote: > > Hi Boris, > > On 9/08/2019 11:14 pm, Boris Ulasevich wrote: >> Hi, >> Please review the following simple change to make solaris_x64 build compilable. >> Syntax error was brought by JDK-8191278 [1]. The fix is evident. > > Yes looks good. Looks good to me too. >> Missing constant issue occurred after JDK-8226238 [2]. I copied workaround for the case of missing EM_AARCH64 constant in system elf.h header from os_linux.cpp implementation. > > I'm really not sure why we keep expanding a Solaris specific structure with entries for architectures the OS does not run on ? I had the same thought, but that?s not the problem at hand. > That aside the fix seems fine - the value is somewhat arbitrary but doesn't conflict with anything AFAICS. Not exactly. This is the ELF instruction set architecture identifier. 183 == 0xB7 - see for example https://en.wikipedia.org/wiki/Executable_and_Linkable_Format Those macros are defined in elf.h; presumably the relevant elf.h is old-ish and doesn?t include AARCH64. From kim.barrett at oracle.com Mon Aug 12 03:51:31 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 11 Aug 2019 23:51:31 -0400 Subject: RFR (S): 8228857: Refactor PlatformMonitor into PlatformMutex and PlatformMonitor In-Reply-To: References: <32C9F58D-FA84-4A18-9A43-86DE2F8AD88E@oracle.com> <85649d80-f85e-4da0-dd4c-db148b33d5e8@oracle.com> <9c8ea98c-a2cd-a832-d977-678a4de379b1@oracle.com> <9f76aa54-ce08-4fbd-bb63-65a88dc0db0d@oracle.com> Message-ID: <4C33A88B-2C96-4477-859B-6B1309E50534@oracle.com> > On Aug 11, 2019, at 6:31 PM, David Holmes wrote: > > Hi Dan, > > On 11/08/2019 10:57 pm, Daniel D. Daugherty wrote: >> On 8/9/19 2:25 AM, David Holmes wrote: >>> Okay here is v2 with Kim's non-copyable adjustments and an alternate approach to the "impl" class so that the PlatformMutex doesn't have to pay for the unused pthread_cond_t. Trade-off in this scheme is that PlatformMonitor now has two "impl" pointers so consumes more space. >>> >>> Also made comment changes suggested by Dan. >>> >>> http://cr.openjdk.java.net/~dholmes/8228857/webrev.v2/ >> > > Thanks Dan. Webrev updated in place. Looks good. From david.holmes at oracle.com Mon Aug 12 03:55:36 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 12 Aug 2019 13:55:36 +1000 Subject: RFR: JDK-8227021: VM fails if any sun.boot.library.path paths are longer than JVM_MAXPATHLEN In-Reply-To: References: <25234969-2215-57e9-d8c5-d97b5669ebb1@oracle.com> <5ba808b0-ae52-0d0a-b84b-fc34df35475d@oracle.com> <025da83a-6569-f6ac-7590-5b200ed2344f@oracle.com> Message-ID: <8e62fc61-b46b-0033-f182-cb4a2dbf92fd@oracle.com> Hi Adam, On 10/08/2019 2:47 am, Adam Farley8 wrote: > Hi Serguei, David, > > My turn to apologise for the delay. :) > > I've modified the code as per Serguei's request. Take a look and let me > know if this is the sort of thing you were thinking of. > > Webrev: http://cr.openjdk.java.net/~afarley/8227021.3/webrev/ I'd prefer to see the helper just as a file static function rather than adding it to the os class. + * supplied array of arrays of chars (a), where n I assume (a) is meant to refer to the parameter, but you actually called it arrayarray. I think "a" or "arr" would suffice. Thanks, David > Best Regards > > Adam Farley > IBM Runtimes > > > "serguei.spitsyn at oracle.com" wrote on > 31/07/2019 17:18:05: > >> From: "serguei.spitsyn at oracle.com" >> To: Adam Farley8 , David Holmes >> >> Cc: serviceability-dev , >> hotspot-dev at openjdk.java.net >> Date: 31/07/2019 17:18 >> Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path >> paths are longer than JVM_MAXPATHLEN >> >> Hi Adam, >> >> It looks Okay to me. >> >> A couple of minor comments. >> >> http://cr.openjdk.java.net/~afarley/8227021.2/webrev/src/hotspot/ >> share/runtime/os.cpp.frames.html > >> 1362 ? ? ? //release allocated storage before exiting the vm >> 1363 ? ? ? while (i > 0) { >> 1364 ? ? ? ? ? i--; >> 1365 ? ? ? ? ? if (opath[i] != NULL) { >> 1366 ? ? ? ? ? ? FREE_C_HEAP_ARRAY(char, opath[i]); >> 1367 ? ? ? ? ? } >> 1368 ? ? ? } >> 1369 ? ? ? FREE_C_HEAP_ARRAY(char*, opath); >> >> 1377 ? ? ? //release allocated storage before returning null >> 1378 ? ? ? while (i > 0) { >> 1379 ? ? ? ? ? i--; >> 1380 ? ? ? ? ? if (opath[i] != NULL) { >> 1381 ? ? ? ? ? ? FREE_C_HEAP_ARRAY(char, opath[i]); >> 1382 ? ? ? ? ? } >> 1383 ? ? ? } >> 1384 ? ? ? FREE_C_HEAP_ARRAY(char*, opath); >> >> This duplicated fragments is worth to refactor to a function. >> Also a space is missed at the beginning of the comment. >> >> >> Thanks, >> Serguei >> >> >> >> On 7/31/19 02:01, Adam Farley8 wrote: >> Hi All, >> >> Reviewers requested for the change below. >> >> @David - Agreed. Would you be prepared to sponsor the change? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8227021 >> Webrev: http://cr.openjdk.java.net/~afarley/8227021.2/webrev/ >> >> Best Regards >> >> Adam Farley >> IBM Runtimes >> >> P.S. Remembered to add the links this time. :) >> >> >> David Holmes wrote on 30/07/2019 03:37:53: >> >> > From: David Holmes >> > To: Adam Farley8 >> > Cc: hotspot-dev at openjdk.java.net, serviceability-dev >> > >> > Date: 30/07/2019 03:38 >> > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path >> > paths are longer than JVM_MAXPATHLEN >> > >> > Hi Adam, >> > >> > On 25/07/2019 3:57 am, Adam Farley8 wrote: >> > > Hi David, >> > > >> > > Welcome back. :) >> > >> > Thanks. Sorry for the delay in getting back to this. >> > >> > I like .v2 as it is much simpler (notwithstanding freeing the already >> > allocated arrays adds some complexity - thanks for fixing that). >> > >> > I'm still not sure we can't optimise things better for unchangeable >> > properties like the boot libary path, but that's another RFE. >> > >> > Thanks, >> > David >> > >> 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 david.holmes at oracle.com Mon Aug 12 03:58:01 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 12 Aug 2019 13:58:01 +1000 Subject: RFR (S): 8228857: Refactor PlatformMonitor into PlatformMutex and PlatformMonitor In-Reply-To: <4C33A88B-2C96-4477-859B-6B1309E50534@oracle.com> References: <32C9F58D-FA84-4A18-9A43-86DE2F8AD88E@oracle.com> <85649d80-f85e-4da0-dd4c-db148b33d5e8@oracle.com> <9c8ea98c-a2cd-a832-d977-678a4de379b1@oracle.com> <9f76aa54-ce08-4fbd-bb63-65a88dc0db0d@oracle.com> <4C33A88B-2C96-4477-859B-6B1309E50534@oracle.com> Message-ID: On 12/08/2019 1:51 pm, Kim Barrett wrote: >> On Aug 11, 2019, at 6:31 PM, David Holmes wrote: >> >> Hi Dan, >> >> On 11/08/2019 10:57 pm, Daniel D. Daugherty wrote: >>> On 8/9/19 2:25 AM, David Holmes wrote: >>>> Okay here is v2 with Kim's non-copyable adjustments and an alternate approach to the "impl" class so that the PlatformMutex doesn't have to pay for the unused pthread_cond_t. Trade-off in this scheme is that PlatformMonitor now has two "impl" pointers so consumes more space. >>>> >>>> Also made comment changes suggested by Dan. >>>> >>>> http://cr.openjdk.java.net/~dholmes/8228857/webrev.v2/ >>> >> >> Thanks Dan. Webrev updated in place. > > Looks good. > Thanks Kim! David From jwkozaczuk at gmail.com Mon Aug 12 04:42:24 2019 From: jwkozaczuk at gmail.com (Waldek Kozaczuk) Date: Mon, 12 Aug 2019 00:42:24 -0400 Subject: Jetty hangs early on Java 12 on OSv with Threadlocal Handshakes ON - shorter version In-Reply-To: <6e41d3f6-bbdc-c1f6-a278-bb031ddb90e6@oracle.com> References: <01d12413-dfda-d2ad-0e17-6e9f3d0f4f0d@oracle.com> <6e41d3f6-bbdc-c1f6-a278-bb031ddb90e6@oracle.com> Message-ID: <6377BB3E-AAE2-42BF-88B7-F59A4326D8A9@gmail.com> Robbin, Sent from my iPhone > On Aug 9, 2019, at 09:05, Robbin Ehn wrote: > > Hi, > >> On 2019-08-09 14:23, Waldek Kozaczuk wrote: >> Hi, >> Thanks for your suggestions. >> I have tried against openjdk-jdk12-latest-linux-x86_64-release.tar.xz from https://builds.shipilev.net/openjdk-jdk12/ and openjdk-jdk13-latest-linux-x86_64-release.tar.xz (Java 13) from https://builds.shipilev.net/openjdk-jdk13/ and I am seeing same symptoms - hanging. > > Pickup a slowdebug jdk/jdk, I think Shipilev calls that openjdk-jdk. > >> I have also tried to use the fast-debug distribution - openjdk-jdk12-latest-linux-x86_64-fastdebug.tar.xz - but unfortunately I hit this snag per gdb: > > Either just start the process with > >java -cp . MyHang & > pid is printed > wait until hang > >gdb -p > gdb>i thread > note the VMThread number > gdb>t VMThreadNumber > gdb>step > ... > until you see what thread is not completed > if all threads are completed but we are still not reached zero > a thread wrongfully elided the handshake > > Alternative you can also do: > >gdb --args java -cp . MyHang > >handle all nostop noprint pass > gdb will now ignore signals > gdb>run > wait for hang, do what I describe above > > >> 2. It iterates through all JavaThread instances from the jtiwh collection (what exactly is this?) > > We use hazard pointers for lock-free JavaThread accesses. > jtiwh is a iterator for looping over this lock-free data-structure. > > and SHOULD end up calling HandshakeState::process_by_vmthread >> (https://github.com/openjdk/jdk/blob/jdk-12%2B12/src/hotspot/share/runtime/handshake.cpp#L361) which eventually should call HandshakeThreadsOperation::do_handshake(JavaThread* thread) for each JavaThread and increment the _done semaphore BUT only if the process_by_vmthread() calls _operation->do_handshake(target), right? But there are at least 3 IFs which may cause this method to return and the critical 4th IF (https://github.com/openjdk/jdk/blob/jdk-12%2B12/src/hotspot/share/runtime/handshake.cpp#L379-L389) which only executes its body if vmthread_can_process_handshake returns true. What could make these first 3 IF be true and make >> process_by_vmthread to return BEFORE the last if? When would last IF be false? > > Either the JavaThread itself process the handshake, if it has not done so VMThread checks is it would be safe to processes it on behalf of the JavaThread. > >> 3. VM_HandshakeAllThreads::doit() loops by calling poll_for_completed_thread() which NEVER completes. > > It do that just fine on Linux/Windows/OSX. > I'm guessing there is a bug in one of the OS primitives used. > Since the uses of semaphores is new in hotspot, that would be my first candidate. There are one per thread semaphore and one operation semaphore. You were right on the money! There was a bug in the sem_trywait() - ?>? instead of ?>=? in the critical if statement. It alls works like a charm now. The issue can be closed. Thanks everybody for your help! Waldek > For every post on the operation semaphore number_of_threads_completed is increased. If VMThread never leaves means he did get all the posts he wanted. > > Instead of gdb, it may be easier to start with adding: > -XX:HandshakeTimeout=1000 > > That should give some valuable output. > > /Robbin > >> Correct me where I made any mistake in my thinking. >> Thanks in advance for your support, >> Waldek >> On Thu, Aug 8, 2019 at 6:53 AM Robbin Ehn > wrote: >> Hi Waldek, >> > #0 0x0000100000c86370 in sem_trywait at plt () >> > #1 0x0000100001702bf2 in PosixSemaphore::trywait() () >> > #2 0x000010000121aab4 in VM_HandshakeAllThreads::doit() () >> VMThread is trying to figure out which threads have not executed their >> handshake >> operation and possible execute it for them (e.g. JavaThread in native). >> If you attach gdb and step around in VM_HandshakeAllThreads::doit while looping >> there, you can figure out why we never finish. >> > When I explicitly enable thread local handshakes on Java 11 it works as >> > well: >> In 11 it is only used by ZGC, but in 12 it is used for stack-scanning after >> nmethods. >> Sweeper thread: >> #12 0x0000100001219a48 in Handshake::execute(ThreadClosure*) () >> #13 0x00001000018b4a0c in NMethodSweeper::possibly_sweep() () >> > One more datapoint - I am able to run a simple Hello World java app on Java >> > 12 on OSv with thread-local handshakes on so it looks like this problem >> > appears on more complicated apps. >> If you never get to needing to sweep nmethod, you will have never executed a >> handshake. (but you will execute safepoints using the handshake poll) >> If you can easily reprod, take a slowdebug and when the process hang, attach >> gdb >> switch to VMThread and step around, you will see a count which decrease once >> for >> every thread which have executed it's handshake. To figure out if a thread have >> executed it's handshake, VMThread will take a per thread semaphore (decrease >> it), which serialize access to the per thread handshake operation, and then >> look >> if the operation is completed, return the semaphore (increase it), and look at >> next thread. >> /Robbin >> > >> > *Lastly, the exact same app works fine on Java 12 on Linux.* >> > >> > So given all that could you please point me to what the problem might be? >> > What has changed in the implementation of thread local handshakes between >> > Java 11 and 12 that may have caused this issue (I see many changes made to >> > >> https://github.com/openjdk/jdk/blob/0fe0312f416add1536a45ecfb292c887ef7e02bd/src/hotspot/share/runtime/handshake.cpp >> > but >> > I am not even sure which commit matches the version of Java 12 or Java 11 I >> > am using)? I am thinking this has to do with some subtle differences >> > between relevant ABI implementation between OSv and Linux. Signals related? >> > >> > Thanks for your help in advance, >> > >> > Waldek >> > >> > Thread dump of all Java threads (in other email that was to big) >> > From martin.doerr at sap.com Mon Aug 12 07:31:12 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 12 Aug 2019 07:31:12 +0000 Subject: RFR : [XS] 8219082 : jdk/jfr/event/runtime/TestShutdownEvent.java failed in validateStackTrace() In-Reply-To: References: Message-ID: +1 Thanks, Martin From: mikhailo.seledtsov at oracle.com Sent: Freitag, 9. August 2019 23:01 To: Baesken, Matthias ; 'hotspot-dev at openjdk.java.net' Cc: Erik Gahlin ; Doerr, Martin Subject: Re: RFR : [XS] 8219082 : jdk/jfr/event/runtime/TestShutdownEvent.java failed in validateStackTrace() Looks good to me, Thank you, Misha On 8/9/19 6:56 AM, Baesken, Matthias wrote: Hello, please review this small test adjustment . The TestShutdownEvent.java JFR test fails now and then in the sub-test "TestVMCrash" . Error is in the stack validation , it finds sometimes a stack with no frames . at jdk.jfr.event.runtime.TestShutdownEvent.validateStackTrace(TestShutdownEvent.java:128) at jdk.jfr.event.runtime.TestShutdownEvent$TestVMCrash.verifyEvents(TestShutdownEvent.java:172) Our conclusion so far is that it is currently not 100% reliable to get a stack trace in this case using vframeStream in jfrStackTraceRepository.cpp (forced crash with Unsafe + event generation using EventShutdown late in VMError.cpp ) . Reason is that we might get compiled frames on the stack and then the vframeStream - based solution does not work ( when running with -Xcomp it always fails). See also the comments of our JIT expert Martin in the bug : "JfrStackTrace uses vframeStream to retrieve the stack frames. This works fine if a native frame is on top (because we have the last Java frame linked in the JavaThread object). That's why the tests works when executed with -Xint. The crashing method is native in this case. The situation is different when there's a compiled frame on top. JIT compilers usually inline Unsafe accesses as instrinsics. So the crashing instruction is just in the middle of a compiled method. The vframeStream API would require a PC for which additional information is available (see CodeEmitInfo for C1 or JVMState for C2). That's not the case for an illegal Unsafe access which simply yields undefined behavior. Vframes are not supported in this case so the stack trace is empty. It is possible to get a native stack trace (see VMError::print_native_stack which doesn't use vframes) for hs_err files. Compiled frames are only shown as single frames even if multiple Java frames are included due to inlining. Note that the test always fails when using -Xcomp. So it doesn't make any sense to expect a non-empty vframe based stack trace when a compiled frame is on top. " My first idea was to run the test with -Xint but its probably not such a good idea ; so better for now remove the unreliable check ( + add a comment ). Thanks, Matthias Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8219082 http://cr.openjdk.java.net/~mbaesken/webrevs/8219082.1/ From erik.osterlund at oracle.com Mon Aug 12 08:52:54 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Mon, 12 Aug 2019 10:52:54 +0200 Subject: RFR: 8227054: ServiceThread needs to know about all OopStorage objects In-Reply-To: References: <8181924C-36E6-4B91-9567-150F00286241@oracle.com> <74C738E7-CBDD-4891-ABD6-F8E023372508@oracle.com> <60099477-9AD4-4EFC-AA6F-6EF19D840E67@oracle.com> <164151e7-fec4-8c61-f247-3d5a41c910c1@oracle.com> <96EE9BB8-9EE5-4FBB-B266-785C563BFC2E@oracle.com> Message-ID: <694f8e0c-b00f-54d4-105d-68e6442b2759@oracle.com> Hi Kim, On 2019-08-12 05:26, Kim Barrett wrote: >> On Aug 10, 2019, at 3:52 AM, Erik Osterlund wrote: >> >> Hi Kim, >> >> Thank you for taking this for another spin. I like the new version a lot better. I think you convinced me on using the private enum being a better idea than my reinterpret_cast. >> >> I only have two questions left: >> >> 1) How would you feel about not using the macro for generating the getters? It looks like 1 short line for the getter vs 1 short line for the macro. In other words, not much typing is saved using the X macro here. But it will confuse IDEs. So I would have preferred the explicit getters. >> >> 2) Similar thought for the initialization of OopStorages where the name is generated from the macro. I thought the name was meant to be in more human readable form as we print them out in logs. So again, I would have loved explicit initialization, which is still just 1 trivial line per OopStorage. >> >> If you have strong opinions about keeping those macros, I will not oppose it. But maybe you agree that retaining that IDE awareness of the code and nice printouts in the logs is worth doing those one liners without X macros? > > Just to be clear, there are no x-macros here, just a couple very > simple macros. Using x-macros would have reduced those blocks of > macro invocations to one-liners. Okay. > Can you describe the IDE confusion? I can think of lots of potential > issues, depending on how smart/not-so-smart a given IDE might be, but > I don't know what actual problems you might be worried about. The two main ones I am concerned about is go-to-definition. There is no real definition now, so you will get to a macro instead. The other concern is the inability to list all callers of the getter. Since there is no definition outside of macro land, you can't do that, and will have to resort to raw text search instead. I for example use the rtags plugin to Emacs to find my way around hotspot using such functionality. But obviously there are lots of other tools doing similar things. I usually try not to break the ability to navigate the code by having it generated by macros, unless it's somehow painful not to do it with macros, keeping that as a plan B. But here it looks trivial, and it doesn't look like the use of macros buys us anything more than another mental indirection to look through. > For me, the macros improve readability by emphasizing the parts that > are different (the interesting parts) and deemphasizing the parts that > are the same (the boring parts). For me it's the opposite. :/ If I want to know the name of e.g. the JNI weak getter, I have to first read the OOPSTORAGE_ACCESSOR(jni_weak) line, then go to the definition of OOPSTORAGE_ACCESSOR, and read the macro to figure out how that invocation will generate the getter, instead of just reading the one-liner getter, like this: static OopStorage* jni_weak() { return storage(jni_weak_index); } > I looked at the logging of OopStorage processing; the use of the > stringized identifiers rather than bespoke strings looked fine to me. > Indeed, it has the small additional benefit for someone who is a > developer that the name exactly matches the associated getter. (Of > course, that doesn't matter to a non-developer log user.) Okay. I think it's nicer for users to get a pretty name instead of an identifier in the code. >> Apart from those two things, I really liked the approach! > > Thanks. Hopefully we?re approaching a conclusion on this change. I hope so. Thanks, /Erik From boris.ulasevich at bell-sw.com Mon Aug 12 08:53:49 2019 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Mon, 12 Aug 2019 11:53:49 +0300 Subject: RFR(S): 8229254: solaris_x64 build fails In-Reply-To: References: <9a371ec1-e125-4945-521b-90bb2b4c6984@bell-sw.com> Message-ID: <28049dbf-b2cd-3ef9-d58e-a66cb50eeedb@bell-sw.com> Hi David, On 12.08.2019 5:47, David Holmes wrote: > Hi Boris, > > On 9/08/2019 11:14 pm, Boris Ulasevich wrote: >> Hi, >> >> Please review the following simple change to make solaris_x64 build >> compilable. >> >> Syntax error was brought by JDK-8191278 [1]. The fix is evident. > > Yes looks good. > >> Missing constant issue occurred after JDK-8226238 [2]. I copied >> workaround for the case of missing EM_AARCH64 constant in system elf.h >> header from os_linux.cpp implementation. > > I'm really not sure why we keep expanding a Solaris specific structure > with entries for architectures the OS does not run on ... Yes. I had the same concern. The first impulse was to remove the AARCH64 data line or to surround it #ifdef AARCH directive. The sense of this line on os_solaris.cpp implementation might be a good question on JDK-8226238 review. I think the answer is that it makes no overhead, and potentially improves .so library compatibility error message. > That aside the fix seems fine - the value is somewhat arbitrary but > doesn't conflict with anything AFAICS. My explanation was not quite intelligible, sorry. As Kim have already answered, this is as constant that should normally come from elf.h header. But as Solaris system header elf.h does not have that, this is just a workaround for the system header on build machine, very similar to that in os_linux.cpp implementation. > Thanks, > David > ----- > >> http://cr.openjdk.java.net/~bulasevich/8229254/webrev.00 >> http://bugs.openjdk.java.net/browse/JDK-8229254 >> >> Testing done: tier1,tier2. >> >> thanks, >> Boris >> >> [1] MappedByteBuffer bulk access memory failures are not handled >> gracefully >> >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2019-June/038352.html >> [2] Improve error output and fix elf issues in os::dll_load >> >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2019-June/038597.html From per.liden at oracle.com Mon Aug 12 09:28:15 2019 From: per.liden at oracle.com (Per Liden) Date: Mon, 12 Aug 2019 11:28:15 +0200 Subject: RFR: 8227054: ServiceThread needs to know about all OopStorage objects In-Reply-To: <694f8e0c-b00f-54d4-105d-68e6442b2759@oracle.com> References: <8181924C-36E6-4B91-9567-150F00286241@oracle.com> <74C738E7-CBDD-4891-ABD6-F8E023372508@oracle.com> <60099477-9AD4-4EFC-AA6F-6EF19D840E67@oracle.com> <164151e7-fec4-8c61-f247-3d5a41c910c1@oracle.com> <96EE9BB8-9EE5-4FBB-B266-785C563BFC2E@oracle.com> <694f8e0c-b00f-54d4-105d-68e6442b2759@oracle.com> Message-ID: <1ce2a058-60e8-9a43-f479-fc4aa1b1e652@oracle.com> Hi Kim & Erik, First, thanks Kim for taking this for a second round. I also like you're new proposal a lot better. On 8/12/19 10:52 AM, Erik ?sterlund wrote: [...] >> Can you describe the IDE confusion?? I can think of lots of potential >> issues, depending on how smart/not-so-smart a given IDE might be, but >> I don't know what actual problems you might be worried about. > > The two main ones I am concerned about is go-to-definition. There is no > real definition now, so you will get to a macro instead. The other > concern is the inability to list all callers of the getter. Since there > is no definition outside of macro land, you can't do that, and will have > to resort to raw text search instead. > > I for example use the rtags plugin to Emacs to find my way around > hotspot using such functionality. But obviously there are lots of other > tools doing similar things. > > I usually try not to break the ability to navigate the code by having it > generated by macros, unless it's somehow painful not to do it with > macros, keeping that as a plan B. But here it looks trivial, and it > doesn't look like the use of macros buys us anything more than another > mental indirection to look through. > >> For me, the macros improve readability by emphasizing the parts that >> are different (the interesting parts) and deemphasizing the parts that >> are the same (the boring parts). > > For me it's the opposite. :/ > If I want to know the name of e.g. the JNI weak getter, I have to first > read the OOPSTORAGE_ACCESSOR(jni_weak) line, then go to the definition > of OOPSTORAGE_ACCESSOR, and read the macro to figure out how that > invocation will generate the getter, instead of just reading the > one-liner getter, like this: > static OopStorage* jni_weak() { return storage(jni_weak_index); } I can only eco Erik's opinion. I can understand if one might want to use macros in this way for long or complicated functions to avoid lots of code duplication and cut-and-paste errors. But for trivial stuff, I think it just hurts readability and confuses IDEs. cheers, Per From matthias.baesken at sap.com Mon Aug 12 10:13:30 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 12 Aug 2019 10:13:30 +0000 Subject: RFR : [XS] 8219082 : jdk/jfr/event/runtime/TestShutdownEvent.java failed in validateStackTrace() In-Reply-To: References: Message-ID: Thanks ! May I get a second review please ? Best regards, Matthias From: mikhailo.seledtsov at oracle.com Sent: Freitag, 9. August 2019 23:01 To: Baesken, Matthias ; 'hotspot-dev at openjdk.java.net' Cc: Erik Gahlin ; Doerr, Martin Subject: Re: RFR : [XS] 8219082 : jdk/jfr/event/runtime/TestShutdownEvent.java failed in validateStackTrace() Looks good to me, Thank you, Misha On 8/9/19 6:56 AM, Baesken, Matthias wrote: Hello, please review this small test adjustment . The TestShutdownEvent.java JFR test fails now and then in the sub-test "TestVMCrash" . Error is in the stack validation , it finds sometimes a stack with no frames . at jdk.jfr.event.runtime.TestShutdownEvent.validateStackTrace(TestShutdownEvent.java:128) at jdk.jfr.event.runtime.TestShutdownEvent$TestVMCrash.verifyEvents(TestShutdownEvent.java:172) Our conclusion so far is that it is currently not 100% reliable to get a stack trace in this case using vframeStream in jfrStackTraceRepository.cpp (forced crash with Unsafe + event generation using EventShutdown late in VMError.cpp ) . Reason is that we might get compiled frames on the stack and then the vframeStream - based solution does not work ( when running with -Xcomp it always fails). See also the comments of our JIT expert Martin in the bug : "JfrStackTrace uses vframeStream to retrieve the stack frames. This works fine if a native frame is on top (because we have the last Java frame linked in the JavaThread object). That's why the tests works when executed with -Xint. The crashing method is native in this case. The situation is different when there's a compiled frame on top. JIT compilers usually inline Unsafe accesses as instrinsics. So the crashing instruction is just in the middle of a compiled method. The vframeStream API would require a PC for which additional information is available (see CodeEmitInfo for C1 or JVMState for C2). That's not the case for an illegal Unsafe access which simply yields undefined behavior. Vframes are not supported in this case so the stack trace is empty. It is possible to get a native stack trace (see VMError::print_native_stack which doesn't use vframes) for hs_err files. Compiled frames are only shown as single frames even if multiple Java frames are included due to inlining. Note that the test always fails when using -Xcomp. So it doesn't make any sense to expect a non-empty vframe based stack trace when a compiled frame is on top. " My first idea was to run the test with -Xint but its probably not such a good idea ; so better for now remove the unreliable check ( + add a comment ). Thanks, Matthias Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8219082 http://cr.openjdk.java.net/~mbaesken/webrevs/8219082.1/ From matthias.baesken at sap.com Mon Aug 12 10:13:31 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 12 Aug 2019 10:13:31 +0000 Subject: RFR : [XS] 8219082 : jdk/jfr/event/runtime/TestShutdownEvent.java failed in validateStackTrace() In-Reply-To: References: Message-ID: Hi Misha + Martin , thanks for the reviews ! From: Doerr, Martin Sent: Montag, 12. August 2019 09:31 To: mikhailo.seledtsov at oracle.com; Baesken, Matthias ; 'hotspot-dev at openjdk.java.net' Cc: Erik Gahlin Subject: RE: RFR : [XS] 8219082 : jdk/jfr/event/runtime/TestShutdownEvent.java failed in validateStackTrace() +1 Thanks, Martin From: mikhailo.seledtsov at oracle.com > Sent: Freitag, 9. August 2019 23:01 To: Baesken, Matthias >; 'hotspot-dev at openjdk.java.net' > Cc: Erik Gahlin >; Doerr, Martin > Subject: Re: RFR : [XS] 8219082 : jdk/jfr/event/runtime/TestShutdownEvent.java failed in validateStackTrace() Looks good to me, Thank you, Misha On 8/9/19 6:56 AM, Baesken, Matthias wrote: Hello, please review this small test adjustment . The TestShutdownEvent.java JFR test fails now and then in the sub-test "TestVMCrash" . Error is in the stack validation , it finds sometimes a stack with no frames . at jdk.jfr.event.runtime.TestShutdownEvent.validateStackTrace(TestShutdownEvent.java:128) at jdk.jfr.event.runtime.TestShutdownEvent$TestVMCrash.verifyEvents(TestShutdownEvent.java:172) Our conclusion so far is that it is currently not 100% reliable to get a stack trace in this case using vframeStream in jfrStackTraceRepository.cpp (forced crash with Unsafe + event generation using EventShutdown late in VMError.cpp ) . Reason is that we might get compiled frames on the stack and then the vframeStream - based solution does not work ( when running with -Xcomp it always fails). See also the comments of our JIT expert Martin in the bug : "JfrStackTrace uses vframeStream to retrieve the stack frames. This works fine if a native frame is on top (because we have the last Java frame linked in the JavaThread object). That's why the tests works when executed with -Xint. The crashing method is native in this case. The situation is different when there's a compiled frame on top. JIT compilers usually inline Unsafe accesses as instrinsics. So the crashing instruction is just in the middle of a compiled method. The vframeStream API would require a PC for which additional information is available (see CodeEmitInfo for C1 or JVMState for C2). That's not the case for an illegal Unsafe access which simply yields undefined behavior. Vframes are not supported in this case so the stack trace is empty. It is possible to get a native stack trace (see VMError::print_native_stack which doesn't use vframes) for hs_err files. Compiled frames are only shown as single frames even if multiple Java frames are included due to inlining. Note that the test always fails when using -Xcomp. So it doesn't make any sense to expect a non-empty vframe based stack trace when a compiled frame is on top. " My first idea was to run the test with -Xint but its probably not such a good idea ; so better for now remove the unreliable check ( + add a comment ). Thanks, Matthias Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8219082 http://cr.openjdk.java.net/~mbaesken/webrevs/8219082.1/ From stefan.reich.maker.of.eye at googlemail.com Mon Aug 12 11:50:34 2019 From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich) Date: Mon, 12 Aug 2019 13:50:34 +0200 Subject: HotSpot compilation latency Message-ID: Hi, a quick general question if you don't mind. How quickly does HotSpot start (and finish) to compile methods? Is this dependent on the system's speed or on wall time? So, if I execute, say, a loop that runs for one second, is there a chance it will be compiled and on-stack-replaced with an optimized version within that second? Many greetings, Stefan -- Stefan Reich BotCompany.de // Java-based operating systems From tobias.hartmann at oracle.com Mon Aug 12 11:59:57 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 12 Aug 2019 13:59:57 +0200 Subject: HotSpot compilation latency In-Reply-To: References: Message-ID: Hi Stefan, On 12.08.19 13:50, Stefan Reich wrote: > How quickly does HotSpot start (and finish) to compile methods? Is this > dependent on the system's speed or on wall time? A method is JIT compiled once the number of invocations or backedges (for loops) reaches the corresponding invocation threshold. With TieredCompilation there are different thresholds for the different tiers: http://hg.openjdk.java.net/jdk/jdk/file/0211b062843d/src/hotspot/share/runtime/globals.hpp#l1975 See also slide 17 and 36 of: http://cr.openjdk.java.net/~thartmann/talks/2017-Hotspot_Under_The_Hood.pdf > So, if I execute, say, a loop that runs for one second, is there a chance > it will be compiled and on-stack-replaced with an optimized version within > that second? That depends on how often the loop backedge is taken on your system in that second. Best regards, Tobias From stefan.reich.maker.of.eye at googlemail.com Mon Aug 12 12:07:43 2019 From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich) Date: Mon, 12 Aug 2019 14:07:43 +0200 Subject: HotSpot compilation latency In-Reply-To: References: Message-ID: Hi Tobias, thank you for your quick answer. So the compilation thresholds themselves are all independent of wall time. That's pretty cool. Thus on a machine twice as fast compilation should kick in twice as fast too. > That depends on how often the loop backedge is taken on your system in that second. Is this dependent on a fixed-interval timer or something? Is it specified? Thanks, Stefan On Mon, 12 Aug 2019 at 14:02, Tobias Hartmann wrote: > Hi Stefan, > > On 12.08.19 13:50, Stefan Reich wrote: > > How quickly does HotSpot start (and finish) to compile methods? Is this > > dependent on the system's speed or on wall time? > > A method is JIT compiled once the number of invocations or backedges (for > loops) reaches the > corresponding invocation threshold. > > With TieredCompilation there are different thresholds for the different > tiers: > > http://hg.openjdk.java.net/jdk/jdk/file/0211b062843d/src/hotspot/share/runtime/globals.hpp#l1975 > > See also slide 17 and 36 of: > http://cr.openjdk.java.net/~thartmann/talks/2017-Hotspot_Under_The_Hood.pdf > > > So, if I execute, say, a loop that runs for one second, is there a chance > > it will be compiled and on-stack-replaced with an optimized version > within > > that second? > > That depends on how often the loop backedge is taken on your system in > that second. > > Best regards, > Tobias > -- Stefan Reich BotCompany.de // Java-based operating systems From tobias.hartmann at oracle.com Mon Aug 12 12:23:09 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 12 Aug 2019 14:23:09 +0200 Subject: HotSpot compilation latency In-Reply-To: References: Message-ID: <48406668-4d97-e66b-ee6b-b57fed23a56d@oracle.com> On 12.08.19 14:07, Stefan Reich wrote: >> That depends on how often the loop backedge is taken on your system in that second. > Is this dependent on a fixed-interval timer or something? Is it specified? Similar to the number of invocations, the number of backedges taken are also counted (by the interpreter or C1 compiled code) and there are backedge thresholds. See Tier*BackEdgeThreshold: http://hg.openjdk.java.net/jdk/jdk/file/0211b062843d/src/hotspot/share/runtime/globals.hpp#l2027 Best regards, Tobias From matthias.baesken at sap.com Mon Aug 12 12:32:42 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 12 Aug 2019 12:32:42 +0000 Subject: RFR [XS]: 8229370: make jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java more stable Message-ID: Hello, please review this small test enhancement. We noticed that on some of our Linux machines (SLES12 based) the TestNetworkUtilizationEvent.java test reported just 1 interface (the test TestNetworkUtilizationEvent.java expects more than 1 on Linux). Looking into the HS code , os_perf_linux.cpp collects the interfaces + additional information about bytes read/written (by looking at /sys/class/net/eth/statistics/ ) and this info is given to JFR . However it seems to need (at least on some machines / setups) more packet send operations / potential retries to really get counter updates (and without updates in the counters, no interfaces are found). So I adjusted the test accordingly. Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8229370 http://cr.openjdk.java.net/~mbaesken/webrevs/8229370.0/ Best regards, Matthias From stefan.reich.maker.of.eye at googlemail.com Mon Aug 12 12:41:11 2019 From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich) Date: Mon, 12 Aug 2019 14:41:11 +0200 Subject: HotSpot compilation latency In-Reply-To: <48406668-4d97-e66b-ee6b-b57fed23a56d@oracle.com> References: <48406668-4d97-e66b-ee6b-b57fed23a56d@oracle.com> Message-ID: So none of this is dependent on clock time at all? On Mon, 12 Aug 2019 at 14:23, Tobias Hartmann wrote: > > On 12.08.19 14:07, Stefan Reich wrote: > >> That depends on how often the loop backedge is taken on your system in > that second. > > Is this dependent on a fixed-interval timer or something? Is it > specified? > > Similar to the number of invocations, the number of backedges taken are > also counted (by the > interpreter or C1 compiled code) and there are backedge thresholds. See > Tier*BackEdgeThreshold: > > http://hg.openjdk.java.net/jdk/jdk/file/0211b062843d/src/hotspot/share/runtime/globals.hpp#l2027 > > Best regards, > Tobias > -- Stefan Reich BotCompany.de // Java-based operating systems From tobias.hartmann at oracle.com Mon Aug 12 12:50:07 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 12 Aug 2019 14:50:07 +0200 Subject: HotSpot compilation latency In-Reply-To: References: <48406668-4d97-e66b-ee6b-b57fed23a56d@oracle.com> Message-ID: <829bf123-ef7e-f854-22ca-180d45ec3ba0@oracle.com> On 12.08.19 14:41, Stefan Reich wrote: > So none of this is dependent on clock time at all? Yes, exactly. Best regards, Tobias From stefan.reich.maker.of.eye at googlemail.com Mon Aug 12 14:39:13 2019 From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich) Date: Mon, 12 Aug 2019 16:39:13 +0200 Subject: HotSpot compilation latency In-Reply-To: <829bf123-ef7e-f854-22ca-180d45ec3ba0@oracle.com> References: <48406668-4d97-e66b-ee6b-b57fed23a56d@oracle.com> <829bf123-ef7e-f854-22ca-180d45ec3ba0@oracle.com> Message-ID: Huh. So the compilation results (which method is compiled and when in the program flow) should typically not very between machines of different speed. (For a single-threaded program.) That's interesting, I always thought there was a time component involved ("profile for 100 ms" or something). Optimization makes more sense without it I guess. Thanks On Mon, 12 Aug 2019 at 14:52, Tobias Hartmann wrote: > > On 12.08.19 14:41, Stefan Reich wrote: > > So none of this is dependent on clock time at all? > > Yes, exactly. > > Best regards, > Tobias > -- Stefan Reich BotCompany.de // Java-based operating systems From stefan.reich.maker.of.eye at googlemail.com Mon Aug 12 14:40:06 2019 From: stefan.reich.maker.of.eye at googlemail.com (Stefan Reich) Date: Mon, 12 Aug 2019 16:40:06 +0200 Subject: HotSpot compilation latency In-Reply-To: References: <48406668-4d97-e66b-ee6b-b57fed23a56d@oracle.com> <829bf123-ef7e-f854-22ca-180d45ec3ba0@oracle.com> Message-ID: > Huh. So the compilation results (which method is compiled and when in the program flow) should typically not *very between machines of different speed. *vary On Mon, 12 Aug 2019 at 16:39, Stefan Reich < stefan.reich.maker.of.eye at googlemail.com> wrote: > Huh. So the compilation results (which method is compiled and when in the > program flow) should typically not very between machines of different speed. > > (For a single-threaded program.) > > That's interesting, I always thought there was a time component involved > ("profile for 100 ms" or something). Optimization makes more sense without > it I guess. > > Thanks > > On Mon, 12 Aug 2019 at 14:52, Tobias Hartmann > wrote: > >> >> On 12.08.19 14:41, Stefan Reich wrote: >> > So none of this is dependent on clock time at all? >> >> Yes, exactly. >> >> Best regards, >> Tobias >> > > > -- > Stefan Reich > BotCompany.de // Java-based operating systems > -- Stefan Reich BotCompany.de // Java-based operating systems From adam.farley at uk.ibm.com Mon Aug 12 15:19:27 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Mon, 12 Aug 2019 16:19:27 +0100 Subject: RFR: JDK-8227021: VM fails if any sun.boot.library.path paths are longer than JVM_MAXPATHLEN In-Reply-To: <8e62fc61-b46b-0033-f182-cb4a2dbf92fd@oracle.com> References: <25234969-2215-57e9-d8c5-d97b5669ebb1@oracle.com> <5ba808b0-ae52-0d0a-b84b-fc34df35475d@oracle.com> <025da83a-6569-f6ac-7590-5b200ed2344f@oracle.com> <8e62fc61-b46b-0033-f182-cb4a2dbf92fd@oracle.com> Message-ID: Hi David, Changes made as requested: http://cr.openjdk.java.net/~afarley/8227021.4/webrev Best Regards Adam Farley IBM Runtimes David Holmes wrote on 12/08/2019 04:55:36: > From: David Holmes > To: Adam Farley8 , > "serguei.spitsyn at oracle.com" > Cc: hotspot-dev at openjdk.java.net > Date: 12/08/2019 04:56 > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > paths are longer than JVM_MAXPATHLEN > > Hi Adam, > > On 10/08/2019 2:47 am, Adam Farley8 wrote: > > Hi Serguei, David, > > > > My turn to apologise for the delay. :) > > > > I've modified the code as per Serguei's request. Take a look and let me > > know if this is the sort of thing you were thinking of. > > > > Webrev: https://urldefense.proofpoint.com/v2/url? > u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.3_webrev_&d=DwID- > g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=L19aeFXoR9JIO62QRPFzZObIU8RbhpCtXSvUibD2ISk&e= > > I'd prefer to see the helper just as a file static function rather than > adding it to the os class. > > + * supplied array of arrays of chars (a), where n > > I assume (a) is meant to refer to the parameter, but you actually called > it arrayarray. I think "a" or "arr" would suffice. > > Thanks, > David > > > Best Regards > > > > Adam Farley > > IBM Runtimes > > > > > > "serguei.spitsyn at oracle.com" wrote on > > 31/07/2019 17:18:05: > > > >> From: "serguei.spitsyn at oracle.com" > >> To: Adam Farley8 , David Holmes > >> > >> Cc: serviceability-dev , > >> hotspot-dev at openjdk.java.net > >> Date: 31/07/2019 17:18 > >> Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > >> paths are longer than JVM_MAXPATHLEN > >> > >> Hi Adam, > >> > >> It looks Okay to me. > >> > >> A couple of minor comments. > >> > >> https://urldefense.proofpoint.com/v2/url? > u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021. > 2_webrev_src_hotspot_&d=DwID-g&c=jf_iaSHvJObTbx- > siA1ZOg&r=P5m8KWUXJf-CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NL6tYuwwDod3DSmj-1ztxAywpO8L52HEyO0wvTR05bs&e= > >> share/runtime/os.cpp.frames.html > > > >> 1362 //release allocated storage before exiting the vm > >> 1363 while (i > 0) { > >> 1364 i--; > >> 1365 if (opath[i] != NULL) { > >> 1366 FREE_C_HEAP_ARRAY(char, opath[i]); > >> 1367 } > >> 1368 } > >> 1369 FREE_C_HEAP_ARRAY(char*, opath); > >> > >> 1377 //release allocated storage before returning null > >> 1378 while (i > 0) { > >> 1379 i--; > >> 1380 if (opath[i] != NULL) { > >> 1381 FREE_C_HEAP_ARRAY(char, opath[i]); > >> 1382 } > >> 1383 } > >> 1384 FREE_C_HEAP_ARRAY(char*, opath); > >> > >> This duplicated fragments is worth to refactor to a function. > >> Also a space is missed at the beginning of the comment. > >> > >> > >> Thanks, > >> Serguei > >> > >> > >> > >> On 7/31/19 02:01, Adam Farley8 wrote: > >> Hi All, > >> > >> Reviewers requested for the change below. > >> > >> @David - Agreed. Would you be prepared to sponsor the change? > >> > >> Bug: https://urldefense.proofpoint.com/v2/url? > u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8227021&d=DwID- > g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=xykJ0KLy9AKWO8zmC0amfR7xxUsvyKEjlf3y7WWOqvE&e= > >> Webrev: https://urldefense.proofpoint.com/v2/url? > u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.2_webrev_&d=DwID- > g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NvIza4VVWG3CiDhmQVmXsghH_4h_c5mFJbHwkCUcut0&e= > >> > >> Best Regards > >> > >> Adam Farley > >> IBM Runtimes > >> > >> P.S. Remembered to add the links this time. :) > >> > >> > >> David Holmes wrote on 30/07/2019 03:37:53: > >> > >> > From: David Holmes > >> > To: Adam Farley8 > >> > Cc: hotspot-dev at openjdk.java.net, serviceability-dev > >> > > >> > Date: 30/07/2019 03:38 > >> > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > >> > paths are longer than JVM_MAXPATHLEN > >> > > >> > Hi Adam, > >> > > >> > On 25/07/2019 3:57 am, Adam Farley8 wrote: > >> > > Hi David, > >> > > > >> > > Welcome back. :) > >> > > >> > Thanks. Sorry for the delay in getting back to this. > >> > > >> > I like .v2 as it is much simpler (notwithstanding freeing the already > >> > allocated arrays adds some complexity - thanks for fixing that). > >> > > >> > I'm still not sure we can't optimise things better for unchangeable > >> > properties like the boot libary path, but that's another RFE. > >> > > >> > Thanks, > >> > David > >> > > >> 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 stefan.karlsson at oracle.com Mon Aug 12 16:19:08 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 12 Aug 2019 18:19:08 +0200 Subject: RFR: 8229258: Make markOopDesc AllStatic In-Reply-To: <72567e47-3b52-8e30-ea6f-9a64fa043c07@redhat.com> References: <72567e47-3b52-8e30-ea6f-9a64fa043c07@redhat.com> Message-ID: <32ccb4ba-0500-2bf4-3761-63a6285f94dc@oracle.com> Hi Roman, Kim helped me figuring out how to get past the volatile issues I had with the class markWord { uintptr_t value; ... } version. So, I've created a version with that: https://cr.openjdk.java.net/~stefank/8229258/webrev.valueMarkWord.01/ I can go with either approach, so let me now what you all think. One drawback of this approach is all the places I had to add .value() calls to get the raw bits. That's mostly done in the compilers and in logging code. Inlined: On 2019-08-09 00:57, Roman Kennke wrote: > Hi Stefan, > > Awesome work! Thanks. :) > > I have a few comments: > > - You're going to need this patch on top of yours to keep Shenandoah in > shape: :-) > http://cr.openjdk.java.net/~rkennke/8229258-shenandoah/webrev.00/ Thanks. > > - Would be good to get as many affected platforms tested as possible. > There are changes like the ones in Shenandoah above that are not easy to > catch by grepping. Maybe reach out to folks who are known to regularily > build fancy platforms like SAP, Bellsoft,.. ? I agree. When we've decided what approach to take, we might want to explicitly ping them. > > - There are a few places where alignment of comments get messed up, e.g.: > > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp: > > ld(mark_word, oopDesc::mark_offset_in_bytes(), obj); // > Reload in transaction, conflicts need to be tracked. > - andi(R0, mark_word, markOopDesc::biased_lock_mask_in_place); // look > at 3 lock bits > - cmpwi(flag, R0, markOopDesc::unlocked_value); // bits > = 001 unlocked > + andi(R0, mark_word, MarkWord::biased_lock_mask_in_place); // look at > 3 lock bits > + cmpwi(flag, R0, MarkWord::unlocked_value); // bits = > 001 unlocked > beq(flag, DONE_LABEL); // all > done if unlocked > > I haven't collected all those places (if any more), but would be good if > you could sweep over the patch and fix those. I haven't done that yet, but will do it. > > - I agree with Coleen that markWord vs. MarkWord is a bit confusing. Not > sure what to do though. > > - I know it would probably disturb even more code, but shouldn't the > files markOop.* be renamed to markWord.* ? > > - The changes concerning SA, Graal and JRF *look* ok to me, but I don't > feel qualified to ack them. Would be good to get someone to review those parts ... Thanks for looking at this, StefanK > > > Thanks, > Roman > > >> Hi all, >> >> Please review this patch to make markOopDesc AllStatic. >> >> https://cr.openjdk.java.net/~stefank/8229258/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8229258 >> >> From the RFE: >> >> I want to change/rename markOop and markOopDesc >> >> Today markOopDescs inherits from oopDesc even though they are not >> oopDescs (Java objects): >> ?`class markOopDesc : public oopDesc {` >> >> This is very confusing to new-comers (and probably to old-timers as well). >> >> A simple fix would be to break the inheritance and do the following rename: >> markOopDesc -> MarkWord >> markOop -> markWord >> >> However, there are more dubious code in this area. markOopDescs are >> created and used like this: >> >> ``` >> class oopDesc { >> ... >> ? volatile markOop _mark; >> ... >> markOop? oopDesc::mark_raw()? const { return _mark; } >> ... >> // Usage >> obj->mark_raw()->is_marked() >> ... >> // Implementation >> ? bool is_marked()?? const { >> ??? return (mask_bits(value(), lock_mask_in_place) == marked_value); >> ? } >> ... >> // Implementation >> ? bool is_being_inflated() const { return (value() == 0); } >> ... >> // Implementation of markOopDesc::value() >> ? uintptr_t value() const { return (uintptr_t) this; } >> ``` >> >> Remember, _mark is an arbitrary bit pattern describing the object. We >> treat it as if it were a pointer to a markOopDesc object, but it's not >> pointing to such an object. While using that (weird) pointer we call >> value() and extract it's bit pattern to be used for further bit pattern >> checking functions. AFAICT, this is also undefined behavior. At least >> is_being_inflated() const is effectively 'return (uintptr_t) this == >> NULL'. This UB was recently discussed here: >> ?https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-July/038704.html >> ?https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-July/038712.html >> >> I propose that we change MarkWord (markOopDesc) to be an AllStatic class >> instead and get rid of this (ab)use of the markWord (markOop) pointer. >> >> The patch is large but mostly straight forward. However, there is some >> Java code that would need some extra scrutiny: SA and JVMCI. >> >> Tested with tier1-3. >> >> Coleen has asked for file rename from markOop.hpp to markWord.hpp. I'd >> like to do that as a separate RFE when/if this patch gets accepted. >> >> Thanks, >> StefanK >> From dean.long at oracle.com Mon Aug 12 18:37:49 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 12 Aug 2019 11:37:49 -0700 Subject: RFR: 8229352: Use of an unitialized register in 32-bit ARM template interpreter In-Reply-To: <20190811065555.2A0A13074FB@aojmv0009> References: <20190716100738.EFA3E2E2022@aojmv0009> <20190811065555.2A0A13074FB@aojmv0009> Message-ID: Looks OK, but after the Condy change, the label "Long" might be better named "NotDouble". dl On 8/10/19 11:54 PM, christoph.goettschkes at microdoc.com wrote: > Hello, > > could someone please review the changes for > https://bugs.openjdk.java.net/browse/JDK-8229352 > > webrev: http://cr.openjdk.java.net/~bulasevich/8229352/webrev.00/ > > The template interpreter for 32-bit arm generates code which accesses the > uninitialized register Rtemp if the platform is softfp for the ldc2_w > bytecode. > Because of that, loading a long constant might take the slow path and call > into the runtime. In addition, loading a double constant might take the > wrong path and not call into the runtime, but load it as if it would be of > type long (never seen in real life). > > I executed the tier1 tests of the hotspot JTreg test group and could not > identify any regressions. Some tests were failing because of insufficient > memory on the target platform. > > Thanks, > Christoph > > "hotspot-dev" wrote on 2019-07-16 > 12:05:59: > >> From: christoph.goettschkes at microdoc.com >> To: hotspot-dev at openjdk.java.net >> Date: 2019-07-16 12:08 >> Subject: [PATCH] Use of an unitialized register in 32-bit ARM template > interpreter >> Sent by: "hotspot-dev" >> >> Hello, >> >> while working with the OpenJDK 11 on a 32-bit ARMv7-A platform, I > noticed >> something weird in the template interpreter, regarding the template for >> the bytecode instruction ldc2_w. >> >> The type check for the operand is only done correctly if the ABI is a >> hard-float one. For soft-float, the check is done wrong, using an >> uninitialized register Rtemp. Please see the following diff: >> >> diff -r 327d5994b2fb src/hotspot/cpu/arm/templateTable_arm.cpp >> --- a/src/hotspot/cpu/arm/templateTable_arm.cpp Tue Mar 12 11:13:39 > 2019 -0400 >> +++ b/src/hotspot/cpu/arm/templateTable_arm.cpp Tue Jul 16 11:22:14 > 2019 +0200 >> @@ -515,36 +515,37 @@ >> void TemplateTable::ldc2_w() { >> transition(vtos, vtos); >> const Register Rtags = R2_tmp; >> const Register Rindex = R3_tmp; >> const Register Rcpool = R4_tmp; >> const Register Rbase = R5_tmp; >> >> __ get_unsigned_2_byte_index_at_bcp(Rindex, 1); >> >> __ get_cpool_and_tags(Rcpool, Rtags); >> const int base_offset = ConstantPool::header_size() * wordSize; >> const int tags_offset = Array::base_offset_in_bytes(); >> >> __ add(Rbase, Rcpool, AsmOperand(Rindex, lsl, LogBytesPerWord)); >> >> + // get type from tags >> + __ add(Rtemp, Rtags, tags_offset); >> + __ ldrb(Rtemp, Address(Rtemp, Rindex)); >> + >> Label Condy, exit; >> #ifdef __ABI_HARD__ >> Label Long; >> - // get type from tags >> - __ add(Rtemp, Rtags, tags_offset); >> - __ ldrb(Rtemp, Address(Rtemp, Rindex)); >> __ cmp(Rtemp, JVM_CONSTANT_Double); >> __ b(Long, ne); >> __ ldr_double(D0_tos, Address(Rbase, base_offset)); >> >> __ push(dtos); >> __ b(exit); >> __ bind(Long); >> #endif >> >> __ cmp(Rtemp, JVM_CONSTANT_Long); >> __ b(Condy, ne); >> #ifdef AARCH64 >> __ ldr(R0_tos, Address(Rbase, base_offset)); >> #else >> __ ldr(R0_tos_lo, Address(Rbase, base_offset + 0 * wordSize)); >> >> If the check for the type of the operand is done correctly, the call to >> InterpreterRuntime::resolve_ldc should never happen. Currently, for > 32-bit >> soft-float arm, InterpreterRuntime::resolve_ldc is called if the operand >> for ldc2_w is of type long. >> >> Also, I find it weird that the "condy_helper" code is genarted for the >> ldc2_w bytecode instruction on 32-bit hard-float arm (and also on x86). >> Aren't the only two valid types for ldc2_w long and double? >> >> -- Christoph >> From shade at redhat.com Mon Aug 12 18:53:46 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 12 Aug 2019 20:53:46 +0200 Subject: RFR: 8229352: Use of an unitialized register in 32-bit ARM template interpreter In-Reply-To: References: <20190716100738.EFA3E2E2022@aojmv0009> <20190811065555.2A0A13074FB@aojmv0009> Message-ID: <687d97ce-be7c-3598-3071-6070fa68d5d0@redhat.com> On 8/12/19 8:37 PM, dean.long at oracle.com wrote: > Looks OK, but after the Condy change, the label "Long" might be better named "NotDouble". +1 > On 8/10/19 11:54 PM, christoph.goettschkes at microdoc.com wrote: >> Hello, >> >> could someone please review the changes for >> https://bugs.openjdk.java.net/browse/JDK-8229352 >> >> webrev: http://cr.openjdk.java.net/~bulasevich/8229352/webrev.00/ Looks good to me. Note: changed the typo in "uninitialized" in issue synopsis, please make sure changeset metadata reflects that. -- Thanks, -Aleksey From david.holmes at oracle.com Mon Aug 12 22:32:14 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 13 Aug 2019 08:32:14 +1000 Subject: RFR: JDK-8227021: VM fails if any sun.boot.library.path paths are longer than JVM_MAXPATHLEN In-Reply-To: References: <25234969-2215-57e9-d8c5-d97b5669ebb1@oracle.com> <5ba808b0-ae52-0d0a-b84b-fc34df35475d@oracle.com> <025da83a-6569-f6ac-7590-5b200ed2344f@oracle.com> <8e62fc61-b46b-0033-f182-cb4a2dbf92fd@oracle.com> Message-ID: Looks fine. Thanks, David On 13/08/2019 1:19 am, Adam Farley8 wrote: > Hi David, > > Changes made as requested: > http://cr.openjdk.java.net/~afarley/8227021.4/webrev > > Best Regards > > Adam Farley > IBM Runtimes > > > David Holmes wrote on 12/08/2019 04:55:36: > >> From: David Holmes >> To: Adam Farley8 , >> "serguei.spitsyn at oracle.com" >> Cc: hotspot-dev at openjdk.java.net >> Date: 12/08/2019 04:56 >> Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path >> paths are longer than JVM_MAXPATHLEN >> >> Hi Adam, >> >> On 10/08/2019 2:47 am, Adam Farley8 wrote: >> > Hi Serguei, David, >> > >> > My turn to apologise for the delay. :) >> > >> > I've modified the code as per Serguei's request. Take a look and let me >> > know if this is the sort of thing you were thinking of. >> > >> > Webrev: https://urldefense.proofpoint.com/v2/url? >> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.3_webrev_&d=DwID- >> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- >> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- >> yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=L19aeFXoR9JIO62QRPFzZObIU8RbhpCtXSvUibD2ISk&e= >> >> I'd prefer to see the helper just as a file static function rather than >> adding it to the os class. >> >> + ?* supplied array of arrays of chars (a), where n >> >> I assume (a) is meant to refer to the parameter, but you actually called >> it arrayarray. I think "a" or "arr" would suffice. >> >> Thanks, >> David >> >> > Best Regards >> > >> > Adam Farley >> > IBM Runtimes >> > >> > >> > "serguei.spitsyn at oracle.com" wrote on >> > 31/07/2019 17:18:05: >> > >> >> From: "serguei.spitsyn at oracle.com" >> >> To: Adam Farley8 , ?David Holmes >> >> >> >> Cc: serviceability-dev , >> >> hotspot-dev at openjdk.java.net >> >> Date: 31/07/2019 17:18 >> >> Subject: Re: RFR: JDK-8227021: ?VM fails if any sun.boot.library.path >> >> paths are longer than JVM_MAXPATHLEN >> >> >> >> Hi Adam, >> >> >> >> It looks Okay to me. >> >> >> >> A couple of minor comments. >> >> >> >> https://urldefense.proofpoint.com/v2/url? >> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021. >> 2_webrev_src_hotspot_&d=DwID-g&c=jf_iaSHvJObTbx- >> siA1ZOg&r=P5m8KWUXJf-CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- >> yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NL6tYuwwDod3DSmj-1ztxAywpO8L52HEyO0wvTR05bs&e= >> >> share/runtime/os.cpp.frames.html >> > >> >> 1362 ? ? ? //release ?allocated storage before exiting the vm >> >> 1363 ? ? ? while (i > 0) { >> >> 1364 ? ? ? ? ? i--; >> >> 1365 ? ? ? ? ? if (opath[i] != NULL) { >> >> 1366 ? ? ? ? ? ? FREE_C_HEAP_ARRAY(char, ?opath[i]); >> >> 1367 ? ? ? ? ? } >> >> 1368 ? ? ? } >> >> 1369 ? ? ? FREE_C_HEAP_ARRAY(char*, opath); >> >> >> >> 1377 ? ? ? //release allocated storage before returning ?null >> >> 1378 ? ? ? while (i > 0) { >> >> 1379 ? ? ? ? ? i--; >> >> 1380 ? ? ? ? ? if (opath[i] != NULL) { >> >> 1381 ? ? ? ? ? ? FREE_C_HEAP_ARRAY(char, ?opath[i]); >> >> 1382 ? ? ? ? ? } >> >> 1383 ? ? ? } >> >> 1384 ? ? ? FREE_C_HEAP_ARRAY(char*, opath); >> >> >> >> This duplicated fragments is worth to refactor to a function. >> >> Also a space is missed at the beginning of the comment. >> >> >> >> >> >> Thanks, >> >> Serguei >> >> >> >> >> >> >> >> On 7/31/19 02:01, Adam Farley8 wrote: >> >> Hi All, >> >> >> >> Reviewers requested for the change below. >> >> >> >> @David - Agreed. Would you be prepared to sponsor the change? >> >> >> >> Bug: https://urldefense.proofpoint.com/v2/url? >> u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8227021&d=DwID- >> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- >> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- >> yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=xykJ0KLy9AKWO8zmC0amfR7xxUsvyKEjlf3y7WWOqvE&e= >> >> Webrev: https://urldefense.proofpoint.com/v2/url? >> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.2_webrev_&d=DwID- >> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- >> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- >> yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NvIza4VVWG3CiDhmQVmXsghH_4h_c5mFJbHwkCUcut0&e= >> >> >> >> Best Regards >> >> >> >> Adam Farley >> >> IBM Runtimes >> >> >> >> P.S. Remembered to add the links this time. :) >> >> >> >> >> >> David Holmes wrote on 30/07/2019 03:37:53: >> >> >> >> > From: David Holmes >> >> > To: Adam Farley8 >> >> > Cc: hotspot-dev at openjdk.java.net, serviceability-dev >> >> > >> >> > Date: 30/07/2019 03:38 >> >> > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path >> >> > paths are longer than JVM_MAXPATHLEN >> >> > >> >> > Hi Adam, >> >> > >> >> > On 25/07/2019 3:57 am, Adam Farley8 wrote: >> >> > > Hi David, >> >> > > >> >> > > Welcome back. :) >> >> > >> >> > Thanks. Sorry for the delay in getting back to this. >> >> > >> >> > I like .v2 as it is much simpler (notwithstanding freeing the ?already >> >> > allocated arrays adds some complexity - thanks for fixing that). >> >> > >> >> > I'm still not sure we can't optimise things better for unchangeable >> >> > properties like the boot libary path, but that's another RFE. >> >> > >> >> > Thanks, >> >> > David >> >> > >> >> 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 rramakrishna at twitter.com Tue Aug 13 01:19:14 2019 From: rramakrishna at twitter.com (Ramki Ramakrishna) Date: Mon, 12 Aug 2019 18:19:14 -0700 Subject: Fwd: Buffered Logging? In-Reply-To: References: Message-ID: (Resent... Apologies to anyone who might see duplicates. There was an issue with my membership in the list which, I am guessing, has now been resolved.) ---------- Forwarded message ---------- From: Ramki Ramakrishna To: hotspot-dev at openjdk.java.net Cc: "Liu, Xin" , "Mathiske, Bernd" , "Hohensee, Paul" , John Coomes , Tony Printezis Bcc: Date: Mon, 12 Aug 2019 15:48:17 -0700 Subject: Buffered Logging? In the JDK 7 time-frame, some folks noticed much longer than expected pauses that seemed to coincide with GC logging in the midst of a GC safepoint. In that setup, the GC logs were going to a disk file (these were often useful for post-mortem analyses) rather than to a RAM-based tmpfs which had been the original design center assumption. The vicissitudes of the dirty page flushing policy in Linux when IO load on the machine (not necessarily the JVM process doing the logging) could affect the length and duration of these inline logging stalls. A buffered logging scheme was then implemented by us (and independently by others) which we have used successfully to date to avoid these pauses in high i/o multi-tenant environments. We have recently ported the OpenJDK 8u based scheme past the Unified Logging related changes and have been using it on OpenJDK 11u. In various fora, some of us have heard people express an interest in such an implementation. Would there be appetite for this in openjdk (there are some differences between our scheme in OpenJDK 8u and their subsequent post-Unified-Logging port to OpenJDK 11)? If so, we'd like to open a JBS ticket, attach some patches rebased to current OpenJDK tip, and start preparing a webrev for discussion with a view to possible upstreaming if it converges past review/discussion/debate. PS: In recent discussion at the JVMLS, mention was made of something that might be similar in support of JFR streaming, so our rebase to tip and familiarization with any JFR-associated buffered logging might well make this easier or, possibly, moot. Thoughts, questions, comments, feedback? -- ramki -- JVM Team, Platform Engineering, Twitter (San Francisco) From kim.barrett at oracle.com Tue Aug 13 02:37:18 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 12 Aug 2019 22:37:18 -0400 Subject: RFR: 8229258: Make markOopDesc AllStatic In-Reply-To: <32ccb4ba-0500-2bf4-3761-63a6285f94dc@oracle.com> References: <72567e47-3b52-8e30-ea6f-9a64fa043c07@redhat.com> <32ccb4ba-0500-2bf4-3761-63a6285f94dc@oracle.com> Message-ID: <5D2F6746-EB37-41C0-B282-5ACEC59A5A81@oracle.com> > On Aug 12, 2019, at 12:19 PM, Stefan Karlsson wrote: > > Hi Roman, > > Kim helped me figuring out how to get past the volatile issues I had with the class markWord { uintptr_t value; ... } version. So, I've created a version with that: > > https://cr.openjdk.java.net/~stefank/8229258/webrev.valueMarkWord.01/ > > I can go with either approach, so let me now what you all think. > > One drawback of this approach is all the places I had to add .value() calls to get the raw bits. That's mostly done in the compilers and in logging code. Well, that was a bit of a slog. I've reviewed all of the C++ changes. I haven't looked at the Java changes at all. Let me know if you need me to do so. I like the approach. I think there are some remaining issues, but I think this mostly looks good. First a few broader issues: (1) I found one area of code where I thought there might be some significant cleanup needed, but then realized it was all CMS-specific, so I'm not going to go into that. Better to just do the minimum for now for this change, and delete that code soon. (2) You mentioned the need for .value() calls as a drawback. I think it's actually overall beneficial. I kept rough track while reviewing, and I think the majority (by about 2:1) of those calls have their result cast to intptr_t (or intx, or long(!) in 64bit-specific code). I think most/all of those casts could be removed. In the baseline code we instead had reinterpret_casts of a pointer to an intptr_t. Some of the remaining calls to .value() are then subject to a cast or conversion to some pointer type. Perhaps a "to_pointer" operation should be provided for these? (And maybe prevent non-use of to_pointer by poisoning template operator T*().) (3) I think all explicit type conversions to markWord (e.g. using a C-style cast to markWord) should be eliminated. In the old code we have three cases: (a) Many were reinterpret_casts of an integral value to markOopDesc*. (b) Some of the remaining were pointer to markOopDesc* casts; either static (down) casts where the value is void* or pointer to oopDesc* or a derivative. (c) Remainder were reinterpret_cast for other pointer conversions conversions. With markWord (a) are now conversions using the constructor, and are better written using constructor syntax. The pointer to markWord conversions should be using markWord::from_pointer. (We might enforce that by poisoning markWord(const volatile void*).) (4) I didn't bother to note misaligned comments and such; you've already said you'll deal with these later, assuming this is the approach taken. And now a few more specific issues: ------------------------------------------------------------------------------ [pre-existing, optional change] assert in all MacroAssembler::biased_locking_enter assert(markWord::age_shift == markWord::lock_bits + markWord::biased_lock_bits, "biased locking makes assumptions about bit layout"); I think these can all be STATIC_ASSERTs. ------------------------------------------------------------------------------ src/hotspot/share/oops/markOop.hpp 341 markWord clear_lock_bits() { return markWord(value() & ~lock_mask_in_place); } I think this should be returning some kind of pointer, and not a markWord. That would also remove the need for the cast to void* of the .value() in MarkWord::decode_pointer(). The kind of pointer for the result should be oopDesc* ? Also removes the need for the reinterpret_cast here: src/hotspot/share/gc/shenandoah/shenandoahForwarding.inline.hpp 58 return oop(reinterpret_cast(old_mark->clear_lock_bits())); 66 return oop(reinterpret_cast(prev_mark->clear_lock_bits())); ------------------------------------------------------------------------------ [pre-existing, not your problem, but I can't help but question this.] src/hotspot/share/jfr/leakprofiler/utilities/saveRestore.cpp 51 MarkWordContext::MarkWordContext(const MarkWordContext& rhs) : _obj(NULL), _mark_word(0) { 52 swap(const_cast(rhs)); 53 } A copy constructor that modifies the source for the copy? That seems very weird and confusing. ------------------------------------------------------------------------------ src/hotspot/share/memory/heap.cpp 418 d Stray character. ------------------------------------------------------------------------------ src/hotspot/share/oops/oop.cpp Comment needs some updating: 108 // Header verification: the mark is typically non-NULL. If we're 109 // at a safepoint, it must not be null. ------------------------------------------------------------------------------ src/hotspot/share/oops/oop.inline.hpp. 46 markWord oopDesc::mark() const { 47 uintptr_t v = HeapAccess::load_at(as_oop(), mark_offset_in_bytes()); 48 return markWord(v); 49 } I was wondering why this wasn't just: markWord oopDesc::mark() const { return HeapAccess::load_at(as_oop(), mark_offset_in_bytes()); } But that would hit the (intentionally) undefined copy-from-volatile constructor for markWord. I think it would work if the Access API (in particular, LoadAtProxy) paid attention to PrimitiveConversion::Translate handlers. But we wouldn't want it to pay attention to the translators for oop and its subclasses. So without more careful thought than I want to apply right now, I think the webrev definition is the way to go. And if Access loads paid attention to translate handlers, probably stores should too, which would remove the need for the value() call here: 71 void oopDesc::release_set_mark(markWord m) { 72 HeapAccess::store_at(as_oop(), mark_offset_in_bytes(), m.value()); 73 } Something to think about for the future? ------------------------------------------------------------------------------ src/hotspot/share/runtime/basicLock.cpp 31 markWord moop = displaced_header(); Variable name should be updated. ------------------------------------------------------------------------------ From david.holmes at oracle.com Tue Aug 13 03:26:06 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 13 Aug 2019 13:26:06 +1000 Subject: RFR (S): 8228857: Refactor PlatformMonitor into PlatformMutex and PlatformMonitor In-Reply-To: <9c8ea98c-a2cd-a832-d977-678a4de379b1@oracle.com> References: <32C9F58D-FA84-4A18-9A43-86DE2F8AD88E@oracle.com> <85649d80-f85e-4da0-dd4c-db148b33d5e8@oracle.com> <9c8ea98c-a2cd-a832-d977-678a4de379b1@oracle.com> Message-ID: Hi Per, Are you okay with the latest version of this change? Thanks, David On 9/08/2019 4:25 pm, David Holmes wrote: > Okay here is v2 with Kim's non-copyable adjustments and an alternate > approach to the "impl" class so that the PlatformMutex doesn't have to > pay for the unused pthread_cond_t. Trade-off in this scheme is that > PlatformMonitor now has two "impl" pointers so consumes more space. > > Also made comment changes suggested by Dan. > > http://cr.openjdk.java.net/~dholmes/8228857/webrev.v2/ > > Thanks, > David > ----- From navy.xliu at gmail.com Tue Aug 13 05:50:36 2019 From: navy.xliu at gmail.com (Liu Xin) Date: Mon, 12 Aug 2019 22:50:36 -0700 Subject: HotSpot compilation latency In-Reply-To: References: <48406668-4d97-e66b-ee6b-b57fed23a56d@oracle.com> <829bf123-ef7e-f854-22ca-180d45ec3ba0@oracle.com> Message-ID: Hi, Stefan, There're 2 counters: invocation and back-edge branch. check out methodData.hpp. InvocationCounter _invocation_counter; InvocationCounter _backedge_counter; Don't you think it's easier to count discrete events than measure elapsed time? Indeed, time is more accurate profile data in runtime. My guess is that the instrumentation code will be very expensive. @Tobias, if I use an external profiler to measure runtime of methods, is that possible JIT or AOT compilers can make use those profile data? thanks, --lx On Mon, Aug 12, 2019 at 7:39 AM Stefan Reich < stefan.reich.maker.of.eye at googlemail.com> wrote: > Huh. So the compilation results (which method is compiled and when in the > program flow) should typically not very between machines of different > speed. > > (For a single-threaded program.) > > That's interesting, I always thought there was a time component involved > ("profile for 100 ms" or something). Optimization makes more sense without > it I guess. > > Thanks > > On Mon, 12 Aug 2019 at 14:52, Tobias Hartmann > wrote: > > > > > On 12.08.19 14:41, Stefan Reich wrote: > > > So none of this is dependent on clock time at all? > > > > Yes, exactly. > > > > Best regards, > > Tobias > > > > > -- > Stefan Reich > BotCompany.de // Java-based operating systems > From tobias.hartmann at oracle.com Tue Aug 13 05:53:13 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 13 Aug 2019 07:53:13 +0200 Subject: HotSpot compilation latency In-Reply-To: References: <48406668-4d97-e66b-ee6b-b57fed23a56d@oracle.com> <829bf123-ef7e-f854-22ca-180d45ec3ba0@oracle.com> Message-ID: On 12.08.19 16:39, Stefan Reich wrote: > Huh. So the compilation results (which method is compiled and when in the program flow) should > typically not very between machines of different speed. > > (For a single-threaded program.) In theory, yes, but not in practice. There are many factors that cause non deterministic behavior. For example, multiple VM threads that are competing (GC threads, compiler threads, ...), compilation of one compiler thread affecting other compilations (inlining, profiling, ...), or even an application that is not deterministic itself. All this affects which method is compiled at what time in the program flow. > That's interesting, I always thought there was a time component involved ("profile for 100 ms" or > something). Optimization makes more sense without it I guess. Yes, wall clock time does not say anything about how complete the profile information is that we gathered during that time (the method might not have been executed/profiled at all due to high load on the system). Best regards, Tobias From christoph.goettschkes at microdoc.com Tue Aug 13 06:27:45 2019 From: christoph.goettschkes at microdoc.com (christoph.goettschkes at microdoc.com) Date: Tue, 13 Aug 2019 08:27:45 +0200 Subject: RFR: 8229352: Use of an unitialized register in 32-bit ARM template interpreter In-Reply-To: <687d97ce-be7c-3598-3071-6070fa68d5d0@redhat.com> References: <20190716100738.EFA3E2E2022@aojmv0009> <20190811065555.2A0A13074FB@aojmv0009> <687d97ce-be7c-3598-3071-6070fa68d5d0@redhat.com> Message-ID: Thanks for your feedback. Here is a new webrev with the proposed change applied: http://cr.openjdk.java.net/~bulasevich/8229352/webrev.01/ I tested the new changes with a subset of the hotspot tier1 JTreg test group. Does this look fine to you? -- Christoph "hotspot-dev" wrote on 2019-08-12 20:53:46: > From: Aleksey Shipilev > To: dean.long at oracle.com, hotspot-dev at openjdk.java.net > Date: 2019-08-12 20:54 > Subject: Re: RFR: 8229352: Use of an unitialized register in 32-bit ARM > template interpreter > Sent by: "hotspot-dev" > > On 8/12/19 8:37 PM, dean.long at oracle.com wrote: > > Looks OK, but after the Condy change, the label "Long" might be better named > "NotDouble". > > +1 > > > On 8/10/19 11:54 PM, christoph.goettschkes at microdoc.com wrote: > >> Hello, > >> > >> could someone please review the changes for > >> https://bugs.openjdk.java.net/browse/JDK-8229352 > >> > >> webrev: http://cr.openjdk.java.net/~bulasevich/8229352/webrev.00/ > > Looks good to me. > > Note: changed the typo in "uninitialized" in issue synopsis, please make sure > changeset metadata > reflects that. > > -- > Thanks, > -Aleksey > From tobias.hartmann at oracle.com Tue Aug 13 06:44:49 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 13 Aug 2019 08:44:49 +0200 Subject: HotSpot compilation latency In-Reply-To: References: <48406668-4d97-e66b-ee6b-b57fed23a56d@oracle.com> <829bf123-ef7e-f854-22ca-180d45ec3ba0@oracle.com> Message-ID: <14a3baa9-93ee-5e60-a059-caed0a39575a@oracle.com> On 13.08.19 07:50, Liu Xin wrote: > @Tobias,? > if I use an external profiler to measure runtime of methods, is that possible JIT or AOT compilers > can make use those profile data? No, that's currently not possible. But the JWarmup proposal (on this list) provides a similar functionality. Best regards, Tobias From navy.xliu at gmail.com Tue Aug 13 06:58:18 2019 From: navy.xliu at gmail.com (Liu Xin) Date: Mon, 12 Aug 2019 23:58:18 -0700 Subject: HotSpot compilation latency In-Reply-To: <14a3baa9-93ee-5e60-a059-caed0a39575a@oracle.com> References: <48406668-4d97-e66b-ee6b-b57fed23a56d@oracle.com> <829bf123-ef7e-f854-22ca-180d45ec3ba0@oracle.com> <14a3baa9-93ee-5e60-a059-caed0a39575a@oracle.com> Message-ID: hi, Tobias, Got it. I will take a look JWarmup. Thanks! --lx On Mon, Aug 12, 2019 at 11:44 PM Tobias Hartmann wrote: > > On 13.08.19 07:50, Liu Xin wrote: > > @Tobias, > > if I use an external profiler to measure runtime of methods, is that > possible JIT or AOT compilers > > can make use those profile data? > > No, that's currently not possible. But the JWarmup proposal (on this list) > provides a similar > functionality. > > Best regards, > Tobias > From per.liden at oracle.com Tue Aug 13 09:34:08 2019 From: per.liden at oracle.com (Per Liden) Date: Tue, 13 Aug 2019 11:34:08 +0200 Subject: RFR (S): 8228857: Refactor PlatformMonitor into PlatformMutex and PlatformMonitor In-Reply-To: References: <32C9F58D-FA84-4A18-9A43-86DE2F8AD88E@oracle.com> <85649d80-f85e-4da0-dd4c-db148b33d5e8@oracle.com> <9c8ea98c-a2cd-a832-d977-678a4de379b1@oracle.com> Message-ID: <5424afa2-0636-5fd9-c2e3-218ea6d073e2@oracle.com> Hi David, On 8/13/19 5:26 AM, David Holmes wrote: > Hi Per, > > Are you okay with the latest version of this change? Yep, I'm ok with that. It seems to be the best we can do for now. cheers, Per > > Thanks, > David > > On 9/08/2019 4:25 pm, David Holmes wrote: >> Okay here is v2 with Kim's non-copyable adjustments and an alternate >> approach to the "impl" class so that the PlatformMutex doesn't have to >> pay for the unused pthread_cond_t. Trade-off in this scheme is that >> PlatformMonitor now has two "impl" pointers so consumes more space. >> >> Also made comment changes suggested by Dan. >> >> http://cr.openjdk.java.net/~dholmes/8228857/webrev.v2/ >> >> Thanks, >> David >> ----- From david.holmes at oracle.com Tue Aug 13 10:24:11 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 13 Aug 2019 20:24:11 +1000 Subject: RFR (S): 8228857: Refactor PlatformMonitor into PlatformMutex and PlatformMonitor In-Reply-To: <5424afa2-0636-5fd9-c2e3-218ea6d073e2@oracle.com> References: <32C9F58D-FA84-4A18-9A43-86DE2F8AD88E@oracle.com> <85649d80-f85e-4da0-dd4c-db148b33d5e8@oracle.com> <9c8ea98c-a2cd-a832-d977-678a4de379b1@oracle.com> <5424afa2-0636-5fd9-c2e3-218ea6d073e2@oracle.com> Message-ID: <1cb57e69-f1eb-497b-aff0-e4c3235a83eb@oracle.com> On 13/08/2019 7:34 pm, Per Liden wrote: > Hi David, > > On 8/13/19 5:26 AM, David Holmes wrote: >> Hi Per, >> >> Are you okay with the latest version of this change? > > Yep, I'm ok with that. It seems to be the best we can do for now. Great! Thanks. David > cheers, > Per > >> >> Thanks, >> David >> >> On 9/08/2019 4:25 pm, David Holmes wrote: >>> Okay here is v2 with Kim's non-copyable adjustments and an alternate >>> approach to the "impl" class so that the PlatformMutex doesn't have >>> to pay for the unused pthread_cond_t. Trade-off in this scheme is >>> that PlatformMonitor now has two "impl" pointers so consumes more space. >>> >>> Also made comment changes suggested by Dan. >>> >>> http://cr.openjdk.java.net/~dholmes/8228857/webrev.v2/ >>> >>> Thanks, >>> David >>> ----- From stefan.karlsson at oracle.com Tue Aug 13 10:42:02 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 13 Aug 2019 12:42:02 +0200 Subject: RFR: 8229258: Make markOopDesc AllStatic In-Reply-To: <5D2F6746-EB37-41C0-B282-5ACEC59A5A81@oracle.com> References: <72567e47-3b52-8e30-ea6f-9a64fa043c07@redhat.com> <32ccb4ba-0500-2bf4-3761-63a6285f94dc@oracle.com> <5D2F6746-EB37-41C0-B282-5ACEC59A5A81@oracle.com> Message-ID: Hi Kim, I've addressed some of you comments and did an initial pass over the patch to clean up some alignment issues: http://cr.openjdk.java.net/~stefank/8229258/webrev.valueMarkWord.02.delta http://cr.openjdk.java.net/~stefank/8229258/webrev.valueMarkWord.02/ Thanks, StefanK On 2019-08-13 04:37, Kim Barrett wrote: >> On Aug 12, 2019, at 12:19 PM, Stefan Karlsson wrote: >> >> Hi Roman, >> >> Kim helped me figuring out how to get past the volatile issues I had with the class markWord { uintptr_t value; ... } version. So, I've created a version with that: >> >> https://cr.openjdk.java.net/~stefank/8229258/webrev.valueMarkWord.01/ >> >> I can go with either approach, so let me now what you all think. >> >> One drawback of this approach is all the places I had to add .value() calls to get the raw bits. That's mostly done in the compilers and in logging code. > > Well, that was a bit of a slog. I've reviewed all of the C++ changes. > I haven't looked at the Java changes at all. Let me know if you need > me to do so. > > I like the approach. I think there are some remaining issues, but I > think this mostly looks good. First a few broader issues: > > (1) I found one area of code where I thought there might be some > significant cleanup needed, but then realized it was all CMS-specific, > so I'm not going to go into that. Better to just do the minimum for > now for this change, and delete that code soon. > > (2) You mentioned the need for .value() calls as a drawback. I think > it's actually overall beneficial. I kept rough track while reviewing, > and I think the majority (by about 2:1) of those calls have their > result cast to intptr_t (or intx, or long(!) in 64bit-specific code). > I think most/all of those casts could be removed. In the baseline code > we instead had reinterpret_casts of a pointer to an intptr_t. > > Some of the remaining calls to .value() are then subject to a cast or > conversion to some pointer type. Perhaps a "to_pointer" operation > should be provided for these? (And maybe prevent non-use of to_pointer > by poisoning template operator T*().) > > (3) I think all explicit type conversions to markWord (e.g. using a > C-style cast to markWord) should be eliminated. In the old code we > have three cases: > > (a) Many were reinterpret_casts of an integral value to markOopDesc*. > > (b) Some of the remaining were pointer to markOopDesc* casts; either > static (down) casts where the value is void* or pointer to oopDesc* or > a derivative. > > (c) Remainder were reinterpret_cast for other pointer conversions > conversions. > > With markWord (a) are now conversions using the constructor, and are > better written using constructor syntax. The pointer to markWord > conversions should be using markWord::from_pointer. (We might enforce > that by poisoning markWord(const volatile void*).) > > (4) I didn't bother to note misaligned comments and such; you've > already said you'll deal with these later, assuming this is the > approach taken. > > And now a few more specific issues: > > ------------------------------------------------------------------------------ > [pre-existing, optional change] > > assert in all MacroAssembler::biased_locking_enter > assert(markWord::age_shift == markWord::lock_bits + markWord::biased_lock_bits, > "biased locking makes assumptions about bit layout"); > > I think these can all be STATIC_ASSERTs. > > ------------------------------------------------------------------------------ > src/hotspot/share/oops/markOop.hpp > 341 markWord clear_lock_bits() { return markWord(value() & ~lock_mask_in_place); } > > I think this should be returning some kind of pointer, and not a > markWord. That would also remove the need for the cast to void* of > the .value() in MarkWord::decode_pointer(). > > The kind of pointer for the result should be oopDesc* ? > > Also removes the need for the reinterpret_cast here: > src/hotspot/share/gc/shenandoah/shenandoahForwarding.inline.hpp > 58 return oop(reinterpret_cast(old_mark->clear_lock_bits())); > 66 return oop(reinterpret_cast(prev_mark->clear_lock_bits())); > > ------------------------------------------------------------------------------ > [pre-existing, not your problem, but I can't help but question this.] > > src/hotspot/share/jfr/leakprofiler/utilities/saveRestore.cpp > 51 MarkWordContext::MarkWordContext(const MarkWordContext& rhs) : _obj(NULL), _mark_word(0) { > 52 swap(const_cast(rhs)); > 53 } > > A copy constructor that modifies the source for the copy? That seems > very weird and confusing. > > ------------------------------------------------------------------------------ > src/hotspot/share/memory/heap.cpp > 418 d > > Stray character. > > ------------------------------------------------------------------------------ > src/hotspot/share/oops/oop.cpp > > Comment needs some updating: > 108 // Header verification: the mark is typically non-NULL. If we're > 109 // at a safepoint, it must not be null. > > ------------------------------------------------------------------------------ > src/hotspot/share/oops/oop.inline.hpp. > 46 markWord oopDesc::mark() const { > 47 uintptr_t v = HeapAccess::load_at(as_oop(), mark_offset_in_bytes()); > 48 return markWord(v); > 49 } > > I was wondering why this wasn't just: > > markWord oopDesc::mark() const { > return HeapAccess::load_at(as_oop(), mark_offset_in_bytes()); > } > > But that would hit the (intentionally) undefined copy-from-volatile > constructor for markWord. > > I think it would work if the Access API (in particular, LoadAtProxy) > paid attention to PrimitiveConversion::Translate handlers. But we > wouldn't want it to pay attention to the translators for oop and its > subclasses. > > So without more careful thought than I want to apply right now, I > think the webrev definition is the way to go. > > And if Access loads paid attention to translate handlers, probably > stores should too, which would remove the need for the value() call > here: > > 71 void oopDesc::release_set_mark(markWord m) { > 72 HeapAccess::store_at(as_oop(), mark_offset_in_bytes(), m.value()); > 73 } > > Something to think about for the future? > > ------------------------------------------------------------------------------ > src/hotspot/share/runtime/basicLock.cpp > 31 markWord moop = displaced_header(); > > Variable name should be updated. > > ------------------------------------------------------------------------------ > From adam.farley at uk.ibm.com Tue Aug 13 15:48:02 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Tue, 13 Aug 2019 16:48:02 +0100 Subject: RFR: JDK-8227021: VM fails if any sun.boot.library.path paths are longer than JVM_MAXPATHLEN In-Reply-To: References: <25234969-2215-57e9-d8c5-d97b5669ebb1@oracle.com> <5ba808b0-ae52-0d0a-b84b-fc34df35475d@oracle.com> <025da83a-6569-f6ac-7590-5b200ed2344f@oracle.com> <8e62fc61-b46b-0033-f182-cb4a2dbf92fd@oracle.com> Message-ID: Hi David, Since we have two positive reviews (yours and Serguei's), could you sponsor the change please? Best Regards Adam Farley IBM Runtimes David Holmes wrote on 12/08/2019 23:32:14: > From: David Holmes > To: Adam Farley8 > Cc: hotspot-dev at openjdk.java.net, "serguei.spitsyn at oracle.com" > > Date: 12/08/2019 23:32 > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > paths are longer than JVM_MAXPATHLEN > > Looks fine. > > Thanks, > David > > On 13/08/2019 1:19 am, Adam Farley8 wrote: > > Hi David, > > > > Changes made as requested: > > https://urldefense.proofpoint.com/v2/url? > u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.4_webrev&d=DwID- > g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=mZM8IR4e_zmrfcsF3XJjoGEMrZb4WtEL7Y6Ugd6Naqg&s=sZ2UKqqUIq0El- > RsqYz6jmTh4Q2UghwdrQX6of8Lw0E&e= > > > > Best Regards > > > > Adam Farley > > IBM Runtimes > > > > > > David Holmes wrote on 12/08/2019 04:55:36: > > > >> From: David Holmes > >> To: Adam Farley8 , > >> "serguei.spitsyn at oracle.com" > >> Cc: hotspot-dev at openjdk.java.net > >> Date: 12/08/2019 04:56 > >> Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > >> paths are longer than JVM_MAXPATHLEN > >> > >> Hi Adam, > >> > >> On 10/08/2019 2:47 am, Adam Farley8 wrote: > >> > Hi Serguei, David, > >> > > >> > My turn to apologise for the delay. :) > >> > > >> > I've modified the code as per Serguei's request. Take a look and let me > >> > know if this is the sort of thing you were thinking of. > >> > > >> > Webrev: https://urldefense.proofpoint.com/v2/url? > >> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.3_webrev_&d=DwID- > >> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > >> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > >> > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=L19aeFXoR9JIO62QRPFzZObIU8RbhpCtXSvUibD2ISk&e= > >> > >> I'd prefer to see the helper just as a file static function rather than > >> adding it to the os class. > >> > >> + * supplied array of arrays of chars (a), where n > >> > >> I assume (a) is meant to refer to the parameter, but you actually called > >> it arrayarray. I think "a" or "arr" would suffice. > >> > >> Thanks, > >> David > >> > >> > Best Regards > >> > > >> > Adam Farley > >> > IBM Runtimes > >> > > >> > > >> > "serguei.spitsyn at oracle.com" wrote on > >> > 31/07/2019 17:18:05: > >> > > >> >> From: "serguei.spitsyn at oracle.com" > >> >> To: Adam Farley8 , David Holmes > >> >> > >> >> Cc: serviceability-dev , > >> >> hotspot-dev at openjdk.java.net > >> >> Date: 31/07/2019 17:18 > >> >> Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > >> >> paths are longer than JVM_MAXPATHLEN > >> >> > >> >> Hi Adam, > >> >> > >> >> It looks Okay to me. > >> >> > >> >> A couple of minor comments. > >> >> > >> >> https://urldefense.proofpoint.com/v2/url? > >> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021. > >> 2_webrev_src_hotspot_&d=DwID-g&c=jf_iaSHvJObTbx- > >> siA1ZOg&r=P5m8KWUXJf-CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > >> > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NL6tYuwwDod3DSmj-1ztxAywpO8L52HEyO0wvTR05bs&e= > >> >> share/runtime/os.cpp.frames.html > >> > > >> >> 1362 //release allocated storage before exiting the vm > >> >> 1363 while (i > 0) { > >> >> 1364 i--; > >> >> 1365 if (opath[i] != NULL) { > >> >> 1366 FREE_C_HEAP_ARRAY(char, opath[i]); > >> >> 1367 } > >> >> 1368 } > >> >> 1369 FREE_C_HEAP_ARRAY(char*, opath); > >> >> > >> >> 1377 //release allocated storage before returning null > >> >> 1378 while (i > 0) { > >> >> 1379 i--; > >> >> 1380 if (opath[i] != NULL) { > >> >> 1381 FREE_C_HEAP_ARRAY(char, opath[i]); > >> >> 1382 } > >> >> 1383 } > >> >> 1384 FREE_C_HEAP_ARRAY(char*, opath); > >> >> > >> >> This duplicated fragments is worth to refactor to a function. > >> >> Also a space is missed at the beginning of the comment. > >> >> > >> >> > >> >> Thanks, > >> >> Serguei > >> >> > >> >> > >> >> > >> >> On 7/31/19 02:01, Adam Farley8 wrote: > >> >> Hi All, > >> >> > >> >> Reviewers requested for the change below. > >> >> > >> >> @David - Agreed. Would you be prepared to sponsor the change? > >> >> > >> >> Bug: https://urldefense.proofpoint.com/v2/url? > >> u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8227021&d=DwID- > >> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > >> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > >> > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=xykJ0KLy9AKWO8zmC0amfR7xxUsvyKEjlf3y7WWOqvE&e= > >> >> Webrev: https://urldefense.proofpoint.com/v2/url? > >> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.2_webrev_&d=DwID- > >> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > >> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > >> > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NvIza4VVWG3CiDhmQVmXsghH_4h_c5mFJbHwkCUcut0&e= > >> >> > >> >> Best Regards > >> >> > >> >> Adam Farley > >> >> IBM Runtimes > >> >> > >> >> P.S. Remembered to add the links this time. :) > >> >> > >> >> > >> >> David Holmes wrote on 30/07/2019 03:37:53: > >> >> > >> >> > From: David Holmes > >> >> > To: Adam Farley8 > >> >> > Cc: hotspot-dev at openjdk.java.net, serviceability-dev > >> >> > > >> >> > Date: 30/07/2019 03:38 > >> >> > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > >> >> > paths are longer than JVM_MAXPATHLEN > >> >> > > >> >> > Hi Adam, > >> >> > > >> >> > On 25/07/2019 3:57 am, Adam Farley8 wrote: > >> >> > > Hi David, > >> >> > > > >> >> > > Welcome back. :) > >> >> > > >> >> > Thanks. Sorry for the delay in getting back to this. > >> >> > > >> >> > I like .v2 as it is much simpler (notwithstanding freeing > the already > >> >> > allocated arrays adds some complexity - thanks for fixing that). > >> >> > > >> >> > I'm still not sure we can't optimise things better for unchangeable > >> >> > properties like the boot libary path, but that's another RFE. > >> >> > > >> >> > Thanks, > >> >> > David > >> >> > > >> >> 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 > 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 daniel.daugherty at oracle.com Tue Aug 13 15:51:56 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 13 Aug 2019 11:51:56 -0400 Subject: RFR: JDK-8227021: VM fails if any sun.boot.library.path paths are longer than JVM_MAXPATHLEN In-Reply-To: References: <25234969-2215-57e9-d8c5-d97b5669ebb1@oracle.com> <5ba808b0-ae52-0d0a-b84b-fc34df35475d@oracle.com> <025da83a-6569-f6ac-7590-5b200ed2344f@oracle.com> <8e62fc61-b46b-0033-f182-cb4a2dbf92fd@oracle.com> Message-ID: <863c9fd2-0ccb-ed97-a677-dadddaf278ee@oracle.com> I don't see any information describing how this change was tested. Dan On 8/13/19 11:48 AM, Adam Farley8 wrote: > Hi David, > > Since we have two positive reviews (yours and Serguei's), could you > sponsor the change please? > > Best Regards > > Adam Farley > IBM Runtimes > > > David Holmes wrote on 12/08/2019 23:32:14: > >> From: David Holmes >> To: Adam Farley8 >> Cc: hotspot-dev at openjdk.java.net, "serguei.spitsyn at oracle.com" >> >> Date: 12/08/2019 23:32 >> Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path >> paths are longer than JVM_MAXPATHLEN >> >> Looks fine. >> >> Thanks, >> David >> >> On 13/08/2019 1:19 am, Adam Farley8 wrote: >>> Hi David, >>> >>> Changes made as requested: >>> https://urldefense.proofpoint.com/v2/url? >> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.4_webrev&d=DwID- >> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- >> > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=mZM8IR4e_zmrfcsF3XJjoGEMrZb4WtEL7Y6Ugd6Naqg&s=sZ2UKqqUIq0El- >> RsqYz6jmTh4Q2UghwdrQX6of8Lw0E&e= >>> Best Regards >>> >>> Adam Farley >>> IBM Runtimes >>> >>> >>> David Holmes wrote on 12/08/2019 04:55:36: >>> >>>> From: David Holmes >>>> To: Adam Farley8 , >>>> "serguei.spitsyn at oracle.com" >>>> Cc: hotspot-dev at openjdk.java.net >>>> Date: 12/08/2019 04:56 >>>> Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path >>>> paths are longer than JVM_MAXPATHLEN >>>> >>>> Hi Adam, >>>> >>>> On 10/08/2019 2:47 am, Adam Farley8 wrote: >>>>> Hi Serguei, David, >>>>> >>>>> My turn to apologise for the delay. :) >>>>> >>>>> I've modified the code as per Serguei's request. Take a look and > let me >>>>> know if this is the sort of thing you were thinking of. >>>>> >>>>> Webrev: https://urldefense.proofpoint.com/v2/url? >>>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.3_webrev_&d=DwID- >>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- >>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- >>>> > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=L19aeFXoR9JIO62QRPFzZObIU8RbhpCtXSvUibD2ISk&e= >>>> I'd prefer to see the helper just as a file static function rather > than >>>> adding it to the os class. >>>> >>>> + * supplied array of arrays of chars (a), where n >>>> >>>> I assume (a) is meant to refer to the parameter, but you actually > called >>>> it arrayarray. I think "a" or "arr" would suffice. >>>> >>>> Thanks, >>>> David >>>> >>>>> Best Regards >>>>> >>>>> Adam Farley >>>>> IBM Runtimes >>>>> >>>>> >>>>> "serguei.spitsyn at oracle.com" wrote on >>>>> 31/07/2019 17:18:05: >>>>> >>>>>> From: "serguei.spitsyn at oracle.com" >>>>>> To: Adam Farley8 , David Holmes >>>>>> >>>>>> Cc: serviceability-dev , >>>>>> hotspot-dev at openjdk.java.net >>>>>> Date: 31/07/2019 17:18 >>>>>> Subject: Re: RFR: JDK-8227021: VM fails if any > sun.boot.library.path >>>>>> paths are longer than JVM_MAXPATHLEN >>>>>> >>>>>> Hi Adam, >>>>>> >>>>>> It looks Okay to me. >>>>>> >>>>>> A couple of minor comments. >>>>>> >>>>>> https://urldefense.proofpoint.com/v2/url? >>>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021. >>>> 2_webrev_src_hotspot_&d=DwID-g&c=jf_iaSHvJObTbx- >>>> siA1ZOg&r=P5m8KWUXJf-CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- >>>> > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NL6tYuwwDod3DSmj-1ztxAywpO8L52HEyO0wvTR05bs&e= >>>>>> share/runtime/os.cpp.frames.html >>>>>> 1362 //release allocated storage before exiting the vm >>>>>> 1363 while (i > 0) { >>>>>> 1364 i--; >>>>>> 1365 if (opath[i] != NULL) { >>>>>> 1366 FREE_C_HEAP_ARRAY(char, opath[i]); >>>>>> 1367 } >>>>>> 1368 } >>>>>> 1369 FREE_C_HEAP_ARRAY(char*, opath); >>>>>> >>>>>> 1377 //release allocated storage before returning null >>>>>> 1378 while (i > 0) { >>>>>> 1379 i--; >>>>>> 1380 if (opath[i] != NULL) { >>>>>> 1381 FREE_C_HEAP_ARRAY(char, opath[i]); >>>>>> 1382 } >>>>>> 1383 } >>>>>> 1384 FREE_C_HEAP_ARRAY(char*, opath); >>>>>> >>>>>> This duplicated fragments is worth to refactor to a function. >>>>>> Also a space is missed at the beginning of the comment. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> >>>>>> On 7/31/19 02:01, Adam Farley8 wrote: >>>>>> Hi All, >>>>>> >>>>>> Reviewers requested for the change below. >>>>>> >>>>>> @David - Agreed. Would you be prepared to sponsor the change? >>>>>> >>>>>> Bug: https://urldefense.proofpoint.com/v2/url? >>>> u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8227021&d=DwID- >>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- >>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- >>>> > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=xykJ0KLy9AKWO8zmC0amfR7xxUsvyKEjlf3y7WWOqvE&e= >>>>>> Webrev: https://urldefense.proofpoint.com/v2/url? >>>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.2_webrev_&d=DwID- >>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- >>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- >>>> > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NvIza4VVWG3CiDhmQVmXsghH_4h_c5mFJbHwkCUcut0&e= >>>>>> Best Regards >>>>>> >>>>>> Adam Farley >>>>>> IBM Runtimes >>>>>> >>>>>> P.S. Remembered to add the links this time. :) >>>>>> >>>>>> >>>>>> David Holmes wrote on 30/07/2019 > 03:37:53: >>>>>>> From: David Holmes >>>>>>> To: Adam Farley8 >>>>>>> Cc: hotspot-dev at openjdk.java.net, serviceability-dev >>>>>>> >>>>>>> Date: 30/07/2019 03:38 >>>>>>> Subject: Re: RFR: JDK-8227021: VM fails if any > sun.boot.library.path >>>>>>> paths are longer than JVM_MAXPATHLEN >>>>>>> >>>>>>> Hi Adam, >>>>>>> >>>>>>> On 25/07/2019 3:57 am, Adam Farley8 wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>> Welcome back. :) >>>>>>> Thanks. Sorry for the delay in getting back to this. >>>>>>> >>>>>>> I like .v2 as it is much simpler (notwithstanding freeing >> the already >>>>>>> allocated arrays adds some complexity - thanks for fixing that). >>>>>>> >>>>>>> I'm still not sure we can't optimise things better for > unchangeable >>>>>>> properties like the boot libary path, but that's another RFE. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>> 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 > 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 adam.farley at uk.ibm.com Tue Aug 13 16:00:57 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Tue, 13 Aug 2019 17:00:57 +0100 Subject: RFR: JDK-8227021: VM fails if any sun.boot.library.path paths are longer than JVM_MAXPATHLEN In-Reply-To: <863c9fd2-0ccb-ed97-a677-dadddaf278ee@oracle.com> References: <25234969-2215-57e9-d8c5-d97b5669ebb1@oracle.com> <5ba808b0-ae52-0d0a-b84b-fc34df35475d@oracle.com> <025da83a-6569-f6ac-7590-5b200ed2344f@oracle.com> <8e62fc61-b46b-0033-f182-cb4a2dbf92fd@oracle.com> Message-ID: Hi Daniel, The basic test case is described in the bug: java -Dsun.boot.library.path=$LONGPATH:$RIGHTPATH AnyClass (where LONGPATH has >5k characters in it) As this code path is executed during library loading at startup, this test case should be enough to demonstrate the fix. Does this answer your question? Best Regards Adam Farley IBM Runtimes "Daniel D. Daugherty" wrote on 13/08/2019 16:51:56: > From: "Daniel D. Daugherty" > To: Adam Farley8 , David Holmes > > Cc: hotspot-dev at openjdk.java.net > Date: 13/08/2019 16:52 > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > paths are longer than JVM_MAXPATHLEN > > I don't see any information describing how this change was tested. > > Dan > > > On 8/13/19 11:48 AM, Adam Farley8 wrote: > > Hi David, > > > > Since we have two positive reviews (yours and Serguei's), could you > > sponsor the change please? > > > > Best Regards > > > > Adam Farley > > IBM Runtimes > > > > > > David Holmes wrote on 12/08/2019 23:32:14: > > > >> From: David Holmes > >> To: Adam Farley8 > >> Cc: hotspot-dev at openjdk.java.net, "serguei.spitsyn at oracle.com" > >> > >> Date: 12/08/2019 23:32 > >> Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > >> paths are longer than JVM_MAXPATHLEN > >> > >> Looks fine. > >> > >> Thanks, > >> David > >> > >> On 13/08/2019 1:19 am, Adam Farley8 wrote: > >>> Hi David, > >>> > >>> Changes made as requested: > >>> https://urldefense.proofpoint.com/v2/url? > >> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.4_webrev&d=DwID- > >> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > >> > > > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=mZM8IR4e_zmrfcsF3XJjoGEMrZb4WtEL7Y6Ugd6Naqg&s=sZ2UKqqUIq0El- > >> RsqYz6jmTh4Q2UghwdrQX6of8Lw0E&e= > >>> Best Regards > >>> > >>> Adam Farley > >>> IBM Runtimes > >>> > >>> > >>> David Holmes wrote on 12/08/2019 04:55:36: > >>> > >>>> From: David Holmes > >>>> To: Adam Farley8 , > >>>> "serguei.spitsyn at oracle.com" > >>>> Cc: hotspot-dev at openjdk.java.net > >>>> Date: 12/08/2019 04:56 > >>>> Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > >>>> paths are longer than JVM_MAXPATHLEN > >>>> > >>>> Hi Adam, > >>>> > >>>> On 10/08/2019 2:47 am, Adam Farley8 wrote: > >>>>> Hi Serguei, David, > >>>>> > >>>>> My turn to apologise for the delay. :) > >>>>> > >>>>> I've modified the code as per Serguei's request. Take a look and > > let me > >>>>> know if this is the sort of thing you were thinking of. > >>>>> > >>>>> Webrev: https://urldefense.proofpoint.com/v2/url? > >>>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.3_webrev_&d=DwID- > >>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > >>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > >>>> > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=L19aeFXoR9JIO62QRPFzZObIU8RbhpCtXSvUibD2ISk&e= > >>>> I'd prefer to see the helper just as a file static function rather > > than > >>>> adding it to the os class. > >>>> > >>>> + * supplied array of arrays of chars (a), where n > >>>> > >>>> I assume (a) is meant to refer to the parameter, but you actually > > called > >>>> it arrayarray. I think "a" or "arr" would suffice. > >>>> > >>>> Thanks, > >>>> David > >>>> > >>>>> Best Regards > >>>>> > >>>>> Adam Farley > >>>>> IBM Runtimes > >>>>> > >>>>> > >>>>> "serguei.spitsyn at oracle.com" wrote on > >>>>> 31/07/2019 17:18:05: > >>>>> > >>>>>> From: "serguei.spitsyn at oracle.com" > >>>>>> To: Adam Farley8 , David Holmes > >>>>>> > >>>>>> Cc: serviceability-dev , > >>>>>> hotspot-dev at openjdk.java.net > >>>>>> Date: 31/07/2019 17:18 > >>>>>> Subject: Re: RFR: JDK-8227021: VM fails if any > > sun.boot.library.path > >>>>>> paths are longer than JVM_MAXPATHLEN > >>>>>> > >>>>>> Hi Adam, > >>>>>> > >>>>>> It looks Okay to me. > >>>>>> > >>>>>> A couple of minor comments. > >>>>>> > >>>>>> https://urldefense.proofpoint.com/v2/url? > >>>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021. > >>>> 2_webrev_src_hotspot_&d=DwID-g&c=jf_iaSHvJObTbx- > >>>> siA1ZOg&r=P5m8KWUXJf-CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > >>>> > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NL6tYuwwDod3DSmj-1ztxAywpO8L52HEyO0wvTR05bs&e= > >>>>>> share/runtime/os.cpp.frames.html > >>>>>> 1362 //release allocated storage before exiting the vm > >>>>>> 1363 while (i > 0) { > >>>>>> 1364 i--; > >>>>>> 1365 if (opath[i] != NULL) { > >>>>>> 1366 FREE_C_HEAP_ARRAY(char, opath[i]); > >>>>>> 1367 } > >>>>>> 1368 } > >>>>>> 1369 FREE_C_HEAP_ARRAY(char*, opath); > >>>>>> > >>>>>> 1377 //release allocated storage before returning null > >>>>>> 1378 while (i > 0) { > >>>>>> 1379 i--; > >>>>>> 1380 if (opath[i] != NULL) { > >>>>>> 1381 FREE_C_HEAP_ARRAY(char, opath[i]); > >>>>>> 1382 } > >>>>>> 1383 } > >>>>>> 1384 FREE_C_HEAP_ARRAY(char*, opath); > >>>>>> > >>>>>> This duplicated fragments is worth to refactor to a function. > >>>>>> Also a space is missed at the beginning of the comment. > >>>>>> > >>>>>> > >>>>>> Thanks, > >>>>>> Serguei > >>>>>> > >>>>>> > >>>>>> > >>>>>> On 7/31/19 02:01, Adam Farley8 wrote: > >>>>>> Hi All, > >>>>>> > >>>>>> Reviewers requested for the change below. > >>>>>> > >>>>>> @David - Agreed. Would you be prepared to sponsor the change? > >>>>>> > >>>>>> Bug: https://urldefense.proofpoint.com/v2/url? > >>>> u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8227021&d=DwID- > >>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > >>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > >>>> > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=xykJ0KLy9AKWO8zmC0amfR7xxUsvyKEjlf3y7WWOqvE&e= > >>>>>> Webrev: https://urldefense.proofpoint.com/v2/url? > >>>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.2_webrev_&d=DwID- > >>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > >>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > >>>> > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NvIza4VVWG3CiDhmQVmXsghH_4h_c5mFJbHwkCUcut0&e= > >>>>>> Best Regards > >>>>>> > >>>>>> Adam Farley > >>>>>> IBM Runtimes > >>>>>> > >>>>>> P.S. Remembered to add the links this time. :) > >>>>>> > >>>>>> > >>>>>> David Holmes wrote on 30/07/2019 > > 03:37:53: > >>>>>>> From: David Holmes > >>>>>>> To: Adam Farley8 > >>>>>>> Cc: hotspot-dev at openjdk.java.net, serviceability-dev > >>>>>>> > >>>>>>> Date: 30/07/2019 03:38 > >>>>>>> Subject: Re: RFR: JDK-8227021: VM fails if any > > sun.boot.library.path > >>>>>>> paths are longer than JVM_MAXPATHLEN > >>>>>>> > >>>>>>> Hi Adam, > >>>>>>> > >>>>>>> On 25/07/2019 3:57 am, Adam Farley8 wrote: > >>>>>>>> Hi David, > >>>>>>>> > >>>>>>>> Welcome back. :) > >>>>>>> Thanks. Sorry for the delay in getting back to this. > >>>>>>> > >>>>>>> I like .v2 as it is much simpler (notwithstanding freeing > >> the already > >>>>>>> allocated arrays adds some complexity - thanks for fixing that). > >>>>>>> > >>>>>>> I'm still not sure we can't optimise things better for > > unchangeable > >>>>>>> properties like the boot libary path, but that's another RFE. > >>>>>>> > >>>>>>> Thanks, > >>>>>>> David > >>>>>>> > >>>>>> 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 > > 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 daniel.daugherty at oracle.com Tue Aug 13 16:05:20 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 13 Aug 2019 12:05:20 -0400 Subject: RFR: JDK-8227021: VM fails if any sun.boot.library.path paths are longer than JVM_MAXPATHLEN In-Reply-To: References: <25234969-2215-57e9-d8c5-d97b5669ebb1@oracle.com> <5ba808b0-ae52-0d0a-b84b-fc34df35475d@oracle.com> <025da83a-6569-f6ac-7590-5b200ed2344f@oracle.com> <8e62fc61-b46b-0033-f182-cb4a2dbf92fd@oracle.com> Message-ID: <7170e79e-1141-ebf9-6576-e05e9e35d912@oracle.com> Hi Adam, I should have been more clear. The code review request should indicate what kind of testing has been done on the change. Could be something like: - Ran through jdk_submit with no failures. - Also ran the test from the bug report on Linux or Win* or XXX. So I see that you've run the bug specific test. Did you run any other testing like jdk_submit? Dan On 8/13/19 12:00 PM, Adam Farley8 wrote: > Hi Daniel, > > The basic test case is described in the bug: > > java -Dsun.boot.library.path=$LONGPATH:$RIGHTPATH AnyClass > > (where LONGPATH has >5k characters in it) > > As this code path is executed during library loading at startup, this > test case should be enough to demonstrate the fix. > > Does this answer your question? > > Best Regards > > Adam Farley > IBM Runtimes > > > "Daniel D. Daugherty" wrote on > 13/08/2019 16:51:56: > > > From: "Daniel D. Daugherty" > > To: Adam Farley8 , David Holmes > > > > Cc: hotspot-dev at openjdk.java.net > > Date: 13/08/2019 16:52 > > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > > paths are longer than JVM_MAXPATHLEN > > > > I don't see any information describing how this change was tested. > > > > Dan > > > > > > On 8/13/19 11:48 AM, Adam Farley8 wrote: > > > Hi David, > > > > > > Since we have two positive reviews (yours and Serguei's), could you > > > sponsor the change please? > > > > > > Best Regards > > > > > > Adam Farley > > > IBM Runtimes > > > > > > > > > David Holmes wrote on 12/08/2019 23:32:14: > > > > > >> From: David Holmes > > >> To: Adam Farley8 > > >> Cc: hotspot-dev at openjdk.java.net, "serguei.spitsyn at oracle.com" > > >> > > >> Date: 12/08/2019 23:32 > > >> Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > > >> paths are longer than JVM_MAXPATHLEN > > >> > > >> Looks fine. > > >> > > >> Thanks, > > >> David > > >> > > >> On 13/08/2019 1:19 am, Adam Farley8 wrote: > > >>> Hi David, > > >>> > > >>> Changes made as requested: > > >>> https://urldefense.proofpoint.com/v2/url? > > >> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.4_webrev&d=DwID- > > >> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > >> > > > > > > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=mZM8IR4e_zmrfcsF3XJjoGEMrZb4WtEL7Y6Ugd6Naqg&s=sZ2UKqqUIq0El- > > >> RsqYz6jmTh4Q2UghwdrQX6of8Lw0E&e= > > >>> Best Regards > > >>> > > >>> Adam Farley > > >>> IBM Runtimes > > >>> > > >>> > > >>> David Holmes wrote on 12/08/2019 04:55:36: > > >>> > > >>>> From: David Holmes > > >>>> To: Adam Farley8 , > > >>>> "serguei.spitsyn at oracle.com" > > >>>> Cc: hotspot-dev at openjdk.java.net > > >>>> Date: 12/08/2019 04:56 > > >>>> Subject: Re: RFR: JDK-8227021: ?VM fails if any > sun.boot.library.path > > >>>> paths are longer than JVM_MAXPATHLEN > > >>>> > > >>>> Hi Adam, > > >>>> > > >>>> On 10/08/2019 2:47 am, Adam Farley8 wrote: > > >>>>> Hi Serguei, David, > > >>>>> > > >>>>> My turn to apologise for the delay. :) > > >>>>> > > >>>>> I've modified the code as per Serguei's request. Take a look ?and > > > let me > > >>>>> know if this is the sort of thing you were thinking of. > > >>>>> > > >>>>> Webrev: https://urldefense.proofpoint.com/v2/url? > > >>>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.3_webrev_&d=DwID- > > >>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > >>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > > >>>> > > > > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=L19aeFXoR9JIO62QRPFzZObIU8RbhpCtXSvUibD2ISk&e= > > >>>> I'd prefer to see the helper just as a file static function rather > > > than > > >>>> adding it to the os class. > > >>>> > > >>>> + ?* supplied array of arrays of chars (a), where n > > >>>> > > >>>> I assume (a) is meant to refer to the parameter, but you actually > > > called > > >>>> it arrayarray. I think "a" or "arr" would suffice. > > >>>> > > >>>> Thanks, > > >>>> David > > >>>> > > >>>>> Best Regards > > >>>>> > > >>>>> Adam Farley > > >>>>> IBM Runtimes > > >>>>> > > >>>>> > > >>>>> "serguei.spitsyn at oracle.com" > ?wrote on > > >>>>> 31/07/2019 17:18:05: > > >>>>> > > >>>>>> From: "serguei.spitsyn at oracle.com" > > >>>>>> To: Adam Farley8 , ?David ?Holmes > > >>>>>> > > >>>>>> Cc: serviceability-dev , > > >>>>>> hotspot-dev at openjdk.java.net > > >>>>>> Date: 31/07/2019 17:18 > > >>>>>> Subject: Re: RFR: JDK-8227021: ?VM fails if any > > > sun.boot.library.path > > >>>>>> paths are longer than JVM_MAXPATHLEN > > >>>>>> > > >>>>>> Hi Adam, > > >>>>>> > > >>>>>> It looks Okay to me. > > >>>>>> > > >>>>>> A couple of minor comments. > > >>>>>> > > >>>>>> https://urldefense.proofpoint.com/v2/url? > > >>>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021. > > >>>> 2_webrev_src_hotspot_&d=DwID-g&c=jf_iaSHvJObTbx- > > >>>> siA1ZOg&r=P5m8KWUXJf-CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > > >>>> > > > > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NL6tYuwwDod3DSmj-1ztxAywpO8L52HEyO0wvTR05bs&e= > > >>>>>> share/runtime/os.cpp.frames.html > > >>>>>> 1362 ? ? ? //release ?allocated storage ?before exiting the vm > > >>>>>> 1363 ? ? ? while (i > 0) { > > >>>>>> 1364 ? ? ? ? ? i--; > > >>>>>> 1365 ? ? ? ? ? if (opath[i] != NULL) ?{ > > >>>>>> 1366 FREE_C_HEAP_ARRAY(char, ? opath[i]); > > >>>>>> 1367 ? ? ? ? ? } > > >>>>>> 1368 ? ? ? } > > >>>>>> 1369 FREE_C_HEAP_ARRAY(char*, opath); > > >>>>>> > > >>>>>> 1377 ? ? ? //release allocated storage before ?returning ?null > > >>>>>> 1378 ? ? ? while (i > 0) { > > >>>>>> 1379 ? ? ? ? ? i--; > > >>>>>> 1380 ? ? ? ? ? if (opath[i] != NULL) ?{ > > >>>>>> 1381 FREE_C_HEAP_ARRAY(char, ? opath[i]); > > >>>>>> 1382 ? ? ? ? ? } > > >>>>>> 1383 ? ? ? } > > >>>>>> 1384 FREE_C_HEAP_ARRAY(char*, opath); > > >>>>>> > > >>>>>> This duplicated fragments is worth to refactor to a function. > > >>>>>> Also a space is missed at the beginning of the comment. > > >>>>>> > > >>>>>> > > >>>>>> Thanks, > > >>>>>> Serguei > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> On 7/31/19 02:01, Adam Farley8 wrote: > > >>>>>> Hi All, > > >>>>>> > > >>>>>> Reviewers requested for the change below. > > >>>>>> > > >>>>>> @David - Agreed. Would you be prepared to sponsor the change? > > >>>>>> > > >>>>>> Bug: https://urldefense.proofpoint.com/v2/url? > > >>>> u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8227021&d=DwID- > > >>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > >>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > > >>>> > > > > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=xykJ0KLy9AKWO8zmC0amfR7xxUsvyKEjlf3y7WWOqvE&e= > > >>>>>> Webrev: https://urldefense.proofpoint.com/v2/url? > > >>>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.2_webrev_&d=DwID- > > >>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > >>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > > >>>> > > > > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NvIza4VVWG3CiDhmQVmXsghH_4h_c5mFJbHwkCUcut0&e= > > >>>>>> Best Regards > > >>>>>> > > >>>>>> Adam Farley > > >>>>>> IBM Runtimes > > >>>>>> > > >>>>>> P.S. Remembered to add the links this time. :) > > >>>>>> > > >>>>>> > > >>>>>> David Holmes wrote on 30/07/2019 > > > 03:37:53: > > >>>>>>> From: David Holmes > > >>>>>>> To: Adam Farley8 > > >>>>>>> Cc: hotspot-dev at openjdk.java.net, serviceability-dev > > >>>>>>> > > >>>>>>> Date: 30/07/2019 03:38 > > >>>>>>> Subject: Re: RFR: JDK-8227021: VM fails if any > > > sun.boot.library.path > > >>>>>>> paths are longer than JVM_MAXPATHLEN > > >>>>>>> > > >>>>>>> Hi Adam, > > >>>>>>> > > >>>>>>> On 25/07/2019 3:57 am, Adam Farley8 wrote: > > >>>>>>>> Hi David, > > >>>>>>>> > > >>>>>>>> Welcome back. :) > > >>>>>>> Thanks. Sorry for the delay in getting back to this. > > >>>>>>> > > >>>>>>> I like .v2 as it is much simpler (notwithstanding freeing > > >> the ?already > > >>>>>>> allocated arrays adds some complexity - thanks for fixing that). > > >>>>>>> > > >>>>>>> I'm still not sure we can't optimise things better for > > > unchangeable > > >>>>>>> properties like the boot libary path, but that's another ?RFE. > > >>>>>>> > > >>>>>>> Thanks, > > >>>>>>> David > > >>>>>>> > > >>>>>> 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 > > > 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 adam.farley at uk.ibm.com Tue Aug 13 16:05:47 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Tue, 13 Aug 2019 17:05:47 +0100 Subject: RFR: JDK-8227021: VM fails if any sun.boot.library.path paths are longer than JVM_MAXPATHLEN In-Reply-To: References: <25234969-2215-57e9-d8c5-d97b5669ebb1@oracle.com> <5ba808b0-ae52-0d0a-b84b-fc34df35475d@oracle.com> <025da83a-6569-f6ac-7590-5b200ed2344f@oracle.com> <8e62fc61-b46b-0033-f182-cb4a2dbf92fd@oracle.com> Message-ID: Hi Serguei, Much obliged. :) Best Regards Adam Farley IBM Runtimes "serguei.spitsyn at oracle.com" wrote on 13/08/2019 17:00:28: > From: "serguei.spitsyn at oracle.com" > To: Adam Farley8 , David Holmes > > Cc: hotspot-dev at openjdk.java.net > Date: 13/08/2019 17:02 > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > paths are longer than JVM_MAXPATHLEN > > Hi Adam, > > I'll sponsor the push. > > Thanks, > Serguei > > > On 8/13/19 08:48, Adam Farley8 wrote: > Hi David, > > Since we have two positive reviews (yours and Serguei's), could you > sponsor the change please? > > Best Regards > > Adam Farley > IBM Runtimes > > > David Holmes wrote on 12/08/2019 23:32:14: > > > From: David Holmes > > To: Adam Farley8 > > Cc: hotspot-dev at openjdk.java.net, "serguei.spitsyn at oracle.com" > > > > Date: 12/08/2019 23:32 > > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > > paths are longer than JVM_MAXPATHLEN > > > > Looks fine. > > > > Thanks, > > David > > > > On 13/08/2019 1:19 am, Adam Farley8 wrote: > > > Hi David, > > > > > > Changes made as requested: > > > https://urldefense.proofpoint.com/v2/url? > > u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.4_webrev&d=DwID- > > g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=mZM8IR4e_zmrfcsF3XJjoGEMrZb4WtEL7Y6Ugd6Naqg&s=sZ2UKqqUIq0El- > > RsqYz6jmTh4Q2UghwdrQX6of8Lw0E&e= > > > > > > Best Regards > > > > > > Adam Farley > > > IBM Runtimes > > > > > > > > > David Holmes wrote on 12/08/2019 04:55:36: > > > > > >> From: David Holmes > > >> To: Adam Farley8 , > > >> "serguei.spitsyn at oracle.com" > > >> Cc: hotspot-dev at openjdk.java.net > > >> Date: 12/08/2019 04:56 > > >> Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > > >> paths are longer than JVM_MAXPATHLEN > > >> > > >> Hi Adam, > > >> > > >> On 10/08/2019 2:47 am, Adam Farley8 wrote: > > >> > Hi Serguei, David, > > >> > > > >> > My turn to apologise for the delay. :) > > >> > > > >> > I've modified the code as per Serguei's request. Take a look > and let me > > >> > know if this is the sort of thing you were thinking of. > > >> > > > >> > Webrev: https://urldefense.proofpoint.com/v2/url? > > >> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.3_webrev_&d=DwID- > > >> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > >> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > > >> > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=L19aeFXoR9JIO62QRPFzZObIU8RbhpCtXSvUibD2ISk&e= > > >> > > >> I'd prefer to see the helper just as a file static function rather than > > >> adding it to the os class. > > >> > > >> + * supplied array of arrays of chars (a), where n > > >> > > >> I assume (a) is meant to refer to the parameter, but you actually called > > >> it arrayarray. I think "a" or "arr" would suffice. > > >> > > >> Thanks, > > >> David > > >> > > >> > Best Regards > > >> > > > >> > Adam Farley > > >> > IBM Runtimes > > >> > > > >> > > > >> > "serguei.spitsyn at oracle.com" wrote on > > >> > 31/07/2019 17:18:05: > > >> > > > >> >> From: "serguei.spitsyn at oracle.com" > > >> >> To: Adam Farley8 , David Holmes > > >> >> > > >> >> Cc: serviceability-dev , > > >> >> hotspot-dev at openjdk.java.net > > >> >> Date: 31/07/2019 17:18 > > >> >> Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > > >> >> paths are longer than JVM_MAXPATHLEN > > >> >> > > >> >> Hi Adam, > > >> >> > > >> >> It looks Okay to me. > > >> >> > > >> >> A couple of minor comments. > > >> >> > > >> >> https://urldefense.proofpoint.com/v2/url? > > >> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021. > > >> 2_webrev_src_hotspot_&d=DwID-g&c=jf_iaSHvJObTbx- > > >> siA1ZOg&r=P5m8KWUXJf-CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > > >> > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NL6tYuwwDod3DSmj-1ztxAywpO8L52HEyO0wvTR05bs&e= > > >> >> share/runtime/os.cpp.frames.html > > >> > > > >> >> 1362 //release allocated storage before exiting the vm > > >> >> 1363 while (i > 0) { > > >> >> 1364 i--; > > >> >> 1365 if (opath[i] != NULL) { > > >> >> 1366 FREE_C_HEAP_ARRAY(char, opath[i]); > > >> >> 1367 } > > >> >> 1368 } > > >> >> 1369 FREE_C_HEAP_ARRAY(char*, opath); > > >> >> > > >> >> 1377 //release allocated storage before returning null > > >> >> 1378 while (i > 0) { > > >> >> 1379 i--; > > >> >> 1380 if (opath[i] != NULL) { > > >> >> 1381 FREE_C_HEAP_ARRAY(char, opath[i]); > > >> >> 1382 } > > >> >> 1383 } > > >> >> 1384 FREE_C_HEAP_ARRAY(char*, opath); > > >> >> > > >> >> This duplicated fragments is worth to refactor to a function. > > >> >> Also a space is missed at the beginning of the comment. > > >> >> > > >> >> > > >> >> Thanks, > > >> >> Serguei > > >> >> > > >> >> > > >> >> > > >> >> On 7/31/19 02:01, Adam Farley8 wrote: > > >> >> Hi All, > > >> >> > > >> >> Reviewers requested for the change below. > > >> >> > > >> >> @David - Agreed. Would you be prepared to sponsor the change? > > >> >> > > >> >> Bug: https://urldefense.proofpoint.com/v2/url? > > >> u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8227021&d=DwID- > > >> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > >> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > > >> > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=xykJ0KLy9AKWO8zmC0amfR7xxUsvyKEjlf3y7WWOqvE&e= > > >> >> Webrev: https://urldefense.proofpoint.com/v2/url? > > >> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.2_webrev_&d=DwID- > > >> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > >> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > > >> > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NvIza4VVWG3CiDhmQVmXsghH_4h_c5mFJbHwkCUcut0&e= > > >> >> > > >> >> Best Regards > > >> >> > > >> >> Adam Farley > > >> >> IBM Runtimes > > >> >> > > >> >> P.S. Remembered to add the links this time. :) > > >> >> > > >> >> > > >> >> David Holmes wrote on 30/07/2019 03:37:53: > > >> >> > > >> >> > From: David Holmes > > >> >> > To: Adam Farley8 > > >> >> > Cc: hotspot-dev at openjdk.java.net, serviceability-dev > > >> >> > > > >> >> > Date: 30/07/2019 03:38 > > >> >> > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > > >> >> > paths are longer than JVM_MAXPATHLEN > > >> >> > > > >> >> > Hi Adam, > > >> >> > > > >> >> > On 25/07/2019 3:57 am, Adam Farley8 wrote: > > >> >> > > Hi David, > > >> >> > > > > >> >> > > Welcome back. :) > > >> >> > > > >> >> > Thanks. Sorry for the delay in getting back to this. > > >> >> > > > >> >> > I like .v2 as it is much simpler (notwithstanding freeing > > the already > > >> >> > allocated arrays adds some complexity - thanks for fixing that). > > >> >> > > > >> >> > I'm still not sure we can't optimise things better for unchangeable > > >> >> > properties like the boot libary path, but that's another RFE. > > >> >> > > > >> >> > Thanks, > > >> >> > David > > >> >> > > > >> >> 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 > > > > 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 adam.farley at uk.ibm.com Tue Aug 13 16:14:21 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Tue, 13 Aug 2019 17:14:21 +0100 Subject: RFR: JDK-8227021: VM fails if any sun.boot.library.path paths are longer than JVM_MAXPATHLEN In-Reply-To: <7170e79e-1141-ebf9-6576-e05e9e35d912@oracle.com> References: <5ba808b0-ae52-0d0a-b84b-fc34df35475d@oracle.com> <025da83a-6569-f6ac-7590-5b200ed2344f@oracle.com> <8e62fc61-b46b-0033-f182-cb4a2dbf92fd@oracle.com> <7170e79e-1141-ebf9-6576-e05e9e35d912@oracle.com> Message-ID: Hi Daniel, As this change isn't a part of the class libraries, and this code path is exercised during startup, I neglected to run testing beyond the bug specific tests and variants theron. I'm happy to take recommendations for the tests I should run. I'm not familiar with jdk_submit. Google isn't helping, nor is a jdk/jdk search. Can you advise on how I can run it? Best Regards Adam Farley IBM Runtimes "Daniel D. Daugherty" wrote on 13/08/2019 17:05:20: > From: "Daniel D. Daugherty" > To: Adam Farley8 > Cc: David Holmes , hotspot-dev at openjdk.java.net > Date: 13/08/2019 17:05 > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > paths are longer than JVM_MAXPATHLEN > > Hi Adam, > > I should have been more clear. The code review request should indicate > what kind of testing has been done on the change. Could be something > like: > > - Ran through jdk_submit with no failures. > - Also ran the test from the bug report on Linux or Win* or XXX. > > So I see that you've run the bug specific test. Did you run any other > testing like jdk_submit? > > Dan > > On 8/13/19 12:00 PM, Adam Farley8 wrote: > Hi Daniel, > > The basic test case is described in the bug: > > java -Dsun.boot.library.path=$LONGPATH:$RIGHTPATH AnyClass > > (where LONGPATH has >5k characters in it) > > As this code path is executed during library loading at startup, > this test case should be enough to demonstrate the fix. > > Does this answer your question? > > Best Regards > > Adam Farley > IBM Runtimes > > > "Daniel D. Daugherty" wrote on 13/08/ > 2019 16:51:56: > > > From: "Daniel D. Daugherty" > > To: Adam Farley8 , David Holmes > > > > Cc: hotspot-dev at openjdk.java.net > > Date: 13/08/2019 16:52 > > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > > paths are longer than JVM_MAXPATHLEN > > > > I don't see any information describing how this change was tested. > > > > Dan > > > > > > On 8/13/19 11:48 AM, Adam Farley8 wrote: > > > Hi David, > > > > > > Since we have two positive reviews (yours and Serguei's), could you > > > sponsor the change please? > > > > > > Best Regards > > > > > > Adam Farley > > > IBM Runtimes > > > > > > > > > David Holmes wrote on 12/08/2019 23:32:14: > > > > > >> From: David Holmes > > >> To: Adam Farley8 > > >> Cc: hotspot-dev at openjdk.java.net, "serguei.spitsyn at oracle.com" > > >> > > >> Date: 12/08/2019 23:32 > > >> Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > > >> paths are longer than JVM_MAXPATHLEN > > >> > > >> Looks fine. > > >> > > >> Thanks, > > >> David > > >> > > >> On 13/08/2019 1:19 am, Adam Farley8 wrote: > > >>> Hi David, > > >>> > > >>> Changes made as requested: > > >>> https://urldefense.proofpoint.com/v2/url? > > >> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.4_webrev&d=DwID- > > >> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > >> > > > > > > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=mZM8IR4e_zmrfcsF3XJjoGEMrZb4WtEL7Y6Ugd6Naqg&s=sZ2UKqqUIq0El- > > >> RsqYz6jmTh4Q2UghwdrQX6of8Lw0E&e= > > >>> Best Regards > > >>> > > >>> Adam Farley > > >>> IBM Runtimes > > >>> > > >>> > > >>> David Holmes wrote on 12/08/2019 04:55:36: > > >>> > > >>>> From: David Holmes > > >>>> To: Adam Farley8 , > > >>>> "serguei.spitsyn at oracle.com" > > >>>> Cc: hotspot-dev at openjdk.java.net > > >>>> Date: 12/08/2019 04:56 > > >>>> Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > > >>>> paths are longer than JVM_MAXPATHLEN > > >>>> > > >>>> Hi Adam, > > >>>> > > >>>> On 10/08/2019 2:47 am, Adam Farley8 wrote: > > >>>>> Hi Serguei, David, > > >>>>> > > >>>>> My turn to apologise for the delay. :) > > >>>>> > > >>>>> I've modified the code as per Serguei's request. Take a look and > > > let me > > >>>>> know if this is the sort of thing you were thinking of. > > >>>>> > > >>>>> Webrev: https://urldefense.proofpoint.com/v2/url? > > >>>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.3_webrev_&d=DwID- > > >>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > >>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > > >>>> > > > > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=L19aeFXoR9JIO62QRPFzZObIU8RbhpCtXSvUibD2ISk&e= > > >>>> I'd prefer to see the helper just as a file static function rather > > > than > > >>>> adding it to the os class. > > >>>> > > >>>> + * supplied array of arrays of chars (a), where n > > >>>> > > >>>> I assume (a) is meant to refer to the parameter, but you actually > > > called > > >>>> it arrayarray. I think "a" or "arr" would suffice. > > >>>> > > >>>> Thanks, > > >>>> David > > >>>> > > >>>>> Best Regards > > >>>>> > > >>>>> Adam Farley > > >>>>> IBM Runtimes > > >>>>> > > >>>>> > > >>>>> "serguei.spitsyn at oracle.com" wrote on > > >>>>> 31/07/2019 17:18:05: > > >>>>> > > >>>>>> From: "serguei.spitsyn at oracle.com" > > >>>>>> To: Adam Farley8 , David Holmes > > >>>>>> > > >>>>>> Cc: serviceability-dev , > > >>>>>> hotspot-dev at openjdk.java.net > > >>>>>> Date: 31/07/2019 17:18 > > >>>>>> Subject: Re: RFR: JDK-8227021: VM fails if any > > > sun.boot.library.path > > >>>>>> paths are longer than JVM_MAXPATHLEN > > >>>>>> > > >>>>>> Hi Adam, > > >>>>>> > > >>>>>> It looks Okay to me. > > >>>>>> > > >>>>>> A couple of minor comments. > > >>>>>> > > >>>>>> https://urldefense.proofpoint.com/v2/url? > > >>>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021. > > >>>> 2_webrev_src_hotspot_&d=DwID-g&c=jf_iaSHvJObTbx- > > >>>> siA1ZOg&r=P5m8KWUXJf-CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > > >>>> > > > > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NL6tYuwwDod3DSmj-1ztxAywpO8L52HEyO0wvTR05bs&e= > > >>>>>> share/runtime/os.cpp.frames.html > > >>>>>> 1362 //release allocated storage before exiting the vm > > >>>>>> 1363 while (i > 0) { > > >>>>>> 1364 i--; > > >>>>>> 1365 if (opath[i] != NULL) { > > >>>>>> 1366 FREE_C_HEAP_ARRAY(char, opath[i]); > > >>>>>> 1367 } > > >>>>>> 1368 } > > >>>>>> 1369 FREE_C_HEAP_ARRAY(char*, opath); > > >>>>>> > > >>>>>> 1377 //release allocated storage before returning null > > >>>>>> 1378 while (i > 0) { > > >>>>>> 1379 i--; > > >>>>>> 1380 if (opath[i] != NULL) { > > >>>>>> 1381 FREE_C_HEAP_ARRAY(char, opath[i]); > > >>>>>> 1382 } > > >>>>>> 1383 } > > >>>>>> 1384 FREE_C_HEAP_ARRAY(char*, opath); > > >>>>>> > > >>>>>> This duplicated fragments is worth to refactor to a function. > > >>>>>> Also a space is missed at the beginning of the comment. > > >>>>>> > > >>>>>> > > >>>>>> Thanks, > > >>>>>> Serguei > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> On 7/31/19 02:01, Adam Farley8 wrote: > > >>>>>> Hi All, > > >>>>>> > > >>>>>> Reviewers requested for the change below. > > >>>>>> > > >>>>>> @David - Agreed. Would you be prepared to sponsor the change? > > >>>>>> > > >>>>>> Bug: https://urldefense.proofpoint.com/v2/url? > > >>>> u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8227021&d=DwID- > > >>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > >>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > > >>>> > > > > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=xykJ0KLy9AKWO8zmC0amfR7xxUsvyKEjlf3y7WWOqvE&e= > > >>>>>> Webrev: https://urldefense.proofpoint.com/v2/url? > > >>>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.2_webrev_&d=DwID- > > >>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > >>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > > >>>> > > > > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NvIza4VVWG3CiDhmQVmXsghH_4h_c5mFJbHwkCUcut0&e= > > >>>>>> Best Regards > > >>>>>> > > >>>>>> Adam Farley > > >>>>>> IBM Runtimes > > >>>>>> > > >>>>>> P.S. Remembered to add the links this time. :) > > >>>>>> > > >>>>>> > > >>>>>> David Holmes wrote on 30/07/2019 > > > 03:37:53: > > >>>>>>> From: David Holmes > > >>>>>>> To: Adam Farley8 > > >>>>>>> Cc: hotspot-dev at openjdk.java.net, serviceability-dev > > >>>>>>> > > >>>>>>> Date: 30/07/2019 03:38 > > >>>>>>> Subject: Re: RFR: JDK-8227021: VM fails if any > > > sun.boot.library.path > > >>>>>>> paths are longer than JVM_MAXPATHLEN > > >>>>>>> > > >>>>>>> Hi Adam, > > >>>>>>> > > >>>>>>> On 25/07/2019 3:57 am, Adam Farley8 wrote: > > >>>>>>>> Hi David, > > >>>>>>>> > > >>>>>>>> Welcome back. :) > > >>>>>>> Thanks. Sorry for the delay in getting back to this. > > >>>>>>> > > >>>>>>> I like .v2 as it is much simpler (notwithstanding freeing > > >> the already > > >>>>>>> allocated arrays adds some complexity - thanks for fixing that). > > >>>>>>> > > >>>>>>> I'm still not sure we can't optimise things better for > > > unchangeable > > >>>>>>> properties like the boot libary path, but that's another RFE. > > >>>>>>> > > >>>>>>> Thanks, > > >>>>>>> David > > >>>>>>> > > >>>>>> 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 > > > 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 daniel.daugherty at oracle.com Tue Aug 13 16:17:24 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 13 Aug 2019 12:17:24 -0400 Subject: RFR: JDK-8227021: VM fails if any sun.boot.library.path paths are longer than JVM_MAXPATHLEN In-Reply-To: References: <5ba808b0-ae52-0d0a-b84b-fc34df35475d@oracle.com> <025da83a-6569-f6ac-7590-5b200ed2344f@oracle.com> <8e62fc61-b46b-0033-f182-cb4a2dbf92fd@oracle.com> <7170e79e-1141-ebf9-6576-e05e9e35d912@oracle.com> Message-ID: <37e96eab-c066-0b0f-e2b2-e9ac132d6c00@oracle.com> Let's see what Serguei (or David) says about testing needed. Looks like he reviewed this change (and your other one too)... I haven't reviewed either change... I just happened to notice that nothing was said in the RFR about testing... Dan On 8/13/19 12:14 PM, Adam Farley8 wrote: > Hi Daniel, > > As this change isn't a part of the class libraries, and this code path > is exercised during startup, I neglected to run testing beyond the bug > specific tests and variants theron. > > I'm happy to take recommendations for the tests I should run. > > I'm not familiar with jdk_submit. Google isn't helping, nor is a > jdk/jdk search. Can you advise on how I can run it? > > Best Regards > > Adam Farley > IBM Runtimes > > > "Daniel D. Daugherty" wrote on > 13/08/2019 17:05:20: > > > From: "Daniel D. Daugherty" > > To: Adam Farley8 > > Cc: David Holmes , hotspot-dev at openjdk.java.net > > Date: 13/08/2019 17:05 > > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > > paths are longer than JVM_MAXPATHLEN > > > > Hi Adam, > > > > I should have been more clear. The code review request should indicate > > what kind of testing has been done on the change. Could be something > > like: > > > > - Ran through jdk_submit with no failures. > > - Also ran the test from the bug report on Linux or Win* or XXX. > > > > So I see that you've run the bug specific test. Did you run any other > > testing like jdk_submit? > > > > Dan > > > > > On 8/13/19 12:00 PM, Adam Farley8 wrote: > > Hi Daniel, > > > > The basic test case is described in the bug: > > > > java -Dsun.boot.library.path=$LONGPATH:$RIGHTPATH AnyClass > > > > (where LONGPATH has >5k characters in it) > > > > As this code path is executed during library loading at startup, > > this test case should be enough to demonstrate the fix. > > > > Does this answer your question? > > > > Best Regards > > > > Adam Farley > > IBM Runtimes > > > > > > "Daniel D. Daugherty" wrote on 13/08/ > > 2019 16:51:56: > > > > > From: "Daniel D. Daugherty" > > > To: Adam Farley8 , David Holmes > > > > > > Cc: hotspot-dev at openjdk.java.net > > > Date: 13/08/2019 16:52 > > > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > > > paths are longer than JVM_MAXPATHLEN > > > > > > I don't see any information describing how this change was tested. > > > > > > Dan > > > > > > > > > On 8/13/19 11:48 AM, Adam Farley8 wrote: > > > > Hi David, > > > > > > > > Since we have two positive reviews (yours and Serguei's), could you > > > > sponsor the change please? > > > > > > > > Best Regards > > > > > > > > Adam Farley > > > > IBM Runtimes > > > > > > > > > > > > David Holmes wrote on 12/08/2019 23:32:14: > > > > > > > >> From: David Holmes > > > >> To: Adam Farley8 > > > >> Cc: hotspot-dev at openjdk.java.net, "serguei.spitsyn at oracle.com" > > > >> > > > >> Date: 12/08/2019 23:32 > > > >> Subject: Re: RFR: JDK-8227021: VM fails if any > sun.boot.library.path > > > >> paths are longer than JVM_MAXPATHLEN > > > >> > > > >> Looks fine. > > > >> > > > >> Thanks, > > > >> David > > > >> > > > >> On 13/08/2019 1:19 am, Adam Farley8 wrote: > > > >>> Hi David, > > > >>> > > > >>> Changes made as requested: > > > >>> https://urldefense.proofpoint.com/v2/url? > > > >> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.4_webrev&d=DwID- > > > >> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > > >> > > > > > > > > > > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=mZM8IR4e_zmrfcsF3XJjoGEMrZb4WtEL7Y6Ugd6Naqg&s=sZ2UKqqUIq0El- > > > >> RsqYz6jmTh4Q2UghwdrQX6of8Lw0E&e= > > > >>> Best Regards > > > >>> > > > >>> Adam Farley > > > >>> IBM Runtimes > > > >>> > > > >>> > > > >>> David Holmes wrote on 12/08/2019 > 04:55:36: > > > >>> > > > >>>> From: David Holmes > > > >>>> To: Adam Farley8 , > > > >>>> "serguei.spitsyn at oracle.com" > > > >>>> Cc: hotspot-dev at openjdk.java.net > > > >>>> Date: 12/08/2019 04:56 > > > >>>> Subject: Re: RFR: JDK-8227021: ?VM fails if any > sun.boot.library.path > > > >>>> paths are longer than JVM_MAXPATHLEN > > > >>>> > > > >>>> Hi Adam, > > > >>>> > > > >>>> On 10/08/2019 2:47 am, Adam Farley8 wrote: > > > >>>>> Hi Serguei, David, > > > >>>>> > > > >>>>> My turn to apologise for the delay. :) > > > >>>>> > > > >>>>> I've modified the code as per Serguei's request. Take a look > ?and > > > > let me > > > >>>>> know if this is the sort of thing you were thinking of. > > > >>>>> > > > >>>>> Webrev: https://urldefense.proofpoint.com/v2/url? > > > >>>> > u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.3_webrev_&d=DwID- > > > >>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > > >>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > > > >>>> > > > > > > > > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=L19aeFXoR9JIO62QRPFzZObIU8RbhpCtXSvUibD2ISk&e= > > > >>>> I'd prefer to see the helper just as a file static function > rather > > > > than > > > >>>> adding it to the os class. > > > >>>> > > > >>>> + ?* supplied array of arrays of chars (a), where n > > > >>>> > > > >>>> I assume (a) is meant to refer to the parameter, but you actually > > > > called > > > >>>> it arrayarray. I think "a" or "arr" would suffice. > > > >>>> > > > >>>> Thanks, > > > >>>> David > > > >>>> > > > >>>>> Best Regards > > > >>>>> > > > >>>>> Adam Farley > > > >>>>> IBM Runtimes > > > >>>>> > > > >>>>> > > > >>>>> "serguei.spitsyn at oracle.com" > ?wrote on > > > >>>>> 31/07/2019 17:18:05: > > > >>>>> > > > >>>>>> From: "serguei.spitsyn at oracle.com" > > > >>>>>> To: Adam Farley8 , ?David ?Holmes > > > >>>>>> > > > >>>>>> Cc: serviceability-dev , > > > >>>>>> hotspot-dev at openjdk.java.net > > > >>>>>> Date: 31/07/2019 17:18 > > > >>>>>> Subject: Re: RFR: JDK-8227021: ?VM fails if any > > > > sun.boot.library.path > > > >>>>>> paths are longer than JVM_MAXPATHLEN > > > >>>>>> > > > >>>>>> Hi Adam, > > > >>>>>> > > > >>>>>> It looks Okay to me. > > > >>>>>> > > > >>>>>> A couple of minor comments. > > > >>>>>> > > > >>>>>> https://urldefense.proofpoint.com/v2/url? > > > >>>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021. > > > >>>> 2_webrev_src_hotspot_&d=DwID-g&c=jf_iaSHvJObTbx- > > > >>>> > siA1ZOg&r=P5m8KWUXJf-CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > > > >>>> > > > > > > > > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NL6tYuwwDod3DSmj-1ztxAywpO8L52HEyO0wvTR05bs&e= > > > >>>>>> share/runtime/os.cpp.frames.html > > > >>>>>> 1362 ? ? ? //release ?allocated storage ?before exiting the vm > > > >>>>>> 1363 ? ? ? while (i > 0) { > > > >>>>>> 1364 i--; > > > >>>>>> 1365 if (opath[i] != NULL) ?{ > > > >>>>>> 1366 ? FREE_C_HEAP_ARRAY(char, ? opath[i]); > > > >>>>>> 1367 } > > > >>>>>> 1368 ? ? ? } > > > >>>>>> 1369 FREE_C_HEAP_ARRAY(char*, opath); > > > >>>>>> > > > >>>>>> 1377 ? ? ? //release allocated storage before ?returning ?null > > > >>>>>> 1378 ? ? ? while (i > 0) { > > > >>>>>> 1379 i--; > > > >>>>>> 1380 if (opath[i] != NULL) ?{ > > > >>>>>> 1381 ? FREE_C_HEAP_ARRAY(char, ? opath[i]); > > > >>>>>> 1382 } > > > >>>>>> 1383 ? ? ? } > > > >>>>>> 1384 FREE_C_HEAP_ARRAY(char*, opath); > > > >>>>>> > > > >>>>>> This duplicated fragments is worth to refactor to a function. > > > >>>>>> Also a space is missed at the beginning of the comment. > > > >>>>>> > > > >>>>>> > > > >>>>>> Thanks, > > > >>>>>> Serguei > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>> On 7/31/19 02:01, Adam Farley8 wrote: > > > >>>>>> Hi All, > > > >>>>>> > > > >>>>>> Reviewers requested for the change below. > > > >>>>>> > > > >>>>>> @David - Agreed. Would you be prepared to sponsor the change? > > > >>>>>> > > > >>>>>> Bug: https://urldefense.proofpoint.com/v2/url? > > > >>>> u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8227021&d=DwID- > > > >>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > > >>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > > > >>>> > > > > > > > > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=xykJ0KLy9AKWO8zmC0amfR7xxUsvyKEjlf3y7WWOqvE&e= > > > >>>>>> Webrev: https://urldefense.proofpoint.com/v2/url? > > > >>>> > u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.2_webrev_&d=DwID- > > > >>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > > >>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > > > >>>> > > > > > > > > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NvIza4VVWG3CiDhmQVmXsghH_4h_c5mFJbHwkCUcut0&e= > > > >>>>>> Best Regards > > > >>>>>> > > > >>>>>> Adam Farley > > > >>>>>> IBM Runtimes > > > >>>>>> > > > >>>>>> P.S. Remembered to add the links this time. :) > > > >>>>>> > > > >>>>>> > > > >>>>>> David Holmes wrote on 30/07/2019 > > > > 03:37:53: > > > >>>>>>> From: David Holmes > > > >>>>>>> To: Adam Farley8 > > > >>>>>>> Cc: hotspot-dev at openjdk.java.net, serviceability-dev > > > >>>>>>> > > > >>>>>>> Date: 30/07/2019 03:38 > > > >>>>>>> Subject: Re: RFR: JDK-8227021: VM fails if any > > > > sun.boot.library.path > > > >>>>>>> paths are longer than JVM_MAXPATHLEN > > > >>>>>>> > > > >>>>>>> Hi Adam, > > > >>>>>>> > > > >>>>>>> On 25/07/2019 3:57 am, Adam Farley8 wrote: > > > >>>>>>>> Hi David, > > > >>>>>>>> > > > >>>>>>>> Welcome back. :) > > > >>>>>>> Thanks. Sorry for the delay in getting back to this. > > > >>>>>>> > > > >>>>>>> I like .v2 as it is much simpler (notwithstanding freeing > > > >> the ?already > > > >>>>>>> allocated arrays adds some complexity - thanks for fixing > that). > > > >>>>>>> > > > >>>>>>> I'm still not sure we can't optimise things better for > > > > unchangeable > > > >>>>>>> properties like the boot libary path, but that's another ?RFE. > > > >>>>>>> > > > >>>>>>> Thanks, > > > >>>>>>> David > > > >>>>>>> > > > >>>>>> 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 > > > > 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 adam.farley at uk.ibm.com Tue Aug 13 16:36:44 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Tue, 13 Aug 2019 17:36:44 +0100 Subject: RFR: JDK-8227021: VM fails if any sun.boot.library.path paths are longer than JVM_MAXPATHLEN In-Reply-To: <9c8ef3d4-44e3-9193-310d-d9ce1d14dcb7@oracle.com> References: <25234969-2215-57e9-d8c5-d97b5669ebb1@oracle.com> <5ba808b0-ae52-0d0a-b84b-fc34df35475d@oracle.com> <025da83a-6569-f6ac-7590-5b200ed2344f@oracle.com> <8e62fc61-b46b-0033-f182-cb4a2dbf92fd@oracle.com> Message-ID: Hi Serguei, Daniel, I ran the bug specific test mentioned in the bug, as well as this: test/hotspot/jtreg/sanity No failures. Well, except for the one we wanted in the bug test. :) On reflection, this seems thin, so I'm running some more hotspot tests now. Advice welcome. Best Regards Adam Farley IBM Runtimes "serguei.spitsyn at oracle.com" wrote on 13/08/2019 17:09:17: > From: "serguei.spitsyn at oracle.com" > To: Adam Farley8 , David Holmes > > Cc: hotspot-dev at openjdk.java.net > Date: 13/08/2019 17:20 > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > paths are longer than JVM_MAXPATHLEN > > Hi Adam, > > Could you, please, tell a little bit on how did you test the fix? > > Thanks, > Serguei > > > On 8/13/19 09:00, serguei.spitsyn at oracle.com wrote: > Hi Adam, > > I'll sponsor the push. > > Thanks, > Serguei > > > On 8/13/19 08:48, Adam Farley8 wrote: > Hi David, > > Since we have two positive reviews (yours and Serguei's), could you > sponsor the change please? > > Best Regards > > Adam Farley > IBM Runtimes > > > David Holmes wrote on 12/08/2019 23:32:14: > > > From: David Holmes > > To: Adam Farley8 > > Cc: hotspot-dev at openjdk.java.net, "serguei.spitsyn at oracle.com" > > > > Date: 12/08/2019 23:32 > > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > > paths are longer than JVM_MAXPATHLEN > > > > Looks fine. > > > > Thanks, > > David > > > > On 13/08/2019 1:19 am, Adam Farley8 wrote: > > > Hi David, > > > > > > Changes made as requested: > > > https://urldefense.proofpoint.com/v2/url? > > u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.4_webrev&d=DwID- > > g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=mZM8IR4e_zmrfcsF3XJjoGEMrZb4WtEL7Y6Ugd6Naqg&s=sZ2UKqqUIq0El- > > RsqYz6jmTh4Q2UghwdrQX6of8Lw0E&e= > > > > > > Best Regards > > > > > > Adam Farley > > > IBM Runtimes > > > > > > > > > David Holmes wrote on 12/08/2019 04:55:36: > > > > > >> From: David Holmes > > >> To: Adam Farley8 , > > >> "serguei.spitsyn at oracle.com" > > >> Cc: hotspot-dev at openjdk.java.net > > >> Date: 12/08/2019 04:56 > > >> Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > > >> paths are longer than JVM_MAXPATHLEN > > >> > > >> Hi Adam, > > >> > > >> On 10/08/2019 2:47 am, Adam Farley8 wrote: > > >> > Hi Serguei, David, > > >> > > > >> > My turn to apologise for the delay. :) > > >> > > > >> > I've modified the code as per Serguei's request. Take a look > and let me > > >> > know if this is the sort of thing you were thinking of. > > >> > > > >> > Webrev: https://urldefense.proofpoint.com/v2/url? > > >> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.3_webrev_&d=DwID- > > >> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > >> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > > >> > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=L19aeFXoR9JIO62QRPFzZObIU8RbhpCtXSvUibD2ISk&e= > > >> > > >> I'd prefer to see the helper just as a file static function rather than > > >> adding it to the os class. > > >> > > >> + * supplied array of arrays of chars (a), where n > > >> > > >> I assume (a) is meant to refer to the parameter, but you actually called > > >> it arrayarray. I think "a" or "arr" would suffice. > > >> > > >> Thanks, > > >> David > > >> > > >> > Best Regards > > >> > > > >> > Adam Farley > > >> > IBM Runtimes > > >> > > > >> > > > >> > "serguei.spitsyn at oracle.com" wrote on > > >> > 31/07/2019 17:18:05: > > >> > > > >> >> From: "serguei.spitsyn at oracle.com" > > >> >> To: Adam Farley8 , David Holmes > > >> >> > > >> >> Cc: serviceability-dev , > > >> >> hotspot-dev at openjdk.java.net > > >> >> Date: 31/07/2019 17:18 > > >> >> Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > > >> >> paths are longer than JVM_MAXPATHLEN > > >> >> > > >> >> Hi Adam, > > >> >> > > >> >> It looks Okay to me. > > >> >> > > >> >> A couple of minor comments. > > >> >> > > >> >> https://urldefense.proofpoint.com/v2/url? > > >> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021. > > >> 2_webrev_src_hotspot_&d=DwID-g&c=jf_iaSHvJObTbx- > > >> siA1ZOg&r=P5m8KWUXJf-CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > > >> > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NL6tYuwwDod3DSmj-1ztxAywpO8L52HEyO0wvTR05bs&e= > > >> >> share/runtime/os.cpp.frames.html > > >> > > > >> >> 1362 //release allocated storage before exiting the vm > > >> >> 1363 while (i > 0) { > > >> >> 1364 i--; > > >> >> 1365 if (opath[i] != NULL) { > > >> >> 1366 FREE_C_HEAP_ARRAY(char, opath[i]); > > >> >> 1367 } > > >> >> 1368 } > > >> >> 1369 FREE_C_HEAP_ARRAY(char*, opath); > > >> >> > > >> >> 1377 //release allocated storage before returning null > > >> >> 1378 while (i > 0) { > > >> >> 1379 i--; > > >> >> 1380 if (opath[i] != NULL) { > > >> >> 1381 FREE_C_HEAP_ARRAY(char, opath[i]); > > >> >> 1382 } > > >> >> 1383 } > > >> >> 1384 FREE_C_HEAP_ARRAY(char*, opath); > > >> >> > > >> >> This duplicated fragments is worth to refactor to a function. > > >> >> Also a space is missed at the beginning of the comment. > > >> >> > > >> >> > > >> >> Thanks, > > >> >> Serguei > > >> >> > > >> >> > > >> >> > > >> >> On 7/31/19 02:01, Adam Farley8 wrote: > > >> >> Hi All, > > >> >> > > >> >> Reviewers requested for the change below. > > >> >> > > >> >> @David - Agreed. Would you be prepared to sponsor the change? > > >> >> > > >> >> Bug: https://urldefense.proofpoint.com/v2/url? > > >> u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8227021&d=DwID- > > >> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > >> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > > >> > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=xykJ0KLy9AKWO8zmC0amfR7xxUsvyKEjlf3y7WWOqvE&e= > > >> >> Webrev: https://urldefense.proofpoint.com/v2/url? > > >> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.2_webrev_&d=DwID- > > >> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > >> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > > >> > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NvIza4VVWG3CiDhmQVmXsghH_4h_c5mFJbHwkCUcut0&e= > > >> >> > > >> >> Best Regards > > >> >> > > >> >> Adam Farley > > >> >> IBM Runtimes > > >> >> > > >> >> P.S. Remembered to add the links this time. :) > > >> >> > > >> >> > > >> >> David Holmes wrote on 30/07/2019 03:37:53: > > >> >> > > >> >> > From: David Holmes > > >> >> > To: Adam Farley8 > > >> >> > Cc: hotspot-dev at openjdk.java.net, serviceability-dev > > >> >> > > > >> >> > Date: 30/07/2019 03:38 > > >> >> > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > > >> >> > paths are longer than JVM_MAXPATHLEN > > >> >> > > > >> >> > Hi Adam, > > >> >> > > > >> >> > On 25/07/2019 3:57 am, Adam Farley8 wrote: > > >> >> > > Hi David, > > >> >> > > > > >> >> > > Welcome back. :) > > >> >> > > > >> >> > Thanks. Sorry for the delay in getting back to this. > > >> >> > > > >> >> > I like .v2 as it is much simpler (notwithstanding freeing > > the already > > >> >> > allocated arrays adds some complexity - thanks for fixing that). > > >> >> > > > >> >> > I'm still not sure we can't optimise things better for unchangeable > > >> >> > properties like the boot libary path, but that's another RFE. > > >> >> > > > >> >> > Thanks, > > >> >> > David > > >> >> > > > >> >> 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 > > > > 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 daniel.daugherty at oracle.com Tue Aug 13 16:57:50 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 13 Aug 2019 12:57:50 -0400 Subject: RFR: JDK-8227021: VM fails if any sun.boot.library.path paths are longer than JVM_MAXPATHLEN In-Reply-To: <37e96eab-c066-0b0f-e2b2-e9ac132d6c00@oracle.com> References: <5ba808b0-ae52-0d0a-b84b-fc34df35475d@oracle.com> <025da83a-6569-f6ac-7590-5b200ed2344f@oracle.com> <8e62fc61-b46b-0033-f182-cb4a2dbf92fd@oracle.com> <7170e79e-1141-ebf9-6576-e05e9e35d912@oracle.com> <37e96eab-c066-0b0f-e2b2-e9ac132d6c00@oracle.com> Message-ID: <993abc4d-1f8f-054e-b966-b8d4ca02aab3@oracle.com> Just realized that I forgot to include this link: https://wiki.openjdk.java.net/display/Build/Submit+Repo Sorry about that... Dan On 8/13/19 12:17 PM, Daniel D. Daugherty wrote: > Let's see what Serguei (or David) says about testing needed. > Looks like he reviewed this change (and your other one too)... > > I haven't reviewed either change... I just happened to notice > that nothing was said in the RFR about testing... > > Dan > > > On 8/13/19 12:14 PM, Adam Farley8 wrote: >> Hi Daniel, >> >> As this change isn't a part of the class libraries, and this code >> path is exercised during startup, I neglected to run testing beyond >> the bug specific tests and variants theron. >> >> I'm happy to take recommendations for the tests I should run. >> >> I'm not familiar with jdk_submit. Google isn't helping, nor is a >> jdk/jdk search. Can you advise on how I can run it? >> >> Best Regards >> >> Adam Farley >> IBM Runtimes >> >> >> "Daniel D. Daugherty" wrote on >> 13/08/2019 17:05:20: >> >> > From: "Daniel D. Daugherty" >> > To: Adam Farley8 >> > Cc: David Holmes , hotspot-dev at openjdk.java.net >> > Date: 13/08/2019 17:05 >> > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path >> > paths are longer than JVM_MAXPATHLEN >> > >> > Hi Adam, >> > >> > I should have been more clear. The code review request should indicate >> > what kind of testing has been done on the change. Could be something >> > like: >> > >> > - Ran through jdk_submit with no failures. >> > - Also ran the test from the bug report on Linux or Win* or XXX. >> > >> > So I see that you've run the bug specific test. Did you run any other >> > testing like jdk_submit? >> > >> > Dan >> > >> >> > On 8/13/19 12:00 PM, Adam Farley8 wrote: >> > Hi Daniel, >> > >> > The basic test case is described in the bug: >> > >> > java -Dsun.boot.library.path=$LONGPATH:$RIGHTPATH AnyClass >> > >> > (where LONGPATH has >5k characters in it) >> > >> > As this code path is executed during library loading at startup, >> > this test case should be enough to demonstrate the fix. >> > >> > Does this answer your question? >> > >> > Best Regards >> > >> > Adam Farley >> > IBM Runtimes >> > >> > >> > "Daniel D. Daugherty" wrote on 13/08/ >> > 2019 16:51:56: >> > >> > > From: "Daniel D. Daugherty" >> > > To: Adam Farley8 , David Holmes >> > > >> > > Cc: hotspot-dev at openjdk.java.net >> > > Date: 13/08/2019 16:52 >> > > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path >> > > paths are longer than JVM_MAXPATHLEN >> > > >> > > I don't see any information describing how this change was tested. >> > > >> > > Dan >> > > >> > > >> > > On 8/13/19 11:48 AM, Adam Farley8 wrote: >> > > > Hi David, >> > > > >> > > > Since we have two positive reviews (yours and Serguei's), could you >> > > > sponsor the change please? >> > > > >> > > > Best Regards >> > > > >> > > > Adam Farley >> > > > IBM Runtimes >> > > > >> > > > >> > > > David Holmes wrote on 12/08/2019 >> 23:32:14: >> > > > >> > > >> From: David Holmes >> > > >> To: Adam Farley8 >> > > >> Cc: hotspot-dev at openjdk.java.net, "serguei.spitsyn at oracle.com" >> > > >> >> > > >> Date: 12/08/2019 23:32 >> > > >> Subject: Re: RFR: JDK-8227021: VM fails if any >> sun.boot.library.path >> > > >> paths are longer than JVM_MAXPATHLEN >> > > >> >> > > >> Looks fine. >> > > >> >> > > >> Thanks, >> > > >> David >> > > >> >> > > >> On 13/08/2019 1:19 am, Adam Farley8 wrote: >> > > >>> Hi David, >> > > >>> >> > > >>> Changes made as requested: >> > > >>> https://urldefense.proofpoint.com/v2/url? >> > > >> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.4_webrev&d=DwID- >> > > >> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- >> > > >> >> > > > >> > > >> > >> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=mZM8IR4e_zmrfcsF3XJjoGEMrZb4WtEL7Y6Ugd6Naqg&s=sZ2UKqqUIq0El- >> > > >> RsqYz6jmTh4Q2UghwdrQX6of8Lw0E&e= >> > > >>> Best Regards >> > > >>> >> > > >>> Adam Farley >> > > >>> IBM Runtimes >> > > >>> >> > > >>> >> > > >>> David Holmes wrote on 12/08/2019 >> 04:55:36: >> > > >>> >> > > >>>> From: David Holmes >> > > >>>> To: Adam Farley8 , >> > > >>>> "serguei.spitsyn at oracle.com" >> > > >>>> Cc: hotspot-dev at openjdk.java.net >> > > >>>> Date: 12/08/2019 04:56 >> > > >>>> Subject: Re: RFR: JDK-8227021: ?VM fails if any >> sun.boot.library.path >> > > >>>> paths are longer than JVM_MAXPATHLEN >> > > >>>> >> > > >>>> Hi Adam, >> > > >>>> >> > > >>>> On 10/08/2019 2:47 am, Adam Farley8 wrote: >> > > >>>>> Hi Serguei, David, >> > > >>>>> >> > > >>>>> My turn to apologise for the delay. :) >> > > >>>>> >> > > >>>>> I've modified the code as per Serguei's request. Take a >> look ?and >> > > > let me >> > > >>>>> know if this is the sort of thing you were thinking of. >> > > >>>>> >> > > >>>>> Webrev: https://urldefense.proofpoint.com/v2/url? >> > > >>>> >> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.3_webrev_&d=DwID- >> > > >>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- >> > > >>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- >> > > >>>> >> > > > >> > > >> > >> yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=L19aeFXoR9JIO62QRPFzZObIU8RbhpCtXSvUibD2ISk&e= >> > > >>>> I'd prefer to see the helper just as a file static function >> rather >> > > > than >> > > >>>> adding it to the os class. >> > > >>>> >> > > >>>> + ?* supplied array of arrays of chars (a), where n >> > > >>>> >> > > >>>> I assume (a) is meant to refer to the parameter, but you >> actually >> > > > called >> > > >>>> it arrayarray. I think "a" or "arr" would suffice. >> > > >>>> >> > > >>>> Thanks, >> > > >>>> David >> > > >>>> >> > > >>>>> Best Regards >> > > >>>>> >> > > >>>>> Adam Farley >> > > >>>>> IBM Runtimes >> > > >>>>> >> > > >>>>> >> > > >>>>> "serguei.spitsyn at oracle.com" >> ?wrote on >> > > >>>>> 31/07/2019 17:18:05: >> > > >>>>> >> > > >>>>>> From: "serguei.spitsyn at oracle.com" >> >> > > >>>>>> To: Adam Farley8 , ?David ?Holmes >> > > >>>>>> >> > > >>>>>> Cc: serviceability-dev , >> > > >>>>>> hotspot-dev at openjdk.java.net >> > > >>>>>> Date: 31/07/2019 17:18 >> > > >>>>>> Subject: Re: RFR: JDK-8227021: ?VM fails if any >> > > > sun.boot.library.path >> > > >>>>>> paths are longer than JVM_MAXPATHLEN >> > > >>>>>> >> > > >>>>>> Hi Adam, >> > > >>>>>> >> > > >>>>>> It looks Okay to me. >> > > >>>>>> >> > > >>>>>> A couple of minor comments. >> > > >>>>>> >> > > >>>>>> https://urldefense.proofpoint.com/v2/url? >> > > >>>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021. >> > > >>>> 2_webrev_src_hotspot_&d=DwID-g&c=jf_iaSHvJObTbx- >> > > >>>> >> siA1ZOg&r=P5m8KWUXJf-CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- >> > > >>>> >> > > > >> > > >> > >> yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NL6tYuwwDod3DSmj-1ztxAywpO8L52HEyO0wvTR05bs&e= >> > > >>>>>> share/runtime/os.cpp.frames.html >> > > >>>>>> 1362 ? ? ? //release ?allocated storage ?before exiting the vm >> > > >>>>>> 1363 ? ? ? while (i > 0) { >> > > >>>>>> 1364 ? ? ? ? ? i--; >> > > >>>>>> 1365 ? ? ? ? ? if (opath[i] != NULL) ?{ >> > > >>>>>> 1366 FREE_C_HEAP_ARRAY(char, ? opath[i]); >> > > >>>>>> 1367 ? ? ? ? ? } >> > > >>>>>> 1368 ? ? ? } >> > > >>>>>> 1369 FREE_C_HEAP_ARRAY(char*, opath); >> > > >>>>>> >> > > >>>>>> 1377 ? ? ? //release allocated storage before ?returning ?null >> > > >>>>>> 1378 ? ? ? while (i > 0) { >> > > >>>>>> 1379 ? ? ? ? ? i--; >> > > >>>>>> 1380 ? ? ? ? ? if (opath[i] != NULL) ?{ >> > > >>>>>> 1381 FREE_C_HEAP_ARRAY(char, ? opath[i]); >> > > >>>>>> 1382 ? ? ? ? ? } >> > > >>>>>> 1383 ? ? ? } >> > > >>>>>> 1384 FREE_C_HEAP_ARRAY(char*, opath); >> > > >>>>>> >> > > >>>>>> This duplicated fragments is worth to refactor to a function. >> > > >>>>>> Also a space is missed at the beginning of the comment. >> > > >>>>>> >> > > >>>>>> >> > > >>>>>> Thanks, >> > > >>>>>> Serguei >> > > >>>>>> >> > > >>>>>> >> > > >>>>>> >> > > >>>>>> On 7/31/19 02:01, Adam Farley8 wrote: >> > > >>>>>> Hi All, >> > > >>>>>> >> > > >>>>>> Reviewers requested for the change below. >> > > >>>>>> >> > > >>>>>> @David - Agreed. Would you be prepared to sponsor the change? >> > > >>>>>> >> > > >>>>>> Bug: https://urldefense.proofpoint.com/v2/url? >> > > >>>> u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8227021&d=DwID- >> > > >>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- >> > > >>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- >> > > >>>> >> > > > >> > > >> > >> yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=xykJ0KLy9AKWO8zmC0amfR7xxUsvyKEjlf3y7WWOqvE&e= >> > > >>>>>> Webrev: https://urldefense.proofpoint.com/v2/url? >> > > >>>> >> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.2_webrev_&d=DwID- >> > > >>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- >> > > >>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- >> > > >>>> >> > > > >> > > >> > >> yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NvIza4VVWG3CiDhmQVmXsghH_4h_c5mFJbHwkCUcut0&e= >> > > >>>>>> Best Regards >> > > >>>>>> >> > > >>>>>> Adam Farley >> > > >>>>>> IBM Runtimes >> > > >>>>>> >> > > >>>>>> P.S. Remembered to add the links this time. :) >> > > >>>>>> >> > > >>>>>> >> > > >>>>>> David Holmes wrote on 30/07/2019 >> > > > 03:37:53: >> > > >>>>>>> From: David Holmes >> > > >>>>>>> To: Adam Farley8 >> > > >>>>>>> Cc: hotspot-dev at openjdk.java.net, serviceability-dev >> > > >>>>>>> >> > > >>>>>>> Date: 30/07/2019 03:38 >> > > >>>>>>> Subject: Re: RFR: JDK-8227021: VM fails if any >> > > > sun.boot.library.path >> > > >>>>>>> paths are longer than JVM_MAXPATHLEN >> > > >>>>>>> >> > > >>>>>>> Hi Adam, >> > > >>>>>>> >> > > >>>>>>> On 25/07/2019 3:57 am, Adam Farley8 wrote: >> > > >>>>>>>> Hi David, >> > > >>>>>>>> >> > > >>>>>>>> Welcome back. :) >> > > >>>>>>> Thanks. Sorry for the delay in getting back to this. >> > > >>>>>>> >> > > >>>>>>> I like .v2 as it is much simpler (notwithstanding freeing >> > > >> the ?already >> > > >>>>>>> allocated arrays adds some complexity - thanks for fixing >> that). >> > > >>>>>>> >> > > >>>>>>> I'm still not sure we can't optimise things better for >> > > > unchangeable >> > > >>>>>>> properties like the boot libary path, but that's another >> ?RFE. >> > > >>>>>>> >> > > >>>>>>> Thanks, >> > > >>>>>>> David >> > > >>>>>>> >> > > >>>>>> 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 >> > > > 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 adam.farley at uk.ibm.com Tue Aug 13 17:13:06 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Tue, 13 Aug 2019 18:13:06 +0100 Subject: RFR: JDK-8227021: VM fails if any sun.boot.library.path paths are longer than JVM_MAXPATHLEN In-Reply-To: <993abc4d-1f8f-054e-b966-b8d4ca02aab3@oracle.com> References: <5ba808b0-ae52-0d0a-b84b-fc34df35475d@oracle.com> <025da83a-6569-f6ac-7590-5b200ed2344f@oracle.com> <8e62fc61-b46b-0033-f182-cb4a2dbf92fd@oracle.com> <7170e79e-1141-ebf9-6576-e05e9e35d912@oracle.com> <993abc4d-1f8f-054e-b966-b8d4ca02aab3@oracle.com> Message-ID: Hi Daniel, I'm an author, so I'm not sure I can use this technique to push changes or run tests on the shared openjdk systems. My testing is run locally, on a linux x86 64-bit machine. Best Regards Adam Farley IBM Runtimes "Daniel D. Daugherty" wrote on 13/08/2019 17:57:50: > From: "Daniel D. Daugherty" > To: Adam Farley8 > Cc: David Holmes , hotspot-dev at openjdk.java.net > Date: 13/08/2019 18:09 > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > paths are longer than JVM_MAXPATHLEN > > Just realized that I forgot to include this link: > > https://wiki.openjdk.java.net/display/Build/Submit+Repo > > Sorry about that... > > Dan > > On 8/13/19 12:17 PM, Daniel D. Daugherty wrote: > Let's see what Serguei (or David) says about testing needed. > Looks like he reviewed this change (and your other one too)... > > I haven't reviewed either change... I just happened to notice > that nothing was said in the RFR about testing... > > Dan > > On 8/13/19 12:14 PM, Adam Farley8 wrote: > Hi Daniel, > > As this change isn't a part of the class libraries, and this code > path is exercised during startup, I neglected to run testing beyond > the bug specific tests and variants theron. > > I'm happy to take recommendations for the tests I should run. > > I'm not familiar with jdk_submit. Google isn't helping, nor is a > jdk/jdk search. Can you advise on how I can run it? > > Best Regards > > Adam Farley > IBM Runtimes > > > "Daniel D. Daugherty" wrote on 13/08/ > 2019 17:05:20: > > > From: "Daniel D. Daugherty" > > To: Adam Farley8 > > Cc: David Holmes , hotspot-dev at openjdk.java.net > > Date: 13/08/2019 17:05 > > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > > paths are longer than JVM_MAXPATHLEN > > > > Hi Adam, > > > > I should have been more clear. The code review request should indicate > > what kind of testing has been done on the change. Could be something > > like: > > > > - Ran through jdk_submit with no failures. > > - Also ran the test from the bug report on Linux or Win* or XXX. > > > > So I see that you've run the bug specific test. Did you run any other > > testing like jdk_submit? > > > > Dan > > > > > On 8/13/19 12:00 PM, Adam Farley8 wrote: > > Hi Daniel, > > > > The basic test case is described in the bug: > > > > java -Dsun.boot.library.path=$LONGPATH:$RIGHTPATH AnyClass > > > > (where LONGPATH has >5k characters in it) > > > > As this code path is executed during library loading at startup, > > this test case should be enough to demonstrate the fix. > > > > Does this answer your question? > > > > Best Regards > > > > Adam Farley > > IBM Runtimes > > > > > > "Daniel D. Daugherty" wrote on 13/08/ > > 2019 16:51:56: > > > > > From: "Daniel D. Daugherty" > > > To: Adam Farley8 , David Holmes > > > > > > Cc: hotspot-dev at openjdk.java.net > > > Date: 13/08/2019 16:52 > > > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > > > paths are longer than JVM_MAXPATHLEN > > > > > > I don't see any information describing how this change was tested. > > > > > > Dan > > > > > > > > > On 8/13/19 11:48 AM, Adam Farley8 wrote: > > > > Hi David, > > > > > > > > Since we have two positive reviews (yours and Serguei's), could you > > > > sponsor the change please? > > > > > > > > Best Regards > > > > > > > > Adam Farley > > > > IBM Runtimes > > > > > > > > > > > > David Holmes wrote on 12/08/2019 23:32:14: > > > > > > > >> From: David Holmes > > > >> To: Adam Farley8 > > > >> Cc: hotspot-dev at openjdk.java.net, "serguei.spitsyn at oracle.com" > > > >> > > > >> Date: 12/08/2019 23:32 > > > >> Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > > > >> paths are longer than JVM_MAXPATHLEN > > > >> > > > >> Looks fine. > > > >> > > > >> Thanks, > > > >> David > > > >> > > > >> On 13/08/2019 1:19 am, Adam Farley8 wrote: > > > >>> Hi David, > > > >>> > > > >>> Changes made as requested: > > > >>> https://urldefense.proofpoint.com/v2/url? > > > >> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.4_webrev&d=DwID- > > > >> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > > >> > > > > > > > > > > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=mZM8IR4e_zmrfcsF3XJjoGEMrZb4WtEL7Y6Ugd6Naqg&s=sZ2UKqqUIq0El- > > > >> RsqYz6jmTh4Q2UghwdrQX6of8Lw0E&e= > > > >>> Best Regards > > > >>> > > > >>> Adam Farley > > > >>> IBM Runtimes > > > >>> > > > >>> > > > >>> David Holmes wrote on 12/08/2019 04:55:36: > > > >>> > > > >>>> From: David Holmes > > > >>>> To: Adam Farley8 , > > > >>>> "serguei.spitsyn at oracle.com" > > > >>>> Cc: hotspot-dev at openjdk.java.net > > > >>>> Date: 12/08/2019 04:56 > > > >>>> Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > > > >>>> paths are longer than JVM_MAXPATHLEN > > > >>>> > > > >>>> Hi Adam, > > > >>>> > > > >>>> On 10/08/2019 2:47 am, Adam Farley8 wrote: > > > >>>>> Hi Serguei, David, > > > >>>>> > > > >>>>> My turn to apologise for the delay. :) > > > >>>>> > > > >>>>> I've modified the code as per Serguei's request. Take a look and > > > > let me > > > >>>>> know if this is the sort of thing you were thinking of. > > > >>>>> > > > >>>>> Webrev: https://urldefense.proofpoint.com/v2/url? > > > >>>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.3_webrev_&d=DwID- > > > >>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > > >>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > > > >>>> > > > > > > > > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=L19aeFXoR9JIO62QRPFzZObIU8RbhpCtXSvUibD2ISk&e= > > > >>>> I'd prefer to see the helper just as a file static function rather > > > > than > > > >>>> adding it to the os class. > > > >>>> > > > >>>> + * supplied array of arrays of chars (a), where n > > > >>>> > > > >>>> I assume (a) is meant to refer to the parameter, but you actually > > > > called > > > >>>> it arrayarray. I think "a" or "arr" would suffice. > > > >>>> > > > >>>> Thanks, > > > >>>> David > > > >>>> > > > >>>>> Best Regards > > > >>>>> > > > >>>>> Adam Farley > > > >>>>> IBM Runtimes > > > >>>>> > > > >>>>> > > > >>>>> "serguei.spitsyn at oracle.com" wrote on > > > >>>>> 31/07/2019 17:18:05: > > > >>>>> > > > >>>>>> From: "serguei.spitsyn at oracle.com" > > > >>>>>> To: Adam Farley8 , David Holmes > > > >>>>>> > > > >>>>>> Cc: serviceability-dev , > > > >>>>>> hotspot-dev at openjdk.java.net > > > >>>>>> Date: 31/07/2019 17:18 > > > >>>>>> Subject: Re: RFR: JDK-8227021: VM fails if any > > > > sun.boot.library.path > > > >>>>>> paths are longer than JVM_MAXPATHLEN > > > >>>>>> > > > >>>>>> Hi Adam, > > > >>>>>> > > > >>>>>> It looks Okay to me. > > > >>>>>> > > > >>>>>> A couple of minor comments. > > > >>>>>> > > > >>>>>> https://urldefense.proofpoint.com/v2/url? > > > >>>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021. > > > >>>> 2_webrev_src_hotspot_&d=DwID-g&c=jf_iaSHvJObTbx- > > > >>>> siA1ZOg&r=P5m8KWUXJf-CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > > > >>>> > > > > > > > > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NL6tYuwwDod3DSmj-1ztxAywpO8L52HEyO0wvTR05bs&e= > > > >>>>>> share/runtime/os.cpp.frames.html > > > >>>>>> 1362 //release allocated storage before exiting the vm > > > >>>>>> 1363 while (i > 0) { > > > >>>>>> 1364 i--; > > > >>>>>> 1365 if (opath[i] != NULL) { > > > >>>>>> 1366 FREE_C_HEAP_ARRAY(char, opath[i]); > > > >>>>>> 1367 } > > > >>>>>> 1368 } > > > >>>>>> 1369 FREE_C_HEAP_ARRAY(char*, opath); > > > >>>>>> > > > >>>>>> 1377 //release allocated storage before returning null > > > >>>>>> 1378 while (i > 0) { > > > >>>>>> 1379 i--; > > > >>>>>> 1380 if (opath[i] != NULL) { > > > >>>>>> 1381 FREE_C_HEAP_ARRAY(char, opath[i]); > > > >>>>>> 1382 } > > > >>>>>> 1383 } > > > >>>>>> 1384 FREE_C_HEAP_ARRAY(char*, opath); > > > >>>>>> > > > >>>>>> This duplicated fragments is worth to refactor to a function. > > > >>>>>> Also a space is missed at the beginning of the comment. > > > >>>>>> > > > >>>>>> > > > >>>>>> Thanks, > > > >>>>>> Serguei > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>> On 7/31/19 02:01, Adam Farley8 wrote: > > > >>>>>> Hi All, > > > >>>>>> > > > >>>>>> Reviewers requested for the change below. > > > >>>>>> > > > >>>>>> @David - Agreed. Would you be prepared to sponsor the change? > > > >>>>>> > > > >>>>>> Bug: https://urldefense.proofpoint.com/v2/url? > > > >>>> u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8227021&d=DwID- > > > >>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > > >>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > > > >>>> > > > > > > > > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=xykJ0KLy9AKWO8zmC0amfR7xxUsvyKEjlf3y7WWOqvE&e= > > > >>>>>> Webrev: https://urldefense.proofpoint.com/v2/url? > > > >>>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.2_webrev_&d=DwID- > > > >>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > > >>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > > > >>>> > > > > > > > > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NvIza4VVWG3CiDhmQVmXsghH_4h_c5mFJbHwkCUcut0&e= > > > >>>>>> Best Regards > > > >>>>>> > > > >>>>>> Adam Farley > > > >>>>>> IBM Runtimes > > > >>>>>> > > > >>>>>> P.S. Remembered to add the links this time. :) > > > >>>>>> > > > >>>>>> > > > >>>>>> David Holmes wrote on 30/07/2019 > > > > 03:37:53: > > > >>>>>>> From: David Holmes > > > >>>>>>> To: Adam Farley8 > > > >>>>>>> Cc: hotspot-dev at openjdk.java.net, serviceability-dev > > > >>>>>>> > > > >>>>>>> Date: 30/07/2019 03:38 > > > >>>>>>> Subject: Re: RFR: JDK-8227021: VM fails if any > > > > sun.boot.library.path > > > >>>>>>> paths are longer than JVM_MAXPATHLEN > > > >>>>>>> > > > >>>>>>> Hi Adam, > > > >>>>>>> > > > >>>>>>> On 25/07/2019 3:57 am, Adam Farley8 wrote: > > > >>>>>>>> Hi David, > > > >>>>>>>> > > > >>>>>>>> Welcome back. :) > > > >>>>>>> Thanks. Sorry for the delay in getting back to this. > > > >>>>>>> > > > >>>>>>> I like .v2 as it is much simpler (notwithstanding freeing > > > >> the already > > > >>>>>>> allocated arrays adds some complexity - thanks for fixing that). > > > >>>>>>> > > > >>>>>>> I'm still not sure we can't optimise things better for > > > > unchangeable > > > >>>>>>> properties like the boot libary path, but that's another RFE. > > > >>>>>>> > > > >>>>>>> Thanks, > > > >>>>>>> David > > > >>>>>>> > > > >>>>>> 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 > > > > 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 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 coleen.phillimore at oracle.com Tue Aug 13 21:29:12 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 13 Aug 2019 17:29:12 -0400 Subject: RFR: JDK-8227021: VM fails if any sun.boot.library.path paths are longer than JVM_MAXPATHLEN In-Reply-To: References: <25234969-2215-57e9-d8c5-d97b5669ebb1@oracle.com> <5ba808b0-ae52-0d0a-b84b-fc34df35475d@oracle.com> <025da83a-6569-f6ac-7590-5b200ed2344f@oracle.com> <8e62fc61-b46b-0033-f182-cb4a2dbf92fd@oracle.com> Message-ID: <269929ba-d3a0-96d8-61a0-703210231443@oracle.com> On 8/13/19 11:48 AM, Adam Farley8 wrote: > Hi David, > > Since we have two positive reviews (yours and Serguei's), could you > sponsor the change please? If you get two positive reviews, but then one with comments, you need to also answer that third reviews.? I had some comments on your change, which I'll repeat here: http://cr.openjdk.java.net/~afarley/8227021.2/webrev/src/hotspot/share/runtime/os.cpp.frames.html This is code is unnecessarily hard to read and understand: 1329 char** os::split_path(const char* path, size_t* n) { 1330 size_t pathmod = (size_t)0; 1331 if (n != NULL) { 1332 pathmod = *n; 1333 } 1334 *n = (size_t)0; It appears that 'n' is both an input and output parameter of this function.? Can you just make it another input parameter with some descriptive name.? Is it the length of the library name that you're looking for?? "pathmod" is huh? Then you don't have to check if someone has passed NULL.? There's only one caller to this from what I see. 1352?? char** opath = (char**) NEW_C_HEAP_ARRAY(char*, count, mtInternal); 1353?? if (opath == NULL) { 1354???? return NULL; 1355?? } Not your change but this calls vm_exit_out_of_memory() if NEW_C_HEAP_ARRAY fails.? It doesn't return NULL so you don't have to check. 1375???? char* s? = (char*)NEW_C_HEAP_ARRAY(char, len + 1, mtInternal); Here you want to use NEW_C_HEAP_ARRAY_RETURN_NULL so you can check for null and free memory. The rest seems okay. thanks, Coleen > > Best Regards > > Adam Farley > IBM Runtimes > > > David Holmes wrote on 12/08/2019 23:32:14: > >> From: David Holmes >> To: Adam Farley8 >> Cc: hotspot-dev at openjdk.java.net, "serguei.spitsyn at oracle.com" >> >> Date: 12/08/2019 23:32 >> Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path >> paths are longer than JVM_MAXPATHLEN >> >> Looks fine. >> >> Thanks, >> David >> >> On 13/08/2019 1:19 am, Adam Farley8 wrote: >>> Hi David, >>> >>> Changes made as requested: >>> https://urldefense.proofpoint.com/v2/url? >> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.4_webrev&d=DwID- >> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- >> > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=mZM8IR4e_zmrfcsF3XJjoGEMrZb4WtEL7Y6Ugd6Naqg&s=sZ2UKqqUIq0El- >> RsqYz6jmTh4Q2UghwdrQX6of8Lw0E&e= >>> Best Regards >>> >>> Adam Farley >>> IBM Runtimes >>> >>> >>> David Holmes wrote on 12/08/2019 04:55:36: >>> >>>> From: David Holmes >>>> To: Adam Farley8 , >>>> "serguei.spitsyn at oracle.com" >>>> Cc: hotspot-dev at openjdk.java.net >>>> Date: 12/08/2019 04:56 >>>> Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path >>>> paths are longer than JVM_MAXPATHLEN >>>> >>>> Hi Adam, >>>> >>>> On 10/08/2019 2:47 am, Adam Farley8 wrote: >>>>> Hi Serguei, David, >>>>> >>>>> My turn to apologise for the delay. :) >>>>> >>>>> I've modified the code as per Serguei's request. Take a look and > let me >>>>> know if this is the sort of thing you were thinking of. >>>>> >>>>> Webrev: https://urldefense.proofpoint.com/v2/url? >>>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.3_webrev_&d=DwID- >>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- >>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- >>>> > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=L19aeFXoR9JIO62QRPFzZObIU8RbhpCtXSvUibD2ISk&e= >>>> I'd prefer to see the helper just as a file static function rather > than >>>> adding it to the os class. >>>> >>>> + * supplied array of arrays of chars (a), where n >>>> >>>> I assume (a) is meant to refer to the parameter, but you actually > called >>>> it arrayarray. I think "a" or "arr" would suffice. >>>> >>>> Thanks, >>>> David >>>> >>>>> Best Regards >>>>> >>>>> Adam Farley >>>>> IBM Runtimes >>>>> >>>>> >>>>> "serguei.spitsyn at oracle.com" wrote on >>>>> 31/07/2019 17:18:05: >>>>> >>>>>> From: "serguei.spitsyn at oracle.com" >>>>>> To: Adam Farley8 , David Holmes >>>>>> >>>>>> Cc: serviceability-dev , >>>>>> hotspot-dev at openjdk.java.net >>>>>> Date: 31/07/2019 17:18 >>>>>> Subject: Re: RFR: JDK-8227021: VM fails if any > sun.boot.library.path >>>>>> paths are longer than JVM_MAXPATHLEN >>>>>> >>>>>> Hi Adam, >>>>>> >>>>>> It looks Okay to me. >>>>>> >>>>>> A couple of minor comments. >>>>>> >>>>>> https://urldefense.proofpoint.com/v2/url? >>>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021. >>>> 2_webrev_src_hotspot_&d=DwID-g&c=jf_iaSHvJObTbx- >>>> siA1ZOg&r=P5m8KWUXJf-CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- >>>> > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NL6tYuwwDod3DSmj-1ztxAywpO8L52HEyO0wvTR05bs&e= >>>>>> share/runtime/os.cpp.frames.html >>>>>> 1362 //release allocated storage before exiting the vm >>>>>> 1363 while (i > 0) { >>>>>> 1364 i--; >>>>>> 1365 if (opath[i] != NULL) { >>>>>> 1366 FREE_C_HEAP_ARRAY(char, opath[i]); >>>>>> 1367 } >>>>>> 1368 } >>>>>> 1369 FREE_C_HEAP_ARRAY(char*, opath); >>>>>> >>>>>> 1377 //release allocated storage before returning null >>>>>> 1378 while (i > 0) { >>>>>> 1379 i--; >>>>>> 1380 if (opath[i] != NULL) { >>>>>> 1381 FREE_C_HEAP_ARRAY(char, opath[i]); >>>>>> 1382 } >>>>>> 1383 } >>>>>> 1384 FREE_C_HEAP_ARRAY(char*, opath); >>>>>> >>>>>> This duplicated fragments is worth to refactor to a function. >>>>>> Also a space is missed at the beginning of the comment. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> >>>>>> On 7/31/19 02:01, Adam Farley8 wrote: >>>>>> Hi All, >>>>>> >>>>>> Reviewers requested for the change below. >>>>>> >>>>>> @David - Agreed. Would you be prepared to sponsor the change? >>>>>> >>>>>> Bug: https://urldefense.proofpoint.com/v2/url? >>>> u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8227021&d=DwID- >>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- >>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- >>>> > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=xykJ0KLy9AKWO8zmC0amfR7xxUsvyKEjlf3y7WWOqvE&e= >>>>>> Webrev: https://urldefense.proofpoint.com/v2/url? >>>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.2_webrev_&d=DwID- >>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- >>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- >>>> > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NvIza4VVWG3CiDhmQVmXsghH_4h_c5mFJbHwkCUcut0&e= >>>>>> Best Regards >>>>>> >>>>>> Adam Farley >>>>>> IBM Runtimes >>>>>> >>>>>> P.S. Remembered to add the links this time. :) >>>>>> >>>>>> >>>>>> David Holmes wrote on 30/07/2019 > 03:37:53: >>>>>>> From: David Holmes >>>>>>> To: Adam Farley8 >>>>>>> Cc: hotspot-dev at openjdk.java.net, serviceability-dev >>>>>>> >>>>>>> Date: 30/07/2019 03:38 >>>>>>> Subject: Re: RFR: JDK-8227021: VM fails if any > sun.boot.library.path >>>>>>> paths are longer than JVM_MAXPATHLEN >>>>>>> >>>>>>> Hi Adam, >>>>>>> >>>>>>> On 25/07/2019 3:57 am, Adam Farley8 wrote: >>>>>>>> Hi David, >>>>>>>> >>>>>>>> Welcome back. :) >>>>>>> Thanks. Sorry for the delay in getting back to this. >>>>>>> >>>>>>> I like .v2 as it is much simpler (notwithstanding freeing >> the already >>>>>>> allocated arrays adds some complexity - thanks for fixing that). >>>>>>> >>>>>>> I'm still not sure we can't optimise things better for > unchangeable >>>>>>> properties like the boot libary path, but that's another RFE. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>> 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 > 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 rramakrishna at twitter.com Tue Aug 13 21:53:36 2019 From: rramakrishna at twitter.com (Ramki Ramakrishna) Date: Tue, 13 Aug 2019 14:53:36 -0700 Subject: Buffered Logging? In-Reply-To: References: Message-ID: I'll go ahead and open a JBS ticket to keep the ball rolling on this one, and so we have a place to hang some patches and discussions off of. Scream if I shouldn't. -- ramki On Mon, Aug 12, 2019 at 6:19 PM Ramki Ramakrishna wrote: > > (Resent... Apologies to anyone who might see duplicates. There was an > issue with my membership in the list which, I am guessing, has now been > resolved.) > > ---------- Forwarded message ---------- > From: Ramki Ramakrishna > To: hotspot-dev at openjdk.java.net > Cc: "Liu, Xin" , "Mathiske, Bernd" < > mathiske at amazon.com>, "Hohensee, Paul" , John Coomes > , Tony Printezis > Bcc: > Date: Mon, 12 Aug 2019 15:48:17 -0700 > Subject: Buffered Logging? > > In the JDK 7 time-frame, some folks noticed much longer than expected > pauses that seemed to coincide with GC logging in the midst of a GC > safepoint. In that setup, the GC logs were going to a disk file (these were > often useful for post-mortem analyses) rather than to a RAM-based tmpfs > which had been the original design center assumption. The vicissitudes of > the dirty page flushing policy in Linux when > IO load on the machine (not necessarily the JVM process doing the logging) > could affect the length and duration of these inline logging stalls. > > A buffered logging scheme was then implemented by us (and independently by > others) which we have used successfully to date to avoid these pauses in > high i/o > multi-tenant environments. > > We have recently ported the OpenJDK 8u based scheme past the Unified > Logging related changes and have been using it on OpenJDK 11u. > > In various fora, some of us have heard people express an interest in such > an implementation. > > Would there be appetite for this in openjdk (there are some differences > between our scheme in OpenJDK 8u and their subsequent post-Unified-Logging > port to OpenJDK 11)? > > If so, we'd like to open a JBS ticket, attach some patches rebased to > current OpenJDK tip, and start preparing a webrev for discussion with a > view to possible upstreaming if it converges past review/discussion/debate. > > PS: In recent discussion at the JVMLS, mention was made of something that > might be similar in support of JFR streaming, so our rebase to tip and > familiarization with any JFR-associated buffered logging might well make > this easier or, possibly, moot. > > Thoughts, questions, comments, feedback? > -- ramki > > -- > JVM Team, Platform Engineering, Twitter (San Francisco) > -- JVM Team, Infrastructure Engineering, Twitter (San Francisco) From rramakrishna at twitter.com Tue Aug 13 23:15:32 2019 From: rramakrishna at twitter.com (Ramki Ramakrishna) Date: Tue, 13 Aug 2019 16:15:32 -0700 Subject: Buffered Logging? In-Reply-To: References: Message-ID: I filed https://bugs.openjdk.java.net/browse/JDK-8229517. Please correct/complete if I mangled or neglected to fill any specific required fields. Patches forthcoming in the next few days. -- ramki On Tue, Aug 13, 2019 at 2:53 PM Ramki Ramakrishna wrote: > > I'll go ahead and open a JBS ticket to keep the ball rolling on this one, > and so we have a place to hang some patches and discussions off of. Scream > if I shouldn't. > > -- ramki > > On Mon, Aug 12, 2019 at 6:19 PM Ramki Ramakrishna < > rramakrishna at twitter.com> wrote: > >> >> (Resent... Apologies to anyone who might see duplicates. There was an >> issue with my membership in the list which, I am guessing, has now been >> resolved.) >> >> ---------- Forwarded message ---------- >> From: Ramki Ramakrishna >> To: hotspot-dev at openjdk.java.net >> Cc: "Liu, Xin" , "Mathiske, Bernd" < >> mathiske at amazon.com>, "Hohensee, Paul" , John >> Coomes , Tony Printezis >> Bcc: >> Date: Mon, 12 Aug 2019 15:48:17 -0700 >> Subject: Buffered Logging? >> >> In the JDK 7 time-frame, some folks noticed much longer than expected >> pauses that seemed to coincide with GC logging in the midst of a GC >> safepoint. In that setup, the GC logs were going to a disk file (these were >> often useful for post-mortem analyses) rather than to a RAM-based tmpfs >> which had been the original design center assumption. The vicissitudes of >> the dirty page flushing policy in Linux when >> IO load on the machine (not necessarily the JVM process doing the logging) >> could affect the length and duration of these inline logging stalls. >> >> A buffered logging scheme was then implemented by us (and independently by >> others) which we have used successfully to date to avoid these pauses in >> high i/o >> multi-tenant environments. >> >> We have recently ported the OpenJDK 8u based scheme past the Unified >> Logging related changes and have been using it on OpenJDK 11u. >> >> In various fora, some of us have heard people express an interest in such >> an implementation. >> >> Would there be appetite for this in openjdk (there are some differences >> between our scheme in OpenJDK 8u and their subsequent post-Unified-Logging >> port to OpenJDK 11)? >> >> If so, we'd like to open a JBS ticket, attach some patches rebased to >> current OpenJDK tip, and start preparing a webrev for discussion with a >> view to possible upstreaming if it converges past review/discussion/debate. >> >> PS: In recent discussion at the JVMLS, mention was made of something that >> might be similar in support of JFR streaming, so our rebase to tip and >> familiarization with any JFR-associated buffered logging might well make >> this easier or, possibly, moot. >> >> Thoughts, questions, comments, feedback? >> -- ramki >> >> -- >> JVM Team, Platform Engineering, Twitter (San Francisco) >> > > > -- > JVM Team, Infrastructure Engineering, Twitter (San Francisco) > -- JVM Team, Infrastructure Engineering, Twitter (San Francisco) From kim.barrett at oracle.com Tue Aug 13 23:26:24 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 13 Aug 2019 19:26:24 -0400 Subject: RFR: 8229258: Make markOopDesc AllStatic In-Reply-To: <32ccb4ba-0500-2bf4-3761-63a6285f94dc@oracle.com> References: <72567e47-3b52-8e30-ea6f-9a64fa043c07@redhat.com> <32ccb4ba-0500-2bf4-3761-63a6285f94dc@oracle.com> Message-ID: <5913EBBD-2A13-43A5-9F37-D36E97397365@oracle.com> > On Aug 12, 2019, at 12:19 PM, Stefan Karlsson wrote: > > Hi Roman, > > Kim helped me figuring out how to get past the volatile issues I had with the class markWord { uintptr_t value; ... } version. So, I've created a version with that: > > https://cr.openjdk.java.net/~stefank/8229258/webrev.valueMarkWord.01/ > > I can go with either approach, so let me now what you all think. I've finally had time to look at the first proposed change. Comparing the first approach (an AllStatic MarkWord class and markWord typedef'd to uintptr_t) vs the second approach (markWord is a thin class wrapping around uintptr_t), I prefer the second. * I think the markWord class provides better type safety. It still involves too many casts sprinkled over the code base, but I think it also provides a better basis for further cast reduction and prevention. * I think having one markWord class for the data and behavior is better / more natural than having a markWord typedef for the data and a MarkWord AllStatic class for the behaviour. * I like that the markWord class eliminates the markWord vs MarkWord homonyms, which I think will be annoying. * The markWord class is a trivially copyable class, allowing it to be efficiently passed around by value, so no disadvantage there. I haven't found anything that I think argues for the first over the second. Other folks might have different priorities or taste. I think either is better than the status quo. I'm still reviewing webrev.valueMarkWord.02, but so far haven't found anything that makes me want to suggest backing off from that direction. Note that the bug summary doesn't describe the second approach. From calvin.cheung at oracle.com Tue Aug 13 23:53:34 2019 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Tue, 13 Aug 2019 16:53:34 -0700 Subject: Result: New Hotspot Group Member: Jiangli Zhou Message-ID: The vote for Jiangli Zhou [1][2] is now closed. Yes: 15 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Calvin Cheung [1] https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-July/thread.html#38936 [2] http://mail.openjdk.java.net/pipermail/hotspot-dev/2019-August/thread.html#38996 From rkennke at redhat.com Wed Aug 14 09:11:17 2019 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 14 Aug 2019 11:11:17 +0200 Subject: RFR: 8229258: Make markOopDesc AllStatic In-Reply-To: <5913EBBD-2A13-43A5-9F37-D36E97397365@oracle.com> References: <72567e47-3b52-8e30-ea6f-9a64fa043c07@redhat.com> <32ccb4ba-0500-2bf4-3761-63a6285f94dc@oracle.com> <5913EBBD-2A13-43A5-9F37-D36E97397365@oracle.com> Message-ID: Am 14.08.19 um 01:26 schrieb Kim Barrett: >> On Aug 12, 2019, at 12:19 PM, Stefan Karlsson wrote: >> >> Hi Roman, >> >> Kim helped me figuring out how to get past the volatile issues I had with the class markWord { uintptr_t value; ... } version. So, I've created a version with that: >> >> https://cr.openjdk.java.net/~stefank/8229258/webrev.valueMarkWord.01/ >> >> I can go with either approach, so let me now what you all think. > > I've finally had time to look at the first proposed change. > > Comparing the first approach (an AllStatic MarkWord class and markWord > typedef'd to uintptr_t) vs the second approach (markWord is a thin > class wrapping around uintptr_t), I prefer the second. > > * I think the markWord class provides better type safety. It still > involves too many casts sprinkled over the code base, but I think it > also provides a better basis for further cast reduction and > prevention. > > * I think having one markWord class for the data and behavior is > better / more natural than having a markWord typedef for the data and > a MarkWord AllStatic class for the behaviour. > > * I like that the markWord class eliminates the markWord vs MarkWord > homonyms, which I think will be annoying. > > * The markWord class is a trivially copyable class, allowing it to be > efficiently passed around by value, so no disadvantage there. > > I haven't found anything that I think argues for the first over the > second. Other folks might have different priorities or taste. I think > either is better than the status quo. > > I'm still reviewing webrev.valueMarkWord.02, but so far haven't found > anything that makes me want to suggest backing off from that direction. > > Note that the bug summary doesn't describe the second approach. +1 :-) Roman From adam.farley at uk.ibm.com Wed Aug 14 11:09:33 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Wed, 14 Aug 2019 12:09:33 +0100 Subject: RFR: JDK-8227021: VM fails if any sun.boot.library.path paths are longer than JVM_MAXPATHLEN In-Reply-To: References: <5ba808b0-ae52-0d0a-b84b-fc34df35475d@oracle.com> <025da83a-6569-f6ac-7590-5b200ed2344f@oracle.com> <8e62fc61-b46b-0033-f182-cb4a2dbf92fd@oracle.com> Message-ID: Addendum: I've run the test/hotspot/jtreg/runtime tests against a patched and unpatched build on linux x86 64bit, and the pass/fail rate is identical. 630 passed, 7 failed, and 63 error in both cases. Best Regards Adam Farley IBM Runtimes Adam Farley8/UK/IBM wrote on 13/08/2019 17:36:44: > From: Adam Farley8/UK/IBM > To: "serguei.spitsyn at oracle.com" , > daniel.daugherty at oracle.com > Cc: David Holmes , hotspot-dev at openjdk.java.net > Date: 13/08/2019 17:36 > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > paths are longer than JVM_MAXPATHLEN > > Hi Serguei, Daniel, > > I ran the bug specific test mentioned in the bug, as well as this: > test/hotspot/jtreg/sanity > > No failures. Well, except for the one we wanted in the bug test. :) > > On reflection, this seems thin, so I'm running some more hotspot tests now. > > Advice welcome. > > Best Regards > > Adam Farley > IBM Runtimes > > "serguei.spitsyn at oracle.com" wrote on > 13/08/2019 17:09:17: > > > From: "serguei.spitsyn at oracle.com" > > To: Adam Farley8 , David Holmes > > > > Cc: hotspot-dev at openjdk.java.net > > Date: 13/08/2019 17:20 > > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > > paths are longer than JVM_MAXPATHLEN > > > > Hi Adam, > > > > Could you, please, tell a little bit on how did you test the fix? > > > > Thanks, > > Serguei > > > > > > On 8/13/19 09:00, serguei.spitsyn at oracle.com wrote: > > Hi Adam, > > > > I'll sponsor the push. > > > > Thanks, > > Serguei > > > > > > On 8/13/19 08:48, Adam Farley8 wrote: > > Hi David, > > > > Since we have two positive reviews (yours and Serguei's), could you > > sponsor the change please? > > > > Best Regards > > > > Adam Farley > > IBM Runtimes > > > > > > David Holmes wrote on 12/08/2019 23:32:14: > > > > > From: David Holmes > > > To: Adam Farley8 > > > Cc: hotspot-dev at openjdk.java.net, "serguei.spitsyn at oracle.com" > > > > > > Date: 12/08/2019 23:32 > > > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > > > paths are longer than JVM_MAXPATHLEN > > > > > > Looks fine. > > > > > > Thanks, > > > David > > > > > > On 13/08/2019 1:19 am, Adam Farley8 wrote: > > > > Hi David, > > > > > > > > Changes made as requested: > > > > https://urldefense.proofpoint.com/v2/url? > > > u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.4_webrev&d=DwID- > > > g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > > > > > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=mZM8IR4e_zmrfcsF3XJjoGEMrZb4WtEL7Y6Ugd6Naqg&s=sZ2UKqqUIq0El- > > > RsqYz6jmTh4Q2UghwdrQX6of8Lw0E&e= > > > > > > > > Best Regards > > > > > > > > Adam Farley > > > > IBM Runtimes > > > > > > > > > > > > David Holmes wrote on 12/08/2019 04:55:36: > > > > > > > >> From: David Holmes > > > >> To: Adam Farley8 , > > > >> "serguei.spitsyn at oracle.com" > > > >> Cc: hotspot-dev at openjdk.java.net > > > >> Date: 12/08/2019 04:56 > > > >> Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > > > >> paths are longer than JVM_MAXPATHLEN > > > >> > > > >> Hi Adam, > > > >> > > > >> On 10/08/2019 2:47 am, Adam Farley8 wrote: > > > >> > Hi Serguei, David, > > > >> > > > > >> > My turn to apologise for the delay. :) > > > >> > > > > >> > I've modified the code as per Serguei's request. Take a look > > and let me > > > >> > know if this is the sort of thing you were thinking of. > > > >> > > > > >> > Webrev: https://urldefense.proofpoint.com/v2/url? > > > >> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.3_webrev_&d=DwID- > > > >> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > > >> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > > > >> > > > > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=L19aeFXoR9JIO62QRPFzZObIU8RbhpCtXSvUibD2ISk&e= > > > >> > > > >> I'd prefer to see the helper just as a file static function > rather than > > > >> adding it to the os class. > > > >> > > > >> + * supplied array of arrays of chars (a), where n > > > >> > > > >> I assume (a) is meant to refer to the parameter, but you > actually called > > > >> it arrayarray. I think "a" or "arr" would suffice. > > > >> > > > >> Thanks, > > > >> David > > > >> > > > >> > Best Regards > > > >> > > > > >> > Adam Farley > > > >> > IBM Runtimes > > > >> > > > > >> > > > > >> > "serguei.spitsyn at oracle.com" wrote on > > > >> > 31/07/2019 17:18:05: > > > >> > > > > >> >> From: "serguei.spitsyn at oracle.com" > > > >> >> To: Adam Farley8 , David Holmes > > > >> >> > > > >> >> Cc: serviceability-dev , > > > >> >> hotspot-dev at openjdk.java.net > > > >> >> Date: 31/07/2019 17:18 > > > >> >> Subject: Re: RFR: JDK-8227021: VM fails if any > sun.boot.library.path > > > >> >> paths are longer than JVM_MAXPATHLEN > > > >> >> > > > >> >> Hi Adam, > > > >> >> > > > >> >> It looks Okay to me. > > > >> >> > > > >> >> A couple of minor comments. > > > >> >> > > > >> >> https://urldefense.proofpoint.com/v2/url? > > > >> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021. > > > >> 2_webrev_src_hotspot_&d=DwID-g&c=jf_iaSHvJObTbx- > > > >> siA1ZOg&r=P5m8KWUXJf-CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > > > >> > > > > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NL6tYuwwDod3DSmj-1ztxAywpO8L52HEyO0wvTR05bs&e= > > > >> >> share/runtime/os.cpp.frames.html > > > >> > > > > >> >> 1362 //release allocated storage before exiting the vm > > > >> >> 1363 while (i > 0) { > > > >> >> 1364 i--; > > > >> >> 1365 if (opath[i] != NULL) { > > > >> >> 1366 FREE_C_HEAP_ARRAY(char, opath[i]); > > > >> >> 1367 } > > > >> >> 1368 } > > > >> >> 1369 FREE_C_HEAP_ARRAY(char*, opath); > > > >> >> > > > >> >> 1377 //release allocated storage before returning null > > > >> >> 1378 while (i > 0) { > > > >> >> 1379 i--; > > > >> >> 1380 if (opath[i] != NULL) { > > > >> >> 1381 FREE_C_HEAP_ARRAY(char, opath[i]); > > > >> >> 1382 } > > > >> >> 1383 } > > > >> >> 1384 FREE_C_HEAP_ARRAY(char*, opath); > > > >> >> > > > >> >> This duplicated fragments is worth to refactor to a function. > > > >> >> Also a space is missed at the beginning of the comment. > > > >> >> > > > >> >> > > > >> >> Thanks, > > > >> >> Serguei > > > >> >> > > > >> >> > > > >> >> > > > >> >> On 7/31/19 02:01, Adam Farley8 wrote: > > > >> >> Hi All, > > > >> >> > > > >> >> Reviewers requested for the change below. > > > >> >> > > > >> >> @David - Agreed. Would you be prepared to sponsor the change? > > > >> >> > > > >> >> Bug: https://urldefense.proofpoint.com/v2/url? > > > >> u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8227021&d=DwID- > > > >> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > > >> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > > > >> > > > > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=xykJ0KLy9AKWO8zmC0amfR7xxUsvyKEjlf3y7WWOqvE&e= > > > >> >> Webrev: https://urldefense.proofpoint.com/v2/url? > > > >> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.2_webrev_&d=DwID- > > > >> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > > >> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > > > >> > > > > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NvIza4VVWG3CiDhmQVmXsghH_4h_c5mFJbHwkCUcut0&e= > > > >> >> > > > >> >> Best Regards > > > >> >> > > > >> >> Adam Farley > > > >> >> IBM Runtimes > > > >> >> > > > >> >> P.S. Remembered to add the links this time. :) > > > >> >> > > > >> >> > > > >> >> David Holmes wrote on 30/07/2019 03:37:53: > > > >> >> > > > >> >> > From: David Holmes > > > >> >> > To: Adam Farley8 > > > >> >> > Cc: hotspot-dev at openjdk.java.net, serviceability-dev > > > >> >> > > > > >> >> > Date: 30/07/2019 03:38 > > > >> >> > Subject: Re: RFR: JDK-8227021: VM fails if any > sun.boot.library.path > > > >> >> > paths are longer than JVM_MAXPATHLEN > > > >> >> > > > > >> >> > Hi Adam, > > > >> >> > > > > >> >> > On 25/07/2019 3:57 am, Adam Farley8 wrote: > > > >> >> > > Hi David, > > > >> >> > > > > > >> >> > > Welcome back. :) > > > >> >> > > > > >> >> > Thanks. Sorry for the delay in getting back to this. > > > >> >> > > > > >> >> > I like .v2 as it is much simpler (notwithstanding freeing > > > the already > > > >> >> > allocated arrays adds some complexity - thanks for fixing that). > > > >> >> > > > > >> >> > I'm still not sure we can't optimise things better for > unchangeable > > > >> >> > properties like the boot libary path, but that's another RFE. > > > >> >> > > > > >> >> > Thanks, > > > >> >> > David > > > >> >> > > > > >> >> 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 > > > > > > > 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 david.holmes at oracle.com Thu Aug 15 09:42:35 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 15 Aug 2019 19:42:35 +1000 Subject: RFR: JDK-8227021: VM fails if any sun.boot.library.path paths are longer than JVM_MAXPATHLEN In-Reply-To: <176e6c1c-6e06-b704-0a53-e2cd2800b51f@oracle.com> References: <5ba808b0-ae52-0d0a-b84b-fc34df35475d@oracle.com> <025da83a-6569-f6ac-7590-5b200ed2344f@oracle.com> <8e62fc61-b46b-0033-f182-cb4a2dbf92fd@oracle.com> <176e6c1c-6e06-b704-0a53-e2cd2800b51f@oracle.com> Message-ID: Hi Serguei, On 15/08/2019 6:18 pm, serguei.spitsyn at oracle.com wrote: > Thank you, Adam! > > David, what do you thin about this testing coverage? > Is it enough for this fix? I don't see any real testing of sun.boot.library.path in our tests only: ./hotspot/jtreg/runtime/6819213/TestBootNativeLibraryPath.java ./hotspot/jtreg/runtime/jni/FindClass/FindClassFromBoot.java seem to refer to it but the former is restricted to 32-bit systems only! So this seems to be an area devoid of any real test code outside of 32-bit. I don't understand why that is the case. So if there's no regression test then there's no real testing of this code at all. That said it seems unfair to force Adam to define tests for code that is effectively untested. It would be reasonable for him to extend existing tests to cover the long path problem, if they existed. But a basic regression test should at least be created IMO. David ----- > Thanks, > Serguei > > > On 8/14/19 04:09, Adam Farley8 wrote: >> Addendum: I've run the test/hotspot/jtreg/runtime tests against a >> patched and unpatched build on linux x86 64bit, and the pass/fail rate >> is identical. >> >> 630 passed, 7 failed, and 63 error in both cases. >> >> Best Regards >> >> Adam Farley >> IBM Runtimes >> >> >> Adam Farley8/UK/IBM wrote on 13/08/2019 17:36:44: >> >> > From: Adam Farley8/UK/IBM >> > To: "serguei.spitsyn at oracle.com" , >> > daniel.daugherty at oracle.com >> > Cc: David Holmes , hotspot-dev at openjdk.java.net >> > Date: 13/08/2019 17:36 >> > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path >> > paths are longer than JVM_MAXPATHLEN >> > >> > Hi Serguei, Daniel, >> > >> > I ran the bug specific test mentioned in the bug, as well as this: >> > test/hotspot/jtreg/sanity >> > >> > No failures. Well, except for the one we wanted in the bug test. :) >> > >> > On reflection, this seems thin, so I'm running some more hotspot >> tests now. >> > >> > Advice welcome. >> > >> > Best Regards >> > >> > Adam Farley >> > IBM Runtimes >> >> > >> > "serguei.spitsyn at oracle.com" wrote on >> > 13/08/2019 17:09:17: >> > >> > > From: "serguei.spitsyn at oracle.com" >> > > To: Adam Farley8 , David Holmes >> > > >> > > Cc: hotspot-dev at openjdk.java.net >> > > Date: 13/08/2019 17:20 >> > > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path >> > > paths are longer than JVM_MAXPATHLEN >> > > >> > > Hi Adam, >> > > >> > > Could you, please, tell a little bit on how did you test the fix? >> > > >> > > Thanks, >> > > Serguei >> > > >> > > >> > > On 8/13/19 09:00, serguei.spitsyn at oracle.com wrote: >> > > Hi Adam, >> > > >> > > I'll sponsor the push. >> > > >> > > Thanks, >> > > Serguei >> > > >> > > >> > > On 8/13/19 08:48, Adam Farley8 wrote: >> > > Hi David, >> > > >> > > Since we have two positive reviews (yours and Serguei's), could you >> > > sponsor the change please? >> > > >> > > Best Regards >> > > >> > > Adam Farley >> > > IBM Runtimes >> > > >> > > >> > > David Holmes wrote on 12/08/2019 23:32:14: >> > > >> > > > From: David Holmes >> > > > To: Adam Farley8 >> > > > Cc: hotspot-dev at openjdk.java.net, "serguei.spitsyn at oracle.com" >> > > > >> > > > Date: 12/08/2019 23:32 >> > > > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path >> > > > paths are longer than JVM_MAXPATHLEN >> > > > >> > > > Looks fine. >> > > > >> > > > Thanks, >> > > > David >> > > > >> > > > On 13/08/2019 1:19 am, Adam Farley8 wrote: >> > > > > Hi David, >> > > > > >> > > > > Changes made as requested: >> > > > > https://urldefense.proofpoint.com/v2/url? >> > > > u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.4_webrev&d=DwID- >> > > > g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- >> > > > >> > > >> > >> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=mZM8IR4e_zmrfcsF3XJjoGEMrZb4WtEL7Y6Ugd6Naqg&s=sZ2UKqqUIq0El- >> > > > RsqYz6jmTh4Q2UghwdrQX6of8Lw0E&e= >> > > > > >> > > > > Best Regards >> > > > > >> > > > > Adam Farley >> > > > > IBM Runtimes >> > > > > >> > > > > >> > > > > David Holmes wrote on 12/08/2019 >> 04:55:36: >> > > > > >> > > > >> From: David Holmes >> > > > >> To: Adam Farley8 , >> > > > >> "serguei.spitsyn at oracle.com" >> > > > >> Cc: hotspot-dev at openjdk.java.net >> > > > >> Date: 12/08/2019 04:56 >> > > > >> Subject: Re: RFR: JDK-8227021: ?VM fails if any >> sun.boot.library.path >> > > > >> paths are longer than JVM_MAXPATHLEN >> > > > >> >> > > > >> Hi Adam, >> > > > >> >> > > > >> On 10/08/2019 2:47 am, Adam Farley8 wrote: >> > > > >> > Hi Serguei, David, >> > > > >> > >> > > > >> > My turn to apologise for the delay. :) >> > > > >> > >> > > > >> > I've modified the code as per Serguei's request. Take a look >> > > ?and let me >> > > > >> > know if this is the sort of thing you were thinking of. >> > > > >> > >> > > > >> > Webrev: https://urldefense.proofpoint.com/v2/url? >> > > > >> >> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.3_webrev_&d=DwID- >> > > > >> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- >> > > > >> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- >> > > > >> >> > > > >> > > >> > >> yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=L19aeFXoR9JIO62QRPFzZObIU8RbhpCtXSvUibD2ISk&e= >> > > > >> >> > > > >> I'd prefer to see the helper just as a file static function >> > rather ?than >> > > > >> adding it to the os class. >> > > > >> >> > > > >> + ?* supplied array of arrays of chars (a), where n >> > > > >> >> > > > >> I assume (a) is meant to refer to the parameter, but you >> > actually ?called >> > > > >> it arrayarray. I think "a" or "arr" would suffice. >> > > > >> >> > > > >> Thanks, >> > > > >> David >> > > > >> >> > > > >> > Best Regards >> > > > >> > >> > > > >> > Adam Farley >> > > > >> > IBM Runtimes >> > > > >> > >> > > > >> > >> > > > >> > "serguei.spitsyn at oracle.com" >> ?wrote on >> > > > >> > 31/07/2019 17:18:05: >> > > > >> > >> > > > >> >> From: "serguei.spitsyn at oracle.com" >> >> > > > >> >> To: Adam Farley8 , ?David ?Holmes >> > > > >> >> >> > > > >> >> Cc: serviceability-dev , >> > > > >> >> hotspot-dev at openjdk.java.net >> > > > >> >> Date: 31/07/2019 17:18 >> > > > >> >> Subject: Re: RFR: JDK-8227021: ?VM fails if any >> > sun.boot.library.path >> > > > >> >> paths are longer than JVM_MAXPATHLEN >> > > > >> >> >> > > > >> >> Hi Adam, >> > > > >> >> >> > > > >> >> It looks Okay to me. >> > > > >> >> >> > > > >> >> A couple of minor comments. >> > > > >> >> >> > > > >> >> https://urldefense.proofpoint.com/v2/url? >> > > > >> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021. >> > > > >> 2_webrev_src_hotspot_&d=DwID-g&c=jf_iaSHvJObTbx- >> > > > >> >> siA1ZOg&r=P5m8KWUXJf-CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- >> > > > >> >> > > > >> > > >> > >> yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NL6tYuwwDod3DSmj-1ztxAywpO8L52HEyO0wvTR05bs&e= >> > > > >> >> share/runtime/os.cpp.frames.html >> > > > >> > >> > > > >> >> 1362 ? ? ? //release ?allocated storage ?before exiting the vm >> > > > >> >> 1363 ? ? ? while (i > 0) { >> > > > >> >> 1364 i--; >> > > > >> >> 1365 if (opath[i] != NULL) ?{ >> > > > >> >> 1366 ? FREE_C_HEAP_ARRAY(char, ??opath[i]); >> > > > >> >> 1367 } >> > > > >> >> 1368 ? ? ? } >> > > > >> >> 1369 FREE_C_HEAP_ARRAY(char*, opath); >> > > > >> >> >> > > > >> >> 1377 ? ? ? //release allocated storage before ?returning ?null >> > > > >> >> 1378 ? ? ? while (i > 0) { >> > > > >> >> 1379 i--; >> > > > >> >> 1380 if (opath[i] != NULL) ?{ >> > > > >> >> 1381 ? FREE_C_HEAP_ARRAY(char, ??opath[i]); >> > > > >> >> 1382 } >> > > > >> >> 1383 ? ? ? } >> > > > >> >> 1384 FREE_C_HEAP_ARRAY(char*, opath); >> > > > >> >> >> > > > >> >> This duplicated fragments is worth to refactor to a function. >> > > > >> >> Also a space is missed at the beginning of the comment. >> > > > >> >> >> > > > >> >> >> > > > >> >> Thanks, >> > > > >> >> Serguei >> > > > >> >> >> > > > >> >> >> > > > >> >> >> > > > >> >> On 7/31/19 02:01, Adam Farley8 wrote: >> > > > >> >> Hi All, >> > > > >> >> >> > > > >> >> Reviewers requested for the change below. >> > > > >> >> >> > > > >> >> @David - Agreed. Would you be prepared to sponsor the change? >> > > > >> >> >> > > > >> >> Bug: https://urldefense.proofpoint.com/v2/url? >> > > > >> u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8227021&d=DwID- >> > > > >> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- >> > > > >> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- >> > > > >> >> > > > >> > > >> > >> yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=xykJ0KLy9AKWO8zmC0amfR7xxUsvyKEjlf3y7WWOqvE&e= >> > > > >> >> Webrev: https://urldefense.proofpoint.com/v2/url? >> > > > >> >> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.2_webrev_&d=DwID- >> > > > >> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- >> > > > >> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- >> > > > >> >> > > > >> > > >> > >> yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NvIza4VVWG3CiDhmQVmXsghH_4h_c5mFJbHwkCUcut0&e= >> > > > >> >> >> > > > >> >> Best Regards >> > > > >> >> >> > > > >> >> Adam Farley >> > > > >> >> IBM Runtimes >> > > > >> >> >> > > > >> >> P.S. Remembered to add the links this time. :) >> > > > >> >> >> > > > >> >> >> > > > >> >> David Holmes wrote on >> 30/07/2019?03:37:53: >> > > > >> >> >> > > > >> >> > From: David Holmes >> > > > >> >> > To: Adam Farley8 >> > > > >> >> > Cc: hotspot-dev at openjdk.java.net, serviceability-dev >> > > > >> >> > >> > > > >> >> > Date: 30/07/2019 03:38 >> > > > >> >> > Subject: Re: RFR: JDK-8227021: VM fails if any >> > sun.boot.library.path >> > > > >> >> > paths are longer than JVM_MAXPATHLEN >> > > > >> >> > >> > > > >> >> > Hi Adam, >> > > > >> >> > >> > > > >> >> > On 25/07/2019 3:57 am, Adam Farley8 wrote: >> > > > >> >> > > Hi David, >> > > > >> >> > > >> > > > >> >> > > Welcome back. :) >> > > > >> >> > >> > > > >> >> > Thanks. Sorry for the delay in getting back to this. >> > > > >> >> > >> > > > >> >> > I like .v2 as it is much simpler (notwithstanding freeing >> > > > the ?already >> > > > >> >> > allocated arrays adds some complexity - thanks for >> fixing ?that). >> > > > >> >> > >> > > > >> >> > I'm still not sure we can't optimise things better for >> > ?unchangeable >> > > > >> >> > properties like the boot libary path, but that's another >> ?RFE. >> > > > >> >> > >> > > > >> >> > Thanks, >> > > > >> >> > David >> > > > >> >> > >> > > > >> >> 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 >> > > > >> > > >> > > 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 adam.farley at uk.ibm.com Thu Aug 15 11:40:13 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Thu, 15 Aug 2019 12:40:13 +0100 Subject: RFR: JDK-8227021: VM fails if any sun.boot.library.path paths are longer than JVM_MAXPATHLEN In-Reply-To: References: <025da83a-6569-f6ac-7590-5b200ed2344f@oracle.com> <8e62fc61-b46b-0033-f182-cb4a2dbf92fd@oracle.com> Message-ID: Hi Daniel, Seems reasonable. Will put together a jtreg shell script. Best Regards Adam Farley IBM Runtimes David Holmes wrote on 15/08/2019 10:42:35: > From: David Holmes > To: "serguei.spitsyn at oracle.com" , Adam > Farley8 > Cc: daniel.daugherty at oracle.com, hotspot-dev at openjdk.java.net > Date: 15/08/2019 10:42 > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > paths are longer than JVM_MAXPATHLEN > > Hi Serguei, > > On 15/08/2019 6:18 pm, serguei.spitsyn at oracle.com wrote: > > Thank you, Adam! > > > > David, what do you thin about this testing coverage? > > Is it enough for this fix? > > I don't see any real testing of sun.boot.library.path in our tests only: > > ./hotspot/jtreg/runtime/6819213/TestBootNativeLibraryPath.java > ./hotspot/jtreg/runtime/jni/FindClass/FindClassFromBoot.java > > seem to refer to it but the former is restricted to 32-bit systems only! > So this seems to be an area devoid of any real test code outside of > 32-bit. I don't understand why that is the case. So if there's no > regression test then there's no real testing of this code at all. That > said it seems unfair to force Adam to define tests for code that is > effectively untested. It would be reasonable for him to extend existing > tests to cover the long path problem, if they existed. > > But a basic regression test should at least be created IMO. > > David > ----- > > > Thanks, > > Serguei > > > > > > On 8/14/19 04:09, Adam Farley8 wrote: > >> Addendum: I've run the test/hotspot/jtreg/runtime tests against a > >> patched and unpatched build on linux x86 64bit, and the pass/fail rate > >> is identical. > >> > >> 630 passed, 7 failed, and 63 error in both cases. > >> > >> Best Regards > >> > >> Adam Farley > >> IBM Runtimes > >> > >> > >> Adam Farley8/UK/IBM wrote on 13/08/2019 17:36:44: > >> > >> > From: Adam Farley8/UK/IBM > >> > To: "serguei.spitsyn at oracle.com" , > >> > daniel.daugherty at oracle.com > >> > Cc: David Holmes , hotspot-dev at openjdk.java.net > >> > Date: 13/08/2019 17:36 > >> > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > >> > paths are longer than JVM_MAXPATHLEN > >> > > >> > Hi Serguei, Daniel, > >> > > >> > I ran the bug specific test mentioned in the bug, as well as this: > >> > test/hotspot/jtreg/sanity > >> > > >> > No failures. Well, except for the one we wanted in the bug test. :) > >> > > >> > On reflection, this seems thin, so I'm running some more hotspot > >> tests now. > >> > > >> > Advice welcome. > >> > > >> > Best Regards > >> > > >> > Adam Farley > >> > IBM Runtimes > >> > >> > > >> > "serguei.spitsyn at oracle.com" wrote on > >> > 13/08/2019 17:09:17: > >> > > >> > > From: "serguei.spitsyn at oracle.com" > >> > > To: Adam Farley8 , David Holmes > >> > > > >> > > Cc: hotspot-dev at openjdk.java.net > >> > > Date: 13/08/2019 17:20 > >> > > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > >> > > paths are longer than JVM_MAXPATHLEN > >> > > > >> > > Hi Adam, > >> > > > >> > > Could you, please, tell a little bit on how did you test the fix? > >> > > > >> > > Thanks, > >> > > Serguei > >> > > > >> > > > >> > > On 8/13/19 09:00, serguei.spitsyn at oracle.com wrote: > >> > > Hi Adam, > >> > > > >> > > I'll sponsor the push. > >> > > > >> > > Thanks, > >> > > Serguei > >> > > > >> > > > >> > > On 8/13/19 08:48, Adam Farley8 wrote: > >> > > Hi David, > >> > > > >> > > Since we have two positive reviews (yours and Serguei's), could you > >> > > sponsor the change please? > >> > > > >> > > Best Regards > >> > > > >> > > Adam Farley > >> > > IBM Runtimes > >> > > > >> > > > >> > > David Holmes wrote on 12/08/2019 23:32:14: > >> > > > >> > > > From: David Holmes > >> > > > To: Adam Farley8 > >> > > > Cc: hotspot-dev at openjdk.java.net, "serguei.spitsyn at oracle.com" > >> > > > > >> > > > Date: 12/08/2019 23:32 > >> > > > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > >> > > > paths are longer than JVM_MAXPATHLEN > >> > > > > >> > > > Looks fine. > >> > > > > >> > > > Thanks, > >> > > > David > >> > > > > >> > > > On 13/08/2019 1:19 am, Adam Farley8 wrote: > >> > > > > Hi David, > >> > > > > > >> > > > > Changes made as requested: > >> > > > > https://urldefense.proofpoint.com/v2/url? > >> > > > u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.4_webrev&d=DwID- > >> > > > g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > >> > > > > >> > > > >> > > >> > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=mZM8IR4e_zmrfcsF3XJjoGEMrZb4WtEL7Y6Ugd6Naqg&s=sZ2UKqqUIq0El- > >> > > > RsqYz6jmTh4Q2UghwdrQX6of8Lw0E&e= > >> > > > > > >> > > > > Best Regards > >> > > > > > >> > > > > Adam Farley > >> > > > > IBM Runtimes > >> > > > > > >> > > > > > >> > > > > David Holmes wrote on 12/08/2019 > >> 04:55:36: > >> > > > > > >> > > > >> From: David Holmes > >> > > > >> To: Adam Farley8 , > >> > > > >> "serguei.spitsyn at oracle.com" > >> > > > >> Cc: hotspot-dev at openjdk.java.net > >> > > > >> Date: 12/08/2019 04:56 > >> > > > >> Subject: Re: RFR: JDK-8227021: VM fails if any > >> sun.boot.library.path > >> > > > >> paths are longer than JVM_MAXPATHLEN > >> > > > >> > >> > > > >> Hi Adam, > >> > > > >> > >> > > > >> On 10/08/2019 2:47 am, Adam Farley8 wrote: > >> > > > >> > Hi Serguei, David, > >> > > > >> > > >> > > > >> > My turn to apologise for the delay. :) > >> > > > >> > > >> > > > >> > I've modified the code as per Serguei's request. Take a look > >> > > and let me > >> > > > >> > know if this is the sort of thing you were thinking of. > >> > > > >> > > >> > > > >> > Webrev: https://urldefense.proofpoint.com/v2/url? > >> > > > >> > >> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.3_webrev_&d=DwID- > >> > > > >> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > >> > > > >> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > >> > > > >> > >> > > > > >> > > > >> > > >> > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=L19aeFXoR9JIO62QRPFzZObIU8RbhpCtXSvUibD2ISk&e= > >> > > > >> > >> > > > >> I'd prefer to see the helper just as a file static function > >> > rather than > >> > > > >> adding it to the os class. > >> > > > >> > >> > > > >> + * supplied array of arrays of chars (a), where n > >> > > > >> > >> > > > >> I assume (a) is meant to refer to the parameter, but you > >> > actually called > >> > > > >> it arrayarray. I think "a" or "arr" would suffice. > >> > > > >> > >> > > > >> Thanks, > >> > > > >> David > >> > > > >> > >> > > > >> > Best Regards > >> > > > >> > > >> > > > >> > Adam Farley > >> > > > >> > IBM Runtimes > >> > > > >> > > >> > > > >> > > >> > > > >> > "serguei.spitsyn at oracle.com" > >> wrote on > >> > > > >> > 31/07/2019 17:18:05: > >> > > > >> > > >> > > > >> >> From: "serguei.spitsyn at oracle.com" > >> > >> > > > >> >> To: Adam Farley8 , David Holmes > >> > > > >> >> > >> > > > >> >> Cc: serviceability-dev , > >> > > > >> >> hotspot-dev at openjdk.java.net > >> > > > >> >> Date: 31/07/2019 17:18 > >> > > > >> >> Subject: Re: RFR: JDK-8227021: VM fails if any > >> > sun.boot.library.path > >> > > > >> >> paths are longer than JVM_MAXPATHLEN > >> > > > >> >> > >> > > > >> >> Hi Adam, > >> > > > >> >> > >> > > > >> >> It looks Okay to me. > >> > > > >> >> > >> > > > >> >> A couple of minor comments. > >> > > > >> >> > >> > > > >> >> https://urldefense.proofpoint.com/v2/url? > >> > > > >> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021. > >> > > > >> 2_webrev_src_hotspot_&d=DwID-g&c=jf_iaSHvJObTbx- > >> > > > >> > >> siA1ZOg&r=P5m8KWUXJf-CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > >> > > > >> > >> > > > > >> > > > >> > > >> > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NL6tYuwwDod3DSmj-1ztxAywpO8L52HEyO0wvTR05bs&e= > >> > > > >> >> share/runtime/os.cpp.frames.html > >> > > > >> > > >> > > > >> >> 1362 //release allocated storage before exiting the vm > >> > > > >> >> 1363 while (i > 0) { > >> > > > >> >> 1364 i--; > >> > > > >> >> 1365 if (opath[i] != NULL) { > >> > > > >> >> 1366 FREE_C_HEAP_ARRAY(char, opath[i]); > >> > > > >> >> 1367 } > >> > > > >> >> 1368 } > >> > > > >> >> 1369 FREE_C_HEAP_ARRAY(char*, opath); > >> > > > >> >> > >> > > > >> >> 1377 //release allocated storage before returning null > >> > > > >> >> 1378 while (i > 0) { > >> > > > >> >> 1379 i--; > >> > > > >> >> 1380 if (opath[i] != NULL) { > >> > > > >> >> 1381 FREE_C_HEAP_ARRAY(char, opath[i]); > >> > > > >> >> 1382 } > >> > > > >> >> 1383 } > >> > > > >> >> 1384 FREE_C_HEAP_ARRAY(char*, opath); > >> > > > >> >> > >> > > > >> >> This duplicated fragments is worth to refactor to a function. > >> > > > >> >> Also a space is missed at the beginning of the comment. > >> > > > >> >> > >> > > > >> >> > >> > > > >> >> Thanks, > >> > > > >> >> Serguei > >> > > > >> >> > >> > > > >> >> > >> > > > >> >> > >> > > > >> >> On 7/31/19 02:01, Adam Farley8 wrote: > >> > > > >> >> Hi All, > >> > > > >> >> > >> > > > >> >> Reviewers requested for the change below. > >> > > > >> >> > >> > > > >> >> @David - Agreed. Would you be prepared to sponsor the change? > >> > > > >> >> > >> > > > >> >> Bug: https://urldefense.proofpoint.com/v2/url? > >> > > > >> u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8227021&d=DwID- > >> > > > >> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > >> > > > >> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > >> > > > >> > >> > > > > >> > > > >> > > >> > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=xykJ0KLy9AKWO8zmC0amfR7xxUsvyKEjlf3y7WWOqvE&e= > >> > > > >> >> Webrev: https://urldefense.proofpoint.com/v2/url? > >> > > > >> > >> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.2_webrev_&d=DwID- > >> > > > >> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > >> > > > >> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > >> > > > >> > >> > > > > >> > > > >> > > >> > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NvIza4VVWG3CiDhmQVmXsghH_4h_c5mFJbHwkCUcut0&e= > >> > > > >> >> > >> > > > >> >> Best Regards > >> > > > >> >> > >> > > > >> >> Adam Farley > >> > > > >> >> IBM Runtimes > >> > > > >> >> > >> > > > >> >> P.S. Remembered to add the links this time. :) > >> > > > >> >> > >> > > > >> >> > >> > > > >> >> David Holmes wrote on > >> 30/07/2019 03:37:53: > >> > > > >> >> > >> > > > >> >> > From: David Holmes > >> > > > >> >> > To: Adam Farley8 > >> > > > >> >> > Cc: hotspot-dev at openjdk.java.net, serviceability-dev > >> > > > >> >> > > >> > > > >> >> > Date: 30/07/2019 03:38 > >> > > > >> >> > Subject: Re: RFR: JDK-8227021: VM fails if any > >> > sun.boot.library.path > >> > > > >> >> > paths are longer than JVM_MAXPATHLEN > >> > > > >> >> > > >> > > > >> >> > Hi Adam, > >> > > > >> >> > > >> > > > >> >> > On 25/07/2019 3:57 am, Adam Farley8 wrote: > >> > > > >> >> > > Hi David, > >> > > > >> >> > > > >> > > > >> >> > > Welcome back. :) > >> > > > >> >> > > >> > > > >> >> > Thanks. Sorry for the delay in getting back to this. > >> > > > >> >> > > >> > > > >> >> > I like .v2 as it is much simpler (notwithstanding freeing > >> > > > the already > >> > > > >> >> > allocated arrays adds some complexity - thanks for > >> fixing that). > >> > > > >> >> > > >> > > > >> >> > I'm still not sure we can't optimise things better for > >> > unchangeable > >> > > > >> >> > properties like the boot libary path, but that's another > >> RFE. > >> > > > >> >> > > >> > > > >> >> > Thanks, > >> > > > >> >> > David > >> > > > >> >> > > >> > > > >> >> 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 > >> > > > > >> > > > >> > > 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 > > > 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 stefan.karlsson at oracle.com Thu Aug 15 11:46:30 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 15 Aug 2019 13:46:30 +0200 Subject: RFR: 8229258: Rework markOop and markOopDesc into a simpler mark word value carrier In-Reply-To: References: <72567e47-3b52-8e30-ea6f-9a64fa043c07@redhat.com> <32ccb4ba-0500-2bf4-3761-63a6285f94dc@oracle.com> <5913EBBD-2A13-43A5-9F37-D36E97397365@oracle.com> Message-ID: <1670ce59-e7b5-0023-b1fd-f9f7c19a0eda@oracle.com> Thanks Kim, Roman, Dan and Coleen for reviews and feedback. I rebased the patch, fixed more alignments, renamed the bug, and rerun the test through tier1-3. https://cr.openjdk.java.net/~stefank/8229258/webrev.valueMarkWord.03.delta/ https://cr.openjdk.java.net/~stefank/8229258/webrev.valueMarkWord.03/ Could I get reviews for this version? I'd also like to ask others to at least partially look at this: 1) Platform maintainers probably want to run this patch through their build system. 2) SA maintainers (CC:ed serviceability-dev) 3) JVMCI maintainers Thanks, StefanK On 2019-08-14 11:11, Roman Kennke wrote: > > Am 14.08.19 um 01:26 schrieb Kim Barrett: >>> On Aug 12, 2019, at 12:19 PM, Stefan Karlsson wrote: >>> >>> Hi Roman, >>> >>> Kim helped me figuring out how to get past the volatile issues I had with the class markWord { uintptr_t value; ... } version. So, I've created a version with that: >>> >>> https://cr.openjdk.java.net/~stefank/8229258/webrev.valueMarkWord.01/ >>> >>> I can go with either approach, so let me now what you all think. >> I've finally had time to look at the first proposed change. >> >> Comparing the first approach (an AllStatic MarkWord class and markWord >> typedef'd to uintptr_t) vs the second approach (markWord is a thin >> class wrapping around uintptr_t), I prefer the second. >> >> * I think the markWord class provides better type safety. It still >> involves too many casts sprinkled over the code base, but I think it >> also provides a better basis for further cast reduction and >> prevention. >> >> * I think having one markWord class for the data and behavior is >> better / more natural than having a markWord typedef for the data and >> a MarkWord AllStatic class for the behaviour. >> >> * I like that the markWord class eliminates the markWord vs MarkWord >> homonyms, which I think will be annoying. >> >> * The markWord class is a trivially copyable class, allowing it to be >> efficiently passed around by value, so no disadvantage there. >> >> I haven't found anything that I think argues for the first over the >> second. Other folks might have different priorities or taste. I think >> either is better than the status quo. >> >> I'm still reviewing webrev.valueMarkWord.02, but so far haven't found >> anything that makes me want to suggest backing off from that direction. >> >> Note that the bug summary doesn't describe the second approach. > +1 :-) > > Roman > From david.holmes at oracle.com Thu Aug 15 11:55:59 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 15 Aug 2019 21:55:59 +1000 Subject: RFR: JDK-8227021: VM fails if any sun.boot.library.path paths are longer than JVM_MAXPATHLEN In-Reply-To: References: <025da83a-6569-f6ac-7590-5b200ed2344f@oracle.com> <8e62fc61-b46b-0033-f182-cb4a2dbf92fd@oracle.com> Message-ID: <8396b3e7-dc3e-d2eb-29a1-e864bbbd42e0@oracle.com> On 15/08/2019 9:40 pm, Adam Farley8 wrote: > Hi Daniel, > > Seems reasonable. > > Will put together a jtreg shell script. shell script tests are not desirable. ProcessTools should be usable to set up a bad command-line and check for the right response. David > Best Regards > > Adam Farley > IBM Runtimes > > > David Holmes wrote on 15/08/2019 10:42:35: > >> From: David Holmes >> To: "serguei.spitsyn at oracle.com" , Adam >> Farley8 >> Cc: daniel.daugherty at oracle.com, hotspot-dev at openjdk.java.net >> Date: 15/08/2019 10:42 >> Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path >> paths are longer than JVM_MAXPATHLEN >> >> Hi Serguei, >> >> On 15/08/2019 6:18 pm, serguei.spitsyn at oracle.com wrote: >> > Thank you, Adam! >> > >> > David, what do you thin about this testing coverage? >> > Is it enough for this fix? >> >> I don't see any real testing of sun.boot.library.path in our tests only: >> >> ./hotspot/jtreg/runtime/6819213/TestBootNativeLibraryPath.java >> ./hotspot/jtreg/runtime/jni/FindClass/FindClassFromBoot.java >> >> seem to refer to it but the former is restricted to 32-bit systems only! >> So this seems to be an area devoid of any real test code outside of >> 32-bit. I don't understand why that is the case. So if there's no >> regression test then there's no real testing of this code at all. That >> said it seems unfair to force Adam to define tests for code that is >> effectively untested. It would be reasonable for him to extend existing >> tests to cover the long path problem, if they existed. >> >> But a basic regression test should at least be created IMO. >> >> David >> ----- >> >> > Thanks, >> > Serguei >> > >> > >> > On 8/14/19 04:09, Adam Farley8 wrote: >> >> Addendum: I've run the test/hotspot/jtreg/runtime tests against a >> >> patched and unpatched build on linux x86 64bit, and the pass/fail rate >> >> is identical. >> >> >> >> 630 passed, 7 failed, and 63 error in both cases. >> >> >> >> Best Regards >> >> >> >> Adam Farley >> >> IBM Runtimes >> >> >> >> >> >> Adam Farley8/UK/IBM wrote on 13/08/2019 17:36:44: >> >> >> >> > From: Adam Farley8/UK/IBM >> >> > To: "serguei.spitsyn at oracle.com" , >> >> > daniel.daugherty at oracle.com >> >> > Cc: David Holmes , hotspot-dev at openjdk.java.net >> >> > Date: 13/08/2019 17:36 >> >> > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path >> >> > paths are longer than JVM_MAXPATHLEN >> >> > >> >> > Hi Serguei, Daniel, >> >> > >> >> > I ran the bug specific test mentioned in the bug, as well as this: >> >> > test/hotspot/jtreg/sanity >> >> > >> >> > No failures. Well, except for the one we wanted in the bug test. :) >> >> > >> >> > On reflection, this seems thin, so I'm running some more hotspot >> >> tests now. >> >> > >> >> > Advice welcome. >> >> > >> >> > Best Regards >> >> > >> >> > Adam Farley >> >> > IBM Runtimes >> >> >> >> > >> >> > "serguei.spitsyn at oracle.com" wrote on >> >> > 13/08/2019 17:09:17: >> >> > >> >> > > From: "serguei.spitsyn at oracle.com" >> >> > > To: Adam Farley8 , David Holmes >> >> > > >> >> > > Cc: hotspot-dev at openjdk.java.net >> >> > > Date: 13/08/2019 17:20 >> >> > > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path >> >> > > paths are longer than JVM_MAXPATHLEN >> >> > > >> >> > > Hi Adam, >> >> > > >> >> > > Could you, please, tell a little bit on how did you test the fix? >> >> > > >> >> > > Thanks, >> >> > > Serguei >> >> > > >> >> > > >> >> > > On 8/13/19 09:00, serguei.spitsyn at oracle.com wrote: >> >> > > Hi Adam, >> >> > > >> >> > > I'll sponsor the push. >> >> > > >> >> > > Thanks, >> >> > > Serguei >> >> > > >> >> > > >> >> > > On 8/13/19 08:48, Adam Farley8 wrote: >> >> > > Hi David, >> >> > > >> >> > > Since we have two positive reviews (yours and Serguei's), could you >> >> > > sponsor the change please? >> >> > > >> >> > > Best Regards >> >> > > >> >> > > Adam Farley >> >> > > IBM Runtimes >> >> > > >> >> > > >> >> > > David Holmes wrote on 12/08/2019 23:32:14: >> >> > > >> >> > > > From: David Holmes >> >> > > > To: Adam Farley8 >> >> > > > Cc: hotspot-dev at openjdk.java.net, "serguei.spitsyn at oracle.com" >> >> > > > >> >> > > > Date: 12/08/2019 23:32 >> >> > > > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path >> >> > > > paths are longer than JVM_MAXPATHLEN >> >> > > > >> >> > > > Looks fine. >> >> > > > >> >> > > > Thanks, >> >> > > > David >> >> > > > >> >> > > > On 13/08/2019 1:19 am, Adam Farley8 wrote: >> >> > > > > Hi David, >> >> > > > > >> >> > > > > Changes made as requested: >> >> > > > > https://urldefense.proofpoint.com/v2/url? >> >> > > > u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.4_webrev&d=DwID- >> >> > > > g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- >> >> > > > >> >> > > >> >> > >> >> >> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=mZM8IR4e_zmrfcsF3XJjoGEMrZb4WtEL7Y6Ugd6Naqg&s=sZ2UKqqUIq0El- >> >> > > > RsqYz6jmTh4Q2UghwdrQX6of8Lw0E&e= >> >> > > > > >> >> > > > > Best Regards >> >> > > > > >> >> > > > > Adam Farley >> >> > > > > IBM Runtimes >> >> > > > > >> >> > > > > >> >> > > > > David Holmes wrote on 12/08/2019 >> >> 04:55:36: >> >> > > > > >> >> > > > >> From: David Holmes >> >> > > > >> To: Adam Farley8 , >> >> > > > >> "serguei.spitsyn at oracle.com" >> >> > > > >> Cc: hotspot-dev at openjdk.java.net >> >> > > > >> Date: 12/08/2019 04:56 >> >> > > > >> Subject: Re: RFR: JDK-8227021: ?VM fails if any >> >> sun.boot.library.path >> >> > > > >> paths are longer than JVM_MAXPATHLEN >> >> > > > >> >> >> > > > >> Hi Adam, >> >> > > > >> >> >> > > > >> On 10/08/2019 2:47 am, Adam Farley8 wrote: >> >> > > > >> > Hi Serguei, David, >> >> > > > >> > >> >> > > > >> > My turn to apologise for the delay. :) >> >> > > > >> > >> >> > > > >> > I've modified the code as per Serguei's request. Take a look >> >> > > ?and let me >> >> > > > >> > know if this is the sort of thing you were thinking of. >> >> > > > >> > >> >> > > > >> > Webrev: https://urldefense.proofpoint.com/v2/url? >> >> > > > >> >> >> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.3_webrev_&d=DwID- >> >> > > > >> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- >> >> > > > >> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- >> >> > > > >> >> >> > > > >> >> > > >> >> > >> >> >> yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=L19aeFXoR9JIO62QRPFzZObIU8RbhpCtXSvUibD2ISk&e= >> >> > > > >> >> >> > > > >> I'd prefer to see the helper just as a file static function >> >> > rather ?than >> >> > > > >> adding it to the os class. >> >> > > > >> >> >> > > > >> + ?* supplied array of arrays of chars (a), where n >> >> > > > >> >> >> > > > >> I assume (a) is meant to refer to the parameter, but you >> >> > actually ?called >> >> > > > >> it arrayarray. I think "a" or "arr" would suffice. >> >> > > > >> >> >> > > > >> Thanks, >> >> > > > >> David >> >> > > > >> >> >> > > > >> > Best Regards >> >> > > > >> > >> >> > > > >> > Adam Farley >> >> > > > >> > IBM Runtimes >> >> > > > >> > >> >> > > > >> > >> >> > > > >> > "serguei.spitsyn at oracle.com" >> >> ?wrote on >> >> > > > >> > 31/07/2019 17:18:05: >> >> > > > >> > >> >> > > > >> >> From: "serguei.spitsyn at oracle.com" >> >> >> >> > > > >> >> To: Adam Farley8 , ?David ?Holmes >> >> > > > >> >> >> >> > > > >> >> Cc: serviceability-dev , >> >> > > > >> >> hotspot-dev at openjdk.java.net >> >> > > > >> >> Date: 31/07/2019 17:18 >> >> > > > >> >> Subject: Re: RFR: JDK-8227021: ?VM fails if any >> >> > sun.boot.library.path >> >> > > > >> >> paths are longer than JVM_MAXPATHLEN >> >> > > > >> >> >> >> > > > >> >> Hi Adam, >> >> > > > >> >> >> >> > > > >> >> It looks Okay to me. >> >> > > > >> >> >> >> > > > >> >> A couple of minor comments. >> >> > > > >> >> >> >> > > > >> >> https://urldefense.proofpoint.com/v2/url? >> >> > > > >> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021. >> >> > > > >> 2_webrev_src_hotspot_&d=DwID-g&c=jf_iaSHvJObTbx- >> >> > > > >> >> >> siA1ZOg&r=P5m8KWUXJf-CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- >> >> > > > >> >> >> > > > >> >> > > >> >> > >> >> >> yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NL6tYuwwDod3DSmj-1ztxAywpO8L52HEyO0wvTR05bs&e= >> >> > > > >> >> share/runtime/os.cpp.frames.html >> >> > > > >> > >> >> > > > >> >> 1362 //release ?allocated storage ?before exiting the vm >> >> > > > >> >> 1363 while (i > 0) { >> >> > > > >> >> 1364 i--; >> >> > > > >> >> 1365 if (opath[i] != NULL) ?{ >> >> > > > >> >> 1366 ? FREE_C_HEAP_ARRAY(char, ??opath[i]); >> >> > > > >> >> 1367 } >> >> > > > >> >> 1368 } >> >> > > > >> >> 1369 FREE_C_HEAP_ARRAY(char*, opath); >> >> > > > >> >> >> >> > > > >> >> 1377 //release allocated storage before ?returning ?null >> >> > > > >> >> 1378 while (i > 0) { >> >> > > > >> >> 1379 i--; >> >> > > > >> >> 1380 if (opath[i] != NULL) ?{ >> >> > > > >> >> 1381 ? FREE_C_HEAP_ARRAY(char, ??opath[i]); >> >> > > > >> >> 1382 } >> >> > > > >> >> 1383 } >> >> > > > >> >> 1384 FREE_C_HEAP_ARRAY(char*, opath); >> >> > > > >> >> >> >> > > > >> >> This duplicated fragments is worth to refactor to a function. >> >> > > > >> >> Also a space is missed at the beginning of the comment. >> >> > > > >> >> >> >> > > > >> >> >> >> > > > >> >> Thanks, >> >> > > > >> >> Serguei >> >> > > > >> >> >> >> > > > >> >> >> >> > > > >> >> >> >> > > > >> >> On 7/31/19 02:01, Adam Farley8 wrote: >> >> > > > >> >> Hi All, >> >> > > > >> >> >> >> > > > >> >> Reviewers requested for the change below. >> >> > > > >> >> >> >> > > > >> >> @David - Agreed. Would you be prepared to sponsor the change? >> >> > > > >> >> >> >> > > > >> >> Bug: https://urldefense.proofpoint.com/v2/url? >> >> > > > >> u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8227021&d=DwID- >> >> > > > >> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- >> >> > > > >> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- >> >> > > > >> >> >> > > > >> >> > > >> >> > >> >> >> yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=xykJ0KLy9AKWO8zmC0amfR7xxUsvyKEjlf3y7WWOqvE&e= >> >> > > > >> >> Webrev: https://urldefense.proofpoint.com/v2/url? >> >> > > > >> >> >> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.2_webrev_&d=DwID- >> >> > > > >> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- >> >> > > > >> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- >> >> > > > >> >> >> > > > >> >> > > >> >> > >> >> >> yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NvIza4VVWG3CiDhmQVmXsghH_4h_c5mFJbHwkCUcut0&e= >> >> > > > >> >> >> >> > > > >> >> Best Regards >> >> > > > >> >> >> >> > > > >> >> Adam Farley >> >> > > > >> >> IBM Runtimes >> >> > > > >> >> >> >> > > > >> >> P.S. Remembered to add the links this time. :) >> >> > > > >> >> >> >> > > > >> >> >> >> > > > >> >> David Holmes wrote on >> >> 30/07/2019?03:37:53: >> >> > > > >> >> >> >> > > > >> >> > From: David Holmes >> >> > > > >> >> > To: Adam Farley8 >> >> > > > >> >> > Cc: hotspot-dev at openjdk.java.net, serviceability-dev >> >> > > > >> >> > >> >> > > > >> >> > Date: 30/07/2019 03:38 >> >> > > > >> >> > Subject: Re: RFR: JDK-8227021: VM fails if any >> >> > sun.boot.library.path >> >> > > > >> >> > paths are longer than JVM_MAXPATHLEN >> >> > > > >> >> > >> >> > > > >> >> > Hi Adam, >> >> > > > >> >> > >> >> > > > >> >> > On 25/07/2019 3:57 am, Adam Farley8 wrote: >> >> > > > >> >> > > Hi David, >> >> > > > >> >> > > >> >> > > > >> >> > > Welcome back. :) >> >> > > > >> >> > >> >> > > > >> >> > Thanks. Sorry for the delay in getting back to this. >> >> > > > >> >> > >> >> > > > >> >> > I like .v2 as it is much simpler (notwithstanding freeing >> >> > > > the ?already >> >> > > > >> >> > allocated arrays adds some complexity - thanks for >> >> fixing ?that). >> >> > > > >> >> > >> >> > > > >> >> > I'm still not sure we can't optimise things better for >> >> > ?unchangeable >> >> > > > >> >> > properties like the boot libary path, but that's another >> >> ?RFE. >> >> > > > >> >> > >> >> > > > >> >> > Thanks, >> >> > > > >> >> > David >> >> > > > >> >> > >> >> > > > >> >> 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 >> >> > > > >> >> > > >> >> > > 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 >> > >> > > 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 adam.farley at uk.ibm.com Thu Aug 15 12:00:35 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Thu, 15 Aug 2019 13:00:35 +0100 Subject: RFR: JDK-8227021: VM fails if any sun.boot.library.path paths are longer than JVM_MAXPATHLEN In-Reply-To: <8396b3e7-dc3e-d2eb-29a1-e864bbbd42e0@oracle.com> References: <025da83a-6569-f6ac-7590-5b200ed2344f@oracle.com> <8e62fc61-b46b-0033-f182-cb4a2dbf92fd@oracle.com> <8396b3e7-dc3e-d2eb-29a1-e864bbbd42e0@oracle.com> Message-ID: Sure thing. - Adam Best Regards Adam Farley IBM Runtimes David Holmes wrote on 15/08/2019 12:55:59: > From: David Holmes > To: Adam Farley8 > Cc: daniel.daugherty at oracle.com, hotspot-dev at openjdk.java.net, > "serguei.spitsyn at oracle.com" > Date: 15/08/2019 12:58 > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > paths are longer than JVM_MAXPATHLEN > > On 15/08/2019 9:40 pm, Adam Farley8 wrote: > > Hi Daniel, > > > > Seems reasonable. > > > > Will put together a jtreg shell script. > > shell script tests are not desirable. ProcessTools should be usable to > set up a bad command-line and check for the right response. > > David > > > Best Regards > > > > Adam Farley > > IBM Runtimes > > > > > > David Holmes wrote on 15/08/2019 10:42:35: > > > >> From: David Holmes > >> To: "serguei.spitsyn at oracle.com" , Adam > >> Farley8 > >> Cc: daniel.daugherty at oracle.com, hotspot-dev at openjdk.java.net > >> Date: 15/08/2019 10:42 > >> Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > >> paths are longer than JVM_MAXPATHLEN > >> > >> Hi Serguei, > >> > >> On 15/08/2019 6:18 pm, serguei.spitsyn at oracle.com wrote: > >> > Thank you, Adam! > >> > > >> > David, what do you thin about this testing coverage? > >> > Is it enough for this fix? > >> > >> I don't see any real testing of sun.boot.library.path in our tests only: > >> > >> ./hotspot/jtreg/runtime/6819213/TestBootNativeLibraryPath.java > >> ./hotspot/jtreg/runtime/jni/FindClass/FindClassFromBoot.java > >> > >> seem to refer to it but the former is restricted to 32-bit systems only! > >> So this seems to be an area devoid of any real test code outside of > >> 32-bit. I don't understand why that is the case. So if there's no > >> regression test then there's no real testing of this code at all. That > >> said it seems unfair to force Adam to define tests for code that is > >> effectively untested. It would be reasonable for him to extend existing > >> tests to cover the long path problem, if they existed. > >> > >> But a basic regression test should at least be created IMO. > >> > >> David > >> ----- > >> > >> > Thanks, > >> > Serguei > >> > > >> > > >> > On 8/14/19 04:09, Adam Farley8 wrote: > >> >> Addendum: I've run the test/hotspot/jtreg/runtime tests against a > >> >> patched and unpatched build on linux x86 64bit, and the pass/fail rate > >> >> is identical. > >> >> > >> >> 630 passed, 7 failed, and 63 error in both cases. > >> >> > >> >> Best Regards > >> >> > >> >> Adam Farley > >> >> IBM Runtimes > >> >> > >> >> > >> >> Adam Farley8/UK/IBM wrote on 13/08/2019 17:36:44: > >> >> > >> >> > From: Adam Farley8/UK/IBM > >> >> > To: "serguei.spitsyn at oracle.com" , > >> >> > daniel.daugherty at oracle.com > >> >> > Cc: David Holmes , hotspot- > dev at openjdk.java.net > >> >> > Date: 13/08/2019 17:36 > >> >> > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > >> >> > paths are longer than JVM_MAXPATHLEN > >> >> > > >> >> > Hi Serguei, Daniel, > >> >> > > >> >> > I ran the bug specific test mentioned in the bug, as well as this: > >> >> > test/hotspot/jtreg/sanity > >> >> > > >> >> > No failures. Well, except for the one we wanted in the bug test. :) > >> >> > > >> >> > On reflection, this seems thin, so I'm running some more hotspot > >> >> tests now. > >> >> > > >> >> > Advice welcome. > >> >> > > >> >> > Best Regards > >> >> > > >> >> > Adam Farley > >> >> > IBM Runtimes > >> >> > >> >> > > >> >> > "serguei.spitsyn at oracle.com" wrote on > >> >> > 13/08/2019 17:09:17: > >> >> > > >> >> > > From: "serguei.spitsyn at oracle.com" > >> >> > > To: Adam Farley8 , David Holmes > >> >> > > > >> >> > > Cc: hotspot-dev at openjdk.java.net > >> >> > > Date: 13/08/2019 17:20 > >> >> > > Subject: Re: RFR: JDK-8227021: VM fails if any > sun.boot.library.path > >> >> > > paths are longer than JVM_MAXPATHLEN > >> >> > > > >> >> > > Hi Adam, > >> >> > > > >> >> > > Could you, please, tell a little bit on how did you test the fix? > >> >> > > > >> >> > > Thanks, > >> >> > > Serguei > >> >> > > > >> >> > > > >> >> > > On 8/13/19 09:00, serguei.spitsyn at oracle.com wrote: > >> >> > > Hi Adam, > >> >> > > > >> >> > > I'll sponsor the push. > >> >> > > > >> >> > > Thanks, > >> >> > > Serguei > >> >> > > > >> >> > > > >> >> > > On 8/13/19 08:48, Adam Farley8 wrote: > >> >> > > Hi David, > >> >> > > > >> >> > > Since we have two positive reviews (yours and Serguei's), could you > >> >> > > sponsor the change please? > >> >> > > > >> >> > > Best Regards > >> >> > > > >> >> > > Adam Farley > >> >> > > IBM Runtimes > >> >> > > > >> >> > > > >> >> > > David Holmes wrote on 12/08/ > 2019 23:32:14: > >> >> > > > >> >> > > > From: David Holmes > >> >> > > > To: Adam Farley8 > >> >> > > > Cc: hotspot-dev at openjdk.java.net, "serguei.spitsyn at oracle.com" > >> >> > > > > >> >> > > > Date: 12/08/2019 23:32 > >> >> > > > Subject: Re: RFR: JDK-8227021: VM fails if any > sun.boot.library.path > >> >> > > > paths are longer than JVM_MAXPATHLEN > >> >> > > > > >> >> > > > Looks fine. > >> >> > > > > >> >> > > > Thanks, > >> >> > > > David > >> >> > > > > >> >> > > > On 13/08/2019 1:19 am, Adam Farley8 wrote: > >> >> > > > > Hi David, > >> >> > > > > > >> >> > > > > Changes made as requested: > >> >> > > > > https://urldefense.proofpoint.com/v2/url? > >> >> > > > u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.4_webrev&d=DwID- > >> >> > > > g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > >> >> > > > > >> >> > > > >> >> > > >> >> > >> > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=mZM8IR4e_zmrfcsF3XJjoGEMrZb4WtEL7Y6Ugd6Naqg&s=sZ2UKqqUIq0El- > >> >> > > > RsqYz6jmTh4Q2UghwdrQX6of8Lw0E&e= > >> >> > > > > > >> >> > > > > Best Regards > >> >> > > > > > >> >> > > > > Adam Farley > >> >> > > > > IBM Runtimes > >> >> > > > > > >> >> > > > > > >> >> > > > > David Holmes wrote on 12/08/2019 > >> >> 04:55:36: > >> >> > > > > > >> >> > > > >> From: David Holmes > >> >> > > > >> To: Adam Farley8 , > >> >> > > > >> "serguei.spitsyn at oracle.com" > >> >> > > > >> Cc: hotspot-dev at openjdk.java.net > >> >> > > > >> Date: 12/08/2019 04:56 > >> >> > > > >> Subject: Re: RFR: JDK-8227021: VM fails if any > >> >> sun.boot.library.path > >> >> > > > >> paths are longer than JVM_MAXPATHLEN > >> >> > > > >> > >> >> > > > >> Hi Adam, > >> >> > > > >> > >> >> > > > >> On 10/08/2019 2:47 am, Adam Farley8 wrote: > >> >> > > > >> > Hi Serguei, David, > >> >> > > > >> > > >> >> > > > >> > My turn to apologise for the delay. :) > >> >> > > > >> > > >> >> > > > >> > I've modified the code as per Serguei's request. Take a look > >> >> > > and let me > >> >> > > > >> > know if this is the sort of thing you were thinking of. > >> >> > > > >> > > >> >> > > > >> > Webrev: https://urldefense.proofpoint.com/v2/url? > >> >> > > > >> > >> >> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.3_webrev_&d=DwID- > >> >> > > > >> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > >> >> > > > >> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > >> >> > > > >> > >> >> > > > > >> >> > > > >> >> > > >> >> > >> > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=L19aeFXoR9JIO62QRPFzZObIU8RbhpCtXSvUibD2ISk&e= > >> >> > > > >> > >> >> > > > >> I'd prefer to see the helper just as a file static function > >> >> > rather than > >> >> > > > >> adding it to the os class. > >> >> > > > >> > >> >> > > > >> + * supplied array of arrays of chars (a), where n > >> >> > > > >> > >> >> > > > >> I assume (a) is meant to refer to the parameter, but you > >> >> > actually called > >> >> > > > >> it arrayarray. I think "a" or "arr" would suffice. > >> >> > > > >> > >> >> > > > >> Thanks, > >> >> > > > >> David > >> >> > > > >> > >> >> > > > >> > Best Regards > >> >> > > > >> > > >> >> > > > >> > Adam Farley > >> >> > > > >> > IBM Runtimes > >> >> > > > >> > > >> >> > > > >> > > >> >> > > > >> > "serguei.spitsyn at oracle.com" > >> >> wrote on > >> >> > > > >> > 31/07/2019 17:18:05: > >> >> > > > >> > > >> >> > > > >> >> From: "serguei.spitsyn at oracle.com" > >> >> > >> >> > > > >> >> To: Adam Farley8 , David Holmes > >> >> > > > >> >> > >> >> > > > >> >> Cc: serviceability-dev dev at openjdk.java.net>, > >> >> > > > >> >> hotspot-dev at openjdk.java.net > >> >> > > > >> >> Date: 31/07/2019 17:18 > >> >> > > > >> >> Subject: Re: RFR: JDK-8227021: VM fails if any > >> >> > sun.boot.library.path > >> >> > > > >> >> paths are longer than JVM_MAXPATHLEN > >> >> > > > >> >> > >> >> > > > >> >> Hi Adam, > >> >> > > > >> >> > >> >> > > > >> >> It looks Okay to me. > >> >> > > > >> >> > >> >> > > > >> >> A couple of minor comments. > >> >> > > > >> >> > >> >> > > > >> >> https://urldefense.proofpoint.com/v2/url? > >> >> > > > >> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021. > >> >> > > > >> 2_webrev_src_hotspot_&d=DwID-g&c=jf_iaSHvJObTbx- > >> >> > > > >> > >> >> siA1ZOg&r=P5m8KWUXJf-CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > >> >> > > > >> > >> >> > > > > >> >> > > > >> >> > > >> >> > >> > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NL6tYuwwDod3DSmj-1ztxAywpO8L52HEyO0wvTR05bs&e= > >> >> > > > >> >> share/runtime/os.cpp.frames.html > >> >> > > > >> > > >> >> > > > >> >> 1362 //release allocated storage before > exiting the vm > >> >> > > > >> >> 1363 while (i > 0) { > >> >> > > > >> >> 1364 i--; > >> >> > > > >> >> 1365 if (opath[i] != NULL) { > >> >> > > > >> >> 1366 FREE_C_HEAP_ARRAY(char, opath[i]); > >> >> > > > >> >> 1367 } > >> >> > > > >> >> 1368 } > >> >> > > > >> >> 1369 FREE_C_HEAP_ARRAY(char*, opath); > >> >> > > > >> >> > >> >> > > > >> >> 1377 //release allocated storage before > returning null > >> >> > > > >> >> 1378 while (i > 0) { > >> >> > > > >> >> 1379 i--; > >> >> > > > >> >> 1380 if (opath[i] != NULL) { > >> >> > > > >> >> 1381 FREE_C_HEAP_ARRAY(char, opath[i]); > >> >> > > > >> >> 1382 } > >> >> > > > >> >> 1383 } > >> >> > > > >> >> 1384 FREE_C_HEAP_ARRAY(char*, opath); > >> >> > > > >> >> > >> >> > > > >> >> This duplicated fragments is worth to refactor to > a function. > >> >> > > > >> >> Also a space is missed at the beginning of the comment. > >> >> > > > >> >> > >> >> > > > >> >> > >> >> > > > >> >> Thanks, > >> >> > > > >> >> Serguei > >> >> > > > >> >> > >> >> > > > >> >> > >> >> > > > >> >> > >> >> > > > >> >> On 7/31/19 02:01, Adam Farley8 wrote: > >> >> > > > >> >> Hi All, > >> >> > > > >> >> > >> >> > > > >> >> Reviewers requested for the change below. > >> >> > > > >> >> > >> >> > > > >> >> @David - Agreed. Would you be prepared to sponsor > the change? > >> >> > > > >> >> > >> >> > > > >> >> Bug: https://urldefense.proofpoint.com/v2/url? > >> >> > > > >> u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8227021&d=DwID- > >> >> > > > >> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > >> >> > > > >> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > >> >> > > > >> > >> >> > > > > >> >> > > > >> >> > > >> >> > >> > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=xykJ0KLy9AKWO8zmC0amfR7xxUsvyKEjlf3y7WWOqvE&e= > >> >> > > > >> >> Webrev: https://urldefense.proofpoint.com/v2/url? > >> >> > > > >> > >> >> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.2_webrev_&d=DwID- > >> >> > > > >> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > >> >> > > > >> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > >> >> > > > >> > >> >> > > > > >> >> > > > >> >> > > >> >> > >> > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NvIza4VVWG3CiDhmQVmXsghH_4h_c5mFJbHwkCUcut0&e= > >> >> > > > >> >> > >> >> > > > >> >> Best Regards > >> >> > > > >> >> > >> >> > > > >> >> Adam Farley > >> >> > > > >> >> IBM Runtimes > >> >> > > > >> >> > >> >> > > > >> >> P.S. Remembered to add the links this time. :) > >> >> > > > >> >> > >> >> > > > >> >> > >> >> > > > >> >> David Holmes wrote on > >> >> 30/07/2019 03:37:53: > >> >> > > > >> >> > >> >> > > > >> >> > From: David Holmes > >> >> > > > >> >> > To: Adam Farley8 > >> >> > > > >> >> > Cc: hotspot-dev at openjdk.java.net, serviceability-dev > >> >> > > > >> >> > > >> >> > > > >> >> > Date: 30/07/2019 03:38 > >> >> > > > >> >> > Subject: Re: RFR: JDK-8227021: VM fails if any > >> >> > sun.boot.library.path > >> >> > > > >> >> > paths are longer than JVM_MAXPATHLEN > >> >> > > > >> >> > > >> >> > > > >> >> > Hi Adam, > >> >> > > > >> >> > > >> >> > > > >> >> > On 25/07/2019 3:57 am, Adam Farley8 wrote: > >> >> > > > >> >> > > Hi David, > >> >> > > > >> >> > > > >> >> > > > >> >> > > Welcome back. :) > >> >> > > > >> >> > > >> >> > > > >> >> > Thanks. Sorry for the delay in getting back to this. > >> >> > > > >> >> > > >> >> > > > >> >> > I like .v2 as it is much simpler (notwithstanding freeing > >> >> > > > the already > >> >> > > > >> >> > allocated arrays adds some complexity - thanks for > >> >> fixing that). > >> >> > > > >> >> > > >> >> > > > >> >> > I'm still not sure we can't optimise things better for > >> >> > unchangeable > >> >> > > > >> >> > properties like the boot libary path, but that's another > >> >> RFE. > >> >> > > > >> >> > > >> >> > > > >> >> > Thanks, > >> >> > > > >> >> > David > >> >> > > > >> >> > > >> >> > > > >> >> 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 Englandand 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 > >> >> > 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 > 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 coleen.phillimore at oracle.com Thu Aug 15 12:42:51 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 15 Aug 2019 08:42:51 -0400 Subject: RFR: JDK-8227021: VM fails if any sun.boot.library.path paths are longer than JVM_MAXPATHLEN In-Reply-To: <269929ba-d3a0-96d8-61a0-703210231443@oracle.com> References: <25234969-2215-57e9-d8c5-d97b5669ebb1@oracle.com> <5ba808b0-ae52-0d0a-b84b-fc34df35475d@oracle.com> <025da83a-6569-f6ac-7590-5b200ed2344f@oracle.com> <8e62fc61-b46b-0033-f182-cb4a2dbf92fd@oracle.com> <269929ba-d3a0-96d8-61a0-703210231443@oracle.com> Message-ID: Hi Adam,? David noticed that my code review replies only went to the mailing list.? So here it is again. Thanks, Coleen On 8/13/19 5:29 PM, coleen.phillimore at oracle.com wrote: > > > On 8/13/19 11:48 AM, Adam Farley8 wrote: >> Hi David, >> >> Since we have two positive reviews (yours and Serguei's), could you >> sponsor the change please? > > If you get two positive reviews, but then one with comments, you need > to also answer that third reviews.? I had some comments on your > change, which I'll repeat here: > > > http://cr.openjdk.java.net/~afarley/8227021.2/webrev/src/hotspot/share/runtime/os.cpp.frames.html > > > This is code is unnecessarily hard to read and understand: > > 1329 char** os::split_path(const char* path, size_t* n) { > 1330 size_t pathmod = (size_t)0; > 1331 if (n != NULL) { > 1332 pathmod = *n; > 1333 } > 1334 *n = (size_t)0; > > It appears that 'n' is both an input and output parameter of this > function.? Can you just make it another input parameter with some > descriptive name.? Is it the length of the library name that you're > looking for?? "pathmod" is huh? > > Then you don't have to check if someone has passed NULL.? There's only > one caller to this from what I see. > > 1352?? char** opath = (char**) NEW_C_HEAP_ARRAY(char*, count, > mtInternal); > 1353?? if (opath == NULL) { > 1354???? return NULL; > 1355?? } > > > Not your change but this calls vm_exit_out_of_memory() if > NEW_C_HEAP_ARRAY fails.? It doesn't return NULL so you don't have to > check. > > 1375???? char* s? = (char*)NEW_C_HEAP_ARRAY(char, len + 1, mtInternal); > > Here you want to use NEW_C_HEAP_ARRAY_RETURN_NULL so you can check for > null and free memory. > > > The rest seems okay. > > thanks, > Coleen > >> >> Best Regards >> >> Adam Farley >> IBM Runtimes >> >> >> David Holmes wrote on 12/08/2019 23:32:14: >> >>> From: David Holmes >>> To: Adam Farley8 >>> Cc: hotspot-dev at openjdk.java.net, "serguei.spitsyn at oracle.com" >>> >>> Date: 12/08/2019 23:32 >>> Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path >>> paths are longer than JVM_MAXPATHLEN >>> >>> Looks fine. >>> >>> Thanks, >>> David >>> >>> On 13/08/2019 1:19 am, Adam Farley8 wrote: >>>> Hi David, >>>> >>>> Changes made as requested: >>>> https://urldefense.proofpoint.com/v2/url? >>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.4_webrev&d=DwID- >>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- >>> >> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=mZM8IR4e_zmrfcsF3XJjoGEMrZb4WtEL7Y6Ugd6Naqg&s=sZ2UKqqUIq0El- >> >>> RsqYz6jmTh4Q2UghwdrQX6of8Lw0E&e= >>>> Best Regards >>>> >>>> Adam Farley >>>> IBM Runtimes >>>> >>>> >>>> David Holmes wrote on 12/08/2019 04:55:36: >>>> >>>>> From: David Holmes >>>>> To: Adam Farley8 , >>>>> "serguei.spitsyn at oracle.com" >>>>> Cc: hotspot-dev at openjdk.java.net >>>>> Date: 12/08/2019 04:56 >>>>> Subject: Re: RFR: JDK-8227021:? VM fails if any sun.boot.library.path >>>>> paths are longer than JVM_MAXPATHLEN >>>>> >>>>> Hi Adam, >>>>> >>>>> On 10/08/2019 2:47 am, Adam Farley8 wrote: >>>>>> Hi Serguei, David, >>>>>> >>>>>> My turn to apologise for the delay. :) >>>>>> >>>>>> I've modified the code as per Serguei's request. Take a look? and >> let me >>>>>> know if this is the sort of thing you were thinking of. >>>>>> >>>>>> Webrev: https://urldefense.proofpoint.com/v2/url? >>>>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.3_webrev_&d=DwID- >>>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- >>>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- >>>>> >> yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=L19aeFXoR9JIO62QRPFzZObIU8RbhpCtXSvUibD2ISk&e= >> >>>>> I'd prefer to see the helper just as a file static function rather >> than >>>>> adding it to the os class. >>>>> >>>>> +? * supplied array of arrays of chars (a), where n >>>>> >>>>> I assume (a) is meant to refer to the parameter, but you actually >> called >>>>> it arrayarray. I think "a" or "arr" would suffice. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Best Regards >>>>>> >>>>>> Adam Farley >>>>>> IBM Runtimes >>>>>> >>>>>> >>>>>> "serguei.spitsyn at oracle.com" ? wrote on >>>>>> 31/07/2019 17:18:05: >>>>>> >>>>>>> From: "serguei.spitsyn at oracle.com" >>>>>>> To: Adam Farley8 , David? Holmes >>>>>>> >>>>>>> Cc: serviceability-dev , >>>>>>> hotspot-dev at openjdk.java.net >>>>>>> Date: 31/07/2019 17:18 >>>>>>> Subject: Re: RFR: JDK-8227021:? VM fails if any >> sun.boot.library.path >>>>>>> paths are longer than JVM_MAXPATHLEN >>>>>>> >>>>>>> Hi Adam, >>>>>>> >>>>>>> It looks Okay to me. >>>>>>> >>>>>>> A couple of minor comments. >>>>>>> >>>>>>> https://urldefense.proofpoint.com/v2/url? >>>>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021. >>>>> 2_webrev_src_hotspot_&d=DwID-g&c=jf_iaSHvJObTbx- >>>>> siA1ZOg&r=P5m8KWUXJf-CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- >>>>> >> yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NL6tYuwwDod3DSmj-1ztxAywpO8L52HEyO0wvTR05bs&e= >> >>>>>>> share/runtime/os.cpp.frames.html >>>>>>> 1362?????? //release? allocated storage? before exiting the vm >>>>>>> 1363?????? while (i > 0) { >>>>>>> 1364?????????? i--; >>>>>>> 1365?????????? if (opath[i] != NULL)? { >>>>>>> 1366???????????? FREE_C_HEAP_ARRAY(char,?? opath[i]); >>>>>>> 1367?????????? } >>>>>>> 1368?????? } >>>>>>> 1369?????? FREE_C_HEAP_ARRAY(char*, opath); >>>>>>> >>>>>>> 1377?????? //release allocated storage before returning? null >>>>>>> 1378?????? while (i > 0) { >>>>>>> 1379?????????? i--; >>>>>>> 1380?????????? if (opath[i] != NULL)? { >>>>>>> 1381???????????? FREE_C_HEAP_ARRAY(char,?? opath[i]); >>>>>>> 1382?????????? } >>>>>>> 1383?????? } >>>>>>> 1384?????? FREE_C_HEAP_ARRAY(char*, opath); >>>>>>> >>>>>>> This duplicated fragments is worth to refactor to a function. >>>>>>> Also a space is missed at the beginning of the comment. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 7/31/19 02:01, Adam Farley8 wrote: >>>>>>> Hi All, >>>>>>> >>>>>>> Reviewers requested for the change below. >>>>>>> >>>>>>> @David - Agreed. Would you be prepared to sponsor the change? >>>>>>> >>>>>>> Bug: https://urldefense.proofpoint.com/v2/url? >>>>> u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8227021&d=DwID- >>>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- >>>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- >>>>> >> yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=xykJ0KLy9AKWO8zmC0amfR7xxUsvyKEjlf3y7WWOqvE&e= >> >>>>>>> Webrev: https://urldefense.proofpoint.com/v2/url? >>>>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.2_webrev_&d=DwID- >>>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- >>>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- >>>>> >> yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NvIza4VVWG3CiDhmQVmXsghH_4h_c5mFJbHwkCUcut0&e= >> >>>>>>> Best Regards >>>>>>> >>>>>>> Adam Farley >>>>>>> IBM Runtimes >>>>>>> >>>>>>> P.S. Remembered to add the links this time. :) >>>>>>> >>>>>>> >>>>>>> David Holmes wrote on 30/07/2019 >> 03:37:53: >>>>>>>> From: David Holmes >>>>>>>> To: Adam Farley8 >>>>>>>> Cc: hotspot-dev at openjdk.java.net, serviceability-dev >>>>>>>> >>>>>>>> Date: 30/07/2019 03:38 >>>>>>>> Subject: Re: RFR: JDK-8227021: VM fails if any >> sun.boot.library.path >>>>>>>> paths are longer than JVM_MAXPATHLEN >>>>>>>> >>>>>>>> Hi Adam, >>>>>>>> >>>>>>>> On 25/07/2019 3:57 am, Adam Farley8 wrote: >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>> Welcome back. :) >>>>>>>> Thanks. Sorry for the delay in getting back to this. >>>>>>>> >>>>>>>> I like .v2 as it is much simpler (notwithstanding freeing >>> the? already >>>>>>>> allocated arrays adds some complexity - thanks for fixing that). >>>>>>>> >>>>>>>> I'm still not sure we can't optimise things better for >> unchangeable >>>>>>>> properties like the boot libary path, but that's another? RFE. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>> 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 >> 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 coleen.phillimore at oracle.com Thu Aug 15 12:56:49 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 15 Aug 2019 08:56:49 -0400 Subject: RFR: 8229258: Rework markOop and markOopDesc into a simpler mark word value carrier In-Reply-To: <1670ce59-e7b5-0023-b1fd-f9f7c19a0eda@oracle.com> References: <72567e47-3b52-8e30-ea6f-9a64fa043c07@redhat.com> <32ccb4ba-0500-2bf4-3761-63a6285f94dc@oracle.com> <5913EBBD-2A13-43A5-9F37-D36E97397365@oracle.com> <1670ce59-e7b5-0023-b1fd-f9f7c19a0eda@oracle.com> Message-ID: <29d31d63-5e83-6861-4f2a-92f2f45e6565@oracle.com> https://cr.openjdk.java.net/~stefank/8229258/webrev.valueMarkWord.03.delta/src/hotspot/share/runtime/synchronizer.cpp.udiff.html + lock->set_displaced_header(markWord::from_pointer(NULL)); Should this be markWork::zero ? + m->set_header(markWord(markWord::zero)); ew. I just clicked through the latest incremental and the full oops directory. The to_pointer and from_pointer casts are awkward, particularly because you can do (Edge*)mark.value() too, but it's good to find where we're using the markWord for various purposes. This is a massive improvement.? Dont' change a thing and check it in.? We can do minor cleanups in followup RFEs. Thanks! Coleen On 8/15/19 7:46 AM, Stefan Karlsson wrote: > Thanks Kim, Roman, Dan and Coleen for reviews and feedback. > > I rebased the patch, fixed more alignments, renamed the bug, and rerun > the test through tier1-3. > > https://cr.openjdk.java.net/~stefank/8229258/webrev.valueMarkWord.03.delta/ > > https://cr.openjdk.java.net/~stefank/8229258/webrev.valueMarkWord.03/ > > Could I get reviews for this version? I'd also like to ask others to > at least partially look at this: > > 1) Platform maintainers probably want to run this patch through their > build system. > 2) SA maintainers (CC:ed serviceability-dev) > 3) JVMCI maintainers > > Thanks, > StefanK > > On 2019-08-14 11:11, Roman Kennke wrote: >> >> Am 14.08.19 um 01:26 schrieb Kim Barrett: >>>> On Aug 12, 2019, at 12:19 PM, Stefan Karlsson >>>> wrote: >>>> >>>> Hi Roman, >>>> >>>> Kim helped me figuring out how to get past the volatile issues I >>>> had with the class markWord { uintptr_t value; ... } version. So, >>>> I've created a version with that: >>>> >>>> https://cr.openjdk.java.net/~stefank/8229258/webrev.valueMarkWord.01/ >>>> >>>> I can go with either approach, so let me now what you all think. >>> I've finally had time to look at the first proposed change. >>> >>> Comparing the first approach (an AllStatic MarkWord class and markWord >>> typedef'd to uintptr_t) vs the second approach (markWord is a thin >>> class wrapping around uintptr_t), I prefer the second. >>> >>> * I think the markWord class provides better type safety. It still >>> involves too many casts sprinkled over the code base, but I think it >>> also provides a better basis for further cast reduction and >>> prevention. >>> >>> * I think having one markWord class for the data and behavior is >>> better / more natural than having a markWord typedef for the data and >>> a MarkWord AllStatic class for the behaviour. >>> >>> * I like that the markWord class eliminates the markWord vs MarkWord >>> homonyms, which I think will be annoying. >>> >>> * The markWord class is a trivially copyable class, allowing it to be >>> efficiently passed around by value, so no disadvantage there. >>> >>> I haven't found anything that I think argues for the first over the >>> second. Other folks might have different priorities or taste. I think >>> either is better than the status quo. >>> >>> I'm still reviewing webrev.valueMarkWord.02, but so far haven't found >>> anything that makes me want to suggest backing off from that direction. >>> >>> Note that the bug summary doesn't describe the second approach. >> +1 :-) >> >> Roman >> > From erik.osterlund at oracle.com Thu Aug 15 15:01:27 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Thu, 15 Aug 2019 17:01:27 +0200 Subject: RFR: 8229345: Memory leak due to vtable stubs not being shared on SPARC Message-ID: <7cc8059e-e148-f7b1-742a-50a1d6350109@oracle.com> Hi, The code cache can be occupied by vtable stubs on SPARC. One of the potential scenarios are continuous creation and unloading of class loaders. It causes excessive allocation and deallocation of nmethods for classes in said class loaders. If call patterns are megamorphic, those nmethods will allocate corresponding vtable stubs for megamorphic inline cache transitions. While the nmethods are recycled, their corresponding vtable stubs are never released. Normally, it is not a problem that vtable stubs are not cleaned up during code cache unloading, because they are shared. There is one for each VM-level signature, and the number of signatures does not grow out of control. However, on SPARC, the vtable stubs are not shared, and are instead continuously allocated, causing a nasty leak that is considerable. SPARC is the only architecture where we do not share vtable stubs. The switch for opting in to vtable stub sharing is the developer flag ShareVtableStubs. The description of the flag makes it seem like turning sharing off is a sweet optimization you can use if your branch prediction is bad and you would rather use a bit more memory, without mentioning that you get a nasty memory leak. It's mentioned that two benchmarks ran faster with sharing turned off. The flag was introduced longer ago than I can track back (Niagara?!), and since then SPARC machines have *much* better branch prediction. This flag doesn't seem to make sense today. The obvious solution is to remove the flag and have all architectures consistently use vtable stub sharing, and hence not leak memory uncontrollably. So that is what I propose to do about this. Webrev: http://cr.openjdk.java.net/~eosterlund/8229345/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8229345 Thanks, /Erik From martin.doerr at sap.com Thu Aug 15 15:07:45 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 15 Aug 2019 15:07:45 +0000 Subject: RFR: 8229258: Rework markOop and markOopDesc into a simpler mark word value carrier In-Reply-To: <29d31d63-5e83-6861-4f2a-92f2f45e6565@oracle.com> References: <72567e47-3b52-8e30-ea6f-9a64fa043c07@redhat.com> <32ccb4ba-0500-2bf4-3761-63a6285f94dc@oracle.com> <5913EBBD-2A13-43A5-9F37-D36E97397365@oracle.com> <1670ce59-e7b5-0023-b1fd-f9f7c19a0eda@oracle.com> <29d31d63-5e83-6861-4f2a-92f2f45e6565@oracle.com> Message-ID: Hi Stefan, > 1) Platform maintainers probably want to run this patch through their > build system. builds on PPC64 and s390. Best regards, Martin > -----Original Message----- > From: hotspot-dev On Behalf Of > coleen.phillimore at oracle.com > Sent: Donnerstag, 15. August 2019 14:57 > To: hotspot-dev at openjdk.java.net > Subject: Re: RFR: 8229258: Rework markOop and markOopDesc into a simpler > mark word value carrier > > > https://cr.openjdk.java.net/~stefank/8229258/webrev.valueMarkWord.03.d > elta/src/hotspot/share/runtime/synchronizer.cpp.udiff.html > > + lock->set_displaced_header(markWord::from_pointer(NULL)); > > > Should this be markWork::zero ? > > + m->set_header(markWord(markWord::zero)); > > > ew. > > I just clicked through the latest incremental and the full oops directory. > > The to_pointer and from_pointer casts are awkward, particularly because > you can do (Edge*)mark.value() too, but it's good to find where we're > using the markWord for various purposes. > > This is a massive improvement.? Dont' change a thing and check it in. > We can do minor cleanups in followup RFEs. > > Thanks! > Coleen > > > On 8/15/19 7:46 AM, Stefan Karlsson wrote: > > Thanks Kim, Roman, Dan and Coleen for reviews and feedback. > > > > I rebased the patch, fixed more alignments, renamed the bug, and rerun > > the test through tier1-3. > > > > > https://cr.openjdk.java.net/~stefank/8229258/webrev.valueMarkWord.03.d > elta/ > > > > > https://cr.openjdk.java.net/~stefank/8229258/webrev.valueMarkWord.03/ > > > > Could I get reviews for this version? I'd also like to ask others to > > at least partially look at this: > > > > 1) Platform maintainers probably want to run this patch through their > > build system. > > 2) SA maintainers (CC:ed serviceability-dev) > > 3) JVMCI maintainers > > > > Thanks, > > StefanK > > > > On 2019-08-14 11:11, Roman Kennke wrote: > >> > >> Am 14.08.19 um 01:26 schrieb Kim Barrett: > >>>> On Aug 12, 2019, at 12:19 PM, Stefan Karlsson > >>>> wrote: > >>>> > >>>> Hi Roman, > >>>> > >>>> Kim helped me figuring out how to get past the volatile issues I > >>>> had with the class markWord { uintptr_t value; ... } version. So, > >>>> I've created a version with that: > >>>> > >>>> > https://cr.openjdk.java.net/~stefank/8229258/webrev.valueMarkWord.01/ > >>>> > >>>> I can go with either approach, so let me now what you all think. > >>> I've finally had time to look at the first proposed change. > >>> > >>> Comparing the first approach (an AllStatic MarkWord class and > markWord > >>> typedef'd to uintptr_t) vs the second approach (markWord is a thin > >>> class wrapping around uintptr_t), I prefer the second. > >>> > >>> * I think the markWord class provides better type safety. It still > >>> involves too many casts sprinkled over the code base, but I think it > >>> also provides a better basis for further cast reduction and > >>> prevention. > >>> > >>> * I think having one markWord class for the data and behavior is > >>> better / more natural than having a markWord typedef for the data and > >>> a MarkWord AllStatic class for the behaviour. > >>> > >>> * I like that the markWord class eliminates the markWord vs MarkWord > >>> homonyms, which I think will be annoying. > >>> > >>> * The markWord class is a trivially copyable class, allowing it to be > >>> efficiently passed around by value, so no disadvantage there. > >>> > >>> I haven't found anything that I think argues for the first over the > >>> second. Other folks might have different priorities or taste. I think > >>> either is better than the status quo. > >>> > >>> I'm still reviewing webrev.valueMarkWord.02, but so far haven't found > >>> anything that makes me want to suggest backing off from that direction. > >>> > >>> Note that the bug summary doesn't describe the second approach. > >> +1 :-) > >> > >> Roman > >> > > From martin.doerr at sap.com Thu Aug 15 15:16:44 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 15 Aug 2019 15:16:44 +0000 Subject: RFR: 8229345: Memory leak due to vtable stubs not being shared on SPARC In-Reply-To: <7cc8059e-e148-f7b1-742a-50a1d6350109@oracle.com> References: <7cc8059e-e148-f7b1-742a-50a1d6350109@oracle.com> Message-ID: Hi Erik, nice change! I like it. We already switched this flag on in SAP JVM on SPARC. We're also convinced that "improves performance markedly for mtrt and compress" is no longer true on recent hardware. Best regards, Martin > -----Original Message----- > From: hotspot-dev On Behalf Of > Erik ?sterlund > Sent: Donnerstag, 15. August 2019 17:01 > To: hotspot-dev developers > Subject: RFR: 8229345: Memory leak due to vtable stubs not being shared on > SPARC > > Hi, > > The code cache can be occupied by vtable stubs on SPARC. One of the > potential scenarios are continuous creation and unloading of class loaders. > It causes excessive allocation and deallocation of nmethods for classes > in said class loaders. If call patterns are megamorphic, those nmethods > will allocate corresponding vtable stubs for megamorphic inline cache > transitions. While the nmethods are recycled, their corresponding vtable > stubs are never released. > > Normally, it is not a problem that vtable stubs are not cleaned up > during code cache unloading, because they are shared. There is one for > each VM-level signature, and the number of signatures does not grow out > of control. > > However, on SPARC, the vtable stubs are not shared, and are instead > continuously allocated, causing a nasty leak that is considerable. > > SPARC is the only architecture where we do not share vtable stubs. The > switch for opting in to vtable stub sharing is the developer flag > ShareVtableStubs. The description of the flag makes it seem like turning > sharing off is a sweet optimization you can use if your branch > prediction is bad and you would rather use a bit more memory, without > mentioning that you get a nasty memory leak. It's mentioned that two > benchmarks ran faster with sharing turned off. The flag was introduced > longer ago than I can track back (Niagara?!), and since then SPARC > machines have *much* better branch prediction. This flag doesn't seem to > make sense today. > > The obvious solution is to remove the flag and have all architectures > consistently use vtable stub sharing, and hence not leak memory > uncontrollably. So that is what I propose to do about this. > > Webrev: > http://cr.openjdk.java.net/~eosterlund/8229345/webrev.00/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8229345 > > Thanks, > /Erik From erik.osterlund at oracle.com Thu Aug 15 15:21:04 2019 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Thu, 15 Aug 2019 17:21:04 +0200 Subject: RFR: 8229345: Memory leak due to vtable stubs not being shared on SPARC In-Reply-To: References: <7cc8059e-e148-f7b1-742a-50a1d6350109@oracle.com> Message-ID: <4B173477-518C-4366-BDBA-8C847D38EEA2@oracle.com> Hi Martin, Thanks for reviewing, and for sharing your experience on your SPARC machines. /Erik > On 15 Aug 2019, at 17:16, Doerr, Martin wrote: > > Hi Erik, > > nice change! I like it. > > We already switched this flag on in SAP JVM on SPARC. > We're also convinced that "improves performance markedly for mtrt and compress" is no longer true on recent hardware. > > Best regards, > Martin > > >> -----Original Message----- >> From: hotspot-dev On Behalf Of >> Erik ?sterlund >> Sent: Donnerstag, 15. August 2019 17:01 >> To: hotspot-dev developers >> Subject: RFR: 8229345: Memory leak due to vtable stubs not being shared on >> SPARC >> >> Hi, >> >> The code cache can be occupied by vtable stubs on SPARC. One of the >> potential scenarios are continuous creation and unloading of class loaders. >> It causes excessive allocation and deallocation of nmethods for classes >> in said class loaders. If call patterns are megamorphic, those nmethods >> will allocate corresponding vtable stubs for megamorphic inline cache >> transitions. While the nmethods are recycled, their corresponding vtable >> stubs are never released. >> >> Normally, it is not a problem that vtable stubs are not cleaned up >> during code cache unloading, because they are shared. There is one for >> each VM-level signature, and the number of signatures does not grow out >> of control. >> >> However, on SPARC, the vtable stubs are not shared, and are instead >> continuously allocated, causing a nasty leak that is considerable. >> >> SPARC is the only architecture where we do not share vtable stubs. The >> switch for opting in to vtable stub sharing is the developer flag >> ShareVtableStubs. The description of the flag makes it seem like turning >> sharing off is a sweet optimization you can use if your branch >> prediction is bad and you would rather use a bit more memory, without >> mentioning that you get a nasty memory leak. It's mentioned that two >> benchmarks ran faster with sharing turned off. The flag was introduced >> longer ago than I can track back (Niagara?!), and since then SPARC >> machines have *much* better branch prediction. This flag doesn't seem to >> make sense today. >> >> The obvious solution is to remove the flag and have all architectures >> consistently use vtable stub sharing, and hence not leak memory >> uncontrollably. So that is what I propose to do about this. >> >> Webrev: >> http://cr.openjdk.java.net/~eosterlund/8229345/webrev.00/ >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8229345 >> >> Thanks, >> /Erik From serguei.spitsyn at oracle.com Thu Aug 15 15:45:34 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 15 Aug 2019 08:45:34 -0700 Subject: RFR: JDK-8227021: VM fails if any sun.boot.library.path paths are longer than JVM_MAXPATHLEN In-Reply-To: References: <5ba808b0-ae52-0d0a-b84b-fc34df35475d@oracle.com> <025da83a-6569-f6ac-7590-5b200ed2344f@oracle.com> <8e62fc61-b46b-0033-f182-cb4a2dbf92fd@oracle.com> <176e6c1c-6e06-b704-0a53-e2cd2800b51f@oracle.com> Message-ID: <71022ee2-7d55-1ba2-99fa-ca3bab88a18c@oracle.com> Hi David, Okay, thanks! This was my guess too. Thanks, Serguei On 8/15/19 02:42, David Holmes wrote: > Hi Serguei, > > On 15/08/2019 6:18 pm, serguei.spitsyn at oracle.com wrote: >> Thank you, Adam! >> >> David, what do you thin about this testing coverage? >> Is it enough for this fix? > > I don't see any real testing of sun.boot.library.path in our tests only: > > ./hotspot/jtreg/runtime/6819213/TestBootNativeLibraryPath.java > ./hotspot/jtreg/runtime/jni/FindClass/FindClassFromBoot.java > > seem to refer to it but the former is restricted to 32-bit systems > only! So this seems to be an area devoid of any real test code outside > of 32-bit. I don't understand why that is the case. So if there's no > regression test then there's no real testing of this code at all. That > said it seems unfair to force Adam to define tests for code that is > effectively untested. It would be reasonable for him to extend > existing tests to cover the long path problem, if they existed. > > But a basic regression test should at least be created IMO. > > David > ----- > >> Thanks, >> Serguei >> >> >> On 8/14/19 04:09, Adam Farley8 wrote: >>> Addendum: I've run the test/hotspot/jtreg/runtime tests against a >>> patched and unpatched build on linux x86 64bit, and the pass/fail >>> rate is identical. >>> >>> 630 passed, 7 failed, and 63 error in both cases. >>> >>> Best Regards >>> >>> Adam Farley >>> IBM Runtimes >>> >>> >>> Adam Farley8/UK/IBM wrote on 13/08/2019 17:36:44: >>> >>> > From: Adam Farley8/UK/IBM >>> > To: "serguei.spitsyn at oracle.com" , >>> > daniel.daugherty at oracle.com >>> > Cc: David Holmes , >>> hotspot-dev at openjdk.java.net >>> > Date: 13/08/2019 17:36 >>> > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path >>> > paths are longer than JVM_MAXPATHLEN >>> > > Hi Serguei, Daniel, >>> > > I ran the bug specific test mentioned in the bug, as well as this: >>> > test/hotspot/jtreg/sanity >>> > > No failures. Well, except for the one we wanted in the bug test. :) >>> > > On reflection, this seems thin, so I'm running some more hotspot >>> tests now. >>> > > Advice welcome. >>> > > Best Regards >>> > >>> > Adam Farley >>> > IBM Runtimes >>> >>> > > "serguei.spitsyn at oracle.com" wrote on >>> > 13/08/2019 17:09:17: >>> > >>> > > From: "serguei.spitsyn at oracle.com" >>> > > To: Adam Farley8 , David Holmes >>> > > >>> > > Cc: hotspot-dev at openjdk.java.net >>> > > Date: 13/08/2019 17:20 >>> > > Subject: Re: RFR: JDK-8227021: VM fails if any >>> sun.boot.library.path >>> > > paths are longer than JVM_MAXPATHLEN >>> > > > > Hi Adam, >>> > > >>> > > Could you, please, tell a little bit on how did you test the fix? >>> > > >>> > > Thanks, >>> > > Serguei >>> > > >>> > > >>> > > On 8/13/19 09:00, serguei.spitsyn at oracle.com wrote: >>> > > Hi Adam, >>> > > >>> > > I'll sponsor the push. >>> > > >>> > > Thanks, >>> > > Serguei >>> > > >>> > > >>> > > On 8/13/19 08:48, Adam Farley8 wrote: >>> > > Hi David, > > >>> > > Since we have two positive reviews (yours and Serguei's), could you >>> > > sponsor the change please? >>> > > >>> > > Best Regards >>> > > >>> > > Adam Farley >>> > > IBM Runtimes >>> > > >>> > > >>> > > David Holmes wrote on 12/08/2019 >>> 23:32:14: >>> > > >>> > > > From: David Holmes >>> > > > To: Adam Farley8 >>> > > > Cc: hotspot-dev at openjdk.java.net, "serguei.spitsyn at oracle.com" >>> > > > >>> > > > Date: 12/08/2019 23:32 >>> > > > Subject: Re: RFR: JDK-8227021: VM fails if any >>> sun.boot.library.path >>> > > > paths are longer than JVM_MAXPATHLEN >>> > > > >>> > > > Looks fine. >>> > > > >>> > > > Thanks, >>> > > > David >>> > > > >>> > > > On 13/08/2019 1:19 am, Adam Farley8 wrote: >>> > > > > Hi David, >>> > > > > >>> > > > > Changes made as requested: >>> > > > > https://urldefense.proofpoint.com/v2/url? >>> > > > >>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.4_webrev&d=DwID- >>> > > > g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- >>> > > > >>> > > >>> > >>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=mZM8IR4e_zmrfcsF3XJjoGEMrZb4WtEL7Y6Ugd6Naqg&s=sZ2UKqqUIq0El- >>> > > > RsqYz6jmTh4Q2UghwdrQX6of8Lw0E&e= >>> > > > > >>> > > > > Best Regards >>> > > > > >>> > > > > Adam Farley >>> > > > > IBM Runtimes >>> > > > > >>> > > > > >>> > > > > David Holmes wrote on 12/08/2019 >>> 04:55:36: >>> > > > > >>> > > > >> From: David Holmes >>> > > > >> To: Adam Farley8 , >>> > > > >> "serguei.spitsyn at oracle.com" >>> > > > >> Cc: hotspot-dev at openjdk.java.net >>> > > > >> Date: 12/08/2019 04:56 >>> > > > >> Subject: Re: RFR: JDK-8227021: ?VM fails if any >>> sun.boot.library.path >>> > > > >> paths are longer than JVM_MAXPATHLEN >>> > > > >> >>> > > > >> Hi Adam, >>> > > > >> >>> > > > >> On 10/08/2019 2:47 am, Adam Farley8 wrote: >>> > > > >> > Hi Serguei, David, >>> > > > >> > >>> > > > >> > My turn to apologise for the delay. :) >>> > > > >> > >>> > > > >> > I've modified the code as per Serguei's request. Take a look >>> > > ?and let me >>> > > > >> > know if this is the sort of thing you were thinking of. >>> > > > >> > >>> > > > >> > Webrev: https://urldefense.proofpoint.com/v2/url? >>> > > > >> >>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.3_webrev_&d=DwID- >>> > > > >> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- >>> > > > >> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- >>> > > > >> >>> > > > >>> > > >>> > >>> yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=L19aeFXoR9JIO62QRPFzZObIU8RbhpCtXSvUibD2ISk&e= >>> > > > >> >>> > > > >> I'd prefer to see the helper just as a file static function >>> > rather ?than >>> > > > >> adding it to the os class. >>> > > > >> >>> > > > >> + ?* supplied array of arrays of chars (a), where n >>> > > > >> >>> > > > >> I assume (a) is meant to refer to the parameter, but you >>> > actually ?called >>> > > > >> it arrayarray. I think "a" or "arr" would suffice. >>> > > > >> >>> > > > >> Thanks, >>> > > > >> David >>> > > > >> >>> > > > >> > Best Regards >>> > > > >> > >>> > > > >> > Adam Farley >>> > > > >> > IBM Runtimes >>> > > > >> > >>> > > > >> > >>> > > > >> > "serguei.spitsyn at oracle.com" >>> ?wrote on >>> > > > >> > 31/07/2019 17:18:05: >>> > > > >> > >>> > > > >> >> From: "serguei.spitsyn at oracle.com" >>> >>> > > > >> >> To: Adam Farley8 , ?David ?Holmes >>> > > > >> >> >>> > > > >> >> Cc: serviceability-dev >>> , >>> > > > >> >> hotspot-dev at openjdk.java.net >>> > > > >> >> Date: 31/07/2019 17:18 >>> > > > >> >> Subject: Re: RFR: JDK-8227021: ?VM fails if any >>> > sun.boot.library.path >>> > > > >> >> paths are longer than JVM_MAXPATHLEN >>> > > > >> >> >>> > > > >> >> Hi Adam, >>> > > > >> >> >>> > > > >> >> It looks Okay to me. >>> > > > >> >> >>> > > > >> >> A couple of minor comments. >>> > > > >> >> >>> > > > >> >> https://urldefense.proofpoint.com/v2/url? >>> > > > >> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021. >>> > > > >> 2_webrev_src_hotspot_&d=DwID-g&c=jf_iaSHvJObTbx- >>> > > > >> >>> siA1ZOg&r=P5m8KWUXJf-CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- >>> > > > >> >>> > > > >>> > > >>> > >>> yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NL6tYuwwDod3DSmj-1ztxAywpO8L52HEyO0wvTR05bs&e= >>> > > > >> >> share/runtime/os.cpp.frames.html >>> > > > >> > >>> > > > >> >> 1362 ? ? ? //release ?allocated storage ?before exiting >>> the vm >>> > > > >> >> 1363 ? ? ? while (i > 0) { >>> > > > >> >> 1364 i--; >>> > > > >> >> 1365 if (opath[i] != NULL) ?{ >>> > > > >> >> 1366 FREE_C_HEAP_ARRAY(char, ??opath[i]); >>> > > > >> >> 1367 } >>> > > > >> >> 1368 ? ? ? } >>> > > > >> >> 1369 FREE_C_HEAP_ARRAY(char*, opath); >>> > > > >> >> >>> > > > >> >> 1377 ? ? ? //release allocated storage before ?returning >>> ?null >>> > > > >> >> 1378 ? ? ? while (i > 0) { >>> > > > >> >> 1379 i--; >>> > > > >> >> 1380 if (opath[i] != NULL) ?{ >>> > > > >> >> 1381 FREE_C_HEAP_ARRAY(char, ??opath[i]); >>> > > > >> >> 1382 } >>> > > > >> >> 1383 ? ? ? } >>> > > > >> >> 1384 FREE_C_HEAP_ARRAY(char*, opath); >>> > > > >> >> >>> > > > >> >> This duplicated fragments is worth to refactor to a >>> function. >>> > > > >> >> Also a space is missed at the beginning of the comment. >>> > > > >> >> >>> > > > >> >> >>> > > > >> >> Thanks, >>> > > > >> >> Serguei >>> > > > >> >> >>> > > > >> >> >>> > > > >> >> >>> > > > >> >> On 7/31/19 02:01, Adam Farley8 wrote: >>> > > > >> >> Hi All, >>> > > > >> >> >>> > > > >> >> Reviewers requested for the change below. >>> > > > >> >> >>> > > > >> >> @David - Agreed. Would you be prepared to sponsor the >>> change? >>> > > > >> >> >>> > > > >> >> Bug: https://urldefense.proofpoint.com/v2/url? >>> > > > >> u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8227021&d=DwID- >>> > > > >> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- >>> > > > >> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- >>> > > > >> >>> > > > >>> > > >>> > >>> yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=xykJ0KLy9AKWO8zmC0amfR7xxUsvyKEjlf3y7WWOqvE&e= >>> > > > >> >> Webrev: https://urldefense.proofpoint.com/v2/url? >>> > > > >> >>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.2_webrev_&d=DwID- >>> > > > >> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- >>> > > > >> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- >>> > > > >> >>> > > > >>> > > >>> > >>> yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NvIza4VVWG3CiDhmQVmXsghH_4h_c5mFJbHwkCUcut0&e= >>> > > > >> >> >>> > > > >> >> Best Regards >>> > > > >> >> >>> > > > >> >> Adam Farley >>> > > > >> >> IBM Runtimes >>> > > > >> >> >>> > > > >> >> P.S. Remembered to add the links this time. :) >>> > > > >> >> >>> > > > >> >> >>> > > > >> >> David Holmes wrote on >>> 30/07/2019?03:37:53: >>> > > > >> >> >>> > > > >> >> > From: David Holmes >>> > > > >> >> > To: Adam Farley8 >>> > > > >> >> > Cc: hotspot-dev at openjdk.java.net, serviceability-dev >>> > > > >> >> > >>> > > > >> >> > Date: 30/07/2019 03:38 >>> > > > >> >> > Subject: Re: RFR: JDK-8227021: VM fails if any >>> > sun.boot.library.path >>> > > > >> >> > paths are longer than JVM_MAXPATHLEN >>> > > > >> >> > >>> > > > >> >> > Hi Adam, >>> > > > >> >> > >>> > > > >> >> > On 25/07/2019 3:57 am, Adam Farley8 wrote: >>> > > > >> >> > > Hi David, >>> > > > >> >> > > >>> > > > >> >> > > Welcome back. :) >>> > > > >> >> > >>> > > > >> >> > Thanks. Sorry for the delay in getting back to this. >>> > > > >> >> > >>> > > > >> >> > I like .v2 as it is much simpler (notwithstanding freeing >>> > > > the ?already >>> > > > >> >> > allocated arrays adds some complexity - thanks for >>> fixing ?that). >>> > > > >> >> > >>> > > > >> >> > I'm still not sure we can't optimise things better for >>> > ?unchangeable >>> > > > >> >> > properties like the boot libary path, but that's >>> another ?RFE. >>> > > > >> >> > >>> > > > >> >> > Thanks, >>> > > > >> >> > David >>> > > > >> >> > >>> > > > >> >> 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 >>> > > > >>> > > >>> > > 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 matthias.baesken at sap.com Thu Aug 15 16:08:36 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 15 Aug 2019 16:08:36 +0000 Subject: RFR: [XS] 8229284: [TESTBUG] jdk/internal/platform/cgroup/TestCgroupMetrics.java fails for - memory:getMemoryUsage Message-ID: Hello, please review this small test adjustment . We sometimes see failures in the jtreg test jdk/internal/platform/cgroup/TestCgroupMetrics.java . Failures look like : java.lang.RuntimeException: Test failed for - memory:getMemoryUsage, expected [56019386368], got [56200986624] at jdk.test.lib.containers.cgroup.MetricsTester.fail(MetricsTester.java:207) at jdk.test.lib.containers.cgroup.MetricsTester.testMemoryUsage(MetricsTester.java:597) at TestCgroupMetrics.main(TestCgroupMetrics.java:53) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:567) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:830) Looking at the coding in MetricsTester.java we expect that "memory.usage_in_bytes" gets larger after one additional allocation of 64 M. However this is sometimes not the case. Reason might be that a GC kicked in and freed space; or for some reasons OS pages were freed. So I make the test more robust and do some allocations in a loop, breaking out of the loop after new values got larger than initial ones . Thanks, Matthias Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8229284 http://cr.openjdk.java.net/~mbaesken/webrevs/8229284.3/ From rkennke at redhat.com Thu Aug 15 17:06:56 2019 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 15 Aug 2019 19:06:56 +0200 Subject: RFR: 8229258: Rework markOop and markOopDesc into a simpler mark word value carrier In-Reply-To: <1670ce59-e7b5-0023-b1fd-f9f7c19a0eda@oracle.com> References: <72567e47-3b52-8e30-ea6f-9a64fa043c07@redhat.com> <32ccb4ba-0500-2bf4-3761-63a6285f94dc@oracle.com> <5913EBBD-2A13-43A5-9F37-D36E97397365@oracle.com> <1670ce59-e7b5-0023-b1fd-f9f7c19a0eda@oracle.com> Message-ID: <86e9cb09-d822-7d9a-2f4c-b19c6c5aebe0@redhat.com> Hi Stefan, I looked over the changes again. I like this much better, a huge improvement over current state, and also better than your first proposal. I also prefer the explicit value() calls. I also built+tested Shenandoah GC again, seems all fine. Didn't know that C++ has an 'explicit' specifier. Oh man. Still seems to have foobared alignment (it was partly kaputted before already): src/hotspot/share/oops/oopsHierarchy.hpp Out of curiosity, what's with the changes in objectMonitor.inline.hpp to access the markWord atomically?: -inline markOop ObjectMonitor::header() const { - return _header; +inline markWord ObjectMonitor::header() const { + return Atomic::load(&_header); } I guess this is good (equal or stronger than before) but is there a rationale behind these changes? I say ship it! Thanks, Roman > Thanks Kim, Roman, Dan and Coleen for reviews and feedback. > > I rebased the patch, fixed more alignments, renamed the bug, and rerun > the test through tier1-3. > > https://cr.openjdk.java.net/~stefank/8229258/webrev.valueMarkWord.03.delta/ > https://cr.openjdk.java.net/~stefank/8229258/webrev.valueMarkWord.03/ > > Could I get reviews for this version? I'd also like to ask others to at > least partially look at this: > > 1) Platform maintainers probably want to run this patch through their > build system. > 2) SA maintainers (CC:ed serviceability-dev) > 3) JVMCI maintainers > > Thanks, > StefanK > > On 2019-08-14 11:11, Roman Kennke wrote: >> >> Am 14.08.19 um 01:26 schrieb Kim Barrett: >>>> On Aug 12, 2019, at 12:19 PM, Stefan Karlsson >>>> wrote: >>>> >>>> Hi Roman, >>>> >>>> Kim helped me figuring out how to get past the volatile issues I had >>>> with the class markWord { uintptr_t value; ... } version. So, I've >>>> created a version with that: >>>> >>>> https://cr.openjdk.java.net/~stefank/8229258/webrev.valueMarkWord.01/ >>>> >>>> I can go with either approach, so let me now what you all think. >>> I've finally had time to look at the first proposed change. >>> >>> Comparing the first approach (an AllStatic MarkWord class and markWord >>> typedef'd to uintptr_t) vs the second approach (markWord is a thin >>> class wrapping around uintptr_t), I prefer the second. >>> >>> * I think the markWord class provides better type safety. It still >>> involves too many casts sprinkled over the code base, but I think it >>> also provides a better basis for further cast reduction and >>> prevention. >>> >>> * I think having one markWord class for the data and behavior is >>> better / more natural than having a markWord typedef for the data and >>> a MarkWord AllStatic class for the behaviour. >>> >>> * I like that the markWord class eliminates the markWord vs MarkWord >>> homonyms, which I think will be annoying. >>> >>> * The markWord class is a trivially copyable class, allowing it to be >>> efficiently passed around by value, so no disadvantage there. >>> >>> I haven't found anything that I think argues for the first over the >>> second. Other folks might have different priorities or taste. I think >>> either is better than the status quo. >>> >>> I'm still reviewing webrev.valueMarkWord.02, but so far haven't found >>> anything that makes me want to suggest backing off from that direction. >>> >>> Note that the bug summary doesn't describe the second approach. >> +1 :-) >> >> Roman >> > From vladimir.kozlov at oracle.com Thu Aug 15 17:35:05 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 15 Aug 2019 10:35:05 -0700 Subject: RFR: 8229345: Memory leak due to vtable stubs not being shared on SPARC In-Reply-To: References: <7cc8059e-e148-f7b1-742a-50a1d6350109@oracle.com> Message-ID: Agree. Changes are good. Thanks, Vladimir On 8/15/19 8:16 AM, Doerr, Martin wrote: > Hi Erik, > > nice change! I like it. > > We already switched this flag on in SAP JVM on SPARC. > We're also convinced that "improves performance markedly for mtrt and compress" is no longer true on recent hardware. > > Best regards, > Martin > > >> -----Original Message----- >> From: hotspot-dev On Behalf Of >> Erik ?sterlund >> Sent: Donnerstag, 15. August 2019 17:01 >> To: hotspot-dev developers >> Subject: RFR: 8229345: Memory leak due to vtable stubs not being shared on >> SPARC >> >> Hi, >> >> The code cache can be occupied by vtable stubs on SPARC. One of the >> potential scenarios are continuous creation and unloading of class loaders. >> It causes excessive allocation and deallocation of nmethods for classes >> in said class loaders. If call patterns are megamorphic, those nmethods >> will allocate corresponding vtable stubs for megamorphic inline cache >> transitions. While the nmethods are recycled, their corresponding vtable >> stubs are never released. >> >> Normally, it is not a problem that vtable stubs are not cleaned up >> during code cache unloading, because they are shared. There is one for >> each VM-level signature, and the number of signatures does not grow out >> of control. >> >> However, on SPARC, the vtable stubs are not shared, and are instead >> continuously allocated, causing a nasty leak that is considerable. >> >> SPARC is the only architecture where we do not share vtable stubs. The >> switch for opting in to vtable stub sharing is the developer flag >> ShareVtableStubs. The description of the flag makes it seem like turning >> sharing off is a sweet optimization you can use if your branch >> prediction is bad and you would rather use a bit more memory, without >> mentioning that you get a nasty memory leak. It's mentioned that two >> benchmarks ran faster with sharing turned off. The flag was introduced >> longer ago than I can track back (Niagara?!), and since then SPARC >> machines have *much* better branch prediction. This flag doesn't seem to >> make sense today. >> >> The obvious solution is to remove the flag and have all architectures >> consistently use vtable stub sharing, and hence not leak memory >> uncontrollably. So that is what I propose to do about this. >> >> Webrev: >> http://cr.openjdk.java.net/~eosterlund/8229345/webrev.00/ >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8229345 >> >> Thanks, >> /Erik From erik.osterlund at oracle.com Thu Aug 15 18:05:29 2019 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Thu, 15 Aug 2019 20:05:29 +0200 Subject: RFR: 8229345: Memory leak due to vtable stubs not being shared on SPARC In-Reply-To: References: <7cc8059e-e148-f7b1-742a-50a1d6350109@oracle.com> Message-ID: Hi Vladimir, Thanks for the review! /Erik > On 15 Aug 2019, at 19:35, Vladimir Kozlov wrote: > > Agree. Changes are good. > > Thanks, > Vladimir > >> On 8/15/19 8:16 AM, Doerr, Martin wrote: >> Hi Erik, >> nice change! I like it. >> We already switched this flag on in SAP JVM on SPARC. >> We're also convinced that "improves performance markedly for mtrt and compress" is no longer true on recent hardware. >> Best regards, >> Martin >>> -----Original Message----- >>> From: hotspot-dev On Behalf Of >>> Erik ?sterlund >>> Sent: Donnerstag, 15. August 2019 17:01 >>> To: hotspot-dev developers >>> Subject: RFR: 8229345: Memory leak due to vtable stubs not being shared on >>> SPARC >>> >>> Hi, >>> >>> The code cache can be occupied by vtable stubs on SPARC. One of the >>> potential scenarios are continuous creation and unloading of class loaders. >>> It causes excessive allocation and deallocation of nmethods for classes >>> in said class loaders. If call patterns are megamorphic, those nmethods >>> will allocate corresponding vtable stubs for megamorphic inline cache >>> transitions. While the nmethods are recycled, their corresponding vtable >>> stubs are never released. >>> >>> Normally, it is not a problem that vtable stubs are not cleaned up >>> during code cache unloading, because they are shared. There is one for >>> each VM-level signature, and the number of signatures does not grow out >>> of control. >>> >>> However, on SPARC, the vtable stubs are not shared, and are instead >>> continuously allocated, causing a nasty leak that is considerable. >>> >>> SPARC is the only architecture where we do not share vtable stubs. The >>> switch for opting in to vtable stub sharing is the developer flag >>> ShareVtableStubs. The description of the flag makes it seem like turning >>> sharing off is a sweet optimization you can use if your branch >>> prediction is bad and you would rather use a bit more memory, without >>> mentioning that you get a nasty memory leak. It's mentioned that two >>> benchmarks ran faster with sharing turned off. The flag was introduced >>> longer ago than I can track back (Niagara?!), and since then SPARC >>> machines have *much* better branch prediction. This flag doesn't seem to >>> make sense today. >>> >>> The obvious solution is to remove the flag and have all architectures >>> consistently use vtable stub sharing, and hence not leak memory >>> uncontrollably. So that is what I propose to do about this. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~eosterlund/8229345/webrev.00/ >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8229345 >>> >>> Thanks, >>> /Erik From stefan.karlsson at oracle.com Thu Aug 15 19:26:34 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 15 Aug 2019 21:26:34 +0200 Subject: RFR: 8229258: Rework markOop and markOopDesc into a simpler mark word value carrier In-Reply-To: <86e9cb09-d822-7d9a-2f4c-b19c6c5aebe0@redhat.com> References: <72567e47-3b52-8e30-ea6f-9a64fa043c07@redhat.com> <32ccb4ba-0500-2bf4-3761-63a6285f94dc@oracle.com> <5913EBBD-2A13-43A5-9F37-D36E97397365@oracle.com> <1670ce59-e7b5-0023-b1fd-f9f7c19a0eda@oracle.com> <86e9cb09-d822-7d9a-2f4c-b19c6c5aebe0@redhat.com> Message-ID: <6d432589-afc6-6f70-f6b7-3837e5b2ae39@oracle.com> Hi Roman, On 2019-08-15 19:06, Roman Kennke wrote: > Hi Stefan, > > I looked over the changes again. I like this much better, a huge > improvement over current state, and also better than your first > proposal. I also prefer the explicit value() calls. Great! > > I also built+tested Shenandoah GC again, seems all fine. > > Didn't know that C++ has an 'explicit' specifier. Oh man. > > Still seems to have foobared alignment (it was partly kaputted before > already): > src/hotspot/share/oops/oopsHierarchy.hpp You're right. I removed one stray whitespace: $ hg diff diff --git a/src/hotspot/share/oops/oopsHierarchy.hpp b/src/hotspot/share/oops/oopsHierarchy.hpp --- a/src/hotspot/share/oops/oopsHierarchy.hpp +++ b/src/hotspot/share/oops/oopsHierarchy.hpp @@ -46,7 +46,7 @@ ?typedef class?? instanceOopDesc*??????????? instanceOop; ?typedef class?? arrayOopDesc*?????????????? arrayOop; ?typedef class???? objArrayOopDesc*??????????? objArrayOop; -typedef class???? typeArrayOopDesc*??????????? typeArrayOop; +typedef class???? typeArrayOopDesc*?????????? typeArrayOop; ?#else I think the other indentation is done on purpose: typedef class oopDesc*??????????????????? oop; typedef class?? instanceOopDesc*??????????? instanceOop; typedef class?? arrayOopDesc*?????????????? arrayOop; typedef class???? objArrayOopDesc*??????????? objArrayOop; typedef class???? typeArrayOopDesc*?????????? typeArrayOop; to show the oops hierarchy. > > Out of curiosity, what's with the changes in objectMonitor.inline.hpp to > access the markWord atomically?: > > -inline markOop ObjectMonitor::header() const { > - return _header; > +inline markWord ObjectMonitor::header() const { > + return Atomic::load(&_header); > } > > I guess this is good (equal or stronger than before) but is there a > rationale behind these changes? Ahh. Right. That was done to solve the problems I were having with volatiles. For example: src/hotspot/share/runtime/objectMonitor.inline.hpp:38:10: error: binding reference of type 'const markWord&' to 'const volatile markWord' discards qualifiers ?? return _header; and: src/hotspot/share/runtime/basicLock.hpp:40:74: error: implicit dereference will not access object of type ?volatile markWord? in statement [-Werror] ? void???????? set_displaced_header(markWord header) { _displaced_header = header; } Kim suggested that the fact that these fields were volatile was an indication that we should be doing some kind of atomic/ordered operation. By replacing these loads and stores with calls to the Atomic APIs, and providing the PrimitiveConversions::Translate specialization, we could solve that problem. > > I say ship it! Thanks a lot for reviewing this! StefanK > > Thanks, > Roman > > >> Thanks Kim, Roman, Dan and Coleen for reviews and feedback. >> >> I rebased the patch, fixed more alignments, renamed the bug, and rerun >> the test through tier1-3. >> >> https://cr.openjdk.java.net/~stefank/8229258/webrev.valueMarkWord.03.delta/ >> https://cr.openjdk.java.net/~stefank/8229258/webrev.valueMarkWord.03/ >> >> Could I get reviews for this version? I'd also like to ask others to at >> least partially look at this: >> >> 1) Platform maintainers probably want to run this patch through their >> build system. >> 2) SA maintainers (CC:ed serviceability-dev) >> 3) JVMCI maintainers >> >> Thanks, >> StefanK >> >> On 2019-08-14 11:11, Roman Kennke wrote: >>> Am 14.08.19 um 01:26 schrieb Kim Barrett: >>>>> On Aug 12, 2019, at 12:19 PM, Stefan Karlsson >>>>> wrote: >>>>> >>>>> Hi Roman, >>>>> >>>>> Kim helped me figuring out how to get past the volatile issues I had >>>>> with the class markWord { uintptr_t value; ... } version. So, I've >>>>> created a version with that: >>>>> >>>>> https://cr.openjdk.java.net/~stefank/8229258/webrev.valueMarkWord.01/ >>>>> >>>>> I can go with either approach, so let me now what you all think. >>>> I've finally had time to look at the first proposed change. >>>> >>>> Comparing the first approach (an AllStatic MarkWord class and markWord >>>> typedef'd to uintptr_t) vs the second approach (markWord is a thin >>>> class wrapping around uintptr_t), I prefer the second. >>>> >>>> * I think the markWord class provides better type safety. It still >>>> involves too many casts sprinkled over the code base, but I think it >>>> also provides a better basis for further cast reduction and >>>> prevention. >>>> >>>> * I think having one markWord class for the data and behavior is >>>> better / more natural than having a markWord typedef for the data and >>>> a MarkWord AllStatic class for the behaviour. >>>> >>>> * I like that the markWord class eliminates the markWord vs MarkWord >>>> homonyms, which I think will be annoying. >>>> >>>> * The markWord class is a trivially copyable class, allowing it to be >>>> efficiently passed around by value, so no disadvantage there. >>>> >>>> I haven't found anything that I think argues for the first over the >>>> second. Other folks might have different priorities or taste. I think >>>> either is better than the status quo. >>>> >>>> I'm still reviewing webrev.valueMarkWord.02, but so far haven't found >>>> anything that makes me want to suggest backing off from that direction. >>>> >>>> Note that the bug summary doesn't describe the second approach. >>> +1 :-) >>> >>> Roman >>> From stefan.karlsson at oracle.com Thu Aug 15 19:37:18 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 15 Aug 2019 21:37:18 +0200 Subject: RFR: 8229258: Rework markOop and markOopDesc into a simpler mark word value carrier In-Reply-To: <29d31d63-5e83-6861-4f2a-92f2f45e6565@oracle.com> References: <72567e47-3b52-8e30-ea6f-9a64fa043c07@redhat.com> <32ccb4ba-0500-2bf4-3761-63a6285f94dc@oracle.com> <5913EBBD-2A13-43A5-9F37-D36E97397365@oracle.com> <1670ce59-e7b5-0023-b1fd-f9f7c19a0eda@oracle.com> <29d31d63-5e83-6861-4f2a-92f2f45e6565@oracle.com> Message-ID: <735439bd-e283-c8f6-059c-d0c08092bd32@oracle.com> On 2019-08-15 14:56, coleen.phillimore at oracle.com wrote: > > https://cr.openjdk.java.net/~stefank/8229258/webrev.valueMarkWord.03.delta/src/hotspot/share/runtime/synchronizer.cpp.udiff.html > > > + lock->set_displaced_header(markWord::from_pointer(NULL)); > > > Should this be markWork::zero ? > > + m->set_header(markWord(markWord::zero)); I can change it to that if you prefer it like that. > > > ew. > > I just clicked through the latest incremental and the full oops > directory. > > The to_pointer and from_pointer casts are awkward, particularly > because you can do (Edge*)mark.value() too, but it's good to find > where we're using the markWord for various purposes. I think Kim preferred the to_pointer() calls, and I tried to stay away from using .value() as much as possible. Using the value() function is a way to break free from the markWord abstraction and do arbitrary bit manipulations on the mark word, instead of going through the markWord API. I'd prefer if we used value() as little as possible. Regarding the example above, we could also change the code to this: mark.to_pointer(). > > This is a massive improvement.? Dont' change a thing and check it in.? > We can do minor cleanups in followup RFEs. Yes. I think this is the most sane way to proceed with this. Thanks for reviewing! StefanK > > Thanks! > Coleen > > > On 8/15/19 7:46 AM, Stefan Karlsson wrote: >> Thanks Kim, Roman, Dan and Coleen for reviews and feedback. >> >> I rebased the patch, fixed more alignments, renamed the bug, and >> rerun the test through tier1-3. >> >> https://cr.openjdk.java.net/~stefank/8229258/webrev.valueMarkWord.03.delta/ >> >> https://cr.openjdk.java.net/~stefank/8229258/webrev.valueMarkWord.03/ >> >> Could I get reviews for this version? I'd also like to ask others to >> at least partially look at this: >> >> 1) Platform maintainers probably want to run this patch through their >> build system. >> 2) SA maintainers (CC:ed serviceability-dev) >> 3) JVMCI maintainers >> >> Thanks, >> StefanK >> >> On 2019-08-14 11:11, Roman Kennke wrote: >>> >>> Am 14.08.19 um 01:26 schrieb Kim Barrett: >>>>> On Aug 12, 2019, at 12:19 PM, Stefan Karlsson >>>>> wrote: >>>>> >>>>> Hi Roman, >>>>> >>>>> Kim helped me figuring out how to get past the volatile issues I >>>>> had with the class markWord { uintptr_t value; ... } version. So, >>>>> I've created a version with that: >>>>> >>>>> https://cr.openjdk.java.net/~stefank/8229258/webrev.valueMarkWord.01/ >>>>> >>>>> I can go with either approach, so let me now what you all think. >>>> I've finally had time to look at the first proposed change. >>>> >>>> Comparing the first approach (an AllStatic MarkWord class and markWord >>>> typedef'd to uintptr_t) vs the second approach (markWord is a thin >>>> class wrapping around uintptr_t), I prefer the second. >>>> >>>> * I think the markWord class provides better type safety. It still >>>> involves too many casts sprinkled over the code base, but I think it >>>> also provides a better basis for further cast reduction and >>>> prevention. >>>> >>>> * I think having one markWord class for the data and behavior is >>>> better / more natural than having a markWord typedef for the data and >>>> a MarkWord AllStatic class for the behaviour. >>>> >>>> * I like that the markWord class eliminates the markWord vs MarkWord >>>> homonyms, which I think will be annoying. >>>> >>>> * The markWord class is a trivially copyable class, allowing it to be >>>> efficiently passed around by value, so no disadvantage there. >>>> >>>> I haven't found anything that I think argues for the first over the >>>> second. Other folks might have different priorities or taste. I think >>>> either is better than the status quo. >>>> >>>> I'm still reviewing webrev.valueMarkWord.02, but so far haven't found >>>> anything that makes me want to suggest backing off from that >>>> direction. >>>> >>>> Note that the bug summary doesn't describe the second approach. >>> +1 :-) >>> >>> Roman >>> >> > From stefan.karlsson at oracle.com Thu Aug 15 19:37:45 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 15 Aug 2019 21:37:45 +0200 Subject: RFR: 8229258: Rework markOop and markOopDesc into a simpler mark word value carrier In-Reply-To: References: <72567e47-3b52-8e30-ea6f-9a64fa043c07@redhat.com> <32ccb4ba-0500-2bf4-3761-63a6285f94dc@oracle.com> <5913EBBD-2A13-43A5-9F37-D36E97397365@oracle.com> <1670ce59-e7b5-0023-b1fd-f9f7c19a0eda@oracle.com> <29d31d63-5e83-6861-4f2a-92f2f45e6565@oracle.com> Message-ID: Thanks Martin! StefanK On 2019-08-15 17:07, Doerr, Martin wrote: > Hi Stefan, > >> 1) Platform maintainers probably want to run this patch through their >> build system. > builds on PPC64 and s390. > > Best regards, > Martin > > >> -----Original Message----- >> From: hotspot-dev On Behalf Of >> coleen.phillimore at oracle.com >> Sent: Donnerstag, 15. August 2019 14:57 >> To: hotspot-dev at openjdk.java.net >> Subject: Re: RFR: 8229258: Rework markOop and markOopDesc into a simpler >> mark word value carrier >> >> >> https://cr.openjdk.java.net/~stefank/8229258/webrev.valueMarkWord.03.d >> elta/src/hotspot/share/runtime/synchronizer.cpp.udiff.html >> >> + lock->set_displaced_header(markWord::from_pointer(NULL)); >> >> >> Should this be markWork::zero ? >> >> + m->set_header(markWord(markWord::zero)); >> >> >> ew. >> >> I just clicked through the latest incremental and the full oops directory. >> >> The to_pointer and from_pointer casts are awkward, particularly because >> you can do (Edge*)mark.value() too, but it's good to find where we're >> using the markWord for various purposes. >> >> This is a massive improvement.? Dont' change a thing and check it in. >> We can do minor cleanups in followup RFEs. >> >> Thanks! >> Coleen >> >> >> On 8/15/19 7:46 AM, Stefan Karlsson wrote: >>> Thanks Kim, Roman, Dan and Coleen for reviews and feedback. >>> >>> I rebased the patch, fixed more alignments, renamed the bug, and rerun >>> the test through tier1-3. >>> >>> >> https://cr.openjdk.java.net/~stefank/8229258/webrev.valueMarkWord.03.d >> elta/ >>> >> https://cr.openjdk.java.net/~stefank/8229258/webrev.valueMarkWord.03/ >>> Could I get reviews for this version? I'd also like to ask others to >>> at least partially look at this: >>> >>> 1) Platform maintainers probably want to run this patch through their >>> build system. >>> 2) SA maintainers (CC:ed serviceability-dev) >>> 3) JVMCI maintainers >>> >>> Thanks, >>> StefanK >>> >>> On 2019-08-14 11:11, Roman Kennke wrote: >>>> Am 14.08.19 um 01:26 schrieb Kim Barrett: >>>>>> On Aug 12, 2019, at 12:19 PM, Stefan Karlsson >>>>>> wrote: >>>>>> >>>>>> Hi Roman, >>>>>> >>>>>> Kim helped me figuring out how to get past the volatile issues I >>>>>> had with the class markWord { uintptr_t value; ... } version. So, >>>>>> I've created a version with that: >>>>>> >>>>>> >> https://cr.openjdk.java.net/~stefank/8229258/webrev.valueMarkWord.01/ >>>>>> I can go with either approach, so let me now what you all think. >>>>> I've finally had time to look at the first proposed change. >>>>> >>>>> Comparing the first approach (an AllStatic MarkWord class and >> markWord >>>>> typedef'd to uintptr_t) vs the second approach (markWord is a thin >>>>> class wrapping around uintptr_t), I prefer the second. >>>>> >>>>> * I think the markWord class provides better type safety. It still >>>>> involves too many casts sprinkled over the code base, but I think it >>>>> also provides a better basis for further cast reduction and >>>>> prevention. >>>>> >>>>> * I think having one markWord class for the data and behavior is >>>>> better / more natural than having a markWord typedef for the data and >>>>> a MarkWord AllStatic class for the behaviour. >>>>> >>>>> * I like that the markWord class eliminates the markWord vs MarkWord >>>>> homonyms, which I think will be annoying. >>>>> >>>>> * The markWord class is a trivially copyable class, allowing it to be >>>>> efficiently passed around by value, so no disadvantage there. >>>>> >>>>> I haven't found anything that I think argues for the first over the >>>>> second. Other folks might have different priorities or taste. I think >>>>> either is better than the status quo. >>>>> >>>>> I'm still reviewing webrev.valueMarkWord.02, but so far haven't found >>>>> anything that makes me want to suggest backing off from that direction. >>>>> >>>>> Note that the bug summary doesn't describe the second approach. >>>> +1 :-) >>>> >>>> Roman >>>> From kim.barrett at oracle.com Thu Aug 15 22:59:57 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 15 Aug 2019 18:59:57 -0400 Subject: RFR: 8229258: Rework markOop and markOopDesc into a simpler mark word value carrier In-Reply-To: <1670ce59-e7b5-0023-b1fd-f9f7c19a0eda@oracle.com> References: <72567e47-3b52-8e30-ea6f-9a64fa043c07@redhat.com> <32ccb4ba-0500-2bf4-3761-63a6285f94dc@oracle.com> <5913EBBD-2A13-43A5-9F37-D36E97397365@oracle.com> <1670ce59-e7b5-0023-b1fd-f9f7c19a0eda@oracle.com> Message-ID: <00FC5053-D5B8-4DD8-96A3-95E12ED7C18C@oracle.com> > On Aug 15, 2019, at 7:46 AM, Stefan Karlsson wrote: > > Thanks Kim, Roman, Dan and Coleen for reviews and feedback. > > I rebased the patch, fixed more alignments, renamed the bug, and rerun the test through tier1-3. > > https://cr.openjdk.java.net/~stefank/8229258/webrev.valueMarkWord.03.delta/ > https://cr.openjdk.java.net/~stefank/8229258/webrev.valueMarkWord.03/ > > Could I get reviews for this version? I'd also like to ask others to at least partially look at this: Here's my comments through webrev.valueMarkWord.03. Looks good. There are a couple of small fixes for which I don't need a new webrev, which are listed first below. Then there are some broader items which could be addressed in followup improvements. ------------------------------------------------------------------------------ src/hotspot/share/oops/markOop.hpp 109 template operator T(); My mistake in the earlier review comment. Function should be const qualified, e.g. that should be template operator T() const; ------------------------------------------------------------------------------ src/hotspot/share/runtime/biasedLocking.cpp 695 prototype.bias_epoch() == mark.bias_epoch())) { I think one more leading space needs to be deleted to get proper alignment here. Or reformat this long and complex if control expression. ------------------------------------------------------------------------------ src/hotspot/share/runtime/vframe.cpp 244 // FIXME: mark is set but not used below. 245 // Either the comment or the code is broken. Is there a bug for this? ------------------------------------------------------------------------------ The remainder seem like they could be followup improvements. ------------------------------------------------------------------------------ src/hotspot/share/oops/markOop.hpp 138 static const uintptr_t zero = 0; All occurrences of this are either (1) markWord member initializater (2) markWord variable initializer (3) temporary markWord initializer There don't appear to be any bare uses otherwise. I think nicer is static markWord zero() { return markWord(0); } (For C++11: `static constexpr markWord zero = markWord(0);`) This seems like it could be a followup improvement. ------------------------------------------------------------------------------ [This is also related to Coleen's comments about to_pointer.] Looking at the changes, in order to reduce the amount of casting pixie dust sprinkled on our code base, I now think markWord::to_pointer should have a template overload, with the template parameter designating the return type. And I think the return type for the non-template should be const qualified, and the template should handle cv qualifiers. Like so (I think, I haven't actually tested this) const void* to_pointer() const { return reinterpret_cast(_value); } template T* to_pointer() const { typedef typename RemoveCV::type TT; return reinterpret_cast(_value); } If one wants a void* then use m.to_pointer(). (I almost want to call it "pointer_to" so it reads "pointer to T".) Coleen and I talked about a possible alternative to the template overload. Perhaps there is a small and fixed number of pointer types we want to support conversion to, in which case we could have a small number of type-specific to_xxx_pointer variants? But I'm not sure the number is actually small and fixed. This seems like it could be a followup improvement. ------------------------------------------------------------------------------ src/hotspot/share/interpreter/bytecodeInterpreter.cpp In the run() function, there are a lot of casts of markWord::value() results or constants from markWord that I think could be removed. Some of them might want C++11 explicitly typed enums though. This seems like it could be a followup improvement. ------------------------------------------------------------------------------ From david.holmes at oracle.com Fri Aug 16 00:55:47 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 16 Aug 2019 10:55:47 +1000 Subject: RFR: 8229345: Memory leak due to vtable stubs not being shared on SPARC In-Reply-To: <7cc8059e-e148-f7b1-742a-50a1d6350109@oracle.com> References: <7cc8059e-e148-f7b1-742a-50a1d6350109@oracle.com> Message-ID: <4402b19c-75f1-f0cc-4355-03eb6d5bd62c@oracle.com> Hi Erik, Probably not needed but looks good to me too. Another flag bytes the dust. FYI this is a "day one" setting going back to 2000. Though the reasoning for it probably predates that and comes from the Solaris Production VM (aka Exact VM). :) Cheers, David On 16/08/2019 1:01 am, Erik ?sterlund wrote: > Hi, > > The code cache can be occupied by vtable stubs on SPARC. One of the > potential scenarios are continuous creation and unloading of class loaders. > It causes excessive allocation and deallocation of nmethods for classes > in said class loaders. If call patterns are megamorphic, those nmethods > will allocate corresponding vtable stubs for megamorphic inline cache > transitions. While the nmethods are recycled, their corresponding vtable > stubs are never released. > > Normally, it is not a problem that vtable stubs are not cleaned up > during code cache unloading, because they are shared. There is one for > each VM-level signature, and the number of signatures does not grow out > of control. > > However, on SPARC, the vtable stubs are not shared, and are instead > continuously allocated, causing a nasty leak that is considerable. > > SPARC is the only architecture where we do not share vtable stubs. The > switch for opting in to vtable stub sharing is the developer flag > ShareVtableStubs. The description of the flag makes it seem like turning > sharing off is a sweet optimization you can use if your branch > prediction is bad and you would rather use a bit more memory, without > mentioning that you get a nasty memory leak. It's mentioned that two > benchmarks ran faster with sharing turned off. The flag was introduced > longer ago than I can track back (Niagara?!), and since then SPARC > machines have *much* better branch prediction. This flag doesn't seem to > make sense today. > > The obvious solution is to remove the flag and have all architectures > consistently use vtable stub sharing, and hence not leak memory > uncontrollably. So that is what I propose to do about this. > > Webrev: > http://cr.openjdk.java.net/~eosterlund/8229345/webrev.00/ > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8229345 > > Thanks, > /Erik From matthias.baesken at sap.com Fri Aug 16 06:10:38 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 16 Aug 2019 06:10:38 +0000 Subject: RFR [XS] : 8229182: runtime/containers/docker/TestMemoryAwareness.java test fails on SLES12 References: <6563ed4bd315281320e11755597fec24f4092ded.camel@redhat.com> <0924470c2bac638fa1feab7d63ee71a57904e408.camel@redhat.com> Message-ID: > Unfortunately we do not see the expected "java.lang.OutOfMemoryError" > in the nightly test runs . > > When I execute the jtreg test locally on the same (!) ppc64le machine , > under the same user but not from the test framework we use nightly > the "java.lang.OutOfMemoryError" shows up. Hello, after looking a bit more into it, we observed that the nightly runs set a higher -Xmx = 768m value that gets inherited into the DockerRunOptions And made the central test fail . So I had to remove this : 105 // make sure we avoid Xmx settings from the jtreg vmoptions 106 opts.appendTestJavaOptions = false; New webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8229182.2/ Best regards, Matthias > > Hi Christoph, > > > > > Hi Matthias, > > > > looks good to me in general. > > > > However, I'm not convinced that line 114 > > ".shouldContain("java.lang.OutOfMemoryError");" won't provoke a test > > error in case the child process was killed by the container, e.g. exited with > > exit code 137. We should at least run this patch for several days in our > system > > to see if it catches all variations of the problem. > > > > Unfortunately we do not see the expected "java.lang.OutOfMemoryError" > in the nightly test runs . > > When I execute the jtreg test locally on the same (!) ppc64le machine , > under the same user but not from the test framework we use nightly > the "java.lang.OutOfMemoryError" shows up. > > Best regards, Matthias > > From erik.osterlund at oracle.com Fri Aug 16 06:14:31 2019 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Fri, 16 Aug 2019 08:14:31 +0200 Subject: RFR: 8229345: Memory leak due to vtable stubs not being shared on SPARC In-Reply-To: <4402b19c-75f1-f0cc-4355-03eb6d5bd62c@oracle.com> References: <7cc8059e-e148-f7b1-742a-50a1d6350109@oracle.com> <4402b19c-75f1-f0cc-4355-03eb6d5bd62c@oracle.com> Message-ID: <533A31DD-6056-488C-BCFC-5EE9181A0FF3@oracle.com> Hi David, Wow, this flag sure has overstayed its welcome. Thanks for the review! /Erik > On 16 Aug 2019, at 02:55, David Holmes wrote: > > Hi Erik, > > Probably not needed but looks good to me too. Another flag bytes the dust. > > FYI this is a "day one" setting going back to 2000. Though the reasoning for it probably predates that and comes from the Solaris Production VM (aka Exact VM). :) > > Cheers, > David > >> On 16/08/2019 1:01 am, Erik ?sterlund wrote: >> Hi, >> The code cache can be occupied by vtable stubs on SPARC. One of the potential scenarios are continuous creation and unloading of class loaders. >> It causes excessive allocation and deallocation of nmethods for classes in said class loaders. If call patterns are megamorphic, those nmethods will allocate corresponding vtable stubs for megamorphic inline cache transitions. While the nmethods are recycled, their corresponding vtable stubs are never released. >> Normally, it is not a problem that vtable stubs are not cleaned up during code cache unloading, because they are shared. There is one for each VM-level signature, and the number of signatures does not grow out of control. >> However, on SPARC, the vtable stubs are not shared, and are instead continuously allocated, causing a nasty leak that is considerable. >> SPARC is the only architecture where we do not share vtable stubs. The switch for opting in to vtable stub sharing is the developer flag ShareVtableStubs. The description of the flag makes it seem like turning sharing off is a sweet optimization you can use if your branch prediction is bad and you would rather use a bit more memory, without mentioning that you get a nasty memory leak. It's mentioned that two benchmarks ran faster with sharing turned off. The flag was introduced longer ago than I can track back (Niagara?!), and since then SPARC machines have *much* better branch prediction. This flag doesn't seem to make sense today. >> The obvious solution is to remove the flag and have all architectures consistently use vtable stub sharing, and hence not leak memory uncontrollably. So that is what I propose to do about this. >> Webrev: >> http://cr.openjdk.java.net/~eosterlund/8229345/webrev.00/ >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8229345 >> Thanks, >> /Erik From sgehwolf at redhat.com Fri Aug 16 08:02:43 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 16 Aug 2019 10:02:43 +0200 Subject: RFR [XS] : 8229182: runtime/containers/docker/TestMemoryAwareness.java test fails on SLES12 In-Reply-To: References: <6563ed4bd315281320e11755597fec24f4092ded.camel@redhat.com> <0924470c2bac638fa1feab7d63ee71a57904e408.camel@redhat.com> Message-ID: <9187885973675ab53221ad3140e79e0115e509a2.camel@redhat.com> Hi Matthias, On Fri, 2019-08-16 at 06:10 +0000, Baesken, Matthias wrote: > > Unfortunately we do not see the expected "java.lang.OutOfMemoryError" > > in the nightly test runs . > > > > When I execute the jtreg test locally on the same (!) ppc64le machine , > > under the same user but not from the test framework we use nightly > > the "java.lang.OutOfMemoryError" shows up. > > Hello, after looking a bit more into it, we observed that the nightly runs set a higher -Xmx = 768m value that gets inherited into the DockerRunOptions > And made the central test fail . > So I had to remove this : > > 105 // make sure we avoid Xmx settings from the jtreg vmoptions > 106 opts.appendTestJavaOptions = false; Can we not set -Xmx explicitly after any test options have been appended so that it takes precedence? It seems fragile to disable appinding all test options altogether. Clearly, this test is susceptible to passed -Xmx options. Failing that, could we just omit the -Xmx option? Thanks, Severin > New webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8229182.2/ > > Best regards, Matthias > > > > Hi Christoph, > > > > > Hi Matthias, > > > > > > looks good to me in general. > > > > > > However, I'm not convinced that line 114 > > > ".shouldContain("java.lang.OutOfMemoryError");" won't provoke a test > > > error in case the child process was killed by the container, e.g. exited with > > > exit code 137. We should at least run this patch for several days in our > > system > > > to see if it catches all variations of the problem. > > > > > > > Unfortunately we do not see the expected "java.lang.OutOfMemoryError" > > in the nightly test runs . > > > > When I execute the jtreg test locally on the same (!) ppc64le machine , > > under the same user but not from the test framework we use nightly > > the "java.lang.OutOfMemoryError" shows up. > > > > Best regards, Matthias > > > > From matthias.baesken at sap.com Fri Aug 16 08:14:45 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 16 Aug 2019 08:14:45 +0000 Subject: RFR [XS] : 8229182: runtime/containers/docker/TestMemoryAwareness.java test fails on SLES12 In-Reply-To: <9187885973675ab53221ad3140e79e0115e509a2.camel@redhat.com> References: <6563ed4bd315281320e11755597fec24f4092ded.camel@redhat.com> <0924470c2bac638fa1feab7d63ee71a57904e408.camel@redhat.com> <9187885973675ab53221ad3140e79e0115e509a2.camel@redhat.com> Message-ID: > Can we not set -Xmx explicitly after any test options have been > appended so that it takes precedence? Hi Bob, do you have a good estimate for an Xmx to set ? > It seems fragile to disable > appinding all test options altogether. Clearly, this test is > susceptible to passed -Xmx options. We have here a java - execution taking place in the docker container, not the test machine itself . I am not sure , are the "regular" test options so good for this special execution ? Some maybe are , some aren?t ... E.g. we ended up with -Xmx768m -Djava.awt.headless=true and more strange settings in the "docker run" call because of this ... Best regards, Matthias > Hi Matthias, > > On Fri, 2019-08-16 at 06:10 +0000, Baesken, Matthias wrote: > > > Unfortunately we do not see the expected > "java.lang.OutOfMemoryError" > > > in the nightly test runs . > > > > > > When I execute the jtreg test locally on the same (!) ppc64le machine , > > > under the same user but not from the test framework we use nightly > > > the "java.lang.OutOfMemoryError" shows up. > > > > Hello, after looking a bit more into it, we observed that the nightly runs > set a higher -Xmx = 768m value that gets inherited into the > DockerRunOptions > > And made the central test fail . > > So I had to remove this : > > > > 105 // make sure we avoid Xmx settings from the jtreg vmoptions > > 106 opts.appendTestJavaOptions = false; > > Can we not set -Xmx explicitly after any test options have been > appended so that it takes precedence? It seems fragile to disable > appinding all test options altogether. Clearly, this test is > susceptible to passed -Xmx options. > > Failing that, could we just omit the -Xmx option? > > Thanks, > Severin > > > New webrev : > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8229182.2/ > > > > Best regards, Matthias > > > > > > > Hi Christoph, > > > > > > > Hi Matthias, > > > > > > > > looks good to me in general. > > > > > > > > However, I'm not convinced that line 114 > > > > ".shouldContain("java.lang.OutOfMemoryError");" won't provoke a > test > > > > error in case the child process was killed by the container, e.g. exited > with > > > > exit code 137. We should at least run this patch for several days in our > > > system > > > > to see if it catches all variations of the problem. > > > > > > > > > > Unfortunately we do not see the expected > "java.lang.OutOfMemoryError" > > > in the nightly test runs . > > > > > > When I execute the jtreg test locally on the same (!) ppc64le machine , > > > under the same user but not from the test framework we use nightly > > > the "java.lang.OutOfMemoryError" shows up. > > > > > > Best regards, Matthias > > > > > > From stefan.karlsson at oracle.com Fri Aug 16 08:20:40 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 16 Aug 2019 10:20:40 +0200 Subject: RFR: 8229258: Rework markOop and markOopDesc into a simpler mark word value carrier In-Reply-To: <00FC5053-D5B8-4DD8-96A3-95E12ED7C18C@oracle.com> References: <72567e47-3b52-8e30-ea6f-9a64fa043c07@redhat.com> <32ccb4ba-0500-2bf4-3761-63a6285f94dc@oracle.com> <5913EBBD-2A13-43A5-9F37-D36E97397365@oracle.com> <1670ce59-e7b5-0023-b1fd-f9f7c19a0eda@oracle.com> <00FC5053-D5B8-4DD8-96A3-95E12ED7C18C@oracle.com> Message-ID: <904604bc-a718-8d44-8e1c-629c8feae840@oracle.com> On 2019-08-16 00:59, Kim Barrett wrote: >> On Aug 15, 2019, at 7:46 AM, Stefan Karlsson wrote: >> >> Thanks Kim, Roman, Dan and Coleen for reviews and feedback. >> >> I rebased the patch, fixed more alignments, renamed the bug, and rerun the test through tier1-3. >> >> https://cr.openjdk.java.net/~stefank/8229258/webrev.valueMarkWord.03.delta/ >> https://cr.openjdk.java.net/~stefank/8229258/webrev.valueMarkWord.03/ >> >> Could I get reviews for this version? I'd also like to ask others to at least partially look at this: > > Here's my comments through webrev.valueMarkWord.03. > > Looks good. There are a couple of small fixes for which I don't need > a new webrev, which are listed first below. Then there are some > broader items which could be addressed in followup improvements. > > ------------------------------------------------------------------------------ > src/hotspot/share/oops/markOop.hpp > 109 template operator T(); > > My mistake in the earlier review comment. Function should be const > qualified, e.g. that should be > > template operator T() const; > I added this after one of our earlier discussions. However, I don't think we need it (const or not). We already get sensible compiler errors without this function when we try to cast markWords to something else: void* p0 = m; void* p1 = (void*)m; int i0 = m; int i1 = (int)m; error: cannot convert ?markWord? to ?void*? in initialization void* p0 = m; ^ error: invalid cast from type ?markWord? to type ?void*? void* p1 = (void*)m; ^ error: cannot convert ?markWord? to ?int? in initialization int i0 = m; ^ error: invalid cast from type ?markWord? to type ?int? int i1 = (int)m; The poisoned constructor seems to be unnecessary as well, now that we have simplified markWord. Without it, I get appropriate error messages when I try to create a markWord from a pointer: error: invalid conversion from ?void*? to ?uintptr_t? {aka ?long unsigned int?} [-fpermissive] markWord p((void*)0x111); ^~~~~~~~~~~~ note: initializing argument 1 of ?markWord::markWord(uintptr_t)? explicit markWord(uintptr_t value) : _value(value) { } I've removed both of these. > ------------------------------------------------------------------------------ > src/hotspot/share/runtime/biasedLocking.cpp > 695 prototype.bias_epoch() == mark.bias_epoch())) { > > I think one more leading space needs to be deleted to get proper > alignment here. Or reformat this long and complex if control > expression. > OK. I followed the pre-existing alignment, but I can change it anyway. > ------------------------------------------------------------------------------ > src/hotspot/share/runtime/vframe.cpp > 244 // FIXME: mark is set but not used below. > 245 // Either the comment or the code is broken. > > Is there a bug for this? > Created JDK-8229808. > ------------------------------------------------------------------------------ > > > The remainder seem like they could be followup improvements. > > ------------------------------------------------------------------------------ > src/hotspot/share/oops/markOop.hpp > 138 static const uintptr_t zero = 0; > > All occurrences of this are either > (1) markWord member initializater > (2) markWord variable initializer > (3) temporary markWord initializer > > There don't appear to be any bare uses otherwise. I think nicer is > > static markWord zero() { return markWord(0); } > > (For C++11: `static constexpr markWord zero = markWord(0);`) > > This seems like it could be a followup improvement. > I had the same thought and then backed away from it, but I can't remember why. This is a small enough change, so I've gone through the few occurrences and cleaned it up. I'll leave the rest of the comments below for follow-up RFEs. This is the last few cleanups: http://cr.openjdk.java.net/~stefank/8229258/webrev.valueMarkWord.04.delta/ http://cr.openjdk.java.net/~stefank/8229258/webrev.valueMarkWord.04/ I ran extended testing on .03 (tier1-7 on linux), checked the markWord functions were inlined, and checked that the generated code for G1ParScanThreadState::copy_to_survivor_space was the same before and after the patch. So I intend to run tier1 testing on .04 and then push this patch. Thanks, StefanK > ------------------------------------------------------------------------------ > > [This is also related to Coleen's comments about to_pointer.] > > Looking at the changes, in order to reduce the amount of casting pixie > dust sprinkled on our code base, I now think markWord::to_pointer > should have a template overload, with the template parameter > designating the return type. And I think the return type for the > non-template should be const qualified, and the template should handle > cv qualifiers. Like so (I think, I haven't actually tested this) > > const void* to_pointer() const { > return reinterpret_cast(_value); > } > > template > T* to_pointer() const { > typedef typename RemoveCV::type TT; > return reinterpret_cast(_value); > } > > If one wants a void* then use m.to_pointer(). > > (I almost want to call it "pointer_to" so it reads "pointer to T".) > > Coleen and I talked about a possible alternative to the template > overload. Perhaps there is a small and fixed number of pointer types > we want to support conversion to, in which case we could have a small > number of type-specific to_xxx_pointer variants? But I'm not sure the > number is actually small and fixed. > > This seems like it could be a followup improvement. > > ------------------------------------------------------------------------------ > src/hotspot/share/interpreter/bytecodeInterpreter.cpp > > In the run() function, there are a lot of casts of markWord::value() > results or constants from markWord that I think could be removed. > Some of them might want C++11 explicitly typed enums though. > > This seems like it could be a followup improvement. > > ------------------------------------------------------------------------------ > From adam.farley at uk.ibm.com Fri Aug 16 11:35:31 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Fri, 16 Aug 2019 12:35:31 +0100 Subject: RFR: JDK-8227021: VM fails if any sun.boot.library.path paths are longer than JVM_MAXPATHLEN In-Reply-To: References: <25234969-2215-57e9-d8c5-d97b5669ebb1@oracle.com> <5ba808b0-ae52-0d0a-b84b-fc34df35475d@oracle.com> <025da83a-6569-f6ac-7590-5b200ed2344f@oracle.com> <8e62fc61-b46b-0033-f182-cb4a2dbf92fd@oracle.com> Message-ID: Hi Coleen, To confirm your suspicions, I didn't see your responses. No offence intended. Responses below. Best Regards Adam Farley IBM Runtimes coleen.phillimore at oracle.com wrote on 15/08/2019 13:42:51: > From: coleen.phillimore at oracle.com > To: hotspot-dev at openjdk.java.net, Adam Farley8 > , David Holmes > Date: 15/08/2019 13:43 > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > paths are longer than JVM_MAXPATHLEN > > Hi Adam, David noticed that my code review replies only went to the > mailing list. So here it is again. > Thanks, > Coleen > > On 8/13/19 5:29 PM, coleen.phillimore at oracle.com wrote: > > > > > > On 8/13/19 11:48 AM, Adam Farley8 wrote: > >> Hi David, > >> > >> Since we have two positive reviews (yours and Serguei's), could you > >> sponsor the change please? > > > > If you get two positive reviews, but then one with comments, you need > > to also answer that third reviews. I had some comments on your > > change, which I'll repeat here: > > > > > > https://urldefense.proofpoint.com/v2/url? > u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021. > 2_webrev_src_hotspot_share_runtime_os.cpp.frames.html&d=DwIDaQ&c=jf_iaSHvJObTbx- > siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=wjd3KxxgFQv49yjlb4Bndy- > F1XV4pbuPZrmemiaFthA&s=xXwflqvuzoEhcREhr-x7rNMVDeroZ8Xh1LnW6NytumE&e= > > > > > > This is code is unnecessarily hard to read and understand: > > > > 1329 char** os::split_path(const char* path, size_t* n) { > > 1330 size_t pathmod = (size_t)0; > > 1331 if (n != NULL) { > > 1332 pathmod = *n; > > 1333 } > > 1334 *n = (size_t)0; > > > > It appears that 'n' is both an input and output parameter of this > > function. Can you just make it another input parameter with some > > descriptive name. Is it the length of the library name that you're > > looking for? "pathmod" is huh? The 'n' is both an input and an output, yes. I could make it another input parameter, but that means modifying the method signature. This seemed unnecessary, given that we have an input vector we're not using for anything. The 'n' input is used as a modifier for the length of the path, as mentioned in the comment. I called it "pathmod" because it's a PATH length MODIFIER. I couldn't think of a better name that's also concise. Would pathlenmod be better? Pathsizemod sounds like we're making the path physically bigger, or maybe that's just me. :) > > > > Then you don't have to check if someone has passed NULL. There's only > > one caller to this from what I see. I'm not sure I understand this. We'd still need to check for null, even if the pathmod has its own input parameter. I believe adding a NULL to an int causes a segmentation error at runtime. If you're saying the null check isn't needed because we can ensure a non-null is passed in via the only place we call split_path, I disagree that this is a future-proof assumption. A null check seems prudent here. > > > > 1352 char** opath = (char**) NEW_C_HEAP_ARRAY(char*, count, > > mtInternal); > > 1353 if (opath == NULL) { > > 1354 return NULL; > > 1355 } > > > > > > Not your change but this calls vm_exit_out_of_memory() if > > NEW_C_HEAP_ARRAY fails. It doesn't return NULL so you don't have to > > check. Seems legit. I'll include this in the .5 version once we have consensus on the other changes. Good spot. > > > > 1375 char* s = (char*)NEW_C_HEAP_ARRAY(char, len + 1, mtInternal); > > > > Here you want to use NEW_C_HEAP_ARRAY_RETURN_NULL so you can check for > > null and free memory. Good idea. Noted for .5. Let me know your thoughts on the other points above. > > > > > > The rest seems okay. > > > > thanks, > > Coleen > > > >> > >> Best Regards > >> > >> Adam Farley > >> IBM Runtimes > >> > >> > >> David Holmes wrote on 12/08/2019 23:32:14: > >> > >>> From: David Holmes > >>> To: Adam Farley8 > >>> Cc: hotspot-dev at openjdk.java.net, "serguei.spitsyn at oracle.com" > >>> > >>> Date: 12/08/2019 23:32 > >>> Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > >>> paths are longer than JVM_MAXPATHLEN > >>> > >>> Looks fine. > >>> > >>> Thanks, > >>> David > >>> > >>> On 13/08/2019 1:19 am, Adam Farley8 wrote: > >>>> Hi David, > >>>> > >>>> Changes made as requested: > >>>> https://urldefense.proofpoint.com/v2/url? > >>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.4_webrev&d=DwID- > >>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > >>> > >> > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=mZM8IR4e_zmrfcsF3XJjoGEMrZb4WtEL7Y6Ugd6Naqg&s=sZ2UKqqUIq0El- > >> > >>> RsqYz6jmTh4Q2UghwdrQX6of8Lw0E&e= > >>>> Best Regards > >>>> > >>>> Adam Farley > >>>> IBM Runtimes > >>>> > >>>> > >>>> David Holmes wrote on 12/08/2019 04:55:36: > >>>> > >>>>> From: David Holmes > >>>>> To: Adam Farley8 , > >>>>> "serguei.spitsyn at oracle.com" > >>>>> Cc: hotspot-dev at openjdk.java.net > >>>>> Date: 12/08/2019 04:56 > >>>>> Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > >>>>> paths are longer than JVM_MAXPATHLEN > >>>>> > >>>>> Hi Adam, > >>>>> > >>>>> On 10/08/2019 2:47 am, Adam Farley8 wrote: > >>>>>> Hi Serguei, David, > >>>>>> > >>>>>> My turn to apologise for the delay. :) > >>>>>> > >>>>>> I've modified the code as per Serguei's request. Take a look and > >> let me > >>>>>> know if this is the sort of thing you were thinking of. > >>>>>> > >>>>>> Webrev: https://urldefense.proofpoint.com/v2/url? > >>>>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.3_webrev_&d=DwID- > >>>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > >>>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > >>>>> > >> > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=L19aeFXoR9JIO62QRPFzZObIU8RbhpCtXSvUibD2ISk&e= > >> > >>>>> I'd prefer to see the helper just as a file static function rather > >> than > >>>>> adding it to the os class. > >>>>> > >>>>> + * supplied array of arrays of chars (a), where n > >>>>> > >>>>> I assume (a) is meant to refer to the parameter, but you actually > >> called > >>>>> it arrayarray. I think "a" or "arr" would suffice. > >>>>> > >>>>> Thanks, > >>>>> David > >>>>> > >>>>>> Best Regards > >>>>>> > >>>>>> Adam Farley > >>>>>> IBM Runtimes > >>>>>> > >>>>>> > >>>>>> "serguei.spitsyn at oracle.com" wrote on > >>>>>> 31/07/2019 17:18:05: > >>>>>> > >>>>>>> From: "serguei.spitsyn at oracle.com" > >>>>>>> To: Adam Farley8 , David Holmes > >>>>>>> > >>>>>>> Cc: serviceability-dev , > >>>>>>> hotspot-dev at openjdk.java.net > >>>>>>> Date: 31/07/2019 17:18 > >>>>>>> Subject: Re: RFR: JDK-8227021: VM fails if any > >> sun.boot.library.path > >>>>>>> paths are longer than JVM_MAXPATHLEN > >>>>>>> > >>>>>>> Hi Adam, > >>>>>>> > >>>>>>> It looks Okay to me. > >>>>>>> > >>>>>>> A couple of minor comments. > >>>>>>> > >>>>>>> https://urldefense.proofpoint.com/v2/url? > >>>>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021. > >>>>> 2_webrev_src_hotspot_&d=DwID-g&c=jf_iaSHvJObTbx- > >>>>> siA1ZOg&r=P5m8KWUXJf-CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > >>>>> > >> > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NL6tYuwwDod3DSmj-1ztxAywpO8L52HEyO0wvTR05bs&e= > >> > >>>>>>> share/runtime/os.cpp.frames.html > >>>>>>> 1362 //release allocated storage before exiting the vm > >>>>>>> 1363 while (i > 0) { > >>>>>>> 1364 i--; > >>>>>>> 1365 if (opath[i] != NULL) { > >>>>>>> 1366 FREE_C_HEAP_ARRAY(char, opath[i]); > >>>>>>> 1367 } > >>>>>>> 1368 } > >>>>>>> 1369 FREE_C_HEAP_ARRAY(char*, opath); > >>>>>>> > >>>>>>> 1377 //release allocated storage before returning null > >>>>>>> 1378 while (i > 0) { > >>>>>>> 1379 i--; > >>>>>>> 1380 if (opath[i] != NULL) { > >>>>>>> 1381 FREE_C_HEAP_ARRAY(char, opath[i]); > >>>>>>> 1382 } > >>>>>>> 1383 } > >>>>>>> 1384 FREE_C_HEAP_ARRAY(char*, opath); > >>>>>>> > >>>>>>> This duplicated fragments is worth to refactor to a function. > >>>>>>> Also a space is missed at the beginning of the comment. > >>>>>>> > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Serguei > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On 7/31/19 02:01, Adam Farley8 wrote: > >>>>>>> Hi All, > >>>>>>> > >>>>>>> Reviewers requested for the change below. > >>>>>>> > >>>>>>> @David - Agreed. Would you be prepared to sponsor the change? > >>>>>>> > >>>>>>> Bug: https://urldefense.proofpoint.com/v2/url? > >>>>> u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8227021&d=DwID- > >>>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > >>>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > >>>>> > >> > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=xykJ0KLy9AKWO8zmC0amfR7xxUsvyKEjlf3y7WWOqvE&e= > >> > >>>>>>> Webrev: https://urldefense.proofpoint.com/v2/url? > >>>>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.2_webrev_&d=DwID- > >>>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > >>>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > >>>>> > >> > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NvIza4VVWG3CiDhmQVmXsghH_4h_c5mFJbHwkCUcut0&e= > >> > >>>>>>> Best Regards > >>>>>>> > >>>>>>> Adam Farley > >>>>>>> IBM Runtimes > >>>>>>> > >>>>>>> P.S. Remembered to add the links this time. :) > >>>>>>> > >>>>>>> > >>>>>>> David Holmes wrote on 30/07/2019 > >> 03:37:53: > >>>>>>>> From: David Holmes > >>>>>>>> To: Adam Farley8 > >>>>>>>> Cc: hotspot-dev at openjdk.java.net, serviceability-dev > >>>>>>>> > >>>>>>>> Date: 30/07/2019 03:38 > >>>>>>>> Subject: Re: RFR: JDK-8227021: VM fails if any > >> sun.boot.library.path > >>>>>>>> paths are longer than JVM_MAXPATHLEN > >>>>>>>> > >>>>>>>> Hi Adam, > >>>>>>>> > >>>>>>>> On 25/07/2019 3:57 am, Adam Farley8 wrote: > >>>>>>>>> Hi David, > >>>>>>>>> > >>>>>>>>> Welcome back. :) > >>>>>>>> Thanks. Sorry for the delay in getting back to this. > >>>>>>>> > >>>>>>>> I like .v2 as it is much simpler (notwithstanding freeing > >>> the already > >>>>>>>> allocated arrays adds some complexity - thanks for fixing that). > >>>>>>>> > >>>>>>>> I'm still not sure we can't optimise things better for > >> unchangeable > >>>>>>>> properties like the boot libary path, but that's another RFE. > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> David > >>>>>>>> > >>>>>>> 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 > >> 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 bob.vandette at oracle.com Fri Aug 16 12:36:24 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Fri, 16 Aug 2019 08:36:24 -0400 Subject: RFR [XS] : 8229182: runtime/containers/docker/TestMemoryAwareness.java test fails on SLES12 In-Reply-To: References: <6563ed4bd315281320e11755597fec24f4092ded.camel@redhat.com> <0924470c2bac638fa1feab7d63ee71a57904e408.camel@redhat.com> <9187885973675ab53221ad3140e79e0115e509a2.camel@redhat.com> Message-ID: <1F1258AE-747D-4024-945A-6380ECC5EB9A@oracle.com> Instead of adding this: opts.appendTestJavaOptions = false; Try adding these lines: String javaHeapSize = new String(sizeToAllocInMb/2) + ?m?; opts.addJavaOpts("-Xmx" + javaHeapSize); This will set the max Java Heap to 1/2 of the size that we will attempt to allocate. This should reliably cause an OOM exception. Bob. > On Aug 16, 2019, at 4:14 AM, Baesken, Matthias wrote: > >> Can we not set -Xmx explicitly after any test options have been >> appended so that it takes precedence? > > Hi Bob, do you have a good estimate for an Xmx to set ? > >> It seems fragile to disable >> appinding all test options altogether. Clearly, this test is >> susceptible to passed -Xmx options. > > We have here a java - execution taking place in the docker container, not the test machine itself . > I am not sure , are the "regular" test options so good for this special execution ? Some maybe are , some aren?t ... > > E.g. we ended up with > > -Xmx768m -Djava.awt.headless=true > > and more strange settings in the "docker run" call because of this ... > > Best regards, Matthias > > > >> Hi Matthias, >> >> On Fri, 2019-08-16 at 06:10 +0000, Baesken, Matthias wrote: >>>> Unfortunately we do not see the expected >> "java.lang.OutOfMemoryError" >>>> in the nightly test runs . >>>> >>>> When I execute the jtreg test locally on the same (!) ppc64le machine , >>>> under the same user but not from the test framework we use nightly >>>> the "java.lang.OutOfMemoryError" shows up. >>> >>> Hello, after looking a bit more into it, we observed that the nightly runs >> set a higher -Xmx = 768m value that gets inherited into the >> DockerRunOptions >>> And made the central test fail . >>> So I had to remove this : >>> >>> 105 // make sure we avoid Xmx settings from the jtreg vmoptions >>> 106 opts.appendTestJavaOptions = false; >> >> Can we not set -Xmx explicitly after any test options have been >> appended so that it takes precedence? It seems fragile to disable >> appinding all test options altogether. Clearly, this test is >> susceptible to passed -Xmx options. >> >> Failing that, could we just omit the -Xmx option? >> >> Thanks, >> Severin >> >>> New webrev : >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8229182.2/ >>> >>> Best regards, Matthias >>> >>> >>>> Hi Christoph, >>>> >>>>> Hi Matthias, >>>>> >>>>> looks good to me in general. >>>>> >>>>> However, I'm not convinced that line 114 >>>>> ".shouldContain("java.lang.OutOfMemoryError");" won't provoke a >> test >>>>> error in case the child process was killed by the container, e.g. exited >> with >>>>> exit code 137. We should at least run this patch for several days in our >>>> system >>>>> to see if it catches all variations of the problem. >>>>> >>>> >>>> Unfortunately we do not see the expected >> "java.lang.OutOfMemoryError" >>>> in the nightly test runs . >>>> >>>> When I execute the jtreg test locally on the same (!) ppc64le machine , >>>> under the same user but not from the test framework we use nightly >>>> the "java.lang.OutOfMemoryError" shows up. >>>> >>>> Best regards, Matthias >>>> >>>> > From boris.ulasevich at bell-sw.com Fri Aug 16 14:28:48 2019 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Fri, 16 Aug 2019 17:28:48 +0300 Subject: RFR: 8229352: Use of an unitialized register in 32-bit ARM template interpreter In-Reply-To: <20190813062935.5296F308C5B@aojmv0009> References: <20190716100738.EFA3E2E2022@aojmv0009> <20190811065555.2A0A13074FB@aojmv0009> <687d97ce-be7c-3598-3071-6070fa68d5d0@redhat.com> <20190813062935.5296F308C5B@aojmv0009> Message-ID: <80dedbe5-3627-c0a7-d33f-d7a89f386ae6@bell-sw.com> Hi Dean, I checked the patch is Ok on arm-hflt. If you think it is good to go I will be happy to commit the patch. regards, Boris On 13.08.2019 9:27, christoph.goettschkes at microdoc.com wrote: > Thanks for your feedback. > > Here is a new webrev with the proposed change applied: > http://cr.openjdk.java.net/~bulasevich/8229352/webrev.01/ > I tested the new changes with a subset of the hotspot tier1 JTreg test > group. > > Does this look fine to you? > > -- Christoph > > "hotspot-dev" wrote on 2019-08-12 > 20:53:46: > >> From: Aleksey Shipilev >> To: dean.long at oracle.com, hotspot-dev at openjdk.java.net >> Date: 2019-08-12 20:54 >> Subject: Re: RFR: 8229352: Use of an unitialized register in 32-bit ARM >> template interpreter >> Sent by: "hotspot-dev" >> >> On 8/12/19 8:37 PM, dean.long at oracle.com wrote: >>> Looks OK, but after the Condy change, the label "Long" might be better > named >> "NotDouble". >> >> +1 >> >>> On 8/10/19 11:54 PM, christoph.goettschkes at microdoc.com wrote: >>>> Hello, >>>> >>>> could someone please review the changes for >>>> https://bugs.openjdk.java.net/browse/JDK-8229352 >>>> >>>> webrev: http://cr.openjdk.java.net/~bulasevich/8229352/webrev.00/ >> >> Looks good to me. >> >> Note: changed the typo in "uninitialized" in issue synopsis, please make > sure >> changeset metadata >> reflects that. >> >> -- >> Thanks, >> -Aleksey >> > From boris.ulasevich at bell-sw.com Fri Aug 16 14:40:26 2019 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Fri, 16 Aug 2019 17:40:26 +0300 Subject: RFR(S): 8229254: solaris_x64 build fails In-Reply-To: <28049dbf-b2cd-3ef9-d58e-a66cb50eeedb@bell-sw.com> References: <9a371ec1-e125-4945-521b-90bb2b4c6984@bell-sw.com> <28049dbf-b2cd-3ef9-d58e-a66cb50eeedb@bell-sw.com> Message-ID: Hi David, Do you think the change is Ok or should I rework it somehow? thanks, Boris On 12.08.2019 11:53, Boris Ulasevich wrote: > Hi David, > > On 12.08.2019 5:47, David Holmes wrote: >> Hi Boris, >> >> On 9/08/2019 11:14 pm, Boris Ulasevich wrote: >>> Hi, >>> >>> Please review the following simple change to make solaris_x64 build >>> compilable. >>> >>> Syntax error was brought by JDK-8191278 [1]. The fix is evident. >> >> Yes looks good. >> >>> Missing constant issue occurred after JDK-8226238 [2]. I copied >>> workaround for the case of missing EM_AARCH64 constant in system >>> elf.h header from os_linux.cpp implementation. >> >> I'm really not sure why we keep expanding a Solaris specific structure >> with entries for architectures the OS does not run on ... > > Yes. I had the same concern. The first impulse was to remove the AARCH64 > data line or to surround it #ifdef AARCH directive. > > The sense of this line on os_solaris.cpp implementation might be a good > question on JDK-8226238 review. I think the answer is that it makes no > overhead, and potentially improves .so library compatibility error message. > >> That aside the fix seems fine - the value is somewhat arbitrary but >> doesn't conflict with anything AFAICS. > > My explanation was not quite intelligible, sorry. As Kim have already > answered, this is as constant that should normally come from elf.h > header. But as Solaris system header elf.h does not have that, this is > just a workaround for the system header on build machine, very similar > to that in os_linux.cpp implementation. > >> Thanks, >> David >> ----- >> >>> http://cr.openjdk.java.net/~bulasevich/8229254/webrev.00 >>> http://bugs.openjdk.java.net/browse/JDK-8229254 >>> >>> Testing done: tier1,tier2. >>> >>> thanks, >>> Boris >>> >>> [1] MappedByteBuffer bulk access memory failures are not handled >>> gracefully >>> >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2019-June/038352.html >>> [2] Improve error output and fix elf issues in os::dll_load >>> >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2019-June/038597.html From kim.barrett at oracle.com Fri Aug 16 18:33:54 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 16 Aug 2019 14:33:54 -0400 Subject: RFR: 8229258: Rework markOop and markOopDesc into a simpler mark word value carrier In-Reply-To: <904604bc-a718-8d44-8e1c-629c8feae840@oracle.com> References: <72567e47-3b52-8e30-ea6f-9a64fa043c07@redhat.com> <32ccb4ba-0500-2bf4-3761-63a6285f94dc@oracle.com> <5913EBBD-2A13-43A5-9F37-D36E97397365@oracle.com> <1670ce59-e7b5-0023-b1fd-f9f7c19a0eda@oracle.com> <00FC5053-D5B8-4DD8-96A3-95E12ED7C18C@oracle.com> <904604bc-a718-8d44-8e1c-629c8feae840@oracle.com> Message-ID: <5C08780B-5DB3-4E6E-A4A4-3257BF90E39B@oracle.com> > On Aug 16, 2019, at 4:20 AM, Stefan Karlsson wrote: > > On 2019-08-16 00:59, Kim Barrett wrote: >> src/hotspot/share/oops/markOop.hpp >> 109 template operator T(); >> My mistake in the earlier review comment. Function should be const >> qualified, e.g. that should be >> template operator T() const; > > I added this after one of our earlier discussions. However, I don't think we need it (const or not). We already get sensible compiler errors without this function when we try to cast markWords to something else: > > void* p0 = m; > void* p1 = (void*)m; > int i0 = m; > int i1 = (int)m; > > [? various errors ?] You?re right. It seems I need to refresh my recollection of what the valid conversions are. > The poisoned constructor seems to be unnecessary as well, now that we have simplified markWord. Without it, I get appropriate error messages when I try to create a markWord from a pointer: > > error: invalid conversion from ?void*? to ?uintptr_t? {aka ?long unsigned int?} [-fpermissive] > markWord p((void*)0x111); > ^~~~~~~~~~~~ > note: initializing argument 1 of ?markWord::markWord(uintptr_t)? > explicit markWord(uintptr_t value) : _value(value) { } I no longer recall why that one was even suggested. But you are right that it isn?t needed. > I've removed both of these. Good. > [?] > > I'll leave the rest of the comments below for follow-up RFEs. OK. > This is the last few cleanups: > http://cr.openjdk.java.net/~stefank/8229258/webrev.valueMarkWord.04.delta/ > http://cr.openjdk.java.net/~stefank/8229258/webrev.valueMarkWord.04/ Looks good. > I ran extended testing on .03 (tier1-7 on linux), checked the markWord functions were inlined, and checked that the generated code for G1ParScanThreadState::copy_to_survivor_space was the same before and after the patch. So I intend to run tier1 testing on .04 and then push this patch. > Thanks for checking the generated code. It?s what we expected, but compilers are sometimes surprising. From dean.long at oracle.com Fri Aug 16 19:16:29 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 16 Aug 2019 12:16:29 -0700 Subject: RFR: 8229352: Use of an unitialized register in 32-bit ARM template interpreter In-Reply-To: <80dedbe5-3627-c0a7-d33f-d7a89f386ae6@bell-sw.com> References: <20190716100738.EFA3E2E2022@aojmv0009> <20190811065555.2A0A13074FB@aojmv0009> <687d97ce-be7c-3598-3071-6070fa68d5d0@redhat.com> <20190813062935.5296F308C5B@aojmv0009> <80dedbe5-3627-c0a7-d33f-d7a89f386ae6@bell-sw.com> Message-ID: <338e4dc9-4d28-774b-fc8e-f4ffc96e1ca6@oracle.com> Yes, you're good to go. dl On 8/16/19 7:28 AM, Boris Ulasevich wrote: > Hi Dean, > > I checked the patch is Ok on arm-hflt. If you think it is good to go I > will be happy to commit the patch. > > regards, > Boris > > On 13.08.2019 9:27, christoph.goettschkes at microdoc.com wrote: >> Thanks for your feedback. >> >> Here is a new webrev with the proposed change applied: >> http://cr.openjdk.java.net/~bulasevich/8229352/webrev.01/ >> I tested the new changes with a subset of the hotspot tier1 JTreg test >> group. >> >> Does this look fine to you? >> >> -- Christoph >> >> "hotspot-dev" wrote on 2019-08-12 >> 20:53:46: >> >>> From: Aleksey Shipilev >>> To: dean.long at oracle.com, hotspot-dev at openjdk.java.net >>> Date: 2019-08-12 20:54 >>> Subject: Re: RFR: 8229352: Use of an unitialized register in 32-bit ARM >>> template interpreter >>> Sent by: "hotspot-dev" >>> >>> On 8/12/19 8:37 PM, dean.long at oracle.com wrote: >>>> Looks OK, but after the Condy change, the label "Long" might be better >> named >>> "NotDouble". >>> >>> +1 >>> >>>> On 8/10/19 11:54 PM, christoph.goettschkes at microdoc.com wrote: >>>>> Hello, >>>>> >>>>> could someone please review the changes for >>>>> https://bugs.openjdk.java.net/browse/JDK-8229352 >>>>> >>>>> webrev: http://cr.openjdk.java.net/~bulasevich/8229352/webrev.00/ >>> >>> Looks good to me. >>> >>> Note: changed the typo in "uninitialized" in issue synopsis, please >>> make >> sure >>> changeset metadata >>> reflects that. >>> >>> -- >>> Thanks, >>> -Aleksey >>> >> From david.holmes at oracle.com Fri Aug 16 22:37:44 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 17 Aug 2019 08:37:44 +1000 Subject: RFR(S): 8229254: solaris_x64 build fails In-Reply-To: References: <9a371ec1-e125-4945-521b-90bb2b4c6984@bell-sw.com> <28049dbf-b2cd-3ef9-d58e-a66cb50eeedb@bell-sw.com> Message-ID: <776ab871-c23b-7844-9a3d-81ea22e53008@oracle.com> Hi Boris, On 17/08/2019 12:40 am, Boris Ulasevich wrote: > Hi David, > > ? Do you think the change is Ok or should I rework it somehow? The change is fine. Thanks, David > thanks, > Boris > > On 12.08.2019 11:53, Boris Ulasevich wrote: >> Hi David, >> >> On 12.08.2019 5:47, David Holmes wrote: >>> Hi Boris, >>> >>> On 9/08/2019 11:14 pm, Boris Ulasevich wrote: >>>> Hi, >>>> >>>> Please review the following simple change to make solaris_x64 build >>>> compilable. >>>> >>>> Syntax error was brought by JDK-8191278 [1]. The fix is evident. >>> >>> Yes looks good. >>> >>>> Missing constant issue occurred after JDK-8226238 [2]. I copied >>>> workaround for the case of missing EM_AARCH64 constant in system >>>> elf.h header from os_linux.cpp implementation. >>> >>> I'm really not sure why we keep expanding a Solaris specific >>> structure with entries for architectures the OS does not run on ... >> >> Yes. I had the same concern. The first impulse was to remove the >> AARCH64 data line or to surround it #ifdef AARCH directive. >> >> The sense of this line on os_solaris.cpp implementation might be a >> good question on JDK-8226238 review. I think the answer is that it >> makes no overhead, and potentially improves .so library compatibility >> error message. >> >>> That aside the fix seems fine - the value is somewhat arbitrary but >>> doesn't conflict with anything AFAICS. >> >> My explanation was not quite intelligible, sorry. As Kim have already >> answered, this is as constant that should normally come from elf.h >> header. But as Solaris system header elf.h does not have that, this is >> just a workaround for the system header on build machine, very similar >> to that in os_linux.cpp implementation. >> >>> Thanks, >>> David >>> ----- >>> >>>> http://cr.openjdk.java.net/~bulasevich/8229254/webrev.00 >>>> http://bugs.openjdk.java.net/browse/JDK-8229254 >>>> >>>> Testing done: tier1,tier2. >>>> >>>> thanks, >>>> Boris >>>> >>>> [1] MappedByteBuffer bulk access memory failures are not handled >>>> gracefully >>>> >>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2019-June/038352.html >>>> >>>> [2] Improve error output and fix elf issues in os::dll_load >>>> >>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2019-June/038597.html >>>> From coleen.phillimore at oracle.com Fri Aug 16 22:59:53 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 16 Aug 2019 18:59:53 -0400 Subject: RFR: JDK-8227021: VM fails if any sun.boot.library.path paths are longer than JVM_MAXPATHLEN In-Reply-To: References: <25234969-2215-57e9-d8c5-d97b5669ebb1@oracle.com> <5ba808b0-ae52-0d0a-b84b-fc34df35475d@oracle.com> <025da83a-6569-f6ac-7590-5b200ed2344f@oracle.com> <8e62fc61-b46b-0033-f182-cb4a2dbf92fd@oracle.com> Message-ID: <4f892f24-4919-4f3a-7e62-0603e08561cc@oracle.com> On 8/16/19 7:35 AM, Adam Farley8 wrote: > Hi Coleen, > > To confirm your suspicions, I didn't see your responses. No offence > intended. I send a lot of mail so I'm sure I can be caught in people's spam filter. :) > > > Responses below. > > Best Regards > > Adam Farley > IBM Runtimes > > > coleen.phillimore at oracle.com wrote on 15/08/2019 13:42:51: > > > From: coleen.phillimore at oracle.com > > To: hotspot-dev at openjdk.java.net, Adam Farley8 > > , David Holmes > > Date: 15/08/2019 13:43 > > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > > paths are longer than JVM_MAXPATHLEN > > > > Hi Adam,? David noticed that my code review replies only went to the > > mailing list.? So here it is again. > > Thanks, > > Coleen > > > > On 8/13/19 5:29 PM, coleen.phillimore at oracle.com wrote: > > > > > > > > > On 8/13/19 11:48 AM, Adam Farley8 wrote: > > >> Hi David, > > >> > > >> Since we have two positive reviews (yours and Serguei's), could you > > >> sponsor the change please? > > > > > > If you get two positive reviews, but then one with comments, you need > > > to also answer that third reviews.? I had some comments on your > > > change, which I'll repeat here: > > > > > > > > > https://urldefense.proofpoint.com/v2/url? > > u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021. > > > 2_webrev_src_hotspot_share_runtime_os.cpp.frames.html&d=DwIDaQ&c=jf_iaSHvJObTbx- > > siA1ZOg&r=P5m8KWUXJf- > > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=wjd3KxxgFQv49yjlb4Bndy- > > F1XV4pbuPZrmemiaFthA&s=xXwflqvuzoEhcREhr-x7rNMVDeroZ8Xh1LnW6NytumE&e= > > > > > > > > > This is code is unnecessarily hard to read and understand: > > > > > > 1329 char** os::split_path(const char* path, size_t* n) { > > > 1330 size_t pathmod = (size_t)0; > > > 1331 if (n != NULL) { > > > 1332 pathmod = *n; > > > 1333 } > > > 1334 *n = (size_t)0; > > > > > > It appears that 'n' is both an input and output parameter of this > > > function.? Can you just make it another input parameter with some > > > descriptive name.? Is it the length of the library name that you're > > > looking for?? "pathmod" is huh? > > The 'n' is both an input and an output, yes. > > I could make it another input parameter, but that means modifying the > method signature. This seemed unnecessary, given that we have an input > vector we're not using for anything. It's not a big deal to add a parameter, especially since there's only one call site, and the names don't have to be squished up C names. How about:? char** split_path(char* path, size_t file_length, size_t* elements) ? > > > The 'n' input is used as a modifier for the length of the path, as > mentioned in the comment. I called it "pathmod" because it's a PATH > length MODIFIER. I couldn't think of a better name that's also concise. > Would pathlenmod be better? Pathsizemod sounds like we're making the path > physically bigger, or maybe that's just me. :) > > > > > > > Then you don't have to check if someone has passed NULL. There's only > > > one caller to this from what I see. > > I'm not sure I understand this. We'd still need to check for null, > even if > the pathmod has its own input parameter. I believe adding a NULL to an > int > causes a segmentation error at runtime. > > If you're saying the null check isn't needed because we can ensure a > non-null > is passed in via the only place we call split_path, I disagree that > this is a > future-proof assumption. A null check seems prudent here. I think the function doesn't make any sense if you pass an output parameter as NULL.? Or at worst you could add it to the line: 1335 if (path == NULL || strlen(path) == 0 || n == NULL) { 1336 ? ?? return NULL; 1337 } 1334 *n = (size_t)0; But that's just weird. Why would a caller pass a non-null path and not want the element count? Thanks, Coleen > > > > > > > > 1352?? char** opath = (char**) NEW_C_HEAP_ARRAY(char*, count, > > > mtInternal); > > > 1353?? if (opath == NULL) { > > > 1354???? return NULL; > > > 1355?? } > > > > > > > > > Not your change but this calls vm_exit_out_of_memory() if > > > NEW_C_HEAP_ARRAY fails.? It doesn't return NULL so you don't have to > > > check. > > Seems legit. I'll include this in the .5 version once we have > consensus on > the other changes. Good spot. > > > > > > > 1375???? char* s? = (char*)NEW_C_HEAP_ARRAY(char, len + 1, > mtInternal); > > > > > > Here you want to use NEW_C_HEAP_ARRAY_RETURN_NULL so you can check > for > > > null and free memory. > > Good idea. Noted for .5. > > Let me know your thoughts on the other points above. > > > > > > > > > > > The rest seems okay. > > > > > > thanks, > > > Coleen > > > > > >> > > >> Best Regards > > >> > > >> Adam Farley > > >> IBM Runtimes > > >> > > >> > > >> David Holmes wrote on 12/08/2019 23:32:14: > > >> > > >>> From: David Holmes > > >>> To: Adam Farley8 > > >>> Cc: hotspot-dev at openjdk.java.net, "serguei.spitsyn at oracle.com" > > >>> > > >>> Date: 12/08/2019 23:32 > > >>> Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > > >>> paths are longer than JVM_MAXPATHLEN > > >>> > > >>> Looks fine. > > >>> > > >>> Thanks, > > >>> David > > >>> > > >>> On 13/08/2019 1:19 am, Adam Farley8 wrote: > > >>>> Hi David, > > >>>> > > >>>> Changes made as requested: > > >>>> https://urldefense.proofpoint.com/v2/url? > > >>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.4_webrev&d=DwID- > > >>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > >>> > > >> > > > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=mZM8IR4e_zmrfcsF3XJjoGEMrZb4WtEL7Y6Ugd6Naqg&s=sZ2UKqqUIq0El- > > >> > > >>> RsqYz6jmTh4Q2UghwdrQX6of8Lw0E&e= > > >>>> Best Regards > > >>>> > > >>>> Adam Farley > > >>>> IBM Runtimes > > >>>> > > >>>> > > >>>> David Holmes wrote on 12/08/2019 > 04:55:36: > > >>>> > > >>>>> From: David Holmes > > >>>>> To: Adam Farley8 , > > >>>>> "serguei.spitsyn at oracle.com" > > >>>>> Cc: hotspot-dev at openjdk.java.net > > >>>>> Date: 12/08/2019 04:56 > > >>>>> Subject: Re: RFR: JDK-8227021:? VM fails if any > sun.boot.library.path > > >>>>> paths are longer than JVM_MAXPATHLEN > > >>>>> > > >>>>> Hi Adam, > > >>>>> > > >>>>> On 10/08/2019 2:47 am, Adam Farley8 wrote: > > >>>>>> Hi Serguei, David, > > >>>>>> > > >>>>>> My turn to apologise for the delay. :) > > >>>>>> > > >>>>>> I've modified the code as per Serguei's request. Take a look? and > > >> let me > > >>>>>> know if this is the sort of thing you were thinking of. > > >>>>>> > > >>>>>> Webrev: https://urldefense.proofpoint.com/v2/url? > > >>>>> > u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.3_webrev_&d=DwID- > > >>>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > >>>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > > >>>>> > > >> > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=L19aeFXoR9JIO62QRPFzZObIU8RbhpCtXSvUibD2ISk&e= > > >> > > >>>>> I'd prefer to see the helper just as a file static function rather > > >> than > > >>>>> adding it to the os class. > > >>>>> > > >>>>> +? * supplied array of arrays of chars (a), where n > > >>>>> > > >>>>> I assume (a) is meant to refer to the parameter, but you actually > > >> called > > >>>>> it arrayarray. I think "a" or "arr" would suffice. > > >>>>> > > >>>>> Thanks, > > >>>>> David > > >>>>> > > >>>>>> Best Regards > > >>>>>> > > >>>>>> Adam Farley > > >>>>>> IBM Runtimes > > >>>>>> > > >>>>>> > > >>>>>> "serguei.spitsyn at oracle.com" > wrote on > > >>>>>> 31/07/2019 17:18:05: > > >>>>>> > > >>>>>>> From: "serguei.spitsyn at oracle.com" > > >>>>>>> To: Adam Farley8 , David? Holmes > > >>>>>>> > > >>>>>>> Cc: serviceability-dev , > > >>>>>>> hotspot-dev at openjdk.java.net > > >>>>>>> Date: 31/07/2019 17:18 > > >>>>>>> Subject: Re: RFR: JDK-8227021: VM fails if any > > >> sun.boot.library.path > > >>>>>>> paths are longer than JVM_MAXPATHLEN > > >>>>>>> > > >>>>>>> Hi Adam, > > >>>>>>> > > >>>>>>> It looks Okay to me. > > >>>>>>> > > >>>>>>> A couple of minor comments. > > >>>>>>> > > >>>>>>> https://urldefense.proofpoint.com/v2/url? > > >>>>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021. > > >>>>> 2_webrev_src_hotspot_&d=DwID-g&c=jf_iaSHvJObTbx- > > >>>>> > siA1ZOg&r=P5m8KWUXJf-CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > > >>>>> > > >> > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NL6tYuwwDod3DSmj-1ztxAywpO8L52HEyO0wvTR05bs&e= > > >> > > >>>>>>> share/runtime/os.cpp.frames.html > > >>>>>>> 1362 //release? allocated storage? before exiting the vm > > >>>>>>> 1363 while (i > 0) { > > >>>>>>> 1364 i--; > > >>>>>>> 1365 if (opath[i] != NULL)? { > > >>>>>>> 1366 FREE_C_HEAP_ARRAY(char,?? opath[i]); > > >>>>>>> 1367 } > > >>>>>>> 1368 } > > >>>>>>> 1369 FREE_C_HEAP_ARRAY(char*, opath); > > >>>>>>> > > >>>>>>> 1377 //release allocated storage before returning? null > > >>>>>>> 1378 while (i > 0) { > > >>>>>>> 1379 i--; > > >>>>>>> 1380 if (opath[i] != NULL)? { > > >>>>>>> 1381 FREE_C_HEAP_ARRAY(char,?? opath[i]); > > >>>>>>> 1382 } > > >>>>>>> 1383 } > > >>>>>>> 1384 FREE_C_HEAP_ARRAY(char*, opath); > > >>>>>>> > > >>>>>>> This duplicated fragments is worth to refactor to a function. > > >>>>>>> Also a space is missed at the beginning of the comment. > > >>>>>>> > > >>>>>>> > > >>>>>>> Thanks, > > >>>>>>> Serguei > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> On 7/31/19 02:01, Adam Farley8 wrote: > > >>>>>>> Hi All, > > >>>>>>> > > >>>>>>> Reviewers requested for the change below. > > >>>>>>> > > >>>>>>> @David - Agreed. Would you be prepared to sponsor the change? > > >>>>>>> > > >>>>>>> Bug: https://urldefense.proofpoint.com/v2/url? > > >>>>> u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8227021&d=DwID- > > >>>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > >>>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > > >>>>> > > >> > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=xykJ0KLy9AKWO8zmC0amfR7xxUsvyKEjlf3y7WWOqvE&e= > > >> > > >>>>>>> Webrev: https://urldefense.proofpoint.com/v2/url? > > >>>>> > u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.2_webrev_&d=DwID- > > >>>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > >>>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > > >>>>> > > >> > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NvIza4VVWG3CiDhmQVmXsghH_4h_c5mFJbHwkCUcut0&e= > > >> > > >>>>>>> Best Regards > > >>>>>>> > > >>>>>>> Adam Farley > > >>>>>>> IBM Runtimes > > >>>>>>> > > >>>>>>> P.S. Remembered to add the links this time. :) > > >>>>>>> > > >>>>>>> > > >>>>>>> David Holmes wrote on 30/07/2019 > > >> 03:37:53: > > >>>>>>>> From: David Holmes > > >>>>>>>> To: Adam Farley8 > > >>>>>>>> Cc: hotspot-dev at openjdk.java.net, serviceability-dev > > >>>>>>>> > > >>>>>>>> Date: 30/07/2019 03:38 > > >>>>>>>> Subject: Re: RFR: JDK-8227021: VM fails if any > > >> sun.boot.library.path > > >>>>>>>> paths are longer than JVM_MAXPATHLEN > > >>>>>>>> > > >>>>>>>> Hi Adam, > > >>>>>>>> > > >>>>>>>> On 25/07/2019 3:57 am, Adam Farley8 wrote: > > >>>>>>>>> Hi David, > > >>>>>>>>> > > >>>>>>>>> Welcome back. :) > > >>>>>>>> Thanks. Sorry for the delay in getting back to this. > > >>>>>>>> > > >>>>>>>> I like .v2 as it is much simpler (notwithstanding freeing > > >>> the? already > > >>>>>>>> allocated arrays adds some complexity - thanks for fixing > that). > > >>>>>>>> > > >>>>>>>> I'm still not sure we can't optimise things better for > > >> unchangeable > > >>>>>>>> properties like the boot libary path, but that's another? RFE. > > >>>>>>>> > > >>>>>>>> Thanks, > > >>>>>>>> David > > >>>>>>>> > > >>>>>>> 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 > > >> 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 stefan.karlsson at oracle.com Mon Aug 19 09:42:11 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 19 Aug 2019 11:42:11 +0200 Subject: RFR: 8229838: Rename markOop files to markWord Message-ID: Hi all, Please review this patch to rename the markOop files to markWord. http://cr.openjdk.java.net/~stefank/8229838/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8229838 JDK-8229258 reworked and renamed the markOopDesc class and markOop typedef, but the rename of the files were deferred. This patch renames the files to match the new name. Thanks, StefanK From david.holmes at oracle.com Mon Aug 19 11:15:34 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 19 Aug 2019 21:15:34 +1000 Subject: RFR: 8229838: Rename markOop files to markWord In-Reply-To: References: Message-ID: Looks good! Thanks, David On 19/08/2019 7:42 pm, Stefan Karlsson wrote: > Hi all, > > Please review this patch to rename the markOop files to markWord. > > http://cr.openjdk.java.net/~stefank/8229838/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8229838 > > JDK-8229258 reworked and renamed the markOopDesc class and markOop > typedef, but the rename of the files were deferred. This patch renames > the files to match the new name. > > Thanks, > StefanK From stefan.karlsson at oracle.com Mon Aug 19 11:28:40 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 19 Aug 2019 13:28:40 +0200 Subject: RFR: 8229838: Rename markOop files to markWord In-Reply-To: References: Message-ID: Thanks, David! StefanK On 2019-08-19 13:15, David Holmes wrote: > Looks good! > > Thanks, > David > > On 19/08/2019 7:42 pm, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch to rename the markOop files to markWord. >> >> http://cr.openjdk.java.net/~stefank/8229838/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8229838 >> >> JDK-8229258 reworked and renamed the markOopDesc class and markOop >> typedef, but the rename of the files were deferred. This patch renames >> the files to match the new name. >> >> Thanks, >> StefanK From robbin.ehn at oracle.com Mon Aug 19 11:30:56 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Mon, 19 Aug 2019 13:30:56 +0200 Subject: RFR: 8229838: Rename markOop files to markWord In-Reply-To: References: Message-ID: <65501543-6793-af2a-52eb-ef84ce0df759@oracle.com> Looks good, thanks! /Robbin On 2019-08-19 11:42, Stefan Karlsson wrote: > Hi all, > > Please review this patch to rename the markOop files to markWord. > > http://cr.openjdk.java.net/~stefank/8229838/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8229838 > > JDK-8229258 reworked and renamed the markOopDesc class and markOop typedef, but > the rename of the files were deferred. This patch renames the files to match the > new name. > > Thanks, > StefanK From stefan.karlsson at oracle.com Mon Aug 19 11:31:18 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 19 Aug 2019 13:31:18 +0200 Subject: RFR: 8229838: Rename markOop files to markWord In-Reply-To: <65501543-6793-af2a-52eb-ef84ce0df759@oracle.com> References: <65501543-6793-af2a-52eb-ef84ce0df759@oracle.com> Message-ID: Thanks, Robbin! StefanK On 2019-08-19 13:30, Robbin Ehn wrote: > Looks good, thanks! > > /Robbin > > On 2019-08-19 11:42, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch to rename the markOop files to markWord. >> >> http://cr.openjdk.java.net/~stefank/8229838/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8229838 >> >> JDK-8229258 reworked and renamed the markOopDesc class and markOop >> typedef, but the rename of the files were deferred. This patch renames >> the files to match the new name. >> >> Thanks, >> StefanK From boris.ulasevich at bell-sw.com Mon Aug 19 12:49:37 2019 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Mon, 19 Aug 2019 15:49:37 +0300 Subject: RFR: 8229352: Use of an unitialized register in 32-bit ARM template interpreter In-Reply-To: <338e4dc9-4d28-774b-fc8e-f4ffc96e1ca6@oracle.com> References: <20190716100738.EFA3E2E2022@aojmv0009> <20190811065555.2A0A13074FB@aojmv0009> <687d97ce-be7c-3598-3071-6070fa68d5d0@redhat.com> <20190813062935.5296F308C5B@aojmv0009> <80dedbe5-3627-c0a7-d33f-d7a89f386ae6@bell-sw.com> <338e4dc9-4d28-774b-fc8e-f4ffc96e1ca6@oracle.com> Message-ID: <9968983b-9121-6483-0586-4f8592127ca0@bell-sw.com> Dean, thank you! Christoph, here is the commit: http://hg.openjdk.java.net/jdk/jdk/rev/2e58f5d927a6 regards, Boris On 16.08.2019 22:16, dean.long at oracle.com wrote: > Yes, you're good to go. > > dl > > On 8/16/19 7:28 AM, Boris Ulasevich wrote: >> Hi Dean, >> >> I checked the patch is Ok on arm-hflt. If you think it is good to go I >> will be happy to commit the patch. >> >> regards, >> Boris >> >> On 13.08.2019 9:27, christoph.goettschkes at microdoc.com wrote: >>> Thanks for your feedback. >>> >>> Here is a new webrev with the proposed change applied: >>> http://cr.openjdk.java.net/~bulasevich/8229352/webrev.01/ >>> I tested the new changes with a subset of the hotspot tier1 JTreg test >>> group. >>> >>> Does this look fine to you? >>> >>> -- Christoph >>> >>> "hotspot-dev" wrote on 2019-08-12 >>> 20:53:46: >>> >>>> From: Aleksey Shipilev >>>> To: dean.long at oracle.com, hotspot-dev at openjdk.java.net >>>> Date: 2019-08-12 20:54 >>>> Subject: Re: RFR: 8229352: Use of an unitialized register in 32-bit ARM >>>> template interpreter >>>> Sent by: "hotspot-dev" >>>> >>>> On 8/12/19 8:37 PM, dean.long at oracle.com wrote: >>>>> Looks OK, but after the Condy change, the label "Long" might be better >>> named >>>> "NotDouble". >>>> >>>> +1 >>>> >>>>> On 8/10/19 11:54 PM, christoph.goettschkes at microdoc.com wrote: >>>>>> Hello, >>>>>> >>>>>> could someone please review the changes for >>>>>> https://bugs.openjdk.java.net/browse/JDK-8229352 >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~bulasevich/8229352/webrev.00/ >>>> >>>> Looks good to me. >>>> >>>> Note: changed the typo in "uninitialized" in issue synopsis, please >>>> make >>> sure >>>> changeset metadata >>>> reflects that. >>>> >>>> -- >>>> Thanks, >>>> -Aleksey >>>> >>> > From boris.ulasevich at bell-sw.com Mon Aug 19 12:50:46 2019 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Mon, 19 Aug 2019 15:50:46 +0300 Subject: RFR(S): 8229254: solaris_x64 build fails In-Reply-To: <776ab871-c23b-7844-9a3d-81ea22e53008@oracle.com> References: <9a371ec1-e125-4945-521b-90bb2b4c6984@bell-sw.com> <28049dbf-b2cd-3ef9-d58e-a66cb50eeedb@bell-sw.com> <776ab871-c23b-7844-9a3d-81ea22e53008@oracle.com> Message-ID: <796cbaa2-51ca-b899-9ea4-d8d82ba784ac@bell-sw.com> Hi David, thank you! On 17.08.2019 1:37, David Holmes wrote: > Hi Boris, > > On 17/08/2019 12:40 am, Boris Ulasevich wrote: >> Hi David, >> >> ?? Do you think the change is Ok or should I rework it somehow? > > The change is fine. > > Thanks, > David > >> thanks, >> Boris >> >> On 12.08.2019 11:53, Boris Ulasevich wrote: >>> Hi David, >>> >>> On 12.08.2019 5:47, David Holmes wrote: >>>> Hi Boris, >>>> >>>> On 9/08/2019 11:14 pm, Boris Ulasevich wrote: >>>>> Hi, >>>>> >>>>> Please review the following simple change to make solaris_x64 build >>>>> compilable. >>>>> >>>>> Syntax error was brought by JDK-8191278 [1]. The fix is evident. >>>> >>>> Yes looks good. >>>> >>>>> Missing constant issue occurred after JDK-8226238 [2]. I copied >>>>> workaround for the case of missing EM_AARCH64 constant in system >>>>> elf.h header from os_linux.cpp implementation. >>>> >>>> I'm really not sure why we keep expanding a Solaris specific >>>> structure with entries for architectures the OS does not run on ... >>> >>> Yes. I had the same concern. The first impulse was to remove the >>> AARCH64 data line or to surround it #ifdef AARCH directive. >>> >>> The sense of this line on os_solaris.cpp implementation might be a >>> good question on JDK-8226238 review. I think the answer is that it >>> makes no overhead, and potentially improves .so library compatibility >>> error message. >>> >>>> That aside the fix seems fine - the value is somewhat arbitrary but >>>> doesn't conflict with anything AFAICS. >>> >>> My explanation was not quite intelligible, sorry. As Kim have already >>> answered, this is as constant that should normally come from elf.h >>> header. But as Solaris system header elf.h does not have that, this >>> is just a workaround for the system header on build machine, very >>> similar to that in os_linux.cpp implementation. >>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> http://cr.openjdk.java.net/~bulasevich/8229254/webrev.00 >>>>> http://bugs.openjdk.java.net/browse/JDK-8229254 >>>>> >>>>> Testing done: tier1,tier2. >>>>> >>>>> thanks, >>>>> Boris >>>>> >>>>> [1] MappedByteBuffer bulk access memory failures are not handled >>>>> gracefully >>>>> >>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2019-June/038352.html >>>>> >>>>> [2] Improve error output and fix elf issues in os::dll_load >>>>> >>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2019-June/038597.html >>>>> From adam.farley at uk.ibm.com Mon Aug 19 15:21:11 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Mon, 19 Aug 2019 16:21:11 +0100 Subject: RFR: JDK-8227021: VM fails if any sun.boot.library.path paths are longer than JVM_MAXPATHLEN In-Reply-To: <4f892f24-4919-4f3a-7e62-0603e08561cc@oracle.com> References: <5ba808b0-ae52-0d0a-b84b-fc34df35475d@oracle.com> <025da83a-6569-f6ac-7590-5b200ed2344f@oracle.com> <8e62fc61-b46b-0033-f182-cb4a2dbf92fd@oracle.com> <4f892f24-4919-4f3a-7e62-0603e08561cc@oracle.com> Message-ID: Hi Coleen, David, Here's the new webrev: http://cr.openjdk.java.net/~afarley/8227021.5/webrev/ I made the requested changes, and moved the null check as suggested. (I agree passing a null for any of these values would be odd, and unlikely to be done on purpose.) It also includes a new jtreg test for this change, which uses ProcessTools. Let me know what you think (inc Serguei + others). Best Regards Adam Farley IBM Runtimes coleen.phillimore at oracle.com wrote on 16/08/2019 23:59:53: > From: coleen.phillimore at oracle.com > To: Adam Farley8 > Cc: David Holmes , hotspot-dev at openjdk.java.net > Date: 17/08/2019 00:00 > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > paths are longer than JVM_MAXPATHLEN > > > On 8/16/19 7:35 AM, Adam Farley8 wrote: > Hi Coleen, > > To confirm your suspicions, I didn't see your responses. No offence intended. > > I send a lot of mail so I'm sure I can be caught in people's spam filter. :) > > > Responses below. > > Best Regards > > Adam Farley > IBM Runtimes > > > coleen.phillimore at oracle.com wrote on 15/08/2019 13:42:51: > > > From: coleen.phillimore at oracle.com > > To: hotspot-dev at openjdk.java.net, Adam Farley8 > > , David Holmes > > Date: 15/08/2019 13:43 > > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > > paths are longer than JVM_MAXPATHLEN > > > > Hi Adam, David noticed that my code review replies only went to the > > mailing list. So here it is again. > > Thanks, > > Coleen > > > > On 8/13/19 5:29 PM, coleen.phillimore at oracle.com wrote: > > > > > > > > > On 8/13/19 11:48 AM, Adam Farley8 wrote: > > >> Hi David, > > >> > > >> Since we have two positive reviews (yours and Serguei's), could you > > >> sponsor the change please? > > > > > > If you get two positive reviews, but then one with comments, you need > > > to also answer that third reviews. I had some comments on your > > > change, which I'll repeat here: > > > > > > > > > https://urldefense.proofpoint.com/v2/url? > > u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021. > > > 2_webrev_src_hotspot_share_runtime_os.cpp.frames.html&d=DwIDaQ&c=jf_iaSHvJObTbx- > > siA1ZOg&r=P5m8KWUXJf- > > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=wjd3KxxgFQv49yjlb4Bndy- > > F1XV4pbuPZrmemiaFthA&s=xXwflqvuzoEhcREhr-x7rNMVDeroZ8Xh1LnW6NytumE&e= > > > > > > > > > This is code is unnecessarily hard to read and understand: > > > > > > 1329 char** os::split_path(const char* path, size_t* n) { > > > 1330 size_t pathmod = (size_t)0; > > > 1331 if (n != NULL) { > > > 1332 pathmod = *n; > > > 1333 } > > > 1334 *n = (size_t)0; > > > > > > It appears that 'n' is both an input and output parameter of this > > > function. Can you just make it another input parameter with some > > > descriptive name. Is it the length of the library name that you're > > > looking for? "pathmod" is huh? > > The 'n' is both an input and an output, yes. > > I could make it another input parameter, but that means modifying the > method signature. This seemed unnecessary, given that we have an input > vector we're not using for anything. > > It's not a big deal to add a parameter, especially since there's > only one call site, and the names don't have to be squished up C names. > > How about: char** split_path(char* path, size_t file_length, > size_t* elements) ? > > > The 'n' input is used as a modifier for the length of the path, as > mentioned in the comment. I called it "pathmod" because it's a PATH > length MODIFIER. I couldn't think of a better name that's also concise. > Would pathlenmod be better? Pathsizemod sounds like we're making the path > physically bigger, or maybe that's just me. :) > > > > > > > Then you don't have to check if someone has passed NULL. There's only > > > one caller to this from what I see. > > I'm not sure I understand this. We'd still need to check for null, even if > the pathmod has its own input parameter. I believe adding a NULL to an int > causes a segmentation error at runtime. > > If you're saying the null check isn't needed because we can ensure anon-null > is passed in via the only place we call split_path, I disagree that this is a > future-proof assumption. A null check seems prudent here. > > I think the function doesn't make any sense if you pass an output > parameter as NULL. Or at worst you could add it to the line: > > 1335 if (path == NULL || strlen(path) == 0 || n == NULL) { > 1336 return NULL; > 1337 } > 1334 *n = (size_t)0; > > But that's just weird. Why would a caller pass a non-null path and > not want the element count? > > Thanks, > Coleen > > > > > > > > 1352 char** opath = (char**) NEW_C_HEAP_ARRAY(char*, count, > > > mtInternal); > > > 1353 if (opath == NULL) { > > > 1354 return NULL; > > > 1355 } > > > > > > > > > Not your change but this calls vm_exit_out_of_memory() if > > > NEW_C_HEAP_ARRAY fails. It doesn't return NULL so you don't have to > > > check. > > Seems legit. I'll include this in the .5 version once we have consensus on > the other changes. Good spot. > > > > > > > 1375 char* s = (char*)NEW_C_HEAP_ARRAY(char, len + 1, mtInternal); > > > > > > Here you want to use NEW_C_HEAP_ARRAY_RETURN_NULL so you can check for > > > null and free memory. > > Good idea. Noted for .5. > > Let me know your thoughts on the other points above. > > > > > > > > > > > The rest seems okay. > > > > > > thanks, > > > Coleen > > > > > >> > > >> Best Regards > > >> > > >> Adam Farley > > >> IBM Runtimes > > >> > > >> > > >> David Holmes wrote on 12/08/2019 23:32:14: > > >> > > >>> From: David Holmes > > >>> To: Adam Farley8 > > >>> Cc: hotspot-dev at openjdk.java.net, "serguei.spitsyn at oracle.com" > > >>> > > >>> Date: 12/08/2019 23:32 > > >>> Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > > >>> paths are longer than JVM_MAXPATHLEN > > >>> > > >>> Looks fine. > > >>> > > >>> Thanks, > > >>> David > > >>> > > >>> On 13/08/2019 1:19 am, Adam Farley8 wrote: > > >>>> Hi David, > > >>>> > > >>>> Changes made as requested: > > >>>> https://urldefense.proofpoint.com/v2/url? > > >>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.4_webrev&d=DwID- > > >>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > >>> > > >> > > > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=mZM8IR4e_zmrfcsF3XJjoGEMrZb4WtEL7Y6Ugd6Naqg&s=sZ2UKqqUIq0El- > > >> > > >>> RsqYz6jmTh4Q2UghwdrQX6of8Lw0E&e= > > >>>> Best Regards > > >>>> > > >>>> Adam Farley > > >>>> IBM Runtimes > > >>>> > > >>>> > > >>>> David Holmes wrote on 12/08/2019 04:55:36: > > >>>> > > >>>>> From: David Holmes > > >>>>> To: Adam Farley8 , > > >>>>> "serguei.spitsyn at oracle.com" > > >>>>> Cc: hotspot-dev at openjdk.java.net > > >>>>> Date: 12/08/2019 04:56 > > >>>>> Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > > >>>>> paths are longer than JVM_MAXPATHLEN > > >>>>> > > >>>>> Hi Adam, > > >>>>> > > >>>>> On 10/08/2019 2:47 am, Adam Farley8 wrote: > > >>>>>> Hi Serguei, David, > > >>>>>> > > >>>>>> My turn to apologise for the delay. :) > > >>>>>> > > >>>>>> I've modified the code as per Serguei's request. Take a look and > > >> let me > > >>>>>> know if this is the sort of thing you were thinking of. > > >>>>>> > > >>>>>> Webrev: https://urldefense.proofpoint.com/v2/url? > > >>>>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.3_webrev_&d=DwID- > > >>>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > >>>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > > >>>>> > > >> > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=L19aeFXoR9JIO62QRPFzZObIU8RbhpCtXSvUibD2ISk&e= > > >> > > >>>>> I'd prefer to see the helper just as a file static function rather > > >> than > > >>>>> adding it to the os class. > > >>>>> > > >>>>> + * supplied array of arrays of chars (a), where n > > >>>>> > > >>>>> I assume (a) is meant to refer to the parameter, but you actually > > >> called > > >>>>> it arrayarray. I think "a" or "arr" would suffice. > > >>>>> > > >>>>> Thanks, > > >>>>> David > > >>>>> > > >>>>>> Best Regards > > >>>>>> > > >>>>>> Adam Farley > > >>>>>> IBM Runtimes > > >>>>>> > > >>>>>> > > >>>>>> "serguei.spitsyn at oracle.com" wrote on > > >>>>>> 31/07/2019 17:18:05: > > >>>>>> > > >>>>>>> From: "serguei.spitsyn at oracle.com" > > >>>>>>> To: Adam Farley8 , David Holmes > > >>>>>>> > > >>>>>>> Cc: serviceability-dev , > > >>>>>>> hotspot-dev at openjdk.java.net > > >>>>>>> Date: 31/07/2019 17:18 > > >>>>>>> Subject: Re: RFR: JDK-8227021: VM fails if any > > >> sun.boot.library.path > > >>>>>>> paths are longer than JVM_MAXPATHLEN > > >>>>>>> > > >>>>>>> Hi Adam, > > >>>>>>> > > >>>>>>> It looks Okay to me. > > >>>>>>> > > >>>>>>> A couple of minor comments. > > >>>>>>> > > >>>>>>> https://urldefense.proofpoint.com/v2/url? > > >>>>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021. > > >>>>> 2_webrev_src_hotspot_&d=DwID-g&c=jf_iaSHvJObTbx- > > >>>>> siA1ZOg&r=P5m8KWUXJf-CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > > >>>>> > > >> > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NL6tYuwwDod3DSmj-1ztxAywpO8L52HEyO0wvTR05bs&e= > > >> > > >>>>>>> share/runtime/os.cpp.frames.html > > >>>>>>> 1362 //release allocated storage before exiting the vm > > >>>>>>> 1363 while (i > 0) { > > >>>>>>> 1364 i--; > > >>>>>>> 1365 if (opath[i] != NULL) { > > >>>>>>> 1366 FREE_C_HEAP_ARRAY(char, opath[i]); > > >>>>>>> 1367 } > > >>>>>>> 1368 } > > >>>>>>> 1369 FREE_C_HEAP_ARRAY(char*, opath); > > >>>>>>> > > >>>>>>> 1377 //release allocated storage before returning null > > >>>>>>> 1378 while (i > 0) { > > >>>>>>> 1379 i--; > > >>>>>>> 1380 if (opath[i] != NULL) { > > >>>>>>> 1381 FREE_C_HEAP_ARRAY(char, opath[i]); > > >>>>>>> 1382 } > > >>>>>>> 1383 } > > >>>>>>> 1384 FREE_C_HEAP_ARRAY(char*, opath); > > >>>>>>> > > >>>>>>> This duplicated fragments is worth to refactor to a function. > > >>>>>>> Also a space is missed at the beginning of the comment. > > >>>>>>> > > >>>>>>> > > >>>>>>> Thanks, > > >>>>>>> Serguei > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> On 7/31/19 02:01, Adam Farley8 wrote: > > >>>>>>> Hi All, > > >>>>>>> > > >>>>>>> Reviewers requested for the change below. > > >>>>>>> > > >>>>>>> @David - Agreed. Would you be prepared to sponsor the change? > > >>>>>>> > > >>>>>>> Bug: https://urldefense.proofpoint.com/v2/url? > > >>>>> u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8227021&d=DwID- > > >>>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > >>>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > > >>>>> > > >> > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=xykJ0KLy9AKWO8zmC0amfR7xxUsvyKEjlf3y7WWOqvE&e= > > >> > > >>>>>>> Webrev: https://urldefense.proofpoint.com/v2/url? > > >>>>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.2_webrev_&d=DwID- > > >>>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > >>>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > > >>>>> > > >> > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NvIza4VVWG3CiDhmQVmXsghH_4h_c5mFJbHwkCUcut0&e= > > >> > > >>>>>>> Best Regards > > >>>>>>> > > >>>>>>> Adam Farley > > >>>>>>> IBM Runtimes > > >>>>>>> > > >>>>>>> P.S. Remembered to add the links this time. :) > > >>>>>>> > > >>>>>>> > > >>>>>>> David Holmes wrote on 30/07/2019 > > >> 03:37:53: > > >>>>>>>> From: David Holmes > > >>>>>>>> To: Adam Farley8 > > >>>>>>>> Cc: hotspot-dev at openjdk.java.net, serviceability-dev > > >>>>>>>> > > >>>>>>>> Date: 30/07/2019 03:38 > > >>>>>>>> Subject: Re: RFR: JDK-8227021: VM fails if any > > >> sun.boot.library.path > > >>>>>>>> paths are longer than JVM_MAXPATHLEN > > >>>>>>>> > > >>>>>>>> Hi Adam, > > >>>>>>>> > > >>>>>>>> On 25/07/2019 3:57 am, Adam Farley8 wrote: > > >>>>>>>>> Hi David, > > >>>>>>>>> > > >>>>>>>>> Welcome back. :) > > >>>>>>>> Thanks. Sorry for the delay in getting back to this. > > >>>>>>>> > > >>>>>>>> I like .v2 as it is much simpler (notwithstanding freeing > > >>> the already > > >>>>>>>> allocated arrays adds some complexity - thanks for fixing that). > > >>>>>>>> > > >>>>>>>> I'm still not sure we can't optimise things better for > > >> unchangeable > > >>>>>>>> properties like the boot libary path, but that's another RFE. > > >>>>>>>> > > >>>>>>>> Thanks, > > >>>>>>>> David > > >>>>>>>> > > >>>>>>> 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 > > >> 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 christoph.goettschkes at microdoc.com Mon Aug 19 15:37:50 2019 From: christoph.goettschkes at microdoc.com (christoph.goettschkes at microdoc.com) Date: Mon, 19 Aug 2019 17:37:50 +0200 Subject: RFR: 8229352: Use of an unitialized register in 32-bit ARM template interpreter In-Reply-To: <9968983b-9121-6483-0586-4f8592127ca0@bell-sw.com> References: <20190716100738.EFA3E2E2022@aojmv0009> <20190811065555.2A0A13074FB@aojmv0009> <687d97ce-be7c-3598-3071-6070fa68d5d0@redhat.com> <20190813062935.5296F308C5B@aojmv0009> <80dedbe5-3627-c0a7-d33f-d7a89f386ae6@bell-sw.com> <338e4dc9-4d28-774b-fc8e-f4ffc96e1ca6@oracle.com> <9968983b-9121-6483-0586-4f8592127ca0@bell-sw.com> Message-ID: Hi Boris, thanks for guiding me through the process and for supporting me, very much appreciated. -- Christoph Boris Ulasevich wrote on 2019-08-19 14:49:37: > From: Boris Ulasevich > To: dean.long at oracle.com, christoph.goettschkes at microdoc.com > Cc: hotspot-dev at openjdk.java.net > Date: 2019-08-19 14:49 > Subject: Re: RFR: 8229352: Use of an unitialized register in 32-bit ARM > template interpreter > > Dean, thank you! > > Christoph, here is the commit: > http://hg.openjdk.java.net/jdk/jdk/rev/2e58f5d927a6 > > regards, > Boris > > On 16.08.2019 22:16, dean.long at oracle.com wrote: > > Yes, you're good to go. > > > > dl > > > > On 8/16/19 7:28 AM, Boris Ulasevich wrote: > >> Hi Dean, > >> > >> I checked the patch is Ok on arm-hflt. If you think it is good to go I > >> will be happy to commit the patch. > >> > >> regards, > >> Boris > >> > >> On 13.08.2019 9:27, christoph.goettschkes at microdoc.com wrote: > >>> Thanks for your feedback. > >>> > >>> Here is a new webrev with the proposed change applied: > >>> http://cr.openjdk.java.net/~bulasevich/8229352/webrev.01/ > >>> I tested the new changes with a subset of the hotspot tier1 JTreg test > >>> group. > >>> > >>> Does this look fine to you? > >>> > >>> -- Christoph > >>> > >>> "hotspot-dev" wrote on 2019-08-12 > >>> 20:53:46: > >>> > >>>> From: Aleksey Shipilev > >>>> To: dean.long at oracle.com, hotspot-dev at openjdk.java.net > >>>> Date: 2019-08-12 20:54 > >>>> Subject: Re: RFR: 8229352: Use of an unitialized register in 32-bit ARM > >>>> template interpreter > >>>> Sent by: "hotspot-dev" > >>>> > >>>> On 8/12/19 8:37 PM, dean.long at oracle.com wrote: > >>>>> Looks OK, but after the Condy change, the label "Long" might be better > >>> named > >>>> "NotDouble". > >>>> > >>>> +1 > >>>> > >>>>> On 8/10/19 11:54 PM, christoph.goettschkes at microdoc.com wrote: > >>>>>> Hello, > >>>>>> > >>>>>> could someone please review the changes for > >>>>>> https://bugs.openjdk.java.net/browse/JDK-8229352 > >>>>>> > >>>>>> webrev: http://cr.openjdk.java.net/~bulasevich/8229352/webrev.00/ > >>>> > >>>> Looks good to me. > >>>> > >>>> Note: changed the typo in "uninitialized" in issue synopsis, please > >>>> make > >>> sure > >>>> changeset metadata > >>>> reflects that. > >>>> > >>>> -- > >>>> Thanks, > >>>> -Aleksey > >>>> > >>> > > > From kim.barrett at oracle.com Mon Aug 19 22:32:22 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 19 Aug 2019 18:32:22 -0400 Subject: RFR: 8227054: ServiceThread needs to know about all OopStorage objects In-Reply-To: <694f8e0c-b00f-54d4-105d-68e6442b2759@oracle.com> References: <8181924C-36E6-4B91-9567-150F00286241@oracle.com> <74C738E7-CBDD-4891-ABD6-F8E023372508@oracle.com> <60099477-9AD4-4EFC-AA6F-6EF19D840E67@oracle.com> <164151e7-fec4-8c61-f247-3d5a41c910c1@oracle.com> <96EE9BB8-9EE5-4FBB-B266-785C563BFC2E@oracle.com> <694f8e0c-b00f-54d4-105d-68e6442b2759@oracle.com> Message-ID: <46A102CD-F381-4ACC-852E-F36B9F9DD9DD@oracle.com> > On Aug 12, 2019, at 4:52 AM, Erik ?sterlund wrote: > On 2019-08-12 05:26, Kim Barrett wrote: >>> On Aug 10, 2019, at 3:52 AM, Erik Osterlund wrote: >>> Apart from those two things, I really liked the approach! >> Thanks. Hopefully we?re approaching a conclusion on this change. > > I hope so. Finally getting back to this; I got distracted by other things. I've removed the macros that were bothering you. full: http://cr.openjdk.java.net/~kbarrett/8227054/open.03/ incr: http://cr.openjdk.java.net/~kbarrett/8227054/open.03.inc/ From erik.osterlund at oracle.com Tue Aug 20 06:23:13 2019 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Tue, 20 Aug 2019 08:23:13 +0200 Subject: RFR: 8227054: ServiceThread needs to know about all OopStorage objects In-Reply-To: <46A102CD-F381-4ACC-852E-F36B9F9DD9DD@oracle.com> References: <8181924C-36E6-4B91-9567-150F00286241@oracle.com> <74C738E7-CBDD-4891-ABD6-F8E023372508@oracle.com> <60099477-9AD4-4EFC-AA6F-6EF19D840E67@oracle.com> <164151e7-fec4-8c61-f247-3d5a41c910c1@oracle.com> <96EE9BB8-9EE5-4FBB-B266-785C563BFC2E@oracle.com> <694f8e0c-b00f-54d4-105d-68e6442b2759@oracle.com> <46A102CD-F381-4ACC-852E-F36B9F9DD9DD@oracle.com> Message-ID: Hi Kim, Looks good. Thanks, /Erik On 20 Aug 2019, at 00:32, Kim Barrett wrote: >> On Aug 12, 2019, at 4:52 AM, Erik ?sterlund wrote: >> On 2019-08-12 05:26, Kim Barrett wrote: >>>> On Aug 10, 2019, at 3:52 AM, Erik Osterlund wrote: >>>> Apart from those two things, I really liked the approach! >>> Thanks. Hopefully we?re approaching a conclusion on this change. >> >> I hope so. > > Finally getting back to this; I got distracted by other things. > > I've removed the macros that were bothering you. > > full: http://cr.openjdk.java.net/~kbarrett/8227054/open.03/ > incr: http://cr.openjdk.java.net/~kbarrett/8227054/open.03.inc/ > From shade at redhat.com Tue Aug 20 08:12:39 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 20 Aug 2019 10:12:39 +0200 Subject: [14] RFR(XS): 8229158: make UseSwitchProfiling non-experimental or false by-default In-Reply-To: <39490af4-3fcf-7849-b8a7-a394a3ee5c61@oracle.com> References: <3eda5642-17f2-75d5-62b7-e118eaed2e90@oracle.com> <39490af4-3fcf-7849-b8a7-a394a3ee5c61@oracle.com> Message-ID: <17acecba-210d-e097-a6cc-763198e8030c@redhat.com> On 8/6/19 1:17 PM, David Holmes wrote: > On 6/08/2019 8:28 pm, Christian Hagedorn wrote: >> https://bugs.openjdk.java.net/browse/JDK-8229158 >> http://cr.openjdk.java.net/~thartmann/8229158/webrev.00/ > > hotspot-compiler-dev seems like a better list for this change as that is where the original code was > reviewed. In particular I think you need to get buy-in from the people that provided this code in > the first place - who would be Aleksey Shipilev and Roland Westrelin. > > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2018-March/028595.html Only now have I notices we have been asked explicitly :) The patch looks good, and it indeed should have been diagnostic from day one (enabled by default, disabled when JVM engineers tell you so to follow up on failures or write targeted tests). -- Thanks, -Aleksey From tobias.hartmann at oracle.com Tue Aug 20 08:46:52 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 20 Aug 2019 10:46:52 +0200 Subject: [14] RFR(XS): 8229158: make UseSwitchProfiling non-experimental or false by-default In-Reply-To: <17acecba-210d-e097-a6cc-763198e8030c@redhat.com> References: <3eda5642-17f2-75d5-62b7-e118eaed2e90@oracle.com> <39490af4-3fcf-7849-b8a7-a394a3ee5c61@oracle.com> <17acecba-210d-e097-a6cc-763198e8030c@redhat.com> Message-ID: <453ba387-4c9d-b405-85e7-e48262557c27@oracle.com> Hi Aleksey, thanks on behalf of Christian who is currently on vacation. Pushed. Best regards, Tobias On 20.08.19 10:12, Aleksey Shipilev wrote: > On 8/6/19 1:17 PM, David Holmes wrote: >> On 6/08/2019 8:28 pm, Christian Hagedorn wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8229158 >>> http://cr.openjdk.java.net/~thartmann/8229158/webrev.00/ >> >> hotspot-compiler-dev seems like a better list for this change as that is where the original code was >> reviewed. In particular I think you need to get buy-in from the people that provided this code in >> the first place - who would be Aleksey Shipilev and Roland Westrelin. >> >> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2018-March/028595.html > > Only now have I notices we have been asked explicitly :) > > The patch looks good, and it indeed should have been diagnostic from day one (enabled by default, > disabled when JVM engineers tell you so to follow up on failures or write targeted tests). > From david.holmes at oracle.com Tue Aug 20 11:55:26 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 20 Aug 2019 21:55:26 +1000 Subject: RFR: JDK-8227021: VM fails if any sun.boot.library.path paths are longer than JVM_MAXPATHLEN In-Reply-To: References: <5ba808b0-ae52-0d0a-b84b-fc34df35475d@oracle.com> <025da83a-6569-f6ac-7590-5b200ed2344f@oracle.com> <8e62fc61-b46b-0033-f182-cb4a2dbf92fd@oracle.com> <4f892f24-4919-4f3a-7e62-0603e08561cc@oracle.com> Message-ID: <4b195206-7a33-4f68-4207-fd214793cf28@oracle.com> Hi Adam, On 20/08/2019 1:21 am, Adam Farley8 wrote: > Hi Coleen, David, > > Here's the new webrev: http://cr.openjdk.java.net/~afarley/8227021.5/webrev/ In this comment: ! * in use, you can pass the length of that in n, to ensure ! * we detect if any path exceeds the maximum path length ! * once prepended onto the sub-path/file name. * It is the callers responsibility to: * a> check the value of n, and n may be 0. the three references to 'n' should be to the new file_name_length parameter. Looking at the test: 2 * Copyright (c) 2019, 2019, Oracle and/or its affiliates. All rights reserved. For a new file there is only a single year specified so this should be: 2 * Copyright (c) 2019, Oracle and/or its affiliates. All rights reserved. 31 * @run main TestSunBootLibraryPath As this just launches another VM it is more efficient to use "@run driver". 35 import java.lang.IllegalArgumentException; Nit: java.lang.* is implicitly imported. 39 static String expectedErrorMessage =("The VM tried to use a path that exceeds the maximum path length for " 40 + "this system. Review path-containing parameters and properties, such as " 41 + "sun.boot.library.path, to identify potential sources for this path."); Nit: no need for parentheses. Probably also no need to check for the entire message - the first line should suffice. 48 //Add enough characters to make it "too long". 49 for (int i = 0 ; i < tooLongPathSize ; i++) tooLongPath += "a"; This can be done more efficiently and succinctly as: tooLongPath += "a".repeat(5000); There's probably an even better way. :) 60 throw new java.lang.IllegalArgumentException("Test was launched with an invalid argument."); No need to specify "java.lang". Thanks, David ----- > I made the requested changes, and moved the null check as suggested. > > (I agree passing a null for any of these values would be odd, and > unlikely to be done on purpose.) > > It also includes a new jtreg test for this change, which uses ProcessTools. > > Let me know what you think (inc Serguei + others). > > Best Regards > > Adam Farley > IBM Runtimes > > > coleen.phillimore at oracle.com wrote on 16/08/2019 23:59:53: > >> From: coleen.phillimore at oracle.com >> To: Adam Farley8 >> Cc: David Holmes , hotspot-dev at openjdk.java.net >> Date: 17/08/2019 00:00 >> Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path >> paths are longer than JVM_MAXPATHLEN >> >> > >> On 8/16/19 7:35 AM, Adam Farley8 wrote: >> Hi Coleen, >> >> To confirm your suspicions, I didn't see your responses. No offence intended. >> >> I send a lot of mail so I'm sure I can be caught in people's spam filter. :) >> >> >> Responses below. >> >> Best Regards >> >> Adam Farley >> IBM Runtimes >> >> >> coleen.phillimore at oracle.com wrote on 15/08/2019 13:42:51: >> >> > From: coleen.phillimore at oracle.com >> > To: hotspot-dev at openjdk.java.net, Adam Farley8 >> > , David Holmes >> > Date: 15/08/2019 13:43 >> > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path >> > paths are longer than JVM_MAXPATHLEN >> > >> > Hi Adam,? David noticed that my code review replies only went to the >> > mailing list.? So here it is again. >> > Thanks, >> > Coleen >> > >> > On 8/13/19 5:29 PM, coleen.phillimore at oracle.com wrote: >> > > >> > > >> > > On 8/13/19 11:48 AM, Adam Farley8 wrote: >> > >> Hi David, >> > >> >> > >> Since we have two positive reviews (yours and Serguei's), could you >> > >> sponsor the change please? >> > > >> > > If you get two positive reviews, but then one with comments, you need >> > > to also answer that third reviews.? I had some comments on your >> > > change, which I'll repeat here: >> > > >> > > >> > > https://urldefense.proofpoint.com/v2/url? >> > u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021. >> > >> 2_webrev_src_hotspot_share_runtime_os.cpp.frames.html&d=DwIDaQ&c=jf_iaSHvJObTbx- >> > siA1ZOg&r=P5m8KWUXJf- >> > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=wjd3KxxgFQv49yjlb4Bndy- >> > F1XV4pbuPZrmemiaFthA&s=xXwflqvuzoEhcREhr-x7rNMVDeroZ8Xh1LnW6NytumE&e= >> > > >> > > >> > > This is code is unnecessarily hard to read and understand: >> > > >> > > 1329 char** os::split_path(const char* path, size_t* n) { >> > > 1330 size_t pathmod = (size_t)0; >> > > 1331 if (n != NULL) { >> > > 1332 pathmod = *n; >> > > 1333 } >> > > 1334 *n = (size_t)0; >> > > >> > > It appears that 'n' is both an input and output parameter of this >> > > function.? Can you just make it another input parameter with some >> > > descriptive name.? Is it the length of the library name that you're >> > > looking for?? "pathmod" is huh? >> >> The 'n' is both an input and an output, yes. >> >> I could make it another input parameter, but that means modifying the >> method signature. This seemed unnecessary, given that we have an input >> vector we're not using for anything. >> >> It's not a big deal to add a parameter, especially since there's >> only one call site, and the names don't have to be squished up C names. >> >> How about:? char** split_path(char* path, size_t file_length, >> size_t* elements) ? > >> >> >> The 'n' input is used as a modifier for the length of the path, as >> mentioned in the comment. I called it "pathmod" because it's a PATH >> length MODIFIER. I couldn't think of a better name that's also concise. >> Would pathlenmod be better? Pathsizemod sounds like we're making the path >> physically bigger, or maybe that's just me. :) >> >> > > >> > > Then you don't have to check if someone has passed NULL. There's only >> > > one caller to this from what I see. >> >> I'm not sure I understand this. We'd still need to check for null, even if >> the pathmod has its own input parameter. I believe adding a NULL to an int >> causes a segmentation error at runtime. >> >> If you're saying the null check isn't needed because we can ensure anon-null >> is passed in via the only place we call split_path, I disagree that this is a >> future-proof assumption. A null check seems prudent here. >> >> I think the function doesn't make any sense if you pass an output >> parameter as NULL.? Or at worst you could add it to the line: >> >> 1335 if (path == NULL || strlen(path) == 0 || n == NULL) { >> 1336 ? ?? return NULL; >> 1337 } >> 1334 *n = (size_t)0; >> >> But that's just weird. Why would a caller pass a non-null path and >> not want the element count? >> >> Thanks, >> Coleen >> >> >> > > >> > > 1352?? char** opath = (char**) NEW_C_HEAP_ARRAY(char*, count, >> > > mtInternal); >> > > 1353?? if (opath == NULL) { >> > > 1354???? return NULL; >> > > 1355?? } >> > > >> > > >> > > Not your change but this calls vm_exit_out_of_memory() if >> > > NEW_C_HEAP_ARRAY fails.? It doesn't return NULL so you don't have to >> > > check. >> >> Seems legit. I'll include this in the .5 version once we have consensus on >> the other changes. Good spot. >> >> > > >> > > 1375???? char* s? = (char*)NEW_C_HEAP_ARRAY(char, len + 1, mtInternal); >> > > >> > > Here you want to use NEW_C_HEAP_ARRAY_RETURN_NULL so you can check for >> > > null and free memory. >> >> Good idea. Noted for .5. >> >> Let me know your thoughts on the other points above. >> >> >> > > >> > > >> > > The rest seems okay. >> > > >> > > thanks, >> > > Coleen >> > > >> > >> >> > >> Best Regards >> > >> >> > >> Adam Farley >> > >> IBM Runtimes >> > >> >> > >> >> > >> David Holmes wrote on 12/08/2019 23:32:14: >> > >> >> > >>> From: David Holmes >> > >>> To: Adam Farley8 >> > >>> Cc: hotspot-dev at openjdk.java.net, "serguei.spitsyn at oracle.com" >> > >>> >> > >>> Date: 12/08/2019 23:32 >> > >>> Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path >> > >>> paths are longer than JVM_MAXPATHLEN >> > >>> >> > >>> Looks fine. >> > >>> >> > >>> Thanks, >> > >>> David >> > >>> >> > >>> On 13/08/2019 1:19 am, Adam Farley8 wrote: >> > >>>> Hi David, >> > >>>> >> > >>>> Changes made as requested: >> > >>>> https://urldefense.proofpoint.com/v2/url? >> > >>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.4_webrev&d=DwID- >> > >>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- >> > >>> >> > >> >> > >> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=mZM8IR4e_zmrfcsF3XJjoGEMrZb4WtEL7Y6Ugd6Naqg&s=sZ2UKqqUIq0El- >> > >> >> > >>> RsqYz6jmTh4Q2UghwdrQX6of8Lw0E&e= >> > >>>> Best Regards >> > >>>> >> > >>>> Adam Farley >> > >>>> IBM Runtimes >> > >>>> >> > >>>> >> > >>>> David Holmes wrote on 12/08/2019 04:55:36: >> > >>>> >> > >>>>> From: David Holmes >> > >>>>> To: Adam Farley8 , >> > >>>>> "serguei.spitsyn at oracle.com" >> > >>>>> Cc: hotspot-dev at openjdk.java.net >> > >>>>> Date: 12/08/2019 04:56 >> > >>>>> Subject: Re: RFR: JDK-8227021:? VM fails if any sun.boot.library.path >> > >>>>> paths are longer than JVM_MAXPATHLEN >> > >>>>> >> > >>>>> Hi Adam, >> > >>>>> >> > >>>>> On 10/08/2019 2:47 am, Adam Farley8 wrote: >> > >>>>>> Hi Serguei, David, >> > >>>>>> >> > >>>>>> My turn to apologise for the delay. :) >> > >>>>>> >> > >>>>>> I've modified the code as per Serguei's request. Take a look? and >> > >> let me >> > >>>>>> know if this is the sort of thing you were thinking of. >> > >>>>>> >> > >>>>>> Webrev: https://urldefense.proofpoint.com/v2/url? >> > >>>>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.3_webrev_&d=DwID- >> > >>>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- >> > >>>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- >> > >>>>> >> > >> >> > >> yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=L19aeFXoR9JIO62QRPFzZObIU8RbhpCtXSvUibD2ISk&e= >> > >> >> > >>>>> I'd prefer to see the helper just as a file static function rather >> > >> than >> > >>>>> adding it to the os class. >> > >>>>> >> > >>>>> +? * supplied array of arrays of chars (a), where n >> > >>>>> >> > >>>>> I assume (a) is meant to refer to the parameter, but you actually >> > >> called >> > >>>>> it arrayarray. I think "a" or "arr" would suffice. >> > >>>>> >> > >>>>> Thanks, >> > >>>>> David >> > >>>>> >> > >>>>>> Best Regards >> > >>>>>> >> > >>>>>> Adam Farley >> > >>>>>> IBM Runtimes >> > >>>>>> >> > >>>>>> >> > >>>>>> "serguei.spitsyn at oracle.com" ? wrote on >> > >>>>>> 31/07/2019 17:18:05: >> > >>>>>> >> > >>>>>>> From: "serguei.spitsyn at oracle.com" >> > >>>>>>> To: Adam Farley8 , David? Holmes >> > >>>>>>> >> > >>>>>>> Cc: serviceability-dev , >> > >>>>>>> hotspot-dev at openjdk.java.net >> > >>>>>>> Date: 31/07/2019 17:18 >> > >>>>>>> Subject: Re: RFR: JDK-8227021: VM fails if any >> > >> sun.boot.library.path >> > >>>>>>> paths are longer than JVM_MAXPATHLEN >> > >>>>>>> >> > >>>>>>> Hi Adam, >> > >>>>>>> >> > >>>>>>> It looks Okay to me. >> > >>>>>>> >> > >>>>>>> A couple of minor comments. >> > >>>>>>> >> > >>>>>>> https://urldefense.proofpoint.com/v2/url? >> > >>>>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021. >> > >>>>> 2_webrev_src_hotspot_&d=DwID-g&c=jf_iaSHvJObTbx- >> > >>>>> siA1ZOg&r=P5m8KWUXJf-CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- >> > >>>>> >> > >> >> > >> yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NL6tYuwwDod3DSmj-1ztxAywpO8L52HEyO0wvTR05bs&e= >> > >> >> > >>>>>>> share/runtime/os.cpp.frames.html >> > >>>>>>> 1362 //release? allocated storage? before exiting the vm >> > >>>>>>> 1363 while (i > 0) { >> > >>>>>>> 1364 i--; >> > >>>>>>> 1365 if (opath[i] != NULL)? { >> > >>>>>>> 1366 FREE_C_HEAP_ARRAY(char,?? opath[i]); >> > >>>>>>> 1367 } >> > >>>>>>> 1368 } >> > >>>>>>> 1369 FREE_C_HEAP_ARRAY(char*, opath); >> > >>>>>>> >> > >>>>>>> 1377 //release allocated storage before returning? null >> > >>>>>>> 1378 while (i > 0) { >> > >>>>>>> 1379 i--; >> > >>>>>>> 1380 if (opath[i] != NULL)? { >> > >>>>>>> 1381 FREE_C_HEAP_ARRAY(char,?? opath[i]); >> > >>>>>>> 1382 } >> > >>>>>>> 1383 } >> > >>>>>>> 1384 FREE_C_HEAP_ARRAY(char*, opath); >> > >>>>>>> >> > >>>>>>> This duplicated fragments is worth to refactor to a function. >> > >>>>>>> Also a space is missed at the beginning of the comment. >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> Thanks, >> > >>>>>>> Serguei >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> On 7/31/19 02:01, Adam Farley8 wrote: >> > >>>>>>> Hi All, >> > >>>>>>> >> > >>>>>>> Reviewers requested for the change below. >> > >>>>>>> >> > >>>>>>> @David - Agreed. Would you be prepared to sponsor the change? >> > >>>>>>> >> > >>>>>>> Bug: https://urldefense.proofpoint.com/v2/url? >> > >>>>> u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8227021&d=DwID- >> > >>>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- >> > >>>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- >> > >>>>> >> > >> >> > >> yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=xykJ0KLy9AKWO8zmC0amfR7xxUsvyKEjlf3y7WWOqvE&e= >> > >> >> > >>>>>>> Webrev: https://urldefense.proofpoint.com/v2/url? >> > >>>>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.2_webrev_&d=DwID- >> > >>>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- >> > >>>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- >> > >>>>> >> > >> >> > >> yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NvIza4VVWG3CiDhmQVmXsghH_4h_c5mFJbHwkCUcut0&e= >> > >> >> > >>>>>>> Best Regards >> > >>>>>>> >> > >>>>>>> Adam Farley >> > >>>>>>> IBM Runtimes >> > >>>>>>> >> > >>>>>>> P.S. Remembered to add the links this time. :) >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> David Holmes wrote on 30/07/2019 >> > >> 03:37:53: >> > >>>>>>>> From: David Holmes >> > >>>>>>>> To: Adam Farley8 >> > >>>>>>>> Cc: hotspot-dev at openjdk.java.net, serviceability-dev >> > >>>>>>>> >> > >>>>>>>> Date: 30/07/2019 03:38 >> > >>>>>>>> Subject: Re: RFR: JDK-8227021: VM fails if any >> > >> sun.boot.library.path >> > >>>>>>>> paths are longer than JVM_MAXPATHLEN >> > >>>>>>>> >> > >>>>>>>> Hi Adam, >> > >>>>>>>> >> > >>>>>>>> On 25/07/2019 3:57 am, Adam Farley8 wrote: >> > >>>>>>>>> Hi David, >> > >>>>>>>>> >> > >>>>>>>>> Welcome back. :) >> > >>>>>>>> Thanks. Sorry for the delay in getting back to this. >> > >>>>>>>> >> > >>>>>>>> I like .v2 as it is much simpler (notwithstanding freeing >> > >>> the? already >> > >>>>>>>> allocated arrays adds some complexity - thanks for fixing that). >> > >>>>>>>> >> > >>>>>>>> I'm still not sure we can't optimise things better for >> > >> unchangeable >> > >>>>>>>> properties like the boot libary path, but that's another? RFE. >> > >>>>>>>> >> > >>>>>>>> Thanks, >> > >>>>>>>> David >> > >>>>>>>> >> > >>>>>>> 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 >> > >> 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 stefan.karlsson at oracle.com Tue Aug 20 12:09:43 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 20 Aug 2019 14:09:43 +0200 Subject: RFR: 8229836: Remove include of globals.hpp from allocation.hpp Message-ID: <5abdb28e-3658-d7d1-20b0-000898818f42@oracle.com> Hi all, Please review this patch to remove the include of globals.hpp from allocation.hpp. http://cr.openjdk.java.net/~stefank/8229836/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8229836 Note this change is just the bare minimum to get it to compile on our build platforms. I haven't tried to find all files that are missing explicit includes of globals.hpp. Thanks, StefanK From adam.farley at uk.ibm.com Tue Aug 20 13:13:38 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Tue, 20 Aug 2019 14:13:38 +0100 Subject: RFR: JDK-8227021: VM fails if any sun.boot.library.path paths are longer than JVM_MAXPATHLEN In-Reply-To: <4b195206-7a33-4f68-4207-fd214793cf28@oracle.com> References: <5ba808b0-ae52-0d0a-b84b-fc34df35475d@oracle.com> <025da83a-6569-f6ac-7590-5b200ed2344f@oracle.com> <8e62fc61-b46b-0033-f182-cb4a2dbf92fd@oracle.com> <4f892f24-4919-4f3a-7e62-0603e08561cc@oracle.com> <4b195206-7a33-4f68-4207-fd214793cf28@oracle.com> Message-ID: Hi David, Good advice. Changes made as requested. Webrev: http://cr.openjdk.java.net/~afarley/8227021.6/webrev/ Does anyone have further concerns or changes to propose? Best Regards Adam Farley IBM Runtimes David Holmes wrote on 20/08/2019 12:55:26: > From: David Holmes > To: Adam Farley8 , coleen.phillimore at oracle.com > Cc: hotspot-dev at openjdk.java.net > Date: 20/08/2019 12:55 > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > paths are longer than JVM_MAXPATHLEN > > Hi Adam, > > On 20/08/2019 1:21 am, Adam Farley8 wrote: > > Hi Coleen, David, > > > > Here's the new webrev: https://urldefense.proofpoint.com/v2/url? > u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.5_webrev_&d=DwID- > g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=zaU5bibnUdHVncMttyVGbYf1yzDRUt26f9raqqKlJm0&s=QPe5l0tueNKISo62mJJ2RdRLUg_LsrhapCgVNJ0W3yQ&e= > > In this comment: > > ! * in use, you can pass the length of that in n, to ensure > ! * we detect if any path exceeds the maximum path length > ! * once prepended onto the sub-path/file name. > * It is the callers responsibility to: > * a> check the value of n, and n may be 0. > > the three references to 'n' should be to the new file_name_length parameter. > > Looking at the test: > > 2 * Copyright (c) 2019, 2019, Oracle and/or its affiliates. All > rights reserved. > > For a new file there is only a single year specified so this should be: > > 2 * Copyright (c) 2019, Oracle and/or its affiliates. All rights > reserved. > > 31 * @run main TestSunBootLibraryPath > > As this just launches another VM it is more efficient to use "@run driver". > > 35 import java.lang.IllegalArgumentException; > > Nit: java.lang.* is implicitly imported. > > 39 static String expectedErrorMessage =("The VM tried to use a > path that exceeds the maximum path length for " > 40 + "this system. Review > path-containing parameters and properties, such as " > 41 + "sun.boot.library.path, to > identify potential sources for this path."); > > Nit: no need for parentheses. > > Probably also no need to check for the entire message - the first line > should suffice. > > 48 //Add enough characters to make it "too long". > 49 for (int i = 0 ; i < tooLongPathSize ; i++) tooLongPath > += "a"; > > This can be done more efficiently and succinctly as: > > tooLongPath += "a".repeat(5000); > > There's probably an even better way. :) > > 60 throw new java.lang.IllegalArgumentException("Test was > launched with an invalid argument."); > > No need to specify "java.lang". > > Thanks, > David > ----- > > > I made the requested changes, and moved the null check as suggested. > > > > (I agree passing a null for any of these values would be odd, and > > unlikely to be done on purpose.) > > > > It also includes a new jtreg test for this change, which uses ProcessTools. > > > > Let me know what you think (inc Serguei + others). > > > > Best Regards > > > > Adam Farley > > IBM Runtimes > > > > > > coleen.phillimore at oracle.com wrote on 16/08/2019 23:59:53: > > > >> From: coleen.phillimore at oracle.com > >> To: Adam Farley8 > >> Cc: David Holmes , hotspot-dev at openjdk.java.net > >> Date: 17/08/2019 00:00 > >> Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > >> paths are longer than JVM_MAXPATHLEN > >> > >> > > > >> On 8/16/19 7:35 AM, Adam Farley8 wrote: > >> Hi Coleen, > >> > >> To confirm your suspicions, I didn't see your responses. No > offence intended. > >> > >> I send a lot of mail so I'm sure I can be caught in people's spamfilter. :) > >> > >> > >> Responses below. > >> > >> Best Regards > >> > >> Adam Farley > >> IBM Runtimes > >> > >> > >> coleen.phillimore at oracle.com wrote on 15/08/2019 13:42:51: > >> > >> > From: coleen.phillimore at oracle.com > >> > To: hotspot-dev at openjdk.java.net, Adam Farley8 > >> > , David Holmes > >> > Date: 15/08/2019 13:43 > >> > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > >> > paths are longer than JVM_MAXPATHLEN > >> > > >> > Hi Adam, David noticed that my code review replies only went to the > >> > mailing list. So here it is again. > >> > Thanks, > >> > Coleen > >> > > >> > On 8/13/19 5:29 PM, coleen.phillimore at oracle.com wrote: > >> > > > >> > > > >> > > On 8/13/19 11:48 AM, Adam Farley8 wrote: > >> > >> Hi David, > >> > >> > >> > >> Since we have two positive reviews (yours and Serguei's), could you > >> > >> sponsor the change please? > >> > > > >> > > If you get two positive reviews, but then one with comments, you need > >> > > to also answer that third reviews. I had some comments on your > >> > > change, which I'll repeat here: > >> > > > >> > > > >> > > https://urldefense.proofpoint.com/v2/url? > >> > u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021. > >> > > >> > 2_webrev_src_hotspot_share_runtime_os.cpp.frames.html&d=DwIDaQ&c=jf_iaSHvJObTbx- > >> > siA1ZOg&r=P5m8KWUXJf- > >> > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=wjd3KxxgFQv49yjlb4Bndy- > >> > F1XV4pbuPZrmemiaFthA&s=xXwflqvuzoEhcREhr-x7rNMVDeroZ8Xh1LnW6NytumE&e= > >> > > > >> > > > >> > > This is code is unnecessarily hard to read and understand: > >> > > > >> > > 1329 char** os::split_path(const char* path, size_t* n) { > >> > > 1330 size_t pathmod = (size_t)0; > >> > > 1331 if (n != NULL) { > >> > > 1332 pathmod = *n; > >> > > 1333 } > >> > > 1334 *n = (size_t)0; > >> > > > >> > > It appears that 'n' is both an input and output parameter of this > >> > > function. Can you just make it another input parameter with some > >> > > descriptive name. Is it the length of the library name that you're > >> > > looking for? "pathmod" is huh? > >> > >> The 'n' is both an input and an output, yes. > >> > >> I could make it another input parameter, but that means modifying the > >> method signature. This seemed unnecessary, given that we have an input > >> vector we're not using for anything. > >> > >> It's not a big deal to add a parameter, especially since there's > >> only one call site, and the names don't have to be squished up C names. > >> > >> How about: char** split_path(char* path, size_t file_length, > >> size_t* elements) ? > > > >> > >> > >> The 'n' input is used as a modifier for the length of the path, as > >> mentioned in the comment. I called it "pathmod" because it's a PATH > >> length MODIFIER. I couldn't think of a better name that's also concise. > >> Would pathlenmod be better? Pathsizemod sounds like we're making the path > >> physically bigger, or maybe that's just me. :) > >> > >> > > > >> > > Then you don't have to check if someone has passed NULL. There's only > >> > > one caller to this from what I see. > >> > >> I'm not sure I understand this. We'd still need to check for null, even if > >> the pathmod has its own input parameter. I believe adding a NULL to an int > >> causes a segmentation error at runtime. > >> > >> If you're saying the null check isn't needed because we can > ensure anon-null > >> is passed in via the only place we call split_path, I disagree > that this is a > >> future-proof assumption. A null check seems prudent here. > >> > >> I think the function doesn't make any sense if you pass an output > >> parameter as NULL. Or at worst you could add it to the line: > >> > >> 1335 if (path == NULL || strlen(path) == 0 || n == NULL) { > >> 1336 return NULL; > >> 1337 } > >> 1334 *n = (size_t)0; > >> > >> But that's just weird. Why would a caller pass a non-null path and > >> not want the element count? > >> > >> Thanks, > >> Coleen > >> > >> > >> > > > >> > > 1352 char** opath = (char**) NEW_C_HEAP_ARRAY(char*, count, > >> > > mtInternal); > >> > > 1353 if (opath == NULL) { > >> > > 1354 return NULL; > >> > > 1355 } > >> > > > >> > > > >> > > Not your change but this calls vm_exit_out_of_memory() if > >> > > NEW_C_HEAP_ARRAY fails. It doesn't return NULL so you don't have to > >> > > check. > >> > >> Seems legit. I'll include this in the .5 version once we have consensus on > >> the other changes. Good spot. > >> > >> > > > >> > > 1375 char* s = (char*)NEW_C_HEAP_ARRAY(char, len + 1, > mtInternal); > >> > > > >> > > Here you want to use NEW_C_HEAP_ARRAY_RETURN_NULL so you cancheck for > >> > > null and free memory. > >> > >> Good idea. Noted for .5. > >> > >> Let me know your thoughts on the other points above. > >> > >> > >> > > > >> > > > >> > > The rest seems okay. > >> > > > >> > > thanks, > >> > > Coleen > >> > > > >> > >> > >> > >> Best Regards > >> > >> > >> > >> Adam Farley > >> > >> IBM Runtimes > >> > >> > >> > >> > >> > >> David Holmes wrote on 12/08/2019 23:32:14: > >> > >> > >> > >>> From: David Holmes > >> > >>> To: Adam Farley8 > >> > >>> Cc: hotspot-dev at openjdk.java.net, "serguei.spitsyn at oracle.com" > >> > >>> > >> > >>> Date: 12/08/2019 23:32 > >> > >>> Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > >> > >>> paths are longer than JVM_MAXPATHLEN > >> > >>> > >> > >>> Looks fine. > >> > >>> > >> > >>> Thanks, > >> > >>> David > >> > >>> > >> > >>> On 13/08/2019 1:19 am, Adam Farley8 wrote: > >> > >>>> Hi David, > >> > >>>> > >> > >>>> Changes made as requested: > >> > >>>> https://urldefense.proofpoint.com/v2/url? > >> > >>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.4_webrev&d=DwID- > >> > >>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > >> > >>> > >> > >> > >> > > >> > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=mZM8IR4e_zmrfcsF3XJjoGEMrZb4WtEL7Y6Ugd6Naqg&s=sZ2UKqqUIq0El- > >> > >> > >> > >>> RsqYz6jmTh4Q2UghwdrQX6of8Lw0E&e= > >> > >>>> Best Regards > >> > >>>> > >> > >>>> Adam Farley > >> > >>>> IBM Runtimes > >> > >>>> > >> > >>>> > >> > >>>> David Holmes wrote on 12/08/ > 2019 04:55:36: > >> > >>>> > >> > >>>>> From: David Holmes > >> > >>>>> To: Adam Farley8 , > >> > >>>>> "serguei.spitsyn at oracle.com" > >> > >>>>> Cc: hotspot-dev at openjdk.java.net > >> > >>>>> Date: 12/08/2019 04:56 > >> > >>>>> Subject: Re: RFR: JDK-8227021: VM fails if any > sun.boot.library.path > >> > >>>>> paths are longer than JVM_MAXPATHLEN > >> > >>>>> > >> > >>>>> Hi Adam, > >> > >>>>> > >> > >>>>> On 10/08/2019 2:47 am, Adam Farley8 wrote: > >> > >>>>>> Hi Serguei, David, > >> > >>>>>> > >> > >>>>>> My turn to apologise for the delay. :) > >> > >>>>>> > >> > >>>>>> I've modified the code as per Serguei's request. Take alook and > >> > >> let me > >> > >>>>>> know if this is the sort of thing you were thinking of. > >> > >>>>>> > >> > >>>>>> Webrev: https://urldefense.proofpoint.com/v2/url? > >> > >>>>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.3_webrev_&d=DwID- > >> > >>>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > >> > >>>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > >> > >>>>> > >> > >> > >> > > >> > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=L19aeFXoR9JIO62QRPFzZObIU8RbhpCtXSvUibD2ISk&e= > >> > >> > >> > >>>>> I'd prefer to see the helper just as a file static function rather > >> > >> than > >> > >>>>> adding it to the os class. > >> > >>>>> > >> > >>>>> + * supplied array of arrays of chars (a), where n > >> > >>>>> > >> > >>>>> I assume (a) is meant to refer to the parameter, but you actually > >> > >> called > >> > >>>>> it arrayarray. I think "a" or "arr" would suffice. > >> > >>>>> > >> > >>>>> Thanks, > >> > >>>>> David > >> > >>>>> > >> > >>>>>> Best Regards > >> > >>>>>> > >> > >>>>>> Adam Farley > >> > >>>>>> IBM Runtimes > >> > >>>>>> > >> > >>>>>> > >> > >>>>>> "serguei.spitsyn at oracle.com" > wrote on > >> > >>>>>> 31/07/2019 17:18:05: > >> > >>>>>> > >> > >>>>>>> From: "serguei.spitsyn at oracle.com" > >> > >>>>>>> To: Adam Farley8 , David Holmes > >> > >>>>>>> > >> > >>>>>>> Cc: serviceability-dev , > >> > >>>>>>> hotspot-dev at openjdk.java.net > >> > >>>>>>> Date: 31/07/2019 17:18 > >> > >>>>>>> Subject: Re: RFR: JDK-8227021: VM fails if any > >> > >> sun.boot.library.path > >> > >>>>>>> paths are longer than JVM_MAXPATHLEN > >> > >>>>>>> > >> > >>>>>>> Hi Adam, > >> > >>>>>>> > >> > >>>>>>> It looks Okay to me. > >> > >>>>>>> > >> > >>>>>>> A couple of minor comments. > >> > >>>>>>> > >> > >>>>>>> https://urldefense.proofpoint.com/v2/url? > >> > >>>>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021. > >> > >>>>> 2_webrev_src_hotspot_&d=DwID-g&c=jf_iaSHvJObTbx- > >> > >>>>> siA1ZOg&r=P5m8KWUXJf-CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > >> > >>>>> > >> > >> > >> > > >> > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NL6tYuwwDod3DSmj-1ztxAywpO8L52HEyO0wvTR05bs&e= > >> > >> > >> > >>>>>>> share/runtime/os.cpp.frames.html > >> > >>>>>>> 1362 //release allocated storage before exiting the vm > >> > >>>>>>> 1363 while (i > 0) { > >> > >>>>>>> 1364 i--; > >> > >>>>>>> 1365 if (opath[i] != NULL) { > >> > >>>>>>> 1366 FREE_C_HEAP_ARRAY(char, opath[i]); > >> > >>>>>>> 1367 } > >> > >>>>>>> 1368 } > >> > >>>>>>> 1369 FREE_C_HEAP_ARRAY(char*, opath); > >> > >>>>>>> > >> > >>>>>>> 1377 //release allocated storage before returning null > >> > >>>>>>> 1378 while (i > 0) { > >> > >>>>>>> 1379 i--; > >> > >>>>>>> 1380 if (opath[i] != NULL) { > >> > >>>>>>> 1381 FREE_C_HEAP_ARRAY(char, opath[i]); > >> > >>>>>>> 1382 } > >> > >>>>>>> 1383 } > >> > >>>>>>> 1384 FREE_C_HEAP_ARRAY(char*, opath); > >> > >>>>>>> > >> > >>>>>>> This duplicated fragments is worth to refactor to a function. > >> > >>>>>>> Also a space is missed at the beginning of the comment. > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> Thanks, > >> > >>>>>>> Serguei > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> On 7/31/19 02:01, Adam Farley8 wrote: > >> > >>>>>>> Hi All, > >> > >>>>>>> > >> > >>>>>>> Reviewers requested for the change below. > >> > >>>>>>> > >> > >>>>>>> @David - Agreed. Would you be prepared to sponsor the change? > >> > >>>>>>> > >> > >>>>>>> Bug: https://urldefense.proofpoint.com/v2/url? > >> > >>>>> u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8227021&d=DwID- > >> > >>>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > >> > >>>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > >> > >>>>> > >> > >> > >> > > >> > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=xykJ0KLy9AKWO8zmC0amfR7xxUsvyKEjlf3y7WWOqvE&e= > >> > >> > >> > >>>>>>> Webrev: https://urldefense.proofpoint.com/v2/url? > >> > >>>>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.2_webrev_&d=DwID- > >> > >>>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > >> > >>>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > >> > >>>>> > >> > >> > >> > > >> > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NvIza4VVWG3CiDhmQVmXsghH_4h_c5mFJbHwkCUcut0&e= > >> > >> > >> > >>>>>>> Best Regards > >> > >>>>>>> > >> > >>>>>>> Adam Farley > >> > >>>>>>> IBM Runtimes > >> > >>>>>>> > >> > >>>>>>> P.S. Remembered to add the links this time. :) > >> > >>>>>>> > >> > >>>>>>> > >> > >>>>>>> David Holmes wrote on 30/07/2019 > >> > >> 03:37:53: > >> > >>>>>>>> From: David Holmes > >> > >>>>>>>> To: Adam Farley8 > >> > >>>>>>>> Cc: hotspot-dev at openjdk.java.net, serviceability-dev > >> > >>>>>>>> > >> > >>>>>>>> Date: 30/07/2019 03:38 > >> > >>>>>>>> Subject: Re: RFR: JDK-8227021: VM fails if any > >> > >> sun.boot.library.path > >> > >>>>>>>> paths are longer than JVM_MAXPATHLEN > >> > >>>>>>>> > >> > >>>>>>>> Hi Adam, > >> > >>>>>>>> > >> > >>>>>>>> On 25/07/2019 3:57 am, Adam Farley8 wrote: > >> > >>>>>>>>> Hi David, > >> > >>>>>>>>> > >> > >>>>>>>>> Welcome back. :) > >> > >>>>>>>> Thanks. Sorry for the delay in getting back to this. > >> > >>>>>>>> > >> > >>>>>>>> I like .v2 as it is much simpler (notwithstanding freeing > >> > >>> the already > >> > >>>>>>>> allocated arrays adds some complexity - thanks for > fixing that). > >> > >>>>>>>> > >> > >>>>>>>> I'm still not sure we can't optimise things better for > >> > >> unchangeable > >> > >>>>>>>> properties like the boot libary path, but that's another RFE. > >> > >>>>>>>> > >> > >>>>>>>> Thanks, > >> > >>>>>>>> David > >> > >>>>>>>> > >> > >>>>>>> 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 > >> > >> 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 > 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 coleen.phillimore at oracle.com Tue Aug 20 13:27:09 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 20 Aug 2019 09:27:09 -0400 Subject: RFR: JDK-8227021: VM fails if any sun.boot.library.path paths are longer than JVM_MAXPATHLEN In-Reply-To: References: <5ba808b0-ae52-0d0a-b84b-fc34df35475d@oracle.com> <025da83a-6569-f6ac-7590-5b200ed2344f@oracle.com> <8e62fc61-b46b-0033-f182-cb4a2dbf92fd@oracle.com> <4f892f24-4919-4f3a-7e62-0603e08561cc@oracle.com> <4b195206-7a33-4f68-4207-fd214793cf28@oracle.com> Message-ID: <9daaf003-fe92-3c3a-9933-47d9b12f2ad9@oracle.com> This looks great.? Thank you for making the changes. One tiny thing that I don't want to see another webrev for.? Can you change: +/* + * Frees all memory allocated on the heap for the + * supplied array of arrays of chars (a), where n + * is the number of elements in the array. + */ to +// +// Frees all memory allocated on the heap for the +// supplied array of arrays of chars (a), where n +// is the number of elements in the array. +// And the big comment to have // at the top of split_path? We prefer // comments in the code.? Do you need a sponsor? Thanks, Coleen On 8/20/19 9:13 AM, Adam Farley8 wrote: > Hi David, > > Good advice. Changes made as requested. > > Webrev: http://cr.openjdk.java.net/~afarley/8227021.6/webrev/ > > Does anyone have further concerns or changes to propose? > > Best Regards > > Adam Farley > IBM Runtimes > > > David Holmes wrote on 20/08/2019 12:55:26: > > > From: David Holmes > > To: Adam Farley8 , coleen.phillimore at oracle.com > > Cc: hotspot-dev at openjdk.java.net > > Date: 20/08/2019 12:55 > > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > > paths are longer than JVM_MAXPATHLEN > > > > Hi Adam, > > > > On 20/08/2019 1:21 am, Adam Farley8 wrote: > > > Hi Coleen, David, > > > > > > Here's the new webrev: https://urldefense.proofpoint.com/v2/url? > > u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.5_webrev_&d=DwID- > > g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=zaU5bibnUdHVncMttyVGbYf1yzDRUt26f9raqqKlJm0&s=QPe5l0tueNKISo62mJJ2RdRLUg_LsrhapCgVNJ0W3yQ&e= > > > > In this comment: > > > > ! ?* in use, you can pass the length of that in n, to ensure > > ! ?* we detect if any path exceeds the maximum path length > > ! ?* once prepended onto the sub-path/file name. > > ? ? * It is the callers responsibility to: > > ? ? * ? a> check the value of n, and n may be 0. > > > > the three references to 'n' should be to the new file_name_length > parameter. > > > > Looking at the test: > > > > ? ?2 ?* Copyright (c) 2019, 2019, Oracle and/or its affiliates. All > > rights reserved. > > > > For a new file there is only a single year specified so this should be: > > > > ? ?2 ?* Copyright (c) 2019, Oracle and/or its affiliates. All rights > > reserved. > > > > ? 31 ?* @run main TestSunBootLibraryPath > > > > As this just launches another VM it is more efficient to use "@run > driver". > > > > ? 35 import java.lang.IllegalArgumentException; > > > > Nit: java.lang.* is implicitly imported. > > > > ? 39 ? ? static String expectedErrorMessage =("The VM tried to use a > > path that exceeds the maximum path length for " > > ? 40 ? ? ? ? ? ? ? ? ? + "this system. Review > > path-containing parameters and properties, such as " > > ? 41 ? ? ? ? ? ? ? ? ? + "sun.boot.library.path, to > > identify potential sources for this path."); > > > > Nit: no need for parentheses. > > > > Probably also no need to check for the entire message - the first line > > should suffice. > > > > ? 48 ? ? ? ? ? ? //Add enough characters to make it "too long". > > ? 49 ? ? ? ? ? ? for (int i = 0 ; i < tooLongPathSize ; i++) > tooLongPath > > += "a"; > > > > This can be done more efficiently and succinctly as: > > > > tooLongPath += "a".repeat(5000); > > > > There's probably an even better way. :) > > > > ? 60 ? ? ? ? ? ? throw new java.lang.IllegalArgumentException("Test was > > launched with an invalid argument."); > > > > No need to specify "java.lang". > > > > Thanks, > > David > > ----- > > > > > I made the requested changes, and moved the null check as suggested. > > > > > > (I agree passing a null for any of these values would be odd, and > > > unlikely to be done on purpose.) > > > > > > It also includes a new jtreg test for this change, which uses > ProcessTools. > > > > > > Let me know what you think (inc Serguei + others). > > > > > > Best Regards > > > > > > Adam Farley > > > IBM Runtimes > > > > > > > > > coleen.phillimore at oracle.com wrote on 16/08/2019 23:59:53: > > > > > >> From: coleen.phillimore at oracle.com > > >> To: Adam Farley8 > > >> Cc: David Holmes , > ?hotspot-dev at openjdk.java.net > > >> Date: 17/08/2019 00:00 > > >> Subject: Re: RFR: JDK-8227021: ?VM fails if any sun.boot.library.path > > >> paths are longer than JVM_MAXPATHLEN > > >> > > >> > > > > > >> On 8/16/19 7:35 AM, Adam Farley8 ?wrote: > > >> Hi Coleen, > > >> > > >> To confirm your suspicions, I didn't see your responses. No > > offence ?intended. > > >> > > >> I send a lot of mail so I'm sure I can be caught in people's > spamfilter. :) > > >> > > >> > > >> Responses below. > > >> > > >> Best Regards > > >> > > >> Adam Farley > > >> IBM Runtimes > > >> > > >> > > >> coleen.phillimore at oracle.com wrote on 15/08/2019 13:42:51: > > >> > > >> > From: coleen.phillimore at oracle.com > > >> > To: hotspot-dev at openjdk.java.net, Adam Farley8 > > >> > , David Holmes > > >> > Date: 15/08/2019 13:43 > > >> > Subject: Re: RFR: JDK-8227021: VM fails if any > sun.boot.library.path > > >> > paths are longer than JVM_MAXPATHLEN > > >> > > > >> > Hi Adam,? David noticed that my code review replies only ?went > to the > > >> > mailing list.? So here it is again. > > >> > Thanks, > > >> > Coleen > > >> > > > >> > On 8/13/19 5:29 PM, coleen.phillimore at oracle.com wrote: > > >> > > > > >> > > > > >> > > On 8/13/19 11:48 AM, Adam Farley8 wrote: > > >> > >> Hi David, > > >> > >> > > >> > >> Since we have two positive reviews (yours and Serguei's), > ?could you > > >> > >> sponsor the change please? > > >> > > > > >> > > If you get two positive reviews, but then one with comments, > ?you need > > >> > > to also answer that third reviews.? I had some comments ?on your > > >> > > change, which I'll repeat here: > > >> > > > > >> > > > > >> > > https://urldefense.proofpoint.com/v2/url? > > >> > u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021. > > >> > > > >> > > > 2_webrev_src_hotspot_share_runtime_os.cpp.frames.html&d=DwIDaQ&c=jf_iaSHvJObTbx- > > >> > siA1ZOg&r=P5m8KWUXJf- > > >> > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=wjd3KxxgFQv49yjlb4Bndy- > > >> > > F1XV4pbuPZrmemiaFthA&s=xXwflqvuzoEhcREhr-x7rNMVDeroZ8Xh1LnW6NytumE&e= > > >> > > > > >> > > > > >> > > This is code is unnecessarily hard to read and understand: > > >> > > > > >> > > 1329 char** os::split_path(const char* path, size_t* n) ?{ > > >> > > 1330 size_t pathmod = (size_t)0; > > >> > > 1331 if (n != NULL) { > > >> > > 1332 pathmod = *n; > > >> > > 1333 } > > >> > > 1334 *n = (size_t)0; > > >> > > > > >> > > It appears that 'n' is both an input and output parameter ?of > this > > >> > > function.? Can you just make it another input parameter ?with > some > > >> > > descriptive name.? Is it the length of the library ?name that > you're > > >> > > looking for?? "pathmod" is huh? > > >> > > >> The 'n' is both an input and an output, yes. > > >> > > >> I could make it another input parameter, but that means modifying > ?the > > >> method signature. This seemed unnecessary, given that we have an > input > > >> vector we're not using for anything. > > >> > > >> It's not a big deal to add a parameter, especially since there's > > >> only one call site, and the names don't have to be squished up C > names. > > >> > > >> How about:? char** split_path(char* path, size_t file_length, > > >> size_t* elements) ? > > > > > >> > > >> > > >> The 'n' input is used as a modifier for the length of the path, as > > >> mentioned in the comment. I called it "pathmod" because ?it's a PATH > > >> length MODIFIER. I couldn't think of a better name that's also > concise. > > >> Would pathlenmod be better? Pathsizemod sounds like we're making > the ?path > > >> physically bigger, or maybe that's just me. :) > > >> > > >> > > > > >> > > Then you don't have to check if someone has passed NULL. > There's only > > >> > > one caller to this from what I see. > > >> > > >> I'm not sure I understand this. We'd still need to check for > null, ?even if > > >> the pathmod has its own input parameter. I believe adding a NULL > to ?an int > > >> causes a segmentation error at runtime. > > >> > > >> If you're saying the null check isn't needed because we can > > ensure ?anon-null > > >> is passed in via the only place we call split_path, I disagree > > that ?this is a > > >> future-proof assumption. A null check seems prudent here. > > >> > > >> I think the function doesn't make any sense if you pass an output > > >> parameter as NULL.? Or at worst you could add it to the line: > > >> > > >> 1335 if (path == NULL || strlen(path) == 0 || n == NULL) { > > >> 1336 ? ?? return NULL; > > >> 1337 } > > >> 1334 *n = (size_t)0; > > >> > > >> But that's just weird. Why would a caller pass a non-null path and > > >> not want the element count? > > >> > > >> Thanks, > > >> Coleen > > >> > > >> > > >> > > > > >> > > 1352?? char** opath = (char**) NEW_C_HEAP_ARRAY(char*, ?count, > > >> > > mtInternal); > > >> > > 1353?? if (opath == NULL) { > > >> > > 1354???? return NULL; > > >> > > 1355?? } > > >> > > > > >> > > > > >> > > Not your change but this calls vm_exit_out_of_memory() if > > >> > > NEW_C_HEAP_ARRAY fails.? It doesn't return NULL so ?you don't > have to > > >> > > check. > > >> > > >> Seems legit. I'll include this in the .5 version once we have > consensus ?on > > >> the other changes. Good spot. > > >> > > >> > > > > >> > > 1375???? char* s? = (char*)NEW_C_HEAP_ARRAY(char, ?len + 1, > > mtInternal); > > >> > > > > >> > > Here you want to use NEW_C_HEAP_ARRAY_RETURN_NULL so you > ?cancheck for > > >> > > null and free memory. > > >> > > >> Good idea. Noted for .5. > > >> > > >> Let me know your thoughts on the other points above. > > >> > > >> > > >> > > > > >> > > > > >> > > The rest seems okay. > > >> > > > > >> > > thanks, > > >> > > Coleen > > >> > > > > >> > >> > > >> > >> Best Regards > > >> > >> > > >> > >> Adam Farley > > >> > >> IBM Runtimes > > >> > >> > > >> > >> > > >> > >> David Holmes wrote on ?12/08/2019 > 23:32:14: > > >> > >> > > >> > >>> From: David Holmes > > >> > >>> To: Adam Farley8 > > >> > >>> Cc: hotspot-dev at openjdk.java.net, "serguei.spitsyn at oracle.com" > > >> > >>> > > >> > >>> Date: 12/08/2019 23:32 > > >> > >>> Subject: Re: RFR: JDK-8227021: VM fails if any > sun.boot.library.path > > >> > >>> paths are longer than JVM_MAXPATHLEN > > >> > >>> > > >> > >>> Looks fine. > > >> > >>> > > >> > >>> Thanks, > > >> > >>> David > > >> > >>> > > >> > >>> On 13/08/2019 1:19 am, Adam Farley8 wrote: > > >> > >>>> Hi David, > > >> > >>>> > > >> > >>>> Changes made as requested: > > >> > >>>> https://urldefense.proofpoint.com/v2/url? > > >> > >>> > u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.4_webrev&d=DwID- > > >> > >>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > >> > >>> > > >> > >> > > >> > > > >> > > > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=mZM8IR4e_zmrfcsF3XJjoGEMrZb4WtEL7Y6Ugd6Naqg&s=sZ2UKqqUIq0El- > > >> > >> > > >> > >>> RsqYz6jmTh4Q2UghwdrQX6of8Lw0E&e= > > >> > >>>> Best Regards > > >> > >>>> > > >> > >>>> Adam Farley > > >> > >>>> IBM Runtimes > > >> > >>>> > > >> > >>>> > > >> > >>>> David Holmes ?wrote on 12/08/ > > 2019 04:55:36: > > >> > >>>> > > >> > >>>>> From: David Holmes > > >> > >>>>> To: Adam Farley8 , > > >> > >>>>> "serguei.spitsyn at oracle.com" > > >> > >>>>> Cc: hotspot-dev at openjdk.java.net > > >> > >>>>> Date: 12/08/2019 04:56 > > >> > >>>>> Subject: Re: RFR: JDK-8227021: VM ?fails if any > > sun.boot.library.path > > >> > >>>>> paths are longer than JVM_MAXPATHLEN > > >> > >>>>> > > >> > >>>>> Hi Adam, > > >> > >>>>> > > >> > >>>>> On 10/08/2019 2:47 am, Adam Farley8 wrote: > > >> > >>>>>> Hi Serguei, David, > > >> > >>>>>> > > >> > >>>>>> My turn to apologise for the delay. ?:) > > >> > >>>>>> > > >> > >>>>>> I've modified the code as per Serguei's ?request. Take > alook? and > > >> > >> let me > > >> > >>>>>> know if this is the sort of thing you ?were thinking of. > > >> > >>>>>> > > >> > >>>>>> Webrev: https://urldefense.proofpoint.com/v2/url? > > >> > >>>>> > u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.3_webrev_&d=DwID- > > >> > >>>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > >> > >>>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > > >> > >>>>> > > >> > >> > > >> > > > >> > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=L19aeFXoR9JIO62QRPFzZObIU8RbhpCtXSvUibD2ISk&e= > > >> > >> > > >> > >>>>> I'd prefer to see the helper just as a file ?static > function rather > > >> > >> than > > >> > >>>>> adding it to the os class. > > >> > >>>>> > > >> > >>>>> +? * supplied array of arrays of chars ?(a), where n > > >> > >>>>> > > >> > >>>>> I assume (a) is meant to refer to the parameter, ?but you > actually > > >> > >> called > > >> > >>>>> it arrayarray. I think "a" or ?"arr" would suffice. > > >> > >>>>> > > >> > >>>>> Thanks, > > >> > >>>>> David > > >> > >>>>> > > >> > >>>>>> Best Regards > > >> > >>>>>> > > >> > >>>>>> Adam Farley > > >> > >>>>>> IBM Runtimes > > >> > >>>>>> > > >> > >>>>>> > > >> > >>>>>> "serguei.spitsyn at oracle.com" > > ? wrote on > > >> > >>>>>> 31/07/2019 17:18:05: > > >> > >>>>>> > > >> > >>>>>>> From: "serguei.spitsyn at oracle.com" > ? > > >> > >>>>>>> To: Adam Farley8 , ?David? Holmes > > >> > >>>>>>> > > >> > >>>>>>> Cc: serviceability-dev > , > > >> > >>>>>>> hotspot-dev at openjdk.java.net > > >> > >>>>>>> Date: 31/07/2019 17:18 > > >> > >>>>>>> Subject: Re: RFR: JDK-8227021: VM fails if any > > >> > >> sun.boot.library.path > > >> > >>>>>>> paths are longer than JVM_MAXPATHLEN > > >> > >>>>>>> > > >> > >>>>>>> Hi Adam, > > >> > >>>>>>> > > >> > >>>>>>> It looks Okay to me. > > >> > >>>>>>> > > >> > >>>>>>> A couple of minor comments. > > >> > >>>>>>> > > >> > >>>>>>> https://urldefense.proofpoint.com/v2/url? > > >> > >>>>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021. > > >> > >>>>> 2_webrev_src_hotspot_&d=DwID-g&c=jf_iaSHvJObTbx- > > >> > >>>>> > siA1ZOg&r=P5m8KWUXJf-CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > > >> > >>>>> > > >> > >> > > >> > > > >> > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NL6tYuwwDod3DSmj-1ztxAywpO8L52HEyO0wvTR05bs&e= > > >> > >> > > >> > >>>>>>> share/runtime/os.cpp.frames.html > > >> > >>>>>>> 1362 ?//release allocated storage? before exiting the vm > > >> > >>>>>>> 1363 ?while (i > 0) { > > >> > >>>>>>> 1364 ? ?i--; > > >> > >>>>>>> 1365 ? ?if (opath[i] != NULL)? { > > >> > >>>>>>> 1366 ? ? ?FREE_C_HEAP_ARRAY(char,?? opath[i]); > > >> > >>>>>>> 1367 ? ?} > > >> > >>>>>>> 1368 ? ? ?} > > >> > >>>>>>> 1369 ?FREE_C_HEAP_ARRAY(char*, opath); > > >> > >>>>>>> > > >> > >>>>>>> 1377 ?//release allocated storage before returning? null > > >> > >>>>>>> 1378 ?while (i > 0) { > > >> > >>>>>>> 1379 ? ?i--; > > >> > >>>>>>> 1380 ? ?if (opath[i] != NULL)? { > > >> > >>>>>>> 1381 ? ? ?FREE_C_HEAP_ARRAY(char,?? opath[i]); > > >> > >>>>>>> 1382 ? ?} > > >> > >>>>>>> 1383 ? ? ?} > > >> > >>>>>>> 1384 ?FREE_C_HEAP_ARRAY(char*, opath); > > >> > >>>>>>> > > >> > >>>>>>> This duplicated fragments is worth ?to refactor to a > function. > > >> > >>>>>>> Also a space is missed at the beginning ?of the comment. > > >> > >>>>>>> > > >> > >>>>>>> > > >> > >>>>>>> Thanks, > > >> > >>>>>>> Serguei > > >> > >>>>>>> > > >> > >>>>>>> > > >> > >>>>>>> > > >> > >>>>>>> On 7/31/19 02:01, Adam Farley8 wrote: > > >> > >>>>>>> Hi All, > > >> > >>>>>>> > > >> > >>>>>>> Reviewers requested for the change ?below. > > >> > >>>>>>> > > >> > >>>>>>> @David - Agreed. Would you be prepared ?to sponsor the > change? > > >> > >>>>>>> > > >> > >>>>>>> Bug: https://urldefense.proofpoint.com/v2/url? > > >> > >>>>> > u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8227021&d=DwID- > > >> > >>>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > >> > >>>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > > >> > >>>>> > > >> > >> > > >> > > > >> > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=xykJ0KLy9AKWO8zmC0amfR7xxUsvyKEjlf3y7WWOqvE&e= > > >> > >> > > >> > >>>>>>> Webrev: https://urldefense.proofpoint.com/v2/url? > > >> > >>>>> > u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.2_webrev_&d=DwID- > > >> > >>>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > >> > >>>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > > >> > >>>>> > > >> > >> > > >> > > > >> > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NvIza4VVWG3CiDhmQVmXsghH_4h_c5mFJbHwkCUcut0&e= > > >> > >> > > >> > >>>>>>> Best Regards > > >> > >>>>>>> > > >> > >>>>>>> Adam Farley > > >> > >>>>>>> IBM Runtimes > > >> > >>>>>>> > > >> > >>>>>>> P.S. Remembered to add the links ?this time. :) > > >> > >>>>>>> > > >> > >>>>>>> > > >> > >>>>>>> David Holmes ?wrote on 30/07/2019 > > >> > >> 03:37:53: > > >> > >>>>>>>> From: David Holmes > > >> > >>>>>>>> To: Adam Farley8 > > >> > >>>>>>>> Cc: hotspot-dev at openjdk.java.net, ?serviceability-dev > > >> > >>>>>>>> > > >> > >>>>>>>> Date: 30/07/2019 03:38 > > >> > >>>>>>>> Subject: Re: RFR: JDK-8227021: ?VM fails if any > > >> > >> sun.boot.library.path > > >> > >>>>>>>> paths are longer than JVM_MAXPATHLEN > > >> > >>>>>>>> > > >> > >>>>>>>> Hi Adam, > > >> > >>>>>>>> > > >> > >>>>>>>> On 25/07/2019 3:57 am, Adam ?Farley8 wrote: > > >> > >>>>>>>>> Hi David, > > >> > >>>>>>>>> > > >> > >>>>>>>>> Welcome back. :) > > >> > >>>>>>>> Thanks. Sorry for the delay ?in getting back to this. > > >> > >>>>>>>> > > >> > >>>>>>>> I like .v2 as it is much simpler ?(notwithstanding freeing > > >> > >>> the? already > > >> > >>>>>>>> allocated arrays adds some complexity ?- thanks for > > fixing that). > > >> > >>>>>>>> > > >> > >>>>>>>> I'm still not sure we can't ?optimise things better for > > >> > >> unchangeable > > >> > >>>>>>>> properties like the boot libary ?path, but that's > another? RFE. > > >> > >>>>>>>> > > >> > >>>>>>>> Thanks, > > >> > >>>>>>>> David > > >> > >>>>>>>> > > >> > >>>>>>> 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 > > >> > >> 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 > > > > 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 coleen.phillimore at oracle.com Tue Aug 20 13:51:13 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 20 Aug 2019 09:51:13 -0400 Subject: RFR: 8229836: Remove include of globals.hpp from allocation.hpp In-Reply-To: <5abdb28e-3658-d7d1-20b0-000898818f42@oracle.com> References: <5abdb28e-3658-d7d1-20b0-000898818f42@oracle.com> Message-ID: <9ff477f2-8aef-fa59-098a-7f5652d031cd@oracle.com> On 8/20/19 8:09 AM, Stefan Karlsson wrote: > Hi all, > > Please review this patch to remove the include of globals.hpp from > allocation.hpp. > > http://cr.openjdk.java.net/~stefank/8229836/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8229836 > > Note this change is just the bare minimum to get it to compile on our > build platforms. I haven't tried to find all files that are missing > explicit includes of globals.hpp. http://cr.openjdk.java.net/~stefank/8229836/webrev.01/src/hotspot/share/oops/oopsHierarchy.hpp.udiff.html Is it because globals.hpp was transitively included, that the extern "C" wasn't needed?? Without extern "C" will it mangle the name? This looks like it doesn't need someone else to review it and can be considered trivial.? It doesn't seem to affect the cpu directories so seems unlikely to break other platforms. thanks, Coleen > > Thanks, > StefanK From adam.farley at uk.ibm.com Tue Aug 20 15:06:48 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Tue, 20 Aug 2019 16:06:48 +0100 Subject: RFR: JDK-8227021: VM fails if any sun.boot.library.path paths are longer than JVM_MAXPATHLEN In-Reply-To: <9daaf003-fe92-3c3a-9933-47d9b12f2ad9@oracle.com> References: <025da83a-6569-f6ac-7590-5b200ed2344f@oracle.com> <8e62fc61-b46b-0033-f182-cb4a2dbf92fd@oracle.com> <4f892f24-4919-4f3a-7e62-0603e08561cc@oracle.com> <4b195206-7a33-4f68-4207-fd214793cf28@oracle.com> Message-ID: Hi Coleen, Changes made. Thanks for your advice and patience. As for the sponsoring, Serguei volunteered a few changes back. Serguei: Are you happy to push the change in its current form? Webrev: http://cr.openjdk.java.net/~afarley/8227021.6/webrev/ Best Regards Adam Farley IBM Runtimes coleen.phillimore at oracle.com wrote on 20/08/2019 14:27:09: > From: coleen.phillimore at oracle.com > To: Adam Farley8 , David Holmes > > Cc: hotspot-dev at openjdk.java.net > Date: 20/08/2019 14:27 > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > paths are longer than JVM_MAXPATHLEN > > > This looks great. Thank you for making the changes. > > One tiny thing that I don't want to see another webrev for. Can you change: > +/* > + * Frees all memory allocated on the heap for the > + * supplied array of arrays of chars (a), where n > + * is the number of elements in the array. > + */ > to > +// > +// Frees all memory allocated on the heap for the > +// supplied array of arrays of chars (a), where n > +// is the number of elements in the array. > +// > And the big comment to have // at the top of split_path? > > We prefer // comments in the code. Do you need a sponsor? > > Thanks, > Coleen > On 8/20/19 9:13 AM, Adam Farley8 wrote: > Hi David, > > Good advice. Changes made as requested. > > Webrev: http://cr.openjdk.java.net/~afarley/8227021.6/webrev/ > > Does anyone have further concerns or changes to propose? > > Best Regards > > Adam Farley > IBM Runtimes > > > David Holmes wrote on 20/08/2019 12:55:26: > > > From: David Holmes > > To: Adam Farley8 , coleen.phillimore at oracle.com > > Cc: hotspot-dev at openjdk.java.net > > Date: 20/08/2019 12:55 > > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > > paths are longer than JVM_MAXPATHLEN > > > > Hi Adam, > > > > On 20/08/2019 1:21 am, Adam Farley8 wrote: > > > Hi Coleen, David, > > > > > > Here's the new webrev: https://urldefense.proofpoint.com/v2/url? > > u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.5_webrev_&d=DwID- > > g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=zaU5bibnUdHVncMttyVGbYf1yzDRUt26f9raqqKlJm0&s=QPe5l0tueNKISo62mJJ2RdRLUg_LsrhapCgVNJ0W3yQ&e= > > > > In this comment: > > > > ! * in use, you can pass the length of that in n, to ensure > > ! * we detect if any path exceeds the maximum path length > > ! * once prepended onto the sub-path/file name. > > * It is the callers responsibility to: > > * a> check the value of n, and n may be 0. > > > > the three references to 'n' should be to the new file_name_length parameter. > > > > Looking at the test: > > > > 2 * Copyright (c) 2019, 2019, Oracle and/or its affiliates. All > > rights reserved. > > > > For a new file there is only a single year specified so this should be: > > > > 2 * Copyright (c) 2019, Oracle and/or its affiliates. All rights > > reserved. > > > > 31 * @run main TestSunBootLibraryPath > > > > As this just launches another VM it is more efficient to use "@run driver". > > > > 35 import java.lang.IllegalArgumentException; > > > > Nit: java.lang.* is implicitly imported. > > > > 39 static String expectedErrorMessage =("The VM tried to use a > > path that exceeds the maximum path length for " > > 40 + "this system. Review > > path-containing parameters and properties, such as " > > 41 + "sun.boot.library.path, to > > identify potential sources for this path."); > > > > Nit: no need for parentheses. > > > > Probably also no need to check for the entire message - the first line > > should suffice. > > > > 48 //Add enough characters to make it "too long". > > 49 for (int i = 0 ; i < tooLongPathSize ; i++) tooLongPath > > += "a"; > > > > This can be done more efficiently and succinctly as: > > > > tooLongPath += "a".repeat(5000); > > > > There's probably an even better way. :) > > > > 60 throw new java.lang.IllegalArgumentException("Test was > > launched with an invalid argument."); > > > > No need to specify "java.lang". > > > > Thanks, > > David > > ----- > > > > > I made the requested changes, and moved the null check as suggested. > > > > > > (I agree passing a null for any of these values would be odd, and > > > unlikely to be done on purpose.) > > > > > > It also includes a new jtreg test for this change, which uses > ProcessTools. > > > > > > Let me know what you think (inc Serguei + others). > > > > > > Best Regards > > > > > > Adam Farley > > > IBM Runtimes > > > > > > > > > coleen.phillimore at oracle.com wrote on 16/08/2019 23:59:53: > > > > > >> From: coleen.phillimore at oracle.com > > >> To: Adam Farley8 > > >> Cc: David Holmes , hotspot-dev at openjdk.java.net > > >> Date: 17/08/2019 00:00 > > >> Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > > >> paths are longer than JVM_MAXPATHLEN > > >> > > >> > > > > > >> On 8/16/19 7:35 AM, Adam Farley8 wrote: > > >> Hi Coleen, > > >> > > >> To confirm your suspicions, I didn't see your responses. No > > offence intended. > > >> > > >> I send a lot of mail so I'm sure I can be caught in people's > spamfilter. :) > > >> > > >> > > >> Responses below. > > >> > > >> Best Regards > > >> > > >> Adam Farley > > >> IBM Runtimes > > >> > > >> > > >> coleen.phillimore at oracle.com wrote on 15/08/2019 13:42:51: > > >> > > >> > From: coleen.phillimore at oracle.com > > >> > To: hotspot-dev at openjdk.java.net, Adam Farley8 > > >> > , David Holmes > > >> > Date: 15/08/2019 13:43 > > >> > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > > >> > paths are longer than JVM_MAXPATHLEN > > >> > > > >> > Hi Adam, David noticed that my code review replies only went to the > > >> > mailing list. So here it is again. > > >> > Thanks, > > >> > Coleen > > >> > > > >> > On 8/13/19 5:29 PM, coleen.phillimore at oracle.com wrote: > > >> > > > > >> > > > > >> > > On 8/13/19 11:48 AM, Adam Farley8 wrote: > > >> > >> Hi David, > > >> > >> > > >> > >> Since we have two positive reviews (yours and Serguei's), could you > > >> > >> sponsor the change please? > > >> > > > > >> > > If you get two positive reviews, but then one with > comments, you need > > >> > > to also answer that third reviews. I had some comments on your > > >> > > change, which I'll repeat here: > > >> > > > > >> > > > > >> > > https://urldefense.proofpoint.com/v2/url? > > >> > u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021. > > >> > > > >> > > > 2_webrev_src_hotspot_share_runtime_os.cpp.frames.html&d=DwIDaQ&c=jf_iaSHvJObTbx- > > >> > siA1ZOg&r=P5m8KWUXJf- > > >> > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=wjd3KxxgFQv49yjlb4Bndy- > > >> > F1XV4pbuPZrmemiaFthA&s=xXwflqvuzoEhcREhr-x7rNMVDeroZ8Xh1LnW6NytumE&e= > > >> > > > > >> > > > > >> > > This is code is unnecessarily hard to read and understand: > > >> > > > > >> > > 1329 char** os::split_path(const char* path, size_t* n) { > > >> > > 1330 size_t pathmod = (size_t)0; > > >> > > 1331 if (n != NULL) { > > >> > > 1332 pathmod = *n; > > >> > > 1333 } > > >> > > 1334 *n = (size_t)0; > > >> > > > > >> > > It appears that 'n' is both an input and output parameter of this > > >> > > function. Can you just make it another input parameter with some > > >> > > descriptive name. Is it the length of the library name that you're > > >> > > looking for? "pathmod" is huh? > > >> > > >> The 'n' is both an input and an output, yes. > > >> > > >> I could make it another input parameter, but that means modifying the > > >> method signature. This seemed unnecessary, given that we have an input > > >> vector we're not using for anything. > > >> > > >> It's not a big deal to add a parameter, especially since there's > > >> only one call site, and the names don't have to be squished up C names. > > >> > > >> How about: char** split_path(char* path, size_t file_length, > > >> size_t* elements) ? > > > > > >> > > >> > > >> The 'n' input is used as a modifier for the length of the path, as > > >> mentioned in the comment. I called it "pathmod" because it's a PATH > > >> length MODIFIER. I couldn't think of a better name that's also concise. > > >> Would pathlenmod be better? Pathsizemod sounds like we're > making the path > > >> physically bigger, or maybe that's just me. :) > > >> > > >> > > > > >> > > Then you don't have to check if someone has passed NULL. There's only > > >> > > one caller to this from what I see. > > >> > > >> I'm not sure I understand this. We'd still need to check for > null, even if > > >> the pathmod has its own input parameter. I believe adding a > NULL to an int > > >> causes a segmentation error at runtime. > > >> > > >> If you're saying the null check isn't needed because we can > > ensure anon-null > > >> is passed in via the only place we call split_path, I disagree > > that this is a > > >> future-proof assumption. A null check seems prudent here. > > >> > > >> I think the function doesn't make any sense if you pass an output > > >> parameter as NULL. Or at worst you could add it to the line: > > >> > > >> 1335 if (path == NULL || strlen(path) == 0 || n == NULL) { > > >> 1336 return NULL; > > >> 1337 } > > >> 1334 *n = (size_t)0; > > >> > > >> But that's just weird. Why would a caller pass a non-null path and > > >> not want the element count? > > >> > > >> Thanks, > > >> Coleen > > >> > > >> > > >> > > > > >> > > 1352 char** opath = (char**) NEW_C_HEAP_ARRAY(char*, count, > > >> > > mtInternal); > > >> > > 1353 if (opath == NULL) { > > >> > > 1354 return NULL; > > >> > > 1355 } > > >> > > > > >> > > > > >> > > Not your change but this calls vm_exit_out_of_memory() if > > >> > > NEW_C_HEAP_ARRAY fails. It doesn't return NULL so you don't have to > > >> > > check. > > >> > > >> Seems legit. I'll include this in the .5 version once we have > consensus on > > >> the other changes. Good spot. > > >> > > >> > > > > >> > > 1375 char* s = (char*)NEW_C_HEAP_ARRAY(char, len + 1, > > mtInternal); > > >> > > > > >> > > Here you want to use NEW_C_HEAP_ARRAY_RETURN_NULL so you > cancheck for > > >> > > null and free memory. > > >> > > >> Good idea. Noted for .5. > > >> > > >> Let me know your thoughts on the other points above. > > >> > > >> > > >> > > > > >> > > > > >> > > The rest seems okay. > > >> > > > > >> > > thanks, > > >> > > Coleen > > >> > > > > >> > >> > > >> > >> Best Regards > > >> > >> > > >> > >> Adam Farley > > >> > >> IBM Runtimes > > >> > >> > > >> > >> > > >> > >> David Holmes wrote on 12/08/ > 2019 23:32:14: > > >> > >> > > >> > >>> From: David Holmes > > >> > >>> To: Adam Farley8 > > >> > >>> Cc: hotspot-dev at openjdk.java.net, "serguei.spitsyn at oracle.com" > > >> > >>> > > >> > >>> Date: 12/08/2019 23:32 > > >> > >>> Subject: Re: RFR: JDK-8227021: VM fails if any > sun.boot.library.path > > >> > >>> paths are longer than JVM_MAXPATHLEN > > >> > >>> > > >> > >>> Looks fine. > > >> > >>> > > >> > >>> Thanks, > > >> > >>> David > > >> > >>> > > >> > >>> On 13/08/2019 1:19 am, Adam Farley8 wrote: > > >> > >>>> Hi David, > > >> > >>>> > > >> > >>>> Changes made as requested: > > >> > >>>> https://urldefense.proofpoint.com/v2/url? > > >> > >>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.4_webrev&d=DwID- > > >> > >>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > >> > >>> > > >> > >> > > >> > > > >> > > > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=mZM8IR4e_zmrfcsF3XJjoGEMrZb4WtEL7Y6Ugd6Naqg&s=sZ2UKqqUIq0El- > > >> > >> > > >> > >>> RsqYz6jmTh4Q2UghwdrQX6of8Lw0E&e= > > >> > >>>> Best Regards > > >> > >>>> > > >> > >>>> Adam Farley > > >> > >>>> IBM Runtimes > > >> > >>>> > > >> > >>>> > > >> > >>>> David Holmes wrote on 12/08/ > > 2019 04:55:36: > > >> > >>>> > > >> > >>>>> From: David Holmes > > >> > >>>>> To: Adam Farley8 , > > >> > >>>>> "serguei.spitsyn at oracle.com" > > >> > >>>>> Cc: hotspot-dev at openjdk.java.net > > >> > >>>>> Date: 12/08/2019 04:56 > > >> > >>>>> Subject: Re: RFR: JDK-8227021: VM fails if any > > sun.boot.library.path > > >> > >>>>> paths are longer than JVM_MAXPATHLEN > > >> > >>>>> > > >> > >>>>> Hi Adam, > > >> > >>>>> > > >> > >>>>> On 10/08/2019 2:47 am, Adam Farley8 wrote: > > >> > >>>>>> Hi Serguei, David, > > >> > >>>>>> > > >> > >>>>>> My turn to apologise for the delay. :) > > >> > >>>>>> > > >> > >>>>>> I've modified the code as per Serguei's request. Takealook and > > >> > >> let me > > >> > >>>>>> know if this is the sort of thing you were thinking of. > > >> > >>>>>> > > >> > >>>>>> Webrev: https://urldefense.proofpoint.com/v2/url? > > >> > >>>>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021. > 3_webrev_&d=DwID- > > >> > >>>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > >> > >>>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > > >> > >>>>> > > >> > >> > > >> > > > >> > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=L19aeFXoR9JIO62QRPFzZObIU8RbhpCtXSvUibD2ISk&e= > > >> > >> > > >> > >>>>> I'd prefer to see the helper just as a file static > function rather > > >> > >> than > > >> > >>>>> adding it to the os class. > > >> > >>>>> > > >> > >>>>> + * supplied array of arrays of chars (a), where n > > >> > >>>>> > > >> > >>>>> I assume (a) is meant to refer to the parameter, but > you actually > > >> > >> called > > >> > >>>>> it arrayarray. I think "a" or "arr" would suffice. > > >> > >>>>> > > >> > >>>>> Thanks, > > >> > >>>>> David > > >> > >>>>> > > >> > >>>>>> Best Regards > > >> > >>>>>> > > >> > >>>>>> Adam Farley > > >> > >>>>>> IBM Runtimes > > >> > >>>>>> > > >> > >>>>>> > > >> > >>>>>> "serguei.spitsyn at oracle.com" > > wrote on > > >> > >>>>>> 31/07/2019 17:18:05: > > >> > >>>>>> > > >> > >>>>>>> From: "serguei.spitsyn at oracle.com" > > > >> > >>>>>>> To: Adam Farley8 , David Holmes > > >> > >>>>>>> > > >> > >>>>>>> Cc: serviceability-dev , > > >> > >>>>>>> hotspot-dev at openjdk.java.net > > >> > >>>>>>> Date: 31/07/2019 17:18 > > >> > >>>>>>> Subject: Re: RFR: JDK-8227021: VM fails if any > > >> > >> sun.boot.library.path > > >> > >>>>>>> paths are longer than JVM_MAXPATHLEN > > >> > >>>>>>> > > >> > >>>>>>> Hi Adam, > > >> > >>>>>>> > > >> > >>>>>>> It looks Okay to me. > > >> > >>>>>>> > > >> > >>>>>>> A couple of minor comments. > > >> > >>>>>>> > > >> > >>>>>>> https://urldefense.proofpoint.com/v2/url? > > >> > >>>>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021. > > >> > >>>>> 2_webrev_src_hotspot_&d=DwID-g&c=jf_iaSHvJObTbx- > > >> > >>>>> siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > > >> > >>>>> > > >> > >> > > >> > > > >> > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NL6tYuwwDod3DSmj-1ztxAywpO8L52HEyO0wvTR05bs&e= > > >> > >> > > >> > >>>>>>> share/runtime/os.cpp.frames.html > > >> > >>>>>>> 1362 //release allocated storage before exiting the vm > > >> > >>>>>>> 1363 while (i > 0) { > > >> > >>>>>>> 1364 i--; > > >> > >>>>>>> 1365 if (opath[i] != NULL) { > > >> > >>>>>>> 1366 FREE_C_HEAP_ARRAY(char, opath[i]); > > >> > >>>>>>> 1367 } > > >> > >>>>>>> 1368 } > > >> > >>>>>>> 1369 FREE_C_HEAP_ARRAY(char*, opath); > > >> > >>>>>>> > > >> > >>>>>>> 1377 //release allocated storage before returning null > > >> > >>>>>>> 1378 while (i > 0) { > > >> > >>>>>>> 1379 i--; > > >> > >>>>>>> 1380 if (opath[i] != NULL) { > > >> > >>>>>>> 1381 FREE_C_HEAP_ARRAY(char, opath[i]); > > >> > >>>>>>> 1382 } > > >> > >>>>>>> 1383 } > > >> > >>>>>>> 1384 FREE_C_HEAP_ARRAY(char*, opath); > > >> > >>>>>>> > > >> > >>>>>>> This duplicated fragments is worth to refactor to a function. > > >> > >>>>>>> Also a space is missed at the beginning of the comment. > > >> > >>>>>>> > > >> > >>>>>>> > > >> > >>>>>>> Thanks, > > >> > >>>>>>> Serguei > > >> > >>>>>>> > > >> > >>>>>>> > > >> > >>>>>>> > > >> > >>>>>>> On 7/31/19 02:01, Adam Farley8 wrote: > > >> > >>>>>>> Hi All, > > >> > >>>>>>> > > >> > >>>>>>> Reviewers requested for the change below. > > >> > >>>>>>> > > >> > >>>>>>> @David - Agreed. Would you be prepared to sponsor the change? > > >> > >>>>>>> > > >> > >>>>>>> Bug: https://urldefense.proofpoint.com/v2/url? > > >> > >>>>> u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8227021&d=DwID- > > >> > >>>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > >> > >>>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > > >> > >>>>> > > >> > >> > > >> > > > >> > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=xykJ0KLy9AKWO8zmC0amfR7xxUsvyKEjlf3y7WWOqvE&e= > > >> > >> > > >> > >>>>>>> Webrev: https://urldefense.proofpoint.com/v2/url? > > >> > >>>>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021. > 2_webrev_&d=DwID- > > >> > >>>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > >> > >>>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > > >> > >>>>> > > >> > >> > > >> > > > >> > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NvIza4VVWG3CiDhmQVmXsghH_4h_c5mFJbHwkCUcut0&e= > > >> > >> > > >> > >>>>>>> Best Regards > > >> > >>>>>>> > > >> > >>>>>>> Adam Farley > > >> > >>>>>>> IBM Runtimes > > >> > >>>>>>> > > >> > >>>>>>> P.S. Remembered to add the links this time. :) > > >> > >>>>>>> > > >> > >>>>>>> > > >> > >>>>>>> David Holmes wrote on 30/07/2019 > > >> > >> 03:37:53: > > >> > >>>>>>>> From: David Holmes > > >> > >>>>>>>> To: Adam Farley8 > > >> > >>>>>>>> Cc: hotspot-dev at openjdk.java.net, serviceability-dev > > >> > >>>>>>>> > > >> > >>>>>>>> Date: 30/07/2019 03:38 > > >> > >>>>>>>> Subject: Re: RFR: JDK-8227021: VM fails if any > > >> > >> sun.boot.library.path > > >> > >>>>>>>> paths are longer than JVM_MAXPATHLEN > > >> > >>>>>>>> > > >> > >>>>>>>> Hi Adam, > > >> > >>>>>>>> > > >> > >>>>>>>> On 25/07/2019 3:57 am, Adam Farley8 wrote: > > >> > >>>>>>>>> Hi David, > > >> > >>>>>>>>> > > >> > >>>>>>>>> Welcome back. :) > > >> > >>>>>>>> Thanks. Sorry for the delay in getting back to this. > > >> > >>>>>>>> > > >> > >>>>>>>> I like .v2 as it is much simpler (notwithstanding freeing > > >> > >>> the already > > >> > >>>>>>>> allocated arrays adds some complexity - thanks for > > fixing that). > > >> > >>>>>>>> > > >> > >>>>>>>> I'm still not sure we can't optimise things better for > > >> > >> unchangeable > > >> > >>>>>>>> properties like the boot libary path, but that's > another RFE. > > >> > >>>>>>>> > > >> > >>>>>>>> Thanks, > > >> > >>>>>>>> David > > >> > >>>>>>>> > > >> > >>>>>>> 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 > > >> > >> 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 > > > > 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 kim.barrett at oracle.com Tue Aug 20 16:08:04 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 20 Aug 2019 12:08:04 -0400 Subject: RFR: 8229836: Remove include of globals.hpp from allocation.hpp In-Reply-To: <5abdb28e-3658-d7d1-20b0-000898818f42@oracle.com> References: <5abdb28e-3658-d7d1-20b0-000898818f42@oracle.com> Message-ID: > On Aug 20, 2019, at 8:09 AM, Stefan Karlsson wrote: > > Hi all, > > Please review this patch to remove the include of globals.hpp from allocation.hpp. > > http://cr.openjdk.java.net/~stefank/8229836/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8229836 > > Note this change is just the bare minimum to get it to compile on our build platforms. I haven't tried to find all files that are missing explicit includes of globals.hpp. > > Thanks, > StefanK Looks good. ------------------------------------------------------------------------------ src/hotspot/share/oops/oopsHierarchy.hpp 76 extern "C" bool CheckUnhandledOops; Huh! I hadn't realized options polluted the global C namespace. Yet another reason to have far fewer :) ------------------------------------------------------------------------------ From kim.barrett at oracle.com Tue Aug 20 19:19:30 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 20 Aug 2019 15:19:30 -0400 Subject: RFR: 8227054: ServiceThread needs to know about all OopStorage objects In-Reply-To: References: <8181924C-36E6-4B91-9567-150F00286241@oracle.com> <74C738E7-CBDD-4891-ABD6-F8E023372508@oracle.com> <60099477-9AD4-4EFC-AA6F-6EF19D840E67@oracle.com> <164151e7-fec4-8c61-f247-3d5a41c910c1@oracle.com> <96EE9BB8-9EE5-4FBB-B266-785C563BFC2E@oracle.com> <694f8e0c-b00f-54d4-105d-68e6442b2759@oracle.com> <46A102CD-F381-4ACC-852E-F36B9F9DD9DD@oracle.com> Message-ID: <33C24634-ED46-4CFC-96A1-02C87AABC2B8@oracle.com> > On Aug 20, 2019, at 2:23 AM, Erik Osterlund wrote: > > Hi Kim, > > Looks good. Thanks. > > Thanks, > /Erik > > On 20 Aug 2019, at 00:32, Kim Barrett wrote: > >>> On Aug 12, 2019, at 4:52 AM, Erik ?sterlund wrote: >>> On 2019-08-12 05:26, Kim Barrett wrote: >>>>> On Aug 10, 2019, at 3:52 AM, Erik Osterlund wrote: >>>>> Apart from those two things, I really liked the approach! >>>> Thanks. Hopefully we?re approaching a conclusion on this change. >>> >>> I hope so. >> >> Finally getting back to this; I got distracted by other things. >> >> I've removed the macros that were bothering you. >> >> full: http://cr.openjdk.java.net/~kbarrett/8227054/open.03/ >> incr: http://cr.openjdk.java.net/~kbarrett/8227054/open.03.inc/ From coleen.phillimore at oracle.com Tue Aug 20 19:42:12 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 20 Aug 2019 15:42:12 -0400 Subject: RFR: 8227054: ServiceThread needs to know about all OopStorage objects In-Reply-To: <33C24634-ED46-4CFC-96A1-02C87AABC2B8@oracle.com> References: <8181924C-36E6-4B91-9567-150F00286241@oracle.com> <74C738E7-CBDD-4891-ABD6-F8E023372508@oracle.com> <60099477-9AD4-4EFC-AA6F-6EF19D840E67@oracle.com> <164151e7-fec4-8c61-f247-3d5a41c910c1@oracle.com> <96EE9BB8-9EE5-4FBB-B266-785C563BFC2E@oracle.com> <694f8e0c-b00f-54d4-105d-68e6442b2759@oracle.com> <46A102CD-F381-4ACC-852E-F36B9F9DD9DD@oracle.com> <33C24634-ED46-4CFC-96A1-02C87AABC2B8@oracle.com> Message-ID: The iterator code seems to have taken on a life of it's own, but the runtime changes still look good. Can you put some comment about why is there a singular iterator and what its purpose is?? Is there some implicit use I can't find? + // Construct a singular iterator. The only valid operations are + // destruction/copy/assignment. + Iterator() : + _index(singular_index), + _limit(singular_index) + DEBUG_ONLY(COMMA _category(singular)) {} + Thanks, Coleen On 8/20/19 3:19 PM, Kim Barrett wrote: >> On Aug 20, 2019, at 2:23 AM, Erik Osterlund wrote: >> >> Hi Kim, >> >> Looks good. > Thanks. > >> Thanks, >> /Erik >> >> On 20 Aug 2019, at 00:32, Kim Barrett wrote: >> >>>> On Aug 12, 2019, at 4:52 AM, Erik ?sterlund wrote: >>>> On 2019-08-12 05:26, Kim Barrett wrote: >>>>>> On Aug 10, 2019, at 3:52 AM, Erik Osterlund wrote: >>>>>> Apart from those two things, I really liked the approach! >>>>> Thanks. Hopefully we?re approaching a conclusion on this change. >>>> I hope so. >>> Finally getting back to this; I got distracted by other things. >>> >>> I've removed the macros that were bothering you. >>> >>> full: http://cr.openjdk.java.net/~kbarrett/8227054/open.03/ >>> incr: http://cr.openjdk.java.net/~kbarrett/8227054/open.03.inc/ > From kim.barrett at oracle.com Tue Aug 20 21:10:58 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 20 Aug 2019 17:10:58 -0400 Subject: RFR: 8227054: ServiceThread needs to know about all OopStorage objects In-Reply-To: References: <8181924C-36E6-4B91-9567-150F00286241@oracle.com> <74C738E7-CBDD-4891-ABD6-F8E023372508@oracle.com> <60099477-9AD4-4EFC-AA6F-6EF19D840E67@oracle.com> <164151e7-fec4-8c61-f247-3d5a41c910c1@oracle.com> <96EE9BB8-9EE5-4FBB-B266-785C563BFC2E@oracle.com> <694f8e0c-b00f-54d4-105d-68e6442b2759@oracle.com> <46A102CD-F381-4ACC-852E-F36B9F9DD9DD@oracle.com> <33C24634-ED46-4CFC-96A1-02C87AABC2B8@oracle.com> Message-ID: > On Aug 20, 2019, at 3:42 PM, coleen.phillimore at oracle.com wrote: > > > The iterator code seems to have taken on a life of it's own, but the runtime changes still look good. Thanks. > Can you put some comment about why is there a singular iterator and what its purpose is? Is there some implicit use I can't find? > > + // Construct a singular iterator. The only valid operations are > + // destruction/copy/assignment. > + Iterator() : > + _index(singular_index), > + _limit(singular_index) > + DEBUG_ONLY(COMMA _category(singular)) {} > + > Does this help? - // Construct a singular iterator. The only valid operations are - // destruction/copy/assignment. + // Construct a singular iterator, not associated with any of the sets + // (strong, weak, or all) of storage objects. The only valid operations + // are destruction/copy/assignment. Singular iterators exist so you can declare a variable and later assign to it, for example Iterator it; if (need_strong) { it = strong_iterator(); } else { it = weak_iterator(); } ? use the iterator ? The C++ standard uses the phrase ?iterator with a singular value?; ?singular iterator? is a common shorthand. From coleen.phillimore at oracle.com Wed Aug 21 01:41:24 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 20 Aug 2019 21:41:24 -0400 Subject: RFR: 8227054: ServiceThread needs to know about all OopStorage objects In-Reply-To: References: <8181924C-36E6-4B91-9567-150F00286241@oracle.com> <74C738E7-CBDD-4891-ABD6-F8E023372508@oracle.com> <60099477-9AD4-4EFC-AA6F-6EF19D840E67@oracle.com> <164151e7-fec4-8c61-f247-3d5a41c910c1@oracle.com> <96EE9BB8-9EE5-4FBB-B266-785C563BFC2E@oracle.com> <694f8e0c-b00f-54d4-105d-68e6442b2759@oracle.com> <46A102CD-F381-4ACC-852E-F36B9F9DD9DD@oracle.com> <33C24634-ED46-4CFC-96A1-02C87AABC2B8@oracle.com> Message-ID: <5b730b9c-2cc6-a4b7-bd0f-dfb2ee7c6b26@oracle.com> On 8/20/19 5:10 PM, Kim Barrett wrote: >> On Aug 20, 2019, at 3:42 PM, coleen.phillimore at oracle.com wrote: >> >> >> The iterator code seems to have taken on a life of it's own, but the runtime changes still look good. > Thanks. > >> Can you put some comment about why is there a singular iterator and what its purpose is? Is there some implicit use I can't find? >> >> + // Construct a singular iterator. The only valid operations are >> + // destruction/copy/assignment. >> + Iterator() : >> + _index(singular_index), >> + _limit(singular_index) >> + DEBUG_ONLY(COMMA _category(singular)) {} >> + >> > Does this help? > > - // Construct a singular iterator. The only valid operations are > - // destruction/copy/assignment. > + // Construct a singular iterator, not associated with any of the sets > + // (strong, weak, or all) of storage objects. The only valid operations > + // are destruction/copy/assignment. > > Singular iterators exist so you can declare a variable and later assign to it. Add this sentence to the comment and I'm fine.? I wanted the comment to say why it exists. Thanks, Coleen > , for example > > Iterator it; > if (need_strong) { > it = strong_iterator(); > } else { > it = weak_iterator(); > } > ? use the iterator ? > > The C++ standard uses the phrase ?iterator with a singular value?; ?singular iterator? is > a common shorthand. > From david.holmes at oracle.com Wed Aug 21 07:23:35 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 21 Aug 2019 17:23:35 +1000 Subject: RFR: JDK-8227021: VM fails if any sun.boot.library.path paths are longer than JVM_MAXPATHLEN In-Reply-To: References: <5ba808b0-ae52-0d0a-b84b-fc34df35475d@oracle.com> <025da83a-6569-f6ac-7590-5b200ed2344f@oracle.com> <8e62fc61-b46b-0033-f182-cb4a2dbf92fd@oracle.com> <4f892f24-4919-4f3a-7e62-0603e08561cc@oracle.com> <4b195206-7a33-4f68-4207-fd214793cf28@oracle.com> Message-ID: Hi Adam, Updates look good. One further style nit I missed: In all // comments in the test e.g. //Grab any path. please add a space after // No need for updated webrev. Thanks, David On 20/08/2019 11:13 pm, Adam Farley8 wrote: > Hi David, > > Good advice. Changes made as requested. > > Webrev: http://cr.openjdk.java.net/~afarley/8227021.6/webrev/ > > Does anyone have further concerns or changes to propose? > > Best Regards > > Adam Farley > IBM Runtimes > > > David Holmes wrote on 20/08/2019 12:55:26: > >> From: David Holmes >> To: Adam Farley8 , coleen.phillimore at oracle.com >> Cc: hotspot-dev at openjdk.java.net >> Date: 20/08/2019 12:55 >> Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path >> paths are longer than JVM_MAXPATHLEN >> >> Hi Adam, >> >> On 20/08/2019 1:21 am, Adam Farley8 wrote: >> > Hi Coleen, David, >> > >> > Here's the new webrev: https://urldefense.proofpoint.com/v2/url? >> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.5_webrev_&d=DwID- >> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- >> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=zaU5bibnUdHVncMttyVGbYf1yzDRUt26f9raqqKlJm0&s=QPe5l0tueNKISo62mJJ2RdRLUg_LsrhapCgVNJ0W3yQ&e= >> >> In this comment: >> >> ! ?* in use, you can pass the length of that in n, to ensure >> ! ?* we detect if any path exceeds the maximum path length >> ! ?* once prepended onto the sub-path/file name. >> ? ? * It is the callers responsibility to: >> ? ? * ? a> check the value of n, and n may be 0. >> >> the three references to 'n' should be to the new file_name_length parameter. >> >> Looking at the test: >> >> ? ?2 ?* Copyright (c) 2019, 2019, Oracle and/or its affiliates. All >> rights reserved. >> >> For a new file there is only a single year specified so this should be: >> >> ? ?2 ?* Copyright (c) 2019, Oracle and/or its affiliates. All rights >> reserved. >> >> ? 31 ?* @run main TestSunBootLibraryPath >> >> As this just launches another VM it is more efficient to use "@run driver". >> >> ? 35 import java.lang.IllegalArgumentException; >> >> Nit: java.lang.* is implicitly imported. >> >> ? 39 ? ? static String expectedErrorMessage =("The VM tried to use a >> path that exceeds the maximum path length for " >> ? 40 ? ? ? ? ? ? ? ? ? + "this system. Review >> path-containing parameters and properties, such as " >> ? 41 ? ? ? ? ? ? ? ? ? + "sun.boot.library.path, to >> identify potential sources for this path."); >> >> Nit: no need for parentheses. >> >> Probably also no need to check for the entire message - the first line >> should suffice. >> >> ? 48 ? ? ? ? ? ? //Add enough characters to make it "too long". >> ? 49 ? ? ? ? ? ? for (int i = 0 ; i < tooLongPathSize ; i++) tooLongPath >> += "a"; >> >> This can be done more efficiently and succinctly as: >> >> tooLongPath += "a".repeat(5000); >> >> There's probably an even better way. :) >> >> ? 60 ? ? ? ? ? ? throw new java.lang.IllegalArgumentException("Test was >> launched with an invalid argument."); >> >> No need to specify "java.lang". >> >> Thanks, >> David >> ----- >> >> > I made the requested changes, and moved the null check as suggested. >> > >> > (I agree passing a null for any of these values would be odd, and >> > unlikely to be done on purpose.) >> > >> > It also includes a new jtreg test for this change, which uses ProcessTools. >> > >> > Let me know what you think (inc Serguei + others). >> > >> > Best Regards >> > >> > Adam Farley >> > IBM Runtimes >> > >> > >> > coleen.phillimore at oracle.com wrote on 16/08/2019 23:59:53: >> > >> >> From: coleen.phillimore at oracle.com >> >> To: Adam Farley8 >> >> Cc: David Holmes , ?hotspot-dev at openjdk.java.net >> >> Date: 17/08/2019 00:00 >> >> Subject: Re: RFR: JDK-8227021: ?VM fails if any sun.boot.library.path >> >> paths are longer than JVM_MAXPATHLEN >> >> >> >> >> > >> >> On 8/16/19 7:35 AM, Adam Farley8 ?wrote: >> >> Hi Coleen, >> >> >> >> To confirm your suspicions, I didn't see your responses. No >> offence ?intended. >> >> >> >> I send a lot of mail so I'm sure I can be caught in people's spamfilter. :) >> >> >> >> >> >> Responses below. >> >> >> >> Best Regards >> >> >> >> Adam Farley >> >> IBM Runtimes >> >> >> >> >> >> coleen.phillimore at oracle.com wrote on 15/08/2019 13:42:51: >> >> >> >> > From: coleen.phillimore at oracle.com >> >> > To: hotspot-dev at openjdk.java.net, Adam Farley8 >> >> > , David Holmes >> >> > Date: 15/08/2019 13:43 >> >> > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path >> >> > paths are longer than JVM_MAXPATHLEN >> >> > >> >> > Hi Adam,? David noticed that my code review replies only ?went to the >> >> > mailing list.? So here it is again. >> >> > Thanks, >> >> > Coleen >> >> > >> >> > On 8/13/19 5:29 PM, coleen.phillimore at oracle.com wrote: >> >> > > >> >> > > >> >> > > On 8/13/19 11:48 AM, Adam Farley8 wrote: >> >> > >> Hi David, >> >> > >> >> >> > >> Since we have two positive reviews (yours and Serguei's), ?could you >> >> > >> sponsor the change please? >> >> > > >> >> > > If you get two positive reviews, but then one with comments, ?you need >> >> > > to also answer that third reviews.? I had some comments ?on your >> >> > > change, which I'll repeat here: >> >> > > >> >> > > >> >> > > https://urldefense.proofpoint.com/v2/url? >> >> > u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021. >> >> > >> >> >> 2_webrev_src_hotspot_share_runtime_os.cpp.frames.html&d=DwIDaQ&c=jf_iaSHvJObTbx- >> >> > siA1ZOg&r=P5m8KWUXJf- >> >> > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=wjd3KxxgFQv49yjlb4Bndy- >> >> > F1XV4pbuPZrmemiaFthA&s=xXwflqvuzoEhcREhr-x7rNMVDeroZ8Xh1LnW6NytumE&e= >> >> > > >> >> > > >> >> > > This is code is unnecessarily hard to read and understand: >> >> > > >> >> > > 1329 char** os::split_path(const char* path, size_t* n) ?{ >> >> > > 1330 size_t pathmod = (size_t)0; >> >> > > 1331 if (n != NULL) { >> >> > > 1332 pathmod = *n; >> >> > > 1333 } >> >> > > 1334 *n = (size_t)0; >> >> > > >> >> > > It appears that 'n' is both an input and output parameter ?of this >> >> > > function.? Can you just make it another input parameter ?with some >> >> > > descriptive name.? Is it the length of the library ?name that you're >> >> > > looking for?? "pathmod" is huh? >> >> >> >> The 'n' is both an input and an output, yes. >> >> >> >> I could make it another input parameter, but that means modifying ?the >> >> method signature. This seemed unnecessary, given that we have an input >> >> vector we're not using for anything. >> >> >> >> It's not a big deal to add a parameter, especially since there's >> >> only one call site, and the names don't have to be squished up C names. >> >> >> >> How about:? char** split_path(char* path, size_t file_length, >> >> size_t* elements) ? >> > >> >> >> >> >> >> The 'n' input is used as a modifier for the length of the path, as >> >> mentioned in the comment. I called it "pathmod" because ?it's a PATH >> >> length MODIFIER. I couldn't think of a better name that's also concise. >> >> Would pathlenmod be better? Pathsizemod sounds like we're making the ?path >> >> physically bigger, or maybe that's just me. :) >> >> >> >> > > >> >> > > Then you don't have to check if someone has passed NULL. There's only >> >> > > one caller to this from what I see. >> >> >> >> I'm not sure I understand this. We'd still need to check for null, ?even if >> >> the pathmod has its own input parameter. I believe adding a NULL to ?an int >> >> causes a segmentation error at runtime. >> >> >> >> If you're saying the null check isn't needed because we can >> ensure ?anon-null >> >> is passed in via the only place we call split_path, I disagree >> that ?this is a >> >> future-proof assumption. A null check seems prudent here. >> >> >> >> I think the function doesn't make any sense if you pass an output >> >> parameter as NULL.? Or at worst you could add it to the line: >> >> >> >> 1335 if (path == NULL || strlen(path) == 0 || n == NULL) { >> >> 1336 ? ?? return NULL; >> >> 1337 } >> >> 1334 *n = (size_t)0; >> >> >> >> But that's just weird. Why would a caller pass a non-null path and >> >> not want the element count? >> >> >> >> Thanks, >> >> Coleen >> >> >> >> >> >> > > >> >> > > 1352?? char** opath = (char**) NEW_C_HEAP_ARRAY(char*, ?count, >> >> > > mtInternal); >> >> > > 1353?? if (opath == NULL) { >> >> > > 1354???? return NULL; >> >> > > 1355?? } >> >> > > >> >> > > >> >> > > Not your change but this calls vm_exit_out_of_memory() if >> >> > > NEW_C_HEAP_ARRAY fails.? It doesn't return NULL so ?you don't have to >> >> > > check. >> >> >> >> Seems legit. I'll include this in the .5 version once we have consensus ?on >> >> the other changes. Good spot. >> >> >> >> > > >> >> > > 1375???? char* s? = (char*)NEW_C_HEAP_ARRAY(char, ?len + 1, >> mtInternal); >> >> > > >> >> > > Here you want to use NEW_C_HEAP_ARRAY_RETURN_NULL so you ?cancheck for >> >> > > null and free memory. >> >> >> >> Good idea. Noted for .5. >> >> >> >> Let me know your thoughts on the other points above. >> >> >> >> >> >> > > >> >> > > >> >> > > The rest seems okay. >> >> > > >> >> > > thanks, >> >> > > Coleen >> >> > > >> >> > >> >> >> > >> Best Regards >> >> > >> >> >> > >> Adam Farley >> >> > >> IBM Runtimes >> >> > >> >> >> > >> >> >> > >> David Holmes wrote on ?12/08/2019 23:32:14: >> >> > >> >> >> > >>> From: David Holmes >> >> > >>> To: Adam Farley8 >> >> > >>> Cc: hotspot-dev at openjdk.java.net, "serguei.spitsyn at oracle.com" >> >> > >>> >> >> > >>> Date: 12/08/2019 23:32 >> >> > >>> Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path >> >> > >>> paths are longer than JVM_MAXPATHLEN >> >> > >>> >> >> > >>> Looks fine. >> >> > >>> >> >> > >>> Thanks, >> >> > >>> David >> >> > >>> >> >> > >>> On 13/08/2019 1:19 am, Adam Farley8 wrote: >> >> > >>>> Hi David, >> >> > >>>> >> >> > >>>> Changes made as requested: >> >> > >>>> https://urldefense.proofpoint.com/v2/url? >> >> > >>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.4_webrev&d=DwID- >> >> > >>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- >> >> > >>> >> >> > >> >> >> > >> >> >> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=mZM8IR4e_zmrfcsF3XJjoGEMrZb4WtEL7Y6Ugd6Naqg&s=sZ2UKqqUIq0El- >> >> > >> >> >> > >>> RsqYz6jmTh4Q2UghwdrQX6of8Lw0E&e= >> >> > >>>> Best Regards >> >> > >>>> >> >> > >>>> Adam Farley >> >> > >>>> IBM Runtimes >> >> > >>>> >> >> > >>>> >> >> > >>>> David Holmes ?wrote on 12/08/ >> 2019 04:55:36: >> >> > >>>> >> >> > >>>>> From: David Holmes >> >> > >>>>> To: Adam Farley8 , >> >> > >>>>> "serguei.spitsyn at oracle.com" >> >> > >>>>> Cc: hotspot-dev at openjdk.java.net >> >> > >>>>> Date: 12/08/2019 04:56 >> >> > >>>>> Subject: Re: RFR: JDK-8227021: VM ?fails if any >> sun.boot.library.path >> >> > >>>>> paths are longer than JVM_MAXPATHLEN >> >> > >>>>> >> >> > >>>>> Hi Adam, >> >> > >>>>> >> >> > >>>>> On 10/08/2019 2:47 am, Adam Farley8 wrote: >> >> > >>>>>> Hi Serguei, David, >> >> > >>>>>> >> >> > >>>>>> My turn to apologise for the delay. ?:) >> >> > >>>>>> >> >> > >>>>>> I've modified the code as per Serguei's ?request. Take alook? and >> >> > >> let me >> >> > >>>>>> know if this is the sort of thing you ?were thinking of. >> >> > >>>>>> >> >> > >>>>>> Webrev: https://urldefense.proofpoint.com/v2/url? >> >> > >>>>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.3_webrev_&d=DwID- >> >> > >>>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- >> >> > >>>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- >> >> > >>>>> >> >> > >> >> >> > >> >> >> yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=L19aeFXoR9JIO62QRPFzZObIU8RbhpCtXSvUibD2ISk&e= >> >> > >> >> >> > >>>>> I'd prefer to see the helper just as a file ?static function rather >> >> > >> than >> >> > >>>>> adding it to the os class. >> >> > >>>>> >> >> > >>>>> +? * supplied array of arrays of chars ?(a), where n >> >> > >>>>> >> >> > >>>>> I assume (a) is meant to refer to the parameter, ?but you actually >> >> > >> called >> >> > >>>>> it arrayarray. I think "a" or ?"arr" would suffice. >> >> > >>>>> >> >> > >>>>> Thanks, >> >> > >>>>> David >> >> > >>>>> >> >> > >>>>>> Best Regards >> >> > >>>>>> >> >> > >>>>>> Adam Farley >> >> > >>>>>> IBM Runtimes >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> "serguei.spitsyn at oracle.com" >> ? wrote on >> >> > >>>>>> 31/07/2019 17:18:05: >> >> > >>>>>> >> >> > >>>>>>> From: "serguei.spitsyn at oracle.com" ? >> >> > >>>>>>> To: Adam Farley8 , ?David? Holmes >> >> > >>>>>>> >> >> > >>>>>>> Cc: serviceability-dev , >> >> > >>>>>>> hotspot-dev at openjdk.java.net >> >> > >>>>>>> Date: 31/07/2019 17:18 >> >> > >>>>>>> Subject: Re: RFR: JDK-8227021: VM fails if any >> >> > >> sun.boot.library.path >> >> > >>>>>>> paths are longer than JVM_MAXPATHLEN >> >> > >>>>>>> >> >> > >>>>>>> Hi Adam, >> >> > >>>>>>> >> >> > >>>>>>> It looks Okay to me. >> >> > >>>>>>> >> >> > >>>>>>> A couple of minor comments. >> >> > >>>>>>> >> >> > >>>>>>> https://urldefense.proofpoint.com/v2/url? >> >> > >>>>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021. >> >> > >>>>> 2_webrev_src_hotspot_&d=DwID-g&c=jf_iaSHvJObTbx- >> >> > >>>>> siA1ZOg&r=P5m8KWUXJf-CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- >> >> > >>>>> >> >> > >> >> >> > >> >> >> yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NL6tYuwwDod3DSmj-1ztxAywpO8L52HEyO0wvTR05bs&e= >> >> > >> >> >> > >>>>>>> share/runtime/os.cpp.frames.html >> >> > >>>>>>> 1362 ? ? ?//release allocated storage? before exiting the vm >> >> > >>>>>>> 1363 ? ? ?while (i > 0) { >> >> > >>>>>>> 1364 ? ?i--; >> >> > >>>>>>> 1365 ? ?if (opath[i] != NULL)? { >> >> > >>>>>>> 1366 ? ? ?FREE_C_HEAP_ARRAY(char,?? opath[i]); >> >> > >>>>>>> 1367 ? ?} >> >> > >>>>>>> 1368 ? ? ?} >> >> > >>>>>>> 1369 ? ? ?FREE_C_HEAP_ARRAY(char*, opath); >> >> > >>>>>>> >> >> > >>>>>>> 1377 ? ? ?//release allocated storage before returning? null >> >> > >>>>>>> 1378 ? ? ?while (i > 0) { >> >> > >>>>>>> 1379 ? ?i--; >> >> > >>>>>>> 1380 ? ?if (opath[i] != NULL)? { >> >> > >>>>>>> 1381 ? ? ?FREE_C_HEAP_ARRAY(char,?? opath[i]); >> >> > >>>>>>> 1382 ? ?} >> >> > >>>>>>> 1383 ? ? ?} >> >> > >>>>>>> 1384 ? ? ?FREE_C_HEAP_ARRAY(char*, opath); >> >> > >>>>>>> >> >> > >>>>>>> This duplicated fragments is worth ?to refactor to a function. >> >> > >>>>>>> Also a space is missed at the beginning ?of the comment. >> >> > >>>>>>> >> >> > >>>>>>> >> >> > >>>>>>> Thanks, >> >> > >>>>>>> Serguei >> >> > >>>>>>> >> >> > >>>>>>> >> >> > >>>>>>> >> >> > >>>>>>> On 7/31/19 02:01, Adam Farley8 wrote: >> >> > >>>>>>> Hi All, >> >> > >>>>>>> >> >> > >>>>>>> Reviewers requested for the change ?below. >> >> > >>>>>>> >> >> > >>>>>>> @David - Agreed. Would you be prepared ?to sponsor the change? >> >> > >>>>>>> >> >> > >>>>>>> Bug: https://urldefense.proofpoint.com/v2/url? >> >> > >>>>> u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8227021&d=DwID- >> >> > >>>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- >> >> > >>>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- >> >> > >>>>> >> >> > >> >> >> > >> >> >> yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=xykJ0KLy9AKWO8zmC0amfR7xxUsvyKEjlf3y7WWOqvE&e= >> >> > >> >> >> > >>>>>>> Webrev: https://urldefense.proofpoint.com/v2/url? >> >> > >>>>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.2_webrev_&d=DwID- >> >> > >>>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- >> >> > >>>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- >> >> > >>>>> >> >> > >> >> >> > >> >> >> yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NvIza4VVWG3CiDhmQVmXsghH_4h_c5mFJbHwkCUcut0&e= >> >> > >> >> >> > >>>>>>> Best Regards >> >> > >>>>>>> >> >> > >>>>>>> Adam Farley >> >> > >>>>>>> IBM Runtimes >> >> > >>>>>>> >> >> > >>>>>>> P.S. Remembered to add the links ?this time. :) >> >> > >>>>>>> >> >> > >>>>>>> >> >> > >>>>>>> David Holmes ?wrote on 30/07/2019 >> >> > >> 03:37:53: >> >> > >>>>>>>> From: David Holmes >> >> > >>>>>>>> To: Adam Farley8 >> >> > >>>>>>>> Cc: hotspot-dev at openjdk.java.net, ?serviceability-dev >> >> > >>>>>>>> >> >> > >>>>>>>> Date: 30/07/2019 03:38 >> >> > >>>>>>>> Subject: Re: RFR: JDK-8227021: ?VM fails if any >> >> > >> sun.boot.library.path >> >> > >>>>>>>> paths are longer than JVM_MAXPATHLEN >> >> > >>>>>>>> >> >> > >>>>>>>> Hi Adam, >> >> > >>>>>>>> >> >> > >>>>>>>> On 25/07/2019 3:57 am, Adam ?Farley8 wrote: >> >> > >>>>>>>>> Hi David, >> >> > >>>>>>>>> >> >> > >>>>>>>>> Welcome back. :) >> >> > >>>>>>>> Thanks. Sorry for the delay ?in getting back to this. >> >> > >>>>>>>> >> >> > >>>>>>>> I like .v2 as it is much simpler ?(notwithstanding freeing >> >> > >>> the? already >> >> > >>>>>>>> allocated arrays adds some complexity ?- thanks for >> fixing that). >> >> > >>>>>>>> >> >> > >>>>>>>> I'm still not sure we can't ?optimise things better for >> >> > >> unchangeable >> >> > >>>>>>>> properties like the boot libary ?path, but that's another? RFE. >> >> > >>>>>>>> >> >> > >>>>>>>> Thanks, >> >> > >>>>>>>> David >> >> > >>>>>>>> >> >> > >>>>>>> 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 >> >> > >> 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 >> > > 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 per.liden at oracle.com Wed Aug 21 07:40:21 2019 From: per.liden at oracle.com (Per Liden) Date: Wed, 21 Aug 2019 09:40:21 +0200 Subject: RFR: 8227054: ServiceThread needs to know about all OopStorage objects In-Reply-To: <46A102CD-F381-4ACC-852E-F36B9F9DD9DD@oracle.com> References: <8181924C-36E6-4B91-9567-150F00286241@oracle.com> <74C738E7-CBDD-4891-ABD6-F8E023372508@oracle.com> <60099477-9AD4-4EFC-AA6F-6EF19D840E67@oracle.com> <164151e7-fec4-8c61-f247-3d5a41c910c1@oracle.com> <96EE9BB8-9EE5-4FBB-B266-785C563BFC2E@oracle.com> <694f8e0c-b00f-54d4-105d-68e6442b2759@oracle.com> <46A102CD-F381-4ACC-852E-F36B9F9DD9DD@oracle.com> Message-ID: <6f6ad51f-7025-62b6-f3d4-47b7e716f24c@oracle.com> On 8/20/19 12:32 AM, Kim Barrett wrote: >> On Aug 12, 2019, at 4:52 AM, Erik ?sterlund wrote: >> On 2019-08-12 05:26, Kim Barrett wrote: >>>> On Aug 10, 2019, at 3:52 AM, Erik Osterlund wrote: >>>> Apart from those two things, I really liked the approach! >>> Thanks. Hopefully we?re approaching a conclusion on this change. >> >> I hope so. > > Finally getting back to this; I got distracted by other things. > > I've removed the macros that were bothering you. > > full: http://cr.openjdk.java.net/~kbarrett/8227054/open.03/ > incr: http://cr.openjdk.java.net/~kbarrett/8227054/open.03.inc/ Thanks, looks good to me! /Per From adam.farley at uk.ibm.com Wed Aug 21 11:15:00 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Wed, 21 Aug 2019 12:15:00 +0100 Subject: RFR: JDK-8227021: VM fails if any sun.boot.library.path paths are longer than JVM_MAXPATHLEN In-Reply-To: References: <025da83a-6569-f6ac-7590-5b200ed2344f@oracle.com> <8e62fc61-b46b-0033-f182-cb4a2dbf92fd@oracle.com> <4f892f24-4919-4f3a-7e62-0603e08561cc@oracle.com> <4b195206-7a33-4f68-4207-fd214793cf28@oracle.com> Message-ID: Hi David, Done. Best Regards Adam Farley IBM Runtimes David Holmes wrote on 21/08/2019 08:23:35: > From: David Holmes > To: Adam Farley8 > Cc: coleen.phillimore at oracle.com, hotspot-dev at openjdk.java.net > Date: 21/08/2019 08:24 > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > paths are longer than JVM_MAXPATHLEN > > Hi Adam, > > Updates look good. One further style nit I missed: In all // comments in > the test e.g. > > //Grab any path. > > please add a space after // > > No need for updated webrev. > > Thanks, > David > > On 20/08/2019 11:13 pm, Adam Farley8 wrote: > > Hi David, > > > > Good advice. Changes made as requested. > > > > Webrev: https://urldefense.proofpoint.com/v2/url? > u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.6_webrev_&d=DwID- > g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=Ewqm4OWSpgtC3ZFW8QrQKu- > maZKVWs4bwiF5e-YtNd8&s=jedS6glfOqiOmvn0kk9366V_Lxy5nIFk7LsnVZhMoMc&e= > > > > Does anyone have further concerns or changes to propose? > > > > Best Regards > > > > Adam Farley > > IBM Runtimes > > > > > > David Holmes wrote on 20/08/2019 12:55:26: > > > >> From: David Holmes > >> To: Adam Farley8 , coleen.phillimore at oracle.com > >> Cc: hotspot-dev at openjdk.java.net > >> Date: 20/08/2019 12:55 > >> Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > >> paths are longer than JVM_MAXPATHLEN > >> > >> Hi Adam, > >> > >> On 20/08/2019 1:21 am, Adam Farley8 wrote: > >> > Hi Coleen, David, > >> > > >> > Here's the new webrev: https://urldefense.proofpoint.com/v2/url? > >> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.5_webrev_&d=DwID- > >> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > >> > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=zaU5bibnUdHVncMttyVGbYf1yzDRUt26f9raqqKlJm0&s=QPe5l0tueNKISo62mJJ2RdRLUg_LsrhapCgVNJ0W3yQ&e= > >> > >> In this comment: > >> > >> ! * in use, you can pass the length of that in n, to ensure > >> ! * we detect if any path exceeds the maximum path length > >> ! * once prepended onto the sub-path/file name. > >> * It is the callers responsibility to: > >> * a> check the value of n, and n may be 0. > >> > >> the three references to 'n' should be to the new file_name_lengthparameter. > >> > >> Looking at the test: > >> > >> 2 * Copyright (c) 2019, 2019, Oracle and/or its affiliates. All > >> rights reserved. > >> > >> For a new file there is only a single year specified so this should be: > >> > >> 2 * Copyright (c) 2019, Oracle and/or its affiliates. All rights > >> reserved. > >> > >> 31 * @run main TestSunBootLibraryPath > >> > >> As this just launches another VM it is more efficient to use > "@run driver". > >> > >> 35 import java.lang.IllegalArgumentException; > >> > >> Nit: java.lang.* is implicitly imported. > >> > >> 39 static String expectedErrorMessage =("The VM tried to use a > >> path that exceeds the maximum path length for " > >> 40 + "this system. Review > >> path-containing parameters and properties, such as " > >> 41 + "sun.boot.library.path, to > >> identify potential sources for this path."); > >> > >> Nit: no need for parentheses. > >> > >> Probably also no need to check for the entire message - the first line > >> should suffice. > >> > >> 48 //Add enough characters to make it "too long". > >> 49 for (int i = 0 ; i < tooLongPathSize ; i++) tooLongPath > >> += "a"; > >> > >> This can be done more efficiently and succinctly as: > >> > >> tooLongPath += "a".repeat(5000); > >> > >> There's probably an even better way. :) > >> > >> 60 throw new java.lang.IllegalArgumentException("Test was > >> launched with an invalid argument."); > >> > >> No need to specify "java.lang". > >> > >> Thanks, > >> David > >> ----- > >> > >> > I made the requested changes, and moved the null check as suggested. > >> > > >> > (I agree passing a null for any of these values would be odd, and > >> > unlikely to be done on purpose.) > >> > > >> > It also includes a new jtreg test for this change, which uses > ProcessTools. > >> > > >> > Let me know what you think (inc Serguei + others). > >> > > >> > Best Regards > >> > > >> > Adam Farley > >> > IBM Runtimes > >> > > >> > > >> > coleen.phillimore at oracle.com wrote on 16/08/2019 23:59:53: > >> > > >> >> From: coleen.phillimore at oracle.com > >> >> To: Adam Farley8 > >> >> Cc: David Holmes , hotspot- > dev at openjdk.java.net > >> >> Date: 17/08/2019 00:00 > >> >> Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > >> >> paths are longer than JVM_MAXPATHLEN > >> >> > >> >> > >> > > >> >> On 8/16/19 7:35 AM, Adam Farley8 wrote: > >> >> Hi Coleen, > >> >> > >> >> To confirm your suspicions, I didn't see your responses. No > >> offence intended. > >> >> > >> >> I send a lot of mail so I'm sure I can be caught in people's > spamfilter. :) > >> >> > >> >> > >> >> Responses below. > >> >> > >> >> Best Regards > >> >> > >> >> Adam Farley > >> >> IBM Runtimes > >> >> > >> >> > >> >> coleen.phillimore at oracle.com wrote on 15/08/2019 13:42:51: > >> >> > >> >> > From: coleen.phillimore at oracle.com > >> >> > To: hotspot-dev at openjdk.java.net, Adam Farley8 > >> >> > , David Holmes > >> >> > Date: 15/08/2019 13:43 > >> >> > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > >> >> > paths are longer than JVM_MAXPATHLEN > >> >> > > >> >> > Hi Adam, David noticed that my code review replies only went to the > >> >> > mailing list. So here it is again. > >> >> > Thanks, > >> >> > Coleen > >> >> > > >> >> > On 8/13/19 5:29 PM, coleen.phillimore at oracle.com wrote: > >> >> > > > >> >> > > > >> >> > > On 8/13/19 11:48 AM, Adam Farley8 wrote: > >> >> > >> Hi David, > >> >> > >> > >> >> > >> Since we have two positive reviews (yours and > Serguei's), could you > >> >> > >> sponsor the change please? > >> >> > > > >> >> > > If you get two positive reviews, but then one with > comments, you need > >> >> > > to also answer that third reviews. I had some comments on your > >> >> > > change, which I'll repeat here: > >> >> > > > >> >> > > > >> >> > > https://urldefense.proofpoint.com/v2/url? > >> >> > u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021. > >> >> > > >> >> > >> > 2_webrev_src_hotspot_share_runtime_os.cpp.frames.html&d=DwIDaQ&c=jf_iaSHvJObTbx- > >> >> > siA1ZOg&r=P5m8KWUXJf- > >> >> > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=wjd3KxxgFQv49yjlb4Bndy- > >> >> > F1XV4pbuPZrmemiaFthA&s=xXwflqvuzoEhcREhr-x7rNMVDeroZ8Xh1LnW6NytumE&e= > >> >> > > > >> >> > > > >> >> > > This is code is unnecessarily hard to read and understand: > >> >> > > > >> >> > > 1329 char** os::split_path(const char* path, size_t* n) { > >> >> > > 1330 size_t pathmod = (size_t)0; > >> >> > > 1331 if (n != NULL) { > >> >> > > 1332 pathmod = *n; > >> >> > > 1333 } > >> >> > > 1334 *n = (size_t)0; > >> >> > > > >> >> > > It appears that 'n' is both an input and output parameter of this > >> >> > > function. Can you just make it another input parameter with some > >> >> > > descriptive name. Is it the length of the library name > that you're > >> >> > > looking for? "pathmod" is huh? > >> >> > >> >> The 'n' is both an input and an output, yes. > >> >> > >> >> I could make it another input parameter, but that means modifying the > >> >> method signature. This seemed unnecessary, given that we have an input > >> >> vector we're not using for anything. > >> >> > >> >> It's not a big deal to add a parameter, especially since there's > >> >> only one call site, and the names don't have to be squished up C names. > >> >> > >> >> How about: char** split_path(char* path, size_t file_length, > >> >> size_t* elements) ? > >> > > >> >> > >> >> > >> >> The 'n' input is used as a modifier for the length of the path, as > >> >> mentioned in the comment. I called it "pathmod" because it's a PATH > >> >> length MODIFIER. I couldn't think of a better name that's also concise. > >> >> Would pathlenmod be better? Pathsizemod sounds like we're > making the path > >> >> physically bigger, or maybe that's just me. :) > >> >> > >> >> > > > >> >> > > Then you don't have to check if someone has passed NULL. > There's only > >> >> > > one caller to this from what I see. > >> >> > >> >> I'm not sure I understand this. We'd still need to check for > null, even if > >> >> the pathmod has its own input parameter. I believe adding a > NULL to an int > >> >> causes a segmentation error at runtime. > >> >> > >> >> If you're saying the null check isn't needed because we can > >> ensure anon-null > >> >> is passed in via the only place we call split_path, I disagree > >> that this is a > >> >> future-proof assumption. A null check seems prudent here. > >> >> > >> >> I think the function doesn't make any sense if you pass an output > >> >> parameter as NULL. Or at worst you could add it to the line: > >> >> > >> >> 1335 if (path == NULL || strlen(path) == 0 || n == NULL) { > >> >> 1336 return NULL; > >> >> 1337 } > >> >> 1334 *n = (size_t)0; > >> >> > >> >> But that's just weird. Why would a caller pass a non-null path and > >> >> not want the element count? > >> >> > >> >> Thanks, > >> >> Coleen > >> >> > >> >> > >> >> > > > >> >> > > 1352 char** opath = (char**) NEW_C_HEAP_ARRAY(char*, count, > >> >> > > mtInternal); > >> >> > > 1353 if (opath == NULL) { > >> >> > > 1354 return NULL; > >> >> > > 1355 } > >> >> > > > >> >> > > > >> >> > > Not your change but this calls vm_exit_out_of_memory() if > >> >> > > NEW_C_HEAP_ARRAY fails. It doesn't return NULL so you > don't have to > >> >> > > check. > >> >> > >> >> Seems legit. I'll include this in the .5 version once we have > consensus on > >> >> the other changes. Good spot. > >> >> > >> >> > > > >> >> > > 1375 char* s = (char*)NEW_C_HEAP_ARRAY(char, len + 1, > >> mtInternal); > >> >> > > > >> >> > > Here you want to use NEW_C_HEAP_ARRAY_RETURN_NULL so you > cancheck for > >> >> > > null and free memory. > >> >> > >> >> Good idea. Noted for .5. > >> >> > >> >> Let me know your thoughts on the other points above. > >> >> > >> >> > >> >> > > > >> >> > > > >> >> > > The rest seems okay. > >> >> > > > >> >> > > thanks, > >> >> > > Coleen > >> >> > > > >> >> > >> > >> >> > >> Best Regards > >> >> > >> > >> >> > >> Adam Farley > >> >> > >> IBM Runtimes > >> >> > >> > >> >> > >> > >> >> > >> David Holmes wrote on 12/08/ > 2019 23:32:14: > >> >> > >> > >> >> > >>> From: David Holmes > >> >> > >>> To: Adam Farley8 > >> >> > >>> Cc: hotspot-dev at openjdk.java.net, "serguei.spitsyn at oracle.com" > >> >> > >>> > >> >> > >>> Date: 12/08/2019 23:32 > >> >> > >>> Subject: Re: RFR: JDK-8227021: VM fails if any > sun.boot.library.path > >> >> > >>> paths are longer than JVM_MAXPATHLEN > >> >> > >>> > >> >> > >>> Looks fine. > >> >> > >>> > >> >> > >>> Thanks, > >> >> > >>> David > >> >> > >>> > >> >> > >>> On 13/08/2019 1:19 am, Adam Farley8 wrote: > >> >> > >>>> Hi David, > >> >> > >>>> > >> >> > >>>> Changes made as requested: > >> >> > >>>> https://urldefense.proofpoint.com/v2/url? > >> >> > >>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.4_webrev&d=DwID- > >> >> > >>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > >> >> > >>> > >> >> > >> > >> >> > > >> >> > >> > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=mZM8IR4e_zmrfcsF3XJjoGEMrZb4WtEL7Y6Ugd6Naqg&s=sZ2UKqqUIq0El- > >> >> > >> > >> >> > >>> RsqYz6jmTh4Q2UghwdrQX6of8Lw0E&e= > >> >> > >>>> Best Regards > >> >> > >>>> > >> >> > >>>> Adam Farley > >> >> > >>>> IBM Runtimes > >> >> > >>>> > >> >> > >>>> > >> >> > >>>> David Holmes wrote on 12/08/ > >> 2019 04:55:36: > >> >> > >>>> > >> >> > >>>>> From: David Holmes > >> >> > >>>>> To: Adam Farley8 , > >> >> > >>>>> "serguei.spitsyn at oracle.com" > >> >> > >>>>> Cc: hotspot-dev at openjdk.java.net > >> >> > >>>>> Date: 12/08/2019 04:56 > >> >> > >>>>> Subject: Re: RFR: JDK-8227021: VM fails if any > >> sun.boot.library.path > >> >> > >>>>> paths are longer than JVM_MAXPATHLEN > >> >> > >>>>> > >> >> > >>>>> Hi Adam, > >> >> > >>>>> > >> >> > >>>>> On 10/08/2019 2:47 am, Adam Farley8 wrote: > >> >> > >>>>>> Hi Serguei, David, > >> >> > >>>>>> > >> >> > >>>>>> My turn to apologise for the delay. :) > >> >> > >>>>>> > >> >> > >>>>>> I've modified the code as per Serguei's request. > Take alook and > >> >> > >> let me > >> >> > >>>>>> know if this is the sort of thing you were thinking of. > >> >> > >>>>>> > >> >> > >>>>>> Webrev: https://urldefense.proofpoint.com/v2/url? > >> >> > >>>>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021. > 3_webrev_&d=DwID- > >> >> > >>>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > >> >> > >>>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > >> >> > >>>>> > >> >> > >> > >> >> > > >> >> > >> > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=L19aeFXoR9JIO62QRPFzZObIU8RbhpCtXSvUibD2ISk&e= > >> >> > >> > >> >> > >>>>> I'd prefer to see the helper just as a file static > function rather > >> >> > >> than > >> >> > >>>>> adding it to the os class. > >> >> > >>>>> > >> >> > >>>>> + * supplied array of arrays of chars (a), where n > >> >> > >>>>> > >> >> > >>>>> I assume (a) is meant to refer to the parameter, but > you actually > >> >> > >> called > >> >> > >>>>> it arrayarray. I think "a" or "arr" would suffice. > >> >> > >>>>> > >> >> > >>>>> Thanks, > >> >> > >>>>> David > >> >> > >>>>> > >> >> > >>>>>> Best Regards > >> >> > >>>>>> > >> >> > >>>>>> Adam Farley > >> >> > >>>>>> IBM Runtimes > >> >> > >>>>>> > >> >> > >>>>>> > >> >> > >>>>>> "serguei.spitsyn at oracle.com" > >> wrote on > >> >> > >>>>>> 31/07/2019 17:18:05: > >> >> > >>>>>> > >> >> > >>>>>>> From: "serguei.spitsyn at oracle.com" > > >> >> > >>>>>>> To: Adam Farley8 , David Holmes > >> >> > >>>>>>> > >> >> > >>>>>>> Cc: serviceability-dev , > >> >> > >>>>>>> hotspot-dev at openjdk.java.net > >> >> > >>>>>>> Date: 31/07/2019 17:18 > >> >> > >>>>>>> Subject: Re: RFR: JDK-8227021: VM fails if any > >> >> > >> sun.boot.library.path > >> >> > >>>>>>> paths are longer than JVM_MAXPATHLEN > >> >> > >>>>>>> > >> >> > >>>>>>> Hi Adam, > >> >> > >>>>>>> > >> >> > >>>>>>> It looks Okay to me. > >> >> > >>>>>>> > >> >> > >>>>>>> A couple of minor comments. > >> >> > >>>>>>> > >> >> > >>>>>>> https://urldefense.proofpoint.com/v2/url? > >> >> > >>>>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021. > >> >> > >>>>> 2_webrev_src_hotspot_&d=DwID-g&c=jf_iaSHvJObTbx- > >> >> > >>>>> siA1ZOg&r=P5m8KWUXJf- > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > >> >> > >>>>> > >> >> > >> > >> >> > > >> >> > >> > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NL6tYuwwDod3DSmj-1ztxAywpO8L52HEyO0wvTR05bs&e= > >> >> > >> > >> >> > >>>>>>> share/runtime/os.cpp.frames.html > >> >> > >>>>>>> 1362 //release allocated storage before exiting the vm > >> >> > >>>>>>> 1363 while (i > 0) { > >> >> > >>>>>>> 1364 i--; > >> >> > >>>>>>> 1365 if (opath[i] != NULL) { > >> >> > >>>>>>> 1366 FREE_C_HEAP_ARRAY(char, opath[i]); > >> >> > >>>>>>> 1367 } > >> >> > >>>>>>> 1368 } > >> >> > >>>>>>> 1369 FREE_C_HEAP_ARRAY(char*, opath); > >> >> > >>>>>>> > >> >> > >>>>>>> 1377 //release allocated storage before returning null > >> >> > >>>>>>> 1378 while (i > 0) { > >> >> > >>>>>>> 1379 i--; > >> >> > >>>>>>> 1380 if (opath[i] != NULL) { > >> >> > >>>>>>> 1381 FREE_C_HEAP_ARRAY(char, opath[i]); > >> >> > >>>>>>> 1382 } > >> >> > >>>>>>> 1383 } > >> >> > >>>>>>> 1384 FREE_C_HEAP_ARRAY(char*, opath); > >> >> > >>>>>>> > >> >> > >>>>>>> This duplicated fragments is worth to refactor to > a function. > >> >> > >>>>>>> Also a space is missed at the beginning of the comment. > >> >> > >>>>>>> > >> >> > >>>>>>> > >> >> > >>>>>>> Thanks, > >> >> > >>>>>>> Serguei > >> >> > >>>>>>> > >> >> > >>>>>>> > >> >> > >>>>>>> > >> >> > >>>>>>> On 7/31/19 02:01, Adam Farley8 wrote: > >> >> > >>>>>>> Hi All, > >> >> > >>>>>>> > >> >> > >>>>>>> Reviewers requested for the change below. > >> >> > >>>>>>> > >> >> > >>>>>>> @David - Agreed. Would you be prepared to sponsor > the change? > >> >> > >>>>>>> > >> >> > >>>>>>> Bug: https://urldefense.proofpoint.com/v2/url? > >> >> > >>>>> u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8227021&d=DwID- > >> >> > >>>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > >> >> > >>>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > >> >> > >>>>> > >> >> > >> > >> >> > > >> >> > >> > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=xykJ0KLy9AKWO8zmC0amfR7xxUsvyKEjlf3y7WWOqvE&e= > >> >> > >> > >> >> > >>>>>>> Webrev: https://urldefense.proofpoint.com/v2/url? > >> >> > >>>>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021. > 2_webrev_&d=DwID- > >> >> > >>>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > >> >> > >>>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > >> >> > >>>>> > >> >> > >> > >> >> > > >> >> > >> > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NvIza4VVWG3CiDhmQVmXsghH_4h_c5mFJbHwkCUcut0&e= > >> >> > >> > >> >> > >>>>>>> Best Regards > >> >> > >>>>>>> > >> >> > >>>>>>> Adam Farley > >> >> > >>>>>>> IBM Runtimes > >> >> > >>>>>>> > >> >> > >>>>>>> P.S. Remembered to add the links this time. :) > >> >> > >>>>>>> > >> >> > >>>>>>> > >> >> > >>>>>>> David Holmes wrote on 30/07/2019 > >> >> > >> 03:37:53: > >> >> > >>>>>>>> From: David Holmes > >> >> > >>>>>>>> To: Adam Farley8 > >> >> > >>>>>>>> Cc: hotspot-dev at openjdk.java.net, serviceability-dev > >> >> > >>>>>>>> > >> >> > >>>>>>>> Date: 30/07/2019 03:38 > >> >> > >>>>>>>> Subject: Re: RFR: JDK-8227021: VM fails if any > >> >> > >> sun.boot.library.path > >> >> > >>>>>>>> paths are longer than JVM_MAXPATHLEN > >> >> > >>>>>>>> > >> >> > >>>>>>>> Hi Adam, > >> >> > >>>>>>>> > >> >> > >>>>>>>> On 25/07/2019 3:57 am, Adam Farley8 wrote: > >> >> > >>>>>>>>> Hi David, > >> >> > >>>>>>>>> > >> >> > >>>>>>>>> Welcome back. :) > >> >> > >>>>>>>> Thanks. Sorry for the delay in getting back to this. > >> >> > >>>>>>>> > >> >> > >>>>>>>> I like .v2 as it is much simpler (notwithstanding freeing > >> >> > >>> the already > >> >> > >>>>>>>> allocated arrays adds some complexity - thanks for > >> fixing that). > >> >> > >>>>>>>> > >> >> > >>>>>>>> I'm still not sure we can't optimise things better for > >> >> > >> unchangeable > >> >> > >>>>>>>> properties like the boot libary path, but that's > another RFE. > >> >> > >>>>>>>> > >> >> > >>>>>>>> Thanks, > >> >> > >>>>>>>> David > >> >> > >>>>>>>> > >> >> > >>>>>>> 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 > >> >> > >> 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 > >> > > > > 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 kim.barrett at oracle.com Wed Aug 21 22:01:46 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 21 Aug 2019 18:01:46 -0400 Subject: RFR: 8227054: ServiceThread needs to know about all OopStorage objects In-Reply-To: <6f6ad51f-7025-62b6-f3d4-47b7e716f24c@oracle.com> References: <8181924C-36E6-4B91-9567-150F00286241@oracle.com> <74C738E7-CBDD-4891-ABD6-F8E023372508@oracle.com> <60099477-9AD4-4EFC-AA6F-6EF19D840E67@oracle.com> <164151e7-fec4-8c61-f247-3d5a41c910c1@oracle.com> <96EE9BB8-9EE5-4FBB-B266-785C563BFC2E@oracle.com> <694f8e0c-b00f-54d4-105d-68e6442b2759@oracle.com> <46A102CD-F381-4ACC-852E-F36B9F9DD9DD@oracle.com> <6f6ad51f-7025-62b6-f3d4-47b7e716f24c@oracle.com> Message-ID: > On Aug 21, 2019, at 3:40 AM, Per Liden wrote: > > On 8/20/19 12:32 AM, Kim Barrett wrote: >>> On Aug 12, 2019, at 4:52 AM, Erik ?sterlund wrote: >>> On 2019-08-12 05:26, Kim Barrett wrote: >>>>> On Aug 10, 2019, at 3:52 AM, Erik Osterlund wrote: >>>>> Apart from those two things, I really liked the approach! >>>> Thanks. Hopefully we?re approaching a conclusion on this change. >>> >>> I hope so. >> Finally getting back to this; I got distracted by other things. >> I've removed the macros that were bothering you. >> full: http://cr.openjdk.java.net/~kbarrett/8227054/open.03/ >> incr: http://cr.openjdk.java.net/~kbarrett/8227054/open.03.inc/ > > Thanks, looks good to me! > > /Per Thanks. From kim.barrett at oracle.com Wed Aug 21 22:02:51 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 21 Aug 2019 18:02:51 -0400 Subject: RFR: 8227054: ServiceThread needs to know about all OopStorage objects In-Reply-To: <5b730b9c-2cc6-a4b7-bd0f-dfb2ee7c6b26@oracle.com> References: <8181924C-36E6-4B91-9567-150F00286241@oracle.com> <74C738E7-CBDD-4891-ABD6-F8E023372508@oracle.com> <60099477-9AD4-4EFC-AA6F-6EF19D840E67@oracle.com> <164151e7-fec4-8c61-f247-3d5a41c910c1@oracle.com> <96EE9BB8-9EE5-4FBB-B266-785C563BFC2E@oracle.com> <694f8e0c-b00f-54d4-105d-68e6442b2759@oracle.com> <46A102CD-F381-4ACC-852E-F36B9F9DD9DD@oracle.com> <33C24634-ED46-4CFC-96A1-02C87AABC2B8@oracle.com> <5b730b9c-2cc6-a4b7-bd0f-dfb2ee7c6b26@oracle.com> Message-ID: > On Aug 20, 2019, at 9:41 PM, coleen.phillimore at oracle.com wrote: > > > > On 8/20/19 5:10 PM, Kim Barrett wrote: >>> On Aug 20, 2019, at 3:42 PM, coleen.phillimore at oracle.com wrote: >>> >>> >>> The iterator code seems to have taken on a life of it's own, but the runtime changes still look good. >> Thanks. >> >>> Can you put some comment about why is there a singular iterator and what its purpose is? Is there some implicit use I can't find? >>> >>> + // Construct a singular iterator. The only valid operations are >>> + // destruction/copy/assignment. >>> + Iterator() : >>> + _index(singular_index), >>> + _limit(singular_index) >>> + DEBUG_ONLY(COMMA _category(singular)) {} >>> + >>> >> Does this help? >> >> - // Construct a singular iterator. The only valid operations are >> - // destruction/copy/assignment. >> + // Construct a singular iterator, not associated with any of the sets >> + // (strong, weak, or all) of storage objects. The only valid operations >> + // are destruction/copy/assignment. >> >> Singular iterators exist so you can declare a variable and later assign to it. > > Add this sentence to the comment and I'm fine. I wanted the comment to say why it exists. Coleen and I discussed this offline and have reached agreement on // Construct a singular iterator for later assignment. The only valid // operations are destruction and assignment. for both OopStorageSet::Iterator() and WeakProcessorPhases::Iterator(). From vladimir.kozlov at oracle.com Thu Aug 22 00:06:07 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 21 Aug 2019 17:06:07 -0700 Subject: [14] RFR(XS) 8229848: [Graal] missing Graal intrinsics for Electronic Code Book (ECB) encryption Message-ID: https://cr.openjdk.java.net/~kvn/8229848/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8229848 JDK-8225625 added new intrinsics. Graal test should be adjusted to new intrinsics. I also created Graal issue (in Lab's Jira) to implement intrinsic in Graal. Tested tier1, tier3-graal Thanks, Vladimir From dean.long at oracle.com Thu Aug 22 00:24:30 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 21 Aug 2019 17:24:30 -0700 Subject: [14] RFR(XS) 8229848: [Graal] missing Graal intrinsics for Electronic Code Book (ECB) encryption In-Reply-To: References: Message-ID: <094fe457-a156-47ea-960c-e7aefa8f35d0@oracle.com> Looks good. dl On 8/21/19 5:06 PM, Vladimir Kozlov wrote: > https://cr.openjdk.java.net/~kvn/8229848/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8229848 > > JDK-8225625 added new intrinsics. Graal test should be adjusted to new > intrinsics. > > I also created Graal issue (in Lab's Jira) to implement intrinsic in > Graal. > > Tested tier1, tier3-graal > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Thu Aug 22 01:02:56 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 21 Aug 2019 18:02:56 -0700 Subject: [14] RFR(XS) 8229848: [Graal] missing Graal intrinsics for Electronic Code Book (ECB) encryption In-Reply-To: <094fe457-a156-47ea-960c-e7aefa8f35d0@oracle.com> References: <094fe457-a156-47ea-960c-e7aefa8f35d0@oracle.com> Message-ID: <50003227-bea7-38f2-61f5-e9533dc32db4@oracle.com> Thank you, Dean Vladimir On 8/21/19 5:24 PM, dean.long at oracle.com wrote: > Looks good. > > dl > > On 8/21/19 5:06 PM, Vladimir Kozlov wrote: >> https://cr.openjdk.java.net/~kvn/8229848/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8229848 >> >> JDK-8225625 added new intrinsics. Graal test should be adjusted to new intrinsics. >> >> I also created Graal issue (in Lab's Jira) to implement intrinsic in Graal. >> >> Tested tier1, tier3-graal >> >> Thanks, >> Vladimir > From zgu at redhat.com Thu Aug 22 18:57:02 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 22 Aug 2019 14:57:02 -0400 Subject: RFR 8229919: Support JNI Critical functions in object pinning API on x86_32 platforms Message-ID: <6f6afdc5-cb13-6c8c-98f8-47917793545c@redhat.com> Please review this patch that supports JNI critical functions in object pinning capable GCs on x86_32 platforms. Bug: https://bugs.openjdk.java.net/browse/JDK-8229919 Webrev: http://cr.openjdk.java.net/~zgu/JDK-8229919/webrev.00/ Test: hotspot_gc_shenandoah (fastdebug and release) with 32-bit VM on Linux x86_64. hotspot_gc, hotspot_runtime and hotspot_compiler Submit tests in progress. Thanks, -Zhengyu From serguei.spitsyn at oracle.com Thu Aug 22 21:36:02 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 22 Aug 2019 14:36:02 -0700 Subject: RFR: JDK-8227021: VM fails if any sun.boot.library.path paths are longer than JVM_MAXPATHLEN In-Reply-To: References: <025da83a-6569-f6ac-7590-5b200ed2344f@oracle.com> <8e62fc61-b46b-0033-f182-cb4a2dbf92fd@oracle.com> <4f892f24-4919-4f3a-7e62-0603e08561cc@oracle.com> <4b195206-7a33-4f68-4207-fd214793cf28@oracle.com> Message-ID: Hi Adam, Sorry for the silence. The fix looks good to me. Thank you for adding the test! I'll try to push it today. Thanks, Serguei On 8/20/19 8:06 AM, Adam Farley8 wrote: > Hi Coleen, > > Changes made. Thanks for your advice and patience. > > As for the sponsoring, Serguei volunteered a few changes back. > > Serguei: Are you happy to push the change in its current form? > > Webrev: http://cr.openjdk.java.net/~afarley/8227021.6/webrev/ > > > Best Regards > > Adam Farley > IBM Runtimes > > > coleen.phillimore at oracle.com wrote on 20/08/2019 14:27:09: > > > From: coleen.phillimore at oracle.com > > To: Adam Farley8 , David Holmes > > > > Cc: hotspot-dev at openjdk.java.net > > Date: 20/08/2019 14:27 > > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > > paths are longer than JVM_MAXPATHLEN > > > > > > This looks great.? Thank you for making the changes. > > > > One tiny thing that I don't want to see another webrev for. Can you > change: > > > +/* > > + * Frees all memory allocated on the heap for the > > + * supplied array of arrays of chars (a), where n > > + * is the number of elements in the array. > > + */ > > to > > > +// > > +// Frees all memory allocated on the heap for the > > +// supplied array of arrays of chars (a), where n > > +// is the number of elements in the array. > > +// > > And the big comment to have // at the top of split_path? > > > > We prefer // comments in the code.? Do you need a sponsor? > > > > Thanks, > > Coleen > > > On 8/20/19 9:13 AM, Adam Farley8 wrote: > > Hi David, > > > > Good advice. Changes made as requested. > > > > Webrev: http://cr.openjdk.java.net/~afarley/8227021.6/webrev/ > > > > > Does anyone have further concerns or changes to propose? > > > > Best Regards > > > > Adam Farley > > IBM Runtimes > > > > > > David Holmes wrote on 20/08/2019 12:55:26: > > > > > From: David Holmes > > > To: Adam Farley8 , > coleen.phillimore at oracle.com > > > Cc: hotspot-dev at openjdk.java.net > > > Date: 20/08/2019 12:55 > > > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > > > paths are longer than JVM_MAXPATHLEN > > > > > > Hi Adam, > > > > > > On 20/08/2019 1:21 am, Adam Farley8 wrote: > > > > Hi Coleen, David, > > > > > > > > Here's the new webrev: https://urldefense.proofpoint.com/v2/url? > > > u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.5_webrev_&d=DwID- > > > g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > > > > > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=zaU5bibnUdHVncMttyVGbYf1yzDRUt26f9raqqKlJm0&s=QPe5l0tueNKISo62mJJ2RdRLUg_LsrhapCgVNJ0W3yQ&e= > > > > > > In this comment: > > > > > > ! ?* in use, you can pass the length of that in n, to ensure > > > ! ?* we detect if any path exceeds the maximum path length > > > ! ?* once prepended onto the sub-path/file name. > > > ? ? * It is the callers responsibility to: > > > ? ? * ? a> check the value of n, and n may be 0. > > > > > > the three references to 'n' should be to the new file_name_length > parameter. > > > > > > Looking at the test: > > > > > > ? ?2 ?* Copyright (c) 2019, 2019, Oracle and/or its affiliates. All > > > rights reserved. > > > > > > For a new file there is only a single year specified so this > should be: > > > > > > ? ?2 ?* Copyright (c) 2019, Oracle and/or its affiliates. All rights > > > reserved. > > > > > > ? 31 ?* @run main TestSunBootLibraryPath > > > > > > As this just launches another VM it is more efficient to use "@run > driver". > > > > > > ? 35 import java.lang.IllegalArgumentException; > > > > > > Nit: java.lang.* is implicitly imported. > > > > > > ? 39 ? ? static String expectedErrorMessage =("The VM tried to use a > > > path that exceeds the maximum path length for " > > > ? 40 ? ? ? ? ? ? ? ? ? + "this system. Review > > > path-containing parameters and properties, such as " > > > ? 41 ? ? ? ? ? ? ? ? ? + "sun.boot.library.path, to > > > identify potential sources for this path."); > > > > > > Nit: no need for parentheses. > > > > > > Probably also no need to check for the entire message - the first > line > > > should suffice. > > > > > > ? 48 ? ? ? ? ? ? //Add enough characters to make it "too long". > > > ? 49 ? ? ? ? ? ? for (int i = 0 ; i < tooLongPathSize ; i++) > tooLongPath > > > += "a"; > > > > > > This can be done more efficiently and succinctly as: > > > > > > tooLongPath += "a".repeat(5000); > > > > > > There's probably an even better way. :) > > > > > > ? 60 ? ? ? ? ? ? throw new > java.lang.IllegalArgumentException("Test was > > > launched with an invalid argument."); > > > > > > No need to specify "java.lang". > > > > > > Thanks, > > > David > > > ----- > > > > > > > I made the requested changes, and moved the null check as suggested. > > > > > > > > (I agree passing a null for any of these values would be odd, and > > > > unlikely to be done on purpose.) > > > > > > > > It also includes a new jtreg test for this change, which uses > > ProcessTools. > > > > > > > > Let me know what you think (inc Serguei + others). > > > > > > > > Best Regards > > > > > > > > Adam Farley > > > > IBM Runtimes > > > > > > > > > > > > coleen.phillimore at oracle.com wrote on 16/08/2019 23:59:53: > > > > > > > >> From: coleen.phillimore at oracle.com > > > >> To: Adam Farley8 > > > >> Cc: David Holmes , > ?hotspot-dev at openjdk.java.net > > > >> Date: 17/08/2019 00:00 > > > >> Subject: Re: RFR: JDK-8227021: ?VM fails if any > sun.boot.library.path > > > >> paths are longer than JVM_MAXPATHLEN > > > >> > > > >> > > > > > > > >> On 8/16/19 7:35 AM, Adam Farley8 ?wrote: > > > >> Hi Coleen, > > > >> > > > >> To confirm your suspicions, I didn't see your responses. No > > > offence ?intended. > > > >> > > > >> I send a lot of mail so I'm sure I can be caught in people's > > spamfilter. :) > > > >> > > > >> > > > >> Responses below. > > > >> > > > >> Best Regards > > > >> > > > >> Adam Farley > > > >> IBM Runtimes > > > >> > > > >> > > > >> coleen.phillimore at oracle.com wrote on 15/08/2019 13:42:51: > > > >> > > > >> > From: coleen.phillimore at oracle.com > > > >> > To: hotspot-dev at openjdk.java.net, Adam Farley8 > > > >> > , David Holmes > > > >> > Date: 15/08/2019 13:43 > > > >> > Subject: Re: RFR: JDK-8227021: VM fails if any > sun.boot.library.path > > > >> > paths are longer than JVM_MAXPATHLEN > > > >> > > > > >> > Hi Adam,? David noticed that my code review replies only > ?went to the > > > >> > mailing list.? So here it is again. > > > >> > Thanks, > > > >> > Coleen > > > >> > > > > >> > On 8/13/19 5:29 PM, coleen.phillimore at oracle.com wrote: > > > >> > > > > > >> > > > > > >> > > On 8/13/19 11:48 AM, Adam Farley8 wrote: > > > >> > >> Hi David, > > > >> > >> > > > >> > >> Since we have two positive reviews (yours and Serguei's), > ?could you > > > >> > >> sponsor the change please? > > > >> > > > > > >> > > If you get two positive reviews, but then one with > > comments, ?you need > > > >> > > to also answer that third reviews.? I had some comments ?on > your > > > >> > > change, which I'll repeat here: > > > >> > > > > > >> > > > > > >> > > https://urldefense.proofpoint.com/v2/url? > > > >> > u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021. > > > >> > > > > >> > > > > > > 2_webrev_src_hotspot_share_runtime_os.cpp.frames.html&d=DwIDaQ&c=jf_iaSHvJObTbx- > > > >> > siA1ZOg&r=P5m8KWUXJf- > > > >> > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=wjd3KxxgFQv49yjlb4Bndy- > > > >> > > F1XV4pbuPZrmemiaFthA&s=xXwflqvuzoEhcREhr-x7rNMVDeroZ8Xh1LnW6NytumE&e= > > > >> > > > > > >> > > > > > >> > > This is code is unnecessarily hard to read and understand: > > > >> > > > > > >> > > 1329 char** os::split_path(const char* path, size_t* n) ?{ > > > >> > > 1330 size_t pathmod = (size_t)0; > > > >> > > 1331 if (n != NULL) { > > > >> > > 1332 pathmod = *n; > > > >> > > 1333 } > > > >> > > 1334 *n = (size_t)0; > > > >> > > > > > >> > > It appears that 'n' is both an input and output parameter > ?of this > > > >> > > function.? Can you just make it another input parameter > ?with some > > > >> > > descriptive name.? Is it the length of the library ?name > that you're > > > >> > > looking for?? "pathmod" is huh? > > > >> > > > >> The 'n' is both an input and an output, yes. > > > >> > > > >> I could make it another input parameter, but that means > modifying ?the > > > >> method signature. This seemed unnecessary, given that we have > an input > > > >> vector we're not using for anything. > > > >> > > > >> It's not a big deal to add a parameter, especially since there's > > > >> only one call site, and the names don't have to be squished up > C names. > > > >> > > > >> How about:? char** split_path(char* path, size_t file_length, > > > >> size_t* elements) ? > > > > > > > >> > > > >> > > > >> The 'n' input is used as a modifier for the length of the path, as > > > >> mentioned in the comment. I called it "pathmod" because ?it's a > PATH > > > >> length MODIFIER. I couldn't think of a better name that's also > concise. > > > >> Would pathlenmod be better? Pathsizemod sounds like we're > > making the ?path > > > >> physically bigger, or maybe that's just me. :) > > > >> > > > >> > > > > > >> > > Then you don't have to check if someone has passed NULL. > There's only > > > >> > > one caller to this from what I see. > > > >> > > > >> I'm not sure I understand this. We'd still need to check for > > null, ?even if > > > >> the pathmod has its own input parameter. I believe adding a > > NULL to ?an int > > > >> causes a segmentation error at runtime. > > > >> > > > >> If you're saying the null check isn't needed because we can > > > ensure ?anon-null > > > >> is passed in via the only place we call split_path, I disagree > > > that ?this is a > > > >> future-proof assumption. A null check seems prudent here. > > > >> > > > >> I think the function doesn't make any sense if you pass an output > > > >> parameter as NULL.? Or at worst you could add it to the line: > > > >> > > > >> 1335 if (path == NULL || strlen(path) == 0 || n == NULL) { > > > >> 1336 ? ?? return NULL; > > > >> 1337 } > > > >> 1334 *n = (size_t)0; > > > >> > > > >> But that's just weird. Why would a caller pass a non-null path and > > > >> not want the element count? > > > >> > > > >> Thanks, > > > >> Coleen > > > >> > > > >> > > > >> > > > > > >> > > 1352?? char** opath = (char**) NEW_C_HEAP_ARRAY(char*, ?count, > > > >> > > mtInternal); > > > >> > > 1353?? if (opath == NULL) { > > > >> > > 1354???? return NULL; > > > >> > > 1355?? } > > > >> > > > > > >> > > > > > >> > > Not your change but this calls vm_exit_out_of_memory() if > > > >> > > NEW_C_HEAP_ARRAY fails.? It doesn't return NULL so ?you > don't have to > > > >> > > check. > > > >> > > > >> Seems legit. I'll include this in the .5 version once we have > > consensus ?on > > > >> the other changes. Good spot. > > > >> > > > >> > > > > > >> > > 1375???? char* s = (char*)NEW_C_HEAP_ARRAY(char, ?len + 1, > > > mtInternal); > > > >> > > > > > >> > > Here you want to use NEW_C_HEAP_ARRAY_RETURN_NULL so you > > ?cancheck for > > > >> > > null and free memory. > > > >> > > > >> Good idea. Noted for .5. > > > >> > > > >> Let me know your thoughts on the other points above. > > > >> > > > >> > > > >> > > > > > >> > > > > > >> > > The rest seems okay. > > > >> > > > > > >> > > thanks, > > > >> > > Coleen > > > >> > > > > > >> > >> > > > >> > >> Best Regards > > > >> > >> > > > >> > >> Adam Farley > > > >> > >> IBM Runtimes > > > >> > >> > > > >> > >> > > > >> > >> David Holmes wrote on ?12/08/ > > 2019 23:32:14: > > > >> > >> > > > >> > >>> From: David Holmes > > > >> > >>> To: Adam Farley8 > > > >> > >>> Cc: hotspot-dev at openjdk.java.net, > "serguei.spitsyn at oracle.com" > > > >> > >>> > > > >> > >>> Date: 12/08/2019 23:32 > > > >> > >>> Subject: Re: RFR: JDK-8227021: VM fails if any > > sun.boot.library.path > > > >> > >>> paths are longer than JVM_MAXPATHLEN > > > >> > >>> > > > >> > >>> Looks fine. > > > >> > >>> > > > >> > >>> Thanks, > > > >> > >>> David > > > >> > >>> > > > >> > >>> On 13/08/2019 1:19 am, Adam Farley8 wrote: > > > >> > >>>> Hi David, > > > >> > >>>> > > > >> > >>>> Changes made as requested: > > > >> > >>>> https://urldefense.proofpoint.com/v2/url? > > > >> > >>> > u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.4_webrev&d=DwID- > > > >> > >>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > > >> > >>> > > > >> > >> > > > >> > > > > >> > > > > > > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=mZM8IR4e_zmrfcsF3XJjoGEMrZb4WtEL7Y6Ugd6Naqg&s=sZ2UKqqUIq0El- > > > >> > >> > > > >> > >>> RsqYz6jmTh4Q2UghwdrQX6of8Lw0E&e= > > > >> > >>>> Best Regards > > > >> > >>>> > > > >> > >>>> Adam Farley > > > >> > >>>> IBM Runtimes > > > >> > >>>> > > > >> > >>>> > > > >> > >>>> David Holmes ?wrote on 12/08/ > > > 2019 04:55:36: > > > >> > >>>> > > > >> > >>>>> From: David Holmes > > > >> > >>>>> To: Adam Farley8 , > > > >> > >>>>> "serguei.spitsyn at oracle.com" > > > >> > >>>>> Cc: hotspot-dev at openjdk.java.net > > > >> > >>>>> Date: 12/08/2019 04:56 > > > >> > >>>>> Subject: Re: RFR: JDK-8227021: VM ?fails if any > > > sun.boot.library.path > > > >> > >>>>> paths are longer than JVM_MAXPATHLEN > > > >> > >>>>> > > > >> > >>>>> Hi Adam, > > > >> > >>>>> > > > >> > >>>>> On 10/08/2019 2:47 am, Adam Farley8 wrote: > > > >> > >>>>>> Hi Serguei, David, > > > >> > >>>>>> > > > >> > >>>>>> My turn to apologise for the delay. ?:) > > > >> > >>>>>> > > > >> > >>>>>> I've modified the code as per Serguei's ?request. > Takealook? and > > > >> > >> let me > > > >> > >>>>>> know if this is the sort of thing you ?were thinking of. > > > >> > >>>>>> > > > >> > >>>>>> Webrev: https://urldefense.proofpoint.com/v2/url? > > > >> > >>>>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021. > > 3_webrev_&d=DwID- > > > >> > >>>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > > >> > >>>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > > > >> > >>>>> > > > >> > >> > > > >> > > > > >> > > > > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=L19aeFXoR9JIO62QRPFzZObIU8RbhpCtXSvUibD2ISk&e= > > > >> > >> > > > >> > >>>>> I'd prefer to see the helper just as a file ?static > > function rather > > > >> > >> than > > > >> > >>>>> adding it to the os class. > > > >> > >>>>> > > > >> > >>>>> +? * supplied array of arrays of chars ?(a), where n > > > >> > >>>>> > > > >> > >>>>> I assume (a) is meant to refer to the parameter, ?but > > you actually > > > >> > >> called > > > >> > >>>>> it arrayarray. I think "a" or ?"arr" would suffice. > > > >> > >>>>> > > > >> > >>>>> Thanks, > > > >> > >>>>> David > > > >> > >>>>> > > > >> > >>>>>> Best Regards > > > >> > >>>>>> > > > >> > >>>>>> Adam Farley > > > >> > >>>>>> IBM Runtimes > > > >> > >>>>>> > > > >> > >>>>>> > > > >> > >>>>>> "serguei.spitsyn at oracle.com" > > > ? wrote on > > > >> > >>>>>> 31/07/2019 17:18:05: > > > >> > >>>>>> > > > >> > >>>>>>> From: "serguei.spitsyn at oracle.com" > > > > > >> > >>>>>>> To: Adam Farley8 , ?David? Holmes > > > >> > >>>>>>> > > > >> > >>>>>>> Cc: serviceability-dev > , > > > >> > >>>>>>> hotspot-dev at openjdk.java.net > > > >> > >>>>>>> Date: 31/07/2019 17:18 > > > >> > >>>>>>> Subject: Re: RFR: JDK-8227021: VM fails if any > > > >> > >> sun.boot.library.path > > > >> > >>>>>>> paths are longer than JVM_MAXPATHLEN > > > >> > >>>>>>> > > > >> > >>>>>>> Hi Adam, > > > >> > >>>>>>> > > > >> > >>>>>>> It looks Okay to me. > > > >> > >>>>>>> > > > >> > >>>>>>> A couple of minor comments. > > > >> > >>>>>>> > > > >> > >>>>>>> https://urldefense.proofpoint.com/v2/url? > > > >> > >>>>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021. > > > >> > >>>>> 2_webrev_src_hotspot_&d=DwID-g&c=jf_iaSHvJObTbx- > > > >> > >>>>> siA1ZOg&r=P5m8KWUXJf- > > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > > > >> > >>>>> > > > >> > >> > > > >> > > > > >> > > > > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NL6tYuwwDod3DSmj-1ztxAywpO8L52HEyO0wvTR05bs&e= > > > >> > >> > > > >> > >>>>>>> share/runtime/os.cpp.frames.html > > > >> > >>>>>>> 1362 ?//release? allocated storage? before exiting the vm > > > >> > >>>>>>> 1363 ?while (i > 0) { > > > >> > >>>>>>> 1364 ? ? ?i--; > > > >> > >>>>>>> 1365 ? ? ?if (opath[i] != NULL)? { > > > >> > >>>>>>> 1366 ? ? ? ?FREE_C_HEAP_ARRAY(char,?? opath[i]); > > > >> > >>>>>>> 1367 ? ? ?} > > > >> > >>>>>>> 1368 ?} > > > >> > >>>>>>> 1369 ?FREE_C_HEAP_ARRAY(char*, opath); > > > >> > >>>>>>> > > > >> > >>>>>>> 1377 ?//release allocated storage before returning? null > > > >> > >>>>>>> 1378 ?while (i > 0) { > > > >> > >>>>>>> 1379 ? ? ?i--; > > > >> > >>>>>>> 1380 ? ? ?if (opath[i] != NULL)? { > > > >> > >>>>>>> 1381 ? ? ? ?FREE_C_HEAP_ARRAY(char,?? opath[i]); > > > >> > >>>>>>> 1382 ? ? ?} > > > >> > >>>>>>> 1383 ?} > > > >> > >>>>>>> 1384 ?FREE_C_HEAP_ARRAY(char*, opath); > > > >> > >>>>>>> > > > >> > >>>>>>> This duplicated fragments is worth ?to refactor to a > function. > > > >> > >>>>>>> Also a space is missed at the beginning ?of the comment. > > > >> > >>>>>>> > > > >> > >>>>>>> > > > >> > >>>>>>> Thanks, > > > >> > >>>>>>> Serguei > > > >> > >>>>>>> > > > >> > >>>>>>> > > > >> > >>>>>>> > > > >> > >>>>>>> On 7/31/19 02:01, Adam Farley8 wrote: > > > >> > >>>>>>> Hi All, > > > >> > >>>>>>> > > > >> > >>>>>>> Reviewers requested for the change ?below. > > > >> > >>>>>>> > > > >> > >>>>>>> @David - Agreed. Would you be prepared ?to sponsor > the change? > > > >> > >>>>>>> > > > >> > >>>>>>> Bug: https://urldefense.proofpoint.com/v2/url? > > > >> > >>>>> > u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8227021&d=DwID- > > > >> > >>>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > > >> > >>>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > > > >> > >>>>> > > > >> > >> > > > >> > > > > >> > > > > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=xykJ0KLy9AKWO8zmC0amfR7xxUsvyKEjlf3y7WWOqvE&e= > > > >> > >> > > > >> > >>>>>>> Webrev: https://urldefense.proofpoint.com/v2/url? > > > >> > >>>>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021. > > 2_webrev_&d=DwID- > > > >> > >>>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > > >> > >>>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > > > >> > >>>>> > > > >> > >> > > > >> > > > > >> > > > > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NvIza4VVWG3CiDhmQVmXsghH_4h_c5mFJbHwkCUcut0&e= > > > >> > >> > > > >> > >>>>>>> Best Regards > > > >> > >>>>>>> > > > >> > >>>>>>> Adam Farley > > > >> > >>>>>>> IBM Runtimes > > > >> > >>>>>>> > > > >> > >>>>>>> P.S. Remembered to add the links ?this time. :) > > > >> > >>>>>>> > > > >> > >>>>>>> > > > >> > >>>>>>> David Holmes ?wrote on > 30/07/2019 > > > >> > >> 03:37:53: > > > >> > >>>>>>>> From: David Holmes > > > >> > >>>>>>>> To: Adam Farley8 > > > >> > >>>>>>>> Cc: hotspot-dev at openjdk.java.net, ?serviceability-dev > > > >> > >>>>>>>> > > > >> > >>>>>>>> Date: 30/07/2019 03:38 > > > >> > >>>>>>>> Subject: Re: RFR: JDK-8227021: ?VM fails if any > > > >> > >> sun.boot.library.path > > > >> > >>>>>>>> paths are longer than JVM_MAXPATHLEN > > > >> > >>>>>>>> > > > >> > >>>>>>>> Hi Adam, > > > >> > >>>>>>>> > > > >> > >>>>>>>> On 25/07/2019 3:57 am, Adam ?Farley8 wrote: > > > >> > >>>>>>>>> Hi David, > > > >> > >>>>>>>>> > > > >> > >>>>>>>>> Welcome back. :) > > > >> > >>>>>>>> Thanks. Sorry for the delay ?in getting back to this. > > > >> > >>>>>>>> > > > >> > >>>>>>>> I like .v2 as it is much simpler ?(notwithstanding > freeing > > > >> > >>> the? already > > > >> > >>>>>>>> allocated arrays adds some complexity ?- thanks for > > > fixing that). > > > >> > >>>>>>>> > > > >> > >>>>>>>> I'm still not sure we can't ?optimise things better for > > > >> > >> unchangeable > > > >> > >>>>>>>> properties like the boot libary ?path, but that's > > another? RFE. > > > >> > >>>>>>>> > > > >> > >>>>>>>> Thanks, > > > >> > >>>>>>>> David > > > >> > >>>>>>>> > > > >> > >>>>>>> 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 > > > >> > >> 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 > > > > > > > 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 adam.farley at uk.ibm.com Fri Aug 23 10:26:59 2019 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Fri, 23 Aug 2019 10:26:59 +0000 Subject: RFR: JDK-8227021: VM fails if any sun.boot.library.path paths are longer than JVM_MAXPATHLEN In-Reply-To: <9a9b7e7f-b7dc-11b7-9c56-39104249038c@oracle.com> References: <025da83a-6569-f6ac-7590-5b200ed2344f@oracle.com> <8e62fc61-b46b-0033-f182-cb4a2dbf92fd@oracle.com> <4f892f24-4919-4f3a-7e62-0603e08561cc@oracle.com> <4b195206-7a33-4f68-4207-fd214793cf28@oracle.com> <9a9b7e7f-b7dc-11b7-9c56-39104249038c@oracle.com> Message-ID: Thanks Serguei. :) Best Regards Adam Farley IBM Runtimes "serguei.spitsyn at oracle.com" wrote on 23/08/2019 11:19:48: > From: "serguei.spitsyn at oracle.com" > To: Adam Farley8 , coleen.phillimore at oracle.com > Cc: David Holmes , hotspot-dev at openjdk.java.net > Date: 23/08/2019 11:20 > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > paths are longer than JVM_MAXPATHLEN > > Hi Adam, > > Pushed. > > Thanks, > Serguei > > > On 8/22/19 14:36, serguei.spitsyn at oracle.com wrote: > Hi Adam, > > Sorry for the silence. > The fix looks good to me. > Thank you for adding the test! > I'll try to push it today. > > Thanks, > Serguei > > On 8/20/19 8:06 AM, Adam Farley8 wrote: > Hi Coleen, > > Changes made. Thanks for your advice and patience. > > As for the sponsoring, Serguei volunteered a few changes back. > > Serguei: Are you happy to push the change in its current form? > > Webrev: http://cr.openjdk.java.net/~afarley/8227021.6/webrev/ > > Best Regards > > Adam Farley > IBM Runtimes > > > coleen.phillimore at oracle.com wrote on 20/08/2019 14:27:09: > > > From: coleen.phillimore at oracle.com > > To: Adam Farley8 , David Holmes > > > > Cc: hotspot-dev at openjdk.java.net > > Date: 20/08/2019 14:27 > > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > > paths are longer than JVM_MAXPATHLEN > > > > > > This looks great. Thank you for making the changes. > > > > One tiny thing that I don't want to see another webrev for. Can you change: > > > +/* > > + * Frees all memory allocated on the heap for the > > + * supplied array of arrays of chars (a), where n > > + * is the number of elements in the array. > > + */ > > to > > > +// > > +// Frees all memory allocated on the heap for the > > +// supplied array of arrays of chars (a), where n > > +// is the number of elements in the array. > > +// > > And the big comment to have // at the top of split_path? > > > > We prefer // comments in the code. Do you need a sponsor? > > > > Thanks, > > Coleen > > > On 8/20/19 9:13 AM, Adam Farley8 wrote: > > Hi David, > > > > Good advice. Changes made as requested. > > > > Webrev: http://cr.openjdk.java.net/~afarley/8227021.6/webrev/ > > > > Does anyone have further concerns or changes to propose? > > > > Best Regards > > > > Adam Farley > > IBM Runtimes > > > > > > David Holmes wrote on 20/08/2019 12:55:26: > > > > > From: David Holmes > > > To: Adam Farley8 , coleen.phillimore at oracle.com > > > Cc: hotspot-dev at openjdk.java.net > > > Date: 20/08/2019 12:55 > > > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > > > paths are longer than JVM_MAXPATHLEN > > > > > > Hi Adam, > > > > > > On 20/08/2019 1:21 am, Adam Farley8 wrote: > > > > Hi Coleen, David, > > > > > > > > Here's the new webrev: https://urldefense.proofpoint.com/v2/url? > > > u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021.5_webrev_&d=DwID- > > > g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > > > > > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=zaU5bibnUdHVncMttyVGbYf1yzDRUt26f9raqqKlJm0&s=QPe5l0tueNKISo62mJJ2RdRLUg_LsrhapCgVNJ0W3yQ&e= > > > > > > In this comment: > > > > > > ! * in use, you can pass the length of that in n, to ensure > > > ! * we detect if any path exceeds the maximum path length > > > ! * once prepended onto the sub-path/file name. > > > * It is the callers responsibility to: > > > * a> check the value of n, and n may be 0. > > > > > > the three references to 'n' should be to the new > file_name_length parameter. > > > > > > Looking at the test: > > > > > > 2 * Copyright (c) 2019, 2019, Oracle and/or its affiliates. All > > > rights reserved. > > > > > > For a new file there is only a single year specified so this should be: > > > > > > 2 * Copyright (c) 2019, Oracle and/or its affiliates. All rights > > > reserved. > > > > > > 31 * @run main TestSunBootLibraryPath > > > > > > As this just launches another VM it is more efficient to use > "@run driver". > > > > > > 35 import java.lang.IllegalArgumentException; > > > > > > Nit: java.lang.* is implicitly imported. > > > > > > 39 static String expectedErrorMessage =("The VM tried to use a > > > path that exceeds the maximum path length for " > > > 40 + "this system. Review > > > path-containing parameters and properties, such as " > > > 41 + "sun.boot.library.path, to > > > identify potential sources for this path."); > > > > > > Nit: no need for parentheses. > > > > > > Probably also no need to check for the entire message - the first line > > > should suffice. > > > > > > 48 //Add enough characters to make it "too long". > > > 49 for (int i = 0 ; i < tooLongPathSize ; i++) tooLongPath > > > += "a"; > > > > > > This can be done more efficiently and succinctly as: > > > > > > tooLongPath += "a".repeat(5000); > > > > > > There's probably an even better way. :) > > > > > > 60 throw new java.lang.IllegalArgumentException("Test was > > > launched with an invalid argument."); > > > > > > No need to specify "java.lang". > > > > > > Thanks, > > > David > > > ----- > > > > > > > I made the requested changes, and moved the null check as suggested. > > > > > > > > (I agree passing a null for any of these values would be odd, and > > > > unlikely to be done on purpose.) > > > > > > > > It also includes a new jtreg test for this change, which uses > > ProcessTools. > > > > > > > > Let me know what you think (inc Serguei + others). > > > > > > > > Best Regards > > > > > > > > Adam Farley > > > > IBM Runtimes > > > > > > > > > > > > coleen.phillimore at oracle.com wrote on 16/08/2019 23:59:53: > > > > > > > >> From: coleen.phillimore at oracle.com > > > >> To: Adam Farley8 > > > >> Cc: David Holmes , hotspot- > dev at openjdk.java.net > > > >> Date: 17/08/2019 00:00 > > > >> Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > > > >> paths are longer than JVM_MAXPATHLEN > > > >> > > > >> > > > > > > > >> On 8/16/19 7:35 AM, Adam Farley8 wrote: > > > >> Hi Coleen, > > > >> > > > >> To confirm your suspicions, I didn't see your responses. No > > > offence intended. > > > >> > > > >> I send a lot of mail so I'm sure I can be caught in people's > > spamfilter. :) > > > >> > > > >> > > > >> Responses below. > > > >> > > > >> Best Regards > > > >> > > > >> Adam Farley > > > >> IBM Runtimes > > > >> > > > >> > > > >> coleen.phillimore at oracle.com wrote on 15/08/2019 13:42:51: > > > >> > > > >> > From: coleen.phillimore at oracle.com > > > >> > To: hotspot-dev at openjdk.java.net, Adam Farley8 > > > >> > , David Holmes > > > >> > Date: 15/08/2019 13:43 > > > >> > Subject: Re: RFR: JDK-8227021: VM fails if any sun.boot.library.path > > > >> > paths are longer than JVM_MAXPATHLEN > > > >> > > > > >> > Hi Adam, David noticed that my code review replies only went to the > > > >> > mailing list. So here it is again. > > > >> > Thanks, > > > >> > Coleen > > > >> > > > > >> > On 8/13/19 5:29 PM, coleen.phillimore at oracle.com wrote: > > > >> > > > > > >> > > > > > >> > > On 8/13/19 11:48 AM, Adam Farley8 wrote: > > > >> > >> Hi David, > > > >> > >> > > > >> > >> Since we have two positive reviews (yours and > Serguei's), could you > > > >> > >> sponsor the change please? > > > >> > > > > > >> > > If you get two positive reviews, but then one with > > comments, you need > > > >> > > to also answer that third reviews. I had some comments on your > > > >> > > change, which I'll repeat here: > > > >> > > > > > >> > > > > > >> > > https://urldefense.proofpoint.com/v2/url? > > > >> > u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021. > > > >> > > > > >> > > > > > > 2_webrev_src_hotspot_share_runtime_os.cpp.frames.html&d=DwIDaQ&c=jf_iaSHvJObTbx- > > > >> > siA1ZOg&r=P5m8KWUXJf- > > > >> > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=wjd3KxxgFQv49yjlb4Bndy- > > > >> > F1XV4pbuPZrmemiaFthA&s=xXwflqvuzoEhcREhr-x7rNMVDeroZ8Xh1LnW6NytumE&e= > > > >> > > > > > >> > > > > > >> > > This is code is unnecessarily hard to read and understand: > > > >> > > > > > >> > > 1329 char** os::split_path(const char* path, size_t* n) { > > > >> > > 1330 size_t pathmod = (size_t)0; > > > >> > > 1331 if (n != NULL) { > > > >> > > 1332 pathmod = *n; > > > >> > > 1333 } > > > >> > > 1334 *n = (size_t)0; > > > >> > > > > > >> > > It appears that 'n' is both an input and output parameter of this > > > >> > > function. Can you just make it another input parameter with some > > > >> > > descriptive name. Is it the length of the library name > that you're > > > >> > > looking for? "pathmod" is huh? > > > >> > > > >> The 'n' is both an input and an output, yes. > > > >> > > > >> I could make it another input parameter, but that means modifying the > > > >> method signature. This seemed unnecessary, given that we have an input > > > >> vector we're not using for anything. > > > >> > > > >> It's not a big deal to add a parameter, especially since there's > > > >> only one call site, and the names don't have to be squished up C names. > > > >> > > > >> How about: char** split_path(char* path, size_t file_length, > > > >> size_t* elements) ? > > > > > > > >> > > > >> > > > >> The 'n' input is used as a modifier for the length of the path, as > > > >> mentioned in the comment. I called it "pathmod" because it's a PATH > > > >> length MODIFIER. I couldn't think of a better name that's also concise. > > > >> Would pathlenmod be better? Pathsizemod sounds like we're > > making the path > > > >> physically bigger, or maybe that's just me. :) > > > >> > > > >> > > > > > >> > > Then you don't have to check if someone has passed NULL. > There's only > > > >> > > one caller to this from what I see. > > > >> > > > >> I'm not sure I understand this. We'd still need to check for > > null, even if > > > >> the pathmod has its own input parameter. I believe adding a > > NULL to an int > > > >> causes a segmentation error at runtime. > > > >> > > > >> If you're saying the null check isn't needed because we can > > > ensure anon-null > > > >> is passed in via the only place we call split_path, I disagree > > > that this is a > > > >> future-proof assumption. A null check seems prudent here. > > > >> > > > >> I think the function doesn't make any sense if you pass an output > > > >> parameter as NULL. Or at worst you could add it to the line: > > > >> > > > >> 1335 if (path == NULL || strlen(path) == 0 || n == NULL) { > > > >> 1336 return NULL; > > > >> 1337 } > > > >> 1334 *n = (size_t)0; > > > >> > > > >> But that's just weird. Why would a caller pass a non-null path and > > > >> not want the element count? > > > >> > > > >> Thanks, > > > >> Coleen > > > >> > > > >> > > > >> > > > > > >> > > 1352 char** opath = (char**) NEW_C_HEAP_ARRAY(char*, count, > > > >> > > mtInternal); > > > >> > > 1353 if (opath == NULL) { > > > >> > > 1354 return NULL; > > > >> > > 1355 } > > > >> > > > > > >> > > > > > >> > > Not your change but this calls vm_exit_out_of_memory() if > > > >> > > NEW_C_HEAP_ARRAY fails. It doesn't return NULL so you > don't have to > > > >> > > check. > > > >> > > > >> Seems legit. I'll include this in the .5 version once we have > > consensus on > > > >> the other changes. Good spot. > > > >> > > > >> > > > > > >> > > 1375 char* s = (char*)NEW_C_HEAP_ARRAY(char, len + 1, > > > mtInternal); > > > >> > > > > > >> > > Here you want to use NEW_C_HEAP_ARRAY_RETURN_NULL so you > > cancheck for > > > >> > > null and free memory. > > > >> > > > >> Good idea. Noted for .5. > > > >> > > > >> Let me know your thoughts on the other points above. > > > >> > > > >> > > > >> > > > > > >> > > > > > >> > > The rest seems okay. > > > >> > > > > > >> > > thanks, > > > >> > > Coleen > > > >> > > > > > >> > >> > > > >> > >> Best Regards > > > >> > >> > > > >> > >> Adam Farley > > > >> > >> IBM Runtimes > > > >> > >> > > > >> > >> > > > >> > >> David Holmes wrote on 12/08/ > > 2019 23:32:14: > > > >> > >> > > > >> > >>> From: David Holmes > > > >> > >>> To: Adam Farley8 > > > >> > >>> Cc: hotspot-dev at openjdk.java.net, "serguei.spitsyn at oracle.com" > > > >> > >>> > > > >> > >>> Date: 12/08/2019 23:32 > > > >> > >>> Subject: Re: RFR: JDK-8227021: VM fails if any > > sun.boot.library.path > > > >> > >>> paths are longer than JVM_MAXPATHLEN > > > >> > >>> > > > >> > >>> Looks fine. > > > >> > >>> > > > >> > >>> Thanks, > > > >> > >>> David > > > >> > >>> > > > >> > >>> On 13/08/2019 1:19 am, Adam Farley8 wrote: > > > >> > >>>> Hi David, > > > >> > >>>> > > > >> > >>>> Changes made as requested: > > > >> > >>>> https://urldefense.proofpoint.com/v2/url? > > > >> > >>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021. > 4_webrev&d=DwID- > > > >> > >>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > > >> > >>> > > > >> > >> > > > >> > > > > >> > > > > > > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=mZM8IR4e_zmrfcsF3XJjoGEMrZb4WtEL7Y6Ugd6Naqg&s=sZ2UKqqUIq0El- > > > >> > >> > > > >> > >>> RsqYz6jmTh4Q2UghwdrQX6of8Lw0E&e= > > > >> > >>>> Best Regards > > > >> > >>>> > > > >> > >>>> Adam Farley > > > >> > >>>> IBM Runtimes > > > >> > >>>> > > > >> > >>>> > > > >> > >>>> David Holmes wrote on 12/08/ > > > 2019 04:55:36: > > > >> > >>>> > > > >> > >>>>> From: David Holmes > > > >> > >>>>> To: Adam Farley8 , > > > >> > >>>>> "serguei.spitsyn at oracle.com" > > > >> > >>>>> Cc: hotspot-dev at openjdk.java.net > > > >> > >>>>> Date: 12/08/2019 04:56 > > > >> > >>>>> Subject: Re: RFR: JDK-8227021: VM fails if any > > > sun.boot.library.path > > > >> > >>>>> paths are longer than JVM_MAXPATHLEN > > > >> > >>>>> > > > >> > >>>>> Hi Adam, > > > >> > >>>>> > > > >> > >>>>> On 10/08/2019 2:47 am, Adam Farley8 wrote: > > > >> > >>>>>> Hi Serguei, David, > > > >> > >>>>>> > > > >> > >>>>>> My turn to apologise for the delay. :) > > > >> > >>>>>> > > > >> > >>>>>> I've modified the code as per Serguei's request. > Takealook and > > > >> > >> let me > > > >> > >>>>>> know if this is the sort of thing you were thinking of. > > > >> > >>>>>> > > > >> > >>>>>> Webrev: https://urldefense.proofpoint.com/v2/url? > > > >> > >>>>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021. > > 3_webrev_&d=DwID- > > > >> > >>>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > > >> > >>>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > > > >> > >>>>> > > > >> > >> > > > >> > > > > >> > > > > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=L19aeFXoR9JIO62QRPFzZObIU8RbhpCtXSvUibD2ISk&e= > > > >> > >> > > > >> > >>>>> I'd prefer to see the helper just as a file static > > function rather > > > >> > >> than > > > >> > >>>>> adding it to the os class. > > > >> > >>>>> > > > >> > >>>>> + * supplied array of arrays of chars (a), where n > > > >> > >>>>> > > > >> > >>>>> I assume (a) is meant to refer to the parameter, but > > you actually > > > >> > >> called > > > >> > >>>>> it arrayarray. I think "a" or "arr" would suffice. > > > >> > >>>>> > > > >> > >>>>> Thanks, > > > >> > >>>>> David > > > >> > >>>>> > > > >> > >>>>>> Best Regards > > > >> > >>>>>> > > > >> > >>>>>> Adam Farley > > > >> > >>>>>> IBM Runtimes > > > >> > >>>>>> > > > >> > >>>>>> > > > >> > >>>>>> "serguei.spitsyn at oracle.com" > > > wrote on > > > >> > >>>>>> 31/07/2019 17:18:05: > > > >> > >>>>>> > > > >> > >>>>>>> From: "serguei.spitsyn at oracle.com" > > > > > >> > >>>>>>> To: Adam Farley8 , David Holmes > > > >> > >>>>>>> > > > >> > >>>>>>> Cc: serviceability-dev , > > > >> > >>>>>>> hotspot-dev at openjdk.java.net > > > >> > >>>>>>> Date: 31/07/2019 17:18 > > > >> > >>>>>>> Subject: Re: RFR: JDK-8227021: VM fails if any > > > >> > >> sun.boot.library.path > > > >> > >>>>>>> paths are longer than JVM_MAXPATHLEN > > > >> > >>>>>>> > > > >> > >>>>>>> Hi Adam, > > > >> > >>>>>>> > > > >> > >>>>>>> It looks Okay to me. > > > >> > >>>>>>> > > > >> > >>>>>>> A couple of minor comments. > > > >> > >>>>>>> > > > >> > >>>>>>> https://urldefense.proofpoint.com/v2/url? > > > >> > >>>>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021. > > > >> > >>>>> 2_webrev_src_hotspot_&d=DwID-g&c=jf_iaSHvJObTbx- > > > >> > >>>>> siA1ZOg&r=P5m8KWUXJf- > > CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > > > >> > >>>>> > > > >> > >> > > > >> > > > > >> > > > > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NL6tYuwwDod3DSmj-1ztxAywpO8L52HEyO0wvTR05bs&e= > > > >> > >> > > > >> > >>>>>>> share/runtime/os.cpp.frames.html > > > >> > >>>>>>> 1362 //release allocated storage before exiting the vm > > > >> > >>>>>>> 1363 while (i > 0) { > > > >> > >>>>>>> 1364 i--; > > > >> > >>>>>>> 1365 if (opath[i] != NULL) { > > > >> > >>>>>>> 1366 FREE_C_HEAP_ARRAY(char, opath[i]); > > > >> > >>>>>>> 1367 } > > > >> > >>>>>>> 1368 } > > > >> > >>>>>>> 1369 FREE_C_HEAP_ARRAY(char*, opath); > > > >> > >>>>>>> > > > >> > >>>>>>> 1377 //release allocated storage before returning null > > > >> > >>>>>>> 1378 while (i > 0) { > > > >> > >>>>>>> 1379 i--; > > > >> > >>>>>>> 1380 if (opath[i] != NULL) { > > > >> > >>>>>>> 1381 FREE_C_HEAP_ARRAY(char, opath[i]); > > > >> > >>>>>>> 1382 } > > > >> > >>>>>>> 1383 } > > > >> > >>>>>>> 1384 FREE_C_HEAP_ARRAY(char*, opath); > > > >> > >>>>>>> > > > >> > >>>>>>> This duplicated fragments is worth to refactor to > a function. > > > >> > >>>>>>> Also a space is missed at the beginning of the comment. > > > >> > >>>>>>> > > > >> > >>>>>>> > > > >> > >>>>>>> Thanks, > > > >> > >>>>>>> Serguei > > > >> > >>>>>>> > > > >> > >>>>>>> > > > >> > >>>>>>> > > > >> > >>>>>>> On 7/31/19 02:01, Adam Farley8 wrote: > > > >> > >>>>>>> Hi All, > > > >> > >>>>>>> > > > >> > >>>>>>> Reviewers requested for the change below. > > > >> > >>>>>>> > > > >> > >>>>>>> @David - Agreed. Would you be prepared to sponsor > the change? > > > >> > >>>>>>> > > > >> > >>>>>>> Bug: https://urldefense.proofpoint.com/v2/url? > > > >> > >>>>> u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8227021&d=DwID- > > > >> > >>>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > > >> > >>>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > > > >> > >>>>> > > > >> > >> > > > >> > > > > >> > > > > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=xykJ0KLy9AKWO8zmC0amfR7xxUsvyKEjlf3y7WWOqvE&e= > > > >> > >> > > > >> > >>>>>>> Webrev: https://urldefense.proofpoint.com/v2/url? > > > >> > >>>>> u=http-3A__cr.openjdk.java.net_-7Eafarley_8227021. > > 2_webrev_&d=DwID- > > > >> > >>>>> g&c=jf_iaSHvJObTbx-siA1ZOg&r=P5m8KWUXJf- > > > >> > >>>>> CeVJc0hDGD9AQ2LkcXDC0PMV9ntVw5Ho&m=8Wa8Zdfmvn- > > > >> > >>>>> > > > >> > >> > > > >> > > > > >> > > > > > > yvzvCAhOyJ_etFblRA4vmLGbKF4aW8PY&s=NvIza4VVWG3CiDhmQVmXsghH_4h_c5mFJbHwkCUcut0&e= > > > >> > >> > > > >> > >>>>>>> Best Regards > > > >> > >>>>>>> > > > >> > >>>>>>> Adam Farley > > > >> > >>>>>>> IBM Runtimes > > > >> > >>>>>>> > > > >> > >>>>>>> P.S. Remembered to add the links this time. :) > > > >> > >>>>>>> > > > >> > >>>>>>> > > > >> > >>>>>>> David Holmes wrote on 30/07/2019 > > > >> > >> 03:37:53: > > > >> > >>>>>>>> From: David Holmes > > > >> > >>>>>>>> To: Adam Farley8 > > > >> > >>>>>>>> Cc: hotspot-dev at openjdk.java.net, serviceability-dev > > > >> > >>>>>>>> > > > >> > >>>>>>>> Date: 30/07/2019 03:38 > > > >> > >>>>>>>> Subject: Re: RFR: JDK-8227021: VM fails if any > > > >> > >> sun.boot.library.path > > > >> > >>>>>>>> paths are longer than JVM_MAXPATHLEN > > > >> > >>>>>>>> > > > >> > >>>>>>>> Hi Adam, > > > >> > >>>>>>>> > > > >> > >>>>>>>> On 25/07/2019 3:57 am, Adam Farley8 wrote: > > > >> > >>>>>>>>> Hi David, > > > >> > >>>>>>>>> > > > >> > >>>>>>>>> Welcome back. :) > > > >> > >>>>>>>> Thanks. Sorry for the delay in getting back to this. > > > >> > >>>>>>>> > > > >> > >>>>>>>> I like .v2 as it is much simpler (notwithstanding freeing > > > >> > >>> the already > > > >> > >>>>>>>> allocated arrays adds some complexity - thanks for > > > fixing that). > > > >> > >>>>>>>> > > > >> > >>>>>>>> I'm still not sure we can't optimise things better for > > > >> > >> unchangeable > > > >> > >>>>>>>> properties like the boot libary path, but that's > > another RFE. > > > >> > >>>>>>>> > > > >> > >>>>>>>> Thanks, > > > >> > >>>>>>>> David > > > >> > >>>>>>>> > > > >> > >>>>>>> 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 > > > >> > >> 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 > > > > > > > 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 stefan.karlsson at oracle.com Mon Aug 26 07:12:44 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 26 Aug 2019 09:12:44 +0200 Subject: RFR: 8229836: Remove include of globals.hpp from allocation.hpp In-Reply-To: <9ff477f2-8aef-fa59-098a-7f5652d031cd@oracle.com> References: <5abdb28e-3658-d7d1-20b0-000898818f42@oracle.com> <9ff477f2-8aef-fa59-098a-7f5652d031cd@oracle.com> Message-ID: <4041f668-5b96-5dca-2a09-bc5b8505a545@oracle.com> On 2019-08-20 15:51, coleen.phillimore at oracle.com wrote: > > > On 8/20/19 8:09 AM, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch to remove the include of globals.hpp from >> allocation.hpp. >> >> http://cr.openjdk.java.net/~stefank/8229836/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8229836 >> >> Note this change is just the bare minimum to get it to compile on our >> build platforms. I haven't tried to find all files that are missing >> explicit includes of globals.hpp. > > http://cr.openjdk.java.net/~stefank/8229836/webrev.01/src/hotspot/share/oops/oopsHierarchy.hpp.udiff.html > > > Is it because globals.hpp was transitively included, that the extern "C" > wasn't needed?? Without extern "C" will it mangle the name? That seems to have been the case. > > This looks like it doesn't need someone else to review it and can be > considered trivial.? It doesn't seem to affect the cpu directories so > seems unlikely to break other platforms. Thanks for reviewing. StefanK > > thanks, > Coleen >> >> Thanks, >> StefanK > From stefan.karlsson at oracle.com Mon Aug 26 07:13:02 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Mon, 26 Aug 2019 09:13:02 +0200 Subject: RFR: 8229836: Remove include of globals.hpp from allocation.hpp In-Reply-To: References: <5abdb28e-3658-d7d1-20b0-000898818f42@oracle.com> Message-ID: <990f3d01-0065-ecc1-1a42-925440fd056c@oracle.com> Thanks for reviewing. StefanK On 2019-08-20 18:08, Kim Barrett wrote: >> On Aug 20, 2019, at 8:09 AM, Stefan Karlsson wrote: >> >> Hi all, >> >> Please review this patch to remove the include of globals.hpp from allocation.hpp. >> >> http://cr.openjdk.java.net/~stefank/8229836/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8229836 >> >> Note this change is just the bare minimum to get it to compile on our build platforms. I haven't tried to find all files that are missing explicit includes of globals.hpp. >> >> Thanks, >> StefanK > > Looks good. > > ------------------------------------------------------------------------------ > src/hotspot/share/oops/oopsHierarchy.hpp > 76 extern "C" bool CheckUnhandledOops; > > Huh! I hadn't realized options polluted the global C namespace. Yet > another reason to have far fewer :) > > ------------------------------------------------------------------------------ > From shade at redhat.com Mon Aug 26 07:43:55 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 26 Aug 2019 09:43:55 +0200 Subject: RFR (XS) 8230118: 32-bit build failures after JDK-8227054 Message-ID: <4dee1825-f0e0-9bfc-d509-29717e05ee67@redhat.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8230118 I believe we should just use pointer_delta: http://cr.openjdk.java.net/~shade/8230118/webrev.01/ Testing: build, tier1 {x86_32, x86_64} -- Thanks, -Aleksey From sgehwolf at redhat.com Mon Aug 26 14:20:10 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Mon, 26 Aug 2019 16:20:10 +0200 Subject: [8u] [RFR] 8140482: Various minor code improvements (runtime) In-Reply-To: <5784a2dbe5944f07b1feb03b7b1f87e7@sap.com> References: <5784a2dbe5944f07b1feb03b7b1f87e7@sap.com> Message-ID: Hi, On Thu, 2018-11-22 at 08:51 +0000, Lindenmaier, Goetz wrote: > Hi, > > Doesn't this have to be posted to jdk8u-dev? > > I had a look at the backport. > Including 7127191 confused me a bit. Is it good to hide the fact that > this was backported in the repository? > In os_linux one fix is missing, is this on purpose? I don't think this is a > critical issue, though, so leaving it out is fine. > > > the dropping of the changes to ... > > src/share/vm/runtime/task.cpp and > > src/os/windows/vm/attachListener_windows.cpp > These changes are included in the webrev ...? > > The webrev looks good to me. > > Best regards, > Goetz. > > > > > > > -----Original Message----- > > From: hotspot-dev On Behalf Of > > Andrew Hughes > > Sent: Mittwoch, 21. November 2018 07:45 > > To: serviceability-dev ; hotspot-dev > > > > Subject: [8u] [RFR] 8140482: Various minor code improvements (runtime) > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8140482 > > Original changeset: > > https://hg.openjdk.java.net/jdk-updates/jdk9u/hotspot/rev/cd86b5699825 > > Webrev: > > https://cr.openjdk.java.net/~andrew/openjdk8/8140482/webrev.01/ > > > > The patch largely applies as is, with some adjustment for context and > > the dropping of the changes to src/cpu/x86/vm/stubRoutines_x86.cpp, > > src/share/vm/runtime/task.cpp and > > src/os/windows/vm/attachListener_windows.cpp > > which don't exist in 8u. A clean backport of 7127191 is included, which > > allows the changes to agent/src/os/linux/libproc_impl.c to apply as-is. > > > > Applying the change to 8u improves the code quality there and aids > > in backporting other changes, such as 8210836 [0]. > > > > Ok for 8u? > > > > [0] https://mail.openjdk.java.net/pipermail/serviceability-dev/2018- > > November/025991.html > > > > Thanks, Reviving this old thread. Andrew, could you please rebase this patch to latest 8u? AFAIK, 7127191 has been included since in 8u and the review would be easier if the webrev didn't show it. I'd need this backport to go in so as to proceed with JDK-8210836. Thanks, Severin From zgu at redhat.com Mon Aug 26 20:49:01 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Mon, 26 Aug 2019 16:49:01 -0400 Subject: RFR 8229919: Support JNI Critical functions in object pinning API on x86_32 platforms In-Reply-To: <6f6afdc5-cb13-6c8c-98f8-47917793545c@redhat.com> References: <6f6afdc5-cb13-6c8c-98f8-47917793545c@redhat.com> Message-ID: <8cc6bb50-80d1-93da-1601-1f780f2febf4@redhat.com> Passed submit tests. Thanks, -Zhengyu On 8/22/19 2:57 PM, Zhengyu Gu wrote: > Please review this patch that supports JNI critical functions in object > pinning capable GCs on x86_32 platforms. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8229919 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8229919/webrev.00/ > > Test: > ? hotspot_gc_shenandoah (fastdebug and release) with 32-bit VM on Linux > x86_64. > ? hotspot_gc, hotspot_runtime and hotspot_compiler > ? Submit tests in progress. > > Thanks, > > -Zhengyu From stefan.karlsson at oracle.com Tue Aug 27 07:32:33 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 27 Aug 2019 09:32:33 +0200 Subject: RFR: 8230203: Replace markWord enums with uintptr_t constants Message-ID: <1c706a0b-4be8-9255-74dc-83a0311b4023@oracle.com> Hi all, Please review this patch to convert the enum constants in markWord into static const unintptr_t constants. http://cr.openjdk.java.net/~stefank/8230203/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8230203 This is a follow-up RFE from the review of JDK-8229258, where a number of unnecessary casts were pointed out. There was also a recent bug in this area, JDK-8221725, where Thomas points out the problem of relying on the bit width of the enum values. This patch: 1) changes all constants to have the same type as the markWord::_value field. 2) Removes unnecessary uintptr_t casts 3) Removes uintx casts, because they are typedefed to be uintptr_t 4) Adds explicit casts to (int) when values are negated. 5) Try to only use uintptr_t inside markWord. 6) Leaves the use of intptr_t for parameters and return types of the different hash functions. Tested with tier1-3 Thanks, StefanK From matthias.baesken at sap.com Tue Aug 27 07:41:05 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 27 Aug 2019 07:41:05 +0000 Subject: RFR [XS]: 8229370: make jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java more stable Message-ID: Hello, any reviews for this small change ? Thanks , Matthias From: Baesken, Matthias Sent: Montag, 12. August 2019 14:33 To: 'hotspot-dev at openjdk.java.net' ; 'hotspot-jfr-dev at openjdk.java.net' Subject: RFR [XS]: 8229370: make jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java more stable Hello, please review this small test enhancement. We noticed that on some of our Linux machines (SLES12 based) the TestNetworkUtilizationEvent.java test reported just 1 interface (the test TestNetworkUtilizationEvent.java expects more than 1 on Linux). Looking into the HS code , os_perf_linux.cpp collects the interfaces + additional information about bytes read/written (by looking at /sys/class/net/eth/statistics/ ) and this info is given to JFR . However it seems to need (at least on some machines / setups) more packet send operations / potential retries to really get counter updates (and without updates in the counters, no interfaces are found). So I adjusted the test accordingly. Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8229370 http://cr.openjdk.java.net/~mbaesken/webrevs/8229370.0/ Best regards, Matthias From david.holmes at oracle.com Tue Aug 27 07:55:54 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 27 Aug 2019 17:55:54 +1000 Subject: RFR [XS]: 8229370: make jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java more stable In-Reply-To: References: Message-ID: <9f1e22b3-14c9-ecb1-e0b0-d6c19fa02a4e@oracle.com> Hi Matthias, On 27/08/2019 5:41 pm, Baesken, Matthias wrote: > Hello, any reviews for this small change ? I missed the initial request - sorry. Seems we have a double up of effort here as we also have JDK-8228990 for the exact same problem that we see on some of our test machines. Our analysis suggests that this test often passes by accident due to incidental activity on the real network interface when the logic intended to generate that activity (the packet sent to 10.0.0.0:12345) actually had no affect (unreachable address). If there is no incidental network activity then the real network interface is not seen and so the test fails. David > Thanks , Matthias > > From: Baesken, Matthias > Sent: Montag, 12. August 2019 14:33 > To: 'hotspot-dev at openjdk.java.net' ; 'hotspot-jfr-dev at openjdk.java.net' > Subject: RFR [XS]: 8229370: make jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java more stable > > Hello, please review this small test enhancement. > > We noticed that on some of our Linux machines (SLES12 based) the TestNetworkUtilizationEvent.java test reported just 1 interface > (the test TestNetworkUtilizationEvent.java expects more than 1 on Linux). > > Looking into the HS code , os_perf_linux.cpp collects the interfaces + additional information about bytes read/written (by looking at /sys/class/net/eth/statistics/ ) > and this info is given to JFR . > > However it seems to need (at least on some machines / setups) more packet send operations / potential retries to really get counter updates (and without updates in the counters, no interfaces are found). > So I adjusted the test accordingly. > > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8229370 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8229370.0/ > > > Best regards, Matthias > From david.holmes at oracle.com Tue Aug 27 08:01:52 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 27 Aug 2019 18:01:52 +1000 Subject: RFR: 8230203: Replace markWord enums with uintptr_t constants In-Reply-To: <1c706a0b-4be8-9255-74dc-83a0311b4023@oracle.com> References: <1c706a0b-4be8-9255-74dc-83a0311b4023@oracle.com> Message-ID: Hi Stefan, On 27/08/2019 5:32 pm, Stefan Karlsson wrote: > Hi all, > > Please review this patch to convert the enum constants in markWord into > static const unintptr_t constants. > > http://cr.openjdk.java.net/~stefank/8230203/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8230203 Overall this seems like a good cleanup, but the introduced "int" casts now jump out at me. In: src/hotspot/cpu/aarch64/aarch64.ad src/hotspot/cpu/arm/macroAssembler_arm.cpp src/hotspot/cpu/ppc/macroAssembler_ppc.cpp it would seem to me that all the "add -(int)markWord::monitor_value" would be cleaner/clearer as: "sub markWord::monitor_value". But that is a bit out of scope for your change - it just jumped out at me. I expect add is more efficient than sub. In src/hotspot/share/opto/macro.cpp I don't understand why this int cast is needed: Node* not_biased_ctrl = opt_bits_test(ctrl, region, 3, x_node, ! (~(int)markWord::age_mask_in_place), 0); I'm unclear if this is really ~(int)markWord::age_mask_in_place or (int)(~markWord::age_mask_in_place) ? If the latter then okay. If the former then I don't grok it. :) Thanks, David ----- > This is a follow-up RFE from the review of JDK-8229258, where a number > of unnecessary casts were pointed out. > > There was also a recent bug in this area, JDK-8221725, where Thomas > points out the problem of relying on the bit width of the enum values. > > This patch: > 1) changes all constants to have the same type as the markWord::_value > field. > 2) Removes unnecessary uintptr_t casts > 3) Removes uintx casts, because they are typedefed to be uintptr_t > 4) Adds explicit casts to (int) when values are negated. > 5) Try to only use uintptr_t inside markWord. > 6) Leaves the use of intptr_t for parameters and return types of the > different hash functions. > > Tested with tier1-3 > > Thanks, > StefanK From shade at redhat.com Tue Aug 27 08:03:45 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 27 Aug 2019 10:03:45 +0200 Subject: RFR (XS) 8230118: 32-bit build failures after JDK-8227054 In-Reply-To: <4dee1825-f0e0-9bfc-d509-29717e05ee67@redhat.com> References: <4dee1825-f0e0-9bfc-d509-29717e05ee67@redhat.com> Message-ID: <3cafb334-7896-c0f7-a7a2-7e841a5aa58e@redhat.com> On 8/26/19 9:43 AM, Aleksey Shipilev wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8230118 > > I believe we should just use pointer_delta: > http://cr.openjdk.java.net/~shade/8230118/webrev.01/ > > Testing: build, tier1 {x86_32, x86_64} Friendly reminder. I guess I should have cc'ed Kim. -- Thanks, -Aleksey From matthias.baesken at sap.com Tue Aug 27 08:15:27 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 27 Aug 2019 08:15:27 +0000 Subject: RFR [XS]: 8229370: make jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java more stable In-Reply-To: <9f1e22b3-14c9-ecb1-e0b0-d6c19fa02a4e@oracle.com> References: <9f1e22b3-14c9-ecb1-e0b0-d6c19fa02a4e@oracle.com> Message-ID: Hi David, thanks for the info about https://bugs.openjdk.java.net/browse/JDK-8228990 regarding your comment in the bug : > So it makes no sense. I finally found an example where the test passed and failed on the same machine. I've seen this too . Looks like my change only increased the probability of incidental network traffic happening on the real network interfaces . Should we exclude the test, in the current state it might indeed be problematic . (otherwise we could make the test pass on Linux when just 1 network interface is found, this might be a legitimate case isn?t it ?) Best regards, Matthias > -----Original Message----- > From: David Holmes > Sent: Dienstag, 27. August 2019 09:56 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' ; hotspot-jfr- > dev at openjdk.java.net > Subject: Re: RFR [XS]: 8229370: make > jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java more stable > > Hi Matthias, > > On 27/08/2019 5:41 pm, Baesken, Matthias wrote: > > Hello, any reviews for this small change ? > > I missed the initial request - sorry. > > Seems we have a double up of effort here as we also have JDK-8228990 for > the exact same problem that we see on some of our test machines. > > Our analysis suggests that this test often passes by accident due to > incidental activity on the real network interface when the logic > intended to generate that activity (the packet sent to 10.0.0.0:12345) > actually had no affect (unreachable address). If there is no incidental > network activity then the real network interface is not seen and so the > test fails. > > David > > > Thanks , Matthias > > > > From: Baesken, Matthias > > Sent: Montag, 12. August 2019 14:33 > > To: 'hotspot-dev at openjdk.java.net' ; > 'hotspot-jfr-dev at openjdk.java.net' > > Subject: RFR [XS]: 8229370: make > jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java more stable > > > > Hello, please review this small test enhancement. > > > > We noticed that on some of our Linux machines (SLES12 based) the > TestNetworkUtilizationEvent.java test reported just 1 interface > > (the test TestNetworkUtilizationEvent.java expects more than 1 on Linux). > > > > Looking into the HS code , os_perf_linux.cpp collects the interfaces + > additional information about bytes read/written (by looking at > /sys/class/net/eth/statistics/ ) > > and this info is given to JFR . > > > > However it seems to need (at least on some machines / setups) more > packet send operations / potential retries to really get counter updates > (and without updates in the counters, no interfaces are found). > > So I adjusted the test accordingly. > > > > > > Bug/webrev : > > > > https://bugs.openjdk.java.net/browse/JDK-8229370 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8229370.0/ > > > > > > Best regards, Matthias > > From martin.doerr at sap.com Tue Aug 27 08:22:16 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 27 Aug 2019 08:22:16 +0000 Subject: RFR: 8230203: Replace markWord enums with uintptr_t constants In-Reply-To: References: <1c706a0b-4be8-9255-74dc-83a0311b4023@oracle.com> Message-ID: Hi, I think it would be better to use C++ 2011 Strongly-typed Enums. Can we still not use them? AFAIK all compilers which are used for jdk/jdk support that. Best regards, Martin > -----Original Message----- > From: hotspot-dev On Behalf Of > David Holmes > Sent: Dienstag, 27. August 2019 10:02 > To: Stefan Karlsson ; hotspot-dev dev at openjdk.java.net> > Subject: Re: RFR: 8230203: Replace markWord enums with uintptr_t > constants > > Hi Stefan, > > On 27/08/2019 5:32 pm, Stefan Karlsson wrote: > > Hi all, > > > > Please review this patch to convert the enum constants in markWord into > > static const unintptr_t constants. > > > > http://cr.openjdk.java.net/~stefank/8230203/webrev.01/ > > https://bugs.openjdk.java.net/browse/JDK-8230203 > > Overall this seems like a good cleanup, but the introduced "int" casts > now jump out at me. In: > > src/hotspot/cpu/aarch64/aarch64.ad > src/hotspot/cpu/arm/macroAssembler_arm.cpp > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp > > it would seem to me that all the "add -(int)markWord::monitor_value" > would be cleaner/clearer as: "sub markWord::monitor_value". But that is > a bit out of scope for your change - it just jumped out at me. I expect > add is more efficient than sub. > > In src/hotspot/share/opto/macro.cpp I don't understand why this int > cast is needed: > > Node* not_biased_ctrl = opt_bits_test(ctrl, region, 3, x_node, > ! > (~(int)markWord::age_mask_in_place), 0); > > I'm unclear if this is really > > ~(int)markWord::age_mask_in_place > > or > > (int)(~markWord::age_mask_in_place) > > ? If the latter then okay. If the former then I don't grok it. :) > > Thanks, > David > ----- > > > This is a follow-up RFE from the review of JDK-8229258, where a number > > of unnecessary casts were pointed out. > > > > There was also a recent bug in this area, JDK-8221725, where Thomas > > points out the problem of relying on the bit width of the enum values. > > > > This patch: > > 1) changes all constants to have the same type as the markWord::_value > > field. > > 2) Removes unnecessary uintptr_t casts > > 3) Removes uintx casts, because they are typedefed to be uintptr_t > > 4) Adds explicit casts to (int) when values are negated. > > 5) Try to only use uintptr_t inside markWord. > > 6) Leaves the use of intptr_t for parameters and return types of the > > different hash functions. > > > > Tested with tier1-3 > > > > Thanks, > > StefanK From shade at redhat.com Tue Aug 27 09:01:46 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 27 Aug 2019 11:01:46 +0200 Subject: RFR (XS) 8230214: AArch64 build failures after JDK-8229836 (Remove include of globals.hpp from allocation.hpp) Message-ID: <20e3b070-d911-55ce-43ba-4a49d5391308@redhat.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8230214 Fix: diff -r 85fbdb87baad src/hotspot/os_cpu/linux_aarch64/gc/z/zPhysicalMemoryBacking_linux_aarch64.cpp --- a/src/hotspot/os_cpu/linux_aarch64/gc/z/zPhysicalMemoryBacking_linux_aarch64.cpp Wed Aug 14 15:07:04 2019 +0200 +++ b/src/hotspot/os_cpu/linux_aarch64/gc/z/zPhysicalMemoryBacking_linux_aarch64.cpp Tue Aug 27 11:01:36 2019 +0200 @@ -30,10 +30,11 @@ #include "gc/z/zMemory.hpp" #include "gc/z/zNUMA.hpp" #include "gc/z/zPhysicalMemory.inline.hpp" #include "gc/z/zPhysicalMemoryBacking_linux_aarch64.hpp" #include "logging/log.hpp" +#include "runtime/globals.hpp" #include "runtime/init.hpp" #include "runtime/os.hpp" #include "utilities/align.hpp" #include "utilities/debug.hpp" Testing: aarch64 build -- Thanks, -Aleksey From david.holmes at oracle.com Tue Aug 27 09:12:39 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 27 Aug 2019 19:12:39 +1000 Subject: RFR (XS) 8230214: AArch64 build failures after JDK-8229836 (Remove include of globals.hpp from allocation.hpp) In-Reply-To: <20e3b070-d911-55ce-43ba-4a49d5391308@redhat.com> References: <20e3b070-d911-55ce-43ba-4a49d5391308@redhat.com> Message-ID: <0f05a268-a26b-3f3c-01a8-6e15877e4ebb@oracle.com> Looks good and trivial. Thanks, David On 27/08/2019 7:01 pm, Aleksey Shipilev wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8230214 > > Fix: > > diff -r 85fbdb87baad src/hotspot/os_cpu/linux_aarch64/gc/z/zPhysicalMemoryBacking_linux_aarch64.cpp > --- a/src/hotspot/os_cpu/linux_aarch64/gc/z/zPhysicalMemoryBacking_linux_aarch64.cpp Wed Aug 14 > 15:07:04 2019 +0200 > +++ b/src/hotspot/os_cpu/linux_aarch64/gc/z/zPhysicalMemoryBacking_linux_aarch64.cpp Tue Aug 27 > 11:01:36 2019 +0200 > @@ -30,10 +30,11 @@ > #include "gc/z/zMemory.hpp" > #include "gc/z/zNUMA.hpp" > #include "gc/z/zPhysicalMemory.inline.hpp" > #include "gc/z/zPhysicalMemoryBacking_linux_aarch64.hpp" > #include "logging/log.hpp" > +#include "runtime/globals.hpp" > #include "runtime/init.hpp" > #include "runtime/os.hpp" > #include "utilities/align.hpp" > #include "utilities/debug.hpp" > > > Testing: aarch64 build > From shade at redhat.com Tue Aug 27 09:15:52 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 27 Aug 2019 11:15:52 +0200 Subject: RFR (XS) 8230214: AArch64 build failures after JDK-8229836 (Remove include of globals.hpp from allocation.hpp) In-Reply-To: <0f05a268-a26b-3f3c-01a8-6e15877e4ebb@oracle.com> References: <20e3b070-d911-55ce-43ba-4a49d5391308@redhat.com> <0f05a268-a26b-3f3c-01a8-6e15877e4ebb@oracle.com> Message-ID: <583d94e4-a36a-9ef8-9daf-4a68f892286b@redhat.com> Thanks, pushed. On 8/27/19 11:12 AM, David Holmes wrote: > Looks good and trivial. > > Thanks, > David > > On 27/08/2019 7:01 pm, Aleksey Shipilev wrote: >> Bug: >> ?? https://bugs.openjdk.java.net/browse/JDK-8230214 >> >> Fix: >> >> diff -r 85fbdb87baad src/hotspot/os_cpu/linux_aarch64/gc/z/zPhysicalMemoryBacking_linux_aarch64.cpp >> --- a/src/hotspot/os_cpu/linux_aarch64/gc/z/zPhysicalMemoryBacking_linux_aarch64.cpp??? Wed Aug 14 >> 15:07:04 2019 +0200 >> +++ b/src/hotspot/os_cpu/linux_aarch64/gc/z/zPhysicalMemoryBacking_linux_aarch64.cpp??? Tue Aug 27 >> 11:01:36 2019 +0200 >> @@ -30,10 +30,11 @@ >> ? #include "gc/z/zMemory.hpp" >> ? #include "gc/z/zNUMA.hpp" >> ? #include "gc/z/zPhysicalMemory.inline.hpp" >> ? #include "gc/z/zPhysicalMemoryBacking_linux_aarch64.hpp" >> ? #include "logging/log.hpp" >> +#include "runtime/globals.hpp" >> ? #include "runtime/init.hpp" >> ? #include "runtime/os.hpp" >> ? #include "utilities/align.hpp" >> ? #include "utilities/debug.hpp" >> >> >> Testing: aarch64 build >> -- Thanks, -Aleksey From shade at redhat.com Tue Aug 27 10:45:36 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 27 Aug 2019 12:45:36 +0200 Subject: RFR (XS) 8230215: MacOS debug build is broken after JDK-8230003 Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8230215 I do this fix blindly, because my MacOS environments actually build jdk/jdk fine. I would appreciate if anyone who has MacOS env currently broken would confirm it fixes the breakage. Fix: https://cr.openjdk.java.net/~shade/8230215/webrev.01/ Testing: Linux x86_64 build, MacOS x86_64 build -- Thanks, -Aleksey From stefan.karlsson at oracle.com Tue Aug 27 11:07:56 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 27 Aug 2019 13:07:56 +0200 Subject: RFR: 8230203: Replace markWord enums with uintptr_t constants In-Reply-To: References: <1c706a0b-4be8-9255-74dc-83a0311b4023@oracle.com> Message-ID: Hi Martin, On 2019-08-27 10:22, Doerr, Martin wrote: > Hi, > > I think it would be better to use C++ 2011 Strongly-typed Enums. Could you elaborate why it would be better to use them in this case? AFAICT these enums where only enums because that used to be the way constants were written in HotSpot. There are some comments around this in: https://bugs.openjdk.java.net/browse/JDK-8153116 Can we still not use them? > AFAIK all compilers which are used for jdk/jdk support that. I don't think we can go there until we get: https://openjdk.java.net/jeps/347 - JEP 347: Adopt C++14 Language Features in HotSpot Thanks, StefanK > > Best regards, > Martin > > >> -----Original Message----- >> From: hotspot-dev On Behalf Of >> David Holmes >> Sent: Dienstag, 27. August 2019 10:02 >> To: Stefan Karlsson ; hotspot-dev > dev at openjdk.java.net> >> Subject: Re: RFR: 8230203: Replace markWord enums with uintptr_t >> constants >> >> Hi Stefan, >> >> On 27/08/2019 5:32 pm, Stefan Karlsson wrote: >>> Hi all, >>> >>> Please review this patch to convert the enum constants in markWord into >>> static const unintptr_t constants. >>> >>> http://cr.openjdk.java.net/~stefank/8230203/webrev.01/ >>> https://bugs.openjdk.java.net/browse/JDK-8230203 >> >> Overall this seems like a good cleanup, but the introduced "int" casts >> now jump out at me. In: >> >> src/hotspot/cpu/aarch64/aarch64.ad >> src/hotspot/cpu/arm/macroAssembler_arm.cpp >> src/hotspot/cpu/ppc/macroAssembler_ppc.cpp >> >> it would seem to me that all the "add -(int)markWord::monitor_value" >> would be cleaner/clearer as: "sub markWord::monitor_value". But that is >> a bit out of scope for your change - it just jumped out at me. I expect >> add is more efficient than sub. >> >> In src/hotspot/share/opto/macro.cpp I don't understand why this int >> cast is needed: >> >> Node* not_biased_ctrl = opt_bits_test(ctrl, region, 3, x_node, >> ! >> (~(int)markWord::age_mask_in_place), 0); >> >> I'm unclear if this is really >> >> ~(int)markWord::age_mask_in_place >> >> or >> >> (int)(~markWord::age_mask_in_place) >> >> ? If the latter then okay. If the former then I don't grok it. :) >> >> Thanks, >> David >> ----- >> >>> This is a follow-up RFE from the review of JDK-8229258, where a number >>> of unnecessary casts were pointed out. >>> >>> There was also a recent bug in this area, JDK-8221725, where Thomas >>> points out the problem of relying on the bit width of the enum values. >>> >>> This patch: >>> 1) changes all constants to have the same type as the markWord::_value >>> field. >>> 2) Removes unnecessary uintptr_t casts >>> 3) Removes uintx casts, because they are typedefed to be uintptr_t >>> 4) Adds explicit casts to (int) when values are negated. >>> 5) Try to only use uintptr_t inside markWord. >>> 6) Leaves the use of intptr_t for parameters and return types of the >>> different hash functions. >>> >>> Tested with tier1-3 >>> >>> Thanks, >>> StefanK From stefan.karlsson at oracle.com Tue Aug 27 11:21:21 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 27 Aug 2019 13:21:21 +0200 Subject: RFR: 8230203: Replace markWord enums with uintptr_t constants In-Reply-To: References: <1c706a0b-4be8-9255-74dc-83a0311b4023@oracle.com> Message-ID: <78e1fc25-cef0-f626-ef23-5fb33a040576@oracle.com> On 2019-08-27 10:01, David Holmes wrote: > Hi Stefan, > > On 27/08/2019 5:32 pm, Stefan Karlsson wrote: >> Hi all, >> >> Please review this patch to convert the enum constants in markWord >> into static const unintptr_t constants. >> >> http://cr.openjdk.java.net/~stefank/8230203/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8230203 > > Overall this seems like a good cleanup, but the introduced "int" casts > now jump out at me. In: > > ?src/hotspot/cpu/aarch64/aarch64.ad > ?src/hotspot/cpu/arm/macroAssembler_arm.cpp > ?src/hotspot/cpu/ppc/macroAssembler_ppc.cpp > > it would seem to me that all the "add -(int)markWord::monitor_value" > would be cleaner/clearer as: "sub markWord::monitor_value". But that is > a bit out of scope for your change - it just jumped out at me. I expect > add is more efficient than sub. > I agree. > In? src/hotspot/share/opto/macro.cpp I don't understand why this int > cast is needed: > > ????? Node* not_biased_ctrl =? opt_bits_test(ctrl, region, 3, x_node, > ! (~(int)markWord::age_mask_in_place), 0); > > I'm unclear if this is really > > ~(int)markWord::age_mask_in_place > > or > > (int)(~markWord::age_mask_in_place) > > ? If the latter then okay. If the former then I don't grok it. :) Without casting we get the following error message: src/hotspot/share/opto/macro.cpp:2229:40: error: overflow in conversion from 'uintptr_t' {aka 'long unsigned int'} to 'int' changes value from '18446744073709551495' to '-121' [-Werror=overflow] (~markWord::age_mask_in_place), 0); The parameter type for opt_bits_test is int. So, I used '~(int)markWord::age_mask_in_place' to solve it. The intention was to 'take the small positive 64 bit wide integer, make it into a positive 32 bit wide integer, and then flip the bits'. It felt more intuitive (safer?) to narrow a positive integer than to cast a large positive integer to a smaller negative integer. Does that make sense, or did I miss something? :) Thanks, StefanK > > Thanks, > David > ----- > >> This is a follow-up RFE from the review of JDK-8229258, where a number >> of unnecessary casts were pointed out. >> >> There was also a recent bug in this area, JDK-8221725, where Thomas >> points out the problem of relying on the bit width of the enum values. >> >> This patch: >> 1) changes all constants to have the same type as the markWord::_value >> field. >> 2) Removes unnecessary uintptr_t casts >> 3) Removes uintx casts, because they are typedefed to be uintptr_t >> 4) Adds explicit casts to (int) when values are negated. >> 5) Try to only use uintptr_t inside markWord. >> 6) Leaves the use of intptr_t for parameters and return types of the >> different hash functions. >> >> Tested with tier1-3 >> >> Thanks, >> StefanK From david.holmes at oracle.com Tue Aug 27 11:37:48 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 27 Aug 2019 21:37:48 +1000 Subject: RFR: 8230203: Replace markWord enums with uintptr_t constants In-Reply-To: <78e1fc25-cef0-f626-ef23-5fb33a040576@oracle.com> References: <1c706a0b-4be8-9255-74dc-83a0311b4023@oracle.com> <78e1fc25-cef0-f626-ef23-5fb33a040576@oracle.com> Message-ID: <215b7869-ff99-9330-a3f4-271c35b479c5@oracle.com> On 27/08/2019 9:21 pm, Stefan Karlsson wrote: > On 2019-08-27 10:01, David Holmes wrote: >> Hi Stefan, >> >> On 27/08/2019 5:32 pm, Stefan Karlsson wrote: >>> Hi all, >>> >>> Please review this patch to convert the enum constants in markWord >>> into static const unintptr_t constants. >>> >>> http://cr.openjdk.java.net/~stefank/8230203/webrev.01/ >>> https://bugs.openjdk.java.net/browse/JDK-8230203 >> >> Overall this seems like a good cleanup, but the introduced "int" casts >> now jump out at me. In: >> >> ??src/hotspot/cpu/aarch64/aarch64.ad >> ??src/hotspot/cpu/arm/macroAssembler_arm.cpp >> ??src/hotspot/cpu/ppc/macroAssembler_ppc.cpp >> >> it would seem to me that all the "add -(int)markWord::monitor_value" >> would be cleaner/clearer as: "sub markWord::monitor_value". But that >> is a bit out of scope for your change - it just jumped out at me. I >> expect add is more efficient than sub. >> > > I agree. > >> In? src/hotspot/share/opto/macro.cpp I don't understand why this int >> cast is needed: >> >> ?????? Node* not_biased_ctrl =? opt_bits_test(ctrl, region, 3, x_node, >> ! (~(int)markWord::age_mask_in_place), 0); >> >> I'm unclear if this is really >> >> ~(int)markWord::age_mask_in_place >> >> or >> >> (int)(~markWord::age_mask_in_place) >> >> ? If the latter then okay. If the former then I don't grok it. :) > > Without casting we get the following error message: > src/hotspot/share/opto/macro.cpp:2229:40: error: overflow in conversion > from 'uintptr_t' {aka 'long unsigned int'} to 'int' changes value from > '18446744073709551495' to '-121' [-Werror=overflow] > ?????????????????????????????????????? (~markWord::age_mask_in_place), 0); > > The parameter type for opt_bits_test is int. So, I used > '~(int)markWord::age_mask_in_place' to solve it. The intention was to > 'take the small positive 64 bit wide integer, make it into a positive 32 > bit wide integer, and then flip the bits'. It felt more intuitive > (safer?) to narrow a positive integer than to cast a large positive > integer to a smaller negative integer. > > Does that make sense, or did I miss something? :) I understand the error message but I'm a little less clear about the overall change. Previously the enums were int types and so only 32-bit always. But the 32-bit masks were applied to 64-bit values on 64-bit systems, so presumably integer promotion came into play in those cases as there were no explicit casts. Now the constants are 64-bit on 64-bit and 32-bit on 32-bit and they match the size of the field being masked, so that is good. But it then leads me to wonder why we are passing a 64-bit mask into opt_bits_test when it can only deal with a 32-bit mask? Makes me wonder whether something in there isn't also the wrong type? Thanks, David > > Thanks, > StefanK > >> >> Thanks, >> David >> ----- >> >>> This is a follow-up RFE from the review of JDK-8229258, where a >>> number of unnecessary casts were pointed out. >>> >>> There was also a recent bug in this area, JDK-8221725, where Thomas >>> points out the problem of relying on the bit width of the enum values. >>> >>> This patch: >>> 1) changes all constants to have the same type as the >>> markWord::_value field. >>> 2) Removes unnecessary uintptr_t casts >>> 3) Removes uintx casts, because they are typedefed to be uintptr_t >>> 4) Adds explicit casts to (int) when values are negated. >>> 5) Try to only use uintptr_t inside markWord. >>> 6) Leaves the use of intptr_t for parameters and return types of the >>> different hash functions. >>> >>> Tested with tier1-3 >>> >>> Thanks, >>> StefanK From matthias.baesken at sap.com Tue Aug 27 12:35:16 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 27 Aug 2019 12:35:16 +0000 Subject: RFR [XS] : 8229182: runtime/containers/docker/TestMemoryAwareness.java test fails on SLES12 In-Reply-To: <1F1258AE-747D-4024-945A-6380ECC5EB9A@oracle.com> References: <6563ed4bd315281320e11755597fec24f4092ded.camel@redhat.com> <0924470c2bac638fa1feab7d63ee71a57904e408.camel@redhat.com> <9187885973675ab53221ad3140e79e0115e509a2.camel@redhat.com> <1F1258AE-747D-4024-945A-6380ECC5EB9A@oracle.com> Message-ID: Hi Bob, I tried your suggestion . It leads to java.lang.RuntimeException: 'java.lang.OutOfMemoryError' missing from stdout/stderr at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:187) at TestMemoryAwareness.testOOM(TestMemoryAwareness.java:120) at TestMemoryAwareness.main(TestMemoryAwareness.java:63) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298) at java.base/java.lang.Thread.run(Thread.java:830) JavaTest Message: Test threw exception: java.lang.RuntimeException JavaTest Message: shutting down test result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: 'java.lang.OutOfMemoryError' missing from stdout/stderr In the docker call we have now both -Xmx133m and -Xmx768m See : docker run --tty=true --rm --volume /net/usr.work/d040975/mytmp/jtreg-workdir/classes/containers/docker/TestMemoryAwareness.d:/test-classes/ --memory 256m --memory-swappiness 0 --memory-swap 256m jdk-internal:test-memory /jdk/bin/java -Xlog:os+container=trace -cp /test-classes/ -Xmx133m -Xmx768m -Djava.awt.headless=true AttemptOOM 266 Best regards, Matthias > -----Original Message----- > From: Bob Vandette > Sent: Freitag, 16. August 2019 14:36 > To: Baesken, Matthias > Cc: Severin Gehwolf ; Langer, Christoph > ; hotspot-dev at openjdk.java.net; Zeller, Arno > > Subject: Re: RFR [XS] : 8229182: > runtime/containers/docker/TestMemoryAwareness.java test fails on SLES12 > > Instead of adding this: opts.appendTestJavaOptions = false; > > > Try adding these lines: > > String javaHeapSize = new String(sizeToAllocInMb/2) + ?m?; > > opts.addJavaOpts("-Xmx" + javaHeapSize); > > This will set the max Java Heap to 1/2 of the size that we will attempt to > allocate. > This should reliably cause an OOM exception. > > Bob. > > > > On Aug 16, 2019, at 4:14 AM, Baesken, Matthias > wrote: > > > >> Can we not set -Xmx explicitly after any test options have been > >> appended so that it takes precedence? > > > > Hi Bob, do you have a good estimate for an Xmx to set ? > > > >> It seems fragile to disable > >> appinding all test options altogether. Clearly, this test is > >> susceptible to passed -Xmx options. > > > > We have here a java - execution taking place in the docker container, not > the test machine itself . > > I am not sure , are the "regular" test options so good for this special > execution ? Some maybe are , some aren?t ... > > > > E.g. we ended up with > > > > -Xmx768m -Djava.awt.headless=true > > > > and more strange settings in the "docker run" call because of this ... > > > > Best regards, Matthias > > > > > > > >> Hi Matthias, > >> > >> On Fri, 2019-08-16 at 06:10 +0000, Baesken, Matthias wrote: > >>>> Unfortunately we do not see the expected > >> "java.lang.OutOfMemoryError" > >>>> in the nightly test runs . > >>>> > >>>> When I execute the jtreg test locally on the same (!) ppc64le > machine , > >>>> under the same user but not from the test framework we use nightly > >>>> the "java.lang.OutOfMemoryError" shows up. > >>> > >>> Hello, after looking a bit more into it, we observed that the nightly > runs > >> set a higher -Xmx = 768m value that gets inherited into the > >> DockerRunOptions > >>> And made the central test fail . > >>> So I had to remove this : > >>> > >>> 105 // make sure we avoid Xmx settings from the jtreg vmoptions > >>> 106 opts.appendTestJavaOptions = false; > >> > >> Can we not set -Xmx explicitly after any test options have been > >> appended so that it takes precedence? It seems fragile to disable > >> appinding all test options altogether. Clearly, this test is > >> susceptible to passed -Xmx options. > >> > >> Failing that, could we just omit the -Xmx option? > >> > >> Thanks, > >> Severin > >> > >>> New webrev : > >>> > >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8229182.2/ > >>> > >>> Best regards, Matthias > >>> > >>> > >>>> Hi Christoph, > >>>> > >>>>> Hi Matthias, > >>>>> > >>>>> looks good to me in general. > >>>>> > >>>>> However, I'm not convinced that line 114 > >>>>> ".shouldContain("java.lang.OutOfMemoryError");" won't provoke a > >> test > >>>>> error in case the child process was killed by the container, e.g. exited > >> with > >>>>> exit code 137. We should at least run this patch for several days in our > >>>> system > >>>>> to see if it catches all variations of the problem. > >>>>> > >>>> > >>>> Unfortunately we do not see the expected > >> "java.lang.OutOfMemoryError" > >>>> in the nightly test runs . > >>>> > >>>> When I execute the jtreg test locally on the same (!) ppc64le > machine , > >>>> under the same user but not from the test framework we use nightly > >>>> the "java.lang.OutOfMemoryError" shows up. > >>>> > >>>> Best regards, Matthias > >>>> > >>>> > > From stefan.karlsson at oracle.com Tue Aug 27 12:52:59 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 27 Aug 2019 14:52:59 +0200 Subject: RFR: 8230203: Replace markWord enums with uintptr_t constants In-Reply-To: <215b7869-ff99-9330-a3f4-271c35b479c5@oracle.com> References: <1c706a0b-4be8-9255-74dc-83a0311b4023@oracle.com> <78e1fc25-cef0-f626-ef23-5fb33a040576@oracle.com> <215b7869-ff99-9330-a3f4-271c35b479c5@oracle.com> Message-ID: <5203f6b2-bebe-7ebe-cfc2-ff8a4a56149f@oracle.com> On 2019-08-27 13:37, David Holmes wrote: > On 27/08/2019 9:21 pm, Stefan Karlsson wrote: >> On 2019-08-27 10:01, David Holmes wrote: >>> Hi Stefan, >>> >>> On 27/08/2019 5:32 pm, Stefan Karlsson wrote: >>>> Hi all, >>>> >>>> Please review this patch to convert the enum constants in markWord >>>> into static const unintptr_t constants. >>>> >>>> http://cr.openjdk.java.net/~stefank/8230203/webrev.01/ >>>> https://bugs.openjdk.java.net/browse/JDK-8230203 >>> >>> Overall this seems like a good cleanup, but the introduced "int" >>> casts now jump out at me. In: >>> >>> ??src/hotspot/cpu/aarch64/aarch64.ad >>> ??src/hotspot/cpu/arm/macroAssembler_arm.cpp >>> ??src/hotspot/cpu/ppc/macroAssembler_ppc.cpp >>> >>> it would seem to me that all the "add -(int)markWord::monitor_value" >>> would be cleaner/clearer as: "sub markWord::monitor_value". But that >>> is a bit out of scope for your change - it just jumped out at me. I >>> expect add is more efficient than sub. >>> >> >> I agree. >> >>> In? src/hotspot/share/opto/macro.cpp I don't understand why this int >>> cast is needed: >>> >>> ?????? Node* not_biased_ctrl =? opt_bits_test(ctrl, region, 3, x_node, >>> ! (~(int)markWord::age_mask_in_place), 0); >>> >>> I'm unclear if this is really >>> >>> ~(int)markWord::age_mask_in_place >>> >>> or >>> >>> (int)(~markWord::age_mask_in_place) >>> >>> ? If the latter then okay. If the former then I don't grok it. :) >> >> Without casting we get the following error message: >> src/hotspot/share/opto/macro.cpp:2229:40: error: overflow in >> conversion from 'uintptr_t' {aka 'long unsigned int'} to 'int' changes >> value from '18446744073709551495' to '-121' [-Werror=overflow] >> >> (~markWord::age_mask_in_place), 0); >> >> The parameter type for opt_bits_test is int. So, I used >> '~(int)markWord::age_mask_in_place' to solve it. The intention was to >> 'take the small positive 64 bit wide integer, make it into a positive >> 32 bit wide integer, and then flip the bits'. It felt more intuitive >> (safer?) to narrow a positive integer than to cast a large positive >> integer to a smaller negative integer. >> >> Does that make sense, or did I miss something? :) > > I understand the error message but I'm a little less clear about the > overall change. Previously the enums were int types and so only 32-bit > always. This is not entirely true. They could be smaller than 32-bit, and could have been larger than 32-bit if high-order bits were used. But yes, previously these values were not larger than 32-bit. But the 32-bit masks were applied to 64-bit values on 64-bit > systems, so presumably integer promotion came into play in those cases > as there were no explicit casts. Now the constants are 64-bit on 64-bit > and 32-bit on 32-bit and they match the size of the field being masked, > so that is good. But it then leads me to wonder why we are passing a > 64-bit mask into opt_bits_test when it can only deal with a 32-bit mask? > Makes me wonder whether something in there isn't also the wrong type? Maybe someone from the compiler team can comment on this? For this specific case we know that the bits will fit inside a 32-bit sized integer and exploit that fact. We do similar narrowing inside the markWord class. For example: uint age() const { return mask_bits(value() >> age_shift, age_mask); } Thanks, StefanK > > Thanks, > David > >> >> Thanks, >> StefanK >> >>> >>> Thanks, >>> David >>> ----- >>> >>>> This is a follow-up RFE from the review of JDK-8229258, where a >>>> number of unnecessary casts were pointed out. >>>> >>>> There was also a recent bug in this area, JDK-8221725, where Thomas >>>> points out the problem of relying on the bit width of the enum values. >>>> >>>> This patch: >>>> 1) changes all constants to have the same type as the >>>> markWord::_value field. >>>> 2) Removes unnecessary uintptr_t casts >>>> 3) Removes uintx casts, because they are typedefed to be uintptr_t >>>> 4) Adds explicit casts to (int) when values are negated. >>>> 5) Try to only use uintptr_t inside markWord. >>>> 6) Leaves the use of intptr_t for parameters and return types of the >>>> different hash functions. >>>> >>>> Tested with tier1-3 >>>> >>>> Thanks, >>>> StefanK From bob.vandette at oracle.com Tue Aug 27 12:43:50 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Tue, 27 Aug 2019 08:43:50 -0400 Subject: RFR [XS] : 8229182: runtime/containers/docker/TestMemoryAwareness.java test fails on SLES12 In-Reply-To: References: <6563ed4bd315281320e11755597fec24f4092ded.camel@redhat.com> <0924470c2bac638fa1feab7d63ee71a57904e408.camel@redhat.com> <9187885973675ab53221ad3140e79e0115e509a2.camel@redhat.com> <1F1258AE-747D-4024-945A-6380ECC5EB9A@oracle.com> Message-ID: <2F25EFBB-363C-491C-B06A-9CDD8C4011BE@oracle.com> Can you send out the updated webrev? Are you sure you retained this change? opts.appendTestJavaOptions = false; We?ll need to figure out why this isn?t inhibiting the jtreg options. Bob.; > On Aug 27, 2019, at 8:35 AM, Baesken, Matthias wrote: > > Hi Bob, I tried your suggestion . > > It leads to > > java.lang.RuntimeException: 'java.lang.OutOfMemoryError' missing from stdout/stderr > > at jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:187) > at TestMemoryAwareness.testOOM(TestMemoryAwareness.java:120) > at TestMemoryAwareness.main(TestMemoryAwareness.java:63) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:564) > at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298) > at java.base/java.lang.Thread.run(Thread.java:830) > > JavaTest Message: Test threw exception: java.lang.RuntimeException > JavaTest Message: shutting down test > > result: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: 'java.lang.OutOfMemoryError' missing from stdout/stderr > > > In the docker call we have now both > > -Xmx133m and -Xmx768m > > See : > > docker run --tty=true --rm --volume /net/usr.work/d040975/mytmp/jtreg-workdir/classes/containers/docker/TestMemoryAwareness.d:/test-classes/ --memory 256m --memory-swappiness 0 --memory-swap 256m jdk-internal:test-memory /jdk/bin/java -Xlog:os+container=trace -cp /test-classes/ -Xmx133m -Xmx768m -Djava.awt.headless=true AttemptOOM 266 > > > Best regards, Matthias > > > >> -----Original Message----- >> From: Bob Vandette >> Sent: Freitag, 16. August 2019 14:36 >> To: Baesken, Matthias >> Cc: Severin Gehwolf ; Langer, Christoph >> ; hotspot-dev at openjdk.java.net; Zeller, Arno >> >> Subject: Re: RFR [XS] : 8229182: >> runtime/containers/docker/TestMemoryAwareness.java test fails on SLES12 >> >> Instead of adding this: opts.appendTestJavaOptions = false; >> >> >> Try adding these lines: >> >> String javaHeapSize = new String(sizeToAllocInMb/2) + ?m?; >> >> opts.addJavaOpts("-Xmx" + javaHeapSize); >> >> This will set the max Java Heap to 1/2 of the size that we will attempt to >> allocate. >> This should reliably cause an OOM exception. >> >> Bob. >> >> >>> On Aug 16, 2019, at 4:14 AM, Baesken, Matthias >> wrote: >>> >>>> Can we not set -Xmx explicitly after any test options have been >>>> appended so that it takes precedence? >>> >>> Hi Bob, do you have a good estimate for an Xmx to set ? >>> >>>> It seems fragile to disable >>>> appinding all test options altogether. Clearly, this test is >>>> susceptible to passed -Xmx options. >>> >>> We have here a java - execution taking place in the docker container, not >> the test machine itself . >>> I am not sure , are the "regular" test options so good for this special >> execution ? Some maybe are , some aren?t ... >>> >>> E.g. we ended up with >>> >>> -Xmx768m -Djava.awt.headless=true >>> >>> and more strange settings in the "docker run" call because of this ... >>> >>> Best regards, Matthias >>> >>> >>> >>>> Hi Matthias, >>>> >>>> On Fri, 2019-08-16 at 06:10 +0000, Baesken, Matthias wrote: >>>>>> Unfortunately we do not see the expected >>>> "java.lang.OutOfMemoryError" >>>>>> in the nightly test runs . >>>>>> >>>>>> When I execute the jtreg test locally on the same (!) ppc64le >> machine , >>>>>> under the same user but not from the test framework we use nightly >>>>>> the "java.lang.OutOfMemoryError" shows up. >>>>> >>>>> Hello, after looking a bit more into it, we observed that the nightly >> runs >>>> set a higher -Xmx = 768m value that gets inherited into the >>>> DockerRunOptions >>>>> And made the central test fail . >>>>> So I had to remove this : >>>>> >>>>> 105 // make sure we avoid Xmx settings from the jtreg vmoptions >>>>> 106 opts.appendTestJavaOptions = false; >>>> >>>> Can we not set -Xmx explicitly after any test options have been >>>> appended so that it takes precedence? It seems fragile to disable >>>> appinding all test options altogether. Clearly, this test is >>>> susceptible to passed -Xmx options. >>>> >>>> Failing that, could we just omit the -Xmx option? >>>> >>>> Thanks, >>>> Severin >>>> >>>>> New webrev : >>>>> >>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8229182.2/ >>>>> >>>>> Best regards, Matthias >>>>> >>>>> >>>>>> Hi Christoph, >>>>>> >>>>>>> Hi Matthias, >>>>>>> >>>>>>> looks good to me in general. >>>>>>> >>>>>>> However, I'm not convinced that line 114 >>>>>>> ".shouldContain("java.lang.OutOfMemoryError");" won't provoke a >>>> test >>>>>>> error in case the child process was killed by the container, e.g. exited >>>> with >>>>>>> exit code 137. We should at least run this patch for several days in our >>>>>> system >>>>>>> to see if it catches all variations of the problem. >>>>>>> >>>>>> >>>>>> Unfortunately we do not see the expected >>>> "java.lang.OutOfMemoryError" >>>>>> in the nightly test runs . >>>>>> >>>>>> When I execute the jtreg test locally on the same (!) ppc64le >> machine , >>>>>> under the same user but not from the test framework we use nightly >>>>>> the "java.lang.OutOfMemoryError" shows up. >>>>>> >>>>>> Best regards, Matthias >>>>>> >>>>>> >>> > From matthias.baesken at sap.com Tue Aug 27 13:12:19 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 27 Aug 2019 13:12:19 +0000 Subject: RFR [XS] : 8229182: runtime/containers/docker/TestMemoryAwareness.java test fails on SLES12 In-Reply-To: <2F25EFBB-363C-491C-B06A-9CDD8C4011BE@oracle.com> References: <6563ed4bd315281320e11755597fec24f4092ded.camel@redhat.com> <0924470c2bac638fa1feab7d63ee71a57904e408.camel@redhat.com> <9187885973675ab53221ad3140e79e0115e509a2.camel@redhat.com> <1F1258AE-747D-4024-945A-6380ECC5EB9A@oracle.com> <2F25EFBB-363C-491C-B06A-9CDD8C4011BE@oracle.com> Message-ID: Hi Bob, I looked a bit more into it. With this small additional change : test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java public static List buildJavaCommand(DockerRunOptions opts) throws Exception { ...... // ********* move AFTER test java options ********** //cmd.addAll(opts.javaOpts); if (opts.appendTestJavaOptions) { Collections.addAll(cmd, Utils.getTestJavaOpts()); } cmd.addAll(opts.javaOpts); cmd.add(opts.classToRun); cmd.addAll(opts.classParams); return cmd; } It works. Obviously the Utils.getTestJavaOpts would overwrite the Xmx setting from javaOpts. Do you think it is fine to change the order of javaOpts and testJavaOpts ? Best regards, Matthias > -----Original Message----- > From: Bob Vandette > Sent: Dienstag, 27. August 2019 14:44 > To: Baesken, Matthias > Cc: Severin Gehwolf ; Langer, Christoph > ; hotspot-dev at openjdk.java.net; Zeller, Arno > > Subject: Re: RFR [XS] : 8229182: > runtime/containers/docker/TestMemoryAwareness.java test fails on SLES12 > > Can you send out the updated webrev? > > Are you sure you retained this change? > > opts.appendTestJavaOptions = false; > > We?ll need to figure out why this isn?t inhibiting the jtreg options. > > Bob.; > > > > > On Aug 27, 2019, at 8:35 AM, Baesken, Matthias > wrote: > > > > Hi Bob, I tried your suggestion . > > > > It leads to > > > > java.lang.RuntimeException: 'java.lang.OutOfMemoryError' missing from > stdout/stderr > > > > at > jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:187) > > at > TestMemoryAwareness.testOOM(TestMemoryAwareness.java:120) > > at TestMemoryAwareness.main(TestMemoryAwareness.java:63) > > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMet > hodAccessorImpl.java:62) > > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Delega > tingMethodAccessorImpl.java:43) > > at java.base/java.lang.reflect.Method.invoke(Method.java:564) > > at > com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run( > MainActionHelper.java:298) > > at java.base/java.lang.Thread.run(Thread.java:830) > > > > JavaTest Message: Test threw exception: java.lang.RuntimeException > > JavaTest Message: shutting down test > > > > result: Failed. Execution failed: `main' threw exception: > java.lang.RuntimeException: 'java.lang.OutOfMemoryError' missing from > stdout/stderr > > > > > > In the docker call we have now both > > > > -Xmx133m and -Xmx768m > > > > See : > > > > docker run --tty=true --rm --volume /net/usr.work/d040975/mytmp/jtreg- > workdir/classes/containers/docker/TestMemoryAwareness.d:/test-classes/ > --memory 256m --memory-swappiness 0 --memory-swap 256m jdk- > internal:test-memory /jdk/bin/java -Xlog:os+container=trace -cp /test- > classes/ -Xmx133m -Xmx768m -Djava.awt.headless=true AttemptOOM 266 > > > > > > Best regards, Matthias > > > > > > > >> -----Original Message----- > >> From: Bob Vandette > >> Sent: Freitag, 16. August 2019 14:36 > >> To: Baesken, Matthias > >> Cc: Severin Gehwolf ; Langer, Christoph > >> ; hotspot-dev at openjdk.java.net; Zeller, > Arno > >> > >> Subject: Re: RFR [XS] : 8229182: > >> runtime/containers/docker/TestMemoryAwareness.java test fails on > SLES12 > >> > >> Instead of adding this: opts.appendTestJavaOptions = false; > >> > >> > >> Try adding these lines: > >> > >> String javaHeapSize = new String(sizeToAllocInMb/2) + ?m?; > >> > >> opts.addJavaOpts("-Xmx" + javaHeapSize); > >> > >> This will set the max Java Heap to 1/2 of the size that we will attempt to > >> allocate. > >> This should reliably cause an OOM exception. > >> > >> Bob. > >> > >> > >>> On Aug 16, 2019, at 4:14 AM, Baesken, Matthias > >> wrote: > >>> > >>>> Can we not set -Xmx explicitly after any test options have been > >>>> appended so that it takes precedence? > >>> > >>> Hi Bob, do you have a good estimate for an Xmx to set ? > >>> > >>>> It seems fragile to disable > >>>> appinding all test options altogether. Clearly, this test is > >>>> susceptible to passed -Xmx options. > >>> > >>> We have here a java - execution taking place in the docker container, > not > >> the test machine itself . > >>> I am not sure , are the "regular" test options so good for this special > >> execution ? Some maybe are , some aren?t ... > >>> > >>> E.g. we ended up with > >>> > >>> -Xmx768m -Djava.awt.headless=true > >>> > >>> and more strange settings in the "docker run" call because of this ... > >>> > >>> Best regards, Matthias > >>> > >>> > >>> > >>>> Hi Matthias, > >>>> > >>>> On Fri, 2019-08-16 at 06:10 +0000, Baesken, Matthias wrote: > >>>>>> Unfortunately we do not see the expected > >>>> "java.lang.OutOfMemoryError" > >>>>>> in the nightly test runs . > >>>>>> > >>>>>> When I execute the jtreg test locally on the same (!) ppc64le > >> machine , > >>>>>> under the same user but not from the test framework we use > nightly > >>>>>> the "java.lang.OutOfMemoryError" shows up. > >>>>> > >>>>> Hello, after looking a bit more into it, we observed that the nightly > >> runs > >>>> set a higher -Xmx = 768m value that gets inherited into the > >>>> DockerRunOptions > >>>>> And made the central test fail . > >>>>> So I had to remove this : > >>>>> > >>>>> 105 // make sure we avoid Xmx settings from the jtreg vmoptions > >>>>> 106 opts.appendTestJavaOptions = false; > >>>> > >>>> Can we not set -Xmx explicitly after any test options have been > >>>> appended so that it takes precedence? It seems fragile to disable > >>>> appinding all test options altogether. Clearly, this test is > >>>> susceptible to passed -Xmx options. > >>>> > >>>> Failing that, could we just omit the -Xmx option? > >>>> > >>>> Thanks, > >>>> Severin > >>>> > >>>>> New webrev : > >>>>> > >>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8229182.2/ > >>>>> > >>>>> Best regards, Matthias > >>>>> > >>>>> > >>>>>> Hi Christoph, > >>>>>> > >>>>>>> Hi Matthias, > >>>>>>> > >>>>>>> looks good to me in general. > >>>>>>> > >>>>>>> However, I'm not convinced that line 114 > >>>>>>> ".shouldContain("java.lang.OutOfMemoryError");" won't provoke a > >>>> test > >>>>>>> error in case the child process was killed by the container, e.g. > exited > >>>> with > >>>>>>> exit code 137. We should at least run this patch for several days in > our > >>>>>> system > >>>>>>> to see if it catches all variations of the problem. > >>>>>>> > >>>>>> > >>>>>> Unfortunately we do not see the expected > >>>> "java.lang.OutOfMemoryError" > >>>>>> in the nightly test runs . > >>>>>> > >>>>>> When I execute the jtreg test locally on the same (!) ppc64le > >> machine , > >>>>>> under the same user but not from the test framework we use > nightly > >>>>>> the "java.lang.OutOfMemoryError" shows up. > >>>>>> > >>>>>> Best regards, Matthias > >>>>>> > >>>>>> > >>> > > From bob.vandette at oracle.com Tue Aug 27 13:18:04 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Tue, 27 Aug 2019 09:18:04 -0400 Subject: RFR [XS] : 8229182: runtime/containers/docker/TestMemoryAwareness.java test fails on SLES12 In-Reply-To: References: <6563ed4bd315281320e11755597fec24f4092ded.camel@redhat.com> <0924470c2bac638fa1feab7d63ee71a57904e408.camel@redhat.com> <9187885973675ab53221ad3140e79e0115e509a2.camel@redhat.com> <1F1258AE-747D-4024-945A-6380ECC5EB9A@oracle.com> <2F25EFBB-363C-491C-B06A-9CDD8C4011BE@oracle.com> Message-ID: <55A6F5EE-7212-4EDC-A0DE-B644BBC1E3A6@oracle.com> I would be concerned that the change in ordering would break other tests. Your experiment shows that appendTestJavaOptions is true! Aren't you setting this to false?? Bob. > On Aug 27, 2019, at 9:12 AM, Baesken, Matthias wrote: > > Hi Bob, I looked a bit more into it. With this small additional change : > > test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java > > public static List buildJavaCommand(DockerRunOptions opts) throws Exception { > ...... > // ********* move AFTER test java options ********** > //cmd.addAll(opts.javaOpts); > if (opts.appendTestJavaOptions) { > Collections.addAll(cmd, Utils.getTestJavaOpts()); > } > cmd.addAll(opts.javaOpts); > > cmd.add(opts.classToRun); > cmd.addAll(opts.classParams); > > return cmd; > } > > > It works. Obviously the Utils.getTestJavaOpts would overwrite the Xmx setting from javaOpts. > Do you think it is fine to change the order of javaOpts and testJavaOpts ? > > Best regards, Matthias > > >> -----Original Message----- >> From: Bob Vandette >> Sent: Dienstag, 27. August 2019 14:44 >> To: Baesken, Matthias >> Cc: Severin Gehwolf ; Langer, Christoph >> ; hotspot-dev at openjdk.java.net; Zeller, Arno >> >> Subject: Re: RFR [XS] : 8229182: >> runtime/containers/docker/TestMemoryAwareness.java test fails on SLES12 >> >> Can you send out the updated webrev? >> >> Are you sure you retained this change? >> >> opts.appendTestJavaOptions = false; >> >> We?ll need to figure out why this isn?t inhibiting the jtreg options. >> >> Bob.; >> >> >> >>> On Aug 27, 2019, at 8:35 AM, Baesken, Matthias >> wrote: >>> >>> Hi Bob, I tried your suggestion . >>> >>> It leads to >>> >>> java.lang.RuntimeException: 'java.lang.OutOfMemoryError' missing from >> stdout/stderr >>> >>> at >> jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:187) >>> at >> TestMemoryAwareness.testOOM(TestMemoryAwareness.java:120) >>> at TestMemoryAwareness.main(TestMemoryAwareness.java:63) >>> at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >> Method) >>> at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMet >> hodAccessorImpl.java:62) >>> at >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Delega >> tingMethodAccessorImpl.java:43) >>> at java.base/java.lang.reflect.Method.invoke(Method.java:564) >>> at >> com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run( >> MainActionHelper.java:298) >>> at java.base/java.lang.Thread.run(Thread.java:830) >>> >>> JavaTest Message: Test threw exception: java.lang.RuntimeException >>> JavaTest Message: shutting down test >>> >>> result: Failed. Execution failed: `main' threw exception: >> java.lang.RuntimeException: 'java.lang.OutOfMemoryError' missing from >> stdout/stderr >>> >>> >>> In the docker call we have now both >>> >>> -Xmx133m and -Xmx768m >>> >>> See : >>> >>> docker run --tty=true --rm --volume /net/usr.work/d040975/mytmp/jtreg- >> workdir/classes/containers/docker/TestMemoryAwareness.d:/test-classes/ >> --memory 256m --memory-swappiness 0 --memory-swap 256m jdk- >> internal:test-memory /jdk/bin/java -Xlog:os+container=trace -cp /test- >> classes/ -Xmx133m -Xmx768m -Djava.awt.headless=true AttemptOOM 266 >>> >>> >>> Best regards, Matthias >>> >>> >>> >>>> -----Original Message----- >>>> From: Bob Vandette >>>> Sent: Freitag, 16. August 2019 14:36 >>>> To: Baesken, Matthias >>>> Cc: Severin Gehwolf ; Langer, Christoph >>>> ; hotspot-dev at openjdk.java.net; Zeller, >> Arno >>>> >>>> Subject: Re: RFR [XS] : 8229182: >>>> runtime/containers/docker/TestMemoryAwareness.java test fails on >> SLES12 >>>> >>>> Instead of adding this: opts.appendTestJavaOptions = false; >>>> >>>> >>>> Try adding these lines: >>>> >>>> String javaHeapSize = new String(sizeToAllocInMb/2) + ?m?; >>>> >>>> opts.addJavaOpts("-Xmx" + javaHeapSize); >>>> >>>> This will set the max Java Heap to 1/2 of the size that we will attempt to >>>> allocate. >>>> This should reliably cause an OOM exception. >>>> >>>> Bob. >>>> >>>> >>>>> On Aug 16, 2019, at 4:14 AM, Baesken, Matthias >>>> wrote: >>>>> >>>>>> Can we not set -Xmx explicitly after any test options have been >>>>>> appended so that it takes precedence? >>>>> >>>>> Hi Bob, do you have a good estimate for an Xmx to set ? >>>>> >>>>>> It seems fragile to disable >>>>>> appinding all test options altogether. Clearly, this test is >>>>>> susceptible to passed -Xmx options. >>>>> >>>>> We have here a java - execution taking place in the docker container, >> not >>>> the test machine itself . >>>>> I am not sure , are the "regular" test options so good for this special >>>> execution ? Some maybe are , some aren?t ... >>>>> >>>>> E.g. we ended up with >>>>> >>>>> -Xmx768m -Djava.awt.headless=true >>>>> >>>>> and more strange settings in the "docker run" call because of this ... >>>>> >>>>> Best regards, Matthias >>>>> >>>>> >>>>> >>>>>> Hi Matthias, >>>>>> >>>>>> On Fri, 2019-08-16 at 06:10 +0000, Baesken, Matthias wrote: >>>>>>>> Unfortunately we do not see the expected >>>>>> "java.lang.OutOfMemoryError" >>>>>>>> in the nightly test runs . >>>>>>>> >>>>>>>> When I execute the jtreg test locally on the same (!) ppc64le >>>> machine , >>>>>>>> under the same user but not from the test framework we use >> nightly >>>>>>>> the "java.lang.OutOfMemoryError" shows up. >>>>>>> >>>>>>> Hello, after looking a bit more into it, we observed that the nightly >>>> runs >>>>>> set a higher -Xmx = 768m value that gets inherited into the >>>>>> DockerRunOptions >>>>>>> And made the central test fail . >>>>>>> So I had to remove this : >>>>>>> >>>>>>> 105 // make sure we avoid Xmx settings from the jtreg vmoptions >>>>>>> 106 opts.appendTestJavaOptions = false; >>>>>> >>>>>> Can we not set -Xmx explicitly after any test options have been >>>>>> appended so that it takes precedence? It seems fragile to disable >>>>>> appinding all test options altogether. Clearly, this test is >>>>>> susceptible to passed -Xmx options. >>>>>> >>>>>> Failing that, could we just omit the -Xmx option? >>>>>> >>>>>> Thanks, >>>>>> Severin >>>>>> >>>>>>> New webrev : >>>>>>> >>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8229182.2/ >>>>>>> >>>>>>> Best regards, Matthias >>>>>>> >>>>>>> >>>>>>>> Hi Christoph, >>>>>>>> >>>>>>>>> Hi Matthias, >>>>>>>>> >>>>>>>>> looks good to me in general. >>>>>>>>> >>>>>>>>> However, I'm not convinced that line 114 >>>>>>>>> ".shouldContain("java.lang.OutOfMemoryError");" won't provoke a >>>>>> test >>>>>>>>> error in case the child process was killed by the container, e.g. >> exited >>>>>> with >>>>>>>>> exit code 137. We should at least run this patch for several days in >> our >>>>>>>> system >>>>>>>>> to see if it catches all variations of the problem. >>>>>>>>> >>>>>>>> >>>>>>>> Unfortunately we do not see the expected >>>>>> "java.lang.OutOfMemoryError" >>>>>>>> in the nightly test runs . >>>>>>>> >>>>>>>> When I execute the jtreg test locally on the same (!) ppc64le >>>> machine , >>>>>>>> under the same user but not from the test framework we use >> nightly >>>>>>>> the "java.lang.OutOfMemoryError" shows up. >>>>>>>> >>>>>>>> Best regards, Matthias >>>>>>>> >>>>>>>> >>>>> >>> > From matthias.baesken at sap.com Tue Aug 27 13:49:18 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 27 Aug 2019 13:49:18 +0000 Subject: RFR [XS] : 8229182: runtime/containers/docker/TestMemoryAwareness.java test fails on SLES12 In-Reply-To: <55A6F5EE-7212-4EDC-A0DE-B644BBC1E3A6@oracle.com> References: <6563ed4bd315281320e11755597fec24f4092ded.camel@redhat.com> <0924470c2bac638fa1feab7d63ee71a57904e408.camel@redhat.com> <9187885973675ab53221ad3140e79e0115e509a2.camel@redhat.com> <1F1258AE-747D-4024-945A-6380ECC5EB9A@oracle.com> <2F25EFBB-363C-491C-B06A-9CDD8C4011BE@oracle.com> <55A6F5EE-7212-4EDC-A0DE-B644BBC1E3A6@oracle.com> Message-ID: Hi Bob, that's the new change : http://cr.openjdk.java.net/~mbaesken/webrevs/8229182.3/ I do not set " opts.appendTestJavaOptions = false;" any more . Instead I set the Xmx . However doing so requires the setting AFTER the testJavaOpts. > >>>> Instead of adding this: opts.appendTestJavaOptions = false; > >>>> > >>>> > >>>> Try adding these lines: > >>>> > >>>> String javaHeapSize = new String(sizeToAllocInMb/2) + ?m?; > >>>> > >>>> opts.addJavaOpts("-Xmx" + javaHeapSize); > >>>> > >>>> This will set the max Java Heap to 1/2 of the size that we will attempt to > >>>> allocate. > >>>> This should reliably cause an OOM exception. Regarding your concern : > I would be concerned that the change in ordering would break other tests. That might be possible . In case we want to be safe, I suggest to add an additional method " appendJavaOpts " opts.appendJavaOpts("-Xmx" + javaHeapSize); to DockerRunOptions ; appendJavaOpts would append the options after the testJavaOpts (so Xmx can be overwritten ). Best regards, Matthias > -----Original Message----- > From: Bob Vandette > Sent: Dienstag, 27. August 2019 15:18 > To: Baesken, Matthias > Cc: Severin Gehwolf ; Langer, Christoph > ; hotspot-dev at openjdk.java.net; Zeller, Arno > > Subject: Re: RFR [XS] : 8229182: > runtime/containers/docker/TestMemoryAwareness.java test fails on SLES12 > > I would be concerned that the change in ordering would break other tests. > > Your experiment shows that appendTestJavaOptions is true! > > Aren't you setting this to false?? > > Bob. > > > > On Aug 27, 2019, at 9:12 AM, Baesken, Matthias > wrote: > > > > Hi Bob, I looked a bit more into it. With this small additional change : > > > > test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java > > > > public static List buildJavaCommand(DockerRunOptions opts) > throws Exception { > > ...... > > // ********* move AFTER test java options ********** > > //cmd.addAll(opts.javaOpts); > > if (opts.appendTestJavaOptions) { > > Collections.addAll(cmd, Utils.getTestJavaOpts()); > > } > > cmd.addAll(opts.javaOpts); > > > > cmd.add(opts.classToRun); > > cmd.addAll(opts.classParams); > > > > return cmd; > > } > > > > > > It works. Obviously the Utils.getTestJavaOpts would overwrite the Xmx > setting from javaOpts. > > Do you think it is fine to change the order of javaOpts and testJavaOpts ? > > > > Best regards, Matthias > > > > > >> -----Original Message----- > >> From: Bob Vandette > >> Sent: Dienstag, 27. August 2019 14:44 > >> To: Baesken, Matthias > >> Cc: Severin Gehwolf ; Langer, Christoph > >> ; hotspot-dev at openjdk.java.net; Zeller, > Arno > >> > >> Subject: Re: RFR [XS] : 8229182: > >> runtime/containers/docker/TestMemoryAwareness.java test fails on > SLES12 > >> > >> Can you send out the updated webrev? > >> > >> Are you sure you retained this change? > >> > >> opts.appendTestJavaOptions = false; > >> > >> We?ll need to figure out why this isn?t inhibiting the jtreg options. > >> > >> Bob.; > >> > >> > >> > >>> On Aug 27, 2019, at 8:35 AM, Baesken, Matthias > >> wrote: > >>> > >>> Hi Bob, I tried your suggestion . > >>> > >>> It leads to > >>> > >>> java.lang.RuntimeException: 'java.lang.OutOfMemoryError' missing from > >> stdout/stderr > >>> > >>> at > >> > jdk.test.lib.process.OutputAnalyzer.shouldContain(OutputAnalyzer.java:187) > >>> at > >> TestMemoryAwareness.testOOM(TestMemoryAwareness.java:120) > >>> at TestMemoryAwareness.main(TestMemoryAwareness.java:63) > >>> at > >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > >> Method) > >>> at > >> > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMet > >> hodAccessorImpl.java:62) > >>> at > >> > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Delega > >> tingMethodAccessorImpl.java:43) > >>> at java.base/java.lang.reflect.Method.invoke(Method.java:564) > >>> at > >> > com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run( > >> MainActionHelper.java:298) > >>> at java.base/java.lang.Thread.run(Thread.java:830) > >>> > >>> JavaTest Message: Test threw exception: java.lang.RuntimeException > >>> JavaTest Message: shutting down test > >>> > >>> result: Failed. Execution failed: `main' threw exception: > >> java.lang.RuntimeException: 'java.lang.OutOfMemoryError' missing from > >> stdout/stderr > >>> > >>> > >>> In the docker call we have now both > >>> > >>> -Xmx133m and -Xmx768m > >>> > >>> See : > >>> > >>> docker run --tty=true --rm --volume > /net/usr.work/d040975/mytmp/jtreg- > >> workdir/classes/containers/docker/TestMemoryAwareness.d:/test- > classes/ > >> --memory 256m --memory-swappiness 0 --memory-swap 256m jdk- > >> internal:test-memory /jdk/bin/java -Xlog:os+container=trace -cp /test- > >> classes/ -Xmx133m -Xmx768m -Djava.awt.headless=true AttemptOOM > 266 > >>> > >>> > >>> Best regards, Matthias > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Bob Vandette > >>>> Sent: Freitag, 16. August 2019 14:36 > >>>> To: Baesken, Matthias > >>>> Cc: Severin Gehwolf ; Langer, Christoph > >>>> ; hotspot-dev at openjdk.java.net; Zeller, > >> Arno > >>>> > >>>> Subject: Re: RFR [XS] : 8229182: > >>>> runtime/containers/docker/TestMemoryAwareness.java test fails on > >> SLES12 > >>>> > >>>> Instead of adding this: opts.appendTestJavaOptions = false; > >>>> > >>>> > >>>> Try adding these lines: > >>>> > >>>> String javaHeapSize = new String(sizeToAllocInMb/2) + ?m?; > >>>> > >>>> opts.addJavaOpts("-Xmx" + javaHeapSize); > >>>> > >>>> This will set the max Java Heap to 1/2 of the size that we will attempt to > >>>> allocate. > >>>> This should reliably cause an OOM exception. > >>>> > >>>> Bob. > >>>> > >>>> > >>>>> On Aug 16, 2019, at 4:14 AM, Baesken, Matthias > >>>> wrote: > >>>>> > >>>>>> Can we not set -Xmx explicitly after any test options have been > >>>>>> appended so that it takes precedence? > >>>>> > >>>>> Hi Bob, do you have a good estimate for an Xmx to set ? > >>>>> > >>>>>> It seems fragile to disable > >>>>>> appinding all test options altogether. Clearly, this test is > >>>>>> susceptible to passed -Xmx options. > >>>>> > >>>>> We have here a java - execution taking place in the docker container, > >> not > >>>> the test machine itself . > >>>>> I am not sure , are the "regular" test options so good for this special > >>>> execution ? Some maybe are , some aren?t ... > >>>>> > >>>>> E.g. we ended up with > >>>>> > >>>>> -Xmx768m -Djava.awt.headless=true > >>>>> > >>>>> and more strange settings in the "docker run" call because of this > ... > >>>>> > >>>>> Best regards, Matthias > >>>>> > >>>>> > >>>>> > >>>>>> Hi Matthias, > >>>>>> > >>>>>> On Fri, 2019-08-16 at 06:10 +0000, Baesken, Matthias wrote: > >>>>>>>> Unfortunately we do not see the expected > >>>>>> "java.lang.OutOfMemoryError" > >>>>>>>> in the nightly test runs . > >>>>>>>> > >>>>>>>> When I execute the jtreg test locally on the same (!) ppc64le > >>>> machine , > >>>>>>>> under the same user but not from the test framework we use > >> nightly > >>>>>>>> the "java.lang.OutOfMemoryError" shows up. > >>>>>>> > >>>>>>> Hello, after looking a bit more into it, we observed that the > nightly > >>>> runs > >>>>>> set a higher -Xmx = 768m value that gets inherited into the > >>>>>> DockerRunOptions > >>>>>>> And made the central test fail . > >>>>>>> So I had to remove this : > >>>>>>> > >>>>>>> 105 // make sure we avoid Xmx settings from the jtreg > vmoptions > >>>>>>> 106 opts.appendTestJavaOptions = false; > >>>>>> > >>>>>> Can we not set -Xmx explicitly after any test options have been > >>>>>> appended so that it takes precedence? It seems fragile to disable > >>>>>> appinding all test options altogether. Clearly, this test is > >>>>>> susceptible to passed -Xmx options. > >>>>>> > >>>>>> Failing that, could we just omit the -Xmx option? > >>>>>> > >>>>>> Thanks, > >>>>>> Severin > >>>>>> > >>>>>>> New webrev : > >>>>>>> > >>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8229182.2/ > >>>>>>> > >>>>>>> Best regards, Matthias > >>>>>>> > >>>>>>> > >>>>>>>> Hi Christoph, > >>>>>>>> > >>>>>>>>> Hi Matthias, > >>>>>>>>> > >>>>>>>>> looks good to me in general. > >>>>>>>>> > >>>>>>>>> However, I'm not convinced that line 114 > >>>>>>>>> ".shouldContain("java.lang.OutOfMemoryError");" won't > provoke a > >>>>>> test > >>>>>>>>> error in case the child process was killed by the container, e.g. > >> exited > >>>>>> with > >>>>>>>>> exit code 137. We should at least run this patch for several days > in > >> our > >>>>>>>> system > >>>>>>>>> to see if it catches all variations of the problem. > >>>>>>>>> > >>>>>>>> > >>>>>>>> Unfortunately we do not see the expected > >>>>>> "java.lang.OutOfMemoryError" > >>>>>>>> in the nightly test runs . > >>>>>>>> > >>>>>>>> When I execute the jtreg test locally on the same (!) ppc64le > >>>> machine , > >>>>>>>> under the same user but not from the test framework we use > >> nightly > >>>>>>>> the "java.lang.OutOfMemoryError" shows up. > >>>>>>>> > >>>>>>>> Best regards, Matthias > >>>>>>>> > >>>>>>>> > >>>>> > >>> > > From sgehwolf at redhat.com Tue Aug 27 14:07:54 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 27 Aug 2019 16:07:54 +0200 Subject: RFR [XS] : 8229182: runtime/containers/docker/TestMemoryAwareness.java test fails on SLES12 In-Reply-To: References: <6563ed4bd315281320e11755597fec24f4092ded.camel@redhat.com> <0924470c2bac638fa1feab7d63ee71a57904e408.camel@redhat.com> <9187885973675ab53221ad3140e79e0115e509a2.camel@redhat.com> <1F1258AE-747D-4024-945A-6380ECC5EB9A@oracle.com> <2F25EFBB-363C-491C-B06A-9CDD8C4011BE@oracle.com> <55A6F5EE-7212-4EDC-A0DE-B644BBC1E3A6@oracle.com> Message-ID: <73ff0c1940648800b27e02fc1c4575a780be2792.camel@redhat.com> On Tue, 2019-08-27 at 13:49 +0000, Baesken, Matthias wrote: > http://cr.openjdk.java.net/~mbaesken/webrevs/8229182.3/ OK, so, in summary, the constraints are as follows: * We don't want to turn of appending global test java options as these could possibly contain local options to a specific test environment. It would be a surprise if docker tests wouldn't have them. * Just setting Java options is not enough as the intention is to set them for the Docker test, but could potentially be overridden by global test options (this issue). Given we'd like to keep that general design, maybe it would make sense to create a 3'rd, separate set of flags, neither java options nor test options would manage to override. Call it "overrideJavaOpts" or some such. At least that would make it clear that these options if set have the final say. Thoughts? Thanks, Severin From matthias.baesken at sap.com Tue Aug 27 14:20:48 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Tue, 27 Aug 2019 14:20:48 +0000 Subject: RFR [XS] : 8229182: runtime/containers/docker/TestMemoryAwareness.java test fails on SLES12 In-Reply-To: <73ff0c1940648800b27e02fc1c4575a780be2792.camel@redhat.com> References: <6563ed4bd315281320e11755597fec24f4092ded.camel@redhat.com> <0924470c2bac638fa1feab7d63ee71a57904e408.camel@redhat.com> <9187885973675ab53221ad3140e79e0115e509a2.camel@redhat.com> <1F1258AE-747D-4024-945A-6380ECC5EB9A@oracle.com> <2F25EFBB-363C-491C-B06A-9CDD8C4011BE@oracle.com> <55A6F5EE-7212-4EDC-A0DE-B644BBC1E3A6@oracle.com> <73ff0c1940648800b27e02fc1c4575a780be2792.camel@redhat.com> Message-ID: Hello , my suggestions was " appendJavaOpts " : In case we want to be safe, I suggest to add an additional method " appendJavaOpts " opts.appendJavaOpts("-Xmx" + javaHeapSize); to DockerRunOptions ; appendJavaOpts would append the options after the testJavaOpts (so Xmx can be overwritten ). But if overrideJavaOpts is preferred that fine with me too ... Best regards, Matthias > > On Tue, 2019-08-27 at 13:49 +0000, Baesken, Matthias wrote: > > http://cr.openjdk.java.net/~mbaesken/webrevs/8229182.3/ > > OK, so, in summary, the constraints are as follows: > > * We don't want to turn of appending global test java options as these > could possibly contain local options to a specific test environment. > It would be a surprise if docker tests wouldn't have them. > * Just setting Java options is not enough as the intention is to set > them for the Docker test, but could potentially be overridden by > global test options (this issue). > > Given we'd like to keep that general design, maybe it would make sense > to create a 3'rd, separate set of flags, neither java options nor test > options would manage to override. Call it "overrideJavaOpts" or some > such. At least that would make it clear that these options if set have > the final say. > > Thoughts? > > Thanks, > Severin From sgehwolf at redhat.com Tue Aug 27 14:33:36 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 27 Aug 2019 16:33:36 +0200 Subject: RFR [XS] : 8229182: runtime/containers/docker/TestMemoryAwareness.java test fails on SLES12 In-Reply-To: References: <6563ed4bd315281320e11755597fec24f4092ded.camel@redhat.com> <0924470c2bac638fa1feab7d63ee71a57904e408.camel@redhat.com> <9187885973675ab53221ad3140e79e0115e509a2.camel@redhat.com> <1F1258AE-747D-4024-945A-6380ECC5EB9A@oracle.com> <2F25EFBB-363C-491C-B06A-9CDD8C4011BE@oracle.com> <55A6F5EE-7212-4EDC-A0DE-B644BBC1E3A6@oracle.com> <73ff0c1940648800b27e02fc1c4575a780be2792.camel@redhat.com> Message-ID: <6281a0bca33bd34981063969bfd2415cdc41729e.camel@redhat.com> On Tue, 2019-08-27 at 14:20 +0000, Baesken, Matthias wrote: > Hello , my suggestions was " appendJavaOpts " : > OK, got it now. Looking at the webrev this wasn't clear as it didn't do that. > In case we want to be safe, I suggest to > add an additional method " appendJavaOpts " > > opts.appendJavaOpts("-Xmx" + javaHeapSize); > > to DockerRunOptions ; appendJavaOpts would append the > options after the testJavaOpts (so Xmx can be overwritten ). > > But if overrideJavaOpts is preferred that fine with me too ... I'd prefer a more telling name than "append". I'd ask myself when trying to use it: Does it append to regular java options? How is it different from addJavaOpts()? You get the idea. I'd prefer overrideJavaOpts for that reason. Perhaps addOverrideOpts()? Either way, the javadoc should make it clear what adding options there means. Thanks, Severin > Best regards, Matthias > > > > On Tue, 2019-08-27 at 13:49 +0000, Baesken, Matthias wrote: > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8229182.3/ > > > > OK, so, in summary, the constraints are as follows: > > > > * We don't want to turn of appending global test java options as > > these > > could possibly contain local options to a specific test > > environment. > > It would be a surprise if docker tests wouldn't have them. > > * Just setting Java options is not enough as the intention is to > > set > > them for the Docker test, but could potentially be overridden by > > global test options (this issue). > > > > Given we'd like to keep that general design, maybe it would make > > sense > > to create a 3'rd, separate set of flags, neither java options nor > > test > > options would manage to override. Call it "overrideJavaOpts" or > > some > > such. At least that would make it clear that these options if set > > have > > the final say. > > > > Thoughts? > > > > Thanks, > > Severin From 363263870 at qq.com Tue Aug 27 14:36:15 2019 From: 363263870 at qq.com (=?ISO-8859-1?B?WWl6dW4gV2FuZw==?=) Date: Tue, 27 Aug 2019 22:36:15 +0800 Subject: hotspot-dev Digest, Vol 148, Issue 72[Is it suitable to change from strncpy to strcpy?] Message-ID: Hi, Please send this mail to Andrew Hughes, thanks! To Andrew, From https://cr.openjdk.java.net/~andrew/openjdk8/8140482/webrev.01/src/share/vm/services/heapDumper.cpp.cdiff.html we can see that you change from strncpy to strcpy. But strcpy is vulnerable to buffer overflow, which may not meet the demand of coverity scan result. So I suggest that you do not change the code. Sorry for inconvenience. Regards, Yizun Wang, SPD Bank ------------------ Original ------------------ From: "hotspot-dev-request"; Date: Tue, Aug 27, 2019 03:58 PM To: "hotspot-dev"; Subject: hotspot-dev Digest, Vol 148, Issue 72 Send hotspot-dev mailing list submissions to hotspot-dev at openjdk.java.net To subscribe or unsubscribe via the World Wide Web, visit https://mail.openjdk.java.net/mailman/listinfo/hotspot-dev or, via email, send a message with subject or body 'help' to hotspot-dev-request at openjdk.java.net You can reach the person managing the list at hotspot-dev-owner at openjdk.java.net When replying, please edit your Subject line so it is more specific than "Re: Contents of hotspot-dev digest..." Today's Topics: 1. Re: [8u] [RFR] 8140482: Various minor code improvements (runtime) (Severin Gehwolf) 2. Re: RFR 8229919: Support JNI Critical functions in object pinning API on x86_32 platforms (Zhengyu Gu) 3. RFR: 8230203: Replace markWord enums with uintptr_t constants (Stefan Karlsson) 4. RE: RFR [XS]: 8229370: make jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java more stable (Baesken, Matthias) 5. Re: RFR [XS]: 8229370: make jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java more stable (David Holmes) ---------------------------------------------------------------------- Message: 1 Date: Mon, 26 Aug 2019 16:20:10 +0200 From: Severin Gehwolf To: "Lindenmaier, Goetz" , Andrew Hughes , serviceability-dev , hotspot-dev Subject: Re: [8u] [RFR] 8140482: Various minor code improvements (runtime) Message-ID: Content-Type: text/plain; charset="UTF-8" Hi, On Thu, 2018-11-22 at 08:51 +0000, Lindenmaier, Goetz wrote: > Hi, > > Doesn't this have to be posted to jdk8u-dev? > > I had a look at the backport. > Including 7127191 confused me a bit. Is it good to hide the fact that > this was backported in the repository? > In os_linux one fix is missing, is this on purpose? I don't think this is a > critical issue, though, so leaving it out is fine. > > > the dropping of the changes to ... > > src/share/vm/runtime/task.cpp and > > src/os/windows/vm/attachListener_windows.cpp > These changes are included in the webrev ...? > > The webrev looks good to me. > > Best regards, > Goetz. > > > > > > > -----Original Message----- > > From: hotspot-dev On Behalf Of > > Andrew Hughes > > Sent: Mittwoch, 21. November 2018 07:45 > > To: serviceability-dev ; hotspot-dev > > > > Subject: [8u] [RFR] 8140482: Various minor code improvements (runtime) > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8140482 > > Original changeset: > > https://hg.openjdk.java.net/jdk-updates/jdk9u/hotspot/rev/cd86b5699825 > > Webrev: > > https://cr.openjdk.java.net/~andrew/openjdk8/8140482/webrev.01/ > > > > The patch largely applies as is, with some adjustment for context and > > the dropping of the changes to src/cpu/x86/vm/stubRoutines_x86.cpp, > > src/share/vm/runtime/task.cpp and > > src/os/windows/vm/attachListener_windows.cpp > > which don't exist in 8u. A clean backport of 7127191 is included, which > > allows the changes to agent/src/os/linux/libproc_impl.c to apply as-is. > > > > Applying the change to 8u improves the code quality there and aids > > in backporting other changes, such as 8210836 [0]. > > > > Ok for 8u? > > > > [0] https://mail.openjdk.java.net/pipermail/serviceability-dev/2018- > > November/025991.html > > > > Thanks, Reviving this old thread. Andrew, could you please rebase this patch to latest 8u? AFAIK, 7127191 has been included since in 8u and the review would be easier if the webrev didn't show it. I'd need this backport to go in so as to proceed with JDK-8210836. Thanks, Severin ------------------------------ Message: 2 Date: Mon, 26 Aug 2019 16:49:01 -0400 From: Zhengyu Gu To: HotSpot Open Source Developers , shenandoah-dev Subject: Re: RFR 8229919: Support JNI Critical functions in object pinning API on x86_32 platforms Message-ID: <8cc6bb50-80d1-93da-1601-1f780f2febf4 at redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Passed submit tests. Thanks, -Zhengyu On 8/22/19 2:57 PM, Zhengyu Gu wrote: > Please review this patch that supports JNI critical functions in object > pinning capable GCs on x86_32 platforms. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8229919 > Webrev: http://cr.openjdk.java.net/~zgu/JDK-8229919/webrev.00/ > > Test: > ? hotspot_gc_shenandoah (fastdebug and release) with 32-bit VM on Linux > x86_64. > ? hotspot_gc, hotspot_runtime and hotspot_compiler > ? Submit tests in progress. > > Thanks, > > -Zhengyu ------------------------------ Message: 3 Date: Tue, 27 Aug 2019 09:32:33 +0200 From: Stefan Karlsson To: hotspot-dev Subject: RFR: 8230203: Replace markWord enums with uintptr_t constants Message-ID: <1c706a0b-4be8-9255-74dc-83a0311b4023 at oracle.com> Content-Type: text/plain; charset=utf-8; format=flowed Hi all, Please review this patch to convert the enum constants in markWord into static const unintptr_t constants. http://cr.openjdk.java.net/~stefank/8230203/webrev.01/ https://bugs.openjdk.java.net/browse/JDK-8230203 This is a follow-up RFE from the review of JDK-8229258, where a number of unnecessary casts were pointed out. There was also a recent bug in this area, JDK-8221725, where Thomas points out the problem of relying on the bit width of the enum values. This patch: 1) changes all constants to have the same type as the markWord::_value field. 2) Removes unnecessary uintptr_t casts 3) Removes uintx casts, because they are typedefed to be uintptr_t 4) Adds explicit casts to (int) when values are negated. 5) Try to only use uintptr_t inside markWord. 6) Leaves the use of intptr_t for parameters and return types of the different hash functions. Tested with tier1-3 Thanks, StefanK ------------------------------ Message: 4 Date: Tue, 27 Aug 2019 07:41:05 +0000 From: "Baesken, Matthias" To: "'hotspot-dev at openjdk.java.net'" , "hotspot-jfr-dev at openjdk.java.net" Subject: RE: RFR [XS]: 8229370: make jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java more stable Message-ID: Content-Type: text/plain; charset="us-ascii" Hello, any reviews for this small change ? Thanks , Matthias From: Baesken, Matthias Sent: Montag, 12. August 2019 14:33 To: 'hotspot-dev at openjdk.java.net' ; 'hotspot-jfr-dev at openjdk.java.net' Subject: RFR [XS]: 8229370: make jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java more stable Hello, please review this small test enhancement. We noticed that on some of our Linux machines (SLES12 based) the TestNetworkUtilizationEvent.java test reported just 1 interface (the test TestNetworkUtilizationEvent.java expects more than 1 on Linux). Looking into the HS code , os_perf_linux.cpp collects the interfaces + additional information about bytes read/written (by looking at /sys/class/net/eth/statistics/ ) and this info is given to JFR . However it seems to need (at least on some machines / setups) more packet send operations / potential retries to really get counter updates (and without updates in the counters, no interfaces are found). So I adjusted the test accordingly. Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8229370 http://cr.openjdk.java.net/~mbaesken/webrevs/8229370.0/ Best regards, Matthias ------------------------------ Message: 5 Date: Tue, 27 Aug 2019 17:55:54 +1000 From: David Holmes To: "Baesken, Matthias" , "'hotspot-dev at openjdk.java.net'" , "hotspot-jfr-dev at openjdk.java.net" Subject: Re: RFR [XS]: 8229370: make jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java more stable Message-ID: <9f1e22b3-14c9-ecb1-e0b0-d6c19fa02a4e at oracle.com> Content-Type: text/plain; charset=utf-8; format=flowed Hi Matthias, On 27/08/2019 5:41 pm, Baesken, Matthias wrote: > Hello, any reviews for this small change ? I missed the initial request - sorry. Seems we have a double up of effort here as we also have JDK-8228990 for the exact same problem that we see on some of our test machines. Our analysis suggests that this test often passes by accident due to incidental activity on the real network interface when the logic intended to generate that activity (the packet sent to 10.0.0.0:12345) actually had no affect (unreachable address). If there is no incidental network activity then the real network interface is not seen and so the test fails. David > Thanks , Matthias > > From: Baesken, Matthias > Sent: Montag, 12. August 2019 14:33 > To: 'hotspot-dev at openjdk.java.net' ; 'hotspot-jfr-dev at openjdk.java.net' > Subject: RFR [XS]: 8229370: make jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java more stable > > Hello, please review this small test enhancement. > > We noticed that on some of our Linux machines (SLES12 based) the TestNetworkUtilizationEvent.java test reported just 1 interface > (the test TestNetworkUtilizationEvent.java expects more than 1 on Linux). > > Looking into the HS code , os_perf_linux.cpp collects the interfaces + additional information about bytes read/written (by looking at /sys/class/net/eth/statistics/ ) > and this info is given to JFR . > > However it seems to need (at least on some machines / setups) more packet send operations / potential retries to really get counter updates (and without updates in the counters, no interfaces are found). > So I adjusted the test accordingly. > > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8229370 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8229370.0/ > > > Best regards, Matthias > End of hotspot-dev Digest, Vol 148, Issue 72 ******************************************** From martin.doerr at sap.com Tue Aug 27 14:37:14 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 27 Aug 2019 14:37:14 +0000 Subject: RFR: 8230203: Replace markWord enums with uintptr_t constants In-Reply-To: References: <1c706a0b-4be8-9255-74dc-83a0311b4023@oracle.com> Message-ID: Hi Stefan, > > I think it would be better to use C++ 2011 Strongly-typed Enums. > > Could you elaborate why it would be better to use them in this case? IMHO enums are better to read and edit. I don't like "static const uintptr_t" replicated 100 times. In addition, static consts usually spam the binaries with stuff which is never needed while enums are only for the compiler. I don't understand what keeps us from targeting JEP 347 to jdk14. Best regards, Martin > -----Original Message----- > From: Stefan Karlsson > Sent: Dienstag, 27. August 2019 13:08 > To: Doerr, Martin ; David Holmes > ; hotspot-dev dev at openjdk.java.net>; Kim Barrett > Subject: Re: RFR: 8230203: Replace markWord enums with uintptr_t > constants > > Hi Martin, > > On 2019-08-27 10:22, Doerr, Martin wrote: > > Hi, > > > > I think it would be better to use C++ 2011 Strongly-typed Enums. > > Could you elaborate why it would be better to use them in this case? > > AFAICT these enums where only enums because that used to be the way > constants were written in HotSpot. There are some comments around this in: > https://bugs.openjdk.java.net/browse/JDK-8153116 > > Can we still not use them? > > AFAIK all compilers which are used for jdk/jdk support that. > > I don't think we can go there until we get: > https://openjdk.java.net/jeps/347 - JEP 347: Adopt C++14 Language > Features in HotSpot > > Thanks, > StefanK > > > > > Best regards, > > Martin > > > > > >> -----Original Message----- > >> From: hotspot-dev On Behalf > Of > >> David Holmes > >> Sent: Dienstag, 27. August 2019 10:02 > >> To: Stefan Karlsson ; hotspot-dev > >> dev at openjdk.java.net> > >> Subject: Re: RFR: 8230203: Replace markWord enums with uintptr_t > >> constants > >> > >> Hi Stefan, > >> > >> On 27/08/2019 5:32 pm, Stefan Karlsson wrote: > >>> Hi all, > >>> > >>> Please review this patch to convert the enum constants in markWord > into > >>> static const unintptr_t constants. > >>> > >>> http://cr.openjdk.java.net/~stefank/8230203/webrev.01/ > >>> https://bugs.openjdk.java.net/browse/JDK-8230203 > >> > >> Overall this seems like a good cleanup, but the introduced "int" casts > >> now jump out at me. In: > >> > >> src/hotspot/cpu/aarch64/aarch64.ad > >> src/hotspot/cpu/arm/macroAssembler_arm.cpp > >> src/hotspot/cpu/ppc/macroAssembler_ppc.cpp > >> > >> it would seem to me that all the "add -(int)markWord::monitor_value" > >> would be cleaner/clearer as: "sub markWord::monitor_value". But that is > >> a bit out of scope for your change - it just jumped out at me. I expect > >> add is more efficient than sub. > >> > >> In src/hotspot/share/opto/macro.cpp I don't understand why this int > >> cast is needed: > >> > >> Node* not_biased_ctrl = opt_bits_test(ctrl, region, 3, x_node, > >> ! > >> (~(int)markWord::age_mask_in_place), 0); > >> > >> I'm unclear if this is really > >> > >> ~(int)markWord::age_mask_in_place > >> > >> or > >> > >> (int)(~markWord::age_mask_in_place) > >> > >> ? If the latter then okay. If the former then I don't grok it. :) > >> > >> Thanks, > >> David > >> ----- > >> > >>> This is a follow-up RFE from the review of JDK-8229258, where a number > >>> of unnecessary casts were pointed out. > >>> > >>> There was also a recent bug in this area, JDK-8221725, where Thomas > >>> points out the problem of relying on the bit width of the enum values. > >>> > >>> This patch: > >>> 1) changes all constants to have the same type as the markWord::_value > >>> field. > >>> 2) Removes unnecessary uintptr_t casts > >>> 3) Removes uintx casts, because they are typedefed to be uintptr_t > >>> 4) Adds explicit casts to (int) when values are negated. > >>> 5) Try to only use uintptr_t inside markWord. > >>> 6) Leaves the use of intptr_t for parameters and return types of the > >>> different hash functions. > >>> > >>> Tested with tier1-3 > >>> > >>> Thanks, > >>> StefanK From zgu at redhat.com Tue Aug 27 14:53:10 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 27 Aug 2019 10:53:10 -0400 Subject: RFR (XS) 8230215: MacOS debug build is broken after JDK-8230003 In-Reply-To: References: Message-ID: <4c95db67-17ad-ab67-7d47-e4419b10a5f6@redhat.com> Looks good to me. Thanks, -Zhengyu On 8/27/19 6:45 AM, Aleksey Shipilev wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8230215 > > I do this fix blindly, because my MacOS environments actually build jdk/jdk fine. I would appreciate > if anyone who has MacOS env currently broken would confirm it fixes the breakage. > > Fix: > https://cr.openjdk.java.net/~shade/8230215/webrev.01/ > > Testing: Linux x86_64 build, MacOS x86_64 build > From zgu at redhat.com Tue Aug 27 14:55:24 2019 From: zgu at redhat.com (Zhengyu Gu) Date: Tue, 27 Aug 2019 10:55:24 -0400 Subject: RFR (XS) 8230118: 32-bit build failures after JDK-8227054 In-Reply-To: <3cafb334-7896-c0f7-a7a2-7e841a5aa58e@redhat.com> References: <4dee1825-f0e0-9bfc-d509-29717e05ee67@redhat.com> <3cafb334-7896-c0f7-a7a2-7e841a5aa58e@redhat.com> Message-ID: <8e3de911-197d-fb7f-c647-143cc97ff731@redhat.com> Good to me. Thanks, -Zhengyu On 8/27/19 4:03 AM, Aleksey Shipilev wrote: > On 8/26/19 9:43 AM, Aleksey Shipilev wrote: >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8230118 >> >> I believe we should just use pointer_delta: >> http://cr.openjdk.java.net/~shade/8230118/webrev.01/ >> >> Testing: build, tier1 {x86_32, x86_64} > > Friendly reminder. I guess I should have cc'ed Kim. > From bob.vandette at oracle.com Tue Aug 27 15:42:19 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Tue, 27 Aug 2019 11:42:19 -0400 Subject: RFR [XS] : 8229182: runtime/containers/docker/TestMemoryAwareness.java test fails on SLES12 In-Reply-To: <6281a0bca33bd34981063969bfd2415cdc41729e.camel@redhat.com> References: <6563ed4bd315281320e11755597fec24f4092ded.camel@redhat.com> <0924470c2bac638fa1feab7d63ee71a57904e408.camel@redhat.com> <9187885973675ab53221ad3140e79e0115e509a2.camel@redhat.com> <1F1258AE-747D-4024-945A-6380ECC5EB9A@oracle.com> <2F25EFBB-363C-491C-B06A-9CDD8C4011BE@oracle.com> <55A6F5EE-7212-4EDC-A0DE-B644BBC1E3A6@oracle.com> <73ff0c1940648800b27e02fc1c4575a780be2792.camel@redhat.com> <6281a0bca33bd34981063969bfd2415cdc41729e.camel@redhat.com> Message-ID: This is an isolated problem and I don?t like the idea of adding a new option just for this case. What if we parse the options and eliminated the general -Xmx option if one was specified by the test? After all, this is the intention of adding a test specific heap limit. Bob. > On Aug 27, 2019, at 10:33 AM, Severin Gehwolf wrote: > > On Tue, 2019-08-27 at 14:20 +0000, Baesken, Matthias wrote: >> Hello , my suggestions was " appendJavaOpts " : >> > > OK, got it now. Looking at the webrev this wasn't clear as it didn't do > that. > >> In case we want to be safe, I suggest to >> add an additional method " appendJavaOpts " >> >> opts.appendJavaOpts("-Xmx" + javaHeapSize); >> >> to DockerRunOptions ; appendJavaOpts would append the >> options after the testJavaOpts (so Xmx can be overwritten ). >> >> But if overrideJavaOpts is preferred that fine with me too ... > > I'd prefer a more telling name than "append". I'd ask myself when > trying to use it: Does it append to regular java options? How is it > different from addJavaOpts()? You get the idea. I'd prefer > overrideJavaOpts for that reason. > > Perhaps addOverrideOpts()? Either way, the javadoc should make it clear > what adding options there means. > > Thanks, > Severin > >> Best regards, Matthias >> >> >>> On Tue, 2019-08-27 at 13:49 +0000, Baesken, Matthias wrote: >>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8229182.3/ >>> >>> OK, so, in summary, the constraints are as follows: >>> >>> * We don't want to turn of appending global test java options as >>> these >>> could possibly contain local options to a specific test >>> environment. >>> It would be a surprise if docker tests wouldn't have them. >>> * Just setting Java options is not enough as the intention is to >>> set >>> them for the Docker test, but could potentially be overridden by >>> global test options (this issue). >>> >>> Given we'd like to keep that general design, maybe it would make >>> sense >>> to create a 3'rd, separate set of flags, neither java options nor >>> test >>> options would manage to override. Call it "overrideJavaOpts" or >>> some >>> such. At least that would make it clear that these options if set >>> have >>> the final say. >>> >>> Thoughts? >>> >>> Thanks, >>> Severin > From shade at redhat.com Tue Aug 27 16:57:30 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 27 Aug 2019 18:57:30 +0200 Subject: RFR (XS) 8230215: MacOS debug build is broken after JDK-8230003 In-Reply-To: <4c95db67-17ad-ab67-7d47-e4419b10a5f6@redhat.com> References: <4c95db67-17ad-ab67-7d47-e4419b10a5f6@redhat.com> Message-ID: <51a1c7a7-34c0-e8b9-115f-97333ca8a7fe@redhat.com> Thanks, pushed. -Aleksey On 8/27/19 4:53 PM, Zhengyu Gu wrote: > Looks good to me. > > Thanks, > > -Zhengyu > > > On 8/27/19 6:45 AM, Aleksey Shipilev wrote: >> Bug: >> ?? https://bugs.openjdk.java.net/browse/JDK-8230215 >> >> I do this fix blindly, because my MacOS environments actually build jdk/jdk fine. I would appreciate >> if anyone who has MacOS env currently broken would confirm it fixes the breakage. >> >> Fix: >> ?? https://cr.openjdk.java.net/~shade/8230215/webrev.01/ >> >> Testing: Linux x86_64 build, MacOS x86_64 build >> From kim.barrett at oracle.com Tue Aug 27 17:13:27 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 27 Aug 2019 13:13:27 -0400 Subject: RFR (XS) 8230118: 32-bit build failures after JDK-8227054 In-Reply-To: <4dee1825-f0e0-9bfc-d509-29717e05ee67@redhat.com> References: <4dee1825-f0e0-9bfc-d509-29717e05ee67@redhat.com> Message-ID: > On Aug 26, 2019, at 3:43 AM, Aleksey Shipilev wrote: > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8230118 > > I believe we should just use pointer_delta: > http://cr.openjdk.java.net/~shade/8230118/webrev.01/ > > Testing: build, tier1 {x86_32, x86_64} > > -- > Thanks, > -Aleksey Looks good. I wonder why this doesn?t show up on other platforms? I just verified that -Wsign-compare is used when building that file on linux-x64; no idea why that expression isn?t tripping it there. From mikhailo.seledtsov at oracle.com Tue Aug 27 17:15:29 2019 From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov) Date: Tue, 27 Aug 2019 10:15:29 -0700 Subject: RFR [XS] : 8229182: runtime/containers/docker/TestMemoryAwareness.java test fails on SLES12 In-Reply-To: References: <9187885973675ab53221ad3140e79e0115e509a2.camel@redhat.com> <1F1258AE-747D-4024-945A-6380ECC5EB9A@oracle.com> <2F25EFBB-363C-491C-B06A-9CDD8C4011BE@oracle.com> <55A6F5EE-7212-4EDC-A0DE-B644BBC1E3A6@oracle.com> <73ff0c1940648800b27e02fc1c4575a780be2792.camel@redhat.com> <6281a0bca33bd34981063969bfd2415cdc41729e.camel@redhat.com> Message-ID: <5D656531.6080204@oracle.com> I agree with Bob. It seems this is exactly what we wish in this case: filter out/eliminate some options that interfere with the test, while retaining other options and passing them to the JVM running inside a container. Thank you, Misha On 8/27/19, 8:42 AM, Bob Vandette wrote: > This is an isolated problem and I don?t like the idea of adding a new option just for this case. > > What if we parse the options and eliminated the general -Xmx option if one was specified > by the test? After all, this is the intention of adding a test specific heap limit. > > Bob. > > > >> On Aug 27, 2019, at 10:33 AM, Severin Gehwolf wrote: >> >> On Tue, 2019-08-27 at 14:20 +0000, Baesken, Matthias wrote: >>> Hello , my suggestions was " appendJavaOpts " : >>> >> OK, got it now. Looking at the webrev this wasn't clear as it didn't do >> that. >> >>> In case we want to be safe, I suggest to >>> add an additional method " appendJavaOpts " >>> >>> opts.appendJavaOpts("-Xmx" + javaHeapSize); >>> >>> to DockerRunOptions ; appendJavaOpts would append the >>> options after the testJavaOpts (so Xmx can be overwritten ). >>> >>> But if overrideJavaOpts is preferred that fine with me too ... >> I'd prefer a more telling name than "append". I'd ask myself when >> trying to use it: Does it append to regular java options? How is it >> different from addJavaOpts()? You get the idea. I'd prefer >> overrideJavaOpts for that reason. >> >> Perhaps addOverrideOpts()? Either way, the javadoc should make it clear >> what adding options there means. >> >> Thanks, >> Severin >> >>> Best regards, Matthias >>> >>> >>>> On Tue, 2019-08-27 at 13:49 +0000, Baesken, Matthias wrote: >>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8229182.3/ >>>> OK, so, in summary, the constraints are as follows: >>>> >>>> * We don't want to turn of appending global test java options as >>>> these >>>> could possibly contain local options to a specific test >>>> environment. >>>> It would be a surprise if docker tests wouldn't have them. >>>> * Just setting Java options is not enough as the intention is to >>>> set >>>> them for the Docker test, but could potentially be overridden by >>>> global test options (this issue). >>>> >>>> Given we'd like to keep that general design, maybe it would make >>>> sense >>>> to create a 3'rd, separate set of flags, neither java options nor >>>> test >>>> options would manage to override. Call it "overrideJavaOpts" or >>>> some >>>> such. At least that would make it clear that these options if set >>>> have >>>> the final say. >>>> >>>> Thoughts? >>>> >>>> Thanks, >>>> Severin From mikhailo.seledtsov at oracle.com Tue Aug 27 17:20:02 2019 From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov) Date: Tue, 27 Aug 2019 10:20:02 -0700 Subject: RFR: [XS] 8229284: [TESTBUG] jdk/internal/platform/cgroup/TestCgroupMetrics.java fails for - memory:getMemoryUsage In-Reply-To: References: Message-ID: <5D656641.6090708@oracle.com> Looks reasonable to me, Thank you, Misha On 8/15/19, 9:08 AM, Baesken, Matthias wrote: > Hello, please review this small test adjustment . > > We sometimes see failures in the jtreg test jdk/internal/platform/cgroup/TestCgroupMetrics.java . > Failures look like : > > java.lang.RuntimeException: Test failed for - memory:getMemoryUsage, expected [56019386368], got [56200986624] > at jdk.test.lib.containers.cgroup.MetricsTester.fail(MetricsTester.java:207) > at jdk.test.lib.containers.cgroup.MetricsTester.testMemoryUsage(MetricsTester.java:597) > at TestCgroupMetrics.main(TestCgroupMetrics.java:53) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:567) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.base/java.lang.Thread.run(Thread.java:830) > > > Looking at the coding in MetricsTester.java we expect that "memory.usage_in_bytes" gets larger after one additional allocation of 64 M. > However this is sometimes not the case. > > Reason might be that a GC kicked in and freed space; or for some reasons OS pages were freed. > > So I make the test more robust and do some allocations in a loop, breaking out of the loop after new values got larger than initial ones . > > > Thanks, Matthias > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8229284 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8229284.3/ > > From kim.barrett at oracle.com Tue Aug 27 18:04:54 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 27 Aug 2019 14:04:54 -0400 Subject: RFR: 8230203: Replace markWord enums with uintptr_t constants In-Reply-To: <1c706a0b-4be8-9255-74dc-83a0311b4023@oracle.com> References: <1c706a0b-4be8-9255-74dc-83a0311b4023@oracle.com> Message-ID: <3D0A760F-1D21-48D6-8903-B4363A4A3404@oracle.com> > On Aug 27, 2019, at 3:32 AM, Stefan Karlsson wrote: > > Hi all, > > Please review this patch to convert the enum constants in markWord into static const unintptr_t constants. > > http://cr.openjdk.java.net/~stefank/8230203/webrev.01/ > https://bugs.openjdk.java.net/browse/JDK-8230203 > > This is a follow-up RFE from the review of JDK-8229258, where a number of unnecessary casts were pointed out. > > There was also a recent bug in this area, JDK-8221725, where Thomas points out the problem of relying on the bit width of the enum values. > > This patch: > 1) changes all constants to have the same type as the markWord::_value field. > 2) Removes unnecessary uintptr_t casts > 3) Removes uintx casts, because they are typedefed to be uintptr_t > 4) Adds explicit casts to (int) when values are negated. > 5) Try to only use uintptr_t inside markWord. > 6) Leaves the use of intptr_t for parameters and return types of the different hash functions. > > Tested with tier1-3 > > Thanks, > StefanK ------------------------------------------------------------------------------ src/hotspot/share/oops/markWord.hpp 134 static const uintptr_t age_bits = 4; ... and 144 static const uintptr_t lock_shift = 0; ... The bit counts and shift counts are used as rhs in shift expressions and such. I think they should be int or uint rather than uintptr_t. ------------------------------------------------------------------------------ src/hotspot/share/oops/markWord.hpp 334 assert((uintptr_t)age <= max_age, "age too large"); I think the cast here is unnecessary and not really helpful. Unfortunately, the cast in the immediately following line: 335 assert((uintptr_t)bias_epoch <= max_bias_epoch, "bias epoch too large"); probably is needed to avoid -Wsign-compare warnings. (Though JDK-8230118 suggests we might not be getting -Wsign-compare warnings when one might think we ought.) ------------------------------------------------------------------------------ src/hotspot/share/oops/markWord.hpp 409 assert((size & ~size_mask) == 0, "shouldn't overflow size field"); 410 return markWord((cms_free_prototype().value() & ~size_mask_in_place) | 411 ((size & size_mask) << size_shift)); I wonder why 411 is applying size_mask after the 409 assert? ------------------------------------------------------------------------------ I think there were 3 casts to int added: src/hotspot/share/opto/macro.cpp 2229 (~(int)markWord::age_mask_in_place), 0); src/hotspot/cpu/ppc/macroAssembler_ppc.cpp 3003 addi(current_header, current_header, -(int)markWord::monitor_value); // monitor src/hotspot/cpu/aarch64/aarch64.ad 3619 __ add(tmp, tmp, -(int)markWord::monitor_value); // monitor Consider preceeding these with STATIC_ASSERTs that the value being cast is <= INT_MAX. ------------------------------------------------------------------------------ From shade at redhat.com Tue Aug 27 18:08:46 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 27 Aug 2019 20:08:46 +0200 Subject: RFR (XS) 8230118: 32-bit build failures after JDK-8227054 In-Reply-To: References: <4dee1825-f0e0-9bfc-d509-29717e05ee67@redhat.com> Message-ID: <91f7f534-aa63-9c84-ebef-0bf8803affb3@redhat.com> On 8/27/19 7:13 PM, Kim Barrett wrote: > Looks good. Thanks, pushed. > I wonder why this doesn?t show up on other platforms? I just verified that -Wsign-compare > is used when building that file on linux-x64; no idea why that expression isn?t tripping it there. Have no idea. -- Thanks, -Aleksey From stefan.karlsson at oracle.com Tue Aug 27 20:06:51 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 27 Aug 2019 22:06:51 +0200 Subject: RFR: 8230203: Replace markWord enums with uintptr_t constants In-Reply-To: <3D0A760F-1D21-48D6-8903-B4363A4A3404@oracle.com> References: <1c706a0b-4be8-9255-74dc-83a0311b4023@oracle.com> <3D0A760F-1D21-48D6-8903-B4363A4A3404@oracle.com> Message-ID: Hi Kim, I think your comments makes sense. I have an updated webrev that changes some of the types: ?https://cr.openjdk.java.net/~stefank/8230203/webrev.02.delta/ ?https://cr.openjdk.java.net/~stefank/8230203/webrev.02/ The new patch compiles on Linux x64 and not yet tested. I'll run it through testing if you think this is the right change. Thanks, StefanK On 2019-08-27 20:04, Kim Barrett wrote: >> On Aug 27, 2019, at 3:32 AM, Stefan Karlsson wrote: >> >> Hi all, >> >> Please review this patch to convert the enum constants in markWord into static const unintptr_t constants. >> >> http://cr.openjdk.java.net/~stefank/8230203/webrev.01/ >> https://bugs.openjdk.java.net/browse/JDK-8230203 >> >> This is a follow-up RFE from the review of JDK-8229258, where a number of unnecessary casts were pointed out. >> >> There was also a recent bug in this area, JDK-8221725, where Thomas points out the problem of relying on the bit width of the enum values. >> >> This patch: >> 1) changes all constants to have the same type as the markWord::_value field. >> 2) Removes unnecessary uintptr_t casts >> 3) Removes uintx casts, because they are typedefed to be uintptr_t >> 4) Adds explicit casts to (int) when values are negated. >> 5) Try to only use uintptr_t inside markWord. >> 6) Leaves the use of intptr_t for parameters and return types of the different hash functions. >> >> Tested with tier1-3 >> >> Thanks, >> StefanK > > ------------------------------------------------------------------------------ > src/hotspot/share/oops/markWord.hpp > 134 static const uintptr_t age_bits = 4; > ... > > and > 144 static const uintptr_t lock_shift = 0; > ... > > The bit counts and shift counts are used as rhs in shift expressions > and such. I think they should be int or uint rather than uintptr_t. > > ------------------------------------------------------------------------------ > src/hotspot/share/oops/markWord.hpp > 334 assert((uintptr_t)age <= max_age, "age too large"); > > I think the cast here is unnecessary and not really helpful. > > Unfortunately, the cast in the immediately following line: > 335 assert((uintptr_t)bias_epoch <= max_bias_epoch, "bias epoch too large"); > > probably is needed to avoid -Wsign-compare warnings. (Though > JDK-8230118 suggests we might not be getting -Wsign-compare warnings > when one might think we ought.) > > ------------------------------------------------------------------------------ > src/hotspot/share/oops/markWord.hpp > 409 assert((size & ~size_mask) == 0, "shouldn't overflow size field"); > 410 return markWord((cms_free_prototype().value() & ~size_mask_in_place) | > 411 ((size & size_mask) << size_shift)); > > I wonder why 411 is applying size_mask after the 409 assert? > > ------------------------------------------------------------------------------ > I think there were 3 casts to int added: > > src/hotspot/share/opto/macro.cpp > 2229 (~(int)markWord::age_mask_in_place), 0); > > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp > 3003 addi(current_header, current_header, -(int)markWord::monitor_value); // monitor > > src/hotspot/cpu/aarch64/aarch64.ad > 3619 __ add(tmp, tmp, -(int)markWord::monitor_value); // monitor > > Consider preceeding these with STATIC_ASSERTs that the value being > cast is <= INT_MAX. > > ------------------------------------------------------------------------------ > From stefan.karlsson at oracle.com Tue Aug 27 20:21:05 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 27 Aug 2019 22:21:05 +0200 Subject: RFR: 8230203: Replace markWord enums with uintptr_t constants In-Reply-To: References: <1c706a0b-4be8-9255-74dc-83a0311b4023@oracle.com> Message-ID: <9dcf7864-8a56-c676-7ff6-593474c74c5b@oracle.com> On 2019-08-27 16:37, Doerr, Martin wrote: > Hi Stefan, > >>> I think it would be better to use C++ 2011 Strongly-typed Enums. >> Could you elaborate why it would be better to use them in this case? > IMHO enums are better to read and edit. I don't like "static const uintptr_t" replicated 100 times. OK. Point taken. > In addition, static consts usually spam the binaries with stuff which is never needed while enums are only for the compiler. I thought that wasn't a problem unless you, for example, tried to take/use the address of the constant. Are you so opposed to this change that you think we should not do it? I'd also like to hear feedback regarding this from other reviewers. Thanks, StefanK > > I don't understand what keeps us from targeting JEP 347 to jdk14. > > Best regards, > Martin > > >> -----Original Message----- >> From: Stefan Karlsson >> Sent: Dienstag, 27. August 2019 13:08 >> To: Doerr, Martin ; David Holmes >> ; hotspot-dev > dev at openjdk.java.net>; Kim Barrett >> Subject: Re: RFR: 8230203: Replace markWord enums with uintptr_t >> constants >> >> Hi Martin, >> >> On 2019-08-27 10:22, Doerr, Martin wrote: >>> Hi, >>> >>> I think it would be better to use C++ 2011 Strongly-typed Enums. >> Could you elaborate why it would be better to use them in this case? >> >> AFAICT these enums where only enums because that used to be the way >> constants were written in HotSpot. There are some comments around this in: >> https://bugs.openjdk.java.net/browse/JDK-8153116 >> >> Can we still not use them? >>> AFAIK all compilers which are used for jdk/jdk support that. >> I don't think we can go there until we get: >> https://openjdk.java.net/jeps/347 - JEP 347: Adopt C++14 Language >> Features in HotSpot >> >> Thanks, >> StefanK >> >>> Best regards, >>> Martin >>> >>> >>>> -----Original Message----- >>>> From: hotspot-dev On Behalf >> Of >>>> David Holmes >>>> Sent: Dienstag, 27. August 2019 10:02 >>>> To: Stefan Karlsson ; hotspot-dev >> >>> dev at openjdk.java.net> >>>> Subject: Re: RFR: 8230203: Replace markWord enums with uintptr_t >>>> constants >>>> >>>> Hi Stefan, >>>> >>>> On 27/08/2019 5:32 pm, Stefan Karlsson wrote: >>>>> Hi all, >>>>> >>>>> Please review this patch to convert the enum constants in markWord >> into >>>>> static const unintptr_t constants. >>>>> >>>>> http://cr.openjdk.java.net/~stefank/8230203/webrev.01/ >>>>> https://bugs.openjdk.java.net/browse/JDK-8230203 >>>> Overall this seems like a good cleanup, but the introduced "int" casts >>>> now jump out at me. In: >>>> >>>> src/hotspot/cpu/aarch64/aarch64.ad >>>> src/hotspot/cpu/arm/macroAssembler_arm.cpp >>>> src/hotspot/cpu/ppc/macroAssembler_ppc.cpp >>>> >>>> it would seem to me that all the "add -(int)markWord::monitor_value" >>>> would be cleaner/clearer as: "sub markWord::monitor_value". But that is >>>> a bit out of scope for your change - it just jumped out at me. I expect >>>> add is more efficient than sub. >>>> >>>> In src/hotspot/share/opto/macro.cpp I don't understand why this int >>>> cast is needed: >>>> >>>> Node* not_biased_ctrl = opt_bits_test(ctrl, region, 3, x_node, >>>> ! >>>> (~(int)markWord::age_mask_in_place), 0); >>>> >>>> I'm unclear if this is really >>>> >>>> ~(int)markWord::age_mask_in_place >>>> >>>> or >>>> >>>> (int)(~markWord::age_mask_in_place) >>>> >>>> ? If the latter then okay. If the former then I don't grok it. :) >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> This is a follow-up RFE from the review of JDK-8229258, where a number >>>>> of unnecessary casts were pointed out. >>>>> >>>>> There was also a recent bug in this area, JDK-8221725, where Thomas >>>>> points out the problem of relying on the bit width of the enum values. >>>>> >>>>> This patch: >>>>> 1) changes all constants to have the same type as the markWord::_value >>>>> field. >>>>> 2) Removes unnecessary uintptr_t casts >>>>> 3) Removes uintx casts, because they are typedefed to be uintptr_t >>>>> 4) Adds explicit casts to (int) when values are negated. >>>>> 5) Try to only use uintptr_t inside markWord. >>>>> 6) Leaves the use of intptr_t for parameters and return types of the >>>>> different hash functions. >>>>> >>>>> Tested with tier1-3 >>>>> >>>>> Thanks, >>>>> StefanK From erik.osterlund at oracle.com Tue Aug 27 20:41:34 2019 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Tue, 27 Aug 2019 22:41:34 +0200 Subject: RFR: 8230203: Replace markWord enums with uintptr_t constants In-Reply-To: <9dcf7864-8a56-c676-7ff6-593474c74c5b@oracle.com> References: <1c706a0b-4be8-9255-74dc-83a0311b4023@oracle.com> <9dcf7864-8a56-c676-7ff6-593474c74c5b@oracle.com> Message-ID: <9F8574F2-CD77-4390-B992-950152C99DCD@oracle.com> Hi, >> On 27 Aug 2019, at 22:21, Stefan Karlsson wrote: >> >> On 2019-08-27 16:37, Doerr, Martin wrote: >> Hi Stefan, >> >>>> I think it would be better to use C++ 2011 Strongly-typed Enums. >>> Could you elaborate why it would be better to use them in this case? >> IMHO enums are better to read and edit. I don't like "static const uintptr_t" replicated 100 times. > > OK. Point taken. > >> In addition, static consts usually spam the binaries with stuff which is never needed while enums are only for the compiler. > > I thought that wasn't a problem unless you, for example, tried to take/use the address of the constant. According to the C++03 standard, storage for static consts must be allocated always. But AFAIK, no compiler actually does that unless it is ODR-used. Subsequent standard updates removed that annoying statement, and changed it to basically say only ODR-used constants need storage. So I think in practice we get the wanted behaviour already, and after C++14, that will also be well specified, withot requiring us to change any code. > Are you so opposed to this change that you think we should not do it? I'd also like to hear feedback regarding this from other reviewers. I think going ahead with your suggested changes is fine. Thanks, /Erik > Thanks, > StefanK >> >> I don't understand what keeps us from targeting JEP 347 to jdk14. >> >> Best regards, >> Martin >> >> >>> -----Original Message----- >>> From: Stefan Karlsson >>> Sent: Dienstag, 27. August 2019 13:08 >>> To: Doerr, Martin ; David Holmes >>> ; hotspot-dev >> dev at openjdk.java.net>; Kim Barrett >>> Subject: Re: RFR: 8230203: Replace markWord enums with uintptr_t >>> constants >>> >>> Hi Martin, >>> >>>> On 2019-08-27 10:22, Doerr, Martin wrote: >>>> Hi, >>>> >>>> I think it would be better to use C++ 2011 Strongly-typed Enums. >>> Could you elaborate why it would be better to use them in this case? >>> >>> AFAICT these enums where only enums because that used to be the way >>> constants were written in HotSpot. There are some comments around this in: >>> https://bugs.openjdk.java.net/browse/JDK-8153116 >>> >>> Can we still not use them? >>>> AFAIK all compilers which are used for jdk/jdk support that. >>> I don't think we can go there until we get: >>> https://openjdk.java.net/jeps/347 - JEP 347: Adopt C++14 Language >>> Features in HotSpot >>> >>> Thanks, >>> StefanK >>> >>>> Best regards, >>>> Martin >>>> >>>> >>>>> -----Original Message----- >>>>> From: hotspot-dev On Behalf >>> Of >>>>> David Holmes >>>>> Sent: Dienstag, 27. August 2019 10:02 >>>>> To: Stefan Karlsson ; hotspot-dev >>> >>>> dev at openjdk.java.net> >>>>> Subject: Re: RFR: 8230203: Replace markWord enums with uintptr_t >>>>> constants >>>>> >>>>> Hi Stefan, >>>>> >>>>>> On 27/08/2019 5:32 pm, Stefan Karlsson wrote: >>>>>> Hi all, >>>>>> >>>>>> Please review this patch to convert the enum constants in markWord >>> into >>>>>> static const unintptr_t constants. >>>>>> >>>>>> http://cr.openjdk.java.net/~stefank/8230203/webrev.01/ >>>>>> https://bugs.openjdk.java.net/browse/JDK-8230203 >>>>> Overall this seems like a good cleanup, but the introduced "int" casts >>>>> now jump out at me. In: >>>>> >>>>> src/hotspot/cpu/aarch64/aarch64.ad >>>>> src/hotspot/cpu/arm/macroAssembler_arm.cpp >>>>> src/hotspot/cpu/ppc/macroAssembler_ppc.cpp >>>>> >>>>> it would seem to me that all the "add -(int)markWord::monitor_value" >>>>> would be cleaner/clearer as: "sub markWord::monitor_value". But that is >>>>> a bit out of scope for your change - it just jumped out at me. I expect >>>>> add is more efficient than sub. >>>>> >>>>> In src/hotspot/share/opto/macro.cpp I don't understand why this int >>>>> cast is needed: >>>>> >>>>> Node* not_biased_ctrl = opt_bits_test(ctrl, region, 3, x_node, >>>>> ! >>>>> (~(int)markWord::age_mask_in_place), 0); >>>>> >>>>> I'm unclear if this is really >>>>> >>>>> ~(int)markWord::age_mask_in_place >>>>> >>>>> or >>>>> >>>>> (int)(~markWord::age_mask_in_place) >>>>> >>>>> ? If the latter then okay. If the former then I don't grok it. :) >>>>> >>>>> Thanks, >>>>> David >>>>> ----- >>>>> >>>>>> This is a follow-up RFE from the review of JDK-8229258, where a number >>>>>> of unnecessary casts were pointed out. >>>>>> >>>>>> There was also a recent bug in this area, JDK-8221725, where Thomas >>>>>> points out the problem of relying on the bit width of the enum values. >>>>>> >>>>>> This patch: >>>>>> 1) changes all constants to have the same type as the markWord::_value >>>>>> field. >>>>>> 2) Removes unnecessary uintptr_t casts >>>>>> 3) Removes uintx casts, because they are typedefed to be uintptr_t >>>>>> 4) Adds explicit casts to (int) when values are negated. >>>>>> 5) Try to only use uintptr_t inside markWord. >>>>>> 6) Leaves the use of intptr_t for parameters and return types of the >>>>>> different hash functions. >>>>>> >>>>>> Tested with tier1-3 >>>>>> >>>>>> Thanks, >>>>>> StefanK > From mikhailo.seledtsov at oracle.com Tue Aug 27 20:47:25 2019 From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov) Date: Tue, 27 Aug 2019 13:47:25 -0700 Subject: RFR [XS]: 8229370: make jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java more stable In-Reply-To: References: <9f1e22b3-14c9-ecb1-e0b0-d6c19fa02a4e@oracle.com> Message-ID: <5D6596DD.5090602@oracle.com> On 8/27/19, 1:15 AM, Baesken, Matthias wrote: > Hi David, thanks for the info about > > https://bugs.openjdk.java.net/browse/JDK-8228990 > > > regarding your comment in the bug : > >> So it makes no sense. I finally found an example where the test passed and failed on the same machine. > I've seen this too . > > Looks like my change only increased the probability of incidental network traffic happening on the real network interfaces . > > Should we exclude the test, in the current state it might indeed be problematic . > > (otherwise we could make the test pass on Linux when just 1 network interface is found, this might be a legitimate case isn?t it ?) Based on David's analysis in the "JDK-8228990: [TESTBUG] JFR TestNetworkUtilizationEvent.java expects 2+ Network interfaces on Linux but finding 1", my opinion is to remove the check for number of interfaces all together. Or just check that there is 1 interface. Misha > > > Best regards, Matthias > > > >> -----Original Message----- >> From: David Holmes >> Sent: Dienstag, 27. August 2019 09:56 >> To: Baesken, Matthias; 'hotspot- >> dev at openjdk.java.net'; hotspot-jfr- >> dev at openjdk.java.net >> Subject: Re: RFR [XS]: 8229370: make >> jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java more stable >> >> Hi Matthias, >> >> On 27/08/2019 5:41 pm, Baesken, Matthias wrote: >>> Hello, any reviews for this small change ? >> I missed the initial request - sorry. >> >> Seems we have a double up of effort here as we also have JDK-8228990 for >> the exact same problem that we see on some of our test machines. >> >> Our analysis suggests that this test often passes by accident due to >> incidental activity on the real network interface when the logic >> intended to generate that activity (the packet sent to 10.0.0.0:12345) >> actually had no affect (unreachable address). If there is no incidental >> network activity then the real network interface is not seen and so the >> test fails. >> >> David >> >>> Thanks , Matthias >>> >>> From: Baesken, Matthias >>> Sent: Montag, 12. August 2019 14:33 >>> To: 'hotspot-dev at openjdk.java.net'; >> 'hotspot-jfr-dev at openjdk.java.net' >>> Subject: RFR [XS]: 8229370: make >> jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java more stable >>> Hello, please review this small test enhancement. >>> >>> We noticed that on some of our Linux machines (SLES12 based) the >> TestNetworkUtilizationEvent.java test reported just 1 interface >>> (the test TestNetworkUtilizationEvent.java expects more than 1 on Linux). >>> >>> Looking into the HS code , os_perf_linux.cpp collects the interfaces + >> additional information about bytes read/written (by looking at >> /sys/class/net/eth/statistics/ ) >>> and this info is given to JFR . >>> >>> However it seems to need (at least on some machines / setups) more >> packet send operations / potential retries to really get counter updates >> (and without updates in the counters, no interfaces are found). >>> So I adjusted the test accordingly. >>> >>> >>> Bug/webrev : >>> >>> https://bugs.openjdk.java.net/browse/JDK-8229370 >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8229370.0/ >>> >>> >>> Best regards, Matthias >>> From kim.barrett at oracle.com Tue Aug 27 20:51:45 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 27 Aug 2019 16:51:45 -0400 Subject: RFR: 8230203: Replace markWord enums with uintptr_t constants In-Reply-To: References: <1c706a0b-4be8-9255-74dc-83a0311b4023@oracle.com> <3D0A760F-1D21-48D6-8903-B4363A4A3404@oracle.com> Message-ID: > On Aug 27, 2019, at 4:06 PM, Stefan Karlsson wrote: > > Hi Kim, > > I think your comments makes sense. I have an updated webrev that changes some of the types: > > https://cr.openjdk.java.net/~stefank/8230203/webrev.02.delta/ > https://cr.openjdk.java.net/~stefank/8230203/webrev.02/ > > The new patch compiles on Linux x64 and not yet tested. I'll run it through testing if you think this is the right change. This looks good to me. From mikhailo.seledtsov at oracle.com Tue Aug 27 20:54:35 2019 From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov) Date: Tue, 27 Aug 2019 13:54:35 -0700 Subject: RFR [XS] : 8229182: runtime/containers/docker/TestMemoryAwareness.java test fails on SLES12 In-Reply-To: <5D656531.6080204@oracle.com> References: <9187885973675ab53221ad3140e79e0115e509a2.camel@redhat.com> <1F1258AE-747D-4024-945A-6380ECC5EB9A@oracle.com> <2F25EFBB-363C-491C-B06A-9CDD8C4011BE@oracle.com> <55A6F5EE-7212-4EDC-A0DE-B644BBC1E3A6@oracle.com> <73ff0c1940648800b27e02fc1c4575a780be2792.camel@redhat.com> <6281a0bca33bd34981063969bfd2415cdc41729e.camel@redhat.com> <5D656531.6080204@oracle.com> Message-ID: <5D65988B.5040807@oracle.com> FYI: you could use jdk.test.lib.Utils.getFilteredTestJavaOpts(String... filters) for this purpose. On 8/27/19, 10:15 AM, Mikhailo Seledtsov wrote: > I agree with Bob. It seems this is exactly what we wish in this case: > filter out/eliminate some options that interfere with the test, while > retaining other options and passing them to the JVM running inside a > container. > > > Thank you, > Misha > > On 8/27/19, 8:42 AM, Bob Vandette wrote: >> This is an isolated problem and I don?t like the idea of adding a new >> option just for this case. >> >> What if we parse the options and eliminated the general -Xmx option >> if one was specified >> by the test? After all, this is the intention of adding a test >> specific heap limit. >> >> Bob. >> >> >> >>> On Aug 27, 2019, at 10:33 AM, Severin Gehwolf >>> wrote: >>> >>> On Tue, 2019-08-27 at 14:20 +0000, Baesken, Matthias wrote: >>>> Hello , my suggestions was " appendJavaOpts " : >>>> >>> OK, got it now. Looking at the webrev this wasn't clear as it didn't do >>> that. >>> >>>> In case we want to be safe, I suggest to >>>> add an additional method " appendJavaOpts " >>>> >>>> opts.appendJavaOpts("-Xmx" + javaHeapSize); >>>> >>>> to DockerRunOptions ; appendJavaOpts would append the >>>> options after the testJavaOpts (so Xmx can be overwritten ). >>>> >>>> But if overrideJavaOpts is preferred that fine with me too ... >>> I'd prefer a more telling name than "append". I'd ask myself when >>> trying to use it: Does it append to regular java options? How is it >>> different from addJavaOpts()? You get the idea. I'd prefer >>> overrideJavaOpts for that reason. >>> >>> Perhaps addOverrideOpts()? Either way, the javadoc should make it clear >>> what adding options there means. >>> >>> Thanks, >>> Severin >>> >>>> Best regards, Matthias >>>> >>>> >>>>> On Tue, 2019-08-27 at 13:49 +0000, Baesken, Matthias wrote: >>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8229182.3/ >>>>> OK, so, in summary, the constraints are as follows: >>>>> >>>>> * We don't want to turn of appending global test java options as >>>>> these >>>>> could possibly contain local options to a specific test >>>>> environment. >>>>> It would be a surprise if docker tests wouldn't have them. >>>>> * Just setting Java options is not enough as the intention is to >>>>> set >>>>> them for the Docker test, but could potentially be overridden by >>>>> global test options (this issue). >>>>> >>>>> Given we'd like to keep that general design, maybe it would make >>>>> sense >>>>> to create a 3'rd, separate set of flags, neither java options nor >>>>> test >>>>> options would manage to override. Call it "overrideJavaOpts" or >>>>> some >>>>> such. At least that would make it clear that these options if set >>>>> have >>>>> the final say. >>>>> >>>>> Thoughts? >>>>> >>>>> Thanks, >>>>> Severin From kim.barrett at oracle.com Tue Aug 27 21:04:29 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 27 Aug 2019 17:04:29 -0400 Subject: RFR: 8230203: Replace markWord enums with uintptr_t constants In-Reply-To: References: <1c706a0b-4be8-9255-74dc-83a0311b4023@oracle.com> Message-ID: <6DEEBC19-7E2E-4DF7-80A6-0C2D1794C4F6@oracle.com> > On Aug 27, 2019, at 10:37 AM, Doerr, Martin wrote: > > Hi Stefan, > >>> I think it would be better to use C++ 2011 Strongly-typed Enums. >> >> Could you elaborate why it would be better to use them in this case? > > IMHO enums are better to read and edit. I don't like "static const uintptr_t" replicated 100 times. Strongly-typed enums (aka enum classes) are not the right thing here. What I think you want is C++11 explicitly typed enums, e.g. ?enum : uintptr_t { ? };? I agree there?s a lot less boilerplate with that. But I like all the cast removals coming out of this change, and would rather not wait for those. > In addition, static consts usually spam the binaries with stuff which is never needed while enums are only for the compiler. The C++11/14 changes to the ODR-used rules solve that. gcc (at least) has implemented effectively that for a long time. Under the new rules one doesn?t need a definition (with no initializer) of such constants in some translation unit unless the name is ODR-used, and an lvalue-to-rvalue converted use no longer counts as an ODR-use. > I don't understand what keeps us from targeting JEP 347 to jdk14. There are still some issues with Solaris Studio. Potential issues with other (more obscure) platforms. From david.holmes at oracle.com Wed Aug 28 01:14:51 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 28 Aug 2019 11:14:51 +1000 Subject: RFR [XS]: 8229370: make jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java more stable In-Reply-To: <5D6596DD.5090602@oracle.com> References: <9f1e22b3-14c9-ecb1-e0b0-d6c19fa02a4e@oracle.com> <5D6596DD.5090602@oracle.com> Message-ID: <0a87d9fc-f7cf-26e1-cf1c-1914eec68fc3@oracle.com> On 28/08/2019 6:47 am, Mikhailo Seledtsov wrote: > On 8/27/19, 1:15 AM, Baesken, Matthias wrote: >> Hi? David,?? thanks for? the info about >> >> https://bugs.openjdk.java.net/browse/JDK-8228990 >> >> >> regarding your comment in the bug : >> >>> So it makes no sense. I finally found an example where the test >>> passed and failed on the same machine. >> I've seen this too . >> >> Looks like? my change? only? increased? the probability of? incidental >> network traffic happening? on the real network interfaces . >> >> Should we exclude the test,? in the current state it might indeed be >> problematic . >> >> (otherwise we could make the test pass? on Linux? when just 1 network >> interface is found,? this might be a legitimate case isn?t it ?) > Based on David's analysis in the "JDK-8228990: [TESTBUG] JFR > TestNetworkUtilizationEvent.java expects 2+ Network interfaces on Linux > but finding 1", my opinion is to remove the check for number of > interfaces all together. Or just check that there is 1 interface. The test expects there to be two interfaces always present: the loopback interface and a real network interface. There could be additional ones. The problem is that the test fails to generate traffic on the real network interface due to the use of 10.0.0.0:12345. I have no idea why someone thought sending a packet to that address would necessarily cause the kind of traffic that would show up in the JFR event. Are we really likely to be running this test on a machine without a real network interface or the loopback interface? The former seems very unlikely. The latter may be something configurable but it seems very unlikely to me that anyone would configure a test system that way. So I don't think the "expected number of interfaces" is the issue. The issue is generating observable traffic on the real network interface - at least that is what we see in our test failures (the output for the "lo" interface is always present). So it should be as simple as changing 10.0.0.0:12345 into something guaranteed to work? I think this needs to be looked at by the JFR folk and net-dev folk to come up with a valid testing scenario. Cheers, David > Misha >> >> >> Best regards, Matthias >> >> >> >>> -----Original Message----- >>> From: David Holmes >>> Sent: Dienstag, 27. August 2019 09:56 >>> To: Baesken, Matthias; 'hotspot- >>> dev at openjdk.java.net'; hotspot-jfr- >>> dev at openjdk.java.net >>> Subject: Re: RFR [XS]: 8229370: make >>> jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java more stable >>> >>> Hi Matthias, >>> >>> On 27/08/2019 5:41 pm, Baesken, Matthias wrote: >>>> Hello, any reviews for this small change ? >>> I missed the initial request - sorry. >>> >>> Seems we have a double up of effort here as we also have JDK-8228990 for >>> the exact same problem that we see on some of our test machines. >>> >>> Our analysis suggests that this test often passes by accident due to >>> incidental activity on the real network interface when the logic >>> intended to generate that activity (the packet sent to 10.0.0.0:12345) >>> actually had no affect (unreachable address). If there is no incidental >>> network activity then the real network interface is not seen and so the >>> test fails. >>> >>> David >>> >>>> Thanks , Matthias >>>> >>>> From: Baesken, Matthias >>>> Sent: Montag, 12. August 2019 14:33 >>>> To: 'hotspot-dev at openjdk.java.net'; >>> 'hotspot-jfr-dev at openjdk.java.net' >>>> Subject: RFR [XS]: 8229370: make >>> jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java more stable >>>> Hello, please review this small test enhancement. >>>> >>>> We noticed that on some of our Linux machines? (SLES12 based)?? the >>> TestNetworkUtilizationEvent.java test reported just 1 interface >>>> (the test? TestNetworkUtilizationEvent.java? expects more than 1 on >>>> Linux). >>>> >>>> Looking into the HS code , os_perf_linux.cpp collects the interfaces + >>> additional information about bytes read/written? (by looking at >>> /sys/class/net/eth/statistics/?? ) >>>> and this info is given to JFR . >>>> >>>> However it seems to need (at least on some machines / setups) more >>> packet send operations / potential? retries to really? get counter >>> updates >>> (and without updates in the counters,?? no interfaces are found). >>>> So I adjusted the test accordingly. >>>> >>>> >>>> Bug/webrev : >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8229370 >>>> >>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8229370.0/ >>>> >>>> >>>> Best regards, Matthias >>>> From david.holmes at oracle.com Wed Aug 28 02:05:10 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 28 Aug 2019 12:05:10 +1000 Subject: RFR: 8230203: Replace markWord enums with uintptr_t constants In-Reply-To: References: <1c706a0b-4be8-9255-74dc-83a0311b4023@oracle.com> <3D0A760F-1D21-48D6-8903-B4363A4A3404@oracle.com> Message-ID: <8eaa5a80-c897-8af8-4610-df41815cd02b@oracle.com> Hi Stefan, On 28/08/2019 6:06 am, Stefan Karlsson wrote: > Hi Kim, > > I think your comments makes sense. I have an updated webrev that changes > some of the types: > > ?https://cr.openjdk.java.net/~stefank/8230203/webrev.02.delta/ > ?https://cr.openjdk.java.net/~stefank/8230203/webrev.02/ I agree that is much clearer now. "bits" and "shifts" are just numbers. masks and comparison-constants should be the same type as the variable(s) they will be applied to. In markWord.hpp: 334 assert(age <= max_age, "age too large"); This assert is a tautology as age and max_age are the same uint type. (I expect some compilers may point this out.) Thanks, David ----- > The new patch compiles on Linux x64 and not yet tested. I'll run it > through testing if you think this is the right change. > > Thanks, > StefanK > > On 2019-08-27 20:04, Kim Barrett wrote: >>> On Aug 27, 2019, at 3:32 AM, Stefan Karlsson >>> wrote: >>> >>> Hi all, >>> >>> Please review this patch to convert the enum constants in markWord >>> into static const unintptr_t constants. >>> >>> http://cr.openjdk.java.net/~stefank/8230203/webrev.01/ >>> https://bugs.openjdk.java.net/browse/JDK-8230203 >>> >>> This is a follow-up RFE from the review of JDK-8229258, where a >>> number of unnecessary casts were pointed out. >>> >>> There was also a recent bug in this area, JDK-8221725, where Thomas >>> points out the problem of relying on the bit width of the enum values. >>> >>> This patch: >>> 1) changes all constants to have the same type as the >>> markWord::_value field. >>> 2) Removes unnecessary uintptr_t casts >>> 3) Removes uintx casts, because they are typedefed to be uintptr_t >>> 4) Adds explicit casts to (int) when values are negated. >>> 5) Try to only use uintptr_t inside markWord. >>> 6) Leaves the use of intptr_t for parameters and return types of the >>> different hash functions. >>> >>> Tested with tier1-3 >>> >>> Thanks, >>> StefanK >> >> ------------------------------------------------------------------------------ >> >> src/hotspot/share/oops/markWord.hpp >> ? 134?? static const uintptr_t age_bits???????????????? = 4; >> ... >> >> and >> ? 144?? static const uintptr_t lock_shift?????????????? = 0; >> ... >> >> The bit counts and shift counts are used as rhs in shift expressions >> and such.? I think they should be int or uint rather than uintptr_t. >> >> ------------------------------------------------------------------------------ >> >> src/hotspot/share/oops/markWord.hpp >> ? 334???? assert((uintptr_t)age <= max_age, "age too large"); >> >> I think the cast here is unnecessary and not really helpful. >> >> Unfortunately, the cast in the immediately following line: >> ? 335???? assert((uintptr_t)bias_epoch <= max_bias_epoch, "bias epoch >> too large"); >> >> probably is needed to avoid -Wsign-compare warnings.? (Though >> JDK-8230118 suggests we might not be getting -Wsign-compare warnings >> when one might think we ought.) >> >> ------------------------------------------------------------------------------ >> >> src/hotspot/share/oops/markWord.hpp >> ? 409???? assert((size & ~size_mask) == 0, "shouldn't overflow size >> field"); >> ? 410???? return markWord((cms_free_prototype().value() & >> ~size_mask_in_place) | >> ? 411???????????????????? ((size & size_mask) << size_shift)); >> >> I wonder why 411 is applying size_mask after the 409 assert? >> >> ------------------------------------------------------------------------------ >> >> I think there were 3 casts to int added: >> >> src/hotspot/share/opto/macro.cpp >> 2229 >> (~(int)markWord::age_mask_in_place), 0); >> >> src/hotspot/cpu/ppc/macroAssembler_ppc.cpp >> 3003?? addi(current_header, current_header, >> -(int)markWord::monitor_value); // monitor >> >> src/hotspot/cpu/aarch64/aarch64.ad >> 3619???? __ add(tmp, tmp, -(int)markWord::monitor_value); // monitor >> >> Consider preceeding these with STATIC_ASSERTs that the value being >> cast is <= INT_MAX. >> >> ------------------------------------------------------------------------------ >> >> > From david.holmes at oracle.com Wed Aug 28 02:06:53 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 28 Aug 2019 12:06:53 +1000 Subject: RFR: 8230203: Replace markWord enums with uintptr_t constants In-Reply-To: <5203f6b2-bebe-7ebe-cfc2-ff8a4a56149f@oracle.com> References: <1c706a0b-4be8-9255-74dc-83a0311b4023@oracle.com> <78e1fc25-cef0-f626-ef23-5fb33a040576@oracle.com> <215b7869-ff99-9330-a3f4-271c35b479c5@oracle.com> <5203f6b2-bebe-7ebe-cfc2-ff8a4a56149f@oracle.com> Message-ID: On 27/08/2019 10:52 pm, Stefan Karlsson wrote: > On 2019-08-27 13:37, David Holmes wrote: >> On 27/08/2019 9:21 pm, Stefan Karlsson wrote: >>> On 2019-08-27 10:01, David Holmes wrote: >>>> Hi Stefan, >>>> >>>> On 27/08/2019 5:32 pm, Stefan Karlsson wrote: >>>>> Hi all, >>>>> >>>>> Please review this patch to convert the enum constants in markWord >>>>> into static const unintptr_t constants. >>>>> >>>>> http://cr.openjdk.java.net/~stefank/8230203/webrev.01/ >>>>> https://bugs.openjdk.java.net/browse/JDK-8230203 >>>> >>>> Overall this seems like a good cleanup, but the introduced "int" >>>> casts now jump out at me. In: >>>> >>>> ??src/hotspot/cpu/aarch64/aarch64.ad >>>> ??src/hotspot/cpu/arm/macroAssembler_arm.cpp >>>> ??src/hotspot/cpu/ppc/macroAssembler_ppc.cpp >>>> >>>> it would seem to me that all the "add -(int)markWord::monitor_value" >>>> would be cleaner/clearer as: "sub markWord::monitor_value". But that >>>> is a bit out of scope for your change - it just jumped out at me. I >>>> expect add is more efficient than sub. >>>> >>> >>> I agree. >>> >>>> In? src/hotspot/share/opto/macro.cpp I don't understand why this int >>>> cast is needed: >>>> >>>> ?????? Node* not_biased_ctrl =? opt_bits_test(ctrl, region, 3, x_node, >>>> ! (~(int)markWord::age_mask_in_place), 0); >>>> >>>> I'm unclear if this is really >>>> >>>> ~(int)markWord::age_mask_in_place >>>> >>>> or >>>> >>>> (int)(~markWord::age_mask_in_place) >>>> >>>> ? If the latter then okay. If the former then I don't grok it. :) >>> >>> Without casting we get the following error message: >>> src/hotspot/share/opto/macro.cpp:2229:40: error: overflow in >>> conversion from 'uintptr_t' {aka 'long unsigned int'} to 'int' >>> changes value from '18446744073709551495' to '-121' [-Werror=overflow] >>> (~markWord::age_mask_in_place), 0); >>> >>> The parameter type for opt_bits_test is int. So, I used >>> '~(int)markWord::age_mask_in_place' to solve it. The intention was to >>> 'take the small positive 64 bit wide integer, make it into a positive >>> 32 bit wide integer, and then flip the bits'. It felt more intuitive >>> (safer?) to narrow a positive integer than to cast a large positive >>> integer to a smaller negative integer. >>> >>> Does that make sense, or did I miss something? :) >> >> I understand the error message but I'm a little less clear about the >> overall change. Previously the enums were int types and so only 32-bit >> always. > > This is not entirely true. They could be smaller than 32-bit, and could > have been larger than 32-bit if high-order bits were used. But yes, > previously these values were not larger than 32-bit. > > ?But the 32-bit masks were applied to 64-bit values on 64-bit >> systems, so presumably integer promotion came into play in those cases >> as there were no explicit casts. Now the constants are 64-bit on >> 64-bit and 32-bit on 32-bit and they match the size of the field being >> masked, so that is good. But it then leads me to wonder why we are >> passing a 64-bit mask into opt_bits_test when it can only deal with a >> 32-bit mask? Makes me wonder whether something in there isn't also the >> wrong type? > > Maybe someone from the compiler team can comment on this? > > For this specific case we know that the bits will fit inside a 32-bit > sized integer and exploit that fact. Okay - this was really just an aside comment. Thanks, David ----- > > We do similar narrowing inside the markWord class. For example: > > ? uint???? age()?????????? const { return mask_bits(value() >> > age_shift, age_mask); } > > Thanks, > StefanK > >> >> Thanks, >> David >> >>> >>> Thanks, >>> StefanK >>> >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> This is a follow-up RFE from the review of JDK-8229258, where a >>>>> number of unnecessary casts were pointed out. >>>>> >>>>> There was also a recent bug in this area, JDK-8221725, where Thomas >>>>> points out the problem of relying on the bit width of the enum values. >>>>> >>>>> This patch: >>>>> 1) changes all constants to have the same type as the >>>>> markWord::_value field. >>>>> 2) Removes unnecessary uintptr_t casts >>>>> 3) Removes uintx casts, because they are typedefed to be uintptr_t >>>>> 4) Adds explicit casts to (int) when values are negated. >>>>> 5) Try to only use uintptr_t inside markWord. >>>>> 6) Leaves the use of intptr_t for parameters and return types of >>>>> the different hash functions. >>>>> >>>>> Tested with tier1-3 >>>>> >>>>> Thanks, >>>>> StefanK From Xiaohong.Gong at arm.com Wed Aug 28 02:25:18 2019 From: Xiaohong.Gong at arm.com (Xiaohong Gong (Arm Technology China)) Date: Wed, 28 Aug 2019 02:25:18 +0000 Subject: RFR: 8229797: [JVMCI] Clean up no longer used JVMCI::dependencies_invalid value. Message-ID: Hi, Please help to review this jvmci patch: Webrew: http://cr.openjdk.java.net/~pli/rfr/8229797/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8229797 This patch fix issue: https://github.com/oracle/graal/issues/1587. The loading of new classes can cause dependencies to become false, which requires the dependent nmethods to be discarded and deoptimized. So if validating dependencies fails, it should make the result to be JVMCI::dependencies_failed, which makes jvmci throw the BailoutException. The invalid dependencies happen at the time of installation without any intervening modification of the system dictionary. So as the system dictionary modification optimization has been removed, the compiler can not know whether the failed dependencies are triggered by class reloading or not. It's better to use dependencies_failed to mark the result. Thanks, Xiaohong Gong From mikhailo.seledtsov at oracle.com Wed Aug 28 02:53:48 2019 From: mikhailo.seledtsov at oracle.com (mikhailo.seledtsov at oracle.com) Date: Tue, 27 Aug 2019 19:53:48 -0700 Subject: RFR [XS]: 8229370: make jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java more stable In-Reply-To: <0a87d9fc-f7cf-26e1-cf1c-1914eec68fc3@oracle.com> References: <9f1e22b3-14c9-ecb1-e0b0-d6c19fa02a4e@oracle.com> <5D6596DD.5090602@oracle.com> <0a87d9fc-f7cf-26e1-cf1c-1914eec68fc3@oracle.com> Message-ID: On 8/27/19 6:14 PM, David Holmes wrote: > On 28/08/2019 6:47 am, Mikhailo Seledtsov wrote: >> On 8/27/19, 1:15 AM, Baesken, Matthias wrote: >>> Hi? David,?? thanks for? the info about >>> >>> https://bugs.openjdk.java.net/browse/JDK-8228990 >>> >>> >>> regarding your comment in the bug : >>> >>>> So it makes no sense. I finally found an example where the test >>>> passed and failed on the same machine. >>> I've seen this too . >>> >>> Looks like? my change? only? increased? the probability of >>> incidental network traffic happening? on the real network interfaces . >>> >>> Should we exclude the test,? in the current state it might indeed be >>> problematic . >>> >>> (otherwise we could make the test pass? on Linux? when just 1 >>> network interface is found,? this might be a legitimate case isn?t >>> it ?) >> Based on David's analysis in the "JDK-8228990: [TESTBUG] JFR >> TestNetworkUtilizationEvent.java expects 2+ Network interfaces on >> Linux but finding 1", my opinion is to remove the check for number of >> interfaces all together. Or just check that there is 1 interface. > > The test expects there to be two interfaces always present: the > loopback interface and a real network interface. There could be > additional ones. The problem is that the test fails to generate > traffic on the real network interface due to the use of > 10.0.0.0:12345. I have no idea why someone thought sending a packet to > that address would necessarily cause the kind of traffic that would > show up in the JFR event. > > Are we really likely to be running this test on a machine without a > real network interface or the loopback interface? The former seems > very unlikely. The latter may be something configurable but it seems > very unlikely to me that anyone would configure a test system that > way. So I don't think the "expected number of interfaces" is the > issue. The issue is generating observable traffic on the real network > interface - at least that is what we see in our test failures (the > output for the "lo" interface is always present). Thank you for detailed explanation. Sorry, I did not understand this at first. > > So it should be as simple as changing 10.0.0.0:12345 into something > guaranteed to work? > > I think this needs to be looked at by the JFR folk and net-dev folk to > come up with a valid testing scenario. Perhaps, we can problem list the test for now, until we find a good solution. Several options come to mind: ?? - pick a suitable destination address for "real network interface" and test it first; if no traffic is generated after sufficient retries, return jtreg.SkippedException (test skipped), instead of failure ?? - try a range of suitable destination addresses; also have a fallback to jtreg.SkippedException if none of them work ?? - in addition, a suitable address can be passed as a test property; this way test will be configurable for a given infrastructure What do you think? Thank you, Misha > Cheers, > David > >> Misha >>> >>> >>> Best regards, Matthias >>> >>> >>> >>>> -----Original Message----- >>>> From: David Holmes >>>> Sent: Dienstag, 27. August 2019 09:56 >>>> To: Baesken, Matthias; 'hotspot- >>>> dev at openjdk.java.net'; hotspot-jfr- >>>> dev at openjdk.java.net >>>> Subject: Re: RFR [XS]: 8229370: make >>>> jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java more stable >>>> >>>> Hi Matthias, >>>> >>>> On 27/08/2019 5:41 pm, Baesken, Matthias wrote: >>>>> Hello, any reviews for this small change ? >>>> I missed the initial request - sorry. >>>> >>>> Seems we have a double up of effort here as we also have >>>> JDK-8228990 for >>>> the exact same problem that we see on some of our test machines. >>>> >>>> Our analysis suggests that this test often passes by accident due to >>>> incidental activity on the real network interface when the logic >>>> intended to generate that activity (the packet sent to 10.0.0.0:12345) >>>> actually had no affect (unreachable address). If there is no >>>> incidental >>>> network activity then the real network interface is not seen and so >>>> the >>>> test fails. >>>> >>>> David >>>> >>>>> Thanks , Matthias >>>>> >>>>> From: Baesken, Matthias >>>>> Sent: Montag, 12. August 2019 14:33 >>>>> To: 'hotspot-dev at openjdk.java.net'; >>>> 'hotspot-jfr-dev at openjdk.java.net' >>>>> Subject: RFR [XS]: 8229370: make >>>> jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java more stable >>>>> Hello, please review this small test enhancement. >>>>> >>>>> We noticed that on some of our Linux machines? (SLES12 based)?? the >>>> TestNetworkUtilizationEvent.java test reported just 1 interface >>>>> (the test TestNetworkUtilizationEvent.java? expects more than 1 on >>>>> Linux). >>>>> >>>>> Looking into the HS code , os_perf_linux.cpp collects the >>>>> interfaces + >>>> additional information about bytes read/written? (by looking at >>>> /sys/class/net/eth/statistics/ ) >>>>> and this info is given to JFR . >>>>> >>>>> However it seems to need (at least on some machines / setups) more >>>> packet send operations / potential? retries to really? get counter >>>> updates >>>> (and without updates in the counters,?? no interfaces are found). >>>>> So I adjusted the test accordingly. >>>>> >>>>> >>>>> Bug/webrev : >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8229370 >>>>> >>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8229370.0/ >>>>> >>>>> >>>>> Best regards, Matthias >>>>> From kim.barrett at oracle.com Wed Aug 28 04:48:15 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 28 Aug 2019 00:48:15 -0400 Subject: RFR: 8230203: Replace markWord enums with uintptr_t constants In-Reply-To: <8eaa5a80-c897-8af8-4610-df41815cd02b@oracle.com> References: <1c706a0b-4be8-9255-74dc-83a0311b4023@oracle.com> <3D0A760F-1D21-48D6-8903-B4363A4A3404@oracle.com> <8eaa5a80-c897-8af8-4610-df41815cd02b@oracle.com> Message-ID: > On Aug 27, 2019, at 10:05 PM, David Holmes wrote: > In markWord.hpp: > > 334 assert(age <= max_age, "age too large"); > > This assert is a tautology as age and max_age are the same uint type. (I expect some compilers may point this out.) max_age == age_mask == right_n_bits(age_bits) == right_n_bits(4) From david.holmes at oracle.com Wed Aug 28 05:37:14 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 28 Aug 2019 15:37:14 +1000 Subject: RFR: 8230203: Replace markWord enums with uintptr_t constants In-Reply-To: <8eaa5a80-c897-8af8-4610-df41815cd02b@oracle.com> References: <1c706a0b-4be8-9255-74dc-83a0311b4023@oracle.com> <3D0A760F-1D21-48D6-8903-B4363A4A3404@oracle.com> <8eaa5a80-c897-8af8-4610-df41815cd02b@oracle.com> Message-ID: <46e7bdb9-9800-ee95-3ba3-1e7c3a44784d@oracle.com> On 28/08/2019 12:05 pm, David Holmes wrote: > Hi Stefan, > > On 28/08/2019 6:06 am, Stefan Karlsson wrote: >> Hi Kim, >> >> I think your comments makes sense. I have an updated webrev that >> changes some of the types: >> >> ??https://cr.openjdk.java.net/~stefank/8230203/webrev.02.delta/ >> ??https://cr.openjdk.java.net/~stefank/8230203/webrev.02/ > > I agree that is much clearer now. "bits" and "shifts" are just numbers. > masks and comparison-constants should be the same type as the > variable(s) they will be applied to. > > In markWord.hpp: > > 334???? assert(age <= max_age, "age too large"); > > This assert is a tautology as age and max_age are the same uint type. (I > expect some compilers may point this out.) Ignore that idiotic comment. > Thanks, > David > ----- > >> The new patch compiles on Linux x64 and not yet tested. I'll run it >> through testing if you think this is the right change. >> >> Thanks, >> StefanK >> >> On 2019-08-27 20:04, Kim Barrett wrote: >>>> On Aug 27, 2019, at 3:32 AM, Stefan Karlsson >>>> wrote: >>>> >>>> Hi all, >>>> >>>> Please review this patch to convert the enum constants in markWord >>>> into static const unintptr_t constants. >>>> >>>> http://cr.openjdk.java.net/~stefank/8230203/webrev.01/ >>>> https://bugs.openjdk.java.net/browse/JDK-8230203 >>>> >>>> This is a follow-up RFE from the review of JDK-8229258, where a >>>> number of unnecessary casts were pointed out. >>>> >>>> There was also a recent bug in this area, JDK-8221725, where Thomas >>>> points out the problem of relying on the bit width of the enum values. >>>> >>>> This patch: >>>> 1) changes all constants to have the same type as the >>>> markWord::_value field. >>>> 2) Removes unnecessary uintptr_t casts >>>> 3) Removes uintx casts, because they are typedefed to be uintptr_t >>>> 4) Adds explicit casts to (int) when values are negated. >>>> 5) Try to only use uintptr_t inside markWord. >>>> 6) Leaves the use of intptr_t for parameters and return types of the >>>> different hash functions. >>>> >>>> Tested with tier1-3 >>>> >>>> Thanks, >>>> StefanK >>> >>> ------------------------------------------------------------------------------ >>> >>> src/hotspot/share/oops/markWord.hpp >>> ? 134?? static const uintptr_t age_bits???????????????? = 4; >>> ... >>> >>> and >>> ? 144?? static const uintptr_t lock_shift?????????????? = 0; >>> ... >>> >>> The bit counts and shift counts are used as rhs in shift expressions >>> and such.? I think they should be int or uint rather than uintptr_t. >>> >>> ------------------------------------------------------------------------------ >>> >>> src/hotspot/share/oops/markWord.hpp >>> ? 334???? assert((uintptr_t)age <= max_age, "age too large"); >>> >>> I think the cast here is unnecessary and not really helpful. >>> >>> Unfortunately, the cast in the immediately following line: >>> ? 335???? assert((uintptr_t)bias_epoch <= max_bias_epoch, "bias epoch >>> too large"); >>> >>> probably is needed to avoid -Wsign-compare warnings.? (Though >>> JDK-8230118 suggests we might not be getting -Wsign-compare warnings >>> when one might think we ought.) >>> >>> ------------------------------------------------------------------------------ >>> >>> src/hotspot/share/oops/markWord.hpp >>> ? 409???? assert((size & ~size_mask) == 0, "shouldn't overflow size >>> field"); >>> ? 410???? return markWord((cms_free_prototype().value() & >>> ~size_mask_in_place) | >>> ? 411???????????????????? ((size & size_mask) << size_shift)); >>> >>> I wonder why 411 is applying size_mask after the 409 assert? >>> >>> ------------------------------------------------------------------------------ >>> >>> I think there were 3 casts to int added: >>> >>> src/hotspot/share/opto/macro.cpp >>> 2229 (~(int)markWord::age_mask_in_place), 0); >>> >>> src/hotspot/cpu/ppc/macroAssembler_ppc.cpp >>> 3003?? addi(current_header, current_header, >>> -(int)markWord::monitor_value); // monitor >>> >>> src/hotspot/cpu/aarch64/aarch64.ad >>> 3619???? __ add(tmp, tmp, -(int)markWord::monitor_value); // monitor >>> >>> Consider preceeding these with STATIC_ASSERTs that the value being >>> cast is <= INT_MAX. >>> >>> ------------------------------------------------------------------------------ >>> >>> >> From david.holmes at oracle.com Wed Aug 28 06:55:03 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 28 Aug 2019 16:55:03 +1000 Subject: RFR: 8230203: Replace markWord enums with uintptr_t constants In-Reply-To: References: <1c706a0b-4be8-9255-74dc-83a0311b4023@oracle.com> <3D0A760F-1D21-48D6-8903-B4363A4A3404@oracle.com> <8eaa5a80-c897-8af8-4610-df41815cd02b@oracle.com> Message-ID: <3817bd03-9045-9f8e-8da3-301107210b2c@oracle.com> On 28/08/2019 2:48 pm, Kim Barrett wrote: >> On Aug 27, 2019, at 10:05 PM, David Holmes wrote: >> In markWord.hpp: >> >> 334 assert(age <= max_age, "age too large"); >> >> This assert is a tautology as age and max_age are the same uint type. (I expect some compilers may point this out.) > > max_age == age_mask > == right_n_bits(age_bits) > == right_n_bits(4) Yeah - thanks Kim. Doh! David From matthias.baesken at sap.com Wed Aug 28 07:18:39 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 28 Aug 2019 07:18:39 +0000 Subject: RFR: [XS] 8229284: [TESTBUG] jdk/internal/platform/cgroup/TestCgroupMetrics.java fails for - memory:getMemoryUsage In-Reply-To: <5D656641.6090708@oracle.com> References: <5D656641.6090708@oracle.com> Message-ID: Hi Mikhailo , thanks for the review . Will push it as XS tomorrow in case no complains show up in the meantime . Best regards, Matthias > -----Original Message----- > From: Mikhailo Seledtsov > Sent: Dienstag, 27. August 2019 19:20 > To: Baesken, Matthias > Cc: 'hotspot-dev at openjdk.java.net' > Subject: Re: RFR: [XS] 8229284: [TESTBUG] > jdk/internal/platform/cgroup/TestCgroupMetrics.java fails for - > memory:getMemoryUsage > > Looks reasonable to me, > Thank you, > Misha > > On 8/15/19, 9:08 AM, Baesken, Matthias wrote: > > Hello, please review this small test adjustment . > > > > We sometimes see failures in the jtreg test > jdk/internal/platform/cgroup/TestCgroupMetrics.java . > > Failures look like : > > > > java.lang.RuntimeException: Test failed for - memory:getMemoryUsage, > expected [56019386368], got [56200986624] > > at jdk.test.lib.containers.cgroup.MetricsTester.fail(MetricsTester.java:207) > > at > jdk.test.lib.containers.cgroup.MetricsTester.testMemoryUsage(MetricsTest > er.java:597) > > at TestCgroupMetrics.main(TestCgroupMetrics.java:53) > > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMet > hodAccessorImpl.java:62) > > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Delega > tingMethodAccessorImpl.java:43) > > at java.base/java.lang.reflect.Method.invoke(Method.java:567) > > at > com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapp > er.java:127) > > at java.base/java.lang.Thread.run(Thread.java:830) > > > > > > Looking at the coding in MetricsTester.java we expect that > "memory.usage_in_bytes" gets larger after one additional allocation of 64 > M. > > However this is sometimes not the case. > > > > Reason might be that a GC kicked in and freed space; or for some reasons > OS pages were freed. > > > > So I make the test more robust and do some allocations in a loop, > breaking out of the loop after new values got larger than initial ones . > > > > > > Thanks, Matthias > > > > Bug/webrev : > > > > https://bugs.openjdk.java.net/browse/JDK-8229284 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8229284.3/ > > > > From david.holmes at oracle.com Wed Aug 28 07:40:40 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 28 Aug 2019 17:40:40 +1000 Subject: RFR [XS]: 8229370: make jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java more stable In-Reply-To: References: <9f1e22b3-14c9-ecb1-e0b0-d6c19fa02a4e@oracle.com> <5D6596DD.5090602@oracle.com> <0a87d9fc-f7cf-26e1-cf1c-1914eec68fc3@oracle.com> Message-ID: <74db647a-ef7d-2064-16af-e838d22d608e@oracle.com> Hi Misha, On 28/08/2019 12:53 pm, mikhailo.seledtsov at oracle.com wrote: > > On 8/27/19 6:14 PM, David Holmes wrote: >> On 28/08/2019 6:47 am, Mikhailo Seledtsov wrote: >>> On 8/27/19, 1:15 AM, Baesken, Matthias wrote: >>>> Hi? David,?? thanks for? the info about >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8228990 >>>> >>>> >>>> regarding your comment in the bug : >>>> >>>>> So it makes no sense. I finally found an example where the test >>>>> passed and failed on the same machine. >>>> I've seen this too . >>>> >>>> Looks like? my change? only? increased? the probability of >>>> incidental network traffic happening? on the real network interfaces . >>>> >>>> Should we exclude the test,? in the current state it might indeed be >>>> problematic . >>>> >>>> (otherwise we could make the test pass? on Linux? when just 1 >>>> network interface is found,? this might be a legitimate case isn?t >>>> it ?) >>> Based on David's analysis in the "JDK-8228990: [TESTBUG] JFR >>> TestNetworkUtilizationEvent.java expects 2+ Network interfaces on >>> Linux but finding 1", my opinion is to remove the check for number of >>> interfaces all together. Or just check that there is 1 interface. >> >> The test expects there to be two interfaces always present: the >> loopback interface and a real network interface. There could be >> additional ones. The problem is that the test fails to generate >> traffic on the real network interface due to the use of >> 10.0.0.0:12345. I have no idea why someone thought sending a packet to >> that address would necessarily cause the kind of traffic that would >> show up in the JFR event. >> >> Are we really likely to be running this test on a machine without a >> real network interface or the loopback interface? The former seems >> very unlikely. The latter may be something configurable but it seems >> very unlikely to me that anyone would configure a test system that >> way. So I don't think the "expected number of interfaces" is the >> issue. The issue is generating observable traffic on the real network >> interface - at least that is what we see in our test failures (the >> output for the "lo" interface is always present). > Thank you for detailed explanation. Sorry, I did not understand this at > first. >> >> So it should be as simple as changing 10.0.0.0:12345 into something >> guaranteed to work? >> >> I think this needs to be looked at by the JFR folk and net-dev folk to >> come up with a valid testing scenario. > > Perhaps, we can problem list the test for now, until we find a good > solution. Several options come to mind: > > ?? - pick a suitable destination address for "real network interface" > and test it first; if no traffic is generated after sufficient retries, > return jtreg.SkippedException (test skipped), instead of failure > > ?? - try a range of suitable destination addresses; also have a > fallback to jtreg.SkippedException if none of them work > > ?? - in addition, a suitable address can be passed as a test property; > this way test will be configurable for a given infrastructure > > > What do you think? I spoke to the net folk and one thing that should be guaranteed to work is to write to the IP address of the machine itself (the real IP address not the loopback address). Now to get that without incurring a name resolution we need to get the network interfaces. From Alan Bateman: NetworkInterface.networkInterfaces().flatMap(NetworkInterface::inetAddresses) will give you a stream of the InetAddress objects. So we could write to one or more of those addresses and then check for the utilization info. David ----- > Thank you, > > Misha > >> Cheers, >> David >> >>> Misha >>>> >>>> >>>> Best regards, Matthias >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: David Holmes >>>>> Sent: Dienstag, 27. August 2019 09:56 >>>>> To: Baesken, Matthias; 'hotspot- >>>>> dev at openjdk.java.net'; hotspot-jfr- >>>>> dev at openjdk.java.net >>>>> Subject: Re: RFR [XS]: 8229370: make >>>>> jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java more stable >>>>> >>>>> Hi Matthias, >>>>> >>>>> On 27/08/2019 5:41 pm, Baesken, Matthias wrote: >>>>>> Hello, any reviews for this small change ? >>>>> I missed the initial request - sorry. >>>>> >>>>> Seems we have a double up of effort here as we also have >>>>> JDK-8228990 for >>>>> the exact same problem that we see on some of our test machines. >>>>> >>>>> Our analysis suggests that this test often passes by accident due to >>>>> incidental activity on the real network interface when the logic >>>>> intended to generate that activity (the packet sent to 10.0.0.0:12345) >>>>> actually had no affect (unreachable address). If there is no >>>>> incidental >>>>> network activity then the real network interface is not seen and so >>>>> the >>>>> test fails. >>>>> >>>>> David >>>>> >>>>>> Thanks , Matthias >>>>>> >>>>>> From: Baesken, Matthias >>>>>> Sent: Montag, 12. August 2019 14:33 >>>>>> To: 'hotspot-dev at openjdk.java.net'; >>>>> 'hotspot-jfr-dev at openjdk.java.net' >>>>>> Subject: RFR [XS]: 8229370: make >>>>> jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java more stable >>>>>> Hello, please review this small test enhancement. >>>>>> >>>>>> We noticed that on some of our Linux machines? (SLES12 based)?? the >>>>> TestNetworkUtilizationEvent.java test reported just 1 interface >>>>>> (the test TestNetworkUtilizationEvent.java? expects more than 1 on >>>>>> Linux). >>>>>> >>>>>> Looking into the HS code , os_perf_linux.cpp collects the >>>>>> interfaces + >>>>> additional information about bytes read/written? (by looking at >>>>> /sys/class/net/eth/statistics/ ) >>>>>> and this info is given to JFR . >>>>>> >>>>>> However it seems to need (at least on some machines / setups) more >>>>> packet send operations / potential? retries to really? get counter >>>>> updates >>>>> (and without updates in the counters,?? no interfaces are found). >>>>>> So I adjusted the test accordingly. >>>>>> >>>>>> >>>>>> Bug/webrev : >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8229370 >>>>>> >>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8229370.0/ >>>>>> >>>>>> >>>>>> Best regards, Matthias >>>>>> From martin.doerr at sap.com Wed Aug 28 08:02:42 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 28 Aug 2019 08:02:42 +0000 Subject: RFR: 8230203: Replace markWord enums with uintptr_t constants In-Reply-To: <6DEEBC19-7E2E-4DF7-80A6-0C2D1794C4F6@oracle.com> References: <1c706a0b-4be8-9255-74dc-83a0311b4023@oracle.com> <6DEEBC19-7E2E-4DF7-80A6-0C2D1794C4F6@oracle.com> Message-ID: Hi Kim, thanks for your explanations. > What I think you want is > C++11 explicitly typed enums, e.g. ?enum : uintptr_t { ? };? Yes. That's what I meant. > I agree there?s a lot less boilerplate with that. But I like all the cast removals > coming out of this change, and would rather not wait for those. I also like the cast removals. > There are still some issues with Solaris Studio. Potential issues with other > (more obscure) platforms. I hope they can get resolved soon. So wrt. to this issue, I abstain. Cast removal looks good, tons of static consts look bad. Best regards, Martin From sgehwolf at redhat.com Wed Aug 28 08:51:21 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 28 Aug 2019 10:51:21 +0200 Subject: RFR: [XS] 8229284: [TESTBUG] jdk/internal/platform/cgroup/TestCgroupMetrics.java fails for - memory:getMemoryUsage In-Reply-To: References: Message-ID: On Thu, 2019-08-15 at 16:08 +0000, Baesken, Matthias wrote: > https://bugs.openjdk.java.net/browse/JDK-8229284 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8229284.3/ Hmm, unrelated to this bug, but still an issue: It appears the failure message is bogus when the test fails. It should be: java.lang.RuntimeException: Test failed for - memory:getMemoryUsage, expected [56200986624], got [56019386368] I.e. the old/new values need to be swapped here: 597 fail(SubSystem.MEMORY, "getMemoryUsage", newMemoryUsage, memoryUsage); Same for the getMemoryMaxUsage() fail: 592 fail(SubSystem.MEMORY, "getMemoryMaxUsage", newMemoryMaxUsage, 593 memoryMaxUsage); As to the bug. It suggests the memoryUsage code causes problems, not memoryMaxUsage. 587 // allocate memory in a loop and check more than once for new values 588 // otherwise we might see seldom the effect of decreasing new memory values 589 // e.g. because the system could free up memory 590 byte[][] bytes = new byte[32][]; 591 for (int i = 0; i < 32; i++) { 592 bytes[i] = new byte[8*1024*1024]; 593 newMemoryMaxUsage = metrics.getMemoryMaxUsage(); 594 newMemoryUsage = metrics.getMemoryUsage(); 595 if (newMemoryMaxUsage > memoryMaxUsage && newMemoryUsage > memoryUsage) { 596 break; 597 } Do we really need to call metrics.getMemoryMaxUsage() in that loop? I'd expect for the following code to work more reliably as the max usage is supposed to capture the high water mark. If memoryMaxUsage ever decreases, it's a bug in the cgroups accounting system right? byte[][] bytes = new byte[32][]; for (int i = 0; i < 32; i++) { bytes[i] = new byte[8*1024*1024]; newMemoryUsage = metrics.getMemoryUsage(); if (newMemoryUsage > memoryUsage) { break; } } newMemoryMaxUsage = metrics.getMemoryMaxUsage(); // assert things Perhaps even assert prior the loop: if (memoryMaxUsage < memoryUsage) { throw new RuntimeException("cgroup accounting bug?"); } Thanks, Severin From robbin.ehn at oracle.com Wed Aug 28 09:57:57 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Wed, 28 Aug 2019 11:57:57 +0200 Subject: RFR(L): 8226705: [REDO] Deoptimize with handshakes In-Reply-To: <1e83f10c-d300-0511-e6df-ee45463807ec@oracle.com> References: <1e83f10c-d300-0511-e6df-ee45463807ec@oracle.com> Message-ID: <7089f41c-be3e-840b-b640-403d925ac272@oracle.com> Hi, hotspot-dev was the intended list. Thanks, Robbin On 2019-08-28 09:30, Robbin Ehn wrote: > Hi all, please consider, > > To get away from the issues of us revoking in the handshake, but before deopt > the locks get re-biased before we hit deopt handler, we instead revoke in deopt > handler. > The deopt handler have a JRT_BLOCK/_END which can safepoint so we revoke after > that but before we start looking at the monitors, with a NoSafepointVerifier. > > Here is the previous changeset on top of jdk/jdk tip but due to merge conflicts > some pieces did not apply: > http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-8221734-baseline/webrev/ > So this is what was reviewed. > > The rebase (merge conflict resolutions) and 8224795 bug fix : > http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-rebase/webrev/ > > Bug 8224795 fix is here: > http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-rebase/webrev/src/hotspot/share/code/nmethod.cpp.sdiff.html > > > After this we have the same functionally as the reverted change-set. > > Here is the changes for doing the revoke in deopt handler instead: > http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-revoke-on-deopt/webrev/ > > This code was messy adding the deopt revocation in 3 places made it worse. > Here is a refactoring of that code. (also removed a dead method in biasedlocking): > http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-refactor/webrev/ > > And here is full: > http://cr.openjdk.java.net/~rehn/8226705/v1/full/webrev/ > > Also a full squashed patch file: > http://cr.openjdk.java.net/~rehn/8226705/v1/full/full.patch > > Latest test run I did t1-t6, Linux/Windows x64 have passed, MacOSX still > running. > > Thanks, Robbin > > From matthias.baesken at sap.com Wed Aug 28 12:02:12 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 28 Aug 2019 12:02:12 +0000 Subject: RFR [XS]: 8229370: make jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java more stable In-Reply-To: <74db647a-ef7d-2064-16af-e838d22d608e@oracle.com> References: <9f1e22b3-14c9-ecb1-e0b0-d6c19fa02a4e@oracle.com> <5D6596DD.5090602@oracle.com> <0a87d9fc-f7cf-26e1-cf1c-1914eec68fc3@oracle.com> <74db647a-ef7d-2064-16af-e838d22d608e@oracle.com> Message-ID: Hi David, thanks for reaching out to the net folks. I use now the stream of InetAddresses from NetworkInterface.networkInterfaces().flatMap(NetworkInterface::inetAddresses) ; However on the machine where I noticed the issue , I still have to do a couple of retries . Just one send to the stream of InetAddresses from NetworkInterface.networkInterfaces().flatMap(NetworkInterface::inetAddresses) does not always give the expected result ? . New webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8229370.2/ Thanks, Matthias > -----Original Message----- > From: David Holmes > Sent: Mittwoch, 28. August 2019 09:41 > To: mikhailo.seledtsov at oracle.com; Baesken, Matthias > > Cc: 'hotspot-dev at openjdk.java.net' ; > hotspot-jfr-dev at openjdk.java.net > Subject: Re: RFR [XS]: 8229370: make > jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java more stable > > Hi Misha, > > On 28/08/2019 12:53 pm, mikhailo.seledtsov at oracle.com wrote: > > > > On 8/27/19 6:14 PM, David Holmes wrote: > >> On 28/08/2019 6:47 am, Mikhailo Seledtsov wrote: > >>> On 8/27/19, 1:15 AM, Baesken, Matthias wrote: > >>>> Hi? David,?? thanks for? the info about > >>>> > >>>> https://bugs.openjdk.java.net/browse/JDK-8228990 > >>>> > >>>> > >>>> regarding your comment in the bug : > >>>> > >>>>> So it makes no sense. I finally found an example where the test > >>>>> passed and failed on the same machine. > >>>> I've seen this too . > >>>> > >>>> Looks like? my change? only? increased? the probability of > >>>> incidental network traffic happening? on the real network interfaces . > >>>> > >>>> Should we exclude the test,? in the current state it might indeed be > >>>> problematic . > >>>> > >>>> (otherwise we could make the test pass? on Linux? when just 1 > >>>> network interface is found,? this might be a legitimate case isn?t > >>>> it ?) > >>> Based on David's analysis in the "JDK-8228990: [TESTBUG] JFR > >>> TestNetworkUtilizationEvent.java expects 2+ Network interfaces on > >>> Linux but finding 1", my opinion is to remove the check for number of > >>> interfaces all together. Or just check that there is 1 interface. > >> > >> The test expects there to be two interfaces always present: the > >> loopback interface and a real network interface. There could be > >> additional ones. The problem is that the test fails to generate > >> traffic on the real network interface due to the use of > >> 10.0.0.0:12345. I have no idea why someone thought sending a packet to > >> that address would necessarily cause the kind of traffic that would > >> show up in the JFR event. > >> > >> Are we really likely to be running this test on a machine without a > >> real network interface or the loopback interface? The former seems > >> very unlikely. The latter may be something configurable but it seems > >> very unlikely to me that anyone would configure a test system that > >> way. So I don't think the "expected number of interfaces" is the > >> issue. The issue is generating observable traffic on the real network > >> interface - at least that is what we see in our test failures (the > >> output for the "lo" interface is always present). > > Thank you for detailed explanation. Sorry, I did not understand this at > > first. > >> > >> So it should be as simple as changing 10.0.0.0:12345 into something > >> guaranteed to work? > >> > >> I think this needs to be looked at by the JFR folk and net-dev folk to > >> come up with a valid testing scenario. > > > > Perhaps, we can problem list the test for now, until we find a good > > solution. Several options come to mind: > > > > ?? - pick a suitable destination address for "real network interface" > > and test it first; if no traffic is generated after sufficient retries, > > return jtreg.SkippedException (test skipped), instead of failure > > > > ?? - try a range of suitable destination addresses; also have a > > fallback to jtreg.SkippedException if none of them work > > > > ?? - in addition, a suitable address can be passed as a test property; > > this way test will be configurable for a given infrastructure > > > > > > What do you think? > > I spoke to the net folk and one thing that should be guaranteed to work > is to write to the IP address of the machine itself (the real IP address > not the loopback address). Now to get that without incurring a name > resolution we need to get the network interfaces. From Alan Bateman: > > NetworkInterface.networkInterfaces().flatMap(NetworkInterface::inetAddr > esses) > will give you a stream of the InetAddress objects. > > So we could write to one or more of those addresses and then check for > the utilization info. > > David > ----- > > > Thank you, > > > > Misha > > > >> Cheers, > >> David > >> > >>> Misha > >>>> > >>>> > >>>> Best regards, Matthias > >>>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: David Holmes > >>>>> Sent: Dienstag, 27. August 2019 09:56 > >>>>> To: Baesken, Matthias; 'hotspot- > >>>>> dev at openjdk.java.net'; hotspot- > jfr- > >>>>> dev at openjdk.java.net > >>>>> Subject: Re: RFR [XS]: 8229370: make > >>>>> jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java more stable > >>>>> > >>>>> Hi Matthias, > >>>>> > >>>>> On 27/08/2019 5:41 pm, Baesken, Matthias wrote: > >>>>>> Hello, any reviews for this small change ? > >>>>> I missed the initial request - sorry. > >>>>> > >>>>> Seems we have a double up of effort here as we also have > >>>>> JDK-8228990 for > >>>>> the exact same problem that we see on some of our test machines. > >>>>> > >>>>> Our analysis suggests that this test often passes by accident due to > >>>>> incidental activity on the real network interface when the logic > >>>>> intended to generate that activity (the packet sent to 10.0.0.0:12345) > >>>>> actually had no affect (unreachable address). If there is no > >>>>> incidental > >>>>> network activity then the real network interface is not seen and so > >>>>> the > >>>>> test fails. > >>>>> > >>>>> David > >>>>> > >>>>>> Thanks , Matthias > >>>>>> > >>>>>> From: Baesken, Matthias > >>>>>> Sent: Montag, 12. August 2019 14:33 > >>>>>> To: 'hotspot-dev at openjdk.java.net' dev at openjdk.java.net>; > >>>>> 'hotspot-jfr-dev at openjdk.java.net' dev at openjdk.java.net> > >>>>>> Subject: RFR [XS]: 8229370: make > >>>>> jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java more stable > >>>>>> Hello, please review this small test enhancement. > >>>>>> > >>>>>> We noticed that on some of our Linux machines? (SLES12 based)?? the > >>>>> TestNetworkUtilizationEvent.java test reported just 1 interface > >>>>>> (the test TestNetworkUtilizationEvent.java? expects more than 1 on > >>>>>> Linux). > >>>>>> > >>>>>> Looking into the HS code , os_perf_linux.cpp collects the > >>>>>> interfaces + > >>>>> additional information about bytes read/written? (by looking at > >>>>> /sys/class/net/eth/statistics/ ) > >>>>>> and this info is given to JFR . > >>>>>> > >>>>>> However it seems to need (at least on some machines / setups) > more > >>>>> packet send operations / potential? retries to really? get counter > >>>>> updates > >>>>> (and without updates in the counters,?? no interfaces are found). > >>>>>> So I adjusted the test accordingly. > >>>>>> > >>>>>> > >>>>>> Bug/webrev : > >>>>>> > >>>>>> https://bugs.openjdk.java.net/browse/JDK-8229370 > >>>>>> > >>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8229370.0/ > >>>>>> > >>>>>> > >>>>>> Best regards, Matthias > >>>>>> From matthias.baesken at sap.com Wed Aug 28 12:39:47 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 28 Aug 2019 12:39:47 +0000 Subject: RFR: [XS] 8229284: [TESTBUG] jdk/internal/platform/cgroup/TestCgroupMetrics.java fails for - memory:getMemoryUsage In-Reply-To: References: Message-ID: Hi Severin, I changed the fail() - calls and the newMemoryMaxUsage handling. New webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8229284.5/ Best regards, Matthias > > On Thu, 2019-08-15 at 16:08 +0000, Baesken, Matthias wrote: > > https://bugs.openjdk.java.net/browse/JDK-8229284 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8229284.3/ > > Hmm, unrelated to this bug, but still an issue: > > It appears the failure message is bogus when the test fails. It should > be: > > java.lang.RuntimeException: Test failed for - memory:getMemoryUsage, > expected [56200986624], got [56019386368] > > I.e. the old/new values need to be swapped here: > > 597 fail(SubSystem.MEMORY, "getMemoryUsage", > newMemoryUsage, memoryUsage); > > Same for the getMemoryMaxUsage() fail: > > 592 fail(SubSystem.MEMORY, "getMemoryMaxUsage", > newMemoryMaxUsage, > 593 memoryMaxUsage); > > As to the bug. It suggests the memoryUsage code causes problems, not > memoryMaxUsage. > > 587 // allocate memory in a loop and check more than once for new > values > 588 // otherwise we might see seldom the effect of decreasing new > memory values > 589 // e.g. because the system could free up memory > 590 byte[][] bytes = new byte[32][]; > 591 for (int i = 0; i < 32; i++) { > 592 bytes[i] = new byte[8*1024*1024]; > 593 newMemoryMaxUsage = metrics.getMemoryMaxUsage(); > 594 newMemoryUsage = metrics.getMemoryUsage(); > 595 if (newMemoryMaxUsage > memoryMaxUsage && > newMemoryUsage > memoryUsage) { > 596 break; > 597 } > > Do we really need to call metrics.getMemoryMaxUsage() in that loop? I'd > expect for the following code to work more reliably as the max usage is > supposed to capture the high water mark. If memoryMaxUsage ever > decreases, it's a bug in the cgroups accounting system right? > > byte[][] bytes = new byte[32][]; > for (int i = 0; i < 32; i++) { > bytes[i] = new byte[8*1024*1024]; > newMemoryUsage = metrics.getMemoryUsage(); > if (newMemoryUsage > memoryUsage) { > break; > } > } > newMemoryMaxUsage = metrics.getMemoryMaxUsage(); > > // assert things > > Perhaps even assert prior the loop: > > if (memoryMaxUsage < memoryUsage) { > throw new RuntimeException("cgroup accounting bug?"); > } > > Thanks, > Severin From david.holmes at oracle.com Wed Aug 28 12:40:10 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 28 Aug 2019 22:40:10 +1000 Subject: RFR [XS]: 8229370: make jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java more stable In-Reply-To: References: <9f1e22b3-14c9-ecb1-e0b0-d6c19fa02a4e@oracle.com> <5D6596DD.5090602@oracle.com> <0a87d9fc-f7cf-26e1-cf1c-1914eec68fc3@oracle.com> <74db647a-ef7d-2064-16af-e838d22d608e@oracle.com> Message-ID: <431d82f5-bea7-192e-3fcb-08888f2c6a42@oracle.com> Hi Matthias, On 28/08/2019 10:02 pm, Baesken, Matthias wrote: > Hi David, thanks for reaching out to the net folks. > > I use now the stream of InetAddresses from NetworkInterface.networkInterfaces().flatMap(NetworkInterface::inetAddresses) ; > > However on the machine where I noticed the issue , I still have to do a couple of retries . > Just one send to the stream of InetAddresses from NetworkInterface.networkInterfaces().flatMap(NetworkInterface::inetAddresses) does not always give > the expected result ? . That doesn't make sense to me, if one of the interfaces is the real network interface and we write to the real IP address. I think we need to add some diagnostics to see exactly which interface and IP address we are writing to, and then see what each interface reports on the read back of the data. Thanks, David > New webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8229370.2/ > > > Thanks, Matthias > > > >> -----Original Message----- >> From: David Holmes >> Sent: Mittwoch, 28. August 2019 09:41 >> To: mikhailo.seledtsov at oracle.com; Baesken, Matthias >> >> Cc: 'hotspot-dev at openjdk.java.net' ; >> hotspot-jfr-dev at openjdk.java.net >> Subject: Re: RFR [XS]: 8229370: make >> jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java more stable >> >> Hi Misha, >> >> On 28/08/2019 12:53 pm, mikhailo.seledtsov at oracle.com wrote: >>> >>> On 8/27/19 6:14 PM, David Holmes wrote: >>>> On 28/08/2019 6:47 am, Mikhailo Seledtsov wrote: >>>>> On 8/27/19, 1:15 AM, Baesken, Matthias wrote: >>>>>> Hi? David,?? thanks for? the info about >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8228990 >>>>>> >>>>>> >>>>>> regarding your comment in the bug : >>>>>> >>>>>>> So it makes no sense. I finally found an example where the test >>>>>>> passed and failed on the same machine. >>>>>> I've seen this too . >>>>>> >>>>>> Looks like? my change? only? increased? the probability of >>>>>> incidental network traffic happening? on the real network interfaces . >>>>>> >>>>>> Should we exclude the test,? in the current state it might indeed be >>>>>> problematic . >>>>>> >>>>>> (otherwise we could make the test pass? on Linux? when just 1 >>>>>> network interface is found,? this might be a legitimate case isn?t >>>>>> it ?) >>>>> Based on David's analysis in the "JDK-8228990: [TESTBUG] JFR >>>>> TestNetworkUtilizationEvent.java expects 2+ Network interfaces on >>>>> Linux but finding 1", my opinion is to remove the check for number of >>>>> interfaces all together. Or just check that there is 1 interface. >>>> >>>> The test expects there to be two interfaces always present: the >>>> loopback interface and a real network interface. There could be >>>> additional ones. The problem is that the test fails to generate >>>> traffic on the real network interface due to the use of >>>> 10.0.0.0:12345. I have no idea why someone thought sending a packet to >>>> that address would necessarily cause the kind of traffic that would >>>> show up in the JFR event. >>>> >>>> Are we really likely to be running this test on a machine without a >>>> real network interface or the loopback interface? The former seems >>>> very unlikely. The latter may be something configurable but it seems >>>> very unlikely to me that anyone would configure a test system that >>>> way. So I don't think the "expected number of interfaces" is the >>>> issue. The issue is generating observable traffic on the real network >>>> interface - at least that is what we see in our test failures (the >>>> output for the "lo" interface is always present). >>> Thank you for detailed explanation. Sorry, I did not understand this at >>> first. >>>> >>>> So it should be as simple as changing 10.0.0.0:12345 into something >>>> guaranteed to work? >>>> >>>> I think this needs to be looked at by the JFR folk and net-dev folk to >>>> come up with a valid testing scenario. >>> >>> Perhaps, we can problem list the test for now, until we find a good >>> solution. Several options come to mind: >>> >>> ?? - pick a suitable destination address for "real network interface" >>> and test it first; if no traffic is generated after sufficient retries, >>> return jtreg.SkippedException (test skipped), instead of failure >>> >>> ?? - try a range of suitable destination addresses; also have a >>> fallback to jtreg.SkippedException if none of them work >>> >>> ?? - in addition, a suitable address can be passed as a test property; >>> this way test will be configurable for a given infrastructure >>> >>> >>> What do you think? >> >> I spoke to the net folk and one thing that should be guaranteed to work >> is to write to the IP address of the machine itself (the real IP address >> not the loopback address). Now to get that without incurring a name >> resolution we need to get the network interfaces. From Alan Bateman: >> >> NetworkInterface.networkInterfaces().flatMap(NetworkInterface::inetAddr >> esses) >> will give you a stream of the InetAddress objects. >> >> So we could write to one or more of those addresses and then check for >> the utilization info. >> >> David >> ----- >> >>> Thank you, >>> >>> Misha >>> >>>> Cheers, >>>> David >>>> >>>>> Misha >>>>>> >>>>>> >>>>>> Best regards, Matthias >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: David Holmes >>>>>>> Sent: Dienstag, 27. August 2019 09:56 >>>>>>> To: Baesken, Matthias; 'hotspot- >>>>>>> dev at openjdk.java.net'; hotspot- >> jfr- >>>>>>> dev at openjdk.java.net >>>>>>> Subject: Re: RFR [XS]: 8229370: make >>>>>>> jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java more stable >>>>>>> >>>>>>> Hi Matthias, >>>>>>> >>>>>>> On 27/08/2019 5:41 pm, Baesken, Matthias wrote: >>>>>>>> Hello, any reviews for this small change ? >>>>>>> I missed the initial request - sorry. >>>>>>> >>>>>>> Seems we have a double up of effort here as we also have >>>>>>> JDK-8228990 for >>>>>>> the exact same problem that we see on some of our test machines. >>>>>>> >>>>>>> Our analysis suggests that this test often passes by accident due to >>>>>>> incidental activity on the real network interface when the logic >>>>>>> intended to generate that activity (the packet sent to 10.0.0.0:12345) >>>>>>> actually had no affect (unreachable address). If there is no >>>>>>> incidental >>>>>>> network activity then the real network interface is not seen and so >>>>>>> the >>>>>>> test fails. >>>>>>> >>>>>>> David >>>>>>> >>>>>>>> Thanks , Matthias >>>>>>>> >>>>>>>> From: Baesken, Matthias >>>>>>>> Sent: Montag, 12. August 2019 14:33 >>>>>>>> To: 'hotspot-dev at openjdk.java.net'> dev at openjdk.java.net>; >>>>>>> 'hotspot-jfr-dev at openjdk.java.net'> dev at openjdk.java.net> >>>>>>>> Subject: RFR [XS]: 8229370: make >>>>>>> jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java more stable >>>>>>>> Hello, please review this small test enhancement. >>>>>>>> >>>>>>>> We noticed that on some of our Linux machines? (SLES12 based)?? the >>>>>>> TestNetworkUtilizationEvent.java test reported just 1 interface >>>>>>>> (the test TestNetworkUtilizationEvent.java? expects more than 1 on >>>>>>>> Linux). >>>>>>>> >>>>>>>> Looking into the HS code , os_perf_linux.cpp collects the >>>>>>>> interfaces + >>>>>>> additional information about bytes read/written? (by looking at >>>>>>> /sys/class/net/eth/statistics/ ) >>>>>>>> and this info is given to JFR . >>>>>>>> >>>>>>>> However it seems to need (at least on some machines / setups) >> more >>>>>>> packet send operations / potential? retries to really? get counter >>>>>>> updates >>>>>>> (and without updates in the counters,?? no interfaces are found). >>>>>>>> So I adjusted the test accordingly. >>>>>>>> >>>>>>>> >>>>>>>> Bug/webrev : >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8229370 >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8229370.0/ >>>>>>>> >>>>>>>> >>>>>>>> Best regards, Matthias >>>>>>>> From sgehwolf at redhat.com Wed Aug 28 12:52:09 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 28 Aug 2019 14:52:09 +0200 Subject: RFR: [XS] 8229284: [TESTBUG] jdk/internal/platform/cgroup/TestCgroupMetrics.java fails for - memory:getMemoryUsage In-Reply-To: References: Message-ID: On Wed, 2019-08-28 at 12:39 +0000, Baesken, Matthias wrote: > http://cr.openjdk.java.net/~mbaesken/webrevs/8229284.5/ Looks good. Thanks, Severin From bob.vandette at oracle.com Wed Aug 28 13:23:40 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Wed, 28 Aug 2019 09:23:40 -0400 Subject: RFR: [XS] 8229284: [TESTBUG] jdk/internal/platform/cgroup/TestCgroupMetrics.java fails for - memory:getMemoryUsage In-Reply-To: References: Message-ID: Should you continue waiting in the loop until BOTH the new usage and max usage exceed their initial values? Bob. > On Aug 28, 2019, at 8:39 AM, Baesken, Matthias wrote: > > Hi Severin, I changed the fail() - calls and the newMemoryMaxUsage handling. > New webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8229284.5/ > > > Best regards, Matthias > > >> >> On Thu, 2019-08-15 at 16:08 +0000, Baesken, Matthias wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8229284 >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8229284.3/ >> >> Hmm, unrelated to this bug, but still an issue: >> >> It appears the failure message is bogus when the test fails. It should >> be: >> >> java.lang.RuntimeException: Test failed for - memory:getMemoryUsage, >> expected [56200986624], got [56019386368] >> >> I.e. the old/new values need to be swapped here: >> >> 597 fail(SubSystem.MEMORY, "getMemoryUsage", >> newMemoryUsage, memoryUsage); >> >> Same for the getMemoryMaxUsage() fail: >> >> 592 fail(SubSystem.MEMORY, "getMemoryMaxUsage", >> newMemoryMaxUsage, >> 593 memoryMaxUsage); >> >> As to the bug. It suggests the memoryUsage code causes problems, not >> memoryMaxUsage. >> >> 587 // allocate memory in a loop and check more than once for new >> values >> 588 // otherwise we might see seldom the effect of decreasing new >> memory values >> 589 // e.g. because the system could free up memory >> 590 byte[][] bytes = new byte[32][]; >> 591 for (int i = 0; i < 32; i++) { >> 592 bytes[i] = new byte[8*1024*1024]; >> 593 newMemoryMaxUsage = metrics.getMemoryMaxUsage(); >> 594 newMemoryUsage = metrics.getMemoryUsage(); >> 595 if (newMemoryMaxUsage > memoryMaxUsage && >> newMemoryUsage > memoryUsage) { >> 596 break; >> 597 } >> >> Do we really need to call metrics.getMemoryMaxUsage() in that loop? I'd >> expect for the following code to work more reliably as the max usage is >> supposed to capture the high water mark. If memoryMaxUsage ever >> decreases, it's a bug in the cgroups accounting system right? >> >> byte[][] bytes = new byte[32][]; >> for (int i = 0; i < 32; i++) { >> bytes[i] = new byte[8*1024*1024]; >> newMemoryUsage = metrics.getMemoryUsage(); >> if (newMemoryUsage > memoryUsage) { >> break; >> } >> } >> newMemoryMaxUsage = metrics.getMemoryMaxUsage(); >> >> // assert things >> >> Perhaps even assert prior the loop: >> >> if (memoryMaxUsage < memoryUsage) { >> throw new RuntimeException("cgroup accounting bug?"); >> } >> >> Thanks, >> Severin > From matthias.baesken at sap.com Wed Aug 28 13:40:13 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 28 Aug 2019 13:40:13 +0000 Subject: jdk11 - 8214315: G1: fatal error: acquiring lock SATB_Q_FL_lock/1 out of order with lock tty_lock/0 Message-ID: Hello, please review this downport of 8214315 to jdk11u-dev . It turned out we need this change as a prerequisite for https://bugs.openjdk.java.net/browse/JDK-8224958 The jdk/jdk - patch applies mostly without a lot of adjustments . Webrev for 11 and original bug : http://cr.openjdk.java.net/~mbaesken/webrevs/8214315_11udev.0/ https://bugs.openjdk.java.net/browse/JDK-8214315 original jdk/jdk change was : http://hg.openjdk.java.net/jdk/jdk/rev/bf2f2560dd53 Thanks and best regards, Matthias From sgehwolf at redhat.com Wed Aug 28 13:41:35 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 28 Aug 2019 15:41:35 +0200 Subject: RFR: [XS] 8229284: [TESTBUG] jdk/internal/platform/cgroup/TestCgroupMetrics.java fails for - memory:getMemoryUsage In-Reply-To: References: Message-ID: <32ce3334e992d0e648990ef644a53522cbe3c8a0.camel@redhat.com> On Wed, 2019-08-28 at 09:23 -0400, Bob Vandette wrote: > Should you continue waiting in the loop until BOTH the new usage and max usage exceed their > initial values? Is it ever possible for the high water mark sequence, metrics.getMemoryMaxUsage(), to ever decrease? I'd think not, so my reasoning would be the call after the loop (newMemoryMaxUsage) must be >= memoryMaxUsage. Then the failure condition of 'newMemoryMaxUsage < memoryMaxUsage' must not be satisfied unless it's a bug, right? Thanks, Severin > Bob. > > > > On Aug 28, 2019, at 8:39 AM, Baesken, Matthias < > > matthias.baesken at sap.com> wrote: > > > > Hi Severin, I changed the fail() - calls and > > the newMemoryMaxUsage handling. > > New webrev : > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8229284.5/ > > > > > > Best regards, Matthias > > > > > > > On Thu, 2019-08-15 at 16:08 +0000, Baesken, Matthias wrote: > > > > https://bugs.openjdk.java.net/browse/JDK-8229284 > > > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8229284.3/ > > > > > > Hmm, unrelated to this bug, but still an issue: > > > > > > It appears the failure message is bogus when the test fails. It > > > should > > > be: > > > > > > java.lang.RuntimeException: Test failed for - > > > memory:getMemoryUsage, > > > expected [56200986624], got [56019386368] > > > > > > I.e. the old/new values need to be swapped here: > > > > > > 597 fail(SubSystem.MEMORY, "getMemoryUsage", > > > newMemoryUsage, memoryUsage); > > > > > > Same for the getMemoryMaxUsage() fail: > > > > > > 592 fail(SubSystem.MEMORY, "getMemoryMaxUsage", > > > newMemoryMaxUsage, > > > 593 memoryMaxUsage); > > > > > > As to the bug. It suggests the memoryUsage code causes problems, > > > not > > > memoryMaxUsage. > > > > > > 587 // allocate memory in a loop and check more than once > > > for new > > > values > > > 588 // otherwise we might see seldom the effect of > > > decreasing new > > > memory values > > > 589 // e.g. because the system could free up memory > > > 590 byte[][] bytes = new byte[32][]; > > > 591 for (int i = 0; i < 32; i++) { > > > 592 bytes[i] = new byte[8*1024*1024]; > > > 593 newMemoryMaxUsage = metrics.getMemoryMaxUsage(); > > > 594 newMemoryUsage = metrics.getMemoryUsage(); > > > 595 if (newMemoryMaxUsage > memoryMaxUsage && > > > newMemoryUsage > memoryUsage) { > > > 596 break; > > > 597 } > > > > > > Do we really need to call metrics.getMemoryMaxUsage() in that > > > loop? I'd > > > expect for the following code to work more reliably as the max > > > usage is > > > supposed to capture the high water mark. If memoryMaxUsage ever > > > decreases, it's a bug in the cgroups accounting system right? > > > > > > byte[][] bytes = new byte[32][]; > > > for (int i = 0; i < 32; i++) { > > > bytes[i] = new byte[8*1024*1024]; > > > newMemoryUsage = metrics.getMemoryUsage(); > > > if (newMemoryUsage > memoryUsage) { > > > break; > > > } > > > } > > > newMemoryMaxUsage = metrics.getMemoryMaxUsage(); > > > > > > // assert things > > > > > > Perhaps even assert prior the loop: > > > > > > if (memoryMaxUsage < memoryUsage) { > > > throw new RuntimeException("cgroup accounting bug?"); > > > } > > > > > > Thanks, > > > Severin From bob.vandette at oracle.com Wed Aug 28 13:49:03 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Wed, 28 Aug 2019 09:49:03 -0400 Subject: RFR: [XS] 8229284: [TESTBUG] jdk/internal/platform/cgroup/TestCgroupMetrics.java fails for - memory:getMemoryUsage In-Reply-To: <32ce3334e992d0e648990ef644a53522cbe3c8a0.camel@redhat.com> References: <32ce3334e992d0e648990ef644a53522cbe3c8a0.camel@redhat.com> Message-ID: <2D347C5A-B1C6-43E7-9AAB-89745BB45938@oracle.com> > On Aug 28, 2019, at 9:41 AM, Severin Gehwolf wrote: > > On Wed, 2019-08-28 at 09:23 -0400, Bob Vandette wrote: >> Should you continue waiting in the loop until BOTH the new usage and max usage exceed their >> initial values? > > Is it ever possible for the high water mark sequence, > metrics.getMemoryMaxUsage(), to ever decrease? I'd think not, so my > reasoning would be the call after the loop (newMemoryMaxUsage) must be >> = memoryMaxUsage. Then the failure condition of 'newMemoryMaxUsage < > memoryMaxUsage' must not be satisfied unless it's a bug, right? That?s true but what the test is trying to do is to cause memory to be allocated and confirm that the API reports both memory metrics increase. Simply confirming that it doesn?t decrease does not prove much. If the API was broken, it might report the same value every time and your version of the test would pass (at least for the Max value). If it proves to be too difficult to allocate enough memory to see the Max value increase without getting an OOM, then we might have to consider removing that part of the test. You might have to adjust the min & max Heap sizes in order to ensure that pages are allocated during the test causing the Max memory size to increase. Bob. > > Thanks, > Severin > >> Bob. >> >> >>> On Aug 28, 2019, at 8:39 AM, Baesken, Matthias < >>> matthias.baesken at sap.com> wrote: >>> >>> Hi Severin, I changed the fail() - calls and >>> the newMemoryMaxUsage handling. >>> New webrev : >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8229284.5/ >>> >>> >>> Best regards, Matthias >>> >>> >>>> On Thu, 2019-08-15 at 16:08 +0000, Baesken, Matthias wrote: >>>>> https://bugs.openjdk.java.net/browse/JDK-8229284 >>>>> >>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8229284.3/ >>>> >>>> Hmm, unrelated to this bug, but still an issue: >>>> >>>> It appears the failure message is bogus when the test fails. It >>>> should >>>> be: >>>> >>>> java.lang.RuntimeException: Test failed for - >>>> memory:getMemoryUsage, >>>> expected [56200986624], got [56019386368] >>>> >>>> I.e. the old/new values need to be swapped here: >>>> >>>> 597 fail(SubSystem.MEMORY, "getMemoryUsage", >>>> newMemoryUsage, memoryUsage); >>>> >>>> Same for the getMemoryMaxUsage() fail: >>>> >>>> 592 fail(SubSystem.MEMORY, "getMemoryMaxUsage", >>>> newMemoryMaxUsage, >>>> 593 memoryMaxUsage); >>>> >>>> As to the bug. It suggests the memoryUsage code causes problems, >>>> not >>>> memoryMaxUsage. >>>> >>>> 587 // allocate memory in a loop and check more than once >>>> for new >>>> values >>>> 588 // otherwise we might see seldom the effect of >>>> decreasing new >>>> memory values >>>> 589 // e.g. because the system could free up memory >>>> 590 byte[][] bytes = new byte[32][]; >>>> 591 for (int i = 0; i < 32; i++) { >>>> 592 bytes[i] = new byte[8*1024*1024]; >>>> 593 newMemoryMaxUsage = metrics.getMemoryMaxUsage(); >>>> 594 newMemoryUsage = metrics.getMemoryUsage(); >>>> 595 if (newMemoryMaxUsage > memoryMaxUsage && >>>> newMemoryUsage > memoryUsage) { >>>> 596 break; >>>> 597 } >>>> >>>> Do we really need to call metrics.getMemoryMaxUsage() in that >>>> loop? I'd >>>> expect for the following code to work more reliably as the max >>>> usage is >>>> supposed to capture the high water mark. If memoryMaxUsage ever >>>> decreases, it's a bug in the cgroups accounting system right? >>>> >>>> byte[][] bytes = new byte[32][]; >>>> for (int i = 0; i < 32; i++) { >>>> bytes[i] = new byte[8*1024*1024]; >>>> newMemoryUsage = metrics.getMemoryUsage(); >>>> if (newMemoryUsage > memoryUsage) { >>>> break; >>>> } >>>> } >>>> newMemoryMaxUsage = metrics.getMemoryMaxUsage(); >>>> >>>> // assert things >>>> >>>> Perhaps even assert prior the loop: >>>> >>>> if (memoryMaxUsage < memoryUsage) { >>>> throw new RuntimeException("cgroup accounting bug?"); >>>> } >>>> >>>> Thanks, >>>> Severin > From matthias.baesken at sap.com Wed Aug 28 14:18:08 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 28 Aug 2019 14:18:08 +0000 Subject: RFR: [XS] 8229284: [TESTBUG] jdk/internal/platform/cgroup/TestCgroupMetrics.java fails for - memory:getMemoryUsage In-Reply-To: References: Message-ID: > Should you continue waiting in the loop until BOTH the new usage and max > usage exceed their initial values? Hi Bob, the current coding does not do it . It checks for "<" to fail . Please see the current coding : 583 long memoryMaxUsage = metrics.getMemoryMaxUsage(); 584 long memoryUsage = metrics.getMemoryUsage(); 586 byte[] bb = new byte[64*1024*1024]; // 64M 587 588 long newMemoryMaxUsage = metrics.getMemoryMaxUsage(); 589 long newMemoryUsage = metrics.getMemoryUsage(); 590 591 if(newMemoryMaxUsage < memoryMaxUsage) { 592 fail(SubSystem.MEMORY, "getMemoryMaxUsage", newMemoryMaxUsage, 593 memoryMaxUsage); 594 } 595 596 if(newMemoryUsage < memoryUsage) { 597 fail(SubSystem.MEMORY, "getMemoryUsage", newMemoryUsage, memoryUsage); 598 } 599 } My change does not intend to change this logic , just does more allocations to make sure the current check works . Best regards, Matthias > -----Original Message----- > From: Bob Vandette > Sent: Mittwoch, 28. August 2019 15:24 > To: Baesken, Matthias > Cc: Severin Gehwolf ; hotspot- > dev at openjdk.java.net > Subject: Re: RFR: [XS] 8229284: [TESTBUG] > jdk/internal/platform/cgroup/TestCgroupMetrics.java fails for - > memory:getMemoryUsage > > Should you continue waiting in the loop until BOTH the new usage and max > usage exceed their > initial values? > > Bob. > > > > On Aug 28, 2019, at 8:39 AM, Baesken, Matthias > wrote: > > > > Hi Severin, I changed the fail() - calls and the newMemoryMaxUsage > handling. > > New webrev : > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8229284.5/ > > > > > > Best regards, Matthias > > > > > >> > >> On Thu, 2019-08-15 at 16:08 +0000, Baesken, Matthias wrote: > >>> https://bugs.openjdk.java.net/browse/JDK-8229284 > >>> > >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8229284.3/ > >> > >> Hmm, unrelated to this bug, but still an issue: > >> > >> It appears the failure message is bogus when the test fails. It should > >> be: > >> > >> java.lang.RuntimeException: Test failed for - memory:getMemoryUsage, > >> expected [56200986624], got [56019386368] > >> > >> I.e. the old/new values need to be swapped here: > >> > >> 597 fail(SubSystem.MEMORY, "getMemoryUsage", > >> newMemoryUsage, memoryUsage); > >> > >> Same for the getMemoryMaxUsage() fail: > >> > >> 592 fail(SubSystem.MEMORY, "getMemoryMaxUsage", > >> newMemoryMaxUsage, > >> 593 memoryMaxUsage); > >> > >> As to the bug. It suggests the memoryUsage code causes problems, not > >> memoryMaxUsage. > >> > >> 587 // allocate memory in a loop and check more than once for new > >> values > >> 588 // otherwise we might see seldom the effect of decreasing new > >> memory values > >> 589 // e.g. because the system could free up memory > >> 590 byte[][] bytes = new byte[32][]; > >> 591 for (int i = 0; i < 32; i++) { > >> 592 bytes[i] = new byte[8*1024*1024]; > >> 593 newMemoryMaxUsage = metrics.getMemoryMaxUsage(); > >> 594 newMemoryUsage = metrics.getMemoryUsage(); > >> 595 if (newMemoryMaxUsage > memoryMaxUsage && > >> newMemoryUsage > memoryUsage) { > >> 596 break; > >> 597 } > >> > >> Do we really need to call metrics.getMemoryMaxUsage() in that loop? I'd > >> expect for the following code to work more reliably as the max usage is > >> supposed to capture the high water mark. If memoryMaxUsage ever > >> decreases, it's a bug in the cgroups accounting system right? > >> > >> byte[][] bytes = new byte[32][]; > >> for (int i = 0; i < 32; i++) { > >> bytes[i] = new byte[8*1024*1024]; > >> newMemoryUsage = metrics.getMemoryUsage(); > >> if (newMemoryUsage > memoryUsage) { > >> break; > >> } > >> } > >> newMemoryMaxUsage = metrics.getMemoryMaxUsage(); > >> > >> // assert things > >> > >> Perhaps even assert prior the loop: > >> > >> if (memoryMaxUsage < memoryUsage) { > >> throw new RuntimeException("cgroup accounting bug?"); > >> } > >> > >> Thanks, > >> Severin > > From matthias.baesken at sap.com Wed Aug 28 14:24:06 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 28 Aug 2019 14:24:06 +0000 Subject: RFR [XS]: 8229370: make jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java more stable In-Reply-To: <431d82f5-bea7-192e-3fcb-08888f2c6a42@oracle.com> References: <9f1e22b3-14c9-ecb1-e0b0-d6c19fa02a4e@oracle.com> <5D6596DD.5090602@oracle.com> <0a87d9fc-f7cf-26e1-cf1c-1914eec68fc3@oracle.com> <74db647a-ef7d-2064-16af-e838d22d608e@oracle.com> <431d82f5-bea7-192e-3fcb-08888f2c6a42@oracle.com> Message-ID: Hi David , I could add some optional UL logging to see what happens. Maybe the OS counters that are fetched by os_perf are not that reliable on some kernels . Best regards, Matthias > > Hi Matthias, > > On 28/08/2019 10:02 pm, Baesken, Matthias wrote: > > Hi David, thanks for reaching out to the net folks. > > > > I use now the stream of InetAddresses from > NetworkInterface.networkInterfaces().flatMap(NetworkInterface::inetAddr > esses) ; > > > > However on the machine where I noticed the issue , I still have to do a > couple of retries . > > Just one send to the stream of InetAddresses from > NetworkInterface.networkInterfaces().flatMap(NetworkInterface::inetAddr > esses) does not always give > > the expected result ? . > > That doesn't make sense to me, if one of the interfaces is the real > network interface and we write to the real IP address. I think we need > to add some diagnostics to see exactly which interface and IP address we > are writing to, and then see what each interface reports on the read > back of the data. > > Thanks, > David > > > New webrev : > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8229370.2/ > > > > > > Thanks, Matthias > > From bob.vandette at oracle.com Wed Aug 28 14:55:27 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Wed, 28 Aug 2019 10:55:27 -0400 Subject: RFR: [XS] 8229284: [TESTBUG] jdk/internal/platform/cgroup/TestCgroupMetrics.java fails for - memory:getMemoryUsage In-Reply-To: References: Message-ID: <0ADBDBD2-964A-4432-84A2-C96440861FCF@oracle.com> > On Aug 28, 2019, at 10:18 AM, Baesken, Matthias wrote: > >> Should you continue waiting in the loop until BOTH the new usage and max >> usage exceed their initial values? > > > Hi Bob, the current coding does not do it . It checks for "<" to fail . > Please see the current coding : > > 583 long memoryMaxUsage = metrics.getMemoryMaxUsage(); > 584 long memoryUsage = metrics.getMemoryUsage(); > > 586 byte[] bb = new byte[64*1024*1024]; // 64M > 587 > 588 long newMemoryMaxUsage = metrics.getMemoryMaxUsage(); > 589 long newMemoryUsage = metrics.getMemoryUsage(); > > 590 > 591 if(newMemoryMaxUsage < memoryMaxUsage) { > 592 fail(SubSystem.MEMORY, "getMemoryMaxUsage", newMemoryMaxUsage, > 593 memoryMaxUsage); > 594 } > 595 > 596 if(newMemoryUsage < memoryUsage) { > 597 fail(SubSystem.MEMORY, "getMemoryUsage", newMemoryUsage, memoryUsage); > 598 } > 599 } > > My change does not intend to change this logic , just does more allocations to make sure the current check works . Yes, your change is clearly an improvement. I just think the original logic is weak and could have been improved at the same time. You have a review from Severin so feel free to push what you?ve got. Bob. > > > Best regards, Matthias > > > >> -----Original Message----- >> From: Bob Vandette >> Sent: Mittwoch, 28. August 2019 15:24 >> To: Baesken, Matthias >> Cc: Severin Gehwolf ; hotspot- >> dev at openjdk.java.net >> Subject: Re: RFR: [XS] 8229284: [TESTBUG] >> jdk/internal/platform/cgroup/TestCgroupMetrics.java fails for - >> memory:getMemoryUsage >> >> Should you continue waiting in the loop until BOTH the new usage and max >> usage exceed their >> initial values? >> >> Bob. >> >> >>> On Aug 28, 2019, at 8:39 AM, Baesken, Matthias >> wrote: >>> >>> Hi Severin, I changed the fail() - calls and the newMemoryMaxUsage >> handling. >>> New webrev : >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8229284.5/ >>> >>> >>> Best regards, Matthias >>> >>> >>>> >>>> On Thu, 2019-08-15 at 16:08 +0000, Baesken, Matthias wrote: >>>>> https://bugs.openjdk.java.net/browse/JDK-8229284 >>>>> >>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8229284.3/ >>>> >>>> Hmm, unrelated to this bug, but still an issue: >>>> >>>> It appears the failure message is bogus when the test fails. It should >>>> be: >>>> >>>> java.lang.RuntimeException: Test failed for - memory:getMemoryUsage, >>>> expected [56200986624], got [56019386368] >>>> >>>> I.e. the old/new values need to be swapped here: >>>> >>>> 597 fail(SubSystem.MEMORY, "getMemoryUsage", >>>> newMemoryUsage, memoryUsage); >>>> >>>> Same for the getMemoryMaxUsage() fail: >>>> >>>> 592 fail(SubSystem.MEMORY, "getMemoryMaxUsage", >>>> newMemoryMaxUsage, >>>> 593 memoryMaxUsage); >>>> >>>> As to the bug. It suggests the memoryUsage code causes problems, not >>>> memoryMaxUsage. >>>> >>>> 587 // allocate memory in a loop and check more than once for new >>>> values >>>> 588 // otherwise we might see seldom the effect of decreasing new >>>> memory values >>>> 589 // e.g. because the system could free up memory >>>> 590 byte[][] bytes = new byte[32][]; >>>> 591 for (int i = 0; i < 32; i++) { >>>> 592 bytes[i] = new byte[8*1024*1024]; >>>> 593 newMemoryMaxUsage = metrics.getMemoryMaxUsage(); >>>> 594 newMemoryUsage = metrics.getMemoryUsage(); >>>> 595 if (newMemoryMaxUsage > memoryMaxUsage && >>>> newMemoryUsage > memoryUsage) { >>>> 596 break; >>>> 597 } >>>> >>>> Do we really need to call metrics.getMemoryMaxUsage() in that loop? I'd >>>> expect for the following code to work more reliably as the max usage is >>>> supposed to capture the high water mark. If memoryMaxUsage ever >>>> decreases, it's a bug in the cgroups accounting system right? >>>> >>>> byte[][] bytes = new byte[32][]; >>>> for (int i = 0; i < 32; i++) { >>>> bytes[i] = new byte[8*1024*1024]; >>>> newMemoryUsage = metrics.getMemoryUsage(); >>>> if (newMemoryUsage > memoryUsage) { >>>> break; >>>> } >>>> } >>>> newMemoryMaxUsage = metrics.getMemoryMaxUsage(); >>>> >>>> // assert things >>>> >>>> Perhaps even assert prior the loop: >>>> >>>> if (memoryMaxUsage < memoryUsage) { >>>> throw new RuntimeException("cgroup accounting bug?"); >>>> } >>>> >>>> Thanks, >>>> Severin >>> > From martin.doerr at sap.com Wed Aug 28 15:17:40 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 28 Aug 2019 15:17:40 +0000 Subject: jdk11 - 8214315: G1: fatal error: acquiring lock SATB_Q_FL_lock/1 out of order with lock tty_lock/0 In-Reply-To: References: Message-ID: Hi Matthias, looks like only the mutex.hpp part didn't apply automatically due to context changes (JDK-8213708). So your version looks good. Best regards, Martin > -----Original Message----- > From: hotspot-dev On Behalf Of > Baesken, Matthias > Sent: Mittwoch, 28. August 2019 15:40 > To: 'hotspot-dev at openjdk.java.net' > Subject: jdk11 - 8214315: G1: fatal error: acquiring lock SATB_Q_FL_lock/1 out > of order with lock tty_lock/0 > > Hello, please review this downport of 8214315 to jdk11u-dev . > It turned out we need this change as a prerequisite for > > https://bugs.openjdk.java.net/browse/JDK-8224958 > > > The jdk/jdk - patch applies mostly without a lot of adjustments . > > > > Webrev for 11 and original bug : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8214315_11udev.0/ > > https://bugs.openjdk.java.net/browse/JDK-8214315 > > > original jdk/jdk change was : > > http://hg.openjdk.java.net/jdk/jdk/rev/bf2f2560dd53 > > > > Thanks and best regards, Matthias > From dean.long at oracle.com Wed Aug 28 16:51:21 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 28 Aug 2019 09:51:21 -0700 Subject: RFR: 8229797: [JVMCI] Clean up no longer used JVMCI::dependencies_invalid value. In-Reply-To: References: Message-ID: Looks good. dl On 8/27/19 7:25 PM, Xiaohong Gong (Arm Technology China) wrote: > Hi, > > Please help to review this jvmci patch: > Webrew: http://cr.openjdk.java.net/~pli/rfr/8229797/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8229797 > > This patch fix issue: https://github.com/oracle/graal/issues/1587. > The loading of new classes can cause dependencies to become false, which requires the dependent > nmethods to be discarded and deoptimized. So if validating dependencies fails, it should make the > result to be JVMCI::dependencies_failed, which makes jvmci throw the BailoutException. > The invalid dependencies happen at the time of installation without any intervening modification of > the system dictionary. So as the system dictionary modification optimization has been removed, the > compiler can not know whether the failed dependencies are triggered by class reloading or not. It's > better to use dependencies_failed to mark the result. > > Thanks, > Xiaohong Gong From mikhailo.seledtsov at oracle.com Wed Aug 28 17:02:15 2019 From: mikhailo.seledtsov at oracle.com (mikhailo.seledtsov at oracle.com) Date: Wed, 28 Aug 2019 10:02:15 -0700 Subject: RFR: [XS] 8229284: [TESTBUG] jdk/internal/platform/cgroup/TestCgroupMetrics.java fails for - memory:getMemoryUsage In-Reply-To: References: Message-ID: <858a8517-77ab-21c8-9a0a-db903ac644a2@oracle.com> +1 On 8/28/19 5:52 AM, Severin Gehwolf wrote: > On Wed, 2019-08-28 at 12:39 +0000, Baesken, Matthias wrote: >> http://cr.openjdk.java.net/~mbaesken/webrevs/8229284.5/ > Looks good. > > Thanks, > Severin > From coleen.phillimore at oracle.com Wed Aug 28 21:40:30 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 28 Aug 2019 17:40:30 -0400 Subject: RFR: 8229797: [JVMCI] Clean up no longer used JVMCI::dependencies_invalid value. In-Reply-To: References: Message-ID: <451bc599-ac8c-c648-35db-a368f46a74d1@oracle.com> With my limited knowledge of Graal, this looks good.? It's consistent with the other JITs now. Coleen On 8/28/19 12:51 PM, dean.long at oracle.com wrote: > Looks good. > > dl > > On 8/27/19 7:25 PM, Xiaohong Gong (Arm Technology China) wrote: >> Hi, >> >> ?? Please help to review this jvmci patch: >> ?? Webrew: http://cr.openjdk.java.net/~pli/rfr/8229797/webrev.00/ >> ?? JBS: https://bugs.openjdk.java.net/browse/JDK-8229797 >> >> ?? This patch fix issue: https://github.com/oracle/graal/issues/1587. >> ?? The loading of new classes can cause dependencies to become false, >> which requires the dependent >> nmethods to be discarded and deoptimized. So if validating >> dependencies fails, it should make the >> result to be JVMCI::dependencies_failed, which makes jvmci throw the >> BailoutException. >> ?? The invalid dependencies happen at the time of installation >> without any intervening modification of >> the system dictionary. So as the system dictionary modification >> optimization has been removed, the >> compiler can not know whether the failed dependencies are triggered >> by class reloading or not. It's >> better to use dependencies_failed to mark the result. >> >> Thanks, >> Xiaohong Gong > From david.holmes at oracle.com Thu Aug 29 02:16:04 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 29 Aug 2019 12:16:04 +1000 Subject: RFR [XS]: 8229370: make jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java more stable In-Reply-To: References: <9f1e22b3-14c9-ecb1-e0b0-d6c19fa02a4e@oracle.com> <5D6596DD.5090602@oracle.com> <0a87d9fc-f7cf-26e1-cf1c-1914eec68fc3@oracle.com> <74db647a-ef7d-2064-16af-e838d22d608e@oracle.com> <431d82f5-bea7-192e-3fcb-08888f2c6a42@oracle.com> Message-ID: On 29/08/2019 12:24 am, Baesken, Matthias wrote: > Hi David , I could add some optional UL logging to see what happens. I just want to see more visibility at the test level to ensure it is finding the interfaces and addresses I would expect it to find. David > Maybe the OS counters that are fetched by os_perf are not that reliable on some kernels . > > > Best regards, Matthias > > > >> >> Hi Matthias, >> >> On 28/08/2019 10:02 pm, Baesken, Matthias wrote: >>> Hi David, thanks for reaching out to the net folks. >>> >>> I use now the stream of InetAddresses from >> NetworkInterface.networkInterfaces().flatMap(NetworkInterface::inetAddr >> esses) ; >>> >>> However on the machine where I noticed the issue , I still have to do a >> couple of retries . >>> Just one send to the stream of InetAddresses from >> NetworkInterface.networkInterfaces().flatMap(NetworkInterface::inetAddr >> esses) does not always give >>> the expected result ? . >> >> That doesn't make sense to me, if one of the interfaces is the real >> network interface and we write to the real IP address. I think we need >> to add some diagnostics to see exactly which interface and IP address we >> are writing to, and then see what each interface reports on the read >> back of the data. >> >> Thanks, >> David >> >>> New webrev : >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8229370.2/ >>> >>> >>> Thanks, Matthias >>> > From erik.osterlund at oracle.com Thu Aug 29 10:01:47 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Thu, 29 Aug 2019 12:01:47 +0200 Subject: RFR(L): 8226705: [REDO] Deoptimize with handshakes In-Reply-To: <7089f41c-be3e-840b-b640-403d925ac272@oracle.com> References: <1e83f10c-d300-0511-e6df-ee45463807ec@oracle.com> <7089f41c-be3e-840b-b640-403d925ac272@oracle.com> Message-ID: Hi Robbin, Glad to see this work making it back again. Last time this patch was proposed, there were no guards against non-monotonic nmethod state transitions. Today there are (since https://bugs.openjdk.java.net/browse/JDK-8224674). In other words, if you call make_not_entrant() on an nmethod that has racingly become zombie, it is today impossible to resurrect that nmethod. Instead, make_not_entrant() will return false. In particular, I think that is what the following code in the patch is guarding against (in codeCache.cpp): 1150 // Mark methods for deopt (if safe or possible). 1151 void CodeCache::mark_all_nmethods_for_deoptimization() { 1152 MutexLocker mu(CodeCache_lock, Mutex::_no_safepoint_check_flag); 1153 CompiledMethodIterator iter(CompiledMethodIterator::only_alive_and_not_unloading); 1154 while(iter.next()) { 1155 CompiledMethod* nm = iter.method(); 1156 if (!nm->method()->is_method_handle_intrinsic() && 1157 !nm->is_not_installed() && 1158 nm->is_in_use() && 1159 !nm->is_native_method()) { 1160 // Intrinsics and native methods are never deopted. A method that is 1161 // not installed yet or is not in use is not safe to deopt; the 1162 // is_in_use() check covers the not_entrant and not zombie cases. 1163 // Note: A not_entrant method can become a zombie at anytime if it was 1164 // made not_entrant before the previous safepoint/handshake. 1165 nm->mark_for_deoptimization(); 1166 } 1167 } 1168 } In fact, this code is also guarding against is_not_installed nmethods (which was introduced as a new function). If we find that an nmethod is bad and say it needs deoptimization, and that nmethod is just about to get installed, it seems to me that skipping that nmethod and not making it not entrant is really dangerous and will eventually lead to a crash. Because in ciEnv.cpp we set_code to the about to be installed nmethod, and it will get called without anything stopping the invalid code from being executed by mutators, and it was being invalidated for a reason. So basically we really do have to make these not entrant, or we will blow up. I guess the reason you needed this check is because make_in_use() doesn't check what the current state is, causing monotonicity problems, making a potentially already not entrant nmethod become in_use, eventually blowing up asserts and probably the VM. Regrettably, make_in_use() still does that, because I had no need for changing it to use nmethod::try_transition in 8224674, nobody previously could find these nmethods. In retrospect, not changing that was a bit silly. So if we just change make_in_use() to use nmethod::try_transition instead, then you can remove the !is_not_installed check... which I argue we have to do. The reason we never ran in to this before is because we made the nmethods not entrant in a safepoint, and between making an nmethod and making it in_use, there is no safepoint check, so they were never observed in this state. ... and similarly here: 1192 if (nm->is_marked_for_deoptimization() && nm->is_in_use()) { 1193 // only_alive_and_not_unloading() can return not_entrant nmethods. 1194 // A not_entrant method can become a zombie at anytime if it was 1195 // made not_entrant before the previous safepoint/handshake. The 1196 // is_in_use() check covers the not_entrant and not zombie cases 1197 // that have become true after the method was marked for deopt. 1198 nm->make_not_entrant(); 1199 } ... we now don't need the guard against is_in_use() here. For what I propose to work out, we need to change nmethod::make_in_use to use nmethod::try_transition, and AOTCompiledMethod::make_entrant() needs to also return false when encountering a not_entrant nmethod, enforcing monotonicity, instead of asserting about that. AOT methods may turn not_in_use AOT methods to in_use, but not not_entrant to in_use. Once not_entrant, an AOT methods should remain not entrant forever. So basically, these guards are for something that used to be racy and dangerous due to the lack of guards inside of the state transitions, and today that is completely harmless, as the proper guards are in the attempts to change state. I would prefer to remove these guards, as it is confusing to the reader that we are guarding against a problem that can't happen. So I think you can remove the various checks for what state the nmethod is in, the comments describing races, and just keep the checks if it's a method handle intrinsic or native method. In deoptimize.cpp, the fetch_unroll_info_helper function has moved down, making it difficult to review as shows the code delta as if everything changed. So I can't see what actually changed there. :( Would you mind moving that code back so the webrev shows what changed there? Thanks, /Erik On 2019-08-28 11:57, Robbin Ehn wrote: > Hi, hotspot-dev was the intended list. > > Thanks, Robbin > > On 2019-08-28 09:30, Robbin Ehn wrote: >> Hi all, please consider, >> >> To get away from the issues of us revoking in the handshake, but >> before deopt >> the locks get re-biased before we hit deopt handler, we instead revoke >> in deopt >> handler. >> The deopt handler have a JRT_BLOCK/_END which can safepoint so we >> revoke after >> that but before we start looking at the monitors, with a >> NoSafepointVerifier. >> >> Here is the previous changeset on top of jdk/jdk tip but due to merge >> conflicts >> some pieces did not apply: >> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-8221734-baseline/webrev/ >> >> So this is what was reviewed. >> >> The rebase (merge conflict resolutions) and 8224795 bug fix : >> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-rebase/webrev/ >> >> Bug 8224795 fix is here: >> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-rebase/webrev/src/hotspot/share/code/nmethod.cpp.sdiff.html >> >> >> After this we have the same functionally as the reverted change-set. >> >> Here is the changes for doing the revoke in deopt handler instead: >> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-revoke-on-deopt/webrev/ >> >> >> This code was messy adding the deopt revocation in 3 places made it >> worse. >> Here is a refactoring of that code. (also removed a dead method in >> biasedlocking): >> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-refactor/webrev/ >> >> And here is full: >> http://cr.openjdk.java.net/~rehn/8226705/v1/full/webrev/ >> >> Also a full squashed patch file: >> http://cr.openjdk.java.net/~rehn/8226705/v1/full/full.patch >> >> Latest test run I did t1-t6, Linux/Windows x64 have passed, MacOSX still >> running. >> >> Thanks, Robbin >> >> From robbin.ehn at oracle.com Thu Aug 29 12:25:45 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Thu, 29 Aug 2019 14:25:45 +0200 Subject: RFR(L): 8226705: [REDO] Deoptimize with handshakes In-Reply-To: References: <1e83f10c-d300-0511-e6df-ee45463807ec@oracle.com> <7089f41c-be3e-840b-b640-403d925ac272@oracle.com> Message-ID: <75e10e47-892e-f36d-6c2c-0f54ea93933f@oracle.com> Hi Erik, thanks for having a look. Just some short answers and questions. On 8/29/19 12:01 PM, Erik ?sterlund wrote: > Hi Robbin, > > Glad to see this work making it back again. Last time this patch was proposed, > there were no guards against non-monotonic nmethod state transitions. Today > there are (since https://bugs.openjdk.java.net/browse/JDK-8224674). In other > words, if you call make_not_entrant() on an nmethod that has racingly become > zombie, it is today impossible to resurrect that nmethod. Instead, > make_not_entrant() will return false. Great, I'll have a look. > > In particular, I think that is what the following code in the patch is guarding > against (in codeCache.cpp): > > 1150 // Mark methods for deopt (if safe or possible). > 1151 void CodeCache::mark_all_nmethods_for_deoptimization() { > 1152?? MutexLocker mu(CodeCache_lock, Mutex::_no_safepoint_check_flag); > 1153?? CompiledMethodIterator > iter(CompiledMethodIterator::only_alive_and_not_unloading); > 1154?? while(iter.next()) { > 1155???? CompiledMethod* nm = iter.method(); > 1156???? if (!nm->method()->is_method_handle_intrinsic() && > 1157???????? !nm->is_not_installed() && > 1158???????? nm->is_in_use() && > 1159???????? !nm->is_native_method()) { > 1160?????? // Intrinsics and native methods are never deopted. A method that is > 1161?????? // not installed yet or is not in use is not safe to deopt; the > 1162?????? // is_in_use() check covers the not_entrant and not zombie cases. > 1163?????? // Note: A not_entrant method can become a zombie at anytime if it was > 1164?????? // made not_entrant before the previous safepoint/handshake. > 1165?????? nm->mark_for_deoptimization(); > 1166???? } > 1167?? } > 1168 } > > In fact, this code is also guarding against is_not_installed nmethods (which was > introduced as a new function). If we find that an nmethod is bad and say it > needs deoptimization, and that nmethod is just about to get installed, it seems > to me that skipping that nmethod and not making it not entrant is really > dangerous and will eventually lead to a crash. Because in ciEnv.cpp we set_code > to the about to be installed nmethod, and it will get called without anything > stopping the invalid code from being executed by mutators, and it was being > invalidated for a reason. So basically we really do have to make these not > entrant, or we will blow up. > > I guess the reason you needed this check is because make_in_use() doesn't check > what the current state is, causing monotonicity problems, making a potentially > already not entrant nmethod become in_use, eventually blowing up asserts and > probably the VM. Regrettably, make_in_use() still does that, because I had no > need for changing it to use nmethod::try_transition in 8224674, nobody > previously could find these nmethods. In retrospect, not changing that was a bit > silly. So if we just change make_in_use() to use nmethod::try_transition > instead, then you can remove the !is_not_installed check... which I argue we > have to do. The reason we never ran in to this before is because we made the > nmethods not entrant in a safepoint, and between making an nmethod and making it > in_use, there is no safepoint check, so they were never observed in this state. > Yes, thread A is creating a new method X, it have state not installed. If we make method X not entrant, Thread A will flip it back to in_use, which bad and we crash. mark_all_nmethods_for_deoptimization is a test method used in the new jtreg test, which is the only use (I see dtrace have some hack to use it, it can crash the vm). > ... and similarly here: > > 1192???? if (nm->is_marked_for_deoptimization() && nm->is_in_use()) { > 1193?????? // only_alive_and_not_unloading() can return not_entrant nmethods. > 1194?????? // A not_entrant method can become a zombie at anytime if it was > 1195?????? // made not_entrant before the previous safepoint/handshake. The > 1196?????? // is_in_use() check covers the not_entrant and not zombie cases > 1197?????? // that have become true after the method was marked for deopt. > 1198?????? nm->make_not_entrant(); > 1199???? } > > ... we now don't need the guard against is_in_use() here. Here we don't need that, but we don't need !nm->is_not_entrant() either, since it would return false as you say!? If we should have an early filter it think nm->is_in_use() is clearer than: not not entrant ;) (since the not_installed is normally not seen here) > > For what I propose to work out, we need to change nmethod::make_in_use to use > nmethod::try_transition, and AOTCompiledMethod::make_entrant() needs to also > return false when encountering a not_entrant nmethod, enforcing monotonicity, > instead of asserting about that. AOT methods may turn not_in_use AOT methods to > in_use, but not not_entrant to in_use. Once not_entrant, an AOT methods should > remain not entrant forever. The only time we see methods which are not installed should be methods that will never be deoptimize (except when calling the test method mark_all_nmethods_for_deoptimization), intrinsic and native. And if I remember correctly make_in_use is called in a constructor which requires extra error-handling. Construction would fail if try_transition failed. The assumption about these 'never deopted' methods seem to be just that :) > > So basically, these guards are for something that used to be racy and dangerous > due to the lack of guards inside of the state transitions, and today that is > completely harmless, as the proper guards are in the attempts to change state. I > would prefer to remove these guards, as it is confusing to the reader that we > are guarding against a problem that can't happen. So I think you can remove the > various checks for what state the nmethod is in, the comments describing races, > and just keep the checks if it's a method handle intrinsic or native method. I'll revisit this. Was a few months since I did this. > > In deoptimize.cpp, the fetch_unroll_info_helper function has moved down, making > it difficult to review as shows the code delta as if everything changed. So I > can't see what actually changed there. :( Would you mind moving that code back > so the webrev shows what changed there? I have inserted two new static functions before fetch_unroll_info_helper, since code from fetch_unroll_info_helper are in these functions diff do this. They are static function they are best off before, and putting after them I don't think would help the diff tool + I need fwd decl. Suggestion? Thanks, Robbin > > Thanks, > /Erik > > On 2019-08-28 11:57, Robbin Ehn wrote: >> Hi, hotspot-dev was the intended list. >> >> Thanks, Robbin >> >> On 2019-08-28 09:30, Robbin Ehn wrote: >>> Hi all, please consider, >>> >>> To get away from the issues of us revoking in the handshake, but before deopt >>> the locks get re-biased before we hit deopt handler, we instead revoke in deopt >>> handler. >>> The deopt handler have a JRT_BLOCK/_END which can safepoint so we revoke after >>> that but before we start looking at the monitors, with a NoSafepointVerifier. >>> >>> Here is the previous changeset on top of jdk/jdk tip but due to merge conflicts >>> some pieces did not apply: >>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-8221734-baseline/webrev/ >>> So this is what was reviewed. >>> >>> The rebase (merge conflict resolutions) and 8224795 bug fix : >>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-rebase/webrev/ >>> >>> Bug 8224795 fix is here: >>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-rebase/webrev/src/hotspot/share/code/nmethod.cpp.sdiff.html >>> >>> >>> After this we have the same functionally as the reverted change-set. >>> >>> Here is the changes for doing the revoke in deopt handler instead: >>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-revoke-on-deopt/webrev/ >>> >>> This code was messy adding the deopt revocation in 3 places made it worse. >>> Here is a refactoring of that code. (also removed a dead method in >>> biasedlocking): >>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-refactor/webrev/ >>> >>> And here is full: >>> http://cr.openjdk.java.net/~rehn/8226705/v1/full/webrev/ >>> >>> Also a full squashed patch file: >>> http://cr.openjdk.java.net/~rehn/8226705/v1/full/full.patch >>> >>> Latest test run I did t1-t6, Linux/Windows x64 have passed, MacOSX still >>> running. >>> >>> Thanks, Robbin >>> >>> From stefan.karlsson at oracle.com Thu Aug 29 13:07:17 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Thu, 29 Aug 2019 15:07:17 +0200 Subject: RFR: 8224815: Remove non-GC uses of CollectedHeap::is_in_reserved() In-Reply-To: <510179ba-415d-a615-e08d-2899a7225f50@oracle.com> References: <510179ba-415d-a615-e08d-2899a7225f50@oracle.com> Message-ID: <5a3f7aa6-ef41-d595-145b-7decc7576380@oracle.com> Hi Erik, On 2019-08-09 09:43, Erik ?sterlund wrote: > Hi, > > The CollectedHeap::is_in_reserved() function assumes the GC has a > contiguous heap. This might not be the case, and hence the shared code > should not make assumptions about that. It should use > CollectedHeap::is_in() instead. > > However, CompressedOops inherently assumes the heap is contiguous, so I > let it know about the reserved region. > > This patch depends on 8229278 and 8229189, which are both out for review > right now. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8224815 > > Webrev: > http://cr.openjdk.java.net/~eosterlund/8224815/webrev.00/ I think this looks good, but have a few cleanups that I'd like to suggest: http://cr.openjdk.java.net/~stefank/8224815/webrev.01.review.00/ 1) Changed some parameters to accept void* to get rid of some casts 2) Replaced address with HeapWord* in GC code. 3) Moved the code that was moved to initialize_reserved_region and moved it into Universe::reserve_heap. I could therefore restore the location of the initialize_reserved_region calls. Fixed a test that relied on the logging order. 4) Moved the heap address range MemRegion out of NarrowPtrStruct into CompressedOops 5) Replaced some DEBUG_ONLY with NOT_DEBUG_RETURN. 6) Minor cleanups I ran this through tier1. It's a bit annoying that we still have CollectedHeap::_reserved, but I understand why you left it for now. However, I see that the Serviceability Agent uses that field. Did you think about if that affects ZGC support in SA in any way? Thanks, StefanK > > Thanks, > /Erik From erik.osterlund at oracle.com Thu Aug 29 13:20:40 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Thu, 29 Aug 2019 15:20:40 +0200 Subject: RFR: 8224815: Remove non-GC uses of CollectedHeap::is_in_reserved() In-Reply-To: <5a3f7aa6-ef41-d595-145b-7decc7576380@oracle.com> References: <510179ba-415d-a615-e08d-2899a7225f50@oracle.com> <5a3f7aa6-ef41-d595-145b-7decc7576380@oracle.com> Message-ID: Hi Stefan, Thanks for having an in-depth look at this patch. On 2019-08-29 15:07, Stefan Karlsson wrote: > Hi Erik, > > On 2019-08-09 09:43, Erik ?sterlund wrote: >> Hi, >> >> The CollectedHeap::is_in_reserved() function assumes the GC has a >> contiguous heap. This might not be the case, and hence the shared code >> should not make assumptions about that. It should use >> CollectedHeap::is_in() instead. >> >> However, CompressedOops inherently assumes the heap is contiguous, so >> I let it know about the reserved region. >> >> This patch depends on 8229278 and 8229189, which are both out for >> review right now. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8224815 >> >> Webrev: >> http://cr.openjdk.java.net/~eosterlund/8224815/webrev.00/ > > > I think this looks good, but have a few cleanups that I'd like to suggest: > > http://cr.openjdk.java.net/~stefank/8224815/webrev.01.review.00/ > > 1) Changed some parameters to accept void* to get rid of some casts > > 2) Replaced address with HeapWord* in GC code. > > 3) Moved the code that was moved to initialize_reserved_region and moved > it into Universe::reserve_heap. I could therefore restore the location > of the initialize_reserved_region calls. Fixed a test that relied on the > logging order. > > 4) Moved the heap address range MemRegion out of NarrowPtrStruct into > CompressedOops > > 5) Replaced some DEBUG_ONLY with NOT_DEBUG_RETURN. > > 6) Minor cleanups > > I ran this through tier1. Thank you for the bits. I think your improvements did make the code nicer, and I agree with all suggestions. > It's a bit annoying that we still have CollectedHeap::_reserved, but I > understand why you left it for now. However, I see that the > Serviceability Agent uses that field. Did you think about if that > affects ZGC support in SA in any way? Yeah it annoyed me a bit too. And no I haven't looked into what the SA does differently if you don't specify a reserve region. I will try to look into that. Thanks, /Erik > Thanks, > StefanK > >> >> Thanks, >> /Erik From matthias.baesken at sap.com Thu Aug 29 13:40:45 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 29 Aug 2019 13:40:45 +0000 Subject: RFR: 8224214: [AIX] Remove support for legacy xlc compiler Message-ID: Hello, please review the following change . For OpenJDK 13 we've moved to XLC 16 as required compiler. However we have still a lot of workarounds and checks in the codebase for the older xlc compilers. This changes removes such changes . Additionally it adjusts the compiler version check in hotspot/share/utilities/globalDefinitions_xlc.hpp and 2 typos in os_aix are fixed . When 8224214 was created a while ago , it was discussed on the mailing list : "we still set some '-qlanglvl' options for C++ which aren't supported by the new compiler [xlc16/xlclang++] either" . Those options generated lots of warnings , so they were removed already so no need to remove them in this change . ( In jdk11 which is built with xlc12 they can still be found : flags-cflags.m4:540: -qalias=noansi -qstrict -qtls=default -qlanglvl=c99vla \ flags-cflags.m4:541: -qlanglvl=noredefmac -qnortti -qnoeh -qignerrno" ) Bug/webrev : https://bugs.openjdk.java.net/browse/JDK-8224214 http://cr.openjdk.java.net/~mbaesken/webrevs/8224214.0/ Thanks, Matthias From martin.doerr at sap.com Thu Aug 29 14:18:38 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 29 Aug 2019 14:18:38 +0000 Subject: RFR: 8224214: [AIX] Remove support for legacy xlc compiler In-Reply-To: References: Message-ID: Hi Matthias, nice cleanup. Looks good to me. We can also require availability of xlclang++ in toolchain.m4. I think some of the changes only work with this compiler. Thanks, Martin > -----Original Message----- > From: hotspot-dev On Behalf Of > Baesken, Matthias > Sent: Donnerstag, 29. August 2019 15:41 > To: 'hotspot-dev at openjdk.java.net' ; > 'ppc-aix-port-dev at openjdk.java.net' > Subject: RFR: 8224214: [AIX] Remove support for legacy xlc compiler > > Hello, please review the following change . > For OpenJDK 13 we've moved to XLC 16 as required compiler. > However we have still a lot of workarounds and checks in the codebase for > the older xlc compilers. > This changes removes such changes . > > Additionally it adjusts the compiler version check in > hotspot/share/utilities/globalDefinitions_xlc.hpp > and 2 typos in os_aix are fixed . > > > When 8224214 was created a while ago , it was discussed on the mailing list > : > > "we still set some '-qlanglvl' options for C++ which aren't supported by the > new compiler [xlc16/xlclang++] either" . > Those options generated lots of warnings , so they were removed already > so no need to remove them in this change . > > ( In jdk11 which is built with xlc12 they can still be found : > flags-cflags.m4:540: -qalias=noansi -qstrict -qtls=default -qlanglvl=c99vla \ > flags-cflags.m4:541: -qlanglvl=noredefmac -qnortti -qnoeh -qignerrno" > ) > > > Bug/webrev : > > https://bugs.openjdk.java.net/browse/JDK-8224214 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8224214.0/ > > > Thanks, Matthias From matthias.baesken at sap.com Thu Aug 29 15:41:45 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 29 Aug 2019 15:41:45 +0000 Subject: RFR: 8224214: [AIX] Remove support for legacy xlc compiler In-Reply-To: References: Message-ID: Hi Martin, I agree about the m4 files . New webrev , this additionally touches toolchain.m4 and flags-cflags.m4 http://cr.openjdk.java.net/~mbaesken/webrevs/8224214.1/ Thanks, Matthias > -----Original Message----- > From: Doerr, Martin > Sent: Donnerstag, 29. August 2019 16:19 > To: Baesken, Matthias ; 'hotspot- > dev at openjdk.java.net' ; 'ppc-aix-port- > dev at openjdk.java.net' > Subject: RE: RFR: 8224214: [AIX] Remove support for legacy xlc compiler > > Hi Matthias, > > nice cleanup. Looks good to me. > > We can also require availability of xlclang++ in toolchain.m4. I think some of > the changes only work with this compiler. > > Thanks, > Martin > > > > -----Original Message----- > > From: hotspot-dev On Behalf > Of > > Baesken, Matthias > > Sent: Donnerstag, 29. August 2019 15:41 > > To: 'hotspot-dev at openjdk.java.net' ; > > 'ppc-aix-port-dev at openjdk.java.net' dev at openjdk.java.net> > > Subject: RFR: 8224214: [AIX] Remove support for legacy xlc compiler > > > > Hello, please review the following change . > > For OpenJDK 13 we've moved to XLC 16 as required compiler. > > However we have still a lot of workarounds and checks in the codebase > for > > the older xlc compilers. > > This changes removes such changes . > > > > Additionally it adjusts the compiler version check in > > hotspot/share/utilities/globalDefinitions_xlc.hpp > > and 2 typos in os_aix are fixed . > > > > > > When 8224214 was created a while ago , it was discussed on the mailing > list > > : > > > > "we still set some '-qlanglvl' options for C++ which aren't supported by the > > new compiler [xlc16/xlclang++] either" . > > Those options generated lots of warnings , so they were removed > already > > so no need to remove them in this change . > > > > ( In jdk11 which is built with xlc12 they can still be found : > > flags-cflags.m4:540: -qalias=noansi -qstrict -qtls=default -qlanglvl=c99vla \ > > flags-cflags.m4:541: -qlanglvl=noredefmac -qnortti -qnoeh -qignerrno" > > ) > > > > > > Bug/webrev : > > > > https://bugs.openjdk.java.net/browse/JDK-8224214 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8224214.0/ > > > > > > Thanks, Matthias From martin.doerr at sap.com Thu Aug 29 15:49:03 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 29 Aug 2019 15:49:03 +0000 Subject: RFR: 8224214: [AIX] Remove support for legacy xlc compiler In-Reply-To: References: Message-ID: Hi Matthias, thanks for the update. Looks good. Best regards, Martin > -----Original Message----- > From: Baesken, Matthias > Sent: Donnerstag, 29. August 2019 17:42 > To: Doerr, Martin ; 'hotspot- > dev at openjdk.java.net' ; 'ppc-aix-port- > dev at openjdk.java.net' > Subject: RE: RFR: 8224214: [AIX] Remove support for legacy xlc compiler > > Hi Martin, I agree about the m4 files . > New webrev , this additionally touches toolchain.m4 and flags-cflags.m4 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8224214.1/ > > Thanks, Matthias > > > -----Original Message----- > > From: Doerr, Martin > > Sent: Donnerstag, 29. August 2019 16:19 > > To: Baesken, Matthias ; 'hotspot- > > dev at openjdk.java.net' ; 'ppc-aix-port- > > dev at openjdk.java.net' > > Subject: RE: RFR: 8224214: [AIX] Remove support for legacy xlc compiler > > > > Hi Matthias, > > > > nice cleanup. Looks good to me. > > > > We can also require availability of xlclang++ in toolchain.m4. I think some of > > the changes only work with this compiler. > > > > Thanks, > > Martin > > > > > > > -----Original Message----- > > > From: hotspot-dev On Behalf > > Of > > > Baesken, Matthias > > > Sent: Donnerstag, 29. August 2019 15:41 > > > To: 'hotspot-dev at openjdk.java.net' ; > > > 'ppc-aix-port-dev at openjdk.java.net' > dev at openjdk.java.net> > > > Subject: RFR: 8224214: [AIX] Remove support for legacy xlc compiler > > > > > > Hello, please review the following change . > > > For OpenJDK 13 we've moved to XLC 16 as required compiler. > > > However we have still a lot of workarounds and checks in the codebase > > for > > > the older xlc compilers. > > > This changes removes such changes . > > > > > > Additionally it adjusts the compiler version check in > > > hotspot/share/utilities/globalDefinitions_xlc.hpp > > > and 2 typos in os_aix are fixed . > > > > > > > > > When 8224214 was created a while ago , it was discussed on the mailing > > list > > > : > > > > > > "we still set some '-qlanglvl' options for C++ which aren't supported by > the > > > new compiler [xlc16/xlclang++] either" . > > > Those options generated lots of warnings , so they were removed > > already > > > so no need to remove them in this change . > > > > > > ( In jdk11 which is built with xlc12 they can still be found : > > > flags-cflags.m4:540: -qalias=noansi -qstrict -qtls=default -qlanglvl=c99vla \ > > > flags-cflags.m4:541: -qlanglvl=noredefmac -qnortti -qnoeh -qignerrno" > > > ) > > > > > > > > > Bug/webrev : > > > > > > https://bugs.openjdk.java.net/browse/JDK-8224214 > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8224214.0/ > > > > > > > > > Thanks, Matthias From erik.osterlund at oracle.com Thu Aug 29 14:35:50 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Thu, 29 Aug 2019 16:35:50 +0200 Subject: RFR(L): 8226705: [REDO] Deoptimize with handshakes In-Reply-To: <75e10e47-892e-f36d-6c2c-0f54ea93933f@oracle.com> References: <1e83f10c-d300-0511-e6df-ee45463807ec@oracle.com> <7089f41c-be3e-840b-b640-403d925ac272@oracle.com> <75e10e47-892e-f36d-6c2c-0f54ea93933f@oracle.com> Message-ID: Hi Robbin, On 2019-08-29 14:25, Robbin Ehn wrote: > Hi Erik, thanks for having a look. > > Just some short answers and questions. > > On 8/29/19 12:01 PM, Erik ?sterlund wrote: >> Hi Robbin, >> >> Glad to see this work making it back again. Last time this patch was >> proposed, there were no guards against non-monotonic nmethod state >> transitions. Today there are (since >> https://bugs.openjdk.java.net/browse/JDK-8224674). In other words, if >> you call make_not_entrant() on an nmethod that has racingly become >> zombie, it is today impossible to resurrect that nmethod. Instead, >> make_not_entrant() will return false. > > Great, I'll have a look. > >> >> In particular, I think that is what the following code in the patch is >> guarding against (in codeCache.cpp): >> >> 1150 // Mark methods for deopt (if safe or possible). >> 1151 void CodeCache::mark_all_nmethods_for_deoptimization() { >> 1152?? MutexLocker mu(CodeCache_lock, Mutex::_no_safepoint_check_flag); >> 1153?? CompiledMethodIterator >> iter(CompiledMethodIterator::only_alive_and_not_unloading); >> 1154?? while(iter.next()) { >> 1155???? CompiledMethod* nm = iter.method(); >> 1156???? if (!nm->method()->is_method_handle_intrinsic() && >> 1157???????? !nm->is_not_installed() && >> 1158???????? nm->is_in_use() && >> 1159???????? !nm->is_native_method()) { >> 1160?????? // Intrinsics and native methods are never deopted. A >> method that is >> 1161?????? // not installed yet or is not in use is not safe to deopt; >> the >> 1162?????? // is_in_use() check covers the not_entrant and not zombie >> cases. >> 1163?????? // Note: A not_entrant method can become a zombie at >> anytime if it was >> 1164?????? // made not_entrant before the previous safepoint/handshake. >> 1165?????? nm->mark_for_deoptimization(); >> 1166???? } >> 1167?? } >> 1168 } >> >> In fact, this code is also guarding against is_not_installed nmethods >> (which was introduced as a new function). If we find that an nmethod >> is bad and say it needs deoptimization, and that nmethod is just about >> to get installed, it seems to me that skipping that nmethod and not >> making it not entrant is really dangerous and will eventually lead to >> a crash. Because in ciEnv.cpp we set_code to the about to be installed >> nmethod, and it will get called without anything stopping the invalid >> code from being executed by mutators, and it was being invalidated for >> a reason. So basically we really do have to make these not entrant, or >> we will blow up. >> >> I guess the reason you needed this check is because make_in_use() >> doesn't check what the current state is, causing monotonicity >> problems, making a potentially already not entrant nmethod become >> in_use, eventually blowing up asserts and probably the VM. >> Regrettably, make_in_use() still does that, because I had no need for >> changing it to use nmethod::try_transition in 8224674, nobody >> previously could find these nmethods. In retrospect, not changing that >> was a bit silly. So if we just change make_in_use() to use >> nmethod::try_transition instead, then you can remove the >> !is_not_installed check... which I argue we have to do. The reason we >> never ran in to this before is because we made the nmethods not >> entrant in a safepoint, and between making an nmethod and making it >> in_use, there is no safepoint check, so they were never observed in >> this state. >> > > Yes, thread A is creating a new method X, it have state not installed. > If we make method X not entrant, Thread A will flip it back to in_use, > which bad > and we crash. mark_all_nmethods_for_deoptimization is a test method used > in the > new jtreg test, which is the only use (I see dtrace have some hack to > use it, it > can crash the vm). Exactly. However, what you are missing here is that this does not happen only for the whitebox test, now that we do normal deopt with handshakes. Consider the following race. A compiler thread compiles a new nmethod. In this nmethod, it's assumed that a certain invoke_virtual callsite is completely monomorphic, and the compiler chooses to implement the callsite with a direct call, which is only valid given its monomorphism. The compilation finishes, and at the very end of the process, the code cache lock is grabbed, under which we allocate the new nmethod, verify the assumptions made (which still hold), inject entries in DependencyContexts so that if these assumptions change, we will deopt, and then unlock the code cache lock. The nmethod is now still in the state not_installed. What can happen now is that another thread loads a class that makes the callsite potentially megamorphic. Deopt is triggered, walking the dependency contexts under the CodeCache_lock, marking things that are now bad. In this list we will find the newly compiled nmethod that has not been made in_use yet. It is marked for deoptimization. Then the Deoptimization::deoptimize_all_marked() function is called to make sure that we 1) make all the marked nmethods not_entrant, and 2) arm the bad activation records in the stack. Now the first step of the two grabs the code cache lock, and walks the code cache. It finds our about to be installed nmethod, and shoots make_not_entrant() at it, racing with the compiler thread calling make_in_use() on it. This is why I advocate an approach where we simply make it safe to call make_in_use() racing with make_not_entrant(), instead of trying to chase down all possible scenarios in which this can happen. I can imagine a number of others, now that deoptimization is being done with handshakes. >> ... and similarly here: >> >> 1192???? if (nm->is_marked_for_deoptimization() && nm->is_in_use()) { >> 1193?????? // only_alive_and_not_unloading() can return not_entrant >> nmethods. >> 1194?????? // A not_entrant method can become a zombie at anytime if >> it was >> 1195?????? // made not_entrant before the previous >> safepoint/handshake. The >> 1196?????? // is_in_use() check covers the not_entrant and not zombie >> cases >> 1197?????? // that have become true after the method was marked for >> deopt. >> 1198?????? nm->make_not_entrant(); >> 1199???? } >> >> ... we now don't need the guard against is_in_use() here. > > Here we don't need that, but we don't need !nm->is_not_entrant() either, > since > it would return false as you say!? Indeed. All state checks to see if it is even safe to call the state transition function should be removed, as it should always be safe. > If we should have an early filter it think nm->is_in_use() is clearer than: > not not entrant ;) (since the not_installed is normally not seen here) The transitioning functions themselves already have early checks, so there really is nothing to gain from checking if we should transition first and then doing it. >> >> For what I propose to work out, we need to change nmethod::make_in_use >> to use nmethod::try_transition, and AOTCompiledMethod::make_entrant() >> needs to also return false when encountering a not_entrant nmethod, >> enforcing monotonicity, instead of asserting about that. AOT methods >> may turn not_in_use AOT methods to in_use, but not not_entrant to >> in_use. Once not_entrant, an AOT methods should remain not entrant >> forever. > > The only time we see methods which are not installed should be methods > that will > never be deoptimize (except when calling the test method > mark_all_nmethods_for_deoptimization), intrinsic and native. That's not right. It's visible to a bunch of deoptimizations. > And if I remember correctly make_in_use is called in a constructor which > requires extra error-handling. Construction would fail if try_transition > failed. > The assumption about these 'never deopted' methods seem to be just that :) That is also not right. We grab the code cache lock, create the nmethod, verify dependencies, install dependencies, drop the code cache lock, all under not_installed. It's only after linking the Method to the code, that we eventually set it to in_use. So it's visible for longer than you thought. And it's visible to calls, a small instant before we change the state to in_use(). That's what I claim isn't right. We don't want to be able to call into these guys. >> >> So basically, these guards are for something that used to be racy and >> dangerous due to the lack of guards inside of the state transitions, >> and today that is completely harmless, as the proper guards are in the >> attempts to change state. I would prefer to remove these guards, as it >> is confusing to the reader that we are guarding against a problem that >> can't happen. So I think you can remove the various checks for what >> state the nmethod is in, the comments describing races, and just keep >> the checks if it's a method handle intrinsic or native method. > > I'll revisit this. Was a few months since I did this. Okay! >> >> In deoptimize.cpp, the fetch_unroll_info_helper function has moved >> down, making it difficult to review as shows the code delta as if >> everything changed. So I can't see what actually changed there. :( >> Would you mind moving that code back so the webrev shows what changed >> there? > > I have inserted two new static functions before fetch_unroll_info_helper, > since code from fetch_unroll_info_helper are in these functions diff do > this. > They are static function they are best off before, and putting after them I > don't think would help the diff tool + I need fwd decl. > Suggestion? Okay, I will try to work out what the actual diff is manually. Thanks, /Erik > Thanks, Robbin > >> >> Thanks, >> /Erik >> >> On 2019-08-28 11:57, Robbin Ehn wrote: >>> Hi, hotspot-dev was the intended list. >>> >>> Thanks, Robbin >>> >>> On 2019-08-28 09:30, Robbin Ehn wrote: >>>> Hi all, please consider, >>>> >>>> To get away from the issues of us revoking in the handshake, but >>>> before deopt >>>> the locks get re-biased before we hit deopt handler, we instead >>>> revoke in deopt >>>> handler. >>>> The deopt handler have a JRT_BLOCK/_END which can safepoint so we >>>> revoke after >>>> that but before we start looking at the monitors, with a >>>> NoSafepointVerifier. >>>> >>>> Here is the previous changeset on top of jdk/jdk tip but due to >>>> merge conflicts >>>> some pieces did not apply: >>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-8221734-baseline/webrev/ >>>> >>>> So this is what was reviewed. >>>> >>>> The rebase (merge conflict resolutions) and 8224795 bug fix : >>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-rebase/webrev/ >>>> >>>> Bug 8224795 fix is here: >>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-rebase/webrev/src/hotspot/share/code/nmethod.cpp.sdiff.html >>>> >>>> >>>> After this we have the same functionally as the reverted change-set. >>>> >>>> Here is the changes for doing the revoke in deopt handler instead: >>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-revoke-on-deopt/webrev/ >>>> >>>> >>>> This code was messy adding the deopt revocation in 3 places made it >>>> worse. >>>> Here is a refactoring of that code. (also removed a dead method in >>>> biasedlocking): >>>> http://cr.openjdk.java.net/~rehn/8226705/v1/8226705-refactor/webrev/ >>>> >>>> And here is full: >>>> http://cr.openjdk.java.net/~rehn/8226705/v1/full/webrev/ >>>> >>>> Also a full squashed patch file: >>>> http://cr.openjdk.java.net/~rehn/8226705/v1/full/full.patch >>>> >>>> Latest test run I did t1-t6, Linux/Windows x64 have passed, MacOSX >>>> still >>>> running. >>>> >>>> Thanks, Robbin >>>> >>>> From kim.barrett at oracle.com Thu Aug 29 17:31:09 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 29 Aug 2019 13:31:09 -0400 Subject: RFR: 8224214: [AIX] Remove support for legacy xlc compiler In-Reply-To: References: Message-ID: <75BFF8E1-B133-4FA3-8D02-A9669CD7198E@oracle.com> > On Aug 29, 2019, at 11:41 AM, Baesken, Matthias wrote: > > Hi Martin, I agree about the m4 files . > New webrev , this additionally touches toolchain.m4 and flags-cflags.m4 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8224214.1/ This looks good. Thanks for removing the DR45 workarounds. You should probably get a build person to look at the additional build changes though. From coleen.phillimore at oracle.com Thu Aug 29 18:07:21 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 29 Aug 2019 14:07:21 -0400 Subject: RFR: 8224815: Remove non-GC uses of CollectedHeap::is_in_reserved() In-Reply-To: References: <510179ba-415d-a615-e08d-2899a7225f50@oracle.com> <5a3f7aa6-ef41-d595-145b-7decc7576380@oracle.com> Message-ID: http://cr.openjdk.java.net/~eosterlund/8224815/webrev.00/src/hotspot/share/ci/ciObjectFactory.cpp.udiff.html I can't believe how many files have assert(Universe::heap()->is_in_reserved(obj)), which seem like they should have failed somewhere else first, since the parameter is "oop". ciObject* ciObjectFactory::get(oop key) { ASSERT_IN_VM; - assert(Universe::heap()->is_in_reserved(key), "must be"); + assert(Universe::heap()->is_in(key), "must be"); NonPermObject* &bucket = find_non_perm(key); It looks like these were added during permgen elimination and really aren't needed in this file.? We already know these are oops. http://cr.openjdk.java.net/~eosterlund/8224815/webrev.00/src/hotspot/share/gc/serial/markSweep.cpp.udiff.html - assert(!Universe::heap()->is_in_reserved(p), + assert(!GenCollectedHeap::heap()->is_in_reserved(p), I'm confused when you want Universe::heap()->is_in() vs when you want SomeMoreSpecific->is_in_reserved().? or check_oop_location().? It looks like check_oop_location is chosen from inside GC where the type is HeapWord*. It seems like all of the runtime asserts should just be assert(OopDesc::is_oop(obj), "is oop"); and that calls Universe::heap()->is_oop() and that calls is_in_reserved and the alignment. http://cr.openjdk.java.net/~eosterlund/8224815/webrev.00/src/hotspot/share/gc/shared/collectedHeap.cpp.udiff.html - if (is_in_reserved(object->klass_or_null())) { + if (is_in(object->klass_or_null())) { return false; } How can this be true?? _klass is in metaspace? http://cr.openjdk.java.net/~eosterlund/8224815/webrev.00/src/hotspot/share/interpreter/interpreterRuntime.cpp.udiff.html All of these can be deleted.? The Handleizing will check is_oop() which checks that the oop is in reserved space, eventually. http://cr.openjdk.java.net/~eosterlund/8224815/webrev.00/src/hotspot/share/oops/compressedOops.cpp.udiff.html Can you put an assert(UseCompressedOops, "should only be called for compressed oops"); since you now assume that the caller checks this first? I only glazed over the GC parts.? This looks good to me. Thanks, Coleen On 8/29/19 9:20 AM, Erik ?sterlund wrote: > Hi Stefan, > > Thanks for having an in-depth look at this patch. > > On 2019-08-29 15:07, Stefan Karlsson wrote: >> Hi Erik, >> >> On 2019-08-09 09:43, Erik ?sterlund wrote: >>> Hi, >>> >>> The CollectedHeap::is_in_reserved() function assumes the GC has a >>> contiguous heap. This might not be the case, and hence the shared >>> code should not make assumptions about that. It should use >>> CollectedHeap::is_in() instead. >>> >>> However, CompressedOops inherently assumes the heap is contiguous, >>> so I let it know about the reserved region. >>> >>> This patch depends on 8229278 and 8229189, which are both out for >>> review right now. >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8224815 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~eosterlund/8224815/webrev.00/ >> >> >> I think this looks good, but have a few cleanups that I'd like to >> suggest: >> >> http://cr.openjdk.java.net/~stefank/8224815/webrev.01.review.00/ >> >> 1) Changed some parameters to accept void* to get rid of some casts >> >> 2) Replaced address with HeapWord* in GC code. >> >> 3) Moved the code that was moved to initialize_reserved_region and >> moved it into Universe::reserve_heap. I could therefore restore the >> location of the initialize_reserved_region calls. Fixed a test that >> relied on the logging order. >> >> 4) Moved the heap address range MemRegion out of NarrowPtrStruct into >> CompressedOops >> >> 5) Replaced some DEBUG_ONLY with NOT_DEBUG_RETURN. >> >> 6) Minor cleanups >> >> I ran this through tier1. > > Thank you for the bits. I think your improvements did make the code > nicer, and I agree with all suggestions. > >> It's a bit annoying that we still have CollectedHeap::_reserved, but >> I understand why you left it for now. However, I see that the >> Serviceability Agent uses that field. Did you think about if that >> affects ZGC support in SA in any way? > > Yeah it annoyed me a bit too. And no I haven't looked into what the SA > does differently if you don't specify a reserve region. I will try to > look into that. > > Thanks, > /Erik > >> Thanks, >> StefanK >> >>> >>> Thanks, >>> /Erik From coleen.phillimore at oracle.com Thu Aug 29 18:41:33 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 29 Aug 2019 14:41:33 -0400 Subject: RFR: 8224815: Remove non-GC uses of CollectedHeap::is_in_reserved() In-Reply-To: References: <510179ba-415d-a615-e08d-2899a7225f50@oracle.com> <5a3f7aa6-ef41-d595-145b-7decc7576380@oracle.com> Message-ID: <2cef4558-6ea5-29bf-2def-030432d758ce@oracle.com> On 8/29/19 2:07 PM, coleen.phillimore at oracle.com wrote: > > http://cr.openjdk.java.net/~eosterlund/8224815/webrev.00/src/hotspot/share/ci/ciObjectFactory.cpp.udiff.html > > > I can't believe how many files have > assert(Universe::heap()->is_in_reserved(obj)), which seem like they > should have failed somewhere else first, since the parameter is "oop". > > ? ciObject* ciObjectFactory::get(oop key) { > ??? ASSERT_IN_VM; > ? - assert(Universe::heap()->is_in_reserved(key), "must be"); > + assert(Universe::heap()->is_in(key), "must be"); > ? ??? NonPermObject* &bucket = find_non_perm(key); > > > It looks like these were added during permgen elimination and really > aren't needed in this file.? We already know these are oops. > > http://cr.openjdk.java.net/~eosterlund/8224815/webrev.00/src/hotspot/share/gc/serial/markSweep.cpp.udiff.html > > > - assert(!Universe::heap()->is_in_reserved(p), > + assert(!GenCollectedHeap::heap()->is_in_reserved(p), > > I'm confused when you want Universe::heap()->is_in() vs when you want > SomeMoreSpecific->is_in_reserved().? or check_oop_location().? It > looks like check_oop_location is chosen from inside GC where the type > is HeapWord*. > > It seems like all of the runtime asserts should just be > assert(OopDesc::is_oop(obj), "is oop"); and that calls > Universe::heap()->is_oop() and that calls is_in_reserved and the > alignment. > > http://cr.openjdk.java.net/~eosterlund/8224815/webrev.00/src/hotspot/share/gc/shared/collectedHeap.cpp.udiff.html > > > - if (is_in_reserved(object->klass_or_null())) { > + if (is_in(object->klass_or_null())) { > ????? return false; > ??? } > > How can this be true?? _klass is in metaspace? > > > http://cr.openjdk.java.net/~eosterlund/8224815/webrev.00/src/hotspot/share/interpreter/interpreterRuntime.cpp.udiff.html > > > All of these can be deleted.? The Handleizing will check is_oop() > which checks that the oop is in reserved space, eventually. > > http://cr.openjdk.java.net/~eosterlund/8224815/webrev.00/src/hotspot/share/oops/compressedOops.cpp.udiff.html > > > Can you put an assert(UseCompressedOops, "should only be called for > compressed oops"); > > since you now assume that the caller checks this first? > > I only glazed over the GC parts.? This looks good to me. If you make the suggested deletions, I don't need to see another webrev. Thanks, Coleen > > Thanks, > Coleen > > On 8/29/19 9:20 AM, Erik ?sterlund wrote: >> Hi Stefan, >> >> Thanks for having an in-depth look at this patch. >> >> On 2019-08-29 15:07, Stefan Karlsson wrote: >>> Hi Erik, >>> >>> On 2019-08-09 09:43, Erik ?sterlund wrote: >>>> Hi, >>>> >>>> The CollectedHeap::is_in_reserved() function assumes the GC has a >>>> contiguous heap. This might not be the case, and hence the shared >>>> code should not make assumptions about that. It should use >>>> CollectedHeap::is_in() instead. >>>> >>>> However, CompressedOops inherently assumes the heap is contiguous, >>>> so I let it know about the reserved region. >>>> >>>> This patch depends on 8229278 and 8229189, which are both out for >>>> review right now. >>>> >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8224815 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~eosterlund/8224815/webrev.00/ >>> >>> >>> I think this looks good, but have a few cleanups that I'd like to >>> suggest: >>> >>> http://cr.openjdk.java.net/~stefank/8224815/webrev.01.review.00/ >>> >>> 1) Changed some parameters to accept void* to get rid of some casts >>> >>> 2) Replaced address with HeapWord* in GC code. >>> >>> 3) Moved the code that was moved to initialize_reserved_region and >>> moved it into Universe::reserve_heap. I could therefore restore the >>> location of the initialize_reserved_region calls. Fixed a test that >>> relied on the logging order. >>> >>> 4) Moved the heap address range MemRegion out of NarrowPtrStruct >>> into CompressedOops >>> >>> 5) Replaced some DEBUG_ONLY with NOT_DEBUG_RETURN. >>> >>> 6) Minor cleanups >>> >>> I ran this through tier1. >> >> Thank you for the bits. I think your improvements did make the code >> nicer, and I agree with all suggestions. >> >>> It's a bit annoying that we still have CollectedHeap::_reserved, but >>> I understand why you left it for now. However, I see that the >>> Serviceability Agent uses that field. Did you think about if that >>> affects ZGC support in SA in any way? >> >> Yeah it annoyed me a bit too. And no I haven't looked into what the >> SA does differently if you don't specify a reserve region. I will try >> to look into that. >> >> Thanks, >> /Erik >> >>> Thanks, >>> StefanK >>> >>>> >>>> Thanks, >>>> /Erik > From devnexen at gmail.com Thu Aug 29 18:44:50 2019 From: devnexen at gmail.com (David CARLIER) Date: Thu, 29 Aug 2019 19:44:50 +0100 Subject: [PATCH] Mac print cpu model name Message-ID: Hi here a mini diff for hotspot/Mac. Thanks. Regards. From ioi.lam at oracle.com Thu Aug 29 19:47:15 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 29 Aug 2019 12:47:15 -0700 Subject: RFR: 8224815: Remove non-GC uses of CollectedHeap::is_in_reserved() In-Reply-To: <510179ba-415d-a615-e08d-2899a7225f50@oracle.com> References: <510179ba-415d-a615-e08d-2899a7225f50@oracle.com> Message-ID: The CDS changes in filemap.cpp/hpp look good to me. Thanks - Ioi On 8/9/19 12:43 AM, Erik ?sterlund wrote: > Hi, > > The CollectedHeap::is_in_reserved() function assumes the GC has a > contiguous heap. This might not be the case, and hence the shared code > should not make assumptions about that. It should use > CollectedHeap::is_in() instead. > > However, CompressedOops inherently assumes the heap is contiguous, so > I let it know about the reserved region. > > This patch depends on 8229278 and 8229189, which are both out for > review right now. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8224815 > > Webrev: > http://cr.openjdk.java.net/~eosterlund/8224815/webrev.00/ > > Thanks, > /Erik From erik.osterlund at oracle.com Thu Aug 29 19:53:15 2019 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Thu, 29 Aug 2019 21:53:15 +0200 Subject: RFR: 8224815: Remove non-GC uses of CollectedHeap::is_in_reserved() In-Reply-To: References: <510179ba-415d-a615-e08d-2899a7225f50@oracle.com> Message-ID: <54611B28-D190-420D-A695-E4932D25693B@oracle.com> Hi Ioi, Thanks for the review! /Erik > On 29 Aug 2019, at 21:47, Ioi Lam wrote: > > The CDS changes in filemap.cpp/hpp look good to me. > > Thanks > - Ioi > >> On 8/9/19 12:43 AM, Erik ?sterlund wrote: >> Hi, >> >> The CollectedHeap::is_in_reserved() function assumes the GC has a contiguous heap. This might not be the case, and hence the shared code should not make assumptions about that. It should use CollectedHeap::is_in() instead. >> >> However, CompressedOops inherently assumes the heap is contiguous, so I let it know about the reserved region. >> >> This patch depends on 8229278 and 8229189, which are both out for review right now. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8224815 >> >> Webrev: >> http://cr.openjdk.java.net/~eosterlund/8224815/webrev.00/ >> >> Thanks, >> /Erik > From forax at univ-mlv.fr Thu Aug 29 20:31:35 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 29 Aug 2019 22:31:35 +0200 (CEST) Subject: [PATCH] Mac print cpu model name In-Reply-To: References: Message-ID: <96498874.1696645.1567110695404.JavaMail.zimbra@u-pem.fr> Hi David, the attachment has been scrubbed :) R?mi ----- Mail original ----- > De: "David CARLIER" > ?: "hotspot-dev" > Envoy?: Jeudi 29 Ao?t 2019 20:44:50 > Objet: [PATCH] Mac print cpu model name > Hi here a mini diff for hotspot/Mac. > > Thanks. > Regards. From mark.reinhold at oracle.com Thu Aug 29 21:02:52 2019 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 29 Aug 2019 14:02:52 -0700 Subject: [PATCH] Mac print cpu model name In-Reply-To: <96498874.1696645.1567110695404.JavaMail.zimbra@u-pem.fr> References: <96498874.1696645.1567110695404.JavaMail.zimbra@u-pem.fr> Message-ID: <20190829140252.102496602@eggemoggin.niobe.net> 2019/8/29 13:31:35 -0700, Remi Forax : > Hi David, > the attachment has been scrubbed :) FYI, the allowed attachment types are: message/rfc822 multipart/alternative multipart/mixed multipart/related multipart/signed text/plain text/x-diff text/x-patch - Mark From devnexen at gmail.com Thu Aug 29 21:38:03 2019 From: devnexen at gmail.com (David CARLIER) Date: Thu, 29 Aug 2019 22:38:03 +0100 Subject: [PATCH] Mac print cpu model name In-Reply-To: <20190829140252.102496602@eggemoggin.niobe.net> References: <96498874.1696645.1567110695404.JavaMail.zimbra@u-pem.fr> <20190829140252.102496602@eggemoggin.niobe.net> Message-ID: Alright :-) hopes It fits better. Regards. # HG changeset patch # User David Carlier # Date 1567104150 -3600 # Thu Aug 29 19:42:30 2019 +0100 # Node ID 8dcf8637118199e40e1015684fe10df2aa4a6693 # Parent 4612a3cfb92729002deb3c86056b1104a12c9d27 hotspot, darwin: print cpu model name diff -r 4612a3cfb927 -r 8dcf86371181 src/hotspot/os/bsd/os_bsd.cpp --- a/src/hotspot/os/bsd/os_bsd.cpp Thu Aug 29 10:52:21 2019 -0700 +++ b/src/hotspot/os/bsd/os_bsd.cpp Thu Aug 29 19:42:30 2019 +0100 @@ -1597,7 +1597,15 @@ } void os::pd_print_cpu_info(outputStream* st, char* buf, size_t buflen) { - // Nothing to do for now. + char model[100]; + size_t size = sizeof(model); + int mib_model[] = {CTL_HW, HW_MODEL }; + if (sysctl(mib_model, sizeof(mib_model)/sizeof(mib_model[0]), + model, &size, NULL, 0) == 0) { + st->print_raw("CPU Model:\n"); + st->print_raw(model); + st->cr(); + } } void os::get_summary_cpu_info(char* buf, size_t buflen) { On Thu, 29 Aug 2019 at 22:03, wrote: > > 2019/8/29 13:31:35 -0700, Remi Forax : > > Hi David, > > the attachment has been scrubbed :) > > FYI, the allowed attachment types are: > > message/rfc822 > multipart/alternative > multipart/mixed > multipart/related > multipart/signed > text/plain > text/x-diff > text/x-patch > > - Mark From david.holmes at oracle.com Thu Aug 29 23:12:26 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 30 Aug 2019 09:12:26 +1000 Subject: RFR: 8224214: [AIX] Remove support for legacy xlc compiler In-Reply-To: References: Message-ID: <5235c148-f3af-7aad-a50d-769de5cd5e28@oracle.com> Hi Matthias, cc'ing build-dev for build changes. But they look fine to me as do the main changes. A couple of nits: - ensure all copyright headers are updated for 2019 - in globalDefinitions_xlc.hpp this comment seems no longer necessary // __IBMCPP__ is not defined any more with xlclang++ But that said, if __IBMCPP__ is no longer defined then it seems a fix is needed in ./share/runtime/vm_version.cpp as well. Cheers, David On 30/08/2019 1:41 am, Baesken, Matthias wrote: > Hi Martin, I agree about the m4 files . > New webrev , this additionally touches toolchain.m4 and flags-cflags.m4 > > http://cr.openjdk.java.net/~mbaesken/webrevs/8224214.1/ > > Thanks, Matthias > >> -----Original Message----- >> From: Doerr, Martin >> Sent: Donnerstag, 29. August 2019 16:19 >> To: Baesken, Matthias ; 'hotspot- >> dev at openjdk.java.net' ; 'ppc-aix-port- >> dev at openjdk.java.net' >> Subject: RE: RFR: 8224214: [AIX] Remove support for legacy xlc compiler >> >> Hi Matthias, >> >> nice cleanup. Looks good to me. >> >> We can also require availability of xlclang++ in toolchain.m4. I think some of >> the changes only work with this compiler. >> >> Thanks, >> Martin >> >> >>> -----Original Message----- >>> From: hotspot-dev On Behalf >> Of >>> Baesken, Matthias >>> Sent: Donnerstag, 29. August 2019 15:41 >>> To: 'hotspot-dev at openjdk.java.net' ; >>> 'ppc-aix-port-dev at openjdk.java.net' > dev at openjdk.java.net> >>> Subject: RFR: 8224214: [AIX] Remove support for legacy xlc compiler >>> >>> Hello, please review the following change . >>> For OpenJDK 13 we've moved to XLC 16 as required compiler. >>> However we have still a lot of workarounds and checks in the codebase >> for >>> the older xlc compilers. >>> This changes removes such changes . >>> >>> Additionally it adjusts the compiler version check in >>> hotspot/share/utilities/globalDefinitions_xlc.hpp >>> and 2 typos in os_aix are fixed . >>> >>> >>> When 8224214 was created a while ago , it was discussed on the mailing >> list >>> : >>> >>> "we still set some '-qlanglvl' options for C++ which aren't supported by the >>> new compiler [xlc16/xlclang++] either" . >>> Those options generated lots of warnings , so they were removed >> already >>> so no need to remove them in this change . >>> >>> ( In jdk11 which is built with xlc12 they can still be found : >>> flags-cflags.m4:540: -qalias=noansi -qstrict -qtls=default -qlanglvl=c99vla \ >>> flags-cflags.m4:541: -qlanglvl=noredefmac -qnortti -qnoeh -qignerrno" >>> ) >>> >>> >>> Bug/webrev : >>> >>> https://bugs.openjdk.java.net/browse/JDK-8224214 >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8224214.0/ >>> >>> >>> Thanks, Matthias From matthias.baesken at sap.com Fri Aug 30 07:55:19 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 30 Aug 2019 07:55:19 +0000 Subject: RFR: 8224214: [AIX] Remove support for legacy xlc compiler In-Reply-To: <5235c148-f3af-7aad-a50d-769de5cd5e28@oracle.com> References: <5235c148-f3af-7aad-a50d-769de5cd5e28@oracle.com> Message-ID: Hi David , thanks for forwarding to build-dev + your comments . May I add you as reviewer? New webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8224214.2/ -adjusted the copyright year in make/autoconf/toolchain.m4 -removed the comment as suggested by you > But that said, if __IBMCPP__ is no longer defined then it seems a fix is > needed in ./share/runtime/vm_version.cpp as well. -removed __IBMCPP__ from share/runtime/vm_version.cpp (more a cleanup than something that is really needed) ; reason is that xlc16/xlclang++ comes with a very rich set of compiler - macros, especially the "usual" clang and GNUC macros are all set ; see : $fgrep GNUC xclangplus.txt #define __GNUC_MINOR__ 2 #define __GNUC_PATCHLEVEL__ 1 #define __GNUC_STDC_INLINE__ 1 #define __GNUC__ 4 $ fgrep clang xclangplus.txt #define __clang__ 1 #define __clang_major__ 4 #define __clang_minor__ 0 #define __clang_patchlevel__ 1 #define __clang_version__ "4.0.1 (tags/RELEASE_401/final)" $ fgrep __VERSION__ xclangplus.txt #define __VERSION__ "IBM XL C/C++ for AIX, Version 16.1.0.1" So we would run into the clang -case in vm_version.cpp and there use the __VERSION__ info that is pretty good IMHO . Best regards, Matthias > > Hi Matthias, > > cc'ing build-dev for build changes. > > But they look fine to me as do the main changes. > > A couple of nits: > > - ensure all copyright headers are updated for 2019 > > - in globalDefinitions_xlc.hpp this comment seems no longer necessary > > // __IBMCPP__ is not defined any more with xlclang++ > > But that said, if __IBMCPP__ is no longer defined then it seems a fix is > needed in ./share/runtime/vm_version.cpp as well. > > Cheers, > David > > On 30/08/2019 1:41 am, Baesken, Matthias wrote: > > Hi Martin, I agree about the m4 files . > > New webrev , this additionally touches toolchain.m4 and flags-cflags.m4 > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8224214.1/ > > > > Thanks, Matthias > > > >> -----Original Message----- > >> From: Doerr, Martin > >> Sent: Donnerstag, 29. August 2019 16:19 > >> To: Baesken, Matthias ; 'hotspot- > >> dev at openjdk.java.net' ; 'ppc-aix-port- > >> dev at openjdk.java.net' > >> Subject: RE: RFR: 8224214: [AIX] Remove support for legacy xlc compiler > >> > >> Hi Matthias, > >> > >> nice cleanup. Looks good to me. > >> > >> We can also require availability of xlclang++ in toolchain.m4. I think some > of > >> the changes only work with this compiler. > >> > >> Thanks, > >> Martin > >> > >> > >>> -----Original Message----- > >>> From: hotspot-dev On > Behalf > >> Of > >>> Baesken, Matthias > >>> Sent: Donnerstag, 29. August 2019 15:41 > >>> To: 'hotspot-dev at openjdk.java.net' ; > >>> 'ppc-aix-port-dev at openjdk.java.net' >> dev at openjdk.java.net> > >>> Subject: RFR: 8224214: [AIX] Remove support for legacy xlc compiler > >>> > >>> Hello, please review the following change . > >>> For OpenJDK 13 we've moved to XLC 16 as required compiler. > >>> However we have still a lot of workarounds and checks in the codebase > >> for > >>> the older xlc compilers. > >>> This changes removes such changes . > >>> > >>> Additionally it adjusts the compiler version check in > >>> hotspot/share/utilities/globalDefinitions_xlc.hpp > >>> and 2 typos in os_aix are fixed . > >>> > >>> > >>> When 8224214 was created a while ago , it was discussed on the > mailing > >> list > >>> : > >>> > >>> "we still set some '-qlanglvl' options for C++ which aren't supported by > the > >>> new compiler [xlc16/xlclang++] either" . > >>> Those options generated lots of warnings , so they were removed > >> already > >>> so no need to remove them in this change . > >>> > >>> ( In jdk11 which is built with xlc12 they can still be found : > >>> flags-cflags.m4:540: -qalias=noansi -qstrict -qtls=default -qlanglvl=c99vla > \ > >>> flags-cflags.m4:541: -qlanglvl=noredefmac -qnortti -qnoeh -qignerrno" > >>> ) > >>> > >>> > >>> Bug/webrev : > >>> > >>> https://bugs.openjdk.java.net/browse/JDK-8224214 > >>> > >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8224214.0/ > >>> > >>> > >>> Thanks, Matthias From erik.osterlund at oracle.com Fri Aug 30 12:31:18 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Fri, 30 Aug 2019 14:31:18 +0200 Subject: RFR: 8224815: Remove non-GC uses of CollectedHeap::is_in_reserved() In-Reply-To: References: <510179ba-415d-a615-e08d-2899a7225f50@oracle.com> <5a3f7aa6-ef41-d595-145b-7decc7576380@oracle.com> Message-ID: Hi Coleen, On 2019-08-29 20:07, coleen.phillimore at oracle.com wrote: > > http://cr.openjdk.java.net/~eosterlund/8224815/webrev.00/src/hotspot/share/ci/ciObjectFactory.cpp.udiff.html > > > I can't believe how many files have > assert(Universe::heap()->is_in_reserved(obj)), which seem like they > should have failed somewhere else first, since the parameter is "oop". > > ? ciObject* ciObjectFactory::get(oop key) { > ??? ASSERT_IN_VM; > - assert(Universe::heap()->is_in_reserved(key), "must be"); > + assert(Universe::heap()->is_in(key), "must be"); > ??? NonPermObject* &bucket = find_non_perm(key); > > > It looks like these were added during permgen elimination and really > aren't needed in this file.? We already know these are oops. You are right that we are sometimes overly conservative about checking if we have valid oops. However, If you are okay with it, I would prefer to split such changes out to a new RFE. Because this patch touches a lot of code, and I would like the patch to come with as few surprises as possible, and be as mechanical as possible. Are you okay with splitting out removal of unnecessary check to a separate RFE? > http://cr.openjdk.java.net/~eosterlund/8224815/webrev.00/src/hotspot/share/gc/serial/markSweep.cpp.udiff.html > > > - assert(!Universe::heap()->is_in_reserved(p), > + assert(!GenCollectedHeap::heap()->is_in_reserved(p), > > I'm confused when you want Universe::heap()->is_in() vs when you want > SomeMoreSpecific->is_in_reserved().? or check_oop_location().? It looks > like check_oop_location is chosen from inside GC where the type is > HeapWord*. The check_oop_location function checks that the address looks like it could be inside of the heap, by looking at the address range, as well as alignment. But it is okay with there not being an oop there content wise. This is useful for example when you are forwarding an oop to a new location, where there is not an oop yet, but you want to make sure it is a valid looking oop location, ignoring the contents. The is_in check, looks if the address is inside of heap memory that has been handed out to mutators. From now on, you never want is_in_reserved in shared code, which is easy to remember! Because the function is removed from CollectedHeap. > It seems like all of the runtime asserts should just be > assert(OopDesc::is_oop(obj), "is oop"); and that calls > Universe::heap()->is_oop() and that calls is_in_reserved and the alignment. > > http://cr.openjdk.java.net/~eosterlund/8224815/webrev.00/src/hotspot/share/gc/shared/collectedHeap.cpp.udiff.html That might be true. However, I would still like to defer such decisions to a follow-up RFE if you are okay with that, to reduce the number of surprises in this patch. > - if (is_in_reserved(object->klass_or_null())) { > + if (is_in(object->klass_or_null())) { > ????? return false; > ??? } > > How can this be true?? _klass is in metaspace? And that right there, is exactly what it checks. It's a sanity check that an oop shouldn't have a _klass pointing into the Java heap, because that couldn't possibly be a valid oop then. Arguably, it should instead check that the _klass points into metaspace, instead of checking that it doesn't point > http://cr.openjdk.java.net/~eosterlund/8224815/webrev.00/src/hotspot/share/interpreter/interpreterRuntime.cpp.udiff.html > > > All of these can be deleted.? The Handleizing will check is_oop() which > checks that the oop is in reserved space, eventually. Sure. Again, I hope it is okay to defer removal of such asserts to a new RFE. > http://cr.openjdk.java.net/~eosterlund/8224815/webrev.00/src/hotspot/share/oops/compressedOops.cpp.udiff.html > > > Can you put an assert(UseCompressedOops, "should only be called for > compressed oops"); > > since you now assume that the caller checks this first? Sure. > I only glazed over the GC parts.? This looks good to me. Thank you for the review Coleen. I will await if you are okay with splitting out of some of your proposed changes to the asserts before producing a new webrev. Thanks, /Erik > Thanks, > Coleen > > On 8/29/19 9:20 AM, Erik ?sterlund wrote: >> Hi Stefan, >> >> Thanks for having an in-depth look at this patch. >> >> On 2019-08-29 15:07, Stefan Karlsson wrote: >>> Hi Erik, >>> >>> On 2019-08-09 09:43, Erik ?sterlund wrote: >>>> Hi, >>>> >>>> The CollectedHeap::is_in_reserved() function assumes the GC has a >>>> contiguous heap. This might not be the case, and hence the shared >>>> code should not make assumptions about that. It should use >>>> CollectedHeap::is_in() instead. >>>> >>>> However, CompressedOops inherently assumes the heap is contiguous, >>>> so I let it know about the reserved region. >>>> >>>> This patch depends on 8229278 and 8229189, which are both out for >>>> review right now. >>>> >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8224815 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~eosterlund/8224815/webrev.00/ >>> >>> >>> I think this looks good, but have a few cleanups that I'd like to >>> suggest: >>> >>> http://cr.openjdk.java.net/~stefank/8224815/webrev.01.review.00/ >>> >>> 1) Changed some parameters to accept void* to get rid of some casts >>> >>> 2) Replaced address with HeapWord* in GC code. >>> >>> 3) Moved the code that was moved to initialize_reserved_region and >>> moved it into Universe::reserve_heap. I could therefore restore the >>> location of the initialize_reserved_region calls. Fixed a test that >>> relied on the logging order. >>> >>> 4) Moved the heap address range MemRegion out of NarrowPtrStruct into >>> CompressedOops >>> >>> 5) Replaced some DEBUG_ONLY with NOT_DEBUG_RETURN. >>> >>> 6) Minor cleanups >>> >>> I ran this through tier1. >> >> Thank you for the bits. I think your improvements did make the code >> nicer, and I agree with all suggestions. >> >>> It's a bit annoying that we still have CollectedHeap::_reserved, but >>> I understand why you left it for now. However, I see that the >>> Serviceability Agent uses that field. Did you think about if that >>> affects ZGC support in SA in any way? >> >> Yeah it annoyed me a bit too. And no I haven't looked into what the SA >> does differently if you don't specify a reserve region. I will try to >> look into that. >> >> Thanks, >> /Erik >> >>> Thanks, >>> StefanK >>> >>>> >>>> Thanks, >>>> /Erik > From david.holmes at oracle.com Fri Aug 30 13:33:44 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 30 Aug 2019 23:33:44 +1000 Subject: RFR: 8224214: [AIX] Remove support for legacy xlc compiler In-Reply-To: References: <5235c148-f3af-7aad-a50d-769de5cd5e28@oracle.com> Message-ID: Hi Matthias, On 30/08/2019 5:55 pm, Baesken, Matthias wrote: > Hi David , thanks for forwarding to build-dev + your comments . May I add you as reviewer? Of course. > > New webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8224214.2/ Updates look good. Thanks, David ----- > -adjusted the copyright year in make/autoconf/toolchain.m4 > -removed the comment as suggested by you > >> But that said, if __IBMCPP__ is no longer defined then it seems a fix is >> needed in ./share/runtime/vm_version.cpp as well. > > -removed __IBMCPP__ from share/runtime/vm_version.cpp (more a cleanup than something that is really needed) ; > reason is that xlc16/xlclang++ comes with a very rich set of compiler - macros, especially the "usual" clang and GNUC macros are all set ; see : > > $fgrep GNUC xclangplus.txt > #define __GNUC_MINOR__ 2 > #define __GNUC_PATCHLEVEL__ 1 > #define __GNUC_STDC_INLINE__ 1 > #define __GNUC__ 4 > > $ fgrep clang xclangplus.txt > #define __clang__ 1 > #define __clang_major__ 4 > #define __clang_minor__ 0 > #define __clang_patchlevel__ 1 > #define __clang_version__ "4.0.1 (tags/RELEASE_401/final)" > > > $ fgrep __VERSION__ xclangplus.txt > #define __VERSION__ "IBM XL C/C++ for AIX, Version 16.1.0.1" > > So we would run into the clang -case in vm_version.cpp and there use the __VERSION__ info that is pretty good IMHO . > > Best regards, Matthias > > >> >> Hi Matthias, >> >> cc'ing build-dev for build changes. >> >> But they look fine to me as do the main changes. >> >> A couple of nits: >> >> - ensure all copyright headers are updated for 2019 >> >> - in globalDefinitions_xlc.hpp this comment seems no longer necessary >> >> // __IBMCPP__ is not defined any more with xlclang++ >> >> But that said, if __IBMCPP__ is no longer defined then it seems a fix is >> needed in ./share/runtime/vm_version.cpp as well. >> >> Cheers, >> David >> >> On 30/08/2019 1:41 am, Baesken, Matthias wrote: >>> Hi Martin, I agree about the m4 files . >>> New webrev , this additionally touches toolchain.m4 and flags-cflags.m4 >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8224214.1/ >>> >>> Thanks, Matthias >>> >>>> -----Original Message----- >>>> From: Doerr, Martin >>>> Sent: Donnerstag, 29. August 2019 16:19 >>>> To: Baesken, Matthias ; 'hotspot- >>>> dev at openjdk.java.net' ; 'ppc-aix-port- >>>> dev at openjdk.java.net' >>>> Subject: RE: RFR: 8224214: [AIX] Remove support for legacy xlc compiler >>>> >>>> Hi Matthias, >>>> >>>> nice cleanup. Looks good to me. >>>> >>>> We can also require availability of xlclang++ in toolchain.m4. I think some >> of >>>> the changes only work with this compiler. >>>> >>>> Thanks, >>>> Martin >>>> >>>> >>>>> -----Original Message----- >>>>> From: hotspot-dev On >> Behalf >>>> Of >>>>> Baesken, Matthias >>>>> Sent: Donnerstag, 29. August 2019 15:41 >>>>> To: 'hotspot-dev at openjdk.java.net' ; >>>>> 'ppc-aix-port-dev at openjdk.java.net' >>> dev at openjdk.java.net> >>>>> Subject: RFR: 8224214: [AIX] Remove support for legacy xlc compiler >>>>> >>>>> Hello, please review the following change . >>>>> For OpenJDK 13 we've moved to XLC 16 as required compiler. >>>>> However we have still a lot of workarounds and checks in the codebase >>>> for >>>>> the older xlc compilers. >>>>> This changes removes such changes . >>>>> >>>>> Additionally it adjusts the compiler version check in >>>>> hotspot/share/utilities/globalDefinitions_xlc.hpp >>>>> and 2 typos in os_aix are fixed . >>>>> >>>>> >>>>> When 8224214 was created a while ago , it was discussed on the >> mailing >>>> list >>>>> : >>>>> >>>>> "we still set some '-qlanglvl' options for C++ which aren't supported by >> the >>>>> new compiler [xlc16/xlclang++] either" . >>>>> Those options generated lots of warnings , so they were removed >>>> already >>>>> so no need to remove them in this change . >>>>> >>>>> ( In jdk11 which is built with xlc12 they can still be found : >>>>> flags-cflags.m4:540: -qalias=noansi -qstrict -qtls=default -qlanglvl=c99vla >> \ >>>>> flags-cflags.m4:541: -qlanglvl=noredefmac -qnortti -qnoeh -qignerrno" >>>>> ) >>>>> >>>>> >>>>> Bug/webrev : >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8224214 >>>>> >>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8224214.0/ >>>>> >>>>> >>>>> Thanks, Matthias From matthias.baesken at sap.com Fri Aug 30 13:44:17 2019 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 30 Aug 2019 13:44:17 +0000 Subject: RFR [XS] : 8229182: runtime/containers/docker/TestMemoryAwareness.java test fails on SLES12 In-Reply-To: <5D65988B.5040807@oracle.com> References: <9187885973675ab53221ad3140e79e0115e509a2.camel@redhat.com> <1F1258AE-747D-4024-945A-6380ECC5EB9A@oracle.com> <2F25EFBB-363C-491C-B06A-9CDD8C4011BE@oracle.com> <55A6F5EE-7212-4EDC-A0DE-B644BBC1E3A6@oracle.com> <73ff0c1940648800b27e02fc1c4575a780be2792.camel@redhat.com> <6281a0bca33bd34981063969bfd2415cdc41729e.camel@redhat.com> <5D656531.6080204@oracle.com> <5D65988B.5040807@oracle.com> Message-ID: Hello , here is a new revision that retains the javaTest options and just resets Xmx . http://cr.openjdk.java.net/~mbaesken/webrevs/8229182.4/ I checked your proposal to use jdk.test.lib.Utils.getFilteredTestJavaOpts(String... filters) ; unfortunately it does not really do what I want . This returns me a copy of the filtered TestJavaOpts . But in DockerTestUtils.java buildJavaCommand we still use the real (unfiltered) options , unless we set opts.appendTestJavaOptions to false . And I think it was stated in the review that it isn?t wanted to set opts.appendTestJavaOptions to false (because this would remove not only the unwanted Xmx in our case but more options that might be needed ). So 8229182.4 allows to intentionally set another Xmx AFTER what Utils.getTestJavaOpts , this is what we want in this test and it should be compatible for other users of DockerTestUtils.java . Best regards, Matthias > -----Original Message----- > From: Mikhailo Seledtsov > Sent: Dienstag, 27. August 2019 22:55 > To: Baesken, Matthias > Cc: Bob Vandette ; hotspot- > dev at openjdk.java.net > Subject: Re: RFR [XS] : 8229182: > runtime/containers/docker/TestMemoryAwareness.java test fails on SLES12 > > FYI: you could use jdk.test.lib.Utils.getFilteredTestJavaOpts(String... > filters) for this purpose. > > On 8/27/19, 10:15 AM, Mikhailo Seledtsov wrote: > > I agree with Bob. It seems this is exactly what we wish in this case: > > filter out/eliminate some options that interfere with the test, while > > retaining other options and passing them to the JVM running inside a > > container. > > > > > > Thank you, > > Misha > > > > On 8/27/19, 8:42 AM, Bob Vandette wrote: > >> This is an isolated problem and I don?t like the idea of adding a new > >> option just for this case. > >> > >> What if we parse the options and eliminated the general -Xmx option > >> if one was specified > >> by the test? After all, this is the intention of adding a test > >> specific heap limit. > >> > >> Bob. > >> > >> > >> > >>> On Aug 27, 2019, at 10:33 AM, Severin Gehwolf > >>> wrote: > >>> > >>> On Tue, 2019-08-27 at 14:20 +0000, Baesken, Matthias wrote: > >>>> Hello , my suggestions was " appendJavaOpts " : > >>>> > >>> OK, got it now. Looking at the webrev this wasn't clear as it didn't do > >>> that. > >>> > >>>> In case we want to be safe, I suggest to > >>>> add an additional method " appendJavaOpts " > >>>> > >>>> opts.appendJavaOpts("-Xmx" + javaHeapSize); > >>>> > >>>> to DockerRunOptions ; appendJavaOpts would append the > >>>> options after the testJavaOpts (so Xmx can be overwritten ). > >>>> > >>>> But if overrideJavaOpts is preferred that fine with me too ... > >>> I'd prefer a more telling name than "append". I'd ask myself when > >>> trying to use it: Does it append to regular java options? How is it > >>> different from addJavaOpts()? You get the idea. I'd prefer > >>> overrideJavaOpts for that reason. > >>> > >>> Perhaps addOverrideOpts()? Either way, the javadoc should make it > clear > >>> what adding options there means. > >>> > >>> Thanks, > >>> Severin > >>> > >>>> Best regards, Matthias > >>>> > >>>> > >>>>> On Tue, 2019-08-27 at 13:49 +0000, Baesken, Matthias wrote: > >>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8229182.3/ > >>>>> OK, so, in summary, the constraints are as follows: > >>>>> > >>>>> * We don't want to turn of appending global test java options as > >>>>> these > >>>>> could possibly contain local options to a specific test > >>>>> environment. > >>>>> It would be a surprise if docker tests wouldn't have them. > >>>>> * Just setting Java options is not enough as the intention is to > >>>>> set > >>>>> them for the Docker test, but could potentially be overridden by > >>>>> global test options (this issue). > >>>>> > >>>>> Given we'd like to keep that general design, maybe it would make > >>>>> sense > >>>>> to create a 3'rd, separate set of flags, neither java options nor > >>>>> test > >>>>> options would manage to override. Call it "overrideJavaOpts" or > >>>>> some > >>>>> such. At least that would make it clear that these options if set > >>>>> have > >>>>> the final say. > >>>>> > >>>>> Thoughts? > >>>>> > >>>>> Thanks, > >>>>> Severin From erik.osterlund at oracle.com Fri Aug 30 14:16:26 2019 From: erik.osterlund at oracle.com (Erik Osterlund) Date: Fri, 30 Aug 2019 16:16:26 +0200 Subject: RFR: 8224815: Remove non-GC uses of CollectedHeap::is_in_reserved() In-Reply-To: References: <510179ba-415d-a615-e08d-2899a7225f50@oracle.com> <5a3f7aa6-ef41-d595-145b-7decc7576380@oracle.com> Message-ID: Hi Coleen, Okay, thanks! /Erik > On 30 Aug 2019, at 16:06, Coleen Phillimore wrote: > > Erik. It?s fine to split out these changes. Please file an RFE and copy me. > Thanks > Coleen > >> On Aug 30, 2019, at 8:31 AM, Erik ?sterlund wrote: >> >> Hi Coleen, >> >>> On 2019-08-29 20:07, coleen.phillimore at oracle.com wrote: >>> http://cr.openjdk.java.net/~eosterlund/8224815/webrev.00/src/hotspot/share/ci/ciObjectFactory.cpp.udiff.html I can't believe how many files have assert(Universe::heap()->is_in_reserved(obj)), which seem like they should have failed somewhere else first, since the parameter is "oop". >>> ciObject* ciObjectFactory::get(oop key) { >>> ASSERT_IN_VM; >>> - assert(Universe::heap()->is_in_reserved(key), "must be"); >>> + assert(Universe::heap()->is_in(key), "must be"); >>> NonPermObject* &bucket = find_non_perm(key); >>> It looks like these were added during permgen elimination and really aren't needed in this file. We already know these are oops. >> >> You are right that we are sometimes overly conservative about checking if we have valid oops. However, If you are okay with it, I would prefer to split such changes out to a new RFE. Because this patch touches a lot of code, and I would like the patch to come with as few surprises as possible, and be as mechanical as possible. Are you okay with splitting out removal of unnecessary check to a separate RFE? >> >>> http://cr.openjdk.java.net/~eosterlund/8224815/webrev.00/src/hotspot/share/gc/serial/markSweep.cpp.udiff.html - assert(!Universe::heap()->is_in_reserved(p), >>> + assert(!GenCollectedHeap::heap()->is_in_reserved(p), >>> I'm confused when you want Universe::heap()->is_in() vs when you want SomeMoreSpecific->is_in_reserved(). or check_oop_location(). It looks like check_oop_location is chosen from inside GC where the type is HeapWord*. >> >> The check_oop_location function checks that the address looks like it could be inside of the heap, by looking at the address range, as well as alignment. But it is okay with there not being an oop there content wise. This is useful for example when you are forwarding an oop to a new location, where there is not an oop yet, but you want to make sure it is a valid looking oop location, ignoring the contents. >> >> The is_in check, looks if the address is inside of heap memory that has been handed out to mutators. From now on, you never want is_in_reserved in shared code, which is easy to remember! Because the function is removed from CollectedHeap. >> >>> It seems like all of the runtime asserts should just be assert(OopDesc::is_oop(obj), "is oop"); and that calls Universe::heap()->is_oop() and that calls is_in_reserved and the alignment. >>> http://cr.openjdk.java.net/~eosterlund/8224815/webrev.00/src/hotspot/share/gc/shared/collectedHeap.cpp.udiff.html >> >> That might be true. However, I would still like to defer such decisions to a follow-up RFE if you are okay with that, to reduce the number of surprises in this patch. >> >>> - if (is_in_reserved(object->klass_or_null())) { >>> + if (is_in(object->klass_or_null())) { >>> return false; >>> } >>> How can this be true? _klass is in metaspace? >> >> And that right there, is exactly what it checks. It's a sanity check that an oop shouldn't have a _klass pointing into the Java heap, because that couldn't possibly be a valid oop then. Arguably, it should instead check that the _klass points into metaspace, instead of checking that it doesn't point >> >>> http://cr.openjdk.java.net/~eosterlund/8224815/webrev.00/src/hotspot/share/interpreter/interpreterRuntime.cpp.udiff.html All of these can be deleted. The Handleizing will check is_oop() which checks that the oop is in reserved space, eventually. >> >> Sure. Again, I hope it is okay to defer removal of such asserts to a new RFE. >> >>> http://cr.openjdk.java.net/~eosterlund/8224815/webrev.00/src/hotspot/share/oops/compressedOops.cpp.udiff.html Can you put an assert(UseCompressedOops, "should only be called for compressed oops"); >>> since you now assume that the caller checks this first? >> >> Sure. >> >>> I only glazed over the GC parts. This looks good to me. >> >> Thank you for the review Coleen. I will await if you are okay with splitting out of some of your proposed changes to the asserts before producing a new webrev. >> >> Thanks, >> /Erik >> >>> Thanks, >>> Coleen >>>> On 8/29/19 9:20 AM, Erik ?sterlund wrote: >>>> Hi Stefan, >>>> >>>> Thanks for having an in-depth look at this patch. >>>> >>>>> On 2019-08-29 15:07, Stefan Karlsson wrote: >>>>> Hi Erik, >>>>> >>>>>> On 2019-08-09 09:43, Erik ?sterlund wrote: >>>>>> Hi, >>>>>> >>>>>> The CollectedHeap::is_in_reserved() function assumes the GC has a contiguous heap. This might not be the case, and hence the shared code should not make assumptions about that. It should use CollectedHeap::is_in() instead. >>>>>> >>>>>> However, CompressedOops inherently assumes the heap is contiguous, so I let it know about the reserved region. >>>>>> >>>>>> This patch depends on 8229278 and 8229189, which are both out for review right now. >>>>>> >>>>>> Bug: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8224815 >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~eosterlund/8224815/webrev.00/ >>>>> >>>>> >>>>> I think this looks good, but have a few cleanups that I'd like to suggest: >>>>> >>>>> http://cr.openjdk.java.net/~stefank/8224815/webrev.01.review.00/ >>>>> >>>>> 1) Changed some parameters to accept void* to get rid of some casts >>>>> >>>>> 2) Replaced address with HeapWord* in GC code. >>>>> >>>>> 3) Moved the code that was moved to initialize_reserved_region and moved it into Universe::reserve_heap. I could therefore restore the location of the initialize_reserved_region calls. Fixed a test that relied on the logging order. >>>>> >>>>> 4) Moved the heap address range MemRegion out of NarrowPtrStruct into CompressedOops >>>>> >>>>> 5) Replaced some DEBUG_ONLY with NOT_DEBUG_RETURN. >>>>> >>>>> 6) Minor cleanups >>>>> >>>>> I ran this through tier1. >>>> >>>> Thank you for the bits. I think your improvements did make the code nicer, and I agree with all suggestions. >>>> >>>>> It's a bit annoying that we still have CollectedHeap::_reserved, but I understand why you left it for now. However, I see that the Serviceability Agent uses that field. Did you think about if that affects ZGC support in SA in any way? >>>> >>>> Yeah it annoyed me a bit too. And no I haven't looked into what the SA does differently if you don't specify a reserve region. I will try to look into that. >>>> >>>> Thanks, >>>> /Erik >>>> >>>>> Thanks, >>>>> StefanK >>>>> >>>>>> >>>>>> Thanks, >>>>>> /Erik > From coleen.phillimore at oracle.com Fri Aug 30 14:06:03 2019 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Fri, 30 Aug 2019 10:06:03 -0400 Subject: RFR: 8224815: Remove non-GC uses of CollectedHeap::is_in_reserved() In-Reply-To: References: <510179ba-415d-a615-e08d-2899a7225f50@oracle.com> <5a3f7aa6-ef41-d595-145b-7decc7576380@oracle.com> Message-ID: Erik. It?s fine to split out these changes. Please file an RFE and copy me. Thanks Coleen > On Aug 30, 2019, at 8:31 AM, Erik ?sterlund wrote: > > Hi Coleen, > >> On 2019-08-29 20:07, coleen.phillimore at oracle.com wrote: >> http://cr.openjdk.java.net/~eosterlund/8224815/webrev.00/src/hotspot/share/ci/ciObjectFactory.cpp.udiff.html I can't believe how many files have assert(Universe::heap()->is_in_reserved(obj)), which seem like they should have failed somewhere else first, since the parameter is "oop". >> ciObject* ciObjectFactory::get(oop key) { >> ASSERT_IN_VM; >> - assert(Universe::heap()->is_in_reserved(key), "must be"); >> + assert(Universe::heap()->is_in(key), "must be"); >> NonPermObject* &bucket = find_non_perm(key); >> It looks like these were added during permgen elimination and really aren't needed in this file. We already know these are oops. > > You are right that we are sometimes overly conservative about checking if we have valid oops. However, If you are okay with it, I would prefer to split such changes out to a new RFE. Because this patch touches a lot of code, and I would like the patch to come with as few surprises as possible, and be as mechanical as possible. Are you okay with splitting out removal of unnecessary check to a separate RFE? > >> http://cr.openjdk.java.net/~eosterlund/8224815/webrev.00/src/hotspot/share/gc/serial/markSweep.cpp.udiff.html - assert(!Universe::heap()->is_in_reserved(p), >> + assert(!GenCollectedHeap::heap()->is_in_reserved(p), >> I'm confused when you want Universe::heap()->is_in() vs when you want SomeMoreSpecific->is_in_reserved(). or check_oop_location(). It looks like check_oop_location is chosen from inside GC where the type is HeapWord*. > > The check_oop_location function checks that the address looks like it could be inside of the heap, by looking at the address range, as well as alignment. But it is okay with there not being an oop there content wise. This is useful for example when you are forwarding an oop to a new location, where there is not an oop yet, but you want to make sure it is a valid looking oop location, ignoring the contents. > > The is_in check, looks if the address is inside of heap memory that has been handed out to mutators. From now on, you never want is_in_reserved in shared code, which is easy to remember! Because the function is removed from CollectedHeap. > >> It seems like all of the runtime asserts should just be assert(OopDesc::is_oop(obj), "is oop"); and that calls Universe::heap()->is_oop() and that calls is_in_reserved and the alignment. >> http://cr.openjdk.java.net/~eosterlund/8224815/webrev.00/src/hotspot/share/gc/shared/collectedHeap.cpp.udiff.html > > That might be true. However, I would still like to defer such decisions to a follow-up RFE if you are okay with that, to reduce the number of surprises in this patch. > >> - if (is_in_reserved(object->klass_or_null())) { >> + if (is_in(object->klass_or_null())) { >> return false; >> } >> How can this be true? _klass is in metaspace? > > And that right there, is exactly what it checks. It's a sanity check that an oop shouldn't have a _klass pointing into the Java heap, because that couldn't possibly be a valid oop then. Arguably, it should instead check that the _klass points into metaspace, instead of checking that it doesn't point > >> http://cr.openjdk.java.net/~eosterlund/8224815/webrev.00/src/hotspot/share/interpreter/interpreterRuntime.cpp.udiff.html All of these can be deleted. The Handleizing will check is_oop() which checks that the oop is in reserved space, eventually. > > Sure. Again, I hope it is okay to defer removal of such asserts to a new RFE. > >> http://cr.openjdk.java.net/~eosterlund/8224815/webrev.00/src/hotspot/share/oops/compressedOops.cpp.udiff.html Can you put an assert(UseCompressedOops, "should only be called for compressed oops"); >> since you now assume that the caller checks this first? > > Sure. > >> I only glazed over the GC parts. This looks good to me. > > Thank you for the review Coleen. I will await if you are okay with splitting out of some of your proposed changes to the asserts before producing a new webrev. > > Thanks, > /Erik > >> Thanks, >> Coleen >>> On 8/29/19 9:20 AM, Erik ?sterlund wrote: >>> Hi Stefan, >>> >>> Thanks for having an in-depth look at this patch. >>> >>>> On 2019-08-29 15:07, Stefan Karlsson wrote: >>>> Hi Erik, >>>> >>>>> On 2019-08-09 09:43, Erik ?sterlund wrote: >>>>> Hi, >>>>> >>>>> The CollectedHeap::is_in_reserved() function assumes the GC has a contiguous heap. This might not be the case, and hence the shared code should not make assumptions about that. It should use CollectedHeap::is_in() instead. >>>>> >>>>> However, CompressedOops inherently assumes the heap is contiguous, so I let it know about the reserved region. >>>>> >>>>> This patch depends on 8229278 and 8229189, which are both out for review right now. >>>>> >>>>> Bug: >>>>> https://bugs.openjdk.java.net/browse/JDK-8224815 >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~eosterlund/8224815/webrev.00/ >>>> >>>> >>>> I think this looks good, but have a few cleanups that I'd like to suggest: >>>> >>>> http://cr.openjdk.java.net/~stefank/8224815/webrev.01.review.00/ >>>> >>>> 1) Changed some parameters to accept void* to get rid of some casts >>>> >>>> 2) Replaced address with HeapWord* in GC code. >>>> >>>> 3) Moved the code that was moved to initialize_reserved_region and moved it into Universe::reserve_heap. I could therefore restore the location of the initialize_reserved_region calls. Fixed a test that relied on the logging order. >>>> >>>> 4) Moved the heap address range MemRegion out of NarrowPtrStruct into CompressedOops >>>> >>>> 5) Replaced some DEBUG_ONLY with NOT_DEBUG_RETURN. >>>> >>>> 6) Minor cleanups >>>> >>>> I ran this through tier1. >>> >>> Thank you for the bits. I think your improvements did make the code nicer, and I agree with all suggestions. >>> >>>> It's a bit annoying that we still have CollectedHeap::_reserved, but I understand why you left it for now. However, I see that the Serviceability Agent uses that field. Did you think about if that affects ZGC support in SA in any way? >>> >>> Yeah it annoyed me a bit too. And no I haven't looked into what the SA does differently if you don't specify a reserve region. I will try to look into that. >>> >>> Thanks, >>> /Erik >>> >>>> Thanks, >>>> StefanK >>>> >>>>> >>>>> Thanks, >>>>> /Erik From mikhailo.seledtsov at oracle.com Fri Aug 30 16:44:59 2019 From: mikhailo.seledtsov at oracle.com (mikhailo.seledtsov at oracle.com) Date: Fri, 30 Aug 2019 09:44:59 -0700 Subject: RFR [XS] : 8229182: runtime/containers/docker/TestMemoryAwareness.java test fails on SLES12 In-Reply-To: References: <1F1258AE-747D-4024-945A-6380ECC5EB9A@oracle.com> <2F25EFBB-363C-491C-B06A-9CDD8C4011BE@oracle.com> <55A6F5EE-7212-4EDC-A0DE-B644BBC1E3A6@oracle.com> <73ff0c1940648800b27e02fc1c4575a780be2792.camel@redhat.com> <6281a0bca33bd34981063969bfd2415cdc41729e.camel@redhat.com> <5D656531.6080204@oracle.com> <5D65988B.5040807@oracle.com> Message-ID: <8e607999-c21b-a4b3-a1aa-dd5ea3893c42@oracle.com> Looks good to me, Thank you, Misha On 8/30/19 6:44 AM, Baesken, Matthias wrote: > Hello , here is a new revision that retains the javaTest options and just resets Xmx . > > http://cr.openjdk.java.net/~mbaesken/webrevs/8229182.4/ > > I checked your proposal to use jdk.test.lib.Utils.getFilteredTestJavaOpts(String... filters) ; unfortunately it does not really do what I want . > This returns me a copy of the filtered TestJavaOpts . > > But in DockerTestUtils.java buildJavaCommand we still use the real (unfiltered) options , unless we set opts.appendTestJavaOptions to false . > And I think it was stated in the review that it isn?t wanted to set opts.appendTestJavaOptions to false (because this would remove not only the unwanted Xmx in our case but more options that might be needed ). > > So 8229182.4 allows to intentionally set another Xmx AFTER what Utils.getTestJavaOpts , this is what we want in this test and it should be compatible for other users of DockerTestUtils.java . > > Best regards, Matthias > > > >> -----Original Message----- >> From: Mikhailo Seledtsov >> Sent: Dienstag, 27. August 2019 22:55 >> To: Baesken, Matthias >> Cc: Bob Vandette ; hotspot- >> dev at openjdk.java.net >> Subject: Re: RFR [XS] : 8229182: >> runtime/containers/docker/TestMemoryAwareness.java test fails on SLES12 >> >> FYI: you could use jdk.test.lib.Utils.getFilteredTestJavaOpts(String... >> filters) for this purpose. >> >> On 8/27/19, 10:15 AM, Mikhailo Seledtsov wrote: >>> I agree with Bob. It seems this is exactly what we wish in this case: >>> filter out/eliminate some options that interfere with the test, while >>> retaining other options and passing them to the JVM running inside a >>> container. >>> >>> >>> Thank you, >>> Misha >>> >>> On 8/27/19, 8:42 AM, Bob Vandette wrote: >>>> This is an isolated problem and I don?t like the idea of adding a new >>>> option just for this case. >>>> >>>> What if we parse the options and eliminated the general -Xmx option >>>> if one was specified >>>> by the test? After all, this is the intention of adding a test >>>> specific heap limit. >>>> >>>> Bob. >>>> >>>> >>>> >>>>> On Aug 27, 2019, at 10:33 AM, Severin Gehwolf >>>>> wrote: >>>>> >>>>> On Tue, 2019-08-27 at 14:20 +0000, Baesken, Matthias wrote: >>>>>> Hello , my suggestions was " appendJavaOpts " : >>>>>> >>>>> OK, got it now. Looking at the webrev this wasn't clear as it didn't do >>>>> that. >>>>> >>>>>> In case we want to be safe, I suggest to >>>>>> add an additional method " appendJavaOpts " >>>>>> >>>>>> opts.appendJavaOpts("-Xmx" + javaHeapSize); >>>>>> >>>>>> to DockerRunOptions ; appendJavaOpts would append the >>>>>> options after the testJavaOpts (so Xmx can be overwritten ). >>>>>> >>>>>> But if overrideJavaOpts is preferred that fine with me too ... >>>>> I'd prefer a more telling name than "append". I'd ask myself when >>>>> trying to use it: Does it append to regular java options? How is it >>>>> different from addJavaOpts()? You get the idea. I'd prefer >>>>> overrideJavaOpts for that reason. >>>>> >>>>> Perhaps addOverrideOpts()? Either way, the javadoc should make it >> clear >>>>> what adding options there means. >>>>> >>>>> Thanks, >>>>> Severin >>>>> >>>>>> Best regards, Matthias >>>>>> >>>>>> >>>>>>> On Tue, 2019-08-27 at 13:49 +0000, Baesken, Matthias wrote: >>>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8229182.3/ >>>>>>> OK, so, in summary, the constraints are as follows: >>>>>>> >>>>>>> * We don't want to turn of appending global test java options as >>>>>>> these >>>>>>> could possibly contain local options to a specific test >>>>>>> environment. >>>>>>> It would be a surprise if docker tests wouldn't have them. >>>>>>> * Just setting Java options is not enough as the intention is to >>>>>>> set >>>>>>> them for the Docker test, but could potentially be overridden by >>>>>>> global test options (this issue). >>>>>>> >>>>>>> Given we'd like to keep that general design, maybe it would make >>>>>>> sense >>>>>>> to create a 3'rd, separate set of flags, neither java options nor >>>>>>> test >>>>>>> options would manage to override. Call it "overrideJavaOpts" or >>>>>>> some >>>>>>> such. At least that would make it clear that these options if set >>>>>>> have >>>>>>> the final say. >>>>>>> >>>>>>> Thoughts? >>>>>>> >>>>>>> Thanks, >>>>>>> Severin From kim.barrett at oracle.com Fri Aug 30 17:13:56 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 30 Aug 2019 13:13:56 -0400 Subject: RFR: 8224214: [AIX] Remove support for legacy xlc compiler In-Reply-To: References: <5235c148-f3af-7aad-a50d-769de5cd5e28@oracle.com> Message-ID: > On Aug 30, 2019, at 3:55 AM, Baesken, Matthias wrote: > > Hi David , thanks for forwarding to build-dev + your comments . May I add you as reviewer? > > New webrev : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8224214.2/ Still looks good to me. From erik.joelsson at oracle.com Fri Aug 30 15:08:49 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 30 Aug 2019 08:08:49 -0700 Subject: RFR: 8224214: [AIX] Remove support for legacy xlc compiler In-Reply-To: References: <5235c148-f3af-7aad-a50d-769de5cd5e28@oracle.com> Message-ID: Build changes look good. /Erik On 2019-08-30 06:33, David Holmes wrote: > Hi Matthias, > > On 30/08/2019 5:55 pm, Baesken, Matthias wrote: >> Hi David , thanks? for forwarding to build-dev + your comments . May >> I add you as reviewer? > > Of course. > >> >> New webrev : >> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8224214.2/ > > Updates look good. > > Thanks, > David > ----- > >> -adjusted? the copyright year in make/autoconf/toolchain.m4 >> -removed the comment? as suggested by you >> >>> But that said, if __IBMCPP__ is no longer defined then it seems a >>> fix is >>> needed in ./share/runtime/vm_version.cpp as well. >> >> -removed? __IBMCPP__? from? share/runtime/vm_version.cpp (more a >> cleanup than something that is really needed) ; >> reason is that? xlc16/xlclang++?? comes with a very rich set of? >> compiler - macros,?? especially? the "usual"? clang and GNUC macros >> are all set ; see : >> >> $fgrep GNUC xclangplus.txt >> #define __GNUC_MINOR__ 2 >> #define __GNUC_PATCHLEVEL__ 1 >> #define __GNUC_STDC_INLINE__ 1 >> #define __GNUC__ 4 >> >> $ fgrep clang xclangplus.txt >> #define __clang__ 1 >> #define __clang_major__ 4 >> #define __clang_minor__ 0 >> #define __clang_patchlevel__ 1 >> #define __clang_version__ "4.0.1 (tags/RELEASE_401/final)" >> >> >> $ fgrep __VERSION__ xclangplus.txt >> #define __VERSION__ "IBM XL C/C++ for AIX, Version 16.1.0.1" >> >> So we? would run into the clang -case? in? vm_version.cpp??? and >> there use? the __VERSION__ info? that is pretty? good IMHO . >> >> Best regards, Matthias >> >> >>> >>> Hi Matthias, >>> >>> cc'ing build-dev for build changes. >>> >>> But they look fine to me as do the main changes. >>> >>> A couple of nits: >>> >>> - ensure all copyright headers are updated for 2019 >>> >>> - in globalDefinitions_xlc.hpp this comment seems no longer necessary >>> >>> ??? // __IBMCPP__ is not defined any more with xlclang++ >>> >>> But that said, if __IBMCPP__ is no longer defined then it seems a >>> fix is >>> needed in ./share/runtime/vm_version.cpp as well. >>> >>> Cheers, >>> David >>> >>> On 30/08/2019 1:41 am, Baesken, Matthias wrote: >>>> Hi Martin, I agree? about the m4 files . >>>> New webrev , this additionally touches??? toolchain.m4? and >>>> flags-cflags.m4 >>>> >>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8224214.1/ >>>> >>>> Thanks, Matthias >>>> >>>>> -----Original Message----- >>>>> From: Doerr, Martin >>>>> Sent: Donnerstag, 29. August 2019 16:19 >>>>> To: Baesken, Matthias ; 'hotspot- >>>>> dev at openjdk.java.net' ; 'ppc-aix-port- >>>>> dev at openjdk.java.net' >>>>> Subject: RE: RFR: 8224214: [AIX] Remove support for legacy xlc >>>>> compiler >>>>> >>>>> Hi Matthias, >>>>> >>>>> nice cleanup. Looks good to me. >>>>> >>>>> We can also require availability of xlclang++ in toolchain.m4. I >>>>> think some >>> of >>>>> the changes only work with this compiler. >>>>> >>>>> Thanks, >>>>> Martin >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: hotspot-dev On >>> Behalf >>>>> Of >>>>>> Baesken, Matthias >>>>>> Sent: Donnerstag, 29. August 2019 15:41 >>>>>> To: 'hotspot-dev at openjdk.java.net' ; >>>>>> 'ppc-aix-port-dev at openjdk.java.net' >>>> dev at openjdk.java.net> >>>>>> Subject: RFR: 8224214: [AIX] Remove support for legacy xlc compiler >>>>>> >>>>>> Hello, please review the following change . >>>>>> For OpenJDK 13 we've moved to XLC 16 as required compiler. >>>>>> However? we have still?? a lot of workarounds and checks in the >>>>>> codebase >>>>> for >>>>>> the older xlc? compilers. >>>>>> This changes removes such changes . >>>>>> >>>>>> Additionally? it? adjusts?? the compiler version check in >>>>>> hotspot/share/utilities/globalDefinitions_xlc.hpp >>>>>> and 2 typos in os_aix? are fixed . >>>>>> >>>>>> >>>>>> When? 8224214?? was created a while ago ,? it was discussed on the >>> mailing >>>>> list >>>>>> : >>>>>> >>>>>> "we still set some '-qlanglvl' options for C++ which aren't >>>>>> supported by >>> the >>>>>> new compiler [xlc16/xlclang++] either" . >>>>>> Those options? generated lots of warnings ,?? so they were removed >>>>> already >>>>>> so? no need to remove them? in this change . >>>>>> >>>>>> (? In jdk11? which is built? with xlc12?? they can still be found : >>>>>> flags-cflags.m4:540: -qalias=noansi -qstrict -qtls=default >>>>>> -qlanglvl=c99vla >>> \ >>>>>> flags-cflags.m4:541: -qlanglvl=noredefmac -qnortti -qnoeh >>>>>> -qignerrno" >>>>>> ) >>>>>> >>>>>> >>>>>> Bug/webrev : >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8224214 >>>>>> >>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8224214.0/ >>>>>> >>>>>> >>>>>> Thanks, Matthias From devnexen at gmail.com Sat Aug 31 20:19:25 2019 From: devnexen at gmail.com (David CARLIER) Date: Sat, 31 Aug 2019 21:19:25 +0100 Subject: [PATCH] Darwin, option to monitor anonymous pages Message-ID: Hi Here a little patch proposal to be able to monitor anonymous pages with tools like mmap Kind regards. # HG changeset patch # User David Carlier # Date 1567278245 -3600 # Sat Aug 31 20:04:05 2019 +0100 # Node ID 7c566025b2e224b241704ec3a3f2fb8c70167c48 # Parent 1262b3ddd7e4f010bf81f2564bf86e7e2c00467a Darwin, option to monitor anonymous pages new flag AnonMapId, from 240 up to 255 to follow up Apple recommendations and flexibility to avoid collisions with increasing code using it. diff -r 1262b3ddd7e4 -r 7c566025b2e2 src/hotspot/os/bsd/globals_bsd.hpp --- a/src/hotspot/os/bsd/globals_bsd.hpp Sat Aug 31 09:18:40 2019 -0700 +++ b/src/hotspot/os/bsd/globals_bsd.hpp Sat Aug 31 20:04:05 2019 +0100 @@ -46,6 +46,7 @@ /* overridden in Arguments::parse_each_vm_init_arg. */ \ product(bool, UseBsdPosixThreadCPUClocks, true, \ "enable fast Bsd Posix clocks where available") \ + product(intx, AnonMapId, 240, "set anonymous page tag ID") \ // // Defines Bsd-specific default values. The flags are available on all diff -r 1262b3ddd7e4 -r 7c566025b2e2 src/hotspot/os/bsd/os_bsd.cpp --- a/src/hotspot/os/bsd/os_bsd.cpp Sat Aug 31 09:18:40 2019 -0700 +++ b/src/hotspot/os/bsd/os_bsd.cpp Sat Aug 31 20:04:05 2019 +0100 @@ -104,6 +104,7 @@ #ifdef __APPLE__ #include + #include #endif #ifndef MAP_ANONYMOUS @@ -2066,18 +2067,26 @@ static char* anon_mmap(char* requested_addr, size_t bytes, bool fixed) { char * addr; int flags; + int fd; flags = MAP_PRIVATE | MAP_NORESERVE | MAP_ANONYMOUS; + fd = -1; if (fixed) { assert((uintptr_t)requested_addr % os::Bsd::page_size() == 0, "unaligned address"); flags |= MAP_FIXED; } +#ifdef __APPLE__ + // Apple guarantees free IDs from 240 up to 255 + // for userland applications. + if (AnonMapId >= 240 && AnonMapId < 255) + fd = VM_MAKE_TAG(AnonMapId); +#endif // Map reserved/uncommitted pages PROT_NONE so we fail early if we // touch an uncommitted page. Otherwise, the read/write might // succeed if we have enough swap space to back the physical page. addr = (char*)::mmap(requested_addr, bytes, PROT_NONE, - flags, -1, 0); + flags, fd, 0); return addr == MAP_FAILED ? NULL : addr; }