From erik.joelsson at oracle.com Wed Jan 2 08:52:03 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 2 Jan 2019 09:52:03 +0100 Subject: RFR(M): 8215902: Add support for SoftFloat-3e library In-Reply-To: <4497ca084b9f48dbb8f6de1aa35c83653fd7acfb.camel@gmail.com> References: <4497ca084b9f48dbb8f6de1aa35c83653fd7acfb.camel@gmail.com> Message-ID: <22c3e7fe-b092-bae5-39d2-2a28c96d5412@oracle.com> From a build perspective, this looks very good. I think adding a link to the github project in the doc makes sense if you want to do that. /Erik On 2018-12-25 16:19, Jakub Van?k wrote: > Hi, > > please review this webrev. It is a successor of the softfloat-3 [patch] > thread (first email > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-November/031311.html > ) > > Changes since the last patch (v6): > > - renamed --with-softloat* to --with-sflt* (it is more compact and it > corresponds to the old --with-sflt-lib=... option) > > - license is now obtained via --with-sflt-license switch (so it is not > included in OpenJDK source tree) > > - updated documentation (slight rewording, added the license option) > > - checks for default --with/--without behavior are in place again > (I forgot them when I changed the way the library is detected) > > - added a simple testcase - I found a disrepancy between softfloat and > system function behavior. When a float with bits 0x003FFFFF is > added to 0x00000001, the correct result is 0x00400000, but the > default software floating point implementation returns 0x00000000. > However I'm not sure where to put this test - now it is in > test/hotspot/jtreg/compiler/floatingpoint. > > - comments in code refer to CR 6757269 and newly JDK-8215902 too. > > I have created a repository with SoftFloat-3e with build configuration > specifically for OpenJDK on armel: > https://github.com/ev3dev-lang-java/softfloat-openjdk > > I can add a link to it to the documentation. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215902 > Webrev: http://cr.openjdk.java.net/~jakvanek/8215902/webrev.02/ > CI build: https://ci.adoptopenjdk.net/view/ev3dev/job/openjdk12_build_ev3_linux/67/ > > Cheers, > > Jakub > From harold.seigel at oracle.com Wed Jan 2 15:42:02 2019 From: harold.seigel at oracle.com (Harold David Seigel) Date: Wed, 2 Jan 2019 10:42:02 -0500 Subject: RFR 8215398: -Xlog option usage => Invalid decorator'\temp\app_cds.log'. In-Reply-To: <9d1ca342-b9b2-32da-8eca-8504a79bd0b4@oracle.com> References: <71efe071-62c1-b1cc-c98f-953c6790eae1@oracle.com> <37e19362-0065-eb00-9bfb-7dcd67f55318@oracle.com> <3b0ff6e7-0fa6-d631-e203-c6070c1e66f0@oracle.com> <1a8d1c28-bc6c-da60-11bb-a57b48ee90b9@oracle.com> <2602b588-9d9e-253e-a875-046846141364@oracle.com> <5c1d77bd.1c69fb81.695ed.d412@mx.google.com> <9d1ca342-b9b2-32da-8eca-8504a79bd0b4@oracle.com> Message-ID: Thanks for your comments.? I pushed the fix. Harold On 12/21/2018 10:47 PM, David Holmes wrote: > On 22/12/2018 9:31 am, Bernd Eckenfels wrote: >> Hello, >> >> David: >>> I don't have an issue with your fix. I just don't understand how the >>> existing test actually works when the test cases seems to fail at the >>> command-line for me. >> >> I think the difference between commandlie and testcase is, that the >> command line Interpreter might do some additional Interpretation of >> quotes and the process builder might transparently wrap Arguments in >> additional quotes. If I recall correctly on Windows the launcher does >> some quite Interpretation, not on *nix. Maybe ist best to compare the >> command line of the running process to be sure all intended cases are >> tested? >> >> (But for Windows ist not that easy to pass those quotes as theyare >> removed on muiltiple Levels ? I think tripple quotes might pass >> through), so supporting single quotes and also raw drive letter (even >> when seem uncanonical interpretation) seems like a good idea.) > > I've no idea what's happening. All I know is that syntax that is > supposed to work (not altered by this bug) is not actually working. > > It will be interesting to see what happens after this patch is applied. > > Thanks, > David > >> On Linux I would rather expect to generate filenames with single >> quotes if it is docmented to look for double quotes only. (I I pass a >> quoted single Quote to a command it will be part of the file name on >> most unix Tools) >> >> Gruss >> Bernd >> From harold.seigel at oracle.com Wed Jan 2 15:41:29 2019 From: harold.seigel at oracle.com (Harold David Seigel) Date: Wed, 2 Jan 2019 10:41:29 -0500 Subject: RFR 8215398: -Xlog option usage => Invalid decorator '\temp\app_cds.log'. In-Reply-To: <2602b588-9d9e-253e-a875-046846141364@oracle.com> References: <71efe071-62c1-b1cc-c98f-953c6790eae1@oracle.com> <37e19362-0065-eb00-9bfb-7dcd67f55318@oracle.com> <3b0ff6e7-0fa6-d631-e203-c6070c1e66f0@oracle.com> <1a8d1c28-bc6c-da60-11bb-a57b48ee90b9@oracle.com> <2602b588-9d9e-253e-a875-046846141364@oracle.com> Message-ID: Hi David, Thanks for the review.? I pushed the fix. I think the existing test works because the double quoted arguments are passed directly to the java process, with no intervening shell, and so the double quotes are not removed.? When running the same command from the Windows prompt, the shell is stripping out the enclosing double quotes before passing the -Xlog args to Java. Harold On 12/21/2018 5:08 PM, David Holmes wrote: > Hi Harold, > > On 22/12/2018 4:32 am, Harold David Seigel wrote: >> Hi David, >> >> Here is the latest webrev.? The only difference between this and the >> previous webrev is the addition of "@bug 8215398" to the test: >> >> http://cr.openjdk.java.net/~hseigel/bug_8215398.3/webrev/index.html > > Okay. > >> >> The point that I'm trying to make about logging's handling of single >> quotes vs. double quotes can perhaps best be shown on Linux: >> >> If I execute the following commands (on Linux): >> >> ??? java -Xlog:safepoint=trace:\"dquotes.log\" -version >> >> ??? java -Xlog:safepoint=trace:\'squotes.log\' -version >> >> and then list out the current directory: >> >> ???? > ls >> ??? 'squotes.log'? dquotes.log >> >> it shows that logging stripped off the double quotes, but not the >> single quotes. > > I see - that is very odd behaviour. > >> With my fix, these commands succeed on Windows even when run from the >> Windows shell: >> >> ??? java -Xlog:safepoint=trace:d:\safepointtrace.txt -version >> ??? java -Xlog:safepoint=trace:"d:\safepointtrace.txt" -version >> ??? java -Xlog:safepoint=trace:"d:\safepoint trace.txt" -version >> >> This one continues to fail because of the single quote issue >> described above: >> >> ??? java -Xlog:safepoint=trace:'d:\safepointtrace.txt' -version >> >> I hope we can move forward with this change. > > I don't have an issue with your fix. I just don't understand how the > existing test actually works when the test cases seems to fail at the > command-line for me. > > Thanks, > David > >> Thanks, Harold >> >> >> On 12/20/2018 9:28 PM, David Holmes wrote: >>> On 21/12/2018 7:30 am, Harold David Seigel wrote: >>>> Hi David, >>>> >>>> Thanks for looking at this! >>>> >>>> Please review this updated webrev.? The fix is the same but the >>>> webrev contains a new test instead of modifying an existing test: >>>> >>>> http://cr.openjdk.java.net/~hseigel/bug_8215398.2/webrev/ >>> >>> I think renaming the existing test would be better as the only >>> difference is the use of quotes. But if you want a new test please add: >>> >>> @bug 8215398 >>> >>>> The logging implementation does not handle single quotes as >>>> expected.? For example, if the TestQuotedLogOutputs.java test is >>>> changed to use single quotes instead of double quotes, it will >>>> fail, even on Linux, because the single quotes are included as part >>>> of the file name.? They are not stripped off.? That is why "java >>>> -Xlog:safepoint=trace:'d:\safepointtrace.txt' -version" fails. >>> >>> It fails with double-quotes too! AFAICS it always fails in a Windows >>> command shell. Maybe the test only passes in cygwin shell? >>> >>> That said I don't understand your comment. I expect the quotes to >>> delimit the filename in case the filename has spaces in the path >>> component. If they aren't stripped off it wouldn't be tokenizing at >>> the internal ":", so ... ??? >>> >>> Thanks, >>> David >>> >>>> Perhaps a new bug is needed to change logging's handling of single >>>> quotes?? It's a bit surprising that this issue hasn't already been >>>> reported. >>>> >>>> Thanks, Harold >>>> >>>> On 12/20/2018 2:07 AM, David Holmes wrote: >>>>> Hi Harold, >>>>> >>>>> On 19/12/2018 11:22 pm, Harold David Seigel wrote: >>>>>> Hi, >>>>>> >>>>>> Please review this small change to fix JDK-8215398.? The fix >>>>>> works by not treating ':' as a delimiter in a -Xlog... option >>>>>> string if it is following by a '\' and preceded by either a >>>>>> single character or the text 'file='.? The fix is for Windows only. >>>>>> >>>>>> Open Webrev: >>>>>> http://cr.openjdk.java.net/~hseigel/bug_8215398/webrev/index.html >>>>> >>>>> I think I can follow the fix. >>>>> >>>>> But I'm a bit concerned about the test. AFAICS the test thought it >>>>> was already testing this case - albeit with the path quoted: >>>>> >>>>> ? 42???????? // Ensure log files can be specified with full path. >>>>> ? 43???????? // On windows, this means that the file name will >>>>> contain >>>>> ? 44???????? // a colon ('C:\log.txt' for example), which is used to >>>>> ? 45???????? // separate -Xlog: options >>>>> (-Xlog:tags:filename:decorators). >>>>> ? 46???????? // Try to log to a file in our current directory, >>>>> using its absolute path. >>>>> ? 47???????? String baseName = "test file.log"; >>>>> ? 48???????? Path filePath = Paths.get(baseName).toAbsolutePath(); >>>>> ? 49???????? String fileName = filePath.toString(); >>>>> ? 50???????? File file = filePath.toFile(); >>>>> ... >>>>> ? 65???????? String[] validOutputs = new String[] { >>>>> ? 66???????????? quote + fileName + quote, >>>>> ? 67???????????? "file=" + quote + fileName + quote, >>>>> ? 68???????????? quote + fileName + quote + ":", >>>>> ? 69???????????? quote + fileName + quote + "::" >>>>> ? 70???????? }; >>>>> >>>>> But even quoted if I specify the drive designator in the path, it >>>>> fails! Here's a local attempt at this: >>>>> >>>>> D:\ade> apps\Java\jdk-11\fastdebug\bin\java >>>>> -Xlog:safepoint=trace:'d:\safepointtrace.txt' -version >>>>> [0.014s][error][logging] Invalid decorator '\safepointtrace.txt''. >>>>> Invalid -Xlog option >>>>> '-Xlog:safepoint=trace:'d:\safepointtrace.txt'', see error log for >>>>> details. >>>>> Error: Could not create the Java Virtual Machine. >>>>> Error: A fatal exception has occurred. Program will exit. >>>>> >>>>> So AFAICS the test can't possibly have been testing what it >>>>> thought it was testing! ??? >>>>> >>>>> I'm also not sure about just adding some unquoted variants to the >>>>> existing TestQuotedLogOutputs without renaming the test and >>>>> updating the @summary >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8215398 >>>>>> >>>>>> The fix was regression tested by running Mach5 tiers 1 and 2 >>>>>> tests and builds on Linux-x64, Windows, and Mac OS X, running >>>>>> tiers 3-5 tests on Linux-x64, running JCK-12 Lang and VM tests on >>>>>> Linux-x64, and by hand on Windows. >>>>>> >>>>>> Thanks, Harol >>>>>> >>>> >> From harold.seigel at oracle.com Wed Jan 2 18:49:49 2019 From: harold.seigel at oracle.com (Harold David Seigel) Date: Wed, 2 Jan 2019 13:49:49 -0500 Subject: RFR 8215644: Clean up globalDefinitions_.hpp In-Reply-To: References: <4548bce5-681b-155a-1caa-91d449f31da1@oracle.com> <38CE2E51-C9AA-4452-AB32-8EF41B4C327F@oracle.com> Message-ID: Hi Kim, Thanks for looking at this. Please review this updated webrev: http://cr.openjdk.java.net/~hseigel/bug_8215644.2/webrev/index.html The only difference from the previous webrev is between lines 1100 - 1110 in the modified globalDefinitions.hpp file.? The change includes removing the two-arg build_u2_from() function as suggested below. I also created a new RFE, JDK-8216010 , to change the callers of build_u2_from() and remove it. Thanks, Harold On 12/27/2018 5:28 PM, Kim Barrett wrote: >> On Dec 27, 2018, at 5:21 PM, Kim Barrett wrote: >> >>> On Dec 20, 2018, at 11:58 AM, Harold David Seigel wrote: >>> >>> Hi, >>> >>> Please review this fix for JDK-8215644. The fix deletes old code and moves misplaced code as described in the bug. >>> >>> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8215644/webrev/index.html >>> >>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8215644 >>> >>> The fix was regression tested by running Mach5 tiers 1 and 2 tests and builds on Linux-x64, Windows, and Mac OS X and by running JCK-12 Lang and VM tests on Linux-x64. >>> >>> Thanks, Harold > I forgot to say, looks good. > >> ------------------------------------------------------------------------------ >> src/hotspot/share/utilities/globalDefinitions.hpp >> 1104 inline u2 build_u2_from( u1 c1, u1 c2 ) { >> >> Other than the build_u2_from(u1* p) overload a few lines later, there >> are no callers of this two-arg overload. So this one could be removed >> by inlining the implementation into the one-arg overload. >> >> Also, the comment describing these as building values using the >> conventions used in class files has been lost. >> >> But the best cleanup would be to also entirely remove build_u2_from() >> and change its callers to instead call Bytes::get_Java_u2(). There >> are 14 callers. Feel free to make that a separate cleanup RFE, if you >> want to avoid expanding the scope of this change. >> >> I note that you also removed this comment: >> 1131 // On the 386, this could be realized with a simple address cast. >> which is good, since that comment seems to be just plain wrong. >> >> ------------------------------------------------------------------------------ > From karen.kinnear at oracle.com Wed Jan 2 22:37:12 2019 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Wed, 2 Jan 2019 17:37:12 -0500 Subject: help with changes to hotspot runtime to implement sealed types In-Reply-To: <8e7dd496-d91f-c0b1-2d17-37e719e93388@oracle.com> References: <8e7dd496-d91f-c0b1-2d17-37e719e93388@oracle.com> Message-ID: Vicente, Just catching up. Had missed the evolution of sealed types. Is there anything written about any future plans for sealed types or does your description capture current and future plans? Is there a requirement that Sealed and Sub are loaded by the same class loader - that is implied by your comment about same package or module, but not currently a requirement for super/sub types in general. Will there be any connection with nestmates? Or any plans for dynamically extending sealed types? When you get to the point of clarifying the JVMS, can you also talk to us about JVMTI and restrictions for class redefinition/retransformation - I would start with a proposal that you can NOT change the new PermittedSubtypes attribute via redefinition. If that is too strong a restriction, disallow removing any existing attribute members and disallow adding the attribute if it does not currently exist. An implementation note - I do not see a change to oops/method.cpp in your diff below. If you look in Method::is_final_method today the result is ?true? if class_access_flags.is_final(). That logic will require changing since it will NOT be true if you have this PermittedSubtypes attribute. This could cause problems - e.g. we do not leave space in the vtable so method overriding would not work. I did not do a full search of all places in which we make assumptions based on class_access_flags.is_final(), but I would assume you would need to do that, e.g. opto/type.cpp - but I assume you are starting out -Xint, and will get the compiler team involved to remove any optimizations that aren?t pertinent anymore. thanks, Karen > On Dec 11, 2018, at 8:53 PM, Vicente Romero wrote: > > Hi HS runtime, > > I'm working on the implementation of sealed types one of the projects under the Amber umbrella. A sealed type is one that can only be subtyped by a set of classes declared by the sealed type in Java: > > final class Sealed permits Sub {} > class Sub extends Sealed {} > > Both Sealed and Sub can coexist in the same compilation unit, package or module. The class file for Sealed have an attribute named PermittedSubtypes that contains a list with the, well, permitted subtypes. In the case of the example it will be Sub only. On top of that class Sealed will be final. So when loading / parsing class file for Sub, we need to check, given that its supertype is final, if Sub is listed as one of the permitted subtypes of Sealed or fail in other case. And here is when I'm finding a roadblock. Currently the VM doesn't allow any class to subtype a final class and this is checked at: > > ClassFileParser::post_process_parsed_stream > > so I removed the code that was doing this check at `ClassFileParser` and created a separate method to do the checking at InstanceKlass with the idea of enforcing the check after the class file was parsed and the given class loaded. But regardless of my intents I always get a SOE. The SOE happens when the subclass ask the super class if the subclass is listed as one of its permitted subtypes. To answer this, the superclass tries to load the subclass so I have a deadlock that I suspect could be hard to solve, if possible. Please see attached what I have done so far. Any ideas? > > Thanks, > Vicente > > PD, the code runs with no error with the slowdebug configuration > From kim.barrett at oracle.com Thu Jan 3 07:59:37 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 3 Jan 2019 02:59:37 -0500 Subject: RFR 8215644: Clean up globalDefinitions_.hpp In-Reply-To: References: <4548bce5-681b-155a-1caa-91d449f31da1@oracle.com> <38CE2E51-C9AA-4452-AB32-8EF41B4C327F@oracle.com> Message-ID: <636999D2-6AB1-4605-8CF6-041217B77826@oracle.com> > On Jan 2, 2019, at 1:49 PM, Harold David Seigel wrote: > > Hi Kim, > > Thanks for looking at this. > > Please review this updated webrev: > > http://cr.openjdk.java.net/~hseigel/bug_8215644.2/webrev/index.html > > The only difference from the previous webrev is between lines 1100 - 1110 in the modified globalDefinitions.hpp file. The change includes removing the two-arg build_u2_from() function as suggested below. > > I also created a new RFE, JDK-8216010, to change the callers of build_u2_from() and remove it. The comments on lines 1103-6 are kind of broken, since there aren?t any four byte => 32-bit word functions here anymore. Of course, fixing JDK-8216010 will delete these comments anyway. So I?m not too worried about it if that new RFE is going to be fixed soon. Looks good. I don?t need a new webrev if you decide to fix the comment. From harold.seigel at oracle.com Thu Jan 3 13:30:30 2019 From: harold.seigel at oracle.com (Harold David Seigel) Date: Thu, 3 Jan 2019 08:30:30 -0500 Subject: RFR 8215644: Clean up globalDefinitions_.hpp In-Reply-To: <636999D2-6AB1-4605-8CF6-041217B77826@oracle.com> References: <4548bce5-681b-155a-1caa-91d449f31da1@oracle.com> <38CE2E51-C9AA-4452-AB32-8EF41B4C327F@oracle.com> <636999D2-6AB1-4605-8CF6-041217B77826@oracle.com> Message-ID: <85dc8d40-2e5b-5d4c-982d-5cb8445e1cce@oracle.com> Thanks Kim! I plan to clean up the comments as part of JDK-8216010. Harold On 1/3/2019 2:59 AM, Kim Barrett wrote: >> On Jan 2, 2019, at 1:49 PM, Harold David Seigel wrote: >> >> Hi Kim, >> >> Thanks for looking at this. >> >> Please review this updated webrev: >> >> http://cr.openjdk.java.net/~hseigel/bug_8215644.2/webrev/index.html >> >> The only difference from the previous webrev is between lines 1100 - 1110 in the modified globalDefinitions.hpp file. The change includes removing the two-arg build_u2_from() function as suggested below. >> >> I also created a new RFE, JDK-8216010, to change the callers of build_u2_from() and remove it. > The comments on lines 1103-6 are kind of broken, since there aren?t any four byte => 32-bit word > functions here anymore. Of course, fixing JDK-8216010 will delete these comments anyway. > So I?m not too worried about it if that new RFE is going to be fixed soon. > > Looks good. I don?t need a new webrev if you decide to fix the comment. > From calvin.cheung at oracle.com Thu Jan 3 18:13:09 2019 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Thu, 03 Jan 2019 10:13:09 -0800 Subject: [12] RFR(xs): 8215947: JVM crash with -XX:+DumpSharedSpaces Message-ID: <5C2E50B5.9070902@oracle.com> bug: https://bugs.openjdk.java.net/browse/JDK-8215947 webrev: http://cr.openjdk.java.net/~ccheung/8215947/webrev.00/ The bug was filed as confidential, the crash is as follows: $ java -XX:+DumpSharedSpaces narrow_klass_base = 0x0000000800000000, narrow_klass_shift = 3 Allocated temporary class space: 1073741824 bytes at 0x00000008c0000000 Allocated shared space: 3221225472 bytes at 0x0000000800000000 Loading classes to share ... Loading classes to share: done. Rewriting and linking classes ... Rewriting and linking classes: done Number of classes 1229 instance classes = 1168 obj array classes = 53 type array classes = 8 Updating ConstMethods ... done. Removing unshareable information ... # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (instanceKlass.cpp:2288), pid=28024, tid=28031 # guarantee(_dep_context == DependencyContext::EMPTY) failed: must be # # JRE version: Java(TM) SE Runtime Environment (11.0.2+7) (build 11.0.2+7-LTS) # Java VM: Java HotSpot(TM) 64-Bit Server VM (11.0.2+7-LTS, mixed mode, tiered, compressed oops, g1 gc, linux-amd64) We currently disable JIT compilation in arguments.cpp if the user specifies -Xshare:dump. } else if (match_option(option, "-Xshare:dump")) { if (FLAG_SET_CMDLINE(bool, DumpSharedSpaces, true) != JVMFlag::SUCCESS) { return JNI_EINVAL; } set_mode_flags(_int); // Prevent compilation, which creates objects The proper way to create a shared archive is by specifying -Xshare:dump instead of -XX:+DumpSharedSpaces. This fix is to disable compilation if DumpSharedSpaces is specified in Arguments::finalize_vm_init_args(). Testing: ran mach5 hs-tier{1,2,3} tests. thanks, Calvin From lois.foltan at oracle.com Thu Jan 3 18:17:20 2019 From: lois.foltan at oracle.com (Lois Foltan) Date: Thu, 3 Jan 2019 13:17:20 -0500 Subject: [12] RFR(xs): 8215947: JVM crash with -XX:+DumpSharedSpaces In-Reply-To: <5C2E50B5.9070902@oracle.com> References: <5C2E50B5.9070902@oracle.com> Message-ID: <06ea5b7a-0242-e9a7-7eef-5f6e6ad6340c@oracle.com> Looks good Calvin! Lois On 1/3/2019 1:13 PM, Calvin Cheung wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8215947 > > webrev: http://cr.openjdk.java.net/~ccheung/8215947/webrev.00/ > > The bug was filed as confidential, the crash is as follows: > > $ java -XX:+DumpSharedSpaces > narrow_klass_base = 0x0000000800000000, narrow_klass_shift = 3 > Allocated temporary class space: 1073741824 bytes at 0x00000008c0000000 > Allocated shared space: 3221225472 bytes at 0x0000000800000000 > Loading classes to share ... > Loading classes to share: done. > Rewriting and linking classes ... > Rewriting and linking classes: done > Number of classes 1229 > ??? instance classes = 1168 > ??? obj array classes = 53 > ??? type array classes = 8 > Updating ConstMethods ... done. > Removing unshareable information ... # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (instanceKlass.cpp:2288), pid=28024, tid=28031 > # guarantee(_dep_context == DependencyContext::EMPTY) failed: must be > # > # JRE version: Java(TM) SE Runtime Environment (11.0.2+7) (build > 11.0.2+7-LTS) > # Java VM: Java HotSpot(TM) 64-Bit Server VM (11.0.2+7-LTS, mixed mode, > tiered, compressed oops, g1 gc, linux-amd64) > > We currently disable JIT compilation in arguments.cpp if the user > specifies -Xshare:dump. > ??? } else if (match_option(option, "-Xshare:dump")) { > ????? if (FLAG_SET_CMDLINE(bool, DumpSharedSpaces, true) != > JVMFlag::SUCCESS) { > ??????? return JNI_EINVAL; > ????? } > ????? set_mode_flags(_int); // Prevent compilation, which creates objects > > The proper way to create a shared archive is by specifying > -Xshare:dump instead of -XX:+DumpSharedSpaces. > This fix is to disable compilation if DumpSharedSpaces is specified in > Arguments::finalize_vm_init_args(). > > Testing: ran mach5 hs-tier{1,2,3} tests. > > thanks, > Calvin From calvin.cheung at oracle.com Thu Jan 3 18:56:06 2019 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Thu, 03 Jan 2019 10:56:06 -0800 Subject: [12] RFR(xs): 8215947: JVM crash with -XX:+DumpSharedSpaces In-Reply-To: <06ea5b7a-0242-e9a7-7eef-5f6e6ad6340c@oracle.com> References: <5C2E50B5.9070902@oracle.com> <06ea5b7a-0242-e9a7-7eef-5f6e6ad6340c@oracle.com> Message-ID: <5C2E5AC6.2090701@oracle.com> Lois, Thanks for your quick review! Calvin On 1/3/19, 10:17 AM, Lois Foltan wrote: > Looks good Calvin! > > Lois > > On 1/3/2019 1:13 PM, Calvin Cheung wrote: >> bug: https://bugs.openjdk.java.net/browse/JDK-8215947 >> >> webrev: http://cr.openjdk.java.net/~ccheung/8215947/webrev.00/ >> >> The bug was filed as confidential, the crash is as follows: >> >> $ java -XX:+DumpSharedSpaces >> narrow_klass_base = 0x0000000800000000, narrow_klass_shift = 3 >> Allocated temporary class space: 1073741824 bytes at 0x00000008c0000000 >> Allocated shared space: 3221225472 bytes at 0x0000000800000000 >> Loading classes to share ... >> Loading classes to share: done. >> Rewriting and linking classes ... >> Rewriting and linking classes: done >> Number of classes 1229 >> instance classes = 1168 >> obj array classes = 53 >> type array classes = 8 >> Updating ConstMethods ... done. >> Removing unshareable information ... # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # Internal Error (instanceKlass.cpp:2288), pid=28024, tid=28031 >> # guarantee(_dep_context == DependencyContext::EMPTY) failed: must be >> # >> # JRE version: Java(TM) SE Runtime Environment (11.0.2+7) (build >> 11.0.2+7-LTS) >> # Java VM: Java HotSpot(TM) 64-Bit Server VM (11.0.2+7-LTS, mixed mode, >> tiered, compressed oops, g1 gc, linux-amd64) >> >> We currently disable JIT compilation in arguments.cpp if the user >> specifies -Xshare:dump. >> } else if (match_option(option, "-Xshare:dump")) { >> if (FLAG_SET_CMDLINE(bool, DumpSharedSpaces, true) != >> JVMFlag::SUCCESS) { >> return JNI_EINVAL; >> } >> set_mode_flags(_int); // Prevent compilation, which creates >> objects >> >> The proper way to create a shared archive is by specifying >> -Xshare:dump instead of -XX:+DumpSharedSpaces. >> This fix is to disable compilation if DumpSharedSpaces is specified >> in Arguments::finalize_vm_init_args(). >> >> Testing: ran mach5 hs-tier{1,2,3} tests. >> >> thanks, >> Calvin From karen.kinnear at oracle.com Thu Jan 3 19:04:13 2019 From: karen.kinnear at oracle.com (Karen Kinnear) Date: Thu, 3 Jan 2019 14:04:13 -0500 Subject: help with changes to hotspot runtime to implement sealed types In-Reply-To: <0e4c5e4a-f7e7-7a30-09d7-3cbf552ba9db@oracle.com> References: <8e7dd496-d91f-c0b1-2d17-37e719e93388@oracle.com> <0e4c5e4a-f7e7-7a30-09d7-3cbf552ba9db@oracle.com> Message-ID: <50D562FA-4FFE-4D48-9C8D-1F4AB3C41703@oracle.com> Thanks Vicente, Let us know if you need any more runtime or compiler assistance. thanks, Karen > On Jan 3, 2019, at 2:02 PM, Vicente Romero wrote: > > Hi Karen, > > On 1/2/19 5:37 PM, Karen Kinnear wrote: >> Vicente, >> >> Just catching up. Had missed the evolution of sealed types. Is there anything written about any future >> plans for sealed types or does your description capture current and future plans? > > my initial implementation has just trying to capture the current description which is still under development. So this is a prototype for users to start playing with the concept. > >> Is there a requirement >> that Sealed and Sub are loaded by the same class loader - that is implied by your comment about same package or module, but not currently a requirement for super/sub types in general. > > the assumption is that they should share the same class loader, I will take a look at enforcing this. > >> Will there be any >> connection with nestmates? > > this is an open option so a sealed type could allow its nestmates to extend it without having to enumerate all of them > >> Or any plans for dynamically extending sealed types? > > the current proposal is that the compiler most know all the subtypes in advance and they should be explicitly enumerated > >> >> When you get to the point of clarifying the JVMS, can you also talk to us about JVMTI >> and restrictions for class redefinition/retransformation - I would start with a proposal that you >> can NOT change the new PermittedSubtypes attribute via redefinition. If that is too strong a restriction, > > sounds like a sensible restriction > >> disallow removing any existing attribute members and disallow adding the attribute if it does not >> currently exist. >> >> An implementation note - I do not see a change to oops/method.cpp in your diff below. >> If you look in Method::is_final_method today the result is ?true? if class_access_flags.is_final(). >> That logic will require changing since it will NOT be true if you have this PermittedSubtypes attribute. >> This could cause problems - e.g. we do not leave space in the vtable so method overriding would not work. > thanks I will take a look at this >> >> I did not do a full search of all places in which we make assumptions based on class_access_flags.is_final(), >> but I would assume you would need to do that, e.g. opto/type.cpp > > I will search for all uses > >> - but I assume you are starting out -Xint, >> and will get the compiler team involved to remove any optimizations that aren?t pertinent anymore. >> >> thanks, >> Karen > > Thanks, > Vicente >> >>> On Dec 11, 2018, at 8:53 PM, Vicente Romero wrote: >>> >>> Hi HS runtime, >>> >>> I'm working on the implementation of sealed types one of the projects under the Amber umbrella. A sealed type is one that can only be subtyped by a set of classes declared by the sealed type in Java: >>> >>> final class Sealed permits Sub {} >>> class Sub extends Sealed {} >>> >>> Both Sealed and Sub can coexist in the same compilation unit, package or module. The class file for Sealed have an attribute named PermittedSubtypes that contains a list with the, well, permitted subtypes. In the case of the example it will be Sub only. On top of that class Sealed will be final. So when loading / parsing class file for Sub, we need to check, given that its supertype is final, if Sub is listed as one of the permitted subtypes of Sealed or fail in other case. And here is when I'm finding a roadblock. Currently the VM doesn't allow any class to subtype a final class and this is checked at: >>> >>> ClassFileParser::post_process_parsed_stream >>> >>> so I removed the code that was doing this check at `ClassFileParser` and created a separate method to do the checking at InstanceKlass with the idea of enforcing the check after the class file was parsed and the given class loaded. But regardless of my intents I always get a SOE. The SOE happens when the subclass ask the super class if the subclass is listed as one of its permitted subtypes. To answer this, the superclass tries to load the subclass so I have a deadlock that I suspect could be hard to solve, if possible. Please see attached what I have done so far. Any ideas? >>> >>> Thanks, >>> Vicente >>> >>> PD, the code runs with no error with the slowdebug configuration >>> > From vicente.romero at oracle.com Thu Jan 3 19:02:46 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 3 Jan 2019 14:02:46 -0500 Subject: help with changes to hotspot runtime to implement sealed types In-Reply-To: References: <8e7dd496-d91f-c0b1-2d17-37e719e93388@oracle.com> Message-ID: <0e4c5e4a-f7e7-7a30-09d7-3cbf552ba9db@oracle.com> Hi Karen, On 1/2/19 5:37 PM, Karen Kinnear wrote: > Vicente, > > Just catching up. Had missed the evolution of sealed types. Is there anything written about any future > plans for sealed types or does your description capture current and future plans? my initial implementation has just trying to capture the current description which is still under development. So this is a prototype for users to start playing with the concept. > Is there a requirement > that Sealed and Sub are loaded by the same class loader - that is implied by your comment about same package or module, but not currently a requirement for super/sub types in general. the assumption is that they should share the same class loader, I will take a look at enforcing this. > Will there be any > connection with nestmates? this is an open option so a sealed type could allow its nestmates to extend it without having to enumerate all of them > Or any plans for dynamically extending sealed types? the current proposal is that the compiler most know all the subtypes in advance and they should be explicitly enumerated > > When you get to the point of clarifying the JVMS, can you also talk to us about JVMTI > and restrictions for class redefinition/retransformation - I would start with a proposal that you > can NOT change the new PermittedSubtypes attribute via redefinition. If that is too strong a restriction, sounds like a sensible restriction > disallow removing any existing attribute members and disallow adding the attribute if it does not > currently exist. > > An implementation note - I do not see a change to oops/method.cpp in your diff below. > If you look in Method::is_final_method today the result is ?true? if class_access_flags.is_final(). > That logic will require changing since it will NOT be true if you have this PermittedSubtypes attribute. > This could cause problems - e.g. we do not leave space in the vtable so method overriding would not work. thanks I will take a look at this > > I did not do a full search of all places in which we make assumptions based on class_access_flags.is_final(), > but I would assume you would need to do that, e.g. opto/type.cpp I will search for all uses > - but I assume you are starting out -Xint, > and will get the compiler team involved to remove any optimizations that aren?t pertinent anymore. > > thanks, > Karen Thanks, Vicente > >> On Dec 11, 2018, at 8:53 PM, Vicente Romero wrote: >> >> Hi HS runtime, >> >> I'm working on the implementation of sealed types one of the projects under the Amber umbrella. A sealed type is one that can only be subtyped by a set of classes declared by the sealed type in Java: >> >> final class Sealed permits Sub {} >> class Sub extends Sealed {} >> >> Both Sealed and Sub can coexist in the same compilation unit, package or module. The class file for Sealed have an attribute named PermittedSubtypes that contains a list with the, well, permitted subtypes. In the case of the example it will be Sub only. On top of that class Sealed will be final. So when loading / parsing class file for Sub, we need to check, given that its supertype is final, if Sub is listed as one of the permitted subtypes of Sealed or fail in other case. And here is when I'm finding a roadblock. Currently the VM doesn't allow any class to subtype a final class and this is checked at: >> >> ClassFileParser::post_process_parsed_stream >> >> so I removed the code that was doing this check at `ClassFileParser` and created a separate method to do the checking at InstanceKlass with the idea of enforcing the check after the class file was parsed and the given class loaded. But regardless of my intents I always get a SOE. The SOE happens when the subclass ask the super class if the subclass is listed as one of its permitted subtypes. To answer this, the superclass tries to load the subclass so I have a deadlock that I suspect could be hard to solve, if possible. Please see attached what I have done so far. Any ideas? >> >> Thanks, >> Vicente >> >> PD, the code runs with no error with the slowdebug configuration >> From vicente.romero at oracle.com Thu Jan 3 19:20:36 2019 From: vicente.romero at oracle.com (Vicente Romero) Date: Thu, 3 Jan 2019 14:20:36 -0500 Subject: help with changes to hotspot runtime to implement sealed types In-Reply-To: <50D562FA-4FFE-4D48-9C8D-1F4AB3C41703@oracle.com> References: <8e7dd496-d91f-c0b1-2d17-37e719e93388@oracle.com> <0e4c5e4a-f7e7-7a30-09d7-3cbf552ba9db@oracle.com> <50D562FA-4FFE-4D48-9C8D-1F4AB3C41703@oracle.com> Message-ID: <0e9eb6bc-4584-3ce1-20b4-284f3c2e084d@oracle.com> sure, thanks for all the feedback and comments Vicente On 1/3/19 2:04 PM, Karen Kinnear wrote: > Thanks Vicente, > > Let us know if you need any more runtime or compiler assistance. > > thanks, > Karen > >> On Jan 3, 2019, at 2:02 PM, Vicente Romero wrote: >> >> Hi Karen, >> >> On 1/2/19 5:37 PM, Karen Kinnear wrote: >>> Vicente, >>> >>> Just catching up. Had missed the evolution of sealed types. Is there anything written about any future >>> plans for sealed types or does your description capture current and future plans? >> my initial implementation has just trying to capture the current description which is still under development. So this is a prototype for users to start playing with the concept. >> >>> Is there a requirement >>> that Sealed and Sub are loaded by the same class loader - that is implied by your comment about same package or module, but not currently a requirement for super/sub types in general. >> the assumption is that they should share the same class loader, I will take a look at enforcing this. >> >>> Will there be any >>> connection with nestmates? >> this is an open option so a sealed type could allow its nestmates to extend it without having to enumerate all of them >> >>> Or any plans for dynamically extending sealed types? >> the current proposal is that the compiler most know all the subtypes in advance and they should be explicitly enumerated >> >>> When you get to the point of clarifying the JVMS, can you also talk to us about JVMTI >>> and restrictions for class redefinition/retransformation - I would start with a proposal that you >>> can NOT change the new PermittedSubtypes attribute via redefinition. If that is too strong a restriction, >> sounds like a sensible restriction >> >>> disallow removing any existing attribute members and disallow adding the attribute if it does not >>> currently exist. >>> >>> An implementation note - I do not see a change to oops/method.cpp in your diff below. >>> If you look in Method::is_final_method today the result is ?true? if class_access_flags.is_final(). >>> That logic will require changing since it will NOT be true if you have this PermittedSubtypes attribute. >>> This could cause problems - e.g. we do not leave space in the vtable so method overriding would not work. >> thanks I will take a look at this >>> I did not do a full search of all places in which we make assumptions based on class_access_flags.is_final(), >>> but I would assume you would need to do that, e.g. opto/type.cpp >> I will search for all uses >> >>> - but I assume you are starting out -Xint, >>> and will get the compiler team involved to remove any optimizations that aren?t pertinent anymore. >>> >>> thanks, >>> Karen >> Thanks, >> Vicente >>>> On Dec 11, 2018, at 8:53 PM, Vicente Romero wrote: >>>> >>>> Hi HS runtime, >>>> >>>> I'm working on the implementation of sealed types one of the projects under the Amber umbrella. A sealed type is one that can only be subtyped by a set of classes declared by the sealed type in Java: >>>> >>>> final class Sealed permits Sub {} >>>> class Sub extends Sealed {} >>>> >>>> Both Sealed and Sub can coexist in the same compilation unit, package or module. The class file for Sealed have an attribute named PermittedSubtypes that contains a list with the, well, permitted subtypes. In the case of the example it will be Sub only. On top of that class Sealed will be final. So when loading / parsing class file for Sub, we need to check, given that its supertype is final, if Sub is listed as one of the permitted subtypes of Sealed or fail in other case. And here is when I'm finding a roadblock. Currently the VM doesn't allow any class to subtype a final class and this is checked at: >>>> >>>> ClassFileParser::post_process_parsed_stream >>>> >>>> so I removed the code that was doing this check at `ClassFileParser` and created a separate method to do the checking at InstanceKlass with the idea of enforcing the check after the class file was parsed and the given class loaded. But regardless of my intents I always get a SOE. The SOE happens when the subclass ask the super class if the subclass is listed as one of its permitted subtypes. To answer this, the superclass tries to load the subclass so I have a deadlock that I suspect could be hard to solve, if possible. Please see attached what I have done so far. Any ideas? >>>> >>>> Thanks, >>>> Vicente >>>> >>>> PD, the code runs with no error with the slowdebug configuration >>>> From jiangli.zhou at oracle.com Thu Jan 3 19:40:41 2019 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Thu, 3 Jan 2019 11:40:41 -0800 Subject: [12] RFR(xs): 8215947: JVM crash with -XX:+DumpSharedSpaces In-Reply-To: <5C2E50B5.9070902@oracle.com> References: <5C2E50B5.9070902@oracle.com> Message-ID: <24863643-5c66-6e40-7a08-78c9f06b93ca@oracle.com> Hi Calvin, This looks ok as a short-term fix. We should also investigate the issue at dump time when -XX:-UseCompiler is not specified. The 'assert(_dep_context == DependencyContext::EMPTY...' was done before we changed to allow java code execution at dump time. I just did a quick test to remove the assert and also set _dep_context to DependencyContext::EMPTY in InstanceKlass::remove_unshareable_info(). That allowed dumping to finish without any failure (with? -XX:+DumpSharedSpaces and no -XX:-UseCompiler). Could you please file a follow up RFE? Thanks, Jiangli On 1/3/19 10:13 AM, Calvin Cheung wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8215947 > > webrev: http://cr.openjdk.java.net/~ccheung/8215947/webrev.00/ > > The bug was filed as confidential, the crash is as follows: > > $ java -XX:+DumpSharedSpaces > narrow_klass_base = 0x0000000800000000, narrow_klass_shift = 3 > Allocated temporary class space: 1073741824 bytes at 0x00000008c0000000 > Allocated shared space: 3221225472 bytes at 0x0000000800000000 > Loading classes to share ... > Loading classes to share: done. > Rewriting and linking classes ... > Rewriting and linking classes: done > Number of classes 1229 > ??? instance classes = 1168 > ??? obj array classes = 53 > ??? type array classes = 8 > Updating ConstMethods ... done. > Removing unshareable information ... # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (instanceKlass.cpp:2288), pid=28024, tid=28031 > # guarantee(_dep_context == DependencyContext::EMPTY) failed: must be > # > # JRE version: Java(TM) SE Runtime Environment (11.0.2+7) (build > 11.0.2+7-LTS) > # Java VM: Java HotSpot(TM) 64-Bit Server VM (11.0.2+7-LTS, mixed mode, > tiered, compressed oops, g1 gc, linux-amd64) > > We currently disable JIT compilation in arguments.cpp if the user > specifies -Xshare:dump. > ??? } else if (match_option(option, "-Xshare:dump")) { > ????? if (FLAG_SET_CMDLINE(bool, DumpSharedSpaces, true) != > JVMFlag::SUCCESS) { > ??????? return JNI_EINVAL; > ????? } > ????? set_mode_flags(_int); // Prevent compilation, which creates objects > > The proper way to create a shared archive is by specifying > -Xshare:dump instead of -XX:+DumpSharedSpaces. > This fix is to disable compilation if DumpSharedSpaces is specified in > Arguments::finalize_vm_init_args(). > > Testing: ran mach5 hs-tier{1,2,3} tests. > > thanks, > Calvin From calvin.cheung at oracle.com Thu Jan 3 20:34:36 2019 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Thu, 03 Jan 2019 12:34:36 -0800 Subject: [12] RFR(xs): 8215947: JVM crash with -XX:+DumpSharedSpaces In-Reply-To: <24863643-5c66-6e40-7a08-78c9f06b93ca@oracle.com> References: <5C2E50B5.9070902@oracle.com> <24863643-5c66-6e40-7a08-78c9f06b93ca@oracle.com> Message-ID: <5C2E71DC.3020808@oracle.com> Hi Jiangli, Thanks for your review and investigation. There already exists an RFE which was filed by you: https://bugs.openjdk.java.net/browse/JDK-8200451 I've linked this bug to the RFE. thanks, Calvin On 1/3/19, 11:40 AM, Jiangli Zhou wrote: > Hi Calvin, > > This looks ok as a short-term fix. We should also investigate the > issue at dump time when -XX:-UseCompiler is not specified. The > 'assert(_dep_context == DependencyContext::EMPTY...' was done before > we changed to allow java code execution at dump time. I just did a > quick test to remove the assert and also set _dep_context to > DependencyContext::EMPTY in InstanceKlass::remove_unshareable_info(). > That allowed dumping to finish without any failure (with > -XX:+DumpSharedSpaces and no -XX:-UseCompiler). Could you please file > a follow up RFE? > > Thanks, > > Jiangli > > > On 1/3/19 10:13 AM, Calvin Cheung wrote: >> bug: https://bugs.openjdk.java.net/browse/JDK-8215947 >> >> webrev: http://cr.openjdk.java.net/~ccheung/8215947/webrev.00/ >> >> The bug was filed as confidential, the crash is as follows: >> >> $ java -XX:+DumpSharedSpaces >> narrow_klass_base = 0x0000000800000000, narrow_klass_shift = 3 >> Allocated temporary class space: 1073741824 bytes at 0x00000008c0000000 >> Allocated shared space: 3221225472 bytes at 0x0000000800000000 >> Loading classes to share ... >> Loading classes to share: done. >> Rewriting and linking classes ... >> Rewriting and linking classes: done >> Number of classes 1229 >> instance classes = 1168 >> obj array classes = 53 >> type array classes = 8 >> Updating ConstMethods ... done. >> Removing unshareable information ... # >> # A fatal error has been detected by the Java Runtime Environment: >> # >> # Internal Error (instanceKlass.cpp:2288), pid=28024, tid=28031 >> # guarantee(_dep_context == DependencyContext::EMPTY) failed: must be >> # >> # JRE version: Java(TM) SE Runtime Environment (11.0.2+7) (build >> 11.0.2+7-LTS) >> # Java VM: Java HotSpot(TM) 64-Bit Server VM (11.0.2+7-LTS, mixed mode, >> tiered, compressed oops, g1 gc, linux-amd64) >> >> We currently disable JIT compilation in arguments.cpp if the user >> specifies -Xshare:dump. >> } else if (match_option(option, "-Xshare:dump")) { >> if (FLAG_SET_CMDLINE(bool, DumpSharedSpaces, true) != >> JVMFlag::SUCCESS) { >> return JNI_EINVAL; >> } >> set_mode_flags(_int); // Prevent compilation, which creates >> objects >> >> The proper way to create a shared archive is by specifying >> -Xshare:dump instead of -XX:+DumpSharedSpaces. >> This fix is to disable compilation if DumpSharedSpaces is specified >> in Arguments::finalize_vm_init_args(). >> >> Testing: ran mach5 hs-tier{1,2,3} tests. >> >> thanks, >> Calvin > From jiangli.zhou at oracle.com Thu Jan 3 21:41:57 2019 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Thu, 3 Jan 2019 13:41:57 -0800 Subject: [12] RFR(xs): 8215947: JVM crash with -XX:+DumpSharedSpaces In-Reply-To: <5C2E71DC.3020808@oracle.com> References: <5C2E50B5.9070902@oracle.com> <24863643-5c66-6e40-7a08-78c9f06b93ca@oracle.com> <5C2E71DC.3020808@oracle.com> Message-ID: <6feecaa0-7502-b4ea-fe76-092dd1f1a24f@oracle.com> On 1/3/19 12:34 PM, Calvin Cheung wrote: > Hi Jiangli, > > Thanks for your review and investigation. > > There already exists an RFE which was filed by you: > ??? https://bugs.openjdk.java.net/browse/JDK-8200451 > I've linked this bug to the RFE. Great! :) Thanks! Jiangli > > thanks, > Calvin > > On 1/3/19, 11:40 AM, Jiangli Zhou wrote: >> Hi Calvin, >> >> This looks ok as a short-term fix. We should also investigate the >> issue at dump time when -XX:-UseCompiler is not specified. The >> 'assert(_dep_context == DependencyContext::EMPTY...' was done before >> we changed to allow java code execution at dump time. I just did a >> quick test to remove the assert and also set _dep_context to >> DependencyContext::EMPTY in InstanceKlass::remove_unshareable_info(). >> That allowed dumping to finish without any failure (with? >> -XX:+DumpSharedSpaces and no -XX:-UseCompiler). Could you please file >> a follow up RFE? >> >> Thanks, >> >> Jiangli >> >> >> On 1/3/19 10:13 AM, Calvin Cheung wrote: >>> bug: https://bugs.openjdk.java.net/browse/JDK-8215947 >>> >>> webrev: http://cr.openjdk.java.net/~ccheung/8215947/webrev.00/ >>> >>> The bug was filed as confidential, the crash is as follows: >>> >>> $ java -XX:+DumpSharedSpaces >>> narrow_klass_base = 0x0000000800000000, narrow_klass_shift = 3 >>> Allocated temporary class space: 1073741824 bytes at 0x00000008c0000000 >>> Allocated shared space: 3221225472 bytes at 0x0000000800000000 >>> Loading classes to share ... >>> Loading classes to share: done. >>> Rewriting and linking classes ... >>> Rewriting and linking classes: done >>> Number of classes 1229 >>> ??? instance classes = 1168 >>> ??? obj array classes = 53 >>> ??? type array classes = 8 >>> Updating ConstMethods ... done. >>> Removing unshareable information ... # >>> # A fatal error has been detected by the Java Runtime Environment: >>> # >>> # Internal Error (instanceKlass.cpp:2288), pid=28024, tid=28031 >>> # guarantee(_dep_context == DependencyContext::EMPTY) failed: must be >>> # >>> # JRE version: Java(TM) SE Runtime Environment (11.0.2+7) (build >>> 11.0.2+7-LTS) >>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (11.0.2+7-LTS, mixed mode, >>> tiered, compressed oops, g1 gc, linux-amd64) >>> >>> We currently disable JIT compilation in arguments.cpp if the user >>> specifies -Xshare:dump. >>> ??? } else if (match_option(option, "-Xshare:dump")) { >>> ????? if (FLAG_SET_CMDLINE(bool, DumpSharedSpaces, true) != >>> JVMFlag::SUCCESS) { >>> ??????? return JNI_EINVAL; >>> ????? } >>> ????? set_mode_flags(_int); // Prevent compilation, which creates >>> objects >>> >>> The proper way to create a shared archive is by specifying >>> -Xshare:dump instead of -XX:+DumpSharedSpaces. >>> This fix is to disable compilation if DumpSharedSpaces is specified >>> in Arguments::finalize_vm_init_args(). >>> >>> Testing: ran mach5 hs-tier{1,2,3} tests. >>> >>> thanks, >>> Calvin >> From erik.osterlund at oracle.com Fri Jan 4 10:10:03 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Fri, 4 Jan 2019 11:10:03 +0100 Subject: RFR: 8215773: applications/kitchensink/Kitchensink.java crash with "assert(ZAddress::is_marked(addr)) failed: Should be marked" Message-ID: <6880f8c3-d4be-29f3-f537-c1edfb7fe519@oracle.com> Hi, During SystemDictionary::do_unloading(), JFR pokes around at the dead mirror oops that died due to class unloading. The mirror is loaded without AS_NO_KEEPALIVE, which makes ZGC load barriers a bit sad, because they dislike loading dead oops. The solution is to load these mirrors with AS_NO_KEEPALIVE decorators, indicating that it is okay for them to be dead as we are only peeking at them. This is fine to do during concurrent execution by the GC thread that is performing class unloading, and hence controls the GC cycle, making sure that the memory of the dead oops is not reclaimed until the accesses have safely finished. Bug: https://bugs.openjdk.java.net/browse/JDK-8215773 Webrev: http://cr.openjdk.java.net/~eosterlund/8215773/webrev.00/ Manually ran kitchensink 24 hours to make sure this doesn't happen again. And hs-tier1-6 on linux. Thanks, /Erik From claes.redestad at oracle.com Fri Jan 4 10:17:14 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 4 Jan 2019 11:17:14 +0100 Subject: RFR: 8216157: Enable inlining of java_lang_Class::is_primitive Message-ID: Hi, moving Class::is_primitive to javaClasses.inline.hpp turns out to be a micro-optimization on a number of operations, such as Array.newInstance (until the C2 intrinsic kicks in). As the method is quite trivial inlining seem to happen everywhere and still end up shrinking the VM size by a few bytes (linux-x64). Bug: https://bugs.openjdk.java.net/browse/JDK-8216157 Webrev: http://cr.openjdk.java.net/~redestad/8216157/open.00/ Testing: tier1-3 in-flight /Claes From erik.osterlund at oracle.com Fri Jan 4 10:53:11 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Fri, 4 Jan 2019 11:53:11 +0100 Subject: RFR: 8216157: Enable inlining of java_lang_Class::is_primitive In-Reply-To: References: Message-ID: <241a1048-057d-236e-2e7a-7ccf8e555e7b@oracle.com> +1 /Erik On 2019-01-04 11:17, Claes Redestad wrote: > Hi, > > moving Class::is_primitive to javaClasses.inline.hpp turns out to be a > micro-optimization on a number of operations, such as Array.newInstance > (until the C2 intrinsic kicks in). > > As the method is quite trivial inlining seem to happen everywhere and > still end up shrinking the VM size by a few bytes (linux-x64). > > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8216157 > Webrev: http://cr.openjdk.java.net/~redestad/8216157/open.00/ > > Testing: tier1-3 in-flight > > /Claes From coleen.phillimore at oracle.com Fri Jan 4 12:37:26 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 4 Jan 2019 07:37:26 -0500 Subject: RFR: 8215773: applications/kitchensink/Kitchensink.java crash with "assert(ZAddress::is_marked(addr)) failed: Should be marked" In-Reply-To: <6880f8c3-d4be-29f3-f537-c1edfb7fe519@oracle.com> References: <6880f8c3-d4be-29f3-f537-c1edfb7fe519@oracle.com> Message-ID: <4595f346-1661-f96f-eb0f-1240fde1910e@oracle.com> Hi Erik,? This is kind of creepy.? They use the dead mirror and call identity hash on it, which writes to the dead mirror. Are these functions called at a safepoint?? Maybe JFR could do something different here. Coleen On 1/4/19 5:10 AM, Erik ?sterlund wrote: > Hi, > > During SystemDictionary::do_unloading(), JFR pokes around at the dead > mirror oops that died due to class unloading. > The mirror is loaded without AS_NO_KEEPALIVE, which makes ZGC load > barriers a bit sad, because they dislike loading dead oops. > > The solution is to load these mirrors with AS_NO_KEEPALIVE decorators, > indicating that it is okay for them to be dead as we are only peeking > at them. This is fine to do during concurrent execution by the GC > thread that is performing class unloading, and hence controls the GC > cycle, making sure that the memory of the dead oops is not reclaimed > until the accesses have safely finished. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8215773 > > Webrev: > http://cr.openjdk.java.net/~eosterlund/8215773/webrev.00/ > > Manually ran kitchensink 24 hours to make sure this doesn't happen > again. And hs-tier1-6 on linux. > > Thanks, > /Erik From coleen.phillimore at oracle.com Fri Jan 4 12:44:01 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 4 Jan 2019 07:44:01 -0500 Subject: RFR: 8216157: Enable inlining of java_lang_Class::is_primitive In-Reply-To: <241a1048-057d-236e-2e7a-7ccf8e555e7b@oracle.com> References: <241a1048-057d-236e-2e7a-7ccf8e555e7b@oracle.com> Message-ID: +1 Coleen On 1/4/19 5:53 AM, Erik ?sterlund wrote: > +1 > > /Erik > > On 2019-01-04 11:17, Claes Redestad wrote: >> Hi, >> >> moving Class::is_primitive to javaClasses.inline.hpp turns out to be a >> micro-optimization on a number of operations, such as Array.newInstance >> (until the C2 intrinsic kicks in). >> >> As the method is quite trivial inlining seem to happen everywhere and >> still end up shrinking the VM size by a few bytes (linux-x64). >> >> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8216157 >> Webrev: http://cr.openjdk.java.net/~redestad/8216157/open.00/ >> >> Testing: tier1-3 in-flight >> >> /Claes > From coleen.phillimore at oracle.com Fri Jan 4 12:46:48 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 4 Jan 2019 07:46:48 -0500 Subject: RFR: 8215773: applications/kitchensink/Kitchensink.java crash with "assert(ZAddress::is_marked(addr)) failed: Should be marked" In-Reply-To: <4595f346-1661-f96f-eb0f-1240fde1910e@oracle.com> References: <6880f8c3-d4be-29f3-f537-c1edfb7fe519@oracle.com> <4595f346-1661-f96f-eb0f-1240fde1910e@oracle.com> Message-ID: <8bd21d5d-84ad-3ae9-04a5-208587731e98@oracle.com> On 1/4/19 7:37 AM, coleen.phillimore at oracle.com wrote: > > Hi Erik,? This is kind of creepy.? They use the dead mirror and call > identity hash on it, which writes to the dead mirror. > > Are these functions called at a safepoint?? Maybe JFR could do > something different here. > > Coleen > > > On 1/4/19 5:10 AM, Erik ?sterlund wrote: >> Hi, >> >> During SystemDictionary::do_unloading(), JFR pokes around at the dead >> mirror oops that died due to class unloading. >> The mirror is loaded without AS_NO_KEEPALIVE, which makes ZGC load >> barriers a bit sad, because they dislike loading dead oops. >> >> The solution is to load these mirrors with AS_NO_KEEPALIVE >> decorators, indicating that it is okay for them to be dead as we are >> only peeking at them. This is fine to do during concurrent execution >> by the GC thread that is performing class unloading, and hence >> controls the GC cycle, making sure that the memory of the dead oops >> is not reclaimed until the accesses have safely finished. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8215773 >> >> Webrev: >> http://cr.openjdk.java.net/~eosterlund/8215773/webrev.00/ >> >> Manually ran kitchensink 24 hours to make sure this doesn't happen >> again. And hs-tier1-6 on linux. >> >> Thanks, >> /Erik > From claes.redestad at oracle.com Fri Jan 4 12:51:20 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 4 Jan 2019 13:51:20 +0100 Subject: RFR: 8216157: Enable inlining of java_lang_Class::is_primitive In-Reply-To: References: <241a1048-057d-236e-2e7a-7ccf8e555e7b@oracle.com> Message-ID: <8bb076fe-d80c-1a79-fdfd-460c977d81fc@oracle.com> Erik, Coleen, thanks for reviewing! /Claes On 2019-01-04 13:44, coleen.phillimore at oracle.com wrote: > +1 > Coleen > > On 1/4/19 5:53 AM, Erik ?sterlund wrote: >> +1 >> >> /Erik >> >> On 2019-01-04 11:17, Claes Redestad wrote: >>> Hi, >>> >>> moving Class::is_primitive to javaClasses.inline.hpp turns out to be a >>> micro-optimization on a number of operations, such as Array.newInstance >>> (until the C2 intrinsic kicks in). >>> >>> As the method is quite trivial inlining seem to happen everywhere and >>> still end up shrinking the VM size by a few bytes (linux-x64). >>> >>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8216157 >>> Webrev: http://cr.openjdk.java.net/~redestad/8216157/open.00/ >>> >>> Testing: tier1-3 in-flight >>> >>> /Claes >> > From erik.osterlund at oracle.com Fri Jan 4 13:28:03 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Fri, 4 Jan 2019 14:28:03 +0100 Subject: RFR: 8215773: applications/kitchensink/Kitchensink.java crash with "assert(ZAddress::is_marked(addr)) failed: Should be marked" In-Reply-To: <4595f346-1661-f96f-eb0f-1240fde1910e@oracle.com> References: <6880f8c3-d4be-29f3-f537-c1edfb7fe519@oracle.com> <4595f346-1661-f96f-eb0f-1240fde1910e@oracle.com> Message-ID: <5014f7c9-607b-6f26-b7b8-12b52f98850f@oracle.com> Hi Coleen, On 2019-01-04 13:37, coleen.phillimore at oracle.com wrote: > > Hi Erik,? This is kind of creepy.? They use the dead mirror and call > identity hash on it, which writes to the dead mirror. Yup, that's right. This is equivalent to how during code cache unloading, possibly dead java.lang.invoke.CallSite objects are chased down, and their possibly dead CallSiteContext are queried so that we can write to its dependency context. It is creepy indeed, but is completely safe to do in the context it is done in, as the same thread performing the accesses, is the thread that will eventually free the memory of the dead objects. And in that incident, I did the same thing: use AS_NO_KEEPALIVE when peeking at the dead objects. > Are these functions called at a safepoint?? Maybe JFR could do > something different here. Yeah, they are called from safepoints with STW-unloading, and called by the ZDriver (the concurrent GC thread controlling the GC phases), during concurrent class unloading. Thanks, /Erik > Coleen > > > On 1/4/19 5:10 AM, Erik ?sterlund wrote: >> Hi, >> >> During SystemDictionary::do_unloading(), JFR pokes around at the dead >> mirror oops that died due to class unloading. >> The mirror is loaded without AS_NO_KEEPALIVE, which makes ZGC load >> barriers a bit sad, because they dislike loading dead oops. >> >> The solution is to load these mirrors with AS_NO_KEEPALIVE >> decorators, indicating that it is okay for them to be dead as we are >> only peeking at them. This is fine to do during concurrent execution >> by the GC thread that is performing class unloading, and hence >> controls the GC cycle, making sure that the memory of the dead oops >> is not reclaimed until the accesses have safely finished. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8215773 >> >> Webrev: >> http://cr.openjdk.java.net/~eosterlund/8215773/webrev.00/ >> >> Manually ran kitchensink 24 hours to make sure this doesn't happen >> again. And hs-tier1-6 on linux. >> >> Thanks, >> /Erik > From coleen.phillimore at oracle.com Fri Jan 4 14:16:35 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 4 Jan 2019 09:16:35 -0500 Subject: RFR: 8215773: applications/kitchensink/Kitchensink.java crash with "assert(ZAddress::is_marked(addr)) failed: Should be marked" In-Reply-To: <5014f7c9-607b-6f26-b7b8-12b52f98850f@oracle.com> References: <6880f8c3-d4be-29f3-f537-c1edfb7fe519@oracle.com> <4595f346-1661-f96f-eb0f-1240fde1910e@oracle.com> <5014f7c9-607b-6f26-b7b8-12b52f98850f@oracle.com> Message-ID: <225b65c8-316f-6dd5-25c1-fd3e9b6999cf@oracle.com> On 1/4/19 8:28 AM, Erik ?sterlund wrote: > Hi Coleen, > > On 2019-01-04 13:37, coleen.phillimore at oracle.com wrote: >> >> Hi Erik,? This is kind of creepy.? They use the dead mirror and call >> identity hash on it, which writes to the dead mirror. > > Yup, that's right. This is equivalent to how during code cache > unloading, possibly dead java.lang.invoke.CallSite objects are chased > down, and their possibly dead CallSiteContext are queried so that we > can write to its dependency context. It is creepy indeed, but is > completely safe to do in the context it is done in, as the same thread > performing the accesses, is the thread that will eventually free the > memory of the dead objects. And in that incident, I did the same > thing: use AS_NO_KEEPALIVE when peeking at the dead objects. > >> Are these functions called at a safepoint?? Maybe JFR could do >> something different here. > > Yeah, they are called from safepoints with STW-unloading, and called > by the ZDriver (the concurrent GC thread controlling the GC phases), > during concurrent class unloading. Ah, ok.? I was getting this mixed up with the cld_unloading_do() calls in jfr.? This is called by do_unloading. Looks strange but good.? This is for 12 right? Thanks, Coleen > > Thanks, > /Erik > >> Coleen >> >> >> On 1/4/19 5:10 AM, Erik ?sterlund wrote: >>> Hi, >>> >>> During SystemDictionary::do_unloading(), JFR pokes around at the >>> dead mirror oops that died due to class unloading. >>> The mirror is loaded without AS_NO_KEEPALIVE, which makes ZGC load >>> barriers a bit sad, because they dislike loading dead oops. >>> >>> The solution is to load these mirrors with AS_NO_KEEPALIVE >>> decorators, indicating that it is okay for them to be dead as we are >>> only peeking at them. This is fine to do during concurrent execution >>> by the GC thread that is performing class unloading, and hence >>> controls the GC cycle, making sure that the memory of the dead oops >>> is not reclaimed until the accesses have safely finished. >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8215773 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~eosterlund/8215773/webrev.00/ >>> >>> Manually ran kitchensink 24 hours to make sure this doesn't happen >>> again. And hs-tier1-6 on linux. >>> >>> Thanks, >>> /Erik >> > From erik.osterlund at oracle.com Fri Jan 4 14:24:22 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Fri, 4 Jan 2019 15:24:22 +0100 Subject: RFR: 8215773: applications/kitchensink/Kitchensink.java crash with "assert(ZAddress::is_marked(addr)) failed: Should be marked" In-Reply-To: <225b65c8-316f-6dd5-25c1-fd3e9b6999cf@oracle.com> References: <6880f8c3-d4be-29f3-f537-c1edfb7fe519@oracle.com> <4595f346-1661-f96f-eb0f-1240fde1910e@oracle.com> <5014f7c9-607b-6f26-b7b8-12b52f98850f@oracle.com> <225b65c8-316f-6dd5-25c1-fd3e9b6999cf@oracle.com> Message-ID: Hi Coleen, On 2019-01-04 15:16, coleen.phillimore at oracle.com wrote: > > > On 1/4/19 8:28 AM, Erik ?sterlund wrote: >> Hi Coleen, >> >> On 2019-01-04 13:37, coleen.phillimore at oracle.com wrote: >>> >>> Hi Erik,? This is kind of creepy.? They use the dead mirror and call >>> identity hash on it, which writes to the dead mirror. >> >> Yup, that's right. This is equivalent to how during code cache >> unloading, possibly dead java.lang.invoke.CallSite objects are chased >> down, and their possibly dead CallSiteContext are queried so that we >> can write to its dependency context. It is creepy indeed, but is >> completely safe to do in the context it is done in, as the same >> thread performing the accesses, is the thread that will eventually >> free the memory of the dead objects. And in that incident, I did the >> same thing: use AS_NO_KEEPALIVE when peeking at the dead objects. >> >>> Are these functions called at a safepoint?? Maybe JFR could do >>> something different here. >> >> Yeah, they are called from safepoints with STW-unloading, and called >> by the ZDriver (the concurrent GC thread controlling the GC phases), >> during concurrent class unloading. > > Ah, ok.? I was getting this mixed up with the cld_unloading_do() calls > in jfr.? This is called by do_unloading. > Looks strange but good. Thanks for the review! > This is for 12 right? Yup. Thanks, /Erik > Thanks, > Coleen >> >> Thanks, >> /Erik >> >>> Coleen >>> >>> >>> On 1/4/19 5:10 AM, Erik ?sterlund wrote: >>>> Hi, >>>> >>>> During SystemDictionary::do_unloading(), JFR pokes around at the >>>> dead mirror oops that died due to class unloading. >>>> The mirror is loaded without AS_NO_KEEPALIVE, which makes ZGC load >>>> barriers a bit sad, because they dislike loading dead oops. >>>> >>>> The solution is to load these mirrors with AS_NO_KEEPALIVE >>>> decorators, indicating that it is okay for them to be dead as we >>>> are only peeking at them. This is fine to do during concurrent >>>> execution by the GC thread that is performing class unloading, and >>>> hence controls the GC cycle, making sure that the memory of the >>>> dead oops is not reclaimed until the accesses have safely finished. >>>> >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8215773 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~eosterlund/8215773/webrev.00/ >>>> >>>> Manually ran kitchensink 24 hours to make sure this doesn't happen >>>> again. And hs-tier1-6 on linux. >>>> >>>> Thanks, >>>> /Erik >>> >> > From mikhailo.seledtsov at oracle.com Fri Jan 4 22:08:26 2019 From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov) Date: Fri, 04 Jan 2019 14:08:26 -0800 Subject: RFR(T): [12]: 8215583: Exclude runtime/handshake/HandshakeWalkSuspendExitTest.java Message-ID: <5C2FD95A.5080102@oracle.com> Please review this trivial change that excludes the unstable test until the underlying issue is addressed ( JDK-8214174 ) Changes is done in JDK 12 repository: (http://hg.openjdk.java.net/jdk/jdk12) JBS: https://bugs.openjdk.java.net/browse/JDK-8215583 Change: --- a/test/hotspot/jtreg/ProblemList.txt +++ b/test/hotspot/jtreg/ProblemList.txt @@ -1,5 +1,5 @@ # -# Copyright (c) 2016, 2018, Oracle and/or its affiliates. All rights reserved. +# Copyright (c) 2016, 2019, 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 @@ -85,6 +85,7 @@ runtime/appcds/javaldr/GCDuringDump.java 8208778 macosx-x64 runtime/appcds/jigsaw/classpathtests/EmptyClassInBootClassPath.java 8213299 generic-all runtime/CompressedOops/UseCompressedOops.java 8079353 generic-all +runtime/handshake/HandshakeWalkSuspendExitTest.java 8214174 generic-all runtime/RedefineTests/RedefineRunningMethods.java 8208778 macosx-x64 runtime/SharedArchiveFile/SASymbolTableTest.java 8193639 solaris-all Testing: 1. Locally: ran runtime/handshake/HandshakeWalkSuspendExitTest.java making sure it is excluded Thank you, Misha From igor.ignatyev at oracle.com Fri Jan 4 22:23:23 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 4 Jan 2019 14:23:23 -0800 Subject: RFR(T): [12]: 8215583: Exclude runtime/handshake/HandshakeWalkSuspendExitTest.java In-Reply-To: <5C2FD95A.5080102@oracle.com> References: <5C2FD95A.5080102@oracle.com> Message-ID: <4A3627A7-1959-450C-9807-A755B7C360D9@oracle.com> Hi Misha, looks good to me. -- Igor > On Jan 4, 2019, at 2:08 PM, Mikhailo Seledtsov wrote: > > Please review this trivial change that excludes the unstable test until the underlying issue is addressed ( JDK-8214174 ) > Changes is done in JDK 12 repository: (http://hg.openjdk.java.net/jdk/jdk12) > > JBS: https://bugs.openjdk.java.net/browse/JDK-8215583 > > Change: > --- a/test/hotspot/jtreg/ProblemList.txt > +++ b/test/hotspot/jtreg/ProblemList.txt > @@ -1,5 +1,5 @@ > # > -# Copyright (c) 2016, 2018, Oracle and/or its affiliates. All rights reserved. > +# Copyright (c) 2016, 2019, 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 > @@ -85,6 +85,7 @@ > runtime/appcds/javaldr/GCDuringDump.java 8208778 macosx-x64 > runtime/appcds/jigsaw/classpathtests/EmptyClassInBootClassPath.java 8213299 generic-all > runtime/CompressedOops/UseCompressedOops.java 8079353 generic-all > +runtime/handshake/HandshakeWalkSuspendExitTest.java 8214174 generic-all > runtime/RedefineTests/RedefineRunningMethods.java 8208778 macosx-x64 > runtime/SharedArchiveFile/SASymbolTableTest.java 8193639 solaris-all > > Testing: > 1. Locally: ran runtime/handshake/HandshakeWalkSuspendExitTest.java > making sure it is excluded > > > Thank you, > Misha From mikhailo.seledtsov at oracle.com Fri Jan 4 23:14:09 2019 From: mikhailo.seledtsov at oracle.com (Mikhailo Seledtsov) Date: Fri, 04 Jan 2019 15:14:09 -0800 Subject: RFR(T): [12]: 8215583: Exclude runtime/handshake/HandshakeWalkSuspendExitTest.java In-Reply-To: <4A3627A7-1959-450C-9807-A755B7C360D9@oracle.com> References: <5C2FD95A.5080102@oracle.com> <4A3627A7-1959-450C-9807-A755B7C360D9@oracle.com> Message-ID: <5C2FE8C1.4020505@oracle.com> Thank you, Misha On 1/4/19, 2:23 PM, Igor Ignatyev wrote: > Hi Misha, > > looks good to me. > > -- Igor > >> On Jan 4, 2019, at 2:08 PM, Mikhailo Seledtsov wrote: >> >> Please review this trivial change that excludes the unstable test until the underlying issue is addressed ( JDK-8214174) >> Changes is done in JDK 12 repository: (http://hg.openjdk.java.net/jdk/jdk12) >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8215583 >> >> Change: >> --- a/test/hotspot/jtreg/ProblemList.txt >> +++ b/test/hotspot/jtreg/ProblemList.txt >> @@ -1,5 +1,5 @@ >> # >> -# Copyright (c) 2016, 2018, Oracle and/or its affiliates. All rights reserved. >> +# Copyright (c) 2016, 2019, 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 >> @@ -85,6 +85,7 @@ >> runtime/appcds/javaldr/GCDuringDump.java 8208778 macosx-x64 >> runtime/appcds/jigsaw/classpathtests/EmptyClassInBootClassPath.java 8213299 generic-all >> runtime/CompressedOops/UseCompressedOops.java 8079353 generic-all >> +runtime/handshake/HandshakeWalkSuspendExitTest.java 8214174 generic-all >> runtime/RedefineTests/RedefineRunningMethods.java 8208778 macosx-x64 >> runtime/SharedArchiveFile/SASymbolTableTest.java 8193639 solaris-all >> >> Testing: >> 1. Locally: ran runtime/handshake/HandshakeWalkSuspendExitTest.java >> making sure it is excluded >> >> >> Thank you, >> Misha From calvin.cheung at oracle.com Sat Jan 5 01:04:27 2019 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Fri, 04 Jan 2019 17:04:27 -0800 Subject: RFR(trivial) 8213002: Remove the IgnoreUnverifiableClassesDuringDump vm option Message-ID: <5C30029B.2090807@oracle.com> bug: https://bugs.openjdk.java.net/browse/JDK-8213002 webrev: http://cr.openjdk.java.net/~ccheung/8213002/webrev.00/ The IgnoreUnverifiableClassesDuringDump option will be obsoleted in JDK12. This change is for removing it in JDK13. Testing: hs-tier{1,2} (in progress). thanks, Calvin From ioi.lam at oracle.com Sat Jan 5 01:07:55 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Fri, 4 Jan 2019 17:07:55 -0800 Subject: RFR(trivial) 8213002: Remove the IgnoreUnverifiableClassesDuringDump vm option In-Reply-To: <5C30029B.2090807@oracle.com> References: <5C30029B.2090807@oracle.com> Message-ID: <8ce9a51e-af1a-179b-8dd6-2ca55ef6c698@oracle.com> Looks good and trivial. Thanks - Ioi On 1/4/19 5:04 PM, Calvin Cheung wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8213002 > > webrev: http://cr.openjdk.java.net/~ccheung/8213002/webrev.00/ > > The IgnoreUnverifiableClassesDuringDump option will be obsoleted in > JDK12. This change is for removing it in JDK13. > > Testing: hs-tier{1,2} (in progress). > > thanks, > Calvin From calvin.cheung at oracle.com Sat Jan 5 01:33:31 2019 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Fri, 04 Jan 2019 17:33:31 -0800 Subject: RFR(trivial) 8213002: Remove the IgnoreUnverifiableClassesDuringDump vm option In-Reply-To: <8ce9a51e-af1a-179b-8dd6-2ca55ef6c698@oracle.com> References: <5C30029B.2090807@oracle.com> <8ce9a51e-af1a-179b-8dd6-2ca55ef6c698@oracle.com> Message-ID: <5C30096B.7090409@oracle.com> Thanks Ioi. On 1/4/19, 5:07 PM, Ioi Lam wrote: > Looks good and trivial. > > Thanks > > - Ioi > > On 1/4/19 5:04 PM, Calvin Cheung wrote: >> bug: https://bugs.openjdk.java.net/browse/JDK-8213002 >> >> webrev: http://cr.openjdk.java.net/~ccheung/8213002/webrev.00/ >> >> The IgnoreUnverifiableClassesDuringDump option will be obsoleted in >> JDK12. This change is for removing it in JDK13. >> >> Testing: hs-tier{1,2} (in progress). >> >> thanks, >> Calvin From david.holmes at oracle.com Sat Jan 5 01:58:07 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 5 Jan 2019 11:58:07 +1000 Subject: RFR(trivial) 8213002: Remove the IgnoreUnverifiableClassesDuringDump vm option In-Reply-To: <5C30029B.2090807@oracle.com> References: <5C30029B.2090807@oracle.com> Message-ID: <2da44e1b-9f89-ba71-ae64-6fcbd530e5db@oracle.com> Looks fine but really we should just have one bug that expires all the obsolete flags that are set of expire in JDK 13. That involves just deleting their entries from the table. That bug may already exist ... (sorry can't check right now). Cheers, David On 5/01/2019 11:04 am, Calvin Cheung wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8213002 > > webrev: http://cr.openjdk.java.net/~ccheung/8213002/webrev.00/ > > The IgnoreUnverifiableClassesDuringDump option will be obsoleted in > JDK12. This change is for removing it in JDK13. > > Testing: hs-tier{1,2} (in progress). > > thanks, > Calvin From david.holmes at oracle.com Sat Jan 5 05:16:55 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 5 Jan 2019 15:16:55 +1000 Subject: RFR(trivial) 8213002: Remove the IgnoreUnverifiableClassesDuringDump vm option In-Reply-To: <2da44e1b-9f89-ba71-ae64-6fcbd530e5db@oracle.com> References: <5C30029B.2090807@oracle.com> <2da44e1b-9f89-ba71-ae64-6fcbd530e5db@oracle.com> Message-ID: On 5/01/2019 11:58 am, David Holmes wrote: > Looks fine but really we should just have one bug that expires all the > obsolete flags that are set of expire in JDK 13. That involves just > deleting their entries from the table. > > That bug may already exist ... (sorry can't check right now). Filed JDK-8216188. Testing it now. David > Cheers, > David > > On 5/01/2019 11:04 am, Calvin Cheung wrote: >> bug: https://bugs.openjdk.java.net/browse/JDK-8213002 >> >> webrev: http://cr.openjdk.java.net/~ccheung/8213002/webrev.00/ >> >> The IgnoreUnverifiableClassesDuringDump option will be obsoleted in >> JDK12. This change is for removing it in JDK13. >> >> Testing: hs-tier{1,2} (in progress). >> >> thanks, >> Calvin From claes.redestad at oracle.com Sat Jan 5 13:56:54 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Sat, 5 Jan 2019 14:56:54 +0100 Subject: RFR (trivial): 8216189: Remove Klass::compute_is_subtype_of Message-ID: Hi, Klass::compute_is_subtype_of appears to be effectively unused and could be removed. Bug: https://bugs.openjdk.java.net/browse/JDK-8216189 Webrev: http://cr.openjdk.java.net/~redestad/8216189/open.00/ Testing: tier1 /Claes From harold.seigel at oracle.com Sat Jan 5 14:31:20 2019 From: harold.seigel at oracle.com (Harold David Seigel) Date: Sat, 5 Jan 2019 09:31:20 -0500 Subject: RFR (trivial): 8216189: Remove Klass::compute_is_subtype_of In-Reply-To: References: Message-ID: <81243acd-594a-65e0-6fe3-2f18f8aebdef@oracle.com> Hi Claes, This looks good. Thanks, Harold On 1/5/2019 8:56 AM, Claes Redestad wrote: > Hi, > > Klass::compute_is_subtype_of appears to be effectively unused > and could be removed. > > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8216189 > Webrev: http://cr.openjdk.java.net/~redestad/8216189/open.00/ > > Testing: tier1 > > /Claes From claes.redestad at oracle.com Sat Jan 5 15:10:58 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Sat, 5 Jan 2019 16:10:58 +0100 Subject: RFR (trivial): 8216189: Remove Klass::compute_is_subtype_of In-Reply-To: <81243acd-594a-65e0-6fe3-2f18f8aebdef@oracle.com> References: <81243acd-594a-65e0-6fe3-2f18f8aebdef@oracle.com> Message-ID: <37f4aadf-fdb4-30c8-013a-c7d264a7ae43@oracle.com> Thanks, Harold! /Claes On 2019-01-05 15:31, Harold David Seigel wrote: > Hi Claes, > > This looks good. > > Thanks, Harold > > On 1/5/2019 8:56 AM, Claes Redestad wrote: >> Hi, >> >> Klass::compute_is_subtype_of appears to be effectively unused >> and could be removed. >> >> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8216189 >> Webrev: http://cr.openjdk.java.net/~redestad/8216189/open.00/ >> >> Testing: tier1 >> >> /Claes From claes.redestad at oracle.com Sat Jan 5 15:24:00 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Sat, 5 Jan 2019 16:24:00 +0100 Subject: RFR: 8216191: Remove FastSuperclassLimit Message-ID: Hi, the develop flag FastSuperclassLimit appears unused and not covered/used by any tests. I propose removing it. Bug: https://bugs.openjdk.java.net/browse/JDK-8216191 Webrev: http://cr.openjdk.java.net/~redestad/8216191/open.00/ Thanks! /Claes From coleen.phillimore at oracle.com Sat Jan 5 18:04:05 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Sat, 5 Jan 2019 13:04:05 -0500 Subject: RFR: 8216191: Remove FastSuperclassLimit In-Reply-To: References: Message-ID: <08fcf2a0-0319-386f-af3c-8f8ec6827982@oracle.com> Looks trivially good to me. Coleen On 1/5/19 10:24 AM, Claes Redestad wrote: > Hi, > > the develop flag FastSuperclassLimit appears unused and not covered/used > by any tests. I propose removing it. > > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8216191 > Webrev: http://cr.openjdk.java.net/~redestad/8216191/open.00/ > > Thanks! > > /Claes From jiangli.zhou at oracle.com Sat Jan 5 18:15:46 2019 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Sat, 5 Jan 2019 10:15:46 -0800 Subject: RFR (trivial): 8216189: Remove Klass::compute_is_subtype_of In-Reply-To: <81243acd-594a-65e0-6fe3-2f18f8aebdef@oracle.com> References: <81243acd-594a-65e0-6fe3-2f18f8aebdef@oracle.com> Message-ID: <64078507-6F50-46C4-AA37-FDFA7994E27B@oracle.com> +1 Thanks, Jiangli > On Jan 5, 2019, at 6:31 AM, Harold David Seigel wrote: > > Hi Claes, > > This looks good. > > Thanks, Harold > >> On 1/5/2019 8:56 AM, Claes Redestad wrote: >> Hi, >> >> Klass::compute_is_subtype_of appears to be effectively unused >> and could be removed. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8216189 >> Webrev: http://cr.openjdk.java.net/~redestad/8216189/open.00/ >> >> Testing: tier1 >> >> /Claes From claes.redestad at oracle.com Sat Jan 5 18:32:00 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Sat, 5 Jan 2019 19:32:00 +0100 Subject: RFR (trivial): 8216189: Remove Klass::compute_is_subtype_of In-Reply-To: <64078507-6F50-46C4-AA37-FDFA7994E27B@oracle.com> References: <81243acd-594a-65e0-6fe3-2f18f8aebdef@oracle.com> <64078507-6F50-46C4-AA37-FDFA7994E27B@oracle.com> Message-ID: <645b0997-7109-dffe-53f8-2a345e8c428a@oracle.com> Thanks, Jiangli! /Claes On 2019-01-05 19:15, Jiangli Zhou wrote: > +1 > > Thanks, > Jiangli > >> On Jan 5, 2019, at 6:31 AM, Harold David Seigel wrote: >> >> Hi Claes, >> >> This looks good. >> >> Thanks, Harold >> >>> On 1/5/2019 8:56 AM, Claes Redestad wrote: >>> Hi, >>> >>> Klass::compute_is_subtype_of appears to be effectively unused >>> and could be removed. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8216189 >>> Webrev: http://cr.openjdk.java.net/~redestad/8216189/open.00/ >>> >>> Testing: tier1 >>> >>> /Claes > From claes.redestad at oracle.com Sat Jan 5 18:32:13 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Sat, 5 Jan 2019 19:32:13 +0100 Subject: RFR: 8216191: Remove FastSuperclassLimit In-Reply-To: <08fcf2a0-0319-386f-af3c-8f8ec6827982@oracle.com> References: <08fcf2a0-0319-386f-af3c-8f8ec6827982@oracle.com> Message-ID: <10e8ae05-24a7-7150-94b3-34212a43f92a@oracle.com> Thanks, Coleen! /Claes On 2019-01-05 19:04, coleen.phillimore at oracle.com wrote: > Looks trivially good to me. > Coleen > > On 1/5/19 10:24 AM, Claes Redestad wrote: >> Hi, >> >> the develop flag FastSuperclassLimit appears unused and not covered/used >> by any tests. I propose removing it. >> >> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8216191 >> Webrev: http://cr.openjdk.java.net/~redestad/8216191/open.00/ >> >> Thanks! >> >> /Claes > From claes.redestad at oracle.com Sun Jan 6 22:20:31 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Sun, 6 Jan 2019 23:20:31 +0100 Subject: RFR (trivial): 8216197: Remove unused new_hash methods Message-ID: Hi, another trivial(?) cleanup. Webrev: http://cr.openjdk.java.net/~redestad/8216197/open.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8216197 Thanks! /Claes From kim.barrett at oracle.com Sun Jan 6 22:49:52 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 6 Jan 2019 17:49:52 -0500 Subject: RFR (trivial): 8216197: Remove unused new_hash methods In-Reply-To: References: Message-ID: <87D8D135-118C-44F8-A970-94F6586D7B94@oracle.com> > On Jan 6, 2019, at 5:20 PM, Claes Redestad wrote: > > Hi, > > another trivial(?) cleanup. > > Webrev: http://cr.openjdk.java.net/~redestad/8216197/open.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8216197 > > Thanks! > > /Claes Looks good, and trivial. From david.holmes at oracle.com Sun Jan 6 23:32:52 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 7 Jan 2019 09:32:52 +1000 Subject: RFR (trivial): 8216197: Remove unused new_hash methods In-Reply-To: References: Message-ID: <31cac36d-bb7c-786e-deb5-fd7873e85228@oracle.com> Looks good. Thanks, David On 7/01/2019 8:20 am, Claes Redestad wrote: > Hi, > > another trivial(?) cleanup. > > Webrev: http://cr.openjdk.java.net/~redestad/8216197/open.00/ > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8216197 > > Thanks! > > /Claes From yumin.qi at gmail.com Mon Jan 7 07:11:36 2019 From: yumin.qi at gmail.com (yumin qi) Date: Mon, 7 Jan 2019 15:11:36 +0800 Subject: RFR(M) 8192921 Improve CDS support for custom loaders In-Reply-To: <4a897215-4577-c46b-f459-c02354d56f5d@oracle.com> References: <4a897215-4577-c46b-f459-c02354d56f5d@oracle.com> Message-ID: Hi, Ioi Thanks for fixing the custom loader issue in CDS. It looks good! Only a few minor suggestions. 1) classListParser.cpp: } else if (parse_int_option("super:", &_super)) {- check_already_loaded("Super class", _super);- continue;+ } According to current design, DumpLoadedClassList will output java/lang/Object id : 1 .... So except for Object, every other class will have "super : " There is no checking for return false. If format damages leads to fail to parse the value, should we do something here? 2) systemDictionaryShared.cpp: bool SystemDictionaryShared::check_hierarchy(...): Klass* k = resolve_super_or_fail(ik->name(), expected_intf->name(), class_loader, protection_domain, false, CHECK_NULL); Since the function return bool, I think here should be CHECK_false, that is, with Exception, it returns false. 3) TestCommon.java: + static byte[] asciibytes(String s) {+ byte b[] = new byte[s.length()];+ for (int i=0; i wrote: > > http://cr.openjdk.java.net/~iklam/jdk13/8192921-cds-cust-loader-improve.v01/ > https://bugs.openjdk.java.net/browse/JDK-8192921 > > > ISSUE: > > In JDK 12, there's experimental support for custom loader in CDS. > However, there are limitations: > > 1. if two or more custom loaders want to load a class named "A", only > one of those loaders can actually succeed in loading an archived > class. > > 2. the classlist needs to be hand-crafted (or by a script that parses > the output of -Xlog:class+load=debug). > > FIX: > > 1. Now you can archive multiple classes of the same name. At run > time, we select an archived class that > (a) matches the fingerprint of the class file, and > (b) matches the class hierarchy of the current loader. > > (b) is the tricky part. See > SystemDictionaryShared::has_same_hierarchy_for_unregistered_class > > For a test case, see DuplicatedClassesTest.java > > 2. -XX:DumpLoadedClassList now automatically includes classes loaded > by custom loaders. The generated class list includes all the > necessary attributes for custom loader support, such as "super:", > "source:" and "interface:". > > I have tested with Eclipse IDE, which loads most of its classes with > custom loaders. I am planning to add more test cases. > > Thanks > - Ioi > > > From per.liden at oracle.com Mon Jan 7 08:14:27 2019 From: per.liden at oracle.com (Per Liden) Date: Mon, 7 Jan 2019 09:14:27 +0100 Subject: RFR: 8215773: applications/kitchensink/Kitchensink.java crash with "assert(ZAddress::is_marked(addr)) failed: Should be marked" In-Reply-To: <6880f8c3-d4be-29f3-f537-c1edfb7fe519@oracle.com> References: <6880f8c3-d4be-29f3-f537-c1edfb7fe519@oracle.com> Message-ID: <586100f4-5073-cf02-1ef7-69f09faf3feb@oracle.com> On 1/4/19 11:10 AM, Erik ?sterlund wrote: > Hi, > > During SystemDictionary::do_unloading(), JFR pokes around at the dead > mirror oops that died due to class unloading. > The mirror is loaded without AS_NO_KEEPALIVE, which makes ZGC load > barriers a bit sad, because they dislike loading dead oops. > > The solution is to load these mirrors with AS_NO_KEEPALIVE decorators, > indicating that it is okay for them to be dead as we are only peeking at > them. This is fine to do during concurrent execution by the GC thread > that is performing class unloading, and hence controls the GC cycle, > making sure that the memory of the dead oops is not reclaimed until the > accesses have safely finished. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8215773 > > Webrev: > http://cr.openjdk.java.net/~eosterlund/8215773/webrev.00/ Looks good. /Per > > Manually ran kitchensink 24 hours to make sure this doesn't happen > again. And hs-tier1-6 on linux. > > Thanks, > /Erik From claes.redestad at oracle.com Mon Jan 7 08:25:35 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 7 Jan 2019 09:25:35 +0100 Subject: RFR (trivial): 8216197: Remove unused new_hash methods In-Reply-To: <87D8D135-118C-44F8-A970-94F6586D7B94@oracle.com> References: <87D8D135-118C-44F8-A970-94F6586D7B94@oracle.com> Message-ID: Kim, David, thanks for reviewing! /Claes On 2019-01-06 23:49, Kim Barrett wrote: >> On Jan 6, 2019, at 5:20 PM, Claes Redestad wrote: >> >> Hi, >> >> another trivial(?) cleanup. >> >> Webrev: http://cr.openjdk.java.net/~redestad/8216197/open.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8216197 >> >> Thanks! >> >> /Claes > > Looks good, and trivial. > From erik.osterlund at oracle.com Mon Jan 7 08:36:27 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Mon, 7 Jan 2019 09:36:27 +0100 Subject: RFR: 8215773: applications/kitchensink/Kitchensink.java crash with "assert(ZAddress::is_marked(addr)) failed: Should be marked" In-Reply-To: <586100f4-5073-cf02-1ef7-69f09faf3feb@oracle.com> References: <6880f8c3-d4be-29f3-f537-c1edfb7fe519@oracle.com> <586100f4-5073-cf02-1ef7-69f09faf3feb@oracle.com> Message-ID: Hi Per, Thanks for the review. /Erik On 2019-01-07 09:14, Per Liden wrote: > On 1/4/19 11:10 AM, Erik ?sterlund wrote: >> Hi, >> >> During SystemDictionary::do_unloading(), JFR pokes around at the dead >> mirror oops that died due to class unloading. >> The mirror is loaded without AS_NO_KEEPALIVE, which makes ZGC load >> barriers a bit sad, because they dislike loading dead oops. >> >> The solution is to load these mirrors with AS_NO_KEEPALIVE >> decorators, indicating that it is okay for them to be dead as we are >> only peeking at them. This is fine to do during concurrent execution >> by the GC thread that is performing class unloading, and hence >> controls the GC cycle, making sure that the memory of the dead oops >> is not reclaimed until the accesses have safely finished. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8215773 >> >> Webrev: >> http://cr.openjdk.java.net/~eosterlund/8215773/webrev.00/ > > Looks good. > > /Per > >> >> Manually ran kitchensink 24 hours to make sure this doesn't happen >> again. And hs-tier1-6 on linux. >> >> Thanks, >> /Erik From claes.redestad at oracle.com Mon Jan 7 12:36:45 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 7 Jan 2019 13:36:45 +0100 Subject: RFR: 8216262: Remove develop flag DelayCompilationDuringStartup Message-ID: <64522ad1-1473-8012-b63a-5309bc72c5cc@oracle.com> Hi, DelayCompilationAtStartup doesn't delay any compilations. Webrev: http://cr.openjdk.java.net/~redestad/8216262/open.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8216262 Testing: tier1 Thanks! /Claes From david.holmes at oracle.com Mon Jan 7 12:54:17 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 7 Jan 2019 22:54:17 +1000 Subject: RFR: 8216262: Remove develop flag DelayCompilationDuringStartup In-Reply-To: <64522ad1-1473-8012-b63a-5309bc72c5cc@oracle.com> References: <64522ad1-1473-8012-b63a-5309bc72c5cc@oracle.com> Message-ID: <9a9f466b-5ffc-06de-9fde-6a8ef78622ee@oracle.com> Hi Claes, On 7/01/2019 10:36 pm, Claes Redestad wrote: > Hi, > > DelayCompilationAtStartup doesn't delay any compilations. > > Webrev: http://cr.openjdk.java.net/~redestad/8216262/open.00/ > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8216262 Normally we would follow a staged removal process: deprecate, obsolete, then expire - see arguments.cpp and special_jvm_flags table. In this case we can probably start at obsoletion, but that would leave expiration for JDK 14. Or compiler folk can argue for / justify immediate full expiration/removal. Cheers, David > Testing: tier1 > > Thanks! > > /Claes From claes.redestad at oracle.com Mon Jan 7 13:01:51 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 7 Jan 2019 14:01:51 +0100 Subject: RFR: 8216262: Remove develop flag DelayCompilationDuringStartup In-Reply-To: <9a9f466b-5ffc-06de-9fde-6a8ef78622ee@oracle.com> References: <64522ad1-1473-8012-b63a-5309bc72c5cc@oracle.com> <9a9f466b-5ffc-06de-9fde-6a8ef78622ee@oracle.com> Message-ID: <2708906c-c27e-4514-3066-0f2a86fbae9e@oracle.com> On 2019-01-07 13:54, David Holmes wrote: > Hi Claes, > > On 7/01/2019 10:36 pm, Claes Redestad wrote: >> Hi, >> >> DelayCompilationAtStartup doesn't delay any compilations. >> >> Webrev: http://cr.openjdk.java.net/~redestad/8216262/open.00/ >> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8216262 > > Normally we would follow a staged removal process: deprecate, obsolete, > then expire - see arguments.cpp and special_jvm_flags table. In this > case we can probably start at obsoletion, but that would leave > expiration for JDK 14. Or compiler folk can argue for / justify > immediate full expiration/removal. I'm under the impression this process does not apply to develop flags (which are not visible an anything by debug builds)? /Claes From robbin.ehn at oracle.com Mon Jan 7 13:04:41 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Mon, 7 Jan 2019 14:04:41 +0100 Subject: RFR 8215155: Remove get_insert() from concurrent hashtable and gtests In-Reply-To: <0362626e-a926-8449-564d-c916a8f98e13@oracle.com> References: <6b738e53-3468-8ad1-23f9-ce2a023b977b@oracle.com> <0362626e-a926-8449-564d-c916a8f98e13@oracle.com> Message-ID: Thanks for fixing Gerard! /Robbin On 12/17/18 10:44 PM, coleen.phillimore at oracle.com wrote: > > > On 12/13/18 10:48 AM, Gerard Ziemski wrote: >>> On Dec 13, 2018, at 8:58 AM, Gerard Ziemski wrote: >>> >>> >>>> On Dec 12, 2018, at 6:30 PM,coleen.phillimore at oracle.com wrote: >>>> >>>> >>>> This looks good to me. >>>> >>>> On 12/12/18 3:01 PM, Gerard Ziemski wrote: >>>>> Hi all, >>>>> >>>>> Please review this enhancement followup to JDK-8214310 and JDK-8213791 >>>>> >>>>> Here we redo the relevant gtest tests to use get(),insert() and are now free to remove the get_insert() API from the concurrent hash table implementation. >>>>> >>>>> bug id:https://bugs.openjdk.java.net/browse/JDK-8215155 >>>>> webrev:http://cr.openjdk.java.net/~gziemski/8215155_rev1 >>>>> Testing: Passed Mach hs_tier1, another Mach hs_tier1,2,3,4,5,6 in progress? >>>>> >>>>> P.S. I?d like to push this into JDK12 if there is no contention about this fix? >>>> It seems pretty straightforward. I'm fine with your pushing this to 12 but the deadline is fast approaching and I think you should have another reviewer. >>> Thank you for the review Coleen! >>> >>> As this is a test related change plus trivial removal of unused API, normally I?d mark it as trivial, but I agree with you - a second reviewer here would be most appreciated. >> I just discovered that I had an assert reversed in my webrev1 fix - in the file jdk/test/hotspot/gtest/utilities/test_concurrentHashtable.cpp, line 108: >> >> EXPECT_EQ(cht->insert(thr, stl, val), false) << "Inserting an unique value failed.?; >> >> should be: >> >> EXPECT_EQ(cht->insert(thr, stl, val), true) << "Inserting an unique value failed.?; >> >> I fixed it and postedhttp://cr.openjdk.java.net/~gziemski/8215155_rev2 >> >> I fired another Mach5 test (why wasn?t it caught?), but now I feel a bit less confident about pushing it into jdk12? > > I can't explain that either.? You can run locally via *make test-hotspot-gtest > *and with some more options to just run the test. > > I read it a bit more carefully this time.? It looks good. > > Coleen > ** >> cheers >> >> >> > From claes.redestad at oracle.com Mon Jan 7 13:31:42 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 7 Jan 2019 14:31:42 +0100 Subject: RFR: 8216262: Remove develop flag DelayCompilationDuringStartup In-Reply-To: <2708906c-c27e-4514-3066-0f2a86fbae9e@oracle.com> References: <64522ad1-1473-8012-b63a-5309bc72c5cc@oracle.com> <9a9f466b-5ffc-06de-9fde-6a8ef78622ee@oracle.com> <2708906c-c27e-4514-3066-0f2a86fbae9e@oracle.com> Message-ID: <818084dc-3e98-97da-20f4-aa00f3f6545e@oracle.com> On 2019-01-07 14:01, Claes Redestad wrote: >> >> Normally we would follow a staged removal process: deprecate, >> obsolete, then expire - see arguments.cpp and special_jvm_flags table. >> In this case we can probably start at obsoletion, but that would leave >> expiration for JDK 14. Or compiler folk can argue for / justify >> immediate full expiration/removal. > > I'm under the impression this process does not apply to develop flags > (which are not visible an anything but debug builds)? We've removed develop flags without obsoletion + expiry many times in the past[1], and while this goes against the written down expiration in arguments.cpp, I believe it to be a misguided recommendation for develop flags. /Claes [1] https://bugs.openjdk.java.net/browse/JDK-8191870 https://bugs.openjdk.java.net/browse/JDK-8132318 https://bugs.openjdk.java.net/browse/JDK-8186042 https://bugs.openjdk.java.net/browse/JDK-8180423 https://bugs.openjdk.java.net/browse/JDK-8058259 From martin.doerr at sap.com Mon Jan 7 14:19:46 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 7 Jan 2019 14:19:46 +0000 Subject: RFR(XS): 8216269: [s390] Debug build broken because CodeBlob has not been declared Message-ID: <9ea21bf0aa564065bc062fd7ddb16f28@sap.com> Hi, we are getting the following build error on s390: In file included from .../jdk/src/hotspot/share/code/relocInfo.hpp:427:0, .../jdk/src/hotspot/cpu/s390/relocInfo_s390.hpp:119:78: error: 'CodeBlob' has not been declared static bool update_oop_pool(address begin, address end, address newTarget, CodeBlob* cb); ^~~~~~~~ Please review this tiny fix: http://cr.openjdk.java.net/~mdoerr/8216269_s390_fix_build/webrev.00/ Best regards, Martin From goetz.lindenmaier at sap.com Mon Jan 7 14:34:11 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 7 Jan 2019 14:34:11 +0000 Subject: RFR(S): 8216271: Make AllocateOldGenAt an unsupported option on AIX. Message-ID: Hi, Similar to AllocateHeapAt this flag ist not supported on AIX. So I reject it at startup and disable the tests. See also https://bugs.openjdk.java.net/browse/JDK-8211208. Please review. http://cr.openjdk.java.net/~goetz/wr19/8216271-aix_AllocateAt/01/ I want to push this to jdk12 please. Best regards, Goetz. From shade at redhat.com Mon Jan 7 14:36:09 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 7 Jan 2019 15:36:09 +0100 Subject: RFR(XS): 8216269: [s390] Debug build broken because CodeBlob has not been declared In-Reply-To: <9ea21bf0aa564065bc062fd7ddb16f28@sap.com> References: <9ea21bf0aa564065bc062fd7ddb16f28@sap.com> Message-ID: On 1/7/19 3:19 PM, Doerr, Martin wrote: > In file included from .../jdk/src/hotspot/share/code/relocInfo.hpp:427:0, > .../jdk/src/hotspot/cpu/s390/relocInfo_s390.hpp:119:78: error: 'CodeBlob' has not been declared > static bool update_oop_pool(address begin, address end, address newTarget, CodeBlob* cb); > ^~~~~~~~ > > Please review this tiny fix: > http://cr.openjdk.java.net/~mdoerr/8216269_s390_fix_build/webrev.00/ Oh. I have just been looking into that in JDK-8216272, closed that as duplicate. Checked the your patch fixed the build failure for me. I tried to put the missing forward declaration into src/hotspot/cpu/s390/relocInfo_s390.hpp, closer to the actual declaration that uses CodeBlob, but then other compilation units look for in in relocInfo.hpp itself. I don't think we need a comment, and also added line should not break the alphabetic order? class nmethod; +class CodeBlob; class CompiledMethod; class Metadata; class NativeMovConstReg; Otherwise this looks good and trivial. -Aleksey From shade at redhat.com Mon Jan 7 14:39:46 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 7 Jan 2019 15:39:46 +0100 Subject: RFR(S): 8216271: Make AllocateOldGenAt an unsupported option on AIX. In-Reply-To: References: Message-ID: On 1/7/19 3:34 PM, Lindenmaier, Goetz wrote: > Please review. > http://cr.openjdk.java.net/~goetz/wr19/8216271-aix_AllocateAt/01/ This looks okay to me. It indeed follows how AllocateHeapAt is handled already. -Aleksey From goetz.lindenmaier at sap.com Mon Jan 7 14:40:39 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 7 Jan 2019 14:40:39 +0000 Subject: RFR(S): 8216271: Make AllocateOldGenAt an unsupported option on AIX. In-Reply-To: References: Message-ID: Thanks Aleksey! Best regards, Goetz. > -----Original Message----- > From: Aleksey Shipilev > Sent: Montag, 7. Januar 2019 15:40 > To: Lindenmaier, Goetz ; hotspot-runtime- > dev at openjdk.java.net > Subject: Re: RFR(S): 8216271: Make AllocateOldGenAt an unsupported option > on AIX. > > On 1/7/19 3:34 PM, Lindenmaier, Goetz wrote: > > Please review. > > http://cr.openjdk.java.net/~goetz/wr19/8216271-aix_AllocateAt/01/ > > This looks okay to me. It indeed follows how AllocateHeapAt is handled > already. > > -Aleksey From coleen.phillimore at oracle.com Mon Jan 7 14:40:58 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 7 Jan 2019 09:40:58 -0500 Subject: RFR(XS): 8216269: [s390] Debug build broken because CodeBlob has not been declared In-Reply-To: References: <9ea21bf0aa564065bc062fd7ddb16f28@sap.com> Message-ID: On 1/7/19 9:36 AM, Aleksey Shipilev wrote: > On 1/7/19 3:19 PM, Doerr, Martin wrote: >> In file included from .../jdk/src/hotspot/share/code/relocInfo.hpp:427:0, >> .../jdk/src/hotspot/cpu/s390/relocInfo_s390.hpp:119:78: error: 'CodeBlob' has not been declared >> static bool update_oop_pool(address begin, address end, address newTarget, CodeBlob* cb); >> ^~~~~~~~ >> >> Please review this tiny fix: >> http://cr.openjdk.java.net/~mdoerr/8216269_s390_fix_build/webrev.00/ > Oh. I have just been looking into that in JDK-8216272, closed that as duplicate. Checked the your > patch fixed the build failure for me. I tried to put the missing forward declaration into > src/hotspot/cpu/s390/relocInfo_s390.hpp, closer to the actual declaration that uses CodeBlob, but > then other compilation units look for in in relocInfo.hpp itself. > > I don't think we need a comment, and also added line should not break the alphabetic order? I didn't know if we had that guideline for forward declarations, but sometimes try to respect it when the files are from a similar subsystem. Looks good/trivial to me as well. thanks, Coleen > > class nmethod; > +class CodeBlob; > class CompiledMethod; > class Metadata; > class NativeMovConstReg; > > Otherwise this looks good and trivial. > > -Aleksey > > From martin.doerr at sap.com Mon Jan 7 15:51:34 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 7 Jan 2019 15:51:34 +0000 Subject: RFR(XS): 8216269: [s390] Debug build broken because CodeBlob has not been declared In-Reply-To: References: <9ea21bf0aa564065bc062fd7ddb16f28@sap.com> Message-ID: <08adbb2e21744d67a5c3da44a8ce7d70@sap.com> Hi Coleen and Aleksey, thank you for the reviews. I'll push Aleksey's version tomorrow. Best regards, Martin -----Original Message----- From: hotspot-runtime-dev On Behalf Of coleen.phillimore at oracle.com Sent: Montag, 7. Januar 2019 15:41 To: hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR(XS): 8216269: [s390] Debug build broken because CodeBlob has not been declared On 1/7/19 9:36 AM, Aleksey Shipilev wrote: > On 1/7/19 3:19 PM, Doerr, Martin wrote: >> In file included from .../jdk/src/hotspot/share/code/relocInfo.hpp:427:0, >> .../jdk/src/hotspot/cpu/s390/relocInfo_s390.hpp:119:78: error: 'CodeBlob' has not been declared >> static bool update_oop_pool(address begin, address end, address newTarget, CodeBlob* cb); >> ^~~~~~~~ >> >> Please review this tiny fix: >> http://cr.openjdk.java.net/~mdoerr/8216269_s390_fix_build/webrev.00/ > Oh. I have just been looking into that in JDK-8216272, closed that as duplicate. Checked the your > patch fixed the build failure for me. I tried to put the missing forward declaration into > src/hotspot/cpu/s390/relocInfo_s390.hpp, closer to the actual declaration that uses CodeBlob, but > then other compilation units look for in in relocInfo.hpp itself. > > I don't think we need a comment, and also added line should not break the alphabetic order? I didn't know if we had that guideline for forward declarations, but sometimes try to respect it when the files are from a similar subsystem. Looks good/trivial to me as well. thanks, Coleen > > class nmethod; > +class CodeBlob; > class CompiledMethod; > class Metadata; > class NativeMovConstReg; > > Otherwise this looks good and trivial. > > -Aleksey > > From thomas.schatzl at oracle.com Mon Jan 7 16:30:41 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 07 Jan 2019 17:30:41 +0100 Subject: RFR(S): 8216271: Make AllocateOldGenAt an unsupported option on AIX. In-Reply-To: References: Message-ID: Hi, On Mon, 2019-01-07 at 14:34 +0000, Lindenmaier, Goetz wrote: > Hi, > > Similar to AllocateHeapAt this flag ist not supported on AIX. So I > reject it at startup and disable the tests. See also > https://bugs.openjdk.java.net/browse/JDK-8211208. > > Please review. > http://cr.openjdk.java.net/~goetz/wr19/8216271-aix_AllocateAt/01/ > > I want to push this to jdk12 please. looks good. Thomas From david.holmes at oracle.com Mon Jan 7 21:21:18 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 8 Jan 2019 07:21:18 +1000 Subject: RFR: 8216262: Remove develop flag DelayCompilationDuringStartup In-Reply-To: <818084dc-3e98-97da-20f4-aa00f3f6545e@oracle.com> References: <64522ad1-1473-8012-b63a-5309bc72c5cc@oracle.com> <9a9f466b-5ffc-06de-9fde-6a8ef78622ee@oracle.com> <2708906c-c27e-4514-3066-0f2a86fbae9e@oracle.com> <818084dc-3e98-97da-20f4-aa00f3f6545e@oracle.com> Message-ID: <2c837971-967c-285c-f85d-a88cfe82aac3@oracle.com> On 7/01/2019 11:31 pm, Claes Redestad wrote: > > > On 2019-01-07 14:01, Claes Redestad wrote: >>> >>> Normally we would follow a staged removal process: deprecate, >>> obsolete, then expire - see arguments.cpp and special_jvm_flags >>> table. In this case we can probably start at obsoletion, but that >>> would leave expiration for JDK 14. Or compiler folk can argue for / >>> justify immediate full expiration/removal. >> >> I'm under the impression this process does not apply to develop flags >> (which are not visible an anything but debug builds)? > > We've removed develop flags without obsoletion + expiry many times in > the past[1], and while this goes against the written down expiration > in arguments.cpp, I believe it to be a misguided recommendation for > develop flags. There have been and still can be exceptions depending on the actual flag but the general guideline is: * To remove internal options (e.g. diagnostic, experimental, develop options), use * a 2-step model adding major release numbers to the obsolete and expire columns. Compiler folk can identify whether this flag can be expired immediately. Thanks, David > /Claes > > [1] > https://bugs.openjdk.java.net/browse/JDK-8191870 > https://bugs.openjdk.java.net/browse/JDK-8132318 > https://bugs.openjdk.java.net/browse/JDK-8186042 > https://bugs.openjdk.java.net/browse/JDK-8180423 > https://bugs.openjdk.java.net/browse/JDK-8058259 From claes.redestad at oracle.com Mon Jan 7 23:13:26 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 8 Jan 2019 00:13:26 +0100 Subject: RFR: 8216262: Remove develop flag DelayCompilationDuringStartup In-Reply-To: <2c837971-967c-285c-f85d-a88cfe82aac3@oracle.com> References: <64522ad1-1473-8012-b63a-5309bc72c5cc@oracle.com> <9a9f466b-5ffc-06de-9fde-6a8ef78622ee@oracle.com> <2708906c-c27e-4514-3066-0f2a86fbae9e@oracle.com> <818084dc-3e98-97da-20f4-aa00f3f6545e@oracle.com> <2c837971-967c-285c-f85d-a88cfe82aac3@oracle.com> Message-ID: On 2019-01-07 22:21, David Holmes wrote: >>> >>> I'm under the impression this process does not apply to develop flags >>> (which are not visible an anything but debug builds)? >> >> We've removed develop flags without obsoletion + expiry many times in >> the past[1], and while this goes against the written down expiration >> in arguments.cpp, I believe it to be a misguided recommendation for >> develop flags. > > There have been and still can be exceptions depending on the actual > flag but the general guideline is: > > ?* To remove internal options (e.g. diagnostic, experimental, develop > options), use > ?* a 2-step model adding major release numbers to the obsolete and > expire columns. > > Compiler folk can identify whether this flag can be expired immediately. To me it seems to be the general rule rather than an exception lately, and see no point in sticking to that recommendation. I've filed https://bugs.openjdk.java.net/browse/JDK-8216311 to drop develop flags from that recommendation. /Claes From david.holmes at oracle.com Tue Jan 8 01:27:47 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 8 Jan 2019 11:27:47 +1000 Subject: RFR: 8216262: Remove develop flag DelayCompilationDuringStartup In-Reply-To: References: <64522ad1-1473-8012-b63a-5309bc72c5cc@oracle.com> <9a9f466b-5ffc-06de-9fde-6a8ef78622ee@oracle.com> <2708906c-c27e-4514-3066-0f2a86fbae9e@oracle.com> <818084dc-3e98-97da-20f4-aa00f3f6545e@oracle.com> <2c837971-967c-285c-f85d-a88cfe82aac3@oracle.com> Message-ID: <3a286b71-c723-0cf3-47d5-e663963d9b11@oracle.com> On 8/01/2019 9:13 am, Claes Redestad wrote: > On 2019-01-07 22:21, David Holmes wrote: >>>> >>>> I'm under the impression this process does not apply to develop flags >>>> (which are not visible an anything but debug builds)? >>> >>> We've removed develop flags without obsoletion + expiry many times in >>> the past[1], and while this goes against the written down expiration >>> in arguments.cpp, I believe it to be a misguided recommendation for >>> develop flags. >> >> There have been and still can be exceptions depending on the actual >> flag but the general guideline is: >> >> ?* To remove internal options (e.g. diagnostic, experimental, develop >> options), use >> ?* a 2-step model adding major release numbers to the obsolete and >> expire columns. >> >> Compiler folk can identify whether this flag can be expired immediately. > > To me it seems to be the general rule rather than an exception lately, Perhaps ... I didn't do a complete census. I see the process being used: 8198635: Remove unused safepoint message functions and ShowSafepointMsgs and also not used: 6909265: assert(_OnDeck != Self->_MutexEvent,"invariant") with -XX:+PrintMallocFree but in this case using the flag led to an assertion failure so it was a reasonable assumption that the flag was not actually being used in practice and so could be immediately removed. > and see no point in > sticking to that recommendation. I've filed > https://bugs.openjdk.java.net/browse/JDK-8216311 > to drop develop flags from that recommendation. Noted. David > /Claes > > From vladimir.kozlov at oracle.com Tue Jan 8 06:27:24 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 7 Jan 2019 22:27:24 -0800 Subject: RFR: 8216262: Remove develop flag DelayCompilationDuringStartup In-Reply-To: <64522ad1-1473-8012-b63a-5309bc72c5cc@oracle.com> References: <64522ad1-1473-8012-b63a-5309bc72c5cc@oracle.com> Message-ID: <13ef0777-a122-555d-4719-ff09c17e674e@oracle.com> This mechanism was added before I joined the team. I see that it is present from day one. I speculate it was added to avoid allocating CPU (very limited at that time) cycles to compilation during VM startup. I agree that currently it is not the case since we have enough cyles and need to compile MHs very eagerly. JVMCI has other mechanism which delay compilation until it is initialized. And I don't think we should delay usage of AOT code. In short - I agree with changes and removal this archaic feature. I would suggest immediate removal (or shortest available). Thanks, Vladimir On 1/7/19 4:36 AM, Claes Redestad wrote: > Hi, > > DelayCompilationAtStartup doesn't delay any compilations. > > Webrev: http://cr.openjdk.java.net/~redestad/8216262/open.00/ > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8216262 > > Testing: tier1 > > Thanks! > > /Claes From goetz.lindenmaier at sap.com Tue Jan 8 08:41:38 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 8 Jan 2019 08:41:38 +0000 Subject: RFR(S): 8216271: Make AllocateOldGenAt an unsupported option on AIX. In-Reply-To: References: Message-ID: <10b56a484fe34140aa44824981961688@sap.com> Unfortunately, after my change to arguments.cpp, TestAllocateOldGenAtError.java started to fail because of a different error message. I exclude this, too, now. http://cr.openjdk.java.net/~goetz/wr19/8216271-aix_AllocateAt/02/ Best regards, Goetz. > -----Original Message----- > From: Thomas Schatzl > Sent: Montag, 7. Januar 2019 17:31 > To: Lindenmaier, Goetz ; hotspot-runtime- > dev at openjdk.java.net > Subject: Re: RFR(S): 8216271: Make AllocateOldGenAt an unsupported option > on AIX. > > Hi, > > On Mon, 2019-01-07 at 14:34 +0000, Lindenmaier, Goetz wrote: > > Hi, > > > > Similar to AllocateHeapAt this flag ist not supported on AIX. So I > > reject it at startup and disable the tests. See also > > https://bugs.openjdk.java.net/browse/JDK-8211208. > > > > Please review. > > http://cr.openjdk.java.net/~goetz/wr19/8216271-aix_AllocateAt/01/ > > > > I want to push this to jdk12 please. > > looks good. > > Thomas > From shade at redhat.com Tue Jan 8 08:45:10 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 8 Jan 2019 09:45:10 +0100 Subject: RFR(S): 8216271: Make AllocateOldGenAt an unsupported option on AIX. In-Reply-To: <10b56a484fe34140aa44824981961688@sap.com> References: <10b56a484fe34140aa44824981961688@sap.com> Message-ID: On 1/8/19 9:41 AM, Lindenmaier, Goetz wrote: > Unfortunately, after my change to arguments.cpp, > TestAllocateOldGenAtError.java started to fail because of > a different error message. I exclude this, too, now. > http://cr.openjdk.java.net/~goetz/wr19/8216271-aix_AllocateAt/02/ Still good. -Aleksey From goetz.lindenmaier at sap.com Tue Jan 8 08:46:20 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 8 Jan 2019 08:46:20 +0000 Subject: RFR(S): 8216271: Make AllocateOldGenAt an unsupported option on AIX. In-Reply-To: References: <10b56a484fe34140aa44824981961688@sap.com> Message-ID: <1a79e2e48ab94400b52e3d7572388b4a@sap.com> Thanks! Best regards, Goetz. > -----Original Message----- > From: Aleksey Shipilev > Sent: Dienstag, 8. Januar 2019 09:45 > To: Lindenmaier, Goetz ; hotspot-runtime- > dev at openjdk.java.net > Subject: Re: RFR(S): 8216271: Make AllocateOldGenAt an unsupported option > on AIX. > > On 1/8/19 9:41 AM, Lindenmaier, Goetz wrote: > > Unfortunately, after my change to arguments.cpp, > > TestAllocateOldGenAtError.java started to fail because of > > a different error message. I exclude this, too, now. > > http://cr.openjdk.java.net/~goetz/wr19/8216271-aix_AllocateAt/02/ > > Still good. > > -Aleksey From tobias.hartmann at oracle.com Tue Jan 8 09:45:55 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 8 Jan 2019 10:45:55 +0100 Subject: RFR: 8216262: Remove develop flag DelayCompilationDuringStartup In-Reply-To: <13ef0777-a122-555d-4719-ff09c17e674e@oracle.com> References: <64522ad1-1473-8012-b63a-5309bc72c5cc@oracle.com> <13ef0777-a122-555d-4719-ff09c17e674e@oracle.com> Message-ID: Hi Claes, On 08.01.19 07:27, Vladimir Kozlov wrote: > In short - I agree with changes and removal this archaic feature. > I would suggest immediate removal (or shortest available). +1 Best regards, Tobias From claes.redestad at oracle.com Tue Jan 8 09:53:35 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 8 Jan 2019 10:53:35 +0100 Subject: RFR: 8216262: Remove develop flag DelayCompilationDuringStartup In-Reply-To: References: <64522ad1-1473-8012-b63a-5309bc72c5cc@oracle.com> <13ef0777-a122-555d-4719-ff09c17e674e@oracle.com> Message-ID: Vladimir, Tobias, thanks for reviewing! /Claes On 2019-01-08 10:45, Tobias Hartmann wrote: > Hi Claes, > > On 08.01.19 07:27, Vladimir Kozlov wrote: >> In short - I agree with changes and removal this archaic feature. >> I would suggest immediate removal (or shortest available). > > +1 > > Best regards, > Tobias > From harold.seigel at oracle.com Tue Jan 8 14:17:39 2019 From: harold.seigel at oracle.com (Harold David Seigel) Date: Tue, 8 Jan 2019 09:17:39 -0500 Subject: RFR 8214442: Improve stack walk API by adding handle marks Message-ID: <5e1b0c22-4ccd-564b-d737-36c4587b6c2d@oracle.com> Hi, Please review this small JDK-13 change to add handle marks to the stack walk API for reasons described in the bug. Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8214442/webrev/index.html JBS Bug:? https://bugs.openjdk.java.net/browse/JDK-8214442 The fix was regression tested by running Mach5 tiers 1 and 2 tests and builds on Linux-x64, Windows, and Mac OS X, Mach5 tiers 3 -5 o Linux-x64, and by running JCK-12 Lang and VM tests on Linux-x64. Thanks, Harold From harold.seigel at oracle.com Tue Jan 8 14:27:10 2019 From: harold.seigel at oracle.com (Harold David Seigel) Date: Tue, 8 Jan 2019 09:27:10 -0500 Subject: RFR 8215901: [TESTBUG] TestCheckedEnsureLocalCapacity.java fails intermittently Message-ID: Hi, Please review this small fix for JDK-8215901.? The test passes if its output matches a certain pattern.? The fix, suggested by Dan, changes the pattern to not require it to be at the beginning of a line. Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8215901/webrev/ JBS Bug:? https://bugs.openjdk.java.net/browse/JDK-8215901 The fix was tested by running the test over 600 times on multiple platforms. Thanks, Harold From zgu at redhat.com Tue Jan 8 14:34:08 2019 From: zgu at redhat.com (zgu at redhat.com) Date: Tue, 08 Jan 2019 09:34:08 -0500 Subject: RFR 8214442: Improve stack walk API by adding handle marks In-Reply-To: <5e1b0c22-4ccd-564b-d737-36c4587b6c2d@oracle.com> References: <5e1b0c22-4ccd-564b-d737-36c4587b6c2d@oracle.com> Message-ID: <1546958048.3477.51.camel@redhat.com> Looks good to me. Thanks, -Zhengyu On Tue, 2019-01-08 at 09:17 -0500, Harold David Seigel wrote: > Hi, > > Please review this small JDK-13 change to add handle marks to the > stack > walk API for reasons described in the bug. > > Open Webrev: > http://cr.openjdk.java.net/~hseigel/bug_8214442/webrev/index.html > > JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8214442 > > The fix was regression tested by running Mach5 tiers 1 and 2 tests > and > builds on Linux-x64, Windows, and Mac OS X, Mach5 tiers 3 -5 o > Linux-x64, and by running JCK-12 Lang and VM tests on Linux-x64. > > Thanks, Harold > From harold.seigel at oracle.com Tue Jan 8 14:34:42 2019 From: harold.seigel at oracle.com (Harold David Seigel) Date: Tue, 8 Jan 2019 09:34:42 -0500 Subject: RFR 8214442: Improve stack walk API by adding handle marks In-Reply-To: <1546958048.3477.51.camel@redhat.com> References: <5e1b0c22-4ccd-564b-d737-36c4587b6c2d@oracle.com> <1546958048.3477.51.camel@redhat.com> Message-ID: <20d7edf4-16b0-c6d9-f794-f02e285b93dd@oracle.com> Thanks Zhengyu! Harold On 1/8/2019 9:34 AM, zgu at redhat.com wrote: > Looks good to me. > > Thanks, > > -Zhengyu > > On Tue, 2019-01-08 at 09:17 -0500, Harold David Seigel wrote: >> Hi, >> >> Please review this small JDK-13 change to add handle marks to the >> stack >> walk API for reasons described in the bug. >> >> Open Webrev: >> http://cr.openjdk.java.net/~hseigel/bug_8214442/webrev/index.html >> >> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8214442 >> >> The fix was regression tested by running Mach5 tiers 1 and 2 tests >> and >> builds on Linux-x64, Windows, and Mac OS X, Mach5 tiers 3 -5 o >> Linux-x64, and by running JCK-12 Lang and VM tests on Linux-x64. >> >> Thanks, Harold >> From daniel.daugherty at oracle.com Tue Jan 8 14:36:26 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 8 Jan 2019 09:36:26 -0500 Subject: RFR 8215901: [TESTBUG] TestCheckedEnsureLocalCapacity.java fails intermittently In-Reply-To: References: Message-ID: <959a3e60-281c-78b1-3956-af6a593bc656@oracle.com> On 1/8/19 9:27 AM, Harold David Seigel wrote: > Hi, > > Please review this small fix for JDK-8215901.? The test passes if its > output matches a certain pattern.? The fix, suggested by Dan, changes > the pattern to not require it to be at the beginning of a line. > > Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8215901/webrev/ test/hotspot/jtreg/runtime/jni/checked/TestCheckedEnsureLocalCapacity.java ??? Perhaps a comment above the variable: ??? // Not anchored to the beginning of the line to allow match with interleaved output. Thumbs up. Your call on whether to add the comment or something like it. Don't need to see another webrev. Dan > > JBS Bug:? https://bugs.openjdk.java.net/browse/JDK-8215901 > > The fix was tested by running the test over 600 times on multiple > platforms. > > Thanks, Harold > From harold.seigel at oracle.com Tue Jan 8 14:38:31 2019 From: harold.seigel at oracle.com (Harold David Seigel) Date: Tue, 8 Jan 2019 09:38:31 -0500 Subject: RFR 8215901: [TESTBUG] TestCheckedEnsureLocalCapacity.java fails intermittently In-Reply-To: <959a3e60-281c-78b1-3956-af6a593bc656@oracle.com> References: <959a3e60-281c-78b1-3956-af6a593bc656@oracle.com> Message-ID: Thanks Dan! I'll add the comment before pushing. Harold On 1/8/2019 9:36 AM, Daniel D. Daugherty wrote: > On 1/8/19 9:27 AM, Harold David Seigel wrote: >> Hi, >> >> Please review this small fix for JDK-8215901.? The test passes if its >> output matches a certain pattern.? The fix, suggested by Dan, changes >> the pattern to not require it to be at the beginning of a line. >> >> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8215901/webrev/ > > test/hotspot/jtreg/runtime/jni/checked/TestCheckedEnsureLocalCapacity.java > > ??? Perhaps a comment above the variable: > > ??? // Not anchored to the beginning of the line to allow match with > interleaved output. > > Thumbs up. Your call on whether to add the comment or something like it. > Don't need to see another webrev. > > Dan > > >> >> JBS Bug:? https://bugs.openjdk.java.net/browse/JDK-8215901 >> >> The fix was tested by running the test over 600 times on multiple >> platforms. >> >> Thanks, Harold >> > From daniel.daugherty at oracle.com Tue Jan 8 14:41:37 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 8 Jan 2019 09:41:37 -0500 Subject: RFR 8215901: [TESTBUG] TestCheckedEnsureLocalCapacity.java fails intermittently In-Reply-To: References: <959a3e60-281c-78b1-3956-af6a593bc656@oracle.com> Message-ID: <51e8fdd0-105c-b473-ecdc-97c88bb5ed1c@oracle.com> Sorry, I just took another look at the test: This line is also a problem: ? L3: ??? private static final String WARNING = "^WARNING: "; Because of the '^' anchor, you could miss an unexpected "WARNING: " in the "no warnings" test case. Dan On 1/8/19 9:38 AM, Harold David Seigel wrote: > Thanks Dan! > > I'll add the comment before pushing. > > Harold > > On 1/8/2019 9:36 AM, Daniel D. Daugherty wrote: >> On 1/8/19 9:27 AM, Harold David Seigel wrote: >>> Hi, >>> >>> Please review this small fix for JDK-8215901.? The test passes if >>> its output matches a certain pattern.? The fix, suggested by Dan, >>> changes the pattern to not require it to be at the beginning of a line. >>> >>> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8215901/webrev/ >> >> test/hotspot/jtreg/runtime/jni/checked/TestCheckedEnsureLocalCapacity.java >> >> ??? Perhaps a comment above the variable: >> >> ??? // Not anchored to the beginning of the line to allow match with >> interleaved output. >> >> Thumbs up. Your call on whether to add the comment or something like it. >> Don't need to see another webrev. >> >> Dan >> >> >>> >>> JBS Bug:? https://bugs.openjdk.java.net/browse/JDK-8215901 >>> >>> The fix was tested by running the test over 600 times on multiple >>> platforms. >>> >>> Thanks, Harold >>> >> From harold.seigel at oracle.com Tue Jan 8 14:44:56 2019 From: harold.seigel at oracle.com (Harold David Seigel) Date: Tue, 8 Jan 2019 09:44:56 -0500 Subject: RFR 8215901: [TESTBUG] TestCheckedEnsureLocalCapacity.java fails intermittently In-Reply-To: <51e8fdd0-105c-b473-ecdc-97c88bb5ed1c@oracle.com> References: <959a3e60-281c-78b1-3956-af6a593bc656@oracle.com> <51e8fdd0-105c-b473-ecdc-97c88bb5ed1c@oracle.com> Message-ID: <3f110348-9443-4507-17ed-3ed291f3d366@oracle.com> Good find!? I'll remove the '^' from '^WARNING', and re-test. Harold On 1/8/2019 9:41 AM, Daniel D. Daugherty wrote: > Sorry, I just took another look at the test: > > This line is also a problem: > > ? L3: ??? private static final String WARNING = "^WARNING: "; > > Because of the '^' anchor, you could miss an unexpected "WARNING: " in > the "no warnings" test case. > > Dan > > > On 1/8/19 9:38 AM, Harold David Seigel wrote: >> Thanks Dan! >> >> I'll add the comment before pushing. >> >> Harold >> >> On 1/8/2019 9:36 AM, Daniel D. Daugherty wrote: >>> On 1/8/19 9:27 AM, Harold David Seigel wrote: >>>> Hi, >>>> >>>> Please review this small fix for JDK-8215901.? The test passes if >>>> its output matches a certain pattern.? The fix, suggested by Dan, >>>> changes the pattern to not require it to be at the beginning of a >>>> line. >>>> >>>> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8215901/webrev/ >>> >>> test/hotspot/jtreg/runtime/jni/checked/TestCheckedEnsureLocalCapacity.java >>> >>> ??? Perhaps a comment above the variable: >>> >>> ??? // Not anchored to the beginning of the line to allow match with >>> interleaved output. >>> >>> Thumbs up. Your call on whether to add the comment or something like >>> it. >>> Don't need to see another webrev. >>> >>> Dan >>> >>> >>>> >>>> JBS Bug:? https://bugs.openjdk.java.net/browse/JDK-8215901 >>>> >>>> The fix was tested by running the test over 600 times on multiple >>>> platforms. >>>> >>>> Thanks, Harold >>>> >>> > From harold.seigel at oracle.com Tue Jan 8 15:08:32 2019 From: harold.seigel at oracle.com (Harold David Seigel) Date: Tue, 8 Jan 2019 10:08:32 -0500 Subject: RFR 8215699: -Xlog::file cannot be used with named pipe Message-ID: Hi, Please review this fix for JDK-8215699.? The fix sets the default logging file count to zero if the log file is a named pipe.? This prevents the logging code from complaining about trying to do log file rotation with a non-regular file. Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8215699/webrev/index.html JBS Bug:? https://bugs.openjdk.java.net/browse/JDK-8215699 The fix was tested by hand on both Linux-x64 and Mac OS X. Logging to a named pipe worked when no filecount was specified and when filecount=0 was specified. The fix was regression tested by running Mach5 tiers 1 and 2 tests and builds on Linux-x64, Windows, and Mac OS X, Mach5 tiers 3 -5 on Linux-x64, and by running JCK-12 Lang and VM tests on Linux-x64. Thanks, Harold From harold.seigel at oracle.com Tue Jan 8 16:25:48 2019 From: harold.seigel at oracle.com (Harold David Seigel) Date: Tue, 8 Jan 2019 11:25:48 -0500 Subject: RFR 8215901: [TESTBUG] TestCheckedEnsureLocalCapacity.java fails intermittently In-Reply-To: <51e8fdd0-105c-b473-ecdc-97c88bb5ed1c@oracle.com> References: <959a3e60-281c-78b1-3956-af6a593bc656@oracle.com> <51e8fdd0-105c-b473-ecdc-97c88bb5ed1c@oracle.com> Message-ID: <4431d458-58c4-77b5-361a-a2e5920414fb@oracle.com> Hi Dan, Please review this updated webrev that removes the '^' from '^WARNING:'.? I also removed the trailing blank. http://cr.openjdk.java.net/~hseigel/bug_8215901.2/webrev/index.html Thanks, Harold On 1/8/2019 9:41 AM, Daniel D. Daugherty wrote: > Sorry, I just took another look at the test: > > This line is also a problem: > > ? L3: ??? private static final String WARNING = "^WARNING: "; > > Because of the '^' anchor, you could miss an unexpected "WARNING: " in > the "no warnings" test case. > > Dan > > > On 1/8/19 9:38 AM, Harold David Seigel wrote: >> Thanks Dan! >> >> I'll add the comment before pushing. >> >> Harold >> >> On 1/8/2019 9:36 AM, Daniel D. Daugherty wrote: >>> On 1/8/19 9:27 AM, Harold David Seigel wrote: >>>> Hi, >>>> >>>> Please review this small fix for JDK-8215901.? The test passes if >>>> its output matches a certain pattern.? The fix, suggested by Dan, >>>> changes the pattern to not require it to be at the beginning of a >>>> line. >>>> >>>> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8215901/webrev/ >>> >>> test/hotspot/jtreg/runtime/jni/checked/TestCheckedEnsureLocalCapacity.java >>> >>> ??? Perhaps a comment above the variable: >>> >>> ??? // Not anchored to the beginning of the line to allow match with >>> interleaved output. >>> >>> Thumbs up. Your call on whether to add the comment or something like >>> it. >>> Don't need to see another webrev. >>> >>> Dan >>> >>> >>>> >>>> JBS Bug:? https://bugs.openjdk.java.net/browse/JDK-8215901 >>>> >>>> The fix was tested by running the test over 600 times on multiple >>>> platforms. >>>> >>>> Thanks, Harold >>>> >>> > From harold.seigel at oracle.com Tue Jan 8 17:05:19 2019 From: harold.seigel at oracle.com (Harold David Seigel) Date: Tue, 8 Jan 2019 12:05:19 -0500 Subject: RFR 8215901: [TESTBUG] TestCheckedEnsureLocalCapacity.java fails intermittently In-Reply-To: <9398d51e-6381-563c-0eac-f22ec56e65fc@oracle.com> References: <959a3e60-281c-78b1-3956-af6a593bc656@oracle.com> <51e8fdd0-105c-b473-ecdc-97c88bb5ed1c@oracle.com> <4431d458-58c4-77b5-361a-a2e5920414fb@oracle.com> <9398d51e-6381-563c-0eac-f22ec56e65fc@oracle.com> Message-ID: Thanks! Harold On 1/8/2019 12:04 PM, Daniel D. Daugherty wrote: > On 1/8/19 11:25 AM, Harold David Seigel wrote: >> >> Hi Dan, >> >> Please review this updated webrev that removes the '^' from >> '^WARNING:'.? I also removed the trailing blank. >> >> http://cr.openjdk.java.net/~hseigel/bug_8215901.2/webrev/index.html >> > > Thumbs up on the re-review. > > Dan > > >> Thanks, Harold >> >> On 1/8/2019 9:41 AM, Daniel D. Daugherty wrote: >>> Sorry, I just took another look at the test: >>> >>> This line is also a problem: >>> >>> ? L3: ??? private static final String WARNING = "^WARNING: "; >>> >>> Because of the '^' anchor, you could miss an unexpected "WARNING: " in >>> the "no warnings" test case. >>> >>> Dan >>> >>> >>> On 1/8/19 9:38 AM, Harold David Seigel wrote: >>>> Thanks Dan! >>>> >>>> I'll add the comment before pushing. >>>> >>>> Harold >>>> >>>> On 1/8/2019 9:36 AM, Daniel D. Daugherty wrote: >>>>> On 1/8/19 9:27 AM, Harold David Seigel wrote: >>>>>> Hi, >>>>>> >>>>>> Please review this small fix for JDK-8215901.? The test passes if >>>>>> its output matches a certain pattern.? The fix, suggested by Dan, >>>>>> changes the pattern to not require it to be at the beginning of a >>>>>> line. >>>>>> >>>>>> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8215901/webrev/ >>>>> >>>>> test/hotspot/jtreg/runtime/jni/checked/TestCheckedEnsureLocalCapacity.java >>>>> >>>>> ??? Perhaps a comment above the variable: >>>>> >>>>> ??? // Not anchored to the beginning of the line to allow match >>>>> with interleaved output. >>>>> >>>>> Thumbs up. Your call on whether to add the comment or something >>>>> like it. >>>>> Don't need to see another webrev. >>>>> >>>>> Dan >>>>> >>>>> >>>>>> >>>>>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8215901 >>>>>> >>>>>> The fix was tested by running the test over 600 times on multiple >>>>>> platforms. >>>>>> >>>>>> Thanks, Harold >>>>>> >>>>> >>> > From harold.seigel at oracle.com Tue Jan 8 17:05:37 2019 From: harold.seigel at oracle.com (Harold David Seigel) Date: Tue, 8 Jan 2019 12:05:37 -0500 Subject: RFR 8214442: Improve stack walk API by adding handle marks In-Reply-To: References: <5e1b0c22-4ccd-564b-d737-36c4587b6c2d@oracle.com> Message-ID: <6ad62657-80d9-a63f-d4f6-7dc37a8ab1b7@oracle.com> Thanks Mandy! Harold On 1/8/2019 12:04 PM, Mandy Chung wrote: > Looks good.? Thanks for fixing it. > > Mandy > > On 1/8/19 6:17 AM, Harold David Seigel wrote: >> Hi, >> >> Please review this small JDK-13 change to add handle marks to the >> stack walk API for reasons described in the bug. >> >> Open Webrev: >> http://cr.openjdk.java.net/~hseigel/bug_8214442/webrev/index.html >> >> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8214442 >> >> The fix was regression tested by running Mach5 tiers 1 and 2 tests >> and builds on Linux-x64, Windows, and Mac OS X, Mach5 tiers 3 -5 o >> Linux-x64, and by running JCK-12 Lang and VM tests on Linux-x64. >> >> Thanks, Harold >> > From daniel.daugherty at oracle.com Tue Jan 8 17:04:51 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 8 Jan 2019 12:04:51 -0500 Subject: RFR 8215901: [TESTBUG] TestCheckedEnsureLocalCapacity.java fails intermittently In-Reply-To: <4431d458-58c4-77b5-361a-a2e5920414fb@oracle.com> References: <959a3e60-281c-78b1-3956-af6a593bc656@oracle.com> <51e8fdd0-105c-b473-ecdc-97c88bb5ed1c@oracle.com> <4431d458-58c4-77b5-361a-a2e5920414fb@oracle.com> Message-ID: <9398d51e-6381-563c-0eac-f22ec56e65fc@oracle.com> On 1/8/19 11:25 AM, Harold David Seigel wrote: > > Hi Dan, > > Please review this updated webrev that removes the '^' from > '^WARNING:'.? I also removed the trailing blank. > > http://cr.openjdk.java.net/~hseigel/bug_8215901.2/webrev/index.html > Thumbs up on the re-review. Dan > Thanks, Harold > > On 1/8/2019 9:41 AM, Daniel D. Daugherty wrote: >> Sorry, I just took another look at the test: >> >> This line is also a problem: >> >> ? L3: ??? private static final String WARNING = "^WARNING: "; >> >> Because of the '^' anchor, you could miss an unexpected "WARNING: " in >> the "no warnings" test case. >> >> Dan >> >> >> On 1/8/19 9:38 AM, Harold David Seigel wrote: >>> Thanks Dan! >>> >>> I'll add the comment before pushing. >>> >>> Harold >>> >>> On 1/8/2019 9:36 AM, Daniel D. Daugherty wrote: >>>> On 1/8/19 9:27 AM, Harold David Seigel wrote: >>>>> Hi, >>>>> >>>>> Please review this small fix for JDK-8215901.? The test passes if >>>>> its output matches a certain pattern.? The fix, suggested by Dan, >>>>> changes the pattern to not require it to be at the beginning of a >>>>> line. >>>>> >>>>> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8215901/webrev/ >>>> >>>> test/hotspot/jtreg/runtime/jni/checked/TestCheckedEnsureLocalCapacity.java >>>> >>>> ??? Perhaps a comment above the variable: >>>> >>>> ??? // Not anchored to the beginning of the line to allow match >>>> with interleaved output. >>>> >>>> Thumbs up. Your call on whether to add the comment or something >>>> like it. >>>> Don't need to see another webrev. >>>> >>>> Dan >>>> >>>> >>>>> >>>>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8215901 >>>>> >>>>> The fix was tested by running the test over 600 times on multiple >>>>> platforms. >>>>> >>>>> Thanks, Harold >>>>> >>>> >> From mandy.chung at oracle.com Tue Jan 8 17:04:59 2019 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 8 Jan 2019 09:04:59 -0800 Subject: RFR 8214442: Improve stack walk API by adding handle marks In-Reply-To: <5e1b0c22-4ccd-564b-d737-36c4587b6c2d@oracle.com> References: <5e1b0c22-4ccd-564b-d737-36c4587b6c2d@oracle.com> Message-ID: Looks good.? Thanks for fixing it. Mandy On 1/8/19 6:17 AM, Harold David Seigel wrote: > Hi, > > Please review this small JDK-13 change to add handle marks to the > stack walk API for reasons described in the bug. > > Open Webrev: > http://cr.openjdk.java.net/~hseigel/bug_8214442/webrev/index.html > > JBS Bug:? https://bugs.openjdk.java.net/browse/JDK-8214442 > > The fix was regression tested by running Mach5 tiers 1 and 2 tests and > builds on Linux-x64, Windows, and Mac OS X, Mach5 tiers 3 -5 o > Linux-x64, and by running JCK-12 Lang and VM tests on Linux-x64. > > Thanks, Harold > From martin.doerr at sap.com Tue Jan 8 17:43:27 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 8 Jan 2019 17:43:27 +0000 Subject: RFR(S): 8216376: [PPC64] Possibly unreliable stack frame resizing in template interpreter Message-ID: Hi, we recently noticed stack corruption while testing JDK-8216060. The issue was not directly in the new code, but it didn't work with the current handling of the interpreter stack frames which is very error-prone at a few places. I'd like to improve these places. At least one of them even seems to be unreliable in the current implementation. Bug with some more background information: https://bugs.openjdk.java.net/browse/JDK-8216376 My proposal to fix it: http://cr.openjdk.java.net/~mdoerr/8216376_PPC64_frame_resizing/webrev.00/ Please review. Best regards, Martin From david.holmes at oracle.com Tue Jan 8 22:52:35 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 9 Jan 2019 08:52:35 +1000 Subject: RFR 8215901: [TESTBUG] TestCheckedEnsureLocalCapacity.java fails intermittently In-Reply-To: <4431d458-58c4-77b5-361a-a2e5920414fb@oracle.com> References: <959a3e60-281c-78b1-3956-af6a593bc656@oracle.com> <51e8fdd0-105c-b473-ecdc-97c88bb5ed1c@oracle.com> <4431d458-58c4-77b5-361a-a2e5920414fb@oracle.com> Message-ID: <874f3fba-9134-7b93-f7af-275cff9d2b39@oracle.com> Looks good. Thanks, David On 9/01/2019 2:25 am, Harold David Seigel wrote: > Hi Dan, > > Please review this updated webrev that removes the '^' from > '^WARNING:'.? I also removed the trailing blank. > > ?? http://cr.openjdk.java.net/~hseigel/bug_8215901.2/webrev/index.html > > Thanks, Harold > > On 1/8/2019 9:41 AM, Daniel D. Daugherty wrote: >> Sorry, I just took another look at the test: >> >> This line is also a problem: >> >> ? L3: ??? private static final String WARNING = "^WARNING: "; >> >> Because of the '^' anchor, you could miss an unexpected "WARNING: " in >> the "no warnings" test case. >> >> Dan >> >> >> On 1/8/19 9:38 AM, Harold David Seigel wrote: >>> Thanks Dan! >>> >>> I'll add the comment before pushing. >>> >>> Harold >>> >>> On 1/8/2019 9:36 AM, Daniel D. Daugherty wrote: >>>> On 1/8/19 9:27 AM, Harold David Seigel wrote: >>>>> Hi, >>>>> >>>>> Please review this small fix for JDK-8215901.? The test passes if >>>>> its output matches a certain pattern.? The fix, suggested by Dan, >>>>> changes the pattern to not require it to be at the beginning of a >>>>> line. >>>>> >>>>> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8215901/webrev/ >>>> >>>> test/hotspot/jtreg/runtime/jni/checked/TestCheckedEnsureLocalCapacity.java >>>> >>>> ??? Perhaps a comment above the variable: >>>> >>>> ??? // Not anchored to the beginning of the line to allow match with >>>> interleaved output. >>>> >>>> Thumbs up. Your call on whether to add the comment or something like >>>> it. >>>> Don't need to see another webrev. >>>> >>>> Dan >>>> >>>> >>>>> >>>>> JBS Bug:? https://bugs.openjdk.java.net/browse/JDK-8215901 >>>>> >>>>> The fix was tested by running the test over 600 times on multiple >>>>> platforms. >>>>> >>>>> Thanks, Harold >>>>> >>>> >> From harold.seigel at oracle.com Wed Jan 9 12:42:09 2019 From: harold.seigel at oracle.com (Harold David Seigel) Date: Wed, 9 Jan 2019 07:42:09 -0500 Subject: RFR 8215901: [TESTBUG] TestCheckedEnsureLocalCapacity.java fails intermittently In-Reply-To: <874f3fba-9134-7b93-f7af-275cff9d2b39@oracle.com> References: <959a3e60-281c-78b1-3956-af6a593bc656@oracle.com> <51e8fdd0-105c-b473-ecdc-97c88bb5ed1c@oracle.com> <4431d458-58c4-77b5-361a-a2e5920414fb@oracle.com> <874f3fba-9134-7b93-f7af-275cff9d2b39@oracle.com> Message-ID: <2ff8e046-d0e0-b7aa-9bb2-28d89c61ece5@oracle.com> Thanks David! Harold On 1/8/2019 5:52 PM, David Holmes wrote: > Looks good. > > Thanks, > David > > On 9/01/2019 2:25 am, Harold David Seigel wrote: >> Hi Dan, >> >> Please review this updated webrev that removes the '^' from >> '^WARNING:'.? I also removed the trailing blank. >> >> http://cr.openjdk.java.net/~hseigel/bug_8215901.2/webrev/index.html >> >> Thanks, Harold >> >> On 1/8/2019 9:41 AM, Daniel D. Daugherty wrote: >>> Sorry, I just took another look at the test: >>> >>> This line is also a problem: >>> >>> ? L3: ??? private static final String WARNING = "^WARNING: "; >>> >>> Because of the '^' anchor, you could miss an unexpected "WARNING: " in >>> the "no warnings" test case. >>> >>> Dan >>> >>> >>> On 1/8/19 9:38 AM, Harold David Seigel wrote: >>>> Thanks Dan! >>>> >>>> I'll add the comment before pushing. >>>> >>>> Harold >>>> >>>> On 1/8/2019 9:36 AM, Daniel D. Daugherty wrote: >>>>> On 1/8/19 9:27 AM, Harold David Seigel wrote: >>>>>> Hi, >>>>>> >>>>>> Please review this small fix for JDK-8215901.? The test passes if >>>>>> its output matches a certain pattern.? The fix, suggested by Dan, >>>>>> changes the pattern to not require it to be at the beginning of a >>>>>> line. >>>>>> >>>>>> Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8215901/webrev/ >>>>> >>>>> test/hotspot/jtreg/runtime/jni/checked/TestCheckedEnsureLocalCapacity.java >>>>> >>>>> ??? Perhaps a comment above the variable: >>>>> >>>>> ??? // Not anchored to the beginning of the line to allow match >>>>> with interleaved output. >>>>> >>>>> Thumbs up. Your call on whether to add the comment or something >>>>> like it. >>>>> Don't need to see another webrev. >>>>> >>>>> Dan >>>>> >>>>> >>>>>> >>>>>> JBS Bug: https://bugs.openjdk.java.net/browse/JDK-8215901 >>>>>> >>>>>> The fix was tested by running the test over 600 times on multiple >>>>>> platforms. >>>>>> >>>>>> Thanks, Harold >>>>>> >>>>> >>> From goetz.lindenmaier at sap.com Wed Jan 9 14:36:46 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 9 Jan 2019 14:36:46 +0000 Subject: RFR(S): 8216376: [PPC64] Possibly unreliable stack frame resizing in template interpreter In-Reply-To: References: Message-ID: Hi Martin, I had a look at your change. To me, it looks correct, and I also understand that it makes the frame resizing more stable. On the other hand, it adds dependent instructions ld/st to each call, where before just a register was moved. This might eat up some of the performance benefits of the frame resizing. As the backlink is checked in assertions, do you really think this is worth while? Shouldn't we just harden the assertions if necessary? Best regards, Goetz. > -----Original Message----- > From: Doerr, Martin > Sent: Dienstag, 8. Januar 2019 18:43 > To: hotspot-runtime-dev at openjdk.java.net; Gustavo Romero > ; Lindenmaier, Goetz > > Subject: RFR(S): 8216376: [PPC64] Possibly unreliable stack frame resizing in > template interpreter > > Hi, > > > > we recently noticed stack corruption while testing JDK-8216060. The issue > was not directly in the new code, but it didn't work with the current handling > of the interpreter stack frames which is very error-prone at a few places. > > I'd like to improve these places. At least one of them even seems to be > unreliable in the current implementation. > > > > Bug with some more background information: > > https://bugs.openjdk.java.net/browse/JDK-8216376 > > > > My proposal to fix it: > > http://cr.openjdk.java.net/~mdoerr/8216376_PPC64_frame_resizing/webrev > .00/ > > > > Please review. > > > > Best regards, > > Martin > > From martin.doerr at sap.com Wed Jan 9 14:50:22 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 9 Jan 2019 14:50:22 +0000 Subject: RFR(S): 8216376: [PPC64] Possibly unreliable stack frame resizing in template interpreter In-Reply-To: References: Message-ID: <394381c440f64d8da76d7edd82415978@sap.com> Hi G?tz, I don't think it has a measurable impact on interpreter performance. Especially not for out-of-order CPUs. The additional ld/st is only used once for each special interpreter entry. The PPC64 ABI only specifies that 288 bytes below SP are preserved (e.g. by interrupt handler). How else should we ensure that the backlink is not overwritten? I think an assertion is not appropriate. We should better comply with the ABI. Best regards, Martin -----Original Message----- From: Lindenmaier, Goetz Sent: Mittwoch, 9. Januar 2019 15:37 To: Doerr, Martin ; hotspot-runtime-dev at openjdk.java.net; Gustavo Romero Subject: RE: RFR(S): 8216376: [PPC64] Possibly unreliable stack frame resizing in template interpreter Hi Martin, I had a look at your change. To me, it looks correct, and I also understand that it makes the frame resizing more stable. On the other hand, it adds dependent instructions ld/st to each call, where before just a register was moved. This might eat up some of the performance benefits of the frame resizing. As the backlink is checked in assertions, do you really think this is worth while? Shouldn't we just harden the assertions if necessary? Best regards, Goetz. > -----Original Message----- > From: Doerr, Martin > Sent: Dienstag, 8. Januar 2019 18:43 > To: hotspot-runtime-dev at openjdk.java.net; Gustavo Romero > ; Lindenmaier, Goetz > > Subject: RFR(S): 8216376: [PPC64] Possibly unreliable stack frame resizing in > template interpreter > > Hi, > > > > we recently noticed stack corruption while testing JDK-8216060. The issue > was not directly in the new code, but it didn't work with the current handling > of the interpreter stack frames which is very error-prone at a few places. > > I'd like to improve these places. At least one of them even seems to be > unreliable in the current implementation. > > > > Bug with some more background information: > > https://bugs.openjdk.java.net/browse/JDK-8216376 > > > > My proposal to fix it: > > http://cr.openjdk.java.net/~mdoerr/8216376_PPC64_frame_resizing/webrev > .00/ > > > > Please review. > > > > Best regards, > > Martin > > From goetz.lindenmaier at sap.com Wed Jan 9 14:52:27 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 9 Jan 2019 14:52:27 +0000 Subject: RFR(S): 8216376: [PPC64] Possibly unreliable stack frame resizing in template interpreter In-Reply-To: <394381c440f64d8da76d7edd82415978@sap.com> References: <394381c440f64d8da76d7edd82415978@sap.com> Message-ID: <2fc87675893c4b048f2ac0b0cde9f197@sap.com> OK, I understand. Reviewed. Best regards, Goetz. > -----Original Message----- > From: Doerr, Martin > Sent: Mittwoch, 9. Januar 2019 15:50 > To: Lindenmaier, Goetz ; hotspot-runtime- > dev at openjdk.java.net; Gustavo Romero > Subject: RE: RFR(S): 8216376: [PPC64] Possibly unreliable stack frame resizing > in template interpreter > > Hi G?tz, > > I don't think it has a measurable impact on interpreter performance. > Especially not for out-of-order CPUs. The additional ld/st is only used once > for each special interpreter entry. > > The PPC64 ABI only specifies that 288 bytes below SP are preserved (e.g. by > interrupt handler). How else should we ensure that the backlink is not > overwritten? > I think an assertion is not appropriate. We should better comply with the > ABI. > > Best regards, > Martin > > > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Mittwoch, 9. Januar 2019 15:37 > To: Doerr, Martin ; hotspot-runtime- > dev at openjdk.java.net; Gustavo Romero > Subject: RE: RFR(S): 8216376: [PPC64] Possibly unreliable stack frame resizing > in template interpreter > > Hi Martin, > > I had a look at your change. > To me, it looks correct, and I also understand that it makes the > frame resizing more stable. > > On the other hand, it adds dependent instructions ld/st to > each call, where before just a register was moved. > This might eat up some of the performance benefits of the > frame resizing. As the backlink is checked in assertions, > do you really think this is worth while? Shouldn't we just > harden the assertions if necessary? > > Best regards, > Goetz. > > > > > -----Original Message----- > > From: Doerr, Martin > > Sent: Dienstag, 8. Januar 2019 18:43 > > To: hotspot-runtime-dev at openjdk.java.net; Gustavo Romero > > ; Lindenmaier, Goetz > > > > Subject: RFR(S): 8216376: [PPC64] Possibly unreliable stack frame resizing in > > template interpreter > > > > Hi, > > > > > > > > we recently noticed stack corruption while testing JDK-8216060. The issue > > was not directly in the new code, but it didn't work with the current > handling > > of the interpreter stack frames which is very error-prone at a few places. > > > > I'd like to improve these places. At least one of them even seems to be > > unreliable in the current implementation. > > > > > > > > Bug with some more background information: > > > > https://bugs.openjdk.java.net/browse/JDK-8216376 > > > > > > > > My proposal to fix it: > > > > > http://cr.openjdk.java.net/~mdoerr/8216376_PPC64_frame_resizing/webrev > > .00/ > > > > > > > > Please review. > > > > > > > > Best regards, > > > > Martin > > > > From martin.doerr at sap.com Wed Jan 9 16:20:35 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 9 Jan 2019 16:20:35 +0000 Subject: RFR(S): 8216376: [PPC64] Possibly unreliable stack frame resizing in template interpreter In-Reply-To: <2fc87675893c4b048f2ac0b0cde9f197@sap.com> References: <394381c440f64d8da76d7edd82415978@sap.com> <2fc87675893c4b048f2ac0b0cde9f197@sap.com> Message-ID: <2f7fcd62091e46e98d53e6eadae49d60@sap.com> Hi G?tz, thanks for the review. Best regards, Martin -----Original Message----- From: Lindenmaier, Goetz Sent: Mittwoch, 9. Januar 2019 15:52 To: Doerr, Martin ; hotspot-runtime-dev at openjdk.java.net; Gustavo Romero Subject: RE: RFR(S): 8216376: [PPC64] Possibly unreliable stack frame resizing in template interpreter OK, I understand. Reviewed. Best regards, Goetz. > -----Original Message----- > From: Doerr, Martin > Sent: Mittwoch, 9. Januar 2019 15:50 > To: Lindenmaier, Goetz ; hotspot-runtime- > dev at openjdk.java.net; Gustavo Romero > Subject: RE: RFR(S): 8216376: [PPC64] Possibly unreliable stack frame resizing > in template interpreter > > Hi G?tz, > > I don't think it has a measurable impact on interpreter performance. > Especially not for out-of-order CPUs. The additional ld/st is only used once > for each special interpreter entry. > > The PPC64 ABI only specifies that 288 bytes below SP are preserved (e.g. by > interrupt handler). How else should we ensure that the backlink is not > overwritten? > I think an assertion is not appropriate. We should better comply with the > ABI. > > Best regards, > Martin > > > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Mittwoch, 9. Januar 2019 15:37 > To: Doerr, Martin ; hotspot-runtime- > dev at openjdk.java.net; Gustavo Romero > Subject: RE: RFR(S): 8216376: [PPC64] Possibly unreliable stack frame resizing > in template interpreter > > Hi Martin, > > I had a look at your change. > To me, it looks correct, and I also understand that it makes the > frame resizing more stable. > > On the other hand, it adds dependent instructions ld/st to > each call, where before just a register was moved. > This might eat up some of the performance benefits of the > frame resizing. As the backlink is checked in assertions, > do you really think this is worth while? Shouldn't we just > harden the assertions if necessary? > > Best regards, > Goetz. > > > > > -----Original Message----- > > From: Doerr, Martin > > Sent: Dienstag, 8. Januar 2019 18:43 > > To: hotspot-runtime-dev at openjdk.java.net; Gustavo Romero > > ; Lindenmaier, Goetz > > > > Subject: RFR(S): 8216376: [PPC64] Possibly unreliable stack frame resizing in > > template interpreter > > > > Hi, > > > > > > > > we recently noticed stack corruption while testing JDK-8216060. The issue > > was not directly in the new code, but it didn't work with the current > handling > > of the interpreter stack frames which is very error-prone at a few places. > > > > I'd like to improve these places. At least one of them even seems to be > > unreliable in the current implementation. > > > > > > > > Bug with some more background information: > > > > https://bugs.openjdk.java.net/browse/JDK-8216376 > > > > > > > > My proposal to fix it: > > > > > http://cr.openjdk.java.net/~mdoerr/8216376_PPC64_frame_resizing/webrev > > .00/ > > > > > > > > Please review. > > > > > > > > Best regards, > > > > Martin > > > > From claes.redestad at oracle.com Wed Jan 9 17:45:49 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 9 Jan 2019 18:45:49 +0100 Subject: RFR: 8216428: Remove IgnoreLibthreadGPFault Message-ID: Hi, remove the develop flag IgnoreLibthreadGPFault, which guards a now-defunct workaround to a Solaris IA32 bug. Bug: https://bugs.openjdk.java.net/browse/JDK-8216428 Webrev: http://cr.openjdk.java.net/~redestad/8216428/open.00/ Thanks! /Claes From gerard.ziemski at oracle.com Wed Jan 9 19:48:03 2019 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Wed, 9 Jan 2019 13:48:03 -0600 Subject: RFR 8215155: Remove get_insert() from concurrent hashtable and gtests In-Reply-To: References: <6b738e53-3468-8ad1-23f9-ce2a023b977b@oracle.com> Message-ID: <67B4490D-EE24-4DFE-9898-3ED72DADA21A@oracle.com> hi Robbin, Coleen, I apologize, but in my haste to try to push this issue before I went off for holiday break (which I failed), I missed another issue, so I?d like to ask you to review this one last small change from webrev2: line 129 in jdk/test/hotspot/gtest/utilities/test_concurrentHashtable.cpp should be 129 cht_insert_helper(thr, cht, val); instead of 129 cht_get_helper(thr, cht, val); bug id: https://bugs.openjdk.java.net/browse/JDK-8215155 webrev: http://cr.openjdk.java.net/~gziemski/8215155_rev3 testing: Passed Mach hs_tier1,2,3 thank you > On Dec 13, 2018, at 9:48 AM, Gerard Ziemski wrote: > >> >> On Dec 13, 2018, at 8:58 AM, Gerard Ziemski wrote: >> >> >>> On Dec 12, 2018, at 6:30 PM, coleen.phillimore at oracle.com wrote: >>> >>> >>> This looks good to me. >>> >>> On 12/12/18 3:01 PM, Gerard Ziemski wrote: >>>> Hi all, >>>> >>>> Please review this enhancement followup to JDK-8214310 and JDK-8213791 >>>> >>>> Here we redo the relevant gtest tests to use get(),insert() and are now free to remove the get_insert() API from the concurrent hash table implementation. >>>> >>>> bug id: https://bugs.openjdk.java.net/browse/JDK-8215155 >>>> webrev: http://cr.openjdk.java.net/~gziemski/8215155_rev1 >>>> Testing: Passed Mach hs_tier1, another Mach hs_tier1,2,3,4,5,6 in progress? >>>> >>>> P.S. I?d like to push this into JDK12 if there is no contention about this fix? >>> >>> It seems pretty straightforward. I'm fine with your pushing this to 12 but the deadline is fast approaching and I think you should have another reviewer. >> >> Thank you for the review Coleen! >> >> As this is a test related change plus trivial removal of unused API, normally I?d mark it as trivial, but I agree with you - a second reviewer here would be most appreciated. > > I just discovered that I had an assert reversed in my webrev1 fix - in the file jdk/test/hotspot/gtest/utilities/test_concurrentHashtable.cpp, line 108: > > EXPECT_EQ(cht->insert(thr, stl, val), false) << "Inserting an unique value failed.?; > > should be: > > EXPECT_EQ(cht->insert(thr, stl, val), true) << "Inserting an unique value failed.?; > > I fixed it and posted http://cr.openjdk.java.net/~gziemski/8215155_rev2 > > I fired another Mach5 test (why wasn?t it caught?), but now I feel a bit less confident about pushing it into jdk12? > > > cheers From gromero at linux.vnet.ibm.com Wed Jan 9 20:23:19 2019 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Wed, 9 Jan 2019 18:23:19 -0200 Subject: RFR(S): 8216376: [PPC64] Possibly unreliable stack frame resizing in template interpreter In-Reply-To: References: Message-ID: Hi Martin, On 01/08/2019 03:43 PM, Doerr, Martin wrote: > we recently noticed stack corruption while testing JDK-8216060. The issue was not directly in the new code, but it didn?t work with the current handling of the interpreter stack frames which is very error-prone at a few places. > I?d like to improve these places. At least one of them even seems to be unreliable in the current implementation. > Bug with some more background information: > > https://bugs.openjdk.java.net/browse/JDK-8216376 > > My proposal to fix it: > http://cr.openjdk.java.net/~mdoerr/8216376_PPC64_frame_resizing/webrev.00/ I've tested this change with JDK-8216060 on top of it for both release and fastdebug builds and all tests passed fine. To the best of my knowledge it looks correct and I think that restoring the SP using resize_frame_absolute after the generated code looks more consistent than the SP cut back before it and even makes the code easier to follow/understand. Thank you. Best regards, Gustavo From david.holmes at oracle.com Wed Jan 9 21:40:29 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Jan 2019 07:40:29 +1000 Subject: RFR: 8216428: Remove IgnoreLibthreadGPFault In-Reply-To: References: Message-ID: <3ad72627-db08-930c-74b5-05b699bf096d@oracle.com> Looks good. I've never noticed this one before. Thanks, David On 10/01/2019 3:45 am, Claes Redestad wrote: > Hi, > > remove the develop flag IgnoreLibthreadGPFault, which guards a > now-defunct workaround to a Solaris IA32 bug. > > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8216428 > Webrev: http://cr.openjdk.java.net/~redestad/8216428/open.00/ > > Thanks! > > /Claes From jiangli.zhou at oracle.com Wed Jan 9 22:15:54 2019 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 9 Jan 2019 14:15:54 -0800 Subject: [12] RFR: 8214827: Incorrect call ClassLoaders.toFileURL("jrt:/java.compiler") Message-ID: <958a0930-3b54-94f1-9c22-e58e50faeaac@oracle.com> Please review the bug fix for SystemDictionaryShared::get_shared_protection_domain(). When jrt:/ location is given, a null URL (due to the error in ClassLoaders.toFileURL) is used for the CodeSource, which results a wrong ProtectionDomain being used for the archived app/platform class from the runtime image. The granted permission is minimum in that case. This turns out to be an issue that's hidden for a long time. The JimageClassProtDomain.java test has been outdated and fails to detect the issue (I'm the guilt one). Please see the comments in the bug for more details. Thanks Martin for finding the issue, and David, Alan and Mandy for discussions. webrev: http://cr.openjdk.java.net/~jiangli/8214827/webrev.01/ bug: https://bugs.openjdk.java.net/browse/JDK-8214827 Tested with appcds tests locally. Tested tier1-2. Tier3 is still in progress. Thanks, Jiangli From claes.redestad at oracle.com Wed Jan 9 22:59:59 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Wed, 9 Jan 2019 23:59:59 +0100 Subject: RFR: 8216428: Remove IgnoreLibthreadGPFault In-Reply-To: <3ad72627-db08-930c-74b5-05b699bf096d@oracle.com> References: <3ad72627-db08-930c-74b5-05b699bf096d@oracle.com> Message-ID: <043e74a4-c9dd-8347-257e-ecee15475344@oracle.com> On 2019-01-09 22:40, David Holmes wrote: > Looks good. Thanks, David. > > I've never noticed this one before. Me neither. And now we can forget about it. :-) /Claes From calvin.cheung at oracle.com Wed Jan 9 23:01:01 2019 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Wed, 09 Jan 2019 15:01:01 -0800 Subject: [12] RFR: 8214827: Incorrect call ClassLoaders.toFileURL("jrt:/java.compiler") In-Reply-To: <958a0930-3b54-94f1-9c22-e58e50faeaac@oracle.com> References: <958a0930-3b54-94f1-9c22-e58e50faeaac@oracle.com> Message-ID: <5C367D2D.7060601@oracle.com> Hi Jiangli, 1) systemDictionaryShared.cpp: Should all those CHECK_(protection_domain) be simply CHECK_NH? In get_shared_jar_manifest() of the same file, CHECK_NH is used. But in other functions, CHECK_(something) is being used. Not sure which one is the preferred way? 2) ProtectionDomain.java: 58 TestCommon.run("-cp", appJar, "ProtDomain").assertNormalExit(); You can also check the output by doing: TestCommon.run("-cp", appJar, "ProtDomain").assertNormalExit("Protection Domains match"); Similarly for line 61. 65 TestCommon.run("-cp", appJar, "JimageClassProtDomain").assertNormalExit(); You can check the output "shouldNotContain" by doing: TestCommon.run("-cp", appJar, "JimageClassProtDomain") .assertNormalExit(output -> output.shouldNotContain("Failed: Protection Domains do not match"); The remaining 3 files look good. thanks, Calvin On 1/9/19, 2:15 PM, Jiangli Zhou wrote: > Please review the bug fix for > SystemDictionaryShared::get_shared_protection_domain(). When > jrt:/ location is given, a null URL (due to the error in > ClassLoaders.toFileURL) is used for the CodeSource, which results a > wrong ProtectionDomain being used for the archived app/platform class > from the runtime image. The granted permission is minimum in that case. > > This turns out to be an issue that's hidden for a long time. The > JimageClassProtDomain.java test has been outdated and fails to detect > the issue (I'm the guilt one). Please see the comments in the bug for > more details. Thanks Martin for finding the issue, and David, Alan and > Mandy for discussions. > > webrev: http://cr.openjdk.java.net/~jiangli/8214827/webrev.01/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8214827 > > Tested with appcds tests locally. Tested tier1-2. Tier3 is still in > progress. > > Thanks, > > Jiangli > From jiangli.zhou at oracle.com Thu Jan 10 00:32:06 2019 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 9 Jan 2019 16:32:06 -0800 Subject: [12] RFR: 8214827: Incorrect call ClassLoaders.toFileURL("jrt:/java.compiler") In-Reply-To: <5C367D2D.7060601@oracle.com> References: <958a0930-3b54-94f1-9c22-e58e50faeaac@oracle.com> <5C367D2D.7060601@oracle.com> Message-ID: Hi Calvin, Thanks for the review! On 1/9/19 3:01 PM, Calvin Cheung wrote: > Hi Jiangli, > > 1) systemDictionaryShared.cpp: > > Should all those CHECK_(protection_domain) be simply CHECK_NH? > In get_shared_jar_manifest() of the same file, CHECK_NH is used. But > in other functions, CHECK_(something) is being used. > Not sure which one is the preferred way? I'm not sure which is the preferred way either. I'm leaving it as is and also checking with Coleen... > > 2) ProtectionDomain.java: > > 58???? TestCommon.run("-cp", appJar, "ProtDomain").assertNormalExit(); > > ??? You can also check the output by doing: > ??? TestCommon.run("-cp", appJar, > "ProtDomain").assertNormalExit("Protection Domains match"); > ??? Similarly for line 61. > > 65???? TestCommon.run("-cp", appJar, > "JimageClassProtDomain").assertNormalExit(); > > ???? You can check the output "shouldNotContain" by doing: > ???? TestCommon.run("-cp", appJar, "JimageClassProtDomain") > ???????? .assertNormalExit(output -> output.shouldNotContain("Failed: > Protection Domains do not match"); I've updated the webrev and incorporated with your suggestions: http://cr.openjdk.java.net/~jiangli/8214827/webrev.02/. > > The remaining 3 files look good. Thanks! Jiangli > > thanks, > Calvin > > On 1/9/19, 2:15 PM, Jiangli Zhou wrote: >> Please review the bug fix for >> SystemDictionaryShared::get_shared_protection_domain(). When >> jrt:/ location is given, a null URL (due to the error in >> ClassLoaders.toFileURL) is used for the CodeSource, which results a >> wrong ProtectionDomain being used for the archived app/platform class >> from the runtime image. The granted permission is minimum in that case. >> >> This turns out to be an issue that's hidden for a long time. The >> JimageClassProtDomain.java test has been outdated and fails to detect >> the issue (I'm the guilt one). Please see the comments in the bug for >> more details. Thanks Martin for finding the issue, and David, Alan >> and Mandy for discussions. >> >> webrev: http://cr.openjdk.java.net/~jiangli/8214827/webrev.01/ >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8214827 >> >> Tested with appcds tests locally. Tested tier1-2. Tier3 is still in >> progress. >> >> Thanks, >> >> Jiangli >> From ioi.lam at oracle.com Thu Jan 10 00:47:47 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 9 Jan 2019 16:47:47 -0800 Subject: [12] RFR: 8214827: Incorrect call ClassLoaders.toFileURL("jrt:/java.compiler") In-Reply-To: References: <958a0930-3b54-94f1-9c22-e58e50faeaac@oracle.com> <5C367D2D.7060601@oracle.com> Message-ID: <558869bb-bff2-dcb9-e7be-6ebb5b7ad413@oracle.com> On 1/9/19 4:32 PM, Jiangli Zhou wrote: > Hi Calvin, > > Thanks for the review! > > > On 1/9/19 3:01 PM, Calvin Cheung wrote: >> Hi Jiangli, >> >> 1) systemDictionaryShared.cpp: >> >> Should all those CHECK_(protection_domain) be simply CHECK_NH? >> In get_shared_jar_manifest() of the same file, CHECK_NH is used. But >> in other functions, CHECK_(something) is being used. >> Not sure which one is the preferred way? > > I'm not sure which is the preferred way either. I'm leaving it as is > and also checking with Coleen... CHECK_(protection_domain)? depends on the fact that protection_domain is NULL at the point of the CHECK_. This could lead to maintenance issues down the road if someone decides to initialize protection_domain earlier. I think CHECK_NH is better. Easier to read and less dependencies. The rest of the changes and Calvin's suggestions look good to me. Thanks - Ioi >> >> 2) ProtectionDomain.java: >> >> 58???? TestCommon.run("-cp", appJar, "ProtDomain").assertNormalExit(); >> >> ??? You can also check the output by doing: >> ??? TestCommon.run("-cp", appJar, >> "ProtDomain").assertNormalExit("Protection Domains match"); >> ??? Similarly for line 61. >> >> 65???? TestCommon.run("-cp", appJar, >> "JimageClassProtDomain").assertNormalExit(); >> >> ???? You can check the output "shouldNotContain" by doing: >> ???? TestCommon.run("-cp", appJar, "JimageClassProtDomain") >> ???????? .assertNormalExit(output -> output.shouldNotContain("Failed: >> Protection Domains do not match"); > > I've updated the webrev and incorporated with your suggestions: > http://cr.openjdk.java.net/~jiangli/8214827/webrev.02/. >> >> The remaining 3 files look good. > > Thanks! > Jiangli >> >> thanks, >> Calvin >> >> On 1/9/19, 2:15 PM, Jiangli Zhou wrote: >>> Please review the bug fix for >>> SystemDictionaryShared::get_shared_protection_domain(). When >>> jrt:/ location is given, a null URL (due to the error in >>> ClassLoaders.toFileURL) is used for the CodeSource, which results a >>> wrong ProtectionDomain being used for the archived app/platform >>> class from the runtime image. The granted permission is minimum in >>> that case. >>> >>> This turns out to be an issue that's hidden for a long time. The >>> JimageClassProtDomain.java test has been outdated and fails to >>> detect the issue (I'm the guilt one). Please see the comments in the >>> bug for more details. Thanks Martin for finding the issue, and >>> David, Alan and Mandy for discussions. >>> >>> webrev: http://cr.openjdk.java.net/~jiangli/8214827/webrev.01/ >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8214827 >>> >>> Tested with appcds tests locally. Tested tier1-2. Tier3 is still in >>> progress. >>> >>> Thanks, >>> >>> Jiangli >>> > From david.holmes at oracle.com Thu Jan 10 01:13:02 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Jan 2019 11:13:02 +1000 Subject: [12] RFR: 8214827: Incorrect call ClassLoaders.toFileURL("jrt:/java.compiler") In-Reply-To: <558869bb-bff2-dcb9-e7be-6ebb5b7ad413@oracle.com> References: <958a0930-3b54-94f1-9c22-e58e50faeaac@oracle.com> <5C367D2D.7060601@oracle.com> <558869bb-bff2-dcb9-e7be-6ebb5b7ad413@oracle.com> Message-ID: <8bee2b3d-f9d7-7405-0f25-5ec81f2a100d@oracle.com> On 10/01/2019 10:47 am, Ioi Lam wrote: > > On 1/9/19 4:32 PM, Jiangli Zhou wrote: >> Hi Calvin, >> >> Thanks for the review! >> >> >> On 1/9/19 3:01 PM, Calvin Cheung wrote: >>> Hi Jiangli, >>> >>> 1) systemDictionaryShared.cpp: >>> >>> Should all those CHECK_(protection_domain) be simply CHECK_NH? >>> In get_shared_jar_manifest() of the same file, CHECK_NH is used. But >>> in other functions, CHECK_(something) is being used. >>> Not sure which one is the preferred way? >> >> I'm not sure which is the preferred way either. I'm leaving it as is >> and also checking with Coleen... > > CHECK_(protection_domain)? depends on the fact that protection_domain is > NULL at the point of the CHECK_. This could lead to maintenance issues > down the road if someone decides to initialize protection_domain earlier. I think this is fairly common practice though. We often define the "result" variable at the start of a method with an "error" value and return the result on error. David ----- > > I think CHECK_NH is better. Easier to read and less dependencies. > > The rest of the changes and Calvin's suggestions look good to me. > > Thanks > > - Ioi > > > >>> >>> 2) ProtectionDomain.java: >>> >>> 58???? TestCommon.run("-cp", appJar, "ProtDomain").assertNormalExit(); >>> >>> ??? You can also check the output by doing: >>> ??? TestCommon.run("-cp", appJar, >>> "ProtDomain").assertNormalExit("Protection Domains match"); >>> ??? Similarly for line 61. >>> >>> 65???? TestCommon.run("-cp", appJar, >>> "JimageClassProtDomain").assertNormalExit(); >>> >>> ???? You can check the output "shouldNotContain" by doing: >>> ???? TestCommon.run("-cp", appJar, "JimageClassProtDomain") >>> ???????? .assertNormalExit(output -> output.shouldNotContain("Failed: >>> Protection Domains do not match"); >> >> I've updated the webrev and incorporated with your suggestions: >> http://cr.openjdk.java.net/~jiangli/8214827/webrev.02/. >>> >>> The remaining 3 files look good. >> >> Thanks! >> Jiangli >>> >>> thanks, >>> Calvin >>> >>> On 1/9/19, 2:15 PM, Jiangli Zhou wrote: >>>> Please review the bug fix for >>>> SystemDictionaryShared::get_shared_protection_domain(). When >>>> jrt:/ location is given, a null URL (due to the error in >>>> ClassLoaders.toFileURL) is used for the CodeSource, which results a >>>> wrong ProtectionDomain being used for the archived app/platform >>>> class from the runtime image. The granted permission is minimum in >>>> that case. >>>> >>>> This turns out to be an issue that's hidden for a long time. The >>>> JimageClassProtDomain.java test has been outdated and fails to >>>> detect the issue (I'm the guilt one). Please see the comments in the >>>> bug for more details. Thanks Martin for finding the issue, and >>>> David, Alan and Mandy for discussions. >>>> >>>> webrev: http://cr.openjdk.java.net/~jiangli/8214827/webrev.01/ >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8214827 >>>> >>>> Tested with appcds tests locally. Tested tier1-2. Tier3 is still in >>>> progress. >>>> >>>> Thanks, >>>> >>>> Jiangli >>>> >> From jiangli.zhou at oracle.com Thu Jan 10 01:50:56 2019 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 9 Jan 2019 17:50:56 -0800 Subject: [12] RFR: 8214827: Incorrect call ClassLoaders.toFileURL("jrt:/java.compiler") In-Reply-To: <8bee2b3d-f9d7-7405-0f25-5ec81f2a100d@oracle.com> References: <958a0930-3b54-94f1-9c22-e58e50faeaac@oracle.com> <5C367D2D.7060601@oracle.com> <558869bb-bff2-dcb9-e7be-6ebb5b7ad413@oracle.com> <8bee2b3d-f9d7-7405-0f25-5ec81f2a100d@oracle.com> Message-ID: <7f4cbd89-a18c-60c5-616a-1c12d814d169@oracle.com> Hi Ioi and David, Thanks for the comments! On 1/9/19 5:13 PM, David Holmes wrote: > On 10/01/2019 10:47 am, Ioi Lam wrote: >> >> On 1/9/19 4:32 PM, Jiangli Zhou wrote: >>> Hi Calvin, >>> >>> Thanks for the review! >>> >>> >>> On 1/9/19 3:01 PM, Calvin Cheung wrote: >>>> Hi Jiangli, >>>> >>>> 1) systemDictionaryShared.cpp: >>>> >>>> Should all those CHECK_(protection_domain) be simply CHECK_NH? >>>> In get_shared_jar_manifest() of the same file, CHECK_NH is used. >>>> But in other functions, CHECK_(something) is being used. >>>> Not sure which one is the preferred way? >>> >>> I'm not sure which is the preferred way either. I'm leaving it as is >>> and also checking with Coleen... >> >> CHECK_(protection_domain)? depends on the fact that protection_domain >> is NULL at the point of the CHECK_. This could lead to maintenance >> issues down the road if someone decides to initialize >> protection_domain earlier. > > I think this is fairly common practice though. We often define the > "result" variable at the start of a method with an "error" value and > return the result on error. I agree with David and it seems to be a common practice. However, I don't have a strong preference on the usage of the CHECK_ macros. Based on the feedback from Coleen, Calvin and Ioi, I updated the webrev to use the CHECK_NH in SystemDictionaryShared::get_shared_protection_domain(). The rest of the usages in the file are not changed in this changeset to minimize risks. Here is the updated webrev: http://cr.openjdk.java.net/~jiangli/8214827/webrev.03/src/hotspot/share/classfile/systemDictionaryShared.cpp.frames.html Full webrev: http://cr.openjdk.java.net/~jiangli/8214827/webrev.03/ Thanks! Jiangli > > David > ----- > >> >> I think CHECK_NH is better. Easier to read and less dependencies. >> >> The rest of the changes and Calvin's suggestions look good to me. >> >> Thanks >> >> - Ioi >> >> >> >>>> >>>> 2) ProtectionDomain.java: >>>> >>>> 58???? TestCommon.run("-cp", appJar, "ProtDomain").assertNormalExit(); >>>> >>>> ??? You can also check the output by doing: >>>> ??? TestCommon.run("-cp", appJar, >>>> "ProtDomain").assertNormalExit("Protection Domains match"); >>>> ??? Similarly for line 61. >>>> >>>> 65???? TestCommon.run("-cp", appJar, >>>> "JimageClassProtDomain").assertNormalExit(); >>>> >>>> ???? You can check the output "shouldNotContain" by doing: >>>> ???? TestCommon.run("-cp", appJar, "JimageClassProtDomain") >>>> ???????? .assertNormalExit(output -> >>>> output.shouldNotContain("Failed: Protection Domains do not match"); >>> >>> I've updated the webrev and incorporated with your suggestions: >>> http://cr.openjdk.java.net/~jiangli/8214827/webrev.02/. >>>> >>>> The remaining 3 files look good. >>> >>> Thanks! >>> Jiangli >>>> >>>> thanks, >>>> Calvin >>>> >>>> On 1/9/19, 2:15 PM, Jiangli Zhou wrote: >>>>> Please review the bug fix for >>>>> SystemDictionaryShared::get_shared_protection_domain(). When >>>>> jrt:/ location is given, a null URL (due to the error in >>>>> ClassLoaders.toFileURL) is used for the CodeSource, which results >>>>> a wrong ProtectionDomain being used for the archived app/platform >>>>> class from the runtime image. The granted permission is minimum in >>>>> that case. >>>>> >>>>> This turns out to be an issue that's hidden for a long time. The >>>>> JimageClassProtDomain.java test has been outdated and fails to >>>>> detect the issue (I'm the guilt one). Please see the comments in >>>>> the bug for more details. Thanks Martin for finding the issue, and >>>>> David, Alan and Mandy for discussions. >>>>> >>>>> webrev: http://cr.openjdk.java.net/~jiangli/8214827/webrev.01/ >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8214827 >>>>> >>>>> Tested with appcds tests locally. Tested tier1-2. Tier3 is still >>>>> in progress. >>>>> >>>>> Thanks, >>>>> >>>>> Jiangli >>>>> >>> From calvin.cheung at oracle.com Thu Jan 10 02:25:03 2019 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Wed, 09 Jan 2019 18:25:03 -0800 Subject: [12] RFR: 8214827: Incorrect call ClassLoaders.toFileURL("jrt:/java.compiler") In-Reply-To: <7f4cbd89-a18c-60c5-616a-1c12d814d169@oracle.com> References: <958a0930-3b54-94f1-9c22-e58e50faeaac@oracle.com> <5C367D2D.7060601@oracle.com> <558869bb-bff2-dcb9-e7be-6ebb5b7ad413@oracle.com> <8bee2b3d-f9d7-7405-0f25-5ec81f2a100d@oracle.com> <7f4cbd89-a18c-60c5-616a-1c12d814d169@oracle.com> Message-ID: <5C36ACFF.2040501@oracle.com> Looks good. thanks, Calvin On 1/9/19, 5:50 PM, Jiangli Zhou wrote: > Hi Ioi and David, > > Thanks for the comments! > > > On 1/9/19 5:13 PM, David Holmes wrote: >> On 10/01/2019 10:47 am, Ioi Lam wrote: >>> >>> On 1/9/19 4:32 PM, Jiangli Zhou wrote: >>>> Hi Calvin, >>>> >>>> Thanks for the review! >>>> >>>> >>>> On 1/9/19 3:01 PM, Calvin Cheung wrote: >>>>> Hi Jiangli, >>>>> >>>>> 1) systemDictionaryShared.cpp: >>>>> >>>>> Should all those CHECK_(protection_domain) be simply CHECK_NH? >>>>> In get_shared_jar_manifest() of the same file, CHECK_NH is used. >>>>> But in other functions, CHECK_(something) is being used. >>>>> Not sure which one is the preferred way? >>>> >>>> I'm not sure which is the preferred way either. I'm leaving it as >>>> is and also checking with Coleen... >>> >>> CHECK_(protection_domain) depends on the fact that >>> protection_domain is NULL at the point of the CHECK_. This could >>> lead to maintenance issues down the road if someone decides to >>> initialize protection_domain earlier. >> >> I think this is fairly common practice though. We often define the >> "result" variable at the start of a method with an "error" value and >> return the result on error. > > I agree with David and it seems to be a common practice. However, I > don't have a strong preference on the usage of the CHECK_ macros. > Based on the feedback from Coleen, Calvin and Ioi, I updated the > webrev to use the CHECK_NH in > SystemDictionaryShared::get_shared_protection_domain(). The rest of > the usages in the file are not changed in this changeset to minimize > risks. > > Here is the updated webrev: > http://cr.openjdk.java.net/~jiangli/8214827/webrev.03/src/hotspot/share/classfile/systemDictionaryShared.cpp.frames.html > > Full webrev: http://cr.openjdk.java.net/~jiangli/8214827/webrev.03/ > > Thanks! > Jiangli >> >> David >> ----- >> >>> >>> I think CHECK_NH is better. Easier to read and less dependencies. >>> >>> The rest of the changes and Calvin's suggestions look good to me. >>> >>> Thanks >>> >>> - Ioi >>> >>> >>> >>>>> >>>>> 2) ProtectionDomain.java: >>>>> >>>>> 58 TestCommon.run("-cp", appJar, >>>>> "ProtDomain").assertNormalExit(); >>>>> >>>>> You can also check the output by doing: >>>>> TestCommon.run("-cp", appJar, >>>>> "ProtDomain").assertNormalExit("Protection Domains match"); >>>>> Similarly for line 61. >>>>> >>>>> 65 TestCommon.run("-cp", appJar, >>>>> "JimageClassProtDomain").assertNormalExit(); >>>>> >>>>> You can check the output "shouldNotContain" by doing: >>>>> TestCommon.run("-cp", appJar, "JimageClassProtDomain") >>>>> .assertNormalExit(output -> >>>>> output.shouldNotContain("Failed: Protection Domains do not match"); >>>> >>>> I've updated the webrev and incorporated with your suggestions: >>>> http://cr.openjdk.java.net/~jiangli/8214827/webrev.02/. >>>>> >>>>> The remaining 3 files look good. >>>> >>>> Thanks! >>>> Jiangli >>>>> >>>>> thanks, >>>>> Calvin >>>>> >>>>> On 1/9/19, 2:15 PM, Jiangli Zhou wrote: >>>>>> Please review the bug fix for >>>>>> SystemDictionaryShared::get_shared_protection_domain(). When >>>>>> jrt:/ location is given, a null URL (due to the error in >>>>>> ClassLoaders.toFileURL) is used for the CodeSource, which results >>>>>> a wrong ProtectionDomain being used for the archived app/platform >>>>>> class from the runtime image. The granted permission is minimum >>>>>> in that case. >>>>>> >>>>>> This turns out to be an issue that's hidden for a long time. The >>>>>> JimageClassProtDomain.java test has been outdated and fails to >>>>>> detect the issue (I'm the guilt one). Please see the comments in >>>>>> the bug for more details. Thanks Martin for finding the issue, >>>>>> and David, Alan and Mandy for discussions. >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~jiangli/8214827/webrev.01/ >>>>>> >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8214827 >>>>>> >>>>>> Tested with appcds tests locally. Tested tier1-2. Tier3 is still >>>>>> in progress. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Jiangli >>>>>> >>>> > From coleen.phillimore at oracle.com Thu Jan 10 02:35:21 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 9 Jan 2019 21:35:21 -0500 Subject: [12] RFR: 8214827: Incorrect call ClassLoaders.toFileURL("jrt:/java.compiler") In-Reply-To: <5C36ACFF.2040501@oracle.com> References: <958a0930-3b54-94f1-9c22-e58e50faeaac@oracle.com> <5C367D2D.7060601@oracle.com> <558869bb-bff2-dcb9-e7be-6ebb5b7ad413@oracle.com> <8bee2b3d-f9d7-7405-0f25-5ec81f2a100d@oracle.com> <7f4cbd89-a18c-60c5-616a-1c12d814d169@oracle.com> <5C36ACFF.2040501@oracle.com> Message-ID: <7a90457b-a491-050d-0502-9c57b511a8c1@oracle.com> http://cr.openjdk.java.net/~jiangli/8214827/webrev.03/src/hotspot/share/classfile/systemDictionaryShared.cpp.udiff.html + Handle protection_domain = Handle(THREAD, mod->shared_protection_domain()); Nit, you can write this as: + Handle protection_domain(THREAD, mod->shared_protection_domain()); Not a full review and I don't need to see another webrev. Coleen On 1/9/19 9:25 PM, Calvin Cheung wrote: > Looks good. > > thanks, > Calvin > > On 1/9/19, 5:50 PM, Jiangli Zhou wrote: >> Hi Ioi and David, >> >> Thanks for the comments! >> >> >> On 1/9/19 5:13 PM, David Holmes wrote: >>> On 10/01/2019 10:47 am, Ioi Lam wrote: >>>> >>>> On 1/9/19 4:32 PM, Jiangli Zhou wrote: >>>>> Hi Calvin, >>>>> >>>>> Thanks for the review! >>>>> >>>>> >>>>> On 1/9/19 3:01 PM, Calvin Cheung wrote: >>>>>> Hi Jiangli, >>>>>> >>>>>> 1) systemDictionaryShared.cpp: >>>>>> >>>>>> Should all those CHECK_(protection_domain) be simply CHECK_NH? >>>>>> In get_shared_jar_manifest() of the same file, CHECK_NH is used. >>>>>> But in other functions, CHECK_(something) is being used. >>>>>> Not sure which one is the preferred way? >>>>> >>>>> I'm not sure which is the preferred way either. I'm leaving it as >>>>> is and also checking with Coleen... >>>> >>>> CHECK_(protection_domain)? depends on the fact that >>>> protection_domain is NULL at the point of the CHECK_. This could >>>> lead to maintenance issues down the road if someone decides to >>>> initialize protection_domain earlier. >>> >>> I think this is fairly common practice though. We often define the >>> "result" variable at the start of a method with an "error" value and >>> return the result on error. >> >> I agree with David and it seems to be a common practice. However, I >> don't have a strong preference on the usage of the CHECK_ macros. >> Based on the feedback from Coleen, Calvin and Ioi, I updated the >> webrev to use the CHECK_NH in >> SystemDictionaryShared::get_shared_protection_domain(). The rest of >> the usages in the file are not changed in this changeset to minimize >> risks. >> >> Here is the updated webrev: >> http://cr.openjdk.java.net/~jiangli/8214827/webrev.03/src/hotspot/share/classfile/systemDictionaryShared.cpp.frames.html >> >> Full webrev: http://cr.openjdk.java.net/~jiangli/8214827/webrev.03/ >> >> Thanks! >> Jiangli >>> >>> David >>> ----- >>> >>>> >>>> I think CHECK_NH is better. Easier to read and less dependencies. >>>> >>>> The rest of the changes and Calvin's suggestions look good to me. >>>> >>>> Thanks >>>> >>>> - Ioi >>>> >>>> >>>> >>>>>> >>>>>> 2) ProtectionDomain.java: >>>>>> >>>>>> 58???? TestCommon.run("-cp", appJar, >>>>>> "ProtDomain").assertNormalExit(); >>>>>> >>>>>> ??? You can also check the output by doing: >>>>>> ??? TestCommon.run("-cp", appJar, >>>>>> "ProtDomain").assertNormalExit("Protection Domains match"); >>>>>> ??? Similarly for line 61. >>>>>> >>>>>> 65???? TestCommon.run("-cp", appJar, >>>>>> "JimageClassProtDomain").assertNormalExit(); >>>>>> >>>>>> ???? You can check the output "shouldNotContain" by doing: >>>>>> ???? TestCommon.run("-cp", appJar, "JimageClassProtDomain") >>>>>> ???????? .assertNormalExit(output -> >>>>>> output.shouldNotContain("Failed: Protection Domains do not match"); >>>>> >>>>> I've updated the webrev and incorporated with your suggestions: >>>>> http://cr.openjdk.java.net/~jiangli/8214827/webrev.02/. >>>>>> >>>>>> The remaining 3 files look good. >>>>> >>>>> Thanks! >>>>> Jiangli >>>>>> >>>>>> thanks, >>>>>> Calvin >>>>>> >>>>>> On 1/9/19, 2:15 PM, Jiangli Zhou wrote: >>>>>>> Please review the bug fix for >>>>>>> SystemDictionaryShared::get_shared_protection_domain(). When >>>>>>> jrt:/ location is given, a null URL (due to the error in >>>>>>> ClassLoaders.toFileURL) is used for the CodeSource, which >>>>>>> results a wrong ProtectionDomain being used for the archived >>>>>>> app/platform class from the runtime image. The granted >>>>>>> permission is minimum in that case. >>>>>>> >>>>>>> This turns out to be an issue that's hidden for a long time. The >>>>>>> JimageClassProtDomain.java test has been outdated and fails to >>>>>>> detect the issue (I'm the guilt one). Please see the comments in >>>>>>> the bug for more details. Thanks Martin for finding the issue, >>>>>>> and David, Alan and Mandy for discussions. >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~jiangli/8214827/webrev.01/ >>>>>>> >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8214827 >>>>>>> >>>>>>> Tested with appcds tests locally. Tested tier1-2. Tier3 is still >>>>>>> in progress. >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Jiangli >>>>>>> >>>>> >> From coleen.phillimore at oracle.com Thu Jan 10 03:08:41 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 9 Jan 2019 22:08:41 -0500 Subject: RFR 8215155: Remove get_insert() from concurrent hashtable and gtests In-Reply-To: <67B4490D-EE24-4DFE-9898-3ED72DADA21A@oracle.com> References: <6b738e53-3468-8ad1-23f9-ce2a023b977b@oracle.com> <67B4490D-EE24-4DFE-9898-3ED72DADA21A@oracle.com> Message-ID: On 1/9/19 2:48 PM, Gerard Ziemski wrote: > hi Robbin, Coleen, > > I apologize, but in my haste to try to push this issue before I went off for holiday break (which I failed), I missed another issue, so I?d like to ask you to review this one last small change from webrev2: > > line 129 in jdk/test/hotspot/gtest/utilities/test_concurrentHashtable.cpp should be > > 129 cht_insert_helper(thr, cht, val); > > instead of > > 129 cht_get_helper(thr, cht, val); Makes sense.? This looks good.? You can run the gtests locally on your machine, which is a lot faster. Coleen > > bug id: https://bugs.openjdk.java.net/browse/JDK-8215155 > webrev: http://cr.openjdk.java.net/~gziemski/8215155_rev3 > testing: Passed Mach hs_tier1,2,3 > > > thank you > >> On Dec 13, 2018, at 9:48 AM, Gerard Ziemski wrote: >> >>> On Dec 13, 2018, at 8:58 AM, Gerard Ziemski wrote: >>> >>> >>>> On Dec 12, 2018, at 6:30 PM, coleen.phillimore at oracle.com wrote: >>>> >>>> >>>> This looks good to me. >>>> >>>> On 12/12/18 3:01 PM, Gerard Ziemski wrote: >>>>> Hi all, >>>>> >>>>> Please review this enhancement followup to JDK-8214310 and JDK-8213791 >>>>> >>>>> Here we redo the relevant gtest tests to use get(),insert() and are now free to remove the get_insert() API from the concurrent hash table implementation. >>>>> >>>>> bug id: https://bugs.openjdk.java.net/browse/JDK-8215155 >>>>> webrev: http://cr.openjdk.java.net/~gziemski/8215155_rev1 >>>>> Testing: Passed Mach hs_tier1, another Mach hs_tier1,2,3,4,5,6 in progress? >>>>> >>>>> P.S. I?d like to push this into JDK12 if there is no contention about this fix? >>>> It seems pretty straightforward. I'm fine with your pushing this to 12 but the deadline is fast approaching and I think you should have another reviewer. >>> Thank you for the review Coleen! >>> >>> As this is a test related change plus trivial removal of unused API, normally I?d mark it as trivial, but I agree with you - a second reviewer here would be most appreciated. >> I just discovered that I had an assert reversed in my webrev1 fix - in the file jdk/test/hotspot/gtest/utilities/test_concurrentHashtable.cpp, line 108: >> >> EXPECT_EQ(cht->insert(thr, stl, val), false) << "Inserting an unique value failed.?; >> >> should be: >> >> EXPECT_EQ(cht->insert(thr, stl, val), true) << "Inserting an unique value failed.?; >> >> I fixed it and posted http://cr.openjdk.java.net/~gziemski/8215155_rev2 >> >> I fired another Mach5 test (why wasn?t it caught?), but now I feel a bit less confident about pushing it into jdk12? >> >> >> cheers From jiangli.zhou at oracle.com Thu Jan 10 03:54:08 2019 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Wed, 9 Jan 2019 19:54:08 -0800 Subject: [12] RFR: 8214827: Incorrect call ClassLoaders.toFileURL("jrt:/java.compiler") In-Reply-To: <7a90457b-a491-050d-0502-9c57b511a8c1@oracle.com> References: <958a0930-3b54-94f1-9c22-e58e50faeaac@oracle.com> <5C367D2D.7060601@oracle.com> <558869bb-bff2-dcb9-e7be-6ebb5b7ad413@oracle.com> <8bee2b3d-f9d7-7405-0f25-5ec81f2a100d@oracle.com> <7f4cbd89-a18c-60c5-616a-1c12d814d169@oracle.com> <5C36ACFF.2040501@oracle.com> <7a90457b-a491-050d-0502-9c57b511a8c1@oracle.com> Message-ID: <1bf2095c-193b-69ed-63e9-3fd447ba003c@oracle.com> On 1/9/19 6:35 PM, coleen.phillimore at oracle.com wrote: > > http://cr.openjdk.java.net/~jiangli/8214827/webrev.03/src/hotspot/share/classfile/systemDictionaryShared.cpp.udiff.html > > > + Handle protection_domain = Handle(THREAD, > mod->shared_protection_domain()); > > > Nit, you can write this as: > > + Handle protection_domain(THREAD, mod->shared_protection_domain()); > Done. Thanks! Jiangli > > Not a full review and I don't need to see another webrev. > > Coleen > > On 1/9/19 9:25 PM, Calvin Cheung wrote: >> Looks good. >> >> thanks, >> Calvin >> >> On 1/9/19, 5:50 PM, Jiangli Zhou wrote: >>> Hi Ioi and David, >>> >>> Thanks for the comments! >>> >>> >>> On 1/9/19 5:13 PM, David Holmes wrote: >>>> On 10/01/2019 10:47 am, Ioi Lam wrote: >>>>> >>>>> On 1/9/19 4:32 PM, Jiangli Zhou wrote: >>>>>> Hi Calvin, >>>>>> >>>>>> Thanks for the review! >>>>>> >>>>>> >>>>>> On 1/9/19 3:01 PM, Calvin Cheung wrote: >>>>>>> Hi Jiangli, >>>>>>> >>>>>>> 1) systemDictionaryShared.cpp: >>>>>>> >>>>>>> Should all those CHECK_(protection_domain) be simply CHECK_NH? >>>>>>> In get_shared_jar_manifest() of the same file, CHECK_NH is used. >>>>>>> But in other functions, CHECK_(something) is being used. >>>>>>> Not sure which one is the preferred way? >>>>>> >>>>>> I'm not sure which is the preferred way either. I'm leaving it as >>>>>> is and also checking with Coleen... >>>>> >>>>> CHECK_(protection_domain)? depends on the fact that >>>>> protection_domain is NULL at the point of the CHECK_. This could >>>>> lead to maintenance issues down the road if someone decides to >>>>> initialize protection_domain earlier. >>>> >>>> I think this is fairly common practice though. We often define the >>>> "result" variable at the start of a method with an "error" value >>>> and return the result on error. >>> >>> I agree with David and it seems to be a common practice. However, I >>> don't have a strong preference on the usage of the CHECK_ macros. >>> Based on the feedback from Coleen, Calvin and Ioi, I updated the >>> webrev to use the CHECK_NH in >>> SystemDictionaryShared::get_shared_protection_domain(). The rest of >>> the usages in the file are not changed in this changeset to minimize >>> risks. >>> >>> Here is the updated webrev: >>> http://cr.openjdk.java.net/~jiangli/8214827/webrev.03/src/hotspot/share/classfile/systemDictionaryShared.cpp.frames.html >>> >>> Full webrev: http://cr.openjdk.java.net/~jiangli/8214827/webrev.03/ >>> >>> Thanks! >>> Jiangli >>>> >>>> David >>>> ----- >>>> >>>>> >>>>> I think CHECK_NH is better. Easier to read and less dependencies. >>>>> >>>>> The rest of the changes and Calvin's suggestions look good to me. >>>>> >>>>> Thanks >>>>> >>>>> - Ioi >>>>> >>>>> >>>>> >>>>>>> >>>>>>> 2) ProtectionDomain.java: >>>>>>> >>>>>>> 58???? TestCommon.run("-cp", appJar, >>>>>>> "ProtDomain").assertNormalExit(); >>>>>>> >>>>>>> ??? You can also check the output by doing: >>>>>>> ??? TestCommon.run("-cp", appJar, >>>>>>> "ProtDomain").assertNormalExit("Protection Domains match"); >>>>>>> ??? Similarly for line 61. >>>>>>> >>>>>>> 65???? TestCommon.run("-cp", appJar, >>>>>>> "JimageClassProtDomain").assertNormalExit(); >>>>>>> >>>>>>> ???? You can check the output "shouldNotContain" by doing: >>>>>>> ???? TestCommon.run("-cp", appJar, "JimageClassProtDomain") >>>>>>> ???????? .assertNormalExit(output -> >>>>>>> output.shouldNotContain("Failed: Protection Domains do not match"); >>>>>> >>>>>> I've updated the webrev and incorporated with your suggestions: >>>>>> http://cr.openjdk.java.net/~jiangli/8214827/webrev.02/. >>>>>>> >>>>>>> The remaining 3 files look good. >>>>>> >>>>>> Thanks! >>>>>> Jiangli >>>>>>> >>>>>>> thanks, >>>>>>> Calvin >>>>>>> >>>>>>> On 1/9/19, 2:15 PM, Jiangli Zhou wrote: >>>>>>>> Please review the bug fix for >>>>>>>> SystemDictionaryShared::get_shared_protection_domain(). When >>>>>>>> jrt:/ location is given, a null URL (due to the error >>>>>>>> in ClassLoaders.toFileURL) is used for the CodeSource, which >>>>>>>> results a wrong ProtectionDomain being used for the archived >>>>>>>> app/platform class from the runtime image. The granted >>>>>>>> permission is minimum in that case. >>>>>>>> >>>>>>>> This turns out to be an issue that's hidden for a long time. >>>>>>>> The JimageClassProtDomain.java test has been outdated and fails >>>>>>>> to detect the issue (I'm the guilt one). Please see the >>>>>>>> comments in the bug for more details. Thanks Martin for finding >>>>>>>> the issue, and David, Alan and Mandy for discussions. >>>>>>>> >>>>>>>> webrev: http://cr.openjdk.java.net/~jiangli/8214827/webrev.01/ >>>>>>>> >>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8214827 >>>>>>>> >>>>>>>> Tested with appcds tests locally. Tested tier1-2. Tier3 is >>>>>>>> still in progress. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Jiangli >>>>>>>> >>>>>> >>> > From martin.doerr at sap.com Thu Jan 10 06:08:57 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 10 Jan 2019 06:08:57 +0000 Subject: RFR(S): 8216376: [PPC64] Possibly unreliable stack frame resizing in template interpreter In-Reply-To: References: Message-ID: <21734eee6c8c47c5b2e464b1071a3dfb@sap.com> Hi Gustavo, thanks a lot for testing and for the review. Best regards, Martin -----Original Message----- From: Gustavo Romero Sent: Mittwoch, 9. Januar 2019 21:23 To: Doerr, Martin ; hotspot-runtime-dev at openjdk.java.net Cc: Lindenmaier, Goetz Subject: Re: RFR(S): 8216376: [PPC64] Possibly unreliable stack frame resizing in template interpreter Hi Martin, On 01/08/2019 03:43 PM, Doerr, Martin wrote: > we recently noticed stack corruption while testing JDK-8216060. The issue was not directly in the new code, but it didn't work with the current handling of the interpreter stack frames which is very error-prone at a few places. > I'd like to improve these places. At least one of them even seems to be unreliable in the current implementation. > Bug with some more background information: > > https://bugs.openjdk.java.net/browse/JDK-8216376 > > My proposal to fix it: > http://cr.openjdk.java.net/~mdoerr/8216376_PPC64_frame_resizing/webrev.00/ I've tested this change with JDK-8216060 on top of it for both release and fastdebug builds and all tests passed fine. To the best of my knowledge it looks correct and I think that restoring the SP using resize_frame_absolute after the generated code looks more consistent than the SP cut back before it and even makes the code easier to follow/understand. Thank you. Best regards, Gustavo From robbin.ehn at oracle.com Thu Jan 10 13:22:17 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Thu, 10 Jan 2019 14:22:17 +0100 Subject: RFR 8215155: Remove get_insert() from concurrent hashtable and gtests In-Reply-To: References: <6b738e53-3468-8ad1-23f9-ce2a023b977b@oracle.com> <67B4490D-EE24-4DFE-9898-3ED72DADA21A@oracle.com> Message-ID: <0cdc6d4c-2908-446c-6d62-29c553c1e821@oracle.com> On 1/10/19 4:08 AM, coleen.phillimore at oracle.com wrote: > > > On 1/9/19 2:48 PM, Gerard Ziemski wrote: >> hi Robbin, Coleen, >> >> I apologize, but in my haste to try to push this issue before I went off for >> holiday break (which I failed), I missed another issue, so I?d like to ask you >> to review this one last small change from webrev2: >> >> line 129 in jdk/test/hotspot/gtest/utilities/test_concurrentHashtable.cpp >> should be >> >> 129???? cht_insert_helper(thr, cht, val); >> >> instead of >> >> 129???? cht_get_helper(thr, cht, val); > > Makes sense.? This looks good.? You can run the gtests locally on your machine, > which is a lot faster. +1 /Robbin > > Coleen >> >> bug id:? https://bugs.openjdk.java.net/browse/JDK-8215155 >> webrev:? http://cr.openjdk.java.net/~gziemski/8215155_rev3 >> testing: Passed Mach hs_tier1,2,3 >> >> >> thank you >> >>> On Dec 13, 2018, at 9:48 AM, Gerard Ziemski wrote: >>> >>>> On Dec 13, 2018, at 8:58 AM, Gerard Ziemski wrote: >>>> >>>> >>>>> On Dec 12, 2018, at 6:30 PM, coleen.phillimore at oracle.com wrote: >>>>> >>>>> >>>>> This looks good to me. >>>>> >>>>> On 12/12/18 3:01 PM, Gerard Ziemski wrote: >>>>>> Hi all, >>>>>> >>>>>> Please review this enhancement followup to JDK-8214310 and JDK-8213791 >>>>>> >>>>>> Here we redo the relevant gtest tests to use get(),insert() and are now >>>>>> free to remove the get_insert() API from the concurrent hash table >>>>>> implementation. >>>>>> >>>>>> bug id:? https://bugs.openjdk.java.net/browse/JDK-8215155 >>>>>> webrev:? http://cr.openjdk.java.net/~gziemski/8215155_rev1 >>>>>> Testing: Passed Mach hs_tier1, another Mach hs_tier1,2,3,4,5,6 in progress? >>>>>> >>>>>> P.S. I?d like to push this into JDK12 if there is no contention about this >>>>>> fix? >>>>> It seems pretty straightforward.? I'm fine with your pushing this to 12 but >>>>> the deadline is fast approaching and I think you should have another reviewer. >>>> Thank you for the review Coleen! >>>> >>>> As this is a test related change plus trivial removal of unused API, >>>> normally I?d mark it as trivial, but I agree with you - a second reviewer >>>> here would be most appreciated. >>> I just discovered that I had an assert reversed in my webrev1 fix - in the >>> file jdk/test/hotspot/gtest/utilities/test_concurrentHashtable.cpp, line 108: >>> >>> EXPECT_EQ(cht->insert(thr, stl, val), false) << "Inserting an unique value >>> failed.?; >>> >>> should be: >>> >>> EXPECT_EQ(cht->insert(thr, stl, val), true) << "Inserting an unique value >>> failed.?; >>> >>> I fixed it and posted http://cr.openjdk.java.net/~gziemski/8215155_rev2 >>> >>> I fired another Mach5 test (why wasn?t it caught?), but now I feel a bit less >>> confident about pushing it into jdk12? >>> >>> >>> cheers > From erik.osterlund at oracle.com Thu Jan 10 15:01:14 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Thu, 10 Jan 2019 16:01:14 +0100 Subject: RFR: 8216428: Remove IgnoreLibthreadGPFault In-Reply-To: References: Message-ID: <913a8f4f-8f16-5ad6-fc64-8517694a753b@oracle.com> Hi Claes, +1 /Erik On 2019-01-09 18:45, Claes Redestad wrote: > Hi, > > remove the develop flag IgnoreLibthreadGPFault, which guards a > now-defunct workaround to a Solaris IA32 bug. > > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8216428 > Webrev: http://cr.openjdk.java.net/~redestad/8216428/open.00/ > > Thanks! > > /Claes From claes.redestad at oracle.com Thu Jan 10 15:08:28 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 10 Jan 2019 16:08:28 +0100 Subject: RFR: 8216428: Remove IgnoreLibthreadGPFault In-Reply-To: <913a8f4f-8f16-5ad6-fc64-8517694a753b@oracle.com> References: <913a8f4f-8f16-5ad6-fc64-8517694a753b@oracle.com> Message-ID: Thanks, Erik! /Claes On 2019-01-10 16:01, Erik ?sterlund wrote: > Hi Claes, > > +1 > > /Erik > > On 2019-01-09 18:45, Claes Redestad wrote: >> Hi, >> >> remove the develop flag IgnoreLibthreadGPFault, which guards a >> now-defunct workaround to a Solaris IA32 bug. >> >> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8216428 >> Webrev: http://cr.openjdk.java.net/~redestad/8216428/open.00/ >> >> Thanks! >> >> /Claes > From calvin.cheung at oracle.com Thu Jan 10 20:08:31 2019 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Thu, 10 Jan 2019 12:08:31 -0800 Subject: RFR(S) 8216184: CDS/appCDS tests failed on Windows due to long path to a classlist file Message-ID: <5C37A63F.8030109@oracle.com> bug: https://bugs.openjdk.java.net/browse/JDK-8216184 webrev: http://cr.openjdk.java.net/~ccheung/8216184/webrev.00/ We are using fopen() to open a classlist file. fopen() can't handle long path name longer than MAX_PATH. A fix is to use os::open() which is capable of handling long path name after the fix for JDK-8188122. Testing: mach5 hs-tier{1,2,3}. thanks, Calvin From ioi.lam at oracle.com Fri Jan 11 01:23:33 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 10 Jan 2019 17:23:33 -0800 Subject: RFR(S) 8216184: CDS/appCDS tests failed on Windows due to long path to a classlist file In-Reply-To: <5C37A63F.8030109@oracle.com> References: <5C37A63F.8030109@oracle.com> Message-ID: <05e41065-0e63-62a7-6acd-b0e3a7034c90@oracle.com> Hi Calvin, Maybe you can use os::fopen() instead of 2 calls to overloaded versions of os::open()? The rest looks good. Thanks - Ioi On 1/10/19 12:08 PM, Calvin Cheung wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8216184 > > webrev: http://cr.openjdk.java.net/~ccheung/8216184/webrev.00/ > > We are using fopen() to open a classlist file. fopen() can't handle > long path name longer than MAX_PATH. > > A fix is to use os::open() which is capable of handling long path name > after the fix for JDK-8188122. > > Testing: mach5 hs-tier{1,2,3}. > > thanks, > Calvin From david.holmes at oracle.com Fri Jan 11 01:42:48 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Jan 2019 11:42:48 +1000 Subject: RFR(S) 8216184: CDS/appCDS tests failed on Windows due to long path to a classlist file In-Reply-To: <05e41065-0e63-62a7-6acd-b0e3a7034c90@oracle.com> References: <5C37A63F.8030109@oracle.com> <05e41065-0e63-62a7-6acd-b0e3a7034c90@oracle.com> Message-ID: <4ad058a0-f112-d850-b2ec-133482813eac@oracle.com> On 11/01/2019 11:23 am, Ioi Lam wrote: > Hi Calvin, > > Maybe you can use os::fopen() instead of 2 calls to overloaded versions > of os::open()? os::fopen still calls ::fopen so will have the exact same problem on Windows. os::fopen only exists to add close-on-exec behaviour. There are numerous uses of plain fopen in shared code in the VM, many of which may also be problematic. In relation to CDS, this comment in ./share/memory/metaspaceShared.cpp seems out-of-place and likely no longer relevant, as I see no fopern use there // Preload classes to be shared. // Should use some os:: method rather than fopen() here. aB. Otherwise looks good to me. Thanks, David ----- > The rest looks good. > > Thanks > > - Ioi > > On 1/10/19 12:08 PM, Calvin Cheung wrote: >> bug: https://bugs.openjdk.java.net/browse/JDK-8216184 >> >> webrev: http://cr.openjdk.java.net/~ccheung/8216184/webrev.00/ >> >> We are using fopen() to open a classlist file. fopen() can't handle >> long path name longer than MAX_PATH. >> >> A fix is to use os::open() which is capable of handling long path name >> after the fix for JDK-8188122. >> >> Testing: mach5 hs-tier{1,2,3}. >> >> thanks, >> Calvin From ioi.lam at oracle.com Fri Jan 11 01:59:38 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 10 Jan 2019 17:59:38 -0800 Subject: RFR(S) 8216184: CDS/appCDS tests failed on Windows due to long path to a classlist file In-Reply-To: <4ad058a0-f112-d850-b2ec-133482813eac@oracle.com> References: <5C37A63F.8030109@oracle.com> <05e41065-0e63-62a7-6acd-b0e3a7034c90@oracle.com> <4ad058a0-f112-d850-b2ec-133482813eac@oracle.com> Message-ID: <4624e8d4-0a2c-7adb-fa67-39947034120f@oracle.com> On 1/10/19 5:42 PM, David Holmes wrote: > On 11/01/2019 11:23 am, Ioi Lam wrote: >> Hi Calvin, >> >> Maybe you can use os::fopen() instead of 2 calls to overloaded >> versions of os::open()? > > os::fopen still calls ::fopen so will have the exact same problem on > Windows. os::fopen only exists to add close-on-exec behaviour. > Ah, maybe we should add a comment in the new code to explain why this gymnastic is necessary? Thanks - Ioi > There are numerous uses of plain fopen in shared code in the VM, many > of which may also be problematic. > > In relation to CDS, this comment in > > ./share/memory/metaspaceShared.cpp > > seems out-of-place and likely no longer relevant, as I see no fopern > use there > > ??? // Preload classes to be shared. > ??? // Should use some os:: method rather than fopen() here. aB. > > Otherwise looks good to me. > > Thanks, > David > ----- > >> The rest looks good. >> >> Thanks >> >> - Ioi >> >> On 1/10/19 12:08 PM, Calvin Cheung wrote: >>> bug: https://bugs.openjdk.java.net/browse/JDK-8216184 >>> >>> webrev: http://cr.openjdk.java.net/~ccheung/8216184/webrev.00/ >>> >>> We are using fopen() to open a classlist file. fopen() can't handle >>> long path name longer than MAX_PATH. >>> >>> A fix is to use os::open() which is capable of handling long path >>> name after the fix for JDK-8188122. >>> >>> Testing: mach5 hs-tier{1,2,3}. >>> >>> thanks, >>> Calvin From david.holmes at oracle.com Fri Jan 11 02:25:23 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Jan 2019 12:25:23 +1000 Subject: RFR(S) 8216184: CDS/appCDS tests failed on Windows due to long path to a classlist file In-Reply-To: <4624e8d4-0a2c-7adb-fa67-39947034120f@oracle.com> References: <5C37A63F.8030109@oracle.com> <05e41065-0e63-62a7-6acd-b0e3a7034c90@oracle.com> <4ad058a0-f112-d850-b2ec-133482813eac@oracle.com> <4624e8d4-0a2c-7adb-fa67-39947034120f@oracle.com> Message-ID: On 11/01/2019 11:59 am, Ioi Lam wrote: > > On 1/10/19 5:42 PM, David Holmes wrote: >> On 11/01/2019 11:23 am, Ioi Lam wrote: >>> Hi Calvin, >>> >>> Maybe you can use os::fopen() instead of 2 calls to overloaded >>> versions of os::open()? >> >> os::fopen still calls ::fopen so will have the exact same problem on >> Windows. os::fopen only exists to add close-on-exec behaviour. >> > Ah, maybe we should add a comment in the new code to explain why this > gymnastic is necessary? +1 That said, from what I've read it should suffice to pre-pend "\\?\" provided we use absolute paths: https://docs.microsoft.com/en-us/windows/desktop/FileIO/naming-a-file#maximum-path-length-limitation The os::open fix for 8188122 is rather more complicated though, so perhaps simplest to just use that as-is. David > Thanks > > - Ioi > >> There are numerous uses of plain fopen in shared code in the VM, many >> of which may also be problematic. >> >> In relation to CDS, this comment in >> >> ./share/memory/metaspaceShared.cpp >> >> seems out-of-place and likely no longer relevant, as I see no fopern >> use there >> >> ??? // Preload classes to be shared. >> ??? // Should use some os:: method rather than fopen() here. aB. >> >> Otherwise looks good to me. >> >> Thanks, >> David >> ----- >> >>> The rest looks good. >>> >>> Thanks >>> >>> - Ioi >>> >>> On 1/10/19 12:08 PM, Calvin Cheung wrote: >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8216184 >>>> >>>> webrev: http://cr.openjdk.java.net/~ccheung/8216184/webrev.00/ >>>> >>>> We are using fopen() to open a classlist file. fopen() can't handle >>>> long path name longer than MAX_PATH. >>>> >>>> A fix is to use os::open() which is capable of handling long path >>>> name after the fix for JDK-8188122. >>>> >>>> Testing: mach5 hs-tier{1,2,3}. >>>> >>>> thanks, >>>> Calvin From martin.doerr at sap.com Fri Jan 11 14:22:08 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 11 Jan 2019 14:22:08 +0000 Subject: RFR(XS): 8216560: gtest build broken on PPC64 Message-ID: <1de961de952c47a68e32ac581f9e4d23@sap.com> Hi, get I can reviews for this trivial build fix, please? "set_thread_state" is in thread.inline.hpp on PPC64 and aarch64. So aarch64 seems to be affected as well (not checked). Webrev: http://cr.openjdk.java.net/~mdoerr/8216560_fix_gtest_build/webrev.00/ Best regards, Martin From robbin.ehn at oracle.com Fri Jan 11 14:26:45 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Fri, 11 Jan 2019 15:26:45 +0100 Subject: RFR(XS): 8216560: gtest build broken on PPC64 In-Reply-To: <1de961de952c47a68e32ac581f9e4d23@sap.com> References: <1de961de952c47a68e32ac581f9e4d23@sap.com> Message-ID: <5ad9671a-0357-91bd-7daf-9cfea993d8e3@oracle.com> Thanks Martin! /Robbin On 1/11/19 3:22 PM, Doerr, Martin wrote: > Hi, > > get I can reviews for this trivial build fix, please? > > "set_thread_state" is in thread.inline.hpp on PPC64 and aarch64. So aarch64 seems to be affected as well (not checked). > > Webrev: > http://cr.openjdk.java.net/~mdoerr/8216560_fix_gtest_build/webrev.00/ > > Best regards, > Martin > From calvin.cheung at oracle.com Fri Jan 11 18:06:44 2019 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Fri, 11 Jan 2019 10:06:44 -0800 Subject: RFR(S) 8216184: CDS/appCDS tests failed on Windows due to long path to a classlist file In-Reply-To: References: <5C37A63F.8030109@oracle.com> <05e41065-0e63-62a7-6acd-b0e3a7034c90@oracle.com> <4ad058a0-f112-d850-b2ec-133482813eac@oracle.com> <4624e8d4-0a2c-7adb-fa67-39947034120f@oracle.com> Message-ID: <5C38DB34.2040507@oracle.com> Hi Ioi, David, Thanks for your review! I have added some comment in classListParser.cpp and removed the old comment in metaspaceShared.cpp. Here's an updated webrev: http://cr.openjdk.java.net/~ccheung/8216184/webrev.01/ On 1/10/19, 6:25 PM, David Holmes wrote: > On 11/01/2019 11:59 am, Ioi Lam wrote: >> >> On 1/10/19 5:42 PM, David Holmes wrote: >>> On 11/01/2019 11:23 am, Ioi Lam wrote: >>>> Hi Calvin, >>>> >>>> Maybe you can use os::fopen() instead of 2 calls to overloaded >>>> versions of os::open()? >>> >>> os::fopen still calls ::fopen so will have the exact same problem on >>> Windows. os::fopen only exists to add close-on-exec behaviour. >>> >> Ah, maybe we should add a comment in the new code to explain why this >> gymnastic is necessary? > > +1 > > That said, from what I've read it should suffice to pre-pend "\\?\" > provided we use absolute paths: > > https://docs.microsoft.com/en-us/windows/desktop/FileIO/naming-a-file#maximum-path-length-limitation > The above doc also mentions: "The Windows API has many functions that also have Unicode versions to permit an extended-length path for a maximum total path length of 32,767 characters." The path needs to be converted to a wide character string in order to use the Unicode versions of the functions. The conversion accounts for some of the complexities in the fix for 8188122. thanks, Calvin > > The os::open fix for 8188122 is rather more complicated though, so > perhaps simplest to just use that as-is. > > David > >> Thanks >> >> - Ioi >> >>> There are numerous uses of plain fopen in shared code in the VM, >>> many of which may also be problematic. >>> >>> In relation to CDS, this comment in >>> >>> ./share/memory/metaspaceShared.cpp >>> >>> seems out-of-place and likely no longer relevant, as I see no fopern >>> use there >>> >>> // Preload classes to be shared. >>> // Should use some os:: method rather than fopen() here. aB. >>> >>> Otherwise looks good to me. >>> >>> Thanks, >>> David >>> ----- >>> >>>> The rest looks good. >>>> >>>> Thanks >>>> >>>> - Ioi >>>> >>>> On 1/10/19 12:08 PM, Calvin Cheung wrote: >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8216184 >>>>> >>>>> webrev: http://cr.openjdk.java.net/~ccheung/8216184/webrev.00/ >>>>> >>>>> We are using fopen() to open a classlist file. fopen() can't >>>>> handle long path name longer than MAX_PATH. >>>>> >>>>> A fix is to use os::open() which is capable of handling long path >>>>> name after the fix for JDK-8188122. >>>>> >>>>> Testing: mach5 hs-tier{1,2,3}. >>>>> >>>>> thanks, >>>>> Calvin From ioi.lam at oracle.com Fri Jan 11 18:58:58 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Fri, 11 Jan 2019 10:58:58 -0800 Subject: RFR(S) 8216184: CDS/appCDS tests failed on Windows due to long path to a classlist file In-Reply-To: <5C38DB34.2040507@oracle.com> References: <5C37A63F.8030109@oracle.com> <05e41065-0e63-62a7-6acd-b0e3a7034c90@oracle.com> <4ad058a0-f112-d850-b2ec-133482813eac@oracle.com> <4624e8d4-0a2c-7adb-fa67-39947034120f@oracle.com> <5C38DB34.2040507@oracle.com> Message-ID: Hi Calvin, I would suggest changing the comment to ? 51?? // Use os::open() because neither fopen() nor os::fopen() ?????? //can handle long path name on Windows. For conciseness, I think "to open the classlist file" can be omitted. No need for a new webrev if you decide to take my suggestion. Thanks - Ioi On 1/11/19 10:06 AM, Calvin Cheung wrote: > Hi Ioi, David, > > Thanks for your review! > > I have added some comment in classListParser.cpp and removed the old > comment in metaspaceShared.cpp. > > Here's an updated webrev: > ??? http://cr.openjdk.java.net/~ccheung/8216184/webrev.01/ > > On 1/10/19, 6:25 PM, David Holmes wrote: >> On 11/01/2019 11:59 am, Ioi Lam wrote: >>> >>> On 1/10/19 5:42 PM, David Holmes wrote: >>>> On 11/01/2019 11:23 am, Ioi Lam wrote: >>>>> Hi Calvin, >>>>> >>>>> Maybe you can use os::fopen() instead of 2 calls to overloaded >>>>> versions of os::open()? >>>> >>>> os::fopen still calls ::fopen so will have the exact same problem >>>> on Windows. os::fopen only exists to add close-on-exec behaviour. >>>> >>> Ah, maybe we should add a comment in the new code to explain why >>> this gymnastic is necessary? >> >> +1 >> >> That said, from what I've read it should suffice to pre-pend "\\?\" >> provided we use absolute paths: >> >> https://docs.microsoft.com/en-us/windows/desktop/FileIO/naming-a-file#maximum-path-length-limitation >> > The above doc also mentions: > "The Windows API has many functions that also have Unicode versions to > permit an extended-length path for a maximum total path length of > 32,767 characters." > > The path needs to be converted to a wide character string in order to > use the Unicode versions of the functions. The conversion accounts for > some of the complexities in the fix for 8188122. > > thanks, > Calvin >> >> The os::open fix for 8188122 is rather more complicated though, so >> perhaps simplest to just use that as-is. >> >> David >> >>> Thanks >>> >>> - Ioi >>> >>>> There are numerous uses of plain fopen in shared code in the VM, >>>> many of which may also be problematic. >>>> >>>> In relation to CDS, this comment in >>>> >>>> ./share/memory/metaspaceShared.cpp >>>> >>>> seems out-of-place and likely no longer relevant, as I see no >>>> fopern use there >>>> >>>> ??? // Preload classes to be shared. >>>> ??? // Should use some os:: method rather than fopen() here. aB. >>>> >>>> Otherwise looks good to me. >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> The rest looks good. >>>>> >>>>> Thanks >>>>> >>>>> - Ioi >>>>> >>>>> On 1/10/19 12:08 PM, Calvin Cheung wrote: >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8216184 >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~ccheung/8216184/webrev.00/ >>>>>> >>>>>> We are using fopen() to open a classlist file. fopen() can't >>>>>> handle long path name longer than MAX_PATH. >>>>>> >>>>>> A fix is to use os::open() which is capable of handling long path >>>>>> name after the fix for JDK-8188122. >>>>>> >>>>>> Testing: mach5 hs-tier{1,2,3}. >>>>>> >>>>>> thanks, >>>>>> Calvin From calvin.cheung at oracle.com Fri Jan 11 20:09:33 2019 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Fri, 11 Jan 2019 12:09:33 -0800 Subject: RFR(S) 8216184: CDS/appCDS tests failed on Windows due to long path to a classlist file In-Reply-To: References: <5C37A63F.8030109@oracle.com> <05e41065-0e63-62a7-6acd-b0e3a7034c90@oracle.com> <4ad058a0-f112-d850-b2ec-133482813eac@oracle.com> <4624e8d4-0a2c-7adb-fa67-39947034120f@oracle.com> <5C38DB34.2040507@oracle.com> Message-ID: <5C38F7FD.60106@oracle.com> On 1/11/19, 10:58 AM, Ioi Lam wrote: > Hi Calvin, I would suggest changing the comment to > > 51 // Use os::open() because neither fopen() nor os::fopen() > //can handle long path name on Windows. > > For conciseness, I think "to open the classlist file" can be omitted. > > No need for a new webrev if you decide to take my suggestion. I have updated the comment. thanks, Calvin > > Thanks > > - Ioi > > > > On 1/11/19 10:06 AM, Calvin Cheung wrote: >> Hi Ioi, David, >> >> Thanks for your review! >> >> I have added some comment in classListParser.cpp and removed the old >> comment in metaspaceShared.cpp. >> >> Here's an updated webrev: >> http://cr.openjdk.java.net/~ccheung/8216184/webrev.01/ >> >> On 1/10/19, 6:25 PM, David Holmes wrote: >>> On 11/01/2019 11:59 am, Ioi Lam wrote: >>>> >>>> On 1/10/19 5:42 PM, David Holmes wrote: >>>>> On 11/01/2019 11:23 am, Ioi Lam wrote: >>>>>> Hi Calvin, >>>>>> >>>>>> Maybe you can use os::fopen() instead of 2 calls to overloaded >>>>>> versions of os::open()? >>>>> >>>>> os::fopen still calls ::fopen so will have the exact same problem >>>>> on Windows. os::fopen only exists to add close-on-exec behaviour. >>>>> >>>> Ah, maybe we should add a comment in the new code to explain why >>>> this gymnastic is necessary? >>> >>> +1 >>> >>> That said, from what I've read it should suffice to pre-pend "\\?\" >>> provided we use absolute paths: >>> >>> https://docs.microsoft.com/en-us/windows/desktop/FileIO/naming-a-file#maximum-path-length-limitation >>> >> The above doc also mentions: >> "The Windows API has many functions that also have Unicode versions >> to permit an extended-length path for a maximum total path length of >> 32,767 characters." >> >> The path needs to be converted to a wide character string in order to >> use the Unicode versions of the functions. The conversion accounts >> for some of the complexities in the fix for 8188122. >> >> thanks, >> Calvin >>> >>> The os::open fix for 8188122 is rather more complicated though, so >>> perhaps simplest to just use that as-is. >>> >>> David >>> >>>> Thanks >>>> >>>> - Ioi >>>> >>>>> There are numerous uses of plain fopen in shared code in the VM, >>>>> many of which may also be problematic. >>>>> >>>>> In relation to CDS, this comment in >>>>> >>>>> ./share/memory/metaspaceShared.cpp >>>>> >>>>> seems out-of-place and likely no longer relevant, as I see no >>>>> fopern use there >>>>> >>>>> // Preload classes to be shared. >>>>> // Should use some os:: method rather than fopen() here. aB. >>>>> >>>>> Otherwise looks good to me. >>>>> >>>>> Thanks, >>>>> David >>>>> ----- >>>>> >>>>>> The rest looks good. >>>>>> >>>>>> Thanks >>>>>> >>>>>> - Ioi >>>>>> >>>>>> On 1/10/19 12:08 PM, Calvin Cheung wrote: >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8216184 >>>>>>> >>>>>>> webrev: http://cr.openjdk.java.net/~ccheung/8216184/webrev.00/ >>>>>>> >>>>>>> We are using fopen() to open a classlist file. fopen() can't >>>>>>> handle long path name longer than MAX_PATH. >>>>>>> >>>>>>> A fix is to use os::open() which is capable of handling long >>>>>>> path name after the fix for JDK-8188122. >>>>>>> >>>>>>> Testing: mach5 hs-tier{1,2,3}. >>>>>>> >>>>>>> thanks, >>>>>>> Calvin From david.holmes at oracle.com Fri Jan 11 23:09:57 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 12 Jan 2019 09:09:57 +1000 Subject: RFR(S) 8216184: CDS/appCDS tests failed on Windows due to long path to a classlist file In-Reply-To: <5C38DB34.2040507@oracle.com> References: <5C37A63F.8030109@oracle.com> <05e41065-0e63-62a7-6acd-b0e3a7034c90@oracle.com> <4ad058a0-f112-d850-b2ec-133482813eac@oracle.com> <4624e8d4-0a2c-7adb-fa67-39947034120f@oracle.com> <5C38DB34.2040507@oracle.com> Message-ID: Looks fine to me. Thanks, David On 12/01/2019 4:06 am, Calvin Cheung wrote: > Hi Ioi, David, > > Thanks for your review! > > I have added some comment in classListParser.cpp and removed the old > comment in metaspaceShared.cpp. > > Here's an updated webrev: > ??? http://cr.openjdk.java.net/~ccheung/8216184/webrev.01/ > > On 1/10/19, 6:25 PM, David Holmes wrote: >> On 11/01/2019 11:59 am, Ioi Lam wrote: >>> >>> On 1/10/19 5:42 PM, David Holmes wrote: >>>> On 11/01/2019 11:23 am, Ioi Lam wrote: >>>>> Hi Calvin, >>>>> >>>>> Maybe you can use os::fopen() instead of 2 calls to overloaded >>>>> versions of os::open()? >>>> >>>> os::fopen still calls ::fopen so will have the exact same problem on >>>> Windows. os::fopen only exists to add close-on-exec behaviour. >>>> >>> Ah, maybe we should add a comment in the new code to explain why this >>> gymnastic is necessary? >> >> +1 >> >> That said, from what I've read it should suffice to pre-pend "\\?\" >> provided we use absolute paths: >> >> https://docs.microsoft.com/en-us/windows/desktop/FileIO/naming-a-file#maximum-path-length-limitation >> > The above doc also mentions: > "The Windows API has many functions that also have Unicode versions to > permit an extended-length path for a maximum total path length of 32,767 > characters." > > The path needs to be converted to a wide character string in order to > use the Unicode versions of the functions. The conversion accounts for > some of the complexities in the fix for 8188122. > > thanks, > Calvin >> >> The os::open fix for 8188122 is rather more complicated though, so >> perhaps simplest to just use that as-is. >> >> David >> >>> Thanks >>> >>> - Ioi >>> >>>> There are numerous uses of plain fopen in shared code in the VM, >>>> many of which may also be problematic. >>>> >>>> In relation to CDS, this comment in >>>> >>>> ./share/memory/metaspaceShared.cpp >>>> >>>> seems out-of-place and likely no longer relevant, as I see no fopern >>>> use there >>>> >>>> ??? // Preload classes to be shared. >>>> ??? // Should use some os:: method rather than fopen() here. aB. >>>> >>>> Otherwise looks good to me. >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> The rest looks good. >>>>> >>>>> Thanks >>>>> >>>>> - Ioi >>>>> >>>>> On 1/10/19 12:08 PM, Calvin Cheung wrote: >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8216184 >>>>>> >>>>>> webrev: http://cr.openjdk.java.net/~ccheung/8216184/webrev.00/ >>>>>> >>>>>> We are using fopen() to open a classlist file. fopen() can't >>>>>> handle long path name longer than MAX_PATH. >>>>>> >>>>>> A fix is to use os::open() which is capable of handling long path >>>>>> name after the fix for JDK-8188122. >>>>>> >>>>>> Testing: mach5 hs-tier{1,2,3}. >>>>>> >>>>>> thanks, >>>>>> Calvin From shade at redhat.com Sat Jan 12 13:03:55 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Sat, 12 Jan 2019 14:03:55 +0100 Subject: RFR(XS): 8216560: gtest build broken on PPC64 In-Reply-To: <1de961de952c47a68e32ac581f9e4d23@sap.com> References: <1de961de952c47a68e32ac581f9e4d23@sap.com> Message-ID: <5cb556fe-7ce9-b4eb-f298-aed5c57ac3d4@redhat.com> On 1/11/19 3:22 PM, Doerr, Martin wrote: > ?set_thread_state? is in thread.inline.hpp on PPC64 and aarch64. So aarch64 seems to be affected as > well (not checked). Right. AArch64 is also broken. I submitted this: https://bugs.openjdk.java.net/browse/JDK-8216591 ...but see that your fix also handles that build failure. Closed as duplicate. > Webrev: > http://cr.openjdk.java.net/~mdoerr/8216560_fix_gtest_build/webrev.00/ Looks good! You might want to fix the synopsis to mention both PPC64 and AArch64. -Aleksey From david.holmes at oracle.com Mon Jan 14 06:01:40 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 14 Jan 2019 16:01:40 +1000 Subject: RFR (S): 8213397: Stack dump should show more clearly when a thread is blocked on a class initialization monitor Message-ID: <90bcd939-2066-0a3b-743a-a2c4d55954d7@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8213397 webrev: http://cr.openjdk.java.net/~dholmes/8213397/webrev/ Please review this simple enhancement to improve the stack trace information when a thread is blocked doing a (logical) Object.wait on the monitor associated with Class static initialization. Details are in the bug report but basically we record, in a thread-local variable, the name of the class before the "wait" and clear it after, thus allowing the stack dump code to query it if it appears we may be in that situation. In InstanceKlass::initialize_impl I also refactored the code a tiny bit to make use of the JavaThread reference to the current thread. A new test using jstack was also added. Testing: - mach5 tiers 1 - 3 - the new test on Windows/Linux/OSX x86 and Solaris sparc, in regular and Xcomp mode - All jstack/stack-dump using tests I could see (linux x64): - runtime/Thread - serviceability/sa/ - serviceability/tmtools/jstack/ - vmTestbase/nsk/jvmti/scenarios/sampling/ - vmTestbase/nsk/jvmti/MonitorWaited/ . - vmTestbase/nsk/jvmti/GetOwnedMonitorInfo/ Thanks, David From martin.doerr at sap.com Mon Jan 14 08:34:35 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 14 Jan 2019 08:34:35 +0000 Subject: RFR(XS): 8216560: gtest build broken on PPC64 In-Reply-To: <5cb556fe-7ce9-b4eb-f298-aed5c57ac3d4@redhat.com> References: <1de961de952c47a68e32ac581f9e4d23@sap.com> <5cb556fe-7ce9-b4eb-f298-aed5c57ac3d4@redhat.com> Message-ID: <381404e659af4d33bbb203b6ba67e400@sap.com> Hi Aleksey, done. Thanks for the review. Best regards, Martin -----Original Message----- From: Aleksey Shipilev Sent: Samstag, 12. Januar 2019 14:04 To: Doerr, Martin ; hotspot-runtime-dev at openjdk.java.net Subject: Re: RFR(XS): 8216560: gtest build broken on PPC64 On 1/11/19 3:22 PM, Doerr, Martin wrote: > "set_thread_state" is in thread.inline.hpp on PPC64 and aarch64. So aarch64 seems to be affected as > well (not checked). Right. AArch64 is also broken. I submitted this: https://bugs.openjdk.java.net/browse/JDK-8216591 ...but see that your fix also handles that build failure. Closed as duplicate. > Webrev: > http://cr.openjdk.java.net/~mdoerr/8216560_fix_gtest_build/webrev.00/ Looks good! You might want to fix the synopsis to mention both PPC64 and AArch64. -Aleksey From robbin.ehn at oracle.com Mon Jan 14 08:54:58 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Mon, 14 Jan 2019 09:54:58 +0100 Subject: RFR (S): 8213397: Stack dump should show more clearly when a thread is blocked on a class initialization monitor In-Reply-To: <90bcd939-2066-0a3b-743a-a2c4d55954d7@oracle.com> References: <90bcd939-2066-0a3b-743a-a2c4d55954d7@oracle.com> Message-ID: Hi David, looks good. In the test I would prefer e.g. semaphore acquire/release instead of boolean ready with sleep. (in this case it doesn't seem to make much of a difference) So do as you wish, I do not need to see a new webrev if you choose to change. Thanks, Robbin On 1/14/19 7:01 AM, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8213397 > webrev: http://cr.openjdk.java.net/~dholmes/8213397/webrev/ > > Please review this simple enhancement to improve the stack trace information > when a thread is blocked doing a (logical) Object.wait on the monitor associated > with Class static initialization. > > Details are in the bug report but basically we record, in a thread-local > variable, the name of the class before the "wait" and clear it after, thus > allowing the stack dump code to query it if it appears we may be in that situation. > > In InstanceKlass::initialize_impl I also refactored the code a tiny bit to make > use of the JavaThread reference to the current thread. > > A new test using jstack was also added. > > Testing: > ? - mach5 tiers 1 - 3 > ? - the new test on Windows/Linux/OSX x86 and Solaris sparc, in regular and > Xcomp mode > ? - All jstack/stack-dump using tests I could see (linux x64): > ??? - runtime/Thread > ??? - serviceability/sa/ > ??? - serviceability/tmtools/jstack/ > ??? - vmTestbase/nsk/jvmti/scenarios/sampling/ > ??? - vmTestbase/nsk/jvmti/MonitorWaited/ . > ??? - vmTestbase/nsk/jvmti/GetOwnedMonitorInfo/ > > Thanks, > David From coleen.phillimore at oracle.com Mon Jan 14 12:25:49 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 14 Jan 2019 07:25:49 -0500 Subject: RFR (S): 8213397: Stack dump should show more clearly when a thread is blocked on a class initialization monitor In-Reply-To: <90bcd939-2066-0a3b-743a-a2c4d55954d7@oracle.com> References: <90bcd939-2066-0a3b-743a-a2c4d55954d7@oracle.com> Message-ID: <5c44ba14-ba6d-b012-f824-6faa9f3ad28b@oracle.com> This is a nice improvement. http://cr.openjdk.java.net/~dholmes/8213397/webrev/src/hotspot/share/runtime/vframe.cpp.udiff.html + // top-frame, so we should be waiting on a Class initialization monitor. + InstanceKlass* k = thread()->class_to_be_initialized(); + if (k != NULL) { + st->print_cr("\t- waiting on the Class initialization monitor for %s", k->external_name()); + } + else { + assert(false, "OBJECT_WAIT state is unexpected"); + } Should be } else { And I don't think this should be an assert.? There are a couple of other places that we lock an object monitor from the VM, but I don't think we wait in these places.? In any case, if we add a wait, it would take a lot of testing and a long time to get to this assert to find it needs to add another case here.? So if you remove the 'else' completely and change the comment to "see if we are waiting on a class initialization monitor" you don't need to fix the {}. Thanks, Coleen On 1/14/19 1:01 AM, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8213397 > webrev: http://cr.openjdk.java.net/~dholmes/8213397/webrev/ > > Please review this simple enhancement to improve the stack trace > information when a thread is blocked doing a (logical) Object.wait on > the monitor associated with Class static initialization. > > Details are in the bug report but basically we record, in a > thread-local variable, the name of the class before the "wait" and > clear it after, thus allowing the stack dump code to query it if it > appears we may be in that situation. > > In InstanceKlass::initialize_impl I also refactored the code a tiny > bit to make use of the JavaThread reference to the current thread. > > A new test using jstack was also added. > > Testing: > ? - mach5 tiers 1 - 3 > ? - the new test on Windows/Linux/OSX x86 and Solaris sparc, in > regular and Xcomp mode > ? - All jstack/stack-dump using tests I could see (linux x64): > ??? - runtime/Thread > ??? - serviceability/sa/ > ??? - serviceability/tmtools/jstack/ > ??? - vmTestbase/nsk/jvmti/scenarios/sampling/ > ??? - vmTestbase/nsk/jvmti/MonitorWaited/ . > ??? - vmTestbase/nsk/jvmti/GetOwnedMonitorInfo/ > > Thanks, > David From david.holmes at oracle.com Mon Jan 14 13:08:01 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 14 Jan 2019 23:08:01 +1000 Subject: RFR (S): 8213397: Stack dump should show more clearly when a thread is blocked on a class initialization monitor In-Reply-To: References: <90bcd939-2066-0a3b-743a-a2c4d55954d7@oracle.com> Message-ID: <85e5d3a6-5b44-acaf-b7eb-f29b40e9b4a9@oracle.com> Hi Robbin, On 14/01/2019 6:54 pm, Robbin Ehn wrote: > Hi David, looks good. Thanks for the review. > In the test I would prefer e.g. semaphore acquire/release instead of > boolean ready with sleep. (in this case it doesn't seem to make much of > a difference) > So do as you wish, I do not need to see a new webrev if you choose to > change. Okay. Path of least resistance ... Thanks, David > Thanks, Robbin > > On 1/14/19 7:01 AM, David Holmes wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8213397 >> webrev: http://cr.openjdk.java.net/~dholmes/8213397/webrev/ >> >> Please review this simple enhancement to improve the stack trace >> information when a thread is blocked doing a (logical) Object.wait on >> the monitor associated with Class static initialization. >> >> Details are in the bug report but basically we record, in a >> thread-local variable, the name of the class before the "wait" and >> clear it after, thus allowing the stack dump code to query it if it >> appears we may be in that situation. >> >> In InstanceKlass::initialize_impl I also refactored the code a tiny >> bit to make use of the JavaThread reference to the current thread. >> >> A new test using jstack was also added. >> >> Testing: >> ?? - mach5 tiers 1 - 3 >> ?? - the new test on Windows/Linux/OSX x86 and Solaris sparc, in >> regular and Xcomp mode >> ?? - All jstack/stack-dump using tests I could see (linux x64): >> ???? - runtime/Thread >> ???? - serviceability/sa/ >> ???? - serviceability/tmtools/jstack/ >> ???? - vmTestbase/nsk/jvmti/scenarios/sampling/ >> ???? - vmTestbase/nsk/jvmti/MonitorWaited/ . >> ???? - vmTestbase/nsk/jvmti/GetOwnedMonitorInfo/ >> >> Thanks, >> David From david.holmes at oracle.com Mon Jan 14 13:13:46 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 14 Jan 2019 23:13:46 +1000 Subject: RFR (S): 8213397: Stack dump should show more clearly when a thread is blocked on a class initialization monitor In-Reply-To: <5c44ba14-ba6d-b012-f824-6faa9f3ad28b@oracle.com> References: <90bcd939-2066-0a3b-743a-a2c4d55954d7@oracle.com> <5c44ba14-ba6d-b012-f824-6faa9f3ad28b@oracle.com> Message-ID: <7bad7b2b-f310-792f-59c0-710b1098f918@oracle.com> Hi Coleen, On 14/01/2019 10:25 pm, coleen.phillimore at oracle.com wrote: > > This is a nice improvement. Thanks for taking a look. > http://cr.openjdk.java.net/~dholmes/8213397/webrev/src/hotspot/share/runtime/vframe.cpp.udiff.html > > > + // top-frame, so we should be waiting on a Class initialization monitor. > + InstanceKlass* k = thread()->class_to_be_initialized(); > + if (k != NULL) { > + st->print_cr("\t- waiting on the Class initialization monitor for %s", > k->external_name()); > + } > + else { > + assert(false, "OBJECT_WAIT state is unexpected"); > + } > > > Should be } else { > > And I don't think this should be an assert.? There are a couple of other > places that we lock an object monitor from the VM, but I don't think we > wait in these places.? In any case, if we add a wait, it would take a > lot of testing and a long time to get to this assert to find it needs to > add another case here.? So if you remove the 'else' completely and > change the comment to "see if we are waiting on a class initialization > monitor" you don't need to fix the {}. Initially I thought the "else" might be some JNI or JVM TI case, but that's not so as there's no direct API to do wait(), it just requires invoking the Object.wait method. So at the moment the implicit else is "unreachable" and I wanted to convey that. I chose the assert in case I was wrong, or in the unlikely event a new VM internal call to wait() was ever added and we happened to encounter it. Leaving it empty to me raises the question "how do we get here?". Thanks, David > Thanks, > Coleen > > > > On 1/14/19 1:01 AM, David Holmes wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8213397 >> webrev: http://cr.openjdk.java.net/~dholmes/8213397/webrev/ >> >> Please review this simple enhancement to improve the stack trace >> information when a thread is blocked doing a (logical) Object.wait on >> the monitor associated with Class static initialization. >> >> Details are in the bug report but basically we record, in a >> thread-local variable, the name of the class before the "wait" and >> clear it after, thus allowing the stack dump code to query it if it >> appears we may be in that situation. >> >> In InstanceKlass::initialize_impl I also refactored the code a tiny >> bit to make use of the JavaThread reference to the current thread. >> >> A new test using jstack was also added. >> >> Testing: >> ? - mach5 tiers 1 - 3 >> ? - the new test on Windows/Linux/OSX x86 and Solaris sparc, in >> regular and Xcomp mode >> ? - All jstack/stack-dump using tests I could see (linux x64): >> ??? - runtime/Thread >> ??? - serviceability/sa/ >> ??? - serviceability/tmtools/jstack/ >> ??? - vmTestbase/nsk/jvmti/scenarios/sampling/ >> ??? - vmTestbase/nsk/jvmti/MonitorWaited/ . >> ??? - vmTestbase/nsk/jvmti/GetOwnedMonitorInfo/ >> >> Thanks, >> David > From coleen.phillimore at oracle.com Mon Jan 14 13:21:24 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 14 Jan 2019 08:21:24 -0500 Subject: RFR (S): 8213397: Stack dump should show more clearly when a thread is blocked on a class initialization monitor In-Reply-To: <7bad7b2b-f310-792f-59c0-710b1098f918@oracle.com> References: <90bcd939-2066-0a3b-743a-a2c4d55954d7@oracle.com> <5c44ba14-ba6d-b012-f824-6faa9f3ad28b@oracle.com> <7bad7b2b-f310-792f-59c0-710b1098f918@oracle.com> Message-ID: On 1/14/19 8:13 AM, David Holmes wrote: > Hi Coleen, > > On 14/01/2019 10:25 pm, coleen.phillimore at oracle.com wrote: >> >> This is a nice improvement. > > Thanks for taking a look. > >> http://cr.openjdk.java.net/~dholmes/8213397/webrev/src/hotspot/share/runtime/vframe.cpp.udiff.html >> >> >> + // top-frame, so we should be waiting on a Class initialization >> monitor. >> + InstanceKlass* k = thread()->class_to_be_initialized(); >> + if (k != NULL) { >> + st->print_cr("\t- waiting on the Class initialization monitor for >> %s", k->external_name()); >> + } >> + else { >> + assert(false, "OBJECT_WAIT state is unexpected"); >> + } >> >> >> Should be } else { >> >> And I don't think this should be an assert.? There are a couple of >> other places that we lock an object monitor from the VM, but I don't >> think we wait in these places.? In any case, if we add a wait, it >> would take a lot of testing and a long time to get to this assert to >> find it needs to add another case here.? So if you remove the 'else' >> completely and change the comment to "see if we are waiting on a >> class initialization monitor" you don't need to fix the {}. > > Initially I thought the "else" might be some JNI or JVM TI case, but > that's not so as there's no direct API to do wait(), it just requires > invoking the Object.wait method. So at the moment the implicit else is > "unreachable" and I wanted to convey that. I chose the assert in case > I was wrong, or in the unlikely event a new VM internal call to wait() > was ever added and we happened to encounter it. Leaving it empty to me > raises the question "how do we get here?". The thing is, that leaving an assert to find some future case is only good if that code is going to execute frequently and we find it in testing.? This is not a frequent path.?? Having the assert might be hit much later down the road when we've forgotten this.? It's not helpful. Thanks, Coleen > > Thanks, > David > >> Thanks, >> Coleen >> >> >> >> On 1/14/19 1:01 AM, David Holmes wrote: >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8213397 >>> webrev: http://cr.openjdk.java.net/~dholmes/8213397/webrev/ >>> >>> Please review this simple enhancement to improve the stack trace >>> information when a thread is blocked doing a (logical) Object.wait >>> on the monitor associated with Class static initialization. >>> >>> Details are in the bug report but basically we record, in a >>> thread-local variable, the name of the class before the "wait" and >>> clear it after, thus allowing the stack dump code to query it if it >>> appears we may be in that situation. >>> >>> In InstanceKlass::initialize_impl I also refactored the code a tiny >>> bit to make use of the JavaThread reference to the current thread. >>> >>> A new test using jstack was also added. >>> >>> Testing: >>> ? - mach5 tiers 1 - 3 >>> ? - the new test on Windows/Linux/OSX x86 and Solaris sparc, in >>> regular and Xcomp mode >>> ? - All jstack/stack-dump using tests I could see (linux x64): >>> ??? - runtime/Thread >>> ??? - serviceability/sa/ >>> ??? - serviceability/tmtools/jstack/ >>> ??? - vmTestbase/nsk/jvmti/scenarios/sampling/ >>> ??? - vmTestbase/nsk/jvmti/MonitorWaited/ . >>> ??? - vmTestbase/nsk/jvmti/GetOwnedMonitorInfo/ >>> >>> Thanks, >>> David >> From david.holmes at oracle.com Mon Jan 14 13:26:10 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 14 Jan 2019 23:26:10 +1000 Subject: RFR (S): 8213397: Stack dump should show more clearly when a thread is blocked on a class initialization monitor In-Reply-To: References: <90bcd939-2066-0a3b-743a-a2c4d55954d7@oracle.com> <5c44ba14-ba6d-b012-f824-6faa9f3ad28b@oracle.com> <7bad7b2b-f310-792f-59c0-710b1098f918@oracle.com> Message-ID: <9880a1a4-5041-8dcb-288c-10382c6acb09@oracle.com> On 14/01/2019 11:21 pm, coleen.phillimore at oracle.com wrote: > > > On 1/14/19 8:13 AM, David Holmes wrote: >> Hi Coleen, >> >> On 14/01/2019 10:25 pm, coleen.phillimore at oracle.com wrote: >>> >>> This is a nice improvement. >> >> Thanks for taking a look. >> >>> http://cr.openjdk.java.net/~dholmes/8213397/webrev/src/hotspot/share/runtime/vframe.cpp.udiff.html >>> >>> >>> + // top-frame, so we should be waiting on a Class initialization >>> monitor. >>> + InstanceKlass* k = thread()->class_to_be_initialized(); >>> + if (k != NULL) { >>> + st->print_cr("\t- waiting on the Class initialization monitor for >>> %s", k->external_name()); >>> + } >>> + else { >>> + assert(false, "OBJECT_WAIT state is unexpected"); >>> + } >>> >>> >>> Should be } else { >>> >>> And I don't think this should be an assert.? There are a couple of >>> other places that we lock an object monitor from the VM, but I don't >>> think we wait in these places.? In any case, if we add a wait, it >>> would take a lot of testing and a long time to get to this assert to >>> find it needs to add another case here.? So if you remove the 'else' >>> completely and change the comment to "see if we are waiting on a >>> class initialization monitor" you don't need to fix the {}. >> >> Initially I thought the "else" might be some JNI or JVM TI case, but >> that's not so as there's no direct API to do wait(), it just requires >> invoking the Object.wait method. So at the moment the implicit else is >> "unreachable" and I wanted to convey that. I chose the assert in case >> I was wrong, or in the unlikely event a new VM internal call to wait() >> was ever added and we happened to encounter it. Leaving it empty to me >> raises the question "how do we get here?". > > The thing is, that leaving an assert to find some future case is only > good if that code is going to execute frequently and we find it in > testing.? This is not a frequent path.?? Having the assert might be hit > much later down the road when we've forgotten this.? It's not helpful. It may not be very helpful but it is more helpful than nothing. But I guess I can remove it. Thanks, David ----- > > Thanks, > Coleen > >> >> Thanks, >> David >> >>> Thanks, >>> Coleen >>> >>> >>> >>> On 1/14/19 1:01 AM, David Holmes wrote: >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8213397 >>>> webrev: http://cr.openjdk.java.net/~dholmes/8213397/webrev/ >>>> >>>> Please review this simple enhancement to improve the stack trace >>>> information when a thread is blocked doing a (logical) Object.wait >>>> on the monitor associated with Class static initialization. >>>> >>>> Details are in the bug report but basically we record, in a >>>> thread-local variable, the name of the class before the "wait" and >>>> clear it after, thus allowing the stack dump code to query it if it >>>> appears we may be in that situation. >>>> >>>> In InstanceKlass::initialize_impl I also refactored the code a tiny >>>> bit to make use of the JavaThread reference to the current thread. >>>> >>>> A new test using jstack was also added. >>>> >>>> Testing: >>>> ? - mach5 tiers 1 - 3 >>>> ? - the new test on Windows/Linux/OSX x86 and Solaris sparc, in >>>> regular and Xcomp mode >>>> ? - All jstack/stack-dump using tests I could see (linux x64): >>>> ??? - runtime/Thread >>>> ??? - serviceability/sa/ >>>> ??? - serviceability/tmtools/jstack/ >>>> ??? - vmTestbase/nsk/jvmti/scenarios/sampling/ >>>> ??? - vmTestbase/nsk/jvmti/MonitorWaited/ . >>>> ??? - vmTestbase/nsk/jvmti/GetOwnedMonitorInfo/ >>>> >>>> Thanks, >>>> David >>> > From thomas.stuefe at gmail.com Mon Jan 14 15:15:50 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 14 Jan 2019 16:15:50 +0100 Subject: RFR(xxs): 8216982: Assertion poison page established too early Message-ID: Hi all, may I please have a review for the following fix: cr: http://cr.openjdk.java.net/~stuefe/webrevs/jdk-8216982-assertion-poison-page-established-too-early/webrev.00/webrev/ bug: https://bugs.openjdk.java.net/browse/JDK-8216982 In short, the assertion poison page is established during initialization using os::reserve/commit_memory; however, the os:: subsystem is not yet fully initialized at that point. The patch moves the initialization after os::init_2(), it is now established at the same point as the safepoint polling page. The initialization can moved back safely - the only drawbacks would be asserts happening earlier than this point not having register output in the error file. Thanks, Thomas From martin.doerr at sap.com Mon Jan 14 15:45:06 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 14 Jan 2019 15:45:06 +0000 Subject: RFR(xxs): 8216982: Assertion poison page established too early In-Reply-To: References: Message-ID: <289b0d2399484b2c9450bc1c3815299f@sap.com> Hi Thomas, thanks for fixing. Looks good. Best regards, Martin -----Original Message----- From: hotspot-runtime-dev On Behalf Of Thomas St?fe Sent: Montag, 14. Januar 2019 16:16 To: Hotspot dev runtime Subject: RFR(xxs): 8216982: Assertion poison page established too early Hi all, may I please have a review for the following fix: cr: http://cr.openjdk.java.net/~stuefe/webrevs/jdk-8216982-assertion-poison-page-established-too-early/webrev.00/webrev/ bug: https://bugs.openjdk.java.net/browse/JDK-8216982 In short, the assertion poison page is established during initialization using os::reserve/commit_memory; however, the os:: subsystem is not yet fully initialized at that point. The patch moves the initialization after os::init_2(), it is now established at the same point as the safepoint polling page. The initialization can moved back safely - the only drawbacks would be asserts happening earlier than this point not having register output in the error file. Thanks, Thomas From thomas.stuefe at gmail.com Mon Jan 14 15:49:48 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 14 Jan 2019 16:49:48 +0100 Subject: RFR(xxs): 8216982: Assertion poison page established too early In-Reply-To: <289b0d2399484b2c9450bc1c3815299f@sap.com> References: <289b0d2399484b2c9450bc1c3815299f@sap.com> Message-ID: Thanks Martin! On Mon, Jan 14, 2019, 16:45 Doerr, Martin Hi Thomas, > > thanks for fixing. Looks good. > > Best regards, > Martin > > > -----Original Message----- > From: hotspot-runtime-dev > On Behalf Of Thomas St?fe > Sent: Montag, 14. Januar 2019 16:16 > To: Hotspot dev runtime > Subject: RFR(xxs): 8216982: Assertion poison page established too early > > Hi all, > > may I please have a review for the following fix: > > cr: > > http://cr.openjdk.java.net/~stuefe/webrevs/jdk-8216982-assertion-poison-page-established-too-early/webrev.00/webrev/ > bug: https://bugs.openjdk.java.net/browse/JDK-8216982 > > In short, the assertion poison page is established during initialization > using os::reserve/commit_memory; however, the os:: subsystem is not yet > fully initialized at that point. > > The patch moves the initialization after os::init_2(), it is now > established at the same point as the safepoint polling page. The > initialization can moved back safely - the only drawbacks would be asserts > happening earlier than this point not having register output in the error > file. > > Thanks, Thomas > From thomas.stuefe at gmail.com Mon Jan 14 16:01:41 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 14 Jan 2019 17:01:41 +0100 Subject: RFR(s): 8214975: No hs-err file if fatal error is raised during dynamic initialization. In-Reply-To: <7c918c7b-6e14-5d60-7677-ab552015936a@oracle.com> References: <7c918c7b-6e14-5d60-7677-ab552015936a@oracle.com> Message-ID: Hi David, Dan, sorry for the extremely long delay. I have been away some weeks. Could you please give this patch a final glance? cr (full): http://cr.openjdk.java.net/~stuefe/webrevs/8214975-no-hs-errfile-on-early-assert/webrev.00/webrev/ cr (delta); http://cr.openjdk.java.net/~stuefe/webrevs/8214975-no-hs-errfile-on-early-assert/webrev_delta.00/webrev/ I only added some small comments and reworked the closing of the hs-err file since David was right - in case the hs-err file could not be opened, we'd call close(-1). Thank you! Cheers, Thomas On Tue, Dec 11, 2018 at 1:58 AM David Holmes wrote: > Hi Thomas, > > On 8/12/2018 9:21 pm, Thomas St?fe wrote: > > Hi, > > > > may I please have reviews for this small patch: > > > > https://bugs.openjdk.java.net/browse/JDK-8214975 > > > http://cr.openjdk.java.net/~stuefe/webrevs/8214975-no-hs-errfile-on-early-assert/webrev.00/webrev > > > > A fatal error (e.g. assert), if triggered during dynamic > > initialization, will plain kill the VM without a trace. (A) > > > > A alternative variant of this error: VM will get caught up in an > > endless recursion, repeat "[Too many errors, abort]\n" endlessly, > > quickly growing its RSS until the OOM Killer kills it. (B) > > > > These symptoms are all caused by VMError::report() attempting to write > > to an uninitialized fdStream object (VMError::out and VMError::log). > > These object instances are allocated at global file scope: > > > > 1199 fdStream VMError::out(defaultStream::output_fd()); > > 1200 fdStream VMError::log; // error log used by > VMError::report_and_die() > > > > They are non-trivial (have vtables) and need to be initialized > > themselves before being used. If the assert happens before they are > > initialized, the vtables will not yet have been set up, and once we > > attempt to call out::write() or log::write(), in an context where we > > only have an outputStream* ptr (e.g. VMError::report()), we crash. > > > > Depending on which one of VMError::log and VMError::out are still > > uninitialized, we end up in (A) or (B). In both cases, the secondary > > signal handler (crash_handler()) will catch the signal, re-try error > > reporting and crash again. This is an endless cycle. We do have > > recursion detection in place to stop this cycle: > > > > 1388 if (recursive_error_count++ > 30) { > > 1389 out.print_raw_cr("[Too many errors, abort]"); > > 1390 os::die(); > > 1391 } > > > > but this again uses methods of outputStream to write the "Too many > > errors" text, which will crash again before ever reaching os::die(). > > > > -- > > > > Solution: do not rely on global non-trivial C++ objects, especially > > not at global scope. Instead, keep the information which must be > > preserved across recursions and different threads (which are only the > > logfile handles themselves) in non-c++ (POD) ints. > > > > As added safety, do not keep them at global scope but at static > > function-scope inside VMError::report_and_die() - that moves their > > initialization back to the first time they are called. To print, we > > still need outputStream objects of course, but they can be restricted > > to function scope inside VMError::report_and_die(), and can be > > recreated each time this function is entered, be it because of > > recursions of from a different thread. > > Okay this seems reasonable - the log is local but the fd it uses is > static. Only comment is that if prepare_log_file return -1 then we will > call close(-1) here: > > 1476 if (fd_log != fd_out) { > 1477 close(fd_log); > 1478 } > > I would have expected to assign to a temporary and only update fd_log if > not -1. > > > Additionally, a jtreg regression test is added. > > Nit: s/the hotspot/hotspot/ > > I note that producing the hs_err log from the test actually induces > numerous secondary errors. Seems there moay be opportunity to make other > parts of error reporting even more robust. > > Thanks, > David > > > Thanks, Thomas > > > From martin.doerr at sap.com Mon Jan 14 16:39:25 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 14 Jan 2019 16:39:25 +0000 Subject: RFR(S): 8216426: Usage of array placement new may lead to memory corruption Message-ID: <61066e81213e40e2840d79025931e597@sap.com> Hi, thanks for looking at this issue and especially for adding comments. Sounds like this issue should better get fixed although there are no known problems. Should we fix it by replacing the array placement new by normal placement new for each element? http://cr.openjdk.java.net/~mdoerr/8216426_array_placement_new/webrev.00/ Best regards, Martin From claes.redestad at oracle.com Mon Jan 14 17:33:45 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 14 Jan 2019 18:33:45 +0100 Subject: RFR: 8216995: Clean up JFR command line processing Message-ID: <067a669e-11e3-25dc-9ab4-77643e0caa1f@oracle.com> Hi, JFR setup could be simplified by using macros defined in globals_extension.hpp rather than use JVMFlag directly. On top of looking cleaner this avoids JVMFlag::find_flag, which does a linear scan of all flags. So a tiny startup optimization (detectable only with special goggles). Webrev: http://cr.openjdk.java.net/~redestad/8216995/open.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8216995 Testing: tier1-2 (ongoing) Thanks! /Claes From gerard.ziemski at oracle.com Mon Jan 14 19:19:23 2019 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Mon, 14 Jan 2019 13:19:23 -0600 Subject: RFR: 8216995: Clean up JFR command line processing In-Reply-To: <067a669e-11e3-25dc-9ab4-77643e0caa1f@oracle.com> References: <067a669e-11e3-25dc-9ab4-77643e0caa1f@oracle.com> Message-ID: hi Claes, Looks good. If I had to change anything, then in "src/hotspot/share/jfr/recorder/jfrRecorder.cpp" I would probably prefer to see something like: + FLAG_SET_MGMT(bool, FlightRecorder, true); + _enabled = FlightRecorder; + assert(_enabled == true, ?must be"); instead of: + FLAG_SET_MGMT(bool, FlightRecorder, true); + _enabled = true; cheers > On Jan 14, 2019, at 11:33 AM, Claes Redestad wrote: > > Hi, > > JFR setup could be simplified by using macros defined > in globals_extension.hpp rather than use JVMFlag directly. > > On top of looking cleaner this avoids JVMFlag::find_flag, which does a > linear scan of all flags. So a tiny startup optimization (detectable > only with special goggles). > > Webrev: http://cr.openjdk.java.net/~redestad/8216995/open.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8216995 > > Testing: tier1-2 (ongoing) > > Thanks! > > /Claes From david.holmes at oracle.com Mon Jan 14 22:01:16 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Jan 2019 08:01:16 +1000 Subject: RFR (S): 8213397: Stack dump should show more clearly when a thread is blocked on a class initialization monitor In-Reply-To: <85e5d3a6-5b44-acaf-b7eb-f29b40e9b4a9@oracle.com> References: <90bcd939-2066-0a3b-743a-a2c4d55954d7@oracle.com> <85e5d3a6-5b44-acaf-b7eb-f29b40e9b4a9@oracle.com> Message-ID: <89859b9b-fd75-923b-145d-e3b8ee2d3fb6@oracle.com> Hi Robbin, On 14/01/2019 11:08 pm, David Holmes wrote: > Hi Robbin, > > On 14/01/2019 6:54 pm, Robbin Ehn wrote: >> Hi David, looks good. > > Thanks for the review. > >> In the test I would prefer e.g. semaphore acquire/release instead of >> boolean ready with sleep. (in this case it doesn't seem to make much >> of a difference) >> So do as you wish, I do not need to see a new webrev if you choose to >> change. > > Okay. Path of least resistance ... Actually there's a reason not to use something like Semaphore and that is because we want the "ready" signal to happen as close as possible to the static initialization attempt. If I used a semaphore there's a much greater chance we will still be inside Semaphore code when the jstack is executed. This realization also made me realise that using "new Target()" to trigger static initialization is not the best thing to do because it will perform the allocation first, and then call the constructor that will result in the static init. So I've changed it to access a static field instead. Updated webrev: http://cr.openjdk.java.net/~dholmes/8213397/webrev.v2 This also addresses Coleen's suggestion to remove the assert in the vframe code. Thanks, David ----- > Thanks, > David > >> Thanks, Robbin >> >> On 1/14/19 7:01 AM, David Holmes wrote: >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8213397 >>> webrev: http://cr.openjdk.java.net/~dholmes/8213397/webrev/ >>> >>> Please review this simple enhancement to improve the stack trace >>> information when a thread is blocked doing a (logical) Object.wait on >>> the monitor associated with Class static initialization. >>> >>> Details are in the bug report but basically we record, in a >>> thread-local variable, the name of the class before the "wait" and >>> clear it after, thus allowing the stack dump code to query it if it >>> appears we may be in that situation. >>> >>> In InstanceKlass::initialize_impl I also refactored the code a tiny >>> bit to make use of the JavaThread reference to the current thread. >>> >>> A new test using jstack was also added. >>> >>> Testing: >>> ?? - mach5 tiers 1 - 3 >>> ?? - the new test on Windows/Linux/OSX x86 and Solaris sparc, in >>> regular and Xcomp mode >>> ?? - All jstack/stack-dump using tests I could see (linux x64): >>> ???? - runtime/Thread >>> ???? - serviceability/sa/ >>> ???? - serviceability/tmtools/jstack/ >>> ???? - vmTestbase/nsk/jvmti/scenarios/sampling/ >>> ???? - vmTestbase/nsk/jvmti/MonitorWaited/ . >>> ???? - vmTestbase/nsk/jvmti/GetOwnedMonitorInfo/ >>> >>> Thanks, >>> David From kim.barrett at oracle.com Tue Jan 15 01:48:08 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 14 Jan 2019 20:48:08 -0500 Subject: RFR(S): 8216426: Usage of array placement new may lead to memory corruption In-Reply-To: <61066e81213e40e2840d79025931e597@sap.com> References: <61066e81213e40e2840d79025931e597@sap.com> Message-ID: <7ABB1142-C876-455B-BF7B-641F6AA1DF88@oracle.com> > On Jan 14, 2019, at 11:39 AM, Doerr, Martin wrote: > > Hi, > > thanks for looking at this issue and especially for adding comments. > Sounds like this issue should better get fixed although there are no known problems. > > Should we fix it by replacing the array placement new by normal placement new for each element? > http://cr.openjdk.java.net/~mdoerr/8216426_array_placement_new/webrev.00/ > > Best regards, > Martin Looks good. ------------------------------------------------------------------------------ src/hotspot/share/utilities/concurrentHashTable.hpp 76 // Only constructed with placement new from an array allocated with MEMFLAGS 77 // of InternalTable. Given this comment, I'm tempted to suggest making the constructor private and having a public "static Bucket* make_array(size_t size)" function. Then remove the comment... But I'm not going to require such a change to pass review. ------------------------------------------------------------------------------ src/hotspot/share/utilities/concurrentHashTable.inline.hpp 196 _buckets = (Bucket*)NEW_C_HEAP_ARRAY(Bucket, _size, F); No cast needed here. NEW_C_HEAP_ARRAY(T, ...) returns T*. I don't need another review for just this change. ------------------------------------------------------------------------------ From david.holmes at oracle.com Tue Jan 15 04:13:07 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Jan 2019 14:13:07 +1000 Subject: RFR(xxs): 8216982: Assertion poison page established too early In-Reply-To: References: Message-ID: Looks good. Please update copyright year to 2019. Thanks, David On 15/01/2019 1:15 am, Thomas St?fe wrote: > Hi all, > > may I please have a review for the following fix: > > cr: > http://cr.openjdk.java.net/~stuefe/webrevs/jdk-8216982-assertion-poison-page-established-too-early/webrev.00/webrev/ > bug: https://bugs.openjdk.java.net/browse/JDK-8216982 > > In short, the assertion poison page is established during initialization > using os::reserve/commit_memory; however, the os:: subsystem is not yet > fully initialized at that point. > > The patch moves the initialization after os::init_2(), it is now > established at the same point as the safepoint polling page. The > initialization can moved back safely - the only drawbacks would be asserts > happening earlier than this point not having register output in the error > file. > > Thanks, Thomas > From david.holmes at oracle.com Tue Jan 15 04:15:30 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Jan 2019 14:15:30 +1000 Subject: RFR(s): 8214975: No hs-err file if fatal error is raised during dynamic initialization. In-Reply-To: References: <7c918c7b-6e14-5d60-7677-ab552015936a@oracle.com> Message-ID: <8e1cbb3f-2a40-0594-459f-0143a6c622f9@oracle.com> Hi Thomas, That seems fine to me. Please update copyright years to 2019. Thanks, David On 15/01/2019 2:01 am, Thomas St?fe wrote: > Hi David, Dan, > > sorry for the extremely long delay. I have been away some weeks. > > Could you please give this patch a final glance? > > cr (full): > http://cr.openjdk.java.net/~stuefe/webrevs/8214975-no-hs-errfile-on-early-assert/webrev.00/webrev/ > cr (delta); > http://cr.openjdk.java.net/~stuefe/webrevs/8214975-no-hs-errfile-on-early-assert/webrev_delta.00/webrev/ > > I only added some small comments and reworked the closing of the hs-err > file since David was right - in case the hs-err file could not be > opened, we'd call close(-1). > > Thank you! > > Cheers, Thomas > > > On Tue, Dec 11, 2018 at 1:58 AM David Holmes > wrote: > > Hi Thomas, > > On 8/12/2018 9:21 pm, Thomas St?fe wrote: > > Hi, > > > > may I please have reviews for this small patch: > > > > https://bugs.openjdk.java.net/browse/JDK-8214975 > > > http://cr.openjdk.java.net/~stuefe/webrevs/8214975-no-hs-errfile-on-early-assert/webrev.00/webrev > > > > A fatal error (e.g. assert), if triggered during dynamic > > initialization, will plain kill the VM without a trace. (A) > > > > A alternative variant of this error: VM will get caught up in an > > endless recursion, repeat "[Too many errors, abort]\n" endlessly, > > quickly growing its RSS until the OOM Killer kills it. (B) > > > > These symptoms are all caused by VMError::report() attempting to > write > > to an uninitialized fdStream object (VMError::out and VMError::log). > > These object instances are allocated at global file scope: > > > > 1199 fdStream VMError::out(defaultStream::output_fd()); > > 1200 fdStream VMError::log; // error log used by > VMError::report_and_die() > > > > They are non-trivial (have vtables) and need to be initialized > > themselves before being used. If the assert happens before they are > > initialized, the vtables will not yet have been set up, and once we > > attempt to call out::write() or log::write(), in an context where we > > only have an outputStream* ptr (e.g. VMError::report()), we crash. > > > > Depending on which one of VMError::log and VMError::out are still > > uninitialized, we end up in (A) or (B). In both cases, the secondary > > signal handler (crash_handler()) will catch the signal, re-try error > > reporting and crash again. This is an endless cycle. We do have > > recursion detection in place to stop this cycle: > > > > 1388 if (recursive_error_count++ > 30) { > > 1389 out.print_raw_cr("[Too many errors, abort]"); > > 1390 os::die(); > > 1391 } > > > > but this again uses methods of outputStream to write the "Too many > > errors" text, which will crash again before ever reaching os::die(). > > > > -- > > > > Solution: do not rely on global non-trivial C++ objects, especially > > not at global scope. Instead, keep the information which must be > > preserved across recursions and different threads (which are only the > > logfile handles themselves) in non-c++ (POD) ints. > > > > As added safety, do not keep them at global scope but at static > > function-scope inside VMError::report_and_die() - that moves their > > initialization back to the first time they are called. To print, we > > still need outputStream objects of course, but they can be restricted > > to function scope inside VMError::report_and_die(), and can be > > recreated each time this function is entered, be it because of > > recursions of from a different thread. > > Okay this seems reasonable - the log is local but the fd it uses is > static. Only comment is that if prepare_log_file return -1 then we will > call close(-1) here: > > 1476? ? ?if (fd_log != fd_out) { > 1477? ? ? ?close(fd_log); > 1478? ? ?} > > I would have expected to assign to a temporary and only update > fd_log if > not -1. > > > Additionally, a jtreg regression test is added. > > Nit: s/the hotspot/hotspot/ > > I note that producing the hs_err log from the test actually induces > numerous secondary errors. Seems there moay be opportunity to make > other > parts of error reporting even more robust. > > Thanks, > David > > > Thanks, Thomas > > > From thomas.stuefe at gmail.com Tue Jan 15 07:03:42 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 15 Jan 2019 08:03:42 +0100 Subject: RFR(xxs): 8216982: Assertion poison page established too early In-Reply-To: References: Message-ID: Thanks David! On Tue, Jan 15, 2019 at 5:13 AM David Holmes wrote: > Looks good. > > Please update copyright year to 2019. > > Thanks, > David > > On 15/01/2019 1:15 am, Thomas St?fe wrote: > > Hi all, > > > > may I please have a review for the following fix: > > > > cr: > > > http://cr.openjdk.java.net/~stuefe/webrevs/jdk-8216982-assertion-poison-page-established-too-early/webrev.00/webrev/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8216982 > > > > In short, the assertion poison page is established during initialization > > using os::reserve/commit_memory; however, the os:: subsystem is not yet > > fully initialized at that point. > > > > The patch moves the initialization after os::init_2(), it is now > > established at the same point as the safepoint polling page. The > > initialization can moved back safely - the only drawbacks would be > asserts > > happening earlier than this point not having register output in the error > > file. > > > > Thanks, Thomas > > > From robbin.ehn at oracle.com Tue Jan 15 08:03:04 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 15 Jan 2019 09:03:04 +0100 Subject: RFR(S): 8216426: Usage of array placement new may lead to memory corruption In-Reply-To: <61066e81213e40e2840d79025931e597@sap.com> References: <61066e81213e40e2840d79025931e597@sap.com> Message-ID: Hi Martin, The Bucket should extend CHeapObj, now that it could. Otherwise looks good, thanks. Originally Bucket did this and I used memset, but gdb was very upset by this. So I changed to array placement new, which meant I had to remove CHeapObj if I remember correctly :) /Robbin On 2019-01-14 17:39, Doerr, Martin wrote: > Hi, > > thanks for looking at this issue and especially for adding comments. > Sounds like this issue should better get fixed although there are no known problems. > > Should we fix it by replacing the array placement new by normal placement new for each element? > http://cr.openjdk.java.net/~mdoerr/8216426_array_placement_new/webrev.00/ > > Best regards, > Martin > From robbin.ehn at oracle.com Tue Jan 15 08:13:42 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 15 Jan 2019 09:13:42 +0100 Subject: RFR (S): 8213397: Stack dump should show more clearly when a thread is blocked on a class initialization monitor In-Reply-To: <89859b9b-fd75-923b-145d-e3b8ee2d3fb6@oracle.com> References: <90bcd939-2066-0a3b-743a-a2c4d55954d7@oracle.com> <85e5d3a6-5b44-acaf-b7eb-f29b40e9b4a9@oracle.com> <89859b9b-fd75-923b-145d-e3b8ee2d3fb6@oracle.com> Message-ID: <9c6e8464-5e76-c151-af34-6a4e92b0ab1b@oracle.com> > > http://cr.openjdk.java.net/~dholmes/8213397/webrev.v2 Ship it! /Robbin > > This also addresses Coleen's suggestion to remove the assert in the vframe code. > > Thanks, > David > ----- > > >> Thanks, >> David >> >>> Thanks, Robbin >>> >>> On 1/14/19 7:01 AM, David Holmes wrote: >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8213397 >>>> webrev: http://cr.openjdk.java.net/~dholmes/8213397/webrev/ >>>> >>>> Please review this simple enhancement to improve the stack trace information when a thread is blocked doing a >>>> (logical) Object.wait on the monitor associated with Class static initialization. >>>> >>>> Details are in the bug report but basically we record, in a thread-local variable, the name of the class before the >>>> "wait" and clear it after, thus allowing the stack dump code to query it if it appears we may be in that situation. >>>> >>>> In InstanceKlass::initialize_impl I also refactored the code a tiny bit to make use of the JavaThread reference to >>>> the current thread. >>>> >>>> A new test using jstack was also added. >>>> >>>> Testing: >>>> ?? - mach5 tiers 1 - 3 >>>> ?? - the new test on Windows/Linux/OSX x86 and Solaris sparc, in regular and Xcomp mode >>>> ?? - All jstack/stack-dump using tests I could see (linux x64): >>>> ???? - runtime/Thread >>>> ???? - serviceability/sa/ >>>> ???? - serviceability/tmtools/jstack/ >>>> ???? - vmTestbase/nsk/jvmti/scenarios/sampling/ >>>> ???? - vmTestbase/nsk/jvmti/MonitorWaited/ . >>>> ???? - vmTestbase/nsk/jvmti/GetOwnedMonitorInfo/ >>>> >>>> Thanks, >>>> David From david.holmes at oracle.com Tue Jan 15 08:45:16 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Jan 2019 18:45:16 +1000 Subject: RFR (S): 8213397: Stack dump should show more clearly when a thread is blocked on a class initialization monitor In-Reply-To: <9c6e8464-5e76-c151-af34-6a4e92b0ab1b@oracle.com> References: <90bcd939-2066-0a3b-743a-a2c4d55954d7@oracle.com> <85e5d3a6-5b44-acaf-b7eb-f29b40e9b4a9@oracle.com> <89859b9b-fd75-923b-145d-e3b8ee2d3fb6@oracle.com> <9c6e8464-5e76-c151-af34-6a4e92b0ab1b@oracle.com> Message-ID: Thanks again Robbin. David On 15/01/2019 6:13 pm, Robbin Ehn wrote: >> >> http://cr.openjdk.java.net/~dholmes/8213397/webrev.v2 > > Ship it! > > /Robbin > >> >> This also addresses Coleen's suggestion to remove the assert in the >> vframe code. >> >> Thanks, >> David >> ----- >> >> >>> Thanks, >>> David >>> >>>> Thanks, Robbin >>>> >>>> On 1/14/19 7:01 AM, David Holmes wrote: >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8213397 >>>>> webrev: http://cr.openjdk.java.net/~dholmes/8213397/webrev/ >>>>> >>>>> Please review this simple enhancement to improve the stack trace >>>>> information when a thread is blocked doing a (logical) Object.wait >>>>> on the monitor associated with Class static initialization. >>>>> >>>>> Details are in the bug report but basically we record, in a >>>>> thread-local variable, the name of the class before the "wait" and >>>>> clear it after, thus allowing the stack dump code to query it if it >>>>> appears we may be in that situation. >>>>> >>>>> In InstanceKlass::initialize_impl I also refactored the code a tiny >>>>> bit to make use of the JavaThread reference to the current thread. >>>>> >>>>> A new test using jstack was also added. >>>>> >>>>> Testing: >>>>> ?? - mach5 tiers 1 - 3 >>>>> ?? - the new test on Windows/Linux/OSX x86 and Solaris sparc, in >>>>> regular and Xcomp mode >>>>> ?? - All jstack/stack-dump using tests I could see (linux x64): >>>>> ???? - runtime/Thread >>>>> ???? - serviceability/sa/ >>>>> ???? - serviceability/tmtools/jstack/ >>>>> ???? - vmTestbase/nsk/jvmti/scenarios/sampling/ >>>>> ???? - vmTestbase/nsk/jvmti/MonitorWaited/ . >>>>> ???? - vmTestbase/nsk/jvmti/GetOwnedMonitorInfo/ >>>>> >>>>> Thanks, >>>>> David From erik.osterlund at oracle.com Tue Jan 15 09:15:14 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Tue, 15 Jan 2019 10:15:14 +0100 Subject: RFR(S): 8216426: Usage of array placement new may lead to memory corruption In-Reply-To: References: <61066e81213e40e2840d79025931e597@sap.com> Message-ID: Hi, Perhaps an alternative approach is to make the Bucket a POD (make the private member public, and remove the constructor), and then simply memset the memory to zero. Thanks, /Erik On 2019-01-15 09:03, Robbin Ehn wrote: > Hi Martin, > > The Bucket should extend CHeapObj, now that it could. > Otherwise looks good, thanks. > > Originally Bucket did this and I used memset, but gdb was very upset > by this. > So I changed to array placement new, which meant I had to remove > CHeapObj if I remember correctly :) > > /Robbin > > On 2019-01-14 17:39, Doerr, Martin wrote: >> Hi, >> >> thanks for looking at this issue and especially for adding comments. >> Sounds like this issue should better get fixed although there are no >> known problems. >> >> Should we fix it by replacing the array placement new by normal >> placement new for each element? >> http://cr.openjdk.java.net/~mdoerr/8216426_array_placement_new/webrev.00/ >> >> >> Best regards, >> Martin >> From robbin.ehn at oracle.com Tue Jan 15 09:26:00 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 15 Jan 2019 10:26:00 +0100 Subject: RFR(S): 8216426: Usage of array placement new may lead to memory corruption In-Reply-To: References: <61066e81213e40e2840d79025931e597@sap.com> Message-ID: <6fed501b-3f9a-1fc6-78fb-fb64741893c3@oracle.com> On 2019-01-15 10:15, Erik ?sterlund wrote: > Hi, > > Perhaps an alternative approach is to make the Bucket a POD (make the private member public, and remove the > constructor), and then simply memset the memory to zero. Sorry, we have NMT tracking via NEW_C_HEAP_ARRAY(Bucket, _size, F);. So yes, make it a POD and use memset. /Robbin > > Thanks, > /Erik > > On 2019-01-15 09:03, Robbin Ehn wrote: >> Hi Martin, >> >> The Bucket should extend CHeapObj, now that it could. >> Otherwise looks good, thanks. >> >> Originally Bucket did this and I used memset, but gdb was very upset by this. >> So I changed to array placement new, which meant I had to remove CHeapObj if I remember correctly :) >> >> /Robbin >> >> On 2019-01-14 17:39, Doerr, Martin wrote: >>> Hi, >>> >>> thanks for looking at this issue and especially for adding comments. >>> Sounds like this issue should better get fixed although there are no known problems. >>> >>> Should we fix it by replacing the array placement new by normal placement new for each element? >>> http://cr.openjdk.java.net/~mdoerr/8216426_array_placement_new/webrev.00/ >>> >>> Best regards, >>> Martin >>> > From markus.gronlund at oracle.com Tue Jan 15 09:34:57 2019 From: markus.gronlund at oracle.com (Markus Gronlund) Date: Tue, 15 Jan 2019 01:34:57 -0800 (PST) Subject: RFR: 8216995: Clean up JFR command line processing In-Reply-To: <067a669e-11e3-25dc-9ab4-77643e0caa1f@oracle.com> References: <067a669e-11e3-25dc-9ab4-77643e0caa1f@oracle.com> Message-ID: <7c894f25-0c80-4428-9f39-ad2144c9d922@default> Hi Claes, Looks good, thanks for fixing this. Markus -----Original Message----- From: Claes Redestad Sent: den 14 januari 2019 18:34 To: Hotspot dev runtime ; hotspot-jfr-dev at openjdk.java.net Subject: RFR: 8216995: Clean up JFR command line processing Hi, JFR setup could be simplified by using macros defined in globals_extension.hpp rather than use JVMFlag directly. On top of looking cleaner this avoids JVMFlag::find_flag, which does a linear scan of all flags. So a tiny startup optimization (detectable only with special goggles). Webrev: http://cr.openjdk.java.net/~redestad/8216995/open.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8216995 Testing: tier1-2 (ongoing) Thanks! /Claes From claes.redestad at oracle.com Tue Jan 15 10:29:34 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 15 Jan 2019 11:29:34 +0100 Subject: RFR: 8216995: Clean up JFR command line processing In-Reply-To: <7c894f25-0c80-4428-9f39-ad2144c9d922@default> References: <067a669e-11e3-25dc-9ab4-77643e0caa1f@oracle.com> <7c894f25-0c80-4428-9f39-ad2144c9d922@default> Message-ID: <7f623e67-46b4-ee0c-68a0-926febf8be7e@oracle.com> Thanks, Markus! /Claes On 2019-01-15 10:34, Markus Gronlund wrote: > Hi Claes, > > Looks good, thanks for fixing this. > > Markus > > -----Original Message----- > From: Claes Redestad > Sent: den 14 januari 2019 18:34 > To: Hotspot dev runtime ; hotspot-jfr-dev at openjdk.java.net > Subject: RFR: 8216995: Clean up JFR command line processing > > Hi, > > JFR setup could be simplified by using macros defined in globals_extension.hpp rather than use JVMFlag directly. > > On top of looking cleaner this avoids JVMFlag::find_flag, which does a linear scan of all flags. So a tiny startup optimization (detectable only with special goggles). > > Webrev: http://cr.openjdk.java.net/~redestad/8216995/open.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8216995 > > Testing: tier1-2 (ongoing) > > Thanks! > > /Claes > From claes.redestad at oracle.com Tue Jan 15 10:34:59 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 15 Jan 2019 11:34:59 +0100 Subject: RFR: 8216995: Clean up JFR command line processing In-Reply-To: References: <067a669e-11e3-25dc-9ab4-77643e0caa1f@oracle.com> Message-ID: <4d552d11-4d27-1166-2b60-2c0cf4c8c5c8@oracle.com> On 2019-01-14 20:19, Gerard Ziemski wrote: > hi Claes, > > Looks good. Thanks! > If I had to change anything, then in "src/hotspot/share/jfr/recorder/jfrRecorder.cpp" I would probably prefer to see something like: > > + FLAG_SET_MGMT(bool, FlightRecorder, true); > + _enabled = FlightRecorder; > + assert(_enabled == true, ?must be"); > > instead of: > > + FLAG_SET_MGMT(bool, FlightRecorder, true); > + _enabled = true; Ok, I'll re-test and push with this small adjustment: FLAG_SET_MGMT(bool, FlightRecorder, true); - _enabled = true; + _enabled = FlightRecorder; + assert(_enabled, "invariant"); return _enabled; /Claes > > > cheers > > >> On Jan 14, 2019, at 11:33 AM, Claes Redestad wrote: >> >> Hi, >> >> JFR setup could be simplified by using macros defined >> in globals_extension.hpp rather than use JVMFlag directly. >> >> On top of looking cleaner this avoids JVMFlag::find_flag, which does a >> linear scan of all flags. So a tiny startup optimization (detectable >> only with special goggles). >> >> Webrev: http://cr.openjdk.java.net/~redestad/8216995/open.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8216995 >> >> Testing: tier1-2 (ongoing) >> >> Thanks! >> >> /Claes > From martin.doerr at sap.com Tue Jan 15 10:51:50 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 15 Jan 2019 10:51:50 +0000 Subject: RFR(S): 8216426: Usage of array placement new may lead to memory corruption In-Reply-To: <6fed501b-3f9a-1fc6-78fb-fb64741893c3@oracle.com> References: <61066e81213e40e2840d79025931e597@sap.com> <6fed501b-3f9a-1fc6-78fb-fb64741893c3@oracle.com> Message-ID: <74c66ced7285482290ab7ad5105955c7@sap.com> Hi Robbin, that's fine. I like it simple. Version which uses memset and removed constructor: http://cr.openjdk.java.net/~mdoerr/8216426_array_placement_new/webrev.01/ I don't like making the field public because it can easily get used incorrectly because there are bits encoded into the pointer. So I think we should better not provide direct access to it. Best regards, Martin -----Original Message----- From: Robbin Ehn Sent: Dienstag, 15. Januar 2019 10:26 To: Erik ?sterlund ; Doerr, Martin ; hotspot-runtime-dev at openjdk.java.net; Kim Barrett ; David Holmes (david.holmes at oracle.com) Subject: Re: RFR(S): 8216426: Usage of array placement new may lead to memory corruption On 2019-01-15 10:15, Erik ?sterlund wrote: > Hi, > > Perhaps an alternative approach is to make the Bucket a POD (make the private member public, and remove the > constructor), and then simply memset the memory to zero. Sorry, we have NMT tracking via NEW_C_HEAP_ARRAY(Bucket, _size, F);. So yes, make it a POD and use memset. /Robbin > > Thanks, > /Erik > > On 2019-01-15 09:03, Robbin Ehn wrote: >> Hi Martin, >> >> The Bucket should extend CHeapObj, now that it could. >> Otherwise looks good, thanks. >> >> Originally Bucket did this and I used memset, but gdb was very upset by this. >> So I changed to array placement new, which meant I had to remove CHeapObj if I remember correctly :) >> >> /Robbin >> >> On 2019-01-14 17:39, Doerr, Martin wrote: >>> Hi, >>> >>> thanks for looking at this issue and especially for adding comments. >>> Sounds like this issue should better get fixed although there are no known problems. >>> >>> Should we fix it by replacing the array placement new by normal placement new for each element? >>> http://cr.openjdk.java.net/~mdoerr/8216426_array_placement_new/webrev.00/ >>> >>> Best regards, >>> Martin >>> > From goetz.lindenmaier at sap.com Tue Jan 15 11:09:58 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 15 Jan 2019 11:09:58 +0000 Subject: RFR(S): 8217044: [aix] Launcher still adds old path to jli library to LIBPATH Message-ID: <256a5fa8b3c4439581fdadee2e739ae5@sap.com> Hi, As AIX does not know $ORIGIN the path to libjli must be in LIBPATH. libjli though has been moved from lib/jli/ to lib/. The path to lib/ is added to LIBPATH anyways, so we can remove the special case for AIX. Please review this small cleanup. http://cr.openjdk.java.net/~goetz/wr19/8217044-aixLauncher/01/ Best regards, Goetz. From goetz.lindenmaier at sap.com Tue Jan 15 11:12:37 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 15 Jan 2019 11:12:37 +0000 Subject: RFR(S): 8217044: [aix] Launcher still adds old path to jli library to LIBPATH In-Reply-To: <256a5fa8b3c4439581fdadee2e739ae5@sap.com> References: <256a5fa8b3c4439581fdadee2e739ae5@sap.com> Message-ID: <9d552dc7b4224b98ae2651a17fae6da7@sap.com> Ah... a small add on: There is one other reference to /jli in the code I could find: diff -r 3d6da8a542ab -r 32af46822a7a test/hotspot/gtest/gtestMain.cpp --- a/test/hotspot/gtest/gtestMain.cpp Mon Jan 14 17:22:23 2019 +0100 +++ b/test/hotspot/gtest/gtestMain.cpp Tue Jan 15 10:15:39 2019 +0100 @@ -224,9 +224,9 @@ // workaround for JDK-7131356 #ifdef __APPLE__ - size_t len = strlen(java_home) + strlen("/lib/jli/libjli.dylib") + 1; + size_t len = strlen(java_home) + strlen("/lib/libjli.dylib") + 1; char* path = new char[len]; - snprintf(path, len, "%s/lib/jli/libjli.dylib", java_home); + snprintf(path, len, "%s/lib/libjli.dylib", java_home); dlopen(path, RTLD_NOW | RTLD_GLOBAL); #endif // __APPLE__ Should I add this to this patch, too? Best regards, Goetz. > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Dienstag, 15. Januar 2019 12:10 > To: hotspot-runtime-dev at openjdk.java.net > Subject: RFR(S): 8217044: [aix] Launcher still adds old path to jli library to > LIBPATH > > Hi, > > > > As AIX does not know $ORIGIN the path to libjli must be in LIBPATH. libjli > though has been moved from lib/jli/ to lib/. The path to lib/ is added to > LIBPATH anyways, so we can remove the special case for AIX. > > > > Please review this small cleanup. > > http://cr.openjdk.java.net/~goetz/wr19/8217044-aixLauncher/01/ > > > > Best regards, > > Goetz. From robbin.ehn at oracle.com Tue Jan 15 11:38:33 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 15 Jan 2019 12:38:33 +0100 Subject: RFR(S): 8216426: Usage of array placement new may lead to memory corruption In-Reply-To: <74c66ced7285482290ab7ad5105955c7@sap.com> References: <61066e81213e40e2840d79025931e597@sap.com> <6fed501b-3f9a-1fc6-78fb-fb64741893c3@oracle.com> <74c66ced7285482290ab7ad5105955c7@sap.com> Message-ID: Hi Martin, Thanks for fixing, looks good! /Robbin On 2019-01-15 11:51, Doerr, Martin wrote: > Hi Robbin, > > that's fine. I like it simple. > > Version which uses memset and removed constructor: > http://cr.openjdk.java.net/~mdoerr/8216426_array_placement_new/webrev.01/ > > I don't like making the field public because it can easily get used incorrectly because there are bits encoded into the pointer. > So I think we should better not provide direct access to it. > > Best regards, > Martin > > > -----Original Message----- > From: Robbin Ehn > Sent: Dienstag, 15. Januar 2019 10:26 > To: Erik ?sterlund ; Doerr, Martin ; hotspot-runtime-dev at openjdk.java.net; Kim Barrett ; David Holmes (david.holmes at oracle.com) > Subject: Re: RFR(S): 8216426: Usage of array placement new may lead to memory corruption > > On 2019-01-15 10:15, Erik ?sterlund wrote: >> Hi, >> >> Perhaps an alternative approach is to make the Bucket a POD (make the private member public, and remove the >> constructor), and then simply memset the memory to zero. > > Sorry, we have NMT tracking via NEW_C_HEAP_ARRAY(Bucket, _size, F);. > So yes, make it a POD and use memset. > > /Robbin > >> >> Thanks, >> /Erik >> >> On 2019-01-15 09:03, Robbin Ehn wrote: >>> Hi Martin, >>> >>> The Bucket should extend CHeapObj, now that it could. >>> Otherwise looks good, thanks. >>> >>> Originally Bucket did this and I used memset, but gdb was very upset by this. >>> So I changed to array placement new, which meant I had to remove CHeapObj if I remember correctly :) >>> >>> /Robbin >>> >>> On 2019-01-14 17:39, Doerr, Martin wrote: >>>> Hi, >>>> >>>> thanks for looking at this issue and especially for adding comments. >>>> Sounds like this issue should better get fixed although there are no known problems. >>>> >>>> Should we fix it by replacing the array placement new by normal placement new for each element? >>>> http://cr.openjdk.java.net/~mdoerr/8216426_array_placement_new/webrev.00/ >>>> >>>> Best regards, >>>> Martin >>>> >> From magnus.ihse.bursie at oracle.com Tue Jan 15 11:48:27 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 15 Jan 2019 12:48:27 +0100 Subject: RFR(S): 8217044: [aix] Launcher still adds old path to jli library to LIBPATH In-Reply-To: <9d552dc7b4224b98ae2651a17fae6da7@sap.com> References: <256a5fa8b3c4439581fdadee2e739ae5@sap.com> <9d552dc7b4224b98ae2651a17fae6da7@sap.com> Message-ID: <6e8ce6ed-195a-9e9e-4363-4027cf342c6c@oracle.com> Please do. The lib/jli remnants has been lingering on too far in too many places. Just be clear in the bug/commit title that this is not just for AIX. FWIW, your fix looks good to me. /Magnus On 2019-01-15 12:12, Lindenmaier, Goetz wrote: > Ah... a small add on: > > There is one other reference to /jli in the code I could find: > > diff -r 3d6da8a542ab -r 32af46822a7a test/hotspot/gtest/gtestMain.cpp > --- a/test/hotspot/gtest/gtestMain.cpp Mon Jan 14 17:22:23 2019 +0100 > +++ b/test/hotspot/gtest/gtestMain.cpp Tue Jan 15 10:15:39 2019 +0100 > @@ -224,9 +224,9 @@ > > // workaround for JDK-7131356 > #ifdef __APPLE__ > - size_t len = strlen(java_home) + strlen("/lib/jli/libjli.dylib") + 1; > + size_t len = strlen(java_home) + strlen("/lib/libjli.dylib") + 1; > char* path = new char[len]; > - snprintf(path, len, "%s/lib/jli/libjli.dylib", java_home); > + snprintf(path, len, "%s/lib/libjli.dylib", java_home); > dlopen(path, RTLD_NOW | RTLD_GLOBAL); > #endif // __APPLE__ > > Should I add this to this patch, too? > > Best regards, > Goetz. > > >> -----Original Message----- >> From: Lindenmaier, Goetz >> Sent: Dienstag, 15. Januar 2019 12:10 >> To: hotspot-runtime-dev at openjdk.java.net >> Subject: RFR(S): 8217044: [aix] Launcher still adds old path to jli library to >> LIBPATH >> >> Hi, >> >> >> >> As AIX does not know $ORIGIN the path to libjli must be in LIBPATH. libjli >> though has been moved from lib/jli/ to lib/. The path to lib/ is added to >> LIBPATH anyways, so we can remove the special case for AIX. >> >> >> >> Please review this small cleanup. >> >> http://cr.openjdk.java.net/~goetz/wr19/8217044-aixLauncher/01/ >> >> >> >> Best regards, >> >> Goetz. From david.holmes at oracle.com Tue Jan 15 12:02:58 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 15 Jan 2019 22:02:58 +1000 Subject: RFR(S): 8217044: [aix] Launcher still adds old path to jli library to LIBPATH In-Reply-To: <256a5fa8b3c4439581fdadee2e739ae5@sap.com> References: <256a5fa8b3c4439581fdadee2e739ae5@sap.com> Message-ID: <70046c5a-eff1-5829-046d-ea94038f798c@oracle.com> Hi Goetz, The launcher code (and JLI) belongs to core-libs not hotspot-runtime so need to be reviewed there. The gtest cleanup in your follow up email could be handled separately - I'm unclear how gtest is currently working with this apparent bug. Thanks, David On 15/01/2019 9:09 pm, Lindenmaier, Goetz wrote: > Hi, > > As AIX does not know $ORIGIN the path to libjli must be in LIBPATH. libjli though has been moved from lib/jli/ to lib/. The path to lib/ is added to LIBPATH anyways, so we can remove the special case for AIX. > > Please review this small cleanup. > http://cr.openjdk.java.net/~goetz/wr19/8217044-aixLauncher/01/ > > Best regards, > Goetz. > From goetz.lindenmaier at sap.com Tue Jan 15 13:15:20 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 15 Jan 2019 13:15:20 +0000 Subject: RFR(S): 8217044: [aix] Launcher still adds old path to jli library to LIBPATH In-Reply-To: <70046c5a-eff1-5829-046d-ea94038f798c@oracle.com> References: <256a5fa8b3c4439581fdadee2e739ae5@sap.com> <70046c5a-eff1-5829-046d-ea94038f798c@oracle.com> Message-ID: <0cef32c9820244b698a9238322802ae7@sap.com> Hi David, ok, I'll discontinue on this list and post anew to core-libs-dev: http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-January/057945.html Best regards, Goetz. > -----Original Message----- > From: David Holmes > Sent: Dienstag, 15. Januar 2019 13:03 > To: Lindenmaier, Goetz ; hotspot-runtime- > dev at openjdk.java.net > Subject: Re: RFR(S): 8217044: [aix] Launcher still adds old path to jli library to > LIBPATH > > Hi Goetz, > > The launcher code (and JLI) belongs to core-libs not hotspot-runtime so > need to be reviewed there. > > The gtest cleanup in your follow up email could be handled separately - > I'm unclear how gtest is currently working with this apparent bug. > > Thanks, > David > > On 15/01/2019 9:09 pm, Lindenmaier, Goetz wrote: > > Hi, > > > > As AIX does not know $ORIGIN the path to libjli must be in LIBPATH. libjli > though has been moved from lib/jli/ to lib/. The path to lib/ is added to > LIBPATH anyways, so we can remove the special case for AIX. > > > > Please review this small cleanup. > > http://cr.openjdk.java.net/~goetz/wr19/8217044-aixLauncher/01/ > > > > Best regards, > > Goetz. > > From erik.osterlund at oracle.com Tue Jan 15 13:16:26 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Tue, 15 Jan 2019 14:16:26 +0100 Subject: RFR(S): 8216426: Usage of array placement new may lead to memory corruption In-Reply-To: <74c66ced7285482290ab7ad5105955c7@sap.com> References: <61066e81213e40e2840d79025931e597@sap.com> <6fed501b-3f9a-1fc6-78fb-fb64741893c3@oracle.com> <74c66ced7285482290ab7ad5105955c7@sap.com> Message-ID: Hi Martin, Unfortunately, according to the C++03 standard, that field needs to be public for the class to be a POD. And if it is not a POD, we will have undefined behaviour. Yay for C++. Thanks, /Erik On 2019-01-15 11:51, Doerr, Martin wrote: > Hi Robbin, > > that's fine. I like it simple. > > Version which uses memset and removed constructor: > http://cr.openjdk.java.net/~mdoerr/8216426_array_placement_new/webrev.01/ > > I don't like making the field public because it can easily get used incorrectly because there are bits encoded into the pointer. > So I think we should better not provide direct access to it. > > Best regards, > Martin > > > -----Original Message----- > From: Robbin Ehn > Sent: Dienstag, 15. Januar 2019 10:26 > To: Erik ?sterlund ; Doerr, Martin ; hotspot-runtime-dev at openjdk.java.net; Kim Barrett ; David Holmes (david.holmes at oracle.com) > Subject: Re: RFR(S): 8216426: Usage of array placement new may lead to memory corruption > > On 2019-01-15 10:15, Erik ?sterlund wrote: >> Hi, >> >> Perhaps an alternative approach is to make the Bucket a POD (make the private member public, and remove the >> constructor), and then simply memset the memory to zero. > Sorry, we have NMT tracking via NEW_C_HEAP_ARRAY(Bucket, _size, F);. > So yes, make it a POD and use memset. > > /Robbin > >> Thanks, >> /Erik >> >> On 2019-01-15 09:03, Robbin Ehn wrote: >>> Hi Martin, >>> >>> The Bucket should extend CHeapObj, now that it could. >>> Otherwise looks good, thanks. >>> >>> Originally Bucket did this and I used memset, but gdb was very upset by this. >>> So I changed to array placement new, which meant I had to remove CHeapObj if I remember correctly :) >>> >>> /Robbin >>> >>> On 2019-01-14 17:39, Doerr, Martin wrote: >>>> Hi, >>>> >>>> thanks for looking at this issue and especially for adding comments. >>>> Sounds like this issue should better get fixed although there are no known problems. >>>> >>>> Should we fix it by replacing the array placement new by normal placement new for each element? >>>> http://cr.openjdk.java.net/~mdoerr/8216426_array_placement_new/webrev.00/ >>>> >>>> Best regards, >>>> Martin >>>> From rkennke at redhat.com Tue Jan 15 13:36:00 2019 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 15 Jan 2019 14:36:00 +0100 Subject: RFR(S): 8216426: Usage of array placement new may lead to memory corruption In-Reply-To: References: <61066e81213e40e2840d79025931e597@sap.com> <6fed501b-3f9a-1fc6-78fb-fb64741893c3@oracle.com> <74c66ced7285482290ab7ad5105955c7@sap.com> Message-ID: <6905389f-e38a-a901-2334-e07924bba05b@redhat.com> Doesn't using memset mean that newer GCC (8) warns about it and thus break compilation? That was the whole point of introducing placement new operator to begin with, IIRC. Roman > Hi Martin, > > Unfortunately, according to the C++03 standard, that field needs to be > public for the class to be a POD. And if it is not a POD, we will have > undefined behaviour. Yay for C++. > > Thanks, > /Erik > > On 2019-01-15 11:51, Doerr, Martin wrote: >> Hi Robbin, >> >> that's fine. I like it simple. >> ? Version which uses memset and removed constructor: >> http://cr.openjdk.java.net/~mdoerr/8216426_array_placement_new/webrev.01/ >> >> I don't like making the field public because it can easily get used >> incorrectly because there are bits encoded into the pointer. >> So I think we should better not provide direct access to it. >> >> Best regards, >> Martin >> >> >> -----Original Message----- >> From: Robbin Ehn >> Sent: Dienstag, 15. Januar 2019 10:26 >> To: Erik ?sterlund ; Doerr, Martin >> ; hotspot-runtime-dev at openjdk.java.net; Kim >> Barrett ; David Holmes >> (david.holmes at oracle.com) >> Subject: Re: RFR(S): 8216426: Usage of array placement new may lead to >> memory corruption >> >> On 2019-01-15 10:15, Erik ?sterlund wrote: >>> Hi, >>> >>> Perhaps an alternative approach is to make the Bucket a POD (make the >>> private member public, and remove the >>> constructor), and then simply memset the memory to zero. >> Sorry, we have NMT tracking via NEW_C_HEAP_ARRAY(Bucket, _size, F);. >> So yes, make it a POD and use memset. >> >> /Robbin >> >>> Thanks, >>> /Erik >>> >>> On 2019-01-15 09:03, Robbin Ehn wrote: >>>> Hi Martin, >>>> >>>> The Bucket should extend CHeapObj, now that it could. >>>> Otherwise looks good, thanks. >>>> >>>> Originally Bucket did this and I used memset, but gdb was very upset >>>> by this. >>>> So I changed to array placement new, which meant I had to remove >>>> CHeapObj if I remember correctly :) >>>> >>>> /Robbin >>>> >>>> On 2019-01-14 17:39, Doerr, Martin wrote: >>>>> Hi, >>>>> >>>>> thanks for looking at this issue and especially for adding comments. >>>>> Sounds like this issue should better get fixed although there are >>>>> no known problems. >>>>> >>>>> Should we fix it by replacing the array placement new by normal >>>>> placement new for each element? >>>>> http://cr.openjdk.java.net/~mdoerr/8216426_array_placement_new/webrev.00/ >>>>> >>>>> >>>>> Best regards, >>>>> Martin >>>>> > From martin.doerr at sap.com Tue Jan 15 14:01:14 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 15 Jan 2019 14:01:14 +0000 Subject: RFR(S): 8216426: Usage of array placement new may lead to memory corruption In-Reply-To: <6905389f-e38a-a901-2334-e07924bba05b@redhat.com> References: <61066e81213e40e2840d79025931e597@sap.com> <6fed501b-3f9a-1fc6-78fb-fb64741893c3@oracle.com> <74c66ced7285482290ab7ad5105955c7@sap.com> <6905389f-e38a-a901-2334-e07924bba05b@redhat.com> Message-ID: <269254b5ee9e489a99e8b4af25a4b875@sap.com> Hi Roman and Erik, I don't have GCC 8 so I can't test it. But hotspot heavily uses memset (also with NEW_C_HEAP_ARRAY), so why should it be a problem here? I don't understand why Bucket is not a POD. Its binary form should look like a C structure. And even if it's not POD, why should it yield undefined behavior? We're not using default initialization. I believe C++ does not require NULL to be 0 before C++11. So memset to 0 may yield undefined behavior, but we rely on this at so many places ... Best regards, Martin -----Original Message----- From: Roman Kennke Sent: Dienstag, 15. Januar 2019 14:36 To: Erik ?sterlund ; Doerr, Martin ; Robbin Ehn ; hotspot-runtime-dev at openjdk.java.net; Kim Barrett ; David Holmes (david.holmes at oracle.com) Subject: Re: RFR(S): 8216426: Usage of array placement new may lead to memory corruption Doesn't using memset mean that newer GCC (8) warns about it and thus break compilation? That was the whole point of introducing placement new operator to begin with, IIRC. Roman > Hi Martin, > > Unfortunately, according to the C++03 standard, that field needs to be > public for the class to be a POD. And if it is not a POD, we will have > undefined behaviour. Yay for C++. > > Thanks, > /Erik > > On 2019-01-15 11:51, Doerr, Martin wrote: >> Hi Robbin, >> >> that's fine. I like it simple. >> ? Version which uses memset and removed constructor: >> http://cr.openjdk.java.net/~mdoerr/8216426_array_placement_new/webrev.01/ >> >> I don't like making the field public because it can easily get used >> incorrectly because there are bits encoded into the pointer. >> So I think we should better not provide direct access to it. >> >> Best regards, >> Martin >> >> >> -----Original Message----- >> From: Robbin Ehn >> Sent: Dienstag, 15. Januar 2019 10:26 >> To: Erik ?sterlund ; Doerr, Martin >> ; hotspot-runtime-dev at openjdk.java.net; Kim >> Barrett ; David Holmes >> (david.holmes at oracle.com) >> Subject: Re: RFR(S): 8216426: Usage of array placement new may lead to >> memory corruption >> >> On 2019-01-15 10:15, Erik ?sterlund wrote: >>> Hi, >>> >>> Perhaps an alternative approach is to make the Bucket a POD (make the >>> private member public, and remove the >>> constructor), and then simply memset the memory to zero. >> Sorry, we have NMT tracking via NEW_C_HEAP_ARRAY(Bucket, _size, F);. >> So yes, make it a POD and use memset. >> >> /Robbin >> >>> Thanks, >>> /Erik >>> >>> On 2019-01-15 09:03, Robbin Ehn wrote: >>>> Hi Martin, >>>> >>>> The Bucket should extend CHeapObj, now that it could. >>>> Otherwise looks good, thanks. >>>> >>>> Originally Bucket did this and I used memset, but gdb was very upset >>>> by this. >>>> So I changed to array placement new, which meant I had to remove >>>> CHeapObj if I remember correctly :) >>>> >>>> /Robbin >>>> >>>> On 2019-01-14 17:39, Doerr, Martin wrote: >>>>> Hi, >>>>> >>>>> thanks for looking at this issue and especially for adding comments. >>>>> Sounds like this issue should better get fixed although there are >>>>> no known problems. >>>>> >>>>> Should we fix it by replacing the array placement new by normal >>>>> placement new for each element? >>>>> http://cr.openjdk.java.net/~mdoerr/8216426_array_placement_new/webrev.00/ >>>>> >>>>> >>>>> Best regards, >>>>> Martin >>>>> > From magnus.ihse.bursie at oracle.com Tue Jan 15 14:05:23 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 15 Jan 2019 15:05:23 +0100 Subject: RFR(M): 8215902: Add support for SoftFloat-3e library In-Reply-To: <4497ca084b9f48dbb8f6de1aa35c83653fd7acfb.camel@gmail.com> References: <4497ca084b9f48dbb8f6de1aa35c83653fd7acfb.camel@gmail.com> Message-ID: <7f69fc73-1c10-6b68-d657-c9e758d4bf1d@oracle.com> On 2018-12-25 16:19, Jakub Van?k wrote: > Hi, > > please review this webrev. It is a successor of the softfloat-3 [patch] > thread (first email > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-November/031311.html > ) > > Changes since the last patch (v6): > > - renamed --with-softloat* to --with-sflt* (it is more compact and it > corresponds to the old --with-sflt-lib=... option) > > - license is now obtained via --with-sflt-license switch (so it is not > included in OpenJDK source tree) > > - updated documentation (slight rewording, added the license option) > > - checks for default --with/--without behavior are in place again > (I forgot them when I changed the way the library is detected) > > - added a simple testcase - I found a disrepancy between softfloat and > system function behavior. When a float with bits 0x003FFFFF is > added to 0x00000001, the correct result is 0x00400000, but the > default software floating point implementation returns 0x00000000. > However I'm not sure where to put this test - now it is in > test/hotspot/jtreg/compiler/floatingpoint. > > - comments in code refer to CR 6757269 and newly JDK-8215902 too. > > I have created a repository with SoftFloat-3e with build configuration > specifically for OpenJDK on armel: > https://github.com/ev3dev-lang-java/softfloat-openjdk > > I can add a link to it to the documentation. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215902 > Webrev: http://cr.openjdk.java.net/~jakvanek/8215902/webrev.02/ Hi Jakub, In general this looks good. Some comments: I agree with Erik that you can add a link to your github project; compiling SoftFloat is outside the scope of the OpenJDK build instructions, but it can sure be helpful to lower the bar for users wanting to do that. Just one question: any particular reason you didn't create your github repo by forking the official https://github.com/ucb-bar/berkeley-softfloat-3? That way, it would have been easy for users to see that you were not adding any malicious or suspicious code to the original SoftFloat distribution. On the other hand, I think the link to http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2016-November/000611.html is unnecessary and just creates clutter in the documentation. Please remove it. /Magnus > CI build: https://ci.adoptopenjdk.net/view/ev3dev/job/openjdk12_build_ev3_linux/67/ > > Cheers, > > Jakub > From erik.osterlund at oracle.com Tue Jan 15 14:16:33 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Tue, 15 Jan 2019 15:16:33 +0100 Subject: RFR(S): 8216426: Usage of array placement new may lead to memory corruption In-Reply-To: <6905389f-e38a-a901-2334-e07924bba05b@redhat.com> References: <61066e81213e40e2840d79025931e597@sap.com> <6fed501b-3f9a-1fc6-78fb-fb64741893c3@oracle.com> <74c66ced7285482290ab7ad5105955c7@sap.com> <6905389f-e38a-a901-2334-e07924bba05b@redhat.com> Message-ID: Hi Roman, Using memset on non-PODs is indeed undefined behaviour. But for PODs, it is not. So I presume GCC warns about incorrect usages involving non-PODs. /Erik On 2019-01-15 14:36, Roman Kennke wrote: > Doesn't using memset mean that newer GCC (8) warns about it and thus > break compilation? That was the whole point of introducing placement new > operator to begin with, IIRC. > > Roman > >> Hi Martin, >> >> Unfortunately, according to the C++03 standard, that field needs to be >> public for the class to be a POD. And if it is not a POD, we will have >> undefined behaviour. Yay for C++. >> >> Thanks, >> /Erik >> >> On 2019-01-15 11:51, Doerr, Martin wrote: >>> Hi Robbin, >>> >>> that's fine. I like it simple. >>> ? Version which uses memset and removed constructor: >>> http://cr.openjdk.java.net/~mdoerr/8216426_array_placement_new/webrev.01/ >>> >>> I don't like making the field public because it can easily get used >>> incorrectly because there are bits encoded into the pointer. >>> So I think we should better not provide direct access to it. >>> >>> Best regards, >>> Martin >>> >>> >>> -----Original Message----- >>> From: Robbin Ehn >>> Sent: Dienstag, 15. Januar 2019 10:26 >>> To: Erik ?sterlund ; Doerr, Martin >>> ; hotspot-runtime-dev at openjdk.java.net; Kim >>> Barrett ; David Holmes >>> (david.holmes at oracle.com) >>> Subject: Re: RFR(S): 8216426: Usage of array placement new may lead to >>> memory corruption >>> >>> On 2019-01-15 10:15, Erik ?sterlund wrote: >>>> Hi, >>>> >>>> Perhaps an alternative approach is to make the Bucket a POD (make the >>>> private member public, and remove the >>>> constructor), and then simply memset the memory to zero. >>> Sorry, we have NMT tracking via NEW_C_HEAP_ARRAY(Bucket, _size, F);. >>> So yes, make it a POD and use memset. >>> >>> /Robbin >>> >>>> Thanks, >>>> /Erik >>>> >>>> On 2019-01-15 09:03, Robbin Ehn wrote: >>>>> Hi Martin, >>>>> >>>>> The Bucket should extend CHeapObj, now that it could. >>>>> Otherwise looks good, thanks. >>>>> >>>>> Originally Bucket did this and I used memset, but gdb was very upset >>>>> by this. >>>>> So I changed to array placement new, which meant I had to remove >>>>> CHeapObj if I remember correctly :) >>>>> >>>>> /Robbin >>>>> >>>>> On 2019-01-14 17:39, Doerr, Martin wrote: >>>>>> Hi, >>>>>> >>>>>> thanks for looking at this issue and especially for adding comments. >>>>>> Sounds like this issue should better get fixed although there are >>>>>> no known problems. >>>>>> >>>>>> Should we fix it by replacing the array placement new by normal >>>>>> placement new for each element? >>>>>> http://cr.openjdk.java.net/~mdoerr/8216426_array_placement_new/webrev.00/ >>>>>> >>>>>> >>>>>> Best regards, >>>>>> Martin >>>>>> From erik.osterlund at oracle.com Tue Jan 15 14:36:59 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Tue, 15 Jan 2019 15:36:59 +0100 Subject: RFR(S): 8216426: Usage of array placement new may lead to memory corruption In-Reply-To: <269254b5ee9e489a99e8b4af25a4b875@sap.com> References: <61066e81213e40e2840d79025931e597@sap.com> <6fed501b-3f9a-1fc6-78fb-fb64741893c3@oracle.com> <74c66ced7285482290ab7ad5105955c7@sap.com> <6905389f-e38a-a901-2334-e07924bba05b@redhat.com> <269254b5ee9e489a99e8b4af25a4b875@sap.com> Message-ID: Hi Martin, On 2019-01-15 15:01, Doerr, Martin wrote: > Hi Roman and Erik, > > I don't have GCC 8 so I can't test it. But hotspot heavily uses memset (also with NEW_C_HEAP_ARRAY), so why should it be a problem here? > > I don't understand why Bucket is not a POD. Its binary form should look like a C structure. > And even if it's not POD, why should it yield undefined behavior? We're not using default initialization. It's not a POD because the standard says it is not. It is explicit about how you can't have private or protected member variables. Its binary form should indeed look like a C structure, but it's not a POD. That implies for example that it will be sent through the stack, not by register in the calling convention, unlike a POD which is sent by register. So despite the rules for what is and what is not a POD seemingly making no sense, they can't just change it to make sense without breaking the ABI. So I guess we are kind of stuck with it. C++11 and later has improved the situation in this area, but we don't have it. Unfortunately, the life cycle for non-PODs is coupled with calling constructors and destructors (unless trivially destructible, then you don't have to), while the life cycle of PODs is not; it's more like a C struct. That means that by making that member private, it is not a POD according to the definition, and suddenly you are not allowed to just memset it and gotta explicitly construct the object to be compliant with the standard. > I believe C++ does not require NULL to be 0 before C++11. It has to be a constant rvalue expression that evaluates to zero in C++03. > So memset to 0 may yield undefined behavior, but we rely on this at so many places ... Well, we are swimming in a vast ocean of undefined behaviour. It's hard not to, when the standard has made it as hard and unintuitive as possible to be compliant, and no sensible tools enforcing it. Thanks, /Erik > Best regards, > Martin > > > -----Original Message----- > From: Roman Kennke > Sent: Dienstag, 15. Januar 2019 14:36 > To: Erik ?sterlund ; Doerr, Martin ; Robbin Ehn ; hotspot-runtime-dev at openjdk.java.net; Kim Barrett ; David Holmes (david.holmes at oracle.com) > Subject: Re: RFR(S): 8216426: Usage of array placement new may lead to memory corruption > > Doesn't using memset mean that newer GCC (8) warns about it and thus > break compilation? That was the whole point of introducing placement new > operator to begin with, IIRC. > > Roman > >> Hi Martin, >> >> Unfortunately, according to the C++03 standard, that field needs to be >> public for the class to be a POD. And if it is not a POD, we will have >> undefined behaviour. Yay for C++. >> >> Thanks, >> /Erik >> >> On 2019-01-15 11:51, Doerr, Martin wrote: >>> Hi Robbin, >>> >>> that's fine. I like it simple. >>> ? Version which uses memset and removed constructor: >>> http://cr.openjdk.java.net/~mdoerr/8216426_array_placement_new/webrev.01/ >>> >>> I don't like making the field public because it can easily get used >>> incorrectly because there are bits encoded into the pointer. >>> So I think we should better not provide direct access to it. >>> >>> Best regards, >>> Martin >>> >>> >>> -----Original Message----- >>> From: Robbin Ehn >>> Sent: Dienstag, 15. Januar 2019 10:26 >>> To: Erik ?sterlund ; Doerr, Martin >>> ; hotspot-runtime-dev at openjdk.java.net; Kim >>> Barrett ; David Holmes >>> (david.holmes at oracle.com) >>> Subject: Re: RFR(S): 8216426: Usage of array placement new may lead to >>> memory corruption >>> >>> On 2019-01-15 10:15, Erik ?sterlund wrote: >>>> Hi, >>>> >>>> Perhaps an alternative approach is to make the Bucket a POD (make the >>>> private member public, and remove the >>>> constructor), and then simply memset the memory to zero. >>> Sorry, we have NMT tracking via NEW_C_HEAP_ARRAY(Bucket, _size, F);. >>> So yes, make it a POD and use memset. >>> >>> /Robbin >>> >>>> Thanks, >>>> /Erik >>>> >>>> On 2019-01-15 09:03, Robbin Ehn wrote: >>>>> Hi Martin, >>>>> >>>>> The Bucket should extend CHeapObj, now that it could. >>>>> Otherwise looks good, thanks. >>>>> >>>>> Originally Bucket did this and I used memset, but gdb was very upset >>>>> by this. >>>>> So I changed to array placement new, which meant I had to remove >>>>> CHeapObj if I remember correctly :) >>>>> >>>>> /Robbin >>>>> >>>>> On 2019-01-14 17:39, Doerr, Martin wrote: >>>>>> Hi, >>>>>> >>>>>> thanks for looking at this issue and especially for adding comments. >>>>>> Sounds like this issue should better get fixed although there are >>>>>> no known problems. >>>>>> >>>>>> Should we fix it by replacing the array placement new by normal >>>>>> placement new for each element? >>>>>> http://cr.openjdk.java.net/~mdoerr/8216426_array_placement_new/webrev.00/ >>>>>> >>>>>> >>>>>> Best regards, >>>>>> Martin >>>>>> From rkennke at redhat.com Tue Jan 15 14:43:44 2019 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 15 Jan 2019 15:43:44 +0100 Subject: RFR(S): 8216426: Usage of array placement new may lead to memory corruption In-Reply-To: <269254b5ee9e489a99e8b4af25a4b875@sap.com> References: <61066e81213e40e2840d79025931e597@sap.com> <6fed501b-3f9a-1fc6-78fb-fb64741893c3@oracle.com> <74c66ced7285482290ab7ad5105955c7@sap.com> <6905389f-e38a-a901-2334-e07924bba05b@redhat.com> <269254b5ee9e489a99e8b4af25a4b875@sap.com> Message-ID: Hi Martin, The thing is, it is a problem all over the place, and Hotspot can't currently be compiled with GCC 8, except when disabling warnings. People are working to fix those issues, so for example: https://bugs.openjdk.java.net/browse/JDK-8214376 https://bugs.openjdk.java.net/browse/JDK-8213745 https://bugs.openjdk.java.net/browse/JDK-8214272 etc. Plus, besides, it's better style to not use memset. If there's a good C++ construct to achieve the same, why not use it? E.g. placement new? Roman > Hi Roman and Erik, > > I don't have GCC 8 so I can't test it. But hotspot heavily uses memset (also with NEW_C_HEAP_ARRAY), so why should it be a problem here? > > I don't understand why Bucket is not a POD. Its binary form should look like a C structure. > And even if it's not POD, why should it yield undefined behavior? We're not using default initialization. > > I believe C++ does not require NULL to be 0 before C++11. So memset to 0 may yield undefined behavior, but we rely on this at so many places ... > > Best regards, > Martin > > > -----Original Message----- > From: Roman Kennke > Sent: Dienstag, 15. Januar 2019 14:36 > To: Erik ?sterlund ; Doerr, Martin ; Robbin Ehn ; hotspot-runtime-dev at openjdk.java.net; Kim Barrett ; David Holmes (david.holmes at oracle.com) > Subject: Re: RFR(S): 8216426: Usage of array placement new may lead to memory corruption > > Doesn't using memset mean that newer GCC (8) warns about it and thus > break compilation? That was the whole point of introducing placement new > operator to begin with, IIRC. > > Roman > >> Hi Martin, >> >> Unfortunately, according to the C++03 standard, that field needs to be >> public for the class to be a POD. And if it is not a POD, we will have >> undefined behaviour. Yay for C++. >> >> Thanks, >> /Erik >> >> On 2019-01-15 11:51, Doerr, Martin wrote: >>> Hi Robbin, >>> >>> that's fine. I like it simple. >>> ? Version which uses memset and removed constructor: >>> http://cr.openjdk.java.net/~mdoerr/8216426_array_placement_new/webrev.01/ >>> >>> I don't like making the field public because it can easily get used >>> incorrectly because there are bits encoded into the pointer. >>> So I think we should better not provide direct access to it. >>> >>> Best regards, >>> Martin >>> >>> >>> -----Original Message----- >>> From: Robbin Ehn >>> Sent: Dienstag, 15. Januar 2019 10:26 >>> To: Erik ?sterlund ; Doerr, Martin >>> ; hotspot-runtime-dev at openjdk.java.net; Kim >>> Barrett ; David Holmes >>> (david.holmes at oracle.com) >>> Subject: Re: RFR(S): 8216426: Usage of array placement new may lead to >>> memory corruption >>> >>> On 2019-01-15 10:15, Erik ?sterlund wrote: >>>> Hi, >>>> >>>> Perhaps an alternative approach is to make the Bucket a POD (make the >>>> private member public, and remove the >>>> constructor), and then simply memset the memory to zero. >>> Sorry, we have NMT tracking via NEW_C_HEAP_ARRAY(Bucket, _size, F);. >>> So yes, make it a POD and use memset. >>> >>> /Robbin >>> >>>> Thanks, >>>> /Erik >>>> >>>> On 2019-01-15 09:03, Robbin Ehn wrote: >>>>> Hi Martin, >>>>> >>>>> The Bucket should extend CHeapObj, now that it could. >>>>> Otherwise looks good, thanks. >>>>> >>>>> Originally Bucket did this and I used memset, but gdb was very upset >>>>> by this. >>>>> So I changed to array placement new, which meant I had to remove >>>>> CHeapObj if I remember correctly :) >>>>> >>>>> /Robbin >>>>> >>>>> On 2019-01-14 17:39, Doerr, Martin wrote: >>>>>> Hi, >>>>>> >>>>>> thanks for looking at this issue and especially for adding comments. >>>>>> Sounds like this issue should better get fixed although there are >>>>>> no known problems. >>>>>> >>>>>> Should we fix it by replacing the array placement new by normal >>>>>> placement new for each element? >>>>>> http://cr.openjdk.java.net/~mdoerr/8216426_array_placement_new/webrev.00/ >>>>>> >>>>>> >>>>>> Best regards, >>>>>> Martin >>>>>> >> > From martin.doerr at sap.com Tue Jan 15 15:42:50 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 15 Jan 2019 15:42:50 +0000 Subject: RFR(S): 8216426: Usage of array placement new may lead to memory corruption In-Reply-To: References: <61066e81213e40e2840d79025931e597@sap.com> <6fed501b-3f9a-1fc6-78fb-fb64741893c3@oracle.com> <74c66ced7285482290ab7ad5105955c7@sap.com> <6905389f-e38a-a901-2334-e07924bba05b@redhat.com> <269254b5ee9e489a99e8b4af25a4b875@sap.com> Message-ID: <5e5515c413b843eb80841476469935b7@sap.com> Hi Erik, I have looked at a newer version of the standard. Seems like they have fixed it. I couldn't find all that stuff in the standard, but thanks for your explanations. We could do it this way after JEP 347 (C++14)? Best regards, Martin -----Original Message----- From: Erik ?sterlund Sent: Dienstag, 15. Januar 2019 15:37 To: Doerr, Martin ; Roman Kennke ; Robbin Ehn ; hotspot-runtime-dev at openjdk.java.net; Kim Barrett ; David Holmes (david.holmes at oracle.com) Subject: Re: RFR(S): 8216426: Usage of array placement new may lead to memory corruption Hi Martin, On 2019-01-15 15:01, Doerr, Martin wrote: > Hi Roman and Erik, > > I don't have GCC 8 so I can't test it. But hotspot heavily uses memset (also with NEW_C_HEAP_ARRAY), so why should it be a problem here? > > I don't understand why Bucket is not a POD. Its binary form should look like a C structure. > And even if it's not POD, why should it yield undefined behavior? We're not using default initialization. It's not a POD because the standard says it is not. It is explicit about how you can't have private or protected member variables. Its binary form should indeed look like a C structure, but it's not a POD. That implies for example that it will be sent through the stack, not by register in the calling convention, unlike a POD which is sent by register. So despite the rules for what is and what is not a POD seemingly making no sense, they can't just change it to make sense without breaking the ABI. So I guess we are kind of stuck with it. C++11 and later has improved the situation in this area, but we don't have it. Unfortunately, the life cycle for non-PODs is coupled with calling constructors and destructors (unless trivially destructible, then you don't have to), while the life cycle of PODs is not; it's more like a C struct. That means that by making that member private, it is not a POD according to the definition, and suddenly you are not allowed to just memset it and gotta explicitly construct the object to be compliant with the standard. > I believe C++ does not require NULL to be 0 before C++11. It has to be a constant rvalue expression that evaluates to zero in C++03. > So memset to 0 may yield undefined behavior, but we rely on this at so many places ... Well, we are swimming in a vast ocean of undefined behaviour. It's hard not to, when the standard has made it as hard and unintuitive as possible to be compliant, and no sensible tools enforcing it. Thanks, /Erik > Best regards, > Martin > > > -----Original Message----- > From: Roman Kennke > Sent: Dienstag, 15. Januar 2019 14:36 > To: Erik ?sterlund ; Doerr, Martin ; Robbin Ehn ; hotspot-runtime-dev at openjdk.java.net; Kim Barrett ; David Holmes (david.holmes at oracle.com) > Subject: Re: RFR(S): 8216426: Usage of array placement new may lead to memory corruption > > Doesn't using memset mean that newer GCC (8) warns about it and thus > break compilation? That was the whole point of introducing placement new > operator to begin with, IIRC. > > Roman > >> Hi Martin, >> >> Unfortunately, according to the C++03 standard, that field needs to be >> public for the class to be a POD. And if it is not a POD, we will have >> undefined behaviour. Yay for C++. >> >> Thanks, >> /Erik >> >> On 2019-01-15 11:51, Doerr, Martin wrote: >>> Hi Robbin, >>> >>> that's fine. I like it simple. >>> ? Version which uses memset and removed constructor: >>> http://cr.openjdk.java.net/~mdoerr/8216426_array_placement_new/webrev.01/ >>> >>> I don't like making the field public because it can easily get used >>> incorrectly because there are bits encoded into the pointer. >>> So I think we should better not provide direct access to it. >>> >>> Best regards, >>> Martin >>> >>> >>> -----Original Message----- >>> From: Robbin Ehn >>> Sent: Dienstag, 15. Januar 2019 10:26 >>> To: Erik ?sterlund ; Doerr, Martin >>> ; hotspot-runtime-dev at openjdk.java.net; Kim >>> Barrett ; David Holmes >>> (david.holmes at oracle.com) >>> Subject: Re: RFR(S): 8216426: Usage of array placement new may lead to >>> memory corruption >>> >>> On 2019-01-15 10:15, Erik ?sterlund wrote: >>>> Hi, >>>> >>>> Perhaps an alternative approach is to make the Bucket a POD (make the >>>> private member public, and remove the >>>> constructor), and then simply memset the memory to zero. >>> Sorry, we have NMT tracking via NEW_C_HEAP_ARRAY(Bucket, _size, F);. >>> So yes, make it a POD and use memset. >>> >>> /Robbin >>> >>>> Thanks, >>>> /Erik >>>> >>>> On 2019-01-15 09:03, Robbin Ehn wrote: >>>>> Hi Martin, >>>>> >>>>> The Bucket should extend CHeapObj, now that it could. >>>>> Otherwise looks good, thanks. >>>>> >>>>> Originally Bucket did this and I used memset, but gdb was very upset >>>>> by this. >>>>> So I changed to array placement new, which meant I had to remove >>>>> CHeapObj if I remember correctly :) >>>>> >>>>> /Robbin >>>>> >>>>> On 2019-01-14 17:39, Doerr, Martin wrote: >>>>>> Hi, >>>>>> >>>>>> thanks for looking at this issue and especially for adding comments. >>>>>> Sounds like this issue should better get fixed although there are >>>>>> no known problems. >>>>>> >>>>>> Should we fix it by replacing the array placement new by normal >>>>>> placement new for each element? >>>>>> http://cr.openjdk.java.net/~mdoerr/8216426_array_placement_new/webrev.00/ >>>>>> >>>>>> >>>>>> Best regards, >>>>>> Martin >>>>>> From martin.doerr at sap.com Tue Jan 15 15:48:16 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 15 Jan 2019 15:48:16 +0000 Subject: RFR(S): 8216426: Usage of array placement new may lead to memory corruption In-Reply-To: References: <61066e81213e40e2840d79025931e597@sap.com> <6fed501b-3f9a-1fc6-78fb-fb64741893c3@oracle.com> <74c66ced7285482290ab7ad5105955c7@sap.com> <6905389f-e38a-a901-2334-e07924bba05b@redhat.com> <269254b5ee9e489a99e8b4af25a4b875@sap.com> Message-ID: <39fd48d5fd1c444b915c3fb84885882a@sap.com> Hi Roman, I had originally proposed to use placement new for each object: (Kim's small request included, now) http://cr.openjdk.java.net/~mdoerr/8216426_array_placement_new/webrev.00/ So seems like we should rather use the webrev.00. Best regards, Martin -----Original Message----- From: Roman Kennke Sent: Dienstag, 15. Januar 2019 15:44 To: Doerr, Martin ; Erik ?sterlund ; Robbin Ehn ; hotspot-runtime-dev at openjdk.java.net; Kim Barrett ; David Holmes (david.holmes at oracle.com) Subject: Re: RFR(S): 8216426: Usage of array placement new may lead to memory corruption Hi Martin, The thing is, it is a problem all over the place, and Hotspot can't currently be compiled with GCC 8, except when disabling warnings. People are working to fix those issues, so for example: https://bugs.openjdk.java.net/browse/JDK-8214376 https://bugs.openjdk.java.net/browse/JDK-8213745 https://bugs.openjdk.java.net/browse/JDK-8214272 etc. Plus, besides, it's better style to not use memset. If there's a good C++ construct to achieve the same, why not use it? E.g. placement new? Roman > Hi Roman and Erik, > > I don't have GCC 8 so I can't test it. But hotspot heavily uses memset (also with NEW_C_HEAP_ARRAY), so why should it be a problem here? > > I don't understand why Bucket is not a POD. Its binary form should look like a C structure. > And even if it's not POD, why should it yield undefined behavior? We're not using default initialization. > > I believe C++ does not require NULL to be 0 before C++11. So memset to 0 may yield undefined behavior, but we rely on this at so many places ... > > Best regards, > Martin > > > -----Original Message----- > From: Roman Kennke > Sent: Dienstag, 15. Januar 2019 14:36 > To: Erik ?sterlund ; Doerr, Martin ; Robbin Ehn ; hotspot-runtime-dev at openjdk.java.net; Kim Barrett ; David Holmes (david.holmes at oracle.com) > Subject: Re: RFR(S): 8216426: Usage of array placement new may lead to memory corruption > > Doesn't using memset mean that newer GCC (8) warns about it and thus > break compilation? That was the whole point of introducing placement new > operator to begin with, IIRC. > > Roman > >> Hi Martin, >> >> Unfortunately, according to the C++03 standard, that field needs to be >> public for the class to be a POD. And if it is not a POD, we will have >> undefined behaviour. Yay for C++. >> >> Thanks, >> /Erik >> >> On 2019-01-15 11:51, Doerr, Martin wrote: >>> Hi Robbin, >>> >>> that's fine. I like it simple. >>> ? Version which uses memset and removed constructor: >>> http://cr.openjdk.java.net/~mdoerr/8216426_array_placement_new/webrev.01/ >>> >>> I don't like making the field public because it can easily get used >>> incorrectly because there are bits encoded into the pointer. >>> So I think we should better not provide direct access to it. >>> >>> Best regards, >>> Martin >>> >>> >>> -----Original Message----- >>> From: Robbin Ehn >>> Sent: Dienstag, 15. Januar 2019 10:26 >>> To: Erik ?sterlund ; Doerr, Martin >>> ; hotspot-runtime-dev at openjdk.java.net; Kim >>> Barrett ; David Holmes >>> (david.holmes at oracle.com) >>> Subject: Re: RFR(S): 8216426: Usage of array placement new may lead to >>> memory corruption >>> >>> On 2019-01-15 10:15, Erik ?sterlund wrote: >>>> Hi, >>>> >>>> Perhaps an alternative approach is to make the Bucket a POD (make the >>>> private member public, and remove the >>>> constructor), and then simply memset the memory to zero. >>> Sorry, we have NMT tracking via NEW_C_HEAP_ARRAY(Bucket, _size, F);. >>> So yes, make it a POD and use memset. >>> >>> /Robbin >>> >>>> Thanks, >>>> /Erik >>>> >>>> On 2019-01-15 09:03, Robbin Ehn wrote: >>>>> Hi Martin, >>>>> >>>>> The Bucket should extend CHeapObj, now that it could. >>>>> Otherwise looks good, thanks. >>>>> >>>>> Originally Bucket did this and I used memset, but gdb was very upset >>>>> by this. >>>>> So I changed to array placement new, which meant I had to remove >>>>> CHeapObj if I remember correctly :) >>>>> >>>>> /Robbin >>>>> >>>>> On 2019-01-14 17:39, Doerr, Martin wrote: >>>>>> Hi, >>>>>> >>>>>> thanks for looking at this issue and especially for adding comments. >>>>>> Sounds like this issue should better get fixed although there are >>>>>> no known problems. >>>>>> >>>>>> Should we fix it by replacing the array placement new by normal >>>>>> placement new for each element? >>>>>> http://cr.openjdk.java.net/~mdoerr/8216426_array_placement_new/webrev.00/ >>>>>> >>>>>> >>>>>> Best regards, >>>>>> Martin >>>>>> >> > From robbin.ehn at oracle.com Tue Jan 15 16:02:51 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 15 Jan 2019 17:02:51 +0100 Subject: RFR(S): 8216426: Usage of array placement new may lead to memory corruption In-Reply-To: <39fd48d5fd1c444b915c3fb84885882a@sap.com> References: <61066e81213e40e2840d79025931e597@sap.com> <6fed501b-3f9a-1fc6-78fb-fb64741893c3@oracle.com> <74c66ced7285482290ab7ad5105955c7@sap.com> <6905389f-e38a-a901-2334-e07924bba05b@redhat.com> <269254b5ee9e489a99e8b4af25a4b875@sap.com> <39fd48d5fd1c444b915c3fb84885882a@sap.com> Message-ID: On 2019-01-15 16:48, Doerr, Martin wrote: > Hi Roman, > > I had originally proposed to use placement new for each object: > (Kim's small request included, now) > http://cr.openjdk.java.net/~mdoerr/8216426_array_placement_new/webrev.00/ > > So seems like we should rather use the webrev.00. Ship it! /Robbin > > Best regards, > Martin > > > -----Original Message----- > From: Roman Kennke > Sent: Dienstag, 15. Januar 2019 15:44 > To: Doerr, Martin ; Erik ?sterlund ; Robbin Ehn ; hotspot-runtime-dev at openjdk.java.net; Kim Barrett ; David Holmes (david.holmes at oracle.com) > Subject: Re: RFR(S): 8216426: Usage of array placement new may lead to memory corruption > > Hi Martin, > > The thing is, it is a problem all over the place, and Hotspot can't > currently be compiled with GCC 8, except when disabling warnings. People > are working to fix those issues, so for example: > > https://bugs.openjdk.java.net/browse/JDK-8214376 > https://bugs.openjdk.java.net/browse/JDK-8213745 > https://bugs.openjdk.java.net/browse/JDK-8214272 > > etc. > > Plus, besides, it's better style to not use memset. > > If there's a good C++ construct to achieve the same, why not use it? > E.g. placement new? > > Roman > >> Hi Roman and Erik, >> >> I don't have GCC 8 so I can't test it. But hotspot heavily uses memset (also with NEW_C_HEAP_ARRAY), so why should it be a problem here? >> >> I don't understand why Bucket is not a POD. Its binary form should look like a C structure. >> And even if it's not POD, why should it yield undefined behavior? We're not using default initialization. >> >> I believe C++ does not require NULL to be 0 before C++11. So memset to 0 may yield undefined behavior, but we rely on this at so many places ... >> >> Best regards, >> Martin >> >> >> -----Original Message----- >> From: Roman Kennke >> Sent: Dienstag, 15. Januar 2019 14:36 >> To: Erik ?sterlund ; Doerr, Martin ; Robbin Ehn ; hotspot-runtime-dev at openjdk.java.net; Kim Barrett ; David Holmes (david.holmes at oracle.com) >> Subject: Re: RFR(S): 8216426: Usage of array placement new may lead to memory corruption >> >> Doesn't using memset mean that newer GCC (8) warns about it and thus >> break compilation? That was the whole point of introducing placement new >> operator to begin with, IIRC. >> >> Roman >> >>> Hi Martin, >>> >>> Unfortunately, according to the C++03 standard, that field needs to be >>> public for the class to be a POD. And if it is not a POD, we will have >>> undefined behaviour. Yay for C++. >>> >>> Thanks, >>> /Erik >>> >>> On 2019-01-15 11:51, Doerr, Martin wrote: >>>> Hi Robbin, >>>> >>>> that's fine. I like it simple. >>>> ? Version which uses memset and removed constructor: >>>> http://cr.openjdk.java.net/~mdoerr/8216426_array_placement_new/webrev.01/ >>>> >>>> I don't like making the field public because it can easily get used >>>> incorrectly because there are bits encoded into the pointer. >>>> So I think we should better not provide direct access to it. >>>> >>>> Best regards, >>>> Martin >>>> >>>> >>>> -----Original Message----- >>>> From: Robbin Ehn >>>> Sent: Dienstag, 15. Januar 2019 10:26 >>>> To: Erik ?sterlund ; Doerr, Martin >>>> ; hotspot-runtime-dev at openjdk.java.net; Kim >>>> Barrett ; David Holmes >>>> (david.holmes at oracle.com) >>>> Subject: Re: RFR(S): 8216426: Usage of array placement new may lead to >>>> memory corruption >>>> >>>> On 2019-01-15 10:15, Erik ?sterlund wrote: >>>>> Hi, >>>>> >>>>> Perhaps an alternative approach is to make the Bucket a POD (make the >>>>> private member public, and remove the >>>>> constructor), and then simply memset the memory to zero. >>>> Sorry, we have NMT tracking via NEW_C_HEAP_ARRAY(Bucket, _size, F);. >>>> So yes, make it a POD and use memset. >>>> >>>> /Robbin >>>> >>>>> Thanks, >>>>> /Erik >>>>> >>>>> On 2019-01-15 09:03, Robbin Ehn wrote: >>>>>> Hi Martin, >>>>>> >>>>>> The Bucket should extend CHeapObj, now that it could. >>>>>> Otherwise looks good, thanks. >>>>>> >>>>>> Originally Bucket did this and I used memset, but gdb was very upset >>>>>> by this. >>>>>> So I changed to array placement new, which meant I had to remove >>>>>> CHeapObj if I remember correctly :) >>>>>> >>>>>> /Robbin >>>>>> >>>>>> On 2019-01-14 17:39, Doerr, Martin wrote: >>>>>>> Hi, >>>>>>> >>>>>>> thanks for looking at this issue and especially for adding comments. >>>>>>> Sounds like this issue should better get fixed although there are >>>>>>> no known problems. >>>>>>> >>>>>>> Should we fix it by replacing the array placement new by normal >>>>>>> placement new for each element? >>>>>>> http://cr.openjdk.java.net/~mdoerr/8216426_array_placement_new/webrev.00/ >>>>>>> >>>>>>> >>>>>>> Best regards, >>>>>>> Martin >>>>>>> >>> >> > From rkennke at redhat.com Tue Jan 15 16:08:24 2019 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 15 Jan 2019 17:08:24 +0100 Subject: RFR(S): 8216426: Usage of array placement new may lead to memory corruption In-Reply-To: References: <61066e81213e40e2840d79025931e597@sap.com> <6fed501b-3f9a-1fc6-78fb-fb64741893c3@oracle.com> <74c66ced7285482290ab7ad5105955c7@sap.com> <6905389f-e38a-a901-2334-e07924bba05b@redhat.com> <269254b5ee9e489a99e8b4af25a4b875@sap.com> <39fd48d5fd1c444b915c3fb84885882a@sap.com> Message-ID: <604a59c6-836d-d89f-ec29-e8e9a14da642@redhat.com> >> I had originally proposed to use placement new for each object: >> (Kim's small request included, now) >> http://cr.openjdk.java.net/~mdoerr/8216426_array_placement_new/webrev.00/ >> >> So seems like we should rather use the webrev.00. > > Ship it! +1 Roman > > /Robbin > >> >> Best regards, >> Martin >> >> >> -----Original Message----- >> From: Roman Kennke >> Sent: Dienstag, 15. Januar 2019 15:44 >> To: Doerr, Martin ; Erik ?sterlund >> ; Robbin Ehn ; >> hotspot-runtime-dev at openjdk.java.net; Kim Barrett >> ; David Holmes (david.holmes at oracle.com) >> >> Subject: Re: RFR(S): 8216426: Usage of array placement new may lead to >> memory corruption >> >> Hi Martin, >> >> The thing is, it is a problem all over the place, and Hotspot can't >> currently be compiled with GCC 8, except when disabling warnings. People >> are working to fix those issues, so for example: >> >> https://bugs.openjdk.java.net/browse/JDK-8214376 >> https://bugs.openjdk.java.net/browse/JDK-8213745 >> https://bugs.openjdk.java.net/browse/JDK-8214272 >> >> etc. >> >> Plus, besides, it's better style to not use memset. >> >> If there's a good C++ construct to achieve the same, why not use it? >> E.g. placement new? >> >> Roman >> >>> Hi Roman and Erik, >>> >>> I don't have GCC 8 so I can't test it. But hotspot heavily uses >>> memset (also with NEW_C_HEAP_ARRAY), so why should it be a problem here? >>> >>> I don't understand why Bucket is not a POD. Its binary form should >>> look like a C structure. >>> And even if it's not POD, why should it yield undefined behavior? >>> We're not using default initialization. >>> >>> I believe C++ does not require NULL to be 0 before C++11. So memset >>> to 0 may yield undefined behavior, but we rely on this at so many >>> places ... >>> >>> Best regards, >>> Martin >>> >>> >>> -----Original Message----- >>> From: Roman Kennke >>> Sent: Dienstag, 15. Januar 2019 14:36 >>> To: Erik ?sterlund ; Doerr, Martin >>> ; Robbin Ehn ; >>> hotspot-runtime-dev at openjdk.java.net; Kim Barrett >>> ; David Holmes (david.holmes at oracle.com) >>> >>> Subject: Re: RFR(S): 8216426: Usage of array placement new may lead >>> to memory corruption >>> >>> Doesn't using memset mean that newer GCC (8) warns about it and thus >>> break compilation? That was the whole point of introducing placement new >>> operator to begin with, IIRC. >>> >>> Roman >>> >>>> Hi Martin, >>>> >>>> Unfortunately, according to the C++03 standard, that field needs to be >>>> public for the class to be a POD. And if it is not a POD, we will have >>>> undefined behaviour. Yay for C++. >>>> >>>> Thanks, >>>> /Erik >>>> >>>> On 2019-01-15 11:51, Doerr, Martin wrote: >>>>> Hi Robbin, >>>>> >>>>> that's fine. I like it simple. >>>>> ?? Version which uses memset and removed constructor: >>>>> http://cr.openjdk.java.net/~mdoerr/8216426_array_placement_new/webrev.01/ >>>>> >>>>> >>>>> I don't like making the field public because it can easily get used >>>>> incorrectly because there are bits encoded into the pointer. >>>>> So I think we should better not provide direct access to it. >>>>> >>>>> Best regards, >>>>> Martin >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Robbin Ehn >>>>> Sent: Dienstag, 15. Januar 2019 10:26 >>>>> To: Erik ?sterlund ; Doerr, Martin >>>>> ; hotspot-runtime-dev at openjdk.java.net; Kim >>>>> Barrett ; David Holmes >>>>> (david.holmes at oracle.com) >>>>> Subject: Re: RFR(S): 8216426: Usage of array placement new may lead to >>>>> memory corruption >>>>> >>>>> On 2019-01-15 10:15, Erik ?sterlund wrote: >>>>>> Hi, >>>>>> >>>>>> Perhaps an alternative approach is to make the Bucket a POD (make the >>>>>> private member public, and remove the >>>>>> constructor), and then simply memset the memory to zero. >>>>> Sorry, we have NMT tracking via NEW_C_HEAP_ARRAY(Bucket, _size, F);. >>>>> So yes, make it a POD and use memset. >>>>> >>>>> /Robbin >>>>> >>>>>> Thanks, >>>>>> /Erik >>>>>> >>>>>> On 2019-01-15 09:03, Robbin Ehn wrote: >>>>>>> Hi Martin, >>>>>>> >>>>>>> The Bucket should extend CHeapObj, now that it could. >>>>>>> Otherwise looks good, thanks. >>>>>>> >>>>>>> Originally Bucket did this and I used memset, but gdb was very upset >>>>>>> by this. >>>>>>> So I changed to array placement new, which meant I had to remove >>>>>>> CHeapObj if I remember correctly :) >>>>>>> >>>>>>> /Robbin >>>>>>> >>>>>>> On 2019-01-14 17:39, Doerr, Martin wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> thanks for looking at this issue and especially for adding >>>>>>>> comments. >>>>>>>> Sounds like this issue should better get fixed although there are >>>>>>>> no known problems. >>>>>>>> >>>>>>>> Should we fix it by replacing the array placement new by normal >>>>>>>> placement new for each element? >>>>>>>> http://cr.openjdk.java.net/~mdoerr/8216426_array_placement_new/webrev.00/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Martin >>>>>>>> >>>> >>> >> From erik.osterlund at oracle.com Tue Jan 15 16:32:27 2019 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Tue, 15 Jan 2019 17:32:27 +0100 Subject: RFR(S): 8216426: Usage of array placement new may lead to memory corruption In-Reply-To: <39fd48d5fd1c444b915c3fb84885882a@sap.com> References: <61066e81213e40e2840d79025931e597@sap.com> <6fed501b-3f9a-1fc6-78fb-fb64741893c3@oracle.com> <74c66ced7285482290ab7ad5105955c7@sap.com> <6905389f-e38a-a901-2334-e07924bba05b@redhat.com> <269254b5ee9e489a99e8b4af25a4b875@sap.com> <39fd48d5fd1c444b915c3fb84885882a@sap.com> Message-ID: Hi Martin, I'm okay with this solution. Maybe we rethink things after C++14. I wonder if NEW_C_HEAP_ARRAY or a similar macro should both allocate and initialize, so that users of the API don't have to trip over the usual (not quite obvious) UB land mines every time an array is allocated, when the solution is typically the same. Thanks, /Erik On 2019-01-15 16:48, Doerr, Martin wrote: > Hi Roman, > > I had originally proposed to use placement new for each object: > (Kim's small request included, now) > http://cr.openjdk.java.net/~mdoerr/8216426_array_placement_new/webrev.00/ > > So seems like we should rather use the webrev.00. > > Best regards, > Martin > > > -----Original Message----- > From: Roman Kennke > Sent: Dienstag, 15. Januar 2019 15:44 > To: Doerr, Martin ; Erik ?sterlund ; Robbin Ehn ; hotspot-runtime-dev at openjdk.java.net; Kim Barrett ; David Holmes (david.holmes at oracle.com) > Subject: Re: RFR(S): 8216426: Usage of array placement new may lead to memory corruption > > Hi Martin, > > The thing is, it is a problem all over the place, and Hotspot can't > currently be compiled with GCC 8, except when disabling warnings. People > are working to fix those issues, so for example: > > https://bugs.openjdk.java.net/browse/JDK-8214376 > https://bugs.openjdk.java.net/browse/JDK-8213745 > https://bugs.openjdk.java.net/browse/JDK-8214272 > > etc. > > Plus, besides, it's better style to not use memset. > > If there's a good C++ construct to achieve the same, why not use it? > E.g. placement new? > > Roman > >> Hi Roman and Erik, >> >> I don't have GCC 8 so I can't test it. But hotspot heavily uses memset (also with NEW_C_HEAP_ARRAY), so why should it be a problem here? >> >> I don't understand why Bucket is not a POD. Its binary form should look like a C structure. >> And even if it's not POD, why should it yield undefined behavior? We're not using default initialization. >> >> I believe C++ does not require NULL to be 0 before C++11. So memset to 0 may yield undefined behavior, but we rely on this at so many places ... >> >> Best regards, >> Martin >> >> >> -----Original Message----- >> From: Roman Kennke >> Sent: Dienstag, 15. Januar 2019 14:36 >> To: Erik ?sterlund ; Doerr, Martin ; Robbin Ehn ; hotspot-runtime-dev at openjdk.java.net; Kim Barrett ; David Holmes (david.holmes at oracle.com) >> Subject: Re: RFR(S): 8216426: Usage of array placement new may lead to memory corruption >> >> Doesn't using memset mean that newer GCC (8) warns about it and thus >> break compilation? That was the whole point of introducing placement new >> operator to begin with, IIRC. >> >> Roman >> >>> Hi Martin, >>> >>> Unfortunately, according to the C++03 standard, that field needs to be >>> public for the class to be a POD. And if it is not a POD, we will have >>> undefined behaviour. Yay for C++. >>> >>> Thanks, >>> /Erik >>> >>> On 2019-01-15 11:51, Doerr, Martin wrote: >>>> Hi Robbin, >>>> >>>> that's fine. I like it simple. >>>> ? Version which uses memset and removed constructor: >>>> http://cr.openjdk.java.net/~mdoerr/8216426_array_placement_new/webrev.01/ >>>> >>>> I don't like making the field public because it can easily get used >>>> incorrectly because there are bits encoded into the pointer. >>>> So I think we should better not provide direct access to it. >>>> >>>> Best regards, >>>> Martin >>>> >>>> >>>> -----Original Message----- >>>> From: Robbin Ehn >>>> Sent: Dienstag, 15. Januar 2019 10:26 >>>> To: Erik ?sterlund ; Doerr, Martin >>>> ; hotspot-runtime-dev at openjdk.java.net; Kim >>>> Barrett ; David Holmes >>>> (david.holmes at oracle.com) >>>> Subject: Re: RFR(S): 8216426: Usage of array placement new may lead to >>>> memory corruption >>>> >>>> On 2019-01-15 10:15, Erik ?sterlund wrote: >>>>> Hi, >>>>> >>>>> Perhaps an alternative approach is to make the Bucket a POD (make the >>>>> private member public, and remove the >>>>> constructor), and then simply memset the memory to zero. >>>> Sorry, we have NMT tracking via NEW_C_HEAP_ARRAY(Bucket, _size, F);. >>>> So yes, make it a POD and use memset. >>>> >>>> /Robbin >>>> >>>>> Thanks, >>>>> /Erik >>>>> >>>>> On 2019-01-15 09:03, Robbin Ehn wrote: >>>>>> Hi Martin, >>>>>> >>>>>> The Bucket should extend CHeapObj, now that it could. >>>>>> Otherwise looks good, thanks. >>>>>> >>>>>> Originally Bucket did this and I used memset, but gdb was very upset >>>>>> by this. >>>>>> So I changed to array placement new, which meant I had to remove >>>>>> CHeapObj if I remember correctly :) >>>>>> >>>>>> /Robbin >>>>>> >>>>>> On 2019-01-14 17:39, Doerr, Martin wrote: >>>>>>> Hi, >>>>>>> >>>>>>> thanks for looking at this issue and especially for adding comments. >>>>>>> Sounds like this issue should better get fixed although there are >>>>>>> no known problems. >>>>>>> >>>>>>> Should we fix it by replacing the array placement new by normal >>>>>>> placement new for each element? >>>>>>> http://cr.openjdk.java.net/~mdoerr/8216426_array_placement_new/webrev.00/ >>>>>>> >>>>>>> >>>>>>> Best regards, >>>>>>> Martin >>>>>>> From linuxtardis at gmail.com Tue Jan 15 16:31:52 2019 From: linuxtardis at gmail.com (Jakub =?UTF-8?Q?Van=C4=9Bk?=) Date: Tue, 15 Jan 2019 17:31:52 +0100 Subject: RFR(M)(round 2): 8215902: Add support for SoftFloat-3e library In-Reply-To: <7f69fc73-1c10-6b68-d657-c9e758d4bf1d@oracle.com> References: <4497ca084b9f48dbb8f6de1aa35c83653fd7acfb.camel@gmail.com> <7f69fc73-1c10-6b68-d657-c9e758d4bf1d@oracle.com> Message-ID: Hi Magnus and Erik, I have added the link to the repository to README and I have removed the link to the mailing list thread. I have also recreated the GitHub repository. Now it is a fork of the mentioned repository with two extra commits containing README and the build scripts. New webrev URL: http://cr.openjdk.java.net/~jakvanek/8215902/webrev.04/ Bug: https://bugs.openjdk.java.net/browse/JDK-8215902 Regards, Jakub On 2019-01-15 at 15:05 +0100, Magnus Ihse Bursie wrote: > On 2018-12-25 16:19, Jakub Van?k wrote: > > Hi, > > > > please review this webrev. It is a successor of the softfloat-3 > > [patch] > > thread (first email > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-November/031311.html > > ) > > > > Changes since the last patch (v6): > > > > - renamed --with-softloat* to --with-sflt* (it is more compact and > > it > > corresponds to the old --with-sflt-lib=... option) > > > > - license is now obtained via --with-sflt-license switch (so it is > > not > > included in OpenJDK source tree) > > > > - updated documentation (slight rewording, added the license > > option) > > > > - checks for default --with/--without behavior are in place again > > (I forgot them when I changed the way the library is detected) > > > > - added a simple testcase - I found a disrepancy between softfloat > > and > > system function behavior. When a float with bits 0x003FFFFF is > > added to 0x00000001, the correct result is 0x00400000, but the > > default software floating point implementation returns > > 0x00000000. > > However I'm not sure where to put this test - now it is in > > test/hotspot/jtreg/compiler/floatingpoint. > > > > - comments in code refer to CR 6757269 and newly JDK-8215902 too. > > > > I have created a repository with SoftFloat-3e with build > > configuration > > specifically for OpenJDK on armel: > > https://github.com/ev3dev-lang-java/softfloat-openjdk > > > > I can add a link to it to the documentation. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215902 > > Webrev: http://cr.openjdk.java.net/~jakvanek/8215902/webrev.02/ > > Hi Jakub, > > In general this looks good. > > Some comments: > > I agree with Erik that you can add a link to your github project; > compiling SoftFloat is outside the scope of the OpenJDK build > instructions, but it can sure be helpful to lower the bar for users > wanting to do that. Just one question: any particular reason you > didn't > create your github repo by forking the official > https://github.com/ucb-bar/berkeley-softfloat-3? That way, it would > have > been easy for users to see that you were not adding any malicious or > suspicious code to the original SoftFloat distribution. > > On the other hand, I think the link to > http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2016-November/000611.html > > is unnecessary and just creates clutter in the documentation. Please > remove it. > > /Magnus > > CI build: > > https://ci.adoptopenjdk.net/view/ev3dev/job/openjdk12_build_ev3_linux/67/ > > > > Cheers, > > > > Jakub > > > > From martin.doerr at sap.com Tue Jan 15 16:41:45 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 15 Jan 2019 16:41:45 +0000 Subject: RFR(S): 8216426: Usage of array placement new may lead to memory corruption In-Reply-To: References: <61066e81213e40e2840d79025931e597@sap.com> <6fed501b-3f9a-1fc6-78fb-fb64741893c3@oracle.com> <74c66ced7285482290ab7ad5105955c7@sap.com> <6905389f-e38a-a901-2334-e07924bba05b@redhat.com> <269254b5ee9e489a99e8b4af25a4b875@sap.com> <39fd48d5fd1c444b915c3fb84885882a@sap.com> Message-ID: <2a332e973aa747b792bfd86b77f4eb30@sap.com> Hi, thanks everyone for reviewing. I also had the idea to introduce something like NEW_CLEARED_C_HEAP_ARRAY. Best regards, Martin -----Original Message----- From: Erik ?sterlund Sent: Dienstag, 15. Januar 2019 17:32 To: Doerr, Martin ; Roman Kennke ; Robbin Ehn ; hotspot-runtime-dev at openjdk.java.net; Kim Barrett ; David Holmes (david.holmes at oracle.com) Subject: Re: RFR(S): 8216426: Usage of array placement new may lead to memory corruption Hi Martin, I'm okay with this solution. Maybe we rethink things after C++14. I wonder if NEW_C_HEAP_ARRAY or a similar macro should both allocate and initialize, so that users of the API don't have to trip over the usual (not quite obvious) UB land mines every time an array is allocated, when the solution is typically the same. Thanks, /Erik On 2019-01-15 16:48, Doerr, Martin wrote: > Hi Roman, > > I had originally proposed to use placement new for each object: > (Kim's small request included, now) > http://cr.openjdk.java.net/~mdoerr/8216426_array_placement_new/webrev.00/ > > So seems like we should rather use the webrev.00. > > Best regards, > Martin > > > -----Original Message----- > From: Roman Kennke > Sent: Dienstag, 15. Januar 2019 15:44 > To: Doerr, Martin ; Erik ?sterlund ; Robbin Ehn ; hotspot-runtime-dev at openjdk.java.net; Kim Barrett ; David Holmes (david.holmes at oracle.com) > Subject: Re: RFR(S): 8216426: Usage of array placement new may lead to memory corruption > > Hi Martin, > > The thing is, it is a problem all over the place, and Hotspot can't > currently be compiled with GCC 8, except when disabling warnings. People > are working to fix those issues, so for example: > > https://bugs.openjdk.java.net/browse/JDK-8214376 > https://bugs.openjdk.java.net/browse/JDK-8213745 > https://bugs.openjdk.java.net/browse/JDK-8214272 > > etc. > > Plus, besides, it's better style to not use memset. > > If there's a good C++ construct to achieve the same, why not use it? > E.g. placement new? > > Roman > >> Hi Roman and Erik, >> >> I don't have GCC 8 so I can't test it. But hotspot heavily uses memset (also with NEW_C_HEAP_ARRAY), so why should it be a problem here? >> >> I don't understand why Bucket is not a POD. Its binary form should look like a C structure. >> And even if it's not POD, why should it yield undefined behavior? We're not using default initialization. >> >> I believe C++ does not require NULL to be 0 before C++11. So memset to 0 may yield undefined behavior, but we rely on this at so many places ... >> >> Best regards, >> Martin >> >> >> -----Original Message----- >> From: Roman Kennke >> Sent: Dienstag, 15. Januar 2019 14:36 >> To: Erik ?sterlund ; Doerr, Martin ; Robbin Ehn ; hotspot-runtime-dev at openjdk.java.net; Kim Barrett ; David Holmes (david.holmes at oracle.com) >> Subject: Re: RFR(S): 8216426: Usage of array placement new may lead to memory corruption >> >> Doesn't using memset mean that newer GCC (8) warns about it and thus >> break compilation? That was the whole point of introducing placement new >> operator to begin with, IIRC. >> >> Roman >> >>> Hi Martin, >>> >>> Unfortunately, according to the C++03 standard, that field needs to be >>> public for the class to be a POD. And if it is not a POD, we will have >>> undefined behaviour. Yay for C++. >>> >>> Thanks, >>> /Erik >>> >>> On 2019-01-15 11:51, Doerr, Martin wrote: >>>> Hi Robbin, >>>> >>>> that's fine. I like it simple. >>>> ? Version which uses memset and removed constructor: >>>> http://cr.openjdk.java.net/~mdoerr/8216426_array_placement_new/webrev.01/ >>>> >>>> I don't like making the field public because it can easily get used >>>> incorrectly because there are bits encoded into the pointer. >>>> So I think we should better not provide direct access to it. >>>> >>>> Best regards, >>>> Martin >>>> >>>> >>>> -----Original Message----- >>>> From: Robbin Ehn >>>> Sent: Dienstag, 15. Januar 2019 10:26 >>>> To: Erik ?sterlund ; Doerr, Martin >>>> ; hotspot-runtime-dev at openjdk.java.net; Kim >>>> Barrett ; David Holmes >>>> (david.holmes at oracle.com) >>>> Subject: Re: RFR(S): 8216426: Usage of array placement new may lead to >>>> memory corruption >>>> >>>> On 2019-01-15 10:15, Erik ?sterlund wrote: >>>>> Hi, >>>>> >>>>> Perhaps an alternative approach is to make the Bucket a POD (make the >>>>> private member public, and remove the >>>>> constructor), and then simply memset the memory to zero. >>>> Sorry, we have NMT tracking via NEW_C_HEAP_ARRAY(Bucket, _size, F);. >>>> So yes, make it a POD and use memset. >>>> >>>> /Robbin >>>> >>>>> Thanks, >>>>> /Erik >>>>> >>>>> On 2019-01-15 09:03, Robbin Ehn wrote: >>>>>> Hi Martin, >>>>>> >>>>>> The Bucket should extend CHeapObj, now that it could. >>>>>> Otherwise looks good, thanks. >>>>>> >>>>>> Originally Bucket did this and I used memset, but gdb was very upset >>>>>> by this. >>>>>> So I changed to array placement new, which meant I had to remove >>>>>> CHeapObj if I remember correctly :) >>>>>> >>>>>> /Robbin >>>>>> >>>>>> On 2019-01-14 17:39, Doerr, Martin wrote: >>>>>>> Hi, >>>>>>> >>>>>>> thanks for looking at this issue and especially for adding comments. >>>>>>> Sounds like this issue should better get fixed although there are >>>>>>> no known problems. >>>>>>> >>>>>>> Should we fix it by replacing the array placement new by normal >>>>>>> placement new for each element? >>>>>>> http://cr.openjdk.java.net/~mdoerr/8216426_array_placement_new/webrev.00/ >>>>>>> >>>>>>> >>>>>>> Best regards, >>>>>>> Martin >>>>>>> From lois.foltan at oracle.com Wed Jan 16 12:29:34 2019 From: lois.foltan at oracle.com (Lois Foltan) Date: Wed, 16 Jan 2019 07:29:34 -0500 Subject: RFR 8215699: -Xlog::file cannot be used with named pipe In-Reply-To: References: Message-ID: <91d8a742-15ee-b51c-f213-45440f0333a6@oracle.com> Looks good Harold! Lois On 1/8/2019 10:08 AM, Harold David Seigel wrote: > Hi, > > Please review this fix for JDK-8215699.? The fix sets the default > logging file count to zero if the log file is a named pipe.? This > prevents the logging code from complaining about trying to do log file > rotation with a non-regular file. > > Open Webrev: > http://cr.openjdk.java.net/~hseigel/bug_8215699/webrev/index.html > > JBS Bug:? https://bugs.openjdk.java.net/browse/JDK-8215699 > > The fix was tested by hand on both Linux-x64 and Mac OS X. Logging to > a named pipe worked when no filecount was specified and when > filecount=0 was specified. > > The fix was regression tested by running Mach5 tiers 1 and 2 tests and > builds on Linux-x64, Windows, and Mac OS X, Mach5 tiers 3 -5 on > Linux-x64, and by running JCK-12 Lang and VM tests on Linux-x64. > > Thanks, Harold > From harold.seigel at oracle.com Wed Jan 16 12:47:38 2019 From: harold.seigel at oracle.com (Harold David Seigel) Date: Wed, 16 Jan 2019 07:47:38 -0500 Subject: RFR 8215699: -Xlog::file cannot be used with named pipe In-Reply-To: <91d8a742-15ee-b51c-f213-45440f0333a6@oracle.com> References: <91d8a742-15ee-b51c-f213-45440f0333a6@oracle.com> Message-ID: Thanks Lois! Harold On 1/16/2019 7:29 AM, Lois Foltan wrote: > Looks good Harold! > Lois > > On 1/8/2019 10:08 AM, Harold David Seigel wrote: >> Hi, >> >> Please review this fix for JDK-8215699.? The fix sets the default >> logging file count to zero if the log file is a named pipe.? This >> prevents the logging code from complaining about trying to do log >> file rotation with a non-regular file. >> >> Open Webrev: >> http://cr.openjdk.java.net/~hseigel/bug_8215699/webrev/index.html >> >> JBS Bug:? https://bugs.openjdk.java.net/browse/JDK-8215699 >> >> The fix was tested by hand on both Linux-x64 and Mac OS X. Logging to >> a named pipe worked when no filecount was specified and when >> filecount=0 was specified. >> >> The fix was regression tested by running Mach5 tiers 1 and 2 tests >> and builds on Linux-x64, Windows, and Mac OS X, Mach5 tiers 3 -5 on >> Linux-x64, and by running JCK-12 Lang and VM tests on Linux-x64. >> >> Thanks, Harold >> > From thomas.stuefe at gmail.com Wed Jan 16 14:25:58 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 16 Jan 2019 15:25:58 +0100 Subject: [RFR]: Per thread IO statistics in JFR In-Reply-To: References: Message-ID: Hi Gunter, (I remove svc but add corelibs and hs-runtime for the jdk/hs parts, respectively. Hope this is not too spammy). This looks all very good. I am not a JFR reviewer (is there such a thing?) but only a JDK reviewer, so I am not sure if I am allowed to review the JFR parts. That said, here it goes: General remarks: A) we may reduce the number of sent events vastly by only sending updates for threads which actually did IO. I know that would require expanding the ThreadStatisticalInfo to keep JFR-specific counters. But I think the memory overhead of the increased size of ThreadStatisticalInfo would be more than offset by the space saved for noop events. What to you think? (Side note, it would be nice to have generic support for this in the JFR layer. If the JFR layer could remember the last values for an event and omit sending it if nothing changed.) B) You could save a bit of work by folding multiple values into one event. Other events seem to do that too, eg. MetaspaceSummary. E.g: instead of having ThreadNetworkWriteStatistics and ThreadNetworkReadStatistics, you could have ThreadNetworkStatistics with "read" and "write" fields, and thus combine the polling functions for those two. Maybe even combine all four values into a single "ThreadIOStatistics" event. Review: Hook functions: - This is bike shedding, but I would like something like "JVM_On()" more, sounding more "hookish", since the functions do not "xxx" but inform the hotspot of "xxx" having occurred - Also, I wonder whether it would make sense to make the len input 64bit (jlong instead of jint) in case we want to use them to instrument 64bit reads too - If you wanted to minimize the number of new JVM_.. hook functions, you could combine network and file io hooks into one: JVM_OnIORead(.. bool is_socket) JVM_OnIOWrite(.. bool is_socket) or even JVM_OnIO(.., bool is_read, bool is_socket). This would also make the dispatching in src/java.base/unix/native/libnio/ch/FileDispatcherImpl.c easier. But this is pure aesthetics, I leave it up to you. --- src/hotspot/share/jfr/metadata/metadata.xml All event definitions have one value, called and labeled "Thread". If you keep them separate, does this field name/label make sense? (I am not fluid with JMC so I do not know where exactly this label text would appear). --- src/hotspot/share/jfr/periodic/jfrPeriodic.cpp GrowableArray written(initial_size); GrowableArray thread_ids(initial_size); You could probably save one GrowableArray and some append calls by something like this: struct data { jlong num; trace_id tid; } GrowableArray - Question, I assume you go thru the trouble of storing the values temporarily since you do not want to call JfrEvent::commit inside the Threads_lock? --- src/hotspot/share/runtime/thread.cpp Nice addition to the extended thread dump. --- src/java.base/unix/native/libnio/ch/FileDispatcherImpl.c - There may be a number of unnecessary casts: e.g. Java_sun_nio_ch_FileDispatcherImpl_read0 JVM_callNetworkReadBytes(env, (jint) readBytes); readBytes is already jint. - You could reduce the code by factoring out that frequent if-else statements: 87 if (readBytes > 0) { 88 if (socket) { 89 JVM_callNetworkReadBytes(env, (jint) readBytes); 90 } else { 91 JVM_callFileReadBytes(env, (jint)readBytes); 92 } 93 } like this static void on_io_read(env, jint nread, jboolean socket) { if (socket) { JVM_callNetworkReadBytes(env, nread); } else { JVM_callFileReadBytes(env, nread); } } you could even add the n>0 condition to the function. - Java_sun_nio_ch_FileDispatcherImpl_pwrite0: you truncate the return value of pread64 to 32bit on 64bit platforms. --- src/java.base/windows/native/libnet/DualStackPlainDatagramSocketImpl.c Probably philosophical but I would leave peek out of the condition. A read is a read. -- src/java.base/unix/native/libnet/SocketOutputStream.c You could move the call to JVM_callNetworkWriteBytes out of the loop (you did this in other places too). -- src/java.base/windows/native/libnio/ch/DatagramDispatcher.c src/java.base/windows/native/libnio/ch/FileDispatcherImpl.c at various places: 52 DWORD read = 0; 83 if (read > 0) { 84 JVM_callNetworkReadBytes(env, read); 85 } DWORD is unsigned, may overflow jint arg? Moot point if you make it 64bit. ---- src/java.base/windows/native/libnet/DualStackPlainDatagramSocketImpl.c Java_java_net_DualStackPlainDatagramSocketImpl_socketSend 462 if (rv > 0) { 463 JVM_callFileWriteBytes(env, rv); 464 } Should this be NetworkWriteBytes? --- src/java.base/windows/native/libnet/SocketOutputStream.c Same here. --- src/java.base/windows/native/libnet/TwoStacksPlainDatagramSocketImpl.c - if (sendto(fd, fullPacket, packetBufferLen, 0, addrp, + if (ret = sendto(fd, fullPacket, packetBufferLen, 0, addrp, addrlen) == SOCKET_ERROR) { NET_ThrowCurrent(env, "Datagram send failed"); } + if (ret > 0) { + JVM_callFileWriteBytes(env, ret); + } + Same here. --- http://cr.openjdk.java.net/~ghaug/webrevs/8216981/src/java.base/windows/native/libnio/ch/DatagramChannelImpl.c.frames.html Java_sun_nio_ch_DatagramChannelImpl_send0 Smae here. --- src/java.base/windows/native/libnio/ch/DatagramDispatcher.c src/java.base/windows/native/libnio/ch/SocketDispatcher.c Same here? --- src/java.base/windows/native/libnio/ch/WindowsSelectorImpl.c + written = send(scoutFd, &byte, 1, 0); + + if (written > 0) { + JVM_callFileWriteBytes(env, written); + } ditto :) Thanks for your work! Cheers, Thomas On Mon, Jan 14, 2019 at 4:59 PM Haug, Gunter wrote: > Hi All, > > Could I please have a review and possibly some opinions on the following > enhancement to JFR and the JDK? > > At SAP we have a per thread IO statistic among our supportability > enhancements which proved to be very helpful for our support engineers. It > might be beneficial for JFR as well and would certainly help us to drive > adoption of OpenJDK. > > The basic idea is simple, we have added fields to the thread class where > the number of bytes read and written from/to file and network are counted > in. The newly created JFR events are written periodically as for example > the ThreadAllocationStatistics event already is. > > In order to collect the data, we have added hooks to the JDK C coding > calling back into the VM. > > I have opened a bug here: > https://bugs.openjdk.java.net/browse/JDK-8216981 > > Here is a webrev: > http://cr.openjdk.java.net/~ghaug/webrevs/8216981 > > There are no tests yet and the code be a bit nicer in places. We will work > on this if/when this feature is deemed acceptable. > > Finally, we have an API in our SAP version of the JDK to access this data > from a Java application. This is used by many SAP applications and I think > we could add an MXBean in a second step, to provide similar functionality. > > Thanks in advance, > Gunter > > > > > From Alan.Bateman at oracle.com Wed Jan 16 14:59:43 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 16 Jan 2019 14:59:43 +0000 Subject: [RFR]: Per thread IO statistics in JFR In-Reply-To: References: Message-ID: Thanks for forwarding as this is a topic that will require a lot of discussion and agreement from several areas due to potential impact on long term maintenance and the potential for some of these native methods to go away. Gunter - can you summarize the approaches that you have explored? In particular, it would be useful to see a write-up of approaches that don't change the native methods to call JVM_* functions at every I/O call. It would also be useful to understand how it compares to dynamic instrumentation today (once there are suitable java methods to instrument). Maybe someone working on JFR can comment on that too. -Alan On 16/01/2019 14:25, Thomas St?fe wrote: > Hi Gunter, > > (I remove svc but add corelibs and hs-runtime for the jdk/hs parts, > respectively. Hope this is not too spammy). > > This looks all very good. > > I am not a JFR reviewer (is there such a thing?) but only a JDK reviewer, > so I am not sure if I am allowed to review the JFR parts. > > That said, here it goes: > > General remarks: > > A) we may reduce the number of sent events vastly by only sending updates > for threads which actually did IO. I know that would require expanding the > ThreadStatisticalInfo to keep JFR-specific counters. But I think the memory > overhead of the increased size of ThreadStatisticalInfo would be more than > offset by the space saved for noop events. What to you think? > > (Side note, it would be nice to have generic support for this in the JFR > layer. If the JFR layer could remember the last values for an event and > omit sending it if nothing changed.) > > B) You could save a bit of work by folding multiple values into one event. > Other events seem to do that too, eg. MetaspaceSummary. E.g: instead of > having ThreadNetworkWriteStatistics and ThreadNetworkReadStatistics, you > could have ThreadNetworkStatistics with "read" and "write" fields, and thus > combine the polling functions for those two. Maybe even combine all four > values into a single "ThreadIOStatistics" event. > > Review: > > Hook functions: > > - This is bike shedding, but I would like something like "JVM_On()" > more, sounding more "hookish", since the functions do not "xxx" but inform > the hotspot of "xxx" having occurred > > - Also, I wonder whether it would make sense to make the len input 64bit > (jlong instead of jint) in case we want to use them to instrument 64bit > reads too > > - If you wanted to minimize the number of new JVM_.. hook functions, you > could combine network and file io hooks into one: > > JVM_OnIORead(.. bool is_socket) > JVM_OnIOWrite(.. bool is_socket) > > or even JVM_OnIO(.., bool is_read, bool is_socket). > > This would also make the dispatching in > src/java.base/unix/native/libnio/ch/FileDispatcherImpl.c easier. But this > is pure aesthetics, I leave it up to you. > > --- > > src/hotspot/share/jfr/metadata/metadata.xml > > All event definitions have one value, called and labeled "Thread". If you > keep them separate, does this field name/label make sense? (I am not fluid > with JMC so I do not know where exactly this label text would appear). > > --- > > src/hotspot/share/jfr/periodic/jfrPeriodic.cpp > > GrowableArray written(initial_size); > GrowableArray thread_ids(initial_size); > > You could probably save one GrowableArray and some append calls by > something like this: > > struct data { jlong num; trace_id tid; } > GrowableArray > > - > > Question, I assume you go thru the trouble of storing the values > temporarily since you do not want to call JfrEvent::commit inside the > Threads_lock? > > --- > > src/hotspot/share/runtime/thread.cpp > > Nice addition to the extended thread dump. > > --- > > src/java.base/unix/native/libnio/ch/FileDispatcherImpl.c > > - There may be a number of unnecessary casts: > > e.g. Java_sun_nio_ch_FileDispatcherImpl_read0 > > JVM_callNetworkReadBytes(env, (jint) readBytes); > > readBytes is already jint. > > - > > You could reduce the code by factoring out that frequent if-else statements: > > 87 if (readBytes > 0) { > 88 if (socket) { > 89 JVM_callNetworkReadBytes(env, (jint) readBytes); > 90 } else { > 91 JVM_callFileReadBytes(env, (jint)readBytes); > 92 } > 93 } > > like this > > static void on_io_read(env, jint nread, jboolean socket) { > if (socket) { > JVM_callNetworkReadBytes(env, nread); > } else { > JVM_callFileReadBytes(env, nread); > } > } > > you could even add the n>0 condition to the function. > > - > > Java_sun_nio_ch_FileDispatcherImpl_pwrite0: you truncate the return value > of pread64 to 32bit on 64bit platforms. > > --- > > src/java.base/windows/native/libnet/DualStackPlainDatagramSocketImpl.c > > Probably philosophical but I would leave peek out of the condition. A read > is a read. > > -- > > src/java.base/unix/native/libnet/SocketOutputStream.c > > You could move the call to JVM_callNetworkWriteBytes out of the loop (you > did this in other places too). > > -- > > src/java.base/windows/native/libnio/ch/DatagramDispatcher.c > src/java.base/windows/native/libnio/ch/FileDispatcherImpl.c > > at various places: > > 52 DWORD read = 0; > > 83 if (read > 0) { > 84 JVM_callNetworkReadBytes(env, read); > 85 } > > DWORD is unsigned, may overflow jint arg? Moot point if you make it 64bit. > > ---- > > src/java.base/windows/native/libnet/DualStackPlainDatagramSocketImpl.c > > Java_java_net_DualStackPlainDatagramSocketImpl_socketSend > > 462 if (rv > 0) { > 463 JVM_callFileWriteBytes(env, rv); > 464 } > > Should this be NetworkWriteBytes? > > --- > > src/java.base/windows/native/libnet/SocketOutputStream.c > > Same here. > > --- > > src/java.base/windows/native/libnet/TwoStacksPlainDatagramSocketImpl.c > > > - if (sendto(fd, fullPacket, packetBufferLen, 0, addrp, > + if (ret = sendto(fd, fullPacket, packetBufferLen, 0, addrp, > addrlen) == SOCKET_ERROR) > { > NET_ThrowCurrent(env, "Datagram send failed"); > } > > + if (ret > 0) { > + JVM_callFileWriteBytes(env, ret); > + } > + > > Same here. > > --- > > http://cr.openjdk.java.net/~ghaug/webrevs/8216981/src/java.base/windows/native/libnio/ch/DatagramChannelImpl.c.frames.html > > Java_sun_nio_ch_DatagramChannelImpl_send0 > > Smae here. > > --- > > src/java.base/windows/native/libnio/ch/DatagramDispatcher.c > src/java.base/windows/native/libnio/ch/SocketDispatcher.c > > > Same here? > > --- > > src/java.base/windows/native/libnio/ch/WindowsSelectorImpl.c > > + written = send(scoutFd, &byte, 1, 0); > + > + if (written > 0) { > + JVM_callFileWriteBytes(env, written); > + } > > ditto :) > > Thanks for your work! > > Cheers, Thomas > > > > > On Mon, Jan 14, 2019 at 4:59 PM Haug, Gunter wrote: > >> Hi All, >> >> Could I please have a review and possibly some opinions on the following >> enhancement to JFR and the JDK? >> >> At SAP we have a per thread IO statistic among our supportability >> enhancements which proved to be very helpful for our support engineers. It >> might be beneficial for JFR as well and would certainly help us to drive >> adoption of OpenJDK. >> >> The basic idea is simple, we have added fields to the thread class where >> the number of bytes read and written from/to file and network are counted >> in. The newly created JFR events are written periodically as for example >> the ThreadAllocationStatistics event already is. >> >> In order to collect the data, we have added hooks to the JDK C coding >> calling back into the VM. >> >> I have opened a bug here: >> https://bugs.openjdk.java.net/browse/JDK-8216981 >> >> Here is a webrev: >> http://cr.openjdk.java.net/~ghaug/webrevs/8216981 >> >> There are no tests yet and the code be a bit nicer in places. We will work >> on this if/when this feature is deemed acceptable. >> >> Finally, we have an API in our SAP version of the JDK to access this data >> from a Java application. This is used by many SAP applications and I think >> we could add an MXBean in a second step, to provide similar functionality. >> >> Thanks in advance, >> Gunter >> >> >> >> >> From daniel.daugherty at oracle.com Wed Jan 16 16:52:29 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 16 Jan 2019 11:52:29 -0500 Subject: RFR (S): 8213397: Stack dump should show more clearly when a thread is blocked on a class initialization monitor In-Reply-To: <9880a1a4-5041-8dcb-288c-10382c6acb09@oracle.com> References: <90bcd939-2066-0a3b-743a-a2c4d55954d7@oracle.com> <5c44ba14-ba6d-b012-f824-6faa9f3ad28b@oracle.com> <7bad7b2b-f310-792f-59c0-710b1098f918@oracle.com> <9880a1a4-5041-8dcb-288c-10382c6acb09@oracle.com> Message-ID: On 1/14/19 8:26 AM, David Holmes wrote: > On 14/01/2019 11:21 pm, coleen.phillimore at oracle.com wrote: >> >> >> On 1/14/19 8:13 AM, David Holmes wrote: >>> Hi Coleen, >>> >>> On 14/01/2019 10:25 pm, coleen.phillimore at oracle.com wrote: >>>> >>>> This is a nice improvement. >>> >>> Thanks for taking a look. >>> >>>> http://cr.openjdk.java.net/~dholmes/8213397/webrev/src/hotspot/share/runtime/vframe.cpp.udiff.html >>>> >>>> >>>> + // top-frame, so we should be waiting on a Class initialization >>>> monitor. >>>> + InstanceKlass* k = thread()->class_to_be_initialized(); >>>> + if (k != NULL) { >>>> + st->print_cr("\t- waiting on the Class initialization monitor for >>>> %s", k->external_name()); >>>> + } >>>> + else { >>>> + assert(false, "OBJECT_WAIT state is unexpected"); >>>> + } >>>> >>>> >>>> Should be } else { >>>> >>>> And I don't think this should be an assert.? There are a couple of >>>> other places that we lock an object monitor from the VM, but I >>>> don't think we wait in these places.? In any case, if we add a >>>> wait, it would take a lot of testing and a long time to get to this >>>> assert to find it needs to add another case here.? So if you remove >>>> the 'else' completely and change the comment to "see if we are >>>> waiting on a class initialization monitor" you don't need to fix >>>> the {}. >>> >>> Initially I thought the "else" might be some JNI or JVM TI case, but >>> that's not so as there's no direct API to do wait(), it just >>> requires invoking the Object.wait method. So at the moment the >>> implicit else is "unreachable" and I wanted to convey that. I chose >>> the assert in case I was wrong, or in the unlikely event a new VM >>> internal call to wait() was ever added and we happened to encounter >>> it. Leaving it empty to me raises the question "how do we get here?". >> >> The thing is, that leaving an assert to find some future case is only >> good if that code is going to execute frequently and we find it in >> testing.? This is not a frequent path.?? Having the assert might be >> hit much later down the road when we've forgotten this.? It's not >> helpful. > > It may not be very helpful but it is more helpful than nothing. > > But I guess I can remove it. Just for the record, I would recommend keeping it. I find it helpful to have assertions in places where the code has reached something unexpected. Instead of: ? assert(false, "OBJECT_WAIT state is unexpected"); I would do it as: ? fatal("OBJECT_WAIT state is unexpected"); to catch it in any form of bits (product, debug, etc). As for tracking back a future occurrence to this review, I often check to see what changeset added an assertion to see the context in which the assertion was placed. The fix is already pushed so again this is just for the record. Dan > > Thanks, > David > ----- > >> >> Thanks, >> Coleen >> >>> >>> Thanks, >>> David >>> >>>> Thanks, >>>> Coleen >>>> >>>> >>>> >>>> On 1/14/19 1:01 AM, David Holmes wrote: >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8213397 >>>>> webrev: http://cr.openjdk.java.net/~dholmes/8213397/webrev/ >>>>> >>>>> Please review this simple enhancement to improve the stack trace >>>>> information when a thread is blocked doing a (logical) Object.wait >>>>> on the monitor associated with Class static initialization. >>>>> >>>>> Details are in the bug report but basically we record, in a >>>>> thread-local variable, the name of the class before the "wait" and >>>>> clear it after, thus allowing the stack dump code to query it if >>>>> it appears we may be in that situation. >>>>> >>>>> In InstanceKlass::initialize_impl I also refactored the code a >>>>> tiny bit to make use of the JavaThread reference to the current >>>>> thread. >>>>> >>>>> A new test using jstack was also added. >>>>> >>>>> Testing: >>>>> ? - mach5 tiers 1 - 3 >>>>> ? - the new test on Windows/Linux/OSX x86 and Solaris sparc, in >>>>> regular and Xcomp mode >>>>> ? - All jstack/stack-dump using tests I could see (linux x64): >>>>> ??? - runtime/Thread >>>>> ??? - serviceability/sa/ >>>>> ??? - serviceability/tmtools/jstack/ >>>>> ??? - vmTestbase/nsk/jvmti/scenarios/sampling/ >>>>> ??? - vmTestbase/nsk/jvmti/MonitorWaited/ . >>>>> ??? - vmTestbase/nsk/jvmti/GetOwnedMonitorInfo/ >>>>> >>>>> Thanks, >>>>> David >>>> >> From daniel.daugherty at oracle.com Wed Jan 16 17:58:25 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 16 Jan 2019 12:58:25 -0500 Subject: RFR(s): 8214975: No hs-err file if fatal error is raised during dynamic initialization. In-Reply-To: <8e1cbb3f-2a40-0594-459f-0143a6c622f9@oracle.com> References: <7c918c7b-6e14-5d60-7677-ab552015936a@oracle.com> <8e1cbb3f-2a40-0594-459f-0143a6c622f9@oracle.com> Message-ID: <107c64bb-a95c-51d2-71a1-077f8e88a76c@oracle.com> > cr (delta); > http://cr.openjdk.java.net/~stuefe/webrevs/8214975-no-hs-errfile-on-early-assert/webrev_delta.00/webrev/ src/hotspot/share/utilities/vmError.cpp ??? No comments. Thumbs up. Dan On 1/14/19 11:15 PM, David Holmes wrote: > Hi Thomas, > > That seems fine to me. > > Please update copyright years to 2019. > > Thanks, > David > > On 15/01/2019 2:01 am, Thomas St?fe wrote: >> Hi David, Dan, >> >> sorry for the extremely long delay. I have been away some weeks. >> >> Could you please give this patch a final glance? >> >> cr (full): >> http://cr.openjdk.java.net/~stuefe/webrevs/8214975-no-hs-errfile-on-early-assert/webrev.00/webrev/ >> cr (delta); >> http://cr.openjdk.java.net/~stuefe/webrevs/8214975-no-hs-errfile-on-early-assert/webrev_delta.00/webrev/ >> >> I only added some small comments and reworked the closing of the >> hs-err file since David was right - in case the hs-err file could not >> be opened, we'd call close(-1). >> >> Thank you! >> >> Cheers, Thomas >> >> >> On Tue, Dec 11, 2018 at 1:58 AM David Holmes > > wrote: >> >> ??? Hi Thomas, >> >> ??? On 8/12/2018 9:21 pm, Thomas St?fe wrote: >> ???? > Hi, >> ???? > >> ???? > may I please have reviews for this small patch: >> ???? > >> ???? > https://bugs.openjdk.java.net/browse/JDK-8214975 >> ???? > >> http://cr.openjdk.java.net/~stuefe/webrevs/8214975-no-hs-errfile-on-early-assert/webrev.00/webrev >> ???? > >> ???? > A fatal error (e.g. assert), if triggered during dynamic >> ???? > initialization, will plain kill the VM without a trace. (A) >> ???? > >> ???? > A alternative variant of this error: VM will get caught up in an >> ???? > endless recursion, repeat "[Too many errors, abort]\n" endlessly, >> ???? > quickly growing its RSS until the OOM Killer kills it. (B) >> ???? > >> ???? > These symptoms are all caused by VMError::report() attempting to >> ??? write >> ???? > to an uninitialized fdStream object (VMError::out and >> VMError::log). >> ???? > These object instances are allocated at global file scope: >> ???? > >> ???? > 1199 fdStream VMError::out(defaultStream::output_fd()); >> ???? > 1200 fdStream VMError::log; // error log used by >> ??? VMError::report_and_die() >> ???? > >> ???? > They are non-trivial (have vtables) and need to be initialized >> ???? > themselves before being used. If the assert happens before >> they are >> ???? > initialized, the vtables will not yet have been set up, and >> once we >> ???? > attempt to call out::write() or log::write(), in an context >> where we >> ???? > only have an outputStream* ptr (e.g. VMError::report()), we >> crash. >> ???? > >> ???? > Depending on which one of VMError::log and VMError::out are still >> ???? > uninitialized, we end up in (A) or (B). In both cases, the >> secondary >> ???? > signal handler (crash_handler()) will catch the signal, re-try >> error >> ???? > reporting and crash again. This is an endless cycle. We do have >> ???? > recursion detection in place to stop this cycle: >> ???? > >> ???? > 1388 if (recursive_error_count++ > 30) { >> ???? > 1389 out.print_raw_cr("[Too many errors, abort]"); >> ???? > 1390 os::die(); >> ???? > 1391 } >> ???? > >> ???? > but this again uses methods of outputStream to write the "Too >> many >> ???? > errors" text, which will crash again before ever reaching >> os::die(). >> ???? > >> ???? > -- >> ???? > >> ???? > Solution: do not rely on global non-trivial C++ objects, >> especially >> ???? > not at global scope. Instead, keep the information which must be >> ???? > preserved across recursions and different threads (which are >> only the >> ???? > logfile handles themselves) in non-c++ (POD) ints. >> ???? > >> ???? > As added safety, do not keep them at global scope but at static >> ???? > function-scope inside VMError::report_and_die() - that moves >> their >> ???? > initialization back to the first time they are called. To >> print, we >> ???? > still need outputStream objects of course, but they can be >> restricted >> ???? > to function scope inside VMError::report_and_die(), and can be >> ???? > recreated each time this function is entered, be it because of >> ???? > recursions of from a different thread. >> >> ??? Okay this seems reasonable - the log is local but the fd it uses is >> ??? static. Only comment is that if prepare_log_file return -1 then >> we will >> ??? call close(-1) here: >> >> ??? 1476? ? ?if (fd_log != fd_out) { >> ??? 1477? ? ? ?close(fd_log); >> ??? 1478? ? ?} >> >> ??? I would have expected to assign to a temporary and only update >> ??? fd_log if >> ??? not -1. >> >> ???? > Additionally, a jtreg regression test is added. >> >> ??? Nit: s/the hotspot/hotspot/ >> >> ??? I note that producing the hs_err log from the test actually induces >> ??? numerous secondary errors. Seems there moay be opportunity to make >> ??? other >> ??? parts of error reporting even more robust. >> >> ??? Thanks, >> ??? David >> >> ???? > Thanks, Thomas >> ???? > >> From coleen.phillimore at oracle.com Wed Jan 16 20:51:56 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 16 Jan 2019 15:51:56 -0500 Subject: RFR 8215699: -Xlog::file cannot be used with named pipe In-Reply-To: <91d8a742-15ee-b51c-f213-45440f0333a6@oracle.com> References: <91d8a742-15ee-b51c-f213-45440f0333a6@oracle.com> Message-ID: <018692d8-e5c4-ef67-857d-564007d20ef9@oracle.com> +1 Coleen On 1/16/19 7:29 AM, Lois Foltan wrote: > Looks good Harold! > Lois > > On 1/8/2019 10:08 AM, Harold David Seigel wrote: >> Hi, >> >> Please review this fix for JDK-8215699.? The fix sets the default >> logging file count to zero if the log file is a named pipe.? This >> prevents the logging code from complaining about trying to do log >> file rotation with a non-regular file. >> >> Open Webrev: >> http://cr.openjdk.java.net/~hseigel/bug_8215699/webrev/index.html >> >> JBS Bug:? https://bugs.openjdk.java.net/browse/JDK-8215699 >> >> The fix was tested by hand on both Linux-x64 and Mac OS X. Logging to >> a named pipe worked when no filecount was specified and when >> filecount=0 was specified. >> >> The fix was regression tested by running Mach5 tiers 1 and 2 tests >> and builds on Linux-x64, Windows, and Mac OS X, Mach5 tiers 3 -5 on >> Linux-x64, and by running JCK-12 Lang and VM tests on Linux-x64. >> >> Thanks, Harold >> > From coleen.phillimore at oracle.com Wed Jan 16 20:57:07 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 16 Jan 2019 15:57:07 -0500 Subject: RFR (S): 8213397: Stack dump should show more clearly when a thread is blocked on a class initialization monitor In-Reply-To: References: <90bcd939-2066-0a3b-743a-a2c4d55954d7@oracle.com> <5c44ba14-ba6d-b012-f824-6faa9f3ad28b@oracle.com> <7bad7b2b-f310-792f-59c0-710b1098f918@oracle.com> <9880a1a4-5041-8dcb-288c-10382c6acb09@oracle.com> Message-ID: On 1/16/19 11:52 AM, Daniel D. Daugherty wrote: > On 1/14/19 8:26 AM, David Holmes wrote: >> On 14/01/2019 11:21 pm, coleen.phillimore at oracle.com wrote: >>> >>> >>> On 1/14/19 8:13 AM, David Holmes wrote: >>>> Hi Coleen, >>>> >>>> On 14/01/2019 10:25 pm, coleen.phillimore at oracle.com wrote: >>>>> >>>>> This is a nice improvement. >>>> >>>> Thanks for taking a look. >>>> >>>>> http://cr.openjdk.java.net/~dholmes/8213397/webrev/src/hotspot/share/runtime/vframe.cpp.udiff.html >>>>> >>>>> >>>>> + // top-frame, so we should be waiting on a Class initialization >>>>> monitor. >>>>> + InstanceKlass* k = thread()->class_to_be_initialized(); >>>>> + if (k != NULL) { >>>>> + st->print_cr("\t- waiting on the Class initialization monitor >>>>> for %s", k->external_name()); >>>>> + } >>>>> + else { >>>>> + assert(false, "OBJECT_WAIT state is unexpected"); >>>>> + } >>>>> >>>>> >>>>> Should be } else { >>>>> >>>>> And I don't think this should be an assert.? There are a couple of >>>>> other places that we lock an object monitor from the VM, but I >>>>> don't think we wait in these places.? In any case, if we add a >>>>> wait, it would take a lot of testing and a long time to get to >>>>> this assert to find it needs to add another case here.? So if you >>>>> remove the 'else' completely and change the comment to "see if we >>>>> are waiting on a class initialization monitor" you don't need to >>>>> fix the {}. >>>> >>>> Initially I thought the "else" might be some JNI or JVM TI case, >>>> but that's not so as there's no direct API to do wait(), it just >>>> requires invoking the Object.wait method. So at the moment the >>>> implicit else is "unreachable" and I wanted to convey that. I chose >>>> the assert in case I was wrong, or in the unlikely event a new VM >>>> internal call to wait() was ever added and we happened to encounter >>>> it. Leaving it empty to me raises the question "how do we get here?". >>> >>> The thing is, that leaving an assert to find some future case is >>> only good if that code is going to execute frequently and we find it >>> in testing.? This is not a frequent path.?? Having the assert might >>> be hit much later down the road when we've forgotten this.? It's not >>> helpful. >> >> It may not be very helpful but it is more helpful than nothing. >> >> But I guess I can remove it. > > Just for the record, I would recommend keeping it. I find it helpful > to have assertions in places where the code has reached something > unexpected. Instead of: > > ? assert(false, "OBJECT_WAIT state is unexpected"); > > I would do it as: > > ? fatal("OBJECT_WAIT state is unexpected"); > > to catch it in any form of bits (product, debug, etc). No, this is even worse!? Do you really want some rarely reproduceable crash coming from a customer?? The assertion isn't even checking for some error in processing, it's for a helpful diagnostic.? The only reason for guarantees is that something *very* bad will happen later. Anyway, this is somewhat of a minor point whether there should have been an assert or not.? My recommendation was what I already wrote. thanks, Coleen > > As for tracking back a future occurrence to this review, I often > check to see what changeset added an assertion to see the context > in which the assertion was placed. > > The fix is already pushed so again this is just for the record. > > Dan > > > >> >> Thanks, >> David >> ----- >> >>> >>> Thanks, >>> Coleen >>> >>>> >>>> Thanks, >>>> David >>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>> >>>>> >>>>> On 1/14/19 1:01 AM, David Holmes wrote: >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8213397 >>>>>> webrev: http://cr.openjdk.java.net/~dholmes/8213397/webrev/ >>>>>> >>>>>> Please review this simple enhancement to improve the stack trace >>>>>> information when a thread is blocked doing a (logical) >>>>>> Object.wait on the monitor associated with Class static >>>>>> initialization. >>>>>> >>>>>> Details are in the bug report but basically we record, in a >>>>>> thread-local variable, the name of the class before the "wait" >>>>>> and clear it after, thus allowing the stack dump code to query it >>>>>> if it appears we may be in that situation. >>>>>> >>>>>> In InstanceKlass::initialize_impl I also refactored the code a >>>>>> tiny bit to make use of the JavaThread reference to the current >>>>>> thread. >>>>>> >>>>>> A new test using jstack was also added. >>>>>> >>>>>> Testing: >>>>>> ? - mach5 tiers 1 - 3 >>>>>> ? - the new test on Windows/Linux/OSX x86 and Solaris sparc, in >>>>>> regular and Xcomp mode >>>>>> ? - All jstack/stack-dump using tests I could see (linux x64): >>>>>> ??? - runtime/Thread >>>>>> ??? - serviceability/sa/ >>>>>> ??? - serviceability/tmtools/jstack/ >>>>>> ??? - vmTestbase/nsk/jvmti/scenarios/sampling/ >>>>>> ??? - vmTestbase/nsk/jvmti/MonitorWaited/ . >>>>>> ??? - vmTestbase/nsk/jvmti/GetOwnedMonitorInfo/ >>>>>> >>>>>> Thanks, >>>>>> David >>>>> >>> > From harold.seigel at oracle.com Wed Jan 16 21:17:55 2019 From: harold.seigel at oracle.com (Harold David Seigel) Date: Wed, 16 Jan 2019 16:17:55 -0500 Subject: RFR 8215699: -Xlog::file cannot be used with named pipe In-Reply-To: <018692d8-e5c4-ef67-857d-564007d20ef9@oracle.com> References: <91d8a742-15ee-b51c-f213-45440f0333a6@oracle.com> <018692d8-e5c4-ef67-857d-564007d20ef9@oracle.com> Message-ID: <4707634e-73be-cbd2-baed-738ce2649ae8@oracle.com> Thanks Coleen! Harold On 1/16/2019 3:51 PM, coleen.phillimore at oracle.com wrote: > +1 > Coleen > > On 1/16/19 7:29 AM, Lois Foltan wrote: >> Looks good Harold! >> Lois >> >> On 1/8/2019 10:08 AM, Harold David Seigel wrote: >>> Hi, >>> >>> Please review this fix for JDK-8215699.? The fix sets the default >>> logging file count to zero if the log file is a named pipe.? This >>> prevents the logging code from complaining about trying to do log >>> file rotation with a non-regular file. >>> >>> Open Webrev: >>> http://cr.openjdk.java.net/~hseigel/bug_8215699/webrev/index.html >>> >>> JBS Bug:? https://bugs.openjdk.java.net/browse/JDK-8215699 >>> >>> The fix was tested by hand on both Linux-x64 and Mac OS X. Logging >>> to a named pipe worked when no filecount was specified and when >>> filecount=0 was specified. >>> >>> The fix was regression tested by running Mach5 tiers 1 and 2 tests >>> and builds on Linux-x64, Windows, and Mac OS X, Mach5 tiers 3 -5 on >>> Linux-x64, and by running JCK-12 Lang and VM tests on Linux-x64. >>> >>> Thanks, Harold >>> >> > From david.holmes at oracle.com Wed Jan 16 22:06:32 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Jan 2019 08:06:32 +1000 Subject: RFR: 8194860: Cleanup Semaphore timed-wait time calculations Message-ID: <7557e8f2-5622-0317-972d-601b607d6b95@oracle.com> bug: https://bugs.openjdk.java.net/browse/JDK-8194860 webrev: http://cr.openjdk.java.net/~dholmes/8194860/webrev/ Details in the bug report, but there was duplication in functionality with regards to timeout conversions/calculations, and the os_bsd.cpp code was broken due to OSXSemaphore and PosixSemaphore having different API's. Summary: - expanded the API to take a relative timeout in millis as well as the existing absolute timeout as a timespec: // wait until the given absolute time is reached bool timedwait(struct timespec ts); // wait until the given relative time elapses bool timedwait(int64_t millis); The millis version simply converts to a timespec and calls the other version e.g bool PosixSemaphore::timedwait(int64_t millis) { struct timespec ts; os::Posix::to_RTC_abstime(&ts, millis); return timedwait(ts); } - added os::Posix::to_RTC_abstime to do the relative to absolute conversion using the existing routines in os::Posix used for PlatformEvent etc. - changed callsites to use new millis version - I had to rearrange the ifndef SOLARIS in os_posix.cpp to expose previously hidden code to Solaris. It isn't all needed by Solaris but I chose not to clutter things with too many ifdefs and only excluded things that really shouldn't be done on Solaris. Also needed to call os::Posix::init on Solaris. Testing (still in progress): - mach 5 tiers 1 - 3 (Linux, Solaris, OS X, Windows) - test/jdk/jdk/jfr (as suspend/resume is the user of the semaphore code) Thanks, David From david.holmes at oracle.com Thu Jan 17 00:23:01 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Jan 2019 10:23:01 +1000 Subject: [RFR]: Per thread IO statistics in JFR In-Reply-To: References: Message-ID: <131aa47d-d794-e3d7-ab64-fa5ff3b03952@oracle.com> On 17/01/2019 12:59 am, Alan Bateman wrote: > > Thanks for forwarding as this is a topic that will require a lot of > discussion and agreement from several areas due to potential impact on > long term maintenance and the potential for some of these native methods > to go away. > > Gunter - can you summarize the approaches that you have explored? In > particular, it would be useful to see a write-up of approaches that > don't change the native methods to call JVM_* functions at every I/O > call. Indeed! Under the adage "you shouldn't pay for what you don't use" this seems an unacceptable penalty on I/O operations if you don't want to gather the event info - and possibly excessive even if you do! The dynamic instrumentation approach was adopted because static instrumentation like this was not considered appropriate. David ----- > It would also be useful to understand how it compares to dynamic > instrumentation today (once there are suitable java methods to > instrument). Maybe someone working on JFR can comment on that too. > > -Alan > > On 16/01/2019 14:25, Thomas St?fe wrote: >> Hi Gunter, >> >> (I remove svc but add corelibs and hs-runtime for the jdk/hs parts, >> respectively. Hope this is not too spammy). >> >> This looks all very good. >> >> I am not a JFR reviewer (is there such a thing?) but only a JDK reviewer, >> so I am not sure if I am allowed to review the JFR parts. >> >> That said, here it goes: >> >> General remarks: >> >> A) we may reduce the number of sent events vastly by only sending updates >> for threads which actually did IO. I know that would require expanding >> the >> ThreadStatisticalInfo to keep JFR-specific counters. But I think the >> memory >> overhead of the increased size of ThreadStatisticalInfo would be more >> than >> offset by the space saved for noop events. What to you think? >> >> (Side note, it would be nice to have generic support for this in the JFR >> layer. If the JFR layer could remember the last values for an event and >> omit sending it if nothing changed.) >> >> B) You could save a bit of work by folding multiple values into one >> event. >> Other events seem to do that too, eg. MetaspaceSummary. E.g: instead of >> having ThreadNetworkWriteStatistics and ThreadNetworkReadStatistics, you >> could have ThreadNetworkStatistics with "read" and "write" fields, and >> thus >> combine the polling functions for those two. Maybe even combine all four >> values into a single "ThreadIOStatistics" event. >> >> Review: >> >> Hook functions: >> >> - This is bike shedding, but I would like something like "JVM_On()" >> more, sounding more "hookish", since the functions do not "xxx" but >> inform >> the hotspot of "xxx" having occurred >> >> - Also, I wonder whether it would make sense to make the len input 64bit >> (jlong instead of jint) in case we want to use them to instrument 64bit >> reads too >> >> - If you wanted to minimize the number of new JVM_.. hook functions, you >> could combine network and file io hooks into one: >> >> JVM_OnIORead(.. bool is_socket) >> JVM_OnIOWrite(.. bool is_socket) >> >> or even JVM_OnIO(.., bool is_read, bool is_socket). >> >> This would also make the dispatching in >> src/java.base/unix/native/libnio/ch/FileDispatcherImpl.c easier. But this >> is pure aesthetics, I leave it up to you. >> >> --- >> >> src/hotspot/share/jfr/metadata/metadata.xml >> >> All event definitions have one value, called and labeled "Thread". If you >> keep them separate, does this field name/label make sense? (I am not >> fluid >> with JMC so I do not know where exactly this label text would appear). >> >> --- >> >> src/hotspot/share/jfr/periodic/jfrPeriodic.cpp >> >> ?? GrowableArray written(initial_size); >> ?? GrowableArray thread_ids(initial_size); >> >> You could probably save one GrowableArray and some append calls by >> something like this: >> >> struct data { jlong num; trace_id tid; } >> GrowableArray >> >> - >> >> Question, I assume you go thru the trouble of storing the values >> temporarily since you do not want to call JfrEvent::commit inside the >> Threads_lock? >> >> --- >> >> src/hotspot/share/runtime/thread.cpp >> >> Nice addition to the extended thread dump. >> >> --- >> >> src/java.base/unix/native/libnio/ch/FileDispatcherImpl.c >> >> - There may be a number of unnecessary casts: >> >> e.g. Java_sun_nio_ch_FileDispatcherImpl_read0 >> >> JVM_callNetworkReadBytes(env, (jint) readBytes); >> >> readBytes is already jint. >> >> - >> >> You could reduce the code by factoring out that frequent if-else >> statements: >> >> ?? 87???? if (readBytes > 0) { >> ?? 88???????? if (socket) { >> ?? 89???????????? JVM_callNetworkReadBytes(env, (jint) readBytes); >> ?? 90???????? } else { >> ?? 91???????????? JVM_callFileReadBytes(env, (jint)readBytes); >> ?? 92???????? } >> ?? 93???? } >> >> like this >> >> static void on_io_read(env, jint nread, jboolean socket) { >> ??????????? if (socket) { >> ??????????????? JVM_callNetworkReadBytes(env, nread); >> ??????????? } else { >> ??????????????? JVM_callFileReadBytes(env, nread); >> ??????????? } >> } >> >> you could even add the n>0 condition to the function. >> >> - >> >> Java_sun_nio_ch_FileDispatcherImpl_pwrite0: you truncate the return value >> of pread64 to 32bit on 64bit platforms. >> >> --- >> >> src/java.base/windows/native/libnet/DualStackPlainDatagramSocketImpl.c >> >> Probably philosophical but I would leave peek out of the condition. A >> read >> is a read. >> >> -- >> >> src/java.base/unix/native/libnet/SocketOutputStream.c >> >> You could move the call to JVM_callNetworkWriteBytes out of the loop (you >> did this in other places too). >> >> -- >> >> src/java.base/windows/native/libnio/ch/DatagramDispatcher.c >> src/java.base/windows/native/libnio/ch/FileDispatcherImpl.c >> >> at various places: >> >> ?? 52???? DWORD read = 0; >> >> ?? 83???? if (read > 0) { >> ?? 84?????? JVM_callNetworkReadBytes(env, read); >> ?? 85???? } >> >> DWORD is unsigned, may overflow jint arg? Moot point if you make it >> 64bit. >> >> ---- >> >> src/java.base/windows/native/libnet/DualStackPlainDatagramSocketImpl.c >> >> Java_java_net_DualStackPlainDatagramSocketImpl_socketSend >> >> ? 462???? if (rv > 0) { >> ? 463?????? JVM_callFileWriteBytes(env, rv); >> ? 464???? } >> >> Should this be NetworkWriteBytes? >> >> --- >> >> src/java.base/windows/native/libnet/SocketOutputStream.c >> >> Same here. >> >> --- >> >> src/java.base/windows/native/libnet/TwoStacksPlainDatagramSocketImpl.c >> >> >> -??? if (sendto(fd, fullPacket, packetBufferLen, 0, addrp, >> +??? if (ret = sendto(fd, fullPacket, packetBufferLen, 0, addrp, >> ???????????????? addrlen) == SOCKET_ERROR) >> ????? { >> ????????? NET_ThrowCurrent(env, "Datagram send failed"); >> ????? } >> >> +??? if (ret > 0) { >> +????? JVM_callFileWriteBytes(env, ret); >> +??? } >> + >> >> Same here. >> >> --- >> >> http://cr.openjdk.java.net/~ghaug/webrevs/8216981/src/java.base/windows/native/libnio/ch/DatagramChannelImpl.c.frames.html >> >> >> Java_sun_nio_ch_DatagramChannelImpl_send0 >> >> Smae here. >> >> --- >> >> src/java.base/windows/native/libnio/ch/DatagramDispatcher.c >> src/java.base/windows/native/libnio/ch/SocketDispatcher.c >> >> >> Same here? >> >> --- >> >> src/java.base/windows/native/libnio/ch/WindowsSelectorImpl.c >> >> +??? written = send(scoutFd, &byte, 1, 0); >> + >> +??? if (written > 0) { >> +??????? JVM_callFileWriteBytes(env, written); >> +??? } >> >> ditto :) >> >> Thanks for your work! >> >> Cheers, Thomas >> >> >> >> >> On Mon, Jan 14, 2019 at 4:59 PM Haug, Gunter wrote: >> >>> Hi All, >>> >>> Could I please have a review and possibly some opinions on the following >>> enhancement to JFR and the JDK? >>> >>> At SAP we have a per thread IO statistic among our supportability >>> enhancements which proved to be very helpful for our support >>> engineers. It >>> might be beneficial for JFR as well and would certainly help us to drive >>> adoption of OpenJDK. >>> >>> The basic idea is simple, we have added fields to the thread class where >>> the number of bytes read and written from/to file and network are >>> counted >>> in. The newly created JFR events are written periodically as for example >>> the ThreadAllocationStatistics event already is. >>> >>> In order to collect the data, we have added hooks to the JDK C coding >>> calling back into the VM. >>> >>> I have opened a bug here: >>> https://bugs.openjdk.java.net/browse/JDK-8216981 >>> >>> Here is a webrev: >>> http://cr.openjdk.java.net/~ghaug/webrevs/8216981 >>> >>> There are no tests yet and the code be a bit nicer in places. We will >>> work >>> on this if/when this feature is deemed acceptable. >>> >>> Finally, we have an API in our SAP version of the JDK to access this >>> data >>> from a Java application. This is used by many SAP applications and I >>> think >>> we could add an MXBean in a second step, to provide similar >>> functionality. >>> >>> Thanks in advance, >>> Gunter >>> >>> >>> >>> >>> > From david.holmes at oracle.com Thu Jan 17 02:28:33 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Jan 2019 12:28:33 +1000 Subject: RFR (S): 8213397: Stack dump should show more clearly when a thread is blocked on a class initialization monitor In-Reply-To: References: <90bcd939-2066-0a3b-743a-a2c4d55954d7@oracle.com> <5c44ba14-ba6d-b012-f824-6faa9f3ad28b@oracle.com> <7bad7b2b-f310-792f-59c0-710b1098f918@oracle.com> <9880a1a4-5041-8dcb-288c-10382c6acb09@oracle.com> Message-ID: <616fb6e0-0ff6-b397-5214-30da1db1d949@oracle.com> On 17/01/2019 6:57 am, coleen.phillimore at oracle.com wrote: > On 1/16/19 11:52 AM, Daniel D. Daugherty wrote: >> On 1/14/19 8:26 AM, David Holmes wrote: >>> On 14/01/2019 11:21 pm, coleen.phillimore at oracle.com wrote: >>>> >>>> >>>> On 1/14/19 8:13 AM, David Holmes wrote: >>>>> Hi Coleen, >>>>> >>>>> On 14/01/2019 10:25 pm, coleen.phillimore at oracle.com wrote: >>>>>> >>>>>> This is a nice improvement. >>>>> >>>>> Thanks for taking a look. >>>>> >>>>>> http://cr.openjdk.java.net/~dholmes/8213397/webrev/src/hotspot/share/runtime/vframe.cpp.udiff.html >>>>>> >>>>>> >>>>>> + // top-frame, so we should be waiting on a Class initialization >>>>>> monitor. >>>>>> + InstanceKlass* k = thread()->class_to_be_initialized(); >>>>>> + if (k != NULL) { >>>>>> + st->print_cr("\t- waiting on the Class initialization monitor >>>>>> for %s", k->external_name()); >>>>>> + } >>>>>> + else { >>>>>> + assert(false, "OBJECT_WAIT state is unexpected"); >>>>>> + } >>>>>> >>>>>> >>>>>> Should be } else { >>>>>> >>>>>> And I don't think this should be an assert.? There are a couple of >>>>>> other places that we lock an object monitor from the VM, but I >>>>>> don't think we wait in these places.? In any case, if we add a >>>>>> wait, it would take a lot of testing and a long time to get to >>>>>> this assert to find it needs to add another case here.? So if you >>>>>> remove the 'else' completely and change the comment to "see if we >>>>>> are waiting on a class initialization monitor" you don't need to >>>>>> fix the {}. >>>>> >>>>> Initially I thought the "else" might be some JNI or JVM TI case, >>>>> but that's not so as there's no direct API to do wait(), it just >>>>> requires invoking the Object.wait method. So at the moment the >>>>> implicit else is "unreachable" and I wanted to convey that. I chose >>>>> the assert in case I was wrong, or in the unlikely event a new VM >>>>> internal call to wait() was ever added and we happened to encounter >>>>> it. Leaving it empty to me raises the question "how do we get here?". >>>> >>>> The thing is, that leaving an assert to find some future case is >>>> only good if that code is going to execute frequently and we find it >>>> in testing.? This is not a frequent path.?? Having the assert might >>>> be hit much later down the road when we've forgotten this.? It's not >>>> helpful. >>> >>> It may not be very helpful but it is more helpful than nothing. >>> >>> But I guess I can remove it. >> >> Just for the record, I would recommend keeping it. I find it helpful >> to have assertions in places where the code has reached something >> unexpected. Instead of: >> >> ? assert(false, "OBJECT_WAIT state is unexpected"); >> >> I would do it as: >> >> ? fatal("OBJECT_WAIT state is unexpected"); >> >> to catch it in any form of bits (product, debug, etc). > > No, this is even worse! I have to agree with Coleen here - at most an assert is warranted so that during testing if we hit such an unexpected condition it is brought to our attention. But if the unexpected condition hits in the wild we do not want to crash the VM! Nothing bad happens if we find the unexpected condition, we just won't report anything. For the record it was pushed with no assert, as Coleen requested. David > Do you really want some rarely reproduceable > crash coming from a customer?? The assertion isn't even checking for > some error in processing, it's for a helpful diagnostic.? The only > reason for guarantees is that something *very* bad will happen later. > > Anyway, this is somewhat of a minor point whether there should have been > an assert or not.? My recommendation was what I already wrote. > thanks, > Coleen >> >> As for tracking back a future occurrence to this review, I often >> check to see what changeset added an assertion to see the context >> in which the assertion was placed. >> >> The fix is already pushed so again this is just for the record. >> >> Dan >> >> >> >>> >>> Thanks, >>> David >>> ----- >>> >>>> >>>> Thanks, >>>> Coleen >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Thanks, >>>>>> Coleen >>>>>> >>>>>> >>>>>> >>>>>> On 1/14/19 1:01 AM, David Holmes wrote: >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8213397 >>>>>>> webrev: http://cr.openjdk.java.net/~dholmes/8213397/webrev/ >>>>>>> >>>>>>> Please review this simple enhancement to improve the stack trace >>>>>>> information when a thread is blocked doing a (logical) >>>>>>> Object.wait on the monitor associated with Class static >>>>>>> initialization. >>>>>>> >>>>>>> Details are in the bug report but basically we record, in a >>>>>>> thread-local variable, the name of the class before the "wait" >>>>>>> and clear it after, thus allowing the stack dump code to query it >>>>>>> if it appears we may be in that situation. >>>>>>> >>>>>>> In InstanceKlass::initialize_impl I also refactored the code a >>>>>>> tiny bit to make use of the JavaThread reference to the current >>>>>>> thread. >>>>>>> >>>>>>> A new test using jstack was also added. >>>>>>> >>>>>>> Testing: >>>>>>> ? - mach5 tiers 1 - 3 >>>>>>> ? - the new test on Windows/Linux/OSX x86 and Solaris sparc, in >>>>>>> regular and Xcomp mode >>>>>>> ? - All jstack/stack-dump using tests I could see (linux x64): >>>>>>> ??? - runtime/Thread >>>>>>> ??? - serviceability/sa/ >>>>>>> ??? - serviceability/tmtools/jstack/ >>>>>>> ??? - vmTestbase/nsk/jvmti/scenarios/sampling/ >>>>>>> ??? - vmTestbase/nsk/jvmti/MonitorWaited/ . >>>>>>> ??? - vmTestbase/nsk/jvmti/GetOwnedMonitorInfo/ >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>> >>>> >> > From david.holmes at oracle.com Thu Jan 17 04:58:50 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Jan 2019 14:58:50 +1000 Subject: RFR: 8194860: Cleanup Semaphore timed-wait time calculations In-Reply-To: <7557e8f2-5622-0317-972d-601b607d6b95@oracle.com> References: <7557e8f2-5622-0317-972d-601b607d6b95@oracle.com> Message-ID: Withdrawn temporarily. The OS X changes were still being tested and they don't work. For some reason we're using kernel semaphores on OS X and they seem to take a relative timeout directly. That explains why they had a different API but doesn't help with the fact that the calling code expects OSXSemaphore and PosixSemaphore to have the same API. David On 17/01/2019 8:06 am, David Holmes wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8194860 > webrev: http://cr.openjdk.java.net/~dholmes/8194860/webrev/ > > Details in the bug report, but there was duplication in functionality > with regards to timeout conversions/calculations, and the os_bsd.cpp > code was broken due to OSXSemaphore and PosixSemaphore having different > API's. > > Summary: > - expanded the API to take a relative timeout in millis as well as the > existing absolute timeout as a timespec: > > ? // wait until the given absolute time is reached > ? bool timedwait(struct timespec ts); > ? // wait until the given relative time elapses > ? bool timedwait(int64_t millis); > > The millis version simply converts to a timespec and calls the other > version e.g > > bool PosixSemaphore::timedwait(int64_t millis) { > ? struct timespec ts; > ? os::Posix::to_RTC_abstime(&ts, millis); > ? return timedwait(ts); > } > > - added os::Posix::to_RTC_abstime to do the relative to absolute > conversion using the existing routines in os::Posix used for > PlatformEvent etc. > > - changed callsites to use new millis version > > - I had to rearrange the ifndef SOLARIS in os_posix.cpp to expose > previously hidden code to Solaris. It isn't all needed by Solaris but I > chose not to clutter things with too many ifdefs and only excluded > things that really shouldn't be done on Solaris. Also needed to call > os::Posix::init on Solaris. > > Testing (still in progress): > - mach 5 tiers 1 - 3 (Linux, Solaris, OS X, Windows) > - test/jdk/jdk/jfr (as suspend/resume is the user of the semaphore code) > > Thanks, > David From david.holmes at oracle.com Thu Jan 17 07:01:10 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Jan 2019 17:01:10 +1000 Subject: RFR: 8194860: Cleanup Semaphore timed-wait time calculations In-Reply-To: References: <7557e8f2-5622-0317-972d-601b607d6b95@oracle.com> Message-ID: <11acad5f-f132-63d1-1476-6b8fc6118f52@oracle.com> Take 2: webrev updated in place. For OSXSemaphore I simply changed the existing timedwait method to take the single millis arg as used by the new PosixSemaphore so that calling code is correct for both cases. I also deleted the unnecessary currenttime() method. I chose not to implement the absolute timedwait because the conversion to a relative wait as needed by the kernel semaphore is non-trivial and as its unused it would be untested. David On 17/01/2019 2:58 pm, David Holmes wrote: > Withdrawn temporarily. > > The OS X changes were still being tested and they don't work. For some > reason we're using kernel semaphores on OS X and they seem to take a > relative timeout directly. That explains why they had a different API > but doesn't help with the fact that the calling code expects > OSXSemaphore and PosixSemaphore to have the same API. > > David > > On 17/01/2019 8:06 am, David Holmes wrote: >> bug: https://bugs.openjdk.java.net/browse/JDK-8194860 >> webrev: http://cr.openjdk.java.net/~dholmes/8194860/webrev/ >> >> Details in the bug report, but there was duplication in functionality >> with regards to timeout conversions/calculations, and the os_bsd.cpp >> code was broken due to OSXSemaphore and PosixSemaphore having >> different API's. >> >> Summary: >> - expanded the API to take a relative timeout in millis as well as the >> existing absolute timeout as a timespec: >> >> ?? // wait until the given absolute time is reached >> ?? bool timedwait(struct timespec ts); >> ?? // wait until the given relative time elapses >> ?? bool timedwait(int64_t millis); >> >> The millis version simply converts to a timespec and calls the other >> version e.g >> >> bool PosixSemaphore::timedwait(int64_t millis) { >> ?? struct timespec ts; >> ?? os::Posix::to_RTC_abstime(&ts, millis); >> ?? return timedwait(ts); >> } >> >> - added os::Posix::to_RTC_abstime to do the relative to absolute >> conversion using the existing routines in os::Posix used for >> PlatformEvent etc. >> >> - changed callsites to use new millis version >> >> - I had to rearrange the ifndef SOLARIS in os_posix.cpp to expose >> previously hidden code to Solaris. It isn't all needed by Solaris but >> I chose not to clutter things with too many ifdefs and only excluded >> things that really shouldn't be done on Solaris. Also needed to call >> os::Posix::init on Solaris. >> >> Testing (still in progress): >> - mach 5 tiers 1 - 3 (Linux, Solaris, OS X, Windows) >> - test/jdk/jdk/jfr (as suspend/resume is the user of the semaphore code) >> >> Thanks, >> David From thomas.stuefe at gmail.com Thu Jan 17 07:23:58 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 17 Jan 2019 08:23:58 +0100 Subject: [RFR]: Per thread IO statistics in JFR In-Reply-To: <131aa47d-d794-e3d7-ab64-fa5ff3b03952@oracle.com> References: <131aa47d-d794-e3d7-ab64-fa5ff3b03952@oracle.com> Message-ID: On Thu, Jan 17, 2019 at 1:23 AM David Holmes wrote: > On 17/01/2019 12:59 am, Alan Bateman wrote: > > > > Thanks for forwarding as this is a topic that will require a lot of > > discussion and agreement from several areas due to potential impact on > > long term maintenance and the potential for some of these native methods > > to go away. > > > > Gunter - can you summarize the approaches that you have explored? In > > particular, it would be useful to see a write-up of approaches that > > don't change the native methods to call JVM_* functions at every I/O > > call. > > Indeed! Under the adage "you shouldn't pay for what you don't use" this > seems an unacceptable penalty on I/O operations if you don't want to > gather the event info - and possibly excessive even if you do! The > dynamic instrumentation approach was adopted because static > instrumentation like this was not considered appropriate. > > You noticed that all Gunther does is to increment stat counters in the VM, he does not generate JFR events at all? Do you object against keeping these counters (which basically boils down to Thread::current->stat_structure->counter++)? Or do you even object against making upcalls into the jvm? Note that, if deemed necessary, we could omit updating the counters unless JFR or our extended thread dumps are activated (which are the consumers of the counters). In any case, I would have assumed the costs for upcall + counter update to be insignificant compared to the IO calls. We should of course measure that. If you generally object upcalls into the libjvm for statistical/monitoring reasons, this would make matters on a number of fronts more complicated. For instance, it was discussed extending NMT coverage to the JDK - which is already in part reality at Unsafe.AllocateMemory - and this would have to be done with upcalls too. Kind Regards, Thomas David > ----- > > > It would also be useful to understand how it compares to dynamic > > instrumentation today (once there are suitable java methods to > > instrument). Maybe someone working on JFR can comment on that too. > > > > -Alan > > > > On 16/01/2019 14:25, Thomas St?fe wrote: > >> Hi Gunter, > >> > >> (I remove svc but add corelibs and hs-runtime for the jdk/hs parts, > >> respectively. Hope this is not too spammy). > >> > >> This looks all very good. > >> > >> I am not a JFR reviewer (is there such a thing?) but only a JDK > reviewer, > >> so I am not sure if I am allowed to review the JFR parts. > >> > >> That said, here it goes: > >> > >> General remarks: > >> > >> A) we may reduce the number of sent events vastly by only sending > updates > >> for threads which actually did IO. I know that would require expanding > >> the > >> ThreadStatisticalInfo to keep JFR-specific counters. But I think the > >> memory > >> overhead of the increased size of ThreadStatisticalInfo would be more > >> than > >> offset by the space saved for noop events. What to you think? > >> > >> (Side note, it would be nice to have generic support for this in the JFR > >> layer. If the JFR layer could remember the last values for an event and > >> omit sending it if nothing changed.) > >> > >> B) You could save a bit of work by folding multiple values into one > >> event. > >> Other events seem to do that too, eg. MetaspaceSummary. E.g: instead of > >> having ThreadNetworkWriteStatistics and ThreadNetworkReadStatistics, you > >> could have ThreadNetworkStatistics with "read" and "write" fields, and > >> thus > >> combine the polling functions for those two. Maybe even combine all four > >> values into a single "ThreadIOStatistics" event. > >> > >> Review: > >> > >> Hook functions: > >> > >> - This is bike shedding, but I would like something like "JVM_On()" > >> more, sounding more "hookish", since the functions do not "xxx" but > >> inform > >> the hotspot of "xxx" having occurred > >> > >> - Also, I wonder whether it would make sense to make the len input 64bit > >> (jlong instead of jint) in case we want to use them to instrument 64bit > >> reads too > >> > >> - If you wanted to minimize the number of new JVM_.. hook functions, you > >> could combine network and file io hooks into one: > >> > >> JVM_OnIORead(.. bool is_socket) > >> JVM_OnIOWrite(.. bool is_socket) > >> > >> or even JVM_OnIO(.., bool is_read, bool is_socket). > >> > >> This would also make the dispatching in > >> src/java.base/unix/native/libnio/ch/FileDispatcherImpl.c easier. But > this > >> is pure aesthetics, I leave it up to you. > >> > >> --- > >> > >> src/hotspot/share/jfr/metadata/metadata.xml > >> > >> All event definitions have one value, called and labeled "Thread". If > you > >> keep them separate, does this field name/label make sense? (I am not > >> fluid > >> with JMC so I do not know where exactly this label text would appear). > >> > >> --- > >> > >> src/hotspot/share/jfr/periodic/jfrPeriodic.cpp > >> > >> GrowableArray written(initial_size); > >> GrowableArray thread_ids(initial_size); > >> > >> You could probably save one GrowableArray and some append calls by > >> something like this: > >> > >> struct data { jlong num; trace_id tid; } > >> GrowableArray > >> > >> - > >> > >> Question, I assume you go thru the trouble of storing the values > >> temporarily since you do not want to call JfrEvent::commit inside the > >> Threads_lock? > >> > >> --- > >> > >> src/hotspot/share/runtime/thread.cpp > >> > >> Nice addition to the extended thread dump. > >> > >> --- > >> > >> src/java.base/unix/native/libnio/ch/FileDispatcherImpl.c > >> > >> - There may be a number of unnecessary casts: > >> > >> e.g. Java_sun_nio_ch_FileDispatcherImpl_read0 > >> > >> JVM_callNetworkReadBytes(env, (jint) readBytes); > >> > >> readBytes is already jint. > >> > >> - > >> > >> You could reduce the code by factoring out that frequent if-else > >> statements: > >> > >> 87 if (readBytes > 0) { > >> 88 if (socket) { > >> 89 JVM_callNetworkReadBytes(env, (jint) readBytes); > >> 90 } else { > >> 91 JVM_callFileReadBytes(env, (jint)readBytes); > >> 92 } > >> 93 } > >> > >> like this > >> > >> static void on_io_read(env, jint nread, jboolean socket) { > >> if (socket) { > >> JVM_callNetworkReadBytes(env, nread); > >> } else { > >> JVM_callFileReadBytes(env, nread); > >> } > >> } > >> > >> you could even add the n>0 condition to the function. > >> > >> - > >> > >> Java_sun_nio_ch_FileDispatcherImpl_pwrite0: you truncate the return > value > >> of pread64 to 32bit on 64bit platforms. > >> > >> --- > >> > >> src/java.base/windows/native/libnet/DualStackPlainDatagramSocketImpl.c > >> > >> Probably philosophical but I would leave peek out of the condition. A > >> read > >> is a read. > >> > >> -- > >> > >> src/java.base/unix/native/libnet/SocketOutputStream.c > >> > >> You could move the call to JVM_callNetworkWriteBytes out of the loop > (you > >> did this in other places too). > >> > >> -- > >> > >> src/java.base/windows/native/libnio/ch/DatagramDispatcher.c > >> src/java.base/windows/native/libnio/ch/FileDispatcherImpl.c > >> > >> at various places: > >> > >> 52 DWORD read = 0; > >> > >> 83 if (read > 0) { > >> 84 JVM_callNetworkReadBytes(env, read); > >> 85 } > >> > >> DWORD is unsigned, may overflow jint arg? Moot point if you make it > >> 64bit. > >> > >> ---- > >> > >> src/java.base/windows/native/libnet/DualStackPlainDatagramSocketImpl.c > >> > >> Java_java_net_DualStackPlainDatagramSocketImpl_socketSend > >> > >> 462 if (rv > 0) { > >> 463 JVM_callFileWriteBytes(env, rv); > >> 464 } > >> > >> Should this be NetworkWriteBytes? > >> > >> --- > >> > >> src/java.base/windows/native/libnet/SocketOutputStream.c > >> > >> Same here. > >> > >> --- > >> > >> src/java.base/windows/native/libnet/TwoStacksPlainDatagramSocketImpl.c > >> > >> > >> - if (sendto(fd, fullPacket, packetBufferLen, 0, addrp, > >> + if (ret = sendto(fd, fullPacket, packetBufferLen, 0, addrp, > >> addrlen) == SOCKET_ERROR) > >> { > >> NET_ThrowCurrent(env, "Datagram send failed"); > >> } > >> > >> + if (ret > 0) { > >> + JVM_callFileWriteBytes(env, ret); > >> + } > >> + > >> > >> Same here. > >> > >> --- > >> > >> > http://cr.openjdk.java.net/~ghaug/webrevs/8216981/src/java.base/windows/native/libnio/ch/DatagramChannelImpl.c.frames.html > >> > >> > >> Java_sun_nio_ch_DatagramChannelImpl_send0 > >> > >> Smae here. > >> > >> --- > >> > >> src/java.base/windows/native/libnio/ch/DatagramDispatcher.c > >> src/java.base/windows/native/libnio/ch/SocketDispatcher.c > >> > >> > >> Same here? > >> > >> --- > >> > >> src/java.base/windows/native/libnio/ch/WindowsSelectorImpl.c > >> > >> + written = send(scoutFd, &byte, 1, 0); > >> + > >> + if (written > 0) { > >> + JVM_callFileWriteBytes(env, written); > >> + } > >> > >> ditto :) > >> > >> Thanks for your work! > >> > >> Cheers, Thomas > >> > >> > >> > >> > >> On Mon, Jan 14, 2019 at 4:59 PM Haug, Gunter > wrote: > >> > >>> Hi All, > >>> > >>> Could I please have a review and possibly some opinions on the > following > >>> enhancement to JFR and the JDK? > >>> > >>> At SAP we have a per thread IO statistic among our supportability > >>> enhancements which proved to be very helpful for our support > >>> engineers. It > >>> might be beneficial for JFR as well and would certainly help us to > drive > >>> adoption of OpenJDK. > >>> > >>> The basic idea is simple, we have added fields to the thread class > where > >>> the number of bytes read and written from/to file and network are > >>> counted > >>> in. The newly created JFR events are written periodically as for > example > >>> the ThreadAllocationStatistics event already is. > >>> > >>> In order to collect the data, we have added hooks to the JDK C coding > >>> calling back into the VM. > >>> > >>> I have opened a bug here: > >>> https://bugs.openjdk.java.net/browse/JDK-8216981 > >>> > >>> Here is a webrev: > >>> http://cr.openjdk.java.net/~ghaug/webrevs/8216981 > >>> > >>> There are no tests yet and the code be a bit nicer in places. We will > >>> work > >>> on this if/when this feature is deemed acceptable. > >>> > >>> Finally, we have an API in our SAP version of the JDK to access this > >>> data > >>> from a Java application. This is used by many SAP applications and I > >>> think > >>> we could add an MXBean in a second step, to provide similar > >>> functionality. > >>> > >>> Thanks in advance, > >>> Gunter > >>> > >>> > >>> > >>> > >>> > > > From david.holmes at oracle.com Thu Jan 17 07:36:56 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Jan 2019 17:36:56 +1000 Subject: [RFR]: Per thread IO statistics in JFR In-Reply-To: References: <131aa47d-d794-e3d7-ab64-fa5ff3b03952@oracle.com> Message-ID: <9598aead-7443-10a4-9824-4aa21c1cb101@oracle.com> On 17/01/2019 5:23 pm, Thomas St?fe wrote: > > > On Thu, Jan 17, 2019 at 1:23 AM David Holmes > wrote: > > On 17/01/2019 12:59 am, Alan Bateman wrote: > > > > Thanks for forwarding as this is a topic that will require a lot of > > discussion and agreement from several areas due to potential > impact on > > long term maintenance and the potential for some of these native > methods > > to go away. > > > > Gunter - can you summarize the approaches that you have explored? In > > particular, it would be useful to see a write-up of approaches that > > don't change the native methods to call JVM_* functions at every I/O > > call. > > Indeed! Under the adage "you shouldn't pay for what you don't use" this > seems an unacceptable penalty on I/O operations if you don't want to > gather the event info - and possibly excessive even if you do! The > dynamic instrumentation approach was adopted because static > instrumentation like this was not considered appropriate. > > > You noticed that all Gunther does is to increment stat counters in the > VM, he does not generate JFR events at all? > > Do you object against keeping these counters (which basically boils down > to Thread::current->stat_structure->counter++)? Or do you even object > against making upcalls into the jvm? Note that, if deemed necessary, we > could omit updating the counters unless JFR or our extended thread dumps > are activated (which are the consumers of the counters). It is the "call JVM_* functions at every I/O call" that I am concerned about! > In any case, I would have assumed the costs for upcall?+ counter update > to be insignificant compared to the IO calls. We should of course > measure that. It's going to depend on the actual I/O operation of course. > > If you generally object upcalls into the libjvm for > statistical/monitoring reasons, this would make matters on a number of > fronts more complicated. For instance, it was discussed extending NMT > coverage to the JDK - which is already in part reality at > Unsafe.AllocateMemory - and this would have to be done with upcalls too. And it would need to be examined in detail too. Cheers, David ----- > Kind Regards, Thomas > > > David > ----- > > > It would also be useful to understand how it compares to dynamic > > instrumentation today (once there are suitable java methods to > > instrument). Maybe someone working on JFR can comment on that too. > > > > -Alan > > > > On 16/01/2019 14:25, Thomas St?fe wrote: > >> Hi Gunter, > >> > >> (I remove svc but add corelibs and hs-runtime for the jdk/hs parts, > >> respectively. Hope this is not too spammy). > >> > >> This looks all very good. > >> > >> I am not a JFR reviewer (is there such a thing?) but only a JDK > reviewer, > >> so I am not sure if I am allowed to review the JFR parts. > >> > >> That said, here it goes: > >> > >> General remarks: > >> > >> A) we may reduce the number of sent events vastly by only > sending updates > >> for threads which actually did IO. I know that would require > expanding > >> the > >> ThreadStatisticalInfo to keep JFR-specific counters. But I think > the > >> memory > >> overhead of the increased size of ThreadStatisticalInfo would be > more > >> than > >> offset by the space saved for noop events. What to you think? > >> > >> (Side note, it would be nice to have generic support for this in > the JFR > >> layer. If the JFR layer could remember the last values for an > event and > >> omit sending it if nothing changed.) > >> > >> B) You could save a bit of work by folding multiple values into one > >> event. > >> Other events seem to do that too, eg. MetaspaceSummary. E.g: > instead of > >> having ThreadNetworkWriteStatistics and > ThreadNetworkReadStatistics, you > >> could have ThreadNetworkStatistics with "read" and "write" > fields, and > >> thus > >> combine the polling functions for those two. Maybe even combine > all four > >> values into a single "ThreadIOStatistics" event. > >> > >> Review: > >> > >> Hook functions: > >> > >> - This is bike shedding, but I would like something like > "JVM_On()" > >> more, sounding more "hookish", since the functions do not "xxx" but > >> inform > >> the hotspot of "xxx" having occurred > >> > >> - Also, I wonder whether it would make sense to make the len > input 64bit > >> (jlong instead of jint) in case we want to use them to > instrument 64bit > >> reads too > >> > >> - If you wanted to minimize the number of new JVM_.. hook > functions, you > >> could combine network and file io hooks into one: > >> > >> JVM_OnIORead(.. bool is_socket) > >> JVM_OnIOWrite(.. bool is_socket) > >> > >> or even JVM_OnIO(.., bool is_read, bool is_socket). > >> > >> This would also make the dispatching in > >> src/java.base/unix/native/libnio/ch/FileDispatcherImpl.c easier. > But this > >> is pure aesthetics, I leave it up to you. > >> > >> --- > >> > >> src/hotspot/share/jfr/metadata/metadata.xml > >> > >> All event definitions have one value, called and labeled > "Thread". If you > >> keep them separate, does this field name/label make sense? (I am > not > >> fluid > >> with JMC so I do not know where exactly this label text would > appear). > >> > >> --- > >> > >> src/hotspot/share/jfr/periodic/jfrPeriodic.cpp > >> > >> ?? GrowableArray written(initial_size); > >> ?? GrowableArray thread_ids(initial_size); > >> > >> You could probably save one GrowableArray and some append calls by > >> something like this: > >> > >> struct data { jlong num; trace_id tid; } > >> GrowableArray > >> > >> - > >> > >> Question, I assume you go thru the trouble of storing the values > >> temporarily since you do not want to call JfrEvent::commit > inside the > >> Threads_lock? > >> > >> --- > >> > >> src/hotspot/share/runtime/thread.cpp > >> > >> Nice addition to the extended thread dump. > >> > >> --- > >> > >> src/java.base/unix/native/libnio/ch/FileDispatcherImpl.c > >> > >> - There may be a number of unnecessary casts: > >> > >> e.g. Java_sun_nio_ch_FileDispatcherImpl_read0 > >> > >> JVM_callNetworkReadBytes(env, (jint) readBytes); > >> > >> readBytes is already jint. > >> > >> - > >> > >> You could reduce the code by factoring out that frequent if-else > >> statements: > >> > >> ?? 87???? if (readBytes > 0) { > >> ?? 88???????? if (socket) { > >> ?? 89???????????? JVM_callNetworkReadBytes(env, (jint) readBytes); > >> ?? 90???????? } else { > >> ?? 91???????????? JVM_callFileReadBytes(env, (jint)readBytes); > >> ?? 92???????? } > >> ?? 93???? } > >> > >> like this > >> > >> static void on_io_read(env, jint nread, jboolean socket) { > >> ??????????? if (socket) { > >> ??????????????? JVM_callNetworkReadBytes(env, nread); > >> ??????????? } else { > >> ??????????????? JVM_callFileReadBytes(env, nread); > >> ??????????? } > >> } > >> > >> you could even add the n>0 condition to the function. > >> > >> - > >> > >> Java_sun_nio_ch_FileDispatcherImpl_pwrite0: you truncate the > return value > >> of pread64 to 32bit on 64bit platforms. > >> > >> --- > >> > >> > src/java.base/windows/native/libnet/DualStackPlainDatagramSocketImpl.c > >> > >> Probably philosophical but I would leave peek out of the > condition. A > >> read > >> is a read. > >> > >> -- > >> > >> src/java.base/unix/native/libnet/SocketOutputStream.c > >> > >> You could move the call to JVM_callNetworkWriteBytes out of the > loop (you > >> did this in other places too). > >> > >> -- > >> > >> src/java.base/windows/native/libnio/ch/DatagramDispatcher.c > >> src/java.base/windows/native/libnio/ch/FileDispatcherImpl.c > >> > >> at various places: > >> > >> ?? 52???? DWORD read = 0; > >> > >> ?? 83???? if (read > 0) { > >> ?? 84?????? JVM_callNetworkReadBytes(env, read); > >> ?? 85???? } > >> > >> DWORD is unsigned, may overflow jint arg? Moot point if you make it > >> 64bit. > >> > >> ---- > >> > >> > src/java.base/windows/native/libnet/DualStackPlainDatagramSocketImpl.c > >> > >> Java_java_net_DualStackPlainDatagramSocketImpl_socketSend > >> > >> ? 462???? if (rv > 0) { > >> ? 463?????? JVM_callFileWriteBytes(env, rv); > >> ? 464???? } > >> > >> Should this be NetworkWriteBytes? > >> > >> --- > >> > >> src/java.base/windows/native/libnet/SocketOutputStream.c > >> > >> Same here. > >> > >> --- > >> > >> > src/java.base/windows/native/libnet/TwoStacksPlainDatagramSocketImpl.c > >> > >> > >> -??? if (sendto(fd, fullPacket, packetBufferLen, 0, addrp, > >> +??? if (ret = sendto(fd, fullPacket, packetBufferLen, 0, addrp, > >> ???????????????? addrlen) == SOCKET_ERROR) > >> ????? { > >> ????????? NET_ThrowCurrent(env, "Datagram send failed"); > >> ????? } > >> > >> +??? if (ret > 0) { > >> +????? JVM_callFileWriteBytes(env, ret); > >> +??? } > >> + > >> > >> Same here. > >> > >> --- > >> > >> > http://cr.openjdk.java.net/~ghaug/webrevs/8216981/src/java.base/windows/native/libnio/ch/DatagramChannelImpl.c.frames.html > > >> > >> > >> Java_sun_nio_ch_DatagramChannelImpl_send0 > >> > >> Smae here. > >> > >> --- > >> > >> src/java.base/windows/native/libnio/ch/DatagramDispatcher.c > >> src/java.base/windows/native/libnio/ch/SocketDispatcher.c > >> > >> > >> Same here? > >> > >> --- > >> > >> src/java.base/windows/native/libnio/ch/WindowsSelectorImpl.c > >> > >> +??? written = send(scoutFd, &byte, 1, 0); > >> + > >> +??? if (written > 0) { > >> +??????? JVM_callFileWriteBytes(env, written); > >> +??? } > >> > >> ditto :) > >> > >> Thanks for your work! > >> > >> Cheers, Thomas > >> > >> > >> > >> > >> On Mon, Jan 14, 2019 at 4:59 PM Haug, Gunter > > wrote: > >> > >>> Hi All, > >>> > >>> Could I please have a review and possibly some opinions on the > following > >>> enhancement to JFR and the JDK? > >>> > >>> At SAP we have a per thread IO statistic among our supportability > >>> enhancements which proved to be very helpful for our support > >>> engineers. It > >>> might be beneficial for JFR as well and would certainly help us > to drive > >>> adoption of OpenJDK. > >>> > >>> The basic idea is simple, we have added fields to the thread > class where > >>> the number of bytes read and written from/to file and network are > >>> counted > >>> in. The newly created JFR events are written periodically as > for example > >>> the ThreadAllocationStatistics event already is. > >>> > >>> In order to collect the data, we have added hooks to the JDK C > coding > >>> calling back into the VM. > >>> > >>> I have opened a bug here: > >>> https://bugs.openjdk.java.net/browse/JDK-8216981 > >>> > >>> Here is a webrev: > >>> http://cr.openjdk.java.net/~ghaug/webrevs/8216981 > >>> > >>> There are no tests yet and the code be a bit nicer in places. > We will > >>> work > >>> on this if/when this feature is deemed acceptable. > >>> > >>> Finally, we have an API in our SAP version of the JDK to access > this > >>> data > >>> from a Java application. This is used by many SAP applications > and I > >>> think > >>> we could add an MXBean in a second step, to provide similar > >>> functionality. > >>> > >>> Thanks in advance, > >>> Gunter > >>> > >>> > >>> > >>> > >>> > > > From Alan.Bateman at oracle.com Thu Jan 17 08:00:07 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 17 Jan 2019 08:00:07 +0000 Subject: [RFR]: Per thread IO statistics in JFR In-Reply-To: References: <131aa47d-d794-e3d7-ab64-fa5ff3b03952@oracle.com> Message-ID: On 17/01/2019 07:23, Thomas St?fe wrote: > : > > Do you object against keeping these counters (which basically boils > down to Thread::current->stat_structure->counter++)? Or do you even > object against making upcalls into the jvm? Note that, if deemed > necessary, we could omit updating the counters unless JFR or our > extended thread dumps are activated (which are the consumers of the > counters). > > In any case, I would have assumed the costs for upcall?+ counter > update to be insignificant compared to the IO calls. We should of > course measure that. > > If you generally object upcalls into the libjvm for > statistical/monitoring reasons, this would make matters on a number of > fronts more complicated. For instance, it was discussed extending NMT > coverage to the JDK - which is already in part reality at > Unsafe.AllocateMemory - and this would have to be done with upcalls too. > There are many issues here that will need write-up and discussion, maybe a JEP if discussions converge on a proposal to bring into the main line as this is a significant change with implications for many areas of the platform. It also potentially conflicts in direction with some of the other projects in progress (particularly with Loom trying to re-imagine threads, do you really want to collect I/O stats on a per thread basis in the future???). As regards the points to instrument then I think we have to assume that much of the native code that is targeted by the current webrev will go away or change significantly in the future. We've been on that path for some time, e.g. the zip area or the prototype to replace the SocketImpl used for classic networking that eliminates a lot of the native code touched in that area by the webrev. Once Panama is further along then I assume we will want to make use of it in the core libraries and at least initially replace the JNI methods that just wrap syscalls today, and longer term more significant refactoring. My point is that instrumenting native methods may not be the right approach, instead maybe we should be look at instrumenting the I/O paths at the java level as that will likely play better with the VM. There is some support for collecting I/O stats in JFR today and maybe someone working in that area can explain that a bit more and what the issues are. It's impossible to tell from the mail with the webrev what has been explored and not explored. It feels like early stages in a much large project that will need a write up of prototypes before a direction can be proposed. -Alan From erik.gahlin at oracle.com Thu Jan 17 12:05:19 2019 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Thu, 17 Jan 2019 13:05:19 +0100 Subject: [RFR]: Per thread IO statistics in JFR In-Reply-To: References: <131aa47d-d794-e3d7-ab64-fa5ff3b03952@oracle.com> Message-ID: <5C406F7F.5000409@oracle.com> On 2019-01-17 09:00, Alan Bateman wrote: > On 17/01/2019 07:23, Thomas St?fe wrote: >> : >> >> Do you object against keeping these counters (which basically boils >> down to Thread::current->stat_structure->counter++)? Or do you even >> object against making upcalls into the jvm? Note that, if deemed >> necessary, we could omit updating the counters unless JFR or our >> extended thread dumps are activated (which are the consumers of the >> counters). >> >> In any case, I would have assumed the costs for upcall + counter >> update to be insignificant compared to the IO calls. We should of >> course measure that. >> >> If you generally object upcalls into the libjvm for >> statistical/monitoring reasons, this would make matters on a number >> of fronts more complicated. For instance, it was discussed extending >> NMT coverage to the JDK - which is already in part reality at >> Unsafe.AllocateMemory - and this would have to be done with upcalls too. >> > There are many issues here that will need write-up and discussion, > maybe a JEP if discussions converge on a proposal to bring into the > main line as this is a significant change with implications for many > areas of the platform. It also potentially conflicts in direction with > some of the other projects in progress (particularly with Loom trying > to re-imagine threads, do you really want to collect I/O stats on a > per thread basis in the future???). > > As regards the points to instrument then I think we have to assume > that much of the native code that is targeted by the current webrev > will go away or change significantly in the future. We've been on that > path for some time, e.g. the zip area or the prototype to replace the > SocketImpl used for classic networking that eliminates a lot of the > native code touched in that area by the webrev. Once Panama is further > along then I assume we will want to make use of it in the core > libraries and at least initially replace the JNI methods that just > wrap syscalls today, and longer term more significant refactoring. My > point is that instrumenting native methods may not be the right > approach, instead maybe we should be look at instrumenting the I/O > paths at the java level as that will likely play better with the VM. > There is some support for collecting I/O stats in JFR today and maybe > someone working in that area can explain that a bit more and what the > issues are. > Today we have File Read, File Write, Socket Read, and Socket Write events. The hook points are added to the JDK using bytecode instrumentation. This happens when you start a JFR recording, so there is no overhead unless you use it. Erik > It's impossible to tell from the mail with the webrev what has been > explored and not explored. It feels like early stages in a much large > project that will need a write up of prototypes before a direction can > be proposed. > > -Alan From david.holmes at oracle.com Thu Jan 17 12:50:26 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Jan 2019 22:50:26 +1000 Subject: RFR: 8194860: Cleanup Semaphore timed-wait time calculations In-Reply-To: <11acad5f-f132-63d1-1476-6b8fc6118f52@oracle.com> References: <7557e8f2-5622-0317-972d-601b607d6b95@oracle.com> <11acad5f-f132-63d1-1476-6b8fc6118f52@oracle.com> Message-ID: <4ed63ae4-baa8-4911-3b8c-4e02339aaec0@oracle.com> Something has gone wrong with the OS X version - the VM won't run. Will take this up again next week. David ----- On 17/01/2019 5:01 pm, David Holmes wrote: > Take 2: webrev updated in place. > > For OSXSemaphore I simply changed the existing timedwait method to take > the single millis arg as used by the new PosixSemaphore so that calling > code is correct for both cases. I also deleted the unnecessary > currenttime() method. I chose not to implement the absolute timedwait > because the conversion to a relative wait as needed by the kernel > semaphore is non-trivial and as its unused it would be untested. > > David > > On 17/01/2019 2:58 pm, David Holmes wrote: >> Withdrawn temporarily. >> >> The OS X changes were still being tested and they don't work. For some >> reason we're using kernel semaphores on OS X and they seem to take a >> relative timeout directly. That explains why they had a different API >> but doesn't help with the fact that the calling code expects >> OSXSemaphore and PosixSemaphore to have the same API. >> >> David >> >> On 17/01/2019 8:06 am, David Holmes wrote: >>> bug: https://bugs.openjdk.java.net/browse/JDK-8194860 >>> webrev: http://cr.openjdk.java.net/~dholmes/8194860/webrev/ >>> >>> Details in the bug report, but there was duplication in functionality >>> with regards to timeout conversions/calculations, and the os_bsd.cpp >>> code was broken due to OSXSemaphore and PosixSemaphore having >>> different API's. >>> >>> Summary: >>> - expanded the API to take a relative timeout in millis as well as >>> the existing absolute timeout as a timespec: >>> >>> ?? // wait until the given absolute time is reached >>> ?? bool timedwait(struct timespec ts); >>> ?? // wait until the given relative time elapses >>> ?? bool timedwait(int64_t millis); >>> >>> The millis version simply converts to a timespec and calls the other >>> version e.g >>> >>> bool PosixSemaphore::timedwait(int64_t millis) { >>> ?? struct timespec ts; >>> ?? os::Posix::to_RTC_abstime(&ts, millis); >>> ?? return timedwait(ts); >>> } >>> >>> - added os::Posix::to_RTC_abstime to do the relative to absolute >>> conversion using the existing routines in os::Posix used for >>> PlatformEvent etc. >>> >>> - changed callsites to use new millis version >>> >>> - I had to rearrange the ifndef SOLARIS in os_posix.cpp to expose >>> previously hidden code to Solaris. It isn't all needed by Solaris but >>> I chose not to clutter things with too many ifdefs and only excluded >>> things that really shouldn't be done on Solaris. Also needed to call >>> os::Posix::init on Solaris. >>> >>> Testing (still in progress): >>> - mach 5 tiers 1 - 3 (Linux, Solaris, OS X, Windows) >>> - test/jdk/jdk/jfr (as suspend/resume is the user of the semaphore code) >>> >>> Thanks, >>> David From coleen.phillimore at oracle.com Thu Jan 17 13:04:42 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 17 Jan 2019 08:04:42 -0500 Subject: RFR: 8194860: Cleanup Semaphore timed-wait time calculations In-Reply-To: <7557e8f2-5622-0317-972d-601b607d6b95@oracle.com> References: <7557e8f2-5622-0317-972d-601b607d6b95@oracle.com> Message-ID: http://cr.openjdk.java.net/~dholmes/8194860/webrev/src/hotspot/os/posix/os_posix.cpp.frames.html For os_init2, I don't see why you have to sprinkle #ifndef SOLARIS. It's just logging, won't the logging be useful in the negative for solaris? Can these three statics default to false/NULL above?? Then you can save having to have this conditional as well: +#else + _use_clock_monotonic_condattr = false; +#endif // !SOLARIS Thank you for resolving the differences between to_abstime and solaris unpackTime, which was one of the causes of this mess left by the refactoring. Looks good, with this one suggestion to remove some #ifndef solaris above. Coleen On 1/16/19 5:06 PM, David Holmes wrote: > bug: https://bugs.openjdk.java.net/browse/JDK-8194860 > webrev: http://cr.openjdk.java.net/~dholmes/8194860/webrev/ > > Details in the bug report, but there was duplication in functionality > with regards to timeout conversions/calculations, and the os_bsd.cpp > code was broken due to OSXSemaphore and PosixSemaphore having > different API's. > > Summary: > - expanded the API to take a relative timeout in millis as well as the > existing absolute timeout as a timespec: > > ? // wait until the given absolute time is reached > ? bool timedwait(struct timespec ts); > ? // wait until the given relative time elapses > ? bool timedwait(int64_t millis); > > The millis version simply converts to a timespec and calls the other > version e.g > > bool PosixSemaphore::timedwait(int64_t millis) { > ? struct timespec ts; > ? os::Posix::to_RTC_abstime(&ts, millis); > ? return timedwait(ts); > } > > - added os::Posix::to_RTC_abstime to do the relative to absolute > conversion using the existing routines in os::Posix used for > PlatformEvent etc. > > - changed callsites to use new millis version > > - I had to rearrange the ifndef SOLARIS in os_posix.cpp to expose > previously hidden code to Solaris. It isn't all needed by Solaris but > I chose not to clutter things with too many ifdefs and only excluded > things that really shouldn't be done on Solaris. Also needed to call > os::Posix::init on Solaris. > > Testing (still in progress): > - mach 5 tiers 1 - 3 (Linux, Solaris, OS X, Windows) > - test/jdk/jdk/jfr (as suspend/resume is the user of the semaphore code) > > Thanks, > David From daniel.daugherty at oracle.com Thu Jan 17 14:33:11 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 17 Jan 2019 09:33:11 -0500 Subject: RFR (S): 8213397: Stack dump should show more clearly when a thread is blocked on a class initialization monitor In-Reply-To: <616fb6e0-0ff6-b397-5214-30da1db1d949@oracle.com> References: <90bcd939-2066-0a3b-743a-a2c4d55954d7@oracle.com> <5c44ba14-ba6d-b012-f824-6faa9f3ad28b@oracle.com> <7bad7b2b-f310-792f-59c0-710b1098f918@oracle.com> <9880a1a4-5041-8dcb-288c-10382c6acb09@oracle.com> <616fb6e0-0ff6-b397-5214-30da1db1d949@oracle.com> Message-ID: <500a0676-1e2c-37b0-d4f2-97c33dd0943b@oracle.com> On 1/16/19 9:28 PM, David Holmes wrote: > On 17/01/2019 6:57 am, coleen.phillimore at oracle.com wrote: >> On 1/16/19 11:52 AM, Daniel D. Daugherty wrote: >>> On 1/14/19 8:26 AM, David Holmes wrote: >>>> On 14/01/2019 11:21 pm, coleen.phillimore at oracle.com wrote: >>>>> >>>>> >>>>> On 1/14/19 8:13 AM, David Holmes wrote: >>>>>> Hi Coleen, >>>>>> >>>>>> On 14/01/2019 10:25 pm, coleen.phillimore at oracle.com wrote: >>>>>>> >>>>>>> This is a nice improvement. >>>>>> >>>>>> Thanks for taking a look. >>>>>> >>>>>>> http://cr.openjdk.java.net/~dholmes/8213397/webrev/src/hotspot/share/runtime/vframe.cpp.udiff.html >>>>>>> >>>>>>> >>>>>>> + // top-frame, so we should be waiting on a Class >>>>>>> initialization monitor. >>>>>>> + InstanceKlass* k = thread()->class_to_be_initialized(); >>>>>>> + if (k != NULL) { >>>>>>> + st->print_cr("\t- waiting on the Class initialization monitor >>>>>>> for %s", k->external_name()); >>>>>>> + } >>>>>>> + else { >>>>>>> + assert(false, "OBJECT_WAIT state is unexpected"); >>>>>>> + } >>>>>>> >>>>>>> >>>>>>> Should be } else { >>>>>>> >>>>>>> And I don't think this should be an assert.? There are a couple >>>>>>> of other places that we lock an object monitor from the VM, but >>>>>>> I don't think we wait in these places.? In any case, if we add a >>>>>>> wait, it would take a lot of testing and a long time to get to >>>>>>> this assert to find it needs to add another case here.? So if >>>>>>> you remove the 'else' completely and change the comment to "see >>>>>>> if we are waiting on a class initialization monitor" you don't >>>>>>> need to fix the {}. >>>>>> >>>>>> Initially I thought the "else" might be some JNI or JVM TI case, >>>>>> but that's not so as there's no direct API to do wait(), it just >>>>>> requires invoking the Object.wait method. So at the moment the >>>>>> implicit else is "unreachable" and I wanted to convey that. I >>>>>> chose the assert in case I was wrong, or in the unlikely event a >>>>>> new VM internal call to wait() was ever added and we happened to >>>>>> encounter it. Leaving it empty to me raises the question "how do >>>>>> we get here?". >>>>> >>>>> The thing is, that leaving an assert to find some future case is >>>>> only good if that code is going to execute frequently and we find >>>>> it in testing.? This is not a frequent path.?? Having the assert >>>>> might be hit much later down the road when we've forgotten this.? >>>>> It's not helpful. >>>> >>>> It may not be very helpful but it is more helpful than nothing. >>>> >>>> But I guess I can remove it. >>> >>> Just for the record, I would recommend keeping it. I find it helpful >>> to have assertions in places where the code has reached something >>> unexpected. Instead of: >>> >>> ? assert(false, "OBJECT_WAIT state is unexpected"); >>> >>> I would do it as: >>> >>> ? fatal("OBJECT_WAIT state is unexpected"); >>> >>> to catch it in any form of bits (product, debug, etc). >> >> No, this is even worse! > > I have to agree with Coleen here - at most an assert is warranted so > that during testing if we hit such an unexpected condition it is > brought to our attention. But if the unexpected condition hits in the > wild we do not want to crash the VM! Nothing bad happens if we find > the unexpected condition, we just won't report anything. Thanks for clarifying. > For the record it was pushed with no assert, as Coleen requested. I'm good with that. > > David > >> Do you really want some rarely reproduceable crash coming from a >> customer? Are you forgetting that I like chasing rare bugs? However, you have a good point about it coming from a customer. >> The assertion isn't even checking for some error in processing, it's >> for a helpful diagnostic. Hmmm... okay. I read it as the code isn't written to handle this condition implying that something bad would happen if we saw this state. Maybe I inferred too much... >> The only reason for guarantees is that something *very* bad will >> happen later. Right. Data corruption, lost data, deadlock. Yup. >> Anyway, this is somewhat of a minor point whether there should have >> been an assert or not. Agreed. Dan >> My recommendation was what I already wrote. >> thanks, >> Coleen >>> >>> As for tracking back a future occurrence to this review, I often >>> check to see what changeset added an assertion to see the context >>> in which the assertion was placed. >>> >>> The fix is already pushed so again this is just for the record. >>> >>> Dan >>> >>> >>> >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> >>>>> Thanks, >>>>> Coleen >>>>> >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> Thanks, >>>>>>> Coleen >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 1/14/19 1:01 AM, David Holmes wrote: >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8213397 >>>>>>>> webrev: http://cr.openjdk.java.net/~dholmes/8213397/webrev/ >>>>>>>> >>>>>>>> Please review this simple enhancement to improve the stack >>>>>>>> trace information when a thread is blocked doing a (logical) >>>>>>>> Object.wait on the monitor associated with Class static >>>>>>>> initialization. >>>>>>>> >>>>>>>> Details are in the bug report but basically we record, in a >>>>>>>> thread-local variable, the name of the class before the "wait" >>>>>>>> and clear it after, thus allowing the stack dump code to query >>>>>>>> it if it appears we may be in that situation. >>>>>>>> >>>>>>>> In InstanceKlass::initialize_impl I also refactored the code a >>>>>>>> tiny bit to make use of the JavaThread reference to the current >>>>>>>> thread. >>>>>>>> >>>>>>>> A new test using jstack was also added. >>>>>>>> >>>>>>>> Testing: >>>>>>>> ? - mach5 tiers 1 - 3 >>>>>>>> ? - the new test on Windows/Linux/OSX x86 and Solaris sparc, in >>>>>>>> regular and Xcomp mode >>>>>>>> ? - All jstack/stack-dump using tests I could see (linux x64): >>>>>>>> ??? - runtime/Thread >>>>>>>> ??? - serviceability/sa/ >>>>>>>> ??? - serviceability/tmtools/jstack/ >>>>>>>> ??? - vmTestbase/nsk/jvmti/scenarios/sampling/ >>>>>>>> ??? - vmTestbase/nsk/jvmti/MonitorWaited/ . >>>>>>>> ??? - vmTestbase/nsk/jvmti/GetOwnedMonitorInfo/ >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>> >>>>> >>> >> From claes.redestad at oracle.com Thu Jan 17 14:50:47 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 17 Jan 2019 15:50:47 +0100 Subject: RFR(trivial): 8217318: Unneeded handleization in InstanceKlass::restore_unshareable_info Message-ID: Hi, a trivial(?) cleanup/optimization to avoid unneeded methodHandles when loading methods from a CDS archive. Bug: https://bugs.openjdk.java.net/browse/JDK-8217318 Patch: diff -r 91ab128a65a3 src/hotspot/share/oops/instanceKlass.cpp --- a/src/hotspot/share/oops/instanceKlass.cpp Wed Jan 16 10:16:08 2019 +0100 +++ b/src/hotspot/share/oops/instanceKlass.cpp Thu Jan 17 15:29:03 2019 +0100 @@ -2375,8 +2375,7 @@ Array* methods = this->methods(); int num_methods = methods->length(); for (int index2 = 0; index2 < num_methods; ++index2) { - methodHandle m(THREAD, methods->at(index2)); - m->restore_unshareable_info(CHECK); + methods->at(index2)->restore_unshareable_info(CHECK); } if (JvmtiExport::has_redefined_a_class()) { // Reinitialize vtable because RedefineClasses may have changed some Testing: tier1-3 (completed) Thanks! /Claes From gunter.haug at sap.com Thu Jan 17 15:15:40 2019 From: gunter.haug at sap.com (Haug, Gunter) Date: Thu, 17 Jan 2019 15:15:40 +0000 Subject: [RFR]: Per thread IO statistics in JFR In-Reply-To: <5C406F7F.5000409@oracle.com> References: <131aa47d-d794-e3d7-ab64-fa5ff3b03952@oracle.com> <5C406F7F.5000409@oracle.com> Message-ID: <805AF7A7-C1F1-48E4-9831-4740A284C16A@sap.com> > Today we have File Read, File Write, Socket Read, and Socket Write > events. The hook points are added to the JDK using bytecode > instrumentation. This happens when you start a JFR recording, so there > is no overhead unless you use it. > > Erik However, in this context it's worth to note that the information provided by the events Erik describes is quite different from what we have proposed. The existing events are triggered only if the time the IO operation takes, exceeds a threshold (10ms/20ms for profile/default settings respectively). They are aimed for providing information on the time IO operations take and do not provide per thread IO statistics. What we are interested in is per thread information similar to the jdk.ThreadAllocationStatistics event. With respect to performance impact, I was not able to observe a degradation above the measurement noise level in real-world benchmarks. I will try to do measurements with synthetic benchmarks and report back ASAP. Gunter ?On 17.01.19, 13:07, "Erik Gahlin" wrote: On 2019-01-17 09:00, Alan Bateman wrote: > On 17/01/2019 07:23, Thomas St?fe wrote: >> : >> >> Do you object against keeping these counters (which basically boils >> down to Thread::current->stat_structure->counter++)? Or do you even >> object against making upcalls into the jvm? Note that, if deemed >> necessary, we could omit updating the counters unless JFR or our >> extended thread dumps are activated (which are the consumers of the >> counters). >> >> In any case, I would have assumed the costs for upcall + counter >> update to be insignificant compared to the IO calls. We should of >> course measure that. >> >> If you generally object upcalls into the libjvm for >> statistical/monitoring reasons, this would make matters on a number >> of fronts more complicated. For instance, it was discussed extending >> NMT coverage to the JDK - which is already in part reality at >> Unsafe.AllocateMemory - and this would have to be done with upcalls too. >> > There are many issues here that will need write-up and discussion, > maybe a JEP if discussions converge on a proposal to bring into the > main line as this is a significant change with implications for many > areas of the platform. It also potentially conflicts in direction with > some of the other projects in progress (particularly with Loom trying > to re-imagine threads, do you really want to collect I/O stats on a > per thread basis in the future???). > > As regards the points to instrument then I think we have to assume > that much of the native code that is targeted by the current webrev > will go away or change significantly in the future. We've been on that > path for some time, e.g. the zip area or the prototype to replace the > SocketImpl used for classic networking that eliminates a lot of the > native code touched in that area by the webrev. Once Panama is further > along then I assume we will want to make use of it in the core > libraries and at least initially replace the JNI methods that just > wrap syscalls today, and longer term more significant refactoring. My > point is that instrumenting native methods may not be the right > approach, instead maybe we should be look at instrumenting the I/O > paths at the java level as that will likely play better with the VM. > There is some support for collecting I/O stats in JFR today and maybe > someone working in that area can explain that a bit more and what the > issues are. > Today we have File Read, File Write, Socket Read, and Socket Write events. The hook points are added to the JDK using bytecode instrumentation. This happens when you start a JFR recording, so there is no overhead unless you use it. Erik > It's impossible to tell from the mail with the webrev what has been > explored and not explored. It feels like early stages in a much large > project that will need a write up of prototypes before a direction can > be proposed. > > -Alan From thomas.stuefe at gmail.com Thu Jan 17 15:40:17 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 17 Jan 2019 16:40:17 +0100 Subject: [RFR]: Per thread IO statistics in JFR In-Reply-To: References: <131aa47d-d794-e3d7-ab64-fa5ff3b03952@oracle.com> Message-ID: Hi Alan, On Thu, Jan 17, 2019 at 9:00 AM Alan Bateman wrote: > On 17/01/2019 07:23, Thomas St?fe wrote: > > : > > Do you object against keeping these counters (which basically boils down > to Thread::current->stat_structure->counter++)? Or do you even object > against making upcalls into the jvm? Note that, if deemed necessary, we > could omit updating the counters unless JFR or our extended thread dumps > are activated (which are the consumers of the counters). > > In any case, I would have assumed the costs for upcall + counter update to > be insignificant compared to the IO calls. We should of course measure that. > > If you generally object upcalls into the libjvm for statistical/monitoring > reasons, this would make matters on a number of fronts more complicated. > For instance, it was discussed extending NMT coverage to the JDK - which is > already in part reality at Unsafe.AllocateMemory - and this would have to > be done with upcalls too. > > There are many issues here that will need write-up and discussion, maybe a > JEP if discussions converge on a proposal to bring into the main line as > this is a significant change with implications for many areas of the > platform. It also potentially conflicts in direction with some of the other > projects in progress (particularly with Loom trying to re-imagine threads, > do you really want to collect I/O stats on a per thread basis in the > future???). > > I think we are aiming for something pragmatic which works right now, with traditional threads, since per-thread IO is a really interesting statistic in App server contexts. > As regards the points to instrument then I think we have to assume that > much of the native code that is targeted by the current webrev will go away > or change significantly in the future. We've been on that path for some > time, e.g. the zip area or the prototype to replace the SocketImpl used for > classic networking that eliminates a lot of the native code touched in that > area by the webrev. Once Panama is further along then I assume we will want > to make use of it in the core libraries and at least initially replace the > JNI methods that just wrap syscalls today, and longer term more significant > refactoring. My point is that instrumenting native methods may not be the > right approach, instead maybe we should be look at instrumenting the I/O > paths at the java level as that will likely play better with the VM. There > is some support for collecting I/O stats in JFR today and maybe someone > working in that area can explain that a bit more and what the issues are. > I understand your concerns, thank you for explaining. I have not followed Panama that closely. I had a closer look today and like it, it looks promising and does address a number of real pain points. Sorry for not being up to date. So, your long term goal is to get rid of all native JDK libraries, move all that - partly highly platform dependent - coding up to java and just do downcalls to naked, unadorned system APIs via something like Pinvoke? And your argument is that it makes not much sense to put a lot of work into the native JDK layer since it will vanish long term? Thanks, Thomas > It's impossible to tell from the mail with the webrev what has been > explored and not explored. It feels like early stages in a much large > project that will need a write up of prototypes before a direction can be > proposed. > > -Alan > From claes.redestad at oracle.com Thu Jan 17 17:12:54 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 17 Jan 2019 18:12:54 +0100 Subject: RFR: 8217325: Enable inlining of java_lang_Class::oop_size_raw Message-ID: <627b8d6a-cdc0-2bc1-c8e7-fcf11e998dff@oracle.com> Hi, InstanceMirrorKlass::oop_size could be helped slightly if java_lang_Class::oop_size_raw was made inlineable. This significantly speeds up one branch in oopDesc::size_given_klass (heavily used by G1, at least during startup/warmup) while not causing any increase in binary size (linux x64). Bug: https://bugs.openjdk.java.net/browse/JDK-8217325 Webrev: http://cr.openjdk.java.net/~redestad/8217325/open.00/ Testing: tier1-2 (complete) Thanks! /Claes From shade at redhat.com Thu Jan 17 17:23:38 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 17 Jan 2019 18:23:38 +0100 Subject: RFR: 8217325: Enable inlining of java_lang_Class::oop_size_raw In-Reply-To: <627b8d6a-cdc0-2bc1-c8e7-fcf11e998dff@oracle.com> References: <627b8d6a-cdc0-2bc1-c8e7-fcf11e998dff@oracle.com> Message-ID: On 1/17/19 6:12 PM, Claes Redestad wrote: > Hi, > > InstanceMirrorKlass::oop_size could be helped slightly if > java_lang_Class::oop_size_raw was made inlineable. > > This significantly speeds up one branch in oopDesc::size_given_klass > (heavily used by G1, at least during startup/warmup) while not causing > any increase in binary size (linux x64). > > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8217325 > Webrev: http://cr.openjdk.java.net/~redestad/8217325/open.00/ Looks good. I remember seeing the profiles for Shenandoah that walks the objects and uses oopDesc::size* heavily, and it was inlined in product builds. That said, inlining it manually does not hurt. -Aleksey From volker.simonis at gmail.com Thu Jan 17 17:31:21 2019 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 17 Jan 2019 18:31:21 +0100 Subject: [RFR]: Per thread IO statistics in JFR In-Reply-To: References: <131aa47d-d794-e3d7-ab64-fa5ff3b03952@oracle.com> Message-ID: On Thu, Jan 17, 2019 at 1:31 PM Alan Bateman wrote: > > On 17/01/2019 07:23, Thomas St?fe wrote: > > : > > > > Do you object against keeping these counters (which basically boils > > down to Thread::current->stat_structure->counter++)? Or do you even > > object against making upcalls into the jvm? Note that, if deemed > > necessary, we could omit updating the counters unless JFR or our > > extended thread dumps are activated (which are the consumers of the > > counters). > > > > In any case, I would have assumed the costs for upcall + counter > > update to be insignificant compared to the IO calls. We should of > > course measure that. > > > > If you generally object upcalls into the libjvm for > > statistical/monitoring reasons, this would make matters on a number of > > fronts more complicated. For instance, it was discussed extending NMT > > coverage to the JDK - which is already in part reality at > > Unsafe.AllocateMemory - and this would have to be done with upcalls too. > > > There are many issues here that will need write-up and discussion, maybe > a JEP if discussions converge on a proposal to bring into the main line > as this is a significant change with implications for many areas of the > platform. We could certainly create a new JEP for this feature, but in the end it is rather trivial. In fact it can be expressed in a single sentence: instrument all native IO functions to collect the number of read and written bytes. As stated before, the overhead is minimal (Gunter will provide some concrete benchmarks soon) and could even be dropped to ~zero if you really insist on this (e.g. by wrapping all calls by a switch which is based on a system property). But honestly speaking we don't think this is really necessary. I want to stress the fact that this is not a wacky idea Gunter came up with but a feature which we're using for almost 10 years in our SAP JVM. It is running in all our enterprise scenarios without ever having caused any problems. > It also potentially conflicts in direction with some of the > other projects in progress (particularly with Loom trying to re-imagine > threads, do you really want to collect I/O stats on a per thread basis > in the future???). > Who knows about the future, our trace is quite useful today :) You're right that this may change when Loom becomes available and I think we've faced similar problems when people started using ThreadPools more heavily. We've mitigated this with another SAP JVM specific feature (which we havn't contributed yet) that we've called "Thread Annotations". They could be set from user code and our profiler could then split the collected statistics based on these annotations even if they were all collected for the same native thread. I image we can come up with similar solutions for project Loom in the future, once it becomes available. > As regards the points to instrument then I think we have to assume that > much of the native code that is targeted by the current webrev will go > away or change significantly in the future. But that's actually nice! That will eventually shrink the code proposed by this change to a few places and make the costs of supporting it even smaller. And needless to say that SAP is committed to support and maintain this feature once it gets integrated. > We've been on that path for > some time, e.g. the zip area or the prototype to replace the SocketImpl > used for classic networking that eliminates a lot of the native code > touched in that area by the webrev. Once Panama is further along then I > assume we will want to make use of it in the core libraries and at least > initially replace the JNI methods that just wrap syscalls today, and > longer term more significant refactoring. Again, I think this will make our implementation simpler because we would have to instrument fewer places. > My point is that instrumenting > native methods may not be the right approach, instead maybe we should be > look at instrumenting the I/O paths at the java level as that will > likely play better with the VM. We gathered some experience with Java-level instrumentation during the last years (e.g. Dynatrace, Wiley, etc) and it has not always been positive :) The overhead is certainly higher compared to the native instrumentation at C-level. And it can influence especially JIT optimizations in an unpredictable way. Finally the Java instrumentation is version dependent and puts the burden on instrumenting the "right" places (end especially catching all the right places) on the developer / support engineer. You could of course upload this overhead into another, external project like JFR, but supporting that doesn't come for free either. > There is some support for collecting I/O > stats in JFR today and maybe someone working in that area can explain > that a bit more and what the issues are. > As far as I understand, the corresponding JFR events only sample the time spent in the instrumented calls while we do an exact IO statistics with regard to the bytes read and written. > It's impossible to tell from the mail with the webrev what has been > explored and not explored. It feels like early stages in a much large > project that will need a write up of prototypes before a direction can > be proposed. As I wrote before, this is a solution we're using successfully since many years. We're convinced that is is superior to Java-level instrumentation with regards to both, overhead as well as maintainability. > > -Alan From coleen.phillimore at oracle.com Thu Jan 17 19:24:33 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 17 Jan 2019 14:24:33 -0500 Subject: RFR: 8217325: Enable inlining of java_lang_Class::oop_size_raw In-Reply-To: References: <627b8d6a-cdc0-2bc1-c8e7-fcf11e998dff@oracle.com> Message-ID: <1ae9be2f-6abf-3342-861a-947d9606335a@oracle.com> +1 nice! Coleen On 1/17/19 12:23 PM, Aleksey Shipilev wrote: > On 1/17/19 6:12 PM, Claes Redestad wrote: >> Hi, >> >> InstanceMirrorKlass::oop_size could be helped slightly if >> java_lang_Class::oop_size_raw was made inlineable. >> >> This significantly speeds up one branch in oopDesc::size_given_klass >> (heavily used by G1, at least during startup/warmup) while not causing >> any increase in binary size (linux x64). >> >> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8217325 >> Webrev: http://cr.openjdk.java.net/~redestad/8217325/open.00/ > Looks good. > > I remember seeing the profiles for Shenandoah that walks the objects and uses oopDesc::size* > heavily, and it was inlined in product builds. That said, inlining it manually does not hurt. > > -Aleksey > From coleen.phillimore at oracle.com Thu Jan 17 19:26:17 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 17 Jan 2019 14:26:17 -0500 Subject: RFR(trivial): 8217318: Unneeded handleization in InstanceKlass::restore_unshareable_info In-Reply-To: References: Message-ID: <231f3502-de93-2afc-4c63-d4c3cc904ab1@oracle.com> This looks good. I'd suggest a comment why methodHandle isn't needed for the place where you removed it but that would look strange: methodHandle isn't needed here, even though it can safepoint, because this class can't be redefined because it's not added to the dictionary yet. Thanks, Coleen On 1/17/19 9:50 AM, Claes Redestad wrote: > Hi, > > a trivial(?) cleanup/optimization to avoid unneeded methodHandles when > loading methods from a CDS archive. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217318 > Patch: > > diff -r 91ab128a65a3 src/hotspot/share/oops/instanceKlass.cpp > --- a/src/hotspot/share/oops/instanceKlass.cpp??? Wed Jan 16 10:16:08 > 2019 +0100 > +++ b/src/hotspot/share/oops/instanceKlass.cpp??? Thu Jan 17 15:29:03 > 2019 +0100 > @@ -2375,8 +2375,7 @@ > ?? Array* methods = this->methods(); > ?? int num_methods = methods->length(); > ?? for (int index2 = 0; index2 < num_methods; ++index2) { > -??? methodHandle m(THREAD, methods->at(index2)); > -??? m->restore_unshareable_info(CHECK); > +??? methods->at(index2)->restore_unshareable_info(CHECK); > ?? } > ?? if (JvmtiExport::has_redefined_a_class()) { > ???? // Reinitialize vtable because RedefineClasses may have changed some > > Testing: tier1-3 (completed) > > Thanks! > > /Claes From david.holmes at oracle.com Thu Jan 17 22:07:13 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 18 Jan 2019 08:07:13 +1000 Subject: RFR (S) 8217337: [TESTBUG] TestThreadDumpClassInitMonitor.java fails with Unexpected thread info line Message-ID: <293bad5b-ba15-1c33-24ca-6749cc395218@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8217337 webrev: http://cr.openjdk.java.net/~dholmes/8217337/webrev/ Please review this simple adjustment to a test I recently added. In debug builds there are two extra lines in the stacktrace, so we have to skip these in a product build. Thanks, David From david.holmes at oracle.com Thu Jan 17 22:19:22 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 18 Jan 2019 08:19:22 +1000 Subject: RFR: 8194860: Cleanup Semaphore timed-wait time calculations In-Reply-To: References: <7557e8f2-5622-0317-972d-601b607d6b95@oracle.com> Message-ID: <6b3f3d2f-259f-72db-8e9a-7b24507711ee@oracle.com> Hi Coleen, Thanks for looking at this - though I still have to resolve my OS X issue. On 17/01/2019 11:04 pm, coleen.phillimore at oracle.com wrote: > http://cr.openjdk.java.net/~dholmes/8194860/webrev/src/hotspot/os/posix/os_posix.cpp.frames.html > > > For os_init2, I don't see why you have to sprinkle #ifndef SOLARIS. It's > just logging, won't the logging be useful in the negative for solaris? The problem is that regardless of whether the initialization works or fails on Solaris, those "attributes" won't get used on Solaris anyway, so the logging would be misleading/confusing. So I just elided it. > Can these three statics default to false/NULL above?? Then you can save > having to have this conditional as well: > > +#else > +? _use_clock_monotonic_condattr = false; > +#endif // !SOLARIS Yes I should be able to do that (famous last words!). > Thank you for resolving the differences between to_abstime and solaris > unpackTime, which was one of the causes of this mess left by the > refactoring. There's still a lot of mess in the Solaris code. Thanks again, David > Looks good, with this one suggestion to remove some #ifndef solaris above. > Coleen > > > > On 1/16/19 5:06 PM, David Holmes wrote: >> bug: https://bugs.openjdk.java.net/browse/JDK-8194860 >> webrev: http://cr.openjdk.java.net/~dholmes/8194860/webrev/ >> >> Details in the bug report, but there was duplication in functionality >> with regards to timeout conversions/calculations, and the os_bsd.cpp >> code was broken due to OSXSemaphore and PosixSemaphore having >> different API's. >> >> Summary: >> - expanded the API to take a relative timeout in millis as well as the >> existing absolute timeout as a timespec: >> >> ? // wait until the given absolute time is reached >> ? bool timedwait(struct timespec ts); >> ? // wait until the given relative time elapses >> ? bool timedwait(int64_t millis); >> >> The millis version simply converts to a timespec and calls the other >> version e.g >> >> bool PosixSemaphore::timedwait(int64_t millis) { >> ? struct timespec ts; >> ? os::Posix::to_RTC_abstime(&ts, millis); >> ? return timedwait(ts); >> } >> >> - added os::Posix::to_RTC_abstime to do the relative to absolute >> conversion using the existing routines in os::Posix used for >> PlatformEvent etc. >> >> - changed callsites to use new millis version >> >> - I had to rearrange the ifndef SOLARIS in os_posix.cpp to expose >> previously hidden code to Solaris. It isn't all needed by Solaris but >> I chose not to clutter things with too many ifdefs and only excluded >> things that really shouldn't be done on Solaris. Also needed to call >> os::Posix::init on Solaris. >> >> Testing (still in progress): >> - mach 5 tiers 1 - 3 (Linux, Solaris, OS X, Windows) >> - test/jdk/jdk/jfr (as suspend/resume is the user of the semaphore code) >> >> Thanks, >> David > From claes.redestad at oracle.com Thu Jan 17 22:59:50 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 17 Jan 2019 23:59:50 +0100 Subject: RFR: 8217325: Enable inlining of java_lang_Class::oop_size_raw In-Reply-To: <1ae9be2f-6abf-3342-861a-947d9606335a@oracle.com> References: <627b8d6a-cdc0-2bc1-c8e7-fcf11e998dff@oracle.com> <1ae9be2f-6abf-3342-861a-947d9606335a@oracle.com> Message-ID: <2b772bac-3874-b5f0-c604-3957d052c462@oracle.com> Aleksey, Coleen, thanks for reviewing! On 2019-01-17 20:24, coleen.phillimore at oracle.com wrote: > +1 nice! > Coleen > > On 1/17/19 12:23 PM, Aleksey Shipilev wrote: >> On 1/17/19 6:12 PM, Claes Redestad wrote: >>> Hi, >>> >>> InstanceMirrorKlass::oop_size could be helped slightly if >>> java_lang_Class::oop_size_raw was made inlineable. >>> >>> This significantly speeds up one branch in oopDesc::size_given_klass >>> (heavily used by G1, at least during startup/warmup) while not causing >>> any increase in binary size (linux x64). >>> >>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8217325 >>> Webrev: http://cr.openjdk.java.net/~redestad/8217325/open.00/ >> Looks good. >> >> I remember seeing the profiles for Shenandoah that walks the objects >> and uses oopDesc::size* >> heavily, and it was inlined in product builds. That said, inlining it >> manually does not hurt. This patch improves the inlining in the slow path taken from oopDesc::size_given_klass when the klass is an InstanceMirrorKlass. This is slow since it has to call the virtual Klass::oop_size method, which can't be inlined, but can still be beneficial if the GC has to deal with a lot of InstanceMirrorKlass oops. The happy case where the oop is a regular object or even an array is dealt with without taking a virtual call in oopDesc::size_given_klass. Something to take a closer look at is that this method - despite being inlineable - doesn't seem to be inlined into oopDesc::size on linux x64 using the gcc version we're building with (product builds).? This seems unfortunate.. Thanks! /Claes >> >> -Aleksey >> > From kishor.kharbas at intel.com Fri Jan 18 02:42:41 2019 From: kishor.kharbas at intel.com (Kharbas, Kishor) Date: Fri, 18 Jan 2019 02:42:41 +0000 Subject: RFR(trivial): 8213695: gc/TestAllocateHeapAtMultiple.java is slow in some configs Message-ID: Greetings, I ran this test multiple times on Linux & Windows and the tests complete in less than a second. However, I do not have a sparc system to test (if I am correct, earlier discussion pointed that timeout issue is seen on sparc). My guess of what is happening is - For testing purposes we use the file system of the test directory, instead of a dax filesystem for nv-dimm. With the AllocateHeapAt flag set, heap memory is mapped to a temporary file in the test directory. Depending on the test environment (filesystem, memory, disk, etc), heap memory access might be quite slower. So I think we should decrease the heap size of the tests. The 5th & 6th subtests can be changed to use 32M instead of 4G. The 4th subtest can be removed. Here is the patch with the changes - http://cr.openjdk.java.net/~kkharbas/8213695/webrev.00/ Hopefully someone can test whether this change makes the run time deterministic. Thanks, Kishor From claes.redestad at oracle.com Fri Jan 18 07:16:27 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 18 Jan 2019 08:16:27 +0100 Subject: RFR(trivial): 8217318: Unneeded handleization in InstanceKlass::restore_unshareable_info In-Reply-To: <231f3502-de93-2afc-4c63-d4c3cc904ab1@oracle.com> References: <231f3502-de93-2afc-4c63-d4c3cc904ab1@oracle.com> Message-ID: <1d067eda-a7c1-c0e9-9a2f-7031fd4d4cfa@oracle.com> On 2019-01-17 20:26, coleen.phillimore at oracle.com wrote: > This looks good. Thanks! > I'd suggest a comment why methodHandle isn't needed for the place > where you removed it but that would look strange: > methodHandle isn't needed here, even though it can safepoint, because > this class can't be redefined because it's not added to the dictionary > yet. +??? // No need for a methodHandle here since methods not yet added +??? // to SystemDictionary can't be redefined. ? /Claes > > Thanks, > Coleen > > On 1/17/19 9:50 AM, Claes Redestad wrote: >> Hi, >> >> a trivial(?) cleanup/optimization to avoid unneeded methodHandles when >> loading methods from a CDS archive. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217318 >> Patch: >> >> diff -r 91ab128a65a3 src/hotspot/share/oops/instanceKlass.cpp >> --- a/src/hotspot/share/oops/instanceKlass.cpp??? Wed Jan 16 10:16:08 >> 2019 +0100 >> +++ b/src/hotspot/share/oops/instanceKlass.cpp??? Thu Jan 17 15:29:03 >> 2019 +0100 >> @@ -2375,8 +2375,7 @@ >> ?? Array* methods = this->methods(); >> ?? int num_methods = methods->length(); >> ?? for (int index2 = 0; index2 < num_methods; ++index2) { >> -??? methodHandle m(THREAD, methods->at(index2)); >> -??? m->restore_unshareable_info(CHECK); >> +??? methods->at(index2)->restore_unshareable_info(CHECK); >> ?? } >> ?? if (JvmtiExport::has_redefined_a_class()) { >> ???? // Reinitialize vtable because RedefineClasses may have changed >> some >> >> Testing: tier1-3 (completed) >> >> Thanks! >> >> /Claes > From coleen.phillimore at oracle.com Fri Jan 18 12:56:57 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 18 Jan 2019 07:56:57 -0500 Subject: RFR: 8194860: Cleanup Semaphore timed-wait time calculations In-Reply-To: <6b3f3d2f-259f-72db-8e9a-7b24507711ee@oracle.com> References: <7557e8f2-5622-0317-972d-601b607d6b95@oracle.com> <6b3f3d2f-259f-72db-8e9a-7b24507711ee@oracle.com> Message-ID: On 1/17/19 5:19 PM, David Holmes wrote: > Hi Coleen, > > Thanks for looking at this - though I still have to resolve my OS X > issue. > > On 17/01/2019 11:04 pm, coleen.phillimore at oracle.com wrote: >> http://cr.openjdk.java.net/~dholmes/8194860/webrev/src/hotspot/os/posix/os_posix.cpp.frames.html >> >> >> For os_init2, I don't see why you have to sprinkle #ifndef SOLARIS. >> It's just logging, won't the logging be useful in the negative for >> solaris? > > The problem is that regardless of whether the initialization works or > fails on Solaris, those "attributes" won't get used on Solaris anyway, > so the logging would be misleading/confusing. So I just elided it. > >> Can these three statics default to false/NULL above?? Then you can >> save having to have this conditional as well: >> >> +#else >> +? _use_clock_monotonic_condattr = false; >> +#endif // !SOLARIS > > Yes I should be able to do that (famous last words!). > >> Thank you for resolving the differences between to_abstime and >> solaris unpackTime, which was one of the causes of this mess left by >> the refactoring. > > There's still a lot of mess in the Solaris code. One mess down, many to go ... Thanks for fixing this. Coleen > > Thanks again, > David > >> Looks good, with this one suggestion to remove some #ifndef solaris >> above. >> Coleen >> >> >> >> On 1/16/19 5:06 PM, David Holmes wrote: >>> bug: https://bugs.openjdk.java.net/browse/JDK-8194860 >>> webrev: http://cr.openjdk.java.net/~dholmes/8194860/webrev/ >>> >>> Details in the bug report, but there was duplication in >>> functionality with regards to timeout conversions/calculations, and >>> the os_bsd.cpp code was broken due to OSXSemaphore and >>> PosixSemaphore having different API's. >>> >>> Summary: >>> - expanded the API to take a relative timeout in millis as well as >>> the existing absolute timeout as a timespec: >>> >>> ? // wait until the given absolute time is reached >>> ? bool timedwait(struct timespec ts); >>> ? // wait until the given relative time elapses >>> ? bool timedwait(int64_t millis); >>> >>> The millis version simply converts to a timespec and calls the other >>> version e.g >>> >>> bool PosixSemaphore::timedwait(int64_t millis) { >>> ? struct timespec ts; >>> ? os::Posix::to_RTC_abstime(&ts, millis); >>> ? return timedwait(ts); >>> } >>> >>> - added os::Posix::to_RTC_abstime to do the relative to absolute >>> conversion using the existing routines in os::Posix used for >>> PlatformEvent etc. >>> >>> - changed callsites to use new millis version >>> >>> - I had to rearrange the ifndef SOLARIS in os_posix.cpp to expose >>> previously hidden code to Solaris. It isn't all needed by Solaris >>> but I chose not to clutter things with too many ifdefs and only >>> excluded things that really shouldn't be done on Solaris. Also >>> needed to call os::Posix::init on Solaris. >>> >>> Testing (still in progress): >>> - mach 5 tiers 1 - 3 (Linux, Solaris, OS X, Windows) >>> - test/jdk/jdk/jfr (as suspend/resume is the user of the semaphore >>> code) >>> >>> Thanks, >>> David >> From christoph.langer at sap.com Fri Jan 18 14:08:23 2019 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 18 Jan 2019 14:08:23 +0000 Subject: RFR (S) 8217337: [TESTBUG] TestThreadDumpClassInitMonitor.java fails with Unexpected thread info line In-Reply-To: <293bad5b-ba15-1c33-24ca-6749cc395218@oracle.com> References: <293bad5b-ba15-1c33-24ca-6749cc395218@oracle.com> Message-ID: Hi David, looks good. Thanks for fixing it. We ran into it in our builds already. Best regards Christoph > -----Original Message----- > From: hotspot-runtime-dev bounces at openjdk.java.net> On Behalf Of David Holmes > Sent: Donnerstag, 17. Januar 2019 23:07 > To: hotspot-runtime-dev at openjdk.java.net > Subject: RFR (S) 8217337: [TESTBUG] TestThreadDumpClassInitMonitor.java > fails with Unexpected thread info line > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217337 > webrev: http://cr.openjdk.java.net/~dholmes/8217337/webrev/ > > Please review this simple adjustment to a test I recently added. In > debug builds there are two extra lines in the stacktrace, so we have to > skip these in a product build. > > Thanks, > David From coleen.phillimore at oracle.com Fri Jan 18 15:10:50 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 18 Jan 2019 10:10:50 -0500 Subject: RFR(trivial): 8217318: Unneeded handleization in InstanceKlass::restore_unshareable_info In-Reply-To: <1d067eda-a7c1-c0e9-9a2f-7031fd4d4cfa@oracle.com> References: <231f3502-de93-2afc-4c63-d4c3cc904ab1@oracle.com> <1d067eda-a7c1-c0e9-9a2f-7031fd4d4cfa@oracle.com> Message-ID: <440db29b-90f3-6276-78ba-4b55a16caf4c@oracle.com> On 1/18/19 2:16 AM, Claes Redestad wrote: > On 2019-01-17 20:26, coleen.phillimore at oracle.com wrote: >> This looks good. > > Thanks! > >> I'd suggest a comment why methodHandle isn't needed for the place >> where you removed it but that would look strange: >> methodHandle isn't needed here, even though it can safepoint, because >> this class can't be redefined because it's not added to the >> dictionary yet. > > +??? // No need for a methodHandle here since methods not yet added > +??? // to SystemDictionary can't be redefined. > I think the comment might cause more confusion than it helps, since it's describing code not there.? Can you add this or similar in the Summary: when you check in? Thanks, Coleen > ? > > /Claes >> >> Thanks, >> Coleen >> >> On 1/17/19 9:50 AM, Claes Redestad wrote: >>> Hi, >>> >>> a trivial(?) cleanup/optimization to avoid unneeded methodHandles when >>> loading methods from a CDS archive. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217318 >>> Patch: >>> >>> diff -r 91ab128a65a3 src/hotspot/share/oops/instanceKlass.cpp >>> --- a/src/hotspot/share/oops/instanceKlass.cpp??? Wed Jan 16 >>> 10:16:08 2019 +0100 >>> +++ b/src/hotspot/share/oops/instanceKlass.cpp??? Thu Jan 17 >>> 15:29:03 2019 +0100 >>> @@ -2375,8 +2375,7 @@ >>> ?? Array* methods = this->methods(); >>> ?? int num_methods = methods->length(); >>> ?? for (int index2 = 0; index2 < num_methods; ++index2) { >>> -??? methodHandle m(THREAD, methods->at(index2)); >>> -??? m->restore_unshareable_info(CHECK); >>> + methods->at(index2)->restore_unshareable_info(CHECK); >>> ?? } >>> ?? if (JvmtiExport::has_redefined_a_class()) { >>> ???? // Reinitialize vtable because RedefineClasses may have changed >>> some >>> >>> Testing: tier1-3 (completed) >>> >>> Thanks! >>> >>> /Claes >> > From claes.redestad at oracle.com Fri Jan 18 15:18:32 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 18 Jan 2019 16:18:32 +0100 Subject: RFR(trivial): 8217318: Unneeded handleization in InstanceKlass::restore_unshareable_info In-Reply-To: <440db29b-90f3-6276-78ba-4b55a16caf4c@oracle.com> References: <231f3502-de93-2afc-4c63-d4c3cc904ab1@oracle.com> <1d067eda-a7c1-c0e9-9a2f-7031fd4d4cfa@oracle.com> <440db29b-90f3-6276-78ba-4b55a16caf4c@oracle.com> Message-ID: <599fe48c-0fc4-7c5f-94a1-736c89698d1d@oracle.com> On 2019-01-18 16:10, coleen.phillimore at oracle.com wrote: > > On 1/18/19 2:16 AM, Claes Redestad wrote: >> +??? // No need for a methodHandle here since methods not yet added >> +??? // to SystemDictionary can't be redefined. >> > > I think the comment might cause more confusion than it helps, since it's > describing code not there.? Can you add this or similar in the Summary: > when you check in? Deal! /Claes From mikhailo.seledtsov at oracle.com Fri Jan 18 18:06:56 2019 From: mikhailo.seledtsov at oracle.com (mikhailo.seledtsov at oracle.com) Date: Fri, 18 Jan 2019 10:06:56 -0800 Subject: RFR(T): [13]: 8217391: [TESTBUG] problem list JFR TestShutdownEvent Message-ID: <408426c1-1235-e90c-3308-716b64e38de6@oracle.com> Please review this trivial change that places the JFR TestShutdownEvent on a problem list. Even though this test ran successfully in pre-integration testing 40 times, on multiple platforms on the automated test system, it turned out that it fails in specific way: ? - in Oracle CI ? - at SAP Problem listing this test for now, while working on the solution. ??? JBS: https://bugs.openjdk.java.net/browse/JDK-8217391 ??? Diff: ??????? diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt ??????? --- a/test/jdk/ProblemList.txt ??????? +++ b/test/jdk/ProblemList.txt ??????? @@ -878,3 +878,4 @@ ??????? # jdk_jfr jdk/jfr/event/io/TestInstrumentation.java 8202142??? generic-all +jdk/jfr/event/runtime/TestShutdownEvent.java 8217345??? generic-all Thank you, Misha From lois.foltan at oracle.com Fri Jan 18 18:23:17 2019 From: lois.foltan at oracle.com (Lois Foltan) Date: Fri, 18 Jan 2019 13:23:17 -0500 Subject: RFR(T): [13]: 8217391: [TESTBUG] problem list JFR TestShutdownEvent In-Reply-To: <408426c1-1235-e90c-3308-716b64e38de6@oracle.com> References: <408426c1-1235-e90c-3308-716b64e38de6@oracle.com> Message-ID: <1fc407f2-fa37-2780-ea8f-62440a8fc7dd@oracle.com> Looks good & trivial. Lois On 1/18/2019 1:06 PM, mikhailo.seledtsov at oracle.com wrote: > Please review this trivial change that places the JFR > TestShutdownEvent on a problem list. > Even though this test ran successfully in pre-integration testing 40 > times, on multiple platforms on > the automated test system, it turned out that it fails in specific way: > ? - in Oracle CI > ? - at SAP > > Problem listing this test for now, while working on the solution. > > ??? JBS: https://bugs.openjdk.java.net/browse/JDK-8217391 > ??? Diff: > ??????? diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt > ??????? --- a/test/jdk/ProblemList.txt > ??????? +++ b/test/jdk/ProblemList.txt > ??????? @@ -878,3 +878,4 @@ > ??????? # jdk_jfr > > jdk/jfr/event/io/TestInstrumentation.java 8202142??? generic-all > +jdk/jfr/event/runtime/TestShutdownEvent.java 8217345 generic-all > > > Thank you, > Misha > From mikhailo.seledtsov at oracle.com Fri Jan 18 18:37:36 2019 From: mikhailo.seledtsov at oracle.com (mikhailo.seledtsov at oracle.com) Date: Fri, 18 Jan 2019 10:37:36 -0800 Subject: RFR(T): [13]: 8217391: [TESTBUG] problem list JFR TestShutdownEvent In-Reply-To: <1fc407f2-fa37-2780-ea8f-62440a8fc7dd@oracle.com> References: <408426c1-1235-e90c-3308-716b64e38de6@oracle.com> <1fc407f2-fa37-2780-ea8f-62440a8fc7dd@oracle.com> Message-ID: <6a389dd7-14ee-c8a7-ccee-0a8d23560475@oracle.com> Thank you Lois, Misha On 1/18/19 10:23 AM, Lois Foltan wrote: > Looks good & trivial. > Lois > > On 1/18/2019 1:06 PM, mikhailo.seledtsov at oracle.com wrote: >> Please review this trivial change that places the JFR >> TestShutdownEvent on a problem list. >> Even though this test ran successfully in pre-integration testing 40 >> times, on multiple platforms on >> the automated test system, it turned out that it fails in specific way: >> ? - in Oracle CI >> ? - at SAP >> >> Problem listing this test for now, while working on the solution. >> >> ??? JBS: https://bugs.openjdk.java.net/browse/JDK-8217391 >> ??? Diff: >> ??????? diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt >> ??????? --- a/test/jdk/ProblemList.txt >> ??????? +++ b/test/jdk/ProblemList.txt >> ??????? @@ -878,3 +878,4 @@ >> ??????? # jdk_jfr >> >> jdk/jfr/event/io/TestInstrumentation.java 8202142??? generic-all >> +jdk/jfr/event/runtime/TestShutdownEvent.java 8217345 generic-all >> >> >> Thank you, >> Misha >> > From david.holmes at oracle.com Fri Jan 18 22:32:24 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 19 Jan 2019 08:32:24 +1000 Subject: RFR (S) 8217337: [TESTBUG] TestThreadDumpClassInitMonitor.java fails with Unexpected thread info line In-Reply-To: References: <293bad5b-ba15-1c33-24ca-6749cc395218@oracle.com> Message-ID: Thanks for the review Christoph! Unfortunately we do limited hotspot testing product mode in the early tiers :( Can I get a second review please. Thanks, David On 19/01/2019 12:08 am, Langer, Christoph wrote: > Hi David, > > looks good. Thanks for fixing it. We ran into it in our builds already. > > Best regards > Christoph > >> -----Original Message----- >> From: hotspot-runtime-dev > bounces at openjdk.java.net> On Behalf Of David Holmes >> Sent: Donnerstag, 17. Januar 2019 23:07 >> To: hotspot-runtime-dev at openjdk.java.net >> Subject: RFR (S) 8217337: [TESTBUG] TestThreadDumpClassInitMonitor.java >> fails with Unexpected thread info line >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217337 >> webrev: http://cr.openjdk.java.net/~dholmes/8217337/webrev/ >> >> Please review this simple adjustment to a test I recently added. In >> debug builds there are two extra lines in the stacktrace, so we have to >> skip these in a product build. >> >> Thanks, >> David From igor.ignatyev at oracle.com Fri Jan 18 22:36:37 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 18 Jan 2019 14:36:37 -0800 Subject: RFR (S) 8217337: [TESTBUG] TestThreadDumpClassInitMonitor.java fails with Unexpected thread info line In-Reply-To: References: <293bad5b-ba15-1c33-24ca-6749cc395218@oracle.com> Message-ID: Hi David, looks good. -- Igor > On Jan 18, 2019, at 2:32 PM, David Holmes wrote: > > Thanks for the review Christoph! Unfortunately we do limited hotspot testing product mode in the early tiers :( > > Can I get a second review please. > > Thanks, > David > > On 19/01/2019 12:08 am, Langer, Christoph wrote: >> Hi David, >> looks good. Thanks for fixing it. We ran into it in our builds already. >> Best regards >> Christoph >>> -----Original Message----- >>> From: hotspot-runtime-dev >> bounces at openjdk.java.net> On Behalf Of David Holmes >>> Sent: Donnerstag, 17. Januar 2019 23:07 >>> To: hotspot-runtime-dev at openjdk.java.net >>> Subject: RFR (S) 8217337: [TESTBUG] TestThreadDumpClassInitMonitor.java >>> fails with Unexpected thread info line >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217337 >>> webrev: http://cr.openjdk.java.net/~dholmes/8217337/webrev/ >>> >>> Please review this simple adjustment to a test I recently added. In >>> debug builds there are two extra lines in the stacktrace, so we have to >>> skip these in a product build. >>> >>> Thanks, >>> David From david.holmes at oracle.com Fri Jan 18 23:18:21 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 19 Jan 2019 09:18:21 +1000 Subject: RFR (S) 8217337: [TESTBUG] TestThreadDumpClassInitMonitor.java fails with Unexpected thread info line In-Reply-To: References: <293bad5b-ba15-1c33-24ca-6749cc395218@oracle.com> Message-ID: <203d8f5e-a8c5-0fb6-ce44-3712eb510e2f@oracle.com> Thanks Igor! David On 19/01/2019 8:36 am, Igor Ignatyev wrote: > Hi David, > > looks good. > > -- Igor > >> On Jan 18, 2019, at 2:32 PM, David Holmes wrote: >> >> Thanks for the review Christoph! Unfortunately we do limited hotspot testing product mode in the early tiers :( >> >> Can I get a second review please. >> >> Thanks, >> David >> >> On 19/01/2019 12:08 am, Langer, Christoph wrote: >>> Hi David, >>> looks good. Thanks for fixing it. We ran into it in our builds already. >>> Best regards >>> Christoph >>>> -----Original Message----- >>>> From: hotspot-runtime-dev >>> bounces at openjdk.java.net> On Behalf Of David Holmes >>>> Sent: Donnerstag, 17. Januar 2019 23:07 >>>> To: hotspot-runtime-dev at openjdk.java.net >>>> Subject: RFR (S) 8217337: [TESTBUG] TestThreadDumpClassInitMonitor.java >>>> fails with Unexpected thread info line >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8217337 >>>> webrev: http://cr.openjdk.java.net/~dholmes/8217337/webrev/ >>>> >>>> Please review this simple adjustment to a test I recently added. In >>>> debug builds there are two extra lines in the stacktrace, so we have to >>>> skip these in a product build. >>>> >>>> Thanks, >>>> David > From sangheon.kim at oracle.com Sat Jan 19 15:17:18 2019 From: sangheon.kim at oracle.com (sangheon.kim at oracle.com) Date: Sat, 19 Jan 2019 07:17:18 -0800 Subject: RFR(trivial): 8213695: gc/TestAllocateHeapAtMultiple.java is slow in some configs In-Reply-To: References: Message-ID: <23c18091-d58a-c260-dd5d-8ff8fa2403fb@oracle.com> Hi Kishor, Sending to 'hotspot-gc-dev' as well. On 1/17/19 6:42 PM, Kharbas, Kishor wrote: > > Greetings, > > I ran this test multiple times on Linux & Windows and the tests > complete in less than a second. However, I do not have a sparc system > to test (if I am correct, earlier discussion pointed that timeout > issue is seen on sparc). > > My guess of what is happening is ? For testing purposes we use the > file system of the test directory, instead of a dax filesystem for > nv-dimm. With the AllocateHeapAt flag set, heap memory is mapped to a > temporary file in the test directory. Depending on the test > environment (filesystem, memory, disk, etc), heap memory access might > be quite slower. > > So I think we should decrease the heap size of the tests. The 5th & > 6th subtests can be changed to use 32M instead of 4G. The 4^th subtest > can be removed. > > Here is the patch with the changes - > http://cr.openjdk.java.net/~kkharbas/8213695/webrev.00/ > > Looks good to me. And I can sponsor this patch, but we need a review from a (R)eviewer. FYI, I tested the patch on sparc machines(same kind of machines which reported the problem) for 40 times and its run time was mostly less than 3 seconds. Thanks, Sangheon > Hopefully someone can test whether this change makes the run time > deterministic. > > Thanks, > > Kishor > From kim.barrett at oracle.com Sat Jan 19 23:37:58 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Sat, 19 Jan 2019 18:37:58 -0500 Subject: RFR(trivial): 8213695: gc/TestAllocateHeapAtMultiple.java is slow in some configs In-Reply-To: <23c18091-d58a-c260-dd5d-8ff8fa2403fb@oracle.com> References: <23c18091-d58a-c260-dd5d-8ff8fa2403fb@oracle.com> Message-ID: <6A099E86-33C6-4C94-8228-6F962D3715DF@oracle.com> > On Jan 19, 2019, at 10:17 AM, sangheon.kim at oracle.com wrote: > > Hi Kishor, > > Sending to 'hotspot-gc-dev' as well. > > On 1/17/19 6:42 PM, Kharbas, Kishor wrote: >> Greetings, >> >> I ran this test multiple times on Linux & Windows and the tests complete in less than a second. However, I do not have a sparc system to test (if I am correct, earlier discussion pointed that timeout issue is seen on sparc). >> >> My guess of what is happening is ? For testing purposes we use the file system of the test directory, instead of a dax filesystem for nv-dimm. With the AllocateHeapAt flag set, heap memory is mapped to a temporary file in the test directory. Depending on the test environment (filesystem, memory, disk, etc), heap memory access might be quite slower. >> >> So I think we should decrease the heap size of the tests. The 5th & 6th subtests can be changed to use 32M instead of 4G. The 4th subtest can be removed. >> >> Here is the patch with the changes - http://cr.openjdk.java.net/~kkharbas/8213695/webrev.00/ > Looks good to me. > And I can sponsor this patch, but we need a review from a (R)eviewer. > > FYI, I tested the patch on sparc machines(same kind of machines which reported the problem) for 40 times and its run time was mostly less than 3 seconds. Looks good. From david.holmes at oracle.com Mon Jan 21 02:29:53 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 21 Jan 2019 12:29:53 +1000 Subject: RFR: 8194860: Cleanup Semaphore timed-wait time calculations In-Reply-To: <6b3f3d2f-259f-72db-8e9a-7b24507711ee@oracle.com> References: <7557e8f2-5622-0317-972d-601b607d6b95@oracle.com> <6b3f3d2f-259f-72db-8e9a-7b24507711ee@oracle.com> Message-ID: <492dfba9-54ca-c09e-c277-0ac2029e4be1@oracle.com> Here's the updated webrev: http://cr.openjdk.java.net/~dholmes/8194860/webrev.v2 Only changes are in os_posix.cpp: - As Coleen requested I statically initialized the various static variables to simplify the conditional compilation for Solaris and removed the dynamic initialization to NULL/false. - I had a bug (exposed on old OS X versions) where I was using clock_gettime even though it might not be available. Thanks, David On 18/01/2019 8:19 am, David Holmes wrote: > Hi Coleen, > > Thanks for looking at this - though I still have to resolve my OS X issue. > > On 17/01/2019 11:04 pm, coleen.phillimore at oracle.com wrote: >> http://cr.openjdk.java.net/~dholmes/8194860/webrev/src/hotspot/os/posix/os_posix.cpp.frames.html >> >> >> For os_init2, I don't see why you have to sprinkle #ifndef SOLARIS. >> It's just logging, won't the logging be useful in the negative for >> solaris? > > The problem is that regardless of whether the initialization works or > fails on Solaris, those "attributes" won't get used on Solaris anyway, > so the logging would be misleading/confusing. So I just elided it. > >> Can these three statics default to false/NULL above?? Then you can >> save having to have this conditional as well: >> >> +#else >> +? _use_clock_monotonic_condattr = false; >> +#endif // !SOLARIS > > Yes I should be able to do that (famous last words!). > >> Thank you for resolving the differences between to_abstime and solaris >> unpackTime, which was one of the causes of this mess left by the >> refactoring. > > There's still a lot of mess in the Solaris code. > > Thanks again, > David > >> Looks good, with this one suggestion to remove some #ifndef solaris >> above. >> Coleen >> >> >> >> On 1/16/19 5:06 PM, David Holmes wrote: >>> bug: https://bugs.openjdk.java.net/browse/JDK-8194860 >>> webrev: http://cr.openjdk.java.net/~dholmes/8194860/webrev/ >>> >>> Details in the bug report, but there was duplication in functionality >>> with regards to timeout conversions/calculations, and the os_bsd.cpp >>> code was broken due to OSXSemaphore and PosixSemaphore having >>> different API's. >>> >>> Summary: >>> - expanded the API to take a relative timeout in millis as well as >>> the existing absolute timeout as a timespec: >>> >>> ? // wait until the given absolute time is reached >>> ? bool timedwait(struct timespec ts); >>> ? // wait until the given relative time elapses >>> ? bool timedwait(int64_t millis); >>> >>> The millis version simply converts to a timespec and calls the other >>> version e.g >>> >>> bool PosixSemaphore::timedwait(int64_t millis) { >>> ? struct timespec ts; >>> ? os::Posix::to_RTC_abstime(&ts, millis); >>> ? return timedwait(ts); >>> } >>> >>> - added os::Posix::to_RTC_abstime to do the relative to absolute >>> conversion using the existing routines in os::Posix used for >>> PlatformEvent etc. >>> >>> - changed callsites to use new millis version >>> >>> - I had to rearrange the ifndef SOLARIS in os_posix.cpp to expose >>> previously hidden code to Solaris. It isn't all needed by Solaris but >>> I chose not to clutter things with too many ifdefs and only excluded >>> things that really shouldn't be done on Solaris. Also needed to call >>> os::Posix::init on Solaris. >>> >>> Testing (still in progress): >>> - mach 5 tiers 1 - 3 (Linux, Solaris, OS X, Windows) >>> - test/jdk/jdk/jfr (as suspend/resume is the user of the semaphore code) >>> >>> Thanks, >>> David >> From jiangli.zhou at oracle.com Mon Jan 21 03:12:43 2019 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Sun, 20 Jan 2019 19:12:43 -0800 Subject: Preliminary code review for 8207812: Implement Dynamic Class Metadata Archive Message-ID: <82df3ad9-b48a-517c-6aae-c5b10cdebbfe@oracle.com> Providing a mechanism for archiving class metadata as part of a Java application execution has been suggested & requested by many in the past. We have listened and this mechanism is now materialized. The following webrev is the implementation for dynamic archiving. It improves CDS/AppCDS usage by eliminating the need for trial runs. The implementation is contributed by Calvin, Ioi and myself. The code is still relatively raw and requires more testing (including test development), cleanup, and polish. We'd like to seek early feedback from the community with this preliminary code review. ? webrev: http://cr.openjdk.java.net/~jiangli/8207812_dynamic_archive/webrev.00/ ? RFE: https://bugs.openjdk.java.net/browse/JDK-8207812 Description ======= A shared archive for a given Java application is dynamically created at the application runtime when -Xshare:dynamicDump is enabled. The archive is created on top of the default CDS archive packaged with the running JDK binary. A separate top-layer archive file is generated for each different Java application. Users can specify the archive name&path using -XX:SharedDynamicArchiveFile= option. ? Example: % bin/java -Xshare:dynamicDump -XX:SharedDynamicArchiveFile=hw.jsa -cp hello.jar HelloWorld NOTE: the command-line options for dynamic archiving is not yet finalized. Please see JDK-8207812 comments for more details. With the dynamic archive in place, following configurations are supported at runtime: - Default CDS archive (base) + dynamic archive: when both archives are mapped successfully - Base archive only: when dynamic archive cannot be mapped If the base layer archive cannot be mapped and used at runtime, the top layer archive is automatically disabled. Base Layer Dependency -------------------- As the dynamically created top layer archive has dependency on the base archive (e.g. pointers to base layer data), the CRC checksums of the base archive header and all shared spaces are recorded in the top layer. At runtime, when the dynamic archive is mapped in, all recorded CRC checksums are compared with the currently mapped base archive CRC values. If any of the CRC checksum mismatches, the dynamic archive is disabled without affecting the usage of the currently mapped base archive. Copying and Relocating Class Metadata --------------------------------- All loaded application classes and library classes (excluding the ones included in the base layer) are dynamically archived in the top-layer based on the current execution context. Copying and relocating of class metadata is done at the end of the application execution and before VM exit. Cleanup is done for archived data to remove any un-shareable information. If a user defined class loader and associated classes are unloaded, those classes are not archived in the currently implementation. Entrenchment for user defined class loader support will be added after initial integration. Shared Spaces in Dynamic Archive ----------------------------- The memory lay-out in the dynamic archive is similar to the existing static archive created using a classlist. Metadata is separated into following four spaces. No 'md' space is needed (C++ vtables are from the base archive). No archived Java heap regions are included in the dynamic archive currently. ?- rw space: Read-writable data ?- ro: Read-only data ?- mc: Trampoline ?- od: Optional data (class file data, for JVMTI support) The shared spaces are mapped individually at runtime. The 'ro' space is mapped as read-only for sharing. Preliminary performance data with HelloWorld indicates there is no observable runtime performance degradation with dynamic archive. The change currently pass all tier1, tier2 and tier3. Thanks, Jiangli From kim.barrett at oracle.com Mon Jan 21 08:42:31 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 21 Jan 2019 03:42:31 -0500 Subject: RFR: 8194860: Cleanup Semaphore timed-wait time calculations In-Reply-To: <492dfba9-54ca-c09e-c277-0ac2029e4be1@oracle.com> References: <7557e8f2-5622-0317-972d-601b607d6b95@oracle.com> <6b3f3d2f-259f-72db-8e9a-7b24507711ee@oracle.com> <492dfba9-54ca-c09e-c277-0ac2029e4be1@oracle.com> Message-ID: > On Jan 20, 2019, at 9:29 PM, David Holmes wrote: > > Here's the updated webrev: > > http://cr.openjdk.java.net/~dholmes/8194860/webrev.v2 > > Only changes are in os_posix.cpp: > > - As Coleen requested I statically initialized the various static variables to simplify the conditional compilation for Solaris and removed the dynamic initialization to NULL/false. > > - I had a bug (exposed on old OS X versions) where I was using clock_gettime even though it might not be available. Looks good. A few questions / comments about mostly pre-existing code. ------------------------------------------------------------------------------ src/hotspot/os/posix/os_posix.cpp 1630 static pthread_condattr_t _condAttr[1]; 1634 static pthread_mutexattr_t _mutexAttr[1]; Pre-existing. Why are these one element arrays, rather than just single objects? ------------------------------------------------------------------------------ src/hotspot/os/posix/os_posix.cpp 1735 int (*condattr_setclock_func)(pthread_condattr_t*, clockid_t) = 1736 (int (*)(pthread_condattr_t*, clockid_t))dlsym(RTLD_DEFAULT, 1737 "pthread_condattr_setclock"); 1738 if (condattr_setclock_func != NULL) { 1739 _pthread_condattr_setclock = condattr_setclock_func; 1740 } Pre-existing. Why the local condattr_setclock_func? Why not just directly set _pthread_condattr_setclock from the dlsym lookup? This isn't like the earlier case with _clock_gettime &etc, where there are additional checks to be performed before accepting the library function. ------------------------------------------------------------------------------ src/hotspot/os/posix/os_posix.hpp 136 static void to_RTC_abstime(timespec* abstime, int64_t millis); I thought about suggesting returning a timespec rather than taking a pointer to one as an argument. That would be more usual C++ style, and would avoid any possibility of accidentally passing in a NULL pointer. But it would require doing some research on the state of copy elision in some compilers that I'm less familiar with. Doing so would also suggest doing the same for to_abstime. ------------------------------------------------------------------------------ From david.holmes at oracle.com Mon Jan 21 12:45:06 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 21 Jan 2019 22:45:06 +1000 Subject: RFR: 8194860: Cleanup Semaphore timed-wait time calculations In-Reply-To: References: <7557e8f2-5622-0317-972d-601b607d6b95@oracle.com> <6b3f3d2f-259f-72db-8e9a-7b24507711ee@oracle.com> <492dfba9-54ca-c09e-c277-0ac2029e4be1@oracle.com> Message-ID: <9332c11a-251a-eaab-804a-beb354eed30d@oracle.com> Hi Kim, Responses inline. On 21/01/2019 6:42 pm, Kim Barrett wrote: >> On Jan 20, 2019, at 9:29 PM, David Holmes wrote: >> >> Here's the updated webrev: >> >> http://cr.openjdk.java.net/~dholmes/8194860/webrev.v2 >> >> Only changes are in os_posix.cpp: >> >> - As Coleen requested I statically initialized the various static variables to simplify the conditional compilation for Solaris and removed the dynamic initialization to NULL/false. >> >> - I had a bug (exposed on old OS X versions) where I was using clock_gettime even though it might not be available. > > Looks good. Thanks for looking at it. > A few questions / comments about mostly pre-existing code. > > ------------------------------------------------------------------------------ > src/hotspot/os/posix/os_posix.cpp > 1630 static pthread_condattr_t _condAttr[1]; > 1634 static pthread_mutexattr_t _mutexAttr[1]; > > Pre-existing. Why are these one element arrays, rather than just > single objects? I don't recall the rationale but its a pattern that's been in the code for years. > ------------------------------------------------------------------------------ > src/hotspot/os/posix/os_posix.cpp > 1735 int (*condattr_setclock_func)(pthread_condattr_t*, clockid_t) = > 1736 (int (*)(pthread_condattr_t*, clockid_t))dlsym(RTLD_DEFAULT, > 1737 "pthread_condattr_setclock"); > 1738 if (condattr_setclock_func != NULL) { > 1739 _pthread_condattr_setclock = condattr_setclock_func; > 1740 } > > Pre-existing. Why the local condattr_setclock_func? Why not just > directly set _pthread_condattr_setclock from the dlsym lookup? This > isn't like the earlier case with _clock_gettime &etc, where there are > additional checks to be performed before accepting the library > function. I just copied the existing patterns when I added this. > ------------------------------------------------------------------------------ > src/hotspot/os/posix/os_posix.hpp > 136 static void to_RTC_abstime(timespec* abstime, int64_t millis); > > I thought about suggesting returning a timespec rather than taking a > pointer to one as an argument. That would be more usual C++ style, and > would avoid any possibility of accidentally passing in a NULL pointer. > But it would require doing some research on the state of copy elision > in some compilers that I'm less familiar with. Doing so would also > suggest doing the same for to_abstime. I'm still a C programmer at heart and find myself much more comfortable using pointers this way - as they get used by the C libraries. I don't know when C++ will or won't make additional copies when returning structs. I always get concerned by C++ code that looks to me like it is returning a stack-allocated local instance. Thanks, David ----- > ------------------------------------------------------------------------------ > From claes.redestad at oracle.com Mon Jan 21 13:57:43 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 21 Jan 2019 14:57:43 +0100 Subject: RFR: 8217442: Optimize native accesses to String.value Message-ID: <0b262c93-185d-90da-8b19-d05e895dacee@oracle.com> Hi, operations like jni_GetStringLength, jni_GetStringUTFLength access String.value multiple times, which emits an access barrier each time. Streamlining the API so that String.value is only accessed once lead to a measurable speed-up (including a tiny startup improvement). Bug: https://bugs.openjdk.java.net/browse/JDK-8217442 Webrev: http://cr.openjdk.java.net/~redestad/8217442/open.00/ Testing: tier1-3 (ongoing/completed on some platforms) /Claes From shade at redhat.com Mon Jan 21 15:07:00 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 21 Jan 2019 16:07:00 +0100 Subject: RFR: 8217442: Optimize native accesses to String.value In-Reply-To: <0b262c93-185d-90da-8b19-d05e895dacee@oracle.com> References: <0b262c93-185d-90da-8b19-d05e895dacee@oracle.com> Message-ID: On 1/21/19 2:57 PM, Claes Redestad wrote: > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8217442 > Webrev: http://cr.openjdk.java.net/~redestad/8217442/open.00/ Mostly stylistics: *) New line here: 592 } 593 int java_lang_String::utf8_length(oop java_string) { *) Seems like new code uses 4-space indent, while the existing style is 2-spaces. *) Stray space after "value": 626 typeArrayOop value = java_lang_String::value(java_string); *) Pretty sure you need to use oopDesc::equals_raw instead of ==, as "oop::operator==" asserts in some BarrierSets, e.g. Shenandoah's. 581 assert(value == java_lang_String::value(java_string), 582 "value must be same as java_lang_String::value(java_string)"); 612 assert(value == java_lang_String::value(java_string), 613 "value must be same as java_lang_String::value(java_string)"); -Aleksey From thomas.stuefe at gmail.com Mon Jan 21 15:29:09 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 21 Jan 2019 16:29:09 +0100 Subject: Do array class name symbols for unloaded array classes leak deliberately? Message-ID: Hi all, Looking at ~ClassLoaderData(), I see that we never seem to decrease the refcount on Klass::_name for ArrayKlass* childs. We do this for InstanceKlass* childs (via ReleaseKlassClosure::do_klass() -> InstanceKlass::release_C_heap_structures(k)) but not for ArrayKlass*. This causes observable leaks: When I run a small test program where I load a number of generated classes, instance and array both, and then GC them, the array class symbol names leak: thomas at t450:/shared/projects/openjdk/jdk-jdk/output-fastdebug$ jjjcmd test3.Example2 VM.symboltable -verbose | grep myclass 26 65535: [Lmyclass_size_1_number_0; 26 65535: [Lmyclass_size_1_number_1; 26 65535: [Lmyclass_size_1_number_2; This seems to be always have been the case and it seems deliberate: the array class name is created as a permanent symbol : Klass* ObjArrayKlass::allocate_objArray_klass(ClassLoaderData* loader_data, int n, Klass* element_klass, TRAPS) { ... name = SymbolTable::new_permanent_symbol(new_str, CHECK_0); ... } Why is that? Why do we remove class name symbols for instance classes, but leave them for arrays? Thanks & Kind Regards, Thomas From claes.redestad at oracle.com Mon Jan 21 16:03:02 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 21 Jan 2019 17:03:02 +0100 Subject: RFR: 8217442: Optimize native accesses to String.value In-Reply-To: References: <0b262c93-185d-90da-8b19-d05e895dacee@oracle.com> Message-ID: <802e5141-ef0d-044c-80f3-4f48175352ed@oracle.com> Hi, On 2019-01-21 16:07, Aleksey Shipilev wrote: > On 1/21/19 2:57 PM, Claes Redestad wrote: >> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8217442 >> Webrev: http://cr.openjdk.java.net/~redestad/8217442/open.00/ > > Mostly stylistics: > > *) New line here: > > 592 } > 593 int java_lang_String::utf8_length(oop java_string) { Fixed. > > *) Seems like new code uses 4-space indent, while the existing style is 2-spaces. I picked up CLion recently and seems it's been reformatting code gratuitously on copy-paste. Told it to use 2-space indentation and fixed things up. > > *) Stray space after "value": > 626 typeArrayOop value = java_lang_String::value(java_string); Seems I got this from a pre-existing indentation quirk where "value" was being aligned with "length". Fixed in the new, standalone places. > > *) Pretty sure you need to use oopDesc::equals_raw instead of ==, as "oop::operator==" asserts in > some BarrierSets, e.g. Shenandoah's. > > 581 assert(value == java_lang_String::value(java_string), > 582 "value must be same as java_lang_String::value(java_string)"); > > 612 assert(value == java_lang_String::value(java_string), > 613 "value must be same as java_lang_String::value(java_string)"); Yes, that seems better/safer. http://cr.openjdk.java.net/~redestad/8217442/open.01/ Thanks! /Claes From shade at redhat.com Mon Jan 21 16:07:44 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 21 Jan 2019 17:07:44 +0100 Subject: RFR: 8217442: Optimize native accesses to String.value In-Reply-To: <802e5141-ef0d-044c-80f3-4f48175352ed@oracle.com> References: <0b262c93-185d-90da-8b19-d05e895dacee@oracle.com> <802e5141-ef0d-044c-80f3-4f48175352ed@oracle.com> Message-ID: On 1/21/19 5:03 PM, Claes Redestad wrote: > http://cr.openjdk.java.net/~redestad/8217442/open.01/ Looks okay to me. -Aleksey From claes.redestad at oracle.com Mon Jan 21 16:12:47 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 21 Jan 2019 17:12:47 +0100 Subject: RFR: 8217442: Optimize native accesses to String.value In-Reply-To: References: <0b262c93-185d-90da-8b19-d05e895dacee@oracle.com> <802e5141-ef0d-044c-80f3-4f48175352ed@oracle.com> Message-ID: <50408dec-ece8-9674-07d6-7438d9e5af2c@oracle.com> On 2019-01-21 17:07, Aleksey Shipilev wrote: > On 1/21/19 5:03 PM, Claes Redestad wrote: >> http://cr.openjdk.java.net/~redestad/8217442/open.01/ > > Looks okay to me. > Thanks! /Claes From claes.redestad at oracle.com Mon Jan 21 16:18:13 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 21 Jan 2019 17:18:13 +0100 Subject: RFR: 8217450: Add PackageEntry::locked_lookup_only Message-ID: <1be87fda-1f82-a88d-90d4-8cce2e972115@oracle.com> Hi, adding a PackageEntry::locked_lookup_only for use from places where we know we hold the Module_lock avoids a small chunk of work during startup. Bug: https://bugs.openjdk.java.net/browse/JDK-8217450 Webrev: http://cr.openjdk.java.net/~redestad/8217450/open.00/ Testing: tier1-3 (ongoing, complete on most platforms) Thanks! /Claes From david.holmes at oracle.com Mon Jan 21 20:54:24 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 22 Jan 2019 06:54:24 +1000 Subject: RFR: 8217442: Optimize native accesses to String.value In-Reply-To: <0b262c93-185d-90da-8b19-d05e895dacee@oracle.com> References: <0b262c93-185d-90da-8b19-d05e895dacee@oracle.com> Message-ID: <59794859-33df-5c52-2cda-784b559826b9@oracle.com> Hi Claes, On 21/01/2019 11:57 pm, Claes Redestad wrote: > Hi, > > operations like jni_GetStringLength, jni_GetStringUTFLength access > String.value multiple times, which emits an access barrier each time. > > Streamlining the API so that String.value is only accessed once lead to > a measurable speed-up (including a tiny startup improvement). From an API perspective this is ugly to me: taking an object and a field that must come from the same object. What if we refactored so that java_lang_String::length(oop java_string, typeArrayOop value) became java_lang_String::length(typeArrayOop value, bool isLatin1) would that also achieve the goal while presenting (IMHO) a cleaner API? Thanks, David > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8217442 > Webrev: http://cr.openjdk.java.net/~redestad/8217442/open.00/ > > Testing: tier1-3 (ongoing/completed on some platforms) > > /Claes From claes.redestad at oracle.com Mon Jan 21 22:07:28 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 21 Jan 2019 23:07:28 +0100 Subject: RFR: 8217442: Optimize native accesses to String.value In-Reply-To: <59794859-33df-5c52-2cda-784b559826b9@oracle.com> References: <0b262c93-185d-90da-8b19-d05e895dacee@oracle.com> <59794859-33df-5c52-2cda-784b559826b9@oracle.com> Message-ID: <9d33d7d1-eeb4-ca23-98eb-d136e26429e1@oracle.com> Hi David, On 2019-01-21 21:54, David Holmes wrote: > What if we refactored so that > > java_lang_String::length(oop java_string, typeArrayOop value) > > became > > java_lang_String::length(typeArrayOop value, bool isLatin1) > > would that also achieve the goal while presenting (IMHO) a cleaner API? doing so would get rid of the contorted asserts at least, and seems to be performance neutral on all operations: http://cr.openjdk.java.net/~redestad/8217442/open.02/ Re-running tests. /Claes From david.holmes at oracle.com Mon Jan 21 22:41:35 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 22 Jan 2019 08:41:35 +1000 Subject: RFR: 8217442: Optimize native accesses to String.value In-Reply-To: <9d33d7d1-eeb4-ca23-98eb-d136e26429e1@oracle.com> References: <0b262c93-185d-90da-8b19-d05e895dacee@oracle.com> <59794859-33df-5c52-2cda-784b559826b9@oracle.com> <9d33d7d1-eeb4-ca23-98eb-d136e26429e1@oracle.com> Message-ID: Hi Claes, Sorry to do this to you but I'm questioning the underlying assumption here regarding the existing patterns of checking value for null before getting the length. According to String.java * Additionally, it is marked with {@link Stable} to trust the contents * of the array. No other facility in JDK provides this functionality (yet). * {@link Stable} is safe here, because value is never null. */ @Stable private final byte[] value; value can never be null so the null checks should be removeable, then you wouldn't have the double-accesses to value. David ----- On 22/01/2019 8:07 am, Claes Redestad wrote: > Hi David, > > On 2019-01-21 21:54, David Holmes wrote: >> What if we refactored so that >> >> java_lang_String::length(oop java_string, typeArrayOop value) >> >> became >> >> java_lang_String::length(typeArrayOop value, bool isLatin1) >> >> would that also achieve the goal while presenting (IMHO) a cleaner API? > > doing so would get rid of the contorted asserts at least, and seems to > be performance neutral on all operations: > > http://cr.openjdk.java.net/~redestad/8217442/open.02/ > > Re-running tests. > > /Claes From claes.redestad at oracle.com Mon Jan 21 22:56:36 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 21 Jan 2019 23:56:36 +0100 Subject: RFR: 8217442: Optimize native accesses to String.value In-Reply-To: References: <0b262c93-185d-90da-8b19-d05e895dacee@oracle.com> <59794859-33df-5c52-2cda-784b559826b9@oracle.com> <9d33d7d1-eeb4-ca23-98eb-d136e26429e1@oracle.com> Message-ID: <6254d556-c1af-02da-6701-aa6640f56f97@oracle.com> Hi, why yes, those checks do seem necessary, don't they? So I did to some digging before I settled on an approach (Erik ?sterlund helped me interpret the profiles and explain to me why the repeated accesses are a cost in these cases). It appears it's related to crashes when debugging Strings that have only been partially initialized. See https://bugs.openjdk.java.net/browse/JDK-8025922 and https://bugs.openjdk.java.net/browse/JDK-8021897 for more details. So I don't think it's advisable to remove the null checks. And even without them there would be a few double-accesses left to optimize away. Thanks! /Claes On 2019-01-21 23:41, David Holmes wrote: > Hi Claes, > > Sorry to do this to you but I'm questioning the underlying assumption > here regarding the existing patterns of checking value for null before > getting the length. According to String.java > > ??? * Additionally, it is marked with {@link Stable} to trust the contents > ???? * of the array. No other facility in JDK provides this > functionality (yet). > ???? * {@link Stable} is safe here, because value is never null. > ???? */ > ??? @Stable > ??? private final byte[] value; > > value can never be null so the null checks should be removeable, then > you wouldn't have the double-accesses to value. > > David > ----- > > On 22/01/2019 8:07 am, Claes Redestad wrote: >> Hi David, >> >> On 2019-01-21 21:54, David Holmes wrote: >>> What if we refactored so that >>> >>> java_lang_String::length(oop java_string, typeArrayOop value) >>> >>> became >>> >>> java_lang_String::length(typeArrayOop value, bool isLatin1) >>> >>> would that also achieve the goal while presenting (IMHO) a cleaner API? >> >> doing so would get rid of the contorted asserts at least, and seems to >> be performance neutral on all operations: >> >> http://cr.openjdk.java.net/~redestad/8217442/open.02/ >> >> Re-running tests. >> >> /Claes From david.holmes at oracle.com Mon Jan 21 23:21:32 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 22 Jan 2019 09:21:32 +1000 Subject: RFR: 8217442: Optimize native accesses to String.value In-Reply-To: <6254d556-c1af-02da-6701-aa6640f56f97@oracle.com> References: <0b262c93-185d-90da-8b19-d05e895dacee@oracle.com> <59794859-33df-5c52-2cda-784b559826b9@oracle.com> <9d33d7d1-eeb4-ca23-98eb-d136e26429e1@oracle.com> <6254d556-c1af-02da-6701-aa6640f56f97@oracle.com> Message-ID: <6d30466c-648a-6795-6df0-f46bb508f45c@oracle.com> Hi Claes, As per our IM discussion lets go back to your first version as both versions break encapsulation to a similar level. I'll send out additional review email for that. Follow up below just to express an opinion ... :) On 22/01/2019 8:56 am, Claes Redestad wrote: > Hi, > > why yes, those checks do seem necessary, don't they? So I did to some > digging before I settled on an approach (Erik ?sterlund helped me > interpret the profiles and explain to me why the repeated accesses are > a cost in these cases). > > It appears it's related to crashes when debugging Strings that have only > been partially initialized. See > https://bugs.openjdk.java.net/browse/JDK-8025922 and > https://bugs.openjdk.java.net/browse/JDK-8021897 for more details. Hmmmm - despite being involved in one of the above code reviews I'm highly suspect of those particular fixes. I don't think the main JNI API needs concern itself with partially initialized Strings - how would it get one? JNI doesn't do error checking so this would seem like a user error to me - caveat emptor. For the debugger case I think the fix was done at the wrong end of the debugger - why should the debugger ask the VM for "this" when single stepping the constructor? The debugger has to be be aware that it's dealing with uninitialized memory. Anyway we won't be revisiting these decisions any time soon. Cheers, David > So I don't think it's advisable to remove the null checks. And even > without them there would be a few double-accesses left to optimize away. > > Thanks! > > /Claes > > On 2019-01-21 23:41, David Holmes wrote: >> Hi Claes, >> >> Sorry to do this to you but I'm questioning the underlying assumption >> here regarding the existing patterns of checking value for null before >> getting the length. According to String.java >> >> ???? * Additionally, it is marked with {@link Stable} to trust the >> contents >> ????? * of the array. No other facility in JDK provides this >> functionality (yet). >> ????? * {@link Stable} is safe here, because value is never null. >> ????? */ >> ???? @Stable >> ???? private final byte[] value; >> >> value can never be null so the null checks should be removeable, then >> you wouldn't have the double-accesses to value. >> >> David >> ----- >> >> On 22/01/2019 8:07 am, Claes Redestad wrote: >>> Hi David, >>> >>> On 2019-01-21 21:54, David Holmes wrote: >>>> What if we refactored so that >>>> >>>> java_lang_String::length(oop java_string, typeArrayOop value) >>>> >>>> became >>>> >>>> java_lang_String::length(typeArrayOop value, bool isLatin1) >>>> >>>> would that also achieve the goal while presenting (IMHO) a cleaner API? >>> >>> doing so would get rid of the contorted asserts at least, and seems to >>> be performance neutral on all operations: >>> >>> http://cr.openjdk.java.net/~redestad/8217442/open.02/ >>> >>> Re-running tests. >>> >>> /Claes From david.holmes at oracle.com Mon Jan 21 23:33:11 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 22 Jan 2019 09:33:11 +1000 Subject: RFR: 8217442: Optimize native accesses to String.value In-Reply-To: References: <0b262c93-185d-90da-8b19-d05e895dacee@oracle.com> <802e5141-ef0d-044c-80f3-4f48175352ed@oracle.com> Message-ID: <16d59b0e-2f3b-4a76-194d-134b92a1bfe7@oracle.com> +1 Thanks, David On 22/01/2019 2:07 am, Aleksey Shipilev wrote: > On 1/21/19 5:03 PM, Claes Redestad wrote: >> http://cr.openjdk.java.net/~redestad/8217442/open.01/ > > Looks okay to me. > > -Aleksey > From david.holmes at oracle.com Tue Jan 22 00:02:58 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 22 Jan 2019 10:02:58 +1000 Subject: RFR: 8217450: Add PackageEntry::locked_lookup_only In-Reply-To: <1be87fda-1f82-a88d-90d4-8cce2e972115@oracle.com> References: <1be87fda-1f82-a88d-90d4-8cce2e972115@oracle.com> Message-ID: <38fa742d-a9ac-9a96-9ac8-63d1595a2898@oracle.com> Hi Claes, On 22/01/2019 2:18 am, Claes Redestad wrote: > Hi, > > adding a PackageEntry::locked_lookup_only for use from places where > we know we hold the Module_lock avoids a small chunk of work during > startup. > > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8217450 > Webrev: http://cr.openjdk.java.net/~redestad/8217450/open.00/ Looks good. Please update copyright years. One minor suggestions: src/hotspot/share/classfile/packageEntry.hpp The new method seems out of order where it is declared. I think it would be better to follow lookup_only with locked_lookup_only and also clarify the locking e.g. // Only lookup Package within loader's package entry table. + // This will acquire the Module_lock. PackageEntry* lookup_only(Symbol* Package); + + // Only lookup Package within loader's package entry table. + // This assumes the Module_lock is already held. + PackageEntry* locked_lookup_only(Symbol* Package); Thanks, David > Testing: tier1-3 (ongoing, complete on most platforms) > > Thanks! > > /Claes > From ioi.lam at oracle.com Tue Jan 22 05:30:56 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 21 Jan 2019 21:30:56 -0800 Subject: RFR(t) 8217424 Remove the idempotent parameter to Method::sort_methods Message-ID: Please review this trivial change. The "idempotent" parameter to Method::sort_methods() is always false, so let's just remove it. https://bugs.openjdk.java.net/browse/JDK-8217424 http://cr.openjdk.java.net/~iklam/jdk13/8217424-sort-methods-idempotent-param.v01/ Thanks - Ioi From claes.redestad at oracle.com Tue Jan 22 10:34:42 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 22 Jan 2019 11:34:42 +0100 Subject: RFR: 8217442: Optimize native accesses to String.value In-Reply-To: <16d59b0e-2f3b-4a76-194d-134b92a1bfe7@oracle.com> References: <0b262c93-185d-90da-8b19-d05e895dacee@oracle.com> <802e5141-ef0d-044c-80f3-4f48175352ed@oracle.com> <16d59b0e-2f3b-4a76-194d-134b92a1bfe7@oracle.com> Message-ID: On 2019-01-22 00:33, David Holmes wrote: > +1 Thanks David, pushed open.01 /Claes From claes.redestad at oracle.com Tue Jan 22 10:53:30 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 22 Jan 2019 11:53:30 +0100 Subject: RFR: 8217450: Add PackageEntry::locked_lookup_only In-Reply-To: <38fa742d-a9ac-9a96-9ac8-63d1595a2898@oracle.com> References: <1be87fda-1f82-a88d-90d4-8cce2e972115@oracle.com> <38fa742d-a9ac-9a96-9ac8-63d1595a2898@oracle.com> Message-ID: <24f221c3-a9b7-41b7-99d0-fdf0ff63a792@oracle.com> On 2019-01-22 01:02, David Holmes wrote: > Looks good. Thanks! > Please update copyright years. Done. > > One minor suggestions: > > src/hotspot/share/classfile/packageEntry.hpp > > The new method seems out of order where it is declared. I think it would > be better to follow lookup_only with locked_lookup_only and also clarify > the locking e.g. > > ??? // Only lookup Package within loader's package entry table. > +?? // This will acquire the Module_lock. > ??? PackageEntry* lookup_only(Symbol* Package); > + > +?? // Only lookup Package within loader's package entry table. > +?? // This assumes the Module_lock is already held. > +?? PackageEntry* locked_lookup_only(Symbol* Package); Sure, updated in-place: http://cr.openjdk.java.net/~redestad/8217450/open.00/ /Claes From shade at redhat.com Tue Jan 22 11:52:06 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 22 Jan 2019 12:52:06 +0100 Subject: RFR(t) 8217424 Remove the idempotent parameter to Method::sort_methods In-Reply-To: References: Message-ID: <05fa4145-afb0-22f3-8db6-3aa7f75032fb@redhat.com> On 1/22/19 6:30 AM, Ioi Lam wrote: > https://bugs.openjdk.java.net/browse/JDK-8217424 > http://cr.openjdk.java.net/~iklam/jdk13/8217424-sort-methods-idempotent-param.v01/ This looks fine. It is not as obvious/trivial, given there are default arguments that can be partially used somewhere (for example, Method::sort_methods(total, true)), but there seem to be only two uses of Method::sort_methods now: // Sort method array by ascending method name (for faster lookups & vtable construction) // Note that the ordering is not alphabetical, see Symbol::fast_compare Method::sort_methods(methods); ...and: Method::sort_methods(total_default_methods, false, false); ...neither of which does anything fancy, so this makes the change okay. -Aleksey From goetz.lindenmaier at sap.com Tue Jan 22 11:59:42 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 22 Jan 2019 11:59:42 +0000 Subject: RFR(S): 8217512: Message of LinkageError: use 'class' etc. instead of 'type' Message-ID: <5d21becdeb284e47995e682868b1730c@sap.com> Hi, I would like to change 'type' to 'class' in the following exception text: (class will be replaced by 'interface' ... etc depending on the actual type). old: java.lang.LinkageError: loader constraint violation: when resolving field "_field1" of type pkg.Foo, the class loader pkg.ClassLoaderForChildGrandFoo @42b2e259 of the current class, pkg.Child, and the class loader pkg.ClassLoaderForParentFoo @4b55c90f for the field's defining type, pkg.Parent, have different Class objects for type pkg.Foo (pkg.Child is in unnamed module of loader pkg.ClassLoaderForChildGrandFoo @42b2e259, parent loader 'app'; pkg.Parent is in unnamed module of loader pkg.ClassLoaderForParentFoo @4b55c90f, parent loader 'app') new: java.lang.LinkageError: loader constraint violation: when resolving field "_field1" of type pkg.Foo, the class loader pkg.ClassLoaderForChildGrandFoo @42b2e259 of the current class, pkg.Child, and the class loader pkg.ClassLoaderForParentFoo @4b55c90f for the field's defining class, pkg.Parent, have different Class objects for type pkg.Foo (pkg.Child is in unnamed module of loader pkg.ClassLoaderForChildGrandFoo @42b2e259, parent loader 'app'; pkg.Parent is in unnamed module of loader pkg.ClassLoaderForParentFoo @4b55c90f, parent loader 'app') I think this makes the text better understandable: 'type' is used where the declared type of _field1 is meant. 'class' is used whenever we address the "defining type", i.e. the class that 'has' the field, is meant. Please review: http://cr.openjdk.java.net/~goetz/wr19/8217512-LinkageE_tiny/01/ Best regards, Goetz. From david.holmes at oracle.com Tue Jan 22 12:14:24 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 22 Jan 2019 22:14:24 +1000 Subject: RFR(S): 8217512: Message of LinkageError: use 'class' etc. instead of 'type' In-Reply-To: <5d21becdeb284e47995e682868b1730c@sap.com> References: <5d21becdeb284e47995e682868b1730c@sap.com> Message-ID: <31cf4dcc-3357-9975-0d2d-5d656743d6d7@oracle.com> Hi Goetz, On 22/01/2019 9:59 pm, Lindenmaier, Goetz wrote: > Hi, > > I would like to change 'type' to 'class' in the following exception text: > (class will be replaced by 'interface' ... etc depending on the actual type). That detail wasn't clear from the bug report. :) Replacing "type" with the actual type seems fine. I'm a little surprised only one test needs adjusting though. Thanks, David > old: > > java.lang.LinkageError: loader constraint violation: > when resolving field "_field1" of type pkg.Foo, > the class loader pkg.ClassLoaderForChildGrandFoo @42b2e259 of the current class, pkg.Child, > and the class loader pkg.ClassLoaderForParentFoo @4b55c90f for the field's defining type, pkg.Parent, > have different Class objects for type pkg.Foo > (pkg.Child is in unnamed module of loader pkg.ClassLoaderForChildGrandFoo @42b2e259, parent loader 'app'; > pkg.Parent is in unnamed module of loader pkg.ClassLoaderForParentFoo @4b55c90f, parent loader 'app') > > new: > > java.lang.LinkageError: loader constraint violation: > when resolving field "_field1" of type pkg.Foo, > the class loader pkg.ClassLoaderForChildGrandFoo @42b2e259 of the current class, pkg.Child, > and the class loader pkg.ClassLoaderForParentFoo @4b55c90f for the field's defining class, pkg.Parent, > have different Class objects for type pkg.Foo > (pkg.Child is in unnamed module of loader pkg.ClassLoaderForChildGrandFoo @42b2e259, parent loader 'app'; > pkg.Parent is in unnamed module of loader pkg.ClassLoaderForParentFoo @4b55c90f, parent loader 'app') > > I think this makes the text better understandable: 'type' is used where the declared type of _field1 > is meant. 'class' is used whenever we address the "defining type", i.e. the class that 'has' the > field, is meant. > > Please review: > http://cr.openjdk.java.net/~goetz/wr19/8217512-LinkageE_tiny/01/ > > Best regards, > Goetz. > From shade at redhat.com Tue Jan 22 12:27:05 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 22 Jan 2019 13:27:05 +0100 Subject: RFR: 8217450: Add PackageEntry::locked_lookup_only In-Reply-To: <24f221c3-a9b7-41b7-99d0-fdf0ff63a792@oracle.com> References: <1be87fda-1f82-a88d-90d4-8cce2e972115@oracle.com> <38fa742d-a9ac-9a96-9ac8-63d1595a2898@oracle.com> <24f221c3-a9b7-41b7-99d0-fdf0ff63a792@oracle.com> Message-ID: On 1/22/19 11:53 AM, Claes Redestad wrote: > http://cr.openjdk.java.net/~redestad/8217450/open.00/ *) "this" seems to be the superfluous change and/or bad grammar here? 211 // Some of java.base's packages were added early in bootstrapping, this ignore duplicates. *) "Pookup" ;) 253 // Pookup Package with loader's package entry table, add it if not found. *) The logic in duplicate finding loop is confusing, because it ignores "pkg" that might be NULL when package exists? I think it can be clearer if we move "PackageEntry* pkg;" down to actual intialization at L212. It seems to me the assert at L213 can "just" check the value returned by locked_lookup_only? Checking "pkg != NULL" is probably makes a tad faster fastdebug build, though. 208 // loop through and add any new packages for java.base 209 PackageEntry* pkg; 210 for (int x = 0; x < pkg_list->length(); x++) { 211 // Some of java.base's packages were added early in bootstrapping, this ignore duplicates. 212 pkg = package_table->locked_create_entry_or_null(pkg_list->at(x), ModuleEntryTable::javabase_moduleEntry()); 213 assert(pkg != NULL || package_table->locked_lookup_only(pkg_list->at(x)) != NULL, 214 "Unable to create a " JAVA_BASE_NAME " package entry"); 215 // Unable to have a GrowableArray of TempNewSymbol. Must decrement the refcount of 216 // the Symbol* that was created above for each package. The refcount was incremented 217 // by SymbolTable::new_symbol and as well by the PackageEntry creation. 218 pkg_list->at(x)->decrement_refcount(); 219 } -Aleksey From goetz.lindenmaier at sap.com Tue Jan 22 13:01:26 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 22 Jan 2019 13:01:26 +0000 Subject: RFR(S): 8217512: Message of LinkageError: use 'class' etc. instead of 'type' In-Reply-To: <31cf4dcc-3357-9975-0d2d-5d656743d6d7@oracle.com> References: <5d21becdeb284e47995e682868b1730c@sap.com> <31cf4dcc-3357-9975-0d2d-5d656743d6d7@oracle.com> Message-ID: Hi David, thanks for looking at this. > That detail wasn't clear from the bug report. :) I made the bug report more precise. I grepped all test for substrings of the message, also I ran it through our nighty tests which executes most of jdk and hotspot jtreg tests, but could not find any other tests. Best regards, Goetz. > -----Original Message----- > From: David Holmes > Sent: Dienstag, 22. Januar 2019 13:14 > To: Lindenmaier, Goetz ; hotspot-runtime- > dev at openjdk.java.net > Subject: Re: RFR(S): 8217512: Message of LinkageError: use 'class' etc. instead > of 'type' > > Hi Goetz, > > On 22/01/2019 9:59 pm, Lindenmaier, Goetz wrote: > > Hi, > > > > I would like to change 'type' to 'class' in the following exception text: > > (class will be replaced by 'interface' ... etc depending on the actual type). > > That detail wasn't clear from the bug report. :) > > Replacing "type" with the actual type seems fine. I'm a little surprised > only one test needs adjusting though. > > Thanks, > David > > > old: > > > > java.lang.LinkageError: loader constraint violation: > > when resolving field "_field1" of type pkg.Foo, > > the class loader pkg.ClassLoaderForChildGrandFoo @42b2e259 of the > current class, pkg.Child, > > and the class loader pkg.ClassLoaderForParentFoo @4b55c90f for the field's > defining type, pkg.Parent, > > have different Class objects for type pkg.Foo > > (pkg.Child is in unnamed module of loader > pkg.ClassLoaderForChildGrandFoo @42b2e259, parent loader 'app'; > > pkg.Parent is in unnamed module of loader pkg.ClassLoaderForParentFoo > @4b55c90f, parent loader 'app') > > > > new: > > > > java.lang.LinkageError: loader constraint violation: > > when resolving field "_field1" of type pkg.Foo, > > the class loader pkg.ClassLoaderForChildGrandFoo @42b2e259 of the > current class, pkg.Child, > > and the class loader pkg.ClassLoaderForParentFoo @4b55c90f for the field's > defining class, pkg.Parent, > > have different Class objects for type pkg.Foo > > (pkg.Child is in unnamed module of loader > pkg.ClassLoaderForChildGrandFoo @42b2e259, parent loader 'app'; > > pkg.Parent is in unnamed module of loader pkg.ClassLoaderForParentFoo > @4b55c90f, parent loader 'app') > > > > I think this makes the text better understandable: 'type' is used where the > declared type of _field1 > > is meant. 'class' is used whenever we address the "defining type", i.e. the > class that 'has' the > > field, is meant. > > > > Please review: > > http://cr.openjdk.java.net/~goetz/wr19/8217512-LinkageE_tiny/01/ > > > > Best regards, > > Goetz. > > From coleen.phillimore at oracle.com Tue Jan 22 13:33:27 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 22 Jan 2019 08:33:27 -0500 Subject: RFR(t) 8217424 Remove the idempotent parameter to Method::sort_methods In-Reply-To: References: Message-ID: I checked out of curiousity, this is what it used to do: ? // Prevent qsort from reordering a previous valid sort by ? // considering the address of the methodOops if two methods ? // would otherwise compare as equal.? Required to preserve ? // optimal access order in the shared archive.? Slower than ? // method_compare, only used for shared archive creation. ? static int method_compare_idempotent(methodOop* a, methodOop* b) { ??? int i = method_compare(a, b); ??? if (i != 0) return i; ??? return ( a < b ? -1 : (a == b ? 0 : 1)); ? } So if the Method name was the same it would preserve the order in the CDS archive.? Not sure why that would have been optimial. Looks good! Coleen On 1/22/19 12:30 AM, Ioi Lam wrote: > Please review this trivial change. > > The "idempotent" parameter to Method::sort_methods() is always false, > so let's just remove it. > > https://bugs.openjdk.java.net/browse/JDK-8217424 > http://cr.openjdk.java.net/~iklam/jdk13/8217424-sort-methods-idempotent-param.v01/ > > > Thanks > - Ioi From coleen.phillimore at oracle.com Tue Jan 22 13:39:37 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 22 Jan 2019 08:39:37 -0500 Subject: RFR: 8194860: Cleanup Semaphore timed-wait time calculations In-Reply-To: <492dfba9-54ca-c09e-c277-0ac2029e4be1@oracle.com> References: <7557e8f2-5622-0317-972d-601b607d6b95@oracle.com> <6b3f3d2f-259f-72db-8e9a-7b24507711ee@oracle.com> <492dfba9-54ca-c09e-c277-0ac2029e4be1@oracle.com> Message-ID: <929e794b-b0cd-1c67-0400-15668f57ece9@oracle.com> Looks good! Coleen On 1/20/19 9:29 PM, David Holmes wrote: > Here's the updated webrev: > > http://cr.openjdk.java.net/~dholmes/8194860/webrev.v2 > > Only changes are in os_posix.cpp: > > - As Coleen requested I statically initialized the various static > variables to simplify the conditional compilation for Solaris and > removed the dynamic initialization to NULL/false. > > - I had a bug (exposed on old OS X versions) where I was using > clock_gettime even though it might not be available. > > Thanks, > David > > On 18/01/2019 8:19 am, David Holmes wrote: >> Hi Coleen, >> >> Thanks for looking at this - though I still have to resolve my OS X >> issue. >> >> On 17/01/2019 11:04 pm, coleen.phillimore at oracle.com wrote: >>> http://cr.openjdk.java.net/~dholmes/8194860/webrev/src/hotspot/os/posix/os_posix.cpp.frames.html >>> >>> >>> For os_init2, I don't see why you have to sprinkle #ifndef SOLARIS. >>> It's just logging, won't the logging be useful in the negative for >>> solaris? >> >> The problem is that regardless of whether the initialization works or >> fails on Solaris, those "attributes" won't get used on Solaris >> anyway, so the logging would be misleading/confusing. So I just >> elided it. >> >>> Can these three statics default to false/NULL above?? Then you can >>> save having to have this conditional as well: >>> >>> +#else >>> +? _use_clock_monotonic_condattr = false; >>> +#endif // !SOLARIS >> >> Yes I should be able to do that (famous last words!). >> >>> Thank you for resolving the differences between to_abstime and >>> solaris unpackTime, which was one of the causes of this mess left by >>> the refactoring. >> >> There's still a lot of mess in the Solaris code. >> >> Thanks again, >> David >> >>> Looks good, with this one suggestion to remove some #ifndef solaris >>> above. >>> Coleen >>> >>> >>> >>> On 1/16/19 5:06 PM, David Holmes wrote: >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8194860 >>>> webrev: http://cr.openjdk.java.net/~dholmes/8194860/webrev/ >>>> >>>> Details in the bug report, but there was duplication in >>>> functionality with regards to timeout conversions/calculations, and >>>> the os_bsd.cpp code was broken due to OSXSemaphore and >>>> PosixSemaphore having different API's. >>>> >>>> Summary: >>>> - expanded the API to take a relative timeout in millis as well as >>>> the existing absolute timeout as a timespec: >>>> >>>> ? // wait until the given absolute time is reached >>>> ? bool timedwait(struct timespec ts); >>>> ? // wait until the given relative time elapses >>>> ? bool timedwait(int64_t millis); >>>> >>>> The millis version simply converts to a timespec and calls the >>>> other version e.g >>>> >>>> bool PosixSemaphore::timedwait(int64_t millis) { >>>> ? struct timespec ts; >>>> ? os::Posix::to_RTC_abstime(&ts, millis); >>>> ? return timedwait(ts); >>>> } >>>> >>>> - added os::Posix::to_RTC_abstime to do the relative to absolute >>>> conversion using the existing routines in os::Posix used for >>>> PlatformEvent etc. >>>> >>>> - changed callsites to use new millis version >>>> >>>> - I had to rearrange the ifndef SOLARIS in os_posix.cpp to expose >>>> previously hidden code to Solaris. It isn't all needed by Solaris >>>> but I chose not to clutter things with too many ifdefs and only >>>> excluded things that really shouldn't be done on Solaris. Also >>>> needed to call os::Posix::init on Solaris. >>>> >>>> Testing (still in progress): >>>> - mach 5 tiers 1 - 3 (Linux, Solaris, OS X, Windows) >>>> - test/jdk/jdk/jfr (as suspend/resume is the user of the semaphore >>>> code) >>>> >>>> Thanks, >>>> David >>> From claes.redestad at oracle.com Tue Jan 22 13:27:41 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 22 Jan 2019 14:27:41 +0100 Subject: RFR: 8217450: Add PackageEntry::locked_lookup_only In-Reply-To: References: <1be87fda-1f82-a88d-90d4-8cce2e972115@oracle.com> <38fa742d-a9ac-9a96-9ac8-63d1595a2898@oracle.com> <24f221c3-a9b7-41b7-99d0-fdf0ff63a792@oracle.com> Message-ID: <3d541cb1-b44a-6f78-a06d-9c5db8c04364@oracle.com> On 2019-01-22 13:27, Aleksey Shipilev wrote: > On 1/22/19 11:53 AM, Claes Redestad wrote: >> http://cr.openjdk.java.net/~redestad/8217450/open.00/ > > *) "this" seems to be the superfluous change and/or bad grammar here? > > 211 // Some of java.base's packages were added early in bootstrapping, this ignore duplicates. Reverted - I was trying to point out that > > *) "Pookup" ;) > > 253 // Pookup Package with loader's package entry table, add it if not found. Wretched typos! > > *) The logic in duplicate finding loop is confusing, because it ignores "pkg" that might be NULL > when package exists? I think it can be clearer if we move "PackageEntry* pkg;" down to actual > intialization at L212. It seems to me the assert at L213 can "just" check the value returned by > locked_lookup_only? Checking "pkg != NULL" is probably makes a tad faster fastdebug build, though. > > 208 // loop through and add any new packages for java.base > 209 PackageEntry* pkg; > 210 for (int x = 0; x < pkg_list->length(); x++) { > 211 // Some of java.base's packages were added early in bootstrapping, this ignore duplicates. > > 212 pkg = package_table->locked_create_entry_or_null(pkg_list->at(x), > ModuleEntryTable::javabase_moduleEntry()); > 213 assert(pkg != NULL || package_table->locked_lookup_only(pkg_list->at(x)) != NULL, > 214 "Unable to create a " JAVA_BASE_NAME " package entry"); > 215 // Unable to have a GrowableArray of TempNewSymbol. Must decrement the refcount of > 216 // the Symbol* that was created above for each package. The refcount was incremented > 217 // by SymbolTable::new_symbol and as well by the PackageEntry creation. > 218 pkg_list->at(x)->decrement_refcount(); > 219 } Might as well remove PackageEntry* pkg and simplify: 211 package_table->locked_create_entry_or_null(pkg_list->at(x), ModuleEntryTable::javabase_moduleEntry()); 212 assert(package_table->locked_lookup_only(pkg_list->at(x)) != NULL, 213 "Unable to create a " JAVA_BASE_NAME " package entry"); http://cr.openjdk.java.net/~redestad/8217450/open.01/ /Claes From erik.helin at oracle.com Tue Jan 22 14:59:40 2019 From: erik.helin at oracle.com (Erik Helin) Date: Tue, 22 Jan 2019 15:59:40 +0100 Subject: RFR: 8213231: ThreadSnapshot::_threadObj can become stale Message-ID: <22302ed6-22d2-1917-ca5c-10dda229ea6b@oracle.com> Hi all, this patch fixes a problem when the oop in ThreadSnapshot::_threadObj can become stale. The issue is that the ThreadSnapshot::oops_do method only gets called when a ThreadSnapshot instance has been registered in a ThreadDumpResult (via the ThreadDumpResult::add_thread_snapshot method). But, in order to register a ThreadSnapshot instance, you must first create it. The problem is that the ThreadSnapshot constructor first sets _threadObj to thread->threadObj() and then further down might call ObjectSynchronizer:: get_lock_owner. The call to ObjectSynchronizer:: get_lock_owner can result in a VM_RevokeBias VM operation being executed. If a GC VM operation already is enqueued, then that GC VM operation will run when the VM_RevokeBias VM operation is executed. That GC VM operation will not update the oop in ThreadSafepoint::_threadObj, because that ThreadSnapshot instance has not yet been registered in any ThreadDumpResult (recall that the ThreadSafepoint is being constructed), so the GC has no way to find it. The oop in ThreadSafepoint::_threadObj will then become dangling which most likely will cause the JVM to get a SIGSEGV some time later. The issue was found when debugging why an instance of java/lang/management/ThreadInfo on the Java heap had a stale pointer in its threadName field. Turns out that the java.lang.Thread instance passed to the ThreadInfo was stale most likely for the reason outlined in the paragraph above. This patch fixes the issue by ensuring that a ThreadSnapshot is always registered in a ThreadDumpResult before the initialization of the ThreadSnapshot is done. This ensures that the GC will always be able to find the oop ThreadSnapshot::_threadObj via ThreadDumpResult::oops_do. Webrev: http://cr.openjdk.java.net/~ehelin/8213231/00/ Issue: https://bugs.openjdk.java.net/browse/JDK-8213231 Testing: - Tier 1, 2 and 3 on Windows, Mac, Linux (all x86-64) - RunThese30M (multiple runs) and RunThese24h on Linux x86-64 (please note that I never managed to reproduce the issue, all analysis was done based on a core file) Thanks, Erik From aoqi at loongson.cn Tue Jan 22 15:10:13 2019 From: aoqi at loongson.cn (Ao Qi) Date: Tue, 22 Jan 2019 23:10:13 +0800 Subject: [TESTBUG] runtime/containers/docker/TestCPUAwareness.java failed in docker not supporting --cpus Message-ID: Hi, --cpus is available in Docker 1.13 and higher [1], so runtime/containers/docker/TestCPUAwareness.java failed in docker which does not support --cpus. Webrev: http://cr.openjdk.java.net/~aoqi/docker/webrev.00/ This patch skips the test if --cpus is not supported. I tested runtime/containers/docker/TestCPUAwareness.java on a Fedora 25 (Docker version 1.12.6, build ae7d637/1.12.6, not supporting --cpus) and Ubuntu 16.04 (Docker version 17.03.2-ce, build f5ec1e2, supporting --cpus) I am not sure if this is a testbug, so I did not file it on JBS. In fact, I am not quite sure what kind of issue can be filed on JBS. Is there any guidance document? Cheers, Ao Qi [1] https://docs.docker.com/config/containers/resource_constraints/#cpu From shade at redhat.com Tue Jan 22 15:11:31 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 22 Jan 2019 16:11:31 +0100 Subject: RFR: 8217450: Add PackageEntry::locked_lookup_only In-Reply-To: <3d541cb1-b44a-6f78-a06d-9c5db8c04364@oracle.com> References: <1be87fda-1f82-a88d-90d4-8cce2e972115@oracle.com> <38fa742d-a9ac-9a96-9ac8-63d1595a2898@oracle.com> <24f221c3-a9b7-41b7-99d0-fdf0ff63a792@oracle.com> <3d541cb1-b44a-6f78-a06d-9c5db8c04364@oracle.com> Message-ID: <2d96832f-5fb0-3ba2-4a94-15df8cc6a25e@redhat.com> On 1/22/19 2:27 PM, Claes Redestad wrote: > Might as well remove PackageEntry* pkg and simplify: > > 211??????? package_table->locked_create_entry_or_null(pkg_list->at(x), > ModuleEntryTable::javabase_moduleEntry()); > 212??????? assert(package_table->locked_lookup_only(pkg_list->at(x)) != NULL, > 213?????????????? "Unable to create a " JAVA_BASE_NAME " package entry"); Mmm. Compilers might complain we do not use the returned value? I think the previous way made a bit more sense, and was a bit faster. Just move the local variable declaration? > http://cr.openjdk.java.net/~redestad/8217450/open.01/ Looks good. -Aleksey From claes.redestad at oracle.com Tue Jan 22 15:21:28 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 22 Jan 2019 16:21:28 +0100 Subject: RFR: 8217450: Add PackageEntry::locked_lookup_only In-Reply-To: <2d96832f-5fb0-3ba2-4a94-15df8cc6a25e@redhat.com> References: <1be87fda-1f82-a88d-90d4-8cce2e972115@oracle.com> <38fa742d-a9ac-9a96-9ac8-63d1595a2898@oracle.com> <24f221c3-a9b7-41b7-99d0-fdf0ff63a792@oracle.com> <3d541cb1-b44a-6f78-a06d-9c5db8c04364@oracle.com> <2d96832f-5fb0-3ba2-4a94-15df8cc6a25e@redhat.com> Message-ID: <973acbfe-8bc2-134a-a5d9-3ae5ff1ec5ab@oracle.com> On 2019-01-22 16:11, Aleksey Shipilev wrote: > Mmm. Compilers might complain we do not use the returned value? I think the previous way made a bit > more sense, and was a bit faster. Just move the local variable declaration? Ok - updated http://cr.openjdk.java.net/~redestad/8217450/open.01/ in place and running some sanity tests before push. Thanks! /Claes From shade at redhat.com Tue Jan 22 15:36:40 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 22 Jan 2019 16:36:40 +0100 Subject: RFR: 8217450: Add PackageEntry::locked_lookup_only In-Reply-To: <973acbfe-8bc2-134a-a5d9-3ae5ff1ec5ab@oracle.com> References: <1be87fda-1f82-a88d-90d4-8cce2e972115@oracle.com> <38fa742d-a9ac-9a96-9ac8-63d1595a2898@oracle.com> <24f221c3-a9b7-41b7-99d0-fdf0ff63a792@oracle.com> <3d541cb1-b44a-6f78-a06d-9c5db8c04364@oracle.com> <2d96832f-5fb0-3ba2-4a94-15df8cc6a25e@redhat.com> <973acbfe-8bc2-134a-a5d9-3ae5ff1ec5ab@oracle.com> Message-ID: <86134365-35c6-2900-1d2f-4e0e7bc91c45@redhat.com> On 1/22/19 4:21 PM, Claes Redestad wrote: > On 2019-01-22 16:11, Aleksey Shipilev wrote: >> Mmm. Compilers might complain we do not use the returned value? I think the previous way made a bit >> more sense, and was a bit faster. Just move the local variable declaration? > > Ok - updated http://cr.openjdk.java.net/~redestad/8217450/open.01/ in > place and running some sanity tests before push. You can coalesce these two lines: 211 PackageEntry* pkg; 212 pkg = package_table->locked_create_entry_or_null(pkg_list->at(x), ModuleEntryTable::javabase_moduleEntry()); ;) -Aleksey From robbin.ehn at oracle.com Tue Jan 22 16:01:49 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Tue, 22 Jan 2019 17:01:49 +0100 Subject: RFR: 8213231: ThreadSnapshot::_threadObj can become stale In-Reply-To: <22302ed6-22d2-1917-ca5c-10dda229ea6b@oracle.com> References: <22302ed6-22d2-1917-ca5c-10dda229ea6b@oracle.com> Message-ID: <5b744708-a97c-3909-ace5-2e4abd237e18@oracle.com> Hi Erik, thanks for fixing, looks good! Thanks, Robbin On 1/22/19 3:59 PM, Erik Helin wrote: > Hi all, > > this patch fixes a problem when the oop in ThreadSnapshot::_threadObj can become > stale. The issue is that the ThreadSnapshot::oops_do method only gets called > when a ThreadSnapshot instance has been registered in a ThreadDumpResult (via > the ThreadDumpResult::add_thread_snapshot method). But, in order to register a > ThreadSnapshot instance, you must first create it. The problem is that the > ThreadSnapshot constructor first sets _threadObj to thread->threadObj() and then > further down might call ObjectSynchronizer:: get_lock_owner. The call to > ObjectSynchronizer:: get_lock_owner can result in a VM_RevokeBias VM operation > being executed. If a GC VM operation already is enqueued, then that GC VM > operation will run when the VM_RevokeBias VM operation is executed. That GC VM > operation will not update the oop in ThreadSafepoint::_threadObj, because that > ThreadSnapshot instance has not yet been registered in any ThreadDumpResult > (recall that the ThreadSafepoint is being constructed), so the GC has no way to > find it. The oop in ThreadSafepoint::_threadObj will then become dangling which > most likely will cause the JVM to get a SIGSEGV some time later. > > The issue was found when debugging why an instance of > java/lang/management/ThreadInfo on the Java heap had a stale pointer in its > threadName field. Turns out that the java.lang.Thread instance passed to the > ThreadInfo was stale most likely for the reason outlined in the paragraph above. > > This patch fixes the issue by ensuring that a ThreadSnapshot is always > registered in a ThreadDumpResult before the initialization of the ThreadSnapshot > is done. This ensures that the GC will always be able to find the oop > ThreadSnapshot::_threadObj via ThreadDumpResult::oops_do. > > Webrev: > http://cr.openjdk.java.net/~ehelin/8213231/00/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8213231 > > Testing: > - Tier 1, 2 and 3 on Windows, Mac, Linux (all x86-64) > - RunThese30M (multiple runs) and RunThese24h on Linux x86-64 > ? (please note that I never managed to reproduce the issue, all analysis was > done based on a core file) > > Thanks, > Erik From coleen.phillimore at oracle.com Tue Jan 22 16:05:54 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 22 Jan 2019 11:05:54 -0500 Subject: Do array class name symbols for unloaded array classes leak deliberately? In-Reply-To: References: Message-ID: Hi Thomas, Yes, this appears to be a bug.? It looks intentional but I can't remember why it would be, and didn't leave a comment. Can you file a bug with your test case? thanks, Coleen On 1/21/19 10:29 AM, Thomas St?fe wrote: > Hi all, > > Looking at ~ClassLoaderData(), I see that we never seem to decrease the > refcount on Klass::_name for ArrayKlass* childs. We do this for > InstanceKlass* childs (via ReleaseKlassClosure::do_klass() -> > InstanceKlass::release_C_heap_structures(k)) but not for ArrayKlass*. > > This causes observable leaks: When I run a small test program where I load > a number of generated classes, instance and array both, and then GC them, > the array class symbol names leak: > > thomas at t450:/shared/projects/openjdk/jdk-jdk/output-fastdebug$ jjjcmd > test3.Example2 VM.symboltable -verbose | grep myclass > 26 65535: [Lmyclass_size_1_number_0; > 26 65535: [Lmyclass_size_1_number_1; > 26 65535: [Lmyclass_size_1_number_2; > > This seems to be always have been the case and it seems deliberate: the > array class name is created as a permanent symbol : > > Klass* ObjArrayKlass::allocate_objArray_klass(ClassLoaderData* loader_data, > int n, Klass* > element_klass, TRAPS) { > > ... > name = SymbolTable::new_permanent_symbol(new_str, CHECK_0); > ... > > } > > Why is that? Why do we remove class name symbols for instance classes, but > leave them for arrays? > > Thanks & Kind Regards, Thomas From lois.foltan at oracle.com Tue Jan 22 16:32:30 2019 From: lois.foltan at oracle.com (Lois Foltan) Date: Tue, 22 Jan 2019 11:32:30 -0500 Subject: RFR: 8217450: Add PackageEntry::locked_lookup_only In-Reply-To: <973acbfe-8bc2-134a-a5d9-3ae5ff1ec5ab@oracle.com> References: <1be87fda-1f82-a88d-90d4-8cce2e972115@oracle.com> <38fa742d-a9ac-9a96-9ac8-63d1595a2898@oracle.com> <24f221c3-a9b7-41b7-99d0-fdf0ff63a792@oracle.com> <3d541cb1-b44a-6f78-a06d-9c5db8c04364@oracle.com> <2d96832f-5fb0-3ba2-4a94-15df8cc6a25e@redhat.com> <973acbfe-8bc2-134a-a5d9-3ae5ff1ec5ab@oracle.com> Message-ID: <189c2201-b61a-b925-52c3-f171bc563a2b@oracle.com> On 1/22/2019 10:21 AM, Claes Redestad wrote: > > > On 2019-01-22 16:11, Aleksey Shipilev wrote: >> Mmm. Compilers might complain we do not use the returned value? I >> think the previous way made a bit >> more sense, and was a bit faster. Just move the local variable >> declaration? > > Ok - updated http://cr.openjdk.java.net/~redestad/8217450/open.01/ in > place and running some sanity tests before push. > > Thanks! > > /Claes Hi Claes, The code change in modules.cpp lines #211-214 does not look correct.? PackageEntry::locked_create_entry_or_null() will return NULL if the package exists and has already been created.? The code at lines #211-214 need a PackageEntry to be successfully returned for java.base packages created during bootstrapping so we can decrement the refcount for it appropriately. Thanks, Lois From thomas.stuefe at gmail.com Tue Jan 22 17:04:58 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 22 Jan 2019 18:04:58 +0100 Subject: Do array class name symbols for unloaded array classes leak deliberately? In-Reply-To: References: Message-ID: Thank you Coleen. I'll open an issue and if time permits post a fix with it. ..Thomas On Tue, Jan 22, 2019 at 5:07 PM wrote: > > Hi Thomas, Yes, this appears to be a bug. It looks intentional but I > can't remember why it would be, and didn't leave a comment. > > Can you file a bug with your test case? > > thanks, > Coleen > > On 1/21/19 10:29 AM, Thomas St?fe wrote: > > Hi all, > > > > Looking at ~ClassLoaderData(), I see that we never seem to decrease the > > refcount on Klass::_name for ArrayKlass* childs. We do this for > > InstanceKlass* childs (via ReleaseKlassClosure::do_klass() -> > > InstanceKlass::release_C_heap_structures(k)) but not for ArrayKlass*. > > > > This causes observable leaks: When I run a small test program where I > load > > a number of generated classes, instance and array both, and then GC them, > > the array class symbol names leak: > > > > thomas at t450:/shared/projects/openjdk/jdk-jdk/output-fastdebug$ jjjcmd > > test3.Example2 VM.symboltable -verbose | grep myclass > > 26 65535: [Lmyclass_size_1_number_0; > > 26 65535: [Lmyclass_size_1_number_1; > > 26 65535: [Lmyclass_size_1_number_2; > > > > This seems to be always have been the case and it seems deliberate: the > > array class name is created as a permanent symbol : > > > > Klass* ObjArrayKlass::allocate_objArray_klass(ClassLoaderData* > loader_data, > > int n, Klass* > > element_klass, TRAPS) { > > > > ... > > name = SymbolTable::new_permanent_symbol(new_str, CHECK_0); > > ... > > > > } > > > > Why is that? Why do we remove class name symbols for instance classes, > but > > leave them for arrays? > > > > Thanks & Kind Regards, Thomas > > From lois.foltan at oracle.com Tue Jan 22 17:10:38 2019 From: lois.foltan at oracle.com (Lois Foltan) Date: Tue, 22 Jan 2019 12:10:38 -0500 Subject: RFR: 8217450: Add PackageEntry::locked_lookup_only In-Reply-To: <189c2201-b61a-b925-52c3-f171bc563a2b@oracle.com> References: <1be87fda-1f82-a88d-90d4-8cce2e972115@oracle.com> <38fa742d-a9ac-9a96-9ac8-63d1595a2898@oracle.com> <24f221c3-a9b7-41b7-99d0-fdf0ff63a792@oracle.com> <3d541cb1-b44a-6f78-a06d-9c5db8c04364@oracle.com> <2d96832f-5fb0-3ba2-4a94-15df8cc6a25e@redhat.com> <973acbfe-8bc2-134a-a5d9-3ae5ff1ec5ab@oracle.com> <189c2201-b61a-b925-52c3-f171bc563a2b@oracle.com> Message-ID: On 1/22/2019 11:32 AM, Lois Foltan wrote: > > > On 1/22/2019 10:21 AM, Claes Redestad wrote: >> >> >> On 2019-01-22 16:11, Aleksey Shipilev wrote: >>> Mmm. Compilers might complain we do not use the returned value? I >>> think the previous way made a bit >>> more sense, and was a bit faster. Just move the local variable >>> declaration? >> >> Ok - updated http://cr.openjdk.java.net/~redestad/8217450/open.01/ in >> place and running some sanity tests before push. >> >> Thanks! >> >> /Claes > > Hi Claes, > > The code change in modules.cpp lines #211-214 does not look correct.? > PackageEntry::locked_create_entry_or_null() will return NULL if the > package exists and has already been created.? The code at lines > #211-214 need a PackageEntry to be successfully returned for java.base > packages created during bootstrapping so we can decrement the refcount > for it appropriately. Just to clarify further.? Obtaining a PackageEntry itself is not a requirement for decrementing the refcount of the Symbol* within the table.? However, the assert at line #213 will trigger if PackageEntry::locked_create_entry_or_null() returns NULL for an existing package.? A PackageEntry can be created for any class loaded, such as java/lang/Class and java/lang/Object for example, during bootstrapping before java.base is defined to the JVM.? These classes are put on a? fixup_module_list so that once the java.base module is defined the JVM can then fixup their java.lang.Module field to be correctly set to java.base. Thanks, Lois > > Thanks, > Lois From gerard.ziemski at oracle.com Tue Jan 22 17:37:05 2019 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Tue, 22 Jan 2019 11:37:05 -0600 Subject: RFR (S) 8216493: VirtualSpaceNodeTest.half_vsn_is_committed_humongous_chunk_is_used_test_vm crashes on local machine Message-ID: <1421EDFD-7F13-4A50-B05D-949D668CE86C@oracle.com> Hi all, Please review this small gtest fix, which fixes ?VirtualSpaceNodeTest.half_vsn_is_committed_humongous_chunk_is_used_test_vm? that used to crash for me locally on both Mac and Linux. The main idea behind this fix is to redo "ChunkManagerRestorer", so that it is more robust in restoring the pre-existing chunks. I?m not sure how it worked before, as to me, it seems that the only case it can currently work, is in a situation where there are no pre-existing chunks. The new implementation uses std::vector to keep track of chunks that need to be restored, which makes it independent of how the underlying chunk list manipulates its contents. References: https://bugs.openjdk.java.net/browse/JDK-8216493 http://cr.openjdk.java.net/~gziemski/8216493_rev1 Passes locally when run on Mac and Linux (used to crash), passes Mach5 hs-tier1,2,3, additional Mach5 hs-tier1,2,3,4,5,6 testing in progress? Cheers From lois.foltan at oracle.com Tue Jan 22 18:37:19 2019 From: lois.foltan at oracle.com (Lois Foltan) Date: Tue, 22 Jan 2019 13:37:19 -0500 Subject: RFR(S): 8217512: Message of LinkageError: use 'class' etc. instead of 'type' In-Reply-To: <5d21becdeb284e47995e682868b1730c@sap.com> References: <5d21becdeb284e47995e682868b1730c@sap.com> Message-ID: Looks good! Lois On 1/22/2019 6:59 AM, Lindenmaier, Goetz wrote: > Hi, > > I would like to change 'type' to 'class' in the following exception text: > (class will be replaced by 'interface' ... etc depending on the actual type). > > old: > > java.lang.LinkageError: loader constraint violation: > when resolving field "_field1" of type pkg.Foo, > the class loader pkg.ClassLoaderForChildGrandFoo @42b2e259 of the current class, pkg.Child, > and the class loader pkg.ClassLoaderForParentFoo @4b55c90f for the field's defining type, pkg.Parent, > have different Class objects for type pkg.Foo > (pkg.Child is in unnamed module of loader pkg.ClassLoaderForChildGrandFoo @42b2e259, parent loader 'app'; > pkg.Parent is in unnamed module of loader pkg.ClassLoaderForParentFoo @4b55c90f, parent loader 'app') > > new: > > java.lang.LinkageError: loader constraint violation: > when resolving field "_field1" of type pkg.Foo, > the class loader pkg.ClassLoaderForChildGrandFoo @42b2e259 of the current class, pkg.Child, > and the class loader pkg.ClassLoaderForParentFoo @4b55c90f for the field's defining class, pkg.Parent, > have different Class objects for type pkg.Foo > (pkg.Child is in unnamed module of loader pkg.ClassLoaderForChildGrandFoo @42b2e259, parent loader 'app'; > pkg.Parent is in unnamed module of loader pkg.ClassLoaderForParentFoo @4b55c90f, parent loader 'app') > > I think this makes the text better understandable: 'type' is used where the declared type of _field1 > is meant. 'class' is used whenever we address the "defining type", i.e. the class that 'has' the > field, is meant. > > Please review: > http://cr.openjdk.java.net/~goetz/wr19/8217512-LinkageE_tiny/01/ > > Best regards, > Goetz. > From claes.redestad at oracle.com Tue Jan 22 19:35:16 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 22 Jan 2019 20:35:16 +0100 Subject: RFR: 8217450: Add PackageEntry::locked_lookup_only In-Reply-To: References: <1be87fda-1f82-a88d-90d4-8cce2e972115@oracle.com> <38fa742d-a9ac-9a96-9ac8-63d1595a2898@oracle.com> <24f221c3-a9b7-41b7-99d0-fdf0ff63a792@oracle.com> <3d541cb1-b44a-6f78-a06d-9c5db8c04364@oracle.com> <2d96832f-5fb0-3ba2-4a94-15df8cc6a25e@redhat.com> <973acbfe-8bc2-134a-a5d9-3ae5ff1ec5ab@oracle.com> <189c2201-b61a-b925-52c3-f171bc563a2b@oracle.com> Message-ID: On 2019-01-22 18:10, Lois Foltan wrote: >>> >>> Ok - updated http://cr.openjdk.java.net/~redestad/8217450/open.01/ in >>> place and running some sanity tests before push. >>> >>> Thanks! >>> >>> /Claes >> >> Hi Claes, >> >> The code change in modules.cpp lines #211-214 does not look correct. >> PackageEntry::locked_create_entry_or_null() will return NULL if the >> package exists and has already been created.? The code at lines >> #211-214 need a PackageEntry to be successfully returned for java.base >> packages created during bootstrapping so we can decrement the refcount >> for it appropriately. > > Just to clarify further.? Obtaining a PackageEntry itself is not a > requirement for decrementing the refcount of the Symbol* within the > table.? However, the assert at line #213 will trigger if > PackageEntry::locked_create_entry_or_null() returns NULL for an existing > package.? A PackageEntry can be created for any class loaded, such as > java/lang/Class and java/lang/Object for example, during bootstrapping > before java.base is defined to the JVM.? These classes are put on a > fixup_module_list so that once the java.base module is defined the JVM > can then fixup their java.lang.Module field to be correctly set to > java.base. Hi Lois, thanks for looking at this! As you say: when locked_create_entry_or_null() returns NULL this *should* be because the package already exists. The assert is thus not asserting if pkg == NULL alone, locked_lookup_only() must also return NULL for the assert to trigger: i.e., I'm checking that a NULL really meant that the package already existed, and not something else, such as a failure to allocate the PackageEntry. I thought this was the purpose of the original assert: getting a NULL back from locked_create_entry_or_null() when we *know* there was no pre- existing package should be impossible (we're holding the lock, so that a NULL must be a failure to allocate or worse). Am I missing something here? /Claes From ioi.lam at oracle.com Tue Jan 22 19:40:26 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Tue, 22 Jan 2019 11:40:26 -0800 Subject: RFR(t) 8217424 Remove the idempotent parameter to Method::sort_methods In-Reply-To: References: Message-ID: Hi Coleen, thanks for the archeological report. I can't really understand what this comment means, either. Also thanks to Aleksey for the review. I'll push the changeset now. BTW, I wonder why we don't do a complete ordering using the method name + signature. That way we can do a simple binary search, and there's no need for the up and down walking in InstanceKlass::find_method_index. Thanks - Ioi On 1/22/19 5:33 AM, coleen.phillimore at oracle.com wrote: > > I checked out of curiousity, this is what it used to do: > > ? // Prevent qsort from reordering a previous valid sort by > ? // considering the address of the methodOops if two methods > ? // would otherwise compare as equal.? Required to preserve > ? // optimal access order in the shared archive.? Slower than > ? // method_compare, only used for shared archive creation. > ? static int method_compare_idempotent(methodOop* a, methodOop* b) { > ??? int i = method_compare(a, b); > ??? if (i != 0) return i; > ??? return ( a < b ? -1 : (a == b ? 0 : 1)); > ? } > > So if the Method name was the same it would preserve the order in the > CDS archive.? Not sure why that would have been optimial. > Looks good! > Coleen > > On 1/22/19 12:30 AM, Ioi Lam wrote: >> Please review this trivial change. >> >> The "idempotent" parameter to Method::sort_methods() is always false, >> so let's just remove it. >> >> https://bugs.openjdk.java.net/browse/JDK-8217424 >> http://cr.openjdk.java.net/~iklam/jdk13/8217424-sort-methods-idempotent-param.v01/ >> >> >> Thanks >> - Ioi > From coleen.phillimore at oracle.com Tue Jan 22 20:17:42 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 22 Jan 2019 15:17:42 -0500 Subject: RFR(t) 8217424 Remove the idempotent parameter to Method::sort_methods In-Reply-To: References: Message-ID: <8c436b86-8dc0-10d8-b7e2-b29636959028@oracle.com> On 1/22/19 2:40 PM, Ioi Lam wrote: > Hi Coleen, thanks for the archeological report. I can't really > understand what this comment means, either. > > Also thanks to Aleksey for the review. I'll push the changeset now. > > BTW, I wonder why we don't do a complete ordering using the method > name + signature. That way we can do a simple binary search, and > there's no need for the up and down walking in > InstanceKlass::find_method_index. I don't know either.? It would help with redefinition in checking for matching methods. Coleen > > Thanks > > - Ioi > > On 1/22/19 5:33 AM, coleen.phillimore at oracle.com wrote: >> >> I checked out of curiousity, this is what it used to do: >> >> ? // Prevent qsort from reordering a previous valid sort by >> ? // considering the address of the methodOops if two methods >> ? // would otherwise compare as equal.? Required to preserve >> ? // optimal access order in the shared archive.? Slower than >> ? // method_compare, only used for shared archive creation. >> ? static int method_compare_idempotent(methodOop* a, methodOop* b) { >> ??? int i = method_compare(a, b); >> ??? if (i != 0) return i; >> ??? return ( a < b ? -1 : (a == b ? 0 : 1)); >> ? } >> >> So if the Method name was the same it would preserve the order in the >> CDS archive.? Not sure why that would have been optimial. >> Looks good! >> Coleen >> >> On 1/22/19 12:30 AM, Ioi Lam wrote: >>> Please review this trivial change. >>> >>> The "idempotent" parameter to Method::sort_methods() is always >>> false, so let's just remove it. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8217424 >>> http://cr.openjdk.java.net/~iklam/jdk13/8217424-sort-methods-idempotent-param.v01/ >>> >>> >>> Thanks >>> - Ioi >> From david.holmes at oracle.com Tue Jan 22 21:00:20 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 23 Jan 2019 07:00:20 +1000 Subject: RFR: 8217450: Add PackageEntry::locked_lookup_only In-Reply-To: <973acbfe-8bc2-134a-a5d9-3ae5ff1ec5ab@oracle.com> References: <1be87fda-1f82-a88d-90d4-8cce2e972115@oracle.com> <38fa742d-a9ac-9a96-9ac8-63d1595a2898@oracle.com> <24f221c3-a9b7-41b7-99d0-fdf0ff63a792@oracle.com> <3d541cb1-b44a-6f78-a06d-9c5db8c04364@oracle.com> <2d96832f-5fb0-3ba2-4a94-15df8cc6a25e@redhat.com> <973acbfe-8bc2-134a-a5d9-3ae5ff1ec5ab@oracle.com> Message-ID: <44a109d1-61c8-df77-ac5e-bcdd15c04ecf@oracle.com> On 23/01/2019 1:21 am, Claes Redestad wrote: > > > On 2019-01-22 16:11, Aleksey Shipilev wrote: >> Mmm. Compilers might complain we do not use the returned value? I >> think the previous way made a bit >> more sense, and was a bit faster. Just move the local variable >> declaration? > > Ok - updated http://cr.openjdk.java.net/~redestad/8217450/open.01/ in > place and running some sanity tests before push. That webrev is now for the regmask changes ??? David > Thanks! > > /Claes From claes.redestad at oracle.com Tue Jan 22 21:04:53 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 22 Jan 2019 22:04:53 +0100 Subject: RFR: 8217450: Add PackageEntry::locked_lookup_only In-Reply-To: <44a109d1-61c8-df77-ac5e-bcdd15c04ecf@oracle.com> References: <1be87fda-1f82-a88d-90d4-8cce2e972115@oracle.com> <38fa742d-a9ac-9a96-9ac8-63d1595a2898@oracle.com> <24f221c3-a9b7-41b7-99d0-fdf0ff63a792@oracle.com> <3d541cb1-b44a-6f78-a06d-9c5db8c04364@oracle.com> <2d96832f-5fb0-3ba2-4a94-15df8cc6a25e@redhat.com> <973acbfe-8bc2-134a-a5d9-3ae5ff1ec5ab@oracle.com> <44a109d1-61c8-df77-ac5e-bcdd15c04ecf@oracle.com> Message-ID: <769b2659-9e5c-7ae8-451d-f1e3125aabab@oracle.com> On 2019-01-22 22:00, David Holmes wrote: > On 23/01/2019 1:21 am, Claes Redestad wrote: >> >> Ok - updated http://cr.openjdk.java.net/~redestad/8217450/open.01/ in >> place and running some sanity tests before push. > > That webrev is now for the regmask changes ??? Oops - fixed. /Claes From david.holmes at oracle.com Tue Jan 22 21:14:27 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 23 Jan 2019 07:14:27 +1000 Subject: RFR: 8217450: Add PackageEntry::locked_lookup_only In-Reply-To: References: <1be87fda-1f82-a88d-90d4-8cce2e972115@oracle.com> <38fa742d-a9ac-9a96-9ac8-63d1595a2898@oracle.com> <24f221c3-a9b7-41b7-99d0-fdf0ff63a792@oracle.com> <3d541cb1-b44a-6f78-a06d-9c5db8c04364@oracle.com> <2d96832f-5fb0-3ba2-4a94-15df8cc6a25e@redhat.com> <973acbfe-8bc2-134a-a5d9-3ae5ff1ec5ab@oracle.com> <189c2201-b61a-b925-52c3-f171bc563a2b@oracle.com> Message-ID: <2b970a60-e096-6811-1751-8fd8d36aba65@oracle.com> On 23/01/2019 5:35 am, Claes Redestad wrote: > > > On 2019-01-22 18:10, Lois Foltan wrote: >>>> >>>> Ok - updated http://cr.openjdk.java.net/~redestad/8217450/open.01/ in >>>> place and running some sanity tests before push. >>>> >>>> Thanks! >>>> >>>> /Claes >>> >>> Hi Claes, >>> >>> The code change in modules.cpp lines #211-214 does not look correct. >>> PackageEntry::locked_create_entry_or_null() will return NULL if the >>> package exists and has already been created.? The code at lines >>> #211-214 need a PackageEntry to be successfully returned for >>> java.base packages created during bootstrapping so we can decrement >>> the refcount for it appropriately. >> >> Just to clarify further.? Obtaining a PackageEntry itself is not a >> requirement for decrementing the refcount of the Symbol* within the >> table.? However, the assert at line #213 will trigger if >> PackageEntry::locked_create_entry_or_null() returns NULL for an >> existing package.? A PackageEntry can be created for any class loaded, >> such as java/lang/Class and java/lang/Object for example, during >> bootstrapping before java.base is defined to the JVM.? These classes >> are put on a fixup_module_list so that once the java.base module is >> defined the JVM can then fixup their java.lang.Module field to be >> correctly set to java.base. > > Hi Lois, > > thanks for looking at this! > > As you say: when locked_create_entry_or_null() returns NULL this > *should* be because the package already exists.? The assert is thus not > asserting if pkg == NULL alone, locked_lookup_only() must also return > NULL for the assert to trigger: i.e., I'm checking that a NULL really > meant that the package already existed, and not something else, such as > a failure to allocate the PackageEntry. I'm in agreement with Claes here. In the original case the assert checks we created a pkg because we are in a path only executed when the package did not pre-exist. In the new code the assert is unconditional so the package may have pre-existed, which is what the second clause is now checking: either we successfully created a pkg, or we didn't because it already existed. David ----- > > I thought this was the purpose of the original assert: getting a NULL > back from locked_create_entry_or_null() when we *know* there was no pre- > existing package should be impossible (we're holding the lock, so that a > NULL must be a failure to allocate or worse). > > Am I missing something here? > > /Claes From david.holmes at oracle.com Tue Jan 22 21:24:24 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 23 Jan 2019 07:24:24 +1000 Subject: [TESTBUG] runtime/containers/docker/TestCPUAwareness.java failed in docker not supporting --cpus In-Reply-To: References: Message-ID: cc'ing Bob as our containers expert ... On 23/01/2019 1:10 am, Ao Qi wrote: > Hi, > > --cpus is available in Docker 1.13 and higher [1], so > runtime/containers/docker/TestCPUAwareness.java failed in docker which > does not support --cpus. > > Webrev: http://cr.openjdk.java.net/~aoqi/docker/webrev.00/ > > This patch skips the test if --cpus is not supported. I tested > runtime/containers/docker/TestCPUAwareness.java on a Fedora 25 (Docker > version 1.12.6, build ae7d637/1.12.6, not supporting --cpus) and > Ubuntu 16.04 (Docker version 17.03.2-ce, build f5ec1e2, supporting > --cpus) The patch causes the test to pass if launching Docker fails for any reason so that is not good. > I am not sure if this is a testbug, so I did not file it on JBS. In > fact, I am not quite sure what kind of issue can be filed on JBS. Is > there any guidance document? Any/all issues can be filed on JBS. You don't need to pre-classify as a testbug, simple create an issue that a test is failing under specific conditions. Whomever works on the bug will then determine whether it is a testbug or product issue or something else. (We don't seem to have any docs on using JBS ...) In this case I'm not sure whether we require a docker version that supports --cpus, and the test should be skipped otherwise. Though ideally this would involve an explicit version check so we don't just pass if the docker process fails. Thanks, David > > Cheers, > Ao Qi > > [1] https://docs.docker.com/config/containers/resource_constraints/#cpu > From david.holmes at oracle.com Tue Jan 22 21:28:49 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 23 Jan 2019 07:28:49 +1000 Subject: RFR: 8194860: Cleanup Semaphore timed-wait time calculations In-Reply-To: <929e794b-b0cd-1c67-0400-15668f57ece9@oracle.com> References: <7557e8f2-5622-0317-972d-601b607d6b95@oracle.com> <6b3f3d2f-259f-72db-8e9a-7b24507711ee@oracle.com> <492dfba9-54ca-c09e-c277-0ac2029e4be1@oracle.com> <929e794b-b0cd-1c67-0400-15668f57ece9@oracle.com> Message-ID: <95afbb21-05e9-5415-24c6-a881d5cf6cf5@oracle.com> Thanks Coleen. David On 22/01/2019 11:39 pm, coleen.phillimore at oracle.com wrote: > Looks good! > Coleen > > On 1/20/19 9:29 PM, David Holmes wrote: >> Here's the updated webrev: >> >> http://cr.openjdk.java.net/~dholmes/8194860/webrev.v2 >> >> Only changes are in os_posix.cpp: >> >> - As Coleen requested I statically initialized the various static >> variables to simplify the conditional compilation for Solaris and >> removed the dynamic initialization to NULL/false. >> >> - I had a bug (exposed on old OS X versions) where I was using >> clock_gettime even though it might not be available. >> >> Thanks, >> David >> >> On 18/01/2019 8:19 am, David Holmes wrote: >>> Hi Coleen, >>> >>> Thanks for looking at this - though I still have to resolve my OS X >>> issue. >>> >>> On 17/01/2019 11:04 pm, coleen.phillimore at oracle.com wrote: >>>> http://cr.openjdk.java.net/~dholmes/8194860/webrev/src/hotspot/os/posix/os_posix.cpp.frames.html >>>> >>>> >>>> For os_init2, I don't see why you have to sprinkle #ifndef SOLARIS. >>>> It's just logging, won't the logging be useful in the negative for >>>> solaris? >>> >>> The problem is that regardless of whether the initialization works or >>> fails on Solaris, those "attributes" won't get used on Solaris >>> anyway, so the logging would be misleading/confusing. So I just >>> elided it. >>> >>>> Can these three statics default to false/NULL above?? Then you can >>>> save having to have this conditional as well: >>>> >>>> +#else >>>> +? _use_clock_monotonic_condattr = false; >>>> +#endif // !SOLARIS >>> >>> Yes I should be able to do that (famous last words!). >>> >>>> Thank you for resolving the differences between to_abstime and >>>> solaris unpackTime, which was one of the causes of this mess left by >>>> the refactoring. >>> >>> There's still a lot of mess in the Solaris code. >>> >>> Thanks again, >>> David >>> >>>> Looks good, with this one suggestion to remove some #ifndef solaris >>>> above. >>>> Coleen >>>> >>>> >>>> >>>> On 1/16/19 5:06 PM, David Holmes wrote: >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8194860 >>>>> webrev: http://cr.openjdk.java.net/~dholmes/8194860/webrev/ >>>>> >>>>> Details in the bug report, but there was duplication in >>>>> functionality with regards to timeout conversions/calculations, and >>>>> the os_bsd.cpp code was broken due to OSXSemaphore and >>>>> PosixSemaphore having different API's. >>>>> >>>>> Summary: >>>>> - expanded the API to take a relative timeout in millis as well as >>>>> the existing absolute timeout as a timespec: >>>>> >>>>> ? // wait until the given absolute time is reached >>>>> ? bool timedwait(struct timespec ts); >>>>> ? // wait until the given relative time elapses >>>>> ? bool timedwait(int64_t millis); >>>>> >>>>> The millis version simply converts to a timespec and calls the >>>>> other version e.g >>>>> >>>>> bool PosixSemaphore::timedwait(int64_t millis) { >>>>> ? struct timespec ts; >>>>> ? os::Posix::to_RTC_abstime(&ts, millis); >>>>> ? return timedwait(ts); >>>>> } >>>>> >>>>> - added os::Posix::to_RTC_abstime to do the relative to absolute >>>>> conversion using the existing routines in os::Posix used for >>>>> PlatformEvent etc. >>>>> >>>>> - changed callsites to use new millis version >>>>> >>>>> - I had to rearrange the ifndef SOLARIS in os_posix.cpp to expose >>>>> previously hidden code to Solaris. It isn't all needed by Solaris >>>>> but I chose not to clutter things with too many ifdefs and only >>>>> excluded things that really shouldn't be done on Solaris. Also >>>>> needed to call os::Posix::init on Solaris. >>>>> >>>>> Testing (still in progress): >>>>> - mach 5 tiers 1 - 3 (Linux, Solaris, OS X, Windows) >>>>> - test/jdk/jdk/jfr (as suspend/resume is the user of the semaphore >>>>> code) >>>>> >>>>> Thanks, >>>>> David >>>> > From daniel.daugherty at oracle.com Tue Jan 22 21:32:33 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 22 Jan 2019 16:32:33 -0500 Subject: RFR: 8213231: ThreadSnapshot::_threadObj can become stale In-Reply-To: <22302ed6-22d2-1917-ca5c-10dda229ea6b@oracle.com> References: <22302ed6-22d2-1917-ca5c-10dda229ea6b@oracle.com> Message-ID: On 1/22/19 9:59 AM, Erik Helin wrote: > Hi all, > > this patch fixes a problem when the oop in ThreadSnapshot::_threadObj > can become stale. The issue is that the ThreadSnapshot::oops_do method > only gets called when a ThreadSnapshot instance has been registered in > a ThreadDumpResult (via the ThreadDumpResult::add_thread_snapshot > method). But, in order to register a ThreadSnapshot instance, you must > first create it. The problem is that the ThreadSnapshot constructor > first sets _threadObj to thread->threadObj() and then further down > might call ObjectSynchronizer:: get_lock_owner. The call to > ObjectSynchronizer:: get_lock_owner can result in a VM_RevokeBias VM > operation being executed. If a GC VM operation already is enqueued, > then that GC VM operation will run when the VM_RevokeBias VM operation > is executed. That GC VM operation will not update the oop in > ThreadSafepoint::_threadObj, because that ThreadSnapshot instance has > not yet been registered in any ThreadDumpResult (recall that the > ThreadSafepoint is being constructed), so the GC has no way to find > it. The oop in ThreadSafepoint::_threadObj will then become dangling > which most likely will cause the JVM to get a SIGSEGV some time later. > > The issue was found when debugging why an instance of > java/lang/management/ThreadInfo on the Java heap had a stale pointer > in its threadName field. Turns out that the java.lang.Thread instance > passed to the ThreadInfo was stale most likely for the reason outlined > in the paragraph above. > > This patch fixes the issue by ensuring that a ThreadSnapshot is always > registered in a ThreadDumpResult before the initialization of the > ThreadSnapshot is done. This ensures that the GC will always be able > to find the oop ThreadSnapshot::_threadObj via ThreadDumpResult::oops_do. > > Webrev: > http://cr.openjdk.java.net/~ehelin/8213231/00/ This one caught my eye since I touched the ThreadSnapshot code in the Thread-SMR project... src/hotspot/share/runtime/vmOperations.cpp ??? No comments. src/hotspot/share/runtime/vmOperations.hpp ??? No comments. src/hotspot/share/services/management.cpp ??? No comments. src/hotspot/share/services/threadService.cpp ??? No comments. src/hotspot/share/services/threadService.hpp ??? No comments. Thumbs up! Dan > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8213231 > > Testing: > - Tier 1, 2 and 3 on Windows, Mac, Linux (all x86-64) > - RunThese30M (multiple runs) and RunThese24h on Linux x86-64 > ? (please note that I never managed to reproduce the issue, all > analysis was done based on a core file) > > Thanks, > Erik > From lois.foltan at oracle.com Tue Jan 22 21:53:27 2019 From: lois.foltan at oracle.com (Lois Foltan) Date: Tue, 22 Jan 2019 16:53:27 -0500 Subject: RFR: 8217450: Add PackageEntry::locked_lookup_only In-Reply-To: References: <1be87fda-1f82-a88d-90d4-8cce2e972115@oracle.com> <38fa742d-a9ac-9a96-9ac8-63d1595a2898@oracle.com> <24f221c3-a9b7-41b7-99d0-fdf0ff63a792@oracle.com> <3d541cb1-b44a-6f78-a06d-9c5db8c04364@oracle.com> <2d96832f-5fb0-3ba2-4a94-15df8cc6a25e@redhat.com> <973acbfe-8bc2-134a-a5d9-3ae5ff1ec5ab@oracle.com> <189c2201-b61a-b925-52c3-f171bc563a2b@oracle.com> Message-ID: <13bcb5fc-c373-03d8-ec4b-2ebd2734e9f2@oracle.com> On 1/22/2019 2:35 PM, Claes Redestad wrote: > > > On 2019-01-22 18:10, Lois Foltan wrote: >>>> >>>> Ok - updated http://cr.openjdk.java.net/~redestad/8217450/open.01/ in >>>> place and running some sanity tests before push. >>>> >>>> Thanks! >>>> >>>> /Claes >>> >>> Hi Claes, >>> >>> The code change in modules.cpp lines #211-214 does not look correct. >>> PackageEntry::locked_create_entry_or_null() will return NULL if the >>> package exists and has already been created.? The code at lines >>> #211-214 need a PackageEntry to be successfully returned for >>> java.base packages created during bootstrapping so we can decrement >>> the refcount for it appropriately. >> >> Just to clarify further.? Obtaining a PackageEntry itself is not a >> requirement for decrementing the refcount of the Symbol* within the >> table.? However, the assert at line #213 will trigger if >> PackageEntry::locked_create_entry_or_null() returns NULL for an >> existing package.? A PackageEntry can be created for any class >> loaded, such as java/lang/Class and java/lang/Object for example, >> during bootstrapping before java.base is defined to the JVM.? These >> classes are put on a fixup_module_list so that once the java.base >> module is defined the JVM can then fixup their java.lang.Module field >> to be correctly set to java.base. > > Hi Lois, > > thanks for looking at this! > > As you say: when locked_create_entry_or_null() returns NULL this > *should* be because the package already exists.? The assert is thus not > asserting if pkg == NULL alone, locked_lookup_only() must also return > NULL for the assert to trigger: i.e., I'm checking that a NULL really > meant that the package already existed, and not something else, such as > a failure to allocate the PackageEntry. > > I thought this was the purpose of the original assert: getting a NULL > back from locked_create_entry_or_null() when we *know* there was no pre- > existing package should be impossible (we're holding the lock, so that a > NULL must be a failure to allocate or worse). > > Am I missing something here? Hi Claes, No you're not!? I wrongfully assumed you had not changed the conditional of the assert and was only checking if pkg != NULL. Thanks for clarifying, I'm ok with the change. Lois > > /Claes From lois.foltan at oracle.com Tue Jan 22 22:00:36 2019 From: lois.foltan at oracle.com (Lois Foltan) Date: Tue, 22 Jan 2019 17:00:36 -0500 Subject: RFR: 8217450: Add PackageEntry::locked_lookup_only In-Reply-To: <13bcb5fc-c373-03d8-ec4b-2ebd2734e9f2@oracle.com> References: <1be87fda-1f82-a88d-90d4-8cce2e972115@oracle.com> <38fa742d-a9ac-9a96-9ac8-63d1595a2898@oracle.com> <24f221c3-a9b7-41b7-99d0-fdf0ff63a792@oracle.com> <3d541cb1-b44a-6f78-a06d-9c5db8c04364@oracle.com> <2d96832f-5fb0-3ba2-4a94-15df8cc6a25e@redhat.com> <973acbfe-8bc2-134a-a5d9-3ae5ff1ec5ab@oracle.com> <189c2201-b61a-b925-52c3-f171bc563a2b@oracle.com> <13bcb5fc-c373-03d8-ec4b-2ebd2734e9f2@oracle.com> Message-ID: <5d64d3e0-737c-969e-9313-2b52e24fea58@oracle.com> On 1/22/2019 4:53 PM, Lois Foltan wrote: > On 1/22/2019 2:35 PM, Claes Redestad wrote: >> >> >> On 2019-01-22 18:10, Lois Foltan wrote: >>>>> >>>>> Ok - updated http://cr.openjdk.java.net/~redestad/8217450/open.01/ in >>>>> place and running some sanity tests before push. >>>>> >>>>> Thanks! >>>>> >>>>> /Claes >>>> >>>> Hi Claes, >>>> >>>> The code change in modules.cpp lines #211-214 does not look >>>> correct. PackageEntry::locked_create_entry_or_null() will return >>>> NULL if the package exists and has already been created.? The code >>>> at lines #211-214 need a PackageEntry to be successfully returned >>>> for java.base packages created during bootstrapping so we can >>>> decrement the refcount for it appropriately. >>> >>> Just to clarify further.? Obtaining a PackageEntry itself is not a >>> requirement for decrementing the refcount of the Symbol* within the >>> table.? However, the assert at line #213 will trigger if >>> PackageEntry::locked_create_entry_or_null() returns NULL for an >>> existing package.? A PackageEntry can be created for any class >>> loaded, such as java/lang/Class and java/lang/Object for example, >>> during bootstrapping before java.base is defined to the JVM.? These >>> classes are put on a fixup_module_list so that once the java.base >>> module is defined the JVM can then fixup their java.lang.Module >>> field to be correctly set to java.base. >> >> Hi Lois, >> >> thanks for looking at this! >> >> As you say: when locked_create_entry_or_null() returns NULL this >> *should* be because the package already exists.? The assert is thus not >> asserting if pkg == NULL alone, locked_lookup_only() must also return >> NULL for the assert to trigger: i.e., I'm checking that a NULL really >> meant that the package already existed, and not something else, such as >> a failure to allocate the PackageEntry. >> >> I thought this was the purpose of the original assert: getting a NULL >> back from locked_create_entry_or_null() when we *know* there was no pre- >> existing package should be impossible (we're holding the lock, so that a >> NULL must be a failure to allocate or worse). >> >> Am I missing something here? > > Hi Claes, > No you're not!? I wrongfully assumed you had not changed the > conditional of the assert and was only checking if pkg != NULL. Thanks > for clarifying, I'm ok with the change. > Lois One more minor note though, you could remove the check in the assert for pkg != NULL, since the locked_lookup_only will always indicate if a PackageEntry was found whether it was already there or just newly created. Lois > >> >> /Claes > From david.holmes at oracle.com Tue Jan 22 22:03:42 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 23 Jan 2019 08:03:42 +1000 Subject: RFR: 8213231: ThreadSnapshot::_threadObj can become stale In-Reply-To: <22302ed6-22d2-1917-ca5c-10dda229ea6b@oracle.com> References: <22302ed6-22d2-1917-ca5c-10dda229ea6b@oracle.com> Message-ID: <48f299a5-0696-e352-a32c-b54d4a3063f6@oracle.com> Hi Erik, Good find! This bug made an interesting read. Makes me wonder how we may have caught this kind of error sooner? Some kind of unhandled oop check? NoSafepointVerifier? On 23/01/2019 12:59 am, Erik Helin wrote: > Hi all, > > this patch fixes a problem when the oop in ThreadSnapshot::_threadObj > can become stale. The issue is that the ThreadSnapshot::oops_do method > only gets called when a ThreadSnapshot instance has been registered in a > ThreadDumpResult (via the ThreadDumpResult::add_thread_snapshot method). > But, in order to register a ThreadSnapshot instance, you must first > create it. The problem is that the ThreadSnapshot constructor first sets > _threadObj to thread->threadObj() and then further down might call > ObjectSynchronizer:: get_lock_owner. The call to ObjectSynchronizer:: > get_lock_owner can result in a VM_RevokeBias VM operation being > executed. If a GC VM operation already is enqueued, then that GC VM > operation will run when the VM_RevokeBias VM operation is executed. That > GC VM operation will not update the oop in ThreadSafepoint::_threadObj, > because that ThreadSnapshot instance has not yet been registered in any > ThreadDumpResult (recall that the ThreadSafepoint is being constructed), > so the GC has no way to find it. The oop in ThreadSafepoint::_threadObj > will then become dangling which most likely will cause the JVM to get a > SIGSEGV some time later. _blocker_object could suffer the same fate, and possibly _blocker_object_owner if there could be other paths leading to a safepoint. > > The issue was found when debugging why an instance of > java/lang/management/ThreadInfo on the Java heap had a stale pointer in > its threadName field. Turns out that the java.lang.Thread instance > passed to the ThreadInfo was stale most likely for the reason outlined > in the paragraph above. > > This patch fixes the issue by ensuring that a ThreadSnapshot is always > registered in a ThreadDumpResult before the initialization of the > ThreadSnapshot is done. This ensures that the GC will always be able to > find the oop ThreadSnapshot::_threadObj via ThreadDumpResult::oops_do. > > Webrev: > http://cr.openjdk.java.net/~ehelin/8213231/00/ Explanation sounded simple enough - actual change was a little harder to follow :) src/hotspot/share/services/threadService.cpp Initially I was concerned about ensuring all oop fields were NULL but I see the ThreadSnapshot constructor handles that. That means some of the NULL setting in initialize is redundant: 854 _stack_trace = NULL; 855 _concurrent_locks = NULL; 856 _next = NULL; 866 _blocker_object = NULL; 867 _blocker_object_owner = NULL; --- src/hotspot/share/services/threadService.hpp The new initialize function doesn't need to be public. + void link_thread_snapshot(ThreadSnapshot* ts); Please follow the existing layout style in that code and shift the method name across to align with others. Thanks, David > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8213231 > > Testing: > - Tier 1, 2 and 3 on Windows, Mac, Linux (all x86-64) > - RunThese30M (multiple runs) and RunThese24h on Linux x86-64 > ? (please note that I never managed to reproduce the issue, all > analysis was done based on a core file) > > Thanks, > Erik From claes.redestad at oracle.com Tue Jan 22 22:18:55 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 22 Jan 2019 23:18:55 +0100 Subject: RFR: 8217450: Add PackageEntry::locked_lookup_only In-Reply-To: <5d64d3e0-737c-969e-9313-2b52e24fea58@oracle.com> References: <1be87fda-1f82-a88d-90d4-8cce2e972115@oracle.com> <38fa742d-a9ac-9a96-9ac8-63d1595a2898@oracle.com> <24f221c3-a9b7-41b7-99d0-fdf0ff63a792@oracle.com> <3d541cb1-b44a-6f78-a06d-9c5db8c04364@oracle.com> <2d96832f-5fb0-3ba2-4a94-15df8cc6a25e@redhat.com> <973acbfe-8bc2-134a-a5d9-3ae5ff1ec5ab@oracle.com> <189c2201-b61a-b925-52c3-f171bc563a2b@oracle.com> <13bcb5fc-c373-03d8-ec4b-2ebd2734e9f2@oracle.com> <5d64d3e0-737c-969e-9313-2b52e24fea58@oracle.com> Message-ID: <81477a3a-5e58-312a-709f-a0a5f97415e1@oracle.com> On 2019-01-22 23:00, Lois Foltan wrote: > One more minor note though, you could remove the check in the assert for > pkg != NULL, since the locked_lookup_only will always indicate if a > PackageEntry was found whether it was already there or just newly created. > Lois Right, we went back and forth on this elsewhere in the review thread and ended up putting the pkg != NULL check back in to not unnecessarily penalize fastdebug build performance. /Claes From aoqi at loongson.cn Wed Jan 23 01:58:34 2019 From: aoqi at loongson.cn (Ao Qi) Date: Wed, 23 Jan 2019 09:58:34 +0800 Subject: [TESTBUG] runtime/containers/docker/TestCPUAwareness.java failed in docker not supporting --cpus In-Reply-To: References: Message-ID: Hi David, On Wed, Jan 23, 2019 at 5:24 AM David Holmes wrote: > > cc'ing Bob as our containers expert ... > > On 23/01/2019 1:10 am, Ao Qi wrote: > > Hi, > > > > --cpus is available in Docker 1.13 and higher [1], so > > runtime/containers/docker/TestCPUAwareness.java failed in docker which > > does not support --cpus. > > > > Webrev: http://cr.openjdk.java.net/~aoqi/docker/webrev.00/ > > > > This patch skips the test if --cpus is not supported. I tested > > runtime/containers/docker/TestCPUAwareness.java on a Fedora 25 (Docker > > version 1.12.6, build ae7d637/1.12.6, not supporting --cpus) and > > Ubuntu 16.04 (Docker version 17.03.2-ce, build f5ec1e2, supporting > > --cpus) > > The patch causes the test to pass if launching Docker fails for any > reason so that is not good. > I tested two versions of docker which does not support --cpus. Their exit values when using --cpus are 2 and 125, and outputs are: flag provided but not defined: --cpus See 'docker run --help'. and unknown flag: --cpus See 'docker run --help'. My initial thought was that the else condition of "output.getExitValue() == 0" should match the condition of "--cpus not supported". Firstly I used output.shouldMatch("docker run --help"), but I am not sure if all the docker version behaves this way when --cpus is not supported and "docker run --help" does not certainly indicate "--cpus not supported", so I removed the else condition. > > I am not sure if this is a testbug, so I did not file it on JBS. In > > fact, I am not quite sure what kind of issue can be filed on JBS. Is > > there any guidance document? > > Any/all issues can be filed on JBS. You don't need to pre-classify as a > testbug, simple create an issue that a test is failing under specific > conditions. Whomever works on the bug will then determine whether it is > a testbug or product issue or something else. (We don't seem to have any > docs on using JBS ...) > What if the issue is not a bug or no body cares the issue? The issue will be open on JBS forever? Thanks for your explanation, and I filed this issue on JBS: https://bugs.openjdk.java.net/browse/JDK-8217597 > In this case I'm not sure whether we require a docker version that > supports --cpus, and the test should be skipped otherwise. Though > ideally this would involve an explicit version check so we don't just > pass if the docker process fails. > > Thanks, > David > > > > > > Cheers, > > Ao Qi > > > > [1] https://docs.docker.com/config/containers/resource_constraints/#cpu > > From david.holmes at oracle.com Wed Jan 23 02:55:21 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 23 Jan 2019 12:55:21 +1000 Subject: [TESTBUG] runtime/containers/docker/TestCPUAwareness.java failed in docker not supporting --cpus In-Reply-To: References: Message-ID: <420d2b08-86df-d591-35c9-d359a8811e9c@oracle.com> On 23/01/2019 11:58 am, Ao Qi wrote: > Hi David, > > On Wed, Jan 23, 2019 at 5:24 AM David Holmes wrote: >> >> cc'ing Bob as our containers expert ... >> >> On 23/01/2019 1:10 am, Ao Qi wrote: >>> Hi, >>> >>> --cpus is available in Docker 1.13 and higher [1], so >>> runtime/containers/docker/TestCPUAwareness.java failed in docker which >>> does not support --cpus. >>> >>> Webrev: http://cr.openjdk.java.net/~aoqi/docker/webrev.00/ >>> >>> This patch skips the test if --cpus is not supported. I tested >>> runtime/containers/docker/TestCPUAwareness.java on a Fedora 25 (Docker >>> version 1.12.6, build ae7d637/1.12.6, not supporting --cpus) and >>> Ubuntu 16.04 (Docker version 17.03.2-ce, build f5ec1e2, supporting >>> --cpus) >> >> The patch causes the test to pass if launching Docker fails for any >> reason so that is not good. >> > > I tested two versions of docker which does not support --cpus. Their > exit values when using --cpus are 2 and 125, and outputs are: > > flag provided but not defined: --cpus > See 'docker run --help'. > > and > > unknown flag: --cpus > See 'docker run --help'. > > My initial thought was that the else condition of > "output.getExitValue() == 0" should match the condition of "--cpus not > supported". Firstly I used output.shouldMatch("docker run --help"), > but I am not sure if all the docker version behaves this way when > --cpus is not supported and "docker run --help" does not certainly > indicate "--cpus not supported", so I removed the else condition. I think we need to try and find a way to clearly identifyt eh failing condition. Is there are "docker --version" we coudl check? >>> I am not sure if this is a testbug, so I did not file it on JBS. In >>> fact, I am not quite sure what kind of issue can be filed on JBS. Is >>> there any guidance document? >> >> Any/all issues can be filed on JBS. You don't need to pre-classify as a >> testbug, simple create an issue that a test is failing under specific >> conditions. Whomever works on the bug will then determine whether it is >> a testbug or product issue or something else. (We don't seem to have any >> docs on using JBS ...) >> > > What if the issue is not a bug or no body cares the issue? The issue > will be open on JBS forever? Possibly :) But each component team performs regular triage of the bugs that get filed and eventually things will be examined enough to see if they are indeed a bug, and if not they will be closed as not an issue. If a bug but low priority it may eventually get closed as "will not fix" just to keep the open bug count down. Cheers, David > Thanks for your explanation, and I filed this issue on JBS: > https://bugs.openjdk.java.net/browse/JDK-8217597 > >> In this case I'm not sure whether we require a docker version that >> supports --cpus, and the test should be skipped otherwise. Though >> ideally this would involve an explicit version check so we don't just >> pass if the docker process fails. >> >> Thanks, >> David >> >> >>> >>> Cheers, >>> Ao Qi >>> >>> [1] https://docs.docker.com/config/containers/resource_constraints/#cpu >>> From aoqi at loongson.cn Wed Jan 23 03:19:35 2019 From: aoqi at loongson.cn (Ao Qi) Date: Wed, 23 Jan 2019 11:19:35 +0800 Subject: [TESTBUG] runtime/containers/docker/TestCPUAwareness.java failed in docker not supporting --cpus In-Reply-To: <420d2b08-86df-d591-35c9-d359a8811e9c@oracle.com> References: <420d2b08-86df-d591-35c9-d359a8811e9c@oracle.com> Message-ID: On Wed, Jan 23, 2019 at 10:55 AM David Holmes wrote: > > On 23/01/2019 11:58 am, Ao Qi wrote: > > Hi David, > > > > On Wed, Jan 23, 2019 at 5:24 AM David Holmes wrote: > >> > >> cc'ing Bob as our containers expert ... > >> > >> On 23/01/2019 1:10 am, Ao Qi wrote: > >>> Hi, > >>> > >>> --cpus is available in Docker 1.13 and higher [1], so > >>> runtime/containers/docker/TestCPUAwareness.java failed in docker which > >>> does not support --cpus. > >>> > >>> Webrev: http://cr.openjdk.java.net/~aoqi/docker/webrev.00/ > >>> > >>> This patch skips the test if --cpus is not supported. I tested > >>> runtime/containers/docker/TestCPUAwareness.java on a Fedora 25 (Docker > >>> version 1.12.6, build ae7d637/1.12.6, not supporting --cpus) and > >>> Ubuntu 16.04 (Docker version 17.03.2-ce, build f5ec1e2, supporting > >>> --cpus) > >> > >> The patch causes the test to pass if launching Docker fails for any > >> reason so that is not good. > >> > > > > I tested two versions of docker which does not support --cpus. Their > > exit values when using --cpus are 2 and 125, and outputs are: > > > > flag provided but not defined: --cpus > > See 'docker run --help'. > > > > and > > > > unknown flag: --cpus > > See 'docker run --help'. > > > > My initial thought was that the else condition of > > "output.getExitValue() == 0" should match the condition of "--cpus not > > supported". Firstly I used output.shouldMatch("docker run --help"), > > but I am not sure if all the docker version behaves this way when > > --cpus is not supported and "docker run --help" does not certainly > > indicate "--cpus not supported", so I removed the else condition. > > I think we need to try and find a way to clearly identifyt eh failing > condition. Is there are "docker --version" we coudl check? > I will do more research. Checking docker version may be one option, and checking whether one option is support by docker may be also one option. I will try them later, while waiting if there are some other opinions :) > >>> I am not sure if this is a testbug, so I did not file it on JBS. In > >>> fact, I am not quite sure what kind of issue can be filed on JBS. Is > >>> there any guidance document? > >> > >> Any/all issues can be filed on JBS. You don't need to pre-classify as a > >> testbug, simple create an issue that a test is failing under specific > >> conditions. Whomever works on the bug will then determine whether it is > >> a testbug or product issue or something else. (We don't seem to have any > >> docs on using JBS ...) > >> > > > > What if the issue is not a bug or no body cares the issue? The issue > > will be open on JBS forever? > > Possibly :) But each component team performs regular triage of the bugs > that get filed and eventually things will be examined enough to see if > they are indeed a bug, and if not they will be closed as not an issue. > If a bug but low priority it may eventually get closed as "will not fix" > just to keep the open bug count down. > I was a little afraid that filing issues that are not bugs or nobody cares would increase the workload of others and frustrate myself, so I was not sure what kind of issue should be filed. Now I basically clear, thanks David. > Cheers, > David > > > Thanks for your explanation, and I filed this issue on JBS: > > https://bugs.openjdk.java.net/browse/JDK-8217597 > > > >> In this case I'm not sure whether we require a docker version that > >> supports --cpus, and the test should be skipped otherwise. Though > >> ideally this would involve an explicit version check so we don't just > >> pass if the docker process fails. > >> > >> Thanks, > >> David > >> > >> > >>> > >>> Cheers, > >>> Ao Qi > >>> > >>> [1] https://docs.docker.com/config/containers/resource_constraints/#cpu > >>> From goetz.lindenmaier at sap.com Wed Jan 23 07:13:07 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 23 Jan 2019 07:13:07 +0000 Subject: RFR(S): 8217512: Message of LinkageError: use 'class' etc. instead of 'type' In-Reply-To: References: <5d21becdeb284e47995e682868b1730c@sap.com> Message-ID: <0e141a44f06847dd837bc724d3e9ea60@sap.com> Hi Lois, thanks for looking at this! Best regards, Goetz. > -----Original Message----- > From: Lois Foltan > Sent: Dienstag, 22. Januar 2019 19:37 > To: Lindenmaier, Goetz ; hotspot-runtime- > dev at openjdk.java.net > Subject: Re: RFR(S): 8217512: Message of LinkageError: use 'class' etc. instead > of 'type' > > Looks good! > Lois > > On 1/22/2019 6:59 AM, Lindenmaier, Goetz wrote: > > Hi, > > > > I would like to change 'type' to 'class' in the following exception text: > > (class will be replaced by 'interface' ... etc depending on the actual type). > > > > old: > > > > java.lang.LinkageError: loader constraint violation: > > when resolving field "_field1" of type pkg.Foo, > > the class loader pkg.ClassLoaderForChildGrandFoo @42b2e259 of the > current class, pkg.Child, > > and the class loader pkg.ClassLoaderForParentFoo @4b55c90f for the field's > defining type, pkg.Parent, > > have different Class objects for type pkg.Foo > > (pkg.Child is in unnamed module of loader > pkg.ClassLoaderForChildGrandFoo @42b2e259, parent loader 'app'; > > pkg.Parent is in unnamed module of loader pkg.ClassLoaderForParentFoo > @4b55c90f, parent loader 'app') > > > > new: > > > > java.lang.LinkageError: loader constraint violation: > > when resolving field "_field1" of type pkg.Foo, > > the class loader pkg.ClassLoaderForChildGrandFoo @42b2e259 of the > current class, pkg.Child, > > and the class loader pkg.ClassLoaderForParentFoo @4b55c90f for the field's > defining class, pkg.Parent, > > have different Class objects for type pkg.Foo > > (pkg.Child is in unnamed module of loader > pkg.ClassLoaderForChildGrandFoo @42b2e259, parent loader 'app'; > > pkg.Parent is in unnamed module of loader pkg.ClassLoaderForParentFoo > @4b55c90f, parent loader 'app') > > > > I think this makes the text better understandable: 'type' is used where the > declared type of _field1 > > is meant. 'class' is used whenever we address the "defining type", i.e. the > class that 'has' the > > field, is meant. > > > > Please review: > > http://cr.openjdk.java.net/~goetz/wr19/8217512-LinkageE_tiny/01/ > > > > Best regards, > > Goetz. > > From magnus.ihse.bursie at oracle.com Wed Jan 23 12:55:58 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 23 Jan 2019 13:55:58 +0100 Subject: RFR(M)(round 2): 8215902: Add support for SoftFloat-3e library In-Reply-To: References: <4497ca084b9f48dbb8f6de1aa35c83653fd7acfb.camel@gmail.com> <7f69fc73-1c10-6b68-d657-c9e758d4bf1d@oracle.com> Message-ID: <3f62f15e-ac5f-94d4-9744-c9cef796a3fa@oracle.com> Hi Jakub, On 2019-01-15 17:31, Jakub Van?k wrote: > Hi Magnus and Erik, > > I have added the link to the repository to README and I have removed > the link to the mailing list thread. I have also recreated the GitHub > repository. Now it is a fork of the mentioned repository with two extra > commits containing README and the build scripts. > > New webrev URL: http://cr.openjdk.java.net/~jakvanek/8215902/webrev.04/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8215902 Sorry for the late reply. This looks very good! Thank you for fixing this, including rebasing the github repo. I'm not sure if you've gotten reviews from the hotspot team for the hotspot source changes, but from a build perspective, this is good to go. /Magnus > > Regards, > > Jakub > > On 2019-01-15 at 15:05 +0100, Magnus Ihse Bursie wrote: >> On 2018-12-25 16:19, Jakub Van?k wrote: >>> Hi, >>> >>> please review this webrev. It is a successor of the softfloat-3 >>> [patch] >>> thread (first email >>> > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-November/031311.html >>> ) >>> >>> Changes since the last patch (v6): >>> >>> - renamed --with-softloat* to --with-sflt* (it is more compact and >>> it >>> corresponds to the old --with-sflt-lib=... option) >>> >>> - license is now obtained via --with-sflt-license switch (so it is >>> not >>> included in OpenJDK source tree) >>> >>> - updated documentation (slight rewording, added the license >>> option) >>> >>> - checks for default --with/--without behavior are in place again >>> (I forgot them when I changed the way the library is detected) >>> >>> - added a simple testcase - I found a disrepancy between softfloat >>> and >>> system function behavior. When a float with bits 0x003FFFFF is >>> added to 0x00000001, the correct result is 0x00400000, but the >>> default software floating point implementation returns >>> 0x00000000. >>> However I'm not sure where to put this test - now it is in >>> test/hotspot/jtreg/compiler/floatingpoint. >>> >>> - comments in code refer to CR 6757269 and newly JDK-8215902 too. >>> >>> I have created a repository with SoftFloat-3e with build >>> configuration >>> specifically for OpenJDK on armel: >>> https://github.com/ev3dev-lang-java/softfloat-openjdk >>> >>> I can add a link to it to the documentation. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8215902 >>> Webrev: http://cr.openjdk.java.net/~jakvanek/8215902/webrev.02/ >> Hi Jakub, >> >> In general this looks good. >> >> Some comments: >> >> I agree with Erik that you can add a link to your github project; >> compiling SoftFloat is outside the scope of the OpenJDK build >> instructions, but it can sure be helpful to lower the bar for users >> wanting to do that. Just one question: any particular reason you >> didn't >> create your github repo by forking the official >> https://github.com/ucb-bar/berkeley-softfloat-3? That way, it would >> have >> been easy for users to see that you were not adding any malicious or >> suspicious code to the original SoftFloat distribution. >> >> On the other hand, I think the link to >> > http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2016-November/000611.html >> >> is unnecessary and just creates clutter in the documentation. Please >> remove it. >> >> /Magnus >>> CI build: >>> https://ci.adoptopenjdk.net/view/ev3dev/job/openjdk12_build_ev3_linux/67/ >>> >>> Cheers, >>> >>> Jakub >>> >> From goetz.lindenmaier at sap.com Wed Jan 23 13:17:41 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 23 Jan 2019 13:17:41 +0000 Subject: RFR(M): 8217621: Verbose ArrayIndexOutOfBoundsException message also in JNI calls. Message-ID: <8df0b8881a6e46968f02e0df2a56a819@sap.com> Hi, Change JDK-8201593: Print array length in ArrayIndexOutOfBoundsException introduced text as "Index 13 out of bounds for length 10" to various AIOOB exceptions thrown in the VM. It omitted the exceptions thrown in jni calls. This change extends the messages to the AIOOB exceptions thrown in Get|SetObjectArrayElement and Get|SetArrayRegion. Before, Get|SetObjectArrayElement printed just the index, Get|SetArrayRegion printed no message. Now the following messages are printed: "Index %d out of bounds for length %d" "length %d is negative" "array region %d..%d out of bounds for length %d" Any advice on capitalizing the first word? It's already handled inconsistently... Please review: http://cr.openjdk.java.net/~goetz/wr19/8217628-AIOOBE_msg_jni/01/ Best regards, Goetz. From erik.helin at oracle.com Wed Jan 23 13:28:10 2019 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 23 Jan 2019 14:28:10 +0100 Subject: RFR: 8213231: ThreadSnapshot::_threadObj can become stale In-Reply-To: <5b744708-a97c-3909-ace5-2e4abd237e18@oracle.com> References: <22302ed6-22d2-1917-ca5c-10dda229ea6b@oracle.com> <5b744708-a97c-3909-ace5-2e4abd237e18@oracle.com> Message-ID: On 1/22/19 5:01 PM, Robbin Ehn wrote: > Hi Erik, thanks for fixing, looks good! Hey Robbin, thanks for reviewing! Erik From erik.helin at oracle.com Wed Jan 23 13:28:42 2019 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 23 Jan 2019 14:28:42 +0100 Subject: RFR: 8213231: ThreadSnapshot::_threadObj can become stale In-Reply-To: References: <22302ed6-22d2-1917-ca5c-10dda229ea6b@oracle.com> Message-ID: <9fc0b7d2-253a-e95e-c484-2f0207da1cd6@oracle.com> On 1/22/19 10:32 PM, Daniel D. Daugherty wrote: > On 1/22/19 9:59 AM, Erik Helin wrote: >> Hi all, >> >> this patch fixes a problem when the oop in ThreadSnapshot::_threadObj >> can become stale. The issue is that the ThreadSnapshot::oops_do method >> only gets called when a ThreadSnapshot instance has been registered in >> a ThreadDumpResult (via the ThreadDumpResult::add_thread_snapshot >> method). But, in order to register a ThreadSnapshot instance, you must >> first create it. The problem is that the ThreadSnapshot constructor >> first sets _threadObj to thread->threadObj() and then further down >> might call ObjectSynchronizer:: get_lock_owner. The call to >> ObjectSynchronizer:: get_lock_owner can result in a VM_RevokeBias VM >> operation being executed. If a GC VM operation already is enqueued, >> then that GC VM operation will run when the VM_RevokeBias VM operation >> is executed. That GC VM operation will not update the oop in >> ThreadSafepoint::_threadObj, because that ThreadSnapshot instance has >> not yet been registered in any ThreadDumpResult (recall that the >> ThreadSafepoint is being constructed), so the GC has no way to find >> it. The oop in ThreadSafepoint::_threadObj will then become dangling >> which most likely will cause the JVM to get a SIGSEGV some time later. >> >> The issue was found when debugging why an instance of >> java/lang/management/ThreadInfo on the Java heap had a stale pointer >> in its threadName field. Turns out that the java.lang.Thread instance >> passed to the ThreadInfo was stale most likely for the reason outlined >> in the paragraph above. >> >> This patch fixes the issue by ensuring that a ThreadSnapshot is always >> registered in a ThreadDumpResult before the initialization of the >> ThreadSnapshot is done. This ensures that the GC will always be able >> to find the oop ThreadSnapshot::_threadObj via ThreadDumpResult::oops_do. >> >> Webrev: >> http://cr.openjdk.java.net/~ehelin/8213231/00/ > > This one caught my eye since I touched the ThreadSnapshot code in the > Thread-SMR project... > > src/hotspot/share/runtime/vmOperations.cpp > ??? No comments. > > src/hotspot/share/runtime/vmOperations.hpp > ??? No comments. > > src/hotspot/share/services/management.cpp > ??? No comments. > > src/hotspot/share/services/threadService.cpp > ??? No comments. > > src/hotspot/share/services/threadService.hpp > ??? No comments. > > Thumbs up! Thanks Dan, appreciate you taking your to review this! Erik > Dan > > >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8213231 >> >> Testing: >> - Tier 1, 2 and 3 on Windows, Mac, Linux (all x86-64) >> - RunThese30M (multiple runs) and RunThese24h on Linux x86-64 >> ? (please note that I never managed to reproduce the issue, all >> analysis was done based on a core file) >> >> Thanks, >> Erik >> > From martin.doerr at sap.com Wed Jan 23 13:53:19 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 23 Jan 2019 13:53:19 +0000 Subject: RFR(M): 8217621: Verbose ArrayIndexOutOfBoundsException message also in JNI calls. In-Reply-To: <8df0b8881a6e46968f02e0df2a56a819@sap.com> References: <8df0b8881a6e46968f02e0df2a56a819@sap.com> Message-ID: Hi G?tz, this looks good to me. Thanks for contributing. Best regards, Martin -----Original Message----- From: hotspot-runtime-dev On Behalf Of Lindenmaier, Goetz Sent: Mittwoch, 23. Januar 2019 14:18 To: hotspot-runtime-dev at openjdk.java.net Subject: [CAUTION] RFR(M): 8217621: Verbose ArrayIndexOutOfBoundsException message also in JNI calls. Hi, Change JDK-8201593: Print array length in ArrayIndexOutOfBoundsException introduced text as "Index 13 out of bounds for length 10" to various AIOOB exceptions thrown in the VM. It omitted the exceptions thrown in jni calls. This change extends the messages to the AIOOB exceptions thrown in Get|SetObjectArrayElement and Get|SetArrayRegion. Before, Get|SetObjectArrayElement printed just the index, Get|SetArrayRegion printed no message. Now the following messages are printed: "Index %d out of bounds for length %d" "length %d is negative" "array region %d..%d out of bounds for length %d" Any advice on capitalizing the first word? It's already handled inconsistently... Please review: http://cr.openjdk.java.net/~goetz/wr19/8217628-AIOOBE_msg_jni/01/ Best regards, Goetz. From erik.helin at oracle.com Wed Jan 23 14:17:28 2019 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 23 Jan 2019 15:17:28 +0100 Subject: RFR: 8213231: ThreadSnapshot::_threadObj can become stale In-Reply-To: <48f299a5-0696-e352-a32c-b54d4a3063f6@oracle.com> References: <22302ed6-22d2-1917-ca5c-10dda229ea6b@oracle.com> <48f299a5-0696-e352-a32c-b54d4a3063f6@oracle.com> Message-ID: <45778e9e-64b2-75cc-5dd8-34a3dd49bba6@oracle.com> On 1/22/19 11:03 PM, David Holmes wrote: > Hi Erik, Hey David, thanks for reviewing! > Good find! This bug made an interesting read. Makes me wonder how we may > have caught this kind of error sooner? Some kind of unhandled oop check? > NoSafepointVerifier? Using -XX:+CheckUnhandledOops (and compiling with -DCHECK_UNHANDLED_OOPS) would have caught the issue, but not exactly the way we want it. If you look in UnhandledOops::clear_unhandled_oops you see that it does not assert if an oop is held over a safepoint, it will overwrite the oopDesc* is with BAD_OOP_ADDR (0xfffffff1). UnhandledOops does this because it is okay to hold on to an oop over a safepoint *if* you remember to update the oop again after the safepoint (this pattern is used at some places in the VM). In the case of this particular bug, we would have crashed in the ThreadInfo constructor because the java.lang.Thread pointer would have had the value BAD_OOP_ADDR. This means that we still would have had to figure out how that java.lang.Thread pointer got the value BAD_OOP_ADDR. This is better than to track down why the ThreadInfo.threadName field was stale, but still usually require quite a bit of archeology in the core file. Adding a NoSafepointVerifier at the top of the constructor for ThreadSnapshot would have helped. But if we would have realized that we needed a NoSafepointVerifier, then it would probably have been better to just use a Handle instead of an oop for the ThreadSnapshot::_threadObj field. In this particular case we could have placed a HandleMark at the top of jmm_GetThreadInfo and jmm_DumpThreads and then used a Handle for ThreadSnapshot::_threadObj. The problem with the Handle approach is that using a Handle for a field in a class requires the instances of that class to always be guarded by a HandleMark. This works fine for ThreadSnapshot as it is used right now, but might not be an applicable technique for all classes (for example a class that does not have a "lexical lifetime" and thus can't be guarded by a HandleMark). I have discussed this a bit with Erik ? and StefanK and we think a more general solution would be to build something on top of OopStorage (and potentially combine that with oopHandle). This way you get a safe and flexible handle for fields in classes. This would probably work for all but the most performance sensitive scenarios (we can probably create some special handles for those cases). > On 23/01/2019 12:59 am, Erik Helin wrote: >> Hi all, >> >> this patch fixes a problem when the oop in ThreadSnapshot::_threadObj >> can become stale. The issue is that the ThreadSnapshot::oops_do method >> only gets called when a ThreadSnapshot instance has been registered in >> a ThreadDumpResult (via the ThreadDumpResult::add_thread_snapshot >> method). But, in order to register a ThreadSnapshot instance, you must >> first create it. The problem is that the ThreadSnapshot constructor >> first sets _threadObj to thread->threadObj() and then further down >> might call ObjectSynchronizer:: get_lock_owner. The call to >> ObjectSynchronizer:: get_lock_owner can result in a VM_RevokeBias VM >> operation being executed. If a GC VM operation already is enqueued, >> then that GC VM operation will run when the VM_RevokeBias VM operation >> is executed. That GC VM operation will not update the oop in >> ThreadSafepoint::_threadObj, because that ThreadSnapshot instance has >> not yet been registered in any ThreadDumpResult (recall that the >> ThreadSafepoint is being constructed), so the GC has no way to find >> it. The oop in ThreadSafepoint::_threadObj will then become dangling >> which most likely will cause the JVM to get a SIGSEGV some time later. > > _blocker_object could suffer the same fate, and possibly > _blocker_object_owner if there could be other paths leading to a safepoint. Yes, that is correct. >> The issue was found when debugging why an instance of >> java/lang/management/ThreadInfo on the Java heap had a stale pointer >> in its threadName field. Turns out that the java.lang.Thread instance >> passed to the ThreadInfo was stale most likely for the reason outlined >> in the paragraph above. >> >> This patch fixes the issue by ensuring that a ThreadSnapshot is always >> registered in a ThreadDumpResult before the initialization of the >> ThreadSnapshot is done. This ensures that the GC will always be able >> to find the oop ThreadSnapshot::_threadObj via ThreadDumpResult::oops_do. >> >> Webrev: >> http://cr.openjdk.java.net/~ehelin/8213231/00/ > > Explanation sounded simple enough - actual change was a little harder to > follow :) > > src/hotspot/share/services/threadService.cpp > > Initially I was concerned about ensuring all oop fields were NULL but I > see the ThreadSnapshot constructor handles that. That means some of the > NULL setting in initialize is redundant: > > ?854?? _stack_trace = NULL; > ?855?? _concurrent_locks = NULL; > ?856?? _next = NULL; > ?866?? _blocker_object = NULL; > ?867?? _blocker_object_owner = NULL; Nice catch, I missed removing those assignments, fixed that in version 01. > src/hotspot/share/services/threadService.hpp > > The new initialize function doesn't need to be public. It does, because it is used from the class ThreadDumpResult, see ThreadDumpResult::add_thread_snapshot. If we want the constructor for ThreadSnapshot and ThreadSnapshot::initialize to be private, then ThreadSnapshot must friend ThreadDumpResult. I did this change for 01, the added benefit is that the only way to create a ThreadSnapshot* is now through ThreadDumpResult::add_thread_snapshot (the ThreadSnapshot constructor is private). This means we have ensured that exactly this bug can't happen again :) > src/hotspot/share/services/threadService.hpp > +?? void link_thread_snapshot(ThreadSnapshot* ts); > > Please follow the existing layout style in that code and shift the > method name across to align with others. I tried to follow the existing style as much as possible, but the code in threadService.hpp contradicts itself in a few places :) See if you prefer the way I indented the function names in 01 (and don't ask me for my opinion on vertically aligning fields and methods in class declarations ;). Please see new webrevs at: - full: http://cr.openjdk.java.net/~ehelin/8213231/01/ - inc: http://cr.openjdk.java.net/~ehelin/8213231/00-01 Thanks, Erik > Thanks, > David > > >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8213231 >> >> Testing: >> - Tier 1, 2 and 3 on Windows, Mac, Linux (all x86-64) >> - RunThese30M (multiple runs) and RunThese24h on Linux x86-64 >> ?? (please note that I never managed to reproduce the issue, all >> analysis was done based on a core file) >> >> Thanks, >> Erik From goetz.lindenmaier at sap.com Wed Jan 23 14:37:52 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 23 Jan 2019 14:37:52 +0000 Subject: RFR(M): 8217628: Verbose ArrayIndexOutOfBoundsException message also in JNI Message-ID: Hi Change JDK-8201593 : Print array length in ArrayIndexOutOfBoundsException introduced text as "Index 13 out of bounds for length 10" to various AIOOB exceptions thrown in the VM. It omitted the exceptions thrown in jni calls. This change extends the messages to the AIOOB exceptions thrown in Get|SetObjectArrayElement and Get|SetArrayRegion. Before, Get|SetObjectArrayElement printed just the index, Get|SetArrayRegion printed no message. Now the following messages are printed: "Index %d out of bounds for length %d" "length %d is negative" "array region %d..%d out of bounds for length %d" Any advice on capitalizing the first word? It's already handled inconsistently... Please review: http://cr.openjdk.java.net/~goetz/wr19/8217628-AIOOBE_msg_jni/01/ Best regards, Goetz. From goetz.lindenmaier at sap.com Wed Jan 23 14:41:25 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 23 Jan 2019 14:41:25 +0000 Subject: RFR(M): 8217621: Verbose ArrayIndexOutOfBoundsException message also in JNI calls. In-Reply-To: <8df0b8881a6e46968f02e0df2a56a819@sap.com> References: <8df0b8881a6e46968f02e0df2a56a819@sap.com> Message-ID: <7ed94809a85140a082505a4cc0fdb722@sap.com> Hi, I mistyped the bugId in the subject. I resent the mail with the proper bug-ID. Best regards, Goetz. > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Mittwoch, 23. Januar 2019 14:18 > To: hotspot-runtime-dev at openjdk.java.net > Subject: RFR(M): 8217621: Verbose ArrayIndexOutOfBoundsException > message also in JNI calls. > > Hi, > > > > Change JDK-8201593 : > Print array length in ArrayIndexOutOfBoundsException > introduced text as "Index 13 out of bounds for length 10" to various AIOOB > exceptions > thrown in the VM. It omitted the exceptions thrown in jni calls. > > This change extends the messages to the AIOOB exceptions thrown in > Get|SetObjectArrayElement and Get|SetArrayRegion. > > Before, Get|SetObjectArrayElement printed just the index, > Get|SetArrayRegion printed no message. > > Now the following messages are printed: > > "Index %d out of bounds for length %d" > "length %d is negative" > "array region %d..%d out of bounds for length %d" > > > > Any advice on capitalizing the first word? It's already > > handled inconsistently... > > > > Please review: > > http://cr.openjdk.java.net/~goetz/wr19/8217628-AIOOBE_msg_jni/01/ > > > > > Best regards, > > Goetz. From martin.doerr at sap.com Wed Jan 23 14:55:44 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 23 Jan 2019 14:55:44 +0000 Subject: RFR(M): 8217628: Verbose ArrayIndexOutOfBoundsException message also in JNI In-Reply-To: References: Message-ID: Hi G?tz, looks still good to me. Or even better with correct bug id in the headline ?? Best regards, Martin -----Original Message----- From: hotspot-runtime-dev On Behalf Of Lindenmaier, Goetz Sent: Mittwoch, 23. Januar 2019 15:38 To: hotspot-runtime-dev at openjdk.java.net Subject: [CAUTION] RFR(M): 8217628: Verbose ArrayIndexOutOfBoundsException message also in JNI Hi Change JDK-8201593 : Print array length in ArrayIndexOutOfBoundsException introduced text as "Index 13 out of bounds for length 10" to various AIOOB exceptions thrown in the VM. It omitted the exceptions thrown in jni calls. This change extends the messages to the AIOOB exceptions thrown in Get|SetObjectArrayElement and Get|SetArrayRegion. Before, Get|SetObjectArrayElement printed just the index, Get|SetArrayRegion printed no message. Now the following messages are printed: "Index %d out of bounds for length %d" "length %d is negative" "array region %d..%d out of bounds for length %d" Any advice on capitalizing the first word? It's already handled inconsistently... Please review: http://cr.openjdk.java.net/~goetz/wr19/8217628-AIOOBE_msg_jni/01/ Best regards, Goetz. From bob.vandette at oracle.com Wed Jan 23 15:37:53 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Wed, 23 Jan 2019 10:37:53 -0500 Subject: [TESTBUG] runtime/containers/docker/TestCPUAwareness.java failed in docker not supporting --cpus In-Reply-To: References: <420d2b08-86df-d591-35c9-d359a8811e9c@oracle.com> Message-ID: <3ABBCD75-1515-4B83-9FC1-18C737FD7C99@oracle.com> Since ?cpus is just a shortcut for of setting both --cpu-period and --cpu-quota?, I?d be ok with removing this test. The tests are intended to test the container/cgroup configuration detection logic and not to verify that docker works correctly. An alternate solution would be to add version detection to the Docker test check in DockerTestUtils.java . We already exec ?docker ps? to see if docker is available and enabled. % docker --version Docker version 17.03.1-ce, build 276fd32 Bob. > On Jan 22, 2019, at 10:19 PM, Ao Qi wrote: > > On Wed, Jan 23, 2019 at 10:55 AM David Holmes wrote: >> >> On 23/01/2019 11:58 am, Ao Qi wrote: >>> Hi David, >>> >>> On Wed, Jan 23, 2019 at 5:24 AM David Holmes wrote: >>>> >>>> cc'ing Bob as our containers expert ... >>>> >>>> On 23/01/2019 1:10 am, Ao Qi wrote: >>>>> Hi, >>>>> >>>>> --cpus is available in Docker 1.13 and higher [1], so >>>>> runtime/containers/docker/TestCPUAwareness.java failed in docker which >>>>> does not support --cpus. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~aoqi/docker/webrev.00/ >>>>> >>>>> This patch skips the test if --cpus is not supported. I tested >>>>> runtime/containers/docker/TestCPUAwareness.java on a Fedora 25 (Docker >>>>> version 1.12.6, build ae7d637/1.12.6, not supporting --cpus) and >>>>> Ubuntu 16.04 (Docker version 17.03.2-ce, build f5ec1e2, supporting >>>>> --cpus) >>>> >>>> The patch causes the test to pass if launching Docker fails for any >>>> reason so that is not good. >>>> >>> >>> I tested two versions of docker which does not support --cpus. Their >>> exit values when using --cpus are 2 and 125, and outputs are: >>> >>> flag provided but not defined: --cpus >>> See 'docker run --help'. >>> >>> and >>> >>> unknown flag: --cpus >>> See 'docker run --help'. >>> >>> My initial thought was that the else condition of >>> "output.getExitValue() == 0" should match the condition of "--cpus not >>> supported". Firstly I used output.shouldMatch("docker run --help"), >>> but I am not sure if all the docker version behaves this way when >>> --cpus is not supported and "docker run --help" does not certainly >>> indicate "--cpus not supported", so I removed the else condition. >> >> I think we need to try and find a way to clearly identifyt eh failing >> condition. Is there are "docker --version" we coudl check? >> > > I will do more research. Checking docker version may be one option, > and checking whether one option is support by docker may be also one > option. I will try them later, while waiting if there are some other > opinions :) > >>>>> I am not sure if this is a testbug, so I did not file it on JBS. In >>>>> fact, I am not quite sure what kind of issue can be filed on JBS. Is >>>>> there any guidance document? >>>> >>>> Any/all issues can be filed on JBS. You don't need to pre-classify as a >>>> testbug, simple create an issue that a test is failing under specific >>>> conditions. Whomever works on the bug will then determine whether it is >>>> a testbug or product issue or something else. (We don't seem to have any >>>> docs on using JBS ...) >>>> >>> >>> What if the issue is not a bug or no body cares the issue? The issue >>> will be open on JBS forever? >> >> Possibly :) But each component team performs regular triage of the bugs >> that get filed and eventually things will be examined enough to see if >> they are indeed a bug, and if not they will be closed as not an issue. >> If a bug but low priority it may eventually get closed as "will not fix" >> just to keep the open bug count down. >> > > I was a little afraid that filing issues that are not bugs or nobody > cares would increase the workload of others and frustrate myself, so I > was not sure what kind of issue should be filed. Now I basically > clear, thanks David. > >> Cheers, >> David >> >>> Thanks for your explanation, and I filed this issue on JBS: >>> https://bugs.openjdk.java.net/browse/JDK-8217597 >>> >>>> In this case I'm not sure whether we require a docker version that >>>> supports --cpus, and the test should be skipped otherwise. Though >>>> ideally this would involve an explicit version check so we don't just >>>> pass if the docker process fails. >>>> >>>> Thanks, >>>> David >>>> >>>> >>>>> >>>>> Cheers, >>>>> Ao Qi >>>>> >>>>> [1] https://docs.docker.com/config/containers/resource_constraints/#cpu >>>>> From daniel.daugherty at oracle.com Wed Jan 23 15:59:27 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 23 Jan 2019 10:59:27 -0500 Subject: RFR: 8213231: ThreadSnapshot::_threadObj can become stale In-Reply-To: <45778e9e-64b2-75cc-5dd8-34a3dd49bba6@oracle.com> References: <22302ed6-22d2-1917-ca5c-10dda229ea6b@oracle.com> <48f299a5-0696-e352-a32c-b54d4a3063f6@oracle.com> <45778e9e-64b2-75cc-5dd8-34a3dd49bba6@oracle.com> Message-ID: <535b2375-9d56-f939-3261-2bc68a5a3f8e@oracle.com> On 1/23/19 9:17 AM, Erik Helin wrote: > On 1/22/19 11:03 PM, David Holmes wrote: >> Hi Erik, > > Hey David, thanks for reviewing! > >> Good find! This bug made an interesting read. Makes me wonder how we >> may have caught this kind of error sooner? Some kind of unhandled oop >> check? NoSafepointVerifier? > > Using -XX:+CheckUnhandledOops (and compiling with > -DCHECK_UNHANDLED_OOPS) would have caught the issue, but not exactly > the way we want it. If you look in UnhandledOops::clear_unhandled_oops > you see that it does not assert if an oop is held over a safepoint, it > will overwrite the oopDesc* is with BAD_OOP_ADDR (0xfffffff1). > UnhandledOops does this because it is okay to hold on to an oop over a > safepoint *if* you remember to update the oop again after the > safepoint (this pattern is used at some places in the VM). > > In the case of this particular bug, we would have crashed in the > ThreadInfo constructor because the java.lang.Thread pointer would have > had the value BAD_OOP_ADDR. This means that we still would have had to > figure out how that java.lang.Thread pointer got the value > BAD_OOP_ADDR. This is better than to track down why the > ThreadInfo.threadName field was stale, but still usually require quite > a bit of archeology in the core file. > > Adding a NoSafepointVerifier at the top of the constructor for > ThreadSnapshot would have helped. But if we would have realized that > we needed a NoSafepointVerifier, then it would probably have been > better to just use a Handle instead of an oop for the > ThreadSnapshot::_threadObj field. In this particular case we could > have placed a HandleMark at the top of jmm_GetThreadInfo and > jmm_DumpThreads and then used a Handle for ThreadSnapshot::_threadObj. > > The problem with the Handle approach is that using a Handle for a > field in a class requires the instances of that class to always be > guarded by a HandleMark. This works fine for ThreadSnapshot as it is > used right now, but might not be an applicable technique for all > classes (for example a class that does not have a "lexical lifetime" > and thus can't be guarded by a HandleMark). > > I have discussed this a bit with Erik ? and StefanK and we think a > more general solution would be to build something on top of OopStorage > (and potentially combine that with oopHandle). This way you get a safe > and flexible handle for fields in classes. This would probably work > for all but the most performance sensitive scenarios (we can probably > create some special handles for those cases). >> On 23/01/2019 12:59 am, Erik Helin wrote: >>> Hi all, >>> >>> this patch fixes a problem when the oop in >>> ThreadSnapshot::_threadObj can become stale. The issue is that the >>> ThreadSnapshot::oops_do method only gets called when a >>> ThreadSnapshot instance has been registered in a ThreadDumpResult >>> (via the ThreadDumpResult::add_thread_snapshot method). But, in >>> order to register a ThreadSnapshot instance, you must first create >>> it. The problem is that the ThreadSnapshot constructor first sets >>> _threadObj to thread->threadObj() and then further down might call >>> ObjectSynchronizer:: get_lock_owner. The call to >>> ObjectSynchronizer:: get_lock_owner can result in a VM_RevokeBias VM >>> operation being executed. If a GC VM operation already is enqueued, >>> then that GC VM operation will run when the VM_RevokeBias VM >>> operation is executed. That GC VM operation will not update the oop >>> in ThreadSafepoint::_threadObj, because that ThreadSnapshot instance >>> has not yet been registered in any ThreadDumpResult (recall that the >>> ThreadSafepoint is being constructed), so the GC has no way to find >>> it. The oop in ThreadSafepoint::_threadObj will then become dangling >>> which most likely will cause the JVM to get a SIGSEGV some time later. >> >> _blocker_object could suffer the same fate, and possibly >> _blocker_object_owner if there could be other paths leading to a >> safepoint. > > Yes, that is correct. >>> The issue was found when debugging why an instance of >>> java/lang/management/ThreadInfo on the Java heap had a stale pointer >>> in its threadName field. Turns out that the java.lang.Thread >>> instance passed to the ThreadInfo was stale most likely for the >>> reason outlined in the paragraph above. >>> >>> This patch fixes the issue by ensuring that a ThreadSnapshot is >>> always registered in a ThreadDumpResult before the initialization of >>> the ThreadSnapshot is done. This ensures that the GC will always be >>> able to find the oop ThreadSnapshot::_threadObj via >>> ThreadDumpResult::oops_do. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~ehelin/8213231/00/ >> >> Explanation sounded simple enough - actual change was a little harder >> to follow :) >> >> src/hotspot/share/services/threadService.cpp >> >> Initially I was concerned about ensuring all oop fields were NULL but >> I see the ThreadSnapshot constructor handles that. That means some of >> the NULL setting in initialize is redundant: >> >> ??854?? _stack_trace = NULL; >> ??855?? _concurrent_locks = NULL; >> ??856?? _next = NULL; >> ??866?? _blocker_object = NULL; >> ??867?? _blocker_object_owner = NULL; > > Nice catch, I missed removing those assignments, fixed that in version > 01. > >> src/hotspot/share/services/threadService.hpp >> >> The new initialize function doesn't need to be public. > > It does, because it is used from the class ThreadDumpResult, see > ThreadDumpResult::add_thread_snapshot. If we want the constructor for > ThreadSnapshot and ThreadSnapshot::initialize to be private, then > ThreadSnapshot must friend ThreadDumpResult. I did this change for 01, > the added benefit is that the only way to create a ThreadSnapshot* is > now through ThreadDumpResult::add_thread_snapshot (the ThreadSnapshot > constructor is private). This means we have ensured that exactly this > bug can't happen again :) > > > src/hotspot/share/services/threadService.hpp >> +?? void link_thread_snapshot(ThreadSnapshot* ts); >> >> Please follow the existing layout style in that code and shift the >> method name across to align with others. > > I tried to follow the existing style as much as possible, but the code > in threadService.hpp contradicts itself in a few places :) See if you > prefer the way I indented the function names in 01 (and don't ask me > for my opinion on vertically aligning fields and methods in class > declarations ;). > > Please see new webrevs at: > - full: http://cr.openjdk.java.net/~ehelin/8213231/01/ > - inc: http://cr.openjdk.java.net/~ehelin/8213231/00-01 src/hotspot/share/services/threadService.cpp ??? No comments. src/hotspot/share/services/threadService.hpp ??? L216: ? // ThreadSnasphot instances should only be created via ??????? Typo: 'ThreadSnasphot' -> 'ThreadSnapshot' Thumbs up. Don't need another webrev for fixing the above typo. Dan > > Thanks, > Erik > >> Thanks, >> David >> >> >>> >>> Issue: >>> https://bugs.openjdk.java.net/browse/JDK-8213231 >>> >>> Testing: >>> - Tier 1, 2 and 3 on Windows, Mac, Linux (all x86-64) >>> - RunThese30M (multiple runs) and RunThese24h on Linux x86-64 >>> ?? (please note that I never managed to reproduce the issue, all >>> analysis was done based on a core file) >>> >>> Thanks, >>> Erik From gunter.haug at sap.com Wed Jan 23 15:59:45 2019 From: gunter.haug at sap.com (Haug, Gunter) Date: Wed, 23 Jan 2019 15:59:45 +0000 Subject: [RFR]: Per thread IO statistics in JFR In-Reply-To: References: <131aa47d-d794-e3d7-ab64-fa5ff3b03952@oracle.com> Message-ID: <089E01D7-D783-4ED7-9624-0273A94774D6@sap.com> Hi Alan, David Here are the results of the measurements. As mentioned before, I had measured some of the standard Java benchmarks and there was no impact. This is probably not surprising to anybody as the overhead up-calls is minuscule in comparison to the calculations that take place and is far below the noise level. A benchmark that is most prone to show the impact the up-calls would do fast (short) IO operations. The fastest operations I could think of were writing to /dev/null and reading from /dev/zero on Linux or macOS. I wrote benchmarks which write/read just one byte one million times in a loop using the jmh framework (https://openjdk.java.net/projects/code-tools/jmh/). The results measured on my mac were all over the place and I moved to a otherwise empty Linux host. Results were more stable there. jmh runs the benchmark multiple times for each invocation and calculates an error within one invocation. It turned out that invocations which had a large error showed poorer performance, obviously because something happened on the host in parallel what degraded performance. I invoked the benchmarks multiple times and decided to discard measurements with an error of more than 0.01. This value is rather random but it was achieved by about one out of four invocations and I think we can get rid of the outliers. It turned out that even with this setup the impact of the up-call is below noise level. In fact, the write benchmark was faster with the up-calls what is not plausible, of course. The read benchmark showed the best and the poorest performance without the up-calls while the results for a JDK with the up-calls (see below for the actual results). As Volker writes, we still think that the overhead of the up-calls is acceptable but it would be possible to introduce a switch which is based on a system property. @Thomas, thanks for your input! I think all your suggestions are well funded. I'll reply in more detail if/when we can alleviate the more general concerns. Best regards, Gunter Write without up-call Mode Cnt Score Error Units thrpt 25 1.867 0.005 ops/s thrpt 25 1.866 0.006 ops/s thrpt 25 1.865 0.004 ops/s thrpt 25 1.860 0.010 ops/s Write with up-call Mode Cnt Score Error Units thrpt 25 1.880 0.010 ops/s thrpt 25 1.884 0.007 ops/s thrpt 25 1.887 0.004 ops/s thrpt 25 1.879 0.010 ops/s Read without up-calls Mode Cnt Score Error Units thrpt 25 2.145 0.008 ops/s thrpt 25 2.145 0.010 ops/s thrpt 25 2.129 0.010 ops/s thrpt 25 2.122 0.009 ops/s Read with up-calls Mode Cnt Score Error Units thrpt 25 2.136 0.007 ops/s thrpt 25 2.132 0.003 ops/s thrpt 25 2.130 0.006 ops/s thrpt 25 2.129 0.009 ops/s ?On 17.01.19, 18:31, "Volker Simonis" wrote: On Thu, Jan 17, 2019 at 1:31 PM Alan Bateman wrote: > > On 17/01/2019 07:23, Thomas St?fe wrote: > > : > > > > Do you object against keeping these counters (which basically boils > > down to Thread::current->stat_structure->counter++)? Or do you even > > object against making upcalls into the jvm? Note that, if deemed > > necessary, we could omit updating the counters unless JFR or our > > extended thread dumps are activated (which are the consumers of the > > counters). > > > > In any case, I would have assumed the costs for upcall + counter > > update to be insignificant compared to the IO calls. We should of > > course measure that. > > > > If you generally object upcalls into the libjvm for > > statistical/monitoring reasons, this would make matters on a number of > > fronts more complicated. For instance, it was discussed extending NMT > > coverage to the JDK - which is already in part reality at > > Unsafe.AllocateMemory - and this would have to be done with upcalls too. > > > There are many issues here that will need write-up and discussion, maybe > a JEP if discussions converge on a proposal to bring into the main line > as this is a significant change with implications for many areas of the > platform. We could certainly create a new JEP for this feature, but in the end it is rather trivial. In fact it can be expressed in a single sentence: instrument all native IO functions to collect the number of read and written bytes. As stated before, the overhead is minimal (Gunter will provide some concrete benchmarks soon) and could even be dropped to ~zero if you really insist on this (e.g. by wrapping all calls by a switch which is based on a system property). But honestly speaking we don't think this is really necessary. I want to stress the fact that this is not a wacky idea Gunter came up with but a feature which we're using for almost 10 years in our SAP JVM. It is running in all our enterprise scenarios without ever having caused any problems. > It also potentially conflicts in direction with some of the > other projects in progress (particularly with Loom trying to re-imagine > threads, do you really want to collect I/O stats on a per thread basis > in the future???). > Who knows about the future, our trace is quite useful today :) You're right that this may change when Loom becomes available and I think we've faced similar problems when people started using ThreadPools more heavily. We've mitigated this with another SAP JVM specific feature (which we havn't contributed yet) that we've called "Thread Annotations". They could be set from user code and our profiler could then split the collected statistics based on these annotations even if they were all collected for the same native thread. I image we can come up with similar solutions for project Loom in the future, once it becomes available. > As regards the points to instrument then I think we have to assume that > much of the native code that is targeted by the current webrev will go > away or change significantly in the future. But that's actually nice! That will eventually shrink the code proposed by this change to a few places and make the costs of supporting it even smaller. And needless to say that SAP is committed to support and maintain this feature once it gets integrated. > We've been on that path for > some time, e.g. the zip area or the prototype to replace the SocketImpl > used for classic networking that eliminates a lot of the native code > touched in that area by the webrev. Once Panama is further along then I > assume we will want to make use of it in the core libraries and at least > initially replace the JNI methods that just wrap syscalls today, and > longer term more significant refactoring. Again, I think this will make our implementation simpler because we would have to instrument fewer places. > My point is that instrumenting > native methods may not be the right approach, instead maybe we should be > look at instrumenting the I/O paths at the java level as that will > likely play better with the VM. We gathered some experience with Java-level instrumentation during the last years (e.g. Dynatrace, Wiley, etc) and it has not always been positive :) The overhead is certainly higher compared to the native instrumentation at C-level. And it can influence especially JIT optimizations in an unpredictable way. Finally the Java instrumentation is version dependent and puts the burden on instrumenting the "right" places (end especially catching all the right places) on the developer / support engineer. You could of course upload this overhead into another, external project like JFR, but supporting that doesn't come for free either. > There is some support for collecting I/O > stats in JFR today and maybe someone working in that area can explain > that a bit more and what the issues are. > As far as I understand, the corresponding JFR events only sample the time spent in the instrumented calls while we do an exact IO statistics with regard to the bytes read and written. > It's impossible to tell from the mail with the webrev what has been > explored and not explored. It feels like early stages in a much large > project that will need a write up of prototypes before a direction can > be proposed. As I wrote before, this is a solution we're using successfully since many years. We're convinced that is is superior to Java-level instrumentation with regards to both, overhead as well as maintainability. > > -Alan From Alan.Bateman at oracle.com Wed Jan 23 16:43:33 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 23 Jan 2019 16:43:33 +0000 Subject: [RFR]: Per thread IO statistics in JFR In-Reply-To: <089E01D7-D783-4ED7-9624-0273A94774D6@sap.com> References: <131aa47d-d794-e3d7-ab64-fa5ff3b03952@oracle.com> <089E01D7-D783-4ED7-9624-0273A94774D6@sap.com> Message-ID: <1666991f-fafb-8845-de5b-894134f9b2a5@oracle.com> On 23/01/2019 15:59, Haug, Gunter wrote: > : > > As Volker writes, we still think that the overhead of the up-calls is acceptable but it would be possible to introduce a switch which is based on a system property. > There are concerns with the approach and patch. The replies from David hint that he also has concerns. I think it would be useful to start out with a summary of what the app server is looking to do with these stats. I think we need to understand if collecting by thread is really the right way to do this as it may not be the right approach in the long term. The granularity is also important as you've instrumented a bunch of places that are surprising as they aren't regular file or socket I/O. I think it's important to understand what prototypes were done with instrumentation at the java level rather than in the native methods. This goes to the maintenance concern. There were suggestions of performance issues but it's not clear if those experiments were recent or from 10 years ago. For the libraries area then we really should be reducing the native code for maintenance and debugging reasons, maybe performance reasons too once we can start to make use of Panama. Finally I think it's important to see how this fits with the instrumentation that JFR and other potential instrumentation of the libraries going forward (native method tracking was mentioned). So overall I think there is a lot to discuss and write-up. -Alan From gerard.ziemski at oracle.com Wed Jan 23 18:49:34 2019 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Wed, 23 Jan 2019 12:49:34 -0600 Subject: RFR 8214821: Remove ConcurrentHashTable::get_copy Message-ID: Hi all, Please review this simple fix that removes ?ConcurrentHashTable::get_copy? API, whose only client was a single gtest. Doing so allows us to remove CONFIG::notfound() That gtest replaces the usage of ?get_copy? API with a local ?cht_get_copy? method, which itself is implemented using "ConcurrentHashTable::get? API I also took this opportunity to clean up a few method names in the test a bit. References: https://bugs.openjdk.java.net/browse/JDK-8214821 http://cr.openjdk.java.net/~gziemski/8214821_rev1 Passes gtest locally on Mac and passes Mach5 hs-tier1,2,3,4,5,6 Cheers From igor.ignatyev at oracle.com Wed Jan 23 19:33:46 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 23 Jan 2019 11:33:46 -0800 Subject: RFR (S) 8216493: VirtualSpaceNodeTest.half_vsn_is_committed_humongous_chunk_is_used_test_vm crashes on local machine In-Reply-To: <1421EDFD-7F13-4A50-B05D-949D668CE86C@oracle.com> References: <1421EDFD-7F13-4A50-B05D-949D668CE86C@oracle.com> Message-ID: <400C7E72-64F5-4790-A68F-A7606ABC94BC@oracle.com> Hi Gerard, the fix looks reasonable to me, one small editorial nit: include of standard headers should go before custom headers, so could you please move 'include ' to L#25 (as precompiled.hpp still must be 1st include). PS I don't think you need to run 1-6 tiers to test this change, as the vast majority of the testing in these tiers do not include gtest tests. Thanks, -- Igor > On Jan 22, 2019, at 9:37 AM, Gerard Ziemski wrote: > > Hi all, > > Please review this small gtest fix, which fixes ?VirtualSpaceNodeTest.half_vsn_is_committed_humongous_chunk_is_used_test_vm? that used to crash for me locally on both Mac and Linux. > > The main idea behind this fix is to redo "ChunkManagerRestorer", so that it is more robust in restoring the pre-existing chunks. I?m not sure how it worked before, as to me, it seems that the only case it can currently work, is in a situation where there are no pre-existing chunks. The new implementation uses std::vector to keep track of chunks that need to be restored, which makes it independent of how the underlying chunk list manipulates its contents. > > References: > > https://bugs.openjdk.java.net/browse/JDK-8216493 > http://cr.openjdk.java.net/~gziemski/8216493_rev1 > > Passes locally when run on Mac and Linux (used to crash), passes Mach5 hs-tier1,2,3, additional Mach5 hs-tier1,2,3,4,5,6 testing in progress? > > > Cheers > From gerard.ziemski at oracle.com Wed Jan 23 19:43:42 2019 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Wed, 23 Jan 2019 13:43:42 -0600 Subject: RFR (S) 8216493: VirtualSpaceNodeTest.half_vsn_is_committed_humongous_chunk_is_used_test_vm crashes on local machine In-Reply-To: <400C7E72-64F5-4790-A68F-A7606ABC94BC@oracle.com> References: <1421EDFD-7F13-4A50-B05D-949D668CE86C@oracle.com> <400C7E72-64F5-4790-A68F-A7606ABC94BC@oracle.com> Message-ID: Thank you Igor! > On Jan 23, 2019, at 1:33 PM, Igor Ignatyev wrote: > > Hi Gerard, > > the fix looks reasonable to me, one small editorial nit: include of standard headers should go before custom headers, so could you please move 'include ' to L#25 (as precompiled.hpp still must be 1st include). Will do. > > PS I don't think you need to run 1-6 tiers to test this change, as the vast majority of the testing in these tiers do not include gtest tests. I had no idea which tier this test was in, so I just thought it would be safe to do 1-6 tiers. cheers > > Thanks, > -- Igor > >> On Jan 22, 2019, at 9:37 AM, Gerard Ziemski wrote: >> >> Hi all, >> >> Please review this small gtest fix, which fixes ?VirtualSpaceNodeTest.half_vsn_is_committed_humongous_chunk_is_used_test_vm? that used to crash for me locally on both Mac and Linux. >> >> The main idea behind this fix is to redo "ChunkManagerRestorer", so that it is more robust in restoring the pre-existing chunks. I?m not sure how it worked before, as to me, it seems that the only case it can currently work, is in a situation where there are no pre-existing chunks. The new implementation uses std::vector to keep track of chunks that need to be restored, which makes it independent of how the underlying chunk list manipulates its contents. >> >> References: >> >> https://bugs.openjdk.java.net/browse/JDK-8216493 >> http://cr.openjdk.java.net/~gziemski/8216493_rev1 >> >> Passes locally when run on Mac and Linux (used to crash), passes Mach5 hs-tier1,2,3, additional Mach5 hs-tier1,2,3,4,5,6 testing in progress? >> >> >> Cheers >> > From daniel.daugherty at oracle.com Wed Jan 23 20:07:05 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 23 Jan 2019 15:07:05 -0500 Subject: RFR(S): 8217658 baseline_cleanups from Async Monitor Deflation project Message-ID: Greetings, I have a (S)mall patch extracted from the Async Monitor Deflation project that is ready for code review. The short version of what this patch is about: ? ? This sub-task captures updates to the baseline code that are not ? ? directly related to Async Monitor Deflation. The details are in the bug report: ??? JDK-8217658 baseline_cleanups from Async Monitor Deflation project ??? https://bugs.openjdk.java.net/browse/JDK-8217658 Here's the webrev: ??? http://cr.openjdk.java.net/~dcubed/8217658-webrev/0-for-jdk13/ This patch along with the other two patches for Async Monitor Deflation project have been through Mach5 builds-tier1,hs-tier1,jdk-tier1,hs-tier2,hs-tier3 testing and I'm currently running my stress testing kits on my Linux-X64 and Solaris-X64 servers. Thanks, in advance, for any questions, comments or suggestions. Dan From daniel.daugherty at oracle.com Wed Jan 23 20:16:49 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 23 Jan 2019 15:16:49 -0500 Subject: RFR(S/M): 8217659 monitor_logging updates from Async Monitor Deflation project Message-ID: Greetings, I have a (S)mall/(M)edium patch extracted from the Async Monitor Deflation project that is ready for code review. I'm calling this a (S)mall/(M)edium because the logic changes are (S)mall, but the logging code is tedious and there's a bunch of it in audit_and_print_stats() so (M)edium. The short version of what this patch is about: ??? This sub-task captures updates and additions to the ??? baseline monitor logging code. The details are in the bug report: ??? JDK-8217659 monitor_logging updates from Async Monitor Deflation project ??? https://bugs.openjdk.java.net/browse/JDK-8217659 Here's the webrev: ??? http://cr.openjdk.java.net/~dcubed/8217659-webrev/0-for-jdk13/ This patch along with the other two patches for Async Monitor Deflation project have been through Mach5 builds-tier1,hs-tier1,jdk-tier1,hs-tier2,hs-tier3 testing and I'm currently running my stress testing kits on my Linux-X64 and Solaris-X64 servers. I have been actively using this new logging code while debugging my port of the Async Monitor Deflation project code. Thanks, in advance, for any questions, comments or suggestions. Dan From harold.seigel at oracle.com Wed Jan 23 21:28:02 2019 From: harold.seigel at oracle.com (Harold Seigel) Date: Wed, 23 Jan 2019 16:28:02 -0500 Subject: RFR 8217660: Refactor module related locked_create_entry_or_null() functions Message-ID: Hi, Please review this change for enhancement JDK-8217660.? The change does the following: * Replaces PackageEntryTable::locked_create_entry_or_null() with locked_create_entry_if_not_exist(), which has no return value. * Adds a PackageEntryTable::locked_create_entry() function for callers who know the package entry cannot already exist. * Replaces ModuleEntryTable::locked_create_entry_or_null() with locked_create_entry(). * Adds a call to lookup_only(module_symbol) to check if a moduleEntry exists, instead of depending on locked_create_entry_or_null() returning null. Open Webrev: http://cr.openjdk.java.net/~hseigel/bug_8217660/webrev/index.html JBS Bug:? https://bugs.openjdk.java.net/browse/JDK-8217660 The fix was regression tested by running Mach5 tiers 1 and 2 tests and builds on Linux-x64, Windows, and Mac OS X, Mach5 tiers 3 -5 on Linux-x64, and by running JCK-12 Lang and VM tests on Linux-x64. Thanks, Harold From david.holmes at oracle.com Thu Jan 24 00:24:21 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 24 Jan 2019 10:24:21 +1000 Subject: RFR: 8213231: ThreadSnapshot::_threadObj can become stale In-Reply-To: <45778e9e-64b2-75cc-5dd8-34a3dd49bba6@oracle.com> References: <22302ed6-22d2-1917-ca5c-10dda229ea6b@oracle.com> <48f299a5-0696-e352-a32c-b54d4a3063f6@oracle.com> <45778e9e-64b2-75cc-5dd8-34a3dd49bba6@oracle.com> Message-ID: Thanks for the updates Erik - they generally look fine. One typo in the header file: // ThreadSnasphot instances should only be created via Snasphot -> Snapshot Cheers, David On 24/01/2019 12:17 am, Erik Helin wrote: > On 1/22/19 11:03 PM, David Holmes wrote: >> Hi Erik, > > Hey David, thanks for reviewing! > >> Good find! This bug made an interesting read. Makes me wonder how we >> may have caught this kind of error sooner? Some kind of unhandled oop >> check? NoSafepointVerifier? > > Using -XX:+CheckUnhandledOops (and compiling with > -DCHECK_UNHANDLED_OOPS) would have caught the issue, but not exactly the > way we want it. If you look in UnhandledOops::clear_unhandled_oops you > see that it does not assert if an oop is held over a safepoint, it will > overwrite the oopDesc* is with BAD_OOP_ADDR (0xfffffff1). UnhandledOops > does this because it is okay to hold on to an oop over a safepoint *if* > you remember to update the oop again after the safepoint (this pattern > is used at some places in the VM). > > In the case of this particular bug, we would have crashed in the > ThreadInfo constructor because the java.lang.Thread pointer would have > had the value BAD_OOP_ADDR. This means that we still would have had to > figure out how that java.lang.Thread pointer got the value BAD_OOP_ADDR. > This is better than to track down why the ThreadInfo.threadName field > was stale, but still usually require quite a bit of archeology in the > core file. > > Adding a NoSafepointVerifier at the top of the constructor for > ThreadSnapshot would have helped. But if we would have realized that we > needed a NoSafepointVerifier, then it would probably have been better to > just use a Handle instead of an oop for the ThreadSnapshot::_threadObj > field. In this particular case we could have placed a HandleMark at the > top of jmm_GetThreadInfo and jmm_DumpThreads and then used a Handle for > ThreadSnapshot::_threadObj. > > The problem with the Handle approach is that using a Handle for a field > in a class requires the instances of that class to always be guarded by > a HandleMark. This works fine for ThreadSnapshot as it is used right > now, but might not be an applicable technique for all classes (for > example a class that does not have a "lexical lifetime" and thus can't > be guarded by a HandleMark). > > I have discussed this a bit with Erik ? and StefanK and we think a more > general solution would be to build something on top of OopStorage (and > potentially combine that with oopHandle). This way you get a safe and > flexible handle for fields in classes. This would probably work for all > but the most performance sensitive scenarios (we can probably create > some special handles for those cases). >> On 23/01/2019 12:59 am, Erik Helin wrote: >>> Hi all, >>> >>> this patch fixes a problem when the oop in ThreadSnapshot::_threadObj >>> can become stale. The issue is that the ThreadSnapshot::oops_do >>> method only gets called when a ThreadSnapshot instance has been >>> registered in a ThreadDumpResult (via the >>> ThreadDumpResult::add_thread_snapshot method). But, in order to >>> register a ThreadSnapshot instance, you must first create it. The >>> problem is that the ThreadSnapshot constructor first sets _threadObj >>> to thread->threadObj() and then further down might call >>> ObjectSynchronizer:: get_lock_owner. The call to ObjectSynchronizer:: >>> get_lock_owner can result in a VM_RevokeBias VM operation being >>> executed. If a GC VM operation already is enqueued, then that GC VM >>> operation will run when the VM_RevokeBias VM operation is executed. >>> That GC VM operation will not update the oop in >>> ThreadSafepoint::_threadObj, because that ThreadSnapshot instance has >>> not yet been registered in any ThreadDumpResult (recall that the >>> ThreadSafepoint is being constructed), so the GC has no way to find >>> it. The oop in ThreadSafepoint::_threadObj will then become dangling >>> which most likely will cause the JVM to get a SIGSEGV some time later. >> >> _blocker_object could suffer the same fate, and possibly >> _blocker_object_owner if there could be other paths leading to a >> safepoint. > > Yes, that is correct. >>> The issue was found when debugging why an instance of >>> java/lang/management/ThreadInfo on the Java heap had a stale pointer >>> in its threadName field. Turns out that the java.lang.Thread instance >>> passed to the ThreadInfo was stale most likely for the reason >>> outlined in the paragraph above. >>> >>> This patch fixes the issue by ensuring that a ThreadSnapshot is >>> always registered in a ThreadDumpResult before the initialization of >>> the ThreadSnapshot is done. This ensures that the GC will always be >>> able to find the oop ThreadSnapshot::_threadObj via >>> ThreadDumpResult::oops_do. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~ehelin/8213231/00/ >> >> Explanation sounded simple enough - actual change was a little harder >> to follow :) >> >> src/hotspot/share/services/threadService.cpp >> >> Initially I was concerned about ensuring all oop fields were NULL but >> I see the ThreadSnapshot constructor handles that. That means some of >> the NULL setting in initialize is redundant: >> >> ??854?? _stack_trace = NULL; >> ??855?? _concurrent_locks = NULL; >> ??856?? _next = NULL; >> ??866?? _blocker_object = NULL; >> ??867?? _blocker_object_owner = NULL; > > Nice catch, I missed removing those assignments, fixed that in version 01. > >> src/hotspot/share/services/threadService.hpp >> >> The new initialize function doesn't need to be public. > > It does, because it is used from the class ThreadDumpResult, see > ThreadDumpResult::add_thread_snapshot. If we want the constructor for > ThreadSnapshot and ThreadSnapshot::initialize to be private, then > ThreadSnapshot must friend ThreadDumpResult. I did this change for 01, > the added benefit is that the only way to create a ThreadSnapshot* is > now through ThreadDumpResult::add_thread_snapshot (the ThreadSnapshot > constructor is private). This means we have ensured that exactly this > bug can't happen again :) > > > src/hotspot/share/services/threadService.hpp >> +?? void link_thread_snapshot(ThreadSnapshot* ts); >> >> Please follow the existing layout style in that code and shift the >> method name across to align with others. > > I tried to follow the existing style as much as possible, but the code > in threadService.hpp contradicts itself in a few places :) See if you > prefer the way I indented the function names in 01 (and don't ask me for > my opinion on vertically aligning fields and methods in class > declarations ;). > > Please see new webrevs at: > - full: http://cr.openjdk.java.net/~ehelin/8213231/01/ > - inc: http://cr.openjdk.java.net/~ehelin/8213231/00-01 > > Thanks, > Erik > >> Thanks, >> David >> >> >>> >>> Issue: >>> https://bugs.openjdk.java.net/browse/JDK-8213231 >>> >>> Testing: >>> - Tier 1, 2 and 3 on Windows, Mac, Linux (all x86-64) >>> - RunThese30M (multiple runs) and RunThese24h on Linux x86-64 >>> ?? (please note that I never managed to reproduce the issue, all >>> analysis was done based on a core file) >>> >>> Thanks, >>> Erik From david.holmes at oracle.com Thu Jan 24 00:40:28 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 24 Jan 2019 10:40:28 +1000 Subject: RFR(M): 8217628: Verbose ArrayIndexOutOfBoundsException message also in JNI In-Reply-To: References: Message-ID: <8b1ed15e-2569-ffad-79aa-95d29340523c@oracle.com> Hi Goetz, On 24/01/2019 12:37 am, Lindenmaier, Goetz wrote: > Hi > > Change JDK-8201593 : Print array length in ArrayIndexOutOfBoundsException > introduced text as "Index 13 out of bounds for length 10" to various AIOOB exceptions > thrown in the VM. It omitted the exceptions thrown in jni calls. > > This change extends the messages to the AIOOB exceptions thrown in > Get|SetObjectArrayElement and Get|SetArrayRegion. > > Before, Get|SetObjectArrayElement printed just the index, > Get|SetArrayRegion printed no message. > > Now the following messages are printed: > "Index %d out of bounds for length %d" > "length %d is negative" > "array region %d..%d out of bounds for length %d" > > Any advice on capitalizing the first word? It's already > handled inconsistently... I'd suggest capitalizing. > Please review: > http://cr.openjdk.java.net/~goetz/wr19/8217628-AIOOBE_msg_jni/01/ Could I ask that you factor the region check into a small function so we don't duplicate the logic please. It would take TRAPS and would be called with a CHECK. Thanks, David ----- > > > Best regards, > > Goetz. > From david.holmes at oracle.com Thu Jan 24 04:18:18 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 24 Jan 2019 14:18:18 +1000 Subject: RFR(S): 8217658 baseline_cleanups from Async Monitor Deflation project In-Reply-To: References: Message-ID: <653c2aaf-64d5-edbb-d7d7-4f88f7da1c63@oracle.com> Hi Dan, This all seems fine. Some comments below. One suggested addition to your cleanup :) ./share/runtime/basicLock.cpp // [RGV] The next line appears to do nothing! intptr_t dh = (intptr_t) displaced_header(); dest->set_displaced_header(displaced_header()); On 24/01/2019 6:07 am, Daniel D. Daugherty wrote: > Greetings, > > I have a (S)mall patch extracted from the Async Monitor Deflation > project that is ready for code review. > > The short version of what this patch is about: > > ? ? This sub-task captures updates to the baseline code that are not > ? ? directly related to Async Monitor Deflation. > > The details are in the bug report: > > ??? JDK-8217658 baseline_cleanups from Async Monitor Deflation project > ??? https://bugs.openjdk.java.net/browse/JDK-8217658 > > Here's the webrev: > > ??? http://cr.openjdk.java.net/~dcubed/8217658-webrev/0-for-jdk13/ To quote your main semantic changes from the bug report: > - add missing "else" to logical if-else-statement in > ObjectSynchronizer::get_lock_owner() Okay - the two conditions are mutually exclusive. > - guarantee that header() is NULL when > ObjectSynchronizer::omRelease() is called > - Replace a set_owner(NULL) call with a set_header(NULL) > call in the "CASE: neutral" part of ObjectSynchronizer::inflate() > when the object->cas_set_mark() fails. This is a rare race. These seem okay but did get me thinking about the different roles of ObjectMonitor::Recycle() and ObjectMonitor::clear() and the individual clearing of fields! I find it all somewhat confusing - in particular why clear() asserts that _header != NULL ! Some explanatory comments on those methods would be appreciated at some point during this project. Thanks, David ----- > > This patch along with the other two patches for Async Monitor Deflation > project have been through Mach5 > builds-tier1,hs-tier1,jdk-tier1,hs-tier2,hs-tier3 > testing and I'm currently running my stress testing kits on my Linux-X64 > and Solaris-X64 servers. > > Thanks, in advance, for any questions, comments or suggestions. > > Dan > From david.holmes at oracle.com Thu Jan 24 07:41:20 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 24 Jan 2019 17:41:20 +1000 Subject: RFR(S/M): 8217659 monitor_logging updates from Async Monitor Deflation project In-Reply-To: References: Message-ID: <0b24c9d7-9f1c-6c62-9a08-66d3ecaf545c@oracle.com> Hi Dan, This looks generally fine too. ObjectSynchronizer::audit_and_print_stats is pretty hard to digest! I think the logging can be simpler if you extract the log stream rather than repeating "log_info(monitorinflation)" so many times. + // I'm not sure why the baseline monitorinflation logic only + // issues logging mesgs for instance objects. + // if (obj->is_instance()) { This needs to be resolved. If the alternative to being an instance is being an array, then I think we should be logging for those too (that might actually catch use of the class initialization monitors). When we have different Info versus Debug logging eg: ! if (deflated_count != 0) { ! if (log_is_enabled(Info, monitorinflation)) { ! log_info(monitorinflation)("deflating global idle monitors, %3.7f secs, %d monitors", timer.seconds(), deflated_count); ! } ! } else { ! if (log_is_enabled(Debug, monitorinflation)) { ! log_debug(monitorinflation)("deflating global idle monitors, %3.7f secs, 0 monitors", timer.seconds()); ! } ! } is it possible to rewrite that as: if (log_is_enabled( deflated_count != 0 ? Info : Debug, monitorinflation)) { ! log_info(monitorinflation)("deflating global idle monitors, %3.7f secs, %d monitors", timer.seconds(), deflated_count); ! } or does the logging macro-magic not allow it? Finally, not sure if IncludeInUseMonitorDetailsInLogMsgs carries its own weight. Could we not put that additional info at the Trace level, rather than Info ? Thanks, David ----- On 24/01/2019 6:16 am, Daniel D. Daugherty wrote: > Greetings, > > I have a (S)mall/(M)edium patch extracted from the Async Monitor Deflation > project that is ready for code review. I'm calling this a (S)mall/(M)edium > because the logic changes are (S)mall, but the logging code is tedious and > there's a bunch of it in audit_and_print_stats() so (M)edium. > > The short version of what this patch is about: > > ??? This sub-task captures updates and additions to the > ??? baseline monitor logging code. > > The details are in the bug report: > > ??? JDK-8217659 monitor_logging updates from Async Monitor Deflation > project > ??? https://bugs.openjdk.java.net/browse/JDK-8217659 > > Here's the webrev: > > ??? http://cr.openjdk.java.net/~dcubed/8217659-webrev/0-for-jdk13/ > > This patch along with the other two patches for Async Monitor Deflation > project have been through Mach5 > builds-tier1,hs-tier1,jdk-tier1,hs-tier2,hs-tier3 > testing and I'm currently running my stress testing kits on my Linux-X64 > and Solaris-X64 servers. > > I have been actively using this new logging code while debugging my > port of the Async Monitor Deflation project code. > > Thanks, in advance, for any questions, comments or suggestions. > > Dan > From erik.helin at oracle.com Thu Jan 24 08:05:27 2019 From: erik.helin at oracle.com (Erik Helin) Date: Thu, 24 Jan 2019 09:05:27 +0100 Subject: RFR: 8213231: ThreadSnapshot::_threadObj can become stale In-Reply-To: References: <22302ed6-22d2-1917-ca5c-10dda229ea6b@oracle.com> <48f299a5-0696-e352-a32c-b54d4a3063f6@oracle.com> <45778e9e-64b2-75cc-5dd8-34a3dd49bba6@oracle.com> Message-ID: On 1/24/19 1:24 AM, David Holmes wrote: > Thanks for the updates Erik - they generally look fine. One typo in the > header file: > > // ThreadSnasphot instances should only be created via > > Snasphot -> Snapshot Thanks for re-reviewing, I will fix the typo before I push. I will push this to jdk/jdk while waiting for the jdk12-fix-request to hopefully get approved. I have to talked Jesper and he is fine with me pushing this patch to jdk/jdk and then manually backporting to jdk/jdk12 if the fix request gets approved (this could, but most likely won't, result in some merge work for Jesper). Thanks, Erik > Cheers, > David > > On 24/01/2019 12:17 am, Erik Helin wrote: >> On 1/22/19 11:03 PM, David Holmes wrote: >>> Hi Erik, >> >> Hey David, thanks for reviewing! >> >>> Good find! This bug made an interesting read. Makes me wonder how we >>> may have caught this kind of error sooner? Some kind of unhandled oop >>> check? NoSafepointVerifier? >> >> Using -XX:+CheckUnhandledOops (and compiling with >> -DCHECK_UNHANDLED_OOPS) would have caught the issue, but not exactly >> the way we want it. If you look in UnhandledOops::clear_unhandled_oops >> you see that it does not assert if an oop is held over a safepoint, it >> will overwrite the oopDesc* is with BAD_OOP_ADDR (0xfffffff1). >> UnhandledOops does this because it is okay to hold on to an oop over a >> safepoint *if* you remember to update the oop again after the >> safepoint (this pattern is used at some places in the VM). >> >> In the case of this particular bug, we would have crashed in the >> ThreadInfo constructor because the java.lang.Thread pointer would have >> had the value BAD_OOP_ADDR. This means that we still would have had to >> figure out how that java.lang.Thread pointer got the value >> BAD_OOP_ADDR. This is better than to track down why the >> ThreadInfo.threadName field was stale, but still usually require quite >> a bit of archeology in the core file. >> >> Adding a NoSafepointVerifier at the top of the constructor for >> ThreadSnapshot would have helped. But if we would have realized that >> we needed a NoSafepointVerifier, then it would probably have been >> better to just use a Handle instead of an oop for the >> ThreadSnapshot::_threadObj field. In this particular case we could >> have placed a HandleMark at the top of jmm_GetThreadInfo and >> jmm_DumpThreads and then used a Handle for ThreadSnapshot::_threadObj. >> >> The problem with the Handle approach is that using a Handle for a >> field in a class requires the instances of that class to always be >> guarded by a HandleMark. This works fine for ThreadSnapshot as it is >> used right now, but might not be an applicable technique for all >> classes (for example a class that does not have a "lexical lifetime" >> and thus can't be guarded by a HandleMark). >> >> I have discussed this a bit with Erik ? and StefanK and we think a >> more general solution would be to build something on top of OopStorage >> (and potentially combine that with oopHandle). This way you get a safe >> and flexible handle for fields in classes. This would probably work >> for all but the most performance sensitive scenarios (we can probably >> create some special handles for those cases). >>> On 23/01/2019 12:59 am, Erik Helin wrote: >>>> Hi all, >>>> >>>> this patch fixes a problem when the oop in >>>> ThreadSnapshot::_threadObj can become stale. The issue is that the >>>> ThreadSnapshot::oops_do method only gets called when a >>>> ThreadSnapshot instance has been registered in a ThreadDumpResult >>>> (via the ThreadDumpResult::add_thread_snapshot method). But, in >>>> order to register a ThreadSnapshot instance, you must first create >>>> it. The problem is that the ThreadSnapshot constructor first sets >>>> _threadObj to thread->threadObj() and then further down might call >>>> ObjectSynchronizer:: get_lock_owner. The call to >>>> ObjectSynchronizer:: get_lock_owner can result in a VM_RevokeBias VM >>>> operation being executed. If a GC VM operation already is enqueued, >>>> then that GC VM operation will run when the VM_RevokeBias VM >>>> operation is executed. That GC VM operation will not update the oop >>>> in ThreadSafepoint::_threadObj, because that ThreadSnapshot instance >>>> has not yet been registered in any ThreadDumpResult (recall that the >>>> ThreadSafepoint is being constructed), so the GC has no way to find >>>> it. The oop in ThreadSafepoint::_threadObj will then become dangling >>>> which most likely will cause the JVM to get a SIGSEGV some time later. >>> >>> _blocker_object could suffer the same fate, and possibly >>> _blocker_object_owner if there could be other paths leading to a >>> safepoint. >> >> Yes, that is correct. >>>> The issue was found when debugging why an instance of >>>> java/lang/management/ThreadInfo on the Java heap had a stale pointer >>>> in its threadName field. Turns out that the java.lang.Thread >>>> instance passed to the ThreadInfo was stale most likely for the >>>> reason outlined in the paragraph above. >>>> >>>> This patch fixes the issue by ensuring that a ThreadSnapshot is >>>> always registered in a ThreadDumpResult before the initialization of >>>> the ThreadSnapshot is done. This ensures that the GC will always be >>>> able to find the oop ThreadSnapshot::_threadObj via >>>> ThreadDumpResult::oops_do. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~ehelin/8213231/00/ >>> >>> Explanation sounded simple enough - actual change was a little harder >>> to follow :) >>> >>> src/hotspot/share/services/threadService.cpp >>> >>> Initially I was concerned about ensuring all oop fields were NULL but >>> I see the ThreadSnapshot constructor handles that. That means some of >>> the NULL setting in initialize is redundant: >>> >>> ??854?? _stack_trace = NULL; >>> ??855?? _concurrent_locks = NULL; >>> ??856?? _next = NULL; >>> ??866?? _blocker_object = NULL; >>> ??867?? _blocker_object_owner = NULL; >> >> Nice catch, I missed removing those assignments, fixed that in version >> 01. >> >>> src/hotspot/share/services/threadService.hpp >>> >>> The new initialize function doesn't need to be public. >> >> It does, because it is used from the class ThreadDumpResult, see >> ThreadDumpResult::add_thread_snapshot. If we want the constructor for >> ThreadSnapshot and ThreadSnapshot::initialize to be private, then >> ThreadSnapshot must friend ThreadDumpResult. I did this change for 01, >> the added benefit is that the only way to create a ThreadSnapshot* is >> now through ThreadDumpResult::add_thread_snapshot (the ThreadSnapshot >> constructor is private). This means we have ensured that exactly this >> bug can't happen again :) >> >> ?> src/hotspot/share/services/threadService.hpp >>> +?? void link_thread_snapshot(ThreadSnapshot* ts); >>> >>> Please follow the existing layout style in that code and shift the >>> method name across to align with others. >> >> I tried to follow the existing style as much as possible, but the code >> in threadService.hpp contradicts itself in a few places :) See if you >> prefer the way I indented the function names in 01 (and don't ask me >> for my opinion on vertically aligning fields and methods in class >> declarations ;). >> >> Please see new webrevs at: >> - full: http://cr.openjdk.java.net/~ehelin/8213231/01/ >> - inc: http://cr.openjdk.java.net/~ehelin/8213231/00-01 >> >> Thanks, >> Erik >> >>> Thanks, >>> David >>> >>> >>>> >>>> Issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8213231 >>>> >>>> Testing: >>>> - Tier 1, 2 and 3 on Windows, Mac, Linux (all x86-64) >>>> - RunThese30M (multiple runs) and RunThese24h on Linux x86-64 >>>> ?? (please note that I never managed to reproduce the issue, all >>>> analysis was done based on a core file) >>>> >>>> Thanks, >>>> Erik From erik.helin at oracle.com Thu Jan 24 08:06:29 2019 From: erik.helin at oracle.com (Erik Helin) Date: Thu, 24 Jan 2019 09:06:29 +0100 Subject: RFR: 8213231: ThreadSnapshot::_threadObj can become stale In-Reply-To: <535b2375-9d56-f939-3261-2bc68a5a3f8e@oracle.com> References: <22302ed6-22d2-1917-ca5c-10dda229ea6b@oracle.com> <48f299a5-0696-e352-a32c-b54d4a3063f6@oracle.com> <45778e9e-64b2-75cc-5dd8-34a3dd49bba6@oracle.com> <535b2375-9d56-f939-3261-2bc68a5a3f8e@oracle.com> Message-ID: On 1/23/19 4:59 PM, Daniel D. Daugherty wrote: > On 1/23/19 9:17 AM, Erik Helin wrote: >> On 1/22/19 11:03 PM, David Holmes wrote: >>> Hi Erik, >> >> Hey David, thanks for reviewing! >> >>> Good find! This bug made an interesting read. Makes me wonder how we >>> may have caught this kind of error sooner? Some kind of unhandled oop >>> check? NoSafepointVerifier? >> >> Using -XX:+CheckUnhandledOops (and compiling with >> -DCHECK_UNHANDLED_OOPS) would have caught the issue, but not exactly >> the way we want it. If you look in UnhandledOops::clear_unhandled_oops >> you see that it does not assert if an oop is held over a safepoint, it >> will overwrite the oopDesc* is with BAD_OOP_ADDR (0xfffffff1). >> UnhandledOops does this because it is okay to hold on to an oop over a >> safepoint *if* you remember to update the oop again after the >> safepoint (this pattern is used at some places in the VM). >> >> In the case of this particular bug, we would have crashed in the >> ThreadInfo constructor because the java.lang.Thread pointer would have >> had the value BAD_OOP_ADDR. This means that we still would have had to >> figure out how that java.lang.Thread pointer got the value >> BAD_OOP_ADDR. This is better than to track down why the >> ThreadInfo.threadName field was stale, but still usually require quite >> a bit of archeology in the core file. >> >> Adding a NoSafepointVerifier at the top of the constructor for >> ThreadSnapshot would have helped. But if we would have realized that >> we needed a NoSafepointVerifier, then it would probably have been >> better to just use a Handle instead of an oop for the >> ThreadSnapshot::_threadObj field. In this particular case we could >> have placed a HandleMark at the top of jmm_GetThreadInfo and >> jmm_DumpThreads and then used a Handle for ThreadSnapshot::_threadObj. >> >> The problem with the Handle approach is that using a Handle for a >> field in a class requires the instances of that class to always be >> guarded by a HandleMark. This works fine for ThreadSnapshot as it is >> used right now, but might not be an applicable technique for all >> classes (for example a class that does not have a "lexical lifetime" >> and thus can't be guarded by a HandleMark). >> >> I have discussed this a bit with Erik ? and StefanK and we think a >> more general solution would be to build something on top of OopStorage >> (and potentially combine that with oopHandle). This way you get a safe >> and flexible handle for fields in classes. This would probably work >> for all but the most performance sensitive scenarios (we can probably >> create some special handles for those cases). >>> On 23/01/2019 12:59 am, Erik Helin wrote: >>>> Hi all, >>>> >>>> this patch fixes a problem when the oop in >>>> ThreadSnapshot::_threadObj can become stale. The issue is that the >>>> ThreadSnapshot::oops_do method only gets called when a >>>> ThreadSnapshot instance has been registered in a ThreadDumpResult >>>> (via the ThreadDumpResult::add_thread_snapshot method). But, in >>>> order to register a ThreadSnapshot instance, you must first create >>>> it. The problem is that the ThreadSnapshot constructor first sets >>>> _threadObj to thread->threadObj() and then further down might call >>>> ObjectSynchronizer:: get_lock_owner. The call to >>>> ObjectSynchronizer:: get_lock_owner can result in a VM_RevokeBias VM >>>> operation being executed. If a GC VM operation already is enqueued, >>>> then that GC VM operation will run when the VM_RevokeBias VM >>>> operation is executed. That GC VM operation will not update the oop >>>> in ThreadSafepoint::_threadObj, because that ThreadSnapshot instance >>>> has not yet been registered in any ThreadDumpResult (recall that the >>>> ThreadSafepoint is being constructed), so the GC has no way to find >>>> it. The oop in ThreadSafepoint::_threadObj will then become dangling >>>> which most likely will cause the JVM to get a SIGSEGV some time later. >>> >>> _blocker_object could suffer the same fate, and possibly >>> _blocker_object_owner if there could be other paths leading to a >>> safepoint. >> >> Yes, that is correct. >>>> The issue was found when debugging why an instance of >>>> java/lang/management/ThreadInfo on the Java heap had a stale pointer >>>> in its threadName field. Turns out that the java.lang.Thread >>>> instance passed to the ThreadInfo was stale most likely for the >>>> reason outlined in the paragraph above. >>>> >>>> This patch fixes the issue by ensuring that a ThreadSnapshot is >>>> always registered in a ThreadDumpResult before the initialization of >>>> the ThreadSnapshot is done. This ensures that the GC will always be >>>> able to find the oop ThreadSnapshot::_threadObj via >>>> ThreadDumpResult::oops_do. >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~ehelin/8213231/00/ >>> >>> Explanation sounded simple enough - actual change was a little harder >>> to follow :) >>> >>> src/hotspot/share/services/threadService.cpp >>> >>> Initially I was concerned about ensuring all oop fields were NULL but >>> I see the ThreadSnapshot constructor handles that. That means some of >>> the NULL setting in initialize is redundant: >>> >>> ??854?? _stack_trace = NULL; >>> ??855?? _concurrent_locks = NULL; >>> ??856?? _next = NULL; >>> ??866?? _blocker_object = NULL; >>> ??867?? _blocker_object_owner = NULL; >> >> Nice catch, I missed removing those assignments, fixed that in version >> 01. >> >>> src/hotspot/share/services/threadService.hpp >>> >>> The new initialize function doesn't need to be public. >> >> It does, because it is used from the class ThreadDumpResult, see >> ThreadDumpResult::add_thread_snapshot. If we want the constructor for >> ThreadSnapshot and ThreadSnapshot::initialize to be private, then >> ThreadSnapshot must friend ThreadDumpResult. I did this change for 01, >> the added benefit is that the only way to create a ThreadSnapshot* is >> now through ThreadDumpResult::add_thread_snapshot (the ThreadSnapshot >> constructor is private). This means we have ensured that exactly this >> bug can't happen again :) >> >> > src/hotspot/share/services/threadService.hpp >>> +?? void link_thread_snapshot(ThreadSnapshot* ts); >>> >>> Please follow the existing layout style in that code and shift the >>> method name across to align with others. >> >> I tried to follow the existing style as much as possible, but the code >> in threadService.hpp contradicts itself in a few places :) See if you >> prefer the way I indented the function names in 01 (and don't ask me >> for my opinion on vertically aligning fields and methods in class >> declarations ;). >> >> Please see new webrevs at: >> - full: http://cr.openjdk.java.net/~ehelin/8213231/01/ >> - inc: http://cr.openjdk.java.net/~ehelin/8213231/00-01 > > src/hotspot/share/services/threadService.cpp > ??? No comments. > > src/hotspot/share/services/threadService.hpp > ??? L216: ? // ThreadSnasphot instances should only be created via > ??????? Typo: 'ThreadSnasphot' -> 'ThreadSnapshot' > > Thumbs up. Don't need another webrev for fixing the above typo. Thanks for re-reviewing! As I wrote to David, I will fix the typo before I push. Thanks, Erik > Dan > > >> >> Thanks, >> Erik >> >>> Thanks, >>> David >>> >>> >>>> >>>> Issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8213231 >>>> >>>> Testing: >>>> - Tier 1, 2 and 3 on Windows, Mac, Linux (all x86-64) >>>> - RunThese30M (multiple runs) and RunThese24h on Linux x86-64 >>>> ?? (please note that I never managed to reproduce the issue, all >>>> analysis was done based on a core file) >>>> >>>> Thanks, >>>> Erik > From claes.redestad at oracle.com Thu Jan 24 09:32:01 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 24 Jan 2019 10:32:01 +0100 Subject: RFR 8217660: Refactor module related locked_create_entry_or_null() functions In-Reply-To: References: Message-ID: <26a16555-328f-2120-8d97-9a39d199807a@oracle.com> Hi Harold, On 2019-01-23 22:28, Harold Seigel wrote: > http://cr.openjdk.java.net/~hseigel/bug_8217660/webrev/index.html looks like a nice cleanup to me, and avoiding a package lookup when we know the package can't exist should be a small improvement. Thanks! /Claes From yumin.qi at gmail.com Thu Jan 24 09:47:15 2019 From: yumin.qi at gmail.com (yumin qi) Date: Thu, 24 Jan 2019 17:47:15 +0800 Subject: Question about os::native_path Message-ID: Hi, inline char* os::native_path(char *path) { return path; } What is the purpose of this function? I think it is for a full native path, but the source code told me it is just itself. Thanks Yumin From david.holmes at oracle.com Thu Jan 24 10:07:26 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 24 Jan 2019 20:07:26 +1000 Subject: Question about os::native_path In-Reply-To: References: Message-ID: <157027ac-22b2-5d41-0bd6-cf06e4becb35@oracle.com> Hi Yumin, On 24/01/2019 7:47 pm, yumin qi wrote: > Hi, > > inline char* os::native_path(char *path) { > return path; > } > > What is the purpose of this function? I think it is for a full native path, > but the source code told me it is just itself. For POSIX systems it is a no-op, but for Windows there is extra stuff to be done. // Convert a pathname to native format. On win32, this involves forcing all // separators to be '\\' rather than '/' (both are legal inputs, but Win95 // sometimes rejects '/') and removing redundant separators. The input path is // assumed to have been converted into the character encoding used by the local // system. Because this might be a double-byte encoding, care is taken to // treat double-byte lead characters correctly. // // This procedure modifies the given path in place, as the result is never // longer than the original. There is no error return; this operation always // succeeds. Cheers, David > Thanks > Yumin > From Pengfei.Li at arm.com Thu Jan 24 10:10:45 2019 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Thu, 24 Jan 2019 10:10:45 +0000 Subject: Question about os::native_path In-Reply-To: References: Message-ID: Hi, > inline char* os::native_path(char *path) { > return path; > } > > What is the purpose of this function? I think it is for a full native path, but the > source code told me it is just itself. This is the code in os_posix.cpp. There's another implementation in os_windows.cpp [1] which converts the path string to windows format. So we don't need to consider the platform at the call sites. ^_^ [1] http://hg.openjdk.java.net/jdk/jdk/file/091ed8f2e7d7/src/hotspot/os/windows/os_windows.cpp#l4572 -- Thanks, Pengfei From wangxue at loongson.cn Thu Jan 24 11:41:30 2019 From: wangxue at loongson.cn (Wang Xue) Date: Thu, 24 Jan 2019 19:41:30 +0800 Subject: Is the square brackets in output of -XX:+PrintStubCode a typo? Message-ID: <29a4ed50-6fa5-3be5-59ee-771f5c743b20@loongson.cn> Hi all, I found that the symbol "[ ]" is not matching when I use -XX:+PrintStubCode. Is it a typo? the output: $ java -XX:+UnlockDiagnosticVMOptions -XX:+PrintStubCode -version StubRoutines::forward exception [0x00007f73548a47a0, 0x00007f73548a48e4[ (324 bytes) StubRoutines::call_stub [0x00007f73548a48e4, 0x00007f73548a4c22[ (830 bytes) StubRoutines::catch_exception [0x00007f73548a4c22, 0x00007f73548a4e03[ (481 bytes) StubRoutines::atomic_xchg [0x00007f73548a4e03, 0x00007f73548a4e08[ (5 bytes) StubRoutines::atomic_xchg_long [0x00007f73548a4e08, 0x00007f73548a4e0f[ (7 bytes) StubRoutines::atomic_cmpxchg [0x00007f73548a4e0f, 0x00007f73548a4e16[ (7 bytes) StubRoutines::atomic_cmpxchg_byte [0x00007f73548a4e16, 0x00007f73548a4e20[ (10 bytes) StubRoutines::atomic_cmpxchg_long [0x00007f73548a4e20, 0x00007f73548a4e29[ (9 bytes) StubRoutines::atomic_add [0x00007f73548a4e29, 0x00007f73548a4e32[ (9 bytes) ... I made a small change to match "[ ]": diff -r b2d1c3b0bd31 src/hotspot/share/runtime/stubCodeGenerator.cpp --- a/src/hotspot/share/runtime/stubCodeGenerator.cpp Wed Jan 23 13:40:09 2019 +0100 +++ b/src/hotspot/share/runtime/stubCodeGenerator.cpp Thu Jan 24 19:04:39 2019 +0800 @@ -60,7 +60,7 @@ st->print("%s", group()); st->print("::"); st->print("%s", name()); - st->print(" [" INTPTR_FORMAT ", " INTPTR_FORMAT "[ (%d bytes)", p2i(begin()), p2i(end()), size_in_bytes()); + st->print(" [" INTPTR_FORMAT ", " INTPTR_FORMAT "] (%d bytes)", p2i(begin()), p2i(end()), size_in_bytes()); } // Implementation of StubCodeGenerator Could someone help to review the small change? Thanks, Wang Xue From yumin.qi at gmail.com Thu Jan 24 11:47:29 2019 From: yumin.qi at gmail.com (yumin qi) Date: Thu, 24 Jan 2019 19:47:29 +0800 Subject: Question about os::native_path In-Reply-To: <157027ac-22b2-5d41-0bd6-cf06e4becb35@oracle.com> References: <157027ac-22b2-5d41-0bd6-cf06e4becb35@oracle.com> Message-ID: David, Pengfei Thanks. It is for Widows -- I did not notice that. Thanks Yumin On Thu, Jan 24, 2019 at 6:07 PM David Holmes wrote: > Hi Yumin, > > On 24/01/2019 7:47 pm, yumin qi wrote: > > Hi, > > > > inline char* os::native_path(char *path) { > > return path; > > } > > > > What is the purpose of this function? I think it is for a full native > path, > > but the source code told me it is just itself. > > For POSIX systems it is a no-op, but for Windows there is extra stuff to > be done. > > // Convert a pathname to native format. On win32, this involves forcing > all > // separators to be '\\' rather than '/' (both are legal inputs, but Win95 > // sometimes rejects '/') and removing redundant separators. The input > path is > // assumed to have been converted into the character encoding used by > the local > // system. Because this might be a double-byte encoding, care is taken to > // treat double-byte lead characters correctly. > // > // This procedure modifies the given path in place, as the result is never > // longer than the original. There is no error return; this operation > always > // succeeds. > > Cheers, > David > > > Thanks > > Yumin > > > From lois.foltan at oracle.com Thu Jan 24 12:27:32 2019 From: lois.foltan at oracle.com (Lois Foltan) Date: Thu, 24 Jan 2019 07:27:32 -0500 Subject: RFR 8217660: Refactor module related locked_create_entry_or_null() functions In-Reply-To: References: Message-ID: On 1/23/2019 4:28 PM, Harold Seigel wrote: > ?* Adds a PackageEntryTable::locked_create_entry() function for callers > ?? who know the package entry cannot already exist. > ?* Replaces ModuleEntryTable::locked_create_entry_or_null() with > ?? locked_create_entry(). > ?* Adds a call to lookup_only(module_symbol) to check if a moduleEntry > ?? exists, instead of depending on locked_create_entry_or_null() > ?? returning null. > > Open Webrev: > http://cr.openjdk.java.net/~hseigel/bug_8217660/webrev/index.html Hi Harold, I think this looks good.? A couple of minor comments: - can you add a comment before the definition of ModuleEntryTable::locked_create_entry() that indicates that it is the caller's responsibility to check if the module has already been defined prior to calling locked_create_entry(). - the only situation I see this as an issue is in create_javabase() but that method should only be called once during bootstrapping. There are no checks in ModuleEntry::set_javabase_ModuleEntry that ensures ModuleEntry::_javabase_module == NULL before setting. I don't need to see another webrev. Thanks, Lois From harold.seigel at oracle.com Thu Jan 24 13:08:11 2019 From: harold.seigel at oracle.com (Harold Seigel) Date: Thu, 24 Jan 2019 08:08:11 -0500 Subject: RFR 8217660: Refactor module related locked_create_entry_or_null() functions In-Reply-To: <26a16555-328f-2120-8d97-9a39d199807a@oracle.com> References: <26a16555-328f-2120-8d97-9a39d199807a@oracle.com> Message-ID: Thanks Claes! Harold On 1/24/2019 4:32 AM, Claes Redestad wrote: > Hi Harold, > > On 2019-01-23 22:28, Harold Seigel wrote: >> http://cr.openjdk.java.net/~hseigel/bug_8217660/webrev/index.html > > looks like a nice cleanup to me, and avoiding a package lookup when > we know the package can't exist should be a small improvement. > > Thanks! > > /Claes From harold.seigel at oracle.com Thu Jan 24 13:20:00 2019 From: harold.seigel at oracle.com (Harold Seigel) Date: Thu, 24 Jan 2019 08:20:00 -0500 Subject: RFR 8217660: Refactor module related locked_create_entry_or_null() functions In-Reply-To: References: Message-ID: <5ff14eaf-a161-d107-c6de-74d82f893b20@oracle.com> Thanks Lois! I'll add the requested comment to ModuleEntrytable::locked_create_entry() and add an assert to set_javabase_moduleEntry() that _javabase_module is NULL. Harold On 1/24/2019 7:27 AM, Lois Foltan wrote: > On 1/23/2019 4:28 PM, Harold Seigel wrote: >> ?* Adds a PackageEntryTable::locked_create_entry() function for callers >> ?? who know the package entry cannot already exist. >> ?* Replaces ModuleEntryTable::locked_create_entry_or_null() with >> ?? locked_create_entry(). >> ?* Adds a call to lookup_only(module_symbol) to check if a moduleEntry >> ?? exists, instead of depending on locked_create_entry_or_null() >> ?? returning null. >> >> Open Webrev: >> http://cr.openjdk.java.net/~hseigel/bug_8217660/webrev/index.html > > Hi Harold, > > I think this looks good.? A couple of minor comments: > > - can you add a comment before the definition of > ModuleEntryTable::locked_create_entry() that indicates that it is the > caller's responsibility to check if the module has already been > defined prior to calling locked_create_entry(). > - the only situation I see this as an issue is in create_javabase() > but that method should only be called once during bootstrapping. There > are no checks in ModuleEntry::set_javabase_ModuleEntry that ensures > ModuleEntry::_javabase_module == NULL before setting. > > I don't need to see another webrev. > Thanks, > Lois From daniel.daugherty at oracle.com Thu Jan 24 14:05:19 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 24 Jan 2019 09:05:19 -0500 Subject: RFR(S): 8217658 baseline_cleanups from Async Monitor Deflation project In-Reply-To: <653c2aaf-64d5-edbb-d7d7-4f88f7da1c63@oracle.com> References: <653c2aaf-64d5-edbb-d7d7-4f88f7da1c63@oracle.com> Message-ID: <63860c8f-4971-e491-d333-d17fa82707c8@oracle.com> On 1/23/19 11:18 PM, David Holmes wrote: > Hi Dan, > > This all seems fine. Some comments below. Thanks for the review! > > One suggested addition to your cleanup :) > > ./share/runtime/basicLock.cpp > > // [RGV] The next line appears to do nothing! > ? intptr_t dh = (intptr_t) displaced_header(); > ? dest->set_displaced_header(displaced_header()); Sure. I was confused for a second since I couldn't remember touching share/runtime/basicLock.cpp in my current project. Of course, you sending me a cleanup out of the blue reminds me of this other one you sent me a very long ago: ./share/vm/prims/jvmtiExport.cpp:???????????????????? ("JVMTI [%s] montior contended enter event triggered", ./share/vm/prims/jvmtiExport.cpp:???????????????????? ("JVMTI [%s] montior contended entered event triggered", ./share/vm/prims/jvmtiExport.cpp:???????????????????? ("JVMTI [%s] montior wait event triggered", ./share/vm/prims/jvmtiExport.cpp:???????????????????? ("JVMTI [%s] montior waited event triggered", that's been hanging around in my cleanup queue for a while... I'll take care of both of these with 8217658. Dan > > On 24/01/2019 6:07 am, Daniel D. Daugherty wrote: >> Greetings, >> >> I have a (S)mall patch extracted from the Async Monitor Deflation >> project that is ready for code review. >> >> The short version of what this patch is about: >> >> ?? ? This sub-task captures updates to the baseline code that are not >> ?? ? directly related to Async Monitor Deflation. >> >> The details are in the bug report: >> >> ???? JDK-8217658 baseline_cleanups from Async Monitor Deflation project >> ???? https://bugs.openjdk.java.net/browse/JDK-8217658 >> >> Here's the webrev: >> >> http://cr.openjdk.java.net/~dcubed/8217658-webrev/0-for-jdk13/ > > To quote your main semantic changes from the bug report: > >> - add missing "else" to logical if-else-statement in >> ? ObjectSynchronizer::get_lock_owner() > > Okay - the two conditions are mutually exclusive. > >> - guarantee that header() is NULL when >> ? ObjectSynchronizer::omRelease() is called >> - Replace a set_owner(NULL) call with a set_header(NULL) >> ? call in the "CASE: neutral" part of ObjectSynchronizer::inflate() >> ? when the object->cas_set_mark() fails. This is a rare race. > > These seem okay but did get me thinking about the different roles of > ObjectMonitor::Recycle() and ObjectMonitor::clear() and the individual > clearing of fields! I find it all somewhat confusing - in particular > why clear() asserts that _header != NULL ! Some explanatory comments > on those methods would be appreciated at some point during this project. > > Thanks, > David > ----- > > >> >> This patch along with the other two patches for Async Monitor Deflation >> project have been through Mach5 >> builds-tier1,hs-tier1,jdk-tier1,hs-tier2,hs-tier3 >> testing and I'm currently running my stress testing kits on my Linux-X64 >> and Solaris-X64 servers. >> >> Thanks, in advance, for any questions, comments or suggestions. >> >> Dan >> From daniel.daugherty at oracle.com Thu Jan 24 14:27:48 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 24 Jan 2019 09:27:48 -0500 Subject: RFR(S/M): 8217659 monitor_logging updates from Async Monitor Deflation project In-Reply-To: <0b24c9d7-9f1c-6c62-9a08-66d3ecaf545c@oracle.com> References: <0b24c9d7-9f1c-6c62-9a08-66d3ecaf545c@oracle.com> Message-ID: <66c9e7c1-540c-fd03-3fe3-f17fb9a83f09@oracle.com> On 1/24/19 2:41 AM, David Holmes wrote: > Hi Dan, > > This looks generally fine too. Thanks for the review! > ObjectSynchronizer::audit_and_print_stats is pretty hard to digest! Agreed! Writing it was also "interesting"... :-) > I think the logging can be simpler if you extract the log stream > rather than repeating "log_info(monitorinflation)" so many times. Sounds good. I'll figure out how to do that and update the code. > > + // I'm not sure why the baseline monitorinflation logic only > + // issues logging mesgs for instance objects. > + //????? if (obj->is_instance()) { > > This needs to be resolved. Yes, that would be why I left that comment in for the review. :-) I'll check the code history for the original monitor deflation logging code and see if I can discern a reason. > If the alternative to being an instance is being an array, then I > think we should be logging for those too (that might actually catch > use of the class initialization monitors). In my debugging of a recent test failure, I saw logging output for and inflated "[I" at the end of the VM's life (IIRC)... > When we have different Info versus Debug logging eg: > > !?? if (deflated_count != 0) { > !???? if (log_is_enabled(Info, monitorinflation)) { > !?????? log_info(monitorinflation)("deflating global idle monitors, > %3.7f secs, %d monitors", timer.seconds(), deflated_count); > !???? } > !?? } else { > !???? if (log_is_enabled(Debug, monitorinflation)) { > !?????? log_debug(monitorinflation)("deflating global idle monitors, > %3.7f secs, 0 monitors", timer.seconds()); > !???? } > !?? } > > is it possible to rewrite that as: > > ?if (log_is_enabled( deflated_count != 0 ? Info : Debug, > ??????????????????? monitorinflation)) { > !?????? log_info(monitorinflation)("deflating global idle monitors, > %3.7f secs, %d monitors", timer.seconds(), deflated_count); > !???? } > > or does the logging macro-magic not allow it? Good question. I'll check it out. Maybe after the above simplifications, other ways to make this function more digestible will become apparent... > Finally, not sure if IncludeInUseMonitorDetailsInLogMsgs carries its > own weight. Could we not put that additional info at the Trace level, > rather than Info ? Thanks for chiming in on IncludeInUseMonitorDetailsInLogMsgs. I tend to agree hence the question during this review cycle. I'm thinking that at VM-exit time, it should be at Debug level and at safepoint time it should be at Trace level. I expect most casual use of monitorinflation logging to be at the Info level... And this output is far from casual... Thanks again for the review. Dan > > Thanks, > David > ----- > > On 24/01/2019 6:16 am, Daniel D. Daugherty wrote: >> Greetings, >> >> I have a (S)mall/(M)edium patch extracted from the Async Monitor >> Deflation >> project that is ready for code review. I'm calling this a >> (S)mall/(M)edium >> because the logic changes are (S)mall, but the logging code is >> tedious and >> there's a bunch of it in audit_and_print_stats() so (M)edium. >> >> The short version of what this patch is about: >> >> ???? This sub-task captures updates and additions to the >> ???? baseline monitor logging code. >> >> The details are in the bug report: >> >> ???? JDK-8217659 monitor_logging updates from Async Monitor Deflation >> project >> ???? https://bugs.openjdk.java.net/browse/JDK-8217659 >> >> Here's the webrev: >> >> http://cr.openjdk.java.net/~dcubed/8217659-webrev/0-for-jdk13/ >> >> This patch along with the other two patches for Async Monitor Deflation >> project have been through Mach5 >> builds-tier1,hs-tier1,jdk-tier1,hs-tier2,hs-tier3 >> testing and I'm currently running my stress testing kits on my Linux-X64 >> and Solaris-X64 servers. >> >> I have been actively using this new logging code while debugging my >> port of the Async Monitor Deflation project code. >> >> Thanks, in advance, for any questions, comments or suggestions. >> >> Dan >> From gerard.ziemski at oracle.com Thu Jan 24 17:17:47 2019 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Thu, 24 Jan 2019 11:17:47 -0600 Subject: RFR (S) 8216493: VirtualSpaceNodeTest.half_vsn_is_committed_humongous_chunk_is_used_test_vm crashes on local machine In-Reply-To: References: <1421EDFD-7F13-4A50-B05D-949D668CE86C@oracle.com> <400C7E72-64F5-4790-A68F-A7606ABC94BC@oracle.com> Message-ID: <00E809F2-047E-4583-995F-795ADF4103F1@oracle.com> hi Igor, > On Jan 23, 2019, at 1:43 PM, Gerard Ziemski wrote: > >> On Jan 23, 2019, at 1:33 PM, Igor Ignatyev wrote: >> >> Hi Gerard, >> >> the fix looks reasonable to me, one small editorial nit: include of standard headers should go before custom headers, so could you please move 'include ' to L#25 (as precompiled.hpp still must be 1st include). > > Will do. I ran into a problem with the ?assert? macro, if I move 'include ? before other hotspot headers. header pulls in an incompatible ?assert? macro that breaks our code, ex: open/src/hotspot/share/memory/freeList.hpp:69:25: error: too many arguments provided to function-like macro invocation jib > assert(_count >= 0, "Count should not be negative"); jib > ^ jib > #########/devkit-macosx_x64/Xcode9.4-MacOSX10.13+1.0/devkit-macosx_x64-Xcode9.4-MacOSX10.13+1.0.tar.gz/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/include/assert.h:92:9: note: macro 'assert' defined here jib > #define assert(e) Fixing this here is beyond the scope, so I hope you?re OK with being the last include? cheers From igor.ignatyev at oracle.com Thu Jan 24 17:56:36 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 24 Jan 2019 09:56:36 -0800 Subject: RFR (S) 8216493: VirtualSpaceNodeTest.half_vsn_is_committed_humongous_chunk_is_used_test_vm crashes on local machine In-Reply-To: <00E809F2-047E-4583-995F-795ADF4103F1@oracle.com> References: <1421EDFD-7F13-4A50-B05D-949D668CE86C@oracle.com> <400C7E72-64F5-4790-A68F-A7606ABC94BC@oracle.com> <00E809F2-047E-4583-995F-795ADF4103F1@oracle.com> Message-ID: right,.. I totally forgot about us redefining assert. sure in this case, I'm fine w/ having the last include. sorry for making you do extra work in vain. -- Igor > On Jan 24, 2019, at 9:17 AM, Gerard Ziemski wrote: > > hi Igor, > >> On Jan 23, 2019, at 1:43 PM, Gerard Ziemski wrote: >> >>> On Jan 23, 2019, at 1:33 PM, Igor Ignatyev wrote: >>> >>> Hi Gerard, >>> >>> the fix looks reasonable to me, one small editorial nit: include of standard headers should go before custom headers, so could you please move 'include ' to L#25 (as precompiled.hpp still must be 1st include). >> >> Will do. > > I ran into a problem with the ?assert? macro, if I move 'include ? before other hotspot headers. > > header pulls in an incompatible ?assert? macro that breaks our code, ex: > > open/src/hotspot/share/memory/freeList.hpp:69:25: error: too many arguments provided to function-like macro invocation jib > assert(_count >= 0, "Count should not be negative"); jib > ^ jib > #########/devkit-macosx_x64/Xcode9.4-MacOSX10.13+1.0/devkit-macosx_x64-Xcode9.4-MacOSX10.13+1.0.tar.gz/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk/usr/include/assert.h:92:9: note: macro 'assert' defined here jib > #define assert(e) > > Fixing this here is beyond the scope, so I hope you?re OK with being the last include? > > > cheers From coleen.phillimore at oracle.com Thu Jan 24 20:39:51 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 24 Jan 2019 15:39:51 -0500 Subject: RFR(S/M): 8217659 monitor_logging updates from Async Monitor Deflation project In-Reply-To: References: Message-ID: http://cr.openjdk.java.net/~dcubed/8217659-webrev/0-for-jdk13/src/hotspot/share/runtime/synchronizer.cpp.frames.html 1426 if (log_is_enabled(Trace, monitorinflation)) { 1427 if (object->is_instance()) { 1428 ResourceMark rm(Self); 1429 log_trace(monitorinflation)("inflate(has_locker): " 1430 "object=" INTPTR_FORMAT ", mark=" INTPTR_FORMAT ", type='%s'", 1431 p2i(object), p2i(object->mark()), 1432 object->klass()->external_name()); 1433 } 1434 } It seems like extra overhead to ask if logging is enabled in both 1426 and internally in 1429.? It seems that if object->is_instance() is a cheap test, 1426 is unnecessary.? I realize it was like this.?? Same at 1477, 1532.? I don't think ResourceMarks are expensive either. 1653 if (log_is_enabled(Info, monitorinflation)) { 1654 log_info(monitorinflation)("deflating global idle monitors, %3.7f secs, %d monitors", timer.seconds(), deflated_count); 1655 } 1656 } else { 1657 if (log_is_enabled(Debug, monitorinflation)) { 1658 log_debug(monitorinflation)("deflating global idle monitors, %3.7f secs, 0 monitors", timer.seconds()); 1659 } log_info/log_debug also ask if log_is_enabled, so the log_is_enabled test isn't necessary here, and 1673, 1677 and 1664.? I think a lot of these were early logging changes that weren't caught then. Duplicating David's comment audit_and_print_stats can create a LogStream log and use that instead of doing log_info/etc. Instead of 2048 if (IncludeInUseMonitorDetailsInLogMsgs) { You can add a tag to the logging, so that you can say -Xlog:monitorinflation+inuse or some such tag. It's not worth adding another command line option when logging gives you the ability to be specific about what output you want. Lastly, I didn't look at what you're verifying and logging but maybe the ~300 line function could be split and you could add more tags in the future to taylor what specific information and verification you are looking for.?? It looks there's a bit of duplication in the logging messages. Coleen On 1/23/19 3:16 PM, Daniel D. Daugherty wrote: > Greetings, > > I have a (S)mall/(M)edium patch extracted from the Async Monitor > Deflation > project that is ready for code review. I'm calling this a > (S)mall/(M)edium > because the logic changes are (S)mall, but the logging code is tedious > and > there's a bunch of it in audit_and_print_stats() so (M)edium. > > The short version of what this patch is about: > > ??? This sub-task captures updates and additions to the > ??? baseline monitor logging code. > > The details are in the bug report: > > ??? JDK-8217659 monitor_logging updates from Async Monitor Deflation > project > ??? https://bugs.openjdk.java.net/browse/JDK-8217659 > > Here's the webrev: > > ??? http://cr.openjdk.java.net/~dcubed/8217659-webrev/0-for-jdk13/ > > This patch along with the other two patches for Async Monitor Deflation > project have been through Mach5 > builds-tier1,hs-tier1,jdk-tier1,hs-tier2,hs-tier3 > testing and I'm currently running my stress testing kits on my Linux-X64 > and Solaris-X64 servers. > > I have been actively using this new logging code while debugging my > port of the Async Monitor Deflation project code. > > Thanks, in advance, for any questions, comments or suggestions. > > Dan > From linuxtardis at gmail.com Thu Jan 24 23:17:38 2019 From: linuxtardis at gmail.com (Jakub =?UTF-8?Q?Van=C4=9Bk?=) Date: Fri, 25 Jan 2019 00:17:38 +0100 Subject: RFR(M)(round 2): 8215902: Add support for SoftFloat-3e library In-Reply-To: <3f62f15e-ac5f-94d4-9744-c9cef796a3fa@oracle.com> References: <4497ca084b9f48dbb8f6de1aa35c83653fd7acfb.camel@gmail.com> <7f69fc73-1c10-6b68-d657-c9e758d4bf1d@oracle.com> <3f62f15e-ac5f-94d4-9744-c9cef796a3fa@oracle.com> Message-ID: <12e1cb109842f145edf23b4ea5ef591395188de9.camel@gmail.com> Hi Magnus, thanks for the review! I haven't received a review for the hotspot source changes yet, so I will have to wait. Regards, Jakub On 2019-01-23 at 13:55 +0100, Magnus Ihse Bursie wrote: > Hi Jakub, > > On 2019-01-15 17:31, Jakub Van?k wrote: > > Hi Magnus and Erik, > > > > I have added the link to the repository to README and I have > > removed > > the link to the mailing list thread. I have also recreated the > > GitHub > > repository. Now it is a fork of the mentioned repository with two > > extra > > commits containing README and the build scripts. > > > > New webrev URL: > > http://cr.openjdk.java.net/~jakvanek/8215902/webrev.04/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215902 > > Sorry for the late reply. > > This looks very good! Thank you for fixing this, including rebasing > the > github repo. > > I'm not sure if you've gotten reviews from the hotspot team for the > hotspot source changes, but from a build perspective, this is good to > go. > > /Magnus > > > > Regards, > > > > Jakub > > > > On 2019-01-15 at 15:05 +0100, Magnus Ihse Bursie wrote: > > > On 2018-12-25 16:19, Jakub Van?k wrote: > > > > Hi, > > > > > > > > please review this webrev. It is a successor of the softfloat-3 > > > > [patch] > > > > thread (first email > > > > > > > > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-November/031311.html > > > > ) > > > > > > > > Changes since the last patch (v6): > > > > > > > > - renamed --with-softloat* to --with-sflt* (it is more compact > > > > and > > > > it > > > > corresponds to the old --with-sflt-lib=... option) > > > > > > > > - license is now obtained via --with-sflt-license switch (so it > > > > is > > > > not > > > > included in OpenJDK source tree) > > > > > > > > - updated documentation (slight rewording, added the license > > > > option) > > > > > > > > - checks for default --with/--without behavior are in place > > > > again > > > > (I forgot them when I changed the way the library is > > > > detected) > > > > > > > > - added a simple testcase - I found a disrepancy between > > > > softfloat > > > > and > > > > system function behavior. When a float with bits 0x003FFFFF > > > > is > > > > added to 0x00000001, the correct result is 0x00400000, but > > > > the > > > > default software floating point implementation returns > > > > 0x00000000. > > > > However I'm not sure where to put this test - now it is in > > > > test/hotspot/jtreg/compiler/floatingpoint. > > > > > > > > - comments in code refer to CR 6757269 and newly JDK-8215902 > > > > too. > > > > > > > > I have created a repository with SoftFloat-3e with build > > > > configuration > > > > specifically for OpenJDK on armel: > > > > https://github.com/ev3dev-lang-java/softfloat-openjdk > > > > > > > > I can add a link to it to the documentation. > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8215902 > > > > Webrev: http://cr.openjdk.java.net/~jakvanek/8215902/webrev.02/ > > > > > > Hi Jakub, > > > > > > In general this looks good. > > > > > > Some comments: > > > > > > I agree with Erik that you can add a link to your github project; > > > compiling SoftFloat is outside the scope of the OpenJDK build > > > instructions, but it can sure be helpful to lower the bar for > > > users > > > wanting to do that. Just one question: any particular reason you > > > didn't > > > create your github repo by forking the official > > > https://github.com/ucb-bar/berkeley-softfloat-3? That way, it > > > would > > > have > > > been easy for users to see that you were not adding any malicious > > > or > > > suspicious code to the original SoftFloat distribution. > > > > > > On the other hand, I think the link to > > > > > > > http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2016-November/000611.html > > > > > > is unnecessary and just creates clutter in the documentation. > > > Please > > > remove it. > > > > > > /Magnus > > > > CI build: > > > > https://ci.adoptopenjdk.net/view/ev3dev/job/openjdk12_build_ev3_linux/67/ > > > > > > > > Cheers, > > > > > > > > Jakub > > > > > > From daniel.daugherty at oracle.com Thu Jan 24 23:52:46 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 24 Jan 2019 18:52:46 -0500 Subject: RFR(S/M): 8217659 monitor_logging updates from Async Monitor Deflation project In-Reply-To: References: Message-ID: Hi Coleen, Thanks for the review. Replies embedded below... On 1/24/19 3:39 PM, coleen.phillimore at oracle.com wrote: > > http://cr.openjdk.java.net/~dcubed/8217659-webrev/0-for-jdk13/src/hotspot/share/runtime/synchronizer.cpp.frames.html > > > 1426 if (log_is_enabled(Trace, monitorinflation)) { > 1427???????? if (object->is_instance()) { > 1428?????????? ResourceMark rm(Self); > 1429 log_trace(monitorinflation)("inflate(has_locker): " > 1430?????????????????????????????????????? "object=" INTPTR_FORMAT ", > mark=" INTPTR_FORMAT ", type='%s'", > 1431?????????????????????????????????????? p2i(object), > p2i(object->mark()), > 1432 object->klass()->external_name()); > 1433???????? } > 1434?????? } > > It seems like extra overhead to ask if logging is enabled in both 1426 > and internally in 1429.? It seems that if object->is_instance() is a > cheap test, 1426 is unnecessary.? I realize it was like this.?? Same > at 1477, 1532.? I don't think ResourceMarks are expensive either. I'll take a closer look at the various 'log_is_enabled()' calls and how to make things more efficient in general. I have a memory of someone saying that log_is_enabled() is pretty cheap. If memory serves correctly, 'ResourceMark rm' is expensive and 'ResourceMark rm(thread)' is much less expensive, but still has a non-trivial cost. If the parameters to a log_foo() call are expensive to assemble, we don't want to do that only to throw them away because the log_foo() code skips the log output. The call to external_name() which allocates a C-string buffer and translates the Java char string into the C-string is not cheap so I think this is one of the cases where we don't want the log_foo() call to make the decision. Also, the object->is_instance() check may be going away. Neither David nor I can remember why this logging code makes that check so I need to chase that down. > 1652?? if (deflated_count != 0) { > 1653 if (log_is_enabled(Info, monitorinflation)) { > 1654 log_info(monitorinflation)("deflating global idle monitors, %3.7f > secs, %d monitors", timer.seconds(), deflated_count); > 1655 } > 1656 } else { > 1657 if (log_is_enabled(Debug, monitorinflation)) { > 1658 log_debug(monitorinflation)("deflating global idle monitors, > %3.7f secs, 0 monitors", timer.seconds()); > 1659 } > > > log_info/log_debug also ask if log_is_enabled, so the log_is_enabled > test isn't necessary here, and 1673, 1677 and 1664.? I think a lot of > these were early logging changes that weren't caught then. David had a suggested rewrite for these lines in his comments that I'm going to check out. One thing I'm trying to avoid is double output lines if we're at log level Debug. > Duplicating David's comment > > audit_and_print_stats > > can create a LogStream log and use that instead of doing log_info/etc. Yup. I'm going to figure out how to do that. > Instead of > > 2048 if (IncludeInUseMonitorDetailsInLogMsgs) { > > You can add a tag to the logging, so that you can say > -Xlog:monitorinflation+inuse or some such tag. > > It's not worth adding another command line option when logging gives > you the ability to be specific about what output you want. Thanks for chiming in on IncludeInUseMonitorDetailsInLogMsgs. That's another possibility. I'll look at that also. In my reply to David I said: > Thanks for chiming in on IncludeInUseMonitorDetailsInLogMsgs. I tend > to agree hence the question during this review cycle. I'm thinking > that at VM-exit time, it should be at Debug level and at safepoint > time it should be at Trace level. I expect most casual use of > monitorinflation logging to be at the Info level... And this output > is far from casual... so I have two possible solutions to look at... > Lastly, I didn't look at what you're verifying and logging but maybe > the ~300 line function could be split and you could add more tags in > the future to taylor what specific information and verification you > are looking for. I'm not sure what you're suggesting here. > It looks there's a bit of duplication in the logging messages. I wasn't aware of any duplication, but I could have missed somthing... Dan > > Coleen > > On 1/23/19 3:16 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> I have a (S)mall/(M)edium patch extracted from the Async Monitor >> Deflation >> project that is ready for code review. I'm calling this a >> (S)mall/(M)edium >> because the logic changes are (S)mall, but the logging code is >> tedious and >> there's a bunch of it in audit_and_print_stats() so (M)edium. >> >> The short version of what this patch is about: >> >> ??? This sub-task captures updates and additions to the >> ??? baseline monitor logging code. >> >> The details are in the bug report: >> >> ??? JDK-8217659 monitor_logging updates from Async Monitor Deflation >> project >> ??? https://bugs.openjdk.java.net/browse/JDK-8217659 >> >> Here's the webrev: >> >> http://cr.openjdk.java.net/~dcubed/8217659-webrev/0-for-jdk13/ >> >> This patch along with the other two patches for Async Monitor Deflation >> project have been through Mach5 >> builds-tier1,hs-tier1,jdk-tier1,hs-tier2,hs-tier3 >> testing and I'm currently running my stress testing kits on my Linux-X64 >> and Solaris-X64 servers. >> >> I have been actively using this new logging code while debugging my >> port of the Async Monitor Deflation project code. >> >> Thanks, in advance, for any questions, comments or suggestions. >> >> Dan >> > From david.holmes at oracle.com Fri Jan 25 02:46:07 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 25 Jan 2019 12:46:07 +1000 Subject: RFR: 8217618: JVM TI SuspendThread doesn't suspend the current thread before returning Message-ID: <266be0b7-232e-abb5-d308-929fde2f538c@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8217618 webrev: http://cr.openjdk.java.net/~dholmes/8217618/webrev/ Lots of analysis in the bug report. Bottom line: SuspendThread of the current thread was not actually suspending the thread until it hit specific thread-state transitions. That meant that SuspendThread would actually return and continue executing native code whilst suspended, in violation of the specification for it. The fix is quite simple: in java_suspend() we check for the current thread and call java_suspend_self(). Testing: - Any test that looked like it referred to thread suspension - hotspot/jtreg/vmTestbase/nsk/jvmti/* - jdk/ com/sun/jdi/* java/lang/ThreadGroup/Suspend.java java/lang/management/CompositeData/ThreadInfoCompositeData.java java/lang/management/ThreadMXBean/* java/nio/channels/SocketChannel/SendUrgentData.java java/util/logging/LogManager/Configuration/TestConfigurationLock.java - Mach 5 tiers 1-3 (in progress) Two tests were found to be erroneously relying on SuspendThread returning whilst suspended: - vmTestbase/nsk/jvmti/scenarios/sampling/SP05/sp05t003/sp05t003.cpp The test updated a shared counter after the SuspendThread call, but it needed to be updated before the call. - vmTestbase/nsk/jvmti/scenarios/hotswap/HS202/hs202t002/hs202t002.cpp The test was using a 0 return value from SuspendThread as an indicator that the thread was in the suspended state - but that value can't be seen until after SuspendThread returns, which is after the thread is resumed. So I ripped out the custom state tracking logic and replaced with a simple check of GetThreadState. Thanks, David From david.holmes at oracle.com Fri Jan 25 06:45:05 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 25 Jan 2019 16:45:05 +1000 Subject: RFR(M)(round 2): 8215902: Add support for SoftFloat-3e library In-Reply-To: <12e1cb109842f145edf23b4ea5ef591395188de9.camel@gmail.com> References: <4497ca084b9f48dbb8f6de1aa35c83653fd7acfb.camel@gmail.com> <7f69fc73-1c10-6b68-d657-c9e758d4bf1d@oracle.com> <3f62f15e-ac5f-94d4-9744-c9cef796a3fa@oracle.com> <12e1cb109842f145edf23b4ea5ef591395188de9.camel@gmail.com> Message-ID: Hi Jakub, On 25/01/2019 9:17 am, Jakub Van?k wrote: > Hi Magnus, > > thanks for the review! > > I haven't received a review for the hotspot source changes yet, so I > will have to wait. Not an expert on the details of the FP code but the wrapper layer appears okay to me. One nit with the test is that we don't name tests using bug numbers any more, so please rename the test to something more descriptive ... perhaps FloatPrecisionTest.java ? Also on the test, given this wraps a number of FP functions does the test need to be more elaborate to ensure they have all been covered? Thanks, David ----- > Regards, > > Jakub > > On 2019-01-23 at 13:55 +0100, Magnus Ihse Bursie wrote: >> Hi Jakub, >> >> On 2019-01-15 17:31, Jakub Van?k wrote: >>> Hi Magnus and Erik, >>> >>> I have added the link to the repository to README and I have >>> removed >>> the link to the mailing list thread. I have also recreated the >>> GitHub >>> repository. Now it is a fork of the mentioned repository with two >>> extra >>> commits containing README and the build scripts. >>> >>> New webrev URL: >>> http://cr.openjdk.java.net/~jakvanek/8215902/webrev.04/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8215902 >> >> Sorry for the late reply. >> >> This looks very good! Thank you for fixing this, including rebasing >> the >> github repo. >> >> I'm not sure if you've gotten reviews from the hotspot team for the >> hotspot source changes, but from a build perspective, this is good to >> go. >> >> /Magnus >>> >>> Regards, >>> >>> Jakub >>> >>> On 2019-01-15 at 15:05 +0100, Magnus Ihse Bursie wrote: >>>> On 2018-12-25 16:19, Jakub Van?k wrote: >>>>> Hi, >>>>> >>>>> please review this webrev. It is a successor of the softfloat-3 >>>>> [patch] >>>>> thread (first email >>>>> >>> >>> > http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2018-November/031311.html >>>>> ) >>>>> >>>>> Changes since the last patch (v6): >>>>> >>>>> - renamed --with-softloat* to --with-sflt* (it is more compact >>>>> and >>>>> it >>>>> corresponds to the old --with-sflt-lib=... option) >>>>> >>>>> - license is now obtained via --with-sflt-license switch (so it >>>>> is >>>>> not >>>>> included in OpenJDK source tree) >>>>> >>>>> - updated documentation (slight rewording, added the license >>>>> option) >>>>> >>>>> - checks for default --with/--without behavior are in place >>>>> again >>>>> (I forgot them when I changed the way the library is >>>>> detected) >>>>> >>>>> - added a simple testcase - I found a disrepancy between >>>>> softfloat >>>>> and >>>>> system function behavior. When a float with bits 0x003FFFFF >>>>> is >>>>> added to 0x00000001, the correct result is 0x00400000, but >>>>> the >>>>> default software floating point implementation returns >>>>> 0x00000000. >>>>> However I'm not sure where to put this test - now it is in >>>>> test/hotspot/jtreg/compiler/floatingpoint. >>>>> >>>>> - comments in code refer to CR 6757269 and newly JDK-8215902 >>>>> too. >>>>> >>>>> I have created a repository with SoftFloat-3e with build >>>>> configuration >>>>> specifically for OpenJDK on armel: >>>>> https://github.com/ev3dev-lang-java/softfloat-openjdk >>>>> >>>>> I can add a link to it to the documentation. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8215902 >>>>> Webrev: http://cr.openjdk.java.net/~jakvanek/8215902/webrev.02/ >>>> >>>> Hi Jakub, >>>> >>>> In general this looks good. >>>> >>>> Some comments: >>>> >>>> I agree with Erik that you can add a link to your github project; >>>> compiling SoftFloat is outside the scope of the OpenJDK build >>>> instructions, but it can sure be helpful to lower the bar for >>>> users >>>> wanting to do that. Just one question: any particular reason you >>>> didn't >>>> create your github repo by forking the official >>>> https://github.com/ucb-bar/berkeley-softfloat-3? That way, it >>>> would >>>> have >>>> been easy for users to see that you were not adding any malicious >>>> or >>>> suspicious code to the original SoftFloat distribution. >>>> >>>> On the other hand, I think the link to >>>> >>> >>> > http://mail.openjdk.java.net/pipermail/aarch32-port-dev/2016-November/000611.html >>>> >>>> is unnecessary and just creates clutter in the documentation. >>>> Please >>>> remove it. >>>> >>>> /Magnus >>>>> CI build: >>>>> > https://ci.adoptopenjdk.net/view/ev3dev/job/openjdk12_build_ev3_linux/67/ >>>>> >>>>> Cheers, >>>>> >>>>> Jakub >>>>> >> >> > From daniel.daugherty at oracle.com Fri Jan 25 13:43:09 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 25 Jan 2019 08:43:09 -0500 Subject: RFR(S): 8217658 baseline_cleanups from Async Monitor Deflation project In-Reply-To: <63860c8f-4971-e491-d333-d17fa82707c8@oracle.com> References: <653c2aaf-64d5-edbb-d7d7-4f88f7da1c63@oracle.com> <63860c8f-4971-e491-d333-d17fa82707c8@oracle.com> Message-ID: <9a534285-e201-09fa-20f8-e2075a908e98@oracle.com> I missed a couple of comments from David H. below... On 1/24/19 9:05 AM, Daniel D. Daugherty wrote: > On 1/23/19 11:18 PM, David Holmes wrote: >> Hi Dan, >> >> This all seems fine. Some comments below. > > Thanks for the review! > > >> >> One suggested addition to your cleanup :) >> >> ./share/runtime/basicLock.cpp >> >> // [RGV] The next line appears to do nothing! >> ? intptr_t dh = (intptr_t) displaced_header(); >> ? dest->set_displaced_header(displaced_header()); > > Sure. I was confused for a second since I couldn't remember touching > share/runtime/basicLock.cpp in my current project. Of course, you > sending me a cleanup out of the blue reminds me of this other one > you sent me a very long ago: > > ./share/vm/prims/jvmtiExport.cpp:???????????????????? ("JVMTI [%s] > montior contended enter event triggered", > ./share/vm/prims/jvmtiExport.cpp:???????????????????? ("JVMTI [%s] > montior contended entered event triggered", > ./share/vm/prims/jvmtiExport.cpp:???????????????????? ("JVMTI [%s] > montior wait event triggered", > ./share/vm/prims/jvmtiExport.cpp:???????????????????? ("JVMTI [%s] > montior waited event triggered", > > that's been hanging around in my cleanup queue for a while... > > I'll take care of both of these with 8217658. > > Dan > > >> >> On 24/01/2019 6:07 am, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I have a (S)mall patch extracted from the Async Monitor Deflation >>> project that is ready for code review. >>> >>> The short version of what this patch is about: >>> >>> ?? ? This sub-task captures updates to the baseline code that are not >>> ?? ? directly related to Async Monitor Deflation. >>> >>> The details are in the bug report: >>> >>> ???? JDK-8217658 baseline_cleanups from Async Monitor Deflation project >>> ???? https://bugs.openjdk.java.net/browse/JDK-8217658 >>> >>> Here's the webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8217658-webrev/0-for-jdk13/ >> >> To quote your main semantic changes from the bug report: >> >>> - add missing "else" to logical if-else-statement in >>> ? ObjectSynchronizer::get_lock_owner() >> >> Okay - the two conditions are mutually exclusive. Yup. That's my thinking. :-) >> >>> - guarantee that header() is NULL when >>> ? ObjectSynchronizer::omRelease() is called >>> - Replace a set_owner(NULL) call with a set_header(NULL) >>> ? call in the "CASE: neutral" part of ObjectSynchronizer::inflate() >>> ? when the object->cas_set_mark() fails. This is a rare race. >> >> These seem okay but did get me thinking about the different roles of >> ObjectMonitor::Recycle() and ObjectMonitor::clear() and the >> individual clearing of fields! I find it all somewhat confusing The fact that we have Recycle(), clear() and individual clearing of fields scattered throughout the code is a mess. I obviously made small clean ups with this fix, but there's still a lot of craziness. >> - in particular why clear() asserts that _header != NULL ! That's clear()'s way of saying "make sure the ObjectMonitor that we're clearing was actually in use". I'll have to double check that my switch from set_owner(NULL) (which was not needed) to set_header(NULL) (which is needed) won't mess things up. Nothing showed up in testing or in stress testing, but... >> Some explanatory comments on those methods would be appreciated at >> some point during this project. Hmmm... I thinking cleaning up/clarifying Recycle(), clear() and individual clearing of fields would be enough work/analysis to warrant its own bug fix. Might be done as part of this overall project, might be pushed separately (and earlier). Dan >> >> Thanks, >> David >> ----- >> >> >>> >>> This patch along with the other two patches for Async Monitor Deflation >>> project have been through Mach5 >>> builds-tier1,hs-tier1,jdk-tier1,hs-tier2,hs-tier3 >>> testing and I'm currently running my stress testing kits on my >>> Linux-X64 >>> and Solaris-X64 servers. >>> >>> Thanks, in advance, for any questions, comments or suggestions. >>> >>> Dan >>> > > From magnus.ihse.bursie at oracle.com Fri Jan 25 14:56:29 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 25 Jan 2019 15:56:29 +0100 Subject: [PATCH] 8170639: [Linux] jsig is limited to a maximum of 64 signals In-Reply-To: <033d9b60-9ab0-7218-e219-86572bce1e35@oracle.com> References: <31c0913e-6d1c-1298-5634-4f78b21f0a7c@oracle.com> <033d9b60-9ab0-7218-e219-86572bce1e35@oracle.com> Message-ID: On 2018-12-18 01:33, David Holmes wrote: > On 18/12/2018 9:57 am, Ao Qi wrote: >> Hi, >> >> On Tue, Dec 18, 2018 at 4:32 AM David Holmes >> wrote: >>> >>> On 17/12/2018 9:48 pm, Ao Qi wrote: >>>> Hi David Holmes, >>>> >>>> Thanks for your reply. It makes sense. Is it possible to create >>>> another bug ID to fix the problem? >>> >>> I'd prefer to see this fixed properly than point fixed on linux for an >>> unsupported platform. >> >> I thought the problem is "[Linux] jsig is limited to a maximum of 64 >> signals" and the patch was intended to fixed this problem. It just >> didn't use "A better solution", but I think it is better than the >> current situation. > > Better for you but I would prefer to see an overall better solution. > It really shouldn't be very difficult. Compare the AIX version with > your improved Linux version, reconcile any differences, and make it a > shared posix version, then confirm it works on OS X and Solaris. > >> Is zero/mips (or all platforms having more than 64 signals) a >> unsupported platform? > > Yes. We make allowances for Zero as it can support a vast range of > platforms for which no native OpenJDK port exists (in the case of MIPS > that port seems inactive), but in general we don't go out of our way > to make changes in the main code that only benefit such platforms. > > I'm subtly trying to coerce you into making the change I'd like to see > here. ;-) I can assist with build/test on other POSIX platforms. If you are going down that route, I recommend looking at src/java.base/unix/native/libjsig/jsig.c for inspiration. It was recently unified across all unix platforms we currently support, so any special treatment there for a specific platform (I think solaris, macosx and aix have some special stuff going on), is likely to apply to the signal handling inside the VM as well. On the other hand, general solutions that worked in jsig.c is likely to work as well in the VM. /Magnus > > Cheers, > David > >> Cheers, >> Ao Qi >>> >>> Thanks, >>> David >>> >>>> Cheers, >>>> Ao Qi >>>> >>>> On Mon, Dec 17, 2018 at 7:30 PM David Holmes >>>> wrote: >>>>> >>>>> Thanks for reminding me about the rest of the discussion. The >>>>> point of >>>>> the RFE I filed was to examine if we could get a consolidated POSIX >>>>> version using sigset_t. I'd rather see that than a point fix for >>>>> Linux. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>> On 17/12/2018 6:50 pm, Ao Qi wrote: >>>>>> Hi David Holmes, >>>>>> >>>>>> I am not sure what is the specific issue of "NSIG not being >>>>>> defined". >>>>>> Do you mean the issue mentioned in "but I found that NSIG was >>>>>> missing >>>>>> from signal.h on some architectures, mips being among them"[1]? If >>>>>> yes, James Cowgill answered this in [2]. I check it on MIPS, NSIG is >>>>>> defined in signal.h and it is 128. >>>>>> >>>>>> Cheers, >>>>>> Ao Qi >>>>>> >>>>>> [1] >>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-November/025401.html >>>>>> [2] >>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-December/025416.html >>>>>> >>>>>> On Mon, Dec 17, 2018 at 8:02 AM David Holmes >>>>>> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Was the issue of NSIG not being defined resolved? >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>> On 14/12/2018 10:23 pm, Ao Qi wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Zero does not build on Linux MIPS (actually all Linux of NSIG > >>>>>>>> 64) >>>>>>>> since OpenJDK 9, because NISG is 128 on MIPS and can not be >>>>>>>> encoded in >>>>>>>> uint64_t sigs. James Cowgill from Debian tried to push a patch >>>>>>>> fixing >>>>>>>> this[1] but it seems he failed. I would like to try again to >>>>>>>> request >>>>>>>> fixing this in http://hg.openjdk.java.net/jdk/jdk. This was >>>>>>>> fixed in >>>>>>>> AIX implementation. >>>>>>>> >>>>>>>> After applying this patch, zero can be built on MIPS (Debian >>>>>>>> testing). >>>>>>>> I've run the jtreg tests [2] on x86 Linux. >>>>>>>> >>>>>>>> [1] >>>>>>>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-November/025399.html >>>>>>>> [2] >>>>>>>> https://download.java.net/openjdk/testresults/12/docs/howtoruntests.html >>>>>>>> >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Ao Qi >>>>>>>> >>>>>>>> $ hg export -r 52869 >>>>>>>> # HG changeset patch >>>>>>>> # User aoqi >>>>>>>> # Date 1544089853 0 >>>>>>>> #????? Thu Dec 06 09:50:53 2018 +0000 >>>>>>>> # Node ID 3eea22b79dc3a4bf26616bde1acb587e3f56e6fe >>>>>>>> # Parent? b4982a22926b4ddf1a7b1f770e4d42ce8c1dd575 >>>>>>>> 8170639: [Linux] jsig is limited to a maximum of 64 signals >>>>>>>> >>>>>>>> diff -r b4982a22926b -r 3eea22b79dc3 >>>>>>>> src/hotspot/os/linux/os_linux.cpp >>>>>>>> --- a/src/hotspot/os/linux/os_linux.cpp Thu Dec 06 11:54:39 >>>>>>>> 2018 +0530 >>>>>>>> +++ b/src/hotspot/os/linux/os_linux.cpp Thu Dec 06 09:50:53 >>>>>>>> 2018 +0000 >>>>>>>> @@ -4434,10 +4434,7 @@ >>>>>>>> >>>>>>>> ???? // For signal-chaining >>>>>>>> ???? struct sigaction sigact[NSIG]; >>>>>>>> -uint64_t sigs = 0; >>>>>>>> -#if (64 < NSIG-1) >>>>>>>> -#error "Not all signals can be encoded in sigs. Adapt its type!" >>>>>>>> -#endif >>>>>>>> +sigset_t sigs; >>>>>>>> ???? bool os::Linux::libjsig_is_loaded = false; >>>>>>>> ???? typedef struct sigaction *(*get_signal_t)(int); >>>>>>>> ???? get_signal_t os::Linux::get_signal_action = NULL; >>>>>>>> @@ -4516,7 +4513,7 @@ >>>>>>>> ???? } >>>>>>>> >>>>>>>> ???? struct sigaction* os::Linux::get_preinstalled_handler(int >>>>>>>> sig) { >>>>>>>> -? if ((((uint64_t)1 << (sig-1)) & sigs) != 0) { >>>>>>>> +? if (sigismember(&sigs, sig)) { >>>>>>>> ???????? return &sigact[sig]; >>>>>>>> ?????? } >>>>>>>> ?????? return NULL; >>>>>>>> @@ -4525,7 +4522,7 @@ >>>>>>>> ???? void os::Linux::save_preinstalled_handler(int sig, struct >>>>>>>> sigaction& oldAct) { >>>>>>>> ?????? assert(sig > 0 && sig < NSIG, "vm signal out of expected >>>>>>>> range"); >>>>>>>> ?????? sigact[sig] = oldAct; >>>>>>>> -? sigs |= (uint64_t)1 << (sig-1); >>>>>>>> +? sigaddset(&sigs, sig); >>>>>>>> ???? } >>>>>>>> >>>>>>>> ???? // for diagnostic >>>>>>>> @@ -4616,6 +4613,7 @@ >>>>>>>> ?????????? (*begin_signal_setting)(); >>>>>>>> ???????? } >>>>>>>> >>>>>>>> +??? ::sigemptyset(&sigs); >>>>>>>> ???????? set_signal_handler(SIGSEGV, true); >>>>>>>> ???????? set_signal_handler(SIGPIPE, true); >>>>>>>> ???????? set_signal_handler(SIGBUS, true); >>>>>>>> From daniel.daugherty at oracle.com Fri Jan 25 16:13:05 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 25 Jan 2019 11:13:05 -0500 Subject: RFR(S): 8217658 baseline_cleanups from Async Monitor Deflation project In-Reply-To: <9a534285-e201-09fa-20f8-e2075a908e98@oracle.com> References: <653c2aaf-64d5-edbb-d7d7-4f88f7da1c63@oracle.com> <63860c8f-4971-e491-d333-d17fa82707c8@oracle.com> <9a534285-e201-09fa-20f8-e2075a908e98@oracle.com> Message-ID: <22285316-8551-ca82-bc13-e22b902ba425@oracle.com> On 1/25/19 8:43 AM, Daniel D. Daugherty wrote: > I missed a couple of comments from David H. below... > > On 1/24/19 9:05 AM, Daniel D. Daugherty wrote: >> On 1/23/19 11:18 PM, David Holmes wrote: >>> Hi Dan, >>> >>> This all seems fine. Some comments below. >> >> Thanks for the review! >> >> >>> >>> One suggested addition to your cleanup :) >>> >>> ./share/runtime/basicLock.cpp >>> >>> // [RGV] The next line appears to do nothing! >>> ? intptr_t dh = (intptr_t) displaced_header(); >>> ? dest->set_displaced_header(displaced_header()); >> >> Sure. I was confused for a second since I couldn't remember touching >> share/runtime/basicLock.cpp in my current project. Of course, you >> sending me a cleanup out of the blue reminds me of this other one >> you sent me a very long ago: >> >> ./share/vm/prims/jvmtiExport.cpp:???????????????????? ("JVMTI [%s] >> montior contended enter event triggered", >> ./share/vm/prims/jvmtiExport.cpp:???????????????????? ("JVMTI [%s] >> montior contended entered event triggered", >> ./share/vm/prims/jvmtiExport.cpp:???????????????????? ("JVMTI [%s] >> montior wait event triggered", >> ./share/vm/prims/jvmtiExport.cpp:???????????????????? ("JVMTI [%s] >> montior waited event triggered", >> >> that's been hanging around in my cleanup queue for a while... >> >> I'll take care of both of these with 8217658. >> >> Dan >> >> >>> >>> On 24/01/2019 6:07 am, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> I have a (S)mall patch extracted from the Async Monitor Deflation >>>> project that is ready for code review. >>>> >>>> The short version of what this patch is about: >>>> >>>> ?? ? This sub-task captures updates to the baseline code that are not >>>> ?? ? directly related to Async Monitor Deflation. >>>> >>>> The details are in the bug report: >>>> >>>> ???? JDK-8217658 baseline_cleanups from Async Monitor Deflation >>>> project >>>> ???? https://bugs.openjdk.java.net/browse/JDK-8217658 >>>> >>>> Here's the webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8217658-webrev/0-for-jdk13/ >>> >>> To quote your main semantic changes from the bug report: >>> >>>> - add missing "else" to logical if-else-statement in >>>> ? ObjectSynchronizer::get_lock_owner() >>> >>> Okay - the two conditions are mutually exclusive. > > Yup. That's my thinking. :-) > > >>> >>>> - guarantee that header() is NULL when >>>> ? ObjectSynchronizer::omRelease() is called >>>> - Replace a set_owner(NULL) call with a set_header(NULL) >>>> ? call in the "CASE: neutral" part of ObjectSynchronizer::inflate() >>>> ? when the object->cas_set_mark() fails. This is a rare race. >>> >>> These seem okay but did get me thinking about the different roles of >>> ObjectMonitor::Recycle() and ObjectMonitor::clear() and the >>> individual clearing of fields! I find it all somewhat confusing > > The fact that we have Recycle(), clear() and individual clearing of > fields scattered throughout the code is a mess. I obviously made > small clean ups with this fix, but there's still a lot of craziness. > > >>> - in particular why clear() asserts that _header != NULL ! > > That's clear()'s way of saying "make sure the ObjectMonitor that > we're clearing was actually in use". I'll have to double check > that my switch from set_owner(NULL) (which was not needed) to > set_header(NULL) (which is needed) won't mess things up. Nothing > showed up in testing or in stress testing, but... Closing the loop on whether I messed this up... Here's the block where I added set_header(NULL) at L1463: 1462???? if (object->cas_set_mark(markOopDesc::encode(m), mark) != mark) { 1463?????? m->set_header(NULL); 1464?????? m->set_object(NULL); 1465?????? m->Recycle(); 1466?????? omRelease(Self, m, true); 1467?????? m = NULL; 1468?????? continue; For this block, we call Recycle() and omRelease(). The set_header(NULL) is needed to make the new omRelease() guarantee() on L1167 happy: 1165 void ObjectSynchronizer::omRelease(Thread * Self, ObjectMonitor * m, 1166??????????????????????????????????? bool fromPerThreadAlloc) { 1167?? guarantee(m->header() == NULL, "invariant"); 1168?? guarantee(m->object() == NULL, "invariant"); so my addition can't run afoul of clear() because we use Recycle() instead. Right now I'm leaning toward describing these as: Recycle() - recycle a partially used ObjectMonitor for putting ??????????? it back on the free list. clear()?? - clear a fully used ObjectMonitor for putting it ??????????? back on the free list. Of course, I'd have to go visit all the uses of these two and make sure that description holds. That will be a reasonable amount of work to do in a separate issue. Dan > > >>> Some explanatory comments on those methods would be appreciated at >>> some point during this project. > > Hmmm... I thinking cleaning up/clarifying Recycle(), clear() and > individual clearing of fields would be enough work/analysis to > warrant its own bug fix. Might be done as part of this overall > project, might be pushed separately (and earlier). > > Dan > >>> >>> Thanks, >>> David >>> ----- >>> >>> >>>> >>>> This patch along with the other two patches for Async Monitor >>>> Deflation >>>> project have been through Mach5 >>>> builds-tier1,hs-tier1,jdk-tier1,hs-tier2,hs-tier3 >>>> testing and I'm currently running my stress testing kits on my >>>> Linux-X64 >>>> and Solaris-X64 servers. >>>> >>>> Thanks, in advance, for any questions, comments or suggestions. >>>> >>>> Dan >>>> >> >> > > From daniel.daugherty at oracle.com Fri Jan 25 17:38:44 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 25 Jan 2019 12:38:44 -0500 Subject: RFR(S): 8217658 baseline_cleanups from Async Monitor Deflation project In-Reply-To: References: Message-ID: <057e5a67-68e3-95b9-e337-a95928fe59d6@oracle.com> Greetings, I've updated the patch to include the two additional cleanups from David H. I've also rebased the patch to the jdk/jdk repo at the 'jdk-13+5' tag; there were no merge surprises. Here's an incremental webrev: http://cr.openjdk.java.net/~dcubed/8217658-webrev/1-for-jdk13.inc/ I've also generated a full webrev since I still need one more reviewer for this: http://cr.openjdk.java.net/~dcubed/8217658-webrev/1-for-jdk13.full/ I've also updated the bug to talk about the two additional cleanups. Thanks, in advance, for any questions, comments or suggestions. Dan On 1/23/19 3:07 PM, Daniel D. Daugherty wrote: > Greetings, > > I have a (S)mall patch extracted from the Async Monitor Deflation > project that is ready for code review. > > The short version of what this patch is about: > > ? ? This sub-task captures updates to the baseline code that are not > ? ? directly related to Async Monitor Deflation. > > The details are in the bug report: > > ??? JDK-8217658 baseline_cleanups from Async Monitor Deflation project > ??? https://bugs.openjdk.java.net/browse/JDK-8217658 > > Here's the webrev: > > ??? http://cr.openjdk.java.net/~dcubed/8217658-webrev/0-for-jdk13/ > > This patch along with the other two patches for Async Monitor Deflation > project have been through Mach5 > builds-tier1,hs-tier1,jdk-tier1,hs-tier2,hs-tier3 > testing and I'm currently running my stress testing kits on my Linux-X64 > and Solaris-X64 servers. > > Thanks, in advance, for any questions, comments or suggestions. > > Dan > > From serguei.spitsyn at oracle.com Fri Jan 25 18:32:55 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 25 Jan 2019 10:32:55 -0800 Subject: RFR: 8217618: JVM TI SuspendThread doesn't suspend the current thread before returning In-Reply-To: <266be0b7-232e-abb5-d308-929fde2f538c@oracle.com> References: <266be0b7-232e-abb5-d308-929fde2f538c@oracle.com> Message-ID: <1311983c-ebdb-b227-77dd-75532038ab94@oracle.com> Hi David, The fix looks good to me. Thank you for taking care about it! Thanks, Serguei On 1/24/19 6:46 PM, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8217618 > webrev: http://cr.openjdk.java.net/~dholmes/8217618/webrev/ > > Lots of analysis in the bug report. Bottom line: SuspendThread of the > current thread was not actually suspending the thread until it hit > specific thread-state transitions. That meant that SuspendThread would > actually return and continue executing native code whilst suspended, > in violation of the specification for it. > > The fix is quite simple: in java_suspend() we check for the current > thread and call java_suspend_self(). > > Testing: > ?- Any test that looked like it referred to thread suspension > ? - hotspot/jtreg/vmTestbase/nsk/jvmti/* > ? - jdk/ > ???? com/sun/jdi/* > ???? java/lang/ThreadGroup/Suspend.java > java/lang/management/CompositeData/ThreadInfoCompositeData.java > ???? java/lang/management/ThreadMXBean/* > ???? java/nio/channels/SocketChannel/SendUrgentData.java > java/util/logging/LogManager/Configuration/TestConfigurationLock.java > > ?- Mach 5 tiers 1-3 (in progress) > > Two tests were found to be erroneously relying on SuspendThread > returning whilst suspended: > > - vmTestbase/nsk/jvmti/scenarios/sampling/SP05/sp05t003/sp05t003.cpp > > The test updated a shared counter after the SuspendThread call, but it > needed to be updated before the call. > > - vmTestbase/nsk/jvmti/scenarios/hotswap/HS202/hs202t002/hs202t002.cpp > > The test was using a 0 return value from SuspendThread as an indicator > that the thread was in the suspended state - but that value can't be > seen until after SuspendThread returns, which is after the thread is > resumed. So I ripped out the custom state tracking logic and replaced > with a simple check of GetThreadState. > > Thanks, > David From daniel.daugherty at oracle.com Fri Jan 25 19:23:04 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 25 Jan 2019 14:23:04 -0500 Subject: RFR: 8217618: JVM TI SuspendThread doesn't suspend the current thread before returning In-Reply-To: <266be0b7-232e-abb5-d308-929fde2f538c@oracle.com> References: <266be0b7-232e-abb5-d308-929fde2f538c@oracle.com> Message-ID: <09a960d7-9180-8c9f-3fde-f242f8e74d81@oracle.com> On 1/24/19 9:46 PM, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8217618 > webrev: http://cr.openjdk.java.net/~dholmes/8217618/webrev/ src/hotspot/share/runtime/thread.cpp ??? L2364: // Self-suspension will happen on the transition out of the vm. ??????? This comment is no longer accurate and should be deleted. ??? L2365: // Catch "this" coming in from JNIEnv pointers when the thread has been freed ??????? This comment should have been deleted by the Thread-SMR project. ??????? Do you mind deleting it now? test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS202/hs202t002/hs202t002.cpp ??? No comments. test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP05/sp05t003/sp05t003.cpp ??? No comments. Thumbs up! No new webrev needed even if you decide to delete the comments I flagged above. Dan > > Lots of analysis in the bug report. Bottom line: SuspendThread of the > current thread was not actually suspending the thread until it hit > specific thread-state transitions. That meant that SuspendThread would > actually return and continue executing native code whilst suspended, > in violation of the specification for it. > > The fix is quite simple: in java_suspend() we check for the current > thread and call java_suspend_self(). > > Testing: > ?- Any test that looked like it referred to thread suspension > ? - hotspot/jtreg/vmTestbase/nsk/jvmti/* > ? - jdk/ > ???? com/sun/jdi/* > ???? java/lang/ThreadGroup/Suspend.java > java/lang/management/CompositeData/ThreadInfoCompositeData.java > ???? java/lang/management/ThreadMXBean/* > ???? java/nio/channels/SocketChannel/SendUrgentData.java > java/util/logging/LogManager/Configuration/TestConfigurationLock.java > > ?- Mach 5 tiers 1-3 (in progress) > > Two tests were found to be erroneously relying on SuspendThread > returning whilst suspended: > > - vmTestbase/nsk/jvmti/scenarios/sampling/SP05/sp05t003/sp05t003.cpp > > The test updated a shared counter after the SuspendThread call, but it > needed to be updated before the call. > > - vmTestbase/nsk/jvmti/scenarios/hotswap/HS202/hs202t002/hs202t002.cpp > > The test was using a 0 return value from SuspendThread as an indicator > that the thread was in the suspended state - but that value can't be > seen until after SuspendThread returns, which is after the thread is > resumed. So I ripped out the custom state tracking logic and replaced > with a simple check of GetThreadState. > > Thanks, > David From coleen.phillimore at oracle.com Fri Jan 25 20:45:57 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 25 Jan 2019 15:45:57 -0500 Subject: RFR(S/M): 8217659 monitor_logging updates from Async Monitor Deflation project In-Reply-To: References: Message-ID: On 1/24/19 6:52 PM, Daniel D. Daugherty wrote: > Hi Coleen, > > Thanks for the review. Replies embedded below... > > > On 1/24/19 3:39 PM, coleen.phillimore at oracle.com wrote: >> >> http://cr.openjdk.java.net/~dcubed/8217659-webrev/0-for-jdk13/src/hotspot/share/runtime/synchronizer.cpp.frames.html >> >> >> 1426 if (log_is_enabled(Trace, monitorinflation)) { >> 1427???????? if (object->is_instance()) { >> 1428?????????? ResourceMark rm(Self); >> 1429 log_trace(monitorinflation)("inflate(has_locker): " >> 1430?????????????????????????????????????? "object=" INTPTR_FORMAT ", >> mark=" INTPTR_FORMAT ", type='%s'", >> 1431?????????????????????????????????????? p2i(object), >> p2i(object->mark()), >> 1432 object->klass()->external_name()); >> 1433???????? } >> 1434?????? } >> >> It seems like extra overhead to ask if logging is enabled in both >> 1426 and internally in 1429.? It seems that if object->is_instance() >> is a cheap test, 1426 is unnecessary. I realize it was like this.?? >> Same at 1477, 1532.? I don't think ResourceMarks are expensive either. > > I'll take a closer look at the various 'log_is_enabled()' calls > and how to make things more efficient in general. I have a memory > of someone saying that log_is_enabled() is pretty cheap. It is but you're testing it twice unnecessarily in most cases. > > If memory serves correctly, 'ResourceMark rm' is expensive and > 'ResourceMark rm(thread)' is much less expensive, but still has a > non-trivial cost. If the parameters to a log_foo() call are > expensive to assemble, we don't want to do that only to throw them > away because the log_foo() code skips the log output. > > The call to external_name() which allocates a C-string buffer and > translates the Java char string into the C-string is not cheap so > I think this is one of the cases where we don't want the log_foo() > call to make the decision. Yes, this is the canonical example.? If you call as_C_string() or external_name() or some such, testing log_is_enabled() is a good idea.?? It looked like some instances didn't need to check if the logging is enabled first. I think the string formatting doesn't happen if the logging isn't enabled, but, yes, as_C_string() etc will be. > > Also, the object->is_instance() check may be going away. Neither > David nor I can remember why this logging code makes that check > so I need to chase that down. > > ok. > > 1652?? if (deflated_count != 0) { >> 1653 if (log_is_enabled(Info, monitorinflation)) { >> 1654 log_info(monitorinflation)("deflating global idle monitors, >> %3.7f secs, %d monitors", timer.seconds(), deflated_count); >> 1655 } >> 1656 } else { >> 1657 if (log_is_enabled(Debug, monitorinflation)) { >> 1658 log_debug(monitorinflation)("deflating global idle monitors, >> %3.7f secs, 0 monitors", timer.seconds()); >> 1659 } >> >> >> log_info/log_debug also ask if log_is_enabled, so the log_is_enabled >> test isn't necessary here, and 1673, 1677 and 1664.? I think a lot of >> these were early logging changes that weren't caught then. > > David had a suggested rewrite for these lines in his comments that > I'm going to check out. One thing I'm trying to avoid is double > output lines if we're at log level Debug. > > >> Duplicating David's comment >> >> audit_and_print_stats >> >> can create a LogStream log and use that instead of doing log_info/etc. > > Yup. I'm going to figure out how to do that. > > >> Instead of >> >> 2048 if (IncludeInUseMonitorDetailsInLogMsgs) { >> >> You can add a tag to the logging, so that you can say >> -Xlog:monitorinflation+inuse or some such tag. >> >> It's not worth adding another command line option when logging gives >> you the ability to be specific about what output you want. > > Thanks for chiming in on IncludeInUseMonitorDetailsInLogMsgs. > > That's another possibility. I'll look at that also. In my reply > to David I said: > >> Thanks for chiming in on IncludeInUseMonitorDetailsInLogMsgs. I tend >> to agree hence the question during this review cycle. I'm thinking >> that at VM-exit time, it should be at Debug level and at safepoint >> time it should be at Trace level. I expect most casual use of >> monitorinflation logging to be at the Info level... And this output >> is far from casual... > > so I have two possible solutions to look at... > > >> Lastly, I didn't look at what you're verifying and logging but maybe >> the ~300 line function could be split and you could add more tags in >> the future to taylor what specific information and verification you >> are looking for. > > I'm not sure what you're suggesting here. The suggestion is to break this function up into smaller functions that aren't so mind numbing to read through.? Maybe it just looked like duplication after a while, but naming the thing you're verifying with a function name would be easier to understand.? And you might want to add more logging tags to some of the checks/functions, if you have some specific thing that you're interested in the future. thanks, Coleen > > >> It looks there's a bit of duplication in the logging messages. > > I wasn't aware of any duplication, but I could have missed somthing... > > Dan > > >> >> Coleen >> >> On 1/23/19 3:16 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I have a (S)mall/(M)edium patch extracted from the Async Monitor >>> Deflation >>> project that is ready for code review. I'm calling this a >>> (S)mall/(M)edium >>> because the logic changes are (S)mall, but the logging code is >>> tedious and >>> there's a bunch of it in audit_and_print_stats() so (M)edium. >>> >>> The short version of what this patch is about: >>> >>> ??? This sub-task captures updates and additions to the >>> ??? baseline monitor logging code. >>> >>> The details are in the bug report: >>> >>> ??? JDK-8217659 monitor_logging updates from Async Monitor Deflation >>> project >>> ??? https://bugs.openjdk.java.net/browse/JDK-8217659 >>> >>> Here's the webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8217659-webrev/0-for-jdk13/ >>> >>> This patch along with the other two patches for Async Monitor Deflation >>> project have been through Mach5 >>> builds-tier1,hs-tier1,jdk-tier1,hs-tier2,hs-tier3 >>> testing and I'm currently running my stress testing kits on my >>> Linux-X64 >>> and Solaris-X64 servers. >>> >>> I have been actively using this new logging code while debugging my >>> port of the Async Monitor Deflation project code. >>> >>> Thanks, in advance, for any questions, comments or suggestions. >>> >>> Dan >>> >> > From claes.redestad at oracle.com Fri Jan 25 21:14:08 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 25 Jan 2019 22:14:08 +0100 Subject: RFR(T): 8217841: Remove unused class TraceCPUTime Message-ID: <67cdd044-d89a-289d-edba-5b8de1979b8d@oracle.com> Hi, TraceCPUTime is not used anywhere. Bug: https://bugs.openjdk.java.net/browse/JDK-8217841 Webrev: http://cr.openjdk.java.net/~redestad/8217841/open.00/ Testing: tier1 (ongoing) Thanks! /Claes From daniel.daugherty at oracle.com Fri Jan 25 21:22:45 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 25 Jan 2019 16:22:45 -0500 Subject: RFR(S/M): 8217659 monitor_logging updates from Async Monitor Deflation project In-Reply-To: References: Message-ID: <19f9d589-184a-4ff2-db3a-6952bb5c4fb7@oracle.com> On 1/25/19 3:45 PM, coleen.phillimore at oracle.com wrote: > On 1/24/19 6:52 PM, Daniel D. Daugherty wrote: >> Hi Coleen, >> >> Thanks for the review. Replies embedded below... >> >> >> On 1/24/19 3:39 PM, coleen.phillimore at oracle.com wrote: >>> >>> http://cr.openjdk.java.net/~dcubed/8217659-webrev/0-for-jdk13/src/hotspot/share/runtime/synchronizer.cpp.frames.html >>> >>> >>> 1426 if (log_is_enabled(Trace, monitorinflation)) { >>> 1427???????? if (object->is_instance()) { >>> 1428?????????? ResourceMark rm(Self); >>> 1429 log_trace(monitorinflation)("inflate(has_locker): " >>> 1430?????????????????????????????????????? "object=" INTPTR_FORMAT >>> ", mark=" INTPTR_FORMAT ", type='%s'", >>> 1431?????????????????????????????????????? p2i(object), >>> p2i(object->mark()), >>> 1432 object->klass()->external_name()); >>> 1433???????? } >>> 1434?????? } >>> >>> It seems like extra overhead to ask if logging is enabled in both >>> 1426 and internally in 1429.? It seems that if object->is_instance() >>> is a cheap test, 1426 is unnecessary. I realize it was like this.?? >>> Same at 1477, 1532.? I don't think ResourceMarks are expensive either. >> >> I'll take a closer look at the various 'log_is_enabled()' calls >> and how to make things more efficient in general. I have a memory >> of someone saying that log_is_enabled() is pretty cheap. > > It is but you're testing it twice unnecessarily in most cases. I'll be looking at making the log_is_enabled() calls efficient. >> >> If memory serves correctly, 'ResourceMark rm' is expensive and >> 'ResourceMark rm(thread)' is much less expensive, but still has a >> non-trivial cost. If the parameters to a log_foo() call are >> expensive to assemble, we don't want to do that only to throw them >> away because the log_foo() code skips the log output. >> >> The call to external_name() which allocates a C-string buffer and >> translates the Java char string into the C-string is not cheap so >> I think this is one of the cases where we don't want the log_foo() >> call to make the decision. > > Yes, this is the canonical example.? If you call as_C_string() or > external_name() or some such, testing log_is_enabled() is a good > idea.?? It looked like some instances didn't need to check if the > logging is enabled first. > > I think the string formatting doesn't happen if the logging isn't > enabled, but, yes, as_C_string() etc will be. I'll be looking at making the log_is_enabled() calls efficient for the trivial logging calls. > >> >> Also, the object->is_instance() check may be going away. Neither >> David nor I can remember why this logging code makes that check >> so I need to chase that down. >> >> > ok. > >> > 1652?? if (deflated_count != 0) { >>> 1653 if (log_is_enabled(Info, monitorinflation)) { >>> 1654 log_info(monitorinflation)("deflating global idle monitors, >>> %3.7f secs, %d monitors", timer.seconds(), deflated_count); >>> 1655 } >>> 1656 } else { >>> 1657 if (log_is_enabled(Debug, monitorinflation)) { >>> 1658 log_debug(monitorinflation)("deflating global idle monitors, >>> %3.7f secs, 0 monitors", timer.seconds()); >>> 1659 } >>> >>> >>> log_info/log_debug also ask if log_is_enabled, so the log_is_enabled >>> test isn't necessary here, and 1673, 1677 and 1664.? I think a lot >>> of these were early logging changes that weren't caught then. >> >> David had a suggested rewrite for these lines in his comments that >> I'm going to check out. One thing I'm trying to avoid is double >> output lines if we're at log level Debug. >> >> >>> Duplicating David's comment >>> >>> audit_and_print_stats >>> >>> can create a LogStream log and use that instead of doing log_info/etc. >> >> Yup. I'm going to figure out how to do that. >> >> >>> Instead of >>> >>> 2048 if (IncludeInUseMonitorDetailsInLogMsgs) { >>> >>> You can add a tag to the logging, so that you can say >>> -Xlog:monitorinflation+inuse or some such tag. >>> >>> It's not worth adding another command line option when logging gives >>> you the ability to be specific about what output you want. >> >> Thanks for chiming in on IncludeInUseMonitorDetailsInLogMsgs. >> >> That's another possibility. I'll look at that also. In my reply >> to David I said: >> >>> Thanks for chiming in on IncludeInUseMonitorDetailsInLogMsgs. I tend >>> to agree hence the question during this review cycle. I'm thinking >>> that at VM-exit time, it should be at Debug level and at safepoint >>> time it should be at Trace level. I expect most casual use of >>> monitorinflation logging to be at the Info level... And this output >>> is far from casual... >> >> so I have two possible solutions to look at... >> >> >>> Lastly, I didn't look at what you're verifying and logging but maybe >>> the ~300 line function could be split and you could add more tags in >>> the future to taylor what specific information and verification you >>> are looking for. >> >> I'm not sure what you're suggesting here. > > The suggestion is to break this function up into smaller functions > that aren't so mind numbing to read through.? Maybe it just looked > like duplication after a while, but naming the thing you're verifying > with a function name would be easier to understand. Okay. Now I'm grok'ing what you're saying. > And you might want to add more logging tags to some of the > checks/functions, if you have some specific thing that you're > interested in the future. For this bug, I'll likely keep the tag as 'monitorinflation' and use logging Levels to differentiate. Obviously, as work continues on the Async Monitor Deflation piece, the need for some new logging tags may present itself... Dan > > thanks, > Coleen > >> >> >>> It looks there's a bit of duplication in the logging messages. >> >> I wasn't aware of any duplication, but I could have missed somthing... >> >> Dan >> >> >>> >>> Coleen >>> >>> On 1/23/19 3:16 PM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> I have a (S)mall/(M)edium patch extracted from the Async Monitor >>>> Deflation >>>> project that is ready for code review. I'm calling this a >>>> (S)mall/(M)edium >>>> because the logic changes are (S)mall, but the logging code is >>>> tedious and >>>> there's a bunch of it in audit_and_print_stats() so (M)edium. >>>> >>>> The short version of what this patch is about: >>>> >>>> ??? This sub-task captures updates and additions to the >>>> ??? baseline monitor logging code. >>>> >>>> The details are in the bug report: >>>> >>>> ??? JDK-8217659 monitor_logging updates from Async Monitor >>>> Deflation project >>>> ??? https://bugs.openjdk.java.net/browse/JDK-8217659 >>>> >>>> Here's the webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8217659-webrev/0-for-jdk13/ >>>> >>>> This patch along with the other two patches for Async Monitor >>>> Deflation >>>> project have been through Mach5 >>>> builds-tier1,hs-tier1,jdk-tier1,hs-tier2,hs-tier3 >>>> testing and I'm currently running my stress testing kits on my >>>> Linux-X64 >>>> and Solaris-X64 servers. >>>> >>>> I have been actively using this new logging code while debugging my >>>> port of the Async Monitor Deflation project code. >>>> >>>> Thanks, in advance, for any questions, comments or suggestions. >>>> >>>> Dan >>>> >>> >> > From daniel.daugherty at oracle.com Sat Jan 26 01:47:27 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 25 Jan 2019 20:47:27 -0500 Subject: RFR(S/M): 8217659 monitor_logging updates from Async Monitor Deflation project In-Reply-To: <66c9e7c1-540c-fd03-3fe3-f17fb9a83f09@oracle.com> References: <0b24c9d7-9f1c-6c62-9a08-66d3ecaf545c@oracle.com> <66c9e7c1-540c-fd03-3fe3-f17fb9a83f09@oracle.com> Message-ID: <1aec57f9-1f48-5fda-d277-3be1ce13f847@oracle.com> On 1/24/19 9:27 AM, Daniel D. Daugherty wrote: > On 1/24/19 2:41 AM, David Holmes wrote: > >> + // I'm not sure why the baseline monitorinflation logic only >> + // issues logging mesgs for instance objects. >> + //????? if (obj->is_instance()) { >> >> This needs to be resolved. > > Yes, that would be why I left that comment in for the review. :-) > I'll check the code history for the original monitor deflation > logging code and see if I can discern a reason. So I tracked back that check to: $ sgv -r1.65 src/share/vm/runtime/synchronizer.cpp | grep 'if (object->is_instance())' 1.65 1.65??????? if (object->is_instance()) { $ sp -r1.65 synchronizer.cpp SCCS/s.synchronizer.cpp: D 1.65 05/06/17 17:01:01 kbr 127 125??? 00085/00002/00728 MRs: COMMENTS: 6264252 Improve uncontended synchronization performance That bug ID (6264252) might sound familiar... It's the integration of Biased Locking into the system. I'm guessing that Ken needed this block for debugging: >?? if (TraceMonitorInflation) { >???? if (object->is_instance()) { >?????? ResourceMark rm; >?????? tty->print_cr("Inflating object " INTPTR_FORMAT " , mark " INTPTR_FORMAT " , type %s", >???????????????????? (intptr_t) object, (intptr_t) object->mark(), Klass::cast(object->klass())->external_name()); >???? } >?? } and that the is_instance() check was a way of reducing the debug output. > >> If the alternative to being an instance is being an array, then I >> think we should be logging for those too (that might actually catch >> use of the class initialization monitors). > > In my debugging of a recent test failure, I saw logging output > for and inflated "[I" at the end of the VM's life (IIRC)... I'm planning to drop the 'if (obj->is_instance())' checks and I'll verify what happens with the Trace logging. Dan From daniel.daugherty at oracle.com Sat Jan 26 02:03:07 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 25 Jan 2019 21:03:07 -0500 Subject: RFR(S/M): 8217659 monitor_logging updates from Async Monitor Deflation project In-Reply-To: <66c9e7c1-540c-fd03-3fe3-f17fb9a83f09@oracle.com> References: <0b24c9d7-9f1c-6c62-9a08-66d3ecaf545c@oracle.com> <66c9e7c1-540c-fd03-3fe3-f17fb9a83f09@oracle.com> Message-ID: On 1/24/19 9:27 AM, Daniel D. Daugherty wrote: > On 1/24/19 2:41 AM, David Holmes wrote: > >> When we have different Info versus Debug logging eg: >> >> !?? if (deflated_count != 0) { >> !???? if (log_is_enabled(Info, monitorinflation)) { >> !?????? log_info(monitorinflation)("deflating global idle monitors, >> %3.7f secs, %d monitors", timer.seconds(), deflated_count); >> !???? } >> !?? } else { >> !???? if (log_is_enabled(Debug, monitorinflation)) { >> !?????? log_debug(monitorinflation)("deflating global idle monitors, >> %3.7f secs, 0 monitors", timer.seconds()); >> !???? } >> !?? } >> >> is it possible to rewrite that as: >> >> ?if (log_is_enabled( deflated_count != 0 ? Info : Debug, >> ??????????????????? monitorinflation)) { >> !?????? log_info(monitorinflation)("deflating global idle monitors, >> %3.7f secs, %d monitors", timer.seconds(), deflated_count); >> !???? } >> >> or does the logging macro-magic not allow it? > > Good question. I'll check it out. Closing the loop on this question: /work/shared/bug_hunt/8183909/8217659_exp/open/src/hotspot/share/runtime/synchronizer.cpp:1653:22: error: expected unqualified-id ? if (log_is_enabled((deflated_count != 0) ? Info : Debug, monitorinflation)) { ???????????????????? ^ /work/shared/bug_hunt/8183909/8217659_exp/open/src/hotspot/share/runtime/synchronizer.cpp:1653:46: error: use of undeclared identifier 'Info'; did you mean 'LogLevel::Info'? ? if (log_is_enabled((deflated_count != 0) ? Info : Debug, monitorinflation)) { ???????????????????????????????????????????? ^~~~ ???????????????????????????????????????????? LogLevel::Info /work/shared/bug_hunt/8183909/8217659_exp/open/src/hotspot/share/logging/log.hpp:69:88: note: expanded from macro 'log_is_enabled' #define log_is_enabled(level, ...) (LogImpl::is_level(LogLevel::level)) ?????? ^ /work/shared/bug_hunt/8183909/8217659_exp/open/src/hotspot/share/logging/logLevel.hpp:57:5: note: 'LogLevel::Info' declared here ??? LOG_LEVEL_LIST ??? ^ /work/shared/bug_hunt/8183909/8217659_exp/open/src/hotspot/share/logging/logLevel.hpp:48:13: note: expanded from macro 'LOG_LEVEL_LIST' ? LOG_LEVEL(Info, info) \ ??????????? ^ /work/shared/bug_hunt/8183909/8217659_exp/open/src/hotspot/share/runtime/synchronizer.cpp:1653:53: error: use of undeclared identifier 'Debug'; did you mean 'LogLevel::Debug'? ? if (log_is_enabled((deflated_count != 0) ? Info : Debug, monitorinflation)) { ??????????????????????????????????????????????????? ^~~~~ LogLevel::Debug /work/shared/bug_hunt/8183909/8217659_exp/open/src/hotspot/share/logging/log.hpp:69:88: note: expanded from macro 'log_is_enabled' #define log_is_enabled(level, ...) (LogImpl::is_level(LogLevel::level)) ?????? ^ /work/shared/bug_hunt/8183909/8217659_exp/open/src/hotspot/share/logging/logLevel.hpp:57:5: note: 'LogLevel::Debug' declared here ??? LOG_LEVEL_LIST ??? ^ /work/shared/bug_hunt/8183909/8217659_exp/open/src/hotspot/share/logging/logLevel.hpp:47:13: note: expanded from macro 'LOG_LEVEL_LIST' ? LOG_LEVEL(Debug, debug) \ ??????????? ^ 3 errors generated. Yeah, the macro stuff was definitely not happy, but I think I have come up with a different simplification... Dan From david.holmes at oracle.com Sat Jan 26 02:46:10 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 26 Jan 2019 12:46:10 +1000 Subject: RFR(S): 8217658 baseline_cleanups from Async Monitor Deflation project In-Reply-To: <057e5a67-68e3-95b9-e337-a95928fe59d6@oracle.com> References: <057e5a67-68e3-95b9-e337-a95928fe59d6@oracle.com> Message-ID: <6c389750-b92c-7cb7-76ef-60d49b116148@oracle.com> Thanks Dan, incremental changes look good. David On 26/01/2019 3:38 am, Daniel D. Daugherty wrote: > Greetings, > > I've updated the patch to include the two additional cleanups from David H. > I've also rebased the patch to the jdk/jdk repo at the 'jdk-13+5' tag; > there were no merge surprises. > > Here's an incremental webrev: > > http://cr.openjdk.java.net/~dcubed/8217658-webrev/1-for-jdk13.inc/ > > I've also generated a full webrev since I still need one more reviewer > for this: > > http://cr.openjdk.java.net/~dcubed/8217658-webrev/1-for-jdk13.full/ > > I've also updated the bug to talk about the two additional cleanups. > > Thanks, in advance, for any questions, comments or suggestions. > > Dan > > > On 1/23/19 3:07 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> I have a (S)mall patch extracted from the Async Monitor Deflation >> project that is ready for code review. >> >> The short version of what this patch is about: >> >> ? ? This sub-task captures updates to the baseline code that are not >> ? ? directly related to Async Monitor Deflation. >> >> The details are in the bug report: >> >> ??? JDK-8217658 baseline_cleanups from Async Monitor Deflation project >> ??? https://bugs.openjdk.java.net/browse/JDK-8217658 >> >> Here's the webrev: >> >> ??? http://cr.openjdk.java.net/~dcubed/8217658-webrev/0-for-jdk13/ >> >> This patch along with the other two patches for Async Monitor Deflation >> project have been through Mach5 >> builds-tier1,hs-tier1,jdk-tier1,hs-tier2,hs-tier3 >> testing and I'm currently running my stress testing kits on my Linux-X64 >> and Solaris-X64 servers. >> >> Thanks, in advance, for any questions, comments or suggestions. >> >> Dan >> >> > From david.holmes at oracle.com Sat Jan 26 02:53:03 2019 From: david.holmes at oracle.com (David Holmes) Date: Sat, 26 Jan 2019 12:53:03 +1000 Subject: RFR(T): 8217841: Remove unused class TraceCPUTime In-Reply-To: <67cdd044-d89a-289d-edba-5b8de1979b8d@oracle.com> References: <67cdd044-d89a-289d-edba-5b8de1979b8d@oracle.com> Message-ID: <3317ebb5-ace2-4065-1e87-4d83f00799b8@oracle.com> Looks fine. I wonder when it stopped being used ... Cheers, David On 26/01/2019 7:14 am, Claes Redestad wrote: > Hi, > > TraceCPUTime is not used anywhere. > > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8217841 > Webrev: http://cr.openjdk.java.net/~redestad/8217841/open.00/ > > Testing: tier1 (ongoing) > > Thanks! > > /Claes From daniel.daugherty at oracle.com Sat Jan 26 03:46:35 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Fri, 25 Jan 2019 22:46:35 -0500 Subject: RFR(S): 8217658 baseline_cleanups from Async Monitor Deflation project In-Reply-To: <6c389750-b92c-7cb7-76ef-60d49b116148@oracle.com> References: <057e5a67-68e3-95b9-e337-a95928fe59d6@oracle.com> <6c389750-b92c-7cb7-76ef-60d49b116148@oracle.com> Message-ID: <7fb13885-e2ff-bb82-b8ca-ed168576ae10@oracle.com> David, Thanks for the re-review. Still hoping for one more reviewer... Dan On 1/25/19 9:46 PM, David Holmes wrote: > Thanks Dan, incremental changes look good. > > David > > On 26/01/2019 3:38 am, Daniel D. Daugherty wrote: >> Greetings, >> >> I've updated the patch to include the two additional cleanups from >> David H. >> I've also rebased the patch to the jdk/jdk repo at the 'jdk-13+5' tag; >> there were no merge surprises. >> >> Here's an incremental webrev: >> >> http://cr.openjdk.java.net/~dcubed/8217658-webrev/1-for-jdk13.inc/ >> >> I've also generated a full webrev since I still need one more >> reviewer for this: >> >> http://cr.openjdk.java.net/~dcubed/8217658-webrev/1-for-jdk13.full/ >> >> I've also updated the bug to talk about the two additional cleanups. >> >> Thanks, in advance, for any questions, comments or suggestions. >> >> Dan >> >> >> On 1/23/19 3:07 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I have a (S)mall patch extracted from the Async Monitor Deflation >>> project that is ready for code review. >>> >>> The short version of what this patch is about: >>> >>> ? ? This sub-task captures updates to the baseline code that are not >>> ? ? directly related to Async Monitor Deflation. >>> >>> The details are in the bug report: >>> >>> ??? JDK-8217658 baseline_cleanups from Async Monitor Deflation project >>> ??? https://bugs.openjdk.java.net/browse/JDK-8217658 >>> >>> Here's the webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8217658-webrev/0-for-jdk13/ >>> >>> This patch along with the other two patches for Async Monitor Deflation >>> project have been through Mach5 >>> builds-tier1,hs-tier1,jdk-tier1,hs-tier2,hs-tier3 >>> testing and I'm currently running my stress testing kits on my >>> Linux-X64 >>> and Solaris-X64 servers. >>> >>> Thanks, in advance, for any questions, comments or suggestions. >>> >>> Dan >>> >>> >> From daniel.daugherty at oracle.com Sun Jan 27 03:10:17 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Sat, 26 Jan 2019 22:10:17 -0500 Subject: RFR(S/M): 8217659 monitor_logging updates from Async Monitor Deflation project In-Reply-To: References: Message-ID: <98f74cf8-1634-c0ad-0bbc-7c2d8e31a467@oracle.com> Greetings, I've updated the patch to resolve code review comments from David H. and Coleen. I've also rebased the patch to the jdk/jdk repo at the 'jdk-13+5' tag (plus the 8217658 patch); there were no merge surprises. Here's an incremental webrev: http://cr.openjdk.java.net/~dcubed/8217659-webrev/1-for-jdk13.inc/ I've also generated a full webrev since the changes to synchronizer.cpp are extensive and that's the easier way to review it: http://cr.openjdk.java.net/~dcubed/8217659-webrev/1-for-jdk13.full/ This patch along with 8217658 have been through Mach5 builds-tier1,hs-tier1,jdk-tier1,hs-tier2,hs-tier3 testing with no failures. Thanks, in advance, for any questions, comments or suggestions. Dan P.S. I've attached sample output for running Hello.java with the monitorinflation logging enabled at Info, Debug and Trace. On 1/23/19 3:16 PM, Daniel D. Daugherty wrote: > Greetings, > > I have a (S)mall/(M)edium patch extracted from the Async Monitor > Deflation > project that is ready for code review. I'm calling this a > (S)mall/(M)edium > because the logic changes are (S)mall, but the logging code is tedious > and > there's a bunch of it in audit_and_print_stats() so (M)edium. > > The short version of what this patch is about: > > ??? This sub-task captures updates and additions to the > ??? baseline monitor logging code. > > The details are in the bug report: > > ??? JDK-8217659 monitor_logging updates from Async Monitor Deflation > project > ??? https://bugs.openjdk.java.net/browse/JDK-8217659 > > Here's the webrev: > > ??? http://cr.openjdk.java.net/~dcubed/8217659-webrev/0-for-jdk13/ > > This patch along with the other two patches for Async Monitor Deflation > project have been through Mach5 > builds-tier1,hs-tier1,jdk-tier1,hs-tier2,hs-tier3 > testing and I'm currently running my stress testing kits on my Linux-X64 > and Solaris-X64 servers. > > I have been actively using this new logging code while debugging my > port of the Async Monitor Deflation project code. > > Thanks, in advance, for any questions, comments or suggestions. > > Dan > > -------------- next part -------------- [0.105s][info][monitorinflation] deflating per-thread idle monitors, 0.0000021 secs, 2 monitors Hello world! [0.141s][info][monitorinflation] Global Lists: InUse Free Total [0.141s][info][monitorinflation] ================== ========== ========== ========== [0.141s][info][monitorinflation] 0 33 127 [0.141s][info][monitorinflation] Per-Thread Lists: InUse Free Provision [0.141s][info][monitorinflation] ================== ========== ========== ========== [0.141s][info][monitorinflation] 0x00007fdd8c030800 0 31 49 [0.141s][info][monitorinflation] 0x00007fdd8c929800 1 30 49 [0.141s][info][monitorinflation] 0x00007fdd8c03e000 0 0 32 [0.141s][info][monitorinflation] 0x00007fdd8c959000 0 0 32 [0.141s][info][monitorinflation] 0x00007fdd8c931000 0 0 32 [0.141s][info][monitorinflation] 0x00007fdd8c03c000 0 0 32 [0.141s][info][monitorinflation] 0x00007fdd8c920800 1 31 49 [0.141s][info][monitorinflation] Checking global lists: [0.141s][info][monitorinflation] gMonitorPopulation=127 equals ckMonitorPopulation=127 [0.141s][info][monitorinflation] gOmInUseCount=0 equals ckOmInUseCount=0 [0.141s][info][monitorinflation] gMonitorFreeCount=33 equals ckMonitorFreeCount=33 [0.141s][info][monitorinflation] Checking per-thread lists: [0.141s][info][monitorinflation] jt=0x00007fdd8c030800: omInUseCount=0 equals ckOmInUseCount=0 [0.141s][info][monitorinflation] jt=0x00007fdd8c030800: omFreeCount=31 equals ckOmFreeCount=31 [0.141s][info][monitorinflation] jt=0x00007fdd8c929800: omInUseCount=1 equals ckOmInUseCount=1 [0.141s][info][monitorinflation] jt=0x00007fdd8c929800: omFreeCount=30 equals ckOmFreeCount=30 [0.141s][info][monitorinflation] jt=0x00007fdd8c03e000: omInUseCount=0 equals ckOmInUseCount=0 [0.141s][info][monitorinflation] jt=0x00007fdd8c03e000: omFreeCount=0 equals ckOmFreeCount=0 [0.141s][info][monitorinflation] jt=0x00007fdd8c959000: omInUseCount=0 equals ckOmInUseCount=0 [0.141s][info][monitorinflation] jt=0x00007fdd8c959000: omFreeCount=0 equals ckOmFreeCount=0 [0.141s][info][monitorinflation] jt=0x00007fdd8c931000: omInUseCount=0 equals ckOmInUseCount=0 [0.141s][info][monitorinflation] jt=0x00007fdd8c931000: omFreeCount=0 equals ckOmFreeCount=0 [0.141s][info][monitorinflation] jt=0x00007fdd8c03c000: omInUseCount=0 equals ckOmInUseCount=0 [0.141s][info][monitorinflation] jt=0x00007fdd8c03c000: omFreeCount=0 equals ckOmFreeCount=0 [0.141s][info][monitorinflation] jt=0x00007fdd8c920800: omInUseCount=1 equals ckOmInUseCount=1 [0.141s][info][monitorinflation] jt=0x00007fdd8c920800: omFreeCount=31 equals ckOmFreeCount=31 [0.141s][info][monitorinflation] No errors found in monitor list checks. [0.141s][info][monitorinflation] In-use per-thread monitor info: [0.141s][info][monitorinflation] (B -> is_busy, H -> has hashcode, L -> lock status) [0.141s][info][monitorinflation] jt monitor BHL object object type [0.141s][info][monitorinflation] ================== ================== === ================== ================== [0.141s][info][monitorinflation] 0x00007fdd8c929800 0x00007fdd8c035580 100 0x000000070ff02790 java.lang.ref.ReferenceQueue$Lock [0.141s][info][monitorinflation] 0x00007fdd8c920800 0x00007fdd8c037480 100 0x000000070ff90b50 java.lang.ref.ReferenceQueue$Lock -------------- next part -------------- [0.245s][debug][monitorinflation] deflating global idle monitors, 0.0000001 secs, 0 monitors [0.245s][info ][monitorinflation] deflating per-thread idle monitors, 0.0000021 secs, 1 monitors [0.245s][info ][monitorinflation] Global Lists: InUse Free Total [0.245s][info ][monitorinflation] ================== ========== ========== ========== [0.245s][info ][monitorinflation] 0 96 127 [0.245s][info ][monitorinflation] Per-Thread Lists: InUse Free Provision [0.245s][info ][monitorinflation] ================== ========== ========== ========== [0.245s][info ][monitorinflation] 0x00007fccbb00c000 0 0 32 [0.245s][info ][monitorinflation] 0x00007fccbb102800 0 0 32 [0.245s][info ][monitorinflation] 0x00007fccbb106000 1 30 49 [0.245s][info ][monitorinflation] 0x00007fccbb104800 0 0 32 [0.245s][info ][monitorinflation] 0x00007fccbb112000 0 0 32 [0.245s][info ][monitorinflation] 0x00007fccbc001000 0 0 32 [0.245s][info ][monitorinflation] 0x00007fccbc004000 0 0 32 [0.245s][info ][monitorinflation] 0x00007fccbc002000 0 0 32 [0.245s][info ][monitorinflation] Checking global lists: [0.245s][info ][monitorinflation] gMonitorPopulation=127 equals ckMonitorPopulation=127 [0.245s][info ][monitorinflation] gOmInUseCount=0 equals ckOmInUseCount=0 [0.245s][info ][monitorinflation] gMonitorFreeCount=96 equals ckMonitorFreeCount=96 [0.245s][info ][monitorinflation] Checking per-thread lists: [0.245s][info ][monitorinflation] jt=0x00007fccbb00c000: omInUseCount=0 equals ckOmInUseCount=0 [0.245s][info ][monitorinflation] jt=0x00007fccbb00c000: omFreeCount=0 equals ckOmFreeCount=0 [0.245s][info ][monitorinflation] jt=0x00007fccbb102800: omInUseCount=0 equals ckOmInUseCount=0 [0.245s][info ][monitorinflation] jt=0x00007fccbb102800: omFreeCount=0 equals ckOmFreeCount=0 [0.245s][info ][monitorinflation] jt=0x00007fccbb106000: omInUseCount=1 equals ckOmInUseCount=1 [0.245s][info ][monitorinflation] jt=0x00007fccbb106000: omFreeCount=30 equals ckOmFreeCount=30 [0.245s][info ][monitorinflation] jt=0x00007fccbb104800: omInUseCount=0 equals ckOmInUseCount=0 [0.245s][info ][monitorinflation] jt=0x00007fccbb104800: omFreeCount=0 equals ckOmFreeCount=0 [0.245s][info ][monitorinflation] jt=0x00007fccbb112000: omInUseCount=0 equals ckOmInUseCount=0 [0.245s][info ][monitorinflation] jt=0x00007fccbb112000: omFreeCount=0 equals ckOmFreeCount=0 [0.245s][info ][monitorinflation] jt=0x00007fccbc001000: omInUseCount=0 equals ckOmInUseCount=0 [0.245s][info ][monitorinflation] jt=0x00007fccbc001000: omFreeCount=0 equals ckOmFreeCount=0 [0.245s][info ][monitorinflation] jt=0x00007fccbc004000: omInUseCount=0 equals ckOmInUseCount=0 [0.245s][info ][monitorinflation] jt=0x00007fccbc004000: omFreeCount=0 equals ckOmFreeCount=0 [0.245s][info ][monitorinflation] jt=0x00007fccbc002000: omInUseCount=0 equals ckOmInUseCount=0 [0.245s][info ][monitorinflation] jt=0x00007fccbc002000: omFreeCount=0 equals ckOmFreeCount=0 [0.245s][info ][monitorinflation] No errors found in monitor list checks. [0.266s][debug][monitorinflation] deflating global idle monitors, 0.0000001 secs, 0 monitors [0.266s][debug][monitorinflation] deflating per-thread idle monitors, 0.0000011 secs, 0 monitors [0.266s][info ][monitorinflation] Global Lists: InUse Free Total [0.266s][info ][monitorinflation] ================== ========== ========== ========== [0.266s][info ][monitorinflation] 0 96 127 [0.266s][info ][monitorinflation] Per-Thread Lists: InUse Free Provision [0.266s][info ][monitorinflation] ================== ========== ========== ========== [0.266s][info ][monitorinflation] 0x00007fccbb00c000 0 0 32 [0.266s][info ][monitorinflation] 0x00007fccbb102800 0 0 32 [0.266s][info ][monitorinflation] 0x00007fccbb106000 1 30 49 [0.266s][info ][monitorinflation] 0x00007fccbb104800 0 0 32 [0.266s][info ][monitorinflation] 0x00007fccbb112000 0 0 32 [0.266s][info ][monitorinflation] 0x00007fccbc001000 0 0 32 [0.266s][info ][monitorinflation] 0x00007fccbc004000 0 0 32 [0.266s][info ][monitorinflation] 0x00007fccbc002000 0 0 32 [0.266s][info ][monitorinflation] 0x00007fccbb110000 0 0 32 [0.266s][info ][monitorinflation] Checking global lists: [0.266s][info ][monitorinflation] gMonitorPopulation=127 equals ckMonitorPopulation=127 [0.266s][info ][monitorinflation] gOmInUseCount=0 equals ckOmInUseCount=0 [0.266s][info ][monitorinflation] gMonitorFreeCount=96 equals ckMonitorFreeCount=96 [0.266s][info ][monitorinflation] Checking per-thread lists: [0.266s][info ][monitorinflation] jt=0x00007fccbb00c000: omInUseCount=0 equals ckOmInUseCount=0 [0.266s][info ][monitorinflation] jt=0x00007fccbb00c000: omFreeCount=0 equals ckOmFreeCount=0 [0.266s][info ][monitorinflation] jt=0x00007fccbb102800: omInUseCount=0 equals ckOmInUseCount=0 [0.266s][info ][monitorinflation] jt=0x00007fccbb102800: omFreeCount=0 equals ckOmFreeCount=0 [0.266s][info ][monitorinflation] jt=0x00007fccbb106000: omInUseCount=1 equals ckOmInUseCount=1 [0.266s][info ][monitorinflation] jt=0x00007fccbb106000: omFreeCount=30 equals ckOmFreeCount=30 [0.266s][info ][monitorinflation] jt=0x00007fccbb104800: omInUseCount=0 equals ckOmInUseCount=0 [0.266s][info ][monitorinflation] jt=0x00007fccbb104800: omFreeCount=0 equals ckOmFreeCount=0 [0.266s][info ][monitorinflation] jt=0x00007fccbb112000: omInUseCount=0 equals ckOmInUseCount=0 [0.266s][info ][monitorinflation] jt=0x00007fccbb112000: omFreeCount=0 equals ckOmFreeCount=0 [0.266s][info ][monitorinflation] jt=0x00007fccbc001000: omInUseCount=0 equals ckOmInUseCount=0 [0.266s][info ][monitorinflation] jt=0x00007fccbc001000: omFreeCount=0 equals ckOmFreeCount=0 [0.266s][info ][monitorinflation] jt=0x00007fccbc004000: omInUseCount=0 equals ckOmInUseCount=0 [0.266s][info ][monitorinflation] jt=0x00007fccbc004000: omFreeCount=0 equals ckOmFreeCount=0 [0.266s][info ][monitorinflation] jt=0x00007fccbc002000: omInUseCount=0 equals ckOmInUseCount=0 [0.266s][info ][monitorinflation] jt=0x00007fccbc002000: omFreeCount=0 equals ckOmFreeCount=0 [0.266s][info ][monitorinflation] jt=0x00007fccbb110000: omInUseCount=0 equals ckOmInUseCount=0 [0.266s][info ][monitorinflation] jt=0x00007fccbb110000: omFreeCount=0 equals ckOmFreeCount=0 [0.266s][info ][monitorinflation] No errors found in monitor list checks. Hello world! [0.300s][debug][monitorinflation] deflating global idle monitors, 0.0000001 secs, 0 monitors [0.301s][debug][monitorinflation] deflating per-thread idle monitors, 0.0000017 secs, 0 monitors [0.301s][info ][monitorinflation] Global Lists: InUse Free Total [0.301s][info ][monitorinflation] ================== ========== ========== ========== [0.301s][info ][monitorinflation] 0 64 127 [0.301s][info ][monitorinflation] Per-Thread Lists: InUse Free Provision [0.301s][info ][monitorinflation] ================== ========== ========== ========== [0.301s][info ][monitorinflation] 0x00007fccbb102800 0 0 32 [0.301s][info ][monitorinflation] 0x00007fccbb106000 1 30 49 [0.301s][info ][monitorinflation] 0x00007fccbb112000 0 0 32 [0.301s][info ][monitorinflation] 0x00007fccbc001000 0 0 32 [0.301s][info ][monitorinflation] 0x00007fccbc004000 0 0 32 [0.301s][info ][monitorinflation] 0x00007fccbc002000 0 0 32 [0.301s][info ][monitorinflation] 0x00007fccbb110000 1 31 49 [0.301s][info ][monitorinflation] Checking global lists: [0.301s][info ][monitorinflation] gMonitorPopulation=127 equals ckMonitorPopulation=127 [0.301s][info ][monitorinflation] gOmInUseCount=0 equals ckOmInUseCount=0 [0.301s][info ][monitorinflation] gMonitorFreeCount=64 equals ckMonitorFreeCount=64 [0.301s][info ][monitorinflation] Checking per-thread lists: [0.301s][info ][monitorinflation] jt=0x00007fccbb102800: omInUseCount=0 equals ckOmInUseCount=0 [0.301s][info ][monitorinflation] jt=0x00007fccbb102800: omFreeCount=0 equals ckOmFreeCount=0 [0.301s][info ][monitorinflation] jt=0x00007fccbb106000: omInUseCount=1 equals ckOmInUseCount=1 [0.301s][info ][monitorinflation] jt=0x00007fccbb106000: omFreeCount=30 equals ckOmFreeCount=30 [0.301s][info ][monitorinflation] jt=0x00007fccbb112000: omInUseCount=0 equals ckOmInUseCount=0 [0.301s][info ][monitorinflation] jt=0x00007fccbb112000: omFreeCount=0 equals ckOmFreeCount=0 [0.301s][info ][monitorinflation] jt=0x00007fccbc001000: omInUseCount=0 equals ckOmInUseCount=0 [0.301s][info ][monitorinflation] jt=0x00007fccbc001000: omFreeCount=0 equals ckOmFreeCount=0 [0.301s][info ][monitorinflation] jt=0x00007fccbc004000: omInUseCount=0 equals ckOmInUseCount=0 [0.301s][info ][monitorinflation] jt=0x00007fccbc004000: omFreeCount=0 equals ckOmFreeCount=0 [0.301s][info ][monitorinflation] jt=0x00007fccbc002000: omInUseCount=0 equals ckOmInUseCount=0 [0.301s][info ][monitorinflation] jt=0x00007fccbc002000: omFreeCount=0 equals ckOmFreeCount=0 [0.301s][info ][monitorinflation] jt=0x00007fccbb110000: omInUseCount=1 equals ckOmInUseCount=1 [0.301s][info ][monitorinflation] jt=0x00007fccbb110000: omFreeCount=31 equals ckOmFreeCount=31 [0.301s][info ][monitorinflation] No errors found in monitor list checks. [0.324s][info ][monitorinflation] Global Lists: InUse Free Total [0.324s][info ][monitorinflation] ================== ========== ========== ========== [0.324s][info ][monitorinflation] 0 64 127 [0.324s][info ][monitorinflation] Per-Thread Lists: InUse Free Provision [0.324s][info ][monitorinflation] ================== ========== ========== ========== [0.324s][info ][monitorinflation] 0x00007fccbb102800 0 0 32 [0.324s][info ][monitorinflation] 0x00007fccbb106000 1 30 49 [0.324s][info ][monitorinflation] 0x00007fccbb112000 0 0 32 [0.324s][info ][monitorinflation] 0x00007fccbc001000 0 0 32 [0.324s][info ][monitorinflation] 0x00007fccbc004000 0 0 32 [0.324s][info ][monitorinflation] 0x00007fccbc002000 0 0 32 [0.324s][info ][monitorinflation] 0x00007fccbb110000 1 31 49 [0.324s][info ][monitorinflation] Checking global lists: [0.324s][info ][monitorinflation] gMonitorPopulation=127 equals ckMonitorPopulation=127 [0.324s][info ][monitorinflation] gOmInUseCount=0 equals ckOmInUseCount=0 [0.324s][info ][monitorinflation] gMonitorFreeCount=64 equals ckMonitorFreeCount=64 [0.324s][info ][monitorinflation] Checking per-thread lists: [0.324s][info ][monitorinflation] jt=0x00007fccbb102800: omInUseCount=0 equals ckOmInUseCount=0 [0.324s][info ][monitorinflation] jt=0x00007fccbb102800: omFreeCount=0 equals ckOmFreeCount=0 [0.324s][info ][monitorinflation] jt=0x00007fccbb106000: omInUseCount=1 equals ckOmInUseCount=1 [0.324s][info ][monitorinflation] jt=0x00007fccbb106000: omFreeCount=30 equals ckOmFreeCount=30 [0.324s][info ][monitorinflation] jt=0x00007fccbb112000: omInUseCount=0 equals ckOmInUseCount=0 [0.324s][info ][monitorinflation] jt=0x00007fccbb112000: omFreeCount=0 equals ckOmFreeCount=0 [0.324s][info ][monitorinflation] jt=0x00007fccbc001000: omInUseCount=0 equals ckOmInUseCount=0 [0.324s][info ][monitorinflation] jt=0x00007fccbc001000: omFreeCount=0 equals ckOmFreeCount=0 [0.324s][info ][monitorinflation] jt=0x00007fccbc004000: omInUseCount=0 equals ckOmInUseCount=0 [0.324s][info ][monitorinflation] jt=0x00007fccbc004000: omFreeCount=0 equals ckOmFreeCount=0 [0.324s][info ][monitorinflation] jt=0x00007fccbc002000: omInUseCount=0 equals ckOmInUseCount=0 [0.324s][info ][monitorinflation] jt=0x00007fccbc002000: omFreeCount=0 equals ckOmFreeCount=0 [0.324s][info ][monitorinflation] jt=0x00007fccbb110000: omInUseCount=1 equals ckOmInUseCount=1 [0.324s][info ][monitorinflation] jt=0x00007fccbb110000: omFreeCount=31 equals ckOmFreeCount=31 [0.324s][info ][monitorinflation] No errors found in monitor list checks. [0.324s][info ][monitorinflation] In-use per-thread monitor info: [0.324s][info ][monitorinflation] (B -> is_busy, H -> has hashcode, L -> lock status) [0.324s][info ][monitorinflation] jt monitor BHL object object type [0.324s][info ][monitorinflation] ================== ================== === ================== ================== [0.324s][info ][monitorinflation] 0x00007fccbb106000 0x00007fccbb108d80 100 0x000000070ff02790 java.lang.ref.ReferenceQueue$Lock [0.324s][info ][monitorinflation] 0x00007fccbb110000 0x00007fccbb10ad80 100 0x000000070ff90b50 java.lang.ref.ReferenceQueue$Lock -------------- next part -------------- [0.054s][trace][monitorinflation] inflate(has_locker): object=0x000000070ff00250, mark=0x00007fa136004282, type='[I' [0.054s][trace][monitorinflation] inflate(has_locker): object=0x000000070ff01ee0, mark=0x00007fa13490d882, type='java.lang.Object' [0.063s][trace][monitorinflation] inflate(has_locker): object=0x000000070ff02790, mark=0x00007fa13490d782, type='java.lang.ref.ReferenceQueue$Lock' [0.114s][trace][monitorinflation] deflate_monitor: object=0x000000070ff00250, mark=0x00007fa136004282, type='[I' [0.114s][trace][monitorinflation] deflate_monitor: object=0x000000070ff01ee0, mark=0x00007fa13490d882, type='java.lang.Object' [0.114s][info ][monitorinflation] deflating global idle monitors, 0.0000001 secs, 0 monitors [0.114s][info ][monitorinflation] deflating per-thread idle monitors, 0.0000277 secs, 2 monitors [0.114s][info ][monitorinflation] Global Lists: InUse Free Total [0.114s][info ][monitorinflation] ================== ========== ========== ========== [0.114s][info ][monitorinflation] 0 160 254 [0.114s][info ][monitorinflation] Per-Thread Lists: InUse Free Provision [0.114s][info ][monitorinflation] ================== ========== ========== ========== [0.114s][info ][monitorinflation] 0x00007fa135006000 0 32 49 [0.114s][info ][monitorinflation] 0x00007fa134906800 0 31 49 [0.114s][info ][monitorinflation] 0x00007fa13600e800 1 30 49 [0.114s][info ][monitorinflation] 0x00007fa135807800 0 0 32 [0.114s][info ][monitorinflation] 0x00007fa13580b000 0 0 32 [0.114s][info ][monitorinflation] 0x00007fa13480d000 0 0 32 [0.114s][info ][monitorinflation] 0x00007fa134913000 0 0 32 [0.114s][info ][monitorinflation] 0x00007fa136010000 0 0 32 [0.114s][info ][monitorinflation] Checking global lists: [0.114s][info ][monitorinflation] gMonitorPopulation=254 equals ckMonitorPopulation=254 [0.114s][info ][monitorinflation] gOmInUseCount=0 equals ckOmInUseCount=0 [0.114s][info ][monitorinflation] gMonitorFreeCount=160 equals ckMonitorFreeCount=160 [0.114s][info ][monitorinflation] Checking per-thread lists: [0.114s][info ][monitorinflation] jt=0x00007fa135006000: omInUseCount=0 equals ckOmInUseCount=0 [0.114s][info ][monitorinflation] jt=0x00007fa135006000: omFreeCount=32 equals ckOmFreeCount=32 [0.114s][info ][monitorinflation] jt=0x00007fa134906800: omInUseCount=0 equals ckOmInUseCount=0 [0.114s][info ][monitorinflation] jt=0x00007fa134906800: omFreeCount=31 equals ckOmFreeCount=31 [0.114s][info ][monitorinflation] jt=0x00007fa13600e800: omInUseCount=1 equals ckOmInUseCount=1 [0.114s][info ][monitorinflation] jt=0x00007fa13600e800: omFreeCount=30 equals ckOmFreeCount=30 [0.114s][info ][monitorinflation] jt=0x00007fa135807800: omInUseCount=0 equals ckOmInUseCount=0 [0.114s][info ][monitorinflation] jt=0x00007fa135807800: omFreeCount=0 equals ckOmFreeCount=0 [0.114s][info ][monitorinflation] jt=0x00007fa13580b000: omInUseCount=0 equals ckOmInUseCount=0 [0.114s][info ][monitorinflation] jt=0x00007fa13580b000: omFreeCount=0 equals ckOmFreeCount=0 [0.114s][info ][monitorinflation] jt=0x00007fa13480d000: omInUseCount=0 equals ckOmInUseCount=0 [0.114s][info ][monitorinflation] jt=0x00007fa13480d000: omFreeCount=0 equals ckOmFreeCount=0 [0.114s][info ][monitorinflation] jt=0x00007fa134913000: omInUseCount=0 equals ckOmInUseCount=0 [0.114s][info ][monitorinflation] jt=0x00007fa134913000: omFreeCount=0 equals ckOmFreeCount=0 [0.114s][info ][monitorinflation] jt=0x00007fa136010000: omInUseCount=0 equals ckOmInUseCount=0 [0.114s][info ][monitorinflation] jt=0x00007fa136010000: omFreeCount=0 equals ckOmFreeCount=0 [0.114s][info ][monitorinflation] No errors found in monitor list checks. [0.114s][info ][monitorinflation] In-use per-thread monitor info: [0.114s][info ][monitorinflation] (B -> is_busy, H -> has hashcode, L -> lock status) [0.114s][info ][monitorinflation] jt monitor BHL object object type [0.114s][info ][monitorinflation] ================== ================== === ================== ================== [0.114s][info ][monitorinflation] 0x00007fa13600e800 0x00007fa13490d780 100 0x000000070ff02790 java.lang.ref.ReferenceQueue$Lock [0.126s][info ][monitorinflation] deflating global idle monitors, 0.0000001 secs, 0 monitors [0.127s][debug][monitorinflation] deflating per-thread idle monitors, 0.0000011 secs, 0 monitors [0.127s][info ][monitorinflation] Global Lists: InUse Free Total [0.127s][info ][monitorinflation] ================== ========== ========== ========== [0.127s][info ][monitorinflation] 0 160 254 [0.127s][info ][monitorinflation] Per-Thread Lists: InUse Free Provision [0.127s][info ][monitorinflation] ================== ========== ========== ========== [0.127s][info ][monitorinflation] 0x00007fa135006000 0 32 49 [0.127s][info ][monitorinflation] 0x00007fa134906800 0 31 49 [0.127s][info ][monitorinflation] 0x00007fa13600e800 1 30 49 [0.127s][info ][monitorinflation] 0x00007fa135807800 0 0 32 [0.127s][info ][monitorinflation] 0x00007fa13580b000 0 0 32 [0.127s][info ][monitorinflation] 0x00007fa13480d000 0 0 32 [0.127s][info ][monitorinflation] 0x00007fa134913000 0 0 32 [0.127s][info ][monitorinflation] 0x00007fa136010000 0 0 32 [0.127s][info ][monitorinflation] 0x00007fa136011000 0 0 32 [0.127s][info ][monitorinflation] Checking global lists: [0.127s][info ][monitorinflation] gMonitorPopulation=254 equals ckMonitorPopulation=254 [0.127s][info ][monitorinflation] gOmInUseCount=0 equals ckOmInUseCount=0 [0.127s][info ][monitorinflation] gMonitorFreeCount=160 equals ckMonitorFreeCount=160 [0.127s][info ][monitorinflation] Checking per-thread lists: [0.127s][info ][monitorinflation] jt=0x00007fa135006000: omInUseCount=0 equals ckOmInUseCount=0 [0.127s][info ][monitorinflation] jt=0x00007fa135006000: omFreeCount=32 equals ckOmFreeCount=32 [0.127s][info ][monitorinflation] jt=0x00007fa134906800: omInUseCount=0 equals ckOmInUseCount=0 [0.127s][info ][monitorinflation] jt=0x00007fa134906800: omFreeCount=31 equals ckOmFreeCount=31 [0.127s][info ][monitorinflation] jt=0x00007fa13600e800: omInUseCount=1 equals ckOmInUseCount=1 [0.127s][info ][monitorinflation] jt=0x00007fa13600e800: omFreeCount=30 equals ckOmFreeCount=30 [0.127s][info ][monitorinflation] jt=0x00007fa135807800: omInUseCount=0 equals ckOmInUseCount=0 [0.127s][info ][monitorinflation] jt=0x00007fa135807800: omFreeCount=0 equals ckOmFreeCount=0 [0.127s][info ][monitorinflation] jt=0x00007fa13580b000: omInUseCount=0 equals ckOmInUseCount=0 [0.127s][info ][monitorinflation] jt=0x00007fa13580b000: omFreeCount=0 equals ckOmFreeCount=0 [0.127s][info ][monitorinflation] jt=0x00007fa13480d000: omInUseCount=0 equals ckOmInUseCount=0 [0.127s][info ][monitorinflation] jt=0x00007fa13480d000: omFreeCount=0 equals ckOmFreeCount=0 [0.127s][info ][monitorinflation] jt=0x00007fa134913000: omInUseCount=0 equals ckOmInUseCount=0 [0.127s][info ][monitorinflation] jt=0x00007fa134913000: omFreeCount=0 equals ckOmFreeCount=0 [0.127s][info ][monitorinflation] jt=0x00007fa136010000: omInUseCount=0 equals ckOmInUseCount=0 [0.127s][info ][monitorinflation] jt=0x00007fa136010000: omFreeCount=0 equals ckOmFreeCount=0 [0.127s][info ][monitorinflation] jt=0x00007fa136011000: omInUseCount=0 equals ckOmInUseCount=0 [0.127s][info ][monitorinflation] jt=0x00007fa136011000: omFreeCount=0 equals ckOmFreeCount=0 [0.127s][info ][monitorinflation] No errors found in monitor list checks. [0.127s][info ][monitorinflation] In-use per-thread monitor info: [0.127s][info ][monitorinflation] (B -> is_busy, H -> has hashcode, L -> lock status) [0.127s][info ][monitorinflation] jt monitor BHL object object type [0.127s][info ][monitorinflation] ================== ================== === ================== ================== [0.127s][info ][monitorinflation] 0x00007fa13600e800 0x00007fa13490d780 100 0x000000070ff02790 java.lang.ref.ReferenceQueue$Lock [0.127s][trace][monitorinflation] inflate(has_locker): object=0x000000070ff90b80, mark=0x00007fa13490f682, type='java.lang.ref.ReferenceQueue$Lock' Hello world! [0.139s][info ][monitorinflation] deflating global idle monitors, 0.0000001 secs, 0 monitors [0.139s][debug][monitorinflation] deflating per-thread idle monitors, 0.0000015 secs, 0 monitors [0.139s][info ][monitorinflation] Global Lists: InUse Free Total [0.139s][info ][monitorinflation] ================== ========== ========== ========== [0.139s][info ][monitorinflation] 0 160 254 [0.139s][info ][monitorinflation] Per-Thread Lists: InUse Free Provision [0.139s][info ][monitorinflation] ================== ========== ========== ========== [0.139s][info ][monitorinflation] 0x00007fa134906800 0 31 49 [0.139s][info ][monitorinflation] 0x00007fa13600e800 1 30 49 [0.139s][info ][monitorinflation] 0x00007fa13580b000 0 0 32 [0.139s][info ][monitorinflation] 0x00007fa13480d000 0 0 32 [0.139s][info ][monitorinflation] 0x00007fa134913000 0 0 32 [0.139s][info ][monitorinflation] 0x00007fa136010000 0 0 32 [0.139s][info ][monitorinflation] 0x00007fa136011000 1 31 49 [0.139s][info ][monitorinflation] Checking global lists: [0.139s][info ][monitorinflation] gMonitorPopulation=254 equals ckMonitorPopulation=254 [0.139s][info ][monitorinflation] gOmInUseCount=0 equals ckOmInUseCount=0 [0.139s][info ][monitorinflation] gMonitorFreeCount=160 equals ckMonitorFreeCount=160 [0.139s][info ][monitorinflation] Checking per-thread lists: [0.139s][info ][monitorinflation] jt=0x00007fa134906800: omInUseCount=0 equals ckOmInUseCount=0 [0.139s][info ][monitorinflation] jt=0x00007fa134906800: omFreeCount=31 equals ckOmFreeCount=31 [0.139s][info ][monitorinflation] jt=0x00007fa13600e800: omInUseCount=1 equals ckOmInUseCount=1 [0.139s][info ][monitorinflation] jt=0x00007fa13600e800: omFreeCount=30 equals ckOmFreeCount=30 [0.139s][info ][monitorinflation] jt=0x00007fa13580b000: omInUseCount=0 equals ckOmInUseCount=0 [0.139s][info ][monitorinflation] jt=0x00007fa13580b000: omFreeCount=0 equals ckOmFreeCount=0 [0.139s][info ][monitorinflation] jt=0x00007fa13480d000: omInUseCount=0 equals ckOmInUseCount=0 [0.139s][info ][monitorinflation] jt=0x00007fa13480d000: omFreeCount=0 equals ckOmFreeCount=0 [0.139s][info ][monitorinflation] jt=0x00007fa134913000: omInUseCount=0 equals ckOmInUseCount=0 [0.139s][info ][monitorinflation] jt=0x00007fa134913000: omFreeCount=0 equals ckOmFreeCount=0 [0.139s][info ][monitorinflation] jt=0x00007fa136010000: omInUseCount=0 equals ckOmInUseCount=0 [0.139s][info ][monitorinflation] jt=0x00007fa136010000: omFreeCount=0 equals ckOmFreeCount=0 [0.139s][info ][monitorinflation] jt=0x00007fa136011000: omInUseCount=1 equals ckOmInUseCount=1 [0.139s][info ][monitorinflation] jt=0x00007fa136011000: omFreeCount=31 equals ckOmFreeCount=31 [0.139s][info ][monitorinflation] No errors found in monitor list checks. [0.139s][info ][monitorinflation] In-use per-thread monitor info: [0.139s][info ][monitorinflation] (B -> is_busy, H -> has hashcode, L -> lock status) [0.139s][info ][monitorinflation] jt monitor BHL object object type [0.139s][info ][monitorinflation] ================== ================== === ================== ================== [0.139s][info ][monitorinflation] 0x00007fa13600e800 0x00007fa13490d780 100 0x000000070ff02790 java.lang.ref.ReferenceQueue$Lock [0.139s][info ][monitorinflation] 0x00007fa136011000 0x00007fa13490f680 100 0x000000070ff90b80 java.lang.ref.ReferenceQueue$Lock [0.155s][info ][monitorinflation] Global Lists: InUse Free Total [0.155s][info ][monitorinflation] ================== ========== ========== ========== [0.155s][info ][monitorinflation] 0 160 254 [0.155s][info ][monitorinflation] Per-Thread Lists: InUse Free Provision [0.155s][info ][monitorinflation] ================== ========== ========== ========== [0.155s][info ][monitorinflation] 0x00007fa134906800 0 31 49 [0.155s][info ][monitorinflation] 0x00007fa13600e800 1 30 49 [0.155s][info ][monitorinflation] 0x00007fa13580b000 0 0 32 [0.155s][info ][monitorinflation] 0x00007fa13480d000 0 0 32 [0.155s][info ][monitorinflation] 0x00007fa134913000 0 0 32 [0.155s][info ][monitorinflation] 0x00007fa136010000 0 0 32 [0.155s][info ][monitorinflation] 0x00007fa136011000 1 31 49 [0.155s][info ][monitorinflation] Checking global lists: [0.155s][info ][monitorinflation] gMonitorPopulation=254 equals ckMonitorPopulation=254 [0.155s][info ][monitorinflation] gOmInUseCount=0 equals ckOmInUseCount=0 [0.155s][info ][monitorinflation] gMonitorFreeCount=160 equals ckMonitorFreeCount=160 [0.155s][info ][monitorinflation] Checking per-thread lists: [0.155s][info ][monitorinflation] jt=0x00007fa134906800: omInUseCount=0 equals ckOmInUseCount=0 [0.155s][info ][monitorinflation] jt=0x00007fa134906800: omFreeCount=31 equals ckOmFreeCount=31 [0.155s][info ][monitorinflation] jt=0x00007fa13600e800: omInUseCount=1 equals ckOmInUseCount=1 [0.155s][info ][monitorinflation] jt=0x00007fa13600e800: omFreeCount=30 equals ckOmFreeCount=30 [0.155s][info ][monitorinflation] jt=0x00007fa13580b000: omInUseCount=0 equals ckOmInUseCount=0 [0.155s][info ][monitorinflation] jt=0x00007fa13580b000: omFreeCount=0 equals ckOmFreeCount=0 [0.155s][info ][monitorinflation] jt=0x00007fa13480d000: omInUseCount=0 equals ckOmInUseCount=0 [0.155s][info ][monitorinflation] jt=0x00007fa13480d000: omFreeCount=0 equals ckOmFreeCount=0 [0.155s][info ][monitorinflation] jt=0x00007fa134913000: omInUseCount=0 equals ckOmInUseCount=0 [0.155s][info ][monitorinflation] jt=0x00007fa134913000: omFreeCount=0 equals ckOmFreeCount=0 [0.155s][info ][monitorinflation] jt=0x00007fa136010000: omInUseCount=0 equals ckOmInUseCount=0 [0.155s][info ][monitorinflation] jt=0x00007fa136010000: omFreeCount=0 equals ckOmFreeCount=0 [0.155s][info ][monitorinflation] jt=0x00007fa136011000: omInUseCount=1 equals ckOmInUseCount=1 [0.155s][info ][monitorinflation] jt=0x00007fa136011000: omFreeCount=31 equals ckOmFreeCount=31 [0.155s][info ][monitorinflation] No errors found in monitor list checks. [0.155s][info ][monitorinflation] In-use per-thread monitor info: [0.155s][info ][monitorinflation] (B -> is_busy, H -> has hashcode, L -> lock status) [0.155s][info ][monitorinflation] jt monitor BHL object object type [0.155s][info ][monitorinflation] ================== ================== === ================== ================== [0.155s][info ][monitorinflation] 0x00007fa13600e800 0x00007fa13490d780 100 0x000000070ff02790 java.lang.ref.ReferenceQueue$Lock [0.155s][info ][monitorinflation] 0x00007fa136011000 0x00007fa13490f680 100 0x000000070ff90b80 java.lang.ref.ReferenceQueue$Lock From claes.redestad at oracle.com Sun Jan 27 21:07:09 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Sun, 27 Jan 2019 22:07:09 +0100 Subject: RFR(T): 8217841: Remove unused class TraceCPUTime In-Reply-To: <3317ebb5-ace2-4065-1e87-4d83f00799b8@oracle.com> References: <67cdd044-d89a-289d-edba-5b8de1979b8d@oracle.com> <3317ebb5-ace2-4065-1e87-4d83f00799b8@oracle.com> Message-ID: <854d71f8-e08c-e248-2396-a5a0c52a7a90@oracle.com> On 2019-01-26 03:53, David Holmes wrote: > Looks fine. Thanks! > > I wonder when it stopped being used ... 8u has some uses in GC code, but seems all usages were switched over to a new GCTraceCPUTime class in 9: https://bugs.openjdk.java.net/browse/JDK-8145092 /Claes From goetz.lindenmaier at sap.com Mon Jan 28 10:22:00 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 28 Jan 2019 10:22:00 +0000 Subject: RFR(M): 8217628: Verbose ArrayIndexOutOfBoundsException message also in JNI In-Reply-To: <8b1ed15e-2569-ffad-79aa-95d29340523c@oracle.com> References: <8b1ed15e-2569-ffad-79aa-95d29340523c@oracle.com> Message-ID: <6cfec56213c44995bd24426f8fa982f0@sap.com> Hi, Here a new webrev: http://cr.openjdk.java.net/~goetz/wr19/8217628-AIOOBE_msg_jni/03/ (David, sorry, I missed the list in my mail Friday...) Messages are capitalized, the method is refactored (definitely better!). Thanks to Martin and Mathias who pointed me to the build error of the lib on solaris ?? This now passed jdk/submit. Best regards, Goetz. > -----Original Message----- > From: David Holmes > Sent: Donnerstag, 24. Januar 2019 01:40 > To: Lindenmaier, Goetz ; hotspot-runtime- > dev at openjdk.java.net > Subject: Re: RFR(M): 8217628: Verbose ArrayIndexOutOfBoundsException > message also in JNI > > Hi Goetz, > > On 24/01/2019 12:37 am, Lindenmaier, Goetz wrote: > > Hi > > > > Change JDK-8201593 > : Print array length in ArrayIndexOutOfBoundsException > > introduced text as "Index 13 out of bounds for length 10" to various AIOOB > exceptions > > thrown in the VM. It omitted the exceptions thrown in jni calls. > > > > This change extends the messages to the AIOOB exceptions thrown in > > Get|SetObjectArrayElement and Get|SetArrayRegion. > > > > Before, Get|SetObjectArrayElement printed just the index, > > Get|SetArrayRegion printed no message. > > > > Now the following messages are printed: > > "Index %d out of bounds for length %d" > > "length %d is negative" > > "array region %d..%d out of bounds for length %d" > > > > Any advice on capitalizing the first word? It's already > > handled inconsistently... > > I'd suggest capitalizing. > > > Please review: > > http://cr.openjdk.java.net/~goetz/wr19/8217628-AIOOBE_msg_jni/01/ > > Could I ask that you factor the region check into a small function so we > don't duplicate the logic please. It would take TRAPS and would be > called with a CHECK. > > Thanks, > David > ----- > > > > > > > Best regards, > > > > Goetz. > > From thomas.schatzl at oracle.com Mon Jan 28 11:45:58 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Mon, 28 Jan 2019 12:45:58 +0100 Subject: RFR (M): 8217778: StringTable cleanup miscalculates amount of dead objects In-Reply-To: <2140b41eb336ec5260b68eefd010c670a0b7a4ca.camel@oracle.com> References: <2140b41eb336ec5260b68eefd010c670a0b7a4ca.camel@oracle.com> Message-ID: <7a944a8567e8768986f3c72a030b0538cc71ebd9.camel@oracle.com> Hi again, cc'ed hotspot-runtime-dev since it concerns the string table. Also, this patch is based on the changes for JDK-8213229. Thanks, Thomas On Mon, 2019-01-28 at 12:43 +0100, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that tries to fix the issue with > the string table reporting too low "dead" numbers to the > ServiceThread notification mechanism in the review for JDK-8213229, > potentially causing C heap memory being kept live for longer than > necessary? > > This change implements one option for fixing this, in particular that > the WeakProcessor calls OopStorage::oops_do() instead of > ::weak_oops_do, counting the number of NULL entries manually. > > There is another, let weak_oops_do() return the number of NULL > entries as function return value. However the return value of the > used iterate_safepoint() is already in use in some I'd consider > interesting test case. I did not want to add another out-parameter > either. > > Since the WeakProcessor has been the main user of the weak_oops_do() > method, I would suggest to clean this up preferably in an extra CR: > there is still one use of the OopStorage::weak_oops_do() method that > could be easily removed. If you think we should not remove it, I > strongly suggest to rename the weak_oops_do() methods to better > indicate what they actually do instead of giving a very strong > (wrong) suggestion where/when they should be used. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8217778 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8217778/webrev/ > Testing: > hs-tier1-5 > > Thanks, > Thomas > > From lois.foltan at oracle.com Mon Jan 28 12:09:52 2019 From: lois.foltan at oracle.com (Lois Foltan) Date: Mon, 28 Jan 2019 07:09:52 -0500 Subject: RFR(M): 8217628: Verbose ArrayIndexOutOfBoundsException message also in JNI In-Reply-To: <6cfec56213c44995bd24426f8fa982f0@sap.com> References: <8b1ed15e-2569-ffad-79aa-95d29340523c@oracle.com> <6cfec56213c44995bd24426f8fa982f0@sap.com> Message-ID: Latest webrev looks good. Lois On 1/28/2019 5:22 AM, Lindenmaier, Goetz wrote: > Hi, > > Here a new webrev: > http://cr.openjdk.java.net/~goetz/wr19/8217628-AIOOBE_msg_jni/03/ > (David, sorry, I missed the list in my mail Friday...) > > Messages are capitalized, the method is refactored (definitely better!). > > Thanks to Martin and Mathias who pointed me to the build error > of the lib on solaris ?? > > This now passed jdk/submit. > > Best regards, > Goetz. > > >> -----Original Message----- >> From: David Holmes >> Sent: Donnerstag, 24. Januar 2019 01:40 >> To: Lindenmaier, Goetz ; hotspot-runtime- >> dev at openjdk.java.net >> Subject: Re: RFR(M): 8217628: Verbose ArrayIndexOutOfBoundsException >> message also in JNI >> >> Hi Goetz, >> >> On 24/01/2019 12:37 am, Lindenmaier, Goetz wrote: >>> Hi >>> >>> Change JDK-8201593 >> : Print array length in ArrayIndexOutOfBoundsException >>> introduced text as "Index 13 out of bounds for length 10" to various AIOOB >> exceptions >>> thrown in the VM. It omitted the exceptions thrown in jni calls. >>> >>> This change extends the messages to the AIOOB exceptions thrown in >>> Get|SetObjectArrayElement and Get|SetArrayRegion. >>> >>> Before, Get|SetObjectArrayElement printed just the index, >>> Get|SetArrayRegion printed no message. >>> >>> Now the following messages are printed: >>> "Index %d out of bounds for length %d" >>> "length %d is negative" >>> "array region %d..%d out of bounds for length %d" >>> >>> Any advice on capitalizing the first word? It's already >>> handled inconsistently... >> I'd suggest capitalizing. >> >>> Please review: >>> http://cr.openjdk.java.net/~goetz/wr19/8217628-AIOOBE_msg_jni/01/ >> Could I ask that you factor the region check into a small function so we >> don't duplicate the logic please. It would take TRAPS and would be >> called with a CHECK. >> >> Thanks, >> David >> ----- >> >>> >>> Best regards, >>> >>> Goetz. >>> From goetz.lindenmaier at sap.com Mon Jan 28 13:13:05 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 28 Jan 2019 13:13:05 +0000 Subject: RFR(M): 8217628: Verbose ArrayIndexOutOfBoundsException message also in JNI In-Reply-To: References: <8b1ed15e-2569-ffad-79aa-95d29340523c@oracle.com> <6cfec56213c44995bd24426f8fa982f0@sap.com> Message-ID: <75093a35d690436c9a7fbbf643c65e4c@sap.com> Thanks, Lois! Best regards, Goetz. > -----Original Message----- > From: Lois Foltan > Sent: Montag, 28. Januar 2019 13:10 > To: Lindenmaier, Goetz ; David Holmes > ; hotspot-runtime-dev at openjdk.java.net > Subject: Re: RFR(M): 8217628: Verbose ArrayIndexOutOfBoundsException > message also in JNI > > Latest webrev looks good. > Lois > > On 1/28/2019 5:22 AM, Lindenmaier, Goetz wrote: > > Hi, > > > > Here a new webrev: > > http://cr.openjdk.java.net/~goetz/wr19/8217628-AIOOBE_msg_jni/03/ > > (David, sorry, I missed the list in my mail Friday...) > > > > Messages are capitalized, the method is refactored (definitely better!). > > > > Thanks to Martin and Mathias who pointed me to the build error > > of the lib on solaris ?? > > > > This now passed jdk/submit. > > > > Best regards, > > Goetz. > > > > > >> -----Original Message----- > >> From: David Holmes > >> Sent: Donnerstag, 24. Januar 2019 01:40 > >> To: Lindenmaier, Goetz ; hotspot-runtime- > >> dev at openjdk.java.net > >> Subject: Re: RFR(M): 8217628: Verbose ArrayIndexOutOfBoundsException > >> message also in JNI > >> > >> Hi Goetz, > >> > >> On 24/01/2019 12:37 am, Lindenmaier, Goetz wrote: > >>> Hi > >>> > >>> Change JDK-8201593 8201593> > >> : Print array length in ArrayIndexOutOfBoundsException > >>> introduced text as "Index 13 out of bounds for length 10" to various AIOOB > >> exceptions > >>> thrown in the VM. It omitted the exceptions thrown in jni calls. > >>> > >>> This change extends the messages to the AIOOB exceptions thrown in > >>> Get|SetObjectArrayElement and Get|SetArrayRegion. > >>> > >>> Before, Get|SetObjectArrayElement printed just the index, > >>> Get|SetArrayRegion printed no message. > >>> > >>> Now the following messages are printed: > >>> "Index %d out of bounds for length %d" > >>> "length %d is negative" > >>> "array region %d..%d out of bounds for length %d" > >>> > >>> Any advice on capitalizing the first word? It's already > >>> handled inconsistently... > >> I'd suggest capitalizing. > >> > >>> Please review: > >>> http://cr.openjdk.java.net/~goetz/wr19/8217628-AIOOBE_msg_jni/01/ > >> Could I ask that you factor the region check into a small function so we > >> don't duplicate the logic please. It would take TRAPS and would be > >> called with a CHECK. > >> > >> Thanks, > >> David > >> ----- > >> > >>> > >>> Best regards, > >>> > >>> Goetz. > >>> From aoqi at loongson.cn Mon Jan 28 15:22:06 2019 From: aoqi at loongson.cn (Ao Qi) Date: Mon, 28 Jan 2019 23:22:06 +0800 Subject: [TESTBUG] runtime/containers/docker/TestCPUAwareness.java failed in docker not supporting --cpus In-Reply-To: <3ABBCD75-1515-4B83-9FC1-18C737FD7C99@oracle.com> References: <420d2b08-86df-d591-35c9-d359a8811e9c@oracle.com> <3ABBCD75-1515-4B83-9FC1-18C737FD7C99@oracle.com> Message-ID: Hi, Since ?cpus is a shortcut for of setting both --cpu-period and --cpu-quota and the test is not intended to verify that docker works correctly, I did not check the docker version and just replaced setting --cpus with setting both --cpu-period and --cpu-quota. What do you think of this patch: http://cr.openjdk.java.net/~aoqi/8217597/webrev.01/ ? Cheers, Ao Qi On Wed, Jan 23, 2019 at 11:37 PM Bob Vandette wrote: > > Since ?cpus is just a shortcut for of setting both --cpu-period and --cpu-quota?, I?d > be ok with removing this test. The tests are intended to test the container/cgroup > configuration detection logic and not to verify that docker works correctly. > > An alternate solution would be to add version detection to the Docker test check in > DockerTestUtils.java . We already exec ?docker ps? to see if docker is available > and enabled. > > % docker --version > Docker version 17.03.1-ce, build 276fd32 > > > Bob. > > > > > On Jan 22, 2019, at 10:19 PM, Ao Qi wrote: > > > > On Wed, Jan 23, 2019 at 10:55 AM David Holmes wrote: > >> > >> On 23/01/2019 11:58 am, Ao Qi wrote: > >>> Hi David, > >>> > >>> On Wed, Jan 23, 2019 at 5:24 AM David Holmes wrote: > >>>> > >>>> cc'ing Bob as our containers expert ... > >>>> > >>>> On 23/01/2019 1:10 am, Ao Qi wrote: > >>>>> Hi, > >>>>> > >>>>> --cpus is available in Docker 1.13 and higher [1], so > >>>>> runtime/containers/docker/TestCPUAwareness.java failed in docker which > >>>>> does not support --cpus. > >>>>> > >>>>> Webrev: http://cr.openjdk.java.net/~aoqi/docker/webrev.00/ > >>>>> > >>>>> This patch skips the test if --cpus is not supported. I tested > >>>>> runtime/containers/docker/TestCPUAwareness.java on a Fedora 25 (Docker > >>>>> version 1.12.6, build ae7d637/1.12.6, not supporting --cpus) and > >>>>> Ubuntu 16.04 (Docker version 17.03.2-ce, build f5ec1e2, supporting > >>>>> --cpus) > >>>> > >>>> The patch causes the test to pass if launching Docker fails for any > >>>> reason so that is not good. > >>>> > >>> > >>> I tested two versions of docker which does not support --cpus. Their > >>> exit values when using --cpus are 2 and 125, and outputs are: > >>> > >>> flag provided but not defined: --cpus > >>> See 'docker run --help'. > >>> > >>> and > >>> > >>> unknown flag: --cpus > >>> See 'docker run --help'. > >>> > >>> My initial thought was that the else condition of > >>> "output.getExitValue() == 0" should match the condition of "--cpus not > >>> supported". Firstly I used output.shouldMatch("docker run --help"), > >>> but I am not sure if all the docker version behaves this way when > >>> --cpus is not supported and "docker run --help" does not certainly > >>> indicate "--cpus not supported", so I removed the else condition. > >> > >> I think we need to try and find a way to clearly identifyt eh failing > >> condition. Is there are "docker --version" we coudl check? > >> > > > > I will do more research. Checking docker version may be one option, > > and checking whether one option is support by docker may be also one > > option. I will try them later, while waiting if there are some other > > opinions :) > > > >>>>> I am not sure if this is a testbug, so I did not file it on JBS. In > >>>>> fact, I am not quite sure what kind of issue can be filed on JBS. Is > >>>>> there any guidance document? > >>>> > >>>> Any/all issues can be filed on JBS. You don't need to pre-classify as a > >>>> testbug, simple create an issue that a test is failing under specific > >>>> conditions. Whomever works on the bug will then determine whether it is > >>>> a testbug or product issue or something else. (We don't seem to have any > >>>> docs on using JBS ...) > >>>> > >>> > >>> What if the issue is not a bug or no body cares the issue? The issue > >>> will be open on JBS forever? > >> > >> Possibly :) But each component team performs regular triage of the bugs > >> that get filed and eventually things will be examined enough to see if > >> they are indeed a bug, and if not they will be closed as not an issue. > >> If a bug but low priority it may eventually get closed as "will not fix" > >> just to keep the open bug count down. > >> > > > > I was a little afraid that filing issues that are not bugs or nobody > > cares would increase the workload of others and frustrate myself, so I > > was not sure what kind of issue should be filed. Now I basically > > clear, thanks David. > > > >> Cheers, > >> David > >> > >>> Thanks for your explanation, and I filed this issue on JBS: > >>> https://bugs.openjdk.java.net/browse/JDK-8217597 > >>> > >>>> In this case I'm not sure whether we require a docker version that > >>>> supports --cpus, and the test should be skipped otherwise. Though > >>>> ideally this would involve an explicit version check so we don't just > >>>> pass if the docker process fails. > >>>> > >>>> Thanks, > >>>> David > >>>> > >>>> > >>>>> > >>>>> Cheers, > >>>>> Ao Qi > >>>>> > >>>>> [1] https://docs.docker.com/config/containers/resource_constraints/#cpu > >>>>> > From bob.vandette at oracle.com Mon Jan 28 15:35:10 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Mon, 28 Jan 2019 10:35:10 -0500 Subject: [TESTBUG] runtime/containers/docker/TestCPUAwareness.java failed in docker not supporting --cpus In-Reply-To: References: <420d2b08-86df-d591-35c9-d359a8811e9c@oracle.com> <3ABBCD75-1515-4B83-9FC1-18C737FD7C99@oracle.com> Message-ID: <6C6F3704-041B-4940-87E5-A73AB0808847@oracle.com> There is already a test that verifies ?cpu-period and ?cpu-quota. I would just remove these lines. 62 // leave one CPU for system and tools, otherwise this test may be unstable 63 int maxNrOfAvailableCpus = availableCPUs - 1; 64 for (int i=1; i < maxNrOfAvailableCpus; i = i * 2) { 65 testCpus(i, i); 66 } 129 private static void testCpus(int valueToSet, int expectedTraceValue) throws Exception { 130 Common.logNewTestCase("test cpus: " + valueToSet); 131 DockerRunOptions opts = Common.newOpts(imageName) 132 .addDockerOpts("--cpus", "" + valueToSet); 133 Common.run(opts) 134 .shouldMatch("active_processor_count.*" + expectedTraceValue); 135 } Bob. > On Jan 28, 2019, at 10:22 AM, Ao Qi wrote: > > Hi, > > Since ?cpus is a shortcut for of setting both --cpu-period and > --cpu-quota and the test is not intended to verify that docker works > correctly, I did not check the docker version and just replaced > setting --cpus with setting both --cpu-period and --cpu-quota. What do > you think of this patch: > http://cr.openjdk.java.net/~aoqi/8217597/webrev.01/ ? > > Cheers, > Ao Qi > > > On Wed, Jan 23, 2019 at 11:37 PM Bob Vandette wrote: >> >> Since ?cpus is just a shortcut for of setting both --cpu-period and --cpu-quota?, I?d >> be ok with removing this test. The tests are intended to test the container/cgroup >> configuration detection logic and not to verify that docker works correctly. >> >> An alternate solution would be to add version detection to the Docker test check in >> DockerTestUtils.java . We already exec ?docker ps? to see if docker is available >> and enabled. >> >> % docker --version >> Docker version 17.03.1-ce, build 276fd32 >> >> >> Bob. >> >> >> >>> On Jan 22, 2019, at 10:19 PM, Ao Qi wrote: >>> >>> On Wed, Jan 23, 2019 at 10:55 AM David Holmes wrote: >>>> >>>> On 23/01/2019 11:58 am, Ao Qi wrote: >>>>> Hi David, >>>>> >>>>> On Wed, Jan 23, 2019 at 5:24 AM David Holmes wrote: >>>>>> >>>>>> cc'ing Bob as our containers expert ... >>>>>> >>>>>> On 23/01/2019 1:10 am, Ao Qi wrote: >>>>>>> Hi, >>>>>>> >>>>>>> --cpus is available in Docker 1.13 and higher [1], so >>>>>>> runtime/containers/docker/TestCPUAwareness.java failed in docker which >>>>>>> does not support --cpus. >>>>>>> >>>>>>> Webrev: http://cr.openjdk.java.net/~aoqi/docker/webrev.00/ >>>>>>> >>>>>>> This patch skips the test if --cpus is not supported. I tested >>>>>>> runtime/containers/docker/TestCPUAwareness.java on a Fedora 25 (Docker >>>>>>> version 1.12.6, build ae7d637/1.12.6, not supporting --cpus) and >>>>>>> Ubuntu 16.04 (Docker version 17.03.2-ce, build f5ec1e2, supporting >>>>>>> --cpus) >>>>>> >>>>>> The patch causes the test to pass if launching Docker fails for any >>>>>> reason so that is not good. >>>>>> >>>>> >>>>> I tested two versions of docker which does not support --cpus. Their >>>>> exit values when using --cpus are 2 and 125, and outputs are: >>>>> >>>>> flag provided but not defined: --cpus >>>>> See 'docker run --help'. >>>>> >>>>> and >>>>> >>>>> unknown flag: --cpus >>>>> See 'docker run --help'. >>>>> >>>>> My initial thought was that the else condition of >>>>> "output.getExitValue() == 0" should match the condition of "--cpus not >>>>> supported". Firstly I used output.shouldMatch("docker run --help"), >>>>> but I am not sure if all the docker version behaves this way when >>>>> --cpus is not supported and "docker run --help" does not certainly >>>>> indicate "--cpus not supported", so I removed the else condition. >>>> >>>> I think we need to try and find a way to clearly identifyt eh failing >>>> condition. Is there are "docker --version" we coudl check? >>>> >>> >>> I will do more research. Checking docker version may be one option, >>> and checking whether one option is support by docker may be also one >>> option. I will try them later, while waiting if there are some other >>> opinions :) >>> >>>>>>> I am not sure if this is a testbug, so I did not file it on JBS. In >>>>>>> fact, I am not quite sure what kind of issue can be filed on JBS. Is >>>>>>> there any guidance document? >>>>>> >>>>>> Any/all issues can be filed on JBS. You don't need to pre-classify as a >>>>>> testbug, simple create an issue that a test is failing under specific >>>>>> conditions. Whomever works on the bug will then determine whether it is >>>>>> a testbug or product issue or something else. (We don't seem to have any >>>>>> docs on using JBS ...) >>>>>> >>>>> >>>>> What if the issue is not a bug or no body cares the issue? The issue >>>>> will be open on JBS forever? >>>> >>>> Possibly :) But each component team performs regular triage of the bugs >>>> that get filed and eventually things will be examined enough to see if >>>> they are indeed a bug, and if not they will be closed as not an issue. >>>> If a bug but low priority it may eventually get closed as "will not fix" >>>> just to keep the open bug count down. >>>> >>> >>> I was a little afraid that filing issues that are not bugs or nobody >>> cares would increase the workload of others and frustrate myself, so I >>> was not sure what kind of issue should be filed. Now I basically >>> clear, thanks David. >>> >>>> Cheers, >>>> David >>>> >>>>> Thanks for your explanation, and I filed this issue on JBS: >>>>> https://bugs.openjdk.java.net/browse/JDK-8217597 >>>>> >>>>>> In this case I'm not sure whether we require a docker version that >>>>>> supports --cpus, and the test should be skipped otherwise. Though >>>>>> ideally this would involve an explicit version check so we don't just >>>>>> pass if the docker process fails. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>> >>>>>>> >>>>>>> Cheers, >>>>>>> Ao Qi >>>>>>> >>>>>>> [1] https://docs.docker.com/config/containers/resource_constraints/#cpu >>>>>>> >> From coleen.phillimore at oracle.com Mon Jan 28 20:20:52 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 28 Jan 2019 15:20:52 -0500 Subject: RFR 8214821: Remove ConcurrentHashTable::get_copy In-Reply-To: References: Message-ID: Looks good! Coleen On 1/23/19 1:49 PM, Gerard Ziemski wrote: > Hi all, > > Please review this simple fix that removes ?ConcurrentHashTable::get_copy? API, whose only client was a single gtest. Doing so allows us to remove CONFIG::notfound() > > That gtest replaces the usage of ?get_copy? API with a local ?cht_get_copy? method, which itself is implemented using "ConcurrentHashTable::get? API > > I also took this opportunity to clean up a few method names in the test a bit. > > References: > > https://bugs.openjdk.java.net/browse/JDK-8214821 > http://cr.openjdk.java.net/~gziemski/8214821_rev1 > > Passes gtest locally on Mac and passes Mach5 hs-tier1,2,3,4,5,6 > > > Cheers From robbin.ehn at oracle.com Mon Jan 28 20:31:42 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Mon, 28 Jan 2019 21:31:42 +0100 Subject: RFR 8214821: Remove ConcurrentHashTable::get_copy In-Reply-To: References: Message-ID: <02860b4e-ac65-df29-13a0-da5a92ea9cf6@oracle.com> Hi Gerard, sorry for the delay. Looks good, thanks! /Robbin On 2019-01-23 19:49, Gerard Ziemski wrote: > Hi all, > > Please review this simple fix that removes ?ConcurrentHashTable::get_copy? API, whose only client was a single gtest. Doing so allows us to remove CONFIG::notfound() > > That gtest replaces the usage of ?get_copy? API with a local ?cht_get_copy? method, which itself is implemented using "ConcurrentHashTable::get? API > > I also took this opportunity to clean up a few method names in the test a bit. > > References: > > https://bugs.openjdk.java.net/browse/JDK-8214821 > http://cr.openjdk.java.net/~gziemski/8214821_rev1 > > Passes gtest locally on Mac and passes Mach5 hs-tier1,2,3,4,5,6 > > > Cheers > From robbin.ehn at oracle.com Mon Jan 28 20:38:48 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Mon, 28 Jan 2019 21:38:48 +0100 Subject: RFR(S): 8217658 baseline_cleanups from Async Monitor Deflation project In-Reply-To: <7fb13885-e2ff-bb82-b8ca-ed168576ae10@oracle.com> References: <057e5a67-68e3-95b9-e337-a95928fe59d6@oracle.com> <6c389750-b92c-7cb7-76ef-60d49b116148@oracle.com> <7fb13885-e2ff-bb82-b8ca-ed168576ae10@oracle.com> Message-ID: <27111e67-2f6a-0756-04ba-3b7dbe25e18e@oracle.com> Hi Dan, Looks great, thanks! /Robbin On 2019-01-26 04:46, Daniel D. Daugherty wrote: > David, > > Thanks for the re-review. Still hoping for one more reviewer... > > Dan > > > On 1/25/19 9:46 PM, David Holmes wrote: >> Thanks Dan, incremental changes look good. >> >> David >> >> On 26/01/2019 3:38 am, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I've updated the patch to include the two additional cleanups from David H. >>> I've also rebased the patch to the jdk/jdk repo at the 'jdk-13+5' tag; >>> there were no merge surprises. >>> >>> Here's an incremental webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8217658-webrev/1-for-jdk13.inc/ >>> >>> I've also generated a full webrev since I still need one more reviewer for this: >>> >>> http://cr.openjdk.java.net/~dcubed/8217658-webrev/1-for-jdk13.full/ >>> >>> I've also updated the bug to talk about the two additional cleanups. >>> >>> Thanks, in advance, for any questions, comments or suggestions. >>> >>> Dan >>> >>> >>> On 1/23/19 3:07 PM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> I have a (S)mall patch extracted from the Async Monitor Deflation >>>> project that is ready for code review. >>>> >>>> The short version of what this patch is about: >>>> >>>> ? ? This sub-task captures updates to the baseline code that are not >>>> ? ? directly related to Async Monitor Deflation. >>>> >>>> The details are in the bug report: >>>> >>>> ??? JDK-8217658 baseline_cleanups from Async Monitor Deflation project >>>> ??? https://bugs.openjdk.java.net/browse/JDK-8217658 >>>> >>>> Here's the webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8217658-webrev/0-for-jdk13/ >>>> >>>> This patch along with the other two patches for Async Monitor Deflation >>>> project have been through Mach5 builds-tier1,hs-tier1,jdk-tier1,hs-tier2,hs-tier3 >>>> testing and I'm currently running my stress testing kits on my Linux-X64 >>>> and Solaris-X64 servers. >>>> >>>> Thanks, in advance, for any questions, comments or suggestions. >>>> >>>> Dan >>>> >>>> >>> > From robbin.ehn at oracle.com Mon Jan 28 20:55:57 2019 From: robbin.ehn at oracle.com (Robbin Ehn) Date: Mon, 28 Jan 2019 21:55:57 +0100 Subject: RFR(S/M): 8217659 monitor_logging updates from Async Monitor Deflation project In-Reply-To: <98f74cf8-1634-c0ad-0bbc-7c2d8e31a467@oracle.com> References: <98f74cf8-1634-c0ad-0bbc-7c2d8e31a467@oracle.com> Message-ID: <55047458-e667-9f62-6676-b27ae4829884@oracle.com> Hi Dan, looks good, thanks. /Robbin On 2019-01-27 04:10, Daniel D. Daugherty wrote: > Greetings, > > I've updated the patch to resolve code review comments from David H. > and Coleen. I've also rebased the patch to the jdk/jdk repo at the > 'jdk-13+5' tag (plus the 8217658 patch); there were no merge surprises. > > Here's an incremental webrev: > > http://cr.openjdk.java.net/~dcubed/8217659-webrev/1-for-jdk13.inc/ > > I've also generated a full webrev since the changes to synchronizer.cpp > are extensive and that's the easier way to review it: > > http://cr.openjdk.java.net/~dcubed/8217659-webrev/1-for-jdk13.full/ > > This patch along with 8217658 have been through Mach5 > builds-tier1,hs-tier1,jdk-tier1,hs-tier2,hs-tier3 testing with > no failures. > > Thanks, in advance, for any questions, comments or suggestions. > > Dan > > P.S. > I've attached sample output for running Hello.java with the > monitorinflation logging enabled at Info, Debug and Trace. > > > On 1/23/19 3:16 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> I have a (S)mall/(M)edium patch extracted from the Async Monitor Deflation >> project that is ready for code review. I'm calling this a (S)mall/(M)edium >> because the logic changes are (S)mall, but the logging code is tedious and >> there's a bunch of it in audit_and_print_stats() so (M)edium. >> >> The short version of what this patch is about: >> >> ??? This sub-task captures updates and additions to the >> ??? baseline monitor logging code. >> >> The details are in the bug report: >> >> ??? JDK-8217659 monitor_logging updates from Async Monitor Deflation project >> ??? https://bugs.openjdk.java.net/browse/JDK-8217659 >> >> Here's the webrev: >> >> ??? http://cr.openjdk.java.net/~dcubed/8217659-webrev/0-for-jdk13/ >> >> This patch along with the other two patches for Async Monitor Deflation >> project have been through Mach5 builds-tier1,hs-tier1,jdk-tier1,hs-tier2,hs-tier3 >> testing and I'm currently running my stress testing kits on my Linux-X64 >> and Solaris-X64 servers. >> >> I have been actively using this new logging code while debugging my >> port of the Async Monitor Deflation project code. >> >> Thanks, in advance, for any questions, comments or suggestions. >> >> Dan >> >> > From claes.redestad at oracle.com Mon Jan 28 21:24:58 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 28 Jan 2019 22:24:58 +0100 Subject: RFR: 8217921: Runtime dead code removal Message-ID: <10accb5f-fe5b-26e3-ce80-5bf19a58c09f@oracle.com> Hi, please review this patch to remove dead code in the runtime, interpreter and related areas. Bug: https://bugs.openjdk.java.net/browse/JDK-8217921 Webrev: http://cr.openjdk.java.net/~redestad/8217921/open.00/ Testing: tier1+2 I've taken care to check every change to ensure it's not in use by some platform specific code on a platform that's not built/supported by Oracle, but help verifying this would be greatly appreciated. I've also checked the patch applies cleanly to a few valhalla and amber branches to avoid excessive merge issues. Thanks! /Claes From daniel.daugherty at oracle.com Mon Jan 28 21:34:16 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 28 Jan 2019 16:34:16 -0500 Subject: RFR(S): 8217658 baseline_cleanups from Async Monitor Deflation project In-Reply-To: <27111e67-2f6a-0756-04ba-3b7dbe25e18e@oracle.com> References: <057e5a67-68e3-95b9-e337-a95928fe59d6@oracle.com> <6c389750-b92c-7cb7-76ef-60d49b116148@oracle.com> <7fb13885-e2ff-bb82-b8ca-ed168576ae10@oracle.com> <27111e67-2f6a-0756-04ba-3b7dbe25e18e@oracle.com> Message-ID: <55efcfd7-b2d2-012e-cb5a-ec56927b6d37@oracle.com> Robbin, thanks for the review! Dan On 1/28/19 3:38 PM, Robbin Ehn wrote: > Hi Dan, > > Looks great, thanks! > > /Robbin > > On 2019-01-26 04:46, Daniel D. Daugherty wrote: >> David, >> >> Thanks for the re-review. Still hoping for one more reviewer... >> >> Dan >> >> >> On 1/25/19 9:46 PM, David Holmes wrote: >>> Thanks Dan, incremental changes look good. >>> >>> David >>> >>> On 26/01/2019 3:38 am, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> I've updated the patch to include the two additional cleanups from >>>> David H. >>>> I've also rebased the patch to the jdk/jdk repo at the 'jdk-13+5' tag; >>>> there were no merge surprises. >>>> >>>> Here's an incremental webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8217658-webrev/1-for-jdk13.inc/ >>>> >>>> I've also generated a full webrev since I still need one more >>>> reviewer for this: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8217658-webrev/1-for-jdk13.full/ >>>> >>>> I've also updated the bug to talk about the two additional cleanups. >>>> >>>> Thanks, in advance, for any questions, comments or suggestions. >>>> >>>> Dan >>>> >>>> >>>> On 1/23/19 3:07 PM, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> I have a (S)mall patch extracted from the Async Monitor Deflation >>>>> project that is ready for code review. >>>>> >>>>> The short version of what this patch is about: >>>>> >>>>> ? ? This sub-task captures updates to the baseline code that are not >>>>> ? ? directly related to Async Monitor Deflation. >>>>> >>>>> The details are in the bug report: >>>>> >>>>> ??? JDK-8217658 baseline_cleanups from Async Monitor Deflation >>>>> project >>>>> ??? https://bugs.openjdk.java.net/browse/JDK-8217658 >>>>> >>>>> Here's the webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8217658-webrev/0-for-jdk13/ >>>>> >>>>> This patch along with the other two patches for Async Monitor >>>>> Deflation >>>>> project have been through Mach5 >>>>> builds-tier1,hs-tier1,jdk-tier1,hs-tier2,hs-tier3 >>>>> testing and I'm currently running my stress testing kits on my >>>>> Linux-X64 >>>>> and Solaris-X64 servers. >>>>> >>>>> Thanks, in advance, for any questions, comments or suggestions. >>>>> >>>>> Dan >>>>> >>>>> >>>> >> From coleen.phillimore at oracle.com Mon Jan 28 21:32:56 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 28 Jan 2019 16:32:56 -0500 Subject: RFR(S/M): 8217659 monitor_logging updates from Async Monitor Deflation project In-Reply-To: <98f74cf8-1634-c0ad-0bbc-7c2d8e31a467@oracle.com> References: <98f74cf8-1634-c0ad-0bbc-7c2d8e31a467@oracle.com> Message-ID: <003a4d2e-f7c1-cc57-6ab8-6a207ce64896@oracle.com> Hi Dan, This looks better, especially audit_and_print_stats. My eyes are terrible, but it looks like this is ObjectMonitor::verify_free() + if (n->is_busy()) { + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global monitor " + "must not be busy.", p2i(n)); + *error_cnt_p = *error_cnt_p + 1; + } + if (n->header() != NULL) { + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global monitor " + "must have NULL _header field: _header=" INTPTR_FORMAT, + p2i(n), p2i(n->header())); + *error_cnt_p = *error_cnt_p + 1; + } + if (n->object() != NULL) { + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global monitor " + "must have NULL _object field: _object=" INTPTR_FORMAT, + p2i(n), p2i(n->object())); + *error_cnt_p = *error_cnt_p + 1; + } ... And this is ObjectMonitor::verify_in_use() + if (n->header() == NULL) { + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": in-use global monitor " + "must have non-NULL _header field.", p2i(n)); + *error_cnt_p = *error_cnt_p + 1; + } + if (n->object() == NULL) { + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": in-use global monitor " + "must have non-NULL _object field.", p2i(n)); + *error_cnt_p = *error_cnt_p + 1; + } ... And you do the same checks for the per-thread versions.? That's what I noticed before.? I like the refactoring that you did but if you want to do more, this is what I'd suggest. ? ObjectMonitor doesn't have any verify functions and it seems like the knowledge of these fields really belongs there.? Anyways, these files are tightly coupled, so it's ok the way it is.? Maybe better not to pull that thread right now. thanks, Coleen On 1/26/19 10:10 PM, Daniel D. Daugherty wrote: > Greetings, > > I've updated the patch to resolve code review comments from David H. > and Coleen. I've also rebased the patch to the jdk/jdk repo at the > 'jdk-13+5' tag (plus the 8217658 patch); there were no merge surprises. > > Here's an incremental webrev: > > http://cr.openjdk.java.net/~dcubed/8217659-webrev/1-for-jdk13.inc/ > > I've also generated a full webrev since the changes to synchronizer.cpp > are extensive and that's the easier way to review it: > > http://cr.openjdk.java.net/~dcubed/8217659-webrev/1-for-jdk13.full/ > > This patch along with 8217658 have been through Mach5 > builds-tier1,hs-tier1,jdk-tier1,hs-tier2,hs-tier3 testing with > no failures. > > Thanks, in advance, for any questions, comments or suggestions. > > Dan > > P.S. > I've attached sample output for running Hello.java with the > monitorinflation logging enabled at Info, Debug and Trace. > > > On 1/23/19 3:16 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> I have a (S)mall/(M)edium patch extracted from the Async Monitor >> Deflation >> project that is ready for code review. I'm calling this a >> (S)mall/(M)edium >> because the logic changes are (S)mall, but the logging code is >> tedious and >> there's a bunch of it in audit_and_print_stats() so (M)edium. >> >> The short version of what this patch is about: >> >> ??? This sub-task captures updates and additions to the >> ??? baseline monitor logging code. >> >> The details are in the bug report: >> >> ??? JDK-8217659 monitor_logging updates from Async Monitor Deflation >> project >> ??? https://bugs.openjdk.java.net/browse/JDK-8217659 >> >> Here's the webrev: >> >> http://cr.openjdk.java.net/~dcubed/8217659-webrev/0-for-jdk13/ >> >> This patch along with the other two patches for Async Monitor Deflation >> project have been through Mach5 >> builds-tier1,hs-tier1,jdk-tier1,hs-tier2,hs-tier3 >> testing and I'm currently running my stress testing kits on my Linux-X64 >> and Solaris-X64 servers. >> >> I have been actively using this new logging code while debugging my >> port of the Async Monitor Deflation project code. >> >> Thanks, in advance, for any questions, comments or suggestions. >> >> Dan >> >> > From daniel.daugherty at oracle.com Mon Jan 28 21:35:12 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 28 Jan 2019 16:35:12 -0500 Subject: RFR(S/M): 8217659 monitor_logging updates from Async Monitor Deflation project In-Reply-To: <55047458-e667-9f62-6676-b27ae4829884@oracle.com> References: <98f74cf8-1634-c0ad-0bbc-7c2d8e31a467@oracle.com> <55047458-e667-9f62-6676-b27ae4829884@oracle.com> Message-ID: Robbin, Thanks for the review! David and Coleen, please confirm if I have addressed your comments from code review round 0. Thanks! Dan On 1/28/19 3:55 PM, Robbin Ehn wrote: > Hi Dan, looks good, thanks. > > /Robbin > > On 2019-01-27 04:10, Daniel D. Daugherty wrote: >> Greetings, >> >> I've updated the patch to resolve code review comments from David H. >> and Coleen. I've also rebased the patch to the jdk/jdk repo at the >> 'jdk-13+5' tag (plus the 8217658 patch); there were no merge surprises. >> >> Here's an incremental webrev: >> >> http://cr.openjdk.java.net/~dcubed/8217659-webrev/1-for-jdk13.inc/ >> >> I've also generated a full webrev since the changes to synchronizer.cpp >> are extensive and that's the easier way to review it: >> >> http://cr.openjdk.java.net/~dcubed/8217659-webrev/1-for-jdk13.full/ >> >> This patch along with 8217658 have been through Mach5 >> builds-tier1,hs-tier1,jdk-tier1,hs-tier2,hs-tier3 testing with >> no failures. >> >> Thanks, in advance, for any questions, comments or suggestions. >> >> Dan >> >> P.S. >> I've attached sample output for running Hello.java with the >> monitorinflation logging enabled at Info, Debug and Trace. >> >> >> On 1/23/19 3:16 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I have a (S)mall/(M)edium patch extracted from the Async Monitor >>> Deflation >>> project that is ready for code review. I'm calling this a >>> (S)mall/(M)edium >>> because the logic changes are (S)mall, but the logging code is >>> tedious and >>> there's a bunch of it in audit_and_print_stats() so (M)edium. >>> >>> The short version of what this patch is about: >>> >>> ??? This sub-task captures updates and additions to the >>> ??? baseline monitor logging code. >>> >>> The details are in the bug report: >>> >>> ??? JDK-8217659 monitor_logging updates from Async Monitor Deflation >>> project >>> ??? https://bugs.openjdk.java.net/browse/JDK-8217659 >>> >>> Here's the webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8217659-webrev/0-for-jdk13/ >>> >>> This patch along with the other two patches for Async Monitor Deflation >>> project have been through Mach5 >>> builds-tier1,hs-tier1,jdk-tier1,hs-tier2,hs-tier3 >>> testing and I'm currently running my stress testing kits on my >>> Linux-X64 >>> and Solaris-X64 servers. >>> >>> I have been actively using this new logging code while debugging my >>> port of the Async Monitor Deflation project code. >>> >>> Thanks, in advance, for any questions, comments or suggestions. >>> >>> Dan >>> >>> >> From coleen.phillimore at oracle.com Mon Jan 28 21:37:34 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 28 Jan 2019 16:37:34 -0500 Subject: RFR: 8217921: Runtime dead code removal In-Reply-To: <10accb5f-fe5b-26e3-ce80-5bf19a58c09f@oracle.com> References: <10accb5f-fe5b-26e3-ce80-5bf19a58c09f@oracle.com> Message-ID: <6c7affae-732d-2651-e736-3bb5ef265048@oracle.com> How did you find these?? What an eclectic mix of old code! Looks good to me. Coleen On 1/28/19 4:24 PM, Claes Redestad wrote: > Hi, > > please review this patch to remove dead code in the runtime, interpreter > and related areas. > > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8217921 > Webrev: http://cr.openjdk.java.net/~redestad/8217921/open.00/ > > Testing: tier1+2 > > I've taken care to check every change to ensure it's not in use by some > platform specific code on a platform that's not built/supported by > Oracle, but help verifying this would be greatly appreciated. > > I've also checked the patch applies cleanly to a few valhalla and amber > branches to avoid excessive merge issues. > > Thanks! > > /Claes From claes.redestad at oracle.com Mon Jan 28 21:43:44 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 28 Jan 2019 22:43:44 +0100 Subject: RFR: 8217921: Runtime dead code removal In-Reply-To: <6c7affae-732d-2651-e736-3bb5ef265048@oracle.com> References: <10accb5f-fe5b-26e3-ce80-5bf19a58c09f@oracle.com> <6c7affae-732d-2651-e736-3bb5ef265048@oracle.com> Message-ID: <617ec2c8-338c-c532-cacd-840be6843990@oracle.com> On 2019-01-28 22:37, coleen.phillimore at oracle.com wrote: > > How did you find these? Played around with CLion + a lot of grepping. > What an eclectic mix of old code! Indubitably! > Looks good to me. Thanks! /Claes From coleen.phillimore at oracle.com Mon Jan 28 21:46:21 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 28 Jan 2019 16:46:21 -0500 Subject: RFR (M): 8217778: StringTable cleanup miscalculates amount of dead objects In-Reply-To: <7a944a8567e8768986f3c72a030b0538cc71ebd9.camel@oracle.com> References: <2140b41eb336ec5260b68eefd010c670a0b7a4ca.camel@oracle.com> <7a944a8567e8768986f3c72a030b0538cc71ebd9.camel@oracle.com> Message-ID: <30a9667d-5b9e-2f25-a069-78027423f451@oracle.com> Hi Thomas,? Can you forward the review thread for JDK-8213229? I wonder if we could just trigger_unloading after any GC has run and ignore dead string counts.? Are they ever zero? Thanks, Coleen On 1/28/19 6:45 AM, Thomas Schatzl wrote: > Hi again, > > cc'ed hotspot-runtime-dev since it concerns the string table. > > Also, this patch is based on the changes for JDK-8213229. > > Thanks, > Thomas > > On Mon, 2019-01-28 at 12:43 +0100, Thomas Schatzl wrote: >> Hi all, >> >> can I have reviews for this change that tries to fix the issue with >> the string table reporting too low "dead" numbers to the >> ServiceThread notification mechanism in the review for JDK-8213229, >> potentially causing C heap memory being kept live for longer than >> necessary? >> >> This change implements one option for fixing this, in particular that >> the WeakProcessor calls OopStorage::oops_do() instead of >> ::weak_oops_do, counting the number of NULL entries manually. >> >> There is another, let weak_oops_do() return the number of NULL >> entries as function return value. However the return value of the >> used iterate_safepoint() is already in use in some I'd consider >> interesting test case. I did not want to add another out-parameter >> either. >> >> Since the WeakProcessor has been the main user of the weak_oops_do() >> method, I would suggest to clean this up preferably in an extra CR: >> there is still one use of the OopStorage::weak_oops_do() method that >> could be easily removed. If you think we should not remove it, I >> strongly suggest to rename the weak_oops_do() methods to better >> indicate what they actually do instead of giving a very strong >> (wrong) suggestion where/when they should be used. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8217778 >> Webrev: >> http://cr.openjdk.java.net/~tschatzl/8217778/webrev/ >> Testing: >> hs-tier1-5 >> >> Thanks, >> Thomas >> >> > From daniel.daugherty at oracle.com Mon Jan 28 22:07:13 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 28 Jan 2019 17:07:13 -0500 Subject: RFR(S/M): 8217659 monitor_logging updates from Async Monitor Deflation project In-Reply-To: <003a4d2e-f7c1-cc57-6ab8-6a207ce64896@oracle.com> References: <98f74cf8-1634-c0ad-0bbc-7c2d8e31a467@oracle.com> <003a4d2e-f7c1-cc57-6ab8-6a207ce64896@oracle.com> Message-ID: <39addd9a-532d-0bab-31fb-bdce5d67f426@oracle.com> On 1/28/19 4:32 PM, coleen.phillimore at oracle.com wrote: > > Hi Dan, This looks better, especially audit_and_print_stats. Thanks! And thanks for the re-review!! > My eyes are terrible, but it looks like this is > ObjectMonitor::verify_free() This comment really confused me. I didn't remember an ObjectMonitor::verify_free() so I was grep'ing all over the place trying to find it. After reading to the bottom of this email, I see that you think this could be refactored into a new function called ObjectMonitor::verify_free(). Now I feel less confused... :-) > + if (n->is_busy()) { > + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global monitor " > + "must not be busy.", p2i(n)); > + *error_cnt_p = *error_cnt_p + 1; > + } > + if (n->header() != NULL) { > + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global monitor " > + "must have NULL _header field: _header=" INTPTR_FORMAT, > + p2i(n), p2i(n->header())); > + *error_cnt_p = *error_cnt_p + 1; > + } > + if (n->object() != NULL) { > + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global monitor " > + "must have NULL _object field: _object=" INTPTR_FORMAT, > + p2i(n), p2i(n->object())); > + *error_cnt_p = *error_cnt_p + 1; > + } ... > > And this is ObjectMonitor::verify_in_use() > > + if (n->header() == NULL) { > + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": in-use global > monitor " > + "must have non-NULL _header field.", p2i(n)); > + *error_cnt_p = *error_cnt_p + 1; > + } > + if (n->object() == NULL) { > + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": in-use global > monitor " > + "must have non-NULL _object field.", p2i(n)); > + *error_cnt_p = *error_cnt_p + 1; > + } ... And another refactor recommendation... okay. > And you do the same checks for the per-thread versions.? That's what I > noticed before.? I like the refactoring that you did but if you want > to do more, this is what I'd suggest. In my first reply to David on this review thread, I wrote: > Maybe after the above simplifications, other ways to make this > function more digestible will become apparent... What you're suggesting fits right in with more simplifications becoming apparent. > ObjectMonitor doesn't have any verify functions and it seems like the > knowledge of these fields really belongs there.? Anyways, these files > are tightly coupled, so it's ok the way it is.? Maybe better not to > pull that thread right now. It's kind of a toss up between ObjectMonitor.* and synchronizer.*. Yes, ObjectMonitor.* defines all the fields and _some_ of the ops, but there is a lot of logic in synchronizer.* that determines how the fields are used. I'll take a look at the possibility of more refactoring, but it may not happen with this bug (8217659). Dan > > thanks, > Coleen > > > > On 1/26/19 10:10 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> I've updated the patch to resolve code review comments from David H. >> and Coleen. I've also rebased the patch to the jdk/jdk repo at the >> 'jdk-13+5' tag (plus the 8217658 patch); there were no merge surprises. >> >> Here's an incremental webrev: >> >> http://cr.openjdk.java.net/~dcubed/8217659-webrev/1-for-jdk13.inc/ >> >> I've also generated a full webrev since the changes to synchronizer.cpp >> are extensive and that's the easier way to review it: >> >> http://cr.openjdk.java.net/~dcubed/8217659-webrev/1-for-jdk13.full/ >> >> This patch along with 8217658 have been through Mach5 >> builds-tier1,hs-tier1,jdk-tier1,hs-tier2,hs-tier3 testing with >> no failures. >> >> Thanks, in advance, for any questions, comments or suggestions. >> >> Dan >> >> P.S. >> I've attached sample output for running Hello.java with the >> monitorinflation logging enabled at Info, Debug and Trace. >> >> >> On 1/23/19 3:16 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I have a (S)mall/(M)edium patch extracted from the Async Monitor >>> Deflation >>> project that is ready for code review. I'm calling this a >>> (S)mall/(M)edium >>> because the logic changes are (S)mall, but the logging code is >>> tedious and >>> there's a bunch of it in audit_and_print_stats() so (M)edium. >>> >>> The short version of what this patch is about: >>> >>> ??? This sub-task captures updates and additions to the >>> ??? baseline monitor logging code. >>> >>> The details are in the bug report: >>> >>> ??? JDK-8217659 monitor_logging updates from Async Monitor Deflation >>> project >>> ??? https://bugs.openjdk.java.net/browse/JDK-8217659 >>> >>> Here's the webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8217659-webrev/0-for-jdk13/ >>> >>> This patch along with the other two patches for Async Monitor Deflation >>> project have been through Mach5 >>> builds-tier1,hs-tier1,jdk-tier1,hs-tier2,hs-tier3 >>> testing and I'm currently running my stress testing kits on my >>> Linux-X64 >>> and Solaris-X64 servers. >>> >>> I have been actively using this new logging code while debugging my >>> port of the Async Monitor Deflation project code. >>> >>> Thanks, in advance, for any questions, comments or suggestions. >>> >>> Dan >>> >>> >> > From coleen.phillimore at oracle.com Mon Jan 28 22:09:29 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 28 Jan 2019 17:09:29 -0500 Subject: RFR (M) 8213753: Move timing of ProtectionDomainTable and ResolvedMethodTable cleanup to service thread Message-ID: <61fe9787-4a8e-c346-cdb6-760a73c2114b@oracle.com> Summary: remove gc timing for short runtime cleanup triggering; make symbol table cleaning triggered automatically on unloading Ran runThese with all Oracle GCs and got similar numbers of symbols unloaded.? Also ran tier1-5. open webrev at http://cr.openjdk.java.net/~coleenp/2019/8213753.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8213753 Thanks, Coleen From coleen.phillimore at oracle.com Mon Jan 28 22:15:21 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Mon, 28 Jan 2019 17:15:21 -0500 Subject: RFR(S/M): 8217659 monitor_logging updates from Async Monitor Deflation project In-Reply-To: <39addd9a-532d-0bab-31fb-bdce5d67f426@oracle.com> References: <98f74cf8-1634-c0ad-0bbc-7c2d8e31a467@oracle.com> <003a4d2e-f7c1-cc57-6ab8-6a207ce64896@oracle.com> <39addd9a-532d-0bab-31fb-bdce5d67f426@oracle.com> Message-ID: <4383a85b-cf89-3f06-0f46-ba4e4159434e@oracle.com> On 1/28/19 5:07 PM, Daniel D. Daugherty wrote: > On 1/28/19 4:32 PM, coleen.phillimore at oracle.com wrote: >> >> Hi Dan, This looks better, especially audit_and_print_stats. > > Thanks! And thanks for the re-review!! > > >> My eyes are terrible, but it looks like this is >> ObjectMonitor::verify_free() > > This comment really confused me. I didn't remember an > ObjectMonitor::verify_free() so I was grep'ing all over the > place trying to find it. > > After reading to the bottom of this email, I see that you > think this could be refactored into a new function called > ObjectMonitor::verify_free(). Now I feel less confused... :-) > Sorry about that.? It was my second (better, if you can believe it) attempt at suggesting this. > >> + if (n->is_busy()) { >> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global monitor " >> + "must not be busy.", p2i(n)); >> + *error_cnt_p = *error_cnt_p + 1; >> + } >> + if (n->header() != NULL) { >> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global monitor " >> + "must have NULL _header field: _header=" INTPTR_FORMAT, >> + p2i(n), p2i(n->header())); >> + *error_cnt_p = *error_cnt_p + 1; >> + } >> + if (n->object() != NULL) { >> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global monitor " >> + "must have NULL _object field: _object=" INTPTR_FORMAT, >> + p2i(n), p2i(n->object())); >> + *error_cnt_p = *error_cnt_p + 1; >> + } ... >> >> And this is ObjectMonitor::verify_in_use() >> >> + if (n->header() == NULL) { >> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": in-use global >> monitor " >> + "must have non-NULL _header field.", p2i(n)); >> + *error_cnt_p = *error_cnt_p + 1; >> + } >> + if (n->object() == NULL) { >> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": in-use global >> monitor " >> + "must have non-NULL _object field.", p2i(n)); >> + *error_cnt_p = *error_cnt_p + 1; >> + } ... > > And another refactor recommendation... okay. > > >> And you do the same checks for the per-thread versions.? That's what >> I noticed before.? I like the refactoring that you did but if you >> want to do more, this is what I'd suggest. > > In my first reply to David on this review thread, I wrote: > >> Maybe after the above simplifications, other ways to make this >> function more digestible will become apparent... > > What you're suggesting fits right in with more simplifications > becoming apparent. > > Yes, the power of refactoring ... >> ObjectMonitor doesn't have any verify functions and it seems like the >> knowledge of these fields really belongs there.? Anyways, these files >> are tightly coupled, so it's ok the way it is.? Maybe better not to >> pull that thread right now. > > It's kind of a toss up between ObjectMonitor.* and synchronizer.*. > Yes, ObjectMonitor.* defines all the fields and _some_ of the ops, > but there is a lot of logic in synchronizer.* that determines how > the fields are used. That's sort of broken encapsulation imho, which makes this tricky code more difficult to understand.? We can clean up as we go though.? There's plenty to do in that regard. > > I'll take a look at the possibility of more refactoring, but it > may not happen with this bug (8217659). > Yes, if you want to do this separately and have captured enough of this to do so, a separate RFE is fine.? I'll add to it if you need me to. Thanks, Coleen > Dan > > >> >> thanks, >> Coleen >> >> >> >> On 1/26/19 10:10 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I've updated the patch to resolve code review comments from David H. >>> and Coleen. I've also rebased the patch to the jdk/jdk repo at the >>> 'jdk-13+5' tag (plus the 8217658 patch); there were no merge surprises. >>> >>> Here's an incremental webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8217659-webrev/1-for-jdk13.inc/ >>> >>> I've also generated a full webrev since the changes to synchronizer.cpp >>> are extensive and that's the easier way to review it: >>> >>> http://cr.openjdk.java.net/~dcubed/8217659-webrev/1-for-jdk13.full/ >>> >>> This patch along with 8217658 have been through Mach5 >>> builds-tier1,hs-tier1,jdk-tier1,hs-tier2,hs-tier3 testing with >>> no failures. >>> >>> Thanks, in advance, for any questions, comments or suggestions. >>> >>> Dan >>> >>> P.S. >>> I've attached sample output for running Hello.java with the >>> monitorinflation logging enabled at Info, Debug and Trace. >>> >>> >>> On 1/23/19 3:16 PM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> I have a (S)mall/(M)edium patch extracted from the Async Monitor >>>> Deflation >>>> project that is ready for code review. I'm calling this a >>>> (S)mall/(M)edium >>>> because the logic changes are (S)mall, but the logging code is >>>> tedious and >>>> there's a bunch of it in audit_and_print_stats() so (M)edium. >>>> >>>> The short version of what this patch is about: >>>> >>>> ??? This sub-task captures updates and additions to the >>>> ??? baseline monitor logging code. >>>> >>>> The details are in the bug report: >>>> >>>> ??? JDK-8217659 monitor_logging updates from Async Monitor >>>> Deflation project >>>> ??? https://bugs.openjdk.java.net/browse/JDK-8217659 >>>> >>>> Here's the webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8217659-webrev/0-for-jdk13/ >>>> >>>> This patch along with the other two patches for Async Monitor >>>> Deflation >>>> project have been through Mach5 >>>> builds-tier1,hs-tier1,jdk-tier1,hs-tier2,hs-tier3 >>>> testing and I'm currently running my stress testing kits on my >>>> Linux-X64 >>>> and Solaris-X64 servers. >>>> >>>> I have been actively using this new logging code while debugging my >>>> port of the Async Monitor Deflation project code. >>>> >>>> Thanks, in advance, for any questions, comments or suggestions. >>>> >>>> Dan >>>> >>>> >>> >> > From daniel.daugherty at oracle.com Mon Jan 28 22:22:28 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 28 Jan 2019 17:22:28 -0500 Subject: RFR(S/M): 8217659 monitor_logging updates from Async Monitor Deflation project In-Reply-To: <4383a85b-cf89-3f06-0f46-ba4e4159434e@oracle.com> References: <98f74cf8-1634-c0ad-0bbc-7c2d8e31a467@oracle.com> <003a4d2e-f7c1-cc57-6ab8-6a207ce64896@oracle.com> <39addd9a-532d-0bab-31fb-bdce5d67f426@oracle.com> <4383a85b-cf89-3f06-0f46-ba4e4159434e@oracle.com> Message-ID: On 1/28/19 5:15 PM, coleen.phillimore at oracle.com wrote: > On 1/28/19 5:07 PM, Daniel D. Daugherty wrote: >> On 1/28/19 4:32 PM, coleen.phillimore at oracle.com wrote: >>> >>> Hi Dan, This looks better, especially audit_and_print_stats. >> >> Thanks! And thanks for the re-review!! >> >> >>> My eyes are terrible, but it looks like this is >>> ObjectMonitor::verify_free() >> >> This comment really confused me. I didn't remember an >> ObjectMonitor::verify_free() so I was grep'ing all over the >> place trying to find it. >> >> After reading to the bottom of this email, I see that you >> think this could be refactored into a new function called >> ObjectMonitor::verify_free(). Now I feel less confused... :-) >> > > Sorry about that.? It was my second (better, if you can believe it) > attempt at suggesting this. It was a better attempt. >> >>> + if (n->is_busy()) { >>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global >>> monitor " >>> + "must not be busy.", p2i(n)); >>> + *error_cnt_p = *error_cnt_p + 1; >>> + } >>> + if (n->header() != NULL) { >>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global >>> monitor " >>> + "must have NULL _header field: _header=" INTPTR_FORMAT, >>> + p2i(n), p2i(n->header())); >>> + *error_cnt_p = *error_cnt_p + 1; >>> + } >>> + if (n->object() != NULL) { >>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global >>> monitor " >>> + "must have NULL _object field: _object=" INTPTR_FORMAT, >>> + p2i(n), p2i(n->object())); >>> + *error_cnt_p = *error_cnt_p + 1; >>> + } ... >>> >>> And this is ObjectMonitor::verify_in_use() >>> >>> + if (n->header() == NULL) { >>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": in-use global >>> monitor " >>> + "must have non-NULL _header field.", p2i(n)); >>> + *error_cnt_p = *error_cnt_p + 1; >>> + } >>> + if (n->object() == NULL) { >>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": in-use global >>> monitor " >>> + "must have non-NULL _object field.", p2i(n)); >>> + *error_cnt_p = *error_cnt_p + 1; >>> + } ... >> >> And another refactor recommendation... okay. >> >> >>> And you do the same checks for the per-thread versions.? That's what >>> I noticed before.? I like the refactoring that you did but if you >>> want to do more, this is what I'd suggest. >> >> In my first reply to David on this review thread, I wrote: >> >>> Maybe after the above simplifications, other ways to make this >>> function more digestible will become apparent... >> >> What you're suggesting fits right in with more simplifications >> becoming apparent. > > Yes, the power of refactoring ... Fits right in there with the power of code deletion. > >>> ObjectMonitor doesn't have any verify functions and it seems like >>> the knowledge of these fields really belongs there.? Anyways, these >>> files are tightly coupled, so it's ok the way it is.? Maybe better >>> not to pull that thread right now. >> >> It's kind of a toss up between ObjectMonitor.* and synchronizer.*. >> Yes, ObjectMonitor.* defines all the fields and _some_ of the ops, >> but there is a lot of logic in synchronizer.* that determines how >> the fields are used. > > That's sort of broken encapsulation imho, which makes this tricky code > more difficult to understand.? We can clean up as we go though.? > There's plenty to do in that regard. Preaching to the choir... The purpose of this bug fix is to make the code easier to diagnose since we are considering making changes to it. We will definitely clean up as we go. >> >> I'll take a look at the possibility of more refactoring, but it >> may not happen with this bug (8217659). >> > > Yes, if you want to do this separately and have captured enough of > this to do so, a separate RFE is fine.? I'll add to it if you need me to. I think I could file a nice RFE to cover this idea if I don't take care of it now. Dan > > Thanks, > Coleen >> Dan >> >> >>> >>> thanks, >>> Coleen >>> >>> >>> >>> On 1/26/19 10:10 PM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> I've updated the patch to resolve code review comments from David H. >>>> and Coleen. I've also rebased the patch to the jdk/jdk repo at the >>>> 'jdk-13+5' tag (plus the 8217658 patch); there were no merge >>>> surprises. >>>> >>>> Here's an incremental webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8217659-webrev/1-for-jdk13.inc/ >>>> >>>> I've also generated a full webrev since the changes to >>>> synchronizer.cpp >>>> are extensive and that's the easier way to review it: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8217659-webrev/1-for-jdk13.full/ >>>> >>>> This patch along with 8217658 have been through Mach5 >>>> builds-tier1,hs-tier1,jdk-tier1,hs-tier2,hs-tier3 testing with >>>> no failures. >>>> >>>> Thanks, in advance, for any questions, comments or suggestions. >>>> >>>> Dan >>>> >>>> P.S. >>>> I've attached sample output for running Hello.java with the >>>> monitorinflation logging enabled at Info, Debug and Trace. >>>> >>>> >>>> On 1/23/19 3:16 PM, Daniel D. Daugherty wrote: >>>>> Greetings, >>>>> >>>>> I have a (S)mall/(M)edium patch extracted from the Async Monitor >>>>> Deflation >>>>> project that is ready for code review. I'm calling this a >>>>> (S)mall/(M)edium >>>>> because the logic changes are (S)mall, but the logging code is >>>>> tedious and >>>>> there's a bunch of it in audit_and_print_stats() so (M)edium. >>>>> >>>>> The short version of what this patch is about: >>>>> >>>>> ??? This sub-task captures updates and additions to the >>>>> ??? baseline monitor logging code. >>>>> >>>>> The details are in the bug report: >>>>> >>>>> ??? JDK-8217659 monitor_logging updates from Async Monitor >>>>> Deflation project >>>>> ??? https://bugs.openjdk.java.net/browse/JDK-8217659 >>>>> >>>>> Here's the webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8217659-webrev/0-for-jdk13/ >>>>> >>>>> This patch along with the other two patches for Async Monitor >>>>> Deflation >>>>> project have been through Mach5 >>>>> builds-tier1,hs-tier1,jdk-tier1,hs-tier2,hs-tier3 >>>>> testing and I'm currently running my stress testing kits on my >>>>> Linux-X64 >>>>> and Solaris-X64 servers. >>>>> >>>>> I have been actively using this new logging code while debugging my >>>>> port of the Async Monitor Deflation project code. >>>>> >>>>> Thanks, in advance, for any questions, comments or suggestions. >>>>> >>>>> Dan >>>>> >>>>> >>>> >>> >> > From aoqi at loongson.cn Tue Jan 29 01:41:34 2019 From: aoqi at loongson.cn (Ao Qi) Date: Tue, 29 Jan 2019 09:41:34 +0800 Subject: [TESTBUG] runtime/containers/docker/TestCPUAwareness.java failed in docker not supporting --cpus In-Reply-To: <6C6F3704-041B-4940-87E5-A73AB0808847@oracle.com> References: <420d2b08-86df-d591-35c9-d359a8811e9c@oracle.com> <3ABBCD75-1515-4B83-9FC1-18C737FD7C99@oracle.com> <6C6F3704-041B-4940-87E5-A73AB0808847@oracle.com> Message-ID: Hi Bob, Thanks! I am not a containers expert and have one small question. The maximum amount of --cpus is 4 (equivalent to both setting ?cpu-period and ?cpu-quota) in the already existing test. Is it valuable to keep testCpus(i, i) according to the max num of available CPUs? If not, I would also prefer removing the lines. In addition, I think I forgot to update the copyright year, it will be fixed in the next version of wevrev. On Mon, Jan 28, 2019 at 11:35 PM Bob Vandette wrote: > > There is already a test that verifies ?cpu-period and ?cpu-quota. > I would just remove these lines. > > 62 // leave one CPU for system and tools, otherwise this test may be unstable > 63 int maxNrOfAvailableCpus = availableCPUs - 1; > 64 for (int i=1; i < maxNrOfAvailableCpus; i = i * 2) { > 65 testCpus(i, i); > 66 } > > 129 private static void testCpus(int valueToSet, int expectedTraceValue) throws Exception { > 130 Common.logNewTestCase("test cpus: " + valueToSet); > 131 DockerRunOptions opts = Common.newOpts(imageName) > 132 .addDockerOpts("--cpus", "" + valueToSet); > 133 Common.run(opts) > 134 .shouldMatch("active_processor_count.*" + expectedTraceValue); > 135 } > > Bob. > > On Jan 28, 2019, at 10:22 AM, Ao Qi wrote: > > Hi, > > Since ?cpus is a shortcut for of setting both --cpu-period and > --cpu-quota and the test is not intended to verify that docker works > correctly, I did not check the docker version and just replaced > setting --cpus with setting both --cpu-period and --cpu-quota. What do > you think of this patch: > http://cr.openjdk.java.net/~aoqi/8217597/webrev.01/ ? > > Cheers, > Ao Qi > > > On Wed, Jan 23, 2019 at 11:37 PM Bob Vandette wrote: > > > Since ?cpus is just a shortcut for of setting both --cpu-period and --cpu-quota?, I?d > be ok with removing this test. The tests are intended to test the container/cgroup > configuration detection logic and not to verify that docker works correctly. > > An alternate solution would be to add version detection to the Docker test check in > DockerTestUtils.java . We already exec ?docker ps? to see if docker is available > and enabled. > > % docker --version > Docker version 17.03.1-ce, build 276fd32 > > > Bob. > > > > On Jan 22, 2019, at 10:19 PM, Ao Qi wrote: > > On Wed, Jan 23, 2019 at 10:55 AM David Holmes wrote: > > > On 23/01/2019 11:58 am, Ao Qi wrote: > > Hi David, > > On Wed, Jan 23, 2019 at 5:24 AM David Holmes wrote: > > > cc'ing Bob as our containers expert ... > > On 23/01/2019 1:10 am, Ao Qi wrote: > > Hi, > > --cpus is available in Docker 1.13 and higher [1], so > runtime/containers/docker/TestCPUAwareness.java failed in docker which > does not support --cpus. > > Webrev: http://cr.openjdk.java.net/~aoqi/docker/webrev.00/ > > This patch skips the test if --cpus is not supported. I tested > runtime/containers/docker/TestCPUAwareness.java on a Fedora 25 (Docker > version 1.12.6, build ae7d637/1.12.6, not supporting --cpus) and > Ubuntu 16.04 (Docker version 17.03.2-ce, build f5ec1e2, supporting > --cpus) > > > The patch causes the test to pass if launching Docker fails for any > reason so that is not good. > > > I tested two versions of docker which does not support --cpus. Their > exit values when using --cpus are 2 and 125, and outputs are: > > flag provided but not defined: --cpus > See 'docker run --help'. > > and > > unknown flag: --cpus > See 'docker run --help'. > > My initial thought was that the else condition of > "output.getExitValue() == 0" should match the condition of "--cpus not > supported". Firstly I used output.shouldMatch("docker run --help"), > but I am not sure if all the docker version behaves this way when > --cpus is not supported and "docker run --help" does not certainly > indicate "--cpus not supported", so I removed the else condition. > > > I think we need to try and find a way to clearly identifyt eh failing > condition. Is there are "docker --version" we coudl check? > > > I will do more research. Checking docker version may be one option, > and checking whether one option is support by docker may be also one > option. I will try them later, while waiting if there are some other > opinions :) > > I am not sure if this is a testbug, so I did not file it on JBS. In > fact, I am not quite sure what kind of issue can be filed on JBS. Is > there any guidance document? > > > Any/all issues can be filed on JBS. You don't need to pre-classify as a > testbug, simple create an issue that a test is failing under specific > conditions. Whomever works on the bug will then determine whether it is > a testbug or product issue or something else. (We don't seem to have any > docs on using JBS ...) > > > What if the issue is not a bug or no body cares the issue? The issue > will be open on JBS forever? > > > Possibly :) But each component team performs regular triage of the bugs > that get filed and eventually things will be examined enough to see if > they are indeed a bug, and if not they will be closed as not an issue. > If a bug but low priority it may eventually get closed as "will not fix" > just to keep the open bug count down. > > > I was a little afraid that filing issues that are not bugs or nobody > cares would increase the workload of others and frustrate myself, so I > was not sure what kind of issue should be filed. Now I basically > clear, thanks David. > > Cheers, > David > > Thanks for your explanation, and I filed this issue on JBS: > https://bugs.openjdk.java.net/browse/JDK-8217597 > > In this case I'm not sure whether we require a docker version that > supports --cpus, and the test should be skipped otherwise. Though > ideally this would involve an explicit version check so we don't just > pass if the docker process fails. > > Thanks, > David > > > > Cheers, > Ao Qi > > [1] https://docs.docker.com/config/containers/resource_constraints/#cpu > > > From kim.barrett at oracle.com Tue Jan 29 03:24:23 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 28 Jan 2019 22:24:23 -0500 Subject: RFR (M): 8217778: StringTable cleanup miscalculates amount of dead objects In-Reply-To: <7a944a8567e8768986f3c72a030b0538cc71ebd9.camel@oracle.com> References: <2140b41eb336ec5260b68eefd010c670a0b7a4ca.camel@oracle.com> <7a944a8567e8768986f3c72a030b0538cc71ebd9.camel@oracle.com> Message-ID: <28211400-CBAA-485C-8852-6FCBBCBC4D09@oracle.com> On Mon, 2019-01-28 at 12:43 +0100, Thomas Schatzl wrote: > Hi all, > > can I have reviews for this change that tries to fix the issue with > the string table reporting too low "dead" numbers to the > ServiceThread notification mechanism in the review for JDK-8213229, > potentially causing C heap memory being kept live for longer than > necessary? > > This change implements one option for fixing this, in particular that > the WeakProcessor calls OopStorage::oops_do() instead of > ::weak_oops_do, counting the number of NULL entries manually. I think this is the right approach to take. > There is another, let weak_oops_do() return the number of NULL > entries as function return value. However the return value of the > used iterate_safepoint() is already in use in some I'd consider > interesting test case. I did not want to add another out-parameter > either. That short-circuiting behavior and result is to support some places in JVMTI that have not (yet) been modified to make use of the feature. There might be other places that could benefit. > Since the WeakProcessor has been the main user of the weak_oops_do() > method, I would suggest to clean this up preferably in an extra CR: > there is still one use of the OopStorage::weak_oops_do() method that > could be easily removed. If you think we should not remove it, I > strongly suggest to rename the weak_oops_do() methods to better > indicate what they actually do instead of giving a very strong > (wrong) suggestion where/when they should be used. Where is the remaining weak_oops_do? I don't have any objection to it being removed, as it exists only for convenience of callers. If there aren't any callers... As I said privately, OopStorage::weak_oops_do is just following a common idiom used elsewhere, where it's a shorthand for an oops_do with a closure that does if-nonnull-then-if-isalive-then-keepalive-else-clear There is nothing wrong with applying oops_do to an OopStorage containing weak oops, and in fact there are various places that do exactly that. Or said differently, it is not necessary to use weak_oops_do to iterate over an OopStorage containing weak oops. > CR: > https://bugs.openjdk.java.net/browse/JDK-8217778 > Webrev: > http://cr.openjdk.java.net/~tschatzl/8217778/webrev/ > Testing: > hs-tier1-5 > > Thanks, > Thomas Looks good. A couple minor cleanup suggestions. I don't need another webrev if you decide to do these. ------------------------------------------------------------------------------ src/hotspot/share/gc/shared/weakProcessor.cpp 41 CountingIsAliveClosure cl(is_alive); Why are we counting here? We don't do anything with the resulting count. (I missed this when reviewing JDK-8213229.) Similarly here, when !is_stringtable(phase): 44 CountingSkippedIsAliveClosure cl(is_alive, keep_alive); There could instead be a separate is_stringtable(phase) clause which had the calls to StringTable::(reset|finish)_dead_counter() and the counting closure stuff all close together and associated only with the stringtable storage iteration. ------------------------------------------------------------------------------ src/hotspot/share/gc/shared/weakProcessor.inline.hpp 74 if (obj == NULL) { 75 _num_skipped++; 76 return; 77 } 78 if (_counting_is_alive.do_object_b(obj)) { 79 _keep_alive->do_oop(p); 80 } else { 81 *p = NULL; 82 } This would be simpler if the line 76 "return" were removed and the line 78 "if" were an "else if", having a single if-ladder. ------------------------------------------------------------------------------ From kim.barrett at oracle.com Tue Jan 29 03:58:35 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 28 Jan 2019 22:58:35 -0500 Subject: RFR (M): 8217778: StringTable cleanup miscalculates amount of dead objects In-Reply-To: <28211400-CBAA-485C-8852-6FCBBCBC4D09@oracle.com> References: <2140b41eb336ec5260b68eefd010c670a0b7a4ca.camel@oracle.com> <7a944a8567e8768986f3c72a030b0538cc71ebd9.camel@oracle.com> <28211400-CBAA-485C-8852-6FCBBCBC4D09@oracle.com> Message-ID: <406D82B0-803C-4998-8237-9902B82FB763@oracle.com> > On Jan 28, 2019, at 10:24 PM, Kim Barrett wrote: > >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8217778 >> Webrev: >> http://cr.openjdk.java.net/~tschatzl/8217778/webrev/ >> Testing: >> hs-tier1-5 >> >> Thanks, >> Thomas > > Looks good. > > A couple minor cleanup suggestions. I don't need another webrev if > you decide to do these. > Sorry, I missed this: ------------------------------------------------------------------------------ src/hotspot/share/gc/shared/weakProcessor.cpp 44 CountingSkippedIsAliveClosure cl(is_alive, keep_alive); A different approach is possible in this serial case. We could wrap the keep_alive closure for counting, as the number we want to pass to inc_dead_counter is also available here as storage->allocation_count() - ------------------------------------------------------------------------------ From kim.barrett at oracle.com Tue Jan 29 04:02:14 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 28 Jan 2019 23:02:14 -0500 Subject: RFR (M): 8217778: StringTable cleanup miscalculates amount of dead objects In-Reply-To: <30a9667d-5b9e-2f25-a069-78027423f451@oracle.com> References: <2140b41eb336ec5260b68eefd010c670a0b7a4ca.camel@oracle.com> <7a944a8567e8768986f3c72a030b0538cc71ebd9.camel@oracle.com> <30a9667d-5b9e-2f25-a069-78027423f451@oracle.com> Message-ID: > On Jan 28, 2019, at 4:46 PM, coleen.phillimore at oracle.com wrote: > > > Hi Thomas, Can you forward the review thread for JDK-8213229? > > I wonder if we could just trigger_unloading after any GC has run and ignore dead string counts. Are they ever zero? We?re trying to only trigger the ServiceThread?s StringTable cleanup when there are enough nulled-out entries to make it worth the effort. My guess would be that interned strings rarely die young. In which case that approach would probably trigger the ServiceThread unnecessarily frequently. Maybe instead avoid the counting and unconditionally trigger after a (possibly concurrent) full collection? That doesn?t do so well for the (possibly rare?) application that does frequently intern and then drop strings though. Or don?t trigger the ServiceThread more often than some (perhaps configurable? Ugh! A new CLOption) frequency. Also, I wonder if the SymbolTable has the same miscalculation. The SymbolTable code was somewhat cribbed from StringTable, after all. From kim.barrett at oracle.com Tue Jan 29 04:04:15 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 28 Jan 2019 23:04:15 -0500 Subject: RFR 8214821: Remove ConcurrentHashTable::get_copy In-Reply-To: References: Message-ID: > On Jan 23, 2019, at 1:49 PM, Gerard Ziemski wrote: > > Hi all, > > Please review this simple fix that removes ?ConcurrentHashTable::get_copy? API, whose only client was a single gtest. Doing so allows us to remove CONFIG::notfound() > > That gtest replaces the usage of ?get_copy? API with a local ?cht_get_copy? method, which itself is implemented using "ConcurrentHashTable::get? API > > I also took this opportunity to clean up a few method names in the test a bit. > > References: > > https://bugs.openjdk.java.net/browse/JDK-8214821 > http://cr.openjdk.java.net/~gziemski/8214821_rev1 > > Passes gtest locally on Mac and passes Mach5 hs-tier1,2,3,4,5,6 > > > Cheers Looks good. From sgehwolf at redhat.com Tue Jan 29 09:15:36 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Tue, 29 Jan 2019 10:15:36 +0100 Subject: RFR: 8217921: Runtime dead code removal In-Reply-To: <10accb5f-fe5b-26e3-ce80-5bf19a58c09f@oracle.com> References: <10accb5f-fe5b-26e3-ce80-5bf19a58c09f@oracle.com> Message-ID: On Mon, 2019-01-28 at 22:24 +0100, Claes Redestad wrote: > Hi, > > please review this patch to remove dead code in the runtime, interpreter > and related areas. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8217921 > Webrev: http://cr.openjdk.java.net/~redestad/8217921/open.00/ > > Testing: tier1+2 > > I've taken care to check every change to ensure it's not in use by some > platform specific code on a platform that's not built/supported by > Oracle, but help verifying this would be greatly appreciated. > > I've also checked the patch applies cleanly to a few valhalla and amber > branches to avoid excessive merge issues. I've verified this builds fine with the Zero config on Linux x86_64. Thanks, Severin From claes.redestad at oracle.com Tue Jan 29 09:18:21 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 29 Jan 2019 10:18:21 +0100 Subject: RFR: 8217921: Runtime dead code removal In-Reply-To: References: <10accb5f-fe5b-26e3-ce80-5bf19a58c09f@oracle.com> Message-ID: On 2019-01-29 10:15, Severin Gehwolf wrote: > I've verified this builds fine with the Zero config on Linux x86_64. Thanks, Severin! /Claes From david.holmes at oracle.com Tue Jan 29 09:30:19 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 29 Jan 2019 19:30:19 +1000 Subject: RFR: 8217921: Runtime dead code removal In-Reply-To: <10accb5f-fe5b-26e3-ce80-5bf19a58c09f@oracle.com> References: <10accb5f-fe5b-26e3-ce80-5bf19a58c09f@oracle.com> Message-ID: Hi Claes, On 29/01/2019 7:24 am, Claes Redestad wrote: > Hi, > > please review this patch to remove dead code in the runtime, interpreter > and related areas. > > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8217921 > Webrev: http://cr.openjdk.java.net/~redestad/8217921/open.00/ This mostly seems okay but I have some reservations about trimming APIs just because we don't currently use them. For example the changes in src/hotspot/share/memory/binaryTreeDictionary.inline.hpp I expect to see a complete data structures defined with all the reasonable operations. The fact we don't actually use some of them doesn't mean to me that we should cull them out of the API. Cheers, David ----- > Testing: tier1+2 > > I've taken care to check every change to ensure it's not in use by some > platform specific code on a platform that's not built/supported by > Oracle, but help verifying this would be greatly appreciated. > > I've also checked the patch applies cleanly to a few valhalla and amber > branches to avoid excessive merge issues. > > Thanks! > > /Claes From david.holmes at oracle.com Tue Jan 29 09:36:15 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 29 Jan 2019 19:36:15 +1000 Subject: RFR(M): 8217628: Verbose ArrayIndexOutOfBoundsException message also in JNI In-Reply-To: <6cfec56213c44995bd24426f8fa982f0@sap.com> References: <8b1ed15e-2569-ffad-79aa-95d29340523c@oracle.com> <6cfec56213c44995bd24426f8fa982f0@sap.com> Message-ID: Looks good! Thanks, David On 28/01/2019 8:22 pm, Lindenmaier, Goetz wrote: > Hi, > > Here a new webrev: > http://cr.openjdk.java.net/~goetz/wr19/8217628-AIOOBE_msg_jni/03/ > (David, sorry, I missed the list in my mail Friday...) > > Messages are capitalized, the method is refactored (definitely better!). > > Thanks to Martin and Mathias who pointed me to the build error > of the lib on solaris ?? > > This now passed jdk/submit. > > Best regards, > Goetz. > > >> -----Original Message----- >> From: David Holmes >> Sent: Donnerstag, 24. Januar 2019 01:40 >> To: Lindenmaier, Goetz ; hotspot-runtime- >> dev at openjdk.java.net >> Subject: Re: RFR(M): 8217628: Verbose ArrayIndexOutOfBoundsException >> message also in JNI >> >> Hi Goetz, >> >> On 24/01/2019 12:37 am, Lindenmaier, Goetz wrote: >>> Hi >>> >>> Change JDK-8201593 >> : Print array length in ArrayIndexOutOfBoundsException >>> introduced text as "Index 13 out of bounds for length 10" to various AIOOB >> exceptions >>> thrown in the VM. It omitted the exceptions thrown in jni calls. >>> >>> This change extends the messages to the AIOOB exceptions thrown in >>> Get|SetObjectArrayElement and Get|SetArrayRegion. >>> >>> Before, Get|SetObjectArrayElement printed just the index, >>> Get|SetArrayRegion printed no message. >>> >>> Now the following messages are printed: >>> "Index %d out of bounds for length %d" >>> "length %d is negative" >>> "array region %d..%d out of bounds for length %d" >>> >>> Any advice on capitalizing the first word? It's already >>> handled inconsistently... >> >> I'd suggest capitalizing. >> >>> Please review: >>> http://cr.openjdk.java.net/~goetz/wr19/8217628-AIOOBE_msg_jni/01/ >> >> Could I ask that you factor the region check into a small function so we >> don't duplicate the logic please. It would take TRAPS and would be >> called with a CHECK. >> >> Thanks, >> David >> ----- >> >>> >>> >>> Best regards, >>> >>> Goetz. >>> From claes.redestad at oracle.com Tue Jan 29 09:50:58 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 29 Jan 2019 10:50:58 +0100 Subject: RFR: 8217921: Runtime dead code removal In-Reply-To: References: <10accb5f-fe5b-26e3-ce80-5bf19a58c09f@oracle.com> Message-ID: <0983b592-ffaa-3d12-c910-3e67bdb2b4bc@oracle.com> On 2019-01-29 10:30, David Holmes wrote: >> >> Webrev: http://cr.openjdk.java.net/~redestad/8217921/open.00/ > > This mostly seems okay but I have some reservations about trimming APIs > just because we don't currently use them. For example the changes in > > src/hotspot/share/memory/binaryTreeDictionary.inline.hpp > > I expect to see a complete data structures defined with all the > reasonable operations. The fact we don't actually use some of them > doesn't mean to me that we should cull them out of the API. I disagree: It's easy to add functionality back if/when we need it, and unused/untested code should be considered broken until proven otherwise. /Claes From thomas.schatzl at oracle.com Tue Jan 29 09:51:31 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 29 Jan 2019 10:51:31 +0100 Subject: RFR (M): 8217778: StringTable cleanup miscalculates amount of dead objects In-Reply-To: <30a9667d-5b9e-2f25-a069-78027423f451@oracle.com> References: <2140b41eb336ec5260b68eefd010c670a0b7a4ca.camel@oracle.com> <7a944a8567e8768986f3c72a030b0538cc71ebd9.camel@oracle.com> <30a9667d-5b9e-2f25-a069-78027423f451@oracle.com> Message-ID: <29d6bf77f5003d13cb0497288115c2a108ce9e5f.camel@oracle.com> Hi, On Mon, 2019-01-28 at 16:46 -0500, coleen.phillimore at oracle.com wrote: > Hi Thomas, Can you forward the review thread for JDK-8213229? the thread starts at http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2019-January/024474.html , but the interesting part is probably starting here http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2019-January/024649.html . > I wonder if we could just trigger_unloading after any GC has run and > ignore dead string counts. Are they ever zero? That seems to be a waste of cpu cycles assuming that interned strings typically have a "long" lifetime. Thanks, Thomas From david.holmes at oracle.com Tue Jan 29 10:00:16 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 29 Jan 2019 20:00:16 +1000 Subject: RFR: 8217921: Runtime dead code removal In-Reply-To: <0983b592-ffaa-3d12-c910-3e67bdb2b4bc@oracle.com> References: <10accb5f-fe5b-26e3-ce80-5bf19a58c09f@oracle.com> <0983b592-ffaa-3d12-c910-3e67bdb2b4bc@oracle.com> Message-ID: On 29/01/2019 7:50 pm, Claes Redestad wrote: > > > On 2019-01-29 10:30, David Holmes wrote: >>> >>> Webrev: http://cr.openjdk.java.net/~redestad/8217921/open.00/ >> >> This mostly seems okay but I have some reservations about trimming >> APIs just because we don't currently use them. For example the changes in >> >> src/hotspot/share/memory/binaryTreeDictionary.inline.hpp >> >> I expect to see a complete data structures defined with all the >> reasonable operations. The fact we don't actually use some of them >> doesn't mean to me that we should cull them out of the API. > > I disagree: It's easy to add functionality back if/when we need it, and > unused/untested code should be considered broken until proven otherwise. I disagree about the ease of adding back. Someone trying to add functionality to an existing data structure is more likely to get it wrong than the person who wrote the thing initially - especially years later. These are basically library classes that have been written. And the person adding back will have no idea that we removed it earlier. Is there a risk that the unused function has bit-rotted? Unfortunately yes, if we have been very lax in how we update these data structures. But if this hasn't been modified then it's as good now as it was when written. But as I said these are just reservations, not hard obstacles. David > /Claes From goetz.lindenmaier at sap.com Tue Jan 29 10:11:02 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 29 Jan 2019 10:11:02 +0000 Subject: RFR(M): 8217628: Verbose ArrayIndexOutOfBoundsException message also in JNI In-Reply-To: References: <8b1ed15e-2569-ffad-79aa-95d29340523c@oracle.com> <6cfec56213c44995bd24426f8fa982f0@sap.com> Message-ID: Thanks! Best regards, Goetz > -----Original Message----- > From: David Holmes > Sent: Dienstag, 29. Januar 2019 10:36 > To: Lindenmaier, Goetz ; hotspot-runtime- > dev at openjdk.java.net > Subject: Re: RFR(M): 8217628: Verbose ArrayIndexOutOfBoundsException > message also in JNI > > Looks good! > > Thanks, > David > > On 28/01/2019 8:22 pm, Lindenmaier, Goetz wrote: > > Hi, > > > > Here a new webrev: > > http://cr.openjdk.java.net/~goetz/wr19/8217628-AIOOBE_msg_jni/03/ > > (David, sorry, I missed the list in my mail Friday...) > > > > Messages are capitalized, the method is refactored (definitely better!). > > > > Thanks to Martin and Mathias who pointed me to the build error > > of the lib on solaris ?? > > > > This now passed jdk/submit. > > > > Best regards, > > Goetz. > > > > > >> -----Original Message----- > >> From: David Holmes > >> Sent: Donnerstag, 24. Januar 2019 01:40 > >> To: Lindenmaier, Goetz ; hotspot-runtime- > >> dev at openjdk.java.net > >> Subject: Re: RFR(M): 8217628: Verbose ArrayIndexOutOfBoundsException > >> message also in JNI > >> > >> Hi Goetz, > >> > >> On 24/01/2019 12:37 am, Lindenmaier, Goetz wrote: > >>> Hi > >>> > >>> Change JDK-8201593 8201593> > >> : Print array length in ArrayIndexOutOfBoundsException > >>> introduced text as "Index 13 out of bounds for length 10" to various AIOOB > >> exceptions > >>> thrown in the VM. It omitted the exceptions thrown in jni calls. > >>> > >>> This change extends the messages to the AIOOB exceptions thrown in > >>> Get|SetObjectArrayElement and Get|SetArrayRegion. > >>> > >>> Before, Get|SetObjectArrayElement printed just the index, > >>> Get|SetArrayRegion printed no message. > >>> > >>> Now the following messages are printed: > >>> "Index %d out of bounds for length %d" > >>> "length %d is negative" > >>> "array region %d..%d out of bounds for length %d" > >>> > >>> Any advice on capitalizing the first word? It's already > >>> handled inconsistently... > >> > >> I'd suggest capitalizing. > >> > >>> Please review: > >>> http://cr.openjdk.java.net/~goetz/wr19/8217628-AIOOBE_msg_jni/01/ > >> > >> Could I ask that you factor the region check into a small function so we > >> don't duplicate the logic please. It would take TRAPS and would be > >> called with a CHECK. > >> > >> Thanks, > >> David > >> ----- > >> > >>> > >>> > >>> Best regards, > >>> > >>> Goetz. > >>> From coleen.phillimore at oracle.com Tue Jan 29 18:12:08 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 29 Jan 2019 13:12:08 -0500 Subject: RFR (M): 8217778: StringTable cleanup miscalculates amount of dead objects In-Reply-To: <29d6bf77f5003d13cb0497288115c2a108ce9e5f.camel@oracle.com> References: <2140b41eb336ec5260b68eefd010c670a0b7a4ca.camel@oracle.com> <7a944a8567e8768986f3c72a030b0538cc71ebd9.camel@oracle.com> <30a9667d-5b9e-2f25-a069-78027423f451@oracle.com> <29d6bf77f5003d13cb0497288115c2a108ce9e5f.camel@oracle.com> Message-ID: <5a9a5170-f5d5-f337-865c-6ae1c2e99241@oracle.com> On 1/29/19 4:51 AM, Thomas Schatzl wrote: > Hi, > > On Mon, 2019-01-28 at 16:46 -0500, coleen.phillimore at oracle.com wrote: >> Hi Thomas, Can you forward the review thread for JDK-8213229? > the thread starts at > http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2019-January/024474.html > , but the interesting part is probably starting here > http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2019-January/024649.html > . So this moves StringTable processing into the WeakProcessor.? good! Not a review though. http://cr.openjdk.java.net/~tschatzl/8217778/webrev/src/hotspot/share/gc/shared/weakProcessor.inline.hpp.frames.html If these Counting closures are only used in the weakProcessor.cpp file, they should be defined there.? It looks like their use was moved. http://cr.openjdk.java.net/~tschatzl/8217778/webrev/src/hotspot/share/gc/shared/weakProcessor.cpp.frames.html I don't know what "is_serial does but it doesn't look like you're using the num_dead() count when calling processor. 40 if (WeakProcessorPhases::is_serial(phase)) { 41 CountingIsAliveClosure cl(is_alive); 42 WeakProcessorPhases::processor(phase)(&cl, keep_alive); 43 } else { 44 CountingSkippedIsAliveClosure cl(is_alive, keep_alive); 45 WeakProcessorPhases::oop_storage(phase)->oops_do(&cl); 46 if (WeakProcessorPhases::is_stringtable(phase)) { 47 StringTable::inc_dead_counter(cl.num_dead() + cl.num_skipped()); 48 } 49 } Thanks, Coleen >> I wonder if we could just trigger_unloading after any GC has run and >> ignore dead string counts. Are they ever zero? > That seems to be a waste of cpu cycles assuming that interned strings > typically have a "long" lifetime. Since the VM has to intern any strings in the JVM_CONSTANT_String in the classfile, class unloading probably should trigger_unloading unconditionally if any classes are unloaded.? It seems very likely there would be unreferenced strings. But we may need the ServiceThread to unlink reclaimed entries even if classes aren't unloaded, which may be infrequent but there may have been stressful applications that have required it in the past. Can you log if the count is ever too low to process the StringTable? The change for this looks reasonable, but not a full review.? I kind of like keeping the concept of weak_oops_do() because it's a well known idiom but as Kim says, it's not necessary to call weak_oops_do on something that contains weak oops. CR: https://bugs.openjdk.java.net/browse/JDK-8217778 Webrev: http://cr.openjdk.java.net/~tschatzl/8217778/webrev/ Thanks, Coleen > > Thanks, > Thomas > > From coleen.phillimore at oracle.com Tue Jan 29 18:22:50 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 29 Jan 2019 13:22:50 -0500 Subject: RFR (M): 8217778: StringTable cleanup miscalculates amount of dead objects In-Reply-To: References: <2140b41eb336ec5260b68eefd010c670a0b7a4ca.camel@oracle.com> <7a944a8567e8768986f3c72a030b0538cc71ebd9.camel@oracle.com> <30a9667d-5b9e-2f25-a069-78027423f451@oracle.com> Message-ID: <00150fef-35af-b5fc-dd8e-ae7c305fd928@oracle.com> On 1/28/19 11:02 PM, Kim Barrett wrote: >> On Jan 28, 2019, at 4:46 PM, coleen.phillimore at oracle.com wrote: >> >> >> Hi Thomas, Can you forward the review thread for JDK-8213229? >> >> I wonder if we could just trigger_unloading after any GC has run and ignore dead string counts. Are they ever zero? > We?re trying to only trigger the ServiceThread?s StringTable cleanup when there > are enough nulled-out entries to make it worth the effort. My guess would be that > interned strings rarely die young. In which case that approach would probably > trigger the ServiceThread unnecessarily frequently. Maybe instead avoid the > counting and unconditionally trigger after a (possibly concurrent) full collection? > That doesn?t do so well for the (possibly rare?) application that does frequently > intern and then drop strings though. Or don?t trigger the ServiceThread more > often than some (perhaps configurable? Ugh! A new CLOption) frequency. I definitely don't want another command line option, but triggering after a collection that might do class unloading makes sense.? But yeah, some cases might have lots of interned strings outside of class loading.? I thought that the stringTable insert code noted dead entries on the way, but that's only used by the symbolTable. > > Also, I wonder if the SymbolTable has the same miscalculation. The SymbolTable > code was somewhat cribbed from StringTable, after all. > Yes, the SymbolTable code was similar but the Symbols are 90-99% brought in by class loading, so triggering during unloading unconditionally make sense there.?? And even when we counted, if there was 1 Symbol free, we'd clean the table.? It's concurrent, and hasn't been seen to cause undo slowdown on the applications we've benchmarked, so this is good. See:? 8213753: Move timing of ProtectionDomainTable and ResolvedMethodTable cleanup to service thread I should split this RFE because this also moves SymbolTable cleaning to only trigger during unloading. Coleen From thomas.schatzl at oracle.com Tue Jan 29 18:37:21 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Tue, 29 Jan 2019 19:37:21 +0100 Subject: RFR (M): 8217778: StringTable cleanup miscalculates amount of dead objects In-Reply-To: <5a9a5170-f5d5-f337-865c-6ae1c2e99241@oracle.com> References: <2140b41eb336ec5260b68eefd010c670a0b7a4ca.camel@oracle.com> <7a944a8567e8768986f3c72a030b0538cc71ebd9.camel@oracle.com> <30a9667d-5b9e-2f25-a069-78027423f451@oracle.com> <29d6bf77f5003d13cb0497288115c2a108ce9e5f.camel@oracle.com> <5a9a5170-f5d5-f337-865c-6ae1c2e99241@oracle.com> Message-ID: <7783a75b6d4b187e066e2b0838abf46366015f6a.camel@oracle.com> Hi, On Tue, 2019-01-29 at 13:12 -0500, coleen.phillimore at oracle.com wrote: > > > On 1/29/19 4:51 AM, Thomas Schatzl wrote: > > Hi, > > > > On Mon, 2019-01-28 at 16:46 -0500, coleen.phillimore at oracle.com > > wrote: > > > Hi Thomas, Can you forward the review thread for JDK-8213229? > > > > the thread starts at > > http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2019-January/024474.html > > , but the interesting part is probably starting here > > http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2019-January/024649.html > > . > > So this moves StringTable processing into the WeakProcessor. good! > Not a review though. > > http://cr.openjdk.java.net/~tschatzl/8217778/webrev/src/hotspot/share/gc/shared/weakProcessor.inline.hpp.frames.html > > If these Counting closures are only used in the weakProcessor.cpp > file, they should be defined there. It looks like their use was > moved. They are also used in the inline.hpp file. > > http://cr.openjdk.java.net/~tschatzl/8217778/webrev/src/hotspot/share/gc/shared/weakProcessor.cpp.frames.html > > I don't know what "is_serial does but it doesn't look like you're > using the num_dead() count when calling processor. > > 40 if (WeakProcessorPhases::is_serial(phase)) { > 41 CountingIsAliveClosure cl(is_alive); > 42 WeakProcessorPhases::processor(phase)(&cl, keep_alive); > 43 } else { > 44 CountingSkippedIsAliveClosure OopClosure> cl(is_alive, keep_alive); > 45 WeakProcessorPhases::oop_storage(phase)->oops_do(&cl); > 46 if (WeakProcessorPhases::is_stringtable(phase)) { > 47 StringTable::inc_dead_counter(cl.num_dead() + > cl.num_skipped()); > 48 } > 49 } I cleaned this up already, Kim had the same comment. Only need to send out another webrev for 8217778. Thanks, Thomas From coleen.phillimore at oracle.com Tue Jan 29 19:38:17 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 29 Jan 2019 14:38:17 -0500 Subject: RFR (M) 8213753: Move timing of ProtectionDomainTable and ResolvedMethodTable cleanup to service thread In-Reply-To: <61fe9787-4a8e-c346-cdb6-760a73c2114b@oracle.com> References: <61fe9787-4a8e-c346-cdb6-760a73c2114b@oracle.com> Message-ID: <5634dda9-dff1-e835-f89d-1c123cb2f913@oracle.com> I've renamed this bug.? Please review on new thread. thanks, Coleen On 1/28/19 5:09 PM, coleen.phillimore at oracle.com wrote: > Summary: remove gc timing for short runtime cleanup triggering; make > symbol table cleaning triggered automatically on unloading > > Ran runThese with all Oracle GCs and got similar numbers of symbols > unloaded.? Also ran tier1-5. > > open webrev at http://cr.openjdk.java.net/~coleenp/2019/8213753.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8213753 > > Thanks, > Coleen From daniel.daugherty at oracle.com Tue Jan 29 21:26:53 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 29 Jan 2019 16:26:53 -0500 Subject: RFR(S/M): 8217659 monitor_logging updates from Async Monitor Deflation project In-Reply-To: References: <98f74cf8-1634-c0ad-0bbc-7c2d8e31a467@oracle.com> <003a4d2e-f7c1-cc57-6ab8-6a207ce64896@oracle.com> <39addd9a-532d-0bab-31fb-bdce5d67f426@oracle.com> <4383a85b-cf89-3f06-0f46-ba4e4159434e@oracle.com> Message-ID: I've snipped this reply down to just the part about refactoring... On 1/28/19 5:22 PM, Daniel D. Daugherty wrote: > On 1/28/19 5:15 PM, coleen.phillimore at oracle.com wrote: >>> >>>> My eyes are terrible, but it looks like this is >>>> ObjectMonitor::verify_free() >>> >>>> + if (n->is_busy()) { >>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global >>>> monitor " >>>> + "must not be busy.", p2i(n)); >>>> + *error_cnt_p = *error_cnt_p + 1; >>>> + } >>>> + if (n->header() != NULL) { >>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global >>>> monitor " >>>> + "must have NULL _header field: _header=" INTPTR_FORMAT, >>>> + p2i(n), p2i(n->header())); >>>> + *error_cnt_p = *error_cnt_p + 1; >>>> + } >>>> + if (n->object() != NULL) { >>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global >>>> monitor " >>>> + "must have NULL _object field: _object=" INTPTR_FORMAT, >>>> + p2i(n), p2i(n->object())); >>>> + *error_cnt_p = *error_cnt_p + 1; >>>> + } ... I have refactored the common code for "verify free" into: +// Check a free monitor entry; log any errors. +void ObjectSynchronizer::ck_free_entry(JavaThread * jt, ObjectMonitor * n, +?????????????????????????????????????? outputStream * out, int *error_cnt_p) { And here's what one of the checks looks like. I tried to put it all into a single out->print_cr() call with conditional inclusion of format strings and parameters, but the compiler really hated it. So I went with: +? if (n->is_busy()) { +??? if (jt != NULL) { +????? out->print_cr("ERROR: jt=" INTPTR_FORMAT ", monitor=" INTPTR_FORMAT +??????????????????? ": free per-thread monitor must not be busy.", p2i(jt), +??????????????????? p2i(n)); +??? } else { +????? out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global monitor " +??????????????????? "must not be busy.", p2i(n)); +??? } +??? *error_cnt_p = *error_cnt_p + 1; +? } >>>> And this is ObjectMonitor::verify_in_use() >>>> >>>> + if (n->header() == NULL) { >>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": in-use global >>>> monitor " >>>> + "must have non-NULL _header field.", p2i(n)); >>>> + *error_cnt_p = *error_cnt_p + 1; >>>> + } >>>> + if (n->object() == NULL) { >>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": in-use global >>>> monitor " >>>> + "must have non-NULL _object field.", p2i(n)); >>>> + *error_cnt_p = *error_cnt_p + 1; >>>> + } ... I have refactored the common code for "verify in use" into: +// Check an in-use monitor entry; log any errors. +void ObjectSynchronizer::ck_in_use_entry(JavaThread * jt, ObjectMonitor * n, +???????????????????????????????????????? outputStream * out, int *error_cnt_p) { And here's what one of the checks looks like: +? if (n->header() == NULL) { +??? if (jt != NULL) { +????? out->print_cr("ERROR: jt=" INTPTR_FORMAT ", monitor=" INTPTR_FORMAT +??????????????????? ": in-use per-thread monitor must have non-NULL _header " +??????????????????? "field.", p2i(jt), p2i(n)); +??? } else { +????? out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": in-use global monitor " +??????????????????? "must have non-NULL _header field.", p2i(n)); +??? } +??? *error_cnt_p = *error_cnt_p + 1; +? } Hopefully this is the last refactor for this bug fix... :-) Here's an incremental webrev: http://cr.openjdk.java.net/~dcubed/8217659-webrev/2-for-jdk13.inc/ Here's a full webrev: http://cr.openjdk.java.net/~dcubed/8217659-webrev/2-for-jdk13.full/ Another Mach5 builds-tier1,hs-tier1,jdk-tier1,hs-tier2,hs-tier3 test run is in process... Thanks, in advance, for any questions, comments or suggestions. Dan > The details are in the bug report: > > ??? JDK-8217659 monitor_logging updates from Async Monitor Deflation > project > https://bugs.openjdk.java.net/browse/JDK-8217659 From coleen.phillimore at oracle.com Tue Jan 29 22:27:50 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 29 Jan 2019 17:27:50 -0500 Subject: RFR(S/M): 8217659 monitor_logging updates from Async Monitor Deflation project In-Reply-To: References: <98f74cf8-1634-c0ad-0bbc-7c2d8e31a467@oracle.com> <003a4d2e-f7c1-cc57-6ab8-6a207ce64896@oracle.com> <39addd9a-532d-0bab-31fb-bdce5d67f426@oracle.com> <4383a85b-cf89-3f06-0f46-ba4e4159434e@oracle.com> Message-ID: <5e1d2efe-c7bb-27ff-491b-96414a10141c@oracle.com> This looks good!? Thank you for doing the refactoring! Coleen On 1/29/19 4:26 PM, Daniel D. Daugherty wrote: > I've snipped this reply down to just the part about refactoring... > > > On 1/28/19 5:22 PM, Daniel D. Daugherty wrote: >> On 1/28/19 5:15 PM, coleen.phillimore at oracle.com wrote: >>>> >>>>> My eyes are terrible, but it looks like this is >>>>> ObjectMonitor::verify_free() >>>> >>>>> + if (n->is_busy()) { >>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global >>>>> monitor " >>>>> + "must not be busy.", p2i(n)); >>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>> + } >>>>> + if (n->header() != NULL) { >>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global >>>>> monitor " >>>>> + "must have NULL _header field: _header=" INTPTR_FORMAT, >>>>> + p2i(n), p2i(n->header())); >>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>> + } >>>>> + if (n->object() != NULL) { >>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global >>>>> monitor " >>>>> + "must have NULL _object field: _object=" INTPTR_FORMAT, >>>>> + p2i(n), p2i(n->object())); >>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>> + } ... > > I have refactored the common code for "verify free" into: > > +// Check a free monitor entry; log any errors. > +void ObjectSynchronizer::ck_free_entry(JavaThread * jt, ObjectMonitor > * n, > +?????????????????????????????????????? outputStream * out, int > *error_cnt_p) { > > And here's what one of the checks looks like. I tried to put it all into > a single out->print_cr() call with conditional inclusion of format > strings > and parameters, but the compiler really hated it. So I went with: > > +? if (n->is_busy()) { > +??? if (jt != NULL) { > +????? out->print_cr("ERROR: jt=" INTPTR_FORMAT ", monitor=" > INTPTR_FORMAT > +??????????????????? ": free per-thread monitor must not be busy.", > p2i(jt), > +??????????????????? p2i(n)); > +??? } else { > +????? out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global > monitor " > +??????????????????? "must not be busy.", p2i(n)); > +??? } > +??? *error_cnt_p = *error_cnt_p + 1; > +? } > > > >>>>> And this is ObjectMonitor::verify_in_use() >>>>> >>>>> + if (n->header() == NULL) { >>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": in-use global >>>>> monitor " >>>>> + "must have non-NULL _header field.", p2i(n)); >>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>> + } >>>>> + if (n->object() == NULL) { >>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": in-use global >>>>> monitor " >>>>> + "must have non-NULL _object field.", p2i(n)); >>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>> + } ... > > I have refactored the common code for "verify in use" into: > > +// Check an in-use monitor entry; log any errors. > +void ObjectSynchronizer::ck_in_use_entry(JavaThread * jt, > ObjectMonitor * n, > +???????????????????????????????????????? outputStream * out, int > *error_cnt_p) { > > And here's what one of the checks looks like: > > +? if (n->header() == NULL) { > +??? if (jt != NULL) { > +????? out->print_cr("ERROR: jt=" INTPTR_FORMAT ", monitor=" > INTPTR_FORMAT > +??????????????????? ": in-use per-thread monitor must have non-NULL > _header " > +??????????????????? "field.", p2i(jt), p2i(n)); > +??? } else { > +????? out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": in-use global > monitor " > +??????????????????? "must have non-NULL _header field.", p2i(n)); > +??? } > +??? *error_cnt_p = *error_cnt_p + 1; > +? } > > Hopefully this is the last refactor for this bug fix... :-) > > > Here's an incremental webrev: > > http://cr.openjdk.java.net/~dcubed/8217659-webrev/2-for-jdk13.inc/ > > Here's a full webrev: > > http://cr.openjdk.java.net/~dcubed/8217659-webrev/2-for-jdk13.full/ > > Another Mach5 builds-tier1,hs-tier1,jdk-tier1,hs-tier2,hs-tier3 test > run is in process... > > Thanks, in advance, for any questions, comments or suggestions. > > Dan > >> The details are in the bug report: >> >> ??? JDK-8217659 monitor_logging updates from Async Monitor Deflation >> project >> https://bugs.openjdk.java.net/browse/JDK-8217659 > From daniel.daugherty at oracle.com Tue Jan 29 22:33:36 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 29 Jan 2019 17:33:36 -0500 Subject: RFR(S/M): 8217659 monitor_logging updates from Async Monitor Deflation project In-Reply-To: <5e1d2efe-c7bb-27ff-491b-96414a10141c@oracle.com> References: <98f74cf8-1634-c0ad-0bbc-7c2d8e31a467@oracle.com> <003a4d2e-f7c1-cc57-6ab8-6a207ce64896@oracle.com> <39addd9a-532d-0bab-31fb-bdce5d67f426@oracle.com> <4383a85b-cf89-3f06-0f46-ba4e4159434e@oracle.com> <5e1d2efe-c7bb-27ff-491b-96414a10141c@oracle.com> Message-ID: <959a2bee-6f5f-8175-6c16-08418eb053e9@oracle.com> Thanks for the quick re-review! Will be waiting for David H and Robbin to chime in on this re-review... Mach5 testing is still in running... no failures so far... 333 passes so far so 62 jobs to go... Dan On 1/29/19 5:27 PM, coleen.phillimore at oracle.com wrote: > > This looks good!? Thank you for doing the refactoring! > Coleen > > On 1/29/19 4:26 PM, Daniel D. Daugherty wrote: >> I've snipped this reply down to just the part about refactoring... >> >> >> On 1/28/19 5:22 PM, Daniel D. Daugherty wrote: >>> On 1/28/19 5:15 PM, coleen.phillimore at oracle.com wrote: >>>>> >>>>>> My eyes are terrible, but it looks like this is >>>>>> ObjectMonitor::verify_free() >>>>> >>>>>> + if (n->is_busy()) { >>>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global >>>>>> monitor " >>>>>> + "must not be busy.", p2i(n)); >>>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>>> + } >>>>>> + if (n->header() != NULL) { >>>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global >>>>>> monitor " >>>>>> + "must have NULL _header field: _header=" INTPTR_FORMAT, >>>>>> + p2i(n), p2i(n->header())); >>>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>>> + } >>>>>> + if (n->object() != NULL) { >>>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global >>>>>> monitor " >>>>>> + "must have NULL _object field: _object=" INTPTR_FORMAT, >>>>>> + p2i(n), p2i(n->object())); >>>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>>> + } ... >> >> I have refactored the common code for "verify free" into: >> >> +// Check a free monitor entry; log any errors. >> +void ObjectSynchronizer::ck_free_entry(JavaThread * jt, >> ObjectMonitor * n, >> +?????????????????????????????????????? outputStream * out, int >> *error_cnt_p) { >> >> And here's what one of the checks looks like. I tried to put it all into >> a single out->print_cr() call with conditional inclusion of format >> strings >> and parameters, but the compiler really hated it. So I went with: >> >> +? if (n->is_busy()) { >> +??? if (jt != NULL) { >> +????? out->print_cr("ERROR: jt=" INTPTR_FORMAT ", monitor=" >> INTPTR_FORMAT >> +??????????????????? ": free per-thread monitor must not be busy.", >> p2i(jt), >> +??????????????????? p2i(n)); >> +??? } else { >> +????? out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global >> monitor " >> +??????????????????? "must not be busy.", p2i(n)); >> +??? } >> +??? *error_cnt_p = *error_cnt_p + 1; >> +? } >> >> >> >>>>>> And this is ObjectMonitor::verify_in_use() >>>>>> >>>>>> + if (n->header() == NULL) { >>>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": in-use global >>>>>> monitor " >>>>>> + "must have non-NULL _header field.", p2i(n)); >>>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>>> + } >>>>>> + if (n->object() == NULL) { >>>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": in-use global >>>>>> monitor " >>>>>> + "must have non-NULL _object field.", p2i(n)); >>>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>>> + } ... >> >> I have refactored the common code for "verify in use" into: >> >> +// Check an in-use monitor entry; log any errors. >> +void ObjectSynchronizer::ck_in_use_entry(JavaThread * jt, >> ObjectMonitor * n, >> +???????????????????????????????????????? outputStream * out, int >> *error_cnt_p) { >> >> And here's what one of the checks looks like: >> >> +? if (n->header() == NULL) { >> +??? if (jt != NULL) { >> +????? out->print_cr("ERROR: jt=" INTPTR_FORMAT ", monitor=" >> INTPTR_FORMAT >> +??????????????????? ": in-use per-thread monitor must have non-NULL >> _header " >> +??????????????????? "field.", p2i(jt), p2i(n)); >> +??? } else { >> +????? out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": in-use global >> monitor " >> +??????????????????? "must have non-NULL _header field.", p2i(n)); >> +??? } >> +??? *error_cnt_p = *error_cnt_p + 1; >> +? } >> >> Hopefully this is the last refactor for this bug fix... :-) >> >> >> Here's an incremental webrev: >> >> http://cr.openjdk.java.net/~dcubed/8217659-webrev/2-for-jdk13.inc/ >> >> Here's a full webrev: >> >> http://cr.openjdk.java.net/~dcubed/8217659-webrev/2-for-jdk13.full/ >> >> Another Mach5 builds-tier1,hs-tier1,jdk-tier1,hs-tier2,hs-tier3 test >> run is in process... >> >> Thanks, in advance, for any questions, comments or suggestions. >> >> Dan >> >>> The details are in the bug report: >>> >>> ??? JDK-8217659 monitor_logging updates from Async Monitor Deflation >>> project >>> https://bugs.openjdk.java.net/browse/JDK-8217659 >> > From david.holmes at oracle.com Wed Jan 30 03:07:40 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 30 Jan 2019 13:07:40 +1000 Subject: RFR(S/M): 8217659 monitor_logging updates from Async Monitor Deflation project In-Reply-To: References: <98f74cf8-1634-c0ad-0bbc-7c2d8e31a467@oracle.com> <003a4d2e-f7c1-cc57-6ab8-6a207ce64896@oracle.com> <39addd9a-532d-0bab-31fb-bdce5d67f426@oracle.com> <4383a85b-cf89-3f06-0f46-ba4e4159434e@oracle.com> Message-ID: <4eeabfbf-1f7e-fe98-3837-0c19b456341a@oracle.com> Hi Dan, First a couple of nits: 1. I don't like the ck_* naming as an abbreviation for "check". chk would be better, or even check. 2. We don't need comments like this: 1430 // Use log_is_enabled() to avoid ResourceMark creation and 1431 // external_name() use if possible. else we'd be using them in 90% of logging blocks. There is one erroneous pattern here. You can't do this: 1654 if ((deflated_count != 0 && log_is_enabled(Info, monitorinflation)) || 1655 log_is_enabled(Debug, monitorinflation)) { 1656 log_info(monitorinflation)("deflating global idle monitors, %3.7f secs, %d monitors", timer.seconds(), deflated_count); 1657 } While Info normally implies Debug, they can be controlled independently, further you may be writing Info output and Debug output to different streams. So you can't just use log_info when it should really be log_debug. Probably the way to handle this without duplication is to again use LogStreams (or outputstreams): LogStream* ls; if (log_is_enabled(Debug, monitorinflation)) ls = else if (log_is_enabled(Info, monitorinflation)) ls = if (ls != null) ls.print(...); Using a LogStream can also avoid duplicate is_enabled checks in places like ObjectSynchronizer::finish_deflate_idle_monitors. Thanks, David ----- On 30/01/2019 7:26 am, Daniel D. Daugherty wrote: > I've snipped this reply down to just the part about refactoring... > > > On 1/28/19 5:22 PM, Daniel D. Daugherty wrote: >> On 1/28/19 5:15 PM, coleen.phillimore at oracle.com wrote: >>>> >>>>> My eyes are terrible, but it looks like this is >>>>> ObjectMonitor::verify_free() >>>> >>>>> + if (n->is_busy()) { >>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global >>>>> monitor " >>>>> + "must not be busy.", p2i(n)); >>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>> + } >>>>> + if (n->header() != NULL) { >>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global >>>>> monitor " >>>>> + "must have NULL _header field: _header=" INTPTR_FORMAT, >>>>> + p2i(n), p2i(n->header())); >>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>> + } >>>>> + if (n->object() != NULL) { >>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global >>>>> monitor " >>>>> + "must have NULL _object field: _object=" INTPTR_FORMAT, >>>>> + p2i(n), p2i(n->object())); >>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>> + } ... > > I have refactored the common code for "verify free" into: > > +// Check a free monitor entry; log any errors. > +void ObjectSynchronizer::ck_free_entry(JavaThread * jt, ObjectMonitor * n, > +?????????????????????????????????????? outputStream * out, int > *error_cnt_p) { > > And here's what one of the checks looks like. I tried to put it all into > a single out->print_cr() call with conditional inclusion of format strings > and parameters, but the compiler really hated it. So I went with: > > +? if (n->is_busy()) { > +??? if (jt != NULL) { > +????? out->print_cr("ERROR: jt=" INTPTR_FORMAT ", monitor=" INTPTR_FORMAT > +??????????????????? ": free per-thread monitor must not be busy.", > p2i(jt), > +??????????????????? p2i(n)); > +??? } else { > +????? out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global > monitor " > +??????????????????? "must not be busy.", p2i(n)); > +??? } > +??? *error_cnt_p = *error_cnt_p + 1; > +? } > > > >>>>> And this is ObjectMonitor::verify_in_use() >>>>> >>>>> + if (n->header() == NULL) { >>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": in-use global >>>>> monitor " >>>>> + "must have non-NULL _header field.", p2i(n)); >>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>> + } >>>>> + if (n->object() == NULL) { >>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": in-use global >>>>> monitor " >>>>> + "must have non-NULL _object field.", p2i(n)); >>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>> + } ... > > I have refactored the common code for "verify in use" into: > > +// Check an in-use monitor entry; log any errors. > +void ObjectSynchronizer::ck_in_use_entry(JavaThread * jt, ObjectMonitor > * n, > +???????????????????????????????????????? outputStream * out, int > *error_cnt_p) { > > And here's what one of the checks looks like: > > +? if (n->header() == NULL) { > +??? if (jt != NULL) { > +????? out->print_cr("ERROR: jt=" INTPTR_FORMAT ", monitor=" INTPTR_FORMAT > +??????????????????? ": in-use per-thread monitor must have non-NULL > _header " > +??????????????????? "field.", p2i(jt), p2i(n)); > +??? } else { > +????? out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": in-use global > monitor " > +??????????????????? "must have non-NULL _header field.", p2i(n)); > +??? } > +??? *error_cnt_p = *error_cnt_p + 1; > +? } > > Hopefully this is the last refactor for this bug fix... :-) > > > Here's an incremental webrev: > > http://cr.openjdk.java.net/~dcubed/8217659-webrev/2-for-jdk13.inc/ > > Here's a full webrev: > > http://cr.openjdk.java.net/~dcubed/8217659-webrev/2-for-jdk13.full/ > > Another Mach5 builds-tier1,hs-tier1,jdk-tier1,hs-tier2,hs-tier3 test > run is in process... > > Thanks, in advance, for any questions, comments or suggestions. > > Dan > >> The details are in the bug report: >> >> ??? JDK-8217659 monitor_logging updates from Async Monitor Deflation >> project >> https://bugs.openjdk.java.net/browse/JDK-8217659 > From ioi.lam at oracle.com Wed Jan 30 03:51:54 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Tue, 29 Jan 2019 19:51:54 -0800 Subject: RFR(XS) 8218029 [TESTBUG] Use -Djava.class.path= to specify empty -cp in CDS tests Message-ID: <5c7f9b93-bd8a-86f5-7d3c-23981bc8b4bc@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8218029 http://cr.openjdk.java.net/~iklam/jdk13/8218029-testbug-empty-classpath.v01/ Please review this simple fix. For portability, ???? "-cp", "\"\"", in the JVM command-line is replaced with ???? "-Djava.class.path=" Thanks! Ioi From david.holmes at oracle.com Wed Jan 30 04:35:27 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 30 Jan 2019 14:35:27 +1000 Subject: RFR(XS) 8218029 [TESTBUG] Use -Djava.class.path= to specify empty -cp in CDS tests In-Reply-To: <5c7f9b93-bd8a-86f5-7d3c-23981bc8b4bc@oracle.com> References: <5c7f9b93-bd8a-86f5-7d3c-23981bc8b4bc@oracle.com> Message-ID: <4c22671b-04bd-9976-65d8-7e0a4843e901@oracle.com> Hi Ioi, On 30/01/2019 1:51 pm, Ioi Lam wrote: > https://bugs.openjdk.java.net/browse/JDK-8218029 > http://cr.openjdk.java.net/~iklam/jdk13/8218029-testbug-empty-classpath.v01/ > > > Please review this simple fix. For portability, > > ???? "-cp", "\"\"", > > in the JVM command-line is replaced with > > ???? "-Djava.class.path=" Not sure I see how this works. ProcessTools will add: -cp but you are setting java.class.path to be empty so to me that means ProcessTools will set -cp which is an error? Or does it somehow become -cp "" ?? And does that mean the actual command-line ends up with: -cp "" -Djava.library.path= ? Thanks, David > > Thanks! > > Ioi > From ioi.lam at oracle.com Wed Jan 30 05:55:58 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Tue, 29 Jan 2019 21:55:58 -0800 Subject: RFR(XS) 8218029 [TESTBUG] Use -Djava.class.path= to specify empty -cp in CDS tests In-Reply-To: <4c22671b-04bd-9976-65d8-7e0a4843e901@oracle.com> References: <5c7f9b93-bd8a-86f5-7d3c-23981bc8b4bc@oracle.com> <4c22671b-04bd-9976-65d8-7e0a4843e901@oracle.com> Message-ID: <630ff22a-aa34-6b74-cc2e-534f557a27bc@oracle.com> On 1/29/19 8:35 PM, David Holmes wrote: > Hi Ioi, > > On 30/01/2019 1:51 pm, Ioi Lam wrote: >> https://bugs.openjdk.java.net/browse/JDK-8218029 >> http://cr.openjdk.java.net/~iklam/jdk13/8218029-testbug-empty-classpath.v01/ >> >> >> Please review this simple fix. For portability, >> >> ????? "-cp", "\"\"", >> >> in the JVM command-line is replaced with >> >> ????? "-Djava.class.path=" > > Not sure I see how this works. ProcessTools will add: > > -cp > > but you are setting java.class.path to be empty so to me that means > ProcessTools will set > > -cp > > which is an error? Or does it somehow become > > -cp "" > > ?? > > And does that mean the actual command-line ends up with: > > -cp "" -Djava.library.path= > > ? Each CDS test typically consists of 2 processes. The "main" test would run in the parent process. It will call ProcessTools.createJavaProcessBuilder to launch a child process. ??? public static ProcessBuilder createJavaProcessBuilder(...., String... command) { ??????? .. ??????? args.add("-cp"); ??????? args.add(System.getProperty("java.class.path")); ??????? .. ??????? Collections.addAll(args, command); Here, the java.class.path property is from the parent process, so it won't be empty. For the tests I touched, the child process's command-line will end up looking like this ?????? java -cp? -Djava.library.path= Foo and the -Djava.library.path= argument overrides the earlier -cp argument. Does this answer your question? ======== BTW, ProcessTools.createJavaProcessBuilder actually is buggy. If the parent process's java.class.path is indeed empty, on Windows, the child process will get ?????? java -cp Hello I.e., Windows throws away the empty argument. I could fix it as String cp = System.getProperty("java.class.path"); if (cp != null) { ??? args.add("-cp"); ??? args.add(cp); } else { ??? args.add("-Djava.library.path="); } What do you think? Thanks - Ioi > > Thanks, > David > >> >> Thanks! >> >> Ioi >> From david.holmes at oracle.com Wed Jan 30 06:15:13 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 30 Jan 2019 16:15:13 +1000 Subject: RFR(XS) 8218029 [TESTBUG] Use -Djava.class.path= to specify empty -cp in CDS tests In-Reply-To: <630ff22a-aa34-6b74-cc2e-534f557a27bc@oracle.com> References: <5c7f9b93-bd8a-86f5-7d3c-23981bc8b4bc@oracle.com> <4c22671b-04bd-9976-65d8-7e0a4843e901@oracle.com> <630ff22a-aa34-6b74-cc2e-534f557a27bc@oracle.com> Message-ID: <17e824aa-4040-3427-8790-62ccc7541f7b@oracle.com> On 30/01/2019 3:55 pm, Ioi Lam wrote: > > On 1/29/19 8:35 PM, David Holmes wrote: >> Hi Ioi, >> >> On 30/01/2019 1:51 pm, Ioi Lam wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8218029 >>> http://cr.openjdk.java.net/~iklam/jdk13/8218029-testbug-empty-classpath.v01/ >>> >>> >>> Please review this simple fix. For portability, >>> >>> ????? "-cp", "\"\"", >>> >>> in the JVM command-line is replaced with >>> >>> ????? "-Djava.class.path=" >> >> Not sure I see how this works. ProcessTools will add: >> >> -cp >> >> but you are setting java.class.path to be empty so to me that means >> ProcessTools will set >> >> -cp >> >> which is an error? Or does it somehow become >> >> -cp "" >> >> ?? >> >> And does that mean the actual command-line ends up with: >> >> -cp "" -Djava.library.path= >> >> ? > > > Each CDS test typically consists of 2 processes. The "main" test would > run in the parent process. It will call > ProcessTools.createJavaProcessBuilder to launch a child process. > > ??? public static ProcessBuilder createJavaProcessBuilder(...., > String... command) { > ??????? .. > ??????? args.add("-cp"); > ??????? args.add(System.getProperty("java.class.path")); > ??????? .. > ??????? Collections.addAll(args, command); > > Here, the java.class.path property is from the parent process, so it > won't be empty. Ah! Yes of course. > For the tests I touched, the child process's command-line will end up > looking like this > > ?????? java -cp? -Djava.library.path= Foo > > and the -Djava.library.path= argument overrides the earlier -cp argument. s/library/class/ :) > Does this answer your question? Yes - thanks. I can't help but think this is working around a problem that should be more readily solvable, but I don't have time to delve into ProcessTools. > ======== > > BTW, ProcessTools.createJavaProcessBuilder actually is buggy. If the > parent process's java.class.path is indeed empty, on Windows, the child > process will get > > ?????? java -cp Hello > > I.e., Windows throws away the empty argument. I could fix it as > > String cp = System.getProperty("java.class.path"); > if (cp != null) { > ??? args.add("-cp"); > ??? args.add(cp); > } else { > ??? args.add("-Djava.library.path="); > } > > What do you think? I think it sounds like ProcessTools both needs a fix for that and could better handle the "forwarding" of the classpath. Though on the other hand do these tests really need to use createJavaProcessBuilder (which presumably allows you to pass through runtime args from jtreg etc) and just launch the VM under test in a more direct and simple way? David ----- > Thanks > > - Ioi > > > >> >> Thanks, >> David >> >>> >>> Thanks! >>> >>> Ioi >>> From ioi.lam at oracle.com Wed Jan 30 08:19:28 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 30 Jan 2019 00:19:28 -0800 Subject: RFR(XS) 8218029 [TESTBUG] Use -Djava.class.path= to specify empty -cp in CDS tests In-Reply-To: <17e824aa-4040-3427-8790-62ccc7541f7b@oracle.com> References: <5c7f9b93-bd8a-86f5-7d3c-23981bc8b4bc@oracle.com> <4c22671b-04bd-9976-65d8-7e0a4843e901@oracle.com> <630ff22a-aa34-6b74-cc2e-534f557a27bc@oracle.com> <17e824aa-4040-3427-8790-62ccc7541f7b@oracle.com> Message-ID: <617e2e40-913e-c7ae-d730-6e92316711d6@oracle.com> On 1/29/19 10:15 PM, David Holmes wrote: > On 30/01/2019 3:55 pm, Ioi Lam wrote: >> >> On 1/29/19 8:35 PM, David Holmes wrote: >>> Hi Ioi, >>> >>> On 30/01/2019 1:51 pm, Ioi Lam wrote: >>>> https://bugs.openjdk.java.net/browse/JDK-8218029 >>>> http://cr.openjdk.java.net/~iklam/jdk13/8218029-testbug-empty-classpath.v01/ >>>> >>>> >>>> Please review this simple fix. For portability, >>>> >>>> ????? "-cp", "\"\"", >>>> >>>> in the JVM command-line is replaced with >>>> >>>> ????? "-Djava.class.path=" >>> >>> Not sure I see how this works. ProcessTools will add: >>> >>> -cp >>> >>> but you are setting java.class.path to be empty so to me that means >>> ProcessTools will set >>> >>> -cp >>> >>> which is an error? Or does it somehow become >>> >>> -cp "" >>> >>> ?? >>> >>> And does that mean the actual command-line ends up with: >>> >>> -cp "" -Djava.library.path= >>> >>> ? >> >> >> Each CDS test typically consists of 2 processes. The "main" test >> would run in the parent process. It will call >> ProcessTools.createJavaProcessBuilder to launch a child process. >> >> ???? public static ProcessBuilder createJavaProcessBuilder(...., >> String... command) { >> ???????? .. >> ???????? args.add("-cp"); >> ???????? args.add(System.getProperty("java.class.path")); >> ???????? .. >> ???????? Collections.addAll(args, command); >> >> Here, the java.class.path property is from the parent process, so it >> won't be empty. > > Ah! Yes of course. > >> For the tests I touched, the child process's command-line will end up >> looking like this >> >> ??????? java -cp? -Djava.library.path= Foo >> >> and the -Djava.library.path= argument overrides the earlier -cp >> argument. > > s/library/class/ :) > >> Does this answer your question? > > Yes - thanks. I can't help but think this is working around a problem > that should be more readily solvable, but I don't have time to delve > into ProcessTools. > >> ======== >> >> BTW, ProcessTools.createJavaProcessBuilder actually is buggy. If the >> parent process's java.class.path is indeed empty, on Windows, the >> child process will get >> >> ??????? java -cp Hello >> >> I.e., Windows throws away the empty argument. I could fix it as >> >> String cp = System.getProperty("java.class.path"); >> if (cp != null) { >> ???? args.add("-cp"); >> ???? args.add(cp); >> } else { >> ???? args.add("-Djava.library.path="); >> } >> >> What do you think? > > I think it sounds like ProcessTools both needs a fix for that and > could better handle the "forwarding" of the classpath. Though on the > other hand do these tests really need to use createJavaProcessBuilder > (which presumably allows you to pass through runtime args from jtreg > etc) and just launch the VM under test in a more direct and simple way? We need to pass the jtreg -vmoptions to the child processes (e.g., -Xcomp, GC flags, etc). > > David > ----- > >> Thanks >> >> - Ioi >> >> >> >>> >>> Thanks, >>> David >>> >>>> >>>> Thanks! >>>> >>>> Ioi >>>> From thomas.schatzl at oracle.com Wed Jan 30 09:57:05 2019 From: thomas.schatzl at oracle.com (Thomas Schatzl) Date: Wed, 30 Jan 2019 10:57:05 +0100 Subject: RFR (M): 8217778: StringTable cleanup miscalculates amount of dead objects In-Reply-To: <28211400-CBAA-485C-8852-6FCBBCBC4D09@oracle.com> References: <2140b41eb336ec5260b68eefd010c670a0b7a4ca.camel@oracle.com> <7a944a8567e8768986f3c72a030b0538cc71ebd9.camel@oracle.com> <28211400-CBAA-485C-8852-6FCBBCBC4D09@oracle.com> Message-ID: <3c8788099fdda94a32e91153a44ace8e8f29f2c6.camel@oracle.com> Hi Kim and Coleen, On Mon, 2019-01-28 at 22:24 -0500, Kim Barrett wrote: > On Mon, 2019-01-28 at 12:43 +0100, Thomas Schatzl wrote: > > Hi all, > > > > can I have reviews for this change that tries to fix the issue > > with the string table reporting too low "dead" numbers to the > > ServiceThread notification mechanism in the review for JDK-8213229, > > potentially causing C heap memory being kept live for longer than > > necessary? > > > > This change implements one option for fixing this, in particular > > that the WeakProcessor calls OopStorage::oops_do() instead of > > ::weak_oops_do, counting the number of NULL entries manually. > > I think this is the right approach to take. > Good. > > CR: > > https://bugs.openjdk.java.net/browse/JDK-8217778 > > Webrev: > > http://cr.openjdk.java.net/~tschatzl/8217778/webrev/ > > Testing: > > hs-tier1-5 > > > > Thanks, > > Thomas > > Looks good. > > A couple minor cleanup suggestions. I don't need another webrev if > you decide to do these. > > ------------------------------------------------------------------- > ----------- > src/hotspot/share/gc/shared/weakProcessor.cpp > 41 CountingIsAliveClosure cl(is_alive); > > Why are we counting here? We don't do anything with the resulting > count. (I missed this when reviewing JDK-8213229.) Fixed. > > Similarly here, when !is_stringtable(phase): > 44 CountingSkippedIsAliveClosure OopClosure> cl(is_alive, keep_alive); > > There could instead be a separate is_stringtable(phase) clause which > had the calls to StringTable::(reset|finish)_dead_counter() and the > counting closure stuff all close together and associated only with > the stringtable storage iteration. Done. > > ------------------------------------------------------------------- > ----------- > src/hotspot/share/gc/shared/weakProcessor.inline.hpp > 74 if (obj == NULL) { > 75 _num_skipped++; > 76 return; > 77 } > 78 if (_counting_is_alive.do_object_b(obj)) { > 79 _keep_alive->do_oop(p); > 80 } else { > 81 *p = NULL; > 82 } > > This would be simpler if the line 76 "return" were removed and the > line 78 "if" were an "else if", having a single if-ladder. Done. > > ------------------------------------------------------------------- > ----------- (from the other email) > ------------------------------------------------------------------- > ----------- > src/hotspot/share/gc/shared/weakProcessor.cpp > 44 CountingSkippedIsAliveClosure OopClosure> cl(is_alive, keep_alive); > > A different approach is possible in this serial case. We could wrap > the keep_alive closure for counting, as the number we want to pass to > inc_dead_counter is also available here as > > storage->allocation_count() - > > ------------------------------------------------------------------- > I did not implement that. It seems to look too different from the parallel case with no difference in actual work done. And we need the CountingSkipped.. closure anyway for the parallel case. New webrevs: http://cr.openjdk.java.net/~tschatzl/8217778/webrev.0_to_1 (diff) http://cr.openjdk.java.net/~tschatzl/8217778/webrev.1 (full) Thanks, Thomas From daniel.daugherty at oracle.com Wed Jan 30 16:07:41 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 30 Jan 2019 11:07:41 -0500 Subject: RFR(S/M): 8217659 monitor_logging updates from Async Monitor Deflation project In-Reply-To: <4eeabfbf-1f7e-fe98-3837-0c19b456341a@oracle.com> References: <98f74cf8-1634-c0ad-0bbc-7c2d8e31a467@oracle.com> <003a4d2e-f7c1-cc57-6ab8-6a207ce64896@oracle.com> <39addd9a-532d-0bab-31fb-bdce5d67f426@oracle.com> <4383a85b-cf89-3f06-0f46-ba4e4159434e@oracle.com> <4eeabfbf-1f7e-fe98-3837-0c19b456341a@oracle.com> Message-ID: On 1/29/19 10:07 PM, David Holmes wrote: > Hi Dan, Hi David! And thanks for the re-review. > First a couple of nits: > > 1. I don't like the ck_* naming as an abbreviation for "check". chk > would be better, or even check. I'll change 'ck_' -> 'chk_'. > 2. We don't need comments like this: > > 1430???????? // Use log_is_enabled() to avoid ResourceMark creation and > 1431???????? // external_name() use if possible. > > else we'd be using them in 90% of logging blocks. I added that comment in two places in response to a comment from Coleen to remove the 'log_is_enabled()' call. Since you're saying that my comment is 'common knowledge' then I'll remove both of them. > There is one erroneous pattern here. You can't do this: > > 1654?? if ((deflated_count != 0 && log_is_enabled(Info, > monitorinflation)) || > 1655?????? log_is_enabled(Debug, monitorinflation)) { > 1656???? log_info(monitorinflation)("deflating global idle monitors, > %3.7f secs, %d monitors", timer.seconds(), deflated_count); > 1657?? } > > While Info normally implies Debug, they can be controlled > independently, further you may be writing Info output and Debug output > to different streams. So you can't just use log_info when it should > really be log_debug. Thanks for catching this one. Obviously I still have more to learn about logging... > Probably the way to handle this without duplication is to again use > LogStreams (or outputstreams): > > LogStream* ls; > if (log_is_enabled(Debug, monitorinflation)) > ? ls = > else if (log_is_enabled(Info, monitorinflation)) > ? ls = > if (ls != null) > ? ls.print(...); Thanks for the pattern. I'll take care of it. I think the bug is in at least two places. > Using a LogStream can also avoid duplicate is_enabled checks in places > like ObjectSynchronizer::finish_deflate_idle_monitors. I'll revisit finish_deflate_idle_monitors() also. Thanks again for the re-review. Dan > > Thanks, > David > ----- > > > On 30/01/2019 7:26 am, Daniel D. Daugherty wrote: >> I've snipped this reply down to just the part about refactoring... >> >> >> On 1/28/19 5:22 PM, Daniel D. Daugherty wrote: >>> On 1/28/19 5:15 PM, coleen.phillimore at oracle.com wrote: >>>>> >>>>>> My eyes are terrible, but it looks like this is >>>>>> ObjectMonitor::verify_free() >>>>> >>>>>> + if (n->is_busy()) { >>>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global >>>>>> monitor " >>>>>> + "must not be busy.", p2i(n)); >>>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>>> + } >>>>>> + if (n->header() != NULL) { >>>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global >>>>>> monitor " >>>>>> + "must have NULL _header field: _header=" INTPTR_FORMAT, >>>>>> + p2i(n), p2i(n->header())); >>>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>>> + } >>>>>> + if (n->object() != NULL) { >>>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global >>>>>> monitor " >>>>>> + "must have NULL _object field: _object=" INTPTR_FORMAT, >>>>>> + p2i(n), p2i(n->object())); >>>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>>> + } ... >> >> I have refactored the common code for "verify free" into: >> >> +// Check a free monitor entry; log any errors. >> +void ObjectSynchronizer::ck_free_entry(JavaThread * jt, >> ObjectMonitor * n, >> +?????????????????????????????????????? outputStream * out, int >> *error_cnt_p) { >> >> And here's what one of the checks looks like. I tried to put it all into >> a single out->print_cr() call with conditional inclusion of format >> strings >> and parameters, but the compiler really hated it. So I went with: >> >> +? if (n->is_busy()) { >> +??? if (jt != NULL) { >> +????? out->print_cr("ERROR: jt=" INTPTR_FORMAT ", monitor=" >> INTPTR_FORMAT >> +??????????????????? ": free per-thread monitor must not be busy.", >> p2i(jt), >> +??????????????????? p2i(n)); >> +??? } else { >> +????? out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global >> monitor " >> +??????????????????? "must not be busy.", p2i(n)); >> +??? } >> +??? *error_cnt_p = *error_cnt_p + 1; >> +? } >> >> >> >>>>>> And this is ObjectMonitor::verify_in_use() >>>>>> >>>>>> + if (n->header() == NULL) { >>>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": in-use global >>>>>> monitor " >>>>>> + "must have non-NULL _header field.", p2i(n)); >>>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>>> + } >>>>>> + if (n->object() == NULL) { >>>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": in-use global >>>>>> monitor " >>>>>> + "must have non-NULL _object field.", p2i(n)); >>>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>>> + } ... >> >> I have refactored the common code for "verify in use" into: >> >> +// Check an in-use monitor entry; log any errors. >> +void ObjectSynchronizer::ck_in_use_entry(JavaThread * jt, >> ObjectMonitor * n, >> +???????????????????????????????????????? outputStream * out, int >> *error_cnt_p) { >> >> And here's what one of the checks looks like: >> >> +? if (n->header() == NULL) { >> +??? if (jt != NULL) { >> +????? out->print_cr("ERROR: jt=" INTPTR_FORMAT ", monitor=" >> INTPTR_FORMAT >> +??????????????????? ": in-use per-thread monitor must have non-NULL >> _header " >> +??????????????????? "field.", p2i(jt), p2i(n)); >> +??? } else { >> +????? out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": in-use global >> monitor " >> +??????????????????? "must have non-NULL _header field.", p2i(n)); >> +??? } >> +??? *error_cnt_p = *error_cnt_p + 1; >> +? } >> >> Hopefully this is the last refactor for this bug fix... :-) >> >> >> Here's an incremental webrev: >> >> http://cr.openjdk.java.net/~dcubed/8217659-webrev/2-for-jdk13.inc/ >> >> Here's a full webrev: >> >> http://cr.openjdk.java.net/~dcubed/8217659-webrev/2-for-jdk13.full/ >> >> Another Mach5 builds-tier1,hs-tier1,jdk-tier1,hs-tier2,hs-tier3 test >> run is in process... >> >> Thanks, in advance, for any questions, comments or suggestions. >> >> Dan >> >>> The details are in the bug report: >>> >>> ??? JDK-8217659 monitor_logging updates from Async Monitor Deflation >>> project >>> https://bugs.openjdk.java.net/browse/JDK-8217659 >> From daniel.daugherty at oracle.com Wed Jan 30 19:23:59 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 30 Jan 2019 14:23:59 -0500 Subject: RFR(S/M): 8217659 monitor_logging updates from Async Monitor Deflation project In-Reply-To: References: <98f74cf8-1634-c0ad-0bbc-7c2d8e31a467@oracle.com> <003a4d2e-f7c1-cc57-6ab8-6a207ce64896@oracle.com> <39addd9a-532d-0bab-31fb-bdce5d67f426@oracle.com> <4383a85b-cf89-3f06-0f46-ba4e4159434e@oracle.com> <4eeabfbf-1f7e-fe98-3837-0c19b456341a@oracle.com> Message-ID: <8d0a0d25-ca0f-1b80-28a5-76d098c4fae9@oracle.com> Greetings, I've addressed David H's latest round of comments. Here's an incremental webrev: http://cr.openjdk.java.net/~dcubed/8217659-webrev/3-for-jdk13.inc/ Here's a full webrev: http://cr.openjdk.java.net/~dcubed/8217659-webrev/3-for-jdk13.full/ Another Mach5 builds-tier1,hs-tier1,jdk-tier1,hs-tier2,hs-tier3 test run is in process... I've manually verified that we get fewer log messages at the Info level (deflate count == 0 are skipped) and that get those deflate count == 0 mesgs at the Debug level. Thanks, in advance, for any questions, comments or suggestions. Dan On 1/30/19 11:07 AM, Daniel D. Daugherty wrote: > On 1/29/19 10:07 PM, David Holmes wrote: >> Hi Dan, > > Hi David! > > And thanks for the re-review. > > >> First a couple of nits: >> >> 1. I don't like the ck_* naming as an abbreviation for "check". chk >> would be better, or even check. > > I'll change 'ck_' -> 'chk_'. > > >> 2. We don't need comments like this: >> >> 1430???????? // Use log_is_enabled() to avoid ResourceMark creation and >> 1431???????? // external_name() use if possible. >> >> else we'd be using them in 90% of logging blocks. > > I added that comment in two places in response to a comment from Coleen > to remove the 'log_is_enabled()' call. Since you're saying that my > comment > is 'common knowledge' then I'll remove both of them. > > >> There is one erroneous pattern here. You can't do this: >> >> 1654?? if ((deflated_count != 0 && log_is_enabled(Info, >> monitorinflation)) || >> 1655?????? log_is_enabled(Debug, monitorinflation)) { >> 1656???? log_info(monitorinflation)("deflating global idle monitors, >> %3.7f secs, %d monitors", timer.seconds(), deflated_count); >> 1657?? } >> >> While Info normally implies Debug, they can be controlled >> independently, further you may be writing Info output and Debug >> output to different streams. So you can't just use log_info when it >> should really be log_debug. > > Thanks for catching this one. Obviously I still have more to learn > about logging... > > >> Probably the way to handle this without duplication is to again use >> LogStreams (or outputstreams): >> >> LogStream* ls; >> if (log_is_enabled(Debug, monitorinflation)) >> ? ls = >> else if (log_is_enabled(Info, monitorinflation)) >> ? ls = >> if (ls != null) >> ? ls.print(...); > > Thanks for the pattern. I'll take care of it. I think the bug is > in at least two places. > > >> Using a LogStream can also avoid duplicate is_enabled checks in >> places like ObjectSynchronizer::finish_deflate_idle_monitors. > > I'll revisit finish_deflate_idle_monitors() also. > > Thanks again for the re-review. > > Dan > > >> >> Thanks, >> David >> ----- >> >> >> On 30/01/2019 7:26 am, Daniel D. Daugherty wrote: >>> I've snipped this reply down to just the part about refactoring... >>> >>> >>> On 1/28/19 5:22 PM, Daniel D. Daugherty wrote: >>>> On 1/28/19 5:15 PM, coleen.phillimore at oracle.com wrote: >>>>>> >>>>>>> My eyes are terrible, but it looks like this is >>>>>>> ObjectMonitor::verify_free() >>>>>> >>>>>>> + if (n->is_busy()) { >>>>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global >>>>>>> monitor " >>>>>>> + "must not be busy.", p2i(n)); >>>>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>>>> + } >>>>>>> + if (n->header() != NULL) { >>>>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global >>>>>>> monitor " >>>>>>> + "must have NULL _header field: _header=" INTPTR_FORMAT, >>>>>>> + p2i(n), p2i(n->header())); >>>>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>>>> + } >>>>>>> + if (n->object() != NULL) { >>>>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global >>>>>>> monitor " >>>>>>> + "must have NULL _object field: _object=" INTPTR_FORMAT, >>>>>>> + p2i(n), p2i(n->object())); >>>>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>>>> + } ... >>> >>> I have refactored the common code for "verify free" into: >>> >>> +// Check a free monitor entry; log any errors. >>> +void ObjectSynchronizer::ck_free_entry(JavaThread * jt, >>> ObjectMonitor * n, >>> +?????????????????????????????????????? outputStream * out, int >>> *error_cnt_p) { >>> >>> And here's what one of the checks looks like. I tried to put it all >>> into >>> a single out->print_cr() call with conditional inclusion of format >>> strings >>> and parameters, but the compiler really hated it. So I went with: >>> >>> +? if (n->is_busy()) { >>> +??? if (jt != NULL) { >>> +????? out->print_cr("ERROR: jt=" INTPTR_FORMAT ", monitor=" >>> INTPTR_FORMAT >>> +??????????????????? ": free per-thread monitor must not be busy.", >>> p2i(jt), >>> +??????????????????? p2i(n)); >>> +??? } else { >>> +????? out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global >>> monitor " >>> +??????????????????? "must not be busy.", p2i(n)); >>> +??? } >>> +??? *error_cnt_p = *error_cnt_p + 1; >>> +? } >>> >>> >>> >>>>>>> And this is ObjectMonitor::verify_in_use() >>>>>>> >>>>>>> + if (n->header() == NULL) { >>>>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": in-use global >>>>>>> monitor " >>>>>>> + "must have non-NULL _header field.", p2i(n)); >>>>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>>>> + } >>>>>>> + if (n->object() == NULL) { >>>>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": in-use global >>>>>>> monitor " >>>>>>> + "must have non-NULL _object field.", p2i(n)); >>>>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>>>> + } ... >>> >>> I have refactored the common code for "verify in use" into: >>> >>> +// Check an in-use monitor entry; log any errors. >>> +void ObjectSynchronizer::ck_in_use_entry(JavaThread * jt, >>> ObjectMonitor * n, >>> +???????????????????????????????????????? outputStream * out, int >>> *error_cnt_p) { >>> >>> And here's what one of the checks looks like: >>> >>> +? if (n->header() == NULL) { >>> +??? if (jt != NULL) { >>> +????? out->print_cr("ERROR: jt=" INTPTR_FORMAT ", monitor=" >>> INTPTR_FORMAT >>> +??????????????????? ": in-use per-thread monitor must have non-NULL >>> _header " >>> +??????????????????? "field.", p2i(jt), p2i(n)); >>> +??? } else { >>> +????? out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": in-use >>> global monitor " >>> +??????????????????? "must have non-NULL _header field.", p2i(n)); >>> +??? } >>> +??? *error_cnt_p = *error_cnt_p + 1; >>> +? } >>> >>> Hopefully this is the last refactor for this bug fix... :-) >>> >>> >>> Here's an incremental webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8217659-webrev/2-for-jdk13.inc/ >>> >>> Here's a full webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8217659-webrev/2-for-jdk13.full/ >>> >>> Another Mach5 builds-tier1,hs-tier1,jdk-tier1,hs-tier2,hs-tier3 test >>> run is in process... >>> >>> Thanks, in advance, for any questions, comments or suggestions. >>> >>> Dan >>> >>>> The details are in the bug report: >>>> >>>> ??? JDK-8217659 monitor_logging updates from Async Monitor >>>> Deflation project >>>> https://bugs.openjdk.java.net/browse/JDK-8217659 >>> > > From daniel.daugherty at oracle.com Wed Jan 30 20:42:37 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 30 Jan 2019 15:42:37 -0500 Subject: RFR(S/M): 8217659 monitor_logging updates from Async Monitor Deflation project In-Reply-To: <8d0a0d25-ca0f-1b80-28a5-76d098c4fae9@oracle.com> References: <98f74cf8-1634-c0ad-0bbc-7c2d8e31a467@oracle.com> <003a4d2e-f7c1-cc57-6ab8-6a207ce64896@oracle.com> <39addd9a-532d-0bab-31fb-bdce5d67f426@oracle.com> <4383a85b-cf89-3f06-0f46-ba4e4159434e@oracle.com> <4eeabfbf-1f7e-fe98-3837-0c19b456341a@oracle.com> <8d0a0d25-ca0f-1b80-28a5-76d098c4fae9@oracle.com> Message-ID: <60514782-8efe-8a8f-9fa4-7a12680d900c@oracle.com> I forgot to include the latest sample logs. Please see the attached... (if interested) Dan On 1/30/19 2:23 PM, Daniel D. Daugherty wrote: > Greetings, > > I've addressed David H's latest round of comments. > > Here's an incremental webrev: > > http://cr.openjdk.java.net/~dcubed/8217659-webrev/3-for-jdk13.inc/ > > Here's a full webrev: > > http://cr.openjdk.java.net/~dcubed/8217659-webrev/3-for-jdk13.full/ > > Another Mach5 builds-tier1,hs-tier1,jdk-tier1,hs-tier2,hs-tier3 test > run is in process... I've manually verified that we get fewer log > messages at the Info level (deflate count == 0 are skipped) and that > get those deflate count == 0 mesgs at the Debug level. > > Thanks, in advance, for any questions, comments or suggestions. > > Dan > > > On 1/30/19 11:07 AM, Daniel D. Daugherty wrote: >> On 1/29/19 10:07 PM, David Holmes wrote: >>> Hi Dan, >> >> Hi David! >> >> And thanks for the re-review. >> >> >>> First a couple of nits: >>> >>> 1. I don't like the ck_* naming as an abbreviation for "check". chk >>> would be better, or even check. >> >> I'll change 'ck_' -> 'chk_'. >> >> >>> 2. We don't need comments like this: >>> >>> 1430???????? // Use log_is_enabled() to avoid ResourceMark creation and >>> 1431???????? // external_name() use if possible. >>> >>> else we'd be using them in 90% of logging blocks. >> >> I added that comment in two places in response to a comment from Coleen >> to remove the 'log_is_enabled()' call. Since you're saying that my >> comment >> is 'common knowledge' then I'll remove both of them. >> >> >>> There is one erroneous pattern here. You can't do this: >>> >>> 1654?? if ((deflated_count != 0 && log_is_enabled(Info, >>> monitorinflation)) || >>> 1655?????? log_is_enabled(Debug, monitorinflation)) { >>> 1656???? log_info(monitorinflation)("deflating global idle monitors, >>> %3.7f secs, %d monitors", timer.seconds(), deflated_count); >>> 1657?? } >>> >>> While Info normally implies Debug, they can be controlled >>> independently, further you may be writing Info output and Debug >>> output to different streams. So you can't just use log_info when it >>> should really be log_debug. >> >> Thanks for catching this one. Obviously I still have more to learn >> about logging... >> >> >>> Probably the way to handle this without duplication is to again use >>> LogStreams (or outputstreams): >>> >>> LogStream* ls; >>> if (log_is_enabled(Debug, monitorinflation)) >>> ? ls = >>> else if (log_is_enabled(Info, monitorinflation)) >>> ? ls = >>> if (ls != null) >>> ? ls.print(...); >> >> Thanks for the pattern. I'll take care of it. I think the bug is >> in at least two places. >> >> >>> Using a LogStream can also avoid duplicate is_enabled checks in >>> places like ObjectSynchronizer::finish_deflate_idle_monitors. >> >> I'll revisit finish_deflate_idle_monitors() also. >> >> Thanks again for the re-review. >> >> Dan >> >> >>> >>> Thanks, >>> David >>> ----- >>> >>> >>> On 30/01/2019 7:26 am, Daniel D. Daugherty wrote: >>>> I've snipped this reply down to just the part about refactoring... >>>> >>>> >>>> On 1/28/19 5:22 PM, Daniel D. Daugherty wrote: >>>>> On 1/28/19 5:15 PM, coleen.phillimore at oracle.com wrote: >>>>>>> >>>>>>>> My eyes are terrible, but it looks like this is >>>>>>>> ObjectMonitor::verify_free() >>>>>>> >>>>>>>> + if (n->is_busy()) { >>>>>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global >>>>>>>> monitor " >>>>>>>> + "must not be busy.", p2i(n)); >>>>>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>>>>> + } >>>>>>>> + if (n->header() != NULL) { >>>>>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global >>>>>>>> monitor " >>>>>>>> + "must have NULL _header field: _header=" INTPTR_FORMAT, >>>>>>>> + p2i(n), p2i(n->header())); >>>>>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>>>>> + } >>>>>>>> + if (n->object() != NULL) { >>>>>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global >>>>>>>> monitor " >>>>>>>> + "must have NULL _object field: _object=" INTPTR_FORMAT, >>>>>>>> + p2i(n), p2i(n->object())); >>>>>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>>>>> + } ... >>>> >>>> I have refactored the common code for "verify free" into: >>>> >>>> +// Check a free monitor entry; log any errors. >>>> +void ObjectSynchronizer::ck_free_entry(JavaThread * jt, >>>> ObjectMonitor * n, >>>> +?????????????????????????????????????? outputStream * out, int >>>> *error_cnt_p) { >>>> >>>> And here's what one of the checks looks like. I tried to put it all >>>> into >>>> a single out->print_cr() call with conditional inclusion of format >>>> strings >>>> and parameters, but the compiler really hated it. So I went with: >>>> >>>> +? if (n->is_busy()) { >>>> +??? if (jt != NULL) { >>>> +????? out->print_cr("ERROR: jt=" INTPTR_FORMAT ", monitor=" >>>> INTPTR_FORMAT >>>> +??????????????????? ": free per-thread monitor must not be busy.", >>>> p2i(jt), >>>> +??????????????????? p2i(n)); >>>> +??? } else { >>>> +????? out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global >>>> monitor " >>>> +??????????????????? "must not be busy.", p2i(n)); >>>> +??? } >>>> +??? *error_cnt_p = *error_cnt_p + 1; >>>> +? } >>>> >>>> >>>> >>>>>>>> And this is ObjectMonitor::verify_in_use() >>>>>>>> >>>>>>>> + if (n->header() == NULL) { >>>>>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": in-use >>>>>>>> global monitor " >>>>>>>> + "must have non-NULL _header field.", p2i(n)); >>>>>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>>>>> + } >>>>>>>> + if (n->object() == NULL) { >>>>>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": in-use >>>>>>>> global monitor " >>>>>>>> + "must have non-NULL _object field.", p2i(n)); >>>>>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>>>>> + } ... >>>> >>>> I have refactored the common code for "verify in use" into: >>>> >>>> +// Check an in-use monitor entry; log any errors. >>>> +void ObjectSynchronizer::ck_in_use_entry(JavaThread * jt, >>>> ObjectMonitor * n, >>>> +???????????????????????????????????????? outputStream * out, int >>>> *error_cnt_p) { >>>> >>>> And here's what one of the checks looks like: >>>> >>>> +? if (n->header() == NULL) { >>>> +??? if (jt != NULL) { >>>> +????? out->print_cr("ERROR: jt=" INTPTR_FORMAT ", monitor=" >>>> INTPTR_FORMAT >>>> +??????????????????? ": in-use per-thread monitor must have >>>> non-NULL _header " >>>> +??????????????????? "field.", p2i(jt), p2i(n)); >>>> +??? } else { >>>> +????? out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": in-use >>>> global monitor " >>>> +??????????????????? "must have non-NULL _header field.", p2i(n)); >>>> +??? } >>>> +??? *error_cnt_p = *error_cnt_p + 1; >>>> +? } >>>> >>>> Hopefully this is the last refactor for this bug fix... :-) >>>> >>>> >>>> Here's an incremental webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8217659-webrev/2-for-jdk13.inc/ >>>> >>>> Here's a full webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8217659-webrev/2-for-jdk13.full/ >>>> >>>> Another Mach5 builds-tier1,hs-tier1,jdk-tier1,hs-tier2,hs-tier3 test >>>> run is in process... >>>> >>>> Thanks, in advance, for any questions, comments or suggestions. >>>> >>>> Dan >>>> >>>>> The details are in the bug report: >>>>> >>>>> ??? JDK-8217659 monitor_logging updates from Async Monitor >>>>> Deflation project >>>>> https://bugs.openjdk.java.net/browse/JDK-8217659 >>>> >> >> > > -------------- next part -------------- [0.103s][info][monitorinflation] deflating per-thread idle monitors, 0.0000016 secs, 1 monitors Hello world! [0.137s][info][monitorinflation] Global Lists: InUse Free Total [0.137s][info][monitorinflation] ================== ========== ========== ========== [0.137s][info][monitorinflation] 0 64 127 [0.137s][info][monitorinflation] Per-Thread Lists: InUse Free Provision [0.137s][info][monitorinflation] ================== ========== ========== ========== [0.137s][info][monitorinflation] 0x00007ffe7085d000 0 0 32 [0.137s][info][monitorinflation] 0x00007ffe7080d000 1 30 49 [0.137s][info][monitorinflation] 0x00007ffe7106d000 0 0 32 [0.137s][info][monitorinflation] 0x00007ffe70862800 0 0 32 [0.137s][info][monitorinflation] 0x00007ffe70866000 0 0 32 [0.137s][info][monitorinflation] 0x00007ffe7000c000 0 0 32 [0.137s][info][monitorinflation] 0x00007ffe70870000 1 31 49 [0.137s][info][monitorinflation] Checking global lists: [0.137s][info][monitorinflation] gMonitorPopulation=127 equals chkMonitorPopulation=127 [0.137s][info][monitorinflation] gOmInUseCount=0 equals chkOmInUseCount=0 [0.137s][info][monitorinflation] gMonitorFreeCount=64 equals chkMonitorFreeCount=64 [0.137s][info][monitorinflation] Checking per-thread lists: [0.137s][info][monitorinflation] jt=0x00007ffe7085d000: omInUseCount=0 equals chkOmInUseCount=0 [0.137s][info][monitorinflation] jt=0x00007ffe7085d000: omFreeCount=0 equals chkOmFreeCount=0 [0.137s][info][monitorinflation] jt=0x00007ffe7080d000: omInUseCount=1 equals chkOmInUseCount=1 [0.137s][info][monitorinflation] jt=0x00007ffe7080d000: omFreeCount=30 equals chkOmFreeCount=30 [0.137s][info][monitorinflation] jt=0x00007ffe7106d000: omInUseCount=0 equals chkOmInUseCount=0 [0.137s][info][monitorinflation] jt=0x00007ffe7106d000: omFreeCount=0 equals chkOmFreeCount=0 [0.137s][info][monitorinflation] jt=0x00007ffe70862800: omInUseCount=0 equals chkOmInUseCount=0 [0.137s][info][monitorinflation] jt=0x00007ffe70862800: omFreeCount=0 equals chkOmFreeCount=0 [0.137s][info][monitorinflation] jt=0x00007ffe70866000: omInUseCount=0 equals chkOmInUseCount=0 [0.137s][info][monitorinflation] jt=0x00007ffe70866000: omFreeCount=0 equals chkOmFreeCount=0 [0.137s][info][monitorinflation] jt=0x00007ffe7000c000: omInUseCount=0 equals chkOmInUseCount=0 [0.137s][info][monitorinflation] jt=0x00007ffe7000c000: omFreeCount=0 equals chkOmFreeCount=0 [0.137s][info][monitorinflation] jt=0x00007ffe70870000: omInUseCount=1 equals chkOmInUseCount=1 [0.137s][info][monitorinflation] jt=0x00007ffe70870000: omFreeCount=31 equals chkOmFreeCount=31 [0.137s][info][monitorinflation] No errors found in monitor list checks. [0.137s][info][monitorinflation] In-use per-thread monitor info: [0.137s][info][monitorinflation] (B -> is_busy, H -> has hashcode, L -> lock status) [0.137s][info][monitorinflation] jt monitor BHL object object type [0.137s][info][monitorinflation] ================== ================== === ================== ================== [0.137s][info][monitorinflation] 0x00007ffe7080d000 0x00007ffe71061b80 100 0x000000070ff02790 java.lang.ref.ReferenceQueue$Lock [0.137s][info][monitorinflation] 0x00007ffe70870000 0x00007ffe71063b80 100 0x000000070ff90bc0 java.lang.ref.ReferenceQueue$Lock -------------- next part -------------- [0.113s][debug][monitorinflation] deflating global idle monitors, 0.0000001 secs, 0 monitors [0.113s][debug][monitorinflation] deflating per-thread idle monitors, 0.0000026 secs, 2 monitors [0.113s][debug][monitorinflation] Global Lists: InUse Free Total [0.113s][debug][monitorinflation] ================== ========== ========== ========== [0.113s][debug][monitorinflation] 0 65 127 [0.113s][debug][monitorinflation] Per-Thread Lists: InUse Free Provision [0.113s][debug][monitorinflation] ================== ========== ========== ========== [0.113s][debug][monitorinflation] 0x00007fe2b7804000 0 0 32 [0.113s][debug][monitorinflation] 0x00007fe2b780f800 0 31 49 [0.113s][debug][monitorinflation] 0x00007fe2b6800800 1 30 49 [0.113s][debug][monitorinflation] 0x00007fe2b7151000 0 0 32 [0.113s][debug][monitorinflation] 0x00007fe2b7154800 0 0 32 [0.113s][debug][monitorinflation] 0x00007fe2b7155800 0 0 32 [0.113s][debug][monitorinflation] 0x00007fe2b680b000 0 0 32 [0.113s][debug][monitorinflation] 0x00007fe2b6808800 0 0 32 [0.114s][debug][monitorinflation] Checking global lists: [0.114s][debug][monitorinflation] gMonitorPopulation=127 equals chkMonitorPopulation=127 [0.114s][debug][monitorinflation] gOmInUseCount=0 equals chkOmInUseCount=0 [0.114s][debug][monitorinflation] gMonitorFreeCount=65 equals chkMonitorFreeCount=65 [0.114s][debug][monitorinflation] Checking per-thread lists: [0.114s][debug][monitorinflation] jt=0x00007fe2b7804000: omInUseCount=0 equals chkOmInUseCount=0 [0.114s][debug][monitorinflation] jt=0x00007fe2b7804000: omFreeCount=0 equals chkOmFreeCount=0 [0.114s][debug][monitorinflation] jt=0x00007fe2b780f800: omInUseCount=0 equals chkOmInUseCount=0 [0.114s][debug][monitorinflation] jt=0x00007fe2b780f800: omFreeCount=31 equals chkOmFreeCount=31 [0.114s][debug][monitorinflation] jt=0x00007fe2b6800800: omInUseCount=1 equals chkOmInUseCount=1 [0.114s][debug][monitorinflation] jt=0x00007fe2b6800800: omFreeCount=30 equals chkOmFreeCount=30 [0.114s][debug][monitorinflation] jt=0x00007fe2b7151000: omInUseCount=0 equals chkOmInUseCount=0 [0.114s][debug][monitorinflation] jt=0x00007fe2b7151000: omFreeCount=0 equals chkOmFreeCount=0 [0.114s][debug][monitorinflation] jt=0x00007fe2b7154800: omInUseCount=0 equals chkOmInUseCount=0 [0.114s][debug][monitorinflation] jt=0x00007fe2b7154800: omFreeCount=0 equals chkOmFreeCount=0 [0.114s][debug][monitorinflation] jt=0x00007fe2b7155800: omInUseCount=0 equals chkOmInUseCount=0 [0.114s][debug][monitorinflation] jt=0x00007fe2b7155800: omFreeCount=0 equals chkOmFreeCount=0 [0.114s][debug][monitorinflation] jt=0x00007fe2b680b000: omInUseCount=0 equals chkOmInUseCount=0 [0.114s][debug][monitorinflation] jt=0x00007fe2b680b000: omFreeCount=0 equals chkOmFreeCount=0 [0.114s][debug][monitorinflation] jt=0x00007fe2b6808800: omInUseCount=0 equals chkOmInUseCount=0 [0.114s][debug][monitorinflation] jt=0x00007fe2b6808800: omFreeCount=0 equals chkOmFreeCount=0 [0.114s][debug][monitorinflation] No errors found in monitor list checks. [0.139s][debug][monitorinflation] deflating global idle monitors, 0.0000001 secs, 0 monitors [0.139s][debug][monitorinflation] deflating per-thread idle monitors, 0.0000013 secs, 0 monitors [0.139s][debug][monitorinflation] Global Lists: InUse Free Total [0.139s][debug][monitorinflation] ================== ========== ========== ========== [0.139s][debug][monitorinflation] 0 65 127 [0.139s][debug][monitorinflation] Per-Thread Lists: InUse Free Provision [0.139s][debug][monitorinflation] ================== ========== ========== ========== [0.139s][debug][monitorinflation] 0x00007fe2b7804000 0 0 32 [0.139s][debug][monitorinflation] 0x00007fe2b780f800 0 31 49 [0.139s][debug][monitorinflation] 0x00007fe2b6800800 1 30 49 [0.139s][debug][monitorinflation] 0x00007fe2b7151000 0 0 32 [0.139s][debug][monitorinflation] 0x00007fe2b7154800 0 0 32 [0.139s][debug][monitorinflation] 0x00007fe2b7155800 0 0 32 [0.139s][debug][monitorinflation] 0x00007fe2b680b000 0 0 32 [0.139s][debug][monitorinflation] 0x00007fe2b6808800 0 0 32 [0.139s][debug][monitorinflation] 0x00007fe2b782d800 0 0 32 [0.139s][debug][monitorinflation] Checking global lists: [0.139s][debug][monitorinflation] gMonitorPopulation=127 equals chkMonitorPopulation=127 [0.139s][debug][monitorinflation] gOmInUseCount=0 equals chkOmInUseCount=0 [0.139s][debug][monitorinflation] gMonitorFreeCount=65 equals chkMonitorFreeCount=65 [0.139s][debug][monitorinflation] Checking per-thread lists: [0.139s][debug][monitorinflation] jt=0x00007fe2b7804000: omInUseCount=0 equals chkOmInUseCount=0 [0.139s][debug][monitorinflation] jt=0x00007fe2b7804000: omFreeCount=0 equals chkOmFreeCount=0 [0.139s][debug][monitorinflation] jt=0x00007fe2b780f800: omInUseCount=0 equals chkOmInUseCount=0 [0.139s][debug][monitorinflation] jt=0x00007fe2b780f800: omFreeCount=31 equals chkOmFreeCount=31 [0.139s][debug][monitorinflation] jt=0x00007fe2b6800800: omInUseCount=1 equals chkOmInUseCount=1 [0.139s][debug][monitorinflation] jt=0x00007fe2b6800800: omFreeCount=30 equals chkOmFreeCount=30 [0.139s][debug][monitorinflation] jt=0x00007fe2b7151000: omInUseCount=0 equals chkOmInUseCount=0 [0.139s][debug][monitorinflation] jt=0x00007fe2b7151000: omFreeCount=0 equals chkOmFreeCount=0 [0.139s][debug][monitorinflation] jt=0x00007fe2b7154800: omInUseCount=0 equals chkOmInUseCount=0 [0.139s][debug][monitorinflation] jt=0x00007fe2b7154800: omFreeCount=0 equals chkOmFreeCount=0 [0.139s][debug][monitorinflation] jt=0x00007fe2b7155800: omInUseCount=0 equals chkOmInUseCount=0 [0.139s][debug][monitorinflation] jt=0x00007fe2b7155800: omFreeCount=0 equals chkOmFreeCount=0 [0.139s][debug][monitorinflation] jt=0x00007fe2b680b000: omInUseCount=0 equals chkOmInUseCount=0 [0.139s][debug][monitorinflation] jt=0x00007fe2b680b000: omFreeCount=0 equals chkOmFreeCount=0 [0.139s][debug][monitorinflation] jt=0x00007fe2b6808800: omInUseCount=0 equals chkOmInUseCount=0 [0.139s][debug][monitorinflation] jt=0x00007fe2b6808800: omFreeCount=0 equals chkOmFreeCount=0 [0.139s][debug][monitorinflation] jt=0x00007fe2b782d800: omInUseCount=0 equals chkOmInUseCount=0 [0.139s][debug][monitorinflation] jt=0x00007fe2b782d800: omFreeCount=0 equals chkOmFreeCount=0 [0.139s][debug][monitorinflation] No errors found in monitor list checks. Hello world! [0.180s][debug][monitorinflation] deflating global idle monitors, 0.0000001 secs, 0 monitors [0.180s][debug][monitorinflation] deflating per-thread idle monitors, 0.0000013 secs, 0 monitors [0.180s][debug][monitorinflation] Global Lists: InUse Free Total [0.180s][debug][monitorinflation] ================== ========== ========== ========== [0.180s][debug][monitorinflation] 0 33 127 [0.180s][debug][monitorinflation] Per-Thread Lists: InUse Free Provision [0.180s][debug][monitorinflation] ================== ========== ========== ========== [0.180s][debug][monitorinflation] 0x00007fe2b780f800 0 31 49 [0.180s][debug][monitorinflation] 0x00007fe2b6800800 1 30 49 [0.180s][debug][monitorinflation] 0x00007fe2b7154800 0 0 32 [0.180s][debug][monitorinflation] 0x00007fe2b7155800 0 0 32 [0.180s][debug][monitorinflation] 0x00007fe2b680b000 0 0 32 [0.180s][debug][monitorinflation] 0x00007fe2b6808800 0 0 32 [0.180s][debug][monitorinflation] 0x00007fe2b782d800 1 31 49 [0.180s][debug][monitorinflation] Checking global lists: [0.180s][debug][monitorinflation] gMonitorPopulation=127 equals chkMonitorPopulation=127 [0.180s][debug][monitorinflation] gOmInUseCount=0 equals chkOmInUseCount=0 [0.180s][debug][monitorinflation] gMonitorFreeCount=33 equals chkMonitorFreeCount=33 [0.180s][debug][monitorinflation] Checking per-thread lists: [0.180s][debug][monitorinflation] jt=0x00007fe2b780f800: omInUseCount=0 equals chkOmInUseCount=0 [0.180s][debug][monitorinflation] jt=0x00007fe2b780f800: omFreeCount=31 equals chkOmFreeCount=31 [0.180s][debug][monitorinflation] jt=0x00007fe2b6800800: omInUseCount=1 equals chkOmInUseCount=1 [0.180s][debug][monitorinflation] jt=0x00007fe2b6800800: omFreeCount=30 equals chkOmFreeCount=30 [0.180s][debug][monitorinflation] jt=0x00007fe2b7154800: omInUseCount=0 equals chkOmInUseCount=0 [0.180s][debug][monitorinflation] jt=0x00007fe2b7154800: omFreeCount=0 equals chkOmFreeCount=0 [0.180s][debug][monitorinflation] jt=0x00007fe2b7155800: omInUseCount=0 equals chkOmInUseCount=0 [0.180s][debug][monitorinflation] jt=0x00007fe2b7155800: omFreeCount=0 equals chkOmFreeCount=0 [0.180s][debug][monitorinflation] jt=0x00007fe2b680b000: omInUseCount=0 equals chkOmInUseCount=0 [0.180s][debug][monitorinflation] jt=0x00007fe2b680b000: omFreeCount=0 equals chkOmFreeCount=0 [0.180s][debug][monitorinflation] jt=0x00007fe2b6808800: omInUseCount=0 equals chkOmInUseCount=0 [0.180s][debug][monitorinflation] jt=0x00007fe2b6808800: omFreeCount=0 equals chkOmFreeCount=0 [0.180s][debug][monitorinflation] jt=0x00007fe2b782d800: omInUseCount=1 equals chkOmInUseCount=1 [0.180s][debug][monitorinflation] jt=0x00007fe2b782d800: omFreeCount=31 equals chkOmFreeCount=31 [0.180s][debug][monitorinflation] No errors found in monitor list checks. [0.195s][debug][monitorinflation] Global Lists: InUse Free Total [0.195s][debug][monitorinflation] ================== ========== ========== ========== [0.195s][debug][monitorinflation] 0 33 127 [0.195s][debug][monitorinflation] Per-Thread Lists: InUse Free Provision [0.195s][debug][monitorinflation] ================== ========== ========== ========== [0.195s][debug][monitorinflation] 0x00007fe2b780f800 0 31 49 [0.195s][debug][monitorinflation] 0x00007fe2b6800800 1 30 49 [0.195s][debug][monitorinflation] 0x00007fe2b7154800 0 0 32 [0.195s][debug][monitorinflation] 0x00007fe2b7155800 0 0 32 [0.195s][debug][monitorinflation] 0x00007fe2b680b000 0 0 32 [0.195s][debug][monitorinflation] 0x00007fe2b6808800 0 0 32 [0.195s][debug][monitorinflation] 0x00007fe2b782d800 1 31 49 [0.195s][debug][monitorinflation] Checking global lists: [0.195s][debug][monitorinflation] gMonitorPopulation=127 equals chkMonitorPopulation=127 [0.195s][debug][monitorinflation] gOmInUseCount=0 equals chkOmInUseCount=0 [0.195s][debug][monitorinflation] gMonitorFreeCount=33 equals chkMonitorFreeCount=33 [0.195s][debug][monitorinflation] Checking per-thread lists: [0.195s][debug][monitorinflation] jt=0x00007fe2b780f800: omInUseCount=0 equals chkOmInUseCount=0 [0.195s][debug][monitorinflation] jt=0x00007fe2b780f800: omFreeCount=31 equals chkOmFreeCount=31 [0.195s][debug][monitorinflation] jt=0x00007fe2b6800800: omInUseCount=1 equals chkOmInUseCount=1 [0.195s][debug][monitorinflation] jt=0x00007fe2b6800800: omFreeCount=30 equals chkOmFreeCount=30 [0.195s][debug][monitorinflation] jt=0x00007fe2b7154800: omInUseCount=0 equals chkOmInUseCount=0 [0.195s][debug][monitorinflation] jt=0x00007fe2b7154800: omFreeCount=0 equals chkOmFreeCount=0 [0.195s][debug][monitorinflation] jt=0x00007fe2b7155800: omInUseCount=0 equals chkOmInUseCount=0 [0.195s][debug][monitorinflation] jt=0x00007fe2b7155800: omFreeCount=0 equals chkOmFreeCount=0 [0.195s][debug][monitorinflation] jt=0x00007fe2b680b000: omInUseCount=0 equals chkOmInUseCount=0 [0.195s][debug][monitorinflation] jt=0x00007fe2b680b000: omFreeCount=0 equals chkOmFreeCount=0 [0.195s][debug][monitorinflation] jt=0x00007fe2b6808800: omInUseCount=0 equals chkOmInUseCount=0 [0.195s][debug][monitorinflation] jt=0x00007fe2b6808800: omFreeCount=0 equals chkOmFreeCount=0 [0.195s][debug][monitorinflation] jt=0x00007fe2b782d800: omInUseCount=1 equals chkOmInUseCount=1 [0.195s][debug][monitorinflation] jt=0x00007fe2b782d800: omFreeCount=31 equals chkOmFreeCount=31 [0.195s][debug][monitorinflation] No errors found in monitor list checks. [0.195s][debug][monitorinflation] In-use per-thread monitor info: [0.195s][debug][monitorinflation] (B -> is_busy, H -> has hashcode, L -> lock status) [0.195s][debug][monitorinflation] jt monitor BHL object object type [0.195s][debug][monitorinflation] ================== ================== === ================== ================== [0.195s][debug][monitorinflation] 0x00007fe2b6800800 0x00007fe2b7816380 100 0x000000070ff02790 java.lang.ref.ReferenceQueue$Lock [0.195s][debug][monitorinflation] 0x00007fe2b782d800 0x00007fe2b7818280 100 0x000000070ff90b80 java.lang.ref.ReferenceQueue$Lock -------------- next part -------------- [0.052s][trace][monitorinflation] inflate(has_locker): object=0x000000070ff01ee0, mark=0x00007fe24184cc82, type='java.lang.Object' [0.061s][trace][monitorinflation] inflate(has_locker): object=0x000000070ff02790, mark=0x00007fe24184cb82, type='java.lang.ref.ReferenceQueue$Lock' [0.100s][trace][monitorinflation] deflate_monitor: object=0x000000070ff01ee0, mark=0x00007fe24184cc82, type='java.lang.Object' [0.100s][debug][monitorinflation] deflating global idle monitors, 0.0000001 secs, 0 monitors [0.100s][debug][monitorinflation] deflating per-thread idle monitors, 0.0000187 secs, 1 monitors [0.100s][trace][monitorinflation] Global Lists: InUse Free Total [0.100s][trace][monitorinflation] ================== ========== ========== ========== [0.100s][trace][monitorinflation] 0 96 127 [0.100s][trace][monitorinflation] Per-Thread Lists: InUse Free Provision [0.100s][trace][monitorinflation] ================== ========== ========== ========== [0.100s][trace][monitorinflation] 0x00007fe24101a000 0 0 32 [0.100s][trace][monitorinflation] 0x00007fe241116800 0 0 32 [0.100s][trace][monitorinflation] 0x00007fe24111a000 1 30 49 [0.100s][trace][monitorinflation] 0x00007fe242006000 0 0 32 [0.100s][trace][monitorinflation] 0x00007fe24111c800 0 0 32 [0.100s][trace][monitorinflation] 0x00007fe241858000 0 0 32 [0.100s][trace][monitorinflation] 0x00007fe24185b800 0 0 32 [0.100s][trace][monitorinflation] 0x00007fe24180f000 0 0 32 [0.100s][trace][monitorinflation] Checking global lists: [0.100s][trace][monitorinflation] gMonitorPopulation=127 equals chkMonitorPopulation=127 [0.100s][trace][monitorinflation] gOmInUseCount=0 equals chkOmInUseCount=0 [0.100s][trace][monitorinflation] gMonitorFreeCount=96 equals chkMonitorFreeCount=96 [0.100s][trace][monitorinflation] Checking per-thread lists: [0.100s][trace][monitorinflation] jt=0x00007fe24101a000: omInUseCount=0 equals chkOmInUseCount=0 [0.100s][trace][monitorinflation] jt=0x00007fe24101a000: omFreeCount=0 equals chkOmFreeCount=0 [0.100s][trace][monitorinflation] jt=0x00007fe241116800: omInUseCount=0 equals chkOmInUseCount=0 [0.100s][trace][monitorinflation] jt=0x00007fe241116800: omFreeCount=0 equals chkOmFreeCount=0 [0.100s][trace][monitorinflation] jt=0x00007fe24111a000: omInUseCount=1 equals chkOmInUseCount=1 [0.100s][trace][monitorinflation] jt=0x00007fe24111a000: omFreeCount=30 equals chkOmFreeCount=30 [0.100s][trace][monitorinflation] jt=0x00007fe242006000: omInUseCount=0 equals chkOmInUseCount=0 [0.100s][trace][monitorinflation] jt=0x00007fe242006000: omFreeCount=0 equals chkOmFreeCount=0 [0.100s][trace][monitorinflation] jt=0x00007fe24111c800: omInUseCount=0 equals chkOmInUseCount=0 [0.100s][trace][monitorinflation] jt=0x00007fe24111c800: omFreeCount=0 equals chkOmFreeCount=0 [0.100s][trace][monitorinflation] jt=0x00007fe241858000: omInUseCount=0 equals chkOmInUseCount=0 [0.100s][trace][monitorinflation] jt=0x00007fe241858000: omFreeCount=0 equals chkOmFreeCount=0 [0.100s][trace][monitorinflation] jt=0x00007fe24185b800: omInUseCount=0 equals chkOmInUseCount=0 [0.100s][trace][monitorinflation] jt=0x00007fe24185b800: omFreeCount=0 equals chkOmFreeCount=0 [0.100s][trace][monitorinflation] jt=0x00007fe24180f000: omInUseCount=0 equals chkOmInUseCount=0 [0.100s][trace][monitorinflation] jt=0x00007fe24180f000: omFreeCount=0 equals chkOmFreeCount=0 [0.100s][trace][monitorinflation] No errors found in monitor list checks. [0.100s][trace][monitorinflation] In-use per-thread monitor info: [0.100s][trace][monitorinflation] (B -> is_busy, H -> has hashcode, L -> lock status) [0.100s][trace][monitorinflation] jt monitor BHL object object type [0.100s][trace][monitorinflation] ================== ================== === ================== ================== [0.100s][trace][monitorinflation] 0x00007fe24111a000 0x00007fe24184cb80 100 0x000000070ff02790 java.lang.ref.ReferenceQueue$Lock [0.113s][debug][monitorinflation] deflating global idle monitors, 0.0000001 secs, 0 monitors [0.113s][debug][monitorinflation] deflating per-thread idle monitors, 0.0000015 secs, 0 monitors [0.113s][trace][monitorinflation] Global Lists: InUse Free Total [0.113s][trace][monitorinflation] ================== ========== ========== ========== [0.113s][trace][monitorinflation] 0 96 127 [0.113s][trace][monitorinflation] Per-Thread Lists: InUse Free Provision [0.113s][trace][monitorinflation] ================== ========== ========== ========== [0.113s][trace][monitorinflation] 0x00007fe24101a000 0 0 32 [0.113s][trace][monitorinflation] 0x00007fe241116800 0 0 32 [0.113s][trace][monitorinflation] 0x00007fe24111a000 1 30 49 [0.113s][trace][monitorinflation] 0x00007fe242006000 0 0 32 [0.113s][trace][monitorinflation] 0x00007fe24111c800 0 0 32 [0.113s][trace][monitorinflation] 0x00007fe241858000 0 0 32 [0.113s][trace][monitorinflation] 0x00007fe24185b800 0 0 32 [0.113s][trace][monitorinflation] 0x00007fe24180f000 0 0 32 [0.113s][trace][monitorinflation] 0x00007fe24112d000 0 0 32 [0.113s][trace][monitorinflation] Checking global lists: [0.113s][trace][monitorinflation] gMonitorPopulation=127 equals chkMonitorPopulation=127 [0.113s][trace][monitorinflation] gOmInUseCount=0 equals chkOmInUseCount=0 [0.113s][trace][monitorinflation] gMonitorFreeCount=96 equals chkMonitorFreeCount=96 [0.113s][trace][monitorinflation] Checking per-thread lists: [0.113s][trace][monitorinflation] jt=0x00007fe24101a000: omInUseCount=0 equals chkOmInUseCount=0 [0.113s][trace][monitorinflation] jt=0x00007fe24101a000: omFreeCount=0 equals chkOmFreeCount=0 [0.113s][trace][monitorinflation] jt=0x00007fe241116800: omInUseCount=0 equals chkOmInUseCount=0 [0.113s][trace][monitorinflation] jt=0x00007fe241116800: omFreeCount=0 equals chkOmFreeCount=0 [0.113s][trace][monitorinflation] jt=0x00007fe24111a000: omInUseCount=1 equals chkOmInUseCount=1 [0.113s][trace][monitorinflation] jt=0x00007fe24111a000: omFreeCount=30 equals chkOmFreeCount=30 [0.113s][trace][monitorinflation] jt=0x00007fe242006000: omInUseCount=0 equals chkOmInUseCount=0 [0.113s][trace][monitorinflation] jt=0x00007fe242006000: omFreeCount=0 equals chkOmFreeCount=0 [0.113s][trace][monitorinflation] jt=0x00007fe24111c800: omInUseCount=0 equals chkOmInUseCount=0 [0.113s][trace][monitorinflation] jt=0x00007fe24111c800: omFreeCount=0 equals chkOmFreeCount=0 [0.113s][trace][monitorinflation] jt=0x00007fe241858000: omInUseCount=0 equals chkOmInUseCount=0 [0.113s][trace][monitorinflation] jt=0x00007fe241858000: omFreeCount=0 equals chkOmFreeCount=0 [0.113s][trace][monitorinflation] jt=0x00007fe24185b800: omInUseCount=0 equals chkOmInUseCount=0 [0.113s][trace][monitorinflation] jt=0x00007fe24185b800: omFreeCount=0 equals chkOmFreeCount=0 [0.113s][trace][monitorinflation] jt=0x00007fe24180f000: omInUseCount=0 equals chkOmInUseCount=0 [0.113s][trace][monitorinflation] jt=0x00007fe24180f000: omFreeCount=0 equals chkOmFreeCount=0 [0.113s][trace][monitorinflation] jt=0x00007fe24112d000: omInUseCount=0 equals chkOmInUseCount=0 [0.113s][trace][monitorinflation] jt=0x00007fe24112d000: omFreeCount=0 equals chkOmFreeCount=0 [0.113s][trace][monitorinflation] No errors found in monitor list checks. [0.113s][trace][monitorinflation] In-use per-thread monitor info: [0.113s][trace][monitorinflation] (B -> is_busy, H -> has hashcode, L -> lock status) [0.113s][trace][monitorinflation] jt monitor BHL object object type [0.113s][trace][monitorinflation] ================== ================== === ================== ================== [0.113s][trace][monitorinflation] 0x00007fe24111a000 0x00007fe24184cb80 100 0x000000070ff02790 java.lang.ref.ReferenceQueue$Lock [0.113s][trace][monitorinflation] inflate(has_locker): object=0x000000070ff90b20, mark=0x00007fe24184eb82, type='java.lang.ref.ReferenceQueue$Lock' Hello world! [0.130s][debug][monitorinflation] deflating global idle monitors, 0.0000001 secs, 0 monitors [0.130s][debug][monitorinflation] deflating per-thread idle monitors, 0.0000018 secs, 0 monitors [0.130s][trace][monitorinflation] Global Lists: InUse Free Total [0.130s][trace][monitorinflation] ================== ========== ========== ========== [0.130s][trace][monitorinflation] 0 64 127 [0.130s][trace][monitorinflation] Per-Thread Lists: InUse Free Provision [0.130s][trace][monitorinflation] ================== ========== ========== ========== [0.130s][trace][monitorinflation] 0x00007fe241116800 0 0 32 [0.130s][trace][monitorinflation] 0x00007fe24111a000 1 30 49 [0.130s][trace][monitorinflation] 0x00007fe24111c800 0 0 32 [0.130s][trace][monitorinflation] 0x00007fe241858000 0 0 32 [0.130s][trace][monitorinflation] 0x00007fe24185b800 0 0 32 [0.130s][trace][monitorinflation] 0x00007fe24180f000 0 0 32 [0.130s][trace][monitorinflation] 0x00007fe24112d000 1 31 49 [0.130s][trace][monitorinflation] Checking global lists: [0.130s][trace][monitorinflation] gMonitorPopulation=127 equals chkMonitorPopulation=127 [0.130s][trace][monitorinflation] gOmInUseCount=0 equals chkOmInUseCount=0 [0.130s][trace][monitorinflation] gMonitorFreeCount=64 equals chkMonitorFreeCount=64 [0.130s][trace][monitorinflation] Checking per-thread lists: [0.130s][trace][monitorinflation] jt=0x00007fe241116800: omInUseCount=0 equals chkOmInUseCount=0 [0.130s][trace][monitorinflation] jt=0x00007fe241116800: omFreeCount=0 equals chkOmFreeCount=0 [0.130s][trace][monitorinflation] jt=0x00007fe24111a000: omInUseCount=1 equals chkOmInUseCount=1 [0.130s][trace][monitorinflation] jt=0x00007fe24111a000: omFreeCount=30 equals chkOmFreeCount=30 [0.130s][trace][monitorinflation] jt=0x00007fe24111c800: omInUseCount=0 equals chkOmInUseCount=0 [0.130s][trace][monitorinflation] jt=0x00007fe24111c800: omFreeCount=0 equals chkOmFreeCount=0 [0.130s][trace][monitorinflation] jt=0x00007fe241858000: omInUseCount=0 equals chkOmInUseCount=0 [0.130s][trace][monitorinflation] jt=0x00007fe241858000: omFreeCount=0 equals chkOmFreeCount=0 [0.130s][trace][monitorinflation] jt=0x00007fe24185b800: omInUseCount=0 equals chkOmInUseCount=0 [0.130s][trace][monitorinflation] jt=0x00007fe24185b800: omFreeCount=0 equals chkOmFreeCount=0 [0.130s][trace][monitorinflation] jt=0x00007fe24180f000: omInUseCount=0 equals chkOmInUseCount=0 [0.130s][trace][monitorinflation] jt=0x00007fe24180f000: omFreeCount=0 equals chkOmFreeCount=0 [0.130s][trace][monitorinflation] jt=0x00007fe24112d000: omInUseCount=1 equals chkOmInUseCount=1 [0.130s][trace][monitorinflation] jt=0x00007fe24112d000: omFreeCount=31 equals chkOmFreeCount=31 [0.130s][trace][monitorinflation] No errors found in monitor list checks. [0.130s][trace][monitorinflation] In-use per-thread monitor info: [0.130s][trace][monitorinflation] (B -> is_busy, H -> has hashcode, L -> lock status) [0.130s][trace][monitorinflation] jt monitor BHL object object type [0.130s][trace][monitorinflation] ================== ================== === ================== ================== [0.130s][trace][monitorinflation] 0x00007fe24111a000 0x00007fe24184cb80 100 0x000000070ff02790 java.lang.ref.ReferenceQueue$Lock [0.130s][trace][monitorinflation] 0x00007fe24112d000 0x00007fe24184eb80 100 0x000000070ff90b20 java.lang.ref.ReferenceQueue$Lock [0.145s][trace][monitorinflation] Global Lists: InUse Free Total [0.145s][trace][monitorinflation] ================== ========== ========== ========== [0.145s][trace][monitorinflation] 0 64 127 [0.145s][trace][monitorinflation] Per-Thread Lists: InUse Free Provision [0.145s][trace][monitorinflation] ================== ========== ========== ========== [0.145s][trace][monitorinflation] 0x00007fe241116800 0 0 32 [0.145s][trace][monitorinflation] 0x00007fe24111a000 1 30 49 [0.145s][trace][monitorinflation] 0x00007fe24111c800 0 0 32 [0.145s][trace][monitorinflation] 0x00007fe241858000 0 0 32 [0.145s][trace][monitorinflation] 0x00007fe24185b800 0 0 32 [0.145s][trace][monitorinflation] 0x00007fe24180f000 0 0 32 [0.145s][trace][monitorinflation] 0x00007fe24112d000 1 31 49 [0.145s][trace][monitorinflation] Checking global lists: [0.145s][trace][monitorinflation] gMonitorPopulation=127 equals chkMonitorPopulation=127 [0.145s][trace][monitorinflation] gOmInUseCount=0 equals chkOmInUseCount=0 [0.145s][trace][monitorinflation] gMonitorFreeCount=64 equals chkMonitorFreeCount=64 [0.145s][trace][monitorinflation] Checking per-thread lists: [0.145s][trace][monitorinflation] jt=0x00007fe241116800: omInUseCount=0 equals chkOmInUseCount=0 [0.145s][trace][monitorinflation] jt=0x00007fe241116800: omFreeCount=0 equals chkOmFreeCount=0 [0.145s][trace][monitorinflation] jt=0x00007fe24111a000: omInUseCount=1 equals chkOmInUseCount=1 [0.145s][trace][monitorinflation] jt=0x00007fe24111a000: omFreeCount=30 equals chkOmFreeCount=30 [0.145s][trace][monitorinflation] jt=0x00007fe24111c800: omInUseCount=0 equals chkOmInUseCount=0 [0.145s][trace][monitorinflation] jt=0x00007fe24111c800: omFreeCount=0 equals chkOmFreeCount=0 [0.145s][trace][monitorinflation] jt=0x00007fe241858000: omInUseCount=0 equals chkOmInUseCount=0 [0.145s][trace][monitorinflation] jt=0x00007fe241858000: omFreeCount=0 equals chkOmFreeCount=0 [0.145s][trace][monitorinflation] jt=0x00007fe24185b800: omInUseCount=0 equals chkOmInUseCount=0 [0.145s][trace][monitorinflation] jt=0x00007fe24185b800: omFreeCount=0 equals chkOmFreeCount=0 [0.145s][trace][monitorinflation] jt=0x00007fe24180f000: omInUseCount=0 equals chkOmInUseCount=0 [0.145s][trace][monitorinflation] jt=0x00007fe24180f000: omFreeCount=0 equals chkOmFreeCount=0 [0.145s][trace][monitorinflation] jt=0x00007fe24112d000: omInUseCount=1 equals chkOmInUseCount=1 [0.145s][trace][monitorinflation] jt=0x00007fe24112d000: omFreeCount=31 equals chkOmFreeCount=31 [0.145s][trace][monitorinflation] No errors found in monitor list checks. [0.145s][trace][monitorinflation] In-use per-thread monitor info: [0.145s][trace][monitorinflation] (B -> is_busy, H -> has hashcode, L -> lock status) [0.145s][trace][monitorinflation] jt monitor BHL object object type [0.145s][trace][monitorinflation] ================== ================== === ================== ================== [0.145s][trace][monitorinflation] 0x00007fe24111a000 0x00007fe24184cb80 100 0x000000070ff02790 java.lang.ref.ReferenceQueue$Lock [0.145s][trace][monitorinflation] 0x00007fe24112d000 0x00007fe24184eb80 100 0x000000070ff90b20 java.lang.ref.ReferenceQueue$Lock From gerard.ziemski at oracle.com Wed Jan 30 21:21:54 2019 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Wed, 30 Jan 2019 15:21:54 -0600 Subject: RFR (M) 8213753: Move timing of ProtectionDomainTable and ResolvedMethodTable cleanup to service thread In-Reply-To: <61fe9787-4a8e-c346-cdb6-760a73c2114b@oracle.com> References: <61fe9787-4a8e-c346-cdb6-760a73c2114b@oracle.com> Message-ID: <1F2CB561-B6FC-46B5-AEDC-B19ABE861D60@oracle.com> hi Coleen, Looks good and I?m glad to see "set_item_clean_count/mark_item_clean_count" stuff go away. #1 In src/hotspot/share/classfile/symbolTable.cpp we no longer need the comment, so should remove it: 472 if (clean_hint) { 473 // we just found out that there is a dead item, 474 // which we were unable to clean right now, 475 // but we have no way of telling whether it's 476 // been previously counted or not, so mark 477 // it only if no other items were found yet 478 mark_has_items_to_clean(); 479 check_concurrent_work(); 480 } and just have: 472 if (clean_hint) { 473 mark_has_items_to_clean(); 474 check_concurrent_work(); 475 } #2 For a followup, I think we can do some further simplifications: a) Combine "mark_has_items_to_clean() and check_concurrent_work()? into one b) Possibly eliminate the 3 new APIs: ?reset_has_items_to_clean/mark_has_items_to_clean/has_items_to_clean? But the main task of changing how we trigger the table cleanup looks fine. cheers > On Jan 28, 2019, at 4:09 PM, coleen.phillimore at oracle.com wrote: > > Summary: remove gc timing for short runtime cleanup triggering; make symbol table cleaning triggered automatically on unloading > > Ran runThese with all Oracle GCs and got similar numbers of symbols unloaded. Also ran tier1-5. > > open webrev at http://cr.openjdk.java.net/~coleenp/2019/8213753.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8213753 > > Thanks, > Coleen From coleen.phillimore at oracle.com Wed Jan 30 22:05:27 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 30 Jan 2019 17:05:27 -0500 Subject: RFR (M) 8213753: Move timing of ProtectionDomainTable and ResolvedMethodTable cleanup to service thread In-Reply-To: <1F2CB561-B6FC-46B5-AEDC-B19ABE861D60@oracle.com> References: <61fe9787-4a8e-c346-cdb6-760a73c2114b@oracle.com> <1F2CB561-B6FC-46B5-AEDC-B19ABE861D60@oracle.com> Message-ID: <2dae803d-fb90-de81-e4e1-30f3e04b5bea@oracle.com> Gerard, Thank you for reviewing this! On 1/30/19 4:21 PM, Gerard Ziemski wrote: > hi Coleen, > > Looks good and I?m glad to see "set_item_clean_count/mark_item_clean_count" stuff go away. > > #1 In src/hotspot/share/classfile/symbolTable.cpp we no longer need the comment, so should remove it: > > 472 if (clean_hint) { > 473 // we just found out that there is a dead item, > 474 // which we were unable to clean right now, > 475 // but we have no way of telling whether it's > 476 // been previously counted or not, so mark > 477 // it only if no other items were found yet > 478 mark_has_items_to_clean(); > 479 check_concurrent_work(); > 480 } > > and just have: > > 472 if (clean_hint) { > 473 mark_has_items_to_clean(); > 474 check_concurrent_work(); > 475 } Yes, that avoids confusion.? Fixed! > > #2 For a followup, I think we can do some further simplifications: > > a) Combine "mark_has_items_to_clean() and check_concurrent_work()? into one > b) Possibly eliminate the 3 new APIs: ?reset_has_items_to_clean/mark_has_items_to_clean/has_items_to_clean? > > But the main task of changing how we trigger the table cleanup looks fine. I agree.? I was thinking there are some more improvements that can be made.? If we find a dead item on insert, set the flag that there's something to clean but have the check_concurrent_work() check at some later interval and not immediately.? Maybe at safepoint cleanup. Thanks! Coleen > > cheers > > >> On Jan 28, 2019, at 4:09 PM, coleen.phillimore at oracle.com wrote: >> >> Summary: remove gc timing for short runtime cleanup triggering; make symbol table cleaning triggered automatically on unloading >> >> Ran runThese with all Oracle GCs and got similar numbers of symbols unloaded. Also ran tier1-5. >> >> open webrev at http://cr.openjdk.java.net/~coleenp/2019/8213753.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8213753 >> >> Thanks, >> Coleen From coleen.phillimore at oracle.com Wed Jan 30 22:09:21 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 30 Jan 2019 17:09:21 -0500 Subject: RFR (T) 8212949: Remove ConstantPoolCache::is_constantPoolCache Message-ID: <7040c1fd-421e-4ceb-882e-5dd0769f45e0@oracle.com> Summary: remove relic of permgen, also is_constMethod too. See bug for more details.? Tested with hs-tier1,2. open webrev at http://cr.openjdk.java.net/~coleenp/2019/8212949.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8212949 Thanks, Coleen From kim.barrett at oracle.com Wed Jan 30 22:16:41 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Wed, 30 Jan 2019 17:16:41 -0500 Subject: RFR (M): 8217778: StringTable cleanup miscalculates amount of dead objects In-Reply-To: <3c8788099fdda94a32e91153a44ace8e8f29f2c6.camel@oracle.com> References: <2140b41eb336ec5260b68eefd010c670a0b7a4ca.camel@oracle.com> <7a944a8567e8768986f3c72a030b0538cc71ebd9.camel@oracle.com> <28211400-CBAA-485C-8852-6FCBBCBC4D09@oracle.com> <3c8788099fdda94a32e91153a44ace8e8f29f2c6.camel@oracle.com> Message-ID: > On Jan 30, 2019, at 4:57 AM, Thomas Schatzl wrote: > New webrevs: > http://cr.openjdk.java.net/~tschatzl/8217778/webrev.0_to_1 (diff) > http://cr.openjdk.java.net/~tschatzl/8217778/webrev.1 (full) > > Thanks, > Thomas Looks good. From coleen.phillimore at oracle.com Wed Jan 30 22:20:29 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 30 Jan 2019 17:20:29 -0500 Subject: RFR(S/M): 8217659 monitor_logging updates from Async Monitor Deflation project In-Reply-To: <8d0a0d25-ca0f-1b80-28a5-76d098c4fae9@oracle.com> References: <98f74cf8-1634-c0ad-0bbc-7c2d8e31a467@oracle.com> <003a4d2e-f7c1-cc57-6ab8-6a207ce64896@oracle.com> <39addd9a-532d-0bab-31fb-bdce5d67f426@oracle.com> <4383a85b-cf89-3f06-0f46-ba4e4159434e@oracle.com> <4eeabfbf-1f7e-fe98-3837-0c19b456341a@oracle.com> <8d0a0d25-ca0f-1b80-28a5-76d098c4fae9@oracle.com> Message-ID: <3c610987-c67f-cae6-b1ad-0410c042d800@oracle.com> "inc" version looks good. Coleen On 1/30/19 2:23 PM, Daniel D. Daugherty wrote: > Greetings, > > I've addressed David H's latest round of comments. > > Here's an incremental webrev: > > http://cr.openjdk.java.net/~dcubed/8217659-webrev/3-for-jdk13.inc/ > > Here's a full webrev: > > http://cr.openjdk.java.net/~dcubed/8217659-webrev/3-for-jdk13.full/ > > Another Mach5 builds-tier1,hs-tier1,jdk-tier1,hs-tier2,hs-tier3 test > run is in process... I've manually verified that we get fewer log > messages at the Info level (deflate count == 0 are skipped) and that > get those deflate count == 0 mesgs at the Debug level. > > Thanks, in advance, for any questions, comments or suggestions. > > Dan > > > On 1/30/19 11:07 AM, Daniel D. Daugherty wrote: >> On 1/29/19 10:07 PM, David Holmes wrote: >>> Hi Dan, >> >> Hi David! >> >> And thanks for the re-review. >> >> >>> First a couple of nits: >>> >>> 1. I don't like the ck_* naming as an abbreviation for "check". chk >>> would be better, or even check. >> >> I'll change 'ck_' -> 'chk_'. >> >> >>> 2. We don't need comments like this: >>> >>> 1430???????? // Use log_is_enabled() to avoid ResourceMark creation and >>> 1431???????? // external_name() use if possible. >>> >>> else we'd be using them in 90% of logging blocks. >> >> I added that comment in two places in response to a comment from Coleen >> to remove the 'log_is_enabled()' call. Since you're saying that my >> comment >> is 'common knowledge' then I'll remove both of them. >> >> >>> There is one erroneous pattern here. You can't do this: >>> >>> 1654?? if ((deflated_count != 0 && log_is_enabled(Info, >>> monitorinflation)) || >>> 1655?????? log_is_enabled(Debug, monitorinflation)) { >>> 1656???? log_info(monitorinflation)("deflating global idle monitors, >>> %3.7f secs, %d monitors", timer.seconds(), deflated_count); >>> 1657?? } >>> >>> While Info normally implies Debug, they can be controlled >>> independently, further you may be writing Info output and Debug >>> output to different streams. So you can't just use log_info when it >>> should really be log_debug. >> >> Thanks for catching this one. Obviously I still have more to learn >> about logging... >> >> >>> Probably the way to handle this without duplication is to again use >>> LogStreams (or outputstreams): >>> >>> LogStream* ls; >>> if (log_is_enabled(Debug, monitorinflation)) >>> ? ls = >>> else if (log_is_enabled(Info, monitorinflation)) >>> ? ls = >>> if (ls != null) >>> ? ls.print(...); >> >> Thanks for the pattern. I'll take care of it. I think the bug is >> in at least two places. >> >> >>> Using a LogStream can also avoid duplicate is_enabled checks in >>> places like ObjectSynchronizer::finish_deflate_idle_monitors. >> >> I'll revisit finish_deflate_idle_monitors() also. >> >> Thanks again for the re-review. >> >> Dan >> >> >>> >>> Thanks, >>> David >>> ----- >>> >>> >>> On 30/01/2019 7:26 am, Daniel D. Daugherty wrote: >>>> I've snipped this reply down to just the part about refactoring... >>>> >>>> >>>> On 1/28/19 5:22 PM, Daniel D. Daugherty wrote: >>>>> On 1/28/19 5:15 PM, coleen.phillimore at oracle.com wrote: >>>>>>> >>>>>>>> My eyes are terrible, but it looks like this is >>>>>>>> ObjectMonitor::verify_free() >>>>>>> >>>>>>>> + if (n->is_busy()) { >>>>>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global >>>>>>>> monitor " >>>>>>>> + "must not be busy.", p2i(n)); >>>>>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>>>>> + } >>>>>>>> + if (n->header() != NULL) { >>>>>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global >>>>>>>> monitor " >>>>>>>> + "must have NULL _header field: _header=" INTPTR_FORMAT, >>>>>>>> + p2i(n), p2i(n->header())); >>>>>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>>>>> + } >>>>>>>> + if (n->object() != NULL) { >>>>>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global >>>>>>>> monitor " >>>>>>>> + "must have NULL _object field: _object=" INTPTR_FORMAT, >>>>>>>> + p2i(n), p2i(n->object())); >>>>>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>>>>> + } ... >>>> >>>> I have refactored the common code for "verify free" into: >>>> >>>> +// Check a free monitor entry; log any errors. >>>> +void ObjectSynchronizer::ck_free_entry(JavaThread * jt, >>>> ObjectMonitor * n, >>>> +?????????????????????????????????????? outputStream * out, int >>>> *error_cnt_p) { >>>> >>>> And here's what one of the checks looks like. I tried to put it all >>>> into >>>> a single out->print_cr() call with conditional inclusion of format >>>> strings >>>> and parameters, but the compiler really hated it. So I went with: >>>> >>>> +? if (n->is_busy()) { >>>> +??? if (jt != NULL) { >>>> +????? out->print_cr("ERROR: jt=" INTPTR_FORMAT ", monitor=" >>>> INTPTR_FORMAT >>>> +??????????????????? ": free per-thread monitor must not be busy.", >>>> p2i(jt), >>>> +??????????????????? p2i(n)); >>>> +??? } else { >>>> +????? out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global >>>> monitor " >>>> +??????????????????? "must not be busy.", p2i(n)); >>>> +??? } >>>> +??? *error_cnt_p = *error_cnt_p + 1; >>>> +? } >>>> >>>> >>>> >>>>>>>> And this is ObjectMonitor::verify_in_use() >>>>>>>> >>>>>>>> + if (n->header() == NULL) { >>>>>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": in-use >>>>>>>> global monitor " >>>>>>>> + "must have non-NULL _header field.", p2i(n)); >>>>>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>>>>> + } >>>>>>>> + if (n->object() == NULL) { >>>>>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": in-use >>>>>>>> global monitor " >>>>>>>> + "must have non-NULL _object field.", p2i(n)); >>>>>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>>>>> + } ... >>>> >>>> I have refactored the common code for "verify in use" into: >>>> >>>> +// Check an in-use monitor entry; log any errors. >>>> +void ObjectSynchronizer::ck_in_use_entry(JavaThread * jt, >>>> ObjectMonitor * n, >>>> +???????????????????????????????????????? outputStream * out, int >>>> *error_cnt_p) { >>>> >>>> And here's what one of the checks looks like: >>>> >>>> +? if (n->header() == NULL) { >>>> +??? if (jt != NULL) { >>>> +????? out->print_cr("ERROR: jt=" INTPTR_FORMAT ", monitor=" >>>> INTPTR_FORMAT >>>> +??????????????????? ": in-use per-thread monitor must have >>>> non-NULL _header " >>>> +??????????????????? "field.", p2i(jt), p2i(n)); >>>> +??? } else { >>>> +????? out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": in-use >>>> global monitor " >>>> +??????????????????? "must have non-NULL _header field.", p2i(n)); >>>> +??? } >>>> +??? *error_cnt_p = *error_cnt_p + 1; >>>> +? } >>>> >>>> Hopefully this is the last refactor for this bug fix... :-) >>>> >>>> >>>> Here's an incremental webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8217659-webrev/2-for-jdk13.inc/ >>>> >>>> Here's a full webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8217659-webrev/2-for-jdk13.full/ >>>> >>>> Another Mach5 builds-tier1,hs-tier1,jdk-tier1,hs-tier2,hs-tier3 test >>>> run is in process... >>>> >>>> Thanks, in advance, for any questions, comments or suggestions. >>>> >>>> Dan >>>> >>>>> The details are in the bug report: >>>>> >>>>> ??? JDK-8217659 monitor_logging updates from Async Monitor >>>>> Deflation project >>>>> https://bugs.openjdk.java.net/browse/JDK-8217659 >>>> >> >> > From daniel.daugherty at oracle.com Wed Jan 30 22:26:54 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 30 Jan 2019 17:26:54 -0500 Subject: RFR(S/M): 8217659 monitor_logging updates from Async Monitor Deflation project In-Reply-To: <3c610987-c67f-cae6-b1ad-0410c042d800@oracle.com> References: <98f74cf8-1634-c0ad-0bbc-7c2d8e31a467@oracle.com> <003a4d2e-f7c1-cc57-6ab8-6a207ce64896@oracle.com> <39addd9a-532d-0bab-31fb-bdce5d67f426@oracle.com> <4383a85b-cf89-3f06-0f46-ba4e4159434e@oracle.com> <4eeabfbf-1f7e-fe98-3837-0c19b456341a@oracle.com> <8d0a0d25-ca0f-1b80-28a5-76d098c4fae9@oracle.com> <3c610987-c67f-cae6-b1ad-0410c042d800@oracle.com> Message-ID: <77dca3bb-19a2-361e-8bc9-430921b7f843@oracle.com> Thank you for the (many) re-reviews! Dan On 1/30/19 5:20 PM, coleen.phillimore at oracle.com wrote: > > "inc" version looks good. > Coleen > > On 1/30/19 2:23 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> I've addressed David H's latest round of comments. >> >> Here's an incremental webrev: >> >> http://cr.openjdk.java.net/~dcubed/8217659-webrev/3-for-jdk13.inc/ >> >> Here's a full webrev: >> >> http://cr.openjdk.java.net/~dcubed/8217659-webrev/3-for-jdk13.full/ >> >> Another Mach5 builds-tier1,hs-tier1,jdk-tier1,hs-tier2,hs-tier3 test >> run is in process... I've manually verified that we get fewer log >> messages at the Info level (deflate count == 0 are skipped) and that >> get those deflate count == 0 mesgs at the Debug level. >> >> Thanks, in advance, for any questions, comments or suggestions. >> >> Dan >> >> >> On 1/30/19 11:07 AM, Daniel D. Daugherty wrote: >>> On 1/29/19 10:07 PM, David Holmes wrote: >>>> Hi Dan, >>> >>> Hi David! >>> >>> And thanks for the re-review. >>> >>> >>>> First a couple of nits: >>>> >>>> 1. I don't like the ck_* naming as an abbreviation for "check". chk >>>> would be better, or even check. >>> >>> I'll change 'ck_' -> 'chk_'. >>> >>> >>>> 2. We don't need comments like this: >>>> >>>> 1430???????? // Use log_is_enabled() to avoid ResourceMark creation >>>> and >>>> 1431???????? // external_name() use if possible. >>>> >>>> else we'd be using them in 90% of logging blocks. >>> >>> I added that comment in two places in response to a comment from Coleen >>> to remove the 'log_is_enabled()' call. Since you're saying that my >>> comment >>> is 'common knowledge' then I'll remove both of them. >>> >>> >>>> There is one erroneous pattern here. You can't do this: >>>> >>>> 1654?? if ((deflated_count != 0 && log_is_enabled(Info, >>>> monitorinflation)) || >>>> 1655?????? log_is_enabled(Debug, monitorinflation)) { >>>> 1656???? log_info(monitorinflation)("deflating global idle >>>> monitors, %3.7f secs, %d monitors", timer.seconds(), deflated_count); >>>> 1657?? } >>>> >>>> While Info normally implies Debug, they can be controlled >>>> independently, further you may be writing Info output and Debug >>>> output to different streams. So you can't just use log_info when it >>>> should really be log_debug. >>> >>> Thanks for catching this one. Obviously I still have more to learn >>> about logging... >>> >>> >>>> Probably the way to handle this without duplication is to again use >>>> LogStreams (or outputstreams): >>>> >>>> LogStream* ls; >>>> if (log_is_enabled(Debug, monitorinflation)) >>>> ? ls = >>>> else if (log_is_enabled(Info, monitorinflation)) >>>> ? ls = >>>> if (ls != null) >>>> ? ls.print(...); >>> >>> Thanks for the pattern. I'll take care of it. I think the bug is >>> in at least two places. >>> >>> >>>> Using a LogStream can also avoid duplicate is_enabled checks in >>>> places like ObjectSynchronizer::finish_deflate_idle_monitors. >>> >>> I'll revisit finish_deflate_idle_monitors() also. >>> >>> Thanks again for the re-review. >>> >>> Dan >>> >>> >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>> >>>> On 30/01/2019 7:26 am, Daniel D. Daugherty wrote: >>>>> I've snipped this reply down to just the part about refactoring... >>>>> >>>>> >>>>> On 1/28/19 5:22 PM, Daniel D. Daugherty wrote: >>>>>> On 1/28/19 5:15 PM, coleen.phillimore at oracle.com wrote: >>>>>>>> >>>>>>>>> My eyes are terrible, but it looks like this is >>>>>>>>> ObjectMonitor::verify_free() >>>>>>>> >>>>>>>>> + if (n->is_busy()) { >>>>>>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global >>>>>>>>> monitor " >>>>>>>>> + "must not be busy.", p2i(n)); >>>>>>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>>>>>> + } >>>>>>>>> + if (n->header() != NULL) { >>>>>>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global >>>>>>>>> monitor " >>>>>>>>> + "must have NULL _header field: _header=" INTPTR_FORMAT, >>>>>>>>> + p2i(n), p2i(n->header())); >>>>>>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>>>>>> + } >>>>>>>>> + if (n->object() != NULL) { >>>>>>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global >>>>>>>>> monitor " >>>>>>>>> + "must have NULL _object field: _object=" INTPTR_FORMAT, >>>>>>>>> + p2i(n), p2i(n->object())); >>>>>>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>>>>>> + } ... >>>>> >>>>> I have refactored the common code for "verify free" into: >>>>> >>>>> +// Check a free monitor entry; log any errors. >>>>> +void ObjectSynchronizer::ck_free_entry(JavaThread * jt, >>>>> ObjectMonitor * n, >>>>> +?????????????????????????????????????? outputStream * out, int >>>>> *error_cnt_p) { >>>>> >>>>> And here's what one of the checks looks like. I tried to put it >>>>> all into >>>>> a single out->print_cr() call with conditional inclusion of format >>>>> strings >>>>> and parameters, but the compiler really hated it. So I went with: >>>>> >>>>> +? if (n->is_busy()) { >>>>> +??? if (jt != NULL) { >>>>> +????? out->print_cr("ERROR: jt=" INTPTR_FORMAT ", monitor=" >>>>> INTPTR_FORMAT >>>>> +??????????????????? ": free per-thread monitor must not be >>>>> busy.", p2i(jt), >>>>> +??????????????????? p2i(n)); >>>>> +??? } else { >>>>> +????? out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free >>>>> global monitor " >>>>> +??????????????????? "must not be busy.", p2i(n)); >>>>> +??? } >>>>> +??? *error_cnt_p = *error_cnt_p + 1; >>>>> +? } >>>>> >>>>> >>>>> >>>>>>>>> And this is ObjectMonitor::verify_in_use() >>>>>>>>> >>>>>>>>> + if (n->header() == NULL) { >>>>>>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": in-use >>>>>>>>> global monitor " >>>>>>>>> + "must have non-NULL _header field.", p2i(n)); >>>>>>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>>>>>> + } >>>>>>>>> + if (n->object() == NULL) { >>>>>>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": in-use >>>>>>>>> global monitor " >>>>>>>>> + "must have non-NULL _object field.", p2i(n)); >>>>>>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>>>>>> + } ... >>>>> >>>>> I have refactored the common code for "verify in use" into: >>>>> >>>>> +// Check an in-use monitor entry; log any errors. >>>>> +void ObjectSynchronizer::ck_in_use_entry(JavaThread * jt, >>>>> ObjectMonitor * n, >>>>> +???????????????????????????????????????? outputStream * out, int >>>>> *error_cnt_p) { >>>>> >>>>> And here's what one of the checks looks like: >>>>> >>>>> +? if (n->header() == NULL) { >>>>> +??? if (jt != NULL) { >>>>> +????? out->print_cr("ERROR: jt=" INTPTR_FORMAT ", monitor=" >>>>> INTPTR_FORMAT >>>>> +??????????????????? ": in-use per-thread monitor must have >>>>> non-NULL _header " >>>>> +??????????????????? "field.", p2i(jt), p2i(n)); >>>>> +??? } else { >>>>> +????? out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": in-use >>>>> global monitor " >>>>> +??????????????????? "must have non-NULL _header field.", p2i(n)); >>>>> +??? } >>>>> +??? *error_cnt_p = *error_cnt_p + 1; >>>>> +? } >>>>> >>>>> Hopefully this is the last refactor for this bug fix... :-) >>>>> >>>>> >>>>> Here's an incremental webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8217659-webrev/2-for-jdk13.inc/ >>>>> >>>>> Here's a full webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8217659-webrev/2-for-jdk13.full/ >>>>> >>>>> Another Mach5 builds-tier1,hs-tier1,jdk-tier1,hs-tier2,hs-tier3 test >>>>> run is in process... >>>>> >>>>> Thanks, in advance, for any questions, comments or suggestions. >>>>> >>>>> Dan >>>>> >>>>>> The details are in the bug report: >>>>>> >>>>>> ??? JDK-8217659 monitor_logging updates from Async Monitor >>>>>> Deflation project >>>>>> https://bugs.openjdk.java.net/browse/JDK-8217659 >>>>> >>> >>> >> > From calvin.cheung at oracle.com Wed Jan 30 23:03:52 2019 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Wed, 30 Jan 2019 15:03:52 -0800 Subject: RFR(XS) 8218029 [TESTBUG] Use -Djava.class.path= to specify empty -cp in CDS tests In-Reply-To: <5c7f9b93-bd8a-86f5-7d3c-23981bc8b4bc@oracle.com> References: <5c7f9b93-bd8a-86f5-7d3c-23981bc8b4bc@oracle.com> Message-ID: <5C522D58.6090002@oracle.com> Hi Ioi, The fix looks fine but I'm not sure if it is necessary. I've tried the following on linux and windows and the java.class.path property is not set. java -cp "" MyApp MyApp just display all system properties as follows: Properties properties = System.getProperties(); properties.forEach((k, v) -> System.out.println(k + ":" + v)); thanks, Calvin On 1/29/19, 7:51 PM, Ioi Lam wrote: > https://bugs.openjdk.java.net/browse/JDK-8218029 > http://cr.openjdk.java.net/~iklam/jdk13/8218029-testbug-empty-classpath.v01/ > > > Please review this simple fix. For portability, > > "-cp", "\"\"", > > in the JVM command-line is replaced with > > "-Djava.class.path=" > > > Thanks! > > Ioi > From david.holmes at oracle.com Thu Jan 31 01:31:01 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 31 Jan 2019 11:31:01 +1000 Subject: RFR (T) 8212949: Remove ConstantPoolCache::is_constantPoolCache In-Reply-To: <7040c1fd-421e-4ceb-882e-5dd0769f45e0@oracle.com> References: <7040c1fd-421e-4ceb-882e-5dd0769f45e0@oracle.com> Message-ID: Looks good! Thanks, David On 31/01/2019 8:09 am, coleen.phillimore at oracle.com wrote: > Summary: remove relic of permgen, also is_constMethod too. > > See bug for more details.? Tested with hs-tier1,2. > > open webrev at http://cr.openjdk.java.net/~coleenp/2019/8212949.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8212949 > > Thanks, > Coleen From coleen.phillimore at oracle.com Thu Jan 31 02:33:32 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 30 Jan 2019 21:33:32 -0500 Subject: RFR (T) 8212949: Remove ConstantPoolCache::is_constantPoolCache In-Reply-To: References: <7040c1fd-421e-4ceb-882e-5dd0769f45e0@oracle.com> Message-ID: Thanks, David. Coleen On 1/30/19 8:31 PM, David Holmes wrote: > Looks good! > > Thanks, > David > > On 31/01/2019 8:09 am, coleen.phillimore at oracle.com wrote: >> Summary: remove relic of permgen, also is_constMethod too. >> >> See bug for more details.? Tested with hs-tier1,2. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2019/8212949.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8212949 >> >> Thanks, >> Coleen From david.holmes at oracle.com Thu Jan 31 02:46:01 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 31 Jan 2019 12:46:01 +1000 Subject: RFR(S/M): 8217659 monitor_logging updates from Async Monitor Deflation project In-Reply-To: <8d0a0d25-ca0f-1b80-28a5-76d098c4fae9@oracle.com> References: <98f74cf8-1634-c0ad-0bbc-7c2d8e31a467@oracle.com> <003a4d2e-f7c1-cc57-6ab8-6a207ce64896@oracle.com> <39addd9a-532d-0bab-31fb-bdce5d67f426@oracle.com> <4383a85b-cf89-3f06-0f46-ba4e4159434e@oracle.com> <4eeabfbf-1f7e-fe98-3837-0c19b456341a@oracle.com> <8d0a0d25-ca0f-1b80-28a5-76d098c4fae9@oracle.com> Message-ID: Hi Dan, On 31/01/2019 5:23 am, Daniel D. Daugherty wrote: > Greetings, > > I've addressed David H's latest round of comments. > > Here's an incremental webrev: > > http://cr.openjdk.java.net/~dcubed/8217659-webrev/3-for-jdk13.inc/ Sorry but I gave you some bad advice, the pattern I suggested doesn't work either: 1648 LogStreamHandle(Debug, monitorinflation) lsh_debug; 1649 LogStreamHandle(Info, monitorinflation) lsh_info; 1650 LogStream * ls = NULL; 1651 if (log_is_enabled(Debug, monitorinflation)) { 1652 ls = &lsh_debug; 1653 } else if (deflated_count != 0 && log_is_enabled(Info, monitorinflation)) { 1654 ls = &lsh_info; 1655 } 1656 if (ls != NULL) { 1657 ls->print_cr("deflating global idle monitors, %3.7f secs, %d monitors", timer.seconds(), deflated_count); 1658 } Assume both Debug and Info are enabled, but directed to different files. You potentially need to log to both of them, but the code above will only log to one of them. I don't think you have a choice but to duplicate the logging statements. :( Sorry again. David ----- > Here's a full webrev: > > http://cr.openjdk.java.net/~dcubed/8217659-webrev/3-for-jdk13.full/ > > Another Mach5 builds-tier1,hs-tier1,jdk-tier1,hs-tier2,hs-tier3 test > run is in process... I've manually verified that we get fewer log > messages at the Info level (deflate count == 0 are skipped) and that > get those deflate count == 0 mesgs at the Debug level. > > Thanks, in advance, for any questions, comments or suggestions. > > Dan > > > On 1/30/19 11:07 AM, Daniel D. Daugherty wrote: >> On 1/29/19 10:07 PM, David Holmes wrote: >>> Hi Dan, >> >> Hi David! >> >> And thanks for the re-review. >> >> >>> First a couple of nits: >>> >>> 1. I don't like the ck_* naming as an abbreviation for "check". chk >>> would be better, or even check. >> >> I'll change 'ck_' -> 'chk_'. >> >> >>> 2. We don't need comments like this: >>> >>> 1430???????? // Use log_is_enabled() to avoid ResourceMark creation and >>> 1431???????? // external_name() use if possible. >>> >>> else we'd be using them in 90% of logging blocks. >> >> I added that comment in two places in response to a comment from Coleen >> to remove the 'log_is_enabled()' call. Since you're saying that my >> comment >> is 'common knowledge' then I'll remove both of them. >> >> >>> There is one erroneous pattern here. You can't do this: >>> >>> 1654?? if ((deflated_count != 0 && log_is_enabled(Info, >>> monitorinflation)) || >>> 1655?????? log_is_enabled(Debug, monitorinflation)) { >>> 1656???? log_info(monitorinflation)("deflating global idle monitors, >>> %3.7f secs, %d monitors", timer.seconds(), deflated_count); >>> 1657?? } >>> >>> While Info normally implies Debug, they can be controlled >>> independently, further you may be writing Info output and Debug >>> output to different streams. So you can't just use log_info when it >>> should really be log_debug. >> >> Thanks for catching this one. Obviously I still have more to learn >> about logging... >> >> >>> Probably the way to handle this without duplication is to again use >>> LogStreams (or outputstreams): >>> >>> LogStream* ls; >>> if (log_is_enabled(Debug, monitorinflation)) >>> ? ls = >>> else if (log_is_enabled(Info, monitorinflation)) >>> ? ls = >>> if (ls != null) >>> ? ls.print(...); >> >> Thanks for the pattern. I'll take care of it. I think the bug is >> in at least two places. >> >> >>> Using a LogStream can also avoid duplicate is_enabled checks in >>> places like ObjectSynchronizer::finish_deflate_idle_monitors. >> >> I'll revisit finish_deflate_idle_monitors() also. >> >> Thanks again for the re-review. >> >> Dan >> >> >>> >>> Thanks, >>> David >>> ----- >>> >>> >>> On 30/01/2019 7:26 am, Daniel D. Daugherty wrote: >>>> I've snipped this reply down to just the part about refactoring... >>>> >>>> >>>> On 1/28/19 5:22 PM, Daniel D. Daugherty wrote: >>>>> On 1/28/19 5:15 PM, coleen.phillimore at oracle.com wrote: >>>>>>> >>>>>>>> My eyes are terrible, but it looks like this is >>>>>>>> ObjectMonitor::verify_free() >>>>>>> >>>>>>>> + if (n->is_busy()) { >>>>>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global >>>>>>>> monitor " >>>>>>>> + "must not be busy.", p2i(n)); >>>>>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>>>>> + } >>>>>>>> + if (n->header() != NULL) { >>>>>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global >>>>>>>> monitor " >>>>>>>> + "must have NULL _header field: _header=" INTPTR_FORMAT, >>>>>>>> + p2i(n), p2i(n->header())); >>>>>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>>>>> + } >>>>>>>> + if (n->object() != NULL) { >>>>>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global >>>>>>>> monitor " >>>>>>>> + "must have NULL _object field: _object=" INTPTR_FORMAT, >>>>>>>> + p2i(n), p2i(n->object())); >>>>>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>>>>> + } ... >>>> >>>> I have refactored the common code for "verify free" into: >>>> >>>> +// Check a free monitor entry; log any errors. >>>> +void ObjectSynchronizer::ck_free_entry(JavaThread * jt, >>>> ObjectMonitor * n, >>>> +?????????????????????????????????????? outputStream * out, int >>>> *error_cnt_p) { >>>> >>>> And here's what one of the checks looks like. I tried to put it all >>>> into >>>> a single out->print_cr() call with conditional inclusion of format >>>> strings >>>> and parameters, but the compiler really hated it. So I went with: >>>> >>>> +? if (n->is_busy()) { >>>> +??? if (jt != NULL) { >>>> +????? out->print_cr("ERROR: jt=" INTPTR_FORMAT ", monitor=" >>>> INTPTR_FORMAT >>>> +??????????????????? ": free per-thread monitor must not be busy.", >>>> p2i(jt), >>>> +??????????????????? p2i(n)); >>>> +??? } else { >>>> +????? out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global >>>> monitor " >>>> +??????????????????? "must not be busy.", p2i(n)); >>>> +??? } >>>> +??? *error_cnt_p = *error_cnt_p + 1; >>>> +? } >>>> >>>> >>>> >>>>>>>> And this is ObjectMonitor::verify_in_use() >>>>>>>> >>>>>>>> + if (n->header() == NULL) { >>>>>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": in-use global >>>>>>>> monitor " >>>>>>>> + "must have non-NULL _header field.", p2i(n)); >>>>>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>>>>> + } >>>>>>>> + if (n->object() == NULL) { >>>>>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": in-use global >>>>>>>> monitor " >>>>>>>> + "must have non-NULL _object field.", p2i(n)); >>>>>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>>>>> + } ... >>>> >>>> I have refactored the common code for "verify in use" into: >>>> >>>> +// Check an in-use monitor entry; log any errors. >>>> +void ObjectSynchronizer::ck_in_use_entry(JavaThread * jt, >>>> ObjectMonitor * n, >>>> +???????????????????????????????????????? outputStream * out, int >>>> *error_cnt_p) { >>>> >>>> And here's what one of the checks looks like: >>>> >>>> +? if (n->header() == NULL) { >>>> +??? if (jt != NULL) { >>>> +????? out->print_cr("ERROR: jt=" INTPTR_FORMAT ", monitor=" >>>> INTPTR_FORMAT >>>> +??????????????????? ": in-use per-thread monitor must have non-NULL >>>> _header " >>>> +??????????????????? "field.", p2i(jt), p2i(n)); >>>> +??? } else { >>>> +????? out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": in-use >>>> global monitor " >>>> +??????????????????? "must have non-NULL _header field.", p2i(n)); >>>> +??? } >>>> +??? *error_cnt_p = *error_cnt_p + 1; >>>> +? } >>>> >>>> Hopefully this is the last refactor for this bug fix... :-) >>>> >>>> >>>> Here's an incremental webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8217659-webrev/2-for-jdk13.inc/ >>>> >>>> Here's a full webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8217659-webrev/2-for-jdk13.full/ >>>> >>>> Another Mach5 builds-tier1,hs-tier1,jdk-tier1,hs-tier2,hs-tier3 test >>>> run is in process... >>>> >>>> Thanks, in advance, for any questions, comments or suggestions. >>>> >>>> Dan >>>> >>>>> The details are in the bug report: >>>>> >>>>> ??? JDK-8217659 monitor_logging updates from Async Monitor >>>>> Deflation project >>>>> https://bugs.openjdk.java.net/browse/JDK-8217659 >>>> >> >> > From daniel.daugherty at oracle.com Thu Jan 31 03:23:37 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 30 Jan 2019 22:23:37 -0500 Subject: RFR(S/M): 8217659 monitor_logging updates from Async Monitor Deflation project In-Reply-To: References: <98f74cf8-1634-c0ad-0bbc-7c2d8e31a467@oracle.com> <003a4d2e-f7c1-cc57-6ab8-6a207ce64896@oracle.com> <39addd9a-532d-0bab-31fb-bdce5d67f426@oracle.com> <4383a85b-cf89-3f06-0f46-ba4e4159434e@oracle.com> <4eeabfbf-1f7e-fe98-3837-0c19b456341a@oracle.com> <8d0a0d25-ca0f-1b80-28a5-76d098c4fae9@oracle.com> Message-ID: <0e089c41-5bee-8e3f-6c3e-3467cabc9150@oracle.com> On 1/30/19 9:46 PM, David Holmes wrote: > Hi Dan, > > On 31/01/2019 5:23 am, Daniel D. Daugherty wrote: >> Greetings, >> >> I've addressed David H's latest round of comments. >> >> Here's an incremental webrev: >> >> http://cr.openjdk.java.net/~dcubed/8217659-webrev/3-for-jdk13.inc/ > > Sorry but I gave you some bad advice, the pattern I suggested doesn't > work either: > > 1648?? LogStreamHandle(Debug, monitorinflation) lsh_debug; > 1649?? LogStreamHandle(Info, monitorinflation) lsh_info; > 1650?? LogStream * ls = NULL; > 1651?? if (log_is_enabled(Debug, monitorinflation)) { > 1652???? ls = &lsh_debug; > 1653?? } else if (deflated_count != 0 && log_is_enabled(Info, > monitorinflation)) { > 1654???? ls = &lsh_info; > 1655?? } > 1656?? if (ls != NULL) { > 1657???? ls->print_cr("deflating global idle monitors, %3.7f secs, %d > monitors", timer.seconds(), deflated_count); > 1658?? } > > Assume both Debug and Info are enabled, but directed to different > files. You potentially need to log to both of them, but the code above > will only log to one of them. I don't think you have a choice but to > duplicate the logging statements. :( Doing that would duplicate the logging statements in the output if both Debug and Info were logging to the same place and I don't want that. If both Debug and Info are enabled and directed to different files, I'm happy to find most of the output in the Debug log file and only the log_info() output in the Info log file. This is particularly true for audit_and_print_stats() output. I'm planning to move forward with the latest webrev if you are okay with that... Dan > > Sorry again. > > David > ----- > > > >> Here's a full webrev: >> >> http://cr.openjdk.java.net/~dcubed/8217659-webrev/3-for-jdk13.full/ >> >> Another Mach5 builds-tier1,hs-tier1,jdk-tier1,hs-tier2,hs-tier3 test >> run is in process... I've manually verified that we get fewer log >> messages at the Info level (deflate count == 0 are skipped) and that >> get those deflate count == 0 mesgs at the Debug level. >> >> Thanks, in advance, for any questions, comments or suggestions. >> >> Dan >> >> >> On 1/30/19 11:07 AM, Daniel D. Daugherty wrote: >>> On 1/29/19 10:07 PM, David Holmes wrote: >>>> Hi Dan, >>> >>> Hi David! >>> >>> And thanks for the re-review. >>> >>> >>>> First a couple of nits: >>>> >>>> 1. I don't like the ck_* naming as an abbreviation for "check". chk >>>> would be better, or even check. >>> >>> I'll change 'ck_' -> 'chk_'. >>> >>> >>>> 2. We don't need comments like this: >>>> >>>> 1430???????? // Use log_is_enabled() to avoid ResourceMark creation >>>> and >>>> 1431???????? // external_name() use if possible. >>>> >>>> else we'd be using them in 90% of logging blocks. >>> >>> I added that comment in two places in response to a comment from Coleen >>> to remove the 'log_is_enabled()' call. Since you're saying that my >>> comment >>> is 'common knowledge' then I'll remove both of them. >>> >>> >>>> There is one erroneous pattern here. You can't do this: >>>> >>>> 1654?? if ((deflated_count != 0 && log_is_enabled(Info, >>>> monitorinflation)) || >>>> 1655?????? log_is_enabled(Debug, monitorinflation)) { >>>> 1656???? log_info(monitorinflation)("deflating global idle >>>> monitors, %3.7f secs, %d monitors", timer.seconds(), deflated_count); >>>> 1657?? } >>>> >>>> While Info normally implies Debug, they can be controlled >>>> independently, further you may be writing Info output and Debug >>>> output to different streams. So you can't just use log_info when it >>>> should really be log_debug. >>> >>> Thanks for catching this one. Obviously I still have more to learn >>> about logging... >>> >>> >>>> Probably the way to handle this without duplication is to again use >>>> LogStreams (or outputstreams): >>>> >>>> LogStream* ls; >>>> if (log_is_enabled(Debug, monitorinflation)) >>>> ? ls = >>>> else if (log_is_enabled(Info, monitorinflation)) >>>> ? ls = >>>> if (ls != null) >>>> ? ls.print(...); >>> >>> Thanks for the pattern. I'll take care of it. I think the bug is >>> in at least two places. >>> >>> >>>> Using a LogStream can also avoid duplicate is_enabled checks in >>>> places like ObjectSynchronizer::finish_deflate_idle_monitors. >>> >>> I'll revisit finish_deflate_idle_monitors() also. >>> >>> Thanks again for the re-review. >>> >>> Dan >>> >>> >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>> >>>> On 30/01/2019 7:26 am, Daniel D. Daugherty wrote: >>>>> I've snipped this reply down to just the part about refactoring... >>>>> >>>>> >>>>> On 1/28/19 5:22 PM, Daniel D. Daugherty wrote: >>>>>> On 1/28/19 5:15 PM, coleen.phillimore at oracle.com wrote: >>>>>>>> >>>>>>>>> My eyes are terrible, but it looks like this is >>>>>>>>> ObjectMonitor::verify_free() >>>>>>>> >>>>>>>>> + if (n->is_busy()) { >>>>>>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global >>>>>>>>> monitor " >>>>>>>>> + "must not be busy.", p2i(n)); >>>>>>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>>>>>> + } >>>>>>>>> + if (n->header() != NULL) { >>>>>>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global >>>>>>>>> monitor " >>>>>>>>> + "must have NULL _header field: _header=" INTPTR_FORMAT, >>>>>>>>> + p2i(n), p2i(n->header())); >>>>>>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>>>>>> + } >>>>>>>>> + if (n->object() != NULL) { >>>>>>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global >>>>>>>>> monitor " >>>>>>>>> + "must have NULL _object field: _object=" INTPTR_FORMAT, >>>>>>>>> + p2i(n), p2i(n->object())); >>>>>>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>>>>>> + } ... >>>>> >>>>> I have refactored the common code for "verify free" into: >>>>> >>>>> +// Check a free monitor entry; log any errors. >>>>> +void ObjectSynchronizer::ck_free_entry(JavaThread * jt, >>>>> ObjectMonitor * n, >>>>> +?????????????????????????????????????? outputStream * out, int >>>>> *error_cnt_p) { >>>>> >>>>> And here's what one of the checks looks like. I tried to put it >>>>> all into >>>>> a single out->print_cr() call with conditional inclusion of format >>>>> strings >>>>> and parameters, but the compiler really hated it. So I went with: >>>>> >>>>> +? if (n->is_busy()) { >>>>> +??? if (jt != NULL) { >>>>> +????? out->print_cr("ERROR: jt=" INTPTR_FORMAT ", monitor=" >>>>> INTPTR_FORMAT >>>>> +??????????????????? ": free per-thread monitor must not be >>>>> busy.", p2i(jt), >>>>> +??????????????????? p2i(n)); >>>>> +??? } else { >>>>> +????? out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free >>>>> global monitor " >>>>> +??????????????????? "must not be busy.", p2i(n)); >>>>> +??? } >>>>> +??? *error_cnt_p = *error_cnt_p + 1; >>>>> +? } >>>>> >>>>> >>>>> >>>>>>>>> And this is ObjectMonitor::verify_in_use() >>>>>>>>> >>>>>>>>> + if (n->header() == NULL) { >>>>>>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": in-use >>>>>>>>> global monitor " >>>>>>>>> + "must have non-NULL _header field.", p2i(n)); >>>>>>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>>>>>> + } >>>>>>>>> + if (n->object() == NULL) { >>>>>>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": in-use >>>>>>>>> global monitor " >>>>>>>>> + "must have non-NULL _object field.", p2i(n)); >>>>>>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>>>>>> + } ... >>>>> >>>>> I have refactored the common code for "verify in use" into: >>>>> >>>>> +// Check an in-use monitor entry; log any errors. >>>>> +void ObjectSynchronizer::ck_in_use_entry(JavaThread * jt, >>>>> ObjectMonitor * n, >>>>> +???????????????????????????????????????? outputStream * out, int >>>>> *error_cnt_p) { >>>>> >>>>> And here's what one of the checks looks like: >>>>> >>>>> +? if (n->header() == NULL) { >>>>> +??? if (jt != NULL) { >>>>> +????? out->print_cr("ERROR: jt=" INTPTR_FORMAT ", monitor=" >>>>> INTPTR_FORMAT >>>>> +??????????????????? ": in-use per-thread monitor must have >>>>> non-NULL _header " >>>>> +??????????????????? "field.", p2i(jt), p2i(n)); >>>>> +??? } else { >>>>> +????? out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": in-use >>>>> global monitor " >>>>> +??????????????????? "must have non-NULL _header field.", p2i(n)); >>>>> +??? } >>>>> +??? *error_cnt_p = *error_cnt_p + 1; >>>>> +? } >>>>> >>>>> Hopefully this is the last refactor for this bug fix... :-) >>>>> >>>>> >>>>> Here's an incremental webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8217659-webrev/2-for-jdk13.inc/ >>>>> >>>>> Here's a full webrev: >>>>> >>>>> http://cr.openjdk.java.net/~dcubed/8217659-webrev/2-for-jdk13.full/ >>>>> >>>>> Another Mach5 builds-tier1,hs-tier1,jdk-tier1,hs-tier2,hs-tier3 test >>>>> run is in process... >>>>> >>>>> Thanks, in advance, for any questions, comments or suggestions. >>>>> >>>>> Dan >>>>> >>>>>> The details are in the bug report: >>>>>> >>>>>> ??? JDK-8217659 monitor_logging updates from Async Monitor >>>>>> Deflation project >>>>>> https://bugs.openjdk.java.net/browse/JDK-8217659 >>>>> >>> >>> >> From ioi.lam at oracle.com Thu Jan 31 03:51:04 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 30 Jan 2019 19:51:04 -0800 Subject: RFR(XS) 8218029 [TESTBUG] Use -Djava.class.path= to specify empty -cp in CDS tests In-Reply-To: <5C522D58.6090002@oracle.com> References: <5c7f9b93-bd8a-86f5-7d3c-23981bc8b4bc@oracle.com> <5C522D58.6090002@oracle.com> Message-ID: <52b98aa0-9e12-b5cf-bb53-67e316d955f3@oracle.com> Hi Calvin, The command-line that you gave (on the Linux shell) would pass the empty string as the value for -cp. However, in the JTREG test cases included in this patch, the command-line that's executed is effectively the following as typed in a Linux shell $ java -cp \"\" MyApp Here's a way to reproduce the problem. You can see that the string with 2 double quote characters were recorded in the NON_EXIST part of the CDS archive. That's not the intention of the test case. ================ $ echo sun/tools/jar/Main > classlist $ java -Xshare:dump -cp \"\" -XX:SharedClassListFile=classlist -verbose | grep Main [0.100s][info][class,load] sun.tools.jar.Main source: jrt:/jdk.jartool [0.103s][info][class,load] sun.tools.jar.Main$CRC32OutputStream source: jrt:/jdk.jartool [0.106s][info][class,load] sun.tools.jar.Main$ModuleInfoEntry source: jrt:/jdk.jartool $ tbjava -Xshare:on -XX:+PrintSharedArchiveAndExit [0.002s][info][class,path] opened: /jdk/bld/sandbox/images/jdk/lib/modules [0.007s][info][class,path] type=BOOT [0.007s][info][class,path] Expecting BOOT path=/jdk/bld/sandbox/images/jdk/lib/modules [0.007s][info][class,path] ok [0.007s][info][class,path] type=APP [0.007s][info][class,path] Expecting -Djava.class.path="" [0.007s][info][class,path] [0.007s][info][class,path] Run time APP classpath is shorter than the one at dump time: [0.007s][info][class,path] type=NON_EXIST [0.007s][info][class,path] Expecting that "" does not exist [0.007s][info][class,path] ok [0.007s][info][class,path] checking shared classpath entry: /jdk/bld/sandbox/images/jdk/lib/modules [0.007s][info][class,path] ok archive is invalid ================ Thanks - Ioi On 1/30/19 3:03 PM, Calvin Cheung wrote: > Hi Ioi, > > The fix looks fine but I'm not sure if it is necessary. > > I've tried the following on linux and windows and the java.class.path > property is not set. > > java -cp "" MyApp > > MyApp just display all system properties as follows: > > ??????? Properties properties = System.getProperties(); > > ??????? properties.forEach((k, v) -> System.out.println(k + ":" + v)); > > thanks, > Calvin > > On 1/29/19, 7:51 PM, Ioi Lam wrote: >> https://bugs.openjdk.java.net/browse/JDK-8218029 >> http://cr.openjdk.java.net/~iklam/jdk13/8218029-testbug-empty-classpath.v01/ >> >> >> Please review this simple fix. For portability, >> >> ???? "-cp", "\"\"", >> >> in the JVM command-line is replaced with >> >> ???? "-Djava.class.path=" >> >> >> Thanks! >> >> Ioi >> From david.holmes at oracle.com Thu Jan 31 03:50:36 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 31 Jan 2019 13:50:36 +1000 Subject: RFR(S/M): 8217659 monitor_logging updates from Async Monitor Deflation project In-Reply-To: <0e089c41-5bee-8e3f-6c3e-3467cabc9150@oracle.com> References: <98f74cf8-1634-c0ad-0bbc-7c2d8e31a467@oracle.com> <003a4d2e-f7c1-cc57-6ab8-6a207ce64896@oracle.com> <39addd9a-532d-0bab-31fb-bdce5d67f426@oracle.com> <4383a85b-cf89-3f06-0f46-ba4e4159434e@oracle.com> <4eeabfbf-1f7e-fe98-3837-0c19b456341a@oracle.com> <8d0a0d25-ca0f-1b80-28a5-76d098c4fae9@oracle.com> <0e089c41-5bee-8e3f-6c3e-3467cabc9150@oracle.com> Message-ID: <8ef7e13c-b870-903b-b95d-89c798b82a2f@oracle.com> On 31/01/2019 1:23 pm, Daniel D. Daugherty wrote: > On 1/30/19 9:46 PM, David Holmes wrote: >> Hi Dan, >> >> On 31/01/2019 5:23 am, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I've addressed David H's latest round of comments. >>> >>> Here's an incremental webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8217659-webrev/3-for-jdk13.inc/ >> >> Sorry but I gave you some bad advice, the pattern I suggested doesn't >> work either: >> >> 1648?? LogStreamHandle(Debug, monitorinflation) lsh_debug; >> 1649?? LogStreamHandle(Info, monitorinflation) lsh_info; >> 1650?? LogStream * ls = NULL; >> 1651?? if (log_is_enabled(Debug, monitorinflation)) { >> 1652???? ls = &lsh_debug; >> 1653?? } else if (deflated_count != 0 && log_is_enabled(Info, >> monitorinflation)) { >> 1654???? ls = &lsh_info; >> 1655?? } >> 1656?? if (ls != NULL) { >> 1657???? ls->print_cr("deflating global idle monitors, %3.7f secs, %d >> monitors", timer.seconds(), deflated_count); >> 1658?? } >> >> Assume both Debug and Info are enabled, but directed to different >> files. You potentially need to log to both of them, but the code above >> will only log to one of them. I don't think you have a choice but to >> duplicate the logging statements. :( > > Doing that would duplicate the logging statements in the output > if both Debug and Info were logging to the same place and I don't > want that. Seems like a flaw in the UL design then. > If both Debug and Info are enabled and directed to different files, > I'm happy to find most of the output in the Debug log file and only > the log_info() output in the Info log file. This is particularly > true for audit_and_print_stats() output. > > I'm planning to move forward with the latest webrev if you are okay > with that... Not completely happy but not strongly objecting. One nit though: 1673 } else if (counters->perThreadScavenged != 0 != 0 && log_is_enabled(Info, monitorinflation)) { !=0 is repeated. Thanks, David > Dan > > >> >> Sorry again. >> >> David >> ----- >> >> >> >>> Here's a full webrev: >>> >>> http://cr.openjdk.java.net/~dcubed/8217659-webrev/3-for-jdk13.full/ >>> >>> Another Mach5 builds-tier1,hs-tier1,jdk-tier1,hs-tier2,hs-tier3 test >>> run is in process... I've manually verified that we get fewer log >>> messages at the Info level (deflate count == 0 are skipped) and that >>> get those deflate count == 0 mesgs at the Debug level. >>> >>> Thanks, in advance, for any questions, comments or suggestions. >>> >>> Dan >>> >>> >>> On 1/30/19 11:07 AM, Daniel D. Daugherty wrote: >>>> On 1/29/19 10:07 PM, David Holmes wrote: >>>>> Hi Dan, >>>> >>>> Hi David! >>>> >>>> And thanks for the re-review. >>>> >>>> >>>>> First a couple of nits: >>>>> >>>>> 1. I don't like the ck_* naming as an abbreviation for "check". chk >>>>> would be better, or even check. >>>> >>>> I'll change 'ck_' -> 'chk_'. >>>> >>>> >>>>> 2. We don't need comments like this: >>>>> >>>>> 1430???????? // Use log_is_enabled() to avoid ResourceMark creation >>>>> and >>>>> 1431???????? // external_name() use if possible. >>>>> >>>>> else we'd be using them in 90% of logging blocks. >>>> >>>> I added that comment in two places in response to a comment from Coleen >>>> to remove the 'log_is_enabled()' call. Since you're saying that my >>>> comment >>>> is 'common knowledge' then I'll remove both of them. >>>> >>>> >>>>> There is one erroneous pattern here. You can't do this: >>>>> >>>>> 1654?? if ((deflated_count != 0 && log_is_enabled(Info, >>>>> monitorinflation)) || >>>>> 1655?????? log_is_enabled(Debug, monitorinflation)) { >>>>> 1656???? log_info(monitorinflation)("deflating global idle >>>>> monitors, %3.7f secs, %d monitors", timer.seconds(), deflated_count); >>>>> 1657?? } >>>>> >>>>> While Info normally implies Debug, they can be controlled >>>>> independently, further you may be writing Info output and Debug >>>>> output to different streams. So you can't just use log_info when it >>>>> should really be log_debug. >>>> >>>> Thanks for catching this one. Obviously I still have more to learn >>>> about logging... >>>> >>>> >>>>> Probably the way to handle this without duplication is to again use >>>>> LogStreams (or outputstreams): >>>>> >>>>> LogStream* ls; >>>>> if (log_is_enabled(Debug, monitorinflation)) >>>>> ? ls = >>>>> else if (log_is_enabled(Info, monitorinflation)) >>>>> ? ls = >>>>> if (ls != null) >>>>> ? ls.print(...); >>>> >>>> Thanks for the pattern. I'll take care of it. I think the bug is >>>> in at least two places. >>>> >>>> >>>>> Using a LogStream can also avoid duplicate is_enabled checks in >>>>> places like ObjectSynchronizer::finish_deflate_idle_monitors. >>>> >>>> I'll revisit finish_deflate_idle_monitors() also. >>>> >>>> Thanks again for the re-review. >>>> >>>> Dan >>>> >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> ----- >>>>> >>>>> >>>>> On 30/01/2019 7:26 am, Daniel D. Daugherty wrote: >>>>>> I've snipped this reply down to just the part about refactoring... >>>>>> >>>>>> >>>>>> On 1/28/19 5:22 PM, Daniel D. Daugherty wrote: >>>>>>> On 1/28/19 5:15 PM, coleen.phillimore at oracle.com wrote: >>>>>>>>> >>>>>>>>>> My eyes are terrible, but it looks like this is >>>>>>>>>> ObjectMonitor::verify_free() >>>>>>>>> >>>>>>>>>> + if (n->is_busy()) { >>>>>>>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global >>>>>>>>>> monitor " >>>>>>>>>> + "must not be busy.", p2i(n)); >>>>>>>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>>>>>>> + } >>>>>>>>>> + if (n->header() != NULL) { >>>>>>>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global >>>>>>>>>> monitor " >>>>>>>>>> + "must have NULL _header field: _header=" INTPTR_FORMAT, >>>>>>>>>> + p2i(n), p2i(n->header())); >>>>>>>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>>>>>>> + } >>>>>>>>>> + if (n->object() != NULL) { >>>>>>>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free global >>>>>>>>>> monitor " >>>>>>>>>> + "must have NULL _object field: _object=" INTPTR_FORMAT, >>>>>>>>>> + p2i(n), p2i(n->object())); >>>>>>>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>>>>>>> + } ... >>>>>> >>>>>> I have refactored the common code for "verify free" into: >>>>>> >>>>>> +// Check a free monitor entry; log any errors. >>>>>> +void ObjectSynchronizer::ck_free_entry(JavaThread * jt, >>>>>> ObjectMonitor * n, >>>>>> +?????????????????????????????????????? outputStream * out, int >>>>>> *error_cnt_p) { >>>>>> >>>>>> And here's what one of the checks looks like. I tried to put it >>>>>> all into >>>>>> a single out->print_cr() call with conditional inclusion of format >>>>>> strings >>>>>> and parameters, but the compiler really hated it. So I went with: >>>>>> >>>>>> +? if (n->is_busy()) { >>>>>> +??? if (jt != NULL) { >>>>>> +????? out->print_cr("ERROR: jt=" INTPTR_FORMAT ", monitor=" >>>>>> INTPTR_FORMAT >>>>>> +??????????????????? ": free per-thread monitor must not be >>>>>> busy.", p2i(jt), >>>>>> +??????????????????? p2i(n)); >>>>>> +??? } else { >>>>>> +????? out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free >>>>>> global monitor " >>>>>> +??????????????????? "must not be busy.", p2i(n)); >>>>>> +??? } >>>>>> +??? *error_cnt_p = *error_cnt_p + 1; >>>>>> +? } >>>>>> >>>>>> >>>>>> >>>>>>>>>> And this is ObjectMonitor::verify_in_use() >>>>>>>>>> >>>>>>>>>> + if (n->header() == NULL) { >>>>>>>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": in-use >>>>>>>>>> global monitor " >>>>>>>>>> + "must have non-NULL _header field.", p2i(n)); >>>>>>>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>>>>>>> + } >>>>>>>>>> + if (n->object() == NULL) { >>>>>>>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": in-use >>>>>>>>>> global monitor " >>>>>>>>>> + "must have non-NULL _object field.", p2i(n)); >>>>>>>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>>>>>>> + } ... >>>>>> >>>>>> I have refactored the common code for "verify in use" into: >>>>>> >>>>>> +// Check an in-use monitor entry; log any errors. >>>>>> +void ObjectSynchronizer::ck_in_use_entry(JavaThread * jt, >>>>>> ObjectMonitor * n, >>>>>> +???????????????????????????????????????? outputStream * out, int >>>>>> *error_cnt_p) { >>>>>> >>>>>> And here's what one of the checks looks like: >>>>>> >>>>>> +? if (n->header() == NULL) { >>>>>> +??? if (jt != NULL) { >>>>>> +????? out->print_cr("ERROR: jt=" INTPTR_FORMAT ", monitor=" >>>>>> INTPTR_FORMAT >>>>>> +??????????????????? ": in-use per-thread monitor must have >>>>>> non-NULL _header " >>>>>> +??????????????????? "field.", p2i(jt), p2i(n)); >>>>>> +??? } else { >>>>>> +????? out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": in-use >>>>>> global monitor " >>>>>> +??????????????????? "must have non-NULL _header field.", p2i(n)); >>>>>> +??? } >>>>>> +??? *error_cnt_p = *error_cnt_p + 1; >>>>>> +? } >>>>>> >>>>>> Hopefully this is the last refactor for this bug fix... :-) >>>>>> >>>>>> >>>>>> Here's an incremental webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8217659-webrev/2-for-jdk13.inc/ >>>>>> >>>>>> Here's a full webrev: >>>>>> >>>>>> http://cr.openjdk.java.net/~dcubed/8217659-webrev/2-for-jdk13.full/ >>>>>> >>>>>> Another Mach5 builds-tier1,hs-tier1,jdk-tier1,hs-tier2,hs-tier3 test >>>>>> run is in process... >>>>>> >>>>>> Thanks, in advance, for any questions, comments or suggestions. >>>>>> >>>>>> Dan >>>>>> >>>>>>> The details are in the bug report: >>>>>>> >>>>>>> ??? JDK-8217659 monitor_logging updates from Async Monitor >>>>>>> Deflation project >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8217659 >>>>>> >>>> >>>> >>> > From calvin.cheung at oracle.com Thu Jan 31 05:10:36 2019 From: calvin.cheung at oracle.com (Calvin Cheung) Date: Wed, 30 Jan 2019 21:10:36 -0800 Subject: RFR(XS) 8218029 [TESTBUG] Use -Djava.class.path= to specify empty -cp in CDS tests In-Reply-To: <52b98aa0-9e12-b5cf-bb53-67e316d955f3@oracle.com> References: <5c7f9b93-bd8a-86f5-7d3c-23981bc8b4bc@oracle.com> <5C522D58.6090002@oracle.com> <52b98aa0-9e12-b5cf-bb53-67e316d955f3@oracle.com> Message-ID: <5C52834C.1010102@oracle.com> Thanks for the clarifications. The fix makes sense. thanks, Calvin On 1/30/19, 7:51 PM, Ioi Lam wrote: > Hi Calvin, > > The command-line that you gave (on the Linux shell) would pass the > empty string as the value for -cp. > > However, in the JTREG test cases included in this patch, the > command-line that's executed is effectively the following as typed in > a Linux shell > > $ java -cp \"\" MyApp > > Here's a way to reproduce the problem. You can see that the string > with 2 double quote characters were recorded in the NON_EXIST part of > the CDS archive. That's not the intention of the test case. > > ================ > > $ echo sun/tools/jar/Main > classlist > > $ java -Xshare:dump -cp \"\" -XX:SharedClassListFile=classlist > -verbose | grep Main > [0.100s][info][class,load] sun.tools.jar.Main source: jrt:/jdk.jartool > [0.103s][info][class,load] sun.tools.jar.Main$CRC32OutputStream > source: jrt:/jdk.jartool > [0.106s][info][class,load] sun.tools.jar.Main$ModuleInfoEntry source: > jrt:/jdk.jartool > > $ tbjava -Xshare:on -XX:+PrintSharedArchiveAndExit > [0.002s][info][class,path] opened: > /jdk/bld/sandbox/images/jdk/lib/modules > [0.007s][info][class,path] type=BOOT > [0.007s][info][class,path] Expecting BOOT > path=/jdk/bld/sandbox/images/jdk/lib/modules > [0.007s][info][class,path] ok > [0.007s][info][class,path] type=APP > [0.007s][info][class,path] Expecting -Djava.class.path="" > [0.007s][info][class,path] > [0.007s][info][class,path] Run time APP classpath is shorter than the > one at dump time: > [0.007s][info][class,path] type=NON_EXIST > [0.007s][info][class,path] Expecting that "" does not exist > [0.007s][info][class,path] ok > [0.007s][info][class,path] checking shared classpath entry: > /jdk/bld/sandbox/images/jdk/lib/modules > [0.007s][info][class,path] ok > archive is invalid > ================ > > Thanks > > - Ioi > > > On 1/30/19 3:03 PM, Calvin Cheung wrote: >> Hi Ioi, >> >> The fix looks fine but I'm not sure if it is necessary. >> >> I've tried the following on linux and windows and the java.class.path >> property is not set. >> >> java -cp "" MyApp >> >> MyApp just display all system properties as follows: >> >> Properties properties = System.getProperties(); >> >> properties.forEach((k, v) -> System.out.println(k + ":" + v)); >> >> thanks, >> Calvin >> >> On 1/29/19, 7:51 PM, Ioi Lam wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8218029 >>> http://cr.openjdk.java.net/~iklam/jdk13/8218029-testbug-empty-classpath.v01/ >>> >>> >>> Please review this simple fix. For portability, >>> >>> "-cp", "\"\"", >>> >>> in the JVM command-line is replaced with >>> >>> "-Djava.class.path=" >>> >>> >>> Thanks! >>> >>> Ioi >>> From bob.vandette at oracle.com Thu Jan 31 14:08:28 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Thu, 31 Jan 2019 09:08:28 -0500 Subject: [TESTBUG] runtime/containers/docker/TestCPUAwareness.java failed in docker not supporting --cpus In-Reply-To: References: <420d2b08-86df-d591-35c9-d359a8811e9c@oracle.com> <3ABBCD75-1515-4B83-9FC1-18C737FD7C99@oracle.com> <6C6F3704-041B-4940-87E5-A73AB0808847@oracle.com> Message-ID: Yes, that does provide a bit more unique testing so leave the change as you had it. Thanks, Bob. > On Jan 28, 2019, at 8:41 PM, Ao Qi wrote: > > Hi Bob, > > Thanks! I am not a containers expert and have one small question. The > maximum amount of --cpus is 4 (equivalent to both setting ?cpu-period > and ?cpu-quota) in the already existing test. Is it valuable to keep > testCpus(i, i) according to the max num of available CPUs? If not, I > would also prefer removing the lines. In addition, I think I forgot to > update the copyright year, it will be fixed in the next version of > wevrev. > > On Mon, Jan 28, 2019 at 11:35 PM Bob Vandette wrote: >> >> There is already a test that verifies ?cpu-period and ?cpu-quota. >> I would just remove these lines. >> >> 62 // leave one CPU for system and tools, otherwise this test may be unstable >> 63 int maxNrOfAvailableCpus = availableCPUs - 1; >> 64 for (int i=1; i < maxNrOfAvailableCpus; i = i * 2) { >> 65 testCpus(i, i); >> 66 } >> >> 129 private static void testCpus(int valueToSet, int expectedTraceValue) throws Exception { >> 130 Common.logNewTestCase("test cpus: " + valueToSet); >> 131 DockerRunOptions opts = Common.newOpts(imageName) >> 132 .addDockerOpts("--cpus", "" + valueToSet); >> 133 Common.run(opts) >> 134 .shouldMatch("active_processor_count.*" + expectedTraceValue); >> 135 } >> >> Bob. >> >> On Jan 28, 2019, at 10:22 AM, Ao Qi wrote: >> >> Hi, >> >> Since ?cpus is a shortcut for of setting both --cpu-period and >> --cpu-quota and the test is not intended to verify that docker works >> correctly, I did not check the docker version and just replaced >> setting --cpus with setting both --cpu-period and --cpu-quota. What do >> you think of this patch: >> http://cr.openjdk.java.net/~aoqi/8217597/webrev.01/ ? >> >> Cheers, >> Ao Qi >> >> >> On Wed, Jan 23, 2019 at 11:37 PM Bob Vandette wrote: >> >> >> Since ?cpus is just a shortcut for of setting both --cpu-period and --cpu-quota?, I?d >> be ok with removing this test. The tests are intended to test the container/cgroup >> configuration detection logic and not to verify that docker works correctly. >> >> An alternate solution would be to add version detection to the Docker test check in >> DockerTestUtils.java . We already exec ?docker ps? to see if docker is available >> and enabled. >> >> % docker --version >> Docker version 17.03.1-ce, build 276fd32 >> >> >> Bob. >> >> >> >> On Jan 22, 2019, at 10:19 PM, Ao Qi wrote: >> >> On Wed, Jan 23, 2019 at 10:55 AM David Holmes wrote: >> >> >> On 23/01/2019 11:58 am, Ao Qi wrote: >> >> Hi David, >> >> On Wed, Jan 23, 2019 at 5:24 AM David Holmes wrote: >> >> >> cc'ing Bob as our containers expert ... >> >> On 23/01/2019 1:10 am, Ao Qi wrote: >> >> Hi, >> >> --cpus is available in Docker 1.13 and higher [1], so >> runtime/containers/docker/TestCPUAwareness.java failed in docker which >> does not support --cpus. >> >> Webrev: http://cr.openjdk.java.net/~aoqi/docker/webrev.00/ >> >> This patch skips the test if --cpus is not supported. I tested >> runtime/containers/docker/TestCPUAwareness.java on a Fedora 25 (Docker >> version 1.12.6, build ae7d637/1.12.6, not supporting --cpus) and >> Ubuntu 16.04 (Docker version 17.03.2-ce, build f5ec1e2, supporting >> --cpus) >> >> >> The patch causes the test to pass if launching Docker fails for any >> reason so that is not good. >> >> >> I tested two versions of docker which does not support --cpus. Their >> exit values when using --cpus are 2 and 125, and outputs are: >> >> flag provided but not defined: --cpus >> See 'docker run --help'. >> >> and >> >> unknown flag: --cpus >> See 'docker run --help'. >> >> My initial thought was that the else condition of >> "output.getExitValue() == 0" should match the condition of "--cpus not >> supported". Firstly I used output.shouldMatch("docker run --help"), >> but I am not sure if all the docker version behaves this way when >> --cpus is not supported and "docker run --help" does not certainly >> indicate "--cpus not supported", so I removed the else condition. >> >> >> I think we need to try and find a way to clearly identifyt eh failing >> condition. Is there are "docker --version" we coudl check? >> >> >> I will do more research. Checking docker version may be one option, >> and checking whether one option is support by docker may be also one >> option. I will try them later, while waiting if there are some other >> opinions :) >> >> I am not sure if this is a testbug, so I did not file it on JBS. In >> fact, I am not quite sure what kind of issue can be filed on JBS. Is >> there any guidance document? >> >> >> Any/all issues can be filed on JBS. You don't need to pre-classify as a >> testbug, simple create an issue that a test is failing under specific >> conditions. Whomever works on the bug will then determine whether it is >> a testbug or product issue or something else. (We don't seem to have any >> docs on using JBS ...) >> >> >> What if the issue is not a bug or no body cares the issue? The issue >> will be open on JBS forever? >> >> >> Possibly :) But each component team performs regular triage of the bugs >> that get filed and eventually things will be examined enough to see if >> they are indeed a bug, and if not they will be closed as not an issue. >> If a bug but low priority it may eventually get closed as "will not fix" >> just to keep the open bug count down. >> >> >> I was a little afraid that filing issues that are not bugs or nobody >> cares would increase the workload of others and frustrate myself, so I >> was not sure what kind of issue should be filed. Now I basically >> clear, thanks David. >> >> Cheers, >> David >> >> Thanks for your explanation, and I filed this issue on JBS: >> https://bugs.openjdk.java.net/browse/JDK-8217597 >> >> In this case I'm not sure whether we require a docker version that >> supports --cpus, and the test should be skipped otherwise. Though >> ideally this would involve an explicit version check so we don't just >> pass if the docker process fails. >> >> Thanks, >> David >> >> >> >> Cheers, >> Ao Qi >> >> [1] https://docs.docker.com/config/containers/resource_constraints/#cpu >> >> >> From daniel.daugherty at oracle.com Thu Jan 31 14:49:02 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 31 Jan 2019 09:49:02 -0500 Subject: RFR(S/M): 8217659 monitor_logging updates from Async Monitor Deflation project In-Reply-To: <8ef7e13c-b870-903b-b95d-89c798b82a2f@oracle.com> References: <98f74cf8-1634-c0ad-0bbc-7c2d8e31a467@oracle.com> <003a4d2e-f7c1-cc57-6ab8-6a207ce64896@oracle.com> <39addd9a-532d-0bab-31fb-bdce5d67f426@oracle.com> <4383a85b-cf89-3f06-0f46-ba4e4159434e@oracle.com> <4eeabfbf-1f7e-fe98-3837-0c19b456341a@oracle.com> <8d0a0d25-ca0f-1b80-28a5-76d098c4fae9@oracle.com> <0e089c41-5bee-8e3f-6c3e-3467cabc9150@oracle.com> <8ef7e13c-b870-903b-b95d-89c798b82a2f@oracle.com> Message-ID: On 1/30/19 10:50 PM, David Holmes wrote: > On 31/01/2019 1:23 pm, Daniel D. Daugherty wrote: >> On 1/30/19 9:46 PM, David Holmes wrote: >>> Hi Dan, >>> >>> On 31/01/2019 5:23 am, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> I've addressed David H's latest round of comments. >>>> >>>> Here's an incremental webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8217659-webrev/3-for-jdk13.inc/ >>> >>> Sorry but I gave you some bad advice, the pattern I suggested >>> doesn't work either: >>> >>> 1648?? LogStreamHandle(Debug, monitorinflation) lsh_debug; >>> 1649?? LogStreamHandle(Info, monitorinflation) lsh_info; >>> 1650?? LogStream * ls = NULL; >>> 1651?? if (log_is_enabled(Debug, monitorinflation)) { >>> 1652???? ls = &lsh_debug; >>> 1653?? } else if (deflated_count != 0 && log_is_enabled(Info, >>> monitorinflation)) { >>> 1654???? ls = &lsh_info; >>> 1655?? } >>> 1656?? if (ls != NULL) { >>> 1657???? ls->print_cr("deflating global idle monitors, %3.7f secs, >>> %d monitors", timer.seconds(), deflated_count); >>> 1658?? } >>> >>> Assume both Debug and Info are enabled, but directed to different >>> files. You potentially need to log to both of them, but the code >>> above will only log to one of them. I don't think you have a choice >>> but to duplicate the logging statements. :( >> >> Doing that would duplicate the logging statements in the output >> if both Debug and Info were logging to the same place and I don't >> want that. > > Seems like a flaw in the UL design then. Let me make sure we're talking about the same thing. When you said duplicate the logging statement, I assume you meant: ??? log_info(monitorinflation)("This is my message."); ??? log_debug(monitorinflation)("This is my message."); which makes sure that the same message goes to the Info log and the Debug log when those logs are separate files. I'll double check, but I believe that construct will send "This is my message." to the combined log twice. Why wouldn't it? You've made two independent log calls at two different logging levels that happen to have the same message. I'm not sure that I agree that this is a design flaw. The logging subsystem would have no way of knowing your intentions with these two separate calls. You might be sprinkling log messages through code paths to see where the code goes... and happen to have the same "XXX" message back to back (logging call wise), but at two different logging levels (which is strange)... > >> If both Debug and Info are enabled and directed to different files, >> I'm happy to find most of the output in the Debug log file and only >> the log_info() output in the Info log file. This is particularly >> true for audit_and_print_stats() output. >> >> I'm planning to move forward with the latest webrev if you are okay >> with that... > > Not completely happy but not strongly objecting. Thanks! > One nit though: > > 1673?? } else if (counters->perThreadScavenged != 0 != 0 && > log_is_enabled(Info, monitorinflation)) { > > > !=0 is repeated. I'll fix that! I'm guessing the compiler evaluated it like this: ? ((counters->perThreadScavenged != 0) != 0) ? ((true) != 0) ? (true) or ? ((false) != 0) ? (false) Thanks for the catch! Dan > > Thanks, > David > >> Dan >> >> >>> >>> Sorry again. >>> >>> David >>> ----- >>> >>> >>> >>>> Here's a full webrev: >>>> >>>> http://cr.openjdk.java.net/~dcubed/8217659-webrev/3-for-jdk13.full/ >>>> >>>> Another Mach5 builds-tier1,hs-tier1,jdk-tier1,hs-tier2,hs-tier3 test >>>> run is in process... I've manually verified that we get fewer log >>>> messages at the Info level (deflate count == 0 are skipped) and that >>>> get those deflate count == 0 mesgs at the Debug level. >>>> >>>> Thanks, in advance, for any questions, comments or suggestions. >>>> >>>> Dan >>>> >>>> >>>> On 1/30/19 11:07 AM, Daniel D. Daugherty wrote: >>>>> On 1/29/19 10:07 PM, David Holmes wrote: >>>>>> Hi Dan, >>>>> >>>>> Hi David! >>>>> >>>>> And thanks for the re-review. >>>>> >>>>> >>>>>> First a couple of nits: >>>>>> >>>>>> 1. I don't like the ck_* naming as an abbreviation for "check". >>>>>> chk would be better, or even check. >>>>> >>>>> I'll change 'ck_' -> 'chk_'. >>>>> >>>>> >>>>>> 2. We don't need comments like this: >>>>>> >>>>>> 1430???????? // Use log_is_enabled() to avoid ResourceMark >>>>>> creation and >>>>>> 1431???????? // external_name() use if possible. >>>>>> >>>>>> else we'd be using them in 90% of logging blocks. >>>>> >>>>> I added that comment in two places in response to a comment from >>>>> Coleen >>>>> to remove the 'log_is_enabled()' call. Since you're saying that my >>>>> comment >>>>> is 'common knowledge' then I'll remove both of them. >>>>> >>>>> >>>>>> There is one erroneous pattern here. You can't do this: >>>>>> >>>>>> 1654?? if ((deflated_count != 0 && log_is_enabled(Info, >>>>>> monitorinflation)) || >>>>>> 1655?????? log_is_enabled(Debug, monitorinflation)) { >>>>>> 1656???? log_info(monitorinflation)("deflating global idle >>>>>> monitors, %3.7f secs, %d monitors", timer.seconds(), >>>>>> deflated_count); >>>>>> 1657?? } >>>>>> >>>>>> While Info normally implies Debug, they can be controlled >>>>>> independently, further you may be writing Info output and Debug >>>>>> output to different streams. So you can't just use log_info when >>>>>> it should really be log_debug. >>>>> >>>>> Thanks for catching this one. Obviously I still have more to learn >>>>> about logging... >>>>> >>>>> >>>>>> Probably the way to handle this without duplication is to again >>>>>> use LogStreams (or outputstreams): >>>>>> >>>>>> LogStream* ls; >>>>>> if (log_is_enabled(Debug, monitorinflation)) >>>>>> ? ls = >>>>>> else if (log_is_enabled(Info, monitorinflation)) >>>>>> ? ls = >>>>>> if (ls != null) >>>>>> ? ls.print(...); >>>>> >>>>> Thanks for the pattern. I'll take care of it. I think the bug is >>>>> in at least two places. >>>>> >>>>> >>>>>> Using a LogStream can also avoid duplicate is_enabled checks in >>>>>> places like ObjectSynchronizer::finish_deflate_idle_monitors. >>>>> >>>>> I'll revisit finish_deflate_idle_monitors() also. >>>>> >>>>> Thanks again for the re-review. >>>>> >>>>> Dan >>>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> ----- >>>>>> >>>>>> >>>>>> On 30/01/2019 7:26 am, Daniel D. Daugherty wrote: >>>>>>> I've snipped this reply down to just the part about refactoring... >>>>>>> >>>>>>> >>>>>>> On 1/28/19 5:22 PM, Daniel D. Daugherty wrote: >>>>>>>> On 1/28/19 5:15 PM, coleen.phillimore at oracle.com wrote: >>>>>>>>>> >>>>>>>>>>> My eyes are terrible, but it looks like this is >>>>>>>>>>> ObjectMonitor::verify_free() >>>>>>>>>> >>>>>>>>>>> + if (n->is_busy()) { >>>>>>>>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free >>>>>>>>>>> global monitor " >>>>>>>>>>> + "must not be busy.", p2i(n)); >>>>>>>>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>>>>>>>> + } >>>>>>>>>>> + if (n->header() != NULL) { >>>>>>>>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free >>>>>>>>>>> global monitor " >>>>>>>>>>> + "must have NULL _header field: _header=" INTPTR_FORMAT, >>>>>>>>>>> + p2i(n), p2i(n->header())); >>>>>>>>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>>>>>>>> + } >>>>>>>>>>> + if (n->object() != NULL) { >>>>>>>>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free >>>>>>>>>>> global monitor " >>>>>>>>>>> + "must have NULL _object field: _object=" INTPTR_FORMAT, >>>>>>>>>>> + p2i(n), p2i(n->object())); >>>>>>>>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>>>>>>>> + } ... >>>>>>> >>>>>>> I have refactored the common code for "verify free" into: >>>>>>> >>>>>>> +// Check a free monitor entry; log any errors. >>>>>>> +void ObjectSynchronizer::ck_free_entry(JavaThread * jt, >>>>>>> ObjectMonitor * n, >>>>>>> +?????????????????????????????????????? outputStream * out, int >>>>>>> *error_cnt_p) { >>>>>>> >>>>>>> And here's what one of the checks looks like. I tried to put it >>>>>>> all into >>>>>>> a single out->print_cr() call with conditional inclusion of >>>>>>> format strings >>>>>>> and parameters, but the compiler really hated it. So I went with: >>>>>>> >>>>>>> +? if (n->is_busy()) { >>>>>>> +??? if (jt != NULL) { >>>>>>> +????? out->print_cr("ERROR: jt=" INTPTR_FORMAT ", monitor=" >>>>>>> INTPTR_FORMAT >>>>>>> +??????????????????? ": free per-thread monitor must not be >>>>>>> busy.", p2i(jt), >>>>>>> +??????????????????? p2i(n)); >>>>>>> +??? } else { >>>>>>> +????? out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": free >>>>>>> global monitor " >>>>>>> +??????????????????? "must not be busy.", p2i(n)); >>>>>>> +??? } >>>>>>> +??? *error_cnt_p = *error_cnt_p + 1; >>>>>>> +? } >>>>>>> >>>>>>> >>>>>>> >>>>>>>>>>> And this is ObjectMonitor::verify_in_use() >>>>>>>>>>> >>>>>>>>>>> + if (n->header() == NULL) { >>>>>>>>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": in-use >>>>>>>>>>> global monitor " >>>>>>>>>>> + "must have non-NULL _header field.", p2i(n)); >>>>>>>>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>>>>>>>> + } >>>>>>>>>>> + if (n->object() == NULL) { >>>>>>>>>>> + out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": in-use >>>>>>>>>>> global monitor " >>>>>>>>>>> + "must have non-NULL _object field.", p2i(n)); >>>>>>>>>>> + *error_cnt_p = *error_cnt_p + 1; >>>>>>>>>>> + } ... >>>>>>> >>>>>>> I have refactored the common code for "verify in use" into: >>>>>>> >>>>>>> +// Check an in-use monitor entry; log any errors. >>>>>>> +void ObjectSynchronizer::ck_in_use_entry(JavaThread * jt, >>>>>>> ObjectMonitor * n, >>>>>>> +???????????????????????????????????????? outputStream * out, >>>>>>> int *error_cnt_p) { >>>>>>> >>>>>>> And here's what one of the checks looks like: >>>>>>> >>>>>>> +? if (n->header() == NULL) { >>>>>>> +??? if (jt != NULL) { >>>>>>> +????? out->print_cr("ERROR: jt=" INTPTR_FORMAT ", monitor=" >>>>>>> INTPTR_FORMAT >>>>>>> +??????????????????? ": in-use per-thread monitor must have >>>>>>> non-NULL _header " >>>>>>> +??????????????????? "field.", p2i(jt), p2i(n)); >>>>>>> +??? } else { >>>>>>> +????? out->print_cr("ERROR: monitor=" INTPTR_FORMAT ": in-use >>>>>>> global monitor " >>>>>>> +??????????????????? "must have non-NULL _header field.", p2i(n)); >>>>>>> +??? } >>>>>>> +??? *error_cnt_p = *error_cnt_p + 1; >>>>>>> +? } >>>>>>> >>>>>>> Hopefully this is the last refactor for this bug fix... :-) >>>>>>> >>>>>>> >>>>>>> Here's an incremental webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8217659-webrev/2-for-jdk13.inc/ >>>>>>> >>>>>>> Here's a full webrev: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~dcubed/8217659-webrev/2-for-jdk13.full/ >>>>>>> >>>>>>> Another Mach5 builds-tier1,hs-tier1,jdk-tier1,hs-tier2,hs-tier3 >>>>>>> test >>>>>>> run is in process... >>>>>>> >>>>>>> Thanks, in advance, for any questions, comments or suggestions. >>>>>>> >>>>>>> Dan >>>>>>> >>>>>>>> The details are in the bug report: >>>>>>>> >>>>>>>> ??? JDK-8217659 monitor_logging updates from Async Monitor >>>>>>>> Deflation project >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8217659 >>>>>>> >>>>> >>>>> >>>> >> From aoqi at loongson.cn Thu Jan 31 16:00:39 2019 From: aoqi at loongson.cn (Ao Qi) Date: Fri, 1 Feb 2019 00:00:39 +0800 Subject: [TESTBUG] runtime/containers/docker/TestCPUAwareness.java failed in docker not supporting --cpus In-Reply-To: References: <420d2b08-86df-d591-35c9-d359a8811e9c@oracle.com> <3ABBCD75-1515-4B83-9FC1-18C737FD7C99@oracle.com> <6C6F3704-041B-4940-87E5-A73AB0808847@oracle.com> Message-ID: I leave the change, and update copyright year: http://cr.openjdk.java.net/~aoqi/8217597/webrev.02/ Could you help to review this? Thanks, Ao Qi On Thu, Jan 31, 2019 at 10:08 PM Bob Vandette wrote: > > Yes, that does provide a bit more unique testing so leave the change as you had it. > > Thanks, > Bob. > > > On Jan 28, 2019, at 8:41 PM, Ao Qi wrote: > > > > Hi Bob, > > > > Thanks! I am not a containers expert and have one small question. The > > maximum amount of --cpus is 4 (equivalent to both setting ?cpu-period > > and ?cpu-quota) in the already existing test. Is it valuable to keep > > testCpus(i, i) according to the max num of available CPUs? If not, I > > would also prefer removing the lines. In addition, I think I forgot to > > update the copyright year, it will be fixed in the next version of > > wevrev. > > > > On Mon, Jan 28, 2019 at 11:35 PM Bob Vandette wrote: > >> > >> There is already a test that verifies ?cpu-period and ?cpu-quota. > >> I would just remove these lines. > >> > >> 62 // leave one CPU for system and tools, otherwise this test may be unstable > >> 63 int maxNrOfAvailableCpus = availableCPUs - 1; > >> 64 for (int i=1; i < maxNrOfAvailableCpus; i = i * 2) { > >> 65 testCpus(i, i); > >> 66 } > >> > >> 129 private static void testCpus(int valueToSet, int expectedTraceValue) throws Exception { > >> 130 Common.logNewTestCase("test cpus: " + valueToSet); > >> 131 DockerRunOptions opts = Common.newOpts(imageName) > >> 132 .addDockerOpts("--cpus", "" + valueToSet); > >> 133 Common.run(opts) > >> 134 .shouldMatch("active_processor_count.*" + expectedTraceValue); > >> 135 } > >> > >> Bob. > >> > >> On Jan 28, 2019, at 10:22 AM, Ao Qi wrote: > >> > >> Hi, > >> > >> Since ?cpus is a shortcut for of setting both --cpu-period and > >> --cpu-quota and the test is not intended to verify that docker works > >> correctly, I did not check the docker version and just replaced > >> setting --cpus with setting both --cpu-period and --cpu-quota. What do > >> you think of this patch: > >> http://cr.openjdk.java.net/~aoqi/8217597/webrev.01/ ? > >> > >> Cheers, > >> Ao Qi > >> > >> > >> On Wed, Jan 23, 2019 at 11:37 PM Bob Vandette wrote: > >> > >> > >> Since ?cpus is just a shortcut for of setting both --cpu-period and --cpu-quota?, I?d > >> be ok with removing this test. The tests are intended to test the container/cgroup > >> configuration detection logic and not to verify that docker works correctly. > >> > >> An alternate solution would be to add version detection to the Docker test check in > >> DockerTestUtils.java . We already exec ?docker ps? to see if docker is available > >> and enabled. > >> > >> % docker --version > >> Docker version 17.03.1-ce, build 276fd32 > >> > >> > >> Bob. > >> > >> > >> > >> On Jan 22, 2019, at 10:19 PM, Ao Qi wrote: > >> > >> On Wed, Jan 23, 2019 at 10:55 AM David Holmes wrote: > >> > >> > >> On 23/01/2019 11:58 am, Ao Qi wrote: > >> > >> Hi David, > >> > >> On Wed, Jan 23, 2019 at 5:24 AM David Holmes wrote: > >> > >> > >> cc'ing Bob as our containers expert ... > >> > >> On 23/01/2019 1:10 am, Ao Qi wrote: > >> > >> Hi, > >> > >> --cpus is available in Docker 1.13 and higher [1], so > >> runtime/containers/docker/TestCPUAwareness.java failed in docker which > >> does not support --cpus. > >> > >> Webrev: http://cr.openjdk.java.net/~aoqi/docker/webrev.00/ > >> > >> This patch skips the test if --cpus is not supported. I tested > >> runtime/containers/docker/TestCPUAwareness.java on a Fedora 25 (Docker > >> version 1.12.6, build ae7d637/1.12.6, not supporting --cpus) and > >> Ubuntu 16.04 (Docker version 17.03.2-ce, build f5ec1e2, supporting > >> --cpus) > >> > >> > >> The patch causes the test to pass if launching Docker fails for any > >> reason so that is not good. > >> > >> > >> I tested two versions of docker which does not support --cpus. Their > >> exit values when using --cpus are 2 and 125, and outputs are: > >> > >> flag provided but not defined: --cpus > >> See 'docker run --help'. > >> > >> and > >> > >> unknown flag: --cpus > >> See 'docker run --help'. > >> > >> My initial thought was that the else condition of > >> "output.getExitValue() == 0" should match the condition of "--cpus not > >> supported". Firstly I used output.shouldMatch("docker run --help"), > >> but I am not sure if all the docker version behaves this way when > >> --cpus is not supported and "docker run --help" does not certainly > >> indicate "--cpus not supported", so I removed the else condition. > >> > >> > >> I think we need to try and find a way to clearly identifyt eh failing > >> condition. Is there are "docker --version" we coudl check? > >> > >> > >> I will do more research. Checking docker version may be one option, > >> and checking whether one option is support by docker may be also one > >> option. I will try them later, while waiting if there are some other > >> opinions :) > >> > >> I am not sure if this is a testbug, so I did not file it on JBS. In > >> fact, I am not quite sure what kind of issue can be filed on JBS. Is > >> there any guidance document? > >> > >> > >> Any/all issues can be filed on JBS. You don't need to pre-classify as a > >> testbug, simple create an issue that a test is failing under specific > >> conditions. Whomever works on the bug will then determine whether it is > >> a testbug or product issue or something else. (We don't seem to have any > >> docs on using JBS ...) > >> > >> > >> What if the issue is not a bug or no body cares the issue? The issue > >> will be open on JBS forever? > >> > >> > >> Possibly :) But each component team performs regular triage of the bugs > >> that get filed and eventually things will be examined enough to see if > >> they are indeed a bug, and if not they will be closed as not an issue. > >> If a bug but low priority it may eventually get closed as "will not fix" > >> just to keep the open bug count down. > >> > >> > >> I was a little afraid that filing issues that are not bugs or nobody > >> cares would increase the workload of others and frustrate myself, so I > >> was not sure what kind of issue should be filed. Now I basically > >> clear, thanks David. > >> > >> Cheers, > >> David > >> > >> Thanks for your explanation, and I filed this issue on JBS: > >> https://bugs.openjdk.java.net/browse/JDK-8217597 > >> > >> In this case I'm not sure whether we require a docker version that > >> supports --cpus, and the test should be skipped otherwise. Though > >> ideally this would involve an explicit version check so we don't just > >> pass if the docker process fails. > >> > >> Thanks, > >> David > >> > >> > >> > >> Cheers, > >> Ao Qi > >> > >> [1] https://docs.docker.com/config/containers/resource_constraints/#cpu > >> > >> > >> > From bob.vandette at oracle.com Thu Jan 31 16:30:23 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Thu, 31 Jan 2019 11:30:23 -0500 Subject: [TESTBUG] runtime/containers/docker/TestCPUAwareness.java failed in docker not supporting --cpus In-Reply-To: References: <420d2b08-86df-d591-35c9-d359a8811e9c@oracle.com> <3ABBCD75-1515-4B83-9FC1-18C737FD7C99@oracle.com> <6C6F3704-041B-4940-87E5-A73AB0808847@oracle.com> Message-ID: I?m not a ?R? reviewer but I?m ok with your change. Bob. > On Jan 31, 2019, at 11:00 AM, Ao Qi wrote: > > I leave the change, and update copyright year: > http://cr.openjdk.java.net/~aoqi/8217597/webrev.02/ Could you help to > review this? > > Thanks, > Ao Qi > > On Thu, Jan 31, 2019 at 10:08 PM Bob Vandette wrote: >> >> Yes, that does provide a bit more unique testing so leave the change as you had it. >> >> Thanks, >> Bob. >> >>> On Jan 28, 2019, at 8:41 PM, Ao Qi wrote: >>> >>> Hi Bob, >>> >>> Thanks! I am not a containers expert and have one small question. The >>> maximum amount of --cpus is 4 (equivalent to both setting ?cpu-period >>> and ?cpu-quota) in the already existing test. Is it valuable to keep >>> testCpus(i, i) according to the max num of available CPUs? If not, I >>> would also prefer removing the lines. In addition, I think I forgot to >>> update the copyright year, it will be fixed in the next version of >>> wevrev. >>> >>> On Mon, Jan 28, 2019 at 11:35 PM Bob Vandette wrote: >>>> >>>> There is already a test that verifies ?cpu-period and ?cpu-quota. >>>> I would just remove these lines. >>>> >>>> 62 // leave one CPU for system and tools, otherwise this test may be unstable >>>> 63 int maxNrOfAvailableCpus = availableCPUs - 1; >>>> 64 for (int i=1; i < maxNrOfAvailableCpus; i = i * 2) { >>>> 65 testCpus(i, i); >>>> 66 } >>>> >>>> 129 private static void testCpus(int valueToSet, int expectedTraceValue) throws Exception { >>>> 130 Common.logNewTestCase("test cpus: " + valueToSet); >>>> 131 DockerRunOptions opts = Common.newOpts(imageName) >>>> 132 .addDockerOpts("--cpus", "" + valueToSet); >>>> 133 Common.run(opts) >>>> 134 .shouldMatch("active_processor_count.*" + expectedTraceValue); >>>> 135 } >>>> >>>> Bob. >>>> >>>> On Jan 28, 2019, at 10:22 AM, Ao Qi wrote: >>>> >>>> Hi, >>>> >>>> Since ?cpus is a shortcut for of setting both --cpu-period and >>>> --cpu-quota and the test is not intended to verify that docker works >>>> correctly, I did not check the docker version and just replaced >>>> setting --cpus with setting both --cpu-period and --cpu-quota. What do >>>> you think of this patch: >>>> http://cr.openjdk.java.net/~aoqi/8217597/webrev.01/ ? >>>> >>>> Cheers, >>>> Ao Qi >>>> >>>> >>>> On Wed, Jan 23, 2019 at 11:37 PM Bob Vandette wrote: >>>> >>>> >>>> Since ?cpus is just a shortcut for of setting both --cpu-period and --cpu-quota?, I?d >>>> be ok with removing this test. The tests are intended to test the container/cgroup >>>> configuration detection logic and not to verify that docker works correctly. >>>> >>>> An alternate solution would be to add version detection to the Docker test check in >>>> DockerTestUtils.java . We already exec ?docker ps? to see if docker is available >>>> and enabled. >>>> >>>> % docker --version >>>> Docker version 17.03.1-ce, build 276fd32 >>>> >>>> >>>> Bob. >>>> >>>> >>>> >>>> On Jan 22, 2019, at 10:19 PM, Ao Qi wrote: >>>> >>>> On Wed, Jan 23, 2019 at 10:55 AM David Holmes wrote: >>>> >>>> >>>> On 23/01/2019 11:58 am, Ao Qi wrote: >>>> >>>> Hi David, >>>> >>>> On Wed, Jan 23, 2019 at 5:24 AM David Holmes wrote: >>>> >>>> >>>> cc'ing Bob as our containers expert ... >>>> >>>> On 23/01/2019 1:10 am, Ao Qi wrote: >>>> >>>> Hi, >>>> >>>> --cpus is available in Docker 1.13 and higher [1], so >>>> runtime/containers/docker/TestCPUAwareness.java failed in docker which >>>> does not support --cpus. >>>> >>>> Webrev: http://cr.openjdk.java.net/~aoqi/docker/webrev.00/ >>>> >>>> This patch skips the test if --cpus is not supported. I tested >>>> runtime/containers/docker/TestCPUAwareness.java on a Fedora 25 (Docker >>>> version 1.12.6, build ae7d637/1.12.6, not supporting --cpus) and >>>> Ubuntu 16.04 (Docker version 17.03.2-ce, build f5ec1e2, supporting >>>> --cpus) >>>> >>>> >>>> The patch causes the test to pass if launching Docker fails for any >>>> reason so that is not good. >>>> >>>> >>>> I tested two versions of docker which does not support --cpus. Their >>>> exit values when using --cpus are 2 and 125, and outputs are: >>>> >>>> flag provided but not defined: --cpus >>>> See 'docker run --help'. >>>> >>>> and >>>> >>>> unknown flag: --cpus >>>> See 'docker run --help'. >>>> >>>> My initial thought was that the else condition of >>>> "output.getExitValue() == 0" should match the condition of "--cpus not >>>> supported". Firstly I used output.shouldMatch("docker run --help"), >>>> but I am not sure if all the docker version behaves this way when >>>> --cpus is not supported and "docker run --help" does not certainly >>>> indicate "--cpus not supported", so I removed the else condition. >>>> >>>> >>>> I think we need to try and find a way to clearly identifyt eh failing >>>> condition. Is there are "docker --version" we coudl check? >>>> >>>> >>>> I will do more research. Checking docker version may be one option, >>>> and checking whether one option is support by docker may be also one >>>> option. I will try them later, while waiting if there are some other >>>> opinions :) >>>> >>>> I am not sure if this is a testbug, so I did not file it on JBS. In >>>> fact, I am not quite sure what kind of issue can be filed on JBS. Is >>>> there any guidance document? >>>> >>>> >>>> Any/all issues can be filed on JBS. You don't need to pre-classify as a >>>> testbug, simple create an issue that a test is failing under specific >>>> conditions. Whomever works on the bug will then determine whether it is >>>> a testbug or product issue or something else. (We don't seem to have any >>>> docs on using JBS ...) >>>> >>>> >>>> What if the issue is not a bug or no body cares the issue? The issue >>>> will be open on JBS forever? >>>> >>>> >>>> Possibly :) But each component team performs regular triage of the bugs >>>> that get filed and eventually things will be examined enough to see if >>>> they are indeed a bug, and if not they will be closed as not an issue. >>>> If a bug but low priority it may eventually get closed as "will not fix" >>>> just to keep the open bug count down. >>>> >>>> >>>> I was a little afraid that filing issues that are not bugs or nobody >>>> cares would increase the workload of others and frustrate myself, so I >>>> was not sure what kind of issue should be filed. Now I basically >>>> clear, thanks David. >>>> >>>> Cheers, >>>> David >>>> >>>> Thanks for your explanation, and I filed this issue on JBS: >>>> https://bugs.openjdk.java.net/browse/JDK-8217597 >>>> >>>> In this case I'm not sure whether we require a docker version that >>>> supports --cpus, and the test should be skipped otherwise. Though >>>> ideally this would involve an explicit version check so we don't just >>>> pass if the docker process fails. >>>> >>>> Thanks, >>>> David >>>> >>>> >>>> >>>> Cheers, >>>> Ao Qi >>>> >>>> [1] https://docs.docker.com/config/containers/resource_constraints/#cpu >>>> >>>> >>>> >> From thomas.stuefe at gmail.com Thu Jan 31 16:39:32 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 31 Jan 2019 17:39:32 +0100 Subject: RFR(T): 8218156: "jcmd VM.metaspace basic" misreports free chunk space Message-ID: Greetings, may I please have reviews for this simple fix: cr: http://cr.openjdk.java.net/~aleonard/8217896/webrev.01/ bug: https://bugs.openjdk.java.net/browse/JDK-8218156 Thank you. Best Regards, Thomas From thomas.stuefe at gmail.com Thu Jan 31 16:41:49 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 31 Jan 2019 17:41:49 +0100 Subject: RFR(T): 8218156: "jcmd VM.metaspace basic" misreports free chunk space In-Reply-To: References: Message-ID: Sorry, wrong cr link. http://cr.openjdk.java.net/~stuefe/webrevs/8218156--%22jcmd-vm.metaspace-basic%22-misreports-free-chunk-space/webrev.00/webrev/ On Thu, Jan 31, 2019 at 5:39 PM Thomas St?fe wrote: > Greetings, > > may I please have reviews for this simple fix: > > cr: http://cr.openjdk.java.net/~aleonard/8217896/webrev.01/ > bug: https://bugs.openjdk.java.net/browse/JDK-8218156 > > Thank you. > > Best Regards, Thomas > From zgu at redhat.com Thu Jan 31 16:58:56 2019 From: zgu at redhat.com (zgu at redhat.com) Date: Thu, 31 Jan 2019 11:58:56 -0500 Subject: RFR(T): 8218156: "jcmd VM.metaspace basic" misreports free chunk space In-Reply-To: References: Message-ID: <1548953936.31327.131.camel@redhat.com> Looks good and trivial. Thanks, -Zhengyu On Thu, 2019-01-31 at 17:41 +0100, Thomas St?fe wrote: > Sorry, wrong cr link. > > http://cr.openjdk.java.net/~stuefe/webrevs/8218156--%22jcmd-vm.metasp > ace-basic%22-misreports-free-chunk-space/webrev.00/webrev/ > > > > On Thu, Jan 31, 2019 at 5:39 PM Thomas St?fe > > wrote: > > > Greetings, > > > > may I please have reviews for this simple fix: > > > > cr: http://cr.openjdk.java.net/~aleonard/8217896/webrev.01/ > > bug: https://bugs.openjdk.java.net/browse/JDK-8218156 > > > > Thank you. > > > > Best Regards, Thomas > > From thomas.stuefe at gmail.com Thu Jan 31 17:08:34 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 31 Jan 2019 18:08:34 +0100 Subject: RFR(T): 8218156: "jcmd VM.metaspace basic" misreports free chunk space In-Reply-To: <1548953936.31327.131.camel@redhat.com> References: <1548953936.31327.131.camel@redhat.com> Message-ID: Thank you! On Thu, Jan 31, 2019 at 5:58 PM wrote: > Looks good and trivial. > > Thanks, > > -Zhengyu > > On Thu, 2019-01-31 at 17:41 +0100, Thomas St?fe wrote: > > Sorry, wrong cr link. > > > > http://cr.openjdk.java.net/~stuefe/webrevs/8218156--%22jcmd-vm.metasp > > ace-basic%22-misreports-free-chunk-space/webrev.00/webrev/ > > > > > > > > On Thu, Jan 31, 2019 at 5:39 PM Thomas St?fe > > > > wrote: > > > > > Greetings, > > > > > > may I please have reviews for this simple fix: > > > > > > cr: http://cr.openjdk.java.net/~aleonard/8217896/webrev.01/ > > > bug: https://bugs.openjdk.java.net/browse/JDK-8218156 > > > > > > Thank you. > > > > > > Best Regards, Thomas > > > > From coleen.phillimore at oracle.com Thu Jan 31 18:19:18 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 31 Jan 2019 13:19:18 -0500 Subject: RFR (S) 8215505: Cleanup jvm.cpp obsolete code after JDK-8210094: Better loading of classloader classes Message-ID: <8521cb54-092f-7a12-4b6c-070c8e15758b@oracle.com> Summary: remove dead code, also remove function that is not needed after 8210094. Because classes are not unloaded until their initiating class is unloaded, the protection domain of the initiating class can not become unreferenced, so the cleanup that was removed is not necessary. Tested with tier1,2? and test/hotspot/jtreg/runtime/Dictionary/ClassForName.java for the case testing why this was added for bug https://bugs.openjdk.java.net/browse/JDK-8175249. open webrev at http://cr.openjdk.java.net/~coleenp/2019/8215505.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8215505 Thanks, Coleen From lois.foltan at oracle.com Thu Jan 31 18:23:32 2019 From: lois.foltan at oracle.com (Lois Foltan) Date: Thu, 31 Jan 2019 13:23:32 -0500 Subject: RFR (S) 8215505: Cleanup jvm.cpp obsolete code after JDK-8210094: Better loading of classloader classes In-Reply-To: <8521cb54-092f-7a12-4b6c-070c8e15758b@oracle.com> References: <8521cb54-092f-7a12-4b6c-070c8e15758b@oracle.com> Message-ID: Looks good! Lois On 1/31/2019 1:19 PM, coleen.phillimore at oracle.com wrote: > Summary: remove dead code, also remove function that is not needed > after 8210094. > > Because classes are not unloaded until their initiating class is > unloaded, the protection domain of the initiating class can not become > unreferenced, so the cleanup that was removed is not necessary. > > Tested with tier1,2? and > test/hotspot/jtreg/runtime/Dictionary/ClassForName.java for the case > testing why this was added for bug > https://bugs.openjdk.java.net/browse/JDK-8175249. > > open webrev at http://cr.openjdk.java.net/~coleenp/2019/8215505.01/webrev > bug link https://bugs.openjdk.java.net/browse/JDK-8215505 > > Thanks, > Coleen From coleen.phillimore at oracle.com Thu Jan 31 18:33:30 2019 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Thu, 31 Jan 2019 13:33:30 -0500 Subject: RFR (S) 8215505: Cleanup jvm.cpp obsolete code after JDK-8210094: Better loading of classloader classes In-Reply-To: References: <8521cb54-092f-7a12-4b6c-070c8e15758b@oracle.com> Message-ID: <3aa68cdc-500f-2a42-fde7-7f4d07974be7@oracle.com> Thanks, Lois! Coleen On 1/31/19 1:23 PM, Lois Foltan wrote: > Looks good! > Lois > > On 1/31/2019 1:19 PM, coleen.phillimore at oracle.com wrote: >> Summary: remove dead code, also remove function that is not needed >> after 8210094. >> >> Because classes are not unloaded until their initiating class is >> unloaded, the protection domain of the initiating class can not >> become unreferenced, so the cleanup that was removed is not necessary. >> >> Tested with tier1,2? and >> test/hotspot/jtreg/runtime/Dictionary/ClassForName.java for the case >> testing why this was added for bug >> https://bugs.openjdk.java.net/browse/JDK-8175249. >> >> open webrev at >> http://cr.openjdk.java.net/~coleenp/2019/8215505.01/webrev >> bug link https://bugs.openjdk.java.net/browse/JDK-8215505 >> >> Thanks, >> Coleen >