From manc at google.com Fri Dec 1 00:23:56 2017 From: manc at google.com (Man Cao) Date: Thu, 30 Nov 2017 16:23:56 -0800 Subject: Unified JVM Logging and diagnostic options LogVMOutput, LogFile, DisplayVMOutput Message-ID: Hello, We (Java Platform Team at Google) found that in JDK9, the file generated by -XX:+LogVMOutput no longer contains GC log messages, because the unified JVM logging framework does not use the defaultStream and fileStream classes and the tty variable. Similarly, related options such as LogFile, DisplayVMOutput have no effect on the messages printed by the unified logging framework. The main problem for us is that most of our production Java servers use the options "-XX:+LogVMOutput -XX:-DisplayVMOutput", to save the GC logs and other VM messages. These flags would no longer work for JDK9's JVM logging framework. In addition, the file generated by -XX:+LogVMOutput may contain information that is not printed by the unified logging framework. What is worse is that if LogFile and the output of unified logging framework point to the same file, the file may contain partial or corrupted messages from the unified logging framework. For example, consider the following command: java -Xlog::file=test.log -XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput -XX:LogFile=test.log Then test.log would miss some of the messages that would be printed at the beginning if you run "java -Xlog". So our questions are: 1. Do you consider this is a bug for the unified logging framework that should be fixed? Should the unified logging framework respect these diagnostic options? 2. Is there a plan to deprecate these diagnostic options (LogVMOutput, LogFile, DisplayVMOutput, etc.)? Will the defaultStream, fileStream classes and the tty variable eventually removed from HotSpot? Thanks, Man From david.holmes at oracle.com Fri Dec 1 00:48:07 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 1 Dec 2017 10:48:07 +1000 Subject: Unified JVM Logging and diagnostic options LogVMOutput, LogFile, DisplayVMOutput In-Reply-To: References: Message-ID: <92addaa5-e735-db64-0e7a-afe8f5f6c2d4@oracle.com> Hi Man, Adding serviceability as UL is a serviceability feature. On 1/12/2017 10:23 AM, Man Cao wrote: > Hello, > > We (Java Platform Team at Google) found that in JDK9, the file generated by > -XX:+LogVMOutput no longer contains GC log messages, because the unified > JVM logging framework does not use the defaultStream and fileStream classes > and the tty variable. Similarly, related options such as LogFile, > DisplayVMOutput have no effect on the messages printed by the unified > logging framework. > > The main problem for us is that most of our production Java servers use the > options "-XX:+LogVMOutput -XX:-DisplayVMOutput", to save the GC logs and > other VM messages. These flags would no longer work for JDK9's JVM logging > framework. In addition, the file generated by -XX:+LogVMOutput may contain > information that is not printed by the unified logging framework. > > What is worse is that if LogFile and the output of unified logging > framework point to the same file, the file may contain partial or corrupted > messages from the unified logging framework. For example, consider the > following command: > > java -Xlog::file=test.log -XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput > -XX:LogFile=test.log > > Then test.log would miss some of the messages that would be printed at the > beginning if you run "java -Xlog". > > So our questions are: > 1. Do you consider this is a bug for the unified logging framework that > should be fixed? Should the unified logging framework respect these > diagnostic options? My understanding is that UL is intended to replace the legacy "logging" flags and works independently of them. So no, UL should not respect these flags. > 2. Is there a plan to deprecate these diagnostic options (LogVMOutput, > LogFile, DisplayVMOutput, etc.)? Will the defaultStream, fileStream classes > and the tty variable eventually removed from HotSpot? I believe that is the general intent - though complete removal is not feasible as UL can't always be used in all contexts. We have migrated various subsystems to UL and all new logging should be using UL. However I don't believe we actually have active RFEs to aggressively complete the switchover. Just my 2c. David > Thanks, > Man > From david.holmes at oracle.com Fri Dec 1 01:08:31 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 1 Dec 2017 11:08:31 +1000 Subject: RFR(XS): 8191787 - move private inline functions from thread.inline.hpp -> thread.cpp In-Reply-To: References: <695072b6-fcb2-0dd7-fe55-42a7b464dca2@oracle.com> <05cd0495-9635-2a3d-2fc9-30afc0880dc1@oracle.com> <3e685be3-4f8a-e328-7bd9-cbb2f72b6b65@oracle.com> Message-ID: <9cea4ceb-56bb-a0ef-0a2c-01a308ae6218@oracle.com> On 1/12/2017 7:33 AM, Daniel D. Daugherty wrote: > Hi David, > > Thanks for looking at this again! > > > On 11/30/17 4:24 PM, David Holmes wrote: >> Hi Dan, >> >> May I suggest simply moving all of the inline smr functions to the >> same position, after all the field initializations, so that it is >> hopefully more evident that they appear before any use. > > I'm in my pre-integration Mach5 tier[12] test cycle so I wasn't planning > on any more tweaks for this bug. Can I pick up this change in my next > code motion fix (8191789)? This fix (8191787) will likely make Jesper's > snapshot on 12.01. My next fix will not... Sure, no problem. It just avoids the need to check where the first use may be. Thanks, David > >> My layperson understanding - perhaps out of date in 2017 - is that to >> inline a function the compiler has to have already seen the definition. > > I was hoping for someone else to jump in to confirm or deny, but > that hasn't happened. That's why I went ahead and moved the one > inline definition before its first use... All other inline defs > are before first use (but it is not obvious). > > Dan > > >> >> Thanks, >> David >> >> On 1/12/2017 1:49 AM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I have updated the fix based on Coleen's and David H's code reviews. >>> >>> Delta webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8191787-webrev/jdk10-1-delta/ >>> >>> Full webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8191787-webrev/jdk10-1-full/ >>> >>> Thanks, in advance, for any comments, questions or suggestions. >>> >>> Dan >>> >>> On 11/29/17 4:16 PM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> Coleen, this is one of your Thread-SMR follow-up suggestions so I need >>>> to hear from you on this thread. Thanks! >>>> >>>> I have a simple cleanup fix for Thread-SMR. The bug is: >>>> >>>> ??? JDK-8191787 move private inline functions from thread.inline.hpp >>>> -> thread.cpp >>>> ??? https://bugs.openjdk.java.net/browse/JDK-8191787 >>>> >>>> This fix is pure code motion: >>>> >>>> - moving inline functions from thread.inline.hpp -> thread.cpp >>>> - making a few functions in thread.hpp private instead of public >>>> >>>> Here is the webrev URL: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8191787-webrev/jdk10-0 >>>> >>>> This fix was (over) tested with a Mach5 tier[1-5] run. There were no >>>> unexpected test failures. >>>> >>>> Thanks, in advance, for any comments, questions or suggestions. >>>> >>>> Dan >>>> >>> > From david.holmes at oracle.com Fri Dec 1 01:10:00 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 1 Dec 2017 11:10:00 +1000 Subject: RFR(XS): 8191943: [TESTBUG] docker/TestCPUAwareness fails on machine with 2 CPUs In-Reply-To: <804ff854-2010-cc6a-851c-ee20c5de1c96@oracle.com> References: <3f7beb17-21ad-73ef-96ec-d0d620d6afae@oracle.com> <4a95a8ce-44a6-340c-c3bd-268bdc0b713e@oracle.com> <077EB0DB-2E88-4EE1-9467-B4839FFA7E45@oracle.com> <9e0bfd91-16a9-2082-db66-8caf4fe3f5c0@oracle.com> <59e6d7f7-5343-2513-cf74-423c35e0158d@oracle.com> <804ff854-2010-cc6a-851c-ee20c5de1c96@oracle.com> Message-ID: <83f4fbbd-df8b-4f1f-f8c7-d66f74a49e1f@oracle.com> Seems okay. Thanks, David On 1/12/2017 6:01 AM, mikhailo wrote: > Bob, David, > > ? Thank you for review. > > ?? Here is an updated webrev addressing your comments: > > ??? http://cr.openjdk.java.net/~mseledtsov/8191943.02/ > > > Misha > > > On 11/29/2017 09:28 PM, David Holmes wrote: >> On 30/11/2017 10:08 AM, mikhailo wrote: >>> Here is an updated webrev: >>> >>> ???? http://cr.openjdk.java.net/~mseledtsov/8191943.01/ >> >> As Bob noted you may still need the guard here: >> >> ? 55???????????? testAPCCombo("0,1", 200*1000, 100*1000, 4*1024, 2); >> ? 56???????????? testAPCCombo("0,1", 200*1000, 100*1000, 1*1024, 2); > I introduced a proper check for this. >> >> though perhaps docker ignores invalid cpu-set values? >> >> 161???????? Common.logNewTestCase("expectedAPC = " + expectedAPC); >> >> That should still be a System.out.println - you already set the test >> case prior: > I changed code to output both the original expected APC and the adjusted > APC. >> >> 155???????? Common.logNewTestCase("test cpu shares, shares = " + shares); >> >> Having the same check duplicated three times is a bit messy, but not >> horrendously so. :) > Introduced a common method to conditionally adjust APC. > > Thank you, > Misha >> >> Thanks, >> David >> >>> >>> Misha >>> >>> >>> On 11/29/2017 01:32 PM, mikhailo wrote: >>>> >>>> On 11/29/2017 01:29 PM, Bob Vandette wrote: >>>>>> On Nov 29, 2017, at 4:10 PM, mikhailo >>>>>> wrote: >>>>>> >>>>>> Hi Bob, >>>>>> >>>>>> The failure was caused by invoking this test case: >>>>>> >>>>>> ???? testCpuShares(4096, 4); >>>>>> ???? The test case sets --cpu-shares to 4096, expects active >>>>>> processor count to be 4; ==> actual APC is 2. >>>>> Ahh, that makes sense.? I thought docker was complaining due to the >>>>> arguments being passed going >>>>> beyond the available cpus. >>>>> >>>>>> Command: >>>>>> >>>>>> ???? docker run --tty=true --rm --cpu-shares=4096 >>>>>> jdk-internal:test-cpu /jdk/bin/java -Xlog:os+container=trace -version >>>>>> >>>>>> Detailed log is attached at: >>>>>> >>>>>> https://bugs.openjdk.java.net/secure/attachment/73820/test-case-failure-cpu-shares-4096.txt >>>>>> >>>>>> >>>>>> >>>>>> Once I saw this issue, I decided to put limits on other test cases >>>>>> based on the number of processors available on a machine, just to >>>>>> be on a safe side. >>>>>> >>>>>> Perhaps a better approach here is to change the expected APC >>>>>> inside the testCpuShares() to be no greater than max number of >>>>>> available processors? >>>>> Yes, the selection algorithm returns the smallest number of >>>>> computed shares, quotas or active processors.? Using this approach, >>>>> you?d actually be validating the algorithm more precisely. >>>> OK. I will update the tests to do this kind of validation, and post >>>> a new webrev. >>>> >>>> >>>> Misha >>>>> >>>>> Bob. >>>>> >>>>> >>>>>> >>>>>> Misha >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 11/29/2017 06:02 AM, Bob Vandette wrote: >>>>>>> Misha, >>>>>>> >>>>>>> Which specific subtest failed on a 2 cpu system? >>>>>>> >>>>>>> I don?t see any subtests that should have failed.? You should be >>>>>>> able >>>>>>> to pass any quota, period and share value to docker independent >>>>>>> of the >>>>>>> number of CPUs.? testCpus and testAPCCombo don?t try to test more >>>>>>> than 2 cpus. >>>>>>> >>>>>>> I?m ok with the change but just wondering why the guards are >>>>>>> necessary. >>>>>>> >>>>>>> Bob. >>>>>>> >>>>>>>> On Nov 28, 2017, at 7:50 PM, mikhailo >>>>>>>> wrote: >>>>>>>> >>>>>>>> Could you, please, review this simple fix? It limits test cases >>>>>>>> in TestCPUAwareness.java >>>>>>>> based on the number of processors available. >>>>>>>> >>>>>>>> ???? JBS: https://bugs.openjdk.java.net/browse/JDK-8191943 >>>>>>>> ???? Webrev: http://cr.openjdk.java.net/~mseledtsov/8191943.00/ >>>>>>>> ???? Testing: >>>>>>>> ???????? 1. Locally: exercised the affected test locally on >>>>>>>> Linux-x64 >>>>>>>> ???????? 2. Exercised the affected test on 2 processor machine >>>>>>>> ???????? 3. Exercise the affected test via automated distributed >>>>>>>> test system >>>>>>>> ??????????? In progress >>>>>>>> >>>>>>>> Misha >>>>>>>> >>>> >>> > From daniel.daugherty at oracle.com Fri Dec 1 01:10:33 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 30 Nov 2017 20:10:33 -0500 Subject: RFR(XS): 8191787 - move private inline functions from thread.inline.hpp -> thread.cpp In-Reply-To: <9cea4ceb-56bb-a0ef-0a2c-01a308ae6218@oracle.com> References: <695072b6-fcb2-0dd7-fe55-42a7b464dca2@oracle.com> <05cd0495-9635-2a3d-2fc9-30afc0880dc1@oracle.com> <3e685be3-4f8a-e328-7bd9-cbb2f72b6b65@oracle.com> <9cea4ceb-56bb-a0ef-0a2c-01a308ae6218@oracle.com> Message-ID: <3e1f6907-3179-c969-3af4-9d35233db310@oracle.com> On 11/30/17 8:08 PM, David Holmes wrote: > On 1/12/2017 7:33 AM, Daniel D. Daugherty wrote: >> Hi David, >> >> Thanks for looking at this again! >> >> >> On 11/30/17 4:24 PM, David Holmes wrote: >>> Hi Dan, >>> >>> May I suggest simply moving all of the inline smr functions to the >>> same position, after all the field initializations, so that it is >>> hopefully more evident that they appear before any use. >> >> I'm in my pre-integration Mach5 tier[12] test cycle so I wasn't planning >> on any more tweaks for this bug. Can I pick up this change in my next >> code motion fix (8191789)? This fix (8191787) will likely make Jesper's >> snapshot on 12.01. My next fix will not... > > Sure, no problem. It just avoids the need to check where the first use > may be. Thanks! Dan > > Thanks, > David > >> >>> My layperson understanding - perhaps out of date in 2017 - is that >>> to inline a function the compiler has to have already seen the >>> definition. >> >> I was hoping for someone else to jump in to confirm or deny, but >> that hasn't happened. That's why I went ahead and moved the one >> inline definition before its first use... All other inline defs >> are before first use (but it is not obvious). >> >> Dan >> >> >>> >>> Thanks, >>> David >>> >>> On 1/12/2017 1:49 AM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> I have updated the fix based on Coleen's and David H's code reviews. >>>> >>>> Delta webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8191787-webrev/jdk10-1-delta/ >>>> >>>> Full webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8191787-webrev/jdk10-1-full/ >>>> >>>> Thanks, in advance, for any comments, questions or suggestions. >>>> >>>> Dan >>>> >>>> On 11/29/17 4:16 PM, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> Coleen, this is one of your Thread-SMR follow-up suggestions so I >>>>> need >>>>> to hear from you on this thread. Thanks! >>>>> >>>>> I have a simple cleanup fix for Thread-SMR. The bug is: >>>>> >>>>> ??? JDK-8191787 move private inline functions from >>>>> thread.inline.hpp -> thread.cpp >>>>> ??? https://bugs.openjdk.java.net/browse/JDK-8191787 >>>>> >>>>> This fix is pure code motion: >>>>> >>>>> - moving inline functions from thread.inline.hpp -> thread.cpp >>>>> - making a few functions in thread.hpp private instead of public >>>>> >>>>> Here is the webrev URL: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8191787-webrev/jdk10-0 >>>>> >>>>> This fix was (over) tested with a Mach5 tier[1-5] run. There were no >>>>> unexpected test failures. >>>>> >>>>> Thanks, in advance, for any comments, questions or suggestions. >>>>> >>>>> Dan >>>>> >>>> >> From manc at google.com Fri Dec 1 01:15:35 2017 From: manc at google.com (Man Cao) Date: Thu, 30 Nov 2017 17:15:35 -0800 Subject: Unified JVM Logging and diagnostic options LogVMOutput, LogFile, DisplayVMOutput In-Reply-To: <92addaa5-e735-db64-0e7a-afe8f5f6c2d4@oracle.com> References: <92addaa5-e735-db64-0e7a-afe8f5f6c2d4@oracle.com> Message-ID: Thanks David for the quick response! Yes, I understand completely removing defaultStream and tty is probably infeasible. If deprecating the diagnostic options (LogVMOutput, LogFile, DisplayVMOutput) is the intent, could someone create a bug/RFE to track it? They should probably first be added to the special_jvm_flags table in arguments.cpp, so there will be a warning when people use them. The case of conflicting -Xlog::file=test.log and -XX:LogFile=test.log is also a concern, the JVM should at least issue a warning about it. In addition, it would make it easier for us to convince production teams to stop using these options. Thanks, Man On Thu, Nov 30, 2017 at 4:48 PM, David Holmes wrote: > Hi Man, > > Adding serviceability as UL is a serviceability feature. > > > On 1/12/2017 10:23 AM, Man Cao wrote: > >> Hello, >> >> We (Java Platform Team at Google) found that in JDK9, the file generated >> by >> -XX:+LogVMOutput no longer contains GC log messages, because the unified >> JVM logging framework does not use the defaultStream and fileStream >> classes >> and the tty variable. Similarly, related options such as LogFile, >> DisplayVMOutput have no effect on the messages printed by the unified >> logging framework. >> >> The main problem for us is that most of our production Java servers use >> the >> options "-XX:+LogVMOutput -XX:-DisplayVMOutput", to save the GC logs and >> other VM messages. These flags would no longer work for JDK9's JVM logging >> framework. In addition, the file generated by -XX:+LogVMOutput may contain >> information that is not printed by the unified logging framework. >> >> What is worse is that if LogFile and the output of unified logging >> framework point to the same file, the file may contain partial or >> corrupted >> messages from the unified logging framework. For example, consider the >> following command: >> >> java -Xlog::file=test.log -XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput >> -XX:LogFile=test.log >> >> Then test.log would miss some of the messages that would be printed at the >> beginning if you run "java -Xlog". >> >> So our questions are: >> 1. Do you consider this is a bug for the unified logging framework that >> should be fixed? Should the unified logging framework respect these >> diagnostic options? >> > > My understanding is that UL is intended to replace the legacy "logging" > flags and works independently of them. So no, UL should not respect these > flags. > > 2. Is there a plan to deprecate these diagnostic options (LogVMOutput, >> LogFile, DisplayVMOutput, etc.)? Will the defaultStream, fileStream >> classes >> and the tty variable eventually removed from HotSpot? >> > > I believe that is the general intent - though complete removal is not > feasible as UL can't always be used in all contexts. We have migrated > various subsystems to UL and all new logging should be using UL. However I > don't believe we actually have active RFEs to aggressively complete the > switchover. > > Just my 2c. > > David > > Thanks, >> Man >> >> From mikhailo.seledtsov at oracle.com Fri Dec 1 01:16:19 2017 From: mikhailo.seledtsov at oracle.com (mikhailo) Date: Thu, 30 Nov 2017 17:16:19 -0800 Subject: RFR(XS): 8191943: [TESTBUG] docker/TestCPUAwareness fails on machine with 2 CPUs In-Reply-To: <83f4fbbd-df8b-4f1f-f8c7-d66f74a49e1f@oracle.com> References: <3f7beb17-21ad-73ef-96ec-d0d620d6afae@oracle.com> <4a95a8ce-44a6-340c-c3bd-268bdc0b713e@oracle.com> <077EB0DB-2E88-4EE1-9467-B4839FFA7E45@oracle.com> <9e0bfd91-16a9-2082-db66-8caf4fe3f5c0@oracle.com> <59e6d7f7-5343-2513-cf74-423c35e0158d@oracle.com> <804ff854-2010-cc6a-851c-ee20c5de1c96@oracle.com> <83f4fbbd-df8b-4f1f-f8c7-d66f74a49e1f@oracle.com> Message-ID: <129b3bcc-bd8e-59cb-bf88-ac937457ca8f@oracle.com> Bob, David, Thank you for review. I will run final testing and then integrate. Misha On 11/30/2017 05:10 PM, David Holmes wrote: > Seems okay. > > Thanks, > David > > On 1/12/2017 6:01 AM, mikhailo wrote: >> Bob, David, >> >> ?? Thank you for review. >> >> ??? Here is an updated webrev addressing your comments: >> >> ???? http://cr.openjdk.java.net/~mseledtsov/8191943.02/ >> >> >> Misha >> >> >> On 11/29/2017 09:28 PM, David Holmes wrote: >>> On 30/11/2017 10:08 AM, mikhailo wrote: >>>> Here is an updated webrev: >>>> >>>> ???? http://cr.openjdk.java.net/~mseledtsov/8191943.01/ >>> >>> As Bob noted you may still need the guard here: >>> >>> ? 55???????????? testAPCCombo("0,1", 200*1000, 100*1000, 4*1024, 2); >>> ? 56???????????? testAPCCombo("0,1", 200*1000, 100*1000, 1*1024, 2); >> I introduced a proper check for this. >>> >>> though perhaps docker ignores invalid cpu-set values? >>> >>> 161???????? Common.logNewTestCase("expectedAPC = " + expectedAPC); >>> >>> That should still be a System.out.println - you already set the test >>> case prior: >> I changed code to output both the original expected APC and the >> adjusted APC. >>> >>> 155???????? Common.logNewTestCase("test cpu shares, shares = " + >>> shares); >>> >>> Having the same check duplicated three times is a bit messy, but not >>> horrendously so. :) >> Introduced a common method to conditionally adjust APC. >> >> Thank you, >> Misha >>> >>> Thanks, >>> David >>> >>>> >>>> Misha >>>> >>>> >>>> On 11/29/2017 01:32 PM, mikhailo wrote: >>>>> >>>>> On 11/29/2017 01:29 PM, Bob Vandette wrote: >>>>>>> On Nov 29, 2017, at 4:10 PM, mikhailo >>>>>>> wrote: >>>>>>> >>>>>>> Hi Bob, >>>>>>> >>>>>>> The failure was caused by invoking this test case: >>>>>>> >>>>>>> ???? testCpuShares(4096, 4); >>>>>>> ???? The test case sets --cpu-shares to 4096, expects active >>>>>>> processor count to be 4; ==> actual APC is 2. >>>>>> Ahh, that makes sense.? I thought docker was complaining due to >>>>>> the arguments being passed going >>>>>> beyond the available cpus. >>>>>> >>>>>>> Command: >>>>>>> >>>>>>> ???? docker run --tty=true --rm --cpu-shares=4096 >>>>>>> jdk-internal:test-cpu /jdk/bin/java -Xlog:os+container=trace >>>>>>> -version >>>>>>> >>>>>>> Detailed log is attached at: >>>>>>> >>>>>>> https://bugs.openjdk.java.net/secure/attachment/73820/test-case-failure-cpu-shares-4096.txt >>>>>>> >>>>>>> >>>>>>> >>>>>>> Once I saw this issue, I decided to put limits on other test >>>>>>> cases based on the number of processors available on a machine, >>>>>>> just to be on a safe side. >>>>>>> >>>>>>> Perhaps a better approach here is to change the expected APC >>>>>>> inside the testCpuShares() to be no greater than max number of >>>>>>> available processors? >>>>>> Yes, the selection algorithm returns the smallest number of >>>>>> computed shares, quotas or active processors.? Using this >>>>>> approach, you?d actually be validating the algorithm more precisely. >>>>> OK. I will update the tests to do this kind of validation, and >>>>> post a new webrev. >>>>> >>>>> >>>>> Misha >>>>>> >>>>>> Bob. >>>>>> >>>>>> >>>>>>> >>>>>>> Misha >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 11/29/2017 06:02 AM, Bob Vandette wrote: >>>>>>>> Misha, >>>>>>>> >>>>>>>> Which specific subtest failed on a 2 cpu system? >>>>>>>> >>>>>>>> I don?t see any subtests that should have failed. You should be >>>>>>>> able >>>>>>>> to pass any quota, period and share value to docker independent >>>>>>>> of the >>>>>>>> number of CPUs.? testCpus and testAPCCombo don?t try to test >>>>>>>> more than 2 cpus. >>>>>>>> >>>>>>>> I?m ok with the change but just wondering why the guards are >>>>>>>> necessary. >>>>>>>> >>>>>>>> Bob. >>>>>>>> >>>>>>>>> On Nov 28, 2017, at 7:50 PM, mikhailo >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Could you, please, review this simple fix? It limits test >>>>>>>>> cases in TestCPUAwareness.java >>>>>>>>> based on the number of processors available. >>>>>>>>> >>>>>>>>> ???? JBS: https://bugs.openjdk.java.net/browse/JDK-8191943 >>>>>>>>> ???? Webrev: http://cr.openjdk.java.net/~mseledtsov/8191943.00/ >>>>>>>>> ???? Testing: >>>>>>>>> ???????? 1. Locally: exercised the affected test locally on >>>>>>>>> Linux-x64 >>>>>>>>> ???????? 2. Exercised the affected test on 2 processor machine >>>>>>>>> ???????? 3. Exercise the affected test via automated >>>>>>>>> distributed test system >>>>>>>>> ??????????? In progress >>>>>>>>> >>>>>>>>> Misha >>>>>>>>> >>>>> >>>> >> From mikhailo.seledtsov at oracle.com Fri Dec 1 02:07:43 2017 From: mikhailo.seledtsov at oracle.com (mikhailo) Date: Thu, 30 Nov 2017 18:07:43 -0800 Subject: RFR(XS): trivial: JDK-8192866 - [TESTBUG] Move UseAppCDS.java from the closed ProblemList.txt to the open one Message-ID: Please review this small fix that I consider a trivial change: http://cr.openjdk.java.net/~mseledtsov/JDK-8192866.00/ I will run the appcds tests, plus tier1. Thank you, Misha From calvin.cheung at oracle.com Fri Dec 1 02:24:06 2017 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Thu, 30 Nov 2017 18:24:06 -0800 Subject: RFR(XS): trivial: JDK-8192866 - [TESTBUG] Move UseAppCDS.java from the closed ProblemList.txt to the open one In-Reply-To: References: Message-ID: <5A20BD46.3010009@oracle.com> Looks good. thanks, Calvin On 11/30/17, 6:07 PM, mikhailo wrote: > Please review this small fix that I consider a trivial change: > http://cr.openjdk.java.net/~mseledtsov/JDK-8192866.00/ > > I will run the appcds tests, plus tier1. > > > Thank you, > Misha > From david.holmes at oracle.com Fri Dec 1 02:24:38 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 1 Dec 2017 12:24:38 +1000 Subject: RFR(XS): trivial: JDK-8192866 - [TESTBUG] Move UseAppCDS.java from the closed ProblemList.txt to the open one In-Reply-To: References: Message-ID: Ship it! Thanks, David On 1/12/2017 12:07 PM, mikhailo wrote: > Please review this small fix that I consider a trivial change: > http://cr.openjdk.java.net/~mseledtsov/JDK-8192866.00/ > > I will run the appcds tests, plus tier1. > > > Thank you, > Misha > From volker.simonis at gmail.com Fri Dec 1 08:10:57 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 1 Dec 2017 09:10:57 +0100 Subject: RFR(XS): trivial: JDK-8192866 - [TESTBUG] Move UseAppCDS.java from the closed ProblemList.txt to the open one In-Reply-To: References: Message-ID: Hi Misha, the bug you mention in ProblemList.txt (i.e 8165603) is closed. Can you please make it visible for everybody? Thanks, Volker On Fri, Dec 1, 2017 at 3:07 AM, mikhailo wrote: > Please review this small fix that I consider a trivial change: > http://cr.openjdk.java.net/~mseledtsov/JDK-8192866.00/ > > I will run the appcds tests, plus tier1. > > > Thank you, > Misha > From david.holmes at oracle.com Fri Dec 1 08:24:47 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 1 Dec 2017 18:24:47 +1000 Subject: RFR(XS): trivial: JDK-8192866 - [TESTBUG] Move UseAppCDS.java from the closed ProblemList.txt to the open one In-Reply-To: References: Message-ID: Hi Volker, On 1/12/2017 6:10 PM, Volker Simonis wrote: > Hi Misha, > > the bug you mention in ProblemList.txt (i.e 8165603) is closed. > Can you please make it visible for everybody? Unfortunately not in this case as the bug description contains information that we must treat as confidential. The bug is: runtime/AppCDS/UseAppCDS.java fails with Error. failed to clean up files after test when running with agentvm Basically jtreg in agentvm mode tries to delete a file used by the test, and it gets an error (Windows only) as the file is "in use", because the test failed to close the file. The fix should be straight-forward (ensure the file is closed or else run in othervm mode). But due to the effort involved in getting AppCDS into the Open, fixing this test was not high priority, and now we're out of time, so it was added to the ProblemList instead - but it was added to the closed list just before the test was moved to the open. Cheers, David > Thanks, > Volker > > On Fri, Dec 1, 2017 at 3:07 AM, mikhailo wrote: >> Please review this small fix that I consider a trivial change: >> http://cr.openjdk.java.net/~mseledtsov/JDK-8192866.00/ >> >> I will run the appcds tests, plus tier1. >> >> >> Thank you, >> Misha >> From volker.simonis at gmail.com Fri Dec 1 09:00:22 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 1 Dec 2017 10:00:22 +0100 Subject: RFR(XS): trivial: JDK-8192866 - [TESTBUG] Move UseAppCDS.java from the closed ProblemList.txt to the open one In-Reply-To: References: Message-ID: On Fri, Dec 1, 2017 at 9:24 AM, David Holmes wrote: > Hi Volker, > > On 1/12/2017 6:10 PM, Volker Simonis wrote: >> >> Hi Misha, >> >> the bug you mention in ProblemList.txt (i.e 8165603) is closed. >> Can you please make it visible for everybody? > > > Unfortunately not in this case as the bug description contains information > that we must treat as confidential. > > The bug is: > > runtime/AppCDS/UseAppCDS.java fails with Error. failed to clean up files > after test when running with agentvm > That's strange. How can a bug about a failure in a public JTreg test which tests a public feature can contain confidential information? Nevertheless, thanks a lot for sharing the information. Regards, Volker > Basically jtreg in agentvm mode tries to delete a file used by the test, and > it gets an error (Windows only) as the file is "in use", because the test > failed to close the file. The fix should be straight-forward (ensure the > file is closed or else run in othervm mode). But due to the effort involved > in getting AppCDS into the Open, fixing this test was not high priority, and > now we're out of time, so it was added to the ProblemList instead - but it > was added to the closed list just before the test was moved to the open. > > Cheers, > David > > > >> Thanks, >> Volker >> >> On Fri, Dec 1, 2017 at 3:07 AM, mikhailo >> wrote: >>> >>> Please review this small fix that I consider a trivial change: >>> http://cr.openjdk.java.net/~mseledtsov/JDK-8192866.00/ >>> >>> I will run the appcds tests, plus tier1. >>> >>> >>> Thank you, >>> Misha >>> > From martin.doerr at sap.com Fri Dec 1 14:03:38 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 1 Dec 2017 14:03:38 +0000 Subject: 8192898: AIX build broken after 8190308 Message-ID: <8b00a1c6303044d5a517a67626049f80@sap.com> Hi, I have opened a new bug jdk-8192898. "MAP_NORESERVE" was introduced in os_posix.cpp. It is not POSIX and it is not defined on AIX. Not sure if any other OS is affected, too. Should non-POSIX code be in os_posix.cpp? I can provide a trivial fix for AIX (see below). But maybe somebody has a better idea? Best regards, Martin --- a/src/hotspot/os/posix/os_posix.cpp Thu Nov 30 18:05:57 2017 +0100 +++ b/src/hotspot/os/posix/os_posix.cpp Thu Nov 30 18:55:02 2017 +0100 @@ -200,7 +200,7 @@ static char* reserve_mmapped_memory(size_t bytes, char* requested_addr) { char * addr; - int flags = MAP_PRIVATE | MAP_NORESERVE | MAP_ANONYMOUS; + int flags = MAP_PRIVATE NOT_AIX( | MAP_NORESERVE ) | MAP_ANONYMOUS; if (requested_addr != NULL) { assert((uintptr_t)requested_addr % os::vm_page_size() == 0, "Requested address should be aligned to OS page size"); flags |= MAP_FIXED; From daniel.daugherty at oracle.com Fri Dec 1 15:18:41 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 1 Dec 2017 10:18:41 -0500 Subject: RFR(XXXS): 8192810 - EnableThreadSMRStatistics should be default off in release builds Message-ID: <2e1fd94a-7e1a-eb12-20c5-6603447d6d2f@oracle.com> Greetings, Trivial fix here so I need a single (R)eviewer for this one. 8192810 EnableThreadSMRStatistics should be default off in release builds https://bugs.openjdk.java.net/browse/JDK-8192810 $ hg diff diff -r 61a14b5cb1c6 src/hotspot/share/runtime/globals.hpp --- a/src/hotspot/share/runtime/globals.hpp??? Fri Dec 01 18:19:39 2017 +0530 +++ b/src/hotspot/share/runtime/globals.hpp??? Fri Dec 01 10:15:47 2017 -0500 @@ -2488,7 +2488,7 @@ ?? diagnostic(bool, EnableThreadSMRExtraValidityChecks, true,??????????????? \ ????????????? "Enable Thread SMR extra validity checks")???????????????????? \ \ -? diagnostic(bool, EnableThreadSMRStatistics, true,???????????????????????? \ +? diagnostic(bool, EnableThreadSMRStatistics, trueInDebug,????????????????? \ ????????????? "Enable Thread SMR Statistics")??????????????????????????????? \ \ ?? product(bool, Inline, true,?????????????????????????????????????????????? \ Thanks, in advance, for a quick review. Dan From george.triantafillou at oracle.com Fri Dec 1 15:49:34 2017 From: george.triantafillou at oracle.com (George Triantafillou) Date: Fri, 1 Dec 2017 10:49:34 -0500 Subject: RFR(XXXS): 8192810 - EnableThreadSMRStatistics should be default off in release builds In-Reply-To: <2e1fd94a-7e1a-eb12-20c5-6603447d6d2f@oracle.com> References: <2e1fd94a-7e1a-eb12-20c5-6603447d6d2f@oracle.com> Message-ID: Hi Dan, Looks good! -George On 12/1/2017 10:18 AM, Daniel D. Daugherty wrote: > Greetings, > > Trivial fix here so I need a single (R)eviewer for this one. > > 8192810 EnableThreadSMRStatistics should be default off in release builds > https://bugs.openjdk.java.net/browse/JDK-8192810 > > $ hg diff > diff -r 61a14b5cb1c6 src/hotspot/share/runtime/globals.hpp > --- a/src/hotspot/share/runtime/globals.hpp??? Fri Dec 01 18:19:39 > 2017 +0530 > +++ b/src/hotspot/share/runtime/globals.hpp??? Fri Dec 01 10:15:47 > 2017 -0500 > @@ -2488,7 +2488,7 @@ > ?? diagnostic(bool, EnableThreadSMRExtraValidityChecks, > true,??????????????? \ > ????????????? "Enable Thread SMR extra validity > checks")???????????????????? \ > \ > -? diagnostic(bool, EnableThreadSMRStatistics, > true,???????????????????????? \ > +? diagnostic(bool, EnableThreadSMRStatistics, > trueInDebug,????????????????? \ > ????????????? "Enable Thread SMR > Statistics")??????????????????????????????? \ > \ > ?? product(bool, Inline, > true,?????????????????????????????????????????????? \ > > > Thanks, in advance, for a quick review. > > Dan > From daniel.daugherty at oracle.com Fri Dec 1 15:50:34 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 1 Dec 2017 10:50:34 -0500 Subject: RFR(XXXS): 8192810 - EnableThreadSMRStatistics should be default off in release builds In-Reply-To: References: <2e1fd94a-7e1a-eb12-20c5-6603447d6d2f@oracle.com> Message-ID: <468f896e-07f7-48fc-a8d2-b11c2a0369f7@oracle.com> Thanks George! Dan On 12/1/17 10:49 AM, George Triantafillou wrote: > Hi Dan, > > Looks good! > > -George > > > On 12/1/2017 10:18 AM, Daniel D. Daugherty wrote: >> Greetings, >> >> Trivial fix here so I need a single (R)eviewer for this one. >> >> 8192810 EnableThreadSMRStatistics should be default off in release >> builds >> https://bugs.openjdk.java.net/browse/JDK-8192810 >> >> $ hg diff >> diff -r 61a14b5cb1c6 src/hotspot/share/runtime/globals.hpp >> --- a/src/hotspot/share/runtime/globals.hpp??? Fri Dec 01 18:19:39 >> 2017 +0530 >> +++ b/src/hotspot/share/runtime/globals.hpp??? Fri Dec 01 10:15:47 >> 2017 -0500 >> @@ -2488,7 +2488,7 @@ >> ?? diagnostic(bool, EnableThreadSMRExtraValidityChecks, >> true,??????????????? \ >> ????????????? "Enable Thread SMR extra validity >> checks")???????????????????? \ >> \ >> -? diagnostic(bool, EnableThreadSMRStatistics, >> true,???????????????????????? \ >> +? diagnostic(bool, EnableThreadSMRStatistics, >> trueInDebug,????????????????? \ >> ????????????? "Enable Thread SMR >> Statistics")??????????????????????????????? \ >> \ >> ?? product(bool, Inline, >> true,?????????????????????????????????????????????? \ >> >> >> Thanks, in advance, for a quick review. >> >> Dan >> > From coleen.phillimore at oracle.com Fri Dec 1 15:52:24 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 1 Dec 2017 10:52:24 -0500 Subject: RFR(XXXS): 8192810 - EnableThreadSMRStatistics should be default off in release builds In-Reply-To: <2e1fd94a-7e1a-eb12-20c5-6603447d6d2f@oracle.com> References: <2e1fd94a-7e1a-eb12-20c5-6603447d6d2f@oracle.com> Message-ID: <7d43dcd0-2e9f-b3f7-ca8b-47ba02f60761@oracle.com> Yes, this looks good.? Thank you for fixing this so quickly! Coleen On 12/1/17 10:18 AM, Daniel D. Daugherty wrote: > Greetings, > > Trivial fix here so I need a single (R)eviewer for this one. > > 8192810 EnableThreadSMRStatistics should be default off in release builds > https://bugs.openjdk.java.net/browse/JDK-8192810 > > $ hg diff > diff -r 61a14b5cb1c6 src/hotspot/share/runtime/globals.hpp > --- a/src/hotspot/share/runtime/globals.hpp??? Fri Dec 01 18:19:39 > 2017 +0530 > +++ b/src/hotspot/share/runtime/globals.hpp??? Fri Dec 01 10:15:47 > 2017 -0500 > @@ -2488,7 +2488,7 @@ > ?? diagnostic(bool, EnableThreadSMRExtraValidityChecks, > true,??????????????? \ > ????????????? "Enable Thread SMR extra validity > checks")???????????????????? \ > \ > -? diagnostic(bool, EnableThreadSMRStatistics, > true,???????????????????????? \ > +? diagnostic(bool, EnableThreadSMRStatistics, > trueInDebug,????????????????? \ > ????????????? "Enable Thread SMR > Statistics")??????????????????????????????? \ > \ > ?? product(bool, Inline, > true,?????????????????????????????????????????????? \ > > > Thanks, in advance, for a quick review. > > Dan > From daniel.daugherty at oracle.com Fri Dec 1 15:54:38 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 1 Dec 2017 10:54:38 -0500 Subject: RFR(XXXS): 8192810 - EnableThreadSMRStatistics should be default off in release builds In-Reply-To: <7d43dcd0-2e9f-b3f7-ca8b-47ba02f60761@oracle.com> References: <2e1fd94a-7e1a-eb12-20c5-6603447d6d2f@oracle.com> <7d43dcd0-2e9f-b3f7-ca8b-47ba02f60761@oracle.com> Message-ID: Thanks Coleen! Dan On 12/1/17 10:52 AM, coleen.phillimore at oracle.com wrote: > Yes, this looks good.? Thank you for fixing this so quickly! > Coleen > > On 12/1/17 10:18 AM, Daniel D. Daugherty wrote: >> Greetings, >> >> Trivial fix here so I need a single (R)eviewer for this one. >> >> 8192810 EnableThreadSMRStatistics should be default off in release >> builds >> https://bugs.openjdk.java.net/browse/JDK-8192810 >> >> $ hg diff >> diff -r 61a14b5cb1c6 src/hotspot/share/runtime/globals.hpp >> --- a/src/hotspot/share/runtime/globals.hpp??? Fri Dec 01 18:19:39 >> 2017 +0530 >> +++ b/src/hotspot/share/runtime/globals.hpp??? Fri Dec 01 10:15:47 >> 2017 -0500 >> @@ -2488,7 +2488,7 @@ >> ?? diagnostic(bool, EnableThreadSMRExtraValidityChecks, >> true,??????????????? \ >> ????????????? "Enable Thread SMR extra validity >> checks")???????????????????? \ >> \ >> -? diagnostic(bool, EnableThreadSMRStatistics, >> true,???????????????????????? \ >> +? diagnostic(bool, EnableThreadSMRStatistics, >> trueInDebug,????????????????? \ >> ????????????? "Enable Thread SMR >> Statistics")??????????????????????????????? \ >> \ >> ?? product(bool, Inline, >> true,?????????????????????????????????????????????? \ >> >> >> Thanks, in advance, for a quick review. >> >> Dan >> > From coleen.phillimore at oracle.com Fri Dec 1 15:57:11 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 1 Dec 2017 10:57:11 -0500 Subject: 8192898: AIX build broken after 8190308 In-Reply-To: <8b00a1c6303044d5a517a67626049f80@sap.com> References: <8b00a1c6303044d5a517a67626049f80@sap.com> Message-ID: <1e535c73-ada8-b2b0-2415-07da71a7739b@oracle.com> Hi Martin, I will sponsor your trivial fix so that it gets pushed today before the jdk10 deadline.? The OS's that Oracle supports seem not affected but we can open a bug if we find other OS's that become broken. os_posix is tricky for AIX because it seems AIX is posix-like enough to not want to duplicate the code for AIX.?? It seems reasonable to have this conditional compilation. Thanks, Coleen On 12/1/17 9:03 AM, Doerr, Martin wrote: > Hi, > > I have opened a new bug jdk-8192898. > "MAP_NORESERVE" was introduced in os_posix.cpp. It is not POSIX and it is not defined on AIX. Not sure if any other OS is affected, too. > > Should non-POSIX code be in os_posix.cpp? > > I can provide a trivial fix for AIX (see below). But maybe somebody has a better idea? > > Best regards, > Martin > > > --- a/src/hotspot/os/posix/os_posix.cpp Thu Nov 30 18:05:57 2017 +0100 > +++ b/src/hotspot/os/posix/os_posix.cpp Thu Nov 30 18:55:02 2017 +0100 > @@ -200,7 +200,7 @@ > > static char* reserve_mmapped_memory(size_t bytes, char* requested_addr) { > char * addr; > - int flags = MAP_PRIVATE | MAP_NORESERVE | MAP_ANONYMOUS; > + int flags = MAP_PRIVATE NOT_AIX( | MAP_NORESERVE ) | MAP_ANONYMOUS; > if (requested_addr != NULL) { > assert((uintptr_t)requested_addr % os::vm_page_size() == 0, "Requested address should be aligned to OS page size"); > flags |= MAP_FIXED; From erik.osterlund at oracle.com Fri Dec 1 16:00:01 2017 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Fri, 1 Dec 2017 17:00:01 +0100 Subject: RFR(XXXS): 8192810 - EnableThreadSMRStatistics should be default off in release builds In-Reply-To: <2e1fd94a-7e1a-eb12-20c5-6603447d6d2f@oracle.com> References: <2e1fd94a-7e1a-eb12-20c5-6603447d6d2f@oracle.com> Message-ID: <5A217C81.5030107@oracle.com> Hi, Looks good. Thanks, /Erik On 2017-12-01 16:18, Daniel D. Daugherty wrote: > Greetings, > > Trivial fix here so I need a single (R)eviewer for this one. > > 8192810 EnableThreadSMRStatistics should be default off in release builds > https://bugs.openjdk.java.net/browse/JDK-8192810 > > $ hg diff > diff -r 61a14b5cb1c6 src/hotspot/share/runtime/globals.hpp > --- a/src/hotspot/share/runtime/globals.hpp Fri Dec 01 18:19:39 > 2017 +0530 > +++ b/src/hotspot/share/runtime/globals.hpp Fri Dec 01 10:15:47 > 2017 -0500 > @@ -2488,7 +2488,7 @@ > diagnostic(bool, EnableThreadSMRExtraValidityChecks, > true, \ > "Enable Thread SMR extra validity > checks") \ > \ > - diagnostic(bool, EnableThreadSMRStatistics, > true, \ > + diagnostic(bool, EnableThreadSMRStatistics, > trueInDebug, \ > "Enable Thread SMR > Statistics") \ > \ > product(bool, Inline, > true, \ > > > Thanks, in advance, for a quick review. > > Dan > From daniel.daugherty at oracle.com Fri Dec 1 16:00:23 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 1 Dec 2017 11:00:23 -0500 Subject: RFR(XXXS): 8192810 - EnableThreadSMRStatistics should be default off in release builds In-Reply-To: <5A217C81.5030107@oracle.com> References: <2e1fd94a-7e1a-eb12-20c5-6603447d6d2f@oracle.com> <5A217C81.5030107@oracle.com> Message-ID: Thanks Erik! Dan On 12/1/17 11:00 AM, Erik ?sterlund wrote: > Hi, > > Looks good. > > Thanks, > /Erik > > On 2017-12-01 16:18, Daniel D. Daugherty wrote: >> Greetings, >> >> Trivial fix here so I need a single (R)eviewer for this one. >> >> 8192810 EnableThreadSMRStatistics should be default off in release >> builds >> https://bugs.openjdk.java.net/browse/JDK-8192810 >> >> $ hg diff >> diff -r 61a14b5cb1c6 src/hotspot/share/runtime/globals.hpp >> --- a/src/hotspot/share/runtime/globals.hpp??? Fri Dec 01 18:19:39 >> 2017 +0530 >> +++ b/src/hotspot/share/runtime/globals.hpp??? Fri Dec 01 10:15:47 >> 2017 -0500 >> @@ -2488,7 +2488,7 @@ >> ?? diagnostic(bool, EnableThreadSMRExtraValidityChecks, >> true,??????????????? \ >> ????????????? "Enable Thread SMR extra validity >> checks")???????????????????? \ >> \ >> -? diagnostic(bool, EnableThreadSMRStatistics, >> true,???????????????????????? \ >> +? diagnostic(bool, EnableThreadSMRStatistics, >> trueInDebug,????????????????? \ >> ????????????? "Enable Thread SMR >> Statistics")??????????????????????????????? \ >> \ >> ?? product(bool, Inline, >> true,?????????????????????????????????????????????? \ >> >> >> Thanks, in advance, for a quick review. >> >> Dan >> > From martin.doerr at sap.com Fri Dec 1 16:05:53 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 1 Dec 2017 16:05:53 +0000 Subject: 8192898: AIX build broken after 8190308 In-Reply-To: <1e535c73-ada8-b2b0-2415-07da71a7739b@oracle.com> References: <8b00a1c6303044d5a517a67626049f80@sap.com> <1e535c73-ada8-b2b0-2415-07da71a7739b@oracle.com> Message-ID: <182853b1e13d480aaa3ef07d03f47550@sap.com> Hi Coleen, thanks a lot for your help. Makes sense. Best regards, Martin -----Original Message----- From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of coleen.phillimore at oracle.com Sent: Freitag, 1. Dezember 2017 16:57 To: hotspot-runtime-dev at openjdk.java.net Subject: Re: 8192898: AIX build broken after 8190308 Hi Martin, I will sponsor your trivial fix so that it gets pushed today before the jdk10 deadline.? The OS's that Oracle supports seem not affected but we can open a bug if we find other OS's that become broken. os_posix is tricky for AIX because it seems AIX is posix-like enough to not want to duplicate the code for AIX.?? It seems reasonable to have this conditional compilation. Thanks, Coleen On 12/1/17 9:03 AM, Doerr, Martin wrote: > Hi, > > I have opened a new bug jdk-8192898. > "MAP_NORESERVE" was introduced in os_posix.cpp. It is not POSIX and it is not defined on AIX. Not sure if any other OS is affected, too. > > Should non-POSIX code be in os_posix.cpp? > > I can provide a trivial fix for AIX (see below). But maybe somebody has a better idea? > > Best regards, > Martin > > > --- a/src/hotspot/os/posix/os_posix.cpp Thu Nov 30 18:05:57 2017 +0100 > +++ b/src/hotspot/os/posix/os_posix.cpp Thu Nov 30 18:55:02 2017 +0100 > @@ -200,7 +200,7 @@ > > static char* reserve_mmapped_memory(size_t bytes, char* requested_addr) { > char * addr; > - int flags = MAP_PRIVATE | MAP_NORESERVE | MAP_ANONYMOUS; > + int flags = MAP_PRIVATE NOT_AIX( | MAP_NORESERVE ) | MAP_ANONYMOUS; > if (requested_addr != NULL) { > assert((uintptr_t)requested_addr % os::vm_page_size() == 0, "Requested address should be aligned to OS page size"); > flags |= MAP_FIXED; From jiangli.zhou at oracle.com Fri Dec 1 18:50:49 2017 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Fri, 1 Dec 2017 10:50:49 -0800 Subject: Several questions regarding AppCDS In-Reply-To: References: <08A854C2-BC11-43E3-9FB9-98E6050D098A@oracle.com> Message-ID: Hi Volker, > On Nov 30, 2017, at 2:56 PM, Volker Simonis wrote: > > > Jiangli Zhou > schrieb am Do. 30. Nov. 2017 um 20:27: > Hi Volker, > > Just some high level information for your questions. We are continually investigating the usage/requirement of the CDS/AppCDS support for custom class loaders and the current implementation may change when the investigation is maturing. That?s part of reason why there is no extended public documentation about the custom class loader support and external tool for generating the new class list available at the time. Ioi probably will fill in more details on this topic. > > Hi Jiangli, > > thanks a lot for your answer. Without the possibility to create the extended class list entries for classes loaded by custom class loaders automatically it will be probably quite hard to use this feature productively. Ioi will send out information regarding the experimental new class list format. Please look for his email. > > There's one thing I forgot to ask. Is there a way (e.g. a tool) to dump the contents of an archive in readable form. E.g. something like SA agent to create class files from an archive? That could be quite helpful for debugging. At runtime shared classes loaded from the mapped archive should be able to be inspected by SA agent, like the dynamically loaded classes. I think you are suggesting a static dumper utility that can be used to translate the archive content into human readable format. That sounds like a useful tool. Best regards, Jiangli > > Thank's a lot and best regards, > Volker > > > Thanks, > > Jiangli > > > On Nov 30, 2017, at 6:46 AM, Volker Simonis > wrote: > > > > Hi Jiangli, Ioi, > > > > after AppCDS has been pushed to the open repos, I started looking at > > it. However, I found very little in-deep documentation of the feature. > > All I could find so far is basically the Oracle docs, blogs and videos > > I've listed below (in the hope that they may be useful for others as > > well). > > > > However this still doesn't answer the following questions: > > > > 1. Is there a specification and explanation of the extended class list > > syntax which is used for AppCDS with custom class loaders? > > > > I only found the documentation in systemDictionaryShared.hpp. But that > > for example mentions the "loader" keyword (as do some of the JTreg > > tests) without further explanation. > > > > 2. Is there a way or tool to create this extended class list automatically? > > > > As far as I can see, all the Jtreg tests which use the extended > > syntax, generate the class list manually. I did some simple tests > > where I load some classes into my own URL class loader but they don't > > seem to appear in the class list generated by -XX:DumpLoadedClassList. > > > > Any further references are highly welcome. > > > > Thank you and best regards, > > Volker > > > > PS: I really liked your JavaOne 2016 presentation :) > > > > Class Data Sharing > > ==================== > > https://docs.oracle.com/javase/9/vm/class-data-sharing.htm#JSJVM-GUID-7EAA3411-8CF0-4D19-BD05-DF5E1780AA91 > > > > Application Class Data Sharing > > ============================== > > https://docs.oracle.com/javase/9/tools/java.htm#JSWOR-GUID-31503FCE-93D0-4175-9B4F-F6A738B2F4C4 > > > > JEP 310: Application Class-Data Sharing > > ======================================= > > http://openjdk.java.net/jeps/310 > > > > Matthew Gilliard's blog > > ----------------------- > > Fast JVM startup with JDK 9 > > https://mjg123.github.io/2017/10/02/JVM-startup.html > > > > Quicker Clojure startup with AppCDS and AOT > > https://mjg123.github.io/2017/10/04/AppCDS-and-Clojure.html > > > > Leveraging AppCDS to Optimize Application Startup and Memory Footprint > > in the Cloud > > ----------------------------------------------------------------------------------- > > https://www.youtube.com/watch?v=dRw77QDSL-A > From ioi.lam at oracle.com Fri Dec 1 18:53:06 2017 From: ioi.lam at oracle.com (Ioi Lam) Date: Fri, 1 Dec 2017 10:53:06 -0800 Subject: RFR(XS) 8190809 JVM crashes while generating appcds for classpath with empty directory entry Message-ID: Hi Please review this very small change. I hope to invoke the trivial rule so that I can push before today's 8PM PDT deadline for JDK 10 integration. https://bugs.openjdk.java.net/browse/JDK-8190809 http://cr.openjdk.java.net/~iklam/jdk10/8190809-cds-crash-empty-cp.v01/ The crash happened because CDS was trying to use a classpath as a JAR file, before checking it's actually a JAR file. I added test case for the use of directories in -cp during CDS dumping, both for empty and non-empty cases. I will test with tier1/tier2 testing before pushing. Thanks - Ioi PS: the check for non-emptiness is done in here: void ClassLoader::check_shared_classpath(const char *path) { ? if (strcmp(path, "") == 0) { ??? exit_with_path_failure("Cannot have empty path in archived classpaths", NULL); ? } ? struct stat st; ? if (os::stat(path, &st) == 0) { ??? if ((st.st_mode & S_IFMT) != S_IFREG) { // is not a regular file ????? if (!os::dir_is_empty(path)) { ??????? tty->print_cr("Error: non-empty directory '%s'", path); ??????? exit_with_path_failure("CDS allows only empty directories in archived classpaths", NULL); ????? } ??? } ? } } From sangheon.kim at oracle.com Fri Dec 1 18:59:47 2017 From: sangheon.kim at oracle.com (sangheon.kim) Date: Fri, 1 Dec 2017 10:59:47 -0800 Subject: RFR(M): 8190308: Supporting heap allocation on alternative memory devices and CSR review In-Reply-To: References: <1509719477.3207.10.camel@oracle.com> <9b259cdd-111a-0634-80a1-0c6ba1a8d260@oracle.com> <4171dc3d-3a43-a455-0efb-ee5ff5640b93@oracle.com> <1510605610.7132.3.camel@oracle.com> <3e6131cd-bac3-c8db-971f-297bb13b087d@oracle.com> Message-ID: <9d6f979d-5b7c-5a64-0f06-fdce3e16f9cd@oracle.com> Hi Martin, On 11/30/2017 10:08 AM, Doerr, Martin wrote: > Hi, > > I just noticed that "MAP_NORESERVE" is not defined on AIX (os_posix.cpp reserve_mmapped_memory). > I guess it's not POSIX, so this looks like a bug. Yes, I agree. I filed https://bugs.openjdk.java.net/browse/JDK-8192919 for this. > Would it make sense to replace it by "NOT_AIX( | MAP_NORESERVE )"? That would be a good quick-fix for AIX. But MAP_ANONYMOUS (used with MAP_NORESERVE in that line) is also not specified on POSIX as well. The difference is that most OS seem to define it. Or line 56(#ifndef MAP_ANONYMOUS) makes to avoid the problem. So I think it would be better to completely move these 2 flags out of os_posix.cpp. Thanks, Sangheon > Or is there a better idea? > > Best regards, > Martin > > > -----Original Message----- > From: hotspot-gc-dev [mailto:hotspot-gc-dev-bounces at openjdk.java.net] On Behalf Of Kharbas, Kishor > Sent: Montag, 13. November 2017 22:33 > To: sangheon.kim ; Thomas Schatzl ; 'hotspot-gc-dev at openjdk.java.net' ; hotspot-runtime-dev at openjdk.java.net > Cc: Kharbas, Kishor > Subject: RE: RFR(M): 8190308: Supporting heap allocation on alternative memory devices and CSR review > > Thanks Sangheon and Thomas! > > -----Original Message----- > From: sangheon.kim [mailto:sangheon.kim at oracle.com] > Sent: Monday, November 13, 2017 12:41 PM > To: Thomas Schatzl ; Kharbas, Kishor ; 'hotspot-gc-dev at openjdk.java.net' ; hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR(M): 8190308: Supporting heap allocation on alternative memory devices and CSR review > > Hi Kishor, > > On 11/13/2017 12:40 PM, Thomas Schatzl wrote: >> Hi Kishor, >> >> On Mon, 2017-11-13 at 19:40 +0000, Kharbas, Kishor wrote: >>> Greetings, >>> >>> I have an updated webrev to remove compilation warning on Windows 32- >>> bit. >>> http://cr.openjdk.java.net/~kkharbas/8190308/webrev.15/ >>> http://cr.openjdk.java.net/~kkharbas/8190308/webrev.15_to_14/ >>> >>> Sorry missed this earlier. I request for a review on this update. >> looks good. The other changes from webrev.13 on also look good. > +1 > > Thanks, > Sangheon > > >> Thanks, >> Thomas >> >>> >>> Thanks >>> Kishor >>> >>> From: sangheon.kim [mailto:sangheon.kim at oracle.com] >>> Sent: Friday, November 3, 2017 4:07 PM >>> To: Kharbas, Kishor ; Thomas Schatzl >> s.schatzl at oracle.com>; 'hotspot-gc-dev at openjdk.java.net' >> dev at openjdk.java.net>; hotspot-runtime-dev at openjdk.java.net >>> Subject: Re: RFR(M): 8190308: Supporting heap allocation on >>> alternative memory devices and CSR review >>> >>> Hi Kishor, >>> >>> >>> On 11/03/2017 02:59 PM, Kharbas, Kishor wrote: >>> Hi Sangheon, >>> >>> Here is link to the updated webrev- >>> http://cr.openjdk.java.net/~kkharbas/8190308/webrev.14/ >>> http://cr.openjdk.java.net/~kkharbas/8190308/webrev.14_to_13/ >>> Looks good to me. >>> >>> Thanks, >>> Sangheon >>> >>> >>> >>> >>> Thanks >>> Kishor >>> >>> From: sangheon.kim [mailto:sangheon.kim at oracle.com] >>> Sent: Friday, November 3, 2017 2:38 PM >>> To: Kharbas, Kishor ; Thomas Schatzl >> s.schatzl at oracle.com>; 'hotspot-gc-dev at openjdk.java.net' >> dev at openjdk.java.net>; hotspot-runtime-dev at openjdk.java.net >>> Subject: Re: RFR(M): 8190308: Supporting heap allocation on >>> alternative memory devices and CSR review >>> >>> Hi Kishor, >>> >>> On 11/03/2017 11:39 AM, Kharbas, Kishor wrote: >>> Thanks a lot! >>> >>> Link to updated webrevs - >>> http://cr.openjdk.java.net/~kkharbas/8190308/webrev.13/ >>> http://cr.openjdk.java.net/~kkharbas/8190308/webrev.13_to_12/ >>> Thank you for fixing all. >>> Looks good to me except below. >>> >>> Could you update the copyright format in TestAllocateHeapAt.java? >>> 2? * Copyright (c) 2017 Oracle and/or its affiliates. All rights >>> reserved. >>> - Missing comma: * Copyright (c) 2017, Oracle and/or its affiliates. >>> All rights reserved. >>> >>> Thanks, >>> Sangheon >>> >>> >>> >>> >>> >>> >>> @Sangheon: Please let me know if you see any corrections needed. >>> >>> -Kishor >>> >>> -----Original Message----- >>> From: Thomas Schatzl [mailto:thomas.schatzl at oracle.com] >>> Sent: Friday, November 3, 2017 7:31 AM >>> To: Kharbas, Kishor ; sangheon.kim >>> ; 'hotspot-gc-dev at openjdk.java.net' >>> ; hotspot-runtime- >>> dev at openjdk.java.net >>> Subject: Re: RFR(M): 8190308: Supporting heap allocation on >>> alternative memory devices and CSR review >>> >>> Hi, >>> >>> On Fri, 2017-11-03 at 08:55 +0000, Kharbas, Kishor wrote: >>> Hi Sangheon, >>> >>> Thanks for the review and comments. Here is an updated webrev- >>> http://cr.openjdk.java.net/~kkharbas/8190308/webrev.12 >>> http://cr.openjdk.java.net/~kkharbas/8190308/webrev.12_to_11 >>> >>> In addition to your suggested corrections, I added code to set Linux >>> core dump filter ensuring Heap is dumped correctly when this feature >>> is used. This is follow-up to Jini George?s comment >>> (http://openjdk.5641.n7.nabble.com/RFR-M-8171181-Supporting-heap- >>> allocation-on-alternative-memory-devices-td300109.html#a300450). >>> >>> Some minor nits: >>> >>> ?- os_posix.cpp:300: please move the else next to the brace >>> ?- arguments.cpp:4624: please add a space between "if" and the >>> bracket >>> >>> I do not need to see a new webrev for these changes. Looks good. >>> >>> Thanks, >>> ? Thomas >>> >>> >>> From calvin.cheung at oracle.com Fri Dec 1 19:05:40 2017 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Fri, 01 Dec 2017 11:05:40 -0800 Subject: RFR(XS) 8190809 JVM crashes while generating appcds for classpath with empty directory entry In-Reply-To: References: Message-ID: <5A21A804.3000305@oracle.com> Hi Ioi, The fix looks good. thanks, Calvin On 12/1/17, 10:53 AM, Ioi Lam wrote: > Hi > > Please review this very small change. I hope to invoke the trivial > rule so that I can push before today's 8PM PDT deadline for JDK 10 > integration. > > https://bugs.openjdk.java.net/browse/JDK-8190809 > http://cr.openjdk.java.net/~iklam/jdk10/8190809-cds-crash-empty-cp.v01/ > > The crash happened because CDS was trying to use a classpath as a JAR > file, before checking it's actually a JAR file. > > I added test case for the use of directories in -cp during CDS > dumping, both for empty and non-empty cases. > > I will test with tier1/tier2 testing before pushing. > > Thanks > - Ioi > > > > > > > PS: the check for non-emptiness is done in here: > > void ClassLoader::check_shared_classpath(const char *path) { > if (strcmp(path, "") == 0) { > exit_with_path_failure("Cannot have empty path in archived > classpaths", NULL); > } > > struct stat st; > if (os::stat(path, &st) == 0) { > if ((st.st_mode & S_IFMT) != S_IFREG) { // is not a regular file > if (!os::dir_is_empty(path)) { > tty->print_cr("Error: non-empty directory '%s'", path); > exit_with_path_failure("CDS allows only empty directories in > archived classpaths", NULL); > } > } > } > } > > From ioi.lam at oracle.com Fri Dec 1 19:07:26 2017 From: ioi.lam at oracle.com (Ioi Lam) Date: Fri, 1 Dec 2017 11:07:26 -0800 Subject: RFR(XS) 8190809 JVM crashes while generating appcds for classpath with empty directory entry In-Reply-To: <5A21A804.3000305@oracle.com> References: <5A21A804.3000305@oracle.com> Message-ID: <84f441ea-c00e-7a23-93ec-15c22dc57376@oracle.com> Thanks Calvin! - Ioi On 12/1/17 11:05 AM, Calvin Cheung wrote: > Hi Ioi, > > The fix looks good. > > thanks, > Calvin > > On 12/1/17, 10:53 AM, Ioi Lam wrote: >> Hi >> >> Please review this very small change. I hope to invoke the trivial >> rule so that I can push before today's 8PM PDT deadline for JDK 10 >> integration. >> >> https://bugs.openjdk.java.net/browse/JDK-8190809 >> http://cr.openjdk.java.net/~iklam/jdk10/8190809-cds-crash-empty-cp.v01/ >> >> The crash happened because CDS was trying to use a classpath as a JAR >> file, before checking it's actually a JAR file. >> >> I added test case for the use of directories in -cp during CDS >> dumping, both for empty and non-empty cases. >> >> I will test with tier1/tier2 testing before pushing. >> >> Thanks >> - Ioi >> >> >> >> >> >> >> PS: the check for non-emptiness is done in here: >> >> void ClassLoader::check_shared_classpath(const char *path) { >> ? if (strcmp(path, "") == 0) { >> ??? exit_with_path_failure("Cannot have empty path in archived >> classpaths", NULL); >> ? } >> >> ? struct stat st; >> ? if (os::stat(path, &st) == 0) { >> ??? if ((st.st_mode & S_IFMT) != S_IFREG) { // is not a regular file >> ????? if (!os::dir_is_empty(path)) { >> ??????? tty->print_cr("Error: non-empty directory '%s'", path); >> ??????? exit_with_path_failure("CDS allows only empty directories in >> archived classpaths", NULL); >> ????? } >> ??? } >> ? } >> } >> >> From jiangli.zhou at oracle.com Fri Dec 1 19:12:36 2017 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Fri, 1 Dec 2017 11:12:36 -0800 Subject: RFR(XS) 8190809 JVM crashes while generating appcds for classpath with empty directory entry In-Reply-To: References: Message-ID: <88EE34B0-77AC-4F96-9C50-7D5CB3D3937A@oracle.com> Looks good. Thanks, Jiangli > On Dec 1, 2017, at 10:53 AM, Ioi Lam wrote: > > Hi > > Please review this very small change. I hope to invoke the trivial rule so that I can push before today's 8PM PDT deadline for JDK 10 integration. > > https://bugs.openjdk.java.net/browse/JDK-8190809 > http://cr.openjdk.java.net/~iklam/jdk10/8190809-cds-crash-empty-cp.v01/ > > The crash happened because CDS was trying to use a classpath as a JAR file, before checking it's actually a JAR file. > > I added test case for the use of directories in -cp during CDS dumping, both for empty and non-empty cases. > > I will test with tier1/tier2 testing before pushing. > > Thanks > - Ioi > > > > > > > PS: the check for non-emptiness is done in here: > > void ClassLoader::check_shared_classpath(const char *path) { > if (strcmp(path, "") == 0) { > exit_with_path_failure("Cannot have empty path in archived classpaths", NULL); > } > > struct stat st; > if (os::stat(path, &st) == 0) { > if ((st.st_mode & S_IFMT) != S_IFREG) { // is not a regular file > if (!os::dir_is_empty(path)) { > tty->print_cr("Error: non-empty directory '%s'", path); > exit_with_path_failure("CDS allows only empty directories in archived classpaths", NULL); > } > } > } > } > > From leonid.mesnik at oracle.com Fri Dec 1 19:32:31 2017 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Fri, 1 Dec 2017 11:32:31 -0800 Subject: RFR(XS) 8190809 JVM crashes while generating appcds for classpath with empty directory entry In-Reply-To: References: Message-ID: Fix looks good. The only one question. Why don?t just always use current dir in 39? 39 File dir = new File(System.getProperty("test.classes", ".")); I think that jtreg always run test in new scratch directory however ?test.classes? might be re-used between runs and people could have fail to create new directory if they re-run test locally. Leonid > On Dec 1, 2017, at 10:53 AM, Ioi Lam wrote: > > Hi > > Please review this very small change. I hope to invoke the trivial rule so that I can push before today's 8PM PDT deadline for JDK 10 integration. > > https://bugs.openjdk.java.net/browse/JDK-8190809 > http://cr.openjdk.java.net/~iklam/jdk10/8190809-cds-crash-empty-cp.v01/ > > The crash happened because CDS was trying to use a classpath as a JAR file, before checking it's actually a JAR file. > > I added test case for the use of directories in -cp during CDS dumping, both for empty and non-empty cases. > > I will test with tier1/tier2 testing before pushing. > > Thanks > - Ioi > > > > > > > PS: the check for non-emptiness is done in here: > > void ClassLoader::check_shared_classpath(const char *path) { > if (strcmp(path, "") == 0) { > exit_with_path_failure("Cannot have empty path in archived classpaths", NULL); > } > > struct stat st; > if (os::stat(path, &st) == 0) { > if ((st.st_mode & S_IFMT) != S_IFREG) { // is not a regular file > if (!os::dir_is_empty(path)) { > tty->print_cr("Error: non-empty directory '%s'", path); > exit_with_path_failure("CDS allows only empty directories in archived classpaths", NULL); > } > } > } > } > > From ioi.lam at oracle.com Fri Dec 1 19:42:27 2017 From: ioi.lam at oracle.com (Ioi Lam) Date: Fri, 1 Dec 2017 11:42:27 -0800 Subject: RFR(XS) 8190809 JVM crashes while generating appcds for classpath with empty directory entry In-Reply-To: References: Message-ID: <1c0cb6d4-e4b3-8595-895d-6e51b85606a3@oracle.com> Hi Leonid, Thanks for the review. I've changed that line to ??????? File dir = new File(System.getProperty("user.dir")); (which is similar to what TestCommon.java does with other temp files). I'll rerun the tests now. Thanks - Ioi On 12/1/17 11:32 AM, Leonid Mesnik wrote: > Fix looks good. > The only one question. Why don?t just always use current dir in 39? > 39 File dir = new File(System.getProperty("test.classes", ".")); > I think that jtreg always run test in new scratch directory however > ?test.classes? might be re-used between runs and people could have > fail to create new directory if they re-run test locally. > > Leonid > >> On Dec 1, 2017, at 10:53 AM, Ioi Lam > > wrote: >> >> Hi >> >> Please review this very small change. I hope to invoke the trivial >> rule so that I can push before today's 8PM PDT deadline for JDK 10 >> integration. >> >> https://bugs.openjdk.java.net/browse/JDK-8190809 >> http://cr.openjdk.java.net/~iklam/jdk10/8190809-cds-crash-empty-cp.v01/ >> >> The crash happened because CDS was trying to use a classpath as a JAR >> file, before checking it's actually a JAR file. >> >> I added test case for the use of directories in -cp during CDS >> dumping, both for empty and non-empty cases. >> >> I will test with tier1/tier2 testing before pushing. >> >> Thanks >> - Ioi >> >> >> >> >> >> >> PS: the check for non-emptiness is done in here: >> >> void ClassLoader::check_shared_classpath(const char *path) { >> ? if (strcmp(path, "") == 0) { >> ??? exit_with_path_failure("Cannot have empty path in archived >> classpaths", NULL); >> ? } >> >> ? struct stat st; >> ? if (os::stat(path, &st) == 0) { >> ??? if ((st.st_mode & S_IFMT) != S_IFREG) { // is not a regular file >> ????? if (!os::dir_is_empty(path)) { >> ??????? tty->print_cr("Error: non-empty directory '%s'", path); >> ??????? exit_with_path_failure("CDS allows only empty directories in >> archived classpaths", NULL); >> ????? } >> ??? } >> ? } >> } >> >> > From leonid.mesnik at oracle.com Fri Dec 1 19:44:56 2017 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Fri, 1 Dec 2017 11:44:56 -0800 Subject: RFR(XS) 8190809 JVM crashes while generating appcds for classpath with empty directory entry In-Reply-To: <1c0cb6d4-e4b3-8595-895d-6e51b85606a3@oracle.com> References: <1c0cb6d4-e4b3-8595-895d-6e51b85606a3@oracle.com> Message-ID: Thank you for update. Looks good. Leonid > On Dec 1, 2017, at 11:42 AM, Ioi Lam wrote: > > Hi Leonid, > > Thanks for the review. I've changed that line to > > File dir = new File(System.getProperty("user.dir")); > (which is similar to what TestCommon.java does with other temp files). > > I'll rerun the tests now. > > Thanks > > - Ioi > > On 12/1/17 11:32 AM, Leonid Mesnik wrote: >> Fix looks good. >> The only one question. Why don?t just always use current dir in 39? >> 39 File dir = new File(System.getProperty("test.classes", ".")); >> I think that jtreg always run test in new scratch directory however ?test.classes? might be re-used between runs and people could have fail to create new directory if they re-run test locally. >> >> Leonid >> >>> On Dec 1, 2017, at 10:53 AM, Ioi Lam > wrote: >>> >>> Hi >>> >>> Please review this very small change. I hope to invoke the trivial rule so that I can push before today's 8PM PDT deadline for JDK 10 integration. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8190809 >>> http://cr.openjdk.java.net/~iklam/jdk10/8190809-cds-crash-empty-cp.v01/ >>> >>> The crash happened because CDS was trying to use a classpath as a JAR file, before checking it's actually a JAR file. >>> >>> I added test case for the use of directories in -cp during CDS dumping, both for empty and non-empty cases. >>> >>> I will test with tier1/tier2 testing before pushing. >>> >>> Thanks >>> - Ioi >>> >>> >>> >>> >>> >>> >>> PS: the check for non-emptiness is done in here: >>> >>> void ClassLoader::check_shared_classpath(const char *path) { >>> if (strcmp(path, "") == 0) { >>> exit_with_path_failure("Cannot have empty path in archived classpaths", NULL); >>> } >>> >>> struct stat st; >>> if (os::stat(path, &st) == 0) { >>> if ((st.st_mode & S_IFMT) != S_IFREG) { // is not a regular file >>> if (!os::dir_is_empty(path)) { >>> tty->print_cr("Error: non-empty directory '%s'", path); >>> exit_with_path_failure("CDS allows only empty directories in archived classpaths", NULL); >>> } >>> } >>> } >>> } >>> >>> >> > From ioi.lam at oracle.com Fri Dec 1 21:57:36 2017 From: ioi.lam at oracle.com (Ioi Lam) Date: Fri, 1 Dec 2017 13:57:36 -0800 Subject: RFR(XS) 8190809 JVM crashes while generating appcds for classpath with empty directory entry In-Reply-To: References: <1c0cb6d4-e4b3-8595-895d-6e51b85606a3@oracle.com> Message-ID: Hi, I had to change the test because of JDK-8192927 "os::dir_is_empty is incorrect on Windows" import jdk.test.lib.Platform; import jdk.test.lib.process.OutputAnalyzer; import java.io.File; public class DirClasspathTest { ??? public static void main(String[] args) throws Exception { ??????? File dir = new File(System.getProperty("user.dir")); ??????? File emptydir = new File(dir, "emptydir"); ??????? emptydir.mkdir(); ??????? // Empty dir in -cp: should be OK ??????? OutputAnalyzer output; ??????? if (!Platform.isWindows()) { ??????????? // This block fails on Windows because of JDK-8192927 ??????????? output = TestCommon.dump(emptydir.getPath(), TestCommon.list("DoesntMatter"), "-Xlog:class+path=info"); ??????????? TestCommon.checkDump(output); ??????? } ??????? // Non-empty dir in -cp: should fail ??????? // is not empty because it has at least one subdirectory, i.e., ??????? output = TestCommon.dump(dir.getPath(), TestCommon.list("DoesntMatter"), "-Xlog:class+path=info"); ??????? output.shouldNotHaveExitValue(0); ??????? output.shouldContain("CDS allows only empty directories in archived classpaths"); ??? } } So the test for "-cp emptydir" is now disabled on Windows. Thanks - Ioi On 12/1/17 11:44 AM, Leonid Mesnik wrote: > Thank you for update. Looks good. > > Leonid > >> On Dec 1, 2017, at 11:42 AM, Ioi Lam > > wrote: >> >> Hi Leonid, >> >> Thanks for the review. I've changed that line to >> >> ??????? File dir = new File(System.getProperty("user.dir")); >> >> (which is similar to what TestCommon.java does with other temp files). >> >> I'll rerun the tests now. >> >> Thanks >> >> - Ioi >> >> >> On 12/1/17 11:32 AM, Leonid Mesnik wrote: >>> Fix looks good. >>> The only one question. Why don?t just always use current dir in 39? >>> 39 File dir = new File(System.getProperty("test.classes", ".")); >>> I think that jtreg always run test in new scratch directory however >>> ?test.classes? might be re-used between runs and people could have >>> fail to create new directory if they re-run test locally. >>> >>> Leonid >>> >>>> On Dec 1, 2017, at 10:53 AM, Ioi Lam >>> > wrote: >>>> >>>> Hi >>>> >>>> Please review this very small change. I hope to invoke the trivial >>>> rule so that I can push before today's 8PM PDT deadline for JDK 10 >>>> integration. >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8190809 >>>> http://cr.openjdk.java.net/~iklam/jdk10/8190809-cds-crash-empty-cp.v01/ >>>> >>>> The crash happened because CDS was trying to use a classpath as a >>>> JAR file, before checking it's actually a JAR file. >>>> >>>> I added test case for the use of directories in -cp during CDS >>>> dumping, both for empty and non-empty cases. >>>> >>>> I will test with tier1/tier2 testing before pushing. >>>> >>>> Thanks >>>> - Ioi >>>> >>>> >>>> >>>> >>>> >>>> >>>> PS: the check for non-emptiness is done in here: >>>> >>>> void ClassLoader::check_shared_classpath(const char *path) { >>>> ? if (strcmp(path, "") == 0) { >>>> ??? exit_with_path_failure("Cannot have empty path in archived >>>> classpaths", NULL); >>>> ? } >>>> >>>> ? struct stat st; >>>> ? if (os::stat(path, &st) == 0) { >>>> ??? if ((st.st_mode & S_IFMT) != S_IFREG) { // is not a regular file >>>> ????? if (!os::dir_is_empty(path)) { >>>> ??????? tty->print_cr("Error: non-empty directory '%s'", path); >>>> ??????? exit_with_path_failure("CDS allows only empty directories >>>> in archived classpaths", NULL); >>>> ????? } >>>> ??? } >>>> ? } >>>> } >>>> >>>> >>> >> > From david.holmes at oracle.com Sun Dec 3 02:06:04 2017 From: david.holmes at oracle.com (David Holmes) Date: Sun, 3 Dec 2017 12:06:04 +1000 Subject: 8192898: AIX build broken after 8190308 In-Reply-To: <8b00a1c6303044d5a517a67626049f80@sap.com> References: <8b00a1c6303044d5a517a67626049f80@sap.com> Message-ID: Hi Martin, On 2/12/2017 12:03 AM, Doerr, Martin wrote: > Hi, > > I have opened a new bug jdk-8192898. > "MAP_NORESERVE" was introduced in os_posix.cpp. It is not POSIX and it is not defined on AIX. Not sure if any other OS is affected, too. > > Should non-POSIX code be in os_posix.cpp? In principle not. That file is starting to become a common place to mostly-share code that is mostly-common across non-Windows platforms. I would prefer to see this file contain predominantly POSIX code with necessary tweaks on a platform basis. Otherwise it may be better to rename the file to avoid confusion. > I can provide a trivial fix for AIX (see below). But maybe somebody has a better idea? I would prefer to see the use of non-POSIX conforming code be conditionalized on the platforms that are known to support it - ie platforms have to specifically opt-in to using it because someone has determined that it does in fact work, and is needed, for that platform. That should have been done by the people who worked on 8190308. I can't expect you to do that for the other platforms, so fixing AIX the way you suggest is the most pragmatic thing to do right now. Thanks, David > Best regards, > Martin > > > --- a/src/hotspot/os/posix/os_posix.cpp Thu Nov 30 18:05:57 2017 +0100 > +++ b/src/hotspot/os/posix/os_posix.cpp Thu Nov 30 18:55:02 2017 +0100 > @@ -200,7 +200,7 @@ > > static char* reserve_mmapped_memory(size_t bytes, char* requested_addr) { > char * addr; > - int flags = MAP_PRIVATE | MAP_NORESERVE | MAP_ANONYMOUS; > + int flags = MAP_PRIVATE NOT_AIX( | MAP_NORESERVE ) | MAP_ANONYMOUS; > if (requested_addr != NULL) { > assert((uintptr_t)requested_addr % os::vm_page_size() == 0, "Requested address should be aligned to OS page size"); > flags |= MAP_FIXED; > From david.holmes at oracle.com Sun Dec 3 02:50:37 2017 From: david.holmes at oracle.com (David Holmes) Date: Sun, 3 Dec 2017 12:50:37 +1000 Subject: RFR(M): 8190308: Supporting heap allocation on alternative memory devices and CSR review In-Reply-To: <9d6f979d-5b7c-5a64-0f06-fdce3e16f9cd@oracle.com> References: <1509719477.3207.10.camel@oracle.com> <9b259cdd-111a-0634-80a1-0c6ba1a8d260@oracle.com> <4171dc3d-3a43-a455-0efb-ee5ff5640b93@oracle.com> <1510605610.7132.3.camel@oracle.com> <3e6131cd-bac3-c8db-971f-297bb13b087d@oracle.com> <9d6f979d-5b7c-5a64-0f06-fdce3e16f9cd@oracle.com> Message-ID: <53aada5a-ef6d-51d1-00b3-45476cdb2b73@oracle.com> On 2/12/2017 4:59 AM, sangheon.kim wrote: > Hi Martin, > > On 11/30/2017 10:08 AM, Doerr, Martin wrote: >> Hi, >> >> I just noticed that "MAP_NORESERVE" is not defined on AIX >> (os_posix.cpp reserve_mmapped_memory). >> I guess it's not POSIX, so this looks like a bug. > Yes, I agree. > I filed https://bugs.openjdk.java.net/browse/JDK-8192919 for this. > >> Would it make sense to replace it by "NOT_AIX( | MAP_NORESERVE )"? > That would be a good quick-fix for AIX. > > But MAP_ANONYMOUS (used with MAP_NORESERVE in that line) is also not > specified on POSIX as well. The difference is that most OS seem to > define it. Or line 56(#ifndef MAP_ANONYMOUS) makes to avoid the problem. > So I think it would be better to completely move these 2 flags out of > os_posix.cpp. Moved out or only used for each OS that has established they are correct for that OS. I've updated the bug with a request to re-open it. Thanks, David > Thanks, > Sangheon > > >> ? Or is there a better idea? >> >> Best regards, >> Martin >> >> >> -----Original Message----- >> From: hotspot-gc-dev [mailto:hotspot-gc-dev-bounces at openjdk.java.net] >> On Behalf Of Kharbas, Kishor >> Sent: Montag, 13. November 2017 22:33 >> To: sangheon.kim ; Thomas Schatzl >> ; 'hotspot-gc-dev at openjdk.java.net' >> ; hotspot-runtime-dev at openjdk.java.net >> Cc: Kharbas, Kishor >> Subject: RE: RFR(M): 8190308: Supporting heap allocation on >> alternative memory devices and CSR review >> >> Thanks Sangheon and Thomas! >> >> -----Original Message----- >> From: sangheon.kim [mailto:sangheon.kim at oracle.com] >> Sent: Monday, November 13, 2017 12:41 PM >> To: Thomas Schatzl ; Kharbas, Kishor >> ; 'hotspot-gc-dev at openjdk.java.net' >> ; hotspot-runtime-dev at openjdk.java.net >> Subject: Re: RFR(M): 8190308: Supporting heap allocation on >> alternative memory devices and CSR review >> >> Hi Kishor, >> >> On 11/13/2017 12:40 PM, Thomas Schatzl wrote: >>> Hi Kishor, >>> >>> On Mon, 2017-11-13 at 19:40 +0000, Kharbas, Kishor wrote: >>>> Greetings, >>>> I have an updated webrev to remove compilation warning on Windows 32- >>>> bit. >>>> http://cr.openjdk.java.net/~kkharbas/8190308/webrev.15/ >>>> http://cr.openjdk.java.net/~kkharbas/8190308/webrev.15_to_14/ >>>> Sorry missed this earlier. I request for a review on this update. >>> ??? looks good. The other changes from webrev.13 on also look good. >> +1 >> >> Thanks, >> Sangheon >> >> >>> Thanks, >>> ??? Thomas >>> >>>> Thanks >>>> Kishor >>>> From: sangheon.kim [mailto:sangheon.kim at oracle.com] >>>> Sent: Friday, November 3, 2017 4:07 PM >>>> To: Kharbas, Kishor ; Thomas Schatzl >>> s.schatzl at oracle.com>; 'hotspot-gc-dev at openjdk.java.net' >>> dev at openjdk.java.net>; hotspot-runtime-dev at openjdk.java.net >>>> Subject: Re: RFR(M): 8190308: Supporting heap allocation on >>>> alternative memory devices and CSR review >>>> Hi Kishor, >>>> >>>> >>>> On 11/03/2017 02:59 PM, Kharbas, Kishor wrote: >>>> Hi Sangheon, >>>> Here is link to the updated webrev- >>>> http://cr.openjdk.java.net/~kkharbas/8190308/webrev.14/ >>>> http://cr.openjdk.java.net/~kkharbas/8190308/webrev.14_to_13/ >>>> Looks good to me. >>>> >>>> Thanks, >>>> Sangheon >>>> >>>> >>>> >>>> Thanks >>>> Kishor >>>> From: sangheon.kim [mailto:sangheon.kim at oracle.com] >>>> Sent: Friday, November 3, 2017 2:38 PM >>>> To: Kharbas, Kishor ; Thomas Schatzl >>> s.schatzl at oracle.com>; 'hotspot-gc-dev at openjdk.java.net' >>> dev at openjdk.java.net>; hotspot-runtime-dev at openjdk.java.net >>>> Subject: Re: RFR(M): 8190308: Supporting heap allocation on >>>> alternative memory devices and CSR review >>>> Hi Kishor, >>>> >>>> On 11/03/2017 11:39 AM, Kharbas, Kishor wrote: >>>> Thanks a lot! >>>> Link to updated webrevs - >>>> http://cr.openjdk.java.net/~kkharbas/8190308/webrev.13/ >>>> http://cr.openjdk.java.net/~kkharbas/8190308/webrev.13_to_12/ >>>> Thank you for fixing all. >>>> Looks good to me except below. >>>> >>>> Could you update the copyright format in TestAllocateHeapAt.java? >>>> 2? * Copyright (c) 2017 Oracle and/or its affiliates. All rights >>>> reserved. >>>> - Missing comma: * Copyright (c) 2017, Oracle and/or its affiliates. >>>> All rights reserved. >>>> >>>> Thanks, >>>> Sangheon >>>> >>>> >>>> >>>> >>>> @Sangheon: Please let me know if you see any corrections needed. >>>> -Kishor >>>> -----Original Message----- >>>> From: Thomas Schatzl [mailto:thomas.schatzl at oracle.com] >>>> Sent: Friday, November 3, 2017 7:31 AM >>>> To: Kharbas, Kishor ; sangheon.kim >>>> ; 'hotspot-gc-dev at openjdk.java.net' >>>> ; hotspot-runtime- >>>> dev at openjdk.java.net >>>> Subject: Re: RFR(M): 8190308: Supporting heap allocation on >>>> alternative memory devices and CSR review >>>> Hi, >>>> On Fri, 2017-11-03 at 08:55 +0000, Kharbas, Kishor wrote: >>>> Hi Sangheon, >>>> Thanks for the review and comments. Here is an updated webrev- >>>> http://cr.openjdk.java.net/~kkharbas/8190308/webrev.12 >>>> http://cr.openjdk.java.net/~kkharbas/8190308/webrev.12_to_11 >>>> In addition to your suggested corrections, I added code to set Linux >>>> core dump filter ensuring Heap is dumped correctly when this feature >>>> is used. This is follow-up to Jini George?s comment >>>> (http://openjdk.5641.n7.nabble.com/RFR-M-8171181-Supporting-heap- >>>> allocation-on-alternative-memory-devices-td300109.html#a300450). >>>> Some minor nits: >>>> ? ?- os_posix.cpp:300: please move the else next to the brace >>>> ? ?- arguments.cpp:4624: please add a space between "if" and the >>>> bracket >>>> I do not need to see a new webrev for these changes. Looks good. >>>> Thanks, >>>> ? ? Thomas > From david.holmes at oracle.com Sun Dec 3 08:49:51 2017 From: david.holmes at oracle.com (David Holmes) Date: Sun, 3 Dec 2017 18:49:51 +1000 Subject: RFR 8154587: Resolution fails for default method named 'clone' In-Reply-To: <22c41169-4c42-bff3-5090-a27ad9019bff@oracle.com> References: <22c41169-4c42-bff3-5090-a27ad9019bff@oracle.com> Message-ID: <5da7a16a-4954-4ce2-aac3-89fe88581c82@oracle.com> Hi Harold, Can't review the details here as not familiar enough with default method rules, but one comment ... On 1/12/2017 2:15 AM, harold seigel wrote: > Hi, > > Please review this fix for JDK-8154587.? The fix adds additional special > casing to skip over non-public methods in class java.lang.Object during > default method and itable processing for interfaces.? These methods need > to be skipped over because of the interface method resolution rules in > JVM Spec 9, section 5.4.3.4 > : > > > ?? 3. Otherwise, if the class|Object|declares a method with the name > ?? and descriptor specified by the interface method reference, which > ?? has its|ACC_PUBLIC|flag set and does not have its|ACC_STATIC|flag > ?? set, method lookup succeeds. > > Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8154587/webrev/ ... I think in static bool is_nonpublic_jlo_method(Method* m) we can spell "jlo" as "Object" (e.g as with Object_klass and Object_klass_loaded()). Thanks, David > JBS Bug:? https://bugs.openjdk.java.net/browse/JDK-8154587 > > The fix was tested with JCK lang and VM tests, JTReg hotspot and many > JTReg JDK tests, M5 tier1 - tier5 tests, and JPRT. > > Thanks, Harold > From martin.doerr at sap.com Mon Dec 4 10:27:17 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 4 Dec 2017 10:27:17 +0000 Subject: RFR(M): 8190308: Supporting heap allocation on alternative memory devices and CSR review In-Reply-To: <53aada5a-ef6d-51d1-00b3-45476cdb2b73@oracle.com> References: <1509719477.3207.10.camel@oracle.com> <9b259cdd-111a-0634-80a1-0c6ba1a8d260@oracle.com> <4171dc3d-3a43-a455-0efb-ee5ff5640b93@oracle.com> <1510605610.7132.3.camel@oracle.com> <3e6131cd-bac3-c8db-971f-297bb13b087d@oracle.com> <9d6f979d-5b7c-5a64-0f06-fdce3e16f9cd@oracle.com> <53aada5a-ef6d-51d1-00b3-45476cdb2b73@oracle.com> Message-ID: Hi Sangheon and David, first of all, sorry that I forgot to mention JDK-8192898 "AIX build broken after JDK-8190308" in this email thread. It was a quick fix to get AIX working again for the jdk10 fork. Thanks for opening the new bug JDK-8192919 and for sharing your thoughts. Sounds like a nice cleanup for jdk11. Best regards, Martin -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Sonntag, 3. Dezember 2017 03:51 To: sangheon.kim ; Doerr, Martin ; Kharbas, Kishor ; Thomas Schatzl ; 'hotspot-gc-dev at openjdk.java.net' ; hotspot-runtime-dev at openjdk.java.net; Stuefe, Thomas Subject: Re: RFR(M): 8190308: Supporting heap allocation on alternative memory devices and CSR review On 2/12/2017 4:59 AM, sangheon.kim wrote: > Hi Martin, > > On 11/30/2017 10:08 AM, Doerr, Martin wrote: >> Hi, >> >> I just noticed that "MAP_NORESERVE" is not defined on AIX >> (os_posix.cpp reserve_mmapped_memory). >> I guess it's not POSIX, so this looks like a bug. > Yes, I agree. > I filed https://bugs.openjdk.java.net/browse/JDK-8192919 for this. > >> Would it make sense to replace it by "NOT_AIX( | MAP_NORESERVE )"? > That would be a good quick-fix for AIX. > > But MAP_ANONYMOUS (used with MAP_NORESERVE in that line) is also not > specified on POSIX as well. The difference is that most OS seem to > define it. Or line 56(#ifndef MAP_ANONYMOUS) makes to avoid the problem. > So I think it would be better to completely move these 2 flags out of > os_posix.cpp. Moved out or only used for each OS that has established they are correct for that OS. I've updated the bug with a request to re-open it. Thanks, David > Thanks, > Sangheon > > >> ? Or is there a better idea? >> >> Best regards, >> Martin >> >> >> -----Original Message----- >> From: hotspot-gc-dev [mailto:hotspot-gc-dev-bounces at openjdk.java.net] >> On Behalf Of Kharbas, Kishor >> Sent: Montag, 13. November 2017 22:33 >> To: sangheon.kim ; Thomas Schatzl >> ; 'hotspot-gc-dev at openjdk.java.net' >> ; hotspot-runtime-dev at openjdk.java.net >> Cc: Kharbas, Kishor >> Subject: RE: RFR(M): 8190308: Supporting heap allocation on >> alternative memory devices and CSR review >> >> Thanks Sangheon and Thomas! >> >> -----Original Message----- >> From: sangheon.kim [mailto:sangheon.kim at oracle.com] >> Sent: Monday, November 13, 2017 12:41 PM >> To: Thomas Schatzl ; Kharbas, Kishor >> ; 'hotspot-gc-dev at openjdk.java.net' >> ; hotspot-runtime-dev at openjdk.java.net >> Subject: Re: RFR(M): 8190308: Supporting heap allocation on >> alternative memory devices and CSR review >> >> Hi Kishor, >> >> On 11/13/2017 12:40 PM, Thomas Schatzl wrote: >>> Hi Kishor, >>> >>> On Mon, 2017-11-13 at 19:40 +0000, Kharbas, Kishor wrote: >>>> Greetings, >>>> I have an updated webrev to remove compilation warning on Windows 32- >>>> bit. >>>> http://cr.openjdk.java.net/~kkharbas/8190308/webrev.15/ >>>> http://cr.openjdk.java.net/~kkharbas/8190308/webrev.15_to_14/ >>>> Sorry missed this earlier. I request for a review on this update. >>> ??? looks good. The other changes from webrev.13 on also look good. >> +1 >> >> Thanks, >> Sangheon >> >> >>> Thanks, >>> ??? Thomas >>> >>>> Thanks >>>> Kishor >>>> From: sangheon.kim [mailto:sangheon.kim at oracle.com] >>>> Sent: Friday, November 3, 2017 4:07 PM >>>> To: Kharbas, Kishor ; Thomas Schatzl >>> s.schatzl at oracle.com>; 'hotspot-gc-dev at openjdk.java.net' >>> dev at openjdk.java.net>; hotspot-runtime-dev at openjdk.java.net >>>> Subject: Re: RFR(M): 8190308: Supporting heap allocation on >>>> alternative memory devices and CSR review >>>> Hi Kishor, >>>> >>>> >>>> On 11/03/2017 02:59 PM, Kharbas, Kishor wrote: >>>> Hi Sangheon, >>>> Here is link to the updated webrev- >>>> http://cr.openjdk.java.net/~kkharbas/8190308/webrev.14/ >>>> http://cr.openjdk.java.net/~kkharbas/8190308/webrev.14_to_13/ >>>> Looks good to me. >>>> >>>> Thanks, >>>> Sangheon >>>> >>>> >>>> >>>> Thanks >>>> Kishor >>>> From: sangheon.kim [mailto:sangheon.kim at oracle.com] >>>> Sent: Friday, November 3, 2017 2:38 PM >>>> To: Kharbas, Kishor ; Thomas Schatzl >>> s.schatzl at oracle.com>; 'hotspot-gc-dev at openjdk.java.net' >>> dev at openjdk.java.net>; hotspot-runtime-dev at openjdk.java.net >>>> Subject: Re: RFR(M): 8190308: Supporting heap allocation on >>>> alternative memory devices and CSR review >>>> Hi Kishor, >>>> >>>> On 11/03/2017 11:39 AM, Kharbas, Kishor wrote: >>>> Thanks a lot! >>>> Link to updated webrevs - >>>> http://cr.openjdk.java.net/~kkharbas/8190308/webrev.13/ >>>> http://cr.openjdk.java.net/~kkharbas/8190308/webrev.13_to_12/ >>>> Thank you for fixing all. >>>> Looks good to me except below. >>>> >>>> Could you update the copyright format in TestAllocateHeapAt.java? >>>> 2? * Copyright (c) 2017 Oracle and/or its affiliates. All rights >>>> reserved. >>>> - Missing comma: * Copyright (c) 2017, Oracle and/or its affiliates. >>>> All rights reserved. >>>> >>>> Thanks, >>>> Sangheon >>>> >>>> >>>> >>>> >>>> @Sangheon: Please let me know if you see any corrections needed. >>>> -Kishor >>>> -----Original Message----- >>>> From: Thomas Schatzl [mailto:thomas.schatzl at oracle.com] >>>> Sent: Friday, November 3, 2017 7:31 AM >>>> To: Kharbas, Kishor ; sangheon.kim >>>> ; 'hotspot-gc-dev at openjdk.java.net' >>>> ; hotspot-runtime- >>>> dev at openjdk.java.net >>>> Subject: Re: RFR(M): 8190308: Supporting heap allocation on >>>> alternative memory devices and CSR review >>>> Hi, >>>> On Fri, 2017-11-03 at 08:55 +0000, Kharbas, Kishor wrote: >>>> Hi Sangheon, >>>> Thanks for the review and comments. Here is an updated webrev- >>>> http://cr.openjdk.java.net/~kkharbas/8190308/webrev.12 >>>> http://cr.openjdk.java.net/~kkharbas/8190308/webrev.12_to_11 >>>> In addition to your suggested corrections, I added code to set Linux >>>> core dump filter ensuring Heap is dumped correctly when this feature >>>> is used. This is follow-up to Jini George?s comment >>>> (http://openjdk.5641.n7.nabble.com/RFR-M-8171181-Supporting-heap- >>>> allocation-on-alternative-memory-devices-td300109.html#a300450). >>>> Some minor nits: >>>> ? ?- os_posix.cpp:300: please move the else next to the brace >>>> ? ?- arguments.cpp:4624: please add a space between "if" and the >>>> bracket >>>> I do not need to see a new webrev for these changes. Looks good. >>>> Thanks, >>>> ? ? Thomas > From harold.seigel at oracle.com Mon Dec 4 14:24:05 2017 From: harold.seigel at oracle.com (harold seigel) Date: Mon, 4 Dec 2017 09:24:05 -0500 Subject: RFR 8154587: Resolution fails for default method named 'clone' In-Reply-To: <5da7a16a-4954-4ce2-aac3-89fe88581c82@oracle.com> References: <22c41169-4c42-bff3-5090-a27ad9019bff@oracle.com> <5da7a16a-4954-4ce2-aac3-89fe88581c82@oracle.com> Message-ID: <077dd6b7-acbd-1108-a54e-53c084f04101@oracle.com> Thanks David. I updated the webrev with that change. Harold On 12/3/2017 3:49 AM, David Holmes wrote: > Hi Harold, > > Can't review the details here as not familiar enough with default > method rules, but one comment ... > > On 1/12/2017 2:15 AM, harold seigel wrote: >> Hi, >> >> Please review this fix for JDK-8154587.? The fix adds additional >> special casing to skip over non-public methods in class >> java.lang.Object during default method and itable processing for >> interfaces.? These methods need to be skipped over because of the >> interface method resolution rules in JVM Spec 9, section 5.4.3.4 >> : >> >> >> ??? 3. Otherwise, if the class|Object|declares a method with the name >> ??? and descriptor specified by the interface method reference, which >> ??? has its|ACC_PUBLIC|flag set and does not have its|ACC_STATIC|flag >> ??? set, method lookup succeeds. >> >> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8154587/webrev/ > > ... I think in > > static bool is_nonpublic_jlo_method(Method* m) > > we can spell "jlo" as "Object" (e.g as with Object_klass and > Object_klass_loaded()). > > Thanks, > David > >> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8154587 >> >> The fix was tested with JCK lang and VM tests, JTReg hotspot and many >> JTReg JDK tests, M5 tier1 - tier5 tests, and JPRT. >> >> Thanks, Harold >> From lois.foltan at oracle.com Mon Dec 4 19:31:01 2017 From: lois.foltan at oracle.com (Lois Foltan) Date: Mon, 4 Dec 2017 14:31:01 -0500 Subject: RFR 8154587: Resolution fails for default method named 'clone' In-Reply-To: <22c41169-4c42-bff3-5090-a27ad9019bff@oracle.com> References: <22c41169-4c42-bff3-5090-a27ad9019bff@oracle.com> Message-ID: <3c0ff7a5-1a46-f4d9-c50a-6e6b322fdabc@oracle.com> Hi Harold, Fix looks good.? I would like to see three more test cases: ??? - the same test written for "finalize" since that is also a non-public method of Object. ??? - a test where class C does not define the method "clone", an IAE should result, correct? ??? - a test case where I2 defines a public method of Object Thanks, Lois On 11/30/2017 11:15 AM, harold seigel wrote: > Hi, > > Please review this fix for JDK-8154587.? The fix adds additional > special casing to skip over non-public methods in class > java.lang.Object during default method and itable processing for > interfaces.? These methods need to be skipped over because of the > interface method resolution rules in JVM Spec 9, section 5.4.3.4 > : > > ?? 3. Otherwise, if the class|Object|declares a method with the name > ?? and descriptor specified by the interface method reference, which > ?? has its|ACC_PUBLIC|flag set and does not have its|ACC_STATIC|flag > ?? set, method lookup succeeds. > > Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8154587/webrev/ > > JBS Bug:? https://bugs.openjdk.java.net/browse/JDK-8154587 > > The fix was tested with JCK lang and VM tests, JTReg hotspot and many > JTReg JDK tests, M5 tier1 - tier5 tests, and JPRT. > > Thanks, Harold > From sangheon.kim at oracle.com Mon Dec 4 19:38:58 2017 From: sangheon.kim at oracle.com (sangheon.kim) Date: Mon, 4 Dec 2017 11:38:58 -0800 Subject: RFR(M): 8190308: Supporting heap allocation on alternative memory devices and CSR review In-Reply-To: References: <1509719477.3207.10.camel@oracle.com> <9b259cdd-111a-0634-80a1-0c6ba1a8d260@oracle.com> <4171dc3d-3a43-a455-0efb-ee5ff5640b93@oracle.com> <1510605610.7132.3.camel@oracle.com> <3e6131cd-bac3-c8db-971f-297bb13b087d@oracle.com> <9d6f979d-5b7c-5a64-0f06-fdce3e16f9cd@oracle.com> <53aada5a-ef6d-51d1-00b3-45476cdb2b73@oracle.com> Message-ID: Hi David and Martin, I re-opened JDK-8192919 with a new title. This enhancement is to remove non-portable flags used in os_posix.cpp. Thanks, Sangheon On 12/04/2017 02:27 AM, Doerr, Martin wrote: > Hi Sangheon and David, > > first of all, sorry that I forgot to mention JDK-8192898 "AIX build broken after JDK-8190308" in this email thread. It was a quick fix to get AIX working again for the jdk10 fork. > > Thanks for opening the new bug JDK-8192919 and for sharing your thoughts. Sounds like a nice cleanup for jdk11. > > Best regards, > Martin > > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Sonntag, 3. Dezember 2017 03:51 > To: sangheon.kim ; Doerr, Martin ; Kharbas, Kishor ; Thomas Schatzl ; 'hotspot-gc-dev at openjdk.java.net' ; hotspot-runtime-dev at openjdk.java.net; Stuefe, Thomas > Subject: Re: RFR(M): 8190308: Supporting heap allocation on alternative memory devices and CSR review > > On 2/12/2017 4:59 AM, sangheon.kim wrote: >> Hi Martin, >> >> On 11/30/2017 10:08 AM, Doerr, Martin wrote: >>> Hi, >>> >>> I just noticed that "MAP_NORESERVE" is not defined on AIX >>> (os_posix.cpp reserve_mmapped_memory). >>> I guess it's not POSIX, so this looks like a bug. >> Yes, I agree. >> I filed https://bugs.openjdk.java.net/browse/JDK-8192919 for this. >> >>> Would it make sense to replace it by "NOT_AIX( | MAP_NORESERVE )"? >> That would be a good quick-fix for AIX. >> >> But MAP_ANONYMOUS (used with MAP_NORESERVE in that line) is also not >> specified on POSIX as well. The difference is that most OS seem to >> define it. Or line 56(#ifndef MAP_ANONYMOUS) makes to avoid the problem. >> So I think it would be better to completely move these 2 flags out of >> os_posix.cpp. > Moved out or only used for each OS that has established they are correct > for that OS. I've updated the bug with a request to re-open it. > > Thanks, > David > >> Thanks, >> Sangheon >> >> >>> ? Or is there a better idea? >>> >>> Best regards, >>> Martin >>> >>> >>> -----Original Message----- >>> From: hotspot-gc-dev [mailto:hotspot-gc-dev-bounces at openjdk.java.net] >>> On Behalf Of Kharbas, Kishor >>> Sent: Montag, 13. November 2017 22:33 >>> To: sangheon.kim ; Thomas Schatzl >>> ; 'hotspot-gc-dev at openjdk.java.net' >>> ; hotspot-runtime-dev at openjdk.java.net >>> Cc: Kharbas, Kishor >>> Subject: RE: RFR(M): 8190308: Supporting heap allocation on >>> alternative memory devices and CSR review >>> >>> Thanks Sangheon and Thomas! >>> >>> -----Original Message----- >>> From: sangheon.kim [mailto:sangheon.kim at oracle.com] >>> Sent: Monday, November 13, 2017 12:41 PM >>> To: Thomas Schatzl ; Kharbas, Kishor >>> ; 'hotspot-gc-dev at openjdk.java.net' >>> ; hotspot-runtime-dev at openjdk.java.net >>> Subject: Re: RFR(M): 8190308: Supporting heap allocation on >>> alternative memory devices and CSR review >>> >>> Hi Kishor, >>> >>> On 11/13/2017 12:40 PM, Thomas Schatzl wrote: >>>> Hi Kishor, >>>> >>>> On Mon, 2017-11-13 at 19:40 +0000, Kharbas, Kishor wrote: >>>>> Greetings, >>>>> I have an updated webrev to remove compilation warning on Windows 32- >>>>> bit. >>>>> http://cr.openjdk.java.net/~kkharbas/8190308/webrev.15/ >>>>> http://cr.openjdk.java.net/~kkharbas/8190308/webrev.15_to_14/ >>>>> Sorry missed this earlier. I request for a review on this update. >>>> ??? looks good. The other changes from webrev.13 on also look good. >>> +1 >>> >>> Thanks, >>> Sangheon >>> >>> >>>> Thanks, >>>> ??? Thomas >>>> >>>>> Thanks >>>>> Kishor >>>>> From: sangheon.kim [mailto:sangheon.kim at oracle.com] >>>>> Sent: Friday, November 3, 2017 4:07 PM >>>>> To: Kharbas, Kishor ; Thomas Schatzl >>>> s.schatzl at oracle.com>; 'hotspot-gc-dev at openjdk.java.net' >>>> dev at openjdk.java.net>; hotspot-runtime-dev at openjdk.java.net >>>>> Subject: Re: RFR(M): 8190308: Supporting heap allocation on >>>>> alternative memory devices and CSR review >>>>> Hi Kishor, >>>>> >>>>> >>>>> On 11/03/2017 02:59 PM, Kharbas, Kishor wrote: >>>>> Hi Sangheon, >>>>> Here is link to the updated webrev- >>>>> http://cr.openjdk.java.net/~kkharbas/8190308/webrev.14/ >>>>> http://cr.openjdk.java.net/~kkharbas/8190308/webrev.14_to_13/ >>>>> Looks good to me. >>>>> >>>>> Thanks, >>>>> Sangheon >>>>> >>>>> >>>>> >>>>> Thanks >>>>> Kishor >>>>> From: sangheon.kim [mailto:sangheon.kim at oracle.com] >>>>> Sent: Friday, November 3, 2017 2:38 PM >>>>> To: Kharbas, Kishor ; Thomas Schatzl >>>> s.schatzl at oracle.com>; 'hotspot-gc-dev at openjdk.java.net' >>>> dev at openjdk.java.net>; hotspot-runtime-dev at openjdk.java.net >>>>> Subject: Re: RFR(M): 8190308: Supporting heap allocation on >>>>> alternative memory devices and CSR review >>>>> Hi Kishor, >>>>> >>>>> On 11/03/2017 11:39 AM, Kharbas, Kishor wrote: >>>>> Thanks a lot! >>>>> Link to updated webrevs - >>>>> http://cr.openjdk.java.net/~kkharbas/8190308/webrev.13/ >>>>> http://cr.openjdk.java.net/~kkharbas/8190308/webrev.13_to_12/ >>>>> Thank you for fixing all. >>>>> Looks good to me except below. >>>>> >>>>> Could you update the copyright format in TestAllocateHeapAt.java? >>>>> 2? * Copyright (c) 2017 Oracle and/or its affiliates. All rights >>>>> reserved. >>>>> - Missing comma: * Copyright (c) 2017, Oracle and/or its affiliates. >>>>> All rights reserved. >>>>> >>>>> Thanks, >>>>> Sangheon >>>>> >>>>> >>>>> >>>>> >>>>> @Sangheon: Please let me know if you see any corrections needed. >>>>> -Kishor >>>>> -----Original Message----- >>>>> From: Thomas Schatzl [mailto:thomas.schatzl at oracle.com] >>>>> Sent: Friday, November 3, 2017 7:31 AM >>>>> To: Kharbas, Kishor ; sangheon.kim >>>>> ; 'hotspot-gc-dev at openjdk.java.net' >>>>> ; hotspot-runtime- >>>>> dev at openjdk.java.net >>>>> Subject: Re: RFR(M): 8190308: Supporting heap allocation on >>>>> alternative memory devices and CSR review >>>>> Hi, >>>>> On Fri, 2017-11-03 at 08:55 +0000, Kharbas, Kishor wrote: >>>>> Hi Sangheon, >>>>> Thanks for the review and comments. Here is an updated webrev- >>>>> http://cr.openjdk.java.net/~kkharbas/8190308/webrev.12 >>>>> http://cr.openjdk.java.net/~kkharbas/8190308/webrev.12_to_11 >>>>> In addition to your suggested corrections, I added code to set Linux >>>>> core dump filter ensuring Heap is dumped correctly when this feature >>>>> is used. This is follow-up to Jini George?s comment >>>>> (http://openjdk.5641.n7.nabble.com/RFR-M-8171181-Supporting-heap- >>>>> allocation-on-alternative-memory-devices-td300109.html#a300450). >>>>> Some minor nits: >>>>> ? ?- os_posix.cpp:300: please move the else next to the brace >>>>> ? ?- arguments.cpp:4624: please add a space between "if" and the >>>>> bracket >>>>> I do not need to see a new webrev for these changes. Looks good. >>>>> Thanks, >>>>> ? ? Thomas From daniel.daugherty at oracle.com Mon Dec 4 20:22:49 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 4 Dec 2017 15:22:49 -0500 Subject: RFR(S/M): 8191789 - migrate more Thread-SMR stuff from thread.[ch]pp -> threadSMR.[ch]pp Message-ID: <3cb950e3-6a99-1f45-9f45-b51e982f1777@oracle.com> Greetings, In terms of actual "new/changed" code, this is a "S" review. However, because of code motion, the changed/insert/delete counts are the size of an "M" or "L" review. Stefan K, this is one of your Thread-SMR follow-up suggestions so I need to hear from you on this thread. Thanks! I have a simple (but tedious) cleanup fix for Thread-SMR. The bug is: ??? JDK-8191789 migrate more Thread-SMR stuff from thread.[ch]pp -> threadSMR.[ch]pp ??? https://bugs.openjdk.java.net/browse/JDK-8191789 This fix is mostly code motion: - move Thread-SMR related code from thread.cpp -> threadSMR.cpp and ? from thread.hpp -> threadSMR.hpp ? - move Threads::_smr_* fields -> ThreadsSMRSupport class ? - move Thread-SMR functions from Threads -> ThreadsSMRSupport class ? - move Thread-SMR helper classes from thread.cpp -> threadsSMR.cpp ? - rename a bunch of Threads::foo() calls -> ThreadsSMRSupport::foo() - collateral changes: ? - DO_JAVA_THREADS macro usage by code moved to threadSMR.cpp have ??? to switch to JavaThreadIterator or some other function. ? - Add ThreadsSMRSupport::inc_smr_java_thread_list_alloc_cnt(). ? - Add ThreadsSMRSupport::update_smr_java_thread_list_max(). ? - Cleanup "friends" for Thread class and ThreadsList class. ? - Add includes of runtime/threadSMR.hpp in a few files. Here is the webrev URL: http://cr.openjdk.java.net/~dcubed/8191789-webrev/jdk10-0 This fix was (over) tested with a Mach5 tier[1-5] run. There were no unexpected test failures. These changes were sanity checked a couple of ways: - Compare pre-Thread-SMR thread.[ch]pp with thread.[ch]pp after this fix ? - Make sure that remaining Thread-SMR changes in thread.cpp and ??? thread.hpp make sense to leave behind. ? - Similar comparison for thread.inline.hpp. - Compare code removed from thread.cpp with code added to threadSMR.cpp, ? compare code removed from thread.hpp with code added to threadSMR.hpp, ? compare code removed from thread.inline.hpp with code added to ? threadSMR.inline.hpp: ? - Make sure the deltas make sense. Thanks, in advance, for any comments, questions or suggestions. Dan From daniel.daugherty at oracle.com Tue Dec 5 14:43:33 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 5 Dec 2017 09:43:33 -0500 Subject: RFR(S/M): 8191789 - migrate more Thread-SMR stuff from thread.[ch]pp -> threadSMR.[ch]pp In-Reply-To: <3cb950e3-6a99-1f45-9f45-b51e982f1777@oracle.com> References: <3cb950e3-6a99-1f45-9f45-b51e982f1777@oracle.com> Message-ID: <6da0a26e-a18b-ae13-3533-0b430a1aed0b@oracle.com> Did a sanity check self-review and found a couple of things in threadSMR.cpp are out of sort order: - moved ThreadsList::remove_thread() - moved ThreadsListSetter::~ThreadsListSetter() and ThreadsListSetter::set() These are pure code motion and I'll include those changes in delta webrev after making any other changes from the reviewers. Dan On 12/4/17 3:22 PM, Daniel D. Daugherty wrote: > Greetings, > > In terms of actual "new/changed" code, this is a "S" review. However, > because of code motion, the changed/insert/delete counts are the size > of an "M" or "L" review. > > Stefan K, this is one of your Thread-SMR follow-up suggestions so I need > to hear from you on this thread. Thanks! > > I have a simple (but tedious) cleanup fix for Thread-SMR. The bug is: > > ??? JDK-8191789 migrate more Thread-SMR stuff from thread.[ch]pp -> > threadSMR.[ch]pp > ??? https://bugs.openjdk.java.net/browse/JDK-8191789 > > This fix is mostly code motion: > > - move Thread-SMR related code from thread.cpp -> threadSMR.cpp and > ? from thread.hpp -> threadSMR.hpp > ? - move Threads::_smr_* fields -> ThreadsSMRSupport class > ? - move Thread-SMR functions from Threads -> ThreadsSMRSupport class > ? - move Thread-SMR helper classes from thread.cpp -> threadsSMR.cpp > ? - rename a bunch of Threads::foo() calls -> ThreadsSMRSupport::foo() > > - collateral changes: > ? - DO_JAVA_THREADS macro usage by code moved to threadSMR.cpp have > ??? to switch to JavaThreadIterator or some other function. > ? - Add ThreadsSMRSupport::inc_smr_java_thread_list_alloc_cnt(). > ? - Add ThreadsSMRSupport::update_smr_java_thread_list_max(). > ? - Cleanup "friends" for Thread class and ThreadsList class. > ? - Add includes of runtime/threadSMR.hpp in a few files. > > > Here is the webrev URL: > > http://cr.openjdk.java.net/~dcubed/8191789-webrev/jdk10-0 > > This fix was (over) tested with a Mach5 tier[1-5] run. There were no > unexpected test failures. > > These changes were sanity checked a couple of ways: > > - Compare pre-Thread-SMR thread.[ch]pp with thread.[ch]pp after this fix > ? - Make sure that remaining Thread-SMR changes in thread.cpp and > ??? thread.hpp make sense to leave behind. > ? - Similar comparison for thread.inline.hpp. > - Compare code removed from thread.cpp with code added to threadSMR.cpp, > ? compare code removed from thread.hpp with code added to threadSMR.hpp, > ? compare code removed from thread.inline.hpp with code added to > ? threadSMR.inline.hpp: > ? - Make sure the deltas make sense. > > Thanks, in advance, for any comments, questions or suggestions. > > Dan > From stefan.karlsson at oracle.com Tue Dec 5 15:07:31 2017 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 5 Dec 2017 16:07:31 +0100 Subject: RFR(S/M): 8191789 - migrate more Thread-SMR stuff from thread.[ch]pp -> threadSMR.[ch]pp In-Reply-To: <3cb950e3-6a99-1f45-9f45-b51e982f1777@oracle.com> References: <3cb950e3-6a99-1f45-9f45-b51e982f1777@oracle.com> Message-ID: <23a9eed8-6f54-ea60-9910-f9409addd952@oracle.com> On 2017-12-04 21:22, Daniel D. Daugherty wrote: > Greetings, > > In terms of actual "new/changed" code, this is a "S" review. However, > because of code motion, the changed/insert/delete counts are the size > of an "M" or "L" review. > > Stefan K, this is one of your Thread-SMR follow-up suggestions so I need > to hear from you on this thread. Thanks! Seems like a good step to me. ======================================================================== http://cr.openjdk.java.net/~dcubed/8191789-webrev/jdk10-0/src/hotspot/share/runtime/threadSMR.hpp.udiff.html Now that you have moved all these functions and variables to a class named ThreadsSMRSupport maybe you want to consider getting rid of the redundant _smr_ prefix/infix? Preexisting: I think you missed moving this in your previous cleanup: + static bool is_a_protected_JavaThread_with_lock(JavaThread *thread) { + MutexLockerEx ml(Threads_lock->owned_by_self() ? NULL : Threads_lock); + return is_a_protected_JavaThread(thread); + } ======================================================================== http://cr.openjdk.java.net/~dcubed/8191789-webrev/jdk10-0/src/hotspot/share/runtime/thread.cpp.frames.html Would it make sense to move the following code sections into functions in ThreadsSMRSupport? That way we could minimize the number of public functions exposed from ThreadSMRSupport. --- 4369 // Maintain fast thread list 4370 ThreadsList *new_list = ThreadsList::add_thread(ThreadsSMRSupport::get_smr_java_thread_list(), p); 4371 if (EnableThreadSMRStatistics) { 4372 ThreadsSMRSupport::inc_smr_java_thread_list_alloc_cnt(); 4373 ThreadsSMRSupport::update_smr_java_thread_list_max(new_list->length()); 4374 } 4375 // Initial _smr_java_thread_list will not generate a "Threads::add" mesg. 4376 log_debug(thread, smr)("tid=" UINTX_FORMAT ": Threads::add: new ThreadsList=" INTPTR_FORMAT, os::current_thread_id(), p2i(new_list)); 4377 4378 ThreadsList *old_list = ThreadsSMRSupport::xchg_smr_java_thread_list(new_list); 4379 ThreadsSMRSupport::smr_free_list(old_list); --- 4396 // Maintain fast thread list 4397 ThreadsList *new_list = ThreadsList::remove_thread(ThreadsSMRSupport::get_smr_java_thread_list(), p); 4398 if (EnableThreadSMRStatistics) { 4399 ThreadsSMRSupport::inc_smr_java_thread_list_alloc_cnt(); 4400 // This list is smaller so no need to check for a "longest" update. 4401 } 4402 4403 // Final _smr_java_thread_list will not generate a "Threads::remove" mesg. 4404 log_debug(thread, smr)("tid=" UINTX_FORMAT ": Threads::remove: new ThreadsList=" INTPTR_FORMAT, os::current_thread_id(), p2i(new_list)); 4405 4406 ThreadsList *old_list = ThreadsSMRSupport::xchg_smr_java_thread_list(new_list); 4407 ThreadsSMRSupport::smr_free_list(old_list); Thanks, StefanK > > I have a simple (but tedious) cleanup fix for Thread-SMR. The bug is: > > ??? JDK-8191789 migrate more Thread-SMR stuff from thread.[ch]pp -> > threadSMR.[ch]pp > ??? https://bugs.openjdk.java.net/browse/JDK-8191789 > > This fix is mostly code motion: > > - move Thread-SMR related code from thread.cpp -> threadSMR.cpp and > ? from thread.hpp -> threadSMR.hpp > ? - move Threads::_smr_* fields -> ThreadsSMRSupport class > ? - move Thread-SMR functions from Threads -> ThreadsSMRSupport class > ? - move Thread-SMR helper classes from thread.cpp -> threadsSMR.cpp > ? - rename a bunch of Threads::foo() calls -> ThreadsSMRSupport::foo() > > - collateral changes: > ? - DO_JAVA_THREADS macro usage by code moved to threadSMR.cpp have > ??? to switch to JavaThreadIterator or some other function. > ? - Add ThreadsSMRSupport::inc_smr_java_thread_list_alloc_cnt(). > ? - Add ThreadsSMRSupport::update_smr_java_thread_list_max(). > ? - Cleanup "friends" for Thread class and ThreadsList class. > ? - Add includes of runtime/threadSMR.hpp in a few files. > > > Here is the webrev URL: > > http://cr.openjdk.java.net/~dcubed/8191789-webrev/jdk10-0 > > This fix was (over) tested with a Mach5 tier[1-5] run. There were no > unexpected test failures. > > These changes were sanity checked a couple of ways: > > - Compare pre-Thread-SMR thread.[ch]pp with thread.[ch]pp after this fix > ? - Make sure that remaining Thread-SMR changes in thread.cpp and > ??? thread.hpp make sense to leave behind. > ? - Similar comparison for thread.inline.hpp. > - Compare code removed from thread.cpp with code added to threadSMR.cpp, > ? compare code removed from thread.hpp with code added to threadSMR.hpp, > ? compare code removed from thread.inline.hpp with code added to > ? threadSMR.inline.hpp: > ? - Make sure the deltas make sense. > > Thanks, in advance, for any comments, questions or suggestions. > > Dan From daniel.daugherty at oracle.com Tue Dec 5 15:27:47 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 5 Dec 2017 10:27:47 -0500 Subject: RFR(S/M): 8191789 - migrate more Thread-SMR stuff from thread.[ch]pp -> threadSMR.[ch]pp In-Reply-To: <23a9eed8-6f54-ea60-9910-f9409addd952@oracle.com> References: <3cb950e3-6a99-1f45-9f45-b51e982f1777@oracle.com> <23a9eed8-6f54-ea60-9910-f9409addd952@oracle.com> Message-ID: <37c8a497-7051-3e5d-8d4a-7af5c2921546@oracle.com> Stefan, Thanks for the fast review! Replies embedded below... On 12/5/17 10:07 AM, Stefan Karlsson wrote: > On 2017-12-04 21:22, Daniel D. Daugherty wrote: >> Greetings, >> >> In terms of actual "new/changed" code, this is a "S" review. However, >> because of code motion, the changed/insert/delete counts are the size >> of an "M" or "L" review. >> >> Stefan K, this is one of your Thread-SMR follow-up suggestions so I need >> to hear from you on this thread. Thanks! > > Seems like a good step to me. Thanks! We discussed this during the Thread-SMR project, but didn't do it before going out for OpenJDK review. It was your comment that motivated us to finally do it... :-) > ======================================================================== > http://cr.openjdk.java.net/~dcubed/8191789-webrev/jdk10-0/src/hotspot/share/runtime/threadSMR.hpp.udiff.html > > > Now that you have moved all these functions and variables to a class > named ThreadsSMRSupport maybe you want to consider getting rid of the > redundant _smr_ prefix/infix? I thought about that, but it made the sanity checking phase much more difficult because of the noise level in the diffs. What I could do is make that change as the last patch before qfold and qfinish... > Preexisting: I think you missed moving this in your previous cleanup: > > +? static bool is_a_protected_JavaThread_with_lock(JavaThread *thread) { > +??? MutexLockerEx ml(Threads_lock->owned_by_self() ? NULL : > Threads_lock); > +??? return is_a_protected_JavaThread(thread); > +? } Sorry, I don't know what you mean here. is_a_protected_JavaThread_with_lock() was in the Threads class and now is in the ThreadsSMRSupport class... What kind of move did I miss? > ======================================================================== > http://cr.openjdk.java.net/~dcubed/8191789-webrev/jdk10-0/src/hotspot/share/runtime/thread.cpp.frames.html > > > Would it make sense to move the following code sections into functions > in ThreadsSMRSupport? That way we could minimize the number of public > functions exposed from ThreadSMRSupport. > > --- > 4369?? // Maintain fast thread list > 4370?? ThreadsList *new_list = > ThreadsList::add_thread(ThreadsSMRSupport::get_smr_java_thread_list(), > p); > 4371?? if (EnableThreadSMRStatistics) { > 4372???? ThreadsSMRSupport::inc_smr_java_thread_list_alloc_cnt(); > 4373 > ThreadsSMRSupport::update_smr_java_thread_list_max(new_list->length()); > 4374?? } > 4375?? // Initial _smr_java_thread_list will not generate a > "Threads::add" mesg. > 4376?? log_debug(thread, smr)("tid=" UINTX_FORMAT ": Threads::add: new > ThreadsList=" INTPTR_FORMAT, os::current_thread_id(), p2i(new_list)); > 4377 > 4378?? ThreadsList *old_list = > ThreadsSMRSupport::xchg_smr_java_thread_list(new_list); > 4379?? ThreadsSMRSupport::smr_free_list(old_list); Sure. We could refactor this into ThreadsSMRSupport::add_thread()... > --- > 4396???? // Maintain fast thread list > 4397???? ThreadsList *new_list = > ThreadsList::remove_thread(ThreadsSMRSupport::get_smr_java_thread_list(), > p); > 4398???? if (EnableThreadSMRStatistics) { > 4399 ThreadsSMRSupport::inc_smr_java_thread_list_alloc_cnt(); > 4400?????? // This list is smaller so no need to check for a "longest" > update. > 4401???? } > 4402 > 4403???? // Final _smr_java_thread_list will not generate a > "Threads::remove" mesg. > 4404???? log_debug(thread, smr)("tid=" UINTX_FORMAT ": > Threads::remove: new ThreadsList=" INTPTR_FORMAT, > os::current_thread_id(), p2i(new_list)); > 4405 > 4406???? ThreadsList *old_list = > ThreadsSMRSupport::xchg_smr_java_thread_list(new_list); > 4407???? ThreadsSMRSupport::smr_free_list(old_list); And we could refactor this into ThreadsSMRSupport::remove_thread()... That would lighten the Thread-SMR footprint in thread.cpp even more... Dan > > Thanks, > StefanK > >> >> I have a simple (but tedious) cleanup fix for Thread-SMR. The bug is: >> >> ???? JDK-8191789 migrate more Thread-SMR stuff from thread.[ch]pp -> >> threadSMR.[ch]pp >> ???? https://bugs.openjdk.java.net/browse/JDK-8191789 >> >> This fix is mostly code motion: >> >> - move Thread-SMR related code from thread.cpp -> threadSMR.cpp and >> ?? from thread.hpp -> threadSMR.hpp >> ?? - move Threads::_smr_* fields -> ThreadsSMRSupport class >> ?? - move Thread-SMR functions from Threads -> ThreadsSMRSupport class >> ?? - move Thread-SMR helper classes from thread.cpp -> threadsSMR.cpp >> ?? - rename a bunch of Threads::foo() calls -> ThreadsSMRSupport::foo() >> >> - collateral changes: >> ?? - DO_JAVA_THREADS macro usage by code moved to threadSMR.cpp have >> ???? to switch to JavaThreadIterator or some other function. >> ?? - Add ThreadsSMRSupport::inc_smr_java_thread_list_alloc_cnt(). >> ?? - Add ThreadsSMRSupport::update_smr_java_thread_list_max(). >> ?? - Cleanup "friends" for Thread class and ThreadsList class. >> ?? - Add includes of runtime/threadSMR.hpp in a few files. >> >> >> Here is the webrev URL: >> >> http://cr.openjdk.java.net/~dcubed/8191789-webrev/jdk10-0 >> >> This fix was (over) tested with a Mach5 tier[1-5] run. There were no >> unexpected test failures. >> >> These changes were sanity checked a couple of ways: >> >> - Compare pre-Thread-SMR thread.[ch]pp with thread.[ch]pp after this fix >> ?? - Make sure that remaining Thread-SMR changes in thread.cpp and >> ???? thread.hpp make sense to leave behind. >> ?? - Similar comparison for thread.inline.hpp. >> - Compare code removed from thread.cpp with code added to threadSMR.cpp, >> ?? compare code removed from thread.hpp with code added to >> threadSMR.hpp, >> ?? compare code removed from thread.inline.hpp with code added to >> ?? threadSMR.inline.hpp: >> ?? - Make sure the deltas make sense. >> >> Thanks, in advance, for any comments, questions or suggestions. >> >> Dan From stefan.karlsson at oracle.com Tue Dec 5 16:22:56 2017 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 5 Dec 2017 17:22:56 +0100 Subject: RFR(S/M): 8191789 - migrate more Thread-SMR stuff from thread.[ch]pp -> threadSMR.[ch]pp In-Reply-To: <37c8a497-7051-3e5d-8d4a-7af5c2921546@oracle.com> References: <3cb950e3-6a99-1f45-9f45-b51e982f1777@oracle.com> <23a9eed8-6f54-ea60-9910-f9409addd952@oracle.com> <37c8a497-7051-3e5d-8d4a-7af5c2921546@oracle.com> Message-ID: <3f496265-7f22-91a8-48f6-1bf8b6280714@oracle.com> Hi Dan, On 2017-12-05 16:27, Daniel D. Daugherty wrote: > Stefan, > > Thanks for the fast review! > > Replies embedded below... > > On 12/5/17 10:07 AM, Stefan Karlsson wrote: >> On 2017-12-04 21:22, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> In terms of actual "new/changed" code, this is a "S" review. However, >>> because of code motion, the changed/insert/delete counts are the size >>> of an "M" or "L" review. >>> >>> Stefan K, this is one of your Thread-SMR follow-up suggestions so I need >>> to hear from you on this thread. Thanks! >> >> Seems like a good step to me. > > Thanks! We discussed this during the Thread-SMR project, but didn't > do it before going out for OpenJDK review. It was your comment that > motivated us to finally do it... :-) > > >> ======================================================================== >> http://cr.openjdk.java.net/~dcubed/8191789-webrev/jdk10-0/src/hotspot/share/runtime/threadSMR.hpp.udiff.html >> >> >> Now that you have moved all these functions and variables to a class >> named ThreadsSMRSupport maybe you want to consider getting rid of the >> redundant _smr_ prefix/infix? > > I thought about that, but it made the sanity checking phase much more > difficult because of the noise level in the diffs. What I could do is > make that change as the last patch before qfold and qfinish... > It makes sense to me to not change it while moving the files. I think its better to push that change as a separate RFE. > >> Preexisting: I think you missed moving this in your previous cleanup: >> >> +? static bool is_a_protected_JavaThread_with_lock(JavaThread *thread) { >> +??? MutexLockerEx ml(Threads_lock->owned_by_self() ? NULL : >> Threads_lock); >> +??? return is_a_protected_JavaThread(thread); >> +? } > > Sorry, I don't know what you mean here. > is_a_protected_JavaThread_with_lock() > was in the Threads class and now is in the ThreadsSMRSupport class... What > kind of move did I miss? I should have been more clear. This function should preferably move out from the header file into an .inline.hpp or .cpp file. During pre-reviews of the SMR work we discussed this, but it seems like we missed this function. This can be handled by a separate RFE. > > >> ======================================================================== >> http://cr.openjdk.java.net/~dcubed/8191789-webrev/jdk10-0/src/hotspot/share/runtime/thread.cpp.frames.html >> >> >> Would it make sense to move the following code sections into functions >> in ThreadsSMRSupport? That way we could minimize the number of public >> functions exposed from ThreadSMRSupport. >> >> --- >> 4369?? // Maintain fast thread list >> 4370?? ThreadsList *new_list = >> ThreadsList::add_thread(ThreadsSMRSupport::get_smr_java_thread_list(), >> p); >> 4371?? if (EnableThreadSMRStatistics) { >> 4372???? ThreadsSMRSupport::inc_smr_java_thread_list_alloc_cnt(); >> 4373 >> ThreadsSMRSupport::update_smr_java_thread_list_max(new_list->length()); >> 4374?? } >> 4375?? // Initial _smr_java_thread_list will not generate a >> "Threads::add" mesg. >> 4376?? log_debug(thread, smr)("tid=" UINTX_FORMAT ": Threads::add: new >> ThreadsList=" INTPTR_FORMAT, os::current_thread_id(), p2i(new_list)); >> 4377 >> 4378?? ThreadsList *old_list = >> ThreadsSMRSupport::xchg_smr_java_thread_list(new_list); >> 4379?? ThreadsSMRSupport::smr_free_list(old_list); > > Sure. We could refactor this into ThreadsSMRSupport::add_thread()... > > >> --- >> 4396???? // Maintain fast thread list >> 4397???? ThreadsList *new_list = >> ThreadsList::remove_thread(ThreadsSMRSupport::get_smr_java_thread_list(), >> p); >> 4398???? if (EnableThreadSMRStatistics) { >> 4399 ThreadsSMRSupport::inc_smr_java_thread_list_alloc_cnt(); >> 4400?????? // This list is smaller so no need to check for a "longest" >> update. >> 4401???? } >> 4402 >> 4403???? // Final _smr_java_thread_list will not generate a >> "Threads::remove" mesg. >> 4404???? log_debug(thread, smr)("tid=" UINTX_FORMAT ": >> Threads::remove: new ThreadsList=" INTPTR_FORMAT, >> os::current_thread_id(), p2i(new_list)); >> 4405 >> 4406???? ThreadsList *old_list = >> ThreadsSMRSupport::xchg_smr_java_thread_list(new_list); >> 4407???? ThreadsSMRSupport::smr_free_list(old_list); > > And we could refactor this into ThreadsSMRSupport::remove_thread()... > > That would lighten the Thread-SMR footprint in thread.cpp even more... Sounds good to me. Thanks, StefanK > > Dan > > >> >> Thanks, >> StefanK >> >>> >>> I have a simple (but tedious) cleanup fix for Thread-SMR. The bug is: >>> >>> ???? JDK-8191789 migrate more Thread-SMR stuff from thread.[ch]pp -> >>> threadSMR.[ch]pp >>> ???? https://bugs.openjdk.java.net/browse/JDK-8191789 >>> >>> This fix is mostly code motion: >>> >>> - move Thread-SMR related code from thread.cpp -> threadSMR.cpp and >>> ?? from thread.hpp -> threadSMR.hpp >>> ?? - move Threads::_smr_* fields -> ThreadsSMRSupport class >>> ?? - move Thread-SMR functions from Threads -> ThreadsSMRSupport class >>> ?? - move Thread-SMR helper classes from thread.cpp -> threadsSMR.cpp >>> ?? - rename a bunch of Threads::foo() calls -> ThreadsSMRSupport::foo() >>> >>> - collateral changes: >>> ?? - DO_JAVA_THREADS macro usage by code moved to threadSMR.cpp have >>> ???? to switch to JavaThreadIterator or some other function. >>> ?? - Add ThreadsSMRSupport::inc_smr_java_thread_list_alloc_cnt(). >>> ?? - Add ThreadsSMRSupport::update_smr_java_thread_list_max(). >>> ?? - Cleanup "friends" for Thread class and ThreadsList class. >>> ?? - Add includes of runtime/threadSMR.hpp in a few files. >>> >>> >>> Here is the webrev URL: >>> >>> http://cr.openjdk.java.net/~dcubed/8191789-webrev/jdk10-0 >>> >>> This fix was (over) tested with a Mach5 tier[1-5] run. There were no >>> unexpected test failures. >>> >>> These changes were sanity checked a couple of ways: >>> >>> - Compare pre-Thread-SMR thread.[ch]pp with thread.[ch]pp after this fix >>> ?? - Make sure that remaining Thread-SMR changes in thread.cpp and >>> ???? thread.hpp make sense to leave behind. >>> ?? - Similar comparison for thread.inline.hpp. >>> - Compare code removed from thread.cpp with code added to threadSMR.cpp, >>> ?? compare code removed from thread.hpp with code added to >>> threadSMR.hpp, >>> ?? compare code removed from thread.inline.hpp with code added to >>> ?? threadSMR.inline.hpp: >>> ?? - Make sure the deltas make sense. >>> >>> Thanks, in advance, for any comments, questions or suggestions. >>> >>> Dan > From daniel.daugherty at oracle.com Tue Dec 5 16:47:55 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 5 Dec 2017 11:47:55 -0500 Subject: RFR(S/M): 8191789 - migrate more Thread-SMR stuff from thread.[ch]pp -> threadSMR.[ch]pp In-Reply-To: <3f496265-7f22-91a8-48f6-1bf8b6280714@oracle.com> References: <3cb950e3-6a99-1f45-9f45-b51e982f1777@oracle.com> <23a9eed8-6f54-ea60-9910-f9409addd952@oracle.com> <37c8a497-7051-3e5d-8d4a-7af5c2921546@oracle.com> <3f496265-7f22-91a8-48f6-1bf8b6280714@oracle.com> Message-ID: <83baf68d-04c0-8173-e2e9-f82b42af9144@oracle.com> On 12/5/17 11:22 AM, Stefan Karlsson wrote: > Hi Dan, > > On 2017-12-05 16:27, Daniel D. Daugherty wrote: >> Stefan, >> >> Thanks for the fast review! >> >> Replies embedded below... >> >> On 12/5/17 10:07 AM, Stefan Karlsson wrote: >>> On 2017-12-04 21:22, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> In terms of actual "new/changed" code, this is a "S" review. However, >>>> because of code motion, the changed/insert/delete counts are the size >>>> of an "M" or "L" review. >>>> >>>> Stefan K, this is one of your Thread-SMR follow-up suggestions so I >>>> need >>>> to hear from you on this thread. Thanks! >>> >>> Seems like a good step to me. >> >> Thanks! We discussed this during the Thread-SMR project, but didn't >> do it before going out for OpenJDK review. It was your comment that >> motivated us to finally do it... :-) >> >> >>> ======================================================================== >>> >>> http://cr.openjdk.java.net/~dcubed/8191789-webrev/jdk10-0/src/hotspot/share/runtime/threadSMR.hpp.udiff.html >>> >>> >>> Now that you have moved all these functions and variables to a class >>> named ThreadsSMRSupport maybe you want to consider getting rid of >>> the redundant _smr_ prefix/infix? >> >> I thought about that, but it made the sanity checking phase much more >> difficult because of the noise level in the diffs. What I could do is >> make that change as the last patch before qfold and qfinish... >> > > It makes sense to me to not change it while moving the files. I think > its better to push that change as a separate RFE. Okay. I'll take it on as a separate changeset. > >> >>> Preexisting: I think you missed moving this in your previous cleanup: >>> >>> +? static bool is_a_protected_JavaThread_with_lock(JavaThread >>> *thread) { >>> +??? MutexLockerEx ml(Threads_lock->owned_by_self() ? NULL : >>> Threads_lock); >>> +??? return is_a_protected_JavaThread(thread); >>> +? } >> >> Sorry, I don't know what you mean here. >> is_a_protected_JavaThread_with_lock() >> was in the Threads class and now is in the ThreadsSMRSupport class... >> What >> kind of move did I miss? > > I should have been more clear. This function should preferably move > out from the header file into an .inline.hpp or .cpp file. During > pre-reviews of the SMR work we discussed this, but it seems like we > missed this function. This can be handled by a separate RFE. Since that one wasn't tagged as "inline" so I didn't move it earlier; my focus in that review cycle was moving inlines out of .hpp files. I can move it now (and will likely make it an inline)... > >> >> >>> ======================================================================== >>> >>> http://cr.openjdk.java.net/~dcubed/8191789-webrev/jdk10-0/src/hotspot/share/runtime/thread.cpp.frames.html >>> >>> >>> Would it make sense to move the following code sections into >>> functions in ThreadsSMRSupport? That way we could minimize the >>> number of public functions exposed from ThreadSMRSupport. >>> >>> --- >>> 4369?? // Maintain fast thread list >>> 4370?? ThreadsList *new_list = >>> ThreadsList::add_thread(ThreadsSMRSupport::get_smr_java_thread_list(), >>> p); >>> 4371?? if (EnableThreadSMRStatistics) { >>> 4372 ThreadsSMRSupport::inc_smr_java_thread_list_alloc_cnt(); >>> 4373 >>> ThreadsSMRSupport::update_smr_java_thread_list_max(new_list->length()); >>> 4374?? } >>> 4375?? // Initial _smr_java_thread_list will not generate a >>> "Threads::add" mesg. >>> 4376?? log_debug(thread, smr)("tid=" UINTX_FORMAT ": Threads::add: >>> new ThreadsList=" INTPTR_FORMAT, os::current_thread_id(), >>> p2i(new_list)); >>> 4377 >>> 4378?? ThreadsList *old_list = >>> ThreadsSMRSupport::xchg_smr_java_thread_list(new_list); >>> 4379?? ThreadsSMRSupport::smr_free_list(old_list); >> >> Sure. We could refactor this into ThreadsSMRSupport::add_thread()... >> >> >>> --- >>> 4396???? // Maintain fast thread list >>> 4397???? ThreadsList *new_list = >>> ThreadsList::remove_thread(ThreadsSMRSupport::get_smr_java_thread_list(), >>> p); >>> 4398???? if (EnableThreadSMRStatistics) { >>> 4399 ThreadsSMRSupport::inc_smr_java_thread_list_alloc_cnt(); >>> 4400?????? // This list is smaller so no need to check for a >>> "longest" update. >>> 4401???? } >>> 4402 >>> 4403???? // Final _smr_java_thread_list will not generate a >>> "Threads::remove" mesg. >>> 4404???? log_debug(thread, smr)("tid=" UINTX_FORMAT ": >>> Threads::remove: new ThreadsList=" INTPTR_FORMAT, >>> os::current_thread_id(), p2i(new_list)); >>> 4405 >>> 4406???? ThreadsList *old_list = >>> ThreadsSMRSupport::xchg_smr_java_thread_list(new_list); >>> 4407???? ThreadsSMRSupport::smr_free_list(old_list); >> >> And we could refactor this into ThreadsSMRSupport::remove_thread()... >> >> That would lighten the Thread-SMR footprint in thread.cpp even more... > > Sounds good to me. Thanks. Dan > > Thanks, > StefanK > >> >> Dan >> >> >>> >>> Thanks, >>> StefanK >>> >>>> >>>> I have a simple (but tedious) cleanup fix for Thread-SMR. The bug is: >>>> >>>> ???? JDK-8191789 migrate more Thread-SMR stuff from thread.[ch]pp >>>> -> threadSMR.[ch]pp >>>> ???? https://bugs.openjdk.java.net/browse/JDK-8191789 >>>> >>>> This fix is mostly code motion: >>>> >>>> - move Thread-SMR related code from thread.cpp -> threadSMR.cpp and >>>> ?? from thread.hpp -> threadSMR.hpp >>>> ?? - move Threads::_smr_* fields -> ThreadsSMRSupport class >>>> ?? - move Thread-SMR functions from Threads -> ThreadsSMRSupport class >>>> ?? - move Thread-SMR helper classes from thread.cpp -> threadsSMR.cpp >>>> ?? - rename a bunch of Threads::foo() calls -> >>>> ThreadsSMRSupport::foo() >>>> >>>> - collateral changes: >>>> ?? - DO_JAVA_THREADS macro usage by code moved to threadSMR.cpp have >>>> ???? to switch to JavaThreadIterator or some other function. >>>> ?? - Add ThreadsSMRSupport::inc_smr_java_thread_list_alloc_cnt(). >>>> ?? - Add ThreadsSMRSupport::update_smr_java_thread_list_max(). >>>> ?? - Cleanup "friends" for Thread class and ThreadsList class. >>>> ?? - Add includes of runtime/threadSMR.hpp in a few files. >>>> >>>> >>>> Here is the webrev URL: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8191789-webrev/jdk10-0 >>>> >>>> This fix was (over) tested with a Mach5 tier[1-5] run. There were no >>>> unexpected test failures. >>>> >>>> These changes were sanity checked a couple of ways: >>>> >>>> - Compare pre-Thread-SMR thread.[ch]pp with thread.[ch]pp after >>>> this fix >>>> ?? - Make sure that remaining Thread-SMR changes in thread.cpp and >>>> ???? thread.hpp make sense to leave behind. >>>> ?? - Similar comparison for thread.inline.hpp. >>>> - Compare code removed from thread.cpp with code added to >>>> threadSMR.cpp, >>>> ?? compare code removed from thread.hpp with code added to >>>> threadSMR.hpp, >>>> ?? compare code removed from thread.inline.hpp with code added to >>>> ?? threadSMR.inline.hpp: >>>> ?? - Make sure the deltas make sense. >>>> >>>> Thanks, in advance, for any comments, questions or suggestions. >>>> >>>> Dan >> From daniel.daugherty at oracle.com Tue Dec 5 21:26:04 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 5 Dec 2017 16:26:04 -0500 Subject: RFR(S/M): 8191789 - migrate more Thread-SMR stuff from thread.[ch]pp -> threadSMR.[ch]pp In-Reply-To: <3cb950e3-6a99-1f45-9f45-b51e982f1777@oracle.com> References: <3cb950e3-6a99-1f45-9f45-b51e982f1777@oracle.com> Message-ID: <22765116-19b8-79a0-dc7b-00a75eacbcf3@oracle.com> Greetings, I've updated the fix based on Stefan K's code review feedback (and my own self-review)... Delta webrev: http://cr.openjdk.java.net/~dcubed/8191789-webrev/jdk10-1-delta/ Full webrev: http://cr.openjdk.java.net/~dcubed/8191789-webrev/jdk10-1-full/ Summary of the changes in this round: - moved ThreadsList::remove_thread() - moved ThreadsListSetter::~ThreadsListSetter() and ThreadsListSetter::set() - remove Threads as a friend of class Thread - add ThreadsSMRSupport::update_smr_tlh_stats() to allow more ThreadsSMRSupport ? code to be private - refactor Threads-SMR code in Threads::add() to call ? new function ThreadsSMRSupport::add_thread() - refactor Threads-SMR code in Threads::remove() to call ? new function ThreadsSMRSupport::remove_thread() - more ThreadsSMRSupport functions can be private - move is_a_protected_JavaThread_with_lock() to ? threadSMR.inline.hpp I have a Mach5 tier[1-5] in progress for this round... Thanks, in advance, for any comments, questions or suggestions. Dan On 12/4/17 3:22 PM, Daniel D. Daugherty wrote: > Greetings, > > In terms of actual "new/changed" code, this is a "S" review. However, > because of code motion, the changed/insert/delete counts are the size > of an "M" or "L" review. > > Stefan K, this is one of your Thread-SMR follow-up suggestions so I need > to hear from you on this thread. Thanks! > > I have a simple (but tedious) cleanup fix for Thread-SMR. The bug is: > > ??? JDK-8191789 migrate more Thread-SMR stuff from thread.[ch]pp -> > threadSMR.[ch]pp > ??? https://bugs.openjdk.java.net/browse/JDK-8191789 > > This fix is mostly code motion: > > - move Thread-SMR related code from thread.cpp -> threadSMR.cpp and > ? from thread.hpp -> threadSMR.hpp > ? - move Threads::_smr_* fields -> ThreadsSMRSupport class > ? - move Thread-SMR functions from Threads -> ThreadsSMRSupport class > ? - move Thread-SMR helper classes from thread.cpp -> threadsSMR.cpp > ? - rename a bunch of Threads::foo() calls -> ThreadsSMRSupport::foo() > > - collateral changes: > ? - DO_JAVA_THREADS macro usage by code moved to threadSMR.cpp have > ??? to switch to JavaThreadIterator or some other function. > ? - Add ThreadsSMRSupport::inc_smr_java_thread_list_alloc_cnt(). > ? - Add ThreadsSMRSupport::update_smr_java_thread_list_max(). > ? - Cleanup "friends" for Thread class and ThreadsList class. > ? - Add includes of runtime/threadSMR.hpp in a few files. > > > Here is the webrev URL: > > http://cr.openjdk.java.net/~dcubed/8191789-webrev/jdk10-0 > > This fix was (over) tested with a Mach5 tier[1-5] run. There were no > unexpected test failures. > > These changes were sanity checked a couple of ways: > > - Compare pre-Thread-SMR thread.[ch]pp with thread.[ch]pp after this fix > ? - Make sure that remaining Thread-SMR changes in thread.cpp and > ??? thread.hpp make sense to leave behind. > ? - Similar comparison for thread.inline.hpp. > - Compare code removed from thread.cpp with code added to threadSMR.cpp, > ? compare code removed from thread.hpp with code added to threadSMR.hpp, > ? compare code removed from thread.inline.hpp with code added to > ? threadSMR.inline.hpp: > ? - Make sure the deltas make sense. > > Thanks, in advance, for any comments, questions or suggestions. > > Dan > From coleen.phillimore at oracle.com Tue Dec 5 21:37:36 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 5 Dec 2017 16:37:36 -0500 Subject: RFR(S/M): 8191789 - migrate more Thread-SMR stuff from thread.[ch]pp -> threadSMR.[ch]pp In-Reply-To: <22765116-19b8-79a0-dc7b-00a75eacbcf3@oracle.com> References: <3cb950e3-6a99-1f45-9f45-b51e982f1777@oracle.com> <22765116-19b8-79a0-dc7b-00a75eacbcf3@oracle.com> Message-ID: Thank you so much for moving this code.? The comment from the main change with the examples look good too (just rereading it now). Thanks, Coleen On 12/5/17 4:26 PM, Daniel D. Daugherty wrote: > Greetings, > > I've updated the fix based on Stefan K's code review feedback (and my > own self-review)... > > Delta webrev: > > http://cr.openjdk.java.net/~dcubed/8191789-webrev/jdk10-1-delta/ > > Full webrev: > > http://cr.openjdk.java.net/~dcubed/8191789-webrev/jdk10-1-full/ > > > Summary of the changes in this round: > > - moved ThreadsList::remove_thread() > - moved ThreadsListSetter::~ThreadsListSetter() and > ThreadsListSetter::set() > - remove Threads as a friend of class Thread > - add ThreadsSMRSupport::update_smr_tlh_stats() to allow more > ThreadsSMRSupport > ? code to be private > > - refactor Threads-SMR code in Threads::add() to call > ? new function ThreadsSMRSupport::add_thread() > - refactor Threads-SMR code in Threads::remove() to call > ? new function ThreadsSMRSupport::remove_thread() > - more ThreadsSMRSupport functions can be private > - move is_a_protected_JavaThread_with_lock() to > ? threadSMR.inline.hpp > > > I have a Mach5 tier[1-5] in progress for this round... > > Thanks, in advance, for any comments, questions or suggestions. > > Dan > > > > On 12/4/17 3:22 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> In terms of actual "new/changed" code, this is a "S" review. However, >> because of code motion, the changed/insert/delete counts are the size >> of an "M" or "L" review. >> >> Stefan K, this is one of your Thread-SMR follow-up suggestions so I need >> to hear from you on this thread. Thanks! >> >> I have a simple (but tedious) cleanup fix for Thread-SMR. The bug is: >> >> ??? JDK-8191789 migrate more Thread-SMR stuff from thread.[ch]pp -> >> threadSMR.[ch]pp >> ??? https://bugs.openjdk.java.net/browse/JDK-8191789 >> >> This fix is mostly code motion: >> >> - move Thread-SMR related code from thread.cpp -> threadSMR.cpp and >> ? from thread.hpp -> threadSMR.hpp >> ? - move Threads::_smr_* fields -> ThreadsSMRSupport class >> ? - move Thread-SMR functions from Threads -> ThreadsSMRSupport class >> ? - move Thread-SMR helper classes from thread.cpp -> threadsSMR.cpp >> ? - rename a bunch of Threads::foo() calls -> ThreadsSMRSupport::foo() >> >> - collateral changes: >> ? - DO_JAVA_THREADS macro usage by code moved to threadSMR.cpp have >> ??? to switch to JavaThreadIterator or some other function. >> ? - Add ThreadsSMRSupport::inc_smr_java_thread_list_alloc_cnt(). >> ? - Add ThreadsSMRSupport::update_smr_java_thread_list_max(). >> ? - Cleanup "friends" for Thread class and ThreadsList class. >> ? - Add includes of runtime/threadSMR.hpp in a few files. >> >> >> Here is the webrev URL: >> >> http://cr.openjdk.java.net/~dcubed/8191789-webrev/jdk10-0 >> >> This fix was (over) tested with a Mach5 tier[1-5] run. There were no >> unexpected test failures. >> >> These changes were sanity checked a couple of ways: >> >> - Compare pre-Thread-SMR thread.[ch]pp with thread.[ch]pp after this fix >> ? - Make sure that remaining Thread-SMR changes in thread.cpp and >> ??? thread.hpp make sense to leave behind. >> ? - Similar comparison for thread.inline.hpp. >> - Compare code removed from thread.cpp with code added to threadSMR.cpp, >> ? compare code removed from thread.hpp with code added to threadSMR.hpp, >> ? compare code removed from thread.inline.hpp with code added to >> ? threadSMR.inline.hpp: >> ? - Make sure the deltas make sense. >> >> Thanks, in advance, for any comments, questions or suggestions. >> >> Dan >> > From jiangli.zhou at Oracle.COM Tue Dec 5 23:19:51 2017 From: jiangli.zhou at Oracle.COM (Jiangli Zhou) Date: Tue, 5 Dec 2017 15:19:51 -0800 Subject: RFR: 8193065: [TESTBUG]GCSharedStringsDuringDump.java: Exception in thread "main" java.lang.RuntimeException: String is not shared. Message-ID: <70BB9696-78ED-4652-B772-165730BBBA23@oracle.com> Please review the following test fix that detects missing ?oa region? as a failure when there are extra allocations/GCs during CDS dump time. When failures are detected, a larger heap size is used for dumping. Please see more detailed analysis in the bug report. webrev: http://cr.openjdk.java.net/~jiangli/8193065/webrev.00/ bug: https://bugs.openjdk.java.net/browse/JDK-8193065?filter=14921 Testing with hs tier1, tier2 and tier7. Thanks, Jiangli From daniel.daugherty at oracle.com Wed Dec 6 03:31:06 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 5 Dec 2017 22:31:06 -0500 Subject: RFR(S/M): 8191789 - migrate more Thread-SMR stuff from thread.[ch]pp -> threadSMR.[ch]pp In-Reply-To: References: <3cb950e3-6a99-1f45-9f45-b51e982f1777@oracle.com> <22765116-19b8-79a0-dc7b-00a75eacbcf3@oracle.com> Message-ID: <11d6c02e-0599-f65d-9b9e-296234e5e14b@oracle.com> Coleen, Thanks for the review! Dan On 12/5/17 4:37 PM, coleen.phillimore at oracle.com wrote: > Thank you so much for moving this code.? The comment from the main > change with the examples look good too (just rereading it now). > > Thanks, > Coleen > > On 12/5/17 4:26 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> I've updated the fix based on Stefan K's code review feedback (and my >> own self-review)... >> >> Delta webrev: >> >> http://cr.openjdk.java.net/~dcubed/8191789-webrev/jdk10-1-delta/ >> >> Full webrev: >> >> http://cr.openjdk.java.net/~dcubed/8191789-webrev/jdk10-1-full/ >> >> >> Summary of the changes in this round: >> >> - moved ThreadsList::remove_thread() >> - moved ThreadsListSetter::~ThreadsListSetter() and >> ThreadsListSetter::set() >> - remove Threads as a friend of class Thread >> - add ThreadsSMRSupport::update_smr_tlh_stats() to allow more >> ThreadsSMRSupport >> ? code to be private >> >> - refactor Threads-SMR code in Threads::add() to call >> ? new function ThreadsSMRSupport::add_thread() >> - refactor Threads-SMR code in Threads::remove() to call >> ? new function ThreadsSMRSupport::remove_thread() >> - more ThreadsSMRSupport functions can be private >> - move is_a_protected_JavaThread_with_lock() to >> ? threadSMR.inline.hpp >> >> >> I have a Mach5 tier[1-5] in progress for this round... >> >> Thanks, in advance, for any comments, questions or suggestions. >> >> Dan >> >> >> >> On 12/4/17 3:22 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> In terms of actual "new/changed" code, this is a "S" review. However, >>> because of code motion, the changed/insert/delete counts are the size >>> of an "M" or "L" review. >>> >>> Stefan K, this is one of your Thread-SMR follow-up suggestions so I >>> need >>> to hear from you on this thread. Thanks! >>> >>> I have a simple (but tedious) cleanup fix for Thread-SMR. The bug is: >>> >>> ??? JDK-8191789 migrate more Thread-SMR stuff from thread.[ch]pp -> >>> threadSMR.[ch]pp >>> ??? https://bugs.openjdk.java.net/browse/JDK-8191789 >>> >>> This fix is mostly code motion: >>> >>> - move Thread-SMR related code from thread.cpp -> threadSMR.cpp and >>> ? from thread.hpp -> threadSMR.hpp >>> ? - move Threads::_smr_* fields -> ThreadsSMRSupport class >>> ? - move Thread-SMR functions from Threads -> ThreadsSMRSupport class >>> ? - move Thread-SMR helper classes from thread.cpp -> threadsSMR.cpp >>> ? - rename a bunch of Threads::foo() calls -> ThreadsSMRSupport::foo() >>> >>> - collateral changes: >>> ? - DO_JAVA_THREADS macro usage by code moved to threadSMR.cpp have >>> ??? to switch to JavaThreadIterator or some other function. >>> ? - Add ThreadsSMRSupport::inc_smr_java_thread_list_alloc_cnt(). >>> ? - Add ThreadsSMRSupport::update_smr_java_thread_list_max(). >>> ? - Cleanup "friends" for Thread class and ThreadsList class. >>> ? - Add includes of runtime/threadSMR.hpp in a few files. >>> >>> >>> Here is the webrev URL: >>> >>> http://cr.openjdk.java.net/~dcubed/8191789-webrev/jdk10-0 >>> >>> This fix was (over) tested with a Mach5 tier[1-5] run. There were no >>> unexpected test failures. >>> >>> These changes were sanity checked a couple of ways: >>> >>> - Compare pre-Thread-SMR thread.[ch]pp with thread.[ch]pp after this >>> fix >>> ? - Make sure that remaining Thread-SMR changes in thread.cpp and >>> ??? thread.hpp make sense to leave behind. >>> ? - Similar comparison for thread.inline.hpp. >>> - Compare code removed from thread.cpp with code added to >>> threadSMR.cpp, >>> ? compare code removed from thread.hpp with code added to >>> threadSMR.hpp, >>> ? compare code removed from thread.inline.hpp with code added to >>> ? threadSMR.inline.hpp: >>> ? - Make sure the deltas make sense. >>> >>> Thanks, in advance, for any comments, questions or suggestions. >>> >>> Dan >>> >> > From david.holmes at oracle.com Wed Dec 6 03:38:23 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 6 Dec 2017 13:38:23 +1000 Subject: RFR(S/M): 8191789 - migrate more Thread-SMR stuff from thread.[ch]pp -> threadSMR.[ch]pp In-Reply-To: <22765116-19b8-79a0-dc7b-00a75eacbcf3@oracle.com> References: <3cb950e3-6a99-1f45-9f45-b51e982f1777@oracle.com> <22765116-19b8-79a0-dc7b-00a75eacbcf3@oracle.com> Message-ID: <0fdb70f2-74e0-8efd-4590-4c26c31c2884@oracle.com> Hi Dan, This all looks good to me. I agree with removing the now redundant _smr_ name components at a later time. Thanks, David On 6/12/2017 7:26 AM, Daniel D. Daugherty wrote: > Greetings, > > I've updated the fix based on Stefan K's code review feedback (and my > own self-review)... > > Delta webrev: > > http://cr.openjdk.java.net/~dcubed/8191789-webrev/jdk10-1-delta/ > > Full webrev: > > http://cr.openjdk.java.net/~dcubed/8191789-webrev/jdk10-1-full/ > > > Summary of the changes in this round: > > - moved ThreadsList::remove_thread() > - moved ThreadsListSetter::~ThreadsListSetter() and > ThreadsListSetter::set() > - remove Threads as a friend of class Thread > - add ThreadsSMRSupport::update_smr_tlh_stats() to allow more > ThreadsSMRSupport > ? code to be private > > - refactor Threads-SMR code in Threads::add() to call > ? new function ThreadsSMRSupport::add_thread() > - refactor Threads-SMR code in Threads::remove() to call > ? new function ThreadsSMRSupport::remove_thread() > - more ThreadsSMRSupport functions can be private > - move is_a_protected_JavaThread_with_lock() to > ? threadSMR.inline.hpp > > > I have a Mach5 tier[1-5] in progress for this round... > > Thanks, in advance, for any comments, questions or suggestions. > > Dan > > > > On 12/4/17 3:22 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> In terms of actual "new/changed" code, this is a "S" review. However, >> because of code motion, the changed/insert/delete counts are the size >> of an "M" or "L" review. >> >> Stefan K, this is one of your Thread-SMR follow-up suggestions so I need >> to hear from you on this thread. Thanks! >> >> I have a simple (but tedious) cleanup fix for Thread-SMR. The bug is: >> >> ??? JDK-8191789 migrate more Thread-SMR stuff from thread.[ch]pp -> >> threadSMR.[ch]pp >> ??? https://bugs.openjdk.java.net/browse/JDK-8191789 >> >> This fix is mostly code motion: >> >> - move Thread-SMR related code from thread.cpp -> threadSMR.cpp and >> ? from thread.hpp -> threadSMR.hpp >> ? - move Threads::_smr_* fields -> ThreadsSMRSupport class >> ? - move Thread-SMR functions from Threads -> ThreadsSMRSupport class >> ? - move Thread-SMR helper classes from thread.cpp -> threadsSMR.cpp >> ? - rename a bunch of Threads::foo() calls -> ThreadsSMRSupport::foo() >> >> - collateral changes: >> ? - DO_JAVA_THREADS macro usage by code moved to threadSMR.cpp have >> ??? to switch to JavaThreadIterator or some other function. >> ? - Add ThreadsSMRSupport::inc_smr_java_thread_list_alloc_cnt(). >> ? - Add ThreadsSMRSupport::update_smr_java_thread_list_max(). >> ? - Cleanup "friends" for Thread class and ThreadsList class. >> ? - Add includes of runtime/threadSMR.hpp in a few files. >> >> >> Here is the webrev URL: >> >> http://cr.openjdk.java.net/~dcubed/8191789-webrev/jdk10-0 >> >> This fix was (over) tested with a Mach5 tier[1-5] run. There were no >> unexpected test failures. >> >> These changes were sanity checked a couple of ways: >> >> - Compare pre-Thread-SMR thread.[ch]pp with thread.[ch]pp after this fix >> ? - Make sure that remaining Thread-SMR changes in thread.cpp and >> ??? thread.hpp make sense to leave behind. >> ? - Similar comparison for thread.inline.hpp. >> - Compare code removed from thread.cpp with code added to threadSMR.cpp, >> ? compare code removed from thread.hpp with code added to threadSMR.hpp, >> ? compare code removed from thread.inline.hpp with code added to >> ? threadSMR.inline.hpp: >> ? - Make sure the deltas make sense. >> >> Thanks, in advance, for any comments, questions or suggestions. >> >> Dan >> > From daniel.daugherty at oracle.com Wed Dec 6 03:39:27 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 5 Dec 2017 22:39:27 -0500 Subject: RFR(S/M): 8191789 - migrate more Thread-SMR stuff from thread.[ch]pp -> threadSMR.[ch]pp In-Reply-To: <0fdb70f2-74e0-8efd-4590-4c26c31c2884@oracle.com> References: <3cb950e3-6a99-1f45-9f45-b51e982f1777@oracle.com> <22765116-19b8-79a0-dc7b-00a75eacbcf3@oracle.com> <0fdb70f2-74e0-8efd-4590-4c26c31c2884@oracle.com> Message-ID: <79648259-27c1-2860-5946-00e1dd16ce38@oracle.com> David, Thanks for the review! Dan On 12/5/17 10:38 PM, David Holmes wrote: > Hi Dan, > > This all looks good to me. > > I agree with removing the now redundant _smr_ name components at a > later time. > > Thanks, > David > > On 6/12/2017 7:26 AM, Daniel D. Daugherty wrote: >> Greetings, >> >> I've updated the fix based on Stefan K's code review feedback (and my >> own self-review)... >> >> Delta webrev: >> >> http://cr.openjdk.java.net/~dcubed/8191789-webrev/jdk10-1-delta/ >> >> Full webrev: >> >> http://cr.openjdk.java.net/~dcubed/8191789-webrev/jdk10-1-full/ >> >> >> Summary of the changes in this round: >> >> - moved ThreadsList::remove_thread() >> - moved ThreadsListSetter::~ThreadsListSetter() and >> ThreadsListSetter::set() >> - remove Threads as a friend of class Thread >> - add ThreadsSMRSupport::update_smr_tlh_stats() to allow more >> ThreadsSMRSupport >> ?? code to be private >> >> - refactor Threads-SMR code in Threads::add() to call >> ?? new function ThreadsSMRSupport::add_thread() >> - refactor Threads-SMR code in Threads::remove() to call >> ?? new function ThreadsSMRSupport::remove_thread() >> - more ThreadsSMRSupport functions can be private >> - move is_a_protected_JavaThread_with_lock() to >> ?? threadSMR.inline.hpp >> >> >> I have a Mach5 tier[1-5] in progress for this round... >> >> Thanks, in advance, for any comments, questions or suggestions. >> >> Dan >> >> >> >> On 12/4/17 3:22 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> In terms of actual "new/changed" code, this is a "S" review. However, >>> because of code motion, the changed/insert/delete counts are the size >>> of an "M" or "L" review. >>> >>> Stefan K, this is one of your Thread-SMR follow-up suggestions so I >>> need >>> to hear from you on this thread. Thanks! >>> >>> I have a simple (but tedious) cleanup fix for Thread-SMR. The bug is: >>> >>> ??? JDK-8191789 migrate more Thread-SMR stuff from thread.[ch]pp -> >>> threadSMR.[ch]pp >>> ??? https://bugs.openjdk.java.net/browse/JDK-8191789 >>> >>> This fix is mostly code motion: >>> >>> - move Thread-SMR related code from thread.cpp -> threadSMR.cpp and >>> ? from thread.hpp -> threadSMR.hpp >>> ? - move Threads::_smr_* fields -> ThreadsSMRSupport class >>> ? - move Thread-SMR functions from Threads -> ThreadsSMRSupport class >>> ? - move Thread-SMR helper classes from thread.cpp -> threadsSMR.cpp >>> ? - rename a bunch of Threads::foo() calls -> ThreadsSMRSupport::foo() >>> >>> - collateral changes: >>> ? - DO_JAVA_THREADS macro usage by code moved to threadSMR.cpp have >>> ??? to switch to JavaThreadIterator or some other function. >>> ? - Add ThreadsSMRSupport::inc_smr_java_thread_list_alloc_cnt(). >>> ? - Add ThreadsSMRSupport::update_smr_java_thread_list_max(). >>> ? - Cleanup "friends" for Thread class and ThreadsList class. >>> ? - Add includes of runtime/threadSMR.hpp in a few files. >>> >>> >>> Here is the webrev URL: >>> >>> http://cr.openjdk.java.net/~dcubed/8191789-webrev/jdk10-0 >>> >>> This fix was (over) tested with a Mach5 tier[1-5] run. There were no >>> unexpected test failures. >>> >>> These changes were sanity checked a couple of ways: >>> >>> - Compare pre-Thread-SMR thread.[ch]pp with thread.[ch]pp after this >>> fix >>> ? - Make sure that remaining Thread-SMR changes in thread.cpp and >>> ??? thread.hpp make sense to leave behind. >>> ? - Similar comparison for thread.inline.hpp. >>> - Compare code removed from thread.cpp with code added to >>> threadSMR.cpp, >>> ? compare code removed from thread.hpp with code added to >>> threadSMR.hpp, >>> ? compare code removed from thread.inline.hpp with code added to >>> ? threadSMR.inline.hpp: >>> ? - Make sure the deltas make sense. >>> >>> Thanks, in advance, for any comments, questions or suggestions. >>> >>> Dan >>> >> From david.holmes at oracle.com Wed Dec 6 06:33:59 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 6 Dec 2017 16:33:59 +1000 Subject: Unified JVM Logging and diagnostic options LogVMOutput, LogFile, DisplayVMOutput In-Reply-To: References: <92addaa5-e735-db64-0e7a-afe8f5f6c2d4@oracle.com> Message-ID: <19afa6c9-0f35-e108-7027-3d7974c89300@oracle.com> On 1/12/2017 11:15 AM, Man Cao wrote: > Thanks David for the quick response! > > Yes, I understand completely removing defaultStream and tty is probably > infeasible. > > If deprecating the diagnostic options (LogVMOutput, LogFile, > DisplayVMOutput) is the intent, could someone create a bug/RFE to track > it? They should probably first be added to the special_jvm_flags table I think there is too much yet to be done in the conversion process to file such a RFE - to be frank we don't have active RFE's for the remaining conversions, rather they are being tackled case by case when people are working in the area. > in arguments.cpp, so there will be a warning when people use them. The > case of conflicting -Xlog::file=test.log and -XX:LogFile=test.log is > also a concern, the JVM should at least issue a warning about it. In > addition, it would make it easier for us to convince production teams to > stop using these options. I have filed: https://bugs.openjdk.java.net/browse/JDK-8193117 JDK-8193117 Issue a warning if legacy logging and Unified Logging are told to use the same file Cheers, David ----- > Thanks, > Man > > On Thu, Nov 30, 2017 at 4:48 PM, David Holmes > wrote: > > Hi Man, > > Adding serviceability as UL is a serviceability feature. > > > On 1/12/2017 10:23 AM, Man Cao wrote: > > Hello, > > We (Java Platform Team at Google) found that in JDK9, the file > generated by > -XX:+LogVMOutput no longer contains GC log messages, because the > unified > JVM logging framework does not use the defaultStream and > fileStream classes > and the tty variable. Similarly, related options such as LogFile, > DisplayVMOutput have no effect on the messages printed by the > unified > logging framework. > > The main problem for us is that most of our production Java > servers use the > options "-XX:+LogVMOutput -XX:-DisplayVMOutput", to save the GC > logs and > other VM messages. These flags would no longer work for JDK9's > JVM logging > framework. In addition, the file generated by -XX:+LogVMOutput > may contain > information that is not printed by the unified logging framework. > > What is worse is that if LogFile and the output of unified logging > framework point to the same file, the file may contain partial > or corrupted > messages from the unified logging framework. For example, > consider the > following command: > > java -Xlog::file=test.log -XX:+UnlockDiagnosticVMOptions > -XX:+LogVMOutput > -XX:LogFile=test.log > > Then test.log would miss some of the messages that would be > printed at the > beginning if you run "java -Xlog". > > So our questions are: > 1. Do you consider this is a bug for the unified logging > framework that > should be fixed? Should the unified logging framework respect these > diagnostic options? > > > My understanding is that UL is intended to replace the legacy > "logging" flags and works independently of them. So no, UL should > not respect these flags. > > 2. Is there a plan to deprecate these diagnostic options > (LogVMOutput, > LogFile, DisplayVMOutput, etc.)? Will the defaultStream, > fileStream classes > and the tty variable eventually removed from HotSpot? > > > I believe that is the general intent - though complete removal is > not feasible as UL can't always be used in all contexts. We have > migrated various subsystems to UL and all new logging should be > using UL. However I don't believe we actually have active RFEs to > aggressively complete the switchover. > > Just my 2c. > > David > > Thanks, > Man > > From sangheon.kim at oracle.com Wed Dec 6 07:46:23 2017 From: sangheon.kim at oracle.com (sangheon.kim) Date: Tue, 5 Dec 2017 23:46:23 -0800 Subject: RFR (XS): 8193105: Print error code when map_memory_to_file() fails Message-ID: <1491e772-b038-93ce-acc7-cd9c6e2325d5@oracle.com> Hi all, Could I have some reviews for this change? JDK-8190308 (Implementation: JEP 316: Heap Allocation on Alternative Memory Devices) introduced a new test(TestAllocateHeapAt.java) but it is failing on Solaris-Sparc with fastdebug build. But unfortunately there's no error print when related function fails. This proposal is simply adding error code print for further investigation of JDK-8192871(TestAllocateHeapAt fails), not change its logic. CR: https://bugs.openjdk.java.net/browse/JDK-8193105 Webrev: http://cr.openjdk.java.net/~sangheki/8193105/webrev.0 Testing: hs-tier1 Thanks, Sangheon From david.holmes at oracle.com Wed Dec 6 11:25:40 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 6 Dec 2017 21:25:40 +1000 Subject: RFR (XS): 8193105: Print error code when map_memory_to_file() fails In-Reply-To: <1491e772-b038-93ce-acc7-cd9c6e2325d5@oracle.com> References: <1491e772-b038-93ce-acc7-cd9c6e2325d5@oracle.com> Message-ID: <003d8069-7b69-85ef-997d-9435cca42446@oracle.com> Hi Sangheon, On 6/12/2017 5:46 PM, sangheon.kim wrote: > Hi all, > > Could I have some reviews for this change? > > JDK-8190308 (Implementation: JEP 316: Heap Allocation on Alternative > Memory Devices) introduced a new test(TestAllocateHeapAt.java) but it is > failing on Solaris-Sparc with fastdebug build. But unfortunately there's > no error print when related function fails. > > This proposal is simply adding error code print for further > investigation of JDK-8192871(TestAllocateHeapAt fails), not change its > logic. > > CR: https://bugs.openjdk.java.net/browse/JDK-8193105 > Webrev: http://cr.openjdk.java.net/~sangheki/8193105/webrev.0 > Testing: hs-tier1 ! vm_exit_during_initialization(err_msg("Error in mapping Java heap at the given filesystem directory. error(%d)", ret)); You should use strerror(ret) to print a readable error string here. Thanks, David > Thanks, > Sangheon From david.holmes at oracle.com Wed Dec 6 11:31:30 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 6 Dec 2017 21:31:30 +1000 Subject: RFR (XS): 8193105: Print error code when map_memory_to_file() fails In-Reply-To: <003d8069-7b69-85ef-997d-9435cca42446@oracle.com> References: <1491e772-b038-93ce-acc7-cd9c6e2325d5@oracle.com> <003d8069-7b69-85ef-997d-9435cca42446@oracle.com> Message-ID: <15ead314-b0b4-a551-e9e4-fe77ce21fa75@oracle.com> On 6/12/2017 9:25 PM, David Holmes wrote: > Hi Sangheon, > > On 6/12/2017 5:46 PM, sangheon.kim wrote: >> Hi all, >> >> Could I have some reviews for this change? >> >> JDK-8190308 (Implementation: JEP 316: Heap Allocation on Alternative >> Memory Devices) introduced a new test(TestAllocateHeapAt.java) but it >> is failing on Solaris-Sparc with fastdebug build. But unfortunately >> there's no error print when related function fails. >> >> This proposal is simply adding error code print for further >> investigation of JDK-8192871(TestAllocateHeapAt fails), not change its >> logic. >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8193105 >> Webrev: http://cr.openjdk.java.net/~sangheki/8193105/webrev.0 >> Testing: hs-tier1 > > !???? vm_exit_during_initialization(err_msg("Error in mapping Java heap > at the given filesystem directory. error(%d)", ret)); > > You should use strerror(ret) to print a readable error string here. Except you can't because on OSX util_posix_fallocate doesn't necessarily return an error code! That's another bug in this particular so-called "posix" function! :( David > Thanks, > David > >> Thanks, >> Sangheon From adam.farley at uk.ibm.com Wed Dec 6 11:53:39 2017 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Wed, 6 Dec 2017 11:53:39 +0000 Subject: RFR: JDK-8190187: C++ code calling JNI_CreateJavaVM can be killed by Java In-Reply-To: References: Message-ID: Hi All, We have a bug in OpenJDK where if you pass an info-only option (like -agentlib:jdwp=help) in through the JNI interface, it can exit your code with RC 0. I think this is a bug because if you planned to do anything after starting a Java VM, you have to do it in an exit hook. If an info-only option is used, exit(0) should not happen. Instead, the user's code should be told the VM cannot be used. Bug Link: https://bugs.openjdk.java.net/browse/JDK-8190187 I have proposed the creation of a new JNI return code indicating a "silent exit", where the vm encountered no error, but that it is not in a fit state to be used. See the link for an implementation of this, along with a handy test. In short, if you agree that this is a problem, we need a champion to: 1) Complete the CSR process for the new JNI Return code. 2) Commit the changes that contain (a) the new return code, and (b) the non-Hotspot code that handles the new code. Optionally, if you want to commit the code containing an example of the fix, you will need to: 3) Commit the Hotspot code that channels the new return code. 4) Complete the CSR process for the jdwp behaviour change. 5) Commit the jdwp code. Note that all of this code has *already been written*. This should be an easy commit once the CSR is done with. Best Regards Adam Farley Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU From harold.seigel at oracle.com Wed Dec 6 13:05:27 2017 From: harold.seigel at oracle.com (harold seigel) Date: Wed, 6 Dec 2017 08:05:27 -0500 Subject: RFR: 8193065: [TESTBUG]GCSharedStringsDuringDump.java: Exception in thread "main" java.lang.RuntimeException: String is not shared. In-Reply-To: <70BB9696-78ED-4652-B772-165730BBBA23@oracle.com> References: <70BB9696-78ED-4652-B772-165730BBBA23@oracle.com> Message-ID: Hi Jiangli, This change looks good. Thanks, Harold On 12/5/2017 6:19 PM, Jiangli Zhou wrote: > Please review the following test fix that detects missing ?oa region? as a failure when there are extra allocations/GCs during CDS dump time. When failures are detected, a larger heap size is used for dumping. Please see more detailed analysis in the bug report. > > webrev: http://cr.openjdk.java.net/~jiangli/8193065/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8193065?filter=14921 > > Testing with hs tier1, tier2 and tier7. > > Thanks, > Jiangli From harold.seigel at oracle.com Wed Dec 6 13:49:55 2017 From: harold.seigel at oracle.com (harold seigel) Date: Wed, 6 Dec 2017 08:49:55 -0500 Subject: RFR 8154587: Resolution fails for default method named 'clone' In-Reply-To: <3c0ff7a5-1a46-f4d9-c50a-6e6b322fdabc@oracle.com> References: <22c41169-4c42-bff3-5090-a27ad9019bff@oracle.com> <3c0ff7a5-1a46-f4d9-c50a-6e6b322fdabc@oracle.com> Message-ID: <137ddf56-0f1e-ae10-3884-97a39fd92eeb@oracle.com> Hi Lois, Thanks for the review.? I'll add these tests in the next iteration of this webrev. >> - a test where class C does not define the method "clone", an IAE should result, correct? Yes, the test throws an IAE. Harold On 12/4/2017 2:31 PM, Lois Foltan wrote: > Hi Harold, > > Fix looks good.? I would like to see three more test cases: > > ??? - the same test written for "finalize" since that is also a > non-public method of Object. > ??? - a test where class C does not define the method "clone", an IAE > should result, correct? > ??? - a test case where I2 defines a public method of Object > > Thanks, > Lois > > On 11/30/2017 11:15 AM, harold seigel wrote: >> Hi, >> >> Please review this fix for JDK-8154587.? The fix adds additional >> special casing to skip over non-public methods in class >> java.lang.Object during default method and itable processing for >> interfaces.? These methods need to be skipped over because of the >> interface method resolution rules in JVM Spec 9, section 5.4.3.4 >> : >> >> ?? 3. Otherwise, if the class|Object|declares a method with the name >> ?? and descriptor specified by the interface method reference, which >> ?? has its|ACC_PUBLIC|flag set and does not have its|ACC_STATIC|flag >> ?? set, method lookup succeeds. >> >> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8154587/webrev/ >> >> JBS Bug:? https://bugs.openjdk.java.net/browse/JDK-8154587 >> >> The fix was tested with JCK lang and VM tests, JTReg hotspot and many >> JTReg JDK tests, M5 tier1 - tier5 tests, and JPRT. >> >> Thanks, Harold >> > From karen.kinnear at oracle.com Wed Dec 6 14:17:47 2017 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 6 Dec 2017 09:17:47 -0500 Subject: Unified JVM Logging and diagnostic options LogVMOutput, LogFile, DisplayVMOutput In-Reply-To: <19afa6c9-0f35-e108-7027-3d7974c89300@oracle.com> References: <92addaa5-e735-db64-0e7a-afe8f5f6c2d4@oracle.com> <19afa6c9-0f35-e108-7027-3d7974c89300@oracle.com> Message-ID: <4B8D1CCD-50DF-4A13-8C04-9B3B4646781F@oracle.com> Just a note - unified logging belongs to runtime. thanks, Karen > On Dec 6, 2017, at 1:33 AM, David Holmes wrote: > > On 1/12/2017 11:15 AM, Man Cao wrote: >> Thanks David for the quick response! >> Yes, I understand completely removing defaultStream and tty is probably infeasible. >> If deprecating the diagnostic options (LogVMOutput, LogFile, DisplayVMOutput) is the intent, could someone create a bug/RFE to track it? They should probably first be added to the special_jvm_flags table > > I think there is too much yet to be done in the conversion process to file such a RFE - to be frank we don't have active RFE's for the remaining conversions, rather they are being tackled case by case when people are working in the area. > >> in arguments.cpp, so there will be a warning when people use them. The case of conflicting -Xlog::file=test.log and -XX:LogFile=test.log is also a concern, the JVM should at least issue a warning about it. In addition, it would make it easier for us to convince production teams to stop using these options. > > I have filed: > > https://bugs.openjdk.java.net/browse/JDK-8193117 > > JDK-8193117 Issue a warning if legacy logging and Unified Logging are told to use the same file > > Cheers, > David > ----- > >> Thanks, >> Man >> On Thu, Nov 30, 2017 at 4:48 PM, David Holmes > wrote: >> Hi Man, >> Adding serviceability as UL is a serviceability feature. >> On 1/12/2017 10:23 AM, Man Cao wrote: >> Hello, >> We (Java Platform Team at Google) found that in JDK9, the file >> generated by >> -XX:+LogVMOutput no longer contains GC log messages, because the >> unified >> JVM logging framework does not use the defaultStream and >> fileStream classes >> and the tty variable. Similarly, related options such as LogFile, >> DisplayVMOutput have no effect on the messages printed by the >> unified >> logging framework. >> The main problem for us is that most of our production Java >> servers use the >> options "-XX:+LogVMOutput -XX:-DisplayVMOutput", to save the GC >> logs and >> other VM messages. These flags would no longer work for JDK9's >> JVM logging >> framework. In addition, the file generated by -XX:+LogVMOutput >> may contain >> information that is not printed by the unified logging framework. >> What is worse is that if LogFile and the output of unified logging >> framework point to the same file, the file may contain partial >> or corrupted >> messages from the unified logging framework. For example, >> consider the >> following command: >> java -Xlog::file=test.log -XX:+UnlockDiagnosticVMOptions >> -XX:+LogVMOutput >> -XX:LogFile=test.log >> Then test.log would miss some of the messages that would be >> printed at the >> beginning if you run "java -Xlog". >> So our questions are: >> 1. Do you consider this is a bug for the unified logging >> framework that >> should be fixed? Should the unified logging framework respect these >> diagnostic options? >> My understanding is that UL is intended to replace the legacy >> "logging" flags and works independently of them. So no, UL should >> not respect these flags. >> 2. Is there a plan to deprecate these diagnostic options >> (LogVMOutput, >> LogFile, DisplayVMOutput, etc.)? Will the defaultStream, >> fileStream classes >> and the tty variable eventually removed from HotSpot? >> I believe that is the general intent - though complete removal is >> not feasible as UL can't always be used in all contexts. We have >> migrated various subsystems to UL and all new logging should be >> using UL. However I don't believe we actually have active RFEs to >> aggressively complete the switchover. >> Just my 2c. >> David >> Thanks, >> Man From gerald.thornbrugh at oracle.com Wed Dec 6 14:29:15 2017 From: gerald.thornbrugh at oracle.com (Gerald Thornbrugh) Date: Wed, 6 Dec 2017 07:29:15 -0700 Subject: RFR(S/M): 8191789 - migrate more Thread-SMR stuff from thread.[ch]pp -> threadSMR.[ch]pp In-Reply-To: <22765116-19b8-79a0-dc7b-00a75eacbcf3@oracle.com> References: <3cb950e3-6a99-1f45-9f45-b51e982f1777@oracle.com> <22765116-19b8-79a0-dc7b-00a75eacbcf3@oracle.com> Message-ID: <54561723-68C0-4CE1-8F00-758AA0CA0CD9@oracle.com> Hi Dan, Your changes look good. Jerry > On Dec 5, 2017, at 2:26 PM, Daniel D. Daugherty wrote: > > Greetings, > > I've updated the fix based on Stefan K's code review feedback (and my > own self-review)... > > Delta webrev: > > http://cr.openjdk.java.net/~dcubed/8191789-webrev/jdk10-1-delta/ > > Full webrev: > > http://cr.openjdk.java.net/~dcubed/8191789-webrev/jdk10-1-full/ > > > Summary of the changes in this round: > > - moved ThreadsList::remove_thread() > - moved ThreadsListSetter::~ThreadsListSetter() and ThreadsListSetter::set() > - remove Threads as a friend of class Thread > - add ThreadsSMRSupport::update_smr_tlh_stats() to allow more ThreadsSMRSupport > code to be private > > - refactor Threads-SMR code in Threads::add() to call > new function ThreadsSMRSupport::add_thread() > - refactor Threads-SMR code in Threads::remove() to call > new function ThreadsSMRSupport::remove_thread() > - more ThreadsSMRSupport functions can be private > - move is_a_protected_JavaThread_with_lock() to > threadSMR.inline.hpp > > > I have a Mach5 tier[1-5] in progress for this round... > > Thanks, in advance, for any comments, questions or suggestions. > > Dan > > > > On 12/4/17 3:22 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> In terms of actual "new/changed" code, this is a "S" review. However, >> because of code motion, the changed/insert/delete counts are the size >> of an "M" or "L" review. >> >> Stefan K, this is one of your Thread-SMR follow-up suggestions so I need >> to hear from you on this thread. Thanks! >> >> I have a simple (but tedious) cleanup fix for Thread-SMR. The bug is: >> >> JDK-8191789 migrate more Thread-SMR stuff from thread.[ch]pp -> threadSMR.[ch]pp >> https://bugs.openjdk.java.net/browse/JDK-8191789 >> >> This fix is mostly code motion: >> >> - move Thread-SMR related code from thread.cpp -> threadSMR.cpp and >> from thread.hpp -> threadSMR.hpp >> - move Threads::_smr_* fields -> ThreadsSMRSupport class >> - move Thread-SMR functions from Threads -> ThreadsSMRSupport class >> - move Thread-SMR helper classes from thread.cpp -> threadsSMR.cpp >> - rename a bunch of Threads::foo() calls -> ThreadsSMRSupport::foo() >> >> - collateral changes: >> - DO_JAVA_THREADS macro usage by code moved to threadSMR.cpp have >> to switch to JavaThreadIterator or some other function. >> - Add ThreadsSMRSupport::inc_smr_java_thread_list_alloc_cnt(). >> - Add ThreadsSMRSupport::update_smr_java_thread_list_max(). >> - Cleanup "friends" for Thread class and ThreadsList class. >> - Add includes of runtime/threadSMR.hpp in a few files. >> >> >> Here is the webrev URL: >> >> http://cr.openjdk.java.net/~dcubed/8191789-webrev/jdk10-0 >> >> This fix was (over) tested with a Mach5 tier[1-5] run. There were no >> unexpected test failures. >> >> These changes were sanity checked a couple of ways: >> >> - Compare pre-Thread-SMR thread.[ch]pp with thread.[ch]pp after this fix >> - Make sure that remaining Thread-SMR changes in thread.cpp and >> thread.hpp make sense to leave behind. >> - Similar comparison for thread.inline.hpp. >> - Compare code removed from thread.cpp with code added to threadSMR.cpp, >> compare code removed from thread.hpp with code added to threadSMR.hpp, >> compare code removed from thread.inline.hpp with code added to >> threadSMR.inline.hpp: >> - Make sure the deltas make sense. >> >> Thanks, in advance, for any comments, questions or suggestions. >> >> Dan >> > From daniel.daugherty at oracle.com Wed Dec 6 14:41:04 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 6 Dec 2017 09:41:04 -0500 Subject: RFR(S/M): 8191789 - migrate more Thread-SMR stuff from thread.[ch]pp -> threadSMR.[ch]pp In-Reply-To: <54561723-68C0-4CE1-8F00-758AA0CA0CD9@oracle.com> References: <3cb950e3-6a99-1f45-9f45-b51e982f1777@oracle.com> <22765116-19b8-79a0-dc7b-00a75eacbcf3@oracle.com> <54561723-68C0-4CE1-8F00-758AA0CA0CD9@oracle.com> Message-ID: <66b47996-59e4-cb4f-c969-5f02c7aab4bd@oracle.com> Jerry, Thanks for the review! Dan On 12/6/17 9:29 AM, Gerald Thornbrugh wrote: > Hi Dan, > > Your changes look good. > > Jerry >> On Dec 5, 2017, at 2:26 PM, Daniel D. Daugherty wrote: >> >> Greetings, >> >> I've updated the fix based on Stefan K's code review feedback (and my >> own self-review)... >> >> Delta webrev: >> >> http://cr.openjdk.java.net/~dcubed/8191789-webrev/jdk10-1-delta/ >> >> Full webrev: >> >> http://cr.openjdk.java.net/~dcubed/8191789-webrev/jdk10-1-full/ >> >> >> Summary of the changes in this round: >> >> - moved ThreadsList::remove_thread() >> - moved ThreadsListSetter::~ThreadsListSetter() and ThreadsListSetter::set() >> - remove Threads as a friend of class Thread >> - add ThreadsSMRSupport::update_smr_tlh_stats() to allow more ThreadsSMRSupport >> code to be private >> >> - refactor Threads-SMR code in Threads::add() to call >> new function ThreadsSMRSupport::add_thread() >> - refactor Threads-SMR code in Threads::remove() to call >> new function ThreadsSMRSupport::remove_thread() >> - more ThreadsSMRSupport functions can be private >> - move is_a_protected_JavaThread_with_lock() to >> threadSMR.inline.hpp >> >> >> I have a Mach5 tier[1-5] in progress for this round... >> >> Thanks, in advance, for any comments, questions or suggestions. >> >> Dan >> >> >> >> On 12/4/17 3:22 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> In terms of actual "new/changed" code, this is a "S" review. However, >>> because of code motion, the changed/insert/delete counts are the size >>> of an "M" or "L" review. >>> >>> Stefan K, this is one of your Thread-SMR follow-up suggestions so I need >>> to hear from you on this thread. Thanks! >>> >>> I have a simple (but tedious) cleanup fix for Thread-SMR. The bug is: >>> >>> JDK-8191789 migrate more Thread-SMR stuff from thread.[ch]pp -> threadSMR.[ch]pp >>> https://bugs.openjdk.java.net/browse/JDK-8191789 >>> >>> This fix is mostly code motion: >>> >>> - move Thread-SMR related code from thread.cpp -> threadSMR.cpp and >>> from thread.hpp -> threadSMR.hpp >>> - move Threads::_smr_* fields -> ThreadsSMRSupport class >>> - move Thread-SMR functions from Threads -> ThreadsSMRSupport class >>> - move Thread-SMR helper classes from thread.cpp -> threadsSMR.cpp >>> - rename a bunch of Threads::foo() calls -> ThreadsSMRSupport::foo() >>> >>> - collateral changes: >>> - DO_JAVA_THREADS macro usage by code moved to threadSMR.cpp have >>> to switch to JavaThreadIterator or some other function. >>> - Add ThreadsSMRSupport::inc_smr_java_thread_list_alloc_cnt(). >>> - Add ThreadsSMRSupport::update_smr_java_thread_list_max(). >>> - Cleanup "friends" for Thread class and ThreadsList class. >>> - Add includes of runtime/threadSMR.hpp in a few files. >>> >>> >>> Here is the webrev URL: >>> >>> http://cr.openjdk.java.net/~dcubed/8191789-webrev/jdk10-0 >>> >>> This fix was (over) tested with a Mach5 tier[1-5] run. There were no >>> unexpected test failures. >>> >>> These changes were sanity checked a couple of ways: >>> >>> - Compare pre-Thread-SMR thread.[ch]pp with thread.[ch]pp after this fix >>> - Make sure that remaining Thread-SMR changes in thread.cpp and >>> thread.hpp make sense to leave behind. >>> - Similar comparison for thread.inline.hpp. >>> - Compare code removed from thread.cpp with code added to threadSMR.cpp, >>> compare code removed from thread.hpp with code added to threadSMR.hpp, >>> compare code removed from thread.inline.hpp with code added to >>> threadSMR.inline.hpp: >>> - Make sure the deltas make sense. >>> >>> Thanks, in advance, for any comments, questions or suggestions. >>> >>> Dan >>> From calvin.cheung at oracle.com Wed Dec 6 17:05:38 2017 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Wed, 06 Dec 2017 09:05:38 -0800 Subject: RFR: 8193065: [TESTBUG]GCSharedStringsDuringDump.java: Exception in thread "main" java.lang.RuntimeException: String is not shared. In-Reply-To: <70BB9696-78ED-4652-B772-165730BBBA23@oracle.com> References: <70BB9696-78ED-4652-B772-165730BBBA23@oracle.com> Message-ID: <5A282362.4020607@oracle.com> Hi Jiangli, Is it also possible that the st0/st1 space cannot be allocated if there's no heap space? Otherwise, it looks good. thanks, Calvin On 12/5/17, 3:19 PM, Jiangli Zhou wrote: > Please review the following test fix that detects missing ?oa region? as a failure when there are extra allocations/GCs during CDS dump time. When failures are detected, a larger heap size is used for dumping. Please see more detailed analysis in the bug report. > > webrev: http://cr.openjdk.java.net/~jiangli/8193065/webrev.00/ > bug: https://bugs.openjdk.java.net/browse/JDK-8193065?filter=14921 > > Testing with hs tier1, tier2 and tier7. > > Thanks, > Jiangli From jiangli.zhou at oracle.com Wed Dec 6 17:33:05 2017 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 6 Dec 2017 09:33:05 -0800 Subject: RFR: 8193065: [TESTBUG]GCSharedStringsDuringDump.java: Exception in thread "main" java.lang.RuntimeException: String is not shared. In-Reply-To: References: <70BB9696-78ED-4652-B772-165730BBBA23@oracle.com> Message-ID: <1B3056F1-FE22-4ACA-BE7B-9BD96E6C0E2C@oracle.com> Thanks, Harold! Jiangli > On Dec 6, 2017, at 5:05 AM, harold seigel wrote: > > Hi Jiangli, > > This change looks good. > > Thanks, Harold > > > On 12/5/2017 6:19 PM, Jiangli Zhou wrote: >> Please review the following test fix that detects missing ?oa region? as a failure when there are extra allocations/GCs during CDS dump time. When failures are detected, a larger heap size is used for dumping. Please see more detailed analysis in the bug report. >> >> webrev: http://cr.openjdk.java.net/~jiangli/8193065/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8193065?filter=14921 >> >> Testing with hs tier1, tier2 and tier7. >> >> Thanks, >> Jiangli > From jiangli.zhou at oracle.com Wed Dec 6 17:48:18 2017 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 6 Dec 2017 09:48:18 -0800 Subject: RFR: 8193065: [TESTBUG]GCSharedStringsDuringDump.java: Exception in thread "main" java.lang.RuntimeException: String is not shared. In-Reply-To: <5A282362.4020607@oracle.com> References: <70BB9696-78ED-4652-B772-165730BBBA23@oracle.com> <5A282362.4020607@oracle.com> Message-ID: Hi Calvin, Thanks for the review. There could be only one string region if a single G1 region (in current execution) is large enough for all archived strings, in which case there would be only st0. I?m hesitate to add additional cases in the check for now without seeing the actual failure. We can add new case later if we run into any new failure case and investigate completely. Thanks, Jiangli > On Dec 6, 2017, at 9:05 AM, Calvin Cheung wrote: > > Hi Jiangli, > > Is it also possible that the st0/st1 space cannot be allocated if there's no heap space? > > Otherwise, it looks good. > > thanks, > Calvin > > On 12/5/17, 3:19 PM, Jiangli Zhou wrote: >> Please review the following test fix that detects missing ?oa region? as a failure when there are extra allocations/GCs during CDS dump time. When failures are detected, a larger heap size is used for dumping. Please see more detailed analysis in the bug report. >> >> webrev: http://cr.openjdk.java.net/~jiangli/8193065/webrev.00/ >> bug: https://bugs.openjdk.java.net/browse/JDK-8193065?filter=14921 >> >> Testing with hs tier1, tier2 and tier7. >> >> Thanks, >> Jiangli From calvin.cheung at oracle.com Wed Dec 6 17:55:14 2017 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Wed, 06 Dec 2017 09:55:14 -0800 Subject: RFR: 8193065: [TESTBUG]GCSharedStringsDuringDump.java: Exception in thread "main" java.lang.RuntimeException: String is not shared. In-Reply-To: References: <70BB9696-78ED-4652-B772-165730BBBA23@oracle.com> <5A282362.4020607@oracle.com> Message-ID: <5A282F02.7040107@oracle.com> On 12/6/17, 9:48 AM, Jiangli Zhou wrote: > Hi Calvin, > > Thanks for the review. There could be only one string region if a single G1 region (in current execution) is large enough for all archived strings, in which case there would be only st0. I?m hesitate to add additional cases in the check for now without seeing the actual failure. We can add new case later if we run into any new failure case and investigate completely. Okay. thanks, Calvin > > Thanks, > > Jiangli > >> On Dec 6, 2017, at 9:05 AM, Calvin Cheung wrote: >> >> Hi Jiangli, >> >> Is it also possible that the st0/st1 space cannot be allocated if there's no heap space? >> >> Otherwise, it looks good. >> >> thanks, >> Calvin >> >> On 12/5/17, 3:19 PM, Jiangli Zhou wrote: >>> Please review the following test fix that detects missing ?oa region? as a failure when there are extra allocations/GCs during CDS dump time. When failures are detected, a larger heap size is used for dumping. Please see more detailed analysis in the bug report. >>> >>> webrev: http://cr.openjdk.java.net/~jiangli/8193065/webrev.00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8193065?filter=14921 >>> >>> Testing with hs tier1, tier2 and tier7. >>> >>> Thanks, >>> Jiangli From kim.barrett at oracle.com Wed Dec 6 19:18:25 2017 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 6 Dec 2017 14:18:25 -0500 Subject: RFR (XS): 8193105: Print error code when map_memory_to_file() fails In-Reply-To: <15ead314-b0b4-a551-e9e4-fe77ce21fa75@oracle.com> References: <1491e772-b038-93ce-acc7-cd9c6e2325d5@oracle.com> <003d8069-7b69-85ef-997d-9435cca42446@oracle.com> <15ead314-b0b4-a551-e9e4-fe77ce21fa75@oracle.com> Message-ID: <5E0CF8CB-57BE-412B-BA66-5F5D008CC9B4@oracle.com> > On Dec 6, 2017, at 6:31 AM, David Holmes wrote: > > On 6/12/2017 9:25 PM, David Holmes wrote: >> Hi Sangheon, >> On 6/12/2017 5:46 PM, sangheon.kim wrote: >>> Hi all, >>> >>> Could I have some reviews for this change? >>> >>> JDK-8190308 (Implementation: JEP 316: Heap Allocation on Alternative Memory Devices) introduced a new test(TestAllocateHeapAt.java) but it is failing on Solaris-Sparc with fastdebug build. But unfortunately there's no error print when related function fails. >>> >>> This proposal is simply adding error code print for further investigation of JDK-8192871(TestAllocateHeapAt fails), not change its logic. >>> >>> CR: https://bugs.openjdk.java.net/browse/JDK-8193105 >>> Webrev: http://cr.openjdk.java.net/~sangheki/8193105/webrev.0 >>> Testing: hs-tier1 >> ! vm_exit_during_initialization(err_msg("Error in mapping Java heap at the given filesystem directory. error(%d)", ret)); >> You should use strerror(ret) to print a readable error string here. > > Except you can't because on OSX util_posix_fallocate doesn't necessarily return an error code! That's another bug in this particular so-called "posix" function! :( I agree that?s ?another bug?. I?m okay with Sangheon?s change as-is, in order to more quickly make progress on 8192871. There should be a follow-on bug to fix the OSX implementation of util_posix_fallocate and use strerror in that error message. > David > >> Thanks, >> David >>> Thanks, >>> Sangheon From sangheon.kim at oracle.com Wed Dec 6 19:19:29 2017 From: sangheon.kim at oracle.com (sangheon.kim) Date: Wed, 6 Dec 2017 11:19:29 -0800 Subject: RFR (XS): 8193105: Print error code when map_memory_to_file() fails In-Reply-To: <15ead314-b0b4-a551-e9e4-fe77ce21fa75@oracle.com> References: <1491e772-b038-93ce-acc7-cd9c6e2325d5@oracle.com> <003d8069-7b69-85ef-997d-9435cca42446@oracle.com> <15ead314-b0b4-a551-e9e4-fe77ce21fa75@oracle.com> Message-ID: <712f43be-9146-b244-c0d5-0af33ef10716@oracle.com> Hi David, Thank you for reviewing this. On 12/06/2017 03:31 AM, David Holmes wrote: > On 6/12/2017 9:25 PM, David Holmes wrote: >> Hi Sangheon, >> >> On 6/12/2017 5:46 PM, sangheon.kim wrote: >>> Hi all, >>> >>> Could I have some reviews for this change? >>> >>> JDK-8190308 (Implementation: JEP 316: Heap Allocation on Alternative >>> Memory Devices) introduced a new test(TestAllocateHeapAt.java) but >>> it is failing on Solaris-Sparc with fastdebug build. But >>> unfortunately there's no error print when related function fails. >>> >>> This proposal is simply adding error code print for further >>> investigation of JDK-8192871(TestAllocateHeapAt fails), not change >>> its logic. >>> >>> CR: https://bugs.openjdk.java.net/browse/JDK-8193105 >>> Webrev: http://cr.openjdk.java.net/~sangheki/8193105/webrev.0 >>> Testing: hs-tier1 >> >> !???? vm_exit_during_initialization(err_msg("Error in mapping Java >> heap at the given filesystem directory. error(%d)", ret)); >> >> You should use strerror(ret) to print a readable error string here. Done. > > Except you can't because on OSX util_posix_fallocate doesn't > necessarily return an error code! That's another bug in this > particular so-called "posix" function! :( OSX version of util_posix_fallocate() uses fcntl(would return 9 kinds of errors) and ftruncate(12 errors). And both functions set errno when those functions fail(i.e. return -1) [1]. But when we get a return value of -1, we don't know which function is failed. If this is your concern I would prefer to address under different CR as I wanted to add this log for Sparc ASAP. JDK-8192871 is reported on Sparc so far. FYI, as there are 3 duplicated errors(EACCES, EBADF and EINVAL) between 2 functions, we can't distinguish in these cases. webrev: http://cr.openjdk.java.net/~sangheki/8193105/webrev.1 [1]: http://www.manpages.info/macosx/fcntl.2.html http://www.manpages.info/macosx/ftruncate.2.html Thanks, Sangheon > > David > >> Thanks, >> David >> >>> Thanks, >>> Sangheon From sangheon.kim at oracle.com Wed Dec 6 19:30:37 2017 From: sangheon.kim at oracle.com (Sangheon Kim) Date: Wed, 6 Dec 2017 11:30:37 -0800 Subject: RFR (XS): 8193105: Print error code when map_memory_to_file() fails In-Reply-To: <712f43be-9146-b244-c0d5-0af33ef10716@oracle.com> References: <1491e772-b038-93ce-acc7-cd9c6e2325d5@oracle.com> <003d8069-7b69-85ef-997d-9435cca42446@oracle.com> <15ead314-b0b4-a551-e9e4-fe77ce21fa75@oracle.com> <712f43be-9146-b244-c0d5-0af33ef10716@oracle.com> Message-ID: <5A28455D.2040300@oracle.com> On 2017-12-06 ?? 11:19, sangheon.kim wrote: > Hi David, > > Thank you for reviewing this. > > On 12/06/2017 03:31 AM, David Holmes wrote: >> On 6/12/2017 9:25 PM, David Holmes wrote: >>> Hi Sangheon, >>> >>> On 6/12/2017 5:46 PM, sangheon.kim wrote: >>>> Hi all, >>>> >>>> Could I have some reviews for this change? >>>> >>>> JDK-8190308 (Implementation: JEP 316: Heap Allocation on >>>> Alternative Memory Devices) introduced a new >>>> test(TestAllocateHeapAt.java) but it is failing on Solaris-Sparc >>>> with fastdebug build. But unfortunately there's no error print when >>>> related function fails. >>>> >>>> This proposal is simply adding error code print for further >>>> investigation of JDK-8192871(TestAllocateHeapAt fails), not change >>>> its logic. >>>> >>>> CR: https://bugs.openjdk.java.net/browse/JDK-8193105 >>>> Webrev: http://cr.openjdk.java.net/~sangheki/8193105/webrev.0 >>>> Testing: hs-tier1 >>> >>> ! vm_exit_during_initialization(err_msg("Error in mapping Java >>> heap at the given filesystem directory. error(%d)", ret)); >>> >>> You should use strerror(ret) to print a readable error string here. > Done. > >> >> Except you can't because on OSX util_posix_fallocate doesn't >> necessarily return an error code! That's another bug in this >> particular so-called "posix" function! :( > OSX version of util_posix_fallocate() uses fcntl(would return 9 kinds > of errors) and ftruncate(12 errors). And both functions set errno when > those functions fail(i.e. return -1) [1]. But when we get a return > value of -1, we don't know which function is failed. If this is your > concern I would prefer to address under different CR as I wanted to > add this log for Sparc ASAP. JDK-8192871 is reported on Sparc so far. Sorry, I misunderstood what you said. Now I understand that OSX version is not returning the error code. I will file a new bug for this. Thanks, Sangheon > > FYI, as there are 3 duplicated errors(EACCES, EBADF and EINVAL) > between 2 functions, we can't distinguish in these cases. > > webrev: http://cr.openjdk.java.net/~sangheki/8193105/webrev.1 > > [1]: > http://www.manpages.info/macosx/fcntl.2.html > http://www.manpages.info/macosx/ftruncate.2.html > > Thanks, > Sangheon > > >> >> David >> >>> Thanks, >>> David >>> >>>> Thanks, >>>> Sangheon > From ioi.lam at oracle.com Wed Dec 6 20:11:48 2017 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 6 Dec 2017 12:11:48 -0800 Subject: RFR: 8193065: [TESTBUG]GCSharedStringsDuringDump.java: Exception in thread "main" java.lang.RuntimeException: String is not shared. In-Reply-To: References: <70BB9696-78ED-4652-B772-165730BBBA23@oracle.com> <5A282362.4020607@oracle.com> Message-ID: <26ee3eda-20a7-ab0d-85cf-e5094379f615@oracle.com> Do we have any test case that would force a st1 region to be used? Thanks - Ioi On 12/6/17 9:48 AM, Jiangli Zhou wrote: > Hi Calvin, > > Thanks for the review. There could be only one string region if a single G1 region (in current execution) is large enough for all archived strings, in which case there would be only st0. I?m hesitate to add additional cases in the check for now without seeing the actual failure. We can add new case later if we run into any new failure case and investigate completely. > > Thanks, > > Jiangli > >> On Dec 6, 2017, at 9:05 AM, Calvin Cheung wrote: >> >> Hi Jiangli, >> >> Is it also possible that the st0/st1 space cannot be allocated if there's no heap space? >> >> Otherwise, it looks good. >> >> thanks, >> Calvin >> >> On 12/5/17, 3:19 PM, Jiangli Zhou wrote: >>> Please review the following test fix that detects missing ?oa region? as a failure when there are extra allocations/GCs during CDS dump time. When failures are detected, a larger heap size is used for dumping. Please see more detailed analysis in the bug report. >>> >>> webrev: http://cr.openjdk.java.net/~jiangli/8193065/webrev.00/ >>> bug: https://bugs.openjdk.java.net/browse/JDK-8193065?filter=14921 >>> >>> Testing with hs tier1, tier2 and tier7. >>> >>> Thanks, >>> Jiangli From coleen.phillimore at oracle.com Wed Dec 6 21:59:15 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 6 Dec 2017 16:59:15 -0500 Subject: RFR (M) 8186903: Remove j-types from Atomic Message-ID: Summary: Change parameter types from jlong, jint, jbyte to int64_t, int32_t and int8_t respectively Leave renaming functions for later change. Ran JPRT which builds more Oracle platforms, mach5 tier1-5 on windows/linux x64 and tier1 on solaris-sparcv9.? Also built Zero product mode (fails building fastdebug for some other reason). Other platforms: could you please test this patch? open webrev at http://cr.openjdk.java.net/~coleenp/8186903.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8186903 This change is for JDK 11. Thanks, Coleen From david.holmes at oracle.com Thu Dec 7 01:54:47 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 7 Dec 2017 11:54:47 +1000 Subject: RFR (XS): 8193105: Print error code when map_memory_to_file() fails In-Reply-To: <5A28455D.2040300@oracle.com> References: <1491e772-b038-93ce-acc7-cd9c6e2325d5@oracle.com> <003d8069-7b69-85ef-997d-9435cca42446@oracle.com> <15ead314-b0b4-a551-e9e4-fe77ce21fa75@oracle.com> <712f43be-9146-b244-c0d5-0af33ef10716@oracle.com> <5A28455D.2040300@oracle.com> Message-ID: On 7/12/2017 5:30 AM, Sangheon Kim wrote: > On 2017-12-06 ?? 11:19, sangheon.kim wrote: >> Hi David, >> >> Thank you for reviewing this. >> >> On 12/06/2017 03:31 AM, David Holmes wrote: >>> On 6/12/2017 9:25 PM, David Holmes wrote: >>>> Hi Sangheon, >>>> >>>> On 6/12/2017 5:46 PM, sangheon.kim wrote: >>>>> Hi all, >>>>> >>>>> Could I have some reviews for this change? >>>>> >>>>> JDK-8190308 (Implementation: JEP 316: Heap Allocation on >>>>> Alternative Memory Devices) introduced a new >>>>> test(TestAllocateHeapAt.java) but it is failing on Solaris-Sparc >>>>> with fastdebug build. But unfortunately there's no error print when >>>>> related function fails. >>>>> >>>>> This proposal is simply adding error code print for further >>>>> investigation of JDK-8192871(TestAllocateHeapAt fails), not change >>>>> its logic. >>>>> >>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8193105 >>>>> Webrev: http://cr.openjdk.java.net/~sangheki/8193105/webrev.0 >>>>> Testing: hs-tier1 >>>> >>>> !???? vm_exit_during_initialization(err_msg("Error in mapping Java >>>> heap at the given filesystem directory. error(%d)", ret)); >>>> >>>> You should use strerror(ret) to print a readable error string here. >> Done. >> >>> >>> Except you can't because on OSX util_posix_fallocate doesn't >>> necessarily return an error code! That's another bug in this >>> particular so-called "posix" function! :( >> OSX version of util_posix_fallocate() uses fcntl(would return 9 kinds >> of errors) and ftruncate(12 errors). And both functions set errno when >> those functions fail(i.e. return -1) [1]. But when we get a return >> value of -1, we don't know which function is failed. If this is your >> concern I would prefer to address under different CR as I wanted to >> add this log for Sparc ASAP. JDK-8192871 is reported on Sparc so far. > Sorry, I misunderstood what you said. > Now I understand that OSX version is not returning the error code. I > will file a new bug for this. Right. But that also means using strerror is not appropriate ... though will it actually cause a problem? Let's go with Kim's suggestion and just stick with your original version that prints the numeric value. The strerror can be added once the other bug is fixed. Thanks, David > Thanks, > Sangheon > > >> >> FYI, as there are 3 duplicated errors(EACCES, EBADF and EINVAL) >> between 2 functions, we can't distinguish in these cases. >> >> webrev: http://cr.openjdk.java.net/~sangheki/8193105/webrev.1 >> >> [1]: >> http://www.manpages.info/macosx/fcntl.2.html >> http://www.manpages.info/macosx/ftruncate.2.html >> >> Thanks, >> Sangheon >> >> >>> >>> David >>> >>>> Thanks, >>>> David >>>> >>>>> Thanks, >>>>> Sangheon >> > From david.holmes at oracle.com Thu Dec 7 02:41:16 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 7 Dec 2017 12:41:16 +1000 Subject: RFR (M) 8186903: Remove j-types from Atomic In-Reply-To: References: Message-ID: <11698d07-aee7-0123-4edb-ed3d57317b87@oracle.com> Hi Coleen, On 7/12/2017 7:59 AM, coleen.phillimore at oracle.com wrote: > Summary: Change parameter types from jlong, jint, jbyte to int64_t, > int32_t and int8_t respectively That's fine. But you also made a bunch of changes to rename the "ptr" variants to "long", and in the process changed intptr_t to int64_t. The change ptr->long isn't really accurate. And intptr_t and int64_t are different sizes on 32-bit! So this change seems problematic and out of scope by your own description. That said I thought we had/were getting rid of the "ptr" variants ?? > Leave renaming functions for later change. > > Ran JPRT which builds more Oracle platforms, mach5 tier1-5 on > windows/linux x64 and tier1 on solaris-sparcv9.? Also built Zero product > mode (fails building fastdebug for some other reason). > > Other platforms: could you please test this patch? > > open webrev at http://cr.openjdk.java.net/~coleenp/8186903.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8186903 > > This change is for JDK 11. src/hotspot/cpu/x86/stubGenerator_x86_32.cpp Return type should be int32_t not int src/hotspot/os_cpu/windows_x86/os_windows_x86.hpp - static intptr_t (*atomic_xchg_long_func) (jlong, volatile jlong*); - static intptr_t atomic_xchg_long_bootstrap (jlong, volatile jlong*); Wow - that looks like a bug! Only returns 32-bits on 32-bit! Everything else seems fine. Thanks, David > Thanks, > Coleen From sangheon.kim at oracle.com Thu Dec 7 03:48:21 2017 From: sangheon.kim at oracle.com (sangheon.kim) Date: Wed, 6 Dec 2017 19:48:21 -0800 Subject: RFR (XS): 8193105: Print error code when map_memory_to_file() fails In-Reply-To: References: <1491e772-b038-93ce-acc7-cd9c6e2325d5@oracle.com> <003d8069-7b69-85ef-997d-9435cca42446@oracle.com> <15ead314-b0b4-a551-e9e4-fe77ce21fa75@oracle.com> <712f43be-9146-b244-c0d5-0af33ef10716@oracle.com> <5A28455D.2040300@oracle.com> Message-ID: On 12/06/2017 05:54 PM, David Holmes wrote: > On 7/12/2017 5:30 AM, Sangheon Kim wrote: >> On 2017-12-06 ?? 11:19, sangheon.kim wrote: >>> Hi David, >>> >>> Thank you for reviewing this. >>> >>> On 12/06/2017 03:31 AM, David Holmes wrote: >>>> On 6/12/2017 9:25 PM, David Holmes wrote: >>>>> Hi Sangheon, >>>>> >>>>> On 6/12/2017 5:46 PM, sangheon.kim wrote: >>>>>> Hi all, >>>>>> >>>>>> Could I have some reviews for this change? >>>>>> >>>>>> JDK-8190308 (Implementation: JEP 316: Heap Allocation on >>>>>> Alternative Memory Devices) introduced a new >>>>>> test(TestAllocateHeapAt.java) but it is failing on Solaris-Sparc >>>>>> with fastdebug build. But unfortunately there's no error print >>>>>> when related function fails. >>>>>> >>>>>> This proposal is simply adding error code print for further >>>>>> investigation of JDK-8192871(TestAllocateHeapAt fails), not >>>>>> change its logic. >>>>>> >>>>>> CR: https://bugs.openjdk.java.net/browse/JDK-8193105 >>>>>> Webrev: http://cr.openjdk.java.net/~sangheki/8193105/webrev.0 >>>>>> Testing: hs-tier1 >>>>> >>>>> !???? vm_exit_during_initialization(err_msg("Error in mapping Java >>>>> heap at the given filesystem directory. error(%d)", ret)); >>>>> >>>>> You should use strerror(ret) to print a readable error string here. >>> Done. >>> >>>> >>>> Except you can't because on OSX util_posix_fallocate doesn't >>>> necessarily return an error code! That's another bug in this >>>> particular so-called "posix" function! :( >>> OSX version of util_posix_fallocate() uses fcntl(would return 9 >>> kinds of errors) and ftruncate(12 errors). And both functions set >>> errno when those functions fail(i.e. return -1) [1]. But when we get >>> a return value of -1, we don't know which function is failed. If >>> this is your concern I would prefer to address under different CR as >>> I wanted to add this log for Sparc ASAP. JDK-8192871 is reported on >>> Sparc so far. >> Sorry, I misunderstood what you said. >> Now I understand that OSX version is not returning the error code. I >> will file a new bug for this. > > Right. But that also means using strerror is not appropriate ... > though will it actually cause a problem? Let's go with Kim's > suggestion and just stick with your original version that prints the > numeric value. The strerror can be added once the other bug is fixed. Okay, I will push webrev.0 which is you and Kim reviewed version. FYI, I filed JDK-8193146(OSX version of util_posix_fallocate() doesn't return error code) to address the problem discussed above. Thanks, Sangheon > > Thanks, > David > >> Thanks, >> Sangheon >> >> >>> >>> FYI, as there are 3 duplicated errors(EACCES, EBADF and EINVAL) >>> between 2 functions, we can't distinguish in these cases. >>> >>> webrev: http://cr.openjdk.java.net/~sangheki/8193105/webrev.1 >>> >>> [1]: >>> http://www.manpages.info/macosx/fcntl.2.html >>> http://www.manpages.info/macosx/ftruncate.2.html >>> >>> Thanks, >>> Sangheon >>> >>> >>>> >>>> David >>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Thanks, >>>>>> Sangheon >>> >> From coleen.phillimore at oracle.com Thu Dec 7 04:00:23 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 6 Dec 2017 23:00:23 -0500 Subject: RFR (M) 8186903: Remove j-types from Atomic In-Reply-To: <11698d07-aee7-0123-4edb-ed3d57317b87@oracle.com> References: <11698d07-aee7-0123-4edb-ed3d57317b87@oracle.com> Message-ID: <4a4bc91d-f63f-4160-d4a0-74d015dd58af@oracle.com> On 12/6/17 9:41 PM, David Holmes wrote: > Hi Coleen, > > On 7/12/2017 7:59 AM, coleen.phillimore at oracle.com wrote: >> Summary: Change parameter types from jlong, jint, jbyte to int64_t, >> int32_t and int8_t respectively > > That's fine. But you also made a bunch of changes to rename the "ptr" > variants to "long", and in the process changed intptr_t to int64_t. > The change ptr->long isn't really accurate. And intptr_t and int64_t > are different sizes on 32-bit! So this change seems problematic and > out of scope by your own description. That said I thought we had/were > getting rid of the "ptr" variants ?? Yes, I did rename atomic_add_ptr_entry to atomic_add_long_entry. This is to match the other names which are currently empty, "long" and "byte".?? This was a last vestige of the ptr variants.?? It's only used on 64 bit windows, so changing it to intptr_t to int64_t is correct.?? For some reason, there isn't a long variant on 32 bits.? Possibly because we don't add jlong values in the vm? ent So this renaming makes it consistent with the other names, which then can all be changed at once, when nice names are agreed upon. > >> Leave renaming functions for later change. >> >> Ran JPRT which builds more Oracle platforms, mach5 tier1-5 on >> windows/linux x64 and tier1 on solaris-sparcv9.? Also built Zero >> product mode (fails building fastdebug for some other reason). >> >> Other platforms: could you please test this patch? >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8186903.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8186903 >> >> This change is for JDK 11. > > src/hotspot/cpu/x86/stubGenerator_x86_32.cpp > > Return type should be int32_t not int > > src/hotspot/os_cpu/windows_x86/os_windows_x86.hpp > > -? static intptr_t? (*atomic_xchg_long_func)???? (jlong, volatile > jlong*); > -? static intptr_t? atomic_xchg_long_bootstrap?? (jlong, volatile > jlong*); > > Wow - that looks like a bug! Only returns 32-bits on 32-bit! This one also is only used on 64 bit.? I have to confess I don't follow all the paths of the atomics and their various translations down to the platform levels.?? I'm not sure how windows 32 bit calls atomic_add or xchg for 64 bit values (or if it is not implemented). > > Everything else seems fine. > Thanks for the eagle eye review. Coleen > Thanks, > David > >> Thanks, >> Coleen From david.holmes at oracle.com Thu Dec 7 04:33:25 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 7 Dec 2017 14:33:25 +1000 Subject: RFR (M) 8186903: Remove j-types from Atomic In-Reply-To: <4a4bc91d-f63f-4160-d4a0-74d015dd58af@oracle.com> References: <11698d07-aee7-0123-4edb-ed3d57317b87@oracle.com> <4a4bc91d-f63f-4160-d4a0-74d015dd58af@oracle.com> Message-ID: On 7/12/2017 2:00 PM, coleen.phillimore at oracle.com wrote: > On 12/6/17 9:41 PM, David Holmes wrote: >> Hi Coleen, >> >> On 7/12/2017 7:59 AM, coleen.phillimore at oracle.com wrote: >>> Summary: Change parameter types from jlong, jint, jbyte to int64_t, >>> int32_t and int8_t respectively >> >> That's fine. But you also made a bunch of changes to rename the "ptr" >> variants to "long", and in the process changed intptr_t to int64_t. >> The change ptr->long isn't really accurate. And intptr_t and int64_t >> are different sizes on 32-bit! So this change seems problematic and >> out of scope by your own description. That said I thought we had/were >> getting rid of the "ptr" variants ?? > > Yes, I did rename atomic_add_ptr_entry to atomic_add_long_entry. This is > to match the other names which are currently empty, "long" and "byte". > This was a last vestige of the ptr variants.?? It's only used on 64 bit > windows, so changing it to intptr_t to int64_t is correct.?? For some > reason, there isn't a long variant on 32 bits.? Possibly because we > don't add jlong values in the vm? Okay. Was hard to see this was all on 64-bit only. Though not clear why this renaming needs to happen at all at this time? I'm finding it very confusing trying to see where we are going with this - shouldn't all the ptr variants become unused with the new Atomic API? I find them easier to spot when written as _ptr_ rather than _long_. (And on Windows a long isn't 64-bits anyway!) > ent > So this renaming makes it consistent with the other names, which then > can all be changed at once, when nice names are agreed upon. >> >>> Leave renaming functions for later change. >>> >>> Ran JPRT which builds more Oracle platforms, mach5 tier1-5 on >>> windows/linux x64 and tier1 on solaris-sparcv9.? Also built Zero >>> product mode (fails building fastdebug for some other reason). >>> >>> Other platforms: could you please test this patch? >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8186903.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8186903 >>> >>> This change is for JDK 11. >> >> src/hotspot/cpu/x86/stubGenerator_x86_32.cpp >> >> Return type should be int32_t not int >> >> src/hotspot/os_cpu/windows_x86/os_windows_x86.hpp >> >> -? static intptr_t? (*atomic_xchg_long_func)???? (jlong, volatile >> jlong*); >> -? static intptr_t? atomic_xchg_long_bootstrap?? (jlong, volatile >> jlong*); >> >> Wow - that looks like a bug! Only returns 32-bits on 32-bit! > > This one also is only used on 64 bit.? I have to confess I don't follow > all the paths of the atomics and their various translations down to the > platform levels.?? I'm not sure how windows 32 bit calls atomic_add or > xchg for 64 bit values (or if it is not implemented). Not implemented at the lowest levels AFAICS - only load/store and cmpxchg<8>. Of course the other atomics can then be written at a higher-level in terms of cmpxchg. The whole use of the stubgenerator for atomics is something that needs re-examining as I think it is completely unnecessary today (and likely for quite some time). The opening comment in atomic_windows_x86.hpp is somewhat startling as we approach 2018 :) // The following alternative implementations are needed because // Windows 95 doesn't support (some of) the corresponding Windows NT // calls. Furthermore, these versions allow inlining in the caller. // (More precisely: The documentation for InterlockedExchange says // it is supported for Windows 95. However, when single-stepping // through the assembly code we cannot step into the routine and // when looking at the routine address we see only garbage code. // Better safe then sorry!). Was bug 7/31/98 (gri). Cheers, David >> >> Everything else seems fine. >> > > Thanks for the eagle eye review. > Coleen >> Thanks, >> David >> >>> Thanks, >>> Coleen > From coleen.phillimore at oracle.com Thu Dec 7 13:11:01 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 7 Dec 2017 08:11:01 -0500 Subject: RFR (M) 8186903: Remove j-types from Atomic In-Reply-To: References: <11698d07-aee7-0123-4edb-ed3d57317b87@oracle.com> <4a4bc91d-f63f-4160-d4a0-74d015dd58af@oracle.com> Message-ID: <65c8cf7b-e3ba-17e5-89ec-4760ffd5884f@oracle.com> On 12/6/17 11:33 PM, David Holmes wrote: > On 7/12/2017 2:00 PM, coleen.phillimore at oracle.com wrote: >> On 12/6/17 9:41 PM, David Holmes wrote: >>> Hi Coleen, >>> >>> On 7/12/2017 7:59 AM, coleen.phillimore at oracle.com wrote: >>>> Summary: Change parameter types from jlong, jint, jbyte to int64_t, >>>> int32_t and int8_t respectively >>> >>> That's fine. But you also made a bunch of changes to rename the >>> "ptr" variants to "long", and in the process changed intptr_t to >>> int64_t. The change ptr->long isn't really accurate. And intptr_t >>> and int64_t are different sizes on 32-bit! So this change seems >>> problematic and out of scope by your own description. That said I >>> thought we had/were getting rid of the "ptr" variants ?? >> >> Yes, I did rename atomic_add_ptr_entry to atomic_add_long_entry. This >> is to match the other names which are currently empty, "long" and >> "byte". This was a last vestige of the ptr variants.?? It's only used >> on 64 bit windows, so changing it to intptr_t to int64_t is >> correct.?? For some reason, there isn't a long variant on 32 bits.? >> Possibly because we don't add jlong values in the vm? > > Okay. Was hard to see this was all on 64-bit only. > > Though not clear why this renaming needs to happen at all at this > time? I'm finding it very confusing trying to see where we are going > with this - shouldn't all the ptr variants become unused with the new > Atomic API? I find them easier to spot when written as _ptr_ rather > than _long_. (And on Windows a long isn't 64-bits anyway!) Yes, all the ptrs variants were removed in a previous change but I'd missed this renaming this one to long.? Since I was fixing the arguments for this function, I took the opportunity to also change the name in the same line.? I could file a new RFE for this and separate out the few lines.? The _long_ matches the other function names, and this case is actually used on _long_ because by this point the pointers have been normalized by template magic to long when they get here.?? See the other related functions in this change: http://cr.openjdk.java.net/~coleenp/8186903.01/webrev/src/hotspot/os_cpu/windows_x86/os_windows_x86.hpp.udiff.html > >> ent >> So this renaming makes it consistent with the other names, which then >> can all be changed at once, when nice names are agreed upon. >>> >>>> Leave renaming functions for later change. >>>> >>>> Ran JPRT which builds more Oracle platforms, mach5 tier1-5 on >>>> windows/linux x64 and tier1 on solaris-sparcv9.? Also built Zero >>>> product mode (fails building fastdebug for some other reason). >>>> >>>> Other platforms: could you please test this patch? >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8186903.01/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8186903 >>>> >>>> This change is for JDK 11. >>> >>> src/hotspot/cpu/x86/stubGenerator_x86_32.cpp >>> >>> Return type should be int32_t not int >>> >>> src/hotspot/os_cpu/windows_x86/os_windows_x86.hpp >>> >>> -? static intptr_t? (*atomic_xchg_long_func)???? (jlong, volatile >>> jlong*); >>> -? static intptr_t? atomic_xchg_long_bootstrap?? (jlong, volatile >>> jlong*); >>> >>> Wow - that looks like a bug! Only returns 32-bits on 32-bit! >> >> This one also is only used on 64 bit.? I have to confess I don't >> follow all the paths of the atomics and their various translations >> down to the platform levels.?? I'm not sure how windows 32 bit calls >> atomic_add or xchg for 64 bit values (or if it is not implemented). > > Not implemented at the lowest levels AFAICS - only load/store and > cmpxchg<8>. Of course the other atomics can then be written at a > higher-level in terms of cmpxchg. > > The whole use of the stubgenerator for atomics is something that needs > re-examining as I think it is completely unnecessary today (and likely > for quite some time). The opening comment in atomic_windows_x86.hpp is > somewhat startling as we approach 2018 :) I asked about this in the review and Erik said they were needed for some reason, but it would be nice to have these cleaned up somehow.?? Kim has some ideas for simplifying the implementation. My script to find all these names goes something like this: foreach atomic (cmpxchg xchg add load store) ... ?? ? foreach type (entry func bootstrap) ... ????????? foreach ("" "long" "byte") ... > > // The following alternative implementations are needed because > // Windows 95 doesn't support (some of) the corresponding Windows NT > // calls. Furthermore, these versions allow inlining in the caller. > // (More precisely: The documentation for InterlockedExchange says > // it is supported for Windows 95. However, when single-stepping > // through the assembly code we cannot step into the routine and > // when looking at the routine address we see only garbage code. > // Better safe then sorry!). Was bug 7/31/98 (gri). Yeah, good thing we can single step on Windows 95! Thanks, Coleen > > Cheers, > David > >>> >>> Everything else seems fine. >>> >> >> Thanks for the eagle eye review. >> Coleen >>> Thanks, >>> David >>> >>>> Thanks, >>>> Coleen >> From coleen.phillimore at oracle.com Thu Dec 7 15:28:33 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 7 Dec 2017 10:28:33 -0500 Subject: RFR (M) 8186903: Remove j-types from Atomic In-Reply-To: <65c8cf7b-e3ba-17e5-89ec-4760ffd5884f@oracle.com> References: <11698d07-aee7-0123-4edb-ed3d57317b87@oracle.com> <4a4bc91d-f63f-4160-d4a0-74d015dd58af@oracle.com> <65c8cf7b-e3ba-17e5-89ec-4760ffd5884f@oracle.com> Message-ID: On 12/7/17 8:11 AM, coleen.phillimore at oracle.com wrote: > > > On 12/6/17 11:33 PM, David Holmes wrote: >> On 7/12/2017 2:00 PM, coleen.phillimore at oracle.com wrote: >>> On 12/6/17 9:41 PM, David Holmes wrote: >>>> Hi Coleen, >>>> >>>> On 7/12/2017 7:59 AM, coleen.phillimore at oracle.com wrote: >>>>> Summary: Change parameter types from jlong, jint, jbyte to >>>>> int64_t, int32_t and int8_t respectively >>>> >>>> That's fine. But you also made a bunch of changes to rename the >>>> "ptr" variants to "long", and in the process changed intptr_t to >>>> int64_t. The change ptr->long isn't really accurate. And intptr_t >>>> and int64_t are different sizes on 32-bit! So this change seems >>>> problematic and out of scope by your own description. That said I >>>> thought we had/were getting rid of the "ptr" variants ?? >>> >>> Yes, I did rename atomic_add_ptr_entry to atomic_add_long_entry. >>> This is to match the other names which are currently empty, "long" >>> and "byte". This was a last vestige of the ptr variants.?? It's only >>> used on 64 bit windows, so changing it to intptr_t to int64_t is >>> correct. For some reason, there isn't a long variant on 32 bits. >>> Possibly because we don't add jlong values in the vm? >> >> Okay. Was hard to see this was all on 64-bit only. >> >> Though not clear why this renaming needs to happen at all at this >> time? I'm finding it very confusing trying to see where we are going >> with this - shouldn't all the ptr variants become unused with the new >> Atomic API? I find them easier to spot when written as _ptr_ rather >> than _long_. (And on Windows a long isn't 64-bits anyway!) > > Yes, all the ptrs variants were removed in a previous change but I'd > missed this renaming this one to long.? Since I was fixing the > arguments for this function, I took the opportunity to also change the > name in the same line.? I could file a new RFE for this and separate > out the few lines.? The _long_ matches the other function names, and > this case is actually used on _long_ because by this point the > pointers have been normalized by template magic to long when they get > here.?? See the other related functions in this change: Sorry, I meant _long_ matches other function names and this case is actually used on int64_t because the pointers have been normalized to 8 byte int64_t, not _long_ because _long_ is 32 bits on windows.?? So much confuse. thanks, Coleen > > http://cr.openjdk.java.net/~coleenp/8186903.01/webrev/src/hotspot/os_cpu/windows_x86/os_windows_x86.hpp.udiff.html > >> >>> ent >>> So this renaming makes it consistent with the other names, which >>> then can all be changed at once, when nice names are agreed upon. >>>> >>>>> Leave renaming functions for later change. >>>>> >>>>> Ran JPRT which builds more Oracle platforms, mach5 tier1-5 on >>>>> windows/linux x64 and tier1 on solaris-sparcv9.? Also built Zero >>>>> product mode (fails building fastdebug for some other reason). >>>>> >>>>> Other platforms: could you please test this patch? >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8186903.01/webrev >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8186903 >>>>> >>>>> This change is for JDK 11. >>>> >>>> src/hotspot/cpu/x86/stubGenerator_x86_32.cpp >>>> >>>> Return type should be int32_t not int >>>> >>>> src/hotspot/os_cpu/windows_x86/os_windows_x86.hpp >>>> >>>> -? static intptr_t? (*atomic_xchg_long_func)???? (jlong, volatile >>>> jlong*); >>>> -? static intptr_t? atomic_xchg_long_bootstrap?? (jlong, volatile >>>> jlong*); >>>> >>>> Wow - that looks like a bug! Only returns 32-bits on 32-bit! >>> >>> This one also is only used on 64 bit.? I have to confess I don't >>> follow all the paths of the atomics and their various translations >>> down to the platform levels.?? I'm not sure how windows 32 bit calls >>> atomic_add or xchg for 64 bit values (or if it is not implemented). >> >> Not implemented at the lowest levels AFAICS - only load/store and >> cmpxchg<8>. Of course the other atomics can then be written at a >> higher-level in terms of cmpxchg. >> >> The whole use of the stubgenerator for atomics is something that >> needs re-examining as I think it is completely unnecessary today (and >> likely for quite some time). The opening comment in >> atomic_windows_x86.hpp is somewhat startling as we approach 2018 :) > > I asked about this in the review and Erik said they were needed for > some reason, but it would be nice to have these cleaned up somehow.?? > Kim has some ideas for simplifying the implementation. My script to > find all these names goes something like this: > > foreach atomic (cmpxchg xchg add load store) > ... > ?? ? foreach type (entry func bootstrap) > ... > ????????? foreach ("" "long" "byte") > ... > >> >> // The following alternative implementations are needed because >> // Windows 95 doesn't support (some of) the corresponding Windows NT >> // calls. Furthermore, these versions allow inlining in the caller. >> // (More precisely: The documentation for InterlockedExchange says >> // it is supported for Windows 95. However, when single-stepping >> // through the assembly code we cannot step into the routine and >> // when looking at the routine address we see only garbage code. >> // Better safe then sorry!). Was bug 7/31/98 (gri). > > Yeah, good thing we can single step on Windows 95! > > Thanks, > Coleen > >> >> Cheers, >> David >> >>>> >>>> Everything else seems fine. >>>> >>> >>> Thanks for the eagle eye review. >>> Coleen >>>> Thanks, >>>> David >>>> >>>>> Thanks, >>>>> Coleen >>> > From zgu at redhat.com Thu Dec 7 15:40:37 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Thu, 7 Dec 2017 10:40:37 -0500 Subject: [8u] RFR 8186770: NMT: Report metadata information in NMT summary Message-ID: Please review this 8u backport. There are minor conflicts after file path changes. --- virtualMemoryTracker.cpp +++ virtualMemoryTracker.cpp @@ -1,5 +1,5 @@ /* - * Copyright (c) 2013, 2016, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2013, 2017, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -23,6 +23,7 @@ */ #include "precompiled.hpp" +#include "memory/metaspace.hpp" #include "runtime/atomic.hpp" #include "runtime/os.hpp" #include "runtime/threadCritical.hpp" Bug: https://bugs.openjdk.java.net/browse/JDK-8186770 Webrev: http://cr.openjdk.java.net/~zgu/8186770/webrev.8u.00/ JDK10 code review: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-September/024559.html Thanks, -Zhengyu From daniel.daugherty at oracle.com Thu Dec 7 16:38:47 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 7 Dec 2017 11:38:47 -0500 Subject: RFR(XXS): 8182307 - Error during JRMP connection establishment Message-ID: <58075a8f-1732-7b9e-74b1-3e36189f87fd@oracle.com> Greetings, I have a small fix for a very intermittent ServerSocket related test failure: ??? JDK-8182307: Error during JRMP connection establishment ??? https://bugs.openjdk.java.net/browse/JDK-8182307 The fix is copied from Jerry's work on the following bugs: ??? JDK-8182757 JDWP: Socket Transport handshake hangs on Solaris ??? https://bugs.openjdk.java.net/browse/JDK-8182757 ??? JDK-8178676 nsk/jvmti/AttachOnDemand/attach045 fails with Exception ??? https://bugs.openjdk.java.net/browse/JDK-8178676 For the gory details of the reasons for this fix please see Jerry's bugs. Webrev URL: http://cr.openjdk.java.net/~dcubed/8182307-webrev/jdk10-0/ I observed this test failure one time in my Thread-SMR work and have been including this fix in months of Thread-SMR stress testing. It was also included in both JPRT and Mach5 tier[1-5] testing of the Thread-SMR changes. Thanks, in advance, for any comments, suggestions or questions. Dan From daniel.daugherty at oracle.com Thu Dec 7 16:55:57 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 7 Dec 2017 11:55:57 -0500 Subject: RFR(XXS): 8182307 - Error during JRMP connection establishment In-Reply-To: <58075a8f-1732-7b9e-74b1-3e36189f87fd@oracle.com> References: <58075a8f-1732-7b9e-74b1-3e36189f87fd@oracle.com> Message-ID: <0a36c975-8bca-c618-9133-66348f145436@oracle.com> Adding core-libs-dev at ... since this is RMI code. Thanks Alan! Folks, this review spans three OpenJDK aliases so Thunderbird's reply-to-list feature won't get it right. This is one of the few times that reply-to-all is the right thing to do... Dan On 12/7/17 11:38 AM, Daniel D. Daugherty wrote: > Greetings, > > I have a small fix for a very intermittent ServerSocket related test > failure: > > ??? JDK-8182307: Error during JRMP connection establishment > ??? https://bugs.openjdk.java.net/browse/JDK-8182307 > > The fix is copied from Jerry's work on the following bugs: > > ??? JDK-8182757 JDWP: Socket Transport handshake hangs on Solaris > ??? https://bugs.openjdk.java.net/browse/JDK-8182757 > > ??? JDK-8178676 nsk/jvmti/AttachOnDemand/attach045 fails with Exception > ??? https://bugs.openjdk.java.net/browse/JDK-8178676 > > For the gory details of the reasons for this fix please see > Jerry's bugs. > > Webrev URL: http://cr.openjdk.java.net/~dcubed/8182307-webrev/jdk10-0/ > > > I observed this test failure one time in my Thread-SMR work and have > been including this fix in months of Thread-SMR stress testing. It was > also included in both JPRT and Mach5 tier[1-5] testing of the Thread-SMR > changes. > > Thanks, in advance, for any comments, suggestions or questions. > > Dan > From gerald.thornbrugh at oracle.com Thu Dec 7 17:00:43 2017 From: gerald.thornbrugh at oracle.com (Gerald Thornbrugh) Date: Thu, 7 Dec 2017 10:00:43 -0700 Subject: RFR(XXS): 8182307 - Error during JRMP connection establishment In-Reply-To: <0a36c975-8bca-c618-9133-66348f145436@oracle.com> References: <58075a8f-1732-7b9e-74b1-3e36189f87fd@oracle.com> <0a36c975-8bca-c618-9133-66348f145436@oracle.com> Message-ID: Hi Dan, Your fix looks good. Jerry > Adding core-libs-dev at ... since this is RMI code. Thanks Alan! > > Folks, this review spans three OpenJDK aliases so Thunderbird's > reply-to-list feature won't get it right. This is one of the > few times that reply-to-all is the right thing to do... > > Dan > > On 12/7/17 11:38 AM, Daniel D. Daugherty wrote: >> Greetings, >> >> I have a small fix for a very intermittent ServerSocket related test >> failure: >> >> ??? JDK-8182307: Error during JRMP connection establishment >> ??? https://bugs.openjdk.java.net/browse/JDK-8182307 >> >> The fix is copied from Jerry's work on the following bugs: >> >> ??? JDK-8182757 JDWP: Socket Transport handshake hangs on Solaris >> ??? https://bugs.openjdk.java.net/browse/JDK-8182757 >> >> ??? JDK-8178676 nsk/jvmti/AttachOnDemand/attach045 fails with Exception >> ??? https://bugs.openjdk.java.net/browse/JDK-8178676 >> >> For the gory details of the reasons for this fix please see >> Jerry's bugs. >> >> Webrev URL: http://cr.openjdk.java.net/~dcubed/8182307-webrev/jdk10-0/ >> >> >> I observed this test failure one time in my Thread-SMR work and have >> been including this fix in months of Thread-SMR stress testing. It was >> also included in both JPRT and Mach5 tier[1-5] testing of the Thread-SMR >> changes. >> >> Thanks, in advance, for any comments, suggestions or questions. >> >> Dan >> > From daniel.daugherty at oracle.com Thu Dec 7 17:05:52 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 7 Dec 2017 12:05:52 -0500 Subject: RFR(XXS): 8182307 - Error during JRMP connection establishment In-Reply-To: References: <58075a8f-1732-7b9e-74b1-3e36189f87fd@oracle.com> <0a36c975-8bca-c618-9133-66348f145436@oracle.com> Message-ID: <3c719cde-b764-5582-67c9-33ff7cf95661@oracle.com> Jerry, Thanks for the review! Dan On 12/7/17 12:00 PM, Gerald Thornbrugh wrote: > Hi Dan, > > Your fix looks good. > > Jerry > >> Adding core-libs-dev at ... since this is RMI code. Thanks Alan! >> >> Folks, this review spans three OpenJDK aliases so Thunderbird's >> reply-to-list feature won't get it right. This is one of the >> few times that reply-to-all is the right thing to do... >> >> Dan >> >> On 12/7/17 11:38 AM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I have a small fix for a very intermittent ServerSocket related test >>> failure: >>> >>> ??? JDK-8182307: Error during JRMP connection establishment >>> ??? https://bugs.openjdk.java.net/browse/JDK-8182307 >>> >>> The fix is copied from Jerry's work on the following bugs: >>> >>> ??? JDK-8182757 JDWP: Socket Transport handshake hangs on Solaris >>> ??? https://bugs.openjdk.java.net/browse/JDK-8182757 >>> >>> ??? JDK-8178676 nsk/jvmti/AttachOnDemand/attach045 fails with Exception >>> ??? https://bugs.openjdk.java.net/browse/JDK-8178676 >>> >>> For the gory details of the reasons for this fix please see >>> Jerry's bugs. >>> >>> Webrev URL: http://cr.openjdk.java.net/~dcubed/8182307-webrev/jdk10-0/ >>> >>> >>> I observed this test failure one time in my Thread-SMR work and have >>> been including this fix in months of Thread-SMR stress testing. It was >>> also included in both JPRT and Mach5 tier[1-5] testing of the >>> Thread-SMR >>> changes. >>> >>> Thanks, in advance, for any comments, suggestions or questions. >>> >>> Dan >>> >> > From Roger.Riggs at Oracle.com Thu Dec 7 17:07:13 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 7 Dec 2017 12:07:13 -0500 Subject: RFR(XXS): 8182307 - Error during JRMP connection establishment In-Reply-To: References: <58075a8f-1732-7b9e-74b1-3e36189f87fd@oracle.com> <0a36c975-8bca-c618-9133-66348f145436@oracle.com> Message-ID: +1 On 12/7/2017 12:00 PM, Gerald Thornbrugh wrote: > Hi Dan, > > Your fix looks good. > > Jerry > >> Adding core-libs-dev at ... since this is RMI code. Thanks Alan! >> >> Folks, this review spans three OpenJDK aliases so Thunderbird's >> reply-to-list feature won't get it right. This is one of the >> few times that reply-to-all is the right thing to do... >> >> Dan >> >> On 12/7/17 11:38 AM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I have a small fix for a very intermittent ServerSocket related test >>> failure: >>> >>> ??? JDK-8182307: Error during JRMP connection establishment >>> ??? https://bugs.openjdk.java.net/browse/JDK-8182307 >>> >>> The fix is copied from Jerry's work on the following bugs: >>> >>> ??? JDK-8182757 JDWP: Socket Transport handshake hangs on Solaris >>> ??? https://bugs.openjdk.java.net/browse/JDK-8182757 >>> >>> ??? JDK-8178676 nsk/jvmti/AttachOnDemand/attach045 fails with Exception >>> ??? https://bugs.openjdk.java.net/browse/JDK-8178676 >>> >>> For the gory details of the reasons for this fix please see >>> Jerry's bugs. >>> >>> Webrev URL: http://cr.openjdk.java.net/~dcubed/8182307-webrev/jdk10-0/ >>> >>> >>> I observed this test failure one time in my Thread-SMR work and have >>> been including this fix in months of Thread-SMR stress testing. It was >>> also included in both JPRT and Mach5 tier[1-5] testing of the >>> Thread-SMR >>> changes. >>> >>> Thanks, in advance, for any comments, suggestions or questions. >>> >>> Dan >>> >> > From daniel.daugherty at oracle.com Thu Dec 7 17:09:19 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 7 Dec 2017 12:09:19 -0500 Subject: RFR(XXS): 8182307 - Error during JRMP connection establishment In-Reply-To: References: <58075a8f-1732-7b9e-74b1-3e36189f87fd@oracle.com> <0a36c975-8bca-c618-9133-66348f145436@oracle.com> Message-ID: <35163e84-b100-1b85-3179-a58699163fc5@oracle.com> Roger, Thanks for the review! Dan P.S. I'm planning to push this fix to jdk/hs since the only sightings have been in jdk/hs testing or in projects that are parented to jdk/hs repos... Hope that's okay... On 12/7/17 12:07 PM, Roger Riggs wrote: > +1 > > On 12/7/2017 12:00 PM, Gerald Thornbrugh wrote: >> Hi Dan, >> >> Your fix looks good. >> >> Jerry >> >>> Adding core-libs-dev at ... since this is RMI code. Thanks Alan! >>> >>> Folks, this review spans three OpenJDK aliases so Thunderbird's >>> reply-to-list feature won't get it right. This is one of the >>> few times that reply-to-all is the right thing to do... >>> >>> Dan >>> >>> On 12/7/17 11:38 AM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> I have a small fix for a very intermittent ServerSocket related test >>>> failure: >>>> >>>> ??? JDK-8182307: Error during JRMP connection establishment >>>> https://bugs.openjdk.java.net/browse/JDK-8182307 >>>> >>>> The fix is copied from Jerry's work on the following bugs: >>>> >>>> ??? JDK-8182757 JDWP: Socket Transport handshake hangs on Solaris >>>> https://bugs.openjdk.java.net/browse/JDK-8182757 >>>> >>>> ??? JDK-8178676 nsk/jvmti/AttachOnDemand/attach045 fails with >>>> Exception >>>> https://bugs.openjdk.java.net/browse/JDK-8178676 >>>> >>>> For the gory details of the reasons for this fix please see >>>> Jerry's bugs. >>>> >>>> Webrev URL: http://cr.openjdk.java.net/~dcubed/8182307-webrev/jdk10-0/ >>>> >>>> >>>> I observed this test failure one time in my Thread-SMR work and have >>>> been including this fix in months of Thread-SMR stress testing. It was >>>> also included in both JPRT and Mach5 tier[1-5] testing of the >>>> Thread-SMR >>>> changes. >>>> >>>> Thanks, in advance, for any comments, suggestions or questions. >>>> >>>> Dan >>>> >>> >> > From serguei.spitsyn at oracle.com Thu Dec 7 18:08:07 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 7 Dec 2017 10:08:07 -0800 Subject: RFR(XXS): 8182307 - Error during JRMP connection establishment In-Reply-To: <35163e84-b100-1b85-3179-a58699163fc5@oracle.com> References: <58075a8f-1732-7b9e-74b1-3e36189f87fd@oracle.com> <0a36c975-8bca-c618-9133-66348f145436@oracle.com> <35163e84-b100-1b85-3179-a58699163fc5@oracle.com> Message-ID: Hi Dan, The fix looks good to me. Nice, you have caught it. Do you want this fixed in 10 or 11? I thought that the jdk/hs is for 11 now. Is it correct? Thanks, Serguei On 12/7/17 09:09, Daniel D. Daugherty wrote: > Roger, > > Thanks for the review! > > Dan > > P.S. > I'm planning to push this fix to jdk/hs since the only sightings > have been in jdk/hs testing or in projects that are parented to > jdk/hs repos... Hope that's okay... > > > On 12/7/17 12:07 PM, Roger Riggs wrote: >> +1 >> >> On 12/7/2017 12:00 PM, Gerald Thornbrugh wrote: >>> Hi Dan, >>> >>> Your fix looks good. >>> >>> Jerry >>> >>>> Adding core-libs-dev at ... since this is RMI code. Thanks Alan! >>>> >>>> Folks, this review spans three OpenJDK aliases so Thunderbird's >>>> reply-to-list feature won't get it right. This is one of the >>>> few times that reply-to-all is the right thing to do... >>>> >>>> Dan >>>> >>>> On 12/7/17 11:38 AM, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> I have a small fix for a very intermittent ServerSocket related test >>>>> failure: >>>>> >>>>> ??? JDK-8182307: Error during JRMP connection establishment >>>>> https://bugs.openjdk.java.net/browse/JDK-8182307 >>>>> >>>>> The fix is copied from Jerry's work on the following bugs: >>>>> >>>>> ??? JDK-8182757 JDWP: Socket Transport handshake hangs on Solaris >>>>> https://bugs.openjdk.java.net/browse/JDK-8182757 >>>>> >>>>> ??? JDK-8178676 nsk/jvmti/AttachOnDemand/attach045 fails with >>>>> Exception >>>>> https://bugs.openjdk.java.net/browse/JDK-8178676 >>>>> >>>>> For the gory details of the reasons for this fix please see >>>>> Jerry's bugs. >>>>> >>>>> Webrev URL: >>>>> http://cr.openjdk.java.net/~dcubed/8182307-webrev/jdk10-0/ >>>>> >>>>> >>>>> I observed this test failure one time in my Thread-SMR work and have >>>>> been including this fix in months of Thread-SMR stress testing. It >>>>> was >>>>> also included in both JPRT and Mach5 tier[1-5] testing of the >>>>> Thread-SMR >>>>> changes. >>>>> >>>>> Thanks, in advance, for any comments, suggestions or questions. >>>>> >>>>> Dan >>>>> >>>> >>> >> > From serguei.spitsyn at oracle.com Thu Dec 7 18:36:35 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 7 Dec 2017 10:36:35 -0800 Subject: RFR(XXS): 8182307 - Error during JRMP connection establishment In-Reply-To: References: <58075a8f-1732-7b9e-74b1-3e36189f87fd@oracle.com> <0a36c975-8bca-c618-9133-66348f145436@oracle.com> <35163e84-b100-1b85-3179-a58699163fc5@oracle.com> Message-ID: <968040bb-0923-a930-cab6-fce3e6d718a7@oracle.com> On 12/7/17 10:08, serguei.spitsyn at oracle.com wrote: > Hi Dan, > > The fix looks good to me. > Nice, you have caught it. > > Do you want this fixed in 10 or 11? > I thought that the jdk/hs is for 11 now. > Is it correct? Never mind. I've just found a message from Jesper the jdk/hs is used for 10 pushes for one more week. Thanks, Serguei > > Thanks, > Serguei > > > On 12/7/17 09:09, Daniel D. Daugherty wrote: >> Roger, >> >> Thanks for the review! >> >> Dan >> >> P.S. >> I'm planning to push this fix to jdk/hs since the only sightings >> have been in jdk/hs testing or in projects that are parented to >> jdk/hs repos... Hope that's okay... >> >> >> On 12/7/17 12:07 PM, Roger Riggs wrote: >>> +1 >>> >>> On 12/7/2017 12:00 PM, Gerald Thornbrugh wrote: >>>> Hi Dan, >>>> >>>> Your fix looks good. >>>> >>>> Jerry >>>> >>>>> Adding core-libs-dev at ... since this is RMI code. Thanks Alan! >>>>> >>>>> Folks, this review spans three OpenJDK aliases so Thunderbird's >>>>> reply-to-list feature won't get it right. This is one of the >>>>> few times that reply-to-all is the right thing to do... >>>>> >>>>> Dan >>>>> >>>>> On 12/7/17 11:38 AM, Daniel D. Daugherty wrote: >>>>>> Greetings, >>>>>> >>>>>> I have a small fix for a very intermittent ServerSocket related test >>>>>> failure: >>>>>> >>>>>> ??? JDK-8182307: Error during JRMP connection establishment >>>>>> https://bugs.openjdk.java.net/browse/JDK-8182307 >>>>>> >>>>>> The fix is copied from Jerry's work on the following bugs: >>>>>> >>>>>> ??? JDK-8182757 JDWP: Socket Transport handshake hangs on Solaris >>>>>> https://bugs.openjdk.java.net/browse/JDK-8182757 >>>>>> >>>>>> ??? JDK-8178676 nsk/jvmti/AttachOnDemand/attach045 fails with >>>>>> Exception >>>>>> https://bugs.openjdk.java.net/browse/JDK-8178676 >>>>>> >>>>>> For the gory details of the reasons for this fix please see >>>>>> Jerry's bugs. >>>>>> >>>>>> Webrev URL: >>>>>> http://cr.openjdk.java.net/~dcubed/8182307-webrev/jdk10-0/ >>>>>> >>>>>> >>>>>> I observed this test failure one time in my Thread-SMR work and have >>>>>> been including this fix in months of Thread-SMR stress testing. >>>>>> It was >>>>>> also included in both JPRT and Mach5 tier[1-5] testing of the >>>>>> Thread-SMR >>>>>> changes. >>>>>> >>>>>> Thanks, in advance, for any comments, suggestions or questions. >>>>>> >>>>>> Dan >>>>>> >>>>> >>>> >>> >> > From manc at google.com Thu Dec 7 18:42:58 2017 From: manc at google.com (Man Cao) Date: Thu, 7 Dec 2017 10:42:58 -0800 Subject: Make reserved_size for compressed class space and metaspace respect the ergo-initialized CompressedClassSpaceSize flag value In-Reply-To: References: Message-ID: Hello, This is a friendly ping. Could anyone review or sponsor this change? It's just a two-liner change. -Man On Thu, Nov 30, 2017 at 2:03 PM, Man Cao wrote: > I realized that the email attachment is probably dropped by the mailing > list, so below is the inlined patch. > > --- old/src/hotspot/share/memory/metaspace.cpp 2017-11-29 > 14:56:59.017118444 -0800 > +++ new/src/hotspot/share/memory/metaspace.cpp 2017-11-29 > 14:56:58.657121375 -0800 > @@ -3321,9 +3321,6 @@ > MinMetaspaceExpansion = align_down_bounded(MinMetaspaceExpansion, > _commit_alignment); > MaxMetaspaceExpansion = align_down_bounded(MaxMetaspaceExpansion, > _commit_alignment); > > - CompressedClassSpaceSize = align_down_bounded(CompressedClassSpaceSize, > _reserve_alignment); > - set_compressed_class_space_size(CompressedClassSpaceSize); > - > // Initial virtual space size will be calculated at global_initialize() > size_t min_metaspace_sz = > VIRTUALSPACEMULTIPLIER * InitialBootClassLoaderMetaspaceSize; > @@ -3341,6 +3338,8 @@ > min_metaspace_sz); > } > > + CompressedClassSpaceSize = align_down_bounded(CompressedClassSpaceSize, > _reserve_alignment); > + set_compressed_class_space_size(CompressedClassSpaceSize); > } > > void Metaspace::global_initialize() { > > Best, > Man > > On Wed, Nov 29, 2017 at 3:21 PM, Man Cao wrote: > >> Hello, >> >> This patch is a follow-up fix for https://bugs.openjdk.java. >> net/browse/JDK-8087291 >> >> This patch moves the call to set_compressed_class_space_size() after the >> flag value for CompressedClassSpaceSize is ergo-initialized, fixing the >> issue that the reserved size for compressed class space and metaspace is >> excessively large when MaxMetaspaceSize is set to a small value. More >> discussion about it is available here: >> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2 >> 017-November/025200.html >> >> This code patch is attached. Could anyone review and/or sponsor this >> patch? >> >> Best, >> Man >> > > From daniel.daugherty at oracle.com Thu Dec 7 18:46:27 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 7 Dec 2017 13:46:27 -0500 Subject: RFR(XXS): 8182307 - Error during JRMP connection establishment In-Reply-To: References: <58075a8f-1732-7b9e-74b1-3e36189f87fd@oracle.com> <0a36c975-8bca-c618-9133-66348f145436@oracle.com> <35163e84-b100-1b85-3179-a58699163fc5@oracle.com> Message-ID: On 12/7/17 1:08 PM, serguei.spitsyn at oracle.com wrote: > Hi Dan, > > The fix looks good to me. > Nice, you have caught it. Thanks for the review! > Do you want this fixed in 10 or 11? > I thought that the jdk/hs is for 11 now. > Is it correct? Please see Mark R's e-mail with the subject line of "JDK 10 enters Rampdown Phase One in one week". In short, the RDP1 deadline applies to jdk/jdk, jdk/hs and jdk/client all at the same time. Dan > > Thanks, > Serguei > > > On 12/7/17 09:09, Daniel D. Daugherty wrote: >> Roger, >> >> Thanks for the review! >> >> Dan >> >> P.S. >> I'm planning to push this fix to jdk/hs since the only sightings >> have been in jdk/hs testing or in projects that are parented to >> jdk/hs repos... Hope that's okay... >> >> >> On 12/7/17 12:07 PM, Roger Riggs wrote: >>> +1 >>> >>> On 12/7/2017 12:00 PM, Gerald Thornbrugh wrote: >>>> Hi Dan, >>>> >>>> Your fix looks good. >>>> >>>> Jerry >>>> >>>>> Adding core-libs-dev at ... since this is RMI code. Thanks Alan! >>>>> >>>>> Folks, this review spans three OpenJDK aliases so Thunderbird's >>>>> reply-to-list feature won't get it right. This is one of the >>>>> few times that reply-to-all is the right thing to do... >>>>> >>>>> Dan >>>>> >>>>> On 12/7/17 11:38 AM, Daniel D. Daugherty wrote: >>>>>> Greetings, >>>>>> >>>>>> I have a small fix for a very intermittent ServerSocket related test >>>>>> failure: >>>>>> >>>>>> ??? JDK-8182307: Error during JRMP connection establishment >>>>>> https://bugs.openjdk.java.net/browse/JDK-8182307 >>>>>> >>>>>> The fix is copied from Jerry's work on the following bugs: >>>>>> >>>>>> ??? JDK-8182757 JDWP: Socket Transport handshake hangs on Solaris >>>>>> https://bugs.openjdk.java.net/browse/JDK-8182757 >>>>>> >>>>>> ??? JDK-8178676 nsk/jvmti/AttachOnDemand/attach045 fails with >>>>>> Exception >>>>>> https://bugs.openjdk.java.net/browse/JDK-8178676 >>>>>> >>>>>> For the gory details of the reasons for this fix please see >>>>>> Jerry's bugs. >>>>>> >>>>>> Webrev URL: >>>>>> http://cr.openjdk.java.net/~dcubed/8182307-webrev/jdk10-0/ >>>>>> >>>>>> >>>>>> I observed this test failure one time in my Thread-SMR work and have >>>>>> been including this fix in months of Thread-SMR stress testing. >>>>>> It was >>>>>> also included in both JPRT and Mach5 tier[1-5] testing of the >>>>>> Thread-SMR >>>>>> changes. >>>>>> >>>>>> Thanks, in advance, for any comments, suggestions or questions. >>>>>> >>>>>> Dan >>>>>> >>>>> >>>> >>> >> > From calvin.cheung at oracle.com Thu Dec 7 23:35:35 2017 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Thu, 07 Dec 2017 15:35:35 -0800 Subject: [10] RFR(S): 8192989: runtime/appcds/javaldr/ArrayTest.java crashes with assert(k->is_instance_klass()) Message-ID: <5A29D047.5050800@oracle.com> bug: https://bugs.openjdk.java.net/browse/JDK-8192989 For JDK10, we're going for a simple and safe fix by not processing array classes found in a class list during CDS dump time. We'll revisit the dumping of array classes in JDK11. webrev: http://cr.openjdk.java.net/~ccheung/8192989/webrev.00/ Testing: hs-tier1, hs-tier2 on 64-bit platforms (linux, macosx, windows, sparc). thanks, Calvin From ioi.lam at oracle.com Fri Dec 8 00:07:23 2017 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 7 Dec 2017 16:07:23 -0800 Subject: [10] RFR(S): 8192989: runtime/appcds/javaldr/ArrayTest.java crashes with assert(k->is_instance_klass()) In-Reply-To: <5A29D047.5050800@oracle.com> References: <5A29D047.5050800@oracle.com> Message-ID: <38cc8ee7-9f50-83f0-2ab7-8499faf7ba20@oracle.com> Looks good. Thanks! - Ioi On 12/7/17 3:35 PM, Calvin Cheung wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8192989 > > For JDK10, we're going for a simple and safe fix by not processing > array classes found in a class list during CDS dump time. > We'll revisit the dumping of array classes in JDK11. > > webrev: http://cr.openjdk.java.net/~ccheung/8192989/webrev.00/ > > Testing: > ??? hs-tier1, hs-tier2 on 64-bit platforms (linux, macosx, windows, > sparc). > > thanks, > Calvin > > From calvin.cheung at oracle.com Fri Dec 8 00:37:34 2017 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Thu, 07 Dec 2017 16:37:34 -0800 Subject: [10] RFR(S): 8192989: runtime/appcds/javaldr/ArrayTest.java crashes with assert(k->is_instance_klass()) In-Reply-To: <38cc8ee7-9f50-83f0-2ab7-8499faf7ba20@oracle.com> References: <5A29D047.5050800@oracle.com> <38cc8ee7-9f50-83f0-2ab7-8499faf7ba20@oracle.com> Message-ID: <5A29DECE.30002@oracle.com> Hi Ioi, Thanks for your quick review. I've file the following bug for JDK11: https://bugs.openjdk.java.net/browse/JDK-8193226 thanks, Calvin On 12/7/17, 4:07 PM, Ioi Lam wrote: > Looks good. Thanks! > > - Ioi > > > On 12/7/17 3:35 PM, Calvin Cheung wrote: >> bug: https://bugs.openjdk.java.net/browse/JDK-8192989 >> >> For JDK10, we're going for a simple and safe fix by not processing >> array classes found in a class list during CDS dump time. >> We'll revisit the dumping of array classes in JDK11. >> >> webrev: http://cr.openjdk.java.net/~ccheung/8192989/webrev.00/ >> >> Testing: >> hs-tier1, hs-tier2 on 64-bit platforms (linux, macosx, windows, >> sparc). >> >> thanks, >> Calvin >> >> > From jiangli.zhou at oracle.com Fri Dec 8 00:39:00 2017 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Thu, 7 Dec 2017 16:39:00 -0800 Subject: [10] RFR(S): 8192989: runtime/appcds/javaldr/ArrayTest.java crashes with assert(k->is_instance_klass()) In-Reply-To: <5A29D047.5050800@oracle.com> References: <5A29D047.5050800@oracle.com> Message-ID: Hi Calvin, The short-term fix looks good. For the test, please add a few multi-dimensional arrays in ArrayTest.arrayClasses[]. I want to make sure they are also identified if present in the class list. We need to test multi-dimensional arrays as well when we add proper handling for array classes. For example: [[[B [[[[[Ljava/lang/Object; Thanks, Jiangli > On Dec 7, 2017, at 3:35 PM, Calvin Cheung wrote: > > bug: https://bugs.openjdk.java.net/browse/JDK-8192989 > > For JDK10, we're going for a simple and safe fix by not processing array classes found in a class list during CDS dump time. > We'll revisit the dumping of array classes in JDK11. > > webrev: http://cr.openjdk.java.net/~ccheung/8192989/webrev.00/ > > Testing: > hs-tier1, hs-tier2 on 64-bit platforms (linux, macosx, windows, sparc). > > thanks, > Calvin > > From daniel.daugherty at oracle.com Fri Dec 8 00:45:32 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 7 Dec 2017 19:45:32 -0500 Subject: RFR(XXS): 8182307 - Error during JRMP connection establishment In-Reply-To: <58075a8f-1732-7b9e-74b1-3e36189f87fd@oracle.com> References: <58075a8f-1732-7b9e-74b1-3e36189f87fd@oracle.com> Message-ID: <5f349300-a8a6-1df5-fb8e-11be4b8b625b@oracle.com> Greetings, My fix for the following bug: ??? JDK-8182307: Error during JRMP connection establishment ??? https://bugs.openjdk.java.net/browse/JDK-8182307 broke two hs-tier3 tests. I'm backing out the fix via: ??? JDK-8193225 [BACKOUT] fix for 8182307 Error during JRMP connection establishment ??? https://bugs.openjdk.java.net/browse/JDK-8193225 Here's the webrev: ??? http://cr.openjdk.java.net/~dcubed/8193225-webrev/jdk10-0/ This is a simple "hg backout". I need a single (R)eviewer. Thanks! Dan On 12/7/17 11:38 AM, Daniel D. Daugherty wrote: > Greetings, > > I have a small fix for a very intermittent ServerSocket related test > failure: > > ??? JDK-8182307: Error during JRMP connection establishment > ??? https://bugs.openjdk.java.net/browse/JDK-8182307 > > The fix is copied from Jerry's work on the following bugs: > > ??? JDK-8182757 JDWP: Socket Transport handshake hangs on Solaris > ??? https://bugs.openjdk.java.net/browse/JDK-8182757 > > ??? JDK-8178676 nsk/jvmti/AttachOnDemand/attach045 fails with Exception > ??? https://bugs.openjdk.java.net/browse/JDK-8178676 > > For the gory details of the reasons for this fix please see > Jerry's bugs. > > Webrev URL: http://cr.openjdk.java.net/~dcubed/8182307-webrev/jdk10-0/ > > > I observed this test failure one time in my Thread-SMR work and have > been including this fix in months of Thread-SMR stress testing. It was > also included in both JPRT and Mach5 tier[1-5] testing of the Thread-SMR > changes. > > Thanks, in advance, for any comments, suggestions or questions. > > Dan > From daniel.daugherty at oracle.com Fri Dec 8 00:46:29 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 7 Dec 2017 19:46:29 -0500 Subject: URGENT RFR(XXS): 8193225 - [BACKOUT] fix for 8182307 Error during JRMP connection In-Reply-To: <58075a8f-1732-7b9e-74b1-3e36189f87fd@oracle.com> References: <58075a8f-1732-7b9e-74b1-3e36189f87fd@oracle.com> Message-ID: <75b321b3-c844-3ec7-352c-32d2817d67a3@oracle.com> Resending with the correct subject line! Greetings, My fix for the following bug: ??? JDK-8182307: Error during JRMP connection establishment ??? https://bugs.openjdk.java.net/browse/JDK-8182307 broke two hs-tier3 tests. I'm backing out the fix via: ??? JDK-8193225 [BACKOUT] fix for 8182307 Error during JRMP connection establishment ??? https://bugs.openjdk.java.net/browse/JDK-8193225 Here's the webrev: ??? http://cr.openjdk.java.net/~dcubed/8193225-webrev/jdk10-0/ This is a simple "hg backout". I need a single (R)eviewer. Thanks! Dan On 12/7/17 11:38 AM, Daniel D. Daugherty wrote: > Greetings, > > I have a small fix for a very intermittent ServerSocket related test > failure: > > ??? JDK-8182307: Error during JRMP connection establishment > ??? https://bugs.openjdk.java.net/browse/JDK-8182307 > > The fix is copied from Jerry's work on the following bugs: > > ??? JDK-8182757 JDWP: Socket Transport handshake hangs on Solaris > ??? https://bugs.openjdk.java.net/browse/JDK-8182757 > > ??? JDK-8178676 nsk/jvmti/AttachOnDemand/attach045 fails with Exception > ??? https://bugs.openjdk.java.net/browse/JDK-8178676 > > For the gory details of the reasons for this fix please see > Jerry's bugs. > > Webrev URL: http://cr.openjdk.java.net/~dcubed/8182307-webrev/jdk10-0/ > > > I observed this test failure one time in my Thread-SMR work and have > been including this fix in months of Thread-SMR stress testing. It was > also included in both JPRT and Mach5 tier[1-5] testing of the Thread-SMR > changes. > > Thanks, in advance, for any comments, suggestions or questions. > > Dan > From igor.ignatyev at oracle.com Fri Dec 8 00:57:31 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 7 Dec 2017 16:57:31 -0800 Subject: URGENT RFR(XXS): 8193225 - [BACKOUT] fix for 8182307 Error during JRMP connection In-Reply-To: <75b321b3-c844-3ec7-352c-32d2817d67a3@oracle.com> References: <58075a8f-1732-7b9e-74b1-3e36189f87fd@oracle.com> <75b321b3-c844-3ec7-352c-32d2817d67a3@oracle.com> Message-ID: <9A41D422-55E0-4AFE-B7CC-469815E5928C@oracle.com> Reviewed. -- Igor > On Dec 7, 2017, at 4:46 PM, Daniel D. Daugherty wrote: > > Resending with the correct subject line! > > > Greetings, > > My fix for the following bug: > > JDK-8182307: Error during JRMP connection establishment > https://bugs.openjdk.java.net/browse/JDK-8182307 > > broke two hs-tier3 tests. I'm backing out the fix via: > > JDK-8193225 [BACKOUT] fix for 8182307 Error during JRMP connection establishment > https://bugs.openjdk.java.net/browse/JDK-8193225 > > Here's the webrev: > > http://cr.openjdk.java.net/~dcubed/8193225-webrev/jdk10-0/ > > This is a simple "hg backout". I need a single (R)eviewer. Thanks! > > Dan > > > > On 12/7/17 11:38 AM, Daniel D. Daugherty wrote: >> Greetings, >> >> I have a small fix for a very intermittent ServerSocket related test >> failure: >> >> JDK-8182307: Error during JRMP connection establishment >> https://bugs.openjdk.java.net/browse/JDK-8182307 >> >> The fix is copied from Jerry's work on the following bugs: >> >> JDK-8182757 JDWP: Socket Transport handshake hangs on Solaris >> https://bugs.openjdk.java.net/browse/JDK-8182757 >> >> JDK-8178676 nsk/jvmti/AttachOnDemand/attach045 fails with Exception >> https://bugs.openjdk.java.net/browse/JDK-8178676 >> >> For the gory details of the reasons for this fix please see >> Jerry's bugs. >> >> Webrev URL: http://cr.openjdk.java.net/~dcubed/8182307-webrev/jdk10-0/ >> >> >> I observed this test failure one time in my Thread-SMR work and have >> been including this fix in months of Thread-SMR stress testing. It was >> also included in both JPRT and Mach5 tier[1-5] testing of the Thread-SMR >> changes. >> >> Thanks, in advance, for any comments, suggestions or questions. >> >> Dan >> > From daniel.daugherty at oracle.com Fri Dec 8 01:06:11 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 7 Dec 2017 20:06:11 -0500 Subject: URGENT RFR(XXS): 8193225 - [BACKOUT] fix for 8182307 Error during JRMP connection In-Reply-To: <9A41D422-55E0-4AFE-B7CC-469815E5928C@oracle.com> References: <58075a8f-1732-7b9e-74b1-3e36189f87fd@oracle.com> <75b321b3-c844-3ec7-352c-32d2817d67a3@oracle.com> <9A41D422-55E0-4AFE-B7CC-469815E5928C@oracle.com> Message-ID: <2cf54ae8-db16-6c88-ff49-6f4fb82d9064@oracle.com> Thanks Igor! Dan On 12/7/17 7:57 PM, Igor Ignatyev wrote: > Reviewed. > > -- Igor > >> On Dec 7, 2017, at 4:46 PM, Daniel D. Daugherty wrote: >> >> Resending with the correct subject line! >> >> >> Greetings, >> >> My fix for the following bug: >> >> JDK-8182307: Error during JRMP connection establishment >> https://bugs.openjdk.java.net/browse/JDK-8182307 >> >> broke two hs-tier3 tests. I'm backing out the fix via: >> >> JDK-8193225 [BACKOUT] fix for 8182307 Error during JRMP connection establishment >> https://bugs.openjdk.java.net/browse/JDK-8193225 >> >> Here's the webrev: >> >> http://cr.openjdk.java.net/~dcubed/8193225-webrev/jdk10-0/ >> >> This is a simple "hg backout". I need a single (R)eviewer. Thanks! >> >> Dan >> >> >> >> On 12/7/17 11:38 AM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I have a small fix for a very intermittent ServerSocket related test >>> failure: >>> >>> JDK-8182307: Error during JRMP connection establishment >>> https://bugs.openjdk.java.net/browse/JDK-8182307 >>> >>> The fix is copied from Jerry's work on the following bugs: >>> >>> JDK-8182757 JDWP: Socket Transport handshake hangs on Solaris >>> https://bugs.openjdk.java.net/browse/JDK-8182757 >>> >>> JDK-8178676 nsk/jvmti/AttachOnDemand/attach045 fails with Exception >>> https://bugs.openjdk.java.net/browse/JDK-8178676 >>> >>> For the gory details of the reasons for this fix please see >>> Jerry's bugs. >>> >>> Webrev URL: http://cr.openjdk.java.net/~dcubed/8182307-webrev/jdk10-0/ >>> >>> >>> I observed this test failure one time in my Thread-SMR work and have >>> been including this fix in months of Thread-SMR stress testing. It was >>> also included in both JPRT and Mach5 tier[1-5] testing of the Thread-SMR >>> changes. >>> >>> Thanks, in advance, for any comments, suggestions or questions. >>> >>> Dan >>> From serguei.spitsyn at oracle.com Fri Dec 8 01:26:03 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 7 Dec 2017 17:26:03 -0800 Subject: URGENT RFR(XXS): 8193225 - [BACKOUT] fix for 8182307 Error during JRMP connection In-Reply-To: <9A41D422-55E0-4AFE-B7CC-469815E5928C@oracle.com> References: <58075a8f-1732-7b9e-74b1-3e36189f87fd@oracle.com> <75b321b3-c844-3ec7-352c-32d2817d67a3@oracle.com> <9A41D422-55E0-4AFE-B7CC-469815E5928C@oracle.com> Message-ID: +1 Sorry, your fix broke two hs-tier3 tests. I've decided to always run all hs-tier's before any of my integrations. :( Thanks, Serguei On 12/7/17 16:57, Igor Ignatyev wrote: > Reviewed. > > -- Igor > >> On Dec 7, 2017, at 4:46 PM, Daniel D. Daugherty wrote: >> >> Resending with the correct subject line! >> >> >> Greetings, >> >> My fix for the following bug: >> >> JDK-8182307: Error during JRMP connection establishment >> https://bugs.openjdk.java.net/browse/JDK-8182307 >> >> broke two hs-tier3 tests. I'm backing out the fix via: >> >> JDK-8193225 [BACKOUT] fix for 8182307 Error during JRMP connection establishment >> https://bugs.openjdk.java.net/browse/JDK-8193225 >> >> Here's the webrev: >> >> http://cr.openjdk.java.net/~dcubed/8193225-webrev/jdk10-0/ >> >> This is a simple "hg backout". I need a single (R)eviewer. Thanks! >> >> Dan >> >> >> >> On 12/7/17 11:38 AM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I have a small fix for a very intermittent ServerSocket related test >>> failure: >>> >>> JDK-8182307: Error during JRMP connection establishment >>> https://bugs.openjdk.java.net/browse/JDK-8182307 >>> >>> The fix is copied from Jerry's work on the following bugs: >>> >>> JDK-8182757 JDWP: Socket Transport handshake hangs on Solaris >>> https://bugs.openjdk.java.net/browse/JDK-8182757 >>> >>> JDK-8178676 nsk/jvmti/AttachOnDemand/attach045 fails with Exception >>> https://bugs.openjdk.java.net/browse/JDK-8178676 >>> >>> For the gory details of the reasons for this fix please see >>> Jerry's bugs. >>> >>> Webrev URL: http://cr.openjdk.java.net/~dcubed/8182307-webrev/jdk10-0/ >>> >>> >>> I observed this test failure one time in my Thread-SMR work and have >>> been including this fix in months of Thread-SMR stress testing. It was >>> also included in both JPRT and Mach5 tier[1-5] testing of the Thread-SMR >>> changes. >>> >>> Thanks, in advance, for any comments, suggestions or questions. >>> >>> Dan >>> From daniel.daugherty at oracle.com Fri Dec 8 01:31:26 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 7 Dec 2017 20:31:26 -0500 Subject: URGENT RFR(XXS): 8193225 - [BACKOUT] fix for 8182307 Error during JRMP connection In-Reply-To: References: <58075a8f-1732-7b9e-74b1-3e36189f87fd@oracle.com> <75b321b3-c844-3ec7-352c-32d2817d67a3@oracle.com> <9A41D422-55E0-4AFE-B7CC-469815E5928C@oracle.com> Message-ID: On 12/7/17 8:26 PM, serguei.spitsyn at oracle.com wrote: > +1 > > Sorry, your fix broke two hs-tier3 tests. Me too! > I've decided to always run all hs-tier's before any of my > integrations. :( My last test run with the fix for 8182307 by itself was a Mach5 tier[1-5] job on 11.22... There were no RMI test failures... I cannot explain what happened (yet)... Dan > > Thanks, > Serguei > > > On 12/7/17 16:57, Igor Ignatyev wrote: >> Reviewed. >> >> -- Igor >> >>> On Dec 7, 2017, at 4:46 PM, Daniel D. Daugherty >>> wrote: >>> >>> Resending with the correct subject line! >>> >>> >>> Greetings, >>> >>> My fix for the following bug: >>> >>> ???? JDK-8182307: Error during JRMP connection establishment >>> ???? https://bugs.openjdk.java.net/browse/JDK-8182307 >>> >>> broke two hs-tier3 tests. I'm backing out the fix via: >>> >>> ???? JDK-8193225 [BACKOUT] fix for 8182307 Error during JRMP >>> connection establishment >>> ???? https://bugs.openjdk.java.net/browse/JDK-8193225 >>> >>> Here's the webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8193225-webrev/jdk10-0/ >>> >>> This is a simple "hg backout". I need a single (R)eviewer. Thanks! >>> >>> Dan >>> >>> >>> >>> On 12/7/17 11:38 AM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> I have a small fix for a very intermittent ServerSocket related test >>>> failure: >>>> >>>> ???? JDK-8182307: Error during JRMP connection establishment >>>> ???? https://bugs.openjdk.java.net/browse/JDK-8182307 >>>> >>>> The fix is copied from Jerry's work on the following bugs: >>>> >>>> ???? JDK-8182757 JDWP: Socket Transport handshake hangs on Solaris >>>> ???? https://bugs.openjdk.java.net/browse/JDK-8182757 >>>> >>>> ???? JDK-8178676 nsk/jvmti/AttachOnDemand/attach045 fails with >>>> Exception >>>> ???? https://bugs.openjdk.java.net/browse/JDK-8178676 >>>> >>>> For the gory details of the reasons for this fix please see >>>> Jerry's bugs. >>>> >>>> Webrev URL: http://cr.openjdk.java.net/~dcubed/8182307-webrev/jdk10-0/ >>>> >>>> >>>> I observed this test failure one time in my Thread-SMR work and have >>>> been including this fix in months of Thread-SMR stress testing. It was >>>> also included in both JPRT and Mach5 tier[1-5] testing of the >>>> Thread-SMR >>>> changes. >>>> >>>> Thanks, in advance, for any comments, suggestions or questions. >>>> >>>> Dan >>>> > From calvin.cheung at oracle.com Fri Dec 8 01:59:22 2017 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Thu, 07 Dec 2017 17:59:22 -0800 Subject: [10] RFR(S): 8192989: runtime/appcds/javaldr/ArrayTest.java crashes with assert(k->is_instance_klass()) In-Reply-To: References: <5A29D047.5050800@oracle.com> Message-ID: <5A29F1FA.9090504@oracle.com> Hi Jiangli, I've added two multidimensional arrays to the test case. updated webrev: http://cr.openjdk.java.net/~ccheung/8192989/webrev.01/ thanks, Calvin On 12/7/17, 4:39 PM, Jiangli Zhou wrote: > Hi Calvin, > > The short-term fix looks good. For the test, please add a few multi-dimensional arrays in ArrayTest.arrayClasses[]. I want to make sure they are also identified if present in the class list. We need to test multi-dimensional arrays as well when we add proper handling for array classes. > > For example: > [[[B > [[[[[Ljava/lang/Object; > > Thanks, > Jiangli > >> On Dec 7, 2017, at 3:35 PM, Calvin Cheung wrote: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8192989 >> >> For JDK10, we're going for a simple and safe fix by not processing array classes found in a class list during CDS dump time. >> We'll revisit the dumping of array classes in JDK11. >> >> webrev: http://cr.openjdk.java.net/~ccheung/8192989/webrev.00/ >> >> Testing: >> hs-tier1, hs-tier2 on 64-bit platforms (linux, macosx, windows, sparc). >> >> thanks, >> Calvin >> >> From david.holmes at oracle.com Fri Dec 8 03:37:21 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 8 Dec 2017 13:37:21 +1000 Subject: RFR (M) 8186903: Remove j-types from Atomic In-Reply-To: References: <11698d07-aee7-0123-4edb-ed3d57317b87@oracle.com> <4a4bc91d-f63f-4160-d4a0-74d015dd58af@oracle.com> <65c8cf7b-e3ba-17e5-89ec-4760ffd5884f@oracle.com> Message-ID: On 8/12/2017 1:28 AM, coleen.phillimore at oracle.com wrote: > On 12/7/17 8:11 AM, coleen.phillimore at oracle.com wrote: >> >> >> On 12/6/17 11:33 PM, David Holmes wrote: >>> On 7/12/2017 2:00 PM, coleen.phillimore at oracle.com wrote: >>>> On 12/6/17 9:41 PM, David Holmes wrote: >>>>> Hi Coleen, >>>>> >>>>> On 7/12/2017 7:59 AM, coleen.phillimore at oracle.com wrote: >>>>>> Summary: Change parameter types from jlong, jint, jbyte to >>>>>> int64_t, int32_t and int8_t respectively >>>>> >>>>> That's fine. But you also made a bunch of changes to rename the >>>>> "ptr" variants to "long", and in the process changed intptr_t to >>>>> int64_t. The change ptr->long isn't really accurate. And intptr_t >>>>> and int64_t are different sizes on 32-bit! So this change seems >>>>> problematic and out of scope by your own description. That said I >>>>> thought we had/were getting rid of the "ptr" variants ?? >>>> >>>> Yes, I did rename atomic_add_ptr_entry to atomic_add_long_entry. >>>> This is to match the other names which are currently empty, "long" >>>> and "byte". This was a last vestige of the ptr variants.?? It's only >>>> used on 64 bit windows, so changing it to intptr_t to int64_t is >>>> correct. For some reason, there isn't a long variant on 32 bits. >>>> Possibly because we don't add jlong values in the vm? >>> >>> Okay. Was hard to see this was all on 64-bit only. >>> >>> Though not clear why this renaming needs to happen at all at this >>> time? I'm finding it very confusing trying to see where we are going >>> with this - shouldn't all the ptr variants become unused with the new >>> Atomic API? I find them easier to spot when written as _ptr_ rather >>> than _long_. (And on Windows a long isn't 64-bits anyway!) >> >> Yes, all the ptrs variants were removed in a previous change but I'd >> missed this renaming this one to long.? Since I was fixing the >> arguments for this function, I took the opportunity to also change the >> name in the same line.? I could file a new RFE for this and separate >> out the few lines.? The _long_ matches the other function names, and >> this case is actually used on _long_ because by this point the >> pointers have been normalized by template magic to long when they get >> here.?? See the other related functions in this change: > > Sorry, I meant _long_ matches other function names and this case is > actually used on int64_t because the pointers have been normalized to 8 > byte int64_t, not _long_ because _long_ is 32 bits on windows.?? So much > confuse. Thanks for clarifying that. :) No further comments from me. I hope all these "long" variants can disappear in the near future. Along with stub generator use in Atomic :) Thanks, David > thanks, > Coleen > >> >> http://cr.openjdk.java.net/~coleenp/8186903.01/webrev/src/hotspot/os_cpu/windows_x86/os_windows_x86.hpp.udiff.html >> >>> >>>> ent >>>> So this renaming makes it consistent with the other names, which >>>> then can all be changed at once, when nice names are agreed upon. >>>>> >>>>>> Leave renaming functions for later change. >>>>>> >>>>>> Ran JPRT which builds more Oracle platforms, mach5 tier1-5 on >>>>>> windows/linux x64 and tier1 on solaris-sparcv9.? Also built Zero >>>>>> product mode (fails building fastdebug for some other reason). >>>>>> >>>>>> Other platforms: could you please test this patch? >>>>>> >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8186903.01/webrev >>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8186903 >>>>>> >>>>>> This change is for JDK 11. >>>>> >>>>> src/hotspot/cpu/x86/stubGenerator_x86_32.cpp >>>>> >>>>> Return type should be int32_t not int >>>>> >>>>> src/hotspot/os_cpu/windows_x86/os_windows_x86.hpp >>>>> >>>>> -? static intptr_t? (*atomic_xchg_long_func)???? (jlong, volatile >>>>> jlong*); >>>>> -? static intptr_t? atomic_xchg_long_bootstrap?? (jlong, volatile >>>>> jlong*); >>>>> >>>>> Wow - that looks like a bug! Only returns 32-bits on 32-bit! >>>> >>>> This one also is only used on 64 bit.? I have to confess I don't >>>> follow all the paths of the atomics and their various translations >>>> down to the platform levels.?? I'm not sure how windows 32 bit calls >>>> atomic_add or xchg for 64 bit values (or if it is not implemented). >>> >>> Not implemented at the lowest levels AFAICS - only load/store and >>> cmpxchg<8>. Of course the other atomics can then be written at a >>> higher-level in terms of cmpxchg. >>> >>> The whole use of the stubgenerator for atomics is something that >>> needs re-examining as I think it is completely unnecessary today (and >>> likely for quite some time). The opening comment in >>> atomic_windows_x86.hpp is somewhat startling as we approach 2018 :) >> >> I asked about this in the review and Erik said they were needed for >> some reason, but it would be nice to have these cleaned up somehow. >> Kim has some ideas for simplifying the implementation. My script to >> find all these names goes something like this: >> >> foreach atomic (cmpxchg xchg add load store) >> ... >> ?? ? foreach type (entry func bootstrap) >> ... >> ????????? foreach ("" "long" "byte") >> ... >> >>> >>> // The following alternative implementations are needed because >>> // Windows 95 doesn't support (some of) the corresponding Windows NT >>> // calls. Furthermore, these versions allow inlining in the caller. >>> // (More precisely: The documentation for InterlockedExchange says >>> // it is supported for Windows 95. However, when single-stepping >>> // through the assembly code we cannot step into the routine and >>> // when looking at the routine address we see only garbage code. >>> // Better safe then sorry!). Was bug 7/31/98 (gri). >> >> Yeah, good thing we can single step on Windows 95! >> >> Thanks, >> Coleen >> >>> >>> Cheers, >>> David >>> >>>>> >>>>> Everything else seems fine. >>>>> >>>> >>>> Thanks for the eagle eye review. >>>> Coleen >>>>> Thanks, >>>>> David >>>>> >>>>>> Thanks, >>>>>> Coleen >>>> >> > From yasuenag at gmail.com Fri Dec 8 05:44:45 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Fri, 8 Dec 2017 14:44:45 +0900 Subject: Make reserved_size for compressed class space and metaspace respect the ergo-initialized CompressedClassSpaceSize flag value In-Reply-To: References: Message-ID: Hi Man, CompressedClassSpaceSize might be modified by FLAG_SET_ERGO. So I think you need to move set_compressed_class_space_size() only. Thanks, Yasumasa 2017-12-08 3:42 GMT+09:00 Man Cao : > Hello, > > This is a friendly ping. Could anyone review or sponsor this change? It's > just a two-liner change. > > -Man > > On Thu, Nov 30, 2017 at 2:03 PM, Man Cao wrote: >> >> I realized that the email attachment is probably dropped by the mailing >> list, so below is the inlined patch. >> >> --- old/src/hotspot/share/memory/metaspace.cpp 2017-11-29 >> 14:56:59.017118444 -0800 >> +++ new/src/hotspot/share/memory/metaspace.cpp 2017-11-29 >> 14:56:58.657121375 -0800 >> @@ -3321,9 +3321,6 @@ >> MinMetaspaceExpansion = align_down_bounded(MinMetaspaceExpansion, >> _commit_alignment); >> MaxMetaspaceExpansion = align_down_bounded(MaxMetaspaceExpansion, >> _commit_alignment); >> >> - CompressedClassSpaceSize = align_down_bounded(CompressedClassSpaceSize, >> _reserve_alignment); >> - set_compressed_class_space_size(CompressedClassSpaceSize); >> - >> // Initial virtual space size will be calculated at global_initialize() >> size_t min_metaspace_sz = >> VIRTUALSPACEMULTIPLIER * InitialBootClassLoaderMetaspaceSize; >> @@ -3341,6 +3338,8 @@ >> min_metaspace_sz); >> } >> >> + CompressedClassSpaceSize = align_down_bounded(CompressedClassSpaceSize, >> _reserve_alignment); >> + set_compressed_class_space_size(CompressedClassSpaceSize); >> } >> >> void Metaspace::global_initialize() { >> >> Best, >> Man >> >> On Wed, Nov 29, 2017 at 3:21 PM, Man Cao wrote: >>> >>> Hello, >>> >>> This patch is a follow-up fix for >>> https://bugs.openjdk.java.net/browse/JDK-8087291 >>> >>> This patch moves the call to set_compressed_class_space_size() after the >>> flag value for CompressedClassSpaceSize is ergo-initialized, fixing the >>> issue that the reserved size for compressed class space and metaspace is >>> excessively large when MaxMetaspaceSize is set to a small value. More >>> discussion about it is available here: >>> >>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-November/025200.html >>> >>> This code patch is attached. Could anyone review and/or sponsor this >>> patch? >>> >>> Best, >>> Man >> >> > From Alan.Bateman at oracle.com Fri Dec 8 09:28:01 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 8 Dec 2017 09:28:01 +0000 Subject: RFR(XXS): 8182307 - Error during JRMP connection establishment In-Reply-To: <0a36c975-8bca-c618-9133-66348f145436@oracle.com> References: <58075a8f-1732-7b9e-74b1-3e36189f87fd@oracle.com> <0a36c975-8bca-c618-9133-66348f145436@oracle.com> Message-ID: <6cadd346-f826-55ce-0276-cfd2f7bef7f4@oracle.com> On 07/12/2017 16:55, Daniel D. Daugherty wrote: > : >> Greetings, >> >> I have a small fix for a very intermittent ServerSocket related test >> failure: >> >> ??? JDK-8182307: Error during JRMP connection establishment >> ??? https://bugs.openjdk.java.net/browse/JDK-8182307 >> >> : >> >> For the gory details of the reasons for this fix please see >> Jerry's bugs. >> >> Webrev URL: http://cr.openjdk.java.net/~dcubed/8182307-webrev/jdk10-0/ >> It's not clear to me how this change solves the issue.? It's a "read timeout" so this means the connection has been established. The client will not care if the server has enabled SO_REUSEADDR or whether it initially bound to a fixed or ephemeral port. Is this issue Solaris only? I ask because there is an awkward issue on Solaris where the kernel will accept a pending connection when the process is at its file descriptor limit. We've seen this periodically, esp. with tests that leave connections or files open. An unsuspecting tests runs later, establishes a connection but gets timeouts as there isn't no code at the application level has accepted the connection. -Alan From adinn at redhat.com Fri Dec 8 11:52:28 2017 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 8 Dec 2017 11:52:28 +0000 Subject: RFR (M) 8186903: Remove j-types from Atomic In-Reply-To: References: Message-ID: <301ab272-399d-3f42-ee2f-15b3790e320c@redhat.com> On 06/12/17 21:59, coleen.phillimore at oracle.com wrote: > Other platforms: could you please test this patch? This built fine on AArch64 and successfully passed basic smoke tests (runs javac and netbeans, passes jtreg tests for j.u.c). I am currently running jcstress tests just to be sure. If you want to wait on the result of that I will let you know the result when they finish (all is ok so far but there is still a long way to go). regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From coleen.phillimore at oracle.com Fri Dec 8 12:36:55 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 8 Dec 2017 07:36:55 -0500 Subject: RFR (M) 8186903: Remove j-types from Atomic In-Reply-To: <301ab272-399d-3f42-ee2f-15b3790e320c@redhat.com> References: <301ab272-399d-3f42-ee2f-15b3790e320c@redhat.com> Message-ID: On 12/8/17 6:52 AM, Andrew Dinn wrote: > On 06/12/17 21:59, coleen.phillimore at oracle.com wrote: >> Other platforms: could you please test this patch? > This built fine on AArch64 and successfully passed basic smoke tests > (runs javac and netbeans, passes jtreg tests for j.u.c). > > I am currently running jcstress tests just to be sure. If you want to > wait on the result of that I will let you know the result when they > finish (all is ok so far but there is still a long way to go). Hi Andrew,? Did you also review the change? There's no rush because this is waiting for JDK 11 to open up. thanks! Coleen > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From coleen.phillimore at oracle.com Fri Dec 8 12:38:45 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 8 Dec 2017 07:38:45 -0500 Subject: RFR (M) 8186903: Remove j-types from Atomic In-Reply-To: References: <11698d07-aee7-0123-4edb-ed3d57317b87@oracle.com> <4a4bc91d-f63f-4160-d4a0-74d015dd58af@oracle.com> <65c8cf7b-e3ba-17e5-89ec-4760ffd5884f@oracle.com> Message-ID: <631b5ff2-53da-7055-c978-cfa0a4a1ef70@oracle.com> Thank you, David. On 12/7/17 10:37 PM, David Holmes wrote: > On 8/12/2017 1:28 AM, coleen.phillimore at oracle.com wrote: >> On 12/7/17 8:11 AM, coleen.phillimore at oracle.com wrote: >>> >>> >>> On 12/6/17 11:33 PM, David Holmes wrote: >>>> On 7/12/2017 2:00 PM, coleen.phillimore at oracle.com wrote: >>>>> On 12/6/17 9:41 PM, David Holmes wrote: >>>>>> Hi Coleen, >>>>>> >>>>>> On 7/12/2017 7:59 AM, coleen.phillimore at oracle.com wrote: >>>>>>> Summary: Change parameter types from jlong, jint, jbyte to >>>>>>> int64_t, int32_t and int8_t respectively >>>>>> >>>>>> That's fine. But you also made a bunch of changes to rename the >>>>>> "ptr" variants to "long", and in the process changed intptr_t to >>>>>> int64_t. The change ptr->long isn't really accurate. And intptr_t >>>>>> and int64_t are different sizes on 32-bit! So this change seems >>>>>> problematic and out of scope by your own description. That said I >>>>>> thought we had/were getting rid of the "ptr" variants ?? >>>>> >>>>> Yes, I did rename atomic_add_ptr_entry to atomic_add_long_entry. >>>>> This is to match the other names which are currently empty, "long" >>>>> and "byte". This was a last vestige of the ptr variants.?? It's >>>>> only used on 64 bit windows, so changing it to intptr_t to int64_t >>>>> is correct. For some reason, there isn't a long variant on 32 >>>>> bits. Possibly because we don't add jlong values in the vm? >>>> >>>> Okay. Was hard to see this was all on 64-bit only. >>>> >>>> Though not clear why this renaming needs to happen at all at this >>>> time? I'm finding it very confusing trying to see where we are >>>> going with this - shouldn't all the ptr variants become unused with >>>> the new Atomic API? I find them easier to spot when written as >>>> _ptr_ rather than _long_. (And on Windows a long isn't 64-bits >>>> anyway!) >>> >>> Yes, all the ptrs variants were removed in a previous change but I'd >>> missed this renaming this one to long.? Since I was fixing the >>> arguments for this function, I took the opportunity to also change >>> the name in the same line.? I could file a new RFE for this and >>> separate out the few lines.? The _long_ matches the other function >>> names, and this case is actually used on _long_ because by this >>> point the pointers have been normalized by template magic to long >>> when they get here.?? See the other related functions in this change: >> >> Sorry, I meant _long_ matches other function names and this case is >> actually used on int64_t because the pointers have been normalized to >> 8 byte int64_t, not _long_ because _long_ is 32 bits on windows.?? So >> much confuse. > > Thanks for clarifying that. :) > > No further comments from me. I hope all these "long" variants can > disappear in the near future. Along with stub generator use in Atomic :) Me too, but I think some of this old code is in platforms Oracle doesn't support so may not have priority for clean up vs. removal. thanks, Coleen > > Thanks, > David > >> thanks, >> Coleen >> >>> >>> http://cr.openjdk.java.net/~coleenp/8186903.01/webrev/src/hotspot/os_cpu/windows_x86/os_windows_x86.hpp.udiff.html >>> >>>> >>>>> ent >>>>> So this renaming makes it consistent with the other names, which >>>>> then can all be changed at once, when nice names are agreed upon. >>>>>> >>>>>>> Leave renaming functions for later change. >>>>>>> >>>>>>> Ran JPRT which builds more Oracle platforms, mach5 tier1-5 on >>>>>>> windows/linux x64 and tier1 on solaris-sparcv9.? Also built Zero >>>>>>> product mode (fails building fastdebug for some other reason). >>>>>>> >>>>>>> Other platforms: could you please test this patch? >>>>>>> >>>>>>> open webrev at >>>>>>> http://cr.openjdk.java.net/~coleenp/8186903.01/webrev >>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8186903 >>>>>>> >>>>>>> This change is for JDK 11. >>>>>> >>>>>> src/hotspot/cpu/x86/stubGenerator_x86_32.cpp >>>>>> >>>>>> Return type should be int32_t not int >>>>>> >>>>>> src/hotspot/os_cpu/windows_x86/os_windows_x86.hpp >>>>>> >>>>>> -? static intptr_t? (*atomic_xchg_long_func)???? (jlong, volatile >>>>>> jlong*); >>>>>> -? static intptr_t? atomic_xchg_long_bootstrap?? (jlong, volatile >>>>>> jlong*); >>>>>> >>>>>> Wow - that looks like a bug! Only returns 32-bits on 32-bit! >>>>> >>>>> This one also is only used on 64 bit.? I have to confess I don't >>>>> follow all the paths of the atomics and their various translations >>>>> down to the platform levels.?? I'm not sure how windows 32 bit >>>>> calls atomic_add or xchg for 64 bit values (or if it is not >>>>> implemented). >>>> >>>> Not implemented at the lowest levels AFAICS - only load/store and >>>> cmpxchg<8>. Of course the other atomics can then be written at a >>>> higher-level in terms of cmpxchg. >>>> >>>> The whole use of the stubgenerator for atomics is something that >>>> needs re-examining as I think it is completely unnecessary today >>>> (and likely for quite some time). The opening comment in >>>> atomic_windows_x86.hpp is somewhat startling as we approach 2018 :) >>> >>> I asked about this in the review and Erik said they were needed for >>> some reason, but it would be nice to have these cleaned up somehow. >>> Kim has some ideas for simplifying the implementation. My script to >>> find all these names goes something like this: >>> >>> foreach atomic (cmpxchg xchg add load store) >>> ... >>> ?? ? foreach type (entry func bootstrap) >>> ... >>> ????????? foreach ("" "long" "byte") >>> ... >>> >>>> >>>> // The following alternative implementations are needed because >>>> // Windows 95 doesn't support (some of) the corresponding Windows NT >>>> // calls. Furthermore, these versions allow inlining in the caller. >>>> // (More precisely: The documentation for InterlockedExchange says >>>> // it is supported for Windows 95. However, when single-stepping >>>> // through the assembly code we cannot step into the routine and >>>> // when looking at the routine address we see only garbage code. >>>> // Better safe then sorry!). Was bug 7/31/98 (gri). >>> >>> Yeah, good thing we can single step on Windows 95! >>> >>> Thanks, >>> Coleen >>> >>>> >>>> Cheers, >>>> David >>>> >>>>>> >>>>>> Everything else seems fine. >>>>>> >>>>> >>>>> Thanks for the eagle eye review. >>>>> Coleen >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> Thanks, >>>>>>> Coleen >>>>> >>> >> From daniel.daugherty at oracle.com Fri Dec 8 14:36:59 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 8 Dec 2017 09:36:59 -0500 Subject: RFR(XXS): 8182307 - Error during JRMP connection establishment In-Reply-To: <6cadd346-f826-55ce-0276-cfd2f7bef7f4@oracle.com> References: <58075a8f-1732-7b9e-74b1-3e36189f87fd@oracle.com> <0a36c975-8bca-c618-9133-66348f145436@oracle.com> <6cadd346-f826-55ce-0276-cfd2f7bef7f4@oracle.com> Message-ID: <56b505b7-4294-69e0-b501-708ea2c7a81d@oracle.com> On 12/8/17 4:28 AM, Alan Bateman wrote: > On 07/12/2017 16:55, Daniel D. Daugherty wrote: >> : >>> Greetings, >>> >>> I have a small fix for a very intermittent ServerSocket related test >>> failure: >>> >>> ??? JDK-8182307: Error during JRMP connection establishment >>> ??? https://bugs.openjdk.java.net/browse/JDK-8182307 >>> >>> : >>> >>> For the gory details of the reasons for this fix please see >>> Jerry's bugs. >>> >>> Webrev URL: http://cr.openjdk.java.net/~dcubed/8182307-webrev/jdk10-0/ >>> > It's not clear to me how this change solves the issue.? It's a "read > timeout" so this means the connection has been established. Yes, the connection has been established, but it has been established to the wrong ServerSocket. The ServerSocket port that was picked by the test with its "return new ServerSocket(port)" call was also picked by another "interloper" process. It's the SO_REUSEADDR attribute that allows these two processes to both think that they have the same random port. We have only observed proven sightings of this bug on Solaris SPARC and Solaris X64 machines. So the interloper and the server side of the test both did accept() calls on the same port. The interloper won the race in this case so it is matched up with the test's client side connect(). The test's client side starts doing its protocol reads, but the interloper does not send what the test's client side expects so the test's client side times out in read(). Here's Jerry's eval note from https://bugs.openjdk.java.net/browse/JDK-8182757: > gthornbr Gerald Thornbrugh > > added a comment - 2017-07-27 11:33 > If a socket is being setup without a fixed port using the SO_REUSEADDR > flag can lead to other processes interfering with the poll/receive > process of a debugger/debuggee configuring a socket for communication. > When SO_REUSEADDR is used other processes can attempt a listen() on > the same port and receive a connect from the debuggee. This causes the > debugger to stay in poll() waiting for a connect and the debuggee > stays in recv() waiting to receive data from the "rogue" process that > will never send it. > > This can also lead to connections being terminated early on the > debuggee side when the "rogue" process terminates the connection > because it does not receive what it expected from the client process > (i.e. the debuggee). > > The fix is to not use the SO_REUSEADDR flag for non-fixed port > sockets. This keeps "rogue" processes from reusing the port address > and from stealing the connects sent by from the debuggee. In the hunt for JDK-8182757 we were fortunate that the tests were configured for the server side accept() call to _not_ timeout. That allowed us to capture stacks from both the debuggee and debugger sides. We were also able to capture debug info from different points in the protocol stack in various repro attemps. The only thing we didn't do was add debugging info in the kernel to try and chase the race enabled by SO_REUSEADDR to ground. This bug's (JDK-8182307) failure mode is more like the other failure that Jerry fixed: https://bugs.openjdk.java.net/browse/JDK-8178676 The server side accept() is configured to timeout so we don't have a stack from the server side hang point to prove that the JDK-8178676 failure is the same as the JDK-8182757. With the fixes for JDK-8182757 and JDK-8178676 in place, we have not seen these failure modes reproduce. The fix for JDK-8182757 was pushed on 2017-08-03 and the fix for JDK-8178676 was pushed on 2017-08-14. It is not proof, but it is a strong indicator that these instances of this failure mode are fixed. > The client will not care if the server has enabled SO_REUSEADDR or > whether it initially bound to a fixed or ephemeral port. True, but the client has been connected to the interloper process which is why the read() times out. It is the SO_REUSEADDR attribute that allows the interloper to accept() the test's server side port and that does break the client side of the test. > Is this issue Solaris only? I ask because there is an awkward issue on > Solaris where the kernel will accept a pending connection when the > process is at its file descriptor limit. We've seen this periodically, > esp. with tests that leave connections or files open. An unsuspecting > tests runs later, establishes a connection but gets timeouts as there > isn't no code at the application level has accepted the connection. We have only seen provable sightings of this failure mode on Solaris SPARC and Solaris X64 machines. Folks have added sightings on other platforms to the older bug that was tracking the original issue: ??? JDK-6303969 JDWP: Socket Transport handshake fails rarely on InstancesTest.java ??? https://bugs.openjdk.java.net/browse/JDK-6303969 but Jerry and I were never able to prove a sighting on anything other than Solaris. This "file descriptor limit" issue is new to me. Do you have a pointer to it? It's entirely possible that there is more than one bug at play here... Dan > > -Alan > > From daniel.daugherty at oracle.com Fri Dec 8 15:25:08 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 8 Dec 2017 10:25:08 -0500 Subject: RFR(XXS/M): 8193135 - get rid of redundant _smr_ prefix/infix in ThreadSMRSupport stuff Message-ID: <753f72e2-3b6c-c43b-8640-892c68e57e19@oracle.com> Greetings, This should be last of the big Thread-SMR cleanup reviews! Stefan K, this is one of your Thread-SMR follow-up suggestions so I need to hear from you on this thread. Thanks! In terms of actual "new/changed" code, this is an "XXS" review. However, because of renaming, the changed/insert/delete counts are the size of an "M" review. This is another simple (but tedious) review; I found that the "udiffs" were easier than "frames" to verify the fix. Here is the bug: ??? JDK-8193135 get rid of redundant _smr_ prefix/infix in ThreadSMRSupport stuff ??? https://bugs.openjdk.java.net/browse/JDK-8193135 Here is the full webrev: http://cr.openjdk.java.net/~dcubed/8193135-webrev/jdk10-0-full/ Because of the removal of the '_smr_' prefix/infix, some functions had to be moved to stay in proper sort order. I've created separate delta webrevs to separate the renaming from the code motion. Here is the renaming part of the review: http://cr.openjdk.java.net/~dcubed/8193135-webrev/jdk10-0-delta-part1/ Here is the code motion part of the review: http://cr.openjdk.java.net/~dcubed/8193135-webrev/jdk10-0-delta-part2/ This fix is being (over) tested with a Mach5 tier[1-5] run. The code motion part was sanity checked by extracting the pre-move code into a file, extracting the post-move code into another file and comparing the two files. I didn't come up with a good way to automate the sanity checking of the removal of the '_smr_' prefix/infix; that was complicated by the fact that the two 'smr_delete()' functions were not renamed to 'delete()'. Thanks, in advance, for any comments, questions or suggestions. Dan From stefan.karlsson at oracle.com Fri Dec 8 15:31:06 2017 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Fri, 8 Dec 2017 16:31:06 +0100 Subject: RFR(XXS/M): 8193135 - get rid of redundant _smr_ prefix/infix in ThreadSMRSupport stuff In-Reply-To: <753f72e2-3b6c-c43b-8640-892c68e57e19@oracle.com> References: <753f72e2-3b6c-c43b-8640-892c68e57e19@oracle.com> Message-ID: Looks good to me. Thanks, StefanK On 2017-12-08 16:25, Daniel D. Daugherty wrote: > Greetings, > > This should be last of the big Thread-SMR cleanup reviews! Stefan K, this > is one of your Thread-SMR follow-up suggestions so I need to hear from > you > on this thread. Thanks! > > In terms of actual "new/changed" code, this is an "XXS" review. However, > because of renaming, the changed/insert/delete counts are the size of an > "M" review. This is another simple (but tedious) review; I found that > the "udiffs" were easier than "frames" to verify the fix. > > Here is the bug: > > ??? JDK-8193135 get rid of redundant _smr_ prefix/infix in > ThreadSMRSupport stuff > ??? https://bugs.openjdk.java.net/browse/JDK-8193135 > > Here is the full webrev: > > http://cr.openjdk.java.net/~dcubed/8193135-webrev/jdk10-0-full/ > > Because of the removal of the '_smr_' prefix/infix, some functions had > to be moved to stay in proper sort order. I've created separate delta > webrevs to separate the renaming from the code motion. > > Here is the renaming part of the review: > > http://cr.openjdk.java.net/~dcubed/8193135-webrev/jdk10-0-delta-part1/ > > Here is the code motion part of the review: > > http://cr.openjdk.java.net/~dcubed/8193135-webrev/jdk10-0-delta-part2/ > > This fix is being (over) tested with a Mach5 tier[1-5] run. > > The code motion part was sanity checked by extracting the pre-move code > into a file, extracting the post-move code into another file and > comparing > the two files. I didn't come up with a good way to automate the sanity > checking of the removal of the '_smr_' prefix/infix; that was complicated > by the fact that the two 'smr_delete()' functions were not renamed to > 'delete()'. > > Thanks, in advance, for any comments, questions or suggestions. > > Dan From daniel.daugherty at oracle.com Fri Dec 8 15:42:04 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 8 Dec 2017 10:42:04 -0500 Subject: RFR(XXS/M): 8193135 - get rid of redundant _smr_ prefix/infix in ThreadSMRSupport stuff In-Reply-To: References: <753f72e2-3b6c-c43b-8640-892c68e57e19@oracle.com> Message-ID: <92306a6a-c48a-93be-1554-c416a3661c4c@oracle.com> Stefan, Thanks for the fast review! Dan On 12/8/17 10:31 AM, Stefan Karlsson wrote: > Looks good to me. > > Thanks, > StefanK > > On 2017-12-08 16:25, Daniel D. Daugherty wrote: >> Greetings, >> >> This should be last of the big Thread-SMR cleanup reviews! Stefan K, >> this >> is one of your Thread-SMR follow-up suggestions so I need to hear >> from you >> on this thread. Thanks! >> >> In terms of actual "new/changed" code, this is an "XXS" review. However, >> because of renaming, the changed/insert/delete counts are the size of an >> "M" review. This is another simple (but tedious) review; I found that >> the "udiffs" were easier than "frames" to verify the fix. >> >> Here is the bug: >> >> ??? JDK-8193135 get rid of redundant _smr_ prefix/infix in >> ThreadSMRSupport stuff >> ??? https://bugs.openjdk.java.net/browse/JDK-8193135 >> >> Here is the full webrev: >> >> http://cr.openjdk.java.net/~dcubed/8193135-webrev/jdk10-0-full/ >> >> Because of the removal of the '_smr_' prefix/infix, some functions had >> to be moved to stay in proper sort order. I've created separate delta >> webrevs to separate the renaming from the code motion. >> >> Here is the renaming part of the review: >> >> http://cr.openjdk.java.net/~dcubed/8193135-webrev/jdk10-0-delta-part1/ >> >> Here is the code motion part of the review: >> >> http://cr.openjdk.java.net/~dcubed/8193135-webrev/jdk10-0-delta-part2/ >> >> This fix is being (over) tested with a Mach5 tier[1-5] run. >> >> The code motion part was sanity checked by extracting the pre-move code >> into a file, extracting the post-move code into another file and >> comparing >> the two files. I didn't come up with a good way to automate the sanity >> checking of the removal of the '_smr_' prefix/infix; that was >> complicated >> by the fact that the two 'smr_delete()' functions were not renamed to >> 'delete()'. >> >> Thanks, in advance, for any comments, questions or suggestions. >> >> Dan > > From george.triantafillou at oracle.com Fri Dec 8 16:03:28 2017 From: george.triantafillou at oracle.com (George Triantafillou) Date: Fri, 8 Dec 2017 11:03:28 -0500 Subject: RFR(XXS/M): 8193135 - get rid of redundant _smr_ prefix/infix in ThreadSMRSupport stuff In-Reply-To: <753f72e2-3b6c-c43b-8640-892c68e57e19@oracle.com> References: <753f72e2-3b6c-c43b-8640-892c68e57e19@oracle.com> Message-ID: <70fef826-6f5c-38cc-9bb9-0d6da0c956df@oracle.com> Dan, Looks good. -George On 12/8/2017 10:25 AM, Daniel D. Daugherty wrote: > Greetings, > > This should be last of the big Thread-SMR cleanup reviews! Stefan K, this > is one of your Thread-SMR follow-up suggestions so I need to hear from > you > on this thread. Thanks! > > In terms of actual "new/changed" code, this is an "XXS" review. However, > because of renaming, the changed/insert/delete counts are the size of an > "M" review. This is another simple (but tedious) review; I found that > the "udiffs" were easier than "frames" to verify the fix. > > Here is the bug: > > ??? JDK-8193135 get rid of redundant _smr_ prefix/infix in > ThreadSMRSupport stuff > ??? https://bugs.openjdk.java.net/browse/JDK-8193135 > > Here is the full webrev: > > http://cr.openjdk.java.net/~dcubed/8193135-webrev/jdk10-0-full/ > > Because of the removal of the '_smr_' prefix/infix, some functions had > to be moved to stay in proper sort order. I've created separate delta > webrevs to separate the renaming from the code motion. > > Here is the renaming part of the review: > > http://cr.openjdk.java.net/~dcubed/8193135-webrev/jdk10-0-delta-part1/ > > Here is the code motion part of the review: > > http://cr.openjdk.java.net/~dcubed/8193135-webrev/jdk10-0-delta-part2/ > > This fix is being (over) tested with a Mach5 tier[1-5] run. > > The code motion part was sanity checked by extracting the pre-move code > into a file, extracting the post-move code into another file and > comparing > the two files. I didn't come up with a good way to automate the sanity > checking of the removal of the '_smr_' prefix/infix; that was complicated > by the fact that the two 'smr_delete()' functions were not renamed to > 'delete()'. > > Thanks, in advance, for any comments, questions or suggestions. > > Dan From daniel.daugherty at oracle.com Fri Dec 8 16:04:42 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 8 Dec 2017 11:04:42 -0500 Subject: RFR(XXS/M): 8193135 - get rid of redundant _smr_ prefix/infix in ThreadSMRSupport stuff In-Reply-To: <70fef826-6f5c-38cc-9bb9-0d6da0c956df@oracle.com> References: <753f72e2-3b6c-c43b-8640-892c68e57e19@oracle.com> <70fef826-6f5c-38cc-9bb9-0d6da0c956df@oracle.com> Message-ID: <81786b17-2347-53b2-0a82-c9c5a2a664f4@oracle.com> George, Thanks for the quick review! Dan On 12/8/17 11:03 AM, George Triantafillou wrote: > Dan, > > Looks good. > > -George > > On 12/8/2017 10:25 AM, Daniel D. Daugherty wrote: >> Greetings, >> >> This should be last of the big Thread-SMR cleanup reviews! Stefan K, >> this >> is one of your Thread-SMR follow-up suggestions so I need to hear >> from you >> on this thread. Thanks! >> >> In terms of actual "new/changed" code, this is an "XXS" review. However, >> because of renaming, the changed/insert/delete counts are the size of an >> "M" review. This is another simple (but tedious) review; I found that >> the "udiffs" were easier than "frames" to verify the fix. >> >> Here is the bug: >> >> ??? JDK-8193135 get rid of redundant _smr_ prefix/infix in >> ThreadSMRSupport stuff >> ??? https://bugs.openjdk.java.net/browse/JDK-8193135 >> >> Here is the full webrev: >> >> http://cr.openjdk.java.net/~dcubed/8193135-webrev/jdk10-0-full/ >> >> Because of the removal of the '_smr_' prefix/infix, some functions had >> to be moved to stay in proper sort order. I've created separate delta >> webrevs to separate the renaming from the code motion. >> >> Here is the renaming part of the review: >> >> http://cr.openjdk.java.net/~dcubed/8193135-webrev/jdk10-0-delta-part1/ >> >> Here is the code motion part of the review: >> >> http://cr.openjdk.java.net/~dcubed/8193135-webrev/jdk10-0-delta-part2/ >> >> This fix is being (over) tested with a Mach5 tier[1-5] run. >> >> The code motion part was sanity checked by extracting the pre-move code >> into a file, extracting the post-move code into another file and >> comparing >> the two files. I didn't come up with a good way to automate the sanity >> checking of the removal of the '_smr_' prefix/infix; that was >> complicated >> by the fact that the two 'smr_delete()' functions were not renamed to >> 'delete()'. >> >> Thanks, in advance, for any comments, questions or suggestions. >> >> Dan > From calvin.cheung at oracle.com Fri Dec 8 19:23:06 2017 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Fri, 08 Dec 2017 11:23:06 -0800 Subject: [10] RFR(S): 8192989: runtime/appcds/javaldr/ArrayTest.java crashes with assert(k->is_instance_klass()) In-Reply-To: References: <5A29D047.5050800@oracle.com> <5A29F1FA.9090504@oracle.com> Message-ID: <5A2AE69A.2030907@oracle.com> Thanks - Jiangli. Calvin On 12/8/17, 11:12 AM, Jiangli Zhou wrote: > >> On Dec 7, 2017, at 5:59 PM, Calvin Cheung > > wrote: >> >> Hi Jiangli, >> >> I've added two multidimensional arrays to the test case. >> updated webrev: >> http://cr.openjdk.java.net/~ccheung/8192989/webrev.01/ >> > > Looks ok. Thanks. > > Jiangli > >> >> thanks, >> Calvin >> >> On 12/7/17, 4:39 PM, Jiangli Zhou wrote: >>> Hi Calvin, >>> >>> The short-term fix looks good. For the test, please add a few >>> multi-dimensional arrays in ArrayTest.arrayClasses[]. I want to make >>> sure they are also identified if present in the class list. We need >>> to test multi-dimensional arrays as well when we add proper handling >>> for array classes. >>> >>> For example: >>> [[[B >>> [[[[[Ljava/lang/Object; >>> >>> Thanks, >>> Jiangli >>> >>>> On Dec 7, 2017, at 3:35 PM, Calvin Cheung>>> > wrote: >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8192989 >>>> >>>> For JDK10, we're going for a simple and safe fix by not processing >>>> array classes found in a class list during CDS dump time. >>>> We'll revisit the dumping of array classes in JDK11. >>>> >>>> webrev: http://cr.openjdk.java.net/~ccheung/8192989/webrev.00/ >>>> >>>> >>>> Testing: >>>> hs-tier1, hs-tier2 on 64-bit platforms (linux, macosx, windows, >>>> sparc). >>>> >>>> thanks, >>>> Calvin >>>> >>>> > From coleen.phillimore at oracle.com Fri Dec 8 19:51:32 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 8 Dec 2017 14:51:32 -0500 Subject: RFR(XXS/M): 8193135 - get rid of redundant _smr_ prefix/infix in ThreadSMRSupport stuff In-Reply-To: <753f72e2-3b6c-c43b-8640-892c68e57e19@oracle.com> References: <753f72e2-3b6c-c43b-8640-892c68e57e19@oracle.com> Message-ID: <8fc65d5e-937f-6617-ad8c-f4195ecce4bc@oracle.com> Hi Dan, These changes look good.? The shortened names look much more meaningful and easier to read with the class name ThreadsSMRSupport prepended. thanks, Coleen On 12/8/17 10:25 AM, Daniel D. Daugherty wrote: > Greetings, > > This should be last of the big Thread-SMR cleanup reviews! Stefan K, this > is one of your Thread-SMR follow-up suggestions so I need to hear from > you > on this thread. Thanks! > > In terms of actual "new/changed" code, this is an "XXS" review. However, > because of renaming, the changed/insert/delete counts are the size of an > "M" review. This is another simple (but tedious) review; I found that > the "udiffs" were easier than "frames" to verify the fix. > > Here is the bug: > > ??? JDK-8193135 get rid of redundant _smr_ prefix/infix in > ThreadSMRSupport stuff > ??? https://bugs.openjdk.java.net/browse/JDK-8193135 > > Here is the full webrev: > > http://cr.openjdk.java.net/~dcubed/8193135-webrev/jdk10-0-full/ > > Because of the removal of the '_smr_' prefix/infix, some functions had > to be moved to stay in proper sort order. I've created separate delta > webrevs to separate the renaming from the code motion. > > Here is the renaming part of the review: > > http://cr.openjdk.java.net/~dcubed/8193135-webrev/jdk10-0-delta-part1/ > > Here is the code motion part of the review: > > http://cr.openjdk.java.net/~dcubed/8193135-webrev/jdk10-0-delta-part2/ > > This fix is being (over) tested with a Mach5 tier[1-5] run. > > The code motion part was sanity checked by extracting the pre-move code > into a file, extracting the post-move code into another file and > comparing > the two files. I didn't come up with a good way to automate the sanity > checking of the removal of the '_smr_' prefix/infix; that was complicated > by the fact that the two 'smr_delete()' functions were not renamed to > 'delete()'. > > Thanks, in advance, for any comments, questions or suggestions. > > Dan From jiangli.zhou at oracle.com Fri Dec 8 19:12:25 2017 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Fri, 8 Dec 2017 11:12:25 -0800 Subject: [10] RFR(S): 8192989: runtime/appcds/javaldr/ArrayTest.java crashes with assert(k->is_instance_klass()) In-Reply-To: <5A29F1FA.9090504@oracle.com> References: <5A29D047.5050800@oracle.com> <5A29F1FA.9090504@oracle.com> Message-ID: > On Dec 7, 2017, at 5:59 PM, Calvin Cheung wrote: > > Hi Jiangli, > > I've added two multidimensional arrays to the test case. > updated webrev: > http://cr.openjdk.java.net/~ccheung/8192989/webrev.01/ Looks ok. Thanks. Jiangli > > thanks, > Calvin > > On 12/7/17, 4:39 PM, Jiangli Zhou wrote: >> Hi Calvin, >> >> The short-term fix looks good. For the test, please add a few multi-dimensional arrays in ArrayTest.arrayClasses[]. I want to make sure they are also identified if present in the class list. We need to test multi-dimensional arrays as well when we add proper handling for array classes. >> >> For example: >> [[[B >> [[[[[Ljava/lang/Object; >> >> Thanks, >> Jiangli >> >>> On Dec 7, 2017, at 3:35 PM, Calvin Cheung wrote: >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8192989 >>> >>> For JDK10, we're going for a simple and safe fix by not processing array classes found in a class list during CDS dump time. >>> We'll revisit the dumping of array classes in JDK11. >>> >>> webrev: http://cr.openjdk.java.net/~ccheung/8192989/webrev.00/ >>> >>> Testing: >>> hs-tier1, hs-tier2 on 64-bit platforms (linux, macosx, windows, sparc). >>> >>> thanks, >>> Calvin >>> >>> From daniel.daugherty at oracle.com Fri Dec 8 20:18:46 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 8 Dec 2017 15:18:46 -0500 Subject: RFR (M) 8186903: Remove j-types from Atomic In-Reply-To: References: Message-ID: On 12/6/17 4:59 PM, coleen.phillimore at oracle.com wrote: > Summary: Change parameter types from jlong, jint, jbyte to int64_t, > int32_t and int8_t respectively > > Leave renaming functions for later change. > > Ran JPRT which builds more Oracle platforms, mach5 tier1-5 on > windows/linux x64 and tier1 on solaris-sparcv9.? Also built Zero > product mode (fails building fastdebug for some other reason). > > Other platforms: could you please test this patch? > > open webrev at http://cr.openjdk.java.net/~coleenp/8186903.01/webrev src/hotspot/cpu/x86/stubGenerator_x86_32.cpp ??? No comments. src/hotspot/cpu/x86/stubGenerator_x86_64.cpp ??? No comments. src/hotspot/cpu/zero/stubGenerator_zero.cpp ??? No comments. src/hotspot/os_cpu/bsd_x86/atomic_bsd_x86.hpp ??? No comments. src/hotspot/os_cpu/bsd_x86/bsd_x86_32.s ??? No comments. src/hotspot/os_cpu/bsd_zero/atomic_bsd_zero.hpp ??? No comments. src/hotspot/os_cpu/linux_arm/atomic_linux_arm.hpp ??? No comments. src/hotspot/os_cpu/linux_arm/os_linux_arm.cpp ??? No comments. src/hotspot/os_cpu/linux_arm/os_linux_arm.hpp ??? No comments. src/hotspot/os_cpu/linux_sparc/os_linux_sparc.hpp ??? No comments. src/hotspot/os_cpu/linux_x86/atomic_linux_x86.hpp ??? No comments. src/hotspot/os_cpu/linux_zero/atomic_linux_zero.hpp ??? No comments. src/hotspot/os_cpu/solaris_sparc/os_solaris_sparc.hpp ??? No comments. src/hotspot/os_cpu/solaris_x86/atomic_solaris_x86.hpp ??? No comments. src/hotspot/os_cpu/solaris_x86/os_solaris_x86.cpp ??? No comments. src/hotspot/os_cpu/solaris_x86/os_solaris_x86.hpp ??? No comments. src/hotspot/os_cpu/windows_x86/atomic_windows_x86.hpp ??? No comments. src/hotspot/os_cpu/windows_x86/os_windows_x86.cpp ??? No comments. src/hotspot/os_cpu/windows_x86/os_windows_x86.hpp ??? No comments. src/hotspot/share/runtime/atomic.hpp ??? No comments. src/hotspot/share/runtime/stubRoutines.cpp ??? No comments. src/hotspot/share/runtime/stubRoutines.hpp ??? No comments. Thumbs up. I'm also scratching my head on some of the switches to "long" usage, but it looks like you and David worked that out... Dan > bug link https://bugs.openjdk.java.net/browse/JDK-8186903 > > This change is for JDK 11. > > Thanks, > Coleen > From daniel.daugherty at oracle.com Fri Dec 8 20:19:45 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 8 Dec 2017 15:19:45 -0500 Subject: RFR(XXS/M): 8193135 - get rid of redundant _smr_ prefix/infix in ThreadSMRSupport stuff In-Reply-To: <8fc65d5e-937f-6617-ad8c-f4195ecce4bc@oracle.com> References: <753f72e2-3b6c-c43b-8640-892c68e57e19@oracle.com> <8fc65d5e-937f-6617-ad8c-f4195ecce4bc@oracle.com> Message-ID: <1ea80b02-7b1a-c6fa-5d27-1a95890229ea@oracle.com> Hi Coleen, Thanks for the review! Dan On 12/8/17 2:51 PM, coleen.phillimore at oracle.com wrote: > Hi Dan, > > These changes look good.? The shortened names look much more > meaningful and easier to read with the class name ThreadsSMRSupport > prepended. > > thanks, > Coleen > > > On 12/8/17 10:25 AM, Daniel D. Daugherty wrote: >> Greetings, >> >> This should be last of the big Thread-SMR cleanup reviews! Stefan K, >> this >> is one of your Thread-SMR follow-up suggestions so I need to hear >> from you >> on this thread. Thanks! >> >> In terms of actual "new/changed" code, this is an "XXS" review. However, >> because of renaming, the changed/insert/delete counts are the size of an >> "M" review. This is another simple (but tedious) review; I found that >> the "udiffs" were easier than "frames" to verify the fix. >> >> Here is the bug: >> >> ??? JDK-8193135 get rid of redundant _smr_ prefix/infix in >> ThreadSMRSupport stuff >> ??? https://bugs.openjdk.java.net/browse/JDK-8193135 >> >> Here is the full webrev: >> >> http://cr.openjdk.java.net/~dcubed/8193135-webrev/jdk10-0-full/ >> >> Because of the removal of the '_smr_' prefix/infix, some functions had >> to be moved to stay in proper sort order. I've created separate delta >> webrevs to separate the renaming from the code motion. >> >> Here is the renaming part of the review: >> >> http://cr.openjdk.java.net/~dcubed/8193135-webrev/jdk10-0-delta-part1/ >> >> Here is the code motion part of the review: >> >> http://cr.openjdk.java.net/~dcubed/8193135-webrev/jdk10-0-delta-part2/ >> >> This fix is being (over) tested with a Mach5 tier[1-5] run. >> >> The code motion part was sanity checked by extracting the pre-move code >> into a file, extracting the post-move code into another file and >> comparing >> the two files. I didn't come up with a good way to automate the sanity >> checking of the removal of the '_smr_' prefix/infix; that was >> complicated >> by the fact that the two 'smr_delete()' functions were not renamed to >> 'delete()'. >> >> Thanks, in advance, for any comments, questions or suggestions. >> >> Dan > From coleen.phillimore at oracle.com Fri Dec 8 20:24:18 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 8 Dec 2017 15:24:18 -0500 Subject: RFR (M) 8186903: Remove j-types from Atomic In-Reply-To: References: Message-ID: <9963df5f-5903-a503-5a47-2a9cd9cf49bc@oracle.com> Thanks Dan! On 12/8/17 3:18 PM, Daniel D. Daugherty wrote: > On 12/6/17 4:59 PM, coleen.phillimore at oracle.com wrote: >> Summary: Change parameter types from jlong, jint, jbyte to int64_t, >> int32_t and int8_t respectively >> >> Leave renaming functions for later change. >> >> Ran JPRT which builds more Oracle platforms, mach5 tier1-5 on >> windows/linux x64 and tier1 on solaris-sparcv9.? Also built Zero >> product mode (fails building fastdebug for some other reason). >> >> Other platforms: could you please test this patch? >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8186903.01/webrev > > src/hotspot/cpu/x86/stubGenerator_x86_32.cpp > ??? No comments. > > src/hotspot/cpu/x86/stubGenerator_x86_64.cpp > ??? No comments. > > src/hotspot/cpu/zero/stubGenerator_zero.cpp > ??? No comments. > > src/hotspot/os_cpu/bsd_x86/atomic_bsd_x86.hpp > ??? No comments. > > src/hotspot/os_cpu/bsd_x86/bsd_x86_32.s > ??? No comments. > > src/hotspot/os_cpu/bsd_zero/atomic_bsd_zero.hpp > ??? No comments. > > src/hotspot/os_cpu/linux_arm/atomic_linux_arm.hpp > ??? No comments. > > src/hotspot/os_cpu/linux_arm/os_linux_arm.cpp > ??? No comments. > > src/hotspot/os_cpu/linux_arm/os_linux_arm.hpp > ??? No comments. > > src/hotspot/os_cpu/linux_sparc/os_linux_sparc.hpp > ??? No comments. > > src/hotspot/os_cpu/linux_x86/atomic_linux_x86.hpp > ??? No comments. > > src/hotspot/os_cpu/linux_zero/atomic_linux_zero.hpp > ??? No comments. > > src/hotspot/os_cpu/solaris_sparc/os_solaris_sparc.hpp > ??? No comments. > > src/hotspot/os_cpu/solaris_x86/atomic_solaris_x86.hpp > ??? No comments. > > src/hotspot/os_cpu/solaris_x86/os_solaris_x86.cpp > ??? No comments. > > src/hotspot/os_cpu/solaris_x86/os_solaris_x86.hpp > ??? No comments. > > src/hotspot/os_cpu/windows_x86/atomic_windows_x86.hpp > ??? No comments. > > src/hotspot/os_cpu/windows_x86/os_windows_x86.cpp > ??? No comments. > > src/hotspot/os_cpu/windows_x86/os_windows_x86.hpp > ??? No comments. > > src/hotspot/share/runtime/atomic.hpp > ??? No comments. > > src/hotspot/share/runtime/stubRoutines.cpp > ??? No comments. > > src/hotspot/share/runtime/stubRoutines.hpp > ??? No comments. > > > Thumbs up. > > I'm also scratching my head on some of the switches to "long" usage, > but it looks like you and David worked that out... > The ptr variants were removed except this one.? It should be some 64 bit entity which for the rest of the functions is currently 'long'. So I made it match.?? It's a further cleanup (as always!)? Now all the ptr variants are gone. Coleen > Dan > > > >> bug link https://bugs.openjdk.java.net/browse/JDK-8186903 >> >> This change is for JDK 11. >> >> Thanks, >> Coleen >> > From manc at google.com Sat Dec 9 02:57:12 2017 From: manc at google.com (Man Cao) Date: Fri, 8 Dec 2017 18:57:12 -0800 Subject: Make reserved_size for compressed class space and metaspace respect the ergo-initialized CompressedClassSpaceSize flag value In-Reply-To: References: Message-ID: Hi Yasumasa, Thanks for the review! Although I think moving or not moving "CompressedClassSpaceSize = align_size_down_bounded()" are equivalent because of logic of alignment and FLAG_SET_ERGO, I made the change you suggested anyway. The new patch is attached and inlined below. --- old/src/hotspot/share/memory/metaspace.cpp 2017-12-08 18:42:48.960285998 -0800 +++ new/src/hotspot/share/memory/metaspace.cpp 2017-12-08 18:42:48.600288972 -0800 @@ -3322,7 +3322,6 @@ MaxMetaspaceExpansion = align_down_bounded(MaxMetaspaceExpansion, _commit_alignment); CompressedClassSpaceSize = align_down_bounded(CompressedClassSpaceSize, _reserve_alignment); - set_compressed_class_space_size(CompressedClassSpaceSize); // Initial virtual space size will be calculated at global_initialize() size_t min_metaspace_sz = @@ -3341,6 +3340,7 @@ min_metaspace_sz); } + set_compressed_class_space_size(CompressedClassSpaceSize); } void Metaspace::global_initialize() { Thanks, Man On Thu, Dec 7, 2017 at 9:44 PM, Yasumasa Suenaga wrote: > Hi Man, > > CompressedClassSpaceSize might be modified by FLAG_SET_ERGO. > So I think you need to move set_compressed_class_space_size() only. > > > Thanks, > > Yasumasa > > > > 2017-12-08 3:42 GMT+09:00 Man Cao : > > Hello, > > > > This is a friendly ping. Could anyone review or sponsor this change? It's > > just a two-liner change. > > > > -Man > > > > On Thu, Nov 30, 2017 at 2:03 PM, Man Cao wrote: > >> > >> I realized that the email attachment is probably dropped by the mailing > >> list, so below is the inlined patch. > >> > >> --- old/src/hotspot/share/memory/metaspace.cpp 2017-11-29 > >> 14:56:59.017118444 -0800 > >> +++ new/src/hotspot/share/memory/metaspace.cpp 2017-11-29 > >> 14:56:58.657121375 -0800 > >> @@ -3321,9 +3321,6 @@ > >> MinMetaspaceExpansion = align_down_bounded(MinMetaspaceExpansion, > >> _commit_alignment); > >> MaxMetaspaceExpansion = align_down_bounded(MaxMetaspaceExpansion, > >> _commit_alignment); > >> > >> - CompressedClassSpaceSize = align_down_bounded( > CompressedClassSpaceSize, > >> _reserve_alignment); > >> - set_compressed_class_space_size(CompressedClassSpaceSize); > >> - > >> // Initial virtual space size will be calculated at > global_initialize() > >> size_t min_metaspace_sz = > >> VIRTUALSPACEMULTIPLIER * InitialBootClassLoaderMetaspaceSize; > >> @@ -3341,6 +3338,8 @@ > >> min_metaspace_sz); > >> } > >> > >> + CompressedClassSpaceSize = align_down_bounded( > CompressedClassSpaceSize, > >> _reserve_alignment); > >> + set_compressed_class_space_size(CompressedClassSpaceSize); > >> } > >> > >> void Metaspace::global_initialize() { > >> > >> Best, > >> Man > >> > >> On Wed, Nov 29, 2017 at 3:21 PM, Man Cao wrote: > >>> > >>> Hello, > >>> > >>> This patch is a follow-up fix for > >>> https://bugs.openjdk.java.net/browse/JDK-8087291 > >>> > >>> This patch moves the call to set_compressed_class_space_size() after > the > >>> flag value for CompressedClassSpaceSize is ergo-initialized, fixing the > >>> issue that the reserved size for compressed class space and metaspace > is > >>> excessively large when MaxMetaspaceSize is set to a small value. More > >>> discussion about it is available here: > >>> > >>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/ > 2017-November/025200.html > >>> > >>> This code patch is attached. Could anyone review and/or sponsor this > >>> patch? > >>> > >>> Best, > >>> Man > >> > >> > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: jdk10hs.patch Type: text/x-patch Size: 716 bytes Desc: not available URL: From yasuenag at gmail.com Sat Dec 9 12:37:01 2017 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sat, 9 Dec 2017 21:37:01 +0900 Subject: Make reserved_size for compressed class space and metaspace respect the ergo-initialized CompressedClassSpaceSize flag value In-Reply-To: References: Message-ID: Hi Man, Looks good, but you need to get a sponsor. Thanks, Yasumasa On 2017/12/09 11:57, Man Cao wrote: > Hi Yasumasa, > > Thanks for the review! Although I think moving or not moving "CompressedClassSpaceSize = align_size_down_bounded()" are equivalent because of logic of alignment and FLAG_SET_ERGO, I made the change you suggested anyway. > The new patch is attached and inlined below. > > > --- old/src/hotspot/share/memory/metaspace.cpp2017-12-08 18:42:48.960285998 -0800 > +++ new/src/hotspot/share/memory/metaspace.cpp2017-12-08 18:42:48.600288972 -0800 > @@ -3322,7 +3322,6 @@ > ? ?MaxMetaspaceExpansion = align_down_bounded(MaxMetaspaceExpansion, _commit_alignment); > ? ?CompressedClassSpaceSize = align_down_bounded(CompressedClassSpaceSize, _reserve_alignment); > -? set_compressed_class_space_size(CompressedClassSpaceSize); > ? ?// Initial virtual space size will be calculated at global_initialize() > ? ?size_t min_metaspace_sz = > @@ -3341,6 +3340,7 @@ > ? ? ? ? ? ? ? ? ? ?min_metaspace_sz); > ? ?} > +? set_compressed_class_space_size(CompressedClassSpaceSize); > ?} > ?void Metaspace::global_initialize() { > > > Thanks, > Man > > On Thu, Dec 7, 2017 at 9:44 PM, Yasumasa Suenaga > wrote: > > Hi Man, > > CompressedClassSpaceSize might be modified by FLAG_SET_ERGO. > So I think you need to move set_compressed_class_space_size() only. > > > Thanks, > > Yasumasa > > > > 2017-12-08 3:42 GMT+09:00 Man Cao >: > > Hello, > > > > This is a friendly ping. Could anyone review or sponsor this change? It's > > just a two-liner change. > > > > -Man > > > > On Thu, Nov 30, 2017 at 2:03 PM, Man Cao > wrote: > >> > >> I realized that the email attachment is probably dropped by the mailing > >> list, so below is the inlined patch. > >> > >> --- old/src/hotspot/share/memory/metaspace.cpp 2017-11-29 > >> 14:56:59.017118444 -0800 > >> +++ new/src/hotspot/share/memory/metaspace.cpp 2017-11-29 > >> 14:56:58.657121375 -0800 > >> @@ -3321,9 +3321,6 @@ > >>? ? MinMetaspaceExpansion = align_down_bounded(MinMetaspaceExpansion, > >> _commit_alignment); > >>? ? MaxMetaspaceExpansion = align_down_bounded(MaxMetaspaceExpansion, > >> _commit_alignment); > >> > >> -? CompressedClassSpaceSize = align_down_bounded(CompressedClassSpaceSize, > >> _reserve_alignment); > >> -? set_compressed_class_space_size(CompressedClassSpaceSize); > >> - > >>? ? // Initial virtual space size will be calculated at global_initialize() > >>? ? size_t min_metaspace_sz = > >>? ? ? ? VIRTUALSPACEMULTIPLIER * InitialBootClassLoaderMetaspaceSize; > >> @@ -3341,6 +3338,8 @@ > >>? ? ? ? ? ? ? ? ? ? min_metaspace_sz); > >>? ? } > >> > >> +? CompressedClassSpaceSize = align_down_bounded(CompressedClassSpaceSize, > >> _reserve_alignment); > >> +? set_compressed_class_space_size(CompressedClassSpaceSize); > >>? } > >> > >>? void Metaspace::global_initialize() { > >> > >> Best, > >> Man > >> > >> On Wed, Nov 29, 2017 at 3:21 PM, Man Cao > wrote: > >>> > >>> Hello, > >>> > >>> This patch is a follow-up fix for > >>> https://bugs.openjdk.java.net/browse/JDK-8087291 > >>> > >>> This patch moves the call to set_compressed_class_space_size() after the > >>> flag value for CompressedClassSpaceSize is ergo-initialized, fixing the > >>> issue that the reserved size for compressed class space and metaspace is > >>> excessively large when MaxMetaspaceSize is set to a small value. More > >>> discussion about it is available here: > >>> > >>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-November/025200.html > >>> > >>> This code patch is attached. Could anyone review and/or sponsor this > >>> patch? > >>> > >>> Best, > >>> Man > >> > >> > > > > From david.holmes at oracle.com Sun Dec 10 05:39:44 2017 From: david.holmes at oracle.com (David Holmes) Date: Sun, 10 Dec 2017 15:39:44 +1000 Subject: RFR: 8193222: EnsureLocalCapacity() should maintain capacity requests through multiple calls Message-ID: <8428e54c-aa5d-07a2-b269-d79f6f41a819@oracle.com> bug: https://bugs.openjdk.java.net/browse/JDK-8193222 webrev: http://cr.openjdk.java.net/~dholmes/8193222/webrev/ In product mode, for hotspot, EnsureLocalCapacity is a no-op as there is no artificial limit applied for local refs. With -Xcheck:jni the checked mode was augmented to watch for "excessive" use of local refs and to produce a warning if that happened e.g.: WARNING: JNI local refs: 41, exceeds capacity: 40 That was added under JDK-8043224. The problem is that the code always modifies the planned capacity (that expected before warnings should be used) without regard for the fact the existing capacity may be higher than that requested. As a result if you have a call chain like: void foo() { // C code env->EnsureLocalCapacity(60); // needs lots of local refs ... JNU_GetPlatformsString(...) env->EnsureLocalCapacity(5); // lower than 60! ... // create 60 local refs } upon return the warning will be issued because the number of local refs exceeds the most recent call to EnsureLocalCapacity. A simple fix is for EnsureLocalCapacity to only raise the planned capacity, not lower it. That fits with the notion of "ensuring" there is sufficient space - the function is not SetLocalcapacity. It also fits with the way PushLocalFrame(capacity) increases the planned capacity by "capacity" but PopLocalFrame does not reduce it again. New test added. Tested through JPRT. Thanks, David From adinn at redhat.com Mon Dec 11 09:20:13 2017 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 11 Dec 2017 09:20:13 +0000 Subject: RFR (M) 8186903: Remove j-types from Atomic In-Reply-To: References: <301ab272-399d-3f42-ee2f-15b3790e320c@redhat.com> Message-ID: On 08/12/17 12:36, coleen.phillimore at oracle.com wrote: > On 12/8/17 6:52 AM, Andrew Dinn wrote: >> On 06/12/17 21:59, coleen.phillimore at oracle.com wrote: >>> Other platforms: could you please test this patch? >> This built fine on AArch64 and successfully passed basic smoke tests >> (runs javac and netbeans, passes jtreg tests for j.u.c). >> >> I am currently running jcstress tests just to be sure. If you want to >> wait on the result of that I will let you know the result when they >> finish (all is ok so far but there is still a long way to go). > > Hi Andrew,? Did you also review the change? > > There's no rush because this is waiting for JDK 11 to open up. No, I didn't review the change. I think I will be doing so though because I saw some failures when running jcstress. Unfortunately, my AArch64 box fell over before the run completed so I did nto get a complete set of results. However, I did record the 3 failures shown below. I'll need to rerun with/without your change just to check whether it really is the culprit. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander ----- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< --- [FAILED] o.o.j.t.coherence.varHandles.fields.opaque.ShortTest (fork: #1, iteration #2, JVM args: [-XX:-TieredCompilation]) Observed state Occurrences Expectation Interpretation -1, -1 2,627,869 ACCEPTABLE Observers sees both read. -1, 0 1 FORBIDDEN Seeing first read, but not second: coherence violation. 0, -1 59 ACCEPTABLE Observe second read, but not first: sequential consistency. 0, 0 133,151 ACCEPTABLE Default value for the fields. Allowed to see this: data r... ----- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< --- [FAILED] o.o.j.t.coherence.varHandles.fields.opaque.ShortTest (fork: #1, iteration #3, JVM args: [-XX:-TieredCompilation]) Observed state Occurrences Expectation Interpretation -1, -1 15,667,937 ACCEPTABLE Observers sees both read. -1, 0 2 FORBIDDEN Seeing first read, but not second: coherence violation. 0, -1 3,713 ACCEPTABLE Observe second read, but not first: sequential consistency. 0, 0 751,608 ACCEPTABLE Default value for the fields. Allowed to see this: data r... ----- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< --- [FAILED] o.o.j.t.coherence.varHandles.fields.opaque.ByteTest (fork: #1, iteration #3, JVM args: [-XX:-TieredCompilation]) Observed state Occurrences Expectation Interpretation -1, -1 11,867,040 ACCEPTABLE Observers sees both read. -1, 0 1 FORBIDDEN Seeing first read, but not second: coherence violation. 0, -1 671 ACCEPTABLE Observe second read, but not first: sequential consistency. 0, 0 74,538 ACCEPTABLE Default value for the fields. Allowed to see this: data r... ----- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< --- From harold.seigel at oracle.com Mon Dec 11 15:34:20 2017 From: harold.seigel at oracle.com (harold seigel) Date: Mon, 11 Dec 2017 10:34:20 -0500 Subject: RFR 8154587: Resolution fails for default method named 'clone' In-Reply-To: <137ddf56-0f1e-ae10-3884-97a39fd92eeb@oracle.com> References: <22c41169-4c42-bff3-5090-a27ad9019bff@oracle.com> <3c0ff7a5-1a46-f4d9-c50a-6e6b322fdabc@oracle.com> <137ddf56-0f1e-ae10-3884-97a39fd92eeb@oracle.com> Message-ID: Hi, Please review this updated webrev for bug JDK-8154587: http://cr.openjdk.java.net/~hseigel/bug_8154587.2/webrev/ The main differences from the previous webrev are: 1. Improved comments and code changes to klassVtable.cpp and klassVtable.hpp 2. Added an assert to cpCache.cpp 3. Added new tests.? The purpose of many these tests, including the .../clone/invokevirtual/ tests, is to check for regressions. These changes were regression tested with the tests listed below plus tonga tests. Thanks, Harold On 12/6/2017 8:49 AM, harold seigel wrote: > Hi Lois, > > Thanks for the review.? I'll add these tests in the next iteration of > this webrev. > > >> - a test where class C does not define the method "clone", an IAE > should result, correct? > > Yes, the test throws an IAE. > > Harold > > > On 12/4/2017 2:31 PM, Lois Foltan wrote: >> Hi Harold, >> >> Fix looks good.? I would like to see three more test cases: >> >> ??? - the same test written for "finalize" since that is also a >> non-public method of Object. >> ??? - a test where class C does not define the method "clone", an IAE >> should result, correct? >> ??? - a test case where I2 defines a public method of Object >> >> Thanks, >> Lois >> >> On 11/30/2017 11:15 AM, harold seigel wrote: >>> Hi, >>> >>> Please review this fix for JDK-8154587.? The fix adds additional >>> special casing to skip over non-public methods in class >>> java.lang.Object during default method and itable processing for >>> interfaces.? These methods need to be skipped over because of the >>> interface method resolution rules in JVM Spec 9, section 5.4.3.4 >>> : >>> >>> ?? 3. Otherwise, if the class|Object|declares a method with the name >>> ?? and descriptor specified by the interface method reference, which >>> ?? has its|ACC_PUBLIC|flag set and does not have its|ACC_STATIC|flag >>> ?? set, method lookup succeeds. >>> >>> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8154587/webrev/ >>> >>> JBS Bug:? https://bugs.openjdk.java.net/browse/JDK-8154587 >>> >>> The fix was tested with JCK lang and VM tests, JTReg hotspot and >>> many JTReg JDK tests, M5 tier1 - tier5 tests, and JPRT. >>> >>> Thanks, Harold >>> >> > From adinn at redhat.com Mon Dec 11 16:09:56 2017 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 11 Dec 2017 16:09:56 +0000 Subject: RFR (M) 8186903: Remove j-types from Atomic In-Reply-To: References: <301ab272-399d-3f42-ee2f-15b3790e320c@redhat.com> Message-ID: <086b8ce4-9c87-6e47-b997-0a321b10f9bd@redhat.com> Hi Coleen, On 11/12/17 09:20, Andrew Dinn wrote: > I'll need to rerun with/without your change just to check whether it > really is the culprit. The failures I saw were nothing to do with your change. I'll pursue them separately. So, the patch builds and runs ok on AArch64 (n.b this is an AArch64 build not an arm build). regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From coleen.phillimore at oracle.com Mon Dec 11 16:13:03 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 11 Dec 2017 11:13:03 -0500 Subject: RFR (M) 8186903: Remove j-types from Atomic In-Reply-To: <086b8ce4-9c87-6e47-b997-0a321b10f9bd@redhat.com> References: <301ab272-399d-3f42-ee2f-15b3790e320c@redhat.com> <086b8ce4-9c87-6e47-b997-0a321b10f9bd@redhat.com> Message-ID: <3f4da9dc-2f8c-1270-d990-80c178f1d392@oracle.com> On 12/11/17 11:09 AM, Andrew Dinn wrote: > Hi Coleen, > > On 11/12/17 09:20, Andrew Dinn wrote: >> I'll need to rerun with/without your change just to check whether it >> really is the culprit. > The failures I saw were nothing to do with your change. I'll pursue them > separately. > > So, the patch builds and runs ok on AArch64 (n.b this is an AArch64 > build not an arm build). Great, thank you for running these tests. Coleen > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander > From karen.kinnear at oracle.com Mon Dec 11 17:58:20 2017 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Mon, 11 Dec 2017 12:58:20 -0500 Subject: RFR 8154587: Resolution fails for default method named 'clone' In-Reply-To: References: <22c41169-4c42-bff3-5090-a27ad9019bff@oracle.com> <3c0ff7a5-1a46-f4d9-c50a-6e6b322fdabc@oracle.com> <137ddf56-0f1e-ae10-3884-97a39fd92eeb@oracle.com> Message-ID: Harold, Ship It! Many many hanks for figuring out all the details of this corner case and for all the work to write the additional tests. Minor requests: 1) cpCache.cpp: can you change the assertion text to say ?Calling non-public method in Object with invokeinterface? so we don?t have to change it as confusing when we add nestmates and allow general calling of non-public methods in invokeinterface 2. defaultHashCode.jasm Summary: change ?overloaded? to ?local? I don?t need to see it again. thanks, Karen > On Dec 11, 2017, at 10:34 AM, harold seigel wrote: > > Hi, > > Please review this updated webrev for bug JDK-8154587: > > http://cr.openjdk.java.net/~hseigel/bug_8154587.2/webrev/ > > The main differences from the previous webrev are: > > 1. Improved comments and code changes to klassVtable.cpp and > klassVtable.hpp > 2. Added an assert to cpCache.cpp > 3. Added new tests. The purpose of many these tests, including the > .../clone/invokevirtual/ tests, is to check for regressions. > > These changes were regression tested with the tests listed below plus tonga tests. > > Thanks, Harold > > On 12/6/2017 8:49 AM, harold seigel wrote: >> Hi Lois, >> >> Thanks for the review. I'll add these tests in the next iteration of this webrev. >> >> >> - a test where class C does not define the method "clone", an IAE should result, correct? >> >> Yes, the test throws an IAE. >> >> Harold >> >> >> On 12/4/2017 2:31 PM, Lois Foltan wrote: >>> Hi Harold, >>> >>> Fix looks good. I would like to see three more test cases: >>> >>> - the same test written for "finalize" since that is also a non-public method of Object. >>> - a test where class C does not define the method "clone", an IAE should result, correct? >>> - a test case where I2 defines a public method of Object >>> >>> Thanks, >>> Lois >>> >>> On 11/30/2017 11:15 AM, harold seigel wrote: >>>> Hi, >>>> >>>> Please review this fix for JDK-8154587. The fix adds additional special casing to skip over non-public methods in class java.lang.Object during default method and itable processing for interfaces. These methods need to be skipped over because of the interface method resolution rules in JVM Spec 9, section 5.4.3.4 : >>>> >>>> 3. Otherwise, if the class|Object|declares a method with the name >>>> and descriptor specified by the interface method reference, which >>>> has its|ACC_PUBLIC|flag set and does not have its|ACC_STATIC|flag >>>> set, method lookup succeeds. >>>> >>>> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8154587/webrev/ >>>> >>>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8154587 >>>> >>>> The fix was tested with JCK lang and VM tests, JTReg hotspot and many JTReg JDK tests, M5 tier1 - tier5 tests, and JPRT. >>>> >>>> Thanks, Harold >>>> >>> >> > From harold.seigel at oracle.com Mon Dec 11 18:10:15 2017 From: harold.seigel at oracle.com (harold seigel) Date: Mon, 11 Dec 2017 13:10:15 -0500 Subject: RFR 8154587: Resolution fails for default method named 'clone' In-Reply-To: References: <22c41169-4c42-bff3-5090-a27ad9019bff@oracle.com> <3c0ff7a5-1a46-f4d9-c50a-6e6b322fdabc@oracle.com> <137ddf56-0f1e-ae10-3884-97a39fd92eeb@oracle.com> Message-ID: <06126ddf-987e-56df-26c0-00dc8645726c@oracle.com> Thanks Karen for the review and for all your help! Harold On 12/11/2017 12:58 PM, Karen Kinnear wrote: > Harold, > > Ship It! > > Many many hanks for figuring out all the details of this corner case and for all the work > to write the additional tests. > > Minor requests: > > 1) cpCache.cpp: can you change the assertion text to say ?Calling non-public method in Object with invokeinterface? so > we don?t have to change it as confusing when we add nestmates and allow general calling of non-public methods in > invokeinterface > > 2. defaultHashCode.jasm > Summary: change ?overloaded? to ?local? > > I don?t need to see it again. > > thanks, > Karen > >> On Dec 11, 2017, at 10:34 AM, harold seigel wrote: >> >> Hi, >> >> Please review this updated webrev for bug JDK-8154587: >> >> http://cr.openjdk.java.net/~hseigel/bug_8154587.2/webrev/ >> >> The main differences from the previous webrev are: >> >> 1. Improved comments and code changes to klassVtable.cpp and >> klassVtable.hpp >> 2. Added an assert to cpCache.cpp >> 3. Added new tests. The purpose of many these tests, including the >> .../clone/invokevirtual/ tests, is to check for regressions. >> >> These changes were regression tested with the tests listed below plus tonga tests. >> >> Thanks, Harold >> >> On 12/6/2017 8:49 AM, harold seigel wrote: >>> Hi Lois, >>> >>> Thanks for the review. I'll add these tests in the next iteration of this webrev. >>> >>>>> - a test where class C does not define the method "clone", an IAE should result, correct? >>> Yes, the test throws an IAE. >>> >>> Harold >>> >>> >>> On 12/4/2017 2:31 PM, Lois Foltan wrote: >>>> Hi Harold, >>>> >>>> Fix looks good. I would like to see three more test cases: >>>> >>>> - the same test written for "finalize" since that is also a non-public method of Object. >>>> - a test where class C does not define the method "clone", an IAE should result, correct? >>>> - a test case where I2 defines a public method of Object >>>> >>>> Thanks, >>>> Lois >>>> >>>> On 11/30/2017 11:15 AM, harold seigel wrote: >>>>> Hi, >>>>> >>>>> Please review this fix for JDK-8154587. The fix adds additional special casing to skip over non-public methods in class java.lang.Object during default method and itable processing for interfaces. These methods need to be skipped over because of the interface method resolution rules in JVM Spec 9, section 5.4.3.4 : >>>>> >>>>> 3. Otherwise, if the class|Object|declares a method with the name >>>>> and descriptor specified by the interface method reference, which >>>>> has its|ACC_PUBLIC|flag set and does not have its|ACC_STATIC|flag >>>>> set, method lookup succeeds. >>>>> >>>>> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8154587/webrev/ >>>>> >>>>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8154587 >>>>> >>>>> The fix was tested with JCK lang and VM tests, JTReg hotspot and many JTReg JDK tests, M5 tier1 - tier5 tests, and JPRT. >>>>> >>>>> Thanks, Harold >>>>> From coleen.phillimore at oracle.com Mon Dec 11 18:42:03 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 11 Dec 2017 13:42:03 -0500 Subject: RFR 8167372: Add code to check for getting oops while thread is in native In-Reply-To: References: <96631f21-5266-59a7-bd70-cfbb2d7dfa37@redhat.com> Message-ID: <33a05c7b-0c4b-3e7e-5058-3b771dc8dba5@oracle.com> Harold, This looks good. thanks! Coleen On 11/29/17 8:40 AM, harold seigel wrote: > Please review this updated webrev that adds the assert suggested below > by Aleksey. > > http://cr.openjdk.java.net/~hseigel/bug_8167372.2/webrev/index.html > > This update was re-tested with the same tests as the original webrev. > > Note that this change will be pushed post JDK-10. > > Thanks, Harold > > > On 11/16/2017 10:06 AM, Aleksey Shipilev wrote: >> On 11/16/2017 02:38 PM, harold seigel wrote: >>> Hi, >>> >>> Please review this JDK-10 enhancement for bug JDK-8167372.? As >>> described in the bug, this fix helps >>> check for naked oops.? The fix was tested with JCK lang and VM >>> tests, JTReg hotspot and many JTReg >>> JDK tests, M5 tier1 - tier5 tests, and JPRT. >>> >>> Open Webrev: >>> http://cr.openjdk.java.net/~hseigel/bug_8167372/webrev/index.html >> This looks good. >> >> It probably makes sense to assert that JNIHandle::resolve path that >> unpacks the naked oops also has >> thread in proper state? This would expose failures like in >> JDK-8191227 [1] better. >> >> Thanks, >> -Aleksey >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8191227 >> > From harold.seigel at oracle.com Mon Dec 11 18:44:15 2017 From: harold.seigel at oracle.com (harold seigel) Date: Mon, 11 Dec 2017 13:44:15 -0500 Subject: RFR 8167372: Add code to check for getting oops while thread is in native In-Reply-To: <33a05c7b-0c4b-3e7e-5058-3b771dc8dba5@oracle.com> References: <96631f21-5266-59a7-bd70-cfbb2d7dfa37@redhat.com> <33a05c7b-0c4b-3e7e-5058-3b771dc8dba5@oracle.com> Message-ID: <422c87b7-e042-178e-c60d-e65ddd3ca566@oracle.com> Thanks Coleen! Harold On 12/11/2017 1:42 PM, coleen.phillimore at oracle.com wrote: > Harold, > This looks good. > thanks! > Coleen > > On 11/29/17 8:40 AM, harold seigel wrote: >> Please review this updated webrev that adds the assert suggested >> below by Aleksey. >> >> http://cr.openjdk.java.net/~hseigel/bug_8167372.2/webrev/index.html >> >> This update was re-tested with the same tests as the original webrev. >> >> Note that this change will be pushed post JDK-10. >> >> Thanks, Harold >> >> >> On 11/16/2017 10:06 AM, Aleksey Shipilev wrote: >>> On 11/16/2017 02:38 PM, harold seigel wrote: >>>> Hi, >>>> >>>> Please review this JDK-10 enhancement for bug JDK-8167372. As >>>> described in the bug, this fix helps >>>> check for naked oops.? The fix was tested with JCK lang and VM >>>> tests, JTReg hotspot and many JTReg >>>> JDK tests, M5 tier1 - tier5 tests, and JPRT. >>>> >>>> Open Webrev: >>>> http://cr.openjdk.java.net/~hseigel/bug_8167372/webrev/index.html >>> This looks good. >>> >>> It probably makes sense to assert that JNIHandle::resolve path that >>> unpacks the naked oops also has >>> thread in proper state? This would expose failures like in >>> JDK-8191227 [1] better. >>> >>> Thanks, >>> -Aleksey >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8191227 >>> >> > From harold.seigel at oracle.com Mon Dec 11 18:54:06 2017 From: harold.seigel at oracle.com (harold seigel) Date: Mon, 11 Dec 2017 13:54:06 -0500 Subject: RFR 8154587: Resolution fails for default method named 'clone' In-Reply-To: References: <22c41169-4c42-bff3-5090-a27ad9019bff@oracle.com> <3c0ff7a5-1a46-f4d9-c50a-6e6b322fdabc@oracle.com> <137ddf56-0f1e-ae10-3884-97a39fd92eeb@oracle.com> Message-ID: Thanks Lois! Harold On 12/11/2017 1:52 PM, Lois Foltan wrote: > Looks good!? Thanks for all the additional testing. > Lois > > On 12/11/2017 10:34 AM, harold seigel wrote: >> Hi, >> >> Please review this updated webrev for bug JDK-8154587: >> >> ?? http://cr.openjdk.java.net/~hseigel/bug_8154587.2/webrev/ >> >> The main differences from the previous webrev are: >> >> 1. Improved comments and code changes to klassVtable.cpp and >> ?? klassVtable.hpp >> 2. Added an assert to cpCache.cpp >> 3. Added new tests.? The purpose of many these tests, including the >> ?? .../clone/invokevirtual/ tests, is to check for regressions. >> >> These changes were regression tested with the tests listed below plus >> tonga tests. >> >> Thanks, Harold >> >> On 12/6/2017 8:49 AM, harold seigel wrote: >>> Hi Lois, >>> >>> Thanks for the review.? I'll add these tests in the next iteration >>> of this webrev. >>> >>> >> - a test where class C does not define the method "clone", an IAE >>> should result, correct? >>> >>> Yes, the test throws an IAE. >>> >>> Harold >>> >>> >>> On 12/4/2017 2:31 PM, Lois Foltan wrote: >>>> Hi Harold, >>>> >>>> Fix looks good.? I would like to see three more test cases: >>>> >>>> ??? - the same test written for "finalize" since that is also a >>>> non-public method of Object. >>>> ??? - a test where class C does not define the method "clone", an >>>> IAE should result, correct? >>>> ??? - a test case where I2 defines a public method of Object >>>> >>>> Thanks, >>>> Lois >>>> >>>> On 11/30/2017 11:15 AM, harold seigel wrote: >>>>> Hi, >>>>> >>>>> Please review this fix for JDK-8154587.? The fix adds additional >>>>> special casing to skip over non-public methods in class >>>>> java.lang.Object during default method and itable processing for >>>>> interfaces.? These methods need to be skipped over because of the >>>>> interface method resolution rules in JVM Spec 9, section 5.4.3.4 >>>>> : >>>>> >>>>> ?? 3. Otherwise, if the class|Object|declares a method with the name >>>>> ?? and descriptor specified by the interface method reference, which >>>>> ?? has its|ACC_PUBLIC|flag set and does not have its|ACC_STATIC|flag >>>>> ?? set, method lookup succeeds. >>>>> >>>>> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8154587/webrev/ >>>>> >>>>> JBS Bug:? https://bugs.openjdk.java.net/browse/JDK-8154587 >>>>> >>>>> The fix was tested with JCK lang and VM tests, JTReg hotspot and >>>>> many JTReg JDK tests, M5 tier1 - tier5 tests, and JPRT. >>>>> >>>>> Thanks, Harold >>>>> >>>> >>> >> > From lois.foltan at oracle.com Mon Dec 11 18:52:38 2017 From: lois.foltan at oracle.com (Lois Foltan) Date: Mon, 11 Dec 2017 13:52:38 -0500 Subject: RFR 8154587: Resolution fails for default method named 'clone' In-Reply-To: References: <22c41169-4c42-bff3-5090-a27ad9019bff@oracle.com> <3c0ff7a5-1a46-f4d9-c50a-6e6b322fdabc@oracle.com> <137ddf56-0f1e-ae10-3884-97a39fd92eeb@oracle.com> Message-ID: Looks good!? Thanks for all the additional testing. Lois On 12/11/2017 10:34 AM, harold seigel wrote: > Hi, > > Please review this updated webrev for bug JDK-8154587: > > ?? http://cr.openjdk.java.net/~hseigel/bug_8154587.2/webrev/ > > The main differences from the previous webrev are: > > 1. Improved comments and code changes to klassVtable.cpp and > ?? klassVtable.hpp > 2. Added an assert to cpCache.cpp > 3. Added new tests.? The purpose of many these tests, including the > ?? .../clone/invokevirtual/ tests, is to check for regressions. > > These changes were regression tested with the tests listed below plus > tonga tests. > > Thanks, Harold > > On 12/6/2017 8:49 AM, harold seigel wrote: >> Hi Lois, >> >> Thanks for the review.? I'll add these tests in the next iteration of >> this webrev. >> >> >> - a test where class C does not define the method "clone", an IAE >> should result, correct? >> >> Yes, the test throws an IAE. >> >> Harold >> >> >> On 12/4/2017 2:31 PM, Lois Foltan wrote: >>> Hi Harold, >>> >>> Fix looks good.? I would like to see three more test cases: >>> >>> ??? - the same test written for "finalize" since that is also a >>> non-public method of Object. >>> ??? - a test where class C does not define the method "clone", an >>> IAE should result, correct? >>> ??? - a test case where I2 defines a public method of Object >>> >>> Thanks, >>> Lois >>> >>> On 11/30/2017 11:15 AM, harold seigel wrote: >>>> Hi, >>>> >>>> Please review this fix for JDK-8154587.? The fix adds additional >>>> special casing to skip over non-public methods in class >>>> java.lang.Object during default method and itable processing for >>>> interfaces.? These methods need to be skipped over because of the >>>> interface method resolution rules in JVM Spec 9, section 5.4.3.4 >>>> : >>>> >>>> ?? 3. Otherwise, if the class|Object|declares a method with the name >>>> ?? and descriptor specified by the interface method reference, which >>>> ?? has its|ACC_PUBLIC|flag set and does not have its|ACC_STATIC|flag >>>> ?? set, method lookup succeeds. >>>> >>>> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8154587/webrev/ >>>> >>>> JBS Bug:? https://bugs.openjdk.java.net/browse/JDK-8154587 >>>> >>>> The fix was tested with JCK lang and VM tests, JTReg hotspot and >>>> many JTReg JDK tests, M5 tier1 - tier5 tests, and JPRT. >>>> >>>> Thanks, Harold >>>> >>> >> > From jiangli.zhou at oracle.com Mon Dec 11 18:49:04 2017 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Mon, 11 Dec 2017 10:49:04 -0800 Subject: RFR 8167372: Add code to check for getting oops while thread is in native In-Reply-To: References: <96631f21-5266-59a7-bd70-cfbb2d7dfa37@redhat.com> Message-ID: <49DDCE56-EE7F-4781-91D7-8BFCE05F0689@oracle.com> Hi Harold, Looks good. Thanks, Jiangli > On Nov 29, 2017, at 5:40 AM, harold seigel wrote: > > Please review this updated webrev that adds the assert suggested below by Aleksey. > > http://cr.openjdk.java.net/~hseigel/bug_8167372.2/webrev/index.html > > This update was re-tested with the same tests as the original webrev. > > Note that this change will be pushed post JDK-10. > > Thanks, Harold > > > On 11/16/2017 10:06 AM, Aleksey Shipilev wrote: >> On 11/16/2017 02:38 PM, harold seigel wrote: >>> Hi, >>> >>> Please review this JDK-10 enhancement for bug JDK-8167372. As described in the bug, this fix helps >>> check for naked oops. The fix was tested with JCK lang and VM tests, JTReg hotspot and many JTReg >>> JDK tests, M5 tier1 - tier5 tests, and JPRT. >>> >>> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8167372/webrev/index.html >> This looks good. >> >> It probably makes sense to assert that JNIHandle::resolve path that unpacks the naked oops also has >> thread in proper state? This would expose failures like in JDK-8191227 [1] better. >> >> Thanks, >> -Aleksey >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8191227 >> > From harold.seigel at oracle.com Mon Dec 11 18:49:45 2017 From: harold.seigel at oracle.com (harold seigel) Date: Mon, 11 Dec 2017 13:49:45 -0500 Subject: RFR 8167372: Add code to check for getting oops while thread is in native In-Reply-To: <49DDCE56-EE7F-4781-91D7-8BFCE05F0689@oracle.com> References: <96631f21-5266-59a7-bd70-cfbb2d7dfa37@redhat.com> <49DDCE56-EE7F-4781-91D7-8BFCE05F0689@oracle.com> Message-ID: <3829cbb1-2e51-2585-5a1f-35ed18af33fa@oracle.com> Thanks Jiangli! Harold On 12/11/2017 1:49 PM, Jiangli Zhou wrote: > Hi Harold, > > Looks good. > > Thanks, > Jiangli > >> On Nov 29, 2017, at 5:40 AM, harold seigel wrote: >> >> Please review this updated webrev that adds the assert suggested below by Aleksey. >> >> http://cr.openjdk.java.net/~hseigel/bug_8167372.2/webrev/index.html >> >> This update was re-tested with the same tests as the original webrev. >> >> Note that this change will be pushed post JDK-10. >> >> Thanks, Harold >> >> >> On 11/16/2017 10:06 AM, Aleksey Shipilev wrote: >>> On 11/16/2017 02:38 PM, harold seigel wrote: >>>> Hi, >>>> >>>> Please review this JDK-10 enhancement for bug JDK-8167372. As described in the bug, this fix helps >>>> check for naked oops. The fix was tested with JCK lang and VM tests, JTReg hotspot and many JTReg >>>> JDK tests, M5 tier1 - tier5 tests, and JPRT. >>>> >>>> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8167372/webrev/index.html >>> This looks good. >>> >>> It probably makes sense to assert that JNIHandle::resolve path that unpacks the naked oops also has >>> thread in proper state? This would expose failures like in JDK-8191227 [1] better. >>> >>> Thanks, >>> -Aleksey >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8191227 >>> From david.holmes at oracle.com Mon Dec 11 22:18:44 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Dec 2017 08:18:44 +1000 Subject: RFR: 8193222: EnsureLocalCapacity() should maintain capacity requests through multiple calls In-Reply-To: <8428e54c-aa5d-07a2-b269-d79f6f41a819@oracle.com> References: <8428e54c-aa5d-07a2-b269-d79f6f41a819@oracle.com> Message-ID: <408bd5f5-042c-b6fd-fe5e-30b89cbed822@oracle.com> Ping! Very simple, and trying to get in before cutoff. Thanks, David On 10/12/2017 3:39 PM, David Holmes wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8193222 > webrev: http://cr.openjdk.java.net/~dholmes/8193222/webrev/ > > In product mode, for hotspot, EnsureLocalCapacity is a no-op as there is > no artificial limit applied for local refs. > > With -Xcheck:jni the checked mode was augmented to watch for "excessive" > use of local refs and to produce a warning if that happened e.g.: > > ?WARNING: JNI local refs: 41, exceeds capacity: 40 > > That was added under JDK-8043224. > > The problem is that the code always modifies the planned capacity (that > expected before warnings should be used) without regard for the fact the > existing capacity may be higher than that requested. As a result if you > have a call chain like: > > void foo() {? // C code > ? env->EnsureLocalCapacity(60); // needs lots of local refs > ? ... > ? JNU_GetPlatformsString(...) > ????? env->EnsureLocalCapacity(5); // lower than 60! > ?? ... > ?? // create 60 local refs > } > > upon return the warning will be issued because the number of local refs > exceeds the most recent call to EnsureLocalCapacity. > > A simple fix is for EnsureLocalCapacity to only raise the planned > capacity, not lower it. That fits with the notion of "ensuring" there is > sufficient space - the function is not SetLocalcapacity. It also fits > with the way PushLocalFrame(capacity) increases the planned capacity by > "capacity" but PopLocalFrame does not reduce it again. > > New test added. > > Tested through JPRT. > > Thanks, > David From coleen.phillimore at oracle.com Mon Dec 11 22:27:54 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 11 Dec 2017 17:27:54 -0500 Subject: Make reserved_size for compressed class space and metaspace respect the ergo-initialized CompressedClassSpaceSize flag value In-Reply-To: References: Message-ID: <761f8e00-d0f1-2560-94e9-cf4c64b3c4a6@oracle.com> Oh, yes, and I don't see an open bug number for this issue.? Please open a bug. thanks, Coleen On 12/9/17 7:37 AM, Yasumasa Suenaga wrote: > Hi Man, > > Looks good, but you need to get a sponsor. > > > Thanks, > > Yasumasa > > > On 2017/12/09 11:57, Man Cao wrote: >> Hi Yasumasa, >> >> Thanks for the review! Although I think moving or not moving >> "CompressedClassSpaceSize = align_size_down_bounded()" are equivalent >> because of logic of alignment and FLAG_SET_ERGO, I made the change >> you suggested anyway. >> The new patch is attached and inlined below. >> >> >> --- old/src/hotspot/share/memory/metaspace.cpp2017-12-08 >> 18:42:48.960285998 -0800 >> +++ new/src/hotspot/share/memory/metaspace.cpp2017-12-08 >> 18:42:48.600288972 -0800 >> @@ -3322,7 +3322,6 @@ >> ?? ?MaxMetaspaceExpansion = align_down_bounded(MaxMetaspaceExpansion, >> _commit_alignment); >> ?? ?CompressedClassSpaceSize = >> align_down_bounded(CompressedClassSpaceSize, _reserve_alignment); >> -? set_compressed_class_space_size(CompressedClassSpaceSize); >> ?? ?// Initial virtual space size will be calculated at >> global_initialize() >> ?? ?size_t min_metaspace_sz = >> @@ -3341,6 +3340,7 @@ >> ?? ? ? ? ? ? ? ? ? ?min_metaspace_sz); >> ?? ?} >> +? set_compressed_class_space_size(CompressedClassSpaceSize); >> ??} >> ??void Metaspace::global_initialize() { >> >> >> Thanks, >> Man >> >> On Thu, Dec 7, 2017 at 9:44 PM, Yasumasa Suenaga > > wrote: >> >> ??? Hi Man, >> >> ??? CompressedClassSpaceSize might be modified by FLAG_SET_ERGO. >> ??? So I think you need to move set_compressed_class_space_size() only. >> >> >> ??? Thanks, >> >> ??? Yasumasa >> >> >> >> ??? 2017-12-08 3:42 GMT+09:00 Man Cao > >: >> ???? > Hello, >> ???? > >> ???? > This is a friendly ping. Could anyone review or sponsor this >> change? It's >> ???? > just a two-liner change. >> ???? > >> ???? > -Man >> ???? > >> ???? > On Thu, Nov 30, 2017 at 2:03 PM, Man Cao > > wrote: >> ???? >> >> ???? >> I realized that the email attachment is probably dropped by >> the mailing >> ???? >> list, so below is the inlined patch. >> ???? >> >> ???? >> --- old/src/hotspot/share/memory/metaspace.cpp 2017-11-29 >> ???? >> 14:56:59.017118444 -0800 >> ???? >> +++ new/src/hotspot/share/memory/metaspace.cpp 2017-11-29 >> ???? >> 14:56:58.657121375 -0800 >> ???? >> @@ -3321,9 +3321,6 @@ >> ???? >>? ? MinMetaspaceExpansion = >> align_down_bounded(MinMetaspaceExpansion, >> ???? >> _commit_alignment); >> ???? >>? ? MaxMetaspaceExpansion = >> align_down_bounded(MaxMetaspaceExpansion, >> ???? >> _commit_alignment); >> ???? >> >> ???? >> -? CompressedClassSpaceSize = >> align_down_bounded(CompressedClassSpaceSize, >> ???? >> _reserve_alignment); >> ???? >> - set_compressed_class_space_size(CompressedClassSpaceSize); >> ???? >> - >> ???? >>? ? // Initial virtual space size will be calculated at >> global_initialize() >> ???? >>? ? size_t min_metaspace_sz = >> ???? >>? ? ? ? VIRTUALSPACEMULTIPLIER * >> InitialBootClassLoaderMetaspaceSize; >> ???? >> @@ -3341,6 +3338,8 @@ >> ???? >>? ? ? ? ? ? ? ? ? ? min_metaspace_sz); >> ???? >>? ? } >> ???? >> >> ???? >> +? CompressedClassSpaceSize = >> align_down_bounded(CompressedClassSpaceSize, >> ???? >> _reserve_alignment); >> ???? >> + set_compressed_class_space_size(CompressedClassSpaceSize); >> ???? >>? } >> ???? >> >> ???? >>? void Metaspace::global_initialize() { >> ???? >> >> ???? >> Best, >> ???? >> Man >> ???? >> >> ???? >> On Wed, Nov 29, 2017 at 3:21 PM, Man Cao > > wrote: >> ???? >>> >> ???? >>> Hello, >> ???? >>> >> ???? >>> This patch is a follow-up fix for >> ???? >>> https://bugs.openjdk.java.net/browse/JDK-8087291 >> >> ???? >>> >> ???? >>> This patch moves the call to >> set_compressed_class_space_size() after the >> ???? >>> flag value for CompressedClassSpaceSize is ergo-initialized, >> fixing the >> ???? >>> issue that the reserved size for compressed class space and >> metaspace is >> ???? >>> excessively large when MaxMetaspaceSize is set to a small >> value. More >> ???? >>> discussion about it is available here: >> ???? >>> >> ???? >>> >> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-November/025200.html >> >> >> ???? >>> >> ???? >>> This code patch is attached. Could anyone review and/or >> sponsor this >> ???? >>> patch? >> ???? >>> >> ???? >>> Best, >> ???? >>> Man >> ???? >> >> ???? >> >> ???? > >> >> From coleen.phillimore at oracle.com Mon Dec 11 22:27:10 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 11 Dec 2017 17:27:10 -0500 Subject: Make reserved_size for compressed class space and metaspace respect the ergo-initialized CompressedClassSpaceSize flag value In-Reply-To: References: Message-ID: Hi this looks good and I will sponsor this with you as contributor using manc at google.com . Have you signed the contributor agreement or are covered by one? thanks, Coleen On 12/9/17 7:37 AM, Yasumasa Suenaga wrote: > Hi Man, > > Looks good, but you need to get a sponsor. > > > Thanks, > > Yasumasa > > > On 2017/12/09 11:57, Man Cao wrote: >> Hi Yasumasa, >> >> Thanks for the review! Although I think moving or not moving >> "CompressedClassSpaceSize = align_size_down_bounded()" are equivalent >> because of logic of alignment and FLAG_SET_ERGO, I made the change >> you suggested anyway. >> The new patch is attached and inlined below. >> >> >> --- old/src/hotspot/share/memory/metaspace.cpp2017-12-08 >> 18:42:48.960285998 -0800 >> +++ new/src/hotspot/share/memory/metaspace.cpp2017-12-08 >> 18:42:48.600288972 -0800 >> @@ -3322,7 +3322,6 @@ >> ?? ?MaxMetaspaceExpansion = align_down_bounded(MaxMetaspaceExpansion, >> _commit_alignment); >> ?? ?CompressedClassSpaceSize = >> align_down_bounded(CompressedClassSpaceSize, _reserve_alignment); >> -? set_compressed_class_space_size(CompressedClassSpaceSize); >> ?? ?// Initial virtual space size will be calculated at >> global_initialize() >> ?? ?size_t min_metaspace_sz = >> @@ -3341,6 +3340,7 @@ >> ?? ? ? ? ? ? ? ? ? ?min_metaspace_sz); >> ?? ?} >> +? set_compressed_class_space_size(CompressedClassSpaceSize); >> ??} >> ??void Metaspace::global_initialize() { >> >> >> Thanks, >> Man >> >> On Thu, Dec 7, 2017 at 9:44 PM, Yasumasa Suenaga > > wrote: >> >> ??? Hi Man, >> >> ??? CompressedClassSpaceSize might be modified by FLAG_SET_ERGO. >> ??? So I think you need to move set_compressed_class_space_size() only. >> >> >> ??? Thanks, >> >> ??? Yasumasa >> >> >> >> ??? 2017-12-08 3:42 GMT+09:00 Man Cao > >: >> ???? > Hello, >> ???? > >> ???? > This is a friendly ping. Could anyone review or sponsor this >> change? It's >> ???? > just a two-liner change. >> ???? > >> ???? > -Man >> ???? > >> ???? > On Thu, Nov 30, 2017 at 2:03 PM, Man Cao > > wrote: >> ???? >> >> ???? >> I realized that the email attachment is probably dropped by >> the mailing >> ???? >> list, so below is the inlined patch. >> ???? >> >> ???? >> --- old/src/hotspot/share/memory/metaspace.cpp 2017-11-29 >> ???? >> 14:56:59.017118444 -0800 >> ???? >> +++ new/src/hotspot/share/memory/metaspace.cpp 2017-11-29 >> ???? >> 14:56:58.657121375 -0800 >> ???? >> @@ -3321,9 +3321,6 @@ >> ???? >>? ? MinMetaspaceExpansion = >> align_down_bounded(MinMetaspaceExpansion, >> ???? >> _commit_alignment); >> ???? >>? ? MaxMetaspaceExpansion = >> align_down_bounded(MaxMetaspaceExpansion, >> ???? >> _commit_alignment); >> ???? >> >> ???? >> -? CompressedClassSpaceSize = >> align_down_bounded(CompressedClassSpaceSize, >> ???? >> _reserve_alignment); >> ???? >> - set_compressed_class_space_size(CompressedClassSpaceSize); >> ???? >> - >> ???? >>? ? // Initial virtual space size will be calculated at >> global_initialize() >> ???? >>? ? size_t min_metaspace_sz = >> ???? >>? ? ? ? VIRTUALSPACEMULTIPLIER * >> InitialBootClassLoaderMetaspaceSize; >> ???? >> @@ -3341,6 +3338,8 @@ >> ???? >>? ? ? ? ? ? ? ? ? ? min_metaspace_sz); >> ???? >>? ? } >> ???? >> >> ???? >> +? CompressedClassSpaceSize = >> align_down_bounded(CompressedClassSpaceSize, >> ???? >> _reserve_alignment); >> ???? >> + set_compressed_class_space_size(CompressedClassSpaceSize); >> ???? >>? } >> ???? >> >> ???? >>? void Metaspace::global_initialize() { >> ???? >> >> ???? >> Best, >> ???? >> Man >> ???? >> >> ???? >> On Wed, Nov 29, 2017 at 3:21 PM, Man Cao > > wrote: >> ???? >>> >> ???? >>> Hello, >> ???? >>> >> ???? >>> This patch is a follow-up fix for >> ???? >>> https://bugs.openjdk.java.net/browse/JDK-8087291 >> >> ???? >>> >> ???? >>> This patch moves the call to >> set_compressed_class_space_size() after the >> ???? >>> flag value for CompressedClassSpaceSize is ergo-initialized, >> fixing the >> ???? >>> issue that the reserved size for compressed class space and >> metaspace is >> ???? >>> excessively large when MaxMetaspaceSize is set to a small >> value. More >> ???? >>> discussion about it is available here: >> ???? >>> >> ???? >>> >> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-November/025200.html >> >> >> ???? >>> >> ???? >>> This code patch is attached. Could anyone review and/or >> sponsor this >> ???? >>> patch? >> ???? >>> >> ???? >>> Best, >> ???? >>> Man >> ???? >> >> ???? >> >> ???? > >> >> From coleen.phillimore at oracle.com Mon Dec 11 22:53:25 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 11 Dec 2017 17:53:25 -0500 Subject: RFR: 8193222: EnsureLocalCapacity() should maintain capacity requests through multiple calls In-Reply-To: <408bd5f5-042c-b6fd-fe5e-30b89cbed822@oracle.com> References: <8428e54c-aa5d-07a2-b269-d79f6f41a819@oracle.com> <408bd5f5-042c-b6fd-fe5e-30b89cbed822@oracle.com> Message-ID: <92d553cd-d1a0-38ac-14ea-1bcf06f2ff72@oracle.com> This looks good to me.? I've reviewed both the code and the test. Thanks, Coleen On 12/11/17 5:18 PM, David Holmes wrote: > Ping! Very simple, and trying to get in before cutoff. > > Thanks, > David > > On 10/12/2017 3:39 PM, David Holmes wrote: >> bug: https://bugs.openjdk.java.net/browse/JDK-8193222 >> webrev: http://cr.openjdk.java.net/~dholmes/8193222/webrev/ >> >> In product mode, for hotspot, EnsureLocalCapacity is a no-op as there >> is no artificial limit applied for local refs. >> >> With -Xcheck:jni the checked mode was augmented to watch for >> "excessive" use of local refs and to produce a warning if that >> happened e.g.: >> >> ??WARNING: JNI local refs: 41, exceeds capacity: 40 >> >> That was added under JDK-8043224. >> >> The problem is that the code always modifies the planned capacity >> (that expected before warnings should be used) without regard for the >> fact the existing capacity may be higher than that requested. As a >> result if you have a call chain like: >> >> void foo() {? // C code >> ?? env->EnsureLocalCapacity(60); // needs lots of local refs >> ?? ... >> ?? JNU_GetPlatformsString(...) >> ?????? env->EnsureLocalCapacity(5); // lower than 60! >> ??? ... >> ??? // create 60 local refs >> } >> >> upon return the warning will be issued because the number of local >> refs exceeds the most recent call to EnsureLocalCapacity. >> >> A simple fix is for EnsureLocalCapacity to only raise the planned >> capacity, not lower it. That fits with the notion of "ensuring" there >> is sufficient space - the function is not SetLocalcapacity. It also >> fits with the way PushLocalFrame(capacity) increases the planned >> capacity by "capacity" but PopLocalFrame does not reduce it again. >> >> New test added. >> >> Tested through JPRT. >> >> Thanks, >> David From manc at google.com Tue Dec 12 00:38:25 2017 From: manc at google.com (Man Cao) Date: Mon, 11 Dec 2017 16:38:25 -0800 Subject: Make reserved_size for compressed class space and metaspace respect the ergo-initialized CompressedClassSpaceSize flag value In-Reply-To: References: Message-ID: Hi Coleen, Thanks for sponsoring this patch! Yes, I'm covered by the agreement signed by Google Inc. [1] Could this patch be a part of https://bugs.openjdk.java.net/browse/JDK-8087291, as this is a simple follow-up fix? If not, could you or someone else create a bug, as I don't have an account to create one? [1] http://www.oracle.com/technetwork/community/oca-486395.html#g -Man On Mon, Dec 11, 2017 at 2:27 PM, wrote: > Hi this looks good and I will sponsor this with you as contributor using > manc at google.com . > > Have you signed the contributor agreement or are covered by one? > > thanks, > Coleen > > On 12/9/17 7:37 AM, Yasumasa Suenaga wrote: > >> Hi Man, >> >> Looks good, but you need to get a sponsor. >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2017/12/09 11:57, Man Cao wrote: >> >>> Hi Yasumasa, >>> >>> Thanks for the review! Although I think moving or not moving >>> "CompressedClassSpaceSize = align_size_down_bounded()" are equivalent >>> because of logic of alignment and FLAG_SET_ERGO, I made the change you >>> suggested anyway. >>> The new patch is attached and inlined below. >>> >>> >>> --- old/src/hotspot/share/memory/metaspace.cpp2017-12-08 >>> 18:42:48.960285998 -0800 >>> +++ new/src/hotspot/share/memory/metaspace.cpp2017-12-08 >>> 18:42:48.600288972 -0800 >>> @@ -3322,7 +3322,6 @@ >>> MaxMetaspaceExpansion = align_down_bounded(MaxMetaspaceExpansion, >>> _commit_alignment); >>> CompressedClassSpaceSize = align_down_bounded(CompressedClassSpaceSize, >>> _reserve_alignment); >>> - set_compressed_class_space_size(CompressedClassSpaceSize); >>> // Initial virtual space size will be calculated at >>> global_initialize() >>> size_t min_metaspace_sz = >>> @@ -3341,6 +3340,7 @@ >>> min_metaspace_sz); >>> } >>> + set_compressed_class_space_size(CompressedClassSpaceSize); >>> } >>> void Metaspace::global_initialize() { >>> >>> >>> Thanks, >>> Man >>> >>> On Thu, Dec 7, 2017 at 9:44 PM, Yasumasa Suenaga >> > wrote: >>> >>> Hi Man, >>> >>> CompressedClassSpaceSize might be modified by FLAG_SET_ERGO. >>> So I think you need to move set_compressed_class_space_size() only. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> >>> 2017-12-08 3:42 GMT+09:00 Man Cao >> manc at google.com>>: >>> > Hello, >>> > >>> > This is a friendly ping. Could anyone review or sponsor this >>> change? It's >>> > just a two-liner change. >>> > >>> > -Man >>> > >>> > On Thu, Nov 30, 2017 at 2:03 PM, Man Cao >> > wrote: >>> >> >>> >> I realized that the email attachment is probably dropped by the >>> mailing >>> >> list, so below is the inlined patch. >>> >> >>> >> --- old/src/hotspot/share/memory/metaspace.cpp 2017-11-29 >>> >> 14:56:59.017118444 -0800 >>> >> +++ new/src/hotspot/share/memory/metaspace.cpp 2017-11-29 >>> >> 14:56:58.657121375 -0800 >>> >> @@ -3321,9 +3321,6 @@ >>> >> MinMetaspaceExpansion = align_down_bounded(MinMetaspac >>> eExpansion, >>> >> _commit_alignment); >>> >> MaxMetaspaceExpansion = align_down_bounded(MaxMetaspac >>> eExpansion, >>> >> _commit_alignment); >>> >> >>> >> - CompressedClassSpaceSize = align_down_bounded(CompressedC >>> lassSpaceSize, >>> >> _reserve_alignment); >>> >> - set_compressed_class_space_size(CompressedClassSpaceSize); >>> >> - >>> >> // Initial virtual space size will be calculated at >>> global_initialize() >>> >> size_t min_metaspace_sz = >>> >> VIRTUALSPACEMULTIPLIER * InitialBootClassLoaderMetaspac >>> eSize; >>> >> @@ -3341,6 +3338,8 @@ >>> >> min_metaspace_sz); >>> >> } >>> >> >>> >> + CompressedClassSpaceSize = align_down_bounded(CompressedC >>> lassSpaceSize, >>> >> _reserve_alignment); >>> >> + set_compressed_class_space_size(CompressedClassSpaceSize); >>> >> } >>> >> >>> >> void Metaspace::global_initialize() { >>> >> >>> >> Best, >>> >> Man >>> >> >>> >> On Wed, Nov 29, 2017 at 3:21 PM, Man Cao >> > wrote: >>> >>> >>> >>> Hello, >>> >>> >>> >>> This patch is a follow-up fix for >>> >>> https://bugs.openjdk.java.net/browse/JDK-8087291 < >>> https://bugs.openjdk.java.net/browse/JDK-8087291> >>> >>> >>> >>> This patch moves the call to set_compressed_class_space_size() >>> after the >>> >>> flag value for CompressedClassSpaceSize is ergo-initialized, >>> fixing the >>> >>> issue that the reserved size for compressed class space and >>> metaspace is >>> >>> excessively large when MaxMetaspaceSize is set to a small >>> value. More >>> >>> discussion about it is available here: >>> >>> >>> >>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2 >>> 017-November/025200.html >> pipermail/hotspot-runtime-dev/2017-November/025200.html> >>> >>> >>> >>> This code patch is attached. Could anyone review and/or sponsor >>> this >>> >>> patch? >>> >>> >>> >>> Best, >>> >>> Man >>> >> >>> >> >>> > >>> >>> >>> > From daniel.daugherty at oracle.com Tue Dec 12 01:00:40 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 11 Dec 2017 20:00:40 -0500 Subject: RFR: 8193222: EnsureLocalCapacity() should maintain capacity requests through multiple calls In-Reply-To: <8428e54c-aa5d-07a2-b269-d79f6f41a819@oracle.com> References: <8428e54c-aa5d-07a2-b269-d79f6f41a819@oracle.com> Message-ID: <8fd7dcf0-1d36-810b-2aa5-160568b06bdc@oracle.com> On 12/10/17 12:39 AM, David Holmes wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8193222 > webrev: http://cr.openjdk.java.net/~dholmes/8193222/webrev/ make/test/JtregNativeHotspot.gmk ??? No comments. src/hotspot/share/prims/jniCheck.cpp ??? No comments. test/hotspot/jtreg/runtime/jni/checked/TestCheckedEnsureLocalCapacity.java ??? L42: ??? // If copies > capacity + warning-threshold then we still get a warning ??????? Nit: Needs a period at the end. ??? L75: ??????? //Warning ??????? Nit: Needs a space before 'W'. test/hotspot/jtreg/runtime/jni/checked/libTestCheckedEnsureLocalCapacity.c ??? No comment. Thumbs up! Your choice on whether to fix the nits. Don't need to see another webrev even if you do... Dan > > In product mode, for hotspot, EnsureLocalCapacity is a no-op as there > is no artificial limit applied for local refs. > > With -Xcheck:jni the checked mode was augmented to watch for > "excessive" use of local refs and to produce a warning if that > happened e.g.: > > ?WARNING: JNI local refs: 41, exceeds capacity: 40 > > That was added under JDK-8043224. > > The problem is that the code always modifies the planned capacity > (that expected before warnings should be used) without regard for the > fact the existing capacity may be higher than that requested. As a > result if you have a call chain like: > > void foo() {? // C code > ? env->EnsureLocalCapacity(60); // needs lots of local refs > ? ... > ? JNU_GetPlatformsString(...) > ????? env->EnsureLocalCapacity(5); // lower than 60! > ?? ... > ?? // create 60 local refs > } > > upon return the warning will be issued because the number of local > refs exceeds the most recent call to EnsureLocalCapacity. > > A simple fix is for EnsureLocalCapacity to only raise the planned > capacity, not lower it. That fits with the notion of "ensuring" there > is sufficient space - the function is not SetLocalcapacity. It also > fits with the way PushLocalFrame(capacity) increases the planned > capacity by "capacity" but PopLocalFrame does not reduce it again. > > New test added. > > Tested through JPRT. > > Thanks, > David > From david.holmes at oracle.com Tue Dec 12 01:18:11 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Dec 2017 11:18:11 +1000 Subject: RFR: 8193222: EnsureLocalCapacity() should maintain capacity requests through multiple calls In-Reply-To: <92d553cd-d1a0-38ac-14ea-1bcf06f2ff72@oracle.com> References: <8428e54c-aa5d-07a2-b269-d79f6f41a819@oracle.com> <408bd5f5-042c-b6fd-fe5e-30b89cbed822@oracle.com> <92d553cd-d1a0-38ac-14ea-1bcf06f2ff72@oracle.com> Message-ID: Thanks Coleen! David On 12/12/2017 8:53 AM, coleen.phillimore at oracle.com wrote: > > This looks good to me.? I've reviewed both the code and the test. > > Thanks, > Coleen > > On 12/11/17 5:18 PM, David Holmes wrote: >> Ping! Very simple, and trying to get in before cutoff. >> >> Thanks, >> David >> >> On 10/12/2017 3:39 PM, David Holmes wrote: >>> bug: https://bugs.openjdk.java.net/browse/JDK-8193222 >>> webrev: http://cr.openjdk.java.net/~dholmes/8193222/webrev/ >>> >>> In product mode, for hotspot, EnsureLocalCapacity is a no-op as there >>> is no artificial limit applied for local refs. >>> >>> With -Xcheck:jni the checked mode was augmented to watch for >>> "excessive" use of local refs and to produce a warning if that >>> happened e.g.: >>> >>> ??WARNING: JNI local refs: 41, exceeds capacity: 40 >>> >>> That was added under JDK-8043224. >>> >>> The problem is that the code always modifies the planned capacity >>> (that expected before warnings should be used) without regard for the >>> fact the existing capacity may be higher than that requested. As a >>> result if you have a call chain like: >>> >>> void foo() {? // C code >>> ?? env->EnsureLocalCapacity(60); // needs lots of local refs >>> ?? ... >>> ?? JNU_GetPlatformsString(...) >>> ?????? env->EnsureLocalCapacity(5); // lower than 60! >>> ??? ... >>> ??? // create 60 local refs >>> } >>> >>> upon return the warning will be issued because the number of local >>> refs exceeds the most recent call to EnsureLocalCapacity. >>> >>> A simple fix is for EnsureLocalCapacity to only raise the planned >>> capacity, not lower it. That fits with the notion of "ensuring" there >>> is sufficient space - the function is not SetLocalcapacity. It also >>> fits with the way PushLocalFrame(capacity) increases the planned >>> capacity by "capacity" but PopLocalFrame does not reduce it again. >>> >>> New test added. >>> >>> Tested through JPRT. >>> >>> Thanks, >>> David > From david.holmes at oracle.com Tue Dec 12 01:18:53 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 12 Dec 2017 11:18:53 +1000 Subject: RFR: 8193222: EnsureLocalCapacity() should maintain capacity requests through multiple calls In-Reply-To: <8fd7dcf0-1d36-810b-2aa5-160568b06bdc@oracle.com> References: <8428e54c-aa5d-07a2-b269-d79f6f41a819@oracle.com> <8fd7dcf0-1d36-810b-2aa5-160568b06bdc@oracle.com> Message-ID: Thanks Dan! Nits will be fixed. David On 12/12/2017 11:00 AM, Daniel D. Daugherty wrote: > On 12/10/17 12:39 AM, David Holmes wrote: >> bug: https://bugs.openjdk.java.net/browse/JDK-8193222 >> webrev: http://cr.openjdk.java.net/~dholmes/8193222/webrev/ > > make/test/JtregNativeHotspot.gmk > ??? No comments. > > src/hotspot/share/prims/jniCheck.cpp > ??? No comments. > > test/hotspot/jtreg/runtime/jni/checked/TestCheckedEnsureLocalCapacity.java > ??? L42: ??? // If copies > capacity + warning-threshold then we still > get a warning > ??????? Nit: Needs a period at the end. > > ??? L75: ??????? //Warning > ??????? Nit: Needs a space before 'W'. > > test/hotspot/jtreg/runtime/jni/checked/libTestCheckedEnsureLocalCapacity.c > ??? No comment. > > Thumbs up! Your choice on whether to fix the nits. > Don't need to see another webrev even if you do... > > Dan > > >> >> In product mode, for hotspot, EnsureLocalCapacity is a no-op as there >> is no artificial limit applied for local refs. >> >> With -Xcheck:jni the checked mode was augmented to watch for >> "excessive" use of local refs and to produce a warning if that >> happened e.g.: >> >> ?WARNING: JNI local refs: 41, exceeds capacity: 40 >> >> That was added under JDK-8043224. >> >> The problem is that the code always modifies the planned capacity >> (that expected before warnings should be used) without regard for the >> fact the existing capacity may be higher than that requested. As a >> result if you have a call chain like: >> >> void foo() {? // C code >> ? env->EnsureLocalCapacity(60); // needs lots of local refs >> ? ... >> ? JNU_GetPlatformsString(...) >> ????? env->EnsureLocalCapacity(5); // lower than 60! >> ?? ... >> ?? // create 60 local refs >> } >> >> upon return the warning will be issued because the number of local >> refs exceeds the most recent call to EnsureLocalCapacity. >> >> A simple fix is for EnsureLocalCapacity to only raise the planned >> capacity, not lower it. That fits with the notion of "ensuring" there >> is sufficient space - the function is not SetLocalcapacity. It also >> fits with the way PushLocalFrame(capacity) increases the planned >> capacity by "capacity" but PopLocalFrame does not reduce it again. >> >> New test added. >> >> Tested through JPRT. >> >> Thanks, >> David >> > From coleen.phillimore at oracle.com Tue Dec 12 16:29:16 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 12 Dec 2017 11:29:16 -0500 Subject: Make reserved_size for compressed class space and metaspace respect the ergo-initialized CompressedClassSpaceSize flag value In-Reply-To: References: Message-ID: <216e433b-d582-dac5-b534-17355182ca29@oracle.com> Man, It has to be a new bug.? I filed bug: https://bugs.openjdk.java.net/browse/JDK-8193386 and will sponsor this. thank you, Coleen On 12/11/17 7:38 PM, Man Cao wrote: > Hi Coleen, > > Thanks for sponsoring this patch! Yes, I'm covered by the agreement > signed by Google Inc. [1] > Could this patch be a part of > https://bugs.openjdk.java.net/browse/JDK-8087291, as this is a simple > follow-up fix? > If not, could you or someone else create a bug, as I don't have an > account to create one? > > [1] http://www.oracle.com/technetwork/community/oca-486395.html#g > > > -Man > > On Mon, Dec 11, 2017 at 2:27 PM, > wrote: > > Hi this looks good and I will sponsor this with you as contributor > using manc at google.com . > > Have you signed the contributor agreement or are covered by one? > > thanks, > Coleen > > On 12/9/17 7:37 AM, Yasumasa Suenaga wrote: > > Hi Man, > > Looks good, but you need to get a sponsor. > > > Thanks, > > Yasumasa > > > On 2017/12/09 11:57, Man Cao wrote: > > Hi Yasumasa, > > Thanks for the review! Although I think moving or not > moving "CompressedClassSpaceSize = > align_size_down_bounded()" are equivalent because of logic > of alignment and FLAG_SET_ERGO, I made the change you > suggested anyway. > The new patch is attached and inlined below. > > > --- old/src/hotspot/share/memory/metaspace.cpp2017-12-08 > 18:42:48.960285998 -0800 > +++ new/src/hotspot/share/memory/metaspace.cpp2017-12-08 > 18:42:48.600288972 -0800 > @@ -3322,7 +3322,6 @@ > ?? ?MaxMetaspaceExpansion = > align_down_bounded(MaxMetaspaceExpansion, _commit_alignment); > ?? ?CompressedClassSpaceSize = > align_down_bounded(CompressedClassSpaceSize, > _reserve_alignment); > -? set_compressed_class_space_size(CompressedClassSpaceSize); > ?? ?// Initial virtual space size will be calculated at > global_initialize() > ?? ?size_t min_metaspace_sz = > @@ -3341,6 +3340,7 @@ > ?? ? ? ? ? ? ? ? ? ?min_metaspace_sz); > ?? ?} > +? set_compressed_class_space_size(CompressedClassSpaceSize); > ??} > ??void Metaspace::global_initialize() { > > > Thanks, > Man > > On Thu, Dec 7, 2017 at 9:44 PM, Yasumasa Suenaga > > >> > wrote: > > ??? Hi Man, > > ??? CompressedClassSpaceSize might be modified by > FLAG_SET_ERGO. > ??? So I think you need to move > set_compressed_class_space_size() only. > > > ??? Thanks, > > ??? Yasumasa > > > > ??? 2017-12-08 3:42 GMT+09:00 Man Cao >>: > ???? > Hello, > ???? > > ???? > This is a friendly ping. Could anyone review or > sponsor this change? It's > ???? > just a two-liner change. > ???? > > ???? > -Man > ???? > > ???? > On Thu, Nov 30, 2017 at 2:03 PM, Man Cao > > >> wrote: > ???? >> > ???? >> I realized that the email attachment is probably > dropped by the mailing > ???? >> list, so below is the inlined patch. > ???? >> > ???? >> --- old/src/hotspot/share/memory/metaspace.cpp > 2017-11-29 > ???? >> 14:56:59.017118444 -0800 > ???? >> +++ new/src/hotspot/share/memory/metaspace.cpp > 2017-11-29 > ???? >> 14:56:58.657121375 -0800 > ???? >> @@ -3321,9 +3321,6 @@ > ???? >>? ? MinMetaspaceExpansion = > align_down_bounded(MinMetaspaceExpansion, > ???? >> _commit_alignment); > ???? >>? ? MaxMetaspaceExpansion = > align_down_bounded(MaxMetaspaceExpansion, > ???? >> _commit_alignment); > ???? >> > ???? >> -? CompressedClassSpaceSize = > align_down_bounded(CompressedClassSpaceSize, > ???? >> _reserve_alignment); > ???? >> - > set_compressed_class_space_size(CompressedClassSpaceSize); > ???? >> - > ???? >>? ? // Initial virtual space size will be > calculated at global_initialize() > ???? >>? ? size_t min_metaspace_sz = > ???? >>? ? ? ? VIRTUALSPACEMULTIPLIER * > InitialBootClassLoaderMetaspaceSize; > ???? >> @@ -3341,6 +3338,8 @@ > ???? >> min_metaspace_sz); > ???? >>? ? } > ???? >> > ???? >> +? CompressedClassSpaceSize = > align_down_bounded(CompressedClassSpaceSize, > ???? >> _reserve_alignment); > ???? >> + > set_compressed_class_space_size(CompressedClassSpaceSize); > ???? >>? } > ???? >> > ???? >>? void Metaspace::global_initialize() { > ???? >> > ???? >> Best, > ???? >> Man > ???? >> > ???? >> On Wed, Nov 29, 2017 at 3:21 PM, Man Cao > > >> wrote: > ???? >>> > ???? >>> Hello, > ???? >>> > ???? >>> This patch is a follow-up fix for > ???? >>> https://bugs.openjdk.java.net/browse/JDK-8087291 > > > > ???? >>> > ???? >>> This patch moves the call to > set_compressed_class_space_size() after the > ???? >>> flag value for CompressedClassSpaceSize is > ergo-initialized, fixing the > ???? >>> issue that the reserved size for compressed class > space and metaspace is > ???? >>> excessively large when MaxMetaspaceSize is set to > a small value. More > ???? >>> discussion about it is available here: > ???? >>> > ???? >>> > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2017-November/025200.html > > > > > ???? >>> > ???? >>> This code patch is attached. Could anyone review > and/or sponsor this > ???? >>> patch? > ???? >>> > ???? >>> Best, > ???? >>> Man > ???? >> > ???? >> > ???? > > > > > From manc at google.com Tue Dec 12 19:04:48 2017 From: manc at google.com (Man Cao) Date: Tue, 12 Dec 2017 11:04:48 -0800 Subject: Make reserved_size for compressed class space and metaspace respect the ergo-initialized CompressedClassSpaceSize flag value In-Reply-To: <216e433b-d582-dac5-b534-17355182ca29@oracle.com> References: <216e433b-d582-dac5-b534-17355182ca29@oracle.com> Message-ID: Great! Thanks again! -Man On Tue, Dec 12, 2017 at 8:29 AM, wrote: > Man, It has to be a new bug. I filed bug: > https://bugs.openjdk.java.net/browse/JDK-8193386 > > and will sponsor this. > thank you, > Coleen > > > On 12/11/17 7:38 PM, Man Cao wrote: > > Hi Coleen, > > Thanks for sponsoring this patch! Yes, I'm covered by the agreement signed > by Google Inc. [1] > Could this patch be a part of https://bugs.openjdk.java.net/ > browse/JDK-8087291, as this is a simple follow-up fix? > If not, could you or someone else create a bug, as I don't have an account > to create one? > > [1] http://www.oracle.com/technetwork/community/oca-486395.html#g > > -Man > > On Mon, Dec 11, 2017 at 2:27 PM, wrote: > >> Hi this looks good and I will sponsor this with you as contributor using >> manc at google.com . >> >> Have you signed the contributor agreement or are covered by one? >> >> thanks, >> Coleen >> >> On 12/9/17 7:37 AM, Yasumasa Suenaga wrote: >> >>> Hi Man, >>> >>> Looks good, but you need to get a sponsor. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2017/12/09 11:57, Man Cao wrote: >>> >>>> Hi Yasumasa, >>>> >>>> Thanks for the review! Although I think moving or not moving >>>> "CompressedClassSpaceSize = align_size_down_bounded()" are equivalent >>>> because of logic of alignment and FLAG_SET_ERGO, I made the change you >>>> suggested anyway. >>>> The new patch is attached and inlined below. >>>> >>>> >>>> --- old/src/hotspot/share/memory/metaspace.cpp2017-12-08 >>>> 18:42:48.960285998 -0800 >>>> +++ new/src/hotspot/share/memory/metaspace.cpp2017-12-08 >>>> 18:42:48.600288972 -0800 >>>> @@ -3322,7 +3322,6 @@ >>>> MaxMetaspaceExpansion = align_down_bounded(MaxMetaspaceExpansion, >>>> _commit_alignment); >>>> CompressedClassSpaceSize = align_down_bounded(CompressedClassSpaceSize, >>>> _reserve_alignment); >>>> - set_compressed_class_space_size(CompressedClassSpaceSize); >>>> // Initial virtual space size will be calculated at >>>> global_initialize() >>>> size_t min_metaspace_sz = >>>> @@ -3341,6 +3340,7 @@ >>>> min_metaspace_sz); >>>> } >>>> + set_compressed_class_space_size(CompressedClassSpaceSize); >>>> } >>>> void Metaspace::global_initialize() { >>>> >>>> >>>> Thanks, >>>> Man >>>> >>>> On Thu, Dec 7, 2017 at 9:44 PM, Yasumasa Suenaga >>> > wrote: >>>> >>>> Hi Man, >>>> >>>> CompressedClassSpaceSize might be modified by FLAG_SET_ERGO. >>>> So I think you need to move set_compressed_class_space_size() only. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> >>>> 2017-12-08 3:42 GMT+09:00 Man Cao >>> manc at google.com>>: >>>> > Hello, >>>> > >>>> > This is a friendly ping. Could anyone review or sponsor this >>>> change? It's >>>> > just a two-liner change. >>>> > >>>> > -Man >>>> > >>>> > On Thu, Nov 30, 2017 at 2:03 PM, Man Cao >>> > wrote: >>>> >> >>>> >> I realized that the email attachment is probably dropped by the >>>> mailing >>>> >> list, so below is the inlined patch. >>>> >> >>>> >> --- old/src/hotspot/share/memory/metaspace.cpp 2017-11-29 >>>> >> 14:56:59.017118444 -0800 >>>> >> +++ new/src/hotspot/share/memory/metaspace.cpp 2017-11-29 >>>> >> 14:56:58.657121375 -0800 >>>> >> @@ -3321,9 +3321,6 @@ >>>> >> MinMetaspaceExpansion = align_down_bounded(MinMetaspac >>>> eExpansion, >>>> >> _commit_alignment); >>>> >> MaxMetaspaceExpansion = align_down_bounded(MaxMetaspac >>>> eExpansion, >>>> >> _commit_alignment); >>>> >> >>>> >> - CompressedClassSpaceSize = align_down_bounded(CompressedC >>>> lassSpaceSize, >>>> >> _reserve_alignment); >>>> >> - set_compressed_class_space_size(CompressedClassSpaceSize); >>>> >> - >>>> >> // Initial virtual space size will be calculated at >>>> global_initialize() >>>> >> size_t min_metaspace_sz = >>>> >> VIRTUALSPACEMULTIPLIER * InitialBootClassLoaderMetaspac >>>> eSize; >>>> >> @@ -3341,6 +3338,8 @@ >>>> >> min_metaspace_sz); >>>> >> } >>>> >> >>>> >> + CompressedClassSpaceSize = align_down_bounded(CompressedC >>>> lassSpaceSize, >>>> >> _reserve_alignment); >>>> >> + set_compressed_class_space_size(CompressedClassSpaceSize); >>>> >> } >>>> >> >>>> >> void Metaspace::global_initialize() { >>>> >> >>>> >> Best, >>>> >> Man >>>> >> >>>> >> On Wed, Nov 29, 2017 at 3:21 PM, Man Cao >>> > wrote: >>>> >>> >>>> >>> Hello, >>>> >>> >>>> >>> This patch is a follow-up fix for >>>> >>> https://bugs.openjdk.java.net/browse/JDK-8087291 < >>>> https://bugs.openjdk.java.net/browse/JDK-8087291> >>>> >>> >>>> >>> This patch moves the call to set_compressed_class_space_size() >>>> after the >>>> >>> flag value for CompressedClassSpaceSize is ergo-initialized, >>>> fixing the >>>> >>> issue that the reserved size for compressed class space and >>>> metaspace is >>>> >>> excessively large when MaxMetaspaceSize is set to a small >>>> value. More >>>> >>> discussion about it is available here: >>>> >>> >>>> >>> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2 >>>> 017-November/025200.html >>> pipermail/hotspot-runtime-dev/2017-November/025200.html> >>>> >>> >>>> >>> This code patch is attached. Could anyone review and/or >>>> sponsor this >>>> >>> patch? >>>> >>> >>>> >>> Best, >>>> >>> Man >>>> >> >>>> >> >>>> > >>>> >>>> >>>> >> > > From coleen.phillimore at oracle.com Tue Dec 12 22:14:01 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 12 Dec 2017 17:14:01 -0500 Subject: RFR (S): 8192003: Refactor weak references in StringTable to use the Access API In-Reply-To: <5A200B40.9060206@oracle.com> References: <5A1D93C1.3020605@oracle.com> <81e2ffcb-4912-9fc7-55d9-0553b737a695@oracle.com> <5A200B40.9060206@oracle.com> Message-ID: Hi Erik, This looks great.? Would obj_field_access<>() be a better name than obj_field_special<> since it's the access which is so special? Like in the other tables, it would be nice to disallow the literal() call for Hashtables so we don't mistakenly add one.? Can you declare a ShouldNotReachHere() literal function for these?? Or version with no body that would cause a linktime error? Thanks, Coleen On 11/30/17 8:44 AM, Erik ?sterlund wrote: > Hi Per, > > Thank you for reviewing this. > > New full webrev: > http://cr.openjdk.java.net/~eosterlund/8192003/webrev.01/ > > New incremental webrev: > http://cr.openjdk.java.net/~eosterlund/8192003/webrev.00_01/ > > On 2017-11-30 11:32, Per Liden wrote: >> Hi Erik, >> >> On 2017-11-28 17:50, Erik ?sterlund wrote: >>> Hi, >>> >>> The StringTable contains weak references to oops. Today the weak >>> semantics is managed using explicit calls to G1 SATB enqueue barriers. >>> >>> Now that the Access API is available, it should be used instead as >>> it is >>> more modular. >>> >>> This change fixes that by making these oops ON_PHANTOM_OOP_REF with a >>> corresponding AS_NO_KEEPALIVE accessor when we do not want to keep it >>> alive, much like my previous changes to other weak tables. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~eosterlund/8192003/webrev.00/ >> >> share/classfile/javaClasses.inline.hpp >> -------------------------------------- >> >> ? 57 typeArrayOop java_lang_String::value_no_keepalive(oop >> java_string) { >> ? 58?? assert(initialized && (value_offset > 0), "Must be initialized"); >> ? 59?? assert(is_instance(java_string), "must be java_string"); >> ? 60?? oop value = >> HeapAccess::oop_load_at(java_string, value_offset); >> ? 61?? return (typeArrayOop)value; >> ? 62 } >> >> How about pushing this barrier down to oopDesc, with a >> oopDesc::obj_field_special_access(...) function? > > Sounds doable. Fixed. (Although I called the method just > "obj_field_special", hope nobody minds...) > >> >> ? 76?? typeArrayOop value = >> java_lang_String::value_no_keepalive(java_string); >> ? 77?? assert(initialized, "Must be initialized"); >> ? 78?? assert(is_instance(java_string), "must be java_string"); >> >> Looks like you accidentally moved the value_no_keepalive() call above >> the asserts? > > Fixed. > >> >> share/classfile/stringTable.cpp >> ------------------------------- >> >> ?155?????? oop string = string_object_no_keepalive(l); >> ?156?????? if (java_lang_String::equals(string, name, len)) { >> ?157???????? return string_object(l); >> ?158?????? } >> >> Can we please add a comment here, saying that returning "string" >> would be very bad, or maybe even fold this a bit, so that no one will >> be tempted to ever return that value, something like: >> >> if (java_lang_String::equals(string_object_no_keepalive(l), name, >> len)) { >> ??? // Comment saying why we must call string_object() here... >> ??? return string_object(l); >> } > > Fixed. > > Thanks, > /Erik > >> cheers, >> Per >> >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8192003 >>> >>> Thanks, >>> /Erik > From mandy.chung at oracle.com Wed Dec 13 00:42:36 2017 From: mandy.chung at oracle.com (mandy chung) Date: Tue, 12 Dec 2017 16:42:36 -0800 Subject: Review Request JDK-8193325: StackFrameInfo::getByteCodeIndex returns wrong value if bci > 32767 Message-ID: <4cf575a1-d420-fb44-cc38-03287366ec3d@oracle.com> http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8193325/webrev.00/ This fixes the bug in hotspot that sets the bci field as int but it's of short type and also StackFrameInfo to return a proper bci value.? Coleen suggests not to change set_bci to take jushort but instead do the cast as in the proposed fix.? The VM is in favor of C++ types and stop propagation of Java types.? bci is of int in VM implementation and so be consistent. Mandy [1] mail.openjdk.java.net/pipermail/core-libs-dev/2017-December/050581.html From ioi.lam at oracle.com Wed Dec 13 00:41:52 2017 From: ioi.lam at oracle.com (Ioi Lam) Date: Tue, 12 Dec 2017 16:41:52 -0800 Subject: RFR(S) 8165603 - UseAppCDS.java failed to clean up files after test Message-ID: https://bugs.openjdk.java.net/browse/JDK-8165603 http://cr.openjdk.java.net/~iklam/jdk11/8165603-files-not-closed.v01/ Summary: The test case opens a temp file for reading without closing it explicitly. This causes jtreg agentvm mode testing on Windows to complain about failing to delete the temp file. The fix is to to put the opening of input/output streams in try-resource blocks, like ? try (BufferedReader br = ?????? new BufferedReader( ???????? new InputStreamReader( ????????? new FileInputStream(filename))) ? ) { ???? for (; ; ) { ?????? String line = br.readLine(); ???? ... ? } The streams will be closed when we leave the "try" block. Besides the test in the bug report, I fixed a few other files in similar ways. Testing -- HotSpot tier1/tier2 tests all passed. I verified that UseAppCDS.java is now executed on Windows and passed. I plan to push into the jdk/hs repo after the jdk 10 repo fork. Thanks - Ioi From david.holmes at oracle.com Wed Dec 13 01:24:55 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 13 Dec 2017 11:24:55 +1000 Subject: Review Request JDK-8193325: StackFrameInfo::getByteCodeIndex returns wrong value if bci > 32767 In-Reply-To: <4cf575a1-d420-fb44-cc38-03287366ec3d@oracle.com> References: <4cf575a1-d420-fb44-cc38-03287366ec3d@oracle.com> Message-ID: <8a326b47-176b-c41a-7fe1-d9d53f37bd5c@oracle.com> Hi Mandy, On 13/12/2017 10:42 AM, mandy chung wrote: > http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8193325/webrev.00/ > > This fixes the bug in hotspot that sets the bci field as int but it's of > short type and also StackFrameInfo to return a proper bci value.? Coleen > suggests not to change set_bci to take jushort but instead do the cast > as in the proposed fix.? The VM is in favor of C++ types and stop > propagation of Java types.? bci is of int in VM implementation and so be > consistent. I must admit I'm unclear why the VM needs the BCI to be an int when logically it is a jushort, but perhaps, as per getByteCodeIndex() it needs to be able to store "-1" to indicate no-bci? The fix itself seems fine, though if we're going to chop off the VM value at 16-bits perhaps we should assert that it isn't a value that requires > 16 bits? Thanks, David > > Mandy > [1] mail.openjdk.java.net/pipermail/core-libs-dev/2017-December/050581.html From david.holmes at oracle.com Wed Dec 13 01:28:42 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 13 Dec 2017 11:28:42 +1000 Subject: RFR(S) 8165603 - UseAppCDS.java failed to clean up files after test In-Reply-To: References: Message-ID: Looks good! Nice cleanup. Thanks, David On 13/12/2017 10:41 AM, Ioi Lam wrote: > https://bugs.openjdk.java.net/browse/JDK-8165603 > http://cr.openjdk.java.net/~iklam/jdk11/8165603-files-not-closed.v01/ > > Summary: > > The test case opens a temp file for reading without closing it > explicitly. This causes > jtreg agentvm mode testing on Windows to complain about failing to > delete the temp file. > > The fix is to to put the opening of input/output streams in try-resource > blocks, like > > ? try (BufferedReader br = > ?????? new BufferedReader( > ???????? new InputStreamReader( > ????????? new FileInputStream(filename))) > ? ) { > ???? for (; ; ) { > ?????? String line = br.readLine(); > ???? ... > ? } > > The streams will be closed when we leave the "try" block. > > Besides the test in the bug report, I fixed a few other files in similar > ways. > > Testing -- HotSpot tier1/tier2 tests all passed. I verified that > UseAppCDS.java > is now executed on Windows and passed. > > I plan to push into the jdk/hs repo after the jdk 10 repo fork. > > Thanks > - Ioi From john.r.rose at oracle.com Wed Dec 13 01:29:41 2017 From: john.r.rose at oracle.com (John Rose) Date: Tue, 12 Dec 2017 17:29:41 -0800 Subject: Review Request JDK-8193325: StackFrameInfo::getByteCodeIndex returns wrong value if bci > 32767 In-Reply-To: <8a326b47-176b-c41a-7fe1-d9d53f37bd5c@oracle.com> References: <4cf575a1-d420-fb44-cc38-03287366ec3d@oracle.com> <8a326b47-176b-c41a-7fe1-d9d53f37bd5c@oracle.com> Message-ID: <4E31CF3C-D7BF-4070-85F5-66D281478F6E@oracle.com> On Dec 12, 2017, at 5:24 PM, David Holmes wrote: > > as per getByteCodeIndex() it needs to be able to store "-1" to indicate no-bci? Yes, that's the essential requirement, to encode a "none" value. FWIW, one natural way to do that here would be to make the int field @Stable and have the accessor return one less than the stored field value. Then, by the rules of @Stable, the field starts out at the logical value of -1, and can transition to a valid BCI if patched to a non-zero value in the range 1..(2^16). Making it "final" and initialized to -1 is not too terrible either, although that creates some tech. debt we need to discharge when upgrading finals to be trustable. ? John From mikhailo.seledtsov at oracle.com Wed Dec 13 01:58:09 2017 From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov) Date: Tue, 12 Dec 2017 17:58:09 -0800 Subject: RFR(S) 8165603 - UseAppCDS.java failed to clean up files after test In-Reply-To: References: Message-ID: <5A308931.8050605@oracle.com> +1 Misha On 12/12/17, 5:28 PM, David Holmes wrote: > Looks good! Nice cleanup. > > Thanks, > David > > On 13/12/2017 10:41 AM, Ioi Lam wrote: >> https://bugs.openjdk.java.net/browse/JDK-8165603 >> http://cr.openjdk.java.net/~iklam/jdk11/8165603-files-not-closed.v01/ >> >> Summary: >> >> The test case opens a temp file for reading without closing it >> explicitly. This causes >> jtreg agentvm mode testing on Windows to complain about failing to >> delete the temp file. >> >> The fix is to to put the opening of input/output streams in >> try-resource blocks, like >> >> try (BufferedReader br = >> new BufferedReader( >> new InputStreamReader( >> new FileInputStream(filename))) >> ) { >> for (; ; ) { >> String line = br.readLine(); >> ... >> } >> >> The streams will be closed when we leave the "try" block. >> >> Besides the test in the bug report, I fixed a few other files in >> similar ways. >> >> Testing -- HotSpot tier1/tier2 tests all passed. I verified that >> UseAppCDS.java >> is now executed on Windows and passed. >> >> I plan to push into the jdk/hs repo after the jdk 10 repo fork. >> >> Thanks >> - Ioi From david.holmes at oracle.com Wed Dec 13 05:03:49 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 13 Dec 2017 15:03:49 +1000 Subject: [JDK 11] RFR: (XS) 8193364: verify_special_jvm_flags should not cause an assertion failure when version is bumped Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8193364 webrev: http://cr.openjdk.java.net/~dholmes/8193364/webrev/ verify_special_jvm_flags operates only in debug builds and sanity checks the entries in the deprecated/obsoleted/expired/aliased tables. In addition it detects whether we have not yet removed the global variables for flags that are obsolete/expired, and issues a warning. In the latter case though it also returns false and causes the assertion to fail. This make it impossible to bump the JDK version without dealing with every flag en-masse. We should issue the warnings but not fail the assert in these cases. --- old/src/hotspot/share/runtime/arguments.cpp 2017-12-12 23:59:14.039718085 -0500 +++ new/src/hotspot/share/runtime/arguments.cpp 2017-12-12 23:59:11.575576703 -0500 @@ -710,7 +710,6 @@ if (!version_less_than(JDK_Version::current(), flag.obsolete_in)) { if (Flag::find_flag(flag.name) != NULL) { warning("Global variable for obsolete special flag entry \"%s\" should be removed", flag.name); - success = false; } } } @@ -720,7 +719,6 @@ if (!version_less_than(JDK_Version::current(), flag.expired_in)) { if (Flag::find_flag(flag.name) != NULL) { warning("Global variable for expired flag entry \"%s\" should be removed", flag.name); - success = false; } } } This need was flagged when we went to JDK 10 (see JDK-8173421) but not actioned. We need it now before we bump the version for JDK 11. Thanks, David From daniel.daugherty at oracle.com Wed Dec 13 13:51:45 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 13 Dec 2017 08:51:45 -0500 Subject: [JDK 11] RFR: (XS) 8193364: verify_special_jvm_flags should not cause an assertion failure when version is bumped In-Reply-To: References: Message-ID: On 12/13/17 12:03 AM, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8193364 > webrev: http://cr.openjdk.java.net/~dholmes/8193364/webrev/ > > verify_special_jvm_flags operates only in debug builds and sanity > checks the entries in the deprecated/obsoleted/expired/aliased tables. > In addition it detects whether we have not yet removed the global > variables for flags that are obsolete/expired, and issues a warning. > In the latter case though it also returns false and causes the > assertion to fail. This make it impossible to bump the JDK version > without dealing with every flag en-masse. > > We should issue the warnings but not fail the assert in these cases. > > --- old/src/hotspot/share/runtime/arguments.cpp??? 2017-12-12 > 23:59:14.039718085 -0500 > +++ new/src/hotspot/share/runtime/arguments.cpp??? 2017-12-12 > 23:59:11.575576703 -0500 > @@ -710,7 +710,6 @@ > ?????? if (!version_less_than(JDK_Version::current(), > flag.obsolete_in)) { > ???????? if (Flag::find_flag(flag.name) != NULL) { > ?????????? warning("Global variable for obsolete special flag entry > \"%s\" should be removed", flag.name); > -????????? success = false; You should add a comment in place of the removed to line. Otherwise, someone reading that function will think that setting 'success' to false was just missed. Perhaps: ????????? // Do not set success to 'false' in this case since ????????? // we only want a warning here for ease of transition ????????? // to a new release. > } > ?????? } > ???? } > @@ -720,7 +719,6 @@ > ?????? if (!version_less_than(JDK_Version::current(), flag.expired_in)) { > ???????? if (Flag::find_flag(flag.name) != NULL) { > ?????????? warning("Global variable for expired flag entry \"%s\" > should be removed", flag.name); > -????????? success = false; And perhaps: ????????? // Do not set success to 'false'; see above note. Dan > } > ?????? } > ???? } > > This need was flagged when we went to JDK 10 (see JDK-8173421) but not > actioned. We need it now before we bump the version for JDK 11. > > Thanks, > David From goetz.lindenmaier at sap.com Thu Dec 14 12:06:19 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 14 Dec 2017 12:06:19 +0000 Subject: RFR(XS): 8193509: Test dynamic path to retrieve active processor count. Message-ID: <4202f82c4cce404c97b2012be1096f30@sap.com> Hi, active_processor_count() in os_linux.cpp has two paths, one is only excercised if the VM runs on a machine with more than 1024 processors. Flag UseCpuAllocPath allows to force this path. Add a test with this flag to excercise this code. Please review this change. I please need a sponsor. (Do I need one with the new repo setup?) http://cr.openjdk.java.net/~goetz/wr17/8193509-activeProcTest/webrev.01/ Best regards, Goetz. From david.holmes at oracle.com Thu Dec 14 12:39:54 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Dec 2017 22:39:54 +1000 Subject: RFR(XS): 8193509: Test dynamic path to retrieve active processor count. In-Reply-To: <4202f82c4cce404c97b2012be1096f30@sap.com> References: <4202f82c4cce404c97b2012be1096f30@sap.com> Message-ID: <5104fd17-a4ad-72f7-ece0-987daf9aa938@oracle.com> Hi Goetz, On 14/12/2017 10:06 PM, Lindenmaier, Goetz wrote: > Hi, > > active_processor_count() in os_linux.cpp has two paths, one is only > excercised if the VM runs on a machine with more than 1024 processors. > Flag UseCpuAllocPath allows to force this path. Add a test with > this flag to excercise this code. Not sure I see the value in having a test for this. Where would this test run such that it would show us there is some problem that needs fixing? The real test of that code path is on a machine with > 1024 processors. That aside please reformat the 29 * @summary If #processors > 1024 os_linux.cpp uses special coding. Excercise this by forcing usage of this coding. If this fails, this VM was either compiled on a platform which does not define CPU_ALLOC, or it is executed on a platform that does not support it. to use multiple lines. Though a simple: @summary Test the UseCpuAllocPath code path would suffice IMHO. And the name of the test should more accurately be TestUseCpuAllocPath. > Please review this change. I please need a sponsor. (Do I need one with the new repo setup?) > http://cr.openjdk.java.net/~goetz/wr17/8193509-activeProcTest/webrev.01/ The need for a sponsor is not related to the repo setup, but the need for adequate cross-platform testing. If the set of platforms you've tested on includes all the platforms Oracle would test on, then a sponsor would not add anything to the equation. But your RFR needs to include what testing you have done. Thanks, David > Best regards, > Goetz. > From goetz.lindenmaier at sap.com Thu Dec 14 13:01:09 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 14 Dec 2017 13:01:09 +0000 Subject: RFR(XS): 8193509: Test dynamic path to retrieve active processor count. In-Reply-To: <5104fd17-a4ad-72f7-ece0-987daf9aa938@oracle.com> References: <4202f82c4cce404c97b2012be1096f30@sap.com> <5104fd17-a4ad-72f7-ece0-987daf9aa938@oracle.com> Message-ID: <8c55fe9b9964421eb1b591cafbed8298@sap.com> Hi David, I implemented the test to detect iff the VM is run on an older OS than it was compiled on which lacks the CPU_ALLOC support. Basically that's what I wrote into the @summary :) I ran the test with jdk 9 on ppc64, ppc64le, s390, x86_64, SLES 11, 12; RHEL 6, 7 (not all combinations, though). Tonight it will run with jdk/hs and a similar coverage. (Actually, the test has been in the test suite for the other platforms, too, but is skipped there, so skipping is tested, too.) New webrev with renamed test: http://cr.openjdk.java.net/~goetz/wr17/8193509-activeProcTest/webrev.02/ Best regards, Goetz. > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Donnerstag, 14. Dezember 2017 13:40 > To: Lindenmaier, Goetz ; hotspot-runtime- > dev at openjdk.java.net > Subject: Re: RFR(XS): 8193509: Test dynamic path to retrieve active processor > count. > > Hi Goetz, > > On 14/12/2017 10:06 PM, Lindenmaier, Goetz wrote: > > Hi, > > > > active_processor_count() in os_linux.cpp has two paths, one is only > > excercised if the VM runs on a machine with more than 1024 processors. > > Flag UseCpuAllocPath allows to force this path. Add a test with > > this flag to excercise this code. > > Not sure I see the value in having a test for this. Where would this > test run such that it would show us there is some problem that needs > fixing? The real test of that code path is on a machine with > 1024 > processors. > > That aside please reformat the > > 29 * @summary If #processors > 1024 os_linux.cpp uses special > coding. Excercise this by forcing usage of this coding. If this fails, > this VM was either compiled on a platform which does not define > CPU_ALLOC, or it is executed on a platform that does not support it. > > to use multiple lines. Though a simple: > > @summary Test the UseCpuAllocPath code path > > would suffice IMHO. > > And the name of the test should more accurately be TestUseCpuAllocPath. > > > Please review this change. I please need a sponsor. (Do I need one with > the new repo setup?) > > http://cr.openjdk.java.net/~goetz/wr17/8193509- > activeProcTest/webrev.01/ > > The need for a sponsor is not related to the repo setup, but the need > for adequate cross-platform testing. If the set of platforms you've > tested on includes all the platforms Oracle would test on, then a > sponsor would not add anything to the equation. But your RFR needs to > include what testing you have done. > > Thanks, > David > > > Best regards, > > Goetz. > > From martin.doerr at sap.com Thu Dec 14 16:00:22 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 14 Dec 2017 16:00:22 +0000 Subject: RFR(XS): 8193521: glibc wastes memory with default configuration Message-ID: <21fef818a07b4b96a433fd80f3529525@sap.com> Hi, I noticed that glibc uses many malloc arenas. By default, glibc allocates a new 128 MB malloc arena for every thread (up to a certain limit, by default 8 * processor count). This is good for few threads which perform a lot of concurrent mallocs, but it doesn't fit well to the JVM which has its own memory management and rather allocates fewer and larger chunks. (See glibc source code libc_malloc which calls arena_get2 in malloc.c and _int_new_arena in arena.c.) Using only one arena significantly reduces virtual memory footprint. Saving memory seems to be more valuable for the JVM than optimizing concurrent mallocs. I suggest to use mallopt(M_ARENA_MAX, 1). It is supported since glibc 2.15. I don't think that we still support older versions with jdk10/11. Please review my proposal: http://cr.openjdk.java.net/~mdoerr/8193521_glibc_malloc/webrev.00/ Running a VM on x86_64 with -Xmx128m -Xss136k -XX:MaxMetaspaceSize=32m -XX:CompressedClassSpaceSize=32m -XX:ReservedCodeCacheSize=64m showed PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 30572 d056149 20 0 1839880 125504 22020 S 103,7 0,8 0:05.09 java After the change, I got it down to: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 30494 d056149 20 0 406932 114360 22544 S 102,7 0,7 0:06.53 java I'm not aware of performance critical concurrent malloc usages in the JVM. Maybe somebody else is? Comments are welcome. I will also need a sponsor if this change is desired. Best regards, Martin From adinn at redhat.com Thu Dec 14 16:27:22 2017 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 14 Dec 2017 16:27:22 +0000 Subject: RFR(XS): 8193521: glibc wastes memory with default configuration In-Reply-To: <21fef818a07b4b96a433fd80f3529525@sap.com> References: <21fef818a07b4b96a433fd80f3529525@sap.com> Message-ID: <2eb52d0b-8c81-f7dc-514f-6c11e1b6c062@redhat.com> Hi Martin, On 14/12/17 16:00, Doerr, Martin wrote: > I suggest to use mallopt(M_ARENA_MAX, 1). It is supported since glibc > 2.15. I don't think that we still support older versions with > jdk10/11. . . . > I'm not aware of performance critical concurrent malloc usages in the > JVM. Maybe somebody else is? Comments are welcome. I will also need a > sponsor if this change is desired. I appreciate the motivation for proposing this and I don't know of any issues it might cause for the JVM itself. However, it might cause problems for some of the libraries the JVM links or, indeed, for Java apps that employ their own native libraries. The former risk could, in theory, be assessed. The latter one is unquantifiable but needs to be taken seriously. So, I think this change is probably not safe. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From thomas.schatzl at oracle.com Thu Dec 14 16:51:17 2017 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Thu, 14 Dec 2017 17:51:17 +0100 Subject: RFR(XS): 8193521: glibc wastes memory with default configuration In-Reply-To: <21fef818a07b4b96a433fd80f3529525@sap.com> References: <21fef818a07b4b96a433fd80f3529525@sap.com> Message-ID: <1513270277.2416.7.camel@oracle.com> Hi, On Thu, 2017-12-14 at 16:00 +0000, Doerr, Martin wrote: > Hi, > > I noticed that glibc uses many malloc arenas. By default, glibc > allocates a new 128 MB malloc arena for every thread (up to a certain > limit, by default 8 * processor count). > This is good for few threads which perform a lot of concurrent > mallocs, but it doesn't fit well to the JVM which has its own memory > management and rather allocates fewer and larger chunks. > (See glibc source code libc_malloc which calls arena_get2 in malloc.c > and _int_new_arena in arena.c.) > Using only one arena significantly reduces virtual memory footprint. > Saving memory seems to be more valuable for the JVM than optimizing > concurrent mallocs. > > I suggest to use mallopt(M_ARENA_MAX, 1). It is supported since glibc > 2.15. I don't think that we still support older versions with > jdk10/11. > Please review my proposal: > http://cr.openjdk.java.net/~mdoerr/8193521_glibc_malloc/webrev.00/ > > Running a VM on x86_64 with -Xmx128m -Xss136k > -XX:MaxMetaspaceSize=32m -XX:CompressedClassSpaceSize=32m > -XX:ReservedCodeCacheSize=64m showed > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ > COMMAND > 30572 d056149 20 0 1839880 125504 22020 S 103,7 0,8 0:05.09 > java > > After the change, I got it down to: > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ > COMMAND > 30494 d056149 20 0 406932 114360 22544 S 102,7 0,7 0:06.53 > java > > I'm not aware of performance critical concurrent malloc usages in the > JVM. Maybe somebody else is? E.g. G1 remembered sets can be a huge malloc'ed memory consumer, although it (also partially) caches allocations from malloc. Afair malloc performance can already be a significant performance issue in that area. Thanks, Thomas From aph at redhat.com Thu Dec 14 18:01:30 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 14 Dec 2017 18:01:30 +0000 Subject: RFR(XS): 8193521: glibc wastes memory with default configuration In-Reply-To: <21fef818a07b4b96a433fd80f3529525@sap.com> References: <21fef818a07b4b96a433fd80f3529525@sap.com> Message-ID: <52cf934f-87c1-2e84-bd0b-1298d766943e@redhat.com> On 14/12/17 16:00, Doerr, Martin wrote: > I'm not aware of performance critical concurrent malloc usages in the JVM. Maybe somebody else is? > Comments are welcome. I will also need a sponsor if this change is desired. Is this something that a JVM should decide? I would have thought it's for the user of the system to decide policy. They can set MALLOC_ARENA_MAX on a system-wide basis if they really need to save memory, or just for Java. Or are you suggesting that Java is so unusual that it justifies overriding a user's settings? If a user has explicitly set MALLOC_ARENA_MAX, don't futz with it. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From martin.doerr at sap.com Thu Dec 14 18:30:07 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 14 Dec 2017 18:30:07 +0000 Subject: RFR(XS): 8193521: glibc wastes memory with default configuration In-Reply-To: <2eb52d0b-8c81-f7dc-514f-6c11e1b6c062@redhat.com> References: <21fef818a07b4b96a433fd80f3529525@sap.com> <2eb52d0b-8c81-f7dc-514f-6c11e1b6c062@redhat.com> Message-ID: Hi Andrew, thanks for your feedback. I'm not really an expert on this topic and I'm hoping that people on the mailing list can help evaluating the risk and the benefit. Own native libraries are a good point. But I still hope that there are enough people out there who would like to see improvements for their use case. Best regards, Martin -----Original Message----- From: Andrew Dinn [mailto:adinn at redhat.com] Sent: Donnerstag, 14. Dezember 2017 17:27 To: Doerr, Martin ; hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR(XS): 8193521: glibc wastes memory with default configuration Hi Martin, On 14/12/17 16:00, Doerr, Martin wrote: > I suggest to use mallopt(M_ARENA_MAX, 1). It is supported since glibc > 2.15. I don't think that we still support older versions with > jdk10/11. . . . > I'm not aware of performance critical concurrent malloc usages in the > JVM. Maybe somebody else is? Comments are welcome. I will also need a > sponsor if this change is desired. I appreciate the motivation for proposing this and I don't know of any issues it might cause for the JVM itself. However, it might cause problems for some of the libraries the JVM links or, indeed, for Java apps that employ their own native libraries. The former risk could, in theory, be assessed. The latter one is unquantifiable but needs to be taken seriously. So, I think this change is probably not safe. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From martin.doerr at sap.com Thu Dec 14 18:31:49 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 14 Dec 2017 18:31:49 +0000 Subject: RFR(XS): 8193521: glibc wastes memory with default configuration In-Reply-To: <1513270277.2416.7.camel@oracle.com> References: <21fef818a07b4b96a433fd80f3529525@sap.com> <1513270277.2416.7.camel@oracle.com> Message-ID: <0527310991204351bf891e3dd0339bdb@sap.com> Hi Thomas, thanks for your input. We're currently testing the change. I haven't seen regressions in benchmarks running with G1 so far, but I think we will need to run more of them. Best regards, Martin -----Original Message----- From: Thomas Schatzl [mailto:thomas.schatzl at oracle.com] Sent: Donnerstag, 14. Dezember 2017 17:51 To: Doerr, Martin ; hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR(XS): 8193521: glibc wastes memory with default configuration Hi, On Thu, 2017-12-14 at 16:00 +0000, Doerr, Martin wrote: > Hi, > > I noticed that glibc uses many malloc arenas. By default, glibc > allocates a new 128 MB malloc arena for every thread (up to a certain > limit, by default 8 * processor count). > This is good for few threads which perform a lot of concurrent > mallocs, but it doesn't fit well to the JVM which has its own memory > management and rather allocates fewer and larger chunks. > (See glibc source code libc_malloc which calls arena_get2 in malloc.c > and _int_new_arena in arena.c.) > Using only one arena significantly reduces virtual memory footprint. > Saving memory seems to be more valuable for the JVM than optimizing > concurrent mallocs. > > I suggest to use mallopt(M_ARENA_MAX, 1). It is supported since glibc > 2.15. I don't think that we still support older versions with > jdk10/11. > Please review my proposal: > http://cr.openjdk.java.net/~mdoerr/8193521_glibc_malloc/webrev.00/ > > Running a VM on x86_64 with -Xmx128m -Xss136k > -XX:MaxMetaspaceSize=32m -XX:CompressedClassSpaceSize=32m > -XX:ReservedCodeCacheSize=64m showed > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ > COMMAND > 30572 d056149 20 0 1839880 125504 22020 S 103,7 0,8 0:05.09 > java > > After the change, I got it down to: > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ > COMMAND > 30494 d056149 20 0 406932 114360 22544 S 102,7 0,7 0:06.53 > java > > I'm not aware of performance critical concurrent malloc usages in the > JVM. Maybe somebody else is? E.g. G1 remembered sets can be a huge malloc'ed memory consumer, although it (also partially) caches allocations from malloc. Afair malloc performance can already be a significant performance issue in that area. Thanks, Thomas From martin.doerr at sap.com Thu Dec 14 18:51:00 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 14 Dec 2017 18:51:00 +0000 Subject: RFR(XS): 8193521: glibc wastes memory with default configuration In-Reply-To: <52cf934f-87c1-2e84-bd0b-1298d766943e@redhat.com> References: <21fef818a07b4b96a433fd80f3529525@sap.com> <52cf934f-87c1-2e84-bd0b-1298d766943e@redhat.com> Message-ID: Hi Andrew, > Or are you suggesting that Java is so unusual that it justifies overriding a user's settings? I think this kind of matches was I thought. I guess most people don't even know that this malloc related stuff can be configured. (I didn't know much about it before I started to investigate this issue, either.) And I also assume that most JVM users don't know that the JVM has own arena implementation etc. which makes glibc arenas under the hood useless for these kind of allocations. So I think it would be nice if we could help these people. Embedded applications or cloud applications running in containers may suffer from wasting so much virtual memory, which is really significant. I was not sure if this is the best approach to address the issue, but I'd like to see an improvement, here. Best regards, Martin -----Original Message----- From: Andrew Haley [mailto:aph at redhat.com] Sent: Donnerstag, 14. Dezember 2017 19:02 To: Doerr, Martin ; hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR(XS): 8193521: glibc wastes memory with default configuration On 14/12/17 16:00, Doerr, Martin wrote: > I'm not aware of performance critical concurrent malloc usages in the JVM. Maybe somebody else is? > Comments are welcome. I will also need a sponsor if this change is desired. Is this something that a JVM should decide? I would have thought it's for the user of the system to decide policy. They can set MALLOC_ARENA_MAX on a system-wide basis if they really need to save memory, or just for Java. Or are you suggesting that Java is so unusual that it justifies overriding a user's settings? If a user has explicitly set MALLOC_ARENA_MAX, don't futz with it. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Thu Dec 14 19:06:04 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 14 Dec 2017 19:06:04 +0000 Subject: RFR(XS): 8193521: glibc wastes memory with default configuration In-Reply-To: References: <21fef818a07b4b96a433fd80f3529525@sap.com> <52cf934f-87c1-2e84-bd0b-1298d766943e@redhat.com> Message-ID: <6f95ad6c-dea4-8bc3-a7c9-3ca25b7a60b9@redhat.com> On 14/12/17 18:51, Doerr, Martin wrote: > And I also assume that most JVM users don't know that the JVM has own arena implementation etc. which makes glibc arenas under the hood useless for these kind of allocations. > So I think it would be nice if we could help these people. So, here's a radical thought: why are we using malloc() at all? Shouldn't we be calling mmap() and then basing our arena in that? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From mandy.chung at oracle.com Thu Dec 14 19:29:28 2017 From: mandy.chung at oracle.com (mandy chung) Date: Thu, 14 Dec 2017 11:29:28 -0800 Subject: Review Request JDK-8193325: StackFrameInfo::getByteCodeIndex returns wrong value if bci > 32767 In-Reply-To: <4E31CF3C-D7BF-4070-85F5-66D281478F6E@oracle.com> References: <4cf575a1-d420-fb44-cc38-03287366ec3d@oracle.com> <8a326b47-176b-c41a-7fe1-d9d53f37bd5c@oracle.com> <4E31CF3C-D7BF-4070-85F5-66D281478F6E@oracle.com> Message-ID: <0a060ad6-5444-cbe2-7124-a3a4809d14a4@oracle.com> On 12/12/17 5:29 PM, John Rose wrote: > On Dec 12, 2017, at 5:24 PM, David Holmes > wrote: >> >> as per getByteCodeIndex() it needs to be able to store "-1" to >> indicate no-bci? > > Yes, that's the essential requirement, to encode a "none" value. > > FWIW, one natural way to do that here would be to make the int field > @Stable and have the accessor return one less than the stored field value. > > Then, by the rules of @Stable, the field starts out at the logical value > of -1, and can transition to a valid BCI if patched to a non-zero value > in the range 1..(2^16). > Thanks for suggesting @Stable that would help this case.? I can't understand why the field has to be patched with non-zero value.? Is this something special requirement for @Stable? > Making it "final" and initialized to -1 is not too terrible either, > although > that creates some tech. debt we need to discharge when upgrading > finals to be trustable. Mandy [1] http://cr.openjdk.java.net/~bchristi/8185925/StackFrameInfo.jol.rmDeclClass.txt From david.holmes at oracle.com Thu Dec 14 21:12:33 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 15 Dec 2017 07:12:33 +1000 Subject: RFR(XS): 8193509: Test dynamic path to retrieve active processor count. In-Reply-To: <8c55fe9b9964421eb1b591cafbed8298@sap.com> References: <4202f82c4cce404c97b2012be1096f30@sap.com> <5104fd17-a4ad-72f7-ece0-987daf9aa938@oracle.com> <8c55fe9b9964421eb1b591cafbed8298@sap.com> Message-ID: <38531b07-45df-f541-3749-1ac6ed64cb16@oracle.com> Hi Goetz, On 14/12/2017 11:01 PM, Lindenmaier, Goetz wrote: > Hi David, > > I implemented the test to detect iff the VM is run on an older OS > than it was compiled on which lacks the CPU_ALLOC support. > Basically that's what I wrote into the @summary :) So do you plan on running the test on such older OS? And on such an OS will you ever find >1024 processors and so try to really take the path that test shows is not usable ? > I ran the test with jdk 9 on ppc64, ppc64le, s390, x86_64, > SLES 11, 12; RHEL 6, 7 (not all combinations, though). > Tonight it will run with jdk/hs and a similar coverage. (Actually, the > test has been in the test suite for the other platforms, too, but > is skipped there, so skipping is tested, too.) > > New webrev with renamed test: > http://cr.openjdk.java.net/~goetz/wr17/8193509-activeProcTest/webrev.02/ Okay. I'll apply it locally and run on our systems just for a sanity check. Meanwhile a second reviewer is needed. Thanks, David > > Best regards, > Goetz. > > > > >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Donnerstag, 14. Dezember 2017 13:40 >> To: Lindenmaier, Goetz ; hotspot-runtime- >> dev at openjdk.java.net >> Subject: Re: RFR(XS): 8193509: Test dynamic path to retrieve active processor >> count. >> >> Hi Goetz, >> >> On 14/12/2017 10:06 PM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> active_processor_count() in os_linux.cpp has two paths, one is only >>> excercised if the VM runs on a machine with more than 1024 processors. >>> Flag UseCpuAllocPath allows to force this path. Add a test with >>> this flag to excercise this code. >> >> Not sure I see the value in having a test for this. Where would this >> test run such that it would show us there is some problem that needs >> fixing? The real test of that code path is on a machine with > 1024 >> processors. >> >> That aside please reformat the >> >> 29 * @summary If #processors > 1024 os_linux.cpp uses special >> coding. Excercise this by forcing usage of this coding. If this fails, >> this VM was either compiled on a platform which does not define >> CPU_ALLOC, or it is executed on a platform that does not support it. >> >> to use multiple lines. Though a simple: >> >> @summary Test the UseCpuAllocPath code path >> >> would suffice IMHO. >> >> And the name of the test should more accurately be TestUseCpuAllocPath. >> >>> Please review this change. I please need a sponsor. (Do I need one with >> the new repo setup?) >>> http://cr.openjdk.java.net/~goetz/wr17/8193509- >> activeProcTest/webrev.01/ >> >> The need for a sponsor is not related to the repo setup, but the need >> for adequate cross-platform testing. If the set of platforms you've >> tested on includes all the platforms Oracle would test on, then a >> sponsor would not add anything to the equation. But your RFR needs to >> include what testing you have done. >> >> Thanks, >> David >> >>> Best regards, >>> Goetz. >>> From ioi.lam at oracle.com Thu Dec 14 22:30:01 2017 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 14 Dec 2017 14:30:01 -0800 Subject: RFR[XS] 8191374 Improve error message when CDS is not supported on exploded build Message-ID: <3d106d47-3a28-764a-5f81-de23d1099cec@oracle.com> Hi, please review this very simple fix for JDK 11: https://bugs.openjdk.java.net/browse/JDK-8191374 http://cr.openjdk.java.net/~iklam/jdk11/8191374-exploded-build-dump-error-msg.v01/ Summary - the error message is changed to be more obvious what's going on. Testing: since we don't have automated tests for exploded builds, I just did some manually testing on Linux using the "exploded build", ./jdk/bin/java, which is an intermediate file created by the JDK build system. Before: ??? $ ./jdk/bin/java -Xshare:dump ??? Error: non-empty directory '/jdk/bld/opencds/jdk/modules/java.base' ??? Hint: enable -Xlog:class+path=info to diagnose the failure ??? Error occurred during initialization of VM ??? CDS allows only empty directories in archived classpaths After: ??? $ ./jdk/bin/java -Xshare:dump ??? Error occurred during initialization of VM ??? CDS is not supported in exploded JDK build Thanks - Ioi From harold.seigel at oracle.com Thu Dec 14 22:41:36 2017 From: harold.seigel at oracle.com (harold seigel) Date: Thu, 14 Dec 2017 17:41:36 -0500 Subject: RFR[XS] 8191374 Improve error message when CDS is not supported on exploded build In-Reply-To: <3d106d47-3a28-764a-5f81-de23d1099cec@oracle.com> References: <3d106d47-3a28-764a-5f81-de23d1099cec@oracle.com> Message-ID: <03b68d85-bee7-d6ab-1e92-64ac30b316e3@oracle.com> Hi Ioi, Fix looks good. Thanks, Harold On 12/14/2017 5:30 PM, Ioi Lam wrote: > Hi, please review this very simple fix for JDK 11: > > https://bugs.openjdk.java.net/browse/JDK-8191374 > http://cr.openjdk.java.net/~iklam/jdk11/8191374-exploded-build-dump-error-msg.v01/ > > > Summary - the error message is changed to be more obvious what's going > on. > > > Testing: since we don't have automated tests for exploded builds, I > just did some > manually testing on Linux using the "exploded build", ./jdk/bin/java, > which is an > intermediate file created by the JDK build system. > > > Before: > > ??? $ ./jdk/bin/java -Xshare:dump > ??? Error: non-empty directory '/jdk/bld/opencds/jdk/modules/java.base' > ??? Hint: enable -Xlog:class+path=info to diagnose the failure > ??? Error occurred during initialization of VM > ??? CDS allows only empty directories in archived classpaths > > > After: > > ??? $ ./jdk/bin/java -Xshare:dump > ??? Error occurred during initialization of VM > ??? CDS is not supported in exploded JDK build > > > Thanks > - Ioi From david.holmes at oracle.com Thu Dec 14 22:54:48 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 15 Dec 2017 08:54:48 +1000 Subject: RFR(XS): 8193509: Test dynamic path to retrieve active processor count. In-Reply-To: <38531b07-45df-f541-3749-1ac6ed64cb16@oracle.com> References: <4202f82c4cce404c97b2012be1096f30@sap.com> <5104fd17-a4ad-72f7-ece0-987daf9aa938@oracle.com> <8c55fe9b9964421eb1b591cafbed8298@sap.com> <38531b07-45df-f541-3749-1ac6ed64cb16@oracle.com> Message-ID: <694ba799-5f9f-742b-3c5b-d50799f0dd4d@oracle.com> My testing passed. So just needing second review. Also for now I suggest ensuring the "FixVersion" is not set when doing the push, as the correct version for JDK 11 has not yet been set in the configuration info used by hgupdater. Otherwise if you correctly set FixVersion to 11, hgupdater will create a 10 backport; if you set it to 10 and hgupdater gets fixed before you push, then you will get a backport for 11. So leave it blank or just wait until we know hgupdater is doing the right thing. Thanks, David On 15/12/2017 7:12 AM, David Holmes wrote: > Hi Goetz, > > On 14/12/2017 11:01 PM, Lindenmaier, Goetz wrote: >> Hi David, >> >> I implemented the test to detect iff the VM is run on an older OS >> than it was compiled on which lacks the CPU_ALLOC support. >> Basically that's what I wrote into the @summary :) > > So do you plan on running the test on such older OS? And on such an OS > will you ever find >1024 processors and so try to really take the path > that test shows is not usable ? > >> I ran the test with jdk 9 on ppc64, ppc64le, s390, x86_64, >> SLES 11, 12; RHEL 6, 7 (not all combinations, though). >> Tonight it will run with jdk/hs and a similar coverage.? (Actually, the >> test has been in the test suite for the other platforms, too, but >> is skipped there, so skipping is tested, too.) >> >> New webrev with renamed test: >> http://cr.openjdk.java.net/~goetz/wr17/8193509-activeProcTest/webrev.02/ > > Okay. I'll apply it locally and run on our systems just for a sanity > check. Meanwhile a second reviewer is needed. > > Thanks, > David > >> >> Best regards, >> ? Goetz. >> >> >> >> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Donnerstag, 14. Dezember 2017 13:40 >>> To: Lindenmaier, Goetz ; hotspot-runtime- >>> dev at openjdk.java.net >>> Subject: Re: RFR(XS): 8193509: Test dynamic path to retrieve active >>> processor >>> count. >>> >>> Hi Goetz, >>> >>> On 14/12/2017 10:06 PM, Lindenmaier, Goetz wrote: >>>> Hi, >>>> >>>> active_processor_count() in os_linux.cpp has two paths, one is only >>>> excercised if the VM runs on a machine with more than 1024 processors. >>>> Flag UseCpuAllocPath allows to force this path. Add a test with >>>> this flag to excercise this code. >>> >>> Not sure I see the value in having a test for this. Where would this >>> test run such that it would show us there is some problem that needs >>> fixing? The real test of that code path is on a machine with > 1024 >>> processors. >>> >>> That aside please reformat the >>> >>> ??? 29? * @summary If #processors > 1024 os_linux.cpp uses special >>> coding. Excercise this by forcing usage of this coding. If this fails, >>> this VM was either compiled on a platform which does not define >>> CPU_ALLOC, or it is executed on a platform that does not support it. >>> >>> to use multiple lines. Though a simple: >>> >>> @summary? Test the UseCpuAllocPath code path >>> >>> would suffice IMHO. >>> >>> And the name of the test should more accurately be TestUseCpuAllocPath. >>> >>>> Please review this change. I please need a sponsor. (Do I need one with >>> the new repo setup?) >>>> http://cr.openjdk.java.net/~goetz/wr17/8193509- >>> activeProcTest/webrev.01/ >>> >>> The need for a sponsor is not related to the repo setup, but the need >>> for adequate cross-platform testing. If the set of platforms you've >>> tested on includes all the platforms Oracle would test on, then a >>> sponsor would not add anything to the equation. But your RFR needs to >>> include what testing you have done. >>> >>> Thanks, >>> David >>> >>>> Best regards, >>>> ??? Goetz. >>>> From jiangli.zhou at oracle.com Thu Dec 14 23:20:40 2017 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Thu, 14 Dec 2017 15:20:40 -0800 Subject: RFR[XS] 8191374 Improve error message when CDS is not supported on exploded build In-Reply-To: <3d106d47-3a28-764a-5f81-de23d1099cec@oracle.com> References: <3d106d47-3a28-764a-5f81-de23d1099cec@oracle.com> Message-ID: Looks good. Thanks, Jiangli > On Dec 14, 2017, at 2:30 PM, Ioi Lam wrote: > > Hi, please review this very simple fix for JDK 11: > > https://bugs.openjdk.java.net/browse/JDK-8191374 > http://cr.openjdk.java.net/~iklam/jdk11/8191374-exploded-build-dump-error-msg.v01/ > > Summary - the error message is changed to be more obvious what's going on. > > > Testing: since we don't have automated tests for exploded builds, I just did some > manually testing on Linux using the "exploded build", ./jdk/bin/java, which is an > intermediate file created by the JDK build system. > > > Before: > > $ ./jdk/bin/java -Xshare:dump > Error: non-empty directory '/jdk/bld/opencds/jdk/modules/java.base' > Hint: enable -Xlog:class+path=info to diagnose the failure > Error occurred during initialization of VM > CDS allows only empty directories in archived classpaths > > > After: > > $ ./jdk/bin/java -Xshare:dump > Error occurred during initialization of VM > CDS is not supported in exploded JDK build > > > Thanks > - Ioi From david.holmes at oracle.com Fri Dec 15 02:29:41 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 15 Dec 2017 12:29:41 +1000 Subject: [JDK 11] RFR: (XS) 8193364: verify_special_jvm_flags should not cause an assertion failure when version is bumped In-Reply-To: References: Message-ID: <84996d65-9a22-3e44-a0d2-87eadea6b914@oracle.com> Hi Dan, Thanks for looking at this. I opted to add an explanatory comment block before the method instead. http://cr.openjdk.java.net/~dholmes/8193364/webrev.v1/ Thanks, David ----- On 13/12/2017 11:51 PM, Daniel D. Daugherty wrote: > On 12/13/17 12:03 AM, David Holmes wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8193364 >> webrev: http://cr.openjdk.java.net/~dholmes/8193364/webrev/ >> >> verify_special_jvm_flags operates only in debug builds and sanity >> checks the entries in the deprecated/obsoleted/expired/aliased tables. >> In addition it detects whether we have not yet removed the global >> variables for flags that are obsolete/expired, and issues a warning. >> In the latter case though it also returns false and causes the >> assertion to fail. This make it impossible to bump the JDK version >> without dealing with every flag en-masse. >> >> We should issue the warnings but not fail the assert in these cases. >> >> --- old/src/hotspot/share/runtime/arguments.cpp??? 2017-12-12 >> 23:59:14.039718085 -0500 >> +++ new/src/hotspot/share/runtime/arguments.cpp??? 2017-12-12 >> 23:59:11.575576703 -0500 >> @@ -710,7 +710,6 @@ >> ?????? if (!version_less_than(JDK_Version::current(), >> flag.obsolete_in)) { >> ???????? if (Flag::find_flag(flag.name) != NULL) { >> ?????????? warning("Global variable for obsolete special flag entry >> \"%s\" should be removed", flag.name); >> -????????? success = false; > > You should add a comment in place of the removed to line. > Otherwise, someone reading that function will think that > setting 'success' to false was just missed. Perhaps: > > ????????? // Do not set success to 'false' in this case since > ????????? // we only want a warning here for ease of transition > ????????? // to a new release. > >> } >> ?????? } >> ???? } >> @@ -720,7 +719,6 @@ >> ?????? if (!version_less_than(JDK_Version::current(), flag.expired_in)) { >> ???????? if (Flag::find_flag(flag.name) != NULL) { >> ?????????? warning("Global variable for expired flag entry \"%s\" >> should be removed", flag.name); >> -????????? success = false; > > And perhaps: > > ????????? // Do not set success to 'false'; see above note. > > Dan > > >> } >> ?????? } >> ???? } >> >> This need was flagged when we went to JDK 10 (see JDK-8173421) but not >> actioned. We need it now before we bump the version for JDK 11. >> >> Thanks, >> David > From ioi.lam at oracle.com Fri Dec 15 04:41:34 2017 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 14 Dec 2017 20:41:34 -0800 Subject: RFR[XS] 8191374 Improve error message when CDS is not supported on exploded build In-Reply-To: References: <3d106d47-3a28-764a-5f81-de23d1099cec@oracle.com> Message-ID: Jiangli & Harold Thanks for the review! - Ioi On 12/14/17 3:20 PM, Jiangli Zhou wrote: > Looks good. > > Thanks, > Jiangli > >> On Dec 14, 2017, at 2:30 PM, Ioi Lam wrote: >> >> Hi, please review this very simple fix for JDK 11: >> >> https://bugs.openjdk.java.net/browse/JDK-8191374 >> http://cr.openjdk.java.net/~iklam/jdk11/8191374-exploded-build-dump-error-msg.v01/ >> >> Summary - the error message is changed to be more obvious what's going on. >> >> >> Testing: since we don't have automated tests for exploded builds, I just did some >> manually testing on Linux using the "exploded build", ./jdk/bin/java, which is an >> intermediate file created by the JDK build system. >> >> >> Before: >> >> $ ./jdk/bin/java -Xshare:dump >> Error: non-empty directory '/jdk/bld/opencds/jdk/modules/java.base' >> Hint: enable -Xlog:class+path=info to diagnose the failure >> Error occurred during initialization of VM >> CDS allows only empty directories in archived classpaths >> >> >> After: >> >> $ ./jdk/bin/java -Xshare:dump >> Error occurred during initialization of VM >> CDS is not supported in exploded JDK build >> >> >> Thanks >> - Ioi From sgehwolf at redhat.com Fri Dec 15 09:46:00 2017 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Fri, 15 Dec 2017 10:46:00 +0100 Subject: RFR(XS): 8193521: glibc wastes memory with default configuration In-Reply-To: <6f95ad6c-dea4-8bc3-a7c9-3ca25b7a60b9@redhat.com> References: <21fef818a07b4b96a433fd80f3529525@sap.com> <52cf934f-87c1-2e84-bd0b-1298d766943e@redhat.com> <6f95ad6c-dea4-8bc3-a7c9-3ca25b7a60b9@redhat.com> Message-ID: <1513331160.4938.4.camel@redhat.com> On Thu, 2017-12-14 at 19:06 +0000, Andrew Haley wrote: > On 14/12/17 18:51, Doerr, Martin wrote: > > And I also assume that most JVM users don't know that the JVM has > > own arena implementation etc. which makes glibc arenas under the > > hood useless for these kind of allocations. > > So I think it would be nice if we could help these people. > > So, here's a radical thought: why are we using malloc() at all? > Shouldn't we be calling mmap() and then basing our arena in that? Failing that it would make sense to limit the max arenas based on the cpu share's a container gets (OSContainer::active_processor_count()). I.e. it could be part of JEP 8182070, Container aware Java. Thoughts? Thanks, Severin From adinn at redhat.com Fri Dec 15 09:56:05 2017 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 15 Dec 2017 09:56:05 +0000 Subject: RFR(XS): 8193521: glibc wastes memory with default configuration In-Reply-To: <6f95ad6c-dea4-8bc3-a7c9-3ca25b7a60b9@redhat.com> References: <21fef818a07b4b96a433fd80f3529525@sap.com> <52cf934f-87c1-2e84-bd0b-1298d766943e@redhat.com> <6f95ad6c-dea4-8bc3-a7c9-3ca25b7a60b9@redhat.com> Message-ID: <7b794a15-9b88-2317-a363-2f830a7091bb@redhat.com> On 14/12/17 19:06, Andrew Haley wrote: > On 14/12/17 18:51, Doerr, Martin wrote: >> And I also assume that most JVM users don't know that the JVM has own arena implementation etc. which makes glibc arenas under the hood useless for these kind of allocations. >> So I think it would be nice if we could help these people. > > So, here's a radical thought: why are we using malloc() at all? > Shouldn't we be calling mmap() and then basing our arena in that? The JVM does that almost all of the time. My guess is that the difference Martin is seeing is down to malloc operations done outside libjvm.so regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From martin.doerr at sap.com Fri Dec 15 10:39:50 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 15 Dec 2017 10:39:50 +0000 Subject: RFR(XS): 8193521: glibc wastes memory with default configuration In-Reply-To: <7b794a15-9b88-2317-a363-2f830a7091bb@redhat.com> References: <21fef818a07b4b96a433fd80f3529525@sap.com> <52cf934f-87c1-2e84-bd0b-1298d766943e@redhat.com> <6f95ad6c-dea4-8bc3-a7c9-3ca25b7a60b9@redhat.com> <7b794a15-9b88-2317-a363-2f830a7091bb@redhat.com> Message-ID: <6d275c67b9534b70ab82d38bff3d98c3@sap.com> Hi, the behavior of the glibc can easily be traced by gdb. I have set a breakpoint in "mmap" with cond "len>10000000" and then looked at the stack traces. The first malloc in each new thread triggers a 128 MB mmap. This typically seems to be the initialization of thread local storage. (Other mallocs may be hidden in libraries.) #0 __mmap (addr=addr at entry=0x0, len=len at entry=134217728, prot=prot at entry=0, flags=flags at entry=16418, fd=fd at entry=-1, offset=offset at entry=0) at ../sysdeps/unix/sysv/linux/wordsize-64/mmap.c:33 #1 0x00007ffff72403d1 in new_heap (size=135168, size at entry=2264, top_pad=) at arena.c:438 #2 0x00007ffff7240c21 in _int_new_arena (size=24) at arena.c:646 #3 arena_get2 (size=size at entry=24, avoid_arena=avoid_arena at entry=0x0) at arena.c:879 #4 0x00007ffff724724a in arena_get2 (avoid_arena=0x0, size=24) at malloc.c:2911 #5 __GI___libc_malloc (bytes=24) at malloc.c:2911 #6 0x00007ffff7de9ff8 in allocate_and_init (map=) at dl-tls.c:603 #7 tls_get_addr_tail (ti=0x7ffff713e100, dtv=0x7ffff0038890, the_map=0x6031a0) at dl-tls.c:791 #8 0x00007ffff6b596ac in Thread::initialize_thread_current() () from openjdk10/lib/server/libjvm.so The VM typically starts more than 20 threads even when only using java -version so we mmap several useless GB. Best regards, Martin -----Original Message----- From: Andrew Dinn [mailto:adinn at redhat.com] Sent: Freitag, 15. Dezember 2017 10:56 To: Andrew Haley ; Doerr, Martin ; hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR(XS): 8193521: glibc wastes memory with default configuration On 14/12/17 19:06, Andrew Haley wrote: > On 14/12/17 18:51, Doerr, Martin wrote: >> And I also assume that most JVM users don't know that the JVM has own arena implementation etc. which makes glibc arenas under the hood useless for these kind of allocations. >> So I think it would be nice if we could help these people. > > So, here's a radical thought: why are we using malloc() at all? > Shouldn't we be calling mmap() and then basing our arena in that? The JVM does that almost all of the time. My guess is that the difference Martin is seeing is down to malloc operations done outside libjvm.so regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From adinn at redhat.com Fri Dec 15 11:26:55 2017 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 15 Dec 2017 11:26:55 +0000 Subject: RFR(XS): 8193521: glibc wastes memory with default configuration In-Reply-To: <6d275c67b9534b70ab82d38bff3d98c3@sap.com> References: <21fef818a07b4b96a433fd80f3529525@sap.com> <52cf934f-87c1-2e84-bd0b-1298d766943e@redhat.com> <6f95ad6c-dea4-8bc3-a7c9-3ca25b7a60b9@redhat.com> <7b794a15-9b88-2317-a363-2f830a7091bb@redhat.com> <6d275c67b9534b70ab82d38bff3d98c3@sap.com> Message-ID: <28e9fb6c-328e-329b-8a48-74ba5eed61f7@redhat.com> On 15/12/17 10:39, Doerr, Martin wrote: > the behavior of the glibc can easily be traced by gdb. Yes, indeed glibc is creating memory not needed /by the JVM/ as part of creating the threads. > The VM typically starts more than 20 threads even when only using > java -version so we mmap several useless GB. Well, that is the bone of contention here. This space may be useless to the JVM code but it may not be useless to other native code. If would be good if you could substantiate your claim that this memory really is 'useless' (to all JVM users). Will your proposed change damage performance for some users? If so then can we scope the potential for damage and agree it is acceptable? regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From adinn at redhat.com Fri Dec 15 11:38:19 2017 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 15 Dec 2017 11:38:19 +0000 Subject: RFR(XS): 8193521: glibc wastes memory with default configuration In-Reply-To: <6d275c67b9534b70ab82d38bff3d98c3@sap.com> References: <21fef818a07b4b96a433fd80f3529525@sap.com> <52cf934f-87c1-2e84-bd0b-1298d766943e@redhat.com> <6f95ad6c-dea4-8bc3-a7c9-3ca25b7a60b9@redhat.com> <7b794a15-9b88-2317-a363-2f830a7091bb@redhat.com> <6d275c67b9534b70ab82d38bff3d98c3@sap.com> Message-ID: On 15/12/17 10:39, Doerr, Martin wrote: > The VM typically starts more than 20 threads even when only using > java -version so we mmap several useless GB. Also, I forgot to mention that it is not mmap calls per se that we need to worry about but actual /physical commit/ of pages in the mmapped region. We are not short of mappable address space and we don't incur any significant cost by mapping the virtual address space we currently use. I have no doubt your trace is showing a vmem page reservation rather than a corresponding physical page commit. If the TLS regions mmapped in your trace were really occupying several GBs of physical pages we would already have done something about it. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From robbin.ehn at oracle.com Fri Dec 15 12:30:58 2017 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Fri, 15 Dec 2017 13:30:58 +0100 Subject: RFR(XS): 8193521: glibc wastes memory with default configuration In-Reply-To: <6f95ad6c-dea4-8bc3-a7c9-3ca25b7a60b9@redhat.com> References: <21fef818a07b4b96a433fd80f3529525@sap.com> <52cf934f-87c1-2e84-bd0b-1298d766943e@redhat.com> <6f95ad6c-dea4-8bc3-a7c9-3ca25b7a60b9@redhat.com> Message-ID: <6ca389c4-a189-3a89-0533-55d81ffb8d5f@oracle.com> On 12/14/2017 08:06 PM, Andrew Haley wrote: > On 14/12/17 18:51, Doerr, Martin wrote: >> And I also assume that most JVM users don't know that the JVM has own arena implementation etc. which makes glibc arenas under the hood useless for these kind of allocations. >> So I think it would be nice if we could help these people. > > So, here's a radical thought: why are we using malloc() at all? > Shouldn't we be calling mmap() and then basing our arena in that? +1 /Robbin > From martin.doerr at sap.com Fri Dec 15 12:31:42 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 15 Dec 2017 12:31:42 +0000 Subject: RFR(XS): 8193521: glibc wastes memory with default configuration In-Reply-To: References: <21fef818a07b4b96a433fd80f3529525@sap.com> <52cf934f-87c1-2e84-bd0b-1298d766943e@redhat.com> <6f95ad6c-dea4-8bc3-a7c9-3ca25b7a60b9@redhat.com> <7b794a15-9b88-2317-a363-2f830a7091bb@redhat.com> <6d275c67b9534b70ab82d38bff3d98c3@sap.com> Message-ID: <50e1c28feb0e493bb42ec4442a01160f@sap.com> Hi Andrew, that's correct. The mmaps I have observed affect virtual memory. Not all of the memory gets committed. So there are basically 2 issues: - virtual memory: Gets somewhat larger than needed. May be an issue for users with reduced ulimit, cloud applications in containers, embedded. - physical memory: We're not wasting so much, but if the JVM handles all performance critical allocations by its own management, it should be worth saving. Related to your earlier mail: > This space may be useless to the JVM code but it may not be useless to > other native code. If would be good if you could substantiate your claim > that this memory really is 'useless' (to all JVM users). Will your > proposed change damage performance for some users? If so then can we > scope the potential for damage and agree it is acceptable? We are testing the change and didn't see performance regressions, yet. But we have to run more benchmarks, especially with G1 (see mail from Thomas Schatzl). Large server tests will be interesting as well. I can't really estimate the risk for native libs and I can understand the concern. Maybe it would be acceptable if the change gets switchable. Best regards, Martin -----Original Message----- From: Andrew Dinn [mailto:adinn at redhat.com] Sent: Freitag, 15. Dezember 2017 12:38 To: Doerr, Martin ; Andrew Haley ; hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR(XS): 8193521: glibc wastes memory with default configuration On 15/12/17 10:39, Doerr, Martin wrote: > The VM typically starts more than 20 threads even when only using > java -version so we mmap several useless GB. Also, I forgot to mention that it is not mmap calls per se that we need to worry about but actual /physical commit/ of pages in the mmapped region. We are not short of mappable address space and we don't incur any significant cost by mapping the virtual address space we currently use. I have no doubt your trace is showing a vmem page reservation rather than a corresponding physical page commit. If the TLS regions mmapped in your trace were really occupying several GBs of physical pages we would already have done something about it. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From robbin.ehn at oracle.com Fri Dec 15 13:12:02 2017 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Fri, 15 Dec 2017 14:12:02 +0100 Subject: RFR(one-liner): UseMembar should not be obsoleted yet Message-ID: <3884984f-f4b9-0d23-80a0-66da0fc2c05f@oracle.com> Hi, please review, After discussion with platform maintainers we keep the option around in JDK 11 also. It's not decided which release it will obsoleted in, so we set it to a future one. Passes: open/test/hotspot/jtreg/runtime/CommandLine/ /Robbin diff -r 6d4e1efac80a src/hotspot/share/runtime/arguments.cpp --- a/src/hotspot/share/runtime/arguments.cpp Wed Dec 13 15:37:48 2017 -0800 +++ b/src/hotspot/share/runtime/arguments.cpp Fri Dec 15 14:04:38 2017 +0100 @@ -499,3 +499,3 @@ { "InitialRAMFraction", JDK_Version::jdk(10), JDK_Version::undefined(), JDK_Version::undefined() }, - { "UseMembar", JDK_Version::jdk(10), JDK_Version::jdk(11), JDK_Version::jdk(12) }, + { "UseMembar", JDK_Version::jdk(10), JDK_Version::undefined(), JDK_Version::undefined() }, { "FastTLABRefill", JDK_Version::jdk(10), JDK_Version::jdk(11), JDK_Version::jdk(12) }, From daniel.daugherty at oracle.com Fri Dec 15 13:17:21 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 15 Dec 2017 08:17:21 -0500 Subject: [JDK 11] RFR: (XS) 8193364: verify_special_jvm_flags should not cause an assertion failure when version is bumped In-Reply-To: <84996d65-9a22-3e44-a0d2-87eadea6b914@oracle.com> References: <84996d65-9a22-3e44-a0d2-87eadea6b914@oracle.com> Message-ID: On 12/14/17 9:29 PM, David Holmes wrote: > Hi Dan, > > Thanks for looking at this. > > I opted to add an explanatory comment block before the method instead. > > http://cr.openjdk.java.net/~dholmes/8193364/webrev.v1/ src/hotspot/share/runtime/arguments.cpp ??? No comments. Thumbs up! Dan > > Thanks, > David > ----- > > On 13/12/2017 11:51 PM, Daniel D. Daugherty wrote: >> On 12/13/17 12:03 AM, David Holmes wrote: >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8193364 >>> webrev: http://cr.openjdk.java.net/~dholmes/8193364/webrev/ >>> >>> verify_special_jvm_flags operates only in debug builds and sanity >>> checks the entries in the deprecated/obsoleted/expired/aliased >>> tables. In addition it detects whether we have not yet removed the >>> global variables for flags that are obsolete/expired, and issues a >>> warning. In the latter case though it also returns false and causes >>> the assertion to fail. This make it impossible to bump the JDK >>> version without dealing with every flag en-masse. >>> >>> We should issue the warnings but not fail the assert in these cases. >>> >>> --- old/src/hotspot/share/runtime/arguments.cpp??? 2017-12-12 >>> 23:59:14.039718085 -0500 >>> +++ new/src/hotspot/share/runtime/arguments.cpp??? 2017-12-12 >>> 23:59:11.575576703 -0500 >>> @@ -710,7 +710,6 @@ >>> ?????? if (!version_less_than(JDK_Version::current(), >>> flag.obsolete_in)) { >>> ???????? if (Flag::find_flag(flag.name) != NULL) { >>> ?????????? warning("Global variable for obsolete special flag entry >>> \"%s\" should be removed", flag.name); >>> -????????? success = false; >> >> You should add a comment in place of the removed to line. >> Otherwise, someone reading that function will think that >> setting 'success' to false was just missed. Perhaps: >> >> ?????????? // Do not set success to 'false' in this case since >> ?????????? // we only want a warning here for ease of transition >> ?????????? // to a new release. >> >>> } >>> ?????? } >>> ???? } >>> @@ -720,7 +719,6 @@ >>> ?????? if (!version_less_than(JDK_Version::current(), >>> flag.expired_in)) { >>> ???????? if (Flag::find_flag(flag.name) != NULL) { >>> ?????????? warning("Global variable for expired flag entry \"%s\" >>> should be removed", flag.name); >>> -????????? success = false; >> >> And perhaps: >> >> ?????????? // Do not set success to 'false'; see above note. >> >> Dan >> >> >>> } >>> ?????? } >>> ???? } >>> >>> This need was flagged when we went to JDK 10 (see JDK-8173421) but >>> not actioned. We need it now before we bump the version for JDK 11. >>> >>> Thanks, >>> David >> From daniel.daugherty at oracle.com Fri Dec 15 13:20:16 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 15 Dec 2017 08:20:16 -0500 Subject: RFR(one-liner): UseMembar should not be obsoleted yet In-Reply-To: <3884984f-f4b9-0d23-80a0-66da0fc2c05f@oracle.com> References: <3884984f-f4b9-0d23-80a0-66da0fc2c05f@oracle.com> Message-ID: <7e5a2659-8ddb-e5f4-8e33-0286cdd4ad74@oracle.com> On 12/15/17 8:12 AM, Robbin Ehn wrote: > Hi, please review, > > After discussion with platform maintainers we keep the option around > in JDK 11 also. It's not decided which release it will obsoleted in, > so we set it to a future one. The bug info for this one is: JDK-8193514 UseMembar should not be obsoleted yet https://bugs.openjdk.java.net/browse/JDK-8193514 > > Passes: > open/test/hotspot/jtreg/runtime/CommandLine/ > > /Robbin > > diff -r 6d4e1efac80a src/hotspot/share/runtime/arguments.cpp > --- a/src/hotspot/share/runtime/arguments.cpp??? Wed Dec 13 15:37:48 > 2017 -0800 > +++ b/src/hotspot/share/runtime/arguments.cpp??? Fri Dec 15 14:04:38 > 2017 +0100 > @@ -499,3 +499,3 @@ > ?? { "InitialRAMFraction",?????????? JDK_Version::jdk(10), > JDK_Version::undefined(), JDK_Version::undefined() }, > -? { "UseMembar",??????????????????? JDK_Version::jdk(10), > JDK_Version::jdk(11), JDK_Version::jdk(12) }, > +? { "UseMembar",??????????????????? JDK_Version::jdk(10), > JDK_Version::undefined(), JDK_Version::undefined() }, > ?? { "FastTLABRefill",?????????????? JDK_Version::jdk(10), > JDK_Version::jdk(11), JDK_Version::jdk(12) }, Thumbs up! Dan From robbin.ehn at oracle.com Fri Dec 15 13:27:23 2017 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Fri, 15 Dec 2017 14:27:23 +0100 Subject: RFR(one-liner): 8193514: UseMembar should not be obsoleted yet In-Reply-To: <7e5a2659-8ddb-e5f4-8e33-0286cdd4ad74@oracle.com> References: <3884984f-f4b9-0d23-80a0-66da0fc2c05f@oracle.com> <7e5a2659-8ddb-e5f4-8e33-0286cdd4ad74@oracle.com> Message-ID: On 12/15/2017 02:20 PM, Daniel D. Daugherty wrote: > On 12/15/17 8:12 AM, Robbin Ehn wrote: >> Hi, please review, >> >> After discussion with platform maintainers we keep the option around in JDK 11 >> also. It's not decided which release it will obsoleted in, so we set it to a >> future one. > > The bug info for this one is: > > JDK-8193514 UseMembar should not be obsoleted yet > https://bugs.openjdk.java.net/browse/JDK-8193514 Thanks! > >> >> Passes: >> open/test/hotspot/jtreg/runtime/CommandLine/ >> >> /Robbin >> >> diff -r 6d4e1efac80a src/hotspot/share/runtime/arguments.cpp >> --- a/src/hotspot/share/runtime/arguments.cpp??? Wed Dec 13 15:37:48 2017 -0800 >> +++ b/src/hotspot/share/runtime/arguments.cpp??? Fri Dec 15 14:04:38 2017 +0100 >> @@ -499,3 +499,3 @@ >> ?? { "InitialRAMFraction",?????????? JDK_Version::jdk(10), >> JDK_Version::undefined(), JDK_Version::undefined() }, >> -? { "UseMembar",??????????????????? JDK_Version::jdk(10), >> JDK_Version::jdk(11), JDK_Version::jdk(12) }, >> +? { "UseMembar",??????????????????? JDK_Version::jdk(10), >> JDK_Version::undefined(), JDK_Version::undefined() }, >> ?? { "FastTLABRefill",?????????????? JDK_Version::jdk(10), >> JDK_Version::jdk(11), JDK_Version::jdk(12) }, > > Thumbs up! And thanks again! /Robbin > > Dan > From karen.kinnear at oracle.com Fri Dec 15 14:44:39 2017 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Fri, 15 Dec 2017 09:44:39 -0500 Subject: RFR(one-liner): 8193514: UseMembar should not be obsoleted yet In-Reply-To: References: <3884984f-f4b9-0d23-80a0-66da0fc2c05f@oracle.com> <7e5a2659-8ddb-e5f4-8e33-0286cdd4ad74@oracle.com> Message-ID: <8E393110-7C3E-4F3A-AE1E-A553FE7FFC18@oracle.com> Thanks Robbin for working this out with the community and for the change. Looks good. Karen > On Dec 15, 2017, at 8:27 AM, Robbin Ehn wrote: > > > On 12/15/2017 02:20 PM, Daniel D. Daugherty wrote: >> On 12/15/17 8:12 AM, Robbin Ehn wrote: >>> Hi, please review, >>> >>> After discussion with platform maintainers we keep the option around in JDK 11 also. It's not decided which release it will obsoleted in, so we set it to a future one. >> The bug info for this one is: >> JDK-8193514 UseMembar should not be obsoleted yet >> https://bugs.openjdk.java.net/browse/JDK-8193514 > > Thanks! > >>> >>> Passes: >>> open/test/hotspot/jtreg/runtime/CommandLine/ >>> >>> /Robbin >>> >>> diff -r 6d4e1efac80a src/hotspot/share/runtime/arguments.cpp >>> --- a/src/hotspot/share/runtime/arguments.cpp Wed Dec 13 15:37:48 2017 -0800 >>> +++ b/src/hotspot/share/runtime/arguments.cpp Fri Dec 15 14:04:38 2017 +0100 >>> @@ -499,3 +499,3 @@ >>> { "InitialRAMFraction", JDK_Version::jdk(10), JDK_Version::undefined(), JDK_Version::undefined() }, >>> - { "UseMembar", JDK_Version::jdk(10), JDK_Version::jdk(11), JDK_Version::jdk(12) }, >>> + { "UseMembar", JDK_Version::jdk(10), JDK_Version::undefined(), JDK_Version::undefined() }, >>> { "FastTLABRefill", JDK_Version::jdk(10), JDK_Version::jdk(11), JDK_Version::jdk(12) }, >> Thumbs up! > > And thanks again! > > /Robbin > >> Dan From adinn at redhat.com Fri Dec 15 15:11:42 2017 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 15 Dec 2017 15:11:42 +0000 Subject: RFR(XS): 8193521: glibc wastes memory with default configuration In-Reply-To: <50e1c28feb0e493bb42ec4442a01160f@sap.com> References: <21fef818a07b4b96a433fd80f3529525@sap.com> <52cf934f-87c1-2e84-bd0b-1298d766943e@redhat.com> <6f95ad6c-dea4-8bc3-a7c9-3ca25b7a60b9@redhat.com> <7b794a15-9b88-2317-a363-2f830a7091bb@redhat.com> <6d275c67b9534b70ab82d38bff3d98c3@sap.com> <50e1c28feb0e493bb42ec4442a01160f@sap.com> Message-ID: <766c70ee-412e-8b76-94aa-b8e05d1ea626@redhat.com> On 15/12/17 12:31, Doerr, Martin wrote: > We are testing the change and didn't see performance regressions, > yet. But we have to run more benchmarks, especially with G1 (see mail > from Thomas Schatzl). Large server tests will be interesting as > well. > > I can't really estimate the risk for native libs and I can understand > the concern. Maybe it would be acceptable if the change gets > switchable. Well, I think Andrew Haley's point was that it already is switchable -- by setting MALLOC_ARENA_MAX to 1. Of course, there is still a position between that status quo and your patch where the JVM makes the config call to the malloc library unless the user explicitly inhibits it e.g. via a new command line -XX option or using an alternative env setting. That would allow a get-out for any users affected. However, the get-out also assumes they know this change is responsible and how to undo it. I am not sure our support org would enjoy fielding the calls this might give rise to. We (Red Hat) are indeed considering setting MALLOC_ARENA_MAX=1 in some of our cloud deployments so as to avoid this allocation cost. It might be appropriate where, say, -Xmx is set under some low threshold. However, if we were to do that it would be under control of the script launching the JVM rather than OpenJDK and would not reverse any prior setting by our users. I don't see why others cannot follow a similar path. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From coleen.phillimore at oracle.com Fri Dec 15 15:21:59 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 15 Dec 2017 10:21:59 -0500 Subject: [JDK 11] RFR: (XS) 8193364: verify_special_jvm_flags should not cause an assertion failure when version is bumped In-Reply-To: References: <84996d65-9a22-3e44-a0d2-87eadea6b914@oracle.com> Message-ID: This looks good. Coleen On 12/15/17 8:17 AM, Daniel D. Daugherty wrote: > On 12/14/17 9:29 PM, David Holmes wrote: >> Hi Dan, >> >> Thanks for looking at this. >> >> I opted to add an explanatory comment block before the method instead. >> >> http://cr.openjdk.java.net/~dholmes/8193364/webrev.v1/ > > src/hotspot/share/runtime/arguments.cpp > ??? No comments. > > Thumbs up! > > Dan > > >> >> Thanks, >> David >> ----- >> >> On 13/12/2017 11:51 PM, Daniel D. Daugherty wrote: >>> On 12/13/17 12:03 AM, David Holmes wrote: >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8193364 >>>> webrev: http://cr.openjdk.java.net/~dholmes/8193364/webrev/ >>>> >>>> verify_special_jvm_flags operates only in debug builds and sanity >>>> checks the entries in the deprecated/obsoleted/expired/aliased >>>> tables. In addition it detects whether we have not yet removed the >>>> global variables for flags that are obsolete/expired, and issues a >>>> warning. In the latter case though it also returns false and causes >>>> the assertion to fail. This make it impossible to bump the JDK >>>> version without dealing with every flag en-masse. >>>> >>>> We should issue the warnings but not fail the assert in these cases. >>>> >>>> --- old/src/hotspot/share/runtime/arguments.cpp 2017-12-12 >>>> 23:59:14.039718085 -0500 >>>> +++ new/src/hotspot/share/runtime/arguments.cpp 2017-12-12 >>>> 23:59:11.575576703 -0500 >>>> @@ -710,7 +710,6 @@ >>>> ?????? if (!version_less_than(JDK_Version::current(), >>>> flag.obsolete_in)) { >>>> ???????? if (Flag::find_flag(flag.name) != NULL) { >>>> ?????????? warning("Global variable for obsolete special flag entry >>>> \"%s\" should be removed", flag.name); >>>> -????????? success = false; >>> >>> You should add a comment in place of the removed to line. >>> Otherwise, someone reading that function will think that >>> setting 'success' to false was just missed. Perhaps: >>> >>> ?????????? // Do not set success to 'false' in this case since >>> ?????????? // we only want a warning here for ease of transition >>> ?????????? // to a new release. >>> >>>> } >>>> ?????? } >>>> ???? } >>>> @@ -720,7 +719,6 @@ >>>> ?????? if (!version_less_than(JDK_Version::current(), >>>> flag.expired_in)) { >>>> ???????? if (Flag::find_flag(flag.name) != NULL) { >>>> ?????????? warning("Global variable for expired flag entry \"%s\" >>>> should be removed", flag.name); >>>> -????????? success = false; >>> >>> And perhaps: >>> >>> ?????????? // Do not set success to 'false'; see above note. >>> >>> Dan >>> >>> >>>> } >>>> ?????? } >>>> ???? } >>>> >>>> This need was flagged when we went to JDK 10 (see JDK-8173421) but >>>> not actioned. We need it now before we bump the version for JDK 11. >>>> >>>> Thanks, >>>> David >>> > From coleen.phillimore at oracle.com Fri Dec 15 15:54:05 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 15 Dec 2017 10:54:05 -0500 Subject: Review Request JDK-8193325: StackFrameInfo::getByteCodeIndex returns wrong value if bci > 32767 In-Reply-To: <4cf575a1-d420-fb44-cc38-03287366ec3d@oracle.com> References: <4cf575a1-d420-fb44-cc38-03287366ec3d@oracle.com> Message-ID: <9a31e94b-2cc0-ef7c-076e-ad2710f5088c@oracle.com> Hi, The hotspot part looks good. Thanks! Coleen On 12/12/17 7:42 PM, mandy chung wrote: > http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8193325/webrev.00/ > > This fixes the bug in hotspot that sets the bci field as int but it's > of short type and also StackFrameInfo to return a proper bci value.? > Coleen suggests not to change set_bci to take jushort but instead do > the cast as in the proposed fix.? The VM is in favor of C++ types and > stop propagation of Java types.? bci is of int in VM implementation > and so be consistent. > > Mandy > [1] > mail.openjdk.java.net/pipermail/core-libs-dev/2017-December/050581.html From martin.doerr at sap.com Fri Dec 15 15:57:45 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 15 Dec 2017 15:57:45 +0000 Subject: RFR(XS): 8193509: Test dynamic path to retrieve active processor count. In-Reply-To: <694ba799-5f9f-742b-3c5b-d50799f0dd4d@oracle.com> References: <4202f82c4cce404c97b2012be1096f30@sap.com> <5104fd17-a4ad-72f7-ece0-987daf9aa938@oracle.com> <8c55fe9b9964421eb1b591cafbed8298@sap.com> <38531b07-45df-f541-3749-1ac6ed64cb16@oracle.com> <694ba799-5f9f-742b-3c5b-d50799f0dd4d@oracle.com> Message-ID: <21493666c4834c9f94680c9f4b5e157f@sap.com> Hi G?tz, thanks for providing this test which runs through the CPU_ALLOC code path. Looks good. Best regards, Martin -----Original Message----- From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of David Holmes Sent: Donnerstag, 14. Dezember 2017 23:55 To: Lindenmaier, Goetz ; hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR(XS): 8193509: Test dynamic path to retrieve active processor count. My testing passed. So just needing second review. Also for now I suggest ensuring the "FixVersion" is not set when doing the push, as the correct version for JDK 11 has not yet been set in the configuration info used by hgupdater. Otherwise if you correctly set FixVersion to 11, hgupdater will create a 10 backport; if you set it to 10 and hgupdater gets fixed before you push, then you will get a backport for 11. So leave it blank or just wait until we know hgupdater is doing the right thing. Thanks, David On 15/12/2017 7:12 AM, David Holmes wrote: > Hi Goetz, > > On 14/12/2017 11:01 PM, Lindenmaier, Goetz wrote: >> Hi David, >> >> I implemented the test to detect iff the VM is run on an older OS >> than it was compiled on which lacks the CPU_ALLOC support. >> Basically that's what I wrote into the @summary :) > > So do you plan on running the test on such older OS? And on such an OS > will you ever find >1024 processors and so try to really take the path > that test shows is not usable ? > >> I ran the test with jdk 9 on ppc64, ppc64le, s390, x86_64, >> SLES 11, 12; RHEL 6, 7 (not all combinations, though). >> Tonight it will run with jdk/hs and a similar coverage.? (Actually, the >> test has been in the test suite for the other platforms, too, but >> is skipped there, so skipping is tested, too.) >> >> New webrev with renamed test: >> http://cr.openjdk.java.net/~goetz/wr17/8193509-activeProcTest/webrev.02/ > > Okay. I'll apply it locally and run on our systems just for a sanity > check. Meanwhile a second reviewer is needed. > > Thanks, > David > >> >> Best regards, >> ? Goetz. >> >> >> >> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Donnerstag, 14. Dezember 2017 13:40 >>> To: Lindenmaier, Goetz ; hotspot-runtime- >>> dev at openjdk.java.net >>> Subject: Re: RFR(XS): 8193509: Test dynamic path to retrieve active >>> processor >>> count. >>> >>> Hi Goetz, >>> >>> On 14/12/2017 10:06 PM, Lindenmaier, Goetz wrote: >>>> Hi, >>>> >>>> active_processor_count() in os_linux.cpp has two paths, one is only >>>> excercised if the VM runs on a machine with more than 1024 processors. >>>> Flag UseCpuAllocPath allows to force this path. Add a test with >>>> this flag to excercise this code. >>> >>> Not sure I see the value in having a test for this. Where would this >>> test run such that it would show us there is some problem that needs >>> fixing? The real test of that code path is on a machine with > 1024 >>> processors. >>> >>> That aside please reformat the >>> >>> ??? 29? * @summary If #processors > 1024 os_linux.cpp uses special >>> coding. Excercise this by forcing usage of this coding. If this fails, >>> this VM was either compiled on a platform which does not define >>> CPU_ALLOC, or it is executed on a platform that does not support it. >>> >>> to use multiple lines. Though a simple: >>> >>> @summary? Test the UseCpuAllocPath code path >>> >>> would suffice IMHO. >>> >>> And the name of the test should more accurately be TestUseCpuAllocPath. >>> >>>> Please review this change. I please need a sponsor. (Do I need one with >>> the new repo setup?) >>>> http://cr.openjdk.java.net/~goetz/wr17/8193509- >>> activeProcTest/webrev.01/ >>> >>> The need for a sponsor is not related to the repo setup, but the need >>> for adequate cross-platform testing. If the set of platforms you've >>> tested on includes all the platforms Oracle would test on, then a >>> sponsor would not add anything to the equation. But your RFR needs to >>> include what testing you have done. >>> >>> Thanks, >>> David >>> >>>> Best regards, >>>> ??? Goetz. >>>> From goetz.lindenmaier at sap.com Fri Dec 15 16:48:07 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 15 Dec 2017 16:48:07 +0000 Subject: RFR(XS): 8193509: Test dynamic path to retrieve active processor count. In-Reply-To: <21493666c4834c9f94680c9f4b5e157f@sap.com> References: <4202f82c4cce404c97b2012be1096f30@sap.com> <5104fd17-a4ad-72f7-ece0-987daf9aa938@oracle.com> <8c55fe9b9964421eb1b591cafbed8298@sap.com> <38531b07-45df-f541-3749-1ac6ed64cb16@oracle.com> <694ba799-5f9f-742b-3c5b-d50799f0dd4d@oracle.com> <21493666c4834c9f94680c9f4b5e157f@sap.com> Message-ID: <5fb5491607fd43568930ba16b27f4845@sap.com> Thanks, Martin! Best regards, Goetz. > -----Original Message----- > From: Doerr, Martin > Sent: Freitag, 15. Dezember 2017 16:58 > To: David Holmes ; Lindenmaier, Goetz > ; hotspot-runtime-dev at openjdk.java.net > Subject: RE: RFR(XS): 8193509: Test dynamic path to retrieve active processor > count. > > Hi G?tz, > > thanks for providing this test which runs through the CPU_ALLOC code path. > Looks good. > > Best regards, > Martin > > > -----Original Message----- > From: hotspot-runtime-dev [mailto:hotspot-runtime-dev- > bounces at openjdk.java.net] On Behalf Of David Holmes > Sent: Donnerstag, 14. Dezember 2017 23:55 > To: Lindenmaier, Goetz ; hotspot-runtime- > dev at openjdk.java.net > Subject: Re: RFR(XS): 8193509: Test dynamic path to retrieve active processor > count. > > My testing passed. So just needing second review. > > Also for now I suggest ensuring the "FixVersion" is not set when doing > the push, as the correct version for JDK 11 has not yet been set in the > configuration info used by hgupdater. Otherwise if you correctly set > FixVersion to 11, hgupdater will create a 10 backport; if you set it to > 10 and hgupdater gets fixed before you push, then you will get a > backport for 11. So leave it blank or just wait until we know hgupdater > is doing the right thing. > > Thanks, > David > > On 15/12/2017 7:12 AM, David Holmes wrote: > > Hi Goetz, > > > > On 14/12/2017 11:01 PM, Lindenmaier, Goetz wrote: > >> Hi David, > >> > >> I implemented the test to detect iff the VM is run on an older OS > >> than it was compiled on which lacks the CPU_ALLOC support. > >> Basically that's what I wrote into the @summary :) > > > > So do you plan on running the test on such older OS? And on such an OS > > will you ever find >1024 processors and so try to really take the path > > that test shows is not usable ? > > > >> I ran the test with jdk 9 on ppc64, ppc64le, s390, x86_64, > >> SLES 11, 12; RHEL 6, 7 (not all combinations, though). > >> Tonight it will run with jdk/hs and a similar coverage.? (Actually, the > >> test has been in the test suite for the other platforms, too, but > >> is skipped there, so skipping is tested, too.) > >> > >> New webrev with renamed test: > >> http://cr.openjdk.java.net/~goetz/wr17/8193509- > activeProcTest/webrev.02/ > > > > Okay. I'll apply it locally and run on our systems just for a sanity > > check. Meanwhile a second reviewer is needed. > > > > Thanks, > > David > > > >> > >> Best regards, > >> ? Goetz. > >> > >> > >> > >> > >>> -----Original Message----- > >>> From: David Holmes [mailto:david.holmes at oracle.com] > >>> Sent: Donnerstag, 14. Dezember 2017 13:40 > >>> To: Lindenmaier, Goetz ; hotspot- > runtime- > >>> dev at openjdk.java.net > >>> Subject: Re: RFR(XS): 8193509: Test dynamic path to retrieve active > >>> processor > >>> count. > >>> > >>> Hi Goetz, > >>> > >>> On 14/12/2017 10:06 PM, Lindenmaier, Goetz wrote: > >>>> Hi, > >>>> > >>>> active_processor_count() in os_linux.cpp has two paths, one is only > >>>> excercised if the VM runs on a machine with more than 1024 > processors. > >>>> Flag UseCpuAllocPath allows to force this path. Add a test with > >>>> this flag to excercise this code. > >>> > >>> Not sure I see the value in having a test for this. Where would this > >>> test run such that it would show us there is some problem that needs > >>> fixing? The real test of that code path is on a machine with > 1024 > >>> processors. > >>> > >>> That aside please reformat the > >>> > >>> ??? 29? * @summary If #processors > 1024 os_linux.cpp uses special > >>> coding. Excercise this by forcing usage of this coding. If this fails, > >>> this VM was either compiled on a platform which does not define > >>> CPU_ALLOC, or it is executed on a platform that does not support it. > >>> > >>> to use multiple lines. Though a simple: > >>> > >>> @summary? Test the UseCpuAllocPath code path > >>> > >>> would suffice IMHO. > >>> > >>> And the name of the test should more accurately be > TestUseCpuAllocPath. > >>> > >>>> Please review this change. I please need a sponsor. (Do I need one > with > >>> the new repo setup?) > >>>> http://cr.openjdk.java.net/~goetz/wr17/8193509- > >>> activeProcTest/webrev.01/ > >>> > >>> The need for a sponsor is not related to the repo setup, but the need > >>> for adequate cross-platform testing. If the set of platforms you've > >>> tested on includes all the platforms Oracle would test on, then a > >>> sponsor would not add anything to the equation. But your RFR needs to > >>> include what testing you have done. > >>> > >>> Thanks, > >>> David > >>> > >>>> Best regards, > >>>> ??? Goetz. > >>>> From goetz.lindenmaier at sap.com Fri Dec 15 16:49:15 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 15 Dec 2017 16:49:15 +0000 Subject: RFR(XS): 8193509: Test dynamic path to retrieve active processor count. In-Reply-To: <694ba799-5f9f-742b-3c5b-d50799f0dd4d@oracle.com> References: <4202f82c4cce404c97b2012be1096f30@sap.com> <5104fd17-a4ad-72f7-ece0-987daf9aa938@oracle.com> <8c55fe9b9964421eb1b591cafbed8298@sap.com> <38531b07-45df-f541-3749-1ac6ed64cb16@oracle.com> <694ba799-5f9f-742b-3c5b-d50799f0dd4d@oracle.com> Message-ID: <939c7a8a1f664419908e4fc90c5c0795@sap.com> Hi David, thanks for reviewing, and especially for running the tests! Best regards, Goetz. > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Donnerstag, 14. Dezember 2017 23:55 > To: Lindenmaier, Goetz ; hotspot-runtime- > dev at openjdk.java.net > Subject: Re: RFR(XS): 8193509: Test dynamic path to retrieve active processor > count. > > My testing passed. So just needing second review. > > Also for now I suggest ensuring the "FixVersion" is not set when doing > the push, as the correct version for JDK 11 has not yet been set in the > configuration info used by hgupdater. Otherwise if you correctly set > FixVersion to 11, hgupdater will create a 10 backport; if you set it to > 10 and hgupdater gets fixed before you push, then you will get a > backport for 11. So leave it blank or just wait until we know hgupdater > is doing the right thing. > > Thanks, > David > > On 15/12/2017 7:12 AM, David Holmes wrote: > > Hi Goetz, > > > > On 14/12/2017 11:01 PM, Lindenmaier, Goetz wrote: > >> Hi David, > >> > >> I implemented the test to detect iff the VM is run on an older OS > >> than it was compiled on which lacks the CPU_ALLOC support. > >> Basically that's what I wrote into the @summary :) > > > > So do you plan on running the test on such older OS? And on such an OS > > will you ever find >1024 processors and so try to really take the path > > that test shows is not usable ? > > > >> I ran the test with jdk 9 on ppc64, ppc64le, s390, x86_64, > >> SLES 11, 12; RHEL 6, 7 (not all combinations, though). > >> Tonight it will run with jdk/hs and a similar coverage.? (Actually, the > >> test has been in the test suite for the other platforms, too, but > >> is skipped there, so skipping is tested, too.) > >> > >> New webrev with renamed test: > >> http://cr.openjdk.java.net/~goetz/wr17/8193509- > activeProcTest/webrev.02/ > > > > Okay. I'll apply it locally and run on our systems just for a sanity > > check. Meanwhile a second reviewer is needed. > > > > Thanks, > > David > > > >> > >> Best regards, > >> ? Goetz. > >> > >> > >> > >> > >>> -----Original Message----- > >>> From: David Holmes [mailto:david.holmes at oracle.com] > >>> Sent: Donnerstag, 14. Dezember 2017 13:40 > >>> To: Lindenmaier, Goetz ; hotspot- > runtime- > >>> dev at openjdk.java.net > >>> Subject: Re: RFR(XS): 8193509: Test dynamic path to retrieve active > >>> processor > >>> count. > >>> > >>> Hi Goetz, > >>> > >>> On 14/12/2017 10:06 PM, Lindenmaier, Goetz wrote: > >>>> Hi, > >>>> > >>>> active_processor_count() in os_linux.cpp has two paths, one is only > >>>> excercised if the VM runs on a machine with more than 1024 > processors. > >>>> Flag UseCpuAllocPath allows to force this path. Add a test with > >>>> this flag to excercise this code. > >>> > >>> Not sure I see the value in having a test for this. Where would this > >>> test run such that it would show us there is some problem that needs > >>> fixing? The real test of that code path is on a machine with > 1024 > >>> processors. > >>> > >>> That aside please reformat the > >>> > >>> ??? 29? * @summary If #processors > 1024 os_linux.cpp uses special > >>> coding. Excercise this by forcing usage of this coding. If this fails, > >>> this VM was either compiled on a platform which does not define > >>> CPU_ALLOC, or it is executed on a platform that does not support it. > >>> > >>> to use multiple lines. Though a simple: > >>> > >>> @summary? Test the UseCpuAllocPath code path > >>> > >>> would suffice IMHO. > >>> > >>> And the name of the test should more accurately be > TestUseCpuAllocPath. > >>> > >>>> Please review this change. I please need a sponsor. (Do I need one > with > >>> the new repo setup?) > >>>> http://cr.openjdk.java.net/~goetz/wr17/8193509- > >>> activeProcTest/webrev.01/ > >>> > >>> The need for a sponsor is not related to the repo setup, but the need > >>> for adequate cross-platform testing. If the set of platforms you've > >>> tested on includes all the platforms Oracle would test on, then a > >>> sponsor would not add anything to the equation. But your RFR needs to > >>> include what testing you have done. > >>> > >>> Thanks, > >>> David > >>> > >>>> Best regards, > >>>> ??? Goetz. > >>>> From david.holmes at oracle.com Sat Dec 16 02:22:10 2017 From: david.holmes at oracle.com (David Holmes) Date: Sat, 16 Dec 2017 12:22:10 +1000 Subject: [JDK 11] RFR: (XS) 8193364: verify_special_jvm_flags should not cause an assertion failure when version is bumped In-Reply-To: References: <84996d65-9a22-3e44-a0d2-87eadea6b914@oracle.com> Message-ID: <96f95ca6-75ff-816c-d23f-737cb31342b6@oracle.com> Thanks Dan! David On 15/12/2017 11:17 PM, Daniel D. Daugherty wrote: > On 12/14/17 9:29 PM, David Holmes wrote: >> Hi Dan, >> >> Thanks for looking at this. >> >> I opted to add an explanatory comment block before the method instead. >> >> http://cr.openjdk.java.net/~dholmes/8193364/webrev.v1/ > > src/hotspot/share/runtime/arguments.cpp > ??? No comments. > > Thumbs up! > > Dan > > >> >> Thanks, >> David >> ----- >> >> On 13/12/2017 11:51 PM, Daniel D. Daugherty wrote: >>> On 12/13/17 12:03 AM, David Holmes wrote: >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8193364 >>>> webrev: http://cr.openjdk.java.net/~dholmes/8193364/webrev/ >>>> >>>> verify_special_jvm_flags operates only in debug builds and sanity >>>> checks the entries in the deprecated/obsoleted/expired/aliased >>>> tables. In addition it detects whether we have not yet removed the >>>> global variables for flags that are obsolete/expired, and issues a >>>> warning. In the latter case though it also returns false and causes >>>> the assertion to fail. This make it impossible to bump the JDK >>>> version without dealing with every flag en-masse. >>>> >>>> We should issue the warnings but not fail the assert in these cases. >>>> >>>> --- old/src/hotspot/share/runtime/arguments.cpp??? 2017-12-12 >>>> 23:59:14.039718085 -0500 >>>> +++ new/src/hotspot/share/runtime/arguments.cpp??? 2017-12-12 >>>> 23:59:11.575576703 -0500 >>>> @@ -710,7 +710,6 @@ >>>> ?????? if (!version_less_than(JDK_Version::current(), >>>> flag.obsolete_in)) { >>>> ???????? if (Flag::find_flag(flag.name) != NULL) { >>>> ?????????? warning("Global variable for obsolete special flag entry >>>> \"%s\" should be removed", flag.name); >>>> -????????? success = false; >>> >>> You should add a comment in place of the removed to line. >>> Otherwise, someone reading that function will think that >>> setting 'success' to false was just missed. Perhaps: >>> >>> ?????????? // Do not set success to 'false' in this case since >>> ?????????? // we only want a warning here for ease of transition >>> ?????????? // to a new release. >>> >>>> } >>>> ?????? } >>>> ???? } >>>> @@ -720,7 +719,6 @@ >>>> ?????? if (!version_less_than(JDK_Version::current(), >>>> flag.expired_in)) { >>>> ???????? if (Flag::find_flag(flag.name) != NULL) { >>>> ?????????? warning("Global variable for expired flag entry \"%s\" >>>> should be removed", flag.name); >>>> -????????? success = false; >>> >>> And perhaps: >>> >>> ?????????? // Do not set success to 'false'; see above note. >>> >>> Dan >>> >>> >>>> } >>>> ?????? } >>>> ???? } >>>> >>>> This need was flagged when we went to JDK 10 (see JDK-8173421) but >>>> not actioned. We need it now before we bump the version for JDK 11. >>>> >>>> Thanks, >>>> David >>> > From david.holmes at oracle.com Sat Dec 16 02:22:24 2017 From: david.holmes at oracle.com (David Holmes) Date: Sat, 16 Dec 2017 12:22:24 +1000 Subject: [JDK 11] RFR: (XS) 8193364: verify_special_jvm_flags should not cause an assertion failure when version is bumped In-Reply-To: References: <84996d65-9a22-3e44-a0d2-87eadea6b914@oracle.com> Message-ID: Thanks Coleen! David On 16/12/2017 1:21 AM, coleen.phillimore at oracle.com wrote: > This looks good. > Coleen > > On 12/15/17 8:17 AM, Daniel D. Daugherty wrote: >> On 12/14/17 9:29 PM, David Holmes wrote: >>> Hi Dan, >>> >>> Thanks for looking at this. >>> >>> I opted to add an explanatory comment block before the method instead. >>> >>> http://cr.openjdk.java.net/~dholmes/8193364/webrev.v1/ >> >> src/hotspot/share/runtime/arguments.cpp >> ??? No comments. >> >> Thumbs up! >> >> Dan >> >> >>> >>> Thanks, >>> David >>> ----- >>> >>> On 13/12/2017 11:51 PM, Daniel D. Daugherty wrote: >>>> On 12/13/17 12:03 AM, David Holmes wrote: >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8193364 >>>>> webrev: http://cr.openjdk.java.net/~dholmes/8193364/webrev/ >>>>> >>>>> verify_special_jvm_flags operates only in debug builds and sanity >>>>> checks the entries in the deprecated/obsoleted/expired/aliased >>>>> tables. In addition it detects whether we have not yet removed the >>>>> global variables for flags that are obsolete/expired, and issues a >>>>> warning. In the latter case though it also returns false and causes >>>>> the assertion to fail. This make it impossible to bump the JDK >>>>> version without dealing with every flag en-masse. >>>>> >>>>> We should issue the warnings but not fail the assert in these cases. >>>>> >>>>> --- old/src/hotspot/share/runtime/arguments.cpp 2017-12-12 >>>>> 23:59:14.039718085 -0500 >>>>> +++ new/src/hotspot/share/runtime/arguments.cpp 2017-12-12 >>>>> 23:59:11.575576703 -0500 >>>>> @@ -710,7 +710,6 @@ >>>>> ?????? if (!version_less_than(JDK_Version::current(), >>>>> flag.obsolete_in)) { >>>>> ???????? if (Flag::find_flag(flag.name) != NULL) { >>>>> ?????????? warning("Global variable for obsolete special flag entry >>>>> \"%s\" should be removed", flag.name); >>>>> -????????? success = false; >>>> >>>> You should add a comment in place of the removed to line. >>>> Otherwise, someone reading that function will think that >>>> setting 'success' to false was just missed. Perhaps: >>>> >>>> ?????????? // Do not set success to 'false' in this case since >>>> ?????????? // we only want a warning here for ease of transition >>>> ?????????? // to a new release. >>>> >>>>> } >>>>> ?????? } >>>>> ???? } >>>>> @@ -720,7 +719,6 @@ >>>>> ?????? if (!version_less_than(JDK_Version::current(), >>>>> flag.expired_in)) { >>>>> ???????? if (Flag::find_flag(flag.name) != NULL) { >>>>> ?????????? warning("Global variable for expired flag entry \"%s\" >>>>> should be removed", flag.name); >>>>> -????????? success = false; >>>> >>>> And perhaps: >>>> >>>> ?????????? // Do not set success to 'false'; see above note. >>>> >>>> Dan >>>> >>>> >>>>> } >>>>> ?????? } >>>>> ???? } >>>>> >>>>> This need was flagged when we went to JDK 10 (see JDK-8173421) but >>>>> not actioned. We need it now before we bump the version for JDK 11. >>>>> >>>>> Thanks, >>>>> David >>>> >> > From ioi.lam at oracle.com Sun Dec 17 01:26:37 2017 From: ioi.lam at oracle.com (Ioi Lam) Date: Sat, 16 Dec 2017 17:26:37 -0800 Subject: RFR[M] 8193672 - [test] Enhance vm.cds property to check for all conditions required to run CDS tests Message-ID: <8d4d9612-ffb6-b806-2fa4-eb2cdbb1bbf8@oracle.com> Hi, Please review this fix that touches many test cases with simple changes. - https://bugs.openjdk.java.net/browse/JDK-8193672 - http://cr.openjdk.java.net/~iklam/jdk11/8193672.enhance.vm.cds.test.property.v01/ SUMMARY ======= All the test changes look like this: Before: * AppCDS does not support uncompressed oops" * @requires (vm.opt.UseCompressedOops == null) | (vm.opt.UseCompressedOops == true) After: * @requires vm.cds This makes the tests easier to maintain, as we no longer need to leak the implementation dependencies of CDS into all of the test cases. The check for "(vm.opt.UseCompressedOops == null) | (vm.opt.UseCompressedOops == true)" is now moved into whitebox.cpp (the first file in the webrev page). TESTING ======= Tested with hotspot tier1 and tier2, which include all the CDS tests. Thanks! - Ioi From david.holmes at oracle.com Sun Dec 17 07:33:15 2017 From: david.holmes at oracle.com (David Holmes) Date: Sun, 17 Dec 2017 17:33:15 +1000 Subject: RFR[M] 8193672 - [test] Enhance vm.cds property to check for all conditions required to run CDS tests In-Reply-To: <8d4d9612-ffb6-b806-2fa4-eb2cdbb1bbf8@oracle.com> References: <8d4d9612-ffb6-b806-2fa4-eb2cdbb1bbf8@oracle.com> Message-ID: <15699928-a996-2344-7f30-49bb2a17dd61@oracle.com> Looks okay. Thanks, David On 17/12/2017 11:26 AM, Ioi Lam wrote: > Hi, > > Please review this fix that touches many test cases with simple changes. > > - https://bugs.openjdk.java.net/browse/JDK-8193672 > - > http://cr.openjdk.java.net/~iklam/jdk11/8193672.enhance.vm.cds.test.property.v01/ > > > > SUMMARY > ======= > > All the test changes look like this: > > Before: > > * AppCDS does not support uncompressed oops" > * @requires (vm.opt.UseCompressedOops == null) | > (vm.opt.UseCompressedOops == true) > > After: > > * @requires vm.cds > > This makes the tests easier to maintain, as we no longer need to > leak the implementation dependencies of CDS into all of the test cases. > > > The check for "(vm.opt.UseCompressedOops == null) | > (vm.opt.UseCompressedOops == true)" > is now moved into whitebox.cpp (the first file in the webrev page). > > > TESTING > ======= > > Tested with hotspot tier1 and tier2, which include all the CDS tests. > > > Thanks! > - Ioi > From robbin.ehn at oracle.com Mon Dec 18 08:39:42 2017 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Mon, 18 Dec 2017 09:39:42 +0100 Subject: RFR(one-liner): 8193514: UseMembar should not be obsoleted yet In-Reply-To: <8E393110-7C3E-4F3A-AE1E-A553FE7FFC18@oracle.com> References: <3884984f-f4b9-0d23-80a0-66da0fc2c05f@oracle.com> <7e5a2659-8ddb-e5f4-8e33-0286cdd4ad74@oracle.com> <8E393110-7C3E-4F3A-AE1E-A553FE7FFC18@oracle.com> Message-ID: <9d29a626-2c93-af66-090d-2e30a88c3855@oracle.com> Thanks Karen. /Robbin On 2017-12-15 15:44, Karen Kinnear wrote: > Thanks Robbin for working this out with the community and for the change. Looks good. > > Karen > >> On Dec 15, 2017, at 8:27 AM, Robbin Ehn > wrote: >> >> >> On 12/15/2017 02:20 PM, Daniel D. Daugherty wrote: >>> On 12/15/17 8:12 AM, Robbin Ehn wrote: >>>> Hi, please review, >>>> >>>> After discussion with platform maintainers we keep the option around in JDK 11 also. It's not decided which release it will obsoleted in, so we set it to a future one. >>> The bug info for this one is: >>> JDK-8193514 UseMembar should not be obsoleted yet >>> https://bugs.openjdk.java.net/browse/JDK-8193514 >> >> Thanks! >> >>>> >>>> Passes: >>>> open/test/hotspot/jtreg/runtime/CommandLine/ >>>> >>>> /Robbin >>>> >>>> diff -r 6d4e1efac80a src/hotspot/share/runtime/arguments.cpp >>>> --- a/src/hotspot/share/runtime/arguments.cpp??? Wed Dec 13 15:37:48 2017 -0800 >>>> +++ b/src/hotspot/share/runtime/arguments.cpp??? Fri Dec 15 14:04:38 2017 +0100 >>>> @@ -499,3 +499,3 @@ >>>> { "InitialRAMFraction",?????????? JDK_Version::jdk(10), JDK_Version::undefined(), JDK_Version::undefined() }, >>>> -? { "UseMembar",??????????????????? JDK_Version::jdk(10), JDK_Version::jdk(11), JDK_Version::jdk(12) }, >>>> +? { "UseMembar",??????????????????? JDK_Version::jdk(10), JDK_Version::undefined(), JDK_Version::undefined() }, >>>> { "FastTLABRefill",?????????????? JDK_Version::jdk(10), JDK_Version::jdk(11), JDK_Version::jdk(12) }, >>> Thumbs up! >> >> And thanks again! >> >> /Robbin >> >>> Dan > From martin.doerr at sap.com Mon Dec 18 10:50:49 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 18 Dec 2017 10:50:49 +0000 Subject: RFR(one-liner): 8193514: UseMembar should not be obsoleted yet In-Reply-To: <8E393110-7C3E-4F3A-AE1E-A553FE7FFC18@oracle.com> References: <3884984f-f4b9-0d23-80a0-66da0fc2c05f@oracle.com> <7e5a2659-8ddb-e5f4-8e33-0286cdd4ad74@oracle.com> <8E393110-7C3E-4F3A-AE1E-A553FE7FFC18@oracle.com> Message-ID: Hi Robbin, thanks for changing. We appreciate the ability to switch it off for some time as long as the serialization page code doesn't disturb. Change looks good. Best regards, Martin -----Original Message----- From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Karen Kinnear Sent: Freitag, 15. Dezember 2017 15:45 To: Robbin Ehn Cc: hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR(one-liner): 8193514: UseMembar should not be obsoleted yet Thanks Robbin for working this out with the community and for the change. Looks good. Karen > On Dec 15, 2017, at 8:27 AM, Robbin Ehn wrote: > > > On 12/15/2017 02:20 PM, Daniel D. Daugherty wrote: >> On 12/15/17 8:12 AM, Robbin Ehn wrote: >>> Hi, please review, >>> >>> After discussion with platform maintainers we keep the option around in JDK 11 also. It's not decided which release it will obsoleted in, so we set it to a future one. >> The bug info for this one is: >> JDK-8193514 UseMembar should not be obsoleted yet >> https://bugs.openjdk.java.net/browse/JDK-8193514 > > Thanks! > >>> >>> Passes: >>> open/test/hotspot/jtreg/runtime/CommandLine/ >>> >>> /Robbin >>> >>> diff -r 6d4e1efac80a src/hotspot/share/runtime/arguments.cpp >>> --- a/src/hotspot/share/runtime/arguments.cpp Wed Dec 13 15:37:48 2017 -0800 >>> +++ b/src/hotspot/share/runtime/arguments.cpp Fri Dec 15 14:04:38 2017 +0100 >>> @@ -499,3 +499,3 @@ >>> { "InitialRAMFraction", JDK_Version::jdk(10), JDK_Version::undefined(), JDK_Version::undefined() }, >>> - { "UseMembar", JDK_Version::jdk(10), JDK_Version::jdk(11), JDK_Version::jdk(12) }, >>> + { "UseMembar", JDK_Version::jdk(10), JDK_Version::undefined(), JDK_Version::undefined() }, >>> { "FastTLABRefill", JDK_Version::jdk(10), JDK_Version::jdk(11), JDK_Version::jdk(12) }, >> Thumbs up! > > And thanks again! > > /Robbin > >> Dan From robbin.ehn at oracle.com Mon Dec 18 11:10:04 2017 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Mon, 18 Dec 2017 12:10:04 +0100 Subject: RFR(one-liner): 8193514: UseMembar should not be obsoleted yet In-Reply-To: References: <3884984f-f4b9-0d23-80a0-66da0fc2c05f@oracle.com> <7e5a2659-8ddb-e5f4-8e33-0286cdd4ad74@oracle.com> <8E393110-7C3E-4F3A-AE1E-A553FE7FFC18@oracle.com> Message-ID: <5b9b5ff2-d0f8-d61f-368c-a1d4af608400@oracle.com> Thanks Martin. /Robbin On 2017-12-18 11:50, Doerr, Martin wrote: > Hi Robbin, > > thanks for changing. We appreciate the ability to switch it off for some time as long as the serialization page code doesn't disturb. Change looks good. > > Best regards, > Martin > > > -----Original Message----- > From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Karen Kinnear > Sent: Freitag, 15. Dezember 2017 15:45 > To: Robbin Ehn > Cc: hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR(one-liner): 8193514: UseMembar should not be obsoleted yet > > Thanks Robbin for working this out with the community and for the change. Looks good. > > Karen > >> On Dec 15, 2017, at 8:27 AM, Robbin Ehn wrote: >> >> >> On 12/15/2017 02:20 PM, Daniel D. Daugherty wrote: >>> On 12/15/17 8:12 AM, Robbin Ehn wrote: >>>> Hi, please review, >>>> >>>> After discussion with platform maintainers we keep the option around in JDK 11 also. It's not decided which release it will obsoleted in, so we set it to a future one. >>> The bug info for this one is: >>> JDK-8193514 UseMembar should not be obsoleted yet >>> https://bugs.openjdk.java.net/browse/JDK-8193514 >> >> Thanks! >> >>>> >>>> Passes: >>>> open/test/hotspot/jtreg/runtime/CommandLine/ >>>> >>>> /Robbin >>>> >>>> diff -r 6d4e1efac80a src/hotspot/share/runtime/arguments.cpp >>>> --- a/src/hotspot/share/runtime/arguments.cpp Wed Dec 13 15:37:48 2017 -0800 >>>> +++ b/src/hotspot/share/runtime/arguments.cpp Fri Dec 15 14:04:38 2017 +0100 >>>> @@ -499,3 +499,3 @@ >>>> { "InitialRAMFraction", JDK_Version::jdk(10), JDK_Version::undefined(), JDK_Version::undefined() }, >>>> - { "UseMembar", JDK_Version::jdk(10), JDK_Version::jdk(11), JDK_Version::jdk(12) }, >>>> + { "UseMembar", JDK_Version::jdk(10), JDK_Version::undefined(), JDK_Version::undefined() }, >>>> { "FastTLABRefill", JDK_Version::jdk(10), JDK_Version::jdk(11), JDK_Version::jdk(12) }, >>> Thumbs up! >> >> And thanks again! >> >> /Robbin >> >>> Dan > From martin.doerr at sap.com Mon Dec 18 15:33:39 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 18 Dec 2017 15:33:39 +0000 Subject: RFR(XS): 8193521: glibc wastes memory with default configuration In-Reply-To: <766c70ee-412e-8b76-94aa-b8e05d1ea626@redhat.com> References: <21fef818a07b4b96a433fd80f3529525@sap.com> <52cf934f-87c1-2e84-bd0b-1298d766943e@redhat.com> <6f95ad6c-dea4-8bc3-a7c9-3ca25b7a60b9@redhat.com> <7b794a15-9b88-2317-a363-2f830a7091bb@redhat.com> <6d275c67b9534b70ab82d38bff3d98c3@sap.com> <50e1c28feb0e493bb42ec4442a01160f@sap.com> <766c70ee-412e-8b76-94aa-b8e05d1ea626@redhat.com> Message-ID: <235f15e98ff447d8b6925e2476c95324@sap.com> Hi both Andrews, thank you for looking into this issue and providing input. I have tried to summarize what we have so far and added a comment to the bug. I'd like to leave the bug open for a little longer. Best regards, Martin -----Original Message----- From: Andrew Dinn [mailto:adinn at redhat.com] Sent: Freitag, 15. Dezember 2017 16:12 To: Doerr, Martin ; Andrew Haley ; hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR(XS): 8193521: glibc wastes memory with default configuration On 15/12/17 12:31, Doerr, Martin wrote: > We are testing the change and didn't see performance regressions, > yet. But we have to run more benchmarks, especially with G1 (see mail > from Thomas Schatzl). Large server tests will be interesting as > well. > > I can't really estimate the risk for native libs and I can understand > the concern. Maybe it would be acceptable if the change gets > switchable. Well, I think Andrew Haley's point was that it already is switchable -- by setting MALLOC_ARENA_MAX to 1. Of course, there is still a position between that status quo and your patch where the JVM makes the config call to the malloc library unless the user explicitly inhibits it e.g. via a new command line -XX option or using an alternative env setting. That would allow a get-out for any users affected. However, the get-out also assumes they know this change is responsible and how to undo it. I am not sure our support org would enjoy fielding the calls this might give rise to. We (Red Hat) are indeed considering setting MALLOC_ARENA_MAX=1 in some of our cloud deployments so as to avoid this allocation cost. It might be appropriate where, say, -Xmx is set under some low threshold. However, if we were to do that it would be under control of the script launching the JVM rather than OpenJDK and would not reverse any prior setting by our users. I don't see why others cannot follow a similar path. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From dmitry.samersoff at bell-sw.com Mon Dec 18 16:51:23 2017 From: dmitry.samersoff at bell-sw.com (Dmitry Samersoff) Date: Mon, 18 Dec 2017 19:51:23 +0300 Subject: RFR[M] 8193672 - [test] Enhance vm.cds property to check for all conditions required to run CDS tests In-Reply-To: <8d4d9612-ffb6-b806-2fa4-eb2cdbb1bbf8@oracle.com> References: <8d4d9612-ffb6-b806-2fa4-eb2cdbb1bbf8@oracle.com> Message-ID: <317168aa-b8ee-7f90-6792-676dfb947dbd@bell-sw.com> Ioi, The fix looks good to me. -Dmitry 17/12/2017 04:26, Ioi Lam ?????: > Hi, > > Please review this fix that touches many test cases with simple changes. > > - https://bugs.openjdk.java.net/browse/JDK-8193672 > - > http://cr.openjdk.java.net/~iklam/jdk11/8193672.enhance.vm.cds.test.property.v01/ > > > > SUMMARY > ======= > > All the test changes look like this: > > Before: > > * AppCDS does not support uncompressed oops" > * @requires (vm.opt.UseCompressedOops == null) | > (vm.opt.UseCompressedOops == true) > > After: > > * @requires vm.cds > > This makes the tests easier to maintain, as we no longer need to > leak the implementation dependencies of CDS into all of the test cases. > > > The check for "(vm.opt.UseCompressedOops == null) | > (vm.opt.UseCompressedOops == true)" > is now moved into whitebox.cpp (the first file in the webrev page). > > > TESTING > ======= > > Tested with hotspot tier1 and tier2, which include all the CDS tests. > > > Thanks! > - Ioi > From goetz.lindenmaier at sap.com Mon Dec 18 17:19:47 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 18 Dec 2017 17:19:47 +0000 Subject: RFR[M] 8193672 - [test] Enhance vm.cds property to check for all conditions required to run CDS tests In-Reply-To: <317168aa-b8ee-7f90-6792-676dfb947dbd@bell-sw.com> References: <8d4d9612-ffb6-b806-2fa4-eb2cdbb1bbf8@oracle.com> <317168aa-b8ee-7f90-6792-676dfb947dbd@bell-sw.com> Message-ID: <012f56f7e179478fb3f260cbb8363c95@sap.com> Hi Ioi, Thanks for spreading the use of this property! Looks good. Best regards, Goetz. -----Original Message----- From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Dmitry Samersoff Sent: Monday, December 18, 2017 5:51 PM To: Ioi Lam ; hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR[M] 8193672 - [test] Enhance vm.cds property to check for all conditions required to run CDS tests Ioi, The fix looks good to me. -Dmitry 17/12/2017 04:26, Ioi Lam ?????: > Hi, > > Please review this fix that touches many test cases with simple changes. > > - https://bugs.openjdk.java.net/browse/JDK-8193672 > - > http://cr.openjdk.java.net/~iklam/jdk11/8193672.enhance.vm.cds.test.property.v01/ > > > > SUMMARY > ======= > > All the test changes look like this: > > Before: > > * AppCDS does not support uncompressed oops" > * @requires (vm.opt.UseCompressedOops == null) | > (vm.opt.UseCompressedOops == true) > > After: > > * @requires vm.cds > > This makes the tests easier to maintain, as we no longer need to > leak the implementation dependencies of CDS into all of the test cases. > > > The check for "(vm.opt.UseCompressedOops == null) | > (vm.opt.UseCompressedOops == true)" > is now moved into whitebox.cpp (the first file in the webrev page). > > > TESTING > ======= > > Tested with hotspot tier1 and tier2, which include all the CDS tests. > > > Thanks! > - Ioi > From david.buck at oracle.com Tue Dec 19 08:16:35 2017 From: david.buck at oracle.com (David Buck) Date: Tue, 19 Dec 2017 17:16:35 +0900 Subject: [8u] RFR(S) 8031304 : Add dcmd to print all loaded dynamic libraries Message-ID: Hi! Please review this straightforward serviceability backport to JDK 8. No real changes to product code. I just moved the import statements in the DynLibDcmdTest.java test case to below the copyright header. bug report: https://bugs.openjdk.java.net/browse/JDK-8031304 JDK 9 review thread: http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-January/013778.html JDK 9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/afa21611f918 JDK 8 webrev for review: http://cr.openjdk.java.net/~dbuck/8031304_jdk8_ver00/ Cheers, -Buck From coleen.phillimore at oracle.com Tue Dec 19 11:42:43 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 19 Dec 2017 06:42:43 -0500 Subject: RFR (S) 8193622: JFR test TestUnloadingEventClass.java times out intermittently Message-ID: Summary: Previous change was leaving scratch classes on CLD::_klasses list which are reported to tracing Tested with assert in tracing code and failed test, and mach4 tier1-5. open webrev at http://cr.openjdk.java.net/~coleenp/8193622.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8193622 This change is relative to jdk/hs repository but will be moved to jdk/jdk10 once the jdk/hs snapshot is integrated. Thanks, Coleen From george.triantafillou at oracle.com Tue Dec 19 15:19:06 2017 From: george.triantafillou at oracle.com (George Triantafillou) Date: Tue, 19 Dec 2017 10:19:06 -0500 Subject: RFR (S) 8193622: JFR test TestUnloadingEventClass.java times out intermittently In-Reply-To: References: Message-ID: <711cdb5f-03b1-6fd3-7b51-13b4960fc11d@oracle.com> Hi Coleen, Looks good. -George On 12/19/2017 6:42 AM, coleen.phillimore at oracle.com wrote: > Summary: Previous change was leaving scratch classes on CLD::_klasses > list which are reported to tracing > > Tested with assert in tracing code and failed test, and mach4 tier1-5. > > open webrev at http://cr.openjdk.java.net/~coleenp/8193622.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8193622 > > This change is relative to jdk/hs repository but will be moved to > jdk/jdk10 once the jdk/hs snapshot is integrated. > > Thanks, > Coleen From vladimir.x.ivanov at oracle.com Tue Dec 19 15:37:45 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 19 Dec 2017 18:37:45 +0300 Subject: [10] RFR (S): 8188145: MethodHandle resolution should follow JVMS sequence of lookup by name & type before type descriptor resolution Message-ID: http://cr.openjdk.java.net/~vlivanov/8188145/webrev.00 https://bugs.openjdk.java.net/browse/JDK-8188145 When resolving MethodHandle constants JVM eagerly resolves type descriptor before doing upcall into JDK which performs method/field resolution later (using MethodHandleNatives.resolve on symbolic MemberName). The problem is that according to JVMS, member resolution (and all exceptions it throws) should precede type descriptor resolution. Proposed fix does member & type descriptor resolution from JVM first and then passes symbolic info into JDK (MHN.linkMethodHandleConstant). The fix is conservative, since JDK repeats method/field resolution on a freshly created MemberName from symbolic info. But considering there are additional security-sensitive checks on JDK side, I decided to leave all optimizations for future enhancements. Testing: hs-precheckin-comp, hs-tier1, hs-tier2 Best regards, Vladimir Ivanov From daniel.daugherty at oracle.com Tue Dec 19 15:39:12 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 19 Dec 2017 10:39:12 -0500 Subject: RFR (S) 8193622: JFR test TestUnloadingEventClass.java times out intermittently In-Reply-To: References: Message-ID: <20478947-8478-9386-c946-9f8e528e505d@oracle.com> On 12/19/17 6:42 AM, coleen.phillimore at oracle.com wrote: > Summary: Previous change was leaving scratch classes on CLD::_klasses > list which are reported to tracing > > Tested with assert in tracing code and failed test, and mach4 tier1-5. > > open webrev at http://cr.openjdk.java.net/~coleenp/8193622.01/webrev src/hotspot/share/classfile/classLoaderData.cpp ??? No comments. Thumbs up! Dan > bug link https://bugs.openjdk.java.net/browse/JDK-8193622 > > This change is relative to jdk/hs repository but will be moved to > jdk/jdk10 once the jdk/hs snapshot is integrated. > > Thanks, > Coleen From markus.gronlund at oracle.com Tue Dec 19 15:40:45 2017 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Tue, 19 Dec 2017 07:40:45 -0800 (PST) Subject: RFR (S) 8193622: JFR test TestUnloadingEventClass.java times out intermittently In-Reply-To: References: Message-ID: <36065a81-b342-4cac-986b-9324c7c19ef3@default> Hi Coleen, Line 850 says: // Only constant pool entries have C heap memory to free. But, with the change, there is an additional else clause that seems to process klasses. Maybe remove the comment? Also: Is the metadata is_klass() check sufficient in allowing for a direct downcast to InstanceKlass* (not Klass*?). Maybe only InstanceKlass'es will ever be on the deallocation_list in this context? In addition: 857 // Remove the class so unloading events aren't triggered for 858 // this class (scratch or error class) in do_unloading(). 859 remove_class(ik); Does this not remove every klass? Not just a scratch or an error klass? Thanks Markus -----Original Message----- From: Coleen Phillimore Sent: den 19 december 2017 12:43 To: hotspot-runtime-dev at openjdk.java.net runtime Subject: RFR (S) 8193622: JFR test TestUnloadingEventClass.java times out intermittently Summary: Previous change was leaving scratch classes on CLD::_klasses list which are reported to tracing Tested with assert in tracing code and failed test, and mach4 tier1-5. open webrev at http://cr.openjdk.java.net/~coleenp/8193622.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8193622 This change is relative to jdk/hs repository but will be moved to jdk/jdk10 once the jdk/hs snapshot is integrated. Thanks, Coleen From coleen.phillimore at oracle.com Tue Dec 19 16:24:52 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 19 Dec 2017 11:24:52 -0500 Subject: RFR (S) 8193622: JFR test TestUnloadingEventClass.java times out intermittently In-Reply-To: <36065a81-b342-4cac-986b-9324c7c19ef3@default> References: <36065a81-b342-4cac-986b-9324c7c19ef3@default> Message-ID: <7c051dbb-e777-6082-07fa-da5bcf572046@oracle.com> On 12/19/17 10:40 AM, Markus Gronlund wrote: > Hi Coleen, > > Line 850 says: // Only constant pool entries have C heap memory to free. > > But, with the change, there is an additional else clause that seems to process klasses. > > Maybe remove the comment? Yes, I meant to remove that comment.? Thanks. > > Also: > > Is the metadata is_klass() check sufficient in allowing for a direct downcast to InstanceKlass* (not Klass*?). Maybe only InstanceKlass'es will ever be on the deallocation_list in this context? Yes, only InstanceKlass will be on the deallocate list.? I should change this and free_deallocate_list with a future RFE.? I used is_klass() because that's what free_deallocate_list had. > In addition: > > 857 // Remove the class so unloading events aren't triggered for > 858 // this class (scratch or error class) in do_unloading(). > 859 remove_class(ik); > > Does this not remove every klass? Not just a scratch or an error klass? Only every Klass that is on the deallocate list, which are the scratch and error klass.?? The other classes aren't on this. Thanks! Coleen > Thanks > Markus > > > -----Original Message----- > From: Coleen Phillimore > Sent: den 19 december 2017 12:43 > To: hotspot-runtime-dev at openjdk.java.net runtime > Subject: RFR (S) 8193622: JFR test TestUnloadingEventClass.java times out intermittently > > Summary: Previous change was leaving scratch classes on CLD::_klasses list which are reported to tracing > > Tested with assert in tracing code and failed test, and mach4 tier1-5. > > open webrev at http://cr.openjdk.java.net/~coleenp/8193622.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8193622 > > This change is relative to jdk/hs repository but will be moved to > jdk/jdk10 once the jdk/hs snapshot is integrated. > > Thanks, > Coleen From markus.gronlund at oracle.com Tue Dec 19 16:41:19 2017 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Tue, 19 Dec 2017 08:41:19 -0800 (PST) Subject: RFR (S) 8193622: JFR test TestUnloadingEventClass.java times out intermittently In-Reply-To: <7c051dbb-e777-6082-07fa-da5bcf572046@oracle.com> References: <36065a81-b342-4cac-986b-9324c7c19ef3@default> <7c051dbb-e777-6082-07fa-da5bcf572046@oracle.com> Message-ID: Thanks Coleen, looks good. Markus -----Original Message----- From: Coleen Phillimore Sent: den 19 december 2017 17:25 To: Markus Gronlund ; hotspot-runtime-dev at openjdk.java.net runtime Subject: Re: RFR (S) 8193622: JFR test TestUnloadingEventClass.java times out intermittently On 12/19/17 10:40 AM, Markus Gronlund wrote: > Hi Coleen, > > Line 850 says: // Only constant pool entries have C heap memory to free. > > But, with the change, there is an additional else clause that seems to process klasses. > > Maybe remove the comment? Yes, I meant to remove that comment.? Thanks. > > Also: > > Is the metadata is_klass() check sufficient in allowing for a direct downcast to InstanceKlass* (not Klass*?). Maybe only InstanceKlass'es will ever be on the deallocation_list in this context? Yes, only InstanceKlass will be on the deallocate list.? I should change this and free_deallocate_list with a future RFE.? I used is_klass() because that's what free_deallocate_list had. > In addition: > > 857 // Remove the class so unloading events aren't triggered for > 858 // this class (scratch or error class) in do_unloading(). > 859 remove_class(ik); > > Does this not remove every klass? Not just a scratch or an error klass? Only every Klass that is on the deallocate list, which are the scratch and error klass.?? The other classes aren't on this. Thanks! Coleen > Thanks > Markus > > > -----Original Message----- > From: Coleen Phillimore > Sent: den 19 december 2017 12:43 > To: hotspot-runtime-dev at openjdk.java.net runtime > > Subject: RFR (S) 8193622: JFR test TestUnloadingEventClass.java times > out intermittently > > Summary: Previous change was leaving scratch classes on CLD::_klasses > list which are reported to tracing > > Tested with assert in tracing code and failed test, and mach4 tier1-5. > > open webrev at http://cr.openjdk.java.net/~coleenp/8193622.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8193622 > > This change is relative to jdk/hs repository but will be moved to > jdk/jdk10 once the jdk/hs snapshot is integrated. > > Thanks, > Coleen From coleen.phillimore at oracle.com Tue Dec 19 16:41:33 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 19 Dec 2017 11:41:33 -0500 Subject: RFR (S) 8193622: JFR test TestUnloadingEventClass.java times out intermittently In-Reply-To: <20478947-8478-9386-c946-9f8e528e505d@oracle.com> References: <20478947-8478-9386-c946-9f8e528e505d@oracle.com> Message-ID: <2400f236-b718-5ef8-80e7-06109334d454@oracle.com> Thanks Dan! Coleen On 12/19/17 10:39 AM, Daniel D. Daugherty wrote: > On 12/19/17 6:42 AM, coleen.phillimore at oracle.com wrote: >> Summary: Previous change was leaving scratch classes on CLD::_klasses >> list which are reported to tracing >> >> Tested with assert in tracing code and failed test, and mach4 tier1-5. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8193622.01/webrev > > src/hotspot/share/classfile/classLoaderData.cpp > ??? No comments. > > Thumbs up! > > Dan > > > >> bug link https://bugs.openjdk.java.net/browse/JDK-8193622 >> >> This change is relative to jdk/hs repository but will be moved to >> jdk/jdk10 once the jdk/hs snapshot is integrated. >> >> Thanks, >> Coleen > From vladimir.kozlov at oracle.com Tue Dec 19 17:56:08 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 19 Dec 2017 09:56:08 -0800 Subject: [10] RFR (S): 8188145: MethodHandle resolution should follow JVMS sequence of lookup by name & type before type descriptor resolution In-Reply-To: References: Message-ID: <0923c6a0-de71-fd92-a8d8-6bebeb2e0b7c@oracle.com> Seems fine. Thanks, Vladimir On 12/19/17 7:37 AM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8188145/webrev.00 > https://bugs.openjdk.java.net/browse/JDK-8188145 > > When resolving MethodHandle constants JVM eagerly resolves type > descriptor before doing upcall into JDK which performs method/field > resolution later (using MethodHandleNatives.resolve on symbolic > MemberName). > > The problem is that according to JVMS, member resolution (and all > exceptions it throws) should precede type descriptor resolution. > > Proposed fix does member & type descriptor resolution from JVM first and > then passes symbolic info into JDK (MHN.linkMethodHandleConstant). > > The fix is conservative, since JDK repeats method/field resolution on a > freshly created MemberName from symbolic info. But considering there are > additional security-sensitive checks on JDK side, I decided to leave all > optimizations for future enhancements. > > Testing: hs-precheckin-comp, hs-tier1, hs-tier2 > > Best regards, > Vladimir Ivanov From paul.sandoz at oracle.com Tue Dec 19 18:11:24 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 19 Dec 2017 10:11:24 -0800 Subject: [10] RFR (S): 8188145: MethodHandle resolution should follow JVMS sequence of lookup by name & type before type descriptor resolution In-Reply-To: References: Message-ID: The logic looks good to me: resolving the member name, before resolving it?s type. Paul. > On 19 Dec 2017, at 07:37, Vladimir Ivanov wrote: > > http://cr.openjdk.java.net/~vlivanov/8188145/webrev.00 > https://bugs.openjdk.java.net/browse/JDK-8188145 > > When resolving MethodHandle constants JVM eagerly resolves type descriptor before doing upcall into JDK which performs method/field resolution later (using MethodHandleNatives.resolve on symbolic MemberName). > > The problem is that according to JVMS, member resolution (and all exceptions it throws) should precede type descriptor resolution. > > Proposed fix does member & type descriptor resolution from JVM first and then passes symbolic info into JDK (MHN.linkMethodHandleConstant). > > The fix is conservative, since JDK repeats method/field resolution on a freshly created MemberName from symbolic info. But considering there are additional security-sensitive checks on JDK side, I decided to leave all optimizations for future enhancements. > > Testing: hs-precheckin-comp, hs-tier1, hs-tier2 > > Best regards, > Vladimir Ivanov From vladimir.x.ivanov at oracle.com Tue Dec 19 18:39:41 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 19 Dec 2017 21:39:41 +0300 Subject: [10] RFR (S): 8188145: MethodHandle resolution should follow JVMS sequence of lookup by name & type before type descriptor resolution In-Reply-To: References: Message-ID: Thanks, Paul & Vladimir! > The logic looks good to me: resolving the member name, before resolving it?s type. Want to elaborate here a bit. Symbolic info from CP entry is placed into a freshly created MemberName instance. It is done that way to piggyback on logic in MethodHandles::resolve_MemberName() to do proper member resolution. An alternative would be to factor out relevant logic from resolve_MemberName() and pass symbolic info directly, but I tried that and wasn't satisfied with the results. After resolution succeeds, type descriptor from member name is resolved. And that's the *only* piece which is used from resolved member name. Resolved member name is thrown away and JDK will repeat member resolution from the very beginning. Type descriptor resolution is performed on the member name to simplify dispatching logic on descriptor format (method vs field). Obvious performance improvement would be to reuse resolved member name and pass it into JDK to construct the method handle right out of it, but I decided to play it safe and keep the fix simple by preserving all the existing checks during MH constant construction. Best regards, Vladimir Ivanov PS: another direction I explored was to pass *symbolic* type descriptor (as a String and not MethodType/Class) into JDK and delay its resolution till member resolution is over in MethodHandles::resolve_MemberName(). But it turned out to be very fragile because any call of MemberName::getType() in between triggers type resolution (and it happens in surprising places, like checking member name equality). >> On 19 Dec 2017, at 07:37, Vladimir Ivanov wrote: >> >> http://cr.openjdk.java.net/~vlivanov/8188145/webrev.00 >> https://bugs.openjdk.java.net/browse/JDK-8188145 >> >> When resolving MethodHandle constants JVM eagerly resolves type descriptor before doing upcall into JDK which performs method/field resolution later (using MethodHandleNatives.resolve on symbolic MemberName). >> >> The problem is that according to JVMS, member resolution (and all exceptions it throws) should precede type descriptor resolution. >> >> Proposed fix does member & type descriptor resolution from JVM first and then passes symbolic info into JDK (MHN.linkMethodHandleConstant). >> >> The fix is conservative, since JDK repeats method/field resolution on a freshly created MemberName from symbolic info. But considering there are additional security-sensitive checks on JDK side, I decided to leave all optimizations for future enhancements. >> >> Testing: hs-precheckin-comp, hs-tier1, hs-tier2 >> >> Best regards, >> Vladimir Ivanov > From coleen.phillimore at oracle.com Tue Dec 19 20:12:30 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 19 Dec 2017 15:12:30 -0500 Subject: RFR (XS) 8152957: Improve specificity of safepoint logging to print safepoint typ Message-ID: Summary: upgrade safepoint begin logs to Info logging, which has the reason. See bug for sample. Tested with existing jtreg tests to make sure new logging line doesn't break anything. open webrev at http://cr.openjdk.java.net/~coleenp/8152957.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8152957 Thanks, Coleen From david.holmes at oracle.com Tue Dec 19 22:05:23 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Dec 2017 08:05:23 +1000 Subject: RFR (XS) 8152957: Improve specificity of safepoint logging to print safepoint typ In-Reply-To: References: Message-ID: <24ec66a8-397c-2601-f24a-30f636fbc168@oracle.com> Hi Coleen, On 20/12/2017 6:12 AM, coleen.phillimore at oracle.com wrote: > Summary: upgrade safepoint begin logs to Info logging, which has the > reason. 410 log_info(safepoint)("Entering safepoint region: %s", VMThread::vm_safepoint_description()); 497/504 log_debug(safepoint)("Leaving safepoint region"); You need to change the "leaving" part to info as well. Though I'm not clear how this simple change relates to the bug synopsis and the request to "print safepoint type" ?? Thanks, David > See bug for sample. > > Tested with existing jtreg tests to make sure new logging line doesn't > break anything. > > open webrev at http://cr.openjdk.java.net/~coleenp/8152957.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8152957 > > Thanks, > Coleen From coleen.phillimore at oracle.com Tue Dec 19 22:07:09 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 19 Dec 2017 17:07:09 -0500 Subject: RFR (XS) 8152957: Improve specificity of safepoint logging to print safepoint typ In-Reply-To: <24ec66a8-397c-2601-f24a-30f636fbc168@oracle.com> References: <24ec66a8-397c-2601-f24a-30f636fbc168@oracle.com> Message-ID: <76064970-8943-bb13-c881-6d9307d1e2ed@oracle.com> On 12/19/17 5:05 PM, David Holmes wrote: > Hi Coleen, > > On 20/12/2017 6:12 AM, coleen.phillimore at oracle.com wrote: >> Summary: upgrade safepoint begin logs to Info logging, which has the >> reason. > > 410?? log_info(safepoint)("Entering safepoint region: %s", > VMThread::vm_safepoint_description()); > 497/504?????? log_debug(safepoint)("Leaving safepoint region"); > > You need to change the "leaving" part to info as well. I had that but it seems like extra not interestesting info.? The safepoint stopped time is more useful and that's when we've left the safepoint region. > > Though I'm not clear how this simple change relates to the bug > synopsis and the request to "print safepoint type" ?? The VMThread::vm_safepoint_description() says why we safepoint. Which is RevokeBias most of the time. thanks Coleen > > Thanks, > David > >> See bug for sample. >> >> Tested with existing jtreg tests to make sure new logging line >> doesn't break anything. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/8152957.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8152957 >> >> Thanks, >> Coleen From david.holmes at oracle.com Tue Dec 19 22:14:11 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Dec 2017 08:14:11 +1000 Subject: RFR (XS) 8152957: Improve specificity of safepoint logging to print safepoint typ In-Reply-To: <76064970-8943-bb13-c881-6d9307d1e2ed@oracle.com> References: <24ec66a8-397c-2601-f24a-30f636fbc168@oracle.com> <76064970-8943-bb13-c881-6d9307d1e2ed@oracle.com> Message-ID: <047b4b84-94f0-1dc0-3636-ab8d69dcfc6c@oracle.com> On 20/12/2017 8:07 AM, coleen.phillimore at oracle.com wrote: > On 12/19/17 5:05 PM, David Holmes wrote: >> Hi Coleen, >> >> On 20/12/2017 6:12 AM, coleen.phillimore at oracle.com wrote: >>> Summary: upgrade safepoint begin logs to Info logging, which has the >>> reason. >> >> 410?? log_info(safepoint)("Entering safepoint region: %s", >> VMThread::vm_safepoint_description()); >> 497/504?????? log_debug(safepoint)("Leaving safepoint region"); >> >> You need to change the "leaving" part to info as well. > > I had that but it seems like extra not interestesting info.? The > safepoint stopped time is more useful and that's when we've left the > safepoint region. Seems unbalanced to me. And it's not clear from where the "safepoint stopped time" actually gets printed. >> >> Though I'm not clear how this simple change relates to the bug >> synopsis and the request to "print safepoint type" ?? > > The VMThread::vm_safepoint_description() says why we safepoint. Which is > RevokeBias most of the time. Ah! Right. Thanks, David > thanks > Coleen >> >> Thanks, >> David >> >>> See bug for sample. >>> >>> Tested with existing jtreg tests to make sure new logging line >>> doesn't break anything. >>> >>> open webrev at http://cr.openjdk.java.net/~coleenp/8152957.01/webrev >>> bug link https://bugs.openjdk.java.net/browse/JDK-8152957 >>> >>> Thanks, >>> Coleen > From coleen.phillimore at oracle.com Tue Dec 19 22:18:37 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 19 Dec 2017 17:18:37 -0500 Subject: RFR (XS) 8152957: Improve specificity of safepoint logging to print safepoint typ In-Reply-To: <047b4b84-94f0-1dc0-3636-ab8d69dcfc6c@oracle.com> References: <24ec66a8-397c-2601-f24a-30f636fbc168@oracle.com> <76064970-8943-bb13-c881-6d9307d1e2ed@oracle.com> <047b4b84-94f0-1dc0-3636-ab8d69dcfc6c@oracle.com> Message-ID: On 12/19/17 5:14 PM, David Holmes wrote: > On 20/12/2017 8:07 AM, coleen.phillimore at oracle.com wrote: >> On 12/19/17 5:05 PM, David Holmes wrote: >>> Hi Coleen, >>> >>> On 20/12/2017 6:12 AM, coleen.phillimore at oracle.com wrote: >>>> Summary: upgrade safepoint begin logs to Info logging, which has >>>> the reason. >>> >>> 410?? log_info(safepoint)("Entering safepoint region: %s", >>> VMThread::vm_safepoint_description()); >>> 497/504?????? log_debug(safepoint)("Leaving safepoint region"); >>> >>> You need to change the "leaving" part to info as well. >> >> I had that but it seems like extra not interestesting info.? The >> safepoint stopped time is more useful and that's when we've left the >> safepoint region. > > Seems unbalanced to me. And it's not clear from where the "safepoint > stopped time" actually gets printed. If you think it's helpful then I'll add it.? It comes from this line closer to the end of the function. ????? RuntimeService::record_safepoint_end(); thanks, Coleen >>> >>> Though I'm not clear how this simple change relates to the bug >>> synopsis and the request to "print safepoint type" ?? >> >> The VMThread::vm_safepoint_description() says why we safepoint. Which >> is RevokeBias most of the time. > > Ah! Right. > > Thanks, > David > >> thanks >> Coleen >>> >>> Thanks, >>> David >>> >>>> See bug for sample. >>>> >>>> Tested with existing jtreg tests to make sure new logging line >>>> doesn't break anything. >>>> >>>> open webrev at http://cr.openjdk.java.net/~coleenp/8152957.01/webrev >>>> bug link https://bugs.openjdk.java.net/browse/JDK-8152957 >>>> >>>> Thanks, >>>> Coleen >> From david.holmes at oracle.com Tue Dec 19 22:31:27 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Dec 2017 08:31:27 +1000 Subject: RFR (XS) 8152957: Improve specificity of safepoint logging to print safepoint typ In-Reply-To: References: <24ec66a8-397c-2601-f24a-30f636fbc168@oracle.com> <76064970-8943-bb13-c881-6d9307d1e2ed@oracle.com> <047b4b84-94f0-1dc0-3636-ab8d69dcfc6c@oracle.com> Message-ID: <12b97a82-e3a8-ed09-8125-cbda766ae2ae@oracle.com> On 20/12/2017 8:18 AM, coleen.phillimore at oracle.com wrote: > On 12/19/17 5:14 PM, David Holmes wrote: >> On 20/12/2017 8:07 AM, coleen.phillimore at oracle.com wrote: >>> On 12/19/17 5:05 PM, David Holmes wrote: >>>> Hi Coleen, >>>> >>>> On 20/12/2017 6:12 AM, coleen.phillimore at oracle.com wrote: >>>>> Summary: upgrade safepoint begin logs to Info logging, which has >>>>> the reason. >>>> >>>> 410?? log_info(safepoint)("Entering safepoint region: %s", >>>> VMThread::vm_safepoint_description()); >>>> 497/504?????? log_debug(safepoint)("Leaving safepoint region"); >>>> >>>> You need to change the "leaving" part to info as well. >>> >>> I had that but it seems like extra not interestesting info.? The >>> safepoint stopped time is more useful and that's when we've left the >>> safepoint region. >> >> Seems unbalanced to me. And it's not clear from where the "safepoint >> stopped time" actually gets printed. > > If you think it's helpful then I'll add it.? It comes from this line > closer to the end of the function. > > ????? RuntimeService::record_safepoint_end(); I'd prefer it. Thanks, David > thanks, > Coleen > >>>> >>>> Though I'm not clear how this simple change relates to the bug >>>> synopsis and the request to "print safepoint type" ?? >>> >>> The VMThread::vm_safepoint_description() says why we safepoint. Which >>> is RevokeBias most of the time. >> >> Ah! Right. >> >> Thanks, >> David >> >>> thanks >>> Coleen >>>> >>>> Thanks, >>>> David >>>> >>>>> See bug for sample. >>>>> >>>>> Tested with existing jtreg tests to make sure new logging line >>>>> doesn't break anything. >>>>> >>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8152957.01/webrev >>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8152957 >>>>> >>>>> Thanks, >>>>> Coleen >>> > From coleen.phillimore at oracle.com Tue Dec 19 22:32:13 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 19 Dec 2017 17:32:13 -0500 Subject: RFR (XS) 8152957: Improve specificity of safepoint logging to print safepoint typ In-Reply-To: <12b97a82-e3a8-ed09-8125-cbda766ae2ae@oracle.com> References: <24ec66a8-397c-2601-f24a-30f636fbc168@oracle.com> <76064970-8943-bb13-c881-6d9307d1e2ed@oracle.com> <047b4b84-94f0-1dc0-3636-ab8d69dcfc6c@oracle.com> <12b97a82-e3a8-ed09-8125-cbda766ae2ae@oracle.com> Message-ID: <53e336dc-a2c1-6309-2475-72f896bf9442@oracle.com> On 12/19/17 5:31 PM, David Holmes wrote: > On 20/12/2017 8:18 AM, coleen.phillimore at oracle.com wrote: >> On 12/19/17 5:14 PM, David Holmes wrote: >>> On 20/12/2017 8:07 AM, coleen.phillimore at oracle.com wrote: >>>> On 12/19/17 5:05 PM, David Holmes wrote: >>>>> Hi Coleen, >>>>> >>>>> On 20/12/2017 6:12 AM, coleen.phillimore at oracle.com wrote: >>>>>> Summary: upgrade safepoint begin logs to Info logging, which has >>>>>> the reason. >>>>> >>>>> 410?? log_info(safepoint)("Entering safepoint region: %s", >>>>> VMThread::vm_safepoint_description()); >>>>> 497/504?????? log_debug(safepoint)("Leaving safepoint region"); >>>>> >>>>> You need to change the "leaving" part to info as well. >>>> >>>> I had that but it seems like extra not interestesting info. The >>>> safepoint stopped time is more useful and that's when we've left >>>> the safepoint region. >>> >>> Seems unbalanced to me. And it's not clear from where the "safepoint >>> stopped time" actually gets printed. >> >> If you think it's helpful then I'll add it.? It comes from this line >> closer to the end of the function. >> >> ?????? RuntimeService::record_safepoint_end(); > > I'd prefer it. You got it. Thanks, Coleen > > Thanks, > David > >> thanks, >> Coleen >> >>>>> >>>>> Though I'm not clear how this simple change relates to the bug >>>>> synopsis and the request to "print safepoint type" ?? >>>> >>>> The VMThread::vm_safepoint_description() says why we safepoint. >>>> Which is RevokeBias most of the time. >>> >>> Ah! Right. >>> >>> Thanks, >>> David >>> >>>> thanks >>>> Coleen >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> See bug for sample. >>>>>> >>>>>> Tested with existing jtreg tests to make sure new logging line >>>>>> doesn't break anything. >>>>>> >>>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8152957.01/webrev >>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8152957 >>>>>> >>>>>> Thanks, >>>>>> Coleen >>>> >> From calvin.cheung at oracle.com Wed Dec 20 01:01:31 2017 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Tue, 19 Dec 2017 17:01:31 -0800 Subject: RFR(S): 8192927: os::dir_is_empty is incorrect on Windows Message-ID: <5A39B66B.6010204@oracle.com> bug: https://bugs.openjdk.java.net/browse/JDK-8192927 This change is targeted for JDK 11. Please refer to the comment in the bug for a description of the change. It also handles path longer than MAX_PATH. webrev: http://cr.openjdk.java.net/~ccheung/8192927/webrev.00/ Testing: hs-tier1, hs-tier2 on linux-x64, windows-x64, macosx appcds tests on the above platforms + sparcv9. thanks, Calvin From coleen.phillimore at oracle.com Wed Dec 20 14:16:47 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 20 Dec 2017 09:16:47 -0500 Subject: RFR (XS) 8152957: Improve specificity of safepoint logging to print safepoint typ In-Reply-To: <53e336dc-a2c1-6309-2475-72f896bf9442@oracle.com> References: <24ec66a8-397c-2601-f24a-30f636fbc168@oracle.com> <76064970-8943-bb13-c881-6d9307d1e2ed@oracle.com> <047b4b84-94f0-1dc0-3636-ab8d69dcfc6c@oracle.com> <12b97a82-e3a8-ed09-8125-cbda766ae2ae@oracle.com> <53e336dc-a2c1-6309-2475-72f896bf9442@oracle.com> Message-ID: <7e3f32e4-5e31-4f39-dcdd-c249baf07dac@oracle.com> In case s/debug/info/ needs to be seen.? Yes, there are two places but I'd rather leave them like they are unless there's more information supporting moving to one place. http://cr.openjdk.java.net/~coleenp/8152957.02/webrev Thanks, Coleen On 12/19/17 5:32 PM, coleen.phillimore at oracle.com wrote: > > > On 12/19/17 5:31 PM, David Holmes wrote: >> On 20/12/2017 8:18 AM, coleen.phillimore at oracle.com wrote: >>> On 12/19/17 5:14 PM, David Holmes wrote: >>>> On 20/12/2017 8:07 AM, coleen.phillimore at oracle.com wrote: >>>>> On 12/19/17 5:05 PM, David Holmes wrote: >>>>>> Hi Coleen, >>>>>> >>>>>> On 20/12/2017 6:12 AM, coleen.phillimore at oracle.com wrote: >>>>>>> Summary: upgrade safepoint begin logs to Info logging, which has >>>>>>> the reason. >>>>>> >>>>>> 410?? log_info(safepoint)("Entering safepoint region: %s", >>>>>> VMThread::vm_safepoint_description()); >>>>>> 497/504?????? log_debug(safepoint)("Leaving safepoint region"); >>>>>> >>>>>> You need to change the "leaving" part to info as well. >>>>> >>>>> I had that but it seems like extra not interestesting info. The >>>>> safepoint stopped time is more useful and that's when we've left >>>>> the safepoint region. >>>> >>>> Seems unbalanced to me. And it's not clear from where the >>>> "safepoint stopped time" actually gets printed. >>> >>> If you think it's helpful then I'll add it.? It comes from this line >>> closer to the end of the function. >>> >>> ?????? RuntimeService::record_safepoint_end(); >> >> I'd prefer it. > > You got it. > Thanks, > Coleen >> >> Thanks, >> David >> >>> thanks, >>> Coleen >>> >>>>>> >>>>>> Though I'm not clear how this simple change relates to the bug >>>>>> synopsis and the request to "print safepoint type" ?? >>>>> >>>>> The VMThread::vm_safepoint_description() says why we safepoint. >>>>> Which is RevokeBias most of the time. >>>> >>>> Ah! Right. >>>> >>>> Thanks, >>>> David >>>> >>>>> thanks >>>>> Coleen >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> See bug for sample. >>>>>>> >>>>>>> Tested with existing jtreg tests to make sure new logging line >>>>>>> doesn't break anything. >>>>>>> >>>>>>> open webrev at >>>>>>> http://cr.openjdk.java.net/~coleenp/8152957.01/webrev >>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8152957 >>>>>>> >>>>>>> Thanks, >>>>>>> Coleen >>>>> >>> > From harold.seigel at oracle.com Wed Dec 20 14:21:50 2017 From: harold.seigel at oracle.com (harold seigel) Date: Wed, 20 Dec 2017 09:21:50 -0500 Subject: RFR (XS) 8152957: Improve specificity of safepoint logging to print safepoint typ In-Reply-To: <7e3f32e4-5e31-4f39-dcdd-c249baf07dac@oracle.com> References: <24ec66a8-397c-2601-f24a-30f636fbc168@oracle.com> <76064970-8943-bb13-c881-6d9307d1e2ed@oracle.com> <047b4b84-94f0-1dc0-3636-ab8d69dcfc6c@oracle.com> <12b97a82-e3a8-ed09-8125-cbda766ae2ae@oracle.com> <53e336dc-a2c1-6309-2475-72f896bf9442@oracle.com> <7e3f32e4-5e31-4f39-dcdd-c249baf07dac@oracle.com> Message-ID: <02afb7f0-9724-34d6-b4a1-246e9937b509@oracle.com> Hi Coleen, These changes look good! Thanks, Harold On 12/20/2017 9:16 AM, coleen.phillimore at oracle.com wrote: > > In case s/debug/info/ needs to be seen.? Yes, there are two places but > I'd rather leave them like they are unless there's more information > supporting moving to one place. > > http://cr.openjdk.java.net/~coleenp/8152957.02/webrev > > Thanks, > Coleen > > > On 12/19/17 5:32 PM, coleen.phillimore at oracle.com wrote: >> >> >> On 12/19/17 5:31 PM, David Holmes wrote: >>> On 20/12/2017 8:18 AM, coleen.phillimore at oracle.com wrote: >>>> On 12/19/17 5:14 PM, David Holmes wrote: >>>>> On 20/12/2017 8:07 AM, coleen.phillimore at oracle.com wrote: >>>>>> On 12/19/17 5:05 PM, David Holmes wrote: >>>>>>> Hi Coleen, >>>>>>> >>>>>>> On 20/12/2017 6:12 AM, coleen.phillimore at oracle.com wrote: >>>>>>>> Summary: upgrade safepoint begin logs to Info logging, which >>>>>>>> has the reason. >>>>>>> >>>>>>> 410?? log_info(safepoint)("Entering safepoint region: %s", >>>>>>> VMThread::vm_safepoint_description()); >>>>>>> 497/504?????? log_debug(safepoint)("Leaving safepoint region"); >>>>>>> >>>>>>> You need to change the "leaving" part to info as well. >>>>>> >>>>>> I had that but it seems like extra not interestesting info. The >>>>>> safepoint stopped time is more useful and that's when we've left >>>>>> the safepoint region. >>>>> >>>>> Seems unbalanced to me. And it's not clear from where the >>>>> "safepoint stopped time" actually gets printed. >>>> >>>> If you think it's helpful then I'll add it.? It comes from this >>>> line closer to the end of the function. >>>> >>>> ?????? RuntimeService::record_safepoint_end(); >>> >>> I'd prefer it. >> >> You got it. >> Thanks, >> Coleen >>> >>> Thanks, >>> David >>> >>>> thanks, >>>> Coleen >>>> >>>>>>> >>>>>>> Though I'm not clear how this simple change relates to the bug >>>>>>> synopsis and the request to "print safepoint type" ?? >>>>>> >>>>>> The VMThread::vm_safepoint_description() says why we safepoint. >>>>>> Which is RevokeBias most of the time. >>>>> >>>>> Ah! Right. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> thanks >>>>>> Coleen >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> See bug for sample. >>>>>>>> >>>>>>>> Tested with existing jtreg tests to make sure new logging line >>>>>>>> doesn't break anything. >>>>>>>> >>>>>>>> open webrev at >>>>>>>> http://cr.openjdk.java.net/~coleenp/8152957.01/webrev >>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8152957 >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Coleen >>>>>> >>>> >> > From frederic.parain at oracle.com Wed Dec 20 14:29:08 2017 From: frederic.parain at oracle.com (Frederic Parain) Date: Wed, 20 Dec 2017 09:29:08 -0500 Subject: [8u] RFR(S) 8031304 : Add dcmd to print all loaded dynamic libraries In-Reply-To: References: Message-ID: Looks good to me. Fred > On Dec 19, 2017, at 03:16, David Buck wrote: > > Hi! > > Please review this straightforward serviceability backport to JDK 8. > > No real changes to product code. I just moved the import statements in the DynLibDcmdTest.java test case to below the copyright header. > > bug report: > https://bugs.openjdk.java.net/browse/JDK-8031304 > > JDK 9 review thread: > http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-January/013778.html > > JDK 9 changeset: > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/afa21611f918 > > JDK 8 webrev for review: > http://cr.openjdk.java.net/~dbuck/8031304_jdk8_ver00/ > > Cheers, > -Buck From zgu at redhat.com Wed Dec 20 14:35:17 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 20 Dec 2017 09:35:17 -0500 Subject: RFR (XS) 8152957: Improve specificity of safepoint logging to print safepoint typ In-Reply-To: <02afb7f0-9724-34d6-b4a1-246e9937b509@oracle.com> References: <24ec66a8-397c-2601-f24a-30f636fbc168@oracle.com> <76064970-8943-bb13-c881-6d9307d1e2ed@oracle.com> <047b4b84-94f0-1dc0-3636-ab8d69dcfc6c@oracle.com> <12b97a82-e3a8-ed09-8125-cbda766ae2ae@oracle.com> <53e336dc-a2c1-6309-2475-72f896bf9442@oracle.com> <7e3f32e4-5e31-4f39-dcdd-c249baf07dac@oracle.com> <02afb7f0-9724-34d6-b4a1-246e9937b509@oracle.com> Message-ID: Looks good to me too. -Zhengyu On 12/20/2017 09:21 AM, harold seigel wrote: > Hi Coleen, > > These changes look good! > > Thanks, Harold > > > On 12/20/2017 9:16 AM, coleen.phillimore at oracle.com wrote: >> >> In case s/debug/info/ needs to be seen. Yes, there are two places but >> I'd rather leave them like they are unless there's more information >> supporting moving to one place. >> >> http://cr.openjdk.java.net/~coleenp/8152957.02/webrev >> >> Thanks, >> Coleen >> >> >> On 12/19/17 5:32 PM, coleen.phillimore at oracle.com wrote: >>> >>> >>> On 12/19/17 5:31 PM, David Holmes wrote: >>>> On 20/12/2017 8:18 AM, coleen.phillimore at oracle.com wrote: >>>>> On 12/19/17 5:14 PM, David Holmes wrote: >>>>>> On 20/12/2017 8:07 AM, coleen.phillimore at oracle.com wrote: >>>>>>> On 12/19/17 5:05 PM, David Holmes wrote: >>>>>>>> Hi Coleen, >>>>>>>> >>>>>>>> On 20/12/2017 6:12 AM, coleen.phillimore at oracle.com wrote: >>>>>>>>> Summary: upgrade safepoint begin logs to Info logging, which >>>>>>>>> has the reason. >>>>>>>> >>>>>>>> 410 log_info(safepoint)("Entering safepoint region: %s", >>>>>>>> VMThread::vm_safepoint_description()); >>>>>>>> 497/504 log_debug(safepoint)("Leaving safepoint region"); >>>>>>>> >>>>>>>> You need to change the "leaving" part to info as well. >>>>>>> >>>>>>> I had that but it seems like extra not interestesting info. The >>>>>>> safepoint stopped time is more useful and that's when we've left >>>>>>> the safepoint region. >>>>>> >>>>>> Seems unbalanced to me. And it's not clear from where the >>>>>> "safepoint stopped time" actually gets printed. >>>>> >>>>> If you think it's helpful then I'll add it. It comes from this >>>>> line closer to the end of the function. >>>>> >>>>> RuntimeService::record_safepoint_end(); >>>> >>>> I'd prefer it. >>> >>> You got it. >>> Thanks, >>> Coleen >>>> >>>> Thanks, >>>> David >>>> >>>>> thanks, >>>>> Coleen >>>>> >>>>>>>> >>>>>>>> Though I'm not clear how this simple change relates to the bug >>>>>>>> synopsis and the request to "print safepoint type" ?? >>>>>>> >>>>>>> The VMThread::vm_safepoint_description() says why we safepoint. >>>>>>> Which is RevokeBias most of the time. >>>>>> >>>>>> Ah! Right. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> thanks >>>>>>> Coleen >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> See bug for sample. >>>>>>>>> >>>>>>>>> Tested with existing jtreg tests to make sure new logging line >>>>>>>>> doesn't break anything. >>>>>>>>> >>>>>>>>> open webrev at >>>>>>>>> http://cr.openjdk.java.net/~coleenp/8152957.01/webrev >>>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8152957 >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Coleen >>>>>>> >>>>> >>> >> > From coleen.phillimore at oracle.com Wed Dec 20 14:47:29 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 20 Dec 2017 09:47:29 -0500 Subject: RFR (XS) 8152957: Improve specificity of safepoint logging to print safepoint typ In-Reply-To: <02afb7f0-9724-34d6-b4a1-246e9937b509@oracle.com> References: <24ec66a8-397c-2601-f24a-30f636fbc168@oracle.com> <76064970-8943-bb13-c881-6d9307d1e2ed@oracle.com> <047b4b84-94f0-1dc0-3636-ab8d69dcfc6c@oracle.com> <12b97a82-e3a8-ed09-8125-cbda766ae2ae@oracle.com> <53e336dc-a2c1-6309-2475-72f896bf9442@oracle.com> <7e3f32e4-5e31-4f39-dcdd-c249baf07dac@oracle.com> <02afb7f0-9724-34d6-b4a1-246e9937b509@oracle.com> Message-ID: Thanks Harold! Coleen On 12/20/17 9:21 AM, harold seigel wrote: > Hi Coleen, > > These changes look good! > > Thanks, Harold > > > On 12/20/2017 9:16 AM, coleen.phillimore at oracle.com wrote: >> >> In case s/debug/info/ needs to be seen.? Yes, there are two places >> but I'd rather leave them like they are unless there's more >> information supporting moving to one place. >> >> http://cr.openjdk.java.net/~coleenp/8152957.02/webrev >> >> Thanks, >> Coleen >> >> >> On 12/19/17 5:32 PM, coleen.phillimore at oracle.com wrote: >>> >>> >>> On 12/19/17 5:31 PM, David Holmes wrote: >>>> On 20/12/2017 8:18 AM, coleen.phillimore at oracle.com wrote: >>>>> On 12/19/17 5:14 PM, David Holmes wrote: >>>>>> On 20/12/2017 8:07 AM, coleen.phillimore at oracle.com wrote: >>>>>>> On 12/19/17 5:05 PM, David Holmes wrote: >>>>>>>> Hi Coleen, >>>>>>>> >>>>>>>> On 20/12/2017 6:12 AM, coleen.phillimore at oracle.com wrote: >>>>>>>>> Summary: upgrade safepoint begin logs to Info logging, which >>>>>>>>> has the reason. >>>>>>>> >>>>>>>> 410?? log_info(safepoint)("Entering safepoint region: %s", >>>>>>>> VMThread::vm_safepoint_description()); >>>>>>>> 497/504?????? log_debug(safepoint)("Leaving safepoint region"); >>>>>>>> >>>>>>>> You need to change the "leaving" part to info as well. >>>>>>> >>>>>>> I had that but it seems like extra not interestesting info. The >>>>>>> safepoint stopped time is more useful and that's when we've left >>>>>>> the safepoint region. >>>>>> >>>>>> Seems unbalanced to me. And it's not clear from where the >>>>>> "safepoint stopped time" actually gets printed. >>>>> >>>>> If you think it's helpful then I'll add it.? It comes from this >>>>> line closer to the end of the function. >>>>> >>>>> ?????? RuntimeService::record_safepoint_end(); >>>> >>>> I'd prefer it. >>> >>> You got it. >>> Thanks, >>> Coleen >>>> >>>> Thanks, >>>> David >>>> >>>>> thanks, >>>>> Coleen >>>>> >>>>>>>> >>>>>>>> Though I'm not clear how this simple change relates to the bug >>>>>>>> synopsis and the request to "print safepoint type" ?? >>>>>>> >>>>>>> The VMThread::vm_safepoint_description() says why we safepoint. >>>>>>> Which is RevokeBias most of the time. >>>>>> >>>>>> Ah! Right. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> thanks >>>>>>> Coleen >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> See bug for sample. >>>>>>>>> >>>>>>>>> Tested with existing jtreg tests to make sure new logging line >>>>>>>>> doesn't break anything. >>>>>>>>> >>>>>>>>> open webrev at >>>>>>>>> http://cr.openjdk.java.net/~coleenp/8152957.01/webrev >>>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8152957 >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Coleen >>>>>>> >>>>> >>> >> > From coleen.phillimore at oracle.com Wed Dec 20 14:47:47 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 20 Dec 2017 09:47:47 -0500 Subject: RFR (XS) 8152957: Improve specificity of safepoint logging to print safepoint typ In-Reply-To: References: <24ec66a8-397c-2601-f24a-30f636fbc168@oracle.com> <76064970-8943-bb13-c881-6d9307d1e2ed@oracle.com> <047b4b84-94f0-1dc0-3636-ab8d69dcfc6c@oracle.com> <12b97a82-e3a8-ed09-8125-cbda766ae2ae@oracle.com> <53e336dc-a2c1-6309-2475-72f896bf9442@oracle.com> <7e3f32e4-5e31-4f39-dcdd-c249baf07dac@oracle.com> <02afb7f0-9724-34d6-b4a1-246e9937b509@oracle.com> Message-ID: <0098c19c-c9b0-be8d-bba8-1e0b649d2cb7@oracle.com> Thanks Zhengyu! Coleen On 12/20/17 9:35 AM, Zhengyu Gu wrote: > Looks good to me too. > > -Zhengyu > > On 12/20/2017 09:21 AM, harold seigel wrote: >> Hi Coleen, >> >> These changes look good! >> >> Thanks, Harold >> >> >> On 12/20/2017 9:16 AM, coleen.phillimore at oracle.com wrote: >>> >>> In case s/debug/info/ needs to be seen.? Yes, there are two places >>> but I'd rather leave them like they are unless there's more >>> information supporting moving to one place. >>> >>> http://cr.openjdk.java.net/~coleenp/8152957.02/webrev >>> >>> Thanks, >>> Coleen >>> >>> >>> On 12/19/17 5:32 PM, coleen.phillimore at oracle.com wrote: >>>> >>>> >>>> On 12/19/17 5:31 PM, David Holmes wrote: >>>>> On 20/12/2017 8:18 AM, coleen.phillimore at oracle.com wrote: >>>>>> On 12/19/17 5:14 PM, David Holmes wrote: >>>>>>> On 20/12/2017 8:07 AM, coleen.phillimore at oracle.com wrote: >>>>>>>> On 12/19/17 5:05 PM, David Holmes wrote: >>>>>>>>> Hi Coleen, >>>>>>>>> >>>>>>>>> On 20/12/2017 6:12 AM, coleen.phillimore at oracle.com wrote: >>>>>>>>>> Summary: upgrade safepoint begin logs to Info logging, which >>>>>>>>>> has the reason. >>>>>>>>> >>>>>>>>> 410?? log_info(safepoint)("Entering safepoint region: %s", >>>>>>>>> VMThread::vm_safepoint_description()); >>>>>>>>> 497/504?????? log_debug(safepoint)("Leaving safepoint region"); >>>>>>>>> >>>>>>>>> You need to change the "leaving" part to info as well. >>>>>>>> >>>>>>>> I had that but it seems like extra not interestesting info. The >>>>>>>> safepoint stopped time is more useful and that's when we've >>>>>>>> left the safepoint region. >>>>>>> >>>>>>> Seems unbalanced to me. And it's not clear from where the >>>>>>> "safepoint stopped time" actually gets printed. >>>>>> >>>>>> If you think it's helpful then I'll add it.? It comes from this >>>>>> line closer to the end of the function. >>>>>> >>>>>> ?????? RuntimeService::record_safepoint_end(); >>>>> >>>>> I'd prefer it. >>>> >>>> You got it. >>>> Thanks, >>>> Coleen >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> thanks, >>>>>> Coleen >>>>>> >>>>>>>>> >>>>>>>>> Though I'm not clear how this simple change relates to the bug >>>>>>>>> synopsis and the request to "print safepoint type" ?? >>>>>>>> >>>>>>>> The VMThread::vm_safepoint_description() says why we safepoint. >>>>>>>> Which is RevokeBias most of the time. >>>>>>> >>>>>>> Ah! Right. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> thanks >>>>>>>> Coleen >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> See bug for sample. >>>>>>>>>> >>>>>>>>>> Tested with existing jtreg tests to make sure new logging >>>>>>>>>> line doesn't break anything. >>>>>>>>>> >>>>>>>>>> open webrev at >>>>>>>>>> http://cr.openjdk.java.net/~coleenp/8152957.01/webrev >>>>>>>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8152957 >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Coleen >>>>>>>> >>>>>> >>>> >>> >> From markus.gronlund at oracle.com Wed Dec 20 16:41:21 2017 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Wed, 20 Dec 2017 08:41:21 -0800 (PST) Subject: [8u] RFR(S) 8031304 : Add dcmd to print all loaded dynamic libraries In-Reply-To: References: Message-ID: <279b7211-9492-48ea-af64-571e898289a2@default> Hi David, Looks good. Thanks Markus -----Original Message----- From: David Buck Sent: den 19 december 2017 09:17 To: serviceability-dev at openjdk.java.net; hotspot-runtime-dev at openjdk.java.net Subject: [8u] RFR(S) 8031304 : Add dcmd to print all loaded dynamic libraries Hi! Please review this straightforward serviceability backport to JDK 8. No real changes to product code. I just moved the import statements in the DynLibDcmdTest.java test case to below the copyright header. bug report: https://bugs.openjdk.java.net/browse/JDK-8031304 JDK 9 review thread: http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-January/013778.html JDK 9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/afa21611f918 JDK 8 webrev for review: http://cr.openjdk.java.net/~dbuck/8031304_jdk8_ver00/ Cheers, -Buck From ioi.lam at oracle.com Wed Dec 20 17:56:54 2017 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 20 Dec 2017 09:56:54 -0800 Subject: RFR(XS) 8193897 - JDK-8191374 caused windows_i586 build to fail Message-ID: Hi, Please review this fix for jprt breakage. I'd like to use the trivial fixrule since it affects JPRT. https://bugs.openjdk.java.net/browse/JDK-8193897 --- a/src/hotspot/share/classfile/classLoader.cpp??? Tue Dec 19 11:29:07 2017 -0800 +++ b/src/hotspot/share/classfile/classLoader.cpp??? Wed Dec 20 09:44:58 2017 -0800 @@ -803,7 +803,7 @@ ?? bool set_base_piece = true; ?#if INCLUDE_CDS -? if (DumpSharedSpaces || UseSharedSpaces) { +? if (DumpSharedSpaces) { ???? if (!Arguments::has_jimage()) { ?????? vm_exit_during_initialization("CDS is not supported in exploded JDK build", NULL); ???? } The failure happens on 32-bit platforms where UseSharedSpaces is true by default. We actually just needed to check for DumpSharedSpaces and disable archive creation for exploded builds. Without an archive, the user won't be able to run with CDS using an exploded build. (Archive loading checks for the JVM which created the archive, so the exploded build can't use an archive created by another JVM). Thanks - Ioi From harold.seigel at oracle.com Wed Dec 20 17:59:56 2017 From: harold.seigel at oracle.com (harold seigel) Date: Wed, 20 Dec 2017 12:59:56 -0500 Subject: RFR(XS) 8193897 - JDK-8191374 caused windows_i586 build to fail In-Reply-To: References: Message-ID: <4c5e0bf2-b22c-f9b8-f225-9c3cba6190f1@oracle.com> Hi Ioi, The change looks good.? Go ahead and push it. Harold On 12/20/2017 12:56 PM, Ioi Lam wrote: > Hi, > > Please review this fix for jprt breakage. > > I'd like to use the trivial fixrule since it affects JPRT. > > > https://bugs.openjdk.java.net/browse/JDK-8193897 > > > --- a/src/hotspot/share/classfile/classLoader.cpp??? Tue Dec 19 > 11:29:07 2017 -0800 > +++ b/src/hotspot/share/classfile/classLoader.cpp??? Wed Dec 20 > 09:44:58 2017 -0800 > @@ -803,7 +803,7 @@ > ?? bool set_base_piece = true; > > ?#if INCLUDE_CDS > -? if (DumpSharedSpaces || UseSharedSpaces) { > +? if (DumpSharedSpaces) { > ???? if (!Arguments::has_jimage()) { > ?????? vm_exit_during_initialization("CDS is not supported in exploded > JDK build", NULL); > ???? } > > > The failure happens on 32-bit platforms where UseSharedSpaces is true > by default. > > We actually just needed to check for DumpSharedSpaces and disable archive > creation for exploded builds. > > Without an archive, the user won't be able to run with CDS using an > exploded build. > (Archive loading checks for the JVM which created the archive, so the > exploded build > can't use an archive created by another JVM). > > Thanks > - Ioi From ioi.lam at oracle.com Wed Dec 20 19:29:09 2017 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 20 Dec 2017 11:29:09 -0800 Subject: RFR(XS) 8193897 - JDK-8191374 caused windows_i586 build to fail In-Reply-To: <4c5e0bf2-b22c-f9b8-f225-9c3cba6190f1@oracle.com> References: <4c5e0bf2-b22c-f9b8-f225-9c3cba6190f1@oracle.com> Message-ID: <8a99d7a8-dc4d-7fcf-79c4-e79a636da3b5@oracle.com> Thanks Harold. I'll push now. - Ioi On 12/20/17 9:59 AM, harold seigel wrote: > Hi Ioi, > > The change looks good.? Go ahead and push it. > > Harold > > > On 12/20/2017 12:56 PM, Ioi Lam wrote: >> Hi, >> >> Please review this fix for jprt breakage. >> >> I'd like to use the trivial fixrule since it affects JPRT. >> >> >> https://bugs.openjdk.java.net/browse/JDK-8193897 >> >> >> --- a/src/hotspot/share/classfile/classLoader.cpp??? Tue Dec 19 >> 11:29:07 2017 -0800 >> +++ b/src/hotspot/share/classfile/classLoader.cpp??? Wed Dec 20 >> 09:44:58 2017 -0800 >> @@ -803,7 +803,7 @@ >> ?? bool set_base_piece = true; >> >> ?#if INCLUDE_CDS >> -? if (DumpSharedSpaces || UseSharedSpaces) { >> +? if (DumpSharedSpaces) { >> ???? if (!Arguments::has_jimage()) { >> ?????? vm_exit_during_initialization("CDS is not supported in >> exploded JDK build", NULL); >> ???? } >> >> >> The failure happens on 32-bit platforms where UseSharedSpaces is true >> by default. >> >> We actually just needed to check for DumpSharedSpaces and disable >> archive >> creation for exploded builds. >> >> Without an archive, the user won't be able to run with CDS using an >> exploded build. >> (Archive loading checks for the JVM which created the archive, so the >> exploded build >> can't use an archive created by another JVM). >> >> Thanks >> - Ioi > From calvin.cheung at oracle.com Wed Dec 20 22:00:05 2017 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Wed, 20 Dec 2017 14:00:05 -0800 Subject: RFR(S): 8192927: os::dir_is_empty is incorrect on Windows In-Reply-To: <5A39B66B.6010204@oracle.com> References: <5A39B66B.6010204@oracle.com> Message-ID: <5A3ADD65.6080600@oracle.com> I've updated the change slightly: - replaced the do-while loop with a while loop; - free(search_path) should be os::free(search_path) updated webrev: http://cr.openjdk.java.net/~ccheung/8192927/webrev.01/ thanks, Calvin On 12/19/17, 5:01 PM, Calvin Cheung wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8192927 > > This change is targeted for JDK 11. > Please refer to the comment in the bug for a description of the > change. It also handles path longer than MAX_PATH. > > webrev: http://cr.openjdk.java.net/~ccheung/8192927/webrev.00/ > > Testing: > hs-tier1, hs-tier2 on linux-x64, windows-x64, macosx > appcds tests on the above platforms + sparcv9. > > thanks, > Calvin From david.holmes at oracle.com Thu Dec 21 00:42:29 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 21 Dec 2017 10:42:29 +1000 Subject: RFR [11] JDK-8179424: Remove terminally deprecated sun.reflect.Reflection.getCallerClass In-Reply-To: <302E7962-B372-4F1F-92ED-BFDB5CF7B290@oracle.com> References: <90fbc317-4c39-d51e-f402-3803917d065d@oracle.com> <81e288b8-3b95-4fee-3ed8-f3c8a5be9d47@oracle.com> <0719bbfb-924d-9e70-1dfb-9ec782442080@oracle.com> <302E7962-B372-4F1F-92ED-BFDB5CF7B290@oracle.com> Message-ID: <628a9c02-8031-142c-8fef-18d0f00baa67@oracle.com> Hi Chris, Adding in hotspot-runtime-dev now that you have included the VM side of the cleanup. What repo are you planning on pushing this to? On 21/12/2017 9:45 AM, Chris Hegarty wrote: > >> On 20 Dec 2017, at 19:21, mandy chung wrote: >> >> The native side and hotspot side should also be cleaned up. Thanks Mandy, I was about call that out too :) > Good call. I think the following is probably as far as we want to > go. Maybe a follow-on issue could be filed if deeper VM clean > up is needed? > > http://cr.openjdk.java.net/~chegar/8179424/webrev.01/ src/hotspot/share/include/jvm.h Can you fix an existing typo please: ! * error if it is not marked propertly. propertly -> properly Also you seem to have missed this test reference: ./langtools/tools/jdeps/jdkinternals/src/p/Main.java: Class caller = Reflection.getCallerClass(2); Otherwise all changes seem fine. Thanks, David > -Chris. > > P.S. jdk and hotspot tests are still running... > From david.holmes at oracle.com Thu Dec 21 09:29:32 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 21 Dec 2017 19:29:32 +1000 Subject: RFR [11] JDK-8179424: Remove terminally deprecated sun.reflect.Reflection.getCallerClass In-Reply-To: <99F52058-C1A7-459B-A731-188C70AE50F6@oracle.com> References: <90fbc317-4c39-d51e-f402-3803917d065d@oracle.com> <81e288b8-3b95-4fee-3ed8-f3c8a5be9d47@oracle.com> <0719bbfb-924d-9e70-1dfb-9ec782442080@oracle.com> <302E7962-B372-4F1F-92ED-BFDB5CF7B290@oracle.com> <628a9c02-8031-142c-8fef-18d0f00baa67@oracle.com> <99F52058-C1A7-459B-A731-188C70AE50F6@oracle.com> Message-ID: On 21/12/2017 7:20 PM, Chris Hegarty wrote: > David, > >> On 21 Dec 2017, at 00:42, David Holmes wrote: >> >> Hi Chris, >> >> Adding in hotspot-runtime-dev now that you have included the VM side of the cleanup. What repo are you planning on pushing this to? > > Since there are now changes in the hotspot area, then it > probably makes sense to push this through jdk/hs. Okay. >> ... >> >> Can you fix an existing typo please: >> ! * error if it is not marked propertly. >> propertly -> properly > > Fixed. > >> Also you seem to have missed this test reference: >> ./langtools/tools/jdeps/jdkinternals/src/p/Main.java: Class caller = Reflection.getCallerClass(2); > > Oops. Adding langtools testing too. > > Updated webrev: > http://cr.openjdk.java.net/~chegar/8179424/webrev.02/ I don't quite follow the change to the langtools test. Is it just trying to reference something in jdk.unsupported? I don't know what the "patch" does. > What?s the correct set of tests and route into jdk/hs these > days? I?ve not pushed there in a while. I'll email you direct. Thanks, David > -Chris. > From chris.hegarty at oracle.com Thu Dec 21 09:20:11 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 21 Dec 2017 09:20:11 +0000 Subject: RFR [11] JDK-8179424: Remove terminally deprecated sun.reflect.Reflection.getCallerClass In-Reply-To: <628a9c02-8031-142c-8fef-18d0f00baa67@oracle.com> References: <90fbc317-4c39-d51e-f402-3803917d065d@oracle.com> <81e288b8-3b95-4fee-3ed8-f3c8a5be9d47@oracle.com> <0719bbfb-924d-9e70-1dfb-9ec782442080@oracle.com> <302E7962-B372-4F1F-92ED-BFDB5CF7B290@oracle.com> <628a9c02-8031-142c-8fef-18d0f00baa67@oracle.com> Message-ID: <99F52058-C1A7-459B-A731-188C70AE50F6@oracle.com> David, > On 21 Dec 2017, at 00:42, David Holmes wrote: > > Hi Chris, > > Adding in hotspot-runtime-dev now that you have included the VM side of the cleanup. What repo are you planning on pushing this to? Since there are now changes in the hotspot area, then it probably makes sense to push this through jdk/hs. > ... > > Can you fix an existing typo please: > ! * error if it is not marked propertly. > propertly -> properly Fixed. > Also you seem to have missed this test reference: > ./langtools/tools/jdeps/jdkinternals/src/p/Main.java: Class caller = Reflection.getCallerClass(2); Oops. Adding langtools testing too. Updated webrev: http://cr.openjdk.java.net/~chegar/8179424/webrev.02/ What?s the correct set of tests and route into jdk/hs these days? I?ve not pushed there in a while. -Chris. From Alan.Bateman at oracle.com Thu Dec 21 09:54:32 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 21 Dec 2017 09:54:32 +0000 Subject: RFR [11] JDK-8179424: Remove terminally deprecated sun.reflect.Reflection.getCallerClass In-Reply-To: References: <90fbc317-4c39-d51e-f402-3803917d065d@oracle.com> <81e288b8-3b95-4fee-3ed8-f3c8a5be9d47@oracle.com> <0719bbfb-924d-9e70-1dfb-9ec782442080@oracle.com> <302E7962-B372-4F1F-92ED-BFDB5CF7B290@oracle.com> <628a9c02-8031-142c-8fef-18d0f00baa67@oracle.com> <99F52058-C1A7-459B-A731-188C70AE50F6@oracle.com> Message-ID: <6c71f4b2-3f4f-b4b3-84d8-59f9aaf128e8@oracle.com> On 21/12/2017 09:29, David Holmes wrote: > : >> >> Updated webrev: >> ?? http://cr.openjdk.java.net/~chegar/8179424/webrev.02/ > > I don't quite follow the change to the langtools test. Is it just > trying to reference something in jdk.unsupported? I don't know what > the "patch" does. I looked through webrev.02 and it looks okay. I assume there will be a follow-up bug created to re-examine JVM_GetCallerClass. The update to the jdeps test does look a bit odd, wouldn't it be better to change it to another internal API? -Alan From chris.hegarty at oracle.com Thu Dec 21 10:20:18 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 21 Dec 2017 10:20:18 +0000 Subject: RFR [11] JDK-8179424: Remove terminally deprecated sun.reflect.Reflection.getCallerClass In-Reply-To: <6c71f4b2-3f4f-b4b3-84d8-59f9aaf128e8@oracle.com> References: <90fbc317-4c39-d51e-f402-3803917d065d@oracle.com> <81e288b8-3b95-4fee-3ed8-f3c8a5be9d47@oracle.com> <0719bbfb-924d-9e70-1dfb-9ec782442080@oracle.com> <302E7962-B372-4F1F-92ED-BFDB5CF7B290@oracle.com> <628a9c02-8031-142c-8fef-18d0f00baa67@oracle.com> <99F52058-C1A7-459B-A731-188C70AE50F6@oracle.com> <6c71f4b2-3f4f-b4b3-84d8-59f9aaf128e8@oracle.com> Message-ID: <9BEBC253-F5FC-428C-988A-8D19E23A668F@oracle.com> David, Alan, > On 21 Dec 2017, at 09:54, Alan Bateman wrote: > > On 21/12/2017 09:29, David Holmes wrote: >> : >>> >>> Updated webrev: >>> http://cr.openjdk.java.net/~chegar/8179424/webrev.02/ >> >> I don't quite follow the change to the langtools test. Is it just trying to reference something in jdk.unsupported? I don't know what the "patch" does. > I looked through webrev.02 and it looks okay. I assume there will be a follow-up bug created to re-examine JVM_GetCallerClass. > > The update to the jdeps test does look a bit odd, wouldn't it be better to change it to another internal API? The test is about identifying StackWalker as the replacement supported API for getCallerClass, which is continues to do. I could add yet another scenario to test for a different internal API that also has a replacement, and add the appropriate @modules to the test to expose its package. -Chris. From david.holmes at oracle.com Thu Dec 21 12:33:36 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 21 Dec 2017 22:33:36 +1000 Subject: RFR [11] JDK-8179424: Remove terminally deprecated sun.reflect.Reflection.getCallerClass In-Reply-To: <9BEBC253-F5FC-428C-988A-8D19E23A668F@oracle.com> References: <90fbc317-4c39-d51e-f402-3803917d065d@oracle.com> <81e288b8-3b95-4fee-3ed8-f3c8a5be9d47@oracle.com> <0719bbfb-924d-9e70-1dfb-9ec782442080@oracle.com> <302E7962-B372-4F1F-92ED-BFDB5CF7B290@oracle.com> <628a9c02-8031-142c-8fef-18d0f00baa67@oracle.com> <99F52058-C1A7-459B-A731-188C70AE50F6@oracle.com> <6c71f4b2-3f4f-b4b3-84d8-59f9aaf128e8@oracle.com> <9BEBC253-F5FC-428C-988A-8D19E23A668F@oracle.com> Message-ID: <9fa09d1b-af25-cdb7-47f3-d03b025472ae@oracle.com> On 21/12/2017 8:20 PM, Chris Hegarty wrote: > David, Alan, > >> On 21 Dec 2017, at 09:54, Alan Bateman wrote: >> >> On 21/12/2017 09:29, David Holmes wrote: >>> : >>>> >>>> Updated webrev: >>>> http://cr.openjdk.java.net/~chegar/8179424/webrev.02/ >>> >>> I don't quite follow the change to the langtools test. Is it just trying to reference something in jdk.unsupported? I don't know what the "patch" does. >> I looked through webrev.02 and it looks okay. I assume there will be a follow-up bug created to re-examine JVM_GetCallerClass. >> >> The update to the jdeps test does look a bit odd, wouldn't it be better to change it to another internal API? > > The test is about identifying StackWalker as the replacement > supported API for getCallerClass, which is continues to do. Won't pretend I actually understand that, but as long as the test works reliably then okay. Thanks, David > I could add yet another scenario to test for a different internal > API that also has a replacement, and add the appropriate > @modules to the test to expose its package. > > -Chris. > From chris.hegarty at oracle.com Thu Dec 21 12:39:44 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 21 Dec 2017 12:39:44 +0000 Subject: RFR [11] JDK-8179424: Remove terminally deprecated sun.reflect.Reflection.getCallerClass In-Reply-To: <9fa09d1b-af25-cdb7-47f3-d03b025472ae@oracle.com> References: <90fbc317-4c39-d51e-f402-3803917d065d@oracle.com> <81e288b8-3b95-4fee-3ed8-f3c8a5be9d47@oracle.com> <0719bbfb-924d-9e70-1dfb-9ec782442080@oracle.com> <302E7962-B372-4F1F-92ED-BFDB5CF7B290@oracle.com> <628a9c02-8031-142c-8fef-18d0f00baa67@oracle.com> <99F52058-C1A7-459B-A731-188C70AE50F6@oracle.com> <6c71f4b2-3f4f-b4b3-84d8-59f9aaf128e8@oracle.com> <9BEBC253-F5FC-428C-988A-8D19E23A668F@oracle.com> <9fa09d1b-af25-cdb7-47f3-d03b025472ae@oracle.com> Message-ID: <0CCA70D9-E178-4A11-BE2A-9255FE24B7B5@oracle.com> > On 21 Dec 2017, at 12:33, David Holmes wrote: > ... >> The test is about identifying StackWalker as the replacement >> supported API for getCallerClass, which is continues to do. > > Won't pretend I actually understand that, but as long as the test works reliably then okay. Jdeps prints helpful messages when it encounters usage of certain common internal APIs, e.g. "I see your are using sun.reflect.Reflection.getCallerClass(int). This is an internal API which has been replaced by java.lang.StackWalker. You may wanna update your code to use that API instead?. For example, http://hg.openjdk.java.net/jdk/jdk/file/tip/src/jdk.jdeps/share/classes/com/sun/tools/jdeps/resources/jdkinternals.properties#l16 -Chris. From markus.gronlund at oracle.com Thu Dec 21 14:14:11 2017 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Thu, 21 Dec 2017 06:14:11 -0800 (PST) Subject: RFR(S): 8193933: Export ClassLoaderData claim state to support interleaved object traversal Message-ID: Greetings, Kindly asking for reviews for the following changes: Bug: https://bugs.openjdk.java.net/browse/JDK-8193933 Webrev: http://cr.openjdk.java.net/~mgronlun/8193933/webrev01/ Additional information about the changes: The only semantically relevant change here is moving the following member functions from private to public: . bool clear_claimed(); . bool claimed() const; . bool claim(); In addition, I took the opportunity to include a few cleanups that have accumulated over time: For GC folks, removing unused headers from ClassLoaderData.hpp revealed some .cpp's having missing includes for "memory/metaspaceCounters.hpp". . genCollectedHeap.cpp . parallelScavengeHeap.cpp . g1MonitoringSupport.cpp . universe.cpp Each have now received an #include "memory/metaspaceCounters.hpp" Summary changes to ClassLoaderData.hpp: . Removed unused header includes . Removed tracing components (moved to classLoaderData.cpp) . Removed unused member functions . Migrated private member functions to classLoaderData.cpp where possible . Reduced to a single private section and a single public section . Removed unused static variables ReadOnly and ReadWrite metaspaces . Removed/introduced a few forward declarations . Some updated member functions now wrapped in Debug/Non-product declarations . A very short attempt to group declared functionality (iterators, handles, statics) Summary changes ClassLoaderData.cpp: I realize it is pretty hopeless to view the changes to ClassLoaderData.cpp via the webrev. Basically the changes attempts to reduce the amount of interleaving regarding the member function definitions for ClassLoaderDataGraph vs ClassLoaderData vs Iterators. Here is the updated class layout: ClassLoaderData::Dependendencies; ClassLoaderData::ChunkedHandleList; ClassLoaderData ClassLoaderDataGraph Iterators In addition, the member function definition order reflects (although not completely) the groupings in ClassLoaderData.hpp. Thank you Markus From mandy.chung at oracle.com Thu Dec 21 16:09:52 2017 From: mandy.chung at oracle.com (mandy chung) Date: Thu, 21 Dec 2017 08:09:52 -0800 Subject: RFR [11] JDK-8179424: Remove terminally deprecated sun.reflect.Reflection.getCallerClass In-Reply-To: <9BEBC253-F5FC-428C-988A-8D19E23A668F@oracle.com> References: <90fbc317-4c39-d51e-f402-3803917d065d@oracle.com> <81e288b8-3b95-4fee-3ed8-f3c8a5be9d47@oracle.com> <0719bbfb-924d-9e70-1dfb-9ec782442080@oracle.com> <302E7962-B372-4F1F-92ED-BFDB5CF7B290@oracle.com> <628a9c02-8031-142c-8fef-18d0f00baa67@oracle.com> <99F52058-C1A7-459B-A731-188C70AE50F6@oracle.com> <6c71f4b2-3f4f-b4b3-84d8-59f9aaf128e8@oracle.com> <9BEBC253-F5FC-428C-988A-8D19E23A668F@oracle.com> Message-ID: <4e811ed4-54c6-b253-44cb-e2f6a9dd83fe@oracle.com> On 12/21/17 2:20 AM, Chris Hegarty wrote: > David, Alan, > >> On 21 Dec 2017, at 09:54, Alan Bateman wrote: >> >> On 21/12/2017 09:29, David Holmes wrote: >>> : >>>> Updated webrev: >>>> http://cr.openjdk.java.net/~chegar/8179424/webrev.02/ >>> I don't quite follow the change to the langtools test. Is it just trying to reference something in jdk.unsupported? I don't know what the "patch" does. >> I looked through webrev.02 and it looks okay. I assume there will be a follow-up bug created to re-examine JVM_GetCallerClass. >> >> The update to the jdeps test does look a bit odd, wouldn't it be better to change it to another internal API? > The test is about identifying StackWalker as the replacement > supported API for getCallerClass, which is continues to do. > I could add yet another scenario to test for a different internal > API that also has a replacement, and add the appropriate > @modules to the test to expose its package. The test shows sun.reflect.Reflection as a removed API seems odd since the class is present but not getCallerClass(int). p.Main is used to check that reference to sun.reflect.Reflection is flagged as JDK internal use and not a removed class.? I suggest to change it to use another sun.reflect.Reflection API and create an issue to follow up sun.reflect.Reflection as flagged as a removed API. Mandy From coleen.phillimore at oracle.com Thu Dec 21 16:15:06 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 21 Dec 2017 11:15:06 -0500 Subject: RFR(S): 8193933: Export ClassLoaderData claim state to support interleaved object traversal In-Reply-To: References: Message-ID: <5e28f346-944f-1065-7da4-2ae5a3e122a4@oracle.com> This bug is marked for JDK 10.? It is not appropriate to do this level of cleanup for JDK 10. I have only looked through the classLoaderData.hpp changes and I don't agree with the gratuituous moving functions around.? I do like removing header files and adding forward declarations, when possible, but that's a smaller change.? Also a cleanup that should be done in JDK 11, not 10. Thanks, Coleen On 12/21/17 9:14 AM, Markus Gronlund wrote: > Greetings, > > > > Kindly asking for reviews for the following changes: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8193933 > > Webrev: http://cr.openjdk.java.net/~mgronlun/8193933/webrev01/ > > > > Additional information about the changes: > > > > The only semantically relevant change here is moving the following member functions from private to public: > > > > . bool clear_claimed(); > > . bool claimed() const; > > . bool claim(); > > > > In addition, I took the opportunity to include a few cleanups that have accumulated over time: > > > > For GC folks, removing unused headers from ClassLoaderData.hpp revealed some .cpp's having missing includes for "memory/metaspaceCounters.hpp". > > > > . genCollectedHeap.cpp > > . parallelScavengeHeap.cpp > > . g1MonitoringSupport.cpp > > . universe.cpp > > > > Each have now received an #include "memory/metaspaceCounters.hpp" > > > > Summary changes to ClassLoaderData.hpp: > > > > . Removed unused header includes > > . Removed tracing components (moved to classLoaderData.cpp) > > . Removed unused member functions > > . Migrated private member functions to classLoaderData.cpp where possible > > . Reduced to a single private section and a single public section > > . Removed unused static variables ReadOnly and ReadWrite metaspaces > > . Removed/introduced a few forward declarations > > . Some updated member functions now wrapped in Debug/Non-product declarations > > . A very short attempt to group declared functionality (iterators, handles, statics) > > > > Summary changes ClassLoaderData.cpp: > > > > I realize it is pretty hopeless to view the changes to ClassLoaderData.cpp via the webrev. > > Basically the changes attempts to reduce the amount of interleaving regarding the member function definitions for ClassLoaderDataGraph vs ClassLoaderData vs Iterators. > > > > Here is the updated class layout: > > > > ClassLoaderData::Dependendencies; > > ClassLoaderData::ChunkedHandleList; > > ClassLoaderData > > ClassLoaderDataGraph > > Iterators > > > > In addition, the member function definition order reflects (although not completely) the groupings in ClassLoaderData.hpp. > > > > Thank you > > Markus > > > > > > > > From chris.hegarty at oracle.com Thu Dec 21 17:18:19 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 21 Dec 2017 17:18:19 +0000 Subject: RFR [11] JDK-8179424: Remove terminally deprecated sun.reflect.Reflection.getCallerClass In-Reply-To: <4e811ed4-54c6-b253-44cb-e2f6a9dd83fe@oracle.com> References: <90fbc317-4c39-d51e-f402-3803917d065d@oracle.com> <81e288b8-3b95-4fee-3ed8-f3c8a5be9d47@oracle.com> <0719bbfb-924d-9e70-1dfb-9ec782442080@oracle.com> <302E7962-B372-4F1F-92ED-BFDB5CF7B290@oracle.com> <628a9c02-8031-142c-8fef-18d0f00baa67@oracle.com> <99F52058-C1A7-459B-A731-188C70AE50F6@oracle.com> <6c71f4b2-3f4f-b4b3-84d8-59f9aaf128e8@oracle.com> <9BEBC253-F5FC-428C-988A-8D19E23A668F@oracle.com> <4e811ed4-54c6-b253-44cb-e2f6a9dd83fe@oracle.com> Message-ID: > On 21 Dec 2017, at 16:09, mandy chung wrote: > >>> ... >> The test is about identifying StackWalker as the replacement >> supported API for getCallerClass, which is continues to do. >> I could add yet another scenario to test for a different internal >> API that also has a replacement, and add the appropriate >> @modules to the test to expose its package. >> > > The test shows sun.reflect.Reflection as a removed API seems odd since the class is present but not getCallerClass(int). There appears to be some confusion here. My webrev REMOVES sun.reflect.Reflection completely, since getCallerClass(int) was its last method. For compilation purposes, the test uses a patched jdk.unsupported module with sun.reflect.Reflection, but that class is not present at runtime. So the sun.reflect.Reflection internal API has been removed, no? > p.Main is used to check that reference to sun.reflect.Reflection is flagged as JDK internal use and not a removed class. I suggest to change it to use another sun.reflect.Reflection API There is no other API in sun.reflect.Reflection, unless you mean to use something in sun.reflect.ReflectionFactory ? > and create an issue to follow up sun.reflect.Reflection as flagged as a removed API. That?s what the test now does with my changes. Why separate it out into a separate issue? If we need a test for an internal API, I can add a scenario that uses sun.reflect.ReflectionFactory. -Chris. From markus.gronlund at oracle.com Thu Dec 21 17:26:17 2017 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Thu, 21 Dec 2017 09:26:17 -0800 (PST) Subject: RFR(S): 8193933: Export ClassLoaderData claim state to support interleaved object traversal In-Reply-To: <5e28f346-944f-1065-7da4-2ae5a3e122a4@oracle.com> References: <5e28f346-944f-1065-7da4-2ae5a3e122a4@oracle.com> Message-ID: <1222e132-d63c-4be4-8a35-8c19c1ed276a@default> Hi Coleen, We can postpone any cleanup activities in this area for 11. Here is a minimal change: http://cr.openjdk.java.net/~mgronlun/8193933/webrev02/ Thanks Markus -----Original Message----- From: Coleen Phillimore Sent: den 21 december 2017 17:15 To: hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR(S): 8193933: Export ClassLoaderData claim state to support interleaved object traversal This bug is marked for JDK 10.? It is not appropriate to do this level of cleanup for JDK 10. I have only looked through the classLoaderData.hpp changes and I don't agree with the gratuituous moving functions around.? I do like removing header files and adding forward declarations, when possible, but that's a smaller change.? Also a cleanup that should be done in JDK 11, not 10. Thanks, Coleen From coleen.phillimore at oracle.com Thu Dec 21 18:10:47 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 21 Dec 2017 13:10:47 -0500 Subject: RFR(S): 8193933: Export ClassLoaderData claim state to support interleaved object traversal In-Reply-To: <1222e132-d63c-4be4-8a35-8c19c1ed276a@default> References: <5e28f346-944f-1065-7da4-2ae5a3e122a4@oracle.com> <1222e132-d63c-4be4-8a35-8c19c1ed276a@default> Message-ID: Hi Markus, This looks fine.? Happy new year! Coleen On 12/21/17 12:26 PM, Markus Gronlund wrote: > Hi Coleen, > > We can postpone any cleanup activities in this area for 11. > > Here is a minimal change: > > http://cr.openjdk.java.net/~mgronlun/8193933/webrev02/ > > Thanks > Markus > > -----Original Message----- > From: Coleen Phillimore > Sent: den 21 december 2017 17:15 > To: hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR(S): 8193933: Export ClassLoaderData claim state to support interleaved object traversal > > > This bug is marked for JDK 10.? It is not appropriate to do this level of cleanup for JDK 10. > > I have only looked through the classLoaderData.hpp changes and I don't agree with the gratuituous moving functions around.? I do like removing header files and adding forward declarations, when possible, but that's a smaller change.? Also a cleanup that should be done in JDK 11, not 10. > > Thanks, > Coleen > From harold.seigel at oracle.com Thu Dec 21 18:33:18 2017 From: harold.seigel at oracle.com (harold seigel) Date: Thu, 21 Dec 2017 13:33:18 -0500 Subject: RFR(S): 8193933: Export ClassLoaderData claim state to support interleaved object traversal In-Reply-To: References: <5e28f346-944f-1065-7da4-2ae5a3e122a4@oracle.com> <1222e132-d63c-4be4-8a35-8c19c1ed276a@default> Message-ID: +1 Harold On 12/21/2017 1:10 PM, coleen.phillimore at oracle.com wrote: > Hi Markus, > This looks fine.? Happy new year! > Coleen > > On 12/21/17 12:26 PM, Markus Gronlund wrote: >> Hi Coleen, >> >> We can postpone any cleanup activities in this area for 11. >> >> Here is a minimal change: >> >> http://cr.openjdk.java.net/~mgronlun/8193933/webrev02/ >> >> Thanks >> Markus >> >> -----Original Message----- >> From: Coleen Phillimore >> Sent: den 21 december 2017 17:15 >> To: hotspot-runtime-dev at openjdk.java.net >> Subject: Re: RFR(S): 8193933: Export ClassLoaderData claim state to >> support interleaved object traversal >> >> >> This bug is marked for JDK 10.? It is not appropriate to do this >> level of cleanup for JDK 10. >> >> I have only looked through the classLoaderData.hpp changes and I >> don't agree with the gratuituous moving functions around.? I do like >> removing header files and adding forward declarations, when possible, >> but that's a smaller change.? Also a cleanup that should be done in >> JDK 11, not 10. >> >> Thanks, >> Coleen >> > From mandy.chung at oracle.com Thu Dec 21 21:40:57 2017 From: mandy.chung at oracle.com (mandy chung) Date: Thu, 21 Dec 2017 13:40:57 -0800 Subject: RFR [11] JDK-8179424: Remove terminally deprecated sun.reflect.Reflection.getCallerClass In-Reply-To: References: <90fbc317-4c39-d51e-f402-3803917d065d@oracle.com> <81e288b8-3b95-4fee-3ed8-f3c8a5be9d47@oracle.com> <0719bbfb-924d-9e70-1dfb-9ec782442080@oracle.com> <302E7962-B372-4F1F-92ED-BFDB5CF7B290@oracle.com> <628a9c02-8031-142c-8fef-18d0f00baa67@oracle.com> <99F52058-C1A7-459B-A731-188C70AE50F6@oracle.com> <6c71f4b2-3f4f-b4b3-84d8-59f9aaf128e8@oracle.com> <9BEBC253-F5FC-428C-988A-8D19E23A668F@oracle.com> <4e811ed4-54c6-b253-44cb-e2f6a9dd83fe@oracle.com> Message-ID: <34412585-eac6-0e62-a5b8-e8f8dd42645e@oracle.com> On 12/21/17 9:18 AM, Chris Hegarty wrote: >> On 21 Dec 2017, at 16:09, mandy chung wrote: >> >>>> ... >>> The test is about identifying StackWalker as the replacement >>> supported API for getCallerClass, which is continues to do. >>> I could add yet another scenario to test for a different internal >>> API that also has a replacement, and add the appropriate >>> @modules to the test to expose its package. >>> >> The test shows sun.reflect.Reflection as a removed API seems odd since the class is present but not getCallerClass(int). > There appears to be some confusion here. My webrev REMOVES > sun.reflect.Reflection completely, since getCallerClass(int) was its > last method. For compilation purposes, the test uses a patched > jdk.unsupported module with sun.reflect.Reflection, but that class > is not present at runtime. So the sun.reflect.Reflection internal API > has been removed, no? That clarifies it.? Thanks. > >> p.Main is used to check that reference to sun.reflect.Reflection is flagged as JDK internal use and not a removed class. I suggest to change it to use another sun.reflect.Reflection API > There is no other API in sun.reflect.Reflection, unless you mean > to use something in sun.reflect.ReflectionFactory ? > ReflectionFactory or other class in sun.reflect package would do it. >> and create an issue to follow up sun.reflect.Reflection as flagged as a removed API. > That?s what the test now does with my changes. Why separate it > out into a separate issue? If we need a test for an internal API, I > can add a scenario that uses sun.reflect.ReflectionFactory. Yes please. That's what this case intends to verify. Thanks Mandy From david.holmes at oracle.com Fri Dec 22 08:07:22 2017 From: david.holmes at oracle.com (David Holmes) Date: Fri, 22 Dec 2017 18:07:22 +1000 Subject: (11) RFR: 8194071: [Testbug] Update VMDeprecatedOptions test for obsolete/expired options Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8194071 webrev: http://cr.openjdk.java.net/~dholmes/8194071/webrev/ In preparation for bumping the JDK version to 11 we remove the deprecated flags that will become obsolete or expired in JDK 11, so that the test will pass. Each flag has an open issue that deals with its actual obsoletion/expiration, and which will hopefully be dealt with very promptly so that the VM warnings (when we switch to version 11) will disappear. Thanks, David From chris.hegarty at oracle.com Fri Dec 22 10:16:14 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 22 Dec 2017 10:16:14 +0000 Subject: RFR [11] JDK-8179424: Remove terminally deprecated sun.reflect.Reflection.getCallerClass In-Reply-To: <34412585-eac6-0e62-a5b8-e8f8dd42645e@oracle.com> References: <90fbc317-4c39-d51e-f402-3803917d065d@oracle.com> <81e288b8-3b95-4fee-3ed8-f3c8a5be9d47@oracle.com> <0719bbfb-924d-9e70-1dfb-9ec782442080@oracle.com> <302E7962-B372-4F1F-92ED-BFDB5CF7B290@oracle.com> <628a9c02-8031-142c-8fef-18d0f00baa67@oracle.com> <99F52058-C1A7-459B-A731-188C70AE50F6@oracle.com> <6c71f4b2-3f4f-b4b3-84d8-59f9aaf128e8@oracle.com> <9BEBC253-F5FC-428C-988A-8D19E23A668F@oracle.com> <4e811ed4-54c6-b253-44cb-e2f6a9dd83fe@oracle.com> <34412585-eac6-0e62-a5b8-e8f8dd42645e@oracle.com> Message-ID: <0a57854d-b5d5-a30a-02cb-14617ef625ca@oracle.com> On 21/12/17 21:40, mandy chung wrote: > ... > > ReflectionFactory or other class in sun.reflect package would do it. >>> and create an issue to follow up sun.reflect.Reflection as flagged as a removed API. >> That?s what the test now does with my changes. Why separate it >> out into a separate issue? If we need a test for an internal API, I >> can add a scenario that uses sun.reflect.ReflectionFactory. > > Yes please. That's what this case intends to verify. Webrev with the test updated as suggested: http://cr.openjdk.java.net/~chegar/8179424/webrev.03/ -Chris. From harold.seigel at oracle.com Fri Dec 22 12:53:13 2017 From: harold.seigel at oracle.com (harold seigel) Date: Fri, 22 Dec 2017 07:53:13 -0500 Subject: (11) RFR: 8194071: [Testbug] Update VMDeprecatedOptions test for obsolete/expired options In-Reply-To: References: Message-ID: <39a61908-ec37-5798-56e3-12cc716cdbb5@oracle.com> Hi David, The fix looks good and can be pushed based on trivial rule. Thanks, Harold On 12/22/2017 3:07 AM, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8194071 > webrev: http://cr.openjdk.java.net/~dholmes/8194071/webrev/ > > In preparation for bumping the JDK version to 11 we remove the > deprecated flags that will become obsolete or expired in JDK 11, so > that the test will pass. > > Each flag has an open issue that deals with its actual > obsoletion/expiration, and which will hopefully be dealt with very > promptly so that the VM warnings (when we switch to version 11) will > disappear. > > Thanks, > David From mandy.chung at oracle.com Fri Dec 22 16:42:01 2017 From: mandy.chung at oracle.com (mandy chung) Date: Fri, 22 Dec 2017 08:42:01 -0800 Subject: RFR [11] JDK-8179424: Remove terminally deprecated sun.reflect.Reflection.getCallerClass In-Reply-To: <0a57854d-b5d5-a30a-02cb-14617ef625ca@oracle.com> References: <90fbc317-4c39-d51e-f402-3803917d065d@oracle.com> <81e288b8-3b95-4fee-3ed8-f3c8a5be9d47@oracle.com> <0719bbfb-924d-9e70-1dfb-9ec782442080@oracle.com> <302E7962-B372-4F1F-92ED-BFDB5CF7B290@oracle.com> <628a9c02-8031-142c-8fef-18d0f00baa67@oracle.com> <99F52058-C1A7-459B-A731-188C70AE50F6@oracle.com> <6c71f4b2-3f4f-b4b3-84d8-59f9aaf128e8@oracle.com> <9BEBC253-F5FC-428C-988A-8D19E23A668F@oracle.com> <4e811ed4-54c6-b253-44cb-e2f6a9dd83fe@oracle.com> <34412585-eac6-0e62-a5b8-e8f8dd42645e@oracle.com> <0a57854d-b5d5-a30a-02cb-14617ef625ca@oracle.com> Message-ID: <42fab3cb-3dc0-f311-31aa-26952d0c835e@oracle.com> On 12/22/17 2:16 AM, Chris Hegarty wrote: > > Webrev with the test updated as suggested: > ? http://cr.openjdk.java.net/~chegar/8179424/webrev.03/ > Looks good.? Thanks for updating the test. Mandy From david.holmes at oracle.com Fri Dec 22 20:22:47 2017 From: david.holmes at oracle.com (David Holmes) Date: Sat, 23 Dec 2017 06:22:47 +1000 Subject: (11) RFR: 8194071: [Testbug] Update VMDeprecatedOptions test for obsolete/expired options In-Reply-To: <39a61908-ec37-5798-56e3-12cc716cdbb5@oracle.com> References: <39a61908-ec37-5798-56e3-12cc716cdbb5@oracle.com> Message-ID: Thanks Harold! BTW should have explicitly noted this is getting pushed to jdk/jdk as that is where the version update will happen first. But I expect to pull down from jdk to hs sometime over the break anyway. David On 22/12/2017 10:53 PM, harold seigel wrote: > Hi David, > > The fix looks good and can be pushed based on trivial rule. > > Thanks, Harold > > > On 12/22/2017 3:07 AM, David Holmes wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8194071 >> webrev: http://cr.openjdk.java.net/~dholmes/8194071/webrev/ >> >> In preparation for bumping the JDK version to 11 we remove the >> deprecated flags that will become obsolete or expired in JDK 11, so >> that the test will pass. >> >> Each flag has an open issue that deals with its actual >> obsoletion/expiration, and which will hopefully be dealt with very >> promptly so that the VM warnings (when we switch to version 11) will >> disappear. >> >> Thanks, >> David > From goetz.lindenmaier at sap.com Wed Dec 27 10:37:51 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 27 Dec 2017 10:37:51 +0000 Subject: RFR(XS): 8194232: Container memory not properly recognized. Message-ID: Hi Please review and sponsor this tiny fix. It needs to go to jdk10. http://cr.openjdk.java.net/~goetz/wr17/8194232-ppcle_unlimited/webrev.01/ TestAggressiveHeap.java fails because the container recognition misinterprets the available memory size. On SLES 12.1 ppc64le, GET_CONTAINER_INFO() sets memlimit to 0x7FFFFFFFFFFF0000. This is compared to UNLIMITED_MEM == 0x7FFFFFFFFFFFF000, making the VM believe memory is _not_ unlimited. Best regards, Goetz. From martin.doerr at sap.com Wed Dec 27 11:09:50 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 27 Dec 2017 11:09:50 +0000 Subject: RFR(XS): 8194232: Container memory not properly recognized. In-Reply-To: References: Message-ID: <2aceeb37519d4f169f61b945fea7a2bb@sap.com> Hi G?tz, thanks for fixing it. I wonder if 4 zeroes will be sufficient on all linux distros in the long run. Does anything speak against using e.g. 8 zeroes? Best regards, Martin -----Original Message----- From: hotspot-runtime-dev [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz Sent: Mittwoch, 27. Dezember 2017 11:38 To: hotspot-runtime-dev at openjdk.java.net Subject: RFR(XS): 8194232: Container memory not properly recognized. Hi Please review and sponsor this tiny fix. It needs to go to jdk10. http://cr.openjdk.java.net/~goetz/wr17/8194232-ppcle_unlimited/webrev.01/ TestAggressiveHeap.java fails because the container recognition misinterprets the available memory size. On SLES 12.1 ppc64le, GET_CONTAINER_INFO() sets memlimit to 0x7FFFFFFFFFFF0000. This is compared to UNLIMITED_MEM == 0x7FFFFFFFFFFFF000, making the VM believe memory is _not_ unlimited. Best regards, Goetz. From goetz.lindenmaier at sap.com Wed Dec 27 11:24:04 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 27 Dec 2017 11:24:04 +0000 Subject: RFR(XS): 8194232: Container memory not properly recognized. In-Reply-To: <2aceeb37519d4f169f61b945fea7a2bb@sap.com> References: <2aceeb37519d4f169f61b945fea7a2bb@sap.com> Message-ID: <055a9833c3104aafa78c255478be7923@sap.com> Hi Martin, Yes, I also figured that the constant is one system page less than max long. If the system pages are > 64K, this constant will be too small, again. But I'm not sure whether adding 8 zeros is right thing to do in ramp down phase. Best regards, Goetz. > -----Original Message----- > From: Doerr, Martin > Sent: Mittwoch, 27. Dezember 2017 12:10 > To: Lindenmaier, Goetz ; hotspot-runtime- > dev at openjdk.java.net > Subject: RE: RFR(XS): 8194232: Container memory not properly recognized. > > Hi G?tz, > > thanks for fixing it. > > I wonder if 4 zeroes will be sufficient on all linux distros in the long run. Does > anything speak against using e.g. 8 zeroes? > > Best regards, > Martin > > > -----Original Message----- > From: hotspot-runtime-dev [mailto:hotspot-runtime-dev- > bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz > Sent: Mittwoch, 27. Dezember 2017 11:38 > To: hotspot-runtime-dev at openjdk.java.net > Subject: RFR(XS): 8194232: Container memory not properly recognized. > > Hi > > Please review and sponsor this tiny fix. It needs to go to jdk10. > http://cr.openjdk.java.net/~goetz/wr17/8194232- > ppcle_unlimited/webrev.01/ > > TestAggressiveHeap.java fails because the container recognition > misinterprets the available memory size. On SLES 12.1 ppc64le, > GET_CONTAINER_INFO() sets memlimit to 0x7FFFFFFFFFFF0000. This > is compared to UNLIMITED_MEM == 0x7FFFFFFFFFFFF000, making > the VM believe memory is _not_ unlimited. > > Best regards, > Goetz. From martin.doerr at sap.com Thu Dec 28 17:47:03 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 28 Dec 2017 17:47:03 +0000 Subject: RFR(M): 8194258: PPC64 safepoint mechanism: Fix initialization on AIX and support SIGTRAP Message-ID: Hi, unfortunately, the safepoint mechanism initialization on AIX is not completely correct, yet. The VM crashes when using -XX:-OptimizePollingPageLocation or when allocation at desired addresses failed. Only pages allocated by mmap can be read protected. In addition, SIGTRAP-based polling performs slightly better on PPC64 and avoids the need for allocating a protected page. I have uploaded a webrev: http://cr.openjdk.java.net/~mdoerr/8194258_PPC64_poll/webrev.00/ We use trap instructions if UseSIGTRAP is enabled (PPC64 specific -XX flag) and fall back to loads from the polling pages otherwise. Please review. I will also need a sponsor because I'm changing the shared file safepointMechanism.cpp. It's not a functional change for other platforms. Best regards, Martin From robbin.ehn at oracle.com Fri Dec 29 11:50:00 2017 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Fri, 29 Dec 2017 12:50:00 +0100 Subject: RFR(M): 8194258: PPC64 safepoint mechanism: Fix initialization on AIX and support SIGTRAP In-Reply-To: References: Message-ID: <224970df-9409-f093-3b97-e36bf4f69f37@oracle.com> Hi Martin, Looks fine! /Robbin On 2017-12-28 18:47, Doerr, Martin wrote: > Hi, > > unfortunately, the safepoint mechanism initialization on AIX is not completely correct, yet. The VM crashes when using -XX:-OptimizePollingPageLocation or when allocation at desired addresses failed. > > Only pages allocated by mmap can be read protected. > > In addition, SIGTRAP-based polling performs slightly better on PPC64 and avoids the need for allocating a protected page. > > I have uploaded a webrev: > > http://cr.openjdk.java.net/~mdoerr/8194258_PPC64_poll/webrev.00/ > > We use trap instructions if UseSIGTRAP is enabled (PPC64 specific -XX flag) and fall back to loads from the polling pages otherwise. > > Please review. > > I will also need a sponsor because I?m changing the shared file safepointMechanism.cpp. It?s not a functional change for other platforms. > > Best regards, > > Martin > From goetz.lindenmaier at sap.com Sat Dec 30 13:00:42 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Sat, 30 Dec 2017 13:00:42 +0000 Subject: RFR(M): 8194258: PPC64 safepoint mechanism: Fix initialization on AIX and support SIGTRAP In-Reply-To: References: Message-ID: <6e810d78f2ae4b89a5022365a699e934@sap.com> Hi Martin, thanks for fixing this issue. The change itself looks good. Nevertheless some points: I would like a comment about the sigtrap mechanism used on ppc, maybe where the macro for UseSIGTRAP is set. I think you need to adapt runtime/logging/OsCpuLoggingTest.java. The tracing is missing on linuxppc, too, if UseSIGTRAP is set. Maybe the test should call the VM with -XX:-UseSIGTRAP on ppc? And then it should work on aix, too? Best regards, Goetz. > -----Original Message----- > From: Doerr, Martin > Sent: Donnerstag, 28. Dezember 2017 18:47 > To: hotspot-runtime-dev at openjdk.java.net; Robbin Ehn > ; Lindenmaier, Goetz > Subject: RFR(M): 8194258: PPC64 safepoint mechanism: Fix initialization on AIX > and support SIGTRAP > > Hi, > > > > unfortunately, the safepoint mechanism initialization on AIX is not completely > correct, yet. The VM crashes when using -XX:-OptimizePollingPageLocation or > when allocation at desired addresses failed. > > Only pages allocated by mmap can be read protected. > > > > In addition, SIGTRAP-based polling performs slightly better on PPC64 and avoids > the need for allocating a protected page. > > > > I have uploaded a webrev: > > http://cr.openjdk.java.net/~mdoerr/8194258_PPC64_poll/webrev.00/ > > > > We use trap instructions if UseSIGTRAP is enabled (PPC64 specific -XX flag) and > fall back to loads from the polling pages otherwise. > > > > Please review. > > > > I will also need a sponsor because I'm changing the shared file > safepointMechanism.cpp. It's not a functional change for other platforms. > > > > Best regards, > > Martin > >