From suenaga at oss.nttdata.com Thu Apr 1 00:16:45 2021 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Thu, 1 Apr 2021 09:16:45 +0900 Subject: Request For Comment: Asynchronous Logging In-Reply-To: References: Message-ID: Hi, On 2021/04/01 4:10, Thomas St?fe wrote: > Hi Volker, > > Excellent summary. Thank you for starting the design discussion away from the PR thread at GH. I think this is a better place for this discussion. > > I think UL had been missing a feature like this. I think we should provide it. Different people have come forward with the same idea in the past, so I believe there is a real need. > > You captured all points succinctly and prepared the discussion well. My remarks are inline (where I don't write one I agree). > > On Tue, Mar 30, 2021 at 8:19 PM Volker Simonis > wrote: > > Hi, > > I'd like to (re)start a discussion on asynchronous logging [1,2,3,4]. > We are successfully using this feature productively at Amazon both in > jdk8 and jdk11 to reduce the tail latency of services which use > logging. We think that async logging is a useful addition to the > current logging framework which might be beneficial to a wider range > of users. The following write-up tries to capture the comments and > suggestions from the previous discussions we are aware of. > > Current state: > > - HotSpot uses the so called "Unified Logging" (UL) framework which > was introduced by JEP 158 [5] in JDK 9. Most logs have been > retrofitted to use UL since then (e.g. "JEP 271: Unified GC Logging" > [6]). > - The current UL implementation is based on the standard C buffered > stream I/O interface [7]. The LogFileStreamOutput class which writes > logs to abstract FILE streams is the only child of the abstract base > class LogOutput. LogFileStreamOutput has three child classes > LogStdoutOutput,? LogStderrOutput and LogFileOutput which write to > stdout, stderr or an arbitrary file respectively. The initial UL JEP > 158 [5] envisioned logging to a socket but has not implemented it. At > least one such extension has been proposed since then [8]. > - UL synchronizes logs from different threads with the help of the > standard C flockfile()/funlockfile() [9] functions. But even without > this explicit locking, all the "stdio functions are thread-safe. This > is achieved by assigning to each FILE object a lockcount and (if the > lockcount is nonzero) an owning thread.? For each library call, these > functions wait until the FILE object is no longer locked by a > different thread, then lock it, do the requested I/O, and unlock the > object again" [9]. A quick look at the glibc sources reveals that FILE > locking is implemented with the help of futex() [10] which breaks down > to s simple atomic compare and swap (CAS) on the fast path. > - Notice that UL "synchronizes" logs from different threads to avoid > log interleaving. But it does not "serialize" logs according to the > time at which? they occurred. This is because the underlying stdio > functions do not guarantee a specific order for different threads > waiting on a locked FILE stream. E.g. if three log events A, B, C > occur in that order, the first will lock the output stream. If the log > events B and C both arrive while the stream is locked, it is > unspecified which of B and C will be logged first after A releases the > lock. > > Problem statement: > > - The amount of time a log event will block its FILE stream depends on > the underlying file system. This can range from a few nanoseconds for > in-memory file systems or milliseconds for physical discs under heavy > load up to several seconds in the worst case scenario for e.g. network > file systems. A blocked log output stream will block all concurrent > threads which try to write log messages at the same time. If logging > is done during a safepoint, this can significantly increase the > safepoint time (e.g. several parallel GC threads trying to log at the > same time). We can treat stdout/stderr as special files here without > loss of generality. > > Proposed solution: > > Extend UL with an asynchronous logging facility. Asynchronous logging > will be optional and disabled by default. It should have the following > properties: > - If disabled (the default) asynchronous logging should have no > observable impact on logging. > > > Additionally, if disabled, it should not cost anything. If enabled, it should cost as little as possible (eg. if logging is enabled but nobody logs). > > - If enabled, log messages will be stored in an intermediate data > structure (e.g. a double ended queue). > - A service thread will concurrently read and remove log messages from > that data structure in a FIFO style and write them to the output > stream > - Storing log messages in the intermediate data structure should take > constant time and not longer than logging a message takes in the > traditional UL system (in general the time should be much shorter > because the actual I/O is deferred). > - Asynchronous logging trades memory overhead (i.e. the size of the > intermediate data structure) for log accuracy. This means that in the > unlikely case where the service thread which does the asynchronous > logging falls behind the log producing threads, some logs might be > lost. However, the probability for this to happen can be minimized by > increasing the configurable size of the intermediate data structure. > - The final output produced by asynchronous logging should be equal to > the output from normal logging if no messages had to be dropped. > > > +1. This means decorators have to be resolved at the log site, not in the flusher. > > Notice that in contrast to the traditional unified logging, > asynchronous logging will give us the possibility to not only > synchronize log events, but to optionally also serialize them based on > their generation time if that's desired. This is because we are in > full control of the synchronization primitives for the intermediate > data structure which stores the logs. > > - If log messages had to be dropped, this should be logged in the log > output (e.g. "[..] 42 messages dropped due to async logging") > - Asynchronous logging should ideally be implemented in such a way > that it can be easily adapted by alternative log targets like for > example sockets in the future. > > > Additional requests: > - no log output should be withheld in case of vm exit or crash > - no log output should be unreasonably delayed > - The logger side should use as little VM infrastructure as possible to prevent circularity. > > > Alternative solutions: > - It has repeatedly been suggested to place the log files into a > memory file system but we don't think this is an optimal solution. > Main memory is often a constrained resource and we don't want log > files to compete with the JVM for it in such cases. > - It has also been argued to place the log files on a fast file system > which is only used for logging but in containerized environments file > system are often virtualized and the properties of the underlying > physical devices are not obvious. > - The load on the file system might be unpredictable due to other > applications on the same host. > - All these workarounds won't work if we eventually implement direct > logging to a network socket as suggested in [8]. > > Implementation details / POC: > > - A recent pull request [2] for JDK-8229517 [3] proposed to use a > simple deque implementation derived from HotSpot's LinkedListImpl > class for the intermediate data structure. It synchronizes access to > the queue with a MutexLocker which is internally implemented with > pthread_lock() and results in an atomic CAS on the fast path. So > performance-wise the locking itself is not different from the > flockfile()/funlockfile() functionality currently used by UL but > adding a log message to the deque should be constant as it basically > only requires a strdup(). And we could even eliminate the strdup() if > we'd pre-allocate a big enough array for holding the log messages as > proposed in the pull request [2]. > > > IIUC to be equivalent to flockfile the implementation would have to use one queue and one mutex *per file sink*, not a global queue/mutex as the patch proposed. Because otherwise you now introduce synchronization between log sites logging into different files, which before did not affect each other. > > - The pull pull request [2] for JDK-8229517 [3] proposed to set the > async flag as an attribute of the Xlog option which feels more natural > because UL configuration is traditionally done within the Xlog option. > But we could just as well use a global -XX flag to enable async > logging? What are your preferences here? > > > I prefer to keep "async" a global option. I think we should expose as little freedom to the user as possible. I do not think there is a sensible scenario where one would wish to write to one file with async, to another file without async. Nevertheless, if we make this option target-specific this has to work, and perform, and be regression-tested in all its variations. Every option we roll out is a contract we have to fulfill. They find their way into all kinds of environments and user scripts, and once out there it is difficult to roll out incompatible changes. For instance,? there is no mechanism to deprecate a part of an option. We have a mechanism for deprecating normal VM options, but Xlog is not a? normal option. I don't like to keep "async" a global option because other -Xlog options (e.g. filecount) does not global. It might break consistency for -Xlog options. > I am concerned with keeping UL maintainable, and that means keeping the implementation malleable. The more implementation details we expose in the form of options and functionality, the more our hands are tied if we want to change the implementation later. E.g. the implementation of a target-specific async option has to be aware of the existence of targets, and would prevent implementation of this feature in a layer which does not know about targets (e.g. deep down in File IO code). > > - The pull pull request [2] for JDK-8229517 [3] (mis)uses the > WatcherThread as service thread to concurrently process the > intermediate data structure and write the log messages out to the log > stream. That should definitely be changed to an independent service > thread. > > > Yes. > > - The pull pull request [2] for JDK-8229517 [3] initially proposed > that the "service thread" runs at a fixed interval to dump log > messages to the log streams. But reviewers commented that this should > better happen either continuously or based on the filling level of the > intermediate data structure. What are your preferences here? > > > I'd say dump continuously. I like the "flush on filling level" idea even less than the idea of periodic flushes. I do not like trace systems which arbitrarily keep output from me and need a flush to spit everything out. Or omit the last n lines if the VM crashes. > > - What are your preferences on the configuration of the intermediate > data structure? Should it be configured based on the maximum number of > log messages it can store or rather on the total size of the stored > log messages? I think that for normal runs this distinction probably > won't make a big difference because the size of log messages will > probably be the same on average so "number of log messages" should > always be proportional to "total size of log mesages". > > > I prefer the configuration of the intermediate buffer to be as a memory size, not "number of entries". The latter does not carry any information (what entries? how large are they?). It also, again, exposes implementation details - in this case that there is a vector of entries. > > A memory size could initially, in a first implementation, translated roughly to deque size by just assuming an average log line length. Future implementations then have the freedom to change this, e.g. use a pre-allocated fixed sized buffer of the given length, or a more involved scheme. > > 1. Before diving into more implementation details, I'd first like to > reach a general consensus that asynchronous logging is a useful > feature that's worth while adding to HotSpot. > > 2. Once we agree on that, we should agree on the desired properties of > asynchronous logging. I've tried to collect a basic set in the > "Proposed solution" section. > > 3. If that's done as well, we can discuss various implementation > details and finally prepare new pull requests. > > Thank you and best regards, > Volker > > [1] https://bugs.openjdk.java.net/browse/JDK-8229517 > [2] https://github.com/openjdk/jdk/pull/3135 > [3] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-November/043427.html > [4] https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-August/039130.html > [5] https://openjdk.java.net/jeps/158 > [6] https://openjdk.java.net/jeps/271 > [7] https://man7.org/linux/man-pages/man3/stdio.3.html > [8] https://gist.github.com/YaSuenag/dacb6d94d8684915422232c7a08d5b5d > [9] https://man7.org/linux/man-pages/man3/flockfile.3.html > [10] https://man7.org/linux/man-pages/man2/futex.2.html > > > Thanks, Thomas From coleenp at openjdk.java.net Thu Apr 1 00:29:19 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 1 Apr 2021 00:29:19 GMT Subject: RFR: 8264285: Clean the modification of ccstr JVM flags [v2] In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 19:02:02 GMT, Ioi Lam wrote: >> src/hotspot/share/runtime/flags/debug_globals.hpp line 38: >> >>> 36: // have any MANAGEABLE flags of the ccstr type, but we really need to >>> 37: // make sure the implementation is correct (in terms of memory allocation) >>> 38: // just in case someone may add such a flag in the future. >> >> Could you have just added a develop flag to the manageable flags instead? > > I had to use a `product` flag due to the following code, which should have been removed as part of [JDK-8243208](https://bugs.openjdk.java.net/browse/JDK-8243208), but I was afraid to do so because I didn't have a test case. I.e., all of our diagnostic/manageable/experimental flags were `product` flags. > > With this PR, now I have a test case -- I changed `DummyManageableStringFlag` to a `notproduct` flag, and removed the following code. I am re-running tiers1-4 now. > > void JVMFlag::check_all_flag_declarations() { > for (JVMFlag* current = &flagTable[0]; current->_name != NULL; current++) { > int flags = static_cast(current->_flags); > // Backwards compatibility. This will be relaxed/removed in JDK-7123237. > int mask = JVMFlag::KIND_DIAGNOSTIC | JVMFlag::KIND_MANAGEABLE | JVMFlag::KIND_EXPERIMENTAL; > if ((flags & mask) != 0) { > assert((flags & mask) == JVMFlag::KIND_DIAGNOSTIC || > (flags & mask) == JVMFlag::KIND_MANAGEABLE || > (flags & mask) == JVMFlag::KIND_EXPERIMENTAL, > "%s can be declared with at most one of " > "DIAGNOSTIC, MANAGEABLE or EXPERIMENTAL", current->_name); > assert((flags & KIND_NOT_PRODUCT) == 0 && > (flags & KIND_DEVELOP) == 0, > "%s has an optional DIAGNOSTIC, MANAGEABLE or EXPERIMENTAL " > "attribute; it must be declared as a product flag", current->_name); > } > } > } What's the difference between notproduct and develop again? Do we run tests with the optimized build and why would this flag be available in that build? ie. why not develop? ------------- PR: https://git.openjdk.java.net/jdk/pull/3254 From coleenp at openjdk.java.net Thu Apr 1 00:29:19 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 1 Apr 2021 00:29:19 GMT Subject: RFR: 8264285: Clean the modification of ccstr JVM flags [v2] In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 19:01:48 GMT, Ioi Lam wrote: >> There are two versions of JVMFlagAccess::ccstrAtPut() for modifying JVM flags of the ccstr type (i.e., strings). >> >> - One version requires the caller to free the old value, but some callers don't do that (writeableFlags.cpp). >> - The other version frees the old value on behalf of the caller. However, this version is accessible only via FLAG_SET_XXX macros and is currently unused. So it's unclear whether it actually works. >> >> We should combine these two versions into a single function, fix problems in the callers, and add test cases. The old value should be freed automatically, because typically the caller isn't interested in the old value. >> >> Note that the FLAG_SET_XXX macros do not return the old value. Requiring the caller of FLAG_SET_XXX to free the old value would be tedious and error prone. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > relax flag attributions (ala JDK-7123237) Marked as reviewed by coleenp (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3254 From coleenp at openjdk.java.net Thu Apr 1 02:11:38 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 1 Apr 2021 02:11:38 GMT Subject: RFR: 8264150: CDS dumping code calls TRAPS functions in VM thread Message-ID: This change initializes the vtables/itables without checking constraints. After initializing but before the class is visible in the SystemDictionary, constraints are checked in a separate loop. Tested with tier1-6 which includes jck tests. ------------- Commit messages: - 8264150: CDS dumping code calls TRAPS functions in VM thread Changes: https://git.openjdk.java.net/jdk/pull/3277/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3277&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264150 Stats: 290 lines in 10 files changed: 146 ins; 84 del; 60 mod Patch: https://git.openjdk.java.net/jdk/pull/3277.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3277/head:pull/3277 PR: https://git.openjdk.java.net/jdk/pull/3277 From iklam at openjdk.java.net Thu Apr 1 04:31:26 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 1 Apr 2021 04:31:26 GMT Subject: RFR: 8264285: Clean the modification of ccstr JVM flags [v2] In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 00:25:53 GMT, Coleen Phillimore wrote: >> I had to use a `product` flag due to the following code, which should have been removed as part of [JDK-8243208](https://bugs.openjdk.java.net/browse/JDK-8243208), but I was afraid to do so because I didn't have a test case. I.e., all of our diagnostic/manageable/experimental flags were `product` flags. >> >> With this PR, now I have a test case -- I changed `DummyManageableStringFlag` to a `notproduct` flag, and removed the following code. I am re-running tiers1-4 now. >> >> void JVMFlag::check_all_flag_declarations() { >> for (JVMFlag* current = &flagTable[0]; current->_name != NULL; current++) { >> int flags = static_cast(current->_flags); >> // Backwards compatibility. This will be relaxed/removed in JDK-7123237. >> int mask = JVMFlag::KIND_DIAGNOSTIC | JVMFlag::KIND_MANAGEABLE | JVMFlag::KIND_EXPERIMENTAL; >> if ((flags & mask) != 0) { >> assert((flags & mask) == JVMFlag::KIND_DIAGNOSTIC || >> (flags & mask) == JVMFlag::KIND_MANAGEABLE || >> (flags & mask) == JVMFlag::KIND_EXPERIMENTAL, >> "%s can be declared with at most one of " >> "DIAGNOSTIC, MANAGEABLE or EXPERIMENTAL", current->_name); >> assert((flags & KIND_NOT_PRODUCT) == 0 && >> (flags & KIND_DEVELOP) == 0, >> "%s has an optional DIAGNOSTIC, MANAGEABLE or EXPERIMENTAL " >> "attribute; it must be declared as a product flag", current->_name); >> } >> } >> } > > What's the difference between notproduct and develop again? Do we run tests with the optimized build and why would this flag be available in that build? ie. why not develop? >From the top of globals.hpp: - `develop` flags are settable / visible only during development and are constant in the PRODUCT version - `notproduct` flags are settable / visible only during development and are not declared in the PRODUCT version Since this flag is only used in test cases, and specifically for modifying its value, it doesn't make sense to expose this flag to the PRODUCT version at all. So I chose `notproduct`, so we can save a few bytes for the PRODUCT as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/3254 From dholmes at openjdk.java.net Thu Apr 1 04:56:28 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 1 Apr 2021 04:56:28 GMT Subject: RFR: 8264150: CDS dumping code calls TRAPS functions in VM thread In-Reply-To: References: Message-ID: <0pLA3mqjez1hR9bG5z5D9wCWvo3JGFvN6S6HyT3uRsI=.156eafb0-c895-40ee-a46c-f68e2f013ca0@github.com> On Tue, 30 Mar 2021 22:25:06 GMT, Coleen Phillimore wrote: > This change initializes the vtables/itables without checking constraints. After initializing but before the class is visible in the SystemDictionary, constraints are checked in a separate loop. > > Tested with tier1-6 which includes jck tests. Thanks for fixing this one Coleen! The refactoring was a bit more extensive than I had envisaged but the end result looks good. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3277 From iklam at openjdk.java.net Thu Apr 1 05:12:22 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 1 Apr 2021 05:12:22 GMT Subject: RFR: 8259070: Add jcmd option to dump CDS [v8] In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 20:58:46 GMT, Yumin Qi wrote: >> Hi, Please review >> >> Added jcmd option for dumping CDS archive during application runtime. Before this change, user has to dump shared archive in two steps: first run application with >> `java -XX:DumpLoadedClassList= .... ` >> to collect shareable class names and saved in file `` , then >> `java -Xshare:dump -XX:SharedClassListFile= -XX:SharedArchiveFile= ...` >> With this change, user can use jcmd to dump CDS without going through above steps. Also user can choose a moment during the app runtime to dump an archive. >> The bug is associated with the CSR: https://bugs.openjdk.java.net/browse/JDK-8259798 which has been approved. >> New added jcmd option: >> `jcmd VM.cds static_dump ` >> or >> `jcmd VM.cds dynamic_dump ` >> To dump dynamic archive, requires start app with newly added flag `-XX:+RecordDynamicDumpInfo`, with this flag, some information related to dynamic dump like loader constraints will be recorded. Note the dumping process changed some object memory locations so for dumping dynamic archive, can only done once for a running app. For static dump, user can dump multiple times against same process. >> The file name is optional, if the file name is not supplied, the file name will take format of `java_pid_static.jsa` or `java_pid_dynamic.jsa` for static and dynamic respectively. The `` is the application process ID. >> >> Tests: tier1,tier2,tier3,tier4 >> >> Thanks >> Yumin > > Yumin Qi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: > > - Fix revert unintentionally comment, merge master. > - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 > - Remove CDS.getVMArguments, changed to use VM.getRuntimeVMArguments. Removed unused function from ClassLoader. Improved InstanceKlass::is_shareable() and related test. Added more test scenarios. > - Remove redundant check for if a class is shareable > - Fix according to review comment and add more tests > - Fix filter more flags to exclude in static dump, add more test cases > - Merge branch 'master' into jdk-8259070 > - Fix white space in CDS.java > - Add function CDS.dumpSharedArchive in java to dump shared archive > - 8259070: Add jcmd option to dump CDS Changes requested by iklam (Reviewer). src/hotspot/share/services/diagnosticCommand.cpp line 1106: > 1104: output()->print_cr("Dynamic dump:"); > 1105: if (!UseSharedSpaces) { > 1106: output()->print_cr("CDS is not available for the JDK"); I think we should use a message similar to this: $ java -Xshare:off -XX:ArchiveClassesAtExit=xxx -version Error occurred during initialization of VM DynamicDumpSharedSpaces is unsupported when base CDS archive is not loaded How about "dynamic_dump is unsupported when base CDS archive is not loaded". src/hotspot/share/services/diagnosticCommand.cpp line 1125: > 1123: Symbol* cds_name = vmSymbols::jdk_internal_misc_CDS(); > 1124: Klass* cds_klass = SystemDictionary::resolve_or_fail(cds_name, true /*throw error*/, CHECK); > 1125: JavaValue result(T_OBJECT); Should be `result(T_VOID)` to match the signature of `CDS.dumpSharedArchive()` src/hotspot/share/services/diagnosticCommand.cpp line 1133: > 1131: vmSymbols::dumpSharedArchive(), > 1132: vmSymbols::dumpSharedArchive_signature(), > 1133: &args, THREAD); Should be `&args, CHECK);`. Recently, we have started to to avoid using `THREAD` if the callee function may throw an exception. src/java.base/share/classes/jdk/internal/misc/CDS.java line 218: > 216: try { > 217: PrintStream prt = new PrintStream(fileName); > 218: prt.println("Command:"); [Try-with-resources](https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html) should be used to make sure the streams are closed when the method exits (normally or on exception). try (InputStreamReader isr = new InputStreamReader(stream); BufferedReader rdr = new BufferedReader(isr); PrintStream prt = new PrintStream(fileName);) { prt.println("Command:"); .... src/java.base/share/classes/jdk/internal/misc/CDS.java line 307: > 305: outputStdStream(proc.getErrorStream(), stdErrFile, cmds); > 306: }).start(); > 307: I think the above code can be refactored to avoid duplication. Something like: String stdOutFile = drainOutput(proc.getInputStream(), "stdout"); String stdErrFile = drainOutput(proc.getErrorStream(), "stderr"); and move the common code into drainOutput(). ------------- PR: https://git.openjdk.java.net/jdk/pull/2737 From david.holmes at oracle.com Thu Apr 1 05:22:53 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 1 Apr 2021 15:22:53 +1000 Subject: RFR: 8264285: Clean the modification of ccstr JVM flags [v2] In-Reply-To: References: Message-ID: <928358f3-5976-8e60-dbf2-c647d8fe3e02@oracle.com> On 1/04/2021 5:05 am, Ioi Lam wrote: > On Wed, 31 Mar 2021 12:58:50 GMT, Coleen Phillimore wrote: > >>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >>> >>> relax flag attributions (ala JDK-7123237) >> >> src/hotspot/share/runtime/flags/debug_globals.hpp line 38: >> >>> 36: // have any MANAGEABLE flags of the ccstr type, but we really need to >>> 37: // make sure the implementation is correct (in terms of memory allocation) >>> 38: // just in case someone may add such a flag in the future. >> >> Could you have just added a develop flag to the manageable flags instead? > > I had to use a `product` flag due to the following code, which should have been removed as part of [JDK-8243208](https://bugs.openjdk.java.net/browse/JDK-8243208), but I was afraid to do so because I didn't have a test case. I.e., all of our diagnostic/manageable/experimental flags were `product` flags. > > With this PR, now I have a test case -- I changed `DummyManageableStringFlag` to a `notproduct` flag, and removed the following code. I am re-running tiers1-4 now. Sorry but I don't understand how a test involving one flag replaces a chunk of code that validated every flag declaration ?? David ----- > void JVMFlag::check_all_flag_declarations() { > for (JVMFlag* current = &flagTable[0]; current->_name != NULL; current++) { > int flags = static_cast(current->_flags); > // Backwards compatibility. This will be relaxed/removed in JDK-7123237. > int mask = JVMFlag::KIND_DIAGNOSTIC | JVMFlag::KIND_MANAGEABLE | JVMFlag::KIND_EXPERIMENTAL; > if ((flags & mask) != 0) { > assert((flags & mask) == JVMFlag::KIND_DIAGNOSTIC || > (flags & mask) == JVMFlag::KIND_MANAGEABLE || > (flags & mask) == JVMFlag::KIND_EXPERIMENTAL, > "%s can be declared with at most one of " > "DIAGNOSTIC, MANAGEABLE or EXPERIMENTAL", current->_name); > assert((flags & KIND_NOT_PRODUCT) == 0 && > (flags & KIND_DEVELOP) == 0, > "%s has an optional DIAGNOSTIC, MANAGEABLE or EXPERIMENTAL " > "attribute; it must be declared as a product flag", current->_name); > } > } > } > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3254 > From ioi.lam at oracle.com Thu Apr 1 05:29:59 2021 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 31 Mar 2021 22:29:59 -0700 Subject: RFR: 8264285: Clean the modification of ccstr JVM flags [v2] In-Reply-To: <928358f3-5976-8e60-dbf2-c647d8fe3e02@oracle.com> References: <928358f3-5976-8e60-dbf2-c647d8fe3e02@oracle.com> Message-ID: <8134d2f8-af9e-12ff-7381-62a91eeeec72@oracle.com> On 3/31/21 10:22 PM, David Holmes wrote: > On 1/04/2021 5:05 am, Ioi Lam wrote: >> On Wed, 31 Mar 2021 12:58:50 GMT, Coleen Phillimore >> wrote: >> >>> >>>> 36: // have any MANAGEABLE flags of the ccstr type, but we really >>>> need to >>>> 37: // make sure the implementation is correct (in terms of memory >>>> allocation) >>>> 38: // just in case someone may add such a flag in the future. >>> >>> Could you have just added a develop flag to the manageable flags >>> instead? >> >> I had to use a `product` flag due to the following code, which should >> have been removed as part of >> [JDK-8243208](https://bugs.openjdk.java.net/browse/JDK-8243208), but >> I was afraid to do so because I didn't have a test case. I.e., all of >> our diagnostic/manageable/experimental flags were `product` flags. >> >> With this PR, now I have a test case -- I changed >> `DummyManageableStringFlag` to a `notproduct` flag, and removed the >> following code. I am re-running tiers1-4 now. > > Sorry but I don't understand how a test involving one flag replaces a > chunk of code that validated every flag declaration ?? > When I did JDK-8243208, I wasn't sure if the VM would actually support diagnostic/manageable/experimental flags that were not `product`. So I added check_all_flag_declarations() to prevent anyone from adding such a flag "casually" without thinking about. Now that I have added such a flag, and I believe I have tested pretty thoroughly (tiers 1-4), I think the VM indeed supports these flags. So now I feel it's safe to remove check_all_flag_declarations(). Thanks - Ioi > David > ----- > >> void JVMFlag::check_all_flag_declarations() { >> ?? for (JVMFlag* current = &flagTable[0]; current->_name != NULL; >> current++) { >> ???? int flags = static_cast(current->_flags); >> ???? // Backwards compatibility. This will be relaxed/removed in >> JDK-7123237. >> ???? int mask = JVMFlag::KIND_DIAGNOSTIC | JVMFlag::KIND_MANAGEABLE | >> JVMFlag::KIND_EXPERIMENTAL; >> ???? if ((flags & mask) != 0) { >> ?????? assert((flags & mask) == JVMFlag::KIND_DIAGNOSTIC || >> ????????????? (flags & mask) == JVMFlag::KIND_MANAGEABLE || >> ????????????? (flags & mask) == JVMFlag::KIND_EXPERIMENTAL, >> ????????????? "%s can be declared with at most one of " >> ????????????? "DIAGNOSTIC, MANAGEABLE or EXPERIMENTAL", current->_name); >> ?????? assert((flags & KIND_NOT_PRODUCT) == 0 && >> ????????????? (flags & KIND_DEVELOP) == 0, >> ????????????? "%s has an optional DIAGNOSTIC, MANAGEABLE or >> EXPERIMENTAL " >> ????????????? "attribute; it must be declared as a product flag", >> current->_name); >> ???? } >> ?? } >> } >> >> ------------- >> >> PR: https://git.openjdk.java.net/jdk/pull/3254 >> From david.holmes at oracle.com Thu Apr 1 05:47:48 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 1 Apr 2021 15:47:48 +1000 Subject: RFR: 8264285: Clean the modification of ccstr JVM flags [v2] In-Reply-To: <8134d2f8-af9e-12ff-7381-62a91eeeec72@oracle.com> References: <928358f3-5976-8e60-dbf2-c647d8fe3e02@oracle.com> <8134d2f8-af9e-12ff-7381-62a91eeeec72@oracle.com> Message-ID: <56fca089-7f8b-1eff-e4cd-9eb1719c1c39@oracle.com> On 1/04/2021 3:29 pm, Ioi Lam wrote: > > > On 3/31/21 10:22 PM, David Holmes wrote: >> On 1/04/2021 5:05 am, Ioi Lam wrote: >>> On Wed, 31 Mar 2021 12:58:50 GMT, Coleen Phillimore >>> wrote: >>> >>>> >>>>> 36: // have any MANAGEABLE flags of the ccstr type, but we really >>>>> need to >>>>> 37: // make sure the implementation is correct (in terms of memory >>>>> allocation) >>>>> 38: // just in case someone may add such a flag in the future. >>>> >>>> Could you have just added a develop flag to the manageable flags >>>> instead? >>> >>> I had to use a `product` flag due to the following code, which should >>> have been removed as part of >>> [JDK-8243208](https://bugs.openjdk.java.net/browse/JDK-8243208), but >>> I was afraid to do so because I didn't have a test case. I.e., all of >>> our diagnostic/manageable/experimental flags were `product` flags. >>> >>> With this PR, now I have a test case -- I changed >>> `DummyManageableStringFlag` to a `notproduct` flag, and removed the >>> following code. I am re-running tiers1-4 now. >> >> Sorry but I don't understand how a test involving one flag replaces a >> chunk of code that validated every flag declaration ?? >> > > When I did JDK-8243208, I wasn't sure if the VM would actually support > diagnostic/manageable/experimental flags that were not `product`. So I > added check_all_flag_declarations() to prevent anyone from adding such a > flag "casually" without thinking about. > > Now that I have added such a flag, and I believe I have tested pretty > thoroughly (tiers 1-4), I think the VM indeed supports these flags. So > now I feel it's safe to remove check_all_flag_declarations(). But the check was checking two things: 1. That diagnostic/manageable/experimental are mutually exclusive 2. That they only apply to product flags I believe both of these rules still stand based on what we defined such attributes to mean. And even if you think #2 should not apply, #1 still does and so could still be checked. And if #2 is no longer our rule then the documentation in globals.hpp should be updated - though IMHO #2 should remain as-is. David ----- > Thanks > - Ioi > > > >> David >> ----- >> >>> void JVMFlag::check_all_flag_declarations() { >>> ?? for (JVMFlag* current = &flagTable[0]; current->_name != NULL; >>> current++) { >>> ???? int flags = static_cast(current->_flags); >>> ???? // Backwards compatibility. This will be relaxed/removed in >>> JDK-7123237. >>> ???? int mask = JVMFlag::KIND_DIAGNOSTIC | JVMFlag::KIND_MANAGEABLE | >>> JVMFlag::KIND_EXPERIMENTAL; >>> ???? if ((flags & mask) != 0) { >>> ?????? assert((flags & mask) == JVMFlag::KIND_DIAGNOSTIC || >>> ????????????? (flags & mask) == JVMFlag::KIND_MANAGEABLE || >>> ????????????? (flags & mask) == JVMFlag::KIND_EXPERIMENTAL, >>> ????????????? "%s can be declared with at most one of " >>> ????????????? "DIAGNOSTIC, MANAGEABLE or EXPERIMENTAL", current->_name); >>> ?????? assert((flags & KIND_NOT_PRODUCT) == 0 && >>> ????????????? (flags & KIND_DEVELOP) == 0, >>> ????????????? "%s has an optional DIAGNOSTIC, MANAGEABLE or >>> EXPERIMENTAL " >>> ????????????? "attribute; it must be declared as a product flag", >>> current->_name); >>> ???? } >>> ?? } >>> } >>> >>> ------------- >>> >>> PR: https://git.openjdk.java.net/jdk/pull/3254 >>> > From iklam at openjdk.java.net Thu Apr 1 06:08:52 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 1 Apr 2021 06:08:52 GMT Subject: RFR: 8264285: Clean the modification of ccstr JVM flags [v3] In-Reply-To: References: Message-ID: > There are two versions of JVMFlagAccess::ccstrAtPut() for modifying JVM flags of the ccstr type (i.e., strings). > > - One version requires the caller to free the old value, but some callers don't do that (writeableFlags.cpp). > - The other version frees the old value on behalf of the caller. However, this version is accessible only via FLAG_SET_XXX macros and is currently unused. So it's unclear whether it actually works. > > We should combine these two versions into a single function, fix problems in the callers, and add test cases. The old value should be freed automatically, because typically the caller isn't interested in the old value. > > Note that the FLAG_SET_XXX macros do not return the old value. Requiring the caller of FLAG_SET_XXX to free the old value would be tedious and error prone. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Revert "relax flag attributions (ala JDK-7123237)" This reverts commit 673aaafc4860dd7f70a3f222422ae84e85fd4219. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3254/files - new: https://git.openjdk.java.net/jdk/pull/3254/files/673aaafc..2a5e2b19 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3254&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3254&range=01-02 Stats: 37 lines in 4 files changed: 36 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3254.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3254/head:pull/3254 PR: https://git.openjdk.java.net/jdk/pull/3254 From ioi.lam at oracle.com Thu Apr 1 06:19:12 2021 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 31 Mar 2021 23:19:12 -0700 Subject: RFR: 8264285: Clean the modification of ccstr JVM flags [v2] In-Reply-To: <56fca089-7f8b-1eff-e4cd-9eb1719c1c39@oracle.com> References: <928358f3-5976-8e60-dbf2-c647d8fe3e02@oracle.com> <8134d2f8-af9e-12ff-7381-62a91eeeec72@oracle.com> <56fca089-7f8b-1eff-e4cd-9eb1719c1c39@oracle.com> Message-ID: On 3/31/21 10:47 PM, David Holmes wrote: > On 1/04/2021 3:29 pm, Ioi Lam wrote: >> >> >> On 3/31/21 10:22 PM, David Holmes wrote: >>> On 1/04/2021 5:05 am, Ioi Lam wrote: >>>> On Wed, 31 Mar 2021 12:58:50 GMT, Coleen Phillimore >>>> wrote: >>>> >>>>> >>>>>> 36: // have any MANAGEABLE flags of the ccstr type, but we really >>>>>> need to >>>>>> 37: // make sure the implementation is correct (in terms of >>>>>> memory allocation) >>>>>> 38: // just in case someone may add such a flag in the future. >>>>> >>>>> Could you have just added a develop flag to the manageable flags >>>>> instead? >>>> >>>> I had to use a `product` flag due to the following code, which >>>> should have been removed as part of >>>> [JDK-8243208](https://bugs.openjdk.java.net/browse/JDK-8243208), >>>> but I was afraid to do so because I didn't have a test case. I.e., >>>> all of our diagnostic/manageable/experimental flags were `product` >>>> flags. >>>> >>>> With this PR, now I have a test case -- I changed >>>> `DummyManageableStringFlag` to a `notproduct` flag, and removed the >>>> following code. I am re-running tiers1-4 now. >>> >>> Sorry but I don't understand how a test involving one flag replaces >>> a chunk of code that validated every flag declaration ?? >>> >> >> When I did JDK-8243208, I wasn't sure if the VM would actually >> support diagnostic/manageable/experimental flags that were not >> `product`. So I added check_all_flag_declarations() to prevent anyone >> from adding such a flag "casually" without thinking about. >> >> Now that I have added such a flag, and I believe I have tested pretty >> thoroughly (tiers 1-4), I think the VM indeed supports these flags. >> So now I feel it's safe to remove check_all_flag_declarations(). > > But the check was checking two things: > > 1. That diagnostic/manageable/experimental are mutually exclusive > 2. That they only apply to product flags > > I believe both of these rules still stand based on what we defined > such attributes to mean. And even if you think #2 should not apply, #1 > still does and so could still be checked. And if #2 is no longer our > rule then the documentation in globals.hpp should be updated - though > IMHO #2 should remain as-is. > I think neither #1 and #2 make sense. These were limitation introduced by the old flags implementation, where you had to declare a flag using one of these macros ??? diagnostic(type, name, .... ??? manageable(type, name, .... ??? experimental(type, name, .... That's why you have #1 (mutual exclusion). #2 was also due to the implementation. It makes no sense that you can't have an develop flag for an experimental feature. However, in the old implementation, adding more variations would cause macro explosion. See https://github.com/openjdk/jdk/blame/7d8519fffe46b6b5139b3aa51b18fcf0249a9e14/src/hotspot/share/runtime/flags/jvmFlag.cpp#L776 Anyway, changing this should be done in a separate RFE. I have reverted [v2] from this PR, so we are back to [v1]. Thanks - Ioi > David > ----- > > >> Thanks >> - Ioi >> >> >> >>> David >>> ----- >>> >>>> void JVMFlag::check_all_flag_declarations() { >>>> ?? for (JVMFlag* current = &flagTable[0]; current->_name != NULL; >>>> current++) { >>>> ???? int flags = static_cast(current->_flags); >>>> ???? // Backwards compatibility. This will be relaxed/removed in >>>> JDK-7123237. >>>> ???? int mask = JVMFlag::KIND_DIAGNOSTIC | JVMFlag::KIND_MANAGEABLE >>>> | JVMFlag::KIND_EXPERIMENTAL; >>>> ???? if ((flags & mask) != 0) { >>>> ?????? assert((flags & mask) == JVMFlag::KIND_DIAGNOSTIC || >>>> ????????????? (flags & mask) == JVMFlag::KIND_MANAGEABLE || >>>> ????????????? (flags & mask) == JVMFlag::KIND_EXPERIMENTAL, >>>> ????????????? "%s can be declared with at most one of " >>>> ????????????? "DIAGNOSTIC, MANAGEABLE or EXPERIMENTAL", >>>> current->_name); >>>> ?????? assert((flags & KIND_NOT_PRODUCT) == 0 && >>>> ????????????? (flags & KIND_DEVELOP) == 0, >>>> ????????????? "%s has an optional DIAGNOSTIC, MANAGEABLE or >>>> EXPERIMENTAL " >>>> ????????????? "attribute; it must be declared as a product flag", >>>> current->_name); >>>> ???? } >>>> ?? } >>>> } >>>> >>>> ------------- >>>> >>>> PR: https://git.openjdk.java.net/jdk/pull/3254 >>>> >> From iklam at openjdk.java.net Thu Apr 1 06:28:25 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 1 Apr 2021 06:28:25 GMT Subject: RFR: 8264150: CDS dumping code calls TRAPS functions in VM thread In-Reply-To: References: Message-ID: On Tue, 30 Mar 2021 22:25:06 GMT, Coleen Phillimore wrote: > This change initializes the vtables/itables without checking constraints. After initializing but before the class is visible in the SystemDictionary, constraints are checked in a separate loop. > > Tested with tier1-6 which includes jck tests. Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3277 From david.holmes at oracle.com Thu Apr 1 06:35:59 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 1 Apr 2021 16:35:59 +1000 Subject: RFR: 8264285: Clean the modification of ccstr JVM flags [v2] In-Reply-To: References: <928358f3-5976-8e60-dbf2-c647d8fe3e02@oracle.com> <8134d2f8-af9e-12ff-7381-62a91eeeec72@oracle.com> <56fca089-7f8b-1eff-e4cd-9eb1719c1c39@oracle.com> Message-ID: <131a0ea9-b491-f38e-d846-11af9db13897@oracle.com> On 1/04/2021 4:19 pm, Ioi Lam wrote: > > > On 3/31/21 10:47 PM, David Holmes wrote: >> On 1/04/2021 3:29 pm, Ioi Lam wrote: >>> >>> >>> On 3/31/21 10:22 PM, David Holmes wrote: >>>> On 1/04/2021 5:05 am, Ioi Lam wrote: >>>>> On Wed, 31 Mar 2021 12:58:50 GMT, Coleen Phillimore >>>>> wrote: >>>>> >>>>>> >>>>>>> 36: // have any MANAGEABLE flags of the ccstr type, but we really >>>>>>> need to >>>>>>> 37: // make sure the implementation is correct (in terms of >>>>>>> memory allocation) >>>>>>> 38: // just in case someone may add such a flag in the future. >>>>>> >>>>>> Could you have just added a develop flag to the manageable flags >>>>>> instead? >>>>> >>>>> I had to use a `product` flag due to the following code, which >>>>> should have been removed as part of >>>>> [JDK-8243208](https://bugs.openjdk.java.net/browse/JDK-8243208), >>>>> but I was afraid to do so because I didn't have a test case. I.e., >>>>> all of our diagnostic/manageable/experimental flags were `product` >>>>> flags. >>>>> >>>>> With this PR, now I have a test case -- I changed >>>>> `DummyManageableStringFlag` to a `notproduct` flag, and removed the >>>>> following code. I am re-running tiers1-4 now. >>>> >>>> Sorry but I don't understand how a test involving one flag replaces >>>> a chunk of code that validated every flag declaration ?? >>>> >>> >>> When I did JDK-8243208, I wasn't sure if the VM would actually >>> support diagnostic/manageable/experimental flags that were not >>> `product`. So I added check_all_flag_declarations() to prevent anyone >>> from adding such a flag "casually" without thinking about. >>> >>> Now that I have added such a flag, and I believe I have tested pretty >>> thoroughly (tiers 1-4), I think the VM indeed supports these flags. >>> So now I feel it's safe to remove check_all_flag_declarations(). >> >> But the check was checking two things: >> >> 1. That diagnostic/manageable/experimental are mutually exclusive >> 2. That they only apply to product flags >> >> I believe both of these rules still stand based on what we defined >> such attributes to mean. And even if you think #2 should not apply, #1 >> still does and so could still be checked. And if #2 is no longer our >> rule then the documentation in globals.hpp should be updated - though >> IMHO #2 should remain as-is. >> > > I think neither #1 and #2 make sense. These were limitation introduced > by the old flags implementation, where you had to declare a flag using > one of these macros > > ??? diagnostic(type, name, .... > ??? manageable(type, name, .... > ??? experimental(type, name, .... > > That's why you have #1 (mutual exclusion). > > #2 was also due to the implementation. It makes no sense that you can't > have an develop flag for an experimental feature. I don't agree with either of those claims. This is about semantics not implementation. diagnostic/manageable/experimental are distinct kinds of product flags with different levels of "support" based on their intended use in the product. We don't need such distinctions with non-product flags because the level of "support" is all the same and all flags are equal. David ----- > However, in the old implementation, adding more variations would cause > macro explosion. See > https://github.com/openjdk/jdk/blame/7d8519fffe46b6b5139b3aa51b18fcf0249a9e14/src/hotspot/share/runtime/flags/jvmFlag.cpp#L776 > > > Anyway, changing this should be done in a separate RFE. I have reverted > [v2] from this PR, so we are back to [v1]. > > Thanks > - Ioi > > >> David >> ----- >> >> >>> Thanks >>> - Ioi >>> >>> >>> >>>> David >>>> ----- >>>> >>>>> void JVMFlag::check_all_flag_declarations() { >>>>> ?? for (JVMFlag* current = &flagTable[0]; current->_name != NULL; >>>>> current++) { >>>>> ???? int flags = static_cast(current->_flags); >>>>> ???? // Backwards compatibility. This will be relaxed/removed in >>>>> JDK-7123237. >>>>> ???? int mask = JVMFlag::KIND_DIAGNOSTIC | JVMFlag::KIND_MANAGEABLE >>>>> | JVMFlag::KIND_EXPERIMENTAL; >>>>> ???? if ((flags & mask) != 0) { >>>>> ?????? assert((flags & mask) == JVMFlag::KIND_DIAGNOSTIC || >>>>> ????????????? (flags & mask) == JVMFlag::KIND_MANAGEABLE || >>>>> ????????????? (flags & mask) == JVMFlag::KIND_EXPERIMENTAL, >>>>> ????????????? "%s can be declared with at most one of " >>>>> ????????????? "DIAGNOSTIC, MANAGEABLE or EXPERIMENTAL", >>>>> current->_name); >>>>> ?????? assert((flags & KIND_NOT_PRODUCT) == 0 && >>>>> ????????????? (flags & KIND_DEVELOP) == 0, >>>>> ????????????? "%s has an optional DIAGNOSTIC, MANAGEABLE or >>>>> EXPERIMENTAL " >>>>> ????????????? "attribute; it must be declared as a product flag", >>>>> current->_name); >>>>> ???? } >>>>> ?? } >>>>> } >>>>> >>>>> ------------- >>>>> >>>>> PR: https://git.openjdk.java.net/jdk/pull/3254 >>>>> >>> > From shade at openjdk.java.net Thu Apr 1 06:57:31 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 1 Apr 2021 06:57:31 GMT Subject: RFR: 8058176: [mlvm] tests should not allow code cache exhaustion [v6] In-Reply-To: References: Message-ID: <41vRG3m7B1ypKxez-IEzb_tsRT4K1sSBoNpqgiOqg9c=.f72b0cef-abdd-4201-8579-69b32688b181@github.com> On Tue, 16 Mar 2021 16:16:09 GMT, Igor Ignatyev wrote: >> Evgeny Nikitin has updated the pull request incrementally with one additional commit since the last revision: >> >> Move a comment a bit higher > > Marked as reviewed by iignatyev (Reviewer). Are we integrating this? I thought to sponsor, but wanted to check if everyone is in agreement this change is fine. ------------- PR: https://git.openjdk.java.net/jdk/pull/2523 From coleenp at openjdk.java.net Thu Apr 1 11:40:28 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 1 Apr 2021 11:40:28 GMT Subject: RFR: 8264285: Clean the modification of ccstr JVM flags [v3] In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 06:08:52 GMT, Ioi Lam wrote: >> There are two versions of JVMFlagAccess::ccstrAtPut() for modifying JVM flags of the ccstr type (i.e., strings). >> >> - One version requires the caller to free the old value, but some callers don't do that (writeableFlags.cpp). >> - The other version frees the old value on behalf of the caller. However, this version is accessible only via FLAG_SET_XXX macros and is currently unused. So it's unclear whether it actually works. >> >> We should combine these two versions into a single function, fix problems in the callers, and add test cases. The old value should be freed automatically, because typically the caller isn't interested in the old value. >> >> Note that the FLAG_SET_XXX macros do not return the old value. Requiring the caller of FLAG_SET_XXX to free the old value would be tedious and error prone. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Revert "relax flag attributions (ala JDK-7123237)" > > This reverts commit 673aaafc4860dd7f70a3f222422ae84e85fd4219. src/hotspot/share/runtime/flags/debug_globals.hpp line 63: > 61: \ > 62: product(ccstr, DummyManageableStringFlag, NULL, MANAGEABLE, \ > 63: "Dummy flag for testing string handling in WriteableFlags") \ So this is in essence a product/manageable flag in debug only mode, which doesn't make sense at all, necessitating another macro that looks honestly bizarre. So I think that means a non-product manageable flag or even a develop manageable flag is something that we want, we want to be able to write a develop flag by the management interface. I agree diagnostic and experimental flags only seem to make sense as product flags. The doc could simply be updated. Also the doc at the top of this file refers to CCC which is no longer -> CSR. // MANAGEABLE flags are writeable external product flags. // They are dynamically writeable through the JDK management interface // (com.sun.management.HotSpotDiagnosticMXBean API) and also through JConsole. // These flags are external exported interface (see CCC). The list of // manageable flags can be queried programmatically through the management // interface. I'm not going to spend time typing about this minor point. The improvement is good and should be checked in. ------------- PR: https://git.openjdk.java.net/jdk/pull/3254 From hseigel at openjdk.java.net Thu Apr 1 12:28:29 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 1 Apr 2021 12:28:29 GMT Subject: RFR: 8264538: Rename SystemDictionary::parse_stream [v3] In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 21:41:39 GMT, Coleen Phillimore wrote: >> This function is used to call the classfile parser for hidden or anonymous classes, and for use with jvmti RedefineClasses. The latter only calls KlassFactory::create_from_stream and skips the rest of the code in SystemDictionary::parse_stream. >> >> Renamed SystemDictionary::parse_stream -> resolve_hidden_class_from_stream >> resolve_from_stream -> resolve_class_from_stream >> and have SystemDictionary::resolve_from_stream() call the right version depending on ClassLoadInfo flags. Callers of resolve_from_stream now pass protection domain via. ClassLoadInfo. >> >> So the external API is resolve_from_stream. >> >> Tested with tier1 on 4 Oracle supported platforms. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Add and remove comments. The changes look good! Thanks, Harold ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3289 From lfoltan at openjdk.java.net Thu Apr 1 13:48:22 2021 From: lfoltan at openjdk.java.net (Lois Foltan) Date: Thu, 1 Apr 2021 13:48:22 GMT Subject: RFR: 8264538: Rename SystemDictionary::parse_stream [v2] In-Reply-To: References: <5XkcECxtI-f304vVc6TXjJNXHA5kpzcHORV8q8mPvzk=.da25a174-4c29-4f5a-a639-695043a06067@github.com> Message-ID: On Wed, 31 Mar 2021 21:22:39 GMT, Coleen Phillimore wrote: >> src/hotspot/share/prims/jvm.cpp line 950: >> >>> 948: InstanceKlass* ik = NULL; >>> 949: if (!is_hidden) { >>> 950: ClassLoadInfo cl_info(protection_domain); >> >> Minor comment, you could pull the creation of ClassLoadInfo out of this if statement since both the the if and the else sections create a ClassLoadInfo with pretty much the same information. > > That other ClassLoadInfo cl_info(protection_domain) you see is from another function, so I can't pull it out. > The other side of the 'if' statement creates a ClassLoadInfo with all the hidden class goodies. In jvm_lookup_define_class there are 2 ClassLoadInfo cl_info constructions on line #950 and line #961 that could be pull out of the if statement. Again comment is minor and I am ok with how you decide to go forward with it. ------------- PR: https://git.openjdk.java.net/jdk/pull/3289 From kevinw at openjdk.java.net Thu Apr 1 14:14:39 2021 From: kevinw at openjdk.java.net (Kevin Walls) Date: Thu, 1 Apr 2021 14:14:39 GMT Subject: RFR: 8264593: debug.cpp utilities should be available in product builds. Message-ID: This is a pull request to move the ifndef PRODUCT in src/hotspot/share/utilities/debug.cpp, and add JNIEXPORT for symbol visibility on Windows. With these changes, we can use gdb on a live Linux process of a product build JVM, and call debug.cpp utilities. e.g. "call universe()", or "call hsfind(0xADDRESS)". (I found that making calls in the JLI_Launch thread (gdb's thread 1) will crash, but switching first to a JavaThread works.) In Visual Studio use the Immediate window, just type the function name. Verified that without the changes, the symbols can't be seen/called. Printing happens on the LIVE jvm's tty (not the gdb session). WizardMode is a develop flag, can't be changed in a product build, so avoid changing that in the debug() utility. pa() is left ifndef PRODUCT, as the class AllocatedObj is ifndef PRODUCT in src/hotspot/share/memory/allocation.hpp pns(...) uses frame fr(sp, fp, pc); but we have an ifndef PRODUCT on frame constructor: frame(void* sp, void* fp, void* pc); Leave pns and pns2 ifndef PRODUCT. File size changes: Linux: libjvm.so becomes 8904 bytes larger. Windows: jvm.dll becomes 6656 bytes larger. ------------- Commit messages: - 8264593: debug.cpp utilities should be available in product builds. Changes: https://git.openjdk.java.net/jdk/pull/3307/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3307&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264593 Stats: 42 lines in 1 file changed: 3 ins; 7 del; 32 mod Patch: https://git.openjdk.java.net/jdk/pull/3307.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3307/head:pull/3307 PR: https://git.openjdk.java.net/jdk/pull/3307 From iignatyev at openjdk.java.net Thu Apr 1 14:22:23 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 1 Apr 2021 14:22:23 GMT Subject: RFR: 8058176: [mlvm] tests should not allow code cache exhaustion [v6] In-Reply-To: <41vRG3m7B1ypKxez-IEzb_tsRT4K1sSBoNpqgiOqg9c=.f72b0cef-abdd-4201-8579-69b32688b181@github.com> References: <41vRG3m7B1ypKxez-IEzb_tsRT4K1sSBoNpqgiOqg9c=.f72b0cef-abdd-4201-8579-69b32688b181@github.com> Message-ID: On Thu, 1 Apr 2021 06:54:21 GMT, Aleksey Shipilev wrote: >> Marked as reviewed by iignatyev (Reviewer). > > Are we integrating this? I thought to sponsor, but wanted to check if everyone is in agreement this change is fine. Fine w/ me. (Don?t know why I haven?t sponsored it before) ------------- PR: https://git.openjdk.java.net/jdk/pull/2523 From coleenp at openjdk.java.net Thu Apr 1 14:58:13 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 1 Apr 2021 14:58:13 GMT Subject: Integrated: 8264538: Rename SystemDictionary::parse_stream In-Reply-To: References: Message-ID: <2AZFt45184wSKISLEKuBb3QwRjqRIcguukA5aA87Ciw=.84d2da62-7101-41d2-934f-5c158d0fdb62@github.com> On Wed, 31 Mar 2021 19:46:24 GMT, Coleen Phillimore wrote: > This function is used to call the classfile parser for hidden or anonymous classes, and for use with jvmti RedefineClasses. The latter only calls KlassFactory::create_from_stream and skips the rest of the code in SystemDictionary::parse_stream. > > Renamed SystemDictionary::parse_stream -> resolve_hidden_class_from_stream > resolve_from_stream -> resolve_class_from_stream > and have SystemDictionary::resolve_from_stream() call the right version depending on ClassLoadInfo flags. Callers of resolve_from_stream now pass protection domain via. ClassLoadInfo. > > So the external API is resolve_from_stream. > > Tested with tier1 on 4 Oracle supported platforms. This pull request has now been integrated. Changeset: 1dc75e9e Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/1dc75e9e Stats: 138 lines in 7 files changed: 37 ins; 29 del; 72 mod 8264538: Rename SystemDictionary::parse_stream Reviewed-by: lfoltan, hseigel ------------- PR: https://git.openjdk.java.net/jdk/pull/3289 From coleenp at openjdk.java.net Thu Apr 1 14:58:13 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 1 Apr 2021 14:58:13 GMT Subject: RFR: 8264538: Rename SystemDictionary::parse_stream [v3] In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 12:24:56 GMT, Harold Seigel wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Add and remove comments. > > The changes look good! > Thanks, Harold Thanks Harold and Lois! ------------- PR: https://git.openjdk.java.net/jdk/pull/3289 From coleenp at openjdk.java.net Thu Apr 1 15:13:27 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 1 Apr 2021 15:13:27 GMT Subject: RFR: 8264150: CDS dumping code calls TRAPS functions in VM thread In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 06:25:08 GMT, Ioi Lam wrote: >> This change initializes the vtables/itables without checking constraints. After initializing but before the class is visible in the SystemDictionary, constraints are checked in a separate loop. >> >> Tested with tier1-6 which includes jck tests. > > Marked as reviewed by iklam (Reviewer). Thanks David and Ioi. Yes, the refactoring was a bit more involved than anticipated. ------------- PR: https://git.openjdk.java.net/jdk/pull/3277 From coleenp at openjdk.java.net Thu Apr 1 15:13:28 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 1 Apr 2021 15:13:28 GMT Subject: Integrated: 8264150: CDS dumping code calls TRAPS functions in VM thread In-Reply-To: References: Message-ID: On Tue, 30 Mar 2021 22:25:06 GMT, Coleen Phillimore wrote: > This change initializes the vtables/itables without checking constraints. After initializing but before the class is visible in the SystemDictionary, constraints are checked in a separate loop. > > Tested with tier1-6 which includes jck tests. This pull request has now been integrated. Changeset: 4b197714 Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/4b197714 Stats: 290 lines in 10 files changed: 146 ins; 84 del; 60 mod 8264150: CDS dumping code calls TRAPS functions in VM thread Reviewed-by: dholmes, iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/3277 From coleen.phillimore at oracle.com Thu Apr 1 15:13:35 2021 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Thu, 1 Apr 2021 11:13:35 -0400 Subject: RFR: 8264538: Rename SystemDictionary::parse_stream [v2] In-Reply-To: References: <5XkcECxtI-f304vVc6TXjJNXHA5kpzcHORV8q8mPvzk=.da25a174-4c29-4f5a-a639-695043a06067@github.com> Message-ID: On 4/1/21 9:48 AM, Lois Foltan wrote: > On Wed, 31 Mar 2021 21:22:39 GMT, Coleen Phillimore wrote: > >>> src/hotspot/share/prims/jvm.cpp line 950: >>> >>>> 948: InstanceKlass* ik = NULL; >>>> 949: if (!is_hidden) { >>>> 950: ClassLoadInfo cl_info(protection_domain); >>> Minor comment, you could pull the creation of ClassLoadInfo out of this if statement since both the the if and the else sections create a ClassLoadInfo with pretty much the same information. >> That other ClassLoadInfo cl_info(protection_domain) you see is from another function, so I can't pull it out. >> The other side of the 'if' statement creates a ClassLoadInfo with all the hidden class goodies. > In jvm_lookup_define_class there are 2 ClassLoadInfo cl_info constructions on line #950 and line #961 that could be pull out of the if statement. Again comment is minor and I am ok with how you decide to go forward with it. Sorry I didn't see this comment in the pull request, and thanks for explaining that the ClassLoadInfo from the 'else' clause could have been pulled out of the if statement.? I was thinking the one in the 'if' clause.? We can change it if we're in the area next time. Thanks, Coleen > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3289 From iklam at openjdk.java.net Thu Apr 1 15:27:54 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 1 Apr 2021 15:27:54 GMT Subject: RFR: 8264285: Clean the modification of ccstr JVM flags [v4] In-Reply-To: References: Message-ID: > There are two versions of JVMFlagAccess::ccstrAtPut() for modifying JVM flags of the ccstr type (i.e., strings). > > - One version requires the caller to free the old value, but some callers don't do that (writeableFlags.cpp). > - The other version frees the old value on behalf of the caller. However, this version is accessible only via FLAG_SET_XXX macros and is currently unused. So it's unclear whether it actually works. > > We should combine these two versions into a single function, fix problems in the callers, and add test cases. The old value should be freed automatically, because typically the caller isn't interested in the old value. > > Note that the FLAG_SET_XXX macros do not return the old value. Requiring the caller of FLAG_SET_XXX to free the old value would be tedious and error prone. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge branch 'master' into 8264285-clean-up-setting-ccstr-jvm-flags - Revert "relax flag attributions (ala JDK-7123237)" This reverts commit 673aaafc4860dd7f70a3f222422ae84e85fd4219. - relax flag attributions (ala JDK-7123237) - restored SET_FLAG_XXX for ccstr type, and fixed bugs in existing ccstr modification code - 8264285: Do not support FLAG_SET_XXX for VM flags of string type ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3254/files - new: https://git.openjdk.java.net/jdk/pull/3254/files/2a5e2b19..5f912221 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3254&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3254&range=02-03 Stats: 8053 lines in 376 files changed: 5492 ins; 1012 del; 1549 mod Patch: https://git.openjdk.java.net/jdk/pull/3254.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3254/head:pull/3254 PR: https://git.openjdk.java.net/jdk/pull/3254 From minqi at openjdk.java.net Thu Apr 1 16:49:27 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 1 Apr 2021 16:49:27 GMT Subject: RFR: 8264540: WhiteBox.metaspaceReserveAlignment should return shared region alignment Message-ID: Hi, Please review After JDK-8236847, the shared region alignment (new as MetaspaceShared::core_region_alignment) is no longer default to os pagesize, it is a configurable value at build time instead. The WhiteBox api metaspaceReserveAlignment() should reflect the change. Tests:tier1,tier2,tier3,tier4 ------------- Commit messages: - 8264540: WhiteBox.metaspaceReserveAlignment should return shared region alignment Changes: https://git.openjdk.java.net/jdk/pull/3309/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3309&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264540 Stats: 23 lines in 5 files changed: 8 ins; 3 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/3309.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3309/head:pull/3309 PR: https://git.openjdk.java.net/jdk/pull/3309 From coleenp at openjdk.java.net Thu Apr 1 17:06:38 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 1 Apr 2021 17:06:38 GMT Subject: RFR: 8262280: Incorrect exception handling for VMThread in class redefinition Message-ID: This is a trivial change to remove the last TRAPS from redefine_single_class which is called by the VM thread during a safepoint. Tested with serviceability/jvmti/RedefineClasses, vmTestbase/nsk/jvmti,jdi and jdk/java/lang/instrument tests. And tier1 sanity in progress. ------------- Commit messages: - 8262280: Incorrect exception handling for VMThread in class redefinition Changes: https://git.openjdk.java.net/jdk/pull/3310/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3310&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262280 Stats: 19 lines in 2 files changed: 0 ins; 0 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/3310.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3310/head:pull/3310 PR: https://git.openjdk.java.net/jdk/pull/3310 From iklam at openjdk.java.net Thu Apr 1 18:11:36 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 1 Apr 2021 18:11:36 GMT Subject: RFR: 8264565: Templatize num_arguments() functions of DCmd subclasses Message-ID: We have many version of `num_arguments()` for the `DCmd` subclasses. They all have identical structure. We should templatize them to reduce duplicated code and avoid cut-and-paste errors. It's still possible to write a customized `num_arguments()` function (although none of the existing cases needs to do that). The rules are described here: class DCmd : public ResourceObj { ... // num_arguments() is used by the DCmdFactoryImpl::get_num_arguments() template functions. // - For subclasses of DCmdWithParser, it's calculated by DCmdParser::num_arguments(). // - Other subclasses of DCmd have zero arguments by default. You can change this // by defining your own version of MyDCmd::num_arguments(). static int num_arguments() { return 0; } ------------- Commit messages: - removed remaining boilerplate num_arguments() functions - DebugOnCmdStartDCmd does not need to subclass from DCmdWithParser - 8264565: Templatize num_arguments() functions of DCmd subclasses Changes: https://git.openjdk.java.net/jdk/pull/3312/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3312&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264565 Stats: 277 lines in 8 files changed: 27 ins; 241 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/3312.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3312/head:pull/3312 PR: https://git.openjdk.java.net/jdk/pull/3312 From iklam at openjdk.java.net Thu Apr 1 18:26:15 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 1 Apr 2021 18:26:15 GMT Subject: RFR: 8264565: Templatize num_arguments() functions of DCmd subclasses In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 17:46:22 GMT, Ioi Lam wrote: > We have many version of `num_arguments()` for the `DCmd` subclasses. They all have identical structure. We should templatize them to reduce duplicated code and avoid cut-and-paste errors. > > It's still possible to write a customized `num_arguments()` function (although none of the existing cases needs to do that). The rules are described here: > > class DCmd : public ResourceObj { > ... > // num_arguments() is used by the DCmdFactoryImpl::get_num_arguments() template functions. > // - For subclasses of DCmdWithParser, it's calculated by DCmdParser::num_arguments(). > // - Other subclasses of DCmd have zero arguments by default. You can change this > // by defining your own version of MyDCmd::num_arguments(). > static int num_arguments() { return 0; } For verification, I added code in an earlier commit (hence removed) to print out the `num_arguments()` of each `DCmd`. The results are identical with and without this patch. https://github.com/openjdk/jdk/blob/25920cdd8296901bcd64d5cf277a616bc90bea90/src/hotspot/share/services/diagnosticFramework.cpp#L521-L523 ------------- PR: https://git.openjdk.java.net/jdk/pull/3312 From iklam at openjdk.java.net Thu Apr 1 18:28:24 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 1 Apr 2021 18:28:24 GMT Subject: Integrated: 8264285: Clean the modification of ccstr JVM flags In-Reply-To: References: Message-ID: On Mon, 29 Mar 2021 21:35:52 GMT, Ioi Lam wrote: > There are two versions of JVMFlagAccess::ccstrAtPut() for modifying JVM flags of the ccstr type (i.e., strings). > > - One version requires the caller to free the old value, but some callers don't do that (writeableFlags.cpp). > - The other version frees the old value on behalf of the caller. However, this version is accessible only via FLAG_SET_XXX macros and is currently unused. So it's unclear whether it actually works. > > We should combine these two versions into a single function, fix problems in the callers, and add test cases. The old value should be freed automatically, because typically the caller isn't interested in the old value. > > Note that the FLAG_SET_XXX macros do not return the old value. Requiring the caller of FLAG_SET_XXX to free the old value would be tedious and error prone. This pull request has now been integrated. Changeset: 58583990 Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/58583990 Stats: 205 lines in 9 files changed: 160 ins; 24 del; 21 mod 8264285: Clean the modification of ccstr JVM flags Reviewed-by: dholmes, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/3254 From iklam at openjdk.java.net Thu Apr 1 18:28:22 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 1 Apr 2021 18:28:22 GMT Subject: RFR: 8264285: Clean the modification of ccstr JVM flags [v2] In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 00:25:59 GMT, Coleen Phillimore wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> relax flag attributions (ala JDK-7123237) > > Marked as reviewed by coleenp (Reviewer). Thanks @coleenp and @dholmes-ora for reviewing. ------------- PR: https://git.openjdk.java.net/jdk/pull/3254 From minqi at openjdk.java.net Thu Apr 1 22:15:51 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 1 Apr 2021 22:15:51 GMT Subject: RFR: 8264540: WhiteBox.metaspaceReserveAlignment should return shared region alignment [v2] In-Reply-To: References: Message-ID: > Hi, Please review > After JDK-8236847, the shared region alignment (new as MetaspaceShared::core_region_alignment) is no longer default to os pagesize, it is a configurable value at build time instead. The WhiteBox api metaspaceReserveAlignment() should reflect the change. > > Tests:tier1,tier2,tier3,tier4 Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Fix minimal build failure ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3309/files - new: https://git.openjdk.java.net/jdk/pull/3309/files/c8d80a05..f99b1c90 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3309&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3309&range=00-01 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3309.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3309/head:pull/3309 PR: https://git.openjdk.java.net/jdk/pull/3309 From iklam at openjdk.java.net Thu Apr 1 23:40:41 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 1 Apr 2021 23:40:41 GMT Subject: RFR: 8262328: Templatize JVMFlag boilerplate access methods Message-ID: We have a bunch of boilerplate method like: JVMFlagAccess::boolAtPut (JVMFlag* f, bool* v, JVMFlagOrigin origin) JVMFlagAccess::intAtPut (JVMFlag* f, int* v, JVMFlagOrigin origin) JVMFlagAccess::uintAtPut (JVMFlag* f, uint* v, JVMFlagOrigin origin) ... Similarly, we also have 8 different functions: JVMFlag::{set_bool, set_int, set_intx, ...} We should replace such patterns with template JVMFlagAccess::set(JVMFlag* f, T* value, JVMFlagOrigin origin) This would allow us to templatize the 8x boilerplate functions in writeableFlags.cpp. The flag access code in whitebox.cpp can also be improved. ------------- Commit messages: - added test case - removed JVMFlag::set_##type() functions - fixed merge - Merge branch 'master' into 8262328-templatize-jvmflag-boilerplate-methods - static_assert to disable SET_FLAG_XXX on ccstr flags - more cleanup - step2 - 8262328: Templatize JVMFlag boilerplate methods Changes: https://git.openjdk.java.net/jdk/pull/3318/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3318&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262328 Stats: 325 lines in 11 files changed: 71 ins; 135 del; 119 mod Patch: https://git.openjdk.java.net/jdk/pull/3318.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3318/head:pull/3318 PR: https://git.openjdk.java.net/jdk/pull/3318 From dongbo at openjdk.java.net Fri Apr 2 03:10:57 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Fri, 2 Apr 2021 03:10:57 GMT Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v3] In-Reply-To: References: Message-ID: <96N9BNz7s4JH99-5lQio5uEP8iAa4YEmn9NK-dUyvCQ=.c663f383-f207-45c3-97bf-b5309b624315@github.com> > In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding. > Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic idea can be found at http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords. > > Patch passed jtreg tier1-3 tests with linux-aarch64-server-fastdebug build. > Tests in `test/jdk/java/util/Base64/` and `compiler/intrinsics/base64/TestBase64.java` runned specially for the correctness of the implementation. > > There can be illegal characters at the start of the input if the data is MIME encoded. > It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now. > > A JMH micro, Base64Decode.java, is added for performance test. > With different input length (upper-bounded by parameter `maxNumBytes` in the JMH micro), > we witness ~2.5x improvements with long inputs and no regression with short inputs for raw base64 decodeing, minor improvements (~10.95%) for MIME on Kunpeng916. > > The Base64Decode.java JMH micro-benchmark results: > > Benchmark (lineSize) (maxNumBytes) Mode Cnt Score Error Units > > # Kunpeng916, intrinsic > Base64Decode.testBase64Decode 4 1 avgt 5 48.614 ? 0.609 ns/op > Base64Decode.testBase64Decode 4 3 avgt 5 58.199 ? 1.650 ns/op > Base64Decode.testBase64Decode 4 7 avgt 5 69.400 ? 0.931 ns/op > Base64Decode.testBase64Decode 4 32 avgt 5 96.818 ? 1.687 ns/op > Base64Decode.testBase64Decode 4 64 avgt 5 122.856 ? 9.217 ns/op > Base64Decode.testBase64Decode 4 80 avgt 5 130.935 ? 1.667 ns/op > Base64Decode.testBase64Decode 4 96 avgt 5 143.627 ? 1.751 ns/op > Base64Decode.testBase64Decode 4 112 avgt 5 152.311 ? 1.178 ns/op > Base64Decode.testBase64Decode 4 512 avgt 5 342.631 ? 0.584 ns/op > Base64Decode.testBase64Decode 4 1000 avgt 5 573.635 ? 1.050 ns/op > Base64Decode.testBase64Decode 4 20000 avgt 5 9534.136 ? 45.172 ns/op > Base64Decode.testBase64Decode 4 50000 avgt 5 22718.726 ? 192.070 ns/op > Base64Decode.testBase64MIMEDecode 4 1 avgt 10 63.558 ? 0.336 ns/op > Base64Decode.testBase64MIMEDecode 4 3 avgt 10 82.504 ? 0.848 ns/op > Base64Decode.testBase64MIMEDecode 4 7 avgt 10 120.591 ? 0.608 ns/op > Base64Decode.testBase64MIMEDecode 4 32 avgt 10 324.314 ? 6.236 ns/op > Base64Decode.testBase64MIMEDecode 4 64 avgt 10 532.678 ? 4.670 ns/op > Base64Decode.testBase64MIMEDecode 4 80 avgt 10 678.126 ? 4.324 ns/op > Base64Decode.testBase64MIMEDecode 4 96 avgt 10 771.603 ? 6.393 ns/op > Base64Decode.testBase64MIMEDecode 4 112 avgt 10 889.608 ? 0.759 ns/op > Base64Decode.testBase64MIMEDecode 4 512 avgt 10 3663.557 ? 3.422 ns/op > Base64Decode.testBase64MIMEDecode 4 1000 avgt 10 7017.784 ? 9.128 ns/op > Base64Decode.testBase64MIMEDecode 4 20000 avgt 10 128670.660 ? 7951.521 ns/op > Base64Decode.testBase64MIMEDecode 4 50000 avgt 10 317113.667 ? 161.758 ns/op > > # Kunpeng916, default > Base64Decode.testBase64Decode 4 1 avgt 5 48.455 ? 0.571 ns/op > Base64Decode.testBase64Decode 4 3 avgt 5 57.937 ? 0.505 ns/op > Base64Decode.testBase64Decode 4 7 avgt 5 73.823 ? 1.452 ns/op > Base64Decode.testBase64Decode 4 32 avgt 5 106.484 ? 1.243 ns/op > Base64Decode.testBase64Decode 4 64 avgt 5 141.004 ? 1.188 ns/op > Base64Decode.testBase64Decode 4 80 avgt 5 156.284 ? 0.572 ns/op > Base64Decode.testBase64Decode 4 96 avgt 5 174.137 ? 0.177 ns/op > Base64Decode.testBase64Decode 4 112 avgt 5 188.445 ? 0.572 ns/op > Base64Decode.testBase64Decode 4 512 avgt 5 610.847 ? 1.559 ns/op > Base64Decode.testBase64Decode 4 1000 avgt 5 1155.368 ? 0.813 ns/op > Base64Decode.testBase64Decode 4 20000 avgt 5 19751.477 ? 24.669 ns/op > Base64Decode.testBase64Decode 4 50000 avgt 5 50046.586 ? 523.155 ns/op > Base64Decode.testBase64MIMEDecode 4 1 avgt 10 64.130 ? 0.238 ns/op > Base64Decode.testBase64MIMEDecode 4 3 avgt 10 82.096 ? 0.205 ns/op > Base64Decode.testBase64MIMEDecode 4 7 avgt 10 118.849 ? 0.610 ns/op > Base64Decode.testBase64MIMEDecode 4 32 avgt 10 331.177 ? 4.732 ns/op > Base64Decode.testBase64MIMEDecode 4 64 avgt 10 549.117 ? 0.177 ns/op > Base64Decode.testBase64MIMEDecode 4 80 avgt 10 702.951 ? 4.572 ns/op > Base64Decode.testBase64MIMEDecode 4 96 avgt 10 799.566 ? 0.301 ns/op > Base64Decode.testBase64MIMEDecode 4 112 avgt 10 923.749 ? 0.389 ns/op > Base64Decode.testBase64MIMEDecode 4 512 avgt 10 4000.725 ? 2.519 ns/op > Base64Decode.testBase64MIMEDecode 4 1000 avgt 10 7674.994 ? 9.281 ns/op > Base64Decode.testBase64MIMEDecode 4 20000 avgt 10 142059.001 ? 157.920 ns/op > Base64Decode.testBase64MIMEDecode 4 50000 avgt 10 355698.369 ? 216.542 ns/op Dong Bo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Merge branch 'master' into aarch64.base64.decode - copyright - trivial fixes - Handling error in SIMD case with loops, combining two non-SIMD cases into one code blob, addressing other comments - Merge branch 'master' into aarch64.base64.decode - 8256245: AArch64: Implement Base64 decoding intrinsic ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3228/files - new: https://git.openjdk.java.net/jdk/pull/3228/files/e658ebf4..16ebc471 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3228&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3228&range=01-02 Stats: 7270 lines in 287 files changed: 5225 ins; 950 del; 1095 mod Patch: https://git.openjdk.java.net/jdk/pull/3228.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3228/head:pull/3228 PR: https://git.openjdk.java.net/jdk/pull/3228 From iklam at openjdk.java.net Fri Apr 2 03:25:26 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 2 Apr 2021 03:25:26 GMT Subject: Withdrawn: 8262328: Templatize JVMFlag boilerplate access methods In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 22:44:34 GMT, Ioi Lam wrote: > We have a bunch of boilerplate method like: > > JVMFlagAccess::boolAtPut (JVMFlag* f, bool* v, JVMFlagOrigin origin) > JVMFlagAccess::intAtPut (JVMFlag* f, int* v, JVMFlagOrigin origin) > JVMFlagAccess::uintAtPut (JVMFlag* f, uint* v, JVMFlagOrigin origin) > ... > > Similarly, we also have 8 different functions: JVMFlag::{set_bool, set_int, set_intx, ...} > > We should replace such patterns with > > template > JVMFlagAccess::set(JVMFlag* f, T* value, JVMFlagOrigin origin) > > This would allow us to templatize the 8x boilerplate functions in writeableFlags.cpp. > > The flag access code in whitebox.cpp can also be improved. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/3318 From iklam at openjdk.java.net Fri Apr 2 03:25:26 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 2 Apr 2021 03:25:26 GMT Subject: RFR: 8262328: Templatize JVMFlag boilerplate access methods In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 22:44:34 GMT, Ioi Lam wrote: > We have a bunch of boilerplate method like: > > JVMFlagAccess::boolAtPut (JVMFlag* f, bool* v, JVMFlagOrigin origin) > JVMFlagAccess::intAtPut (JVMFlag* f, int* v, JVMFlagOrigin origin) > JVMFlagAccess::uintAtPut (JVMFlag* f, uint* v, JVMFlagOrigin origin) > ... > > Similarly, we also have 8 different functions: JVMFlag::{set_bool, set_int, set_intx, ...} > > We should replace such patterns with > > template > JVMFlagAccess::set(JVMFlag* f, T* value, JVMFlagOrigin origin) > > This would allow us to templatize the 8x boilerplate functions in writeableFlags.cpp. > > The flag access code in whitebox.cpp can also be improved. I need to work on this PR some more. Closing it for now. ------------- PR: https://git.openjdk.java.net/jdk/pull/3318 From dongbo at openjdk.java.net Fri Apr 2 07:08:33 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Fri, 2 Apr 2021 07:08:33 GMT Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic In-Reply-To: References: <_ZrhnM9OyXLckhtT27laLzWPZbCFZTPjm6ePbZdbyOs=.fcc6aaba-1578-443a-aa57-8141a99231f6@github.com> Message-ID: On Tue, 30 Mar 2021 03:24:16 GMT, Dong Bo wrote: >>> I think I can rewrite this part as loops. >>> With an intial implemention, we can have almost half of the code size reduced (1312B -> 748B). Sounds OK to you? >> >> Sounds great, but I'm still somewhat concerned that the non-SIMD case only offers 3-12% performance gain. Make it just 748 bytes, and therefore not icache-hostile, then perhaps the balance of risk and reward is justified. > >> > With an intial implemention, we can have almost half of the code size reduced (1312B -> 748B). Sounds OK to you? >> >> Sounds great, but I'm still somewhat concerned that the non-SIMD case only offers 3-12% performance gain. Make it just 748 bytes, and therefore not icache-hostile, then perhaps the balance of risk and reward is justified. > > Hi, @theRealAph @nick-arm > > The code is updated. The error handling in SIMD case was rewriten as loops. > > Also combined the two non-SIMD code blocks into one. > Due to we have only one non-SIMD loop now, it is moved into `generate_base64_decodeBlock`. > The size of the stub is 692 bytes, the non-SIMD loop takes about 92 bytes if my calculation is right. > > Verified with tests `test/jdk/java/util/Base64/` and `compiler/intrinsics/base64/TestBase64.java`. > Compared with previous implementation, the performance changes are negligible. > > Other comments are addressed too. Thanks. PING... Any suggestions on the updated commit? ------------- PR: https://git.openjdk.java.net/jdk/pull/3228 From yyang at openjdk.java.net Fri Apr 2 07:38:32 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Fri, 2 Apr 2021 07:38:32 GMT Subject: RFR: 8263028: Windows build fails due to several treat-warning-as-errors In-Reply-To: References: <6cv_HeWJ9HsBrB7NSFU-TGl4PP0Tp820KzwJ-FRn_so=.e4d8ab11-4203-4278-a829-43b6f1626465@github.com> <_4snjvydeDKDu6aZgC1Fqr_kc6sHII7F7Ywinh3H9Rw=.61007752-81c3-44a0-911f-4dd184259966@github.com> Message-ID: On Mon, 29 Mar 2021 14:42:00 GMT, Yi Yang wrote: >> I searched the net once more for setting the locale, and this time I found some creative workarounds on superuser. The suggestion is to create a *secondary* user account, and set US English as locale for that account. Then you can go back to your main account, and us the "Run as..." functionality to execute an arbitrary command as that user. >> >> This could be done by: `%comspec% runas /profile /user:yourotheruser "the_application_you_want_ to_run_in_english"` or using the GUI (shift+right click on the icon, select `Run as different user`). >> >> I assume you would be able to start a cygwin shell like this, and have all processes started in that shell belonging to this US English user. >> >> @kelthuzadx Can you please verify if this method works? If so, I believe it is convenient enough for us to be able to require US English locale for building on Windows. > > Hi Magnus, > >> I searched the net once more for setting the locale, and this time I found some creative workarounds on superuser. The suggestion is to create a secondary user account, and set US English as locale for that account. Then you can go back to your main account, and us the "Run as..." functionality to execute an arbitrary command as that user. > >> This could be done by: %comspec% runas /profile /user:yourotheruser "the_application_you_want_ to_run_in_english" or using the GUI (shift+right click on the icon, select Run as different user). > > Thanks for your investigations and kind suggestions. It is more troublesome to add new a user to the Chinese system and set its system locale to English. Instead of doing this, I prefer to directly change the system locale to English. > > When I set the system locale to English(`Control Panel->Change date, time,...->Administrative->Change System locale->English`), and it indeed works for building! No warnings were generated. All works fine. > >> a) it does not occur in what is at least the "recommended" locale, and > >> b) more issues are likely to creep up in the future (in fact, there might already be testing issues as Jorn says) > >> On the other hand, I am not really comfortable either with just stating in the build document that US English is the only supported Windows locale, since it has such far-reaching consequences for the individual developers. > > You convinced me, I agree with you that stating these has far-reaching consequences and your internal test matrix will become incredibly heavy. However, I think we can add a section in the FAQ or other places in the building document to give a solution for such problems as much as possible, e.g. > > Q: Why I can not build JDK on a non-English system? What should I do next? > A: Maybe you can change your system locale to English and try again > > Just IMHO, :-) > > Best Regards, > Yang In order to avoid disturbing others, I will comment on the https://bugs.openjdk.java.net/browse/JDK-8264425 ------------- PR: https://git.openjdk.java.net/jdk/pull/3107 From yyang at openjdk.java.net Fri Apr 2 07:38:32 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Fri, 2 Apr 2021 07:38:32 GMT Subject: Withdrawn: 8263028: Windows build fails due to several treat-warning-as-errors In-Reply-To: References: Message-ID: On Sun, 21 Mar 2021 04:22:42 GMT, Yi Yang wrote: > cl.exe(19.28.29334) can not build JDK on windows_x64 because it treats many warnings as errors thus prohibiting further compilation. (See detailed failure logs on JBS) > > 1. methodMatcher.cpp > > cl.exe can not handle advanced usage of sscanf(i.e. regex-like sscanf) correctly. This looks like an msvc compiler bug, it has been there for a long while, so I temporarily disable these warnings in a limited region. Outside of this region, the compiler still treats them as errors. This change does not affect the functionality of MethodMatcher::parse_method_pattern, it can parse class name and method name in a desired manner. > > 2. vm_version_x86.cpp > > Some comments contain characters(Register Trademark) that cannot be represented in the current code page (936). Replacing them with ASCII-characters makes the compiler happy. > > Best Regards, > Yang This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/3107 From aph at openjdk.java.net Fri Apr 2 08:41:34 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Fri, 2 Apr 2021 08:41:34 GMT Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v3] In-Reply-To: <96N9BNz7s4JH99-5lQio5uEP8iAa4YEmn9NK-dUyvCQ=.c663f383-f207-45c3-97bf-b5309b624315@github.com> References: <96N9BNz7s4JH99-5lQio5uEP8iAa4YEmn9NK-dUyvCQ=.c663f383-f207-45c3-97bf-b5309b624315@github.com> Message-ID: On Fri, 2 Apr 2021 03:10:57 GMT, Dong Bo wrote: >> In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding. >> Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic idea can be found at http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords. >> >> Patch passed jtreg tier1-3 tests with linux-aarch64-server-fastdebug build. >> Tests in `test/jdk/java/util/Base64/` and `compiler/intrinsics/base64/TestBase64.java` runned specially for the correctness of the implementation. >> >> There can be illegal characters at the start of the input if the data is MIME encoded. >> It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now. >> >> A JMH micro, Base64Decode.java, is added for performance test. >> With different input length (upper-bounded by parameter `maxNumBytes` in the JMH micro), >> we witness ~2.5x improvements with long inputs and no regression with short inputs for raw base64 decodeing, minor improvements (~10.95%) for MIME on Kunpeng916. >> >> The Base64Decode.java JMH micro-benchmark results: >> >> Benchmark (lineSize) (maxNumBytes) Mode Cnt Score Error Units >> >> # Kunpeng916, intrinsic >> Base64Decode.testBase64Decode 4 1 avgt 5 48.614 ? 0.609 ns/op >> Base64Decode.testBase64Decode 4 3 avgt 5 58.199 ? 1.650 ns/op >> Base64Decode.testBase64Decode 4 7 avgt 5 69.400 ? 0.931 ns/op >> Base64Decode.testBase64Decode 4 32 avgt 5 96.818 ? 1.687 ns/op >> Base64Decode.testBase64Decode 4 64 avgt 5 122.856 ? 9.217 ns/op >> Base64Decode.testBase64Decode 4 80 avgt 5 130.935 ? 1.667 ns/op >> Base64Decode.testBase64Decode 4 96 avgt 5 143.627 ? 1.751 ns/op >> Base64Decode.testBase64Decode 4 112 avgt 5 152.311 ? 1.178 ns/op >> Base64Decode.testBase64Decode 4 512 avgt 5 342.631 ? 0.584 ns/op >> Base64Decode.testBase64Decode 4 1000 avgt 5 573.635 ? 1.050 ns/op >> Base64Decode.testBase64Decode 4 20000 avgt 5 9534.136 ? 45.172 ns/op >> Base64Decode.testBase64Decode 4 50000 avgt 5 22718.726 ? 192.070 ns/op >> Base64Decode.testBase64MIMEDecode 4 1 avgt 10 63.558 ? 0.336 ns/op >> Base64Decode.testBase64MIMEDecode 4 3 avgt 10 82.504 ? 0.848 ns/op >> Base64Decode.testBase64MIMEDecode 4 7 avgt 10 120.591 ? 0.608 ns/op >> Base64Decode.testBase64MIMEDecode 4 32 avgt 10 324.314 ? 6.236 ns/op >> Base64Decode.testBase64MIMEDecode 4 64 avgt 10 532.678 ? 4.670 ns/op >> Base64Decode.testBase64MIMEDecode 4 80 avgt 10 678.126 ? 4.324 ns/op >> Base64Decode.testBase64MIMEDecode 4 96 avgt 10 771.603 ? 6.393 ns/op >> Base64Decode.testBase64MIMEDecode 4 112 avgt 10 889.608 ? 0.759 ns/op >> Base64Decode.testBase64MIMEDecode 4 512 avgt 10 3663.557 ? 3.422 ns/op >> Base64Decode.testBase64MIMEDecode 4 1000 avgt 10 7017.784 ? 9.128 ns/op >> Base64Decode.testBase64MIMEDecode 4 20000 avgt 10 128670.660 ? 7951.521 ns/op >> Base64Decode.testBase64MIMEDecode 4 50000 avgt 10 317113.667 ? 161.758 ns/op >> >> # Kunpeng916, default >> Base64Decode.testBase64Decode 4 1 avgt 5 48.455 ? 0.571 ns/op >> Base64Decode.testBase64Decode 4 3 avgt 5 57.937 ? 0.505 ns/op >> Base64Decode.testBase64Decode 4 7 avgt 5 73.823 ? 1.452 ns/op >> Base64Decode.testBase64Decode 4 32 avgt 5 106.484 ? 1.243 ns/op >> Base64Decode.testBase64Decode 4 64 avgt 5 141.004 ? 1.188 ns/op >> Base64Decode.testBase64Decode 4 80 avgt 5 156.284 ? 0.572 ns/op >> Base64Decode.testBase64Decode 4 96 avgt 5 174.137 ? 0.177 ns/op >> Base64Decode.testBase64Decode 4 112 avgt 5 188.445 ? 0.572 ns/op >> Base64Decode.testBase64Decode 4 512 avgt 5 610.847 ? 1.559 ns/op >> Base64Decode.testBase64Decode 4 1000 avgt 5 1155.368 ? 0.813 ns/op >> Base64Decode.testBase64Decode 4 20000 avgt 5 19751.477 ? 24.669 ns/op >> Base64Decode.testBase64Decode 4 50000 avgt 5 50046.586 ? 523.155 ns/op >> Base64Decode.testBase64MIMEDecode 4 1 avgt 10 64.130 ? 0.238 ns/op >> Base64Decode.testBase64MIMEDecode 4 3 avgt 10 82.096 ? 0.205 ns/op >> Base64Decode.testBase64MIMEDecode 4 7 avgt 10 118.849 ? 0.610 ns/op >> Base64Decode.testBase64MIMEDecode 4 32 avgt 10 331.177 ? 4.732 ns/op >> Base64Decode.testBase64MIMEDecode 4 64 avgt 10 549.117 ? 0.177 ns/op >> Base64Decode.testBase64MIMEDecode 4 80 avgt 10 702.951 ? 4.572 ns/op >> Base64Decode.testBase64MIMEDecode 4 96 avgt 10 799.566 ? 0.301 ns/op >> Base64Decode.testBase64MIMEDecode 4 112 avgt 10 923.749 ? 0.389 ns/op >> Base64Decode.testBase64MIMEDecode 4 512 avgt 10 4000.725 ? 2.519 ns/op >> Base64Decode.testBase64MIMEDecode 4 1000 avgt 10 7674.994 ? 9.281 ns/op >> Base64Decode.testBase64MIMEDecode 4 20000 avgt 10 142059.001 ? 157.920 ns/op >> Base64Decode.testBase64MIMEDecode 4 50000 avgt 10 355698.369 ? 216.542 ns/op > > Dong Bo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Merge branch 'master' into aarch64.base64.decode > - copyright > - trivial fixes > - Handling error in SIMD case with loops, combining two non-SIMD cases into one code blob, addressing other comments > - Merge branch 'master' into aarch64.base64.decode > - 8256245: AArch64: Implement Base64 decoding intrinsic test/micro/org/openjdk/bench/java/util/Base64Decode.java line 85: > 83: } > 84: } > 85: Are there any existing test cases for failing inputs? ------------- PR: https://git.openjdk.java.net/jdk/pull/3228 From aph at openjdk.java.net Fri Apr 2 08:49:29 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Fri, 2 Apr 2021 08:49:29 GMT Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v3] In-Reply-To: <96N9BNz7s4JH99-5lQio5uEP8iAa4YEmn9NK-dUyvCQ=.c663f383-f207-45c3-97bf-b5309b624315@github.com> References: <96N9BNz7s4JH99-5lQio5uEP8iAa4YEmn9NK-dUyvCQ=.c663f383-f207-45c3-97bf-b5309b624315@github.com> Message-ID: <8yiJSbnHVrZTDGmKi7oQygWvCR8Gyvv4iSLdEAAez7I=.fa47a77d-54f1-4b60-94af-ad1aefb40470@github.com> On Fri, 2 Apr 2021 03:10:57 GMT, Dong Bo wrote: >> In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding. >> Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic idea can be found at http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords. >> >> Patch passed jtreg tier1-3 tests with linux-aarch64-server-fastdebug build. >> Tests in `test/jdk/java/util/Base64/` and `compiler/intrinsics/base64/TestBase64.java` runned specially for the correctness of the implementation. >> >> There can be illegal characters at the start of the input if the data is MIME encoded. >> It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now. >> >> A JMH micro, Base64Decode.java, is added for performance test. >> With different input length (upper-bounded by parameter `maxNumBytes` in the JMH micro), >> we witness ~2.5x improvements with long inputs and no regression with short inputs for raw base64 decodeing, minor improvements (~10.95%) for MIME on Kunpeng916. >> >> The Base64Decode.java JMH micro-benchmark results: >> >> Benchmark (lineSize) (maxNumBytes) Mode Cnt Score Error Units >> >> # Kunpeng916, intrinsic >> Base64Decode.testBase64Decode 4 1 avgt 5 48.614 ? 0.609 ns/op >> Base64Decode.testBase64Decode 4 3 avgt 5 58.199 ? 1.650 ns/op >> Base64Decode.testBase64Decode 4 7 avgt 5 69.400 ? 0.931 ns/op >> Base64Decode.testBase64Decode 4 32 avgt 5 96.818 ? 1.687 ns/op >> Base64Decode.testBase64Decode 4 64 avgt 5 122.856 ? 9.217 ns/op >> Base64Decode.testBase64Decode 4 80 avgt 5 130.935 ? 1.667 ns/op >> Base64Decode.testBase64Decode 4 96 avgt 5 143.627 ? 1.751 ns/op >> Base64Decode.testBase64Decode 4 112 avgt 5 152.311 ? 1.178 ns/op >> Base64Decode.testBase64Decode 4 512 avgt 5 342.631 ? 0.584 ns/op >> Base64Decode.testBase64Decode 4 1000 avgt 5 573.635 ? 1.050 ns/op >> Base64Decode.testBase64Decode 4 20000 avgt 5 9534.136 ? 45.172 ns/op >> Base64Decode.testBase64Decode 4 50000 avgt 5 22718.726 ? 192.070 ns/op >> Base64Decode.testBase64MIMEDecode 4 1 avgt 10 63.558 ? 0.336 ns/op >> Base64Decode.testBase64MIMEDecode 4 3 avgt 10 82.504 ? 0.848 ns/op >> Base64Decode.testBase64MIMEDecode 4 7 avgt 10 120.591 ? 0.608 ns/op >> Base64Decode.testBase64MIMEDecode 4 32 avgt 10 324.314 ? 6.236 ns/op >> Base64Decode.testBase64MIMEDecode 4 64 avgt 10 532.678 ? 4.670 ns/op >> Base64Decode.testBase64MIMEDecode 4 80 avgt 10 678.126 ? 4.324 ns/op >> Base64Decode.testBase64MIMEDecode 4 96 avgt 10 771.603 ? 6.393 ns/op >> Base64Decode.testBase64MIMEDecode 4 112 avgt 10 889.608 ? 0.759 ns/op >> Base64Decode.testBase64MIMEDecode 4 512 avgt 10 3663.557 ? 3.422 ns/op >> Base64Decode.testBase64MIMEDecode 4 1000 avgt 10 7017.784 ? 9.128 ns/op >> Base64Decode.testBase64MIMEDecode 4 20000 avgt 10 128670.660 ? 7951.521 ns/op >> Base64Decode.testBase64MIMEDecode 4 50000 avgt 10 317113.667 ? 161.758 ns/op >> >> # Kunpeng916, default >> Base64Decode.testBase64Decode 4 1 avgt 5 48.455 ? 0.571 ns/op >> Base64Decode.testBase64Decode 4 3 avgt 5 57.937 ? 0.505 ns/op >> Base64Decode.testBase64Decode 4 7 avgt 5 73.823 ? 1.452 ns/op >> Base64Decode.testBase64Decode 4 32 avgt 5 106.484 ? 1.243 ns/op >> Base64Decode.testBase64Decode 4 64 avgt 5 141.004 ? 1.188 ns/op >> Base64Decode.testBase64Decode 4 80 avgt 5 156.284 ? 0.572 ns/op >> Base64Decode.testBase64Decode 4 96 avgt 5 174.137 ? 0.177 ns/op >> Base64Decode.testBase64Decode 4 112 avgt 5 188.445 ? 0.572 ns/op >> Base64Decode.testBase64Decode 4 512 avgt 5 610.847 ? 1.559 ns/op >> Base64Decode.testBase64Decode 4 1000 avgt 5 1155.368 ? 0.813 ns/op >> Base64Decode.testBase64Decode 4 20000 avgt 5 19751.477 ? 24.669 ns/op >> Base64Decode.testBase64Decode 4 50000 avgt 5 50046.586 ? 523.155 ns/op >> Base64Decode.testBase64MIMEDecode 4 1 avgt 10 64.130 ? 0.238 ns/op >> Base64Decode.testBase64MIMEDecode 4 3 avgt 10 82.096 ? 0.205 ns/op >> Base64Decode.testBase64MIMEDecode 4 7 avgt 10 118.849 ? 0.610 ns/op >> Base64Decode.testBase64MIMEDecode 4 32 avgt 10 331.177 ? 4.732 ns/op >> Base64Decode.testBase64MIMEDecode 4 64 avgt 10 549.117 ? 0.177 ns/op >> Base64Decode.testBase64MIMEDecode 4 80 avgt 10 702.951 ? 4.572 ns/op >> Base64Decode.testBase64MIMEDecode 4 96 avgt 10 799.566 ? 0.301 ns/op >> Base64Decode.testBase64MIMEDecode 4 112 avgt 10 923.749 ? 0.389 ns/op >> Base64Decode.testBase64MIMEDecode 4 512 avgt 10 4000.725 ? 2.519 ns/op >> Base64Decode.testBase64MIMEDecode 4 1000 avgt 10 7674.994 ? 9.281 ns/op >> Base64Decode.testBase64MIMEDecode 4 20000 avgt 10 142059.001 ? 157.920 ns/op >> Base64Decode.testBase64MIMEDecode 4 50000 avgt 10 355698.369 ? 216.542 ns/op > > Dong Bo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Merge branch 'master' into aarch64.base64.decode > - copyright > - trivial fixes > - Handling error in SIMD case with loops, combining two non-SIMD cases into one code blob, addressing other comments > - Merge branch 'master' into aarch64.base64.decode > - 8256245: AArch64: Implement Base64 decoding intrinsic src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5811: > 5809: __ ldrb(r12, __ post(src, 1)); > 5810: __ ldrb(r13, __ post(src, 1)); > 5811: // get the de-code For loads and four post increments rather than one load and a few BFMs? Why? ------------- PR: https://git.openjdk.java.net/jdk/pull/3228 From aph at openjdk.java.net Fri Apr 2 08:49:24 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Fri, 2 Apr 2021 08:49:24 GMT Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic In-Reply-To: <_ZrhnM9OyXLckhtT27laLzWPZbCFZTPjm6ePbZdbyOs=.fcc6aaba-1578-443a-aa57-8141a99231f6@github.com> References: <_ZrhnM9OyXLckhtT27laLzWPZbCFZTPjm6ePbZdbyOs=.fcc6aaba-1578-443a-aa57-8141a99231f6@github.com> Message-ID: On Mon, 29 Mar 2021 03:28:54 GMT, Dong Bo wrote: > > Please consider losing the non-SIMD case. It doesn't result in any significant gain. > > The non-SIMD case is useful for MIME decoding performance. Your test results suggest that it isn't useful for that, surely? ------------- PR: https://git.openjdk.java.net/jdk/pull/3228 From ngasson at openjdk.java.net Fri Apr 2 09:08:41 2021 From: ngasson at openjdk.java.net (Nick Gasson) Date: Fri, 2 Apr 2021 09:08:41 GMT Subject: RFR: 8264564: AArch64: use MOVI instead of FMOV to zero FP register Message-ID: HotSpot generates an FMOV from ZR to zero a floating point register: fmov d0, xzr This used to be recommended by the Arm ARM, but that advice was removed in revision A.j and subsequent revisions (section C.5.3). Integer->FP moves may be slow on some cores. Instead the preferred instruction is MOVI with immediate zero: movi d0, #0x0 Some micro-architectures special-case FMOV from ZR, and on those cores this change will have no effect, but in any case FMOV won't be faster than MOVI. GCC made this change back in 2016: https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=523d72071960 Tested tier1 on AArch64. I don't expect this to have any visible effect on benchmarks. ------------- Commit messages: - 8264564: AArch64: use MOVI instead of FMOV to zero FP register Changes: https://git.openjdk.java.net/jdk/pull/3322/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3322&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264564 Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/3322.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3322/head:pull/3322 PR: https://git.openjdk.java.net/jdk/pull/3322 From yyang at openjdk.java.net Fri Apr 2 09:49:45 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Fri, 2 Apr 2021 09:49:45 GMT Subject: RFR: 8264644: More complete ClassLoaderData for cld->print() Message-ID: Trivial chanage to make debugging happy, now cld->print() would be: ClassLoaderData(0x00007ff17432b670) - name 'platform' - holder WeakHandle: 0x00000007fef56678 - class loader 0x7ff17432b828 - metaspace 0x7ff17468a0b0 - unloading false - class mirror holder false - modified oops true - keep alive 0 - claim strong - handles 43 - dependency count 0 - klasses {java.sql.SQLFeatureNotSupportedException,java.sql.SQLNonTransientException,java.sql.SQLException,sun.util.resources.provider.NonBaseLocaleDataMetaInfo,org.ietf.jgss.GSSException,javax.sql.DataSource,java.sql.Wrapper,javax.sql.CommonDataSource,java.sql.Time,java.sql.Date,java.sql.Timestamp,sun.util.resources.cldr.provider.CLDRLocaleDataMetaInfo, } - packages 0x7ff17432bc20 - module 0x7ff17432c520 - unnamed module 0x7ff17432c3d0 - dictionary 0x7ff17432c470 - deallocate list 0x7ff0a4023bd0 ------------- Commit messages: - make debugging happy Changes: https://git.openjdk.java.net/jdk/pull/3323/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3323&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264644 Stats: 52 lines in 2 files changed: 40 ins; 4 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/3323.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3323/head:pull/3323 PR: https://git.openjdk.java.net/jdk/pull/3323 From aph at openjdk.java.net Fri Apr 2 10:17:22 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Fri, 2 Apr 2021 10:17:22 GMT Subject: RFR: 8264564: AArch64: use MOVI instead of FMOV to zero FP register In-Reply-To: References: Message-ID: <8XYUkQBQmuPEbLwY0PZBB8-2k5HbC9V_YaO_ZiIU9g8=.7e685457-6b66-4ee7-bea2-7434ca017d22@github.com> On Fri, 2 Apr 2021 09:02:36 GMT, Nick Gasson wrote: > HotSpot generates an FMOV from ZR to zero a floating point register: > > fmov d0, xzr > > This used to be recommended by the Arm ARM, but that advice was removed > in revision A.j and subsequent revisions (section C.5.3). > > Integer->FP moves may be slow on some cores. Instead the preferred > instruction is MOVI with immediate zero: > > movi d0, #0x0 > > Some micro-architectures special-case FMOV from ZR, and on those cores > this change will have no effect, but in any case FMOV won't be faster > than MOVI. > > GCC made this change back in 2016: > https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=523d72071960 > > Tested tier1 on AArch64. I don't expect this to have any visible effect > on benchmarks. Marked as reviewed by aph (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3322 From aph at openjdk.java.net Fri Apr 2 10:20:25 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Fri, 2 Apr 2021 10:20:25 GMT Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v3] In-Reply-To: <96N9BNz7s4JH99-5lQio5uEP8iAa4YEmn9NK-dUyvCQ=.c663f383-f207-45c3-97bf-b5309b624315@github.com> References: <96N9BNz7s4JH99-5lQio5uEP8iAa4YEmn9NK-dUyvCQ=.c663f383-f207-45c3-97bf-b5309b624315@github.com> Message-ID: On Fri, 2 Apr 2021 03:10:57 GMT, Dong Bo wrote: >> In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding. >> Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic idea can be found at http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords. >> >> Patch passed jtreg tier1-3 tests with linux-aarch64-server-fastdebug build. >> Tests in `test/jdk/java/util/Base64/` and `compiler/intrinsics/base64/TestBase64.java` runned specially for the correctness of the implementation. >> >> There can be illegal characters at the start of the input if the data is MIME encoded. >> It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now. >> >> A JMH micro, Base64Decode.java, is added for performance test. >> With different input length (upper-bounded by parameter `maxNumBytes` in the JMH micro), >> we witness ~2.5x improvements with long inputs and no regression with short inputs for raw base64 decodeing, minor improvements (~10.95%) for MIME on Kunpeng916. >> >> The Base64Decode.java JMH micro-benchmark results: >> >> Benchmark (lineSize) (maxNumBytes) Mode Cnt Score Error Units >> >> # Kunpeng916, intrinsic >> Base64Decode.testBase64Decode 4 1 avgt 5 48.614 ? 0.609 ns/op >> Base64Decode.testBase64Decode 4 3 avgt 5 58.199 ? 1.650 ns/op >> Base64Decode.testBase64Decode 4 7 avgt 5 69.400 ? 0.931 ns/op >> Base64Decode.testBase64Decode 4 32 avgt 5 96.818 ? 1.687 ns/op >> Base64Decode.testBase64Decode 4 64 avgt 5 122.856 ? 9.217 ns/op >> Base64Decode.testBase64Decode 4 80 avgt 5 130.935 ? 1.667 ns/op >> Base64Decode.testBase64Decode 4 96 avgt 5 143.627 ? 1.751 ns/op >> Base64Decode.testBase64Decode 4 112 avgt 5 152.311 ? 1.178 ns/op >> Base64Decode.testBase64Decode 4 512 avgt 5 342.631 ? 0.584 ns/op >> Base64Decode.testBase64Decode 4 1000 avgt 5 573.635 ? 1.050 ns/op >> Base64Decode.testBase64Decode 4 20000 avgt 5 9534.136 ? 45.172 ns/op >> Base64Decode.testBase64Decode 4 50000 avgt 5 22718.726 ? 192.070 ns/op >> Base64Decode.testBase64MIMEDecode 4 1 avgt 10 63.558 ? 0.336 ns/op >> Base64Decode.testBase64MIMEDecode 4 3 avgt 10 82.504 ? 0.848 ns/op >> Base64Decode.testBase64MIMEDecode 4 7 avgt 10 120.591 ? 0.608 ns/op >> Base64Decode.testBase64MIMEDecode 4 32 avgt 10 324.314 ? 6.236 ns/op >> Base64Decode.testBase64MIMEDecode 4 64 avgt 10 532.678 ? 4.670 ns/op >> Base64Decode.testBase64MIMEDecode 4 80 avgt 10 678.126 ? 4.324 ns/op >> Base64Decode.testBase64MIMEDecode 4 96 avgt 10 771.603 ? 6.393 ns/op >> Base64Decode.testBase64MIMEDecode 4 112 avgt 10 889.608 ? 0.759 ns/op >> Base64Decode.testBase64MIMEDecode 4 512 avgt 10 3663.557 ? 3.422 ns/op >> Base64Decode.testBase64MIMEDecode 4 1000 avgt 10 7017.784 ? 9.128 ns/op >> Base64Decode.testBase64MIMEDecode 4 20000 avgt 10 128670.660 ? 7951.521 ns/op >> Base64Decode.testBase64MIMEDecode 4 50000 avgt 10 317113.667 ? 161.758 ns/op >> >> # Kunpeng916, default >> Base64Decode.testBase64Decode 4 1 avgt 5 48.455 ? 0.571 ns/op >> Base64Decode.testBase64Decode 4 3 avgt 5 57.937 ? 0.505 ns/op >> Base64Decode.testBase64Decode 4 7 avgt 5 73.823 ? 1.452 ns/op >> Base64Decode.testBase64Decode 4 32 avgt 5 106.484 ? 1.243 ns/op >> Base64Decode.testBase64Decode 4 64 avgt 5 141.004 ? 1.188 ns/op >> Base64Decode.testBase64Decode 4 80 avgt 5 156.284 ? 0.572 ns/op >> Base64Decode.testBase64Decode 4 96 avgt 5 174.137 ? 0.177 ns/op >> Base64Decode.testBase64Decode 4 112 avgt 5 188.445 ? 0.572 ns/op >> Base64Decode.testBase64Decode 4 512 avgt 5 610.847 ? 1.559 ns/op >> Base64Decode.testBase64Decode 4 1000 avgt 5 1155.368 ? 0.813 ns/op >> Base64Decode.testBase64Decode 4 20000 avgt 5 19751.477 ? 24.669 ns/op >> Base64Decode.testBase64Decode 4 50000 avgt 5 50046.586 ? 523.155 ns/op >> Base64Decode.testBase64MIMEDecode 4 1 avgt 10 64.130 ? 0.238 ns/op >> Base64Decode.testBase64MIMEDecode 4 3 avgt 10 82.096 ? 0.205 ns/op >> Base64Decode.testBase64MIMEDecode 4 7 avgt 10 118.849 ? 0.610 ns/op >> Base64Decode.testBase64MIMEDecode 4 32 avgt 10 331.177 ? 4.732 ns/op >> Base64Decode.testBase64MIMEDecode 4 64 avgt 10 549.117 ? 0.177 ns/op >> Base64Decode.testBase64MIMEDecode 4 80 avgt 10 702.951 ? 4.572 ns/op >> Base64Decode.testBase64MIMEDecode 4 96 avgt 10 799.566 ? 0.301 ns/op >> Base64Decode.testBase64MIMEDecode 4 112 avgt 10 923.749 ? 0.389 ns/op >> Base64Decode.testBase64MIMEDecode 4 512 avgt 10 4000.725 ? 2.519 ns/op >> Base64Decode.testBase64MIMEDecode 4 1000 avgt 10 7674.994 ? 9.281 ns/op >> Base64Decode.testBase64MIMEDecode 4 20000 avgt 10 142059.001 ? 157.920 ns/op >> Base64Decode.testBase64MIMEDecode 4 50000 avgt 10 355698.369 ? 216.542 ns/op > > Dong Bo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Merge branch 'master' into aarch64.base64.decode > - copyright > - trivial fixes > - Handling error in SIMD case with loops, combining two non-SIMD cases into one code blob, addressing other comments > - Merge branch 'master' into aarch64.base64.decode > - 8256245: AArch64: Implement Base64 decoding intrinsic src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5802: > 5800: // The 1st character of the input can be illegal if the data is MIME encoded. > 5801: // We cannot benefits from SIMD for this case. The max line size of MIME > 5802: // encoding is 76, with the PreProcess80B blob, we actually use no-simd "cannot benefit" ------------- PR: https://git.openjdk.java.net/jdk/pull/3228 From aph at openjdk.java.net Fri Apr 2 10:20:20 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Fri, 2 Apr 2021 10:20:20 GMT Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic In-Reply-To: References: <_ZrhnM9OyXLckhtT27laLzWPZbCFZTPjm6ePbZdbyOs=.fcc6aaba-1578-443a-aa57-8141a99231f6@github.com> Message-ID: On Fri, 2 Apr 2021 07:05:26 GMT, Dong Bo wrote: > PING... Any suggestions on the updated commit? Once you reply to the comments, sure. ------------- PR: https://git.openjdk.java.net/jdk/pull/3228 From coleenp at openjdk.java.net Fri Apr 2 12:50:22 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 2 Apr 2021 12:50:22 GMT Subject: RFR: 8264644: More complete ClassLoaderData for cld->print() In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 09:42:01 GMT, Yi Yang wrote: > Trivial chanage to make debugging happy, now cld->print() would be: > > ClassLoaderData(0x00007ff17432b670) > - name 'platform' > - holder WeakHandle: 0x00000007fef56678 > - class loader 0x7ff17432b828 > - metaspace 0x7ff17468a0b0 > - unloading false > - class mirror holder false > - modified oops true > - keep alive 0 > - claim strong > - handles 43 > - dependency count 0 > - klasses {java.sql.SQLFeatureNotSupportedException,java.sql.SQLNonTransientException,java.sql.SQLException,sun.util.resources.provider.NonBaseLocaleDataMetaInfo,org.ietf.jgss.GSSException,javax.sql.DataSource,java.sql.Wrapper,javax.sql.CommonDataSource,java.sql.Time,java.sql.Date,java.sql.Timestamp,sun.util.resources.cldr.provider.CLDRLocaleDataMetaInfo, } > - packages 0x7ff17432bc20 > - module 0x7ff17432c520 > - unnamed module 0x7ff17432c3d0 > - dictionary 0x7ff17432c470 > - deallocate list 0x7ff0a4023bd0 This looks nice. If you use -XX:+PrintSystemDictionaryAtExit with this change, is it pages and pages long? Or does it look ok? Thank you for doing this! src/hotspot/share/classfile/classLoaderData.cpp line 950: > 948: out->print (" - holder "); > 949: _holder.print_on(out); > 950: out->print_cr(""); indent 2 here. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3323 From hseigel at openjdk.java.net Fri Apr 2 13:01:11 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Fri, 2 Apr 2021 13:01:11 GMT Subject: RFR: 8262280: Incorrect exception handling for VMThread in class redefinition In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 16:58:00 GMT, Coleen Phillimore wrote: > This is a trivial change to remove the last TRAPS from redefine_single_class which is called by the VM thread during a safepoint. > Tested with serviceability/jvmti/RedefineClasses, vmTestbase/nsk/jvmti,jdi and jdk/java/lang/instrument tests. And tier1 sanity in progress. The changes look good and trivial. Thank! Harold ------------- Marked as reviewed by hseigel (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3310 From coleenp at openjdk.java.net Fri Apr 2 13:09:30 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 2 Apr 2021 13:09:30 GMT Subject: Integrated: 8262280: Incorrect exception handling for VMThread in class redefinition In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 16:58:00 GMT, Coleen Phillimore wrote: > This is a trivial change to remove the last TRAPS from redefine_single_class which is called by the VM thread during a safepoint. > Tested with serviceability/jvmti/RedefineClasses, vmTestbase/nsk/jvmti,jdi and jdk/java/lang/instrument tests. And tier1 sanity in progress. This pull request has now been integrated. Changeset: 885916ed Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/885916ed Stats: 19 lines in 2 files changed: 0 ins; 0 del; 19 mod 8262280: Incorrect exception handling for VMThread in class redefinition Reviewed-by: hseigel ------------- PR: https://git.openjdk.java.net/jdk/pull/3310 From coleenp at openjdk.java.net Fri Apr 2 13:09:29 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 2 Apr 2021 13:09:29 GMT Subject: RFR: 8262280: Incorrect exception handling for VMThread in class redefinition In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 12:58:18 GMT, Harold Seigel wrote: >> This is a trivial change to remove the last TRAPS from redefine_single_class which is called by the VM thread during a safepoint. >> Tested with serviceability/jvmti/RedefineClasses, vmTestbase/nsk/jvmti,jdi and jdk/java/lang/instrument tests. And tier1 sanity in progress. > > The changes look good and trivial. > Thank! Harold Thanks Harold! ------------- PR: https://git.openjdk.java.net/jdk/pull/3310 From yyang at openjdk.java.net Fri Apr 2 14:43:35 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Fri, 2 Apr 2021 14:43:35 GMT Subject: RFR: 8264644: More complete ClassLoaderData for cld->print() In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 12:47:04 GMT, Coleen Phillimore wrote: >> Trivial chanage to make debugging happy, now cld->print() would be: >> >> ClassLoaderData(0x00007ff17432b670) >> - name 'platform' >> - holder WeakHandle: 0x00000007fef56678 >> - class loader 0x7ff17432b828 >> - metaspace 0x7ff17468a0b0 >> - unloading false >> - class mirror holder false >> - modified oops true >> - keep alive 0 >> - claim strong >> - handles 43 >> - dependency count 0 >> - klasses {java.sql.SQLFeatureNotSupportedException,java.sql.SQLNonTransientException,java.sql.SQLException,sun.util.resources.provider.NonBaseLocaleDataMetaInfo,org.ietf.jgss.GSSException,javax.sql.DataSource,java.sql.Wrapper,javax.sql.CommonDataSource,java.sql.Time,java.sql.Date,java.sql.Timestamp,sun.util.resources.cldr.provider.CLDRLocaleDataMetaInfo, } >> - packages 0x7ff17432bc20 >> - module 0x7ff17432c520 >> - unnamed module 0x7ff17432c3d0 >> - dictionary 0x7ff17432c470 >> - deallocate list 0x7ff0a4023bd0 > > This looks nice. If you use -XX:+PrintSystemDictionaryAtExit with this change, is it pages and pages long? Or does it look ok? Thank you for doing this! Hi @coleenp, thanks for looking at this, it does outputs too detailed content for klasses(actually that's what I want to see), if you think it is too much detail for most people, I can print detailed content of klasses of CLD only when -XX:+Verbose. ... ClassLoaderData(0x00007fea483e5a50) - name 'app' - holder WeakHandle: 0x00000007fef56d98 - class loader 0x7fea483e5c08 - metaspace (nil) - unloading false - class mirror holder false - modified oops true - keep alive 0 - claim none - handles 20 - dependency count 0 - klasses { } - packages 0x7fea483e5df0 - module 0x7fea483ea640 - unnamed module 0x7fea483e65a0 - dictionary 0x7fea483e6640 - deallocate list (nil) ClassLoaderData(0x00007fea482ee640) - name 'platform' - holder WeakHandle: 0x00000007fef56678 - class loader 0x7fea482ee7f8 - metaspace (nil) - unloading false - class mirror holder false - modified oops true - keep alive 0 - claim none - handles 24 - dependency count 0 - klasses { } - packages 0x7fea482eebf0 - module 0x7fea482ef4f0 - unnamed module 0x7fea482ef3a0 - dictionary 0x7fea482ef440 - deallocate list (nil) ClassLoaderData(0x00007fea482e01f0) - name 'bootstrap' - class loader (nil) - metaspace 0x7fea48391b60 - unloading false - class mirror holder false - modified oops true - keep alive 1 - claim none - handles 668 - dependency count 0 - klasses {java.lang.Shutdown$Lock,java.lang.Shutdown,[Ljava.nio.charset.CoderResult;,java.nio.charset.CoderResult,java.nio.HeapCharBuffer,java.nio.CharBuffer,java.lang.Readable,java.lang.invoke.StringConcatFactory$3,java.lang.invoke.StringConcatFactory$2,java.lang.invoke.StringConcatFactory$1,java.lang.invoke.StringConcatFactory,jdk.internal.util.Preconditions,sun.net.util.IPAddressUtil,sun.net.www.protocol.file.Handler,java.net.URLStreamHandler,java.util.HexFormat,sun.net.www.ParseUtil,[Ljava.io.File$PathStatus;,java.io.File$PathStatus,java.net.URL$3,jdk.internal.access.JavaNetURLAccess,java.net.URL$DefaultFactory,java.net.URLStreamHandlerFactory,jdk.internal.loader.URLClassPath,jdk.internal.loader.BootLoader,java.util.ArrayDeque,java.util.Deque,java.util.Queue,jdk.internal.loader.NativeLibraries$2,jdk.internal.loader.NativeLibraries$NativeLibraryImpl,jdk.internal.loader.NativeLibrary,java.security.ProtectionDomain$JavaSecurityAccessImpl,jdk.internal.access.JavaSecurit yAccess,java.util.WeakHashMap$KeySet,java.util.Collections$SetFromMap,[Ljava.util.WeakHashMap$Entry;,java.util.WeakHashMap$Entry,java.util.WeakHashMap,java.lang.ClassLoader$ParallelLoaders,[Ljava.security.cert.Certificate;,java.security.cert.Certificate,java.net.URI$1,jdk.internal.access.JavaNetUriAccess,jdk.internal.loader.ClassLoaderValue,jdk.internal.loader.AbstractClassLoaderValue,jdk.internal.module.ModuleBootstrap$Counters,jdk.internal.module.ModulePatcher,jdk.internal.util.ArraysSupport,java.io.UnixFileSystem,java.io.FileSystem,java.io.DefaultFileSystem,java.io.File,java.lang.module.ModuleDescriptor$1,jdk.internal.access.JavaLangModuleAccess,java.lang.reflect.Modifier,sun.invoke.util.VerifyAccess,jdk.internal.module.ModuleBootstrap,java.lang.invoke.MethodHandleStatics,java.lang.IllegalArgumentException,java.util.Collections$EmptyMap,java.util.Collections$EmptyList,java.util.Collections$EmptySet,java.util.Collections,jdk.internal.misc.OSEnvironment,jdk.internal.misc.Signal$Nat iveHandler,[Ljava.util.Hashtable$Entry;,java.util.Hashtable$Entry,jdk.internal.misc.Signal,java.lang.Terminator$1,jdk.internal.misc.Signal$Handler,java.lang.Terminator,java.io.BufferedWriter,java.nio.ByteOrder,java.nio.HeapByteBuffer,java.nio.Buffer$1,jdk.internal.access.JavaNioAccess,jdk.internal.misc.ScopedMemoryAccess,java.nio.ByteBuffer,java.nio.charset.CodingErrorAction,sun.nio.cs.UTF_8$Encoder,java.nio.charset.CharsetEncoder,sun.nio.cs.StreamEncoder,sun.nio.cs.UTF_8,sun.nio.cs.Unicode,sun.nio.cs.HistoricallyNamedCharset,sun.security.action.GetPropertyAction,java.util.concurrent.atomic.AtomicInteger,java.lang.ThreadLocal,sun.nio.cs.StandardCharsets,java.nio.charset.spi.CharsetProvider,java.nio.charset.Charset,java.io.OutputStreamWriter,java.io.Writer,java.io.BufferedOutputStream,java.io.PrintStream,java.io.FilterOutputStream,java.io.BufferedInputStream,java.io.FilterInputStream,java.io.FileOutputStream,java.io.OutputStream,java.io.Flushable,java.io.FileDescriptor$1,jdk.internal .access.JavaIOFileDescriptorAccess,java.io.FileDescriptor,java.io.FileInputStream,jdk.internal.util.StaticProperty,java.util.HashMap$EntryIterator,java.util.HashMap$HashIterator,java.util.HashMap$EntrySet,java.lang.CharacterDataLatin1,java.lang.CharacterData,java.util.Arrays,java.lang.VersionProps,java.lang.StringConcatHelper,jdk.internal.util.SystemProps$Raw,jdk.internal.util.SystemProps,jdk.internal.misc.VM,java.lang.System$2,jdk.internal.access.JavaLangAccess,java.lang.ref.Finalizer$FinalizerThread,java.lang.ref.Reference$1,jdk.internal.access.JavaLangRefAccess,java.lang.ref.ReferenceQueue$Lock,java.lang.ref.ReferenceQueue$Null,java.lang.ref.ReferenceQueue,jdk.internal.ref.Cleaner,java.lang.ref.Reference$ReferenceHandler,jdk.internal.reflect.ReflectionFactory,jdk.internal.reflect.ReflectionFactory$GetReflectionFactoryAction,java.security.PrivilegedAction,java.util.concurrent.ConcurrentHashMap$ReservationNode,java.util.concurrent.locks.LockSupport,java.util.concurrent.ConcurrentHa shMap$CounterCell,[Ljava.util.concurrent.ConcurrentHashMap$Segment;,java.util.concurrent.ConcurrentHashMap$Segment,[Ljava.util.concurrent.locks.ReentrantLock;,java.util.concurrent.locks.ReentrantLock,[Ljava.util.concurrent.locks.Lock;,java.util.concurrent.locks.Lock,java.lang.Runtime,java.util.HashMap$TreeNode,java.util.LinkedHashMap$Entry,java.util.KeyValueHolder,java.util.ImmutableCollections$MapN$MapNIterator,java.util.ImmutableCollections$MapN$1,java.lang.Math,jdk.internal.reflect.Reflection,java.util.Objects,java.lang.invoke.MethodHandles$Lookup,java.lang.StringLatin1,java.lang.reflect.ReflectPermission,java.security.BasicPermission,java.security.Permission,java.security.Guard,java.lang.invoke.MemberName$Factory,java.lang.invoke.MethodHandles,jdk.internal.access.SharedSecrets,java.lang.reflect.ReflectAccess,jdk.internal.access.JavaLangReflectAccess,jdk.internal.misc.CDS,java.lang.String$CaseInsensitiveComparator,java.util.Comparator,[Ljava.io.ObjectStreamField;,java.io.ObjectSt reamField,[Ljava.util.jar.Manifest;,[Ljava.net.URL;,java.lang.ArithmeticException,java.lang.NullPointerException,[J,[[I,[I,[S,[B,[D,[F,[C,[Z,java.lang.Module$ArchivedData,jdk.internal.module.ArchivedBootLayer,jdk.internal.loader.BuiltinClassLoader$LoadedModule,java.util.HashSet,java.util.AbstractSet,[Ljdk.internal.module.ServicesCatalog$ServiceProvider;,jdk.internal.module.ServicesCatalog$ServiceProvider,java.util.concurrent.CopyOnWriteArrayList,[Ljdk.internal.module.ServicesCatalog;,jdk.internal.module.ServicesCatalog,[Ljava.util.concurrent.ConcurrentHashMap$Node;,java.util.concurrent.ConcurrentHashMap$Node,jdk.internal.loader.NativeLibraries,java.security.ProtectionDomain$Key,[Ljava.security.Principal;,java.security.Principal,jdk.internal.loader.ClassLoaders$BootClassLoader,jdk.internal.loader.ArchivedClassLoaders,[Ljdk.internal.math.FDBigInteger;,jdk.internal.math.FDBigInteger,java.lang.ModuleLayer,java.util.ImmutableCollections,jdk.internal.module.ModuleLoaderMap$Mapper,java.uti l.function.Function,[Ljava.lang.module.ResolvedModule;,java.lang.module.ResolvedModule,java.lang.module.Configuration,[Ljava.util.HashMap$Node;,java.util.HashMap$Node,[Ljava.util.Map$Entry;,java.util.Map$Entry,java.util.HashMap,java.util.Collections$UnmodifiableMap,[Ljdk.internal.module.ModuleHashes;,jdk.internal.module.ModuleHashes,[Ljdk.internal.module.ModuleTarget;,jdk.internal.module.ModuleTarget,java.util.ImmutableCollections$ListN,[Ljava.lang.module.ModuleDescriptor$Opens;,java.lang.module.ModuleDescriptor$Opens,jdk.internal.module.SystemModuleFinders$3,jdk.internal.module.ModuleHashes$HashSupplier,jdk.internal.module.SystemModuleFinders$2,java.util.function.Supplier,java.net.URI,java.util.ImmutableCollections$List12,java.util.ImmutableCollections$AbstractImmutableList,[Ljava.lang.module.ModuleDescriptor$Provides;,java.lang.module.ModuleDescriptor$Provides,[Ljava.lang.module.ModuleDescriptor$Exports;,java.lang.module.ModuleDescriptor$Exports,[Ljava.lang.module.ModuleDescriptor $Requires$Modifier;,java.lang.module.ModuleDescriptor$Requires$Modifier,[Ljava.lang.Enum;,java.lang.Enum,[Ljava.lang.module.ModuleDescriptor$Requires;,java.lang.module.ModuleDescriptor$Requires,java.util.ImmutableCollections$Set12,java.lang.module.ModuleDescriptor$Version,[Ljava.lang.module.ModuleDescriptor;,java.lang.module.ModuleDescriptor,jdk.internal.module.ModuleReferenceImpl,[Ljava.lang.module.ModuleReference;,java.lang.module.ModuleReference,java.util.ImmutableCollections$SetN,java.util.ImmutableCollections$AbstractImmutableSet,java.util.Set,java.util.ImmutableCollections$AbstractImmutableCollection,jdk.internal.module.SystemModuleFinders$SystemModuleFinder,java.lang.module.ModuleFinder,jdk.internal.module.ArchivedModuleGraph,[Lsun.util.locale.BaseLocale;,sun.util.locale.BaseLocale,java.util.ImmutableCollections$MapN,java.util.ImmutableCollections$AbstractImmutableMap,java.util.jar.Attributes$Name,java.lang.Character$CharacterCache,java.lang.Short$ShortCache,java.lang.Byte$By teCache,java.lang.Long$LongCache,java.lang.Integer$IntegerCache,jdk.internal.vm.vector.VectorSupport$VectorShuffle,jdk.internal.vm.vector.VectorSupport$VectorMask,jdk.internal.vm.vector.VectorSupport$Vector,jdk.internal.vm.vector.VectorSupport$VectorPayload,jdk.internal.vm.vector.VectorSupport,java.lang.reflect.RecordComponent,java.util.Iterator,[Ljava.lang.Long;,java.lang.Long,[Ljava.lang.Integer;,java.lang.Integer,[Ljava.lang.Short;,java.lang.Short,[Ljava.lang.Byte;,java.lang.Byte,java.lang.Double,java.lang.Float,[Ljava.lang.Number;,java.lang.Number,[Ljava.lang.Character;,java.lang.Character,java.lang.Boolean,java.util.concurrent.locks.AbstractOwnableSynchronizer,java.lang.LiveStackFrameInfo,java.lang.LiveStackFrame,java.lang.StackFrameInfo,java.lang.StackWalker$StackFrame,java.lang.StackStreamFactory$AbstractStackWalker,java.lang.StackWalker,java.nio.Buffer,[Ljava.lang.StackTraceElement;,java.lang.StackTraceElement,java.util.ArrayList,java.util.RandomAccess,java.util.AbstractList ,java.util.List,java.util.AbstractCollection,java.util.Collection,java.lang.Iterable,java.util.concurrent.ConcurrentHashMap,java.util.concurrent.ConcurrentMap,java.util.AbstractMap,java.security.CodeSource,jdk.internal.loader.ClassLoaders$PlatformClassLoader,jdk.internal.loader.ClassLoaders$AppClassLoader,jdk.internal.loader.ClassLoaders,jdk.internal.loader.BuiltinClassLoader,java.util.jar.Manifest,java.net.URL,java.io.ByteArrayInputStream,java.io.InputStream,java.io.Closeable,java.lang.AutoCloseable,jdk.internal.module.Modules,jdk.internal.misc.Unsafe,jdk.internal.misc.UnsafeConstants,java.lang.StringBuilder,java.lang.StringBuffer,java.lang.AbstractStringBuilder,java.lang.Appendable,java.lang.AssertionStatusDirectives,java.lang.invoke.VolatileCallSite,java.lang.invoke.MutableCallSite,java.lang.invoke.ConstantCallSite,java.lang.invoke.MethodHandleNatives$CallSiteContext,jdk.internal.invoke.NativeEntryPoint,java.lang.invoke.CallSite,java.lang.BootstrapMethodError,[Ljava.lang.invoke.M ethodType;,java.lang.invoke.MethodType,[Ljava.lang.invoke.TypeDescriptor$OfMethod;,java.lang.invoke.TypeDescriptor$OfMethod,[Ljava.lang.invoke.LambdaForm;,java.lang.invoke.LambdaForm,java.lang.invoke.MethodHandleNatives,java.lang.invoke.ResolvedMethodName,java.lang.invoke.MemberName,java.lang.invoke.VarHandle,java.lang.invoke.DirectMethodHandle,[Ljava.lang.invoke.MethodHandle;,java.lang.invoke.MethodHandle,jdk.internal.reflect.NativeConstructorAccessorImpl,jdk.internal.reflect.CallerSensitive,[Ljava.lang.annotation.Annotation;,java.lang.annotation.Annotation,jdk.internal.reflect.UnsafeStaticFieldAccessorImpl,jdk.internal.reflect.UnsafeFieldAccessorImpl,jdk.internal.reflect.FieldAccessorImpl,jdk.internal.reflect.FieldAccessor,jdk.internal.reflect.ConstantPool,jdk.internal.reflect.DelegatingClassLoader,jdk.internal.reflect.ConstructorAccessorImpl,jdk.internal.reflect.ConstructorAccessor,jdk.internal.reflect.MethodAccessorImpl,jdk.internal.reflect.MethodAccessor,jdk.internal.reflect.Ma gicAccessorImpl,[Ljava.lang.reflect.Constructor;,java.lang.reflect.Constructor,[Ljava.lang.reflect.Method;,java.lang.reflect.Method,[Ljava.lang.reflect.Executable;,java.lang.reflect.Executable,java.lang.reflect.Parameter,java.lang.reflect.Field,[Ljava.lang.reflect.Member;,java.lang.reflect.Member,[Ljava.lang.reflect.AccessibleObject;,java.lang.reflect.AccessibleObject,[Ljava.lang.Module;,java.lang.Module,java.util.Properties,java.util.Hashtable,java.util.Map,java.util.Dictionary,[Ljava.lang.ThreadGroup;,java.lang.ThreadGroup,[Ljava.lang.Thread$UncaughtExceptionHandler;,java.lang.Thread$UncaughtExceptionHandler,[Ljava.lang.Thread;,java.lang.Thread,[Ljava.lang.Runnable;,java.lang.Runnable,java.lang.ref.Finalizer,java.lang.ref.PhantomReference,java.lang.ref.FinalReference,[Ljava.lang.ref.WeakReference;,java.lang.ref.WeakReference,[Ljava.lang.ref.SoftReference;,java.lang.ref.SoftReference,[Ljava.lang.ref.Reference;,java.lang.ref.Reference,java.lang.IllegalMonitorStateException,java.lang .StackOverflowError,[Ljava.lang.OutOfMemoryError;,java.lang.OutOfMemoryError,java.lang.InternalError,[Ljava.lang.VirtualMachineError;,java.lang.VirtualMachineError,java.lang.ArrayStoreException,java.lang.ClassCastException,java.lang.NoClassDefFoundError,java.lang.LinkageError,java.lang.Record,java.lang.ClassNotFoundException,java.lang.ReflectiveOperationException,java.security.SecureClassLoader,java.security.AccessController,java.security.AccessControlContext,[Ljava.security.ProtectionDomain;,java.security.ProtectionDomain,java.lang.SecurityManager,java.lang.RuntimeException,java.lang.Exception,java.lang.ThreadDeath,[Ljava.lang.Error;,java.lang.Error,[Ljava.lang.Throwable;,java.lang.Throwable,java.lang.System,[Ljava.lang.ClassLoader;,java.lang.ClassLoader,[Ljava.lang.Cloneable;,java.lang.Cloneable,[Ljava.lang.Class;,java.lang.Class,[Ljava.lang.invoke.TypeDescriptor$OfField;,java.lang.invoke.TypeDescriptor$OfField,[Ljava.lang.invoke.TypeDescriptor;,java.lang.invoke.TypeDescriptor,[Lj ava.lang.reflect.Type;,java.lang.reflect.Type,[Ljava.lang.reflect.GenericDeclaration;,java.lang.reflect.GenericDeclaration,[Ljava.lang.reflect.AnnotatedElement;,java.lang.reflect.AnnotatedElement,[Ljava.lang.String;,java.lang.String,[Ljava.lang.constant.ConstantDesc;,java.lang.constant.ConstantDesc,[Ljava.lang.constant.Constable;,java.lang.constant.Constable,[Ljava.lang.CharSequence;,java.lang.CharSequence,[Ljava.lang.Comparable;,java.lang.Comparable,[Ljava.io.Serializable;,java.io.Serializable,[[Ljava.lang.Object;,[Ljava.lang.Object;,java.lang.Object, } - packages 0x7fea482e03a0 - module 0x7fea482e5030 - unnamed module 0x7fea482e0b50 - dictionary 0x7fea482e0bf0 - jmethod count 3 - deallocate list (nil) ------------- PR: https://git.openjdk.java.net/jdk/pull/3323 From coleenp at openjdk.java.net Fri Apr 2 15:03:22 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 2 Apr 2021 15:03:22 GMT Subject: RFR: 8264644: More complete ClassLoaderData for cld->print() In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 14:40:25 GMT, Yi Yang wrote: >> This looks nice. If you use -XX:+PrintSystemDictionaryAtExit with this change, is it pages and pages long? Or does it look ok? Thank you for doing this! > > Hi @coleenp, thanks for looking at this, it does outputs too detailed content for klasses(actually that's what I want to see), if you think it is too much detail for most people, I can print detailed content of klasses of CLD only when -XX:+Verbose. > ... > ClassLoaderData(0x00007fea483e5a50) > - name 'app' > - holder WeakHandle: 0x00000007fef56d98 > - class loader 0x7fea483e5c08 > - metaspace (nil) > - unloading false > - class mirror holder false > - modified oops true > - keep alive 0 > - claim none > - handles 20 > - dependency count 0 > - klasses { } > - packages 0x7fea483e5df0 > - module 0x7fea483ea640 > - unnamed module 0x7fea483e65a0 > - dictionary 0x7fea483e6640 > - deallocate list (nil) > ClassLoaderData(0x00007fea482ee640) > - name 'platform' > - holder WeakHandle: 0x00000007fef56678 > - class loader 0x7fea482ee7f8 > - metaspace (nil) > - unloading false > - class mirror holder false > - modified oops true > - keep alive 0 > - claim none > - handles 24 > - dependency count 0 > - klasses { } > - packages 0x7fea482eebf0 > - module 0x7fea482ef4f0 > - unnamed module 0x7fea482ef3a0 > - dictionary 0x7fea482ef440 > - deallocate list (nil) > ClassLoaderData(0x00007fea482e01f0) > - name 'bootstrap' > - class loader (nil) > - metaspace 0x7fea48391b60 > - unloading false > - class mirror holder false > - modified oops true > - keep alive 1 > - claim none > - handles 668 > - dependency count 0 > - klasses {java.lang.Shutdown$Lock,java.lang.Shutdown,[Ljava.nio.charset.CoderResult;,java.nio.charset.CoderResult,java.nio.HeapCharBuffer,java.nio.CharBuffer,java.lang.Readable,java.lang.invoke.StringConcatFactory$3,java.lang.invoke.StringConcatFactory$2,java.lang.invoke.StringConcatFactory$1,java.lang.invoke.StringConcatFactory,jdk.internal.util.Preconditions,sun.net.util.IPAddressUtil,sun.net.www.protocol.file.Handler,java.net.URLStreamHandler,java.util.HexFormat,sun.net.www.ParseUtil,[Ljava.io.File$PathStatus;,java.io.File$PathStatus,java.net.URL$3,jdk.internal.access.JavaNetURLAccess,java.net.URL$DefaultFactory,java.net.URLStreamHandlerFactory,jdk.internal.loader.URLClassPath,jdk.internal.loader.BootLoader,java.util.ArrayDeque,java.util.Deque,java.util.Queue,jdk.internal.loader.NativeLibraries$2,jdk.internal.loader.NativeLibraries$NativeLibraryImpl,jdk.internal.loader.NativeLibrary,java.security.ProtectionDomain$JavaSecurityAccessImpl,jdk.internal.access.JavaSecur ityAccess,java.util.WeakHashMap$KeySet,java.util.Collections$SetFromMap,[Ljava.util.WeakHashMap$Entry;,java.util.WeakHashMap$Entry,java.util.WeakHashMap,java.lang.ClassLoader$ParallelLoaders,[Ljava.security.cert.Certificate;,java.security.cert.Certificate,java.net.URI$1,jdk.internal.access.JavaNetUriAccess,jdk.internal.loader.ClassLoaderValue,jdk.internal.loader.AbstractClassLoaderValue,jdk.internal.module.ModuleBootstrap$Counters,jdk.internal.module.ModulePatcher,jdk.internal.util.ArraysSupport,java.io.UnixFileSystem,java.io.FileSystem,java.io.DefaultFileSystem,java.io.File,java.lang.module.ModuleDescriptor$1,jdk.internal.access.JavaLangModuleAccess,java.lang.reflect.Modifier,sun.invoke.util.VerifyAccess,jdk.internal.module.ModuleBootstrap,java.lang.invoke.MethodHandleStatics,java.lang.IllegalArgumentException,java.util.Collections$EmptyMap,java.util.Collections$EmptyList,java.util.Collections$EmptySet,java.util.Collections,jdk.internal.misc.OSEnvironment,jdk.internal.misc.Signal$N ativeHandler,[Ljava.util.Hashtable$Entry;,java.util.Hashtable$Entry,jdk.internal.misc.Signal,java.lang.Terminator$1,jdk.internal.misc.Signal$Handler,java.lang.Terminator,java.io.BufferedWriter,java.nio.ByteOrder,java.nio.HeapByteBuffer,java.nio.Buffer$1,jdk.internal.access.JavaNioAccess,jdk.internal.misc.ScopedMemoryAccess,java.nio.ByteBuffer,java.nio.charset.CodingErrorAction,sun.nio.cs.UTF_8$Encoder,java.nio.charset.CharsetEncoder,sun.nio.cs.StreamEncoder,sun.nio.cs.UTF_8,sun.nio.cs.Unicode,sun.nio.cs.HistoricallyNamedCharset,sun.security.action.GetPropertyAction,java.util.concurrent.atomic.AtomicInteger,java.lang.ThreadLocal,sun.nio.cs.StandardCharsets,java.nio.charset.spi.CharsetProvider,java.nio.charset.Charset,java.io.OutputStreamWriter,java.io.Writer,java.io.BufferedOutputStream,java.io.PrintStream,java.io.FilterOutputStream,java.io.BufferedInputStream,java.io.FilterInputStream,java.io.FileOutputStream,java.io.OutputStream,java.io.Flushable,java.io.FileDescriptor$1,jdk.intern al.access.JavaIOFileDescriptorAccess,java.io.FileDescriptor,java.io.FileInputStream,jdk.internal.util.StaticProperty,java.util.HashMap$EntryIterator,java.util.HashMap$HashIterator,java.util.HashMap$EntrySet,java.lang.CharacterDataLatin1,java.lang.CharacterData,java.util.Arrays,java.lang.VersionProps,java.lang.StringConcatHelper,jdk.internal.util.SystemProps$Raw,jdk.internal.util.SystemProps,jdk.internal.misc.VM,java.lang.System$2,jdk.internal.access.JavaLangAccess,java.lang.ref.Finalizer$FinalizerThread,java.lang.ref.Reference$1,jdk.internal.access.JavaLangRefAccess,java.lang.ref.ReferenceQueue$Lock,java.lang.ref.ReferenceQueue$Null,java.lang.ref.ReferenceQueue,jdk.internal.ref.Cleaner,java.lang.ref.Reference$ReferenceHandler,jdk.internal.reflect.ReflectionFactory,jdk.internal.reflect.ReflectionFactory$GetReflectionFactoryAction,java.security.PrivilegedAction,java.util.concurrent.ConcurrentHashMap$ReservationNode,java.util.concurrent.locks.LockSupport,java.util.concurrent.Concurrent HashMap$CounterCell,[Ljava.util.concurrent.ConcurrentHashMap$Segment;,java.util.concurrent.ConcurrentHashMap$Segment,[Ljava.util.concurrent.locks.ReentrantLock;,java.util.concurrent.locks.ReentrantLock,[Ljava.util.concurrent.locks.Lock;,java.util.concurrent.locks.Lock,java.lang.Runtime,java.util.HashMap$TreeNode,java.util.LinkedHashMap$Entry,java.util.KeyValueHolder,java.util.ImmutableCollections$MapN$MapNIterator,java.util.ImmutableCollections$MapN$1,java.lang.Math,jdk.internal.reflect.Reflection,java.util.Objects,java.lang.invoke.MethodHandles$Lookup,java.lang.StringLatin1,java.lang.reflect.ReflectPermission,java.security.BasicPermission,java.security.Permission,java.security.Guard,java.lang.invoke.MemberName$Factory,java.lang.invoke.MethodHandles,jdk.internal.access.SharedSecrets,java.lang.reflect.ReflectAccess,jdk.internal.access.JavaLangReflectAccess,jdk.internal.misc.CDS,java.lang.String$CaseInsensitiveComparator,java.util.Comparator,[Ljava.io.ObjectStreamField;,java.io.Object StreamField,[Ljava.util.jar.Manifest;,[Ljava.net.URL;,java.lang.ArithmeticException,java.lang.NullPointerException,[J,[[I,[I,[S,[B,[D,[F,[C,[Z,java.lang.Module$ArchivedData,jdk.internal.module.ArchivedBootLayer,jdk.internal.loader.BuiltinClassLoader$LoadedModule,java.util.HashSet,java.util.AbstractSet,[Ljdk.internal.module.ServicesCatalog$ServiceProvider;,jdk.internal.module.ServicesCatalog$ServiceProvider,java.util.concurrent.CopyOnWriteArrayList,[Ljdk.internal.module.ServicesCatalog;,jdk.internal.module.ServicesCatalog,[Ljava.util.concurrent.ConcurrentHashMap$Node;,java.util.concurrent.ConcurrentHashMap$Node,jdk.internal.loader.NativeLibraries,java.security.ProtectionDomain$Key,[Ljava.security.Principal;,java.security.Principal,jdk.internal.loader.ClassLoaders$BootClassLoader,jdk.internal.loader.ArchivedClassLoaders,[Ljdk.internal.math.FDBigInteger;,jdk.internal.math.FDBigInteger,java.lang.ModuleLayer,java.util.ImmutableCollections,jdk.internal.module.ModuleLoaderMap$Mapper,java.u til.function.Function,[Ljava.lang.module.ResolvedModule;,java.lang.module.ResolvedModule,java.lang.module.Configuration,[Ljava.util.HashMap$Node;,java.util.HashMap$Node,[Ljava.util.Map$Entry;,java.util.Map$Entry,java.util.HashMap,java.util.Collections$UnmodifiableMap,[Ljdk.internal.module.ModuleHashes;,jdk.internal.module.ModuleHashes,[Ljdk.internal.module.ModuleTarget;,jdk.internal.module.ModuleTarget,java.util.ImmutableCollections$ListN,[Ljava.lang.module.ModuleDescriptor$Opens;,java.lang.module.ModuleDescriptor$Opens,jdk.internal.module.SystemModuleFinders$3,jdk.internal.module.ModuleHashes$HashSupplier,jdk.internal.module.SystemModuleFinders$2,java.util.function.Supplier,java.net.URI,java.util.ImmutableCollections$List12,java.util.ImmutableCollections$AbstractImmutableList,[Ljava.lang.module.ModuleDescriptor$Provides;,java.lang.module.ModuleDescriptor$Provides,[Ljava.lang.module.ModuleDescriptor$Exports;,java.lang.module.ModuleDescriptor$Exports,[Ljava.lang.module.ModuleDescript or$Requires$Modifier;,java.lang.module.ModuleDescriptor$Requires$Modifier,[Ljava.lang.Enum;,java.lang.Enum,[Ljava.lang.module.ModuleDescriptor$Requires;,java.lang.module.ModuleDescriptor$Requires,java.util.ImmutableCollections$Set12,java.lang.module.ModuleDescriptor$Version,[Ljava.lang.module.ModuleDescriptor;,java.lang.module.ModuleDescriptor,jdk.internal.module.ModuleReferenceImpl,[Ljava.lang.module.ModuleReference;,java.lang.module.ModuleReference,java.util.ImmutableCollections$SetN,java.util.ImmutableCollections$AbstractImmutableSet,java.util.Set,java.util.ImmutableCollections$AbstractImmutableCollection,jdk.internal.module.SystemModuleFinders$SystemModuleFinder,java.lang.module.ModuleFinder,jdk.internal.module.ArchivedModuleGraph,[Lsun.util.locale.BaseLocale;,sun.util.locale.BaseLocale,java.util.ImmutableCollections$MapN,java.util.ImmutableCollections$AbstractImmutableMap,java.util.jar.Attributes$Name,java.lang.Character$CharacterCache,java.lang.Short$ShortCache,java.lang.Byte$ ByteCache,java.lang.Long$LongCache,java.lang.Integer$IntegerCache,jdk.internal.vm.vector.VectorSupport$VectorShuffle,jdk.internal.vm.vector.VectorSupport$VectorMask,jdk.internal.vm.vector.VectorSupport$Vector,jdk.internal.vm.vector.VectorSupport$VectorPayload,jdk.internal.vm.vector.VectorSupport,java.lang.reflect.RecordComponent,java.util.Iterator,[Ljava.lang.Long;,java.lang.Long,[Ljava.lang.Integer;,java.lang.Integer,[Ljava.lang.Short;,java.lang.Short,[Ljava.lang.Byte;,java.lang.Byte,java.lang.Double,java.lang.Float,[Ljava.lang.Number;,java.lang.Number,[Ljava.lang.Character;,java.lang.Character,java.lang.Boolean,java.util.concurrent.locks.AbstractOwnableSynchronizer,java.lang.LiveStackFrameInfo,java.lang.LiveStackFrame,java.lang.StackFrameInfo,java.lang.StackWalker$StackFrame,java.lang.StackStreamFactory$AbstractStackWalker,java.lang.StackWalker,java.nio.Buffer,[Ljava.lang.StackTraceElement;,java.lang.StackTraceElement,java.util.ArrayList,java.util.RandomAccess,java.util.AbstractLi st,java.util.List,java.util.AbstractCollection,java.util.Collection,java.lang.Iterable,java.util.concurrent.ConcurrentHashMap,java.util.concurrent.ConcurrentMap,java.util.AbstractMap,java.security.CodeSource,jdk.internal.loader.ClassLoaders$PlatformClassLoader,jdk.internal.loader.ClassLoaders$AppClassLoader,jdk.internal.loader.ClassLoaders,jdk.internal.loader.BuiltinClassLoader,java.util.jar.Manifest,java.net.URL,java.io.ByteArrayInputStream,java.io.InputStream,java.io.Closeable,java.lang.AutoCloseable,jdk.internal.module.Modules,jdk.internal.misc.Unsafe,jdk.internal.misc.UnsafeConstants,java.lang.StringBuilder,java.lang.StringBuffer,java.lang.AbstractStringBuilder,java.lang.Appendable,java.lang.AssertionStatusDirectives,java.lang.invoke.VolatileCallSite,java.lang.invoke.MutableCallSite,java.lang.invoke.ConstantCallSite,java.lang.invoke.MethodHandleNatives$CallSiteContext,jdk.internal.invoke.NativeEntryPoint,java.lang.invoke.CallSite,java.lang.BootstrapMethodError,[Ljava.lang.invoke .MethodType;,java.lang.invoke.MethodType,[Ljava.lang.invoke.TypeDescriptor$OfMethod;,java.lang.invoke.TypeDescriptor$OfMethod,[Ljava.lang.invoke.LambdaForm;,java.lang.invoke.LambdaForm,java.lang.invoke.MethodHandleNatives,java.lang.invoke.ResolvedMethodName,java.lang.invoke.MemberName,java.lang.invoke.VarHandle,java.lang.invoke.DirectMethodHandle,[Ljava.lang.invoke.MethodHandle;,java.lang.invoke.MethodHandle,jdk.internal.reflect.NativeConstructorAccessorImpl,jdk.internal.reflect.CallerSensitive,[Ljava.lang.annotation.Annotation;,java.lang.annotation.Annotation,jdk.internal.reflect.UnsafeStaticFieldAccessorImpl,jdk.internal.reflect.UnsafeFieldAccessorImpl,jdk.internal.reflect.FieldAccessorImpl,jdk.internal.reflect.FieldAccessor,jdk.internal.reflect.ConstantPool,jdk.internal.reflect.DelegatingClassLoader,jdk.internal.reflect.ConstructorAccessorImpl,jdk.internal.reflect.ConstructorAccessor,jdk.internal.reflect.MethodAccessorImpl,jdk.internal.reflect.MethodAccessor,jdk.internal.reflect. MagicAccessorImpl,[Ljava.lang.reflect.Constructor;,java.lang.reflect.Constructor,[Ljava.lang.reflect.Method;,java.lang.reflect.Method,[Ljava.lang.reflect.Executable;,java.lang.reflect.Executable,java.lang.reflect.Parameter,java.lang.reflect.Field,[Ljava.lang.reflect.Member;,java.lang.reflect.Member,[Ljava.lang.reflect.AccessibleObject;,java.lang.reflect.AccessibleObject,[Ljava.lang.Module;,java.lang.Module,java.util.Properties,java.util.Hashtable,java.util.Map,java.util.Dictionary,[Ljava.lang.ThreadGroup;,java.lang.ThreadGroup,[Ljava.lang.Thread$UncaughtExceptionHandler;,java.lang.Thread$UncaughtExceptionHandler,[Ljava.lang.Thread;,java.lang.Thread,[Ljava.lang.Runnable;,java.lang.Runnable,java.lang.ref.Finalizer,java.lang.ref.PhantomReference,java.lang.ref.FinalReference,[Ljava.lang.ref.WeakReference;,java.lang.ref.WeakReference,[Ljava.lang.ref.SoftReference;,java.lang.ref.SoftReference,[Ljava.lang.ref.Reference;,java.lang.ref.Reference,java.lang.IllegalMonitorStateException,java.la ng.StackOverflowError,[Ljava.lang.OutOfMemoryError;,java.lang.OutOfMemoryError,java.lang.InternalError,[Ljava.lang.VirtualMachineError;,java.lang.VirtualMachineError,java.lang.ArrayStoreException,java.lang.ClassCastException,java.lang.NoClassDefFoundError,java.lang.LinkageError,java.lang.Record,java.lang.ClassNotFoundException,java.lang.ReflectiveOperationException,java.security.SecureClassLoader,java.security.AccessController,java.security.AccessControlContext,[Ljava.security.ProtectionDomain;,java.security.ProtectionDomain,java.lang.SecurityManager,java.lang.RuntimeException,java.lang.Exception,java.lang.ThreadDeath,[Ljava.lang.Error;,java.lang.Error,[Ljava.lang.Throwable;,java.lang.Throwable,java.lang.System,[Ljava.lang.ClassLoader;,java.lang.ClassLoader,[Ljava.lang.Cloneable;,java.lang.Cloneable,[Ljava.lang.Class;,java.lang.Class,[Ljava.lang.invoke.TypeDescriptor$OfField;,java.lang.invoke.TypeDescriptor$OfField,[Ljava.lang.invoke.TypeDescriptor;,java.lang.invoke.TypeDescriptor,[ Ljava.lang.reflect.Type;,java.lang.reflect.Type,[Ljava.lang.reflect.GenericDeclaration;,java.lang.reflect.GenericDeclaration,[Ljava.lang.reflect.AnnotatedElement;,java.lang.reflect.AnnotatedElement,[Ljava.lang.String;,java.lang.String,[Ljava.lang.constant.ConstantDesc;,java.lang.constant.ConstantDesc,[Ljava.lang.constant.Constable;,java.lang.constant.Constable,[Ljava.lang.CharSequence;,java.lang.CharSequence,[Ljava.lang.Comparable;,java.lang.Comparable,[Ljava.io.Serializable;,java.io.Serializable,[[Ljava.lang.Object;,[Ljava.lang.Object;,java.lang.Object, } > - packages 0x7fea482e03a0 > - module 0x7fea482e5030 > - unnamed module 0x7fea482e0b50 > - dictionary 0x7fea482e0bf0 > - jmethod count 3 > - deallocate list (nil) I was just using PrintSystemDictionaryAtExit and wanted to ignore the CLDG information, which is already quite verbose for this option, so there was a lot of scrolling. It's sort of a small change to add a nonproduct PrintClassLoaderDataGraphAtExit and use that to print the CLDG at exit and remove it from PrintSystemDictionaryAtExit. Then we can each get the info we want. ------------- PR: https://git.openjdk.java.net/jdk/pull/3323 From yyang at openjdk.java.net Fri Apr 2 16:12:49 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Fri, 2 Apr 2021 16:12:49 GMT Subject: RFR: 8264644: More complete ClassLoaderData for cld->print() [v2] In-Reply-To: References: Message-ID: > Trivial chanage to make debugging happy, now cld->print() would be: > > ClassLoaderData(0x00007ff17432b670) > - name 'platform' > - holder WeakHandle: 0x00000007fef56678 > - class loader 0x7ff17432b828 > - metaspace 0x7ff17468a0b0 > - unloading false > - class mirror holder false > - modified oops true > - keep alive 0 > - claim strong > - handles 43 > - dependency count 0 > - klasses {java.sql.SQLFeatureNotSupportedException,java.sql.SQLNonTransientException,java.sql.SQLException,sun.util.resources.provider.NonBaseLocaleDataMetaInfo,org.ietf.jgss.GSSException,javax.sql.DataSource,java.sql.Wrapper,javax.sql.CommonDataSource,java.sql.Time,java.sql.Date,java.sql.Timestamp,sun.util.resources.cldr.provider.CLDRLocaleDataMetaInfo, } > - packages 0x7ff17432bc20 > - module 0x7ff17432c520 > - unnamed module 0x7ff17432c3d0 > - dictionary 0x7ff17432c470 > - deallocate list 0x7ff0a4023bd0 Yi Yang has updated the pull request incrementally with one additional commit since the last revision: new flag PrintClassLoaderDataGraphAtExit ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3323/files - new: https://git.openjdk.java.net/jdk/pull/3323/files/d4ff71b1..bfb2261d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3323&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3323&range=00-01 Stats: 14 lines in 3 files changed: 8 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/3323.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3323/head:pull/3323 PR: https://git.openjdk.java.net/jdk/pull/3323 From yyang at openjdk.java.net Fri Apr 2 16:18:25 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Fri, 2 Apr 2021 16:18:25 GMT Subject: RFR: 8264644: More complete ClassLoaderData for cld->print() [v2] In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 15:00:46 GMT, Coleen Phillimore wrote: >> Hi @coleenp, thanks for looking at this, it does outputs too detailed content for klasses(actually that's what I want to see), if you think it is too much detail for most people, I can print detailed content of klasses of CLD only when -XX:+Verbose. >> ... >> ClassLoaderData(0x00007fea483e5a50) >> - name 'app' >> - holder WeakHandle: 0x00000007fef56d98 >> - class loader 0x7fea483e5c08 >> - metaspace (nil) >> - unloading false >> - class mirror holder false >> - modified oops true >> - keep alive 0 >> - claim none >> - handles 20 >> - dependency count 0 >> - klasses { } >> - packages 0x7fea483e5df0 >> - module 0x7fea483ea640 >> - unnamed module 0x7fea483e65a0 >> - dictionary 0x7fea483e6640 >> - deallocate list (nil) >> ClassLoaderData(0x00007fea482ee640) >> - name 'platform' >> - holder WeakHandle: 0x00000007fef56678 >> - class loader 0x7fea482ee7f8 >> - metaspace (nil) >> - unloading false >> - class mirror holder false >> - modified oops true >> - keep alive 0 >> - claim none >> - handles 24 >> - dependency count 0 >> - klasses { } >> - packages 0x7fea482eebf0 >> - module 0x7fea482ef4f0 >> - unnamed module 0x7fea482ef3a0 >> - dictionary 0x7fea482ef440 >> - deallocate list (nil) >> ClassLoaderData(0x00007fea482e01f0) >> - name 'bootstrap' >> - class loader (nil) >> - metaspace 0x7fea48391b60 >> - unloading false >> - class mirror holder false >> - modified oops true >> - keep alive 1 >> - claim none >> - handles 668 >> - dependency count 0 >> - klasses {java.lang.Shutdown$Lock,java.lang.Shutdown,[Ljava.nio.charset.CoderResult;,java.nio.charset.CoderResult,java.nio.HeapCharBuffer,java.nio.CharBuffer,java.lang.Readable,java.lang.invoke.StringConcatFactory$3,java.lang.invoke.StringConcatFactory$2,java.lang.invoke.StringConcatFactory$1,java.lang.invoke.StringConcatFactory,jdk.internal.util.Preconditions,sun.net.util.IPAddressUtil,sun.net.www.protocol.file.Handler,java.net.URLStreamHandler,java.util.HexFormat,sun.net.www.ParseUtil,[Ljava.io.File$PathStatus;,java.io.File$PathStatus,java.net.URL$3,jdk.internal.access.JavaNetURLAccess,java.net.URL$DefaultFactory,java.net.URLStreamHandlerFactory,jdk.internal.loader.URLClassPath,jdk.internal.loader.BootLoader,java.util.ArrayDeque,java.util.Deque,java.util.Queue,jdk.internal.loader.NativeLibraries$2,jdk.internal.loader.NativeLibraries$NativeLibraryImpl,jdk.internal.loader.NativeLibrary,java.security.ProtectionDomain$JavaSecurityAccessImpl,jdk.internal.access.JavaSecu rityAccess,java.util.WeakHashMap$KeySet,java.util.Collections$SetFromMap,[Ljava.util.WeakHashMap$Entry;,java.util.WeakHashMap$Entry,java.util.WeakHashMap,java.lang.ClassLoader$ParallelLoaders,[Ljava.security.cert.Certificate;,java.security.cert.Certificate,java.net.URI$1,jdk.internal.access.JavaNetUriAccess,jdk.internal.loader.ClassLoaderValue,jdk.internal.loader.AbstractClassLoaderValue,jdk.internal.module.ModuleBootstrap$Counters,jdk.internal.module.ModulePatcher,jdk.internal.util.ArraysSupport,java.io.UnixFileSystem,java.io.FileSystem,java.io.DefaultFileSystem,java.io.File,java.lang.module.ModuleDescriptor$1,jdk.internal.access.JavaLangModuleAccess,java.lang.reflect.Modifier,sun.invoke.util.VerifyAccess,jdk.internal.module.ModuleBootstrap,java.lang.invoke.MethodHandleStatics,java.lang.IllegalArgumentException,java.util.Collections$EmptyMap,java.util.Collections$EmptyList,java.util.Collections$EmptySet,java.util.Collections,jdk.internal.misc.OSEnvironment,jdk.internal.misc.Signal$ NativeHandler,[Ljava.util.Hashtable$Entry;,java.util.Hashtable$Entry,jdk.internal.misc.Signal,java.lang.Terminator$1,jdk.internal.misc.Signal$Handler,java.lang.Terminator,java.io.BufferedWriter,java.nio.ByteOrder,java.nio.HeapByteBuffer,java.nio.Buffer$1,jdk.internal.access.JavaNioAccess,jdk.internal.misc.ScopedMemoryAccess,java.nio.ByteBuffer,java.nio.charset.CodingErrorAction,sun.nio.cs.UTF_8$Encoder,java.nio.charset.CharsetEncoder,sun.nio.cs.StreamEncoder,sun.nio.cs.UTF_8,sun.nio.cs.Unicode,sun.nio.cs.HistoricallyNamedCharset,sun.security.action.GetPropertyAction,java.util.concurrent.atomic.AtomicInteger,java.lang.ThreadLocal,sun.nio.cs.StandardCharsets,java.nio.charset.spi.CharsetProvider,java.nio.charset.Charset,java.io.OutputStreamWriter,java.io.Writer,java.io.BufferedOutputStream,java.io.PrintStream,java.io.FilterOutputStream,java.io.BufferedInputStream,java.io.FilterInputStream,java.io.FileOutputStream,java.io.OutputStream,java.io.Flushable,java.io.FileDescriptor$1,jdk.inter nal.access.JavaIOFileDescriptorAccess,java.io.FileDescriptor,java.io.FileInputStream,jdk.internal.util.StaticProperty,java.util.HashMap$EntryIterator,java.util.HashMap$HashIterator,java.util.HashMap$EntrySet,java.lang.CharacterDataLatin1,java.lang.CharacterData,java.util.Arrays,java.lang.VersionProps,java.lang.StringConcatHelper,jdk.internal.util.SystemProps$Raw,jdk.internal.util.SystemProps,jdk.internal.misc.VM,java.lang.System$2,jdk.internal.access.JavaLangAccess,java.lang.ref.Finalizer$FinalizerThread,java.lang.ref.Reference$1,jdk.internal.access.JavaLangRefAccess,java.lang.ref.ReferenceQueue$Lock,java.lang.ref.ReferenceQueue$Null,java.lang.ref.ReferenceQueue,jdk.internal.ref.Cleaner,java.lang.ref.Reference$ReferenceHandler,jdk.internal.reflect.ReflectionFactory,jdk.internal.reflect.ReflectionFactory$GetReflectionFactoryAction,java.security.PrivilegedAction,java.util.concurrent.ConcurrentHashMap$ReservationNode,java.util.concurrent.locks.LockSupport,java.util.concurrent.Concurren tHashMap$CounterCell,[Ljava.util.concurrent.ConcurrentHashMap$Segment;,java.util.concurrent.ConcurrentHashMap$Segment,[Ljava.util.concurrent.locks.ReentrantLock;,java.util.concurrent.locks.ReentrantLock,[Ljava.util.concurrent.locks.Lock;,java.util.concurrent.locks.Lock,java.lang.Runtime,java.util.HashMap$TreeNode,java.util.LinkedHashMap$Entry,java.util.KeyValueHolder,java.util.ImmutableCollections$MapN$MapNIterator,java.util.ImmutableCollections$MapN$1,java.lang.Math,jdk.internal.reflect.Reflection,java.util.Objects,java.lang.invoke.MethodHandles$Lookup,java.lang.StringLatin1,java.lang.reflect.ReflectPermission,java.security.BasicPermission,java.security.Permission,java.security.Guard,java.lang.invoke.MemberName$Factory,java.lang.invoke.MethodHandles,jdk.internal.access.SharedSecrets,java.lang.reflect.ReflectAccess,jdk.internal.access.JavaLangReflectAccess,jdk.internal.misc.CDS,java.lang.String$CaseInsensitiveComparator,java.util.Comparator,[Ljava.io.ObjectStreamField;,java.io.Objec tStreamField,[Ljava.util.jar.Manifest;,[Ljava.net.URL;,java.lang.ArithmeticException,java.lang.NullPointerException,[J,[[I,[I,[S,[B,[D,[F,[C,[Z,java.lang.Module$ArchivedData,jdk.internal.module.ArchivedBootLayer,jdk.internal.loader.BuiltinClassLoader$LoadedModule,java.util.HashSet,java.util.AbstractSet,[Ljdk.internal.module.ServicesCatalog$ServiceProvider;,jdk.internal.module.ServicesCatalog$ServiceProvider,java.util.concurrent.CopyOnWriteArrayList,[Ljdk.internal.module.ServicesCatalog;,jdk.internal.module.ServicesCatalog,[Ljava.util.concurrent.ConcurrentHashMap$Node;,java.util.concurrent.ConcurrentHashMap$Node,jdk.internal.loader.NativeLibraries,java.security.ProtectionDomain$Key,[Ljava.security.Principal;,java.security.Principal,jdk.internal.loader.ClassLoaders$BootClassLoader,jdk.internal.loader.ArchivedClassLoaders,[Ljdk.internal.math.FDBigInteger;,jdk.internal.math.FDBigInteger,java.lang.ModuleLayer,java.util.ImmutableCollections,jdk.internal.module.ModuleLoaderMap$Mapper,java. util.function.Function,[Ljava.lang.module.ResolvedModule;,java.lang.module.ResolvedModule,java.lang.module.Configuration,[Ljava.util.HashMap$Node;,java.util.HashMap$Node,[Ljava.util.Map$Entry;,java.util.Map$Entry,java.util.HashMap,java.util.Collections$UnmodifiableMap,[Ljdk.internal.module.ModuleHashes;,jdk.internal.module.ModuleHashes,[Ljdk.internal.module.ModuleTarget;,jdk.internal.module.ModuleTarget,java.util.ImmutableCollections$ListN,[Ljava.lang.module.ModuleDescriptor$Opens;,java.lang.module.ModuleDescriptor$Opens,jdk.internal.module.SystemModuleFinders$3,jdk.internal.module.ModuleHashes$HashSupplier,jdk.internal.module.SystemModuleFinders$2,java.util.function.Supplier,java.net.URI,java.util.ImmutableCollections$List12,java.util.ImmutableCollections$AbstractImmutableList,[Ljava.lang.module.ModuleDescriptor$Provides;,java.lang.module.ModuleDescriptor$Provides,[Ljava.lang.module.ModuleDescriptor$Exports;,java.lang.module.ModuleDescriptor$Exports,[Ljava.lang.module.ModuleDescrip tor$Requires$Modifier;,java.lang.module.ModuleDescriptor$Requires$Modifier,[Ljava.lang.Enum;,java.lang.Enum,[Ljava.lang.module.ModuleDescriptor$Requires;,java.lang.module.ModuleDescriptor$Requires,java.util.ImmutableCollections$Set12,java.lang.module.ModuleDescriptor$Version,[Ljava.lang.module.ModuleDescriptor;,java.lang.module.ModuleDescriptor,jdk.internal.module.ModuleReferenceImpl,[Ljava.lang.module.ModuleReference;,java.lang.module.ModuleReference,java.util.ImmutableCollections$SetN,java.util.ImmutableCollections$AbstractImmutableSet,java.util.Set,java.util.ImmutableCollections$AbstractImmutableCollection,jdk.internal.module.SystemModuleFinders$SystemModuleFinder,java.lang.module.ModuleFinder,jdk.internal.module.ArchivedModuleGraph,[Lsun.util.locale.BaseLocale;,sun.util.locale.BaseLocale,java.util.ImmutableCollections$MapN,java.util.ImmutableCollections$AbstractImmutableMap,java.util.jar.Attributes$Name,java.lang.Character$CharacterCache,java.lang.Short$ShortCache,java.lang.Byte $ByteCache,java.lang.Long$LongCache,java.lang.Integer$IntegerCache,jdk.internal.vm.vector.VectorSupport$VectorShuffle,jdk.internal.vm.vector.VectorSupport$VectorMask,jdk.internal.vm.vector.VectorSupport$Vector,jdk.internal.vm.vector.VectorSupport$VectorPayload,jdk.internal.vm.vector.VectorSupport,java.lang.reflect.RecordComponent,java.util.Iterator,[Ljava.lang.Long;,java.lang.Long,[Ljava.lang.Integer;,java.lang.Integer,[Ljava.lang.Short;,java.lang.Short,[Ljava.lang.Byte;,java.lang.Byte,java.lang.Double,java.lang.Float,[Ljava.lang.Number;,java.lang.Number,[Ljava.lang.Character;,java.lang.Character,java.lang.Boolean,java.util.concurrent.locks.AbstractOwnableSynchronizer,java.lang.LiveStackFrameInfo,java.lang.LiveStackFrame,java.lang.StackFrameInfo,java.lang.StackWalker$StackFrame,java.lang.StackStreamFactory$AbstractStackWalker,java.lang.StackWalker,java.nio.Buffer,[Ljava.lang.StackTraceElement;,java.lang.StackTraceElement,java.util.ArrayList,java.util.RandomAccess,java.util.AbstractL ist,java.util.List,java.util.AbstractCollection,java.util.Collection,java.lang.Iterable,java.util.concurrent.ConcurrentHashMap,java.util.concurrent.ConcurrentMap,java.util.AbstractMap,java.security.CodeSource,jdk.internal.loader.ClassLoaders$PlatformClassLoader,jdk.internal.loader.ClassLoaders$AppClassLoader,jdk.internal.loader.ClassLoaders,jdk.internal.loader.BuiltinClassLoader,java.util.jar.Manifest,java.net.URL,java.io.ByteArrayInputStream,java.io.InputStream,java.io.Closeable,java.lang.AutoCloseable,jdk.internal.module.Modules,jdk.internal.misc.Unsafe,jdk.internal.misc.UnsafeConstants,java.lang.StringBuilder,java.lang.StringBuffer,java.lang.AbstractStringBuilder,java.lang.Appendable,java.lang.AssertionStatusDirectives,java.lang.invoke.VolatileCallSite,java.lang.invoke.MutableCallSite,java.lang.invoke.ConstantCallSite,java.lang.invoke.MethodHandleNatives$CallSiteContext,jdk.internal.invoke.NativeEntryPoint,java.lang.invoke.CallSite,java.lang.BootstrapMethodError,[Ljava.lang.invok e.MethodType;,java.lang.invoke.MethodType,[Ljava.lang.invoke.TypeDescriptor$OfMethod;,java.lang.invoke.TypeDescriptor$OfMethod,[Ljava.lang.invoke.LambdaForm;,java.lang.invoke.LambdaForm,java.lang.invoke.MethodHandleNatives,java.lang.invoke.ResolvedMethodName,java.lang.invoke.MemberName,java.lang.invoke.VarHandle,java.lang.invoke.DirectMethodHandle,[Ljava.lang.invoke.MethodHandle;,java.lang.invoke.MethodHandle,jdk.internal.reflect.NativeConstructorAccessorImpl,jdk.internal.reflect.CallerSensitive,[Ljava.lang.annotation.Annotation;,java.lang.annotation.Annotation,jdk.internal.reflect.UnsafeStaticFieldAccessorImpl,jdk.internal.reflect.UnsafeFieldAccessorImpl,jdk.internal.reflect.FieldAccessorImpl,jdk.internal.reflect.FieldAccessor,jdk.internal.reflect.ConstantPool,jdk.internal.reflect.DelegatingClassLoader,jdk.internal.reflect.ConstructorAccessorImpl,jdk.internal.reflect.ConstructorAccessor,jdk.internal.reflect.MethodAccessorImpl,jdk.internal.reflect.MethodAccessor,jdk.internal.reflect .MagicAccessorImpl,[Ljava.lang.reflect.Constructor;,java.lang.reflect.Constructor,[Ljava.lang.reflect.Method;,java.lang.reflect.Method,[Ljava.lang.reflect.Executable;,java.lang.reflect.Executable,java.lang.reflect.Parameter,java.lang.reflect.Field,[Ljava.lang.reflect.Member;,java.lang.reflect.Member,[Ljava.lang.reflect.AccessibleObject;,java.lang.reflect.AccessibleObject,[Ljava.lang.Module;,java.lang.Module,java.util.Properties,java.util.Hashtable,java.util.Map,java.util.Dictionary,[Ljava.lang.ThreadGroup;,java.lang.ThreadGroup,[Ljava.lang.Thread$UncaughtExceptionHandler;,java.lang.Thread$UncaughtExceptionHandler,[Ljava.lang.Thread;,java.lang.Thread,[Ljava.lang.Runnable;,java.lang.Runnable,java.lang.ref.Finalizer,java.lang.ref.PhantomReference,java.lang.ref.FinalReference,[Ljava.lang.ref.WeakReference;,java.lang.ref.WeakReference,[Ljava.lang.ref.SoftReference;,java.lang.ref.SoftReference,[Ljava.lang.ref.Reference;,java.lang.ref.Reference,java.lang.IllegalMonitorStateException,java.l ang.StackOverflowError,[Ljava.lang.OutOfMemoryError;,java.lang.OutOfMemoryError,java.lang.InternalError,[Ljava.lang.VirtualMachineError;,java.lang.VirtualMachineError,java.lang.ArrayStoreException,java.lang.ClassCastException,java.lang.NoClassDefFoundError,java.lang.LinkageError,java.lang.Record,java.lang.ClassNotFoundException,java.lang.ReflectiveOperationException,java.security.SecureClassLoader,java.security.AccessController,java.security.AccessControlContext,[Ljava.security.ProtectionDomain;,java.security.ProtectionDomain,java.lang.SecurityManager,java.lang.RuntimeException,java.lang.Exception,java.lang.ThreadDeath,[Ljava.lang.Error;,java.lang.Error,[Ljava.lang.Throwable;,java.lang.Throwable,java.lang.System,[Ljava.lang.ClassLoader;,java.lang.ClassLoader,[Ljava.lang.Cloneable;,java.lang.Cloneable,[Ljava.lang.Class;,java.lang.Class,[Ljava.lang.invoke.TypeDescriptor$OfField;,java.lang.invoke.TypeDescriptor$OfField,[Ljava.lang.invoke.TypeDescriptor;,java.lang.invoke.TypeDescriptor, [Ljava.lang.reflect.Type;,java.lang.reflect.Type,[Ljava.lang.reflect.GenericDeclaration;,java.lang.reflect.GenericDeclaration,[Ljava.lang.reflect.AnnotatedElement;,java.lang.reflect.AnnotatedElement,[Ljava.lang.String;,java.lang.String,[Ljava.lang.constant.ConstantDesc;,java.lang.constant.ConstantDesc,[Ljava.lang.constant.Constable;,java.lang.constant.Constable,[Ljava.lang.CharSequence;,java.lang.CharSequence,[Ljava.lang.Comparable;,java.lang.Comparable,[Ljava.io.Serializable;,java.io.Serializable,[[Ljava.lang.Object;,[Ljava.lang.Object;,java.lang.Object, } >> - packages 0x7fea482e03a0 >> - module 0x7fea482e5030 >> - unnamed module 0x7fea482e0b50 >> - dictionary 0x7fea482e0bf0 >> - jmethod count 3 >> - deallocate list (nil) > > I was just using PrintSystemDictionaryAtExit and wanted to ignore the CLDG information, which is already quite verbose for this option, so there was a lot of scrolling. > > It's sort of a small change to add a nonproduct PrintClassLoaderDataGraphAtExit and use that to print the CLDG at exit and remove it from PrintSystemDictionaryAtExit. Then we can each get the info we want. While adding the new flag PrintSystemDictionaryAtExit, I found that we may have missed acquiring CLDGraph_lock in some places. https://github.com/openjdk/jdk/blob/177bc84fe861f93f51e6d8ab5bf0738f4009522a/src/hotspot/share/classfile/classLoaderDataGraph.cpp#L674-L676 https://github.com/openjdk/jdk/blob/177bc84fe861f93f51e6d8ab5bf0738f4009522a/src/hotspot/share/memory/universe.cpp#L1129-L1131 It seems they are neither at a safepoint nor owned the CLDGraph_lock? Thanks! Yang ------------- PR: https://git.openjdk.java.net/jdk/pull/3323 From github.com+168222+mgkwill at openjdk.java.net Fri Apr 2 16:38:02 2021 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Fri, 2 Apr 2021 16:38:02 GMT Subject: RFR: 8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v27] In-Reply-To: References: Message-ID: > When using LargePageSizeInBytes=1G, os::Linux::reserve_memory_special_huge_tlbfs* cannot select large pages smaller than 1G. Code heap usually uses less than 1G, so currently the code precludes code heap from using > Large pages in this circumstance and when os::Linux::reserve_memory_special_huge_tlbfs* is called page sizes fall back to Linux::page_size() (usually 4k). > > This change allows the above use case by populating all large_page_sizes present in /sys/kernel/mm/hugepages in _page_sizes upon calling os::Linux::setup_large_page_size(). > > In os::Linux::reserve_memory_special_huge_tlbfs* we then select the largest large page size available in _page_sizes that is smaller than bytes being reserved. Marcus G K Williams has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 44 commits: - Merge branch 'master' into update_hlp - Rebase on pull/3073 Signed-off-by: Marcus G K Williams - Merge branch 'pull/3073' into update_hlp - Thomas review. Changed commit_memory_special to return bool to signal if the request succeeded or not. - Self review. Update helper name to better match commit_memory_special(). - Marcus review. Updated comments. - Ivan review Renamed helper to commit_memory_special and updated the comments. - 8262291: Refactor reserve_memory_special_huge_tlbfs - Merge branch 'master' into update_hlp - Addressed kstefanj review suggestions Signed-off-by: Marcus G K Williams - ... and 34 more: https://git.openjdk.java.net/jdk/compare/f60e81bf...f5bfe224 ------------- Changes: https://git.openjdk.java.net/jdk/pull/1153/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1153&range=26 Stats: 282 lines in 4 files changed: 80 ins; 101 del; 101 mod Patch: https://git.openjdk.java.net/jdk/pull/1153.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1153/head:pull/1153 PR: https://git.openjdk.java.net/jdk/pull/1153 From coleenp at openjdk.java.net Fri Apr 2 16:40:27 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 2 Apr 2021 16:40:27 GMT Subject: RFR: 8264644: Add PrintClassLoaderDataGraphAtExit to print the detailed CLD graph [v2] In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 16:15:11 GMT, Yi Yang wrote: >> I was just using PrintSystemDictionaryAtExit and wanted to ignore the CLDG information, which is already quite verbose for this option, so there was a lot of scrolling. >> >> It's sort of a small change to add a nonproduct PrintClassLoaderDataGraphAtExit and use that to print the CLDG at exit and remove it from PrintSystemDictionaryAtExit. Then we can each get the info we want. > > While adding the new flag PrintSystemDictionaryAtExit, I found that we may have missed acquiring CLDGraph_lock in some places. > > https://github.com/openjdk/jdk/blob/177bc84fe861f93f51e6d8ab5bf0738f4009522a/src/hotspot/share/classfile/classLoaderDataGraph.cpp#L674-L676 > > https://github.com/openjdk/jdk/blob/177bc84fe861f93f51e6d8ab5bf0738f4009522a/src/hotspot/share/memory/universe.cpp#L1129-L1131 > > It seems they are neither at a safepoint nor owned the CLDGraph_lock? > > Thanks! > Yang Yes, I like the new option. You're correct. There should be a CLDG_lock at both Universe::verify and debug.cpp. The latter is only called from the debugger so I didn't know if adding the lock would break anything, the former should have the lock. If you don't mind adding these and retesting, while waiting for your second reviewer (who might be having a holiday weekend), that would be great. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/3323 From ccheung at openjdk.java.net Fri Apr 2 16:41:35 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 2 Apr 2021 16:41:35 GMT Subject: RFR: 8264540: WhiteBox.metaspaceReserveAlignment should return shared region alignment [v2] In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 22:15:51 GMT, Yumin Qi wrote: >> Hi, Please review >> After JDK-8236847, the shared region alignment (new as MetaspaceShared::core_region_alignment) is no longer default to os pagesize, it is a configurable value at build time instead. The WhiteBox api metaspaceReserveAlignment() should reflect the change. >> >> Tests:tier1,tier2,tier3,tier4 > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Fix minimal build failure Looks good. Just one comment in one of the test changes. test/hotspot/jtreg/runtime/cds/appcds/SharedRegionAlignmentTest.java line 38: > 36: * @run driver jdk.test.lib.helpers.ClassFileInstaller sun.hotspot.WhiteBox > 37: * @run driver jdk.test.lib.helpers.ClassFileInstaller -jar hello.jar Hello > 38: * @run main/othervm/timeout=240 -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI -Xbootclasspath/a:. SharedRegionAlignmentTest Is the increase in timeout necessary? ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3309 From iklam at openjdk.java.net Fri Apr 2 16:49:10 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 2 Apr 2021 16:49:10 GMT Subject: RFR: 8264540: WhiteBox.metaspaceReserveAlignment should return shared region alignment [v2] In-Reply-To: References: Message-ID: <26YqIl7ho5DGoDoVZArObAqsUcwzVORBrdP16m26jPY=.3556bf65-9927-461d-b00c-3e0c16ae7736@github.com> On Thu, 1 Apr 2021 22:15:51 GMT, Yumin Qi wrote: >> Hi, Please review >> After JDK-8236847, the shared region alignment (new as MetaspaceShared::core_region_alignment) is no longer default to os pagesize, it is a configurable value at build time instead. The WhiteBox api metaspaceReserveAlignment() should reflect the change. >> >> Tests:tier1,tier2,tier3,tier4 > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Fix minimal build failure Changes requested by iklam (Reviewer). test/hotspot/jtreg/runtime/cds/appcds/SharedRegionAlignmentTest.java line 75: > 73: TestCommon.concat(dumpLP, logArg)); > 74: out.shouldContain("Dumping shared data to file"); > 75: boolean is_alignment_logged = out.getStdout().contains(regionAlignmentString + regionAlignment); Is `is_alignment_logged` still needed? Now both dump time and run time should contain the `regionAlignmentString + regionAlignment` string. Also, I think it's better to use a local variable like: String expectedAlignment = regionAlignmentString + regionAlignment; ------------- PR: https://git.openjdk.java.net/jdk/pull/3309 From minqi at openjdk.java.net Fri Apr 2 16:49:11 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 2 Apr 2021 16:49:11 GMT Subject: RFR: 8264540: WhiteBox.metaspaceReserveAlignment should return shared region alignment [v2] In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 16:37:51 GMT, Calvin Cheung wrote: >> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix minimal build failure > > test/hotspot/jtreg/runtime/cds/appcds/SharedRegionAlignmentTest.java line 38: > >> 36: * @run driver jdk.test.lib.helpers.ClassFileInstaller sun.hotspot.WhiteBox >> 37: * @run driver jdk.test.lib.helpers.ClassFileInstaller -jar hello.jar Hello >> 38: * @run main/othervm/timeout=240 -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI -Xbootclasspath/a:. SharedRegionAlignmentTest > > Is the increase in timeout necessary? I will do a test in debug to check if it should be removed. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/3309 From coleenp at openjdk.java.net Fri Apr 2 16:50:24 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 2 Apr 2021 16:50:24 GMT Subject: RFR: 8264565: Templatize num_arguments() functions of DCmd subclasses In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 17:46:22 GMT, Ioi Lam wrote: > We have many version of `num_arguments()` for the `DCmd` subclasses. They all have identical structure. We should templatize them to reduce duplicated code and avoid cut-and-paste errors. > > It's still possible to write a customized `num_arguments()` function (although none of the existing cases needs to do that). The rules are described here: > > class DCmd : public ResourceObj { > ... > // num_arguments() is used by the DCmdFactoryImpl::get_num_arguments() template functions. > // - For subclasses of DCmdWithParser, it's calculated by DCmdParser::num_arguments(). > // - Other subclasses of DCmd have zero arguments by default. You can change this > // by defining your own version of MyDCmd::num_arguments(). > static int num_arguments() { return 0; } Wow cool and nice. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3312 From github.com+168222+mgkwill at openjdk.java.net Fri Apr 2 16:55:30 2021 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Fri, 2 Apr 2021 16:55:30 GMT Subject: RFR: 8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v23] In-Reply-To: References: <_uIvdHdm5ptjZJ8gEw8AzBJ8PC-16GoEWUuKW5zAXrg=.36c2da1c-685b-4d4d-a4e5-73b3fc48b812@github.com> Message-ID: On Thu, 18 Mar 2021 12:47:40 GMT, Stefan Johansson wrote: > > > This would also give us to to think about a question I haven't made up my mind around. What will `LargePageSizeInBytes` mean after this change? Should the JVM use 1g pages (on a system where 2m i the default) even if `LargePageSizeInBytes` is not set? > > > > > > I see two valid scenarios: > > Me too. > > > a) either use huge pages as best as possible; remove fine-grained control from user hands. So, if we have 1G pages, prefer those over 2M over 4K. Then, we could completely remove LargePageSizeInBytes. There is no need for this switch anymore. > > I agree, preferably we can make it so that the upper layers can use something like `page_size_for_region*` and request a certain page size, but fall back to smaller ones. > > > b) or keep the current behavior. In that case, UseLargePageSize means "use at most default huge page size" even if larger pages are available; and LargePageSizeInBytes can be used to override the large page size to use. > > So it becomes more like a maximium value right? Or at least this is how I've thought about this second scenario. On a system with both 2M (the default size) and 1G pages available you would have to set `LargePageSizeInBytes=1g` to use the 1G pages, but the 2M could still be used for smaller mappings. > > > (a): Its elegant, and efficiently uses system resources when available. But its an incompatible change, and the VM being grabby means we could end up using pages meant for a different process. > > (b): downward compatible. In a sense. With Marcus change, we break downward compatibility already: where "UseLargePageSizeInBytes" before meant "use that or nothing", it now means "use that or whatever smaller page sizes you find". > > I prefer (a), honestly. > > I would also prefer (a). @kstefanj @tstuefe 1. Would (a) [removing fine grained control of large page [Huge Page] sizes with LargePageSizeInBytes and relying on automatic selection of sizes from available] require JEP process? 2. Can we put LargePageSizeInBytes flag in DIAGNOSTIC or EXPERIMENTAL and set it otherwise to the largest available page size? This way we have the default (a) and if users want to change page size they can use diagnostic or experimental and use (b). Also this would lower the amount of change needed. I'm a bit concerned with removing LargePageSizeInBytes altogether. I don't know if some use cases would break or need more fine tuned control of page sizes. I've incorporated https://github.com/openjdk/jdk/pull/3073 into this change, as a good base to build on, this also seemed to be Stefan's optimal path for this change. ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From minqi at openjdk.java.net Fri Apr 2 17:10:28 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 2 Apr 2021 17:10:28 GMT Subject: RFR: 8264540: WhiteBox.metaspaceReserveAlignment should return shared region alignment [v2] In-Reply-To: <26YqIl7ho5DGoDoVZArObAqsUcwzVORBrdP16m26jPY=.3556bf65-9927-461d-b00c-3e0c16ae7736@github.com> References: <26YqIl7ho5DGoDoVZArObAqsUcwzVORBrdP16m26jPY=.3556bf65-9927-461d-b00c-3e0c16ae7736@github.com> Message-ID: On Fri, 2 Apr 2021 16:45:39 GMT, Ioi Lam wrote: >> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix minimal build failure > > test/hotspot/jtreg/runtime/cds/appcds/SharedRegionAlignmentTest.java line 75: > >> 73: TestCommon.concat(dumpLP, logArg)); >> 74: out.shouldContain("Dumping shared data to file"); >> 75: boolean is_alignment_logged = out.getStdout().contains(regionAlignmentString + regionAlignment); > > Is `is_alignment_logged` still needed? Now both dump time and run time should contain the `regionAlignmentString + regionAlignment` string. Also, I think it's better to use a local variable like: > > String expectedAlignment = regionAlignmentString + regionAlignment; Yes, it should be contained in both dump/runtime time, will remove it. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/3309 From minqi at openjdk.java.net Fri Apr 2 17:31:39 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 2 Apr 2021 17:31:39 GMT Subject: RFR: 8264540: WhiteBox.metaspaceReserveAlignment should return shared region alignment [v3] In-Reply-To: References: Message-ID: > Hi, Please review > After JDK-8236847, the shared region alignment (new as MetaspaceShared::core_region_alignment) is no longer default to os pagesize, it is a configurable value at build time instead. The WhiteBox api metaspaceReserveAlignment() should reflect the change. > > Tests:tier1,tier2,tier3,tier4 Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: SharedRegionAlignmentTest: removed timeout on test, removed is_alignment_logged ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3309/files - new: https://git.openjdk.java.net/jdk/pull/3309/files/f99b1c90..155b3b7d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3309&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3309&range=01-02 Stats: 10 lines in 1 file changed: 1 ins; 3 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/3309.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3309/head:pull/3309 PR: https://git.openjdk.java.net/jdk/pull/3309 From ccheung at openjdk.java.net Fri Apr 2 17:50:24 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Fri, 2 Apr 2021 17:50:24 GMT Subject: RFR: 8264540: WhiteBox.metaspaceReserveAlignment should return shared region alignment [v3] In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 17:31:39 GMT, Yumin Qi wrote: >> Hi, Please review >> After JDK-8236847, the shared region alignment (new as MetaspaceShared::core_region_alignment) is no longer default to os pagesize, it is a configurable value at build time instead. The WhiteBox api metaspaceReserveAlignment() should reflect the change. >> >> Tests:tier1,tier2,tier3,tier4 > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > SharedRegionAlignmentTest: removed timeout on test, removed is_alignment_logged Marked as reviewed by ccheung (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3309 From minqi at openjdk.java.net Fri Apr 2 19:27:59 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 2 Apr 2021 19:27:59 GMT Subject: RFR: 8259070: Add jcmd option to dump CDS [v9] In-Reply-To: References: Message-ID: <_jXjltEgPfLS6x74d5Q3UfwNXMsRvqyM_9-sDzVDcAg=.38d5f001-5351-4208-98d9-42002aecdd19@github.com> > Hi, Please review > > Added jcmd option for dumping CDS archive during application runtime. Before this change, user has to dump shared archive in two steps: first run application with > `java -XX:DumpLoadedClassList= .... ` > to collect shareable class names and saved in file `` , then > `java -Xshare:dump -XX:SharedClassListFile= -XX:SharedArchiveFile= ...` > With this change, user can use jcmd to dump CDS without going through above steps. Also user can choose a moment during the app runtime to dump an archive. > The bug is associated with the CSR: https://bugs.openjdk.java.net/browse/JDK-8259798 which has been approved. > New added jcmd option: > `jcmd VM.cds static_dump ` > or > `jcmd VM.cds dynamic_dump ` > To dump dynamic archive, requires start app with newly added flag `-XX:+RecordDynamicDumpInfo`, with this flag, some information related to dynamic dump like loader constraints will be recorded. Note the dumping process changed some object memory locations so for dumping dynamic archive, can only done once for a running app. For static dump, user can dump multiple times against same process. > The file name is optional, if the file name is not supplied, the file name will take format of `java_pid_static.jsa` or `java_pid_dynamic.jsa` for static and dynamic respectively. The `` is the application process ID. > > Tests: tier1,tier2,tier3,tier4 > > Thanks > Yumin Yumin Qi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: - Restructed code and rename LingeredTestApp.java to JCmdTestLingeredApp.java - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 - Fix revert unintentionally comment, merge master. - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 - Remove CDS.getVMArguments, changed to use VM.getRuntimeVMArguments. Removed unused function from ClassLoader. Improved InstanceKlass::is_shareable() and related test. Added more test scenarios. - Remove redundant check for if a class is shareable - Fix according to review comment and add more tests - Fix filter more flags to exclude in static dump, add more test cases - Merge branch 'master' into jdk-8259070 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/328e9514...79822e79 ------------- Changes: https://git.openjdk.java.net/jdk/pull/2737/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2737&range=08 Stats: 846 lines in 23 files changed: 772 ins; 58 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/2737.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2737/head:pull/2737 PR: https://git.openjdk.java.net/jdk/pull/2737 From github.com+58006833+xbzhang99 at openjdk.java.net Fri Apr 2 23:22:52 2021 From: github.com+58006833+xbzhang99 at openjdk.java.net (Xubo Zhang) Date: Fri, 2 Apr 2021 23:22:52 GMT Subject: RFR: 8264543: Using Intel serialize instruction to replace cpuid in Cross modify fence, on supported platforms Message-ID: Intel introduced a new instruction ?serialize? which ensures that all modifications to flags, registers, and memory by previous instructions are completed and all buffered writes are drained to memory before the next instruction is fetched and executed. It is a serializing instruction and can be used to implement cross modify fence (OrderAccess::cross_modify_fence_impl) more efficiently than using ?cpuid? on supported 32-bit and 64-bit x86 platforms. The availability of the SERIALIZE instruction is indicated by the presence of the CPUID feature flag SERIALIZE, bit 14 of the EDX register in sub-leaf CPUID:7H.0H. https://software.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html ------------- Commit messages: - 8264543: Using Intel serialize instruction to replace cpuid in Cross modify fence, on supported platforms Changes: https://git.openjdk.java.net/jdk/pull/3334/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3334&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264543 Stats: 103901 lines in 6 files changed: 103892 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/3334.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3334/head:pull/3334 PR: https://git.openjdk.java.net/jdk/pull/3334 From hshi at openjdk.java.net Sat Apr 3 01:01:59 2021 From: hshi at openjdk.java.net (Hui Shi) Date: Sat, 3 Apr 2021 01:01:59 GMT Subject: RFR: 8264649: runtime/InternalApi/ThreadCpuTimesDeadlock.java crash in fastdebug C2 with -XX:-UseTLAB Message-ID: Detailed analysis in https://bugs.openjdk.java.net/browse/JDK-8264649 Tier1/2 release /fastdebug passed ------------- Commit messages: - 8264649: runtime/InternalApi/ThreadCpuTimesDeadlock.java crash in fastdebug C2 with -XX:-UseTLAB Changes: https://git.openjdk.java.net/jdk/pull/3336/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3336&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264649 Stats: 13 lines in 2 files changed: 12 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3336.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3336/head:pull/3336 PR: https://git.openjdk.java.net/jdk/pull/3336 From xliu at openjdk.java.net Sat Apr 3 01:30:24 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Sat, 3 Apr 2021 01:30:24 GMT Subject: RFR: 8229517: Support for optional asynchronous/buffered logging [v2] In-Reply-To: <38hXykjHJTEhOD0CAggi-VnbcQra-I9Js8BWeM86s88=.ef06f49b-ab26-4b3a-827e-da79ba242302@github.com> References: <5lZuUwWVD5NwXo_gUOnUDUD4tdYUvils5Cx5X5r8elo=.5d1f1074-730a-4f88-ba67-67977ffe58d0@github.com> <37Cm5ItlFJ8nzQW_HI6-oyO_TuTK3f09BqiZ2-0l-iE=.fdde37ed-aa6b-4c28-bc30-0403542a518b@github.com> <0qKPSmxPH02xshv9gpcarh-LIc6xiZnlYVCDrRPtCP0=.94eaa31a-501b-4d48-ade0-ae1abf6acddf@github.com> <38hXykjHJTEhOD0CAggi-VnbcQra-I9Js8BWeM86s88=.ef06f49b-ab26-4b3a-827e-da79ba242302@github.com> Message-ID: On Tue, 30 Mar 2021 13:17:05 GMT, Robbin Ehn wrote: > Hi Xin, regrading the VM thread blocking on logs. > > If you instead use two arrays, one active and one for flushing, you can swap them with atomic stores from the flushing thread. > And use GlobalCounter::write_synchronize(); to make sure no writer is still using the swapped out array for logging. > > The logging thread would use GlobalCounter::critical_section_begin(), atomic inc position to get the spot in the array for the log, store the log and then GlobalCounter::critical_section_end(). > > That way you will never block a logging thread with the flushing and run enqueues in parallel. > > If you want really want smooth logging you could also remove the strdup, since it may cause a syscall to "break in" more memory. > To solve that you could use the arrays as memory instead, and do bump the pointer allocation with an atomic increment to size needed instead of position. > > I tested a bit locally generally I don't think there is an issue with blocking the VM thread on flushing. > So I'm not really that concern about this, but it's always nice to have an algorithm which is constant time instead. (Neither CS begin()/end() or atomic inc can fail or loop on x86) hi, Robbin, Thanks for your comments. I am new for GlobalCounter. please correct me if I am wrong. critical_section_begin/end() reminds me of Linux kernel's rcu_read_lock/unlck(). Traditionally, the best scenario of RCU is many reads and rare writes. it's because concurrent writers still need to use atomic operations or locking mechanism. Unfortunately, all participants of logging are writers. No one is read-only. The algorithm you described is appealing. The difficulty is that hotspot GlobalCounter is epoch-based. It's unsafe to swap two buffers until all writers are in quiescent state. One `write_synchronize()` can't guarantee that. Thinking of that log sites are high-frequent and concurrent, you would see multiple version(epoch) in-flight. Further, the most expensive synchronization is atomic_incrementation. You can't eliminate them. If we decide to go to a lock-free solution, I think the classic lock-free linkedlist is the best way to do that. I have seen that hotspot recently checks in a lock-free FIFO. TBH, I would rather grumpy customers yell at me about async-logging performance first before jump into lock-free algorithms. Here is why. 1. it?s easy to implement using a lock. it is easy to be reviewed as well. 2. log sites should be less contentious. Some are temporally distanced. eg. classloading and gc marking. 3. aysnc logging is an auxiliary feature. Even the entire logging subsystem is neither critical nor mandatory. I know that I serialize all file-based logs using a mutex. In my defense, it's probably unusual to log several files in real life. As Volker pointed out earlier, the cost is effectively same as the existing futex imposed by Unified Logging there[1] if we have only one file output. I like the idea of swapping 2 buffers. In our internal jdk8u, I do use this approach. flusher swaps 2 ring buffers after it dump one[2]. For linkedlist deque, [pop_all](https://github.com/openjdk/jdk/pull/3135/files#diff-a1d0f5e0f4539bc398c42f4298959ef2ecdbc62a6611dabcd903198e63f86431R51) is essentially swapping 2 linked lists in O(1) complexity. It still uses a mutex, but it pops up all elements at once. The amortized cost is low. I use the following approach to prevent blocked IO from suspending java threads and vmthread. 1. flushing is done in a NonJavaThread. It means it can ignore safepoints. 2. release the lock of buffer before it start doing IO. It won't block anybody from enqueuing. The main use case would be a synchronous log for everything, but asynchronous log for safepoint and gc. Recently, I am thinking how to get a consensus of a feature before beat it to death. Look, there's alway room to improve it. I think it's a good idea to focus on the core problem we are solving and sidetrack optimizations for future development. [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/logging/logFileStreamOutput.cpp#L123 [2] https://cr.openjdk.java.net/~xliu/8229517/webrev04/webrev/src/share/vm/utilities/ostream.cpp.udiff.html ------------- PR: https://git.openjdk.java.net/jdk/pull/3135 From thomas.stuefe at gmail.com Sat Apr 3 06:48:25 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sat, 3 Apr 2021 08:48:25 +0200 Subject: Request For Comment: Asynchronous Logging In-Reply-To: References: Message-ID: > > > > > - What are your preferences on the configuration of the intermediate > > data structure? Should it be configured based on the maximum number > of > > log messages it can store or rather on the total size of the stored > > log messages? I think that for normal runs this distinction probably > > won't make a big difference because the size of log messages will > > probably be the same on average so "number of log messages" should > > always be proportional to "total size of log mesages". > > > > > > I prefer the configuration of the intermediate buffer to be as a memory > size, not "number of entries". The latter does not carry any information > (what entries? how large are they?). It also, again, exposes implementation > details - in this case that there is a vector of entries. > > Maybe our perspective differs from yours. We provide long term support for customers who use the JDK in a large variety of situations, and on a wide number of platforms. Any combination of flags, regardless how odd and exotic, will be used by a small subset of our users in the years to come. So it has to work reliably and has to be tested. I would like to keep long term maintainability of the JDK, and that includes being careful with rolling out new features. I personally think that UL is already too complex. IMHO exposing the ability to log to different log files was a bad choice. I have never seen a situation where this feature was useful, let alone vital. But it is there and can never be undone and its complexity causes technical debt. Just as one example of how this already impacts us, I am currently changing NMT to be late-initializable (see JDK-8256844), and that includes revamping early dynamic C++ initialization. UL is by far the most complex early initialization in that stage, with a surprising number of os::malloc calls. All to initialize what basically is just a constant static structure, which should have been static-initialized as a number of constants. But revamping that is very difficult because we chose to expose features like this. Every feature increases complexity. If the feature is useful, fine. But aesthetics alone are not a good reason. Please let's have this design discussion before pushing patches. The right way to do things is to build consent first, then to write code. Every added feature increases maintenance effort for *all* maintainers. Thanks, Thomas From kbarrett at openjdk.java.net Sun Apr 4 04:22:33 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sun, 4 Apr 2021 04:22:33 GMT Subject: RFR: 8254050: HotSpot Style Guide should permit using the "override" virtual specifier [v2] In-Reply-To: References: Message-ID: <7PJYmtT187gCOMP-Oy86qdXVaXPpl4DP3AXDx8roGTg=.844c2fef-1ef4-4666-ae4f-859d1606ec6f@github.com> > Please review and vote on this change to the HotSpot Style Guide to permit > the use of `override` virtual specifiers. The virtual specifiers `override` > and `final` were added in C++11, and use of `final` is already permitted in > HotSpot code. > > Using the `override` specifier provides error checking that the function is > indeed overriding a virtual function declared in a base class. This can > prevent some often surprisingly difficult to spot bugs. > > This is a modification of the Style Guide, so rough consensus among > the HotSpot Group members is required to make this change. Only Group > members should vote for approval (via the github PR), though reasoned > objections or comments from anyone will be considered. A decision on > this proposal will not be made before Tuesday 30-Mar-2021 at 12h00 UTC. > > Since we're piggybacking on github PRs here, please use the PR review > process to approve (click on Review Changes > Approve), rather than > sending a "vote: yes" email reply that would be normal for a CFV. > Other responses can still use email of course. Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into override_specifier - permit override specifier ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3021/files - new: https://git.openjdk.java.net/jdk/pull/3021/files/a48a6036..375a916e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3021&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3021&range=00-01 Stats: 42617 lines in 2058 files changed: 23969 ins; 9403 del; 9245 mod Patch: https://git.openjdk.java.net/jdk/pull/3021.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3021/head:pull/3021 PR: https://git.openjdk.java.net/jdk/pull/3021 From kbarrett at openjdk.java.net Sun Apr 4 04:22:39 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sun, 4 Apr 2021 04:22:39 GMT Subject: RFR: 8254050: HotSpot Style Guide should permit using the "override" virtual specifier [v2] In-Reply-To: References: Message-ID: On Tue, 16 Mar 2021 14:27:10 GMT, Daniel D. Daugherty wrote: >> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: >> >> - Merge branch 'master' into override_specifier >> - permit override specifier > > doc/hotspot-style.md line 753: > >> 751: ([n2928](http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2928.htm)), >> 752: ([n3206](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3206.htm)), >> 753: ([n3272](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3272.htm)) > > nit - The difference in case caught my attention: > > JTC1 <-> jtc1 > SC22 <-> sc22 > WG21 <-> wg21 > > any particular significance to the difference? That's how they were written in the document I cut-and-pasted them from (https://gcc.gnu.org/projects/cxx-status.html). Some of the links there seem to be to systems with case sensitive file-systems. ------------- PR: https://git.openjdk.java.net/jdk/pull/3021 From kbarrett at openjdk.java.net Sun Apr 4 04:26:25 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sun, 4 Apr 2021 04:26:25 GMT Subject: RFR: 8254050: HotSpot Style Guide should permit using the "override" virtual specifier [v3] In-Reply-To: References: Message-ID: > Please review and vote on this change to the HotSpot Style Guide to permit > the use of `override` virtual specifiers. The virtual specifiers `override` > and `final` were added in C++11, and use of `final` is already permitted in > HotSpot code. > > Using the `override` specifier provides error checking that the function is > indeed overriding a virtual function declared in a base class. This can > prevent some often surprisingly difficult to spot bugs. > > This is a modification of the Style Guide, so rough consensus among > the HotSpot Group members is required to make this change. Only Group > members should vote for approval (via the github PR), though reasoned > objections or comments from anyone will be considered. A decision on > this proposal will not be made before Tuesday 30-Mar-2021 at 12h00 UTC. > > Since we're piggybacking on github PRs here, please use the PR review > process to approve (click on Review Changes > Approve), rather than > sending a "vote: yes" email reply that would be normal for a CFV. > Other responses can still use email of course. Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: rebuild hotspot-style.html ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3021/files - new: https://git.openjdk.java.net/jdk/pull/3021/files/375a916e..301a604d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3021&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3021&range=01-02 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3021.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3021/head:pull/3021 PR: https://git.openjdk.java.net/jdk/pull/3021 From kbarrett at openjdk.java.net Sun Apr 4 04:26:25 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sun, 4 Apr 2021 04:26:25 GMT Subject: RFR: 8254050: HotSpot Style Guide should permit using the "override" virtual specifier [v3] In-Reply-To: References: Message-ID: On Tue, 23 Mar 2021 19:08:26 GMT, Vladimir Kozlov wrote: >> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision: >> >> rebuild hotspot-style.html > > Marked as reviewed by kvn (Reviewer). There have been no issues raised with the proposed change, and plenty of support. It has been approved by the HotSpot Lead (@vnkozlov ). Thanks for all the reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/3021 From kbarrett at openjdk.java.net Sun Apr 4 04:30:01 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sun, 4 Apr 2021 04:30:01 GMT Subject: Integrated: 8254050: HotSpot Style Guide should permit using the "override" virtual specifier In-Reply-To: References: Message-ID: On Tue, 16 Mar 2021 03:44:56 GMT, Kim Barrett wrote: > Please review and vote on this change to the HotSpot Style Guide to permit > the use of `override` virtual specifiers. The virtual specifiers `override` > and `final` were added in C++11, and use of `final` is already permitted in > HotSpot code. > > Using the `override` specifier provides error checking that the function is > indeed overriding a virtual function declared in a base class. This can > prevent some often surprisingly difficult to spot bugs. > > This is a modification of the Style Guide, so rough consensus among > the HotSpot Group members is required to make this change. Only Group > members should vote for approval (via the github PR), though reasoned > objections or comments from anyone will be considered. A decision on > this proposal will not be made before Tuesday 30-Mar-2021 at 12h00 UTC. > > Since we're piggybacking on github PRs here, please use the PR review > process to approve (click on Review Changes > Approve), rather than > sending a "vote: yes" email reply that would be normal for a CFV. > Other responses can still use email of course. This pull request has now been integrated. Changeset: 07806669 Author: Kim Barrett URL: https://git.openjdk.java.net/jdk/commit/07806669 Stats: 10 lines in 2 files changed: 6 ins; 4 del; 0 mod 8254050: HotSpot Style Guide should permit using the "override" virtual specifier Reviewed-by: dholmes, jrose, stuefe, tschatzl, dcubed, iklam, kvn ------------- PR: https://git.openjdk.java.net/jdk/pull/3021 From ysuenaga at openjdk.java.net Mon Apr 5 00:31:57 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Mon, 5 Apr 2021 00:31:57 GMT Subject: RFR: 8263718: unused-result warning happens at os_linux.cpp [v2] In-Reply-To: <_fwXlba2zOGlxvF4NDbUKm7psfPRid2kZaGHTpRMlE0=.75ce10c1-f848-44fe-8d5e-70044d2fe4d9@github.com> References: <5W8i9Wro1OWbzlUbEyeTy4TBLQmhWysLSjDcjadMygc=.a8348509-517b-48c4-be70-68b3ddb1088b@github.com> <_fwXlba2zOGlxvF4NDbUKm7psfPRid2kZaGHTpRMlE0=.75ce10c1-f848-44fe-8d5e-70044d2fe4d9@github.com> Message-ID: On Tue, 30 Mar 2021 05:57:45 GMT, Yasumasa Suenaga wrote: >> I think I am comfortable with the changes as proposed. A summary of what we found for each platform should be put in the bug report. >> >> Thanks, >> David > > Thanks @dholmes-ora for your review! > >> A summary of what we found for each platform should be put in the bug report. > > I left it to the [comment](https://bugs.openjdk.java.net/browse/JDK-8263718?focusedCommentId=14410190&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14410190). PING: could you review it? I need one more reviewer to push. ------------- PR: https://git.openjdk.java.net/jdk/pull/3042 From xliu at openjdk.java.net Mon Apr 5 06:52:22 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Mon, 5 Apr 2021 06:52:22 GMT Subject: RFR: 8229517: Support for optional asynchronous/buffered logging [v2] In-Reply-To: References: Message-ID: On Fri, 26 Mar 2021 09:12:05 GMT, Volker Simonis wrote: >> Xin Liu has updated the pull request incrementally with two additional commits since the last revision: >> >> - 8229517: Support for optional asynchronous/buffered logging >> >> add a constraint for the option LogAsyncInterval. >> - 8229517: Support for optional asynchronous/buffered logging >> >> LogMessage supports async_mode. >> remove the option AsyncLogging >> renanme the option GCLogBufferSize to AsyncLogBufferSize >> move drop_log() to LogAsyncFlusher. > > src/hotspot/share/logging/logFileOutput.cpp line 322: > >> 320: >> 321: LogAsyncFlusher* flusher = LogAsyncFlusher::instance(); >> 322: if (_async_mode && flusher != NULL) { > > Why you don't check for `flusher == NULL` in `LogAsyncFlusher::instance()` and call `LogAsyncFlusher::initialize()` in case it is NULL. I think it's no difference where the NULL check is and doing it in `LogAsyncFlusher::instance()` will save you from calling `LogAsyncFlusher::initialize()` in `init_globals()`. > > Put `LogAsyncFlusher::instance()` into the `if (_async_mode)` block and add an assertion that `flusher != NULL`. hi, @simonis and @tstuefe The purpose of nullcheck here is to circumvent the problem of circular dependency which also mentioned by Thomas. Logging subsystem as a low-level infrastructure could be invoked as early as `LogConfiguration::initialize` has done in `Threads::create_vm()`. At this time, mutex and Thread haven't been initialized, therefore, I can't initialize `LogAsyncFlusher` appropriately. The reason I provide separated APIs `LogAsyncFlusher::initialize()` & `LogAsyncFlusher::instance()` because I need to separate log subsystems into 2 phrases. LogAsyncFlusher::initialize() marks an important point. Before this point, logging subsystem can only use synchronous mode no matter what. After this point, async_mode takes effect because buffer has been established. That is to say, all code in this PR can only take over logging after that point. I read Thomas concerned about fancy calls such as strdup, os::malloc etc. Instead of designing async-logging absolutely self-contained and low-level, I chose a common technique called 'lazy-initialization'. I don't think async mode is absolutely necessary in the startup time of hotspot. The gain is obvious. I can use hotspot's established constructs to simplify the implementation. May I ask you and Thomas to comment on this design? If it works, I will add more comments about it. > test/hotspot/gtest/logging/test_asynclog.cpp line 168: > >> 166: EXPECT_FALSE(file_contains_substring(TestLogFileName, "log_trace-test")); // trace message is masked out >> 167: EXPECT_TRUE(file_contains_substring(TestLogFileName, "log_debug-test")); >> 168: } > > Should have a newline at the end. noted. ------------- PR: https://git.openjdk.java.net/jdk/pull/3135 From ioi.lam at oracle.com Mon Apr 5 17:01:19 2021 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 5 Apr 2021 10:01:19 -0700 Subject: [PING] Re: RFR: 8264565: Templatize num_arguments() functions of DCmd subclasses In-Reply-To: References: Message-ID: <250f322c-586a-bc08-98ed-3a8e33d30bb0@oracle.com> Hi, could I have one more review for this? Thanks - Ioi On 4/1/21 11:11 AM, Ioi Lam wrote: > We have many version of `num_arguments()` for the `DCmd` subclasses. They all have identical structure. We should templatize them to reduce duplicated code and avoid cut-and-paste errors. > > It's still possible to write a customized `num_arguments()` function (although none of the existing cases needs to do that). The rules are described here: > > class DCmd : public ResourceObj { > ... > // num_arguments() is used by the DCmdFactoryImpl::get_num_arguments() template functions. > // - For subclasses of DCmdWithParser, it's calculated by DCmdParser::num_arguments(). > // - Other subclasses of DCmd have zero arguments by default. You can change this > // by defining your own version of MyDCmd::num_arguments(). > static int num_arguments() { return 0; } > > ------------- > > Commit messages: > - removed remaining boilerplate num_arguments() functions > - DebugOnCmdStartDCmd does not need to subclass from DCmdWithParser > - 8264565: Templatize num_arguments() functions of DCmd subclasses > > Changes: https://git.openjdk.java.net/jdk/pull/3312/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3312&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8264565 > Stats: 277 lines in 8 files changed: 27 ins; 241 del; 9 mod > Patch: https://git.openjdk.java.net/jdk/pull/3312.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/3312/head:pull/3312 > > PR: https://git.openjdk.java.net/jdk/pull/3312 From iklam at openjdk.java.net Mon Apr 5 17:42:49 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 5 Apr 2021 17:42:49 GMT Subject: RFR: 8262328: Templatize JVMFlag boilerplate access methods [v2] In-Reply-To: References: Message-ID: > We have a bunch of boilerplate method like: > > JVMFlagAccess::boolAtPut (JVMFlag* f, bool* v, JVMFlagOrigin origin) > JVMFlagAccess::intAtPut (JVMFlag* f, int* v, JVMFlagOrigin origin) > JVMFlagAccess::uintAtPut (JVMFlag* f, uint* v, JVMFlagOrigin origin) > ... > > Similarly, we also have 8 different functions: JVMFlag::{set_bool, set_int, set_intx, ...} > > We should replace such patterns with > > template > JVMFlagAccess::set(JVMFlag* f, T* value, JVMFlagOrigin origin) > > This would allow us to templatize the 8x boilerplate functions in writeableFlags.cpp. > > The flag access code in whitebox.cpp can also be improved. Ioi Lam has updated the pull request incrementally with two additional commits since the last revision: - removed unnecessary #include - Restored in templates so we can require exact types (i.e., cannot mix size_t and uintx even they might be the same type of some platforms) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3318/files - new: https://git.openjdk.java.net/jdk/pull/3318/files/86ce3ce7..58160ff0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3318&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3318&range=00-01 Stats: 123 lines in 9 files changed: 32 ins; 17 del; 74 mod Patch: https://git.openjdk.java.net/jdk/pull/3318.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3318/head:pull/3318 PR: https://git.openjdk.java.net/jdk/pull/3318 From iklam at openjdk.java.net Mon Apr 5 17:43:23 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 5 Apr 2021 17:43:23 GMT Subject: RFR: 8264540: WhiteBox.metaspaceReserveAlignment should return shared region alignment [v3] In-Reply-To: References: Message-ID: <9a58Ahl8yOmTOqzasP52xsNh_OgoxGRRNnDzGuHnXLI=.19f485bc-90bb-454d-8f32-1181a246344c@github.com> On Fri, 2 Apr 2021 17:31:39 GMT, Yumin Qi wrote: >> Hi, Please review >> After JDK-8236847, the shared region alignment (new as MetaspaceShared::core_region_alignment) is no longer default to os pagesize, it is a configurable value at build time instead. The WhiteBox api metaspaceReserveAlignment() should reflect the change. >> >> Tests:tier1,tier2,tier3,tier4 > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > SharedRegionAlignmentTest: removed timeout on test, removed is_alignment_logged Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3309 From iklam at openjdk.java.net Mon Apr 5 17:45:20 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 5 Apr 2021 17:45:20 GMT Subject: RFR: 8262328: Templatize JVMFlag boilerplate access methods In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 03:20:51 GMT, Ioi Lam wrote: >> We have a bunch of boilerplate method like: >> >> JVMFlagAccess::boolAtPut (JVMFlag* f, bool* v, JVMFlagOrigin origin) >> JVMFlagAccess::intAtPut (JVMFlag* f, int* v, JVMFlagOrigin origin) >> JVMFlagAccess::uintAtPut (JVMFlag* f, uint* v, JVMFlagOrigin origin) >> ... >> >> Similarly, we also have 8 different functions: JVMFlag::{set_bool, set_int, set_intx, ...} >> >> We should replace such patterns with >> >> template >> JVMFlagAccess::set(JVMFlag* f, T* value, JVMFlagOrigin origin) >> >> This would allow us to templatize the 8x boilerplate functions in writeableFlags.cpp. >> >> The flag access code in whitebox.cpp can also be improved. > > I need to work on this PR some more. Closing it for now. I've updated the patch and the JVMFlagAccess API should have identical behavior as before. Now it's ready to be reviewed again. ------------- PR: https://git.openjdk.java.net/jdk/pull/3318 From hseigel at openjdk.java.net Mon Apr 5 18:05:42 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Mon, 5 Apr 2021 18:05:42 GMT Subject: RFR: 8264711: More runtime TRAPS cleanups Message-ID: Please review this additional cleanup of use of TRAPS in hotspot runtime code. The changes were tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows and Mach5 tiers 3-5 on Linux x64. Thanks, Harold ------------- Commit messages: - 8264711: More runtime TRAPS cleanups Changes: https://git.openjdk.java.net/jdk/pull/3345/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3345&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264711 Stats: 146 lines in 32 files changed: 5 ins; 19 del; 122 mod Patch: https://git.openjdk.java.net/jdk/pull/3345.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3345/head:pull/3345 PR: https://git.openjdk.java.net/jdk/pull/3345 From minqi at openjdk.java.net Mon Apr 5 18:34:27 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Mon, 5 Apr 2021 18:34:27 GMT Subject: RFR: 8264540: WhiteBox.metaspaceReserveAlignment should return shared region alignment [v3] In-Reply-To: References: Message-ID: <-_FyoGTj6GjeJ_k1KHbly2osY4AThbRqbCNiNwi9LQ8=.974cb327-e189-4399-8d67-130ee0723d09@github.com> On Fri, 2 Apr 2021 17:47:16 GMT, Calvin Cheung wrote: >> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> SharedRegionAlignmentTest: removed timeout on test, removed is_alignment_logged > > Marked as reviewed by ccheung (Reviewer). @calvinccheung @iklam Thanks for review! ------------- PR: https://git.openjdk.java.net/jdk/pull/3309 From minqi at openjdk.java.net Mon Apr 5 18:34:27 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Mon, 5 Apr 2021 18:34:27 GMT Subject: Integrated: 8264540: WhiteBox.metaspaceReserveAlignment should return shared region alignment In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 16:41:15 GMT, Yumin Qi wrote: > Hi, Please review > After JDK-8236847, the shared region alignment (new as MetaspaceShared::core_region_alignment) is no longer default to os pagesize, it is a configurable value at build time instead. The WhiteBox api metaspaceReserveAlignment() should reflect the change. > > Tests:tier1,tier2,tier3,tier4 This pull request has now been integrated. Changeset: d920f858 Author: Yumin Qi URL: https://git.openjdk.java.net/jdk/commit/d920f858 Stats: 32 lines in 5 files changed: 14 ins; 5 del; 13 mod 8264540: WhiteBox.metaspaceReserveAlignment should return shared region alignment Reviewed-by: ccheung, iklam ------------- PR: https://git.openjdk.java.net/jdk/pull/3309 From ioi.lam at oracle.com Mon Apr 5 18:36:46 2021 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 5 Apr 2021 11:36:46 -0700 Subject: Request For Comment: Asynchronous Logging In-Reply-To: References: Message-ID: <044c99ac-90b0-4953-98d2-1a90da6d72a2@oracle.com> On 3/31/21 5:16 PM, Yasumasa Suenaga wrote: > On 2021/04/01 4:10, Thomas St?fe wrote: >> >> I prefer to keep "async" a global option. I think we should expose as >> little freedom to the user as possible. I do not think there is a >> sensible scenario where one would wish to write to one file with >> async, to another file without async. Nevertheless, if we make this >> option target-specific this has to work, and perform, and be >> regression-tested in all its variations. Every option we roll out is >> a contract we have to fulfill. They find their way into all kinds of >> environments and user scripts, and once out there it is difficult to >> roll out incompatible changes. For instance,? there is no mechanism >> to deprecate a part of an option. We have a mechanism for deprecating >> normal VM options, but Xlog is not a? normal option. > > I don't like to keep "async" a global option because other -Xlog > options (e.g. filecount) does not global. > It might break consistency for -Xlog options. > There is actually one global Xlog option today: ??? java -Xlog:disable .... For async logging, I would prefer a global option like ??? java -Xlog:async -Xlog:gc=gc.txt -Xlog:metaspace=metaspace.txt I think we should expand the set of global Xlog options when appropriate. To take this further (maybe in a separate RFE), having a global file option will be useful. It's a pain to specify the same file many times, especially if you don't want the log file rotation: ??? java? -Xlog:gc=log.txt:none:filesize=0 -Xlog:metaspace=log.txt:none:filesize=0 ... Yes, you can put all of the logs into a single command-line argument, like ??? java? -Xlog:gc,metaspace:file=log.txt:none:filesize=0 but that will be difficult if you have a script that builds the command-line conditionally. So, if we now add a new "async" option for each file, it will make things even more unmanageable. Instead, something like this will be much easier to use: ??? java? -Xlog:file=log.txt -Xlog:gc -Xlog:metaspace ??? java? -Xlog:file=log.txt -Xlog:gc -Xlog:metaspace -Xlog:async Thanks - Ioi From lfoltan at openjdk.java.net Mon Apr 5 19:07:19 2021 From: lfoltan at openjdk.java.net (Lois Foltan) Date: Mon, 5 Apr 2021 19:07:19 GMT Subject: RFR: 8264711: More runtime TRAPS cleanups In-Reply-To: References: Message-ID: On Mon, 5 Apr 2021 17:57:13 GMT, Harold Seigel wrote: > Please review this additional cleanup of use of TRAPS in hotspot runtime code. The changes were tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows and Mach5 tiers 3-5 on Linux x64. > > Thanks, Harold Looks good Harold. One minor comment for the file jfrJavaSupport.cpp. Thanks, Lois src/hotspot/share/jfr/jni/jfrJavaSupport.cpp line 144: > 142: ObjectSynchronizer::jni_enter(h_obj, THREAD->as_Java_thread()); > 143: ObjectSynchronizer::notifyall(h_obj, THREAD); > 144: ObjectSynchronizer::jni_exit(THREAD->as_Java_thread(), h_obj()); For consistency can you switch the parameter order for jni_enter as well in this change? It looks a little bit odd that jni_exit was changed and not jni_enter. ------------- Marked as reviewed by lfoltan (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3345 From pchilanomate at openjdk.java.net Mon Apr 5 19:14:26 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Mon, 5 Apr 2021 19:14:26 GMT Subject: RFR: 8264711: More runtime TRAPS cleanups In-Reply-To: References: Message-ID: On Mon, 5 Apr 2021 17:57:13 GMT, Harold Seigel wrote: > Please review this additional cleanup of use of TRAPS in hotspot runtime code. The changes were tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows and Mach5 tiers 3-5 on Linux x64. > > Thanks, Harold Hi Harold, I looked at the changes to synchronization code and looks good except for one issue below. Thanks, Patricio src/hotspot/share/prims/jni.cpp line 2738: > 2736: > 2737: Handle obj(THREAD, JNIHandles::resolve_non_null(jobj)); > 2738: ObjectSynchronizer::jni_exit(THREAD->as_Java_thread(), obj()); Here we would return JNI_ERR if we throw IMSE from jni_exit(). src/hotspot/share/runtime/synchronizer.cpp line 609: > 607: // intentionally do not use CHECK on check_owner because we must exit the > 608: // monitor even if an exception was already pending. > 609: if (monitor->check_owner(current)) { We can actually throw IMSE from check_owner() if this thread is not the real owner. ------------- PR: https://git.openjdk.java.net/jdk/pull/3345 From github.com+71302734+amitdpawar at openjdk.java.net Mon Apr 5 20:01:46 2021 From: github.com+71302734+amitdpawar at openjdk.java.net (Amit Pawar) Date: Mon, 5 Apr 2021 20:01:46 GMT Subject: RFR: JDK-8260332: ParallelGC: Cooperative pretouch for oldgen expansion [v3] In-Reply-To: References: Message-ID: <05FD9DBxPoyo_8qezoYQ6CB9I9jRToM0gyeFhGK9zb4=.c9030357-a5aa-4ef5-95fe-34af135bbeee@github.com> > In case of ParallelGC, oldgen expansion can happen during promotion. Expanding thread will touch the pages and can't request for task execution as this GC thread is already executing a task. The expanding thread holds the lock on "ExpandHeap_lock" to resize the oldgen and other threads may wait for their turn. This is a blocking call. > > This patch changes this behavior by adding another constructor in "MutexLocker" class to enable non blocking or try_lock operation. This way one thread will acquire the lock and other threads can join pretouch work. Threads failed to acquire the lock will join pretouch only when task is marked ready by expanding thread. > > Following minimum expansion size are seen during expansion. > 1. 512KB without largepages and without UseNUMA. > 2. 64MB without largepages and with UseNUMA, > 3. 2MB (on x86) with large pages and without UseNUMA, > 4. 64MB without large pages and with UseNUMA. > > When Oldgen is expanding repeatedly with smaller size then this change wont help. For such cases, resize size should adapt to application demand to make use of this change. For example if application nature triggers 100 expansion with smaller sizes in same GC then it is better to increase the expansion size during each resize to reduce the number of resizes. If this patch is accepted then will plan to fix this case in another patch. > > Jtreg all test passed. > > Please review this change. Amit Pawar has updated the pull request incrementally with one additional commit since the last revision: Updated the code as per the suggestion and enabled co-operative pretouch for both ParallelGC and G1GC. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2976/files - new: https://git.openjdk.java.net/jdk/pull/2976/files/01e5077e..f75593aa Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2976&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2976&range=01-02 Stats: 312 lines in 10 files changed: 168 ins; 105 del; 39 mod Patch: https://git.openjdk.java.net/jdk/pull/2976.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2976/head:pull/2976 PR: https://git.openjdk.java.net/jdk/pull/2976 From github.com+71302734+amitdpawar at openjdk.java.net Mon Apr 5 20:10:27 2021 From: github.com+71302734+amitdpawar at openjdk.java.net (Amit Pawar) Date: Mon, 5 Apr 2021 20:10:27 GMT Subject: RFR: JDK-8260332: ParallelGC: Cooperative pretouch for oldgen expansion [v2] In-Reply-To: References: <8hmX1slrUPMWTec3K6Z1xSV7D6JEtbmLEox0JNZ93xQ=.66ea31cd-f702-4653-8a12-01cea1d50843@github.com> Message-ID: On Mon, 29 Mar 2021 09:22:43 GMT, Kim Barrett wrote: >> Thank you Kim for your reply and please see my inline comments. >>> >>> >>> > [https://bugs.openjdk.java.net/browse/JDK-8254699](JDK-8254699) contains test results in XL file to show PreTouchParallelChunkSize was recently changed from 1GB to 4MB on Linux after testing various sizes. I have downloaded the same XL file and same is updated for Oldgen case during resize and it gives some rough idea about the improvement for this fix and follow up fix. Please check "PretouchOldgenDuringResize" sheet for "Co-operative Fix" and "Adaptive Resize Fix" columns. >>> > [PreTouchParallelChunkSize_TestResults_UpdatedForOldGenCase.xlsx](https://github.com/openjdk/jdk/files/6147180/PreTouchParallelChunkSize_TestResults_UpdatedForOldGenCase.xlsx) >>> >>> I'm not sure how to interpret this. In particular, it says "Test done using November 27rd Openjdk build". That predates a number of recent changes in this area that seem relevant. Is that correct? Or is that stale and the data has been updated for a newer baseline. >> >> Sorry for the confusion. I didnt test again and pre-touch time taken with different chunk size per thread was already recorded in the spreadsheet and thought to use it for reference to reply to David feedback "A change like this needs a lot more testing than that, both functionally and performance.". >> >>> >>> Also, can you provide details about how this information is generated and collected? I would like to reproduce the results and do some other experiments. >> >> JDK-8254699 was fixed by me and test was done using SPECJbb composite with following command along with JVM flag "PreTouchParallelChunkSize" with values 1G (earlier default on x86) and 4M (current default on x86). To generate this info, "Ticks::now()" function was called to record the time taken for pretouch operation. The first table (please ignore resize related) in the sheet "SPECjbb_Summary" was created from the sheet "SPECjbb_128C256T_GCPretouchTime" that contains pretouch log dumps for SPECjbb composite tests. >> >> Command (also mentioned in SPECjbb_128C256T_GCPretouchTime sheet): >> -Xms24g -Xmx970g -Xmn960g -server -XX:+UseParallelGC -XX:+AlwaysPreTouch -XX:+UseLargePages -XX:LargePageSizeInBytes=2m -XX:MaxTenuringThreshold=15 -XX:+ScavengeBeforeFullGC -XX:+UseAdaptiveSizePolicy -XX:ParallelGCThreads=256 -XX:-UseBiasedLocking -XX:SurvivorRatio=200 -XX:TargetSurvivorRatio=95 -XX:+UseNUMA -XX:-UseNUMAInterleaving -XX:+UseTransparentHugePages -XX:-UseAdaptiveNUMAChunkSizing >> >>> >>> I think that, as proposed, the change is making already messy code still more messy, and some refactoring is needed. I don't know what the details of that might look like yet; I'm still exploring and poking at the code. I also need to look at the corresponding part of G1 that you mentioned. >> >> First, I thought to push this change for ParallelGC and next G1GC. Earlier ParallelGC pretouch was done with single threaded and later this was fixed by moving multithreaded pretouch common code from G1GC and ParallelGC to PretouchTask class. I thought to do it similarly for this case too. >> >>> >>> > The "Adaptive Resize Fix" column in the sheet is for next suggested fix and may possibly help to improve further. For server JVM, expansion size of 512KB, 2MB (hugepages) and 64MB looks good for first resize but later needs some attention I think. JVM flag "MinHeapDeltaBytes" needs to be known by the user and need to set it upfront. I think this can be consider for first resize in every GC and later dynamically go for higher size like double the previous size to adopt to application nature. This way it may help to reduce the GC pause time during the expansion. I thought to share my observation and my understanding could be wrong. So please check and suggest. >>> >>> I think something like this has a serious risk of growing the oldgen a lot more than needed, which may have serious downsides. >> >> I believe this depends on application runtime nature and it may expand as needed. If you still think that this change is not useful then please suggest. Will withdraw this PR. >> >> Thanks, >> Amit > >> > > [PreTouchParallelChunkSize_TestResults_UpdatedForOldGenCase.xlsx](https://github.com/openjdk/jdk/files/6147180/PreTouchParallelChunkSize_TestResults_UpdatedForOldGenCase.xlsx) >> > >> > >> > I'm not sure how to interpret this. In particular, it says "Test done using November 27rd Openjdk build". That predates a number of recent changes in this area that seem relevant. Is that correct? Or is that stale and the data has been updated for a newer baseline. >> >> Sorry for the confusion. I didnt test again and pre-touch time taken with different chunk size per thread was already recorded in the spreadsheet and thought to use it for reference to reply to David feedback "A change like this needs a lot more testing than that, both functionally and performance.". > > Getting any benefit from parallel pretouch here suggests we have many threads piling up on the expand mutex. Before JDK-8260045 (pushed together with JDK-8260044 on 2/12/2021) that would lead to "expansion storms", where several threads piled up on that mutex and serially entered and did a new expansion (with associated pretouch, and possibly of significant size). Getting rid of the expansion storms may alleviate the serial pretouch quite a bit. There may still be some benefit to cooperative parallization, but new measurements are needed to determine how much of a problem still exists. > > If it is still worth addressing, I think the proposed approach has problems, as it makes messy complicated code messier and more complicated. I think some preliminary refactoring is needed. For example, splitting MutableSpace::initialize into a setup-pages part and set-the-range part. I've not explored in detail what's needed yet, pending new measurements. (I haven't had time to do those measurements yet myself.) Thanks Kim for your feedback. I have updated the code and it looks good now. Please use "Full" diff to see all the changes. Summary of changes: added new class in pretouchTask.hpp file for synchronization. Now co-operative pretouch is enabled for both ParallelGC and G1GC. For testing purpose, added new flag "UseMultithreadedPretouchForOldGen" and timing is enabled for old-gen pretouch case for measurements. Enabling this flag makes try_lock to be used instead of lock (which is current default). This change will be useful only if PreTouchParallelChunkSize value is not very huge compared to old-gen expansion size. For Linux it is set to 4MB and for other OS it is still 1GB. Testing SPECJbb composite on AMD EPYC machine shows following improvement. - Parallel GC: with UseNUMA, minimum expansion size is 64MB -- with 2MB hugepages, master branch time taken is ~9-10ms and current fix time taken is ~1-2ms` -- without hugepages, master branch time taken is ~14-17ms and current fix time taken is ~2-3ms - Parallel GC: without UseNUMA, minimum expansion size is 512KB so this change is not useful for this size. Sometime expansion goes upto 20MB then pretouch takes less time for such large size. - G1 GC: with UseNUMA, maximum expansion size is 32MB -- with 2MB hugepages, master branch time taken is ~5-7ms and current fix time taken is ~1-7ms` (higher time due to single thread activity as there was no other thread waiting to acquire the lock) - G1 GC: without UseNUMA, minimum expansion size 64KB and maximum expansion size is 32MB -- without hugepages, master branch time taken = ~9-11ms and current fix time taken ~2-9ms (same here too) Please check. ------------- PR: https://git.openjdk.java.net/jdk/pull/2976 From hseigel at openjdk.java.net Mon Apr 5 20:27:54 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Mon, 5 Apr 2021 20:27:54 GMT Subject: RFR: 8264711: More runtime TRAPS cleanups [v2] In-Reply-To: References: Message-ID: On Mon, 5 Apr 2021 19:11:49 GMT, Patricio Chilano Mateo wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> Undo change to ObjectSynchronizer::jni_exit() > > Hi Harold, > > I looked at the changes to synchronization code and looks good except for one issue below. > > Thanks, > Patricio Thanks Lois and Patricio for reviewing the change! I removed my bogus change to ObjectSynchronizer::jni_exit() which also made calls consistent in jfrJavaSupport.cpp. Harold ------------- PR: https://git.openjdk.java.net/jdk/pull/3345 From hseigel at openjdk.java.net Mon Apr 5 20:27:53 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Mon, 5 Apr 2021 20:27:53 GMT Subject: RFR: 8264711: More runtime TRAPS cleanups [v2] In-Reply-To: References: Message-ID: > Please review this additional cleanup of use of TRAPS in hotspot runtime code. The changes were tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows and Mach5 tiers 3-5 on Linux x64. > > Thanks, Harold Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: Undo change to ObjectSynchronizer::jni_exit() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3345/files - new: https://git.openjdk.java.net/jdk/pull/3345/files/b83f1404..e488fb8a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3345&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3345&range=00-01 Stats: 6 lines in 4 files changed: 1 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/3345.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3345/head:pull/3345 PR: https://git.openjdk.java.net/jdk/pull/3345 From pchilanomate at openjdk.java.net Mon Apr 5 21:58:18 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Mon, 5 Apr 2021 21:58:18 GMT Subject: RFR: 8264711: More runtime TRAPS cleanups [v2] In-Reply-To: References: Message-ID: <2bT7H0E5An2OdtaDZvm3JWsrGlbSGxhSNdlfIp81N4s=.75e61e4b-1ab3-48cc-be1d-5e027a56e079@github.com> On Mon, 5 Apr 2021 20:27:53 GMT, Harold Seigel wrote: >> Please review this additional cleanup of use of TRAPS in hotspot runtime code. The changes were tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows and Mach5 tiers 3-5 on Linux x64. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > Undo change to ObjectSynchronizer::jni_exit() Marked as reviewed by pchilanomate (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3345 From pchilanomate at openjdk.java.net Mon Apr 5 21:58:19 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Mon, 5 Apr 2021 21:58:19 GMT Subject: RFR: 8264711: More runtime TRAPS cleanups [v2] In-Reply-To: References: Message-ID: On Mon, 5 Apr 2021 20:24:31 GMT, Harold Seigel wrote: > Thanks Lois and Patricio for reviewing the change! > I removed my bogus change to ObjectSynchronizer::jni_exit() which also made calls consistent in jfrJavaSupport.cpp. > Harold Thanks Harold! Fix looks good. ------------- PR: https://git.openjdk.java.net/jdk/pull/3345 From dholmes at openjdk.java.net Mon Apr 5 22:29:30 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 5 Apr 2021 22:29:30 GMT Subject: RFR: 8264565: Templatize num_arguments() functions of DCmd subclasses In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 17:46:22 GMT, Ioi Lam wrote: > We have many version of `num_arguments()` for the `DCmd` subclasses. They all have identical structure. We should templatize them to reduce duplicated code and avoid cut-and-paste errors. > > It's still possible to write a customized `num_arguments()` function (although none of the existing cases needs to do that). The rules are described here: > > class DCmd : public ResourceObj { > ... > // num_arguments() is used by the DCmdFactoryImpl::get_num_arguments() template functions. > // - For subclasses of DCmdWithParser, it's calculated by DCmdParser::num_arguments(). > // - Other subclasses of DCmd have zero arguments by default. You can change this > // by defining your own version of MyDCmd::num_arguments(). > static int num_arguments() { return 0; } Looks like a good cleanup! Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3312 From iklam at openjdk.java.net Mon Apr 5 22:50:55 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 5 Apr 2021 22:50:55 GMT Subject: RFR: 8264565: Templatize num_arguments() functions of DCmd subclasses [v2] In-Reply-To: References: Message-ID: > We have many version of `num_arguments()` for the `DCmd` subclasses. They all have identical structure. We should templatize them to reduce duplicated code and avoid cut-and-paste errors. > > It's still possible to write a customized `num_arguments()` function (although none of the existing cases needs to do that). The rules are described here: > > class DCmd : public ResourceObj { > ... > // num_arguments() is used by the DCmdFactoryImpl::get_num_arguments() template functions. > // - For subclasses of DCmdWithParser, it's calculated by DCmdParser::num_arguments(). > // - Other subclasses of DCmd have zero arguments by default. You can change this > // by defining your own version of MyDCmd::num_arguments(). > static int num_arguments() { return 0; } Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge branch 'master' into 8264565-templatize-dcmd-num-arguments - removed remaining boilerplate num_arguments() functions - DebugOnCmdStartDCmd does not need to subclass from DCmdWithParser - 8264565: Templatize num_arguments() functions of DCmd subclasses ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3312/files - new: https://git.openjdk.java.net/jdk/pull/3312/files/ec38f55e..373b1c11 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3312&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3312&range=00-01 Stats: 17290 lines in 172 files changed: 13403 ins; 2198 del; 1689 mod Patch: https://git.openjdk.java.net/jdk/pull/3312.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3312/head:pull/3312 PR: https://git.openjdk.java.net/jdk/pull/3312 From dholmes at openjdk.java.net Mon Apr 5 23:31:27 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 5 Apr 2021 23:31:27 GMT Subject: RFR: 8264711: More runtime TRAPS cleanups [v2] In-Reply-To: References: Message-ID: On Mon, 5 Apr 2021 20:27:53 GMT, Harold Seigel wrote: >> Please review this additional cleanup of use of TRAPS in hotspot runtime code. The changes were tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows and Mach5 tiers 3-5 on Linux x64. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > Undo change to ObjectSynchronizer::jni_exit() Hi Harold, Lots of good cleanup here but also a couple of things that I think are incorrect. Platform string creation can throw exceptions; and I also believe the ClassFileLoadHook can too. Thanks, David src/hotspot/share/classfile/javaClasses.cpp line 396: > 394: > 395: // Converts a C string to a Java String based on current encoding > 396: Handle java_lang_String::create_from_platform_dependent_str(JavaThread* current, const char* str) { This change is incorrect. JNU_NewStringPlatform can raise an exception so TRAPS here is correct. src/hotspot/share/classfile/klassFactory.cpp line 117: > 115: Handle protection_domain, > 116: JvmtiCachedClassFileData** cached_class_file, > 117: TRAPS) { I don't think this removal of TRAPS is correct. The ClassFileLoadHook could result in an exception becoming pending. src/hotspot/share/prims/jvmtiEnv.cpp line 709: > 707: > 708: // need the path as java.lang.String > 709: Handle path = java_lang_String::create_from_platform_dependent_str(THREAD, segment); This change will need reverting as an exception is possible as previously noted. But note that if there was no possibility of exception here then the following check of HAS_PENDING_EXCEPTION should also have been removed. ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3345 From david.holmes at oracle.com Mon Apr 5 23:42:43 2021 From: david.holmes at oracle.com (David Holmes) Date: Tue, 6 Apr 2021 09:42:43 +1000 Subject: RFR: 8264711: More runtime TRAPS cleanups In-Reply-To: References: Message-ID: On 6/04/2021 5:14 am, Patricio Chilano Mateo wrote: > src/hotspot/share/prims/jni.cpp line 2738: > >> 2736: >> 2737: Handle obj(THREAD, JNIHandles::resolve_non_null(jobj)); >> 2738: ObjectSynchronizer::jni_exit(THREAD->as_Java_thread(), obj()); > > Here we would return JNI_ERR if we throw IMSE from jni_exit(). Strictly speaking we probably should return JNI_ERR in that case, but the spec (as usual) is non-specific about the relationship between error codes and throwing exceptions. I would not suggest making such a change now. Note that we would have to be careful to only return JNI_ERR in the single case of IMSE, and even then we would have to be certain that the IMSE came from the actual "exit" and not e.g. err = MonitorEnter(obj); ... throwIMSE() ... err = MonitorExit(obj) Cheers, David > src/hotspot/share/runtime/synchronizer.cpp line 609: > >> 607: // intentionally do not use CHECK on check_owner because we must exit the >> 608: // monitor even if an exception was already pending. >> 609: if (monitor->check_owner(current)) { > > We can actually throw IMSE from check_owner() if this thread is not the real owner. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3345 > From dholmes at openjdk.java.net Tue Apr 6 01:55:25 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 6 Apr 2021 01:55:25 GMT Subject: RFR: 8264644: Add PrintClassLoaderDataGraphAtExit to print the detailed CLD graph [v2] In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 16:12:49 GMT, Yi Yang wrote: >> Trivial chanage to make debugging happy, now cld->print() would be: >> >> ClassLoaderData(0x00007ff17432b670) >> - name 'platform' >> - holder WeakHandle: 0x00000007fef56678 >> - class loader 0x7ff17432b828 >> - metaspace 0x7ff17468a0b0 >> - unloading false >> - class mirror holder false >> - modified oops true >> - keep alive 0 >> - claim strong >> - handles 43 >> - dependency count 0 >> - klasses {java.sql.SQLFeatureNotSupportedException,java.sql.SQLNonTransientException,java.sql.SQLException,sun.util.resources.provider.NonBaseLocaleDataMetaInfo,org.ietf.jgss.GSSException,javax.sql.DataSource,java.sql.Wrapper,javax.sql.CommonDataSource,java.sql.Time,java.sql.Date,java.sql.Timestamp,sun.util.resources.cldr.provider.CLDRLocaleDataMetaInfo, } >> - packages 0x7ff17432bc20 >> - module 0x7ff17432c520 >> - unnamed module 0x7ff17432c3d0 >> - dictionary 0x7ff17432c470 >> - deallocate list 0x7ff0a4023bd0 > > Yi Yang has updated the pull request incrementally with one additional commit since the last revision: > > new flag PrintClassLoaderDataGraphAtExit Hi Yi, Approval in principle, but some changes requested, please see below. Thanks, David src/hotspot/share/classfile/classLoaderData.cpp line 952: > 950: out->print_cr(""); > 951: } > 952: out->print_cr(" - class loader %p", _class_loader.ptr_raw()); We don't use the %p in VM shared code as it behaves differently across platforms - use PTR_FORMAT. src/hotspot/share/oops/method.cpp line 2260: > 2258: void Method::print_jmethod_ids(const ClassLoaderData* loader_data, outputStream* out) { > 2259: out->print("%d", loader_data->jmethod_ids()->count_methods()); > 2260: } This method is pointless if it only prints the count to the stream without any descriptive text. Just delete it and print the method count directly in the caller. ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3323 From dholmes at openjdk.java.net Tue Apr 6 02:24:24 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 6 Apr 2021 02:24:24 GMT Subject: RFR: 8262328: Templatize JVMFlag boilerplate access methods [v2] In-Reply-To: References: Message-ID: On Mon, 5 Apr 2021 17:42:49 GMT, Ioi Lam wrote: >> We have a bunch of boilerplate method like: >> >> JVMFlagAccess::boolAtPut (JVMFlag* f, bool* v, JVMFlagOrigin origin) >> JVMFlagAccess::intAtPut (JVMFlag* f, int* v, JVMFlagOrigin origin) >> JVMFlagAccess::uintAtPut (JVMFlag* f, uint* v, JVMFlagOrigin origin) >> ... >> >> Similarly, we also have 8 different functions: JVMFlag::{set_bool, set_int, set_intx, ...} >> >> We should replace such patterns with >> >> template >> JVMFlagAccess::set(JVMFlag* f, T* value, JVMFlagOrigin origin) >> >> This would allow us to templatize the 8x boilerplate functions in writeableFlags.cpp. >> >> The flag access code in whitebox.cpp can also be improved. > > Ioi Lam has updated the pull request incrementally with two additional commits since the last revision: > > - removed unnecessary #include > - Restored in templates so we can require exact types (i.e., cannot mix size_t and uintx even they might be the same type of some platforms) Hi Ioi, In terms of readability and writeability I prefer AtPut() over set(). Is there any way to push the JVM_FLAG_TYPE down a level so it doesn't shout at you when reading the code? set() would look much much better. Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/3318 From yyang at openjdk.java.net Tue Apr 6 02:32:27 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Tue, 6 Apr 2021 02:32:27 GMT Subject: RFR: 8264644: Add PrintClassLoaderDataGraphAtExit to print the detailed CLD graph [v2] In-Reply-To: References: Message-ID: On Tue, 6 Apr 2021 01:43:40 GMT, David Holmes wrote: >> Yi Yang has updated the pull request incrementally with one additional commit since the last revision: >> >> new flag PrintClassLoaderDataGraphAtExit > > src/hotspot/share/oops/method.cpp line 2260: > >> 2258: void Method::print_jmethod_ids(const ClassLoaderData* loader_data, outputStream* out) { >> 2259: out->print("%d", loader_data->jmethod_ids()->count_methods()); >> 2260: } > > This method is pointless if it only prints the count to the stream without any descriptive text. Just delete it and print the method count directly in the caller. The type of jmethod_ids is JNIMethodBlock, which is declared in `method.cpp`, we have to access its internal fields via print_jmethod_ids that declared in `method.hpp`. But if we only want to show jmethod_ids's address, then we can remove Method::print_jmethod_ids and print it directly. I'm not sure if others think jmethod_ids._count is important for their debugging, so I keep unchanged :) ------------- PR: https://git.openjdk.java.net/jdk/pull/3323 From ngasson at openjdk.java.net Tue Apr 6 02:47:27 2021 From: ngasson at openjdk.java.net (Nick Gasson) Date: Tue, 6 Apr 2021 02:47:27 GMT Subject: Integrated: 8264564: AArch64: use MOVI instead of FMOV to zero FP register In-Reply-To: References: Message-ID: <4V2AbylJa_2gA42TjAObbDyT58BYDnEYMA50LyBG-kQ=.33b9d8c3-c6ae-4de9-91df-8b9043ba8a2c@github.com> On Fri, 2 Apr 2021 09:02:36 GMT, Nick Gasson wrote: > HotSpot generates an FMOV from ZR to zero a floating point register: > > fmov d0, xzr > > This used to be recommended by the Arm ARM, but that advice was removed > in revision A.j and subsequent revisions (section C.5.3). > > Integer->FP moves may be slow on some cores. Instead the preferred > instruction is MOVI with immediate zero: > > movi d0, #0x0 > > Some micro-architectures special-case FMOV from ZR, and on those cores > this change will have no effect, but in any case FMOV won't be faster > than MOVI. > > GCC made this change back in 2016: > https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=523d72071960 > > Tested tier1 on AArch64. I don't expect this to have any visible effect > on benchmarks. This pull request has now been integrated. Changeset: 43d4a6f6 Author: Nick Gasson URL: https://git.openjdk.java.net/jdk/commit/43d4a6f6 Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod 8264564: AArch64: use MOVI instead of FMOV to zero FP register Reviewed-by: aph ------------- PR: https://git.openjdk.java.net/jdk/pull/3322 From dholmes at openjdk.java.net Tue Apr 6 03:13:25 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 6 Apr 2021 03:13:25 GMT Subject: RFR: 8264644: Add PrintClassLoaderDataGraphAtExit to print the detailed CLD graph [v2] In-Reply-To: References: Message-ID: On Tue, 6 Apr 2021 02:29:28 GMT, Yi Yang wrote: >> src/hotspot/share/oops/method.cpp line 2260: >> >>> 2258: void Method::print_jmethod_ids(const ClassLoaderData* loader_data, outputStream* out) { >>> 2259: out->print("%d", loader_data->jmethod_ids()->count_methods()); >>> 2260: } >> >> This method is pointless if it only prints the count to the stream without any descriptive text. Just delete it and print the method count directly in the caller. > > The type of jmethod_ids is JNIMethodBlock, which is declared in `method.cpp`, we have to access its internal fields via print_jmethod_ids that declared in `method.hpp`. But if we only want to show jmethod_ids's address, then we can remove Method::print_jmethod_ids and print it directly. I'm not sure if others think jmethod_ids._count is important for their debugging, so I keep unchanged :) Sorry I don't see your point. I am suggesting that this: out->print (" - jmethod count "); Method::print_jmethod_ids(this, out); out->print_cr(""); be replaced by: out->print_cr(" - jmethod count %d", this->jmethod_ids()->count_methods()); ------------- PR: https://git.openjdk.java.net/jdk/pull/3323 From yyang at openjdk.java.net Tue Apr 6 03:23:29 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Tue, 6 Apr 2021 03:23:29 GMT Subject: RFR: 8264644: Add PrintClassLoaderDataGraphAtExit to print the detailed CLD graph [v2] In-Reply-To: References: Message-ID: On Tue, 6 Apr 2021 03:09:57 GMT, David Holmes wrote: >> The type of jmethod_ids is JNIMethodBlock, which is declared in `method.cpp`, we have to access its internal fields via print_jmethod_ids that declared in `method.hpp`. But if we only want to show jmethod_ids's address, then we can remove Method::print_jmethod_ids and print it directly. I'm not sure if others think jmethod_ids._count is important for their debugging, so I keep unchanged :) > > Sorry I don't see your point. I am suggesting that this: > > out->print (" - jmethod count "); > Method::print_jmethod_ids(this, out); > out->print_cr(""); > > be replaced by: > > out->print_cr(" - jmethod count %d", this->jmethod_ids()->count_methods()); Hi David, I means, `count_methods()` is inaccessible from classLoaderDataGraph.cpp because `this->jmethod_ids()` is type of JNIMethodBlock, it was defined in **method.cpp**, i.e.: // method.cpp class JNIMethodBlock { ... public: int count_methods(){...} } In order to access count_methods, we have to add an API in method.hpp and method.cpp: // method.cpp class JNIMethodBlock { ... int count_methods(){...} } void Method::print_jmethod_ids(JNIMethodBlock* block,...){ block->count_methods(); .... } // method.hpp void Method::print_jmethod_ids(JNIMethodBlock* block,...); Thanks~ Yang ------------- PR: https://git.openjdk.java.net/jdk/pull/3323 From iklam at openjdk.java.net Tue Apr 6 03:30:28 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 6 Apr 2021 03:30:28 GMT Subject: RFR: 8264565: Templatize num_arguments() functions of DCmd subclasses [v2] In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 16:46:50 GMT, Coleen Phillimore wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: >> >> - Merge branch 'master' into 8264565-templatize-dcmd-num-arguments >> - removed remaining boilerplate num_arguments() functions >> - DebugOnCmdStartDCmd does not need to subclass from DCmdWithParser >> - 8264565: Templatize num_arguments() functions of DCmd subclasses > > Wow cool and nice. Thanks @coleenp and @dholmes-ora for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/3312 From iklam at openjdk.java.net Tue Apr 6 03:30:29 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 6 Apr 2021 03:30:29 GMT Subject: Integrated: 8264565: Templatize num_arguments() functions of DCmd subclasses In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 17:46:22 GMT, Ioi Lam wrote: > We have many version of `num_arguments()` for the `DCmd` subclasses. They all have identical structure. We should templatize them to reduce duplicated code and avoid cut-and-paste errors. > > It's still possible to write a customized `num_arguments()` function (although none of the existing cases needs to do that). The rules are described here: > > class DCmd : public ResourceObj { > ... > // num_arguments() is used by the DCmdFactoryImpl::get_num_arguments() template functions. > // - For subclasses of DCmdWithParser, it's calculated by DCmdParser::num_arguments(). > // - Other subclasses of DCmd have zero arguments by default. You can change this > // by defining your own version of MyDCmd::num_arguments(). > static int num_arguments() { return 0; } This pull request has now been integrated. Changeset: ff223530 Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/ff223530 Stats: 277 lines in 8 files changed: 27 ins; 241 del; 9 mod 8264565: Templatize num_arguments() functions of DCmd subclasses Reviewed-by: coleenp, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/3312 From iklam at openjdk.java.net Tue Apr 6 03:56:50 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 6 Apr 2021 03:56:50 GMT Subject: RFR: 8262328: Templatize JVMFlag boilerplate access methods [v3] In-Reply-To: References: Message-ID: > We have a bunch of boilerplate method like: > > JVMFlagAccess::boolAtPut (JVMFlag* f, bool* v, JVMFlagOrigin origin) > JVMFlagAccess::intAtPut (JVMFlag* f, int* v, JVMFlagOrigin origin) > JVMFlagAccess::uintAtPut (JVMFlag* f, uint* v, JVMFlagOrigin origin) > ... > > Similarly, we also have 8 different functions: JVMFlag::{set_bool, set_int, set_intx, ...} > > We should replace such patterns with > > template > JVMFlagAccess::set(JVMFlag* f, T* value, JVMFlagOrigin origin) > > This would allow us to templatize the 8x boilerplate functions in writeableFlags.cpp. > > The flag access code in whitebox.cpp can also be improved. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: reinstated JVMFlagAccess::set_{bool,int,uint,...} functions for better readability ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3318/files - new: https://git.openjdk.java.net/jdk/pull/3318/files/58160ff0..4c0c8ae2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3318&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3318&range=01-02 Stats: 19 lines in 3 files changed: 9 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/3318.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3318/head:pull/3318 PR: https://git.openjdk.java.net/jdk/pull/3318 From iklam at openjdk.java.net Tue Apr 6 04:18:27 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 6 Apr 2021 04:18:27 GMT Subject: RFR: 8262328: Templatize JVMFlag boilerplate access methods [v2] In-Reply-To: References: Message-ID: <8r2foSsKCT4PIs2pu1U3eQliF0rXeXHX6RSJrpvqIrA=.d115d915-aedf-4bdc-9dce-4945095a3310@github.com> On Tue, 6 Apr 2021 02:20:54 GMT, David Holmes wrote: > Hi Ioi, > > In terms of readability and writeability I prefer AtPut() over set(). Is there any way to push the JVM_FLAG_TYPE down a level so it doesn't shout at you when reading the code? set() would look much much better. > > Thanks, > David I added the `JVMFlagAccess::set_()` functions back (they are the same as the old `AtPut` functions, but with a more consistent naming style). Now I use the more low-level `set()` only in templates where the type is not statically known. E.g, `WriteableFlags::set_flag_impl()`. * * * A related note: in an [earlier version](https://webrevs.openjdk.java.net/?repo=jdk&pr=3318&range=00), I tried to get rid of the `` altogether, where the code is much cleaner with template type inference. JVMFlag* flag = someSizetFlag; size_t s = 0; JVMFlagAccess::set(flag, &s, origin); However, this may allow type mismatch like the following, on platforms that use the exact same type for `size_t` and `uint`: JVMFlag* flag = someSizetFlag; uint s = 0; JVMFlagAccess::set(flag, &s, origin); but you will get a runtime failure on platforms where `size_t` is not the same as `uint`. So I decided against this design due to non-portability. ------------- PR: https://git.openjdk.java.net/jdk/pull/3318 From dholmes at openjdk.java.net Tue Apr 6 04:19:30 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 6 Apr 2021 04:19:30 GMT Subject: RFR: 8264644: Add PrintClassLoaderDataGraphAtExit to print the detailed CLD graph [v2] In-Reply-To: References: Message-ID: On Tue, 6 Apr 2021 03:20:08 GMT, Yi Yang wrote: >> Sorry I don't see your point. I am suggesting that this: >> >> out->print (" - jmethod count "); >> Method::print_jmethod_ids(this, out); >> out->print_cr(""); >> >> be replaced by: >> >> out->print_cr(" - jmethod count %d", this->jmethod_ids()->count_methods()); > > Hi David, > > I means, `count_methods()` is inaccessible from classLoaderDataGraph.cpp because `this->jmethod_ids()` is type of JNIMethodBlock, it was defined in **method.cpp**, i.e.: > // method.cpp > class JNIMethodBlock { > ... > public: > int count_methods(){...} > } > In order to access count_methods, we have to add an API in method.hpp and method.cpp: > // method.cpp > class JNIMethodBlock { > ... > int count_methods(){...} > } > > void Method::print_jmethod_ids(JNIMethodBlock* block,...){ > block->count_methods(); > .... > } > // method.hpp > void Method::print_jmethod_ids(JNIMethodBlock* block,...); > Thanks~ > Yang Ah I see. In that case I'd suggest adding an API to get the count. If external code knows enough about jmethod_ids that it knows to print the count, then the count is worth exposing IMO. Otherwise restore the actual "jmethod count" text to the print function so it's a stand-alone print function again. Aside: print_jmethod_ids() is badly named given it doesn't print any id's. ------------- PR: https://git.openjdk.java.net/jdk/pull/3323 From yyang at openjdk.java.net Tue Apr 6 06:38:53 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Tue, 6 Apr 2021 06:38:53 GMT Subject: RFR: 8264644: Add PrintClassLoaderDataGraphAtExit to print the detailed CLD graph [v3] In-Reply-To: References: Message-ID: > Trivial chanage to make debugging happy, now cld->print() would be: > > ClassLoaderData(0x00007ff17432b670) > - name 'platform' > - holder WeakHandle: 0x00000007fef56678 > - class loader 0x7ff17432b828 > - metaspace 0x7ff17468a0b0 > - unloading false > - class mirror holder false > - modified oops true > - keep alive 0 > - claim strong > - handles 43 > - dependency count 0 > - klasses {java.sql.SQLFeatureNotSupportedException,java.sql.SQLNonTransientException,java.sql.SQLException,sun.util.resources.provider.NonBaseLocaleDataMetaInfo,org.ietf.jgss.GSSException,javax.sql.DataSource,java.sql.Wrapper,javax.sql.CommonDataSource,java.sql.Time,java.sql.Date,java.sql.Timestamp,sun.util.resources.cldr.provider.CLDRLocaleDataMetaInfo, } > - packages 0x7ff17432bc20 > - module 0x7ff17432c520 > - unnamed module 0x7ff17432c3d0 > - dictionary 0x7ff17432c470 > - deallocate list 0x7ff0a4023bd0 Yi Yang has updated the pull request incrementally with two additional commits since the last revision: - add CLDG_lock - use PTR_FORMAT ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3323/files - new: https://git.openjdk.java.net/jdk/pull/3323/files/bfb2261d..97db359e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3323&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3323&range=01-02 Stats: 12 lines in 4 files changed: 1 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/3323.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3323/head:pull/3323 PR: https://git.openjdk.java.net/jdk/pull/3323 From yyang at openjdk.java.net Tue Apr 6 06:45:10 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Tue, 6 Apr 2021 06:45:10 GMT Subject: RFR: 8264644: Add PrintClassLoaderDataGraphAtExit to print the detailed CLD graph [v3] In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 12:47:04 GMT, Coleen Phillimore wrote: >> Yi Yang has updated the pull request incrementally with two additional commits since the last revision: >> >> - add CLDG_lock >> - use PTR_FORMAT > > This looks nice. If you use -XX:+PrintSystemDictionaryAtExit with this change, is it pages and pages long? Or does it look ok? Thank you for doing this! Thanks @coleenp @dholmes-ora for your reviews. For @coleenp : It looks Universe::verify is already called at the safepoint. print_loader_data_graph really misses CLDG_lock, it crashes without acquiring this lock. I've added MutexLocker for it. For @dholmes-ora: print_jmethod_ids now renamed to print_jmethod_ids_count. In order to prevent incorrect use, I did not add an API like Method::get_jmethod_ids_count. Method:: print_jmethod_ids should be enough at present. ------------- PR: https://git.openjdk.java.net/jdk/pull/3323 From dongbo at openjdk.java.net Tue Apr 6 06:58:03 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Tue, 6 Apr 2021 06:58:03 GMT Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v4] In-Reply-To: References: Message-ID: > In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding. > Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic idea can be found at http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords. > > Patch passed jtreg tier1-3 tests with linux-aarch64-server-fastdebug build. > Tests in `test/jdk/java/util/Base64/` and `compiler/intrinsics/base64/TestBase64.java` runned specially for the correctness of the implementation. > > There can be illegal characters at the start of the input if the data is MIME encoded. > It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now. > > A JMH micro, Base64Decode.java, is added for performance test. > With different input length (upper-bounded by parameter `maxNumBytes` in the JMH micro), > we witness ~2.5x improvements with long inputs and no regression with short inputs for raw base64 decodeing, minor improvements (~10.95%) for MIME on Kunpeng916. > > The Base64Decode.java JMH micro-benchmark results: > > Benchmark (lineSize) (maxNumBytes) Mode Cnt Score Error Units > > # Kunpeng916, intrinsic > Base64Decode.testBase64Decode 4 1 avgt 5 48.614 ? 0.609 ns/op > Base64Decode.testBase64Decode 4 3 avgt 5 58.199 ? 1.650 ns/op > Base64Decode.testBase64Decode 4 7 avgt 5 69.400 ? 0.931 ns/op > Base64Decode.testBase64Decode 4 32 avgt 5 96.818 ? 1.687 ns/op > Base64Decode.testBase64Decode 4 64 avgt 5 122.856 ? 9.217 ns/op > Base64Decode.testBase64Decode 4 80 avgt 5 130.935 ? 1.667 ns/op > Base64Decode.testBase64Decode 4 96 avgt 5 143.627 ? 1.751 ns/op > Base64Decode.testBase64Decode 4 112 avgt 5 152.311 ? 1.178 ns/op > Base64Decode.testBase64Decode 4 512 avgt 5 342.631 ? 0.584 ns/op > Base64Decode.testBase64Decode 4 1000 avgt 5 573.635 ? 1.050 ns/op > Base64Decode.testBase64Decode 4 20000 avgt 5 9534.136 ? 45.172 ns/op > Base64Decode.testBase64Decode 4 50000 avgt 5 22718.726 ? 192.070 ns/op > Base64Decode.testBase64MIMEDecode 4 1 avgt 10 63.558 ? 0.336 ns/op > Base64Decode.testBase64MIMEDecode 4 3 avgt 10 82.504 ? 0.848 ns/op > Base64Decode.testBase64MIMEDecode 4 7 avgt 10 120.591 ? 0.608 ns/op > Base64Decode.testBase64MIMEDecode 4 32 avgt 10 324.314 ? 6.236 ns/op > Base64Decode.testBase64MIMEDecode 4 64 avgt 10 532.678 ? 4.670 ns/op > Base64Decode.testBase64MIMEDecode 4 80 avgt 10 678.126 ? 4.324 ns/op > Base64Decode.testBase64MIMEDecode 4 96 avgt 10 771.603 ? 6.393 ns/op > Base64Decode.testBase64MIMEDecode 4 112 avgt 10 889.608 ? 0.759 ns/op > Base64Decode.testBase64MIMEDecode 4 512 avgt 10 3663.557 ? 3.422 ns/op > Base64Decode.testBase64MIMEDecode 4 1000 avgt 10 7017.784 ? 9.128 ns/op > Base64Decode.testBase64MIMEDecode 4 20000 avgt 10 128670.660 ? 7951.521 ns/op > Base64Decode.testBase64MIMEDecode 4 50000 avgt 10 317113.667 ? 161.758 ns/op > > # Kunpeng916, default > Base64Decode.testBase64Decode 4 1 avgt 5 48.455 ? 0.571 ns/op > Base64Decode.testBase64Decode 4 3 avgt 5 57.937 ? 0.505 ns/op > Base64Decode.testBase64Decode 4 7 avgt 5 73.823 ? 1.452 ns/op > Base64Decode.testBase64Decode 4 32 avgt 5 106.484 ? 1.243 ns/op > Base64Decode.testBase64Decode 4 64 avgt 5 141.004 ? 1.188 ns/op > Base64Decode.testBase64Decode 4 80 avgt 5 156.284 ? 0.572 ns/op > Base64Decode.testBase64Decode 4 96 avgt 5 174.137 ? 0.177 ns/op > Base64Decode.testBase64Decode 4 112 avgt 5 188.445 ? 0.572 ns/op > Base64Decode.testBase64Decode 4 512 avgt 5 610.847 ? 1.559 ns/op > Base64Decode.testBase64Decode 4 1000 avgt 5 1155.368 ? 0.813 ns/op > Base64Decode.testBase64Decode 4 20000 avgt 5 19751.477 ? 24.669 ns/op > Base64Decode.testBase64Decode 4 50000 avgt 5 50046.586 ? 523.155 ns/op > Base64Decode.testBase64MIMEDecode 4 1 avgt 10 64.130 ? 0.238 ns/op > Base64Decode.testBase64MIMEDecode 4 3 avgt 10 82.096 ? 0.205 ns/op > Base64Decode.testBase64MIMEDecode 4 7 avgt 10 118.849 ? 0.610 ns/op > Base64Decode.testBase64MIMEDecode 4 32 avgt 10 331.177 ? 4.732 ns/op > Base64Decode.testBase64MIMEDecode 4 64 avgt 10 549.117 ? 0.177 ns/op > Base64Decode.testBase64MIMEDecode 4 80 avgt 10 702.951 ? 4.572 ns/op > Base64Decode.testBase64MIMEDecode 4 96 avgt 10 799.566 ? 0.301 ns/op > Base64Decode.testBase64MIMEDecode 4 112 avgt 10 923.749 ? 0.389 ns/op > Base64Decode.testBase64MIMEDecode 4 512 avgt 10 4000.725 ? 2.519 ns/op > Base64Decode.testBase64MIMEDecode 4 1000 avgt 10 7674.994 ? 9.281 ns/op > Base64Decode.testBase64MIMEDecode 4 20000 avgt 10 142059.001 ? 157.920 ns/op > Base64Decode.testBase64MIMEDecode 4 50000 avgt 10 355698.369 ? 216.542 ns/op Dong Bo has updated the pull request incrementally with one additional commit since the last revision: load data with one ldrw, add JMH tests for error inputs ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3228/files - new: https://git.openjdk.java.net/jdk/pull/3228/files/16ebc471..54a75f05 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3228&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3228&range=02-03 Stats: 37 lines in 2 files changed: 30 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/3228.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3228/head:pull/3228 PR: https://git.openjdk.java.net/jdk/pull/3228 From rehn at openjdk.java.net Tue Apr 6 07:10:30 2021 From: rehn at openjdk.java.net (Robbin Ehn) Date: Tue, 6 Apr 2021 07:10:30 GMT Subject: RFR: 8229517: Support for optional asynchronous/buffered logging [v2] In-Reply-To: References: <5lZuUwWVD5NwXo_gUOnUDUD4tdYUvils5Cx5X5r8elo=.5d1f1074-730a-4f88-ba67-67977ffe58d0@github.com> <37Cm5ItlFJ8nzQW_HI6-oyO_TuTK3f09BqiZ2-0l-iE=.fdde37ed-aa6b-4c28-bc30-0403542a518b@github.com> <0qKPSmxPH02xshv9gpcarh-LIc6xiZnlYVCDrRPtCP0=.94eaa31a-501b-4d48-ade0-ae1abf6acddf@github.com> <38hXykjHJTEhOD0CAggi-VnbcQra-I9Js8BWeM86s88=.ef06f49b-ab26-4b3a-827e-da79ba242302@github.com> Message-ID: On Sat, 3 Apr 2021 01:27:10 GMT, Xin Liu wrote: >> Hi Xin, regrading the VM thread blocking on logs. >> >> If you instead use two arrays, one active and one for flushing, you can swap them with atomic stores from the flushing thread. >> And use GlobalCounter::write_synchronize(); to make sure no writer is still using the swapped out array for logging. >> >> The logging thread would use GlobalCounter::critical_section_begin(), atomic inc position to get the spot in the array for the log, store the log and then GlobalCounter::critical_section_end(). >> >> That way you will never block a logging thread with the flushing and run enqueues in parallel. >> >> If you want really want smooth logging you could also remove the strdup, since it may cause a syscall to "break in" more memory. >> To solve that you could use the arrays as memory instead, and do bump the pointer allocation with an atomic increment to size needed instead of position. >> >> I tested a bit locally generally I don't think there is an issue with blocking the VM thread on flushing. >> So I'm not really that concern about this, but it's always nice to have an algorithm which is constant time instead. (Neither CS begin()/end() or atomic inc can fail or loop on x86) > >> Hi Xin, regrading the VM thread blocking on logs. >> >> If you instead use two arrays, one active and one for flushing, you can swap them with atomic stores from the flushing thread. >> And use GlobalCounter::write_synchronize(); to make sure no writer is still using the swapped out array for logging. >> >> The logging thread would use GlobalCounter::critical_section_begin(), atomic inc position to get the spot in the array for the log, store the log and then GlobalCounter::critical_section_end(). >> >> That way you will never block a logging thread with the flushing and run enqueues in parallel. >> >> If you want really want smooth logging you could also remove the strdup, since it may cause a syscall to "break in" more memory. >> To solve that you could use the arrays as memory instead, and do bump the pointer allocation with an atomic increment to size needed instead of position. >> >> I tested a bit locally generally I don't think there is an issue with blocking the VM thread on flushing. >> So I'm not really that concern about this, but it's always nice to have an algorithm which is constant time instead. (Neither CS begin()/end() or atomic inc can fail or loop on x86) > > hi, Robbin, > > Thanks for your comments. I am new for GlobalCounter. please correct me if I am wrong. > > critical_section_begin/end() reminds me of Linux kernel's rcu_read_lock/unlck(). Traditionally, the best scenario of RCU is many reads and rare writes. it's because concurrent writers still need to use atomic operations or locking mechanism. Unfortunately, all participants of logging are writers. No one is read-only. > > The algorithm you described is appealing. The difficulty is that hotspot GlobalCounter is epoch-based. It's unsafe to swap two buffers until all writers are in quiescent state. One `write_synchronize()` can't guarantee that. Thinking of that log sites are high-frequent and concurrent, you would see multiple version(epoch) in-flight. Further, the most expensive synchronization is atomic_incrementation. You can't eliminate them. > > If we decide to go to a lock-free solution, I think the classic lock-free linkedlist is the best way to do that. I have seen that hotspot recently checks in a lock-free FIFO. TBH, I would rather grumpy customers yell at me about async-logging performance first before jump into lock-free algorithms. Here is why. > 1. it?s easy to implement using a lock. it is easy to be reviewed as well. > 2. log sites should be less contentious. Some are temporally distanced. eg. classloading and gc marking. > 3. aysnc logging is an auxiliary feature. Even the entire logging subsystem is neither critical nor mandatory. > > I know that I serialize all file-based logs using a mutex. In my defense, it's probably unusual to log several files in real life. As Volker pointed out earlier, the cost is effectively same as the existing futex imposed by Unified Logging there[1] if we have only one file output. > > I like the idea of swapping 2 buffers. In our internal jdk8u, I do use this approach. flusher swaps 2 ring buffers after it dump one[2]. For linkedlist deque, [pop_all](https://github.com/openjdk/jdk/pull/3135/files#diff-a1d0f5e0f4539bc398c42f4298959ef2ecdbc62a6611dabcd903198e63f86431R51) is essentially swapping 2 linked lists in O(1) complexity. It still uses a mutex, but it pops up all elements at once. The amortized cost is low. > > I use the following approach to prevent blocked IO from suspending java threads and vmthread. > 1. flushing is done in a NonJavaThread. It means it can ignore safepoints. > 2. release the lock of buffer before it start doing IO. It won't block anybody from enqueuing. > > The main use case would be a synchronous log for everything, but asynchronous log for safepoint and gc. > Recently, I am thinking how to get a consensus of a feature before beat it to death. Look, there's alway room to improve it. I think it's a good idea to focus on the core problem we are solving and sidetrack optimizations for future development. > > [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/logging/logFileStreamOutput.cpp#L123 > [2] https://cr.openjdk.java.net/~xliu/8229517/webrev04/webrev/src/share/vm/utilities/ostream.cpp.udiff.html Hi Xin, >From the algorithm perspective all loggers are readers. We are protecting the buffer pointer which only the flusher writes to. To make sure not one still sees the old buffer after the storing of the swapped in one we need to issue a write synchronize. When the write synchronize finishes we know that the to be flushed buffer is no longer visible. That the readers of this buffer pointer writes into the buffer doesn't matter since they can only write if they can see the buffer. When no reader can see the buffer, they can not write to it either. I do not follow your reasoning on atomic increment. - This change-set have: ` { // critical area MutexLocker ml(&_lock, Mutex::_no_safepoint_check_flag); enqueue_impl(m); }` - A lock free linked list is most often implemented with CAS. Both CAS and above mutex serialization are more expensive atomic inc. If you feel that your current code is battle-proven and you think doing additional enhancements as incremental changes is better, please do so. As I said, I don't have any big concern about either performance nor blocking the the VM thread. ------------- PR: https://git.openjdk.java.net/jdk/pull/3135 From dongbo at openjdk.java.net Tue Apr 6 07:25:57 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Tue, 6 Apr 2021 07:25:57 GMT Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v5] In-Reply-To: References: Message-ID: <0aGgD88Mxj7nICTvKhNtkEYlYlP7TUMG082EgaEHU04=.ba1d4468-5c74-4a06-b8c6-d66c7b0c394d@github.com> > In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding. > Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic idea can be found at http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords. > > Patch passed jtreg tier1-3 tests with linux-aarch64-server-fastdebug build. > Tests in `test/jdk/java/util/Base64/` and `compiler/intrinsics/base64/TestBase64.java` runned specially for the correctness of the implementation. > > There can be illegal characters at the start of the input if the data is MIME encoded. > It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now. > > A JMH micro, Base64Decode.java, is added for performance test. > With different input length (upper-bounded by parameter `maxNumBytes` in the JMH micro), > we witness ~2.5x improvements with long inputs and no regression with short inputs for raw base64 decodeing, minor improvements (~10.95%) for MIME on Kunpeng916. > > The Base64Decode.java JMH micro-benchmark results: > > Benchmark (lineSize) (maxNumBytes) Mode Cnt Score Error Units > > # Kunpeng916, intrinsic > Base64Decode.testBase64Decode 4 1 avgt 5 48.614 ? 0.609 ns/op > Base64Decode.testBase64Decode 4 3 avgt 5 58.199 ? 1.650 ns/op > Base64Decode.testBase64Decode 4 7 avgt 5 69.400 ? 0.931 ns/op > Base64Decode.testBase64Decode 4 32 avgt 5 96.818 ? 1.687 ns/op > Base64Decode.testBase64Decode 4 64 avgt 5 122.856 ? 9.217 ns/op > Base64Decode.testBase64Decode 4 80 avgt 5 130.935 ? 1.667 ns/op > Base64Decode.testBase64Decode 4 96 avgt 5 143.627 ? 1.751 ns/op > Base64Decode.testBase64Decode 4 112 avgt 5 152.311 ? 1.178 ns/op > Base64Decode.testBase64Decode 4 512 avgt 5 342.631 ? 0.584 ns/op > Base64Decode.testBase64Decode 4 1000 avgt 5 573.635 ? 1.050 ns/op > Base64Decode.testBase64Decode 4 20000 avgt 5 9534.136 ? 45.172 ns/op > Base64Decode.testBase64Decode 4 50000 avgt 5 22718.726 ? 192.070 ns/op > Base64Decode.testBase64MIMEDecode 4 1 avgt 10 63.558 ? 0.336 ns/op > Base64Decode.testBase64MIMEDecode 4 3 avgt 10 82.504 ? 0.848 ns/op > Base64Decode.testBase64MIMEDecode 4 7 avgt 10 120.591 ? 0.608 ns/op > Base64Decode.testBase64MIMEDecode 4 32 avgt 10 324.314 ? 6.236 ns/op > Base64Decode.testBase64MIMEDecode 4 64 avgt 10 532.678 ? 4.670 ns/op > Base64Decode.testBase64MIMEDecode 4 80 avgt 10 678.126 ? 4.324 ns/op > Base64Decode.testBase64MIMEDecode 4 96 avgt 10 771.603 ? 6.393 ns/op > Base64Decode.testBase64MIMEDecode 4 112 avgt 10 889.608 ? 0.759 ns/op > Base64Decode.testBase64MIMEDecode 4 512 avgt 10 3663.557 ? 3.422 ns/op > Base64Decode.testBase64MIMEDecode 4 1000 avgt 10 7017.784 ? 9.128 ns/op > Base64Decode.testBase64MIMEDecode 4 20000 avgt 10 128670.660 ? 7951.521 ns/op > Base64Decode.testBase64MIMEDecode 4 50000 avgt 10 317113.667 ? 161.758 ns/op > > # Kunpeng916, default > Base64Decode.testBase64Decode 4 1 avgt 5 48.455 ? 0.571 ns/op > Base64Decode.testBase64Decode 4 3 avgt 5 57.937 ? 0.505 ns/op > Base64Decode.testBase64Decode 4 7 avgt 5 73.823 ? 1.452 ns/op > Base64Decode.testBase64Decode 4 32 avgt 5 106.484 ? 1.243 ns/op > Base64Decode.testBase64Decode 4 64 avgt 5 141.004 ? 1.188 ns/op > Base64Decode.testBase64Decode 4 80 avgt 5 156.284 ? 0.572 ns/op > Base64Decode.testBase64Decode 4 96 avgt 5 174.137 ? 0.177 ns/op > Base64Decode.testBase64Decode 4 112 avgt 5 188.445 ? 0.572 ns/op > Base64Decode.testBase64Decode 4 512 avgt 5 610.847 ? 1.559 ns/op > Base64Decode.testBase64Decode 4 1000 avgt 5 1155.368 ? 0.813 ns/op > Base64Decode.testBase64Decode 4 20000 avgt 5 19751.477 ? 24.669 ns/op > Base64Decode.testBase64Decode 4 50000 avgt 5 50046.586 ? 523.155 ns/op > Base64Decode.testBase64MIMEDecode 4 1 avgt 10 64.130 ? 0.238 ns/op > Base64Decode.testBase64MIMEDecode 4 3 avgt 10 82.096 ? 0.205 ns/op > Base64Decode.testBase64MIMEDecode 4 7 avgt 10 118.849 ? 0.610 ns/op > Base64Decode.testBase64MIMEDecode 4 32 avgt 10 331.177 ? 4.732 ns/op > Base64Decode.testBase64MIMEDecode 4 64 avgt 10 549.117 ? 0.177 ns/op > Base64Decode.testBase64MIMEDecode 4 80 avgt 10 702.951 ? 4.572 ns/op > Base64Decode.testBase64MIMEDecode 4 96 avgt 10 799.566 ? 0.301 ns/op > Base64Decode.testBase64MIMEDecode 4 112 avgt 10 923.749 ? 0.389 ns/op > Base64Decode.testBase64MIMEDecode 4 512 avgt 10 4000.725 ? 2.519 ns/op > Base64Decode.testBase64MIMEDecode 4 1000 avgt 10 7674.994 ? 9.281 ns/op > Base64Decode.testBase64MIMEDecode 4 20000 avgt 10 142059.001 ? 157.920 ns/op > Base64Decode.testBase64MIMEDecode 4 50000 avgt 10 355698.369 ? 216.542 ns/op Dong Bo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: - conflicts resolved - Merge branch 'master' of https://git.openjdk.java.net/jdk into aarch64.base64.decode - resovling conflicts - load data with one ldrw, add JMH tests for error inputs - Merge branch 'master' into aarch64.base64.decode - copyright - trivial fixes - Handling error in SIMD case with loops, combining two non-SIMD cases into one code blob, addressing other comments - Merge branch 'master' into aarch64.base64.decode - 8256245: AArch64: Implement Base64 decoding intrinsic ------------- Changes: https://git.openjdk.java.net/jdk/pull/3228/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3228&range=04 Stats: 438 lines in 3 files changed: 438 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3228.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3228/head:pull/3228 PR: https://git.openjdk.java.net/jdk/pull/3228 From ayang at openjdk.java.net Tue Apr 6 08:00:55 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Tue, 6 Apr 2021 08:00:55 GMT Subject: RFR: 8249528: Remove obsolete comment in G1RootProcessor::process_java_roots Message-ID: <8XcBRc2-cEW3wZnNA67FoG8WEZATeNuT9uk2-MiGicg=.dec0b7c8-d3a2-4f5a-9f9e-870ede4d88e0@github.com> Updating the obsolete comment and some trivial change of removing dead code in related files. ------------- Commit messages: - root Changes: https://git.openjdk.java.net/jdk/pull/3352/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3352&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8249528 Stats: 42 lines in 5 files changed: 19 ins; 13 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/3352.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3352/head:pull/3352 PR: https://git.openjdk.java.net/jdk/pull/3352 From dongbo at openjdk.java.net Tue Apr 6 08:04:12 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Tue, 6 Apr 2021 08:04:12 GMT Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic In-Reply-To: References: <_ZrhnM9OyXLckhtT27laLzWPZbCFZTPjm6ePbZdbyOs=.fcc6aaba-1578-443a-aa57-8141a99231f6@github.com> Message-ID: On Fri, 2 Apr 2021 10:17:57 GMT, Andrew Haley wrote: >> PING... Any suggestions on the updated commit? > >> PING... Any suggestions on the updated commit? > > Once you reply to the comments, sure. > > Are there any existing test cases for failing inputs? > I added one, the error character is injected at the paramized index of the encoded data. There are no big differences for small error injected index, seems too much time is took by exception handing. Witnessed ~2x performance improvements as expected. The JMH tests: ### Kunpeng 916, intrinsic?tested with `-jar benchmarks.jar testBase64WithErrorInputsDecode -p errorIndex=3,64,144,208,272,1000,20000 -p maxNumBytes=1` Base64Decode.testBase64WithErrorInputsDecode 3 4 1 avgt 10 3696.151 ? 202.783 ns/op Base64Decode.testBase64WithErrorInputsDecode 64 4 1 avgt 10 3899.269 ? 178.289 ns/op Base64Decode.testBase64WithErrorInputsDecode 144 4 1 avgt 10 3902.022 ? 163.611 ns/op Base64Decode.testBase64WithErrorInputsDecode 208 4 1 avgt 10 3982.423 ? 256.638 ns/op Base64Decode.testBase64WithErrorInputsDecode 272 4 1 avgt 10 3984.545 ? 144.282 ns/op Base64Decode.testBase64WithErrorInputsDecode 1000 4 1 avgt 10 4532.959 ? 310.068 ns/op Base64Decode.testBase64WithErrorInputsDecode 20000 4 1 avgt 10 17578.148 ? 631.600 ns/op ### Kunpeng 916, default?tested with `-XX:-UseBASE64Intrinsics -jar benchmarks.jar testBase64WithErrorInputsDecode -p errorIndex=3,64,144,208,272,1000,20000 -p maxNumBytes=1` Base64Decode.testBase64WithErrorInputsDecode 3 4 1 avgt 10 3760.330 ? 261.672 ns/op Base64Decode.testBase64WithErrorInputsDecode 64 4 1 avgt 10 3900.326 ? 121.632 ns/op Base64Decode.testBase64WithErrorInputsDecode 144 4 1 avgt 10 4041.428 ? 174.435 ns/op Base64Decode.testBase64WithErrorInputsDecode 208 4 1 avgt 10 4177.670 ? 214.433 ns/op Base64Decode.testBase64WithErrorInputsDecode 272 4 1 avgt 10 4324.020 ? 106.826 ns/op Base64Decode.testBase64WithErrorInputsDecode 1000 4 1 avgt 10 5476.469 ? 171.647 ns/op Base64Decode.testBase64WithErrorInputsDecode 20000 4 1 avgt 10 34163.743 ? 162.263 ns/op > > Your test results suggest that it isn't useful for that, surely? > The results suggest non-SIMD code provides ~11.9% improvements for MIME decoding. Furthermore, according to local tests, we may have about ~30% performance regression for MIME decoding without non-SIMD code. In worst case, a MIME line has only 4 base64 encoded characters and a newline string consisted of error inputs, e.g. `\r\n`. When the instrinsic encounter an illegal character (`\r`), it has to exit. Then the Java code will pass the next illegal source byte (`\n`) to the intrinsic. With only SIMD code, it will execute too much wasty instructions before it can detect the error. Whie with non-SIMD code, the instrinsic will execute only one non-SIMD round for this error input. > > For loads and four post increments rather than one load and a few BFMs? Why? > Nice suggestion. Done, thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/3228 From tschatzl at openjdk.java.net Tue Apr 6 09:33:20 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Tue, 6 Apr 2021 09:33:20 GMT Subject: RFR: 8249528: Remove obsolete comment in G1RootProcessor::process_java_roots In-Reply-To: <8XcBRc2-cEW3wZnNA67FoG8WEZATeNuT9uk2-MiGicg=.dec0b7c8-d3a2-4f5a-9f9e-870ede4d88e0@github.com> References: <8XcBRc2-cEW3wZnNA67FoG8WEZATeNuT9uk2-MiGicg=.dec0b7c8-d3a2-4f5a-9f9e-870ede4d88e0@github.com> Message-ID: <50JgoPj04EG7Kyv9cxCKT7RP7TeWzgoqSOhUGmSvi48=.4c684b0f-5ec2-4042-b853-a815e39cc3a6@github.com> On Tue, 6 Apr 2021 07:55:04 GMT, Albert Mingkun Yang wrote: > Updating the obsolete comment and some trivial change of removing dead code in related files. Lgtm. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3352 From aph at openjdk.java.net Tue Apr 6 09:47:31 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Tue, 6 Apr 2021 09:47:31 GMT Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic In-Reply-To: References: Message-ID: <2JT6v2dKf3XicURmOEsdociN7j0SgmVwYdQMr8PaU-c=.9963e17e-44de-4576-9726-c1b15bd7f4e7@github.com> On Sat, 27 Mar 2021 08:58:03 GMT, Dong Bo wrote: > There can be illegal characters at the start of the input if the data is MIME encoded. > It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now. What is the reasoning here? Sure, there can be illegal characters at the start, but what if there are not? The generic logic uses decodeBlock() even in the MIME case, because we don't know that there certainly will be illegal characters. ------------- PR: https://git.openjdk.java.net/jdk/pull/3228 From dongbo at openjdk.java.net Tue Apr 6 11:19:36 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Tue, 6 Apr 2021 11:19:36 GMT Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic In-Reply-To: <2JT6v2dKf3XicURmOEsdociN7j0SgmVwYdQMr8PaU-c=.9963e17e-44de-4576-9726-c1b15bd7f4e7@github.com> References: <2JT6v2dKf3XicURmOEsdociN7j0SgmVwYdQMr8PaU-c=.9963e17e-44de-4576-9726-c1b15bd7f4e7@github.com> Message-ID: On Tue, 6 Apr 2021 09:44:28 GMT, Andrew Haley wrote: > > It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now. > > What is the reasoning here? Sure, there can be illegal characters at the start, but what if there are not? The generic logic uses decodeBlock() even in the MIME case, because we don't know that there certainly will be illegal characters. This code block only process 80B of the inputs. If no illegal characters were found, the stub will use the SIMD instructions to process the rest of the inputs if the data length is large enough, i.e. >= 64B, to form up at least one SIMD round. ------------- PR: https://git.openjdk.java.net/jdk/pull/3228 From aph at openjdk.java.net Tue Apr 6 14:07:26 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Tue, 6 Apr 2021 14:07:26 GMT Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v5] In-Reply-To: <0aGgD88Mxj7nICTvKhNtkEYlYlP7TUMG082EgaEHU04=.ba1d4468-5c74-4a06-b8c6-d66c7b0c394d@github.com> References: <0aGgD88Mxj7nICTvKhNtkEYlYlP7TUMG082EgaEHU04=.ba1d4468-5c74-4a06-b8c6-d66c7b0c394d@github.com> Message-ID: On Tue, 6 Apr 2021 07:25:57 GMT, Dong Bo wrote: >> In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding. >> Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic idea can be found at http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords. >> >> Patch passed jtreg tier1-3 tests with linux-aarch64-server-fastdebug build. >> Tests in `test/jdk/java/util/Base64/` and `compiler/intrinsics/base64/TestBase64.java` runned specially for the correctness of the implementation. >> >> There can be illegal characters at the start of the input if the data is MIME encoded. >> It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now. >> >> A JMH micro, Base64Decode.java, is added for performance test. >> With different input length (upper-bounded by parameter `maxNumBytes` in the JMH micro), >> we witness ~2.5x improvements with long inputs and no regression with short inputs for raw base64 decodeing, minor improvements (~10.95%) for MIME on Kunpeng916. >> >> The Base64Decode.java JMH micro-benchmark results: >> >> Benchmark (lineSize) (maxNumBytes) Mode Cnt Score Error Units >> >> # Kunpeng916, intrinsic >> Base64Decode.testBase64Decode 4 1 avgt 5 48.614 ? 0.609 ns/op >> Base64Decode.testBase64Decode 4 3 avgt 5 58.199 ? 1.650 ns/op >> Base64Decode.testBase64Decode 4 7 avgt 5 69.400 ? 0.931 ns/op >> Base64Decode.testBase64Decode 4 32 avgt 5 96.818 ? 1.687 ns/op >> Base64Decode.testBase64Decode 4 64 avgt 5 122.856 ? 9.217 ns/op >> Base64Decode.testBase64Decode 4 80 avgt 5 130.935 ? 1.667 ns/op >> Base64Decode.testBase64Decode 4 96 avgt 5 143.627 ? 1.751 ns/op >> Base64Decode.testBase64Decode 4 112 avgt 5 152.311 ? 1.178 ns/op >> Base64Decode.testBase64Decode 4 512 avgt 5 342.631 ? 0.584 ns/op >> Base64Decode.testBase64Decode 4 1000 avgt 5 573.635 ? 1.050 ns/op >> Base64Decode.testBase64Decode 4 20000 avgt 5 9534.136 ? 45.172 ns/op >> Base64Decode.testBase64Decode 4 50000 avgt 5 22718.726 ? 192.070 ns/op >> Base64Decode.testBase64MIMEDecode 4 1 avgt 10 63.558 ? 0.336 ns/op >> Base64Decode.testBase64MIMEDecode 4 3 avgt 10 82.504 ? 0.848 ns/op >> Base64Decode.testBase64MIMEDecode 4 7 avgt 10 120.591 ? 0.608 ns/op >> Base64Decode.testBase64MIMEDecode 4 32 avgt 10 324.314 ? 6.236 ns/op >> Base64Decode.testBase64MIMEDecode 4 64 avgt 10 532.678 ? 4.670 ns/op >> Base64Decode.testBase64MIMEDecode 4 80 avgt 10 678.126 ? 4.324 ns/op >> Base64Decode.testBase64MIMEDecode 4 96 avgt 10 771.603 ? 6.393 ns/op >> Base64Decode.testBase64MIMEDecode 4 112 avgt 10 889.608 ? 0.759 ns/op >> Base64Decode.testBase64MIMEDecode 4 512 avgt 10 3663.557 ? 3.422 ns/op >> Base64Decode.testBase64MIMEDecode 4 1000 avgt 10 7017.784 ? 9.128 ns/op >> Base64Decode.testBase64MIMEDecode 4 20000 avgt 10 128670.660 ? 7951.521 ns/op >> Base64Decode.testBase64MIMEDecode 4 50000 avgt 10 317113.667 ? 161.758 ns/op >> >> # Kunpeng916, default >> Base64Decode.testBase64Decode 4 1 avgt 5 48.455 ? 0.571 ns/op >> Base64Decode.testBase64Decode 4 3 avgt 5 57.937 ? 0.505 ns/op >> Base64Decode.testBase64Decode 4 7 avgt 5 73.823 ? 1.452 ns/op >> Base64Decode.testBase64Decode 4 32 avgt 5 106.484 ? 1.243 ns/op >> Base64Decode.testBase64Decode 4 64 avgt 5 141.004 ? 1.188 ns/op >> Base64Decode.testBase64Decode 4 80 avgt 5 156.284 ? 0.572 ns/op >> Base64Decode.testBase64Decode 4 96 avgt 5 174.137 ? 0.177 ns/op >> Base64Decode.testBase64Decode 4 112 avgt 5 188.445 ? 0.572 ns/op >> Base64Decode.testBase64Decode 4 512 avgt 5 610.847 ? 1.559 ns/op >> Base64Decode.testBase64Decode 4 1000 avgt 5 1155.368 ? 0.813 ns/op >> Base64Decode.testBase64Decode 4 20000 avgt 5 19751.477 ? 24.669 ns/op >> Base64Decode.testBase64Decode 4 50000 avgt 5 50046.586 ? 523.155 ns/op >> Base64Decode.testBase64MIMEDecode 4 1 avgt 10 64.130 ? 0.238 ns/op >> Base64Decode.testBase64MIMEDecode 4 3 avgt 10 82.096 ? 0.205 ns/op >> Base64Decode.testBase64MIMEDecode 4 7 avgt 10 118.849 ? 0.610 ns/op >> Base64Decode.testBase64MIMEDecode 4 32 avgt 10 331.177 ? 4.732 ns/op >> Base64Decode.testBase64MIMEDecode 4 64 avgt 10 549.117 ? 0.177 ns/op >> Base64Decode.testBase64MIMEDecode 4 80 avgt 10 702.951 ? 4.572 ns/op >> Base64Decode.testBase64MIMEDecode 4 96 avgt 10 799.566 ? 0.301 ns/op >> Base64Decode.testBase64MIMEDecode 4 112 avgt 10 923.749 ? 0.389 ns/op >> Base64Decode.testBase64MIMEDecode 4 512 avgt 10 4000.725 ? 2.519 ns/op >> Base64Decode.testBase64MIMEDecode 4 1000 avgt 10 7674.994 ? 9.281 ns/op >> Base64Decode.testBase64MIMEDecode 4 20000 avgt 10 142059.001 ? 157.920 ns/op >> Base64Decode.testBase64MIMEDecode 4 50000 avgt 10 355698.369 ? 216.542 ns/op > > Dong Bo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: > > - conflicts resolved > - Merge branch 'master' of https://git.openjdk.java.net/jdk into aarch64.base64.decode > - resovling conflicts > - load data with one ldrw, add JMH tests for error inputs > - Merge branch 'master' into aarch64.base64.decode > - copyright > - trivial fixes > - Handling error in SIMD case with loops, combining two non-SIMD cases into one code blob, addressing other comments > - Merge branch 'master' into aarch64.base64.decode > - 8256245: AArch64: Implement Base64 decoding intrinsic src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5800: > 5798: __ br(Assembler::LT, Process4B); > 5799: > 5800: // The 1st character of the input can be illegal if the data is MIME encoded. Why is this sentence here? It is very misleading. ------------- PR: https://git.openjdk.java.net/jdk/pull/3228 From aph at openjdk.java.net Tue Apr 6 14:07:28 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Tue, 6 Apr 2021 14:07:28 GMT Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v3] In-Reply-To: References: <96N9BNz7s4JH99-5lQio5uEP8iAa4YEmn9NK-dUyvCQ=.c663f383-f207-45c3-97bf-b5309b624315@github.com> Message-ID: On Fri, 2 Apr 2021 10:01:27 GMT, Andrew Haley wrote: >> Dong Bo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: >> >> - Merge branch 'master' into aarch64.base64.decode >> - copyright >> - trivial fixes >> - Handling error in SIMD case with loops, combining two non-SIMD cases into one code blob, addressing other comments >> - Merge branch 'master' into aarch64.base64.decode >> - 8256245: AArch64: Implement Base64 decoding intrinsic > > src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5802: > >> 5800: // The 1st character of the input can be illegal if the data is MIME encoded. >> 5801: // We cannot benefits from SIMD for this case. The max line size of MIME >> 5802: // encoding is 76, with the PreProcess80B blob, we actually use no-simd > > "cannot benefit" OK, so I now understand what is actually going on here, and it has nothing to do with illegal first characters. The problem is that the maximum block length the decode will be supplied with is 76 bytes, and there isn't enough time for the SIMD to be worthwhile. So the comment should be "In the MIME case, the line length cannot be more than 76 bytes (see RFC 2045.) This is too short a block for SIMD to be worthwhile, so we use non-SIMD here." ------------- PR: https://git.openjdk.java.net/jdk/pull/3228 From coleenp at openjdk.java.net Tue Apr 6 14:58:34 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 6 Apr 2021 14:58:34 GMT Subject: RFR: 8264644: Add PrintClassLoaderDataGraphAtExit to print the detailed CLD graph [v3] In-Reply-To: References: Message-ID: On Tue, 6 Apr 2021 06:38:53 GMT, Yi Yang wrote: >> Trivial chanage to make debugging happy, now cld->print() would be: >> >> ClassLoaderData(0x00007ff17432b670) >> - name 'platform' >> - holder WeakHandle: 0x00000007fef56678 >> - class loader 0x7ff17432b828 >> - metaspace 0x7ff17468a0b0 >> - unloading false >> - class mirror holder false >> - modified oops true >> - keep alive 0 >> - claim strong >> - handles 43 >> - dependency count 0 >> - klasses {java.sql.SQLFeatureNotSupportedException,java.sql.SQLNonTransientException,java.sql.SQLException,sun.util.resources.provider.NonBaseLocaleDataMetaInfo,org.ietf.jgss.GSSException,javax.sql.DataSource,java.sql.Wrapper,javax.sql.CommonDataSource,java.sql.Time,java.sql.Date,java.sql.Timestamp,sun.util.resources.cldr.provider.CLDRLocaleDataMetaInfo, } >> - packages 0x7ff17432bc20 >> - module 0x7ff17432c520 >> - unnamed module 0x7ff17432c3d0 >> - dictionary 0x7ff17432c470 >> - deallocate list 0x7ff0a4023bd0 > > Yi Yang has updated the pull request incrementally with two additional commits since the last revision: > > - add CLDG_lock > - use PTR_FORMAT Marked as reviewed by coleenp (Reviewer). src/hotspot/share/classfile/classLoaderData.cpp line 978: > 976: if (_jmethod_ids != NULL) { > 977: out->print (" - jmethod count "); > 978: Method::print_jmethod_ids_counts(this, out); Yes, this is good. It was interesting at one point (to me) how many jmethodIds were in each CLD. ------------- PR: https://git.openjdk.java.net/jdk/pull/3323 From iklam at openjdk.java.net Tue Apr 6 15:54:44 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 6 Apr 2021 15:54:44 GMT Subject: RFR: 8264748: Do not include arguments.hpp from compilerDefinitions.hpp Message-ID: compilerDefinitions.hpp is a popular header, included by 588 of about 1000 HotSpot .o files. It includes arguments.hpp only for a single function that's not used in critical paths. After refactoring, the number of .o files that includes arguments.hpp reduces from 623 to 68. (I also removed arguments.hpp from other files that don't actually need it.) ------------- Commit messages: - 8264748: Do not include arguments.hpp from compilerDefinitions.hpp Changes: https://git.openjdk.java.net/jdk/pull/3351/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3351&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264748 Stats: 59 lines in 41 files changed: 16 ins; 33 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/3351.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3351/head:pull/3351 PR: https://git.openjdk.java.net/jdk/pull/3351 From gziemski at openjdk.java.net Tue Apr 6 19:08:29 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Tue, 6 Apr 2021 19:08:29 GMT Subject: RFR: 8264748: Do not include arguments.hpp from compilerDefinitions.hpp In-Reply-To: References: Message-ID: <4ZB90qjNLJqkNUk2KlNEm7wJC-e7sd6xoGWB3o8oTs0=.53d08a52-2bc9-4d5f-b8d8-0d57196fee18@github.com> On Tue, 6 Apr 2021 07:27:36 GMT, Ioi Lam wrote: > compilerDefinitions.hpp is a popular header, included by 588 of about 1000 HotSpot .o files. It includes arguments.hpp only for a single function that's not used in critical paths. > > After refactoring, the number of .o files that includes arguments.hpp reduces from 623 to 68. > > (I also removed arguments.hpp from other files that don't actually need it.) Nice! How do you figure out where to remove the unneeded header and/or what to replace it with? Do you use some tool to help you out with this? ------------- Marked as reviewed by gziemski (Committer). PR: https://git.openjdk.java.net/jdk/pull/3351 From coleenp at openjdk.java.net Tue Apr 6 19:10:49 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 6 Apr 2021 19:10:49 GMT Subject: RFR: 8259242: vmTestbase/vm/mlvm/mixed/stress/java/findDeadlock/TestDescription.java timed out Message-ID: This change makes the DictionaryEntry pd_set lock free, because when I set a low SafepointTimeout on the findDeadlock test, these threads were waiting on the ProtectionDomainSet_lock. This lock is a singleton that's taken for every dictionary entry. I don't know if this change will make the test never timeout again, because removing this lock caused us to hit a low SafepointTimeout on another _no_safepoint_check lock that is not so easy to eradictate. Tested with tiers 1-3. There's a test that exercises this code in runtime/Dictionary/ProtectionDomainCacheTest.java. ------------- Commit messages: - 8259242: vmTestbase/vm/mlvm/mixed/stress/java/findDeadlock/TestDescription.java timed out Changes: https://git.openjdk.java.net/jdk/pull/3362/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3362&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259242 Stats: 121 lines in 9 files changed: 61 ins; 34 del; 26 mod Patch: https://git.openjdk.java.net/jdk/pull/3362.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3362/head:pull/3362 PR: https://git.openjdk.java.net/jdk/pull/3362 From iklam at openjdk.java.net Tue Apr 6 19:39:18 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 6 Apr 2021 19:39:18 GMT Subject: RFR: 8264748: Do not include arguments.hpp from compilerDefinitions.hpp In-Reply-To: <4ZB90qjNLJqkNUk2KlNEm7wJC-e7sd6xoGWB3o8oTs0=.53d08a52-2bc9-4d5f-b8d8-0d57196fee18@github.com> References: <4ZB90qjNLJqkNUk2KlNEm7wJC-e7sd6xoGWB3o8oTs0=.53d08a52-2bc9-4d5f-b8d8-0d57196fee18@github.com> Message-ID: On Tue, 6 Apr 2021 19:04:57 GMT, Gerard Ziemski wrote: > Nice! > > How do you figure out where to remove the unneeded header and/or what to replace it with? > > Do you use some tool to help you out with this? Hi Gerard, thanks for the review. The tools I used are here: https://github.com/iklam/tools/tree/main/headers ------------- PR: https://git.openjdk.java.net/jdk/pull/3351 From stefank at openjdk.java.net Tue Apr 6 19:57:17 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Tue, 6 Apr 2021 19:57:17 GMT Subject: RFR: 8264748: Do not include arguments.hpp from compilerDefinitions.hpp In-Reply-To: References: Message-ID: <0pYJXDOFv-FZa1NQug9msnWorBiyg9aa8x6bd6Kn3uo=.648fd161-a5ee-41c1-925e-6bd431275ea8@github.com> On Tue, 6 Apr 2021 07:27:36 GMT, Ioi Lam wrote: > compilerDefinitions.hpp is a popular header, included by 588 of about 1000 HotSpot .o files. It includes arguments.hpp only for a single function that's not used in critical paths. > > After refactoring, the number of .o files that includes arguments.hpp reduces from 623 to 68. > > (I also removed arguments.hpp from other files that don't actually need it.) Marked as reviewed by stefank (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3351 From dholmes at openjdk.java.net Wed Apr 7 04:58:39 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 7 Apr 2021 04:58:39 GMT Subject: RFR: 8259242: vmTestbase/vm/mlvm/mixed/stress/java/findDeadlock/TestDescription.java timed out In-Reply-To: References: Message-ID: <88mUXjYGWsrhiXxlkanE11_g8d6A0eppyxwOCyrCZ5Y=.93e091b7-8739-4934-acc1-57d5cd133455@github.com> On Tue, 6 Apr 2021 18:54:09 GMT, Coleen Phillimore wrote: > This change makes the DictionaryEntry pd_set lock free, because when I set a low SafepointTimeout on the findDeadlock test, these threads were waiting on the ProtectionDomainSet_lock. This lock is a singleton that's taken for every dictionary entry. > > I don't know if this change will make the test never timeout again, because removing this lock caused us to hit a low SafepointTimeout on another _no_safepoint_check lock that is not so easy to eradictate. > > Tested with tiers 1-3. There's a test that exercises this code in runtime/Dictionary/ProtectionDomainCacheTest.java. Hi Coleen, Can you explain the synchronization protocol you are using here please - I don't understand how the handshake fits into it ?? Further comments below. Thanks, David src/hotspot/share/classfile/dictionary.cpp line 422: > 420: void Dictionary::clean_cached_protection_domains(GrowableArray* delete_list) { > 421: assert(Thread::current()->is_Java_thread(), "only called by JavaThread"); > 422: assert_locked_or_safepoint(SystemDictionary_lock); If the current thread must be a JavaThread then we cannot be at a safepoint and so the second assert can just check the lock is held. src/hotspot/share/classfile/dictionary.hpp line 145: > 143: > 144: ProtectionDomainEntry* pd_set() const { return Atomic::load(&_pd_set); } > 145: void set_pd_set(ProtectionDomainEntry* entry) { Atomic::store(&_pd_set, entry); } These probably need to be load_acquire and release_store, so that a lock-free traversal can proceed correctly with a locked addition/removal. With suitable name changes for the methods. src/hotspot/share/classfile/protectionDomainCache.cpp line 89: > 87: // If there are any deleted entries, Handshake-all then they'll be > 88: // safe to remove since traversing the pd_set list does not stop for > 89: // safepoints and only JavaThreads will read the pd_set. I do not understand what you are trying to do here. This is basically a no-op handshake with every thread? Does all the threads remain in the handshake until the last one is processed or do they proceed through one at a time? The former seems better suited for a safepoint operation. The latter means this doesn't work as they may have moved on to a new removal. src/hotspot/share/classfile/protectionDomainCache.hpp line 115: > 113: > 114: ProtectionDomainEntry* next() { return Atomic::load(&_next); } > 115: void set_next(ProtectionDomainEntry* entry) { Atomic::store(&_next, entry); } Again these may need to be load_acquire/release_store for correct lock-free traversal. With suitable name changes for the methods. ------------- PR: https://git.openjdk.java.net/jdk/pull/3362 From dholmes at openjdk.java.net Wed Apr 7 05:13:36 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 7 Apr 2021 05:13:36 GMT Subject: RFR: 8264644: Add PrintClassLoaderDataGraphAtExit to print the detailed CLD graph [v3] In-Reply-To: References: Message-ID: On Tue, 6 Apr 2021 06:38:53 GMT, Yi Yang wrote: >> Trivial chanage to make debugging happy, now cld->print() would be: >> >> ClassLoaderData(0x00007ff17432b670) >> - name 'platform' >> - holder WeakHandle: 0x00000007fef56678 >> - class loader 0x7ff17432b828 >> - metaspace 0x7ff17468a0b0 >> - unloading false >> - class mirror holder false >> - modified oops true >> - keep alive 0 >> - claim strong >> - handles 43 >> - dependency count 0 >> - klasses {java.sql.SQLFeatureNotSupportedException,java.sql.SQLNonTransientException,java.sql.SQLException,sun.util.resources.provider.NonBaseLocaleDataMetaInfo,org.ietf.jgss.GSSException,javax.sql.DataSource,java.sql.Wrapper,javax.sql.CommonDataSource,java.sql.Time,java.sql.Date,java.sql.Timestamp,sun.util.resources.cldr.provider.CLDRLocaleDataMetaInfo, } >> - packages 0x7ff17432bc20 >> - module 0x7ff17432c520 >> - unnamed module 0x7ff17432c3d0 >> - dictionary 0x7ff17432c470 >> - deallocate list 0x7ff0a4023bd0 > > Yi Yang has updated the pull request incrementally with two additional commits since the last revision: > > - add CLDG_lock > - use PTR_FORMAT A couple of minor nits. Thanks, David src/hotspot/share/classfile/classLoaderData.cpp line 952: > 950: out->print_cr(""); > 951: } > 952: out->print_cr(" - class loader " PTR_FORMAT, p2i(_class_loader.ptr_raw())); I'm surprised the p2i's were added. If the values are pointers then p2i should not be needed. If using p2i then INTPTR_FORMAT is the correct format specifier to use. ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3323 From dholmes at openjdk.java.net Wed Apr 7 05:13:37 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 7 Apr 2021 05:13:37 GMT Subject: RFR: 8264644: Add PrintClassLoaderDataGraphAtExit to print the detailed CLD graph [v3] In-Reply-To: References: Message-ID: On Tue, 6 Apr 2021 14:54:58 GMT, Coleen Phillimore wrote: >> Yi Yang has updated the pull request incrementally with two additional commits since the last revision: >> >> - add CLDG_lock >> - use PTR_FORMAT > > src/hotspot/share/classfile/classLoaderData.cpp line 978: > >> 976: if (_jmethod_ids != NULL) { >> 977: out->print (" - jmethod count "); >> 978: Method::print_jmethod_ids_counts(this, out); > > Yes, this is good. It was interesting at one point (to me) how many jmethodIds were in each CLD. Okay by me too. But it should be count not counts. ------------- PR: https://git.openjdk.java.net/jdk/pull/3323 From yyang at openjdk.java.net Wed Apr 7 05:30:30 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Wed, 7 Apr 2021 05:30:30 GMT Subject: RFR: 8264644: Add PrintClassLoaderDataGraphAtExit to print the detailed CLD graph [v3] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 05:07:54 GMT, David Holmes wrote: >> Yi Yang has updated the pull request incrementally with two additional commits since the last revision: >> >> - add CLDG_lock >> - use PTR_FORMAT > > src/hotspot/share/classfile/classLoaderData.cpp line 952: > >> 950: out->print_cr(""); >> 951: } >> 952: out->print_cr(" - class loader " PTR_FORMAT, p2i(_class_loader.ptr_raw())); > > I'm surprised the p2i's were added. If the values are pointers then p2i should not be needed. If using p2i then INTPTR_FORMAT is the correct format specifier to use. I'm not sure the original intentions of these two macros. It looks like the definitions of PRT_FORMAT and INTPTR_FORMAT are identical: https://github.com/openjdk/jdk/blob/c3abdc9aadc734053dbcc43d5294d5f16a0b0ce3/src/hotspot/share/utilities/globalDefinitions.hpp#L129-L132 Also I find many occurrences that using p2i while format specifier is PRT_FORMAT. If this is indeed wrong, I may fix them later. ------------- PR: https://git.openjdk.java.net/jdk/pull/3323 From iklam at openjdk.java.net Wed Apr 7 05:41:26 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 7 Apr 2021 05:41:26 GMT Subject: RFR: 8264748: Do not include arguments.hpp from compilerDefinitions.hpp In-Reply-To: <0pYJXDOFv-FZa1NQug9msnWorBiyg9aa8x6bd6Kn3uo=.648fd161-a5ee-41c1-925e-6bd431275ea8@github.com> References: <0pYJXDOFv-FZa1NQug9msnWorBiyg9aa8x6bd6Kn3uo=.648fd161-a5ee-41c1-925e-6bd431275ea8@github.com> Message-ID: On Tue, 6 Apr 2021 19:54:03 GMT, Stefan Karlsson wrote: >> compilerDefinitions.hpp is a popular header, included by 588 of about 1000 HotSpot .o files. It includes arguments.hpp only for a single function that's not used in critical paths. >> >> After refactoring, the number of .o files that includes arguments.hpp reduces from 623 to 68. >> >> (I also removed arguments.hpp from other files that don't actually need it.) > > Marked as reviewed by stefank (Reviewer). Thanks @stefank and @gerard-ziemski for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/3351 From iklam at openjdk.java.net Wed Apr 7 05:41:26 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 7 Apr 2021 05:41:26 GMT Subject: Integrated: 8264748: Do not include arguments.hpp from compilerDefinitions.hpp In-Reply-To: References: Message-ID: On Tue, 6 Apr 2021 07:27:36 GMT, Ioi Lam wrote: > compilerDefinitions.hpp is a popular header, included by 588 of about 1000 HotSpot .o files. It includes arguments.hpp only for a single function that's not used in critical paths. > > After refactoring, the number of .o files that includes arguments.hpp reduces from 623 to 68. > > (I also removed arguments.hpp from other files that don't actually need it.) This pull request has now been integrated. Changeset: 17202c89 Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/17202c89 Stats: 59 lines in 41 files changed: 16 ins; 33 del; 10 mod 8264748: Do not include arguments.hpp from compilerDefinitions.hpp Reviewed-by: gziemski, stefank ------------- PR: https://git.openjdk.java.net/jdk/pull/3351 From dongbo at openjdk.java.net Wed Apr 7 05:51:02 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Wed, 7 Apr 2021 05:51:02 GMT Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v6] In-Reply-To: References: Message-ID: > In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding. > Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic idea can be found at http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords. > > Patch passed jtreg tier1-3 tests with linux-aarch64-server-fastdebug build. > Tests in `test/jdk/java/util/Base64/` and `compiler/intrinsics/base64/TestBase64.java` runned specially for the correctness of the implementation. > > There can be illegal characters at the start of the input if the data is MIME encoded. > It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now. > > A JMH micro, Base64Decode.java, is added for performance test. > With different input length (upper-bounded by parameter `maxNumBytes` in the JMH micro), > we witness ~2.5x improvements with long inputs and no regression with short inputs for raw base64 decodeing, minor improvements (~10.95%) for MIME on Kunpeng916. > > The Base64Decode.java JMH micro-benchmark results: > > Benchmark (lineSize) (maxNumBytes) Mode Cnt Score Error Units > > # Kunpeng916, intrinsic > Base64Decode.testBase64Decode 4 1 avgt 5 48.614 ? 0.609 ns/op > Base64Decode.testBase64Decode 4 3 avgt 5 58.199 ? 1.650 ns/op > Base64Decode.testBase64Decode 4 7 avgt 5 69.400 ? 0.931 ns/op > Base64Decode.testBase64Decode 4 32 avgt 5 96.818 ? 1.687 ns/op > Base64Decode.testBase64Decode 4 64 avgt 5 122.856 ? 9.217 ns/op > Base64Decode.testBase64Decode 4 80 avgt 5 130.935 ? 1.667 ns/op > Base64Decode.testBase64Decode 4 96 avgt 5 143.627 ? 1.751 ns/op > Base64Decode.testBase64Decode 4 112 avgt 5 152.311 ? 1.178 ns/op > Base64Decode.testBase64Decode 4 512 avgt 5 342.631 ? 0.584 ns/op > Base64Decode.testBase64Decode 4 1000 avgt 5 573.635 ? 1.050 ns/op > Base64Decode.testBase64Decode 4 20000 avgt 5 9534.136 ? 45.172 ns/op > Base64Decode.testBase64Decode 4 50000 avgt 5 22718.726 ? 192.070 ns/op > Base64Decode.testBase64MIMEDecode 4 1 avgt 10 63.558 ? 0.336 ns/op > Base64Decode.testBase64MIMEDecode 4 3 avgt 10 82.504 ? 0.848 ns/op > Base64Decode.testBase64MIMEDecode 4 7 avgt 10 120.591 ? 0.608 ns/op > Base64Decode.testBase64MIMEDecode 4 32 avgt 10 324.314 ? 6.236 ns/op > Base64Decode.testBase64MIMEDecode 4 64 avgt 10 532.678 ? 4.670 ns/op > Base64Decode.testBase64MIMEDecode 4 80 avgt 10 678.126 ? 4.324 ns/op > Base64Decode.testBase64MIMEDecode 4 96 avgt 10 771.603 ? 6.393 ns/op > Base64Decode.testBase64MIMEDecode 4 112 avgt 10 889.608 ? 0.759 ns/op > Base64Decode.testBase64MIMEDecode 4 512 avgt 10 3663.557 ? 3.422 ns/op > Base64Decode.testBase64MIMEDecode 4 1000 avgt 10 7017.784 ? 9.128 ns/op > Base64Decode.testBase64MIMEDecode 4 20000 avgt 10 128670.660 ? 7951.521 ns/op > Base64Decode.testBase64MIMEDecode 4 50000 avgt 10 317113.667 ? 161.758 ns/op > > # Kunpeng916, default > Base64Decode.testBase64Decode 4 1 avgt 5 48.455 ? 0.571 ns/op > Base64Decode.testBase64Decode 4 3 avgt 5 57.937 ? 0.505 ns/op > Base64Decode.testBase64Decode 4 7 avgt 5 73.823 ? 1.452 ns/op > Base64Decode.testBase64Decode 4 32 avgt 5 106.484 ? 1.243 ns/op > Base64Decode.testBase64Decode 4 64 avgt 5 141.004 ? 1.188 ns/op > Base64Decode.testBase64Decode 4 80 avgt 5 156.284 ? 0.572 ns/op > Base64Decode.testBase64Decode 4 96 avgt 5 174.137 ? 0.177 ns/op > Base64Decode.testBase64Decode 4 112 avgt 5 188.445 ? 0.572 ns/op > Base64Decode.testBase64Decode 4 512 avgt 5 610.847 ? 1.559 ns/op > Base64Decode.testBase64Decode 4 1000 avgt 5 1155.368 ? 0.813 ns/op > Base64Decode.testBase64Decode 4 20000 avgt 5 19751.477 ? 24.669 ns/op > Base64Decode.testBase64Decode 4 50000 avgt 5 50046.586 ? 523.155 ns/op > Base64Decode.testBase64MIMEDecode 4 1 avgt 10 64.130 ? 0.238 ns/op > Base64Decode.testBase64MIMEDecode 4 3 avgt 10 82.096 ? 0.205 ns/op > Base64Decode.testBase64MIMEDecode 4 7 avgt 10 118.849 ? 0.610 ns/op > Base64Decode.testBase64MIMEDecode 4 32 avgt 10 331.177 ? 4.732 ns/op > Base64Decode.testBase64MIMEDecode 4 64 avgt 10 549.117 ? 0.177 ns/op > Base64Decode.testBase64MIMEDecode 4 80 avgt 10 702.951 ? 4.572 ns/op > Base64Decode.testBase64MIMEDecode 4 96 avgt 10 799.566 ? 0.301 ns/op > Base64Decode.testBase64MIMEDecode 4 112 avgt 10 923.749 ? 0.389 ns/op > Base64Decode.testBase64MIMEDecode 4 512 avgt 10 4000.725 ? 2.519 ns/op > Base64Decode.testBase64MIMEDecode 4 1000 avgt 10 7674.994 ? 9.281 ns/op > Base64Decode.testBase64MIMEDecode 4 20000 avgt 10 142059.001 ? 157.920 ns/op > Base64Decode.testBase64MIMEDecode 4 50000 avgt 10 355698.369 ? 216.542 ns/op Dong Bo has updated the pull request incrementally with one additional commit since the last revision: fix misleading annotations ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3228/files - new: https://git.openjdk.java.net/jdk/pull/3228/files/faa830cf..a342ad1e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3228&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3228&range=04-05 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3228.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3228/head:pull/3228 PR: https://git.openjdk.java.net/jdk/pull/3228 From dongbo at openjdk.java.net Wed Apr 7 06:00:45 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Wed, 7 Apr 2021 06:00:45 GMT Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v5] In-Reply-To: References: <0aGgD88Mxj7nICTvKhNtkEYlYlP7TUMG082EgaEHU04=.ba1d4468-5c74-4a06-b8c6-d66c7b0c394d@github.com> Message-ID: On Tue, 6 Apr 2021 14:04:07 GMT, Andrew Haley wrote: >> Dong Bo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: >> >> - conflicts resolved >> - Merge branch 'master' of https://git.openjdk.java.net/jdk into aarch64.base64.decode >> - resovling conflicts >> - load data with one ldrw, add JMH tests for error inputs >> - Merge branch 'master' into aarch64.base64.decode >> - copyright >> - trivial fixes >> - Handling error in SIMD case with loops, combining two non-SIMD cases into one code blob, addressing other comments >> - Merge branch 'master' into aarch64.base64.decode >> - 8256245: AArch64: Implement Base64 decoding intrinsic > > src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5800: > >> 5798: __ br(Assembler::LT, Process4B); >> 5799: >> 5800: // The 1st character of the input can be illegal if the data is MIME encoded. > > Why is this sentence here? It is very misleading. This sentence was used to describe the worst case observed frequently so that readers can understand more easily why the pre-processing non-SIMD code is necessary. I apologize for being unclear and misleading. The annotations have been modified as suggested. ------------- PR: https://git.openjdk.java.net/jdk/pull/3228 From david.holmes at oracle.com Wed Apr 7 06:04:28 2021 From: david.holmes at oracle.com (David Holmes) Date: Wed, 7 Apr 2021 16:04:28 +1000 Subject: RFR: 8264644: Add PrintClassLoaderDataGraphAtExit to print the detailed CLD graph [v3] In-Reply-To: References: Message-ID: On 7/04/2021 3:30 pm, Yi Yang wrote: > On Wed, 7 Apr 2021 05:07:54 GMT, David Holmes wrote: > >>> Yi Yang has updated the pull request incrementally with two additional commits since the last revision: >>> >>> - add CLDG_lock >>> - use PTR_FORMAT >> >> src/hotspot/share/classfile/classLoaderData.cpp line 952: >> >>> 950: out->print_cr(""); >>> 951: } >>> 952: out->print_cr(" - class loader " PTR_FORMAT, p2i(_class_loader.ptr_raw())); >> >> I'm surprised the p2i's were added. If the values are pointers then p2i should not be needed. If using p2i then INTPTR_FORMAT is the correct format specifier to use. > > I'm not sure the original intentions of these two macros. It looks like the definitions of PRT_FORMAT and INTPTR_FORMAT are identical: > > https://github.com/openjdk/jdk/blob/c3abdc9aadc734053dbcc43d5294d5f16a0b0ce3/src/hotspot/share/utilities/globalDefinitions.hpp#L129-L132 Yes the ultimate definitions are currently identical. The issue is about semantic correctness: if printing a pointer type use PTR_FORMAT; if printing an integer representation of a pointer (as provided by p2i()) then use INTPTR_FORMAT. > Also I find many occurrences that using p2i while format specifier is PRT_FORMAT. If this is indeed wrong, I may fix them later. Yes unfortunately there is a lot of inconsistency here. p2i was introduced with: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/53a41e7cbe05 and it was a very large change. Since then, in parts of runtime at least, we have tried to use them in a consistent way. Thanks, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3323 > From yyang at openjdk.java.net Wed Apr 7 06:48:52 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Wed, 7 Apr 2021 06:48:52 GMT Subject: RFR: 8264644: Add PrintClassLoaderDataGraphAtExit to print the detailed CLD graph [v4] In-Reply-To: References: Message-ID: > Trivial chanage to make debugging happy, now cld->print() would be: > > ClassLoaderData(0x00007ff17432b670) > - name 'platform' > - holder WeakHandle: 0x00000007fef56678 > - class loader 0x7ff17432b828 > - metaspace 0x7ff17468a0b0 > - unloading false > - class mirror holder false > - modified oops true > - keep alive 0 > - claim strong > - handles 43 > - dependency count 0 > - klasses {java.sql.SQLFeatureNotSupportedException,java.sql.SQLNonTransientException,java.sql.SQLException,sun.util.resources.provider.NonBaseLocaleDataMetaInfo,org.ietf.jgss.GSSException,javax.sql.DataSource,java.sql.Wrapper,javax.sql.CommonDataSource,java.sql.Time,java.sql.Date,java.sql.Timestamp,sun.util.resources.cldr.provider.CLDRLocaleDataMetaInfo, } > - packages 0x7ff17432bc20 > - module 0x7ff17432c520 > - unnamed module 0x7ff17432c3d0 > - dictionary 0x7ff17432c470 > - deallocate list 0x7ff0a4023bd0 Yi Yang has updated the pull request incrementally with one additional commit since the last revision: INTPTR_FORMAT ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3323/files - new: https://git.openjdk.java.net/jdk/pull/3323/files/97db359e..1eb6766b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3323&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3323&range=02-03 Stats: 12 lines in 3 files changed: 0 ins; 0 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/3323.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3323/head:pull/3323 PR: https://git.openjdk.java.net/jdk/pull/3323 From yyang at openjdk.java.net Wed Apr 7 06:48:54 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Wed, 7 Apr 2021 06:48:54 GMT Subject: RFR: 8264644: Add PrintClassLoaderDataGraphAtExit to print the detailed CLD graph [v3] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 05:27:41 GMT, Yi Yang wrote: >> src/hotspot/share/classfile/classLoaderData.cpp line 952: >> >>> 950: out->print_cr(""); >>> 951: } >>> 952: out->print_cr(" - class loader " PTR_FORMAT, p2i(_class_loader.ptr_raw())); >> >> I'm surprised the p2i's were added. If the values are pointers then p2i should not be needed. If using p2i then INTPTR_FORMAT is the correct format specifier to use. > > I'm not sure the original intentions of these two macros. It looks like the definitions of PRT_FORMAT and INTPTR_FORMAT are identical: > > https://github.com/openjdk/jdk/blob/c3abdc9aadc734053dbcc43d5294d5f16a0b0ce3/src/hotspot/share/utilities/globalDefinitions.hpp#L129-L132 > > Also I find many occurrences that using p2i while format specifier is PRT_FORMAT. If this is indeed wrong, I may fix them later. Even if a pointer is given, p2i is necessary for PRT_FORMAT and INTPTR_FORMAT specifier, the compiler will throw errors without p2i. ------------- PR: https://git.openjdk.java.net/jdk/pull/3323 From aph at openjdk.java.net Wed Apr 7 09:56:20 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Wed, 7 Apr 2021 09:56:20 GMT Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v6] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 05:51:02 GMT, Dong Bo wrote: >> In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding. >> Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic idea can be found at http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords. >> >> Patch passed jtreg tier1-3 tests with linux-aarch64-server-fastdebug build. >> Tests in `test/jdk/java/util/Base64/` and `compiler/intrinsics/base64/TestBase64.java` runned specially for the correctness of the implementation. >> >> There can be illegal characters at the start of the input if the data is MIME encoded. >> It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now. >> >> A JMH micro, Base64Decode.java, is added for performance test. >> With different input length (upper-bounded by parameter `maxNumBytes` in the JMH micro), >> we witness ~2.5x improvements with long inputs and no regression with short inputs for raw base64 decodeing, minor improvements (~10.95%) for MIME on Kunpeng916. >> >> The Base64Decode.java JMH micro-benchmark results: >> >> Benchmark (lineSize) (maxNumBytes) Mode Cnt Score Error Units >> >> # Kunpeng916, intrinsic >> Base64Decode.testBase64Decode 4 1 avgt 5 48.614 ? 0.609 ns/op >> Base64Decode.testBase64Decode 4 3 avgt 5 58.199 ? 1.650 ns/op >> Base64Decode.testBase64Decode 4 7 avgt 5 69.400 ? 0.931 ns/op >> Base64Decode.testBase64Decode 4 32 avgt 5 96.818 ? 1.687 ns/op >> Base64Decode.testBase64Decode 4 64 avgt 5 122.856 ? 9.217 ns/op >> Base64Decode.testBase64Decode 4 80 avgt 5 130.935 ? 1.667 ns/op >> Base64Decode.testBase64Decode 4 96 avgt 5 143.627 ? 1.751 ns/op >> Base64Decode.testBase64Decode 4 112 avgt 5 152.311 ? 1.178 ns/op >> Base64Decode.testBase64Decode 4 512 avgt 5 342.631 ? 0.584 ns/op >> Base64Decode.testBase64Decode 4 1000 avgt 5 573.635 ? 1.050 ns/op >> Base64Decode.testBase64Decode 4 20000 avgt 5 9534.136 ? 45.172 ns/op >> Base64Decode.testBase64Decode 4 50000 avgt 5 22718.726 ? 192.070 ns/op >> Base64Decode.testBase64MIMEDecode 4 1 avgt 10 63.558 ? 0.336 ns/op >> Base64Decode.testBase64MIMEDecode 4 3 avgt 10 82.504 ? 0.848 ns/op >> Base64Decode.testBase64MIMEDecode 4 7 avgt 10 120.591 ? 0.608 ns/op >> Base64Decode.testBase64MIMEDecode 4 32 avgt 10 324.314 ? 6.236 ns/op >> Base64Decode.testBase64MIMEDecode 4 64 avgt 10 532.678 ? 4.670 ns/op >> Base64Decode.testBase64MIMEDecode 4 80 avgt 10 678.126 ? 4.324 ns/op >> Base64Decode.testBase64MIMEDecode 4 96 avgt 10 771.603 ? 6.393 ns/op >> Base64Decode.testBase64MIMEDecode 4 112 avgt 10 889.608 ? 0.759 ns/op >> Base64Decode.testBase64MIMEDecode 4 512 avgt 10 3663.557 ? 3.422 ns/op >> Base64Decode.testBase64MIMEDecode 4 1000 avgt 10 7017.784 ? 9.128 ns/op >> Base64Decode.testBase64MIMEDecode 4 20000 avgt 10 128670.660 ? 7951.521 ns/op >> Base64Decode.testBase64MIMEDecode 4 50000 avgt 10 317113.667 ? 161.758 ns/op >> >> # Kunpeng916, default >> Base64Decode.testBase64Decode 4 1 avgt 5 48.455 ? 0.571 ns/op >> Base64Decode.testBase64Decode 4 3 avgt 5 57.937 ? 0.505 ns/op >> Base64Decode.testBase64Decode 4 7 avgt 5 73.823 ? 1.452 ns/op >> Base64Decode.testBase64Decode 4 32 avgt 5 106.484 ? 1.243 ns/op >> Base64Decode.testBase64Decode 4 64 avgt 5 141.004 ? 1.188 ns/op >> Base64Decode.testBase64Decode 4 80 avgt 5 156.284 ? 0.572 ns/op >> Base64Decode.testBase64Decode 4 96 avgt 5 174.137 ? 0.177 ns/op >> Base64Decode.testBase64Decode 4 112 avgt 5 188.445 ? 0.572 ns/op >> Base64Decode.testBase64Decode 4 512 avgt 5 610.847 ? 1.559 ns/op >> Base64Decode.testBase64Decode 4 1000 avgt 5 1155.368 ? 0.813 ns/op >> Base64Decode.testBase64Decode 4 20000 avgt 5 19751.477 ? 24.669 ns/op >> Base64Decode.testBase64Decode 4 50000 avgt 5 50046.586 ? 523.155 ns/op >> Base64Decode.testBase64MIMEDecode 4 1 avgt 10 64.130 ? 0.238 ns/op >> Base64Decode.testBase64MIMEDecode 4 3 avgt 10 82.096 ? 0.205 ns/op >> Base64Decode.testBase64MIMEDecode 4 7 avgt 10 118.849 ? 0.610 ns/op >> Base64Decode.testBase64MIMEDecode 4 32 avgt 10 331.177 ? 4.732 ns/op >> Base64Decode.testBase64MIMEDecode 4 64 avgt 10 549.117 ? 0.177 ns/op >> Base64Decode.testBase64MIMEDecode 4 80 avgt 10 702.951 ? 4.572 ns/op >> Base64Decode.testBase64MIMEDecode 4 96 avgt 10 799.566 ? 0.301 ns/op >> Base64Decode.testBase64MIMEDecode 4 112 avgt 10 923.749 ? 0.389 ns/op >> Base64Decode.testBase64MIMEDecode 4 512 avgt 10 4000.725 ? 2.519 ns/op >> Base64Decode.testBase64MIMEDecode 4 1000 avgt 10 7674.994 ? 9.281 ns/op >> Base64Decode.testBase64MIMEDecode 4 20000 avgt 10 142059.001 ? 157.920 ns/op >> Base64Decode.testBase64MIMEDecode 4 50000 avgt 10 355698.369 ? 216.542 ns/op > > Dong Bo has updated the pull request incrementally with one additional commit since the last revision: > > fix misleading annotations src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5829: > 5827: __ strb(r14, __ post(dst, 1)); > 5828: __ strb(r15, __ post(dst, 1)); > 5829: __ strb(r13, __ post(dst, 1)); I think this sequence should be 4 BFMs, STRW, BFM, STRW. That's the best we can do, I think. ------------- PR: https://git.openjdk.java.net/jdk/pull/3228 From aph at openjdk.java.net Wed Apr 7 09:56:21 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Wed, 7 Apr 2021 09:56:21 GMT Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v6] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 09:50:45 GMT, Andrew Haley wrote: >> Dong Bo has updated the pull request incrementally with one additional commit since the last revision: >> >> fix misleading annotations > > src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5829: > >> 5827: __ strb(r14, __ post(dst, 1)); >> 5828: __ strb(r15, __ post(dst, 1)); >> 5829: __ strb(r13, __ post(dst, 1)); > > I think this sequence should be 4 BFMs, STRW, BFM, STRW. That's the best we can do, I think. Sorry, that's not quite right, but you get the idea: let's not generate unnecessary memory traffic. ------------- PR: https://git.openjdk.java.net/jdk/pull/3228 From thartmann at openjdk.java.net Wed Apr 7 11:33:37 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Wed, 7 Apr 2021 11:33:37 GMT Subject: RFR: 8264649: runtime/InternalApi/ThreadCpuTimesDeadlock.java crash in fastdebug C2 with -XX:-UseTLAB In-Reply-To: References: Message-ID: <6BN6FtOuI_DuZS8Zpuy2k5xTSu10uXZjrfxMEt6e978=.b5e1ee6b-7dba-413c-9c04-bbf66098b588@github.com> On Sat, 3 Apr 2021 00:53:54 GMT, Hui Shi wrote: > Please help review this fix. Detailed analysis in https://bugs.openjdk.java.net/browse/JDK-8264649 > > Tier1/2 release /fastdebug passed Changes requested by thartmann (Reviewer). src/hotspot/share/opto/phaseX.cpp line 1481: > 1479: // Smash all inputs to 'old', isolating him completely > 1480: Node *temp = new Node(1); > 1481: temp->init_req(0,nn); // Add a use to nn to prevent him from dying Just wondering, why do we even need this? Without that code, `remove_dead_node(old)` would kill `nn` as well if it becomes dead. test/hotspot/jtreg/runtime/InternalApi/ThreadCpuTimesDeadlock.java line 36: > 34: * @test > 35: * @bug 8264649 > 36: * @summary OSR compiled metthod crash when UseTLAB is off Typo `metthod`. ------------- PR: https://git.openjdk.java.net/jdk/pull/3336 From coleenp at openjdk.java.net Wed Apr 7 11:53:11 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 7 Apr 2021 11:53:11 GMT Subject: RFR: 8259242: vmTestbase/vm/mlvm/mixed/stress/java/findDeadlock/TestDescription.java timed out In-Reply-To: <88mUXjYGWsrhiXxlkanE11_g8d6A0eppyxwOCyrCZ5Y=.93e091b7-8739-4934-acc1-57d5cd133455@github.com> References: <88mUXjYGWsrhiXxlkanE11_g8d6A0eppyxwOCyrCZ5Y=.93e091b7-8739-4934-acc1-57d5cd133455@github.com> Message-ID: On Wed, 7 Apr 2021 04:38:24 GMT, David Holmes wrote: >> This change makes the DictionaryEntry pd_set lock free, because when I set a low SafepointTimeout on the findDeadlock test, these threads were waiting on the ProtectionDomainSet_lock. This lock is a singleton that's taken for every dictionary entry. >> >> I don't know if this change will make the test never timeout again, because removing this lock caused us to hit a low SafepointTimeout on another _no_safepoint_check lock that is not so easy to eradictate. >> >> Tested with tiers 1-3. There's a test that exercises this code in runtime/Dictionary/ProtectionDomainCacheTest.java. > > src/hotspot/share/classfile/dictionary.cpp line 422: > >> 420: void Dictionary::clean_cached_protection_domains(GrowableArray* delete_list) { >> 421: assert(Thread::current()->is_Java_thread(), "only called by JavaThread"); >> 422: assert_locked_or_safepoint(SystemDictionary_lock); > > If the current thread must be a JavaThread then we cannot be at a safepoint and so the second assert can just check the lock is held. sure. > src/hotspot/share/classfile/dictionary.hpp line 145: > >> 143: >> 144: ProtectionDomainEntry* pd_set() const { return Atomic::load(&_pd_set); } >> 145: void set_pd_set(ProtectionDomainEntry* entry) { Atomic::store(&_pd_set, entry); } > > These probably need to be load_acquire and release_store, so that a lock-free traversal can proceed correctly with a locked addition/removal. With suitable name changes for the methods. I forgot that the method names have to match the implementation details. Thanks I didn't know whether they needed acquire etc. ------------- PR: https://git.openjdk.java.net/jdk/pull/3362 From coleenp at openjdk.java.net Wed Apr 7 11:59:52 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 7 Apr 2021 11:59:52 GMT Subject: RFR: 8259242: vmTestbase/vm/mlvm/mixed/stress/java/findDeadlock/TestDescription.java timed out In-Reply-To: <88mUXjYGWsrhiXxlkanE11_g8d6A0eppyxwOCyrCZ5Y=.93e091b7-8739-4934-acc1-57d5cd133455@github.com> References: <88mUXjYGWsrhiXxlkanE11_g8d6A0eppyxwOCyrCZ5Y=.93e091b7-8739-4934-acc1-57d5cd133455@github.com> Message-ID: <2jPlaBgIHX4F2zQcME2D2W2dJQuTbSWamQ_VLoBJiZE=.d374d4b8-e89e-4c8f-ba24-866f82c4f47d@github.com> On Wed, 7 Apr 2021 04:49:02 GMT, David Holmes wrote: >> This change makes the DictionaryEntry pd_set lock free, because when I set a low SafepointTimeout on the findDeadlock test, these threads were waiting on the ProtectionDomainSet_lock. This lock is a singleton that's taken for every dictionary entry. >> >> I don't know if this change will make the test never timeout again, because removing this lock caused us to hit a low SafepointTimeout on another _no_safepoint_check lock that is not so easy to eradictate. >> >> Tested with tiers 1-3. There's a test that exercises this code in runtime/Dictionary/ProtectionDomainCacheTest.java. > > src/hotspot/share/classfile/protectionDomainCache.cpp line 89: > >> 87: // If there are any deleted entries, Handshake-all then they'll be >> 88: // safe to remove since traversing the pd_set list does not stop for >> 89: // safepoints and only JavaThreads will read the pd_set. > > I do not understand what you are trying to do here. This is basically a no-op handshake with every thread? Does all the threads remain in the handshake until the last one is processed or do they proceed through one at a time? The former seems better suited for a safepoint operation. The latter means this doesn't work as they may have moved on to a new removal. Only the ServiceThread calls this code, so they won't be removed again. This is modeled after the ObjectMonitor code that does the same thing. All the threads have to hit a handshake at a safepoint polling place, which they cannot do while reading the list. After all the threads have hit the handshake, no thread can see the old entries on the list. I thought that's what I said in the comment. What should I say to make this clearer? > src/hotspot/share/classfile/protectionDomainCache.hpp line 115: > >> 113: >> 114: ProtectionDomainEntry* next() { return Atomic::load(&_next); } >> 115: void set_next(ProtectionDomainEntry* entry) { Atomic::store(&_next, entry); } > > Again these may need to be load_acquire/release_store for correct lock-free traversal. With suitable name changes for the methods. Thanks, I'll add acquire/release and change the names to match the implementation details. ------------- PR: https://git.openjdk.java.net/jdk/pull/3362 From coleenp at openjdk.java.net Wed Apr 7 12:05:35 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 7 Apr 2021 12:05:35 GMT Subject: RFR: 8259242: vmTestbase/vm/mlvm/mixed/stress/java/findDeadlock/TestDescription.java timed out In-Reply-To: <88mUXjYGWsrhiXxlkanE11_g8d6A0eppyxwOCyrCZ5Y=.93e091b7-8739-4934-acc1-57d5cd133455@github.com> References: <88mUXjYGWsrhiXxlkanE11_g8d6A0eppyxwOCyrCZ5Y=.93e091b7-8739-4934-acc1-57d5cd133455@github.com> Message-ID: On Wed, 7 Apr 2021 04:55:35 GMT, David Holmes wrote: >> This change makes the DictionaryEntry pd_set lock free, because when I set a low SafepointTimeout on the findDeadlock test, these threads were waiting on the ProtectionDomainSet_lock. This lock is a singleton that's taken for every dictionary entry. >> >> I don't know if this change will make the test never timeout again, because removing this lock caused us to hit a low SafepointTimeout on another _no_safepoint_check lock that is not so easy to eradictate. >> >> Tested with tiers 1-3. There's a test that exercises this code in runtime/Dictionary/ProtectionDomainCacheTest.java. > > Hi Coleen, > > Can you explain the synchronization protocol you are using here please - I don't understand how the handshake fits into it ?? > > Further comments below. > > Thanks, > David The lock-free algorithm is based on the one for object monitors, except that adding and deleting entries is done with the SystemDictionary_lock held, reading entries is done with a (now) Atomic load acquires etc with no safepoint polls, and deleting the entries is done by saving the entries off to the side, until a handshake is reached, meaning none of the readers are reading the old version of the list. ------------- PR: https://git.openjdk.java.net/jdk/pull/3362 From hshi at openjdk.java.net Wed Apr 7 12:09:09 2021 From: hshi at openjdk.java.net (Hui Shi) Date: Wed, 7 Apr 2021 12:09:09 GMT Subject: RFR: 8264649: runtime/InternalApi/ThreadCpuTimesDeadlock.java crash in fastdebug C2 with -XX:-UseTLAB [v2] In-Reply-To: <6BN6FtOuI_DuZS8Zpuy2k5xTSu10uXZjrfxMEt6e978=.b5e1ee6b-7dba-413c-9c04-bbf66098b588@github.com> References: <6BN6FtOuI_DuZS8Zpuy2k5xTSu10uXZjrfxMEt6e978=.b5e1ee6b-7dba-413c-9c04-bbf66098b588@github.com> Message-ID: <03pdWufgmVqBPCnhdEvHJnRHkblBlxSiAUsG4Zjpg30=.a17a5efa-8f65-4933-994a-f176f9c45cfb@github.com> On Wed, 7 Apr 2021 11:29:06 GMT, Tobias Hartmann wrote: >> Hui Shi has updated the pull request incrementally with one additional commit since the last revision: >> >> fix typo in test description > > src/hotspot/share/opto/phaseX.cpp line 1481: > >> 1479: // Smash all inputs to 'old', isolating him completely >> 1480: Node *temp = new Node(1); >> 1481: temp->init_req(0,nn); // Add a use to nn to prevent him from dying > > Just wondering, why do we even need this? Without that code, `remove_dead_node(old)` would kill `nn` as well if it becomes dead. Thanks for your review! Checking code history, this code is quite old. From comments around, it doesn't want nn removed directly in PhaseIterGVN::subsume_node and leaves optimization to next GVN iteration. In my understanding, it might save callers to insert codes checking if "nn" is removed/dead at every subsume_node/replace_node callsite, simplifies implementation. 8153779a hotspot/src/share/vm/opto/phaseX.cpp (J. Duke 2007-12-01 00:00:00 +0000 1479) // Smash all inputs to 'old', isolating him completely 2a0815a5 hotspot/src/share/vm/opto/phaseX.cpp (Tobias Hartmann 2014-06-02 08:07:29 +0200 1480) Node *temp = new Node(1); 8153779a hotspot/src/share/vm/opto/phaseX.cpp (J. Duke 2007-12-01 00:00:00 +0000 1481) temp->init_req(0,nn); // Add a use to nn to prevent him from dying 8153779a hotspot/src/share/vm/opto/phaseX.cpp (J. Duke 2007-12-01 00:00:00 +0000 1482) remove_dead_node( old ); 8153779a hotspot/src/share/vm/opto/phaseX.cpp (J. Duke 2007-12-01 00:00:00 +0000 1483) temp->del_req(0); // Yank bogus edge > test/hotspot/jtreg/runtime/InternalApi/ThreadCpuTimesDeadlock.java line 36: > >> 34: * @test >> 35: * @bug 8264649 >> 36: * @summary OSR compiled metthod crash when UseTLAB is off > > Typo `metthod`. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/3336 From hshi at openjdk.java.net Wed Apr 7 12:09:05 2021 From: hshi at openjdk.java.net (Hui Shi) Date: Wed, 7 Apr 2021 12:09:05 GMT Subject: RFR: 8264649: runtime/InternalApi/ThreadCpuTimesDeadlock.java crash in fastdebug C2 with -XX:-UseTLAB [v2] In-Reply-To: References: Message-ID: > Please help review this fix. Detailed analysis in https://bugs.openjdk.java.net/browse/JDK-8264649 > > Tier1/2 release /fastdebug passed Hui Shi has updated the pull request incrementally with one additional commit since the last revision: fix typo in test description ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3336/files - new: https://git.openjdk.java.net/jdk/pull/3336/files/08292fe1..2f6b68df Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3336&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3336&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3336.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3336/head:pull/3336 PR: https://git.openjdk.java.net/jdk/pull/3336 From coleenp at openjdk.java.net Wed Apr 7 12:30:52 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 7 Apr 2021 12:30:52 GMT Subject: RFR: 8259242: vmTestbase/vm/mlvm/mixed/stress/java/findDeadlock/TestDescription.java timed out In-Reply-To: <2jPlaBgIHX4F2zQcME2D2W2dJQuTbSWamQ_VLoBJiZE=.d374d4b8-e89e-4c8f-ba24-866f82c4f47d@github.com> References: <88mUXjYGWsrhiXxlkanE11_g8d6A0eppyxwOCyrCZ5Y=.93e091b7-8739-4934-acc1-57d5cd133455@github.com> <2jPlaBgIHX4F2zQcME2D2W2dJQuTbSWamQ_VLoBJiZE=.d374d4b8-e89e-4c8f-ba24-866f82c4f47d@github.com> Message-ID: On Wed, 7 Apr 2021 11:55:56 GMT, Coleen Phillimore wrote: >> src/hotspot/share/classfile/protectionDomainCache.hpp line 115: >> >>> 113: >>> 114: ProtectionDomainEntry* next() { return Atomic::load(&_next); } >>> 115: void set_next(ProtectionDomainEntry* entry) { Atomic::store(&_next, entry); } >> >> Again these may need to be load_acquire/release_store for correct lock-free traversal. With suitable name changes for the methods. > > Thanks, I'll add acquire/release and change the names to match the implementation details. Did we collectively agree on the naming convention that set_next has to be release_set_next because the implementation uses release_store, or is this just your preference? I find this noisy in the context where these functions are being called. ------------- PR: https://git.openjdk.java.net/jdk/pull/3362 From coleenp at openjdk.java.net Wed Apr 7 12:39:19 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 7 Apr 2021 12:39:19 GMT Subject: RFR: 8259242: vmTestbase/vm/mlvm/mixed/stress/java/findDeadlock/TestDescription.java timed out [v2] In-Reply-To: References: Message-ID: > This change makes the DictionaryEntry pd_set lock free, because when I set a low SafepointTimeout on the findDeadlock test, these threads were waiting on the ProtectionDomainSet_lock. This lock is a singleton that's taken for every dictionary entry. > > I don't know if this change will make the test never timeout again, because removing this lock caused us to hit a low SafepointTimeout on another _no_safepoint_check lock that is not so easy to eradictate. > > Tested with tiers 1-3. There's a test that exercises this code in runtime/Dictionary/ProtectionDomainCacheTest.java. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Add acquire/release and update names. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3362/files - new: https://git.openjdk.java.net/jdk/pull/3362/files/0695d6e9..40c359b1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3362&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3362&range=00-01 Stats: 25 lines in 3 files changed: 0 ins; 1 del; 24 mod Patch: https://git.openjdk.java.net/jdk/pull/3362.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3362/head:pull/3362 PR: https://git.openjdk.java.net/jdk/pull/3362 From hseigel at openjdk.java.net Wed Apr 7 12:50:13 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 7 Apr 2021 12:50:13 GMT Subject: RFR: 8264711: More runtime TRAPS cleanups [v3] In-Reply-To: References: Message-ID: > Please review this additional cleanup of use of TRAPS in hotspot runtime code. The changes were tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows and Mach5 tiers 3-5 on Linux x64. > > Thanks, Harold Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: restore improperly removed TRAPS ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3345/files - new: https://git.openjdk.java.net/jdk/pull/3345/files/e488fb8a..1ee327f0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3345&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3345&range=01-02 Stats: 42 lines in 7 files changed: 5 ins; 3 del; 34 mod Patch: https://git.openjdk.java.net/jdk/pull/3345.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3345/head:pull/3345 PR: https://git.openjdk.java.net/jdk/pull/3345 From hseigel at openjdk.java.net Wed Apr 7 14:19:53 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 7 Apr 2021 14:19:53 GMT Subject: RFR: 8264711: More runtime TRAPS cleanups [v4] In-Reply-To: References: Message-ID: On Mon, 5 Apr 2021 19:08:38 GMT, Patricio Chilano Mateo wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> remove unneeded statement > > src/hotspot/share/runtime/synchronizer.cpp line 609: > >> 607: // intentionally do not use CHECK on check_owner because we must exit the >> 608: // monitor even if an exception was already pending. >> 609: if (monitor->check_owner(current)) { > > We can actually throw IMSE from check_owner() if this thread is not the real owner. I reverted this change. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/3345 From hseigel at openjdk.java.net Wed Apr 7 14:19:50 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 7 Apr 2021 14:19:50 GMT Subject: RFR: 8264711: More runtime TRAPS cleanups [v4] In-Reply-To: References: Message-ID: > Please review this additional cleanup of use of TRAPS in hotspot runtime code. The changes were tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows and Mach5 tiers 3-5 on Linux x64. > > Thanks, Harold Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: remove unneeded statement ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3345/files - new: https://git.openjdk.java.net/jdk/pull/3345/files/1ee327f0..0f1b4f6b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3345&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3345&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3345.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3345/head:pull/3345 PR: https://git.openjdk.java.net/jdk/pull/3345 From hseigel at openjdk.java.net Wed Apr 7 14:24:23 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 7 Apr 2021 14:24:23 GMT Subject: RFR: 8264711: More runtime TRAPS cleanups [v2] In-Reply-To: References: Message-ID: On Mon, 5 Apr 2021 23:28:38 GMT, David Holmes wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> Undo change to ObjectSynchronizer::jni_exit() > > Hi Harold, > > Lots of good cleanup here but also a couple of things that I think are incorrect. Platform string creation can throw exceptions; and I also believe the ClassFileLoadHook can too. > > Thanks, > David Please review this latest version of this change containing reviewer suggested changes. Thanks, Harold > src/hotspot/share/classfile/javaClasses.cpp line 396: > >> 394: >> 395: // Converts a C string to a Java String based on current encoding >> 396: Handle java_lang_String::create_from_platform_dependent_str(JavaThread* current, const char* str) { > > This change is incorrect. JNU_NewStringPlatform can raise an exception so TRAPS here is correct. Thanks for finding this. I reverted this change and the change to as_platform_dependent_str() because it calls GetStringPlatformChars() which calls JNU_GetStringPlatformChars() which can throw an exception. > src/hotspot/share/prims/jvmtiEnv.cpp line 709: > >> 707: >> 708: // need the path as java.lang.String >> 709: Handle path = java_lang_String::create_from_platform_dependent_str(THREAD, segment); > > This change will need reverting as an exception is possible as previously noted. > > But note that if there was no possibility of exception here then the following check of HAS_PENDING_EXCEPTION should also have been removed. Reverted. ------------- PR: https://git.openjdk.java.net/jdk/pull/3345 From hseigel at openjdk.java.net Wed Apr 7 14:24:24 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Wed, 7 Apr 2021 14:24:24 GMT Subject: RFR: 8264711: More runtime TRAPS cleanups [v4] In-Reply-To: References: Message-ID: On Mon, 5 Apr 2021 23:15:48 GMT, David Holmes wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> remove unneeded statement > > src/hotspot/share/classfile/klassFactory.cpp line 117: > >> 115: ClassLoaderData* loader_data, >> 116: Handle protection_domain, >> 117: JvmtiCachedClassFileData** cached_class_file) { > > I don't think this removal of TRAPS is correct. The ClassFileLoadHook could result in an exception becoming pending. Thanks! This change was reverted. ------------- PR: https://git.openjdk.java.net/jdk/pull/3345 From shade at openjdk.java.net Wed Apr 7 14:52:53 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 7 Apr 2021 14:52:53 GMT Subject: RFR: 8264513: Cleanup CardTableBarrierSetC2::post_barrier In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 13:46:47 GMT, Aleksey Shipilev wrote: > There are few stale comments after CMS removal. We can also clean up some coding, while we are at it. Gentle ping? ------------- PR: https://git.openjdk.java.net/jdk/pull/3285 From github.com+71302734+amitdpawar at openjdk.java.net Wed Apr 7 15:22:10 2021 From: github.com+71302734+amitdpawar at openjdk.java.net (Amit Pawar) Date: Wed, 7 Apr 2021 15:22:10 GMT Subject: RFR: JDK-8260332: ParallelGC: Cooperative pretouch for oldgen expansion [v4] In-Reply-To: References: Message-ID: > In case of ParallelGC, oldgen expansion can happen during promotion. Expanding thread will touch the pages and can't request for task execution as this GC thread is already executing a task. The expanding thread holds the lock on "ExpandHeap_lock" to resize the oldgen and other threads may wait for their turn. This is a blocking call. > > This patch changes this behavior by adding another constructor in "MutexLocker" class to enable non blocking or try_lock operation. This way one thread will acquire the lock and other threads can join pretouch work. Threads failed to acquire the lock will join pretouch only when task is marked ready by expanding thread. > > Following minimum expansion size are seen during expansion. > 1. 512KB without largepages and without UseNUMA. > 2. 64MB without largepages and with UseNUMA, > 3. 2MB (on x86) with large pages and without UseNUMA, > 4. 64MB without large pages and with UseNUMA. > > When Oldgen is expanding repeatedly with smaller size then this change wont help. For such cases, resize size should adapt to application demand to make use of this change. For example if application nature triggers 100 expansion with smaller sizes in same GC then it is better to increase the expansion size during each resize to reduce the number of resizes. If this patch is accepted then will plan to fix this case in another patch. > > Jtreg all test passed. > > Please review this change. Amit Pawar has updated the pull request incrementally with one additional commit since the last revision: This code is used for testing purpose and lock should be acquired with no safepoint check as similar to earlier code. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2976/files - new: https://git.openjdk.java.net/jdk/pull/2976/files/f75593aa..259a10c6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2976&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2976&range=02-03 Stats: 26 lines in 1 file changed: 5 ins; 0 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/2976.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2976/head:pull/2976 PR: https://git.openjdk.java.net/jdk/pull/2976 From minqi at openjdk.java.net Wed Apr 7 15:37:49 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 7 Apr 2021 15:37:49 GMT Subject: RFR: 8259070: Add jcmd option to dump CDS [v10] In-Reply-To: References: Message-ID: <8Em0aTz_KxKneptL7dOuu1ldmzYI0kwDzEfHkz1kQrc=.2ad4881c-23db-4934-8a79-f84db54a1417@github.com> > Hi, Please review > > Added jcmd option for dumping CDS archive during application runtime. Before this change, user has to dump shared archive in two steps: first run application with > `java -XX:DumpLoadedClassList= .... ` > to collect shareable class names and saved in file `` , then > `java -Xshare:dump -XX:SharedClassListFile= -XX:SharedArchiveFile= ...` > With this change, user can use jcmd to dump CDS without going through above steps. Also user can choose a moment during the app runtime to dump an archive. > The bug is associated with the CSR: https://bugs.openjdk.java.net/browse/JDK-8259798 which has been approved. > New added jcmd option: > `jcmd VM.cds static_dump ` > or > `jcmd VM.cds dynamic_dump ` > To dump dynamic archive, requires start app with newly added flag `-XX:+RecordDynamicDumpInfo`, with this flag, some information related to dynamic dump like loader constraints will be recorded. Note the dumping process changed some object memory locations so for dumping dynamic archive, can only done once for a running app. For static dump, user can dump multiple times against same process. > The file name is optional, if the file name is not supplied, the file name will take format of `java_pid_static.jsa` or `java_pid_dynamic.jsa` for static and dynamic respectively. The `` is the application process ID. > > Tests: tier1,tier2,tier3,tier4 > > Thanks > Yumin Yumin Qi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 - Restructed code and rename LingeredTestApp.java to JCmdTestLingeredApp.java - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 - Fix revert unintentionally comment, merge master. - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 - Remove CDS.getVMArguments, changed to use VM.getRuntimeVMArguments. Removed unused function from ClassLoader. Improved InstanceKlass::is_shareable() and related test. Added more test scenarios. - Remove redundant check for if a class is shareable - Fix according to review comment and add more tests - Fix filter more flags to exclude in static dump, add more test cases - ... and 4 more: https://git.openjdk.java.net/jdk/compare/a756d8d7...b3d20348 ------------- Changes: https://git.openjdk.java.net/jdk/pull/2737/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2737&range=09 Stats: 835 lines in 23 files changed: 762 ins; 58 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/2737.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2737/head:pull/2737 PR: https://git.openjdk.java.net/jdk/pull/2737 From github.com+71302734+amitdpawar at openjdk.java.net Wed Apr 7 15:42:35 2021 From: github.com+71302734+amitdpawar at openjdk.java.net (Amit Pawar) Date: Wed, 7 Apr 2021 15:42:35 GMT Subject: RFR: JDK-8260332: ParallelGC: Cooperative pretouch for oldgen expansion [v2] In-Reply-To: References: <8hmX1slrUPMWTec3K6Z1xSV7D6JEtbmLEox0JNZ93xQ=.66ea31cd-f702-4653-8a12-01cea1d50843@github.com> Message-ID: <4ZQtaZ4bPx9u0LZMyvtR_vIB0d2D5_0Ts7ML-PbBwPA=.0758209f-4a1e-453b-af33-92355583d465@github.com> On Mon, 5 Apr 2021 20:07:00 GMT, Amit Pawar wrote: >>> > > [PreTouchParallelChunkSize_TestResults_UpdatedForOldGenCase.xlsx](https://github.com/openjdk/jdk/files/6147180/PreTouchParallelChunkSize_TestResults_UpdatedForOldGenCase.xlsx) >>> > >>> > >>> > I'm not sure how to interpret this. In particular, it says "Test done using November 27rd Openjdk build". That predates a number of recent changes in this area that seem relevant. Is that correct? Or is that stale and the data has been updated for a newer baseline. >>> >>> Sorry for the confusion. I didnt test again and pre-touch time taken with different chunk size per thread was already recorded in the spreadsheet and thought to use it for reference to reply to David feedback "A change like this needs a lot more testing than that, both functionally and performance.". >> >> Getting any benefit from parallel pretouch here suggests we have many threads piling up on the expand mutex. Before JDK-8260045 (pushed together with JDK-8260044 on 2/12/2021) that would lead to "expansion storms", where several threads piled up on that mutex and serially entered and did a new expansion (with associated pretouch, and possibly of significant size). Getting rid of the expansion storms may alleviate the serial pretouch quite a bit. There may still be some benefit to cooperative parallization, but new measurements are needed to determine how much of a problem still exists. >> >> If it is still worth addressing, I think the proposed approach has problems, as it makes messy complicated code messier and more complicated. I think some preliminary refactoring is needed. For example, splitting MutableSpace::initialize into a setup-pages part and set-the-range part. I've not explored in detail what's needed yet, pending new measurements. (I haven't had time to do those measurements yet myself.) > > Thanks Kim for your feedback. > > I have updated the code and it looks good now. Please use "Full" diff to see all the changes. > > Summary of changes: added new class in pretouchTask.hpp file for synchronization. Now co-operative pretouch is enabled for both ParallelGC and G1GC. For testing purpose, added new flag "UseMultithreadedPretouchForOldGen" and timing is enabled for old-gen pretouch case for measurements. Enabling this flag makes try_lock to be used instead of lock (which is current default). > > This change will be useful only if PreTouchParallelChunkSize value is not very huge compared to old-gen expansion size. For Linux it is set to 4MB and for other OS it is still 1GB. > > Testing SPECJbb composite on AMD EPYC machine shows following improvement. > > - Parallel GC: with UseNUMA, minimum expansion size is 64MB > -- with 2MB hugepages, master branch time taken is ~9-10ms and current fix time taken is ~1-2ms` > -- without hugepages, master branch time taken is ~14-17ms and current fix time taken is ~2-3ms > > - Parallel GC: without UseNUMA, minimum expansion size is 512KB so this change is not useful for this size. Sometime expansion goes upto 20MB then pretouch takes less time for such large size. > > - G1 GC: with UseNUMA, maximum expansion size is 32MB > -- with 2MB hugepages, master branch time taken is ~5-7ms and current fix time taken is ~1-7ms` (higher time due to single thread activity as there was no other thread waiting to acquire the lock) > > - G1 GC: without UseNUMA, minimum expansion size 64KB and maximum expansion size is 32MB > -- without hugepages, master branch time taken = ~9-11ms and current fix time taken ~2-9ms (same here too) > > Please check. Fixing runtime issue seen in Pre-submit tests. I somehow missed no safepoint check while acquiring the lock in G1 case. Minor issue. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/2976 From dcubed at openjdk.java.net Wed Apr 7 15:44:33 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 7 Apr 2021 15:44:33 GMT Subject: RFR: 8264711: More runtime TRAPS cleanups [v4] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 14:19:50 GMT, Harold Seigel wrote: >> Please review this additional cleanup of use of TRAPS in hotspot runtime code. The changes were tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows and Mach5 tiers 3-5 on Linux x64. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > remove unneeded statement Marked as reviewed by dcubed (Reviewer). src/hotspot/share/interpreter/bytecode.cpp line 160: > 158: } > 159: > 160: Handle Bytecode_invoke::appendix(TRAPS) { You might want to mention the removal of this function in the bug report so that it will show up in a JBS search. ------------- PR: https://git.openjdk.java.net/jdk/pull/3345 From dcubed at openjdk.java.net Wed Apr 7 15:44:34 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 7 Apr 2021 15:44:34 GMT Subject: RFR: 8264711: More runtime TRAPS cleanups [v4] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 15:40:58 GMT, Daniel D. Daugherty wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> remove unneeded statement > > Marked as reviewed by dcubed (Reviewer). Thumbs up. ------------- PR: https://git.openjdk.java.net/jdk/pull/3345 From goetz at openjdk.java.net Wed Apr 7 16:20:54 2021 From: goetz at openjdk.java.net (Goetz Lindenmaier) Date: Wed, 7 Apr 2021 16:20:54 GMT Subject: RFR: 8264173: [s390] Improve Hardware Feature Detection And Reporting [v3] In-Reply-To: <-dA2uhXwH7eME201-lzohAOpXigVwsUjtGACZZWMRXc=.0a4e611f-a3c0-470f-a310-5d17715492e1@github.com> References: <-OjFHEcBr4ajS6JQWPsPHXm2w8MNQ5b028UlabrDv84=.174c9149-ca67-4929-a3b5-0bc6f561df5e@github.com> <-dA2uhXwH7eME201-lzohAOpXigVwsUjtGACZZWMRXc=.0a4e611f-a3c0-470f-a310-5d17715492e1@github.com> Message-ID: <7Urlz3zuxm7aJgwjId9mUtSG_2qeeGrX4mNGqDtJ5aI=.d881dc3b-b102-4427-b43c-9d7b73abeb60@github.com> On Mon, 29 Mar 2021 10:36:47 GMT, Lutz Schmidt wrote: >> This enhancement is intended to improve the hardware feature detection and reporting, in particular for more recently introduced hardware. The enhancement is a prerequisite for possible future feature exploitation. >> >> Reviews are highly welcome and appreciated. > > Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision: > > cleaned up some spaces Marked as reviewed by goetz (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3196 From goetz at openjdk.java.net Wed Apr 7 16:20:56 2021 From: goetz at openjdk.java.net (Goetz Lindenmaier) Date: Wed, 7 Apr 2021 16:20:56 GMT Subject: RFR: 8264173: [s390] Improve Hardware Feature Detection And Reporting [v2] In-Reply-To: <5OhEhVbnzUEotih1ykgz3Omnt3jQVEYG4B2uMFbCROY=.cbe91475-a6a5-41c3-a11c-4e23d9df9937@github.com> References: <-OjFHEcBr4ajS6JQWPsPHXm2w8MNQ5b028UlabrDv84=.174c9149-ca67-4929-a3b5-0bc6f561df5e@github.com> <5OhEhVbnzUEotih1ykgz3Omnt3jQVEYG4B2uMFbCROY=.cbe91475-a6a5-41c3-a11c-4e23d9df9937@github.com> Message-ID: On Mon, 29 Mar 2021 10:32:40 GMT, Lutz Schmidt wrote: >> I didn't expect the change to become that large. But it looks good to me. The lengthy output only gets generated with -XX:+Verbose. That's fine. > > Thank you for the review, Martin! LGTM ------------- PR: https://git.openjdk.java.net/jdk/pull/3196 From lucy at openjdk.java.net Wed Apr 7 16:20:57 2021 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Wed, 7 Apr 2021 16:20:57 GMT Subject: RFR: 8264173: [s390] Improve Hardware Feature Detection And Reporting [v3] In-Reply-To: <7Urlz3zuxm7aJgwjId9mUtSG_2qeeGrX4mNGqDtJ5aI=.d881dc3b-b102-4427-b43c-9d7b73abeb60@github.com> References: <-OjFHEcBr4ajS6JQWPsPHXm2w8MNQ5b028UlabrDv84=.174c9149-ca67-4929-a3b5-0bc6f561df5e@github.com> <-dA2uhXwH7eME201-lzohAOpXigVwsUjtGACZZWMRXc=.0a4e611f-a3c0-470f-a310-5d17715492e1@github.com> <7Urlz3zuxm7aJgwjId9mUtSG_2qeeGrX4mNGqDtJ5aI=.d881dc3b-b102-4427-b43c-9d7b73abeb60@github.com> Message-ID: On Wed, 7 Apr 2021 16:17:07 GMT, Goetz Lindenmaier wrote: >> Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision: >> >> cleaned up some spaces > > Marked as reviewed by goetz (Reviewer). Thank you Goetz! I will now proceed and integrate the PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/3196 From lucy at openjdk.java.net Wed Apr 7 16:23:44 2021 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Wed, 7 Apr 2021 16:23:44 GMT Subject: Integrated: 8264173: [s390] Improve Hardware Feature Detection And Reporting In-Reply-To: <-OjFHEcBr4ajS6JQWPsPHXm2w8MNQ5b028UlabrDv84=.174c9149-ca67-4929-a3b5-0bc6f561df5e@github.com> References: <-OjFHEcBr4ajS6JQWPsPHXm2w8MNQ5b028UlabrDv84=.174c9149-ca67-4929-a3b5-0bc6f561df5e@github.com> Message-ID: On Thu, 25 Mar 2021 15:28:21 GMT, Lutz Schmidt wrote: > This enhancement is intended to improve the hardware feature detection and reporting, in particular for more recently introduced hardware. The enhancement is a prerequisite for possible future feature exploitation. > > Reviews are highly welcome and appreciated. This pull request has now been integrated. Changeset: d3fdd739 Author: Lutz Schmidt URL: https://git.openjdk.java.net/jdk/commit/d3fdd739 Stats: 557 lines in 4 files changed: 340 ins; 74 del; 143 mod 8264173: [s390] Improve Hardware Feature Detection And Reporting Reviewed-by: mdoerr, goetz ------------- PR: https://git.openjdk.java.net/jdk/pull/3196 From lucy at openjdk.java.net Wed Apr 7 18:03:09 2021 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Wed, 7 Apr 2021 18:03:09 GMT Subject: RFR: 8264848: [macos] libjvm.dylib linker warning due to macOS version mismatch Message-ID: May I please request reviews for this small build fix. It removes a linker warning by adding a assembly-time parameter which was previously missing. The same parameter is used at c++ compile time. ------------- Commit messages: - Update Copyright Header - Merge branch 'JDK-8264848' of github.com:RealLucy/jdk into JDK-8264848 - 8264848: [macos] libjvm.dylib linker warning due to macOS version mismatch - cleaned up some spaces - update copyright headers - 8264173: [s390] Improve Hardware Feature Detection And Reporting - 8264848: [macos] libjvm.dylib linker warning due to macOS version mismatch Changes: https://git.openjdk.java.net/jdk/pull/3379/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3379&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264848 Stats: 11 lines in 1 file changed: 10 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3379.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3379/head:pull/3379 PR: https://git.openjdk.java.net/jdk/pull/3379 From erikj at openjdk.java.net Wed Apr 7 18:32:31 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 7 Apr 2021 18:32:31 GMT Subject: RFR: 8264848: [macos] libjvm.dylib linker warning due to macOS version mismatch In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 16:32:52 GMT, Lutz Schmidt wrote: > May I please request reviews for this small build fix. It removes a linker warning by adding a assembly-time parameter which was previously missing. The same parameter is used at c++ compile time. So that's where that warning came from! I don't think the comment needs to mention the warning. Otherwise this looks good to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/3379 From lucy at openjdk.java.net Wed Apr 7 18:48:01 2021 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Wed, 7 Apr 2021 18:48:01 GMT Subject: RFR: 8264848: [macos] libjvm.dylib linker warning due to macOS version mismatch [v2] In-Reply-To: References: Message-ID: > May I please request reviews for this small build fix. It removes a linker warning by adding a assembly-time parameter which was previously missing. The same parameter is used at c++ compile time. Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision: Updated comment per request from erikj79 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3379/files - new: https://git.openjdk.java.net/jdk/pull/3379/files/e8da1ccf..323f5014 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3379&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3379&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3379.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3379/head:pull/3379 PR: https://git.openjdk.java.net/jdk/pull/3379 From lucy at openjdk.java.net Wed Apr 7 18:51:45 2021 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Wed, 7 Apr 2021 18:51:45 GMT Subject: RFR: 8264848: [macos] libjvm.dylib linker warning due to macOS version mismatch In-Reply-To: References: Message-ID: <-Dyy-drsBENbEuLF4hrfSj_gnxeOql6oYFqXbh6Mhnw=.d2659d93-dce4-41fd-b0b7-6bf3957bd348@github.com> On Wed, 7 Apr 2021 18:29:31 GMT, Erik Joelsson wrote: >> May I please request reviews for this small build fix. It removes a linker warning by adding a assembly-time parameter which was previously missing. The same parameter is used at c++ compile time. > > So that's where that warning came from! > > I don't think the comment needs to mention the warning. Otherwise this looks good to me. Thank you Erik for having a look. Would you also be willing to mark this PR as reviewed? ------------- PR: https://git.openjdk.java.net/jdk/pull/3379 From erikj at openjdk.java.net Wed Apr 7 19:01:05 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 7 Apr 2021 19:01:05 GMT Subject: RFR: 8264848: [macos] libjvm.dylib linker warning due to macOS version mismatch [v2] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 18:48:01 GMT, Lutz Schmidt wrote: >> May I please request reviews for this small build fix. It removes a linker warning by adding a assembly-time parameter which was previously missing. The same parameter is used at c++ compile time. > > Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision: > > Updated comment per request from erikj79 Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3379 From dcubed at openjdk.java.net Wed Apr 7 19:06:40 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 7 Apr 2021 19:06:40 GMT Subject: RFR: 8264848: [macos] libjvm.dylib linker warning due to macOS version mismatch [v2] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 18:48:01 GMT, Lutz Schmidt wrote: >> May I please request reviews for this small build fix. It removes a linker warning by adding a assembly-time parameter which was previously missing. The same parameter is used at c++ compile time. > > Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision: > > Updated comment per request from erikj79 Thumbs up. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3379 From dcubed at openjdk.java.net Wed Apr 7 19:10:08 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 7 Apr 2021 19:10:08 GMT Subject: RFR: 8264848: [macos] libjvm.dylib linker warning due to macOS version mismatch [v2] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 19:03:14 GMT, Daniel D. Daugherty wrote: >> Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated comment per request from erikj79 > > Thumbs up. Side bar: I don't quite understand the commit history part of this PR. It looks like this PR was used for something else before it was used for this fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/3379 From lucy at openjdk.java.net Wed Apr 7 19:28:38 2021 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Wed, 7 Apr 2021 19:28:38 GMT Subject: RFR: 8264848: [macos] libjvm.dylib linker warning due to macOS version mismatch [v2] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 19:06:26 GMT, Daniel D. Daugherty wrote: >> Thumbs up. > > Side bar: I don't quite understand the commit history part of this PR. > It looks like this PR was used for something else before it was used > for this fix. @dcubed-ojdk Please just ignore the commit history. For some reason I don't understand, my push of JDK-8264848 was appended to the pushes for JDK-8264173. With previous PRs, that did not happen. Luckily, GitHub was smart enough. Btw, thanks a lot for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/3379 From iklam at openjdk.java.net Wed Apr 7 21:24:55 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 7 Apr 2021 21:24:55 GMT Subject: RFR: 8264868: Reduce inclusion of registerMap.hpp and register.hpp Message-ID: Register.hpp is included 815 times, and registerMap.hpp is include 862 times (out of about 1000 HotSpot .o files). This can be reduced by refactoring the popular header file **frame.hpp**, so that it doesn't include registerMap.hpp anymore. This reduces the number of .o files that include register.hpp to 612, and that of registerMap.hpp to 109. The total number of lines of C++ code compiled for HotSpot is reduced by about 0.5%. ------------- Commit messages: - 8264868: Reduce inclusion of registerMap.hpp and register.hpp Changes: https://git.openjdk.java.net/jdk/pull/3384/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3384&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264868 Stats: 263 lines in 27 files changed: 203 ins; 51 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/3384.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3384/head:pull/3384 PR: https://git.openjdk.java.net/jdk/pull/3384 From coleenp at openjdk.java.net Wed Apr 7 21:40:35 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Wed, 7 Apr 2021 21:40:35 GMT Subject: RFR: 8264868: Reduce inclusion of registerMap.hpp and register.hpp In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 21:03:10 GMT, Ioi Lam wrote: > Register.hpp is included 815 times, and registerMap.hpp is include 862 times (out of about 1000 HotSpot .o files). > > This can be reduced by refactoring the popular header file **frame.hpp**, so that it doesn't include registerMap.hpp anymore. This reduces the number of .o files that include register.hpp to 612, and that of registerMap.hpp to 109. > > The total number of lines of C++ code compiled for HotSpot is reduced by about 0.5%. I like StackFrameStream getting its own header file. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3384 From clanger at openjdk.java.net Wed Apr 7 22:02:54 2021 From: clanger at openjdk.java.net (Christoph Langer) Date: Wed, 7 Apr 2021 22:02:54 GMT Subject: RFR: 8264848: [macos] libjvm.dylib linker warning due to macOS version mismatch [v2] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 18:48:01 GMT, Lutz Schmidt wrote: >> May I please request reviews for this small build fix. It removes a linker warning by adding a assembly-time parameter which was previously missing. The same parameter is used at c++ compile time. > > Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision: > > Updated comment per request from erikj79 Cool, Lutz, you found it ?? ------------- Marked as reviewed by clanger (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3379 From dholmes at openjdk.java.net Thu Apr 8 02:09:44 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 8 Apr 2021 02:09:44 GMT Subject: RFR: 8262328: Templatize JVMFlag boilerplate access methods [v3] In-Reply-To: References: Message-ID: <90k6XitD4HHsJ4Ysooht5KF1Iqcfzhy0cwQZelpo8zg=.29771578-30e0-4fd7-b5af-b50383de6598@github.com> On Tue, 6 Apr 2021 03:56:50 GMT, Ioi Lam wrote: >> We have a bunch of boilerplate method like: >> >> JVMFlagAccess::boolAtPut (JVMFlag* f, bool* v, JVMFlagOrigin origin) >> JVMFlagAccess::intAtPut (JVMFlag* f, int* v, JVMFlagOrigin origin) >> JVMFlagAccess::uintAtPut (JVMFlag* f, uint* v, JVMFlagOrigin origin) >> ... >> >> Similarly, we also have 8 different functions: JVMFlag::{set_bool, set_int, set_intx, ...} >> >> We should replace such patterns with >> >> template >> JVMFlagAccess::set(JVMFlag* f, T* value, JVMFlagOrigin origin) >> >> This would allow us to templatize the 8x boilerplate functions in writeableFlags.cpp. >> >> The flag access code in whitebox.cpp can also be improved. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > reinstated JVMFlagAccess::set_{bool,int,uint,...} functions for better readability Hi Ioi, This latest version looks good to me. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3318 From yyang at openjdk.java.net Thu Apr 8 03:51:06 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Thu, 8 Apr 2021 03:51:06 GMT Subject: RFR: 8264881: Remove the old development option MemProfiling In-Reply-To: <4FP-BKxopk1Sto9DXzCdTSB4soCqNJQrbie6G4c3718=.d42fb986-e2de-41bd-a920-8743d016b51e@github.com> References: <4FP-BKxopk1Sto9DXzCdTSB4soCqNJQrbie6G4c3718=.d42fb986-e2de-41bd-a920-8743d016b51e@github.com> Message-ID: <0G5GvIyCJeDfetSLreWC9vOueJgQ3resRkRFvS8c64I=.71b09c36-4fd4-4dad-9cf4-e7366ad02431@github.com> On Thu, 8 Apr 2021 03:19:21 GMT, Yi Yang wrote: > MemProfiler is a very old development option added at: > > ^As 00018/00000/00000 > ^Ad D 1.1 98/04/14 13:18:32 renes 1 0 > ^Ac date and time created 98/04/14 13:18:32 by renes > ^Ae > > Today it doesn't work because it is untested and there is no reason/scenario to prove it is useful. > > After a short discussion in https://github.com/openjdk/jdk/pull/3340, I'd like to propose removing the memprofiler if there are no strong objections. > > Thanks! > Yang Gentle query: I do find another three product options(UseNewCode\d) that do nothing, they have been added in JDK6 as initial load commit(Maybe early). Does anyone know what's the intention of adding these options? Is it reasonable to remove them now? ------------- PR: https://git.openjdk.java.net/jdk/pull/3393 From david.holmes at oracle.com Thu Apr 8 05:34:49 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 8 Apr 2021 15:34:49 +1000 Subject: RFR: 8264881: Remove the old development option MemProfiling In-Reply-To: <0G5GvIyCJeDfetSLreWC9vOueJgQ3resRkRFvS8c64I=.71b09c36-4fd4-4dad-9cf4-e7366ad02431@github.com> References: <4FP-BKxopk1Sto9DXzCdTSB4soCqNJQrbie6G4c3718=.d42fb986-e2de-41bd-a920-8743d016b51e@github.com> <0G5GvIyCJeDfetSLreWC9vOueJgQ3resRkRFvS8c64I=.71b09c36-4fd4-4dad-9cf4-e7366ad02431@github.com> Message-ID: <2a85f724-0d53-c96b-860e-2993fcd10534@oracle.com> On 8/04/2021 1:51 pm, Yi Yang wrote: > On Thu, 8 Apr 2021 03:19:21 GMT, Yi Yang wrote: > >> MemProfiler is a very old development option added at: >> >> ^As 00018/00000/00000 >> ^Ad D 1.1 98/04/14 13:18:32 renes 1 0 >> ^Ac date and time created 98/04/14 13:18:32 by renes >> ^Ae >> >> Today it doesn't work because it is untested and there is no reason/scenario to prove it is useful. >> >> After a short discussion in https://github.com/openjdk/jdk/pull/3340, I'd like to propose removing the memprofiler if there are no strong objections. >> >> Thanks! >> Yang > > Gentle query: I do find another three product options(UseNewCode\d) that do nothing, they have been added in JDK6 as initial load commit(Maybe early). Does anyone know what's the intention of adding these options? Is it reasonable to remove them now? The UseNewCode flags are there as a development aid so that you can conditionally enable changed logic during development without needing to add a new runtime flag just for that. It can be very useful for gating changes when doing performance runs. No code ever gets committed that actually uses them though. So no, please do not delete them. :) Thanks, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3393 > From dholmes at openjdk.java.net Thu Apr 8 05:44:05 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 8 Apr 2021 05:44:05 GMT Subject: RFR: 8264881: Remove the old development option MemProfiling In-Reply-To: <4FP-BKxopk1Sto9DXzCdTSB4soCqNJQrbie6G4c3718=.d42fb986-e2de-41bd-a920-8743d016b51e@github.com> References: <4FP-BKxopk1Sto9DXzCdTSB4soCqNJQrbie6G4c3718=.d42fb986-e2de-41bd-a920-8743d016b51e@github.com> Message-ID: On Thu, 8 Apr 2021 03:19:21 GMT, Yi Yang wrote: > MemProfiler is a very old development option added at: > > ^As 00018/00000/00000 > ^Ad D 1.1 98/04/14 13:18:32 renes 1 0 > ^Ac date and time created 98/04/14 13:18:32 by renes > ^Ae > > Today it doesn't work because it is untested and there is no reason/scenario to prove it is useful. > > After a short discussion in https://github.com/openjdk/jdk/pull/3340, I'd like to propose removing the memprofiler if there are no strong objections. > > Thanks! > Yang Hi Yi, Actual code removal looks good. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3393 From yyang at openjdk.java.net Thu Apr 8 06:04:44 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Thu, 8 Apr 2021 06:04:44 GMT Subject: RFR: 8264881: Remove the old development option MemProfiling In-Reply-To: References: <4FP-BKxopk1Sto9DXzCdTSB4soCqNJQrbie6G4c3718=.d42fb986-e2de-41bd-a920-8743d016b51e@github.com> Message-ID: On Thu, 8 Apr 2021 05:38:56 GMT, David Holmes wrote: >> MemProfiler is a very old development option added at: >> >> ^As 00018/00000/00000 >> ^Ad D 1.1 98/04/14 13:18:32 renes 1 0 >> ^Ac date and time created 98/04/14 13:18:32 by renes >> ^Ae >> >> Today it doesn't work because it is untested and there is no reason/scenario to prove it is useful. >> >> After a short discussion in https://github.com/openjdk/jdk/pull/3340, I'd like to propose removing the memprofiler if there are no strong objections. >> >> Thanks! >> Yang > > Hi Yi, > > Actual code removal looks good. > > Thanks, > David > _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [hotspot-runtime-dev](mailto:hotspot-runtime-dev at openjdk.java.net):_ > > On 8/04/2021 1:51 pm, Yi Yang wrote: > > > On Thu, 8 Apr 2021 03:19:21 GMT, Yi Yang wrote: > > > MemProfiler is a very old development option added at: > > > ^As 00018/00000/00000 > > > ^Ad D 1.1 98/04/14 13:18:32 renes 1 0 > > > ^Ac date and time created 98/04/14 13:18:32 by renes > > > ^Ae > > > Today it doesn't work because it is untested and there is no reason/scenario to prove it is useful. > > > After a short discussion in https://github.com/[/pull/3340](https://github.com/openjdk/jdk/pull/3340), I'd like to propose removing the memprofiler if there are no strong objections. > > > Thanks! > > > Yang > > > > > > Gentle query: I do find another three product options(UseNewCode\d) that do nothing, they have been added in JDK6 as initial load commit(Maybe early). Does anyone know what's the intention of adding these options? Is it reasonable to remove them now? > > The UseNewCode flags are there as a development aid so that you can > conditionally enable changed logic during development without needing to > add a new runtime flag just for that. It can be very useful for gating > changes when doing performance runs. No code ever gets committed that > actually uses them though. > > So no, please do not delete them. :) > > Thanks, > David Got it. Thank you David, you are the OpenJDK encyclopedia. :) (PS: it looks like they are wrongly marked as product flags) ------------- PR: https://git.openjdk.java.net/jdk/pull/3393 From dongbo at openjdk.java.net Thu Apr 8 06:33:43 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Thu, 8 Apr 2021 06:33:43 GMT Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v7] In-Reply-To: References: Message-ID: > In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding. > Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic idea can be found at http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords. > > Patch passed jtreg tier1-3 tests with linux-aarch64-server-fastdebug build. > Tests in `test/jdk/java/util/Base64/` and `compiler/intrinsics/base64/TestBase64.java` runned specially for the correctness of the implementation. > > There can be illegal characters at the start of the input if the data is MIME encoded. > It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now. > > A JMH micro, Base64Decode.java, is added for performance test. > With different input length (upper-bounded by parameter `maxNumBytes` in the JMH micro), > we witness ~2.5x improvements with long inputs and no regression with short inputs for raw base64 decodeing, minor improvements (~10.95%) for MIME on Kunpeng916. > > The Base64Decode.java JMH micro-benchmark results: > > Benchmark (lineSize) (maxNumBytes) Mode Cnt Score Error Units > > # Kunpeng916, intrinsic > Base64Decode.testBase64Decode 4 1 avgt 5 48.614 ? 0.609 ns/op > Base64Decode.testBase64Decode 4 3 avgt 5 58.199 ? 1.650 ns/op > Base64Decode.testBase64Decode 4 7 avgt 5 69.400 ? 0.931 ns/op > Base64Decode.testBase64Decode 4 32 avgt 5 96.818 ? 1.687 ns/op > Base64Decode.testBase64Decode 4 64 avgt 5 122.856 ? 9.217 ns/op > Base64Decode.testBase64Decode 4 80 avgt 5 130.935 ? 1.667 ns/op > Base64Decode.testBase64Decode 4 96 avgt 5 143.627 ? 1.751 ns/op > Base64Decode.testBase64Decode 4 112 avgt 5 152.311 ? 1.178 ns/op > Base64Decode.testBase64Decode 4 512 avgt 5 342.631 ? 0.584 ns/op > Base64Decode.testBase64Decode 4 1000 avgt 5 573.635 ? 1.050 ns/op > Base64Decode.testBase64Decode 4 20000 avgt 5 9534.136 ? 45.172 ns/op > Base64Decode.testBase64Decode 4 50000 avgt 5 22718.726 ? 192.070 ns/op > Base64Decode.testBase64MIMEDecode 4 1 avgt 10 63.558 ? 0.336 ns/op > Base64Decode.testBase64MIMEDecode 4 3 avgt 10 82.504 ? 0.848 ns/op > Base64Decode.testBase64MIMEDecode 4 7 avgt 10 120.591 ? 0.608 ns/op > Base64Decode.testBase64MIMEDecode 4 32 avgt 10 324.314 ? 6.236 ns/op > Base64Decode.testBase64MIMEDecode 4 64 avgt 10 532.678 ? 4.670 ns/op > Base64Decode.testBase64MIMEDecode 4 80 avgt 10 678.126 ? 4.324 ns/op > Base64Decode.testBase64MIMEDecode 4 96 avgt 10 771.603 ? 6.393 ns/op > Base64Decode.testBase64MIMEDecode 4 112 avgt 10 889.608 ? 0.759 ns/op > Base64Decode.testBase64MIMEDecode 4 512 avgt 10 3663.557 ? 3.422 ns/op > Base64Decode.testBase64MIMEDecode 4 1000 avgt 10 7017.784 ? 9.128 ns/op > Base64Decode.testBase64MIMEDecode 4 20000 avgt 10 128670.660 ? 7951.521 ns/op > Base64Decode.testBase64MIMEDecode 4 50000 avgt 10 317113.667 ? 161.758 ns/op > > # Kunpeng916, default > Base64Decode.testBase64Decode 4 1 avgt 5 48.455 ? 0.571 ns/op > Base64Decode.testBase64Decode 4 3 avgt 5 57.937 ? 0.505 ns/op > Base64Decode.testBase64Decode 4 7 avgt 5 73.823 ? 1.452 ns/op > Base64Decode.testBase64Decode 4 32 avgt 5 106.484 ? 1.243 ns/op > Base64Decode.testBase64Decode 4 64 avgt 5 141.004 ? 1.188 ns/op > Base64Decode.testBase64Decode 4 80 avgt 5 156.284 ? 0.572 ns/op > Base64Decode.testBase64Decode 4 96 avgt 5 174.137 ? 0.177 ns/op > Base64Decode.testBase64Decode 4 112 avgt 5 188.445 ? 0.572 ns/op > Base64Decode.testBase64Decode 4 512 avgt 5 610.847 ? 1.559 ns/op > Base64Decode.testBase64Decode 4 1000 avgt 5 1155.368 ? 0.813 ns/op > Base64Decode.testBase64Decode 4 20000 avgt 5 19751.477 ? 24.669 ns/op > Base64Decode.testBase64Decode 4 50000 avgt 5 50046.586 ? 523.155 ns/op > Base64Decode.testBase64MIMEDecode 4 1 avgt 10 64.130 ? 0.238 ns/op > Base64Decode.testBase64MIMEDecode 4 3 avgt 10 82.096 ? 0.205 ns/op > Base64Decode.testBase64MIMEDecode 4 7 avgt 10 118.849 ? 0.610 ns/op > Base64Decode.testBase64MIMEDecode 4 32 avgt 10 331.177 ? 4.732 ns/op > Base64Decode.testBase64MIMEDecode 4 64 avgt 10 549.117 ? 0.177 ns/op > Base64Decode.testBase64MIMEDecode 4 80 avgt 10 702.951 ? 4.572 ns/op > Base64Decode.testBase64MIMEDecode 4 96 avgt 10 799.566 ? 0.301 ns/op > Base64Decode.testBase64MIMEDecode 4 112 avgt 10 923.749 ? 0.389 ns/op > Base64Decode.testBase64MIMEDecode 4 512 avgt 10 4000.725 ? 2.519 ns/op > Base64Decode.testBase64MIMEDecode 4 1000 avgt 10 7674.994 ? 9.281 ns/op > Base64Decode.testBase64MIMEDecode 4 20000 avgt 10 142059.001 ? 157.920 ns/op > Base64Decode.testBase64MIMEDecode 4 50000 avgt 10 355698.369 ? 216.542 ns/op Dong Bo has updated the pull request incrementally with one additional commit since the last revision: reduce unnecessary memory write traffic in non-SIMD code ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3228/files - new: https://git.openjdk.java.net/jdk/pull/3228/files/a342ad1e..ab0e405b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3228&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3228&range=05-06 Stats: 7 lines in 1 file changed: 0 ins; 1 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/3228.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3228/head:pull/3228 PR: https://git.openjdk.java.net/jdk/pull/3228 From dongbo at openjdk.java.net Thu Apr 8 06:39:11 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Thu, 8 Apr 2021 06:39:11 GMT Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v6] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 09:53:36 GMT, Andrew Haley wrote: >> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5829: >> >>> 5827: __ strb(r14, __ post(dst, 1)); >>> 5828: __ strb(r15, __ post(dst, 1)); >>> 5829: __ strb(r13, __ post(dst, 1)); >> >> I think this sequence should be 4 BFMs, STRW, BFM, STRW. That's the best we can do, I think. > > Sorry, that's not quite right, but you get the idea: let's not generate unnecessary memory traffic. Okay, implemented as: __ lslw(r14, r10, 10); __ bfiw(r14, r11, 4, 6); __ bfmw(r14, r12, 2, 5); __ rev16w(r14, r14); __ bfiw(r13, r12, 6, 2); __ strh(r14, __ post(dst, 2)); __ strb(r13, __ post(dst, 1)); ------------- PR: https://git.openjdk.java.net/jdk/pull/3228 From tschatzl at openjdk.java.net Thu Apr 8 07:23:14 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 8 Apr 2021 07:23:14 GMT Subject: RFR: 8264513: Cleanup CardTableBarrierSetC2::post_barrier In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 13:46:47 GMT, Aleksey Shipilev wrote: > There are few stale comments after CMS removal. We can also clean up some coding, while we are at it. Lgtm. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3285 From lucy at openjdk.java.net Thu Apr 8 08:00:09 2021 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Thu, 8 Apr 2021 08:00:09 GMT Subject: RFR: 8264848: [macos] libjvm.dylib linker warning due to macOS version mismatch [v2] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 21:59:15 GMT, Christoph Langer wrote: >> Lutz Schmidt has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated comment per request from erikj79 > > Cool, Lutz, you found it ?? Thank you for the review, Christoph! I'll integrate the change today, early afternoon (UTC). ------------- PR: https://git.openjdk.java.net/jdk/pull/3379 From aph at openjdk.java.net Thu Apr 8 08:32:18 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Thu, 8 Apr 2021 08:32:18 GMT Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v7] In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 06:33:43 GMT, Dong Bo wrote: >> In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding. >> Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic idea can be found at http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords. >> >> Patch passed jtreg tier1-3 tests with linux-aarch64-server-fastdebug build. >> Tests in `test/jdk/java/util/Base64/` and `compiler/intrinsics/base64/TestBase64.java` runned specially for the correctness of the implementation. >> >> There can be illegal characters at the start of the input if the data is MIME encoded. >> It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now. >> >> A JMH micro, Base64Decode.java, is added for performance test. >> With different input length (upper-bounded by parameter `maxNumBytes` in the JMH micro), >> we witness ~2.5x improvements with long inputs and no regression with short inputs for raw base64 decodeing, minor improvements (~10.95%) for MIME on Kunpeng916. >> >> The Base64Decode.java JMH micro-benchmark results: >> >> Benchmark (lineSize) (maxNumBytes) Mode Cnt Score Error Units >> >> # Kunpeng916, intrinsic >> Base64Decode.testBase64Decode 4 1 avgt 5 48.614 ? 0.609 ns/op >> Base64Decode.testBase64Decode 4 3 avgt 5 58.199 ? 1.650 ns/op >> Base64Decode.testBase64Decode 4 7 avgt 5 69.400 ? 0.931 ns/op >> Base64Decode.testBase64Decode 4 32 avgt 5 96.818 ? 1.687 ns/op >> Base64Decode.testBase64Decode 4 64 avgt 5 122.856 ? 9.217 ns/op >> Base64Decode.testBase64Decode 4 80 avgt 5 130.935 ? 1.667 ns/op >> Base64Decode.testBase64Decode 4 96 avgt 5 143.627 ? 1.751 ns/op >> Base64Decode.testBase64Decode 4 112 avgt 5 152.311 ? 1.178 ns/op >> Base64Decode.testBase64Decode 4 512 avgt 5 342.631 ? 0.584 ns/op >> Base64Decode.testBase64Decode 4 1000 avgt 5 573.635 ? 1.050 ns/op >> Base64Decode.testBase64Decode 4 20000 avgt 5 9534.136 ? 45.172 ns/op >> Base64Decode.testBase64Decode 4 50000 avgt 5 22718.726 ? 192.070 ns/op >> Base64Decode.testBase64MIMEDecode 4 1 avgt 10 63.558 ? 0.336 ns/op >> Base64Decode.testBase64MIMEDecode 4 3 avgt 10 82.504 ? 0.848 ns/op >> Base64Decode.testBase64MIMEDecode 4 7 avgt 10 120.591 ? 0.608 ns/op >> Base64Decode.testBase64MIMEDecode 4 32 avgt 10 324.314 ? 6.236 ns/op >> Base64Decode.testBase64MIMEDecode 4 64 avgt 10 532.678 ? 4.670 ns/op >> Base64Decode.testBase64MIMEDecode 4 80 avgt 10 678.126 ? 4.324 ns/op >> Base64Decode.testBase64MIMEDecode 4 96 avgt 10 771.603 ? 6.393 ns/op >> Base64Decode.testBase64MIMEDecode 4 112 avgt 10 889.608 ? 0.759 ns/op >> Base64Decode.testBase64MIMEDecode 4 512 avgt 10 3663.557 ? 3.422 ns/op >> Base64Decode.testBase64MIMEDecode 4 1000 avgt 10 7017.784 ? 9.128 ns/op >> Base64Decode.testBase64MIMEDecode 4 20000 avgt 10 128670.660 ? 7951.521 ns/op >> Base64Decode.testBase64MIMEDecode 4 50000 avgt 10 317113.667 ? 161.758 ns/op >> >> # Kunpeng916, default >> Base64Decode.testBase64Decode 4 1 avgt 5 48.455 ? 0.571 ns/op >> Base64Decode.testBase64Decode 4 3 avgt 5 57.937 ? 0.505 ns/op >> Base64Decode.testBase64Decode 4 7 avgt 5 73.823 ? 1.452 ns/op >> Base64Decode.testBase64Decode 4 32 avgt 5 106.484 ? 1.243 ns/op >> Base64Decode.testBase64Decode 4 64 avgt 5 141.004 ? 1.188 ns/op >> Base64Decode.testBase64Decode 4 80 avgt 5 156.284 ? 0.572 ns/op >> Base64Decode.testBase64Decode 4 96 avgt 5 174.137 ? 0.177 ns/op >> Base64Decode.testBase64Decode 4 112 avgt 5 188.445 ? 0.572 ns/op >> Base64Decode.testBase64Decode 4 512 avgt 5 610.847 ? 1.559 ns/op >> Base64Decode.testBase64Decode 4 1000 avgt 5 1155.368 ? 0.813 ns/op >> Base64Decode.testBase64Decode 4 20000 avgt 5 19751.477 ? 24.669 ns/op >> Base64Decode.testBase64Decode 4 50000 avgt 5 50046.586 ? 523.155 ns/op >> Base64Decode.testBase64MIMEDecode 4 1 avgt 10 64.130 ? 0.238 ns/op >> Base64Decode.testBase64MIMEDecode 4 3 avgt 10 82.096 ? 0.205 ns/op >> Base64Decode.testBase64MIMEDecode 4 7 avgt 10 118.849 ? 0.610 ns/op >> Base64Decode.testBase64MIMEDecode 4 32 avgt 10 331.177 ? 4.732 ns/op >> Base64Decode.testBase64MIMEDecode 4 64 avgt 10 549.117 ? 0.177 ns/op >> Base64Decode.testBase64MIMEDecode 4 80 avgt 10 702.951 ? 4.572 ns/op >> Base64Decode.testBase64MIMEDecode 4 96 avgt 10 799.566 ? 0.301 ns/op >> Base64Decode.testBase64MIMEDecode 4 112 avgt 10 923.749 ? 0.389 ns/op >> Base64Decode.testBase64MIMEDecode 4 512 avgt 10 4000.725 ? 2.519 ns/op >> Base64Decode.testBase64MIMEDecode 4 1000 avgt 10 7674.994 ? 9.281 ns/op >> Base64Decode.testBase64MIMEDecode 4 20000 avgt 10 142059.001 ? 157.920 ns/op >> Base64Decode.testBase64MIMEDecode 4 50000 avgt 10 355698.369 ? 216.542 ns/op > > Dong Bo has updated the pull request incrementally with one additional commit since the last revision: > > reduce unnecessary memory write traffic in non-SIMD code Marked as reviewed by aph (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3228 From dongbo at openjdk.java.net Thu Apr 8 09:08:17 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Thu, 8 Apr 2021 09:08:17 GMT Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v7] In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 08:28:53 GMT, Andrew Haley wrote: >> Dong Bo has updated the pull request incrementally with one additional commit since the last revision: >> >> reduce unnecessary memory write traffic in non-SIMD code > > Marked as reviewed by aph (Reviewer). @theRealAph Thanks for the review. Hi @nick-arm, are you also ok with the newest commit? ------------- PR: https://git.openjdk.java.net/jdk/pull/3228 From ngasson at openjdk.java.net Thu Apr 8 09:13:09 2021 From: ngasson at openjdk.java.net (Nick Gasson) Date: Thu, 8 Apr 2021 09:13:09 GMT Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v7] In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 06:33:43 GMT, Dong Bo wrote: >> In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding. >> Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic idea can be found at http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords. >> >> Patch passed jtreg tier1-3 tests with linux-aarch64-server-fastdebug build. >> Tests in `test/jdk/java/util/Base64/` and `compiler/intrinsics/base64/TestBase64.java` runned specially for the correctness of the implementation. >> >> There can be illegal characters at the start of the input if the data is MIME encoded. >> It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now. >> >> A JMH micro, Base64Decode.java, is added for performance test. >> With different input length (upper-bounded by parameter `maxNumBytes` in the JMH micro), >> we witness ~2.5x improvements with long inputs and no regression with short inputs for raw base64 decodeing, minor improvements (~10.95%) for MIME on Kunpeng916. >> >> The Base64Decode.java JMH micro-benchmark results: >> >> Benchmark (lineSize) (maxNumBytes) Mode Cnt Score Error Units >> >> # Kunpeng916, intrinsic >> Base64Decode.testBase64Decode 4 1 avgt 5 48.614 ? 0.609 ns/op >> Base64Decode.testBase64Decode 4 3 avgt 5 58.199 ? 1.650 ns/op >> Base64Decode.testBase64Decode 4 7 avgt 5 69.400 ? 0.931 ns/op >> Base64Decode.testBase64Decode 4 32 avgt 5 96.818 ? 1.687 ns/op >> Base64Decode.testBase64Decode 4 64 avgt 5 122.856 ? 9.217 ns/op >> Base64Decode.testBase64Decode 4 80 avgt 5 130.935 ? 1.667 ns/op >> Base64Decode.testBase64Decode 4 96 avgt 5 143.627 ? 1.751 ns/op >> Base64Decode.testBase64Decode 4 112 avgt 5 152.311 ? 1.178 ns/op >> Base64Decode.testBase64Decode 4 512 avgt 5 342.631 ? 0.584 ns/op >> Base64Decode.testBase64Decode 4 1000 avgt 5 573.635 ? 1.050 ns/op >> Base64Decode.testBase64Decode 4 20000 avgt 5 9534.136 ? 45.172 ns/op >> Base64Decode.testBase64Decode 4 50000 avgt 5 22718.726 ? 192.070 ns/op >> Base64Decode.testBase64MIMEDecode 4 1 avgt 10 63.558 ? 0.336 ns/op >> Base64Decode.testBase64MIMEDecode 4 3 avgt 10 82.504 ? 0.848 ns/op >> Base64Decode.testBase64MIMEDecode 4 7 avgt 10 120.591 ? 0.608 ns/op >> Base64Decode.testBase64MIMEDecode 4 32 avgt 10 324.314 ? 6.236 ns/op >> Base64Decode.testBase64MIMEDecode 4 64 avgt 10 532.678 ? 4.670 ns/op >> Base64Decode.testBase64MIMEDecode 4 80 avgt 10 678.126 ? 4.324 ns/op >> Base64Decode.testBase64MIMEDecode 4 96 avgt 10 771.603 ? 6.393 ns/op >> Base64Decode.testBase64MIMEDecode 4 112 avgt 10 889.608 ? 0.759 ns/op >> Base64Decode.testBase64MIMEDecode 4 512 avgt 10 3663.557 ? 3.422 ns/op >> Base64Decode.testBase64MIMEDecode 4 1000 avgt 10 7017.784 ? 9.128 ns/op >> Base64Decode.testBase64MIMEDecode 4 20000 avgt 10 128670.660 ? 7951.521 ns/op >> Base64Decode.testBase64MIMEDecode 4 50000 avgt 10 317113.667 ? 161.758 ns/op >> >> # Kunpeng916, default >> Base64Decode.testBase64Decode 4 1 avgt 5 48.455 ? 0.571 ns/op >> Base64Decode.testBase64Decode 4 3 avgt 5 57.937 ? 0.505 ns/op >> Base64Decode.testBase64Decode 4 7 avgt 5 73.823 ? 1.452 ns/op >> Base64Decode.testBase64Decode 4 32 avgt 5 106.484 ? 1.243 ns/op >> Base64Decode.testBase64Decode 4 64 avgt 5 141.004 ? 1.188 ns/op >> Base64Decode.testBase64Decode 4 80 avgt 5 156.284 ? 0.572 ns/op >> Base64Decode.testBase64Decode 4 96 avgt 5 174.137 ? 0.177 ns/op >> Base64Decode.testBase64Decode 4 112 avgt 5 188.445 ? 0.572 ns/op >> Base64Decode.testBase64Decode 4 512 avgt 5 610.847 ? 1.559 ns/op >> Base64Decode.testBase64Decode 4 1000 avgt 5 1155.368 ? 0.813 ns/op >> Base64Decode.testBase64Decode 4 20000 avgt 5 19751.477 ? 24.669 ns/op >> Base64Decode.testBase64Decode 4 50000 avgt 5 50046.586 ? 523.155 ns/op >> Base64Decode.testBase64MIMEDecode 4 1 avgt 10 64.130 ? 0.238 ns/op >> Base64Decode.testBase64MIMEDecode 4 3 avgt 10 82.096 ? 0.205 ns/op >> Base64Decode.testBase64MIMEDecode 4 7 avgt 10 118.849 ? 0.610 ns/op >> Base64Decode.testBase64MIMEDecode 4 32 avgt 10 331.177 ? 4.732 ns/op >> Base64Decode.testBase64MIMEDecode 4 64 avgt 10 549.117 ? 0.177 ns/op >> Base64Decode.testBase64MIMEDecode 4 80 avgt 10 702.951 ? 4.572 ns/op >> Base64Decode.testBase64MIMEDecode 4 96 avgt 10 799.566 ? 0.301 ns/op >> Base64Decode.testBase64MIMEDecode 4 112 avgt 10 923.749 ? 0.389 ns/op >> Base64Decode.testBase64MIMEDecode 4 512 avgt 10 4000.725 ? 2.519 ns/op >> Base64Decode.testBase64MIMEDecode 4 1000 avgt 10 7674.994 ? 9.281 ns/op >> Base64Decode.testBase64MIMEDecode 4 20000 avgt 10 142059.001 ? 157.920 ns/op >> Base64Decode.testBase64MIMEDecode 4 50000 avgt 10 355698.369 ? 216.542 ns/op > > Dong Bo has updated the pull request incrementally with one additional commit since the last revision: > > reduce unnecessary memory write traffic in non-SIMD code Marked as reviewed by ngasson (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3228 From ngasson at openjdk.java.net Thu Apr 8 09:13:09 2021 From: ngasson at openjdk.java.net (Nick Gasson) Date: Thu, 8 Apr 2021 09:13:09 GMT Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v7] In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 09:05:43 GMT, Dong Bo wrote: > Hi @nick-arm, are you also ok with the newest commit? It looks ok to me but I'm not a Reviewer. ------------- PR: https://git.openjdk.java.net/jdk/pull/3228 From david.holmes at oracle.com Thu Apr 8 09:48:38 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 8 Apr 2021 19:48:38 +1000 Subject: RFR: 8259242: vmTestbase/vm/mlvm/mixed/stress/java/findDeadlock/TestDescription.java timed out In-Reply-To: References: <88mUXjYGWsrhiXxlkanE11_g8d6A0eppyxwOCyrCZ5Y=.93e091b7-8739-4934-acc1-57d5cd133455@github.com> <2jPlaBgIHX4F2zQcME2D2W2dJQuTbSWamQ_VLoBJiZE=.d374d4b8-e89e-4c8f-ba24-866f82c4f47d@github.com> Message-ID: <74fa0aa4-6984-6416-a5f1-f91aaa244ced@oracle.com> On 7/04/2021 10:30 pm, Coleen Phillimore wrote: > On Wed, 7 Apr 2021 11:55:56 GMT, Coleen Phillimore wrote: > >>> src/hotspot/share/classfile/protectionDomainCache.hpp line 115: >>> >>>> 113: >>>> 114: ProtectionDomainEntry* next() { return Atomic::load(&_next); } >>>> 115: void set_next(ProtectionDomainEntry* entry) { Atomic::store(&_next, entry); } >>> >>> Again these may need to be load_acquire/release_store for correct lock-free traversal. With suitable name changes for the methods. >> >> Thanks, I'll add acquire/release and change the names to match the implementation details. > > Did we collectively agree on the naming convention that set_next has to be release_set_next because the implementation uses release_store, or is this just your preference? I find this noisy in the context where these functions are being called. Yes that is the convention that was established and in place for a number of fields. Thanks, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3362 > From david.holmes at oracle.com Thu Apr 8 09:52:16 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 8 Apr 2021 19:52:16 +1000 Subject: RFR: 8259242: vmTestbase/vm/mlvm/mixed/stress/java/findDeadlock/TestDescription.java timed out In-Reply-To: References: <88mUXjYGWsrhiXxlkanE11_g8d6A0eppyxwOCyrCZ5Y=.93e091b7-8739-4934-acc1-57d5cd133455@github.com> Message-ID: <3bcd67bc-8e2d-50b2-7ef0-8d1598b2e265@oracle.com> On 7/04/2021 10:05 pm, Coleen Phillimore wrote: > On Wed, 7 Apr 2021 04:55:35 GMT, David Holmes wrote: > >>> This change makes the DictionaryEntry pd_set lock free, because when I set a low SafepointTimeout on the findDeadlock test, these threads were waiting on the ProtectionDomainSet_lock. This lock is a singleton that's taken for every dictionary entry. >>> >>> I don't know if this change will make the test never timeout again, because removing this lock caused us to hit a low SafepointTimeout on another _no_safepoint_check lock that is not so easy to eradictate. >>> >>> Tested with tiers 1-3. There's a test that exercises this code in runtime/Dictionary/ProtectionDomainCacheTest.java. >> >> Hi Coleen, >> >> Can you explain the synchronization protocol you are using here please - I don't understand how the handshake fits into it ?? >> >> Further comments below. >> >> Thanks, >> David > > The lock-free algorithm is based on the one for object monitors, except that adding and deleting entries is done with the SystemDictionary_lock held, reading entries is done with a (now) Atomic load acquires etc with no safepoint polls, and deleting the entries is done by saving the entries off to the side, until a handshake is reached, meaning none of the readers are reading the old version of the list. I really don't see why we need to use handshakes here. The writers use a lock, and use release_stores. The readers use load_acquire. Our normal lock-free data structures don't need handshakes to be involved, so sorry but I'm not getting it. Thanks, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3362 > From dholmes at openjdk.java.net Thu Apr 8 10:13:21 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 8 Apr 2021 10:13:21 GMT Subject: RFR: 8264711: More runtime TRAPS cleanups [v4] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 14:19:50 GMT, Harold Seigel wrote: >> Please review this additional cleanup of use of TRAPS in hotspot runtime code. The changes were tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows and Mach5 tiers 3-5 on Linux x64. >> >> Thanks, Harold > > Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: > > remove unneeded statement Hi Harold, Updates seem fine. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3345 From david.holmes at oracle.com Thu Apr 8 10:19:21 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 8 Apr 2021 20:19:21 +1000 Subject: RFR: 8264881: Remove the old development option MemProfiling In-Reply-To: References: <4FP-BKxopk1Sto9DXzCdTSB4soCqNJQrbie6G4c3718=.d42fb986-e2de-41bd-a920-8743d016b51e@github.com> Message-ID: On 8/04/2021 4:04 pm, Yi Yang wrote: > On Thu, 8 Apr 2021 05:38:56 GMT, David Holmes wrote: >> The UseNewCode flags are there as a development aid so that you can >> conditionally enable changed logic during development without needing to >> add a new runtime flag just for that. It can be very useful for gating >> changes when doing performance runs. No code ever gets committed that >> actually uses them though. >> >> So no, please do not delete them. :) >> >> Thanks, >> David > > Got it. Thank you David, you are the OpenJDK encyclopedia. :) > (PS: it looks like they are wrongly marked as product flags) No that is deliberate as well. Lets say I'm doing a performance test on two variants of a fix. I use UseNewCode to select between them, but I want to do the performance run on a product build. Cheers, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3393 > From coleenp at openjdk.java.net Thu Apr 8 11:49:16 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 8 Apr 2021 11:49:16 GMT Subject: RFR: 8264881: Remove the old development option MemProfiling In-Reply-To: <4FP-BKxopk1Sto9DXzCdTSB4soCqNJQrbie6G4c3718=.d42fb986-e2de-41bd-a920-8743d016b51e@github.com> References: <4FP-BKxopk1Sto9DXzCdTSB4soCqNJQrbie6G4c3718=.d42fb986-e2de-41bd-a920-8743d016b51e@github.com> Message-ID: On Thu, 8 Apr 2021 03:19:21 GMT, Yi Yang wrote: > MemProfiler is a very old development option added at: > > ^As 00018/00000/00000 > ^Ad D 1.1 98/04/14 13:18:32 renes 1 0 > ^Ac date and time created 98/04/14 13:18:32 by renes > ^Ae > > Today it doesn't work because it is untested and there is no reason/scenario to prove it is useful. > > After a short discussion in https://github.com/openjdk/jdk/pull/3340, I'd like to propose removing the memprofiler if there are no strong objections. > > Thanks! > Yang Thank you for finding and removing this code. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3393 From coleenp at openjdk.java.net Thu Apr 8 11:57:18 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 8 Apr 2021 11:57:18 GMT Subject: RFR: 8259242: vmTestbase/vm/mlvm/mixed/stress/java/findDeadlock/TestDescription.java timed out [v2] In-Reply-To: References: <88mUXjYGWsrhiXxlkanE11_g8d6A0eppyxwOCyrCZ5Y=.93e091b7-8739-4934-acc1-57d5cd133455@github.com> Message-ID: On Wed, 7 Apr 2021 12:02:44 GMT, Coleen Phillimore wrote: >> Hi Coleen, >> >> Can you explain the synchronization protocol you are using here please - I don't understand how the handshake fits into it ?? >> >> Further comments below. >> >> Thanks, >> David > > The lock-free algorithm is based on the one for object monitors, except that adding and deleting entries is done with the SystemDictionary_lock held, reading entries is done with a (now) Atomic load acquires etc with no safepoint polls, and deleting the entries is done by saving the entries off to the side, until a handshake is reached, meaning none of the readers are reading the old version of the list. The reader thread could be using the linked list and have just loaded -> next, while the deleting thread also has loaded -> next, deciding it's unused and calling delete on it. The reader is then swapped back in the process and looks at the _pd_cache field which was deleted or the _next field which is will point to the delete pattern. When we call 'delete' on a node in this list, we have to make sure that nothing is reading it. The concurrent hashtable uses globalCounter for this situation. Many of our lock free data structures delete entries in safepoints (like dictionaries). This pd_set list does the same as the ObjectMonitor code. The handshake is rare as I said in the comments. The protection domain is generally associated with the klass in the initiating loader, which stays alive while this class is alive. ------------- PR: https://git.openjdk.java.net/jdk/pull/3362 From hseigel at openjdk.java.net Thu Apr 8 12:16:20 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 8 Apr 2021 12:16:20 GMT Subject: RFR: 8264711: More runtime TRAPS cleanups [v4] In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 10:10:00 GMT, David Holmes wrote: >> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision: >> >> remove unneeded statement > > Hi Harold, > > Updates seem fine. > > Thanks, > David Thanks Lois, Patricio, David, and Dan for reviewing this! ------------- PR: https://git.openjdk.java.net/jdk/pull/3345 From hseigel at openjdk.java.net Thu Apr 8 12:16:21 2021 From: hseigel at openjdk.java.net (Harold Seigel) Date: Thu, 8 Apr 2021 12:16:21 GMT Subject: Integrated: 8264711: More runtime TRAPS cleanups In-Reply-To: References: Message-ID: <3YKOgP4x6Fu-oS7-x_SuhvhDLWG3vH1cVzjNzKTHc6A=.5ffc2a72-2d23-46d1-9738-e59f318c636a@github.com> On Mon, 5 Apr 2021 17:57:13 GMT, Harold Seigel wrote: > Please review this additional cleanup of use of TRAPS in hotspot runtime code. The changes were tested with Mach5 tiers 1-2 on Linux, Mac OS, and Windows and Mach5 tiers 3-5 on Linux x64. > > Thanks, Harold This pull request has now been integrated. Changeset: af13c64f Author: Harold Seigel URL: https://git.openjdk.java.net/jdk/commit/af13c64f Stats: 97 lines in 26 files changed: 1 ins; 13 del; 83 mod 8264711: More runtime TRAPS cleanups Reviewed-by: lfoltan, pchilanomate, dholmes, dcubed ------------- PR: https://git.openjdk.java.net/jdk/pull/3345 From lucy at openjdk.java.net Thu Apr 8 13:40:15 2021 From: lucy at openjdk.java.net (Lutz Schmidt) Date: Thu, 8 Apr 2021 13:40:15 GMT Subject: Integrated: 8264848: [macos] libjvm.dylib linker warning due to macOS version mismatch In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 16:32:52 GMT, Lutz Schmidt wrote: > May I please request reviews for this small build fix. It removes a linker warning by adding a assembly-time parameter which was previously missing. The same parameter is used at c++ compile time. This pull request has now been integrated. Changeset: 04fa1ed4 Author: Lutz Schmidt URL: https://git.openjdk.java.net/jdk/commit/04fa1ed4 Stats: 11 lines in 1 file changed: 10 ins; 0 del; 1 mod 8264848: [macos] libjvm.dylib linker warning due to macOS version mismatch Reviewed-by: erikj, dcubed, clanger ------------- PR: https://git.openjdk.java.net/jdk/pull/3379 From kvn at openjdk.java.net Thu Apr 8 15:32:40 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 8 Apr 2021 15:32:40 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler Message-ID: As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: - `jdk.aot` module ? the `jaotc` tool - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution - related HotSpot code guarded by `#if INCLUDE_AOT` Additionally, remove tests as well as code in makefiles related to AoT compilation. Tested hs-tier1-4 ------------- Commit messages: - 8264805: Remove the experimental Ahead-of-Time Compiler Changes: https://git.openjdk.java.net/jdk/pull/3398/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3398&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264805 Stats: 26903 lines in 375 files changed: 4 ins; 26703 del; 196 mod Patch: https://git.openjdk.java.net/jdk/pull/3398.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3398/head:pull/3398 PR: https://git.openjdk.java.net/jdk/pull/3398 From gziemski at openjdk.java.net Thu Apr 8 15:33:25 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Thu, 8 Apr 2021 15:33:25 GMT Subject: RFR: 8264543: Cross modify fence optimization for x86 In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 23:14:44 GMT, Xubo Zhang wrote: > Intel introduced a new instruction ?serialize? which ensures that all modifications to flags, registers, and memory by previous instructions are completed and all buffered writes are drained to memory before the next instruction is fetched and executed. It is a serializing instruction and can be used to implement cross modify fence (OrderAccess::cross_modify_fence_impl) more efficiently than using ?cpuid? on supported 32-bit and 64-bit x86 platforms. > > The availability of the SERIALIZE instruction is indicated by the presence of the CPUID feature flag SERIALIZE, bit 14 of the EDX register in sub-leaf CPUID:7H.0H. > > https://software.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html If this is an optimization, do you have any numbers that show an improvement with this change? ------------- PR: https://git.openjdk.java.net/jdk/pull/3334 From kvn at openjdk.java.net Thu Apr 8 15:58:39 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 8 Apr 2021 15:58:39 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v2] In-Reply-To: References: Message-ID: > As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: > > - `jdk.aot` module ? the `jaotc` tool > - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution > - related HotSpot code guarded by `#if INCLUDE_AOT` > > Additionally, remove tests as well as code in makefiles related to AoT compilation. > > Tested hs-tier1-4 Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Merge branch 'master' into JDK-8264805 - 8264805: Remove the experimental Ahead-of-Time Compiler ------------- Changes: https://git.openjdk.java.net/jdk/pull/3398/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3398&range=01 Stats: 26906 lines in 375 files changed: 4 ins; 26709 del; 193 mod Patch: https://git.openjdk.java.net/jdk/pull/3398.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3398/head:pull/3398 PR: https://git.openjdk.java.net/jdk/pull/3398 From kvn at openjdk.java.net Thu Apr 8 16:17:33 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 8 Apr 2021 16:17:33 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v3] In-Reply-To: References: Message-ID: > As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: > > - `jdk.aot` module ? the `jaotc` tool > - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution > - related HotSpot code guarded by `#if INCLUDE_AOT` > > Additionally, remove tests as well as code in makefiles related to AoT compilation. > > Tested hs-tier1-4 Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge branch 'master' into JDK-8264805 - Merge branch 'master' into JDK-8264805 - 8264805: Remove the experimental Ahead-of-Time Compiler ------------- Changes: https://git.openjdk.java.net/jdk/pull/3398/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3398&range=02 Stats: 26906 lines in 375 files changed: 4 ins; 26709 del; 193 mod Patch: https://git.openjdk.java.net/jdk/pull/3398.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3398/head:pull/3398 PR: https://git.openjdk.java.net/jdk/pull/3398 From kvn at openjdk.java.net Thu Apr 8 17:24:38 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 8 Apr 2021 17:24:38 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4] In-Reply-To: References: Message-ID: > As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: > > - `jdk.aot` module ? the `jaotc` tool > - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution > - related HotSpot code guarded by `#if INCLUDE_AOT` > > Additionally, remove tests as well as code in makefiles related to AoT compilation. > > Tested hs-tier1-4 Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: Remove exports from Graal module to jdk.aot ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3398/files - new: https://git.openjdk.java.net/jdk/pull/3398/files/3dbc6210..6cce0f6c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3398&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3398&range=02-03 Stats: 39 lines in 3 files changed: 0 ins; 36 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3398.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3398/head:pull/3398 PR: https://git.openjdk.java.net/jdk/pull/3398 From coleenp at openjdk.java.net Thu Apr 8 19:35:06 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 8 Apr 2021 19:35:06 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 15:23:52 GMT, Vladimir Kozlov wrote: > As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: > > - `jdk.aot` module ? the `jaotc` tool > - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution > - related HotSpot code guarded by `#if INCLUDE_AOT` > > Additionally, remove tests as well as code in makefiles related to AoT compilation. > > Tested hs-tier1-4 void CodeCache::mark_for_evol_deoptimization(InstanceKlass* dependee) { This function, its caller and the function in jvmtiRedefineClasses.cpp that calls it can be deleted also, but you can file a separate RFE for that if you want. ------------- PR: https://git.openjdk.java.net/jdk/pull/3398 From coleenp at openjdk.java.net Thu Apr 8 19:42:06 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 8 Apr 2021 19:42:06 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4] In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov wrote: >> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: >> >> - `jdk.aot` module ? the `jaotc` tool >> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution >> - related HotSpot code guarded by `#if INCLUDE_AOT` >> >> Additionally, remove tests as well as code in makefiles related to AoT compilation. >> >> Tested hs-tier1-4 > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Remove exports from Graal module to jdk.aot I looked at the changes in oops, runtime, classfile and code directories. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3398 From erikj at openjdk.java.net Thu Apr 8 19:54:07 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 8 Apr 2021 19:54:07 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4] In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov wrote: >> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: >> >> - `jdk.aot` module ? the `jaotc` tool >> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution >> - related HotSpot code guarded by `#if INCLUDE_AOT` >> >> Additionally, remove tests as well as code in makefiles related to AoT compilation. >> >> Tested hs-tier1-4 > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Remove exports from Graal module to jdk.aot Build changes look good. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3398 From stefank at openjdk.java.net Thu Apr 8 20:04:07 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Thu, 8 Apr 2021 20:04:07 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4] In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov wrote: >> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: >> >> - `jdk.aot` module ? the `jaotc` tool >> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution >> - related HotSpot code guarded by `#if INCLUDE_AOT` >> >> Additionally, remove tests as well as code in makefiles related to AoT compilation. >> >> Tested hs-tier1-4 > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Remove exports from Graal module to jdk.aot GC changes look good. ------------- Marked as reviewed by stefank (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3398 From kvn at openjdk.java.net Thu Apr 8 20:04:08 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 8 Apr 2021 20:04:08 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4] In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 19:58:11 GMT, Stefan Karlsson wrote: >> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove exports from Graal module to jdk.aot > > GC changes look good. > void CodeCache::mark_for_evol_deoptimization(InstanceKlass* dependee) { > This function, its caller and the function in jvmtiRedefineClasses.cpp that calls it can be deleted also, but you can file a separate RFE for that if you want. Thank you, Coleen, for review. I will wait other comments and will remove this code. ------------- PR: https://git.openjdk.java.net/jdk/pull/3398 From kvn at openjdk.java.net Thu Apr 8 20:04:08 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 8 Apr 2021 20:04:08 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4] In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 20:00:30 GMT, Vladimir Kozlov wrote: >> GC changes look good. > >> void CodeCache::mark_for_evol_deoptimization(InstanceKlass* dependee) { >> This function, its caller and the function in jvmtiRedefineClasses.cpp that calls it can be deleted also, but you can file a separate RFE for that if you want. > > Thank you, Coleen, for review. I will wait other comments and will remove this code. Thank you, Erik and Stefan. ------------- PR: https://git.openjdk.java.net/jdk/pull/3398 From dcubed at openjdk.java.net Thu Apr 8 20:18:07 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Thu, 8 Apr 2021 20:18:07 GMT Subject: RFR: 8259242: vmTestbase/vm/mlvm/mixed/stress/java/findDeadlock/TestDescription.java timed out [v2] In-Reply-To: <2jPlaBgIHX4F2zQcME2D2W2dJQuTbSWamQ_VLoBJiZE=.d374d4b8-e89e-4c8f-ba24-866f82c4f47d@github.com> References: <88mUXjYGWsrhiXxlkanE11_g8d6A0eppyxwOCyrCZ5Y=.93e091b7-8739-4934-acc1-57d5cd133455@github.com> <2jPlaBgIHX4F2zQcME2D2W2dJQuTbSWamQ_VLoBJiZE=.d374d4b8-e89e-4c8f-ba24-866f82c4f47d@github.com> Message-ID: On Wed, 7 Apr 2021 11:55:19 GMT, Coleen Phillimore wrote: >> src/hotspot/share/classfile/protectionDomainCache.cpp line 89: >> >>> 87: // If there are any deleted entries, Handshake-all then they'll be >>> 88: // safe to remove since traversing the pd_set list does not stop for >>> 89: // safepoints and only JavaThreads will read the pd_set. >> >> I do not understand what you are trying to do here. This is basically a no-op handshake with every thread? Does all the threads remain in the handshake until the last one is processed or do they proceed through one at a time? The former seems better suited for a safepoint operation. The latter means this doesn't work as they may have moved on to a new removal. > > Only the ServiceThread calls this code, so they won't be removed again. This is modeled after the ObjectMonitor code that does the same thing. All the threads have to hit a handshake at a safepoint polling place, which they cannot do while reading the list. After all the threads have hit the handshake, no thread can see the old entries on the list. > I thought that's what I said in the comment. What should I say to make this clearer? See src/hotspot/share/runtime/synchronizer.cpp: size_t ObjectSynchronizer::deflate_idle_monitors() { if (current->is_Java_thread()) { // A JavaThread needs to handshake in order to safely free the // ObjectMonitors that were deflated in this cycle. HandshakeForDeflation hfd_hc; Handshake::execute(&hfd_hc); ------------- PR: https://git.openjdk.java.net/jdk/pull/3362 From iignatyev at openjdk.java.net Thu Apr 8 20:31:11 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 8 Apr 2021 20:31:11 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4] In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov wrote: >> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: >> >> - `jdk.aot` module ? the `jaotc` tool >> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution >> - related HotSpot code guarded by `#if INCLUDE_AOT` >> >> Additionally, remove tests as well as code in makefiles related to AoT compilation. >> >> Tested hs-tier1-4 > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Remove exports from Graal module to jdk.aot Test changes look good to me. ------------- Marked as reviewed by iignatyev (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3398 From coleenp at openjdk.java.net Thu Apr 8 21:03:07 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 8 Apr 2021 21:03:07 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4] In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 20:28:27 GMT, Igor Ignatyev wrote: >> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove exports from Graal module to jdk.aot > > Test changes look good to me. There's a comment above void VM_RedefineClasses::mark_dependent_code(InstanceKlass* ik) { that should be rewritten, so I think we should just file an RFE to remove it afterwards. ------------- PR: https://git.openjdk.java.net/jdk/pull/3398 From pchilanomate at openjdk.java.net Thu Apr 8 21:10:10 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Thu, 8 Apr 2021 21:10:10 GMT Subject: RFR: 8259242: vmTestbase/vm/mlvm/mixed/stress/java/findDeadlock/TestDescription.java timed out [v2] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 12:39:19 GMT, Coleen Phillimore wrote: >> This change makes the DictionaryEntry pd_set reads lock free, because when I set a low SafepointTimeout on the findDeadlock test, these threads were waiting on the ProtectionDomainSet_lock. This lock is a singleton that's taken for every dictionary entry. >> >> I don't know if this change will make the test never timeout again, because removing this lock caused us to hit a low SafepointTimeout on another _no_safepoint_check lock that is not so easy to eradictate. >> >> Tested with tiers 1-3. There's a test that exercises this code in runtime/Dictionary/ProtectionDomainCacheTest.java. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Add acquire/release and update names. Hi Coleen, Changes LGTM. Some comments below: src/hotspot/share/classfile/dictionary.cpp line 92: > 90: // This doesn't require a lock because nothing is reading this > 91: // entry anymore. The ClassLoader is dead. > 92: if (entry->pd_set_acquire() != NULL) { I think this should still be a 'while' to remove the whole list. src/hotspot/share/classfile/protectionDomainCache.cpp line 93: > 91: // with the caller class and class loader, which if still alive will keep this > 92: // protection domain entry alive. > 93: if (delete_list->length() != 0) { If you want you could also use a threshold to decide when to issue the handshake, to avoid triggering it for very few entries (given removals seem to be rare already). See is_async_deflation_needed() for example. src/hotspot/share/classfile/protectionDomainCache.cpp line 211: > 209: } > 210: > 211: extra line? ------------- PR: https://git.openjdk.java.net/jdk/pull/3362 From gziemski at openjdk.java.net Thu Apr 8 21:56:22 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Thu, 8 Apr 2021 21:56:22 GMT Subject: RFR: 8262328: Templatize JVMFlag boilerplate access methods [v3] In-Reply-To: <90k6XitD4HHsJ4Ysooht5KF1Iqcfzhy0cwQZelpo8zg=.29771578-30e0-4fd7-b5af-b50383de6598@github.com> References: <90k6XitD4HHsJ4Ysooht5KF1Iqcfzhy0cwQZelpo8zg=.29771578-30e0-4fd7-b5af-b50383de6598@github.com> Message-ID: On Thu, 8 Apr 2021 02:04:09 GMT, David Holmes wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> reinstated JVMFlagAccess::set_{bool,int,uint,...} functions for better readability > > Hi Ioi, > > This latest version looks good to me. > > Thanks, > David I'm taking a look at your fix Ioi. Building it locally, wanted to check out a few things... ------------- PR: https://git.openjdk.java.net/jdk/pull/3318 From kvn at openjdk.java.net Thu Apr 8 21:57:07 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 8 Apr 2021 21:57:07 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4] In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 20:59:59 GMT, Coleen Phillimore wrote: > There's a comment above > void VM_RedefineClasses::mark_dependent_code(InstanceKlass* ik) { > that should be rewritten, so I think we should just file an RFE to remove it afterwards. https://bugs.openjdk.java.net/browse/JDK-8264941 ------------- PR: https://git.openjdk.java.net/jdk/pull/3398 From coleenp at openjdk.java.net Thu Apr 8 23:09:49 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 8 Apr 2021 23:09:49 GMT Subject: RFR: 8259242: Remove ProtectionDomainSet_lock [v3] In-Reply-To: References: Message-ID: > This change makes the DictionaryEntry pd_set reads lock free, because when I set a low SafepointTimeout on the findDeadlock test, these threads were waiting on the ProtectionDomainSet_lock. This lock is a singleton that's taken for every dictionary entry. > > I don't know if this change will make the test never timeout again, because removing this lock caused us to hit a low SafepointTimeout on another _no_safepoint_check lock that is not so easy to eradictate. > > Tested with tiers 1-3. There's a test that exercises this code in runtime/Dictionary/ProtectionDomainCacheTest.java. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Make ProtectionDomainEntry delete list global and set a threshold for deletions before handshaking. Fix if to when. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3362/files - new: https://git.openjdk.java.net/jdk/pull/3362/files/40c359b1..06624ed1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3362&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3362&range=01-02 Stats: 24 lines in 3 files changed: 11 ins; 1 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/3362.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3362/head:pull/3362 PR: https://git.openjdk.java.net/jdk/pull/3362 From coleenp at openjdk.java.net Thu Apr 8 23:09:52 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 8 Apr 2021 23:09:52 GMT Subject: RFR: 8259242: Remove ProtectionDomainSet_lock [v2] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 12:39:19 GMT, Coleen Phillimore wrote: >> This change makes the DictionaryEntry pd_set reads lock free, because when I set a low SafepointTimeout on the findDeadlock test, these threads were waiting on the ProtectionDomainSet_lock. This lock is a singleton that's taken for every dictionary entry. >> >> I don't know if this change will make the test never timeout again, because removing this lock caused us to hit a low SafepointTimeout on another _no_safepoint_check lock that is not so easy to eradictate. >> >> Tested with tiers 1-3. There's a test that exercises this code in runtime/Dictionary/ProtectionDomainCacheTest.java. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Add acquire/release and update names. Thank you for reviewing, Patricio. ------------- PR: https://git.openjdk.java.net/jdk/pull/3362 From coleenp at openjdk.java.net Thu Apr 8 23:09:53 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 8 Apr 2021 23:09:53 GMT Subject: RFR: 8259242: Remove ProtectionDomainSet_lock [v2] In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 23:02:19 GMT, Coleen Phillimore wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Add acquire/release and update names. > > Thank you for reviewing, Patricio. I renamed this bug and pull request. ------------- PR: https://git.openjdk.java.net/jdk/pull/3362 From coleenp at openjdk.java.net Thu Apr 8 23:09:58 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Thu, 8 Apr 2021 23:09:58 GMT Subject: RFR: 8259242: Remove ProtectionDomainSet_lock [v2] In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 20:18:21 GMT, Patricio Chilano Mateo wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Add acquire/release and update names. > > src/hotspot/share/classfile/dictionary.cpp line 92: > >> 90: // This doesn't require a lock because nothing is reading this >> 91: // entry anymore. The ClassLoader is dead. >> 92: if (entry->pd_set_acquire() != NULL) { > > I think this should still be a 'while' to remove the whole list. You're right, thank you for finding this. I was going to rewrite this to call a function so I can access _next directly. > src/hotspot/share/classfile/protectionDomainCache.cpp line 93: > >> 91: // with the caller class and class loader, which if still alive will keep this >> 92: // protection domain entry alive. >> 93: if (delete_list->length() != 0) { > > If you want you could also use a threshold to decide when to issue the handshake, to avoid triggering it for very few entries (given removals seem to be rare already). See is_async_deflation_needed() for example. I wanted to avoid making delete_list global and CHeap allocated. I could do that and make the threshold 20. > src/hotspot/share/classfile/protectionDomainCache.cpp line 211: > >> 209: } >> 210: >> 211: > > extra line? removed. ------------- PR: https://git.openjdk.java.net/jdk/pull/3362 From dongbo at openjdk.java.net Fri Apr 9 01:31:21 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Fri, 9 Apr 2021 01:31:21 GMT Subject: Integrated: 8256245: AArch64: Implement Base64 decoding intrinsic In-Reply-To: References: Message-ID: On Sat, 27 Mar 2021 08:58:03 GMT, Dong Bo wrote: > In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding. > Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic idea can be found at http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords. > > Patch passed jtreg tier1-3 tests with linux-aarch64-server-fastdebug build. > Tests in `test/jdk/java/util/Base64/` and `compiler/intrinsics/base64/TestBase64.java` runned specially for the correctness of the implementation. > > There can be illegal characters at the start of the input if the data is MIME encoded. > It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now. > > A JMH micro, Base64Decode.java, is added for performance test. > With different input length (upper-bounded by parameter `maxNumBytes` in the JMH micro), > we witness ~2.5x improvements with long inputs and no regression with short inputs for raw base64 decodeing, minor improvements (~10.95%) for MIME on Kunpeng916. > > The Base64Decode.java JMH micro-benchmark results: > > Benchmark (lineSize) (maxNumBytes) Mode Cnt Score Error Units > > # Kunpeng916, intrinsic > Base64Decode.testBase64Decode 4 1 avgt 5 48.614 ? 0.609 ns/op > Base64Decode.testBase64Decode 4 3 avgt 5 58.199 ? 1.650 ns/op > Base64Decode.testBase64Decode 4 7 avgt 5 69.400 ? 0.931 ns/op > Base64Decode.testBase64Decode 4 32 avgt 5 96.818 ? 1.687 ns/op > Base64Decode.testBase64Decode 4 64 avgt 5 122.856 ? 9.217 ns/op > Base64Decode.testBase64Decode 4 80 avgt 5 130.935 ? 1.667 ns/op > Base64Decode.testBase64Decode 4 96 avgt 5 143.627 ? 1.751 ns/op > Base64Decode.testBase64Decode 4 112 avgt 5 152.311 ? 1.178 ns/op > Base64Decode.testBase64Decode 4 512 avgt 5 342.631 ? 0.584 ns/op > Base64Decode.testBase64Decode 4 1000 avgt 5 573.635 ? 1.050 ns/op > Base64Decode.testBase64Decode 4 20000 avgt 5 9534.136 ? 45.172 ns/op > Base64Decode.testBase64Decode 4 50000 avgt 5 22718.726 ? 192.070 ns/op > Base64Decode.testBase64MIMEDecode 4 1 avgt 10 63.558 ? 0.336 ns/op > Base64Decode.testBase64MIMEDecode 4 3 avgt 10 82.504 ? 0.848 ns/op > Base64Decode.testBase64MIMEDecode 4 7 avgt 10 120.591 ? 0.608 ns/op > Base64Decode.testBase64MIMEDecode 4 32 avgt 10 324.314 ? 6.236 ns/op > Base64Decode.testBase64MIMEDecode 4 64 avgt 10 532.678 ? 4.670 ns/op > Base64Decode.testBase64MIMEDecode 4 80 avgt 10 678.126 ? 4.324 ns/op > Base64Decode.testBase64MIMEDecode 4 96 avgt 10 771.603 ? 6.393 ns/op > Base64Decode.testBase64MIMEDecode 4 112 avgt 10 889.608 ? 0.759 ns/op > Base64Decode.testBase64MIMEDecode 4 512 avgt 10 3663.557 ? 3.422 ns/op > Base64Decode.testBase64MIMEDecode 4 1000 avgt 10 7017.784 ? 9.128 ns/op > Base64Decode.testBase64MIMEDecode 4 20000 avgt 10 128670.660 ? 7951.521 ns/op > Base64Decode.testBase64MIMEDecode 4 50000 avgt 10 317113.667 ? 161.758 ns/op > > # Kunpeng916, default > Base64Decode.testBase64Decode 4 1 avgt 5 48.455 ? 0.571 ns/op > Base64Decode.testBase64Decode 4 3 avgt 5 57.937 ? 0.505 ns/op > Base64Decode.testBase64Decode 4 7 avgt 5 73.823 ? 1.452 ns/op > Base64Decode.testBase64Decode 4 32 avgt 5 106.484 ? 1.243 ns/op > Base64Decode.testBase64Decode 4 64 avgt 5 141.004 ? 1.188 ns/op > Base64Decode.testBase64Decode 4 80 avgt 5 156.284 ? 0.572 ns/op > Base64Decode.testBase64Decode 4 96 avgt 5 174.137 ? 0.177 ns/op > Base64Decode.testBase64Decode 4 112 avgt 5 188.445 ? 0.572 ns/op > Base64Decode.testBase64Decode 4 512 avgt 5 610.847 ? 1.559 ns/op > Base64Decode.testBase64Decode 4 1000 avgt 5 1155.368 ? 0.813 ns/op > Base64Decode.testBase64Decode 4 20000 avgt 5 19751.477 ? 24.669 ns/op > Base64Decode.testBase64Decode 4 50000 avgt 5 50046.586 ? 523.155 ns/op > Base64Decode.testBase64MIMEDecode 4 1 avgt 10 64.130 ? 0.238 ns/op > Base64Decode.testBase64MIMEDecode 4 3 avgt 10 82.096 ? 0.205 ns/op > Base64Decode.testBase64MIMEDecode 4 7 avgt 10 118.849 ? 0.610 ns/op > Base64Decode.testBase64MIMEDecode 4 32 avgt 10 331.177 ? 4.732 ns/op > Base64Decode.testBase64MIMEDecode 4 64 avgt 10 549.117 ? 0.177 ns/op > Base64Decode.testBase64MIMEDecode 4 80 avgt 10 702.951 ? 4.572 ns/op > Base64Decode.testBase64MIMEDecode 4 96 avgt 10 799.566 ? 0.301 ns/op > Base64Decode.testBase64MIMEDecode 4 112 avgt 10 923.749 ? 0.389 ns/op > Base64Decode.testBase64MIMEDecode 4 512 avgt 10 4000.725 ? 2.519 ns/op > Base64Decode.testBase64MIMEDecode 4 1000 avgt 10 7674.994 ? 9.281 ns/op > Base64Decode.testBase64MIMEDecode 4 20000 avgt 10 142059.001 ? 157.920 ns/op > Base64Decode.testBase64MIMEDecode 4 50000 avgt 10 355698.369 ? 216.542 ns/op This pull request has now been integrated. Changeset: 77b16739 Author: Dong Bo Committer: Fei Yang URL: https://git.openjdk.java.net/jdk/commit/77b16739 Stats: 436 lines in 3 files changed: 436 ins; 0 del; 0 mod 8256245: AArch64: Implement Base64 decoding intrinsic Reviewed-by: aph, ngasson ------------- PR: https://git.openjdk.java.net/jdk/pull/3228 From yyang at openjdk.java.net Fri Apr 9 02:12:14 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Fri, 9 Apr 2021 02:12:14 GMT Subject: RFR: 8264644: Add PrintClassLoaderDataGraphAtExit to print the detailed CLD graph [v3] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 05:10:29 GMT, David Holmes wrote: >> Yi Yang has updated the pull request incrementally with two additional commits since the last revision: >> >> - add CLDG_lock >> - use PTR_FORMAT > > A couple of minor nits. > > Thanks, > David Hi @dholmes-ora , how about my latest update? If you think it's okay, I would like to integrate it. ------------- PR: https://git.openjdk.java.net/jdk/pull/3323 From yyang at openjdk.java.net Fri Apr 9 02:13:15 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Fri, 9 Apr 2021 02:13:15 GMT Subject: RFR: 8264881: Remove the old development option MemProfiling In-Reply-To: References: <4FP-BKxopk1Sto9DXzCdTSB4soCqNJQrbie6G4c3718=.d42fb986-e2de-41bd-a920-8743d016b51e@github.com> Message-ID: On Thu, 8 Apr 2021 05:38:56 GMT, David Holmes wrote: >> MemProfiler is a very old development option added at: >> >> ^As 00018/00000/00000 >> ^Ad D 1.1 98/04/14 13:18:32 renes 1 0 >> ^Ac date and time created 98/04/14 13:18:32 by renes >> ^Ae >> >> Today it doesn't work because it is untested and there is no reason/scenario to prove it is useful. >> >> After a short discussion in https://github.com/openjdk/jdk/pull/3340, I'd like to propose removing the memprofiler if there are no strong objections. >> >> Thanks! >> Yang > > Hi Yi, > > Actual code removal looks good. > > Thanks, > David Thanks @dholmes-ora @coleenp for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/3393 From dholmes at openjdk.java.net Fri Apr 9 02:21:12 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 9 Apr 2021 02:21:12 GMT Subject: RFR: 8259242: Remove ProtectionDomainSet_lock [v3] In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 23:09:49 GMT, Coleen Phillimore wrote: >> This change makes the DictionaryEntry pd_set reads lock free, because when I set a low SafepointTimeout on the findDeadlock test, these threads were waiting on the ProtectionDomainSet_lock. This lock is a singleton that's taken for every dictionary entry. >> >> I don't know if this change will make the test never timeout again, because removing this lock caused us to hit a low SafepointTimeout on another _no_safepoint_check lock that is not so easy to eradictate. >> >> Tested with tiers 1-3. There's a test that exercises this code in runtime/Dictionary/ProtectionDomainCacheTest.java. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Make ProtectionDomainEntry delete list global and set a threshold for deletions before handshaking. Fix if to when. Hi Coleen, Thanks for the additional explanations about the synchronization protocol that is being used. The use of the global handshake with the OM deletion had not really registered with me as a general technique that we would employ for safe-memory-reclamation. (I'm not sure if I find it cool or scary! :) ) So to summarise the protocol: - the pd_set can only be set and appended to when the lock is held - traversal of a pd_set is lock-free - removal from a pd_set is a two phase process: - 1. Under the lock move the entry to the global delete list - 2. When appropriate the serviceThread will process the delete list, by first handshaking all threads, and then iterating through and deleting the entries We know an entry cannot be in-use when deleted because that implies a traversal is in progress, but if a traversal is in progress then the handshake cannot have happened. Is that correct? I would like to see this high-level description as a block comment somewhere for clarity, as the individual pieces of code seem spread around and it is not easy (for me) to see the connections when just reading the code. Thanks, David src/hotspot/share/classfile/dictionary.cpp line 148: > 146: "can only be called by a JavaThread or at safepoint"); > 147: // This cannot safepoint while reading the protection domain set. > 148: NoSafepointVerifier nsv; Does this implicitly also mean NoHandshakeVerifier? Or do we need a seperate NHV? src/hotspot/share/classfile/dictionary.cpp line 455: > 453: prev->release_set_next(current->next_acquire()); > 454: } > 455: delete_list->push(current); Suggested comment before this: // Mark current for deletion, but in the meantime it can still be traversed It is important that current is not unlinked so that in-progress traversals do not break. Though to be honest I'm unclear exactly what triggers the clearing of an entry this way. src/hotspot/share/classfile/dictionary.cpp line 560: > 558: void DictionaryEntry::print_count(outputStream *st) { > 559: int count = 0; > 560: for (ProtectionDomainEntry* current = pd_set_acquire(); // accessed inside SD lock Can the end-of-line comment get promoted to a full line comment before the loop - or even an assert that the lock is held. src/hotspot/share/classfile/protectionDomainCache.cpp line 116: > 114: _delete_list = new (ResourceObj::C_HEAP, mtClass) > 115: GrowableArray(20, mtClass); > 116: } What is protecting this code to ensure the allocation can only happen once? ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3362 From dholmes at openjdk.java.net Fri Apr 9 02:34:19 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 9 Apr 2021 02:34:19 GMT Subject: RFR: 8264644: Add PrintClassLoaderDataGraphAtExit to print the detailed CLD graph [v4] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 06:48:52 GMT, Yi Yang wrote: >> Trivial chanage to make debugging happy, now cld->print() would be: >> >> ClassLoaderData(0x00007ff17432b670) >> - name 'platform' >> - holder WeakHandle: 0x00000007fef56678 >> - class loader 0x7ff17432b828 >> - metaspace 0x7ff17468a0b0 >> - unloading false >> - class mirror holder false >> - modified oops true >> - keep alive 0 >> - claim strong >> - handles 43 >> - dependency count 0 >> - klasses {java.sql.SQLFeatureNotSupportedException,java.sql.SQLNonTransientException,java.sql.SQLException,sun.util.resources.provider.NonBaseLocaleDataMetaInfo,org.ietf.jgss.GSSException,javax.sql.DataSource,java.sql.Wrapper,javax.sql.CommonDataSource,java.sql.Time,java.sql.Date,java.sql.Timestamp,sun.util.resources.cldr.provider.CLDRLocaleDataMetaInfo, } >> - packages 0x7ff17432bc20 >> - module 0x7ff17432c520 >> - unnamed module 0x7ff17432c3d0 >> - dictionary 0x7ff17432c470 >> - deallocate list 0x7ff0a4023bd0 > > Yi Yang has updated the pull request incrementally with one additional commit since the last revision: > > INTPTR_FORMAT Looks good. Sorry for the delay. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3323 From yyang at openjdk.java.net Fri Apr 9 02:39:13 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Fri, 9 Apr 2021 02:39:13 GMT Subject: RFR: 8264644: Add PrintClassLoaderDataGraphAtExit to print the detailed CLD graph [v4] In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 02:31:43 GMT, David Holmes wrote: >> Yi Yang has updated the pull request incrementally with one additional commit since the last revision: >> >> INTPTR_FORMAT > > Looks good. Sorry for the delay. > > Thanks, > David Thank you Coleen and David~ ------------- PR: https://git.openjdk.java.net/jdk/pull/3323 From dholmes at openjdk.java.net Fri Apr 9 04:35:15 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 9 Apr 2021 04:35:15 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4] In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov wrote: >> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: >> >> - `jdk.aot` module ? the `jaotc` tool >> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution >> - related HotSpot code guarded by `#if INCLUDE_AOT` >> >> Additionally, remove tests as well as code in makefiles related to AoT compilation. >> >> Tested hs-tier1-4 > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Remove exports from Graal module to jdk.aot Hi Vladimir, This looks good to me - I went through all the files. It was nice to see how nicely compartmentalized the AOT feature was - that made checking the changes quite simple. The one exception was the fingerprinting code, which for some reason was AOT-only but not marked that way, so I'm not sure what the story is there. ?? I was also surprised to see some of the flags were not marked experimental, so there will need to a CSR request to remove those without going through the normal deprecation process. Thanks, David src/hotspot/cpu/x86/compiledIC_x86.cpp line 134: > 132: #ifdef ASSERT > 133: CodeBlob *cb = CodeCache::find_blob_unsafe((address) _call); > 134: assert(cb, "sanity"); Nit: implied boolean - use "cb != NULL" src/hotspot/share/memory/heap.hpp line 174: > 172: bool contains(const void* p) const { return low() <= p && p < high(); } > 173: bool contains_blob(const CodeBlob* blob) const { > 174: const void* start = (void*)blob; start seems redundant now ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3398 From dholmes at openjdk.java.net Fri Apr 9 04:59:07 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 9 Apr 2021 04:59:07 GMT Subject: RFR: 8264868: Reduce inclusion of registerMap.hpp and register.hpp In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 21:03:10 GMT, Ioi Lam wrote: > Register.hpp is included 815 times, and registerMap.hpp is include 862 times (out of about 1000 HotSpot .o files). > > This can be reduced by refactoring the popular header file **frame.hpp**, so that it doesn't include registerMap.hpp anymore. This reduces the number of .o files that include register.hpp to 612, and that of registerMap.hpp to 109. > > The total number of lines of C++ code compiled for HotSpot is reduced by about 0.5%. Hi Ioi, It isn't at all obvious to me how the stackFrameStream refactoring relates to the topic of this RFE. :) But I don't see anything amiss, and if it improves build time etc, then it seems fine. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3384 From iklam at openjdk.java.net Fri Apr 9 05:45:24 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 9 Apr 2021 05:45:24 GMT Subject: RFR: 8264868: Reduce inclusion of registerMap.hpp and register.hpp In-Reply-To: References: Message-ID: <_n-nvDr_g2QoByrwZP8beV9gCRPkyZIprPEDxfkzQ84=.933cdd3b-2ad5-45fd-bb41-b93aecb343b2@github.com> On Fri, 9 Apr 2021 04:56:32 GMT, David Holmes wrote: > Hi Ioi, > > It isn't at all obvious to me how the stackFrameStream refactoring relates to the topic of this RFE. :) > > But I don't see anything amiss, and if it improves build time etc, then it seems fine. > > Thanks, > David Thanks for the review! `StackFrameStream` was the only thing in frame.hpp that needed to use `RegisterMap`. Since `StackFrameStream` is used by only 15 .o files, I moved it to its own header file. This makes possible to decouple frame.hpp with registerMap.hpp. ------------- PR: https://git.openjdk.java.net/jdk/pull/3384 From david.holmes at oracle.com Fri Apr 9 06:17:52 2021 From: david.holmes at oracle.com (David Holmes) Date: Fri, 9 Apr 2021 16:17:52 +1000 Subject: RFR: 8264868: Reduce inclusion of registerMap.hpp and register.hpp In-Reply-To: <_n-nvDr_g2QoByrwZP8beV9gCRPkyZIprPEDxfkzQ84=.933cdd3b-2ad5-45fd-bb41-b93aecb343b2@github.com> References: <_n-nvDr_g2QoByrwZP8beV9gCRPkyZIprPEDxfkzQ84=.933cdd3b-2ad5-45fd-bb41-b93aecb343b2@github.com> Message-ID: <62691bf8-1cf2-e310-cd87-fa5cfdc8d0d6@oracle.com> On 9/04/2021 3:45 pm, Ioi Lam wrote: > On Fri, 9 Apr 2021 04:56:32 GMT, David Holmes wrote: > >> Hi Ioi, >> >> It isn't at all obvious to me how the stackFrameStream refactoring relates to the topic of this RFE. :) >> >> But I don't see anything amiss, and if it improves build time etc, then it seems fine. >> >> Thanks, >> David > > Thanks for the review! > > `StackFrameStream` was the only thing in frame.hpp that needed to use `RegisterMap`. Since `StackFrameStream` is used by only 15 .o files, I moved it to its own header file. This makes possible to decouple frame.hpp with registerMap.hpp. Ah! Got it. Thanks, David > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3384 > From yyang at openjdk.java.net Fri Apr 9 06:26:16 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Fri, 9 Apr 2021 06:26:16 GMT Subject: Integrated: 8264881: Remove the old development option MemProfiling In-Reply-To: <4FP-BKxopk1Sto9DXzCdTSB4soCqNJQrbie6G4c3718=.d42fb986-e2de-41bd-a920-8743d016b51e@github.com> References: <4FP-BKxopk1Sto9DXzCdTSB4soCqNJQrbie6G4c3718=.d42fb986-e2de-41bd-a920-8743d016b51e@github.com> Message-ID: On Thu, 8 Apr 2021 03:19:21 GMT, Yi Yang wrote: > MemProfiler is a very old development option added at: > > ^As 00018/00000/00000 > ^Ad D 1.1 98/04/14 13:18:32 renes 1 0 > ^Ac date and time created 98/04/14 13:18:32 by renes > ^Ae > > Today it doesn't work because it is untested and there is no reason/scenario to prove it is useful. > > After a short discussion in https://github.com/openjdk/jdk/pull/3340, I'd like to propose removing the memprofiler if there are no strong objections. > > Thanks! > Yang This pull request has now been integrated. Changeset: 666fd62e Author: Yi Yang Committer: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/666fd62e Stats: 201 lines in 8 files changed: 0 ins; 201 del; 0 mod 8264881: Remove the old development option MemProfiling Reviewed-by: dholmes, coleenp, shade ------------- PR: https://git.openjdk.java.net/jdk/pull/3393 From shade at openjdk.java.net Fri Apr 9 06:26:16 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 9 Apr 2021 06:26:16 GMT Subject: RFR: 8264881: Remove the old development option MemProfiling In-Reply-To: <4FP-BKxopk1Sto9DXzCdTSB4soCqNJQrbie6G4c3718=.d42fb986-e2de-41bd-a920-8743d016b51e@github.com> References: <4FP-BKxopk1Sto9DXzCdTSB4soCqNJQrbie6G4c3718=.d42fb986-e2de-41bd-a920-8743d016b51e@github.com> Message-ID: On Thu, 8 Apr 2021 03:19:21 GMT, Yi Yang wrote: > MemProfiler is a very old development option added at: > > ^As 00018/00000/00000 > ^Ad D 1.1 98/04/14 13:18:32 renes 1 0 > ^Ac date and time created 98/04/14 13:18:32 by renes > ^Ae > > Today it doesn't work because it is untested and there is no reason/scenario to prove it is useful. > > After a short discussion in https://github.com/openjdk/jdk/pull/3340, I'd like to propose removing the memprofiler if there are no strong objections. > > Thanks! > Yang Looks fine to me as well. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3393 From shade at openjdk.java.net Fri Apr 9 06:27:23 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 9 Apr 2021 06:27:23 GMT Subject: RFR: 8264513: Cleanup CardTableBarrierSetC2::post_barrier In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 07:18:01 GMT, Thomas Schatzl wrote: >> There are few stale comments after CMS removal. We can also clean up some coding, while we are at it. > > Lgtm. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/3285 From shade at openjdk.java.net Fri Apr 9 06:27:24 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 9 Apr 2021 06:27:24 GMT Subject: Integrated: 8264513: Cleanup CardTableBarrierSetC2::post_barrier In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 13:46:47 GMT, Aleksey Shipilev wrote: > There are few stale comments after CMS removal. We can also clean up some coding, while we are at it. This pull request has now been integrated. Changeset: 1c6b1134 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/1c6b1134 Stats: 20 lines in 1 file changed: 5 ins; 5 del; 10 mod 8264513: Cleanup CardTableBarrierSetC2::post_barrier Reviewed-by: tschatzl ------------- PR: https://git.openjdk.java.net/jdk/pull/3285 From thartmann at openjdk.java.net Fri Apr 9 07:04:24 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Fri, 9 Apr 2021 07:04:24 GMT Subject: RFR: 8264649: runtime/InternalApi/ThreadCpuTimesDeadlock.java crash in fastdebug C2 with -XX:-UseTLAB [v2] In-Reply-To: References: Message-ID: <-63abPXoiWhcD8FhNKDptvxLVKYCLjKW5WtAGKUVg4U=.9b9367a3-202f-418c-b049-dad477aa6f2f@github.com> On Wed, 7 Apr 2021 12:09:05 GMT, Hui Shi wrote: >> Please help review this fix. Detailed analysis in https://bugs.openjdk.java.net/browse/JDK-8264649 >> >> Tier1/2 release /fastdebug passed > > Hui Shi has updated the pull request incrementally with one additional commit since the last revision: > > fix typo in test description Thanks for the details. Your fix looks reasonable to me. ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3336 From aph at openjdk.java.net Fri Apr 9 08:18:18 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Fri, 9 Apr 2021 08:18:18 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4] In-Reply-To: References: Message-ID: <7ioJ2_GFIK53zxpqFcYLt9LYDd8WS7ronekRuo6O5Ac=.572d87d5-2f1f-41cf-8c9b-6d018926f0cf@github.com> On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov wrote: >> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: >> >> - `jdk.aot` module ? the `jaotc` tool >> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution >> - related HotSpot code guarded by `#if INCLUDE_AOT` >> >> Additionally, remove tests as well as code in makefiles related to AoT compilation. >> >> Tested hs-tier1-4 > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Remove exports from Graal module to jdk.aot AArch64 looks fine. ------------- Marked as reviewed by aph (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3398 From xliu at openjdk.java.net Fri Apr 9 08:38:03 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Fri, 9 Apr 2021 08:38:03 GMT Subject: RFR: 8229517: Support for optional asynchronous/buffered logging [v3] In-Reply-To: References: Message-ID: > This patch provides a buffer to store asynchrounous messages and flush them to > underlying files periodically. Xin Liu has updated the pull request incrementally with three additional commits since the last revision: - fix runtime/logging/RedefineClasses.java crashed with -XX:+AsyncLogging nmethod::print(outputStream* st) should not obtain tty_lock by assuming st is defaultStream. It could be logStream as well. Currently, AyncLogFlusher::_lock has the same rank of tty_lock. https://issues.amazon.com/issues/JVM-563 - 8229517: Support for optional asynchronous/buffered logging Move LogAsyncFlusher from WatcherThread to a standalone NonJavaThread https://issues.amazon.com/issues/JVM-565 - 8229517: Support for optional asynchronous/buffered logging re-introduce the global option AsyncLogging. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3135/files - new: https://git.openjdk.java.net/jdk/pull/3135/files/bcefbecb..81b2a0cb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3135&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3135&range=01-02 Stats: 113 lines in 9 files changed: 74 ins; 22 del; 17 mod Patch: https://git.openjdk.java.net/jdk/pull/3135.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3135/head:pull/3135 PR: https://git.openjdk.java.net/jdk/pull/3135 From xliu at openjdk.java.net Fri Apr 9 08:38:06 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Fri, 9 Apr 2021 08:38:06 GMT Subject: RFR: 8229517: Support for optional asynchronous/buffered logging [v3] In-Reply-To: References: Message-ID: On Fri, 26 Mar 2021 08:47:04 GMT, Volker Simonis wrote: >> Xin Liu has updated the pull request incrementally with three additional commits since the last revision: >> >> - fix runtime/logging/RedefineClasses.java crashed with -XX:+AsyncLogging >> >> nmethod::print(outputStream* st) should not obtain tty_lock by assuming >> st is defaultStream. It could be logStream as well. >> >> Currently, AyncLogFlusher::_lock has the same rank of tty_lock. >> https://issues.amazon.com/issues/JVM-563 >> - 8229517: Support for optional asynchronous/buffered logging >> >> Move LogAsyncFlusher from WatcherThread to a standalone NonJavaThread >> https://issues.amazon.com/issues/JVM-565 >> - 8229517: Support for optional asynchronous/buffered logging >> >> re-introduce the global option AsyncLogging. > > src/hotspot/share/logging/logFileOutput.cpp line 50: > >> 48: : LogFileStreamOutput(NULL), _name(os::strdup_check_oom(name, mtLogging)), >> 49: _file_name(NULL), _archive_name(NULL), _current_file(0), >> 50: _file_count(DefaultFileCount), _is_default_file_count(true), _async_mode(AsyncLogging), _archive_name_len(0), > > See comments on `globals.hpp`. No need for an extra option. Make this `false` by default. > > And can you please also add the `_async_mode` to the following log trace in `LogFileOutput::initialize()`: > log_trace(logging)("Initializing logging to file '%s' (filecount: %u" > ", filesize: " SIZE_FORMAT " KiB).", > _file_name, _file_count, _rotate_size / K); ack. I will add some log_traces for asynclogflusher and this. ------------- PR: https://git.openjdk.java.net/jdk/pull/3135 From shade at openjdk.java.net Fri Apr 9 08:54:18 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 9 Apr 2021 08:54:18 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4] In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov wrote: >> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: >> >> - `jdk.aot` module ? the `jaotc` tool >> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution >> - related HotSpot code guarded by `#if INCLUDE_AOT` >> >> Additionally, remove tests as well as code in makefiles related to AoT compilation. >> >> Tested hs-tier1-4 > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Remove exports from Graal module to jdk.aot Shenandoah parts look good. I have a few minor comments after reading the rest. src/hotspot/cpu/x86/globalDefinitions_x86.hpp line 73: > 71: > 72: #if INCLUDE_JVMCI > 73: #define COMPRESSED_CLASS_POINTERS_DEPENDS_ON_COMPRESSED_OOPS (EnableJVMCI) Minor nit: can probably drop parentheses here. src/hotspot/share/code/compiledIC.cpp line 715: > 713: tty->print("interpreted"); > 714: } else { > 715: tty->print("unknown"); We can probably split this cleanup into the minor issue, your call. The benefit of separate issue: backportability. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3398 From whuang at openjdk.java.net Fri Apr 9 10:25:41 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Fri, 9 Apr 2021 10:25:41 GMT Subject: RFR: 8264940: java/lang/invoke/6998541/Test6998541.java failed "guarantee(ik->is_initialized()) failed: java/lang/Byte$ByteCache must be initialized" Message-ID: <-17CHkPMQoZhr9gsnQ_1UvBDFAYUlaXCBFLQ7dGPK6g=.ebce6503-4974-41cc-8635-3b0168f02fe8@github.com> * The main reason is that in this situation the `BoxCache` is not initialized before `uncommon_trap`. * `java.lang.Byte$ByteCache` is loaded without initializing here * I think that all `*Cache` classes should be loaded in this situation. ------------- Commit messages: - 8264940: java/lang/invoke/6998541/Test6998541.java failed "guarantee(ik->is_initialized()) failed: java/lang/Byte$ByteCache must be initialized" Changes: https://git.openjdk.java.net/jdk/pull/3411/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3411&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264940 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3411.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3411/head:pull/3411 PR: https://git.openjdk.java.net/jdk/pull/3411 From coleenp at openjdk.java.net Fri Apr 9 10:59:17 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 9 Apr 2021 10:59:17 GMT Subject: RFR: 8259242: Remove ProtectionDomainSet_lock [v3] In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 01:44:41 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Make ProtectionDomainEntry delete list global and set a threshold for deletions before handshaking. Fix if to when. > > src/hotspot/share/classfile/dictionary.cpp line 148: > >> 146: "can only be called by a JavaThread or at safepoint"); >> 147: // This cannot safepoint while reading the protection domain set. >> 148: NoSafepointVerifier nsv; > > Does this implicitly also mean NoHandshakeVerifier? Or do we need a seperate NHV? It does mean the same thing in that we check for handshakes where we'd check for safepoints, and that what NSV detects. ------------- PR: https://git.openjdk.java.net/jdk/pull/3362 From coleenp at openjdk.java.net Fri Apr 9 11:04:27 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 9 Apr 2021 11:04:27 GMT Subject: RFR: 8259242: Remove ProtectionDomainSet_lock [v3] In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 01:53:04 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Make ProtectionDomainEntry delete list global and set a threshold for deletions before handshaking. Fix if to when. > > src/hotspot/share/classfile/dictionary.cpp line 560: > >> 558: void DictionaryEntry::print_count(outputStream *st) { >> 559: int count = 0; >> 560: for (ProtectionDomainEntry* current = pd_set_acquire(); // accessed inside SD lock > > Can the end-of-line comment get promoted to a full line comment before the loop - or even an assert that the lock is held. Ok, I added an assert instead. This logging at pd_set creation time is sort of useless, but it's useful at PrintSystemDictionaryAtExit time. > src/hotspot/share/classfile/protectionDomainCache.cpp line 116: > >> 114: _delete_list = new (ResourceObj::C_HEAP, mtClass) >> 115: GrowableArray(20, mtClass); >> 116: } > > What is protecting this code to ensure the allocation can only happen once? Yes. This functions is only called from the service thread. ------------- PR: https://git.openjdk.java.net/jdk/pull/3362 From coleenp at openjdk.java.net Fri Apr 9 11:13:10 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 9 Apr 2021 11:13:10 GMT Subject: RFR: 8259242: Remove ProtectionDomainSet_lock [v3] In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 02:17:29 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Make ProtectionDomainEntry delete list global and set a threshold for deletions before handshaking. Fix if to when. > > src/hotspot/share/classfile/dictionary.cpp line 455: > >> 453: prev->release_set_next(current->next_acquire()); >> 454: } >> 455: delete_list->push(current); > > Suggested comment before this: > // Mark current for deletion, but in the meantime it can still be traversed > > It is important that current is not unlinked so that in-progress traversals do not break. Though to be honest I'm unclear exactly what triggers the clearing of an entry this way. I added the comment. The service thread could be trying to remove this entry and there's a small chance that some class loading will be looking up this entry with SystemDictionary::find_instance_klass. // First clean cached pd lists in loaded CLDs // It's unlikely, but some loaded classes in a dictionary might // point to a protection_domain that has been unloaded. // The dictionary pd_set points at entries in the ProtectionDomainCacheTable. There's a test runtime/Dictionary/ProtectionDomainCache.java that does this. It creates a protection domain with a jar file loading with a URL class loader that's then removed. The defining class loader of the class loaded has that protection domain in its pd_set. ------------- PR: https://git.openjdk.java.net/jdk/pull/3362 From coleenp at openjdk.java.net Fri Apr 9 11:34:20 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 9 Apr 2021 11:34:20 GMT Subject: RFR: 8259242: Remove ProtectionDomainSet_lock [v3] In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 02:17:53 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Make ProtectionDomainEntry delete list global and set a threshold for deletions before handshaking. Fix if to when. > > Hi Coleen, > > Thanks for the additional explanations about the synchronization protocol that is being used. The use of the global handshake with the OM deletion had not really registered with me as a general technique that we would employ for safe-memory-reclamation. (I'm not sure if I find it cool or scary! :) ) > > So to summarise the protocol: > - the pd_set can only be set and appended to when the lock is held > - traversal of a pd_set is lock-free > - removal from a pd_set is a two phase process: > - 1. Under the lock move the entry to the global delete list > - 2. When appropriate the serviceThread will process the delete list, by first handshaking all threads, and then iterating through and deleting the entries > > We know an entry cannot be in-use when deleted because that implies a traversal is in progress, but if a traversal is in progress then the handshake cannot have happened. > > Is that correct? > > I would like to see this high-level description as a block comment somewhere for clarity, as the individual pieces of code seem spread around and it is not easy (for me) to see the connections when just reading the code. > > Thanks, > David Hi David, Yes you have the design correct. It's used for ObjectMonitors, nmethod unloading, implicitly class unloading with ZGC, and now this. The concurrent hashtable uses the globalCounter mechanism, which I briefly considered but it would have required more surgery to the code and would slightly affect read times, and that mechanism is more complicated imo. I could have done something with a lock bit/refcount for readers but that's more error prone and harder to get right. There's a new lockFreeQueue.hpp implementation but this wasn't a queue. Maybe this should be generalized to be lockFreeList sometime. I put a block comment before Dictionary::contains_protection_domain, the lock free reader with the NSV which describes the protocol. Hopefully this is clear. Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/3362 From coleenp at openjdk.java.net Fri Apr 9 11:43:22 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 9 Apr 2021 11:43:22 GMT Subject: RFR: 8264940: java/lang/invoke/6998541/Test6998541.java failed "guarantee(ik->is_initialized()) failed: java/lang/Byte$ByteCache must be initialized" In-Reply-To: <-17CHkPMQoZhr9gsnQ_1UvBDFAYUlaXCBFLQ7dGPK6g=.ebce6503-4974-41cc-8635-3b0168f02fe8@github.com> References: <-17CHkPMQoZhr9gsnQ_1UvBDFAYUlaXCBFLQ7dGPK6g=.ebce6503-4974-41cc-8635-3b0168f02fe8@github.com> Message-ID: On Fri, 9 Apr 2021 10:15:57 GMT, Wang Huang wrote: > * The main reason is that in this situation the `BoxCache` is not initialized before `uncommon_trap`. > * `java.lang.Byte$ByteCache` is loaded without initializing here > * I think that all `*Cache` classes should be loaded in this situation. Changes requested by coleenp (Reviewer). src/hotspot/share/runtime/deoptimization.cpp line 979: > 977: static BooleanBoxCache *_singleton; > 978: BooleanBoxCache(Thread *thread) { > 979: InstanceKlass* ik = find_cache_klass(java_lang_Boolean::symbol(), thread); If this throws a Java exception, you have to handle it here, you can't ignore it with thread. You should initialize these classes during initialization. You shouldn't be doing this in deoptimization. ------------- PR: https://git.openjdk.java.net/jdk/pull/3411 From dholmes at openjdk.java.net Fri Apr 9 12:01:13 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 9 Apr 2021 12:01:13 GMT Subject: RFR: 8264940: java/lang/invoke/6998541/Test6998541.java failed "guarantee(ik->is_initialized()) failed: java/lang/Byte$ByteCache must be initialized" In-Reply-To: References: <-17CHkPMQoZhr9gsnQ_1UvBDFAYUlaXCBFLQ7dGPK6g=.ebce6503-4974-41cc-8635-3b0168f02fe8@github.com> Message-ID: <5sr0T4XA92nZGjxReHoQhEbag23iYjPT-iVCsGNZwq8=.644a847b-8038-4cfb-8763-fb4586e4f0d2@github.com> On Fri, 9 Apr 2021 11:40:34 GMT, Coleen Phillimore wrote: >> * The main reason is that in this situation the `BoxCache` is not initialized before `uncommon_trap`. >> * `java.lang.Byte$ByteCache` is loaded without initializing here >> * I think that all `*Cache` classes should be loaded in this situation. > > Changes requested by coleenp (Reviewer). To evaluate what is the right fix for this problem I need to understand how JDK-8261137 caused the problem. Can you explain that please? When was this class normally initialized? Simply initializing the class at the point where you thought it already should have been initialized may not be the right solution, and as Coleen has pointed out you have to deal with any exceptions that may occur during that initialization. Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/3411 From coleenp at openjdk.java.net Fri Apr 9 12:06:38 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 9 Apr 2021 12:06:38 GMT Subject: RFR: 8259242: Remove ProtectionDomainSet_lock [v4] In-Reply-To: References: Message-ID: <2uEIJDc2SaYfQQJ9KBdLPIZoPTS5-Kem5HmYtMhlzaM=.f1bc6b04-0364-4d2c-b91b-a8098e4a2919@github.com> > This change makes the DictionaryEntry pd_set reads lock free, because when I set a low SafepointTimeout on the findDeadlock test, these threads were waiting on the ProtectionDomainSet_lock. This lock is a singleton that's taken for every dictionary entry. > > I don't know if this change will make the test never timeout again, because removing this lock caused us to hit a low SafepointTimeout on another _no_safepoint_check lock that is not so easy to eradictate. > > Tested with tiers 1-3. There's a test that exercises this code in runtime/Dictionary/ProtectionDomainCacheTest.java. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Add overall comment and assert in count function. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3362/files - new: https://git.openjdk.java.net/jdk/pull/3362/files/06624ed1..153eccd7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3362&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3362&range=02-03 Stats: 12 lines in 1 file changed: 11 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3362.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3362/head:pull/3362 PR: https://git.openjdk.java.net/jdk/pull/3362 From dholmes at openjdk.java.net Fri Apr 9 12:14:23 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 9 Apr 2021 12:14:23 GMT Subject: RFR: 8259242: Remove ProtectionDomainSet_lock [v4] In-Reply-To: <2uEIJDc2SaYfQQJ9KBdLPIZoPTS5-Kem5HmYtMhlzaM=.f1bc6b04-0364-4d2c-b91b-a8098e4a2919@github.com> References: <2uEIJDc2SaYfQQJ9KBdLPIZoPTS5-Kem5HmYtMhlzaM=.f1bc6b04-0364-4d2c-b91b-a8098e4a2919@github.com> Message-ID: On Fri, 9 Apr 2021 12:06:38 GMT, Coleen Phillimore wrote: >> This change makes the DictionaryEntry pd_set reads lock free, because when I set a low SafepointTimeout on the findDeadlock test, these threads were waiting on the ProtectionDomainSet_lock. This lock is a singleton that's taken for every dictionary entry. >> >> I don't know if this change will make the test never timeout again, because removing this lock caused us to hit a low SafepointTimeout on another _no_safepoint_check lock that is not so easy to eradictate. >> >> Tested with tiers 1-3. There's a test that exercises this code in runtime/Dictionary/ProtectionDomainCacheTest.java. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Add overall comment and assert in count function. Updates look good - thanks Coleen! David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3362 From pchilanomate at openjdk.java.net Fri Apr 9 14:54:19 2021 From: pchilanomate at openjdk.java.net (Patricio Chilano Mateo) Date: Fri, 9 Apr 2021 14:54:19 GMT Subject: RFR: 8259242: Remove ProtectionDomainSet_lock [v4] In-Reply-To: <2uEIJDc2SaYfQQJ9KBdLPIZoPTS5-Kem5HmYtMhlzaM=.f1bc6b04-0364-4d2c-b91b-a8098e4a2919@github.com> References: <2uEIJDc2SaYfQQJ9KBdLPIZoPTS5-Kem5HmYtMhlzaM=.f1bc6b04-0364-4d2c-b91b-a8098e4a2919@github.com> Message-ID: On Fri, 9 Apr 2021 12:06:38 GMT, Coleen Phillimore wrote: >> This change makes the DictionaryEntry pd_set reads lock free, because when I set a low SafepointTimeout on the findDeadlock test, these threads were waiting on the ProtectionDomainSet_lock. This lock is a singleton that's taken for every dictionary entry. >> >> I don't know if this change will make the test never timeout again, because removing this lock caused us to hit a low SafepointTimeout on another _no_safepoint_check lock that is not so easy to eradictate. >> >> Tested with tiers 1-3. There's a test that exercises this code in runtime/Dictionary/ProtectionDomainCacheTest.java. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Add overall comment and assert in count function. Looks good, thanks Coleen! ------------- Marked as reviewed by pchilanomate (Committer). PR: https://git.openjdk.java.net/jdk/pull/3362 From coleenp at openjdk.java.net Fri Apr 9 15:02:29 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 9 Apr 2021 15:02:29 GMT Subject: RFR: 8259242: Remove ProtectionDomainSet_lock [v4] In-Reply-To: References: <2uEIJDc2SaYfQQJ9KBdLPIZoPTS5-Kem5HmYtMhlzaM=.f1bc6b04-0364-4d2c-b91b-a8098e4a2919@github.com> Message-ID: <5Xy1Ijp7uixg3pZk9U4lR3vvZqmFzy9zp_ikiHevgdo=.e31d4f75-a298-4cb5-a9e9-e727c7f2a9c5@github.com> On Fri, 9 Apr 2021 14:51:04 GMT, Patricio Chilano Mateo wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Add overall comment and assert in count function. > > Looks good, thanks Coleen! Thank you Patricio and David! ------------- PR: https://git.openjdk.java.net/jdk/pull/3362 From coleenp at openjdk.java.net Fri Apr 9 15:02:29 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Fri, 9 Apr 2021 15:02:29 GMT Subject: Integrated: 8259242: Remove ProtectionDomainSet_lock In-Reply-To: References: Message-ID: <0GRKY6LsVgh8iopovyzAUPwksjtTAAYXVIHnYwEwsWE=.540142fb-026f-4e0b-b0ba-99f2ebf07510@github.com> On Tue, 6 Apr 2021 18:54:09 GMT, Coleen Phillimore wrote: > This change makes the DictionaryEntry pd_set reads lock free, because when I set a low SafepointTimeout on the findDeadlock test, these threads were waiting on the ProtectionDomainSet_lock. This lock is a singleton that's taken for every dictionary entry. > > I don't know if this change will make the test never timeout again, because removing this lock caused us to hit a low SafepointTimeout on another _no_safepoint_check lock that is not so easy to eradictate. > > Tested with tiers 1-3. There's a test that exercises this code in runtime/Dictionary/ProtectionDomainCacheTest.java. This pull request has now been integrated. Changeset: 06e6b1f7 Author: Coleen Phillimore URL: https://git.openjdk.java.net/jdk/commit/06e6b1f7 Stats: 162 lines in 10 files changed: 80 ins; 33 del; 49 mod 8259242: Remove ProtectionDomainSet_lock Reviewed-by: dholmes, pchilanomate ------------- PR: https://git.openjdk.java.net/jdk/pull/3362 From gziemski at openjdk.java.net Fri Apr 9 16:21:17 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Fri, 9 Apr 2021 16:21:17 GMT Subject: RFR: 8262328: Templatize JVMFlag boilerplate access methods [v3] In-Reply-To: References: Message-ID: On Tue, 6 Apr 2021 03:56:50 GMT, Ioi Lam wrote: >> We have a bunch of boilerplate method like: >> >> JVMFlagAccess::boolAtPut (JVMFlag* f, bool* v, JVMFlagOrigin origin) >> JVMFlagAccess::intAtPut (JVMFlag* f, int* v, JVMFlagOrigin origin) >> JVMFlagAccess::uintAtPut (JVMFlag* f, uint* v, JVMFlagOrigin origin) >> ... >> >> Similarly, we also have 8 different functions: JVMFlag::{set_bool, set_int, set_intx, ...} >> >> We should replace such patterns with >> >> template >> JVMFlagAccess::set(JVMFlag* f, T* value, JVMFlagOrigin origin) >> >> This would allow us to templatize the 8x boilerplate functions in writeableFlags.cpp. >> >> The flag access code in whitebox.cpp can also be improved. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > reinstated JVMFlagAccess::set_{bool,int,uint,...} functions for better readability Very nice! With all this reduction and "templatization" effort, soon we will be left with one line of a template code at this rate :-) The only feedback I have is that I wish we could replace `int type_enum` with `FlagType type_enum` ------------- Marked as reviewed by gziemski (Committer). PR: https://git.openjdk.java.net/jdk/pull/3318 From iveresov at openjdk.java.net Fri Apr 9 16:41:20 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 9 Apr 2021 16:41:20 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4] In-Reply-To: References: Message-ID: <32eWo34nJ7czxicNNgoww6GpOpg0jKq8NZY_pPeQPpI=.e698cb8a-78e7-40a2-b54e-9b29ce1bedb1@github.com> On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov wrote: >> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: >> >> - `jdk.aot` module ? the `jaotc` tool >> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution >> - related HotSpot code guarded by `#if INCLUDE_AOT` >> >> Additionally, remove tests as well as code in makefiles related to AoT compilation. >> >> Tested hs-tier1-4 > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Remove exports from Graal module to jdk.aot src/hotspot/share/jvmci/jvmciCodeInstaller.cpp line 1184: > 1182: } > 1183: } else if (jvmci_env()->isa_HotSpotMetaspaceConstantImpl(constant)) { > 1184: if (!_immutable_pic_compilation) { All _immutable_pic_compilation mentions can be removed as well. It is true only for AOT compiles produced by Graal. It's never going to be used without AOT. src/hotspot/share/oops/instanceKlass.hpp line 257: > 255: _misc_declares_nonstatic_concrete_methods = 1 << 6, // directly declares non-static, concrete methods > 256: _misc_has_been_redefined = 1 << 7, // class has been redefined > 257: _unused = 1 << 8, // Any particular reason we don't want to remove this gap? ------------- PR: https://git.openjdk.java.net/jdk/pull/3398 From iklam at openjdk.java.net Fri Apr 9 16:42:21 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 9 Apr 2021 16:42:21 GMT Subject: RFR: 8262328: Templatize JVMFlag boilerplate access methods [v3] In-Reply-To: References: Message-ID: <4RmcvUiJTMLRNzjPkKm-8R4F_bUwnlhvWmgsrxi-TbQ=.907c7ee6-1bc8-404a-a6a2-046f8be5f566@github.com> On Fri, 9 Apr 2021 16:17:53 GMT, Gerard Ziemski wrote: > Very nice! With all this reduction and "templatization" effort, soon we will be left with one line of a template code at this rate :-) > > The only feedback I have is that I wish we could replace `int type_enum` with `FlagType type_enum` Hi Gerard, thanks for the review. Replacing the int with enum will cause quite a bit of changes, so I would probably do that in a separate RFE. ------------- PR: https://git.openjdk.java.net/jdk/pull/3318 From iklam at openjdk.java.net Fri Apr 9 16:58:23 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 9 Apr 2021 16:58:23 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4] In-Reply-To: References: Message-ID: <3zISek5YyT0zkmPX3UZtXKy_r63eOZoW6emV3SuRjPg=.4b805fb5-80c9-4b76-92f8-43f2335c525b@github.com> On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov wrote: >> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: >> >> - `jdk.aot` module ? the `jaotc` tool >> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution >> - related HotSpot code guarded by `#if INCLUDE_AOT` >> >> Additionally, remove tests as well as code in makefiles related to AoT compilation. >> >> Tested hs-tier1-4 > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Remove exports from Graal module to jdk.aot LGTM. Just a small nit. src/hotspot/share/oops/methodCounters.cpp line 77: > 75: } > 76: > 77: void MethodCounters::metaspace_pointers_do(MetaspaceClosure* it) { MethodCounters::metaspace_pointers_do can be removed altogether (also need to remove the declaration in methodCounter.hpp). ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3398 From kvn at openjdk.java.net Fri Apr 9 17:13:17 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 9 Apr 2021 17:13:17 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4] In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 04:32:14 GMT, David Holmes wrote: > Hi Vladimir, > > This looks good to me - I went through all the files. > > It was nice to see how nicely compartmentalized the AOT feature was - that made checking the changes quite simple. The one exception was the fingerprinting code, which for some reason was AOT-only but not marked that way, so I'm not sure what the story is there. ?? > > I was also surprised to see some of the flags were not marked experimental, so there will need to a CSR request to remove those without going through the normal deprecation process. > > Thanks, > David Thank you, David. We thought that we could use fingerprint code for other cases that is why we did not put it under `#if INCLUDE_AOT`. I filed CSR for AOT product flags removal: https://bugs.openjdk.java.net/browse/JDK-8265000 ------------- PR: https://git.openjdk.java.net/jdk/pull/3398 From kvn at openjdk.java.net Fri Apr 9 17:42:27 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 9 Apr 2021 17:42:27 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4] In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 17:09:58 GMT, Vladimir Kozlov wrote: >> Hi Vladimir, >> >> This looks good to me - I went through all the files. >> >> It was nice to see how nicely compartmentalized the AOT feature was - that made checking the changes quite simple. The one exception was the fingerprinting code, which for some reason was AOT-only but not marked that way, so I'm not sure what the story is there. ?? >> >> I was also surprised to see some of the flags were not marked experimental, so there will need to a CSR request to remove those without going through the normal deprecation process. >> >> Thanks, >> David > >> Hi Vladimir, >> >> This looks good to me - I went through all the files. >> >> It was nice to see how nicely compartmentalized the AOT feature was - that made checking the changes quite simple. The one exception was the fingerprinting code, which for some reason was AOT-only but not marked that way, so I'm not sure what the story is there. ?? >> >> I was also surprised to see some of the flags were not marked experimental, so there will need to a CSR request to remove those without going through the normal deprecation process. >> >> Thanks, >> David > > Thank you, David. > We thought that we could use fingerprint code for other cases that is why we did not put it under `#if INCLUDE_AOT`. > I filed CSR for AOT product flags removal: https://bugs.openjdk.java.net/browse/JDK-8265000 Thank you, Igor Ignatyev, Igor Veresov, Ioi, Aleksey and Andrew for reviews. I will update changes based on your comments. ------------- PR: https://git.openjdk.java.net/jdk/pull/3398 From kvn at openjdk.java.net Fri Apr 9 17:43:22 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 9 Apr 2021 17:43:22 GMT Subject: RFR: 8264806: Remove the experimental JIT compiler Message-ID: As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK: - `jdk.internal.vm.compiler` ? the Graal compiler - `jdk.internal.vm.compiler.management` ? Graal's `MBean` - `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests Remove Graal related code in makefiles. Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build: src/jdk.internal.vm.compiler/share/classes/module-info.java src/jdk.internal.vm.compiler.management/share/classes/module-info.java @AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it. Tested hs-tier1-4 ------------- Depends on: https://git.openjdk.java.net/jdk/pull/3398 Commit messages: - 8264806: Remove the experimental JIT compiler Changes: https://git.openjdk.java.net/jdk/pull/3421/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3421&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264806 Stats: 441620 lines in 2886 files changed: 0 ins; 441604 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/3421.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3421/head:pull/3421 PR: https://git.openjdk.java.net/jdk/pull/3421 From kvn at openjdk.java.net Fri Apr 9 17:45:20 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 9 Apr 2021 17:45:20 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4] In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 02:44:23 GMT, David Holmes wrote: >> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove exports from Graal module to jdk.aot > > src/hotspot/cpu/x86/compiledIC_x86.cpp line 134: > >> 132: #ifdef ASSERT >> 133: CodeBlob *cb = CodeCache::find_blob_unsafe((address) _call); >> 134: assert(cb, "sanity"); > > Nit: implied boolean - use "cb != NULL" done ------------- PR: https://git.openjdk.java.net/jdk/pull/3398 From kvn at openjdk.java.net Fri Apr 9 18:23:26 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 9 Apr 2021 18:23:26 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4] In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 03:03:33 GMT, David Holmes wrote: >> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove exports from Graal module to jdk.aot > > src/hotspot/share/memory/heap.hpp line 174: > >> 172: bool contains(const void* p) const { return low() <= p && p < high(); } >> 173: bool contains_blob(const CodeBlob* blob) const { >> 174: const void* start = (void*)blob; > > start seems redundant now Done: bool contains_blob(const CodeBlob* blob) const { - const void* start = (void*)blob; - return contains(start); + return contains((void*)blob); } ------------- PR: https://git.openjdk.java.net/jdk/pull/3398 From kvn at openjdk.java.net Fri Apr 9 18:23:25 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 9 Apr 2021 18:23:25 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4] In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 08:29:21 GMT, Aleksey Shipilev wrote: >> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove exports from Graal module to jdk.aot > > src/hotspot/cpu/x86/globalDefinitions_x86.hpp line 73: > >> 71: >> 72: #if INCLUDE_JVMCI >> 73: #define COMPRESSED_CLASS_POINTERS_DEPENDS_ON_COMPRESSED_OOPS (EnableJVMCI) > > Minor nit: can probably drop parentheses here. done ------------- PR: https://git.openjdk.java.net/jdk/pull/3398 From akozlov at openjdk.java.net Fri Apr 9 18:32:40 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Fri, 9 Apr 2021 18:32:40 GMT Subject: RFR: 8262896: [macos_aarch64] Crash in jni_fast_GetLongField Message-ID: <-z566EC0VCwqMkAGtW5Pz7_dyFjrht5qGHXL8Ba4lNQ=.4b5da342-f167-4a21-9fc3-bff50e7228fb@github.com> Hi, please review a fix for a random crash on macos/aarch64. By default, GetXXXField JNI Interface implementation is a generated function (-XX:+UseFastJNIAccessors). Usually the function is called by JNI code running in WXExec mode and everything is fine. But sometime we attempt to call it in WXWrite context, like in the stack trace attached to the bug: v ~BufferBlob::jni_fast_GetLongField V [libjvm.dylib+0x7a6538] Perf_Detach+0x168 j jdk.internal.perf.Perf.detach(Ljava/nio/ByteBuffer;)V+0 java.base at 17-internal j jdk.internal.perf.Perf$CleanerAction.run()V+8 java.base at 17-internal j jdk.internal.ref.CleanerImpl$PhantomCleanableRef.performCleanup()V+4 java.base at 17-internal j jdk.internal.ref.PhantomCleanable.clean()V+12 java.base at 17-internal j jdk.internal.ref.CleanerImpl.run()V+57 java.base at 17-internal j java.lang.Thread.run()V+11 java.base at 17-internal j jdk.internal.misc.InnocuousThread.run()V+20 java.base at 17-internal v ~StubRoutines::call_stub One way to fix the bug is to ensure WXExec mode before calling GetXXXField, but it depends on finding and fixing all such cases. This patch instead adds additional actions to GetXXXField implementation to ensure correct W^X mode regardless if it is called from WXWrite or WXExec mode. ------------- Commit messages: - Add W^X in FastGetXXXField Changes: https://git.openjdk.java.net/jdk/pull/3422/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3422&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262896 Stats: 69 lines in 3 files changed: 61 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/3422.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3422/head:pull/3422 PR: https://git.openjdk.java.net/jdk/pull/3422 From kvn at openjdk.java.net Fri Apr 9 18:32:26 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 9 Apr 2021 18:32:26 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4] In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 08:32:59 GMT, Aleksey Shipilev wrote: >> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove exports from Graal module to jdk.aot > > src/hotspot/share/code/compiledIC.cpp line 715: > >> 713: tty->print("interpreted"); >> 714: } else { >> 715: tty->print("unknown"); > > We can probably split this cleanup into the minor issue, your call. The benefit of separate issue: backportability. Reverted and filed https://bugs.openjdk.java.net/browse/JDK-8265013 ------------- PR: https://git.openjdk.java.net/jdk/pull/3398 From kvn at openjdk.java.net Fri Apr 9 18:36:24 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 9 Apr 2021 18:36:24 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4] In-Reply-To: <32eWo34nJ7czxicNNgoww6GpOpg0jKq8NZY_pPeQPpI=.e698cb8a-78e7-40a2-b54e-9b29ce1bedb1@github.com> References: <32eWo34nJ7czxicNNgoww6GpOpg0jKq8NZY_pPeQPpI=.e698cb8a-78e7-40a2-b54e-9b29ce1bedb1@github.com> Message-ID: <8rFTTlGuCqN9XzBEbaAAf9R-YhTTqe45jv9Gh7F506w=.67e92697-68c4-4657-abb4-803231a9d1a9@github.com> On Fri, 9 Apr 2021 16:30:41 GMT, Igor Veresov wrote: >> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove exports from Graal module to jdk.aot > > src/hotspot/share/oops/instanceKlass.hpp line 257: > >> 255: _misc_declares_nonstatic_concrete_methods = 1 << 6, // directly declares non-static, concrete methods >> 256: _misc_has_been_redefined = 1 << 7, // class has been redefined >> 257: _unused = 1 << 8, // > > Any particular reason we don't want to remove this gap? Less changes. We don't get any benefits from removing it. It is opposite - if we need a new value we will use it without changing following values again. ------------- PR: https://git.openjdk.java.net/jdk/pull/3398 From kvn at openjdk.java.net Fri Apr 9 19:09:25 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 9 Apr 2021 19:09:25 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4] In-Reply-To: <32eWo34nJ7czxicNNgoww6GpOpg0jKq8NZY_pPeQPpI=.e698cb8a-78e7-40a2-b54e-9b29ce1bedb1@github.com> References: <32eWo34nJ7czxicNNgoww6GpOpg0jKq8NZY_pPeQPpI=.e698cb8a-78e7-40a2-b54e-9b29ce1bedb1@github.com> Message-ID: On Fri, 9 Apr 2021 16:34:58 GMT, Igor Veresov wrote: >> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove exports from Graal module to jdk.aot > > src/hotspot/share/jvmci/jvmciCodeInstaller.cpp line 1184: > >> 1182: } >> 1183: } else if (jvmci_env()->isa_HotSpotMetaspaceConstantImpl(constant)) { >> 1184: if (!_immutable_pic_compilation) { > > All _immutable_pic_compilation mentions can be removed as well. It is true only for AOT compiles produced by Graal. It's never going to be used without AOT. Done. I removed _immutable_pic_compilation in JVMCI in Hotspot. ------------- PR: https://git.openjdk.java.net/jdk/pull/3398 From kvn at openjdk.java.net Fri Apr 9 19:26:22 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 9 Apr 2021 19:26:22 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4] In-Reply-To: <3zISek5YyT0zkmPX3UZtXKy_r63eOZoW6emV3SuRjPg=.4b805fb5-80c9-4b76-92f8-43f2335c525b@github.com> References: <3zISek5YyT0zkmPX3UZtXKy_r63eOZoW6emV3SuRjPg=.4b805fb5-80c9-4b76-92f8-43f2335c525b@github.com> Message-ID: <9RiwxlBLMiREzNvRHU14RQBW33nieUT8-Pmkod_GvtA=.ad51b2f9-f244-4346-8844-9fee39c9aa5b@github.com> On Fri, 9 Apr 2021 16:54:35 GMT, Ioi Lam wrote: >> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove exports from Graal module to jdk.aot > > src/hotspot/share/oops/methodCounters.cpp line 77: > >> 75: } >> 76: >> 77: void MethodCounters::metaspace_pointers_do(MetaspaceClosure* it) { > > MethodCounters::metaspace_pointers_do can be removed altogether (also need to remove the declaration in methodCounter.hpp). Done. ------------- PR: https://git.openjdk.java.net/jdk/pull/3398 From erikj at openjdk.java.net Fri Apr 9 19:33:34 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 9 Apr 2021 19:33:34 GMT Subject: RFR: 8264806: Remove the experimental JIT compiler In-Reply-To: References: Message-ID: <9YQ-kwVWOO0OzJO1YcfP9nnzUInhLOJ9yiecsYWBIp4=.22504511-4d72-4a41-8092-820501c1ca35@github.com> On Fri, 9 Apr 2021 17:35:11 GMT, Vladimir Kozlov wrote: > As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK: > > - `jdk.internal.vm.compiler` ? the Graal compiler > - `jdk.internal.vm.compiler.management` ? Graal's `MBean` > - `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests > > Remove Graal related code in makefiles. > > Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build: > src/jdk.internal.vm.compiler/share/classes/module-info.java > src/jdk.internal.vm.compiler.management/share/classes/module-info.java > > @AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it. > > Tested hs-tier1-4 make/GraalBuilderImage.gmk line 1: > 1: # This file should not be removed. This outout image is this makefile produces is used as input to the separate GraalVM build. make/Main.gmk line 444: > 442: )) > 443: > 444: $(eval $(call SetupTarget, graal-builder-image, \ Same as above, this needs to stay. make/autoconf/spec.gmk.in line 895: > 893: STATIC_LIBS_IMAGE_DIR := $(IMAGES_OUTPUTDIR)/$(STATIC_LIBS_IMAGE_SUBDIR) > 894: > 895: # Graal builder image Like above, this needs to stay. ------------- PR: https://git.openjdk.java.net/jdk/pull/3421 From kvn at openjdk.java.net Fri Apr 9 19:57:19 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 9 Apr 2021 19:57:19 GMT Subject: RFR: 8264940: java/lang/invoke/6998541/Test6998541.java failed "guarantee(ik->is_initialized()) failed: java/lang/Byte$ByteCache must be initialized" In-Reply-To: <5sr0T4XA92nZGjxReHoQhEbag23iYjPT-iVCsGNZwq8=.644a847b-8038-4cfb-8763-fb4586e4f0d2@github.com> References: <-17CHkPMQoZhr9gsnQ_1UvBDFAYUlaXCBFLQ7dGPK6g=.ebce6503-4974-41cc-8635-3b0168f02fe8@github.com> <5sr0T4XA92nZGjxReHoQhEbag23iYjPT-iVCsGNZwq8=.644a847b-8038-4cfb-8763-fb4586e4f0d2@github.com> Message-ID: On Fri, 9 Apr 2021 11:58:02 GMT, David Holmes wrote: >> Changes requested by coleenp (Reviewer). > > To evaluate what is the right fix for this problem I need to understand how JDK-8261137 caused the problem. Can you explain that please? When was this class normally initialized? > > Simply initializing the class at the point where you thought it already should have been initialized may not be the right solution, and as Coleen has pointed out you have to deal with any exceptions that may occur during that initialization. > > Thanks, > David The issue happens because the test was run with `-Xcomp` flag. The method was not executed in Interpreter and class was not initialized before the method is JIT compiled. I agree with @dholmes-ora that we should not fix it in Deoptimizer. I think we should restrict "Optimization of Box nodes in uncommon_trap" [8261137 ](https://bugs.openjdk.java.net/browse/JDK-8261137) only to cases when class is initialized. ------------- PR: https://git.openjdk.java.net/jdk/pull/3411 From kvn at openjdk.java.net Fri Apr 9 20:07:16 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 9 Apr 2021 20:07:16 GMT Subject: RFR: 8264649: runtime/InternalApi/ThreadCpuTimesDeadlock.java crash in fastdebug C2 with -XX:-UseTLAB [v2] In-Reply-To: <03pdWufgmVqBPCnhdEvHJnRHkblBlxSiAUsG4Zjpg30=.a17a5efa-8f65-4933-994a-f176f9c45cfb@github.com> References: <6BN6FtOuI_DuZS8Zpuy2k5xTSu10uXZjrfxMEt6e978=.b5e1ee6b-7dba-413c-9c04-bbf66098b588@github.com> <03pdWufgmVqBPCnhdEvHJnRHkblBlxSiAUsG4Zjpg30=.a17a5efa-8f65-4933-994a-f176f9c45cfb@github.com> Message-ID: On Wed, 7 Apr 2021 12:00:10 GMT, Hui Shi wrote: >> src/hotspot/share/opto/phaseX.cpp line 1481: >> >>> 1479: // Smash all inputs to 'old', isolating him completely >>> 1480: Node *temp = new Node(1); >>> 1481: temp->init_req(0,nn); // Add a use to nn to prevent him from dying >> >> Just wondering, why do we even need this? Without that code, `remove_dead_node(old)` would kill `nn` as well if it becomes dead. > > Thanks for your review! > > Checking code history, this code is quite old. From comments around, it doesn't want nn removed directly in PhaseIterGVN::subsume_node and leaves optimization to next GVN iteration. > > In my understanding, it might save callers to insert codes checking if "nn" is removed/dead at every subsume_node/replace_node callsite, simplifies implementation. > > 8153779a hotspot/src/share/vm/opto/phaseX.cpp (J. Duke 2007-12-01 00:00:00 +0000 1479) // Smash all inputs to 'old', isolating him completely > 2a0815a5 hotspot/src/share/vm/opto/phaseX.cpp (Tobias Hartmann 2014-06-02 08:07:29 +0200 1480) Node *temp = new Node(1); > 8153779a hotspot/src/share/vm/opto/phaseX.cpp (J. Duke 2007-12-01 00:00:00 +0000 1481) temp->init_req(0,nn); // Add a use to nn to prevent him from dying > 8153779a hotspot/src/share/vm/opto/phaseX.cpp (J. Duke 2007-12-01 00:00:00 +0000 1482) remove_dead_node( old ); > 8153779a hotspot/src/share/vm/opto/phaseX.cpp (J. Duke 2007-12-01 00:00:00 +0000 1483) temp->del_req(0); // Yank bogus edge Note `nn` could be new node created during parsing which does not have users yet. that is why we need to keep it ------------- PR: https://git.openjdk.java.net/jdk/pull/3336 From kvn at openjdk.java.net Fri Apr 9 20:32:20 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 9 Apr 2021 20:32:20 GMT Subject: RFR: 8264649: runtime/InternalApi/ThreadCpuTimesDeadlock.java crash in fastdebug C2 with -XX:-UseTLAB [v2] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 12:09:05 GMT, Hui Shi wrote: >> Please help review this fix. Detailed analysis in https://bugs.openjdk.java.net/browse/JDK-8264649 >> >> Tier1/2 release /fastdebug passed > > Hui Shi has updated the pull request incrementally with one additional commit since the last revision: > > fix typo in test description I agree with change. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3336 From mchung at openjdk.java.net Fri Apr 9 20:53:33 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 9 Apr 2021 20:53:33 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4] In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov wrote: >> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: >> >> - `jdk.aot` module ? the `jaotc` tool >> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution >> - related HotSpot code guarded by `#if INCLUDE_AOT` >> >> Additionally, remove tests as well as code in makefiles related to AoT compilation. >> >> Tested hs-tier1-4 > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Remove exports from Graal module to jdk.aot I reviewed the module-loader-map and non-hotspot non-AOT tests. ------------- Marked as reviewed by mchung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3398 From kvn at openjdk.java.net Fri Apr 9 21:59:04 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 9 Apr 2021 21:59:04 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v5] In-Reply-To: References: Message-ID: > As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: > > - `jdk.aot` module ? the `jaotc` tool > - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution > - related HotSpot code guarded by `#if INCLUDE_AOT` > > Additionally, remove tests as well as code in makefiles related to AoT compilation. > > Tested hs-tier1-4 Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3398/files - new: https://git.openjdk.java.net/jdk/pull/3398/files/6cce0f6c..71a166c1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3398&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3398&range=03-04 Stats: 36 lines in 9 files changed: 0 ins; 27 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/3398.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3398/head:pull/3398 PR: https://git.openjdk.java.net/jdk/pull/3398 From iveresov at openjdk.java.net Fri Apr 9 22:02:33 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 9 Apr 2021 22:02:33 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v5] In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 21:59:04 GMT, Vladimir Kozlov wrote: >> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: >> >> - `jdk.aot` module ? the `jaotc` tool >> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution >> - related HotSpot code guarded by `#if INCLUDE_AOT` >> >> Additionally, remove tests as well as code in makefiles related to AoT compilation. >> >> Tested hs-tier1-4 > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments Marked as reviewed by iveresov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3398 From kvn at openjdk.java.net Fri Apr 9 22:26:40 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 9 Apr 2021 22:26:40 GMT Subject: RFR: 8264806: Remove the experimental JIT compiler [v2] In-Reply-To: References: Message-ID: <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com> > As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK: > > - `jdk.internal.vm.compiler` ? the Graal compiler > - `jdk.internal.vm.compiler.management` ? Graal's `MBean` > - `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests > > Remove Graal related code in makefiles. > > Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build: > src/jdk.internal.vm.compiler/share/classes/module-info.java > src/jdk.internal.vm.compiler.management/share/classes/module-info.java > > @AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it. > > Tested hs-tier1-4 Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Restore Graal Builder image makefile - Merge latest changes from branch 'JDK-8264805' into JDK-8264806 - 8264806: Remove the experimental JIT compiler ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3421/files - new: https://git.openjdk.java.net/jdk/pull/3421/files/8ff9b599..a246aaa6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3421&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3421&range=00-01 Stats: 102 lines in 12 files changed: 66 ins; 27 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/3421.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3421/head:pull/3421 PR: https://git.openjdk.java.net/jdk/pull/3421 From kvn at openjdk.java.net Fri Apr 9 22:33:36 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 9 Apr 2021 22:33:36 GMT Subject: RFR: 8264806: Remove the experimental JIT compiler In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 17:35:11 GMT, Vladimir Kozlov wrote: > As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK: > > - `jdk.internal.vm.compiler` ? the Graal compiler > - `jdk.internal.vm.compiler.management` ? Graal's `MBean` > - `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests > > Remove Graal related code in makefiles. > > Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build: > src/jdk.internal.vm.compiler/share/classes/module-info.java > src/jdk.internal.vm.compiler.management/share/classes/module-info.java > > @AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it. > > Tested hs-tier1-4 Thankyou, @erikj79, for review. I restored code as you asked. For some reasons incremental webrev shows update only in Cdiffs. ------------- PR: https://git.openjdk.java.net/jdk/pull/3421 From dcubed at openjdk.java.net Fri Apr 9 23:04:29 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 9 Apr 2021 23:04:29 GMT Subject: RFR: 8264940: java/lang/invoke/6998541/Test6998541.java failed "guarantee(ik->is_initialized()) failed: java/lang/Byte$ByteCache must be initialized" In-Reply-To: References: <-17CHkPMQoZhr9gsnQ_1UvBDFAYUlaXCBFLQ7dGPK6g=.ebce6503-4974-41cc-8635-3b0168f02fe8@github.com> <5sr0T4XA92nZGjxReHoQhEbag23iYjPT-iVCsGNZwq8=.644a847b-8038-4cfb-8763-fb4586e4f0d2@github.com> Message-ID: On Fri, 9 Apr 2021 19:54:44 GMT, Vladimir Kozlov wrote: >> To evaluate what is the right fix for this problem I need to understand how JDK-8261137 caused the problem. Can you explain that please? When was this class normally initialized? >> >> Simply initializing the class at the point where you thought it already should have been initialized may not be the right solution, and as Coleen has pointed out you have to deal with any exceptions that may occur during that initialization. >> >> Thanks, >> David > > The issue happens because the test was run with `-Xcomp` flag. The method was not executed in Interpreter and class was not initialized before the method is JIT compiled. > I agree with @dholmes-ora that we should not fix it in Deoptimizer. I think we should restrict "Optimization of Box nodes in uncommon_trap" [8261137 ](https://bugs.openjdk.java.net/browse/JDK-8261137) only to cases when class is initialized. @vnkozlov and @Wanghuang-Huawei, This failure appears to be happening twice in every Tier6 job set. Is there an estimate on when a fix for this issue will be ready? ------------- PR: https://git.openjdk.java.net/jdk/pull/3411 From iklam at openjdk.java.net Fri Apr 9 23:28:04 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 9 Apr 2021 23:28:04 GMT Subject: RFR: 8264868: Reduce inclusion of registerMap.hpp and register.hpp [v2] In-Reply-To: References: Message-ID: > Register.hpp is included 815 times, and registerMap.hpp is include 862 times (out of about 1000 HotSpot .o files). > > This can be reduced by refactoring the popular header file **frame.hpp**, so that it doesn't include registerMap.hpp anymore. This reduces the number of .o files that include register.hpp to 612, and that of registerMap.hpp to 109. > > The total number of lines of C++ code compiled for HotSpot is reduced by about 0.5%. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into 8264868-reduce-registerMap-hpp - 8264868: Reduce inclusion of registerMap.hpp and register.hpp ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3384/files - new: https://git.openjdk.java.net/jdk/pull/3384/files/507136ef..288658cf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3384&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3384&range=00-01 Stats: 6195 lines in 169 files changed: 4507 ins; 1090 del; 598 mod Patch: https://git.openjdk.java.net/jdk/pull/3384.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3384/head:pull/3384 PR: https://git.openjdk.java.net/jdk/pull/3384 From hshi at openjdk.java.net Fri Apr 9 23:59:29 2021 From: hshi at openjdk.java.net (Hui Shi) Date: Fri, 9 Apr 2021 23:59:29 GMT Subject: RFR: 8264649: runtime/InternalApi/ThreadCpuTimesDeadlock.java crash in fastdebug C2 with -XX:-UseTLAB [v2] In-Reply-To: <-63abPXoiWhcD8FhNKDptvxLVKYCLjKW5WtAGKUVg4U=.9b9367a3-202f-418c-b049-dad477aa6f2f@github.com> References: <-63abPXoiWhcD8FhNKDptvxLVKYCLjKW5WtAGKUVg4U=.9b9367a3-202f-418c-b049-dad477aa6f2f@github.com> Message-ID: On Fri, 9 Apr 2021 07:01:01 GMT, Tobias Hartmann wrote: >> Hui Shi has updated the pull request incrementally with one additional commit since the last revision: >> >> fix typo in test description > > Thanks for the details. Your fix looks reasonable to me. Thanks! @TobiHartmann @vnkozlov ------------- PR: https://git.openjdk.java.net/jdk/pull/3336 From hshi at openjdk.java.net Sat Apr 10 00:07:34 2021 From: hshi at openjdk.java.net (Hui Shi) Date: Sat, 10 Apr 2021 00:07:34 GMT Subject: Integrated: 8264649: runtime/InternalApi/ThreadCpuTimesDeadlock.java crash in fastdebug C2 with -XX:-UseTLAB In-Reply-To: References: Message-ID: On Sat, 3 Apr 2021 00:53:54 GMT, Hui Shi wrote: > Please help review this fix. Detailed analysis in https://bugs.openjdk.java.net/browse/JDK-8264649 > > Tier1/2 release /fastdebug passed This pull request has now been integrated. Changeset: 42f4d706 Author: Hui Shi Committer: Jie Fu URL: https://git.openjdk.java.net/jdk/commit/42f4d706 Stats: 13 lines in 2 files changed: 12 ins; 0 del; 1 mod 8264649: runtime/InternalApi/ThreadCpuTimesDeadlock.java crash in fastdebug C2 with -XX:-UseTLAB Reviewed-by: thartmann, kvn ------------- PR: https://git.openjdk.java.net/jdk/pull/3336 From amenkov at openjdk.java.net Sat Apr 10 01:22:45 2021 From: amenkov at openjdk.java.net (Alex Menkov) Date: Sat, 10 Apr 2021 01:22:45 GMT Subject: RFR: 8262002: java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.sh failed with "TestCaseScaffoldException: DummyClassWithLVT did not match .class file" Message-ID: The test actually failed starting from jdk13, but the error is masked by JDK-8264667 (and shell part of the test didn't verify result of the java execution) The fix: - updates JvmtiClassFileReconstituter to add attributes in the same order as javac does - makes the test java instead of shell - added workaround for JDK-8264667 - test code is ready to ignore order of attributes ------------- Commit messages: - fixed spaces - JDK-8262002 Changes: https://git.openjdk.java.net/jdk/pull/3426/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3426&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262002 Stats: 220 lines in 4 files changed: 113 ins; 96 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/3426.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3426/head:pull/3426 PR: https://git.openjdk.java.net/jdk/pull/3426 From amenkov at openjdk.java.net Sat Apr 10 01:22:46 2021 From: amenkov at openjdk.java.net (Alex Menkov) Date: Sat, 10 Apr 2021 01:22:46 GMT Subject: RFR: 8262002: java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.sh failed with "TestCaseScaffoldException: DummyClassWithLVT did not match .class file" In-Reply-To: References: Message-ID: <3C-yT6xsCeRk7U96EHpt2NuALsf2h3VqauXRGMENE80=.c8fa44d0-0ee0-4db4-8572-516b38586575@github.com> On Sat, 10 Apr 2021 01:10:37 GMT, Alex Menkov wrote: > The test actually failed starting from jdk13, but the error is masked by JDK-8264667 (and shell part of the test didn't verify result of the java execution) > The fix: > - updates JvmtiClassFileReconstituter to add attributes in the same order as javac does > - makes the test java instead of shell > - added workaround for JDK-8264667 > - test code is ready to ignore order of attributes label remove core-libs ------------- PR: https://git.openjdk.java.net/jdk/pull/3426 From dlong at openjdk.java.net Sat Apr 10 04:05:27 2021 From: dlong at openjdk.java.net (Dean Long) Date: Sat, 10 Apr 2021 04:05:27 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4] In-Reply-To: <3zISek5YyT0zkmPX3UZtXKy_r63eOZoW6emV3SuRjPg=.4b805fb5-80c9-4b76-92f8-43f2335c525b@github.com> References: <3zISek5YyT0zkmPX3UZtXKy_r63eOZoW6emV3SuRjPg=.4b805fb5-80c9-4b76-92f8-43f2335c525b@github.com> Message-ID: On Fri, 9 Apr 2021 16:54:51 GMT, Ioi Lam wrote: >> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove exports from Graal module to jdk.aot > > LGTM. Just a small nit. @iklam I thought the fingerprint code was also used by CDS. ------------- PR: https://git.openjdk.java.net/jdk/pull/3398 From iklam at openjdk.java.net Sat Apr 10 06:08:33 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Sat, 10 Apr 2021 06:08:33 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4] In-Reply-To: <3zISek5YyT0zkmPX3UZtXKy_r63eOZoW6emV3SuRjPg=.4b805fb5-80c9-4b76-92f8-43f2335c525b@github.com> References: <3zISek5YyT0zkmPX3UZtXKy_r63eOZoW6emV3SuRjPg=.4b805fb5-80c9-4b76-92f8-43f2335c525b@github.com> Message-ID: On Fri, 9 Apr 2021 16:54:51 GMT, Ioi Lam wrote: >> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove exports from Graal module to jdk.aot > > LGTM. Just a small nit. > @iklam > I thought the fingerprint code was also used by CDS. CDS actually uses a different mechanism (CRC of the classfile bytes) to validate that a class has not changed between archive dumping time and runtime. See https://github.com/openjdk/jdk/blob/5784f6b7f74d0b8081ac107fea172539d57d6020/src/hotspot/share/classfile/systemDictionaryShared.cpp#L1126-L1130 ------------- PR: https://git.openjdk.java.net/jdk/pull/3398 From iklam at openjdk.java.net Sat Apr 10 06:12:24 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Sat, 10 Apr 2021 06:12:24 GMT Subject: RFR: 8264868: Reduce inclusion of registerMap.hpp and register.hpp [v2] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 21:37:08 GMT, Coleen Phillimore wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: >> >> - Merge branch 'master' into 8264868-reduce-registerMap-hpp >> - 8264868: Reduce inclusion of registerMap.hpp and register.hpp > > I like StackFrameStream getting its own header file. Thanks @coleenp and @dholmes-ora for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/3384 From iklam at openjdk.java.net Sat Apr 10 06:12:25 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Sat, 10 Apr 2021 06:12:25 GMT Subject: Integrated: 8264868: Reduce inclusion of registerMap.hpp and register.hpp In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 21:03:10 GMT, Ioi Lam wrote: > Register.hpp is included 815 times, and registerMap.hpp is include 862 times (out of about 1000 HotSpot .o files). > > This can be reduced by refactoring the popular header file **frame.hpp**, so that it doesn't include registerMap.hpp anymore. This reduces the number of .o files that include register.hpp to 612, and that of registerMap.hpp to 109. > > The total number of lines of C++ code compiled for HotSpot is reduced by about 0.5%. This pull request has now been integrated. Changeset: c15680e7 Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/c15680e7 Stats: 263 lines in 27 files changed: 203 ins; 51 del; 9 mod 8264868: Reduce inclusion of registerMap.hpp and register.hpp Reviewed-by: coleenp, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/3384 From iklam at openjdk.java.net Sat Apr 10 07:12:52 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Sat, 10 Apr 2021 07:12:52 GMT Subject: RFR: 8262328: Templatize JVMFlag boilerplate access methods [v4] In-Reply-To: References: Message-ID: > We have a bunch of boilerplate method like: > > JVMFlagAccess::boolAtPut (JVMFlag* f, bool* v, JVMFlagOrigin origin) > JVMFlagAccess::intAtPut (JVMFlag* f, int* v, JVMFlagOrigin origin) > JVMFlagAccess::uintAtPut (JVMFlag* f, uint* v, JVMFlagOrigin origin) > ... > > Similarly, we also have 8 different functions: JVMFlag::{set_bool, set_int, set_intx, ...} > > We should replace such patterns with > > template > JVMFlagAccess::set(JVMFlag* f, T* value, JVMFlagOrigin origin) > > This would allow us to templatize the 8x boilerplate functions in writeableFlags.cpp. > > The flag access code in whitebox.cpp can also be improved. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: - Merge branch 'master' into 8262328-templatize-jvmflag-boilerplate-methods - reinstated JVMFlagAccess::set_{bool,int,uint,...} functions for better readability - removed unnecessary #include - Restored in templates so we can require exact types (i.e., cannot mix size_t and uintx even they might be the same type of some platforms) - added test case - removed JVMFlag::set_##type() functions - fixed merge - Merge branch 'master' into 8262328-templatize-jvmflag-boilerplate-methods - static_assert to disable SET_FLAG_XXX on ccstr flags - more cleanup - ... and 2 more: https://git.openjdk.java.net/jdk/compare/c15680e7...e3280b69 ------------- Changes: https://git.openjdk.java.net/jdk/pull/3318/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3318&range=03 Stats: 337 lines in 10 files changed: 100 ins; 140 del; 97 mod Patch: https://git.openjdk.java.net/jdk/pull/3318.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3318/head:pull/3318 PR: https://git.openjdk.java.net/jdk/pull/3318 From aph at openjdk.java.net Sat Apr 10 10:27:30 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Sat, 10 Apr 2021 10:27:30 GMT Subject: RFR: 8262896: [macos_aarch64] Crash in jni_fast_GetLongField In-Reply-To: <-z566EC0VCwqMkAGtW5Pz7_dyFjrht5qGHXL8Ba4lNQ=.4b5da342-f167-4a21-9fc3-bff50e7228fb@github.com> References: <-z566EC0VCwqMkAGtW5Pz7_dyFjrht5qGHXL8Ba4lNQ=.4b5da342-f167-4a21-9fc3-bff50e7228fb@github.com> Message-ID: On Fri, 9 Apr 2021 18:25:10 GMT, Anton Kozlov wrote: > Hi, please review a fix for a random crash on macos/aarch64. > > By default, GetXXXField JNI Interface implementation is a generated function (-XX:+UseFastJNIAccessors). Usually the function is called by JNI code running in WXExec mode and everything is fine. But sometime we attempt to call it in WXWrite context, like in the stack trace attached to the bug: > > v ~BufferBlob::jni_fast_GetLongField > V [libjvm.dylib+0x7a6538] Perf_Detach+0x168 > j jdk.internal.perf.Perf.detach(Ljava/nio/ByteBuffer;)V+0 java.base at 17-internal > j jdk.internal.perf.Perf$CleanerAction.run()V+8 java.base at 17-internal > j jdk.internal.ref.CleanerImpl$PhantomCleanableRef.performCleanup()V+4 java.base at 17-internal > j jdk.internal.ref.PhantomCleanable.clean()V+12 java.base at 17-internal > j jdk.internal.ref.CleanerImpl.run()V+57 java.base at 17-internal > j java.lang.Thread.run()V+11 java.base at 17-internal > j jdk.internal.misc.InnocuousThread.run()V+20 java.base at 17-internal > v ~StubRoutines::call_stub > > One way to fix the bug is to ensure WXExec mode before calling GetXXXField, but it depends on finding and fixing all such cases. > > This patch instead adds additional actions to GetXXXField implementation to ensure correct W^X mode regardless if it is called from WXWrite or WXExec mode. So I'm curious because I don't know the overhead of W^X switching. How much does this gain over turning off UseFastJNIAccessors? I guess it doesn't much matter because you keep track of the current mode and only flip it if you really need to, which is rare? ------------- PR: https://git.openjdk.java.net/jdk/pull/3422 From iignatyev at openjdk.java.net Sat Apr 10 15:28:35 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Sat, 10 Apr 2021 15:28:35 GMT Subject: RFR: 8264806: Remove the experimental JIT compiler In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 22:30:32 GMT, Vladimir Kozlov wrote: >> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK: >> >> - `jdk.internal.vm.compiler` ? the Graal compiler >> - `jdk.internal.vm.compiler.management` ? Graal's `MBean` >> - `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests >> >> Remove Graal related code in makefiles. >> >> Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build: >> src/jdk.internal.vm.compiler/share/classes/module-info.java >> src/jdk.internal.vm.compiler.management/share/classes/module-info.java >> >> @AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it. >> >> Tested hs-tier1-4 > > Thankyou, @erikj79, for review. I restored code as you asked. > For some reasons incremental webrev shows update only in Cdiffs. none of the full webrevs seem to render even the list of changed files? is it just me? ------------- PR: https://git.openjdk.java.net/jdk/pull/3421 From iignatyev at openjdk.java.net Sat Apr 10 15:41:44 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Sat, 10 Apr 2021 15:41:44 GMT Subject: RFR: 8264806: Remove the experimental JIT compiler [v2] In-Reply-To: <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com> References: <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com> Message-ID: On Fri, 9 Apr 2021 22:26:40 GMT, Vladimir Kozlov wrote: >> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK: >> >> - `jdk.internal.vm.compiler` ? the Graal compiler >> - `jdk.internal.vm.compiler.management` ? Graal's `MBean` >> - `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests >> >> Remove Graal related code in makefiles. >> >> Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build: >> src/jdk.internal.vm.compiler/share/classes/module-info.java >> src/jdk.internal.vm.compiler.management/share/classes/module-info.java >> >> @AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it. >> >> Tested hs-tier1-4 > > Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Restore Graal Builder image makefile > - Merge latest changes from branch 'JDK-8264805' into JDK-8264806 > - 8264806: Remove the experimental JIT compiler should we remove `sun.hotspot.code.Compiler::isGraalEnabled` method and update a few of its users accordingly? what about `vm.graal.enabled` `@requires` property? ------------- Changes requested by iignatyev (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3421 From iklam at openjdk.java.net Sat Apr 10 15:44:20 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Sat, 10 Apr 2021 15:44:20 GMT Subject: RFR: 8262328: Templatize JVMFlag boilerplate access methods [v3] In-Reply-To: <90k6XitD4HHsJ4Ysooht5KF1Iqcfzhy0cwQZelpo8zg=.29771578-30e0-4fd7-b5af-b50383de6598@github.com> References: <90k6XitD4HHsJ4Ysooht5KF1Iqcfzhy0cwQZelpo8zg=.29771578-30e0-4fd7-b5af-b50383de6598@github.com> Message-ID: On Thu, 8 Apr 2021 02:04:09 GMT, David Holmes wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> reinstated JVMFlagAccess::set_{bool,int,uint,...} functions for better readability > > Hi Ioi, > > This latest version looks good to me. > > Thanks, > David Thanks @dholmes-ora and @gerard-ziemski for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/3318 From iklam at openjdk.java.net Sat Apr 10 15:44:21 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Sat, 10 Apr 2021 15:44:21 GMT Subject: Integrated: 8262328: Templatize JVMFlag boilerplate access methods In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 22:44:34 GMT, Ioi Lam wrote: > We have a bunch of boilerplate method like: > > JVMFlagAccess::boolAtPut (JVMFlag* f, bool* v, JVMFlagOrigin origin) > JVMFlagAccess::intAtPut (JVMFlag* f, int* v, JVMFlagOrigin origin) > JVMFlagAccess::uintAtPut (JVMFlag* f, uint* v, JVMFlagOrigin origin) > ... > > Similarly, we also have 8 different functions: JVMFlag::{set_bool, set_int, set_intx, ...} > > We should replace such patterns with > > template > JVMFlagAccess::set(JVMFlag* f, T* value, JVMFlagOrigin origin) > > This would allow us to templatize the 8x boilerplate functions in writeableFlags.cpp. > > The flag access code in whitebox.cpp can also be improved. This pull request has now been integrated. Changeset: 627ad9fe Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/627ad9fe Stats: 337 lines in 10 files changed: 100 ins; 140 del; 97 mod 8262328: Templatize JVMFlag boilerplate access methods Reviewed-by: dholmes, gziemski ------------- PR: https://git.openjdk.java.net/jdk/pull/3318 From kvn at openjdk.java.net Sat Apr 10 16:35:40 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Sat, 10 Apr 2021 16:35:40 GMT Subject: RFR: 8264806: Remove the experimental JIT compiler [v2] In-Reply-To: References: <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com> Message-ID: On Sat, 10 Apr 2021 15:38:11 GMT, Igor Ignatyev wrote: > should we remove `sun.hotspot.code.Compiler::isGraalEnabled` method and update a few of its users accordingly? > what about `vm.graal.enabled` `@requires` property? Thank you, @iignatev for looking on changes. I forgot to mention that `Compiler::isGraalEnabled()` returns always false now. Because 94 tests uses `@requires !vm.graal.enabled` I don't want to include them in these changes which are already very big. I am not sure if I should modify tests if GraalVM group wants to run all these tests. Unfortunately changes in `Compiler.java` are listed the last on `Files changed` tab and GitHub has trouble to load these big changes - it takes time to see them. Here `Compiler.java` chnges for review: diff --git a/test/lib/sun/hotspot/code/Compiler.java b/test/lib/sun/hotspot/code/Compiler.java index 99122bd93b8..71288ae4482 100644 --- a/test/lib/sun/hotspot/code/Compiler.java +++ b/test/lib/sun/hotspot/code/Compiler.java @@ -60,33 +60,10 @@ public class Compiler { /** * Check if Graal is used as JIT compiler. * - * Graal is enabled if following conditions are true: - * - we are not in Interpreter mode - * - UseJVMCICompiler flag is true - * - jvmci.Compiler variable is equal to 'graal' - * - TieredCompilation is not used or TieredStopAtLevel is greater than 3 - * No need to check client mode because it set UseJVMCICompiler to false. - * - * @return true if Graal is used as JIT compiler. + * @return false because Graal is removed from JDK. */ public static boolean isGraalEnabled() { - Boolean useCompiler = WB.getBooleanVMFlag("UseCompiler"); - if (useCompiler == null || !useCompiler) { - return false; - } - Boolean useJvmciComp = WB.getBooleanVMFlag("UseJVMCICompiler"); - if (useJvmciComp == null || !useJvmciComp) { - return false; - } - - Boolean tieredCompilation = WB.getBooleanVMFlag("TieredCompilation"); - Long compLevel = WB.getIntxVMFlag("TieredStopAtLevel"); - // if TieredCompilation is enabled and compilation level is <= 3 then no Graal is used - if (tieredCompilation != null && tieredCompilation && - compLevel != null && compLevel <= 3) { - return false; - } - return true; + return false; } ``` ------------- PR: https://git.openjdk.java.net/jdk/pull/3421 From kvn at openjdk.java.net Sat Apr 10 16:40:48 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Sat, 10 Apr 2021 16:40:48 GMT Subject: RFR: 8264806: Remove the experimental JIT compiler [v2] In-Reply-To: References: <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com> Message-ID: On Sat, 10 Apr 2021 15:38:11 GMT, Igor Ignatyev wrote: >> Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Restore Graal Builder image makefile >> - Merge latest changes from branch 'JDK-8264805' into JDK-8264806 >> - 8264806: Remove the experimental JIT compiler > > should we remove `sun.hotspot.code.Compiler::isGraalEnabled` method and update a few of its users accordingly? > what about `vm.graal.enabled` `@requires` property? @iignatev If you think that I should clean tests anyway I will file follow up RFE to do that. ------------- PR: https://git.openjdk.java.net/jdk/pull/3421 From iignatyev at openjdk.java.net Sat Apr 10 16:50:46 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Sat, 10 Apr 2021 16:50:46 GMT Subject: RFR: 8264806: Remove the experimental JIT compiler [v2] In-Reply-To: References: <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com> Message-ID: On Sat, 10 Apr 2021 16:36:54 GMT, Vladimir Kozlov wrote: >> should we remove `sun.hotspot.code.Compiler::isGraalEnabled` method and update a few of its users accordingly? >> what about `vm.graal.enabled` `@requires` property? > > @iignatev If you think that I should clean tests anyway I will file follow up RFE to do that. > > should we remove `sun.hotspot.code.Compiler::isGraalEnabled` method and update a few of its users accordingly? > > what about `vm.graal.enabled` `@requires` property? > > Thank you, @iignatev for looking on changes. > > I forgot to mention that `Compiler::isGraalEnabled()` returns always false now. Because 94 tests uses `@requires !vm.graal.enabled` I don't want to include them in these changes which are already very big. I am not sure if I should modify tests if GraalVM group wants to run all these tests. > If you think that I should clean tests anyway I will file follow up RFE to do that. changing `Compiler::isGraalEnabled()` to always return false effectively makes these tests unrunnable for GraalVM group (unless they are keep the modified `sun/hotspot/code/Compiler` and/or `requires/VMProps` in their forks). on top of that, I foresee that there will be more tests incompatible w/ Graal yet given it won't be run/tested in OpenJDK, these tests won't be marked and hence will fail when run w/ Graal. so Graal people will have to either do marking themselves (I guess in both upstream and their fork) or maintain a list of inapplicable tests in a format that works best for their setup. that's to say, I think we should clean up the tests, yet I totally agree there is no need to do it as part of this PR. we can discuss how to do it better for both OpenJDK and GraalVM folks in the follow-up RFE. ------------- PR: https://git.openjdk.java.net/jdk/pull/3421 From iignatyev at openjdk.java.net Sat Apr 10 16:50:46 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Sat, 10 Apr 2021 16:50:46 GMT Subject: RFR: 8264806: Remove the experimental JIT compiler [v2] In-Reply-To: <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com> References: <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com> Message-ID: On Fri, 9 Apr 2021 22:26:40 GMT, Vladimir Kozlov wrote: >> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK: >> >> - `jdk.internal.vm.compiler` ? the Graal compiler >> - `jdk.internal.vm.compiler.management` ? Graal's `MBean` >> - `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests >> >> Remove Graal related code in makefiles. >> >> Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build: >> src/jdk.internal.vm.compiler/share/classes/module-info.java >> src/jdk.internal.vm.compiler.management/share/classes/module-info.java >> >> @AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it. >> >> Tested hs-tier1-4 > > Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Restore Graal Builder image makefile > - Merge latest changes from branch 'JDK-8264805' into JDK-8264806 > - 8264806: Remove the experimental JIT compiler Marked as reviewed by iignatyev (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3421 From kvn at openjdk.java.net Sat Apr 10 17:44:34 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Sat, 10 Apr 2021 17:44:34 GMT Subject: RFR: 8264806: Remove the experimental JIT compiler [v2] In-Reply-To: References: <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com> Message-ID: On Sat, 10 Apr 2021 16:47:45 GMT, Igor Ignatyev wrote: >> Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Restore Graal Builder image makefile >> - Merge latest changes from branch 'JDK-8264805' into JDK-8264806 >> - 8264806: Remove the experimental JIT compiler > > Marked as reviewed by iignatyev (Reviewer). Thank you, Igor. I filed https://bugs.openjdk.java.net/browse/JDK-8265032 ------------- PR: https://git.openjdk.java.net/jdk/pull/3421 From dcubed at openjdk.java.net Sat Apr 10 21:27:31 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Sat, 10 Apr 2021 21:27:31 GMT Subject: RFR: 8264940: java/lang/invoke/6998541/Test6998541.java failed "guarantee(ik->is_initialized()) failed: java/lang/Byte$ByteCache must be initialized" In-Reply-To: References: <-17CHkPMQoZhr9gsnQ_1UvBDFAYUlaXCBFLQ7dGPK6g=.ebce6503-4974-41cc-8635-3b0168f02fe8@github.com> <5sr0T4XA92nZGjxReHoQhEbag23iYjPT-iVCsGNZwq8=.644a847b-8038-4cfb-8763-fb4586e4f0d2@github.com> Message-ID: On Fri, 9 Apr 2021 19:54:44 GMT, Vladimir Kozlov wrote: >> To evaluate what is the right fix for this problem I need to understand how JDK-8261137 caused the problem. Can you explain that please? When was this class normally initialized? >> >> Simply initializing the class at the point where you thought it already should have been initialized may not be the right solution, and as Coleen has pointed out you have to deal with any exceptions that may occur during that initialization. >> >> Thanks, >> David > > The issue happens because the test was run with `-Xcomp` flag. The method was not executed in Interpreter and class was not initialized before the method is JIT compiled. > I agree with @dholmes-ora that we should not fix it in Deoptimizer. I think we should restrict "Optimization of Box nodes in uncommon_trap" [8261137 ](https://bugs.openjdk.java.net/browse/JDK-8261137) only to cases when class is initialized. @vnkozlov and @Wanghuang-Huawei, This failure has now reached Tier8 and we have 8 failures (so far). I haven't seen a response to my query on Friday. Please ProblemList this test if the fix is not going to be integrated soon. ------------- PR: https://git.openjdk.java.net/jdk/pull/3411 From whuang at openjdk.java.net Sun Apr 11 02:24:46 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Sun, 11 Apr 2021 02:24:46 GMT Subject: RFR: 8264940: java/lang/invoke/6998541/Test6998541.java failed "guarantee(ik->is_initialized()) failed: java/lang/Byte$ByteCache must be initialized" In-Reply-To: References: <-17CHkPMQoZhr9gsnQ_1UvBDFAYUlaXCBFLQ7dGPK6g=.ebce6503-4974-41cc-8635-3b0168f02fe8@github.com> <5sr0T4XA92nZGjxReHoQhEbag23iYjPT-iVCsGNZwq8=.644a847b-8038-4cfb-8763-fb4586e4f0d2@github.com> Message-ID: On Fri, 9 Apr 2021 19:54:44 GMT, Vladimir Kozlov wrote: >> To evaluate what is the right fix for this problem I need to understand how JDK-8261137 caused the problem. Can you explain that please? When was this class normally initialized? >> >> Simply initializing the class at the point where you thought it already should have been initialized may not be the right solution, and as Coleen has pointed out you have to deal with any exceptions that may occur during that initialization. >> >> Thanks, >> David > > The issue happens because the test was run with `-Xcomp` flag. The method was not executed in Interpreter and class was not initialized before the method is JIT compiled. > I agree with @dholmes-ora that we should not fix it in Deoptimizer. I think we should restrict "Optimization of Box nodes in uncommon_trap" [8261137 ](https://bugs.openjdk.java.net/browse/JDK-8261137) only to cases when class is initialized. > @vnkozlov and @Wanghuang-Huawei, > This failure has now reached Tier8 and we have 8 failures (so far). > I haven't seen a response to my query on Friday. Please ProblemList > this test if the fix is not going to be integrated soon. I am very sorry about that.I have fixed this issue in a new way and test it on my x86 and aarch64 machine. I think I will push a new commit tomorrow. ------------- PR: https://git.openjdk.java.net/jdk/pull/3411 From dnsimon at openjdk.java.net Sun Apr 11 10:28:36 2021 From: dnsimon at openjdk.java.net (Doug Simon) Date: Sun, 11 Apr 2021 10:28:36 GMT Subject: RFR: 8264806: Remove the experimental JIT compiler [v2] In-Reply-To: References: <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com> Message-ID: On Sat, 10 Apr 2021 17:41:05 GMT, Vladimir Kozlov wrote: >> Marked as reviewed by iignatyev (Reviewer). > > Thank you, Igor. I filed https://bugs.openjdk.java.net/browse/JDK-8265032 We would definitely like to be able to continue testing of GraalVM with the JDK set of jtreg tests. So keeping `Compiler::isGraalEnabled()` working like it does today is important. ------------- PR: https://git.openjdk.java.net/jdk/pull/3421 From whuang at openjdk.java.net Mon Apr 12 02:10:17 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Mon, 12 Apr 2021 02:10:17 GMT Subject: RFR: 8264940: java/lang/invoke/6998541/Test6998541.java failed "guarantee(ik->is_initialized()) failed: java/lang/Byte$ByteCache must be initialized" [v2] In-Reply-To: <-17CHkPMQoZhr9gsnQ_1UvBDFAYUlaXCBFLQ7dGPK6g=.ebce6503-4974-41cc-8635-3b0168f02fe8@github.com> References: <-17CHkPMQoZhr9gsnQ_1UvBDFAYUlaXCBFLQ7dGPK6g=.ebce6503-4974-41cc-8635-3b0168f02fe8@github.com> Message-ID: > * The main reason is that in this situation the `BoxCache` is not initialized before `uncommon_trap`. > * `java.lang.Byte$ByteCache` is loaded without initializing here > * I think that all `*Cache` classes should be loaded in this situation. Wang Huang has updated the pull request incrementally with one additional commit since the last revision: fix bug in the other way ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3411/files - new: https://git.openjdk.java.net/jdk/pull/3411/files/1b73187c..3c971646 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3411&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3411&range=00-01 Stats: 32 lines in 2 files changed: 27 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/3411.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3411/head:pull/3411 PR: https://git.openjdk.java.net/jdk/pull/3411 From whuang at openjdk.java.net Mon Apr 12 02:15:59 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Mon, 12 Apr 2021 02:15:59 GMT Subject: RFR: 8264940: java/lang/invoke/6998541/Test6998541.java failed "guarantee(ik->is_initialized()) failed: java/lang/Byte$ByteCache must be initialized" [v2] In-Reply-To: <5sr0T4XA92nZGjxReHoQhEbag23iYjPT-iVCsGNZwq8=.644a847b-8038-4cfb-8763-fb4586e4f0d2@github.com> References: <-17CHkPMQoZhr9gsnQ_1UvBDFAYUlaXCBFLQ7dGPK6g=.ebce6503-4974-41cc-8635-3b0168f02fe8@github.com> <5sr0T4XA92nZGjxReHoQhEbag23iYjPT-iVCsGNZwq8=.644a847b-8038-4cfb-8763-fb4586e4f0d2@github.com> Message-ID: <1lB_vtMyExCTmI3wu8ff_BX-84tnKoB8y35KkJIPs7U=.69bf8433-d732-482d-bde7-8f5d994b101a@github.com> On Fri, 9 Apr 2021 11:58:02 GMT, David Holmes wrote: >> Changes requested by coleenp (Reviewer). > > To evaluate what is the right fix for this problem I need to understand how JDK-8261137 caused the problem. Can you explain that please? When was this class normally initialized? > > Simply initializing the class at the point where you thought it already should have been initialized may not be the right solution, and as Coleen has pointed out you have to deal with any exceptions that may occur during that initialization. > > Thanks, > David @dholmes-ora @vnkozlov @dcubed-ojdk @coleenp I fixed the bug according to @vnkozlov's suggestion. I added method `is_box_cache_valid` to judge if a box cache class is ready. ------------- PR: https://git.openjdk.java.net/jdk/pull/3411 From dholmes at openjdk.java.net Mon Apr 12 06:21:06 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 12 Apr 2021 06:21:06 GMT Subject: RFR: 8264940: java/lang/invoke/6998541/Test6998541.java failed "guarantee(ik->is_initialized()) failed: java/lang/Byte$ByteCache must be initialized" [v2] In-Reply-To: References: <-17CHkPMQoZhr9gsnQ_1UvBDFAYUlaXCBFLQ7dGPK6g=.ebce6503-4974-41cc-8635-3b0168f02fe8@github.com> Message-ID: On Mon, 12 Apr 2021 02:10:17 GMT, Wang Huang wrote: >> * The main reason is that in this situation the `BoxCache` is not initialized before `uncommon_trap`. >> * `java.lang.Byte$ByteCache` is loaded without initializing here >> * I think that all `*Cache` classes should be loaded in this situation. > > Wang Huang has updated the pull request incrementally with one additional commit since the last revision: > > fix bug in the other way This approach looks much better to me, but I'll leave it to @vnkozlov to confirm the details. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3411 From shade at openjdk.java.net Mon Apr 12 06:23:35 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 12 Apr 2021 06:23:35 GMT Subject: RFR: 8264644: Add PrintClassLoaderDataGraphAtExit to print the detailed CLD graph [v4] In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 06:48:52 GMT, Yi Yang wrote: >> Trivial chanage to make debugging happy, now cld->print() would be: >> >> ClassLoaderData(0x00007ff17432b670) >> - name 'platform' >> - holder WeakHandle: 0x00000007fef56678 >> - class loader 0x7ff17432b828 >> - metaspace 0x7ff17468a0b0 >> - unloading false >> - class mirror holder false >> - modified oops true >> - keep alive 0 >> - claim strong >> - handles 43 >> - dependency count 0 >> - klasses {java.sql.SQLFeatureNotSupportedException,java.sql.SQLNonTransientException,java.sql.SQLException,sun.util.resources.provider.NonBaseLocaleDataMetaInfo,org.ietf.jgss.GSSException,javax.sql.DataSource,java.sql.Wrapper,javax.sql.CommonDataSource,java.sql.Time,java.sql.Date,java.sql.Timestamp,sun.util.resources.cldr.provider.CLDRLocaleDataMetaInfo, } >> - packages 0x7ff17432bc20 >> - module 0x7ff17432c520 >> - unnamed module 0x7ff17432c3d0 >> - dictionary 0x7ff17432c470 >> - deallocate list 0x7ff0a4023bd0 > > Yi Yang has updated the pull request incrementally with one additional commit since the last revision: > > INTPTR_FORMAT Looks good with a minor nit. src/hotspot/share/classfile/classLoaderData.cpp line 943: > 941: } > 942: }; > 943: void ClassLoaderData::print_on(outputStream* out) const { These declarations should be separated by a newline, I think? ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3323 From yyang at openjdk.java.net Mon Apr 12 06:48:22 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Mon, 12 Apr 2021 06:48:22 GMT Subject: RFR: 8264644: Add PrintClassLoaderDataGraphAtExit to print the detailed CLD graph [v5] In-Reply-To: References: Message-ID: > Trivial chanage to make debugging happy, now cld->print() would be: > > ClassLoaderData(0x00007ff17432b670) > - name 'platform' > - holder WeakHandle: 0x00000007fef56678 > - class loader 0x7ff17432b828 > - metaspace 0x7ff17468a0b0 > - unloading false > - class mirror holder false > - modified oops true > - keep alive 0 > - claim strong > - handles 43 > - dependency count 0 > - klasses {java.sql.SQLFeatureNotSupportedException,java.sql.SQLNonTransientException,java.sql.SQLException,sun.util.resources.provider.NonBaseLocaleDataMetaInfo,org.ietf.jgss.GSSException,javax.sql.DataSource,java.sql.Wrapper,javax.sql.CommonDataSource,java.sql.Time,java.sql.Date,java.sql.Timestamp,sun.util.resources.cldr.provider.CLDRLocaleDataMetaInfo, } > - packages 0x7ff17432bc20 > - module 0x7ff17432c520 > - unnamed module 0x7ff17432c3d0 > - dictionary 0x7ff17432c470 > - deallocate list 0x7ff0a4023bd0 Yi Yang has updated the pull request incrementally with one additional commit since the last revision: newline ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3323/files - new: https://git.openjdk.java.net/jdk/pull/3323/files/1eb6766b..070ca1a5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3323&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3323&range=03-04 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3323.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3323/head:pull/3323 PR: https://git.openjdk.java.net/jdk/pull/3323 From yyang at openjdk.java.net Mon Apr 12 06:48:23 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Mon, 12 Apr 2021 06:48:23 GMT Subject: RFR: 8264644: Add PrintClassLoaderDataGraphAtExit to print the detailed CLD graph [v4] In-Reply-To: References: Message-ID: On Mon, 12 Apr 2021 06:18:17 GMT, Aleksey Shipilev wrote: >> Yi Yang has updated the pull request incrementally with one additional commit since the last revision: >> >> INTPTR_FORMAT > > src/hotspot/share/classfile/classLoaderData.cpp line 943: > >> 941: } >> 942: }; >> 943: void ClassLoaderData::print_on(outputStream* out) const { > > These declarations should be separated by a newline, I think? Yes, I've added a new line. Thank you Aleksey. ------------- PR: https://git.openjdk.java.net/jdk/pull/3323 From dholmes at openjdk.java.net Mon Apr 12 07:11:36 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 12 Apr 2021 07:11:36 GMT Subject: RFR: 8264940: java/lang/invoke/6998541/Test6998541.java failed "guarantee(ik->is_initialized()) failed: java/lang/Byte$ByteCache must be initialized" [v2] In-Reply-To: References: <-17CHkPMQoZhr9gsnQ_1UvBDFAYUlaXCBFLQ7dGPK6g=.ebce6503-4974-41cc-8635-3b0168f02fe8@github.com> Message-ID: On Mon, 12 Apr 2021 02:10:17 GMT, Wang Huang wrote: >> * The main reason is that in this situation the `BoxCache` is not initialized before `uncommon_trap`. >> * `java.lang.Byte$ByteCache` is loaded without initializing here >> * I think that all `*Cache` classes should be loaded in this situation. > > Wang Huang has updated the pull request incrementally with one additional commit since the last revision: > > fix bug in the other way src/hotspot/share/opto/callGenerator.cpp line 31: > 29: #include "ci/ciMemberName.hpp" > 30: #include "ci/ciMethodHandle.hpp" > 31: #include "ci/ciUtilities.inline.hpp" You are also missing the #include of systemDictionary.hpp ------------- PR: https://git.openjdk.java.net/jdk/pull/3411 From ysuenaga at openjdk.java.net Mon Apr 12 07:53:16 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Mon, 12 Apr 2021 07:53:16 GMT Subject: RFR: 8263718: unused-result warning happens at os_linux.cpp [v2] In-Reply-To: References: <5W8i9Wro1OWbzlUbEyeTy4TBLQmhWysLSjDcjadMygc=.a8348509-517b-48c4-be70-68b3ddb1088b@github.com> <_fwXlba2zOGlxvF4NDbUKm7psfPRid2kZaGHTpRMlE0=.75ce10c1-f848-44fe-8d5e-70044d2fe4d9@github.com> Message-ID: On Mon, 5 Apr 2021 00:28:44 GMT, Yasumasa Suenaga wrote: >> Thanks @dholmes-ora for your review! >> >>> A summary of what we found for each platform should be put in the bug report. >> >> I left it to the [comment](https://bugs.openjdk.java.net/browse/JDK-8263718?focusedCommentId=14410190&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14410190). > > PING: could you review it? I need one more reviewer to push. Ping: could you review this change? Any comments are welcome. ------------- PR: https://git.openjdk.java.net/jdk/pull/3042 From yyang at openjdk.java.net Mon Apr 12 08:36:10 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Mon, 12 Apr 2021 08:36:10 GMT Subject: Integrated: 8264644: Add PrintClassLoaderDataGraphAtExit to print the detailed CLD graph In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 09:42:01 GMT, Yi Yang wrote: > Trivial chanage to make debugging happy, now cld->print() would be: > > > ClassLoaderData(0x00007ff17432b670) > - name 'platform' > - holder WeakHandle: 0x00000007fef56678 > - class loader 0x7ff17432b828 > - metaspace 0x7ff17468a0b0 > - unloading false > - class mirror holder false > - modified oops true > - keep alive 0 > - claim strong > - handles 43 > - dependency count 0 > - klasses {java.sql.SQLFeatureNotSupportedException,java.sql.SQLNonTransientException,java.sql.SQLException,sun.util.resources.provider.NonBaseLocaleDataMetaInfo,org.ietf.jgss.GSSException,javax.sql.DataSource,java.sql.Wrapper,javax.sql.CommonDataSource,java.sql.Time,java.sql.Date,java.sql.Timestamp,sun.util.resources.cldr.provider.CLDRLocaleDataMetaInfo, } > - packages 0x7ff17432bc20 > - module 0x7ff17432c520 > - unnamed module 0x7ff17432c3d0 > - dictionary 0x7ff17432c470 > - deallocate list 0x7ff0a4023bd0 This pull request has now been integrated. Changeset: 440c34a6 Author: Yi Yang Committer: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/440c34a6 Stats: 61 lines in 6 files changed: 47 ins; 1 del; 13 mod 8264644: Add PrintClassLoaderDataGraphAtExit to print the detailed CLD graph Reviewed-by: coleenp, dholmes, shade ------------- PR: https://git.openjdk.java.net/jdk/pull/3323 From stefank at openjdk.java.net Mon Apr 12 08:41:31 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 12 Apr 2021 08:41:31 GMT Subject: RFR: 8265052: Break circular include dependency in objArrayOop.inline.hpp Message-ID: There's a circular dependency of the includes in objArrayOop.inline.hpp. This does not show up in the current main line, but caused compilation errors in a JFR enhancement. The objArrayOop.inline.hpp can't even be compiled by itself: In file included from /home/stefank/git/alt2/open/src/hotspot/share/oops/access.inline.hpp:28, from /home/stefank/git/alt2/open/src/hotspot/share/oops/objArrayOop.inline.hpp:28: ------------- Commit messages: - 8265052: Break circular include dependency in objArrayOop.inline.hpp Changes: https://git.openjdk.java.net/jdk/pull/3431/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3431&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265052 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3431.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3431/head:pull/3431 PR: https://git.openjdk.java.net/jdk/pull/3431 From sjohanss at openjdk.java.net Mon Apr 12 08:47:42 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Mon, 12 Apr 2021 08:47:42 GMT Subject: RFR: 8262291: Refactor reserve_memory_special_huge_tlbfs [v4] In-Reply-To: References: Message-ID: <2_n9MpmoyaMms2YaKR2akPZ4yySRxeHRCi6WsSKG3_Q=.64e83959-86a8-47d7-84e8-0e73224afdd6@github.com> On Thu, 25 Mar 2021 16:01:36 GMT, Thomas Stuefe wrote: >> Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision: >> >> Self review. >> >> Update helper name to better match commit_memory_special(). > > Hi Stefan, > > this is a welcome cleanup! > > Remarks inline. > > Cheers, Thomas @tstuefe, I'm back from my leave now. Do you have any additional comments? ------------- PR: https://git.openjdk.java.net/jdk/pull/3073 From tschatzl at openjdk.java.net Mon Apr 12 09:18:59 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Mon, 12 Apr 2021 09:18:59 GMT Subject: RFR: 8265052: Break circular include dependency in objArrayOop.inline.hpp In-Reply-To: References: Message-ID: On Mon, 12 Apr 2021 08:09:00 GMT, Stefan Karlsson wrote: > There's a circular dependency of the includes in objArrayOop.inline.hpp. This does not show up in the current main line, but caused compilation errors in a JFR enhancement. > > The objArrayOop.inline.hpp can't even be compiled by itself: > > In file included from /home/stefank/git/alt2/open/src/hotspot/share/oops/access.inline.hpp:28, > from /home/stefank/git/alt2/open/src/hotspot/share/oops/objArrayOop.inline.hpp:28: Lgtm. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3431 From egahlin at openjdk.java.net Mon Apr 12 09:30:46 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Mon, 12 Apr 2021 09:30:46 GMT Subject: RFR: 8265052: Break circular include dependency in objArrayOop.inline.hpp In-Reply-To: References: Message-ID: On Mon, 12 Apr 2021 08:09:00 GMT, Stefan Karlsson wrote: > There's a circular dependency of the includes in objArrayOop.inline.hpp. This does not show up in the current main line, but caused compilation errors in a JFR enhancement. > > The objArrayOop.inline.hpp can't even be compiled by itself: > > In file included from /home/stefank/git/alt2/open/src/hotspot/share/oops/access.inline.hpp:28, > from /home/stefank/git/alt2/open/src/hotspot/share/oops/objArrayOop.inline.hpp:28: Marked as reviewed by egahlin (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3431 From sjohanss at openjdk.java.net Mon Apr 12 09:31:22 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Mon, 12 Apr 2021 09:31:22 GMT Subject: RFR: 8262291: Refactor reserve_memory_special_huge_tlbfs [v6] In-Reply-To: References: Message-ID: > Please review this refactoring of the hugetlbfs reservation code. > > **Summary** > In recent adventures in this area of the code I noticed a strange condition in `reserve_memory_special_huge_tlbfs` where we take the "mixed-mapping" route even if the size doesn't require any small pages to be used: > > if (is_aligned(bytes, os::large_page_size()) && alignment <= os::large_page_size()) { > return reserve_memory_special_huge_tlbfs_only(bytes, req_addr, exec); > } else { > return reserve_memory_special_huge_tlbfs_mixed(bytes, alignment, req_addr, exec); > } > > > The second condition here is needed because if the alignment is larger than the large page size, we needed to enforce this and can't just trust `mmap` to give us a properly aligned address. Doing this by using the mixed-function feels a bit weird and looking a bit more at this I found a way to refactor this function to avoid having the two helpers. > > Instead of only having the mixed path honor the passed down alignment, make sure that is always done. This will also have the side-effect that all large pages in a "mixed"-mapping will be at the start and then we will have a tail of small pages. This actually also ensures that we will use large pages for a mixed mapping, in the past there was a corner case where we could end up with just a head and tail of small pages and no large page in between (if the mapping was smaller than 2 large pages and there was no alignment constraint). > > **Testing** > Mach5 tier1-3 and a lot of local testing with different large page configurations. Stefan Johansson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Merge branch 'master' into 8262291-one-special-alloc - Thomas review. Changed commit_memory_special to return bool to signal if the request succeeded or not. - Self review. Update helper name to better match commit_memory_special(). - Marcus review. Updated comments. - Ivan review Renamed helper to commit_memory_special and updated the comments. - 8262291: Refactor reserve_memory_special_huge_tlbfs ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3073/files - new: https://git.openjdk.java.net/jdk/pull/3073/files/787b87fe..44936c49 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3073&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3073&range=04-05 Stats: 66087 lines in 2243 files changed: 43116 ins; 12682 del; 10289 mod Patch: https://git.openjdk.java.net/jdk/pull/3073.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3073/head:pull/3073 PR: https://git.openjdk.java.net/jdk/pull/3073 From dholmes at openjdk.java.net Mon Apr 12 09:34:41 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 12 Apr 2021 09:34:41 GMT Subject: RFR: 8265052: Break circular include dependency in objArrayOop.inline.hpp In-Reply-To: References: Message-ID: On Mon, 12 Apr 2021 08:09:00 GMT, Stefan Karlsson wrote: > There's a circular dependency of the includes in objArrayOop.inline.hpp. This does not show up in the current main line, but caused compilation errors in a JFR enhancement. > > The objArrayOop.inline.hpp can't even be compiled by itself: > > In file included from /home/stefank/git/alt2/open/src/hotspot/share/oops/access.inline.hpp:28, > from /home/stefank/git/alt2/open/src/hotspot/share/oops/objArrayOop.inline.hpp:28: Hi Stefan, Fix seems fine. Though it seems somewhat fortuitous that the inline functions used by this inline header file are actually declared in the non-inline version of the access header file. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3431 From sjohanss at openjdk.java.net Mon Apr 12 10:18:40 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Mon, 12 Apr 2021 10:18:40 GMT Subject: RFR: 8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v23] In-Reply-To: References: <_uIvdHdm5ptjZJ8gEw8AzBJ8PC-16GoEWUuKW5zAXrg=.36c2da1c-685b-4d4d-a4e5-73b3fc48b812@github.com> Message-ID: On Thu, 18 Mar 2021 12:47:40 GMT, Stefan Johansson wrote: >>> This would also give us to to think about a question I haven't made up my mind around. What will `LargePageSizeInBytes` mean after this change? Should the JVM use 1g pages (on a system where 2m i the default) even if `LargePageSizeInBytes` is not set? >> >> I see two valid scenarios: >> a) either use huge pages as best as possible; remove fine-grained control from user hands. So, if we have 1G pages, prefer those over 2M over 4K. Then, we could completely remove LargePageSizeInBytes. There is no need for this switch anymore. >> b) or keep the current behavior. In that case, UseLargePageSize means "use at most default huge page size" even if larger pages are available; and LargePageSizeInBytes can be used to override the large page size to use. >> >> (a): Its elegant, and efficiently uses system resources when available. But its an incompatible change, and the VM being grabby means we could end up using pages meant for a different process. >> (b): downward compatible. In a sense. With Marcus change, we break downward compatibility already: where "UseLargePageSizeInBytes" before meant "use that or nothing", it now means "use that or whatever smaller page sizes you find". >> >> I prefer (a), honestly. >> >> ..Thomas > >> > This would also give us to to think about a question I haven't made up my mind around. What will `LargePageSizeInBytes` mean after this change? Should the JVM use 1g pages (on a system where 2m i the default) even if `LargePageSizeInBytes` is not set? >> >> I see two valid scenarios: > > Me too. > >> a) either use huge pages as best as possible; remove fine-grained control from user hands. So, if we have 1G pages, prefer those over 2M over 4K. Then, we could completely remove LargePageSizeInBytes. There is no need for this switch anymore. > > I agree, preferably we can make it so that the upper layers can use something like `page_size_for_region*` and request a certain page size, but fall back to smaller ones. > >> b) or keep the current behavior. In that case, UseLargePageSize means "use at most default huge page size" even if larger pages are available; and LargePageSizeInBytes can be used to override the large page size to use. >> > > So it becomes more like a maximium value right? Or at least this is how I've thought about this second scenario. On a system with both 2M (the default size) and 1G pages available you would have to set `LargePageSizeInBytes=1g` to use the 1G pages, but the 2M could still be used for smaller mappings. > >> (a): Its elegant, and efficiently uses system resources when available. But its an incompatible change, and the VM being grabby means we could end up using pages meant for a different process. >> (b): downward compatible. In a sense. With Marcus change, we break downward compatibility already: where "UseLargePageSizeInBytes" before meant "use that or nothing", it now means "use that or whatever smaller page sizes you find". >> >> I prefer (a), honestly. >> > I would also prefer (a). > @kstefanj @tstuefe > > 1. Would (a) [removing fine grained control of large page [Huge Page] sizes with LargePageSizeInBytes and relying on automatic selection of sizes from available] require JEP process? > Not a JEP, but likely a CSR. If we change the meaning of `LargePageSizeInBytes` (or deprecate it) a CSR will be needed. > 2. Can we put LargePageSizeInBytes flag in DIAGNOSTIC or EXPERIMENTAL and set it otherwise to the largest available page size? This way we have the default (a) and if users want to change page size they can use diagnostic or experimental and use (b). Also this would lower the amount of change needed. I'm a bit concerned with removing LargePageSizeInBytes altogether. I don't know if some use cases would break or need more fine tuned control of page sizes. > Changing the flag to diagnostic or experimental would also require a CSR and I don't see any real benefit of doing that. > > It appears the comment in the flag supports a solution like [2] above, but we could change change to `max page size or 0 to let VM choose`: "Large page size (0 to let VM choose the page size)" > > Current LargePageSizeInBytes flag code: > > ``` > product(size_t, LargePageSizeInBytes, 0, \ > "Large page size (0 to let VM choose the page size)") \ > range(0, max_uintx) \ > ``` > Reading this I wonder if the easiest way forward would just be to keep it this way. If the flag is set, only that page size is used, if not all configured page sizes can be used. So if someone sets `LargePagesSizeInBytes` only that size will end up in the available page sizes map. I might need to think a bit more about this, but if there is no problems with that approach it would be quite nice. > I've incorporated #3073 into this change, as a good base to build on, this also seemed to be Stefan's optimal path for this change. Hopefully I can push #3073 soon, and then you can just merge master to get this code correctly. ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From whuang at openjdk.java.net Mon Apr 12 12:10:08 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Mon, 12 Apr 2021 12:10:08 GMT Subject: RFR: 8264940: java/lang/invoke/6998541/Test6998541.java failed "guarantee(ik->is_initialized()) failed: java/lang/Byte$ByteCache must be initialized" [v2] In-Reply-To: References: <-17CHkPMQoZhr9gsnQ_1UvBDFAYUlaXCBFLQ7dGPK6g=.ebce6503-4974-41cc-8635-3b0168f02fe8@github.com> Message-ID: <_FfwgQsFE2gf507Z6YbQPqwCrbdLbH1FodqfaZ8WHQA=.2b6baea3-102c-4708-8b42-ed1be07418c1@github.com> On Mon, 12 Apr 2021 07:07:27 GMT, David Holmes wrote: >> Wang Huang has updated the pull request incrementally with one additional commit since the last revision: >> >> fix bug in the other way > > src/hotspot/share/opto/callGenerator.cpp line 31: > >> 29: #include "ci/ciMemberName.hpp" >> 30: #include "ci/ciMethodHandle.hpp" >> 31: #include "ci/ciUtilities.inline.hpp" > > You are also missing the #include of systemDictionary.hpp Thank you for your review. I have fixed this problem. ------------- PR: https://git.openjdk.java.net/jdk/pull/3411 From whuang at openjdk.java.net Mon Apr 12 12:10:06 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Mon, 12 Apr 2021 12:10:06 GMT Subject: RFR: 8264940: java/lang/invoke/6998541/Test6998541.java failed "guarantee(ik->is_initialized()) failed: java/lang/Byte$ByteCache must be initialized" [v3] In-Reply-To: <-17CHkPMQoZhr9gsnQ_1UvBDFAYUlaXCBFLQ7dGPK6g=.ebce6503-4974-41cc-8635-3b0168f02fe8@github.com> References: <-17CHkPMQoZhr9gsnQ_1UvBDFAYUlaXCBFLQ7dGPK6g=.ebce6503-4974-41cc-8635-3b0168f02fe8@github.com> Message-ID: > * The main reason is that in this situation the `BoxCache` is not initialized before `uncommon_trap`. > * `java.lang.Byte$ByteCache` is loaded without initializing here > * I think that all `*Cache` classes should be loaded in this situation. Wang Huang has updated the pull request incrementally with one additional commit since the last revision: add missing header ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3411/files - new: https://git.openjdk.java.net/jdk/pull/3411/files/3c971646..6c7f9435 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3411&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3411&range=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3411.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3411/head:pull/3411 PR: https://git.openjdk.java.net/jdk/pull/3411 From sjohanss at openjdk.java.net Mon Apr 12 12:21:58 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Mon, 12 Apr 2021 12:21:58 GMT Subject: RFR: 8265064: Move clearing and setting of members into helpers in ReservedSpace Message-ID: Currently there are a few places in `ReservedSpace` that updates a set of members directly during initialization. This could be refactored into helper functions to improve readability and also to pave way for some further cleanups. This is one of a few cleanups I plan to do to enable a clean implementation of: [JDK-8261527: Record page size used for underlying mapping in ReservedSpace](https://bugs.openjdk.java.net/browse/JDK-8261527) **Testing** Mach5 tier1 and tier2. ------------- Commit messages: - Self review. - 8265064: Move clearing and setting of members into helpers in ReservedSpace Changes: https://git.openjdk.java.net/jdk/pull/3435/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3435&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265064 Stats: 83 lines in 2 files changed: 43 ins; 27 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/3435.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3435/head:pull/3435 PR: https://git.openjdk.java.net/jdk/pull/3435 From stefank at openjdk.java.net Mon Apr 12 12:36:48 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 12 Apr 2021 12:36:48 GMT Subject: RFR: 8265052: Break circular include dependency in objArrayOop.inline.hpp In-Reply-To: References: Message-ID: On Mon, 12 Apr 2021 09:32:09 GMT, David Holmes wrote: > Fix seems fine. Though it seems somewhat fortuitous that the inline functions used by this inline header file are actually declared in the non-inline version of the access header file. Yes, I agree. Thanks for reviewing @dholmes-ora and @egahlin ------------- PR: https://git.openjdk.java.net/jdk/pull/3431 From stuefe at openjdk.java.net Mon Apr 12 13:19:47 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 12 Apr 2021 13:19:47 GMT Subject: RFR: 8262291: Refactor reserve_memory_special_huge_tlbfs [v6] In-Reply-To: References: Message-ID: <-_har4xeqFlcZNPG45yUmvKa1XbkZ6gD_PvjOEY-TE8=.196a1b1c-b05d-4da5-b656-236379059f36@github.com> On Mon, 12 Apr 2021 09:31:22 GMT, Stefan Johansson wrote: >> Please review this refactoring of the hugetlbfs reservation code. >> >> **Summary** >> In recent adventures in this area of the code I noticed a strange condition in `reserve_memory_special_huge_tlbfs` where we take the "mixed-mapping" route even if the size doesn't require any small pages to be used: >> >> if (is_aligned(bytes, os::large_page_size()) && alignment <= os::large_page_size()) { >> return reserve_memory_special_huge_tlbfs_only(bytes, req_addr, exec); >> } else { >> return reserve_memory_special_huge_tlbfs_mixed(bytes, alignment, req_addr, exec); >> } >> >> >> The second condition here is needed because if the alignment is larger than the large page size, we needed to enforce this and can't just trust `mmap` to give us a properly aligned address. Doing this by using the mixed-function feels a bit weird and looking a bit more at this I found a way to refactor this function to avoid having the two helpers. >> >> Instead of only having the mixed path honor the passed down alignment, make sure that is always done. This will also have the side-effect that all large pages in a "mixed"-mapping will be at the start and then we will have a tail of small pages. This actually also ensures that we will use large pages for a mixed mapping, in the past there was a corner case where we could end up with just a head and tail of small pages and no large page in between (if the mapping was smaller than 2 large pages and there was no alignment constraint). >> >> **Testing** >> Mach5 tier1-3 and a lot of local testing with different large page configurations. > > Stefan Johansson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Merge branch 'master' into 8262291-one-special-alloc > - Thomas review. > > Changed commit_memory_special to return bool to signal if the request succeeded or not. > - Self review. > > Update helper name to better match commit_memory_special(). > - Marcus review. > > Updated comments. > - Ivan review > > Renamed helper to commit_memory_special and updated the comments. > - 8262291: Refactor reserve_memory_special_huge_tlbfs Looks good to me. Thanks, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/3073 From tschatzl at openjdk.java.net Mon Apr 12 13:53:45 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Mon, 12 Apr 2021 13:53:45 GMT Subject: RFR: 8265064: Move clearing and setting of members into helpers in ReservedSpace In-Reply-To: References: Message-ID: On Mon, 12 Apr 2021 11:59:57 GMT, Stefan Johansson wrote: > Currently there are a few places in `ReservedSpace` that updates a set of members directly during initialization. This could be refactored into helper functions to improve readability and also to pave way for some further cleanups. > > This is one of a few cleanups I plan to do to enable a clean implementation of: > [JDK-8261527: Record page size used for underlying mapping in ReservedSpace](https://bugs.openjdk.java.net/browse/JDK-8261527) > > **Testing** > Mach5 tier1 and tier2. Changes requested by tschatzl (Reviewer). src/hotspot/share/memory/virtualspace.cpp line 139: > 137: > 138: void ReservedSpace::clear_members() { > 139: _base = NULL; This method could call `initialize_members()` with the appropriate argument values, couldn't it? ------------- PR: https://git.openjdk.java.net/jdk/pull/3435 From stefank at openjdk.java.net Mon Apr 12 15:46:40 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 12 Apr 2021 15:46:40 GMT Subject: RFR: 8265052: Break circular include dependency in objArrayOop.inline.hpp In-Reply-To: References: Message-ID: On Mon, 12 Apr 2021 08:09:00 GMT, Stefan Karlsson wrote: > There's a circular dependency of the includes in objArrayOop.inline.hpp. This does not show up in the current main line, but caused compilation errors in a JFR enhancement. > > The objArrayOop.inline.hpp can't even be compiled by itself: > > In file included from /home/stefank/git/alt2/open/src/hotspot/share/oops/access.inline.hpp:28, > from /home/stefank/git/alt2/open/src/hotspot/share/oops/objArrayOop.inline.hpp:28: Build testing passed ------------- PR: https://git.openjdk.java.net/jdk/pull/3431 From stefank at openjdk.java.net Mon Apr 12 15:46:40 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 12 Apr 2021 15:46:40 GMT Subject: Integrated: 8265052: Break circular include dependency in objArrayOop.inline.hpp In-Reply-To: References: Message-ID: <8eeTstLDppAJpY3hBT9IFvmBdPa7L-hD5J0Xr8UEcUA=.c5f89117-1626-4e32-88b6-a033542f28fa@github.com> On Mon, 12 Apr 2021 08:09:00 GMT, Stefan Karlsson wrote: > There's a circular dependency of the includes in objArrayOop.inline.hpp. This does not show up in the current main line, but caused compilation errors in a JFR enhancement. > > The objArrayOop.inline.hpp can't even be compiled by itself: > > In file included from /home/stefank/git/alt2/open/src/hotspot/share/oops/access.inline.hpp:28, > from /home/stefank/git/alt2/open/src/hotspot/share/oops/objArrayOop.inline.hpp:28: This pull request has now been integrated. Changeset: 7c20d97a Author: Stefan Karlsson URL: https://git.openjdk.java.net/jdk/commit/7c20d97a Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8265052: Break circular include dependency in objArrayOop.inline.hpp Reviewed-by: tschatzl, egahlin, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/3431 From erikj at openjdk.java.net Mon Apr 12 16:21:50 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 12 Apr 2021 16:21:50 GMT Subject: RFR: 8264806: Remove the experimental JIT compiler [v2] In-Reply-To: <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com> References: <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com> Message-ID: On Fri, 9 Apr 2021 22:26:40 GMT, Vladimir Kozlov wrote: >> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK: >> >> - `jdk.internal.vm.compiler` ? the Graal compiler >> - `jdk.internal.vm.compiler.management` ? Graal's `MBean` >> - `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests >> >> Remove Graal related code in makefiles. >> >> Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build: >> >> src/jdk.internal.vm.compiler/share/classes/module-info.java >> src/jdk.internal.vm.compiler.management/share/classes/module-info.java >> >> >> @AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it. >> >> Tested hs-tier1-4 > > Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Restore Graal Builder image makefile > - Merge latest changes from branch 'JDK-8264805' into JDK-8264806 > - 8264806: Remove the experimental JIT compiler make/common/Modules.gmk line 68: > 66: > 67: # Filter out Graal specific modules > 68: MODULES_FILTER += jdk.internal.vm.compiler If we are unconditionally filtering out these modules, then why leave the module-info.java files in at all? ------------- PR: https://git.openjdk.java.net/jdk/pull/3421 From kvn at openjdk.java.net Mon Apr 12 17:22:00 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 12 Apr 2021 17:22:00 GMT Subject: RFR: 8264806: Remove the experimental JIT compiler [v2] In-Reply-To: References: <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com> Message-ID: On Mon, 12 Apr 2021 16:18:32 GMT, Erik Joelsson wrote: >> Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Restore Graal Builder image makefile >> - Merge latest changes from branch 'JDK-8264805' into JDK-8264806 >> - 8264806: Remove the experimental JIT compiler > > make/common/Modules.gmk line 68: > >> 66: >> 67: # Filter out Graal specific modules >> 68: MODULES_FILTER += jdk.internal.vm.compiler > > If we are unconditionally filtering out these modules, then why leave the module-info.java files in at all? We filter out because we can't build Graal anymore. But we need these module-info.java files because JVMCI's module-info.java references them: https://github.com/openjdk/jdk/blob/master/src/jdk.internal.vm.ci/share/classes/module-info.java#L26 Otherwise we can't build JVMCI which we continue to support. I filed followup RFE to implement Alan's suggestion to use Module API which will allow to remove these files later: https://bugs.openjdk.java.net/browse/JDK-8265091 ------------- PR: https://git.openjdk.java.net/jdk/pull/3421 From kvn at openjdk.java.net Mon Apr 12 17:59:08 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 12 Apr 2021 17:59:08 GMT Subject: RFR: 8264940: java/lang/invoke/6998541/Test6998541.java failed "guarantee(ik->is_initialized()) failed: java/lang/Byte$ByteCache must be initialized" [v3] In-Reply-To: References: <-17CHkPMQoZhr9gsnQ_1UvBDFAYUlaXCBFLQ7dGPK6g=.ebce6503-4974-41cc-8635-3b0168f02fe8@github.com> Message-ID: On Mon, 12 Apr 2021 12:10:06 GMT, Wang Huang wrote: >> * The main reason is that in this situation the `BoxCache` is not initialized before `uncommon_trap`. >> * `java.lang.Byte$ByteCache` is loaded without initializing here >> * I think that all `*Cache` classes should be loaded in this situation. > > Wang Huang has updated the pull request incrementally with one additional commit since the last revision: > > add missing header src/hotspot/share/opto/callGenerator.cpp line 595: > 593: return false; > 594: } > 595: The code is correct but, please, move this new code into ciInstanceKlass (near other `box` queries). The VM queries should be done in CI. static bool is_box_cache_valid(CallNode* call) { ciInstanceKlass* klass = call->as_CallStaticJava()->method()->holder(); return klass->is_box_cache_valid(); } ------------- PR: https://git.openjdk.java.net/jdk/pull/3411 From erikj at openjdk.java.net Mon Apr 12 20:58:35 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 12 Apr 2021 20:58:35 GMT Subject: RFR: 8264806: Remove the experimental JIT compiler [v2] In-Reply-To: References: <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com> Message-ID: <7HS0ES8bIxSFNXrIiGQRIgm5w30UQqGIHP7TmfWNDAg=.3a2af723-79ee-4ce8-9e1c-3873b09ed9c0@github.com> On Mon, 12 Apr 2021 17:18:36 GMT, Vladimir Kozlov wrote: >> make/common/Modules.gmk line 68: >> >>> 66: >>> 67: # Filter out Graal specific modules >>> 68: MODULES_FILTER += jdk.internal.vm.compiler >> >> If we are unconditionally filtering out these modules, then why leave the module-info.java files in at all? > > We filter out because we can't build Graal anymore. But we need these module-info.java files because JVMCI's module-info.java references them: > https://github.com/openjdk/jdk/blob/master/src/jdk.internal.vm.ci/share/classes/module-info.java#L26 > > Otherwise we can't build JVMCI which we continue to support. > > I filed followup RFE to implement Alan's suggestion to use Module API which will allow to remove these files later: > https://bugs.openjdk.java.net/browse/JDK-8265091 Right, I thought I saw something about modules that Alan commented on, but couldn't find it. All good then. ------------- PR: https://git.openjdk.java.net/jdk/pull/3421 From erikj at openjdk.java.net Mon Apr 12 20:58:32 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 12 Apr 2021 20:58:32 GMT Subject: RFR: 8264806: Remove the experimental JIT compiler [v2] In-Reply-To: <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com> References: <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com> Message-ID: On Fri, 9 Apr 2021 22:26:40 GMT, Vladimir Kozlov wrote: >> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK: >> >> - `jdk.internal.vm.compiler` ? the Graal compiler >> - `jdk.internal.vm.compiler.management` ? Graal's `MBean` >> - `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests >> >> Remove Graal related code in makefiles. >> >> Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build: >> >> src/jdk.internal.vm.compiler/share/classes/module-info.java >> src/jdk.internal.vm.compiler.management/share/classes/module-info.java >> >> >> @AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it. >> >> Tested hs-tier1-4 > > Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Restore Graal Builder image makefile > - Merge latest changes from branch 'JDK-8264805' into JDK-8264806 > - 8264806: Remove the experimental JIT compiler Build changes look good. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3421 From kvn at openjdk.java.net Mon Apr 12 22:10:06 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 12 Apr 2021 22:10:06 GMT Subject: RFR: 8264806: Remove the experimental JIT compiler [v3] In-Reply-To: References: Message-ID: > As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK: > > - `jdk.internal.vm.compiler` ? the Graal compiler > - `jdk.internal.vm.compiler.management` ? Graal's `MBean` > - `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests > > Remove Graal related code in makefiles. > > Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build: > > src/jdk.internal.vm.compiler/share/classes/module-info.java > src/jdk.internal.vm.compiler.management/share/classes/module-info.java > > > @AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it. > > Tested hs-tier1-4 Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: Restore Compiler::isGraalEnabled() ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3421/files - new: https://git.openjdk.java.net/jdk/pull/3421/files/a246aaa6..9d6bd42c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3421&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3421&range=01-02 Stats: 25 lines in 1 file changed: 23 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3421.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3421/head:pull/3421 PR: https://git.openjdk.java.net/jdk/pull/3421 From kvn at openjdk.java.net Mon Apr 12 22:26:09 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 12 Apr 2021 22:26:09 GMT Subject: RFR: 8264806: Remove the experimental JIT compiler [v2] In-Reply-To: References: <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com> Message-ID: On Sun, 11 Apr 2021 10:25:47 GMT, Doug Simon wrote: >> Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Restore Graal Builder image makefile >> - Merge latest changes from branch 'JDK-8264805' into JDK-8264806 >> - 8264806: Remove the experimental JIT compiler > > We would definitely like to be able to continue testing of GraalVM with the JDK set of jtreg tests. So keeping `Compiler::isGraalEnabled()` working like it does today is important. @dougxc I restored Compiler::isGraalEnabled(). ------------- PR: https://git.openjdk.java.net/jdk/pull/3421 From iklam at openjdk.java.net Tue Apr 13 02:09:12 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 13 Apr 2021 02:09:12 GMT Subject: RFR: 8265103: Remove unnecessary inclusion of oopMap.hpp Message-ID: oopMap.hpp is included by about 585 out of about 1000 .o files in HotSpot. In turn, it pulls in other complex headers such as vmreg.hpp, register.hpp and their cpu-dependent headers. There are only 4 header files that include oopMap.hpp. All of these can be replaced for forward declarations. According to https://github.com/iklam/tools/tree/main/headers [before] ------------- Commit messages: - fixed copyright year - removed unrelated changes - 8265103: Remove unnecessary inclusion of oopMap.hpp Changes: https://git.openjdk.java.net/jdk/pull/3446/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3446&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265103 Stats: 75 lines in 53 files changed: 58 ins; 4 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/3446.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3446/head:pull/3446 PR: https://git.openjdk.java.net/jdk/pull/3446 From whuang at openjdk.java.net Tue Apr 13 02:35:22 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Tue, 13 Apr 2021 02:35:22 GMT Subject: RFR: 8264940: java/lang/invoke/6998541/Test6998541.java failed "guarantee(ik->is_initialized()) failed: java/lang/Byte$ByteCache must be initialized" [v3] In-Reply-To: References: <-17CHkPMQoZhr9gsnQ_1UvBDFAYUlaXCBFLQ7dGPK6g=.ebce6503-4974-41cc-8635-3b0168f02fe8@github.com> Message-ID: On Mon, 12 Apr 2021 17:55:47 GMT, Vladimir Kozlov wrote: >> Wang Huang has updated the pull request incrementally with one additional commit since the last revision: >> >> add missing header > > src/hotspot/share/opto/callGenerator.cpp line 595: > >> 593: return false; >> 594: } >> 595: > > The code is correct but, please, move this new code into ciInstanceKlass (near other `box` queries). The VM queries should be done in CI. > > static bool is_box_cache_valid(CallNode* call) { > ciInstanceKlass* klass = call->as_CallStaticJava()->method()->holder(); > return klass->is_box_cache_valid(); > } I have cleaned these codes. Thank you for your review. ------------- PR: https://git.openjdk.java.net/jdk/pull/3411 From whuang at openjdk.java.net Tue Apr 13 02:35:21 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Tue, 13 Apr 2021 02:35:21 GMT Subject: RFR: 8264940: java/lang/invoke/6998541/Test6998541.java failed "guarantee(ik->is_initialized()) failed: java/lang/Byte$ByteCache must be initialized" [v4] In-Reply-To: <-17CHkPMQoZhr9gsnQ_1UvBDFAYUlaXCBFLQ7dGPK6g=.ebce6503-4974-41cc-8635-3b0168f02fe8@github.com> References: <-17CHkPMQoZhr9gsnQ_1UvBDFAYUlaXCBFLQ7dGPK6g=.ebce6503-4974-41cc-8635-3b0168f02fe8@github.com> Message-ID: > * The main reason is that in this situation the `BoxCache` is not initialized before `uncommon_trap`. > * `java.lang.Byte$ByteCache` is loaded without initializing here > * I think that all `*Cache` classes should be loaded in this situation. Wang Huang has updated the pull request incrementally with one additional commit since the last revision: refactor ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3411/files - new: https://git.openjdk.java.net/jdk/pull/3411/files/6c7f9435..3cde7f94 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3411&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3411&range=02-03 Stats: 48 lines in 3 files changed: 26 ins; 21 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3411.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3411/head:pull/3411 PR: https://git.openjdk.java.net/jdk/pull/3411 From dholmes at openjdk.java.net Tue Apr 13 03:59:59 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 13 Apr 2021 03:59:59 GMT Subject: RFR: 8264940: java/lang/invoke/6998541/Test6998541.java failed "guarantee(ik->is_initialized()) failed: java/lang/Byte$ByteCache must be initialized" [v4] In-Reply-To: References: <-17CHkPMQoZhr9gsnQ_1UvBDFAYUlaXCBFLQ7dGPK6g=.ebce6503-4974-41cc-8635-3b0168f02fe8@github.com> Message-ID: <8xpRzyLd65jHpeI-WdZsaGs8rDnBP3TbRvARE1k8_fE=.027cddf7-cd60-4757-98ae-2e125c57b700@github.com> On Tue, 13 Apr 2021 02:35:21 GMT, Wang Huang wrote: >> * The main reason is that in this situation the `BoxCache` is not initialized before `uncommon_trap`. >> * `java.lang.Byte$ByteCache` is loaded without initializing here >> * I think that all `*Cache` classes should be loaded in this situation. > > Wang Huang has updated the pull request incrementally with one additional commit since the last revision: > > refactor Looks fine - just a missing include. Thanks, David src/hotspot/share/ci/ciInstanceKlass.cpp line 287: > 285: static bool is_klass_initialized(Symbol* klass_name) { > 286: VM_ENTRY_MARK; > 287: InstanceKlass* ik = SystemDictionary::find_instance_klass(klass_name, Handle(), Handle()); You need the #include for systemDictionary.hpp in this file now. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3411 From dholmes at openjdk.java.net Tue Apr 13 04:08:58 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 13 Apr 2021 04:08:58 GMT Subject: RFR: 8265103: Remove unnecessary inclusion of oopMap.hpp In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 01:55:13 GMT, Ioi Lam wrote: > oopMap.hpp is included by about 585 out of about 1000 .o files in HotSpot. In turn, it pulls in other complex headers such as vmreg.hpp, register.hpp and their cpu-dependent headers. > > There are only 4 header files that include oopMap.hpp. All of these can be replaced for forward declarations. > > According to https://github.com/iklam/tools/tree/main/headers > > > [before] Seems okay. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3446 From whuang at openjdk.java.net Tue Apr 13 04:31:16 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Tue, 13 Apr 2021 04:31:16 GMT Subject: RFR: 8264940: java/lang/invoke/6998541/Test6998541.java failed "guarantee(ik->is_initialized()) failed: java/lang/Byte$ByteCache must be initialized" [v5] In-Reply-To: <-17CHkPMQoZhr9gsnQ_1UvBDFAYUlaXCBFLQ7dGPK6g=.ebce6503-4974-41cc-8635-3b0168f02fe8@github.com> References: <-17CHkPMQoZhr9gsnQ_1UvBDFAYUlaXCBFLQ7dGPK6g=.ebce6503-4974-41cc-8635-3b0168f02fe8@github.com> Message-ID: > * The main reason is that in this situation the `BoxCache` is not initialized before `uncommon_trap`. > * `java.lang.Byte$ByteCache` is loaded without initializing here > * I think that all `*Cache` classes should be loaded in this situation. Wang Huang has updated the pull request incrementally with one additional commit since the last revision: adjust headers ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3411/files - new: https://git.openjdk.java.net/jdk/pull/3411/files/3cde7f94..6cbb39fb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3411&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3411&range=03-04 Stats: 3 lines in 2 files changed: 1 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3411.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3411/head:pull/3411 PR: https://git.openjdk.java.net/jdk/pull/3411 From whuang at openjdk.java.net Tue Apr 13 04:31:17 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Tue, 13 Apr 2021 04:31:17 GMT Subject: RFR: 8264940: java/lang/invoke/6998541/Test6998541.java failed "guarantee(ik->is_initialized()) failed: java/lang/Byte$ByteCache must be initialized" [v4] In-Reply-To: <8xpRzyLd65jHpeI-WdZsaGs8rDnBP3TbRvARE1k8_fE=.027cddf7-cd60-4757-98ae-2e125c57b700@github.com> References: <-17CHkPMQoZhr9gsnQ_1UvBDFAYUlaXCBFLQ7dGPK6g=.ebce6503-4974-41cc-8635-3b0168f02fe8@github.com> <8xpRzyLd65jHpeI-WdZsaGs8rDnBP3TbRvARE1k8_fE=.027cddf7-cd60-4757-98ae-2e125c57b700@github.com> Message-ID: <_BkokNdefmOVfcG9e4Bas60z97EL5vWriN949JmGZXs=.5ad6833c-540a-4b86-83e5-10bea18ee8b0@github.com> On Tue, 13 Apr 2021 03:55:58 GMT, David Holmes wrote: >> Wang Huang has updated the pull request incrementally with one additional commit since the last revision: >> >> refactor > > src/hotspot/share/ci/ciInstanceKlass.cpp line 287: > >> 285: static bool is_klass_initialized(Symbol* klass_name) { >> 286: VM_ENTRY_MARK; >> 287: InstanceKlass* ik = SystemDictionary::find_instance_klass(klass_name, Handle(), Handle()); > > You need the #include for systemDictionary.hpp in this file now. Yes. Thank you for your review. I have adjusted headers in the latest patch. ------------- PR: https://git.openjdk.java.net/jdk/pull/3411 From david.holmes at oracle.com Tue Apr 13 04:46:23 2021 From: david.holmes at oracle.com (David Holmes) Date: Tue, 13 Apr 2021 14:46:23 +1000 Subject: RFR: 8262896: [macos_aarch64] Crash in jni_fast_GetLongField In-Reply-To: <-z566EC0VCwqMkAGtW5Pz7_dyFjrht5qGHXL8Ba4lNQ=.4b5da342-f167-4a21-9fc3-bff50e7228fb@github.com> References: <-z566EC0VCwqMkAGtW5Pz7_dyFjrht5qGHXL8Ba4lNQ=.4b5da342-f167-4a21-9fc3-bff50e7228fb@github.com> Message-ID: <4e4ce450-2a62-2ae6-c55b-f554360186d0@oracle.com> Hi Anton, On 10/04/2021 4:32 am, Anton Kozlov wrote: > Hi, please review a fix for a random crash on macos/aarch64. > > By default, GetXXXField JNI Interface implementation is a generated function (-XX:+UseFastJNIAccessors). Usually the function is called by JNI code running in WXExec mode and everything is fine. But sometime we attempt to call it in WXWrite context, like in the stack trace attached to the bug: > > v ~BufferBlob::jni_fast_GetLongField > V [libjvm.dylib+0x7a6538] Perf_Detach+0x168 I'm struggling to see how we get to the jni_fast_GetLongField from Perf_Detach ?? > j jdk.internal.perf.Perf.detach(Ljava/nio/ByteBuffer;)V+0 java.base at 17-internal > j jdk.internal.perf.Perf$CleanerAction.run()V+8 java.base at 17-internal > j jdk.internal.ref.CleanerImpl$PhantomCleanableRef.performCleanup()V+4 java.base at 17-internal > j jdk.internal.ref.PhantomCleanable.clean()V+12 java.base at 17-internal > j jdk.internal.ref.CleanerImpl.run()V+57 java.base at 17-internal > j java.lang.Thread.run()V+11 java.base at 17-internal > j jdk.internal.misc.InnocuousThread.run()V+20 java.base at 17-internal > v ~StubRoutines::call_stub > > One way to fix the bug is to ensure WXExec mode before calling GetXXXField, but it depends on finding and fixing all such cases. > > This patch instead adds additional actions to GetXXXField implementation to ensure correct W^X mode regardless if it is called from WXWrite or WXExec mode. Once again I'm finding it very hard to understand what the actual rules are for these W^X mode changes and what code requires what. IIUC the normal(?) mode is WXExec and we use that when executing JITed or other native code. But if we enter the VM we need to switch to WXWrite mode. So that is what the PERF_ENTRY (via JVM_ENTRY) does for Perf_Detach. But for some reason these generated fast-accessors need to be run in WXExec mode. So IIUC the transitions that are already in place for executing "VM code" are going to be wrong any time that VM code ends up executing something like a fast-accessor - is that the case? And what other code is in the same category as these generated fast-accessors? Thanks, David > ------------- > > Commit messages: > - Add W^X in FastGetXXXField > > Changes: https://git.openjdk.java.net/jdk/pull/3422/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3422&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8262896 > Stats: 69 lines in 3 files changed: 61 ins; 0 del; 8 mod > Patch: https://git.openjdk.java.net/jdk/pull/3422.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/3422/head:pull/3422 > > PR: https://git.openjdk.java.net/jdk/pull/3422 > From kvn at openjdk.java.net Tue Apr 13 05:14:57 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Tue, 13 Apr 2021 05:14:57 GMT Subject: RFR: 8264940: java/lang/invoke/6998541/Test6998541.java failed "guarantee(ik->is_initialized()) failed: java/lang/Byte$ByteCache must be initialized" [v5] In-Reply-To: References: <-17CHkPMQoZhr9gsnQ_1UvBDFAYUlaXCBFLQ7dGPK6g=.ebce6503-4974-41cc-8635-3b0168f02fe8@github.com> Message-ID: On Tue, 13 Apr 2021 04:31:16 GMT, Wang Huang wrote: >> * The main reason is that in this situation the `BoxCache` is not initialized before `uncommon_trap`. >> * `java.lang.Byte$ByteCache` is loaded without initializing here >> * I think that all `*Cache` classes should be loaded in this situation. > > Wang Huang has updated the pull request incrementally with one additional commit since the last revision: > > adjust headers Good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3411 From thomas.stuefe at gmail.com Tue Apr 13 05:30:41 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 13 Apr 2021 07:30:41 +0200 Subject: Request For Comment: Asynchronous Logging In-Reply-To: <7FEF3035-8926-467C-AD7B-A001A9C8FD5B@amazon.com> References: <7FEF3035-8926-467C-AD7B-A001A9C8FD5B@amazon.com> Message-ID: Hi Xin & others, Sorry for the late response, I had vacation. As I wrote before, I think this is a valuable improvement. I would be unhappy if this were stalled further. In this thread there seems to be a majority opinion now for - having an own thread instead of using the WatcherThread - having a global option for async (good point, Ioi) AFAICS the only POC left is the question whether to make the sizing option a memory size or a "number of entries". I argued for the memory size before, but won't insist on it, in order to move this issue forward (we could always just keep that option diagnostic). Is there anything else left to discuss? I mentioned before that I think UL is too complex and could benefit from simplification; but this is clearly not Xins fault, and I am sorry that I brought this even up here, since it has nothing to do with this RFE. Cheers, Thomas On Tue, Mar 30, 2021 at 11:21 PM Liu, Xin wrote: > Thanks Volker for this. I would like to append some additional materials. > I forgot to mention them when I wrote the Rationale[5] yesterday. > > We identified and root-caused the tail-latency on a Linux system with > software RAID in 2018. > We have different implementations on jdk8u and jdk11u. We are seeking to > merge this feature to tip. > > Nonetheless, it doesn't mean "async-logging facility" only solves Amazon's > peculiar problem. When we studied this, we found many interesting > references. > Eg. LinkedIn reported and analyzed it well[1]. In particular, they > mentioned that one reason was Linux cache writeback [2]. IMHO, that could > impact > almost all mass-storge Linux filesystems. Twitter also expressed that "I > would love to hear if this can happen with OpenJDK!"[3]. This is also > reported > by other companies[4]. > > Thanks, > --lx > > > [1] > https://engineering.linkedin.com/blog/2016/02/eliminating-large-jvm-gc-pauses-caused-by-background-io-traffic > [2] > https://yoshinorimatsunobu.blogspot.com/2014/03/why-buffered-writes-are-sometimes.html > [3] https://www.evanjones.ca/jvm-mmap-pause-finding.html > [4] > https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-June/042301.html > [5] https://github.com/openjdk/jdk/pull/3135#issuecomment-809942487 > > ?On 3/30/21, 11:20 AM, "Volker Simonis" wrote: > > CAUTION: This email originated from outside of the organization. Do > not click links or open attachments unless you can confirm the sender and > know the content is safe. > > > > Hi, > > I'd like to (re)start a discussion on asynchronous logging [1,2,3,4]. > We are successfully using this feature productively at Amazon both in > jdk8 and jdk11 to reduce the tail latency of services which use > logging. We think that async logging is a useful addition to the > current logging framework which might be beneficial to a wider range > of users. The following write-up tries to capture the comments and > suggestions from the previous discussions we are aware of. > > Current state: > > - HotSpot uses the so called "Unified Logging" (UL) framework which > was introduced by JEP 158 [5] in JDK 9. Most logs have been > retrofitted to use UL since then (e.g. "JEP 271: Unified GC Logging" > [6]). > - The current UL implementation is based on the standard C buffered > stream I/O interface [7]. The LogFileStreamOutput class which writes > logs to abstract FILE streams is the only child of the abstract base > class LogOutput. LogFileStreamOutput has three child classes > LogStdoutOutput, LogStderrOutput and LogFileOutput which write to > stdout, stderr or an arbitrary file respectively. The initial UL JEP > 158 [5] envisioned logging to a socket but has not implemented it. At > least one such extension has been proposed since then [8]. > - UL synchronizes logs from different threads with the help of the > standard C flockfile()/funlockfile() [9] functions. But even without > this explicit locking, all the "stdio functions are thread-safe. This > is achieved by assigning to each FILE object a lockcount and (if the > lockcount is nonzero) an owning thread. For each library call, these > functions wait until the FILE object is no longer locked by a > different thread, then lock it, do the requested I/O, and unlock the > object again" [9]. A quick look at the glibc sources reveals that FILE > locking is implemented with the help of futex() [10] which breaks down > to s simple atomic compare and swap (CAS) on the fast path. > - Notice that UL "synchronizes" logs from different threads to avoid > log interleaving. But it does not "serialize" logs according to the > time at which they occurred. This is because the underlying stdio > functions do not guarantee a specific order for different threads > waiting on a locked FILE stream. E.g. if three log events A, B, C > occur in that order, the first will lock the output stream. If the log > events B and C both arrive while the stream is locked, it is > unspecified which of B and C will be logged first after A releases the > lock. > > Problem statement: > > - The amount of time a log event will block its FILE stream depends on > the underlying file system. This can range from a few nanoseconds for > in-memory file systems or milliseconds for physical discs under heavy > load up to several seconds in the worst case scenario for e.g. network > file systems. A blocked log output stream will block all concurrent > threads which try to write log messages at the same time. If logging > is done during a safepoint, this can significantly increase the > safepoint time (e.g. several parallel GC threads trying to log at the > same time). We can treat stdout/stderr as special files here without > loss of generality. > > Proposed solution: > > Extend UL with an asynchronous logging facility. Asynchronous logging > will be optional and disabled by default. It should have the following > properties: > - If disabled (the default) asynchronous logging should have no > observable impact on logging. > - If enabled, log messages will be stored in an intermediate data > structure (e.g. a double ended queue). > - A service thread will concurrently read and remove log messages from > that data structure in a FIFO style and write them to the output > stream > - Storing log messages in the intermediate data structure should take > constant time and not longer than logging a message takes in the > traditional UL system (in general the time should be much shorter > because the actual I/O is deferred). > - Asynchronous logging trades memory overhead (i.e. the size of the > intermediate data structure) for log accuracy. This means that in the > unlikely case where the service thread which does the asynchronous > logging falls behind the log producing threads, some logs might be > lost. However, the probability for this to happen can be minimized by > increasing the configurable size of the intermediate data structure. > - The final output produced by asynchronous logging should be equal to > the output from normal logging if no messages had to be dropped. > Notice that in contrast to the traditional unified logging, > asynchronous logging will give us the possibility to not only > synchronize log events, but to optionally also serialize them based on > their generation time if that's desired. This is because we are in > full control of the synchronization primitives for the intermediate > data structure which stores the logs. > - If log messages had to be dropped, this should be logged in the log > output (e.g. "[..] 42 messages dropped due to async logging") > - Asynchronous logging should ideally be implemented in such a way > that it can be easily adapted by alternative log targets like for > example sockets in the future. > > Alternative solutions: > - It has repeatedly been suggested to place the log files into a > memory file system but we don't think this is an optimal solution. > Main memory is often a constrained resource and we don't want log > files to compete with the JVM for it in such cases. > - It has also been argued to place the log files on a fast file system > which is only used for logging but in containerized environments file > system are often virtualized and the properties of the underlying > physical devices are not obvious. > - The load on the file system might be unpredictable due to other > applications on the same host. > - All these workarounds won't work if we eventually implement direct > logging to a network socket as suggested in [8]. > > Implementation details / POC: > > - A recent pull request [2] for JDK-8229517 [3] proposed to use a > simple deque implementation derived from HotSpot's LinkedListImpl > class for the intermediate data structure. It synchronizes access to > the queue with a MutexLocker which is internally implemented with > pthread_lock() and results in an atomic CAS on the fast path. So > performance-wise the locking itself is not different from the > flockfile()/funlockfile() functionality currently used by UL but > adding a log message to the deque should be constant as it basically > only requires a strdup(). And we could even eliminate the strdup() if > we'd pre-allocate a big enough array for holding the log messages as > proposed in the pull request [2]. > - The pull pull request [2] for JDK-8229517 [3] proposed to set the > async flag as an attribute of the Xlog option which feels more natural > because UL configuration is traditionally done within the Xlog option. > But we could just as well use a global -XX flag to enable async > logging? What are your preferences here? > - The pull pull request [2] for JDK-8229517 [3] (mis)uses the > WatcherThread as service thread to concurrently process the > intermediate data structure and write the log messages out to the log > stream. That should definitely be changed to an independent service > thread. > - The pull pull request [2] for JDK-8229517 [3] initially proposed > that the "service thread" runs at a fixed interval to dump log > messages to the log streams. But reviewers commented that this should > better happen either continuously or based on the filling level of the > intermediate data structure. What are your preferences here? > - What are your preferences on the configuration of the intermediate > data structure? Should it be configured based on the maximum number of > log messages it can store or rather on the total size of the stored > log messages? I think that for normal runs this distinction probably > won't make a big difference because the size of log messages will > probably be the same on average so "number of log messages" should > always be proportional to "total size of log mesages". > > 1. Before diving into more implementation details, I'd first like to > reach a general consensus that asynchronous logging is a useful > feature that's worth while adding to HotSpot. > > 2. Once we agree on that, we should agree on the desired properties of > asynchronous logging. I've tried to collect a basic set in the > "Proposed solution" section. > > 3. If that's done as well, we can discuss various implementation > details and finally prepare new pull requests. > > Thank you and best regards, > Volker > > [1] https://bugs.openjdk.java.net/browse/JDK-8229517 > [2] https://github.com/openjdk/jdk/pull/3135 > [3] > https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-November/043427.html > [4] > https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-August/039130.html > [5] https://openjdk.java.net/jeps/158 > [6] https://openjdk.java.net/jeps/271 > [7] https://man7.org/linux/man-pages/man3/stdio.3.html > [8] https://gist.github.com/YaSuenag/dacb6d94d8684915422232c7a08d5b5d > [9] https://man7.org/linux/man-pages/man3/flockfile.3.html > [10] https://man7.org/linux/man-pages/man2/futex.2.html > > From sjohanss at openjdk.java.net Tue Apr 13 06:53:57 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Tue, 13 Apr 2021 06:53:57 GMT Subject: RFR: 8265064: Move clearing and setting of members into helpers in ReservedSpace In-Reply-To: References: Message-ID: On Mon, 12 Apr 2021 13:48:14 GMT, Thomas Schatzl wrote: >> Currently there are a few places in `ReservedSpace` that updates a set of members directly during initialization. This could be refactored into helper functions to improve readability and also to pave way for some further cleanups. >> >> This is one of a few cleanups I plan to do to enable a clean implementation of: >> [JDK-8261527: Record page size used for underlying mapping in ReservedSpace](https://bugs.openjdk.java.net/browse/JDK-8261527) >> >> **Testing** >> Mach5 tier1 and tier2. > > src/hotspot/share/memory/virtualspace.cpp line 139: > >> 137: >> 138: void ReservedSpace::clear_members() { >> 139: _base = NULL; > > This method could call `initialize_members()` with the appropriate argument values, couldn't it? Yes. I tried that as well, but then I called it `set_members()` because calling `initialize_members()` from `clear_members()` felt a bit backwards. The reason I didn't go with this approach was that I preferred the name `initialize_members()`. But I'll make the change and call initialize from clear, it's pretty obvious what is going on. ------------- PR: https://git.openjdk.java.net/jdk/pull/3435 From stefank at openjdk.java.net Tue Apr 13 07:06:00 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Tue, 13 Apr 2021 07:06:00 GMT Subject: RFR: 8265103: Remove unnecessary inclusion of oopMap.hpp In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 01:55:13 GMT, Ioi Lam wrote: > oopMap.hpp is included by about 585 out of about 1000 .o files in HotSpot. In turn, it pulls in other complex headers such as vmreg.hpp, register.hpp and their cpu-dependent headers. > > There are only 4 header files that include oopMap.hpp. All of these can be replaced for forward declarations. > > According to https://github.com/iklam/tools/tree/main/headers > > > [before] Marked as reviewed by stefank (Reviewer). src/hotspot/share/c1/c1_LinearScan.hpp line 34: > 32: #include "c1/c1_LIR.hpp" > 33: #include "c1/c1_LIRGenerator.hpp" > 34: #include "compiler/oopMap.hpp" The description states: > There are only 4 header files that include oopMap.hpp. All of these can be replaced for forward declarations. But this had to be added. Did you check how many files include c1_LinearScan.hpp? ------------- PR: https://git.openjdk.java.net/jdk/pull/3446 From iklam at openjdk.java.net Tue Apr 13 07:12:59 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 13 Apr 2021 07:12:59 GMT Subject: RFR: 8265103: Remove unnecessary inclusion of oopMap.hpp In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 07:02:34 GMT, Stefan Karlsson wrote: > The description states: > > > There are only 4 header files that include oopMap.hpp. All of these can be replaced for forward declarations. > > But this had to be added. Did you check how many files include c1_LinearScan.hpp? c1_LinearScan.hpp is included in only 6 .o files. ------------- PR: https://git.openjdk.java.net/jdk/pull/3446 From sjohanss at openjdk.java.net Tue Apr 13 07:13:25 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Tue, 13 Apr 2021 07:13:25 GMT Subject: RFR: 8265064: Move clearing and setting of members into helpers in ReservedSpace [v2] In-Reply-To: References: Message-ID: > Currently there are a few places in `ReservedSpace` that updates a set of members directly during initialization. This could be refactored into helper functions to improve readability and also to pave way for some further cleanups. > > This is one of a few cleanups I plan to do to enable a clean implementation of: > [JDK-8261527: Record page size used for underlying mapping in ReservedSpace](https://bugs.openjdk.java.net/browse/JDK-8261527) > > **Testing** > Mach5 tier1 and tier2. Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision: Thomas review. Using initialize_members() in clear_members(). ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3435/files - new: https://git.openjdk.java.net/jdk/pull/3435/files/de6e48b9..cd9f0816 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3435&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3435&range=00-01 Stats: 6 lines in 1 file changed: 0 ins; 5 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3435.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3435/head:pull/3435 PR: https://git.openjdk.java.net/jdk/pull/3435 From stefank at openjdk.java.net Tue Apr 13 07:17:59 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Tue, 13 Apr 2021 07:17:59 GMT Subject: RFR: 8265103: Remove unnecessary inclusion of oopMap.hpp In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 07:09:55 GMT, Ioi Lam wrote: >> src/hotspot/share/c1/c1_LinearScan.hpp line 34: >> >>> 32: #include "c1/c1_LIR.hpp" >>> 33: #include "c1/c1_LIRGenerator.hpp" >>> 34: #include "compiler/oopMap.hpp" >> >> The description states: >>> There are only 4 header files that include oopMap.hpp. All of these can be replaced for forward declarations. >> >> But this had to be added. Did you check how many files include c1_LinearScan.hpp? > >> The description states: >> >> > There are only 4 header files that include oopMap.hpp. All of these can be replaced for forward declarations. >> >> But this had to be added. Did you check how many files include c1_LinearScan.hpp? > > c1_LinearScan.hpp is included in only 6 .o files. Great! ------------- PR: https://git.openjdk.java.net/jdk/pull/3446 From sjohanss at openjdk.java.net Tue Apr 13 07:27:03 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Tue, 13 Apr 2021 07:27:03 GMT Subject: RFR: 8262291: Refactor reserve_memory_special_huge_tlbfs [v6] In-Reply-To: <-_har4xeqFlcZNPG45yUmvKa1XbkZ6gD_PvjOEY-TE8=.196a1b1c-b05d-4da5-b656-236379059f36@github.com> References: <-_har4xeqFlcZNPG45yUmvKa1XbkZ6gD_PvjOEY-TE8=.196a1b1c-b05d-4da5-b656-236379059f36@github.com> Message-ID: On Mon, 12 Apr 2021 13:17:04 GMT, Thomas Stuefe wrote: >> Stefan Johansson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: >> >> - Merge branch 'master' into 8262291-one-special-alloc >> - Thomas review. >> >> Changed commit_memory_special to return bool to signal if the request succeeded or not. >> - Self review. >> >> Update helper name to better match commit_memory_special(). >> - Marcus review. >> >> Updated comments. >> - Ivan review >> >> Renamed helper to commit_memory_special and updated the comments. >> - 8262291: Refactor reserve_memory_special_huge_tlbfs > > Looks good to me. > > Thanks, Thomas Thanks @tstuefe, you have to actively approve the PR to make it ready for integration since you are the only Reviewer. ------------- PR: https://git.openjdk.java.net/jdk/pull/3073 From tschatzl at openjdk.java.net Tue Apr 13 07:51:59 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Tue, 13 Apr 2021 07:51:59 GMT Subject: RFR: 8265064: Move clearing and setting of members into helpers in ReservedSpace [v2] In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 07:13:25 GMT, Stefan Johansson wrote: >> Currently there are a few places in `ReservedSpace` that updates a set of members directly during initialization. This could be refactored into helper functions to improve readability and also to pave way for some further cleanups. >> >> This is one of a few cleanups I plan to do to enable a clean implementation of: >> [JDK-8261527: Record page size used for underlying mapping in ReservedSpace](https://bugs.openjdk.java.net/browse/JDK-8261527) >> >> **Testing** >> Mach5 tier1 and tier2. > > Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision: > > Thomas review. > > Using initialize_members() in clear_members(). Lgtm. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3435 From iwalulya at openjdk.java.net Tue Apr 13 08:19:03 2021 From: iwalulya at openjdk.java.net (Ivan Walulya) Date: Tue, 13 Apr 2021 08:19:03 GMT Subject: RFR: 8265064: Move clearing and setting of members into helpers in ReservedSpace [v2] In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 07:13:25 GMT, Stefan Johansson wrote: >> Currently there are a few places in `ReservedSpace` that updates a set of members directly during initialization. This could be refactored into helper functions to improve readability and also to pave way for some further cleanups. >> >> This is one of a few cleanups I plan to do to enable a clean implementation of: >> [JDK-8261527: Record page size used for underlying mapping in ReservedSpace](https://bugs.openjdk.java.net/browse/JDK-8261527) >> >> **Testing** >> Mach5 tier1 and tier2. > > Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision: > > Thomas review. > > Using initialize_members() in clear_members(). looks good ------------- Marked as reviewed by iwalulya (Committer). PR: https://git.openjdk.java.net/jdk/pull/3435 From stuefe at openjdk.java.net Tue Apr 13 08:21:05 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 13 Apr 2021 08:21:05 GMT Subject: RFR: 8262291: Refactor reserve_memory_special_huge_tlbfs [v6] In-Reply-To: References: Message-ID: <7ECh94k8YC-6YVBm-ZNoRfkjG95iiP18nzIKwevGx7Q=.09dcec6c-4405-4d5f-b887-22f819afb982@github.com> On Mon, 12 Apr 2021 09:31:22 GMT, Stefan Johansson wrote: >> Please review this refactoring of the hugetlbfs reservation code. >> >> **Summary** >> In recent adventures in this area of the code I noticed a strange condition in `reserve_memory_special_huge_tlbfs` where we take the "mixed-mapping" route even if the size doesn't require any small pages to be used: >> >> if (is_aligned(bytes, os::large_page_size()) && alignment <= os::large_page_size()) { >> return reserve_memory_special_huge_tlbfs_only(bytes, req_addr, exec); >> } else { >> return reserve_memory_special_huge_tlbfs_mixed(bytes, alignment, req_addr, exec); >> } >> >> >> The second condition here is needed because if the alignment is larger than the large page size, we needed to enforce this and can't just trust `mmap` to give us a properly aligned address. Doing this by using the mixed-function feels a bit weird and looking a bit more at this I found a way to refactor this function to avoid having the two helpers. >> >> Instead of only having the mixed path honor the passed down alignment, make sure that is always done. This will also have the side-effect that all large pages in a "mixed"-mapping will be at the start and then we will have a tail of small pages. This actually also ensures that we will use large pages for a mixed mapping, in the past there was a corner case where we could end up with just a head and tail of small pages and no large page in between (if the mapping was smaller than 2 large pages and there was no alignment constraint). >> >> **Testing** >> Mach5 tier1-3 and a lot of local testing with different large page configurations. > > Stefan Johansson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Merge branch 'master' into 8262291-one-special-alloc > - Thomas review. > > Changed commit_memory_special to return bool to signal if the request succeeded or not. > - Self review. > > Update helper name to better match commit_memory_special(). > - Marcus review. > > Updated comments. > - Ivan review > > Renamed helper to commit_memory_special and updated the comments. > - 8262291: Refactor reserve_memory_special_huge_tlbfs Oh right, sorry. Looks good Stefan! ..Thomas ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3073 From sjohanss at openjdk.java.net Tue Apr 13 09:02:02 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Tue, 13 Apr 2021 09:02:02 GMT Subject: RFR: 8262291: Refactor reserve_memory_special_huge_tlbfs [v6] In-Reply-To: <-_har4xeqFlcZNPG45yUmvKa1XbkZ6gD_PvjOEY-TE8=.196a1b1c-b05d-4da5-b656-236379059f36@github.com> References: <-_har4xeqFlcZNPG45yUmvKa1XbkZ6gD_PvjOEY-TE8=.196a1b1c-b05d-4da5-b656-236379059f36@github.com> Message-ID: On Mon, 12 Apr 2021 13:17:04 GMT, Thomas Stuefe wrote: >> Stefan Johansson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: >> >> - Merge branch 'master' into 8262291-one-special-alloc >> - Thomas review. >> >> Changed commit_memory_special to return bool to signal if the request succeeded or not. >> - Self review. >> >> Update helper name to better match commit_memory_special(). >> - Marcus review. >> >> Updated comments. >> - Ivan review >> >> Renamed helper to commit_memory_special and updated the comments. >> - 8262291: Refactor reserve_memory_special_huge_tlbfs > > Looks good to me. > > Thanks, Thomas Thanks for the reviews @tstuefe, @mgkwill and @walulyai ------------- PR: https://git.openjdk.java.net/jdk/pull/3073 From sjohanss at openjdk.java.net Tue Apr 13 09:02:03 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Tue, 13 Apr 2021 09:02:03 GMT Subject: Integrated: 8262291: Refactor reserve_memory_special_huge_tlbfs In-Reply-To: References: Message-ID: On Thu, 18 Mar 2021 14:00:00 GMT, Stefan Johansson wrote: > Please review this refactoring of the hugetlbfs reservation code. > > **Summary** > In recent adventures in this area of the code I noticed a strange condition in `reserve_memory_special_huge_tlbfs` where we take the "mixed-mapping" route even if the size doesn't require any small pages to be used: > > if (is_aligned(bytes, os::large_page_size()) && alignment <= os::large_page_size()) { > return reserve_memory_special_huge_tlbfs_only(bytes, req_addr, exec); > } else { > return reserve_memory_special_huge_tlbfs_mixed(bytes, alignment, req_addr, exec); > } > > > The second condition here is needed because if the alignment is larger than the large page size, we needed to enforce this and can't just trust `mmap` to give us a properly aligned address. Doing this by using the mixed-function feels a bit weird and looking a bit more at this I found a way to refactor this function to avoid having the two helpers. > > Instead of only having the mixed path honor the passed down alignment, make sure that is always done. This will also have the side-effect that all large pages in a "mixed"-mapping will be at the start and then we will have a tail of small pages. This actually also ensures that we will use large pages for a mixed mapping, in the past there was a corner case where we could end up with just a head and tail of small pages and no large page in between (if the mapping was smaller than 2 large pages and there was no alignment constraint). > > **Testing** > Mach5 tier1-3 and a lot of local testing with different large page configurations. This pull request has now been integrated. Changeset: f2f7aa3b Author: Stefan Johansson URL: https://git.openjdk.java.net/jdk/commit/f2f7aa3b Stats: 163 lines in 3 files changed: 25 ins; 63 del; 75 mod 8262291: Refactor reserve_memory_special_huge_tlbfs Reviewed-by: iwalulya, stuefe ------------- PR: https://git.openjdk.java.net/jdk/pull/3073 From whuang at openjdk.java.net Tue Apr 13 09:26:59 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Tue, 13 Apr 2021 09:26:59 GMT Subject: RFR: 8264940: java/lang/invoke/6998541/Test6998541.java failed "guarantee(ik->is_initialized()) failed: java/lang/Byte$ByteCache must be initialized" [v5] In-Reply-To: References: <-17CHkPMQoZhr9gsnQ_1UvBDFAYUlaXCBFLQ7dGPK6g=.ebce6503-4974-41cc-8635-3b0168f02fe8@github.com> Message-ID: On Fri, 9 Apr 2021 11:40:24 GMT, Coleen Phillimore wrote: >> Wang Huang has updated the pull request incrementally with one additional commit since the last revision: >> >> adjust headers > > src/hotspot/share/runtime/deoptimization.cpp line 979: > >> 977: static BooleanBoxCache *_singleton; >> 978: BooleanBoxCache(Thread *thread) { >> 979: InstanceKlass* ik = find_cache_klass(java_lang_Boolean::symbol(), thread); > > If this throws a Java exception, you have to handle it here, you can't ignore it with thread. You should initialize these classes during initialization. You shouldn't be doing this in deoptimization. Yes. I changed my patch. Thank you for your review. ------------- PR: https://git.openjdk.java.net/jdk/pull/3411 From dnsimon at openjdk.java.net Tue Apr 13 09:33:11 2021 From: dnsimon at openjdk.java.net (Doug Simon) Date: Tue, 13 Apr 2021 09:33:11 GMT Subject: RFR: 8264806: Remove the experimental JIT compiler [v2] In-Reply-To: References: <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com> Message-ID: <_hHXNVNqB4NJAmS2mndxsKnFCg7fWWooaWMuWVL0bQA=.b8397a2a-0482-4851-9889-0432057070da@github.com> On Sun, 11 Apr 2021 10:25:47 GMT, Doug Simon wrote: >> Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Restore Graal Builder image makefile >> - Merge latest changes from branch 'JDK-8264805' into JDK-8264806 >> - 8264806: Remove the experimental JIT compiler > > We would definitely like to be able to continue testing of GraalVM with the JDK set of jtreg tests. So keeping `Compiler::isGraalEnabled()` working like it does today is important. > @dougxc I restored Compiler::isGraalEnabled(). Thanks. I guess this should really be named `isJVMCICompilerEnabled` now and the `vm.graal.enabled` predicate renamed to `vm.jvmcicompiler.enabled` but maybe that's too big a change (or can be done later). ------------- PR: https://git.openjdk.java.net/jdk/pull/3421 From sjohanss at openjdk.java.net Tue Apr 13 09:56:09 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Tue, 13 Apr 2021 09:56:09 GMT Subject: RFR: 8265066: Split ReservedSpace constructor to avoid default parameter Message-ID: <3a8swSA9QPceAHBKF_8zz2_OBoRSsENZaO8sORs-idA=.676bbcca-d934-4f96-88e6-7a3c0809d55e@github.com> Please review this change to change this constructor in ReservedSpace: // Initialize the reserved space with the given size. If preferred_page_size // is set, use this as minimum page size/alignment. This may waste some space // if the given size is not aligned to that value, as the reservation will be // aligned up to the final alignment in this case. ReservedSpace(size_t size, size_t preferred_page_size = 0); I propose to split this constructor into two instead of having the default parameter. This makes the implementation more straight forward. I also make the single argument constructor explicit to avoid implicit conversion. There was one place where we relied on implicit conversion and this has been updated to explicitly create the ReservedSpace. This cleanup is another step towards: [JDK-8261527: Record page size used for underlying mapping in ReservedSpace](https://bugs.openjdk.java.net/browse/JDK-8261527) ------------- Commit messages: - 8265066: Split ReservedSpace constructor to avoid default parameter Changes: https://git.openjdk.java.net/jdk/pull/3457/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3457&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265066 Stats: 32 lines in 3 files changed: 14 ins; 4 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/3457.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3457/head:pull/3457 PR: https://git.openjdk.java.net/jdk/pull/3457 From aph at openjdk.java.net Tue Apr 13 10:06:57 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Tue, 13 Apr 2021 10:06:57 GMT Subject: RFR: 8262896: [macos_aarch64] Crash in jni_fast_GetLongField In-Reply-To: <-z566EC0VCwqMkAGtW5Pz7_dyFjrht5qGHXL8Ba4lNQ=.4b5da342-f167-4a21-9fc3-bff50e7228fb@github.com> References: <-z566EC0VCwqMkAGtW5Pz7_dyFjrht5qGHXL8Ba4lNQ=.4b5da342-f167-4a21-9fc3-bff50e7228fb@github.com> Message-ID: On Fri, 9 Apr 2021 18:25:10 GMT, Anton Kozlov wrote: > Hi, please review a fix for a random crash on macos/aarch64. > > By default, GetXXXField JNI Interface implementation is a generated function (-XX:+UseFastJNIAccessors). Usually the function is called by JNI code running in WXExec mode and everything is fine. But sometime we attempt to call it in WXWrite context, like in the stack trace attached to the bug: > > > v ~BufferBlob::jni_fast_GetLongField > V [libjvm.dylib+0x7a6538] Perf_Detach+0x168 > j jdk.internal.perf.Perf.detach(Ljava/nio/ByteBuffer;)V+0 java.base at 17-internal > j jdk.internal.perf.Perf$CleanerAction.run()V+8 java.base at 17-internal > j jdk.internal.ref.CleanerImpl$PhantomCleanableRef.performCleanup()V+4 java.base at 17-internal > j jdk.internal.ref.PhantomCleanable.clean()V+12 java.base at 17-internal > j jdk.internal.ref.CleanerImpl.run()V+57 java.base at 17-internal > j java.lang.Thread.run()V+11 java.base at 17-internal > j jdk.internal.misc.InnocuousThread.run()V+20 java.base at 17-internal > v ~StubRoutines::call_stub > > > One way to fix the bug is to ensure WXExec mode before calling GetXXXField, but it depends on finding and fixing all such cases. > > This patch instead adds additional actions to GetXXXField implementation to ensure correct W^X mode regardless if it is called from WXWrite or WXExec mode. Looking at this further, the use of W^X for functions like this one, callable from JNI code, makes no sense. These functions are never written to once they have been generated. Could we generate them during init into a non-executable page, then remap that page as read/execute only? Then we wouldn't have to care about the state of W^X. ------------- PR: https://git.openjdk.java.net/jdk/pull/3422 From akozlov at openjdk.java.net Tue Apr 13 10:22:57 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Tue, 13 Apr 2021 10:22:57 GMT Subject: RFR: 8262896: [macos_aarch64] Crash in jni_fast_GetLongField In-Reply-To: References: <-z566EC0VCwqMkAGtW5Pz7_dyFjrht5qGHXL8Ba4lNQ=.4b5da342-f167-4a21-9fc3-bff50e7228fb@github.com> Message-ID: On Sat, 10 Apr 2021 10:24:42 GMT, Andrew Haley wrote: > How much does this gain over turning off UseFastJNIAccessors? The benchmark is https://github.com/AntonKozlov/macos-aarch64-transition-bench/commit/6de6c410e7884c290ec3e85c0d7fa9339e254192. For loopCnt=1: Before, +UseFastJNIAccessors: MyBenchmark.testGetField 1 thrpt 25 201397788.701 ? 907059.494 ops/s Before, -UseFastJNIAccessors: MyBenchmark.testGetField 1 thrpt 25 20435101.708 ? 233303.518 ops/s After, +UseFastJNIAccessors: MyBenchmark.testGetField 1 thrpt 25 151830846.914 ? 654947.292 ops/s After, -UseFastJNIAccessors: MyBenchmark.testGetField 1 thrpt 25 20278690.117 ? 287142.720 ops/s After with ThreadWXEnable commented out, +UseFastJNIAccessors: MyBenchmark.testGetField 1 thrpt 25 165277289.798 ? 939646.095 ops/s After with ThreadWXEnable and JavaThread::thread_from_jni_environment commented out, +UseFastJNIAccessors: MyBenchmark.testGetField 1 thrpt 25 187846151.217 ? 1014919.707 ops/s In summary, the fast accessor is ~10x faster now, before the patch. The code of this patch is not optimal, it introduces ~25% performance penalty, and only ~7% is W^X overhead. Indirection costs ~7% and JavaThread::thread_from_jni_environment is another ~11%. I was going to look at performance side after fixing the annoying failure. > I guess it doesn't much matter because you keep track of the current mode and only flip it if you really need to, which is rare? In most cases GetXXXField is called from WXExec. So the overhead should be only checking current thread mode. It's also sad that the cost is constant while we rarely call these accessors from WXWrite. ------------- PR: https://git.openjdk.java.net/jdk/pull/3422 From akozlov at openjdk.java.net Tue Apr 13 10:55:00 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Tue, 13 Apr 2021 10:55:00 GMT Subject: RFR: 8262896: [macos_aarch64] Crash in jni_fast_GetLongField In-Reply-To: <-z566EC0VCwqMkAGtW5Pz7_dyFjrht5qGHXL8Ba4lNQ=.4b5da342-f167-4a21-9fc3-bff50e7228fb@github.com> References: <-z566EC0VCwqMkAGtW5Pz7_dyFjrht5qGHXL8Ba4lNQ=.4b5da342-f167-4a21-9fc3-bff50e7228fb@github.com> Message-ID: On Fri, 9 Apr 2021 18:25:10 GMT, Anton Kozlov wrote: > Hi, please review a fix for a random crash on macos/aarch64. > > By default, GetXXXField JNI Interface implementation is a generated function (-XX:+UseFastJNIAccessors). Usually the function is called by JNI code running in WXExec mode and everything is fine. But sometime we attempt to call it in WXWrite context, like in the stack trace attached to the bug: > > > v ~BufferBlob::jni_fast_GetLongField > V [libjvm.dylib+0x7a6538] Perf_Detach+0x168 > j jdk.internal.perf.Perf.detach(Ljava/nio/ByteBuffer;)V+0 java.base at 17-internal > j jdk.internal.perf.Perf$CleanerAction.run()V+8 java.base at 17-internal > j jdk.internal.ref.CleanerImpl$PhantomCleanableRef.performCleanup()V+4 java.base at 17-internal > j jdk.internal.ref.PhantomCleanable.clean()V+12 java.base at 17-internal > j jdk.internal.ref.CleanerImpl.run()V+57 java.base at 17-internal > j java.lang.Thread.run()V+11 java.base at 17-internal > j jdk.internal.misc.InnocuousThread.run()V+20 java.base at 17-internal > v ~StubRoutines::call_stub > > > One way to fix the bug is to ensure WXExec mode before calling GetXXXField, but it depends on finding and fixing all such cases. > > This patch instead adds additional actions to GetXXXField implementation to ensure correct W^X mode regardless if it is called from WXWrite or WXExec mode. Hi David, > > v ~BufferBlob::jni_fast_GetLongField > > V [libjvm.dylib+0x7a6538] Perf_Detach+0x168 > > I'm struggling to see how we get to the jni_fast_GetLongField from > Perf_Detach ?? Perf_Detach calls e.g GetDirectBufferAddress https://github.com/openjdk/jdk/blob/1935655622226421797ea9109bebd4a00fe60402/src/hotspot/share/prims/perf.cpp#L114, which calls GetLongField https://github.com/openjdk/jdk/blob/1935655622226421797ea9109bebd4a00fe60402/src/hotspot/share/prims/jni.cpp#L3058 > Once again I'm finding it very hard to understand what the actual rules > are for these W^X mode changes and what code requires what. Sorry for this. Probably there should be a document or comment in the code, but I didn't find a right place for that. But your understanding below is totally correct. > IIUC the normal(?) mode is WXExec and we use that when executing JITed or other native code. Right, since most of the time we execute generated code. > But if we enter the VM we need to switch to WXWrite mode. Not a strong necessity, but a choice. It is done to avoid going back and forth between W^X modes while executing VM code, also to avoid many subtle issues similar to this one but in much bigger counts. > for some reason these generated fast-accessors need to be run in WXExec > mode. It just impossible to execute generated code without switching to WXExec. > So IIUC the transitions that are already in place for executing > "VM code" are going to be wrong any time that VM code ends up executing > something like a fast-accessor - is that the case? Partially, yes. It's not totally wrong, since VM code still may need to write code cache, i.e. during deoptimization happening randomly. > And what other code > is in the same category as these generated fast-accessors? There are rather small number of such cases (I found these by grepping WXExec) * SafeFetch32/N * StubRoutines::UnsafeArrayCopy_stub * ProgrammableInvoker::invoke_native Hope it clarifies minor details. ------------- PR: https://git.openjdk.java.net/jdk/pull/3422 From akozlov at openjdk.java.net Tue Apr 13 11:03:57 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Tue, 13 Apr 2021 11:03:57 GMT Subject: RFR: 8262896: [macos_aarch64] Crash in jni_fast_GetLongField In-Reply-To: References: <-z566EC0VCwqMkAGtW5Pz7_dyFjrht5qGHXL8Ba4lNQ=.4b5da342-f167-4a21-9fc3-bff50e7228fb@github.com> Message-ID: <24EhmL01R2K1HZC0T5vCOOaQZmYZ9kenjT1m-owScZg=.ae014ac3-b074-48c7-b3f4-f0d9973d553d@github.com> On Tue, 13 Apr 2021 10:04:20 GMT, Andrew Haley wrote: > Looking at this further, the use of W^X for functions like this one, callable from JNI code, makes no sense. > These functions are never written to once they have been generated. Could we generate them during init into a non-executable page, then remap that page as read/execute only? Then we wouldn't have to care about the state of W^X. Indeed, this code does not need to be changed after it was generated. But I don't think it will be easy to implement simple remapping (due security restrictions). It would be helpful if we could unlock only a part of the code cache for writing, leaving the other executable, but I don't know immediate way to do this. Probably I'll convert this to draft. Meanwhile it is still worth to fix the random crash. What do you think about this patch compared to turning off fast JNI accessors? ------------- PR: https://git.openjdk.java.net/jdk/pull/3422 From aph at openjdk.java.net Tue Apr 13 12:14:59 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Tue, 13 Apr 2021 12:14:59 GMT Subject: RFR: 8262896: [macos_aarch64] Crash in jni_fast_GetLongField In-Reply-To: <24EhmL01R2K1HZC0T5vCOOaQZmYZ9kenjT1m-owScZg=.ae014ac3-b074-48c7-b3f4-f0d9973d553d@github.com> References: <-z566EC0VCwqMkAGtW5Pz7_dyFjrht5qGHXL8Ba4lNQ=.4b5da342-f167-4a21-9fc3-bff50e7228fb@github.com> <24EhmL01R2K1HZC0T5vCOOaQZmYZ9kenjT1m-owScZg=.ae014ac3-b074-48c7-b3f4-f0d9973d553d@github.com> Message-ID: <9L0A1iqpznMn-59122uCEtUQ4LhwqDgfIGA8vmB8moI=.5850f5bb-4e96-4897-9a01-a1029339865c@github.com> On Tue, 13 Apr 2021 11:01:10 GMT, Anton Kozlov wrote: > Indeed, this code does not need to be changed after it was generated. But I don't think it will be easy to implement simple remapping (due security restrictions). Why not? As far as I can see, the "Allow Unsigned Executable Memory" Hardened Runtime capability allows exactly this. Maybe it'd stop OpenJDK being notarized, but Apple doen't say so. > It would be helpful if we could unlock only a part of the code cache for writing, leaving the other executable, but I don't know immediate way to do this. > > Probably I'll convert this to draft. Meanwhile it is still worth to fix the random crash. What do you think about this patch compared to turning off fast JNI accessors? It depends on performance. I've had a quick look at how `pthread_jit_write_protect_np` works, and it looks like some serious overhead. Can you measure, say, a few million JNI accessors to see which works best? ------------- PR: https://git.openjdk.java.net/jdk/pull/3422 From aph at openjdk.java.net Tue Apr 13 12:24:57 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Tue, 13 Apr 2021 12:24:57 GMT Subject: RFR: 8262896: [macos_aarch64] Crash in jni_fast_GetLongField In-Reply-To: <9L0A1iqpznMn-59122uCEtUQ4LhwqDgfIGA8vmB8moI=.5850f5bb-4e96-4897-9a01-a1029339865c@github.com> References: <-z566EC0VCwqMkAGtW5Pz7_dyFjrht5qGHXL8Ba4lNQ=.4b5da342-f167-4a21-9fc3-bff50e7228fb@github.com> <24EhmL01R2K1HZC0T5vCOOaQZmYZ9kenjT1m-owScZg=.ae014ac3-b074-48c7-b3f4-f0d9973d553d@github.com> <9L0A1iqpznMn-59122uCEtUQ4LhwqDgfIGA8vmB8moI=.5850f5bb-4e96-4897-9a01-a1029339865c@github.com> Message-ID: <6lQ9kBqGhJo3eGugM4NJLIXoH0v9OMfhBVVLZavK71E=.03f3fa28-fe8d-48e3-8490-b0881bea83b7@github.com> On Tue, 13 Apr 2021 12:11:55 GMT, Andrew Haley wrote: > It depends on performance. I've had a quick look at how `pthread_jit_write_protect_np` works, and it looks like some serious overhead. Can you measure, say, a few million JNI accessors to see which works best? I just had a look, and according to https://dougallj.github.io/applecpu/firestorm.html `MSR (APRR)` only takes a single cycle, but there is still some overhead because of an `ISB`. Please try it and see, though. ------------- PR: https://git.openjdk.java.net/jdk/pull/3422 From aph at redhat.com Tue Apr 13 12:27:48 2021 From: aph at redhat.com (Andrew Haley) Date: Tue, 13 Apr 2021 13:27:48 +0100 Subject: RFR: 8262896: [macos_aarch64] Crash in jni_fast_GetLongField In-Reply-To: References: <-z566EC0VCwqMkAGtW5Pz7_dyFjrht5qGHXL8Ba4lNQ=.4b5da342-f167-4a21-9fc3-bff50e7228fb@github.com> Message-ID: On 4/13/21 11:22 AM, Anton Kozlov wrote: > In summary, the fast accessor is ~10x faster now, before the patch. OK, so still a clear win. Looks like Apple have made pthread_jit_write_protect_np extremely fast. I think that what you have here is close to the best we're going to do. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From sjohanss at openjdk.java.net Tue Apr 13 12:41:57 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Tue, 13 Apr 2021 12:41:57 GMT Subject: RFR: 8265064: Move clearing and setting of members into helpers in ReservedSpace [v2] In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 07:48:53 GMT, Thomas Schatzl wrote: >> Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision: >> >> Thomas review. >> >> Using initialize_members() in clear_members(). > > Lgtm. Thanks @tschatzl and @walulyai for the reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/3435 From sjohanss at openjdk.java.net Tue Apr 13 12:41:59 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Tue, 13 Apr 2021 12:41:59 GMT Subject: Integrated: 8265064: Move clearing and setting of members into helpers in ReservedSpace In-Reply-To: References: Message-ID: On Mon, 12 Apr 2021 11:59:57 GMT, Stefan Johansson wrote: > Currently there are a few places in `ReservedSpace` that updates a set of members directly during initialization. This could be refactored into helper functions to improve readability and also to pave way for some further cleanups. > > This is one of a few cleanups I plan to do to enable a clean implementation of: > [JDK-8261527: Record page size used for underlying mapping in ReservedSpace](https://bugs.openjdk.java.net/browse/JDK-8261527) > > **Testing** > Mach5 tier1 and tier2. This pull request has now been integrated. Changeset: a4f644eb Author: Stefan Johansson URL: https://git.openjdk.java.net/jdk/commit/a4f644eb Stats: 78 lines in 2 files changed: 38 ins; 27 del; 13 mod 8265064: Move clearing and setting of members into helpers in ReservedSpace Reviewed-by: tschatzl, iwalulya ------------- PR: https://git.openjdk.java.net/jdk/pull/3435 From vkempik at openjdk.java.net Tue Apr 13 13:02:09 2021 From: vkempik at openjdk.java.net (Vladimir Kempik) Date: Tue, 13 Apr 2021 13:02:09 GMT Subject: RFR: 8262896: [macos_aarch64] Crash in jni_fast_GetLongField In-Reply-To: <9L0A1iqpznMn-59122uCEtUQ4LhwqDgfIGA8vmB8moI=.5850f5bb-4e96-4897-9a01-a1029339865c@github.com> References: <-z566EC0VCwqMkAGtW5Pz7_dyFjrht5qGHXL8Ba4lNQ=.4b5da342-f167-4a21-9fc3-bff50e7228fb@github.com> <24EhmL01R2K1HZC0T5vCOOaQZmYZ9kenjT1m-owScZg=.ae014ac3-b074-48c7-b3f4-f0d9973d553d@github.com> <9L0A1iqpznMn-59122uCEtUQ4LhwqDgfIGA8vmB8moI=.5850f5bb-4e96-4897-9a01-a1029339865c@github.com> Message-ID: On Tue, 13 Apr 2021 12:11:55 GMT, Andrew Haley wrote: > Why not? As far as I can see, the "Allow Unsigned Executable Memory" Hardened Runtime capability allows exactly this. Maybe it'd stop OpenJDK being notarized, but Apple doen't say so. AFAIR, this entitlement https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_security_cs_allow-unsigned-executable-memory is not available on macos_arm64 this entitlement allows you to allocate rwx memory on macos_intel, but on macos_arm64 kernel forbids to allocate rwx memory(withotu MAP_JIT) no matter what. ------------- PR: https://git.openjdk.java.net/jdk/pull/3422 From aph at openjdk.java.net Tue Apr 13 15:10:16 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Tue, 13 Apr 2021 15:10:16 GMT Subject: RFR: 8262896: [macos_aarch64] Crash in jni_fast_GetLongField In-Reply-To: <-z566EC0VCwqMkAGtW5Pz7_dyFjrht5qGHXL8Ba4lNQ=.4b5da342-f167-4a21-9fc3-bff50e7228fb@github.com> References: <-z566EC0VCwqMkAGtW5Pz7_dyFjrht5qGHXL8Ba4lNQ=.4b5da342-f167-4a21-9fc3-bff50e7228fb@github.com> Message-ID: On Fri, 9 Apr 2021 18:25:10 GMT, Anton Kozlov wrote: > Hi, please review a fix for a random crash on macos/aarch64. > > By default, GetXXXField JNI Interface implementation is a generated function (-XX:+UseFastJNIAccessors). Usually the function is called by JNI code running in WXExec mode and everything is fine. But sometime we attempt to call it in WXWrite context, like in the stack trace attached to the bug: > > > v ~BufferBlob::jni_fast_GetLongField > V [libjvm.dylib+0x7a6538] Perf_Detach+0x168 > j jdk.internal.perf.Perf.detach(Ljava/nio/ByteBuffer;)V+0 java.base at 17-internal > j jdk.internal.perf.Perf$CleanerAction.run()V+8 java.base at 17-internal > j jdk.internal.ref.CleanerImpl$PhantomCleanableRef.performCleanup()V+4 java.base at 17-internal > j jdk.internal.ref.PhantomCleanable.clean()V+12 java.base at 17-internal > j jdk.internal.ref.CleanerImpl.run()V+57 java.base at 17-internal > j java.lang.Thread.run()V+11 java.base at 17-internal > j jdk.internal.misc.InnocuousThread.run()V+20 java.base at 17-internal > v ~StubRoutines::call_stub > > > One way to fix the bug is to ensure WXExec mode before calling GetXXXField, but it depends on finding and fixing all such cases. > > This patch instead adds additional actions to GetXXXField implementation to ensure correct W^X mode regardless if it is called from WXWrite or WXExec mode. Approving here, but if any more of these come up I think we'll need a more general-purpose solution. ------------- Marked as reviewed by aph (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3422 From aph at openjdk.java.net Tue Apr 13 15:10:16 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Tue, 13 Apr 2021 15:10:16 GMT Subject: RFR: 8262896: [macos_aarch64] Crash in jni_fast_GetLongField In-Reply-To: References: <-z566EC0VCwqMkAGtW5Pz7_dyFjrht5qGHXL8Ba4lNQ=.4b5da342-f167-4a21-9fc3-bff50e7228fb@github.com> <24EhmL01R2K1HZC0T5vCOOaQZmYZ9kenjT1m-owScZg=.ae014ac3-b074-48c7-b3f4-f0d9973d553d@github.com> <9L0A1iqpznMn-59122uCEtUQ4LhwqDgfIGA8vmB8moI=.5850f5bb-4e96-4897-9a01-a1029339865c@github.com> Message-ID: On Tue, 13 Apr 2021 12:59:02 GMT, Vladimir Kempik wrote: > > Why not? As far as I can see, the "Allow Unsigned Executable Memory" Hardened Runtime capability allows exactly this. Maybe it'd stop OpenJDK being notarized, but Apple doen't say so. > > AFAIR, this entitlement https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_security_cs_allow-unsigned-executable-memory is not available on macos_arm64 > > this entitlement allows you to allocate rwx memory on macos_intel, but on macos_arm64 kernel forbids to allocate rwx memory(withotu MAP_JIT) no matter what. Fair enough. ------------- PR: https://git.openjdk.java.net/jdk/pull/3422 From xliu at openjdk.java.net Tue Apr 13 15:45:34 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Tue, 13 Apr 2021 15:45:34 GMT Subject: RFR: 8229517: Support for optional asynchronous/buffered logging [v4] In-Reply-To: References: Message-ID: > This patch provides a buffer to store asynchrounous messages and flush them to > underlying files periodically. Xin Liu has updated the pull request incrementally with one additional commit since the last revision: Revert "fix runtime/logging/RedefineClasses.java crashed with -XX:+AsyncLogging" This reverts commit 81b2a0cb2a6cf57b1cd0baacdf8c0419f14819b4. This problem is sidetracked by JDK-8265102. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3135/files - new: https://git.openjdk.java.net/jdk/pull/3135/files/81b2a0cb..54aadfaf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3135&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3135&range=02-03 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3135.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3135/head:pull/3135 PR: https://git.openjdk.java.net/jdk/pull/3135 From dcubed at openjdk.java.net Tue Apr 13 16:25:58 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 13 Apr 2021 16:25:58 GMT Subject: RFR: 8264940: java/lang/invoke/6998541/Test6998541.java failed "guarantee(ik->is_initialized()) failed: java/lang/Byte$ByteCache must be initialized" [v5] In-Reply-To: References: <-17CHkPMQoZhr9gsnQ_1UvBDFAYUlaXCBFLQ7dGPK6g=.ebce6503-4974-41cc-8635-3b0168f02fe8@github.com> Message-ID: On Tue, 13 Apr 2021 04:31:16 GMT, Wang Huang wrote: >> * The main reason is that in this situation the `BoxCache` is not initialized before `uncommon_trap`. >> * `java.lang.Byte$ByteCache` is loaded without initializing here >> * I think that all `*Cache` classes should be loaded in this situation. > > Wang Huang has updated the pull request incrementally with one additional commit since the last revision: > > adjust headers Marked as reviewed by dcubed (Reviewer). I've reviewed and I'm testing the fix right now. If it passes, then I'll sponsor. ------------- PR: https://git.openjdk.java.net/jdk/pull/3411 From whuang at openjdk.java.net Tue Apr 13 16:45:17 2021 From: whuang at openjdk.java.net (Wang Huang) Date: Tue, 13 Apr 2021 16:45:17 GMT Subject: Integrated: 8264940: java/lang/invoke/6998541/Test6998541.java failed "guarantee(ik->is_initialized()) failed: java/lang/Byte$ByteCache must be initialized" In-Reply-To: <-17CHkPMQoZhr9gsnQ_1UvBDFAYUlaXCBFLQ7dGPK6g=.ebce6503-4974-41cc-8635-3b0168f02fe8@github.com> References: <-17CHkPMQoZhr9gsnQ_1UvBDFAYUlaXCBFLQ7dGPK6g=.ebce6503-4974-41cc-8635-3b0168f02fe8@github.com> Message-ID: On Fri, 9 Apr 2021 10:15:57 GMT, Wang Huang wrote: > * The main reason is that in this situation the `BoxCache` is not initialized before `uncommon_trap`. > * `java.lang.Byte$ByteCache` is loaded without initializing here > * I think that all `*Cache` classes should be loaded in this situation. This pull request has now been integrated. Changeset: c7975113 Author: Wang Huang Committer: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/c7975113 Stats: 33 lines in 3 files changed: 32 ins; 0 del; 1 mod 8264940: java/lang/invoke/6998541/Test6998541.java failed "guarantee(ik->is_initialized()) failed: java/lang/Byte$ByteCache must be initialized" Co-authored-by: Wu Yan Reviewed-by: dholmes, kvn, dcubed ------------- PR: https://git.openjdk.java.net/jdk/pull/3411 From dcubed at openjdk.java.net Tue Apr 13 16:45:17 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Tue, 13 Apr 2021 16:45:17 GMT Subject: RFR: 8264940: java/lang/invoke/6998541/Test6998541.java failed "guarantee(ik->is_initialized()) failed: java/lang/Byte$ByteCache must be initialized" [v5] In-Reply-To: References: <-17CHkPMQoZhr9gsnQ_1UvBDFAYUlaXCBFLQ7dGPK6g=.ebce6503-4974-41cc-8635-3b0168f02fe8@github.com> Message-ID: On Tue, 13 Apr 2021 04:31:16 GMT, Wang Huang wrote: >> * The main reason is that in this situation the `BoxCache` is not initialized before `uncommon_trap`. >> * `java.lang.Byte$ByteCache` is loaded without initializing here >> * I think that all `*Cache` classes should be loaded in this situation. > > Wang Huang has updated the pull request incrementally with one additional commit since the last revision: > > adjust headers I reproduced the failure on my MBP13 with 'fastdebug' and 'slow debug' bits with these options: VM_OPTIONS=-Xcomp -XX:+CreateCoredumpOnCrash -ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -server -XX:-TieredCompilation -XX:+DeoptimizeALot and then retested with the fix in place with 'fastdebug' bits and the failure no longer reproduced. ------------- PR: https://git.openjdk.java.net/jdk/pull/3411 From kvn at openjdk.java.net Tue Apr 13 17:55:20 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Tue, 13 Apr 2021 17:55:20 GMT Subject: RFR: 8264806: Remove the experimental JIT compiler [v2] In-Reply-To: <_hHXNVNqB4NJAmS2mndxsKnFCg7fWWooaWMuWVL0bQA=.b8397a2a-0482-4851-9889-0432057070da@github.com> References: <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com> <_hHXNVNqB4NJAmS2mndxsKnFCg7fWWooaWMuWVL0bQA=.b8397a2a-0482-4851-9889-0432057070da@github.com> Message-ID: On Tue, 13 Apr 2021 09:30:23 GMT, Doug Simon wrote: >> We would definitely like to be able to continue testing of GraalVM with the JDK set of jtreg tests. So keeping `Compiler::isGraalEnabled()` working like it does today is important. > >> @dougxc I restored Compiler::isGraalEnabled(). > > Thanks. I guess this should really be named `isJVMCICompilerEnabled` now and the `vm.graal.enabled` predicate renamed to `vm.jvmcicompiler.enabled` but maybe that's too big a change (or can be done later). @dougxc Renaming should be done separately. May be use RFE I filed: https://bugs.openjdk.java.net/browse/JDK-8265032 Do you approve these Graal removal changes? ------------- PR: https://git.openjdk.java.net/jdk/pull/3421 From iklam at openjdk.java.net Tue Apr 13 20:49:19 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 13 Apr 2021 20:49:19 GMT Subject: RFR: 8265101: Remove unnecessary functions in os*.inline.hpp Message-ID: <1nuLsyk3arkBvaLReeV9Y650aSRPNR5uwTTSUSFcz8E=.cf6a62e1-994e-4baf-9a5b-39ea86486719@github.com> Many functions like `os::write`, `os::exit`, `os::dll_unload`, etc, are implemented in various os*.inline.hpp files. This forces many .hpp and .cpp files to explicitly include "runtime/os.inline.hpp". There's no performance reason to inline these functions. They will make a system call, whose overhead is way bigger than the cost of making an extra function call. The full list methods moved from `os*inline.hpp` to `os_.cpp` are: os::dll_unload(void *lib) os::lseek(int fd, jlong offset, int whence) os::fsync(int fd) os::ftruncate(int fd, jlong length) os::read(int fd, void *buf, unsigned int nBytes) os::write(int fd, const void *buf, unsigned int nBytes) os::close(int fd) os::socket_close(int fd) os::socket(int domain, int type, int protocol) os::recv(int fd, char* buf, size_t nBytes, uint flags) os::send(int fd, char* buf, size_t nBytes, uint flags) os::raw_send(int fd, char* buf, size_t nBytes, uint flags) os::connect(int fd, struct sockaddr* him, socklen_t len) os::get_host_by_name(char* name) os::exit(int num) I also took this chance to remove unnecessary inclusion of os.hpp and os.inline.hpp from various files. I added some missing `#include` directives that were exposed as a result. - **Notes for Reviewers**: please start from os*.{hpp,cpp} files first. - Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. ------------- Commit messages: - fixed copyright - removed unnecessary include os.hpp - remove unnecessary include os.inline.hpp - step1 Changes: https://git.openjdk.java.net/jdk/pull/3475/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3475&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265101 Stats: 257 lines in 58 files changed: 109 ins; 98 del; 50 mod Patch: https://git.openjdk.java.net/jdk/pull/3475.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3475/head:pull/3475 PR: https://git.openjdk.java.net/jdk/pull/3475 From akozlov at openjdk.java.net Tue Apr 13 21:12:57 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Tue, 13 Apr 2021 21:12:57 GMT Subject: RFR: 8262896: [macos_aarch64] Crash in jni_fast_GetLongField In-Reply-To: <-z566EC0VCwqMkAGtW5Pz7_dyFjrht5qGHXL8Ba4lNQ=.4b5da342-f167-4a21-9fc3-bff50e7228fb@github.com> References: <-z566EC0VCwqMkAGtW5Pz7_dyFjrht5qGHXL8Ba4lNQ=.4b5da342-f167-4a21-9fc3-bff50e7228fb@github.com> Message-ID: On Fri, 9 Apr 2021 18:25:10 GMT, Anton Kozlov wrote: > Hi, please review a fix for a random crash on macos/aarch64. > > By default, GetXXXField JNI Interface implementation is a generated function (-XX:+UseFastJNIAccessors). Usually the function is called by JNI code running in WXExec mode and everything is fine. But sometime we attempt to call it in WXWrite context, like in the stack trace attached to the bug: > > > v ~BufferBlob::jni_fast_GetLongField > V [libjvm.dylib+0x7a6538] Perf_Detach+0x168 > j jdk.internal.perf.Perf.detach(Ljava/nio/ByteBuffer;)V+0 java.base at 17-internal > j jdk.internal.perf.Perf$CleanerAction.run()V+8 java.base at 17-internal > j jdk.internal.ref.CleanerImpl$PhantomCleanableRef.performCleanup()V+4 java.base at 17-internal > j jdk.internal.ref.PhantomCleanable.clean()V+12 java.base at 17-internal > j jdk.internal.ref.CleanerImpl.run()V+57 java.base at 17-internal > j java.lang.Thread.run()V+11 java.base at 17-internal > j jdk.internal.misc.InnocuousThread.run()V+20 java.base at 17-internal > v ~StubRoutines::call_stub > > > One way to fix the bug is to ensure WXExec mode before calling GetXXXField, but it depends on finding and fixing all such cases. > > This patch instead adds additional actions to GetXXXField implementation to ensure correct W^X mode regardless if it is called from WXWrite or WXExec mode. Thanks! Yes, I also not happy with this from performance side. I'll look in this. ------------- PR: https://git.openjdk.java.net/jdk/pull/3422 From dnsimon at openjdk.java.net Tue Apr 13 21:22:14 2021 From: dnsimon at openjdk.java.net (Doug Simon) Date: Tue, 13 Apr 2021 21:22:14 GMT Subject: RFR: 8264806: Remove the experimental JIT compiler [v3] In-Reply-To: References: Message-ID: On Mon, 12 Apr 2021 22:10:06 GMT, Vladimir Kozlov wrote: >> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK: >> >> - `jdk.internal.vm.compiler` ? the Graal compiler >> - `jdk.internal.vm.compiler.management` ? Graal's `MBean` >> - `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests >> >> Remove Graal related code in makefiles. >> >> Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build: >> >> src/jdk.internal.vm.compiler/share/classes/module-info.java >> src/jdk.internal.vm.compiler.management/share/classes/module-info.java >> >> >> @AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it. >> >> Tested hs-tier1-4 > > Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: > > Restore Compiler::isGraalEnabled() Approved. ------------- PR: https://git.openjdk.java.net/jdk/pull/3421 From dholmes at openjdk.java.net Tue Apr 13 22:37:57 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 13 Apr 2021 22:37:57 GMT Subject: RFR: 8262896: [macos_aarch64] Crash in jni_fast_GetLongField In-Reply-To: <-z566EC0VCwqMkAGtW5Pz7_dyFjrht5qGHXL8Ba4lNQ=.4b5da342-f167-4a21-9fc3-bff50e7228fb@github.com> References: <-z566EC0VCwqMkAGtW5Pz7_dyFjrht5qGHXL8Ba4lNQ=.4b5da342-f167-4a21-9fc3-bff50e7228fb@github.com> Message-ID: On Fri, 9 Apr 2021 18:25:10 GMT, Anton Kozlov wrote: > Hi, please review a fix for a random crash on macos/aarch64. > > By default, GetXXXField JNI Interface implementation is a generated function (-XX:+UseFastJNIAccessors). Usually the function is called by JNI code running in WXExec mode and everything is fine. But sometime we attempt to call it in WXWrite context, like in the stack trace attached to the bug: > > > v ~BufferBlob::jni_fast_GetLongField > V [libjvm.dylib+0x7a6538] Perf_Detach+0x168 > j jdk.internal.perf.Perf.detach(Ljava/nio/ByteBuffer;)V+0 java.base at 17-internal > j jdk.internal.perf.Perf$CleanerAction.run()V+8 java.base at 17-internal > j jdk.internal.ref.CleanerImpl$PhantomCleanableRef.performCleanup()V+4 java.base at 17-internal > j jdk.internal.ref.PhantomCleanable.clean()V+12 java.base at 17-internal > j jdk.internal.ref.CleanerImpl.run()V+57 java.base at 17-internal > j java.lang.Thread.run()V+11 java.base at 17-internal > j jdk.internal.misc.InnocuousThread.run()V+20 java.base at 17-internal > v ~StubRoutines::call_stub > > > One way to fix the bug is to ensure WXExec mode before calling GetXXXField, but it depends on finding and fixing all such cases. > > This patch instead adds additional actions to GetXXXField implementation to ensure correct W^X mode regardless if it is called from WXWrite or WXExec mode. I'm also concerned about the overall approach to W^X, but like Andrew I can accept the current proposal. I will also sponsor this for you. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3422 From akozlov at openjdk.java.net Tue Apr 13 22:37:58 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Tue, 13 Apr 2021 22:37:58 GMT Subject: Integrated: 8262896: [macos_aarch64] Crash in jni_fast_GetLongField In-Reply-To: <-z566EC0VCwqMkAGtW5Pz7_dyFjrht5qGHXL8Ba4lNQ=.4b5da342-f167-4a21-9fc3-bff50e7228fb@github.com> References: <-z566EC0VCwqMkAGtW5Pz7_dyFjrht5qGHXL8Ba4lNQ=.4b5da342-f167-4a21-9fc3-bff50e7228fb@github.com> Message-ID: On Fri, 9 Apr 2021 18:25:10 GMT, Anton Kozlov wrote: > Hi, please review a fix for a random crash on macos/aarch64. > > By default, GetXXXField JNI Interface implementation is a generated function (-XX:+UseFastJNIAccessors). Usually the function is called by JNI code running in WXExec mode and everything is fine. But sometime we attempt to call it in WXWrite context, like in the stack trace attached to the bug: > > > v ~BufferBlob::jni_fast_GetLongField > V [libjvm.dylib+0x7a6538] Perf_Detach+0x168 > j jdk.internal.perf.Perf.detach(Ljava/nio/ByteBuffer;)V+0 java.base at 17-internal > j jdk.internal.perf.Perf$CleanerAction.run()V+8 java.base at 17-internal > j jdk.internal.ref.CleanerImpl$PhantomCleanableRef.performCleanup()V+4 java.base at 17-internal > j jdk.internal.ref.PhantomCleanable.clean()V+12 java.base at 17-internal > j jdk.internal.ref.CleanerImpl.run()V+57 java.base at 17-internal > j java.lang.Thread.run()V+11 java.base at 17-internal > j jdk.internal.misc.InnocuousThread.run()V+20 java.base at 17-internal > v ~StubRoutines::call_stub > > > One way to fix the bug is to ensure WXExec mode before calling GetXXXField, but it depends on finding and fixing all such cases. > > This patch instead adds additional actions to GetXXXField implementation to ensure correct W^X mode regardless if it is called from WXWrite or WXExec mode. This pull request has now been integrated. Changeset: 283d64f8 Author: Anton Kozlov Committer: David Holmes URL: https://git.openjdk.java.net/jdk/commit/283d64f8 Stats: 69 lines in 3 files changed: 61 ins; 0 del; 8 mod 8262896: [macos_aarch64] Crash in jni_fast_GetLongField Reviewed-by: aph, dholmes ------------- PR: https://git.openjdk.java.net/jdk/pull/3422 From sspitsyn at openjdk.java.net Tue Apr 13 22:50:57 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Tue, 13 Apr 2021 22:50:57 GMT Subject: RFR: 8264593: debug.cpp utilities should be available in product builds. In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 14:05:42 GMT, Kevin Walls wrote: > This is a pull request to move the ifndef PRODUCT in src/hotspot/share/utilities/debug.cpp, and add JNIEXPORT for symbol visibility on Windows. > > With these changes, we can use gdb on a live Linux process of a product build JVM, and call debug.cpp utilities. > e.g. "call universe()", or "call hsfind(0xADDRESS)". > > (I found that making calls in the JLI_Launch thread (gdb's thread 1) will crash, but switching first to a JavaThread works.) > > In Visual Studio use the Immediate window, just type the function name. Verified that without the changes, the symbols can't be seen/called. > > Printing happens on the LIVE jvm's tty (not the gdb session). > > > WizardMode is a develop flag, can't be changed in a product build, so avoid changing that in the debug() utility. > > > pa() is left ifndef PRODUCT, as the class AllocatedObj is ifndef PRODUCT in src/hotspot/share/memory/allocation.hpp > > > pns(...) uses frame fr(sp, fp, pc); but we have an ifndef PRODUCT on frame constructor: frame(void* sp, void* fp, void* pc); > Leave pns and pns2 ifndef PRODUCT. > > > File size changes: > Linux: libjvm.so becomes 8904 bytes larger. > Windows: jvm.dll becomes 6656 bytes larger. Hi Kevin, Sorry for the latency. This looks good to me. Thank you for taking care about it! I vote for these changes as they improve debugability of product builds. This also makes the debug.cpp functions potentially available for post-mortem analysis. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3307 From minqi at openjdk.java.net Tue Apr 13 23:04:24 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 13 Apr 2021 23:04:24 GMT Subject: RFR: 8259070: Add jcmd option to dump CDS [v11] In-Reply-To: References: Message-ID: > Hi, Please review > > Added jcmd option for dumping CDS archive during application runtime. Before this change, user has to dump shared archive in two steps: first run application with > `java -XX:DumpLoadedClassList= .... ` > to collect shareable class names and saved in file `` , then > `java -Xshare:dump -XX:SharedClassListFile= -XX:SharedArchiveFile= ...` > With this change, user can use jcmd to dump CDS without going through above steps. Also user can choose a moment during the app runtime to dump an archive. > The bug is associated with the CSR: https://bugs.openjdk.java.net/browse/JDK-8259798 which has been approved. > New added jcmd option: > `jcmd VM.cds static_dump ` > or > `jcmd VM.cds dynamic_dump ` > To dump dynamic archive, requires start app with newly added flag `-XX:+RecordDynamicDumpInfo`, with this flag, some information related to dynamic dump like loader constraints will be recorded. Note the dumping process changed some object memory locations so for dumping dynamic archive, can only done once for a running app. For static dump, user can dump multiple times against same process. > The file name is optional, if the file name is not supplied, the file name will take format of `java_pid_static.jsa` or `java_pid_dynamic.jsa` for static and dynamic respectively. The `` is the application process ID. > > Tests: tier1,tier2,tier3,tier4 > > Thanks > Yumin Yumin Qi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: - Fix too much verbose output, make call to stopApp after test - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 - Restructed code and rename LingeredTestApp.java to JCmdTestLingeredApp.java - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 - Fix revert unintentionally comment, merge master. - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 - Remove CDS.getVMArguments, changed to use VM.getRuntimeVMArguments. Removed unused function from ClassLoader. Improved InstanceKlass::is_shareable() and related test. Added more test scenarios. - Remove redundant check for if a class is shareable - ... and 6 more: https://git.openjdk.java.net/jdk/compare/008fc75a...88c0f7d1 ------------- Changes: https://git.openjdk.java.net/jdk/pull/2737/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2737&range=10 Stats: 860 lines in 23 files changed: 786 ins; 58 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/2737.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2737/head:pull/2737 PR: https://git.openjdk.java.net/jdk/pull/2737 From never at openjdk.java.net Wed Apr 14 00:42:11 2021 From: never at openjdk.java.net (Tom Rodriguez) Date: Wed, 14 Apr 2021 00:42:11 GMT Subject: RFR: 8265180: JvmtiCompiledMethodLoadEvent should include the stub section of nmethods Message-ID: 8265180: JvmtiCompiledMethodLoadEvent should include the stub section of nmethods ------------- Commit messages: - 8265180: JvmtiCompiledMethodLoadEvent should include the stub section of nmethods Changes: https://git.openjdk.java.net/jdk/pull/3481/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3481&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265180 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3481.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3481/head:pull/3481 PR: https://git.openjdk.java.net/jdk/pull/3481 From iklam at openjdk.java.net Wed Apr 14 01:45:03 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 14 Apr 2021 01:45:03 GMT Subject: RFR: 8259070: Add jcmd option to dump CDS [v11] In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 23:04:24 GMT, Yumin Qi wrote: >> Hi, Please review >> >> Added jcmd option for dumping CDS archive during application runtime. Before this change, user has to dump shared archive in two steps: first run application with >> `java -XX:DumpLoadedClassList= .... ` >> to collect shareable class names and saved in file `` , then >> `java -Xshare:dump -XX:SharedClassListFile= -XX:SharedArchiveFile= ...` >> With this change, user can use jcmd to dump CDS without going through above steps. Also user can choose a moment during the app runtime to dump an archive. >> The bug is associated with the CSR: https://bugs.openjdk.java.net/browse/JDK-8259798 which has been approved. >> New added jcmd option: >> `jcmd VM.cds static_dump ` >> or >> `jcmd VM.cds dynamic_dump ` >> To dump dynamic archive, requires start app with newly added flag `-XX:+RecordDynamicDumpInfo`, with this flag, some information related to dynamic dump like loader constraints will be recorded. Note the dumping process changed some object memory locations so for dumping dynamic archive, can only done once for a running app. For static dump, user can dump multiple times against same process. >> The file name is optional, if the file name is not supplied, the file name will take format of `java_pid_static.jsa` or `java_pid_dynamic.jsa` for static and dynamic respectively. The `` is the application process ID. >> >> Tests: tier1,tier2,tier3,tier4 >> >> Thanks >> Yumin > > Yumin Qi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Fix too much verbose output, make call to stopApp after test > - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 > - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 > - Restructed code and rename LingeredTestApp.java to JCmdTestLingeredApp.java > - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 > - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 > - Fix revert unintentionally comment, merge master. > - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 > - Remove CDS.getVMArguments, changed to use VM.getRuntimeVMArguments. Removed unused function from ClassLoader. Improved InstanceKlass::is_shareable() and related test. Added more test scenarios. > - Remove redundant check for if a class is shareable > - ... and 6 more: https://git.openjdk.java.net/jdk/compare/008fc75a...88c0f7d1 The latest versions looks good to me. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2737 From iklam at openjdk.java.net Wed Apr 14 02:46:24 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 14 Apr 2021 02:46:24 GMT Subject: RFR: 8265103: Remove unnecessary inclusion of oopMap.hpp [v2] In-Reply-To: References: Message-ID: > oopMap.hpp is included by about 585 out of about 1000 .o files in HotSpot. In turn, it pulls in other complex headers such as vmreg.hpp, register.hpp and their cpu-dependent headers. > > There are only 4 header files that include oopMap.hpp. All of these can be replaced for forward declarations. > > According to https://github.com/iklam/tools/tree/main/headers > > > [before] Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge branch 'master' into 8265103-reduce-inclusion-oopMap.hpp - fixed copyright year - removed unrelated changes - 8265103: Remove unnecessary inclusion of oopMap.hpp ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3446/files - new: https://git.openjdk.java.net/jdk/pull/3446/files/80a7f91d..2ee7d02e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3446&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3446&range=00-01 Stats: 8870 lines in 576 files changed: 4450 ins; 3988 del; 432 mod Patch: https://git.openjdk.java.net/jdk/pull/3446.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3446/head:pull/3446 PR: https://git.openjdk.java.net/jdk/pull/3446 From dholmes at openjdk.java.net Wed Apr 14 02:49:56 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 14 Apr 2021 02:49:56 GMT Subject: RFR: 8265101: Remove unnecessary functions in os*.inline.hpp In-Reply-To: <1nuLsyk3arkBvaLReeV9Y650aSRPNR5uwTTSUSFcz8E=.cf6a62e1-994e-4baf-9a5b-39ea86486719@github.com> References: <1nuLsyk3arkBvaLReeV9Y650aSRPNR5uwTTSUSFcz8E=.cf6a62e1-994e-4baf-9a5b-39ea86486719@github.com> Message-ID: On Tue, 13 Apr 2021 20:11:35 GMT, Ioi Lam wrote: > Many functions like `os::write`, `os::exit`, `os::dll_unload`, etc, are implemented in various os*.inline.hpp files. This forces many .hpp and .cpp files to explicitly include "runtime/os.inline.hpp". > > There's no performance reason to inline these functions. They will make a system call, whose overhead is way bigger than the cost of making an extra function call. > > The full list methods moved from `os*inline.hpp` to `os_.cpp` are: > > > os::dll_unload(void *lib) > os::lseek(int fd, jlong offset, int whence) > os::fsync(int fd) > os::ftruncate(int fd, jlong length) > os::read(int fd, void *buf, unsigned int nBytes) > os::write(int fd, const void *buf, unsigned int nBytes) > os::close(int fd) > os::socket_close(int fd) > os::socket(int domain, int type, int protocol) > os::recv(int fd, char* buf, size_t nBytes, uint flags) > os::send(int fd, char* buf, size_t nBytes, uint flags) > os::raw_send(int fd, char* buf, size_t nBytes, uint flags) > os::connect(int fd, struct sockaddr* him, socklen_t len) > os::get_host_by_name(char* name) > os::exit(int num) > > > I also took this chance to remove unnecessary inclusion of os.hpp and os.inline.hpp from various files. I added some missing `#include` directives that were exposed as a result. > > - **Notes for Reviewers**: please start from os*.{hpp,cpp} files first. > - Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. Hi Ioi, This all seems fine to me. I agree these seem unlikely to need to be inlined for performance. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3475 From kvn at openjdk.java.net Wed Apr 14 03:29:55 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 14 Apr 2021 03:29:55 GMT Subject: RFR: 8265180: JvmtiCompiledMethodLoadEvent should include the stub section of nmethods In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 00:35:55 GMT, Tom Rodriguez wrote: > 8265180: JvmtiCompiledMethodLoadEvent should include the stub section of nmethods Good. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3481 From iklam at openjdk.java.net Wed Apr 14 05:15:02 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 14 Apr 2021 05:15:02 GMT Subject: RFR: 8265103: Remove unnecessary inclusion of oopMap.hpp [v2] In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 07:02:39 GMT, Stefan Karlsson wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: >> >> - Merge branch 'master' into 8265103-reduce-inclusion-oopMap.hpp >> - fixed copyright year >> - removed unrelated changes >> - 8265103: Remove unnecessary inclusion of oopMap.hpp > > Marked as reviewed by stefank (Reviewer). Thanks @stefank and @dholmes-ora for the review. Tested again with latest repo: mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. ------------- PR: https://git.openjdk.java.net/jdk/pull/3446 From iklam at openjdk.java.net Wed Apr 14 05:15:03 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 14 Apr 2021 05:15:03 GMT Subject: Integrated: 8265103: Remove unnecessary inclusion of oopMap.hpp In-Reply-To: References: Message-ID: <_jJ6m46xcXV6PufA-mdiz3NZeld5A_6TEfRd7tI0quE=.b7b0f583-793c-413b-bfa2-304a0a1a653a@github.com> On Tue, 13 Apr 2021 01:55:13 GMT, Ioi Lam wrote: > oopMap.hpp is included by about 585 out of about 1000 .o files in HotSpot. In turn, it pulls in other complex headers such as vmreg.hpp, register.hpp and their cpu-dependent headers. > > There are only 4 header files that include oopMap.hpp. All of these can be replaced for forward declarations. > > According to https://github.com/iklam/tools/tree/main/headers > > > [before] This pull request has now been integrated. Changeset: ea5c55a4 Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/ea5c55a4 Stats: 75 lines in 53 files changed: 58 ins; 4 del; 13 mod 8265103: Remove unnecessary inclusion of oopMap.hpp Reviewed-by: dholmes, stefank ------------- PR: https://git.openjdk.java.net/jdk/pull/3446 From xxinliu at amazon.com Tue Apr 13 22:12:12 2021 From: xxinliu at amazon.com (Liu, Xin) Date: Tue, 13 Apr 2021 15:12:12 -0700 Subject: Request For Comment: Asynchronous Logging In-Reply-To: References: <7FEF3035-8926-467C-AD7B-A001A9C8FD5B@amazon.com> Message-ID: <2170bebc-e5a2-219c-0a4b-f41623098c43@amazon.com> Hi, Thomas, I am still working on this feature. I have tabulated the requests from reviewers. I draw a line of "consensus" and working on them one by one. ------------------------------------------------------------- | request | Status | ------------------------------------------------------------- | independent NonJavaThread | done [1] | |-----------------------------------------------------------| | pass tier1-test with +AsyncLogging |JDK-8265102 | |-----------------------------------------------------------<- progress | inject meta-info to display no. of dropping msg. |WIP | |-----------------------------------------------------------| | preserve accurate decorations | | |-----------------------------------------------------------| | hoist async_mode to base class for stdout/err| [2] | |-----------------------------------------------------------| | CSR |JDK-8264323 | |-----------------------------------------------------------<- consensus |use string table over malloc | | ------------------------------------------------------------| |use lock-free data structure. | | ------------------------------------------------------------- I would like to mark items below consensus "improvement" and leave them in separated JBS. I discussed about lock-free algorithms with Robbin on github. He agree to defer it[3]. I don't like strdup either, but I don't think it would hurt performance a lot. David Holmes comments and I quote "If we had had async logging from day one then the way we construct log messages would have been done differently". In current codebase, I have to copy logging messages anyway, the real cost should come from "copying" instead of allocating. Further, I have moved "allocate" and "free" out of critical areas. If performance does matter, we will have a overall deign including both sync/async messages and decorators. May I call out JDK-8264323? It's a CSR about JVM option. I have written down pros and cons. Could you take a look? I can support both global option and finer-grained output-option. I won't increase much complexity. [1]code is here: https://github.com/openjdk/jdk/pull/3135/commits/9211121c7afeb7a9fe602fd2a4d20bd98ddb1569 [2] here is the request: https://github.com/openjdk/jdk/pull/3135#issuecomment-809977841 [3] https://github.com/openjdk/jdk/pull/3135#issuecomment-813880728 On 4/12/21 10:30 PM, Thomas St?fe wrote: > *CAUTION*: This email originated from outside of the organization. Do > not click links or open attachments unless you can confirm the sender > and know the content is safe. > > > Hi Xin & others, > > Sorry for the late response, I had vacation.? > > As I wrote before, I think this is a valuable improvement. I would be > unhappy if this were stalled further.? > > In this thread there seems to be a majority opinion now for? > - having an own thread instead of using the WatcherThread > - having a global option for async (good point, Ioi) > > AFAICS the only POC left is the question whether to make the sizing > option a memory size or a "number of entries". I argued for the memory > size before, but won't insist on it, in order to move this issue forward > (we could always just keep that option diagnostic). > > Is there anything else left to discuss? > > I mentioned before that I think UL is too complex and could benefit from > simplification; but this is clearly not Xins fault, and I am sorry that > I brought this even up here, since it has nothing to do with this RFE. > > Cheers, Thomas > > > > On Tue, Mar 30, 2021 at 11:21 PM Liu, Xin > wrote: > > Thanks Volker for this. I would like to append some additional > materials.? I forgot to mention them when I wrote the Rationale[5] > yesterday. > > We identified and root-caused the tail-latency on a Linux system > with software RAID in 2018.? > We have different implementations on jdk8u and jdk11u. We are > seeking to merge this feature to tip. > > Nonetheless, it doesn't mean "async-logging facility" only solves > Amazon's peculiar problem.? When we studied this, we found many > interesting references. > Eg. LinkedIn reported and analyzed it well[1]. In particular, they > mentioned that one reason was Linux cache writeback [2]. IMHO, that > could impact > almost all mass-storge Linux filesystems. Twitter also expressed > that "I would love to hear if this can happen with OpenJDK!"[3].? > This is also reported > by other companies[4]. > > Thanks, > --lx > > > [1] > https://engineering.linkedin.com/blog/2016/02/eliminating-large-jvm-gc-pauses-caused-by-background-io-traffic > > [2] > https://yoshinorimatsunobu.blogspot.com/2014/03/why-buffered-writes-are-sometimes.html > > [3] https://www.evanjones.ca/jvm-mmap-pause-finding.html > > [4] > https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-June/042301.html > > [5] https://github.com/openjdk/jdk/pull/3135#issuecomment-809942487 > > > ?On 3/30/21, 11:20 AM, "Volker Simonis" > wrote: > > ? ? CAUTION: This email originated from outside of the organization. > Do not click links or open attachments unless you can confirm the > sender and know the content is safe. > > > > ? ? Hi, > > ? ? I'd like to (re)start a discussion on asynchronous logging > [1,2,3,4]. > ? ? We are successfully using this feature productively at Amazon > both in > ? ? jdk8 and jdk11 to reduce the tail latency of services which use > ? ? logging. We think that async logging is a useful addition to the > ? ? current logging framework which might be beneficial to a wider range > ? ? of users. The following write-up tries to capture the comments and > ? ? suggestions from the previous discussions we are aware of. > > ? ? Current state: > > ? ? - HotSpot uses the so called "Unified Logging" (UL) framework which > ? ? was introduced by JEP 158 [5] in JDK 9. Most logs have been > ? ? retrofitted to use UL since then (e.g. "JEP 271: Unified GC Logging" > ? ? [6]). > ? ? - The current UL implementation is based on the standard C buffered > ? ? stream I/O interface [7]. The LogFileStreamOutput class which writes > ? ? logs to abstract FILE streams is the only child of the abstract base > ? ? class LogOutput. LogFileStreamOutput has three child classes > ? ? LogStdoutOutput,? LogStderrOutput and LogFileOutput which write to > ? ? stdout, stderr or an arbitrary file respectively. The initial UL JEP > ? ? 158 [5] envisioned logging to a socket but has not implemented > it. At > ? ? least one such extension has been proposed since then [8]. > ? ? - UL synchronizes logs from different threads with the help of the > ? ? standard C flockfile()/funlockfile() [9] functions. But even without > ? ? this explicit locking, all the "stdio functions are thread-safe. > This > ? ? is achieved by assigning to each FILE object a lockcount and (if the > ? ? lockcount is nonzero) an owning thread.? For each library call, > these > ? ? functions wait until the FILE object is no longer locked by a > ? ? different thread, then lock it, do the requested I/O, and unlock the > ? ? object again" [9]. A quick look at the glibc sources reveals > that FILE > ? ? locking is implemented with the help of futex() [10] which > breaks down > ? ? to s simple atomic compare and swap (CAS) on the fast path. > ? ? - Notice that UL "synchronizes" logs from different threads to avoid > ? ? log interleaving. But it does not "serialize" logs according to the > ? ? time at which? they occurred. This is because the underlying stdio > ? ? functions do not guarantee a specific order for different threads > ? ? waiting on a locked FILE stream. E.g. if three log events A, B, C > ? ? occur in that order, the first will lock the output stream. If > the log > ? ? events B and C both arrive while the stream is locked, it is > ? ? unspecified which of B and C will be logged first after A > releases the > ? ? lock. > > ? ? Problem statement: > > ? ? - The amount of time a log event will block its FILE stream > depends on > ? ? the underlying file system. This can range from a few > nanoseconds for > ? ? in-memory file systems or milliseconds for physical discs under > heavy > ? ? load up to several seconds in the worst case scenario for e.g. > network > ? ? file systems. A blocked log output stream will block all concurrent > ? ? threads which try to write log messages at the same time. If logging > ? ? is done during a safepoint, this can significantly increase the > ? ? safepoint time (e.g. several parallel GC threads trying to log > at the > ? ? same time). We can treat stdout/stderr as special files here without > ? ? loss of generality. > > ? ? Proposed solution: > > ? ? Extend UL with an asynchronous logging facility. Asynchronous > logging > ? ? will be optional and disabled by default. It should have the > following > ? ? properties: > ? ? - If disabled (the default) asynchronous logging should have no > ? ? observable impact on logging. > ? ? - If enabled, log messages will be stored in an intermediate data > ? ? structure (e.g. a double ended queue). > ? ? - A service thread will concurrently read and remove log > messages from > ? ? that data structure in a FIFO style and write them to the output > ? ? stream > ? ? - Storing log messages in the intermediate data structure should > take > ? ? constant time and not longer than logging a message takes in the > ? ? traditional UL system (in general the time should be much shorter > ? ? because the actual I/O is deferred). > ? ? - Asynchronous logging trades memory overhead (i.e. the size of the > ? ? intermediate data structure) for log accuracy. This means that > in the > ? ? unlikely case where the service thread which does the asynchronous > ? ? logging falls behind the log producing threads, some logs might be > ? ? lost. However, the probability for this to happen can be > minimized by > ? ? increasing the configurable size of the intermediate data structure. > ? ? - The final output produced by asynchronous logging should be > equal to > ? ? the output from normal logging if no messages had to be dropped. > ? ? Notice that in contrast to the traditional unified logging, > ? ? asynchronous logging will give us the possibility to not only > ? ? synchronize log events, but to optionally also serialize them > based on > ? ? their generation time if that's desired. This is because we are in > ? ? full control of the synchronization primitives for the intermediate > ? ? data structure which stores the logs. > ? ? - If log messages had to be dropped, this should be logged in > the log > ? ? output (e.g. "[..] 42 messages dropped due to async logging") > ? ? - Asynchronous logging should ideally be implemented in such a way > ? ? that it can be easily adapted by alternative log targets like for > ? ? example sockets in the future. > > ? ? Alternative solutions: > ? ? - It has repeatedly been suggested to place the log files into a > ? ? memory file system but we don't think this is an optimal solution. > ? ? Main memory is often a constrained resource and we don't want log > ? ? files to compete with the JVM for it in such cases. > ? ? - It has also been argued to place the log files on a fast file > system > ? ? which is only used for logging but in containerized environments > file > ? ? system are often virtualized and the properties of the underlying > ? ? physical devices are not obvious. > ? ? - The load on the file system might be unpredictable due to other > ? ? applications on the same host. > ? ? - All these workarounds won't work if we eventually implement direct > ? ? logging to a network socket as suggested in [8]. > > ? ? Implementation details / POC: > > ? ? - A recent pull request [2] for JDK-8229517 [3] proposed to use a > ? ? simple deque implementation derived from HotSpot's LinkedListImpl > ? ? class for the intermediate data structure. It synchronizes access to > ? ? the queue with a MutexLocker which is internally implemented with > ? ? pthread_lock() and results in an atomic CAS on the fast path. So > ? ? performance-wise the locking itself is not different from the > ? ? flockfile()/funlockfile() functionality currently used by UL but > ? ? adding a log message to the deque should be constant as it basically > ? ? only requires a strdup(). And we could even eliminate the > strdup() if > ? ? we'd pre-allocate a big enough array for holding the log messages as > ? ? proposed in the pull request [2]. > ? ? - The pull pull request [2] for JDK-8229517 [3] proposed to set the > ? ? async flag as an attribute of the Xlog option which feels more > natural > ? ? because UL configuration is traditionally done within the Xlog > option. > ? ? But we could just as well use a global -XX flag to enable async > ? ? logging? What are your preferences here? > ? ? - The pull pull request [2] for JDK-8229517 [3] (mis)uses the > ? ? WatcherThread as service thread to concurrently process the > ? ? intermediate data structure and write the log messages out to > the log > ? ? stream. That should definitely be changed to an independent service > ? ? thread. > ? ? - The pull pull request [2] for JDK-8229517 [3] initially proposed > ? ? that the "service thread" runs at a fixed interval to dump log > ? ? messages to the log streams. But reviewers commented that this > should > ? ? better happen either continuously or based on the filling level > of the > ? ? intermediate data structure. What are your preferences here? > ? ? - What are your preferences on the configuration of the intermediate > ? ? data structure? Should it be configured based on the maximum > number of > ? ? log messages it can store or rather on the total size of the stored > ? ? log messages? I think that for normal runs this distinction probably > ? ? won't make a big difference because the size of log messages will > ? ? probably be the same on average so "number of log messages" should > ? ? always be proportional to "total size of log mesages". > > ? ? 1. Before diving into more implementation details, I'd first like to > ? ? reach a general consensus that asynchronous logging is a useful > ? ? feature that's worth while adding to HotSpot. > > ? ? 2. Once we agree on that, we should agree on the desired > properties of > ? ? asynchronous logging. I've tried to collect a basic set in the > ? ? "Proposed solution" section. > > ? ? 3. If that's done as well, we can discuss various implementation > ? ? details and finally prepare new pull requests. > > ? ? Thank you and best regards, > ? ? Volker > > ? ? [1] https://bugs.openjdk.java.net/browse/JDK-8229517 > > ? ? [2] https://github.com/openjdk/jdk/pull/3135 > > ? ? [3] > https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-November/043427.html > > ? ? [4] > https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-August/039130.html > > ? ? [5] https://openjdk.java.net/jeps/158 > > ? ? [6] https://openjdk.java.net/jeps/271 > > ? ? [7] https://man7.org/linux/man-pages/man3/stdio.3.html > > ? ? [8] > https://gist.github.com/YaSuenag/dacb6d94d8684915422232c7a08d5b5d > > ? ? [9] https://man7.org/linux/man-pages/man3/flockfile.3.html > > ? ? [10] https://man7.org/linux/man-pages/man2/futex.2.html > > From stefank at openjdk.java.net Wed Apr 14 07:54:56 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Wed, 14 Apr 2021 07:54:56 GMT Subject: RFR: 8265180: JvmtiCompiledMethodLoadEvent should include the stub section of nmethods In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 00:35:55 GMT, Tom Rodriguez wrote: > 8265180: JvmtiCompiledMethodLoadEvent should include the stub section of nmethods src/hotspot/share/prims/jvmtiExport.cpp line 1111: > 1109: : JvmtiMethodEventMark(thread,methodHandle(thread, nm->method())) { > 1110: _code_data = nm->code_begin(); > 1111: _code_size = (jint)pointer_delta(nm->code_end(), nm->code_begin(), sizeof(char)); Could CodeBlob::code_size be used instead?: int code_size() const { return code_end() - code_begin(); } ------------- PR: https://git.openjdk.java.net/jdk/pull/3481 From sjohanss at openjdk.java.net Wed Apr 14 14:46:55 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Wed, 14 Apr 2021 14:46:55 GMT Subject: RFR: 8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v27] In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 16:38:02 GMT, Marcus G K Williams wrote: >> When using LargePageSizeInBytes=1G, os::Linux::reserve_memory_special_huge_tlbfs* cannot select large pages smaller than 1G. Code heap usually uses less than 1G, so currently the code precludes code heap from using >> Large pages in this circumstance and when os::Linux::reserve_memory_special_huge_tlbfs* is called page sizes fall back to Linux::page_size() (usually 4k). >> >> This change allows the above use case by populating all large_page_sizes present in /sys/kernel/mm/hugepages in _page_sizes upon calling os::Linux::setup_large_page_size(). >> >> In os::Linux::reserve_memory_special_huge_tlbfs* we then select the largest large page size available in _page_sizes that is smaller than bytes being reserved. > > Marcus G K Williams has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 44 commits: > > - Merge branch 'master' into update_hlp > - Rebase on pull/3073 > > Signed-off-by: Marcus G K Williams > - Merge branch 'pull/3073' into update_hlp > - Thomas review. > > Changed commit_memory_special to return bool to signal if the request succeeded or not. > - Self review. > > Update helper name to better match commit_memory_special(). > - Marcus review. > > Updated comments. > - Ivan review > > Renamed helper to commit_memory_special and updated the comments. > - 8262291: Refactor reserve_memory_special_huge_tlbfs > - Merge branch 'master' into update_hlp > - Addressed kstefanj review suggestions > > Signed-off-by: Marcus G K Williams > - ... and 34 more: https://git.openjdk.java.net/jdk/compare/f60e81bf...f5bfe224 So now #3073 has been integrated, so you could merge with master to get this change. I also discussed the meaning of `LargePageSizeInBytes` with some folks internally and @stefank pointed me to: https://docs.oracle.com/en/java/javase/16/docs/specs/man/java.html There the flag is defined as: -XX:LargePageSizeInBytes=size Sets the maximum size (in bytes) for large pages used for the Java heap. The size argument must be a power of 2 (2, 4, 8, 16, and so on). Append the letter k or K to indicate kilobytes, m or M to indicate megabytes, or g or G to indicate gigabytes. By default, the size is set to 0, meaning that the JVM chooses the size for large pages automatically. ... So with this and what's in the code, the default behavior for the VM should be to try to use the best suitable large page size available for a mapping. If `LargePageSizeInBytes` is set this will limit the page sizes used to only include the ones less than or equal to `LargePageSizeInBytes`. Does that make sense to everyone? This will change the behavior compared to the what we have today: * Default (`LargePageSizeInBytes=0`) - old behavior - use the systems default large page size - new behavior - use all configure large page sizes * Value set (`LargePageSizeInBytes=X`) - old behavior - use only large pages of size X - new behavior - use large pages of size X or smaller So the new behavior better fits what's in the docs, but I still suspect we might need a CSR. ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From ccheung at openjdk.java.net Wed Apr 14 16:10:53 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Wed, 14 Apr 2021 16:10:53 GMT Subject: RFR: 8259070: Add jcmd option to dump CDS [v11] In-Reply-To: References: Message-ID: <2MZBR7N1LLVc5ZpiuP9b6IBzhekgk4gCwz2EkY6xv7k=.60f0234f-61fb-4f29-b68e-08f0a92ca3de@github.com> On Tue, 13 Apr 2021 23:04:24 GMT, Yumin Qi wrote: >> Hi, Please review >> >> Added jcmd option for dumping CDS archive during application runtime. Before this change, user has to dump shared archive in two steps: first run application with >> `java -XX:DumpLoadedClassList= .... ` >> to collect shareable class names and saved in file `` , then >> `java -Xshare:dump -XX:SharedClassListFile= -XX:SharedArchiveFile= ...` >> With this change, user can use jcmd to dump CDS without going through above steps. Also user can choose a moment during the app runtime to dump an archive. >> The bug is associated with the CSR: https://bugs.openjdk.java.net/browse/JDK-8259798 which has been approved. >> New added jcmd option: >> `jcmd VM.cds static_dump ` >> or >> `jcmd VM.cds dynamic_dump ` >> To dump dynamic archive, requires start app with newly added flag `-XX:+RecordDynamicDumpInfo`, with this flag, some information related to dynamic dump like loader constraints will be recorded. Note the dumping process changed some object memory locations so for dumping dynamic archive, can only done once for a running app. For static dump, user can dump multiple times against same process. >> The file name is optional, if the file name is not supplied, the file name will take format of `java_pid_static.jsa` or `java_pid_dynamic.jsa` for static and dynamic respectively. The `` is the application process ID. >> >> Tests: tier1,tier2,tier3,tier4 >> >> Thanks >> Yumin > > Yumin Qi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Fix too much verbose output, make call to stopApp after test > - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 > - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 > - Restructed code and rename LingeredTestApp.java to JCmdTestLingeredApp.java > - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 > - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 > - Fix revert unintentionally comment, merge master. > - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 > - Remove CDS.getVMArguments, changed to use VM.getRuntimeVMArguments. Removed unused function from ClassLoader. Improved InstanceKlass::is_shareable() and related test. Added more test scenarios. > - Remove redundant check for if a class is shareable > - ... and 6 more: https://git.openjdk.java.net/jdk/compare/008fc75a...88c0f7d1 src/hotspot/share/memory/dynamicArchive.cpp line 348: > 346: set_has_been_dumped_once(); > 347: } > 348: assert(ArchiveClassesAtExit == nullptr, "already checked in arguments.cpp?"); Same assert has been done at line 338. test/hotspot/jtreg/runtime/cds/appcds/DumpClassList.java line 89: > 87: output.shouldContain("skip writing class java/lang/NewClass"); > 88: // but classes on -Xbootclasspath/a should not be skipped > 89: output.shouldNotContain("skip writing class boot/append/Foo"); Why was the above checks removed? ------------- PR: https://git.openjdk.java.net/jdk/pull/2737 From ccheung at openjdk.java.net Wed Apr 14 16:16:45 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Wed, 14 Apr 2021 16:16:45 GMT Subject: RFR: 8259070: Add jcmd option to dump CDS [v11] In-Reply-To: References: Message-ID: On Tue, 13 Apr 2021 23:04:24 GMT, Yumin Qi wrote: >> Hi, Please review >> >> Added jcmd option for dumping CDS archive during application runtime. Before this change, user has to dump shared archive in two steps: first run application with >> `java -XX:DumpLoadedClassList= .... ` >> to collect shareable class names and saved in file `` , then >> `java -Xshare:dump -XX:SharedClassListFile= -XX:SharedArchiveFile= ...` >> With this change, user can use jcmd to dump CDS without going through above steps. Also user can choose a moment during the app runtime to dump an archive. >> The bug is associated with the CSR: https://bugs.openjdk.java.net/browse/JDK-8259798 which has been approved. >> New added jcmd option: >> `jcmd VM.cds static_dump ` >> or >> `jcmd VM.cds dynamic_dump ` >> To dump dynamic archive, requires start app with newly added flag `-XX:+RecordDynamicDumpInfo`, with this flag, some information related to dynamic dump like loader constraints will be recorded. Note the dumping process changed some object memory locations so for dumping dynamic archive, can only done once for a running app. For static dump, user can dump multiple times against same process. >> The file name is optional, if the file name is not supplied, the file name will take format of `java_pid_static.jsa` or `java_pid_dynamic.jsa` for static and dynamic respectively. The `` is the application process ID. >> >> Tests: tier1,tier2,tier3,tier4 >> >> Thanks >> Yumin > > Yumin Qi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Fix too much verbose output, make call to stopApp after test > - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 > - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 > - Restructed code and rename LingeredTestApp.java to JCmdTestLingeredApp.java > - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 > - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 > - Fix revert unintentionally comment, merge master. > - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8259070 > - Remove CDS.getVMArguments, changed to use VM.getRuntimeVMArguments. Removed unused function from ClassLoader. Improved InstanceKlass::is_shareable() and related test. Added more test scenarios. > - Remove redundant check for if a class is shareable > - ... and 6 more: https://git.openjdk.java.net/jdk/compare/008fc75a...88c0f7d1 Looks good. Just have a few minor comments. test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTest.java line 86: > 84: bootJar = JarBuilder.build("boot", BOOT_CLASSES); > 85: Path testJarPath = FileSystems.getDefault().getPath(testJar); > 86: Path bootJarPath = FileSystems.getDefault().getPath(bootJar); I think the above could be replaced with: String testJarPath = TestCommon.getTestJar(?test.jar?); String bootJarPath = TestCommon.getTestJar(?boot.jar?); Most of the CDS tests use the `getTestJar` method. You can leave it as is if you like. test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTest.java line 149: > 147: args.add("-Xlog:class+load"); > 148: > 149: LingeredApp app = createLingeredApp(args.toArray(new String[0])); Instead of `new String[0]`, I think it is more intuitive to use `new String[args.size()]`. ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2737 From never at openjdk.java.net Wed Apr 14 16:31:43 2021 From: never at openjdk.java.net (Tom Rodriguez) Date: Wed, 14 Apr 2021 16:31:43 GMT Subject: RFR: 8265180: JvmtiCompiledMethodLoadEvent should include the stub section of nmethods In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 07:51:13 GMT, Stefan Karlsson wrote: >> 8265180: JvmtiCompiledMethodLoadEvent should include the stub section of nmethods > > src/hotspot/share/prims/jvmtiExport.cpp line 1111: > >> 1109: : JvmtiMethodEventMark(thread,methodHandle(thread, nm->method())) { >> 1110: _code_data = nm->code_begin(); >> 1111: _code_size = (jint)pointer_delta(nm->code_end(), nm->code_begin(), sizeof(char)); > > Could CodeBlob::code_size be used instead?: > > int code_size() const { return code_end() - code_begin(); } It certainly could. I was just following the pattern used by JvmtiExport::post_dynamic_code_generated but maybe it's better to use the real nmethod API. I'll change it. ------------- PR: https://git.openjdk.java.net/jdk/pull/3481 From never at openjdk.java.net Wed Apr 14 16:41:01 2021 From: never at openjdk.java.net (Tom Rodriguez) Date: Wed, 14 Apr 2021 16:41:01 GMT Subject: RFR: 8265180: JvmtiCompiledMethodLoadEvent should include the stub section of nmethods [v2] In-Reply-To: References: Message-ID: > 8265180: JvmtiCompiledMethodLoadEvent should include the stub section of nmethods Tom Rodriguez has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8265180: JvmtiCompiledMethodLoadEvent should include the stub section of nmethods ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3481/files - new: https://git.openjdk.java.net/jdk/pull/3481/files/ef1e6929..7dbe88f9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3481&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3481&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3481.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3481/head:pull/3481 PR: https://git.openjdk.java.net/jdk/pull/3481 From iignatyev at openjdk.java.net Wed Apr 14 17:24:56 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Wed, 14 Apr 2021 17:24:56 GMT Subject: RFR: 8058176: [mlvm] tests should not allow code cache exhaustion [v7] In-Reply-To: References: Message-ID: On Wed, 17 Mar 2021 19:02:32 GMT, Evgeny Nikitin wrote: >> Another approach to the JDK-8058176 and #2440 - never allowing the tests hit CodeCache limits. The most significant consumer is the MH graph builder (the MHTransformationGen), whose consumption is now controlled. List of changes: >> >> * Code cache size getters are added to WhiteBox; >> * MH sequences are now built with remaining Code cache size in mind (always let 2M clearance); >> * Dependencies on WhiteBox added for all affected tests; >> * The test cases in question un-problemlisted. >> >> Testing: the whole vmTestbase/vm/mlvm/ in win-lin-mac x86. > > Evgeny Nikitin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: > > - Merge branch 'master' into JDK-8058176/public > - Move a comment a bit higher > - Extract allowances into constants > - Add non-nmethods pool to the monitoring > - Fix 'cycles to build' error output > - Add support for segmented CodeCache > - Switch to ManagementBeans approach instead of the WhiteBox one > - Un-problemlist the OOME tests > - Add CodeCache methods to the WhiteBox > - 8058176: [mlvm] tests should not allow code cache exhaustion hm... I guess no one else wants to share their opinion, so I'll take it as an agreement and /sponsor ------------- PR: https://git.openjdk.java.net/jdk/pull/2523 From enikitin at openjdk.java.net Wed Apr 14 17:36:40 2021 From: enikitin at openjdk.java.net (Evgeny Nikitin) Date: Wed, 14 Apr 2021 17:36:40 GMT Subject: Integrated: 8058176: [mlvm] tests should not allow code cache exhaustion In-Reply-To: References: Message-ID: On Thu, 11 Feb 2021 13:27:52 GMT, Evgeny Nikitin wrote: > Another approach to the JDK-8058176 and #2440 - never allowing the tests hit CodeCache limits. The most significant consumer is the MH graph builder (the MHTransformationGen), whose consumption is now controlled. List of changes: > > * Code cache size getters are added to WhiteBox; > * MH sequences are now built with remaining Code cache size in mind (always let 2M clearance); > * Dependencies on WhiteBox added for all affected tests; > * The test cases in question un-problemlisted. > > Testing: the whole vmTestbase/vm/mlvm/ in win-lin-mac x86. This pull request has now been integrated. Changeset: 4c83d24f Author: Evgeny Nikitin Committer: Igor Ignatyev URL: https://git.openjdk.java.net/jdk/commit/4c83d24f Stats: 57 lines in 2 files changed: 49 ins; 6 del; 2 mod 8058176: [mlvm] tests should not allow code cache exhaustion Reviewed-by: iignatyev ------------- PR: https://git.openjdk.java.net/jdk/pull/2523 From github.com+168222+mgkwill at openjdk.java.net Wed Apr 14 19:04:10 2021 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Wed, 14 Apr 2021 19:04:10 GMT Subject: RFR: 8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v27] In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 14:43:34 GMT, Stefan Johansson wrote: > So now #3073 has been integrated, so you could merge with master to get this change. > I will merge master and pickup change form #3073 today. > I also discussed the meaning of `LargePageSizeInBytes` with some folks internally and @stefank pointed me to: > https://docs.oracle.com/en/java/javase/16/docs/specs/man/java.html > > There the flag is defined as: > > ``` > -XX:LargePageSizeInBytes=size > Sets the maximum size (in bytes) for large pages used for the Java heap. The size argument must be > a power of 2 (2, 4, 8, 16, and so on). Append the letter k or K to indicate kilobytes, m or M to > indicate megabytes, or g or G to indicate gigabytes. By default, the size is set to 0, meaning that > the JVM chooses the size for large pages automatically. ... > ``` > > So with this and what's in the code, the default behavior for the VM should be to try to use the best suitable large page size available for a mapping. If `LargePageSizeInBytes` is set this will limit the page sizes used to only include the ones less than or equal to `LargePageSizeInBytes`. > > Does that make sense to everyone? Thanks for the clarification @kstefanj. This makes sense and fits within my original goals for the change. What are your thoughts @tstuefe ? > This will change the behavior compared to the what we have today: > > * Default (`LargePageSizeInBytes=0`) > > * old behavior - use the systems default large page size > * new behavior - use all configure large page sizes > * Value set (`LargePageSizeInBytes=X`) > > * old behavior - use only large pages of size X > * new behavior - use large pages of size X or smaller > > So the new behavior better fits what's in the docs, but I still suspect we might need a CSR. ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From minqi at openjdk.java.net Wed Apr 14 19:08:25 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 14 Apr 2021 19:08:25 GMT Subject: RFR: 8259070: Add jcmd option to dump CDS [v12] In-Reply-To: References: Message-ID: <3a_niaHCAlxycKq7lSyi6QWCntKhwGQXqjVN1d1D2SQ=.a85bfd81-7b5c-4416-b73a-d817e830aefd@github.com> > Hi, Please review > > Added jcmd option for dumping CDS archive during application runtime. Before this change, user has to dump shared archive in two steps: first run application with > `java -XX:DumpLoadedClassList= .... ` > to collect shareable class names and saved in file `` , then > `java -Xshare:dump -XX:SharedClassListFile= -XX:SharedArchiveFile= ...` > With this change, user can use jcmd to dump CDS without going through above steps. Also user can choose a moment during the app runtime to dump an archive. > The bug is associated with the CSR: https://bugs.openjdk.java.net/browse/JDK-8259798 which has been approved. > New added jcmd option: > `jcmd VM.cds static_dump ` > or > `jcmd VM.cds dynamic_dump ` > To dump dynamic archive, requires start app with newly added flag `-XX:+RecordDynamicDumpInfo`, with this flag, some information related to dynamic dump like loader constraints will be recorded. Note the dumping process changed some object memory locations so for dumping dynamic archive, can only done once for a running app. For static dump, user can dump multiple times against same process. > The file name is optional, if the file name is not supplied, the file name will take format of `java_pid_static.jsa` or `java_pid_dynamic.jsa` for static and dynamic respectively. The `` is the application process ID. > > Tests: tier1,tier2,tier3,tier4 > > Thanks > Yumin Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Removed extra assert and fixed extra Path usage in test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2737/files - new: https://git.openjdk.java.net/jdk/pull/2737/files/88c0f7d1..042ec8f3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2737&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2737&range=10-11 Stats: 5 lines in 2 files changed: 0 ins; 3 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/2737.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2737/head:pull/2737 PR: https://git.openjdk.java.net/jdk/pull/2737 From sspitsyn at openjdk.java.net Wed Apr 14 23:35:32 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Wed, 14 Apr 2021 23:35:32 GMT Subject: RFR: 8265180: JvmtiCompiledMethodLoadEvent should include the stub section of nmethods [v2] In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 16:41:01 GMT, Tom Rodriguez wrote: >> 8265180: JvmtiCompiledMethodLoadEvent should include the stub section of nmethods > > Tom Rodriguez has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > 8265180: JvmtiCompiledMethodLoadEvent should include the stub section of nmethods Hi Thomas, The fix looks good. Thanks, Serguei ------------- Marked as reviewed by sspitsyn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3481 From xliu at openjdk.java.net Thu Apr 15 00:46:10 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Thu, 15 Apr 2021 00:46:10 GMT Subject: RFR: 8229517: Support for optional asynchronous/buffered logging [v5] In-Reply-To: References: Message-ID: > This patch provides a buffer to store asynchrounous messages and flush them to > underlying files periodically. Xin Liu has updated the pull request incrementally with one additional commit since the last revision: Inject the number of dropped messages since last dumpping. Each LogOutput has an independent counter. The out-of-band message "[number] messages dropped..." will be dumped into its corresponding LogOutput. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3135/files - new: https://git.openjdk.java.net/jdk/pull/3135/files/54aadfaf..f453d03f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3135&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3135&range=03-04 Stats: 95 lines in 8 files changed: 63 ins; 21 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/3135.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3135/head:pull/3135 PR: https://git.openjdk.java.net/jdk/pull/3135 From dholmes at openjdk.java.net Thu Apr 15 02:57:51 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 15 Apr 2021 02:57:51 GMT Subject: RFR: 8265246: Fix macos-Aarch64 build after JDK-8263709 Message-ID: <7OAbKJ1TjoI7wa8gXgZ-m3XiEYTXgHlB_xFGIT7c_zk=.f328aa65-a4d3-4493-ac8f-1d92d7c7d324@github.com> Two recent macOS-Aarch64 fixes were merged into my changes without conflict, but needed editing to match my changes: s/thread/current/ in two places. Testing: all platform builds in mach5, including macOS-Aarch64 of course (in progress) Thanks, David ------------- Commit messages: - 8265246: Fix macos-Aarch64 build after JDK-8263709 Changes: https://git.openjdk.java.net/jdk/pull/3506/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3506&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265246 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3506.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3506/head:pull/3506 PR: https://git.openjdk.java.net/jdk/pull/3506 From mikael at openjdk.java.net Thu Apr 15 03:04:34 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Thu, 15 Apr 2021 03:04:34 GMT Subject: RFR: 8265246: Fix macos-Aarch64 build after JDK-8263709 In-Reply-To: <7OAbKJ1TjoI7wa8gXgZ-m3XiEYTXgHlB_xFGIT7c_zk=.f328aa65-a4d3-4493-ac8f-1d92d7c7d324@github.com> References: <7OAbKJ1TjoI7wa8gXgZ-m3XiEYTXgHlB_xFGIT7c_zk=.f328aa65-a4d3-4493-ac8f-1d92d7c7d324@github.com> Message-ID: On Thu, 15 Apr 2021 02:51:38 GMT, David Holmes wrote: > Two recent macOS-Aarch64 fixes were merged into my changes without conflict, but needed editing to match my changes: > > s/thread/current/ > > in two places. > > Testing: all platform builds in mach5, including macOS-Aarch64 of course (in progress) > > Thanks, > David Marked as reviewed by mikael (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3506 From dholmes at openjdk.java.net Thu Apr 15 03:04:34 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 15 Apr 2021 03:04:34 GMT Subject: RFR: 8265246: Fix macos-Aarch64 build after JDK-8263709 In-Reply-To: References: <7OAbKJ1TjoI7wa8gXgZ-m3XiEYTXgHlB_xFGIT7c_zk=.f328aa65-a4d3-4493-ac8f-1d92d7c7d324@github.com> Message-ID: On Thu, 15 Apr 2021 02:57:38 GMT, Mikael Vidstedt wrote: >> Two recent macOS-Aarch64 fixes were merged into my changes without conflict, but needed editing to match my changes: >> >> s/thread/current/ >> >> in two places. >> >> Testing: all platform builds in mach5, including macOS-Aarch64 of course (in progress) >> >> Thanks, >> David > > Marked as reviewed by mikael (Reviewer). Thanks @vidmik ! ------------- PR: https://git.openjdk.java.net/jdk/pull/3506 From dholmes at openjdk.java.net Thu Apr 15 03:04:35 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 15 Apr 2021 03:04:35 GMT Subject: Integrated: 8265246: Fix macos-Aarch64 build after JDK-8263709 In-Reply-To: <7OAbKJ1TjoI7wa8gXgZ-m3XiEYTXgHlB_xFGIT7c_zk=.f328aa65-a4d3-4493-ac8f-1d92d7c7d324@github.com> References: <7OAbKJ1TjoI7wa8gXgZ-m3XiEYTXgHlB_xFGIT7c_zk=.f328aa65-a4d3-4493-ac8f-1d92d7c7d324@github.com> Message-ID: On Thu, 15 Apr 2021 02:51:38 GMT, David Holmes wrote: > Two recent macOS-Aarch64 fixes were merged into my changes without conflict, but needed editing to match my changes: > > s/thread/current/ > > in two places. > > Testing: all platform builds in mach5, including macOS-Aarch64 of course (in progress) > > Thanks, > David This pull request has now been integrated. Changeset: 59319486 Author: David Holmes URL: https://git.openjdk.java.net/jdk/commit/59319486 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8265246: Fix macos-Aarch64 build after JDK-8263709 Reviewed-by: mikael ------------- PR: https://git.openjdk.java.net/jdk/pull/3506 From mli at openjdk.java.net Thu Apr 15 03:14:41 2021 From: mli at openjdk.java.net (Hamlin Li) Date: Thu, 15 Apr 2021 03:14:41 GMT Subject: RFR: 8259070: Add jcmd option to dump CDS [v12] In-Reply-To: <3a_niaHCAlxycKq7lSyi6QWCntKhwGQXqjVN1d1D2SQ=.a85bfd81-7b5c-4416-b73a-d817e830aefd@github.com> References: <3a_niaHCAlxycKq7lSyi6QWCntKhwGQXqjVN1d1D2SQ=.a85bfd81-7b5c-4416-b73a-d817e830aefd@github.com> Message-ID: On Wed, 14 Apr 2021 19:08:25 GMT, Yumin Qi wrote: >> Hi, Please review >> >> Added jcmd option for dumping CDS archive during application runtime. Before this change, user has to dump shared archive in two steps: first run application with >> `java -XX:DumpLoadedClassList= .... ` >> to collect shareable class names and saved in file `` , then >> `java -Xshare:dump -XX:SharedClassListFile= -XX:SharedArchiveFile= ...` >> With this change, user can use jcmd to dump CDS without going through above steps. Also user can choose a moment during the app runtime to dump an archive. >> The bug is associated with the CSR: https://bugs.openjdk.java.net/browse/JDK-8259798 which has been approved. >> New added jcmd option: >> `jcmd VM.cds static_dump ` >> or >> `jcmd VM.cds dynamic_dump ` >> To dump dynamic archive, requires start app with newly added flag `-XX:+RecordDynamicDumpInfo`, with this flag, some information related to dynamic dump like loader constraints will be recorded. Note the dumping process changed some object memory locations so for dumping dynamic archive, can only done once for a running app. For static dump, user can dump multiple times against same process. >> The file name is optional, if the file name is not supplied, the file name will take format of `java_pid_static.jsa` or `java_pid_dynamic.jsa` for static and dynamic respectively. The `` is the application process ID. >> >> Tests: tier1,tier2,tier3,tier4 >> >> Thanks >> Yumin > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Removed extra assert and fixed extra Path usage in test Marked as reviewed by mli (Reviewer). I looked back at the history, and find out why it calls from JVM into java then into JVM again, nice solution! ------------- PR: https://git.openjdk.java.net/jdk/pull/2737 From sspitsyn at openjdk.java.net Thu Apr 15 03:17:36 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 15 Apr 2021 03:17:36 GMT Subject: RFR: 8262002: java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.sh failed with "TestCaseScaffoldException: DummyClassWithLVT did not match .class file" In-Reply-To: References: Message-ID: On Sat, 10 Apr 2021 01:10:37 GMT, Alex Menkov wrote: > The test actually failed starting from jdk13, but the error is masked by JDK-8264667 (and shell part of the test didn't verify result of the java execution) > The fix: > - updates JvmtiClassFileReconstituter to add attributes in the same order as javac does > - makes the test java instead of shell > - added workaround for JDK-8264667 > - test code is ready to ignore order of attributes test/jdk/java/lang/instrument/ATransformerManagementTestCase.java line 125: > 123: manager.addTransformer(transformer, canRetransform); > 124: // verbosePrint("Added transformer " + transformer > 125: // + " with canRetransform=" + canRetransform); I'd suggest to remove the commented out lines. ------------- PR: https://git.openjdk.java.net/jdk/pull/3426 From sspitsyn at openjdk.java.net Thu Apr 15 03:30:34 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 15 Apr 2021 03:30:34 GMT Subject: RFR: 8262002: java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.sh failed with "TestCaseScaffoldException: DummyClassWithLVT did not match .class file" In-Reply-To: References: Message-ID: On Sat, 10 Apr 2021 01:10:37 GMT, Alex Menkov wrote: > The test actually failed starting from jdk13, but the error is masked by JDK-8264667 (and shell part of the test didn't verify result of the java execution) > The fix: > - updates JvmtiClassFileReconstituter to add attributes in the same order as javac does > - makes the test java instead of shell > - added workaround for JDK-8264667 > - test code is ready to ignore order of attributes test/jdk/java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.java line 152: > 150: // directory so there is no conflict with the file > 151: // in the test classes directory. > 152: String resourceName = fTargetClassName + ".class"; This name can be defined out of methods `originalTargetClassFile` and `transformClassFile`. The method name `transformClassFile` is confusing. I'd suggest to rename it to `transformedClassFile` or `modifiedClassFile`. Also, the name `originalTargetClassFile` can be shortened to `originalClassFile`. ------------- PR: https://git.openjdk.java.net/jdk/pull/3426 From sspitsyn at openjdk.java.net Thu Apr 15 04:05:35 2021 From: sspitsyn at openjdk.java.net (Serguei Spitsyn) Date: Thu, 15 Apr 2021 04:05:35 GMT Subject: RFR: 8262002: java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.sh failed with "TestCaseScaffoldException: DummyClassWithLVT did not match .class file" In-Reply-To: References: Message-ID: On Sat, 10 Apr 2021 01:10:37 GMT, Alex Menkov wrote: > The test actually failed starting from jdk13, but the error is masked by JDK-8264667 (and shell part of the test didn't verify result of the java execution) > The fix: > - updates JvmtiClassFileReconstituter to add attributes in the same order as javac does > - makes the test java instead of shell > - added workaround for JDK-8264667 > - test code is ready to ignore order of attributes test/jdk/java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.java line 186: > 184: int lineNum = 0; > 185: for (String line: out1) { > 186: if (expectedDiffenent(line)) { Is it possible to use the `expectedDiffenent()` as a filter to get only needed lines from `disassembleClassFile()`? ------------- PR: https://git.openjdk.java.net/jdk/pull/3426 From minqi at openjdk.java.net Thu Apr 15 05:24:41 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 15 Apr 2021 05:24:41 GMT Subject: Integrated: 8259070: Add jcmd option to dump CDS In-Reply-To: References: Message-ID: On Fri, 26 Feb 2021 00:03:40 GMT, Yumin Qi wrote: > Hi, Please review > > Added jcmd option for dumping CDS archive during application runtime. Before this change, user has to dump shared archive in two steps: first run application with > `java -XX:DumpLoadedClassList= .... ` > to collect shareable class names and saved in file `` , then > `java -Xshare:dump -XX:SharedClassListFile= -XX:SharedArchiveFile= ...` > With this change, user can use jcmd to dump CDS without going through above steps. Also user can choose a moment during the app runtime to dump an archive. > The bug is associated with the CSR: https://bugs.openjdk.java.net/browse/JDK-8259798 which has been approved. > New added jcmd option: > `jcmd VM.cds static_dump ` > or > `jcmd VM.cds dynamic_dump ` > To dump dynamic archive, requires start app with newly added flag `-XX:+RecordDynamicDumpInfo`, with this flag, some information related to dynamic dump like loader constraints will be recorded. Note the dumping process changed some object memory locations so for dumping dynamic archive, can only done once for a running app. For static dump, user can dump multiple times against same process. > The file name is optional, if the file name is not supplied, the file name will take format of `java_pid_static.jsa` or `java_pid_dynamic.jsa` for static and dynamic respectively. The `` is the application process ID. > > Tests: tier1,tier2,tier3,tier4 > > Thanks > Yumin This pull request has now been integrated. Changeset: e7cbeba8 Author: Yumin Qi URL: https://git.openjdk.java.net/jdk/commit/e7cbeba8 Stats: 857 lines in 23 files changed: 783 ins; 58 del; 16 mod 8259070: Add jcmd option to dump CDS Reviewed-by: ccheung, iklam, mli ------------- PR: https://git.openjdk.java.net/jdk/pull/2737 From minqi at openjdk.java.net Thu Apr 15 05:24:38 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 15 Apr 2021 05:24:38 GMT Subject: RFR: 8259070: Add jcmd option to dump CDS [v12] In-Reply-To: References: Message-ID: <6rB1bQQTIMyzBIPTaK-GTib06tleC6MQlmM6Xy_m8VM=.cf46161f-872a-442f-9229-a02045bc4de9@github.com> On Sat, 27 Feb 2021 18:20:52 GMT, Ioi Lam wrote: >> Hi Yumin, >> >> This is a very useful addition. >> >> My biggest concern with this patch though is the use of `os::fork_and_exec()` in regular, non-fatal situations. I had a look at that function and I think that is very unsafe. >> >> - it does not close file descriptors, so the child vm will inherit all file descriptors not opened with FD_CLOEXEC. In Runtime.exec, we do this whole dance around safely closing off all unused file descriptors, which is missing here. Note that even though we mostly open all fds with CLOEXEC, this does not matter, since user code may not do that. >> - It uses vfork "if available", which is probably always, but that may be okay since the child exec's right away. Still, vfork makes me nervous. >> - Weirdly enough, it always spawns the child program via one indirection using a shell; so there is always the shell between you and your spawned VM, and you probably wont get the return code of your child vm process back. >> >> Until now, os::fork_and_exec() was only used in fatal situations where the VM was about to die anyway. And where it did not really matter if it worked or not. >> >> If we now want to use it in regular situations, we need to give that thing an overhaul and make it a first class fork api, and also test it better that it is today. The file descriptor issue has to be addressed at the very least. >> >> I really would consider rewriting the whole thing using posix_spawn. Since JDK15 I think posix_spawn is the default for Runtime.exec, so we know it works well. I would also do this in a separate RFE. >> >> Alternatively, you could call into java and use Runtime.exec(). >> >> Further remarks inline. >> >> Thanks, Thomas > >> I really would consider rewriting the whole thing using posix_spawn. Since JDK15 I think posix_spawn is the default for Runtime.exec, so we know it works well. I would also do this in a separate RFE. >> >> Alternatively, you could call into java and use Runtime.exec(). > > I think we should call into Java and use `Runtime.exec()`. Running a subprocess is very complicated, so we shouldn't try to duplicate the code in the VM. @iklam @calvinccheung @Hamlin-Li Thanks for review! ------------- PR: https://git.openjdk.java.net/jdk/pull/2737 From stuefe at openjdk.java.net Thu Apr 15 05:55:39 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 15 Apr 2021 05:55:39 GMT Subject: RFR: 8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v27] In-Reply-To: References: Message-ID: On Wed, 14 Apr 2021 14:43:34 GMT, Stefan Johansson wrote: >> Marcus G K Williams has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 44 commits: >> >> - Merge branch 'master' into update_hlp >> - Rebase on pull/3073 >> >> Signed-off-by: Marcus G K Williams >> - Merge branch 'pull/3073' into update_hlp >> - Thomas review. >> >> Changed commit_memory_special to return bool to signal if the request succeeded or not. >> - Self review. >> >> Update helper name to better match commit_memory_special(). >> - Marcus review. >> >> Updated comments. >> - Ivan review >> >> Renamed helper to commit_memory_special and updated the comments. >> - 8262291: Refactor reserve_memory_special_huge_tlbfs >> - Merge branch 'master' into update_hlp >> - Addressed kstefanj review suggestions >> >> Signed-off-by: Marcus G K Williams >> - ... and 34 more: https://git.openjdk.java.net/jdk/compare/f60e81bf...f5bfe224 > > So now #3073 has been integrated, so you could merge with master to get this change. > > I also discussed the meaning of `LargePageSizeInBytes` with some folks internally and @stefank pointed me to: > https://docs.oracle.com/en/java/javase/16/docs/specs/man/java.html > > There the flag is defined as: > > -XX:LargePageSizeInBytes=size > Sets the maximum size (in bytes) for large pages used for the Java heap. The size argument must be > a power of 2 (2, 4, 8, 16, and so on). Append the letter k or K to indicate kilobytes, m or M to > indicate megabytes, or g or G to indicate gigabytes. By default, the size is set to 0, meaning that > the JVM chooses the size for large pages automatically. ... > > > So with this and what's in the code, the default behavior for the VM should be to try to use the best suitable large page size available for a mapping. If `LargePageSizeInBytes` is set this will limit the page sizes used to only include the ones less than or equal to `LargePageSizeInBytes`. > > Does that make sense to everyone? > > This will change the behavior compared to the what we have today: > * Default (`LargePageSizeInBytes=0`) > - old behavior - use the systems default large page size > - new behavior - use all configure large page sizes > * Value set (`LargePageSizeInBytes=X`) > - old behavior - use only large pages of size X > - new behavior - use large pages of size X or smaller > > So the new behavior better fits what's in the docs, but I still suspect we might need a CSR. The behavior proposed by @kstefanj in https://github.com/openjdk/jdk/pull/1153#issuecomment-819573437 sounds good and elegant. A small concern, with `LargePageSizeInBytes=0` we would now use any configured page size, with preference given to the largest possible one, right? Which may take away those pages from some other application on machines where the admin has a carefully groomed large page setup. Say, a database in addition to the java VM. Should this worry us, we could slightly change the meaning of LargePageSizeInBytes=0 to mean "default system page size". This would result in: * Default (`LargePageSizeInBytes=0`) * old behavior - use the systems default large page size * new behavior - use all configured page sizes up to and including the systems default large page size But I am fine with the original proposal too; then the admin in this example would have to manually specify LargePageSizeInBytes=default system page size to prevent the VM from grabbing other page sizes. In any case it would require a release note. Also a CSR. I am very busy atm but May looks better and I could assist with the CSR if needed. Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From xliu at openjdk.java.net Thu Apr 15 06:37:10 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Thu, 15 Apr 2021 06:37:10 GMT Subject: RFR: 8229517: Support for optional asynchronous/buffered logging [v6] In-Reply-To: References: Message-ID: > This patch provides a buffer to store asynchrounous messages and flush them to > underlying files periodically. Xin Liu has updated the pull request incrementally with one additional commit since the last revision: Fix build issue with `--disable-precompiled-headers` ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3135/files - new: https://git.openjdk.java.net/jdk/pull/3135/files/f453d03f..3d74a32b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3135&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3135&range=04-05 Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3135.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3135/head:pull/3135 PR: https://git.openjdk.java.net/jdk/pull/3135 From sjohanss at openjdk.java.net Thu Apr 15 08:49:43 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Thu, 15 Apr 2021 08:49:43 GMT Subject: RFR: 8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v27] In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 16:38:02 GMT, Marcus G K Williams wrote: >> When using LargePageSizeInBytes=1G, os::Linux::reserve_memory_special_huge_tlbfs* cannot select large pages smaller than 1G. Code heap usually uses less than 1G, so currently the code precludes code heap from using >> Large pages in this circumstance and when os::Linux::reserve_memory_special_huge_tlbfs* is called page sizes fall back to Linux::page_size() (usually 4k). >> >> This change allows the above use case by populating all large_page_sizes present in /sys/kernel/mm/hugepages in _page_sizes upon calling os::Linux::setup_large_page_size(). >> >> In os::Linux::reserve_memory_special_huge_tlbfs* we then select the largest large page size available in _page_sizes that is smaller than bytes being reserved. > > Marcus G K Williams has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 44 commits: > > - Merge branch 'master' into update_hlp > - Rebase on pull/3073 > > Signed-off-by: Marcus G K Williams > - Merge branch 'pull/3073' into update_hlp > - Thomas review. > > Changed commit_memory_special to return bool to signal if the request succeeded or not. > - Self review. > > Update helper name to better match commit_memory_special(). > - Marcus review. > > Updated comments. > - Ivan review > > Renamed helper to commit_memory_special and updated the comments. > - 8262291: Refactor reserve_memory_special_huge_tlbfs > - Merge branch 'master' into update_hlp > - Addressed kstefanj review suggestions > > Signed-off-by: Marcus G K Williams > - ... and 34 more: https://git.openjdk.java.net/jdk/compare/f60e81bf...f5bfe224 I would be good with that alteration as well and it will be an even smaller default change in many cases which might be nice. I think we should kick off the CSR work as soon as possible, so I'll look into that. And adding a release note for this change is also a good idea. ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From tschatzl at openjdk.java.net Thu Apr 15 08:57:34 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 15 Apr 2021 08:57:34 GMT Subject: RFR: 8265066: Split ReservedSpace constructor to avoid default parameter In-Reply-To: <3a8swSA9QPceAHBKF_8zz2_OBoRSsENZaO8sORs-idA=.676bbcca-d934-4f96-88e6-7a3c0809d55e@github.com> References: <3a8swSA9QPceAHBKF_8zz2_OBoRSsENZaO8sORs-idA=.676bbcca-d934-4f96-88e6-7a3c0809d55e@github.com> Message-ID: <3kRQ8Jcftk69oi0URPtfDnqpAdRw_zAfySIih5wM3C8=.9fdd5642-d0f3-44e7-ad41-42b27ffe37ae@github.com> On Tue, 13 Apr 2021 09:34:31 GMT, Stefan Johansson wrote: > Please review this change to change this constructor in ReservedSpace: > > // Initialize the reserved space with the given size. If preferred_page_size > // is set, use this as minimum page size/alignment. This may waste some space > // if the given size is not aligned to that value, as the reservation will be > // aligned up to the final alignment in this case. > ReservedSpace(size_t size, size_t preferred_page_size = 0); > > > I propose to split this constructor into two instead of having the default parameter. This makes the implementation more straight forward. I also make the single argument constructor explicit to avoid implicit conversion. There was one place where we relied on implicit conversion and this has been updated to explicitly create the ReservedSpace. > > This cleanup is another step towards: > [JDK-8261527: Record page size used for underlying mapping in ReservedSpace](https://bugs.openjdk.java.net/browse/JDK-8261527) src/hotspot/share/memory/virtualspace.cpp line 58: > 56: > 57: ReservedSpace::ReservedSpace(size_t size, size_t preferred_page_size) : _fd_for_heap(-1) { > 58: assert(is_power_of_2(preferred_page_size), "invariant"); Shouldn't this be something like `is_one_of_available_page_sizes` (or potentially 0 if this means "any")? This assert hasn't been in the original code, and it does not seem correct, so maybe it's not worth putting here too? ------------- PR: https://git.openjdk.java.net/jdk/pull/3457 From sjohanss at openjdk.java.net Thu Apr 15 09:24:50 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Thu, 15 Apr 2021 09:24:50 GMT Subject: RFR: 8265066: Split ReservedSpace constructor to avoid default parameter [v2] In-Reply-To: <3a8swSA9QPceAHBKF_8zz2_OBoRSsENZaO8sORs-idA=.676bbcca-d934-4f96-88e6-7a3c0809d55e@github.com> References: <3a8swSA9QPceAHBKF_8zz2_OBoRSsENZaO8sORs-idA=.676bbcca-d934-4f96-88e6-7a3c0809d55e@github.com> Message-ID: > Please review this change to change this constructor in ReservedSpace: > > // Initialize the reserved space with the given size. If preferred_page_size > // is set, use this as minimum page size/alignment. This may waste some space > // if the given size is not aligned to that value, as the reservation will be > // aligned up to the final alignment in this case. > ReservedSpace(size_t size, size_t preferred_page_size = 0); > > > I propose to split this constructor into two instead of having the default parameter. This makes the implementation more straight forward. I also make the single argument constructor explicit to avoid implicit conversion. There was one place where we relied on implicit conversion and this has been updated to explicitly create the ReservedSpace. > > This cleanup is another step towards: > [JDK-8261527: Record page size used for underlying mapping in ReservedSpace](https://bugs.openjdk.java.net/browse/JDK-8261527) Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision: Thomas review. Removed assert. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3457/files - new: https://git.openjdk.java.net/jdk/pull/3457/files/a4cc6cae..8983be35 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3457&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3457&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3457.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3457/head:pull/3457 PR: https://git.openjdk.java.net/jdk/pull/3457 From sjohanss at openjdk.java.net Thu Apr 15 09:24:51 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Thu, 15 Apr 2021 09:24:51 GMT Subject: RFR: 8265066: Split ReservedSpace constructor to avoid default parameter [v2] In-Reply-To: <3kRQ8Jcftk69oi0URPtfDnqpAdRw_zAfySIih5wM3C8=.9fdd5642-d0f3-44e7-ad41-42b27ffe37ae@github.com> References: <3a8swSA9QPceAHBKF_8zz2_OBoRSsENZaO8sORs-idA=.676bbcca-d934-4f96-88e6-7a3c0809d55e@github.com> <3kRQ8Jcftk69oi0URPtfDnqpAdRw_zAfySIih5wM3C8=.9fdd5642-d0f3-44e7-ad41-42b27ffe37ae@github.com> Message-ID: <8Eq6j_08bMzv5gTWllBMERof378hRjws9f2R8DWhwQ8=.56a7311d-9475-47f7-a3de-1ee6ac729c64@github.com> On Thu, 15 Apr 2021 08:51:21 GMT, Thomas Schatzl wrote: >> Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision: >> >> Thomas review. >> >> Removed assert. > > src/hotspot/share/memory/virtualspace.cpp line 58: > >> 56: >> 57: ReservedSpace::ReservedSpace(size_t size, size_t preferred_page_size) : _fd_for_heap(-1) { >> 58: assert(is_power_of_2(preferred_page_size), "invariant"); > > Shouldn't this be something like `is_one_of_available_page_sizes` (or potentially 0 if this means "any")? This assert hasn't been in the original code, and it does not seem correct, so maybe it's not worth putting here too? Yes, you are correct. The assert would only catch bogus values, and having the assert query the os-layer here might be a bit over the top. I'll just remove the assert for now. ------------- PR: https://git.openjdk.java.net/jdk/pull/3457 From tschatzl at openjdk.java.net Thu Apr 15 10:06:35 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 15 Apr 2021 10:06:35 GMT Subject: RFR: 8265066: Split ReservedSpace constructor to avoid default parameter [v2] In-Reply-To: References: <3a8swSA9QPceAHBKF_8zz2_OBoRSsENZaO8sORs-idA=.676bbcca-d934-4f96-88e6-7a3c0809d55e@github.com> Message-ID: On Thu, 15 Apr 2021 09:24:50 GMT, Stefan Johansson wrote: >> Please review this change to change this constructor in ReservedSpace: >> >> // Initialize the reserved space with the given size. If preferred_page_size >> // is set, use this as minimum page size/alignment. This may waste some space >> // if the given size is not aligned to that value, as the reservation will be >> // aligned up to the final alignment in this case. >> ReservedSpace(size_t size, size_t preferred_page_size = 0); >> >> >> I propose to split this constructor into two instead of having the default parameter. This makes the implementation more straight forward. I also make the single argument constructor explicit to avoid implicit conversion. There was one place where we relied on implicit conversion and this has been updated to explicitly create the ReservedSpace. >> >> This cleanup is another step towards: >> [JDK-8261527: Record page size used for underlying mapping in ReservedSpace](https://bugs.openjdk.java.net/browse/JDK-8261527) > > Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision: > > Thomas review. > > Removed assert. Lgtm. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3457 From chagedorn at openjdk.java.net Thu Apr 15 10:15:51 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Thu, 15 Apr 2021 10:15:51 GMT Subject: RFR: 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests Message-ID: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> This RFE provides an IR test framework to perform regex-based checks on the C2 IR shape of test methods emitted by the VM flags `-XX:+PrintIdeal` and `-XX:+PrintOptoAssembly`. The framework can also be used for other non-IR matching (and non-compiler) tests by providing easy to use annotations for commonly used testing patterns and compiler control flags. The framework is based on the ideas of the currently present IR test framework in [Valhalla](https://github.com/openjdk/valhalla/blob/e9c78ce4fcfd01361c35883e0d68f9ae5a80d079/test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypeTest.java) (mainly implemented by @TobiHartmann) which is being used with great success. This new framework aims to replace the old one in Valhalla at some point. A detailed description about how this new IR test framework works and how it is used is provided in the [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) file and in the [Javadocs](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc/jdk/test/lib/hotspot/ir_framework/package-summary.html) written for the framework classes. To finish a first version of this framework for JDK 17, I decided to leave some improvement possibilities and ideas to be followed up on in additional RFEs. Some ideas are mentioned in "Future Work" in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) and were also created as subtasks of this RFE. Testing (also described in "Internal Framework Tests in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md)): There are various tests to verify the correctness of the test framework which can be found as JTreg tests in the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) folder. Additional testing was performed by converting all compiler Inline Types test of project Valhalla (done by @katyapav in [JDK-8263024](https://bugs.openjdk.java.net/browse/JDK-8263024)) that used the old framework to the new framework. This provided additional testing for the framework itself. We ran the converted tests with all the flag settings used in hs-tier1-9 and hs-precheckin-comp. For sanity checking, this was also done with a sample IR test in mainline. Some stats about the framework code added to [ir_framework](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework): - without the [Javadocs files](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc) : 60 changed files, 13212 insertions, 0 deletions. - without the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) and [examples](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/examples) folder: 40 files changed, 6781 insertions - comments: 2399 insertions (calculated with `git diff --cached !(tests|examples) | grep -c -E "(^[+-]\s*(/)?*)|(^[+-]\s*//)"`) - which leaves 4382 lines of code inserted Big thanks to: - @TobiHartmann for all his help by discussing the new framework and for providing insights from his IR test framework in Valhalla. - @katyapav for converting the Valhalla tests to use the new framework which found some harder to catch bugs in the framework and also some actual C2 bugs. - @iignatev for helping to simplify the framework usage with JTreg and with the framework internal VM calling structure. - and others who provided valuable feedback. Thanks, Christian ------------- Commit messages: - Fix comment - Remove accidentally added print statement - Fix whitespaces + minor fix - Fix whitespaces - Add Javadoc files - 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests Changes: https://git.openjdk.java.net/jdk/pull/3508/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3508&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254129 Stats: 24497 lines in 144 files changed: 24497 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3508.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3508/head:pull/3508 PR: https://git.openjdk.java.net/jdk/pull/3508 From chagedorn at openjdk.java.net Thu Apr 15 13:19:56 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Thu, 15 Apr 2021 13:19:56 GMT Subject: RFR: 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests [v2] In-Reply-To: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> Message-ID: > This RFE provides an IR test framework to perform regex-based checks on the C2 IR shape of test methods emitted by the VM flags `-XX:+PrintIdeal` and `-XX:+PrintOptoAssembly`. The framework can also be used for other non-IR matching (and non-compiler) tests by providing easy to use annotations for commonly used testing patterns and compiler control flags. > > The framework is based on the ideas of the currently present IR test framework in [Valhalla](https://github.com/openjdk/valhalla/blob/e9c78ce4fcfd01361c35883e0d68f9ae5a80d079/test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypeTest.java) (mainly implemented by @TobiHartmann) which is being used with great success. This new framework aims to replace the old one in Valhalla at some point. > > A detailed description about how this new IR test framework works and how it is used is provided in the [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) file and in the [Javadocs](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc/jdk/test/lib/hotspot/ir_framework/package-summary.html) written for the framework classes. > > To finish a first version of this framework for JDK 17, I decided to leave some improvement possibilities and ideas to be followed up on in additional RFEs. Some ideas are mentioned in "Future Work" in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) and were also created as subtasks of this RFE. > > Testing (also described in "Internal Framework Tests in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md)): > There are various tests to verify the correctness of the test framework which can be found as JTreg tests in the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) folder. Additional testing was performed by converting all compiler Inline Types test of project Valhalla (done by @katyapav in [JDK-8263024](https://bugs.openjdk.java.net/browse/JDK-8263024)) that used the old framework to the new framework. This provided additional testing for the framework itself. We ran the converted tests with all the flag settings used in hs-tier1-9 and hs-precheckin-comp. For sanity checking, this was also done with a sample IR test in mainline. > > Some stats about the framework code added to [ir_framework](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework): > > - without the [Javadocs files](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc) : 60 changed files, 13212 insertions, 0 deletions. > - without the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) and [examples](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/examples) folder: 40 files changed, 6781 insertions > - comments: 2399 insertions (calculated with `git diff --cached !(tests|examples) | grep -c -E "(^[+-]\s*(/)?*)|(^[+-]\s*//)"`) > - which leaves 4382 lines of code inserted > > Big thanks to: > - @TobiHartmann for all his help by discussing the new framework and for providing insights from his IR test framework in Valhalla. > - @katyapav for converting the Valhalla tests to use the new framework which found some harder to catch bugs in the framework and also some actual C2 bugs. > - @iignatev for helping to simplify the framework usage with JTreg and with the framework internal VM calling structure. > - and others who provided valuable feedback. > > Thanks, > Christian Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: Adjust whitelist ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3508/files - new: https://git.openjdk.java.net/jdk/pull/3508/files/e2843410..7ed789dc Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3508&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3508&range=00-01 Stats: 9 lines in 1 file changed: 2 ins; 6 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3508.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3508/head:pull/3508 PR: https://git.openjdk.java.net/jdk/pull/3508 From aph at redhat.com Thu Apr 15 15:59:54 2021 From: aph at redhat.com (Andrew Haley) Date: Thu, 15 Apr 2021 16:59:54 +0100 Subject: Mysterious AArch64 test failures on MacOS Message-ID: <9ee3e1b4-3716-4b86-26a3-c0133933f532@redhat.com> Compiling 46 files for jdk.jpackage /Users/aph/jdk/test/hotspot/gtest/classfile/test_AltHashing.cpp:138:22: error: parameter type 'AltHashingTest' is an abstract class TEST_F(AltHashingTest, halfsiphash_test_ByteArray) { ^ /Users/aph/googletest/googletest/include/gtest/gtest.h:494:16: note: unimplemented pure virtual method 'TestBody' in 'AltHashingTest' virtual void TestBody() = 0; ^ /Users/aph/jdk/test/hotspot/gtest/classfile/test_AltHashing.cpp:138:24: error: unknown type name 'halfsiphash_test_ByteArray' TEST_F(AltHashingTest, halfsiphash_test_ByteArray) { ^ This is a default build on AArch64/MacOS. Does anyone else have the same problem? What is it? -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From iignatyev at openjdk.java.net Thu Apr 15 17:52:34 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 15 Apr 2021 17:52:34 GMT Subject: RFR: 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests [v2] In-Reply-To: References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> Message-ID: On Thu, 15 Apr 2021 13:19:56 GMT, Christian Hagedorn wrote: >> This RFE provides an IR test framework to perform regex-based checks on the C2 IR shape of test methods emitted by the VM flags `-XX:+PrintIdeal` and `-XX:+PrintOptoAssembly`. The framework can also be used for other non-IR matching (and non-compiler) tests by providing easy to use annotations for commonly used testing patterns and compiler control flags. >> >> The framework is based on the ideas of the currently present IR test framework in [Valhalla](https://github.com/openjdk/valhalla/blob/e9c78ce4fcfd01361c35883e0d68f9ae5a80d079/test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypeTest.java) (mainly implemented by @TobiHartmann) which is being used with great success. This new framework aims to replace the old one in Valhalla at some point. >> >> A detailed description about how this new IR test framework works and how it is used is provided in the [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) file and in the [Javadocs](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc/jdk/test/lib/hotspot/ir_framework/package-summary.html) written for the framework classes. >> >> To finish a first version of this framework for JDK 17, I decided to leave some improvement possibilities and ideas to be followed up on in additional RFEs. Some ideas are mentioned in "Future Work" in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) and were also created as subtasks of this RFE. >> >> Testing (also described in "Internal Framework Tests in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md)): >> There are various tests to verify the correctness of the test framework which can be found as JTreg tests in the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) folder. Additional testing was performed by converting all compiler Inline Types test of project Valhalla (done by @katyapav in [JDK-8263024](https://bugs.openjdk.java.net/browse/JDK-8263024)) that used the old framework to the new framework. This provided additional testing for the framework itself. We ran the converted tests with all the flag settings used in hs-tier1-9 and hs-precheckin-comp. For sanity checking, this was also done with a sample IR test in mainline. >> >> Some stats about the framework code added to [ir_framework](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework): >> >> - without the [Javadocs files](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc) : 60 changed files, 13212 insertions, 0 deletions. >> - without the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) and [examples](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/examples) folder: 40 files changed, 6781 insertions >> - comments: 2399 insertions (calculated with `git diff --cached !(tests|examples) | grep -c -E "(^[+-]\s*(/)?*)|(^[+-]\s*//)"`) >> - which leaves 4382 lines of code inserted >> >> Big thanks to: >> - @TobiHartmann for all his help by discussing the new framework and for providing insights from his IR test framework in Valhalla. >> - @katyapav for converting the Valhalla tests to use the new framework which found some harder to catch bugs in the framework and also some actual C2 bugs. >> - @iignatev for helping to simplify the framework usage with JTreg and with the framework internal VM calling structure. >> - and others who provided valuable feedback. >> >> Thanks, >> Christian > > Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: > > Adjust whitelist Hi Christian, kudos to you, Tobias, Katya, and all involved, I have really high hopes that this framework will improve the quality of both JVM and our testing. I'll look at the code later, a few general comments: - although having javadoc for testlibraries is highly desirable, I don't think we should check in the generated HTML files - the same goes for `README.html` generated from `README.md` - this library is hotspot-centric, I highly doubt that it will be used by any tests outside of the hotspot test base, hence the more appropriate location for it would be inside `test/hotspot/jtreg/testlibrary`. - I assume `test/lib/jdk/test/lib/hotspot/ir_framework/tests/` are the tests for the framework, in that case they should be in `test/lib-test`, if we stick to `test/lib` as the location for the library, or in `test/hotspot/jtreg/testlibrary_tests`, if we move it to `test/hotspot` Thanks, -- Igor ------------- PR: https://git.openjdk.java.net/jdk/pull/3508 From kvn at openjdk.java.net Thu Apr 15 18:08:38 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Thu, 15 Apr 2021 18:08:38 GMT Subject: RFR: 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests [v2] In-Reply-To: References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> Message-ID: On Thu, 15 Apr 2021 13:19:56 GMT, Christian Hagedorn wrote: >> This RFE provides an IR test framework to perform regex-based checks on the C2 IR shape of test methods emitted by the VM flags `-XX:+PrintIdeal` and `-XX:+PrintOptoAssembly`. The framework can also be used for other non-IR matching (and non-compiler) tests by providing easy to use annotations for commonly used testing patterns and compiler control flags. >> >> The framework is based on the ideas of the currently present IR test framework in [Valhalla](https://github.com/openjdk/valhalla/blob/e9c78ce4fcfd01361c35883e0d68f9ae5a80d079/test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypeTest.java) (mainly implemented by @TobiHartmann) which is being used with great success. This new framework aims to replace the old one in Valhalla at some point. >> >> A detailed description about how this new IR test framework works and how it is used is provided in the [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) file and in the [Javadocs](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc/jdk/test/lib/hotspot/ir_framework/package-summary.html) written for the framework classes. >> >> To finish a first version of this framework for JDK 17, I decided to leave some improvement possibilities and ideas to be followed up on in additional RFEs. Some ideas are mentioned in "Future Work" in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) and were also created as subtasks of this RFE. >> >> Testing (also described in "Internal Framework Tests in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md)): >> There are various tests to verify the correctness of the test framework which can be found as JTreg tests in the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) folder. Additional testing was performed by converting all compiler Inline Types test of project Valhalla (done by @katyapav in [JDK-8263024](https://bugs.openjdk.java.net/browse/JDK-8263024)) that used the old framework to the new framework. This provided additional testing for the framework itself. We ran the converted tests with all the flag settings used in hs-tier1-9 and hs-precheckin-comp. For sanity checking, this was also done with a sample IR test in mainline. >> >> Some stats about the framework code added to [ir_framework](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework): >> >> - without the [Javadocs files](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc) : 60 changed files, 13212 insertions, 0 deletions. >> - without the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) and [examples](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/examples) folder: 40 files changed, 6781 insertions >> - comments: 2399 insertions (calculated with `git diff --cached !(tests|examples) | grep -c -E "(^[+-]\s*(/)?*)|(^[+-]\s*//)"`) >> - which leaves 4382 lines of code inserted >> >> Big thanks to: >> - @TobiHartmann for all his help by discussing the new framework and for providing insights from his IR test framework in Valhalla. >> - @katyapav for converting the Valhalla tests to use the new framework which found some harder to catch bugs in the framework and also some actual C2 bugs. >> - @iignatev for helping to simplify the framework usage with JTreg and with the framework internal VM calling structure. >> - and others who provided valuable feedback. >> >> Thanks, >> Christian > > Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: > > Adjust whitelist I understand the desire to use this framework for more then IR verification but it is main goal. Why you did not place it into `test/lib/sun/hotspot/code/`? I also don't think you should include javadoc generated files into these changes. test/lib/jdk/test/lib/hotspot/ir_framework/CompLevel.java line 62: > 60: * > 61: */ > 62: ANY(-2), This will change (`-2` -> `-1`) after AOT is removed (8264805). test/lib/jdk/test/lib/hotspot/ir_framework/CompLevel.java line 63: > 61: */ > 62: ANY(-2), > 63: /** For completeness may be add value `NONE(0)` for Interpreter only case. test/lib/jdk/test/lib/hotspot/ir_framework/IRMatcher.java line 478: > 476: * Helper class to store information about a method that needs to be IR matched. > 477: */ > 478: class IRMethod { Can you move this class `IRMethod` into a separate file? This file is already big. test/lib/jdk/test/lib/hotspot/ir_framework/examples/TEST.ROOT line 1: > 1: # Minimal TEST.ROOT file to run the examples tests as if the examples would have been placed inside Missing Copyright header. test/lib/jdk/test/lib/hotspot/ir_framework/tests/README.md line 7: > 5: > 6: Additional testing should be performed with the converted Valhalla tests (see [JDK-8263024](https://bugs.openjdk.java.net/browse/JDK-8263024)) to make sure a changeset is correct (these are part of the Valhalla CI). > 7: I don't think you should reference particular RFE which will be resolved eventually. The statement itself is fine. test/lib/jdk/test/lib/hotspot/ir_framework/tests/TEST.ROOT line 1: > 1: # Minimal TEST.ROOT file to run the internal framework tests as if they would have been placed inside Missing Copyright header. ------------- PR: https://git.openjdk.java.net/jdk/pull/3508 From mikael.vidstedt at oracle.com Thu Apr 15 18:59:07 2021 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 15 Apr 2021 18:59:07 +0000 Subject: Mysterious AArch64 test failures on MacOS In-Reply-To: <9ee3e1b4-3716-4b86-26a3-c0133933f532@redhat.com> References: <9ee3e1b4-3716-4b86-26a3-c0133933f532@redhat.com> Message-ID: <195F29CB-C7DB-464B-9DD6-8258FE1E4B2E@oracle.com> I don?t think I?ve seen that. Which version of gtest are you using? Looks like we?re on 1.8.1. Cheers, Mikael > On Apr 15, 2021, at 8:59 AM, Andrew Haley wrote: > > Compiling 46 files for jdk.jpackage > /Users/aph/jdk/test/hotspot/gtest/classfile/test_AltHashing.cpp:138:22: error: parameter type 'AltHashingTest' is an abstract class > TEST_F(AltHashingTest, halfsiphash_test_ByteArray) { > ^ > /Users/aph/googletest/googletest/include/gtest/gtest.h:494:16: note: unimplemented pure virtual method 'TestBody' in 'AltHashingTest' > virtual void TestBody() = 0; > ^ > /Users/aph/jdk/test/hotspot/gtest/classfile/test_AltHashing.cpp:138:24: error: unknown type name 'halfsiphash_test_ByteArray' > TEST_F(AltHashingTest, halfsiphash_test_ByteArray) { > ^ > This is a default build on AArch64/MacOS. Does anyone else have the same > problem? What is it? > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > From dnsimon at openjdk.java.net Thu Apr 15 19:05:33 2021 From: dnsimon at openjdk.java.net (Doug Simon) Date: Thu, 15 Apr 2021 19:05:33 GMT Subject: RFR: 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests [v2] In-Reply-To: References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> Message-ID: On Thu, 15 Apr 2021 13:19:56 GMT, Christian Hagedorn wrote: >> This RFE provides an IR test framework to perform regex-based checks on the C2 IR shape of test methods emitted by the VM flags `-XX:+PrintIdeal` and `-XX:+PrintOptoAssembly`. The framework can also be used for other non-IR matching (and non-compiler) tests by providing easy to use annotations for commonly used testing patterns and compiler control flags. >> >> The framework is based on the ideas of the currently present IR test framework in [Valhalla](https://github.com/openjdk/valhalla/blob/e9c78ce4fcfd01361c35883e0d68f9ae5a80d079/test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypeTest.java) (mainly implemented by @TobiHartmann) which is being used with great success. This new framework aims to replace the old one in Valhalla at some point. >> >> A detailed description about how this new IR test framework works and how it is used is provided in the [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) file and in the [Javadocs](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc/jdk/test/lib/hotspot/ir_framework/package-summary.html) written for the framework classes. >> >> To finish a first version of this framework for JDK 17, I decided to leave some improvement possibilities and ideas to be followed up on in additional RFEs. Some ideas are mentioned in "Future Work" in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) and were also created as subtasks of this RFE. >> >> Testing (also described in "Internal Framework Tests in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md)): >> There are various tests to verify the correctness of the test framework which can be found as JTreg tests in the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) folder. Additional testing was performed by converting all compiler Inline Types test of project Valhalla (done by @katyapav in [JDK-8263024](https://bugs.openjdk.java.net/browse/JDK-8263024)) that used the old framework to the new framework. This provided additional testing for the framework itself. We ran the converted tests with all the flag settings used in hs-tier1-9 and hs-precheckin-comp. For sanity checking, this was also done with a sample IR test in mainline. >> >> Some stats about the framework code added to [ir_framework](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework): >> >> - without the [Javadocs files](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc) : 60 changed files, 13212 insertions, 0 deletions. >> - without the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) and [examples](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/examples) folder: 40 files changed, 6781 insertions >> - comments: 2399 insertions (calculated with `git diff --cached !(tests|examples) | grep -c -E "(^[+-]\s*(/)?*)|(^[+-]\s*//)"`) >> - which leaves 4382 lines of code inserted >> >> Big thanks to: >> - @TobiHartmann for all his help by discussing the new framework and for providing insights from his IR test framework in Valhalla. >> - @katyapav for converting the Valhalla tests to use the new framework which found some harder to catch bugs in the framework and also some actual C2 bugs. >> - @iignatev for helping to simplify the framework usage with JTreg and with the framework internal VM calling structure. >> - and others who provided valuable feedback. >> >> Thanks, >> Christian > > Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: > > Adjust whitelist test/lib/jdk/test/lib/hotspot/ir_framework/README.html line 1: > 1:

IR Test Framework

Just curious: why HTML instead of markdown? ------------- PR: https://git.openjdk.java.net/jdk/pull/3508 From never at openjdk.java.net Thu Apr 15 23:45:37 2021 From: never at openjdk.java.net (Tom Rodriguez) Date: Thu, 15 Apr 2021 23:45:37 GMT Subject: Integrated: 8265180: JvmtiCompiledMethodLoadEvent should include the stub section of nmethods In-Reply-To: References: Message-ID: <5ueJ4HEfOPZjJdNyiEAZgT9FnHXaoGC56m5ZgLK7UU0=.9db908f8-31e4-4ee5-acfb-45ef6a6ea49a@github.com> On Wed, 14 Apr 2021 00:35:55 GMT, Tom Rodriguez wrote: > 8265180: JvmtiCompiledMethodLoadEvent should include the stub section of nmethods This pull request has now been integrated. Changeset: 3423f3e1 Author: Tom Rodriguez URL: https://git.openjdk.java.net/jdk/commit/3423f3e1 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8265180: JvmtiCompiledMethodLoadEvent should include the stub section of nmethods Reviewed-by: kvn, sspitsyn ------------- PR: https://git.openjdk.java.net/jdk/pull/3481 From iignatyev at openjdk.java.net Fri Apr 16 00:44:36 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Fri, 16 Apr 2021 00:44:36 GMT Subject: RFR: 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests [v2] In-Reply-To: References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> Message-ID: On Thu, 15 Apr 2021 18:05:16 GMT, Vladimir Kozlov wrote: > Why you did not place it into `test/lib/sun/hotspot/code/`? there is an RFE to rename `sun.hotspot` testlibrary classes, so I wouldn't put new stuff there. ------------- PR: https://git.openjdk.java.net/jdk/pull/3508 From iignatyev at openjdk.java.net Fri Apr 16 01:33:38 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Fri, 16 Apr 2021 01:33:38 GMT Subject: RFR: 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests [v2] In-Reply-To: References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> Message-ID: On Fri, 16 Apr 2021 01:08:28 GMT, Igor Ignatyev wrote: >> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: >> >> Adjust whitelist > > test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 367: > >> 365: >> 366: for (Class helperClass : helperClasses) { >> 367: TestRun.check(!this.helperClasses.contains(helperClass), "Cannot add the same class twice: " + helperClass); > > won't it be easy to use `Set` to store `helperClasses`? you might also want to update javadoc for this method to state that there can be duplicates. ------------- PR: https://git.openjdk.java.net/jdk/pull/3508 From iignatyev at openjdk.java.net Fri Apr 16 01:33:37 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Fri, 16 Apr 2021 01:33:37 GMT Subject: RFR: 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests [v2] In-Reply-To: References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> Message-ID: On Thu, 15 Apr 2021 13:19:56 GMT, Christian Hagedorn wrote: >> This RFE provides an IR test framework to perform regex-based checks on the C2 IR shape of test methods emitted by the VM flags `-XX:+PrintIdeal` and `-XX:+PrintOptoAssembly`. The framework can also be used for other non-IR matching (and non-compiler) tests by providing easy to use annotations for commonly used testing patterns and compiler control flags. >> >> The framework is based on the ideas of the currently present IR test framework in [Valhalla](https://github.com/openjdk/valhalla/blob/e9c78ce4fcfd01361c35883e0d68f9ae5a80d079/test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypeTest.java) (mainly implemented by @TobiHartmann) which is being used with great success. This new framework aims to replace the old one in Valhalla at some point. >> >> A detailed description about how this new IR test framework works and how it is used is provided in the [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) file and in the [Javadocs](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc/jdk/test/lib/hotspot/ir_framework/package-summary.html) written for the framework classes. >> >> To finish a first version of this framework for JDK 17, I decided to leave some improvement possibilities and ideas to be followed up on in additional RFEs. Some ideas are mentioned in "Future Work" in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) and were also created as subtasks of this RFE. >> >> Testing (also described in "Internal Framework Tests in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md)): >> There are various tests to verify the correctness of the test framework which can be found as JTreg tests in the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) folder. Additional testing was performed by converting all compiler Inline Types test of project Valhalla (done by @katyapav in [JDK-8263024](https://bugs.openjdk.java.net/browse/JDK-8263024)) that used the old framework to the new framework. This provided additional testing for the framework itself. We ran the converted tests with all the flag settings used in hs-tier1-9 and hs-precheckin-comp. For sanity checking, this was also done with a sample IR test in mainline. >> >> Some stats about the framework code added to [ir_framework](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework): >> >> - without the [Javadocs files](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc) : 60 changed files, 13212 insertions, 0 deletions. >> - without the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) and [examples](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/examples) folder: 40 files changed, 6781 insertions >> - comments: 2399 insertions (calculated with `git diff --cached !(tests|examples) | grep -c -E "(^[+-]\s*(/)?*)|(^[+-]\s*//)"`) >> - which leaves 4382 lines of code inserted >> >> Big thanks to: >> - @TobiHartmann for all his help by discussing the new framework and for providing insights from his IR test framework in Valhalla. >> - @katyapav for converting the Valhalla tests to use the new framework which found some harder to catch bugs in the framework and also some actual C2 bugs. >> - @iignatev for helping to simplify the framework usage with JTreg and with the framework internal VM calling structure. >> - and others who provided valuable feedback. >> >> Thanks, >> Christian > > Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: > > Adjust whitelist Hi Christian, here is the 1st portion of my comments. I'll return to reviewing it 1st thing tomorrow... Cheers, -- Igor test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 107: > 105: */ > 106: public static final Set JTREG_WHITELIST_FLAGS = new HashSet<>( > 107: Arrays.asList( it doesn't seem to be a comprehensive list of flags that don't affect IR verification work, e.g. different GCs. I think it might be easy to go with the blacklist instead, and possibly warning people if there are any flags in `test.*.opts`. test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 146: > 144: private List> helperClasses = null; > 145: private List scenarios = null; > 146: private final List flags = new ArrayList<>(); why did you decide to eagerly create list for `flags`, but not for `scenarios` / `helpersClasses`? test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 166: > 164: if (VERBOSE) { > 165: System.out.println("Test class: " + testClass); > 166: } this c-tor can be replaced by: Suggestion: this(StackWalker.getInstance(StackWalker.Option.RETAIN_CLASS_REFERENCE).getCallerClass()); and actually, I don't see it being used (outside of the tests for this testlibrary) and I don't think it will ever be used by actual tests that would use this framework, so I think we can safely remove it. test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 211: > 209: } > 210: > 211: /** I'm not sure how much of the benefits all these different `run.*` bring. I fully understand the desire to simplify the most common use-case (i.e. no-arg `run`), but for the rest I'd assume the users will be capable of writing, for example, `new TestFramework(testClass).addScenarios(scenarios).start();` instead of `TestFramework .runWithScenarios(testClass, scenarios);` test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 269: > 267: *
    > 268: *

  • If a helper class is not in the same file as the test class, make sure that JTreg compiles it by using > 269: * {@literal @}compile in the JTreg header comment block.

    • you don't need `@compile` to compile a helper class, 1st of all, you shouldn't use `@compile` when you want to compile a class in your test, you should use `@build`, 2nd, in this particular case, the class will be automatically built as part of your test b/c jtreg (or rather javac) will be able to statically detect it as a dependency of the code that calls `runWithHelperClasses(Class, Class...)` test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 366: > 364: } > 365: > 366: for (Class helperClass : helperClasses) { nit: I'd use `var` here test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 367: > 365: > 366: for (Class helperClass : helperClasses) { > 367: TestRun.check(!this.helperClasses.contains(helperClass), "Cannot add the same class twice: " + helperClass); won't it be easy to use `Set` to store `helperClasses`? test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 407: > 405: start(null); > 406: } catch (TestVMException e) { > 407: System.err.println("\n" + e.getExceptionInfo()); you shouldn't use "\n", as it might not be the right line-separator. you can either do: Suggestion: System.err.println(); System.err.println(e.getExceptionInfo()); or Suggestion: System.err.printf("%n%s%n", e.getExceptionInfo()); test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 604: > 602: * Disable IR verification completely in certain cases. > 603: */ > 604: private void maybeDisableIRVerificationCompletely() { nit: Suggestion: private void disableIRVerificationIfNotFeasible() { test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 617: > 615: "and PrintOptoAssembly), running with -Xint, or -Xcomp (use warm-up of 0 instead)"); > 616: return; > 617: } I'd reorder them as "platform" checks are faster than `hasIRAnnotations` check and, I'd guess, will be a more common culprit to disable IR verification. test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 669: > 667: } > 668: if (e instanceof IRViolationException) { > 669: IRViolationException irException = (IRViolationException) e; nit: Suggestion: if (e instanceof IRViolationException irException) { test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 674: > 672: + "Compilation(s) of failed matche(s):"); > 673: System.out.println(irException.getCompilations()); > 674: builder.append(errorMsg).append("\n").append(irException.getExceptionInfo()).append(e.getMessage()); as `builder.toString` will be printed out to cout/cerr, you should use platform-specific line-separator instead of `\n` ------------- Changes requested by iignatyev (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3508 From dholmes at openjdk.java.net Fri Apr 16 06:18:40 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 16 Apr 2021 06:18:40 GMT Subject: RFR: 8264372: Threads::destroy_vm only ever returns true Message-ID: Trivial cleanup to remove the bool return from Threads::destroy_vm as it only ever returned true. Testing: tiers 1-3 Thanks, David ------------- Commit messages: - 8264372: Threads::destroy_vm only ever returns true Changes: https://git.openjdk.java.net/jdk/pull/3535/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3535&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264372 Stats: 15 lines in 3 files changed: 0 ins; 9 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/3535.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3535/head:pull/3535 PR: https://git.openjdk.java.net/jdk/pull/3535 From xliu at openjdk.java.net Fri Apr 16 07:05:15 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Fri, 16 Apr 2021 07:05:15 GMT Subject: RFR: 8229517: Support for optional asynchronous/buffered logging [v7] In-Reply-To: References: Message-ID: > This patch provides a buffer to store asynchrounous messages and flush them to > underlying files periodically. Xin Liu has updated the pull request incrementally with one additional commit since the last revision: Support Jcmd pid VM.log disable This patch also supports to add a new output dynamically. If output_option specifies async=true, the new output will use asynchronous writing. Currently jcmd VM.log prohibts users from changing established output_options in runtime. users can disable them all and then recreate them with the new output_options. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3135/files - new: https://git.openjdk.java.net/jdk/pull/3135/files/3d74a32b..2bd104ff Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3135&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3135&range=05-06 Stats: 13 lines in 2 files changed: 11 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3135.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3135/head:pull/3135 PR: https://git.openjdk.java.net/jdk/pull/3135 From shade at openjdk.java.net Fri Apr 16 07:25:34 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 16 Apr 2021 07:25:34 GMT Subject: RFR: 8264372: Threads::destroy_vm only ever returns true In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 06:12:39 GMT, David Holmes wrote: > Trivial cleanup to remove the bool return from Threads::destroy_vm as it only ever returned true. > > Testing: tiers 1-3 > > Thanks, > David Looks good to me. src/hotspot/share/prims/jni.cpp line 3735: > 3733: ThreadStateTransition::transition_from_native(thread, _thread_in_vm); > 3734: Threads::destroy_vm(); > 3735: // Should not change thread state, VM is gone It looks like this comment is there to match the removed `ThreadStateTransition::transition(thread, _thread_in_vm, _thread_in_native);`? In other words, it looks unnecessary. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3535 From thartmann at openjdk.java.net Fri Apr 16 08:11:40 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Fri, 16 Apr 2021 08:11:40 GMT Subject: RFR: 8265323: Leftover local variables in PcDesc In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 03:16:30 GMT, Yi Yang wrote: > Leftover local variables in PcDesc. Remove it to save electric power. Marked as reviewed by thartmann (Reviewer). src/hotspot/share/code/pcDesc.cpp line 46: > 44: #ifndef PRODUCT > 45: ResourceMark rm; > 46: st->print_cr("PcDesc(pc=" PTR_FORMAT " offset=%x bits=%x):", p2i(real_pc(code)), pc_offset(), _flags); This changes the output from PcDesc(pc=0x00007fe00d12475f offset=ffffffff bits=0): PcDesc(pc=0x00007fe00d12478c offset=2c bits=0): Test::test3 at -1 (line 33) ``` to PcDesc(pc=0x00007f4fc9035a5f offset=ffffffff bits=0): PcDesc(pc=0x00007f4fc9035a8c offset=2c bits=0): Test::test3 at -1 (line 33) ``` But since that is more inline with the output of `ScopeDesc::print_on`, that's fine with me. ------------- PR: https://git.openjdk.java.net/jdk/pull/3532 From mgronlun at openjdk.java.net Fri Apr 16 08:43:34 2021 From: mgronlun at openjdk.java.net (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 16 Apr 2021 08:43:34 GMT Subject: RFR: 8244190: JFR: When starting a JVM with -XX:StartFlightRecording, output is written to stdout In-Reply-To: <4lEy3QYbIm_kI-Nap9g4oRaSmRIDzmugBRSvJ9zqa2c=.e5cd4790-6080-4c30-8747-c9e3ab2d545d@github.com> References: <4lEy3QYbIm_kI-Nap9g4oRaSmRIDzmugBRSvJ9zqa2c=.e5cd4790-6080-4c30-8747-c9e3ab2d545d@github.com> Message-ID: <2wuOHJoCC9Plc9xiHfrWobWtPU8a3eWjwSsGOIH9qxE=.f22c9b5d-89b2-4c07-9731-31df93928d55@github.com> On Fri, 9 Apr 2021 15:24:52 GMT, Erik Gahlin wrote: > Hi, > > Could I have review of a change that makes it possible to silence the output of JFR during startup. That is: > > "Started recording 1. No limit specified, using maxsize=250MB as default. > > Use jcmd 38045 JFR.dump name=1 filename=FILEPATH to copy recording data to file" > > There are severals ways to approach this: > > 1) Remove the output completely > - Con: Users will think JFR is not working since they are used to see the output > - Con: The PID must be found by other means > - Con: No hint about jcmd, or disk space being used > > 2) Introduce a flag to silence the output, i.e. -XX:StartFlightRecording:silent=true > - Con: Users must read documentation to find out about the option > - Con: It introduces a second mechanism to control logging > - Pro: Easy to backport. No behavioral change. > > 3) Write to unified logging with level Info > - Con: Users will think JFR is not working since they are used to see the output > - Con: The PID must be found by other means > - Con: No hint about jcmd, or disk space being used > - Con: Users must read documentation to find out about -Xlog:jfr+startup=info > > 4) Write to unified logging with level Warning > - Con: Confusing since it is not a warning. > - Pro: Users can see the tag set and turn it off easily using -Xlog:jfr+startup=off/error > > 5) If -XX:StartFlightRecording has been specified, set jfr+startup=Info temporarily and write with level Info. > - Con: If user has specified -Xlog:jfr+startup=warning it will not take effect. > - Pro: Users can see the tag set and turn it off easily using -Xlog:jfr+startup=off/error > > One could try to detect if the user has set the level to jfr+startup=warning and not change the level to Info in those cases. Unfortunately there is no mechanism in UL to see if a tag set has been touched and one would need to take into account there could be several types of output, i.e. files, that can be touched. It becomes complicated. > > I have chosen to implement 5. It's not perfect, but perhaps sufficient for now? Detection of -Xlog:jfr+startup=warning could be added in the future if there is a need. > > $ java -XX:StartFlightRecording -version > [0.385s][info][jfr,startup] Started recording 1. No limit specified, using maxsize=250MB as default. > [0.385s][info][jfr,startup] > [0.385s][info][jfr,startup] Use jcmd 7469 JFR.dump name=1 filename=FILEPATH to copy recording data to file. > > $ java -XX:StartFlightRecording:settings=foo.bar -version > [0.174s][error][jfr,startup] Could not parse settings file 'foo.bar' > > Testing: jdk/jdk/jfr, tier1-tier4 > > Thanks > Erik Looks good. ------------- Marked as reviewed by mgronlun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3417 From aph at redhat.com Fri Apr 16 08:54:15 2021 From: aph at redhat.com (Andrew Haley) Date: Fri, 16 Apr 2021 09:54:15 +0100 Subject: Mysterious AArch64 test failures on MacOS In-Reply-To: <195F29CB-C7DB-464B-9DD6-8258FE1E4B2E@oracle.com> References: <9ee3e1b4-3716-4b86-26a3-c0133933f532@redhat.com> <195F29CB-C7DB-464B-9DD6-8258FE1E4B2E@oracle.com> Message-ID: <7ac26415-3dc3-10d0-1388-ab658f014b6b@redhat.com> On 4/15/21 7:59 PM, Mikael Vidstedt wrote: > > I don?t think I?ve seen that. Which version of gtest are you using? Looks like we?re on 1.8.1. That's it, thanks, I was on 1.10. Looks like it's something to do with pre-C++11 compatibility, but this is JDK head, so I don't know what. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From david.holmes at oracle.com Fri Apr 16 09:13:13 2021 From: david.holmes at oracle.com (David Holmes) Date: Fri, 16 Apr 2021 19:13:13 +1000 Subject: RFR: 8264372: Threads::destroy_vm only ever returns true In-Reply-To: References: Message-ID: On 16/04/2021 5:25 pm, Aleksey Shipilev wrote: > On Fri, 16 Apr 2021 06:12:39 GMT, David Holmes wrote: > >> Trivial cleanup to remove the bool return from Threads::destroy_vm as it only ever returned true. >> >> Testing: tiers 1-3 >> >> Thanks, >> David > > Looks good to me. Thanks for looking at this Aleksey! > src/hotspot/share/prims/jni.cpp line 3735: > >> 3733: ThreadStateTransition::transition_from_native(thread, _thread_in_vm); >> 3734: Threads::destroy_vm(); >> 3735: // Should not change thread state, VM is gone > > It looks like this comment is there to match the removed `ThreadStateTransition::transition(thread, _thread_in_vm, _thread_in_native);`? In other words, it looks unnecessary. Right - I will remove. I was reading it as "Don't bother changing state any more, VM is gone". David > ------------- > > Marked as reviewed by shade (Reviewer). > > PR: https://git.openjdk.java.net/jdk/pull/3535 > From neliasso at openjdk.java.net Fri Apr 16 09:30:33 2021 From: neliasso at openjdk.java.net (Nils Eliasson) Date: Fri, 16 Apr 2021 09:30:33 GMT Subject: RFR: 8265323: Leftover local variables in PcDesc In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 03:16:30 GMT, Yi Yang wrote: > Leftover local variables in PcDesc. Remove it to save electric power. Approved. ------------- Marked as reviewed by neliasso (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3532 From shade at openjdk.java.net Fri Apr 16 10:15:58 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 16 Apr 2021 10:15:58 GMT Subject: RFR: 8265332: gtest/LargePageGtests.java OOMEs on -XX:+UseSHM cases Message-ID: It looks like some `+UseSHM` test cases added by [JDK-8213269](https://bugs.openjdk.java.net/browse/JDK-8213269) reliably blow up the VM log reader with OOME. There are lots of `OpenJDK 64-Bit Server VM warning: Failed to reserve shared memory.` in the log, if you increase the test heap size. AFAIU, many of those messages are expected from the new test cases. I believe ultimately this test produces a virtually unbounded number of warning messages, which would eventually blow out the Java heap. `ConcurrentTestRunner` runs a time-bound number of iterations, which means the faster machine is, the more warning messages would be printed. I believe the way out is to make `ConcurrentTestRunner` to cap the number of iterations, so that VM output length is more predictable. This is a reliable `tier1` failure on my TR 3970X. Test times before: # default [ OK ] os_linux.reserve_memory_special_concurrent_vm (15003 ms) # -XX:+UseLargePages [ OK ] os_linux.reserve_memory_special_concurrent_vm (16121 ms) # -XX:+UseLargePages -XX:LargePageSizeInBytes=1G [ OK ] os_linux.reserve_memory_special_concurrent_vm (15006 ms) # -XX:+UseLargePages -XX:+UseSHM [ OK ] os_linux.reserve_memory_special_concurrent_vm (15030 ms) Test times after: # default [ OK ] os_linux.reserve_memory_special_concurrent_vm (15003 ms) # -XX:+UseLargePages [ OK ] os_linux.reserve_memory_special_concurrent_vm (16071 ms) # -XX:+UseLargePages -XX:LargePageSizeInBytes=1G [ OK ] os_linux.reserve_memory_special_concurrent_vm (15006 ms) # -XX:+UseLargePages -XX:+UseSHM [ OK ] os_linux.reserve_memory_special_concurrent_vm (1190 ms) The major difference is that the last mode gets capped by `maxIteration`. This fixes the test failure, as `-XX:+UseSHM` case would produce lots of warnings on my machine. Additional testing: - [x] `os_linux` gtest - [x] `gtest/LargePageGtests.java` used to fail, now passes ------------- Commit messages: - 8265332: gtest/LargePageGtests.java OOMEs on -XX:+UseSHM cases Changes: https://git.openjdk.java.net/jdk/pull/3542/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3542&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265332 Stats: 23 lines in 4 files changed: 13 ins; 0 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/3542.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3542/head:pull/3542 PR: https://git.openjdk.java.net/jdk/pull/3542 From dcubed at openjdk.java.net Fri Apr 16 15:05:37 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 16 Apr 2021 15:05:37 GMT Subject: RFR: 8264372: Threads::destroy_vm only ever returns true In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 06:12:39 GMT, David Holmes wrote: > Trivial cleanup to remove the bool return from Threads::destroy_vm as it only ever returned true. > > Testing: tiers 1-3 > > Thanks, > David Thumbs up! `// Don't bother changing state any more, VM is gone.` would be a better comment. ------------- Marked as reviewed by dcubed (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3535 From stuefe at openjdk.java.net Fri Apr 16 17:01:45 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Fri, 16 Apr 2021 17:01:45 GMT Subject: RFR: 8265332: gtest/LargePageGtests.java OOMEs on -XX:+UseSHM cases In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 10:06:43 GMT, Aleksey Shipilev wrote: > It looks like some `+UseSHM` test cases added by [JDK-8213269](https://bugs.openjdk.java.net/browse/JDK-8213269) reliably blow up the VM log reader with OOME. There are lots of `OpenJDK 64-Bit Server VM warning: Failed to reserve shared memory.` in the log, if you increase the test heap size. AFAIU, many of those messages are expected from the new test cases. > > I believe ultimately this test produces a virtually unbounded number of warning messages, which would eventually blow out the Java heap in test infra parsers. `ConcurrentTestRunner` runs a time-bound number of iterations, which means the faster machine is, the more warning messages would be printed. I believe the way out is to make `ConcurrentTestRunner` to cap the number of iterations, so that VM output length is more predictable. > > This is a reliable tier1 failure on my TR 3970X, probably because it has enough cores to run 30 threads concurrently for 15 seconds all spewing warning messages. > > Test times before: > > > # default > [ OK ] os_linux.reserve_memory_special_concurrent_vm (15003 ms) > > # -XX:+UseLargePages > [ OK ] os_linux.reserve_memory_special_concurrent_vm (16121 ms) > > # -XX:+UseLargePages -XX:LargePageSizeInBytes=1G > [ OK ] os_linux.reserve_memory_special_concurrent_vm (15006 ms) > > # -XX:+UseLargePages -XX:+UseSHM > [ OK ] os_linux.reserve_memory_special_concurrent_vm (15030 ms) > > > Test times after: > > > # default > [ OK ] os_linux.reserve_memory_special_concurrent_vm (15003 ms) > > # -XX:+UseLargePages > [ OK ] os_linux.reserve_memory_special_concurrent_vm (16071 ms) > > # -XX:+UseLargePages -XX:LargePageSizeInBytes=1G > [ OK ] os_linux.reserve_memory_special_concurrent_vm (15006 ms) > > # -XX:+UseLargePages -XX:+UseSHM > [ OK ] os_linux.reserve_memory_special_concurrent_vm (1190 ms) > > > The major difference is that the last mode gets capped by `maxIteration`. This fixes the test failure, as `-XX:+UseSHM` case would produce lots of warnings on my machine. > > Additional testing: > - [x] `os_linux` gtest > - [x] `gtest/LargePageGtests.java` used to fail, now passes I think a better and simpler way would be to make those messages conditional. IMHO only fatal error information should be unconditionally printed. This is not fatal, since if we get no large pages the VM would just happily switch to small pages. I wanted to quieten these messages for a long time, but never dared because of backward compatibility. But maybe we should just do it. Another useful fix, for a different RFE maybe, would be to limit size of output from chatty sub processes in the test framework to something sensible. ------------- PR: https://git.openjdk.java.net/jdk/pull/3542 From egahlin at openjdk.java.net Fri Apr 16 17:30:44 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Fri, 16 Apr 2021 17:30:44 GMT Subject: Integrated: 8244190: JFR: When starting a JVM with -XX:StartFlightRecording, output is written to stdout In-Reply-To: <4lEy3QYbIm_kI-Nap9g4oRaSmRIDzmugBRSvJ9zqa2c=.e5cd4790-6080-4c30-8747-c9e3ab2d545d@github.com> References: <4lEy3QYbIm_kI-Nap9g4oRaSmRIDzmugBRSvJ9zqa2c=.e5cd4790-6080-4c30-8747-c9e3ab2d545d@github.com> Message-ID: On Fri, 9 Apr 2021 15:24:52 GMT, Erik Gahlin wrote: > Hi, > > Could I have review of a change that makes it possible to silence the output of JFR during startup. That is: > > "Started recording 1. No limit specified, using maxsize=250MB as default. > > Use jcmd 38045 JFR.dump name=1 filename=FILEPATH to copy recording data to file" > > There are severals ways to approach this: > > 1) Remove the output completely > - Con: Users will think JFR is not working since they are used to see the output > - Con: The PID must be found by other means > - Con: No hint about jcmd, or disk space being used > > 2) Introduce a flag to silence the output, i.e. -XX:StartFlightRecording:silent=true > - Con: Users must read documentation to find out about the option > - Con: It introduces a second mechanism to control logging > - Pro: Easy to backport. No behavioral change. > > 3) Write to unified logging with level Info > - Con: Users will think JFR is not working since they are used to see the output > - Con: The PID must be found by other means > - Con: No hint about jcmd, or disk space being used > - Con: Users must read documentation to find out about -Xlog:jfr+startup=info > > 4) Write to unified logging with level Warning > - Con: Confusing since it is not a warning. > - Pro: Users can see the tag set and turn it off easily using -Xlog:jfr+startup=off/error > > 5) If -XX:StartFlightRecording has been specified, set jfr+startup=Info temporarily and write with level Info. > - Con: If user has specified -Xlog:jfr+startup=warning it will not take effect. > - Pro: Users can see the tag set and turn it off easily using -Xlog:jfr+startup=off/error > > One could try to detect if the user has set the level to jfr+startup=warning and not change the level to Info in those cases. Unfortunately there is no mechanism in UL to see if a tag set has been touched and one would need to take into account there could be several types of output, i.e. files, that can be touched. It becomes complicated. > > I have chosen to implement 5. It's not perfect, but perhaps sufficient for now? Detection of -Xlog:jfr+startup=warning could be added in the future if there is a need. > > $ java -XX:StartFlightRecording -version > [0.385s][info][jfr,startup] Started recording 1. No limit specified, using maxsize=250MB as default. > [0.385s][info][jfr,startup] > [0.385s][info][jfr,startup] Use jcmd 7469 JFR.dump name=1 filename=FILEPATH to copy recording data to file. > > $ java -XX:StartFlightRecording:settings=foo.bar -version > [0.174s][error][jfr,startup] Could not parse settings file 'foo.bar' > > Testing: jdk/jdk/jfr, tier1-tier4 > > Thanks > Erik This pull request has now been integrated. Changeset: 7c37c022 Author: Erik Gahlin URL: https://git.openjdk.java.net/jdk/commit/7c37c022 Stats: 170 lines in 11 files changed: 130 ins; 7 del; 33 mod 8244190: JFR: When starting a JVM with -XX:StartFlightRecording, output is written to stdout Reviewed-by: mgronlun ------------- PR: https://git.openjdk.java.net/jdk/pull/3417 From iignatyev at openjdk.java.net Fri Apr 16 18:27:39 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Fri, 16 Apr 2021 18:27:39 GMT Subject: RFR: 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests [v2] In-Reply-To: References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> Message-ID: On Thu, 15 Apr 2021 13:19:56 GMT, Christian Hagedorn wrote: >> This RFE provides an IR test framework to perform regex-based checks on the C2 IR shape of test methods emitted by the VM flags `-XX:+PrintIdeal` and `-XX:+PrintOptoAssembly`. The framework can also be used for other non-IR matching (and non-compiler) tests by providing easy to use annotations for commonly used testing patterns and compiler control flags. >> >> The framework is based on the ideas of the currently present IR test framework in [Valhalla](https://github.com/openjdk/valhalla/blob/e9c78ce4fcfd01361c35883e0d68f9ae5a80d079/test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypeTest.java) (mainly implemented by @TobiHartmann) which is being used with great success. This new framework aims to replace the old one in Valhalla at some point. >> >> A detailed description about how this new IR test framework works and how it is used is provided in the [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) file and in the [Javadocs](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc/jdk/test/lib/hotspot/ir_framework/package-summary.html) written for the framework classes. >> >> To finish a first version of this framework for JDK 17, I decided to leave some improvement possibilities and ideas to be followed up on in additional RFEs. Some ideas are mentioned in "Future Work" in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) and were also created as subtasks of this RFE. >> >> Testing (also described in "Internal Framework Tests in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md)): >> There are various tests to verify the correctness of the test framework which can be found as JTreg tests in the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) folder. Additional testing was performed by converting all compiler Inline Types test of project Valhalla (done by @katyapav in [JDK-8263024](https://bugs.openjdk.java.net/browse/JDK-8263024)) that used the old framework to the new framework. This provided additional testing for the framework itself. We ran the converted tests with all the flag settings used in hs-tier1-9 and hs-precheckin-comp. For sanity checking, this was also done with a sample IR test in mainline. >> >> Some stats about the framework code added to [ir_framework](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework): >> >> - without the [Javadocs files](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc) : 60 changed files, 13212 insertions, 0 deletions. >> - without the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) and [examples](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/examples) folder: 40 files changed, 6781 insertions >> - comments: 2399 insertions (calculated with `git diff --cached !(tests|examples) | grep -c -E "(^[+-]\s*(/)?*)|(^[+-]\s*//)"`) >> - which leaves 4382 lines of code inserted >> >> Big thanks to: >> - @TobiHartmann for all his help by discussing the new framework and for providing insights from his IR test framework in Valhalla. >> - @katyapav for converting the Valhalla tests to use the new framework which found some harder to catch bugs in the framework and also some actual C2 bugs. >> - @iignatev for helping to simplify the framework usage with JTreg and with the framework internal VM calling structure. >> - and others who provided valuable feedback. >> >> Thanks, >> Christian > > Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: > > Adjust whitelist next portion of my comments, stay tuned for more to come :) -- Igor PS I must say that by some reason github's 'file changed' tab is unbelievably slow for me in this particular PR, so it's somewhat painful to even just find the place I want to associate my comment with (not to speak about actually using it to browse/read the code) test/lib/jdk/test/lib/hotspot/ir_framework/AbstractInfo.java line 41: > 39: */ > 40: abstract public class AbstractInfo { > 41: private static final Random random = new Random(); you shouldn't use Random w/o predefined seed as it might make it harder to reproduce, please consider using `jdk.test.lib.Utils.getRandomInstance` or `jdk.test.lib.RandomFactory.getRandom` here test/lib/jdk/test/lib/hotspot/ir_framework/AbstractInfo.java line 57: > 55: * @return an inverted boolean of the result of the last invocation of this method. > 56: */ > 57: public boolean toggleBoolean() { I don't think `toggleBoolean` really belongs to `AbstractInfo`, I'd rather move it into a (separate) aux class. test/lib/jdk/test/lib/hotspot/ir_framework/ArgumentValue.java line 35: > 33: */ > 34: class ArgumentValue { > 35: private static final Random random = new Random(); the same comment as in `AbstractInfo`, please use the reproducible rng here. test/lib/jdk/test/lib/hotspot/ir_framework/IREncodingPrinter.java line 213: > 211: > 212: private boolean checkBooleanFlag(String flag, String value, Boolean actualFlagValue) { > 213: boolean actualBooleanFlagValue = actualFlagValue; as `actualFlagValue` can't be null, you don't need to use box here: Suggestion: private boolean checkBooleanFlag(String flag, String value, boolean actualBooleanFlagValue) { the same for `checkLongFlag`, `checkDoubleFlag` test/lib/jdk/test/lib/hotspot/ir_framework/IRMatcher.java line 47: > 45: > 46: public IRMatcher(String hotspotPidFileName, String irEncoding, Class testClass) { > 47: this.compilations = new LinkedHashMap<>(); why do we use LinkedHashMap here (as opposed to HashMap)? I haven't found the place where you need to traverse it in the insertion order. test/lib/jdk/test/lib/hotspot/ir_framework/IRMatcher.java line 88: > 86: Map irRulesMap = new HashMap<>(); > 87: String patternString = "(?<=" + IREncodingPrinter.START + "\\R)[\\s\\S]*(?=" + IREncodingPrinter.END + ")"; > 88: Pattern pattern = Pattern.compile(patternString); `patternString` is effectively a constant here, but you will compile it into `j.u.Pattern` on each invocation of `parseIREncoding`, it might be a better idea to introduce a static field that holds a precompiled patter. test/lib/jdk/test/lib/hotspot/ir_framework/IRMatcher.java line 98: > 96: String[] splitComma = line.split(","); > 97: if (splitComma.length < 2) { > 98: throw new TestFrameworkException("Invalid IR match rule encoding"); will it make sense to include the line-offender into the exception message here? test/lib/jdk/test/lib/hotspot/ir_framework/IRMatcher.java line 101: > 99: } > 100: String testName = splitComma[0]; > 101: Integer[] irRulesIdx = new Integer[splitComma.length - 1]; you can actually use an array of int here, so there will be less wasted memory and no unboxing later on test/lib/jdk/test/lib/hotspot/ir_framework/IRMatcher.java line 116: > 114: private void parseHotspotPidFile() { > 115: Map compileIdMap = new HashMap<>(); > 116: try (BufferedReader br = new BufferedReader(new FileReader(new File(System.getProperty("user.dir") + File.separator + hotspotPidFileName)))) { more idiomatic/modern version would be Suggestion: try (BufferedReader br = Files.newBufferedReader(Paths.get(System.getProperty("user.dir"), hotspotPidFileName))) { I actually not sure if you really need `$user.dir`, won't hotspot_pid file get generated in the current dir? test/lib/jdk/test/lib/hotspot/ir_framework/IRMatcher.java line 207: > 205: private void addTestMethodCompileId(Map compileIdMap, String line) { > 206: Pattern pattern = Pattern.compile("compile_id='(\\d+)'.*" + Pattern.quote(testClass.getCanonicalName()) + " (\\S+)"); > 207: Matcher matcher = pattern.matcher(line); similarly to `parseIREncoding`, `pattern` here can be precomputed in `IRMatcher::IRMatcher` and stored into a final instance field. test/lib/jdk/test/lib/hotspot/ir_framework/IRMatcher.java line 243: > 241: private String getMethodName(Map compileIdMap, String line) { > 242: Pattern pattern = Pattern.compile("compile_id='(\\d+)'"); > 243: Matcher matcher = pattern.matcher(line); again, precompiled pattern can be saved into a (in this case) static field and reused. test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 639: > 637: TestFormat.check(!scenarioIndices.contains(scenarioIndex), > 638: "Cannot define two scenarios with the same index " + scenarioIndex); > 639: scenarioIndices.add(scenarioIndex); you can use `Set::add` to verify that the element isn't in a set: Suggestion: TestFormat.check(scenarioIndices.add(scenarioIndex), "Cannot define two scenarios with the same index " + scenarioIndex); test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 795: > 793: private void checkFlagVMExitCode(OutputAnalyzer oa) { > 794: String flagVMOutput = oa.getOutput(); > 795: final int exitCode = oa.getExitValue(); nit: there is no need for this `final` test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 804: > 802: System.err.println("--- OUTPUT TestFramework flag VM ---"); > 803: System.err.println(flagVMOutput); > 804: throw new RuntimeException("\nTestFramework flag VM exited with " + exitCode); what's the reason for `\n` in the begging of this exception message? test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 958: > 956: throw new TestFrameworkException("Internal Test Framework exception - please file a bug:\n" + failureMessage, e); > 957: } > 958: } I am not convinced that we really these guys when we already have `TestFormat::check` and `TestRun::check` (I'm actually not 100% convinced that we need check/fail in both TestFormat and TestRun) test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 1027: > 1025: } > 1026: > 1027: public static String getRerunHint() { why is this a method and not just a public final static String? test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 1043: > 1041: * Dedicated socket to send data from the flag and test VM back to the driver VM. > 1042: */ > 1043: class TestFrameworkSocket { could you please move it to a separate .java file? test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 1043: > 1041: * Dedicated socket to send data from the flag and test VM back to the driver VM. > 1042: */ > 1043: class TestFrameworkSocket { I guess it should implement AutoClosable, and then you try-catch-finally in `TestFramework::start` could be replaced by `try-w-resource`. btw, I don't the fact that `socket` is a field of `TestFramework` with the lifetime bounded to `start` method. ------------- Changes requested by iignatyev (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3508 From iignatyev at openjdk.java.net Fri Apr 16 18:27:40 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Fri, 16 Apr 2021 18:27:40 GMT Subject: RFR: 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests [v2] In-Reply-To: References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> Message-ID: On Fri, 16 Apr 2021 01:48:49 GMT, Igor Ignatyev wrote: >> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: >> >> Adjust whitelist > > test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 639: > >> 637: TestFormat.check(!scenarioIndices.contains(scenarioIndex), >> 638: "Cannot define two scenarios with the same index " + scenarioIndex); >> 639: scenarioIndices.add(scenarioIndex); > > you can use `Set::add` to verify that the element isn't in a set: > Suggestion: > > TestFormat.check(scenarioIndices.add(scenarioIndex), > "Cannot define two scenarios with the same index " + scenarioIndex); also, shouldn't this check be done as part of `addScenarios`? ------------- PR: https://git.openjdk.java.net/jdk/pull/3508 From dholmes at openjdk.java.net Sun Apr 18 04:35:31 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Sun, 18 Apr 2021 04:35:31 GMT Subject: RFR: 8264372: Threads::destroy_vm only ever returns true [v2] In-Reply-To: References: Message-ID: > Trivial cleanup to remove the bool return from Threads::destroy_vm as it only ever returned true. > > Testing: tiers 1-3 > > Thanks, > David David Holmes has updated the pull request incrementally with one additional commit since the last revision: Adjusted comment ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3535/files - new: https://git.openjdk.java.net/jdk/pull/3535/files/778b233b..371c2d15 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3535&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3535&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3535.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3535/head:pull/3535 PR: https://git.openjdk.java.net/jdk/pull/3535 From dholmes at openjdk.java.net Sun Apr 18 04:35:33 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Sun, 18 Apr 2021 04:35:33 GMT Subject: RFR: 8264372: Threads::destroy_vm only ever returns true [v2] In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 15:02:56 GMT, Daniel D. Daugherty wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Adjusted comment > > Thumbs up! > > `// Don't bother changing state any more, VM is gone.` > > would be a better comment. Thanks @dcubed-ojdk and @shipilev , I adjusted the comment to read: // Don't bother restoring thread state, VM is gone. Integrating now. ------------- PR: https://git.openjdk.java.net/jdk/pull/3535 From dholmes at openjdk.java.net Sun Apr 18 04:35:35 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Sun, 18 Apr 2021 04:35:35 GMT Subject: Integrated: 8264372: Threads::destroy_vm only ever returns true In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 06:12:39 GMT, David Holmes wrote: > Trivial cleanup to remove the bool return from Threads::destroy_vm as it only ever returned true. > > Testing: tiers 1-3 > > Thanks, > David This pull request has now been integrated. Changeset: 1ac25b82 Author: David Holmes URL: https://git.openjdk.java.net/jdk/commit/1ac25b82 Stats: 15 lines in 3 files changed: 0 ins; 9 del; 6 mod 8264372: Threads::destroy_vm only ever returns true Reviewed-by: shade, dcubed ------------- PR: https://git.openjdk.java.net/jdk/pull/3535 From dnsimon at openjdk.java.net Sun Apr 18 11:53:11 2021 From: dnsimon at openjdk.java.net (Doug Simon) Date: Sun, 18 Apr 2021 11:53:11 GMT Subject: RFR: 8265403: consolidate definition of CPU features In-Reply-To: References: Message-ID: On Sat, 17 Apr 2021 20:18:31 GMT, Doug Simon wrote: > While porting [JDK-8224974](https://bugs.openjdk.java.net/browse/JDK-8224974) to Graal, I noticed that new CPU features were defined for x86 and AArch64 without being exposed via JVMCI. To avoid this problem in future, this PR updates x86 and AArch64 to define CPU features with a single macro that is used to generate enum declarations as well as vmstructs entries. > > In addition, the JVMCI API is updated to exposes the new CPU feature constants and now has a check that ensure these constants are in sync with the underlying macro definition. src/hotspot/cpu/aarch64/vm_version_aarch64.cpp line 198: > 196: sprintf(buf, "0x%02x:0x%x:0x%03x:%d", _cpu, _variant, _model, _revision); > 197: if (_model2) sprintf(buf+strlen(buf), "(0x%03x)", _model2); > 198: #define ADD_FEATURE_IF_SUPPORTED(id, name, bit) if (_features & CPU_##id) strcat(buf, ", " name); I'm not sure why only some of the supported AArch64 CPU features were being added to `_features_string` but I assume there's no harm in adding them all. src/hotspot/cpu/x86/vm_version_x86.hpp line 382: > 380: static const char* _features_names[]; > 381: > 382: // NB! When adding new CPU feature detection consider updating vmStructs_x86.hpp, vmStructs_jvmci.hpp, and VM_Version::get_processor_features(). No need for this comment any more as the derivative declarations are now automatically kept up to date. src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot.amd64/src/jdk/vm/ci/hotspot/amd64/AMD64HotSpotJVMCIBackendFactory.java line 57: > 55: > 56: Map constants = config.getStore().getConstants(); > 57: Function nameToFeature = name -> name.equals("3DNOW_PREFETCH") ? CPUFeature.AMD_3DNOW_PREFETCH : CPUFeature.valueOf(name); The `AMD_3DNOW_PREFETCH` enum constant has to keep its old name to preserve backward compatibility. ------------- PR: https://git.openjdk.java.net/jdk/pull/3558 From dnsimon at openjdk.java.net Sun Apr 18 11:53:10 2021 From: dnsimon at openjdk.java.net (Doug Simon) Date: Sun, 18 Apr 2021 11:53:10 GMT Subject: RFR: 8265403: consolidate definition of CPU features Message-ID: While porting [JDK-8224974](https://bugs.openjdk.java.net/browse/JDK-8224974) to Graal, I noticed that new CPU features were defined for x86 and AArch64 without being exposed via JVMCI. To avoid this problem in future, this PR updates x86 and AArch64 to define CPU features with a single macro that is used to generate enum declarations as well as vmstructs entries. In addition, the JVMCI API is updated to exposes the new CPU feature constants and now has a check that ensure these constants are in sync with the underlying macro definition. ------------- Commit messages: - 8265403: consolidate definition of CPU features Changes: https://git.openjdk.java.net/jdk/pull/3558/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3558&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265403 Stats: 481 lines in 15 files changed: 144 ins; 230 del; 107 mod Patch: https://git.openjdk.java.net/jdk/pull/3558.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3558/head:pull/3558 PR: https://git.openjdk.java.net/jdk/pull/3558 From sangheki at openjdk.java.net Sun Apr 18 23:21:35 2021 From: sangheki at openjdk.java.net (Sangheon Kim) Date: Sun, 18 Apr 2021 23:21:35 GMT Subject: RFR: 8249528: Remove obsolete comment in G1RootProcessor::process_java_roots In-Reply-To: <8XcBRc2-cEW3wZnNA67FoG8WEZATeNuT9uk2-MiGicg=.dec0b7c8-d3a2-4f5a-9f9e-870ede4d88e0@github.com> References: <8XcBRc2-cEW3wZnNA67FoG8WEZATeNuT9uk2-MiGicg=.dec0b7c8-d3a2-4f5a-9f9e-870ede4d88e0@github.com> Message-ID: <2vJMo1uORw0CQc_ne74Yz7mB-KA1JbCSCdBoVbRwVQI=.d635314a-adc8-4bbe-923f-493ee65296b0@github.com> On Tue, 6 Apr 2021 07:55:04 GMT, Albert Mingkun Yang wrote: > Updating the obsolete comment and some trivial change of removing dead code in related files. > ### Webrevs > > * 00: [Full](https://webrevs.openjdk.java.net/?repo=jdk&pr=3352&range=00) ([2c7a0894](https://git.openjdk.java.net/jdk/pull/3352/files/2c7a0894a575b158c67f8879cae1ac0c6cb2c299)) Looks good. ------------- PR: https://git.openjdk.java.net/jdk/pull/3352 From sangheki at openjdk.java.net Sun Apr 18 23:27:36 2021 From: sangheki at openjdk.java.net (Sangheon Kim) Date: Sun, 18 Apr 2021 23:27:36 GMT Subject: RFR: 8249528: Remove obsolete comment in G1RootProcessor::process_java_roots In-Reply-To: <8XcBRc2-cEW3wZnNA67FoG8WEZATeNuT9uk2-MiGicg=.dec0b7c8-d3a2-4f5a-9f9e-870ede4d88e0@github.com> References: <8XcBRc2-cEW3wZnNA67FoG8WEZATeNuT9uk2-MiGicg=.dec0b7c8-d3a2-4f5a-9f9e-870ede4d88e0@github.com> Message-ID: On Tue, 6 Apr 2021 07:55:04 GMT, Albert Mingkun Yang wrote: > Updating the obsolete comment and some trivial change of removing dead code in related files. Looks good. ------------- Marked as reviewed by sangheki (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3352 From dholmes at openjdk.java.net Mon Apr 19 01:55:36 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Mon, 19 Apr 2021 01:55:36 GMT Subject: RFR: 8263718: unused-result warning happens at os_linux.cpp In-Reply-To: References: <2LTmcTAinL0BQn5t5ltR32S3uyQ-bwjKF8xRQ71DXf0=.9e9c1a88-7daf-4360-9faa-844a8bd6f489@github.com> <0l5lZg45-QTxenQ0RtyrX2q7PCHaO9Tm3FwzSC_ALK0=.6a7ee9d2-6019-45f9-8ffd-8c706a17aa51@github.com> <2jyfuXZyygeYZAtIiwDCiGC1BKSi1Ga_sot9xmW9EAc=.a9c24bd5-262e-44c1-aa6b-4a7de331e431@github.com> <4FT5wC9-SYkH2FekmMKbKGfHOOUwfS8vUnP KEylN2fk=.c00769fc-b287-40d4-ad18-f3c738e4e483@github.com> Message-ID: On Fri, 19 Mar 2021 17:33:35 GMT, Thomas Stuefe wrote: >> I tried to build OpenJDK with g++-10.2.1_pre1-r3 on Alpine Linux 3.13.2, but I saw following warning: > > Writing to the *end* of the allocated area may do the trick. > > ..Thomas @tstuefe or @stefank are either of you prepared to be the second reviewer here? Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/3042 From yyang at openjdk.java.net Mon Apr 19 02:12:34 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Mon, 19 Apr 2021 02:12:34 GMT Subject: RFR: 8265323: Leftover local variables in PcDesc In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 08:08:14 GMT, Tobias Hartmann wrote: >> Leftover local variables in PcDesc. Remove it to save electric power. > > Marked as reviewed by thartmann (Reviewer). Thanks @TobiHartmann and @neliasso for the reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/3532 From stuefe at openjdk.java.net Mon Apr 19 05:15:35 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Mon, 19 Apr 2021 05:15:35 GMT Subject: RFR: 8263718: unused-result warning happens at os_linux.cpp [v3] In-Reply-To: References: Message-ID: On Tue, 30 Mar 2021 05:58:17 GMT, Yasumasa Suenaga wrote: >> I tried to build OpenJDK with g++-10.2.1_pre1-r3 on Alpine Linux 3.13.2, but I saw following warning: > > Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: > > Add comment This looks fine to me. Cheers, Thomas ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3042 From yyang at openjdk.java.net Mon Apr 19 06:29:35 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Mon, 19 Apr 2021 06:29:35 GMT Subject: Integrated: 8265323: Leftover local variables in PcDesc In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 03:16:30 GMT, Yi Yang wrote: > Leftover local variables in PcDesc. Remove it to save electric power. This pull request has now been integrated. Changeset: a2b0e0f4 Author: Yi Yang Committer: Tobias Hartmann URL: https://git.openjdk.java.net/jdk/commit/a2b0e0f4 Stats: 6 lines in 1 file changed: 0 ins; 5 del; 1 mod 8265323: Leftover local variables in PcDesc Reviewed-by: thartmann, neliasso ------------- PR: https://git.openjdk.java.net/jdk/pull/3532 From stefank at openjdk.java.net Mon Apr 19 07:04:41 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Mon, 19 Apr 2021 07:04:41 GMT Subject: RFR: 8265066: Split ReservedSpace constructor to avoid default parameter [v2] In-Reply-To: References: <3a8swSA9QPceAHBKF_8zz2_OBoRSsENZaO8sORs-idA=.676bbcca-d934-4f96-88e6-7a3c0809d55e@github.com> Message-ID: On Thu, 15 Apr 2021 09:24:50 GMT, Stefan Johansson wrote: >> Please review this change to change this constructor in ReservedSpace: >> >> // Initialize the reserved space with the given size. If preferred_page_size >> // is set, use this as minimum page size/alignment. This may waste some space >> // if the given size is not aligned to that value, as the reservation will be >> // aligned up to the final alignment in this case. >> ReservedSpace(size_t size, size_t preferred_page_size = 0); >> >> >> I propose to split this constructor into two instead of having the default parameter. This makes the implementation more straight forward. I also make the single argument constructor explicit to avoid implicit conversion. There was one place where we relied on implicit conversion and this has been updated to explicitly create the ReservedSpace. >> >> This cleanup is another step towards: >> [JDK-8261527: Record page size used for underlying mapping in ReservedSpace](https://bugs.openjdk.java.net/browse/JDK-8261527) > > Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision: > > Thomas review. > > Removed assert. Marked as reviewed by stefank (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3457 From ayang at openjdk.java.net Mon Apr 19 07:07:38 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Mon, 19 Apr 2021 07:07:38 GMT Subject: RFR: 8249528: Remove obsolete comment in G1RootProcessor::process_java_roots In-Reply-To: <8XcBRc2-cEW3wZnNA67FoG8WEZATeNuT9uk2-MiGicg=.dec0b7c8-d3a2-4f5a-9f9e-870ede4d88e0@github.com> References: <8XcBRc2-cEW3wZnNA67FoG8WEZATeNuT9uk2-MiGicg=.dec0b7c8-d3a2-4f5a-9f9e-870ede4d88e0@github.com> Message-ID: On Tue, 6 Apr 2021 07:55:04 GMT, Albert Mingkun Yang wrote: > Updating the obsolete comment and some trivial change of removing dead code in related files. Thanks for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/3352 From ayang at openjdk.java.net Mon Apr 19 07:07:38 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Mon, 19 Apr 2021 07:07:38 GMT Subject: Integrated: 8249528: Remove obsolete comment in G1RootProcessor::process_java_roots In-Reply-To: <8XcBRc2-cEW3wZnNA67FoG8WEZATeNuT9uk2-MiGicg=.dec0b7c8-d3a2-4f5a-9f9e-870ede4d88e0@github.com> References: <8XcBRc2-cEW3wZnNA67FoG8WEZATeNuT9uk2-MiGicg=.dec0b7c8-d3a2-4f5a-9f9e-870ede4d88e0@github.com> Message-ID: <6azd2xZDwryQhbSG_HDJ1qGOWDxTLmkZnc_iQCrmtLI=.d7f93b30-f94d-4e70-9ff4-c4b9a4012421@github.com> On Tue, 6 Apr 2021 07:55:04 GMT, Albert Mingkun Yang wrote: > Updating the obsolete comment and some trivial change of removing dead code in related files. This pull request has now been integrated. Changeset: c607d12e Author: Albert Mingkun Yang URL: https://git.openjdk.java.net/jdk/commit/c607d12e Stats: 42 lines in 5 files changed: 19 ins; 13 del; 10 mod 8249528: Remove obsolete comment in G1RootProcessor::process_java_roots Reviewed-by: tschatzl, sangheki ------------- PR: https://git.openjdk.java.net/jdk/pull/3352 From sjohanss at openjdk.java.net Mon Apr 19 07:11:38 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Mon, 19 Apr 2021 07:11:38 GMT Subject: RFR: 8265066: Split ReservedSpace constructor to avoid default parameter [v2] In-Reply-To: References: <3a8swSA9QPceAHBKF_8zz2_OBoRSsENZaO8sORs-idA=.676bbcca-d934-4f96-88e6-7a3c0809d55e@github.com> Message-ID: On Thu, 15 Apr 2021 10:04:05 GMT, Thomas Schatzl wrote: >> Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision: >> >> Thomas review. >> >> Removed assert. > > Lgtm. Thanks for the reviews @tschatzl and @stefank. ------------- PR: https://git.openjdk.java.net/jdk/pull/3457 From sjohanss at openjdk.java.net Mon Apr 19 07:11:38 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Mon, 19 Apr 2021 07:11:38 GMT Subject: Integrated: 8265066: Split ReservedSpace constructor to avoid default parameter In-Reply-To: <3a8swSA9QPceAHBKF_8zz2_OBoRSsENZaO8sORs-idA=.676bbcca-d934-4f96-88e6-7a3c0809d55e@github.com> References: <3a8swSA9QPceAHBKF_8zz2_OBoRSsENZaO8sORs-idA=.676bbcca-d934-4f96-88e6-7a3c0809d55e@github.com> Message-ID: On Tue, 13 Apr 2021 09:34:31 GMT, Stefan Johansson wrote: > Please review this change to change this constructor in ReservedSpace: > > // Initialize the reserved space with the given size. If preferred_page_size > // is set, use this as minimum page size/alignment. This may waste some space > // if the given size is not aligned to that value, as the reservation will be > // aligned up to the final alignment in this case. > ReservedSpace(size_t size, size_t preferred_page_size = 0); > > > I propose to split this constructor into two instead of having the default parameter. This makes the implementation more straight forward. I also make the single argument constructor explicit to avoid implicit conversion. There was one place where we relied on implicit conversion and this has been updated to explicitly create the ReservedSpace. > > This cleanup is another step towards: > [JDK-8261527: Record page size used for underlying mapping in ReservedSpace](https://bugs.openjdk.java.net/browse/JDK-8261527) This pull request has now been integrated. Changeset: e390e550 Author: Stefan Johansson URL: https://git.openjdk.java.net/jdk/commit/e390e550 Stats: 30 lines in 3 files changed: 12 ins; 4 del; 14 mod 8265066: Split ReservedSpace constructor to avoid default parameter Reviewed-by: tschatzl, stefank ------------- PR: https://git.openjdk.java.net/jdk/pull/3457 From dnsimon at openjdk.java.net Mon Apr 19 09:42:02 2021 From: dnsimon at openjdk.java.net (Doug Simon) Date: Mon, 19 Apr 2021 09:42:02 GMT Subject: RFR: 8265403: consolidate definition of CPU features [v2] In-Reply-To: References: Message-ID: <4M8_w76Ai_dnNI4LbRClcxhhBaJ7XVHpCeYr-p5ilZs=.01a7ad3a-2855-45f6-b2ad-d439bf282e50@github.com> > While porting [JDK-8224974](https://bugs.openjdk.java.net/browse/JDK-8224974) to Graal, I noticed that new CPU features were defined for x86 and AArch64 without being exposed via JVMCI. To avoid this problem in future, this PR updates x86 and AArch64 to define CPU features with a single macro that is used to generate enum declarations as well as vmstructs entries. > > In addition, the JVMCI API is updated to exposes the new CPU feature constants and now has a check that ensure these constants are in sync with the underlying macro definition. Doug Simon has updated the pull request incrementally with one additional commit since the last revision: avoid use of a lambda in JVMCI initialization ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3558/files - new: https://git.openjdk.java.net/jdk/pull/3558/files/b69675f4..bdf9eefb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3558&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3558&range=00-01 Stats: 23 lines in 3 files changed: 5 ins; 9 del; 9 mod Patch: https://git.openjdk.java.net/jdk/pull/3558.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3558/head:pull/3558 PR: https://git.openjdk.java.net/jdk/pull/3558 From dnsimon at openjdk.java.net Mon Apr 19 09:46:17 2021 From: dnsimon at openjdk.java.net (Doug Simon) Date: Mon, 19 Apr 2021 09:46:17 GMT Subject: RFR: 8265403: consolidate definition of CPU features [v3] In-Reply-To: References: Message-ID: > While porting [JDK-8224974](https://bugs.openjdk.java.net/browse/JDK-8224974) to Graal, I noticed that new CPU features were defined for x86 and AArch64 without being exposed via JVMCI. To avoid this problem in future, this PR updates x86 and AArch64 to define CPU features with a single macro that is used to generate enum declarations as well as vmstructs entries. > > In addition, the JVMCI API is updated to exposes the new CPU feature constants and now has a check that ensure these constants are in sync with the underlying macro definition. Doug Simon has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: avoid use of a lambda in JVMCI initialization ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3558/files - new: https://git.openjdk.java.net/jdk/pull/3558/files/bdf9eefb..124019d7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3558&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3558&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3558.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3558/head:pull/3558 PR: https://git.openjdk.java.net/jdk/pull/3558 From egahlin at openjdk.java.net Mon Apr 19 10:33:01 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Mon, 19 Apr 2021 10:33:01 GMT Subject: RFR: 8265036: JFR: Remove use of -XX:StartFlightRecording= and -XX:FlightRecorderOptions= Message-ID: Hi, Could I have a review of fix that removes the use of "=" together with -XX:StartFlightRecording and -XX:FlightRecorderOptions. It's been possible to use "-XX:StartFlightRecording:" and "-XX:FlightRecorderOption:" since JFR was introduced into OpenJDK (JDK 11), so this is not a change of the specification, just an update to make the use consistent in tests, comments, documentation etc. I also removed the use of -XX:+FlightRecorder, which is not needed, and has been deprecated since JDK 13. Testing: jdk/jdk/jfr, tier 1-4. Thanks Erik ------------- Commit messages: - Initial Changes: https://git.openjdk.java.net/jdk/pull/3561/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3561&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265036 Stats: 97 lines in 39 files changed: 0 ins; 0 del; 97 mod Patch: https://git.openjdk.java.net/jdk/pull/3561.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3561/head:pull/3561 PR: https://git.openjdk.java.net/jdk/pull/3561 From chagedorn at openjdk.java.net Mon Apr 19 12:49:39 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Mon, 19 Apr 2021 12:49:39 GMT Subject: RFR: 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests [v3] In-Reply-To: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> Message-ID: > This RFE provides an IR test framework to perform regex-based checks on the C2 IR shape of test methods emitted by the VM flags `-XX:+PrintIdeal` and `-XX:+PrintOptoAssembly`. The framework can also be used for other non-IR matching (and non-compiler) tests by providing easy to use annotations for commonly used testing patterns and compiler control flags. > > The framework is based on the ideas of the currently present IR test framework in [Valhalla](https://github.com/openjdk/valhalla/blob/e9c78ce4fcfd01361c35883e0d68f9ae5a80d079/test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypeTest.java) (mainly implemented by @TobiHartmann) which is being used with great success. This new framework aims to replace the old one in Valhalla at some point. > > A detailed description about how this new IR test framework works and how it is used is provided in the [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) file and in the [Javadocs](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc/jdk/test/lib/hotspot/ir_framework/package-summary.html) written for the framework classes. > > To finish a first version of this framework for JDK 17, I decided to leave some improvement possibilities and ideas to be followed up on in additional RFEs. Some ideas are mentioned in "Future Work" in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) and were also created as subtasks of this RFE. > > Testing (also described in "Internal Framework Tests in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md)): > There are various tests to verify the correctness of the test framework which can be found as JTreg tests in the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) folder. Additional testing was performed by converting all compiler Inline Types test of project Valhalla (done by @katyapav in [JDK-8263024](https://bugs.openjdk.java.net/browse/JDK-8263024)) that used the old framework to the new framework. This provided additional testing for the framework itself. We ran the converted tests with all the flag settings used in hs-tier1-9 and hs-precheckin-comp. For sanity checking, this was also done with a sample IR test in mainline. > > Some stats about the framework code added to [ir_framework](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework): > > - without the [Javadocs files](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc) : 60 changed files, 13212 insertions, 0 deletions. > - without the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) and [examples](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/examples) folder: 40 files changed, 6781 insertions > - comments: 2399 insertions (calculated with `git diff --cached !(tests|examples) | grep -c -E "(^[+-]\s*(/)?*)|(^[+-]\s*//)"`) > - which leaves 4382 lines of code inserted > > Big thanks to: > - @TobiHartmann for all his help by discussing the new framework and for providing insights from his IR test framework in Valhalla. > - @katyapav for converting the Valhalla tests to use the new framework which found some harder to catch bugs in the framework and also some actual C2 bugs. > - @iignatev for helping to simplify the framework usage with JTreg and with the framework internal VM calling structure. > - and others who provided valuable feedback. > > Thanks, > Christian Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: Apply review comments in code from Igor I. and Vladimir K. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3508/files - new: https://git.openjdk.java.net/jdk/pull/3508/files/7ed789dc..b3f58111 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3508&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3508&range=01-02 Stats: 807 lines in 10 files changed: 433 ins; 321 del; 53 mod Patch: https://git.openjdk.java.net/jdk/pull/3508.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3508/head:pull/3508 PR: https://git.openjdk.java.net/jdk/pull/3508 From chagedorn at openjdk.java.net Mon Apr 19 12:49:46 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Mon, 19 Apr 2021 12:49:46 GMT Subject: RFR: 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests [v2] In-Reply-To: References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> Message-ID: On Fri, 16 Apr 2021 17:41:08 GMT, Igor Ignatyev wrote: >> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: >> >> Adjust whitelist > > test/lib/jdk/test/lib/hotspot/ir_framework/AbstractInfo.java line 57: > >> 55: * @return an inverted boolean of the result of the last invocation of this method. >> 56: */ >> 57: public boolean toggleBoolean() { > > I don't think `toggleBoolean` really belongs to `AbstractInfo`, I'd rather move it into a (separate) aux class. The problem with having a separate class for it is that we would need to create a new instance somehow in a test and store it in a field to access it in subsequent iterations of a test. On the other hand, one could argue that we do not really need to guarantee that the first invocation of `toggleBoolean()` always returns `false` as the common use-case of this method is just to execute some if-else paths (roughly) equally often (regardless with which one we start) . Then we could also just move the method to `TestFramework::toggleBoolean()` with a static boolean field. We are always only executing a single test at a time, so `toggleBoolean()` reliably returns a different boolean each time it is called in a single test. What do you think? > test/lib/jdk/test/lib/hotspot/ir_framework/IRMatcher.java line 47: > >> 45: >> 46: public IRMatcher(String hotspotPidFileName, String irEncoding, Class testClass) { >> 47: this.compilations = new LinkedHashMap<>(); > > why do we use LinkedHashMap here (as opposed to HashMap)? I haven't found the place where you need to traverse it in the insertion order. I think you're right. I first had the linked hash map to keep some sort of ordering for the reported IR rule failures. But in the current version, the compilations would only be sorted by type of test which probably does not add much benefit. I changed it back to `HashMap`. > test/lib/jdk/test/lib/hotspot/ir_framework/IRMatcher.java line 116: > >> 114: private void parseHotspotPidFile() { >> 115: Map compileIdMap = new HashMap<>(); >> 116: try (BufferedReader br = new BufferedReader(new FileReader(new File(System.getProperty("user.dir") + File.separator + hotspotPidFileName)))) { > > more idiomatic/modern version would be > Suggestion: > > try (BufferedReader br = Files.newBufferedReader(Paths.get(System.getProperty("user.dir"), hotspotPidFileName))) { > > > I actually not sure if you really need `$user.dir`, won't hotspot_pid file get generated in the current dir? Yes it should. Would this be equivalent to `Paths.get("")`? It seems to work like that. > test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 107: > >> 105: */ >> 106: public static final Set JTREG_WHITELIST_FLAGS = new HashSet<>( >> 107: Arrays.asList( > > it doesn't seem to be a comprehensive list of flags that don't affect IR verification work, e.g. different GCs. I think it might be easy to go with the blacklist instead, and possibly warning people if there are any flags in `test.*.opts`. Maybe first some general background about having a whitelist/blacklist in the first place. When a user writes an `@IR` rule, we do not want him to think about any possible VM flag combination (which he is not specifically using in his test, for example with `addFlags`) that could break his `@IR` rule and then requiring him to restrict the `@IR` rule with `IR::applyIfXX()` for these flags. I agree that the whitelist is probably not complete and could be improved (but I think we should not whitelist different GCs as these affect the barrier code of the IR). About whitelist vs. blacklist, I had discussions about it with @TobiHartmann. We eventually decided to use a whitelist which seemed easier to maintain and is probably a lot shorter than a blacklist. In addition, if a new flag is introduced or removed, we most likely do not need to worry about updating the whitelist as the (currently) whitelisted flags will most likely remain unchanged. This first whitelist version is also just a best guess solution. We might miss on some other flags that will not affect the IR but we have the confidence that we do not run into surprising failures due to forgetting to blacklist a particular flag. But this is open for discussion of course. It would be interesting to hear how people think about it. > test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 146: > >> 144: private List> helperClasses = null; >> 145: private List scenarios = null; >> 146: private final List flags = new ArrayList<>(); > > why did you decide to eagerly create list for `flags`, but not for `scenarios` / `helpersClasses`? Good catch. I adapted it to also create it lazily. > test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 166: > >> 164: if (VERBOSE) { >> 165: System.out.println("Test class: " + testClass); >> 166: } > > this c-tor can be replaced by: > Suggestion: > > this(StackWalker.getInstance(StackWalker.Option.RETAIN_CLASS_REFERENCE).getCallerClass()); > > > and actually, I don't see it being used (outside of the tests for this testlibrary) and I don't think it will ever be used by actual tests that would use this framework, so I think we can safely remove it. I think we should keep it for the cases when a user wants a more specific setup for his tests in the calling test class. For example, if he wants to define a new default warm-up for all of his tests (using `setDefaultWarmup`) or if he needs to combine different options for which there is no `runXX` method (helper classes, scenarios, and/or flags). In this case, he needs to create a `TestFramework()` builder and then call the different builder methods. We could argue that a single constructor is enough in which the test class needs to be specified. But I think most of the time, the user wants to test the calling class for which this additional constructor is quite useful. > test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 211: > >> 209: } >> 210: >> 211: /** > > I'm not sure how much of the benefits all these different `run.*` bring. I fully understand the desire to simplify the most common use-case (i.e. no-arg `run`), but for the rest I'd assume the users will be capable of writing, for example, `new TestFramework(testClass).addScenarios(scenarios).start();` instead of `TestFramework .runWithScenarios(testClass, scenarios);` I think you are probably right. I added this builder approach later during the development of the framework. It might be better to keep the `TestFramework` interface simple(r). However, I will wait for others to comment on that before changing/removing all of these. If we're gonna simplify it, I suggest to keep `run()` and maybe also `runWithFlags()` as (probably?) most common use-case. > test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 269: > >> 267: *
      >> 268: *

    • If a helper class is not in the same file as the test class, make sure that JTreg compiles it by using >> 269: * {@literal @}compile in the JTreg header comment block.

      • > > you don't need `@compile` to compile a helper class, 1st of all, you shouldn't use `@compile` when you want to compile a class in your test, you should use `@build`, 2nd, in this particular case, the class will be automatically built as part of your test b/c jtreg (or rather javac) will be able to statically detect it as a dependency of the code that calls `runWithHelperClasses(Class, Class...)` Okay, thanks for clearing that up! I removed that comment and related ones. > test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 407: > >> 405: start(null); >> 406: } catch (TestVMException e) { >> 407: System.err.println("\n" + e.getExceptionInfo()); > > you shouldn't use "\n", as it might not be the right line-separator. you can either do: > Suggestion: > > System.err.println(); > System.err.println(e.getExceptionInfo()); > > or > Suggestion: > > System.err.printf("%n%s%n", e.getExceptionInfo()); I will address all `\n` in a separate commit as there are a lot of them. Could I also just use `System.lineSeparator()` anywhere where I'm currently using `\n` like `System.err.println(System.lineSeparator() + e.getExceptionInfo()`)? Might be easier when I'm using `\n` with a `StringBuilder`, for example. > test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 674: > >> 672: + "Compilation(s) of failed matche(s):"); >> 673: System.out.println(irException.getCompilations()); >> 674: builder.append(errorMsg).append("\n").append(irException.getExceptionInfo()).append(e.getMessage()); > > as `builder.toString` will be printed out to cout/cerr, you should use platform-specific line-separator instead of `\n` See earlier comment. > test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 804: > >> 802: System.err.println("--- OUTPUT TestFramework flag VM ---"); >> 803: System.err.println(flagVMOutput); >> 804: throw new RuntimeException("\nTestFramework flag VM exited with " + exitCode); > > what's the reason for `\n` in the begging of this exception message? I guess it's not necessary. Removed it. > test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 958: > >> 956: throw new TestFrameworkException("Internal Test Framework exception - please file a bug:\n" + failureMessage, e); >> 957: } >> 958: } > > I am not convinced that we really these guys when we already have `TestFormat::check` and `TestRun::check` (I'm actually not 100% convinced that we need check/fail in both TestFormat and TestRun) I wanted to distinguish the following cases (but I'm open to use a different approach): - `TestFormat::check` (using `TestFormatException`): The format of any test/helper class does not conform with the format the framework is expecting. The user needs to fix this (for example, using a wrong annotation). I report these kind of failures before actually running any of the tests [here](https://github.com/openjdk/jdk/blob/7ed789dc98691d7c7fc2295e045a9f54b9fa6277/test/lib/jdk/test/lib/hotspot/ir_framework/TestFrameworkExecution.java#L265). - `TestRun::check` (using `TestRunException`): Thrown while the framework is [executing a test](https://github.com/openjdk/jdk/blob/7ed789dc98691d7c7fc2295e045a9f54b9fa6277/test/lib/jdk/test/lib/hotspot/ir_framework/TestFrameworkExecution.java#L799), there is nothing wrong with the format of a test. - `TestFramework::check` (using `TestFrameworkException`): If such a check fails there is a bug in the framework itself (like internal framework assertions). The user cannot really do anything about it without fixing the framework itself. I have to double check again if I'm using the right kind of exception everywhere. > test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 1027: > >> 1025: } >> 1026: >> 1027: public static String getRerunHint() { > > why is this a method and not just a public final static String? Fixed. > test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 1043: > >> 1041: * Dedicated socket to send data from the flag and test VM back to the driver VM. >> 1042: */ >> 1043: class TestFrameworkSocket { > > I guess it should implement AutoClosable, and then you try-catch-finally in `TestFramework::start` could be replaced by `try-w-resource`. > > btw, I don't the fact that `socket` is a field of `TestFramework` with the lifetime bounded to `start` method. +1 for `AutoClosable`. I wanted to avoid passing the socket object to all the different methods and thus tried to use the `socket` field like that. I agree that this not nice. Is delegating the socket object from `TestFramework::start` to the different methods the only solution or are there any other recommended ways? ------------- PR: https://git.openjdk.java.net/jdk/pull/3508 From chagedorn at openjdk.java.net Mon Apr 19 12:49:40 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Mon, 19 Apr 2021 12:49:40 GMT Subject: RFR: 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests [v2] In-Reply-To: References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> Message-ID: On Thu, 15 Apr 2021 13:19:56 GMT, Christian Hagedorn wrote: >> This RFE provides an IR test framework to perform regex-based checks on the C2 IR shape of test methods emitted by the VM flags `-XX:+PrintIdeal` and `-XX:+PrintOptoAssembly`. The framework can also be used for other non-IR matching (and non-compiler) tests by providing easy to use annotations for commonly used testing patterns and compiler control flags. >> >> The framework is based on the ideas of the currently present IR test framework in [Valhalla](https://github.com/openjdk/valhalla/blob/e9c78ce4fcfd01361c35883e0d68f9ae5a80d079/test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypeTest.java) (mainly implemented by @TobiHartmann) which is being used with great success. This new framework aims to replace the old one in Valhalla at some point. >> >> A detailed description about how this new IR test framework works and how it is used is provided in the [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) file and in the [Javadocs](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc/jdk/test/lib/hotspot/ir_framework/package-summary.html) written for the framework classes. >> >> To finish a first version of this framework for JDK 17, I decided to leave some improvement possibilities and ideas to be followed up on in additional RFEs. Some ideas are mentioned in "Future Work" in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) and were also created as subtasks of this RFE. >> >> Testing (also described in "Internal Framework Tests in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md)): >> There are various tests to verify the correctness of the test framework which can be found as JTreg tests in the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) folder. Additional testing was performed by converting all compiler Inline Types test of project Valhalla (done by @katyapav in [JDK-8263024](https://bugs.openjdk.java.net/browse/JDK-8263024)) that used the old framework to the new framework. This provided additional testing for the framework itself. We ran the converted tests with all the flag settings used in hs-tier1-9 and hs-precheckin-comp. For sanity checking, this was also done with a sample IR test in mainline. >> >> Some stats about the framework code added to [ir_framework](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework): >> >> - without the [Javadocs files](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc) : 60 changed files, 13212 insertions, 0 deletions. >> - without the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) and [examples](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/examples) folder: 40 files changed, 6781 insertions >> - comments: 2399 insertions (calculated with `git diff --cached !(tests|examples) | grep -c -E "(^[+-]\s*(/)?*)|(^[+-]\s*//)"`) >> - which leaves 4382 lines of code inserted >> >> Big thanks to: >> - @TobiHartmann for all his help by discussing the new framework and for providing insights from his IR test framework in Valhalla. >> - @katyapav for converting the Valhalla tests to use the new framework which found some harder to catch bugs in the framework and also some actual C2 bugs. >> - @iignatev for helping to simplify the framework usage with JTreg and with the framework internal VM calling structure. >> - and others who provided valuable feedback. >> >> Thanks, >> Christian > > Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: > > Adjust whitelist Thanks a lot to @iignatev for your careful review and also to @vnkozlov! I will update this PR incrementally regarding the different review comments. I'll start with handling the comments directly in the code. I waited with some of the changes if there is still something open for discussion/follow-up. ------------- PR: https://git.openjdk.java.net/jdk/pull/3508 From chagedorn at openjdk.java.net Mon Apr 19 12:49:48 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Mon, 19 Apr 2021 12:49:48 GMT Subject: RFR: 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests [v2] In-Reply-To: References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> Message-ID: On Thu, 15 Apr 2021 19:02:44 GMT, Doug Simon wrote: >> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: >> >> Adjust whitelist > > test/lib/jdk/test/lib/hotspot/ir_framework/README.html line 1: > >> 1:

      IR Test Framework

      > > Just curious: why HTML instead of markdown? There is also a `README.md` file in the same folder from which I generated this HTML file from. But as others have suggested, I will remove this html file again and only leave the markdown file. ------------- PR: https://git.openjdk.java.net/jdk/pull/3508 From chagedorn at openjdk.java.net Mon Apr 19 12:49:47 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Mon, 19 Apr 2021 12:49:47 GMT Subject: RFR: 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests [v2] In-Reply-To: References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> Message-ID: On Thu, 15 Apr 2021 17:08:07 GMT, Vladimir Kozlov wrote: >> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: >> >> Adjust whitelist > > test/lib/jdk/test/lib/hotspot/ir_framework/CompLevel.java line 62: > >> 60: *
    >> 61: */ >> 62: ANY(-2), > > This will change (`-2` -> `-1`) after AOT is removed (8264805). I'll change that as soon as it is integrated. > test/lib/jdk/test/lib/hotspot/ir_framework/CompLevel.java line 63: > >> 61: */ >> 62: ANY(-2), >> 63: /** > > For completeness may be add value `NONE(0)` for Interpreter only case. I agree that it makes sense for completeness. But I'm not sure if this is useful to have as `NONE` would not be supported by the framework for the time being and would just require additional handling, informing the user that this has no effect. ------------- PR: https://git.openjdk.java.net/jdk/pull/3508 From chagedorn at openjdk.java.net Mon Apr 19 12:49:48 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Mon, 19 Apr 2021 12:49:48 GMT Subject: RFR: 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests [v2] In-Reply-To: References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> Message-ID: On Fri, 16 Apr 2021 01:10:07 GMT, Igor Ignatyev wrote: >> test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 367: >> >>> 365: >>> 366: for (Class helperClass : helperClasses) { >>> 367: TestRun.check(!this.helperClasses.contains(helperClass), "Cannot add the same class twice: " + helperClass); >> >> won't it be easy to use `Set` to store `helperClasses`? > > you might also want to update javadoc for this method to state that there can be duplicates. Have I understood this correctly that you suggest to just remove this check completely and just specifying in the Javadocs that duplicates are ignore (due to using a `Set`)? >> test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 639: >> >>> 637: TestFormat.check(!scenarioIndices.contains(scenarioIndex), >>> 638: "Cannot define two scenarios with the same index " + scenarioIndex); >>> 639: scenarioIndices.add(scenarioIndex); >> >> you can use `Set::add` to verify that the element isn't in a set: >> Suggestion: >> >> TestFormat.check(scenarioIndices.add(scenarioIndex), >> "Cannot define two scenarios with the same index " + scenarioIndex); > > also, shouldn't this check be done as part of `addScenarios`? Right, I moved it to `addScenarios`. ------------- PR: https://git.openjdk.java.net/jdk/pull/3508 From chagedorn at openjdk.java.net Mon Apr 19 12:52:38 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Mon, 19 Apr 2021 12:52:38 GMT Subject: RFR: 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests [v2] In-Reply-To: References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> Message-ID: On Thu, 15 Apr 2021 17:49:34 GMT, Igor Ignatyev wrote: > * although having javadoc for testlibraries is highly desirable, I don't think we should check in the generated HTML files > * the same goes for `README.html` generated from `README.md` Okay, I will remove them. Does it make sense to still have the HTML files somewhere in the web, for example, on my cr.openjdk? > * this library is hotspot-centric, I highly doubt that it will be used by any tests outside of the hotspot test base, hence the more appropriate location for it would be inside `test/hotspot/jtreg/testlibrary`. > * I assume `test/lib/jdk/test/lib/hotspot/ir_framework/tests/` are the tests for the framework, in that case they should be in `test/lib-test`, if we stick to `test/lib` as the location for the library, or in `test/hotspot/jtreg/testlibrary_tests`, if we move it to `test/hotspot` That makes sense to move everything to `test/hotspot/jtreg/testlibrary`. Right, the `test/lib/jdk/test/lib/hotspot/ir_framework/tests/` are only tests for the framework itself and should not be run as part of tier testing each time (does not make much sense) but only when the framework is actually modified. Is this still the case when putting them in `test/hotspot/jtreg/testlibrary_tests` (i.e. not executed unless run manually)? I will do this things in a separate commit and adjust the README.md file accordingly (has links to the Javadoc files). ------------- PR: https://git.openjdk.java.net/jdk/pull/3508 From sjohanss at openjdk.java.net Mon Apr 19 14:28:56 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Mon, 19 Apr 2021 14:28:56 GMT Subject: RFR: 8265268: Unify ReservedSpace reservation code in initialize and try_reserve_heap Message-ID: Please review this change to unify the reservation code in ReservedSpace. **Summary** The code in `ReservedSpace::initialize(...)` and `ReservedHeapSpace::try_reserve_heap(...)` is very similar and more or less does the same things. The difference between them is logging, what is considered a failure and how that is handled. This change introduces a new function `ReservedSpace::reserve(...)` that is used by both `initialize(...)` and `try_reserve_heap(...)`. The biggest reason for only having one function handling the reservations is to avoid code duplication and having to change two places when something needs to be updated. There will be some small changes in what is getting logged in some cases, but the goal is to avoid changing behavior as much as possible. Some additional notes to help reviewing: * There are two reservation helpers: `reserve_memory()` for regular pages and file backed mappings. `reserve_memory_special()` for explicit large pages. * In `reserve_memory()` the `is_align()`-check at the end was previously done at the end of `initialize()`. It was moved here because this is the only case where an unaligned address can be returned. For large pages as well as when a requested address is provided, the returned address will be aligned. * The support to have a backing file is only used by the heap when `AllocateHeapAt` is set. If this option is used together with `UseLargePages` a debug message is printed since it is up to the backing file system if large pages are used or not. This output has been unified and is now printed when the file is created rather then deep in the reservation code. Previously this message differed depending on if `UseCompressedOops` was enabled or not. Now the same message is printed for both cases. * The failure checking function `failed_to_reserve_as_requested(...)` now only checks if the memory was allocated at the expected address. Releasing the memory is done by the caller. * The size passed into `map_or_reserve_memory_aligned` was previously aligned up using the alignment, but the size should always be aligned already. An assert has been added to the start of the `reserve` function and the `align_up` has been removed. **Testing** A lot of local testing as well as tier1-tier5 in Mach5. ------------- Commit messages: - 8265268: Unify ReservedSpace reservation code in initialize and try_reserve_heap Changes: https://git.openjdk.java.net/jdk/pull/3570/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3570&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265268 Stats: 273 lines in 2 files changed: 117 ins; 142 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/3570.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3570/head:pull/3570 PR: https://git.openjdk.java.net/jdk/pull/3570 From iignatyev at openjdk.java.net Mon Apr 19 15:30:40 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Mon, 19 Apr 2021 15:30:40 GMT Subject: RFR: 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests [v2] In-Reply-To: References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> Message-ID: On Thu, 15 Apr 2021 13:19:56 GMT, Christian Hagedorn wrote: >> This RFE provides an IR test framework to perform regex-based checks on the C2 IR shape of test methods emitted by the VM flags `-XX:+PrintIdeal` and `-XX:+PrintOptoAssembly`. The framework can also be used for other non-IR matching (and non-compiler) tests by providing easy to use annotations for commonly used testing patterns and compiler control flags. >> >> The framework is based on the ideas of the currently present IR test framework in [Valhalla](https://github.com/openjdk/valhalla/blob/e9c78ce4fcfd01361c35883e0d68f9ae5a80d079/test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypeTest.java) (mainly implemented by @TobiHartmann) which is being used with great success. This new framework aims to replace the old one in Valhalla at some point. >> >> A detailed description about how this new IR test framework works and how it is used is provided in the [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) file and in the [Javadocs](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc/jdk/test/lib/hotspot/ir_framework/package-summary.html) written for the framework classes. >> >> To finish a first version of this framework for JDK 17, I decided to leave some improvement possibilities and ideas to be followed up on in additional RFEs. Some ideas are mentioned in "Future Work" in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) and were also created as subtasks of this RFE. >> >> Testing (also described in "Internal Framework Tests in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md)): >> There are various tests to verify the correctness of the test framework which can be found as JTreg tests in the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) folder. Additional testing was performed by converting all compiler Inline Types test of project Valhalla (done by @katyapav in [JDK-8263024](https://bugs.openjdk.java.net/browse/JDK-8263024)) that used the old framework to the new framework. This provided additional testing for the framework itself. We ran the converted tests with all the flag settings used in hs-tier1-9 and hs-precheckin-comp. For sanity checking, this was also done with a sample IR test in mainline. >> >> Some stats about the framework code added to [ir_framework](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework): >> >> - without the [Javadocs files](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc) : 60 changed files, 13212 insertions, 0 deletions. >> - without the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) and [examples](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/examples) folder: 40 files changed, 6781 insertions >> - comments: 2399 insertions (calculated with `git diff --cached !(tests|examples) | grep -c -E "(^[+-]\s*(/)?*)|(^[+-]\s*//)"`) >> - which leaves 4382 lines of code inserted >> >> Big thanks to: >> - @TobiHartmann for all his help by discussing the new framework and for providing insights from his IR test framework in Valhalla. >> - @katyapav for converting the Valhalla tests to use the new framework which found some harder to catch bugs in the framework and also some actual C2 bugs. >> - @iignatev for helping to simplify the framework usage with JTreg and with the framework internal VM calling structure. >> - and others who provided valuable feedback. >> >> Thanks, >> Christian > > Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: > > Adjust whitelist @chhagedorn , I haven't finished reviewing the patch, but I figure it would be better to re-review the patch after you address the prev comments, so I will post the few pending comments I had and will return to review the whole patch after we finish discussing prev. comments. Cheers, -- Igor test/lib/jdk/test/lib/hotspot/ir_framework/IRMatcher.java line 182: > 180: private static void appendLine(StringBuilder builder, String line) { > 181: if (line.contains("&")) { > 182: line = line.replace("&", "&"); although I doubt it will ever be a problem in our use case, yet to be safe this replacement should be the last one, otherwise `&lt;` will become `<` while it should be `<` test/lib/jdk/test/lib/hotspot/ir_framework/IRMatcher.java line 349: > 347: if (matchCount > 0) { > 348: matcher.reset(); > 349: failMsg.append(" Regex ").append(nodeId).append(") ").append(nodeRegex).append("\n"); it seems you missed an opening parenthesis after `Regex ` . test/lib/jdk/test/lib/hotspot/ir_framework/IRMatcher.java line 516: > 514: */ > 515: public void appendIdealOutput(String idealOutput) { > 516: outputBuilder.setLength(0); I doubt that a method named `append.*` should remove the previous values. ------------- PR: https://git.openjdk.java.net/jdk/pull/3508 From iignatyev at openjdk.java.net Mon Apr 19 15:37:36 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Mon, 19 Apr 2021 15:37:36 GMT Subject: RFR: 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests [v2] In-Reply-To: References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> Message-ID: On Mon, 19 Apr 2021 12:48:26 GMT, Christian Hagedorn wrote: > > * although having javadoc for testlibraries is highly desirable, I don't think we should check in the generated HTML files > > * the same goes for `README.html` generated from `README.md` > > Okay, I will remove them. Does it make sense to still have the HTML files somewhere in the web, for example, on my cr.openjdk? > > > * this library is hotspot-centric, I highly doubt that it will be used by any tests outside of the hotspot test base, hence the more appropriate location for it would be inside `test/hotspot/jtreg/testlibrary`. > > * I assume `test/lib/jdk/test/lib/hotspot/ir_framework/tests/` are the tests for the framework, in that case they should be in `test/lib-test`, if we stick to `test/lib` as the location for the library, or in `test/hotspot/jtreg/testlibrary_tests`, if we move it to `test/hotspot` > > That makes sense to move everything to `test/hotspot/jtreg/testlibrary`. Right, the `test/lib/jdk/test/lib/hotspot/ir_framework/tests/` are only tests for the framework itself and should not be run as part of tier testing each time (does not make much sense) but only when the framework is actually modified. Is this still the case when putting them in `test/hotspot/jtreg/testlibrary_tests` (i.e. not executed unless run manually)? `test/hotspot/jtreg/testlibrary_tests` are seldomly run as part of `:hotspot_misc` test group, yet I don't think it's an issue. the benefit of running testlibrary tests is to gain confidence that the tests which use these libraries are reliable. I'd also disagree that `ir_framework/tests` should be run *only* when the framework is actually, they should also be run when its dependencies are changed, and the framework highly depends on hotspot, so to be sure that the framework didn't get broken after changes in c2, whitebox, etc, you do need run these tests more often. Thanks, -- Igor ------------- PR: https://git.openjdk.java.net/jdk/pull/3508 From iignatyev at openjdk.java.net Mon Apr 19 17:03:38 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Mon, 19 Apr 2021 17:03:38 GMT Subject: RFR: 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests [v2] In-Reply-To: References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> Message-ID: On Mon, 19 Apr 2021 11:11:40 GMT, Christian Hagedorn wrote: >> test/lib/jdk/test/lib/hotspot/ir_framework/AbstractInfo.java line 57: >> >>> 55: * @return an inverted boolean of the result of the last invocation of this method. >>> 56: */ >>> 57: public boolean toggleBoolean() { >> >> I don't think `toggleBoolean` really belongs to `AbstractInfo`, I'd rather move it into a (separate) aux class. > > The problem with having a separate class for it is that we would need to create a new instance somehow in a test and store it in a field to access it in subsequent iterations of a test. On the other hand, one could argue that we do not really need to guarantee that the first invocation of `toggleBoolean()` always returns `false` as the common use-case of this method is just to execute some if-else paths (roughly) equally often (regardless with which one we start) . Then we could also just move the method to `TestFramework::toggleBoolean()` with a static boolean field. We are always only executing a single test at a time, so `toggleBoolean()` reliably returns a different boolean each time it is called in a single test. What do you think? `TestFramework::toggleBoolean()` sounds like a good alternative. >> test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 107: >> >>> 105: */ >>> 106: public static final Set JTREG_WHITELIST_FLAGS = new HashSet<>( >>> 107: Arrays.asList( >> >> it doesn't seem to be a comprehensive list of flags that don't affect IR verification work, e.g. different GCs. I think it might be easy to go with the blacklist instead, and possibly warning people if there are any flags in `test.*.opts`. > > Maybe first some general background about having a whitelist/blacklist in the first place. When a user writes an `@IR` rule, we do not want him to think about any possible VM flag combination (which he is not specifically using in his test, for example with `addFlags`) that could break his `@IR` rule and then requiring him to restrict the `@IR` rule with `IR::applyIfXX()` for these flags. > > I agree that the whitelist is probably not complete and could be improved (but I think we should not whitelist different GCs as these affect the barrier code of the IR). About whitelist vs. blacklist, I had discussions about it with @TobiHartmann. We eventually decided to use a whitelist which seemed easier to maintain and is probably a lot shorter than a blacklist. In addition, if a new flag is introduced or removed, we most likely do not need to worry about updating the whitelist as the (currently) whitelisted flags will most likely remain unchanged. This first whitelist version is also just a best guess solution. We might miss on some other flags that will not affect the IR but we have the confidence that we do not run into surprising failures due to forgetting to blacklist a particular flag. But this is open for discussion of course. It would be interesting to hear how people think about it. I'll need to think about it a bit more, but my first impression after reading your comment is that we don't actually want to allow any flags, so we might better off just using `@requies vm.flagless` or reusing the underlying code to check that we don't have any flags that can "significantly" change behavior. > But I think most of the time, the user wants to test the calling class for which this additional constructor is quite useful. I concur that in most cases the users would want to use the caller as a `testClass`, yet we already have `run` and friends to cover that (most common) use-case, users who would need to construct fancier `TestFramework`, most probably, won't be doing it in their `testClass`, and if they would, the overhead of writing `new TestFramework(getClass())` is just 10 keystrokes and is neglatible (given the assumption of a more complicated use case) ------------- PR: https://git.openjdk.java.net/jdk/pull/3508 From iignatyev at openjdk.java.net Mon Apr 19 17:03:38 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Mon, 19 Apr 2021 17:03:38 GMT Subject: RFR: 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests [v2] In-Reply-To: References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> Message-ID: On Fri, 16 Apr 2021 02:14:35 GMT, Igor Ignatyev wrote: >> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: >> >> Adjust whitelist > > test/lib/jdk/test/lib/hotspot/ir_framework/AbstractInfo.java line 41: > >> 39: */ >> 40: abstract public class AbstractInfo { >> 41: private static final Random random = new Random(); > > you shouldn't use Random w/o predefined seed as it might make it harder to reproduce, please consider using `jdk.test.lib.Utils.getRandomInstance` or `jdk.test.lib.RandomFactory.getRandom` here I've also noticed that you use `Collections::shuffle` in `TestFrameworkExecution` w/o passing a reproducible rng. ------------- PR: https://git.openjdk.java.net/jdk/pull/3508 From ioi.lam at oracle.com Mon Apr 19 17:26:59 2021 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 19 Apr 2021 10:26:59 -0700 Subject: [EXTERNAL] Request For Comment: Asynchronous Logging In-Reply-To: <2170bebc-e5a2-219c-0a4b-f41623098c43@amazon.com> References: <7FEF3035-8926-467C-AD7B-A001A9C8FD5B@amazon.com> <2170bebc-e5a2-219c-0a4b-f41623098c43@amazon.com> Message-ID: On 4/13/21 3:12 PM, Liu, Xin wrote: > Hi, Thomas, > > I am still working on this feature. I have tabulated the requests from > reviewers. I draw a line of "consensus" and working on them one by one. > > ------------------------------------------------------------- > | request | Status | > ------------------------------------------------------------- > | independent NonJavaThread | done [1] | > |-----------------------------------------------------------| > | pass tier1-test with +AsyncLogging |JDK-8265102 | > |-----------------------------------------------------------<- progress > | inject meta-info to display no. of dropping msg. |WIP | > |-----------------------------------------------------------| > | preserve accurate decorations | | > |-----------------------------------------------------------| > | hoist async_mode to base class for stdout/err| [2] | > |-----------------------------------------------------------| > | CSR |JDK-8264323 | > |-----------------------------------------------------------<- consensus > |use string table over malloc | | > ------------------------------------------------------------| > |use lock-free data structure. | | > ------------------------------------------------------------- > > > I would like to mark items below consensus "improvement" and leave them > in separated JBS. I discussed about lock-free algorithms with Robbin on > github. He agree to defer it[3]. I don't like strdup either, but I > don't think it would hurt performance a lot. David Holmes comments and I > quote "If we had had async logging from day one then the way we > construct log messages would have been done differently". In current > codebase, I have to copy logging messages anyway, the real cost should > come from "copying" instead of allocating. Further, I have moved > "allocate" and "free" out of critical areas. If performance does matter, > we will have a overall deign including both sync/async messages and > decorators. > > May I call out JDK-8264323? It's a CSR about JVM option. I have written > down pros and cons. Could you take a look? I can support both global > option and finer-grained output-option. I won't increase much complexity. If we decide that global option is the way to go, I think we should not add fine-grained option at the same time. Even if the implementation may be easy for now, it makes the system more complex and harder to evolve in the future. Thanks - Ioi > [1]code is here: > https://github.com/openjdk/jdk/pull/3135/commits/9211121c7afeb7a9fe602fd2a4d20bd98ddb1569 > [2] here is the request: > https://github.com/openjdk/jdk/pull/3135#issuecomment-809977841 > [3] https://github.com/openjdk/jdk/pull/3135#issuecomment-813880728 > > > > > On 4/12/21 10:30 PM, Thomas St?fe wrote: >> *CAUTION*: This email originated from outside of the organization. Do >> not click links or open attachments unless you can confirm the sender >> and know the content is safe. >> >> >> Hi Xin & others, >> >> Sorry for the late response, I had vacation. >> >> As I wrote before, I think this is a valuable improvement. I would be >> unhappy if this were stalled further. >> >> In this thread there seems to be a majority opinion now for >> - having an own thread instead of using the WatcherThread >> - having a global option for async (good point, Ioi) >> >> AFAICS the only POC left is the question whether to make the sizing >> option a memory size or a "number of entries". I argued for the memory >> size before, but won't insist on it, in order to move this issue forward >> (we could always just keep that option diagnostic). >> >> Is there anything else left to discuss? >> >> I mentioned before that I think UL is too complex and could benefit from >> simplification; but this is clearly not Xins fault, and I am sorry that >> I brought this even up here, since it has nothing to do with this RFE. >> >> Cheers, Thomas >> >> >> >> On Tue, Mar 30, 2021 at 11:21 PM Liu, Xin > > wrote: >> >> Thanks Volker for this. I would like to append some additional >> materials.? I forgot to mention them when I wrote the Rationale[5] >> yesterday. >> >> We identified and root-caused the tail-latency on a Linux system >> with software RAID in 2018. >> We have different implementations on jdk8u and jdk11u. We are >> seeking to merge this feature to tip. >> >> Nonetheless, it doesn't mean "async-logging facility" only solves >> Amazon's peculiar problem.? When we studied this, we found many >> interesting references. >> Eg. LinkedIn reported and analyzed it well[1]. In particular, they >> mentioned that one reason was Linux cache writeback [2]. IMHO, that >> could impact >> almost all mass-storge Linux filesystems. Twitter also expressed >> that "I would love to hear if this can happen with OpenJDK!"[3]. >> This is also reported >> by other companies[4]. >> >> Thanks, >> --lx >> >> >> [1] >> https://engineering.linkedin.com/blog/2016/02/eliminating-large-jvm-gc-pauses-caused-by-background-io-traffic >> >> [2] >> https://yoshinorimatsunobu.blogspot.com/2014/03/why-buffered-writes-are-sometimes.html >> >> [3] https://www.evanjones.ca/jvm-mmap-pause-finding.html >> >> [4] >> https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-June/042301.html >> >> [5] https://github.com/openjdk/jdk/pull/3135#issuecomment-809942487 >> >> >> ?On 3/30/21, 11:20 AM, "Volker Simonis" > > wrote: >> >> ? ? CAUTION: This email originated from outside of the organization. >> Do not click links or open attachments unless you can confirm the >> sender and know the content is safe. >> >> >> >> ? ? Hi, >> >> ? ? I'd like to (re)start a discussion on asynchronous logging >> [1,2,3,4]. >> ? ? We are successfully using this feature productively at Amazon >> both in >> ? ? jdk8 and jdk11 to reduce the tail latency of services > which use >> ? ? logging. We think that async logging is a useful addition to the >> ? ? current logging framework which might be beneficial to a wider range >> ? ? of users. The following write-up tries to capture the > comments and >> ? ? suggestions from the previous discussions we are aware of. >> >> ? ? Current state: >> >> ? ? - HotSpot uses the so called "Unified Logging" (UL) framework which >> ? ? was introduced by JEP 158 [5] in JDK 9. Most logs have been >> ? ? retrofitted to use UL since then (e.g. "JEP 271: Unified GC Logging" >> ? ? [6]). >> ? ? - The current UL implementation is based on the standard C buffered >> ? ? stream I/O interface [7]. The LogFileStreamOutput class which writes >> ? ? logs to abstract FILE streams is the only child of the abstract base >> ? ? class LogOutput. LogFileStreamOutput has three child classes >> ? ? LogStdoutOutput,? LogStderrOutput and LogFileOutput which write to >> ? ? stdout, stderr or an arbitrary file respectively. The > initial UL JEP >> ? ? 158 [5] envisioned logging to a socket but has not implemented >> it. At >> ? ? least one such extension has been proposed since then > [8]. >> ? ? - UL synchronizes logs from different threads with the help of the >> ? ? standard C flockfile()/funlockfile() [9] functions. But even without >> ? ? this explicit locking, all the "stdio functions are thread-safe. >> This >> ? ? is achieved by assigning to each FILE object a lockcount and (if the >> ? ? lockcount is nonzero) an owning thread.? For each library call, >> these >> ? ? functions wait until the FILE object is no longer locked by a >> ? ? different thread, then lock it, do the requested I/O, > and unlock the >> ? ? object again" [9]. A quick look at the glibc sources reveals >> that FILE >> ? ? locking is implemented with the help of futex() [10] which >> breaks down >> ? ? to s simple atomic compare and swap (CAS) on the fast > path. >> ? ? - Notice that UL "synchronizes" logs from different threads to avoid >> ? ? log interleaving. But it does not "serialize" logs according to the >> ? ? time at which? they occurred. This is because the underlying stdio >> ? ? functions do not guarantee a specific order for different threads >> ? ? waiting on a locked FILE stream. E.g. if three log events A, B, C >> ? ? occur in that order, the first will lock the output stream. If >> the log >> ? ? events B and C both arrive while the stream is locked, it is >> ? ? unspecified which of B and C will be logged first after A >> releases the >> ? ? lock. >> >> ? ? Problem statement: >> >> ? ? - The amount of time a log event will block its FILE stream >> depends on >> ? ? the underlying file system. This can range from a few >> nanoseconds for >> ? ? in-memory file systems or milliseconds for physical discs under >> heavy >> ? ? load up to several seconds in the worst case scenario > for e.g. >> network >> ? ? file systems. A blocked log output stream will block all concurrent >> ? ? threads which try to write log messages at the same time. If logging >> ? ? is done during a safepoint, this can significantly increase the >> ? ? safepoint time (e.g. several parallel GC threads trying to log >> at the >> ? ? same time). We can treat stdout/stderr as special files here without >> ? ? loss of generality. >> >> ? ? Proposed solution: >> >> ? ? Extend UL with an asynchronous logging facility. Asynchronous >> logging >> ? ? will be optional and disabled by default. It should have the >> following >> ? ? properties: >> ? ? - If disabled (the default) asynchronous logging should have no >> ? ? observable impact on logging. >> ? ? - If enabled, log messages will be stored in an intermediate data >> ? ? structure (e.g. a double ended queue). >> ? ? - A service thread will concurrently read and remove log >> messages from >> ? ? that data structure in a FIFO style and write them to > the output >> ? ? stream >> ? ? - Storing log messages in the intermediate data structure should >> take >> ? ? constant time and not longer than logging a message takes in the >> ? ? traditional UL system (in general the time should be much shorter >> ? ? because the actual I/O is deferred). >> ? ? - Asynchronous logging trades memory overhead (i.e. the size of the >> ? ? intermediate data structure) for log accuracy. This means that >> in the >> ? ? unlikely case where the service thread which does the > asynchronous >> ? ? logging falls behind the log producing threads, some logs might be >> ? ? lost. However, the probability for this to happen can > be >> minimized by >> ? ? increasing the configurable size of the intermediate data structure. >> ? ? - The final output produced by asynchronous logging should be >> equal to >> ? ? the output from normal logging if no messages had to be dropped. >> ? ? Notice that in contrast to the traditional unified logging, >> ? ? asynchronous logging will give us the possibility to not only >> ? ? synchronize log events, but to optionally also serialize them >> based on >> ? ? their generation time if that's desired. This is because we are in >> ? ? full control of the synchronization primitives for the intermediate >> ? ? data structure which stores the logs. >> ? ? - If log messages had to be dropped, this should be logged in >> the log >> ? ? output (e.g. "[..] 42 messages dropped due to async logging") >> ? ? - Asynchronous logging should ideally be implemented in such a way >> ? ? that it can be easily adapted by alternative log targets like for >> ? ? example sockets in the future. >> >> ? ? Alternative solutions: >> ? ? - It has repeatedly been suggested to place the log files into a >> ? ? memory file system but we don't think this is an optimal solution. >> ? ? Main memory is often a constrained resource and we don't want log >> ? ? files to compete with the JVM for it in such cases. >> ? ? - It has also been argued to place the log files on a > fast file >> system >> ? ? which is only used for logging but in containerized environments >> file >> ? ? system are often virtualized and the properties of the underlying >> ? ? physical devices are not obvious. >> ? ? - The load on the file system might be unpredictable due to other >> ? ? applications on the same host. >> ? ? - All these workarounds won't work if we eventually implement direct >> ? ? logging to a network socket as suggested in [8]. >> >> ? ? Implementation details / POC: >> >> ? ? - A recent pull request [2] for JDK-8229517 [3] proposed to use a >> ? ? simple deque implementation derived from HotSpot's LinkedListImpl >> ? ? class for the intermediate data structure. It synchronizes access to >> ? ? the queue with a MutexLocker which is internally implemented with >> ? ? pthread_lock() and results in an atomic CAS on the fast path. So >> ? ? performance-wise the locking itself is not different from the >> ? ? flockfile()/funlockfile() functionality currently used by UL but >> ? ? adding a log message to the deque should be constant as it basically >> ? ? only requires a strdup(). And we could even eliminate > the >> strdup() if >> ? ? we'd pre-allocate a big enough array for holding the log messages as >> ? ? proposed in the pull request [2]. >> ? ? - The pull pull request [2] for JDK-8229517 [3] proposed to set the >> ? ? async flag as an attribute of the Xlog option which feels more >> natural >> ? ? because UL configuration is traditionally done within > the Xlog >> option. >> ? ? But we could just as well use a global -XX flag to enable async >> ? ? logging? What are your preferences here? >> ? ? - The pull pull request [2] for JDK-8229517 [3] (mis)uses the >> ? ? WatcherThread as service thread to concurrently process the >> ? ? intermediate data structure and write the log messages out to >> the log >> ? ? stream. That should definitely be changed to an independent service >> ? ? thread. >> ? ? - The pull pull request [2] for JDK-8229517 [3] initially proposed >> ? ? that the "service thread" runs at a fixed interval to > dump log >> ? ? messages to the log streams. But reviewers commented that this >> should >> ? ? better happen either continuously or based on the filling level >> of the >> ? ? intermediate data structure. What are your preferences here? >> ? ? - What are your preferences on the configuration of the intermediate >> ? ? data structure? Should it be configured based on the maximum >> number of >> ? ? log messages it can store or rather on the total size > of the stored >> ? ? log messages? I think that for normal runs this distinction probably >> ? ? won't make a big difference because the size of log messages will >> ? ? probably be the same on average so "number of log messages" should >> ? ? always be proportional to "total size of log mesages". >> >> ? ? 1. Before diving into more implementation details, I'd first like to >> ? ? reach a general consensus that asynchronous logging is a useful >> ? ? feature that's worth while adding to HotSpot. >> >> ? ? 2. Once we agree on that, we should agree on the desired >> properties of >> ? ? asynchronous logging. I've tried to collect a basic set in the >> ? ? "Proposed solution" section. >> >> ? ? 3. If that's done as well, we can discuss various implementation >> ? ? details and finally prepare new pull requests. >> >> ? ? Thank you and best regards, >> ? ? Volker >> >> ? ? [1] https://bugs.openjdk.java.net/browse/JDK-8229517 >> >> ? ? [2] https://github.com/openjdk/jdk/pull/3135 >> >> ? ? [3] >> https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-November/043427.html >> >> ? ? [4] >> https://mail.openjdk.java.net/pipermail/hotspot-dev/2019-August/039130.html >> >> ? ? [5] https://openjdk.java.net/jeps/158 >> >> ? ? [6] https://openjdk.java.net/jeps/271 >> >> ? ? [7] https://man7.org/linux/man-pages/man3/stdio.3.html >> >> ? ? [8] >> https://gist.github.com/YaSuenag/dacb6d94d8684915422232c7a08d5b5d >> >> ? ? [9] https://man7.org/linux/man-pages/man3/flockfile.3.html >> >> ? ? [10] https://man7.org/linux/man-pages/man2/futex.2.html >> >> > From iklam at openjdk.java.net Mon Apr 19 17:56:56 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 19 Apr 2021 17:56:56 GMT Subject: RFR: 8265411: Avoid unnecessary Method::init_intrinsic_id calls Message-ID: `check_methods_for_intrinsics()` in classFileParser.cpp calls `Method::klass_id_for_intrinsics()` to see if a class has intrinsic methods. However, the latter returns any class whose name is included in `vmSymbols`. This causes many unnecessary calls to `Method::init_intrinsic_id()`. To fix this, we precompute the classes that are known to have intrinsics using `constexpr`. See `vmIntrinsics::class_has_intrinsics`. After the fix, when running `java -Xshare:off -version`, the number of classes initialized for intrinsics is reduced from 130 to 30. Testing: mach5 tiers 1~4 passed. ------------- Commit messages: - more fixes - Improve vmIntrinsics with constexpr Changes: https://git.openjdk.java.net/jdk/pull/3564/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3564&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265411 Stats: 54 lines in 5 files changed: 47 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/3564.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3564/head:pull/3564 PR: https://git.openjdk.java.net/jdk/pull/3564 From cjplummer at openjdk.java.net Mon Apr 19 20:20:07 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 19 Apr 2021 20:20:07 GMT Subject: RFR: 8265036: JFR: Remove use of -XX:StartFlightRecording= and -XX:FlightRecorderOptions= In-Reply-To: References: Message-ID: On Sun, 18 Apr 2021 15:17:35 GMT, Erik Gahlin wrote: > Hi, > > Could I have a review of fix that removes the use of "=" together with -XX:StartFlightRecording and -XX:FlightRecorderOptions. It's been possible to use "-XX:StartFlightRecording:" and "-XX:FlightRecorderOption:" since JFR was introduced into OpenJDK (JDK 11), so this is not a change of the specification, just an update to make the use consistent in tests, comments, documentation etc. > > I also removed the use of -XX:+FlightRecorder, which is not needed, and has been deprecated since JDK 13. > > Testing: jdk/jdk/jfr, tier 1-4. > > Thanks > Erik The changes look good. Have you considered doing a test run where the use of `=` and `XX:+FlightRecorder` are disallowed just to make sure you caught them all? ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3561 From cjplummer at openjdk.java.net Mon Apr 19 21:16:08 2021 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Mon, 19 Apr 2021 21:16:08 GMT Subject: RFR: 8265036: JFR: Remove use of -XX:StartFlightRecording= and -XX:FlightRecorderOptions= In-Reply-To: References: Message-ID: <2-NewUlYrdJ7H67-xrLMo71CB-m2YPTrjJmYVPR7Hi4=.134d7e91-2d75-49f6-b3df-dfaec043fef7@github.com> On Sun, 18 Apr 2021 15:17:35 GMT, Erik Gahlin wrote: > Hi, > > Could I have a review of fix that removes the use of "=" together with -XX:StartFlightRecording and -XX:FlightRecorderOptions. It's been possible to use "-XX:StartFlightRecording:" and "-XX:FlightRecorderOption:" since JFR was introduced into OpenJDK (JDK 11), so this is not a change of the specification, just an update to make the use consistent in tests, comments, documentation etc. > > I also removed the use of -XX:+FlightRecorder, which is not needed, and has been deprecated since JDK 13. > > Testing: jdk/jdk/jfr, tier 1-4. > > Thanks > Erik Sorry, I accidentally stuck an "integrate" label in this PR (was meant for my own PR). I immediately deleted it. Hopefully no harm done. ------------- PR: https://git.openjdk.java.net/jdk/pull/3561 From github.com+2249648+johntortugo at openjdk.java.net Mon Apr 19 21:57:10 2021 From: github.com+2249648+johntortugo at openjdk.java.net (John Tortugo) Date: Mon, 19 Apr 2021 21:57:10 GMT Subject: RFR: 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests [v3] In-Reply-To: References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> Message-ID: On Mon, 19 Apr 2021 12:49:39 GMT, Christian Hagedorn wrote: >> This RFE provides an IR test framework to perform regex-based checks on the C2 IR shape of test methods emitted by the VM flags `-XX:+PrintIdeal` and `-XX:+PrintOptoAssembly`. The framework can also be used for other non-IR matching (and non-compiler) tests by providing easy to use annotations for commonly used testing patterns and compiler control flags. >> >> The framework is based on the ideas of the currently present IR test framework in [Valhalla](https://github.com/openjdk/valhalla/blob/e9c78ce4fcfd01361c35883e0d68f9ae5a80d079/test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypeTest.java) (mainly implemented by @TobiHartmann) which is being used with great success. This new framework aims to replace the old one in Valhalla at some point. >> >> A detailed description about how this new IR test framework works and how it is used is provided in the [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) file and in the [Javadocs](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc/jdk/test/lib/hotspot/ir_framework/package-summary.html) written for the framework classes. >> >> To finish a first version of this framework for JDK 17, I decided to leave some improvement possibilities and ideas to be followed up on in additional RFEs. Some ideas are mentioned in "Future Work" in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) and were also created as subtasks of this RFE. >> >> Testing (also described in "Internal Framework Tests in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md)): >> There are various tests to verify the correctness of the test framework which can be found as JTreg tests in the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) folder. Additional testing was performed by converting all compiler Inline Types test of project Valhalla (done by @katyapav in [JDK-8263024](https://bugs.openjdk.java.net/browse/JDK-8263024)) that used the old framework to the new framework. This provided additional testing for the framework itself. We ran the converted tests with all the flag settings used in hs-tier1-9 and hs-precheckin-comp. For sanity checking, this was also done with a sample IR test in mainline. >> >> Some stats about the framework code added to [ir_framework](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework): >> >> - without the [Javadocs files](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc) : 60 changed files, 13212 insertions, 0 deletions. >> - without the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) and [examples](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/examples) folder: 40 files changed, 6781 insertions >> - comments: 2399 insertions (calculated with `git diff --cached !(tests|examples) | grep -c -E "(^[+-]\s*(/)?*)|(^[+-]\s*//)"`) >> - which leaves 4382 lines of code inserted >> >> Big thanks to: >> - @TobiHartmann for all his help by discussing the new framework and for providing insights from his IR test framework in Valhalla. >> - @katyapav for converting the Valhalla tests to use the new framework which found some harder to catch bugs in the framework and also some actual C2 bugs. >> - @iignatev for helping to simplify the framework usage with JTreg and with the framework internal VM calling structure. >> - and others who provided valuable feedback. >> >> Thanks, >> Christian > > Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: > > Apply review comments in code from Igor I. and Vladimir K. test/lib/jdk/test/lib/hotspot/ir_framework/IRMethod.java line 32: > 30: */ > 31: class IRMethod { > 32: final private Method method; The order of these keywords seems to be inverted. test/lib/jdk/test/lib/hotspot/ir_framework/README.md line 43: > 41: The simplest form of testing provides a single `@Test` annotated method which the framework will invoke as part of the testing. The test method has no or well-defined arguments that the framework can automatically provide. > 42: > 43: More information on base tasts with a precise definition can be found in the [Javadocs](./doc/jdk/test/lib/hotspot/ir_framework/Test.html). Concrete examples on how to specify a base test can be found in [BaseTestsExample](./examples/BaseTestExample.java). "tasts" test/lib/jdk/test/lib/hotspot/ir_framework/README.md line 48: > 46: The base tests do not provide any way of verification by user code. A checked test enabled that by allowing the user to define an additional `@Check` annotated method which is invoked directly after the `@Test` annotated method. This allows the user to perform various checks about the test method including return value verification. > 47: > 48: More information on checked tasts with a precise definition can be found in the [Javadocs](./doc/jdk/test/lib/hotspot/ir_framework/Check.html). Concrete examples on how to specify a checked test can be found in [CheckedTestsExample](./examples/CheckedTestExample.java). Typo "tasts" test/lib/jdk/test/lib/hotspot/ir_framework/README.md line 53: > 51: Neither the base nor the checked tests provide any control over how a `@Test` annotated method is invoked in terms of customized argument values and/or conditions for the invocation itself. A custom run test gives full control over the invocation of the `@Test` annotated method to the user. The framework calls a dedicated `@Run` annotated method from which the user can invoke the `@Test` method according to his/her needs. > 52: > 53: More information on checked tasts with a precise definition can be found in the [Javadocs](./doc/jdk/test/lib/hotspot/ir_framework/Run.html). Concrete examples on how to specify a custom run test can be found in [CustomRunTestsExample](./examples/CustomRunTestExample.java). Typo: "tasts" -> "tests". test/lib/jdk/test/lib/hotspot/ir_framework/README.md line 74: > 72: > 73: ### 2.3 Test VM Flags and Scenarios > 74: The recommended way to use the framework is by using defining single `@run driver` statement in the JTreg header which, however, does not allow the specification of additional test VM flags. Instead, the user has the possibility to provide VM flags by calling `TestFramework.runWithFlags()` or by creating a `TestFramework` builder object on which `addFlags()` can be called. Typo: missing article or duplicated words? "is by using defining single" test/lib/jdk/test/lib/hotspot/ir_framework/README.md line 110: > 108: > 109: The framework will spawn a new "test VM" to execute the user defined tests. The test VM collects all tests of the test class specified by the user code in `main()` and ensures that there is no violation of the required format by the framework. In a next step, the framework does the following for each test in general: > 110: 1. Warm the test up for a predefined number of times (default 2000). This can also be adapted for all tests by using `testFrameworkobject.setDefaultWarmup(100)` or for individual tests with an additional [@Warmup](./doc/jdk/test/lib/hotspot/ir_framework/Warmup.html) annotation. The previous section seems to indicate that the default number of warm-up iterations is 200. "-Dwarmup=200". test/lib/jdk/test/lib/hotspot/ir_framework/README.md line 112: > 110: 1. Warm the test up for a predefined number of times (default 2000). This can also be adapted for all tests by using `testFrameworkobject.setDefaultWarmup(100)` or for individual tests with an additional [@Warmup](./doc/jdk/test/lib/hotspot/ir_framework/Warmup.html) annotation. > 111: 2. After the warm-up is finished, the framework compiles the associated `@Test` annotated method at the specified compilation level (default: C2). > 112: 3. After the compilation, the test is invokes one more time. Typoe: "invokes" -> "invoked". test/lib/jdk/test/lib/hotspot/ir_framework/README.md line 116: > 114: Once the test VM terminates, IR verification (if possible) is performed on the output of the test VM. If any test throws an exception during its execution or if IR matching fails, the failures are collected and reported in a pretty format. Check the standard error and output for more information and how to reproduce these failures. > 115: > 116: Some of the steps above can be different due to the kind of the test or due to using non-default annotation properties. These details and differences are discribed in the Javadocs for the three tests (see section 2.1 Different Tests). Typo: "discribed" -> "described". test/lib/jdk/test/lib/hotspot/ir_framework/examples/BaseTestExample.java line 65: > 63: > 64: public static void main(String[] args) { > 65: TestFramework.run(); // equivalent to TestFramework.run(TestSimpleTest.class) Did you mean same as `TestFramework.run(BaseTestExample.class)` ? test/lib/jdk/test/lib/hotspot/ir_framework/examples/CheckedTestExample.java line 72: > 70: > 71: public static void main(String[] args) { > 72: TestFramework.run(); // equivalent to TestFramework.run(TestSimpleTest.class) Did you mean same as `TestFramework.run(CheckedTestExample.class)` ? test/lib/jdk/test/lib/hotspot/ir_framework/examples/CustomRunTestExample.java line 80: > 78: > 79: public static void main(String[] args) { > 80: TestFramework.run(); // equivalent to TestFramework.run(TestSimpleTest.class) Did you mean same as `TestFramework.run(CustomRunTestExample.class)` ? test/lib/jdk/test/lib/hotspot/ir_framework/examples/IRExample.java line 145: > 143: @IR(failOn = {IRNode.STORE, IRNode.LOOP}) // LOOP regex not found but STORE regex, letting the rule fail > 144: @IR(failOn = {IRNode.LOOP, IRNode.STORE}) // Order does not matter > 145: @IR(failOn = {IRNode.STORE, IRNode.LOAD}) // LOOP and STORE regex, letting the rule fail LOOP regex? ------------- PR: https://git.openjdk.java.net/jdk/pull/3508 From github.com+168222+mgkwill at openjdk.java.net Mon Apr 19 23:06:32 2021 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Mon, 19 Apr 2021 23:06:32 GMT Subject: RFR: 8265491: Math Signum optimization for x86 Message-ID: For x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM. We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization. Base: Benchmark Mode Cnt Score Error Units Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op Optimized: signum intrinsic patch Benchmark Mode Cnt Score Error Units Signum._1_signumFloatTest avgt 5 3.782 ? 0.019 ns/op Signum._3_signumDoubleTest avgt 5 3.782 ? 0.017 ns/op Signed-off-by: Marcus G K Williams ------------- Commit messages: - Add x86 signum intrinsic Changes: https://git.openjdk.java.net/jdk/pull/3581/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3581&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265491 Stats: 189 lines in 4 files changed: 186 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3581.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3581/head:pull/3581 PR: https://git.openjdk.java.net/jdk/pull/3581 From iignatyev at openjdk.java.net Mon Apr 19 23:27:09 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Mon, 19 Apr 2021 23:27:09 GMT Subject: RFR: 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests [v2] In-Reply-To: References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> Message-ID: On Mon, 19 Apr 2021 09:23:10 GMT, Christian Hagedorn wrote: > I suggest to keep run() and maybe also runWithFlags() as (probably?) most common use-case. I guess you are right, `run()` and `runWithFlags(String[])` will be most-commonly used ones. ------------- PR: https://git.openjdk.java.net/jdk/pull/3508 From iignatyev at openjdk.java.net Mon Apr 19 23:36:15 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Mon, 19 Apr 2021 23:36:15 GMT Subject: RFR: 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests [v2] In-Reply-To: References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> Message-ID: On Mon, 19 Apr 2021 09:42:04 GMT, Christian Hagedorn wrote: >> test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 407: >> >>> 405: start(null); >>> 406: } catch (TestVMException e) { >>> 407: System.err.println("\n" + e.getExceptionInfo()); >> >> you shouldn't use "\n", as it might not be the right line-separator. you can either do: >> Suggestion: >> >> System.err.println(); >> System.err.println(e.getExceptionInfo()); >> >> or >> Suggestion: >> >> System.err.printf("%n%s%n", e.getExceptionInfo()); > > I will address all `\n` in a separate commit as there are a lot of them. Could I also just use `System.lineSeparator()` anywhere where I'm currently using `\n` like `System.err.println(System.lineSeparator() + e.getExceptionInfo()`)? Might be easier when I'm using `\n` with a `StringBuilder`, for example. sure you case use `System.lineSeparator()`, it's just a matter of personal choice/style >> test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 804: >> >>> 802: System.err.println("--- OUTPUT TestFramework flag VM ---"); >>> 803: System.err.println(flagVMOutput); >>> 804: throw new RuntimeException("\nTestFramework flag VM exited with " + exitCode); >> >> what's the reason for `\n` in the begging of this exception message? > > I guess it's not necessary. Removed it. ?? . I noticed that you have leading `\n` in other exceptions, do you plan to remove it from there as well? ------------- PR: https://git.openjdk.java.net/jdk/pull/3508 From iignatyev at openjdk.java.net Mon Apr 19 23:36:14 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Mon, 19 Apr 2021 23:36:14 GMT Subject: RFR: 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests [v2] In-Reply-To: References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> Message-ID: On Mon, 19 Apr 2021 09:37:40 GMT, Christian Hagedorn wrote: >> you might also want to update javadoc for this method to state that there can be duplicates. > > Have I understood this correctly that you suggest to just remove this check completely and just specifying in the Javadocs that duplicates are ignore (due to using a `Set`)? you don't have to ignore duplicates, you can still throw an exception if you encounter one. I, personally, don't think we should force users to avoid dups (as I don't yet? see any issues w/ duplicated helpers), but if you think we need to enforce that *and* make it users' responsibilities then you should continue to throw an exception. in both cases, javadoc should be updated to reflect that duplicates are ignored or that an exception is raised in case a duplicate was encountered. ------------- PR: https://git.openjdk.java.net/jdk/pull/3508 From iignatyev at openjdk.java.net Mon Apr 19 23:41:09 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Mon, 19 Apr 2021 23:41:09 GMT Subject: RFR: 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests [v2] In-Reply-To: References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> Message-ID: <_4R3VaH4SDOdZ9K4mgapY3eIKYD2Y_ALsMjDFz7KSAc=.73e9490f-2b1f-49f8-b41a-2dbd5c4e77a0@github.com> On Mon, 19 Apr 2021 08:10:13 GMT, Christian Hagedorn wrote: >> test/lib/jdk/test/lib/hotspot/ir_framework/IRMatcher.java line 116: >> >>> 114: private void parseHotspotPidFile() { >>> 115: Map compileIdMap = new HashMap<>(); >>> 116: try (BufferedReader br = new BufferedReader(new FileReader(new File(System.getProperty("user.dir") + File.separator + hotspotPidFileName)))) { >> >> more idiomatic/modern version would be >> Suggestion: >> >> try (BufferedReader br = Files.newBufferedReader(Paths.get(System.getProperty("user.dir"), hotspotPidFileName))) { >> >> >> I actually not sure if you really need `$user.dir`, won't hotspot_pid file get generated in the current dir? > > Yes it should. Would this be equivalent to `Paths.get("")`? It seems to work like that. `Paths.get(hotspotPidFileName)` returns you a `Path` to `hotspotPidFileName` in cwd. >> test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 958: >> >>> 956: throw new TestFrameworkException("Internal Test Framework exception - please file a bug:\n" + failureMessage, e); >>> 957: } >>> 958: } >> >> I am not convinced that we really these guys when we already have `TestFormat::check` and `TestRun::check` (I'm actually not 100% convinced that we need check/fail in both TestFormat and TestRun) > > I wanted to distinguish the following cases (but I'm open to use a different approach): > > - `TestFormat::check` (using `TestFormatException`): The format of any test/helper class does not conform with the format the framework is expecting. The user needs to fix this (for example, using a wrong annotation). I report these kind of failures before actually running any of the tests [here](https://github.com/openjdk/jdk/blob/7ed789dc98691d7c7fc2295e045a9f54b9fa6277/test/lib/jdk/test/lib/hotspot/ir_framework/TestFrameworkExecution.java#L265). > - `TestRun::check` (using `TestRunException`): Thrown while the framework is [executing a test](https://github.com/openjdk/jdk/blob/7ed789dc98691d7c7fc2295e045a9f54b9fa6277/test/lib/jdk/test/lib/hotspot/ir_framework/TestFrameworkExecution.java#L799), there is nothing wrong with the format of a test. > - `TestFramework::check` (using `TestFrameworkException`): If such a check fails there is a bug in the framework itself (like internal framework assertions). The user cannot really do anything about it without fixing the framework itself. > > I have to double check again if I'm using the right kind of exception everywhere. I understand that you want to use different exception types to distinguish different kinds of failures, I just don't see lots of benefits in have `::check` and `::fail` methods, they are just `if (p) throw new X(m)` or `throw new X(m)`. if, for example, you want `TestFrameworkException` to always have `Internal Test Framework exception - please file a bug`, you can prepend it in `TestFrameworkException::` ------------- PR: https://git.openjdk.java.net/jdk/pull/3508 From ysuenaga at openjdk.java.net Tue Apr 20 05:10:08 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 20 Apr 2021 05:10:08 GMT Subject: Integrated: 8263718: unused-result warning happens at os_linux.cpp In-Reply-To: References: Message-ID: On Wed, 17 Mar 2021 06:31:28 GMT, Yasumasa Suenaga wrote: > I tried to build OpenJDK with g++-10.2.1_pre1-r3 on Alpine Linux 3.13.2, but I saw following warning: This pull request has now been integrated. Changeset: f1d4ae6c Author: Yasumasa Suenaga URL: https://git.openjdk.java.net/jdk/commit/f1d4ae6c Stats: 27 lines in 3 files changed: 6 ins; 20 del; 1 mod 8263718: unused-result warning happens at os_linux.cpp Reviewed-by: dholmes, stuefe ------------- PR: https://git.openjdk.java.net/jdk/pull/3042 From dholmes at openjdk.java.net Tue Apr 20 05:23:07 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 20 Apr 2021 05:23:07 GMT Subject: RFR: 8265411: Avoid unnecessary Method::init_intrinsic_id calls In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 05:52:02 GMT, Ioi Lam wrote: > `check_methods_for_intrinsics()` in classFileParser.cpp calls `Method::klass_id_for_intrinsics()` to see if a class has intrinsic methods. However, the latter returns any class whose name is included in `vmSymbols`. This causes many unnecessary calls to `Method::init_intrinsic_id()`. > > To fix this, we precompute the classes that are known to have intrinsics using `constexpr`. See `vmIntrinsics::class_has_intrinsics`. > > After the fix, when running `java -Xshare:off -version`, the number of classes initialized for intrinsics is reduced from 130 to 30. > > Testing: mach5 tiers 1~4 passed. Hi Ioi, That all appears fine to me. Is there any startup impact? Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3564 From egahlin at openjdk.java.net Tue Apr 20 07:43:36 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Tue, 20 Apr 2021 07:43:36 GMT Subject: RFR: 8265036: JFR: Remove use of -XX:StartFlightRecording= and -XX:FlightRecorderOptions= [v2] In-Reply-To: References: Message-ID: > Hi, > > Could I have a review of fix that removes the use of "=" together with -XX:StartFlightRecording and -XX:FlightRecorderOptions. It's been possible to use "-XX:StartFlightRecording:" and "-XX:FlightRecorderOption:" since JFR was introduced into OpenJDK (JDK 11), so this is not a change of the specification, just an update to make the use consistent in tests, comments, documentation etc. > > I also removed the use of -XX:+FlightRecorder, which is not needed, and has been deprecated since JDK 13. > > Testing: jdk/jdk/jfr, tier 1-4. > > Thanks > Erik Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision: Replace '=' in jfrOptionsSet.cpp ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3561/files - new: https://git.openjdk.java.net/jdk/pull/3561/files/4ce08939..138bac16 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3561&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3561&range=00-01 Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/3561.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3561/head:pull/3561 PR: https://git.openjdk.java.net/jdk/pull/3561 From egahlin at openjdk.java.net Tue Apr 20 07:55:08 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Tue, 20 Apr 2021 07:55:08 GMT Subject: RFR: 8265036: JFR: Remove use of -XX:StartFlightRecording= and -XX:FlightRecorderOptions= [v2] In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 20:16:59 GMT, Chris Plummer wrote: > The changes look good. Have you considered doing a test run where the use of `=` and `XX:+FlightRecorder` are disallowed just to make sure you caught them all? It's a good idea, but it requires changes outside OpenJDK which I rather not do now. I'm sure somebody will reintroduce '=', so this is not so much about getting rid of them all, but to avoid them being propagated, when code is copy pasted for new tests etc. ------------- PR: https://git.openjdk.java.net/jdk/pull/3561 From jbhateja at openjdk.java.net Tue Apr 20 08:41:07 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Tue, 20 Apr 2021 08:41:07 GMT Subject: RFR: 8265491: Math Signum optimization for x86 In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 23:00:47 GMT, Marcus G K Williams wrote: > x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM. > > We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization. > > Base: > Benchmark Mode Cnt Score Error Units > Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op > Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op > > Optimized: > signum intrinsic patch > Benchmark Mode Cnt Score Error Units > Signum._1_signumFloatTest avgt 5 3.782 ? 0.019 ns/op > Signum._3_signumDoubleTest avgt 5 3.782 ? 0.017 ns/op > > Signed-off-by: Marcus G K Williams @mgkwill, your newly added benchmark has 4 micro worklets, please publish the results for all of them. ------------- PR: https://git.openjdk.java.net/jdk/pull/3581 From stuefe at openjdk.java.net Tue Apr 20 11:52:35 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 20 Apr 2021 11:52:35 GMT Subject: RFR: JDK-8155004: CrashOnOutOfMemoryError doesn't work for OOM caused by inability to create threads Message-ID: Greetings, this is an old issue and I'd like to fix it. If we fail to create a java thread due to platform limitations we throw an OOM. But we fail to honor the various xxxOnOutOfMemoryError switches. The fix is very straightforward. One remaining question, maybe for a future RFE, is how we want to handle native threads creation error. AFAICS currently, failing to create a native thread may or may not result in a fatal shutdown, a log output, or just be ignored, depending on the thread. If `...OnOutOfMemoryError` is specified, should native thread creation failure be handled the same way as a java thread? - No if I take the option name literally, since there is no OOM involved - Yes if I take into account what these switches are actually used for - analysis or quick shutdown of a JVM inside a container in case of an OOM. Since it is completely random which thread is hit by the limit. Thanks, Thomas ------------- Commit messages: - start Changes: https://git.openjdk.java.net/jdk/pull/3586/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3586&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8155004 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3586.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3586/head:pull/3586 PR: https://git.openjdk.java.net/jdk/pull/3586 From dholmes at openjdk.java.net Tue Apr 20 12:10:07 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 20 Apr 2021 12:10:07 GMT Subject: RFR: JDK-8155004: CrashOnOutOfMemoryError doesn't work for OOM caused by inability to create threads In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 10:52:26 GMT, Thomas Stuefe wrote: > Greetings, > > this is an old issue and I'd like to fix it. If we fail to create a java thread due to platform limitations we throw an OOM. But we fail to honor the various xxxOnOutOfMemoryError switches. > > The fix is very straightforward. > > One remaining question, maybe for a future RFE, is how we want to handle native threads creation error. AFAICS currently, failing to create a native thread may or may not result in a fatal shutdown, a log output, or just be ignored, depending on the thread. > > If `...OnOutOfMemoryError` is specified, should native thread creation failure be handled the same way as a java thread? > > - No if I take the option name literally, since there is no OOM involved > - Yes if I take into account what these switches are actually used for - analysis or quick shutdown of a JVM inside a container in case of an OOM. Since it is completely random which thread is hit by the limit. > > Thanks, Thomas Hi Thomas, As I wrote in the bug report my take on these flags are that they are only intended for a Java heap OOME not arbitrary resource exhaustion where the VM chooses to throw OOME. I have previously rejected a number of "bug" reports about this. I was wondering if AbortVMOnException would not suffice here for you support case? Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/3586 From chagedorn at openjdk.java.net Tue Apr 20 13:40:59 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Tue, 20 Apr 2021 13:40:59 GMT Subject: RFR: 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests [v4] In-Reply-To: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> Message-ID: > This RFE provides an IR test framework to perform regex-based checks on the C2 IR shape of test methods emitted by the VM flags `-XX:+PrintIdeal` and `-XX:+PrintOptoAssembly`. The framework can also be used for other non-IR matching (and non-compiler) tests by providing easy to use annotations for commonly used testing patterns and compiler control flags. > > The framework is based on the ideas of the currently present IR test framework in [Valhalla](https://github.com/openjdk/valhalla/blob/e9c78ce4fcfd01361c35883e0d68f9ae5a80d079/test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypeTest.java) (mainly implemented by @TobiHartmann) which is being used with great success. This new framework aims to replace the old one in Valhalla at some point. > > A detailed description about how this new IR test framework works and how it is used is provided in the [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) file and in the [Javadocs](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc/jdk/test/lib/hotspot/ir_framework/package-summary.html) written for the framework classes. > > To finish a first version of this framework for JDK 17, I decided to leave some improvement possibilities and ideas to be followed up on in additional RFEs. Some ideas are mentioned in "Future Work" in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) and were also created as subtasks of this RFE. > > Testing (also described in "Internal Framework Tests in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md)): > There are various tests to verify the correctness of the test framework which can be found as JTreg tests in the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) folder. Additional testing was performed by converting all compiler Inline Types test of project Valhalla (done by @katyapav in [JDK-8263024](https://bugs.openjdk.java.net/browse/JDK-8263024)) that used the old framework to the new framework. This provided additional testing for the framework itself. We ran the converted tests with all the flag settings used in hs-tier1-9 and hs-precheckin-comp. For sanity checking, this was also done with a sample IR test in mainline. > > Some stats about the framework code added to [ir_framework](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework): > > - without the [Javadocs files](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc) : 60 changed files, 13212 insertions, 0 deletions. > - without the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) and [examples](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/examples) folder: 40 files changed, 6781 insertions > - comments: 2399 insertions (calculated with `git diff --cached !(tests|examples) | grep -c -E "(^[+-]\s*(/)?*)|(^[+-]\s*//)"`) > - which leaves 4382 lines of code inserted > > Big thanks to: > - @TobiHartmann for all his help by discussing the new framework and for providing insights from his IR test framework in Valhalla. > - @katyapav for converting the Valhalla tests to use the new framework which found some harder to catch bugs in the framework and also some actual C2 bugs. > - @iignatev for helping to simplify the framework usage with JTreg and with the framework internal VM calling structure. > - and others who provided valuable feedback. > > Thanks, > Christian Christian Hagedorn has updated the pull request incrementally with three additional commits since the last revision: - Improve error format output by changing some new lines - Replace "\n" by System.lineSeparator() - Fix typos and grammar, code format (JohnTortugo), fix exception throwing, toggleBoolean, shuffle and others (Igor I.) ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3508/files - new: https://git.openjdk.java.net/jdk/pull/3508/files/b3f58111..433006c5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3508&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3508&range=02-03 Stats: 209 lines in 19 files changed: 44 ins; 41 del; 124 mod Patch: https://git.openjdk.java.net/jdk/pull/3508.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3508/head:pull/3508 PR: https://git.openjdk.java.net/jdk/pull/3508 From chagedorn at openjdk.java.net Tue Apr 20 13:41:03 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Tue, 20 Apr 2021 13:41:03 GMT Subject: RFR: 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests [v3] In-Reply-To: References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> Message-ID: On Mon, 19 Apr 2021 12:49:39 GMT, Christian Hagedorn wrote: >> This RFE provides an IR test framework to perform regex-based checks on the C2 IR shape of test methods emitted by the VM flags `-XX:+PrintIdeal` and `-XX:+PrintOptoAssembly`. The framework can also be used for other non-IR matching (and non-compiler) tests by providing easy to use annotations for commonly used testing patterns and compiler control flags. >> >> The framework is based on the ideas of the currently present IR test framework in [Valhalla](https://github.com/openjdk/valhalla/blob/e9c78ce4fcfd01361c35883e0d68f9ae5a80d079/test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypeTest.java) (mainly implemented by @TobiHartmann) which is being used with great success. This new framework aims to replace the old one in Valhalla at some point. >> >> A detailed description about how this new IR test framework works and how it is used is provided in the [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) file and in the [Javadocs](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc/jdk/test/lib/hotspot/ir_framework/package-summary.html) written for the framework classes. >> >> To finish a first version of this framework for JDK 17, I decided to leave some improvement possibilities and ideas to be followed up on in additional RFEs. Some ideas are mentioned in "Future Work" in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) and were also created as subtasks of this RFE. >> >> Testing (also described in "Internal Framework Tests in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md)): >> There are various tests to verify the correctness of the test framework which can be found as JTreg tests in the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) folder. Additional testing was performed by converting all compiler Inline Types test of project Valhalla (done by @katyapav in [JDK-8263024](https://bugs.openjdk.java.net/browse/JDK-8263024)) that used the old framework to the new framework. This provided additional testing for the framework itself. We ran the converted tests with all the flag settings used in hs-tier1-9 and hs-precheckin-comp. For sanity checking, this was also done with a sample IR test in mainline. >> >> Some stats about the framework code added to [ir_framework](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework): >> >> - without the [Javadocs files](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc) : 60 changed files, 13212 insertions, 0 deletions. >> - without the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) and [examples](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/examples) folder: 40 files changed, 6781 insertions >> - comments: 2399 insertions (calculated with `git diff --cached !(tests|examples) | grep -c -E "(^[+-]\s*(/)?*)|(^[+-]\s*//)"`) >> - which leaves 4382 lines of code inserted >> >> Big thanks to: >> - @TobiHartmann for all his help by discussing the new framework and for providing insights from his IR test framework in Valhalla. >> - @katyapav for converting the Valhalla tests to use the new framework which found some harder to catch bugs in the framework and also some actual C2 bugs. >> - @iignatev for helping to simplify the framework usage with JTreg and with the framework internal VM calling structure. >> - and others who provided valuable feedback. >> >> Thanks, >> Christian > > Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: > > Apply review comments in code from Igor I. and Vladimir K. Updated with review comments from @JohnTortugo and @iignatev related to code. ------------- PR: https://git.openjdk.java.net/jdk/pull/3508 From chagedorn at openjdk.java.net Tue Apr 20 13:41:04 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Tue, 20 Apr 2021 13:41:04 GMT Subject: RFR: 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests [v2] In-Reply-To: References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> Message-ID: On Mon, 19 Apr 2021 15:37:49 GMT, Igor Ignatyev wrote: >> test/lib/jdk/test/lib/hotspot/ir_framework/AbstractInfo.java line 41: >> >>> 39: */ >>> 40: abstract public class AbstractInfo { >>> 41: private static final Random random = new Random(); >> >> you shouldn't use Random w/o predefined seed as it might make it harder to reproduce, please consider using `jdk.test.lib.Utils.getRandomInstance` or `jdk.test.lib.RandomFactory.getRandom` here > > I've also noticed that you use `Collections::shuffle` in `TestFrameworkExecution` w/o passing a reproducible rng. Fixed that, too. ------------- PR: https://git.openjdk.java.net/jdk/pull/3508 From chagedorn at openjdk.java.net Tue Apr 20 13:41:08 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Tue, 20 Apr 2021 13:41:08 GMT Subject: RFR: 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests [v2] In-Reply-To: References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> Message-ID: On Sat, 17 Apr 2021 01:16:33 GMT, Igor Ignatyev wrote: >> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: >> >> Adjust whitelist > > test/lib/jdk/test/lib/hotspot/ir_framework/IRMatcher.java line 182: > >> 180: private static void appendLine(StringBuilder builder, String line) { >> 181: if (line.contains("&")) { >> 182: line = line.replace("&", "&"); > > although I doubt it will ever be a problem in our use case, yet to be safe this replacement should be the last one, otherwise `&lt;` will become `<` while it should be `<` Good catch! > test/lib/jdk/test/lib/hotspot/ir_framework/IRMatcher.java line 349: > >> 347: if (matchCount > 0) { >> 348: matcher.reset(); >> 349: failMsg.append(" Regex ").append(nodeId).append(") ").append(nodeRegex).append("\n"); > > it seems you missed an opening parenthesis after `Regex ` . I used the parenthesis like an enumeration `Regex 1), Regex 2)` etc. But might be better to just use `Regex 1:`. > test/lib/jdk/test/lib/hotspot/ir_framework/IRMatcher.java line 516: > >> 514: */ >> 515: public void appendIdealOutput(String idealOutput) { >> 516: outputBuilder.setLength(0); > > I doubt that a method named `append.*` should remove the previous values. Renamed the methods into `set.*`. ------------- PR: https://git.openjdk.java.net/jdk/pull/3508 From chagedorn at openjdk.java.net Tue Apr 20 13:41:09 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Tue, 20 Apr 2021 13:41:09 GMT Subject: RFR: 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests [v2] In-Reply-To: References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> Message-ID: On Mon, 19 Apr 2021 16:59:45 GMT, Igor Ignatyev wrote: >> Maybe first some general background about having a whitelist/blacklist in the first place. When a user writes an `@IR` rule, we do not want him to think about any possible VM flag combination (which he is not specifically using in his test, for example with `addFlags`) that could break his `@IR` rule and then requiring him to restrict the `@IR` rule with `IR::applyIfXX()` for these flags. >> >> I agree that the whitelist is probably not complete and could be improved (but I think we should not whitelist different GCs as these affect the barrier code of the IR). About whitelist vs. blacklist, I had discussions about it with @TobiHartmann. We eventually decided to use a whitelist which seemed easier to maintain and is probably a lot shorter than a blacklist. In addition, if a new flag is introduced or removed, we most likely do not need to worry about updating the whitelist as the (currently) whitelisted flags will most likely remain unchanged. This first whitelist version is also just a best guess solution. We might miss on some other flags that will not affect the IR but we have the confidence that we do not run into surprising failures due to forgetting to blacklist a particular flag. But this is open for discussion of course. It would be interesting to hear how people think about it. > > I'll need to think about it a bit more, but my first impression after reading your comment is that we don't actually want to allow any flags, so we might better off just using `@requies vm.flagless` or reusing the underlying code to check that we don't have any flags that can "significantly" change behavior. Our idea was to only restrict the IR verification done after the test VM terminates with the whitelist (or blacklist). But the framework should still run each test with any flag combination. This showed to be quite useful in Valhalla to find bugs. >> I think we should keep it for the cases when a user wants a more specific setup for his tests in the calling test class. For example, if he wants to define a new default warm-up for all of his tests (using `setDefaultWarmup`) or if he needs to combine different options for which there is no `runXX` method (helper classes, scenarios, and/or flags). In this case, he needs to create a `TestFramework()` builder and then call the different builder methods. We could argue that a single constructor is enough in which the test class needs to be specified. But I think most of the time, the user wants to test the calling class for which this additional constructor is quite useful. > >> But I think most of the time, the user wants to test the calling class for which this additional constructor is quite useful. > > I concur that in most cases the users would want to use the caller as a `testClass`, yet we already have `run` and friends to cover that (most common) use-case, users who would need to construct fancier `TestFramework`, most probably, won't be doing it in their `testClass`, and if they would, the overhead of writing `new TestFramework(getClass())` is just 10 keystrokes and is neglatible (given the assumption of a more complicated use case) That is true. The entire test will probably look more complex in this case so it's probably reasonable to only provide the constructor with a class argument. However, if we are going to remove most of the (current) `runXX()` methods as discussed in a comment below, then keeping this parameterless constructor might be justified again? Anyhow, I'm fine with both. (Nit: when used from `main()` we would need to use `MyTestClass.class` instead of `getClass()`) >> I think you are probably right. I added this builder approach later during the development of the framework. It might be better to keep the `TestFramework` interface simple(r). However, I will wait for others to comment on that before changing/removing all of these. >> >> If we're gonna simplify it, I suggest to keep `run()` and maybe also `runWithFlags()` as (probably?) most common use-case. > >> I suggest to keep run() and maybe also runWithFlags() as (probably?) most common use-case. > > I guess you are right, `run()` and `runWithFlags(String[])` will be most-commonly used ones. Sounds good. Will do these changes if others agree. >> I will address all `\n` in a separate commit as there are a lot of them. Could I also just use `System.lineSeparator()` anywhere where I'm currently using `\n` like `System.err.println(System.lineSeparator() + e.getExceptionInfo()`)? Might be easier when I'm using `\n` with a `StringBuilder`, for example. > > sure you case use `System.lineSeparator()`, it's just a matter of personal choice/style ?? I fixed them. >> I guess it's not necessary. Removed it. > > ?? . I noticed that you have leading `\n` in other exceptions, do you plan to remove it from there as well? Sometimes, I found the resulting format of the error message nicer with the additional new lines. For example the exception at [L940](https://github.com/openjdk/jdk/blob/a563fb33ead7d2c8c9a5266d7187c956327281b2/test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java#L940): JavaTest Message: Test threw exception: jdk.test.lib.hotspot.ir_framework.TestFormatException: Violations (1) -------------- - Cannot use explicit compile command annotations ... vs. no new lines: JavaTest Message: Test threw exception: jdk.test.lib.hotspot.ir_framework.TestFormatException: Violations (1) -------------- - Cannot use explicit compile command annotations ... I will check the other exceptions again if they really need the new lines or not. >> I wanted to distinguish the following cases (but I'm open to use a different approach): >> >> - `TestFormat::check` (using `TestFormatException`): The format of any test/helper class does not conform with the format the framework is expecting. The user needs to fix this (for example, using a wrong annotation). I report these kind of failures before actually running any of the tests [here](https://github.com/openjdk/jdk/blob/7ed789dc98691d7c7fc2295e045a9f54b9fa6277/test/lib/jdk/test/lib/hotspot/ir_framework/TestFrameworkExecution.java#L265). >> - `TestRun::check` (using `TestRunException`): Thrown while the framework is [executing a test](https://github.com/openjdk/jdk/blob/7ed789dc98691d7c7fc2295e045a9f54b9fa6277/test/lib/jdk/test/lib/hotspot/ir_framework/TestFrameworkExecution.java#L799), there is nothing wrong with the format of a test. >> - `TestFramework::check` (using `TestFrameworkException`): If such a check fails there is a bug in the framework itself (like internal framework assertions). The user cannot really do anything about it without fixing the framework itself. >> >> I have to double check again if I'm using the right kind of exception everywhere. > > I understand that you want to use different exception types to distinguish different kinds of failures, I just don't see lots of benefits in have `::check` and `::fail` methods, they are just `if (p) throw new X(m)` or `throw new X(m)`. > > if, for example, you want `TestFrameworkException` to always have `Internal Test Framework exception - please file a bug`, you can prepend it in `TestFrameworkException::` I see your point. Having `fail` indeed does not add much benefit compared to just having `throw new XX` for `TestFramework` and `TestRun`. I replaced these `fail` methods with direct `throw new XX` statements and only kept the `check` methods. For `TestFormat`, I think it makes makes more sense to keep the `check` and `fail` methods as I'm also logging the failures and sometimes not even throwing an exception directly. ------------- PR: https://git.openjdk.java.net/jdk/pull/3508 From chagedorn at openjdk.java.net Tue Apr 20 13:41:09 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Tue, 20 Apr 2021 13:41:09 GMT Subject: RFR: 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests [v2] In-Reply-To: References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> Message-ID: <-IVxOwoxe3y80ESAqhDj9Ps1eslFee_G_qnt8igLQjs=.c2057599-cd95-4b71-8bbc-9b379581f0eb@github.com> On Mon, 19 Apr 2021 23:30:16 GMT, Igor Ignatyev wrote: >> Have I understood this correctly that you suggest to just remove this check completely and just specifying in the Javadocs that duplicates are ignore (due to using a `Set`)? > > you don't have to ignore duplicates, you can still throw an exception if you encounter one. I, personally, don't think we should force users to avoid dups (as I don't yet? see any issues w/ duplicated helpers), but if you think we need to enforce that *and* make it users' responsibilities then you should continue to throw an exception. in both cases, javadoc should be updated to reflect that duplicates are ignored or that an exception is raised in case a duplicate was encountered. >From a correctness point of view, it should not make a difference if a helper class is added twice. We will just apply all the annotations twice (enqueue a method for compilation, set a method to be not inlined etc.). But I think it's unnecessary work for the framework to walk through all methods and process them twice. So, I tend towards just ignoring dups without an exception and mention that in the Javadocs. ------------- PR: https://git.openjdk.java.net/jdk/pull/3508 From chagedorn at openjdk.java.net Tue Apr 20 13:41:09 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Tue, 20 Apr 2021 13:41:09 GMT Subject: RFR: 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests [v3] In-Reply-To: References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> Message-ID: <_h0p3wWDlBKQqd1Pjev89NtWoMBRWcllgcolvzYas3Q=.b32b6657-1caa-4a11-9388-7c4754f538de@github.com> On Mon, 19 Apr 2021 20:52:31 GMT, John Tortugo wrote: >> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: >> >> Apply review comments in code from Igor I. and Vladimir K. > > test/lib/jdk/test/lib/hotspot/ir_framework/README.md line 110: > >> 108: >> 109: The framework will spawn a new "test VM" to execute the user defined tests. The test VM collects all tests of the test class specified by the user code in `main()` and ensures that there is no violation of the required format by the framework. In a next step, the framework does the following for each test in general: >> 110: 1. Warm the test up for a predefined number of times (default 2000). This can also be adapted for all tests by using `testFrameworkobject.setDefaultWarmup(100)` or for individual tests with an additional [@Warmup](./doc/jdk/test/lib/hotspot/ir_framework/Warmup.html) annotation. > > The previous section seems to indicate that the default number of warm-up iterations is 200. "-Dwarmup=200". I added a comment in section 2.5 mentioning the framework default of 2000 to avoid confusions. ------------- PR: https://git.openjdk.java.net/jdk/pull/3508 From chagedorn at openjdk.java.net Tue Apr 20 13:42:17 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Tue, 20 Apr 2021 13:42:17 GMT Subject: RFR: 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests [v3] In-Reply-To: References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> Message-ID: On Mon, 19 Apr 2021 12:49:39 GMT, Christian Hagedorn wrote: >> This RFE provides an IR test framework to perform regex-based checks on the C2 IR shape of test methods emitted by the VM flags `-XX:+PrintIdeal` and `-XX:+PrintOptoAssembly`. The framework can also be used for other non-IR matching (and non-compiler) tests by providing easy to use annotations for commonly used testing patterns and compiler control flags. >> >> The framework is based on the ideas of the currently present IR test framework in [Valhalla](https://github.com/openjdk/valhalla/blob/e9c78ce4fcfd01361c35883e0d68f9ae5a80d079/test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypeTest.java) (mainly implemented by @TobiHartmann) which is being used with great success. This new framework aims to replace the old one in Valhalla at some point. >> >> A detailed description about how this new IR test framework works and how it is used is provided in the [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) file and in the [Javadocs](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc/jdk/test/lib/hotspot/ir_framework/package-summary.html) written for the framework classes. >> >> To finish a first version of this framework for JDK 17, I decided to leave some improvement possibilities and ideas to be followed up on in additional RFEs. Some ideas are mentioned in "Future Work" in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) and were also created as subtasks of this RFE. >> >> Testing (also described in "Internal Framework Tests in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md)): >> There are various tests to verify the correctness of the test framework which can be found as JTreg tests in the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) folder. Additional testing was performed by converting all compiler Inline Types test of project Valhalla (done by @katyapav in [JDK-8263024](https://bugs.openjdk.java.net/browse/JDK-8263024)) that used the old framework to the new framework. This provided additional testing for the framework itself. We ran the converted tests with all the flag settings used in hs-tier1-9 and hs-precheckin-comp. For sanity checking, this was also done with a sample IR test in mainline. >> >> Some stats about the framework code added to [ir_framework](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework): >> >> - without the [Javadocs files](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc) : 60 changed files, 13212 insertions, 0 deletions. >> - without the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) and [examples](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/examples) folder: 40 files changed, 6781 insertions >> - comments: 2399 insertions (calculated with `git diff --cached !(tests|examples) | grep -c -E "(^[+-]\s*(/)?*)|(^[+-]\s*//)"`) >> - which leaves 4382 lines of code inserted >> >> Big thanks to: >> - @TobiHartmann for all his help by discussing the new framework and for providing insights from his IR test framework in Valhalla. >> - @katyapav for converting the Valhalla tests to use the new framework which found some harder to catch bugs in the framework and also some actual C2 bugs. >> - @iignatev for helping to simplify the framework usage with JTreg and with the framework internal VM calling structure. >> - and others who provided valuable feedback. >> >> Thanks, >> Christian > > Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: > > Apply review comments in code from Igor I. and Vladimir K. > > > * although having javadoc for testlibraries is highly desirable, I don't think we should check in the generated HTML files > > > * the same goes for `README.html` generated from `README.md` > > > > > > Okay, I will remove them. Does it make sense to still have the HTML files somewhere in the web, for example, on my cr.openjdk? > > > * this library is hotspot-centric, I highly doubt that it will be used by any tests outside of the hotspot test base, hence the more appropriate location for it would be inside `test/hotspot/jtreg/testlibrary`. > > > * I assume `test/lib/jdk/test/lib/hotspot/ir_framework/tests/` are the tests for the framework, in that case they should be in `test/lib-test`, if we stick to `test/lib` as the location for the library, or in `test/hotspot/jtreg/testlibrary_tests`, if we move it to `test/hotspot` > > > > > > That makes sense to move everything to `test/hotspot/jtreg/testlibrary`. Right, the `test/lib/jdk/test/lib/hotspot/ir_framework/tests/` are only tests for the framework itself and should not be run as part of tier testing each time (does not make much sense) but only when the framework is actually modified. Is this still the case when putting them in `test/hotspot/jtreg/testlibrary_tests` (i.e. not executed unless run manually)? > > `test/hotspot/jtreg/testlibrary_tests` are seldomly run as part of `:hotspot_misc` test group, yet I don't think it's an issue. the benefit of running testlibrary tests is to gain confidence that the tests which use these libraries are reliable. I'd also disagree that `ir_framework/tests` should be run _only_ when the framework is actually, they should also be run when its dependencies are changed, and the framework highly depends on hotspot, so to be sure that the framework didn't get broken after changes in c2, whitebox, etc, you do need run these tests more often. I see your point. I have not considered the dependencies which can frequently change even though the framework does not. I therefore agree with you that we should run them at least from time to time. I will move everything to `test/hotspot/jtreg/testlibrary` in a next step. ------------- PR: https://git.openjdk.java.net/jdk/pull/3508 From chagedorn at openjdk.java.net Tue Apr 20 13:52:13 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Tue, 20 Apr 2021 13:52:13 GMT Subject: RFR: 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests [v5] In-Reply-To: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> Message-ID: > This RFE provides an IR test framework to perform regex-based checks on the C2 IR shape of test methods emitted by the VM flags `-XX:+PrintIdeal` and `-XX:+PrintOptoAssembly`. The framework can also be used for other non-IR matching (and non-compiler) tests by providing easy to use annotations for commonly used testing patterns and compiler control flags. > > The framework is based on the ideas of the currently present IR test framework in [Valhalla](https://github.com/openjdk/valhalla/blob/e9c78ce4fcfd01361c35883e0d68f9ae5a80d079/test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypeTest.java) (mainly implemented by @TobiHartmann) which is being used with great success. This new framework aims to replace the old one in Valhalla at some point. > > A detailed description about how this new IR test framework works and how it is used is provided in the [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) file and in the [Javadocs](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc/jdk/test/lib/hotspot/ir_framework/package-summary.html) written for the framework classes. > > To finish a first version of this framework for JDK 17, I decided to leave some improvement possibilities and ideas to be followed up on in additional RFEs. Some ideas are mentioned in "Future Work" in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) and were also created as subtasks of this RFE. > > Testing (also described in "Internal Framework Tests in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md)): > There are various tests to verify the correctness of the test framework which can be found as JTreg tests in the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) folder. Additional testing was performed by converting all compiler Inline Types test of project Valhalla (done by @katyapav in [JDK-8263024](https://bugs.openjdk.java.net/browse/JDK-8263024)) that used the old framework to the new framework. This provided additional testing for the framework itself. We ran the converted tests with all the flag settings used in hs-tier1-9 and hs-precheckin-comp. For sanity checking, this was also done with a sample IR test in mainline. > > Some stats about the framework code added to [ir_framework](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework): > > - without the [Javadocs files](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc) : 60 changed files, 13212 insertions, 0 deletions. > - without the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) and [examples](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/examples) folder: 40 files changed, 6781 insertions > - comments: 2399 insertions (calculated with `git diff --cached !(tests|examples) | grep -c -E "(^[+-]\s*(/)?*)|(^[+-]\s*//)"`) > - which leaves 4382 lines of code inserted > > Big thanks to: > - @TobiHartmann for all his help by discussing the new framework and for providing insights from his IR test framework in Valhalla. > - @katyapav for converting the Valhalla tests to use the new framework which found some harder to catch bugs in the framework and also some actual C2 bugs. > - @iignatev for helping to simplify the framework usage with JTreg and with the framework internal VM calling structure. > - and others who provided valuable feedback. > > Thanks, > Christian Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: Remove Javadocs and README.html, update README.md to reference java files instead of html files ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3508/files - new: https://git.openjdk.java.net/jdk/pull/3508/files/433006c5..72eece63 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3508&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3508&range=03-04 Stats: 11647 lines in 86 files changed: 0 ins; 11635 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/3508.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3508/head:pull/3508 PR: https://git.openjdk.java.net/jdk/pull/3508 From sjohanss at openjdk.java.net Tue Apr 20 14:11:28 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Tue, 20 Apr 2021 14:11:28 GMT Subject: RFR: 8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v27] In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 16:38:02 GMT, Marcus G K Williams wrote: >> When using LargePageSizeInBytes=1G, os::Linux::reserve_memory_special_huge_tlbfs* cannot select large pages smaller than 1G. Code heap usually uses less than 1G, so currently the code precludes code heap from using >> Large pages in this circumstance and when os::Linux::reserve_memory_special_huge_tlbfs* is called page sizes fall back to Linux::page_size() (usually 4k). >> >> This change allows the above use case by populating all large_page_sizes present in /sys/kernel/mm/hugepages in _page_sizes upon calling os::Linux::setup_large_page_size(). >> >> In os::Linux::reserve_memory_special_huge_tlbfs* we then select the largest large page size available in _page_sizes that is smaller than bytes being reserved. > > Marcus G K Williams has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 44 commits: > > - Merge branch 'master' into update_hlp > - Rebase on pull/3073 > > Signed-off-by: Marcus G K Williams > - Merge branch 'pull/3073' into update_hlp > - Thomas review. > > Changed commit_memory_special to return bool to signal if the request succeeded or not. > - Self review. > > Update helper name to better match commit_memory_special(). > - Marcus review. > > Updated comments. > - Ivan review > > Renamed helper to commit_memory_special and updated the comments. > - 8262291: Refactor reserve_memory_special_huge_tlbfs > - Merge branch 'master' into update_hlp > - Addressed kstefanj review suggestions > > Signed-off-by: Marcus G K Williams > - ... and 34 more: https://git.openjdk.java.net/jdk/compare/f60e81bf...f5bfe224 Just created a CSR for this: [JDK-8265517](https://bugs.openjdk.java.net/browse/JDK-8265517) Please take a look at it and provide feedback if you have any. @mgkwill, please update the patch with the text from the CSR for `LargePageSizeInBytes`. ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From stuefe at openjdk.java.net Tue Apr 20 14:45:07 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 20 Apr 2021 14:45:07 GMT Subject: RFR: JDK-8155004: CrashOnOutOfMemoryError doesn't work for OOM caused by inability to create threads In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 10:52:26 GMT, Thomas Stuefe wrote: > Greetings, > > this is an old issue and I'd like to fix it. If we fail to create a java thread due to platform limitations we throw an OOM. But we fail to honor the various xxxOnOutOfMemoryError switches. > > The fix is very straightforward. > > One remaining question, maybe for a future RFE, is how we want to handle native threads creation error. AFAICS currently, failing to create a native thread may or may not result in a fatal shutdown, a log output, or just be ignored, depending on the thread. > > If `...OnOutOfMemoryError` is specified, should native thread creation failure be handled the same way as a java thread? > > - No if I take the option name literally, since there is no OOM involved > - Yes if I take into account what these switches are actually used for - analysis or quick shutdown of a JVM inside a container in case of an OOM. Since it is completely random which thread is hit by the limit. > > Thanks, Thomas I would fix it because its a well known and documented way to handle OOMs in a VM. In fact its much better known than AbortVMOnException, and has been around for much longer. People use these switches, expect them to work, but they don't. Other reasons include: - maybe the customer does not want to crash but just a clean exit - maybe the customer wants to have a heap dump to take a look at who created that many java threads - Fix is really really simple Thanks, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/3586 From github.com+168222+mgkwill at openjdk.java.net Tue Apr 20 14:46:04 2021 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Tue, 20 Apr 2021 14:46:04 GMT Subject: RFR: 8265491: Math Signum optimization for x86 In-Reply-To: References: Message-ID: <6mLapx2FtNNrgyWDg8lmrumY1JIZpPEDZ6UHbGu-btM=.784d8a12-15c5-495d-80cc-33d379ddd4be@github.com> On Tue, 20 Apr 2021 08:38:14 GMT, Jatin Bhateja wrote: > @mgkwill, your newly added benchmark has 4 micro worklets, please publish the results for all of them. @jatin-bhateja Certainly. Omission was an oversight. I've updated the description of the pull request with overhead results. ------------- PR: https://git.openjdk.java.net/jdk/pull/3581 From stuefe at openjdk.java.net Tue Apr 20 14:53:05 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 20 Apr 2021 14:53:05 GMT Subject: RFR: JDK-8155004: CrashOnOutOfMemoryError doesn't work for OOM caused by inability to create threads In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 10:52:26 GMT, Thomas Stuefe wrote: > Greetings, > > this is an old issue and I'd like to fix it. If we fail to create a java thread due to platform limitations we throw an OOM. But we fail to honor the various xxxOnOutOfMemoryError switches. > > The fix is very straightforward. > > One remaining question, maybe for a future RFE, is how we want to handle native threads creation error. AFAICS currently, failing to create a native thread may or may not result in a fatal shutdown, a log output, or just be ignored, depending on the thread. > > If `...OnOutOfMemoryError` is specified, should native thread creation failure be handled the same way as a java thread? > > - No if I take the option name literally, since there is no OOM involved > - Yes if I take into account what these switches are actually used for - analysis or quick shutdown of a JVM inside a container in case of an OOM. Since it is completely random which thread is hit by the limit. > > Thanks, Thomas p.s. I do not understand your quotes around "bug", nor your hesitance to fix this. I have seen quite a number of desperate setups customers have around crashy or OOMy JVMs, to analyse and to restart quickly. Anything in that area we can do helps. One example, take a look at the way CloudFoundry handles OOMs in a JVM. They have a JVMTI agent hooked up to resource-exhausted, then attempt to run analysis code (written in Java too) to dump the heap. This is so fragile. xxxOnOutOfMemoryError could really help in these scenarios, if it would function reliably. ------------- PR: https://git.openjdk.java.net/jdk/pull/3586 From jiefu at openjdk.java.net Tue Apr 20 15:00:08 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Tue, 20 Apr 2021 15:00:08 GMT Subject: RFR: 8265491: Math Signum optimization for x86 In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 23:00:47 GMT, Marcus G K Williams wrote: > x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM. > > We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization. > > Base: > Benchmark Mode Cnt Score Error Units > Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op > Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op > Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op > Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op > > Optimized: > signum intrinsic patch > Benchmark Mode Cnt Score Error Units > Signum._1_signumFloatTest avgt 5 3.782 ? 0.019 ns/op > Signum._2_overheadFloat avgt 5 3.309 ? 0.011 ns/op > Signum._3_signumDoubleTest avgt 5 3.782 ? 0.017 ns/op > Signum._4_overheadDouble avgt 5 3.310 ? 0.006 ns/op > > Signed-off-by: Marcus G K Williams test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java line 28: > 26: * @test > 27: * @summary Test compiler intrinsics for signum > 28: * @requires os.arch=="aarch64" | os.arch=="x86" | os.arch=="amd64" | os.arch=="x86_64" What about os.arch=="i386" ? ------------- PR: https://git.openjdk.java.net/jdk/pull/3581 From github.com+168222+mgkwill at openjdk.java.net Tue Apr 20 15:06:41 2021 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Tue, 20 Apr 2021 15:06:41 GMT Subject: RFR: 8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v28] In-Reply-To: References: Message-ID: > Change the meaning of LargePageSizeInBytes to be the maximum large page size the JVM may use (not the only one). A default value of zero will mean to allow the JVM use large page sizes up to the system's default large page size. Marcus G K Williams has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 46 commits: - Fix merge Signed-off-by: Marcus G K Williams - Merge branch 'master' into update_hlp - Merge branch 'master' into update_hlp - Rebase on pull/3073 Signed-off-by: Marcus G K Williams - Merge branch 'pull/3073' into update_hlp - Thomas review. Changed commit_memory_special to return bool to signal if the request succeeded or not. - Self review. Update helper name to better match commit_memory_special(). - Marcus review. Updated comments. - Ivan review Renamed helper to commit_memory_special and updated the comments. - 8262291: Refactor reserve_memory_special_huge_tlbfs - ... and 36 more: https://git.openjdk.java.net/jdk/compare/713483c7...f99fd5dd ------------- Changes: https://git.openjdk.java.net/jdk/pull/1153/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1153&range=27 Stats: 134 lines in 3 files changed: 64 ins; 47 del; 23 mod Patch: https://git.openjdk.java.net/jdk/pull/1153.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1153/head:pull/1153 PR: https://git.openjdk.java.net/jdk/pull/1153 From github.com+168222+mgkwill at openjdk.java.net Tue Apr 20 15:14:12 2021 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Tue, 20 Apr 2021 15:14:12 GMT Subject: RFR: 8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v27] In-Reply-To: References: Message-ID: <_ltdF3SwIhzoZ5GhSiK2r3mUHLDApXaCVY78sk1gr9M=.c16cf61f-fe99-4610-abb3-9798d6d19053@github.com> On Tue, 20 Apr 2021 14:07:48 GMT, Stefan Johansson wrote: > Just created a CSR for this: [JDK-8265517](https://bugs.openjdk.java.net/browse/JDK-8265517) > Please take a look at it and provide feedback if you have any. > > @mgkwill, please update the patch with the text from the CSR for `LargePageSizeInBytes`. Thanks for creating the CSR @stefank! I've read through it and it looks reasonable to me. I've changed the text of the summary of this patch to match the summary of the CSR. Please let me know if more context from the CSR is needed. A modification of the code is needed to accomplish what @tstuefe suggested: > Default (`LargePageSizeInBytes=0`) > * old behavior - use the systems default large page size > * new behavior - use all configured page sizes up to and including the systems default large page size I'll update with a suggested route in the next couple of days. ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From github.com+168222+mgkwill at openjdk.java.net Tue Apr 20 15:28:43 2021 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Tue, 20 Apr 2021 15:28:43 GMT Subject: RFR: 8265491: Math Signum optimization for x86 [v2] In-Reply-To: References: Message-ID: > x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM. > > We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization. > > Base: > Benchmark Mode Cnt Score Error Units > Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op > Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op > Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op > Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op > > Optimized: > signum intrinsic patch > Benchmark Mode Cnt Score Error Units > Signum._1_signumFloatTest avgt 5 3.782 ? 0.019 ns/op > Signum._2_overheadFloat avgt 5 3.309 ? 0.011 ns/op > Signum._3_signumDoubleTest avgt 5 3.782 ? 0.017 ns/op > Signum._4_overheadDouble avgt 5 3.310 ? 0.006 ns/op > > Signed-off-by: Marcus G K Williams Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision: Add os.arch=="i386" to signum jtreg Signed-off-by: Marcus G K Williams ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3581/files - new: https://git.openjdk.java.net/jdk/pull/3581/files/e461edc7..99a2971d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3581&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3581&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3581.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3581/head:pull/3581 PR: https://git.openjdk.java.net/jdk/pull/3581 From github.com+168222+mgkwill at openjdk.java.net Tue Apr 20 15:28:48 2021 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Tue, 20 Apr 2021 15:28:48 GMT Subject: RFR: 8265491: Math Signum optimization for x86 [v2] In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 14:57:09 GMT, Jie Fu wrote: >> Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision: >> >> Add os.arch=="i386" to signum jtreg >> >> Signed-off-by: Marcus G K Williams > > test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java line 28: > >> 26: * @test >> 27: * @summary Test compiler intrinsics for signum >> 28: * @requires os.arch=="aarch64" | os.arch=="x86" | os.arch=="amd64" | os.arch=="x86_64" > > What about os.arch=="i386" ? @DamonFool, I wasn't sure about `os.arch=="i386"`. I'm still getting my head around os.arch and how it is used in these tests. I'll add it to the jtreg. ------------- PR: https://git.openjdk.java.net/jdk/pull/3581 From stuefe at openjdk.java.net Tue Apr 20 15:38:12 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 20 Apr 2021 15:38:12 GMT Subject: RFR: 8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v27] In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 14:07:48 GMT, Stefan Johansson wrote: >> Marcus G K Williams has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 44 commits: >> >> - Merge branch 'master' into update_hlp >> - Rebase on pull/3073 >> >> Signed-off-by: Marcus G K Williams >> - Merge branch 'pull/3073' into update_hlp >> - Thomas review. >> >> Changed commit_memory_special to return bool to signal if the request succeeded or not. >> - Self review. >> >> Update helper name to better match commit_memory_special(). >> - Marcus review. >> >> Updated comments. >> - Ivan review >> >> Renamed helper to commit_memory_special and updated the comments. >> - 8262291: Refactor reserve_memory_special_huge_tlbfs >> - Merge branch 'master' into update_hlp >> - Addressed kstefanj review suggestions >> >> Signed-off-by: Marcus G K Williams >> - ... and 34 more: https://git.openjdk.java.net/jdk/compare/f60e81bf...f5bfe224 > > Just created a CSR for this: [JDK-8265517](https://bugs.openjdk.java.net/browse/JDK-8265517) > Please take a look at it and provide feedback if you have any. > > @mgkwill, please update the patch with the text from the CSR for `LargePageSizeInBytes`. Hi @kstefanj, (@mgkwill : there are multiple Stefans, it can get confusing) CSR looks good overall. Thanks for doing this. I comment here to give Marcus a way to participate (not sure if he has JBS access). Some points: - does it have to have the same title as the issue it is associated with? A title like "Change definition of LargePageSizeInBytes" would be easier to understand and search for. - Can the CSR please state that it only affects Linux? Side note, I had a look at the Windows implementation. It processes LargePageSizeInBytes, but I am not sure it has any effect. On Windows, one obtains the "minimum large page size" and uses that value to align the size requested from VirtualAlloc. Thats it, there is no way to specify an explicit large page size when reserving. LargePageSizeInBytes overwrites this "minimum large page size", but all this does is it somewhat affects the allocated size. So it may be that we could just remove this switch from Windows altogether. - "The Java man pages already defines " -> "The Java man page already defines " - Do we allow explicit -XX:LargePageSizeInBytes=0 ? Seems somewhat pointless. Do we handle it today? Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From github.com+168222+mgkwill at openjdk.java.net Tue Apr 20 15:54:11 2021 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Tue, 20 Apr 2021 15:54:11 GMT Subject: RFR: 8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v27] In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 14:07:48 GMT, Stefan Johansson wrote: >> Marcus G K Williams has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 44 commits: >> >> - Merge branch 'master' into update_hlp >> - Rebase on pull/3073 >> >> Signed-off-by: Marcus G K Williams >> - Merge branch 'pull/3073' into update_hlp >> - Thomas review. >> >> Changed commit_memory_special to return bool to signal if the request succeeded or not. >> - Self review. >> >> Update helper name to better match commit_memory_special(). >> - Marcus review. >> >> Updated comments. >> - Ivan review >> >> Renamed helper to commit_memory_special and updated the comments. >> - 8262291: Refactor reserve_memory_special_huge_tlbfs >> - Merge branch 'master' into update_hlp >> - Addressed kstefanj review suggestions >> >> Signed-off-by: Marcus G K Williams >> - ... and 34 more: https://git.openjdk.java.net/jdk/compare/f60e81bf...f5bfe224 > > Just created a CSR for this: [JDK-8265517](https://bugs.openjdk.java.net/browse/JDK-8265517) > Please take a look at it and provide feedback if you have any. > > @mgkwill, please update the patch with the text from the CSR for `LargePageSizeInBytes`. > Hi @kstefanj, > > (@mgkwill : there are multiple Stefans, it can get confusing) Thanks for including me @tstuefe and noting the highlighting of the wrong Stefan. Whoops :P . Updated. > > CSR looks good overall. Thanks for doing this. I comment here to give Marcus a way to participate (not sure if he has JBS access). Some points: > I don't have access yet. Still working towards my authorship. I have a few patches in but not sure of the threshold/process. > * does it have to have the same title as the issue it is associated with? A title like "Change definition of LargePageSizeInBytes" would be easier to understand and search for. +1 > * Can the CSR please state that it only affects Linux? > +1 > Side note, I had a look at the Windows implementation. It processes LargePageSizeInBytes, but I am not sure it has any effect. On Windows, one obtains the "minimum large page size" and uses that value to align the size requested from VirtualAlloc. Thats it, there is no way to specify an explicit large page size when reserving. LargePageSizeInBytes overwrites this "minimum large page size", but all this does is it somewhat affects the allocated size. So it may be that we could just remove this switch from Windows altogether. > Can this be handled in the same CSR? > * "The Java man pages already defines " -> "The Java man page already defines " +1 > * Do we allow explicit -XX:LargePageSizeInBytes=0 ? Seems somewhat pointless. Do we handle it today? Default is `LargePageSizeInBytes=0` - so it seems we would treat `-XX:LargePageSizeInBytes=0` as the same as default. We don't have a specific case for 0 except default handling as far as I can see. ` product(size_t, LargePageSizeInBytes, 0, \ "Large page size (0 to let VM choose the page size)") \ range(0, max_uintx) \ ` > > Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From egahlin at openjdk.java.net Tue Apr 20 15:58:06 2021 From: egahlin at openjdk.java.net (Erik Gahlin) Date: Tue, 20 Apr 2021 15:58:06 GMT Subject: Integrated: 8265036: JFR: Remove use of -XX:StartFlightRecording= and -XX:FlightRecorderOptions= In-Reply-To: References: Message-ID: <-SX_kKhJgQjALbNUDSfjyWa5IETaK5rUHwewSUm7zhg=.9c50555e-5afc-4499-a39a-d6ff860cfd6c@github.com> On Sun, 18 Apr 2021 15:17:35 GMT, Erik Gahlin wrote: > Hi, > > Could I have a review of fix that removes the use of "=" together with -XX:StartFlightRecording and -XX:FlightRecorderOptions. It's been possible to use "-XX:StartFlightRecording:" and "-XX:FlightRecorderOption:" since JFR was introduced into OpenJDK (JDK 11), so this is not a change of the specification, just an update to make the use consistent in tests, comments, documentation etc. > > I also removed the use of -XX:+FlightRecorder, which is not needed, and has been deprecated since JDK 13. > > Testing: jdk/jdk/jfr, tier 1-4. > > Thanks > Erik This pull request has now been integrated. Changeset: 4dcaac1f Author: Erik Gahlin URL: https://git.openjdk.java.net/jdk/commit/4dcaac1f Stats: 104 lines in 40 files changed: 0 ins; 0 del; 104 mod 8265036: JFR: Remove use of -XX:StartFlightRecording= and -XX:FlightRecorderOptions= Reviewed-by: cjplummer ------------- PR: https://git.openjdk.java.net/jdk/pull/3561 From iklam at openjdk.java.net Tue Apr 20 17:03:07 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 20 Apr 2021 17:03:07 GMT Subject: RFR: 8265411: Avoid unnecessary Method::init_intrinsic_id calls In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 05:19:56 GMT, David Holmes wrote: > Hi Ioi, > > That all appears fine to me. > > Is there any startup impact? > > Thanks, > David Hi David, when CDS is turned off, I can see a small improvement in start-up, due to the reduction in intrinsic ID lookup: $ perf stat -r 100 bin/java -Xshare:off -Xint -version OLD: 191,632,128 cycles 0.074624 sec NEW: 191,387,603 cycles 0.073704 sec With CDS enabled, the intrinsic ID lookup is done during archive dump time, so this PR makes no difference. Also, the lookup table itself is generated during C++ compilation, so it has no runtime impact: .section .rodata .type _ZL18_intrinsics_lookup, @object _ZL18_intrinsics_lookup: .byte 0 .byte 0 .byte 1 .byte 1 .... ------------- PR: https://git.openjdk.java.net/jdk/pull/3564 From chagedorn at openjdk.java.net Tue Apr 20 17:30:17 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Tue, 20 Apr 2021 17:30:17 GMT Subject: RFR: 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests [v2] In-Reply-To: References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> Message-ID: On Mon, 19 Apr 2021 15:34:27 GMT, Igor Ignatyev wrote: >>> * although having javadoc for testlibraries is highly desirable, I don't think we should check in the generated HTML files >>> * the same goes for `README.html` generated from `README.md` >> >> Okay, I will remove them. Does it make sense to still have the HTML files somewhere in the web, for example, on my cr.openjdk? >> >>> * this library is hotspot-centric, I highly doubt that it will be used by any tests outside of the hotspot test base, hence the more appropriate location for it would be inside `test/hotspot/jtreg/testlibrary`. >>> * I assume `test/lib/jdk/test/lib/hotspot/ir_framework/tests/` are the tests for the framework, in that case they should be in `test/lib-test`, if we stick to `test/lib` as the location for the library, or in `test/hotspot/jtreg/testlibrary_tests`, if we move it to `test/hotspot` >> >> That makes sense to move everything to `test/hotspot/jtreg/testlibrary`. Right, the `test/lib/jdk/test/lib/hotspot/ir_framework/tests/` are only tests for the framework itself and should not be run as part of tier testing each time (does not make much sense) but only when the framework is actually modified. Is this still the case when putting them in `test/hotspot/jtreg/testlibrary_tests` (i.e. not executed unless run manually)? >> >> I will do this things in a separate commit and adjust the README.md file accordingly (has links to the Javadoc files). > >> > * although having javadoc for testlibraries is highly desirable, I don't think we should check in the generated HTML files >> > * the same goes for `README.html` generated from `README.md` >> >> Okay, I will remove them. Does it make sense to still have the HTML files somewhere in the web, for example, on my cr.openjdk? >> >> > * this library is hotspot-centric, I highly doubt that it will be used by any tests outside of the hotspot test base, hence the more appropriate location for it would be inside `test/hotspot/jtreg/testlibrary`. >> > * I assume `test/lib/jdk/test/lib/hotspot/ir_framework/tests/` are the tests for the framework, in that case they should be in `test/lib-test`, if we stick to `test/lib` as the location for the library, or in `test/hotspot/jtreg/testlibrary_tests`, if we move it to `test/hotspot` >> >> That makes sense to move everything to `test/hotspot/jtreg/testlibrary`. Right, the `test/lib/jdk/test/lib/hotspot/ir_framework/tests/` are only tests for the framework itself and should not be run as part of tier testing each time (does not make much sense) but only when the framework is actually modified. Is this still the case when putting them in `test/hotspot/jtreg/testlibrary_tests` (i.e. not executed unless run manually)? > > `test/hotspot/jtreg/testlibrary_tests` are seldomly run as part of `:hotspot_misc` test group, yet I don't think it's an issue. the benefit of running testlibrary tests is to gain confidence that the tests which use these libraries are reliable. I'd also disagree that `ir_framework/tests` should be run *only* when the framework is actually, they should also be run when its dependencies are changed, and the framework highly depends on hotspot, so to be sure that the framework didn't get broken after changes in c2, whitebox, etc, you do need run these tests more often. > > Thanks, > -- Igor There is no decision, yet, (and open for discussion) about the location and package name for the framework and the framework internal tests. After discussing it offline with @iignatev, we think there are basically two good options: 1. Leave the framework in `/test/lib` and put the framework internal tests into `/test/lib-test`: - Pros: Only need to specify `@library /test/lib` in a JTreg test; the framework internal tests are run in tier1 before any other tests are run which depend on the framework ensuring correctness. - Cons: Clarity: The framework is intended to be used for HotSpot tests only (thus not exactly the right location in `/test/lib`); the framework internal tests might be run too often as part of tier1 (trade-off ensuring correctness vs. execution time). 2. Move the framework to `/test/hotspot/jtreg/testlibrary`, put the framework internal tests into `/test/hotspot/jtreg/testlibrary_tests`, and use package name `hotspot.test.lib.ir_framework`: - Pros: Clarity: The framework is only used for HotSpot tests (mainly compiler tests but could also be used for other tests). - Cons: A JTreg test needs to additionally specify `/testlibrary/ir_framework` like `@library /testlibrary/ir_framework /test/lib`; the framework internal tests are run more seldomly as part of `:hotspot_misc` (trade-off, see cons of first option). What do others think about that? ------------- PR: https://git.openjdk.java.net/jdk/pull/3508 From minqi at openjdk.java.net Tue Apr 20 17:43:04 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 20 Apr 2021 17:43:04 GMT Subject: RFR: 8265411: Avoid unnecessary Method::init_intrinsic_id calls In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 05:52:02 GMT, Ioi Lam wrote: > `check_methods_for_intrinsics()` in classFileParser.cpp calls `Method::klass_id_for_intrinsics()` to see if a class has intrinsic methods. However, the latter returns any class whose name is included in `vmSymbols`. This causes many unnecessary calls to `Method::init_intrinsic_id()`. > > To fix this, we precompute the classes that are known to have intrinsics using `constexpr`. See `vmIntrinsics::class_has_intrinsics`. > > After the fix, when running `java -Xshare:off -version`, the number of classes initialized for intrinsics is reduced from 130 to 30. > > Testing: mach5 tiers 1~4 passed. LGTM, thanks for fixing this! ------------- Marked as reviewed by minqi (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3564 From iklam at openjdk.java.net Tue Apr 20 18:15:39 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 20 Apr 2021 18:15:39 GMT Subject: RFR: 8265411: Avoid unnecessary Method::init_intrinsic_id calls [v2] In-Reply-To: References: Message-ID: > `check_methods_for_intrinsics()` in classFileParser.cpp calls `Method::klass_id_for_intrinsics()` to see if a class has intrinsic methods. However, the latter returns any class whose name is included in `vmSymbols`. This causes many unnecessary calls to `Method::init_intrinsic_id()`. > > To fix this, we precompute the classes that are known to have intrinsics using `constexpr`. See `vmIntrinsics::class_has_intrinsics`. > > After the fix, when running `java -Xshare:off -version`, the number of classes initialized for intrinsics is reduced from 130 to 30. > > Testing: mach5 tiers 1~4 passed. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into 8265411-avoid-unnecessary-method-init-intrinsic-id - more fixes - Improve vmIntrinsics with constexpr ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3564/files - new: https://git.openjdk.java.net/jdk/pull/3564/files/eb8e0bf6..f4857a66 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3564&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3564&range=00-01 Stats: 5993 lines in 210 files changed: 3199 ins; 2216 del; 578 mod Patch: https://git.openjdk.java.net/jdk/pull/3564.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3564/head:pull/3564 PR: https://git.openjdk.java.net/jdk/pull/3564 From minqi at openjdk.java.net Tue Apr 20 18:15:39 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 20 Apr 2021 18:15:39 GMT Subject: RFR: 8265411: Avoid unnecessary Method::init_intrinsic_id calls In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 05:52:02 GMT, Ioi Lam wrote: > `check_methods_for_intrinsics()` in classFileParser.cpp calls `Method::klass_id_for_intrinsics()` to see if a class has intrinsic methods. However, the latter returns any class whose name is included in `vmSymbols`. This causes many unnecessary calls to `Method::init_intrinsic_id()`. > > To fix this, we precompute the classes that are known to have intrinsics using `constexpr`. See `vmIntrinsics::class_has_intrinsics`. > > After the fix, when running `java -Xshare:off -version`, the number of classes initialized for intrinsics is reduced from 130 to 30. > > Testing: mach5 tiers 1~4 passed. BTW, the the fix works for the problem: adding symbols to vmSymbols.hpp caused debug build failed due to this bug. ------------- PR: https://git.openjdk.java.net/jdk/pull/3564 From jbhateja at openjdk.java.net Tue Apr 20 18:40:09 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Tue, 20 Apr 2021 18:40:09 GMT Subject: RFR: 8265491: Math Signum optimization for x86 [v2] In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 15:28:43 GMT, Marcus G K Williams wrote: >> x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM. >> >> We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization. >> >> Base: >> Benchmark Mode Cnt Score Error Units >> Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op >> Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op >> Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op >> Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op >> >> Optimized: >> signum intrinsic patch >> Benchmark Mode Cnt Score Error Units >> Signum._1_signumFloatTest avgt 5 3.782 ? 0.019 ns/op >> Signum._2_overheadFloat avgt 5 3.309 ? 0.011 ns/op >> Signum._3_signumDoubleTest avgt 5 3.782 ? 0.017 ns/op >> Signum._4_overheadDouble avgt 5 3.310 ? 0.006 ns/op >> >> Signed-off-by: Marcus G K Williams > > Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision: > > Add os.arch=="i386" to signum jtreg > > Signed-off-by: Marcus G K Williams src/hotspot/cpu/x86/x86.ad line 5786: > 5784: ins_encode %{ > 5785: Label exit; > 5786: Can you kindly move this into a macro assembly routine. src/hotspot/cpu/x86/x86.ad line 5806: > 5804: Label exit; > 5805: > 5806: __ ucomisd($dst$$XMMRegister, $zero$$XMMRegister); Same as above, please create a macro assembly routine to capture it. ------------- PR: https://git.openjdk.java.net/jdk/pull/3581 From github.com+168222+mgkwill at openjdk.java.net Tue Apr 20 22:22:07 2021 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Tue, 20 Apr 2021 22:22:07 GMT Subject: RFR: 8265491: Math Signum optimization for x86 [v2] In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 08:30:43 GMT, Jatin Bhateja wrote: >> Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision: >> >> Add os.arch=="i386" to signum jtreg >> >> Signed-off-by: Marcus G K Williams > > src/hotspot/cpu/x86/x86.ad line 5786: > >> 5784: ins_encode %{ >> 5785: Label exit; >> 5786: > > Can you kindly move this into a macro assembly routine. Do you mean `instruct signumF_reg`? Please explain your reasoning for the proposed move. > src/hotspot/cpu/x86/x86.ad line 5806: > >> 5804: Label exit; >> 5805: >> 5806: __ ucomisd($dst$$XMMRegister, $zero$$XMMRegister); > > Same as above, please create a macro assembly routine to capture it. Do you mean `instruct signumD_reg`? Please explain your reasoning for the proposed move. ------------- PR: https://git.openjdk.java.net/jdk/pull/3581 From ysuenaga at openjdk.java.net Tue Apr 20 23:56:06 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Tue, 20 Apr 2021 23:56:06 GMT Subject: RFR: JDK-8155004: CrashOnOutOfMemoryError doesn't work for OOM caused by inability to create threads In-Reply-To: References: Message-ID: <1cWYnS5Buu5Qx8eL2wgMnTcAXKp5o9E7DLqQsHudbdE=.0eb2315f-f0e4-4739-8a50-cb17e14381e5@github.com> On Tue, 20 Apr 2021 14:50:21 GMT, Thomas Stuefe wrote: >> Greetings, >> >> this is an old issue and I'd like to fix it. If we fail to create a java thread due to platform limitations we throw an OOM. But we fail to honor the various xxxOnOutOfMemoryError switches. >> >> The fix is very straightforward. >> >> If fixes >> - CrashOnOutOfMemoryError >> - ExitOnOutOfMemoryError >> - HeapDumpOnOutOfMemoryError >> - and, in theory "OnOutOfMemoryError=". >> >> the latter only in theory because most of the times whatever prevented the thread to start up will also prevent the fork needed to get the user command running. >> >> One remaining question, maybe for a future RFE, is how we want to handle native threads creation error. AFAICS currently, failing to create a native thread may or may not result in a fatal shutdown, a log output, or just be ignored, depending on the thread. >> >> If `...OnOutOfMemoryError` is specified, should native thread creation failure be handled the same way as a java thread? >> >> - No if I take the option name literally, since there is no OOM involved >> - Yes if I take into account what these switches are actually used for - analysis or quick shutdown of a JVM inside a container in case of an OOM. Since it is completely random which thread is hit by the limit. >> >> Thanks, Thomas > > p.s. I do not understand your quotes around "bug", nor your hesitance to fix this. I have seen quite a number of desperate setups customers have around crashy or OOMy JVMs, to analyse and to restart quickly. Anything in that area we can do helps. > > One example, take a look at the way CloudFoundry handles OOMs in a JVM. They have a JVMTI agent hooked up to resource-exhausted, then attempt to run analysis code (written in Java too) to dump the heap. This is so fragile. > > xxxOnOutOfMemoryError could really help in these scenarios, if it would function reliably. Mostly agree with @tstuefe . I give +1 to this PR. I also have seen OOMs due to native thread creation, then I advised to watch the log to reboot the system quickly. (I've provided HeapStats to my customers to do it - it is JVMTI agent and similar way to CloudFoundry's agent) However I want to know why JVM ignores it now. Because JVM cannot work correctly if the error is caused by ENOMEM? ------------- PR: https://git.openjdk.java.net/jdk/pull/3586 From iklam at openjdk.java.net Wed Apr 21 01:46:10 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 21 Apr 2021 01:46:10 GMT Subject: RFR: 8265411: Avoid unnecessary Method::init_intrinsic_id calls [v2] In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 05:19:56 GMT, David Holmes wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Merge branch 'master' into 8265411-avoid-unnecessary-method-init-intrinsic-id >> - more fixes >> - Improve vmIntrinsics with constexpr > > Hi Ioi, > > That all appears fine to me. > > Is there any startup impact? > > Thanks, > David Thanks @dholmes-ora and @yminqi for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/3564 From iklam at openjdk.java.net Wed Apr 21 01:46:10 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 21 Apr 2021 01:46:10 GMT Subject: Integrated: 8265411: Avoid unnecessary Method::init_intrinsic_id calls In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 05:52:02 GMT, Ioi Lam wrote: > `check_methods_for_intrinsics()` in classFileParser.cpp calls `Method::klass_id_for_intrinsics()` to see if a class has intrinsic methods. However, the latter returns any class whose name is included in `vmSymbols`. This causes many unnecessary calls to `Method::init_intrinsic_id()`. > > To fix this, we precompute the classes that are known to have intrinsics using `constexpr`. See `vmIntrinsics::class_has_intrinsics`. > > After the fix, when running `java -Xshare:off -version`, the number of classes initialized for intrinsics is reduced from 130 to 30. > > Testing: mach5 tiers 1~4 passed. This pull request has now been integrated. Changeset: 739769c8 Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/739769c8 Stats: 54 lines in 5 files changed: 47 ins; 0 del; 7 mod 8265411: Avoid unnecessary Method::init_intrinsic_id calls Reviewed-by: dholmes, minqi ------------- PR: https://git.openjdk.java.net/jdk/pull/3564 From jiefu at openjdk.java.net Wed Apr 21 04:00:11 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 21 Apr 2021 04:00:11 GMT Subject: RFR: 8265491: Math Signum optimization for x86 [v2] In-Reply-To: References: Message-ID: <6q9w2ylkC6SGEN7-9WeO6qCXhEvNqO3JJAQHWx40GkM=.022014cb-b8e9-4f05-86e9-e855fe4cc6f0@github.com> On Tue, 20 Apr 2021 15:28:43 GMT, Marcus G K Williams wrote: >> x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM. >> >> We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization. >> >> Base: >> Benchmark Mode Cnt Score Error Units >> Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op >> Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op >> Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op >> Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op >> >> Optimized: >> signum intrinsic patch >> Benchmark Mode Cnt Score Error Units >> Signum._1_signumFloatTest avgt 5 3.782 ? 0.019 ns/op >> Signum._2_overheadFloat avgt 5 3.309 ? 0.011 ns/op >> Signum._3_signumDoubleTest avgt 5 3.782 ? 0.017 ns/op >> Signum._4_overheadDouble avgt 5 3.310 ? 0.006 ns/op >> >> Signed-off-by: Marcus G K Williams > > Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision: > > Add os.arch=="i386" to signum jtreg > > Signed-off-by: Marcus G K Williams src/hotspot/cpu/x86/x86.ad line 5780: > 5778: // --------------------------------- Signum --------------------------- > 5779: > 5780: instruct signumF_reg(regF dst, regF zero, regF one, rFlagsReg cr) %{ Do we need `predicate(UseSSE>=2);` here? src/hotspot/cpu/x86/x86.ad line 5788: > 5786: > 5787: __ ucomiss($dst$$XMMRegister, $zero$$XMMRegister); > 5788: __ jcc(Assembler::parity, exit); How about checking equal first and then parity? I think the unordered case is rare in real programs. src/hotspot/cpu/x86/x86.ad line 5792: > 5790: __ movflt($dst$$XMMRegister, $one$$XMMRegister); > 5791: __ jcc(Assembler::above, exit); > 5792: __ movflt($dst$$XMMRegister, $zero$$XMMRegister); Is it possible to use just one instruction to assign -1 to $dst? Maybe, you can try to follow negF_reg/negF_reg_reg. ------------- PR: https://git.openjdk.java.net/jdk/pull/3581 From stuefe at openjdk.java.net Wed Apr 21 04:19:03 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 21 Apr 2021 04:19:03 GMT Subject: RFR: JDK-8155004: CrashOnOutOfMemoryError doesn't work for OOM caused by inability to create threads In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 14:50:21 GMT, Thomas Stuefe wrote: >> Greetings, >> >> this is an old issue and I'd like to fix it. If we fail to create a java thread due to platform limitations we throw an OOM. But we fail to honor the various xxxOnOutOfMemoryError switches. >> >> The fix is very straightforward. >> >> If fixes >> - CrashOnOutOfMemoryError >> - ExitOnOutOfMemoryError >> - HeapDumpOnOutOfMemoryError >> - and, in theory "OnOutOfMemoryError=". >> >> the latter only in theory because most of the times whatever prevented the thread to start up will also prevent the fork needed to get the user command running. >> >> One remaining question, maybe for a future RFE, is how we want to handle native threads creation error. AFAICS currently, failing to create a native thread may or may not result in a fatal shutdown, a log output, or just be ignored, depending on the thread. >> >> If `...OnOutOfMemoryError` is specified, should native thread creation failure be handled the same way as a java thread? >> >> - No if I take the option name literally, since there is no OOM involved >> - Yes if I take into account what these switches are actually used for - analysis or quick shutdown of a JVM inside a container in case of an OOM. Since it is completely random which thread is hit by the limit. >> >> Thanks, Thomas > > p.s. I do not understand your quotes around "bug", nor your hesitance to fix this. I have seen quite a number of desperate setups customers have around crashy or OOMy JVMs, to analyse and to restart quickly. Anything in that area we can do helps. > > One example, take a look at the way CloudFoundry handles OOMs in a JVM. They have a JVMTI agent hooked up to resource-exhausted, then attempt to run analysis code (written in Java too) to dump the heap. This is so fragile. > > xxxOnOutOfMemoryError could really help in these scenarios, if it would function reliably. > Mostly agree with @tstuefe . I give +1 to this PR. I also have seen OOMs due to native thread creation, then I advised to watch the log to reboot the system quickly. > (I've provided HeapStats to my customers to do it - it is JVMTI agent and similar way to CloudFoundry's agent) > > However I want to know why JVM ignores it now. Because JVM cannot work correctly if the error is caused by ENOMEM? Its simply not implemented. The ...OnOutOfMemoryError handling needs to be added to places where OOM is thrown, and is missing from a couple of places. ------------- PR: https://git.openjdk.java.net/jdk/pull/3586 From minqi at openjdk.java.net Wed Apr 21 04:44:39 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 21 Apr 2021 04:44:39 GMT Subject: RFR: 8265393: VM crashes if both -XX:+RecordDynamicDumpInfo and -XX:SharedArchiveFile options are specified Message-ID: Hi, Please review 1) When the two flags -XX:+RecordDynamicDumpInfo and -XX:SharedArchiveFile used, in Arguments::init_shared_archive_paths() : if (DynamicDumpSharedSpaces) { if (os::same_files(SharedArchiveFile, ArchiveClassesAtExit)) { ... ArchiveClassesAtExit is NULL. C++ does not have a defined behavior of strcmp with strings of NULL. Posix version of os::same_files(const char* file1, const char* file2) calls strcmp without checking input args. This should be same as it is treated on Windows. 2) JCmdTest.java is fat and possible to cause test timeout. Split JCmdTest.java into two separate Tests: JCmdTestStaticDump.java and JCmdTestDynamicDump.java. 3) Add a test to check run with -XX:+RecordDynamicDumpInfo and -XX:SharedArchiveFile in JCmdTestDynamicDump.java The test does not use utility to create jvm process since it will take testing envs into process, but the way in the test using LingeredApp does not take envs. Tests: tier1,tier2,tier3,tier4 Thanks Yumin ------------- Commit messages: - 8265393: VM crashes if both -XX:+RecordDynamicDumpInfo and -XX:SharedArchiveFile options are specified Changes: https://git.openjdk.java.net/jdk/pull/3599/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3599&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265393 Stats: 933 lines in 5 files changed: 570 ins; 362 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3599.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3599/head:pull/3599 PR: https://git.openjdk.java.net/jdk/pull/3599 From kbarrett at openjdk.java.net Wed Apr 21 04:54:09 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Wed, 21 Apr 2021 04:54:09 GMT Subject: RFR: 8265101: Remove unnecessary functions in os*.inline.hpp In-Reply-To: <1nuLsyk3arkBvaLReeV9Y650aSRPNR5uwTTSUSFcz8E=.cf6a62e1-994e-4baf-9a5b-39ea86486719@github.com> References: <1nuLsyk3arkBvaLReeV9Y650aSRPNR5uwTTSUSFcz8E=.cf6a62e1-994e-4baf-9a5b-39ea86486719@github.com> Message-ID: <5vz0auyYhol5sA3eCPouF6IJ6C3JdEQeOMd-TFhPBgw=.45b3ece8-5641-4385-9633-6d8714d802cd@github.com> On Tue, 13 Apr 2021 20:11:35 GMT, Ioi Lam wrote: > Many functions like `os::write`, `os::exit`, `os::dll_unload`, etc, are implemented in various os*.inline.hpp files. This forces many .hpp and .cpp files to explicitly include "runtime/os.inline.hpp". > > There's no performance reason to inline these functions. They will make a system call, whose overhead is way bigger than the cost of making an extra function call. > > The full list methods moved from `os*inline.hpp` to `os_.cpp` are: > > > os::dll_unload(void *lib) > os::lseek(int fd, jlong offset, int whence) > os::fsync(int fd) > os::ftruncate(int fd, jlong length) > os::read(int fd, void *buf, unsigned int nBytes) > os::write(int fd, const void *buf, unsigned int nBytes) > os::close(int fd) > os::socket_close(int fd) > os::socket(int domain, int type, int protocol) > os::recv(int fd, char* buf, size_t nBytes, uint flags) > os::send(int fd, char* buf, size_t nBytes, uint flags) > os::raw_send(int fd, char* buf, size_t nBytes, uint flags) > os::connect(int fd, struct sockaddr* him, socklen_t len) > os::get_host_by_name(char* name) > os::exit(int num) > > > I also took this chance to remove unnecessary inclusion of os.hpp and os.inline.hpp from various files. I added some missing `#include` directives that were exposed as a result. > > - **Notes for Reviewers**: please start from os*.{hpp,cpp} files first. > - Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. Marked as reviewed by kbarrett (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3475 From iklam at openjdk.java.net Wed Apr 21 05:22:03 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 21 Apr 2021 05:22:03 GMT Subject: RFR: 8265393: VM crashes if both -XX:+RecordDynamicDumpInfo and -XX:SharedArchiveFile options are specified In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 04:38:14 GMT, Yumin Qi wrote: > Hi, Please review > 1) When the two flags -XX:+RecordDynamicDumpInfo and -XX:SharedArchiveFile used, in > Arguments::init_shared_archive_paths() : > if (DynamicDumpSharedSpaces) { > if (os::same_files(SharedArchiveFile, ArchiveClassesAtExit)) { > ... > ArchiveClassesAtExit is NULL. > C++ does not have a defined behavior of strcmp with strings of NULL. Posix version of os::same_files(const char* file1, const char* file2) calls strcmp without checking input args. This should be same as it is treated on Windows. > 2) JCmdTest.java is fat and possible to cause test timeout. Split JCmdTest.java into two separate Tests: JCmdTestStaticDump.java and JCmdTestDynamicDump.java. > 3) Add a test to check run with -XX:+RecordDynamicDumpInfo and -XX:SharedArchiveFile in JCmdTestDynamicDump.java > The test does not use utility to create jvm process since it will take testing envs into process, but the way in the test using LingeredApp does not take envs. > > Tests: tier1,tier2,tier3,tier4 > > Thanks > Yumin There's duplicated code between JCmdTestDynamicDump.java and JCmdTestStaticDump.java. I think these should be moved to a common base class. ------------- Changes requested by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3599 From jbhateja at openjdk.java.net Wed Apr 21 05:31:07 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Wed, 21 Apr 2021 05:31:07 GMT Subject: RFR: 8265491: Math Signum optimization for x86 [v2] In-Reply-To: References: Message-ID: <-Wq9ER4LeGazK0GmnIqjEhLzjGbWA_X_gYjN2Rog9zs=.dde56832-6a13-4f33-b2b2-e034fbec786f@github.com> On Tue, 20 Apr 2021 22:19:00 GMT, Marcus G K Williams wrote: >> src/hotspot/cpu/x86/x86.ad line 5786: >> >>> 5784: ins_encode %{ >>> 5785: Label exit; >>> 5786: >> >> Can you kindly move this into a macro assembly routine. > > Do you mean `instruct signumF_reg`? Please explain your reasoning for the proposed move. I am referring to moving the instruction sequence into a macro assembly routine for better code sharing, one should be enough for both float and double type, please refer to following snippet for more detail. https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L5672 ------------- PR: https://git.openjdk.java.net/jdk/pull/3581 From ysuenaga at openjdk.java.net Wed Apr 21 06:13:03 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 21 Apr 2021 06:13:03 GMT Subject: RFR: JDK-8155004: CrashOnOutOfMemoryError doesn't work for OOM caused by inability to create threads In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 04:16:19 GMT, Thomas Stuefe wrote: > Its simply not implemented. The ...OnOutOfMemoryError handling needs to be added to places where OOM is thrown, and is missing from a couple of places. Strictly speaking, we need to think about OOME from Java layer as well. For example, OOME would be thrown when direct buffer cannot allocate native memory (-XX:MaxDirectMemorySize). It is not caught by JVMTI ResourceExhausted event, however it might be important information to know system memory usage. I've found out similar issue on JFR, and I've posted #1403 , however it might not be accepted because C2 might eliminate throwing exceptions. IMHO *OnOutOfMemoryError, unified logging (-Xlog:exceptions), JVMTI event, JFR events should be hook all of OOMEs, they should be able to hook same source at least. ------------- PR: https://git.openjdk.java.net/jdk/pull/3586 From dholmes at openjdk.java.net Wed Apr 21 06:42:10 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 21 Apr 2021 06:42:10 GMT Subject: RFR: 8265491: Math Signum optimization for x86 [v2] In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 15:28:43 GMT, Marcus G K Williams wrote: >> x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM. >> >> We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization. >> >> Base: >> Benchmark Mode Cnt Score Error Units >> Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op >> Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op >> Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op >> Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op >> >> Optimized: >> signum intrinsic patch >> Benchmark Mode Cnt Score Error Units >> Signum._1_signumFloatTest avgt 5 3.782 ? 0.019 ns/op >> Signum._2_overheadFloat avgt 5 3.309 ? 0.011 ns/op >> Signum._3_signumDoubleTest avgt 5 3.782 ? 0.017 ns/op >> Signum._4_overheadDouble avgt 5 3.310 ? 0.006 ns/op >> >> Signed-off-by: Marcus G K Williams > > Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision: > > Add os.arch=="i386" to signum jtreg > > Signed-off-by: Marcus G K Williams test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java line 28: > 26: * @test > 27: * @summary Test compiler intrinsics for signum > 28: * @requires os.arch=="aarch64" | os.arch=="x86" | os.arch=="i386" | os.arch=="amd64" | os.arch=="x86_64" Shouldn't this test run successfully on all platforms, even if they don't do anything in response to UseSignumIntrinsic? I can run it today on x86_64. ------------- PR: https://git.openjdk.java.net/jdk/pull/3581 From stuefe at openjdk.java.net Wed Apr 21 06:53:22 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 21 Apr 2021 06:53:22 GMT Subject: RFR: JDK-8155004: CrashOnOutOfMemoryError doesn't work for OOM caused by inability to create threads In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 06:10:28 GMT, Yasumasa Suenaga wrote: > > Its simply not implemented. The ...OnOutOfMemoryError handling needs to be added to places where OOM is thrown, and is missing from a couple of places. > > Strictly speaking, we need to think about OOME from Java layer as well. For example, OOME would be thrown when direct buffer cannot allocate native memory (-XX:MaxDirectMemorySize). It is not caught by JVMTI ResourceExhausted event, however it might be important information to know system memory usage. > Please open a new issue for that, we can then discuss this separately. > I've found out similar issue on JFR, and I've posted #1403 , however it might not be accepted because C2 might eliminate throwing exceptions. IMHO *OnOutOfMemoryError, unified logging (-Xlog:exceptions), JVMTI event, JFR events should be hook all of OOMEs, they should be able to hook same source at least. Fully agree. In fact, I think semantically binding the switches to *OutOfMemoryError* is a design flaw, since you can have any number of resource bottlenecks where one might wish to restart the VM but which do not result in a OOM in java; one example is the creation of native threads by the VM. But that is a discussion for another day. We seem to have two opposite factions in this discussion. The "works as designed and leave it be" faction and the one wanting to cover as much resource exhaustion cases as possible by these switches. How do we proceed? ------------- PR: https://git.openjdk.java.net/jdk/pull/3586 From david.holmes at oracle.com Wed Apr 21 07:20:20 2021 From: david.holmes at oracle.com (David Holmes) Date: Wed, 21 Apr 2021 17:20:20 +1000 Subject: RFR: JDK-8155004: CrashOnOutOfMemoryError doesn't work for OOM caused by inability to create threads In-Reply-To: References: Message-ID: <045a0939-c5e7-3d1d-e2f9-cb95fdd7f7ca@oracle.com> Hi Thomas, On 21/04/2021 12:53 am, Thomas Stuefe wrote: > On Tue, 20 Apr 2021 10:52:26 GMT, Thomas Stuefe wrote: > >> Greetings, >> >> this is an old issue and I'd like to fix it. If we fail to create a java thread due to platform limitations we throw an OOM. But we fail to honor the various xxxOnOutOfMemoryError switches. >> >> The fix is very straightforward. >> >> One remaining question, maybe for a future RFE, is how we want to handle native threads creation error. AFAICS currently, failing to create a native thread may or may not result in a fatal shutdown, a log output, or just be ignored, depending on the thread. >> >> If `...OnOutOfMemoryError` is specified, should native thread creation failure be handled the same way as a java thread? >> >> - No if I take the option name literally, since there is no OOM involved >> - Yes if I take into account what these switches are actually used for - analysis or quick shutdown of a JVM inside a container in case of an OOM. Since it is completely random which thread is hit by the limit. >> >> Thanks, Thomas > > p.s. I do not understand your quotes around "bug", nor your hesitance to fix this. I have seen quite a number of desperate setups customers have around crashy or OOMy JVMs, to analyse and to restart quickly. Anything in that area we can do helps. My hesitance is because the intent of these flags is to provide a response for Java heap exhaustion, not to provide a response to every place that java.lang.OutOfMemoryError may be thrown. You've picked this one case of native thread exhaustion to add-in but that just makes it inconsistent. Why should that case be handled and not all the others? It is unfortunate that there is more than one way to read OutOfMemoryError, but it should be read as out-of-Java-heap-memory-error. We have had bug reports when someone uses this flag and their code does "throw new OutOfMemoryError() and they want to know why the VM didn't crash! I wouldn't object to a general broadening of what this flag applies to but I do object to cherry-picking a single case, resulting in the flag have no well-defined meaning at all. And per your latest email perhaps we need new generic flags for resource-exhaustion. Cheers, David ----- > One example, take a look at the way CloudFoundry handles OOMs in a JVM. They have a JVMTI agent hooked up to resource-exhausted, then attempt to run analysis code (written in Java too) to dump the heap. This is so fragile. > > xxxOnOutOfMemoryError could really help in these scenarios, if it would function reliably. > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3586 > From stuefe at openjdk.java.net Wed Apr 21 07:48:04 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 21 Apr 2021 07:48:04 GMT Subject: RFR: JDK-8155004: CrashOnOutOfMemoryError doesn't work for OOM caused by inability to create threads In-Reply-To: References: Message-ID: <4tfI8Yvvdah-xoHVzuwiWljN8mmG9JEqVLFm9EOllAw=.f126795a-1171-4510-93da-81b303e5c7b7@github.com> On Tue, 20 Apr 2021 10:52:26 GMT, Thomas Stuefe wrote: > Greetings, > > this is an old issue and I'd like to fix it. If we fail to create a java thread due to platform limitations we throw an OOM. But we fail to honor the various xxxOnOutOfMemoryError switches. > > The fix is very straightforward. > > If fixes > - CrashOnOutOfMemoryError > - ExitOnOutOfMemoryError > - HeapDumpOnOutOfMemoryError > - and, in theory "OnOutOfMemoryError=". > > the latter only in theory because most of the times whatever prevented the thread to start up will also prevent the fork needed to get the user command running. > > One remaining question, maybe for a future RFE, is how we want to handle native threads creation error. AFAICS currently, failing to create a native thread may or may not result in a fatal shutdown, a log output, or just be ignored, depending on the thread. > > If `...OnOutOfMemoryError` is specified, should native thread creation failure be handled the same way as a java thread? > > - No if I take the option name literally, since there is no OOM involved > - Yes if I take into account what these switches are actually used for - analysis or quick shutdown of a JVM inside a container in case of an OOM. Since it is completely random which thread is hit by the limit. > > Thanks, Thomas Hi David, (snip) > > p.s. I do not understand your quotes around "bug", nor your hesitance to fix this. I have seen quite a number of desperate setups customers have around crashy or OOMy JVMs, to analyse and to restart quickly. Anything in that area we can do helps. > > My hesitance is because the intent of these flags is to provide a > response for Java heap exhaustion, not to provide a response to every > place that java.lang.OutOfMemoryError may be thrown. You've picked this > one case of native thread exhaustion to add-in but that just makes it > inconsistent. Why should that case be handled and not all the others? It > is unfortunate that there is more than one way to read OutOfMemoryError, > but it should be read as out-of-Java-heap-memory-error. We have had bug > reports when someone uses this flag and their code does "throw new > OutOfMemoryError() and they want to know why the VM didn't crash! > > I wouldn't object to a general broadening of what this flag applies to > but I do object to cherry-picking a single case, resulting in the flag > have no well-defined meaning at all. > Okay, I understand your concern now better. If you do not object in principle to broadening of ..OnOutOfMemoryError to cover more cases, but just to the fact that this RFE only handles this one case of resource exhaustion, I think we have common ground. Both Yasumasa and me are fully in favour of making the ..OnOutOfMemoryError coverage as complete as possible. I would prefer to do this one RFE at a time, since that way we can put in work when we have free cycles, and these smaller patches are more easy to backport. Today ..OnOutOfMemoryError is invoked on OOM for both heap- and metaspace exhaustion, and AFAICS has been this way since at least jdk 11. So it is not consistently applied to java heap ooms only. > And per your latest email perhaps we need new generic flags for > resource-exhaustion. I'd like that very much. But let me make an argument for fixing the ..OnOutOfMemoryError first, where fixing means making them apply to as many cases of thrown OOMs as possible: The public does not know when these hooks fire and reasonably assume they fire for all instances of OOM, regardless the cause. To my knowledge we never told them differently. Since it is difficult enough to educate them about new options - look at AbortVMOnException, not many seem to know that one - I'd go with the flow and let the switches do what the public always thought they would do. There are a lot of StackOverFlow articles describing these switches, for instance. Cheers, Thomas > > Cheers, > David > ----- > ------------- PR: https://git.openjdk.java.net/jdk/pull/3586 From ysuenaga at openjdk.java.net Wed Apr 21 07:53:02 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 21 Apr 2021 07:53:02 GMT Subject: RFR: JDK-8155004: CrashOnOutOfMemoryError doesn't work for OOM caused by inability to create threads In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 06:49:56 GMT, Thomas Stuefe wrote: > We seem to have two opposite factions in this discussion. The "works as designed and leave it be" faction and the one wanting to cover as much resource exhaustion cases as possible by these switches. How do we proceed? I like latter, but we need to discuss more because, for example, as you know, description of [HeapDumpOnOutOfMemoryError](https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/clopts001.html) says it affects when an allocation from the Java heap or the permanent generation cannot be satisfied. We will change this spec. I cannot understand "a discussion for another day" well, but... UL (-Xlog:exceptions) has the most coverage of OOMEs (Throwables), so we need to follow it. It will be bigger change than what you thought, but my patch ( #1403 ) will help you. IMHO you can work for it in this PR, and we can work for the others (JFR, JVMTI) in other issues. Is it ok? Otherwise do you want to work just for OOME of native thread creation at first? Ether way, it is the best if these work are acomplished in JDK 17 ?? ------------- PR: https://git.openjdk.java.net/jdk/pull/3586 From sjohanss at openjdk.java.net Wed Apr 21 10:16:41 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Wed, 21 Apr 2021 10:16:41 GMT Subject: RFR: 8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v27] In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 15:51:29 GMT, Marcus G K Williams wrote: >> Just created a CSR for this: [JDK-8265517](https://bugs.openjdk.java.net/browse/JDK-8265517) >> Please take a look at it and provide feedback if you have any. >> >> @mgkwill, please update the patch with the text from the CSR for `LargePageSizeInBytes`. > >> Hi @kstefanj, >> >> (@mgkwill : there are multiple Stefans, it can get confusing) > > Thanks for including me @tstuefe and noting the highlighting of the wrong Stefan. Whoops :P . Updated. >> >> CSR looks good overall. Thanks for doing this. I comment here to give Marcus a way to participate (not sure if he has JBS access). Some points: >> > > I don't have access yet. Still working towards my authorship. I have a few patches in but not sure of the threshold/process. > >> * does it have to have the same title as the issue it is associated with? A title like "Change definition of LargePageSizeInBytes" would be easier to understand and search for. > > +1 > >> * Can the CSR please state that it only affects Linux? >> > > +1 > >> Side note, I had a look at the Windows implementation. It processes LargePageSizeInBytes, but I am not sure it has any effect. On Windows, one obtains the "minimum large page size" and uses that value to align the size requested from VirtualAlloc. Thats it, there is no way to specify an explicit large page size when reserving. LargePageSizeInBytes overwrites this "minimum large page size", but all this does is it somewhat affects the allocated size. So it may be that we could just remove this switch from Windows altogether. >> > > Can this be handled in the same CSR? > >> * "The Java man pages already defines " -> "The Java man page already defines " > > +1 > >> * Do we allow explicit -XX:LargePageSizeInBytes=0 ? Seems somewhat pointless. Do we handle it today? > > Default is `LargePageSizeInBytes=0` - so it seems we would treat `-XX:LargePageSizeInBytes=0` as the same as default. We don't have a specific case for 0 except default handling as far as I can see. > > ` product(size_t, LargePageSizeInBytes, 0, \ > "Large page size (0 to let VM choose the page size)") \ > range(0, max_uintx) \ > ` > >> >> Cheers, Thomas Hi @mgkwill and @tstuefe! > A modification of the code is needed to accomplish what @tstuefe suggested: > > > Default (`LargePageSizeInBytes=0`) > > > > * old behavior - use the systems default large page size > > * new behavior - use all configured page sizes up to and including the systems default large page size > > I'll update with a suggested route in the next couple of days. Nice, an easy approach should be to just remove all large page sizes larger than the decided maximum from _page_sizes. > CSR looks good overall. Thanks for doing this. I comment here to give Marcus a way to participate (not sure if he has JBS access). Some points: > > * does it have to have the same title as the issue it is associated with? A title like "Change definition of LargePageSizeInBytes" would be easier to understand and search for. > I found some other CSRs that had different titels compared to the issues, so change it. Maybe we should also change the name of this issue as well. To something like: Allow multiple large page sizes to be used on Linux > * Can the CSR please state that it only affects Linux? > Not sure we should say only affects Linux, but maybe that only Linux implements support for the new definition (allowing multiple page sizes to be used). But the definition for the flag is the same for all OSes. On Windows we won't make use of the somewhat relaxed definition and it will continue to mean maximum large page size (and only). Is this ok with you? > > Side note, I had a look at the Windows implementation. It processes LargePageSizeInBytes, but I am not sure it has any effect. On Windows, one obtains the "minimum large page size" and uses that value to align the size requested from VirtualAlloc. Thats it, there is no way to specify an explicit large page size when reserving. LargePageSizeInBytes overwrites this "minimum large page size", but all this does is it somewhat affects the allocated size. So it may be that we could just remove this switch from Windows altogether. > Interesting, well it doesn't really go against what we say in the CSR right? > > * "The Java man pages already defines " -> "The Java man page already defines " > Fixed. > * Do we allow explicit -XX:LargePageSizeInBytes=0 ? Seems somewhat pointless. Do we handle it today? Actually we don't, but we probably should handle it. Would be kind of strange preventing someone from setting the default. ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From shade at openjdk.java.net Wed Apr 21 10:32:02 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 21 Apr 2021 10:32:02 GMT Subject: RFR: 8259316: [REDO] C1/C2 compiler support for blackholes [v2] In-Reply-To: References: Message-ID: > This reworks the compiler support for blackholes. The key difference against the last version (#1203) is that blackholes are only acceptable as empty static methods, which both simplifies the implementation and eliminates a few compatibility questions. > > JMH uses the `Blackhole::consume` methods to avoid dead-code elimination of the code that produces benchmark values. It now relies on producing opaque side-effects and breaking inlining. While it was proved useful for many years, it unfortunately comes with several major drawbacks. > > Instead of introducing public APIs or special-casing JMH methods in JVM, we can hook a new command to compiler control, and let JMH sign up its `Blackhole` methods for it with `-XX:CompileCommand=blackhole,org.openjdk.jmh.infra.Blackhole::consume`. See CSR and related discussion for alternatives and future plans. > > C1 code is platform-independent, and it handles blackhole via the intrinsics paths, lowering it to nothing. > > C2 makes the `Blackhole` the subclass of `MemBar`, and use the same `Matcher` path as `Op_MemCPUOrder`: it does not match to anything, but it survives until matching, and keeps arguments alive. Additionally, C1 and C2 hooks are now using the synthetic `_blackhole` intrinsic, similarly to existing `_compiledLambdaForm`. It avoids introducing new nodes in C1. It also seems to require the least fiddling with C2 internals. Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: - Merge branch 'master' into JDK-8259316-blackholes-redo - Redo BlackholeIntrinsicTest to see if target blackhole methods were indeed intrinsified - Rename BlackholeStaticTest to BlackholeIntrinsicTest - BlackholeStaticTest should unlock blackholes - Do not print double-warning on blackhole already set - Add more checks for C2 intrinsic - Simplify intrinsic test and add warning test - Common the blackhole checks - Binding JVMCI through get_jvmci_method - Merge branch 'master' into JDK-8259316-blackholes-redo - ... and 11 more: https://git.openjdk.java.net/jdk/compare/ed477da9...7f4f94d6 ------------- Changes: https://git.openjdk.java.net/jdk/pull/2024/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2024&range=01 Stats: 1164 lines in 32 files changed: 1161 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/2024.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2024/head:pull/2024 PR: https://git.openjdk.java.net/jdk/pull/2024 From shade at openjdk.java.net Wed Apr 21 10:32:03 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 21 Apr 2021 10:32:03 GMT Subject: RFR: 8259316: [REDO] C1/C2 compiler support for blackholes In-Reply-To: References: Message-ID: On Mon, 11 Jan 2021 10:18:15 GMT, Aleksey Shipilev wrote: > This reworks the compiler support for blackholes. The key difference against the last version (#1203) is that blackholes are only acceptable as empty static methods, which both simplifies the implementation and eliminates a few compatibility questions. > > JMH uses the `Blackhole::consume` methods to avoid dead-code elimination of the code that produces benchmark values. It now relies on producing opaque side-effects and breaking inlining. While it was proved useful for many years, it unfortunately comes with several major drawbacks. > > Instead of introducing public APIs or special-casing JMH methods in JVM, we can hook a new command to compiler control, and let JMH sign up its `Blackhole` methods for it with `-XX:CompileCommand=blackhole,org.openjdk.jmh.infra.Blackhole::consume`. See CSR and related discussion for alternatives and future plans. > > C1 code is platform-independent, and it handles blackhole via the intrinsics paths, lowering it to nothing. > > C2 makes the `Blackhole` the subclass of `MemBar`, and use the same `Matcher` path as `Op_MemCPUOrder`: it does not match to anything, but it survives until matching, and keeps arguments alive. Additionally, C1 and C2 hooks are now using the synthetic `_blackhole` intrinsic, similarly to existing `_compiledLambdaForm`. It avoids introducing new nodes in C1. It also seems to require the least fiddling with C2 internals. CSR is approved, I would appreciate some code reviews. ------------- PR: https://git.openjdk.java.net/jdk/pull/2024 From david.holmes at oracle.com Wed Apr 21 10:39:27 2021 From: david.holmes at oracle.com (David Holmes) Date: Wed, 21 Apr 2021 20:39:27 +1000 Subject: RFR: JDK-8155004: CrashOnOutOfMemoryError doesn't work for OOM caused by inability to create threads In-Reply-To: <4tfI8Yvvdah-xoHVzuwiWljN8mmG9JEqVLFm9EOllAw=.f126795a-1171-4510-93da-81b303e5c7b7@github.com> References: <4tfI8Yvvdah-xoHVzuwiWljN8mmG9JEqVLFm9EOllAw=.f126795a-1171-4510-93da-81b303e5c7b7@github.com> Message-ID: <0c6d21c3-c2a9-e497-8525-b0ffd80ce58d@oracle.com> Hi Thomas, On 21/04/2021 5:48 pm, Thomas Stuefe wrote: > Hi David, > > (snip) > >>> p.s. I do not understand your quotes around "bug", nor your hesitance to fix this. I have seen quite a number of desperate setups customers have around crashy or OOMy JVMs, to analyse and to restart quickly. Anything in that area we can do helps. >> >> My hesitance is because the intent of these flags is to provide a >> response for Java heap exhaustion, not to provide a response to every >> place that java.lang.OutOfMemoryError may be thrown. You've picked this >> one case of native thread exhaustion to add-in but that just makes it >> inconsistent. Why should that case be handled and not all the others? It >> is unfortunate that there is more than one way to read OutOfMemoryError, >> but it should be read as out-of-Java-heap-memory-error. We have had bug >> reports when someone uses this flag and their code does "throw new >> OutOfMemoryError() and they want to know why the VM didn't crash! >> >> I wouldn't object to a general broadening of what this flag applies to >> but I do object to cherry-picking a single case, resulting in the flag >> have no well-defined meaning at all. >> > > Okay, I understand your concern now better. > > If you do not object in principle to broadening of ..OnOutOfMemoryError to cover more cases, but just to the fact that this RFE only handles this one case of resource exhaustion, I think we have common ground. Both Yasumasa and me are fully in favour of making the ..OnOutOfMemoryError coverage as complete as possible. I would prefer to do this one RFE at a time, since that way we can put in work when we have free cycles, and these smaller patches are more easy to backport. I've done some more research and I'm less convinced that this is worth pursuing. You might think it good to add more cases to when these flags get applied but what if existing users of these flags do not want them to be applied to these new cases? You might argue that being unable to start a native thread is something that should trigger a heapdump, or abort the VM, but somebody else may not want that. And even if we agree that most people might want this case, what about the other cases? I certainly don't think that any throwing of OutOfMemoryError should trigger these flags as many of them do not actually reflect being out-of-memory: the OOME is just a proxy for out-of-some-resource. > Today ..OnOutOfMemoryError is invoked on OOM for both heap- and metaspace exhaustion, and AFAICS has been this way since at least jdk 11. So it is not consistently applied to java heap ooms only. Okay you got me, but these are both allocation regions directly related to Java-level allocation: either instances or classes. >> And per your latest email perhaps we need new generic flags for >> resource-exhaustion. > > I'd like that very much. But let me make an argument for fixing the ..OnOutOfMemoryError first, where fixing means making them apply to as many cases of thrown OOMs as possible: > > The public does not know when these hooks fire and reasonably assume they fire for all instances of OOM, regardless the cause. To my knowledge we never told them differently. Since it is difficult enough to educate them about new options - look at AbortVMOnException, not many seem to know that one - I'd go with the flow and let the switches do what the public always thought they would do. There are a lot of StackOverFlow articles describing these switches, for instance. An initial google search did not reveal to me any huge issues with these flags. And most of the time people want to get a heap dump because they only expect HeapDumpOnOutOfMemory to do a heap dump when out of heap memory. I think if you want to offer similar options for other circumstances, then it is better to add new flags to deal with that, rather than takeover the existing ones and potentially change behaviour in a way that users have no control over. Sorry. Cheers, David > Cheers, Thomas > >> >> Cheers, >> David >> ----- >> > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3586 > From shade at openjdk.java.net Wed Apr 21 10:44:12 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 21 Apr 2021 10:44:12 GMT Subject: RFR: 8265332: gtest/LargePageGtests.java OOMEs on -XX:+UseSHM cases [v2] In-Reply-To: References: Message-ID: > It looks like some `+UseSHM` test cases added by [JDK-8213269](https://bugs.openjdk.java.net/browse/JDK-8213269) reliably blow up the VM log reader with OOME. There are lots of `OpenJDK 64-Bit Server VM warning: Failed to reserve shared memory.` in the log, if you increase the test heap size. AFAIU, many of those messages are expected from the new test cases. > > I believe ultimately this test produces a virtually unbounded number of warning messages, which would eventually blow out the Java heap in test infra parsers. This is a reliable tier1 failure on my TR 3970X, probably because it has enough cores to run 30 threads concurrently for 15 seconds all spewing warning messages. > > #### Try 1 > > The first attempt recognizes that `ConcurrentTestRunner` runs a time-bound number of iterations, which means the faster machine is, the more warning messages would be printed. Then, the way out is to make `ConcurrentTestRunner` to cap the number of iterations, so that VM output length is more predictable. > > Test times before: > > > # default > [ OK ] os_linux.reserve_memory_special_concurrent_vm (15003 ms) > > # -XX:+UseLargePages > [ OK ] os_linux.reserve_memory_special_concurrent_vm (16121 ms) > > # -XX:+UseLargePages -XX:LargePageSizeInBytes=1G > [ OK ] os_linux.reserve_memory_special_concurrent_vm (15006 ms) > > # -XX:+UseLargePages -XX:+UseSHM > [ OK ] os_linux.reserve_memory_special_concurrent_vm (15030 ms) > > > Test times after: > > > # default > [ OK ] os_linux.reserve_memory_special_concurrent_vm (15003 ms) > > # -XX:+UseLargePages > [ OK ] os_linux.reserve_memory_special_concurrent_vm (16071 ms) > > # -XX:+UseLargePages -XX:LargePageSizeInBytes=1G > [ OK ] os_linux.reserve_memory_special_concurrent_vm (15006 ms) > > # -XX:+UseLargePages -XX:+UseSHM > [ OK ] os_linux.reserve_memory_special_concurrent_vm (1190 ms) > > > The major difference is that the last mode gets capped by `maxIteration`. This fixes the test failure, as `-XX:+UseSHM` case would produce lots of warnings on my machine. > > #### Try 2 > > The second attempt run the tests with `-XX:-PrintWarnings` to avoid warning log overload. > > Additional testing: > - [x] `os_linux` gtest > - [x] `gtest/LargePageGtests.java` used to fail, now passes Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Just run with -XX:-PrintWarnings - Merge branch 'master' into JDK-8265332-largepages-oome - 8265332: gtest/LargePageGtests.java OOMEs on -XX:+UseSHM cases ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3542/files - new: https://git.openjdk.java.net/jdk/pull/3542/files/078218bb..9e4b4c99 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3542&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3542&range=00-01 Stats: 71588 lines in 1898 files changed: 32779 ins; 33866 del; 4943 mod Patch: https://git.openjdk.java.net/jdk/pull/3542.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3542/head:pull/3542 PR: https://git.openjdk.java.net/jdk/pull/3542 From shade at openjdk.java.net Wed Apr 21 10:44:14 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 21 Apr 2021 10:44:14 GMT Subject: RFR: 8265332: gtest/LargePageGtests.java OOMEs on -XX:+UseSHM cases In-Reply-To: References: Message-ID: <-pb-hj5-l8d2yC468yyIrB17isL_yqht4zkfgXX0ejs=.1936b1ac-060d-4202-ae31-37609efd5f79@github.com> On Fri, 16 Apr 2021 10:06:43 GMT, Aleksey Shipilev wrote: > It looks like some `+UseSHM` test cases added by [JDK-8213269](https://bugs.openjdk.java.net/browse/JDK-8213269) reliably blow up the VM log reader with OOME. There are lots of `OpenJDK 64-Bit Server VM warning: Failed to reserve shared memory.` in the log, if you increase the test heap size. AFAIU, many of those messages are expected from the new test cases. > > I believe ultimately this test produces a virtually unbounded number of warning messages, which would eventually blow out the Java heap in test infra parsers. This is a reliable tier1 failure on my TR 3970X, probably because it has enough cores to run 30 threads concurrently for 15 seconds all spewing warning messages. > > #### Try 1 > > The first attempt recognizes that `ConcurrentTestRunner` runs a time-bound number of iterations, which means the faster machine is, the more warning messages would be printed. Then, the way out is to make `ConcurrentTestRunner` to cap the number of iterations, so that VM output length is more predictable. > > Test times before: > > > # default > [ OK ] os_linux.reserve_memory_special_concurrent_vm (15003 ms) > > # -XX:+UseLargePages > [ OK ] os_linux.reserve_memory_special_concurrent_vm (16121 ms) > > # -XX:+UseLargePages -XX:LargePageSizeInBytes=1G > [ OK ] os_linux.reserve_memory_special_concurrent_vm (15006 ms) > > # -XX:+UseLargePages -XX:+UseSHM > [ OK ] os_linux.reserve_memory_special_concurrent_vm (15030 ms) > > > Test times after: > > > # default > [ OK ] os_linux.reserve_memory_special_concurrent_vm (15003 ms) > > # -XX:+UseLargePages > [ OK ] os_linux.reserve_memory_special_concurrent_vm (16071 ms) > > # -XX:+UseLargePages -XX:LargePageSizeInBytes=1G > [ OK ] os_linux.reserve_memory_special_concurrent_vm (15006 ms) > > # -XX:+UseLargePages -XX:+UseSHM > [ OK ] os_linux.reserve_memory_special_concurrent_vm (1190 ms) > > > The major difference is that the last mode gets capped by `maxIteration`. This fixes the test failure, as `-XX:+UseSHM` case would produce lots of warnings on my machine. > > #### Try 2 > > The second attempt run the tests with `-XX:-PrintWarnings` to avoid warning log overload. > > Additional testing: > - [x] `os_linux` gtest > - [x] `gtest/LargePageGtests.java` used to fail, now passes All right! How about we run these tests with `-XX:-PrintWarnings` then? See new, much simpler commit. ------------- PR: https://git.openjdk.java.net/jdk/pull/3542 From vlivanov at openjdk.java.net Wed Apr 21 10:44:59 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Wed, 21 Apr 2021 10:44:59 GMT Subject: RFR: 8259316: [REDO] C1/C2 compiler support for blackholes [v2] In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 10:32:02 GMT, Aleksey Shipilev wrote: >> This reworks the compiler support for blackholes. The key difference against the last version (#1203) is that blackholes are only acceptable as empty static methods, which both simplifies the implementation and eliminates a few compatibility questions. >> >> JMH uses the `Blackhole::consume` methods to avoid dead-code elimination of the code that produces benchmark values. It now relies on producing opaque side-effects and breaking inlining. While it was proved useful for many years, it unfortunately comes with several major drawbacks. >> >> Instead of introducing public APIs or special-casing JMH methods in JVM, we can hook a new command to compiler control, and let JMH sign up its `Blackhole` methods for it with `-XX:CompileCommand=blackhole,org.openjdk.jmh.infra.Blackhole::consume`. See CSR and related discussion for alternatives and future plans. >> >> C1 code is platform-independent, and it handles blackhole via the intrinsics paths, lowering it to nothing. >> >> C2 makes the `Blackhole` the subclass of `MemBar`, and use the same `Matcher` path as `Op_MemCPUOrder`: it does not match to anything, but it survives until matching, and keeps arguments alive. Additionally, C1 and C2 hooks are now using the synthetic `_blackhole` intrinsic, similarly to existing `_compiledLambdaForm`. It avoids introducing new nodes in C1. It also seems to require the least fiddling with C2 internals. > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: > > - Merge branch 'master' into JDK-8259316-blackholes-redo > - Redo BlackholeIntrinsicTest to see if target blackhole methods were indeed intrinsified > - Rename BlackholeStaticTest to BlackholeIntrinsicTest > - BlackholeStaticTest should unlock blackholes > - Do not print double-warning on blackhole already set > - Add more checks for C2 intrinsic > - Simplify intrinsic test and add warning test > - Common the blackhole checks > - Binding JVMCI through get_jvmci_method > - Merge branch 'master' into JDK-8259316-blackholes-redo > - ... and 11 more: https://git.openjdk.java.net/jdk/compare/ed477da9...7f4f94d6 Still looks good. src/hotspot/share/compiler/compilerOracle.hpp line 145: > 143: static bool should_break_at(const methodHandle& method); > 144: > 145: // Tells whether there are any methods to print for print_method_statistics() Excessive whitespaces. ------------- Marked as reviewed by vlivanov (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2024 From dnsimon at openjdk.java.net Wed Apr 21 10:45:00 2021 From: dnsimon at openjdk.java.net (Doug Simon) Date: Wed, 21 Apr 2021 10:45:00 GMT Subject: RFR: 8259316: [REDO] C1/C2 compiler support for blackholes [v2] In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 10:32:02 GMT, Aleksey Shipilev wrote: >> This reworks the compiler support for blackholes. The key difference against the last version (#1203) is that blackholes are only acceptable as empty static methods, which both simplifies the implementation and eliminates a few compatibility questions. >> >> JMH uses the `Blackhole::consume` methods to avoid dead-code elimination of the code that produces benchmark values. It now relies on producing opaque side-effects and breaking inlining. While it was proved useful for many years, it unfortunately comes with several major drawbacks. >> >> Instead of introducing public APIs or special-casing JMH methods in JVM, we can hook a new command to compiler control, and let JMH sign up its `Blackhole` methods for it with `-XX:CompileCommand=blackhole,org.openjdk.jmh.infra.Blackhole::consume`. See CSR and related discussion for alternatives and future plans. >> >> C1 code is platform-independent, and it handles blackhole via the intrinsics paths, lowering it to nothing. >> >> C2 makes the `Blackhole` the subclass of `MemBar`, and use the same `Matcher` path as `Op_MemCPUOrder`: it does not match to anything, but it survives until matching, and keeps arguments alive. Additionally, C1 and C2 hooks are now using the synthetic `_blackhole` intrinsic, similarly to existing `_compiledLambdaForm`. It avoids introducing new nodes in C1. It also seems to require the least fiddling with C2 internals. > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: > > - Merge branch 'master' into JDK-8259316-blackholes-redo > - Redo BlackholeIntrinsicTest to see if target blackhole methods were indeed intrinsified > - Rename BlackholeStaticTest to BlackholeIntrinsicTest > - BlackholeStaticTest should unlock blackholes > - Do not print double-warning on blackhole already set > - Add more checks for C2 intrinsic > - Simplify intrinsic test and add warning test > - Common the blackhole checks > - Binding JVMCI through get_jvmci_method > - Merge branch 'master' into JDK-8259316-blackholes-redo > - ... and 11 more: https://git.openjdk.java.net/jdk/compare/ed477da9...7f4f94d6 JVMCI changes look good. ------------- PR: https://git.openjdk.java.net/jdk/pull/2024 From redestad at openjdk.java.net Wed Apr 21 11:04:40 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Wed, 21 Apr 2021 11:04:40 GMT Subject: RFR: 8265606: Reduce allocations in AdapterHandlerLibrary::get_adapter Message-ID: Use stack allocated arrays used when looking up and creating adapters. Resource allocate if number of args grows large, which is relatively rare. ------------- Commit messages: - Avoid resource allocation for small arrays - Revert "8265606: Reduce allocations in AdapterHandlerLibrary::get_adapter" - 8265606: Reduce allocations in AdapterHandlerLibrary::get_adapter Changes: https://git.openjdk.java.net/jdk/pull/3595/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3595&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265606 Stats: 13 lines in 1 file changed: 7 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/3595.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3595/head:pull/3595 PR: https://git.openjdk.java.net/jdk/pull/3595 From stuefe at openjdk.java.net Wed Apr 21 11:49:46 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 21 Apr 2021 11:49:46 GMT Subject: RFR: 8265332: gtest/LargePageGtests.java OOMEs on -XX:+UseSHM cases [v2] In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 10:44:12 GMT, Aleksey Shipilev wrote: >> It looks like some `+UseSHM` test cases added by [JDK-8213269](https://bugs.openjdk.java.net/browse/JDK-8213269) reliably blow up the VM log reader with OOME. There are lots of `OpenJDK 64-Bit Server VM warning: Failed to reserve shared memory.` in the log, if you increase the test heap size. AFAIU, many of those messages are expected from the new test cases. >> >> I believe ultimately this test produces a virtually unbounded number of warning messages, which would eventually blow out the Java heap in test infra parsers. This is a reliable tier1 failure on my TR 3970X, probably because it has enough cores to run 30 threads concurrently for 15 seconds all spewing warning messages. >> >> #### Try 1 >> >> The first attempt recognizes that `ConcurrentTestRunner` runs a time-bound number of iterations, which means the faster machine is, the more warning messages would be printed. Then, the way out is to make `ConcurrentTestRunner` to cap the number of iterations, so that VM output length is more predictable. >> >> Test times before: >> >> >> # default >> [ OK ] os_linux.reserve_memory_special_concurrent_vm (15003 ms) >> >> # -XX:+UseLargePages >> [ OK ] os_linux.reserve_memory_special_concurrent_vm (16121 ms) >> >> # -XX:+UseLargePages -XX:LargePageSizeInBytes=1G >> [ OK ] os_linux.reserve_memory_special_concurrent_vm (15006 ms) >> >> # -XX:+UseLargePages -XX:+UseSHM >> [ OK ] os_linux.reserve_memory_special_concurrent_vm (15030 ms) >> >> >> Test times after: >> >> >> # default >> [ OK ] os_linux.reserve_memory_special_concurrent_vm (15003 ms) >> >> # -XX:+UseLargePages >> [ OK ] os_linux.reserve_memory_special_concurrent_vm (16071 ms) >> >> # -XX:+UseLargePages -XX:LargePageSizeInBytes=1G >> [ OK ] os_linux.reserve_memory_special_concurrent_vm (15006 ms) >> >> # -XX:+UseLargePages -XX:+UseSHM >> [ OK ] os_linux.reserve_memory_special_concurrent_vm (1190 ms) >> >> >> The major difference is that the last mode gets capped by `maxIteration`. This fixes the test failure, as `-XX:+UseSHM` case would produce lots of warnings on my machine. >> >> #### Try 2 >> >> The second attempt run the tests with `-XX:-PrintWarnings` to avoid warning log overload. >> >> Additional testing: >> - [x] `os_linux` gtest >> - [x] `gtest/LargePageGtests.java` used to fail, now passes > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Just run with -XX:-PrintWarnings > - Merge branch 'master' into JDK-8265332-largepages-oome > - 8265332: gtest/LargePageGtests.java OOMEs on -XX:+UseSHM cases Good and trivial. Thanks! ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3542 From mbaesken at openjdk.java.net Wed Apr 21 12:29:39 2021 From: mbaesken at openjdk.java.net (Matthias Baesken) Date: Wed, 21 Apr 2021 12:29:39 GMT Subject: RFR: JDK-8155004: CrashOnOutOfMemoryError doesn't work for OOM caused by inability to create threads In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 10:52:26 GMT, Thomas Stuefe wrote: > Greetings, > > this is an old issue and I'd like to fix it. If we fail to create a java thread due to platform limitations we throw an OOM. But we fail to honor the various xxxOnOutOfMemoryError switches. > > The fix is very straightforward. > > If fixes > - CrashOnOutOfMemoryError > - ExitOnOutOfMemoryError > - HeapDumpOnOutOfMemoryError > - and, in theory "OnOutOfMemoryError=". > > the latter only in theory because most of the times whatever prevented the thread to start up will also prevent the fork needed to get the user command running. > > One remaining question, maybe for a future RFE, is how we want to handle native threads creation error. AFAICS currently, failing to create a native thread may or may not result in a fatal shutdown, a log output, or just be ignored, depending on the thread. > > If `...OnOutOfMemoryError` is specified, should native thread creation failure be handled the same way as a java thread? > > - No if I take the option name literally, since there is no OOM involved > - Yes if I take into account what these switches are actually used for - analysis or quick shutdown of a JVM inside a container in case of an OOM. Since it is completely random which thread is hit by the limit. > > Thanks, Thomas Marked as reviewed by mbaesken (Reviewer). Hello , the description of the flags in globals.hpp says : ExitOnOutOfMemoryError JVM exits on the first occurrence of an out-of-memory error thrown from JVM CrashOnOutOfMemoryError JVM aborts, producing an error log and core/mini dump, on the first occurrence of an out-of-memory error thrown from JVM So I think the patch Thomas did is fine, it improves the situation where customers expect an exit/crash, when the flag is set accordingly. But they do not get it at the moment. ------------- PR: https://git.openjdk.java.net/jdk/pull/3586 From stuefe at openjdk.java.net Wed Apr 21 12:33:33 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 21 Apr 2021 12:33:33 GMT Subject: RFR: JDK-8155004: CrashOnOutOfMemoryError doesn't work for OOM caused by inability to create threads In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 10:52:26 GMT, Thomas Stuefe wrote: > Greetings, > > this is an old issue and I'd like to fix it. If we fail to create a java thread due to platform limitations we throw an OOM. But we fail to honor the various xxxOnOutOfMemoryError switches. > > The fix is very straightforward. > > If fixes > - CrashOnOutOfMemoryError > - ExitOnOutOfMemoryError > - HeapDumpOnOutOfMemoryError > - and, in theory "OnOutOfMemoryError=". > > the latter only in theory because most of the times whatever prevented the thread to start up will also prevent the fork needed to get the user command running. > > One remaining question, maybe for a future RFE, is how we want to handle native threads creation error. AFAICS currently, failing to create a native thread may or may not result in a fatal shutdown, a log output, or just be ignored, depending on the thread. > > If `...OnOutOfMemoryError` is specified, should native thread creation failure be handled the same way as a java thread? > > - No if I take the option name literally, since there is no OOM involved > - Yes if I take into account what these switches are actually used for - analysis or quick shutdown of a JVM inside a container in case of an OOM. Since it is completely random which thread is hit by the limit. > > Thanks, Thomas Hi David, okay, I'll withdraw the patch and close the issue as wont-fix. We'll keep the fixes downstream. Wrt new flags, this sounds good. JDK 17 would be a good release for such a new flag, but I am not sure yet if I can find the spare cycles. Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/3586 From stuefe at openjdk.java.net Wed Apr 21 12:33:33 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 21 Apr 2021 12:33:33 GMT Subject: Withdrawn: JDK-8155004: CrashOnOutOfMemoryError doesn't work for OOM caused by inability to create threads In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 10:52:26 GMT, Thomas Stuefe wrote: > Greetings, > > this is an old issue and I'd like to fix it. If we fail to create a java thread due to platform limitations we throw an OOM. But we fail to honor the various xxxOnOutOfMemoryError switches. > > The fix is very straightforward. > > If fixes > - CrashOnOutOfMemoryError > - ExitOnOutOfMemoryError > - HeapDumpOnOutOfMemoryError > - and, in theory "OnOutOfMemoryError=". > > the latter only in theory because most of the times whatever prevented the thread to start up will also prevent the fork needed to get the user command running. > > One remaining question, maybe for a future RFE, is how we want to handle native threads creation error. AFAICS currently, failing to create a native thread may or may not result in a fatal shutdown, a log output, or just be ignored, depending on the thread. > > If `...OnOutOfMemoryError` is specified, should native thread creation failure be handled the same way as a java thread? > > - No if I take the option name literally, since there is no OOM involved > - Yes if I take into account what these switches are actually used for - analysis or quick shutdown of a JVM inside a container in case of an OOM. Since it is completely random which thread is hit by the limit. > > Thanks, Thomas This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/3586 From shade at openjdk.java.net Wed Apr 21 12:37:38 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 21 Apr 2021 12:37:38 GMT Subject: RFR: 8261492: Shenandoah: reconsider forwardee accesses memory ordering [v3] In-Reply-To: References: Message-ID: <5eFYUAN5vePIHfJMyvgAz2XNf6kxbtEhR7ktB2hBNjA=.ef0c8a80-d56d-494f-83d0-2857e463650e@github.com> On Tue, 16 Feb 2021 10:26:06 GMT, Aleksey Shipilev wrote: >> Shenandoah carries forwardee information in object's mark word. Installing the new mark word is effectively "releasing" the object copy, and reading from the new mark word is "acquiring" that object copy. >> >> For the forwardee update side, Hotspot's default for atomic operations is memory_order_conservative, which emits two-way memory fences around the CASes at least on AArch64 and PPC64. This seems to be excessive for Shenandoah forwardee updates, and "release" is enough. >> >> For the forwardee load side, we need to guarantee "acquire". We do not do it now, reading the markword without memory semantics. It does not seem to pose a practical problem today, because GC does not access the object contents in the new copy, and mutators get this from the JRT-called stub that separates the fwdptr access and object contents access by a lot. It still should be cleaner to "acquire" the mark on load to avoid surprises. >> >> Additional testing: >> - [x] Linux x86_64 `hotspot_gc_shenandoah` >> - [x] Linux AArch64 `hotspot_gc_shenandoah` >> - [x] Linux AArch64 `tier1` with Shenandoah > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - A few minor touchups > - Add a blurb to x86 code as well > - Use implicit "consume" in AArch64, add more notes. > - Merge branch 'master' into JDK-8261492-shenandoah-forwardee-memord > - Make sure to access fwdptr with acquire semantics in assembler code > - 8261492: Shenandoah: reconsider forwardee accesses memory ordering Not yet, bot. Waiting for JDK-8261579 to remeasure perf differences. ------------- PR: https://git.openjdk.java.net/jdk/pull/2496 From stuefe at openjdk.java.net Wed Apr 21 12:49:39 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 21 Apr 2021 12:49:39 GMT Subject: RFR: 8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v27] In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 15:51:29 GMT, Marcus G K Williams wrote: >> Just created a CSR for this: [JDK-8265517](https://bugs.openjdk.java.net/browse/JDK-8265517) >> Please take a look at it and provide feedback if you have any. >> >> @mgkwill, please update the patch with the text from the CSR for `LargePageSizeInBytes`. > >> Hi @kstefanj, >> >> (@mgkwill : there are multiple Stefans, it can get confusing) > > Thanks for including me @tstuefe and noting the highlighting of the wrong Stefan. Whoops :P . Updated. >> >> CSR looks good overall. Thanks for doing this. I comment here to give Marcus a way to participate (not sure if he has JBS access). Some points: >> > > I don't have access yet. Still working towards my authorship. I have a few patches in but not sure of the threshold/process. > >> * does it have to have the same title as the issue it is associated with? A title like "Change definition of LargePageSizeInBytes" would be easier to understand and search for. > > +1 > >> * Can the CSR please state that it only affects Linux? >> > > +1 > >> Side note, I had a look at the Windows implementation. It processes LargePageSizeInBytes, but I am not sure it has any effect. On Windows, one obtains the "minimum large page size" and uses that value to align the size requested from VirtualAlloc. Thats it, there is no way to specify an explicit large page size when reserving. LargePageSizeInBytes overwrites this "minimum large page size", but all this does is it somewhat affects the allocated size. So it may be that we could just remove this switch from Windows altogether. >> > > Can this be handled in the same CSR? > >> * "The Java man pages already defines " -> "The Java man page already defines " > > +1 > >> * Do we allow explicit -XX:LargePageSizeInBytes=0 ? Seems somewhat pointless. Do we handle it today? > > Default is `LargePageSizeInBytes=0` - so it seems we would treat `-XX:LargePageSizeInBytes=0` as the same as default. We don't have a specific case for 0 except default handling as far as I can see. > > ` product(size_t, LargePageSizeInBytes, 0, \ > "Large page size (0 to let VM choose the page size)") \ > range(0, max_uintx) \ > ` > >> >> Cheers, Thomas > Hi @mgkwill and @tstuefe! > > > A modification of the code is needed to accomplish what @tstuefe suggested: > > > Default (`LargePageSizeInBytes=0`) > > > > > > * old behavior - use the systems default large page size > > > * new behavior - use all configured page sizes up to and including the systems default large page size > > > > > > I'll update with a suggested route in the next couple of days. > > Nice, an easy approach should be to just remove all large page sizes larger than the decided maximum from _page_sizes. > > > CSR looks good overall. Thanks for doing this. I comment here to give Marcus a way to participate (not sure if he has JBS access). Some points: > > > > * does it have to have the same title as the issue it is associated with? A title like "Change definition of LargePageSizeInBytes" would be easier to understand and search for. > > I found some other CSRs that had different titels compared to the issues, so change it. Maybe we should also change the name of this issue as well. To something like: > Allow multiple large page sizes to be used on Linux > > > * Can the CSR please state that it only affects Linux? > > Not sure we should say only affects Linux, but maybe that only Linux implements support for the new definition (allowing multiple page sizes to be used). But the definition for the flag is the same for all OSes. On Windows we won't make use of the somewhat relaxed definition and it will continue to mean maximum large page size (and only). Is this ok with you? > > > Side note, I had a look at the Windows implementation. It processes LargePageSizeInBytes, but I am not sure it has any effect. On Windows, one obtains the "minimum large page size" and uses that value to align the size requested from VirtualAlloc. Thats it, there is no way to specify an explicit large page size when reserving. LargePageSizeInBytes overwrites this "minimum large page size", but all this does is it somewhat affects the allocated size. So it may be that we could just remove this switch from Windows altogether. > > Interesting, well it doesn't really go against what we say in the CSR right? I am fine with leaving Windows implicitly covered. > > > * "The Java man pages already defines " -> "The Java man page already defines " > > Fixed. > > > * Do we allow explicit -XX:LargePageSizeInBytes=0 ? Seems somewhat pointless. Do we handle it today? > > Actually we don't, but we probably should handle it. Would be kind of strange preventing someone from setting the default. I marked the CSR as reviewed. Thanks & Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From sjohanss at openjdk.java.net Wed Apr 21 13:10:39 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Wed, 21 Apr 2021 13:10:39 GMT Subject: RFR: 8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v27] In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 12:46:21 GMT, Thomas Stuefe wrote: >>> Hi @kstefanj, >>> >>> (@mgkwill : there are multiple Stefans, it can get confusing) >> >> Thanks for including me @tstuefe and noting the highlighting of the wrong Stefan. Whoops :P . Updated. >>> >>> CSR looks good overall. Thanks for doing this. I comment here to give Marcus a way to participate (not sure if he has JBS access). Some points: >>> >> >> I don't have access yet. Still working towards my authorship. I have a few patches in but not sure of the threshold/process. >> >>> * does it have to have the same title as the issue it is associated with? A title like "Change definition of LargePageSizeInBytes" would be easier to understand and search for. >> >> +1 >> >>> * Can the CSR please state that it only affects Linux? >>> >> >> +1 >> >>> Side note, I had a look at the Windows implementation. It processes LargePageSizeInBytes, but I am not sure it has any effect. On Windows, one obtains the "minimum large page size" and uses that value to align the size requested from VirtualAlloc. Thats it, there is no way to specify an explicit large page size when reserving. LargePageSizeInBytes overwrites this "minimum large page size", but all this does is it somewhat affects the allocated size. So it may be that we could just remove this switch from Windows altogether. >>> >> >> Can this be handled in the same CSR? >> >>> * "The Java man pages already defines " -> "The Java man page already defines " >> >> +1 >> >>> * Do we allow explicit -XX:LargePageSizeInBytes=0 ? Seems somewhat pointless. Do we handle it today? >> >> Default is `LargePageSizeInBytes=0` - so it seems we would treat `-XX:LargePageSizeInBytes=0` as the same as default. We don't have a specific case for 0 except default handling as far as I can see. >> >> ` product(size_t, LargePageSizeInBytes, 0, \ >> "Large page size (0 to let VM choose the page size)") \ >> range(0, max_uintx) \ >> ` >> >>> >>> Cheers, Thomas > >> Hi @mgkwill and @tstuefe! >> >> > A modification of the code is needed to accomplish what @tstuefe suggested: >> > > Default (`LargePageSizeInBytes=0`) >> > > >> > > * old behavior - use the systems default large page size >> > > * new behavior - use all configured page sizes up to and including the systems default large page size >> > >> > >> > I'll update with a suggested route in the next couple of days. >> >> Nice, an easy approach should be to just remove all large page sizes larger than the decided maximum from _page_sizes. >> >> > CSR looks good overall. Thanks for doing this. I comment here to give Marcus a way to participate (not sure if he has JBS access). Some points: >> > >> > * does it have to have the same title as the issue it is associated with? A title like "Change definition of LargePageSizeInBytes" would be easier to understand and search for. >> >> I found some other CSRs that had different titels compared to the issues, so change it. Maybe we should also change the name of this issue as well. To something like: >> Allow multiple large page sizes to be used on Linux >> >> > * Can the CSR please state that it only affects Linux? >> >> Not sure we should say only affects Linux, but maybe that only Linux implements support for the new definition (allowing multiple page sizes to be used). But the definition for the flag is the same for all OSes. On Windows we won't make use of the somewhat relaxed definition and it will continue to mean maximum large page size (and only). Is this ok with you? >> >> > Side note, I had a look at the Windows implementation. It processes LargePageSizeInBytes, but I am not sure it has any effect. On Windows, one obtains the "minimum large page size" and uses that value to align the size requested from VirtualAlloc. Thats it, there is no way to specify an explicit large page size when reserving. LargePageSizeInBytes overwrites this "minimum large page size", but all this does is it somewhat affects the allocated size. So it may be that we could just remove this switch from Windows altogether. >> >> Interesting, well it doesn't really go against what we say in the CSR right? > > I am fine with leaving Windows implicitly covered. > >> >> > * "The Java man pages already defines " -> "The Java man page already defines " >> >> Fixed. >> >> > * Do we allow explicit -XX:LargePageSizeInBytes=0 ? Seems somewhat pointless. Do we handle it today? >> >> Actually we don't, but we probably should handle it. Would be kind of strange preventing someone from setting the default. > > I marked the CSR as reviewed. > > Thanks & Cheers, Thomas Thanks for reviewing the the CSR @tstuefe. Internal discussions around the text in the CSR pointed out the "system" might not be the best wording when it comes to default size. I will update the CSR using "for the environment" instead, for example: > ?By default, the size is set to 0, meaning that the JVM will use the default large page size for the environment as the maximum size for large pages.? Hope this is still good. ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From duke at openjdk.java.net Wed Apr 21 13:21:39 2021 From: duke at openjdk.java.net (duke) Date: Wed, 21 Apr 2021 13:21:39 GMT Subject: Withdrawn: 8259383: AsyncGetCallTrace() crashes sporadically In-Reply-To: <55VhodtLlLULjpxGm3PXOn2iFgrVIdqcZwysOSEK8rg=.d1571446-fc26-4b7d-9450-29ecacb31dda@github.com> References: <55VhodtLlLULjpxGm3PXOn2iFgrVIdqcZwysOSEK8rg=.d1571446-fc26-4b7d-9450-29ecacb31dda@github.com> Message-ID: <6hOp3Z-00yD5XS_sJ0LKViyBLSg8-F0AsxZuNep9TkY=.820f279d-3fe0-4df9-a236-67fb5ed17e9e@github.com> On Mon, 11 Jan 2021 18:39:41 GMT, Lutz Schmidt wrote: > Hi, > may I please ask the community to review this small fix? It closes another hole in AsyncGetCallTrace(). > Thanks a lot! > Lutz This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/2032 From aph at redhat.com Wed Apr 21 14:48:09 2021 From: aph at redhat.com (Andrew Haley) Date: Wed, 21 Apr 2021 15:48:09 +0100 Subject: AArch64: Apple M1: getting a core dump Message-ID: <47bf9b8b-e824-db90-0c54-c29786b5abe7@redhat.com> I've been looking at a rare HotSpot crash and trying to fugure out the cause, but I can't get a core dump. I've tried things like "ulimit -c unlimited" but no luck. HotSpot says it's dumping core, but there is no core in the current dir or in "/cores". So, my question: has anyone here ever managed to get a core dump on one of these machines? And if so, what did you do? Thanks, -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From stuefe at openjdk.java.net Wed Apr 21 15:31:41 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 21 Apr 2021 15:31:41 GMT Subject: RFR: 8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v27] In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 12:46:21 GMT, Thomas Stuefe wrote: >>> Hi @kstefanj, >>> >>> (@mgkwill : there are multiple Stefans, it can get confusing) >> >> Thanks for including me @tstuefe and noting the highlighting of the wrong Stefan. Whoops :P . Updated. >>> >>> CSR looks good overall. Thanks for doing this. I comment here to give Marcus a way to participate (not sure if he has JBS access). Some points: >>> >> >> I don't have access yet. Still working towards my authorship. I have a few patches in but not sure of the threshold/process. >> >>> * does it have to have the same title as the issue it is associated with? A title like "Change definition of LargePageSizeInBytes" would be easier to understand and search for. >> >> +1 >> >>> * Can the CSR please state that it only affects Linux? >>> >> >> +1 >> >>> Side note, I had a look at the Windows implementation. It processes LargePageSizeInBytes, but I am not sure it has any effect. On Windows, one obtains the "minimum large page size" and uses that value to align the size requested from VirtualAlloc. Thats it, there is no way to specify an explicit large page size when reserving. LargePageSizeInBytes overwrites this "minimum large page size", but all this does is it somewhat affects the allocated size. So it may be that we could just remove this switch from Windows altogether. >>> >> >> Can this be handled in the same CSR? >> >>> * "The Java man pages already defines " -> "The Java man page already defines " >> >> +1 >> >>> * Do we allow explicit -XX:LargePageSizeInBytes=0 ? Seems somewhat pointless. Do we handle it today? >> >> Default is `LargePageSizeInBytes=0` - so it seems we would treat `-XX:LargePageSizeInBytes=0` as the same as default. We don't have a specific case for 0 except default handling as far as I can see. >> >> ` product(size_t, LargePageSizeInBytes, 0, \ >> "Large page size (0 to let VM choose the page size)") \ >> range(0, max_uintx) \ >> ` >> >>> >>> Cheers, Thomas > >> Hi @mgkwill and @tstuefe! >> >> > A modification of the code is needed to accomplish what @tstuefe suggested: >> > > Default (`LargePageSizeInBytes=0`) >> > > >> > > * old behavior - use the systems default large page size >> > > * new behavior - use all configured page sizes up to and including the systems default large page size >> > >> > >> > I'll update with a suggested route in the next couple of days. >> >> Nice, an easy approach should be to just remove all large page sizes larger than the decided maximum from _page_sizes. >> >> > CSR looks good overall. Thanks for doing this. I comment here to give Marcus a way to participate (not sure if he has JBS access). Some points: >> > >> > * does it have to have the same title as the issue it is associated with? A title like "Change definition of LargePageSizeInBytes" would be easier to understand and search for. >> >> I found some other CSRs that had different titels compared to the issues, so change it. Maybe we should also change the name of this issue as well. To something like: >> Allow multiple large page sizes to be used on Linux >> >> > * Can the CSR please state that it only affects Linux? >> >> Not sure we should say only affects Linux, but maybe that only Linux implements support for the new definition (allowing multiple page sizes to be used). But the definition for the flag is the same for all OSes. On Windows we won't make use of the somewhat relaxed definition and it will continue to mean maximum large page size (and only). Is this ok with you? >> >> > Side note, I had a look at the Windows implementation. It processes LargePageSizeInBytes, but I am not sure it has any effect. On Windows, one obtains the "minimum large page size" and uses that value to align the size requested from VirtualAlloc. Thats it, there is no way to specify an explicit large page size when reserving. LargePageSizeInBytes overwrites this "minimum large page size", but all this does is it somewhat affects the allocated size. So it may be that we could just remove this switch from Windows altogether. >> >> Interesting, well it doesn't really go against what we say in the CSR right? > > I am fine with leaving Windows implicitly covered. > >> >> > * "The Java man pages already defines " -> "The Java man page already defines " >> >> Fixed. >> >> > * Do we allow explicit -XX:LargePageSizeInBytes=0 ? Seems somewhat pointless. Do we handle it today? >> >> Actually we don't, but we probably should handle it. Would be kind of strange preventing someone from setting the default. > > I marked the CSR as reviewed. > > Thanks & Cheers, Thomas > Thanks for reviewing the the CSR @tstuefe. Internal discussions around the text in the CSR pointed out the "system" might not be the best wording when it comes to default size. I will update the CSR using "for the environment" instead, for example: > > > ?By default, the size is set to 0, meaning that the JVM will use the default large page size for the environment as the maximum size for large pages.? > > Hope this is still good. Still good. I was vaguely concerned about the "default" in "default system page size" because that is a Linux concept; on other Unices which have multiple page sizes there is no concept of a default (eg AIX, HPUX). But this is just idle nitpicking, the CSR is clear the way you wrote it. ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From vkempik at azul.com Wed Apr 21 15:48:16 2021 From: vkempik at azul.com (Vladimir Kempik) Date: Wed, 21 Apr 2021 15:48:16 +0000 Subject: AArch64: Apple M1: getting a core dump In-Reply-To: <47bf9b8b-e824-db90-0c54-c29786b5abe7@redhat.com> References: <47bf9b8b-e824-db90-0c54-c29786b5abe7@redhat.com> Message-ID: <52c8f46eb89447fa948b7da6d14067c0@azul.com> Hello That sounds like a limitation of hardened runtime in macos. So you need to resign you jdk without hardened runtime ( its -o runtime option to codesign) Regards, Vladimir Andrew Haley 21 ?????? 2021 ?. 17:48:32 ???????: I've been looking at a rare HotSpot crash and trying to fugure out the cause, but I can't get a core dump. I've tried things like "ulimit -c unlimited" but no luck. HotSpot says it's dumping core, but there is no core in the current dir or in "/cores". So, my question: has anyone here ever managed to get a core dump on one of these machines? And if so, what did you do? Thanks, -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Wed Apr 21 15:53:01 2021 From: aph at redhat.com (Andrew Haley) Date: Wed, 21 Apr 2021 16:53:01 +0100 Subject: AArch64: Apple M1: getting a core dump In-Reply-To: <52c8f46eb89447fa948b7da6d14067c0@azul.com> References: <47bf9b8b-e824-db90-0c54-c29786b5abe7@redhat.com> <52c8f46eb89447fa948b7da6d14067c0@azul.com> Message-ID: <9c064cca-1207-a75d-435c-c9719e4c3990@redhat.com> On 4/21/21 4:48 PM, Vladimir Kempik wrote: > Hello > That sounds like a limitation of hardened runtime in macos. > So you need to resign you jdk without hardened runtime ( its -o runtime option to codesign) OK. I guess I don't have any idea how codesign happens when JDK is built. All I do is type "make". :-) -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From github.com+168222+mgkwill at openjdk.java.net Wed Apr 21 16:23:38 2021 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Wed, 21 Apr 2021 16:23:38 GMT Subject: RFR: 8265491: Math Signum optimization for x86 [v2] In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 06:38:54 GMT, David Holmes wrote: >> Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision: >> >> Add os.arch=="i386" to signum jtreg >> >> Signed-off-by: Marcus G K Williams > > test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java line 28: > >> 26: * @test >> 27: * @summary Test compiler intrinsics for signum >> 28: * @requires os.arch=="aarch64" | os.arch=="x86" | os.arch=="i386" | os.arch=="amd64" | os.arch=="x86_64" > > Shouldn't this test run successfully on all platforms, even if they don't do anything in response to UseSignumIntrinsic? I can run it today on x86_64. Hi @dholmes-ora. I have not done negative testing on any platform using TestSignumIntrinsic.java. I'm not the original author, but what you say makes sense after some thought. I'll try an easy test, remove this line and see if presubmit tests pass. ------------- PR: https://git.openjdk.java.net/jdk/pull/3581 From vkempik at azul.com Wed Apr 21 16:43:37 2021 From: vkempik at azul.com (Vladimir Kempik) Date: Wed, 21 Apr 2021 16:43:37 +0000 Subject: AArch64: Apple M1: getting a core dump In-Reply-To: <9c064cca-1207-a75d-435c-c9719e4c3990@redhat.com> References: <47bf9b8b-e824-db90-0c54-c29786b5abe7@redhat.com> <52c8f46eb89447fa948b7da6d14067c0@azul.com> <9c064cca-1207-a75d-435c-c9719e4c3990@redhat.com> Message-ID: <05B66BC6-508F-4DA3-B5F2-DB282A134BF4@azul.com> Hello you might want to slightly hack openjdk?s build system and remove these ?options runtime $ egrep -ir "\-\-options runtime" make make/Bundles.gmk: --timestamp --options runtime --deep --force \ make/Bundles.gmk: --timestamp --options runtime --deep --force \ make/common/NativeCompilation.gmk: $(CODESIGN) -s "$(MACOSX_CODESIGN_IDENTITY)" --timestamp --options runtime \ then make clean images. Regards, Vladimir > 21 ???. 2021 ?., ? 18:53, Andrew Haley ???????(?): > > On 4/21/21 4:48 PM, Vladimir Kempik wrote: >> Hello >> That sounds like a limitation of hardened runtime in macos. >> So you need to resign you jdk without hardened runtime ( its -o runtime option to codesign) > > OK. I guess I don't have any idea how codesign happens when JDK is built. > All I do is type "make". :-) > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From github.com+168222+mgkwill at openjdk.java.net Wed Apr 21 16:50:35 2021 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Wed, 21 Apr 2021 16:50:35 GMT Subject: RFR: 8265491: Math Signum optimization for x86 [v2] In-Reply-To: <6q9w2ylkC6SGEN7-9WeO6qCXhEvNqO3JJAQHWx40GkM=.022014cb-b8e9-4f05-86e9-e855fe4cc6f0@github.com> References: <6q9w2ylkC6SGEN7-9WeO6qCXhEvNqO3JJAQHWx40GkM=.022014cb-b8e9-4f05-86e9-e855fe4cc6f0@github.com> Message-ID: <0GErbVcHiUYxfrFLooYD5wFx5pKa6Lavi7zKszA1AXc=.9ba89489-5411-431e-a3a5-3b59c5bbf49b@github.com> On Wed, 21 Apr 2021 03:48:57 GMT, Jie Fu wrote: >> Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision: >> >> Add os.arch=="i386" to signum jtreg >> >> Signed-off-by: Marcus G K Williams > > src/hotspot/cpu/x86/x86.ad line 5780: > >> 5778: // --------------------------------- Signum --------------------------- >> 5779: >> 5780: instruct signumF_reg(regF dst, regF zero, regF one, rFlagsReg cr) %{ > > Do we need `predicate(UseSSE>=2);` here? It seems ucomiss is SSE, but ucomisd is SSE2. I will add a SSE predicate to `instruct signumF_reg` and an SSE2 predicate to `instruct signumD_reg`. Thanks for the suggestion. ------------- PR: https://git.openjdk.java.net/jdk/pull/3581 From github.com+168222+mgkwill at openjdk.java.net Wed Apr 21 16:59:39 2021 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Wed, 21 Apr 2021 16:59:39 GMT Subject: RFR: 8265491: Math Signum optimization for x86 [v2] In-Reply-To: <0GErbVcHiUYxfrFLooYD5wFx5pKa6Lavi7zKszA1AXc=.9ba89489-5411-431e-a3a5-3b59c5bbf49b@github.com> References: <6q9w2ylkC6SGEN7-9WeO6qCXhEvNqO3JJAQHWx40GkM=.022014cb-b8e9-4f05-86e9-e855fe4cc6f0@github.com> <0GErbVcHiUYxfrFLooYD5wFx5pKa6Lavi7zKszA1AXc=.9ba89489-5411-431e-a3a5-3b59c5bbf49b@github.com> Message-ID: On Wed, 21 Apr 2021 16:47:20 GMT, Marcus G K Williams wrote: >> src/hotspot/cpu/x86/x86.ad line 5780: >> >>> 5778: // --------------------------------- Signum --------------------------- >>> 5779: >>> 5780: instruct signumF_reg(regF dst, regF zero, regF one, rFlagsReg cr) %{ >> >> Do we need `predicate(UseSSE>=2);` here? > > It seems ucomiss is SSE, but ucomisd is SSE2. I will add a SSE predicate to `instruct signumF_reg` and an SSE2 predicate to `instruct signumD_reg`. Thanks for the suggestion. It looks like subss, subsd are also SSE, SSE2 respectively. ------------- PR: https://git.openjdk.java.net/jdk/pull/3581 From kvn at openjdk.java.net Wed Apr 21 17:02:38 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Wed, 21 Apr 2021 17:02:38 GMT Subject: RFR: 8259316: [REDO] C1/C2 compiler support for blackholes [v2] In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 10:32:02 GMT, Aleksey Shipilev wrote: >> This reworks the compiler support for blackholes. The key difference against the last version (#1203) is that blackholes are only acceptable as empty static methods, which both simplifies the implementation and eliminates a few compatibility questions. >> >> JMH uses the `Blackhole::consume` methods to avoid dead-code elimination of the code that produces benchmark values. It now relies on producing opaque side-effects and breaking inlining. While it was proved useful for many years, it unfortunately comes with several major drawbacks. >> >> Instead of introducing public APIs or special-casing JMH methods in JVM, we can hook a new command to compiler control, and let JMH sign up its `Blackhole` methods for it with `-XX:CompileCommand=blackhole,org.openjdk.jmh.infra.Blackhole::consume`. See CSR and related discussion for alternatives and future plans. >> >> C1 code is platform-independent, and it handles blackhole via the intrinsics paths, lowering it to nothing. >> >> C2 makes the `Blackhole` the subclass of `MemBar`, and use the same `Matcher` path as `Op_MemCPUOrder`: it does not match to anything, but it survives until matching, and keeps arguments alive. Additionally, C1 and C2 hooks are now using the synthetic `_blackhole` intrinsic, similarly to existing `_compiledLambdaForm`. It avoids introducing new nodes in C1. It also seems to require the least fiddling with C2 internals. > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: > > - Merge branch 'master' into JDK-8259316-blackholes-redo > - Redo BlackholeIntrinsicTest to see if target blackhole methods were indeed intrinsified > - Rename BlackholeStaticTest to BlackholeIntrinsicTest > - BlackholeStaticTest should unlock blackholes > - Do not print double-warning on blackhole already set > - Add more checks for C2 intrinsic > - Simplify intrinsic test and add warning test > - Common the blackhole checks > - Binding JVMCI through get_jvmci_method > - Merge branch 'master' into JDK-8259316-blackholes-redo > - ... and 11 more: https://git.openjdk.java.net/jdk/compare/ed477da9...7f4f94d6 Good. Please, update copyright year in files you touched. ------------- Marked as reviewed by kvn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/2024 From github.com+168222+mgkwill at openjdk.java.net Wed Apr 21 17:29:31 2021 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Wed, 21 Apr 2021 17:29:31 GMT Subject: RFR: 8265491: Math Signum optimization for x86 [v2] In-Reply-To: <-Wq9ER4LeGazK0GmnIqjEhLzjGbWA_X_gYjN2Rog9zs=.dde56832-6a13-4f33-b2b2-e034fbec786f@github.com> References: <-Wq9ER4LeGazK0GmnIqjEhLzjGbWA_X_gYjN2Rog9zs=.dde56832-6a13-4f33-b2b2-e034fbec786f@github.com> Message-ID: On Wed, 21 Apr 2021 05:28:38 GMT, Jatin Bhateja wrote: >> Do you mean `instruct signumF_reg`? Please explain your reasoning for the proposed move. > > I am referring to moving the instruction sequence into a macro assembly routine for better code sharing, one should be enough for both float and double type, please refer to following snippet for more detail. > https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L5672 Hi @jatin-bhateja your original request was quite unclear. The highlighting of the code was incorrect and the use of 'this' made it unclear what you were suggesting and you did not explain a reason for the suggestion. > Can you kindly move **this** into a macro assembly routine. Seeing "better code sharing" as the reason it's unclear to me if the proposed refactor results in any meaningful benefit for the work involved. It's also unclear if there are any hard code structure or style issues that would necessitate the move. The refactor you suggest calls for the instruction sequences here to be moved into a src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp function that is then called here. Inside that function there is a selection between float and double but otherwise stays the same except one is formatted .AD and one is .CPP/.HPP. If I am doing this refactor for `instruct signumF_reg` and `instruct signumD_reg` to cut down on code duplication, I see that as close to a wash for saving of code lines and effort involved. I also think this would make the code more complex to read. However if there are strong opinions as to why this is necessary I'd be happy to hear them. ------------- PR: https://git.openjdk.java.net/jdk/pull/3581 From github.com+168222+mgkwill at openjdk.java.net Wed Apr 21 17:38:03 2021 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Wed, 21 Apr 2021 17:38:03 GMT Subject: RFR: 8265491: Math Signum optimization for x86 [v3] In-Reply-To: References: Message-ID: <8HCZEiL6_Gfv36clgI91Okyzf0zOp1VulIgLRe-3Lic=.a03d4ce7-71b3-44ea-bca8-cef03f6c70fe@github.com> > x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM. > > We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization. > > Base: > Benchmark Mode Cnt Score Error Units > Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op > Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op > Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op > Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op > > Optimized: > signum intrinsic patch > Benchmark Mode Cnt Score Error Units > Signum._1_signumFloatTest avgt 5 3.782 ? 0.019 ns/op > Signum._2_overheadFloat avgt 5 3.309 ? 0.011 ns/op > Signum._3_signumDoubleTest avgt 5 3.782 ? 0.017 ns/op > Signum._4_overheadDouble avgt 5 3.310 ? 0.006 ns/op > > Signed-off-by: Marcus G K Williams Marcus G K Williams has updated the pull request incrementally with two additional commits since the last revision: - Remove requires os.arch from TestSignumIntrinsic Signed-off-by: Marcus G K Williams - Add predicate to signum intrinsics Signed-off-by: Marcus G K Williams ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3581/files - new: https://git.openjdk.java.net/jdk/pull/3581/files/99a2971d..a6d670be Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3581&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3581&range=01-02 Stats: 3 lines in 2 files changed: 2 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3581.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3581/head:pull/3581 PR: https://git.openjdk.java.net/jdk/pull/3581 From iignatyev at openjdk.java.net Wed Apr 21 17:46:36 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Wed, 21 Apr 2021 17:46:36 GMT Subject: RFR: 8259316: [REDO] C1/C2 compiler support for blackholes In-Reply-To: References: Message-ID: <8iISzMjc07ATtdgcPJ90Dn25FhQGS1Ofu713-qiCq_M=.1e9eab51-0d40-4029-a7ad-39ebdd6a7c97@github.com> On Wed, 21 Apr 2021 10:27:56 GMT, Aleksey Shipilev wrote: >> This reworks the compiler support for blackholes. The key difference against the last version (#1203) is that blackholes are only acceptable as empty static methods, which both simplifies the implementation and eliminates a few compatibility questions. >> >> JMH uses the `Blackhole::consume` methods to avoid dead-code elimination of the code that produces benchmark values. It now relies on producing opaque side-effects and breaking inlining. While it was proved useful for many years, it unfortunately comes with several major drawbacks. >> >> Instead of introducing public APIs or special-casing JMH methods in JVM, we can hook a new command to compiler control, and let JMH sign up its `Blackhole` methods for it with `-XX:CompileCommand=blackhole,org.openjdk.jmh.infra.Blackhole::consume`. See CSR and related discussion for alternatives and future plans. >> >> C1 code is platform-independent, and it handles blackhole via the intrinsics paths, lowering it to nothing. >> >> C2 makes the `Blackhole` the subclass of `MemBar`, and use the same `Matcher` path as `Op_MemCPUOrder`: it does not match to anything, but it survives until matching, and keeps arguments alive. Additionally, C1 and C2 hooks are now using the synthetic `_blackhole` intrinsic, similarly to existing `_compiledLambdaForm`. It avoids introducing new nodes in C1. It also seems to require the least fiddling with C2 internals. > > CSR is approved, I would appreciate some code reviews. @shipilev , as your tests ignore external vm flags you should add `@requires vm.flagless` so we won't waste time on running them with different GC, JITs, etc. to restore the balance in test descriptions, you might want to delete `@build compiler.blackhole.BlackholeTarget` as there is a statically detectable dependency b/w `compiler.blackhole.*Test` and `BlackholeTarget` hence jtreg/javac will build it while building `compiler.blackhole.*Test` Thanks, -- Igor ------------- PR: https://git.openjdk.java.net/jdk/pull/2024 From github.com+168222+mgkwill at openjdk.java.net Wed Apr 21 18:03:39 2021 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Wed, 21 Apr 2021 18:03:39 GMT Subject: RFR: 8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v27] In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 12:46:21 GMT, Thomas Stuefe wrote: > Nice, an easy approach should be to just remove all large page sizes larger than the decided maximum from _page_sizes. Sounds like a good approach, I'll do that. >> * Do we allow explicit -XX:LargePageSizeInBytes=0 ? Seems somewhat pointless. Do we handle it today? > Actually we don't, but we probably should handle it. Would be kind of strange preventing someone from setting the default. How should we handle this differently? ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From github.com+168222+mgkwill at openjdk.java.net Wed Apr 21 18:44:19 2021 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Wed, 21 Apr 2021 18:44:19 GMT Subject: RFR: 8265491: Math Signum optimization for x86 [v2] In-Reply-To: <6q9w2ylkC6SGEN7-9WeO6qCXhEvNqO3JJAQHWx40GkM=.022014cb-b8e9-4f05-86e9-e855fe4cc6f0@github.com> References: <6q9w2ylkC6SGEN7-9WeO6qCXhEvNqO3JJAQHWx40GkM=.022014cb-b8e9-4f05-86e9-e855fe4cc6f0@github.com> Message-ID: On Wed, 21 Apr 2021 03:56:44 GMT, Jie Fu wrote: >> Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision: >> >> Add os.arch=="i386" to signum jtreg >> >> Signed-off-by: Marcus G K Williams > > src/hotspot/cpu/x86/x86.ad line 5788: > >> 5786: >> 5787: __ ucomiss($dst$$XMMRegister, $zero$$XMMRegister); >> 5788: __ jcc(Assembler::parity, exit); > > How about checking equal first and then parity? > > I think the unordered case is rare in real programs. +1 > src/hotspot/cpu/x86/x86.ad line 5792: > >> 5790: __ movflt($dst$$XMMRegister, $one$$XMMRegister); >> 5791: __ jcc(Assembler::above, exit); >> 5792: __ movflt($dst$$XMMRegister, $zero$$XMMRegister); > > Is it possible to use just one instruction to assign -1 to $dst? > > Maybe, you can try to follow negF_reg/negF_reg_reg. Good idea. Changed to use `xorps($dst$$XMMRegister, ExternalAddress(float_signflip()));` and `xorpd($dst$$XMMRegister, ExternalAddress(double_signflip()));` ------------- PR: https://git.openjdk.java.net/jdk/pull/3581 From github.com+168222+mgkwill at openjdk.java.net Wed Apr 21 18:46:46 2021 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Wed, 21 Apr 2021 18:46:46 GMT Subject: RFR: 8265491: Math Signum optimization for x86 [v4] In-Reply-To: References: Message-ID: <0VJzL5kKixle3AEe3M6VefPBVAehsEepNrFSyumpoxM=.560b904f-7ca9-42cc-ad3f-684b8b86313b@github.com> On Wed, 21 Apr 2021 17:47:12 GMT, Marcus G K Williams wrote: >> x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM. >> >> We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization. >> >> Base: >> >> Benchmark Mode Cnt Score Error Units >> Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op >> Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op >> Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op >> Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op >> >> >> Optimized: >> signum intrinsic patch >> >> Benchmark Mode Cnt Score Error Units >> Signum._1_signumFloatTest avgt 5 3.769 ? 0.015 ns/op >> Signum._2_overheadFloat avgt 5 3.312 ? 0.025 ns/op >> Signum._3_signumDoubleTest avgt 5 3.765 ? 0.005 ns/op >> Signum._4_overheadDouble avgt 5 3.309 ? 0.010 ns/op >> >> >> Signed-off-by: Marcus G K Williams > > Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision: > > Fix predicate > > Signed-off-by: Marcus G K Williams Updated benchmarks from patch updated from comments of @DamonFool: Benchmark Mode Cnt Score Error Units Signum._1_signumFloatTest avgt 5 3.769 ? 0.015 ns/op Signum._2_overheadFloat avgt 5 3.312 ? 0.025 ns/op Signum._3_signumDoubleTest avgt 5 3.765 ? 0.005 ns/op Signum._4_overheadDouble avgt 5 3.309 ? 0.010 ns/op Updated Summary. ------------- PR: https://git.openjdk.java.net/jdk/pull/3581 From github.com+168222+mgkwill at openjdk.java.net Wed Apr 21 17:47:12 2021 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Wed, 21 Apr 2021 17:47:12 GMT Subject: RFR: 8265491: Math Signum optimization for x86 [v4] In-Reply-To: References: Message-ID: > x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM. > > We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization. > > Base: > Benchmark Mode Cnt Score Error Units > Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op > Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op > Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op > Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op > > Optimized: > signum intrinsic patch > Benchmark Mode Cnt Score Error Units > Signum._1_signumFloatTest avgt 5 3.782 ? 0.019 ns/op > Signum._2_overheadFloat avgt 5 3.309 ? 0.011 ns/op > Signum._3_signumDoubleTest avgt 5 3.782 ? 0.017 ns/op > Signum._4_overheadDouble avgt 5 3.310 ? 0.006 ns/op > > Signed-off-by: Marcus G K Williams Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision: Fix predicate Signed-off-by: Marcus G K Williams ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3581/files - new: https://git.openjdk.java.net/jdk/pull/3581/files/a6d670be..0349468b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3581&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3581&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3581.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3581/head:pull/3581 PR: https://git.openjdk.java.net/jdk/pull/3581 From github.com+168222+mgkwill at openjdk.java.net Wed Apr 21 18:44:14 2021 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Wed, 21 Apr 2021 18:44:14 GMT Subject: RFR: 8265491: Math Signum optimization for x86 [v5] In-Reply-To: References: Message-ID: <4KS_ollgdqiNeQgI-XB2AKVJwpgtTo8lRRCwUvqTryk=.8597bbde-a56b-4d2a-a59c-8e80c83b3ec2@github.com> > x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM. > > We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization. > > Base: > Benchmark Mode Cnt Score Error Units > Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op > Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op > Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op > Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op > > Optimized: > signum intrinsic patch > Benchmark Mode Cnt Score Error Units > Signum._1_signumFloatTest avgt 5 3.782 ? 0.019 ns/op > Signum._2_overheadFloat avgt 5 3.309 ? 0.011 ns/op > Signum._3_signumDoubleTest avgt 5 3.782 ? 0.017 ns/op > Signum._4_overheadDouble avgt 5 3.310 ? 0.006 ns/op > > Signed-off-by: Marcus G K Williams Marcus G K Williams has updated the pull request incrementally with two additional commits since the last revision: - Reorder jcc equal,parity Signed-off-by: Marcus G K Williams - Use xorp to negate 1 Signed-off-by: Marcus G K Williams ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3581/files - new: https://git.openjdk.java.net/jdk/pull/3581/files/0349468b..895eab4d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3581&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3581&range=03-04 Stats: 8 lines in 1 file changed: 2 ins; 4 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3581.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3581/head:pull/3581 PR: https://git.openjdk.java.net/jdk/pull/3581 From amenkov at openjdk.java.net Wed Apr 21 20:51:49 2021 From: amenkov at openjdk.java.net (Alex Menkov) Date: Wed, 21 Apr 2021 20:51:49 GMT Subject: RFR: 8262002: java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.sh failed with "TestCaseScaffoldException: DummyClassWithLVT did not match .class file" [v2] In-Reply-To: References: Message-ID: > The test actually failed starting from jdk13, but the error is masked by JDK-8264667 (and shell part of the test didn't verify result of the java execution) > The fix: > - updates JvmtiClassFileReconstituter to add attributes in the same order as javac does > - makes the test java instead of shell > - added workaround for JDK-8264667 > - test code is ready to ignore order of attributes Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: Updated the fix accordingly feedback ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3426/files - new: https://git.openjdk.java.net/jdk/pull/3426/files/62b5b474..67ce2ea0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3426&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3426&range=00-01 Stats: 30 lines in 2 files changed: 1 ins; 6 del; 23 mod Patch: https://git.openjdk.java.net/jdk/pull/3426.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3426/head:pull/3426 PR: https://git.openjdk.java.net/jdk/pull/3426 From amenkov at openjdk.java.net Wed Apr 21 20:51:51 2021 From: amenkov at openjdk.java.net (Alex Menkov) Date: Wed, 21 Apr 2021 20:51:51 GMT Subject: RFR: 8262002: java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.sh failed with "TestCaseScaffoldException: DummyClassWithLVT did not match .class file" [v2] In-Reply-To: References: Message-ID: On Thu, 15 Apr 2021 03:14:34 GMT, Serguei Spitsyn wrote: >> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated the fix accordingly feedback > > test/jdk/java/lang/instrument/ATransformerManagementTestCase.java line 125: > >> 123: manager.addTransformer(transformer, canRetransform); >> 124: // verbosePrint("Added transformer " + transformer >> 125: // + " with canRetransform=" + canRetransform); > > I'd suggest to remove the commented out lines. fixed > test/jdk/java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.java line 152: > >> 150: // directory so there is no conflict with the file >> 151: // in the test classes directory. >> 152: String resourceName = fTargetClassName + ".class"; > > This name can be defined out of methods `originalTargetClassFile` and `transformClassFile`. The method name `transformClassFile` is confusing. I'd suggest to rename it to `transformedClassFile` or `modifiedClassFile`. Also, the name `originalTargetClassFile` can be shortened to `originalClassFile`. done > test/jdk/java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.java line 186: > >> 184: int lineNum = 0; >> 185: for (String line: out1) { >> 186: if (expectedDiffenent(line)) { > > Is it possible to use the `expectedDiffenent()` as a filter to get only needed lines from `disassembleClassFile()`? It's implemented this way to keep lineNum correct. But it was error here. Fixed now ------------- PR: https://git.openjdk.java.net/jdk/pull/3426 From amenkov at openjdk.java.net Wed Apr 21 20:51:52 2021 From: amenkov at openjdk.java.net (Alex Menkov) Date: Wed, 21 Apr 2021 20:51:52 GMT Subject: RFR: 8262002: java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.sh failed with "TestCaseScaffoldException: DummyClassWithLVT did not match .class file" [v2] In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 20:46:43 GMT, Alex Menkov wrote: >> test/jdk/java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.java line 186: >> >>> 184: int lineNum = 0; >>> 185: for (String line: out1) { >>> 186: if (expectedDiffenent(line)) { >> >> Is it possible to use the `expectedDiffenent()` as a filter to get only needed lines from `disassembleClassFile()`? > > It's implemented this way to keep lineNum correct. But it was error here. Fixed now And fixed typo in the method name ------------- PR: https://git.openjdk.java.net/jdk/pull/3426 From pliden at openjdk.java.net Wed Apr 21 21:16:48 2021 From: pliden at openjdk.java.net (Per Liden) Date: Wed, 21 Apr 2021 21:16:48 GMT Subject: RFR: 8265702: ZGC on macOS/aarch64 Message-ID: This patch enables ZGC on macOS/aarch64. It does three things: 1) Enables building of ZGC on this platform. 2) Adds `os::processor_id()`, which for now always returns 0. 3) Fixes a WX issue in `OptoRuntime::handle_exception_C()`, where the stackwater mark might unnecessarily process a frame when the thread is in WXExec mode. In this case, the we're not touching any oops, so we don't need to process any frames. Testing: Passes the same tests as macOS/x86_64 (with the exception of pre-existing issues unrelated to ZGC). ------------- Commit messages: - 8265702: ZGC on macOS/aarch64 Changes: https://git.openjdk.java.net/jdk/pull/3609/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3609&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265702 Stats: 13 lines in 3 files changed: 7 ins; 1 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/3609.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3609/head:pull/3609 PR: https://git.openjdk.java.net/jdk/pull/3609 From minqi at openjdk.java.net Wed Apr 21 22:42:38 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 21 Apr 2021 22:42:38 GMT Subject: RFR: 8255493: Support for pre-generated java.lang.invoke classes in CDS dynamic archive Message-ID: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> Hi, Please review When do dynamic dump, the pre-generated lambda form classes from java.lang.invoke are not stored in dynamic archive. The patch will regenerate the four holder classes, "java.lang.invoke.Invokers$Holder", "java.lang.invoke.DirectMethodHandle$Holder", "java.lang.invoke.DelegatingMethodHandle$Holder", "java.lang.invoke.LambdaForm$Holder" which will include the versions in static archive and new loaded functions all together and stored in dynamic archive. New test case added. (Minor change to PrintSharedArchiveAtExit, which the index is not consecutive) Tests: tier1,tier2,tier3,tier4 Thanks Yumin ------------- Commit messages: - 8255493: Support for pre-generated java.lang.invoke classes in CDS dynamic archive Changes: https://git.openjdk.java.net/jdk/pull/3611/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3611&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255493 Stats: 273 lines in 11 files changed: 238 ins; 14 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/3611.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3611/head:pull/3611 PR: https://git.openjdk.java.net/jdk/pull/3611 From iklam at openjdk.java.net Wed Apr 21 22:57:51 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 21 Apr 2021 22:57:51 GMT Subject: RFR: 8265696 move cds sources Message-ID: The number of CDS source files have grown significantly. To improve modularity, the following files should be moved a new directory, src/hotspot/share/cds. - src/hotspot/share/classfile/classListParser.cpp - src/hotspot/share/classfile/classListParser.hpp - src/hotspot/share/classfile/classListWriter.hpp - src/hotspot/share/classfile/compactHashtable.cpp - src/hotspot/share/classfile/compactHashtable.hpp - src/hotspot/share/classfile/lambdaFormInvokers.cpp - src/hotspot/share/classfile/lambdaFormInvokers.hpp - src/hotspot/share/memory/archiveBuilder.cpp - src/hotspot/share/memory/archiveBuilder.hpp - src/hotspot/share/memory/archiveUtils.cpp - src/hotspot/share/memory/archiveUtils.hpp - src/hotspot/share/memory/archiveUtils.inline.hpp - src/hotspot/share/memory/cppVtables.cpp - src/hotspot/share/memory/cppVtables.hpp - src/hotspot/share/memory/dumpAllocStats.cpp - src/hotspot/share/memory/dumpAllocStats.hpp - src/hotspot/share/memory/dynamicArchive.cpp - src/hotspot/share/memory/dynamicArchive.hpp - src/hotspot/share/memory/filemap.cpp - src/hotspot/share/memory/filemap.hpp - src/hotspot/share/memory/heapShared.cpp - src/hotspot/share/memory/heapShared.hpp - src/hotspot/share/memory/heapShared.inline.hpp - src/hotspot/share/memory/metaspaceShared.cpp - src/hotspot/share/memory/metaspaceShared.hpp - src/hotspot/share/prims/cdsoffsets.cpp - src/hotspot/share/prims/cdsoffsets.hpp Testing with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. ------------- Commit messages: - fixed copyright - moved more files - fixed include lines - 8265696: Move CDS sources from shared/memory to shared/cds Changes: https://git.openjdk.java.net/jdk/pull/3610/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3610&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265696 Stats: 275 lines in 78 files changed: 116 ins; 134 del; 25 mod Patch: https://git.openjdk.java.net/jdk/pull/3610.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3610/head:pull/3610 PR: https://git.openjdk.java.net/jdk/pull/3610 From iklam at openjdk.java.net Wed Apr 21 22:57:52 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 21 Apr 2021 22:57:52 GMT Subject: RFR: 8265696 move cds sources In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 21:55:25 GMT, Ioi Lam wrote: > The number of CDS source files have grown significantly. To improve modularity, the following files should be moved a new directory, src/hotspot/share/cds. > > - src/hotspot/share/classfile/classListParser.cpp > - src/hotspot/share/classfile/classListParser.hpp > - src/hotspot/share/classfile/classListWriter.hpp > - src/hotspot/share/classfile/compactHashtable.cpp > - src/hotspot/share/classfile/compactHashtable.hpp > - src/hotspot/share/classfile/lambdaFormInvokers.cpp > - src/hotspot/share/classfile/lambdaFormInvokers.hpp > - src/hotspot/share/memory/archiveBuilder.cpp > - src/hotspot/share/memory/archiveBuilder.hpp > - src/hotspot/share/memory/archiveUtils.cpp > - src/hotspot/share/memory/archiveUtils.hpp > - src/hotspot/share/memory/archiveUtils.inline.hpp > - src/hotspot/share/memory/cppVtables.cpp > - src/hotspot/share/memory/cppVtables.hpp > - src/hotspot/share/memory/dumpAllocStats.cpp > - src/hotspot/share/memory/dumpAllocStats.hpp > - src/hotspot/share/memory/dynamicArchive.cpp > - src/hotspot/share/memory/dynamicArchive.hpp > - src/hotspot/share/memory/filemap.cpp > - src/hotspot/share/memory/filemap.hpp > - src/hotspot/share/memory/heapShared.cpp > - src/hotspot/share/memory/heapShared.hpp > - src/hotspot/share/memory/heapShared.inline.hpp > - src/hotspot/share/memory/metaspaceShared.cpp > - src/hotspot/share/memory/metaspaceShared.hpp > - src/hotspot/share/prims/cdsoffsets.cpp > - src/hotspot/share/prims/cdsoffsets.hpp > > Testing with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. make/hotspot/lib/JvmFeatures.gmk line 134: > 132: metaspaceShared_$(HOTSPOT_TARGET_CPU_ARCH).cpp \ > 133: sharedClassUtil.cpp \ > 134: sharedPathsMiscInfo.cpp \ Removed obsolete files that no longer exist. src/hotspot/os/windows/os_windows.cpp line 42: > 40: #include "logging/logStream.hpp" > 41: #include "memory/allocation.inline.hpp" > 42: #include "oops/oop.inline.hpp" Removed some unnecessary inclusions. ------------- PR: https://git.openjdk.java.net/jdk/pull/3610 From erikj at openjdk.java.net Wed Apr 21 23:07:20 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 21 Apr 2021 23:07:20 GMT Subject: RFR: 8265702: ZGC on macOS/aarch64 In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 21:10:02 GMT, Per Liden wrote: > This patch enables ZGC on macOS/aarch64. It does three things: > 1) Enables building of ZGC on this platform. > 2) Adds `os::processor_id()`, which for now always returns 0. > 3) Fixes a WX issue in `OptoRuntime::handle_exception_C()`, where the stackwater mark might unnecessarily process a frame when the thread is in WXExec mode. In this case, the we're not touching any oops, so we don't need to process any frames. > > Testing: Passes the same tests as macOS/x86_64 (with the exception of pre-existing issues unrelated to ZGC). Build change looks good. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3609 From github.com+168222+mgkwill at openjdk.java.net Wed Apr 21 23:08:23 2021 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Wed, 21 Apr 2021 23:08:23 GMT Subject: RFR: 8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v27] In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 12:46:21 GMT, Thomas Stuefe wrote: > I found some other CSRs that had different titels compared to the issues, so change it. Maybe we should also change the name of this issue as well. To something like: > Allow multiple large page sizes to be used on Linux I'd be in favor of this. ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From erikj at openjdk.java.net Wed Apr 21 23:10:22 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 21 Apr 2021 23:10:22 GMT Subject: RFR: 8265696 move cds sources In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 22:04:13 GMT, Ioi Lam wrote: >> The number of CDS source files have grown significantly. To improve modularity, the following files should be moved a new directory, src/hotspot/share/cds. >> >> - src/hotspot/share/classfile/classListParser.cpp >> - src/hotspot/share/classfile/classListParser.hpp >> - src/hotspot/share/classfile/classListWriter.hpp >> - src/hotspot/share/classfile/compactHashtable.cpp >> - src/hotspot/share/classfile/compactHashtable.hpp >> - src/hotspot/share/classfile/lambdaFormInvokers.cpp >> - src/hotspot/share/classfile/lambdaFormInvokers.hpp >> - src/hotspot/share/memory/archiveBuilder.cpp >> - src/hotspot/share/memory/archiveBuilder.hpp >> - src/hotspot/share/memory/archiveUtils.cpp >> - src/hotspot/share/memory/archiveUtils.hpp >> - src/hotspot/share/memory/archiveUtils.inline.hpp >> - src/hotspot/share/memory/cppVtables.cpp >> - src/hotspot/share/memory/cppVtables.hpp >> - src/hotspot/share/memory/dumpAllocStats.cpp >> - src/hotspot/share/memory/dumpAllocStats.hpp >> - src/hotspot/share/memory/dynamicArchive.cpp >> - src/hotspot/share/memory/dynamicArchive.hpp >> - src/hotspot/share/memory/filemap.cpp >> - src/hotspot/share/memory/filemap.hpp >> - src/hotspot/share/memory/heapShared.cpp >> - src/hotspot/share/memory/heapShared.hpp >> - src/hotspot/share/memory/heapShared.inline.hpp >> - src/hotspot/share/memory/metaspaceShared.cpp >> - src/hotspot/share/memory/metaspaceShared.hpp >> - src/hotspot/share/prims/cdsoffsets.cpp >> - src/hotspot/share/prims/cdsoffsets.hpp >> >> Testing with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. > > make/hotspot/lib/JvmFeatures.gmk line 134: > >> 132: metaspaceShared_$(HOTSPOT_TARGET_CPU_ARCH).cpp \ >> 133: sharedClassUtil.cpp \ >> 134: sharedPathsMiscInfo.cpp \ > > Removed obsolete files that no longer exist. Thank you! ------------- PR: https://git.openjdk.java.net/jdk/pull/3610 From erikj at openjdk.java.net Wed Apr 21 23:10:21 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 21 Apr 2021 23:10:21 GMT Subject: RFR: 8265696 move cds sources In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 21:55:25 GMT, Ioi Lam wrote: > The number of CDS source files have grown significantly. To improve modularity, the following files should be moved a new directory, src/hotspot/share/cds. > > - src/hotspot/share/classfile/classListParser.cpp > - src/hotspot/share/classfile/classListParser.hpp > - src/hotspot/share/classfile/classListWriter.hpp > - src/hotspot/share/classfile/compactHashtable.cpp > - src/hotspot/share/classfile/compactHashtable.hpp > - src/hotspot/share/classfile/lambdaFormInvokers.cpp > - src/hotspot/share/classfile/lambdaFormInvokers.hpp > - src/hotspot/share/memory/archiveBuilder.cpp > - src/hotspot/share/memory/archiveBuilder.hpp > - src/hotspot/share/memory/archiveUtils.cpp > - src/hotspot/share/memory/archiveUtils.hpp > - src/hotspot/share/memory/archiveUtils.inline.hpp > - src/hotspot/share/memory/cppVtables.cpp > - src/hotspot/share/memory/cppVtables.hpp > - src/hotspot/share/memory/dumpAllocStats.cpp > - src/hotspot/share/memory/dumpAllocStats.hpp > - src/hotspot/share/memory/dynamicArchive.cpp > - src/hotspot/share/memory/dynamicArchive.hpp > - src/hotspot/share/memory/filemap.cpp > - src/hotspot/share/memory/filemap.hpp > - src/hotspot/share/memory/heapShared.cpp > - src/hotspot/share/memory/heapShared.hpp > - src/hotspot/share/memory/heapShared.inline.hpp > - src/hotspot/share/memory/metaspaceShared.cpp > - src/hotspot/share/memory/metaspaceShared.hpp > - src/hotspot/share/prims/cdsoffsets.cpp > - src/hotspot/share/prims/cdsoffsets.hpp > > Testing with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. Build changes look good. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3610 From jiefu at openjdk.java.net Wed Apr 21 23:56:22 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Wed, 21 Apr 2021 23:56:22 GMT Subject: RFR: 8265491: Math Signum optimization for x86 [v5] In-Reply-To: <4KS_ollgdqiNeQgI-XB2AKVJwpgtTo8lRRCwUvqTryk=.8597bbde-a56b-4d2a-a59c-8e80c83b3ec2@github.com> References: <4KS_ollgdqiNeQgI-XB2AKVJwpgtTo8lRRCwUvqTryk=.8597bbde-a56b-4d2a-a59c-8e80c83b3ec2@github.com> Message-ID: On Wed, 21 Apr 2021 18:44:14 GMT, Marcus G K Williams wrote: >> x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM. >> >> We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization. >> >> Base: >> >> Benchmark Mode Cnt Score Error Units >> Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op >> Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op >> Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op >> Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op >> >> >> Optimized: >> signum intrinsic patch >> >> Benchmark Mode Cnt Score Error Units >> Signum._1_signumFloatTest avgt 5 3.769 ? 0.015 ns/op >> Signum._2_overheadFloat avgt 5 3.312 ? 0.025 ns/op >> Signum._3_signumDoubleTest avgt 5 3.765 ? 0.005 ns/op >> Signum._4_overheadDouble avgt 5 3.309 ? 0.010 ns/op >> >> >> Signed-off-by: Marcus G K Williams > > Marcus G K Williams has updated the pull request incrementally with two additional commits since the last revision: > > - Reorder jcc equal,parity > > Signed-off-by: Marcus G K Williams > - Use xorp to negate 1 > > Signed-off-by: Marcus G K Williams src/hotspot/cpu/x86/vm_version_x86.cpp line 1703: > 1701: } > 1702: #endif // !PRODUCT > 1703: if (FLAG_IS_DEFAULT(UseSignumIntrinsic) && (UseSSE >= 2)) { `UseSSE >=2` looks a bit uncomfortable to me since signumF_reg only requires UseSSE>=1. How about something like this: diff --git a/src/hotspot/cpu/x86/x86.ad b/src/hotspot/cpu/x86/x86.ad index bbf5256c112..0a738704c4d 100644 --- a/src/hotspot/cpu/x86/x86.ad +++ b/src/hotspot/cpu/x86/x86.ad @@ -1598,6 +1598,16 @@ const bool Matcher::match_rule_supported(int opcode) { return false; } break; + case Op_SignumF: + if (UseSSE < 1) { + return false; + } + break; + case Op_SignumD: + if (UseSSE < 2) { + return false; + } + break; #endif // !LP64 } return true; // Match rules are supported by default. diff --git a/src/hotspot/share/opto/library_call.cpp b/src/hotspot/share/opto/library_call.cpp index 7cb7955c612..217ee39d709 100644 --- a/src/hotspot/share/opto/library_call.cpp +++ b/src/hotspot/share/opto/library_call.cpp @@ -1737,8 +1737,8 @@ bool LibraryCallKit::inline_math_native(vmIntrinsics::ID id) { case vmIntrinsics::_dpow: return inline_math_pow(); case vmIntrinsics::_dcopySign: return inline_double_math(id); case vmIntrinsics::_fcopySign: return inline_math(id); - case vmIntrinsics::_dsignum: return inline_double_math(id); - case vmIntrinsics::_fsignum: return inline_math(id); + case vmIntrinsics::_dsignum: return Matcher::match_rule_supported(Op_SignumD) ? inline_double_math(id) : false; + case vmIntrinsics::_fsignum: return Matcher::match_rule_supported(Op_SignumF) ? inline_math(id) : false; // These intrinsics are not yet correctly implemented case vmIntrinsics::_datan2: In this way, we can enable UseSignumIntrinsic by default on x86. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/3581 From david.holmes at oracle.com Thu Apr 22 01:57:31 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 22 Apr 2021 11:57:31 +1000 Subject: RFR: 8255493: Support for pre-generated java.lang.invoke classes in CDS dynamic archive In-Reply-To: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> References: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> Message-ID: Hi Yumin, On 22/04/2021 8:42 am, Yumin Qi wrote: > Hi, Please review > > When do dynamic dump, the pre-generated lambda form classes from java.lang.invoke are not stored in dynamic archive. The patch will regenerate the four holder classes, > "java.lang.invoke.Invokers$Holder", > "java.lang.invoke.DirectMethodHandle$Holder", > "java.lang.invoke.DelegatingMethodHandle$Holder", > "java.lang.invoke.LambdaForm$Holder" > which will include the versions in static archive and new loaded functions all together and stored in dynamic archive. New test case added. > (Minor change to PrintSharedArchiveAtExit, which the index is not consecutive) Meta questions: - why are they not already stored? - why do we need them to be stored? - can we avoid hardwiring a set of classes that then tightly couples our code to the JDK code in a way that we may not easily detect breakages? Thanks, David > Tests: tier1,tier2,tier3,tier4 > > Thanks > Yumin > > ------------- > > Commit messages: > - 8255493: Support for pre-generated java.lang.invoke classes in CDS dynamic archive > > Changes: https://git.openjdk.java.net/jdk/pull/3611/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3611&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8255493 > Stats: 273 lines in 11 files changed: 238 ins; 14 del; 21 mod > Patch: https://git.openjdk.java.net/jdk/pull/3611.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/3611/head:pull/3611 > > PR: https://git.openjdk.java.net/jdk/pull/3611 > From minqi at openjdk.java.net Thu Apr 22 03:51:21 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 22 Apr 2021 03:51:21 GMT Subject: RFR: 8255493: Support for pre-generated java.lang.invoke classes in CDS dynamic archive In-Reply-To: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> References: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> Message-ID: On Wed, 21 Apr 2021 22:34:48 GMT, Yumin Qi wrote: > Hi, Please review > > When do dynamic dump, the pre-generated lambda form classes from java.lang.invoke are not stored in dynamic archive. The patch will regenerate the four holder classes, > "java.lang.invoke.Invokers$Holder", > "java.lang.invoke.DirectMethodHandle$Holder", > "java.lang.invoke.DelegatingMethodHandle$Holder", > "java.lang.invoke.LambdaForm$Holder" > which will include the versions in static archive and new loaded functions all together and stored in dynamic archive. New test case added. > (Minor change to PrintSharedArchiveAtExit, which the index is not consecutive) > > Tests: tier1,tier2,tier3,tier4 > > Thanks > Yumin > _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [hotspot-dev](mailto:hotspot-dev at mail.openjdk.java.net):_ > > Hi Yumin, > > On 22/04/2021 8:42 am, Yumin Qi wrote: > > > Hi, Please review > > When do dynamic dump, the pre-generated lambda form classes from java.lang.invoke are not stored in dynamic archive. The patch will regenerate the four holder classes, > > "java.lang.invoke.Invokers$Holder", > > "java.lang.invoke.DirectMethodHandle$Holder", > > "java.lang.invoke.DelegatingMethodHandle$Holder", > > "java.lang.invoke.LambdaForm$Holder" > > which will include the versions in static archive and new loaded functions all together and stored in dynamic archive. New test case added. > > (Minor change to PrintSharedArchiveAtExit, which the index is not consecutive) > > Meta questions: > - why are they not already stored? > - why do we need them to be stored? > - can we avoid hardwiring a set of classes that then tightly couples > our code to the JDK code in a way that we may not easily detect breakages? > > Thanks, > David Hi, David 1) When dump static archive, we stored the holder classes which were logged (bug https://bugs.openjdk.java.net/browse/JDK-8247536) during build time. The pre-generated lambda form classes were collected in jlink stage, then regenerated the holder classes which hold the LF functions, stored in static archive. That is, whatever LF forms generated during build are archive in static archive. 2) At runtime, user code Lambda will generate new classes which are not stored into dynamic archive. The holder classes are the four invoke class$holder classes, so we record the lambda format for dynamic dump, regenerate the holder classes which will host both static contents plus the newly loaded contents then stored in dynamic archive. There are two versions of those four holder classes, one is the static version, and the other (bigger) in dynamic, so if dynamic mapped, we use the dynamic versions which host more LF functions. 3) We only regenerate the four holder classes and regardless of the others (species), those four holders host majority of the invoke functions. The names are hardcoded since there are no mapping from jdk to vm for this. Do we have a way to do this? Thanks Yumin ------------- PR: https://git.openjdk.java.net/jdk/pull/3611 From dholmes at openjdk.java.net Thu Apr 22 04:22:25 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 22 Apr 2021 04:22:25 GMT Subject: RFR: 8265696 move cds sources In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 23:05:26 GMT, Erik Joelsson wrote: >> make/hotspot/lib/JvmFeatures.gmk line 134: >> >>> 132: metaspaceShared_$(HOTSPOT_TARGET_CPU_ARCH).cpp \ >>> 133: sharedClassUtil.cpp \ >>> 134: sharedPathsMiscInfo.cpp \ >> >> Removed obsolete files that no longer exist. > > Thank you! I don't suppose we can just exclude the new directory rather than listing individual files? ------------- PR: https://git.openjdk.java.net/jdk/pull/3610 From dholmes at openjdk.java.net Thu Apr 22 04:22:25 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 22 Apr 2021 04:22:25 GMT Subject: RFR: 8265696 move cds sources In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 21:55:25 GMT, Ioi Lam wrote: > The number of CDS source files have grown significantly. To improve modularity, the following files should be moved a new directory, src/hotspot/share/cds. > > - src/hotspot/share/classfile/classListParser.cpp > - src/hotspot/share/classfile/classListParser.hpp > - src/hotspot/share/classfile/classListWriter.hpp > - src/hotspot/share/classfile/compactHashtable.cpp > - src/hotspot/share/classfile/compactHashtable.hpp > - src/hotspot/share/classfile/lambdaFormInvokers.cpp > - src/hotspot/share/classfile/lambdaFormInvokers.hpp > - src/hotspot/share/memory/archiveBuilder.cpp > - src/hotspot/share/memory/archiveBuilder.hpp > - src/hotspot/share/memory/archiveUtils.cpp > - src/hotspot/share/memory/archiveUtils.hpp > - src/hotspot/share/memory/archiveUtils.inline.hpp > - src/hotspot/share/memory/cppVtables.cpp > - src/hotspot/share/memory/cppVtables.hpp > - src/hotspot/share/memory/dumpAllocStats.cpp > - src/hotspot/share/memory/dumpAllocStats.hpp > - src/hotspot/share/memory/dynamicArchive.cpp > - src/hotspot/share/memory/dynamicArchive.hpp > - src/hotspot/share/memory/filemap.cpp > - src/hotspot/share/memory/filemap.hpp > - src/hotspot/share/memory/heapShared.cpp > - src/hotspot/share/memory/heapShared.hpp > - src/hotspot/share/memory/heapShared.inline.hpp > - src/hotspot/share/memory/metaspaceShared.cpp > - src/hotspot/share/memory/metaspaceShared.hpp > - src/hotspot/share/prims/cdsoffsets.cpp > - src/hotspot/share/prims/cdsoffsets.hpp > > Testing with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. Hi Ioi, Moving these files to their own directory is fine, but all the moved headers need further adjustments for the include guards. Thanks, David src/hotspot/share/cds/archiveUtils.inline.hpp line 25: > 23: */ > 24: > 25: #ifndef SHARE_MEMORY_ARCHIVEUTILS_INLINE_HPP The header file include guards all need updating for the new path. src/hotspot/share/cds/dynamicArchive.hpp line 38: > 36: #include "utilities/resourceHash.hpp" > 37: > 38: #if INCLUDE_CDS I have to wonder who is including this file and why, if CDS is not enabled. ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3610 From dholmes at openjdk.java.net Thu Apr 22 04:37:20 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 22 Apr 2021 04:37:20 GMT Subject: RFR: 8265702: ZGC on macOS/aarch64 In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 21:10:02 GMT, Per Liden wrote: > This patch enables ZGC on macOS/aarch64. It does three things: > 1) Enables building of ZGC on this platform. > 2) Adds `os::processor_id()`, which for now always returns 0. > 3) Fixes a WX issue in `OptoRuntime::handle_exception_C()`, where the stackwater mark might unnecessarily process a frame when the thread is in WXExec mode. In this case, the we're not touching any oops, so we don't need to process any frames. > > Testing: Passes the same tests as macOS/x86_64 (with the exception of pre-existing issues unrelated to ZGC). Hi Per, Looks good. One minor nit. Thanks, David src/hotspot/os/bsd/os_bsd.cpp line 2149: > 2147: > 2148: return (uint)processor_id; > 2149: #else Please add a comment indicating what platform this else is referring to. ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3609 From minqi at openjdk.java.net Thu Apr 22 04:56:01 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 22 Apr 2021 04:56:01 GMT Subject: RFR: 8265393: VM crashes if both -XX:+RecordDynamicDumpInfo and -XX:SharedArchiveFile options are specified [v2] In-Reply-To: References: Message-ID: > Hi, Please review > 1) When the two flags -XX:+RecordDynamicDumpInfo and -XX:SharedArchiveFile used, in > Arguments::init_shared_archive_paths() : > if (DynamicDumpSharedSpaces) { > if (os::same_files(SharedArchiveFile, ArchiveClassesAtExit)) { > ... > ArchiveClassesAtExit is NULL. > C++ does not have a defined behavior of strcmp with strings of NULL. Posix version of os::same_files(const char* file1, const char* file2) calls strcmp without checking input args. This should be same as it is treated on Windows. > 2) JCmdTest.java is fat and possible to cause test timeout. Split JCmdTest.java into two separate Tests: JCmdTestStaticDump.java and JCmdTestDynamicDump.java. > 3) Add a test to check run with -XX:+RecordDynamicDumpInfo and -XX:SharedArchiveFile in JCmdTestDynamicDump.java > The test does not use utility to create jvm process since it will take testing envs into process, but the way in the test using LingeredApp does not take envs. > > Tests: tier1,tier2,tier3,tier4 > > Thanks > Yumin Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Abstract common code into base class ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3599/files - new: https://git.openjdk.java.net/jdk/pull/3599/files/948f8586..ae4b3690 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3599&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3599&range=00-01 Stats: 450 lines in 3 files changed: 202 ins; 238 del; 10 mod Patch: https://git.openjdk.java.net/jdk/pull/3599.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3599/head:pull/3599 PR: https://git.openjdk.java.net/jdk/pull/3599 From iklam at openjdk.java.net Thu Apr 22 05:44:00 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 22 Apr 2021 05:44:00 GMT Subject: RFR: 8265101: Remove unnecessary functions in os*.inline.hpp [v2] In-Reply-To: <1nuLsyk3arkBvaLReeV9Y650aSRPNR5uwTTSUSFcz8E=.cf6a62e1-994e-4baf-9a5b-39ea86486719@github.com> References: <1nuLsyk3arkBvaLReeV9Y650aSRPNR5uwTTSUSFcz8E=.cf6a62e1-994e-4baf-9a5b-39ea86486719@github.com> Message-ID: <6Vcemuks-FUZMJtDAmnXIy2mBSA-r7_ct5I8n0mpvJs=.41940da8-e878-470e-b3db-8560db8c0ed5@github.com> > Many functions like `os::write`, `os::exit`, `os::dll_unload`, etc, are implemented in various os*.inline.hpp files. This forces many .hpp and .cpp files to explicitly include "runtime/os.inline.hpp". > > There's no performance reason to inline these functions. They will make a system call, whose overhead is way bigger than the cost of making an extra function call. > > The full list methods moved from `os*inline.hpp` to `os_.cpp` are: > > > os::dll_unload(void *lib) > os::lseek(int fd, jlong offset, int whence) > os::fsync(int fd) > os::ftruncate(int fd, jlong length) > os::read(int fd, void *buf, unsigned int nBytes) > os::write(int fd, const void *buf, unsigned int nBytes) > os::close(int fd) > os::socket_close(int fd) > os::socket(int domain, int type, int protocol) > os::recv(int fd, char* buf, size_t nBytes, uint flags) > os::send(int fd, char* buf, size_t nBytes, uint flags) > os::raw_send(int fd, char* buf, size_t nBytes, uint flags) > os::connect(int fd, struct sockaddr* him, socklen_t len) > os::get_host_by_name(char* name) > os::exit(int num) > > > I also took this chance to remove unnecessary inclusion of os.hpp and os.inline.hpp from various files. I added some missing `#include` directives that were exposed as a result. > > - **Notes for Reviewers**: please start from os*.{hpp,cpp} files first. > - Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Merge branch 'master' into 8265101-remove-unnecessary-os-inline-functions - Merge branch 'master' into 8265101-remove-unnecessary-os-inline-functions - fixed copyright - removed unnecessary include os.hpp - remove unnecessary include os.inline.hpp - step1 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3475/files - new: https://git.openjdk.java.net/jdk/pull/3475/files/399eefcc..67422c61 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3475&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3475&range=00-01 Stats: 70475 lines in 1895 files changed: 31765 ins; 33832 del; 4878 mod Patch: https://git.openjdk.java.net/jdk/pull/3475.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3475/head:pull/3475 PR: https://git.openjdk.java.net/jdk/pull/3475 From iklam at openjdk.java.net Thu Apr 22 05:48:30 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 22 Apr 2021 05:48:30 GMT Subject: Integrated: 8265101: Remove unnecessary functions in os*.inline.hpp In-Reply-To: <1nuLsyk3arkBvaLReeV9Y650aSRPNR5uwTTSUSFcz8E=.cf6a62e1-994e-4baf-9a5b-39ea86486719@github.com> References: <1nuLsyk3arkBvaLReeV9Y650aSRPNR5uwTTSUSFcz8E=.cf6a62e1-994e-4baf-9a5b-39ea86486719@github.com> Message-ID: <1YtUa49c8XZ0_Adl_aBZIBbZJFI_8Wd3HmDFM_tU-KY=.5f263ee7-b413-4418-b8b6-ce9b5cbc3666@github.com> On Tue, 13 Apr 2021 20:11:35 GMT, Ioi Lam wrote: > Many functions like `os::write`, `os::exit`, `os::dll_unload`, etc, are implemented in various os*.inline.hpp files. This forces many .hpp and .cpp files to explicitly include "runtime/os.inline.hpp". > > There's no performance reason to inline these functions. They will make a system call, whose overhead is way bigger than the cost of making an extra function call. > > The full list methods moved from `os*inline.hpp` to `os_.cpp` are: > > > os::dll_unload(void *lib) > os::lseek(int fd, jlong offset, int whence) > os::fsync(int fd) > os::ftruncate(int fd, jlong length) > os::read(int fd, void *buf, unsigned int nBytes) > os::write(int fd, const void *buf, unsigned int nBytes) > os::close(int fd) > os::socket_close(int fd) > os::socket(int domain, int type, int protocol) > os::recv(int fd, char* buf, size_t nBytes, uint flags) > os::send(int fd, char* buf, size_t nBytes, uint flags) > os::raw_send(int fd, char* buf, size_t nBytes, uint flags) > os::connect(int fd, struct sockaddr* him, socklen_t len) > os::get_host_by_name(char* name) > os::exit(int num) > > > I also took this chance to remove unnecessary inclusion of os.hpp and os.inline.hpp from various files. I added some missing `#include` directives that were exposed as a result. > > - **Notes for Reviewers**: please start from os*.{hpp,cpp} files first. > - Tested with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. This pull request has now been integrated. Changeset: 33b6378f Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/33b6378f Stats: 257 lines in 58 files changed: 109 ins; 98 del; 50 mod 8265101: Remove unnecessary functions in os*.inline.hpp Reviewed-by: dholmes, kbarrett ------------- PR: https://git.openjdk.java.net/jdk/pull/3475 From iklam at openjdk.java.net Thu Apr 22 05:48:30 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 22 Apr 2021 05:48:30 GMT Subject: RFR: 8265101: Remove unnecessary functions in os*.inline.hpp [v2] In-Reply-To: References: <1nuLsyk3arkBvaLReeV9Y650aSRPNR5uwTTSUSFcz8E=.cf6a62e1-994e-4baf-9a5b-39ea86486719@github.com> Message-ID: On Wed, 14 Apr 2021 02:46:57 GMT, David Holmes wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: >> >> - Merge branch 'master' into 8265101-remove-unnecessary-os-inline-functions >> - Merge branch 'master' into 8265101-remove-unnecessary-os-inline-functions >> - fixed copyright >> - removed unnecessary include os.hpp >> - remove unnecessary include os.inline.hpp >> - step1 > > Hi Ioi, > > This all seems fine to me. I agree these seem unlikely to need to be inlined for performance. > > Thanks, > David Thanks @dholmes-ora and @kimbarrett for the review. Tested again in mach5 build tiers 1-5. ------------- PR: https://git.openjdk.java.net/jdk/pull/3475 From stefank at openjdk.java.net Thu Apr 22 06:01:26 2021 From: stefank at openjdk.java.net (Stefan Karlsson) Date: Thu, 22 Apr 2021 06:01:26 GMT Subject: RFR: 8265702: ZGC on macOS/aarch64 In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 21:10:02 GMT, Per Liden wrote: > This patch enables ZGC on macOS/aarch64. It does three things: > 1) Enables building of ZGC on this platform. > 2) Adds `os::processor_id()`, which for now always returns 0. > 3) Fixes a WX issue in `OptoRuntime::handle_exception_C()`, where the stackwater mark might unnecessarily process a frame when the thread is in WXExec mode. In this case, the we're not touching any oops, so we don't need to process any frames. > > Testing: Passes the same tests as macOS/x86_64 (with the exception of pre-existing issues unrelated to ZGC). Marked as reviewed by stefank (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3609 From david.holmes at oracle.com Thu Apr 22 06:08:15 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 22 Apr 2021 16:08:15 +1000 Subject: RFR: 8255493: Support for pre-generated java.lang.invoke classes in CDS dynamic archive In-Reply-To: References: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> Message-ID: <5508929f-c377-cf08-3171-77aabaf39b03@oracle.com> On 22/04/2021 1:51 pm, Yumin Qi wrote: >> _Mailing list message from [David Holmes](mailto:david.holmes at oracle.com) on [hotspot-dev](mailto:hotspot-dev at mail.openjdk.java.net):_ >> >> Hi Yumin, >> >> On 22/04/2021 8:42 am, Yumin Qi wrote: >> >>> Hi, Please review >>> When do dynamic dump, the pre-generated lambda form classes from java.lang.invoke are not stored in dynamic archive. The patch will regenerate the four holder classes, >>> "java.lang.invoke.Invokers$Holder", >>> "java.lang.invoke.DirectMethodHandle$Holder", >>> "java.lang.invoke.DelegatingMethodHandle$Holder", >>> "java.lang.invoke.LambdaForm$Holder" >>> which will include the versions in static archive and new loaded functions all together and stored in dynamic archive. New test case added. >>> (Minor change to PrintSharedArchiveAtExit, which the index is not consecutive) >> >> Meta questions: >> - why are they not already stored? >> - why do we need them to be stored? >> - can we avoid hardwiring a set of classes that then tightly couples >> our code to the JDK code in a way that we may not easily detect breakages? >> >> Thanks, >> David > Hi, David > 1) When dump static archive, we stored the holder classes which were logged (bug https://bugs.openjdk.java.net/browse/JDK-8247536) during build time. The pre-generated lambda form classes were collected in jlink stage, then regenerated the holder classes which hold the LF functions, stored in static archive. That is, whatever LF forms generated during build are archive in static archive. Okay I think I get how these classes are generated and then stored in the static archive. > 2) At runtime, user code Lambda will generate new classes which are not stored into dynamic archive. The holder classes are the four invoke class$holder classes, so we record the lambda format for dynamic dump, regenerate the holder classes which will host both static contents plus the newly loaded contents then stored in dynamic archive. There are two versions of those four holder classes, one is the static version, and the other (bigger) in dynamic, so if dynamic mapped, we use the dynamic versions which host more LF functions. Not following this part. How can you regenerate an existing class? I'm not familiar with the details of LF classes and how all that machinery works. > 3) We only regenerate the four holder classes and regardless of the others (species), those four holders host majority of the invoke functions. The names are hardcoded since there are no mapping from jdk to vm for this. Do we have a way to do this? Probably not but that is the problem I'm flagging. Is this list of classes going to grow? If they rework code on the Java side are we going to know what changes to make on the VM side? Is way we can make this less fragile? Thanks, David > > Thanks > Yumin > > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3611 > From dholmes at openjdk.java.net Thu Apr 22 06:08:23 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 22 Apr 2021 06:08:23 GMT Subject: RFR: 8255493: Support for pre-generated java.lang.invoke classes in CDS dynamic archive In-Reply-To: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> References: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> Message-ID: On Wed, 21 Apr 2021 22:34:48 GMT, Yumin Qi wrote: > Hi, Please review > > When do dynamic dump, the pre-generated lambda form classes from java.lang.invoke are not stored in dynamic archive. The patch will regenerate the four holder classes, > "java.lang.invoke.Invokers$Holder", > "java.lang.invoke.DirectMethodHandle$Holder", > "java.lang.invoke.DelegatingMethodHandle$Holder", > "java.lang.invoke.LambdaForm$Holder" > which will include the versions in static archive and new loaded functions all together and stored in dynamic archive. New test case added. > (Minor change to PrintSharedArchiveAtExit, which the index is not consecutive) > > Tests: tier1,tier2,tier3,tier4 > > Thanks > Yumin src/hotspot/share/memory/dynamicArchive.cpp line 374: > 372: if (LambdaFormInvokers::should_regenerate_holder_classes()) { > 373: JavaThread* THREAD = JavaThread::current(); > 374: assert(THREAD->is_Java_thread(), "Should be JavaThread"); JavaThread::current() already asserts this. src/hotspot/share/memory/dynamicArchive.cpp line 376: > 374: assert(THREAD->is_Java_thread(), "Should be JavaThread"); > 375: log_info(cds, dynamic)("Regenerate lambdaform holder classes ..."); > 376: LambdaFormInvokers::regenerate_holder_classes(THREAD); What if this throws an exception? ------------- PR: https://git.openjdk.java.net/jdk/pull/3611 From stuefe at openjdk.java.net Thu Apr 22 06:13:20 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 22 Apr 2021 06:13:20 GMT Subject: RFR: 8265696 move cds sources In-Reply-To: References: Message-ID: <3ivrvr2C4ouw_Pv1-7TuY2Ugn5KK_-MgoGBre3ij4TY=.f6e507f9-7b17-46c5-b836-540b807cec5a@github.com> On Wed, 21 Apr 2021 21:55:25 GMT, Ioi Lam wrote: > The number of CDS source files have grown significantly. To improve modularity, the following files should be moved a new directory, src/hotspot/share/cds. > > - src/hotspot/share/classfile/classListParser.cpp > - src/hotspot/share/classfile/classListParser.hpp > - src/hotspot/share/classfile/classListWriter.hpp > - src/hotspot/share/classfile/compactHashtable.cpp > - src/hotspot/share/classfile/compactHashtable.hpp > - src/hotspot/share/classfile/lambdaFormInvokers.cpp > - src/hotspot/share/classfile/lambdaFormInvokers.hpp > - src/hotspot/share/memory/archiveBuilder.cpp > - src/hotspot/share/memory/archiveBuilder.hpp > - src/hotspot/share/memory/archiveUtils.cpp > - src/hotspot/share/memory/archiveUtils.hpp > - src/hotspot/share/memory/archiveUtils.inline.hpp > - src/hotspot/share/memory/cppVtables.cpp > - src/hotspot/share/memory/cppVtables.hpp > - src/hotspot/share/memory/dumpAllocStats.cpp > - src/hotspot/share/memory/dumpAllocStats.hpp > - src/hotspot/share/memory/dynamicArchive.cpp > - src/hotspot/share/memory/dynamicArchive.hpp > - src/hotspot/share/memory/filemap.cpp > - src/hotspot/share/memory/filemap.hpp > - src/hotspot/share/memory/heapShared.cpp > - src/hotspot/share/memory/heapShared.hpp > - src/hotspot/share/memory/heapShared.inline.hpp > - src/hotspot/share/memory/metaspaceShared.cpp > - src/hotspot/share/memory/metaspaceShared.hpp > - src/hotspot/share/prims/cdsoffsets.cpp > - src/hotspot/share/prims/cdsoffsets.hpp > > Testing with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. Hi @iklam, this is a very welcome change! Nothing much to add to what David wrote (include guards need renaming). Apart from that, I was surprised that no gtests needed to be adapted, but seems cds has no gtests? I tested building without cds, works fine. Thanks for doing this! If you fix the include guards, this is fine by me. ..Thomas ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3610 From iklam at openjdk.java.net Thu Apr 22 06:18:11 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 22 Apr 2021 06:18:11 GMT Subject: RFR: 8265696 move cds sources [v2] In-Reply-To: References: Message-ID: <-pjc1lfaVdvDcDXtulHWrE_OLkJm73_FXvy-4WoyzKw=.165c328e-1f6d-4ce1-b188-91be4e11ef7f@github.com> > The number of CDS source files have grown significantly. To improve modularity, the following files should be moved a new directory, src/hotspot/share/cds. > > - src/hotspot/share/classfile/classListParser.cpp > - src/hotspot/share/classfile/classListParser.hpp > - src/hotspot/share/classfile/classListWriter.hpp > - src/hotspot/share/classfile/compactHashtable.cpp > - src/hotspot/share/classfile/compactHashtable.hpp > - src/hotspot/share/classfile/lambdaFormInvokers.cpp > - src/hotspot/share/classfile/lambdaFormInvokers.hpp > - src/hotspot/share/memory/archiveBuilder.cpp > - src/hotspot/share/memory/archiveBuilder.hpp > - src/hotspot/share/memory/archiveUtils.cpp > - src/hotspot/share/memory/archiveUtils.hpp > - src/hotspot/share/memory/archiveUtils.inline.hpp > - src/hotspot/share/memory/cppVtables.cpp > - src/hotspot/share/memory/cppVtables.hpp > - src/hotspot/share/memory/dumpAllocStats.cpp > - src/hotspot/share/memory/dumpAllocStats.hpp > - src/hotspot/share/memory/dynamicArchive.cpp > - src/hotspot/share/memory/dynamicArchive.hpp > - src/hotspot/share/memory/filemap.cpp > - src/hotspot/share/memory/filemap.hpp > - src/hotspot/share/memory/heapShared.cpp > - src/hotspot/share/memory/heapShared.hpp > - src/hotspot/share/memory/heapShared.inline.hpp > - src/hotspot/share/memory/metaspaceShared.cpp > - src/hotspot/share/memory/metaspaceShared.hpp > - src/hotspot/share/prims/cdsoffsets.cpp > - src/hotspot/share/prims/cdsoffsets.hpp > > Testing with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. Ioi Lam has updated the pull request incrementally with two additional commits since the last revision: - exclude all files under shared/cds if CDS is disabled; compactHashtable.cpp cannot be excluded since a bit of it is used even when CDS is disabled - fixed include guards -> #ifndef SHARE_CDS_xxxxx ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3610/files - new: https://git.openjdk.java.net/jdk/pull/3610/files/ba45831f..a1a2699f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3610&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3610&range=00-01 Stats: 66 lines in 19 files changed: 6 ins; 16 del; 44 mod Patch: https://git.openjdk.java.net/jdk/pull/3610.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3610/head:pull/3610 PR: https://git.openjdk.java.net/jdk/pull/3610 From iklam at openjdk.java.net Thu Apr 22 06:23:21 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 22 Apr 2021 06:23:21 GMT Subject: RFR: 8265696 move cds sources [v2] In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 04:14:38 GMT, David Holmes wrote: >> Thank you! > > I don't suppose we can just exclude the new directory rather than listing individual files? Fixed. Now all files under share/cds are excluded. I needed to move compactHashtable.cpp back to its old location since a little of it is used even when CDS is not used. ------------- PR: https://git.openjdk.java.net/jdk/pull/3610 From iklam at openjdk.java.net Thu Apr 22 06:23:20 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 22 Apr 2021 06:23:20 GMT Subject: RFR: 8265696 move cds sources [v2] In-Reply-To: <3ivrvr2C4ouw_Pv1-7TuY2Ugn5KK_-MgoGBre3ij4TY=.f6e507f9-7b17-46c5-b836-540b807cec5a@github.com> References: <3ivrvr2C4ouw_Pv1-7TuY2Ugn5KK_-MgoGBre3ij4TY=.f6e507f9-7b17-46c5-b836-540b807cec5a@github.com> Message-ID: On Thu, 22 Apr 2021 06:10:17 GMT, Thomas Stuefe wrote: > Hi @iklam, > > this is a very welcome change! > > Nothing much to add to what David wrote (include guards need renaming). > > Apart from that, I was surprised that no gtests needed to be adapted, but seems cds has no gtests? > > I tested building without cds, works fine. > > Thanks for doing this! > > If you fix the include guards, this is fine by me. > > ..Thomas Hi Thomas, thanks for the review. You're right that we don't have any gtests .... that should be fixed at some point. ------------- PR: https://git.openjdk.java.net/jdk/pull/3610 From iklam at openjdk.java.net Thu Apr 22 06:23:23 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 22 Apr 2021 06:23:23 GMT Subject: RFR: 8265696 move cds sources [v2] In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 04:16:57 GMT, David Holmes wrote: >> Ioi Lam has updated the pull request incrementally with two additional commits since the last revision: >> >> - exclude all files under shared/cds if CDS is disabled; compactHashtable.cpp cannot be excluded since a bit of it is used even when CDS is disabled >> - fixed include guards -> #ifndef SHARE_CDS_xxxxx > > src/hotspot/share/cds/archiveUtils.inline.hpp line 25: > >> 23: */ >> 24: >> 25: #ifndef SHARE_MEMORY_ARCHIVEUTILS_INLINE_HPP > > The header file include guards all need updating for the new path. Fixed. > src/hotspot/share/cds/dynamicArchive.hpp line 38: > >> 36: #include "utilities/resourceHash.hpp" >> 37: >> 38: #if INCLUDE_CDS > > I have to wonder who is including this file and why, if CDS is not enabled. E.g., jvm.cpp includes dynamicArchive.hpp, but only uses its declarations inside INCLUDE_CDS blocks. It would be too verbose to do this in jvm.cpp #if INCLUDE_CDS #include "cds/dynamicArchive.hpp" #endif ------------- PR: https://git.openjdk.java.net/jdk/pull/3610 From iklam at openjdk.java.net Thu Apr 22 06:27:45 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 22 Apr 2021 06:27:45 GMT Subject: RFR: 8265696 move cds sources [v3] In-Reply-To: References: Message-ID: > The number of CDS source files have grown significantly. To improve modularity, the following files should be moved a new directory, src/hotspot/share/cds. > > - src/hotspot/share/classfile/classListParser.cpp > - src/hotspot/share/classfile/classListParser.hpp > - src/hotspot/share/classfile/classListWriter.hpp > - src/hotspot/share/classfile/compactHashtable.cpp > - src/hotspot/share/classfile/compactHashtable.hpp > - src/hotspot/share/classfile/lambdaFormInvokers.cpp > - src/hotspot/share/classfile/lambdaFormInvokers.hpp > - src/hotspot/share/memory/archiveBuilder.cpp > - src/hotspot/share/memory/archiveBuilder.hpp > - src/hotspot/share/memory/archiveUtils.cpp > - src/hotspot/share/memory/archiveUtils.hpp > - src/hotspot/share/memory/archiveUtils.inline.hpp > - src/hotspot/share/memory/cppVtables.cpp > - src/hotspot/share/memory/cppVtables.hpp > - src/hotspot/share/memory/dumpAllocStats.cpp > - src/hotspot/share/memory/dumpAllocStats.hpp > - src/hotspot/share/memory/dynamicArchive.cpp > - src/hotspot/share/memory/dynamicArchive.hpp > - src/hotspot/share/memory/filemap.cpp > - src/hotspot/share/memory/filemap.hpp > - src/hotspot/share/memory/heapShared.cpp > - src/hotspot/share/memory/heapShared.hpp > - src/hotspot/share/memory/heapShared.inline.hpp > - src/hotspot/share/memory/metaspaceShared.cpp > - src/hotspot/share/memory/metaspaceShared.hpp > - src/hotspot/share/prims/cdsoffsets.cpp > - src/hotspot/share/prims/cdsoffsets.hpp > > Testing with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - Merge branch 'master' into 8265696-move-cds-sources - exclude all files under shared/cds if CDS is disabled; compactHashtable.cpp cannot be excluded since a bit of it is used even when CDS is disabled - fixed include guards -> #ifndef SHARE_CDS_xxxxx - fixed copyright - moved more files - fixed include lines - 8265696: Move CDS sources from shared/memory to shared/cds ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3610/files - new: https://git.openjdk.java.net/jdk/pull/3610/files/a1a2699f..729c6519 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3610&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3610&range=01-02 Stats: 338 lines in 63 files changed: 131 ins; 143 del; 64 mod Patch: https://git.openjdk.java.net/jdk/pull/3610.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3610/head:pull/3610 PR: https://git.openjdk.java.net/jdk/pull/3610 From dholmes at openjdk.java.net Thu Apr 22 06:41:33 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 22 Apr 2021 06:41:33 GMT Subject: RFR: 8265696 move cds sources [v3] In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 06:27:45 GMT, Ioi Lam wrote: >> The number of CDS source files have grown significantly. To improve modularity, the following files should be moved a new directory, src/hotspot/share/cds. >> >> - src/hotspot/share/classfile/classListParser.cpp >> - src/hotspot/share/classfile/classListParser.hpp >> - src/hotspot/share/classfile/classListWriter.hpp >> - src/hotspot/share/classfile/compactHashtable.cpp >> - src/hotspot/share/classfile/compactHashtable.hpp >> - src/hotspot/share/classfile/lambdaFormInvokers.cpp >> - src/hotspot/share/classfile/lambdaFormInvokers.hpp >> - src/hotspot/share/memory/archiveBuilder.cpp >> - src/hotspot/share/memory/archiveBuilder.hpp >> - src/hotspot/share/memory/archiveUtils.cpp >> - src/hotspot/share/memory/archiveUtils.hpp >> - src/hotspot/share/memory/archiveUtils.inline.hpp >> - src/hotspot/share/memory/cppVtables.cpp >> - src/hotspot/share/memory/cppVtables.hpp >> - src/hotspot/share/memory/dumpAllocStats.cpp >> - src/hotspot/share/memory/dumpAllocStats.hpp >> - src/hotspot/share/memory/dynamicArchive.cpp >> - src/hotspot/share/memory/dynamicArchive.hpp >> - src/hotspot/share/memory/filemap.cpp >> - src/hotspot/share/memory/filemap.hpp >> - src/hotspot/share/memory/heapShared.cpp >> - src/hotspot/share/memory/heapShared.hpp >> - src/hotspot/share/memory/heapShared.inline.hpp >> - src/hotspot/share/memory/metaspaceShared.cpp >> - src/hotspot/share/memory/metaspaceShared.hpp >> - src/hotspot/share/prims/cdsoffsets.cpp >> - src/hotspot/share/prims/cdsoffsets.hpp >> >> Testing with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: > > - Merge branch 'master' into 8265696-move-cds-sources > - exclude all files under shared/cds if CDS is disabled; compactHashtable.cpp cannot be excluded since a bit of it is used even when CDS is disabled > - fixed include guards -> #ifndef SHARE_CDS_xxxxx > - fixed copyright > - moved more files > - fixed include lines > - 8265696: Move CDS sources from shared/memory to shared/cds Updates look good. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3610 From dholmes at openjdk.java.net Thu Apr 22 06:41:33 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 22 Apr 2021 06:41:33 GMT Subject: RFR: 8265696 move cds sources [v3] In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 06:19:19 GMT, Ioi Lam wrote: >> src/hotspot/share/cds/dynamicArchive.hpp line 38: >> >>> 36: #include "utilities/resourceHash.hpp" >>> 37: >>> 38: #if INCLUDE_CDS >> >> I have to wonder who is including this file and why, if CDS is not enabled. > > E.g., jvm.cpp includes dynamicArchive.hpp, but only uses its declarations inside INCLUDE_CDS blocks. It would be too verbose to do this in jvm.cpp > > > #if INCLUDE_CDS > #include "cds/dynamicArchive.hpp" > #endif We routinely do that for other INCLUDE_X features. ------------- PR: https://git.openjdk.java.net/jdk/pull/3610 From pliden at openjdk.java.net Thu Apr 22 06:43:46 2021 From: pliden at openjdk.java.net (Per Liden) Date: Thu, 22 Apr 2021 06:43:46 GMT Subject: RFR: 8265702: ZGC on macOS/aarch64 [v2] In-Reply-To: References: Message-ID: <2yB8guCDtonp_f251AssKN1-8TuSYqH2zjqjrEmO7ks=.704854fb-c601-4417-a34c-46e7242f2743@github.com> On Thu, 22 Apr 2021 04:26:11 GMT, David Holmes wrote: >> Per Liden has updated the pull request incrementally with one additional commit since the last revision: >> >> Add comment to #else > > src/hotspot/os/bsd/os_bsd.cpp line 2149: > >> 2147: >> 2148: return (uint)processor_id; >> 2149: #else > > Please add a comment indicating what platform this else is referring to. Will fix! ------------- PR: https://git.openjdk.java.net/jdk/pull/3609 From pliden at openjdk.java.net Thu Apr 22 06:43:45 2021 From: pliden at openjdk.java.net (Per Liden) Date: Thu, 22 Apr 2021 06:43:45 GMT Subject: RFR: 8265702: ZGC on macOS/aarch64 [v2] In-Reply-To: References: Message-ID: <7qkG6INxywBIAyzPqO812c7Pn7IUp5gZzfcjl27lE2E=.73fa7b17-7f51-4cdc-b621-e44d3b619740@github.com> > This patch enables ZGC on macOS/aarch64. It does three things: > 1) Enables building of ZGC on this platform. > 2) Adds `os::processor_id()`, which for now always returns 0. > 3) Fixes a WX issue in `OptoRuntime::handle_exception_C()`, where the stackwater mark might unnecessarily process a frame when the thread is in WXExec mode. In this case, the we're not touching any oops, so we don't need to process any frames. > > Testing: Passes the same tests as macOS/x86_64 (with the exception of pre-existing issues unrelated to ZGC). Per Liden has updated the pull request incrementally with one additional commit since the last revision: Add comment to #else ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3609/files - new: https://git.openjdk.java.net/jdk/pull/3609/files/c8913936..dd8c42ff Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3609&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3609&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3609.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3609/head:pull/3609 PR: https://git.openjdk.java.net/jdk/pull/3609 From yyang at openjdk.java.net Thu Apr 22 07:01:45 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Thu, 22 Apr 2021 07:01:45 GMT Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex Message-ID: The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). An notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has corresponding C1 intrinsic version. In fact, there is an utilitiy method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replaces these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has corresponding intrinsic method in HotSpot. But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few stuffs we can do later: 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase. 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag Testing: compiler and jdk ------------- Commit messages: - consolidate Changes: https://git.openjdk.java.net/jdk/pull/3615/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265518 Stats: 253 lines in 11 files changed: 184 ins; 48 del; 21 mod Patch: https://git.openjdk.java.net/jdk/pull/3615.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3615/head:pull/3615 PR: https://git.openjdk.java.net/jdk/pull/3615 From sjohanss at openjdk.java.net Thu Apr 22 07:05:28 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Thu, 22 Apr 2021 07:05:28 GMT Subject: RFR: 8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v27] In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 18:00:52 GMT, Marcus G K Williams wrote: > > > * Do we allow explicit -XX:LargePageSizeInBytes=0 ? Seems somewhat pointless. Do we handle it today? > > > Actually we don't, but we probably should handle it. Would be kind of strange preventing someone from setting the default. > > How should we handle this differently? I just mean that if `LargePageSizeInBytes=0` on the command line that should give the same result as not setting anything. Right now you get a warning, and the default behavior. The warning should go away since it is documented to mean use the default. > $ java -XX:+UseLargePages -XX:LargePageSizeInBytes=0 -version > Java HotSpot(TM) 64-Bit Server VM warning: Setting LargePageSizeInBytes=0 has no effect on this OS. Using the default large page size 2048K. I also updated the title for the issue in JBS and I suspect that you will get a notification to change it here as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From shade at openjdk.java.net Thu Apr 22 08:34:28 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 22 Apr 2021 08:34:28 GMT Subject: RFR: 8265332: gtest/LargePageGtests.java OOMEs on -XX:+UseSHM cases [v2] In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 10:44:12 GMT, Aleksey Shipilev wrote: >> It looks like some `+UseSHM` test cases added by [JDK-8213269](https://bugs.openjdk.java.net/browse/JDK-8213269) reliably blow up the VM log reader with OOME. There are lots of `OpenJDK 64-Bit Server VM warning: Failed to reserve shared memory.` in the log, if you increase the test heap size. AFAIU, many of those messages are expected from the new test cases. >> >> I believe ultimately this test produces a virtually unbounded number of warning messages, which would eventually blow out the Java heap in test infra parsers. This is a reliable tier1 failure on my TR 3970X, probably because it has enough cores to run 30 threads concurrently for 15 seconds all spewing warning messages. >> >> #### Try 1 >> >> The first attempt recognizes that `ConcurrentTestRunner` runs a time-bound number of iterations, which means the faster machine is, the more warning messages would be printed. Then, the way out is to make `ConcurrentTestRunner` to cap the number of iterations, so that VM output length is more predictable. >> >> Test times before: >> >> >> # default >> [ OK ] os_linux.reserve_memory_special_concurrent_vm (15003 ms) >> >> # -XX:+UseLargePages >> [ OK ] os_linux.reserve_memory_special_concurrent_vm (16121 ms) >> >> # -XX:+UseLargePages -XX:LargePageSizeInBytes=1G >> [ OK ] os_linux.reserve_memory_special_concurrent_vm (15006 ms) >> >> # -XX:+UseLargePages -XX:+UseSHM >> [ OK ] os_linux.reserve_memory_special_concurrent_vm (15030 ms) >> >> >> Test times after: >> >> >> # default >> [ OK ] os_linux.reserve_memory_special_concurrent_vm (15003 ms) >> >> # -XX:+UseLargePages >> [ OK ] os_linux.reserve_memory_special_concurrent_vm (16071 ms) >> >> # -XX:+UseLargePages -XX:LargePageSizeInBytes=1G >> [ OK ] os_linux.reserve_memory_special_concurrent_vm (15006 ms) >> >> # -XX:+UseLargePages -XX:+UseSHM >> [ OK ] os_linux.reserve_memory_special_concurrent_vm (1190 ms) >> >> >> The major difference is that the last mode gets capped by `maxIteration`. This fixes the test failure, as `-XX:+UseSHM` case would produce lots of warnings on my machine. >> >> #### Try 2 >> >> The second attempt run the tests with `-XX:-PrintWarnings` to avoid warning log overload. >> >> Additional testing: >> - [x] `os_linux` gtest >> - [x] `gtest/LargePageGtests.java` used to fail, now passes > > Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Just run with -XX:-PrintWarnings > - Merge branch 'master' into JDK-8265332-largepages-oome > - 8265332: gtest/LargePageGtests.java OOMEs on -XX:+UseSHM cases Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/3542 From shade at openjdk.java.net Thu Apr 22 08:34:29 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 22 Apr 2021 08:34:29 GMT Subject: Integrated: 8265332: gtest/LargePageGtests.java OOMEs on -XX:+UseSHM cases In-Reply-To: References: Message-ID: <6rWNMPHBWhmA7UtXVvAlEtfX7JzBC_f3CrrnO34da08=.1de5cf4c-fd5e-40a1-ad72-8bf57678390d@github.com> On Fri, 16 Apr 2021 10:06:43 GMT, Aleksey Shipilev wrote: > It looks like some `+UseSHM` test cases added by [JDK-8213269](https://bugs.openjdk.java.net/browse/JDK-8213269) reliably blow up the VM log reader with OOME. There are lots of `OpenJDK 64-Bit Server VM warning: Failed to reserve shared memory.` in the log, if you increase the test heap size. AFAIU, many of those messages are expected from the new test cases. > > I believe ultimately this test produces a virtually unbounded number of warning messages, which would eventually blow out the Java heap in test infra parsers. This is a reliable tier1 failure on my TR 3970X, probably because it has enough cores to run 30 threads concurrently for 15 seconds all spewing warning messages. > > #### Try 1 > > The first attempt recognizes that `ConcurrentTestRunner` runs a time-bound number of iterations, which means the faster machine is, the more warning messages would be printed. Then, the way out is to make `ConcurrentTestRunner` to cap the number of iterations, so that VM output length is more predictable. > > Test times before: > > > # default > [ OK ] os_linux.reserve_memory_special_concurrent_vm (15003 ms) > > # -XX:+UseLargePages > [ OK ] os_linux.reserve_memory_special_concurrent_vm (16121 ms) > > # -XX:+UseLargePages -XX:LargePageSizeInBytes=1G > [ OK ] os_linux.reserve_memory_special_concurrent_vm (15006 ms) > > # -XX:+UseLargePages -XX:+UseSHM > [ OK ] os_linux.reserve_memory_special_concurrent_vm (15030 ms) > > > Test times after: > > > # default > [ OK ] os_linux.reserve_memory_special_concurrent_vm (15003 ms) > > # -XX:+UseLargePages > [ OK ] os_linux.reserve_memory_special_concurrent_vm (16071 ms) > > # -XX:+UseLargePages -XX:LargePageSizeInBytes=1G > [ OK ] os_linux.reserve_memory_special_concurrent_vm (15006 ms) > > # -XX:+UseLargePages -XX:+UseSHM > [ OK ] os_linux.reserve_memory_special_concurrent_vm (1190 ms) > > > The major difference is that the last mode gets capped by `maxIteration`. This fixes the test failure, as `-XX:+UseSHM` case would produce lots of warnings on my machine. > > #### Try 2 > > The second attempt run the tests with `-XX:-PrintWarnings` to avoid warning log overload. > > Additional testing: > - [x] `os_linux` gtest > - [x] `gtest/LargePageGtests.java` used to fail, now passes This pull request has now been integrated. Changeset: aa297848 Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/aa297848 Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod 8265332: gtest/LargePageGtests.java OOMEs on -XX:+UseSHM cases Reviewed-by: stuefe ------------- PR: https://git.openjdk.java.net/jdk/pull/3542 From iwalulya at openjdk.java.net Thu Apr 22 09:24:24 2021 From: iwalulya at openjdk.java.net (Ivan Walulya) Date: Thu, 22 Apr 2021 09:24:24 GMT Subject: RFR: 8265268: Unify ReservedSpace reservation code in initialize and try_reserve_heap In-Reply-To: References: Message-ID: <8hHwRoZtjv2RD3yVrssiSjdxGiPE8Qcg8Yl1pN9rc9g=.12734c10-6747-4fb8-bc6d-e4af555d32b7@github.com> On Mon, 19 Apr 2021 13:51:19 GMT, Stefan Johansson wrote: > Please review this change to unify the reservation code in ReservedSpace. > > **Summary** > The code in `ReservedSpace::initialize(...)` and `ReservedHeapSpace::try_reserve_heap(...)` is very similar and more or less does the same things. The difference between them is logging, what is considered a failure and how that is handled. > > This change introduces a new function `ReservedSpace::reserve(...)` that is used by both `initialize(...)` and `try_reserve_heap(...)`. The biggest reason for only having one function handling the reservations is to avoid code duplication and having to change two places when something needs to be updated. > > There will be some small changes in what is getting logged in some cases, but the goal is to avoid changing behavior as much as possible. > > Some additional notes to help reviewing: > * There are two reservation helpers: > `reserve_memory()` for regular pages and file backed mappings. > `reserve_memory_special()` for explicit large pages. > * In `reserve_memory()` the `is_align()`-check at the end was previously done at the end of `initialize()`. It was moved here because this is the only case where an unaligned address can be returned. For large pages as well as when a requested address is provided, the returned address will be aligned. > * The support to have a backing file is only used by the heap when `AllocateHeapAt` is set. If this option is used together with `UseLargePages` a debug message is printed since it is up to the backing file system if large pages are used or not. This output has been unified and is now printed when the file is created rather then deep in the reservation code. Previously this message differed depending on if `UseCompressedOops` was enabled or not. Now the same message is printed for both cases. > > * The failure checking function `failed_to_reserve_as_requested(...)` now only checks if the memory was allocated at the expected address. Releasing the memory is done by the caller. > > * The size passed into `map_or_reserve_memory_aligned` was previously aligned up using the alignment, but the size should always be aligned already. An assert has been added to the start of the `reserve` function and the `align_up` has been removed. > > **Testing** > A lot of local testing as well as tier1-tier5 in Mach5. src/hotspot/share/memory/virtualspace.cpp line 159: > 157: base = map_or_reserve_memory(size, fd, exec); > 158: // Check alignment constraints. This is only needed when there is > 159: // no requested address. If a requested address is used it must be "If a requested address is used it must be aligned." seems redundant here, as it is covered in the branch above, and the assert clearly states that. src/hotspot/share/memory/virtualspace.cpp line 184: > 182: // Check alignment constraints. > 183: assert((uintptr_t)base % alignment == 0, > 184: "Large pages returned a non-aligned address, base: " PTR_FORMAT "Reserve large pages returned..." src/hotspot/share/memory/virtualspace.cpp line 188: > 186: p2i(base), alignment); > 187: } else { > 188: // failed; fall back to reserve regular memory. Shouldn't we have this in the caller, because it is up to the caller to do the fallback. ------------- PR: https://git.openjdk.java.net/jdk/pull/3570 From shade at openjdk.java.net Thu Apr 22 10:43:41 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 22 Apr 2021 10:43:41 GMT Subject: RFR: 8259316: [REDO] C1/C2 compiler support for blackholes [v2] In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 16:59:56 GMT, Vladimir Kozlov wrote: > Good. Please, update copyright year in files you touched. Thanks, only a few files needed updates to 2021. ------------- PR: https://git.openjdk.java.net/jdk/pull/2024 From shade at openjdk.java.net Thu Apr 22 10:43:43 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 22 Apr 2021 10:43:43 GMT Subject: RFR: 8259316: [REDO] C1/C2 compiler support for blackholes [v2] In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 10:41:11 GMT, Vladimir Ivanov wrote: >> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: >> >> - Merge branch 'master' into JDK-8259316-blackholes-redo >> - Redo BlackholeIntrinsicTest to see if target blackhole methods were indeed intrinsified >> - Rename BlackholeStaticTest to BlackholeIntrinsicTest >> - BlackholeStaticTest should unlock blackholes >> - Do not print double-warning on blackhole already set >> - Add more checks for C2 intrinsic >> - Simplify intrinsic test and add warning test >> - Common the blackhole checks >> - Binding JVMCI through get_jvmci_method >> - Merge branch 'master' into JDK-8259316-blackholes-redo >> - ... and 11 more: https://git.openjdk.java.net/jdk/compare/ed477da9...7f4f94d6 > > src/hotspot/share/compiler/compilerOracle.hpp line 145: > >> 143: static bool should_break_at(const methodHandle& method); >> 144: >> 145: // Tells whether there are any methods to print for print_method_statistics() > > Excessive whitespaces. Removed. ------------- PR: https://git.openjdk.java.net/jdk/pull/2024 From shade at openjdk.java.net Thu Apr 22 10:43:41 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 22 Apr 2021 10:43:41 GMT Subject: RFR: 8259316: [REDO] C1/C2 compiler support for blackholes [v2] In-Reply-To: References: Message-ID: <-MM1SeUWBAkFc_dMmWBjAmM6mt6M2o2Ze3TC4xp-t7g=.3c1bf1c4-6e84-4a04-a2e2-d03db0b92498@github.com> On Thu, 22 Apr 2021 10:39:45 GMT, Aleksey Shipilev wrote: >> Good. Please, update copyright year in files you touched. > >> Good. Please, update copyright year in files you touched. > > Thanks, only a few files needed updates to 2021. > @shipilev , as your tests ignore external vm flags you should add `@requires vm.flagless` so we won't waste time on running them with different GC, JITs, etc. Right. Added! > to restore the balance in test descriptions, you might want to delete `@build compiler.blackhole.BlackholeTarget` as there is a statically detectable dependency b/w `compiler.blackhole.*Test` and `BlackholeTarget` hence jtreg/javac will build it while building `compiler.blackhole.*Test` I don't think that's true... When I remove `@build` from those tests, they fail with missing `BlackholeTarget`. ------------- PR: https://git.openjdk.java.net/jdk/pull/2024 From shade at openjdk.java.net Thu Apr 22 10:43:41 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 22 Apr 2021 10:43:41 GMT Subject: RFR: 8259316: [REDO] C1/C2 compiler support for blackholes [v3] In-Reply-To: References: Message-ID: <_E9qpCCmcJW7v1MU-mM-pn58xKMRjnXvUI-fwK-fQLs=.c72b5e5e-d981-414c-8618-3e5b8260090d@github.com> > This reworks the compiler support for blackholes. The key difference against the last version (#1203) is that blackholes are only acceptable as empty static methods, which both simplifies the implementation and eliminates a few compatibility questions. > > JMH uses the `Blackhole::consume` methods to avoid dead-code elimination of the code that produces benchmark values. It now relies on producing opaque side-effects and breaking inlining. While it was proved useful for many years, it unfortunately comes with several major drawbacks. > > Instead of introducing public APIs or special-casing JMH methods in JVM, we can hook a new command to compiler control, and let JMH sign up its `Blackhole` methods for it with `-XX:CompileCommand=blackhole,org.openjdk.jmh.infra.Blackhole::consume`. See CSR and related discussion for alternatives and future plans. > > C1 code is platform-independent, and it handles blackhole via the intrinsics paths, lowering it to nothing. > > C2 makes the `Blackhole` the subclass of `MemBar`, and use the same `Matcher` path as `Op_MemCPUOrder`: it does not match to anything, but it survives until matching, and keeps arguments alive. Additionally, C1 and C2 hooks are now using the synthetic `_blackhole` intrinsic, similarly to existing `_compiledLambdaForm`. It avoids introducing new nodes in C1. It also seems to require the least fiddling with C2 internals. Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits: - Update copyrights where needed - Add vm.flagless requirement to tests - Stray whitespace - Merge branch 'master' into JDK-8259316-blackholes-redo - Merge branch 'master' into JDK-8259316-blackholes-redo - Redo BlackholeIntrinsicTest to see if target blackhole methods were indeed intrinsified - Rename BlackholeStaticTest to BlackholeIntrinsicTest - BlackholeStaticTest should unlock blackholes - Do not print double-warning on blackhole already set - Add more checks for C2 intrinsic - ... and 15 more: https://git.openjdk.java.net/jdk/compare/a93d9119...00c199ba ------------- Changes: https://git.openjdk.java.net/jdk/pull/2024/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2024&range=02 Stats: 1173 lines in 32 files changed: 1167 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/2024.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2024/head:pull/2024 PR: https://git.openjdk.java.net/jdk/pull/2024 From tschatzl at openjdk.java.net Thu Apr 22 12:09:20 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 22 Apr 2021 12:09:20 GMT Subject: RFR: 8265268: Unify ReservedSpace reservation code in initialize and try_reserve_heap In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 13:51:19 GMT, Stefan Johansson wrote: > Please review this change to unify the reservation code in ReservedSpace. > > **Summary** > The code in `ReservedSpace::initialize(...)` and `ReservedHeapSpace::try_reserve_heap(...)` is very similar and more or less does the same things. The difference between them is logging, what is considered a failure and how that is handled. > > This change introduces a new function `ReservedSpace::reserve(...)` that is used by both `initialize(...)` and `try_reserve_heap(...)`. The biggest reason for only having one function handling the reservations is to avoid code duplication and having to change two places when something needs to be updated. > > There will be some small changes in what is getting logged in some cases, but the goal is to avoid changing behavior as much as possible. > > Some additional notes to help reviewing: > * There are two reservation helpers: > `reserve_memory()` for regular pages and file backed mappings. > `reserve_memory_special()` for explicit large pages. > * In `reserve_memory()` the `is_align()`-check at the end was previously done at the end of `initialize()`. It was moved here because this is the only case where an unaligned address can be returned. For large pages as well as when a requested address is provided, the returned address will be aligned. > * The support to have a backing file is only used by the heap when `AllocateHeapAt` is set. If this option is used together with `UseLargePages` a debug message is printed since it is up to the backing file system if large pages are used or not. This output has been unified and is now printed when the file is created rather then deep in the reservation code. Previously this message differed depending on if `UseCompressedOops` was enabled or not. Now the same message is printed for both cases. > > * The failure checking function `failed_to_reserve_as_requested(...)` now only checks if the memory was allocated at the expected address. Releasing the memory is done by the caller. > > * The size passed into `map_or_reserve_memory_aligned` was previously aligned up using the alignment, but the size should always be aligned already. An assert has been added to the start of the `reserve` function and the `align_up` has been removed. > > **Testing** > A lot of local testing as well as tier1-tier5 in Mach5. Changes requested by tschatzl (Reviewer). src/hotspot/share/memory/virtualspace.cpp line 146: > 144: char* base; > 145: // If the memory was requested at a particular address, use > 146: // os::attempt_reserve_memory_at() to avoid over mapping something "to avoid mapping over" - word order src/hotspot/share/memory/virtualspace.cpp line 147: > 145: // If the memory was requested at a particular address, use > 146: // os::attempt_reserve_memory_at() to avoid over mapping something > 147: // important. If available space is not detected, return NULL. "If available space is not detected" -> "If this (reservation) is unsuccessful...". available space detected != reservation possible/successful src/hotspot/share/memory/virtualspace.cpp line 217: > 215: // There are basically three different cases that we need to handle below: > 216: // - Mapping backed by a file > 217: // - Mapping backed by explicit large pages I think there should be a description what "explicit large pages" are. Only in the case that the OS can't commit large page memory this path is taken. The third option kind of suggests that there is only "explicit large page support" if you want large pages (only talking about normal pages or THP, but on e.g. Linux you do not need to pre-commit large pages reservations. ------------- PR: https://git.openjdk.java.net/jdk/pull/3570 From tschatzl at openjdk.java.net Thu Apr 22 12:09:21 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 22 Apr 2021 12:09:21 GMT Subject: RFR: 8265268: Unify ReservedSpace reservation code in initialize and try_reserve_heap In-Reply-To: <8hHwRoZtjv2RD3yVrssiSjdxGiPE8Qcg8Yl1pN9rc9g=.12734c10-6747-4fb8-bc6d-e4af555d32b7@github.com> References: <8hHwRoZtjv2RD3yVrssiSjdxGiPE8Qcg8Yl1pN9rc9g=.12734c10-6747-4fb8-bc6d-e4af555d32b7@github.com> Message-ID: On Thu, 22 Apr 2021 08:46:37 GMT, Ivan Walulya wrote: >> Please review this change to unify the reservation code in ReservedSpace. >> >> **Summary** >> The code in `ReservedSpace::initialize(...)` and `ReservedHeapSpace::try_reserve_heap(...)` is very similar and more or less does the same things. The difference between them is logging, what is considered a failure and how that is handled. >> >> This change introduces a new function `ReservedSpace::reserve(...)` that is used by both `initialize(...)` and `try_reserve_heap(...)`. The biggest reason for only having one function handling the reservations is to avoid code duplication and having to change two places when something needs to be updated. >> >> There will be some small changes in what is getting logged in some cases, but the goal is to avoid changing behavior as much as possible. >> >> Some additional notes to help reviewing: >> * There are two reservation helpers: >> `reserve_memory()` for regular pages and file backed mappings. >> `reserve_memory_special()` for explicit large pages. >> * In `reserve_memory()` the `is_align()`-check at the end was previously done at the end of `initialize()`. It was moved here because this is the only case where an unaligned address can be returned. For large pages as well as when a requested address is provided, the returned address will be aligned. >> * The support to have a backing file is only used by the heap when `AllocateHeapAt` is set. If this option is used together with `UseLargePages` a debug message is printed since it is up to the backing file system if large pages are used or not. This output has been unified and is now printed when the file is created rather then deep in the reservation code. Previously this message differed depending on if `UseCompressedOops` was enabled or not. Now the same message is printed for both cases. >> >> * The failure checking function `failed_to_reserve_as_requested(...)` now only checks if the memory was allocated at the expected address. Releasing the memory is done by the caller. >> >> * The size passed into `map_or_reserve_memory_aligned` was previously aligned up using the alignment, but the size should always be aligned already. An assert has been added to the start of the `reserve` function and the `align_up` has been removed. >> >> **Testing** >> A lot of local testing as well as tier1-tier5 in Mach5. > > src/hotspot/share/memory/virtualspace.cpp line 184: > >> 182: // Check alignment constraints. >> 183: assert((uintptr_t)base % alignment == 0, >> 184: "Large pages returned a non-aligned address, base: " PTR_FORMAT > > "Reserve large pages returned..." s/Reserve/Reserving > src/hotspot/share/memory/virtualspace.cpp line 188: > >> 186: p2i(base), alignment); >> 187: } else { >> 188: // failed; fall back to reserve regular memory. > > Shouldn't we have this in the caller, because it is up to the caller to do the fallback. At least this comment suggests some action that is never taken. ------------- PR: https://git.openjdk.java.net/jdk/pull/3570 From erikj at openjdk.java.net Thu Apr 22 12:34:27 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 22 Apr 2021 12:34:27 GMT Subject: RFR: 8265696 move cds sources [v3] In-Reply-To: References: Message-ID: <3Wpcv8EYtsrZFR0wsASnEgR32CNbCSZGLbYo56q5PdQ=.57993606-1efc-4e0a-b7e2-29417818068b@github.com> On Thu, 22 Apr 2021 06:27:45 GMT, Ioi Lam wrote: >> The number of CDS source files have grown significantly. To improve modularity, the following files should be moved a new directory, src/hotspot/share/cds. >> >> - src/hotspot/share/classfile/classListParser.cpp >> - src/hotspot/share/classfile/classListParser.hpp >> - src/hotspot/share/classfile/classListWriter.hpp >> - src/hotspot/share/classfile/compactHashtable.cpp >> - src/hotspot/share/classfile/compactHashtable.hpp >> - src/hotspot/share/classfile/lambdaFormInvokers.cpp >> - src/hotspot/share/classfile/lambdaFormInvokers.hpp >> - src/hotspot/share/memory/archiveBuilder.cpp >> - src/hotspot/share/memory/archiveBuilder.hpp >> - src/hotspot/share/memory/archiveUtils.cpp >> - src/hotspot/share/memory/archiveUtils.hpp >> - src/hotspot/share/memory/archiveUtils.inline.hpp >> - src/hotspot/share/memory/cppVtables.cpp >> - src/hotspot/share/memory/cppVtables.hpp >> - src/hotspot/share/memory/dumpAllocStats.cpp >> - src/hotspot/share/memory/dumpAllocStats.hpp >> - src/hotspot/share/memory/dynamicArchive.cpp >> - src/hotspot/share/memory/dynamicArchive.hpp >> - src/hotspot/share/memory/filemap.cpp >> - src/hotspot/share/memory/filemap.hpp >> - src/hotspot/share/memory/heapShared.cpp >> - src/hotspot/share/memory/heapShared.hpp >> - src/hotspot/share/memory/heapShared.inline.hpp >> - src/hotspot/share/memory/metaspaceShared.cpp >> - src/hotspot/share/memory/metaspaceShared.hpp >> - src/hotspot/share/prims/cdsoffsets.cpp >> - src/hotspot/share/prims/cdsoffsets.hpp >> >> Testing with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: > > - Merge branch 'master' into 8265696-move-cds-sources > - exclude all files under shared/cds if CDS is disabled; compactHashtable.cpp cannot be excluded since a bit of it is used even when CDS is disabled > - fixed include guards -> #ifndef SHARE_CDS_xxxxx > - fixed copyright > - moved more files > - fixed include lines > - 8265696: Move CDS sources from shared/memory to shared/cds Marked as reviewed by erikj (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3610 From erikj at openjdk.java.net Thu Apr 22 12:34:28 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 22 Apr 2021 12:34:28 GMT Subject: RFR: 8265696 move cds sources [v3] In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 06:19:29 GMT, Ioi Lam wrote: >> I don't suppose we can just exclude the new directory rather than listing individual files? > > Fixed. Now all files under share/cds are excluded. I needed to move compactHashtable.cpp back to its old location since a little of it is used even when CDS is not used. That's indeed a better idea. ------------- PR: https://git.openjdk.java.net/jdk/pull/3610 From thartmann at openjdk.java.net Thu Apr 22 13:33:33 2021 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Thu, 22 Apr 2021 13:33:33 GMT Subject: RFR: 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests [v5] In-Reply-To: References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> Message-ID: On Tue, 20 Apr 2021 13:52:13 GMT, Christian Hagedorn wrote: >> This RFE provides an IR test framework to perform regex-based checks on the C2 IR shape of test methods emitted by the VM flags `-XX:+PrintIdeal` and `-XX:+PrintOptoAssembly`. The framework can also be used for other non-IR matching (and non-compiler) tests by providing easy to use annotations for commonly used testing patterns and compiler control flags. >> >> The framework is based on the ideas of the currently present IR test framework in [Valhalla](https://github.com/openjdk/valhalla/blob/e9c78ce4fcfd01361c35883e0d68f9ae5a80d079/test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypeTest.java) (mainly implemented by @TobiHartmann) which is being used with great success. This new framework aims to replace the old one in Valhalla at some point. >> >> A detailed description about how this new IR test framework works and how it is used is provided in the [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) file and in the [Javadocs](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc/jdk/test/lib/hotspot/ir_framework/package-summary.html) written for the framework classes. >> >> To finish a first version of this framework for JDK 17, I decided to leave some improvement possibilities and ideas to be followed up on in additional RFEs. Some ideas are mentioned in "Future Work" in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) and were also created as subtasks of this RFE. >> >> Testing (also described in "Internal Framework Tests in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md)): >> There are various tests to verify the correctness of the test framework which can be found as JTreg tests in the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) folder. Additional testing was performed by converting all compiler Inline Types test of project Valhalla (done by @katyapav in [JDK-8263024](https://bugs.openjdk.java.net/browse/JDK-8263024)) that used the old framework to the new framework. This provided additional testing for the framework itself. We ran the converted tests with all the flag settings used in hs-tier1-9 and hs-precheckin-comp. For sanity checking, this was also done with a sample IR test in mainline. >> >> Some stats about the framework code added to [ir_framework](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework): >> >> - without the [Javadocs files](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc) : 60 changed files, 13212 insertions, 0 deletions. >> - without the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) and [examples](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/examples) folder: 40 files changed, 6781 insertions >> - comments: 2399 insertions (calculated with `git diff --cached !(tests|examples) | grep -c -E "(^[+-]\s*(/)?*)|(^[+-]\s*//)"`) >> - which leaves 4382 lines of code inserted >> >> Big thanks to: >> - @TobiHartmann for all his help by discussing the new framework and for providing insights from his IR test framework in Valhalla. >> - @katyapav for converting the Valhalla tests to use the new framework which found some harder to catch bugs in the framework and also some actual C2 bugs. >> - @iignatev for helping to simplify the framework usage with JTreg and with the framework internal VM calling structure. >> - and others who provided valuable feedback. >> >> Thanks, >> Christian > > Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: > > Remove Javadocs and README.html, update README.md to reference java files instead of html files Great work, Christian! I'm glad we finally have the capability to write regression tests with IR verification. Hard to review this in detail but I've added some comments. In any case, conversion of Valhalla tests to the new framework has proven that this is good to go. We can still fix problems and add new features once this is in. test/lib/jdk/test/lib/hotspot/ir_framework/Check.java line 94: > 92: @Retention(RetentionPolicy.RUNTIME) > 93: public @interface Check { > 94: Some classes/interfaces have a newline at the beginning and others don't. I think they can be removed. test/lib/jdk/test/lib/hotspot/ir_framework/IREncodingPrinter.java line 36: > 34: > 35: /** > 36: * Prints an encoding of all @Test methods whether an @IR rules should be applied to the dedicated test framework socket. The comment is a bit confusing, maybe "rules" -> "rule"? test/lib/jdk/test/lib/hotspot/ir_framework/README.md line 4: > 2: This folder contains a test framework whose main purpose is to perform regex-based checks on the C2 IR shape of test methods emitted by the VM flags _-XX:+PrintIdeal_ and _-XX:+PrintOptoAssembly_. The framework can also be used for other non-IR matching (and non-compiler) tests by providing easy to use annotations for commonly used testing patterns and compiler control flags. > 3: > 4: The framework is based on the ideas of the currently present IR test framework in [Valhalla](https://github.com/openjdk/valhalla/blob/e9c78ce4fcfd01361c35883e0d68f9ae5a80d079/test/hotspot/jtreg/runtime/valhalla/inlinetypes/InlineTypesTest.java) and aims to replace it at some point. I think this line can be removed because we will happily remove the Valhalla version as soon as this one gets integrated :) test/lib/jdk/test/lib/hotspot/ir_framework/README.md line 46: > 44: > 45: #### Checked Tests > 46: The base tests do not provide any way of verification by user code. A checked test enabled that by allowing the user to define an additional `@Check` annotated method which is invoked directly after the `@Test` annotated method. This allows the user to perform various checks about the test method including return value verification. "enabled" -> "enables" test/lib/jdk/test/lib/hotspot/ir_framework/README.md line 65: > 63: A regex can either be a custom string or any of the default regexes provided by the framework in [IRNode](IRNode.java) for some commonly used IR nodes (also provides the possibility of composite regexes). > 64: > 65: An IR verification cannot (and does not want to) always be performed. For example, a JTreg test could be run with _-Xint_ or not a debug build (_-XX:+PrintIdeal_ and _-XX:+PrintOptoAssembly_ are debug build flags). But also CI tier testing could add additional JTreg VM and Javaoptions flags which could make an IR rule unstable. Maybe rephrase "does not want to" test/lib/jdk/test/lib/hotspot/ir_framework/README.md line 93: > 91: - `-DTest=test1,test2`: Provide a list of `@Test` method names which should be executed. > 92: - `-DExclude=test3`: Provide a list of `@Test` method names which should be excluded from execution. > 93: - `-DScenarios=1,2`: Provide a list of scenario indexes to specify which scenarios that should be executed. "that" should be removed test/lib/jdk/test/lib/hotspot/ir_framework/README.md line 101: > 99: - `-DExcluceRandom=true`: The framework randomly excludes some methods from compilation. IR verification is disabled completely with this flag. > 100: - `-DFlipC1C2=true`: The framework compiles all `@Test` annotated method with C1 if a C2 compilation would have been applied and vice versa. IR verification is disabled completely with this flag. > 101: - `-DShuffleTests=false`: Disables the shuffling of tests (a shuffling is always done by default). Maybe explain that "shuffling" means execution in random order. test/lib/jdk/test/lib/hotspot/ir_framework/README.md line 128: > 126: This framework is based on the idea of the currently present IR test framework in [Valhalla](https://github.com/openjdk/valhalla/blob/e9c78ce4fcfd01361c35883e0d68f9ae5a80d079/test/hotspot/jtreg/runtime/valhalla/inlinetypes/InlineTypesTest.java). This IR framework was used with great success in Valhalla and thus served as a foundation for this new IR framework. > 127: > 128: The new framework supports all the features that are present in the Valhalla IR framework with the idea to replace it at some point. The initial design and feature set was kept simple and straight forward and serves well for small to medium sized tests. There are a lot of possibilities to further enhance the framework and make it more powerful. This can be tackled in additional RFEs. A few ideas include: Again, I would remove the reference to the Valhalla framework. Looking through the changes, I see 13 references to "Valhalla", I think these should all be removed. test/lib/jdk/test/lib/hotspot/ir_framework/README.md line 135: > 133: - More interface methods for verification in checked and custom run tests. > 134: - More stress/debug framework flags. > 135: - Additional check possibilities in `@IR` annotations. I would remove the "Future Work" section and migrate it completely to RFEs. Otherwise it will quickly be outdated anyway. ------------- Marked as reviewed by thartmann (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3508 From iignatyev at openjdk.java.net Thu Apr 22 13:40:23 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 22 Apr 2021 13:40:23 GMT Subject: RFR: 8259316: [REDO] C1/C2 compiler support for blackholes [v2] In-Reply-To: <-MM1SeUWBAkFc_dMmWBjAmM6mt6M2o2Ze3TC4xp-t7g=.3c1bf1c4-6e84-4a04-a2e2-d03db0b92498@github.com> References: <-MM1SeUWBAkFc_dMmWBjAmM6mt6M2o2Ze3TC4xp-t7g=.3c1bf1c4-6e84-4a04-a2e2-d03db0b92498@github.com> Message-ID: On Thu, 22 Apr 2021 10:40:26 GMT, Aleksey Shipilev wrote: > > to restore the balance in test descriptions, you might want to delete `@build compiler.blackhole.BlackholeTarget` as there is a statically detectable dependency b/w `compiler.blackhole.*Test` and `BlackholeTarget` hence jtreg/javac will build it while building `compiler.blackhole.*Test` > > I don't think that's true... When I remove `@build` from those tests, they fail with missing `BlackholeTarget`. right, that's b/c you need to add `/` into the list of libraries: Suggestion: - * @library /test/lib - * @build compiler.blackhole.BlackholeTarget + * @library /test/lib / ------------- PR: https://git.openjdk.java.net/jdk/pull/2024 From tschatzl at openjdk.java.net Thu Apr 22 13:47:26 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 22 Apr 2021 13:47:26 GMT Subject: RFR: 8265268: Unify ReservedSpace reservation code in initialize and try_reserve_heap In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 12:00:21 GMT, Thomas Schatzl wrote: >> Please review this change to unify the reservation code in ReservedSpace. >> >> **Summary** >> The code in `ReservedSpace::initialize(...)` and `ReservedHeapSpace::try_reserve_heap(...)` is very similar and more or less does the same things. The difference between them is logging, what is considered a failure and how that is handled. >> >> This change introduces a new function `ReservedSpace::reserve(...)` that is used by both `initialize(...)` and `try_reserve_heap(...)`. The biggest reason for only having one function handling the reservations is to avoid code duplication and having to change two places when something needs to be updated. >> >> There will be some small changes in what is getting logged in some cases, but the goal is to avoid changing behavior as much as possible. >> >> Some additional notes to help reviewing: >> * There are two reservation helpers: >> `reserve_memory()` for regular pages and file backed mappings. >> `reserve_memory_special()` for explicit large pages. >> * In `reserve_memory()` the `is_align()`-check at the end was previously done at the end of `initialize()`. It was moved here because this is the only case where an unaligned address can be returned. For large pages as well as when a requested address is provided, the returned address will be aligned. >> * The support to have a backing file is only used by the heap when `AllocateHeapAt` is set. If this option is used together with `UseLargePages` a debug message is printed since it is up to the backing file system if large pages are used or not. This output has been unified and is now printed when the file is created rather then deep in the reservation code. Previously this message differed depending on if `UseCompressedOops` was enabled or not. Now the same message is printed for both cases. >> >> * The failure checking function `failed_to_reserve_as_requested(...)` now only checks if the memory was allocated at the expected address. Releasing the memory is done by the caller. >> >> * The size passed into `map_or_reserve_memory_aligned` was previously aligned up using the alignment, but the size should always be aligned already. An assert has been added to the start of the `reserve` function and the `align_up` has been removed. >> >> **Testing** >> A lot of local testing as well as tier1-tier5 in Mach5. > > src/hotspot/share/memory/virtualspace.cpp line 217: > >> 215: // There are basically three different cases that we need to handle below: >> 216: // - Mapping backed by a file >> 217: // - Mapping backed by explicit large pages > > I think there should be a description what "explicit large pages" are. Only in the case that the OS can't commit large page memory this path is taken. > The third option kind of suggests that there is only "explicit large page support" if you want large pages (only talking about normal pages or THP, but on e.g. Linux you do not need to pre-commit large pages reservations. @kstefanj enlightened me about that even on Linux we pre-commit everything *but* the linux counters (particularly `free_hugepages`) is not updated until the page has been touched. That misled me to believing that we do not need to actually precommit there. So, ignore this comment. ------------- PR: https://git.openjdk.java.net/jdk/pull/3570 From sjohanss at openjdk.java.net Thu Apr 22 14:01:48 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Thu, 22 Apr 2021 14:01:48 GMT Subject: RFR: 8265268: Unify ReservedSpace reservation code in initialize and try_reserve_heap [v2] In-Reply-To: References: Message-ID: > Please review this change to unify the reservation code in ReservedSpace. > > **Summary** > The code in `ReservedSpace::initialize(...)` and `ReservedHeapSpace::try_reserve_heap(...)` is very similar and more or less does the same things. The difference between them is logging, what is considered a failure and how that is handled. > > This change introduces a new function `ReservedSpace::reserve(...)` that is used by both `initialize(...)` and `try_reserve_heap(...)`. The biggest reason for only having one function handling the reservations is to avoid code duplication and having to change two places when something needs to be updated. > > There will be some small changes in what is getting logged in some cases, but the goal is to avoid changing behavior as much as possible. > > Some additional notes to help reviewing: > * There are two reservation helpers: > `reserve_memory()` for regular pages and file backed mappings. > `reserve_memory_special()` for explicit large pages. > * In `reserve_memory()` the `is_align()`-check at the end was previously done at the end of `initialize()`. It was moved here because this is the only case where an unaligned address can be returned. For large pages as well as when a requested address is provided, the returned address will be aligned. > * The support to have a backing file is only used by the heap when `AllocateHeapAt` is set. If this option is used together with `UseLargePages` a debug message is printed since it is up to the backing file system if large pages are used or not. This output has been unified and is now printed when the file is created rather then deep in the reservation code. Previously this message differed depending on if `UseCompressedOops` was enabled or not. Now the same message is printed for both cases. > > * The failure checking function `failed_to_reserve_as_requested(...)` now only checks if the memory was allocated at the expected address. Releasing the memory is done by the caller. > > * The size passed into `map_or_reserve_memory_aligned` was previously aligned up using the alignment, but the size should always be aligned already. An assert has been added to the start of the `reserve` function and the `align_up` has been removed. > > **Testing** > A lot of local testing as well as tier1-tier5 in Mach5. Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision: Thomas and Ivan review ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3570/files - new: https://git.openjdk.java.net/jdk/pull/3570/files/5383ea9d..7e85384d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3570&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3570&range=00-01 Stats: 10 lines in 1 file changed: 1 ins; 2 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/3570.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3570/head:pull/3570 PR: https://git.openjdk.java.net/jdk/pull/3570 From sjohanss at openjdk.java.net Thu Apr 22 14:01:48 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Thu, 22 Apr 2021 14:01:48 GMT Subject: RFR: 8265268: Unify ReservedSpace reservation code in initialize and try_reserve_heap [v2] In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 13:58:33 GMT, Stefan Johansson wrote: >> Please review this change to unify the reservation code in ReservedSpace. >> >> **Summary** >> The code in `ReservedSpace::initialize(...)` and `ReservedHeapSpace::try_reserve_heap(...)` is very similar and more or less does the same things. The difference between them is logging, what is considered a failure and how that is handled. >> >> This change introduces a new function `ReservedSpace::reserve(...)` that is used by both `initialize(...)` and `try_reserve_heap(...)`. The biggest reason for only having one function handling the reservations is to avoid code duplication and having to change two places when something needs to be updated. >> >> There will be some small changes in what is getting logged in some cases, but the goal is to avoid changing behavior as much as possible. >> >> Some additional notes to help reviewing: >> * There are two reservation helpers: >> `reserve_memory()` for regular pages and file backed mappings. >> `reserve_memory_special()` for explicit large pages. >> * In `reserve_memory()` the `is_align()`-check at the end was previously done at the end of `initialize()`. It was moved here because this is the only case where an unaligned address can be returned. For large pages as well as when a requested address is provided, the returned address will be aligned. >> * The support to have a backing file is only used by the heap when `AllocateHeapAt` is set. If this option is used together with `UseLargePages` a debug message is printed since it is up to the backing file system if large pages are used or not. This output has been unified and is now printed when the file is created rather then deep in the reservation code. Previously this message differed depending on if `UseCompressedOops` was enabled or not. Now the same message is printed for both cases. >> >> * The failure checking function `failed_to_reserve_as_requested(...)` now only checks if the memory was allocated at the expected address. Releasing the memory is done by the caller. >> >> * The size passed into `map_or_reserve_memory_aligned` was previously aligned up using the alignment, but the size should always be aligned already. An assert has been added to the start of the `reserve` function and the `align_up` has been removed. >> >> **Testing** >> A lot of local testing as well as tier1-tier5 in Mach5. > > Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision: > > Thomas and Ivan review Thanks for reviewing @walulyai and @tschatzl. I've addressed your comments and did some small additional changes to comments. ------------- PR: https://git.openjdk.java.net/jdk/pull/3570 From sjohanss at openjdk.java.net Thu Apr 22 14:01:50 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Thu, 22 Apr 2021 14:01:50 GMT Subject: RFR: 8265268: Unify ReservedSpace reservation code in initialize and try_reserve_heap [v2] In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 11:55:03 GMT, Thomas Schatzl wrote: >> Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision: >> >> Thomas and Ivan review > > src/hotspot/share/memory/virtualspace.cpp line 146: > >> 144: char* base; >> 145: // If the memory was requested at a particular address, use >> 146: // os::attempt_reserve_memory_at() to avoid over mapping something > > "to avoid mapping over" - word order Fixed. > src/hotspot/share/memory/virtualspace.cpp line 147: > >> 145: // If the memory was requested at a particular address, use >> 146: // os::attempt_reserve_memory_at() to avoid over mapping something >> 147: // important. If available space is not detected, return NULL. > > "If available space is not detected" -> "If this (reservation) is unsuccessful...". > > available space detected != reservation possible/successful Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/3570 From sjohanss at openjdk.java.net Thu Apr 22 14:01:51 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Thu, 22 Apr 2021 14:01:51 GMT Subject: RFR: 8265268: Unify ReservedSpace reservation code in initialize and try_reserve_heap [v2] In-Reply-To: <8hHwRoZtjv2RD3yVrssiSjdxGiPE8Qcg8Yl1pN9rc9g=.12734c10-6747-4fb8-bc6d-e4af555d32b7@github.com> References: <8hHwRoZtjv2RD3yVrssiSjdxGiPE8Qcg8Yl1pN9rc9g=.12734c10-6747-4fb8-bc6d-e4af555d32b7@github.com> Message-ID: On Thu, 22 Apr 2021 08:42:51 GMT, Ivan Walulya wrote: >> Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision: >> >> Thomas and Ivan review > > src/hotspot/share/memory/virtualspace.cpp line 159: > >> 157: base = map_or_reserve_memory(size, fd, exec); >> 158: // Check alignment constraints. This is only needed when there is >> 159: // no requested address. If a requested address is used it must be > > "If a requested address is used it must be aligned." seems redundant here, as it is covered in the branch above, and the assert clearly states that. Yes, I added the assert later on and that really made this redundant. Removed. ------------- PR: https://git.openjdk.java.net/jdk/pull/3570 From sjohanss at openjdk.java.net Thu Apr 22 14:01:52 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Thu, 22 Apr 2021 14:01:52 GMT Subject: RFR: 8265268: Unify ReservedSpace reservation code in initialize and try_reserve_heap [v2] In-Reply-To: References: <8hHwRoZtjv2RD3yVrssiSjdxGiPE8Qcg8Yl1pN9rc9g=.12734c10-6747-4fb8-bc6d-e4af555d32b7@github.com> Message-ID: On Thu, 22 Apr 2021 11:56:24 GMT, Thomas Schatzl wrote: >> src/hotspot/share/memory/virtualspace.cpp line 184: >> >>> 182: // Check alignment constraints. >>> 183: assert((uintptr_t)base % alignment == 0, >>> 184: "Large pages returned a non-aligned address, base: " PTR_FORMAT >> >> "Reserve large pages returned..." > > s/Reserve/Reserving Since it's an assert I changed it to be more explicit: "reserve_memory_special() returned an unaligned address..." Also change the condition to use `is_aligned(...)`. >> src/hotspot/share/memory/virtualspace.cpp line 188: >> >>> 186: p2i(base), alignment); >>> 187: } else { >>> 188: // failed; fall back to reserve regular memory. >> >> Shouldn't we have this in the caller, because it is up to the caller to do the fallback. > > At least this comment suggests some action that is never taken. As Ivan states this is handled by the caller in `reserve()`, so I moved the comment there. Also change the wording a bit. ------------- PR: https://git.openjdk.java.net/jdk/pull/3570 From sjohanss at openjdk.java.net Thu Apr 22 14:01:52 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Thu, 22 Apr 2021 14:01:52 GMT Subject: RFR: 8265268: Unify ReservedSpace reservation code in initialize and try_reserve_heap [v2] In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 13:44:43 GMT, Thomas Schatzl wrote: >> src/hotspot/share/memory/virtualspace.cpp line 217: >> >>> 215: // There are basically three different cases that we need to handle below: >>> 216: // - Mapping backed by a file >>> 217: // - Mapping backed by explicit large pages >> >> I think there should be a description what "explicit large pages" are. Only in the case that the OS can't commit large page memory this path is taken. >> The third option kind of suggests that there is only "explicit large page support" if you want large pages (only talking about normal pages or THP, but on e.g. Linux you do not need to pre-commit large pages reservations. > > @kstefanj enlightened me about that even on Linux we pre-commit everything *but* the linux counters (particularly `free_hugepages`) is not updated until the page has been touched. That misled me to believing that we do not need to actually precommit there. > So, ignore this comment. Discussed this with Thomas offline and we agreed on the current text being ok after all. ------------- PR: https://git.openjdk.java.net/jdk/pull/3570 From iwalulya at openjdk.java.net Thu Apr 22 14:08:22 2021 From: iwalulya at openjdk.java.net (Ivan Walulya) Date: Thu, 22 Apr 2021 14:08:22 GMT Subject: RFR: 8265268: Unify ReservedSpace reservation code in initialize and try_reserve_heap [v2] In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 14:01:48 GMT, Stefan Johansson wrote: >> Please review this change to unify the reservation code in ReservedSpace. >> >> **Summary** >> The code in `ReservedSpace::initialize(...)` and `ReservedHeapSpace::try_reserve_heap(...)` is very similar and more or less does the same things. The difference between them is logging, what is considered a failure and how that is handled. >> >> This change introduces a new function `ReservedSpace::reserve(...)` that is used by both `initialize(...)` and `try_reserve_heap(...)`. The biggest reason for only having one function handling the reservations is to avoid code duplication and having to change two places when something needs to be updated. >> >> There will be some small changes in what is getting logged in some cases, but the goal is to avoid changing behavior as much as possible. >> >> Some additional notes to help reviewing: >> * There are two reservation helpers: >> `reserve_memory()` for regular pages and file backed mappings. >> `reserve_memory_special()` for explicit large pages. >> * In `reserve_memory()` the `is_align()`-check at the end was previously done at the end of `initialize()`. It was moved here because this is the only case where an unaligned address can be returned. For large pages as well as when a requested address is provided, the returned address will be aligned. >> * The support to have a backing file is only used by the heap when `AllocateHeapAt` is set. If this option is used together with `UseLargePages` a debug message is printed since it is up to the backing file system if large pages are used or not. This output has been unified and is now printed when the file is created rather then deep in the reservation code. Previously this message differed depending on if `UseCompressedOops` was enabled or not. Now the same message is printed for both cases. >> >> * The failure checking function `failed_to_reserve_as_requested(...)` now only checks if the memory was allocated at the expected address. Releasing the memory is done by the caller. >> >> * The size passed into `map_or_reserve_memory_aligned` was previously aligned up using the alignment, but the size should always be aligned already. An assert has been added to the start of the `reserve` function and the `align_up` has been removed. >> >> **Testing** >> A lot of local testing as well as tier1-tier5 in Mach5. > > Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision: > > Thomas and Ivan review src/hotspot/share/memory/virtualspace.cpp line 189: > 187: if (large_pages_requested()) { > 188: log_debug(gc, heap, coops)("Reserve regular memory without large pages"); > 189: } I think we should move this entire block to the caller. ------------- PR: https://git.openjdk.java.net/jdk/pull/3570 From sjohanss at openjdk.java.net Thu Apr 22 14:22:24 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Thu, 22 Apr 2021 14:22:24 GMT Subject: RFR: 8265268: Unify ReservedSpace reservation code in initialize and try_reserve_heap [v2] In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 14:05:35 GMT, Ivan Walulya wrote: >> Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision: >> >> Thomas and Ivan review > > src/hotspot/share/memory/virtualspace.cpp line 189: > >> 187: if (large_pages_requested()) { >> 188: log_debug(gc, heap, coops)("Reserve regular memory without large pages"); >> 189: } > > I think we should move this entire block to the caller. I thought about this as well, but wanted to keep `reserve(...)` as "clean" as possible and this log-message is connected to reserving large pages which is handled in `reserve_memory_special(...)`. The strange thing is that this log is using the tag-set `gc, heap, coops` (pre-existing) which suggests that we could move it all the way out to `try_reserve_heap(...)`. The problem with doing that is that this log is used by the test: TestLargePageUseForAuxMemory for other mappings than the heap. It would most likely make sense to move this message to a different tag-set or possibly split it so that this log only is printed for the heap and we have a different one for other mappings. The sad part about that is that the log message and the "failure" becomes more separated. ------------- PR: https://git.openjdk.java.net/jdk/pull/3570 From iignatyev at openjdk.java.net Thu Apr 22 14:24:46 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Thu, 22 Apr 2021 14:24:46 GMT Subject: RFR: 8259316: [REDO] C1/C2 compiler support for blackholes [v4] In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 14:22:00 GMT, Aleksey Shipilev wrote: >> This reworks the compiler support for blackholes. The key difference against the last version (#1203) is that blackholes are only acceptable as empty static methods, which both simplifies the implementation and eliminates a few compatibility questions. >> >> JMH uses the `Blackhole::consume` methods to avoid dead-code elimination of the code that produces benchmark values. It now relies on producing opaque side-effects and breaking inlining. While it was proved useful for many years, it unfortunately comes with several major drawbacks. >> >> Instead of introducing public APIs or special-casing JMH methods in JVM, we can hook a new command to compiler control, and let JMH sign up its `Blackhole` methods for it with `-XX:CompileCommand=blackhole,org.openjdk.jmh.infra.Blackhole::consume`. See CSR and related discussion for alternatives and future plans. >> >> C1 code is platform-independent, and it handles blackhole via the intrinsics paths, lowering it to nothing. >> >> C2 makes the `Blackhole` the subclass of `MemBar`, and use the same `Matcher` path as `Op_MemCPUOrder`: it does not match to anything, but it survives until matching, and keeps arguments alive. Additionally, C1 and C2 hooks are now using the synthetic `_blackhole` intrinsic, similarly to existing `_compiledLambdaForm`. It avoids introducing new nodes in C1. It also seems to require the least fiddling with C2 internals. > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Remove @build in favor of @library Marked as reviewed by iignatyev (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/2024 From shade at openjdk.java.net Thu Apr 22 14:24:46 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 22 Apr 2021 14:24:46 GMT Subject: RFR: 8259316: [REDO] C1/C2 compiler support for blackholes [v2] In-Reply-To: References: <-MM1SeUWBAkFc_dMmWBjAmM6mt6M2o2Ze3TC4xp-t7g=.3c1bf1c4-6e84-4a04-a2e2-d03db0b92498@github.com> Message-ID: On Thu, 22 Apr 2021 13:37:11 GMT, Igor Ignatyev wrote: > ``` > - * @library /test/lib > - * @build compiler.blackhole.BlackholeTarget > + * @library /test/lib / > ``` I see! Did so in the new commit. ------------- PR: https://git.openjdk.java.net/jdk/pull/2024 From shade at openjdk.java.net Thu Apr 22 14:24:45 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 22 Apr 2021 14:24:45 GMT Subject: RFR: 8259316: [REDO] C1/C2 compiler support for blackholes [v4] In-Reply-To: References: Message-ID: > This reworks the compiler support for blackholes. The key difference against the last version (#1203) is that blackholes are only acceptable as empty static methods, which both simplifies the implementation and eliminates a few compatibility questions. > > JMH uses the `Blackhole::consume` methods to avoid dead-code elimination of the code that produces benchmark values. It now relies on producing opaque side-effects and breaking inlining. While it was proved useful for many years, it unfortunately comes with several major drawbacks. > > Instead of introducing public APIs or special-casing JMH methods in JVM, we can hook a new command to compiler control, and let JMH sign up its `Blackhole` methods for it with `-XX:CompileCommand=blackhole,org.openjdk.jmh.infra.Blackhole::consume`. See CSR and related discussion for alternatives and future plans. > > C1 code is platform-independent, and it handles blackhole via the intrinsics paths, lowering it to nothing. > > C2 makes the `Blackhole` the subclass of `MemBar`, and use the same `Matcher` path as `Op_MemCPUOrder`: it does not match to anything, but it survives until matching, and keeps arguments alive. Additionally, C1 and C2 hooks are now using the synthetic `_blackhole` intrinsic, similarly to existing `_compiledLambdaForm`. It avoids introducing new nodes in C1. It also seems to require the least fiddling with C2 internals. Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: Remove @build in favor of @library ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2024/files - new: https://git.openjdk.java.net/jdk/pull/2024/files/00c199ba..f8bc8271 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2024&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2024&range=02-03 Stats: 12 lines in 6 files changed: 0 ins; 6 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/2024.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2024/head:pull/2024 PR: https://git.openjdk.java.net/jdk/pull/2024 From iwalulya at openjdk.java.net Thu Apr 22 14:34:23 2021 From: iwalulya at openjdk.java.net (Ivan Walulya) Date: Thu, 22 Apr 2021 14:34:23 GMT Subject: RFR: 8265268: Unify ReservedSpace reservation code in initialize and try_reserve_heap [v2] In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 14:19:20 GMT, Stefan Johansson wrote: >> src/hotspot/share/memory/virtualspace.cpp line 189: >> >>> 187: if (large_pages_requested()) { >>> 188: log_debug(gc, heap, coops)("Reserve regular memory without large pages"); >>> 189: } >> >> I think we should move this entire block to the caller. > > I thought about this as well, but wanted to keep `reserve(...)` as "clean" as possible and this log-message is connected to reserving large pages which is handled in `reserve_memory_special(...)`. > > The strange thing is that this log is using the tag-set `gc, heap, coops` (pre-existing) which suggests that we could move it all the way out to `try_reserve_heap(...)`. The problem with doing that is that this log is used by the test: TestLargePageUseForAuxMemory for other mappings than the heap. It would most likely make sense to move this message to a different tag-set or possibly split it so that this log only is printed for the heap and we have a different one for other mappings. The sad part about that is that the log message and the "failure" becomes more separated. ok, that seems reasonable. We can leave it as is. ------------- PR: https://git.openjdk.java.net/jdk/pull/3570 From tschatzl at openjdk.java.net Thu Apr 22 15:11:22 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 22 Apr 2021 15:11:22 GMT Subject: RFR: 8265268: Unify ReservedSpace reservation code in initialize and try_reserve_heap [v2] In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 14:01:48 GMT, Stefan Johansson wrote: >> Please review this change to unify the reservation code in ReservedSpace. >> >> **Summary** >> The code in `ReservedSpace::initialize(...)` and `ReservedHeapSpace::try_reserve_heap(...)` is very similar and more or less does the same things. The difference between them is logging, what is considered a failure and how that is handled. >> >> This change introduces a new function `ReservedSpace::reserve(...)` that is used by both `initialize(...)` and `try_reserve_heap(...)`. The biggest reason for only having one function handling the reservations is to avoid code duplication and having to change two places when something needs to be updated. >> >> There will be some small changes in what is getting logged in some cases, but the goal is to avoid changing behavior as much as possible. >> >> Some additional notes to help reviewing: >> * There are two reservation helpers: >> `reserve_memory()` for regular pages and file backed mappings. >> `reserve_memory_special()` for explicit large pages. >> * In `reserve_memory()` the `is_align()`-check at the end was previously done at the end of `initialize()`. It was moved here because this is the only case where an unaligned address can be returned. For large pages as well as when a requested address is provided, the returned address will be aligned. >> * The support to have a backing file is only used by the heap when `AllocateHeapAt` is set. If this option is used together with `UseLargePages` a debug message is printed since it is up to the backing file system if large pages are used or not. This output has been unified and is now printed when the file is created rather then deep in the reservation code. Previously this message differed depending on if `UseCompressedOops` was enabled or not. Now the same message is printed for both cases. >> >> * The failure checking function `failed_to_reserve_as_requested(...)` now only checks if the memory was allocated at the expected address. Releasing the memory is done by the caller. >> >> * The size passed into `map_or_reserve_memory_aligned` was previously aligned up using the alignment, but the size should always be aligned already. An assert has been added to the start of the `reserve` function and the `align_up` has been removed. >> >> **Testing** >> A lot of local testing as well as tier1-tier5 in Mach5. > > Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision: > > Thomas and Ivan review Looks good apart from that indentation issue. src/hotspot/share/memory/virtualspace.cpp line 187: > 185: p2i(base), alignment); > 186: } else { > 187: if (large_pages_requested()) { Indentation. ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3570 From gziemski at openjdk.java.net Thu Apr 22 16:00:33 2021 From: gziemski at openjdk.java.net (Gerard Ziemski) Date: Thu, 22 Apr 2021 16:00:33 GMT Subject: RFR: 8265702: ZGC on macOS/aarch64 [v2] In-Reply-To: <7qkG6INxywBIAyzPqO812c7Pn7IUp5gZzfcjl27lE2E=.73fa7b17-7f51-4cdc-b621-e44d3b619740@github.com> References: <7qkG6INxywBIAyzPqO812c7Pn7IUp5gZzfcjl27lE2E=.73fa7b17-7f51-4cdc-b621-e44d3b619740@github.com> Message-ID: On Thu, 22 Apr 2021 06:43:45 GMT, Per Liden wrote: >> This patch enables ZGC on macOS/aarch64. It does three things: >> 1) Enables building of ZGC on this platform. >> 2) Adds `os::processor_id()`, which for now always returns 0. >> 3) Fixes a WX issue in `OptoRuntime::handle_exception_C()`, where the stackwater mark might unnecessarily process a frame when the thread is in WXExec mode. In this case, the we're not touching any oops, so we don't need to process any frames. >> >> Testing: Passes the same tests as macOS/x86_64 (with the exception of pre-existing issues unrelated to ZGC). > > Per Liden has updated the pull request incrementally with one additional commit since the last revision: > > Add comment to #else Marked as reviewed by gziemski (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3609 From avoitylov at openjdk.java.net Thu Apr 22 16:01:53 2021 From: avoitylov at openjdk.java.net (Aleksei Voitylov) Date: Thu, 22 Apr 2021 16:01:53 GMT Subject: RFR: 8265756: AArch64: initialize memory allocated for locals according to Windows AArch64 stack page growth requirement in template interpreter Message-ID: Hi, please review this PR which fixes several JCK test failures on Windows AArch64. On Windows AArch64, the order in which the pages are touched during stack allocation, matters. Here is a quote: "Functions that allocate 4k or more worth of stack must ensure that each page prior to the final page is touched in order" [1]. Since on Linux and Mac the order does not matter, the suggested fix reverses the order in which memory pages are touched during stack allocation for locals in template interpreter for all platforms. Testing: JCK, jtreg, newly developed regression test on Linux AArch64, Windows AArch64, Mac AArch64, Pre-submit tests (which includes the newly developed test). [1] https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-160#stack ------------- Commit messages: - add reproducer to jtreg - JDK-8265756: AArch64: initialize memory allocated for locals according to Windows AArch64 stack page growth requirement in template interpreter Changes: https://git.openjdk.java.net/jdk/pull/3633/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3633&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265756 Stats: 112 lines in 3 files changed: 105 ins; 5 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3633.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3633/head:pull/3633 PR: https://git.openjdk.java.net/jdk/pull/3633 From iwalulya at openjdk.java.net Thu Apr 22 16:03:22 2021 From: iwalulya at openjdk.java.net (Ivan Walulya) Date: Thu, 22 Apr 2021 16:03:22 GMT Subject: RFR: 8265268: Unify ReservedSpace reservation code in initialize and try_reserve_heap [v2] In-Reply-To: References: Message-ID: <2fgF2yLHCiC6_j7xEhTJrSyhZOaci500jRu6EUpvt9c=.992ae106-89a9-4d34-a90b-a86f69b6313a@github.com> On Thu, 22 Apr 2021 14:01:48 GMT, Stefan Johansson wrote: >> Please review this change to unify the reservation code in ReservedSpace. >> >> **Summary** >> The code in `ReservedSpace::initialize(...)` and `ReservedHeapSpace::try_reserve_heap(...)` is very similar and more or less does the same things. The difference between them is logging, what is considered a failure and how that is handled. >> >> This change introduces a new function `ReservedSpace::reserve(...)` that is used by both `initialize(...)` and `try_reserve_heap(...)`. The biggest reason for only having one function handling the reservations is to avoid code duplication and having to change two places when something needs to be updated. >> >> There will be some small changes in what is getting logged in some cases, but the goal is to avoid changing behavior as much as possible. >> >> Some additional notes to help reviewing: >> * There are two reservation helpers: >> `reserve_memory()` for regular pages and file backed mappings. >> `reserve_memory_special()` for explicit large pages. >> * In `reserve_memory()` the `is_align()`-check at the end was previously done at the end of `initialize()`. It was moved here because this is the only case where an unaligned address can be returned. For large pages as well as when a requested address is provided, the returned address will be aligned. >> * The support to have a backing file is only used by the heap when `AllocateHeapAt` is set. If this option is used together with `UseLargePages` a debug message is printed since it is up to the backing file system if large pages are used or not. This output has been unified and is now printed when the file is created rather then deep in the reservation code. Previously this message differed depending on if `UseCompressedOops` was enabled or not. Now the same message is printed for both cases. >> >> * The failure checking function `failed_to_reserve_as_requested(...)` now only checks if the memory was allocated at the expected address. Releasing the memory is done by the caller. >> >> * The size passed into `map_or_reserve_memory_aligned` was previously aligned up using the alignment, but the size should always be aligned already. An assert has been added to the start of the `reserve` function and the `align_up` has been removed. >> >> **Testing** >> A lot of local testing as well as tier1-tier5 in Mach5. > > Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision: > > Thomas and Ivan review Marked as reviewed by iwalulya (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3570 From adinn at openjdk.java.net Thu Apr 22 16:12:23 2021 From: adinn at openjdk.java.net (Andrew Dinn) Date: Thu, 22 Apr 2021 16:12:23 GMT Subject: RFR: 8265756: AArch64: initialize memory allocated for locals according to Windows AArch64 stack page growth requirement in template interpreter In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 15:55:40 GMT, Aleksei Voitylov wrote: > Hi, > > please review this PR which fixes several JCK test failures on Windows AArch64. On Windows AArch64, the order in which the pages are touched during stack allocation, matters. Here is a quote: "Functions that allocate 4k or more worth of stack must ensure that each page prior to the final page is touched in order" [1]. Since on Linux and Mac the order does not matter, the suggested fix reverses the order in which memory pages are touched during stack allocation for locals in template interpreter for all platforms. > > Testing: JCK, jtreg, newly developed regression test on Linux AArch64, Windows AArch64, Mac AArch64, Pre-submit tests (which includes the newly developed test). > > [1] https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-160#stack Looks good. ------------- Marked as reviewed by adinn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3633 From ccheung at openjdk.java.net Thu Apr 22 16:35:21 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Thu, 22 Apr 2021 16:35:21 GMT Subject: RFR: 8265393: VM crashes if both -XX:+RecordDynamicDumpInfo and -XX:SharedArchiveFile options are specified [v2] In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 04:56:01 GMT, Yumin Qi wrote: >> Hi, Please review >> 1) When the two flags -XX:+RecordDynamicDumpInfo and -XX:SharedArchiveFile used, in >> Arguments::init_shared_archive_paths() : >> if (DynamicDumpSharedSpaces) { >> if (os::same_files(SharedArchiveFile, ArchiveClassesAtExit)) { >> ... >> ArchiveClassesAtExit is NULL. >> C++ does not have a defined behavior of strcmp with strings of NULL. Posix version of os::same_files(const char* file1, const char* file2) calls strcmp without checking input args. This should be same as it is treated on Windows. >> 2) JCmdTest.java is fat and possible to cause test timeout. Split JCmdTest.java into two separate Tests: JCmdTestStaticDump.java and JCmdTestDynamicDump.java. >> 3) Add a test to check run with -XX:+RecordDynamicDumpInfo and -XX:SharedArchiveFile in JCmdTestDynamicDump.java >> The test does not use utility to create jvm process since it will take testing envs into process, but the way in the test using LingeredApp does not take envs. >> >> Tests: tier1,tier2,tier3,tier4 >> >> Thanks >> Yumin > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Abstract common code into base class Looks good. I spotted some minor issues in the test code. Thanks, Calvin ------------- Changes requested by ccheung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3599 From ccheung at openjdk.java.net Thu Apr 22 16:41:25 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Thu, 22 Apr 2021 16:41:25 GMT Subject: RFR: 8265393: VM crashes if both -XX:+RecordDynamicDumpInfo and -XX:SharedArchiveFile options are specified [v2] In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 04:56:01 GMT, Yumin Qi wrote: >> Hi, Please review >> 1) When the two flags -XX:+RecordDynamicDumpInfo and -XX:SharedArchiveFile used, in >> Arguments::init_shared_archive_paths() : >> if (DynamicDumpSharedSpaces) { >> if (os::same_files(SharedArchiveFile, ArchiveClassesAtExit)) { >> ... >> ArchiveClassesAtExit is NULL. >> C++ does not have a defined behavior of strcmp with strings of NULL. Posix version of os::same_files(const char* file1, const char* file2) calls strcmp without checking input args. This should be same as it is treated on Windows. >> 2) JCmdTest.java is fat and possible to cause test timeout. Split JCmdTest.java into two separate Tests: JCmdTestStaticDump.java and JCmdTestDynamicDump.java. >> 3) Add a test to check run with -XX:+RecordDynamicDumpInfo and -XX:SharedArchiveFile in JCmdTestDynamicDump.java >> The test does not use utility to create jvm process since it will take testing envs into process, but the way in the test using LingeredApp does not take envs. >> >> Tests: tier1,tier2,tier3,tier4 >> >> Thanks >> Yumin > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Abstract common code into base class test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestDumpBase.java line 31: > 29: > 30: import jdk.test.lib.apps.LingeredApp; > 31: import jdk.test.lib.cds.CDSTestUtils; Extra import test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestDumpBase.java line 35: > 33: import jdk.test.lib.process.OutputAnalyzer; > 34: import jdk.test.lib.process.ProcessTools; > 35: import jdk.test.lib.JDKToolFinder; Extra import test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestDumpBase.java line 40: > 38: > 39: import java.io.InputStreamReader; > 40: import java.io.BufferedReader; Extra import. test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestDumpBase.java line 71: > 69: "jdk/test/lib/apps/LingeredApp", > 70: "jdk/test/lib/apps/LingeredApp$1"}; > 71: private static final String BOOT_CLASSES[] = {"Hello"}; Too many blank spaces before the '='. test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestDumpBase.java line 82: > 80: System.out.println("Jar file created: " + testJar); > 81: System.out.println("Jar file created: " + bootJar); > 82: allJars = testJar+ File.pathSeparator + bootJar; Need a blank space after `testJar`. test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestDynamicDump.java line 42: > 40: import java.io.IOException; > 41: import java.util.ArrayList; > 42: import java.util.List; Extra import. test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestDynamicDump.java line 46: > 44: import jdk.test.lib.apps.LingeredApp; > 45: import jdk.test.lib.cds.CDSTestUtils; > 46: import jdk.test.lib.dcmd.PidJcmdExecutor; Extra import. test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestDynamicDump.java line 52: > 50: > 51: import java.io.InputStreamReader; > 52: import java.io.BufferedReader; Extra import. test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestStaticDump.java line 43: > 41: import java.nio.file.Path; > 42: import java.util.ArrayList; > 43: import java.util.List; Extra import. test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestStaticDump.java line 50: > 48: > 49: import java.io.InputStreamReader; > 50: import java.io.BufferedReader; Extra import. test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestStaticDump.java line 89: > 87: final boolean noBoot = !useBoot; > 88: final boolean EXPECT_PASS = true; > 89: final boolean EXPECT_FAIL = !EXPECT_PASS; These are also used in JCmdTestDynamicDump. Maybe move them to JCmdTestDumpBase? ------------- PR: https://git.openjdk.java.net/jdk/pull/3599 From github.com+168222+mgkwill at openjdk.java.net Thu Apr 22 18:44:58 2021 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Thu, 22 Apr 2021 18:44:58 GMT Subject: RFR: 8265491: Math Signum optimization for x86 [v6] In-Reply-To: References: Message-ID: <-OoR0roTaaBaxayn8kBzM1YVMHgicNGxa6hcVRnH1oE=.485b7b08-e12b-49e0-9ca7-cfef150e588b@github.com> > x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM. > > We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization. > > Base: > > Benchmark Mode Cnt Score Error Units > Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op > Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op > Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op > Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op > > > Optimized: > signum intrinsic patch > > Benchmark Mode Cnt Score Error Units > Signum._1_signumFloatTest avgt 5 3.769 ? 0.015 ns/op > Signum._2_overheadFloat avgt 5 3.312 ? 0.025 ns/op > Signum._3_signumDoubleTest avgt 5 3.765 ? 0.005 ns/op > Signum._4_overheadDouble avgt 5 3.309 ? 0.010 ns/op > > > Signed-off-by: Marcus G K Williams Marcus G K Williams has updated the pull request incrementally with two additional commits since the last revision: - Implement Default UseSignumIntrinsic suggestion Signed-off-by: Marcus G K Williams - Use three operand xorps/d Signed-off-by: Marcus G K Williams ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3581/files - new: https://git.openjdk.java.net/jdk/pull/3581/files/895eab4d..afefdc28 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3581&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3581&range=04-05 Stats: 21 lines in 3 files changed: 10 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/3581.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3581/head:pull/3581 PR: https://git.openjdk.java.net/jdk/pull/3581 From minqi at openjdk.java.net Thu Apr 22 18:44:54 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 22 Apr 2021 18:44:54 GMT Subject: RFR: 8265393: VM crashes if both -XX:+RecordDynamicDumpInfo and -XX:SharedArchiveFile options are specified [v3] In-Reply-To: References: Message-ID: > Hi, Please review > 1) When the two flags -XX:+RecordDynamicDumpInfo and -XX:SharedArchiveFile used, in > Arguments::init_shared_archive_paths() : > if (DynamicDumpSharedSpaces) { > if (os::same_files(SharedArchiveFile, ArchiveClassesAtExit)) { > ... > ArchiveClassesAtExit is NULL. > C++ does not have a defined behavior of strcmp with strings of NULL. Posix version of os::same_files(const char* file1, const char* file2) calls strcmp without checking input args. This should be same as it is treated on Windows. > 2) JCmdTest.java is fat and possible to cause test timeout. Split JCmdTest.java into two separate Tests: JCmdTestStaticDump.java and JCmdTestDynamicDump.java. > 3) Add a test to check run with -XX:+RecordDynamicDumpInfo and -XX:SharedArchiveFile in JCmdTestDynamicDump.java > The test does not use utility to create jvm process since it will take testing envs into process, but the way in the test using LingeredApp does not take envs. > > Tests: tier1,tier2,tier3,tier4 > > Thanks > Yumin Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Remove extra imports, fix nits to review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3599/files - new: https://git.openjdk.java.net/jdk/pull/3599/files/ae4b3690..489134c4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3599&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3599&range=01-02 Stats: 47 lines in 3 files changed: 7 ins; 36 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3599.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3599/head:pull/3599 PR: https://git.openjdk.java.net/jdk/pull/3599 From ccheung at openjdk.java.net Thu Apr 22 18:54:25 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Thu, 22 Apr 2021 18:54:25 GMT Subject: RFR: 8265393: VM crashes if both -XX:+RecordDynamicDumpInfo and -XX:SharedArchiveFile options are specified [v3] In-Reply-To: References: Message-ID: <1wXCl23O4Ns_5DuTbLDM0Ug9-bib1k_vShVKyPe1wCA=.44a3f84c-9472-4322-bbd1-8dce66acd025@github.com> On Thu, 22 Apr 2021 18:44:54 GMT, Yumin Qi wrote: >> Hi, Please review >> 1) When the two flags -XX:+RecordDynamicDumpInfo and -XX:SharedArchiveFile used, in >> Arguments::init_shared_archive_paths() : >> if (DynamicDumpSharedSpaces) { >> if (os::same_files(SharedArchiveFile, ArchiveClassesAtExit)) { >> ... >> ArchiveClassesAtExit is NULL. >> C++ does not have a defined behavior of strcmp with strings of NULL. Posix version of os::same_files(const char* file1, const char* file2) calls strcmp without checking input args. This should be same as it is treated on Windows. >> 2) JCmdTest.java is fat and possible to cause test timeout. Split JCmdTest.java into two separate Tests: JCmdTestStaticDump.java and JCmdTestDynamicDump.java. >> 3) Add a test to check run with -XX:+RecordDynamicDumpInfo and -XX:SharedArchiveFile in JCmdTestDynamicDump.java >> The test does not use utility to create jvm process since it will take testing envs into process, but the way in the test using LingeredApp does not take envs. >> >> Tests: tier1,tier2,tier3,tier4 >> >> Thanks >> Yumin > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Remove extra imports, fix nits to review comments LGTM. ------------- Marked as reviewed by ccheung (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3599 From minqi at openjdk.java.net Thu Apr 22 18:57:24 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 22 Apr 2021 18:57:24 GMT Subject: RFR: 8265393: VM crashes if both -XX:+RecordDynamicDumpInfo and -XX:SharedArchiveFile options are specified [v3] In-Reply-To: <1wXCl23O4Ns_5DuTbLDM0Ug9-bib1k_vShVKyPe1wCA=.44a3f84c-9472-4322-bbd1-8dce66acd025@github.com> References: <1wXCl23O4Ns_5DuTbLDM0Ug9-bib1k_vShVKyPe1wCA=.44a3f84c-9472-4322-bbd1-8dce66acd025@github.com> Message-ID: <7HX2QJ2BftIHgtcK8yFLnHhKRwD2SngJroPvVwJ60nk=.cdb98c56-9423-4042-bc10-617d129bc13f@github.com> On Thu, 22 Apr 2021 18:51:23 GMT, Calvin Cheung wrote: > LGTM. Thanks for review! ------------- PR: https://git.openjdk.java.net/jdk/pull/3599 From github.com+168222+mgkwill at openjdk.java.net Thu Apr 22 18:58:32 2021 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Thu, 22 Apr 2021 18:58:32 GMT Subject: RFR: 8265491: Math Signum optimization for x86 [v6] In-Reply-To: <-OoR0roTaaBaxayn8kBzM1YVMHgicNGxa6hcVRnH1oE=.485b7b08-e12b-49e0-9ca7-cfef150e588b@github.com> References: <-OoR0roTaaBaxayn8kBzM1YVMHgicNGxa6hcVRnH1oE=.485b7b08-e12b-49e0-9ca7-cfef150e588b@github.com> Message-ID: On Thu, 22 Apr 2021 18:44:58 GMT, Marcus G K Williams wrote: >> x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM. >> >> We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization. >> >> Base: >> >> Benchmark Mode Cnt Score Error Units >> Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op >> Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op >> Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op >> Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op >> >> >> Optimized: >> signum intrinsic patch >> >> Benchmark Mode Cnt Score Error Units >> Signum._1_signumFloatTest avgt 5 3.769 ? 0.015 ns/op >> Signum._2_overheadFloat avgt 5 3.312 ? 0.025 ns/op >> Signum._3_signumDoubleTest avgt 5 3.765 ? 0.005 ns/op >> Signum._4_overheadDouble avgt 5 3.309 ? 0.010 ns/op >> >> >> Signed-off-by: Marcus G K Williams > > Marcus G K Williams has updated the pull request incrementally with two additional commits since the last revision: > > - Implement Default UseSignumIntrinsic suggestion > > Signed-off-by: Marcus G K Williams > - Use three operand xorps/d > > Signed-off-by: Marcus G K Williams - Switched to 3 operand xorps/d on colleague suggestion to insure I don't introduce a hard to find register bug. - Implemented @DamonFool suggestion for Default Enable of UseSignumIntrinsic on x86. Slightly worried about `!has_match_rule(opcode)` for aarch64. But as long as it doesn't hit this I think it will work. src/hotspot/cpu/aarch64/aarch64.ad: const bool Matcher::match_rule_supported(int opcode) { if (!has_match_rule(opcode)) return false; Also moved matcher checks in src/hotspot/cpu/x86/x86.ad outside of #ifndef _LP64 #endif // !LP64 Thanks for the review @DamonFool @dholmes-ora @jatin-bhateja. ------------- PR: https://git.openjdk.java.net/jdk/pull/3581 From github.com+168222+mgkwill at openjdk.java.net Thu Apr 22 19:02:24 2021 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Thu, 22 Apr 2021 19:02:24 GMT Subject: RFR: 8265491: Math Signum optimization for x86 [v5] In-Reply-To: References: <4KS_ollgdqiNeQgI-XB2AKVJwpgtTo8lRRCwUvqTryk=.8597bbde-a56b-4d2a-a59c-8e80c83b3ec2@github.com> Message-ID: On Wed, 21 Apr 2021 23:53:50 GMT, Jie Fu wrote: >> Marcus G K Williams has updated the pull request incrementally with two additional commits since the last revision: >> >> - Reorder jcc equal,parity >> >> Signed-off-by: Marcus G K Williams >> - Use xorp to negate 1 >> >> Signed-off-by: Marcus G K Williams > > src/hotspot/cpu/x86/vm_version_x86.cpp line 1703: > >> 1701: } >> 1702: #endif // !PRODUCT >> 1703: if (FLAG_IS_DEFAULT(UseSignumIntrinsic) && (UseSSE >= 2)) { > > `UseSSE >=2` looks a bit uncomfortable to me since signumF_reg only requires UseSSE>=1. > > How about something like this: > > diff --git a/src/hotspot/cpu/x86/x86.ad b/src/hotspot/cpu/x86/x86.ad > index bbf5256c112..0a738704c4d 100644 > --- a/src/hotspot/cpu/x86/x86.ad > +++ b/src/hotspot/cpu/x86/x86.ad > @@ -1598,6 +1598,16 @@ const bool Matcher::match_rule_supported(int opcode) { > return false; > } > break; > + case Op_SignumF: > + if (UseSSE < 1) { > + return false; > + } > + break; > + case Op_SignumD: > + if (UseSSE < 2) { > + return false; > + } > + break; > #endif // !LP64 > } > return true; // Match rules are supported by default. > diff --git a/src/hotspot/share/opto/library_call.cpp b/src/hotspot/share/opto/library_call.cpp > index 7cb7955c612..217ee39d709 100644 > --- a/src/hotspot/share/opto/library_call.cpp > +++ b/src/hotspot/share/opto/library_call.cpp > @@ -1737,8 +1737,8 @@ bool LibraryCallKit::inline_math_native(vmIntrinsics::ID id) { > case vmIntrinsics::_dpow: return inline_math_pow(); > case vmIntrinsics::_dcopySign: return inline_double_math(id); > case vmIntrinsics::_fcopySign: return inline_math(id); > - case vmIntrinsics::_dsignum: return inline_double_math(id); > - case vmIntrinsics::_fsignum: return inline_math(id); > + case vmIntrinsics::_dsignum: return Matcher::match_rule_supported(Op_SignumD) ? inline_double_math(id) : false; > + case vmIntrinsics::_fsignum: return Matcher::match_rule_supported(Op_SignumF) ? inline_math(id) : false; > > // These intrinsics are not yet correctly implemented > case vmIntrinsics::_datan2: > > > In this way, we can enable UseSignumIntrinsic by default on x86. > Thanks. Thanks for the suggestion. This looks good as long as it doesn't affect aarch64. ------------- PR: https://git.openjdk.java.net/jdk/pull/3581 From minqi at openjdk.java.net Thu Apr 22 21:18:27 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 22 Apr 2021 21:18:27 GMT Subject: RFR: 8255493: Support for pre-generated java.lang.invoke classes in CDS dynamic archive In-Reply-To: References: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> Message-ID: <9GVQ8IrhFpCUuZ8HOuW7Od7UXTaHbL94JGCKEwrTDwA=.30bae633-ec12-41e9-9eba-a365f74eea29@github.com> On Thu, 22 Apr 2021 06:03:35 GMT, David Holmes wrote: >> Hi, Please review >> >> When do dynamic dump, the pre-generated lambda form classes from java.lang.invoke are not stored in dynamic archive. The patch will regenerate the four holder classes, >> "java.lang.invoke.Invokers$Holder", >> "java.lang.invoke.DirectMethodHandle$Holder", >> "java.lang.invoke.DelegatingMethodHandle$Holder", >> "java.lang.invoke.LambdaForm$Holder" >> which will include the versions in static archive and new loaded functions all together and stored in dynamic archive. New test case added. >> (Minor change to PrintSharedArchiveAtExit, which the index is not consecutive) >> >> Tests: tier1,tier2,tier3,tier4 >> >> Thanks >> Yumin > > src/hotspot/share/memory/dynamicArchive.cpp line 374: > >> 372: if (LambdaFormInvokers::should_regenerate_holder_classes()) { >> 373: JavaThread* THREAD = JavaThread::current(); >> 374: assert(THREAD->is_Java_thread(), "Should be JavaThread"); > > JavaThread::current() already asserts this. Will remove the assert. I will also move the check should_regenerate_holder_classes to LambdaFormInvokers::should_regenerate_holder_classes(). > src/hotspot/share/memory/dynamicArchive.cpp line 376: > >> 374: assert(THREAD->is_Java_thread(), "Should be JavaThread"); >> 375: log_info(cds, dynamic)("Regenerate lambdaform holder classes ..."); >> 376: LambdaFormInvokers::regenerate_holder_classes(THREAD); > > What if this throws an exception? If there is exception in java side to regenerate the holder classes, there is a log for cds to indicate the regeneration failed, the exception is cleared and continue. It will not affect other parts. ------------- PR: https://git.openjdk.java.net/jdk/pull/3611 From sviswanathan at openjdk.java.net Thu Apr 22 22:27:50 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Thu, 22 Apr 2021 22:27:50 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics Message-ID: Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods. These methods are built into a separate library instead of being part of libjvm.so or jvm.dll. The following changes are made: The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml. The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?. The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk. Changes are made to build system to support dependency tracking for assembly files with includes. The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux. The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library. Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com). This work is part of second round of incubation of the Vector API. JEP: https://bugs.openjdk.java.net/browse/JDK-8261663 Please review. Performance: Micro benchmark Base Optimized Unit Gain(Optimized/Base) Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 Double128Vector.COS 49.94 245.89 ops/ms 4.92 Double128Vector.COSH 26.91 126.00 ops/ms 4.68 Double128Vector.EXP 71.64 379.65 ops/ms 5.30 Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 Double128Vector.LOG 61.95 279.84 ops/ms 4.52 Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 Double128Vector.SIN 49.36 240.79 ops/ms 4.88 Double128Vector.SINH 26.59 103.75 ops/ms 3.90 Double128Vector.TAN 41.05 152.39 ops/ms 3.71 Double128Vector.TANH 45.29 169.53 ops/ms 3.74 Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 Double256Vector.COS 58.26 389.77 ops/ms 6.69 Double256Vector.COSH 29.44 151.11 ops/ms 5.13 Double256Vector.EXP 86.67 564.68 ops/ms 6.52 Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 Double256Vector.LOG 71.52 394.90 ops/ms 5.52 Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 Double256Vector.SIN 57.06 380.98 ops/ms 6.68 Double256Vector.SINH 29.40 117.37 ops/ms 3.99 Double256Vector.TAN 44.90 279.90 ops/ms 6.23 Double256Vector.TANH 54.08 274.71 ops/ms 5.08 Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 Double512Vector.COS 59.88 837.04 ops/ms 13.98 Double512Vector.COSH 30.34 172.76 ops/ms 5.70 Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 Double512Vector.LOG 74.84 996.00 ops/ms 13.31 Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 Double512Vector.POW 37.42 384.13 ops/ms 10.26 Double512Vector.SIN 59.74 728.45 ops/ms 12.19 Double512Vector.SINH 29.47 143.38 ops/ms 4.87 Double512Vector.TAN 46.20 587.21 ops/ms 12.71 Double512Vector.TANH 57.36 495.42 ops/ms 8.64 Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 Double64Vector.COS 23.42 152.01 ops/ms 6.49 Double64Vector.COSH 17.34 113.34 ops/ms 6.54 Double64Vector.EXP 27.08 203.53 ops/ms 7.52 Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 Double64Vector.LOG 26.75 142.63 ops/ms 5.33 Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 Double64Vector.SIN 23.28 146.91 ops/ms 6.31 Double64Vector.SINH 17.62 88.59 ops/ms 5.03 Double64Vector.TAN 21.00 86.43 ops/ms 4.12 Double64Vector.TANH 23.75 111.35 ops/ms 4.69 Float128Vector.ACOS 57.52 110.65 ops/ms 1.92 Float128Vector.ASIN 57.15 117.95 ops/ms 2.06 Float128Vector.ATAN 22.52 318.74 ops/ms 14.15 Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42 Float128Vector.CBRT 29.72 443.74 ops/ms 14.93 Float128Vector.COS 42.82 803.02 ops/ms 18.75 Float128Vector.COSH 31.44 118.34 ops/ms 3.76 Float128Vector.EXP 72.43 855.33 ops/ms 11.81 Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38 Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12 Float128Vector.LOG 52.95 877.94 ops/ms 16.58 Float128Vector.LOG10 49.26 603.72 ops/ms 12.26 Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61 Float128Vector.SIN 43.38 745.31 ops/ms 17.18 Float128Vector.SINH 31.11 112.91 ops/ms 3.63 Float128Vector.TAN 37.25 332.13 ops/ms 8.92 Float128Vector.TANH 57.63 453.77 ops/ms 7.87 Float256Vector.ACOS 65.23 123.73 ops/ms 1.90 Float256Vector.ASIN 63.41 132.86 ops/ms 2.10 Float256Vector.ATAN 23.51 649.02 ops/ms 27.61 Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07 Float256Vector.CBRT 45.99 594.81 ops/ms 12.93 Float256Vector.COS 43.75 926.69 ops/ms 21.18 Float256Vector.COSH 33.52 130.46 ops/ms 3.89 Float256Vector.EXP 75.70 1366.72 ops/ms 18.05 Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84 Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34 Float256Vector.LOG 53.31 1545.77 ops/ms 29.00 Float256Vector.LOG10 50.31 863.80 ops/ms 17.17 Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66 Float256Vector.SIN 44.07 911.04 ops/ms 20.67 Float256Vector.SINH 33.16 122.50 ops/ms 3.69 Float256Vector.TAN 37.85 497.75 ops/ms 13.15 Float256Vector.TANH 64.27 537.20 ops/ms 8.36 Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52 Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93 Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69 Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57 Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11 Float512Vector.COS 40.92 1567.93 ops/ms 38.32 Float512Vector.COSH 33.42 138.36 ops/ms 4.14 Float512Vector.EXP 70.51 3835.97 ops/ms 54.41 Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35 Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47 Float512Vector.LOG 49.61 3156.99 ops/ms 63.64 Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02 Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81 Float512Vector.POW 32.73 1015.85 ops/ms 31.04 Float512Vector.SIN 41.17 1587.71 ops/ms 38.56 Float512Vector.SINH 33.05 129.39 ops/ms 3.91 Float512Vector.TAN 35.60 1336.11 ops/ms 37.53 Float512Vector.TANH 65.77 2295.28 ops/ms 34.90 Float64Vector.ACOS 48.41 89.34 ops/ms 1.85 Float64Vector.ASIN 47.30 95.72 ops/ms 2.02 Float64Vector.ATAN 20.62 49.45 ops/ms 2.40 Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04 Float64Vector.CBRT 24.03 134.57 ops/ms 5.60 Float64Vector.COS 44.28 394.33 ops/ms 8.91 Float64Vector.COSH 28.35 95.27 ops/ms 3.36 Float64Vector.EXP 65.80 486.37 ops/ms 7.39 Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48 Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93 Float64Vector.LOG 51.93 163.25 ops/ms 3.14 Float64Vector.LOG10 49.53 147.98 ops/ms 2.99 Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77 Float64Vector.SIN 44.41 382.09 ops/ms 8.60 Float64Vector.SINH 28.20 90.68 ops/ms 3.22 Float64Vector.TAN 36.29 160.89 ops/ms 4.43 Float64Vector.TANH 47.65 214.04 ops/ms 4.49 ------------- Commit messages: - remove whitespace - Merge master - Small fix - cleanup - x86 short vector math optimization for Vector API Changes: https://git.openjdk.java.net/jdk/pull/3638/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265783 Stats: 417153 lines in 124 files changed: 416959 ins; 126 del; 68 mod Patch: https://git.openjdk.java.net/jdk/pull/3638.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3638/head:pull/3638 PR: https://git.openjdk.java.net/jdk/pull/3638 From david.holmes at oracle.com Thu Apr 22 22:45:43 2021 From: david.holmes at oracle.com (David Holmes) Date: Fri, 23 Apr 2021 08:45:43 +1000 Subject: RFR: 8255493: Support for pre-generated java.lang.invoke classes in CDS dynamic archive In-Reply-To: <9GVQ8IrhFpCUuZ8HOuW7Od7UXTaHbL94JGCKEwrTDwA=.30bae633-ec12-41e9-9eba-a365f74eea29@github.com> References: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> <9GVQ8IrhFpCUuZ8HOuW7Od7UXTaHbL94JGCKEwrTDwA=.30bae633-ec12-41e9-9eba-a365f74eea29@github.com> Message-ID: <893ed848-fc58-a980-3636-256aadc16df6@oracle.com> On 23/04/2021 7:18 am, Yumin Qi wrote: > On Thu, 22 Apr 2021 06:03:35 GMT, David Holmes wrote: >> src/hotspot/share/memory/dynamicArchive.cpp line 376: >> >>> 374: assert(THREAD->is_Java_thread(), "Should be JavaThread"); >>> 375: log_info(cds, dynamic)("Regenerate lambdaform holder classes ..."); >>> 376: LambdaFormInvokers::regenerate_holder_classes(THREAD); >> >> What if this throws an exception? > > If there is exception in java side to regenerate the holder classes, there is a log for cds to indicate the regeneration failed, the exception is cleared and continue. It will not affect other parts. There are two allocation sites in regenerate_holder_classes that use CHECK and so will return if an OOME is pending. In those cases the exception is neither logged nor cleared. Cheers, David ----- > ------------- > > PR: https://git.openjdk.java.net/jdk/pull/3611 > From dholmes at openjdk.java.net Thu Apr 22 23:29:27 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 22 Apr 2021 23:29:27 GMT Subject: RFR: 8265756: AArch64: initialize memory allocated for locals according to Windows AArch64 stack page growth requirement in template interpreter In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 15:55:40 GMT, Aleksei Voitylov wrote: > Hi, > > please review this PR which fixes several JCK test failures on Windows AArch64. On Windows AArch64, the order in which the pages are touched during stack allocation, matters. Here is a quote: "Functions that allocate 4k or more worth of stack must ensure that each page prior to the final page is touched in order" [1]. Since on Linux and Mac the order does not matter, the suggested fix reverses the order in which memory pages are touched during stack allocation for locals in template interpreter for all platforms. > > Testing: JCK, jtreg, newly developed regression test on Linux AArch64, Windows AArch64, Mac AArch64, Pre-submit tests (which includes the newly developed test). > > [1] https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-160#stack Can you please add comments to the new test explaining exactly what it is that the test is doing, why you need to use a jasm file etc. Also add an @bug tag to the test. Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/3633 From jiefu at openjdk.java.net Thu Apr 22 23:56:35 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 22 Apr 2021 23:56:35 GMT Subject: RFR: 8265491: Math Signum optimization for x86 [v6] In-Reply-To: <-OoR0roTaaBaxayn8kBzM1YVMHgicNGxa6hcVRnH1oE=.485b7b08-e12b-49e0-9ca7-cfef150e588b@github.com> References: <-OoR0roTaaBaxayn8kBzM1YVMHgicNGxa6hcVRnH1oE=.485b7b08-e12b-49e0-9ca7-cfef150e588b@github.com> Message-ID: On Thu, 22 Apr 2021 18:44:58 GMT, Marcus G K Williams wrote: >> x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM. >> >> We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization. >> >> Base: >> >> Benchmark Mode Cnt Score Error Units >> Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op >> Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op >> Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op >> Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op >> >> >> Optimized: >> signum intrinsic patch >> >> Benchmark Mode Cnt Score Error Units >> Signum._1_signumFloatTest avgt 5 3.769 ? 0.015 ns/op >> Signum._2_overheadFloat avgt 5 3.312 ? 0.025 ns/op >> Signum._3_signumDoubleTest avgt 5 3.765 ? 0.005 ns/op >> Signum._4_overheadDouble avgt 5 3.309 ? 0.010 ns/op >> >> >> Signed-off-by: Marcus G K Williams > > Marcus G K Williams has updated the pull request incrementally with two additional commits since the last revision: > > - Implement Default UseSignumIntrinsic suggestion > > Signed-off-by: Marcus G K Williams > - Use three operand xorps/d > > Signed-off-by: Marcus G K Williams Looks good to me. Thanks for your update. Please make sure the copyright year has been updated (TestSignumIntrinsic.java?) and all the imports are actually needed (import org.openjdk.jmh.annotations.Setup; ?). ------------- PR: https://git.openjdk.java.net/jdk/pull/3581 From xliu at openjdk.java.net Fri Apr 23 00:39:24 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Fri, 23 Apr 2021 00:39:24 GMT Subject: RFR: 8229517: Support for optional asynchronous/buffered logging [v8] In-Reply-To: References: Message-ID: <711MkdqQiop8W7j_y8LS9evcM2O76NJrC0nkPYgOJok=.21f502a5-fcd1-405b-a5f2-5b1442776101@github.com> > This patch provides a buffer to store asynchrounous messages and flush them to > underlying files periodically. Xin Liu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 18 additional commits since the last revision: - Refactor LogAsyncFlusher::abort() This change makes sure LogAsyncFlusher::abort() is lock-less. Therefore, it's not subject to mutex rank issue. Newly added gtest(mutex_lock_access_leaf) may deliberately trigger SIGSEGV while holding access rank mutex, so abort() must be lockless. - Merge branch 'master' into JDK-8229517 - Fix a race condition bug on LogAsyncFlusher termination. I saw intermitent crashes of java with the following arguments. -Xlog:'all=trace:file=hotspot-x.log:level,tags:filecount=0,async=true' --version The root cause is that there is a race condition between main thread _exit and LogAsyncFlusher::run. This patch added a synchronization using Terminator_lock in LogAsyncFlusher::terminate. This guranatees that no log entry will emit when main thread is exiting. - Resolve rank conflict between tty_lock and LogAsyncFlusher's _lock. LogAsyncFlusher::_lock ranks Mutex::tty on purpose, which is same as tty_lock. Ideally, they are orthogonal. In reality, it's possible that a thread emits logs to a log file while (mistakenly) holding tty_lock. ttyUnlocker is placed in enqueue member functions to resolve conflicts betwen them. This patch fixed the jtreg test: runtime/logging/RedefineClasses.java and the full brunt logging -Xlog:'all:file=hotspot.log::async=true' - Remove LogAsyncInterval completely It was used as a timeout parameter of the monitor. Now the monitor is waked up when the occupancy of asynclog buffer is more 3/4. - Support Jcmd pid VM.log disable This patch also supports to add a new output dynamically. If output_option specifies async=true, the new output will use asynchronous writing. Currently jcmd VM.log prohibts users from changing established output_options in runtime. users can disable them all and then recreate them with the new output_options. - Fix build issue with `--disable-precompiled-headers` - Inject the number of dropped messages since last dumpping. Each LogOutput has an independent counter. The out-of-band message "[number] messages dropped..." will be dumped into its corresponding LogOutput. - Revert "fix runtime/logging/RedefineClasses.java crashed with -XX:+AsyncLogging" This reverts commit 81b2a0cb2a6cf57b1cd0baacdf8c0419f14819b4. This problem is sidetracked by JDK-8265102. - fix runtime/logging/RedefineClasses.java crashed with -XX:+AsyncLogging nmethod::print(outputStream* st) should not obtain tty_lock by assuming st is defaultStream. It could be logStream as well. Currently, AyncLogFlusher::_lock has the same rank of tty_lock. https://issues.amazon.com/issues/JVM-563 - ... and 8 more: https://git.openjdk.java.net/jdk/compare/5e87deb4...4cf4a57f ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3135/files - new: https://git.openjdk.java.net/jdk/pull/3135/files/2bd104ff..4cf4a57f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3135&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3135&range=06-07 Stats: 124746 lines in 3715 files changed: 70137 ins; 41702 del; 12907 mod Patch: https://git.openjdk.java.net/jdk/pull/3135.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3135/head:pull/3135 PR: https://git.openjdk.java.net/jdk/pull/3135 From iklam at openjdk.java.net Fri Apr 23 01:12:58 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 23 Apr 2021 01:12:58 GMT Subject: RFR: 8265696: Move CDS sources to src/hotspot/shared/cds [v4] In-Reply-To: References: Message-ID: <54irbsjsyoXMzokCiBLZ6tA8du9aTbn1viKvfVArHb0=.ac9d7bec-bb98-4033-a4f6-eea95f8e38e9@github.com> > The number of CDS source files have grown significantly. To improve modularity, the following files should be moved a new directory, src/hotspot/share/cds. > > - src/hotspot/share/classfile/classListParser.cpp > - src/hotspot/share/classfile/classListParser.hpp > - src/hotspot/share/classfile/classListWriter.hpp > - src/hotspot/share/classfile/compactHashtable.cpp > - src/hotspot/share/classfile/compactHashtable.hpp > - src/hotspot/share/classfile/lambdaFormInvokers.cpp > - src/hotspot/share/classfile/lambdaFormInvokers.hpp > - src/hotspot/share/memory/archiveBuilder.cpp > - src/hotspot/share/memory/archiveBuilder.hpp > - src/hotspot/share/memory/archiveUtils.cpp > - src/hotspot/share/memory/archiveUtils.hpp > - src/hotspot/share/memory/archiveUtils.inline.hpp > - src/hotspot/share/memory/cppVtables.cpp > - src/hotspot/share/memory/cppVtables.hpp > - src/hotspot/share/memory/dumpAllocStats.cpp > - src/hotspot/share/memory/dumpAllocStats.hpp > - src/hotspot/share/memory/dynamicArchive.cpp > - src/hotspot/share/memory/dynamicArchive.hpp > - src/hotspot/share/memory/filemap.cpp > - src/hotspot/share/memory/filemap.hpp > - src/hotspot/share/memory/heapShared.cpp > - src/hotspot/share/memory/heapShared.hpp > - src/hotspot/share/memory/heapShared.inline.hpp > - src/hotspot/share/memory/metaspaceShared.cpp > - src/hotspot/share/memory/metaspaceShared.hpp > - src/hotspot/share/prims/cdsoffsets.cpp > - src/hotspot/share/prims/cdsoffsets.hpp > > Testing with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: - Merge branch 'master' into 8265696-move-cds-sources - Merge branch 'master' into 8265696-move-cds-sources - exclude all files under shared/cds if CDS is disabled; compactHashtable.cpp cannot be excluded since a bit of it is used even when CDS is disabled - fixed include guards -> #ifndef SHARE_CDS_xxxxx - fixed copyright - moved more files - fixed include lines - 8265696: Move CDS sources from shared/memory to shared/cds ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3610/files - new: https://git.openjdk.java.net/jdk/pull/3610/files/729c6519..43c75a72 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3610&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3610&range=02-03 Stats: 5509 lines in 251 files changed: 2774 ins; 1594 del; 1141 mod Patch: https://git.openjdk.java.net/jdk/pull/3610.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3610/head:pull/3610 PR: https://git.openjdk.java.net/jdk/pull/3610 From iklam at openjdk.java.net Fri Apr 23 01:23:56 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 23 Apr 2021 01:23:56 GMT Subject: RFR: 8265696: Move CDS sources to src/hotspot/shared/cds [v5] In-Reply-To: References: Message-ID: > The number of CDS source files have grown significantly. To improve modularity, the following files should be moved a new directory, src/hotspot/share/cds. > > - src/hotspot/share/classfile/classListParser.cpp > - src/hotspot/share/classfile/classListParser.hpp > - src/hotspot/share/classfile/classListWriter.hpp > - src/hotspot/share/classfile/compactHashtable.cpp > - src/hotspot/share/classfile/compactHashtable.hpp > - src/hotspot/share/classfile/lambdaFormInvokers.cpp > - src/hotspot/share/classfile/lambdaFormInvokers.hpp > - src/hotspot/share/memory/archiveBuilder.cpp > - src/hotspot/share/memory/archiveBuilder.hpp > - src/hotspot/share/memory/archiveUtils.cpp > - src/hotspot/share/memory/archiveUtils.hpp > - src/hotspot/share/memory/archiveUtils.inline.hpp > - src/hotspot/share/memory/cppVtables.cpp > - src/hotspot/share/memory/cppVtables.hpp > - src/hotspot/share/memory/dumpAllocStats.cpp > - src/hotspot/share/memory/dumpAllocStats.hpp > - src/hotspot/share/memory/dynamicArchive.cpp > - src/hotspot/share/memory/dynamicArchive.hpp > - src/hotspot/share/memory/filemap.cpp > - src/hotspot/share/memory/filemap.hpp > - src/hotspot/share/memory/heapShared.cpp > - src/hotspot/share/memory/heapShared.hpp > - src/hotspot/share/memory/heapShared.inline.hpp > - src/hotspot/share/memory/metaspaceShared.cpp > - src/hotspot/share/memory/metaspaceShared.hpp > - src/hotspot/share/prims/cdsoffsets.cpp > - src/hotspot/share/prims/cdsoffsets.hpp > > Testing with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: - fixed merge - Merge branch 'master' into 8265696-move-cds-sources - Merge branch 'master' into 8265696-move-cds-sources - Merge branch 'master' into 8265696-move-cds-sources - exclude all files under shared/cds if CDS is disabled; compactHashtable.cpp cannot be excluded since a bit of it is used even when CDS is disabled - fixed include guards -> #ifndef SHARE_CDS_xxxxx - fixed copyright - moved more files - fixed include lines - 8265696: Move CDS sources from shared/memory to shared/cds ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3610/files - new: https://git.openjdk.java.net/jdk/pull/3610/files/43c75a72..5ca1c512 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3610&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3610&range=03-04 Stats: 47 lines in 6 files changed: 17 ins; 12 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/3610.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3610/head:pull/3610 PR: https://git.openjdk.java.net/jdk/pull/3610 From dholmes at openjdk.java.net Fri Apr 23 02:07:31 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Fri, 23 Apr 2021 02:07:31 GMT Subject: RFR: 8265696: Move CDS sources to src/hotspot/shared/cds [v5] In-Reply-To: References: Message-ID: On Fri, 23 Apr 2021 01:23:56 GMT, Ioi Lam wrote: >> The number of CDS source files have grown significantly. To improve modularity, the following files should be moved a new directory, src/hotspot/share/cds. >> >> - src/hotspot/share/classfile/classListParser.cpp >> - src/hotspot/share/classfile/classListParser.hpp >> - src/hotspot/share/classfile/classListWriter.hpp >> - src/hotspot/share/classfile/compactHashtable.cpp >> - src/hotspot/share/classfile/compactHashtable.hpp >> - src/hotspot/share/classfile/lambdaFormInvokers.cpp >> - src/hotspot/share/classfile/lambdaFormInvokers.hpp >> - src/hotspot/share/memory/archiveBuilder.cpp >> - src/hotspot/share/memory/archiveBuilder.hpp >> - src/hotspot/share/memory/archiveUtils.cpp >> - src/hotspot/share/memory/archiveUtils.hpp >> - src/hotspot/share/memory/archiveUtils.inline.hpp >> - src/hotspot/share/memory/cppVtables.cpp >> - src/hotspot/share/memory/cppVtables.hpp >> - src/hotspot/share/memory/dumpAllocStats.cpp >> - src/hotspot/share/memory/dumpAllocStats.hpp >> - src/hotspot/share/memory/dynamicArchive.cpp >> - src/hotspot/share/memory/dynamicArchive.hpp >> - src/hotspot/share/memory/filemap.cpp >> - src/hotspot/share/memory/filemap.hpp >> - src/hotspot/share/memory/heapShared.cpp >> - src/hotspot/share/memory/heapShared.hpp >> - src/hotspot/share/memory/heapShared.inline.hpp >> - src/hotspot/share/memory/metaspaceShared.cpp >> - src/hotspot/share/memory/metaspaceShared.hpp >> - src/hotspot/share/prims/cdsoffsets.cpp >> - src/hotspot/share/prims/cdsoffsets.hpp >> >> Testing with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: > > - fixed merge > - Merge branch 'master' into 8265696-move-cds-sources > - Merge branch 'master' into 8265696-move-cds-sources > - Merge branch 'master' into 8265696-move-cds-sources > - exclude all files under shared/cds if CDS is disabled; compactHashtable.cpp cannot be excluded since a bit of it is used even when CDS is disabled > - fixed include guards -> #ifndef SHARE_CDS_xxxxx > - fixed copyright > - moved more files > - fixed include lines > - 8265696: Move CDS sources from shared/memory to shared/cds Marked as reviewed by dholmes (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3610 From iklam at openjdk.java.net Fri Apr 23 03:07:02 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 23 Apr 2021 03:07:02 GMT Subject: RFR: 8265696: Move CDS sources to src/hotspot/shared/cds [v6] In-Reply-To: References: Message-ID: > The number of CDS source files have grown significantly. To improve modularity, the following files should be moved a new directory, src/hotspot/share/cds. > > - src/hotspot/share/classfile/classListParser.cpp > - src/hotspot/share/classfile/classListParser.hpp > - src/hotspot/share/classfile/classListWriter.hpp > - src/hotspot/share/classfile/compactHashtable.cpp > - src/hotspot/share/classfile/compactHashtable.hpp > - src/hotspot/share/classfile/lambdaFormInvokers.cpp > - src/hotspot/share/classfile/lambdaFormInvokers.hpp > - src/hotspot/share/memory/archiveBuilder.cpp > - src/hotspot/share/memory/archiveBuilder.hpp > - src/hotspot/share/memory/archiveUtils.cpp > - src/hotspot/share/memory/archiveUtils.hpp > - src/hotspot/share/memory/archiveUtils.inline.hpp > - src/hotspot/share/memory/cppVtables.cpp > - src/hotspot/share/memory/cppVtables.hpp > - src/hotspot/share/memory/dumpAllocStats.cpp > - src/hotspot/share/memory/dumpAllocStats.hpp > - src/hotspot/share/memory/dynamicArchive.cpp > - src/hotspot/share/memory/dynamicArchive.hpp > - src/hotspot/share/memory/filemap.cpp > - src/hotspot/share/memory/filemap.hpp > - src/hotspot/share/memory/heapShared.cpp > - src/hotspot/share/memory/heapShared.hpp > - src/hotspot/share/memory/heapShared.inline.hpp > - src/hotspot/share/memory/metaspaceShared.cpp > - src/hotspot/share/memory/metaspaceShared.hpp > - src/hotspot/share/prims/cdsoffsets.cpp > - src/hotspot/share/prims/cdsoffsets.hpp > > Testing with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: - Merge branch 'master' into 8265696-move-cds-sources - fixed merge - Merge branch 'master' into 8265696-move-cds-sources - Merge branch 'master' into 8265696-move-cds-sources - Merge branch 'master' into 8265696-move-cds-sources - exclude all files under shared/cds if CDS is disabled; compactHashtable.cpp cannot be excluded since a bit of it is used even when CDS is disabled - fixed include guards -> #ifndef SHARE_CDS_xxxxx - fixed copyright - moved more files - fixed include lines - ... and 1 more: https://git.openjdk.java.net/jdk/compare/ba1998d8...8a9e7bdf ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3610/files - new: https://git.openjdk.java.net/jdk/pull/3610/files/5ca1c512..8a9e7bdf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3610&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3610&range=04-05 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3610.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3610/head:pull/3610 PR: https://git.openjdk.java.net/jdk/pull/3610 From yyang at openjdk.java.net Fri Apr 23 03:50:54 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Fri, 23 Apr 2021 03:50:54 GMT Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex [v2] In-Reply-To: References: Message-ID: > The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version. > > In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot. > > But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later: > > 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase. > 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag > > Testing: compiler and jdk Yi Yang has updated the pull request incrementally with one additional commit since the last revision: remove java_nio_Buffer in javaClasses.hpp ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3615/files - new: https://git.openjdk.java.net/jdk/pull/3615/files/a6affc54..7f30dc48 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=00-01 Stats: 27 lines in 2 files changed: 0 ins; 27 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3615.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3615/head:pull/3615 PR: https://git.openjdk.java.net/jdk/pull/3615 From iklam at openjdk.java.net Fri Apr 23 04:16:32 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 23 Apr 2021 04:16:32 GMT Subject: Integrated: 8265696: Move CDS sources to src/hotspot/shared/cds In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 21:55:25 GMT, Ioi Lam wrote: > The number of CDS source files have grown significantly. To improve modularity, the following files should be moved a new directory, src/hotspot/share/cds. > > - src/hotspot/share/classfile/classListParser.cpp > - src/hotspot/share/classfile/classListParser.hpp > - src/hotspot/share/classfile/classListWriter.hpp > - src/hotspot/share/classfile/compactHashtable.cpp > - src/hotspot/share/classfile/compactHashtable.hpp > - src/hotspot/share/classfile/lambdaFormInvokers.cpp > - src/hotspot/share/classfile/lambdaFormInvokers.hpp > - src/hotspot/share/memory/archiveBuilder.cpp > - src/hotspot/share/memory/archiveBuilder.hpp > - src/hotspot/share/memory/archiveUtils.cpp > - src/hotspot/share/memory/archiveUtils.hpp > - src/hotspot/share/memory/archiveUtils.inline.hpp > - src/hotspot/share/memory/cppVtables.cpp > - src/hotspot/share/memory/cppVtables.hpp > - src/hotspot/share/memory/dumpAllocStats.cpp > - src/hotspot/share/memory/dumpAllocStats.hpp > - src/hotspot/share/memory/dynamicArchive.cpp > - src/hotspot/share/memory/dynamicArchive.hpp > - src/hotspot/share/memory/filemap.cpp > - src/hotspot/share/memory/filemap.hpp > - src/hotspot/share/memory/heapShared.cpp > - src/hotspot/share/memory/heapShared.hpp > - src/hotspot/share/memory/heapShared.inline.hpp > - src/hotspot/share/memory/metaspaceShared.cpp > - src/hotspot/share/memory/metaspaceShared.hpp > - src/hotspot/share/prims/cdsoffsets.cpp > - src/hotspot/share/prims/cdsoffsets.hpp > > Testing with mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero. This pull request has now been integrated. Changeset: 95f0fd6c Author: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/95f0fd6c Stats: 588 lines in 81 files changed: 254 ins; 282 del; 52 mod 8265696: Move CDS sources to src/hotspot/shared/cds Reviewed-by: erikj, dholmes, stuefe ------------- PR: https://git.openjdk.java.net/jdk/pull/3610 From iklam at openjdk.java.net Fri Apr 23 04:16:31 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 23 Apr 2021 04:16:31 GMT Subject: RFR: 8265696: Move CDS sources to src/hotspot/shared/cds [v6] In-Reply-To: <3ivrvr2C4ouw_Pv1-7TuY2Ugn5KK_-MgoGBre3ij4TY=.f6e507f9-7b17-46c5-b836-540b807cec5a@github.com> References: <3ivrvr2C4ouw_Pv1-7TuY2Ugn5KK_-MgoGBre3ij4TY=.f6e507f9-7b17-46c5-b836-540b807cec5a@github.com> Message-ID: On Thu, 22 Apr 2021 06:10:17 GMT, Thomas Stuefe wrote: >> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: >> >> - Merge branch 'master' into 8265696-move-cds-sources >> - fixed merge >> - Merge branch 'master' into 8265696-move-cds-sources >> - Merge branch 'master' into 8265696-move-cds-sources >> - Merge branch 'master' into 8265696-move-cds-sources >> - exclude all files under shared/cds if CDS is disabled; compactHashtable.cpp cannot be excluded since a bit of it is used even when CDS is disabled >> - fixed include guards -> #ifndef SHARE_CDS_xxxxx >> - fixed copyright >> - moved more files >> - fixed include lines >> - ... and 1 more: https://git.openjdk.java.net/jdk/compare/f8227451...8a9e7bdf > > Hi @iklam, > > this is a very welcome change! > > Nothing much to add to what David wrote (include guards need renaming). > > Apart from that, I was surprised that no gtests needed to be adapted, but seems cds has no gtests? > > I tested building without cds, works fine. > > Thanks for doing this! > > If you fix the include guards, this is fine by me. > > ..Thomas Thanks @tstuefe @erikj79 @dholmes-ora for the review. The latest merged code passes Mach5 build tiers 1-5. I also manually tested the minimal VM build to verify the exclusion of CDS object files. ------------- PR: https://git.openjdk.java.net/jdk/pull/3610 From sjohanss at openjdk.java.net Fri Apr 23 08:38:43 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Fri, 23 Apr 2021 08:38:43 GMT Subject: RFR: 8265268: Unify ReservedSpace reservation code in initialize and try_reserve_heap [v3] In-Reply-To: References: Message-ID: > Please review this change to unify the reservation code in ReservedSpace. > > **Summary** > The code in `ReservedSpace::initialize(...)` and `ReservedHeapSpace::try_reserve_heap(...)` is very similar and more or less does the same things. The difference between them is logging, what is considered a failure and how that is handled. > > This change introduces a new function `ReservedSpace::reserve(...)` that is used by both `initialize(...)` and `try_reserve_heap(...)`. The biggest reason for only having one function handling the reservations is to avoid code duplication and having to change two places when something needs to be updated. > > There will be some small changes in what is getting logged in some cases, but the goal is to avoid changing behavior as much as possible. > > Some additional notes to help reviewing: > * There are two reservation helpers: > `reserve_memory()` for regular pages and file backed mappings. > `reserve_memory_special()` for explicit large pages. > * In `reserve_memory()` the `is_align()`-check at the end was previously done at the end of `initialize()`. It was moved here because this is the only case where an unaligned address can be returned. For large pages as well as when a requested address is provided, the returned address will be aligned. > * The support to have a backing file is only used by the heap when `AllocateHeapAt` is set. If this option is used together with `UseLargePages` a debug message is printed since it is up to the backing file system if large pages are used or not. This output has been unified and is now printed when the file is created rather then deep in the reservation code. Previously this message differed depending on if `UseCompressedOops` was enabled or not. Now the same message is printed for both cases. > > * The failure checking function `failed_to_reserve_as_requested(...)` now only checks if the memory was allocated at the expected address. Releasing the memory is done by the caller. > > * The size passed into `map_or_reserve_memory_aligned` was previously aligned up using the alignment, but the size should always be aligned already. An assert has been added to the start of the `reserve` function and the `align_up` has been removed. > > **Testing** > A lot of local testing as well as tier1-tier5 in Mach5. Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision: Thomas indent review ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3570/files - new: https://git.openjdk.java.net/jdk/pull/3570/files/7e85384d..2c001990 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3570&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3570&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3570.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3570/head:pull/3570 PR: https://git.openjdk.java.net/jdk/pull/3570 From sjohanss at openjdk.java.net Fri Apr 23 08:38:44 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Fri, 23 Apr 2021 08:38:44 GMT Subject: RFR: 8265268: Unify ReservedSpace reservation code in initialize and try_reserve_heap [v2] In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 15:07:54 GMT, Thomas Schatzl wrote: >> Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision: >> >> Thomas and Ivan review > > src/hotspot/share/memory/virtualspace.cpp line 187: > >> 185: p2i(base), alignment); >> 186: } else { >> 187: if (large_pages_requested()) { > > Indentation. Nice catch Thomas! ------------- PR: https://git.openjdk.java.net/jdk/pull/3570 From aph at openjdk.java.net Fri Apr 23 08:53:33 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Fri, 23 Apr 2021 08:53:33 GMT Subject: RFR: 8265756: AArch64: initialize memory allocated for locals according to Windows AArch64 stack page growth requirement in template interpreter In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 15:55:40 GMT, Aleksei Voitylov wrote: > Hi, > > please review this PR which fixes several JCK test failures on Windows AArch64. On Windows AArch64, the order in which the pages are touched during stack allocation, matters. Here is a quote: "Functions that allocate 4k or more worth of stack must ensure that each page prior to the final page is touched in order" [1]. Since on Linux and Mac the order does not matter, the suggested fix reverses the order in which memory pages are touched during stack allocation for locals in template interpreter for all platforms. > > Testing: JCK, jtreg, newly developed regression test on Linux AArch64, Windows AArch64, Mac AArch64, Pre-submit tests (which includes the newly developed test). > > [1] https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-160#stack test/hotspot/jtreg/runtime/LocalVariableTable/TestLongLVTHelper.jasm line 31: > 29: > 30: public static Method tst:"()I" > 31: stack 3 locals 30000 Looks good. You might as well make locals = 65535 for a better stress test. ------------- PR: https://git.openjdk.java.net/jdk/pull/3633 From aph at openjdk.java.net Fri Apr 23 09:00:37 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Fri, 23 Apr 2021 09:00:37 GMT Subject: RFR: 8265491: Math Signum optimization for x86 [v6] In-Reply-To: References: <-Wq9ER4LeGazK0GmnIqjEhLzjGbWA_X_gYjN2Rog9zs=.dde56832-6a13-4f33-b2b2-e034fbec786f@github.com> Message-ID: <0Avbb0TUKgZg5On5mRpirby1UyAqSKc8vQYIly1J2Bo=.dd8d60ef-e328-4624-a89b-fe3e4789deda@github.com> On Wed, 21 Apr 2021 17:26:30 GMT, Marcus G K Williams wrote: >> I am referring to moving the instruction sequence into a macro assembly routine for better code sharing, one should be enough for both float and double type, please refer to following snippet for more detail. >> https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/x86/x86.ad#L5672 > > Hi @jatin-bhateja your original request was quite unclear. The highlighting of the code was incorrect and the use of 'this' made it unclear what you were suggesting and you did not explain a reason for the suggestion. > >> Can you kindly move **this** into a macro assembly routine. > > Seeing "better code sharing" as the reason it's unclear to me if the proposed refactor results in any meaningful benefit for the work involved. It's also unclear if there are any hard code structure or style issues that would necessitate the move. > > The refactor you suggest calls for the instruction sequences here to be moved into a src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp function that is then called here. Inside that function there is a selection between float and double but otherwise stays the same except one is formatted .AD and one is .CPP/.HPP. > > If I am doing this refactor for `instruct signumF_reg` and `instruct signumD_reg` to cut down on code duplication, I see that as close to a wash for saving of code lines and effort involved. I also think this would make the code more complex to read. > > However if there are strong opinions as to why this is necessary I'd be happy to hear them. I think it'd be easier to understand with a signum macro in MacroAssembler. Less code duplication is good, obviously. And it's potentially useful elsewhere. Win-win-win. We've already factored out C2 instruction sequences for things like vabsnegd into c2_MacroAssembler_x86. ------------- PR: https://git.openjdk.java.net/jdk/pull/3581 From github.com+73799211+gregcawthorne at openjdk.java.net Fri Apr 23 09:22:35 2021 From: github.com+73799211+gregcawthorne at openjdk.java.net (gregcawthorne) Date: Fri, 23 Apr 2021 09:22:35 GMT Subject: RFR: 8265768 [aarch64] Use glibc libm impl for dlog, dlog10, dexp iff 2.29 or greater on AArch64. Message-ID: Glibc 2.29 onwards provides optimised versions of log,log10,exp. These functions have an accuracy of 0.9ulp or better in glibc 2.29. Therefore this patch adds code to parse, store and check the runtime glibcs version in os_linux.cpp/hpp. This is then used to select the glibcs implementation of log, log10, exp at runtime for c1 and c2, iff we have glibc 2.29 or greater. This will ensure OpenJDK can benefit from future improvements to glibc. Glibc adheres to the ieee754 standard, unless stated otherwise in its spec. As there are no stated exceptions in the current glibc spec for dlog, dlog10 and dexp, we can assume they currently follow ieee754 (which testing confirms). As such, future version of glibc are unlikely to lose this compliance with ieee754 in future. W.r.t performance this patch sees ~15-30% performance improvements for log and log10, with ~50-80% performance improvements for exp for the common input ranged (which output real numbers). However for the NaN and inf output ranges we see a slow down of up to a factor of 2 for some functions and architectures. Due to this being the uncommon case we assert that this is a worthwhile tradeoff. ------------- Commit messages: - Use glibc libm impl for dlog,dlog10,dexp iff 2.29 or greater on AArch64. Changes: https://git.openjdk.java.net/jdk/pull/3510/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3510&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265768 Stats: 85 lines in 7 files changed: 79 ins; 5 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3510.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3510/head:pull/3510 PR: https://git.openjdk.java.net/jdk/pull/3510 From aph at openjdk.java.net Fri Apr 23 09:37:23 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Fri, 23 Apr 2021 09:37:23 GMT Subject: RFR: 8265768 [aarch64] Use glibc libm impl for dlog, dlog10, dexp iff 2.29 or greater on AArch64. In-Reply-To: References: Message-ID: On Thu, 15 Apr 2021 08:33:47 GMT, gregcawthorne wrote: > Glibc 2.29 onwards provides optimised versions of log,log10,exp. > These functions have an accuracy of 0.9ulp or better in glibc > 2.29. > > Therefore this patch adds code to parse, store and check > the runtime glibcs version in os_linux.cpp/hpp. > This is then used to select the glibcs implementation of > log, log10, exp at runtime for c1 and c2, iff we have > glibc 2.29 or greater. > > This will ensure OpenJDK can benefit from future improvements > to glibc. > > Glibc adheres to the ieee754 standard, unless stated otherwise > in its spec. > > As there are no stated exceptions in the current glibc spec > for dlog, dlog10 and dexp, we can assume they currently follow > ieee754 (which testing confirms). As such, future version of > glibc are unlikely to lose this compliance with ieee754 in > future. > > W.r.t performance this patch sees ~15-30% performance improvements for > log and log10, with ~50-80% performance improvements for exp for the > common input ranged (which output real numbers). However for the NaN > and inf output ranges we see a slow down of up to a factor of 2 for > some functions and architectures. > > Due to this being the uncommon case we assert that this is a > worthwhile tradeoff. Please provide the benchmarks. They should be in jdk/test/micro/. ------------- PR: https://git.openjdk.java.net/jdk/pull/3510 From avoitylov at openjdk.java.net Fri Apr 23 11:23:46 2021 From: avoitylov at openjdk.java.net (Aleksei Voitylov) Date: Fri, 23 Apr 2021 11:23:46 GMT Subject: RFR: 8265756: AArch64: initialize memory allocated for locals according to Windows AArch64 stack page growth requirement in template interpreter In-Reply-To: References: Message-ID: <4-NQ7nQndXAR0Ik5CuBxXvWIF0I626NJ0FsY00DtFW0=.09d08014-2981-4f5c-ada2-30ef743480d6@github.com> On Thu, 22 Apr 2021 23:26:16 GMT, David Holmes wrote: >> Hi, >> >> please review this PR which fixes several JCK test failures on Windows AArch64. On Windows AArch64, the order in which the pages are touched during stack allocation, matters. Here is a quote: "Functions that allocate 4k or more worth of stack must ensure that each page prior to the final page is touched in order" [1]. Since on Linux and Mac the order does not matter, the suggested fix reverses the order in which memory pages are touched during stack allocation for locals in template interpreter for all platforms. >> >> Testing: JCK, jtreg, newly developed regression test on Linux AArch64, Windows AArch64, Mac AArch64, Pre-submit tests (which includes the newly developed test). >> >> [1] https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-160#stack > > Can you please add comments to the new test explaining exactly what it is that the test is doing, why you need to use a jasm file etc. Also add an @bug tag to the test. > > Thanks, > David @dholmes-ora @theRealAph thanks for your comments. Please check the updated version. ------------- PR: https://git.openjdk.java.net/jdk/pull/3633 From avoitylov at openjdk.java.net Fri Apr 23 11:23:46 2021 From: avoitylov at openjdk.java.net (Aleksei Voitylov) Date: Fri, 23 Apr 2021 11:23:46 GMT Subject: RFR: 8265756: AArch64: initialize memory allocated for locals according to Windows AArch64 stack page growth requirement in template interpreter [v2] In-Reply-To: References: Message-ID: <5R3RSWrXRduyuTPfrX8p9vkeOI_6xG1Dx8aMtQEs9u0=.adebbf55-005f-4bc3-8ebc-02cca2884627@github.com> > Hi, > > please review this PR which fixes several JCK test failures on Windows AArch64. On Windows AArch64, the order in which the pages are touched during stack allocation, matters. Here is a quote: "Functions that allocate 4k or more worth of stack must ensure that each page prior to the final page is touched in order" [1]. Since on Linux and Mac the order does not matter, the suggested fix reverses the order in which memory pages are touched during stack allocation for locals in template interpreter for all platforms. > > Testing: JCK, jtreg, newly developed regression test on Linux AArch64, Windows AArch64, Mac AArch64, Pre-submit tests (which includes the newly developed test). > > [1] https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-160#stack Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision: add comments to tests and extend LVT size ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3633/files - new: https://git.openjdk.java.net/jdk/pull/3633/files/7f0bcc09..5e8c7d6a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3633&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3633&range=00-01 Stats: 14 lines in 2 files changed: 11 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3633.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3633/head:pull/3633 PR: https://git.openjdk.java.net/jdk/pull/3633 From avoitylov at openjdk.java.net Fri Apr 23 11:23:47 2021 From: avoitylov at openjdk.java.net (Aleksei Voitylov) Date: Fri, 23 Apr 2021 11:23:47 GMT Subject: RFR: 8265756: AArch64: initialize memory allocated for locals according to Windows AArch64 stack page growth requirement in template interpreter [v2] In-Reply-To: References: Message-ID: On Fri, 23 Apr 2021 08:50:26 GMT, Andrew Haley wrote: >> Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision: >> >> add comments to tests and extend LVT size > > test/hotspot/jtreg/runtime/LocalVariableTable/TestLongLVTHelper.jasm line 31: > >> 29: >> 30: public static Method tst:"()I" >> 31: stack 3 locals 30000 > > Looks good. You might as well make locals = 65535 for a better stress test. Sure, done. ------------- PR: https://git.openjdk.java.net/jdk/pull/3633 From adinn at openjdk.java.net Fri Apr 23 11:52:32 2021 From: adinn at openjdk.java.net (Andrew Dinn) Date: Fri, 23 Apr 2021 11:52:32 GMT Subject: RFR: 8265756: AArch64: initialize memory allocated for locals according to Windows AArch64 stack page growth requirement in template interpreter In-Reply-To: <4-NQ7nQndXAR0Ik5CuBxXvWIF0I626NJ0FsY00DtFW0=.09d08014-2981-4f5c-ada2-30ef743480d6@github.com> References: <4-NQ7nQndXAR0Ik5CuBxXvWIF0I626NJ0FsY00DtFW0=.09d08014-2981-4f5c-ada2-30ef743480d6@github.com> Message-ID: On Fri, 23 Apr 2021 11:20:50 GMT, Aleksei Voitylov wrote: >> Can you please add comments to the new test explaining exactly what it is that the test is doing, why you need to use a jasm file etc. Also add an @bug tag to the test. >> >> Thanks, >> David > > @dholmes-ora @theRealAph thanks for your comments. Please check the updated version. @voitylov The patch still looks good modulo one niggle I have with the comment. You use the phrase "local variable table" (twice). That jarred when I read it because it's the term used for the debug mode bytecode attribute that records names and liveness ranges for parameter & local variables found in the java source. It would avoid any potential for confusion if you used a different term, e.g. "local vars stack region". ------------- PR: https://git.openjdk.java.net/jdk/pull/3633 From sjohanss at openjdk.java.net Fri Apr 23 12:08:27 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Fri, 23 Apr 2021 12:08:27 GMT Subject: Integrated: 8265268: Unify ReservedSpace reservation code in initialize and try_reserve_heap In-Reply-To: References: Message-ID: On Mon, 19 Apr 2021 13:51:19 GMT, Stefan Johansson wrote: > Please review this change to unify the reservation code in ReservedSpace. > > **Summary** > The code in `ReservedSpace::initialize(...)` and `ReservedHeapSpace::try_reserve_heap(...)` is very similar and more or less does the same things. The difference between them is logging, what is considered a failure and how that is handled. > > This change introduces a new function `ReservedSpace::reserve(...)` that is used by both `initialize(...)` and `try_reserve_heap(...)`. The biggest reason for only having one function handling the reservations is to avoid code duplication and having to change two places when something needs to be updated. > > There will be some small changes in what is getting logged in some cases, but the goal is to avoid changing behavior as much as possible. > > Some additional notes to help reviewing: > * There are two reservation helpers: > `reserve_memory()` for regular pages and file backed mappings. > `reserve_memory_special()` for explicit large pages. > * In `reserve_memory()` the `is_align()`-check at the end was previously done at the end of `initialize()`. It was moved here because this is the only case where an unaligned address can be returned. For large pages as well as when a requested address is provided, the returned address will be aligned. > * The support to have a backing file is only used by the heap when `AllocateHeapAt` is set. If this option is used together with `UseLargePages` a debug message is printed since it is up to the backing file system if large pages are used or not. This output has been unified and is now printed when the file is created rather then deep in the reservation code. Previously this message differed depending on if `UseCompressedOops` was enabled or not. Now the same message is printed for both cases. > > * The failure checking function `failed_to_reserve_as_requested(...)` now only checks if the memory was allocated at the expected address. Releasing the memory is done by the caller. > > * The size passed into `map_or_reserve_memory_aligned` was previously aligned up using the alignment, but the size should always be aligned already. An assert has been added to the start of the `reserve` function and the `align_up` has been removed. > > **Testing** > A lot of local testing as well as tier1-tier5 in Mach5. This pull request has now been integrated. Changeset: 5db64c33 Author: Stefan Johansson URL: https://git.openjdk.java.net/jdk/commit/5db64c33 Stats: 272 lines in 2 files changed: 116 ins; 142 del; 14 mod 8265268: Unify ReservedSpace reservation code in initialize and try_reserve_heap Reviewed-by: tschatzl, iwalulya ------------- PR: https://git.openjdk.java.net/jdk/pull/3570 From sjohanss at openjdk.java.net Fri Apr 23 12:08:26 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Fri, 23 Apr 2021 12:08:26 GMT Subject: RFR: 8265268: Unify ReservedSpace reservation code in initialize and try_reserve_heap [v2] In-Reply-To: <2fgF2yLHCiC6_j7xEhTJrSyhZOaci500jRu6EUpvt9c=.992ae106-89a9-4d34-a90b-a86f69b6313a@github.com> References: <2fgF2yLHCiC6_j7xEhTJrSyhZOaci500jRu6EUpvt9c=.992ae106-89a9-4d34-a90b-a86f69b6313a@github.com> Message-ID: On Thu, 22 Apr 2021 16:00:39 GMT, Ivan Walulya wrote: >> Stefan Johansson has updated the pull request incrementally with one additional commit since the last revision: >> >> Thomas and Ivan review > > Marked as reviewed by iwalulya (Committer). Thanks @walulyai and @tschatzl for reviewing. ------------- PR: https://git.openjdk.java.net/jdk/pull/3570 From chagedorn at openjdk.java.net Fri Apr 23 12:39:32 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Fri, 23 Apr 2021 12:39:32 GMT Subject: RFR: 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests [v6] In-Reply-To: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> Message-ID: > This RFE provides an IR test framework to perform regex-based checks on the C2 IR shape of test methods emitted by the VM flags `-XX:+PrintIdeal` and `-XX:+PrintOptoAssembly`. The framework can also be used for other non-IR matching (and non-compiler) tests by providing easy to use annotations for commonly used testing patterns and compiler control flags. > > The framework is based on the ideas of the currently present IR test framework in [Valhalla](https://github.com/openjdk/valhalla/blob/e9c78ce4fcfd01361c35883e0d68f9ae5a80d079/test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypeTest.java) (mainly implemented by @TobiHartmann) which is being used with great success. This new framework aims to replace the old one in Valhalla at some point. > > A detailed description about how this new IR test framework works and how it is used is provided in the [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) file and in the [Javadocs](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc/jdk/test/lib/hotspot/ir_framework/package-summary.html) written for the framework classes. > > To finish a first version of this framework for JDK 17, I decided to leave some improvement possibilities and ideas to be followed up on in additional RFEs. Some ideas are mentioned in "Future Work" in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) and were also created as subtasks of this RFE. > > Testing (also described in "Internal Framework Tests in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md)): > There are various tests to verify the correctness of the test framework which can be found as JTreg tests in the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) folder. Additional testing was performed by converting all compiler Inline Types test of project Valhalla (done by @katyapav in [JDK-8263024](https://bugs.openjdk.java.net/browse/JDK-8263024)) that used the old framework to the new framework. This provided additional testing for the framework itself. We ran the converted tests with all the flag settings used in hs-tier1-9 and hs-precheckin-comp. For sanity checking, this was also done with a sample IR test in mainline. > > Some stats about the framework code added to [ir_framework](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework): > > - without the [Javadocs files](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc) : 60 changed files, 13212 insertions, 0 deletions. > - without the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) and [examples](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/examples) folder: 40 files changed, 6781 insertions > - comments: 2399 insertions (calculated with `git diff --cached !(tests|examples) | grep -c -E "(^[+-]\s*(/)?*)|(^[+-]\s*//)"`) > - which leaves 4382 lines of code inserted > > Big thanks to: > - @TobiHartmann for all his help by discussing the new framework and for providing insights from his IR test framework in Valhalla. > - @katyapav for converting the Valhalla tests to use the new framework which found some harder to catch bugs in the framework and also some actual C2 bugs. > - @iignatev for helping to simplify the framework usage with JTreg and with the framework internal VM calling structure. > - and others who provided valuable feedback. > > Thanks, > Christian Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: Review comments by Tobias: Formatting fields, spacing, README.md typos and cleanup ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3508/files - new: https://git.openjdk.java.net/jdk/pull/3508/files/72eece63..0720a330 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3508&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3508&range=04-05 Stats: 59 lines in 21 files changed: 6 ins; 34 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/3508.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3508/head:pull/3508 PR: https://git.openjdk.java.net/jdk/pull/3508 From chagedorn at openjdk.java.net Fri Apr 23 12:39:33 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Fri, 23 Apr 2021 12:39:33 GMT Subject: RFR: 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests [v5] In-Reply-To: References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> Message-ID: On Thu, 22 Apr 2021 13:30:17 GMT, Tobias Hartmann wrote: > Great work, Christian! I'm glad we finally have the capability to write regression tests with IR verification. > > Hard to review this in detail but I've added some comments. In any case, conversion of Valhalla tests to the new framework has proven that this is good to go. We can still fix problems and add new features once this is in. Thank you Tobias for your review! I pushed an update with your review comments. I agree that we can still follow up with fixes and new features once this went it. > test/lib/jdk/test/lib/hotspot/ir_framework/Check.java line 94: > >> 92: @Retention(RetentionPolicy.RUNTIME) >> 93: public @interface Check { >> 94: > > Some classes/interfaces have a newline at the beginning and others don't. I think they can be removed. Cleaned that up together with some other formatting. > test/lib/jdk/test/lib/hotspot/ir_framework/README.md line 128: > >> 126: This framework is based on the idea of the currently present IR test framework in [Valhalla](https://github.com/openjdk/valhalla/blob/e9c78ce4fcfd01361c35883e0d68f9ae5a80d079/test/hotspot/jtreg/runtime/valhalla/inlinetypes/InlineTypesTest.java). This IR framework was used with great success in Valhalla and thus served as a foundation for this new IR framework. >> 127: >> 128: The new framework supports all the features that are present in the Valhalla IR framework with the idea to replace it at some point. The initial design and feature set was kept simple and straight forward and serves well for small to medium sized tests. There are a lot of possibilities to further enhance the framework and make it more powerful. This can be tackled in additional RFEs. A few ideas include: > > Again, I would remove the reference to the Valhalla framework. Looking through the changes, I see 13 references to "Valhalla", I think these should all be removed. I removed all references except the ones in the testing section about the converted tests. I think these references are important to keep for now. ------------- PR: https://git.openjdk.java.net/jdk/pull/3508 From aph at openjdk.java.net Fri Apr 23 15:01:28 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Fri, 23 Apr 2021 15:01:28 GMT Subject: RFR: 8265756: AArch64: initialize memory allocated for locals according to Windows AArch64 stack page growth requirement in template interpreter [v2] In-Reply-To: <5R3RSWrXRduyuTPfrX8p9vkeOI_6xG1Dx8aMtQEs9u0=.adebbf55-005f-4bc3-8ebc-02cca2884627@github.com> References: <5R3RSWrXRduyuTPfrX8p9vkeOI_6xG1Dx8aMtQEs9u0=.adebbf55-005f-4bc3-8ebc-02cca2884627@github.com> Message-ID: On Fri, 23 Apr 2021 11:23:46 GMT, Aleksei Voitylov wrote: >> Hi, >> >> please review this PR which fixes several JCK test failures on Windows AArch64. On Windows AArch64, the order in which the pages are touched during stack allocation, matters. Here is a quote: "Functions that allocate 4k or more worth of stack must ensure that each page prior to the final page is touched in order" [1]. Since on Linux and Mac the order does not matter, the suggested fix reverses the order in which memory pages are touched during stack allocation for locals in template interpreter for all platforms. >> >> Testing: JCK, jtreg, newly developed regression test on Linux AArch64, Windows AArch64, Mac AArch64, Pre-submit tests (which includes the newly developed test). >> >> [1] https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-160#stack > > Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision: > > add comments to tests and extend LVT size Marked as reviewed by aph (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3633 From github.com+168222+mgkwill at openjdk.java.net Fri Apr 23 17:24:54 2021 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Fri, 23 Apr 2021 17:24:54 GMT Subject: RFR: 8265491: Math Signum optimization for x86 [v7] In-Reply-To: <0Avbb0TUKgZg5On5mRpirby1UyAqSKc8vQYIly1J2Bo=.dd8d60ef-e328-4624-a89b-fe3e4789deda@github.com> References: <-Wq9ER4LeGazK0GmnIqjEhLzjGbWA_X_gYjN2Rog9zs=.dde56832-6a13-4f33-b2b2-e034fbec786f@github.com> <0Avbb0TUKgZg5On5mRpirby1UyAqSKc8vQYIly1J2Bo=.dd8d60ef-e328-4624-a89b-fe3e4789deda@github.com> Message-ID: On Fri, 23 Apr 2021 08:57:48 GMT, Andrew Haley wrote: >> Hi @jatin-bhateja your original request was quite unclear. The highlighting of the code was incorrect and the use of 'this' made it unclear what you were suggesting and you did not explain a reason for the suggestion. >> >>> Can you kindly move **this** into a macro assembly routine. >> >> Seeing "better code sharing" as the reason it's unclear to me if the proposed refactor results in any meaningful benefit for the work involved. It's also unclear if there are any hard code structure or style issues that would necessitate the move. >> >> The refactor you suggest calls for the instruction sequences here to be moved into a src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp function that is then called here. Inside that function there is a selection between float and double but otherwise stays the same except one is formatted .AD and one is .CPP/.HPP. >> >> If I am doing this refactor for `instruct signumF_reg` and `instruct signumD_reg` to cut down on code duplication, I see that as close to a wash for saving of code lines and effort involved. I also think this would make the code more complex to read. >> >> However if there are strong opinions as to why this is necessary I'd be happy to hear them. > > I think it'd be easier to understand with a signum macro in MacroAssembler. Less code duplication is good, obviously. And it's potentially useful elsewhere. Win-win-win. > We've already factored out C2 instruction sequences for things like vabsnegd into c2_MacroAssembler_x86. I wave the white flag. Thanks for the review and suggestions @theRealAph and @jatin-bhateja. In an effort to eradicate the 5 lines of duplication and with an eye to potential usefulness in the future I've created a twice called `C2_MacroAssembler::signum_fp` using 36 lines of code and modification of c2_MacroAssembler_x86.cpp c2_MacroAssembler_x86.hpp. ------------- PR: https://git.openjdk.java.net/jdk/pull/3581 From github.com+168222+mgkwill at openjdk.java.net Fri Apr 23 17:24:54 2021 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Fri, 23 Apr 2021 17:24:54 GMT Subject: RFR: 8265491: Math Signum optimization for x86 [v6] In-Reply-To: References: <-OoR0roTaaBaxayn8kBzM1YVMHgicNGxa6hcVRnH1oE=.485b7b08-e12b-49e0-9ca7-cfef150e588b@github.com> Message-ID: On Thu, 22 Apr 2021 23:53:12 GMT, Jie Fu wrote: > Looks good to me. > Thanks for your update. > > Please make sure the copyright year has been updated (TestSignumIntrinsic.java?) and all the imports are actually needed (import org.openjdk.jmh.annotations.Setup; ?). Thanks @DamonFool. Updated with your suggestions. ------------- PR: https://git.openjdk.java.net/jdk/pull/3581 From github.com+168222+mgkwill at openjdk.java.net Fri Apr 23 17:24:53 2021 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Fri, 23 Apr 2021 17:24:53 GMT Subject: RFR: 8265491: Math Signum optimization for x86 [v7] In-Reply-To: References: Message-ID: <-R3W5TtT5d8dyhcrKvkAUSndQshrVZTHN0VxpIJZoow=.6024f8a6-9fbd-4cc9-9381-8ea54a931bf9@github.com> > x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM. > > We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization. > > Base: > > Benchmark Mode Cnt Score Error Units > Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op > Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op > Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op > Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op > > > Optimized: > signum intrinsic patch > > Benchmark Mode Cnt Score Error Units > Signum._1_signumFloatTest avgt 5 3.769 ? 0.015 ns/op > Signum._2_overheadFloat avgt 5 3.312 ? 0.025 ns/op > Signum._3_signumDoubleTest avgt 5 3.765 ? 0.005 ns/op > Signum._4_overheadDouble avgt 5 3.309 ? 0.010 ns/op > > > Signed-off-by: Marcus G K Williams Marcus G K Williams has updated the pull request incrementally with two additional commits since the last revision: - Update DamonFool Signed-off-by: Marcus G K Williams - Refactor on suggestion of jatin-bhateja & theRealAph Signed-off-by: Marcus G K Williams ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3581/files - new: https://git.openjdk.java.net/jdk/pull/3581/files/afefdc28..3e0a4c79 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3581&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3581&range=05-06 Stats: 60 lines in 5 files changed: 40 ins; 15 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/3581.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3581/head:pull/3581 PR: https://git.openjdk.java.net/jdk/pull/3581 From iklam at openjdk.java.net Fri Apr 23 21:23:31 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 23 Apr 2021 21:23:31 GMT Subject: RFR: 8265393: VM crashes if both -XX:+RecordDynamicDumpInfo and -XX:SharedArchiveFile options are specified [v3] In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 18:44:54 GMT, Yumin Qi wrote: >> Hi, Please review >> 1) When the two flags -XX:+RecordDynamicDumpInfo and -XX:SharedArchiveFile used, in >> Arguments::init_shared_archive_paths() : >> if (DynamicDumpSharedSpaces) { >> if (os::same_files(SharedArchiveFile, ArchiveClassesAtExit)) { >> ... >> ArchiveClassesAtExit is NULL. >> C++ does not have a defined behavior of strcmp with strings of NULL. Posix version of os::same_files(const char* file1, const char* file2) calls strcmp without checking input args. This should be same as it is treated on Windows. >> 2) JCmdTest.java is fat and possible to cause test timeout. Split JCmdTest.java into two separate Tests: JCmdTestStaticDump.java and JCmdTestDynamicDump.java. >> 3) Add a test to check run with -XX:+RecordDynamicDumpInfo and -XX:SharedArchiveFile in JCmdTestDynamicDump.java >> The test does not use utility to create jvm process since it will take testing envs into process, but the way in the test using LingeredApp does not take envs. >> >> Tests: tier1,tier2,tier3,tier4 >> >> Thanks >> Yumin > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Remove extra imports, fix nits to review comments The latest code looks good to me. ------------- Marked as reviewed by iklam (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3599 From minqi at openjdk.java.net Fri Apr 23 21:37:25 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 23 Apr 2021 21:37:25 GMT Subject: RFR: 8265393: VM crashes if both -XX:+RecordDynamicDumpInfo and -XX:SharedArchiveFile options are specified [v3] In-Reply-To: References: Message-ID: On Fri, 23 Apr 2021 21:20:03 GMT, Ioi Lam wrote: >> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove extra imports, fix nits to review comments > > The latest code looks good to me. @iklam Thanks for review. ------------- PR: https://git.openjdk.java.net/jdk/pull/3599 From minqi at openjdk.java.net Fri Apr 23 21:55:25 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 23 Apr 2021 21:55:25 GMT Subject: Integrated: 8265393: VM crashes if both -XX:+RecordDynamicDumpInfo and -XX:SharedArchiveFile options are specified In-Reply-To: References: Message-ID: <3kVN_-oHIBVlXwYldnd4YBeUsfEoDQ4tiBJuFLIu1es=.6bd847c8-dc42-4e73-87f7-fe281e01eb49@github.com> On Wed, 21 Apr 2021 04:38:14 GMT, Yumin Qi wrote: > Hi, Please review > 1) When the two flags -XX:+RecordDynamicDumpInfo and -XX:SharedArchiveFile used, in > Arguments::init_shared_archive_paths() : > if (DynamicDumpSharedSpaces) { > if (os::same_files(SharedArchiveFile, ArchiveClassesAtExit)) { > ... > ArchiveClassesAtExit is NULL. > C++ does not have a defined behavior of strcmp with strings of NULL. Posix version of os::same_files(const char* file1, const char* file2) calls strcmp without checking input args. This should be same as it is treated on Windows. > 2) JCmdTest.java is fat and possible to cause test timeout. Split JCmdTest.java into two separate Tests: JCmdTestStaticDump.java and JCmdTestDynamicDump.java. > 3) Add a test to check run with -XX:+RecordDynamicDumpInfo and -XX:SharedArchiveFile in JCmdTestDynamicDump.java > The test does not use utility to create jvm process since it will take testing envs into process, but the way in the test using LingeredApp does not take envs. > > Tests: tier1,tier2,tier3,tier4 > > Thanks > Yumin This pull request has now been integrated. Changeset: 20a373a0 Author: Yumin Qi URL: https://git.openjdk.java.net/jdk/commit/20a373a0 Stats: 868 lines in 6 files changed: 505 ins; 362 del; 1 mod 8265393: VM crashes if both -XX:+RecordDynamicDumpInfo and -XX:SharedArchiveFile options are specified Reviewed-by: iklam, ccheung ------------- PR: https://git.openjdk.java.net/jdk/pull/3599 From xliu at openjdk.java.net Fri Apr 23 22:03:33 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Fri, 23 Apr 2021 22:03:33 GMT Subject: RFR: 8229517: Support for optional asynchronous/buffered logging [v8] In-Reply-To: References: Message-ID: On Thu, 25 Mar 2021 19:30:25 GMT, Volker Simonis wrote: >> Xin Liu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 18 additional commits since the last revision: >> >> - Refactor LogAsyncFlusher::abort() >> >> This change makes sure LogAsyncFlusher::abort() is lock-less. >> Therefore, it's not subject to mutex rank issue. Newly added >> gtest(mutex_lock_access_leaf) may deliberately trigger SIGSEGV >> while holding access rank mutex, so abort() must be lockless. >> - Merge branch 'master' into JDK-8229517 >> - Fix a race condition bug on LogAsyncFlusher termination. >> >> I saw intermitent crashes of java with the following arguments. >> -Xlog:'all=trace:file=hotspot-x.log:level,tags:filecount=0,async=true' --version >> >> The root cause is that there is a race condition between main thread _exit and >> LogAsyncFlusher::run. This patch added a synchronization using >> Terminator_lock in LogAsyncFlusher::terminate. This guranatees that no >> log entry will emit when main thread is exiting. >> - Resolve rank conflict between tty_lock and LogAsyncFlusher's _lock. >> >> LogAsyncFlusher::_lock ranks Mutex::tty on purpose, which is same as tty_lock. >> Ideally, they are orthogonal. In reality, it's possible that a thread emits logs >> to a log file while (mistakenly) holding tty_lock. ttyUnlocker is placed in enqueue >> member functions to resolve conflicts betwen them. >> >> This patch fixed the jtreg test: runtime/logging/RedefineClasses.java and the >> full brunt logging -Xlog:'all:file=hotspot.log::async=true' >> - Remove LogAsyncInterval completely >> >> It was used as a timeout parameter of the monitor. Now the monitor is waked up >> when the occupancy of asynclog buffer is more 3/4. >> - Support Jcmd pid VM.log disable >> >> This patch also supports to add a new output dynamically. If >> output_option specifies async=true, the new output will use >> asynchronous writing. >> >> Currently jcmd VM.log prohibts users from changing established >> output_options in runtime. users can disable them all and then >> recreate them with the new output_options. >> - Fix build issue with `--disable-precompiled-headers` >> - Inject the number of dropped messages since last dumpping. >> >> Each LogOutput has an independent counter. The out-of-band message >> "[number] messages dropped..." will be dumped into its corresponding >> LogOutput. >> - Revert "fix runtime/logging/RedefineClasses.java crashed with -XX:+AsyncLogging" >> >> This reverts commit 81b2a0cb2a6cf57b1cd0baacdf8c0419f14819b4. >> >> This problem is sidetracked by JDK-8265102. >> - fix runtime/logging/RedefineClasses.java crashed with -XX:+AsyncLogging >> >> nmethod::print(outputStream* st) should not obtain tty_lock by assuming >> st is defaultStream. It could be logStream as well. >> >> Currently, AyncLogFlusher::_lock has the same rank of tty_lock. >> https://issues.amazon.com/issues/JVM-563 >> - ... and 8 more: https://git.openjdk.java.net/jdk/compare/0feed460...4cf4a57f > > src/hotspot/share/logging/logAsyncFlusher.hpp line 34: > >> 32: >> 33: template >> 34: class LinkedListDeque : private LinkedListImpl { > > The name `LinkedListDeque` implies that this is a general purpose Deque implementation which is not true. It's fine to have an implementation for your very specific needs (otherwise it should probably be in its own file under `share/utilities/dequeue.hpp`). But to make this explicitly clear to the reader, can you please rename it to something like `AsyncFlusherDeque` and specify it's semantics in a comment on top of the class. E.g this class doesn't support the usage of the inherited `add()` method because that would break the `size()` functionality. I have changed the class declaration to `template class LinkedListDeque ` Per your request, I have moved all logging logics out of it, so it can be used as a generic LinkedListDeque. I think it's fair enough to keep its name. In logging logics, I use a typedef version here: `typedef LinkedListDeque AsyncLogBuffer;` ------------- PR: https://git.openjdk.java.net/jdk/pull/3135 From xliu at openjdk.java.net Fri Apr 23 22:11:33 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Fri, 23 Apr 2021 22:11:33 GMT Subject: RFR: 8229517: Support for optional asynchronous/buffered logging [v8] In-Reply-To: References: Message-ID: On Fri, 26 Mar 2021 09:52:25 GMT, Volker Simonis wrote: >> Xin Liu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 18 additional commits since the last revision: >> >> - Refactor LogAsyncFlusher::abort() >> >> This change makes sure LogAsyncFlusher::abort() is lock-less. >> Therefore, it's not subject to mutex rank issue. Newly added >> gtest(mutex_lock_access_leaf) may deliberately trigger SIGSEGV >> while holding access rank mutex, so abort() must be lockless. >> - Merge branch 'master' into JDK-8229517 >> - Fix a race condition bug on LogAsyncFlusher termination. >> >> I saw intermitent crashes of java with the following arguments. >> -Xlog:'all=trace:file=hotspot-x.log:level,tags:filecount=0,async=true' --version >> >> The root cause is that there is a race condition between main thread _exit and >> LogAsyncFlusher::run. This patch added a synchronization using >> Terminator_lock in LogAsyncFlusher::terminate. This guranatees that no >> log entry will emit when main thread is exiting. >> - Resolve rank conflict between tty_lock and LogAsyncFlusher's _lock. >> >> LogAsyncFlusher::_lock ranks Mutex::tty on purpose, which is same as tty_lock. >> Ideally, they are orthogonal. In reality, it's possible that a thread emits logs >> to a log file while (mistakenly) holding tty_lock. ttyUnlocker is placed in enqueue >> member functions to resolve conflicts betwen them. >> >> This patch fixed the jtreg test: runtime/logging/RedefineClasses.java and the >> full brunt logging -Xlog:'all:file=hotspot.log::async=true' >> - Remove LogAsyncInterval completely >> >> It was used as a timeout parameter of the monitor. Now the monitor is waked up >> when the occupancy of asynclog buffer is more 3/4. >> - Support Jcmd pid VM.log disable >> >> This patch also supports to add a new output dynamically. If >> output_option specifies async=true, the new output will use >> asynchronous writing. >> >> Currently jcmd VM.log prohibts users from changing established >> output_options in runtime. users can disable them all and then >> recreate them with the new output_options. >> - Fix build issue with `--disable-precompiled-headers` >> - Inject the number of dropped messages since last dumpping. >> >> Each LogOutput has an independent counter. The out-of-band message >> "[number] messages dropped..." will be dumped into its corresponding >> LogOutput. >> - Revert "fix runtime/logging/RedefineClasses.java crashed with -XX:+AsyncLogging" >> >> This reverts commit 81b2a0cb2a6cf57b1cd0baacdf8c0419f14819b4. >> >> This problem is sidetracked by JDK-8265102. >> - fix runtime/logging/RedefineClasses.java crashed with -XX:+AsyncLogging >> >> nmethod::print(outputStream* st) should not obtain tty_lock by assuming >> st is defaultStream. It could be logStream as well. >> >> Currently, AyncLogFlusher::_lock has the same rank of tty_lock. >> https://issues.amazon.com/issues/JVM-563 >> - ... and 8 more: https://git.openjdk.java.net/jdk/compare/1938a54a...4cf4a57f > > src/hotspot/share/logging/logAsyncFlusher.hpp line 111: > >> 109: o._message = NULL; // transfer the ownership of _message to this >> 110: } >> 111: > > Maybe add an explicit copy assignment operator with a `ShouldNotReachHere` to make sure `AsyncLogMessages` are not assigned unintentionally. I do use copy constructor here. The container ` typedef LinkedListDeque AsyncLogBuffer;` stores objects instead of raw pointers on purpose. I create objects and push it to the container in equeue(). It's always easier to manage memory with copying byval. There's no smart_pointer in hotspot, I had to explicitly manage memory if I would store raw pointers. That makes code error-prone and messy. ------------- PR: https://git.openjdk.java.net/jdk/pull/3135 From xliu at openjdk.java.net Fri Apr 23 22:17:33 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Fri, 23 Apr 2021 22:17:33 GMT Subject: RFR: 8229517: Support for optional asynchronous/buffered logging [v8] In-Reply-To: References: Message-ID: On Thu, 25 Mar 2021 21:19:05 GMT, Volker Simonis wrote: >> Xin Liu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 18 additional commits since the last revision: >> >> - Refactor LogAsyncFlusher::abort() >> >> This change makes sure LogAsyncFlusher::abort() is lock-less. >> Therefore, it's not subject to mutex rank issue. Newly added >> gtest(mutex_lock_access_leaf) may deliberately trigger SIGSEGV >> while holding access rank mutex, so abort() must be lockless. >> - Merge branch 'master' into JDK-8229517 >> - Fix a race condition bug on LogAsyncFlusher termination. >> >> I saw intermitent crashes of java with the following arguments. >> -Xlog:'all=trace:file=hotspot-x.log:level,tags:filecount=0,async=true' --version >> >> The root cause is that there is a race condition between main thread _exit and >> LogAsyncFlusher::run. This patch added a synchronization using >> Terminator_lock in LogAsyncFlusher::terminate. This guranatees that no >> log entry will emit when main thread is exiting. >> - Resolve rank conflict between tty_lock and LogAsyncFlusher's _lock. >> >> LogAsyncFlusher::_lock ranks Mutex::tty on purpose, which is same as tty_lock. >> Ideally, they are orthogonal. In reality, it's possible that a thread emits logs >> to a log file while (mistakenly) holding tty_lock. ttyUnlocker is placed in enqueue >> member functions to resolve conflicts betwen them. >> >> This patch fixed the jtreg test: runtime/logging/RedefineClasses.java and the >> full brunt logging -Xlog:'all:file=hotspot.log::async=true' >> - Remove LogAsyncInterval completely >> >> It was used as a timeout parameter of the monitor. Now the monitor is waked up >> when the occupancy of asynclog buffer is more 3/4. >> - Support Jcmd pid VM.log disable >> >> This patch also supports to add a new output dynamically. If >> output_option specifies async=true, the new output will use >> asynchronous writing. >> >> Currently jcmd VM.log prohibts users from changing established >> output_options in runtime. users can disable them all and then >> recreate them with the new output_options. >> - Fix build issue with `--disable-precompiled-headers` >> - Inject the number of dropped messages since last dumpping. >> >> Each LogOutput has an independent counter. The out-of-band message >> "[number] messages dropped..." will be dumped into its corresponding >> LogOutput. >> - Revert "fix runtime/logging/RedefineClasses.java crashed with -XX:+AsyncLogging" >> >> This reverts commit 81b2a0cb2a6cf57b1cd0baacdf8c0419f14819b4. >> >> This problem is sidetracked by JDK-8265102. >> - fix runtime/logging/RedefineClasses.java crashed with -XX:+AsyncLogging >> >> nmethod::print(outputStream* st) should not obtain tty_lock by assuming >> st is defaultStream. It could be logStream as well. >> >> Currently, AyncLogFlusher::_lock has the same rank of tty_lock. >> https://issues.amazon.com/issues/JVM-563 >> - ... and 8 more: https://git.openjdk.java.net/jdk/compare/1c42ea7a...4cf4a57f > > src/hotspot/share/logging/logAsyncFlusher.hpp line 96: > >> 94: _level(decorations.get_level()), _tagset(decorations.get_logTagSet()) { >> 95: // allow to fail here, then _message is NULL >> 96: _message = os::strdup(msg, mtLogging); > > If you think `msg` can't be NULL here please add an assertion, otherwise please handle it. I deliberately design this code snippet tolerate error. `os::strdup` uses malloc. The default behavior is returning NULL when it fails. it's fine that _message is NULL. the payload is "null" and nothing will be emitted eventually. If I handle error(lacking memory) here, the it may then recursively generates more logs. ------------- PR: https://git.openjdk.java.net/jdk/pull/3135 From github.com+168222+mgkwill at openjdk.java.net Fri Apr 23 22:24:38 2021 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Fri, 23 Apr 2021 22:24:38 GMT Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux [v29] In-Reply-To: References: Message-ID: > Change the meaning of LargePageSizeInBytes to be the maximum large page size the JVM may use (not the only one). A default value of zero will mean to allow the JVM use large page sizes up to the system's default large page size. Marcus G K Williams has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 48 commits: - Set LargePageSizeInBytes to largepage upper limit Signed-off-by: Marcus G K Williams - Merge branch 'master' into update_hlp - Fix merge Signed-off-by: Marcus G K Williams - Merge branch 'master' into update_hlp - Merge branch 'master' into update_hlp - Rebase on pull/3073 Signed-off-by: Marcus G K Williams - Merge branch 'pull/3073' into update_hlp - Thomas review. Changed commit_memory_special to return bool to signal if the request succeeded or not. - Self review. Update helper name to better match commit_memory_special(). - Marcus review. Updated comments. - ... and 38 more: https://git.openjdk.java.net/jdk/compare/5aab1609...6f063309 ------------- Changes: https://git.openjdk.java.net/jdk/pull/1153/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1153&range=28 Stats: 138 lines in 3 files changed: 68 ins; 47 del; 23 mod Patch: https://git.openjdk.java.net/jdk/pull/1153.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1153/head:pull/1153 PR: https://git.openjdk.java.net/jdk/pull/1153 From github.com+168222+mgkwill at openjdk.java.net Fri Apr 23 22:39:27 2021 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Fri, 23 Apr 2021 22:39:27 GMT Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux [v27] In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 18:00:52 GMT, Marcus G K Williams wrote: > an easy approach should be to just remove all large page sizes larger than the decided maximum from _page_sizes. It seemed easier to forgo adding large page sizes if they were less than `LargePageSizeInBytes` and `LargePageSizeInBytes != 0` or default. Please let me know if the solution seems appropriate. > The warning should go away since it is documented to mean use the default. Done. Feedback there would also be helpful. I'm seeing one failure with the TestTracePageSizes test that I'm yet to figure out. On a run with `run main/othervm -XX:+AlwaysPreTouch -Xlog:pagesize:ps-%p.log -XX:+UseSerialGC -XX:+UseTransparentHugePages TestTracePageSizes` ============================== Test summary ============================== TEST TOTAL PASS FAIL ERROR jtreg:test/hotspot/jtreg/runtime/os/TestTracePageSizes.java >> 6 5 1 0 << ============================== TEST FAILURE ... --- >From logfile: [0.004s][info][pagesize] Heap: min=8M max=15452M base=0x000000043a400000 page_size=2M size=15452M From smaps: [43a400000, 440000000) pageSize=4KB isTHP=false isHUGETLB=false Failure: 4 != 2048 STDERR: java.lang.AssertionError: Page sizes mismatch: 4 != 2048 at TestTracePageSizes.main(TestTracePageSizes.java:202) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:568) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.base/java.lang.Thread.run(Thread.java:831) JavaTest Message: Test threw exception: java.lang.AssertionError: Page sizes mismatch: 4 != 2048 JavaTest Message: shutting down test ... reason: User specified action: run main/othervm -XX:+AlwaysPreTouch -Xlog:pagesize:ps-%p.log -XX:+UseSerialGC -XX:+UseTransparentHugePages TestTracePageSizes Mode: othervm [/othervm specified] elapsed time (seconds): 0.803 configuration: STDOUT: Added range: [43a400000, 440000000) pageSize=4KB isTHP=false isHUGETLB=false Added range: [440000000, 480000000) pageSize=4KB isTHP=true isHUGETLB=false Added range: [480000000, 57c2a0000) pageSize=4KB isTHP=false isHUGETLB=false Two guesses so far: It seems like a possible issue with `ReservedSpace::actual_reserved_page_size` returning the wrong page size. Or could this base page address be 4k padding for THP largepage? ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From xliu at openjdk.java.net Fri Apr 23 22:42:24 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Fri, 23 Apr 2021 22:42:24 GMT Subject: RFR: 8229517: Support for optional asynchronous/buffered logging [v8] In-Reply-To: References: Message-ID: On Tue, 30 Mar 2021 06:57:16 GMT, Xin Liu wrote: >> src/hotspot/share/logging/logAsyncFlusher.hpp line 116: >> >>> 114: bool equals(const AsyncLogMessage& o) const { >>> 115: return (&_output == &o._output) && (_message == o._message || !strcmp(_message, o._message)); >>> 116: } >> >> [`strcmp()` is not defined for `NULL`](https://en.cppreference.com/w/cpp/string/byte/strcmp) but you can have `_message == NULL` if you've transferred ownership in the copy constructor. > > yes, this is subtle bug! thanks! > I thought that if _message is NULL, then o._message must be NULL, then it will be true for _message == o._message. I was wrong. fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/3135 From xliu at openjdk.java.net Fri Apr 23 23:29:48 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Fri, 23 Apr 2021 23:29:48 GMT Subject: RFR: 8229517: Support for optional asynchronous/buffered logging [v9] In-Reply-To: References: Message-ID: > This patch provides a buffer to store asynchrounous messages and flush them to > underlying files periodically. Xin Liu has updated the pull request incrementally with two additional commits since the last revision: - Fix bugs/style/typo based on reviewers' feedbacks. - Accurate Decorations for AsyncLogging. A lightweight LogDecorationRef is created to keep LogDecorations at logging site. It uses refcnt to keep track multiple usage and automatically clean up. If no decorator is in use, no LogDecorationRef is created. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3135/files - new: https://git.openjdk.java.net/jdk/pull/3135/files/4cf4a57f..e2d6f9e0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3135&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3135&range=07-08 Stats: 207 lines in 12 files changed: 152 ins; 21 del; 34 mod Patch: https://git.openjdk.java.net/jdk/pull/3135.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3135/head:pull/3135 PR: https://git.openjdk.java.net/jdk/pull/3135 From xliu at openjdk.java.net Fri Apr 23 23:29:49 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Fri, 23 Apr 2021 23:29:49 GMT Subject: RFR: 8229517: Support for optional asynchronous/buffered logging [v9] In-Reply-To: References: Message-ID: On Thu, 25 Mar 2021 20:19:19 GMT, Volker Simonis wrote: >> Xin Liu has updated the pull request incrementally with two additional commits since the last revision: >> >> - Fix bugs/style/typo based on reviewers' feedbacks. >> - Accurate Decorations for AsyncLogging. >> >> A lightweight LogDecorationRef is created to keep LogDecorations at >> logging site. It uses refcnt to keep track multiple usage and >> automatically clean up. If no decorator is in use, no LogDecorationRef >> is created. > > src/hotspot/share/logging/logConfiguration.cpp line 544: > >> 542: " If set to 0, log rotation is disabled." >> 543: " This will cause existing log files to be overwritten."); >> 544: out->print_cr(" async=true|false - write asynchronously or not."); > > Mention the default here which should be "false". fixed. > src/hotspot/share/logging/logDecorators.hpp line 89: > >> 87: } >> 88: >> 89: LogDecorators(const LogDecorators& o) : _decorators(o._decorators) { > > Why do you need this new copy constructor? I have removed it. > src/hotspot/share/logging/logDecorators.hpp line 92: > >> 90: } >> 91: >> 92: LogDecorators& operator=(const LogDecorators& rhs) { > > Why do you need this new assignment operator? removed ------------- PR: https://git.openjdk.java.net/jdk/pull/3135 From xliu at openjdk.java.net Fri Apr 23 23:29:50 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Fri, 23 Apr 2021 23:29:50 GMT Subject: RFR: 8229517: Support for optional asynchronous/buffered logging [v9] In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 08:34:04 GMT, Xin Liu wrote: >> src/hotspot/share/logging/logFileOutput.cpp line 50: >> >>> 48: : LogFileStreamOutput(NULL), _name(os::strdup_check_oom(name, mtLogging)), >>> 49: _file_name(NULL), _archive_name(NULL), _current_file(0), >>> 50: _file_count(DefaultFileCount), _is_default_file_count(true), _async_mode(AsyncLogging), _archive_name_len(0), >> >> See comments on `globals.hpp`. No need for an extra option. Make this `false` by default. >> >> And can you please also add the `_async_mode` to the following log trace in `LogFileOutput::initialize()`: >> >> log_trace(logging)("Initializing logging to file '%s' (filecount: %u" >> ", filesize: " SIZE_FORMAT " KiB).", >> _file_name, _file_count, _rotate_size / K); > > ack. I will add some log_traces for asynclogflusher and this. done. ------------- PR: https://git.openjdk.java.net/jdk/pull/3135 From jiefu at openjdk.java.net Sat Apr 24 00:11:28 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Sat, 24 Apr 2021 00:11:28 GMT Subject: RFR: 8265491: Math Signum optimization for x86 [v7] In-Reply-To: <-R3W5TtT5d8dyhcrKvkAUSndQshrVZTHN0VxpIJZoow=.6024f8a6-9fbd-4cc9-9381-8ea54a931bf9@github.com> References: <-R3W5TtT5d8dyhcrKvkAUSndQshrVZTHN0VxpIJZoow=.6024f8a6-9fbd-4cc9-9381-8ea54a931bf9@github.com> Message-ID: On Fri, 23 Apr 2021 17:24:53 GMT, Marcus G K Williams wrote: >> x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM. >> >> We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization. >> >> Base: >> >> Benchmark Mode Cnt Score Error Units >> Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op >> Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op >> Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op >> Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op >> >> >> Optimized: >> signum intrinsic patch >> >> Benchmark Mode Cnt Score Error Units >> Signum._1_signumFloatTest avgt 5 3.769 ? 0.015 ns/op >> Signum._2_overheadFloat avgt 5 3.312 ? 0.025 ns/op >> Signum._3_signumDoubleTest avgt 5 3.765 ? 0.005 ns/op >> Signum._4_overheadDouble avgt 5 3.309 ? 0.010 ns/op >> >> >> Signed-off-by: Marcus G K Williams > > Marcus G K Williams has updated the pull request incrementally with two additional commits since the last revision: > > - Update DamonFool > > Signed-off-by: Marcus G K Williams > - Refactor on suggestion of jatin-bhateja & theRealAph > > Signed-off-by: Marcus G K Williams test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java line 2: > 1: /* > 2: * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved. This is incorrect since it's not a new file. I suggest this kind of change diff --git a/test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java b/test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java index 86434d556bb..37aa511dcff 100644 --- a/test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java +++ b/test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2020, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2020, 2021, Oracle and/or its affiliates. All rights reserved. * Copyright (c) 2020, BELLSOFT. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * ------------- PR: https://git.openjdk.java.net/jdk/pull/3581 From github.com+168222+mgkwill at openjdk.java.net Sat Apr 24 00:21:50 2021 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Sat, 24 Apr 2021 00:21:50 GMT Subject: RFR: 8265491: Math Signum optimization for x86 [v7] In-Reply-To: References: <-R3W5TtT5d8dyhcrKvkAUSndQshrVZTHN0VxpIJZoow=.6024f8a6-9fbd-4cc9-9381-8ea54a931bf9@github.com> Message-ID: On Sat, 24 Apr 2021 00:08:19 GMT, Jie Fu wrote: >> Marcus G K Williams has updated the pull request incrementally with two additional commits since the last revision: >> >> - Update DamonFool >> >> Signed-off-by: Marcus G K Williams >> - Refactor on suggestion of jatin-bhateja & theRealAph >> >> Signed-off-by: Marcus G K Williams > > test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java line 2: > >> 1: /* >> 2: * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved. > > This is incorrect since it's not a new file. > > I suggest this kind of change > > diff --git a/test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java b/test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java > index 86434d556bb..37aa511dcff 100644 > --- a/test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java > +++ b/test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2020, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2020, 2021, Oracle and/or its affiliates. All rights reserved. > * Copyright (c) 2020, BELLSOFT. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * Thanks again @DamonFool. Fixed as you suggested. ------------- PR: https://git.openjdk.java.net/jdk/pull/3581 From github.com+168222+mgkwill at openjdk.java.net Sat Apr 24 00:21:49 2021 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Sat, 24 Apr 2021 00:21:49 GMT Subject: RFR: 8265491: Math Signum optimization for x86 [v8] In-Reply-To: References: Message-ID: > x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM. > > We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization. > > Base: > > Benchmark Mode Cnt Score Error Units > Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op > Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op > Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op > Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op > > > Optimized: > signum intrinsic patch > > Benchmark Mode Cnt Score Error Units > Signum._1_signumFloatTest avgt 5 3.769 ? 0.015 ns/op > Signum._2_overheadFloat avgt 5 3.312 ? 0.025 ns/op > Signum._3_signumDoubleTest avgt 5 3.765 ? 0.005 ns/op > Signum._4_overheadDouble avgt 5 3.309 ? 0.010 ns/op > > > Signed-off-by: Marcus G K Williams Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision: Fix copyright Signed-off-by: Marcus G K Williams ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3581/files - new: https://git.openjdk.java.net/jdk/pull/3581/files/3e0a4c79..7d54845f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3581&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3581&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3581.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3581/head:pull/3581 PR: https://git.openjdk.java.net/jdk/pull/3581 From jiefu at openjdk.java.net Sat Apr 24 00:27:25 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Sat, 24 Apr 2021 00:27:25 GMT Subject: RFR: 8265491: Math Signum optimization for x86 [v8] In-Reply-To: References: Message-ID: On Sat, 24 Apr 2021 00:21:49 GMT, Marcus G K Williams wrote: >> x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM. >> >> We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization. >> >> Base: >> >> Benchmark Mode Cnt Score Error Units >> Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op >> Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op >> Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op >> Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op >> >> >> Optimized: >> signum intrinsic patch >> >> Benchmark Mode Cnt Score Error Units >> Signum._1_signumFloatTest avgt 5 3.769 ? 0.015 ns/op >> Signum._2_overheadFloat avgt 5 3.312 ? 0.025 ns/op >> Signum._3_signumDoubleTest avgt 5 3.765 ? 0.005 ns/op >> Signum._4_overheadDouble avgt 5 3.309 ? 0.010 ns/op >> >> >> Signed-off-by: Marcus G K Williams > > Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision: > > Fix copyright > > Signed-off-by: Marcus G K Williams Looks good to me. Thanks. ------------- Marked as reviewed by jiefu (Committer). PR: https://git.openjdk.java.net/jdk/pull/3581 From xliu at openjdk.java.net Sat Apr 24 08:16:26 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Sat, 24 Apr 2021 08:16:26 GMT Subject: RFR: 8229517: Support for optional asynchronous/buffered logging [v2] In-Reply-To: References: <5lZuUwWVD5NwXo_gUOnUDUD4tdYUvils5Cx5X5r8elo=.5d1f1074-730a-4f88-ba67-67977ffe58d0@github.com> <37Cm5ItlFJ8nzQW_HI6-oyO_TuTK3f09BqiZ2-0l-iE=.fdde37ed-aa6b-4c28-bc30-0403542a518b@github.com> <0qKPSmxPH02xshv9gpcarh-LIc6xiZnlYVCDrRPtCP0=.94eaa31a-501b-4d48-ade0-ae1abf6acddf@github.com> <38hXykjHJTEhOD0CAggi-VnbcQra-I9Js8BWeM86s88=.ef06f49b-ab26-4b3a-827e-da79ba242302@github.com> Message-ID: On Tue, 6 Apr 2021 07:05:57 GMT, Robbin Ehn wrote: > Hi Xin, > > From the algorithm perspective all loggers are readers. > We are protecting the buffer pointer which only the flusher writes to. > To make sure not one still sees the old buffer after the storing of the swapped in one we need to issue a write synchronize. > When the write synchronize finishes we know that the to be flushed buffer is no longer visible. > > That the readers of this buffer pointer writes into the buffer doesn't matter since they can only write if they can see the buffer. > When no reader can see the buffer, they can not write to it either. > > I do not follow your reasoning on atomic increment. > > * This change-set have: > ` { // critical area MutexLocker ml(&_lock, Mutex::_no_safepoint_check_flag); enqueue_impl(m); }` > > * A lock free linked list is most often implemented with CAS. > > > Both CAS and above mutex serialization are more expensive atomic inc. > > If you feel that your current code is battle-proven and you think doing additional enhancements as incremental changes is better, please do so. As I said, I don't have any big concern about either performance nor blocking the the VM thread. Hi, Robin, Now I understand "From the algorithm perspective all loggers are readers". `LogOutputList` uses the similar idea and I do leverage it when obtaining lock is inappropriate in this PR. `GlobalCounter::write_synchronize()` is epoch-based RCU for "safe memory reclamation". It's intriguing to use in a ping-pang buffer and now I see it's correct! I am very interested in it and let me try it out after this PR. I feel sorry that my reflection arc is so long. I have to read and understand a lot of hotspot runtime code, which is not easy for me. For "the most expensive synchronization is atomic_incrementation." I mean we need to atomic increase the writing pointer of a buffer no matter what. It should be the most expensive "cost". Yes, I acknowledge that atomic operations are cheaper than CAS or mutex. So far, I am fine with the performance(it's not my intention to writing a "high-performance" logging), but I feel it's quite cumbersome to use Mutex given the fact that its ranking is stiff. GlobalCounter+ping-pang buffer should result in a more concise and efficient implementation. thanks, --lx ------------- PR: https://git.openjdk.java.net/jdk/pull/3135 From kbarrett at openjdk.java.net Sat Apr 24 19:38:23 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Sat, 24 Apr 2021 19:38:23 GMT Subject: RFR: 8254598: StringDedupTable should use OopStorage Message-ID: Please review this change to the String Deduplication facility. It is being changed to use OopStorage to hold weak references to relevant objects, rather than bespoke data structures requiring dedicated processing phases by supporting GCs. (The Shenandoah update was contributed by Zhengyu Gu.) This change significantly simplifies the interface between a given GC and the String Deduplication facility, which should make it much easier for other GCs to opt in. However, this change does not alter the set of GCs providing support; currently only G1 and Shenandoah support string deduplication. Adding support by other GCs will be in followup RFEs. Reviewing via the diffs might not be all that useful for some parts, as several files have been essentially completely replaced, and a number of files have been added or eliminated. The full webrev might be a better place to look. The major changes are in gc/shared/stringdedup/* and in the supporting collectors, but there are also some smaller changes in other places, most notably classfile/{stringTable,javaClasses}. This change is additionally labeled for review by core-libs, although there are no source changes there. This change injects a byte field of bits into java.lang.String, using one of the previously unused padding bytes in that class. (There were two unused bytes, now only one.) Testing: mach5 tier1-2 with and without -XX:+UseStringDeduplication Locally (linux-x64) ran all of the existing tests that use string deduplication with both G1 and Shenandoah. Note that TestStringDeduplicationInterned.java is disabled for shenandoah, as it currently fails, for reasons I haven't figured out but suspect are test related. - gc/stringdedup/ -- these used to be in gc/g1 - runtime/cds/SharedStringsDedup.java - runtime/cds/appcds/cacheObject/DifferentHeapSizes.java - runtime/cds/appcds/sharedStrings/* shenandoah-only: - gc/shenandoah/jvmti/TestHeapDump.java - gc/shenandoah/TestStringDedup.java - gc/shenandoah/TestStringDedupStress.java Performance tested baseline, baseline + stringdedup, new with stringdedup, finding no significant differences. ------------- Commit messages: - New string deduplication Changes: https://git.openjdk.java.net/jdk/pull/3662/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3662&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8254598 Stats: 6185 lines in 105 files changed: 2361 ins; 3202 del; 622 mod Patch: https://git.openjdk.java.net/jdk/pull/3662.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3662/head:pull/3662 PR: https://git.openjdk.java.net/jdk/pull/3662 From ayang at openjdk.java.net Sun Apr 25 19:51:51 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Sun, 25 Apr 2021 19:51:51 GMT Subject: RFR: 8234020: Remove FullGCCount_lock Message-ID: Remove an unused method and unnecessary synchronization in Serial GC. ------------- Commit messages: - fullgclock Changes: https://git.openjdk.java.net/jdk/pull/3679/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3679&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8234020 Stats: 23 lines in 4 files changed: 0 ins; 23 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3679.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3679/head:pull/3679 PR: https://git.openjdk.java.net/jdk/pull/3679 From kbarrett at openjdk.java.net Mon Apr 26 04:05:25 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Mon, 26 Apr 2021 04:05:25 GMT Subject: RFR: 8234020: Remove FullGCCount_lock In-Reply-To: References: Message-ID: On Sun, 25 Apr 2021 19:44:50 GMT, Albert Mingkun Yang wrote: > Remove an unused method and unnecessary synchronization in Serial GC. Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3679 From dongbo at openjdk.java.net Mon Apr 26 05:58:52 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Mon, 26 Apr 2021 05:58:52 GMT Subject: RFR: 8264973: AArch64: Optimize vector max/min/add reduction of two integers with NEON pairwise instructions Message-ID: On aarch64, current implementations of vector reduce_add2I, reduce_max2I, reduce_min2I can be optimized with NEON pairwise instructions: ## reduce_add2I, before mov w10, v19.s[0] mov w2, v19.s[1] add w10, w0, w10 add w10, w10, w2 ## reduce_add2I, optimized addp v23.2s, v24.2s, v24.2s mov w10, v23.s[0] add w10, w10, w2 ## reduce_max2I, before dup v16.2d, v23.d[0] sminv s16, v16.4s mov w10, v16.s[0] cmp w10, w0 csel w10, w10, w0, lt ## reduce_max2I, optimized sminp v16.2s, v23.2s, v23.2s mov w10, v16.s[0] cmp w10, w0 csel w10, w10, w0, lt I don't expect this to change anything of SuperWord, vectorizing of length 2 reductions is disabled by [1]. This is useful for VectorAPI, tested benchmarks in [2], performance can improve ~51% and ~8% for `Int64Vector.ADD` and `Int64Vector.MAX` respectively. Benchmark (size) Mode Cnt Score Error Units # optimized Int64Vector.ADDLanes 1024 thrpt 10 2492.123 ? 23.561 ops/ms Int64Vector.ADDMaskedLanes 1024 thrpt 10 1825.882 ? 5.261 ops/ms Int64Vector.MAXLanes 1024 thrpt 10 1921.028 ? 3.253 ops/ms Int64Vector.MAXMaskedLanes 1024 thrpt 10 1588.575 ? 3.903 ops/ms Int64Vector.MINLanes 1024 thrpt 10 1923.913 ? 2.117 ops/ms Int64Vector.MINMaskedLanes 1024 thrpt 10 1596.875 ? 2.163 ops/ms # default Int64Vector.ADDLanes 1024 thrpt 10 1644.223 ? 1.885 ops/ms Int64Vector.ADDMaskedLanes 1024 thrpt 10 1491.502 ? 26.436 ops/ms Int64Vector.MAXLanes 1024 thrpt 10 1784.066 ? 3.816 ops/ms Int64Vector.MAXMaskedLanes 1024 thrpt 10 1494.750 ? 3.451 ops/ms Int64Vector.MINLanes 1024 thrpt 10 1785.266 ? 8.893 ops/ms Int64Vector.MINMaskedLanes 1024 thrpt 10 1499.233 ? 3.498 ops/ms Verified correctness with tests `test/jdk/jdk/incubator/vector/`. Also tested linux-aarch64-server-fastdebug tier1-3. [1] https://github.com/openjdk/jdk/blob/3bf4c904fbbd87d4db18db22c1be384616483eed/src/hotspot/share/opto/superword.cpp#L2004 [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/jdk/jdk/incubator/vector/benchmark/src/main/java/benchmark/jdk/incubator/vector/Int64Vector.java ------------- Commit messages: - 8264973: AArch64: Optimize vector max/min/add reduction of two integers with NEON pairwise instructions Changes: https://git.openjdk.java.net/jdk/pull/3683/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3683&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264973 Stats: 40 lines in 3 files changed: 2 ins; 12 del; 26 mod Patch: https://git.openjdk.java.net/jdk/pull/3683.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3683/head:pull/3683 PR: https://git.openjdk.java.net/jdk/pull/3683 From yyang at openjdk.java.net Mon Apr 26 06:33:31 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Mon, 26 Apr 2021 06:33:31 GMT Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex [v2] In-Reply-To: References: Message-ID: On Fri, 23 Apr 2021 03:50:54 GMT, Yi Yang wrote: >> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version. >> >> In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot. >> >> But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later: >> >> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase. >> 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag >> >> Testing: cds, compiler and jdk > > Yi Yang has updated the pull request incrementally with one additional commit since the last revision: > > remove java_nio_Buffer in javaClasses.hpp Can I have a review of this PR? Thanks! ------------- PR: https://git.openjdk.java.net/jdk/pull/3615 From sjohanss at openjdk.java.net Mon Apr 26 08:21:31 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Mon, 26 Apr 2021 08:21:31 GMT Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux [v27] In-Reply-To: References: Message-ID: On Fri, 23 Apr 2021 22:34:16 GMT, Marcus G K Williams wrote: > > an easy approach should be to just remove all large page sizes larger than the decided maximum from _page_sizes. > > It seemed easier to forgo adding large page sizes if they were less than `LargePageSizeInBytes` and `LargePageSizeInBytes != 0` or default. Please let me know if the solution seems appropriate. > Sure, this is fine as well. I have some comments bug will post them in the code. > > The warning should go away since it is documented to mean use the default. > > Done. Feedback there would also be helpful. > > I'm seeing one failure with the TestTracePageSizes test that I'm yet to figure out. On a run with `run main/othervm -XX:+AlwaysPreTouch -Xlog:pagesize:ps-%p.log -XX:+UseSerialGC -XX:+UseTransparentHugePages TestTracePageSizes` > reason: User specified action: run main/othervm -XX:+AlwaysPreTouch -Xlog:pagesize:ps-%p.log -XX:+UseSerialGC -XX:+UseTransparentHugePages TestTracePageSizes > ... > Added range: [43a400000, 440000000) pageSize=4KB isTHP=false isHUGETLB=false > Added range: [440000000, 480000000) pageSize=4KB isTHP=true isHUGETLB=false > Added range: [480000000, 57c2a0000) pageSize=4KB isTHP=false isHUGETLB=false > > Two guesses so far: It seems like a possible issue with `ReservedSpace::actual_reserved_page_size` returning the wrong page size. Or could this base page address be 4k padding for THP largepage? This seems to be a problem with the test, it assumes that the whole range for the heap should be using the same page size but for THP this might not be true since it is up to the system to decide. Been able to reproduce it locally as well and it seems more likely to happen when the heap large, might be that the whole range can't be satisfied with large pages and for some reason the system decides to not use them for the first range `[43a400000, 440000000)`. This range is still 2M aligned, so it should be able to. ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From pliden at openjdk.java.net Mon Apr 26 08:49:31 2021 From: pliden at openjdk.java.net (Per Liden) Date: Mon, 26 Apr 2021 08:49:31 GMT Subject: Integrated: 8265702: ZGC on macOS/aarch64 In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 21:10:02 GMT, Per Liden wrote: > This patch enables ZGC on macOS/aarch64. It does three things: > 1) Enables building of ZGC on this platform. > 2) Adds `os::processor_id()`, which for now always returns 0. > 3) Fixes a WX issue in `OptoRuntime::handle_exception_C()`, where the stackwater mark might unnecessarily process a frame when the thread is in WXExec mode. In this case, the we're not touching any oops, so we don't need to process any frames. > > Testing: Passes the same tests as macOS/x86_64 (with the exception of pre-existing issues unrelated to ZGC). This pull request has now been integrated. Changeset: 0d08d735 Author: Per Liden URL: https://git.openjdk.java.net/jdk/commit/0d08d735 Stats: 13 lines in 3 files changed: 7 ins; 1 del; 5 mod 8265702: ZGC on macOS/aarch64 Reviewed-by: erikj, dholmes, stefank, gziemski ------------- PR: https://git.openjdk.java.net/jdk/pull/3609 From pliden at openjdk.java.net Mon Apr 26 08:49:30 2021 From: pliden at openjdk.java.net (Per Liden) Date: Mon, 26 Apr 2021 08:49:30 GMT Subject: RFR: 8265702: ZGC on macOS/aarch64 [v2] In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 23:04:43 GMT, Erik Joelsson wrote: >> Per Liden has updated the pull request incrementally with one additional commit since the last revision: >> >> Add comment to #else > > Build change looks good. Thanks @erikj79, @dholmes-ora, @stefank and @gerard-ziemski for reviewing! ------------- PR: https://git.openjdk.java.net/jdk/pull/3609 From sjohanss at openjdk.java.net Mon Apr 26 08:53:45 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Mon, 26 Apr 2021 08:53:45 GMT Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux [v29] In-Reply-To: References: Message-ID: On Fri, 23 Apr 2021 22:24:38 GMT, Marcus G K Williams wrote: >> Change the meaning of LargePageSizeInBytes to be the maximum large page size the JVM may use (not the only one). A default value of zero will mean to allow the JVM use large page sizes up to the system's default large page size. > > Marcus G K Williams has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 48 commits: > > - Set LargePageSizeInBytes to largepage upper limit > > Signed-off-by: Marcus G K Williams > - Merge branch 'master' into update_hlp > - Fix merge > > Signed-off-by: Marcus G K Williams > - Merge branch 'master' into update_hlp > - Merge branch 'master' into update_hlp > - Rebase on pull/3073 > > Signed-off-by: Marcus G K Williams > - Merge branch 'pull/3073' into update_hlp > - Thomas review. > > Changed commit_memory_special to return bool to signal if the request succeeded or not. > - Self review. > > Update helper name to better match commit_memory_special(). > - Marcus review. > > Updated comments. > - ... and 38 more: https://git.openjdk.java.net/jdk/compare/5aab1609...6f063309 Changes requested by sjohanss (Reviewer). src/hotspot/os/linux/os_linux.cpp line 3737: > 3735: // Populate large page sizes to _page_sizes. Add pages that > 3736: // are less than or equal to LargePageSizeInBytes, except when LargePageSizeInBytes=0 > 3737: // or FLAG_IS_DEFAULT(LargePageSizeInBytes), add all sizes What we currently have in the CSR is to use the default large page size as the max if `LargePageSizeInBytes`is not set. If we first check if `LargePageSizeInBytes` have been set and update `_large_page_size` accordingly above (see comment below). I think this comment should say something like: Suggestion: // Populate _page_sizes with large page sizes less than or equal to // _large_page_size. src/hotspot/os/linux/os_linux.cpp line 3767: > 3765: } else { > 3766: _large_page_size = default_large_page_size; > 3767: } Move this part up to be done before you populate `_page_sizes` with the page sizes from `all_page_sizes`. Then you can use `_large_page_size` as the maximum page size that you add to `_page_sizes` and you don't have to care about `LargePageSizeInBytes` in that for-loop. ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From sjohanss at openjdk.java.net Mon Apr 26 08:53:46 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Mon, 26 Apr 2021 08:53:46 GMT Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux [v29] In-Reply-To: <2UqkjBQ_wVQcz_qx2wjchZanODAw8-QB-qROH9kdLM0=.e1980df2-de0c-412f-b219-5ac2eb38fafb@github.com> References: <2UqkjBQ_wVQcz_qx2wjchZanODAw8-QB-qROH9kdLM0=.e1980df2-de0c-412f-b219-5ac2eb38fafb@github.com> Message-ID: On Mon, 26 Apr 2021 08:34:26 GMT, Stefan Johansson wrote: >> src/hotspot/os/linux/os_linux.cpp line 3767: >> >>> 3765: } else { >>> 3766: _large_page_size = default_large_page_size; >>> 3767: } >> >> Move this part up to be done before you populate `_page_sizes` with the page sizes from `all_page_sizes`. Then you can use `_large_page_size` as the maximum page size that you add to `_page_sizes` and you don't have to care about `LargePageSizeInBytes` in that for-loop. > > I also think that the log-tag should be `pagesize`. The comment here could also be updated: // Check LargePageSizeInBytes and setup _large_page_size to hold // the maximum allowed large page size. If not set the default large // page size is used as the maximum. ``` ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From sjohanss at openjdk.java.net Mon Apr 26 08:53:46 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Mon, 26 Apr 2021 08:53:46 GMT Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux [v29] In-Reply-To: References: Message-ID: <2UqkjBQ_wVQcz_qx2wjchZanODAw8-QB-qROH9kdLM0=.e1980df2-de0c-412f-b219-5ac2eb38fafb@github.com> On Mon, 26 Apr 2021 08:33:44 GMT, Stefan Johansson wrote: >> Marcus G K Williams has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 48 commits: >> >> - Set LargePageSizeInBytes to largepage upper limit >> >> Signed-off-by: Marcus G K Williams >> - Merge branch 'master' into update_hlp >> - Fix merge >> >> Signed-off-by: Marcus G K Williams >> - Merge branch 'master' into update_hlp >> - Merge branch 'master' into update_hlp >> - Rebase on pull/3073 >> >> Signed-off-by: Marcus G K Williams >> - Merge branch 'pull/3073' into update_hlp >> - Thomas review. >> >> Changed commit_memory_special to return bool to signal if the request succeeded or not. >> - Self review. >> >> Update helper name to better match commit_memory_special(). >> - Marcus review. >> >> Updated comments. >> - ... and 38 more: https://git.openjdk.java.net/jdk/compare/5aab1609...6f063309 > > src/hotspot/os/linux/os_linux.cpp line 3767: > >> 3765: } else { >> 3766: _large_page_size = default_large_page_size; >> 3767: } > > Move this part up to be done before you populate `_page_sizes` with the page sizes from `all_page_sizes`. Then you can use `_large_page_size` as the maximum page size that you add to `_page_sizes` and you don't have to care about `LargePageSizeInBytes` in that for-loop. I also think that the log-tag should be `pagesize`. ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From njian at openjdk.java.net Mon Apr 26 10:29:29 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Mon, 26 Apr 2021 10:29:29 GMT Subject: RFR: 8264973: AArch64: Optimize vector max/min/add reduction of two integers with NEON pairwise instructions In-Reply-To: References: Message-ID: On Mon, 26 Apr 2021 05:50:20 GMT, Dong Bo wrote: > On aarch64, current implementations of vector reduce_add2I, reduce_max2I, reduce_min2I can be optimized with NEON pairwise instructions: > > > ## reduce_add2I, before > mov w10, v19.s[0] > mov w2, v19.s[1] > add w10, w0, w10 > add w10, w10, w2 > ## reduce_add2I, optimized > addp v23.2s, v24.2s, v24.2s > mov w10, v23.s[0] > add w10, w10, w2 > > ## reduce_max2I, before > dup v16.2d, v23.d[0] > sminv s16, v16.4s > mov w10, v16.s[0] > cmp w10, w0 > csel w10, w10, w0, lt > ## reduce_max2I, optimized > sminp v16.2s, v23.2s, v23.2s > mov w10, v16.s[0] > cmp w10, w0 > csel w10, w10, w0, lt > > > I don't expect this to change anything of SuperWord, vectorizing reductions of two integers is disabled by [1]. > This is useful for VectorAPI, tested benchmarks in [2], performance can improve ~51% and ~8% for `Int64Vector.ADD` and `Int64Vector.MAX` respectively. > > > Benchmark (size) Mode Cnt Score Error Units > # optimized > Int64Vector.ADDLanes 1024 thrpt 10 2492.123 ? 23.561 ops/ms > Int64Vector.ADDMaskedLanes 1024 thrpt 10 1825.882 ? 5.261 ops/ms > Int64Vector.MAXLanes 1024 thrpt 10 1921.028 ? 3.253 ops/ms > Int64Vector.MAXMaskedLanes 1024 thrpt 10 1588.575 ? 3.903 ops/ms > Int64Vector.MINLanes 1024 thrpt 10 1923.913 ? 2.117 ops/ms > Int64Vector.MINMaskedLanes 1024 thrpt 10 1596.875 ? 2.163 ops/ms > # default > Int64Vector.ADDLanes 1024 thrpt 10 1644.223 ? 1.885 ops/ms > Int64Vector.ADDMaskedLanes 1024 thrpt 10 1491.502 ? 26.436 ops/ms > Int64Vector.MAXLanes 1024 thrpt 10 1784.066 ? 3.816 ops/ms > Int64Vector.MAXMaskedLanes 1024 thrpt 10 1494.750 ? 3.451 ops/ms > Int64Vector.MINLanes 1024 thrpt 10 1785.266 ? 8.893 ops/ms > Int64Vector.MINMaskedLanes 1024 thrpt 10 1499.233 ? 3.498 ops/ms > > > Verified correctness with tests `test/jdk/jdk/incubator/vector/`. Also tested linux-aarch64-server-fastdebug tier1-3. > > [1] https://github.com/openjdk/jdk/blob/3bf4c904fbbd87d4db18db22c1be384616483eed/src/hotspot/share/opto/superword.cpp#L2004 > [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/jdk/jdk/incubator/vector/benchmark/src/main/java/benchmark/jdk/incubator/vector/Int64Vector.java Yes, this looks good to me. Thanks! ------------- Marked as reviewed by njian (Committer). PR: https://git.openjdk.java.net/jdk/pull/3683 From njian at openjdk.java.net Mon Apr 26 10:32:37 2021 From: njian at openjdk.java.net (Ningsheng Jian) Date: Mon, 26 Apr 2021 10:32:37 GMT Subject: RFR: 8264973: AArch64: Optimize vector max/min/add reduction of two integers with NEON pairwise instructions In-Reply-To: References: Message-ID: On Mon, 26 Apr 2021 05:50:20 GMT, Dong Bo wrote: > On aarch64, current implementations of vector reduce_add2I, reduce_max2I, reduce_min2I can be optimized with NEON pairwise instructions: > > > ## reduce_add2I, before > mov w10, v19.s[0] > mov w2, v19.s[1] > add w10, w0, w10 > add w10, w10, w2 > ## reduce_add2I, optimized > addp v23.2s, v24.2s, v24.2s > mov w10, v23.s[0] > add w10, w10, w2 > > ## reduce_max2I, before > dup v16.2d, v23.d[0] > sminv s16, v16.4s > mov w10, v16.s[0] > cmp w10, w0 > csel w10, w10, w0, lt > ## reduce_max2I, optimized > sminp v16.2s, v23.2s, v23.2s > mov w10, v16.s[0] > cmp w10, w0 > csel w10, w10, w0, lt > > > I don't expect this to change anything of SuperWord, vectorizing reductions of two integers is disabled by [1]. > This is useful for VectorAPI, tested benchmarks in [2], performance can improve ~51% and ~8% for `Int64Vector.ADD` and `Int64Vector.MAX` respectively. > > > Benchmark (size) Mode Cnt Score Error Units > # optimized > Int64Vector.ADDLanes 1024 thrpt 10 2492.123 ? 23.561 ops/ms > Int64Vector.ADDMaskedLanes 1024 thrpt 10 1825.882 ? 5.261 ops/ms > Int64Vector.MAXLanes 1024 thrpt 10 1921.028 ? 3.253 ops/ms > Int64Vector.MAXMaskedLanes 1024 thrpt 10 1588.575 ? 3.903 ops/ms > Int64Vector.MINLanes 1024 thrpt 10 1923.913 ? 2.117 ops/ms > Int64Vector.MINMaskedLanes 1024 thrpt 10 1596.875 ? 2.163 ops/ms > # default > Int64Vector.ADDLanes 1024 thrpt 10 1644.223 ? 1.885 ops/ms > Int64Vector.ADDMaskedLanes 1024 thrpt 10 1491.502 ? 26.436 ops/ms > Int64Vector.MAXLanes 1024 thrpt 10 1784.066 ? 3.816 ops/ms > Int64Vector.MAXMaskedLanes 1024 thrpt 10 1494.750 ? 3.451 ops/ms > Int64Vector.MINLanes 1024 thrpt 10 1785.266 ? 8.893 ops/ms > Int64Vector.MINMaskedLanes 1024 thrpt 10 1499.233 ? 3.498 ops/ms > > > Verified correctness with tests `test/jdk/jdk/incubator/vector/`. Also tested linux-aarch64-server-fastdebug tier1-3. > > [1] https://github.com/openjdk/jdk/blob/3bf4c904fbbd87d4db18db22c1be384616483eed/src/hotspot/share/opto/superword.cpp#L2004 > [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/jdk/jdk/incubator/vector/benchmark/src/main/java/benchmark/jdk/incubator/vector/Int64Vector.java src/hotspot/cpu/aarch64/assembler_aarch64.hpp line 2408: > 2406: INSN(minv, 0, 0b011011, false); // accepted arrangements: T8B, T16B, T4H, T8H, T2S, T4S > 2407: INSN(smaxp, 0, 0b101001, false); // accepted arrangements: T8B, T16B, T4H, T8H, T2S, T4S > 2408: INSN(sminp, 0, 0b101011, false); // accepted arrangements: T8B, T16B, T4H, T8H, T2S, T4S Just one nit: do we need an assembler test case for them? ------------- PR: https://git.openjdk.java.net/jdk/pull/3683 From avoitylov at openjdk.java.net Mon Apr 26 10:53:36 2021 From: avoitylov at openjdk.java.net (Aleksei Voitylov) Date: Mon, 26 Apr 2021 10:53:36 GMT Subject: RFR: 8265756: AArch64: initialize memory allocated for locals according to Windows AArch64 stack page growth requirement in template interpreter [v3] In-Reply-To: References: Message-ID: > Hi, > > please review this PR which fixes several JCK test failures on Windows AArch64. On Windows AArch64, the order in which the pages are touched during stack allocation, matters. Here is a quote: "Functions that allocate 4k or more worth of stack must ensure that each page prior to the final page is touched in order" [1]. Since on Linux and Mac the order does not matter, the suggested fix reverses the order in which memory pages are touched during stack allocation for locals in template interpreter for all platforms. > > Testing: JCK, jtreg, newly developed regression test on Linux AArch64, Windows AArch64, Mac AArch64, Pre-submit tests (which includes the newly developed test). > > [1] https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-160#stack Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision: terminology refresh and move tests to a different location ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3633/files - new: https://git.openjdk.java.net/jdk/pull/3633/files/5e8c7d6a..590721a6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3633&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3633&range=01-02 Stats: 216 lines in 4 files changed: 108 ins; 108 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3633.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3633/head:pull/3633 PR: https://git.openjdk.java.net/jdk/pull/3633 From dongbo at openjdk.java.net Mon Apr 26 11:16:00 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Mon, 26 Apr 2021 11:16:00 GMT Subject: RFR: 8264973: AArch64: Optimize vector max/min/add reduction of two integers with NEON pairwise instructions [v2] In-Reply-To: References: Message-ID: <1ZfSsFKnXwnkqtxIGeyZyb6L9yFghYh-sTZUWTY3A5U=.1a518678-3fd9-4dcb-be04-20c0060bfe91@github.com> > On aarch64, current implementations of vector reduce_add2I, reduce_max2I, reduce_min2I can be optimized with NEON pairwise instructions: > > > ## reduce_add2I, before > mov w10, v19.s[0] > mov w2, v19.s[1] > add w10, w0, w10 > add w10, w10, w2 > ## reduce_add2I, optimized > addp v23.2s, v24.2s, v24.2s > mov w10, v23.s[0] > add w10, w10, w2 > > ## reduce_max2I, before > dup v16.2d, v23.d[0] > sminv s16, v16.4s > mov w10, v16.s[0] > cmp w10, w0 > csel w10, w10, w0, lt > ## reduce_max2I, optimized > sminp v16.2s, v23.2s, v23.2s > mov w10, v16.s[0] > cmp w10, w0 > csel w10, w10, w0, lt > > > I don't expect this to change anything of SuperWord, vectorizing reductions of two integers is disabled by [1]. > This is useful for VectorAPI, tested benchmarks in [2], performance can improve ~51% and ~8% for `Int64Vector.ADD` and `Int64Vector.MAX` respectively. > > > Benchmark (size) Mode Cnt Score Error Units > # optimized > Int64Vector.ADDLanes 1024 thrpt 10 2492.123 ? 23.561 ops/ms > Int64Vector.ADDMaskedLanes 1024 thrpt 10 1825.882 ? 5.261 ops/ms > Int64Vector.MAXLanes 1024 thrpt 10 1921.028 ? 3.253 ops/ms > Int64Vector.MAXMaskedLanes 1024 thrpt 10 1588.575 ? 3.903 ops/ms > Int64Vector.MINLanes 1024 thrpt 10 1923.913 ? 2.117 ops/ms > Int64Vector.MINMaskedLanes 1024 thrpt 10 1596.875 ? 2.163 ops/ms > # default > Int64Vector.ADDLanes 1024 thrpt 10 1644.223 ? 1.885 ops/ms > Int64Vector.ADDMaskedLanes 1024 thrpt 10 1491.502 ? 26.436 ops/ms > Int64Vector.MAXLanes 1024 thrpt 10 1784.066 ? 3.816 ops/ms > Int64Vector.MAXMaskedLanes 1024 thrpt 10 1494.750 ? 3.451 ops/ms > Int64Vector.MINLanes 1024 thrpt 10 1785.266 ? 8.893 ops/ms > Int64Vector.MINMaskedLanes 1024 thrpt 10 1499.233 ? 3.498 ops/ms > > > Verified correctness with tests `test/jdk/jdk/incubator/vector/`. Also tested linux-aarch64-server-fastdebug tier1-3. > > [1] https://github.com/openjdk/jdk/blob/3bf4c904fbbd87d4db18db22c1be384616483eed/src/hotspot/share/opto/superword.cpp#L2004 > [2] https://github.com/openjdk/panama-vector/blob/vectorIntrinsics/test/jdk/jdk/incubator/vector/benchmark/src/main/java/benchmark/jdk/incubator/vector/Int64Vector.java Dong Bo has updated the pull request incrementally with one additional commit since the last revision: add assembler tests for smaxp/sminp ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3683/files - new: https://git.openjdk.java.net/jdk/pull/3683/files/0de0bef4..838ccc9c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3683&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3683&range=00-01 Stats: 254 lines in 2 files changed: 21 ins; 0 del; 233 mod Patch: https://git.openjdk.java.net/jdk/pull/3683.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3683/head:pull/3683 PR: https://git.openjdk.java.net/jdk/pull/3683 From dongbo at openjdk.java.net Mon Apr 26 11:20:35 2021 From: dongbo at openjdk.java.net (Dong Bo) Date: Mon, 26 Apr 2021 11:20:35 GMT Subject: RFR: 8264973: AArch64: Optimize vector max/min/add reduction of two integers with NEON pairwise instructions [v2] In-Reply-To: References: Message-ID: <6c5_c5_wzHfSy1jgOk5SzPDAk1h_qIG0UkwWXxFpH6s=.bc853035-5a9d-4b6b-975e-dd3b7d1f6a64@github.com> On Mon, 26 Apr 2021 10:29:24 GMT, Ningsheng Jian wrote: >> Dong Bo has updated the pull request incrementally with one additional commit since the last revision: >> >> add assembler tests for smaxp/sminp > > src/hotspot/cpu/aarch64/assembler_aarch64.hpp line 2408: > >> 2406: INSN(minv, 0, 0b011011, false); // accepted arrangements: T8B, T16B, T4H, T8H, T2S, T4S >> 2407: INSN(smaxp, 0, 0b101001, false); // accepted arrangements: T8B, T16B, T4H, T8H, T2S, T4S >> 2408: INSN(sminp, 0, 0b101011, false); // accepted arrangements: T8B, T16B, T4H, T8H, T2S, T4S > > Just one nit: do we need an assembler test case for them? Sure, added in the updated commit. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/3683 From avoitylov at openjdk.java.net Mon Apr 26 13:08:37 2021 From: avoitylov at openjdk.java.net (Aleksei Voitylov) Date: Mon, 26 Apr 2021 13:08:37 GMT Subject: RFR: 8265756: AArch64: initialize memory allocated for locals according to Windows AArch64 stack page growth requirement in template interpreter In-Reply-To: References: <4-NQ7nQndXAR0Ik5CuBxXvWIF0I626NJ0FsY00DtFW0=.09d08014-2981-4f5c-ada2-30ef743480d6@github.com> Message-ID: On Fri, 23 Apr 2021 11:49:23 GMT, Andrew Dinn wrote: >> @dholmes-ora @theRealAph thanks for your comments. Please check the updated version. > > @voitylov The patch still looks good modulo one niggle I have with the comment. > > You use the phrase "local variable table" (twice). That jarred when I read it because it's the term used for the debug mode bytecode attribute that records names and liveness ranges for parameter & local variables found in the java source. It would avoid any potential for confusion if you used a different term, e.g. "local vars stack region". @adinn thank you for noticing. I updated the terminology and renamed the test. ------------- PR: https://git.openjdk.java.net/jdk/pull/3633 From alanb at openjdk.java.net Mon Apr 26 13:23:27 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Mon, 26 Apr 2021 13:23:27 GMT Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex [v2] In-Reply-To: References: Message-ID: <9-2H-KUkJbuLQ4wO0bSrKG4OgihZzAU30TryjlFi3jc=.bdd81481-05e6-473b-b837-2ae17fd19067@github.com> On Fri, 23 Apr 2021 03:50:54 GMT, Yi Yang wrote: >> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version. >> >> In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot. >> >> But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later: >> >> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase. >> 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag >> >> Testing: cds, compiler and jdk > > Yi Yang has updated the pull request incrementally with one additional commit since the last revision: > > remove java_nio_Buffer in javaClasses.hpp src/java.base/share/classes/java/nio/Buffer.java line 740: > 738: */ > 739: final int checkIndex(int i) { // package-private > 740: return Objects.checkIndex(i, limit); Changing Buffer.checkIndex to use Objects.checkIndex is okay. ------------- PR: https://git.openjdk.java.net/jdk/pull/3615 From adinn at openjdk.java.net Mon Apr 26 13:36:27 2021 From: adinn at openjdk.java.net (Andrew Dinn) Date: Mon, 26 Apr 2021 13:36:27 GMT Subject: RFR: 8265756: AArch64: initialize memory allocated for locals according to Windows AArch64 stack page growth requirement in template interpreter [v3] In-Reply-To: References: Message-ID: On Mon, 26 Apr 2021 10:53:36 GMT, Aleksei Voitylov wrote: >> Hi, >> >> please review this PR which fixes several JCK test failures on Windows AArch64. On Windows AArch64, the order in which the pages are touched during stack allocation, matters. Here is a quote: "Functions that allocate 4k or more worth of stack must ensure that each page prior to the final page is touched in order" [1]. Since on Linux and Mac the order does not matter, the suggested fix reverses the order in which memory pages are touched during stack allocation for locals in template interpreter for all platforms. >> >> Testing: JCK, jtreg, newly developed regression test on Linux AArch64, Windows AArch64, Mac AArch64, Pre-submit tests (which includes the newly developed test). >> >> [1] https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-160#stack > > Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision: > > terminology refresh and move tests to a different location Marked as reviewed by adinn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3633 From adinn at openjdk.java.net Mon Apr 26 13:36:27 2021 From: adinn at openjdk.java.net (Andrew Dinn) Date: Mon, 26 Apr 2021 13:36:27 GMT Subject: RFR: 8265756: AArch64: initialize memory allocated for locals according to Windows AArch64 stack page growth requirement in template interpreter In-Reply-To: References: <4-NQ7nQndXAR0Ik5CuBxXvWIF0I626NJ0FsY00DtFW0=.09d08014-2981-4f5c-ada2-30ef743480d6@github.com> Message-ID: <7I_juASLsEtRBKjSFAiEWpFKD6TebwSwJXnC_0WRYFs=.661324d7-1bd1-4260-9ed4-3ab2e19cee48@github.com> On Mon, 26 Apr 2021 13:05:07 GMT, Aleksei Voitylov wrote: >> @voitylov The patch still looks good modulo one niggle I have with the comment. >> >> You use the phrase "local variable table" (twice). That jarred when I read it because it's the term used for the debug mode bytecode attribute that records names and liveness ranges for parameter & local variables found in the java source. It would avoid any potential for confusion if you used a different term, e.g. "local vars stack region". > > @adinn thank you for noticing. I updated the terminology and renamed the test. @voitylov thanks looks good. ------------- PR: https://git.openjdk.java.net/jdk/pull/3633 From adinn at openjdk.java.net Mon Apr 26 13:43:25 2021 From: adinn at openjdk.java.net (Andrew Dinn) Date: Mon, 26 Apr 2021 13:43:25 GMT Subject: RFR: 8265756: AArch64: initialize memory allocated for locals according to Windows AArch64 stack page growth requirement in template interpreter In-Reply-To: References: <4-NQ7nQndXAR0Ik5CuBxXvWIF0I626NJ0FsY00DtFW0=.09d08014-2981-4f5c-ada2-30ef743480d6@github.com> Message-ID: On Mon, 26 Apr 2021 13:05:07 GMT, Aleksei Voitylov wrote: >> @voitylov The patch still looks good modulo one niggle I have with the comment. >> >> You use the phrase "local variable table" (twice). That jarred when I read it because it's the term used for the debug mode bytecode attribute that records names and liveness ranges for parameter & local variables found in the java source. It would avoid any potential for confusion if you used a different term, e.g. "local vars stack region". > > @adinn thank you for noticing. I updated the terminology and renamed the test. @voitylov When you are ready type the /integrate command in a new comment and I will happily sponsor the change. ------------- PR: https://git.openjdk.java.net/jdk/pull/3633 From avoitylov at openjdk.java.net Mon Apr 26 13:43:26 2021 From: avoitylov at openjdk.java.net (Aleksei Voitylov) Date: Mon, 26 Apr 2021 13:43:26 GMT Subject: RFR: 8265756: AArch64: initialize memory allocated for locals according to Windows AArch64 stack page growth requirement in template interpreter In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 23:26:16 GMT, David Holmes wrote: >> Hi, >> >> please review this PR which fixes several JCK test failures on Windows AArch64. On Windows AArch64, the order in which the pages are touched during stack allocation, matters. Here is a quote: "Functions that allocate 4k or more worth of stack must ensure that each page prior to the final page is touched in order" [1]. Since on Linux and Mac the order does not matter, the suggested fix reverses the order in which memory pages are touched during stack allocation for locals in template interpreter for all platforms. >> >> Testing: JCK, jtreg, newly developed regression test on Linux AArch64, Windows AArch64, Mac AArch64, Pre-submit tests (which includes the newly developed test). >> >> [1] https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-160#stack > > Can you please add comments to the new test explaining exactly what it is that the test is doing, why you need to use a jasm file etc. Also add an @bug tag to the test. > > Thanks, > David @dholmes-ora do you have any further comments? ------------- PR: https://git.openjdk.java.net/jdk/pull/3633 From sjohanss at openjdk.java.net Mon Apr 26 14:12:26 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Mon, 26 Apr 2021 14:12:26 GMT Subject: RFR: 8234020: Remove FullGCCount_lock In-Reply-To: References: Message-ID: On Sun, 25 Apr 2021 19:44:50 GMT, Albert Mingkun Yang wrote: > Remove an unused method and unnecessary synchronization in Serial GC. Looks good, but please also remove: https://github.com/openjdk/jdk/blob/536cde177986a03e16bb3604e88bc35a6f39bec2/src/hotspot/share/runtime/mutexLocker.cpp#L75 ------------- Changes requested by sjohanss (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3679 From coleenp at openjdk.java.net Mon Apr 26 15:43:29 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 26 Apr 2021 15:43:29 GMT Subject: RFR: 8264593: debug.cpp utilities should be available in product builds. In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 14:05:42 GMT, Kevin Walls wrote: > This is a pull request to move the ifndef PRODUCT in src/hotspot/share/utilities/debug.cpp, and add JNIEXPORT for symbol visibility on Windows. > > With these changes, we can use gdb on a live Linux process of a product build JVM, and call debug.cpp utilities. > e.g. "call universe()", or "call hsfind(0xADDRESS)". > > (I found that making calls in the JLI_Launch thread (gdb's thread 1) will crash, but switching first to a JavaThread works.) > > In Visual Studio use the Immediate window, just type the function name. Verified that without the changes, the symbols can't be seen/called. > > Printing happens on the LIVE jvm's tty (not the gdb session). > > > WizardMode is a develop flag, can't be changed in a product build, so avoid changing that in the debug() utility. > > > pa() is left ifndef PRODUCT, as the class AllocatedObj is ifndef PRODUCT in src/hotspot/share/memory/allocation.hpp > > > pns(...) uses frame fr(sp, fp, pc); but we have an ifndef PRODUCT on frame constructor: frame(void* sp, void* fp, void* pc); > Leave pns and pns2 ifndef PRODUCT. > > > File size changes: > Linux: libjvm.so becomes 8904 bytes larger. > Windows: jvm.dll becomes 6656 bytes larger. Looks good with a very minor comment. Thank you for doing this and sorry for not getting to it sooner! src/hotspot/share/utilities/debug.cpp line 495: > 493: // AllocatedObj in allocation.hpp is not defined for PRODUCT > 494: extern "C" JNIEXPORT void pa(intptr_t p) { ((AllocatedObj*) p)->print(); } > 495: #endif I don't really think 'pa' is interesting enough to keep. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3307 From vlivanov at openjdk.java.net Mon Apr 26 17:27:11 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Mon, 26 Apr 2021 17:27:11 GMT Subject: RFR: 8264593: debug.cpp utilities should be available in product builds. In-Reply-To: References: Message-ID: <-dt9Hu5UMvmvM6st_KqqOUpL6FXhVtQRnYNp5mmSRfI=.7509a60c-7737-4675-82b4-26214940a238@github.com> On Thu, 1 Apr 2021 14:05:42 GMT, Kevin Walls wrote: > This is a pull request to move the ifndef PRODUCT in src/hotspot/share/utilities/debug.cpp, and add JNIEXPORT for symbol visibility on Windows. > > With these changes, we can use gdb on a live Linux process of a product build JVM, and call debug.cpp utilities. > e.g. "call universe()", or "call hsfind(0xADDRESS)". > > (I found that making calls in the JLI_Launch thread (gdb's thread 1) will crash, but switching first to a JavaThread works.) > > In Visual Studio use the Immediate window, just type the function name. Verified that without the changes, the symbols can't be seen/called. > > Printing happens on the LIVE jvm's tty (not the gdb session). > > > WizardMode is a develop flag, can't be changed in a product build, so avoid changing that in the debug() utility. > > > pa() is left ifndef PRODUCT, as the class AllocatedObj is ifndef PRODUCT in src/hotspot/share/memory/allocation.hpp > > > pns(...) uses frame fr(sp, fp, pc); but we have an ifndef PRODUCT on frame constructor: frame(void* sp, void* fp, void* pc); > Leave pns and pns2 ifndef PRODUCT. > > > File size changes: > Linux: libjvm.so becomes 8904 bytes larger. > Windows: jvm.dll becomes 6656 bytes larger. Looks good. It's a very valuable improvement in debuggability of product binaries. I'm surprised that all the diagnostic code debug commands rely on is already available in product binaries. ------------- Marked as reviewed by vlivanov (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3307 From kvn at openjdk.java.net Mon Apr 26 18:57:43 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 26 Apr 2021 18:57:43 GMT Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex [v2] In-Reply-To: References: Message-ID: On Fri, 23 Apr 2021 03:50:54 GMT, Yi Yang wrote: >> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version. >> >> In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot. >> >> But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later: >> >> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase. >> 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag >> >> Testing: cds, compiler and jdk > > Yi Yang has updated the pull request incrementally with one additional commit since the last revision: > > remove java_nio_Buffer in javaClasses.hpp @veresov please look on C1 changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/3615 From xliu at openjdk.java.net Mon Apr 26 19:00:56 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Mon, 26 Apr 2021 19:00:56 GMT Subject: RFR: 8265867: thread.hpp defines some enums but no reference Message-ID: Deleted 2 useless enums. This patch also added const and constexpr for the applicable member functions. ------------- Commit messages: - 8265867: thread.hpp defines some enums but no reference Changes: https://git.openjdk.java.net/jdk/pull/3702/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3702&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265867 Stats: 104 lines in 4 files changed: 0 ins; 12 del; 92 mod Patch: https://git.openjdk.java.net/jdk/pull/3702.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3702/head:pull/3702 PR: https://git.openjdk.java.net/jdk/pull/3702 From iignatyev at openjdk.java.net Mon Apr 26 19:09:43 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Mon, 26 Apr 2021 19:09:43 GMT Subject: RFR: 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests [v2] In-Reply-To: References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> Message-ID: On Mon, 19 Apr 2021 07:29:13 GMT, Christian Hagedorn wrote: >> test/lib/jdk/test/lib/hotspot/ir_framework/CompLevel.java line 62: >> >>> 60: *
>>> 61: */ >>> 62: ANY(-2), >> >> This will change (`-2` -> `-1`) after AOT is removed (8264805). > > I'll change that as soon as it is integrated. should we also add a comment suggesting to keep in sync w/ `compiler/compilerDefinitions.hpp`? ------------- PR: https://git.openjdk.java.net/jdk/pull/3508 From iignatyev at openjdk.java.net Mon Apr 26 19:09:43 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Mon, 26 Apr 2021 19:09:43 GMT Subject: RFR: 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests [v6] In-Reply-To: References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> Message-ID: On Fri, 23 Apr 2021 12:39:32 GMT, Christian Hagedorn wrote: >> This RFE provides an IR test framework to perform regex-based checks on the C2 IR shape of test methods emitted by the VM flags `-XX:+PrintIdeal` and `-XX:+PrintOptoAssembly`. The framework can also be used for other non-IR matching (and non-compiler) tests by providing easy to use annotations for commonly used testing patterns and compiler control flags. >> >> The framework is based on the ideas of the currently present IR test framework in [Valhalla](https://github.com/openjdk/valhalla/blob/e9c78ce4fcfd01361c35883e0d68f9ae5a80d079/test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypeTest.java) (mainly implemented by @TobiHartmann) which is being used with great success. This new framework aims to replace the old one in Valhalla at some point. >> >> A detailed description about how this new IR test framework works and how it is used is provided in the [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) file and in the [Javadocs](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc/jdk/test/lib/hotspot/ir_framework/package-summary.html) written for the framework classes. >> >> To finish a first version of this framework for JDK 17, I decided to leave some improvement possibilities and ideas to be followed up on in additional RFEs. Some ideas are mentioned in "Future Work" in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) and were also created as subtasks of this RFE. >> >> Testing (also described in "Internal Framework Tests in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md)): >> There are various tests to verify the correctness of the test framework which can be found as JTreg tests in the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) folder. Additional testing was performed by converting all compiler Inline Types test of project Valhalla (done by @katyapav in [JDK-8263024](https://bugs.openjdk.java.net/browse/JDK-8263024)) that used the old framework to the new framework. This provided additional testing for the framework itself. We ran the converted tests with all the flag settings used in hs-tier1-9 and hs-precheckin-comp. For sanity checking, this was also done with a sample IR test in mainline. >> >> Some stats about the framework code added to [ir_framework](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework): >> >> - without the [Javadocs files](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc) : 60 changed files, 13212 insertions, 0 deletions. >> - without the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) and [examples](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/examples) folder: 40 files changed, 6781 insertions >> - comments: 2399 insertions (calculated with `git diff --cached !(tests|examples) | grep -c -E "(^[+-]\s*(/)?*)|(^[+-]\s*//)"`) >> - which leaves 4382 lines of code inserted >> >> Big thanks to: >> - @TobiHartmann for all his help by discussing the new framework and for providing insights from his IR test framework in Valhalla. >> - @katyapav for converting the Valhalla tests to use the new framework which found some harder to catch bugs in the framework and also some actual C2 bugs. >> - @iignatev for helping to simplify the framework usage with JTreg and with the framework internal VM calling structure. >> - and others who provided valuable feedback. >> >> Thanks, >> Christian > > Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: > > Review comments by Tobias: Formatting fields, spacing, README.md typos and cleanup Changes requested by iignatyev (Reviewer). test/lib/jdk/test/lib/hotspot/ir_framework/AbstractInfo.java line 87: > 85: String parameters = args == null || args.length == 0 ? "" : > 86: " with arguments [" + Arrays.stream(args).map(Class::getName).collect(Collectors.joining(",")) + "]"; > 87: throw new TestRunException("Could not find method " + name + " in " + c + parameters); I'd pass `e` (`NSME`) to `TestRunException::` so the info in it won't be lost test/lib/jdk/test/lib/hotspot/ir_framework/Argument.java line 80: > 78: * Float and double values are restricted to the range [-10000,10000]. > 79: */ > 80: RANDOM_EACH nit: I'd put a trailing comma here, so the future additions will have lesser chance for a merge conflict test/lib/jdk/test/lib/hotspot/ir_framework/CheckAt.java line 42: > 40: * and the framework has compiled the associated {@link Test} method. > 41: */ > 42: COMPILED nit: trailing comma test/lib/jdk/test/lib/hotspot/ir_framework/CompLevel.java line 65: > 63: * Compilation level 1: C1 compilation without any profile information. > 64: */ > 65: C1(1), this name might be misleading, as one can assume that it means all C1 levels, `C1_SIMPLE`? test/lib/jdk/test/lib/hotspot/ir_framework/CompLevel.java line 77: > 75: * Compilation level 4: C2 compilation with full optimizations. > 76: */ > 77: C2(4); nit: Suggestion: C2(4), ; test/lib/jdk/test/lib/hotspot/ir_framework/DeclaredTest.java line 90: > 88: argumentValString += " (" + (int)(Character)argumentVal + ")"; > 89: } > 90: builder.append("arg ").append(i).append(": ").append(argumentValString).append(", "); you can avoid extra string concatination: Suggestion: builder.append("arg ").append(i).append(": ").append(argumentVal.toString()); if (argumentVal instanceof Character) { builder.append(" (").append((int)(Character)argumentVal).append(")"); } builder..append(", "); test/lib/jdk/test/lib/hotspot/ir_framework/DontCompile.java line 39: > 37: *

  • The usage of any other compilation level is forbidden and results in a > 38: * {@link TestFormatException TestFormatException}.

    • > 39: * this actually suggests that we shouldn't use `CompLevel` here and need to introduce another enum to denote compilers. test/lib/jdk/test/lib/hotspot/ir_framework/ForceCompile.java line 44: > 42: * {@link TestFormatException}. > 43: *

  • {@link CompLevel#WAIT_FOR_COMPILATION}: Does not apply to {@code @ForceCompile} and results in a > 44: * {@link TestFormatException}.

    • the same comment as in `ForceCompileClassInitializer.java` test/lib/jdk/test/lib/hotspot/ir_framework/ForceCompileClassInitializer.java line 44: > 42: * {@link TestFormatException}. > 43: *

  • {@link CompLevel#WAIT_FOR_COMPILATION}: Does not apply to {@code @ForceCompileClassInitializer} and results in a > 44: * {@link TestFormatException}.

    • I don't think you should list all `CompLevel` here as this increases maintenance cost (if/when we update CompLevel) for little to no gain, I'd just mention that `SKIP` and `WAIT_FOR_COMPILATION` are inapplicable here. test/lib/jdk/test/lib/hotspot/ir_framework/IRMatcher.java line 39: > 37: class IRMatcher { > 38: private static final boolean PRINT_IR_ENCODING = Boolean.parseBoolean(System.getProperty("PrintIREncoding", "false")); > 39: private static final Pattern irEncodingPattern = we typically use UPPER_CAMEL_CASE for constants such as `irEncodingPattern` test/lib/jdk/test/lib/hotspot/ir_framework/IRMatcher.java line 54: > 52: > 53: public IRMatcher(String hotspotPidFileName, String irEncoding, Class testClass) { > 54: this.compilations = new HashMap<>(); nite: double space b/w `=` and `new` test/lib/jdk/test/lib/hotspot/ir_framework/IRMatcher.java line 127: > 125: private void parseHotspotPidFile() { > 126: Map compileIdMap = new HashMap<>(); > 127: try (BufferedReader br = Files.newBufferedReader(Paths.get(hotspotPidFileName))) { nit: I'd use `var` here, and it seems this would reduce classes imported from `java.io` to just `IOException`, so we could change L#26 to an explicit import. Suggestion: try (var br = Files.newBufferedReader(Paths.get(hotspotPidFileName))) { test/lib/jdk/test/lib/hotspot/ir_framework/IRNode.java line 132: > 130: > 131: static List mergeNodes(String[] nodes) { > 132: final List mergedNodes = new ArrayList<>(); nit: I don't see any reasons for this var to be `final`. test/lib/jdk/test/lib/hotspot/ir_framework/RunMode.java line 42: > 40: * method. > 41: */ > 42: STANDALONE nit: a trailing comma test/lib/jdk/test/lib/hotspot/ir_framework/Scenario.java line 55: > 53: static { > 54: if (!SCENARIOS_PROPERTY.isEmpty()) { > 55: System.out.println(Arrays.toString(SCENARIOS_PROPERTY.split("\\s*,\\s*"))); did you mean to print it here or was it just a leftover from a debugging session? test/lib/jdk/test/lib/hotspot/ir_framework/Scenario.java line 62: > 60: + "a number: " + SCENARIOS_PROPERTY); > 61: } > 62: } a more idiomatic way to do that would be to remove initialization of `ENABLED_SCENARIOS` at L46 and do: Suggestion: if (!SCENARIOS_PROPERTY.isEmpty()) { var split = SCENARIOS_PROPERTY.split("\\s*,\\s*"); System.out.println(Arrays.toString(split)); try { ENABLED_SCENARIOS = Arrays.stream(split).map(Integer::parseInt).collect(Collectors.toList()); } catch (NumberFormatException e) { throw new TestRunException("Provided a scenario index in the -DScenario comma-separated list which is not " + "a number: " + SCENARIOS_PROPERTY); } } else { ENABLED_SCENARIOS = Collections.emptyList(); } test/lib/jdk/test/lib/hotspot/ir_framework/Scenario.java line 66: > 64: if (!ADDITIONAL_SCENARIO_FLAGS_PROPERTY.isEmpty()) { > 65: ADDITIONAL_SCENARIO_FLAGS.addAll(Arrays.asList(ADDITIONAL_SCENARIO_FLAGS_PROPERTY.split("\\s*,\\s*"))); > 66: } similar comment, this can be replaced by just: Suggestion: ADDITIONAL_SCENARIO_FLAGS = ADDITIONAL_SCENARIO_FLAGS_PROPERTY.isEmpty() ? Collections.emptyList() : Arrays.asList(ADDITIONAL_SCENARIO_FLAGS_PROPERTY.split("\\s*,\\s*")); test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 135: > 133: - To only run the failed tests use -DTest, -DExclude, > 134: and/or -DScenarios. > 135: - To also get the standard output of the test VM run with\s why do you need `\s` here? test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 146: > 144: private static final boolean REPORT_STDOUT = Boolean.getBoolean("ReportStdout"); > 145: private final boolean VERIFY_VM = Boolean.getBoolean("VerifyVM") && Platform.isDebugBuild(); > 146: private boolean VERIFY_IR = Boolean.parseBoolean(System.getProperty("VerifyIR", "true")); it seems both these guys were meant to be `static final` test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 156: > 154: private List scenarios = null; > 155: private Set scenarioIndices = null; > 156: private List flags = null; `null` is a default value for reference types, so there is no need to set it explicitly. ------------- PR: https://git.openjdk.java.net/jdk/pull/3508 From iignatyev at openjdk.java.net Mon Apr 26 19:18:44 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Mon, 26 Apr 2021 19:18:44 GMT Subject: RFR: 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests [v2] In-Reply-To: References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> Message-ID: <8m3dztYNNjO9ZHKSoyH3-YOtwFbKpMyn8WPgnxZRV-Q=.a07c3878-4567-4c43-b732-515fa750a6b2@github.com> On Mon, 19 Apr 2021 15:34:27 GMT, Igor Ignatyev wrote: >>> * although having javadoc for testlibraries is highly desirable, I don't think we should check in the generated HTML files >>> * the same goes for `README.html` generated from `README.md` >> >> Okay, I will remove them. Does it make sense to still have the HTML files somewhere in the web, for example, on my cr.openjdk? >> >>> * this library is hotspot-centric, I highly doubt that it will be used by any tests outside of the hotspot test base, hence the more appropriate location for it would be inside `test/hotspot/jtreg/testlibrary`. >>> * I assume `test/lib/jdk/test/lib/hotspot/ir_framework/tests/` are the tests for the framework, in that case they should be in `test/lib-test`, if we stick to `test/lib` as the location for the library, or in `test/hotspot/jtreg/testlibrary_tests`, if we move it to `test/hotspot` >> >> That makes sense to move everything to `test/hotspot/jtreg/testlibrary`. Right, the `test/lib/jdk/test/lib/hotspot/ir_framework/tests/` are only tests for the framework itself and should not be run as part of tier testing each time (does not make much sense) but only when the framework is actually modified. Is this still the case when putting them in `test/hotspot/jtreg/testlibrary_tests` (i.e. not executed unless run manually)? >> >> I will do this things in a separate commit and adjust the README.md file accordingly (has links to the Javadoc files). > >> > * although having javadoc for testlibraries is highly desirable, I don't think we should check in the generated HTML files >> > * the same goes for `README.html` generated from `README.md` >> >> Okay, I will remove them. Does it make sense to still have the HTML files somewhere in the web, for example, on my cr.openjdk? >> >> > * this library is hotspot-centric, I highly doubt that it will be used by any tests outside of the hotspot test base, hence the more appropriate location for it would be inside `test/hotspot/jtreg/testlibrary`. >> > * I assume `test/lib/jdk/test/lib/hotspot/ir_framework/tests/` are the tests for the framework, in that case they should be in `test/lib-test`, if we stick to `test/lib` as the location for the library, or in `test/hotspot/jtreg/testlibrary_tests`, if we move it to `test/hotspot` >> >> That makes sense to move everything to `test/hotspot/jtreg/testlibrary`. Right, the `test/lib/jdk/test/lib/hotspot/ir_framework/tests/` are only tests for the framework itself and should not be run as part of tier testing each time (does not make much sense) but only when the framework is actually modified. Is this still the case when putting them in `test/hotspot/jtreg/testlibrary_tests` (i.e. not executed unless run manually)? > > `test/hotspot/jtreg/testlibrary_tests` are seldomly run as part of `:hotspot_misc` test group, yet I don't think it's an issue. the benefit of running testlibrary tests is to gain confidence that the tests which use these libraries are reliable. I'd also disagree that `ir_framework/tests` should be run *only* when the framework is actually, they should also be run when its dependencies are changed, and the framework highly depends on hotspot, so to be sure that the framework didn't get broken after changes in c2, whitebox, etc, you do need run these tests more often. > > Thanks, > -- Igor > There is no decision, yet, (and open for discussion) about the location and package name for the framework and the framework internal tests. After discussing it offline with @iignatev, we think there are basically two good options: > > 1. Leave the framework in `/test/lib` and put the framework internal tests into `/test/lib-test`: > > * Pros: Only need to specify `@library /test/lib` in a JTreg test; the framework internal tests are run in tier1 before any other tests are run which depend on the framework ensuring correctness. > * Cons: Clarity: The framework is intended to be used for HotSpot tests only (thus not exactly the right location in `/test/lib`); the framework internal tests might be run too often as part of tier1 (trade-off ensuring correctness vs. execution time). > 2. Move the framework to `/test/hotspot/jtreg/testlibrary`, put the framework internal tests into `/test/hotspot/jtreg/testlibrary_tests`, and use package name `hotspot.test.lib.ir_framework`: > > * Pros: Clarity: The framework is only used for HotSpot tests (mainly compiler tests but could also be used for other tests). > * Cons: A JTreg test needs to additionally specify `/testlibrary/ir_framework` like `@library /testlibrary/ir_framework /test/lib`; the framework internal tests are run more seldomly as part of `:hotspot_misc` (trade-off, see cons of first option). > there is also 3rd alternative, move the framework to `/test/hotspot/jtreg/compiler/` and use `compiler.ir_framework` or `compiler.lib.ir_framework` as the package name. that will make it even clearer that this is a compiler-specific library, and its users are going to be in `/test/hotspot/jtreg/compiler/`. I understand that there can be some runtime (or other) tests that might benefit from this library, but in the end, they won't be clear runtime tests, so `t/h/j/compiler` might be a better location for them anyways. the `@library` tag will still have to contain two paths, but these will be usual paths as in many compiler tests : `@library / /test/lib`. the tests can be placed in `/test/hotspot/jtreg/testlibrary_tests` as in the 2nd option, with the same trade-off. -- Igor ------------- PR: https://git.openjdk.java.net/jdk/pull/3508 From xliu at openjdk.java.net Mon Apr 26 20:48:38 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Mon, 26 Apr 2021 20:48:38 GMT Subject: RFR: 8229517: Support for optional asynchronous/buffered logging [v9] In-Reply-To: References: Message-ID: <9NrS00PFPoWlahBK0TCWHRTNWYGKePcVkYPEnr6Dtm4=.f8f9c9a4-fc98-4108-8a38-734e21d4b1d9@github.com> On Fri, 23 Apr 2021 23:29:48 GMT, Xin Liu wrote: >> This patch provides a buffer to store asynchrounous messages and flush them to >> underlying files periodically. > > Xin Liu has updated the pull request incrementally with two additional commits since the last revision: > > - Fix bugs/style/typo based on reviewers' feedbacks. > - Accurate Decorations for AsyncLogging. > > A lightweight LogDecorationRef is created to keep LogDecorations at > logging site. It uses refcnt to keep track multiple usage and > automatically clean up. If no decorator is in use, no LogDecorationRef > is created. ### Integration Test We understand that a feature is useless or even harmful if it's buggy. In addition to the gtest in this PR, we also set up an integration tests to verify it. 1. The full-brunt logging in an entire jvm lifecycle The following command dump **all** logs in trace verbosity in async logging mode. There are 13k messages and no one is dropped from [0.004s] to [0.087s] > time ./build/linux-x86_64-server-release/images/jdk/bin/java -Xlog:'all=trace:file=hotspot.log:uptime,tid,l,tg:filecount=0,async=true' --version $wc -l hotspot.log 13386 hotspot.log $grep "messages dropped" hotspot.log -n 2. Gclog test We directly use the testcase in linkedin whitepaper[1]. [Test.java](https://github.com/navyxliu/JavaGCworkload/blob/master/Test.java) launches N threads and each one churns up java heap by allocating String objects. We use the default gc(G1GC) of jdk17. The following command runs infinite time with 10g heap. It launches 4 threads and dump gc logs in trace verbosity. > java -Xmx10g -Xms10g -Xlog:gc=trace:file=gc.log::async=true Test -1 4 We have been running it over a week and no message is drop. 3. Gclog test with dropping messages The following command still uses Test.java introduced in prior test, it dumps all logset as long as it contains `gc`. IIUC, it simulates `-XX:+PrintGCDetails`. It still starts 4 threads and the test ends in 180s. > java -Xmx10g -Xms10g -Xlog:'gc*=trace:file=gc-star.log::async=true' Test 180 4 Log rotation works correctly. Give the verbose log and intense gc activities, we do observe some logs dropped. In gc-star.log.0, whose timestamp is from [11445.736s] to [11449.168s], it totally drops 4717 messages out of 130224, or 3.6% messages are ditched. No message is dropped after we enlarge the buffer to -XX:AsyncLogBufferSize=102400. In debug build, hotspot will dump dropping messages to tty console with `-XX:+Verbose`. 4. Gclog test with dynamical reconfiguration While running Test 3, we can dynamically reconfigure logs using jcmd VM.log We use a [script](https://github.com/navyxliu/JavaGCworkload/blob/master/jcmd_test.sh) to disable all outputs and re-create a file-based output in async mode. We periodic ran the script in a day and no problem has been identified. 5. Gclog test with NMT the following command is same as 3 plus `-XX:NativeMemoryTracking=summary` > java -Xmx10g -Xms10g -Xlog:'gc*=trace:file=gc-star.log::async=true' -XX:NativeMemoryTracking=summary Test -1 4 We use a [script](https://github.com/navyxliu/JavaGCworkload/blob/master/monitor_nmt.sh) to monitor NMT summary. All offheap allocation are marked "mtLogging". We don't observe memory leak on Logging category in long-haul running. We also ran asynchorous logging in Minecraft 1.16.5 on both Linux and MacOS. No problem has been captured yet. [1] https://engineering.linkedin.com/blog/2016/02/eliminating-large-jvm-gc-pauses-caused-by-background-io-traffic ------------- PR: https://git.openjdk.java.net/jdk/pull/3135 From minqi at openjdk.java.net Mon Apr 26 20:50:04 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Mon, 26 Apr 2021 20:50:04 GMT Subject: RFR: 8255493: Support for pre-generated java.lang.invoke classes in CDS dynamic archive [v2] In-Reply-To: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> References: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> Message-ID: > Hi, Please review > > When do dynamic dump, the pre-generated lambda form classes from java.lang.invoke are not stored in dynamic archive. The patch will regenerate the four holder classes, > "java.lang.invoke.Invokers$Holder", > "java.lang.invoke.DirectMethodHandle$Holder", > "java.lang.invoke.DelegatingMethodHandle$Holder", > "java.lang.invoke.LambdaForm$Holder" > which will include the versions in static archive and new loaded functions all together and stored in dynamic archive. New test case added. > (Minor change to PrintSharedArchiveAtExit, which the index is not consecutive) > > Tests: tier1,tier2,tier3,tier4 > > Thanks > Yumin Yumin Qi has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Serialize lambdafor invokers in readonly talbe, merged with master - Merge branch 'master' into jdk-8255493 - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8255493 - 8255493: Support for pre-generated java.lang.invoke classes in CDS dynamic archive ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3611/files - new: https://git.openjdk.java.net/jdk/pull/3611/files/008c1d0a..e437c902 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3611&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3611&range=00-01 Stats: 11424 lines in 557 files changed: 5864 ins; 3387 del; 2173 mod Patch: https://git.openjdk.java.net/jdk/pull/3611.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3611/head:pull/3611 PR: https://git.openjdk.java.net/jdk/pull/3611 From coleenp at openjdk.java.net Mon Apr 26 21:01:34 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Mon, 26 Apr 2021 21:01:34 GMT Subject: RFR: 8265867: thread.hpp defines some enums but no reference In-Reply-To: References: Message-ID: On Mon, 26 Apr 2021 18:54:37 GMT, Xin Liu wrote: > Deleted 2 useless enums. > This patch also added const and constexpr for the applicable member functions. src/hotspot/share/gc/shared/threadLocalAllocBuffer.hpp line 189: > 187: static constexpr ByteSize end_offset() { return byte_offset_of(ThreadLocalAllocBuffer, _end); } > 188: static constexpr ByteSize top_offset() { return byte_offset_of(ThreadLocalAllocBuffer, _top); } > 189: static constexpr ByteSize pf_top_offset() { return byte_offset_of(ThreadLocalAllocBuffer, _pf_top); } Is constexpr really necessary here? Isn't this usually a constant expression for most compilers? ------------- PR: https://git.openjdk.java.net/jdk/pull/3702 From ayang at openjdk.java.net Mon Apr 26 21:08:55 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Mon, 26 Apr 2021 21:08:55 GMT Subject: RFR: 8234020: Remove FullGCCount_lock [v2] In-Reply-To: References: Message-ID: > Remove an unused method and unnecessary synchronization in Serial GC. Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: review ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3679/files - new: https://git.openjdk.java.net/jdk/pull/3679/files/536cde17..232c64f7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3679&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3679&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3679.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3679/head:pull/3679 PR: https://git.openjdk.java.net/jdk/pull/3679 From kevinw at openjdk.java.net Mon Apr 26 21:12:36 2021 From: kevinw at openjdk.java.net (Kevin Walls) Date: Mon, 26 Apr 2021 21:12:36 GMT Subject: RFR: 8264593: debug.cpp utilities should be available in product builds. In-Reply-To: References: Message-ID: On Mon, 26 Apr 2021 15:37:55 GMT, Coleen Phillimore wrote: >> This is a pull request to move the ifndef PRODUCT in src/hotspot/share/utilities/debug.cpp, and add JNIEXPORT for symbol visibility on Windows. >> >> With these changes, we can use gdb on a live Linux process of a product build JVM, and call debug.cpp utilities. >> e.g. "call universe()", or "call hsfind(0xADDRESS)". >> >> (I found that making calls in the JLI_Launch thread (gdb's thread 1) will crash, but switching first to a JavaThread works.) >> >> In Visual Studio use the Immediate window, just type the function name. Verified that without the changes, the symbols can't be seen/called. >> >> Printing happens on the LIVE jvm's tty (not the gdb session). >> >> >> WizardMode is a develop flag, can't be changed in a product build, so avoid changing that in the debug() utility. >> >> >> pa() is left ifndef PRODUCT, as the class AllocatedObj is ifndef PRODUCT in src/hotspot/share/memory/allocation.hpp >> >> >> pns(...) uses frame fr(sp, fp, pc); but we have an ifndef PRODUCT on frame constructor: frame(void* sp, void* fp, void* pc); >> Leave pns and pns2 ifndef PRODUCT. >> >> >> File size changes: >> Linux: libjvm.so becomes 8904 bytes larger. >> Windows: jvm.dll becomes 6656 bytes larger. > > src/hotspot/share/utilities/debug.cpp line 495: > >> 493: // AllocatedObj in allocation.hpp is not defined for PRODUCT >> 494: extern "C" JNIEXPORT void pa(intptr_t p) { ((AllocatedObj*) p)->print(); } >> 495: #endif > > I don't really think 'pa' is interesting enough to keep. Thanks Coleen - I haven't used pa either. Will update without it... ------------- PR: https://git.openjdk.java.net/jdk/pull/3307 From kvn at openjdk.java.net Mon Apr 26 22:45:25 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Mon, 26 Apr 2021 22:45:25 GMT Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v6] In-Reply-To: References: Message-ID: > As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: > > - `jdk.aot` module ? the `jaotc` tool > - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution > - related HotSpot code guarded by `#if INCLUDE_AOT` > > Additionally, remove tests as well as code in makefiles related to AoT compilation. > > Tested hs-tier1-4 Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Merge branch 'master' into JDK-8264805 - Address review comments - Remove exports from Graal module to jdk.aot - Merge branch 'master' into JDK-8264805 - Merge branch 'master' into JDK-8264805 - 8264805: Remove the experimental Ahead-of-Time Compiler ------------- Changes: https://git.openjdk.java.net/jdk/pull/3398/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3398&range=05 Stats: 26972 lines in 378 files changed: 2 ins; 26772 del; 198 mod Patch: https://git.openjdk.java.net/jdk/pull/3398.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3398/head:pull/3398 PR: https://git.openjdk.java.net/jdk/pull/3398 From iklam at openjdk.java.net Mon Apr 26 23:11:41 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 26 Apr 2021 23:11:41 GMT Subject: RFR: 8265867: thread.hpp defines some enums but no reference In-Reply-To: References: Message-ID: <0AxHkbXhMW-Wn6ee_CyHG0aRVEeCvHmtQbxmbVNzuz0=.7acdc568-a11f-410d-8345-5c3566154355@github.com> On Mon, 26 Apr 2021 20:58:47 GMT, Coleen Phillimore wrote: >> Deleted 2 useless enums. >> This patch also added const and constexpr for the applicable member functions. > > src/hotspot/share/gc/shared/threadLocalAllocBuffer.hpp line 189: > >> 187: static constexpr ByteSize end_offset() { return byte_offset_of(ThreadLocalAllocBuffer, _end); } >> 188: static constexpr ByteSize top_offset() { return byte_offset_of(ThreadLocalAllocBuffer, _top); } >> 189: static constexpr ByteSize pf_top_offset() { return byte_offset_of(ThreadLocalAllocBuffer, _pf_top); } > > Is constexpr really necessary here? Isn't this usually a constant expression for most compilers? We have many of these inline functions that could be either `const` and `constexpr`. Since `constexpr` has been allowed only recently, there are very few functions that are actually declared `constexpr`. My recommendation is to limit `constexpr` only to new code. We can change `const` to `constexpr` when required (e.g., when an existing function is called by new code that's in a `constexpr` context). That way, we can limit code churn. ------------- PR: https://git.openjdk.java.net/jdk/pull/3702 From iklam at openjdk.java.net Mon Apr 26 23:32:37 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Mon, 26 Apr 2021 23:32:37 GMT Subject: RFR: 8255493: Support for pre-generated java.lang.invoke classes in CDS dynamic archive [v2] In-Reply-To: References: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> Message-ID: On Mon, 26 Apr 2021 20:50:04 GMT, Yumin Qi wrote: >> Hi, Please review >> >> When do dynamic dump, the pre-generated lambda form classes from java.lang.invoke are not stored in dynamic archive. The patch will regenerate the four holder classes, >> "java.lang.invoke.Invokers$Holder", >> "java.lang.invoke.DirectMethodHandle$Holder", >> "java.lang.invoke.DelegatingMethodHandle$Holder", >> "java.lang.invoke.LambdaForm$Holder" >> which will include the versions in static archive and new loaded functions all together and stored in dynamic archive. New test case added. >> (Minor change to PrintSharedArchiveAtExit, which the index is not consecutive) >> >> Tests: tier1,tier2,tier3,tier4 >> >> Thanks >> Yumin > > Yumin Qi has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Serialize lambdafor invokers in readonly talbe, merged with master > - Merge branch 'master' into jdk-8255493 > - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8255493 > - 8255493: Support for pre-generated java.lang.invoke classes in CDS dynamic archive Changes requested by iklam (Reviewer). src/hotspot/share/cds/lambdaFormInvokers.cpp line 90: > 88: int len = _lambdaform_lines->length(); > 89: objArrayHandle list_lines = oopFactory::new_objArray_handle(vmClasses::String_klass(), len, CHECK); > 90: if (list_lines == nullptr) { There's no need to check for null. If allocation fails, the CHECK in the previous line will force this function to return. (same for the check on line 96). src/hotspot/share/cds/lambdaFormInvokers.cpp line 137: > 135: // make a copy of class bytes so GC will not affect us. > 136: char *buf = resource_allocate_bytes(THREAD, len); > 137: if (buf == nullptr) { `resource_allocate_bytes(THREAD, len)` by default uses `AllocFailStrategy::EXIT_OOM`. We should explicitly pass `RETURN_NULL` instead. Also, the `resource_free_bytes` call below doesn't seem necessary. The buffer will be freed when the ResourceMark is popped. src/hotspot/share/cds/metaspaceShared.cpp line 1466: > 1464: LambdaFormInvokers::append_filtered(str); > 1465: } > 1466: } I think the above block should be moved into lambdaFormInvokers.cpp ------------- PR: https://git.openjdk.java.net/jdk/pull/3611 From coleenp at openjdk.java.net Tue Apr 27 00:38:37 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 27 Apr 2021 00:38:37 GMT Subject: RFR: 8265867: thread.hpp defines some enums but no reference In-Reply-To: <0AxHkbXhMW-Wn6ee_CyHG0aRVEeCvHmtQbxmbVNzuz0=.7acdc568-a11f-410d-8345-5c3566154355@github.com> References: <0AxHkbXhMW-Wn6ee_CyHG0aRVEeCvHmtQbxmbVNzuz0=.7acdc568-a11f-410d-8345-5c3566154355@github.com> Message-ID: <7jo2q2G2UWhUi23Kg0Q2DhckxBaalaxEx1tGgrGicJ0=.6a06df9a-9170-41c9-a917-177976102bfe@github.com> On Mon, 26 Apr 2021 23:08:13 GMT, Ioi Lam wrote: >> src/hotspot/share/gc/shared/threadLocalAllocBuffer.hpp line 189: >> >>> 187: static constexpr ByteSize end_offset() { return byte_offset_of(ThreadLocalAllocBuffer, _end); } >>> 188: static constexpr ByteSize top_offset() { return byte_offset_of(ThreadLocalAllocBuffer, _top); } >>> 189: static constexpr ByteSize pf_top_offset() { return byte_offset_of(ThreadLocalAllocBuffer, _pf_top); } >> >> Is constexpr really necessary here? Isn't this usually a constant expression for most compilers? > > We have many of these inline functions that could be either `const` and `constexpr`. Since `constexpr` has been allowed only recently, there are very few functions that are actually declared `constexpr`. > > My recommendation is to limit `constexpr` only to new code. We can change `const` to `constexpr` when required (e.g., when an existing function is called by new code that's in a `constexpr` context). That way, we can limit code churn. I agree and it's more characters to look at for no real performance benefit. These offset functions are in many classes. ------------- PR: https://git.openjdk.java.net/jdk/pull/3702 From github.com+2249648+johntortugo at openjdk.java.net Tue Apr 27 01:02:44 2021 From: github.com+2249648+johntortugo at openjdk.java.net (John Tortugo) Date: Tue, 27 Apr 2021 01:02:44 GMT Subject: RFR: 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests [v6] In-Reply-To: References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> Message-ID: <1MYGXgT-l5ghB-P0sQ7V1YcH3KmqPVra8pnjjWpJIOo=.c7a271c2-01dc-448e-ac95-22d7d30af0af@github.com> On Fri, 23 Apr 2021 12:39:32 GMT, Christian Hagedorn wrote: >> This RFE provides an IR test framework to perform regex-based checks on the C2 IR shape of test methods emitted by the VM flags `-XX:+PrintIdeal` and `-XX:+PrintOptoAssembly`. The framework can also be used for other non-IR matching (and non-compiler) tests by providing easy to use annotations for commonly used testing patterns and compiler control flags. >> >> The framework is based on the ideas of the currently present IR test framework in [Valhalla](https://github.com/openjdk/valhalla/blob/e9c78ce4fcfd01361c35883e0d68f9ae5a80d079/test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypeTest.java) (mainly implemented by @TobiHartmann) which is being used with great success. This new framework aims to replace the old one in Valhalla at some point. >> >> A detailed description about how this new IR test framework works and how it is used is provided in the [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) file and in the [Javadocs](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc/jdk/test/lib/hotspot/ir_framework/package-summary.html) written for the framework classes. >> >> To finish a first version of this framework for JDK 17, I decided to leave some improvement possibilities and ideas to be followed up on in additional RFEs. Some ideas are mentioned in "Future Work" in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) and were also created as subtasks of this RFE. >> >> Testing (also described in "Internal Framework Tests in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md)): >> There are various tests to verify the correctness of the test framework which can be found as JTreg tests in the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) folder. Additional testing was performed by converting all compiler Inline Types test of project Valhalla (done by @katyapav in [JDK-8263024](https://bugs.openjdk.java.net/browse/JDK-8263024)) that used the old framework to the new framework. This provided additional testing for the framework itself. We ran the converted tests with all the flag settings used in hs-tier1-9 and hs-precheckin-comp. For sanity checking, this was also done with a sample IR test in mainline. >> >> Some stats about the framework code added to [ir_framework](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework): >> >> - without the [Javadocs files](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc) : 60 changed files, 13212 insertions, 0 deletions. >> - without the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) and [examples](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/examples) folder: 40 files changed, 6781 insertions >> - comments: 2399 insertions (calculated with `git diff --cached !(tests|examples) | grep -c -E "(^[+-]\s*(/)?*)|(^[+-]\s*//)"`) >> - which leaves 4382 lines of code inserted >> >> Big thanks to: >> - @TobiHartmann for all his help by discussing the new framework and for providing insights from his IR test framework in Valhalla. >> - @katyapav for converting the Valhalla tests to use the new framework which found some harder to catch bugs in the framework and also some actual C2 bugs. >> - @iignatev for helping to simplify the framework usage with JTreg and with the framework internal VM calling structure. >> - and others who provided valuable feedback. >> >> Thanks, >> Christian > > Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: > > Review comments by Tobias: Formatting fields, spacing, README.md typos and cleanup test/lib/jdk/test/lib/hotspot/ir_framework/Run.java line 96: > 94: public @interface Run { > 95: /** > 96: * The associated {@link Test @Test} methods (one or more) for for this {@code @Run} annotated run method. Typo: "for for" test/lib/jdk/test/lib/hotspot/ir_framework/TestFrameworkExecution.java line 149: > 147: String testClassName = args[0]; > 148: System.out.println("Framework main(), about to run tests in class " + testClassName); > 149: Class testClass; Merge this and next line? test/lib/jdk/test/lib/hotspot/ir_framework/TestFrameworkExecution.java line 163: > 161: Class c; > 162: try { > 163: c = Class.forName(className); Maybe just return "Class.forName(className)" here? test/lib/jdk/test/lib/hotspot/ir_framework/TestFrameworkExecution.java line 174: > 172: */ > 173: private void addHelperClasses(String[] args) { > 174: Class[] helperClasses = getHelperClasses(args); It's a bit confusing that this local variable has the same name as the class property. test/lib/jdk/test/lib/hotspot/ir_framework/TestFrameworkExecution.java line 308: > 306: > 307: private void processControlAnnotations(Class clazz) { > 308: if (!XCOMP) { Perhaps transform this condition on an early return, i.e., "if (XCOMP) return ;", instead of nesting the whole method under the if. test/lib/jdk/test/lib/hotspot/ir_framework/TestFrameworkExecution.java line 340: > 338: private void applyClassAnnotations(Class c) { > 339: ForceCompileClassInitializer anno = getAnnotation(c, ForceCompileClassInitializer.class); > 340: if (anno != null) { Transform to early return? test/lib/jdk/test/lib/hotspot/ir_framework/TestFrameworkExecution.java line 373: > 371: boolean exclude = random.nextBoolean(); > 372: CompLevel level = CompLevel.ANY; > 373: if (exclude) { Transform to early return? test/lib/jdk/test/lib/hotspot/ir_framework/TestFrameworkExecution.java line 378: > 376: case 1 -> { > 377: level = CompLevel.C1; > 378: WHITE_BOX.makeMethodNotCompilable(ex, CompLevel.C2.getValue(), false); I'm curious why two calls (with different values for the last parameter) are needed for these? test/lib/jdk/test/lib/hotspot/ir_framework/TestFrameworkExecution.java line 591: > 589: } > 590: > 591: private static CompLevel flipCompLevel(CompLevel compLevel) { Wouldn't be better to put this on the CompLevel enum itself? ------------- PR: https://git.openjdk.java.net/jdk/pull/3508 From kvn at openjdk.java.net Tue Apr 27 01:15:37 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Tue, 27 Apr 2021 01:15:37 GMT Subject: Integrated: 8264805: Remove the experimental Ahead-of-Time Compiler In-Reply-To: References: Message-ID: <3MIAR4n0RJot9rerXkZf7hB7NlYhJbPI6ri5q9IP3SM=.c6fecb4a-0d84-4c78-bf41-b750ee03d6df@github.com> On Thu, 8 Apr 2021 15:23:52 GMT, Vladimir Kozlov wrote: > As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: > > - `jdk.aot` module ? the `jaotc` tool > - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution > - related HotSpot code guarded by `#if INCLUDE_AOT` > > Additionally, remove tests as well as code in makefiles related to AoT compilation. > > Tested hs-tier1-4 This pull request has now been integrated. Changeset: 694acedf Author: Vladimir Kozlov URL: https://git.openjdk.java.net/jdk/commit/694acedf Stats: 26972 lines in 378 files changed: 2 ins; 26772 del; 198 mod 8264805: Remove the experimental Ahead-of-Time Compiler Reviewed-by: coleenp, erikj, stefank, iignatyev, dholmes, aph, shade, iklam, mchung, iveresov ------------- PR: https://git.openjdk.java.net/jdk/pull/3398 From dholmes at openjdk.java.net Tue Apr 27 02:07:34 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 27 Apr 2021 02:07:34 GMT Subject: RFR: 8265867: thread.hpp defines some enums but no reference In-Reply-To: References: Message-ID: On Mon, 26 Apr 2021 18:54:37 GMT, Xin Liu wrote: > Deleted 2 useless enums. > This patch also added const and constexpr for the applicable member functions. Hi Xin, Please don't mix together cleanups this way. Getting rid of unused enums is fine, but 99% of the patch relates to const and constexpr. I had trouble finding the enum changes among the rest, and what would otherwise be a short and trivial patch becomes more unweildy and requires a lot more time to review. A separate RFE for those would be better IMO. Thanks, David ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3702 From kvn at openjdk.java.net Tue Apr 27 02:18:40 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Tue, 27 Apr 2021 02:18:40 GMT Subject: RFR: 8264806: Remove the experimental JIT compiler [v4] In-Reply-To: References: Message-ID: <0mJY3m49euRLBowk0WfgXqx6bGSqNJFykEXZdJ9cO6k=.87753850-16f7-4c15-b526-c29898caf5ac@github.com> > As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK: > > - `jdk.internal.vm.compiler` ? the Graal compiler > - `jdk.internal.vm.compiler.management` ? Graal's `MBean` > - `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests > > Remove Graal related code in makefiles. > > Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build: > > src/jdk.internal.vm.compiler/share/classes/module-info.java > src/jdk.internal.vm.compiler.management/share/classes/module-info.java > > > @AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it. > > Tested hs-tier1-4 Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: - Merge branch 'JDK-8264805' into JDK-8264806 - Merge branch 'master' into JDK-8264805 - Restore Compiler::isGraalEnabled() - Restore Graal Builder image makefile - Merge latest changes from branch 'JDK-8264805' into JDK-8264806 - Address review comments - 8264806: Remove the experimental JIT compiler - Remove exports from Graal module to jdk.aot - Merge branch 'master' into JDK-8264805 - Merge branch 'master' into JDK-8264805 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/b524a81a...db7c9aaf ------------- Changes: https://git.openjdk.java.net/jdk/pull/3421/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3421&range=03 Stats: 468493 lines in 3247 files changed: 2 ins; 468290 del; 201 mod Patch: https://git.openjdk.java.net/jdk/pull/3421.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3421/head:pull/3421 PR: https://git.openjdk.java.net/jdk/pull/3421 From minqi at openjdk.java.net Tue Apr 27 04:14:05 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 27 Apr 2021 04:14:05 GMT Subject: RFR: 8255493: Support for pre-generated java.lang.invoke classes in CDS dynamic archive [v3] In-Reply-To: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> References: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> Message-ID: > Hi, Please review > > When do dynamic dump, the pre-generated lambda form classes from java.lang.invoke are not stored in dynamic archive. The patch will regenerate the four holder classes, > "java.lang.invoke.Invokers$Holder", > "java.lang.invoke.DirectMethodHandle$Holder", > "java.lang.invoke.DelegatingMethodHandle$Holder", > "java.lang.invoke.LambdaForm$Holder" > which will include the versions in static archive and new loaded functions all together and stored in dynamic archive. New test case added. > (Minor change to PrintSharedArchiveAtExit, which the index is not consecutive) > > Tests: tier1,tier2,tier3,tier4 > > Thanks > Yumin Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Move read static invoker lines to LambdaFormInokers, remove unneeded check for return NULL ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3611/files - new: https://git.openjdk.java.net/jdk/pull/3611/files/e437c902..9b5aa513 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3611&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3611&range=01-02 Stats: 32 lines in 3 files changed: 11 ins; 18 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3611.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3611/head:pull/3611 PR: https://git.openjdk.java.net/jdk/pull/3611 From minqi at openjdk.java.net Tue Apr 27 04:27:42 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 27 Apr 2021 04:27:42 GMT Subject: RFR: 8255493: Support for pre-generated java.lang.invoke classes in CDS dynamic archive [v2] In-Reply-To: References: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> Message-ID: On Mon, 26 Apr 2021 23:23:25 GMT, Ioi Lam wrote: >> Yumin Qi has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: >> >> - Serialize lambdafor invokers in readonly talbe, merged with master >> - Merge branch 'master' into jdk-8255493 >> - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8255493 >> - 8255493: Support for pre-generated java.lang.invoke classes in CDS dynamic archive > > src/hotspot/share/cds/lambdaFormInvokers.cpp line 137: > >> 135: // make a copy of class bytes so GC will not affect us. >> 136: char *buf = resource_allocate_bytes(THREAD, len); >> 137: if (buf == nullptr) { > > `resource_allocate_bytes(THREAD, len)` by default uses `AllocFailStrategy::EXIT_OOM`. We should explicitly pass `RETURN_NULL` instead. > > Also, the `resource_free_bytes` call below doesn't seem necessary. The buffer will be freed when the ResourceMark is popped. Done. > src/hotspot/share/cds/metaspaceShared.cpp line 1466: > >> 1464: LambdaFormInvokers::append_filtered(str); >> 1465: } >> 1466: } > > I think the above block should be moved into lambdaFormInvokers.cpp Done. ------------- PR: https://git.openjdk.java.net/jdk/pull/3611 From xliu at openjdk.java.net Tue Apr 27 04:42:37 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Tue, 27 Apr 2021 04:42:37 GMT Subject: RFR: 8265867: thread.hpp defines some enums but no reference In-Reply-To: References: Message-ID: <9NZEfZzYStFF22Nss1y9KHozSh-XYxdfjFu7TM4NKKc=.79aa88d6-4bfa-4db0-a769-eb259e5ee3c5@github.com> On Tue, 27 Apr 2021 02:05:08 GMT, David Holmes wrote: > Hi Xin, > > Please don't mix together cleanups this way. Getting rid of unused enums is fine, but 99% of the patch relates to const and constexpr. I had trouble finding the enum changes among the rest, and what would otherwise be a short and trivial patch becomes more unweildy and requires a lot more time to review. A separate RFE for those would be better IMO. > > Thanks, > David hi, David, Thanks. I will create another JBS to track const and constexpr issue. Sorry, I felt it was too "trivial" if one PR just deletes two enums. I will pay attention to it. thanks, --lx ------------- PR: https://git.openjdk.java.net/jdk/pull/3702 From kvn at openjdk.java.net Tue Apr 27 04:44:17 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Tue, 27 Apr 2021 04:44:17 GMT Subject: RFR: 8264806: Remove the experimental JIT compiler [v5] In-Reply-To: References: Message-ID: <9SR3Bnj0ywpPcSx4uU4G9oH7cXJv6dWPIkvyIb_rnKo=.30180267-aeb7-4ab3-947a-cdf80e62c81c@github.com> > As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK: > > - `jdk.internal.vm.compiler` ? the Graal compiler > - `jdk.internal.vm.compiler.management` ? Graal's `MBean` > - `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests > > Remove Graal related code in makefiles. > > Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build: > > src/jdk.internal.vm.compiler/share/classes/module-info.java > src/jdk.internal.vm.compiler.management/share/classes/module-info.java > > > @AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it. > > Tested hs-tier1-4 Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: - Merge branch 'master' into JDK-8264806 - Merge branch 'JDK-8264805' into JDK-8264806 - Merge branch 'master' into JDK-8264805 - Restore Compiler::isGraalEnabled() - Restore Graal Builder image makefile - Merge latest changes from branch 'JDK-8264805' into JDK-8264806 - Address review comments - 8264806: Remove the experimental JIT compiler - Remove exports from Graal module to jdk.aot - Merge branch 'master' into JDK-8264805 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/694acedf...b1e9ba63 ------------- Changes: https://git.openjdk.java.net/jdk/pull/3421/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3421&range=04 Stats: 441532 lines in 2884 files changed: 0 ins; 441518 del; 14 mod Patch: https://git.openjdk.java.net/jdk/pull/3421.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3421/head:pull/3421 PR: https://git.openjdk.java.net/jdk/pull/3421 From dholmes at openjdk.java.net Tue Apr 27 05:01:11 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 27 Apr 2021 05:01:11 GMT Subject: RFR: 8266017: Refactor the *klass::array_klass_impl code to separate the non-exception-throwing API Message-ID: We currently have array_klass() and array_klass_or_null(), where the former can throw exceptions and the latter can not. But they both delegate to: array_klass_impl(bool or_null, TRAPS) which combines both the exception-throwing and non-exception-throwing code into one method declared with TRAPS. To make progress with the change of TRAPS to JavaThread (JDK-8252685) we need to separate these code paths into distinct methods. Testing: tiers 1-3 (in progress) Thanks, David ------------- Commit messages: - 8266017: Refactor the *klass::array_klass_impl code to separate the non-exception-throwing API Changes: https://git.openjdk.java.net/jdk/pull/3711/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3711&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266017 Stats: 113 lines in 8 files changed: 69 ins; 21 del; 23 mod Patch: https://git.openjdk.java.net/jdk/pull/3711.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3711/head:pull/3711 PR: https://git.openjdk.java.net/jdk/pull/3711 From stuefe at openjdk.java.net Tue Apr 27 05:13:35 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Tue, 27 Apr 2021 05:13:35 GMT Subject: RFR: 8265867: thread.hpp defines some enums but no reference In-Reply-To: References: Message-ID: On Mon, 26 Apr 2021 18:54:37 GMT, Xin Liu wrote: > Deleted 2 useless enums. > This patch also added const and constexpr for the applicable member functions. I like this change (both the constness fixes and the removal of enums), but as David said, please make them two changes and give them clear titles. Wrt to the constexpr, I am not against this since constexpr is to my understanding mostly a safety measure against bitrot, preventing us from accidentally making a constexpr function non-const. But the majority seems not to like that part, so I'd just leave it out for now. Cheers, Thomas src/hotspot/share/runtime/thread.hpp line 1077: > 1075: // last_Java_sp > 1076: bool has_last_Java_frame() const { return _anchor.has_last_Java_frame(); } > 1077: intptr_t* last_Java_sp() const { return _anchor.last_Java_sp(); } Why the whitespace change? ------------- PR: https://git.openjdk.java.net/jdk/pull/3702 From kbarrett at openjdk.java.net Tue Apr 27 05:14:44 2021 From: kbarrett at openjdk.java.net (Kim Barrett) Date: Tue, 27 Apr 2021 05:14:44 GMT Subject: RFR: JDK-8260332: ParallelGC: Cooperative pretouch for oldgen expansion [v4] In-Reply-To: References: Message-ID: <5sjdcyjz3-64_zVVbfXxx9r6DlzYaHJ2a0-PWHUgpPU=.5ab268ec-d525-49d8-b672-b8c58ef21d74@github.com> On Wed, 7 Apr 2021 15:22:10 GMT, Amit Pawar wrote: >> In case of ParallelGC, oldgen expansion can happen during promotion. Expanding thread will touch the pages and can't request for task execution as this GC thread is already executing a task. The expanding thread holds the lock on "ExpandHeap_lock" to resize the oldgen and other threads may wait for their turn. This is a blocking call. >> >> This patch changes this behavior by adding another constructor in "MutexLocker" class to enable non blocking or try_lock operation. This way one thread will acquire the lock and other threads can join pretouch work. Threads failed to acquire the lock will join pretouch only when task is marked ready by expanding thread. >> >> Following minimum expansion size are seen during expansion. >> 1. 512KB without largepages and without UseNUMA. >> 2. 64MB without largepages and with UseNUMA, >> 3. 2MB (on x86) with large pages and without UseNUMA, >> 4. 64MB without large pages and with UseNUMA. >> >> When Oldgen is expanding repeatedly with smaller size then this change wont help. For such cases, resize size should adapt to application demand to make use of this change. For example if application nature triggers 100 expansion with smaller sizes in same GC then it is better to increase the expansion size during each resize to reduce the number of resizes. If this patch is accepted then will plan to fix this case in another patch. >> >> Jtreg all test passed. >> >> Please review this change. > > Amit Pawar has updated the pull request incrementally with one additional commit since the last revision: > > This code is used for testing purpose and lock should be acquired with no > safepoint check as similar to earlier code. Sorry to be slow to respond. I've done some prototyping of an alternative that I think is promising, but have been swamped with other work. It might be a while before I can really spend time on it again. ------------- PR: https://git.openjdk.java.net/jdk/pull/2976 From kvn at openjdk.java.net Tue Apr 27 06:26:53 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Tue, 27 Apr 2021 06:26:53 GMT Subject: Integrated: 8264806: Remove the experimental JIT compiler In-Reply-To: References: Message-ID: On Fri, 9 Apr 2021 17:35:11 GMT, Vladimir Kozlov wrote: > As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Java-based JIT compiler (Graal) from JDK: > > - `jdk.internal.vm.compiler` ? the Graal compiler > - `jdk.internal.vm.compiler.management` ? Graal's `MBean` > - `test/hotspot/jtreg/compiler/graalunit` ? Graal's unit tests > > Remove Graal related code in makefiles. > > Note, next two `module-info.java` files are preserved so that the JVMCI module `jdk.internal.vm.ci` continues to build: > > src/jdk.internal.vm.compiler/share/classes/module-info.java > src/jdk.internal.vm.compiler.management/share/classes/module-info.java > > > @AlanBateman suggested that we can avoid it by using Module API to export packages at runtime . It requires changes in GraalVM's JVMCI too so I will file followup RFE to implement it. > > Tested hs-tier1-4 This pull request has now been integrated. Changeset: 4785e112 Author: Vladimir Kozlov URL: https://git.openjdk.java.net/jdk/commit/4785e112 Stats: 441532 lines in 2884 files changed: 0 ins; 441518 del; 14 mod 8264806: Remove the experimental JIT compiler Reviewed-by: iignatyev, erikj ------------- PR: https://git.openjdk.java.net/jdk/pull/3421 From ayang at openjdk.java.net Tue Apr 27 07:24:41 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Tue, 27 Apr 2021 07:24:41 GMT Subject: RFR: 8234020: Remove FullGCCount_lock [v2] In-Reply-To: References: Message-ID: On Mon, 26 Apr 2021 21:08:55 GMT, Albert Mingkun Yang wrote: >> Remove an unused method and unnecessary synchronization in Serial GC. > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Thanks for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/3679 From ayang at openjdk.java.net Tue Apr 27 07:24:42 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Tue, 27 Apr 2021 07:24:42 GMT Subject: Integrated: 8234020: Remove FullGCCount_lock In-Reply-To: References: Message-ID: <6Mn9cmdspnIf-FtYZAun7U05l8FwFbjH8_3qfkjBBGE=.4d0b2201-3a68-4bbd-9acc-62c0755ea563@github.com> On Sun, 25 Apr 2021 19:44:50 GMT, Albert Mingkun Yang wrote: > Remove an unused method and unnecessary synchronization in Serial GC. This pull request has now been integrated. Changeset: 468c847c Author: Albert Mingkun Yang URL: https://git.openjdk.java.net/jdk/commit/468c847c Stats: 24 lines in 4 files changed: 0 ins; 24 del; 0 mod 8234020: Remove FullGCCount_lock Reviewed-by: kbarrett ------------- PR: https://git.openjdk.java.net/jdk/pull/3679 From dholmes at openjdk.java.net Tue Apr 27 07:40:40 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 27 Apr 2021 07:40:40 GMT Subject: RFR: 8265756: AArch64: initialize memory allocated for locals according to Windows AArch64 stack page growth requirement in template interpreter [v3] In-Reply-To: References: Message-ID: On Mon, 26 Apr 2021 10:53:36 GMT, Aleksei Voitylov wrote: >> Hi, >> >> please review this PR which fixes several JCK test failures on Windows AArch64. On Windows AArch64, the order in which the pages are touched during stack allocation, matters. Here is a quote: "Functions that allocate 4k or more worth of stack must ensure that each page prior to the final page is touched in order" [1]. Since on Linux and Mac the order does not matter, the suggested fix reverses the order in which memory pages are touched during stack allocation for locals in template interpreter for all platforms. >> >> Testing: JCK, jtreg, newly developed regression test on Linux AArch64, Windows AArch64, Mac AArch64, Pre-submit tests (which includes the newly developed test). >> >> [1] https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-160#stack > > Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision: > > terminology refresh and move tests to a different location Nothing further form me (I was away for a few days) - the test comments look good. I did not actually review the change itself (not my area). Thanks, David ------------- PR: https://git.openjdk.java.net/jdk/pull/3633 From dholmes at openjdk.java.net Tue Apr 27 07:48:35 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 27 Apr 2021 07:48:35 GMT Subject: RFR: 8265768 [aarch64] Use glibc libm impl for dlog, dlog10, dexp iff 2.29 or greater on AArch64. In-Reply-To: References: Message-ID: On Thu, 15 Apr 2021 08:33:47 GMT, gregcawthorne wrote: > Glibc 2.29 onwards provides optimised versions of log,log10,exp. > These functions have an accuracy of 0.9ulp or better in glibc > 2.29. > > Therefore this patch adds code to parse, store and check > the runtime glibcs version in os_linux.cpp/hpp. > This is then used to select the glibcs implementation of > log, log10, exp at runtime for c1 and c2, iff we have > glibc 2.29 or greater. > > This will ensure OpenJDK can benefit from future improvements > to glibc. > > Glibc adheres to the ieee754 standard, unless stated otherwise > in its spec. > > As there are no stated exceptions in the current glibc spec > for dlog, dlog10 and dexp, we can assume they currently follow > ieee754 (which testing confirms). As such, future version of > glibc are unlikely to lose this compliance with ieee754 in > future. > > W.r.t performance this patch sees ~15-30% performance improvements for > log and log10, with ~50-80% performance improvements for exp for the > common input ranged (which output real numbers). However for the NaN > and inf output ranges we see a slow down of up to a factor of 2 for > some functions and architectures. > > Due to this being the uncommon case we assert that this is a > worthwhile tradeoff. I only reviewed the shared code changes and they seem fine. One minor request below. Thanks, David src/hotspot/os/linux/os_linux.cpp line 548: > 546: } > 547: > 548: void os::Linux::set_libc_major_minor(const char *libc_vers){ Please add a comment showing what the expected format of the version string is. It is hard to check the parsing logic without knowing that. ------------- PR: https://git.openjdk.java.net/jdk/pull/3510 From avoitylov at openjdk.java.net Tue Apr 27 09:24:34 2021 From: avoitylov at openjdk.java.net (Aleksei Voitylov) Date: Tue, 27 Apr 2021 09:24:34 GMT Subject: RFR: 8265756: AArch64: initialize memory allocated for locals according to Windows AArch64 stack page growth requirement in template interpreter In-Reply-To: References: <4-NQ7nQndXAR0Ik5CuBxXvWIF0I626NJ0FsY00DtFW0=.09d08014-2981-4f5c-ada2-30ef743480d6@github.com> Message-ID: On Mon, 26 Apr 2021 13:37:34 GMT, Andrew Dinn wrote: >> @adinn thank you for noticing. I updated the terminology and renamed the test. > > @voitylov When you are ready type the /integrate command in a new comment and I will happily sponsor the change. @adinn @theRealAph thank you for review, @dholmes-ora thank you for your comments! ------------- PR: https://git.openjdk.java.net/jdk/pull/3633 From aph at openjdk.java.net Tue Apr 27 10:00:38 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Tue, 27 Apr 2021 10:00:38 GMT Subject: RFR: 8265768 [aarch64] Use glibc libm impl for dlog, dlog10, dexp iff 2.29 or greater on AArch64. In-Reply-To: References: Message-ID: On Thu, 15 Apr 2021 08:33:47 GMT, gregcawthorne wrote: > Glibc 2.29 onwards provides optimised versions of log,log10,exp. > These functions have an accuracy of 0.9ulp or better in glibc > 2.29. > > Therefore this patch adds code to parse, store and check > the runtime glibcs version in os_linux.cpp/hpp. > This is then used to select the glibcs implementation of > log, log10, exp at runtime for c1 and c2, iff we have > glibc 2.29 or greater. > > This will ensure OpenJDK can benefit from future improvements > to glibc. > > Glibc adheres to the ieee754 standard, unless stated otherwise > in its spec. > > As there are no stated exceptions in the current glibc spec > for dlog, dlog10 and dexp, we can assume they currently follow > ieee754 (which testing confirms). As such, future version of > glibc are unlikely to lose this compliance with ieee754 in > future. > > W.r.t performance this patch sees ~15-30% performance improvements for > log and log10, with ~50-80% performance improvements for exp for the > common input ranged (which output real numbers). However for the NaN > and inf output ranges we see a slow down of up to a factor of 2 for > some functions and architectures. > > Due to this being the uncommon case we assert that this is a > worthwhile tradeoff. One other thing: I can't find any reference to monotonicity in the libc 2.29 documentation. In fact, I can't find any references at all to the glibc 2.29 changes in this area. Please provide some pointers, thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/3510 From github.com+73799211+gregcawthorne at openjdk.java.net Tue Apr 27 10:19:35 2021 From: github.com+73799211+gregcawthorne at openjdk.java.net (gregcawthorne) Date: Tue, 27 Apr 2021 10:19:35 GMT Subject: RFR: 8265768 [aarch64] Use glibc libm impl for dlog, dlog10, dexp iff 2.29 or greater on AArch64. In-Reply-To: References: Message-ID: On Tue, 27 Apr 2021 09:57:21 GMT, Andrew Haley wrote: > One other thing: I can't find any reference to monotonicity in the libc 2.29 documentation. In fact, I can't find any references at all to the glibc 2.29 changes in this area. Please provide some pointers, thanks. Hi Aph. I have added a link: https://sourceware.org/legacy-ml/libc-announce/2019/msg00000.html As a comment in os_linux_aarch64.cpp, in the patch. This mentions the improvements for exp and log in glib version 2.29 (log10 calls down to log I believe). My understanding was also driven by speaking to Szabolcs Nagy inside arm, who maintains our (AOR) Arm Optimised Routines library. It is from this library from which these improvements have been included into glibc. We have talked about the possibility of including AOR in OpenJDK. But that seems to be more of a legality question at this point in time, as I am informed the Free Software Foundation currently holds the copyright to AOR. Thanks, Greg. ------------- PR: https://git.openjdk.java.net/jdk/pull/3510 From github.com+73799211+gregcawthorne at openjdk.java.net Tue Apr 27 10:34:34 2021 From: github.com+73799211+gregcawthorne at openjdk.java.net (gregcawthorne) Date: Tue, 27 Apr 2021 10:34:34 GMT Subject: RFR: 8265768 [aarch64] Use glibc libm impl for dlog, dlog10, dexp iff 2.29 or greater on AArch64. In-Reply-To: References: Message-ID: On Thu, 15 Apr 2021 08:33:47 GMT, gregcawthorne wrote: > Glibc 2.29 onwards provides optimised versions of log,log10,exp. > These functions have an accuracy of 0.9ulp or better in glibc > 2.29. > > Therefore this patch adds code to parse, store and check > the runtime glibcs version in os_linux.cpp/hpp. > This is then used to select the glibcs implementation of > log, log10, exp at runtime for c1 and c2, iff we have > glibc 2.29 or greater. > > This will ensure OpenJDK can benefit from future improvements > to glibc. > > Glibc adheres to the ieee754 standard, unless stated otherwise > in its spec. > > As there are no stated exceptions in the current glibc spec > for dlog, dlog10 and dexp, we can assume they currently follow > ieee754 (which testing confirms). As such, future version of > glibc are unlikely to lose this compliance with ieee754 in > future. > > W.r.t performance this patch sees ~15-30% performance improvements for > log and log10, with ~50-80% performance improvements for exp for the > common input ranged (which output real numbers). However for the NaN > and inf output ranges we see a slow down of up to a factor of 2 for > some functions and architectures. > > Due to this being the uncommon case we assert that this is a > worthwhile tradeoff. My current understanding with regards to the monotonicity of the functions that glibc follows IEEE 754 unless explicit defined in the spec. http://port70.net/~nsz/c/c11/n1570.html#F.10.3.7 However, I will see if I can get a clearer answer for you. ------------- PR: https://git.openjdk.java.net/jdk/pull/3510 From github.com+73799211+gregcawthorne at openjdk.java.net Tue Apr 27 11:14:35 2021 From: github.com+73799211+gregcawthorne at openjdk.java.net (gregcawthorne) Date: Tue, 27 Apr 2021 11:14:35 GMT Subject: RFR: 8265768 [aarch64] Use glibc libm impl for dlog, dlog10, dexp iff 2.29 or greater on AArch64. In-Reply-To: References: Message-ID: <-qtOeeCL2B6XL14mdyYHlGgWIP-nyNm8LacuQoqrVmk=.e62c2da6-70de-490d-a164-a24946c1991c@github.com> On Thu, 15 Apr 2021 08:33:47 GMT, gregcawthorne wrote: > Glibc 2.29 onwards provides optimised versions of log,log10,exp. > These functions have an accuracy of 0.9ulp or better in glibc > 2.29. > > Therefore this patch adds code to parse, store and check > the runtime glibcs version in os_linux.cpp/hpp. > This is then used to select the glibcs implementation of > log, log10, exp at runtime for c1 and c2, iff we have > glibc 2.29 or greater. > > This will ensure OpenJDK can benefit from future improvements > to glibc. > > Glibc adheres to the ieee754 standard, unless stated otherwise > in its spec. > > As there are no stated exceptions in the current glibc spec > for dlog, dlog10 and dexp, we can assume they currently follow > ieee754 (which testing confirms). As such, future version of > glibc are unlikely to lose this compliance with ieee754 in > future. > > W.r.t performance this patch sees ~15-30% performance improvements for > log and log10, with ~50-80% performance improvements for exp for the > common input ranged (which output real numbers). However for the NaN > and inf output ranges we see a slow down of up to a factor of 2 for > some functions and architectures. > > Due to this being the uncommon case we assert that this is a > worthwhile tradeoff. >From speaking to Szabolcs, the current AOR exp and log implementations have a very low ulp error (iirc < 0.51 ulp). So incorrect roundings are in fact rare, but not impossible. Therefore It seems glibc does not guarantee monotonicity. This is reinforced in the standard (although some aspects of this such as the table of error for AArch64 do need updating): https://www.gnu.org/software/libc/manual/html_node/Errors-in-Math-Functions.html "The GNU C Library does not aim for functions to satisfy other properties of the underlying mathematical function, such as monotonicity, where not implied by the above goals" So even if it the current implementations are monotonic it seems we can't guarantee them to remain that way in future glibc versions. Greg. ------------- PR: https://git.openjdk.java.net/jdk/pull/3510 From avoitylov at openjdk.java.net Tue Apr 27 11:20:41 2021 From: avoitylov at openjdk.java.net (Aleksei Voitylov) Date: Tue, 27 Apr 2021 11:20:41 GMT Subject: Integrated: 8265756: AArch64: initialize memory allocated for locals according to Windows AArch64 stack page growth requirement in template interpreter In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 15:55:40 GMT, Aleksei Voitylov wrote: > Hi, > > please review this PR which fixes several JCK test failures on Windows AArch64. On Windows AArch64, the order in which the pages are touched during stack allocation, matters. Here is a quote: "Functions that allocate 4k or more worth of stack must ensure that each page prior to the final page is touched in order" [1]. Since on Linux and Mac the order does not matter, the suggested fix reverses the order in which memory pages are touched during stack allocation for locals in template interpreter for all platforms. > > Testing: JCK, jtreg, newly developed regression test on Linux AArch64, Windows AArch64, Mac AArch64, Pre-submit tests (which includes the newly developed test). > > [1] https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-160#stack This pull request has now been integrated. Changeset: f6e26f6f Author: Aleksei Voitylov Committer: Andrew Dinn URL: https://git.openjdk.java.net/jdk/commit/f6e26f6f Stats: 123 lines in 3 files changed: 116 ins; 5 del; 2 mod 8265756: AArch64: initialize memory allocated for locals according to Windows AArch64 stack page growth requirement in template interpreter Reviewed-by: adinn, aph ------------- PR: https://git.openjdk.java.net/jdk/pull/3633 From akozlov at openjdk.java.net Tue Apr 27 13:31:36 2021 From: akozlov at openjdk.java.net (Anton Kozlov) Date: Tue, 27 Apr 2021 13:31:36 GMT Subject: RFR: 8265768 [aarch64] Use glibc libm impl for dlog, dlog10, dexp iff 2.29 or greater on AArch64. In-Reply-To: References: Message-ID: On Thu, 15 Apr 2021 08:33:47 GMT, gregcawthorne wrote: > Glibc 2.29 onwards provides optimised versions of log,log10,exp. > These functions have an accuracy of 0.9ulp or better in glibc > 2.29. > > Therefore this patch adds code to parse, store and check > the runtime glibcs version in os_linux.cpp/hpp. > This is then used to select the glibcs implementation of > log, log10, exp at runtime for c1 and c2, iff we have > glibc 2.29 or greater. > > This will ensure OpenJDK can benefit from future improvements > to glibc. > > Glibc adheres to the ieee754 standard, unless stated otherwise > in its spec. > > As there are no stated exceptions in the current glibc spec > for dlog, dlog10 and dexp, we can assume they currently follow > ieee754 (which testing confirms). As such, future version of > glibc are unlikely to lose this compliance with ieee754 in > future. > > W.r.t performance this patch sees ~15-30% performance improvements for > log and log10, with ~50-80% performance improvements for exp for the > common input ranged (which output real numbers). However for the NaN > and inf output ranges we see a slow down of up to a factor of 2 for > some functions and architectures. > > Due to this being the uncommon case we assert that this is a > worthwhile tradeoff. Changes requested by akozlov (no project role). src/hotspot/os_cpu/windows_aarch64/os_windows_aarch64.hpp line 29: > 27: > 28: static void setup_fpu(); > 29: static bool stub_use_cmath_impl(int intrinsicID); Something similar should be done in hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp. I've pushed this patch in my GHA and the build have failed: https://github.com/AntonKozlov/jdk/runs/2447540531. Similar check can be made if you set up GHA as described in https://github.com/openjdk/jdk/pull/3510/checks ------------- PR: https://git.openjdk.java.net/jdk/pull/3510 From coleenp at openjdk.java.net Tue Apr 27 14:47:38 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 27 Apr 2021 14:47:38 GMT Subject: RFR: 8255493: Support for pre-generated java.lang.invoke classes in CDS dynamic archive [v3] In-Reply-To: References: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> Message-ID: On Tue, 27 Apr 2021 04:14:05 GMT, Yumin Qi wrote: >> Hi, Please review >> >> When do dynamic dump, the pre-generated lambda form classes from java.lang.invoke are not stored in dynamic archive. The patch will regenerate the four holder classes, >> "java.lang.invoke.Invokers$Holder", >> "java.lang.invoke.DirectMethodHandle$Holder", >> "java.lang.invoke.DelegatingMethodHandle$Holder", >> "java.lang.invoke.LambdaForm$Holder" >> which will include the versions in static archive and new loaded functions all together and stored in dynamic archive. New test case added. >> (Minor change to PrintSharedArchiveAtExit, which the index is not consecutive) >> >> Tests: tier1,tier2,tier3,tier4 >> >> Thanks >> Yumin > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Move read static invoker lines to LambdaFormInokers, remove unneeded check for return NULL I just had a couple of comments, otherwise looks ok to me but I have to confess that I don't know this code that well. src/hotspot/share/cds/lambdaFormInvokers.cpp line 86: > 84: guarantee(cds_klass != NULL, "jdk/internal/misc/CDS must exist!"); > 85: > 86: log_info(cds)("Total lambdaform lines %d", _lambdaform_lines->length()); Can this logging be DEBUG level instead? src/hotspot/share/cds/lambdaFormInvokers.cpp line 125: > 123: log_info(cds)("Out of memory when reloading classes, quit"); > 124: return; > 125: } as_utf8_string doesn't return NULL for OOM. If resource allocation fails in the lower levels, it'll vm_exit_out_of_memory. ------------- PR: https://git.openjdk.java.net/jdk/pull/3611 From aph at openjdk.java.net Tue Apr 27 14:57:35 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Tue, 27 Apr 2021 14:57:35 GMT Subject: RFR: 8265768 [aarch64] Use glibc libm impl for dlog, dlog10, dexp iff 2.29 or greater on AArch64. In-Reply-To: References: Message-ID: On Thu, 15 Apr 2021 08:33:47 GMT, gregcawthorne wrote: > Glibc 2.29 onwards provides optimised versions of log,log10,exp. > These functions have an accuracy of 0.9ulp or better in glibc > 2.29. > > Therefore this patch adds code to parse, store and check > the runtime glibcs version in os_linux.cpp/hpp. > This is then used to select the glibcs implementation of > log, log10, exp at runtime for c1 and c2, iff we have > glibc 2.29 or greater. > > This will ensure OpenJDK can benefit from future improvements > to glibc. > > Glibc adheres to the ieee754 standard, unless stated otherwise > in its spec. > > As there are no stated exceptions in the current glibc spec > for dlog, dlog10 and dexp, we can assume they currently follow > ieee754 (which testing confirms). As such, future version of > glibc are unlikely to lose this compliance with ieee754 in > future. > > W.r.t performance this patch sees ~15-30% performance improvements for > log and log10, with ~50-80% performance improvements for exp for the > common input ranged (which output real numbers). However for the NaN > and inf output ranges we see a slow down of up to a factor of 2 for > some functions and architectures. > > Due to this being the uncommon case we assert that this is a > worthwhile tradeoff. > Therefore It seems glibc does not guarantee monotonicity. > https://www.gnu.org/software/libc/manual/html_node/Errors-in-Math-Functions.html > "The GNU C Library does not aim for functions to satisfy other properties of the underlying mathematical function, such as monotonicity, where not implied by the above goals" OK, so without a Java Specification review, we'll have to decline this patch. Sorry. ------------- PR: https://git.openjdk.java.net/jdk/pull/3510 From chagedorn at openjdk.java.net Tue Apr 27 15:25:42 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Tue, 27 Apr 2021 15:25:42 GMT Subject: RFR: 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests [v6] In-Reply-To: References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> Message-ID: On Mon, 26 Apr 2021 18:09:25 GMT, Igor Ignatyev wrote: >> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comments by Tobias: Formatting fields, spacing, README.md typos and cleanup > > test/lib/jdk/test/lib/hotspot/ir_framework/CompLevel.java line 65: > >> 63: * Compilation level 1: C1 compilation without any profile information. >> 64: */ >> 65: C1(1), > > this name might be misleading, as one can assume that it means all C1 levels, `C1_SIMPLE`? I initially had `C1_SIMPLE` but then replaced it with `C1` as `@DontCompile` can only exclude a compilation for a compiler and not a specific level. However, while thinking about it, it might be better to not share `C1/C1_SIMPLE` but use a separate annotation for `@DontCompile`. I added a new `Compiler` annotation class and updated the usages and checks. > test/lib/jdk/test/lib/hotspot/ir_framework/DontCompile.java line 39: > >> 37: *

  • The usage of any other compilation level is forbidden and results in a >> 38: * {@link TestFormatException TestFormatException}.

    • >> 39: * > > this actually suggests that we shouldn't use `CompLevel` here and need to introduce another enum to denote compilers. I was thinking about the same thing while processing an earlier review comment above :) So, it indeed makes sense to use a separate enum for it. > test/lib/jdk/test/lib/hotspot/ir_framework/IRMatcher.java line 39: > >> 37: class IRMatcher { >> 38: private static final boolean PRINT_IR_ENCODING = Boolean.parseBoolean(System.getProperty("PrintIREncoding", "false")); >> 39: private static final Pattern irEncodingPattern = > > we typically use UPPER_CAMEL_CASE for constants such as `irEncodingPattern` I updated this and other inconsistencies in the naming of `static final` variables. > test/lib/jdk/test/lib/hotspot/ir_framework/Scenario.java line 55: > >> 53: static { >> 54: if (!SCENARIOS_PROPERTY.isEmpty()) { >> 55: System.out.println(Arrays.toString(SCENARIOS_PROPERTY.split("\\s*,\\s*"))); > > did you mean to print it here or was it just a leftover from a debugging session? Good catch. It was a leftover. > test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 135: > >> 133: - To only run the failed tests use -DTest, -DExclude, >> 134: and/or -DScenarios. >> 135: - To also get the standard output of the test VM run with\s > > why do you need `\s` here? I needed this because `jcheck` complained about trailing whitespaces. Maybe this needs to be addressed at some point in `jcheck`. > test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 146: > >> 144: private static final boolean REPORT_STDOUT = Boolean.getBoolean("ReportStdout"); >> 145: private final boolean VERIFY_VM = Boolean.getBoolean("VerifyVM") && Platform.isDebugBuild(); >> 146: private boolean VERIFY_IR = Boolean.parseBoolean(System.getProperty("VerifyIR", "true")); > > it seems both these guys were meant to be `static final` `VERIFY_VM` should be yes. But `VERIFY_IR` is only initialized and later updated in `disableIRVerificationIfNotFeasible()`. However, I suggest to rename this field into something more meaningful like `irVerificationPossible`. ------------- PR: https://git.openjdk.java.net/jdk/pull/3508 From chagedorn at openjdk.java.net Tue Apr 27 15:25:43 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Tue, 27 Apr 2021 15:25:43 GMT Subject: RFR: 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests [v6] In-Reply-To: <1MYGXgT-l5ghB-P0sQ7V1YcH3KmqPVra8pnjjWpJIOo=.c7a271c2-01dc-448e-ac95-22d7d30af0af@github.com> References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> <1MYGXgT-l5ghB-P0sQ7V1YcH3KmqPVra8pnjjWpJIOo=.c7a271c2-01dc-448e-ac95-22d7d30af0af@github.com> Message-ID: On Mon, 26 Apr 2021 23:54:44 GMT, John Tortugo wrote: >> Christian Hagedorn has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comments by Tobias: Formatting fields, spacing, README.md typos and cleanup > > test/lib/jdk/test/lib/hotspot/ir_framework/TestFrameworkExecution.java line 308: > >> 306: >> 307: private void processControlAnnotations(Class clazz) { >> 308: if (!XCOMP) { > > Perhaps transform this condition on an early return, i.e., "if (XCOMP) return ;", instead of nesting the whole method under the if. This handling with `XCOMP` (and other related ones) seem to be wrong and only worked like that in the old Valhalla framework. I don't think it is correct like that anymore. I discussed it with @TobiHartmann and thus added a new debug flag `-DIgnoreCompilerControls` to achieve the same functionality as in the old framework. I will push this update in a separate commit. > test/lib/jdk/test/lib/hotspot/ir_framework/TestFrameworkExecution.java line 373: > >> 371: boolean exclude = random.nextBoolean(); >> 372: CompLevel level = CompLevel.ANY; >> 373: if (exclude) { > > Transform to early return? I refactored the code relating to `ExcludeRandom`. > test/lib/jdk/test/lib/hotspot/ir_framework/TestFrameworkExecution.java line 378: > >> 376: case 1 -> { >> 377: level = CompLevel.C1; >> 378: WHITE_BOX.makeMethodNotCompilable(ex, CompLevel.C2.getValue(), false); > > I'm curious why two calls (with different values for the last parameter) are needed for these? The parameter is for [osr](https://github.com/openjdk/jdk/blob/dc323a933401e4e540cdc416de5260923f42ba7f/src/hotspot/share/prims/whitebox.cpp#L928-L937): We need to exclude the method for osr and for normal compilations. ------------- PR: https://git.openjdk.java.net/jdk/pull/3508 From chagedorn at openjdk.java.net Tue Apr 27 15:37:58 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Tue, 27 Apr 2021 15:37:58 GMT Subject: RFR: 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests [v7] In-Reply-To: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> Message-ID: > This RFE provides an IR test framework to perform regex-based checks on the C2 IR shape of test methods emitted by the VM flags `-XX:+PrintIdeal` and `-XX:+PrintOptoAssembly`. The framework can also be used for other non-IR matching (and non-compiler) tests by providing easy to use annotations for commonly used testing patterns and compiler control flags. > > The framework is based on the ideas of the currently present IR test framework in [Valhalla](https://github.com/openjdk/valhalla/blob/e9c78ce4fcfd01361c35883e0d68f9ae5a80d079/test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypeTest.java) (mainly implemented by @TobiHartmann) which is being used with great success. This new framework aims to replace the old one in Valhalla at some point. > > A detailed description about how this new IR test framework works and how it is used is provided in the [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) file and in the [Javadocs](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc/jdk/test/lib/hotspot/ir_framework/package-summary.html) written for the framework classes. > > To finish a first version of this framework for JDK 17, I decided to leave some improvement possibilities and ideas to be followed up on in additional RFEs. Some ideas are mentioned in "Future Work" in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) and were also created as subtasks of this RFE. > > Testing (also described in "Internal Framework Tests in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md)): > There are various tests to verify the correctness of the test framework which can be found as JTreg tests in the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) folder. Additional testing was performed by converting all compiler Inline Types test of project Valhalla (done by @katyapav in [JDK-8263024](https://bugs.openjdk.java.net/browse/JDK-8263024)) that used the old framework to the new framework. This provided additional testing for the framework itself. We ran the converted tests with all the flag settings used in hs-tier1-9 and hs-precheckin-comp. For sanity checking, this was also done with a sample IR test in mainline. > > Some stats about the framework code added to [ir_framework](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework): > > - without the [Javadocs files](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc) : 60 changed files, 13212 insertions, 0 deletions. > - without the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) and [examples](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/examples) folder: 40 files changed, 6781 insertions > - comments: 2399 insertions (calculated with `git diff --cached !(tests|examples) | grep -c -E "(^[+-]\s*(/)?*)|(^[+-]\s*//)"`) > - which leaves 4382 lines of code inserted > > Big thanks to: > - @TobiHartmann for all his help by discussing the new framework and for providing insights from his IR test framework in Valhalla. > - @katyapav for converting the Valhalla tests to use the new framework which found some harder to catch bugs in the framework and also some actual C2 bugs. > - @iignatev for helping to simplify the framework usage with JTreg and with the framework internal VM calling structure. > - and others who provided valuable feedback. > > Thanks, > Christian Christian Hagedorn has updated the pull request incrementally with two additional commits since the last revision: - Fix XCOMP cases from old framework and turn it into new debug flag -DIgnoreCompilerControls - Apply review comments: Added new Compiler annotation class for @DontCompile, changed C1 into C1_SIMPLE, refactored code for ExcludeRandom and FlipC1C2, added missing flag description in README, and some other smaller refactoring/renamings ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3508/files - new: https://git.openjdk.java.net/jdk/pull/3508/files/0720a330..90a0064d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3508&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3508&range=05-06 Stats: 484 lines in 23 files changed: 207 ins; 85 del; 192 mod Patch: https://git.openjdk.java.net/jdk/pull/3508.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3508/head:pull/3508 PR: https://git.openjdk.java.net/jdk/pull/3508 From iignatyev at openjdk.java.net Tue Apr 27 15:44:44 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Tue, 27 Apr 2021 15:44:44 GMT Subject: RFR: 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests [v6] In-Reply-To: References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> Message-ID: <0ieb3GL4kRcuSN4ZftJdRVlarhrqcYC0LFb9ZSpd7UY=.8f6cf2af-6e92-4743-bbf0-2b21f76d2413@github.com> On Tue, 27 Apr 2021 15:21:44 GMT, Christian Hagedorn wrote: >> test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 135: >> >>> 133: - To only run the failed tests use -DTest, -DExclude, >>> 134: and/or -DScenarios. >>> 135: - To also get the standard output of the test VM run with\s >> >> why do you need `\s` here? > > I needed this because `jcheck` complained about trailing whitespaces. Maybe this needs to be addressed at some point in `jcheck`. well, why do you want to have a trailing space here? the text block you current have produces the following multeline sting, which has a trailing space at 4th line: ``` ############################################################# - To only run the failed tests use -DTest, -DExclude, and/or -DScenarios. - To also get the standard output of the test VM run with -DReportStdout=true or for even more fine-grained logging use -DVerbose=true. ############################################################# ------------- PR: https://git.openjdk.java.net/jdk/pull/3508 From chagedorn at openjdk.java.net Tue Apr 27 16:01:40 2021 From: chagedorn at openjdk.java.net (Christian Hagedorn) Date: Tue, 27 Apr 2021 16:01:40 GMT Subject: RFR: 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests [v6] In-Reply-To: <0ieb3GL4kRcuSN4ZftJdRVlarhrqcYC0LFb9ZSpd7UY=.8f6cf2af-6e92-4743-bbf0-2b21f76d2413@github.com> References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> <0ieb3GL4kRcuSN4ZftJdRVlarhrqcYC0LFb9ZSpd7UY=.8f6cf2af-6e92-4743-bbf0-2b21f76d2413@github.com> Message-ID: <9WzMXz_x4oWYNvye8WlUwI8S1ecO0krG3YhavJFsHn4=.e0687541-e365-4507-b577-d6f8f8d98930@github.com> On Tue, 27 Apr 2021 15:41:07 GMT, Igor Ignatyev wrote: >> I needed this because `jcheck` complained about trailing whitespaces. Maybe this needs to be addressed at some point in `jcheck`. > > well, why do you want to have a trailing space here? the text block you current have produces the following multeline sting, which has a trailing space at 4th line: > ``` ############################################################# > - To only run the failed tests use -DTest, -DExclude, > and/or -DScenarios. > - To also get the standard output of the test VM run with > -DReportStdout=true or for even more fine-grained logging > use -DVerbose=true. > ############################################################# Hm, it somehow made sense when I added it back there but looking at it again it no longer does. I'll remove it in the next iteration. ------------- PR: https://git.openjdk.java.net/jdk/pull/3508 From minqi at openjdk.java.net Tue Apr 27 16:31:38 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 27 Apr 2021 16:31:38 GMT Subject: RFR: 8255493: Support for pre-generated java.lang.invoke classes in CDS dynamic archive [v3] In-Reply-To: References: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> Message-ID: On Tue, 27 Apr 2021 14:29:14 GMT, Coleen Phillimore wrote: >> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> Move read static invoker lines to LambdaFormInokers, remove unneeded check for return NULL > > src/hotspot/share/cds/lambdaFormInvokers.cpp line 86: > >> 84: guarantee(cds_klass != NULL, "jdk/internal/misc/CDS must exist!"); >> 85: >> 86: log_info(cds)("Total lambdaform lines %d", _lambdaform_lines->length()); > > Can this logging be DEBUG level instead? Thanks for review! Will move into DEBUG_ONLY > src/hotspot/share/cds/lambdaFormInvokers.cpp line 125: > >> 123: log_info(cds)("Out of memory when reloading classes, quit"); >> 124: return; >> 125: } > > as_utf8_string doesn't return NULL for OOM. If resource allocation fails in the lower levels, it'll vm_exit_out_of_memory. Will delete the result check. ------------- PR: https://git.openjdk.java.net/jdk/pull/3611 From minqi at openjdk.java.net Tue Apr 27 16:53:08 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 27 Apr 2021 16:53:08 GMT Subject: RFR: 8255493: Support for pre-generated java.lang.invoke classes in CDS dynamic archive [v4] In-Reply-To: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> References: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> Message-ID: > Hi, Please review > > When do dynamic dump, the pre-generated lambda form classes from java.lang.invoke are not stored in dynamic archive. The patch will regenerate the four holder classes, > "java.lang.invoke.Invokers$Holder", > "java.lang.invoke.DirectMethodHandle$Holder", > "java.lang.invoke.DelegatingMethodHandle$Holder", > "java.lang.invoke.LambdaForm$Holder" > which will include the versions in static archive and new loaded functions all together and stored in dynamic archive. New test case added. > (Minor change to PrintSharedArchiveAtExit, which the index is not consecutive) > > Tests: tier1,tier2,tier3,tier4 > > Thanks > Yumin Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Moved log invoker lines to debug only, removed check for as_utf8_string ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3611/files - new: https://git.openjdk.java.net/jdk/pull/3611/files/9b5aa513..c46b64c2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3611&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3611&range=02-03 Stats: 6 lines in 1 file changed: 1 ins; 5 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3611.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3611/head:pull/3611 PR: https://git.openjdk.java.net/jdk/pull/3611 From kevinw at openjdk.java.net Tue Apr 27 16:57:18 2021 From: kevinw at openjdk.java.net (Kevin Walls) Date: Tue, 27 Apr 2021 16:57:18 GMT Subject: RFR: 8264593: debug.cpp utilities should be available in product builds. [v2] In-Reply-To: References: Message-ID: <3a7QjXW2fF6Jr0a0TudKxM_n1icuj5rQ54gJz0Egz8U=.f602c0b9-232b-4746-84bb-5fb97f221c38@github.com> > This is a pull request to move the ifndef PRODUCT in src/hotspot/share/utilities/debug.cpp, and add JNIEXPORT for symbol visibility on Windows. > > With these changes, we can use gdb on a live Linux process of a product build JVM, and call debug.cpp utilities. > e.g. "call universe()", or "call hsfind(0xADDRESS)". > > (I found that making calls in the JLI_Launch thread (gdb's thread 1) will crash, but switching first to a JavaThread works.) > > In Visual Studio use the Immediate window, just type the function name. Verified that without the changes, the symbols can't be seen/called. > > Printing happens on the LIVE jvm's tty (not the gdb session). > > > WizardMode is a develop flag, can't be changed in a product build, so avoid changing that in the debug() utility. > > > pa() is left ifndef PRODUCT, as the class AllocatedObj is ifndef PRODUCT in src/hotspot/share/memory/allocation.hpp > > > pns(...) uses frame fr(sp, fp, pc); but we have an ifndef PRODUCT on frame constructor: frame(void* sp, void* fp, void* pc); > Leave pns and pns2 ifndef PRODUCT. > > > File size changes: > Linux: libjvm.so becomes 8904 bytes larger. > Windows: jvm.dll becomes 6656 bytes larger. Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into debug_utils - Remove pa() util as unnecessary. Tidy help. - 8264593: debug.cpp utilities should be available in product builds. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3307/files - new: https://git.openjdk.java.net/jdk/pull/3307/files/c3c81fc7..f6e19d64 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3307&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3307&range=00-01 Stats: 611853 lines in 6126 files changed: 76854 ins; 524012 del; 10987 mod Patch: https://git.openjdk.java.net/jdk/pull/3307.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3307/head:pull/3307 PR: https://git.openjdk.java.net/jdk/pull/3307 From xxinliu at amazon.com Tue Apr 27 17:17:29 2021 From: xxinliu at amazon.com (Liu, Xin) Date: Tue, 27 Apr 2021 10:17:29 -0700 Subject: Request For Comment: Asynchronous Logging In-Reply-To: References: <7FEF3035-8926-467C-AD7B-A001A9C8FD5B@amazon.com> <2170bebc-e5a2-219c-0a4b-f41623098c43@amazon.com> Message-ID: Hi, I would like to report my current progress. I have finished all pending tasks except "hoist async_mode to base class for stdout/err". May I ask to defer it after this PR? I will create an issue and work on it immediately after this PR. It's not difficult but I need to modify the existing interfaces. I would like to keep this PR almost "added" to ease reviewers. If Yasumasa allows me to do so, now the only blocker is CSR. it seems that Iom and Thomas agree with a global option. Shall we go that way? Meanwhile, I have pushed all my code to github: https://github.com/openjdk/jdk/pull/3135 Could you take a look it? ------------------------------------------------------------- | request | Status | ------------------------------------------------------------- | independent NonJavaThread | done | |-----------------------------------------------------------| | pass tier1-test with +AsyncLogging | [1] | |-----------------------------------------------------------| | inject meta-info to display no. of dropping msg. | done | |-----------------------------------------------------------| | support jcmd VM.log | done | |-----------------------------------------------------------| | preserve accurate decorations | | |-----------------------------------------------------------<- progress | hoist async_mode to base class for stdout/err| | |-----------------------------------------------------------| | CSR |JDK-8264323 | |-----------------------------------------------------------<- consensus |use string table over malloc | | ------------------------------------------------------------| |use lock-free data structure. | | ------------------------------------------------------------- [1] the only exception is serviceability/dcmd/gc/RunGCTest.java. it emits gclog and checks result right away without any synchronization. if we do run jtreg test with async logging, I need to add an flushing api in whitebox. thanks, --lx From coleenp at openjdk.java.net Tue Apr 27 17:40:37 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 27 Apr 2021 17:40:37 GMT Subject: RFR: 8255493: Support for pre-generated java.lang.invoke classes in CDS dynamic archive [v4] In-Reply-To: References: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> Message-ID: On Tue, 27 Apr 2021 16:53:08 GMT, Yumin Qi wrote: >> Hi, Please review >> >> When do dynamic dump, the pre-generated lambda form classes from java.lang.invoke are not stored in dynamic archive. The patch will regenerate the four holder classes, >> "java.lang.invoke.Invokers$Holder", >> "java.lang.invoke.DirectMethodHandle$Holder", >> "java.lang.invoke.DelegatingMethodHandle$Holder", >> "java.lang.invoke.LambdaForm$Holder" >> which will include the versions in static archive and new loaded functions all together and stored in dynamic archive. New test case added. >> (Minor change to PrintSharedArchiveAtExit, which the index is not consecutive) >> >> Tests: tier1,tier2,tier3,tier4 >> >> Thanks >> Yumin > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Moved log invoker lines to debug only, removed check for as_utf8_string src/hotspot/share/cds/lambdaFormInvokers.cpp line 85: > 83: Klass* cds_klass = SystemDictionary::resolve_or_null(cds_name, THREAD); > 84: guarantee(cds_klass != NULL, "jdk/internal/misc/CDS must exist!"); > 85: DEBUG_ONLY(log_info(cds)("Total lambdaform lines %d", _lambdaform_lines->length());) No sorry, I meant log_debug(cds)("Total lambdaform lines %d", ...) Since this is something you don't want with -Xlog:cds at the info level. Same with line 77 ------------- PR: https://git.openjdk.java.net/jdk/pull/3611 From mcimadamore at openjdk.java.net Tue Apr 27 18:01:41 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 27 Apr 2021 18:01:41 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) Message-ID: This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. [1] - https://openjdk.java.net/jeps/412 ------------- Commit messages: - Add linker test excludes for x86 and other platforms which do not support `CLinker` - Integrate latest API tweaks - Fix x86 build - Fix `TestLinkToNativeRBP` - Initial push Changes: https://git.openjdk.java.net/jdk/pull/3699/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264774 Stats: 14083 lines in 213 files changed: 8502 ins; 3605 del; 1976 mod Patch: https://git.openjdk.java.net/jdk/pull/3699.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699 PR: https://git.openjdk.java.net/jdk/pull/3699 From mcimadamore at openjdk.java.net Tue Apr 27 18:01:41 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 27 Apr 2021 18:01:41 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) In-Reply-To: References: Message-ID: On Mon, 26 Apr 2021 17:10:13 GMT, Maurizio Cimadamore wrote: > This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/412 Here we list the main changes introduced in this PR. As usual, a big thank to all who helped along the way: @ChrisHegarty, @iwanowww, @JornVernee, @PaulSandoz and @sundararajana. ### Managing memory segments: `ResourceScope` This PR introduces a new abstraction (first discussed [here](https://inside.java/2021/01/25/memory-access-pulling-all-the-threads/)), namely `ResourceScope` which is used to manage the lifecycle of resources associated with off-heap memory (such as `MemorySegment`, `VaList`, etc). This is probably the biggest change in the API, as `MemorySegment` is no longer `AutoCloseable`: it instead features a *scope accessor* which can be used to access the memory segment's `ResourceScope`; the `ResourceScope` is the new `AutoCloseable`. In other words, code like this: try (MemorySegment segment = MemorySegment.allocateNative(100)) { ... } Now becomes like this: try (ResourceScope scope = ResourceScope.ofConfinedScope()) { MemorySegment segment = MemorySegment.allocateNative(100, scope); ... } While simple cases where only one segment is allocated become a little more verbose, this new API idiom obviously scales much better when multiple segments are created with the same lifecycle. Another important fact, which is captured by the name of the `ResourceScope` factory in the above snippet, is that segments no longer feature dynamic ownership changes. These were cool, but ultimately too expensive to support in the shared case. Instead, the API now requires clients to make a choice upfront (confined, shared or *implicit* - where the latter means GC-managed, like direct buffers). Implementation-wise, `ResourceScope` is implemented by a bunch of internal classes: `ResourceScopeImpl`, `ConfinedScope` and `SharedScope`. A resource scope impl has a so called *resource list* which can be also shared or confined. This is where cleanup actions are added; the resource list can be attached to a `Cleaner` to get implicit deallocation. There is a new test `TestResourceScope` to stress test the behavior of resource scopes, as well as a couple of microbenchmarks to assess the cost of creating/closing scopes (`ResourceScopeClose`) and acquiring/releasing them (`BulkMismatchAcquire`). ### IO operation on shared buffer views In the previous iteration of the Memory Access API we have introduced the concept of *shared* segments. Shared segments are as easy to use as confined ones, and they are as fast. One problem with shared segments was that it wasn't clear how to support IO operations on byte buffers derived from such segments: since the segment memory could be released at any time, there was simply no way to guarantee that a shared segment could not be closed in the middle of a (possibly async) IO operation. In this iteration, shared segments are just segments backed by a *shared resource scope*. The new API introduces way to manage the new complexity, in the form of two methods `ResourceScope::acquire` and `ResourceScope::release`, respectively, which can be used to *acquire* a resource scope. When a resource scope is in the acquired state, it cannot be closed (you can think of it as some slightly better and asymmetric form of an atomic reference counter). This means we are now finally in a position to add support for IO operations on all byte buffers, including those derived from shared segments. A big thank to @ChrisHegarty who lead the effort here. More info on this work are included in his [writeup](https://inside.java/2021/04/21/fma-and-nio-channels/). Most of the implementation for this feature occurs in the internal NIO packages; a new method on `Buffer` has been added to facilitate acquiring from NIO code - most of the logic associated with acquiring is in the `IOUtil` class. @ChrisHegarty has added many good tests for scoped IO operations under the `foreign/channels` folder, to check for all possible buffer/scope flavors. ### Allocating at speed: `SegmentAllocator` Another abstraction introduced in this JEP is that of `SegmentAllocator`. A segment allocator is a functional interface which can be used to tell other APIs (and, crucially, the `CLinker` API) how segments should be allocated, if the need arise. For instance, think about some code which turns a Java string into a C string. Such code will invariably: 1. allocate a memory segment off heap 2. bulk copy (where possible) the content of the Java string into the off-heap segment 3. add a NULL terminator So, in (1) such string conversion routine need to allocate a new off-heap segment; how is that done? Is that a call to malloc? Or something else? In the previous iteration of the Foreign Linker API, the method `CLinker::toCString` had two overloads: a simple version, only taking a Java string parameter; and a more advanced version taking a `NativeScope`. A `NativeScope` was, at its core, a custom segment allocator - but the allocation scheme was fixed in `NativeScope` as that class always acted as an arena-style allocator. `SegmentAllocator` is like `NativeScope` in spirit, in that it helps programs allocating segments - but it does so in a more general way than `NativeScope`, since a `SegmentAllocator` is not tied to any specific allocation strategy: in fact the strategy is left there to be defined by the user. As before, `SegmentAllocator` does provide some common factories, e.g. to create an arena allocator similar to `NativeScope` - but the `CLinker` API is now free to work with _any_ implementations of the `SegmentAllocator` interface. This generalization is crucial, given that, when operating with off-heap memory, allocation performance is often the bottleneck. Not only is `SegmentAllocator` accepted by all methods in the `CLinker` API which need to allocate memory: even the behavior of downcall method handle can now be affected by segment allocators: when linking a native function which returns a struct by value, the `CLinker` API will in fact need to dynamically allocate a segment to hold the result. In such cases, the method handle generated by `CLinker` will now accept an additional *prefix* parameter of type `SegmentAllocator` which tells `CLinker` *how* should memory be allocated for the result value. For instance, now clients can tell `CLinker` to return structs by value in *heap* segments, by using a `SegmentAllocator` which allocates memory on the heap; this might be useful if the segment is quickly discarded after use. There's not much implementation for `SegmentAllocator` as most of it is defined in terms of `default` methods in the interface itself. However we do have implementation classes for the arena allocation scheme (`ArenaAllocator.java`). We support confined allocation and shared allocation. The shared allocation achieves lock-free by using a `ThreadLocal` of confined arena allocators. `TestSegmentAllocators` is the test which checks most of the arena allocation flavors. ### `MemoryAddress` as scoped entities A natural consequence of introducing the `ResourceScope` abstraction is that now not only `MemorySegment` are associated with a scope, but even instances of `MemoryAddress` can be. This means extra safety, because passing addresses which are associated with a closed scope to a native function will issue an exception. As before, it is possible to have memory addresses which the runtime knows nothing about (those returned by native calls, or those created via `MemoryAddress::ofLong`); these addresses are simply associated with the so called *global scope* - meaning that they are not actively managed by the user and are considered to be "always alive" by the runtime (as before). Implementation-wise, you will now see that `MemoryAddressImpl` is no longer a pair of `Object`/`long`. It is now a pair of `MemorySegment`/`long`. The `MemorySegment`, if present, tells us which segment this address has been obtained from (and hence which scope is associated with the address). If null, if means that the address has no segment, and therefore is associated with the global scope. The `long` part acts as an offset into the segment (if segment is non-null), or as an absolute address. A new test `SafeFunctionAccessTest` attempts to call native functions with (closed) scoped addresses to see if exceptions are thrown. ### *Virtual* downcall method handles There are cases where the address of a downcall handle cannot be specified when a downcall method handle is linked, but can only be known subsequently, by doing more native calls. To better support these use cases, `CLinker` now provides a factory for downcall method handles which does *not* require any function entry point. Instead, such entry point will be provided *dynamically*, via an additional prefix parameter (of type `MemoryAddress`). Many thanks to @JornVernee who implemented this improvement. The implementation changes for this range from tweaking the Java ABI support (to make sure that the prefix argument is handled as expected), to low-level hotspot changes to parameterize the generated compiled stub to use the address (dynamic) parameter. Note that regular downcall method handles (the ones that are bound to an address) are now simply obtained by getting a "virtual" method handle, and inserting a `MemoryAddress` coordinate in the first argument position. `TestVirtualCalls` has been written explicitly to test dynamic passing of address parameters but, in reality, all existing downcall tests are stressing the new implementation logic (since, as said before, the old logic is expressed as an adaptation of the new virtual method handles). The benchmark we used to test downcall performances `CallOverhead` has now been split into two: `CallOverheadConstant` vs. `CallOverheadVirtual`. ### Optimized upcall support The previous iteration of the Foreign Linker API supported intrinsification of downcall handles, which allows calls to downcall method handles to perform as fast as a regular JNI call. The dual case, calling Java code from native code (upcalls) was left unoptimized. In this iteration, @JornVernee has added intrinsics support for upcalls as well as downcalls, based on some prior work from @iwanowww. As for downcalls, a lot of the adaptation now happens in Java code, before we jump into the target method handle. As for the code which calls such target handle, changes have been made so that the native code can jump to the optimized entry point (if one exists) for such method handle more directly. The performance improvements with this new approach are rather nice, with `CLinker` upcalls being 3x-4x faster compared with regular upcalls via JNI. Again, here we have changes in the guts of the Java ABI support, as we needed to adjust the method handle specialization logic to be able to work in two directions (both from Java to native and from native to Java). On the Hotspot front, the optimization changes are in `universalUpcallHandler_x86_64.cpp`. ### Accessing restricted methods It is still the case that some of the methods in the API are "restricted" and access to these methods is disabled by default. In previous iterations, access to such methods was granted by setting a JDK read-only runtime property: `-Dforeign.restricted=permit`. In this iteration we have refined the story for accessing restricted methods (thanks @sundararajana ), by introducing a new experimental command line option in the Java launcher, namely `--enable-native-access=`. This options accepts a list of modules (separated by commas), where a module name can also be `ALL-UNNAMED` (for the unnamed module). Adding this command line flag to the launcher has the effect of allowing access to restricted methods to a given set of modules (the list of modules specified in the command line option). Access to restricted methods from any other module not in the list is disallowed and will result in an `IllegalAccessException`. When implementing this flag we considered two options: adding some resolution-time checks in the JVM (e.g. in `linkResolver`); or use `@CallerSensitive` methods. In the end we opted for the latter given that `@CallerSensitive` are generally well understood and optimized, and the general feeling was that inventing another form of callsite-dependent check might have been unnecessarily risky, given that the same checks can be implemented in Java using `@CallerSensitive`. We plan (not in 17) to add `javadoc` support by means of an annotation (like we do for preview API methods) so that the text that is currently copied and pasted in all restricted methods can be inferred automagically by javadoc. ### GitHub testing status Most platforms build and tests pass. There are a bunch of *additional* Linux platforms which do not yet work correctly: * Zero * arm * ppc * s390 The first two can be addresses easily by stubbing out few functions (I'll do that shortly). The last two are harder, as this patch moves some static functions (e.g. `long_move`, `float_move`) up to `SharedRuntime`; unfortunately, while most platforms use the same signatures for these function, on ppc and s390 that's not the case and function with same name, but incompatible signatures are defined there, leading to build issues. We will try to tweak the code around this, to make sure that these platforms remain buildable. Javadoc: http://cr.openjdk.java.net/~mcimadamore/JEP-412/v1/javadoc/jdk/incubator/foreign/package-summary.html Specdiff: http://cr.openjdk.java.net/~mcimadamore/JEP-412/v1/specdiff/overview-summary.html ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From ccheung at openjdk.java.net Tue Apr 27 18:03:38 2021 From: ccheung at openjdk.java.net (Calvin Cheung) Date: Tue, 27 Apr 2021 18:03:38 GMT Subject: RFR: 8255493: Support for pre-generated java.lang.invoke classes in CDS dynamic archive [v4] In-Reply-To: References: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> Message-ID: On Tue, 27 Apr 2021 16:53:08 GMT, Yumin Qi wrote: >> Hi, Please review >> >> When do dynamic dump, the pre-generated lambda form classes from java.lang.invoke are not stored in dynamic archive. The patch will regenerate the four holder classes, >> "java.lang.invoke.Invokers$Holder", >> "java.lang.invoke.DirectMethodHandle$Holder", >> "java.lang.invoke.DelegatingMethodHandle$Holder", >> "java.lang.invoke.LambdaForm$Holder" >> which will include the versions in static archive and new loaded functions all together and stored in dynamic archive. New test case added. >> (Minor change to PrintSharedArchiveAtExit, which the index is not consecutive) >> >> Tests: tier1,tier2,tier3,tier4 >> >> Thanks >> Yumin > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Moved log invoker lines to debug only, removed check for as_utf8_string Looks good. Just a few minor comments. src/hotspot/share/cds/archiveBuilder.cpp line 263: > 261: log_info(cds)(" obj array classes = %5d", _num_obj_array_klasses); > 262: log_info(cds)(" type array classes = %5d", _num_type_array_klasses); > 263: log_info(cds)(" symbols = %5d", _symbols->length()); Please align the '=' at line 263 with the line above. src/hotspot/share/cds/filemap.hpp line 240: > 238: size_t _ptrmap_size_in_bits; // Size of pointer relocation bitmap > 239: narrowOop _heap_obj_roots; // An objArray that stores all the roots of archived heap objects > 240: I think you can revert the changes to this file since there are only couple of blank lines addition/deletion probably by mistake. test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/TestDynamicRegenerateHolderClasses.java line 26: > 24: > 25: /* > 26: * @test Please add a `@bug` line to this file. ------------- PR: https://git.openjdk.java.net/jdk/pull/3611 From sviswanathan at openjdk.java.net Tue Apr 27 18:15:40 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Tue, 27 Apr 2021 18:15:40 GMT Subject: RFR: 8265491: Math Signum optimization for x86 [v8] In-Reply-To: References: Message-ID: On Sat, 24 Apr 2021 00:21:49 GMT, Marcus G K Williams wrote: >> x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM. >> >> We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization. >> >> Base: >> >> Benchmark Mode Cnt Score Error Units >> Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op >> Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op >> Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op >> Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op >> >> >> Optimized: >> signum intrinsic patch >> >> Benchmark Mode Cnt Score Error Units >> Signum._1_signumFloatTest avgt 5 3.769 ? 0.015 ns/op >> Signum._2_overheadFloat avgt 5 3.312 ? 0.025 ns/op >> Signum._3_signumDoubleTest avgt 5 3.765 ? 0.005 ns/op >> Signum._4_overheadDouble avgt 5 3.309 ? 0.010 ns/op >> >> >> Signed-off-by: Marcus G K Williams > > Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision: > > Fix copyright > > Signed-off-by: Marcus G K Williams src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1065: > 1063: > 1064: jcc(Assembler::equal, DONE_LABEL); > 1065: jcc(Assembler::parity, DONE_LABEL); Please add comments here to explain that equal takes care of special case for +0.0/-0.0 and parity takes care of NaN. If the argument is positive zero or negative zero, then the result is the same as the argument. If the argument is NaN, then the result is NaN. src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1076: > 1074: > 1075: if (opcode == Op_SignumF){ > 1076: xorps(dst, ExternalAddress(StubRoutines::x86::vector_float_sign_flip()), scratch); The vector_float_sign_flip is 64 bit aligned. Whereas the sse version of xorps and xorpd will need 128 bit aligned memory address. ------------- PR: https://git.openjdk.java.net/jdk/pull/3581 From minqi at openjdk.java.net Tue Apr 27 18:17:38 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 27 Apr 2021 18:17:38 GMT Subject: RFR: 8255493: Support for pre-generated java.lang.invoke classes in CDS dynamic archive [v4] In-Reply-To: References: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> Message-ID: <1vVDebQs9oZtRuQuNCZaxLuKFYG1Ud_D6rsLYJdp3Y0=.7d87e98b-2efb-4056-b935-03b0ad5d25c9@github.com> On Tue, 27 Apr 2021 17:59:19 GMT, Calvin Cheung wrote: >> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> Moved log invoker lines to debug only, removed check for as_utf8_string > > src/hotspot/share/cds/archiveBuilder.cpp line 263: > >> 261: log_info(cds)(" obj array classes = %5d", _num_obj_array_klasses); >> 262: log_info(cds)(" type array classes = %5d", _num_type_array_klasses); >> 263: log_info(cds)(" symbols = %5d", _symbols->length()); > > Please align the '=' at line 263 with the line above. Will reformat. Thanks. > test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/TestDynamicRegenerateHolderClasses.java line 26: > >> 24: >> 25: /* >> 26: * @test > > Please add a `@bug` line to this file. Will update. ------------- PR: https://git.openjdk.java.net/jdk/pull/3611 From minqi at openjdk.java.net Tue Apr 27 18:17:39 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 27 Apr 2021 18:17:39 GMT Subject: RFR: 8255493: Support for pre-generated java.lang.invoke classes in CDS dynamic archive [v4] In-Reply-To: References: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> Message-ID: On Tue, 27 Apr 2021 17:37:37 GMT, Coleen Phillimore wrote: >> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> Moved log invoker lines to debug only, removed check for as_utf8_string > > src/hotspot/share/cds/lambdaFormInvokers.cpp line 85: > >> 83: Klass* cds_klass = SystemDictionary::resolve_or_null(cds_name, THREAD); >> 84: guarantee(cds_klass != NULL, "jdk/internal/misc/CDS must exist!"); >> 85: DEBUG_ONLY(log_info(cds)("Total lambdaform lines %d", _lambdaform_lines->length());) > > No sorry, I meant > log_debug(cds)("Total lambdaform lines %d", ...) > Since this is something you don't want with -Xlog:cds at the info level. Same with line 77 Sorry, I misunderstood the comment. ------------- PR: https://git.openjdk.java.net/jdk/pull/3611 From xliu at openjdk.java.net Tue Apr 27 18:22:58 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Tue, 27 Apr 2021 18:22:58 GMT Subject: RFR: 8265867: thread.hpp defines some enums but no reference [v2] In-Reply-To: References: Message-ID: On Tue, 27 Apr 2021 05:06:53 GMT, Thomas Stuefe wrote: >> Xin Liu has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert code change about "constness". > > src/hotspot/share/runtime/thread.hpp line 1077: > >> 1075: // last_Java_sp >> 1076: bool has_last_Java_frame() const { return _anchor.has_last_Java_frame(); } >> 1077: intptr_t* last_Java_sp() const { return _anchor.last_Java_sp(); } > > Why the whitespace change? I try to align with above "const". I will format this patch better next time. ------------- PR: https://git.openjdk.java.net/jdk/pull/3702 From xliu at openjdk.java.net Tue Apr 27 18:22:57 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Tue, 27 Apr 2021 18:22:57 GMT Subject: RFR: 8265867: thread.hpp defines some enums but no reference [v2] In-Reply-To: References: Message-ID: > Deleted 2 useless enums. > This patch also added const and constexpr for the applicable member functions. Xin Liu has updated the pull request incrementally with one additional commit since the last revision: Revert code change about "constness". ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3702/files - new: https://git.openjdk.java.net/jdk/pull/3702/files/830ae1a3..244b5aa0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3702&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3702&range=00-01 Stats: 92 lines in 4 files changed: 0 ins; 0 del; 92 mod Patch: https://git.openjdk.java.net/jdk/pull/3702.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3702/head:pull/3702 PR: https://git.openjdk.java.net/jdk/pull/3702 From minqi at openjdk.java.net Tue Apr 27 18:35:05 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 27 Apr 2021 18:35:05 GMT Subject: RFR: 8255493: Support for pre-generated java.lang.invoke classes in CDS dynamic archive [v5] In-Reply-To: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> References: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> Message-ID: > Hi, Please review > > When do dynamic dump, the pre-generated lambda form classes from java.lang.invoke are not stored in dynamic archive. The patch will regenerate the four holder classes, > "java.lang.invoke.Invokers$Holder", > "java.lang.invoke.DirectMethodHandle$Holder", > "java.lang.invoke.DelegatingMethodHandle$Holder", > "java.lang.invoke.LambdaForm$Holder" > which will include the versions in static archive and new loaded functions all together and stored in dynamic archive. New test case added. > (Minor change to PrintSharedArchiveAtExit, which the index is not consecutive) > > Tests: tier1,tier2,tier3,tier4 > > Thanks > Yumin Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Changed DEBUG_ONLY to log_debug, make small changes for format, added bug tag to test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3611/files - new: https://git.openjdk.java.net/jdk/pull/3611/files/c46b64c2..ebbda846 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3611&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3611&range=03-04 Stats: 3 lines in 3 files changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3611.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3611/head:pull/3611 PR: https://git.openjdk.java.net/jdk/pull/3611 From alanb at openjdk.java.net Tue Apr 27 18:51:38 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Tue, 27 Apr 2021 18:51:38 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) In-Reply-To: References: Message-ID: <6SevcbQtVmLuygupdqgGyTXI943L_DitH0AK5r-Ou40=.d2ea73a1-0f30-46f2-b2d6-8f59db9b8a83@github.com> On Mon, 26 Apr 2021 17:10:13 GMT, Maurizio Cimadamore wrote: > This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/412 src/java.base/share/classes/java/lang/Module.java line 253: > 251: } > 252: > 253: boolean isEnableNativeAccess() { Would it be possible change isEnableNativeAccess and addNEnableNativeAccess to keep them consistent with the existing methods in this file. src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 384: > 382: Module addEnableNativeAccess(Module m); > 383: > 384: boolean isEnableNativeAccess(Module m); Probably better to co-locate these with the other module methods, and add a comment so that it's consistent with the existing methods. src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 272: > 270: BootLoader.loadModule(base); > 271: SharedSecrets.getJavaLangAccess() > 272: .addEnableNativeAccess(Modules.defineModule(null, base.descriptor(), baseUri)); This would be cleaner if you replace it with: Module baseModule = Modules.defineModule(null, base.descriptor(), baseUri); JLA.addEnableNativeAccess(baseModule); You can use JLA in addEnableNativeAccess too, no need for "jla". src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 876: > 874: } > 875: > 876: private static void addEnableNativeAccess(ModuleLayer layer) { It would be useful to add a method description in the same style as the existing methods, just to keep these methods consistent. src/java.base/share/classes/sun/nio/ch/IOUtil.java line 57: > 55: > 56: static int write(FileDescriptor fd, ByteBuffer src, long position, > 57: boolean async, NativeDispatcher nd) UnixAsynchronousSocketChannel is an outlier user of IOUtil and I think we need to see if we can avoid extending this class to async if possible. src/java.base/share/classes/sun/nio/ch/IOUtil.java line 466: > 464: } > 465: > 466: private static final JavaNioAccess NIO_ACCESS = SharedSecrets.getJavaNioAccess(); It might be cleaner to move to acquire/release methods to their own supporting class as it's not really IOUtil. ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From joe.darcy at oracle.com Tue Apr 27 19:06:44 2021 From: joe.darcy at oracle.com (Joe Darcy) Date: Tue, 27 Apr 2021 12:06:44 -0700 Subject: RFR: 8265768 [aarch64] Use glibc libm impl for dlog, dlog10, dexp iff 2.29 or greater on AArch64. In-Reply-To: References: Message-ID: <0edd130b-2bcc-7ab8-65bc-e73ec9350fb1@oracle.com> Assuming the intention is to replace the current code/intrinsics used for Math.{log, log10, exp} etc., this review should also be sent to core-libs. Thanks, -Joe On 4/23/2021 2:22 AM, gregcawthorne wrote: > Glibc 2.29 onwards provides optimised versions of log,log10,exp. > These functions have an accuracy of 0.9ulp or better in glibc > 2.29. > > Therefore this patch adds code to parse, store and check > the runtime glibcs version in os_linux.cpp/hpp. > This is then used to select the glibcs implementation of > log, log10, exp at runtime for c1 and c2, iff we have > glibc 2.29 or greater. > > This will ensure OpenJDK can benefit from future improvements > to glibc. > > Glibc adheres to the ieee754 standard, unless stated otherwise > in its spec. > > As there are no stated exceptions in the current glibc spec > for dlog, dlog10 and dexp, we can assume they currently follow > ieee754 (which testing confirms). As such, future version of > glibc are unlikely to lose this compliance with ieee754 in > future. > > W.r.t performance this patch sees ~15-30% performance improvements for > log and log10, with ~50-80% performance improvements for exp for the > common input ranged (which output real numbers). However for the NaN > and inf output ranges we see a slow down of up to a factor of 2 for > some functions and architectures. > > Due to this being the uncommon case we assert that this is a > worthwhile tradeoff. > > ------------- > > Commit messages: > - Use glibc libm impl for dlog,dlog10,dexp iff 2.29 or greater on AArch64. > > Changes: https://git.openjdk.java.net/jdk/pull/3510/files > Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3510&range=00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8265768 > Stats: 85 lines in 7 files changed: 79 ins; 5 del; 1 mod > Patch: https://git.openjdk.java.net/jdk/pull/3510.diff > Fetch: git fetch https://git.openjdk.java.net/jdk pull/3510/head:pull/3510 > > PR: https://git.openjdk.java.net/jdk/pull/3510 From iignatyev at openjdk.java.net Tue Apr 27 19:10:50 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Tue, 27 Apr 2021 19:10:50 GMT Subject: RFR: 8264806: Remove the experimental JIT compiler [v2] In-Reply-To: <_hHXNVNqB4NJAmS2mndxsKnFCg7fWWooaWMuWVL0bQA=.b8397a2a-0482-4851-9889-0432057070da@github.com> References: <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com> <_hHXNVNqB4NJAmS2mndxsKnFCg7fWWooaWMuWVL0bQA=.b8397a2a-0482-4851-9889-0432057070da@github.com> Message-ID: <95GbTmxTIqVaWrUNi-Tj9vpkSVATyUA7HoFF2v6N6GQ=.7ffe5ebb-c815-48e2-883a-797742c741ce@github.com> On Tue, 13 Apr 2021 09:30:23 GMT, Doug Simon wrote: > I guess this should really be named `isJVMCICompilerEnabled` now and the `vm.graal.enabled` predicate renamed to `vm.jvmcicompiler.enabled` but maybe that's too big a change (or can be done later). @dougxc, I don't think that we should (or even can) rename it to `vm.jvmcicompiler.enabled`. although the value of the property is indeed `true` whenever a jvmci compiler is enabled, it is used to filter out tests that are incompatible with a particular compiler -- graal. so what we can do is to change `requires/VMProps.java` to set `vm.graal.enabled` only if the jvmci compiler is indeed graal, but on the other hand, we haven't heard anyone complaining that the test coverage for their jvmci compiler has been reduced, so I don't see much of the benefit here. -- Igor ------------- PR: https://git.openjdk.java.net/jdk/pull/3421 From minqi at openjdk.java.net Tue Apr 27 19:23:44 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 27 Apr 2021 19:23:44 GMT Subject: RFR: 8255493: Support for pre-generated java.lang.invoke classes in CDS dynamic archive [v6] In-Reply-To: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> References: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> Message-ID: > Hi, Please review > > When do dynamic dump, the pre-generated lambda form classes from java.lang.invoke are not stored in dynamic archive. The patch will regenerate the four holder classes, > "java.lang.invoke.Invokers$Holder", > "java.lang.invoke.DirectMethodHandle$Holder", > "java.lang.invoke.DelegatingMethodHandle$Holder", > "java.lang.invoke.LambdaForm$Holder" > which will include the versions in static archive and new loaded functions all together and stored in dynamic archive. New test case added. > (Minor change to PrintSharedArchiveAtExit, which the index is not consecutive) > > Tests: tier1,tier2,tier3,tier4 > > Thanks > Yumin Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Removed unused function static_archive_invokers(), add back accidentally deleted empty line ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3611/files - new: https://git.openjdk.java.net/jdk/pull/3611/files/ebbda846..386f2da4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3611&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3611&range=04-05 Stats: 4 lines in 2 files changed: 1 ins; 3 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3611.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3611/head:pull/3611 PR: https://git.openjdk.java.net/jdk/pull/3611 From minqi at openjdk.java.net Tue Apr 27 19:33:35 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 27 Apr 2021 19:33:35 GMT Subject: RFR: 8255493: Support for pre-generated java.lang.invoke classes in CDS dynamic archive [v6] In-Reply-To: References: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> Message-ID: On Tue, 27 Apr 2021 19:23:44 GMT, Yumin Qi wrote: >> Hi, Please review >> >> When do dynamic dump, the pre-generated lambda form classes from java.lang.invoke are not stored in dynamic archive. The patch will regenerate the four holder classes, >> "java.lang.invoke.Invokers$Holder", >> "java.lang.invoke.DirectMethodHandle$Holder", >> "java.lang.invoke.DelegatingMethodHandle$Holder", >> "java.lang.invoke.LambdaForm$Holder" >> which will include the versions in static archive and new loaded functions all together and stored in dynamic archive. New test case added. >> (Minor change to PrintSharedArchiveAtExit, which the index is not consecutive) >> >> Tests: tier1,tier2,tier3,tier4 >> >> Thanks >> Yumin > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Removed unused function static_archive_invokers(), add back accidentally deleted empty line Please hold, there is more clean up need to do: including file headers, empty lines etc. ------------- PR: https://git.openjdk.java.net/jdk/pull/3611 From dnsimon at openjdk.java.net Tue Apr 27 19:52:22 2021 From: dnsimon at openjdk.java.net (Doug Simon) Date: Tue, 27 Apr 2021 19:52:22 GMT Subject: RFR: 8264806: Remove the experimental JIT compiler [v2] In-Reply-To: <95GbTmxTIqVaWrUNi-Tj9vpkSVATyUA7HoFF2v6N6GQ=.7ffe5ebb-c815-48e2-883a-797742c741ce@github.com> References: <_PS0KHvkB_l9YrKjZ7wLAiKb-SK761YFub4XU5mrBRc=.c32572f6-063f-4503-a20f-aa6b9115f808@github.com> <_hHXNVNqB4NJAmS2mndxsKnFCg7fWWooaWMuWVL0bQA=.b8397a2a-0482-4851-9889-0432057070da@github.com> <95GbTmxTIqVaWrUNi-Tj9vpkSVATyUA7HoFF2v6N6GQ=.7ffe5ebb-c815-48e2-883a-797742c741ce@github.com> Message-ID: On Tue, 27 Apr 2021 19:07:45 GMT, Igor Ignatyev wrote: > > I guess this should really be named `isJVMCICompilerEnabled` now and the `vm.graal.enabled` predicate renamed to `vm.jvmcicompiler.enabled` but maybe that's too big a change (or can be done later). > > @dougxc, I don't think that we should (or even can) rename it to `vm.jvmcicompiler.enabled`. although the value of the property is indeed `true` whenever a jvmci compiler is enabled, it is used to filter out tests that are incompatible with a particular compiler -- graal. so what we can do is to change `requires/VMProps.java` to set `vm.graal.enabled` only if the jvmci compiler is indeed graal, but on the other hand, we haven't heard anyone complaining that the test coverage for their jvmci compiler has been reduced, so I don't see much of the benefit here. > > -- Igor Yes, we should just it as is until a second JVMCI compiler shows up. ------------- PR: https://git.openjdk.java.net/jdk/pull/3421 From iklam at openjdk.java.net Tue Apr 27 19:54:11 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Tue, 27 Apr 2021 19:54:11 GMT Subject: RFR: 8265867: thread.hpp defines some enums but no reference [v2] In-Reply-To: References: Message-ID: <9ki_TT5R91MYcslCLrzJsm5NvA1ZxwnHaTpvR8oYJWA=.c098640e-d7cc-4970-b16f-5fa68fde5081@github.com> On Tue, 27 Apr 2021 18:22:57 GMT, Xin Liu wrote: >> Deleted 2 useless enums. >> This patch also added const and constexpr for the applicable member functions. > > Xin Liu has updated the pull request incrementally with one additional commit since the last revision: > > Revert code change about "constness". Marked as reviewed by iklam (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3702 From mcimadamore at openjdk.java.net Tue Apr 27 20:23:10 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Tue, 27 Apr 2021 20:23:10 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) In-Reply-To: <6SevcbQtVmLuygupdqgGyTXI943L_DitH0AK5r-Ou40=.d2ea73a1-0f30-46f2-b2d6-8f59db9b8a83@github.com> References: <6SevcbQtVmLuygupdqgGyTXI943L_DitH0AK5r-Ou40=.d2ea73a1-0f30-46f2-b2d6-8f59db9b8a83@github.com> Message-ID: On Tue, 27 Apr 2021 18:46:02 GMT, Alan Bateman wrote: >> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/412 > > src/java.base/share/classes/java/lang/Module.java line 253: > >> 251: } >> 252: >> 253: boolean isEnableNativeAccess() { > > Would it be possible change isEnableNativeAccess and addNEnableNativeAccess to keep them consistent with the existing methods in this file. Change as in "adding javadoc" ? Or is the naming of the method something that's bothering? > src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 384: > >> 382: Module addEnableNativeAccess(Module m); >> 383: >> 384: boolean isEnableNativeAccess(Module m); > > Probably better to co-locate these with the other module methods, and add a comment so that it's consistent with the existing methods. sure I'll fix this > src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 272: > >> 270: BootLoader.loadModule(base); >> 271: SharedSecrets.getJavaLangAccess() >> 272: .addEnableNativeAccess(Modules.defineModule(null, base.descriptor(), baseUri)); > > This would be cleaner if you replace it with: > > Module baseModule = Modules.defineModule(null, base.descriptor(), baseUri); > JLA.addEnableNativeAccess(baseModule); > > You can use JLA in addEnableNativeAccess too, no need for "jla". ok > src/java.base/share/classes/jdk/internal/module/ModuleBootstrap.java line 876: > >> 874: } >> 875: >> 876: private static void addEnableNativeAccess(ModuleLayer layer) { > > It would be useful to add a method description in the same style as the existing methods, just to keep these methods consistent. I'll fix ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From minqi at openjdk.java.net Tue Apr 27 20:44:28 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 27 Apr 2021 20:44:28 GMT Subject: RFR: 8255493: Support for pre-generated java.lang.invoke classes in CDS dynamic archive [v7] In-Reply-To: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> References: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> Message-ID: > Hi, Please review > > When do dynamic dump, the pre-generated lambda form classes from java.lang.invoke are not stored in dynamic archive. The patch will regenerate the four holder classes, > "java.lang.invoke.Invokers$Holder", > "java.lang.invoke.DirectMethodHandle$Holder", > "java.lang.invoke.DelegatingMethodHandle$Holder", > "java.lang.invoke.LambdaForm$Holder" > which will include the versions in static archive and new loaded functions all together and stored in dynamic archive. New test case added. > (Minor change to PrintSharedArchiveAtExit, which the index is not consecutive) > > Tests: tier1,tier2,tier3,tier4 > > Thanks > Yumin Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Remove unnecessary file header including ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3611/files - new: https://git.openjdk.java.net/jdk/pull/3611/files/386f2da4..6df841d8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3611&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3611&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3611.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3611/head:pull/3611 PR: https://git.openjdk.java.net/jdk/pull/3611 From minqi at openjdk.java.net Tue Apr 27 21:08:38 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Tue, 27 Apr 2021 21:08:38 GMT Subject: RFR: 8255493: Support for pre-generated java.lang.invoke classes in CDS dynamic archive [v8] In-Reply-To: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> References: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> Message-ID: > Hi, Please review > > When do dynamic dump, the pre-generated lambda form classes from java.lang.invoke are not stored in dynamic archive. The patch will regenerate the four holder classes, > "java.lang.invoke.Invokers$Holder", > "java.lang.invoke.DirectMethodHandle$Holder", > "java.lang.invoke.DelegatingMethodHandle$Holder", > "java.lang.invoke.LambdaForm$Holder" > which will include the versions in static archive and new loaded functions all together and stored in dynamic archive. New test case added. > (Minor change to PrintSharedArchiveAtExit, which the index is not consecutive) > > Tests: tier1,tier2,tier3,tier4 > > Thanks > Yumin Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Restore filemap.[ch]pp ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3611/files - new: https://git.openjdk.java.net/jdk/pull/3611/files/6df841d8..a63af745 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3611&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3611&range=06-07 Stats: 8 lines in 2 files changed: 3 ins; 2 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3611.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3611/head:pull/3611 PR: https://git.openjdk.java.net/jdk/pull/3611 From xliu at openjdk.java.net Tue Apr 27 21:16:07 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Tue, 27 Apr 2021 21:16:07 GMT Subject: RFR: 8265867: thread.hpp defines some enums but no reference [v2] In-Reply-To: References: Message-ID: On Tue, 27 Apr 2021 18:22:57 GMT, Xin Liu wrote: >> Deleted 2 useless enums. >> This patch also added const and constexpr for the applicable member functions. > > Xin Liu has updated the pull request incrementally with one additional commit since the last revision: > > Revert code change about "constness". Thanks reviewers. I took a look at the building failure on macos. it should not be relevant to this patch. Linker editor can't resolve the symbol `__Copy_conjoint_words` on macos/arm64. 2021-04-27T18:48:46.3842240Z Undefined symbols for architecture arm64: 2021-04-27T18:48:46.3873510Z "__Copy_conjoint_words", referenced from: 2021-04-27T18:48:46.3894950Z G1FullGCCompactTask::G1CompactRegionClosure::apply(oopDesc*) in g1FullGCCompactTask.o 2021-04-27T18:48:46.3931360Z PSParallelCompact::decrement_destination_counts(ParCompactionManager*, PSParallelCompact::SpaceId, unsigned long, HeapWordImpl**) in psParallelCompact.o 2021-04-27T18:48:46.3950530Z PSParallelCompact::copy_back(HeapWordImpl**, HeapWordImpl**) in psParallelCompact.o 2021-04-27T18:48:46.3997600Z PSParallelCompact::fill_region(ParCompactionManager*, MoveAndUpdateClosure&, unsigned long) in psParallelCompact.o 2021-04-27T18:48:46.4034130Z MoveAndUpdateClosure::copy_partial_obj() in psParallelCompact.o 2021-04-27T18:48:46.4052290Z MoveAndUpdateClosure::copy_until_full() in psParallelCompact.o 2021-04-27T18:48:46.4101250Z MoveAndUpdateClosure::do_addr(HeapWordImpl**, unsigned long) in psParallelCompact.o 2021-04-27T18:48:46.4137880Z ... ... 2021-04-27T18:48:46.4792490Z ld: symbol(s) not found for architecture arm64 2021-04-27T18:48:46.4834120Z clang: error: linker command failed with exit code 1 (use -v to see invocation) 2021-04-27T18:48:46.4919160Z gmake[3]: *** [lib/CompileJvm.gmk:144: /Users/runner/work/jdk/jdk/jdk/build/macos-aarch64/support/modules_libs/java.base/server/libjvm.dylib] Error 1 2021-04-27T18:48:46.4920590Z gmake[3]: *** Waiting for unfinished jobs.... 2021-04-27T18:48:46.7713910Z gmake[2]: *** [make/Main.gmk:255: hotspot-server-libs] Error 2 ------------- PR: https://git.openjdk.java.net/jdk/pull/3702 From kevinw at openjdk.java.net Tue Apr 27 21:17:09 2021 From: kevinw at openjdk.java.net (Kevin Walls) Date: Tue, 27 Apr 2021 21:17:09 GMT Subject: RFR: 8264593: debug.cpp utilities should be available in product builds. [v2] In-Reply-To: References: Message-ID: On Mon, 26 Apr 2021 21:09:28 GMT, Kevin Walls wrote: >> src/hotspot/share/utilities/debug.cpp line 495: >> >>> 493: // AllocatedObj in allocation.hpp is not defined for PRODUCT >>> 494: extern "C" JNIEXPORT void pa(intptr_t p) { ((AllocatedObj*) p)->print(); } >>> 495: #endif >> >> I don't really think 'pa' is interesting enough to keep. > > Thanks Coleen - I haven't used pa either. Will update without it... I've taken out pa(intptr_t) and the misleading comment above it saying "pv". Also removed pv() from the help, which was perhaps an old name for pa. ------------- PR: https://git.openjdk.java.net/jdk/pull/3307 From github.com+168222+mgkwill at openjdk.java.net Tue Apr 27 21:38:40 2021 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Tue, 27 Apr 2021 21:38:40 GMT Subject: RFR: 8265491: Math Signum optimization for x86 [v9] In-Reply-To: References: Message-ID: > x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM. > > We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization. > > Base: > > Benchmark Mode Cnt Score Error Units > Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op > Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op > Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op > Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op > > > Optimized: > signum intrinsic patch > > Benchmark Mode Cnt Score Error Units > Signum._1_signumFloatTest avgt 5 3.769 ? 0.015 ns/op > Signum._2_overheadFloat avgt 5 3.312 ? 0.025 ns/op > Signum._3_signumDoubleTest avgt 5 3.765 ? 0.005 ns/op > Signum._4_overheadDouble avgt 5 3.309 ? 0.010 ns/op > > > Signed-off-by: Marcus G K Williams Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision: sviswa7 review Signed-off-by: Marcus G K Williams ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3581/files - new: https://git.openjdk.java.net/jdk/pull/3581/files/7d54845f..07054334 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3581&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3581&range=07-08 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3581.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3581/head:pull/3581 PR: https://git.openjdk.java.net/jdk/pull/3581 From github.com+168222+mgkwill at openjdk.java.net Tue Apr 27 21:43:11 2021 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Tue, 27 Apr 2021 21:43:11 GMT Subject: RFR: 8265491: Math Signum optimization for x86 [v9] In-Reply-To: References: Message-ID: On Tue, 27 Apr 2021 21:38:40 GMT, Marcus G K Williams wrote: >> x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM. >> >> We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization. >> >> Base: >> >> Benchmark Mode Cnt Score Error Units >> Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op >> Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op >> Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op >> Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op >> >> >> Optimized: >> signum intrinsic patch >> >> Benchmark Mode Cnt Score Error Units >> Signum._1_signumFloatTest avgt 5 3.769 ? 0.015 ns/op >> Signum._2_overheadFloat avgt 5 3.312 ? 0.025 ns/op >> Signum._3_signumDoubleTest avgt 5 3.765 ? 0.005 ns/op >> Signum._4_overheadDouble avgt 5 3.309 ? 0.010 ns/op >> >> >> Signed-off-by: Marcus G K Williams > > Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision: > > sviswa7 review > > Signed-off-by: Marcus G K Williams Thanks for the review @sviswa7. I've updated to `StubRoutines::x86::float_sign_flip()` & `StubRoutines::x86::double_sign_flip()` as I was using when the code was in the src/hotspot/cpu/x86/x86.ad. If I understood your comment correctly this should use 128 bit aligned. I've added comments as suggested. ------------- PR: https://git.openjdk.java.net/jdk/pull/3581 From amenkov at openjdk.java.net Tue Apr 27 21:47:20 2021 From: amenkov at openjdk.java.net (Alex Menkov) Date: Tue, 27 Apr 2021 21:47:20 GMT Subject: RFR: 8262002: java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.sh failed with "TestCaseScaffoldException: DummyClassWithLVT did not match .class file" [v2] In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 20:51:49 GMT, Alex Menkov wrote: >> The test actually failed starting from jdk13, but the error is masked by JDK-8264667 (and shell part of the test didn't verify result of the java execution) >> The fix: >> - updates JvmtiClassFileReconstituter to add attributes in the same order as javac does >> - makes the test java instead of shell >> - added workaround for JDK-8264667 >> - test code is ready to ignore order of attributes > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > Updated the fix accordingly feedback Ping ------------- PR: https://git.openjdk.java.net/jdk/pull/3426 From github.com+168222+mgkwill at openjdk.java.net Tue Apr 27 22:20:38 2021 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Tue, 27 Apr 2021 22:20:38 GMT Subject: RFR: 8265491: Math Signum optimization for x86 [v10] In-Reply-To: References: Message-ID: > x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM. > > We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization. > > Base: > > Benchmark Mode Cnt Score Error Units > Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op > Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op > Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op > Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op > > > Optimized: > signum intrinsic patch > > Benchmark Mode Cnt Score Error Units > Signum._1_signumFloatTest avgt 5 3.769 ? 0.015 ns/op > Signum._2_overheadFloat avgt 5 3.312 ? 0.025 ns/op > Signum._3_signumDoubleTest avgt 5 3.765 ? 0.005 ns/op > Signum._4_overheadDouble avgt 5 3.309 ? 0.010 ns/op > > > Signed-off-by: Marcus G K Williams Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision: Handle x86 float/dbl signflip Signed-off-by: Marcus G K Williams ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3581/files - new: https://git.openjdk.java.net/jdk/pull/3581/files/07054334..7044d9a6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3581&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3581&range=08-09 Stats: 29 lines in 1 file changed: 27 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3581.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3581/head:pull/3581 PR: https://git.openjdk.java.net/jdk/pull/3581 From coleenp at openjdk.java.net Tue Apr 27 22:29:08 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 27 Apr 2021 22:29:08 GMT Subject: RFR: 8262002: java/lang/instrument/VerifyLocalVariableTableOnRetransformTest.sh failed with "TestCaseScaffoldException: DummyClassWithLVT did not match .class file" [v2] In-Reply-To: References: Message-ID: On Wed, 21 Apr 2021 20:51:49 GMT, Alex Menkov wrote: >> The test actually failed starting from jdk13, but the error is masked by JDK-8264667 (and shell part of the test didn't verify result of the java execution) >> The fix: >> - updates JvmtiClassFileReconstituter to add attributes in the same order as javac does >> - makes the test java instead of shell >> - added workaround for JDK-8264667 >> - test code is ready to ignore order of attributes > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > Updated the fix accordingly feedback Looks good and great to replace the shell file in the process. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3426 From coleenp at openjdk.java.net Tue Apr 27 22:31:10 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 27 Apr 2021 22:31:10 GMT Subject: RFR: 8265867: thread.hpp defines some enums but no reference [v2] In-Reply-To: References: Message-ID: On Tue, 27 Apr 2021 18:22:57 GMT, Xin Liu wrote: >> Deleted 2 useless enums. >> This patch also added const and constexpr for the applicable member functions. > > Xin Liu has updated the pull request incrementally with one additional commit since the last revision: > > Revert code change about "constness". Looks good! ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3702 From coleenp at openjdk.java.net Tue Apr 27 22:51:10 2021 From: coleenp at openjdk.java.net (Coleen Phillimore) Date: Tue, 27 Apr 2021 22:51:10 GMT Subject: RFR: 8254598: StringDedupTable should use OopStorage In-Reply-To: References: Message-ID: <4YgAwCoXuOzm1572oV0RKg3zIpkjr-KtAMmsCVEztoY=.7b93caa9-27f5-4e7e-813d-0ecfa8724043@github.com> On Fri, 23 Apr 2021 19:48:47 GMT, Kim Barrett wrote: > Please review this change to the String Deduplication facility. It is being > changed to use OopStorage to hold weak references to relevant objects, > rather than bespoke data structures requiring dedicated processing phases by > supporting GCs. > > (The Shenandoah update was contributed by Zhengyu Gu.) > > This change significantly simplifies the interface between a given GC and > the String Deduplication facility, which should make it much easier for > other GCs to opt in. However, this change does not alter the set of GCs > providing support; currently only G1 and Shenandoah support string > deduplication. Adding support by other GCs will be in followup RFEs. > > Reviewing via the diffs might not be all that useful for some parts, as > several files have been essentially completely replaced, and a number of > files have been added or eliminated. The full webrev might be a better > place to look. > > The major changes are in gc/shared/stringdedup/* and in the supporting > collectors, but there are also some smaller changes in other places, most > notably classfile/{stringTable,javaClasses}. > > This change is additionally labeled for review by core-libs, although there > are no source changes there. This change injects a byte field of bits into > java.lang.String, using one of the previously unused padding bytes in that > class. (There were two unused bytes, now only one.) > > Testing: > mach5 tier1-2 with and without -XX:+UseStringDeduplication > > Locally (linux-x64) ran all of the existing tests that use string > deduplication with both G1 and Shenandoah. Note that > TestStringDeduplicationInterned.java is disabled for shenandoah, as it > currently fails, for reasons I haven't figured out but suspect are test > related. > > - gc/stringdedup/ -- these used to be in gc/g1 > - runtime/cds/SharedStringsDedup.java > - runtime/cds/appcds/cacheObject/DifferentHeapSizes.java > - runtime/cds/appcds/sharedStrings/* > > shenandoah-only: > - gc/shenandoah/jvmti/TestHeapDump.java > - gc/shenandoah/TestStringDedup.java > - gc/shenandoah/TestStringDedupStress.java > > Performance tested baseline, baseline + stringdedup, new with stringdedup, > finding no significant differences. I looked at the runtime code, which looks fine. I didn't read the GC code. src/hotspot/share/classfile/javaClasses.inline.hpp line 77: > 75: > 76: uint8_t* java_lang_String::flags_addr(oop java_string) { > 77: assert(_initialized, "Mut be initialized"); typo: must src/hotspot/share/classfile/stringTable.cpp line 784: > 782: SharedStringIterator iter(f); > 783: _shared_table.iterate(&iter); > 784: } So with this change (somewhere below) do you no longer deduplicate strings from the shared string table? ie // The CDS archive does not include the string deduplication table. Only the string // table is saved in the archive. The shared strings from CDS archive need to be // added to the string deduplication table before deduplication occurs. That is // done in the beginning of the StringDedupThread (see StringDedupThread::do_deduplication()). void StringDedupThread::deduplicate_shared_strings(StringDedupStat* stat) { StringDedupSharedClosure sharedStringDedup(stat); StringTable::shared_oops_do(&sharedStringDedup); } Asking @iklam to have a look then. src/hotspot/share/runtime/globals.hpp line 1994: > 1992: \ > 1993: product(uint64_t, StringDeduplicationHashSeed, 0, DIAGNOSTIC, \ > 1994: "Seed for the table hashing function; 0 requests computed seed") \ Should these two really be develop() options? src/hotspot/share/runtime/mutexLocker.cpp line 239: > 237: def(StringDedupQueue_lock , PaddedMonitor, leaf, true, _safepoint_check_never); > 238: def(StringDedupTable_lock , PaddedMutex , leaf + 1, true, _safepoint_check_never); > 239: } Why weren't these duplicate definitions? This is disturbing. ------------- Marked as reviewed by coleenp (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3662 From dholmes at openjdk.java.net Tue Apr 27 23:30:44 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Tue, 27 Apr 2021 23:30:44 GMT Subject: RFR: 8255493: Support for pre-generated java.lang.invoke classes in CDS dynamic archive [v8] In-Reply-To: References: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> Message-ID: <2Cbv0djuFx5CkDh_FZRm84B5vW3EjtUKcG5_8sFamt4=.39933cd9-a3bd-4af7-be36-e8dd4a8ad43a@github.com> On Tue, 27 Apr 2021 21:08:38 GMT, Yumin Qi wrote: >> Hi, Please review >> >> When do dynamic dump, the pre-generated lambda form classes from java.lang.invoke are not stored in dynamic archive. The patch will regenerate the four holder classes, >> "java.lang.invoke.Invokers$Holder", >> "java.lang.invoke.DirectMethodHandle$Holder", >> "java.lang.invoke.DelegatingMethodHandle$Holder", >> "java.lang.invoke.LambdaForm$Holder" >> which will include the versions in static archive and new loaded functions all together and stored in dynamic archive. New test case added. >> (Minor change to PrintSharedArchiveAtExit, which the index is not consecutive) >> >> Tests: tier1,tier2,tier3,tier4 >> >> Thanks >> Yumin > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Restore filemap.[ch]pp Hi Yumin, A few comments below - the exception issue still remains. I can't really comment on the actual archiving logic here as I'm not familiar enough with the design or code. Thanks, David src/hotspot/share/cds/dynamicArchive.cpp line 374: > 372: JavaThread* THREAD = JavaThread::current(); > 373: log_info(cds, dynamic)("Regenerate lambdaform holder classes ..."); > 374: LambdaFormInvokers::regenerate_holder_classes(THREAD); You still have not addressed the exception problem here. This call can return early with an exception pending due to line 89 in the called method, which uses CHECK. That exception will escape up to the Java code after the VM operation completes. Note: If `regenerate_holder_classes` is changed to suppress all exceptions then it should not be declared TRAPS and there is no need to pass THREAD (manifest [Java]Thread::current() internally as needed). src/hotspot/share/cds/lambdaFormInvokers.cpp line 67: > 65: void LambdaFormInvokers::append_filtered(char* line) { > 66: for (int k = 0; k < NUM_FILTER; k++) { > 67: if (strstr(line, filter[k]) != nullptr) { Do you really want to match anywhere in the string? I'm assuming the line should start with the filter? src/hotspot/share/cds/lambdaFormInvokers.cpp line 185: > 183: int len = (int)strlen(str); > 184: Array* line = ArchiveBuilder::new_ro_array(len+1); > 185: strcpy(line->adr_at(0), str); // copies terminating zero as well Should use strncpy for safety (code checkers will flag this). src/hotspot/share/classfile/systemDictionaryShared.cpp line 2277: > 2275: void do_value(const RunTimeSharedClassInfo* record) { > 2276: ResourceMark rm; > 2277: _st->print_cr("%4d: %s %s", ++_index, record->_klass->external_name(), Not clear why the _index handling is changing. src/hotspot/share/classfile/systemDictionaryShared.cpp line 2297: > 2295: class_loader_name_for_shared(k)); > 2296: k = k->next_link(); > 2297: _index++; Not clear why the _index handling is changing. ------------- Changes requested by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3611 From suenaga at oss.nttdata.com Tue Apr 27 23:35:58 2021 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Wed, 28 Apr 2021 08:35:58 +0900 Subject: [EXTERNAL] [EXTERNAL] Request For Comment: Asynchronous Logging In-Reply-To: References: <7FEF3035-8926-467C-AD7B-A001A9C8FD5B@amazon.com> <2170bebc-e5a2-219c-0a4b-f41623098c43@amazon.com> Message-ID: <3579bad2-a6a0-fd84-22e6-09d175df7a4b@oss.nttdata.com> Hi Xin, On 2021/04/28 2:17, Liu, Xin wrote: > Hi, > > I would like to report my current progress. I have finished all pending > tasks except "hoist async_mode to base class for stdout/err". May I ask > to defer it after this PR? I will create an issue and work on it > immediately after this PR. It's not difficult but I need to modify the > existing interfaces. I would like to keep this PR almost "added" to ease > reviewers. > > If Yasumasa allows me to do so, now the only blocker is CSR. it seems > that Iom and Thomas agree with a global option. Shall we go that way? I agree with you, but I'm not clear a bit between "async=" in -Xlog and -XX:+AsyncLogging. CSR says about them in below, but I think they are not same because -XX:AsyncLogging affects global, on the other hand "async=" affects in each log output. Is it right? ----- Unified Logging framework can define a global option -Xlog:async[=true|false]. The effect is same as -XX:+/-AsyncLogging ----- Thanks, Yasumasa > Meanwhile, I have pushed all my code to github: > https://github.com/openjdk/jdk/pull/3135 > > Could you take a look it? > > ------------------------------------------------------------- > | request | Status | > ------------------------------------------------------------- > | independent NonJavaThread | done | > |-----------------------------------------------------------| > | pass tier1-test with +AsyncLogging | [1] | > |-----------------------------------------------------------| > | inject meta-info to display no. of dropping msg. | done | > |-----------------------------------------------------------| > | support jcmd VM.log | done | > |-----------------------------------------------------------| > | preserve accurate decorations | | > |-----------------------------------------------------------<- progress > | hoist async_mode to base class for stdout/err| | > |-----------------------------------------------------------| > | CSR |JDK-8264323 | > |-----------------------------------------------------------<- consensus > |use string table over malloc | | > ------------------------------------------------------------| > |use lock-free data structure. | | > ------------------------------------------------------------- > > > [1] the only exception is serviceability/dcmd/gc/RunGCTest.java. it > emits gclog and checks result right away without any synchronization. if > we do run jtreg test with async logging, I need to add an flushing api > in whitebox. > > > thanks, > --lx > From sviswanathan at openjdk.java.net Tue Apr 27 23:37:52 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Tue, 27 Apr 2021 23:37:52 GMT Subject: RFR: 8265491: Math Signum optimization for x86 [v9] In-Reply-To: References: Message-ID: On Tue, 27 Apr 2021 21:40:24 GMT, Marcus G K Williams wrote: >> Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision: >> >> sviswa7 review >> >> Signed-off-by: Marcus G K Williams > > Thanks for the review @sviswa7. > > I've updated to `StubRoutines::x86::float_sign_flip()` & `StubRoutines::x86::double_sign_flip()` as I was using when the code was in the src/hotspot/cpu/x86/x86.ad. If I understood your comment correctly this should use 128 bit aligned. > > I've added comments as suggested. @mgkwill I was wrong. It looks like the CodeEntryAlignment is set to 16 bytes i.e. 128 bits as minimum (globals_x86.hpp). So please continue to use the vector_float_sign_flip and vector_double_sign_flip masks. Xorps and xorpd are vector instructions and we should use the vector masks here. ------------- PR: https://git.openjdk.java.net/jdk/pull/3581 From psandoz at openjdk.java.net Wed Apr 28 00:17:54 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Wed, 28 Apr 2021 00:17:54 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) In-Reply-To: References: Message-ID: On Mon, 26 Apr 2021 17:10:13 GMT, Maurizio Cimadamore wrote: > This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/412 The Java changes are mostly familiar to me, having reviewed many PRs in the Panama repository, hence the lack of specific comments here. I did a pass through the changes and nothing major stood out to me. The new API changes make it much easy to build APIs around memory segments, exposing and reusing resource scope, acquiring/releasing on resource scope, where necessary. ------------- Marked as reviewed by psandoz (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3699 From dholmes at openjdk.java.net Wed Apr 28 00:24:55 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 28 Apr 2021 00:24:55 GMT Subject: RFR: 8265867: thread.hpp defines some enums but no reference [v2] In-Reply-To: References: Message-ID: On Tue, 27 Apr 2021 18:22:57 GMT, Xin Liu wrote: >> Deleted 2 useless enums. >> This patch also added const and constexpr for the applicable member functions. > > Xin Liu has updated the pull request incrementally with one additional commit since the last revision: > > Revert code change about "constness". Looks good - and now trivial :) Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3702 From iklam at openjdk.java.net Wed Apr 28 00:31:57 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 28 Apr 2021 00:31:57 GMT Subject: RFR: 8254598: StringDedupTable should use OopStorage In-Reply-To: <4YgAwCoXuOzm1572oV0RKg3zIpkjr-KtAMmsCVEztoY=.7b93caa9-27f5-4e7e-813d-0ecfa8724043@github.com> References: <4YgAwCoXuOzm1572oV0RKg3zIpkjr-KtAMmsCVEztoY=.7b93caa9-27f5-4e7e-813d-0ecfa8724043@github.com> Message-ID: On Tue, 27 Apr 2021 22:47:06 GMT, Coleen Phillimore wrote: >> Please review this change to the String Deduplication facility. It is being >> changed to use OopStorage to hold weak references to relevant objects, >> rather than bespoke data structures requiring dedicated processing phases by >> supporting GCs. >> >> (The Shenandoah update was contributed by Zhengyu Gu.) >> >> This change significantly simplifies the interface between a given GC and >> the String Deduplication facility, which should make it much easier for >> other GCs to opt in. However, this change does not alter the set of GCs >> providing support; currently only G1 and Shenandoah support string >> deduplication. Adding support by other GCs will be in followup RFEs. >> >> Reviewing via the diffs might not be all that useful for some parts, as >> several files have been essentially completely replaced, and a number of >> files have been added or eliminated. The full webrev might be a better >> place to look. >> >> The major changes are in gc/shared/stringdedup/* and in the supporting >> collectors, but there are also some smaller changes in other places, most >> notably classfile/{stringTable,javaClasses}. >> >> This change is additionally labeled for review by core-libs, although there >> are no source changes there. This change injects a byte field of bits into >> java.lang.String, using one of the previously unused padding bytes in that >> class. (There were two unused bytes, now only one.) >> >> Testing: >> mach5 tier1-2 with and without -XX:+UseStringDeduplication >> >> Locally (linux-x64) ran all of the existing tests that use string >> deduplication with both G1 and Shenandoah. Note that >> TestStringDeduplicationInterned.java is disabled for shenandoah, as it >> currently fails, for reasons I haven't figured out but suspect are test >> related. >> >> - gc/stringdedup/ -- these used to be in gc/g1 >> - runtime/cds/SharedStringsDedup.java >> - runtime/cds/appcds/cacheObject/DifferentHeapSizes.java >> - runtime/cds/appcds/sharedStrings/* >> >> shenandoah-only: >> - gc/shenandoah/jvmti/TestHeapDump.java >> - gc/shenandoah/TestStringDedup.java >> - gc/shenandoah/TestStringDedupStress.java >> >> Performance tested baseline, baseline + stringdedup, new with stringdedup, >> finding no significant differences. > > src/hotspot/share/classfile/stringTable.cpp line 784: > >> 782: SharedStringIterator iter(f); >> 783: _shared_table.iterate(&iter); >> 784: } > > So with this change (somewhere below) do you no longer deduplicate strings from the shared string table? ie > > // The CDS archive does not include the string deduplication table. Only the string > // table is saved in the archive. The shared strings from CDS archive need to be > // added to the string deduplication table before deduplication occurs. That is > // done in the beginning of the StringDedupThread (see StringDedupThread::do_deduplication()). > void StringDedupThread::deduplicate_shared_strings(StringDedupStat* stat) { > StringDedupSharedClosure sharedStringDedup(stat); > StringTable::shared_oops_do(&sharedStringDedup); > } > Asking @iklam to have a look then. If I understand correctly, we no longer need to add the entire set of shared strings into the dedup table. +// As a space optimization, when shared StringTable entries exist the shared +// part of the StringTable is also used as a source for byte arrays. This +// permits deduplication of strings against those shared entries without +// recording them in this table too. +class StringDedup::Table : AllStatic { ... +void StringDedup::Table::deduplicate(oop java_string) { + assert(java_lang_String::is_instance(java_string), "precondition"); + _cur_stat.inc_inspected(); + if ((StringTable::shared_entry_count() > 0) && + try_deduplicate_shared(java_string)) { + return; // Done if deduplicated against shared StringTable. ------------- PR: https://git.openjdk.java.net/jdk/pull/3662 From iklam at openjdk.java.net Wed Apr 28 00:53:53 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 28 Apr 2021 00:53:53 GMT Subject: RFR: 8254598: StringDedupTable should use OopStorage In-Reply-To: References: Message-ID: <8yDFk4JdgCTBjvxuLDC1Bkqel_WPwGXibQyU9yyxM0k=.f317ce73-527d-4012-ae50-4142ea0ead76@github.com> On Fri, 23 Apr 2021 19:48:47 GMT, Kim Barrett wrote: > Please review this change to the String Deduplication facility. It is being > changed to use OopStorage to hold weak references to relevant objects, > rather than bespoke data structures requiring dedicated processing phases by > supporting GCs. > > (The Shenandoah update was contributed by Zhengyu Gu.) > > This change significantly simplifies the interface between a given GC and > the String Deduplication facility, which should make it much easier for > other GCs to opt in. However, this change does not alter the set of GCs > providing support; currently only G1 and Shenandoah support string > deduplication. Adding support by other GCs will be in followup RFEs. > > Reviewing via the diffs might not be all that useful for some parts, as > several files have been essentially completely replaced, and a number of > files have been added or eliminated. The full webrev might be a better > place to look. > > The major changes are in gc/shared/stringdedup/* and in the supporting > collectors, but there are also some smaller changes in other places, most > notably classfile/{stringTable,javaClasses}. > > This change is additionally labeled for review by core-libs, although there > are no source changes there. This change injects a byte field of bits into > java.lang.String, using one of the previously unused padding bytes in that > class. (There were two unused bytes, now only one.) > > Testing: > mach5 tier1-2 with and without -XX:+UseStringDeduplication > > Locally (linux-x64) ran all of the existing tests that use string > deduplication with both G1 and Shenandoah. Note that > TestStringDeduplicationInterned.java is disabled for shenandoah, as it > currently fails, for reasons I haven't figured out but suspect are test > related. > > - gc/stringdedup/ -- these used to be in gc/g1 > - runtime/cds/SharedStringsDedup.java > - runtime/cds/appcds/cacheObject/DifferentHeapSizes.java > - runtime/cds/appcds/sharedStrings/* > > shenandoah-only: > - gc/shenandoah/jvmti/TestHeapDump.java > - gc/shenandoah/TestStringDedup.java > - gc/shenandoah/TestStringDedupStress.java > > Performance tested baseline, baseline + stringdedup, new with stringdedup, > finding no significant differences. Changes requested by iklam (Reviewer). src/hotspot/share/gc/shared/stringdedup/stringDedupTable.cpp line 557: > 555: // non-latin1, and deduplicating if we find a match. For deduplication we > 556: // only care if the arrays consist of the same sequence of bytes. > 557: const jchar* chars = static_cast(value->base(T_CHAR)); The encoding of the shared strings always match CompactStrings. Otherwise the CDS archive will fail to map. E.g., $ java -XX:-CompactStrings -Xshare:dump $ java -XX:+CompactStrings -Xlog:cds -version ... [0.032s][info][cds] UseSharedSpaces: The shared archive file's CompactStrings setting (disabled) does not equal the current CompactStrings setting (enabled). [0.032s][info][cds] UseSharedSpaces: Unable to map shared spaces ... So you can avoid this `if` block when `CompactStrings == true`. The `!java_lang_String::is_latin1(found)` check below can be changed to an assert. Also, I think we need an explicit test case where you'd return `true` at line 564. I can write a new test case and email to you. I think it will involve dumping an archive with `-XX:-CompactStrings`. ------------- PR: https://git.openjdk.java.net/jdk/pull/3662 From github.com+168222+mgkwill at openjdk.java.net Wed Apr 28 01:39:23 2021 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Wed, 28 Apr 2021 01:39:23 GMT Subject: RFR: 8265491: Math Signum optimization for x86 [v11] In-Reply-To: References: Message-ID: > x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM. > > We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization. > > Base: > > Benchmark Mode Cnt Score Error Units > Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op > Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op > Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op > Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op > > > Optimized: > signum intrinsic patch > > Benchmark Mode Cnt Score Error Units > Signum._1_signumFloatTest avgt 5 3.769 ? 0.015 ns/op > Signum._2_overheadFloat avgt 5 3.312 ? 0.025 ns/op > Signum._3_signumDoubleTest avgt 5 3.765 ? 0.005 ns/op > Signum._4_overheadDouble avgt 5 3.309 ? 0.010 ns/op > > > Signed-off-by: Marcus G K Williams Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision: Revert to vector _sign_flip Signed-off-by: Marcus G K Williams ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3581/files - new: https://git.openjdk.java.net/jdk/pull/3581/files/7044d9a6..c3478950 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3581&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3581&range=09-10 Stats: 29 lines in 1 file changed: 0 ins; 27 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3581.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3581/head:pull/3581 PR: https://git.openjdk.java.net/jdk/pull/3581 From github.com+168222+mgkwill at openjdk.java.net Wed Apr 28 01:39:24 2021 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Wed, 28 Apr 2021 01:39:24 GMT Subject: RFR: 8265491: Math Signum optimization for x86 [v9] In-Reply-To: References: Message-ID: <09seyLuNve6Sw3scAsRb18rKnrkcdPsmIyprf17tBNs=.14998c96-d2ed-44c0-99e1-e17f37d32d70@github.com> On Tue, 27 Apr 2021 21:40:24 GMT, Marcus G K Williams wrote: >> Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision: >> >> sviswa7 review >> >> Signed-off-by: Marcus G K Williams > > Thanks for the review @sviswa7. > > I've updated to `StubRoutines::x86::float_sign_flip()` & `StubRoutines::x86::double_sign_flip()` as I was using when the code was in the src/hotspot/cpu/x86/x86.ad. If I understood your comment correctly this should use 128 bit aligned. > > I've added comments as suggested. > @mgkwill I was wrong. It looks like the CodeEntryAlignment is set to 16 bytes i.e. 128 bits as minimum (globals_x86.hpp). So please continue to use the vector_float_sign_flip and vector_double_sign_flip masks. Xorps and xorpd are vector instructions and we should use the vector masks here. Thanks @sviswa7. I've reverted to `StubRoutines::x86::vector_float_sign_flip(`) `StubRoutines::x86::vector_double_sign_flip()` ------------- PR: https://git.openjdk.java.net/jdk/pull/3581 From sviswanathan at openjdk.java.net Wed Apr 28 01:39:25 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Wed, 28 Apr 2021 01:39:25 GMT Subject: RFR: 8265491: Math Signum optimization for x86 [v10] In-Reply-To: References: Message-ID: <5qYmiJljiuGzgble4BcC6uHd1xSHpewfwMqxpWmItJE=.4e7f68ec-9eb8-42db-95e1-4e2b38820cfd@github.com> On Tue, 27 Apr 2021 22:20:38 GMT, Marcus G K Williams wrote: >> x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM. >> >> We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization. >> >> Base: >> >> Benchmark Mode Cnt Score Error Units >> Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op >> Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op >> Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op >> Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op >> >> >> Optimized: >> signum intrinsic patch >> >> Benchmark Mode Cnt Score Error Units >> Signum._1_signumFloatTest avgt 5 3.769 ? 0.015 ns/op >> Signum._2_overheadFloat avgt 5 3.312 ? 0.025 ns/op >> Signum._3_signumDoubleTest avgt 5 3.765 ? 0.005 ns/op >> Signum._4_overheadDouble avgt 5 3.309 ? 0.010 ns/op >> >> >> Signed-off-by: Marcus G K Williams > > Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision: > > Handle x86 float/dbl signflip > > Signed-off-by: Marcus G K Williams Looks good to me. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/3581 From minqi at openjdk.java.net Wed Apr 28 03:01:12 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 28 Apr 2021 03:01:12 GMT Subject: RFR: 8255493: Support for pre-generated java.lang.invoke classes in CDS dynamic archive [v8] In-Reply-To: <2Cbv0djuFx5CkDh_FZRm84B5vW3EjtUKcG5_8sFamt4=.39933cd9-a3bd-4af7-be36-e8dd4a8ad43a@github.com> References: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> <2Cbv0djuFx5CkDh_FZRm84B5vW3EjtUKcG5_8sFamt4=.39933cd9-a3bd-4af7-be36-e8dd4a8ad43a@github.com> Message-ID: On Tue, 27 Apr 2021 23:17:15 GMT, David Holmes wrote: >> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> Restore filemap.[ch]pp > > src/hotspot/share/cds/dynamicArchive.cpp line 374: > >> 372: JavaThread* THREAD = JavaThread::current(); >> 373: log_info(cds, dynamic)("Regenerate lambdaform holder classes ..."); >> 374: LambdaFormInvokers::regenerate_holder_classes(THREAD); > > You still have not addressed the exception problem here. This call can return early with an exception pending due to line 89 in the called method, which uses CHECK. That exception will escape up to the Java code after the VM operation completes. > > Note: If `regenerate_holder_classes` is changed to suppress all exceptions then it should not be declared TRAPS and there is no need to pass THREAD (manifest [Java]Thread::current() internally as needed). Thanks for pointing this out, I checked the function LambdaFormInvokers::regenerate_holder_classes again. Looks the TRAPS can be removed. There are two cases: 1) If any allocation failed due to OOM, vm will exit except for the line 124: char *buf = resource_allocate_bytes(THREAD, len, AllocFailStrategy::RETURN_NULL); if (buf == nullptr) { log_info(cds)("Out of memory when reloading class %s, quit", class_name); return; } 2) CDS.generateLambdaFormHolderClasses may throw exception, the exception is supressed inside the function. So I will remove the TRAPS. > src/hotspot/share/cds/lambdaFormInvokers.cpp line 185: > >> 183: int len = (int)strlen(str); >> 184: Array* line = ArchiveBuilder::new_ro_array(len+1); >> 185: strcpy(line->adr_at(0), str); // copies terminating zero as well > > Should use strncpy for safety (code checkers will flag this). Will update with strncpy. ------------- PR: https://git.openjdk.java.net/jdk/pull/3611 From minqi at openjdk.java.net Wed Apr 28 03:11:52 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 28 Apr 2021 03:11:52 GMT Subject: RFR: 8255493: Support for pre-generated java.lang.invoke classes in CDS dynamic archive [v8] In-Reply-To: <2Cbv0djuFx5CkDh_FZRm84B5vW3EjtUKcG5_8sFamt4=.39933cd9-a3bd-4af7-be36-e8dd4a8ad43a@github.com> References: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> <2Cbv0djuFx5CkDh_FZRm84B5vW3EjtUKcG5_8sFamt4=.39933cd9-a3bd-4af7-be36-e8dd4a8ad43a@github.com> Message-ID: On Tue, 27 Apr 2021 23:22:24 GMT, David Holmes wrote: >> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> Restore filemap.[ch]pp > > src/hotspot/share/classfile/systemDictionaryShared.cpp line 2277: > >> 2275: void do_value(const RunTimeSharedClassInfo* record) { >> 2276: ResourceMark rm; >> 2277: _st->print_cr("%4d: %s %s", ++_index, record->_klass->external_name(), > > Not clear why the _index handling is changing. This is found the printout of index is not consecutive between the two dictionaries. The previous index is printout, then increased then the next dictionary take the index and increased again. I will check again. ------------- PR: https://git.openjdk.java.net/jdk/pull/3611 From stuefe at openjdk.java.net Wed Apr 28 04:27:51 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Wed, 28 Apr 2021 04:27:51 GMT Subject: RFR: 8265867: thread.hpp defines some enums but no reference [v2] In-Reply-To: References: Message-ID: <1Z2k5mhlb-AdMkXtIE-7o5BAwvNBdVhcmJ_ljV-dBDs=.f5341c2c-b3fb-44e2-bf59-c9197077e8d8@github.com> On Tue, 27 Apr 2021 18:22:57 GMT, Xin Liu wrote: >> Deleted 2 useless enums. >> This patch also added const and constexpr for the applicable member functions. > > Xin Liu has updated the pull request incrementally with one additional commit since the last revision: > > Revert code change about "constness". +1 ------------- Marked as reviewed by stuefe (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3702 From jbhateja at openjdk.java.net Wed Apr 28 05:43:53 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Wed, 28 Apr 2021 05:43:53 GMT Subject: RFR: 8265491: Math Signum optimization for x86 [v11] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 01:39:23 GMT, Marcus G K Williams wrote: >> x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM. >> >> We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization. >> >> Base: >> >> Benchmark Mode Cnt Score Error Units >> Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op >> Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op >> Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op >> Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op >> >> >> Optimized: >> signum intrinsic patch >> >> Benchmark Mode Cnt Score Error Units >> Signum._1_signumFloatTest avgt 5 3.769 ? 0.015 ns/op >> Signum._2_overheadFloat avgt 5 3.312 ? 0.025 ns/op >> Signum._3_signumDoubleTest avgt 5 3.765 ? 0.005 ns/op >> Signum._4_overheadDouble avgt 5 3.309 ? 0.010 ns/op >> >> >> Signed-off-by: Marcus G K Williams > > Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision: > > Revert to vector _sign_flip > > Signed-off-by: Marcus G K Williams src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1067: > 1065: jcc(Assembler::parity, DONE_LABEL); // handle special case NaN, if argument NaN, return NaN > 1066: > 1067: if (opcode == Op_SignumF){ Too many if/else, can you kindly club the instruction for SignumF and SignumD in one conditional(if/else) block. src/hotspot/cpu/x86/x86.ad line 5791: > 5789: > 5790: instruct signumF_reg(regF dst, regF zero, regF one, rRegP scratch, rFlagsReg cr) %{ > 5791: predicate(UseSSE>=1); Predicate looks redundant since you already added a check in match_rule_supported src/hotspot/cpu/x86/x86.ad line 5803: > 5801: > 5802: instruct signumD_reg(regD dst, regD zero, regD one, rRegP scratch, rFlagsReg cr) %{ > 5803: predicate(UseSSE>=2); Same as above ------------- PR: https://git.openjdk.java.net/jdk/pull/3581 From iklam at openjdk.java.net Wed Apr 28 06:48:09 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Wed, 28 Apr 2021 06:48:09 GMT Subject: RFR: 8254598: StringDedupTable should use OopStorage In-Reply-To: <8yDFk4JdgCTBjvxuLDC1Bkqel_WPwGXibQyU9yyxM0k=.f317ce73-527d-4012-ae50-4142ea0ead76@github.com> References: <8yDFk4JdgCTBjvxuLDC1Bkqel_WPwGXibQyU9yyxM0k=.f317ce73-527d-4012-ae50-4142ea0ead76@github.com> Message-ID: On Wed, 28 Apr 2021 00:44:19 GMT, Ioi Lam wrote: >> Please review this change to the String Deduplication facility. It is being >> changed to use OopStorage to hold weak references to relevant objects, >> rather than bespoke data structures requiring dedicated processing phases by >> supporting GCs. >> >> (The Shenandoah update was contributed by Zhengyu Gu.) >> >> This change significantly simplifies the interface between a given GC and >> the String Deduplication facility, which should make it much easier for >> other GCs to opt in. However, this change does not alter the set of GCs >> providing support; currently only G1 and Shenandoah support string >> deduplication. Adding support by other GCs will be in followup RFEs. >> >> Reviewing via the diffs might not be all that useful for some parts, as >> several files have been essentially completely replaced, and a number of >> files have been added or eliminated. The full webrev might be a better >> place to look. >> >> The major changes are in gc/shared/stringdedup/* and in the supporting >> collectors, but there are also some smaller changes in other places, most >> notably classfile/{stringTable,javaClasses}. >> >> This change is additionally labeled for review by core-libs, although there >> are no source changes there. This change injects a byte field of bits into >> java.lang.String, using one of the previously unused padding bytes in that >> class. (There were two unused bytes, now only one.) >> >> Testing: >> mach5 tier1-2 with and without -XX:+UseStringDeduplication >> >> Locally (linux-x64) ran all of the existing tests that use string >> deduplication with both G1 and Shenandoah. Note that >> TestStringDeduplicationInterned.java is disabled for shenandoah, as it >> currently fails, for reasons I haven't figured out but suspect are test >> related. >> >> - gc/stringdedup/ -- these used to be in gc/g1 >> - runtime/cds/SharedStringsDedup.java >> - runtime/cds/appcds/cacheObject/DifferentHeapSizes.java >> - runtime/cds/appcds/sharedStrings/* >> >> shenandoah-only: >> - gc/shenandoah/jvmti/TestHeapDump.java >> - gc/shenandoah/TestStringDedup.java >> - gc/shenandoah/TestStringDedupStress.java >> >> Performance tested baseline, baseline + stringdedup, new with stringdedup, >> finding no significant differences. > > src/hotspot/share/gc/shared/stringdedup/stringDedupTable.cpp line 557: > >> 555: // non-latin1, and deduplicating if we find a match. For deduplication we >> 556: // only care if the arrays consist of the same sequence of bytes. >> 557: const jchar* chars = static_cast(value->base(T_CHAR)); > > The encoding of the shared strings always match CompactStrings. Otherwise the CDS archive will fail to map. E.g., > > > $ java -XX:-CompactStrings -Xshare:dump > $ java -XX:+CompactStrings -Xlog:cds -version > ... > [0.032s][info][cds] UseSharedSpaces: The shared archive file's CompactStrings > setting (disabled) does not equal the current CompactStrings setting (enabled). > [0.032s][info][cds] UseSharedSpaces: Unable to map shared spaces > ... > > > So you can avoid this `if` block when `CompactStrings == true`. The `!java_lang_String::is_latin1(found)` check below can be changed to an assert. > > Also, I think we need an explicit test case where you'd return `true` at line 564. I can write a new test case and email to you. I think it will involve dumping an archive with `-XX:-CompactStrings`. Oh, I realized that my suggestion above is wrong. When `CompactStrings==true`, you can still have a string whose coder is UTF16: https://github.com/openjdk/jdk/blob/75a2354dc276e107d64516d20fc72bc7ef3d5f86/src/java.base/share/classes/java/lang/String.java#L343-L351 ------------- PR: https://git.openjdk.java.net/jdk/pull/3662 From xliu at openjdk.java.net Wed Apr 28 06:57:53 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Wed, 28 Apr 2021 06:57:53 GMT Subject: Integrated: 8265867: thread.hpp defines some enums but no reference In-Reply-To: References: Message-ID: On Mon, 26 Apr 2021 18:54:37 GMT, Xin Liu wrote: > Deleted 2 useless enums. This pull request has now been integrated. Changeset: 164454fe Author: Xin Liu Committer: Ioi Lam URL: https://git.openjdk.java.net/jdk/commit/164454feebc31431e76201d613f0c34b8556d637 Stats: 12 lines in 1 file changed: 0 ins; 12 del; 0 mod 8265867: thread.hpp defines some enums but no reference Reviewed-by: dholmes, stuefe, iklam, coleenp ------------- PR: https://git.openjdk.java.net/jdk/pull/3702 From dholmes at openjdk.java.net Wed Apr 28 08:01:56 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 28 Apr 2021 08:01:56 GMT Subject: RFR: 8255493: Support for pre-generated java.lang.invoke classes in CDS dynamic archive [v8] In-Reply-To: References: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> <2Cbv0djuFx5CkDh_FZRm84B5vW3EjtUKcG5_8sFamt4=.39933cd9-a3bd-4af7-be36-e8dd4a8ad43a@github.com> Message-ID: On Wed, 28 Apr 2021 02:58:05 GMT, Yumin Qi wrote: >> src/hotspot/share/cds/dynamicArchive.cpp line 374: >> >>> 372: JavaThread* THREAD = JavaThread::current(); >>> 373: log_info(cds, dynamic)("Regenerate lambdaform holder classes ..."); >>> 374: LambdaFormInvokers::regenerate_holder_classes(THREAD); >> >> You still have not addressed the exception problem here. This call can return early with an exception pending due to line 89 in the called method, which uses CHECK. That exception will escape up to the Java code after the VM operation completes. >> >> Note: If `regenerate_holder_classes` is changed to suppress all exceptions then it should not be declared TRAPS and there is no need to pass THREAD (manifest [Java]Thread::current() internally as needed). > > Thanks for pointing this out, I checked the function LambdaFormInvokers::regenerate_holder_classes again. Looks the TRAPS can be removed. There are two cases: > 1) If any allocation failed due to OOM, vm will exit except for the line 124: > char *buf = resource_allocate_bytes(THREAD, len, AllocFailStrategy::RETURN_NULL); > if (buf == nullptr) { > log_info(cds)("Out of memory when reloading class %s, quit", class_name); > return; > } > 2) CDS.generateLambdaFormHolderClasses may throw exception, the exception is supressed inside the function. > So I will remove the TRAPS. Are you saying that this: objArrayHandle list_lines = oopFactory::new_objArray_handle(vmClasses::String_klass(), len, CHECK); won't throw an exception but will abort the VM? I'm not seeing that. ------------- PR: https://git.openjdk.java.net/jdk/pull/3611 From chegar at openjdk.java.net Wed Apr 28 08:22:52 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Wed, 28 Apr 2021 08:22:52 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) In-Reply-To: <6SevcbQtVmLuygupdqgGyTXI943L_DitH0AK5r-Ou40=.d2ea73a1-0f30-46f2-b2d6-8f59db9b8a83@github.com> References: <6SevcbQtVmLuygupdqgGyTXI943L_DitH0AK5r-Ou40=.d2ea73a1-0f30-46f2-b2d6-8f59db9b8a83@github.com> Message-ID: On Tue, 27 Apr 2021 18:40:24 GMT, Alan Bateman wrote: >> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/412 > > src/java.base/share/classes/sun/nio/ch/IOUtil.java line 466: > >> 464: } >> 465: >> 466: private static final JavaNioAccess NIO_ACCESS = SharedSecrets.getJavaNioAccess(); > > It might be cleaner to move to acquire/release methods to their own supporting class as it's not really IOUtil. I went back and forth on this a number of times already. I think where we landed is a reasonable place, given the current shape of the code. Scope is a private property of Buffer, and as such should be consulted anywhere where a buffer's address is being accessed. In fact, a prior prototype would not allow access to the underlying address value without the caller passing a valid handle for the buffer view's scope. It's hard to find the sweet-spot here between code reuse and safety, but the high-order bit is that the code accessing the address is auditable and testable to avoid accessing memory unsafely. Maybe there is a better alternative implementation code structure (at the cost of some duplication), but it is not obvious to me what that is (and I have given it some thought). Suggestions welcome. Note, there is a little more follow-on work to be done in this area, if we are to expand support to other non-TCP channel implementations. Maybe investigation into possible code refactorings could be done as part of that? ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From kevinw at openjdk.java.net Wed Apr 28 08:57:03 2021 From: kevinw at openjdk.java.net (Kevin Walls) Date: Wed, 28 Apr 2021 08:57:03 GMT Subject: RFR: 8264593: debug.cpp utilities should be available in product builds. [v2] In-Reply-To: <3a7QjXW2fF6Jr0a0TudKxM_n1icuj5rQ54gJz0Egz8U=.f602c0b9-232b-4746-84bb-5fb97f221c38@github.com> References: <3a7QjXW2fF6Jr0a0TudKxM_n1icuj5rQ54gJz0Egz8U=.f602c0b9-232b-4746-84bb-5fb97f221c38@github.com> Message-ID: <1kwOAouzf_TbNzP0Yoa7ifWKNxVsXOV-OkJyQlJa38s=.cb883557-b467-482d-af31-6a46b9b7924f@github.com> On Tue, 27 Apr 2021 16:57:18 GMT, Kevin Walls wrote: >> This is a pull request to move the ifndef PRODUCT in src/hotspot/share/utilities/debug.cpp, and add JNIEXPORT for symbol visibility on Windows. >> >> With these changes, we can use gdb on a live Linux process of a product build JVM, and call debug.cpp utilities. >> e.g. "call universe()", or "call hsfind(0xADDRESS)". >> >> (I found that making calls in the JLI_Launch thread (gdb's thread 1) will crash, but switching first to a JavaThread works.) >> >> In Visual Studio use the Immediate window, just type the function name. Verified that without the changes, the symbols can't be seen/called. >> >> Printing happens on the LIVE jvm's tty (not the gdb session). >> >> >> WizardMode is a develop flag, can't be changed in a product build, so avoid changing that in the debug() utility. >> >> >> pa() is left ifndef PRODUCT, as the class AllocatedObj is ifndef PRODUCT in src/hotspot/share/memory/allocation.hpp >> >> >> pns(...) uses frame fr(sp, fp, pc); but we have an ifndef PRODUCT on frame constructor: frame(void* sp, void* fp, void* pc); >> Leave pns and pns2 ifndef PRODUCT. >> >> >> File size changes: >> Linux: libjvm.so becomes 8904 bytes larger. >> Windows: jvm.dll becomes 6656 bytes larger. > > Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge remote-tracking branch 'upstream/master' into debug_utils > - Remove pa() util as unnecessary. Tidy help. > - 8264593: debug.cpp utilities should be available in product builds. Thanks all. The main limit with product builds is that printing Java object details e.g. with hsfind() doesn't include full field information, though it's still useful. Plan to consider that separately. ------------- PR: https://git.openjdk.java.net/jdk/pull/3307 From kevinw at openjdk.java.net Wed Apr 28 08:57:04 2021 From: kevinw at openjdk.java.net (Kevin Walls) Date: Wed, 28 Apr 2021 08:57:04 GMT Subject: Integrated: 8264593: debug.cpp utilities should be available in product builds. In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 14:05:42 GMT, Kevin Walls wrote: > This is a pull request to move the ifndef PRODUCT in src/hotspot/share/utilities/debug.cpp, and add JNIEXPORT for symbol visibility on Windows. > > With these changes, we can use gdb on a live Linux process of a product build JVM, and call debug.cpp utilities. > e.g. "call universe()", or "call hsfind(0xADDRESS)". > > (I found that making calls in the JLI_Launch thread (gdb's thread 1) will crash, but switching first to a JavaThread works.) > > In Visual Studio use the Immediate window, just type the function name. Verified that without the changes, the symbols can't be seen/called. > > Printing happens on the LIVE jvm's tty (not the gdb session). > > > WizardMode is a develop flag, can't be changed in a product build, so avoid changing that in the debug() utility. > > > pa() is left ifndef PRODUCT, as the class AllocatedObj is ifndef PRODUCT in src/hotspot/share/memory/allocation.hpp > > > pns(...) uses frame fr(sp, fp, pc); but we have an ifndef PRODUCT on frame constructor: frame(void* sp, void* fp, void* pc); > Leave pns and pns2 ifndef PRODUCT. > > > File size changes: > Linux: libjvm.so becomes 8904 bytes larger. > Windows: jvm.dll becomes 6656 bytes larger. This pull request has now been integrated. Changeset: e325a750 Author: Kevin Walls URL: https://git.openjdk.java.net/jdk/commit/e325a750ac795181f14b278fcd171170dbb3bbd5 Stats: 43 lines in 1 file changed: 2 ins; 12 del; 29 mod 8264593: debug.cpp utilities should be available in product builds. Reviewed-by: sspitsyn, coleenp, vlivanov ------------- PR: https://git.openjdk.java.net/jdk/pull/3307 From chegar at openjdk.java.net Wed Apr 28 09:14:53 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Wed, 28 Apr 2021 09:14:53 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) In-Reply-To: References: Message-ID: On Mon, 26 Apr 2021 17:10:13 GMT, Maurizio Cimadamore wrote: > This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/412 src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ResourceScope.java line 135: > 133: } finally { > 134: segment.scope().release(segmentHandle); > 135: } I do like the symmetry in this example, but just to add an alternative idiom: `segmentHandle.scope().release(segmentHandle)` , which guarantees to avoid release throwing and IAE src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ResourceScope.java line 186: > 184: *
  • this resource scope is confined, and this method is called from a thread other than the thread owning this resource scope
    • > 185: *
  • this resource scope is shared and a resource associated with this scope is accessed while this method is called
    • > 186: *
  • one or more handles (see {@link #acquire()}) associated with this resource scope have not been closed
    • Minor spec suggestion: "... associated with this resource scope have not been *released*" src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ResourceScope.java line 205: > 203: * until all the resource scope handles acquired from it have been {@link #release(Handle)} released}. > 204: * @return a resource scope handle. > 205: */ Given recent changes, it might be good to generalise the opening sentence here. Maybe : " Acquires a resource scope handle associated with this resource scope. If the resource scope is explicit ... " Or some such. ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From aph at openjdk.java.net Wed Apr 28 09:27:51 2021 From: aph at openjdk.java.net (Andrew Haley) Date: Wed, 28 Apr 2021 09:27:51 GMT Subject: RFR: 8265768 [aarch64] Use glibc libm impl for dlog, dlog10, dexp iff 2.29 or greater on AArch64. In-Reply-To: References: Message-ID: <3L8L5wzGgohp-2AXzFWxNCCKI4KsBLUUfOqHJ8lUc74=.77b833de-e3f0-41b5-a060-c731031bd9a5@github.com> On Thu, 15 Apr 2021 08:33:47 GMT, gregcawthorne wrote: > Glibc 2.29 onwards provides optimised versions of log,log10,exp. > These functions have an accuracy of 0.9ulp or better in glibc > 2.29. > > Therefore this patch adds code to parse, store and check > the runtime glibcs version in os_linux.cpp/hpp. > This is then used to select the glibcs implementation of > log, log10, exp at runtime for c1 and c2, iff we have > glibc 2.29 or greater. > > This will ensure OpenJDK can benefit from future improvements > to glibc. > > Glibc adheres to the ieee754 standard, unless stated otherwise > in its spec. > > As there are no stated exceptions in the current glibc spec > for dlog, dlog10 and dexp, we can assume they currently follow > ieee754 (which testing confirms). As such, future version of > glibc are unlikely to lose this compliance with ieee754 in > future. > > W.r.t performance this patch sees ~15-30% performance improvements for > log and log10, with ~50-80% performance improvements for exp for the > common input ranged (which output real numbers). However for the NaN > and inf output ranges we see a slow down of up to a factor of 2 for > some functions and architectures. > > Due to this being the uncommon case we assert that this is a > worthwhile tradeoff. Re monotonicity: all is not necessarily lost. There's a theorem due to Ferguson and Brightman which says that if abs(f(m+) - f(m)) eps < ----------------------- abs(f(m+)) + abs(f(m))' for all m, the approximation is monotone. m is the machine number, m+ its successor eps the maximum relative error of the approximation f(m) See http://www-leland.stanford.edu/class/ee486/doc/ferguson1991.pdf, particularly the Appendix, which contains a table of expressions for the five basic transcendental functions. ------------- PR: https://git.openjdk.java.net/jdk/pull/3510 From ayang at openjdk.java.net Wed Apr 28 09:30:10 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Wed, 28 Apr 2021 09:30:10 GMT Subject: RFR: 8234532: Remove ThreadLocalAllocBuffer::_fast_refill_waste since it is never set Message-ID: It has some cascading effect; two performance variables, `fastWaste` and `maxFastWaste`, can be removed also. ------------- Commit messages: - refill Changes: https://git.openjdk.java.net/jdk/pull/3756/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3756&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8234532 Stats: 47 lines in 6 files changed: 0 ins; 40 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/3756.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3756/head:pull/3756 PR: https://git.openjdk.java.net/jdk/pull/3756 From ayang at openjdk.java.net Wed Apr 28 09:41:14 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Wed, 28 Apr 2021 09:41:14 GMT Subject: RFR: 8234532: Remove ThreadLocalAllocBuffer::_fast_refill_waste since it is never set [v2] In-Reply-To: References: Message-ID: > It has some cascading effect; two performance variables, `fastWaste` and `maxFastWaste`, can be removed also. Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - merge - refill ------------- Changes: https://git.openjdk.java.net/jdk/pull/3756/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3756&range=01 Stats: 42 lines in 5 files changed: 0 ins; 35 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/3756.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3756/head:pull/3756 PR: https://git.openjdk.java.net/jdk/pull/3756 From mcimadamore at openjdk.java.net Wed Apr 28 10:20:53 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 28 Apr 2021 10:20:53 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 09:06:29 GMT, Chris Hegarty wrote: >> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/412 > > src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ResourceScope.java line 205: > >> 203: * until all the resource scope handles acquired from it have been {@link #release(Handle)} released}. >> 204: * @return a resource scope handle. >> 205: */ > > Given recent changes, it might be good to generalise the opening sentence here. Maybe : > " Acquires a resource scope handle associated with this resource scope. If the resource scope is explicit ... " Or some such. I'm afraid I don't get this comment ;-) ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From github.com+73799211+gregcawthorne at openjdk.java.net Wed Apr 28 10:34:51 2021 From: github.com+73799211+gregcawthorne at openjdk.java.net (gregcawthorne) Date: Wed, 28 Apr 2021 10:34:51 GMT Subject: RFR: 8265768 [aarch64] Use glibc libm impl for dlog, dlog10, dexp iff 2.29 or greater on AArch64. In-Reply-To: <3L8L5wzGgohp-2AXzFWxNCCKI4KsBLUUfOqHJ8lUc74=.77b833de-e3f0-41b5-a060-c731031bd9a5@github.com> References: <3L8L5wzGgohp-2AXzFWxNCCKI4KsBLUUfOqHJ8lUc74=.77b833de-e3f0-41b5-a060-c731031bd9a5@github.com> Message-ID: On Wed, 28 Apr 2021 09:25:01 GMT, Andrew Haley wrote: > Re monotonicity: all is not necessarily lost. There's a theorem due to Ferguson and Brightman which says that > > ``` > if > abs(f(m+) - f(m)) > eps < ----------------------- > abs(f(m+)) + abs(f(m))' > > for all m, the approximation is monotone. > > m is the machine number, m+ its successor > eps the maximum relative error of the approximation f(m) > ``` > > See > http://www-leland.stanford.edu/class/ee486/doc/ferguson1991.pdf, particularly the Appendix, which contains a table of expressions for the five basic transcendental functions. We can definitely be checked for single precision! I am uncertain how much water that would hold. ------------- PR: https://git.openjdk.java.net/jdk/pull/3510 From aph at redhat.com Wed Apr 28 10:41:28 2021 From: aph at redhat.com (Andrew Haley) Date: Wed, 28 Apr 2021 11:41:28 +0100 Subject: RFR: 8265768 [aarch64] Use glibc libm impl for dlog, dlog10, dexp iff 2.29 or greater on AArch64. In-Reply-To: References: <3L8L5wzGgohp-2AXzFWxNCCKI4KsBLUUfOqHJ8lUc74=.77b833de-e3f0-41b5-a060-c731031bd9a5@github.com> Message-ID: <21fe1ed2-927d-44a8-4cc2-e8054ccb697b@redhat.com> On 4/28/21 11:34 AM, gregcawthorne wrote: > > We can definitely be checked for single precision! I am uncertain how much water that would hold. I'm not sure I understand the relevance of that comment. All that is required is for someone to check the above expression carefully, and to make sure that no-one breaks it in the future. (Which is *highly* unlikely, because that would make the approximation worse.) The author, works for Arm, right? So they should be able to check this without very much trouble, and we're good. From mcimadamore at openjdk.java.net Wed Apr 28 10:42:55 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 28 Apr 2021 10:42:55 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v2] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 09:10:37 GMT, Chris Hegarty wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Address first batch of review comments > > src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ResourceScope.java line 135: > >> 133: } finally { >> 134: segment.scope().release(segmentHandle); >> 135: } > > I do like the symmetry in this example, but just to add an alternative idiom: > `segmentHandle.scope().release(segmentHandle)` > , which guarantees to avoid release throwing and IAE I see what you mean - I don't think I want to encourage that style too much by giving it prominence in the javadoc. It's true you can go back to the scope from the handle, so that you are guaranteed to release the right thing, but I think that should be unnecessary in most idiomatic uses. ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From mcimadamore at openjdk.java.net Wed Apr 28 10:42:54 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 28 Apr 2021 10:42:54 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v2] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/412 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Address first batch of review comments ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3699/files - new: https://git.openjdk.java.net/jdk/pull/3699/files/7545f71f..a80d8180 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=00-01 Stats: 42 lines in 4 files changed: 25 ins; 11 del; 6 mod Patch: https://git.openjdk.java.net/jdk/pull/3699.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699 PR: https://git.openjdk.java.net/jdk/pull/3699 From chegar at openjdk.java.net Wed Apr 28 10:42:56 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Wed, 28 Apr 2021 10:42:56 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v2] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 09:06:29 GMT, Chris Hegarty wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Address first batch of review comments > > src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/ResourceScope.java line 205: > >> 203: * until all the resource scope handles acquired from it have been {@link #release(Handle)} released}. >> 204: * @return a resource scope handle. >> 205: */ > > Given recent changes, it might be good to generalise the opening sentence here. Maybe : > " Acquires a resource scope handle associated with this resource scope. If the resource scope is explicit ... " Or some such. The spec for the acquire method talks only of explicit resource scopes. The comment is suggesting that the spec could be generalised a little, since it is possible to acquire a resource scope handle associated with implicit scopes. ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From chegar at openjdk.java.net Wed Apr 28 13:12:55 2021 From: chegar at openjdk.java.net (Chris Hegarty) Date: Wed, 28 Apr 2021 13:12:55 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v2] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 10:42:54 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/412 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Address first batch of review comments Like Paul, I tracked the changes to this API in the Panama repo. Most of my remaining comments are small and come from re-reading the API docs. src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 270: > 268: > 269: /** > 270: * Converts a Java string into a null-terminated C string, using the platform's default charset, Sorry if this has come up before, but, is the platform's default charset the right choice here? For other areas, we choose UTF-8 as the default. In fact, there is a draft JEP to move the default charset to UTF-8. So if there is an implicit need to match the underlying platform's charset then this may need to be revisited. For now, I just want to check that this is not an accidental reliance on the platform's default charset, but a deliberate one. src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 101: > 99: *

    Lifecycle and confinement

    > 100: * > 101: * Memory segments are associated to a resource scope (see {@link ResourceScope}), which can be accessed using Typo?? "Memory segments are associated *with* a resource scope" src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 112: > 110: MemoryAccess.getLong(segment); // already closed! > 111: * } > 112: * Additionally, access to a memory segment in subject to the thread-confinement checks enforced by the owning scope; that is, Typo?? "Additionally, access to a memory segment *is* subject to ..." src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 114: > 112: * Additionally, access to a memory segment in subject to the thread-confinement checks enforced by the owning scope; that is, > 113: * if the segment is associated with a shared scope, it can be accessed by multiple threads; if it is associated with a confined > 114: * scope, it can only be accessed by the thread which own the scope. Typo?? "it can only be accessed by the thread which ownS the scope." src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 693: > 691: */ > 692: static MemorySegment allocateNative(MemoryLayout layout, ResourceScope scope) { > 693: Objects.requireNonNull(scope); Should the allocateNative methods declare that they throw ISE, if the given ResourceScope is not alive? ( I found myself asking this q, then considering the behaviour of a SegmentAllocator that is asked to allocate after a RS has been closed ) ------------- Marked as reviewed by chegar (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3699 From mcimadamore at openjdk.java.net Wed Apr 28 13:45:53 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 28 Apr 2021 13:45:53 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v2] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 13:08:26 GMT, Chris Hegarty wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Address first batch of review comments > > src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java line 693: > >> 691: */ >> 692: static MemorySegment allocateNative(MemoryLayout layout, ResourceScope scope) { >> 693: Objects.requireNonNull(scope); > > Should the allocateNative methods declare that they throw ISE, if the given ResourceScope is not alive? ( I found myself asking this q, then considering the behaviour of a SegmentAllocator that is asked to allocate after a RS has been closed ) Good point, yes it should ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From mcimadamore at openjdk.java.net Wed Apr 28 13:50:55 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 28 Apr 2021 13:50:55 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v2] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 12:47:36 GMT, Chris Hegarty wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Address first batch of review comments > > src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 270: > >> 268: >> 269: /** >> 270: * Converts a Java string into a null-terminated C string, using the platform's default charset, > > Sorry if this has come up before, but, is the platform's default charset the right choice here? For other areas, we choose UTF-8 as the default. In fact, there is a draft JEP to move the default charset to UTF-8. So if there is an implicit need to match the underlying platform's charset then this may need to be revisited. For now, I just want to check that this is not an accidental reliance on the platform's default charset, but a deliberate one. I believe here the goal is to be consistent with `String::getBytes`: /** * Encodes this {@code String} into a sequence of bytes using the * platform's default charset, storing the result into a new byte array. * *

    The behavior of this method when this string cannot be encoded in * the default charset is unspecified. The {@link * java.nio.charset.CharsetEncoder} class should be used when more control * over the encoding process is required. * * @return The resultant byte array * * @since 1.1 */ public byte[] getBytes() { return encode(Charset.defaultCharset(), coder(), value); } So, you are right in that there's an element of platform-dependency here - but I think it's a dependency that users learned to "ignore" mostly. If developers want to be precise, and platform independent, they can always use the Charset-accepting method. Of course this could be revisited, but I think there is some consistency in what the API is trying to do. If, in the future, defaultCharset will just be Utf8 - well, that's ok too - as long as the method is specified to be "defaultCharset" dependent, what's behind "defaultCharset" is an implementation detail that the user will have to be aware of one way or another. ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From zgu at openjdk.java.net Wed Apr 28 14:48:05 2021 From: zgu at openjdk.java.net (Zhengyu Gu) Date: Wed, 28 Apr 2021 14:48:05 GMT Subject: RFR: 8254598: StringDedupTable should use OopStorage In-Reply-To: References: Message-ID: On Fri, 23 Apr 2021 19:48:47 GMT, Kim Barrett wrote: > Please review this change to the String Deduplication facility. It is being > changed to use OopStorage to hold weak references to relevant objects, > rather than bespoke data structures requiring dedicated processing phases by > supporting GCs. > > (The Shenandoah update was contributed by Zhengyu Gu.) > > This change significantly simplifies the interface between a given GC and > the String Deduplication facility, which should make it much easier for > other GCs to opt in. However, this change does not alter the set of GCs > providing support; currently only G1 and Shenandoah support string > deduplication. Adding support by other GCs will be in followup RFEs. > > Reviewing via the diffs might not be all that useful for some parts, as > several files have been essentially completely replaced, and a number of > files have been added or eliminated. The full webrev might be a better > place to look. > > The major changes are in gc/shared/stringdedup/* and in the supporting > collectors, but there are also some smaller changes in other places, most > notably classfile/{stringTable,javaClasses}. > > This change is additionally labeled for review by core-libs, although there > are no source changes there. This change injects a byte field of bits into > java.lang.String, using one of the previously unused padding bytes in that > class. (There were two unused bytes, now only one.) > > Testing: > mach5 tier1-2 with and without -XX:+UseStringDeduplication > > Locally (linux-x64) ran all of the existing tests that use string > deduplication with both G1 and Shenandoah. Note that > TestStringDeduplicationInterned.java is disabled for shenandoah, as it > currently fails, for reasons I haven't figured out but suspect are test > related. > > - gc/stringdedup/ -- these used to be in gc/g1 > - runtime/cds/SharedStringsDedup.java > - runtime/cds/appcds/cacheObject/DifferentHeapSizes.java > - runtime/cds/appcds/sharedStrings/* > > shenandoah-only: > - gc/shenandoah/jvmti/TestHeapDump.java > - gc/shenandoah/TestStringDedup.java > - gc/shenandoah/TestStringDedupStress.java > > Performance tested baseline, baseline + stringdedup, new with stringdedup, > finding no significant differences. Just FYI: Concurrent GC, such as Sheanndoah and ZGC (if it decides to implement string deduplication in the future), can not enqueue candidates during concurrent thread root scanning, because of potential lock rank inversion between OopStorage lock and stack watermark lock. src/hotspot/share/classfile/stringTable.cpp line 355: > 353: // Notify deduplication support that the string is being interned. A string > 354: // must never be deduplicated after it has been interned. Doing so interferes > 355: // with compiler optimizations don on e.g. interned string literals. typo: don -> done ------------- PR: https://git.openjdk.java.net/jdk/pull/3662 From alanb at openjdk.java.net Wed Apr 28 16:17:53 2021 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 28 Apr 2021 16:17:53 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v2] In-Reply-To: References: Message-ID: <0P9z_Fj6-ogctJUqlsZRC3JfOXGCbx0YLNh8me9grio=.0d53fd2d-d6b0-4c69-9da1-4781a1194405@github.com> On Wed, 28 Apr 2021 13:47:43 GMT, Maurizio Cimadamore wrote: >> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/CLinker.java line 270: >> >>> 268: >>> 269: /** >>> 270: * Converts a Java string into a null-terminated C string, using the platform's default charset, >> >> Sorry if this has come up before, but, is the platform's default charset the right choice here? For other areas, we choose UTF-8 as the default. In fact, there is a draft JEP to move the default charset to UTF-8. So if there is an implicit need to match the underlying platform's charset then this may need to be revisited. For now, I just want to check that this is not an accidental reliance on the platform's default charset, but a deliberate one. > > I believe here the goal is to be consistent with `String::getBytes`: > > > /** > * Encodes this {@code String} into a sequence of bytes using the > * platform's default charset, storing the result into a new byte array. > * > *

    The behavior of this method when this string cannot be encoded in > * the default charset is unspecified. The {@link > * java.nio.charset.CharsetEncoder} class should be used when more control > * over the encoding process is required. > * > * @return The resultant byte array > * > * @since 1.1 > */ > public byte[] getBytes() { > return encode(Charset.defaultCharset(), coder(), value); > } > > > So, you are right in that there's an element of platform-dependency here - but I think it's a dependency that users learned to "ignore" mostly. If developers want to be precise, and platform independent, they can always use the Charset-accepting method. Of course this could be revisited, but I think there is some consistency in what the API is trying to do. If, in the future, defaultCharset will just be Utf8 - well, that's ok too - as long as the method is specified to be "defaultCharset" dependent, what's behind "defaultCharset" is an implementation detail that the user will have to be aware of one way or another. Naoto is working on a couple of changes in advance of JEP 400. One of these is to expose a system property with the host charset and I suspect that the CLinker method will want to use that instead of Charset.defaultCharset. ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From minqi at openjdk.java.net Wed Apr 28 16:47:36 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 28 Apr 2021 16:47:36 GMT Subject: RFR: 8255493: Support for pre-generated java.lang.invoke classes in CDS dynamic archive [v9] In-Reply-To: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> References: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> Message-ID: > Hi, Please review > > When do dynamic dump, the pre-generated lambda form classes from java.lang.invoke are not stored in dynamic archive. The patch will regenerate the four holder classes, > "java.lang.invoke.Invokers$Holder", > "java.lang.invoke.DirectMethodHandle$Holder", > "java.lang.invoke.DelegatingMethodHandle$Holder", > "java.lang.invoke.LambdaForm$Holder" > which will include the versions in static archive and new loaded functions all together and stored in dynamic archive. New test case added. > (Minor change to PrintSharedArchiveAtExit, which the index is not consecutive) > > Tests: tier1,tier2,tier3,tier4 > > Thanks > Yumin Yumin Qi has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: - Removed TRAP from regenerate_holder_classes, also correct SharedLambdaDictionaryPrinter index - Merge branch 'master' into jdk-8255493 - Restore filemap.[ch]pp - Remove unnecessary file header including - Removed unused function static_archive_invokers(), add back accidentally deleted empty line - Changed DEBUG_ONLY to log_debug, make small changes for format, added bug tag to test - Moved log invoker lines to debug only, removed check for as_utf8_string - Move read static invoker lines to LambdaFormInokers, remove unneeded check for return NULL - Serialize lambdafor invokers in readonly talbe, merged with master - Merge branch 'master' into jdk-8255493 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/e25b4899...78445575 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3611/files - new: https://git.openjdk.java.net/jdk/pull/3611/files/a63af745..78445575 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3611&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3611&range=07-08 Stats: 473076 lines in 3466 files changed: 2089 ins; 469813 del; 1174 mod Patch: https://git.openjdk.java.net/jdk/pull/3611.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3611/head:pull/3611 PR: https://git.openjdk.java.net/jdk/pull/3611 From minqi at openjdk.java.net Wed Apr 28 16:59:54 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 28 Apr 2021 16:59:54 GMT Subject: RFR: 8255493: Support for pre-generated java.lang.invoke classes in CDS dynamic archive [v8] In-Reply-To: <2Cbv0djuFx5CkDh_FZRm84B5vW3EjtUKcG5_8sFamt4=.39933cd9-a3bd-4af7-be36-e8dd4a8ad43a@github.com> References: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> <2Cbv0djuFx5CkDh_FZRm84B5vW3EjtUKcG5_8sFamt4=.39933cd9-a3bd-4af7-be36-e8dd4a8ad43a@github.com> Message-ID: On Tue, 27 Apr 2021 23:26:41 GMT, David Holmes wrote: >> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> Restore filemap.[ch]pp > > src/hotspot/share/cds/lambdaFormInvokers.cpp line 67: > >> 65: void LambdaFormInvokers::append_filtered(char* line) { >> 66: for (int k = 0; k < NUM_FILTER; k++) { >> 67: if (strstr(line, filter[k]) != nullptr) { > > Do you really want to match anywhere in the string? I'm assuming the line should start with the filter? You reminded me that only the invoker lines which contain four holder class be stored in static archive, not else. I will change that part. For the filtered lines, it starts with [LF_RESOLVE] .... so the comparison I used here to check if the line contains "java.lang.invoke.". ------------- PR: https://git.openjdk.java.net/jdk/pull/3611 From dfuchs at openjdk.java.net Wed Apr 28 17:28:53 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 28 Apr 2021 17:28:53 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v2] In-Reply-To: References: Message-ID: <689o3jJsku_BVrUSQATPla7V0BfqOYZuzlJXtmy347E=.6871722d-66a7-4364-8e19-3eecb6df2e3a@github.com> On Wed, 28 Apr 2021 10:42:54 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/412 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Address first batch of review comments src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/package-info.java line 224: > 222: * Some methods in this package are considered restricted. Restricted methods are typically used to bind native > 223: * foreign data and/or functions to first-class Java API elements which can then be used directly by client. For instance > 224: * the restricted method {@link jdk.incubator.foreign.MemoryAddress#asSegment(long, ResourceScope)} can be used to create typo: `used directly by client.` => `used directly by clients.` ? ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From iveresov at openjdk.java.net Wed Apr 28 17:35:55 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Wed, 28 Apr 2021 17:35:55 GMT Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex [v2] In-Reply-To: References: Message-ID: On Fri, 23 Apr 2021 03:50:54 GMT, Yi Yang wrote: >> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version. >> >> In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot. >> >> But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later: >> >> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase. >> 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag >> >> Testing: cds, compiler and jdk > > Yi Yang has updated the pull request incrementally with one additional commit since the last revision: > > remove java_nio_Buffer in javaClasses.hpp src/hotspot/share/c1/c1_GraphBuilder.cpp line 2052: > 2050: return; > 2051: } > 2052: Do we need to keep this flag? ------------- PR: https://git.openjdk.java.net/jdk/pull/3615 From mchung at openjdk.java.net Wed Apr 28 18:04:53 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 28 Apr 2021 18:04:53 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v2] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 10:42:54 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/412 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Address first batch of review comments I reviewed the `--enable-native-access` related change that looks fine. > Access to restricted methods from any other module not in the list is disallowed and will result in an IllegalAccessException. I think you meant to say `IllegalCallerException` instead of `IllegalAccessException`. Also do you intend to have javadoc to generate `@throw IllegalCallerException` for the restricted methods automatically besides the javadoc description? Making the restricted methods as `@CallerSensitive` in order to get the caller class for native access check is the proper approach. However, some interface methods are restricted methods such as `CLinker::downcallHandle` whose the implementation method is `@CallerSensitive`. I concern with the security issue with method handle and type aliasing. On the other hand, `CLinker` is a sealed interface and only implemented by the platform and so it's less of a concern. I think the interface method should also be `@CallerSensitive` so that for example a method handle for `CLinker::downcallHandle` will be produced with the proper caller-sensitive context. ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From dfuchs at openjdk.java.net Wed Apr 28 18:10:54 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 28 Apr 2021 18:10:54 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v2] In-Reply-To: References: Message-ID: <9aIvV_N89PFpzwfhedEwNju-eKqhpZoFHL59F5pUv6g=.9c515555-c446-4280-8f24-88ffd753712f@github.com> On Wed, 28 Apr 2021 10:42:54 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/412 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Address first batch of review comments src/java.base/share/classes/jdk/internal/module/IllegalNativeAccessChecker.java line 40: > 38: > 39: private IllegalNativeAccessChecker(Set allowedModuleNames, boolean allowAllUnnamedModules) { > 40: this.allowedModuleNames = Collections.unmodifiableSet(allowedModuleNames); Should that be Set.copyOf() to take advantage of the immutability of `SetN` (but at the expense of additional copying)... src/java.base/share/classes/jdk/internal/module/IllegalNativeAccessChecker.java line 78: > 76: int index = 0; > 77: // the system property is removed after decoding > 78: String value = getAndRemoveProperty(prefix + index); I am not sure what is going on with the removal of the properties, but if I'm not mistaken this is racy: from the implementation of the checker() method above, it looks as if two different threads could trigger a call to the decode() function concurrently, which can result in a random partitioning of the properties against the two checkers being instantiated, with one of them being eventually set as the system-wide checker. ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From mcimadamore at openjdk.java.net Wed Apr 28 18:17:59 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 28 Apr 2021 18:17:59 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v2] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 18:02:03 GMT, Mandy Chung wrote: > I reviewed the `--enable-native-access` related change that looks fine. > > > Access to restricted methods from any other module not in the list is disallowed and will result in an IllegalAccessException. > > I think you meant to say `IllegalCallerException` instead of `IllegalAccessException`. Also do you intend to have javadoc to generate `@throw IllegalCallerException` for the restricted methods automatically besides the javadoc description? > IllegalCalller is probably better yes - we started off with an access-like check, so things have evolved a bit. I'll also add the @throws. > Making the restricted methods as `@CallerSensitive` in order to get the caller class for native access check is the proper approach. However, some interface methods are restricted methods such as `CLinker::downcallHandle` whose the implementation method is `@CallerSensitive`. I concern with the security issue with method handle and type aliasing. On the other hand, `CLinker` is a sealed interface and only implemented by the platform and so it's less of a concern. I think the interface method should also be `@CallerSensitive` so that for example a method handle for `CLinker::downcallHandle` will be produced with the proper caller-sensitive context. I believe that we had to move @CallerSensitive out of interfaces because there was a test that was checking that @CS was not put on "virtual" methods. ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From mcimadamore at openjdk.java.net Wed Apr 28 18:21:54 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 28 Apr 2021 18:21:54 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v2] In-Reply-To: <9aIvV_N89PFpzwfhedEwNju-eKqhpZoFHL59F5pUv6g=.9c515555-c446-4280-8f24-88ffd753712f@github.com> References: <9aIvV_N89PFpzwfhedEwNju-eKqhpZoFHL59F5pUv6g=.9c515555-c446-4280-8f24-88ffd753712f@github.com> Message-ID: On Wed, 28 Apr 2021 18:07:32 GMT, Daniel Fuchs wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Address first batch of review comments > > src/java.base/share/classes/jdk/internal/module/IllegalNativeAccessChecker.java line 78: > >> 76: int index = 0; >> 77: // the system property is removed after decoding >> 78: String value = getAndRemoveProperty(prefix + index); > > I am not sure what is going on with the removal of the properties, but if I'm not mistaken this is racy: from the implementation of the checker() method above, it looks as if two different threads could trigger a call to the decode() function concurrently, which can result in a random partitioning of the properties against the two checkers being instantiated, with one of them being eventually set as the system-wide checker. I think the method is called during module bootstrap - I don't think there is a race in practice. This method is also called in other parts of ModuleBootstrap. The code you allude to is called during initialization of the IllegalNativeAccessChecker singleton, which should happen only once, and only from one thread. ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From minqi at openjdk.java.net Wed Apr 28 18:31:43 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 28 Apr 2021 18:31:43 GMT Subject: RFR: 8255493: Support for pre-generated java.lang.invoke classes in CDS dynamic archive [v8] In-Reply-To: <2Cbv0djuFx5CkDh_FZRm84B5vW3EjtUKcG5_8sFamt4=.39933cd9-a3bd-4af7-be36-e8dd4a8ad43a@github.com> References: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> <2Cbv0djuFx5CkDh_FZRm84B5vW3EjtUKcG5_8sFamt4=.39933cd9-a3bd-4af7-be36-e8dd4a8ad43a@github.com> Message-ID: On Tue, 27 Apr 2021 23:22:38 GMT, David Holmes wrote: >> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> Restore filemap.[ch]pp > > src/hotspot/share/classfile/systemDictionaryShared.cpp line 2297: > >> 2295: class_loader_name_for_shared(k)); >> 2296: k = k->next_link(); >> 2297: _index++; > > Not clear why the _index handling is changing. I reverted this part. The problem is when construct the lambda dictionary library, I wrongly add one to the last dictionary's index. ------------- PR: https://git.openjdk.java.net/jdk/pull/3611 From mchung at openjdk.java.net Wed Apr 28 18:34:23 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 28 Apr 2021 18:34:23 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v2] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 10:42:54 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/412 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Address first batch of review comments > I believe that we had to move @CallerSensitive out of interfaces because there was a test that was checking that @cs was not put on "virtual" methods. Good if we do have such test. We need to re-examine this with the security team. I suggest to create a JBS issue and follow up separately. ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From mcimadamore at openjdk.java.net Wed Apr 28 18:33:36 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 28 Apr 2021 18:33:36 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v3] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/412 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Address review comments: * fix typos in javadoc * document ISE being thrown in all methods accepting a scope; add more tests for that ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3699/files - new: https://git.openjdk.java.net/jdk/pull/3699/files/a80d8180..24e554c5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=01-02 Stats: 112 lines in 6 files changed: 50 ins; 0 del; 62 mod Patch: https://git.openjdk.java.net/jdk/pull/3699.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699 PR: https://git.openjdk.java.net/jdk/pull/3699 From mcimadamore at openjdk.java.net Wed Apr 28 18:35:54 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 28 Apr 2021 18:35:54 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v2] In-Reply-To: <9aIvV_N89PFpzwfhedEwNju-eKqhpZoFHL59F5pUv6g=.9c515555-c446-4280-8f24-88ffd753712f@github.com> References: <9aIvV_N89PFpzwfhedEwNju-eKqhpZoFHL59F5pUv6g=.9c515555-c446-4280-8f24-88ffd753712f@github.com> Message-ID: <9u5yskXth55699_itCsdggIyKauvUauftz9zy0svpLI=.744431e1-4a6d-4fe2-a664-09b35e53eaf7@github.com> On Wed, 28 Apr 2021 17:53:44 GMT, Daniel Fuchs wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Address first batch of review comments > > src/java.base/share/classes/jdk/internal/module/IllegalNativeAccessChecker.java line 40: > >> 38: >> 39: private IllegalNativeAccessChecker(Set allowedModuleNames, boolean allowAllUnnamedModules) { >> 40: this.allowedModuleNames = Collections.unmodifiableSet(allowedModuleNames); > > Should that be Set.copyOf() to take advantage of the immutability of `SetN` (but at the expense of additional copying)... Honestly, I'm not even sure why we should be concerned about mutation of the set here - since we create this with a bunch of values read from a system property... e.g. should we just store `allowedModuleNames` period? ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From mcimadamore at openjdk.java.net Wed Apr 28 18:34:41 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 28 Apr 2021 18:34:41 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v2] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 18:23:41 GMT, Mandy Chung wrote: > > I believe that we had to move @CallerSensitive out of interfaces because there was a test that was checking that @cs was not put on "virtual" methods. > > Good if we do have such test. We need to re-examine this with the security team. I suggest to create a JBS issue and follow up separately. The test in question is: test/jdk/jdk/internal/reflect/CallerSensitive/CheckCSMs.java ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From mchung at openjdk.java.net Wed Apr 28 18:38:28 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 28 Apr 2021 18:38:28 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v2] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 18:26:30 GMT, Maurizio Cimadamore wrote: > test/jdk/jdk/internal/reflect/CallerSensitive/CheckCSMs.java Yes that's the test. That test misses to catch your case where aliasing may be possible. ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From github.com+168222+mgkwill at openjdk.java.net Wed Apr 28 18:38:07 2021 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Wed, 28 Apr 2021 18:38:07 GMT Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux [v29] In-Reply-To: References: Message-ID: <7DAPl6-yypQPTFb6cc6hBTRxMGKFMeVI5-RTuFacdsY=.e14b980d-c7f6-491b-a52a-d037e7c96559@github.com> On Mon, 26 Apr 2021 08:31:29 GMT, Stefan Johansson wrote: >> Marcus G K Williams has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 48 commits: >> >> - Set LargePageSizeInBytes to largepage upper limit >> >> Signed-off-by: Marcus G K Williams >> - Merge branch 'master' into update_hlp >> - Fix merge >> >> Signed-off-by: Marcus G K Williams >> - Merge branch 'master' into update_hlp >> - Merge branch 'master' into update_hlp >> - Rebase on pull/3073 >> >> Signed-off-by: Marcus G K Williams >> - Merge branch 'pull/3073' into update_hlp >> - Thomas review. >> >> Changed commit_memory_special to return bool to signal if the request succeeded or not. >> - Self review. >> >> Update helper name to better match commit_memory_special(). >> - Marcus review. >> >> Updated comments. >> - ... and 38 more: https://git.openjdk.java.net/jdk/compare/5aab1609...6f063309 > > src/hotspot/os/linux/os_linux.cpp line 3737: > >> 3735: // Populate large page sizes to _page_sizes. Add pages that >> 3736: // are less than or equal to LargePageSizeInBytes, except when LargePageSizeInBytes=0 >> 3737: // or FLAG_IS_DEFAULT(LargePageSizeInBytes), add all sizes > > What we currently have in the CSR is to use the default large page size as the max if `LargePageSizeInBytes`is not set. If we first check if `LargePageSizeInBytes` have been set and update `_large_page_size` accordingly above (see comment below). I think this comment should say something like: > > Suggestion: > > // Populate _page_sizes with large page sizes less than or equal to > // _large_page_size. +1 ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From github.com+168222+mgkwill at openjdk.java.net Wed Apr 28 18:36:53 2021 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Wed, 28 Apr 2021 18:36:53 GMT Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux [v30] In-Reply-To: References: Message-ID: > Change the meaning of LargePageSizeInBytes to be the maximum large page size the JVM may use (not the only one). A default value of zero will mean to allow the JVM use large page sizes up to the system's default large page size. Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision: kstefanj review Signed-off-by: Marcus G K Williams ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1153/files - new: https://git.openjdk.java.net/jdk/pull/1153/files/6f063309..6cd6be15 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1153&range=29 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1153&range=28-29 Stats: 34 lines in 1 file changed: 11 ins; 12 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/1153.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1153/head:pull/1153 PR: https://git.openjdk.java.net/jdk/pull/1153 From github.com+168222+mgkwill at openjdk.java.net Wed Apr 28 18:38:31 2021 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Wed, 28 Apr 2021 18:38:31 GMT Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux [v29] In-Reply-To: References: <2UqkjBQ_wVQcz_qx2wjchZanODAw8-QB-qROH9kdLM0=.e1980df2-de0c-412f-b219-5ac2eb38fafb@github.com> Message-ID: On Mon, 26 Apr 2021 08:47:07 GMT, Stefan Johansson wrote: >> I also think that the log-tag should be `pagesize`. > > The comment here could also be updated: > > // Check LargePageSizeInBytes and setup _large_page_size to hold > // the maximum allowed large page size. If not set the default large > // page size is used as the maximum. ``` +1 ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From dfuchs at openjdk.java.net Wed Apr 28 18:47:08 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 28 Apr 2021 18:47:08 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v2] In-Reply-To: References: <9aIvV_N89PFpzwfhedEwNju-eKqhpZoFHL59F5pUv6g=.9c515555-c446-4280-8f24-88ffd753712f@github.com> Message-ID: On Wed, 28 Apr 2021 18:19:14 GMT, Maurizio Cimadamore wrote: >> src/java.base/share/classes/jdk/internal/module/IllegalNativeAccessChecker.java line 78: >> >>> 76: int index = 0; >>> 77: // the system property is removed after decoding >>> 78: String value = getAndRemoveProperty(prefix + index); >> >> I am not sure what is going on with the removal of the properties, but if I'm not mistaken this is racy: from the implementation of the checker() method above, it looks as if two different threads could trigger a call to the decode() function concurrently, which can result in a random partitioning of the properties against the two checkers being instantiated, with one of them being eventually set as the system-wide checker. > > I think the method is called during module bootstrap - I don't think there is a race in practice. This method is also called in other parts of ModuleBootstrap. The code you allude to is called during initialization of the IllegalNativeAccessChecker singleton, which should happen only once, and only from one thread. I'll take your word for it - the use of a volatile variable to store the singleton instance made this suspicious. ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From minqi at openjdk.java.net Wed Apr 28 19:00:20 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 28 Apr 2021 19:00:20 GMT Subject: RFR: 8255493: Support for pre-generated java.lang.invoke classes in CDS dynamic archive [v10] In-Reply-To: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> References: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> Message-ID: > Hi, Please review > > When do dynamic dump, the pre-generated lambda form classes from java.lang.invoke are not stored in dynamic archive. The patch will regenerate the four holder classes, > "java.lang.invoke.Invokers$Holder", > "java.lang.invoke.DirectMethodHandle$Holder", > "java.lang.invoke.DelegatingMethodHandle$Holder", > "java.lang.invoke.LambdaForm$Holder" > which will include the versions in static archive and new loaded functions all together and stored in dynamic archive. New test case added. > (Minor change to PrintSharedArchiveAtExit, which the index is not consecutive) > > Tests: tier1,tier2,tier3,tier4 > > Thanks > Yumin Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: Only store four lambda invoker (which will be regenerated in dynamic dump) lines in static archive ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3611/files - new: https://git.openjdk.java.net/jdk/pull/3611/files/78445575..05a7ca93 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3611&range=09 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3611&range=08-09 Stats: 43 lines in 1 file changed: 25 ins; 3 del; 15 mod Patch: https://git.openjdk.java.net/jdk/pull/3611.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3611/head:pull/3611 PR: https://git.openjdk.java.net/jdk/pull/3611 From dfuchs at openjdk.java.net Wed Apr 28 19:09:54 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Wed, 28 Apr 2021 19:09:54 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v2] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 10:42:54 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/412 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Address first batch of review comments src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/LibraryLookup.java line 52: > 50: *

    > 51: * For {@link #lookup(String) memory addresses} obtained from a library lookup object, > 52: * since {@link CLinker#downcallHandle(Addressable, MethodType, FunctionDescriptor) native method handles} These should be `{@linkplain }` since the text of the link is plain text (and not code) src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/LibraryLookup.java line 88: > 86: * @return the memory segment associated with the library symbol (if any). > 87: * @throws IllegalArgumentException if the address associated with the lookup symbol do not match the > 88: * {@link MemoryLayout#byteAlignment() alignment constraints} in {@code layout}. Same remark here (`{@linkplain }`) src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryAddress.java line 43: > 41: * when performing memory dereference operations using a memory access var handle (see {@link MemoryHandles}). > 42: *

    > 43: * A memory address is associated with a {@link ResourceScope resource scope}; the resource scope determines the `{@linkplain }` src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryAddress.java line 46: > 44: * lifecycle of the memory address, and whether the address can be used from multiple threads. Memory addresses > 45: * obtained from {@link #ofLong(long) numeric values}, or from native code, are associated with the > 46: * {@link ResourceScope#globalScope() global resource scope}. Memory addresses obtained from segments ... and here to (`{@linkplain }`) src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryAddress.java line 102: > 100: * @param segment the segment relative to which this address offset should be computed > 101: * @throws IllegalArgumentException if {@code segment} is not compatible with this address; this can happen, for instance, > 102: * when {@code segment} models an heap memory region, while this address is a {@link #isNative() native} address. `{@linkplain }` src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryAddress.java line 209: > 207: /** > 208: * The native memory address instance modelling the {@code NULL} address, associated > 209: * with the {@link ResourceScope#globalScope() global} resource scope. `{@linkplain }` ? ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From github.com+168222+mgkwill at openjdk.java.net Wed Apr 28 19:26:21 2021 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Wed, 28 Apr 2021 19:26:21 GMT Subject: RFR: 8265491: Math Signum optimization for x86 [v12] In-Reply-To: References: Message-ID: > x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM. > > We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization. > > Base: > > Benchmark Mode Cnt Score Error Units > Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op > Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op > Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op > Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op > > > Optimized: > signum intrinsic patch > > Benchmark Mode Cnt Score Error Units > Signum._1_signumFloatTest avgt 5 3.769 ? 0.015 ns/op > Signum._2_overheadFloat avgt 5 3.312 ? 0.025 ns/op > Signum._3_signumDoubleTest avgt 5 3.765 ? 0.005 ns/op > Signum._4_overheadDouble avgt 5 3.309 ? 0.010 ns/op > > > Signed-off-by: Marcus G K Williams Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision: jatin-bhateja review Signed-off-by: Marcus G K Williams ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3581/files - new: https://git.openjdk.java.net/jdk/pull/3581/files/c3478950..a3fae395 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3581&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3581&range=10-11 Stats: 24 lines in 2 files changed: 5 ins; 14 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/3581.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3581/head:pull/3581 PR: https://git.openjdk.java.net/jdk/pull/3581 From github.com+168222+mgkwill at openjdk.java.net Wed Apr 28 19:26:22 2021 From: github.com+168222+mgkwill at openjdk.java.net (Marcus G K Williams) Date: Wed, 28 Apr 2021 19:26:22 GMT Subject: RFR: 8265491: Math Signum optimization for x86 In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 08:38:14 GMT, Jatin Bhateja wrote: >> x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM. >> >> We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization. >> >> Base: >> >> Benchmark Mode Cnt Score Error Units >> Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op >> Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op >> Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op >> Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op >> >> >> Optimized: >> signum intrinsic patch >> >> Benchmark Mode Cnt Score Error Units >> Signum._1_signumFloatTest avgt 5 3.769 ? 0.015 ns/op >> Signum._2_overheadFloat avgt 5 3.312 ? 0.025 ns/op >> Signum._3_signumDoubleTest avgt 5 3.765 ? 0.005 ns/op >> Signum._4_overheadDouble avgt 5 3.309 ? 0.010 ns/op >> >> >> Signed-off-by: Marcus G K Williams > > @mgkwill, your newly added benchmark has 4 micro worklets, please publish the results for all of them. Thanks for your review @jatin-bhateja. I've implemented your suggested changes. ------------- PR: https://git.openjdk.java.net/jdk/pull/3581 From mcimadamore at openjdk.java.net Wed Apr 28 20:38:55 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 28 Apr 2021 20:38:55 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v2] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 19:02:57 GMT, Daniel Fuchs wrote: >> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: >> >> Address first batch of review comments > > src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryAddress.java line 209: > >> 207: /** >> 208: * The native memory address instance modelling the {@code NULL} address, associated >> 209: * with the {@link ResourceScope#globalScope() global} resource scope. > > `{@linkplain }` ? thanks - I'll do a pass - I think I probably got all of them wrong ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From dholmes at openjdk.java.net Wed Apr 28 20:40:52 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 28 Apr 2021 20:40:52 GMT Subject: RFR: 8255493: Support for pre-generated java.lang.invoke classes in CDS dynamic archive [v10] In-Reply-To: References: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> Message-ID: On Wed, 28 Apr 2021 19:00:20 GMT, Yumin Qi wrote: >> Hi, Please review >> >> When do dynamic dump, the pre-generated lambda form classes from java.lang.invoke are not stored in dynamic archive. The patch will regenerate the four holder classes, >> "java.lang.invoke.Invokers$Holder", >> "java.lang.invoke.DirectMethodHandle$Holder", >> "java.lang.invoke.DelegatingMethodHandle$Holder", >> "java.lang.invoke.LambdaForm$Holder" >> which will include the versions in static archive and new loaded functions all together and stored in dynamic archive. New test case added. >> (Minor change to PrintSharedArchiveAtExit, which the index is not consecutive) >> >> Tests: tier1,tier2,tier3,tier4 >> >> Thanks >> Yumin > > Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: > > Only store four lambda invoker (which will be regenerated in dynamic dump) lines in static archive src/hotspot/share/cds/lambdaFormInvokers.cpp line 82: > 80: } > 81: > 82: void LambdaFormInvokers::regenerate_holder_classes() { If this is no longer a TRAPS function then it should not be using CHECK macro: objArrayHandle list_lines = oopFactory::new_objArray_handle(vmClasses::String_klass(), len, CHECK); for (int i = 0; i < len; i++) { Handle h_line = java_lang_String::create_from_str(_lambdaform_lines->at(i), CHECK); If exceptions are not possible just use THREAD and comment why they are not possible. If they are possible then you need to use THREAD and handle them appropriately. ------------- PR: https://git.openjdk.java.net/jdk/pull/3611 From mcimadamore at openjdk.java.net Wed Apr 28 20:43:54 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 28 Apr 2021 20:43:54 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v3] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 18:33:36 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/412 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments: > * fix typos in javadoc > * document ISE being thrown in all methods accepting a scope; add more tests for that > > test/jdk/jdk/internal/reflect/CallerSensitive/CheckCSMs.java > > Yes that's the test. That test misses to catch your case where aliasing may be possible. > Yes that's the test. That test misses to catch your case where aliasing may be possible. To be clear - by aliasing you mean when the @CallerSensitive implementation is called with invokeinterface - so, e.g. doing `MethodHandles.lookup().findVirtual(CLinker.class, ...)` right? ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From mchung at openjdk.java.net Wed Apr 28 20:43:54 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 28 Apr 2021 20:43:54 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v3] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 20:38:47 GMT, Maurizio Cimadamore wrote: > To be clear - by aliasing you mean when the @CallerSensitive implementation is called with invokeinterface - so, e.g. doing `MethodHandles.lookup().findVirtual(CLinker.class, ...)` right? Yes. The caller would be java.base if it's invoked via method handle. ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From minqi at openjdk.java.net Wed Apr 28 20:54:54 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Wed, 28 Apr 2021 20:54:54 GMT Subject: RFR: 8255493: Support for pre-generated java.lang.invoke classes in CDS dynamic archive [v10] In-Reply-To: References: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> Message-ID: On Wed, 28 Apr 2021 20:37:39 GMT, David Holmes wrote: >> Yumin Qi has updated the pull request incrementally with one additional commit since the last revision: >> >> Only store four lambda invoker (which will be regenerated in dynamic dump) lines in static archive > > src/hotspot/share/cds/lambdaFormInvokers.cpp line 82: > >> 80: } >> 81: >> 82: void LambdaFormInvokers::regenerate_holder_classes() { > > If this is no longer a TRAPS function then it should not be using CHECK macro: > > > objArrayHandle list_lines = oopFactory::new_objArray_handle(vmClasses::String_klass(), len, CHECK); > for (int i = 0; i < len; i++) { > Handle h_line = java_lang_String::create_from_str(_lambdaform_lines->at(i), CHECK); > > > If exceptions are not possible just use THREAD and comment why they are not possible. If they are possible then you need to use THREAD and handle them appropriately. I will rework the dynamic dump so it will be like static dump --- handle exceptions after returned. So will remove the all the checks in this file. Thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/3611 From sviswanathan at openjdk.java.net Wed Apr 28 21:11:26 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Wed, 28 Apr 2021 21:11:26 GMT Subject: RFR: 8265783: Create a separate library for x86 Intel SVML assembly intrinsics [v2] In-Reply-To: References: Message-ID: > Intel Short Vector Math Library (SVML) based intrinsics in native x86 assembly provide optimized implementation for Vector API transcendental and trigonometric methods. > These methods are built into a separate library instead of being part of libjvm.so or jvm.dll. > > The following changes are made: > The source for these methods is placed in the jdk.incubator.vector module under src/jdk.incubator.vector/linux/native/libsvml and src/jdk.incubator.vector/windows/native/libsvml. > The assembly source files are named as ?*.S? and include files are named as ?*.S.inc?. > The corresponding build script is placed at make/modules/jdk.incubator.vector/Lib.gmk. > Changes are made to build system to support dependency tracking for assembly files with includes. > The built native libraries (libsvml.so/svml.dll) are placed in bin directory of JDK on Windows and lib directory of JDK on Linux. > The C2 JIT uses the dll_load and dll_lookup to get the addresses of optimized methods from this library. > > Build system changes and module library build scripts are contributed by Magnus (magnus.ihse.bursie at oracle.com). > > This work is part of second round of incubation of the Vector API. > JEP: https://bugs.openjdk.java.net/browse/JDK-8261663 > > Please review. > > Performance: > Micro benchmark Base Optimized Unit Gain(Optimized/Base) > Double128Vector.ACOS 45.91 87.34 ops/ms 1.90 > Double128Vector.ASIN 45.06 92.36 ops/ms 2.05 > Double128Vector.ATAN 19.92 118.36 ops/ms 5.94 > Double128Vector.ATAN2 15.24 88.17 ops/ms 5.79 > Double128Vector.CBRT 45.77 208.36 ops/ms 4.55 > Double128Vector.COS 49.94 245.89 ops/ms 4.92 > Double128Vector.COSH 26.91 126.00 ops/ms 4.68 > Double128Vector.EXP 71.64 379.65 ops/ms 5.30 > Double128Vector.EXPM1 35.95 150.37 ops/ms 4.18 > Double128Vector.HYPOT 50.67 174.10 ops/ms 3.44 > Double128Vector.LOG 61.95 279.84 ops/ms 4.52 > Double128Vector.LOG10 59.34 239.05 ops/ms 4.03 > Double128Vector.LOG1P 18.56 200.32 ops/ms 10.79 > Double128Vector.SIN 49.36 240.79 ops/ms 4.88 > Double128Vector.SINH 26.59 103.75 ops/ms 3.90 > Double128Vector.TAN 41.05 152.39 ops/ms 3.71 > Double128Vector.TANH 45.29 169.53 ops/ms 3.74 > Double256Vector.ACOS 54.21 106.39 ops/ms 1.96 > Double256Vector.ASIN 53.60 107.99 ops/ms 2.01 > Double256Vector.ATAN 21.53 189.11 ops/ms 8.78 > Double256Vector.ATAN2 16.67 140.76 ops/ms 8.44 > Double256Vector.CBRT 56.45 397.13 ops/ms 7.04 > Double256Vector.COS 58.26 389.77 ops/ms 6.69 > Double256Vector.COSH 29.44 151.11 ops/ms 5.13 > Double256Vector.EXP 86.67 564.68 ops/ms 6.52 > Double256Vector.EXPM1 41.96 201.28 ops/ms 4.80 > Double256Vector.HYPOT 66.18 305.74 ops/ms 4.62 > Double256Vector.LOG 71.52 394.90 ops/ms 5.52 > Double256Vector.LOG10 65.43 362.32 ops/ms 5.54 > Double256Vector.LOG1P 19.99 300.88 ops/ms 15.05 > Double256Vector.SIN 57.06 380.98 ops/ms 6.68 > Double256Vector.SINH 29.40 117.37 ops/ms 3.99 > Double256Vector.TAN 44.90 279.90 ops/ms 6.23 > Double256Vector.TANH 54.08 274.71 ops/ms 5.08 > Double512Vector.ACOS 55.65 687.54 ops/ms 12.35 > Double512Vector.ASIN 57.31 777.72 ops/ms 13.57 > Double512Vector.ATAN 21.42 729.21 ops/ms 34.04 > Double512Vector.ATAN2 16.37 414.33 ops/ms 25.32 > Double512Vector.CBRT 56.78 834.38 ops/ms 14.69 > Double512Vector.COS 59.88 837.04 ops/ms 13.98 > Double512Vector.COSH 30.34 172.76 ops/ms 5.70 > Double512Vector.EXP 99.66 1608.12 ops/ms 16.14 > Double512Vector.EXPM1 43.39 318.61 ops/ms 7.34 > Double512Vector.HYPOT 73.87 1502.72 ops/ms 20.34 > Double512Vector.LOG 74.84 996.00 ops/ms 13.31 > Double512Vector.LOG10 71.12 1046.52 ops/ms 14.72 > Double512Vector.LOG1P 19.75 776.87 ops/ms 39.34 > Double512Vector.POW 37.42 384.13 ops/ms 10.26 > Double512Vector.SIN 59.74 728.45 ops/ms 12.19 > Double512Vector.SINH 29.47 143.38 ops/ms 4.87 > Double512Vector.TAN 46.20 587.21 ops/ms 12.71 > Double512Vector.TANH 57.36 495.42 ops/ms 8.64 > Double64Vector.ACOS 24.04 73.67 ops/ms 3.06 > Double64Vector.ASIN 23.78 75.11 ops/ms 3.16 > Double64Vector.ATAN 14.14 62.81 ops/ms 4.44 > Double64Vector.ATAN2 10.38 44.43 ops/ms 4.28 > Double64Vector.CBRT 16.47 107.50 ops/ms 6.53 > Double64Vector.COS 23.42 152.01 ops/ms 6.49 > Double64Vector.COSH 17.34 113.34 ops/ms 6.54 > Double64Vector.EXP 27.08 203.53 ops/ms 7.52 > Double64Vector.EXPM1 18.77 96.73 ops/ms 5.15 > Double64Vector.HYPOT 18.54 103.62 ops/ms 5.59 > Double64Vector.LOG 26.75 142.63 ops/ms 5.33 > Double64Vector.LOG10 25.85 139.71 ops/ms 5.40 > Double64Vector.LOG1P 13.26 97.94 ops/ms 7.38 > Double64Vector.SIN 23.28 146.91 ops/ms 6.31 > Double64Vector.SINH 17.62 88.59 ops/ms 5.03 > Double64Vector.TAN 21.00 86.43 ops/ms 4.12 > Double64Vector.TANH 23.75 111.35 ops/ms 4.69 > Float128Vector.ACOS 57.52 110.65 ops/ms 1.92 > Float128Vector.ASIN 57.15 117.95 ops/ms 2.06 > Float128Vector.ATAN 22.52 318.74 ops/ms 14.15 > Float128Vector.ATAN2 17.06 246.07 ops/ms 14.42 > Float128Vector.CBRT 29.72 443.74 ops/ms 14.93 > Float128Vector.COS 42.82 803.02 ops/ms 18.75 > Float128Vector.COSH 31.44 118.34 ops/ms 3.76 > Float128Vector.EXP 72.43 855.33 ops/ms 11.81 > Float128Vector.EXPM1 37.82 127.85 ops/ms 3.38 > Float128Vector.HYPOT 53.20 591.68 ops/ms 11.12 > Float128Vector.LOG 52.95 877.94 ops/ms 16.58 > Float128Vector.LOG10 49.26 603.72 ops/ms 12.26 > Float128Vector.LOG1P 20.89 430.59 ops/ms 20.61 > Float128Vector.SIN 43.38 745.31 ops/ms 17.18 > Float128Vector.SINH 31.11 112.91 ops/ms 3.63 > Float128Vector.TAN 37.25 332.13 ops/ms 8.92 > Float128Vector.TANH 57.63 453.77 ops/ms 7.87 > Float256Vector.ACOS 65.23 123.73 ops/ms 1.90 > Float256Vector.ASIN 63.41 132.86 ops/ms 2.10 > Float256Vector.ATAN 23.51 649.02 ops/ms 27.61 > Float256Vector.ATAN2 18.19 455.95 ops/ms 25.07 > Float256Vector.CBRT 45.99 594.81 ops/ms 12.93 > Float256Vector.COS 43.75 926.69 ops/ms 21.18 > Float256Vector.COSH 33.52 130.46 ops/ms 3.89 > Float256Vector.EXP 75.70 1366.72 ops/ms 18.05 > Float256Vector.EXPM1 39.00 149.72 ops/ms 3.84 > Float256Vector.HYPOT 52.91 1023.18 ops/ms 19.34 > Float256Vector.LOG 53.31 1545.77 ops/ms 29.00 > Float256Vector.LOG10 50.31 863.80 ops/ms 17.17 > Float256Vector.LOG1P 21.51 616.59 ops/ms 28.66 > Float256Vector.SIN 44.07 911.04 ops/ms 20.67 > Float256Vector.SINH 33.16 122.50 ops/ms 3.69 > Float256Vector.TAN 37.85 497.75 ops/ms 13.15 > Float256Vector.TANH 64.27 537.20 ops/ms 8.36 > Float512Vector.ACOS 67.33 1718.00 ops/ms 25.52 > Float512Vector.ASIN 66.12 1780.85 ops/ms 26.93 > Float512Vector.ATAN 22.63 1780.31 ops/ms 78.69 > Float512Vector.ATAN2 17.52 1113.93 ops/ms 63.57 > Float512Vector.CBRT 54.78 2087.58 ops/ms 38.11 > Float512Vector.COS 40.92 1567.93 ops/ms 38.32 > Float512Vector.COSH 33.42 138.36 ops/ms 4.14 > Float512Vector.EXP 70.51 3835.97 ops/ms 54.41 > Float512Vector.EXPM1 38.06 279.80 ops/ms 7.35 > Float512Vector.HYPOT 50.99 3287.55 ops/ms 64.47 > Float512Vector.LOG 49.61 3156.99 ops/ms 63.64 > Float512Vector.LOG10 46.94 2489.16 ops/ms 53.02 > Float512Vector.LOG1P 20.66 1689.86 ops/ms 81.81 > Float512Vector.POW 32.73 1015.85 ops/ms 31.04 > Float512Vector.SIN 41.17 1587.71 ops/ms 38.56 > Float512Vector.SINH 33.05 129.39 ops/ms 3.91 > Float512Vector.TAN 35.60 1336.11 ops/ms 37.53 > Float512Vector.TANH 65.77 2295.28 ops/ms 34.90 > Float64Vector.ACOS 48.41 89.34 ops/ms 1.85 > Float64Vector.ASIN 47.30 95.72 ops/ms 2.02 > Float64Vector.ATAN 20.62 49.45 ops/ms 2.40 > Float64Vector.ATAN2 15.95 112.35 ops/ms 7.04 > Float64Vector.CBRT 24.03 134.57 ops/ms 5.60 > Float64Vector.COS 44.28 394.33 ops/ms 8.91 > Float64Vector.COSH 28.35 95.27 ops/ms 3.36 > Float64Vector.EXP 65.80 486.37 ops/ms 7.39 > Float64Vector.EXPM1 34.61 85.99 ops/ms 2.48 > Float64Vector.HYPOT 50.40 147.82 ops/ms 2.93 > Float64Vector.LOG 51.93 163.25 ops/ms 3.14 > Float64Vector.LOG10 49.53 147.98 ops/ms 2.99 > Float64Vector.LOG1P 19.20 206.81 ops/ms 10.77 > Float64Vector.SIN 44.41 382.09 ops/ms 8.60 > Float64Vector.SINH 28.20 90.68 ops/ms 3.22 > Float64Vector.TAN 36.29 160.89 ops/ms 4.43 > Float64Vector.TANH 47.65 214.04 ops/ms 4.49 Sandhya Viswanathan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - Merge master - remove whitespace - Merge master - Small fix - cleanup - x86 short vector math optimization for Vector API ------------- Changes: https://git.openjdk.java.net/jdk/pull/3638/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3638&range=01 Stats: 417102 lines in 120 files changed: 416935 ins; 123 del; 44 mod Patch: https://git.openjdk.java.net/jdk/pull/3638.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3638/head:pull/3638 PR: https://git.openjdk.java.net/jdk/pull/3638 From mcimadamore at openjdk.java.net Wed Apr 28 21:13:53 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 28 Apr 2021 21:13:53 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v3] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 20:40:49 GMT, Mandy Chung wrote: > > To be clear - by aliasing you mean when the @CallerSensitive implementation is called with invokeinterface - so, e.g. doing `MethodHandles.lookup().findVirtual(CLinker.class, ...)` right? > > Yes. The caller would be java.base if it's invoked via method handle. I just did a test: public class TestLookup { public static void main(String[] args) throws Throwable { MethodHandle handle = MethodHandles.lookup().findVirtual(CLinker.class, "downcallHandle", MethodType.methodType(MethodHandle.class, Addressable.class, MethodType.class, FunctionDescriptor.class)); CLinker linker = CLinker.getInstance(); handle.invoke(linker, MemoryAddress.NULL, MethodType.methodType(void.class), FunctionDescriptor.ofVoid()); } } this fails as expected when the handle is invoked. To test I had to disable the check on CLinker.getInstance - otherwise that would have always throw anyway. Also, on IllegalCaller vs. IllegalAccess - looking more, I think our impl throws IllegalCaller - now that was done because IllegalAccess is a checked exception and we don't want a checked exception here - but the option is called "enableNativeAccess" - is that still ok? ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From mcimadamore at openjdk.java.net Wed Apr 28 21:49:50 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Wed, 28 Apr 2021 21:49:50 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v2] In-Reply-To: References: <9aIvV_N89PFpzwfhedEwNju-eKqhpZoFHL59F5pUv6g=.9c515555-c446-4280-8f24-88ffd753712f@github.com> Message-ID: On Wed, 28 Apr 2021 18:44:18 GMT, Daniel Fuchs wrote: >> I think the method is called during module bootstrap - I don't think there is a race in practice. This method is also called in other parts of ModuleBootstrap. The code you allude to is called during initialization of the IllegalNativeAccessChecker singleton, which should happen only once, and only from one thread. > > I'll take your word for it - the use of a volatile variable to store the singleton instance made this suspicious. good point - I think that came in when I adapted the code from IllegalAccessLogger - which can indeed be accessed from multiple threads. In this case the initialization is effectively part of bootstrap, and volatile is not required. ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From mchung at openjdk.java.net Wed Apr 28 23:26:01 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Wed, 28 Apr 2021 23:26:01 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v3] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 21:10:33 GMT, Maurizio Cimadamore wrote: > I just did a test: > > ``` > public class TestLookup { > public static void main(String[] args) throws Throwable { > MethodHandle handle = MethodHandles.lookup().findVirtual(CLinker.class, "downcallHandle", MethodType.methodType(MethodHandle.class, Addressable.class, MethodType.class, FunctionDescriptor.class)); > CLinker linker = CLinker.getInstance(); > handle.invoke(linker, MemoryAddress.NULL, MethodType.methodType(void.class), FunctionDescriptor.ofVoid()); > } > } > ``` > > this fails as expected when the handle is invoked. To test I had to disable the check on CLinker.getInstance - otherwise that would have always throw anyway. My statement was overly simplified. If `handle` is invoked in another module B and invoked by a class in module B, which module (the `lookup`'s module or ) do you expect be the caller to check against for native access check? `CLinker::downcallHandle` is not caller-sensitive but its implementation is. The method handle of a caller-sensitive method behaves as if it were called from an instruction contained in the lookup class [1]. [1] https://download.java.net/java/early_access/jdk17/docs/api/java.base/java/lang/invoke/MethodHandles.Lookup.html#callsens > Also, on IllegalCaller vs. IllegalAccess - looking more, I think our impl throws IllegalCaller - now that was done because IllegalAccess is a checked exception and we don't want a checked exception here - but the option is called "enableNativeAccess" - is that still ok? Yes the implementation throws `IllegalCallerException` which is why I point out this. Hmm... this seems more of `IllegalAccess` as the caller does not have access to this restricted method. OTOH, `Module::addOpens` grants deep reflection access to the named module if the caller has access. Otherwise, `IllegalCallerException` is thrown. So I think it's okay to throw ICE. Others may have a different opinion. ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From yyang at openjdk.java.net Thu Apr 29 02:33:52 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Thu, 29 Apr 2021 02:33:52 GMT Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex [v2] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 17:32:18 GMT, Igor Veresov wrote: > Do we need to keep this flag? Exactly, the flag should be removed. Thanks, Yang ------------- PR: https://git.openjdk.java.net/jdk/pull/3615 From yyang at openjdk.java.net Thu Apr 29 02:47:19 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Thu, 29 Apr 2021 02:47:19 GMT Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex [v3] In-Reply-To: References: Message-ID: > The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version. > > In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot. > > But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later: > > 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase. > 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag > > Testing: cds, compiler and jdk Yi Yang has updated the pull request incrementally with one additional commit since the last revision: remove InlineNIOCheckIndex flag ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3615/files - new: https://git.openjdk.java.net/jdk/pull/3615/files/7f30dc48..db8b6ef4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=01-02 Stats: 23 lines in 3 files changed: 11 ins; 11 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3615.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3615/head:pull/3615 PR: https://git.openjdk.java.net/jdk/pull/3615 From yyang at openjdk.java.net Thu Apr 29 02:53:18 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Thu, 29 Apr 2021 02:53:18 GMT Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex [v4] In-Reply-To: References: Message-ID: > The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version. > > In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot. > > But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later: > > 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase. > 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag > > Testing: cds, compiler and jdk Yi Yang has updated the pull request incrementally with one additional commit since the last revision: remove extra newline ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3615/files - new: https://git.openjdk.java.net/jdk/pull/3615/files/db8b6ef4..bbdf4b9e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3615.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3615/head:pull/3615 PR: https://git.openjdk.java.net/jdk/pull/3615 From xxinliu at amazon.com Thu Apr 29 06:19:35 2021 From: xxinliu at amazon.com (Liu, Xin) Date: Wed, 28 Apr 2021 23:19:35 -0700 Subject: Request For Comment: Asynchronous Logging In-Reply-To: <3579bad2-a6a0-fd84-22e6-09d175df7a4b@oss.nttdata.com> References: <7FEF3035-8926-467C-AD7B-A001A9C8FD5B@amazon.com> <2170bebc-e5a2-219c-0a4b-f41623098c43@amazon.com> <3579bad2-a6a0-fd84-22e6-09d175df7a4b@oss.nttdata.com> Message-ID: hi, Yasumsa, I have updated the CSR to reflect the latest discussion. To simplify implementation and user interface, we decide to have only one global option. A global flag -Xlog:async set the asynclogging mode for all log outputs, before and after -Xlog:async. According to my test, with default size of buffer, All log tagsets can write asynchronously and I hardly observe the buffer overflows. Another argument is that we don't think it's a very common the end-users need to define different outputs with different async properties. Please note that it is supposed to include stdout/stderr streams if -Xlog:async is set. pull/3135 only supports LogFileOutput. I will create a JBS issue and hoist the current logics to LogFileStreamOutput, which includes stdout/stderr as well. thanks, --lx On 4/27/21 4:35 PM, Yasumasa Suenaga wrote: > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > Hi Xin, > > On 2021/04/28 2:17, Liu, Xin wrote: >> Hi, >> >> I would like to report my current progress. I have finished all pending >> tasks except "hoist async_mode to base class for stdout/err". May I ask >> to defer it after this PR? I will create an issue and work on it >> immediately after this PR. It's not difficult but I need to modify the >> existing interfaces. I would like to keep this PR almost "added" to ease >> reviewers. >> >> If Yasumasa allows me to do so, now the only blocker is CSR. it seems >> that Iom and Thomas agree with a global option. Shall we go that way? > > I agree with you, but I'm not clear a bit between "async=" in -Xlog and -XX:+AsyncLogging. > > CSR says about them in below, but I think they are not same because -XX:AsyncLogging affects global, on the other hand "async=" affects in each log output. Is it right? > > ----- > Unified Logging framework can define a global option -Xlog:async[=true|false]. The effect is same as -XX:+/-AsyncLogging > ----- > > > Thanks, > > Yasumasa > > >> Meanwhile, I have pushed all my code to github: >> https://github.com/openjdk/jdk/pull/3135 >> >> Could you take a look it? >> >> ------------------------------------------------------------- >> | request | Status | >> ------------------------------------------------------------- >> | independent NonJavaThread | done | >> |-----------------------------------------------------------| >> | pass tier1-test with +AsyncLogging | [1] | >> |-----------------------------------------------------------| >> | inject meta-info to display no. of dropping msg. | done | >> |-----------------------------------------------------------| >> | support jcmd VM.log | done | >> |-----------------------------------------------------------| >> | preserve accurate decorations | | >> |-----------------------------------------------------------<- progress >> | hoist async_mode to base class for stdout/err| | >> |-----------------------------------------------------------| >> | CSR |JDK-8264323 | >> |-----------------------------------------------------------<- consensus >> |use string table over malloc | | >> ------------------------------------------------------------| >> |use lock-free data structure. | | >> ------------------------------------------------------------- >> >> >> [1] the only exception is serviceability/dcmd/gc/RunGCTest.java. it >> emits gclog and checks result right away without any synchronization. if >> we do run jtreg test with async logging, I need to add an flushing api >> in whitebox. >> >> >> thanks, >> --lx >> From stuefe at openjdk.java.net Thu Apr 29 06:59:03 2021 From: stuefe at openjdk.java.net (Thomas Stuefe) Date: Thu, 29 Apr 2021 06:59:03 GMT Subject: RFR: 8229517: Support for optional asynchronous/buffered logging [v9] In-Reply-To: <9NrS00PFPoWlahBK0TCWHRTNWYGKePcVkYPEnr6Dtm4=.f8f9c9a4-fc98-4108-8a38-734e21d4b1d9@github.com> References: <9NrS00PFPoWlahBK0TCWHRTNWYGKePcVkYPEnr6Dtm4=.f8f9c9a4-fc98-4108-8a38-734e21d4b1d9@github.com> Message-ID: On Mon, 26 Apr 2021 20:45:23 GMT, Xin Liu wrote: >> Xin Liu has updated the pull request incrementally with two additional commits since the last revision: >> >> - Fix bugs/style/typo based on reviewers' feedbacks. >> - Accurate Decorations for AsyncLogging. >> >> A lightweight LogDecorationRef is created to keep LogDecorations at >> logging site. It uses refcnt to keep track multiple usage and >> automatically clean up. If no decorator is in use, no LogDecorationRef >> is created. > > ### Integration Test > We understand that a feature is useless or even harmful if it's buggy. In addition to the gtest in this PR, we also set up an integration tests to verify it. > > 1. The full-brunt logging in an entire jvm lifecycle > The following command dump **all** logs in trace verbosity in async logging mode. > There are 13k messages and no one is dropped from [0.004s] to [0.087s] > >> time ./build/linux-x86_64-server-release/images/jdk/bin/java -Xlog:'all=trace:file=hotspot.log:uptime,tid,l,tg:filecount=0,async=true' --version > > > $wc -l hotspot.log > 13386 hotspot.log > $grep "messages dropped" hotspot.log -n > > > 2. Gclog test > We directly use the testcase in linkedin whitepaper[1]. [Test.java](https://github.com/navyxliu/JavaGCworkload/blob/master/Test.java) launches N threads and each one churns up java heap by allocating String objects. We use the default gc(G1GC) of jdk17. > > The following command runs infinite time with 10g heap. It launches 4 threads and dump gc logs in trace verbosity. >> java -Xmx10g -Xms10g -Xlog:gc=trace:file=gc.log::async=true Test -1 4 > > We have been running it over a week and no message is drop. > > 3. Gclog test with dropping messages > The following command still uses Test.java introduced in prior test, it dumps all logset as long as it contains `gc`. > IIUC, it simulates `-XX:+PrintGCDetails`. It still starts 4 threads and the test ends in 180s. > >> java -Xmx10g -Xms10g -Xlog:'gc*=trace:file=gc-star.log::async=true' Test 180 4 > > Log rotation works correctly. Give the verbose log and intense gc activities, we do observe some logs dropped. > > In gc-star.log.0, whose timestamp is from [11445.736s] to [11449.168s], it totally drops 4717 messages out of 130224, or 3.6% messages are ditched. > > No message is dropped after we enlarge the buffer to -XX:AsyncLogBufferSize=102400. > In debug build, hotspot will dump dropping messages to tty console with `-XX:+Verbose`. > > 4. Gclog test with dynamical reconfiguration > While running Test 3, we can dynamically reconfigure logs using jcmd VM.log > > We use a [script](https://github.com/navyxliu/JavaGCworkload/blob/master/jcmd_test.sh) to disable all outputs and re-create a file-based output in async mode. We periodic ran the script in a day and no problem has been identified. > > 5. Gclog test with NMT > the following command is same as 3 plus `-XX:NativeMemoryTracking=summary` >> java -Xmx10g -Xms10g -Xlog:'gc*=trace:file=gc-star.log::async=true' -XX:NativeMemoryTracking=summary Test -1 4 > > We use a [script](https://github.com/navyxliu/JavaGCworkload/blob/master/monitor_nmt.sh) to monitor NMT summary. All offheap allocation are marked "mtLogging". We don't observe memory leak on Logging category in long-haul running. > > We also ran asynchorous logging in Minecraft 1.16.5 on both Linux and MacOS. No problem has been captured yet. > > [1] https://engineering.linkedin.com/blog/2016/02/eliminating-large-jvm-gc-pauses-caused-by-background-io-traffic Hi @navyxliu , sorry for the quiet time, but good work on the testing! Had a read through your patch. One thing I dislike is the optimization you did for LogDecorations. I see what you did there, but this makes the coding a lot more unreadable while being not a perfect solution. The fact that LogDecorations are implemented with a fixed sized 256 char buffer is not perfect today even outside the context of async logging. It may still be too small (interestingly, one thing I noticed is that UL does not have standard decorators like "file" and "line" which may exhaust that buffer). While still taking much too much memory on average, especially in a context like yours where you want to store resolved decorations. I propose to tackle that problem separately though, independently from your patch. One possible solution we have done in the past with similar problems is to delay the string resolution and store the raw data for printing in some kind of vector (similar to a va_arg pointer). But I'd leave this for another day, your patch is complex as it is. For now I propose one of two things: - Either live with the full Decorations and pay the 256char-per-message price - Or, just resolve the decorations in the async logger thread, for now clearly document it as "works as designed, decorators (e.g. tid) may be off if async logging is engaged") and in both cases wait for the follow-up RFE to introduce a better way to persist decorations. What do you think? Cheers, Thomas ------------- PR: https://git.openjdk.java.net/jdk/pull/3135 From tschatzl at openjdk.java.net Thu Apr 29 07:08:54 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Thu, 29 Apr 2021 07:08:54 GMT Subject: RFR: 8234532: Remove ThreadLocalAllocBuffer::_fast_refill_waste since it is never set [v2] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 09:41:14 GMT, Albert Mingkun Yang wrote: >> It has some cascading effect; two performance variables, `fastWaste` and `maxFastWaste`, can be removed also. > > Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - merge > - refill Lgtm apart from that minor formatting nit. src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp line 109: > 107: _slow_refill_waste); > 108: } else { > 109: assert(_number_of_refills == 0 && Please fill back the clause from the next line. I think the assert condition now fits a single line, the text may be on the next line ------------- Marked as reviewed by tschatzl (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3756 From thomas.stuefe at gmail.com Thu Apr 29 07:23:34 2021 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 29 Apr 2021 09:23:34 +0200 Subject: Request For Comment: Asynchronous Logging In-Reply-To: References: <7FEF3035-8926-467C-AD7B-A001A9C8FD5B@amazon.com> <2170bebc-e5a2-219c-0a4b-f41623098c43@amazon.com> Message-ID: Good job, Xin. For the record, I am fine with delaying the stdout/err async tracing to another RFE. I added some more notes to the PR. ..Thomas On Tue, Apr 27, 2021 at 7:17 PM Liu, Xin wrote: > Hi, > > I would like to report my current progress. I have finished all pending > tasks except "hoist async_mode to base class for stdout/err". May I ask > to defer it after this PR? I will create an issue and work on it > immediately after this PR. It's not difficult but I need to modify the > existing interfaces. I would like to keep this PR almost "added" to ease > reviewers. > > If Yasumasa allows me to do so, now the only blocker is CSR. it seems > that Iom and Thomas agree with a global option. Shall we go that way? > > Meanwhile, I have pushed all my code to github: > https://github.com/openjdk/jdk/pull/3135 > > Could you take a look it? > > ------------------------------------------------------------- > | request | Status | > ------------------------------------------------------------- > | independent NonJavaThread | done | > |-----------------------------------------------------------| > | pass tier1-test with +AsyncLogging | [1] | > |-----------------------------------------------------------| > | inject meta-info to display no. of dropping msg. | done | > |-----------------------------------------------------------| > | support jcmd VM.log | done | > |-----------------------------------------------------------| > | preserve accurate decorations | | > |-----------------------------------------------------------<- progress > | hoist async_mode to base class for stdout/err| | > |-----------------------------------------------------------| > | CSR |JDK-8264323 | > |-----------------------------------------------------------<- consensus > |use string table over malloc | | > ------------------------------------------------------------| > |use lock-free data structure. | | > ------------------------------------------------------------- > > > [1] the only exception is serviceability/dcmd/gc/RunGCTest.java. it > emits gclog and checks result right away without any synchronization. if > we do run jtreg test with async logging, I need to add an flushing api > in whitebox. > > > thanks, > --lx > > From suenaga at oss.nttdata.com Thu Apr 29 07:55:46 2021 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Thu, 29 Apr 2021 16:55:46 +0900 Subject: Request For Comment: Asynchronous Logging In-Reply-To: References: <7FEF3035-8926-467C-AD7B-A001A9C8FD5B@amazon.com> <2170bebc-e5a2-219c-0a4b-f41623098c43@amazon.com> <3579bad2-a6a0-fd84-22e6-09d175df7a4b@oss.nttdata.com> Message-ID: <4b94c4c59f8885ce6791d433f81702ce@oss.nttdata.com> Hi, The CSR looks good to me. Thank you for the update! Yasumasa 2021-04-29 15:19 ? Liu, Xin ????????: > hi, Yasumsa, > > I have updated the CSR to reflect the latest discussion. To simplify > implementation and user interface, we decide to have only one global > option. A global flag -Xlog:async set the asynclogging mode for all log > outputs, before and after -Xlog:async. > > According to my test, with default size of buffer, All log tagsets can > write asynchronously and I hardly observe the buffer overflows. Another > argument is that we don't think it's a very common the end-users need > to > define different outputs with different async properties. > > Please note that it is supposed to include stdout/stderr streams if > -Xlog:async is set. pull/3135 only supports LogFileOutput. I will > create > a JBS issue and hoist the current logics to LogFileStreamOutput, which > includes stdout/stderr as well. > > > thanks, > --lx > > > > > > > > > > > On 4/27/21 4:35 PM, Yasumasa Suenaga wrote: >> CAUTION: This email originated from outside of the organization. Do >> not > click links or open attachments unless you can confirm the sender and > know the content is safe. >> >> >> >> Hi Xin, >> >> On 2021/04/28 2:17, Liu, Xin wrote: >>> Hi, >>> >>> I would like to report my current progress. I have finished all >>> pending >>> tasks except "hoist async_mode to base class for stdout/err". May I >>> ask >>> to defer it after this PR? I will create an issue and work on it >>> immediately after this PR. It's not difficult but I need to modify >>> the >>> existing interfaces. I would like to keep this PR almost "added" to >>> ease >>> reviewers. >>> >>> If Yasumasa allows me to do so, now the only blocker is CSR. it seems >>> that Iom and Thomas agree with a global option. Shall we go that way? >> >> I agree with you, but I'm not clear a bit between "async=" in -Xlog >> and -XX:+AsyncLogging. >> >> CSR says about them in below, but I think they are not same because >> -XX:AsyncLogging affects global, on the other hand "async=" affects in >> each log output. Is it right? >> >> ----- >> Unified Logging framework can define a global option >> -Xlog:async[=true|false]. The effect is same as -XX:+/-AsyncLogging >> ----- >> >> >> Thanks, >> >> Yasumasa >> >> >>> Meanwhile, I have pushed all my code to github: >>> https://github.com/openjdk/jdk/pull/3135 >>> >>> Could you take a look it? >>> >>> ------------------------------------------------------------- >>> | request | Status | >>> ------------------------------------------------------------- >>> | independent NonJavaThread | done | >>> |-----------------------------------------------------------| >>> | pass tier1-test with +AsyncLogging | [1] | >>> |-----------------------------------------------------------| >>> | inject meta-info to display no. of dropping msg. | done | >>> |-----------------------------------------------------------| >>> | support jcmd VM.log | done | >>> |-----------------------------------------------------------| >>> | preserve accurate decorations | | >>> |-----------------------------------------------------------<- >>> progress >>> | hoist async_mode to base class for stdout/err| | >>> |-----------------------------------------------------------| >>> | CSR |JDK-8264323 | >>> |-----------------------------------------------------------<- >>> consensus >>> |use string table over malloc | | >>> ------------------------------------------------------------| >>> |use lock-free data structure. | | >>> ------------------------------------------------------------- >>> >>> >>> [1] the only exception is serviceability/dcmd/gc/RunGCTest.java. it >>> emits gclog and checks result right away without any synchronization. >>> if >>> we do run jtreg test with async logging, I need to add an flushing >>> api >>> in whitebox. >>> >>> >>> thanks, >>> --lx >>> From ayang at openjdk.java.net Thu Apr 29 08:11:12 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Thu, 29 Apr 2021 08:11:12 GMT Subject: RFR: 8234532: Remove ThreadLocalAllocBuffer::_fast_refill_waste since it is never set [v3] In-Reply-To: References: Message-ID: > It has some cascading effect; two performance variables, `fastWaste` and `maxFastWaste`, can be removed also. Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: review ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3756/files - new: https://git.openjdk.java.net/jdk/pull/3756/files/867bbe14..dcaff0bb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3756&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3756&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3756.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3756/head:pull/3756 PR: https://git.openjdk.java.net/jdk/pull/3756 From sjohanss at openjdk.java.net Thu Apr 29 08:40:51 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Thu, 29 Apr 2021 08:40:51 GMT Subject: RFR: 8234532: Remove ThreadLocalAllocBuffer::_fast_refill_waste since it is never set [v3] In-Reply-To: References: Message-ID: On Thu, 29 Apr 2021 08:11:12 GMT, Albert Mingkun Yang wrote: >> It has some cascading effect; two performance variables, `fastWaste` and `maxFastWaste`, can be removed also. > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Looks good. ------------- Marked as reviewed by sjohanss (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3756 From pliden at openjdk.java.net Thu Apr 29 08:49:54 2021 From: pliden at openjdk.java.net (Per Liden) Date: Thu, 29 Apr 2021 08:49:54 GMT Subject: RFR: 8234532: Remove ThreadLocalAllocBuffer::_fast_refill_waste since it is never set [v3] In-Reply-To: References: Message-ID: On Thu, 29 Apr 2021 08:11:12 GMT, Albert Mingkun Yang wrote: >> It has some cascading effect; two performance variables, `fastWaste` and `maxFastWaste`, can be removed also. > > Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision: > > review Looks good. But we should also probably rename `_slow_refill_waste` to `_refill_waste`, since "slow" doesn't really make sense anymore. Of course, that would also affect the `slowWaste` PerfCounter. Maybe this could be a follow up refinement? ------------- Marked as reviewed by pliden (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3756 From ayang at openjdk.java.net Thu Apr 29 09:06:51 2021 From: ayang at openjdk.java.net (Albert Mingkun Yang) Date: Thu, 29 Apr 2021 09:06:51 GMT Subject: RFR: 8234532: Remove ThreadLocalAllocBuffer::_fast_refill_waste since it is never set [v3] In-Reply-To: References: Message-ID: On Thu, 29 Apr 2021 08:46:57 GMT, Per Liden wrote: > Maybe this could be a follow up refinement? Sure, will do so after this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/3756 From jbhateja at openjdk.java.net Thu Apr 29 09:07:56 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Thu, 29 Apr 2021 09:07:56 GMT Subject: RFR: 8265491: Math Signum optimization for x86 [v12] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 19:26:21 GMT, Marcus G K Williams wrote: >> x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM. >> >> We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization. >> >> Base: >> >> Benchmark Mode Cnt Score Error Units >> Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op >> Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op >> Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op >> Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op >> >> >> Optimized: >> signum intrinsic patch >> >> Benchmark Mode Cnt Score Error Units >> Signum._1_signumFloatTest avgt 5 3.769 ? 0.015 ns/op >> Signum._2_overheadFloat avgt 5 3.312 ? 0.025 ns/op >> Signum._3_signumDoubleTest avgt 5 3.765 ? 0.005 ns/op >> Signum._4_overheadDouble avgt 5 3.309 ? 0.010 ns/op >> >> >> Signed-off-by: Marcus G K Williams > > Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision: > > jatin-bhateja review > > Signed-off-by: Marcus G K Williams Marked as reviewed by jbhateja (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3581 From jbhateja at openjdk.java.net Thu Apr 29 09:07:56 2021 From: jbhateja at openjdk.java.net (Jatin Bhateja) Date: Thu, 29 Apr 2021 09:07:56 GMT Subject: RFR: 8265491: Math Signum optimization for x86 In-Reply-To: References: Message-ID: On Tue, 20 Apr 2021 08:38:14 GMT, Jatin Bhateja wrote: >> x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM. >> >> We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization. >> >> Base: >> >> Benchmark Mode Cnt Score Error Units >> Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op >> Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op >> Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op >> Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op >> >> >> Optimized: >> signum intrinsic patch >> >> Benchmark Mode Cnt Score Error Units >> Signum._1_signumFloatTest avgt 5 3.769 ? 0.015 ns/op >> Signum._2_overheadFloat avgt 5 3.312 ? 0.025 ns/op >> Signum._3_signumDoubleTest avgt 5 3.765 ? 0.005 ns/op >> Signum._4_overheadDouble avgt 5 3.309 ? 0.010 ns/op >> >> >> Signed-off-by: Marcus G K Williams > > @mgkwill, your newly added benchmark has 4 micro worklets, please publish the results for all of them. > Thanks for your review @jatin-bhateja. I've implemented your suggested changes. Thanks Marcus! ------------- PR: https://git.openjdk.java.net/jdk/pull/3581 From jiefu at openjdk.java.net Thu Apr 29 09:22:52 2021 From: jiefu at openjdk.java.net (Jie Fu) Date: Thu, 29 Apr 2021 09:22:52 GMT Subject: RFR: 8265491: Math Signum optimization for x86 [v12] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 19:26:21 GMT, Marcus G K Williams wrote: >> x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM. >> >> We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization. >> >> Base: >> >> Benchmark Mode Cnt Score Error Units >> Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op >> Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op >> Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op >> Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op >> >> >> Optimized: >> signum intrinsic patch >> >> Benchmark Mode Cnt Score Error Units >> Signum._1_signumFloatTest avgt 5 3.769 ? 0.015 ns/op >> Signum._2_overheadFloat avgt 5 3.312 ? 0.025 ns/op >> Signum._3_signumDoubleTest avgt 5 3.765 ? 0.005 ns/op >> Signum._4_overheadDouble avgt 5 3.309 ? 0.010 ns/op >> >> >> Signed-off-by: Marcus G K Williams > > Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision: > > jatin-bhateja review > > Signed-off-by: Marcus G K Williams Marked as reviewed by jiefu (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3581 From dfuchs at openjdk.java.net Thu Apr 29 09:33:58 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 29 Apr 2021 09:33:58 GMT Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex [v4] In-Reply-To: References: Message-ID: On Thu, 29 Apr 2021 02:53:18 GMT, Yi Yang wrote: >> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version. >> >> In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot. >> >> But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later: >> >> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase. >> 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag >> >> Testing: cds, compiler and jdk > > Yi Yang has updated the pull request incrementally with one additional commit since the last revision: > > remove extra newline test/hotspot/jtreg/compiler/c1/TestCheckIndexC1Intrinsic.java line 60: > 58: } catch (IndexOutOfBoundsException e) { > 59: // got it! > 60: } In all places where `Precondition.checkIndex` is expected to throw, an AssertionError should be generated if it doesn't throw: try { Preconditions.checkIndex(1, 1, null); throw new AssertionError("Expected IndexOutOfBoundsException not thrown"); } catch (IndexOutOfBoundsException e) { // got it! } ------------- PR: https://git.openjdk.java.net/jdk/pull/3615 From yyang at openjdk.java.net Thu Apr 29 10:01:52 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Thu, 29 Apr 2021 10:01:52 GMT Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex [v4] In-Reply-To: References: Message-ID: On Thu, 29 Apr 2021 09:30:50 GMT, Daniel Fuchs wrote: >> Yi Yang has updated the pull request incrementally with one additional commit since the last revision: >> >> remove extra newline > > test/hotspot/jtreg/compiler/c1/TestCheckIndexC1Intrinsic.java line 60: > >> 58: } catch (IndexOutOfBoundsException e) { >> 59: // got it! >> 60: } > > In all places where `Precondition.checkIndex` is expected to throw, an AssertionError should be generated if it doesn't throw: > > > try { > Preconditions.checkIndex(1, 1, null); > throw new AssertionError("Expected IndexOutOfBoundsException not thrown"); > } catch (IndexOutOfBoundsException e) { > // got it! > } Yes, it does make sense ------------- PR: https://git.openjdk.java.net/jdk/pull/3615 From dfuchs at openjdk.java.net Thu Apr 29 10:16:20 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Thu, 29 Apr 2021 10:16:20 GMT Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex [v5] In-Reply-To: References: Message-ID: On Thu, 29 Apr 2021 10:13:16 GMT, Yi Yang wrote: >> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version. >> >> In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot. >> >> But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later: >> >> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase. >> 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag >> >> Testing: cds, compiler and jdk > > Yi Yang has updated the pull request incrementally with one additional commit since the last revision: > > AssertionError when expected exception was not thrown test/hotspot/jtreg/compiler/c1/TestCheckIndexC1Intrinsic.java line 86: > 84: // read fields > 85: Preconditions.checkIndex(limit + 1, limit, (s, integers) -> new MyException("Reason:" + s + "::" + integers)); > 86: throw new AssertionError("Expected IndexOutOfBoundsException not thrown"); nit: well maybe here it should be: throw new AssertionError("Expected MyException not thrown"); test/hotspot/jtreg/compiler/c1/TestCheckIndexC1Intrinsic.java line 94: > 92: static void check1(int i) { > 93: try { > 94: Preconditions.checkIndex(i, 9999, (s, integers) -> new RuntimeException("ex")); I believe throw new AssertionError("Expected IndexOutOfBoundsException not thrown"); should be added in `check1`...`check4` as well... ------------- PR: https://git.openjdk.java.net/jdk/pull/3615 From yyang at openjdk.java.net Thu Apr 29 10:16:19 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Thu, 29 Apr 2021 10:16:19 GMT Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex [v5] In-Reply-To: References: Message-ID: > The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version. > > In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot. > > But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later: > > 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase. > 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag > > Testing: cds, compiler and jdk Yi Yang has updated the pull request incrementally with one additional commit since the last revision: AssertionError when expected exception was not thrown ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3615/files - new: https://git.openjdk.java.net/jdk/pull/3615/files/bbdf4b9e..1a96be7e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=03-04 Stats: 8 lines in 1 file changed: 5 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3615.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3615/head:pull/3615 PR: https://git.openjdk.java.net/jdk/pull/3615 From mcimadamore at openjdk.java.net Thu Apr 29 10:34:53 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 29 Apr 2021 10:34:53 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v3] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 23:22:38 GMT, Mandy Chung wrote: > My statement was overly simplified, sorry. If `handle` is invoked in another module B and invoked by a class in module B, which module (the `lookup`'s module or ) do you expect be the caller to check against for native access check? `CLinker::downcallHandle` is not caller-sensitive but its implementation is. > > The method handle of a caller-sensitive method behaves as if it were called from an instruction contained in the lookup class [1]. I think I expect that, with caller sensitive, it is possible from a client in an "enabled" module to obtain a MethodHandle, and then pass it to an unprivileged module, which then calls it, and works ok. This matches my expectation (this trick could be used also to give a client access to an otherwise inaccessible - in the classic sense - method). So, when working with method handles, I'm completely fine working with the lookup class as context (and not with the real caller class). Given all this, do you agree that current checks are not affected by interface-ness of some of the methods involved? ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From yyang at openjdk.java.net Thu Apr 29 10:40:52 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Thu, 29 Apr 2021 10:40:52 GMT Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex [v5] In-Reply-To: References: Message-ID: <8qnpaKEeGr3iGKtcGK8l5YjtxP_Y3cdmwbbDVvr-Y7Y=.d0a0cc48-3027-4b15-982b-88b18c4d0830@github.com> On Thu, 29 Apr 2021 10:13:05 GMT, Daniel Fuchs wrote: >> Yi Yang has updated the pull request incrementally with one additional commit since the last revision: >> >> AssertionError when expected exception was not thrown > > test/hotspot/jtreg/compiler/c1/TestCheckIndexC1Intrinsic.java line 94: > >> 92: static void check1(int i) { >> 93: try { >> 94: Preconditions.checkIndex(i, 9999, (s, integers) -> new RuntimeException("ex")); > > I believe > > throw new AssertionError("Expected IndexOutOfBoundsException not thrown"); > > > should be added in `check1`...`check4` as well... Hmm.. They would throw desired exceptions only if i==9999. ------------- PR: https://git.openjdk.java.net/jdk/pull/3615 From mcimadamore at openjdk.java.net Thu Apr 29 11:15:00 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 29 Apr 2021 11:15:00 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v4] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/412 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: Address review comments: * Fix all link vs. linkplain * Remove `volatile` and other defensive copying in `IllegalNativeAccessChecker` * Added @throws clauses in restricted methods for `IllegalCallerException` ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3699/files - new: https://git.openjdk.java.net/jdk/pull/3699/files/24e554c5..20671853 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=02-03 Stats: 102 lines in 8 files changed: 57 ins; 0 del; 45 mod Patch: https://git.openjdk.java.net/jdk/pull/3699.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699 PR: https://git.openjdk.java.net/jdk/pull/3699 From mcimadamore at openjdk.java.net Thu Apr 29 11:15:32 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 29 Apr 2021 11:15:32 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v3] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 18:33:36 GMT, Maurizio Cimadamore wrote: >> This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. >> >> [1] - https://openjdk.java.net/jeps/412 > > Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments: > * fix typos in javadoc > * document ISE being thrown in all methods accepting a scope; add more tests for that Here's a new round of javadoc/specdiff with latest changes Javadoc: http://cr.openjdk.java.net/~mcimadamore/JEP-412/v2/javadoc/jdk/incubator/foreign/package-summary.html Specdiff: http://cr.openjdk.java.net/~mcimadamore/JEP-412/v2/specdiff/overview-summary.html ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From vlivanov at openjdk.java.net Thu Apr 29 12:01:14 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Thu, 29 Apr 2021 12:01:14 GMT Subject: RFR: 8266074: Vtable-based CHA implementation Message-ID: As of now, Class Hierarchy Analysis (CHA) employs an approximate algorithm to enumerate all non-abstract methods in a class hierarchy. It served quite well for many years, but it accumulated significant complexity to support different corner cases over time and inevitable evolution of the JVM stretched the whole approach way too much (to the point where it become almost impossible to extend the analysis any further). It turns out the root problem is the decision to reimplement method resolution and method selection logic from scratch and to perform it on JVM internal representation. It makes it very hard to reason about correctness and the implementation becomes sensitive to changes in internal representation. So, the main motivation for the redesign is twofold: * reduce maintenance burden and increase confidence in the code; * unlock some long-awaited enhancements. Though I did experiment with relaxing existing constraints (e.g., enable default method support), any possible enhancements are deliberately kept out of scope for the current PR. (It does deliver a bit of minor enhancements front as the changes in compiler/cha/StrengthReduceInterfaceCall.java manifest, but it's a side effect of the other changes and was not the goal of the current work.) Proposed implementation (`LinkedConcreteMethodFinder`) mimics method invocation and relies on vtable/itable information to detect target method for every subclass it visits. It removes all the complexity associated with method resolution and method selection logic and leaves only essential logic to prepare for method selection. Vtables are filled during class linkage, so new logic doesn't work on not yet linked classed. Instead of supporting not yet linked case, it is simply ignored. It is safe to skip them (treat as "effectively non-concrete") since it is guaranteed there are no instances created yet. But it requires VM to check dependencies once a class is linked. I ended up with 2 separate dependency validation passes (when class is loaded and when it is linked). To avoid duplicated work, only dependencies which may be affected by class initialization state change (`unique_concrete_method_4`) are visited. (I experimented with merging passes into a single pass (delay the pass until linkage is over), but it severely affected other class-related dependencies and relevant optimizations.code.) Compiler Interface (CI) is changed to require users to provide complete information about the call site being analyzed. Old implementation is kept intact for now (will be removed later) to: - JVMCI hasn't been migrated to the new implementation yet; - enable verification that 2 implementations (old and new) agree on the results; - temporarily keep an option to revert to the original implementation in case any regressions show up. Testing: - [x] hs-tier1 - hs-tier9 - [x] hs-tier1 - hs-tier4 w/ `-XX:-UseVtableBasedCHA` - [x] performance testing Thanks! ------------- Commit messages: - Introduce NewKlassDepChange and KlassInitDepChange - LinkedConcreteMethodFinder - Dependencies::assert_unique_concrete_method - 4-arg dependency support: Dependencies::assert_common_4 et al Changes: https://git.openjdk.java.net/jdk/pull/3727/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3727&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266074 Stats: 542 lines in 11 files changed: 468 ins; 6 del; 68 mod Patch: https://git.openjdk.java.net/jdk/pull/3727.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3727/head:pull/3727 PR: https://git.openjdk.java.net/jdk/pull/3727 From mcimadamore at openjdk.java.net Thu Apr 29 12:22:41 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Thu, 29 Apr 2021 12:22:41 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v5] In-Reply-To: References: Message-ID: <02OtcjUL7EtDhrlea772aQceCYVBpl3uMAWuwkgK6p0=.46f81497-dcc1-4ab2-b60a-84ee417f1301@github.com> > This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/412 Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision: - Merge branch 'master' into JEP-412 - Address review comments: * Fix all link vs. linkplain * Remove `volatile` and other defensive copying in `IllegalNativeAccessChecker` * Added @throws clauses in restricted methods for `IllegalCallerException` - Address review comments: * fix typos in javadoc * document ISE being thrown in all methods accepting a scope; add more tests for that - Address first batch of review comments - Add linker test excludes for x86 and other platforms which do not support `CLinker` - Integrate latest API tweaks - Fix x86 build - Fix `TestLinkToNativeRBP` - Initial push ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3699/files - new: https://git.openjdk.java.net/jdk/pull/3699/files/20671853..f27db3f3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=03-04 Stats: 477828 lines in 3664 files changed: 4983 ins; 470775 del; 2070 mod Patch: https://git.openjdk.java.net/jdk/pull/3699.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699 PR: https://git.openjdk.java.net/jdk/pull/3699 From ysuenaga at openjdk.java.net Thu Apr 29 13:10:14 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 29 Apr 2021 13:10:14 GMT Subject: RFR: 8266172: -Wstringop-overflow happens in vmError.cpp Message-ID: <88rBsBX8phrAbHXhElCDWK0GxIlB0IrtPCd58cJSHGU=.a3f74351-9550-48b6-916d-a40c3c29ce32@github.com> We can see following compiler warnings in vmError.cpp on GCC 11. In function 'void crash_with_segfault()', inlined from 'static void VMError::controlled_crash(int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/utilities/vmError.cpp:1804:33: ------------- Commit messages: - 8266172: -Wstringop-overflow happens in vmError.cpp Changes: https://git.openjdk.java.net/jdk/pull/3789/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3789&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266172 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3789.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3789/head:pull/3789 PR: https://git.openjdk.java.net/jdk/pull/3789 From dholmes at openjdk.java.net Thu Apr 29 14:17:52 2021 From: dholmes at openjdk.java.net (David Holmes) Date: Thu, 29 Apr 2021 14:17:52 GMT Subject: RFR: 8266172: -Wstringop-overflow happens in vmError.cpp In-Reply-To: <88rBsBX8phrAbHXhElCDWK0GxIlB0IrtPCd58cJSHGU=.a3f74351-9550-48b6-916d-a40c3c29ce32@github.com> References: <88rBsBX8phrAbHXhElCDWK0GxIlB0IrtPCd58cJSHGU=.a3f74351-9550-48b6-916d-a40c3c29ce32@github.com> Message-ID: <8EOj5sOURxIlG7dFMknJo_jnlkRYqLjOvd3CNrYiFto=.56066b92-4417-470e-bed0-ef101a0606f9@github.com> On Thu, 29 Apr 2021 07:26:05 GMT, Yasumasa Suenaga wrote: > We can see following compiler warnings in vmError.cpp on GCC 11. > > > In function 'void crash_with_segfault()', > inlined from 'static void VMError::controlled_crash(int)' at /home/ysuenaga/github-forked/jdk/src/hotspot/share/utilities/vmError.cpp:1804:33: I'm not sure whether to disable the warning via pragma, as this is a bogus warning, or whether to side-step by changing to int* as you have. As long as we still crash "correctly" I suppose this is okay. Thanks, David ------------- Marked as reviewed by dholmes (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3789 From redestad at openjdk.java.net Thu Apr 29 16:15:09 2021 From: redestad at openjdk.java.net (Claes Redestad) Date: Thu, 29 Apr 2021 16:15:09 GMT Subject: RFR: 8266252: Streamline AbstractInterpreter::method_kind Message-ID: This patch refactors AbstractInterpreter::method_kind to reduce branches on average while better compartmentalizing the exceptional cases. Additionally Method::is_empty_method is trivial enough that making it inlineable helps reduce cost while reducing size of the libjvm. Result is a 40% speed-up, or a reduction of .25% of instructions on Hello World that scales to larger applications. ------------- Commit messages: - Improve comment - Select native as the kind for StrictMath::sqrt - Streamline AbstractInterpreter::method_kind Changes: https://git.openjdk.java.net/jdk/pull/3798/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3798&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266252 Stats: 89 lines in 3 files changed: 28 ins; 37 del; 24 mod Patch: https://git.openjdk.java.net/jdk/pull/3798.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3798/head:pull/3798 PR: https://git.openjdk.java.net/jdk/pull/3798 From sviswanathan at openjdk.java.net Thu Apr 29 17:18:54 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Thu, 29 Apr 2021 17:18:54 GMT Subject: RFR: 8265491: Math Signum optimization for x86 [v12] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 19:26:21 GMT, Marcus G K Williams wrote: >> x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM. >> >> We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization. >> >> Base: >> >> Benchmark Mode Cnt Score Error Units >> Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op >> Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op >> Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op >> Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op >> >> >> Optimized: >> signum intrinsic patch >> >> Benchmark Mode Cnt Score Error Units >> Signum._1_signumFloatTest avgt 5 3.769 ? 0.015 ns/op >> Signum._2_overheadFloat avgt 5 3.312 ? 0.025 ns/op >> Signum._3_signumDoubleTest avgt 5 3.765 ? 0.005 ns/op >> Signum._4_overheadDouble avgt 5 3.309 ? 0.010 ns/op >> >> >> Signed-off-by: Marcus G K Williams > > Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision: > > jatin-bhateja review > > Signed-off-by: Marcus G K Williams @vnkozlov @neliasso Could you please help review this small patch from Marcus. ------------- PR: https://git.openjdk.java.net/jdk/pull/3581 From mchung at openjdk.java.net Thu Apr 29 18:20:53 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Thu, 29 Apr 2021 18:20:53 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v3] In-Reply-To: References: Message-ID: On Thu, 29 Apr 2021 10:31:29 GMT, Maurizio Cimadamore wrote: > I think I expect that, with caller sensitive, it is possible from a client in an "enabled" module to obtain a MethodHandle, and then pass it to an unprivileged module, which then calls it, and works ok. This matches my expectation (this trick could be used also to give a client access to an otherwise inaccessible - in the classic sense - method). > > So, when working with method handles, I'm completely fine working with the lookup class as context (and not with the real caller class). Good, this matches the behavior of method handles for CSMs. However, I think the implementation does the opposite since we don't support interface method being CSM. Can you test that out? > Given all this, do you agree that current checks are not affected by interface-ness of some of the methods involved? I think the implementation does not support that. I will also need to look into how this impacts JDK-8266010. As I suggest earlier, I'm fine to do this as a follow up after integration. ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From neliasso at openjdk.java.net Thu Apr 29 18:23:53 2021 From: neliasso at openjdk.java.net (Nils Eliasson) Date: Thu, 29 Apr 2021 18:23:53 GMT Subject: RFR: 8265491: Math Signum optimization for x86 [v12] In-Reply-To: References: Message-ID: <_VXARuqmXZCTBAD-R0vOMp0_Q2kTi5cLEtbtWqqar_U=.41a4ad63-1316-478c-b03a-286595c6d837@github.com> On Wed, 28 Apr 2021 19:26:21 GMT, Marcus G K Williams wrote: >> x86 Math.Signum() uses two floating point compares and a copy sign operation involving data movement to gpr and XMM. >> >> We can optimize to one floating point compare and sign computation in XMM. We observe ~25% performance improvement with this optimization. >> >> Base: >> >> Benchmark Mode Cnt Score Error Units >> Signum._1_signumFloatTest avgt 5 4.660 ? 0.040 ns/op >> Signum._2_overheadFloat avgt 5 3.314 ? 0.023 ns/op >> Signum._3_signumDoubleTest avgt 5 4.809 ? 0.043 ns/op >> Signum._4_overheadDouble avgt 5 3.313 ? 0.015 ns/op >> >> >> Optimized: >> signum intrinsic patch >> >> Benchmark Mode Cnt Score Error Units >> Signum._1_signumFloatTest avgt 5 3.769 ? 0.015 ns/op >> Signum._2_overheadFloat avgt 5 3.312 ? 0.025 ns/op >> Signum._3_signumDoubleTest avgt 5 3.765 ? 0.005 ns/op >> Signum._4_overheadDouble avgt 5 3.309 ? 0.010 ns/op >> >> >> Signed-off-by: Marcus G K Williams > > Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision: > > jatin-bhateja review > > Signed-off-by: Marcus G K Williams Looks good! ------------- Marked as reviewed by neliasso (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3581 From sviswanathan at openjdk.java.net Thu Apr 29 18:30:00 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Thu, 29 Apr 2021 18:30:00 GMT Subject: RFR: 8265491: Math Signum optimization for x86 [v12] In-Reply-To: <_VXARuqmXZCTBAD-R0vOMp0_Q2kTi5cLEtbtWqqar_U=.41a4ad63-1316-478c-b03a-286595c6d837@github.com> References: <_VXARuqmXZCTBAD-R0vOMp0_Q2kTi5cLEtbtWqqar_U=.41a4ad63-1316-478c-b03a-286595c6d837@github.com> Message-ID: On Thu, 29 Apr 2021 18:21:12 GMT, Nils Eliasson wrote: >> Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision: >> >> jatin-bhateja review >> >> Signed-off-by: Marcus G K Williams > > Looks good! @neliasso Thanks a lot for the review. ------------- PR: https://git.openjdk.java.net/jdk/pull/3581 From sjohanss at openjdk.java.net Thu Apr 29 19:52:52 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Thu, 29 Apr 2021 19:52:52 GMT Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux [v15] In-Reply-To: References: Message-ID: On Sat, 13 Mar 2021 07:25:12 GMT, Thomas Stuefe wrote: >> src/hotspot/os/linux/os_linux.cpp line 4046: >> >>> 4044: // Select large_page_size from _page_sizes >>> 4045: // that is smaller than size_t bytes >>> 4046: size_t large_page_size = os::page_size_for_region_aligned(bytes, 1); >> >> This one also needs to use `os::page_size_for_region_unaligned(...)` since we know we have a size that needs both small and large pages. > > +1 to what stefan wrote My comment here is a bit outdated. Now this function is used for both the "mixed" and the "only" case. As I see it we have to possibilities here. Either we stall this change a bit longer and let me finish the `ReservedSpace` work I've been doing lately. I have a patch coming out tonight or tomorrow that will add a page size member to `ReservedSpace`. I could then make a change to the `reserve_memory_special` API to pass a page size along with the other parameters and then this change will only be about enabling multiple page sizes. Everything else should just work. Alternatively we have to come up with some helper that decide the page size given the current alignment and size. ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From sjohanss at openjdk.java.net Thu Apr 29 19:55:54 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Thu, 29 Apr 2021 19:55:54 GMT Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux [v30] In-Reply-To: References: Message-ID: <2Jj6MiFwxq9a3sNZl5fQPuzk6rgYf_fXJ6ztmXbY61g=.432eb729-e52d-4c7a-9e47-7f9a44fcaedb@github.com> On Wed, 28 Apr 2021 18:36:53 GMT, Marcus G K Williams wrote: >> Change the meaning of LargePageSizeInBytes to be the maximum large page size the JVM may use (not the only one). A default value of zero will mean to allow the JVM use large page sizes up to the system's default large page size. > > Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision: > > kstefanj review > > Signed-off-by: Marcus G K Williams src/hotspot/share/runtime/os.cpp line 1483: > 1481: for (size_t page_size = page_sizes().largest(); page_size != 0; > 1482: page_size = page_sizes().next_smaller(page_size)) { > 1483: if (page_size <= max_page_size && page_size > (size_t)vm_page_size()) { Is this really needed? ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From sjohanss at openjdk.java.net Thu Apr 29 20:55:29 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Thu, 29 Apr 2021 20:55:29 GMT Subject: RFR: 8261527: Record page size used for underlying mapping in ReservedSpace Message-ID: Please review this change to use the actual page size rather than `bool large` when creating and initializing `ReservedSpace`. This allows us to then get rid of the helper `ReservedSpace::actual_reserved_page_size()` and instead use the "real" page size for logging and other use. The PR consist of two commits, one that changes `ReservedSpace` to use and store a page size and one that removes `actual_reserved_page_size()` and instead uses `ReservedSpace::page_size()`. Hopefully this might help ease the review a bit. There are two changes in behavior: * In `JfrVirtualMemorySegment::initialize()` we now always pass down `os::vm_page_size()` which means never use large pages. This differs from the old condition where large pages were enabled if transparent huge pages were enabled. This change has been discussed with the JFR team and they will later investigate how to re-enable large page use. * In `ReservedSpace::reserve()`, if a file is used, the page size is always set to `os::vm_page_size()`. So when logging the page_size for such mapping it will not report a large page size. This was incorrectly done in the past when using `ReservedSpace::actual_reserved_page_size()` to figure out the page size. This makes the `runtime/os/TestTracePageSizes.java` test pass even if run with `-XX:AllocateHeapAt=/tmp`. **Testing** Mach5 tier1-4 and a lot of local testing. ------------- Commit messages: - Use ReservedSpace.page_size() instead of actual_reserved_page_size() - 8261527: Record page size used for underlying mapping in ReservedSpace Changes: https://git.openjdk.java.net/jdk/pull/3802/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3802&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261527 Stats: 135 lines in 20 files changed: 18 ins; 26 del; 91 mod Patch: https://git.openjdk.java.net/jdk/pull/3802.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3802/head:pull/3802 PR: https://git.openjdk.java.net/jdk/pull/3802 From minqi at openjdk.java.net Thu Apr 29 22:30:40 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 29 Apr 2021 22:30:40 GMT Subject: RFR: 8255493: Support for pre-generated java.lang.invoke classes in CDS dynamic archive [v11] In-Reply-To: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> References: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> Message-ID: > Hi, Please review > > When do dynamic dump, the pre-generated lambda form classes from java.lang.invoke are not stored in dynamic archive. The patch will regenerate the four holder classes, > "java.lang.invoke.Invokers$Holder", > "java.lang.invoke.DirectMethodHandle$Holder", > "java.lang.invoke.DelegatingMethodHandle$Holder", > "java.lang.invoke.LambdaForm$Holder" > which will include the versions in static archive and new loaded functions all together and stored in dynamic archive. New test case added. > (Minor change to PrintSharedArchiveAtExit, which the index is not consecutive) > > Tests: tier1,tier2,tier3,tier4 > > Thanks > Yumin Yumin Qi has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision: - Changed DynamicArchive::dump as static counterpart. Suppressed exceptions in LambdaFormInvokers::regenerate_holder_classes except for oom - Merge branch 'master' into jdk-8255493 - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8255493 - Only store four lambda invoker (which will be regenerated in dynamic dump) lines in static archive - Removed TRAP from regenerate_holder_classes, also correct SharedLambdaDictionaryPrinter index - Merge branch 'master' into jdk-8255493 - Restore filemap.[ch]pp - Remove unnecessary file header including - Removed unused function static_archive_invokers(), add back accidentally deleted empty line - Changed DEBUG_ONLY to log_debug, make small changes for format, added bug tag to test - ... and 6 more: https://git.openjdk.java.net/jdk/compare/ca9b4f7b...0846f121 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3611/files - new: https://git.openjdk.java.net/jdk/pull/3611/files/05a7ca93..0846f121 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3611&range=10 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3611&range=09-10 Stats: 2388 lines in 80 files changed: 1802 ins; 389 del; 197 mod Patch: https://git.openjdk.java.net/jdk/pull/3611.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3611/head:pull/3611 PR: https://git.openjdk.java.net/jdk/pull/3611 From minqi at openjdk.java.net Thu Apr 29 22:44:04 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Thu, 29 Apr 2021 22:44:04 GMT Subject: RFR: 8255493: Support for pre-generated java.lang.invoke classes in CDS dynamic archive [v11] In-Reply-To: References: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> Message-ID: On Thu, 29 Apr 2021 22:30:40 GMT, Yumin Qi wrote: >> Hi, Please review >> >> When do dynamic dump, the pre-generated lambda form classes from java.lang.invoke are not stored in dynamic archive. The patch will regenerate the four holder classes, >> "java.lang.invoke.Invokers$Holder", >> "java.lang.invoke.DirectMethodHandle$Holder", >> "java.lang.invoke.DelegatingMethodHandle$Holder", >> "java.lang.invoke.LambdaForm$Holder" >> which will include the versions in static archive and new loaded functions all together and stored in dynamic archive. New test case added. >> (Minor change to PrintSharedArchiveAtExit, which the index is not consecutive) >> >> Tests: tier1,tier2,tier3,tier4 >> >> Thanks >> Yumin > > Yumin Qi has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision: > > - Changed DynamicArchive::dump as static counterpart. Suppressed exceptions in LambdaFormInvokers::regenerate_holder_classes except for oom > - Merge branch 'master' into jdk-8255493 > - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8255493 > - Only store four lambda invoker (which will be regenerated in dynamic dump) lines in static archive > - Removed TRAP from regenerate_holder_classes, also correct SharedLambdaDictionaryPrinter index > - Merge branch 'master' into jdk-8255493 > - Restore filemap.[ch]pp > - Remove unnecessary file header including > - Removed unused function static_archive_invokers(), add back accidentally deleted empty line > - Changed DEBUG_ONLY to log_debug, make small changes for format, added bug tag to test > - ... and 6 more: https://git.openjdk.java.net/jdk/compare/248598ed...0846f121 The recent version change made DynamicArchive::dump take TRAPS, same as static dump. The design of LambdaFormInvokers::regenerate_holder_classes is that if the regeneration failed, it won't affect normal classes archived. So we have tests for wrong tag or line format in classlist to make sure dump archive. I changed to handle all exceptions except for OOM (which will be processed by caller if possible for the extreme case) in the function. ------------- PR: https://git.openjdk.java.net/jdk/pull/3611 From github.com+58006833+xbzhang99 at openjdk.java.net Thu Apr 29 23:54:02 2021 From: github.com+58006833+xbzhang99 at openjdk.java.net (Xubo Zhang) Date: Thu, 29 Apr 2021 23:54:02 GMT Subject: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms Message-ID: 8266332: Adler32 intrinsic for x86 64-bit platforms ------------- Commit messages: - Fixed issues raised by Sandhya - create stub code for Adler32 -- initial version Changes: https://git.openjdk.java.net/jdk/pull/3806/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3806&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266332 Stats: 287 lines in 11 files changed: 281 ins; 5 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3806.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3806/head:pull/3806 PR: https://git.openjdk.java.net/jdk/pull/3806 From iklam at openjdk.java.net Thu Apr 29 23:55:10 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Thu, 29 Apr 2021 23:55:10 GMT Subject: RFR: 8255493: Support for pre-generated java.lang.invoke classes in CDS dynamic archive [v11] In-Reply-To: References: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> Message-ID: On Thu, 29 Apr 2021 22:30:40 GMT, Yumin Qi wrote: >> Hi, Please review >> >> When do dynamic dump, the pre-generated lambda form classes from java.lang.invoke are not stored in dynamic archive. The patch will regenerate the four holder classes, >> "java.lang.invoke.Invokers$Holder", >> "java.lang.invoke.DirectMethodHandle$Holder", >> "java.lang.invoke.DelegatingMethodHandle$Holder", >> "java.lang.invoke.LambdaForm$Holder" >> which will include the versions in static archive and new loaded functions all together and stored in dynamic archive. New test case added. >> (Minor change to PrintSharedArchiveAtExit, which the index is not consecutive) >> >> Tests: tier1,tier2,tier3,tier4 >> >> Thanks >> Yumin > > Yumin Qi has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision: > > - Changed DynamicArchive::dump as static counterpart. Suppressed exceptions in LambdaFormInvokers::regenerate_holder_classes except for oom > - Merge branch 'master' into jdk-8255493 > - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8255493 > - Only store four lambda invoker (which will be regenerated in dynamic dump) lines in static archive > - Removed TRAP from regenerate_holder_classes, also correct SharedLambdaDictionaryPrinter index > - Merge branch 'master' into jdk-8255493 > - Restore filemap.[ch]pp > - Remove unnecessary file header including > - Removed unused function static_archive_invokers(), add back accidentally deleted empty line > - Changed DEBUG_ONLY to log_debug, make small changes for format, added bug tag to test > - ... and 6 more: https://git.openjdk.java.net/jdk/compare/65d4ba4a...0846f121 Changes requested by iklam (Reviewer). src/hotspot/share/cds/lambdaFormInvokers.cpp line 84: > 82: #define HANDLE_IF_HAS_EXCEPTION \ > 83: if (HAS_PENDING_EXCEPTION) { \ > 84: if (!PENDING_EXCEPTION->is_a(vmClasses::OutOfMemoryError_klass())) { \ I would suggest adding a comment and error message to explain why we ignore the error: // We may get an exception if the classlist contains an error (or an outdated entry generated by // an older JDK). if (DumpSharedArchive) { log_error(cds)("Failed to generate LambdaForm holder classes. Is your classlist out of date?"); } else { log_error(cds)("Failed to generate LambdaForm holder classes. Was the base archive generated with an outdated classlist?"); } src/hotspot/share/cds/lambdaFormInvokers.cpp line 123: > 121: JavaCalls::call_static(&result, cds_klass, method, signrs, list_lines, THREAD); > 122: > 123: HANDLE_IF_HAS_EXCEPTION; Instead of using a macro, I think the code can be more readable like this: if (check_exception(THREAD)) { return; } and `check_exception` can contain the logic of `HANDLE_IF_HAS_EXCEPTION`. src/hotspot/share/cds/lambdaFormInvokers.cpp line 141: > 139: ClassFileStream st((u1*)buf, len, NULL, ClassFileStream::verify); > 140: reload_class(class_name, st, THREAD); > 141: HANDLE_IF_HAS_EXCEPTION; Is this necessary? I think bad classlists will cause errors in the JavaCalls::call_static call above, but not here. ------------- PR: https://git.openjdk.java.net/jdk/pull/3611 From github.com+58006833+xbzhang99 at openjdk.java.net Thu Apr 29 23:57:00 2021 From: github.com+58006833+xbzhang99 at openjdk.java.net (Xubo Zhang) Date: Thu, 29 Apr 2021 23:57:00 GMT Subject: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms In-Reply-To: References: Message-ID: On Thu, 29 Apr 2021 23:47:17 GMT, Xubo Zhang wrote: > 8266332: Adler32 intrinsic for x86 64-bit platforms Currently, only 64-bit Linux is supported ------------- PR: https://git.openjdk.java.net/jdk/pull/3806 From sviswanathan at openjdk.java.net Fri Apr 30 00:24:56 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Fri, 30 Apr 2021 00:24:56 GMT Subject: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms In-Reply-To: References: Message-ID: On Thu, 29 Apr 2021 23:47:17 GMT, Xubo Zhang wrote: > Implement Adler32 intrinsic for x86 64-bit platform using vector instructions. > > For the following benchmark: > http://cr.openjdk.java.net/~pli/rfr/8216259/TestAdler32.java > > The optimization shows ~5x improvement. > > Base: > Benchmark (count) Mode Cnt Score Error Units > TestAdler32Perf.testAdler32Update 64 avgt 25 0.084 ? 0.001 us/op > TestAdler32Perf.testAdler32Update 128 avgt 25 0.104 ? 0.001 us/op > TestAdler32Perf.testAdler32Update 256 avgt 25 0.146 ? 0.002 us/op > TestAdler32Perf.testAdler32Update 512 avgt 25 0.226 ? 0.002 us/op > TestAdler32Perf.testAdler32Update 1024 avgt 25 0.390 ? 0.005 us/op > TestAdler32Perf.testAdler32Update 2048 avgt 25 0.714 ? 0.007 us/op > TestAdler32Perf.testAdler32Update 4096 avgt 25 1.359 ? 0.014 us/op > TestAdler32Perf.testAdler32Update 8192 avgt 25 2.751 ? 0.023 us/op > TestAdler32Perf.testAdler32Update 16384 avgt 25 5.494 ? 0.077 us/op > TestAdler32Perf.testAdler32Update 32768 avgt 25 11.058 ? 0.160 us/op > TestAdler32Perf.testAdler32Update 65536 avgt 25 22.198 ? 0.319 us/op > > > With patch: > Benchmark (count) Mode Cnt Score Error Units > TestAdler32Perf.testAdler32Update 64 avgt 25 0.020 ? 0.001 us/op > TestAdler32Perf.testAdler32Update 128 avgt 25 0.025 ? 0.001 us/op > TestAdler32Perf.testAdler32Update 256 avgt 25 0.031 ? 0.001 us/op > TestAdler32Perf.testAdler32Update 512 avgt 25 0.048 ? 0.001 us/op > TestAdler32Perf.testAdler32Update 1024 avgt 25 0.078 ? 0.001 us/op > TestAdler32Perf.testAdler32Update 2048 avgt 25 0.139 ? 0.002 us/op > TestAdler32Perf.testAdler32Update 4096 avgt 25 0.262 ? 0.004 us/op > TestAdler32Perf.testAdler32Update 8192 avgt 25 0.524 ? 0.010 us/op > TestAdler32Perf.testAdler32Update 16384 avgt 25 1.017 ? 0.022 us/op > TestAdler32Perf.testAdler32Update 32768 avgt 25 2.058 ? 0.052 us/op > TestAdler32Perf.testAdler32Update 65536 avgt 25 3.994 ? 0.013 us/op src/hotspot/cpu/x86/macroAssembler_x86.cpp line 3249: > 3247: void MacroAssembler::vpmulld(XMMRegister dst, XMMRegister nds, AddressLiteral src, int vector_len) { > 3248: // Used in sign-bit flipping with aligned address. > 3249: bool aligned_adr = (((intptr_t)src.target() & 15) == 0); This is an AVX instruction. So alignment is not required. The assert need to only check for UseAVX>0. src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 5812: > 5810: StubCodeMark mark(this, "StubRoutines", "updateBytesAdler32"); > 5811: > 5812: address start = __ pc(); The algorithm part can go into macroAssembler_x86_adler.cpp with Intel copyright (see macroAssembler_x86_sha.cpp). ------------- PR: https://git.openjdk.java.net/jdk/pull/3806 From sviswanathan at openjdk.java.net Fri Apr 30 00:44:01 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Fri, 30 Apr 2021 00:44:01 GMT Subject: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms In-Reply-To: References: Message-ID: On Thu, 29 Apr 2021 23:47:17 GMT, Xubo Zhang wrote: > Implement Adler32 intrinsic for x86 64-bit platform using vector instructions. > > For the following benchmark: > http://cr.openjdk.java.net/~pli/rfr/8216259/TestAdler32.java > > The optimization shows ~5x improvement. > > Base: > Benchmark (count) Mode Cnt Score Error Units > TestAdler32Perf.testAdler32Update 64 avgt 25 0.084 ? 0.001 us/op > TestAdler32Perf.testAdler32Update 128 avgt 25 0.104 ? 0.001 us/op > TestAdler32Perf.testAdler32Update 256 avgt 25 0.146 ? 0.002 us/op > TestAdler32Perf.testAdler32Update 512 avgt 25 0.226 ? 0.002 us/op > TestAdler32Perf.testAdler32Update 1024 avgt 25 0.390 ? 0.005 us/op > TestAdler32Perf.testAdler32Update 2048 avgt 25 0.714 ? 0.007 us/op > TestAdler32Perf.testAdler32Update 4096 avgt 25 1.359 ? 0.014 us/op > TestAdler32Perf.testAdler32Update 8192 avgt 25 2.751 ? 0.023 us/op > TestAdler32Perf.testAdler32Update 16384 avgt 25 5.494 ? 0.077 us/op > TestAdler32Perf.testAdler32Update 32768 avgt 25 11.058 ? 0.160 us/op > TestAdler32Perf.testAdler32Update 65536 avgt 25 22.198 ? 0.319 us/op > > > With patch: > Benchmark (count) Mode Cnt Score Error Units > TestAdler32Perf.testAdler32Update 64 avgt 25 0.020 ? 0.001 us/op > TestAdler32Perf.testAdler32Update 128 avgt 25 0.025 ? 0.001 us/op > TestAdler32Perf.testAdler32Update 256 avgt 25 0.031 ? 0.001 us/op > TestAdler32Perf.testAdler32Update 512 avgt 25 0.048 ? 0.001 us/op > TestAdler32Perf.testAdler32Update 1024 avgt 25 0.078 ? 0.001 us/op > TestAdler32Perf.testAdler32Update 2048 avgt 25 0.139 ? 0.002 us/op > TestAdler32Perf.testAdler32Update 4096 avgt 25 0.262 ? 0.004 us/op > TestAdler32Perf.testAdler32Update 8192 avgt 25 0.524 ? 0.010 us/op > TestAdler32Perf.testAdler32Update 16384 avgt 25 1.017 ? 0.022 us/op > TestAdler32Perf.testAdler32Update 32768 avgt 25 2.058 ? 0.052 us/op > TestAdler32Perf.testAdler32Update 65536 avgt 25 3.994 ? 0.013 us/op src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 5870: > 5868: __ cmovl(Assembler::above, s, size); // s = min(size, LIMIT) > 5869: __ lea(end, Address(s, data, Address::times_1, -CHUNKSIZE_M1)); > 5870: __ cmpq(data, end); This should be cmpptr here. src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 5895: > 5893: // reduce > 5894: __ vpslld(yb, yb, 3, Assembler::AVX_256bit); //b is scaled by 8 > 5895: __ vpmulld(ysa, ya, ExternalAddress((address) StubRoutines::x86::_adler32_ascale_table), Assembler::AVX_256bit); //need scratch register?? All the instructions with ExternalAddress can modify rscratch1 which is r10. It is good to pass an explicit scratch register to these as last argument. ------------- PR: https://git.openjdk.java.net/jdk/pull/3806 From xliu at openjdk.java.net Fri Apr 30 01:22:55 2021 From: xliu at openjdk.java.net (Xin Liu) Date: Fri, 30 Apr 2021 01:22:55 GMT Subject: RFR: 8229517: Support for optional asynchronous/buffered logging [v9] In-Reply-To: References: <9NrS00PFPoWlahBK0TCWHRTNWYGKePcVkYPEnr6Dtm4=.f8f9c9a4-fc98-4108-8a38-734e21d4b1d9@github.com> Message-ID: On Thu, 29 Apr 2021 06:56:05 GMT, Thomas Stuefe wrote: > While still taking much too much memory on average, especially in a context like yours where you want to store resolved decorations. Hi, Thomas, Thank you for reviewing the patch. I think we should provide accurate log decorations. I am okay to compromise if accuracy comes at expensive expense. My performance results suggest that is not. When I make the patch "Accurate Decorations for AsyncLogging", you can see that I deliberately avoid from changing existed code. That leaves little room for me to support new features. eg. I can't allocate a LogDecorations object using keyword `new`. Global new/delete are forbidden in HotSpot. That's why I choose a new class LogDecorationRef. The reason I choose refcnt because I found LogMessageBuffer used a same LogDecorations object while it iterated. A refcnt can save duplication. I made a new revision which just copy LogDecorations for AsyncLogMessage. My profiling results show that the optimization of refcnt is very limited. Here is my experiment. 1. baseline: dummy version dump without any log. > perf stat -r 200 java --version > /dev/null 2. original dump all logs in trace verbosity. > perf stat -r 200 java -Xlog:'all=trace:file=hotspot-gold.log:uptime,tid,l,tg:filecount=0' --version 3. original without decoration > perf stat -r 200 java -Xlog:'all=trace:file=hotspot-none.log:uptime,none:filecount=0' --version 4. asynclogging refcnt > perf stat -r 200 java -XX:+AsyncLogging -Xlog:'all=trace:file=hotspot-async-refcnt.log:uptime,tid,l,tg:filecount=0' --version 5. asynclogging copy LogDecorations > perf stat -r 200 java -XX:+AsyncLogging -Xlog:'all=trace:file=hotspot-async-copying.log:uptime,tid,l,tg:filecount=0' --version | | | wall-time(ms) | | |---|---------------|---------------|---| | 1 | baseline | 30.928 | | | 2 | original | 98.204 | | | 3 | original-none | 84.624 | | | 4 | async-refcnt | 82.632 | | | 5 | async-copying | 83.71 | | | | | | | I compare the generated log files, async logging generates the same result as Original's. `original` is synchronous logs. `async-refcnt` does show the best results, which is 15.8% faster compared to original. It takes benefits from a standalone thread. `async-copying` is my latest patch which just copys LogDecoratons once. The performance is very close but the implementation is much simpler. `original-none` shows that decorations take a small partition of runtime. The main overhead is still the log messages. Copying it isn't expensive. The benefit of multi-threading can overshadow it. Is that okay I revert my refcnt version and replace it with straight-forward copying. ------------- PR: https://git.openjdk.java.net/jdk/pull/3135 From yyang at openjdk.java.net Fri Apr 30 02:19:30 2021 From: yyang at openjdk.java.net (Yi Yang) Date: Fri, 30 Apr 2021 02:19:30 GMT Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex [v6] In-Reply-To: References: Message-ID: > The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version. > > In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot. > > But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later: > > 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase. > 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag > > Testing: cds, compiler and jdk Yi Yang has updated the pull request incrementally with one additional commit since the last revision: better check1-4 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3615/files - new: https://git.openjdk.java.net/jdk/pull/3615/files/1a96be7e..954abc6e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3615&range=04-05 Stats: 32 lines in 1 file changed: 31 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3615.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3615/head:pull/3615 PR: https://git.openjdk.java.net/jdk/pull/3615 From minqi at openjdk.java.net Fri Apr 30 03:01:06 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 30 Apr 2021 03:01:06 GMT Subject: RFR: 8255493: Support for pre-generated java.lang.invoke classes in CDS dynamic archive [v11] In-Reply-To: References: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> Message-ID: On Thu, 29 Apr 2021 23:48:37 GMT, Ioi Lam wrote: >> Yumin Qi has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision: >> >> - Changed DynamicArchive::dump as static counterpart. Suppressed exceptions in LambdaFormInvokers::regenerate_holder_classes except for oom >> - Merge branch 'master' into jdk-8255493 >> - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8255493 >> - Only store four lambda invoker (which will be regenerated in dynamic dump) lines in static archive >> - Removed TRAP from regenerate_holder_classes, also correct SharedLambdaDictionaryPrinter index >> - Merge branch 'master' into jdk-8255493 >> - Restore filemap.[ch]pp >> - Remove unnecessary file header including >> - Removed unused function static_archive_invokers(), add back accidentally deleted empty line >> - Changed DEBUG_ONLY to log_debug, make small changes for format, added bug tag to test >> - ... and 6 more: https://git.openjdk.java.net/jdk/compare/c3c9da7e...0846f121 > > src/hotspot/share/cds/lambdaFormInvokers.cpp line 84: > >> 82: #define HANDLE_IF_HAS_EXCEPTION \ >> 83: if (HAS_PENDING_EXCEPTION) { \ >> 84: if (!PENDING_EXCEPTION->is_a(vmClasses::OutOfMemoryError_klass())) { \ > > I would suggest adding a comment and error message to explain why we ignore the error: > > > // We may get an exception if the classlist contains an error (or an outdated entry generated by > // an older JDK). > if (DumpSharedArchive) { > log_error(cds)("Failed to generate LambdaForm holder classes. Is your classlist out of date?"); > } else { > log_error(cds)("Failed to generate LambdaForm holder classes. Was the base archive generated with an outdated classlist?"); > } Do you mean DumpSharedSpaces? So the message will be different between static (DumpSharedSpaces) and dynamic, right? > src/hotspot/share/cds/lambdaFormInvokers.cpp line 123: > >> 121: JavaCalls::call_static(&result, cds_klass, method, signrs, list_lines, THREAD); >> 122: >> 123: HANDLE_IF_HAS_EXCEPTION; > > Instead of using a macro, I think the code can be more readable like this: > > > if (check_exception(THREAD)) { > return; > } > > > and `check_exception` can contain the logic of `HANDLE_IF_HAS_EXCEPTION`. OK, I was think of that, if a function or macro and finally took macro. > src/hotspot/share/cds/lambdaFormInvokers.cpp line 141: > >> 139: ClassFileStream st((u1*)buf, len, NULL, ClassFileStream::verify); >> 140: reload_class(class_name, st, THREAD); >> 141: HANDLE_IF_HAS_EXCEPTION; > > Is this necessary? I think bad classlists will cause errors in the JavaCalls::call_static call above, but not here. Here is the original code, and it is necessary, KlassFactory::create_from_stream could throw exception. ------------- PR: https://git.openjdk.java.net/jdk/pull/3611 From iklam at openjdk.java.net Fri Apr 30 03:46:58 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 30 Apr 2021 03:46:58 GMT Subject: RFR: 8255493: Support for pre-generated java.lang.invoke classes in CDS dynamic archive [v11] In-Reply-To: References: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> Message-ID: On Fri, 30 Apr 2021 02:57:02 GMT, Yumin Qi wrote: >> src/hotspot/share/cds/lambdaFormInvokers.cpp line 84: >> >>> 82: #define HANDLE_IF_HAS_EXCEPTION \ >>> 83: if (HAS_PENDING_EXCEPTION) { \ >>> 84: if (!PENDING_EXCEPTION->is_a(vmClasses::OutOfMemoryError_klass())) { \ >> >> I would suggest adding a comment and error message to explain why we ignore the error: >> >> >> // We may get an exception if the classlist contains an error (or an outdated entry generated by >> // an older JDK). >> if (DumpSharedArchive) { >> log_error(cds)("Failed to generate LambdaForm holder classes. Is your classlist out of date?"); >> } else { >> log_error(cds)("Failed to generate LambdaForm holder classes. Was the base archive generated with an outdated classlist?"); >> } > > Do you mean DumpSharedSpaces? So the message will be different between static (DumpSharedSpaces) and dynamic, right? Yes, because the errors can only be caused by bad input from the classlist, which is only used during static archive dump. The information collected during dynamic dump are correct, and cannot cause `CDS.generateLambdaFormHolderClasses()` to fail. >> src/hotspot/share/cds/lambdaFormInvokers.cpp line 141: >> >>> 139: ClassFileStream st((u1*)buf, len, NULL, ClassFileStream::verify); >>> 140: reload_class(class_name, st, THREAD); >>> 141: HANDLE_IF_HAS_EXCEPTION; >> >> Is this necessary? I think bad classlists will cause errors in the JavaCalls::call_static call above, but not here. > > Here is the original code, and it is necessary, KlassFactory::create_from_stream could throw exception. What kid of exceptions will be thrown (other than OOM?) Do you mean `CDS.generateLambdaFormHolderClasses()` can generate bad class files? ------------- PR: https://git.openjdk.java.net/jdk/pull/3611 From minqi at openjdk.java.net Fri Apr 30 03:59:52 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 30 Apr 2021 03:59:52 GMT Subject: RFR: 8255493: Support for pre-generated java.lang.invoke classes in CDS dynamic archive [v11] In-Reply-To: References: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> Message-ID: On Fri, 30 Apr 2021 03:44:55 GMT, Ioi Lam wrote: >> Here is the original code, and it is necessary, KlassFactory::create_from_stream could throw exception. > > What kid of exceptions will be thrown (other than OOM?) Do you mean `CDS.generateLambdaFormHolderClasses()` can generate bad class files? This is after CDS.generateLambdaFormHolderClasses, we get the byte stream of a class --- we need create instanceklass of the class. The exception is from ClassParser ---- whatever the exception during the process. ------------- PR: https://git.openjdk.java.net/jdk/pull/3611 From iklam at openjdk.java.net Fri Apr 30 04:24:52 2021 From: iklam at openjdk.java.net (Ioi Lam) Date: Fri, 30 Apr 2021 04:24:52 GMT Subject: RFR: 8255493: Support for pre-generated java.lang.invoke classes in CDS dynamic archive [v11] In-Reply-To: References: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> Message-ID: On Fri, 30 Apr 2021 03:57:20 GMT, Yumin Qi wrote: >> What kid of exceptions will be thrown (other than OOM?) Do you mean `CDS.generateLambdaFormHolderClasses()` can generate bad class files? > > This is after CDS.generateLambdaFormHolderClasses, we get the byte stream of a class --- we need create instanceklass of the class. The exception is from ClassParser ---- whatever the exception during the process. The ClassParser will throw an error only if OOM, or if the class is invalid. However, if the class is invalid, it means there's a bug inside generateLambdaFormHolderClasses() -- it's not supposed to generate an invalid class. So we cannot just print a warning and ignore the error. The user may not notice the error message. The archive dumping should fail so the user knows what has happened, and will hopefully report the error to us. ------------- PR: https://git.openjdk.java.net/jdk/pull/3611 From sjohanss at openjdk.java.net Fri Apr 30 07:50:56 2021 From: sjohanss at openjdk.java.net (Stefan Johansson) Date: Fri, 30 Apr 2021 07:50:56 GMT Subject: RFR: 8256155: Allow multiple large page sizes to be used on Linux [v30] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 18:36:53 GMT, Marcus G K Williams wrote: >> Change the meaning of LargePageSizeInBytes to be the maximum large page size the JVM may use (not the only one). A default value of zero will mean to allow the JVM use large page sizes up to the system's default large page size. > > Marcus G K Williams has updated the pull request incrementally with one additional commit since the last revision: > > kstefanj review > > Signed-off-by: Marcus G K Williams Filed [JDK-8266349](https://bugs.openjdk.java.net/browse/JDK-8266349) for passing page size down to `reserve_memory_special`. As I mentioned [here](https://github.com/openjdk/jdk/pull/1153/files#r623353767), if we do this change before this one. We should not have to care about anything but adding the available and configure page sizes to `os::_page_sizes`. ------------- PR: https://git.openjdk.java.net/jdk/pull/1153 From dfuchs at openjdk.java.net Fri Apr 30 08:59:51 2021 From: dfuchs at openjdk.java.net (Daniel Fuchs) Date: Fri, 30 Apr 2021 08:59:51 GMT Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex [v6] In-Reply-To: References: Message-ID: <7a4Q1KdYnrj-8iKArQaCHP_s6QHuN58Gz1PpvlSOKzo=.03f760ef-75a4-4882-ac3a-b5a21bc3d73d@github.com> On Fri, 30 Apr 2021 02:19:30 GMT, Yi Yang wrote: >> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version. >> >> In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot. >> >> But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later: >> >> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase. >> 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag >> >> Testing: cds, compiler and jdk > > Yi Yang has updated the pull request incrementally with one additional commit since the last revision: > > better check1-4 Thanks for taking this feedback into account and updating the test! Note: I only reviewed the test. ------------- Marked as reviewed by dfuchs (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3615 From tschatzl at openjdk.java.net Fri Apr 30 09:02:16 2021 From: tschatzl at openjdk.java.net (Thomas Schatzl) Date: Fri, 30 Apr 2021 09:02:16 GMT Subject: RFR: 8214237: Join parallel phases post evacuation Message-ID: Hi all, can I get reviews for this change that joins all non-object moving post evacuation tasks into two parallel batched phases? This has the advantage of avoiding spinup and teardown of the separate tasks and also makes a few tasks that are done serially at the moment run in parallel to each other. For that, extensive analysis of dependencies has been performed, and I found that we need two `G1BatchedGangTasks` (introduced just for this purpose): The first one, `G1PostEvacuateCollectionSetCleanupTask1` contains the following subtasks: * Merge PSS (serial) * Recalculate Used (serial) * Remove Self Forwards (parallel, on evacuation failure) * Clear Card Table (parallel) The second one, `G1PostEvacuateCollectionSetCleanupTask2` contains the following subtasks: * Eagerly Reclaim Humongous Objects (serial) * Purge Code Roots (serial) * Reset Hot Card Cache (serial) * Update Derived Pointers (serial) * Redirty Logged Cards (parallel) * Restore Preserved Marks (parallel, on evacuation failure) * Free Collection Set (parallel) Feel free to propose better names for the batch tasks :) The distribution has been somewhat arbitrary with the following limitations: **Redirty Logged Cards** depends on **Clear Card Table** - we need to clear card table scanning information from the card table before redirtying (Clear Card Table could actually split into the part that clears the "Young Gen" marks and the parts that actually contain card scan information, but it does not seem to provide an advantage). **Redirty Cards** depends on ***Merge PSS** - that phase merge per thread DCQs into global dcq; redirty cards could of course take from the per-thread dcq if needed **Free Collection Set** depends on **Merge PSS** to merge per thread surviving young words to single one and **Recalculate Used** as it updates the heap usage counters. More dependencies between other phases not merged are noted on the [JDK-8214237](https://bugs.openjdk.java.net/browse/JDK-8214237] page. This change seems huge (~1k LOC changes), but actually it isn't: lots of code has been moved 1:1 from `g1CollectedHeap.cpp` to the new `g1YoungGCPostEvacuateTasks.*` files. `g1CollectedHeap.cpp` just got way too huge with this change so it was really useful to start splitting the young gc related things into new files like has been done for the full GC. I'll continue extending this move, but there just has to be a start somewhere. I tried to do this change in a few steps, but that unfortunately caused too many weird intermediate workarounds steps in the timing code (`G1GCPhaseTimes`). So let me try to cut down the change into steps for you. So the change can be split up into - move functionality to `g1YoungGCPostEvacuateTasks.cpp`: this affected dismantling existing AbstractGangTasks into main code (constructor, destructor, do_work method) and move that code to the corresponding `G1AbstractSubTask`. - The helper code typically inlined into that `AbstractGangTask` were moved as well close to that `G1AbstractSubTask`. - wiring up stuff to work with `G1BatchedGangTask` And the review tasks should roughly be: - verify that the copy&paste has been correct (there is a list below) - verify that dependencies are correct (see above) - minor wiring changes Here's a summary for the copy&paste changes: * `RedirtyLoggedCardTableEntryClosure` moved verbatim to `g1YoungGCPostEvacuateTasks.cpp` * `G1RedirtyLoggedCardsTask` were transformed into a `G1AbstractSubTask` * `G1CollectedHeap::remove_self_forwarding_pointers()` and `G1CollectedHeap::restore_after_evac_failure` were transformed into a `G1AbstractSubTask` * recalculate used memory activity has been extracted from the code and put into `G1PostEvacuateCollectionSetCleanupTask1::RecalculateUsedTask` * serial tasks that were about calling a single method were wrapped into a `G1AbstractSubTask` that just calls the same method * `G1FreeCollectionSetTask` moved to `G1PostEvacuateCollectionSetCleanupTask2::FreeCollectionSetTask` * `G1FreeHumongousRegionClosure` moved verbatim to `g1YoungGCPostEvacuateTasks.cpp`, and wrapped into a `G1AbstractSubTask` Minor other things: * the condition for executing and printing logs for when doing eager reclaim has been unified: sometimes the logs have been printed without any eager reclaim because they did not correspond Feel free to ask questions. Testing: tier1-5 multiple times Thanks, Thomas ------------- Commit messages: - Whitespace fixes - Initial version Changes: https://git.openjdk.java.net/jdk/pull/3811/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3811&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8214237 Stats: 1763 lines in 25 files changed: 962 ins; 691 del; 110 mod Patch: https://git.openjdk.java.net/jdk/pull/3811.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3811/head:pull/3811 PR: https://git.openjdk.java.net/jdk/pull/3811 From mcimadamore at openjdk.java.net Fri Apr 30 12:23:45 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 30 Apr 2021 12:23:45 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v6] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/412 Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision: * Add @CS to interface methods in the Foreign API * Beef up test for methd handles and restricted methods ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3699/files - new: https://git.openjdk.java.net/jdk/pull/3699/files/f27db3f3..75474a1f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=04-05 Stats: 306 lines in 8 files changed: 306 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3699.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699 PR: https://git.openjdk.java.net/jdk/pull/3699 From mcimadamore at openjdk.java.net Fri Apr 30 12:27:55 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 30 Apr 2021 12:27:55 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v3] In-Reply-To: References: Message-ID: On Thu, 29 Apr 2021 18:18:00 GMT, Mandy Chung wrote: > I think the implementation does not support that. I will also need to look into how this impacts JDK-8266010. As I suggest earlier, I'm fine to do this as a follow up after integration. I've added `@CS` in the interface methods too. I've also added a stronger test which creates method handles in one module (which doesn't have native access) and then calls them from another module (which does NOT have native access enabled), and make sure that all call fails as expected (e.g. that caller context is that of the lookup module). Surprisingly, CheckCSMs does NOT fail if both interface and implementation methods are `@CS` annotated - but if only interface is annotated, the test fails. This seems odd - since I can't find any logic in the test which check for overriding. Is the test accidentally passing? ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From mcimadamore at openjdk.java.net Fri Apr 30 15:20:42 2021 From: mcimadamore at openjdk.java.net (Maurizio Cimadamore) Date: Fri, 30 Apr 2021 15:20:42 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v7] In-Reply-To: References: Message-ID: > This PR contains the API and implementation changes for JEP-412 [1]. A more detailed description of such changes, to avoid repetitions during the review process, is included as a separate comment. > > [1] - https://openjdk.java.net/jeps/412 Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision: - Revert bad change in benchmark copyright - Do not apply optimized bound check if accessed offset/length do not fit in an `int` value ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3699/files - new: https://git.openjdk.java.net/jdk/pull/3699/files/75474a1f..793ea5c5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3699&range=05-06 Stats: 23 lines in 3 files changed: 17 ins; 5 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3699.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3699/head:pull/3699 PR: https://git.openjdk.java.net/jdk/pull/3699 From minqi at openjdk.java.net Fri Apr 30 15:25:43 2021 From: minqi at openjdk.java.net (Yumin Qi) Date: Fri, 30 Apr 2021 15:25:43 GMT Subject: RFR: 8255493: Support for pre-generated java.lang.invoke classes in CDS dynamic archive [v12] In-Reply-To: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> References: <1pzgNgNpNfLesL4HuoDH8IYJL8LXGf4ouN2aq4ZG5Ks=.16303e3b-03cb-4ddf-8fdb-adadb6493829@github.com> Message-ID: > Hi, Please review > > When do dynamic dump, the pre-generated lambda form classes from java.lang.invoke are not stored in dynamic archive. The patch will regenerate the four holder classes, > "java.lang.invoke.Invokers$Holder", > "java.lang.invoke.DirectMethodHandle$Holder", > "java.lang.invoke.DelegatingMethodHandle$Holder", > "java.lang.invoke.LambdaForm$Holder" > which will include the versions in static archive and new loaded functions all together and stored in dynamic archive. New test case added. > (Minor change to PrintSharedArchiveAtExit, which the index is not consecutive) > > Tests: tier1,tier2,tier3,tier4 > > Thanks > Yumin Yumin Qi has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 18 additional commits since the last revision: - Removed macro for exception handling, removed checking exception after reload class - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8255493 - Changed DynamicArchive::dump as static counterpart. Suppressed exceptions in LambdaFormInvokers::regenerate_holder_classes except for oom - Merge branch 'master' into jdk-8255493 - Merge branch 'master' of ssh://github.com/yminqi/jdk into jdk-8255493 - Only store four lambda invoker (which will be regenerated in dynamic dump) lines in static archive - Removed TRAP from regenerate_holder_classes, also correct SharedLambdaDictionaryPrinter index - Merge branch 'master' into jdk-8255493 - Restore filemap.[ch]pp - Remove unnecessary file header including - ... and 8 more: https://git.openjdk.java.net/jdk/compare/a5d84a15...95d68855 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3611/files - new: https://git.openjdk.java.net/jdk/pull/3611/files/0846f121..95d68855 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3611&range=11 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3611&range=10-11 Stats: 1772 lines in 32 files changed: 1563 ins; 96 del; 113 mod Patch: https://git.openjdk.java.net/jdk/pull/3611.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3611/head:pull/3611 PR: https://git.openjdk.java.net/jdk/pull/3611 From mchung at openjdk.java.net Fri Apr 30 17:23:01 2021 From: mchung at openjdk.java.net (Mandy Chung) Date: Fri, 30 Apr 2021 17:23:01 GMT Subject: RFR: 8264774: Implementation of Foreign Function and Memory API (Incubator) [v3] In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 12:24:38 GMT, Maurizio Cimadamore wrote: > I've added `@CS` in the interface methods too. I've also added a stronger test which creates method handles in one module (which doesn't have native access) and then calls them from another module (which does NOT have native access enabled), and make sure that all call fails as expected (e.g. that caller context is that of the lookup module). Thanks. > Surprisingly, CheckCSMs does NOT fail if both interface and implementation methods are `@CS` annotated - but if only interface is annotated, the test fails. This seems odd - since I can't find any logic in the test which check for overriding. Is the test accidentally passing? I create JDK-8266383 and I will look into that. ------------- PR: https://git.openjdk.java.net/jdk/pull/3699 From psandoz at openjdk.java.net Fri Apr 30 17:33:52 2021 From: psandoz at openjdk.java.net (Paul Sandoz) Date: Fri, 30 Apr 2021 17:33:52 GMT Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex [v6] In-Reply-To: References: Message-ID: <9Z_DkUjmqefCjf9mvecHUtoLHhw1qGNWJPxufuwvXI0=.36498a86-d09f-4eea-ab89-74844dd862cf@github.com> On Fri, 30 Apr 2021 02:19:30 GMT, Yi Yang wrote: >> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version. >> >> In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot. >> >> But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later: >> >> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase. >> 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag >> >> Testing: cds, compiler and jdk > > Yi Yang has updated the pull request incrementally with one additional commit since the last revision: > > better check1-4 It was my hope this would eventually happen when we added `Objects.checkIndex` and the underlying intrinsic. Very good! ------------- PR: https://git.openjdk.java.net/jdk/pull/3615 From iignatyev at openjdk.java.net Fri Apr 30 19:15:02 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Fri, 30 Apr 2021 19:15:02 GMT Subject: RFR: 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests [v7] In-Reply-To: References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> Message-ID: On Fri, 30 Apr 2021 18:22:16 GMT, Igor Ignatyev wrote: >> Christian Hagedorn has updated the pull request incrementally with two additional commits since the last revision: >> >> - Fix XCOMP cases from old framework and turn it into new debug flag -DIgnoreCompilerControls >> - Apply review comments: Added new Compiler annotation class for @DontCompile, changed C1 into C1_SIMPLE, refactored code for ExcludeRandom and FlipC1C2, added missing flag description in README, and some other smaller refactoring/renamings > > test/lib/jdk/test/lib/hotspot/ir_framework/TestInfo.java line 57: > >> 55: * allowing a compilation on the requested level in {@link Test#compLevel()}. >> 56: * >> 57: * @return {@code true} if the framework compiled the test; > > as in `RunInfo`: > s/compiled/skipped compilation of/ btw, do we really need these methods in both `RunInfo` and `TestInfo`? ------------- PR: https://git.openjdk.java.net/jdk/pull/3508 From iignatyev at openjdk.java.net Fri Apr 30 19:15:01 2021 From: iignatyev at openjdk.java.net (Igor Ignatyev) Date: Fri, 30 Apr 2021 19:15:01 GMT Subject: RFR: 8254129: IR Test Framework to support regex-based matching on the IR in JTreg compiler tests [v7] In-Reply-To: References: <2iYQOJ5yeu7SvGcScLPBOWCPMLv69e1ksOL1vW3ytL8=.0c27621d-ef3d-422c-9d8c-922078ca3160@github.com> Message-ID: On Tue, 27 Apr 2021 15:37:58 GMT, Christian Hagedorn wrote: >> This RFE provides an IR test framework to perform regex-based checks on the C2 IR shape of test methods emitted by the VM flags `-XX:+PrintIdeal` and `-XX:+PrintOptoAssembly`. The framework can also be used for other non-IR matching (and non-compiler) tests by providing easy to use annotations for commonly used testing patterns and compiler control flags. >> >> The framework is based on the ideas of the currently present IR test framework in [Valhalla](https://github.com/openjdk/valhalla/blob/e9c78ce4fcfd01361c35883e0d68f9ae5a80d079/test/hotspot/jtreg/compiler/valhalla/inlinetypes/InlineTypeTest.java) (mainly implemented by @TobiHartmann) which is being used with great success. This new framework aims to replace the old one in Valhalla at some point. >> >> A detailed description about how this new IR test framework works and how it is used is provided in the [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) file and in the [Javadocs](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc/jdk/test/lib/hotspot/ir_framework/package-summary.html) written for the framework classes. >> >> To finish a first version of this framework for JDK 17, I decided to leave some improvement possibilities and ideas to be followed up on in additional RFEs. Some ideas are mentioned in "Future Work" in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md) and were also created as subtasks of this RFE. >> >> Testing (also described in "Internal Framework Tests in [README.md](https://github.com/chhagedorn/jdk/blob/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/README.md)): >> There are various tests to verify the correctness of the test framework which can be found as JTreg tests in the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) folder. Additional testing was performed by converting all compiler Inline Types test of project Valhalla (done by @katyapav in [JDK-8263024](https://bugs.openjdk.java.net/browse/JDK-8263024)) that used the old framework to the new framework. This provided additional testing for the framework itself. We ran the converted tests with all the flag settings used in hs-tier1-9 and hs-precheckin-comp. For sanity checking, this was also done with a sample IR test in mainline. >> >> Some stats about the framework code added to [ir_framework](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework): >> >> - without the [Javadocs files](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/doc) : 60 changed files, 13212 insertions, 0 deletions. >> - without the [tests](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/tests) and [examples](https://github.com/chhagedorn/jdk/tree/aa005f384a4567c6c0b5f08f7c5df57f705dc540/test/lib/jdk/test/lib/hotspot/ir_framework/examples) folder: 40 files changed, 6781 insertions >> - comments: 2399 insertions (calculated with `git diff --cached !(tests|examples) | grep -c -E "(^[+-]\s*(/)?*)|(^[+-]\s*//)"`) >> - which leaves 4382 lines of code inserted >> >> Big thanks to: >> - @TobiHartmann for all his help by discussing the new framework and for providing insights from his IR test framework in Valhalla. >> - @katyapav for converting the Valhalla tests to use the new framework which found some harder to catch bugs in the framework and also some actual C2 bugs. >> - @iignatev for helping to simplify the framework usage with JTreg and with the framework internal VM calling structure. >> - and others who provided valuable feedback. >> >> Thanks, >> Christian > > Christian Hagedorn has updated the pull request incrementally with two additional commits since the last revision: > > - Fix XCOMP cases from old framework and turn it into new debug flag -DIgnoreCompilerControls > - Apply review comments: Added new Compiler annotation class for @DontCompile, changed C1 into C1_SIMPLE, refactored code for ExcludeRandom and FlipC1C2, added missing flag description in README, and some other smaller refactoring/renamings Hi Christian, I've reviewed all the files but `examples` and `tests`, for them I'd actually recommend you to put `examples` into `tests` (possible in a subdir), and just update readme to say that the examples can be found in test directory. I'd also recommend you to put your java files into separate packages to reflect their decision b/w multiple JVMs (flag, test, driver), so you will end up w/ 3-4 subpackages (+1 for the code shared b/w 3 JVMs), this will make it easier to reason about and maintain the framework. Thanks, -- Igor test/lib/jdk/test/lib/hotspot/ir_framework/RunInfo.java line 89: > 87: * {@link #isCompilationSkipped(String)}. > 88: * > 89: * @return {@code true} if the framework compiled the test; s/compiled/skipped compilation of/ ? test/lib/jdk/test/lib/hotspot/ir_framework/RunInfo.java line 105: > 103: * > 104: * @param testName the test method for which the method object should be returned. > 105: * @return {@code true} if the framework compiled the test; the same comment as above test/lib/jdk/test/lib/hotspot/ir_framework/TestFramework.java line 984: > 982: private final String hotspotPidFileName; > 983: > 984: JVMOutput(OutputAnalyzer oa, Scenario scenario, ProcessBuilder process) { instead of passing a ProcessBuilder, you can either pass a command-line or better just past prepared flags, and make it JVMOutput's (you will need a better name) responsibility to execute the process, create OutputAnalyzer, etc. Suggestion: JVMOutput(List cmds, Scenario scenario) { var pb = ProcessTools.createJavaProcessBuilder(cmds); try { // Calls 'main' of TestFrameworkExecution to run all specified tests with commands 'cmds'. // Use executeProcess instead of executeTestJvm as we have already added the JTreg VM and // Java options in prepareTestVMFlags(). this.oa = ProcessTools.executeProcess(process); } catch (Exception e) { throw new TestFrameworkException("Error while executing Test VM", e); } this.cmd = pb.command(); ... and then runTest will be smth like private void runTestVM(List additionalFlags) { List cmds = prepareTestVMFlags(additionalFlags); socket.start(); JVMOutput output = new JVMOutput(cmds, scenario); ... test/lib/jdk/test/lib/hotspot/ir_framework/TestFrameworkExecution.java line 375: > 373: case 2 -> compiler = Compiler.C2; > 374: default -> compiler = Compiler.ANY; > 375: } Suggestion: Compiler compiler = switch (Utils.getRandomInstance().nextInt() % 3) { case 1 -> Compiler.C1; case 2 -> Compiler.C2; default -> Compiler.ANY; } test/lib/jdk/test/lib/hotspot/ir_framework/TestFrameworkExecution.java line 796: > 794: if (VERBOSE) { > 795: System.out.println("Run " + test.toString()); > 796: } else if (testFilterPresent) { I'm not sure, but it feels like it shouldn't be `else if` test/lib/jdk/test/lib/hotspot/ir_framework/TestFrameworkExecution.java line 819: > 817: if (GC_AFTER) { > 818: System.out.println("doing GC"); > 819: System.gc(); since this VM has access to WhiteBox API, you can call `WhiteBox.fullGC()` here as it's more "reliable". test/lib/jdk/test/lib/hotspot/ir_framework/TestFrameworkExecution.java line 827: > 825: System.out.println(System.lineSeparator() + System.lineSeparator() + "Test execution times:"); > 826: for (Map.Entry entry : durations.entrySet()) { > 827: System.out.format("%-10s%15d ns" + System.lineSeparator(), entry.getValue() + ":", entry.getKey()); instead of System.lineSeparator(), you can use `%n` in the format string test/lib/jdk/test/lib/hotspot/ir_framework/TestFrameworkExecution.java line 960: > 958: * Abstract super class for base, checked and custom run tests. > 959: */ > 960: abstract class AbstractTest { can you move this and all the classes below into their own .java files? you might want to put them into a separate package (as a way to group/isolate them) test/lib/jdk/test/lib/hotspot/ir_framework/TestFrameworkPrepareFlags.java line 92: > 90: + String.join(TestFramework.TEST_VM_FLAGS_DELIMITER, flags) > 91: + System.lineSeparator() + TestFramework.TEST_VM_FLAGS_END; > 92: TestFrameworkSocket.write(encoding, "flag encoding"); I don't see a need to use socket here, it will significantly simplify the code, the failure analysis, and reproducing if we just save prepared flags into a file w/ a well-known location (e.g. passed as an argument/property to `TestFrameworkPrepareFlags`), and when used command-line argument file (`@-file`) to pass these flags to the test VM. test/lib/jdk/test/lib/hotspot/ir_framework/TestFrameworkSocket.java line 87: > 85: > 86: /** > 87: * Waits for client sockets (created by flag or test VM) to connect. Return the messages received by the clients. it actually waits for just one client, and return the message sent by it (ore received from): Suggestion: * Waits for a client (created by flag or test VM) to connect. Return the messages received from the client. test/lib/jdk/test/lib/hotspot/ir_framework/TestInfo.java line 57: > 55: * allowing a compilation on the requested level in {@link Test#compLevel()}. > 56: * > 57: * @return {@code true} if the framework compiled the test; as in `RunInfo`: s/compiled/skipped compilation of/ test/lib/jdk/test/lib/hotspot/ir_framework/TestVMException.java line 34: > 32: TestVMException(String exceptionInfo) { > 33: super("There were one or multiple errors. Please check stderr for more information."); > 34: this.exceptionInfo = exceptionInfo; why can't this info be stored as `Throwable::message`? ------------- Changes requested by iignatyev (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3508 From iveresov at openjdk.java.net Fri Apr 30 19:23:52 2021 From: iveresov at openjdk.java.net (Igor Veresov) Date: Fri, 30 Apr 2021 19:23:52 GMT Subject: RFR: 8265518: C1: Intrinsic support for Preconditions.checkIndex [v6] In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 02:19:30 GMT, Yi Yang wrote: >> The JDK codebase re-created many variants of checkIndex(`grep -I -r 'cehckIndex' jdk/`). A notable variant is java.nio.Buffer.checkIndex, which annotated with @IntrinsicCandidate and it only has a corresponding C1 intrinsic version. >> >> In fact, there is an utility method `jdk.internal.util.Preconditions.checkIndex`(wrapped by java.lang.Objects.checkIndex) that behaves the same as these variants of checkIndex, we can replace these re-created variants of checkIndex by Objects.checkIndex, it would significantly reduce duplicated code and enjoys performance improvement because Preconditions.checkIndex is @IntrinsicCandidate and it has a corresponding intrinsic method in HotSpot. >> >> But, the problem is currently HotSpot only implements the C2 version of Preconditions.checkIndex. To reuse it global-widely in JDK code, I think we can firstly implement its C1 counterpart. There are also a few kinds of stuff we can do later: >> >> 1. Replace all variants of checkIndex by Objects.checkIndex in the whole JDK codebase. >> 2. Remove Buffer.checkIndex and obsolete/deprecate InlineNIOCheckIndex flag >> >> Testing: cds, compiler and jdk > > Yi Yang has updated the pull request incrementally with one additional commit since the last revision: > > better check1-4 Looks like now the test fails in the pre-submit tests? ------------- PR: https://git.openjdk.java.net/jdk/pull/3615 From kvn at openjdk.java.net Fri Apr 30 19:26:52 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 30 Apr 2021 19:26:52 GMT Subject: RFR: 8266074: Vtable-based CHA implementation In-Reply-To: References: Message-ID: <5GRZsKzjv3hRaV9LNgp2tQIaAmsUbIbGr4xGQDdkwus=.77bed390-12c6-4526-b8b1-c68f736b7c1c@github.com> On Tue, 27 Apr 2021 20:15:25 GMT, Vladimir Ivanov wrote: > As of now, Class Hierarchy Analysis (CHA) employs an approximate algorithm to enumerate all non-abstract methods in a class hierarchy. > > It served quite well for many years, but it accumulated significant complexity > to support different corner cases over time and inevitable evolution of the JVM > stretched the whole approach way too much (to the point where it become almost > impossible to extend the analysis any further). > > It turns out the root problem is the decision to reimplement method resolution > and method selection logic from scratch and to perform it on JVM internal > representation. It makes it very hard to reason about correctness and the > implementation becomes sensitive to changes in internal representation. > > So, the main motivation for the redesign is twofold: > * reduce maintenance burden and increase confidence in the code; > * unlock some long-awaited enhancements. > > Though I did experiment with relaxing existing constraints (e.g., enable default method support), > any possible enhancements are deliberately kept out of scope for the current PR. > (It does deliver a bit of minor enhancements front as the changes in > compiler/cha/StrengthReduceInterfaceCall.java manifest, but it's a side effect > of the other changes and was not the goal of the current work.) > > Proposed implementation (`LinkedConcreteMethodFinder`) mimics method invocation > and relies on vtable/itable information to detect target method for every > subclass it visits. It removes all the complexity associated with method > resolution and method selection logic and leaves only essential logic to prepare for method selection. > > Vtables are filled during class linkage, so new logic doesn't work on not yet linked classed. > Instead of supporting not yet linked case, it is simply ignored. It is safe to > skip them (treat as "effectively non-concrete") since it is guaranteed there > are no instances created yet. But it requires VM to check dependencies once a > class is linked. > > I ended up with 2 separate dependency validation passes (when class is loaded > and when it is linked). To avoid duplicated work, only dependencies > which may be affected by class initialization state change > (`unique_concrete_method_4`) are visited. > > (I experimented with merging passes into a single pass (delay the pass until > linkage is over), but it severely affected other class-related dependencies and > relevant optimizations.code.) > > Compiler Interface (CI) is changed to require users to provide complete information about the call site being analyzed. > > Old implementation is kept intact for now (will be removed later) to: > - JVMCI hasn't been migrated to the new implementation yet; > - enable verification that 2 implementations (old and new) agree on the results; > - temporarily keep an option to revert to the original implementation in case any regressions show up. > > Testing: > - [x] hs-tier1 - hs-tier9 > - [x] hs-tier1 - hs-tier4 w/ `-XX:-UseVtableBasedCHA` > - [x] performance testing > > Thanks! In general looks good. I have few comments. src/hotspot/share/code/dependencies.hpp line 138: > 136: // than {M1}. > 137: unique_concrete_method_2, // one unique concrete method under CX > 138: unique_concrete_method_4, // one unique concrete method under CX Needs comment to distinguish from `unique_concrete_method_2`. test/hotspot/jtreg/compiler/cha/StrengthReduceInterfaceCall.java line 35: > 33: * > 34: * @run main/othervm -Xbootclasspath/a:. -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions > 35: * -XX:+UseVtableBasedCHA `UseVtableBasedCHA` is `true` by default. May be duplicate these `runs` for both cases: on and off. ------------- PR: https://git.openjdk.java.net/jdk/pull/3727 From vlivanov at openjdk.java.net Fri Apr 30 19:37:52 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Fri, 30 Apr 2021 19:37:52 GMT Subject: RFR: 8266074: Vtable-based CHA implementation In-Reply-To: <5GRZsKzjv3hRaV9LNgp2tQIaAmsUbIbGr4xGQDdkwus=.77bed390-12c6-4526-b8b1-c68f736b7c1c@github.com> References: <5GRZsKzjv3hRaV9LNgp2tQIaAmsUbIbGr4xGQDdkwus=.77bed390-12c6-4526-b8b1-c68f736b7c1c@github.com> Message-ID: On Fri, 30 Apr 2021 19:15:50 GMT, Vladimir Kozlov wrote: >> As of now, Class Hierarchy Analysis (CHA) employs an approximate algorithm to enumerate all non-abstract methods in a class hierarchy. >> >> It served quite well for many years, but it accumulated significant complexity >> to support different corner cases over time and inevitable evolution of the JVM >> stretched the whole approach way too much (to the point where it become almost >> impossible to extend the analysis any further). >> >> It turns out the root problem is the decision to reimplement method resolution >> and method selection logic from scratch and to perform it on JVM internal >> representation. It makes it very hard to reason about correctness and the >> implementation becomes sensitive to changes in internal representation. >> >> So, the main motivation for the redesign is twofold: >> * reduce maintenance burden and increase confidence in the code; >> * unlock some long-awaited enhancements. >> >> Though I did experiment with relaxing existing constraints (e.g., enable default method support), >> any possible enhancements are deliberately kept out of scope for the current PR. >> (It does deliver a bit of minor enhancements front as the changes in >> compiler/cha/StrengthReduceInterfaceCall.java manifest, but it's a side effect >> of the other changes and was not the goal of the current work.) >> >> Proposed implementation (`LinkedConcreteMethodFinder`) mimics method invocation >> and relies on vtable/itable information to detect target method for every >> subclass it visits. It removes all the complexity associated with method >> resolution and method selection logic and leaves only essential logic to prepare for method selection. >> >> Vtables are filled during class linkage, so new logic doesn't work on not yet linked classed. >> Instead of supporting not yet linked case, it is simply ignored. It is safe to >> skip them (treat as "effectively non-concrete") since it is guaranteed there >> are no instances created yet. But it requires VM to check dependencies once a >> class is linked. >> >> I ended up with 2 separate dependency validation passes (when class is loaded >> and when it is linked). To avoid duplicated work, only dependencies >> which may be affected by class initialization state change >> (`unique_concrete_method_4`) are visited. >> >> (I experimented with merging passes into a single pass (delay the pass until >> linkage is over), but it severely affected other class-related dependencies and >> relevant optimizations.code.) >> >> Compiler Interface (CI) is changed to require users to provide complete information about the call site being analyzed. >> >> Old implementation is kept intact for now (will be removed later) to: >> - JVMCI hasn't been migrated to the new implementation yet; >> - enable verification that 2 implementations (old and new) agree on the results; >> - temporarily keep an option to revert to the original implementation in case any regressions show up. >> >> Testing: >> - [x] hs-tier1 - hs-tier9 >> - [x] hs-tier1 - hs-tier4 w/ `-XX:-UseVtableBasedCHA` >> - [x] performance testing >> >> Thanks! > > test/hotspot/jtreg/compiler/cha/StrengthReduceInterfaceCall.java line 35: > >> 33: * >> 34: * @run main/othervm -Xbootclasspath/a:. -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions >> 35: * -XX:+UseVtableBasedCHA > > `UseVtableBasedCHA` is `true` by default. May be duplicate these `runs` for both cases: on and off. The test assumes `UseVtableBasedCHA` is on and some of the assertions it makes fail with `-XX:-UseVtableBasedCHA`. So, it would require all the changes in the test logic have to be guarded by a check whether UseVtableBasedCHA is on or off. Considering `UseVtableBasedCHA` is turned on by default in the PR, I don't see much value in complicating the test. ------------- PR: https://git.openjdk.java.net/jdk/pull/3727 From github.com+58006833+xbzhang99 at openjdk.java.net Fri Apr 30 19:57:30 2021 From: github.com+58006833+xbzhang99 at openjdk.java.net (Xubo Zhang) Date: Fri, 30 Apr 2021 19:57:30 GMT Subject: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms [v2] In-Reply-To: References: Message-ID: > Implement Adler32 intrinsic for x86 64-bit platform using vector instructions. > > For the following benchmark: > http://cr.openjdk.java.net/~pli/rfr/8216259/TestAdler32.java > > The optimization shows ~5x improvement. > > Base: > Benchmark (count) Mode Cnt Score Error Units > TestAdler32Perf.testAdler32Update 64 avgt 25 0.084 ? 0.001 us/op > TestAdler32Perf.testAdler32Update 128 avgt 25 0.104 ? 0.001 us/op > TestAdler32Perf.testAdler32Update 256 avgt 25 0.146 ? 0.002 us/op > TestAdler32Perf.testAdler32Update 512 avgt 25 0.226 ? 0.002 us/op > TestAdler32Perf.testAdler32Update 1024 avgt 25 0.390 ? 0.005 us/op > TestAdler32Perf.testAdler32Update 2048 avgt 25 0.714 ? 0.007 us/op > TestAdler32Perf.testAdler32Update 4096 avgt 25 1.359 ? 0.014 us/op > TestAdler32Perf.testAdler32Update 8192 avgt 25 2.751 ? 0.023 us/op > TestAdler32Perf.testAdler32Update 16384 avgt 25 5.494 ? 0.077 us/op > TestAdler32Perf.testAdler32Update 32768 avgt 25 11.058 ? 0.160 us/op > TestAdler32Perf.testAdler32Update 65536 avgt 25 22.198 ? 0.319 us/op > > > With patch: > Benchmark (count) Mode Cnt Score Error Units > TestAdler32Perf.testAdler32Update 64 avgt 25 0.020 ? 0.001 us/op > TestAdler32Perf.testAdler32Update 128 avgt 25 0.025 ? 0.001 us/op > TestAdler32Perf.testAdler32Update 256 avgt 25 0.031 ? 0.001 us/op > TestAdler32Perf.testAdler32Update 512 avgt 25 0.048 ? 0.001 us/op > TestAdler32Perf.testAdler32Update 1024 avgt 25 0.078 ? 0.001 us/op > TestAdler32Perf.testAdler32Update 2048 avgt 25 0.139 ? 0.002 us/op > TestAdler32Perf.testAdler32Update 4096 avgt 25 0.262 ? 0.004 us/op > TestAdler32Perf.testAdler32Update 8192 avgt 25 0.524 ? 0.010 us/op > TestAdler32Perf.testAdler32Update 16384 avgt 25 1.017 ? 0.022 us/op > TestAdler32Perf.testAdler32Update 32768 avgt 25 2.058 ? 0.052 us/op > TestAdler32Perf.testAdler32Update 65536 avgt 25 3.994 ? 0.013 us/op Xubo Zhang has updated the pull request incrementally with one additional commit since the last revision: refactor adler32 algorithm to a new file x86/macroAssembler_x86_adler.cpp; added a scratch reg to vpmulld, and some other issues ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3806/files - new: https://git.openjdk.java.net/jdk/pull/3806/files/c2b5a126..9d8e0230 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3806&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3806&range=00-01 Stats: 387 lines in 4 files changed: 210 ins; 169 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/3806.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3806/head:pull/3806 PR: https://git.openjdk.java.net/jdk/pull/3806 From kvn at openjdk.java.net Fri Apr 30 20:16:11 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 30 Apr 2021 20:16:11 GMT Subject: RFR: 8266074: Vtable-based CHA implementation In-Reply-To: References: <5GRZsKzjv3hRaV9LNgp2tQIaAmsUbIbGr4xGQDdkwus=.77bed390-12c6-4526-b8b1-c68f736b7c1c@github.com> Message-ID: On Fri, 30 Apr 2021 19:34:40 GMT, Vladimir Ivanov wrote: >> test/hotspot/jtreg/compiler/cha/StrengthReduceInterfaceCall.java line 35: >> >>> 33: * >>> 34: * @run main/othervm -Xbootclasspath/a:. -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions >>> 35: * -XX:+UseVtableBasedCHA >> >> `UseVtableBasedCHA` is `true` by default. May be duplicate these `runs` for both cases: on and off. > > The test assumes `UseVtableBasedCHA` is on and some of the assertions it makes fail with `-XX:-UseVtableBasedCHA`. So, it would require all the changes in the test logic have to be guarded by a check whether UseVtableBasedCHA is on or off. > > Considering `UseVtableBasedCHA` is turned on by default in the PR, I don't see much value in complicating the test. So only new implementation is tested with these changes in test. Got it. May be use: `@requires vm.opt.final.UseVtableBasedCHA == true` ------------- PR: https://git.openjdk.java.net/jdk/pull/3727 From sviswanathan at openjdk.java.net Fri Apr 30 20:17:55 2021 From: sviswanathan at openjdk.java.net (Sandhya Viswanathan) Date: Fri, 30 Apr 2021 20:17:55 GMT Subject: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms [v2] In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 19:57:30 GMT, Xubo Zhang wrote: >> Implement Adler32 intrinsic for x86 64-bit platform using vector instructions. >> >> For the following benchmark: >> http://cr.openjdk.java.net/~pli/rfr/8216259/TestAdler32.java >> >> The optimization shows ~5x improvement. >> >> Base: >> Benchmark (count) Mode Cnt Score Error Units >> TestAdler32Perf.testAdler32Update 64 avgt 25 0.084 ? 0.001 us/op >> TestAdler32Perf.testAdler32Update 128 avgt 25 0.104 ? 0.001 us/op >> TestAdler32Perf.testAdler32Update 256 avgt 25 0.146 ? 0.002 us/op >> TestAdler32Perf.testAdler32Update 512 avgt 25 0.226 ? 0.002 us/op >> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.390 ? 0.005 us/op >> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.714 ? 0.007 us/op >> TestAdler32Perf.testAdler32Update 4096 avgt 25 1.359 ? 0.014 us/op >> TestAdler32Perf.testAdler32Update 8192 avgt 25 2.751 ? 0.023 us/op >> TestAdler32Perf.testAdler32Update 16384 avgt 25 5.494 ? 0.077 us/op >> TestAdler32Perf.testAdler32Update 32768 avgt 25 11.058 ? 0.160 us/op >> TestAdler32Perf.testAdler32Update 65536 avgt 25 22.198 ? 0.319 us/op >> >> >> With patch: >> Benchmark (count) Mode Cnt Score Error Units >> TestAdler32Perf.testAdler32Update 64 avgt 25 0.020 ? 0.001 us/op >> TestAdler32Perf.testAdler32Update 128 avgt 25 0.025 ? 0.001 us/op >> TestAdler32Perf.testAdler32Update 256 avgt 25 0.031 ? 0.001 us/op >> TestAdler32Perf.testAdler32Update 512 avgt 25 0.048 ? 0.001 us/op >> TestAdler32Perf.testAdler32Update 1024 avgt 25 0.078 ? 0.001 us/op >> TestAdler32Perf.testAdler32Update 2048 avgt 25 0.139 ? 0.002 us/op >> TestAdler32Perf.testAdler32Update 4096 avgt 25 0.262 ? 0.004 us/op >> TestAdler32Perf.testAdler32Update 8192 avgt 25 0.524 ? 0.010 us/op >> TestAdler32Perf.testAdler32Update 16384 avgt 25 1.017 ? 0.022 us/op >> TestAdler32Perf.testAdler32Update 32768 avgt 25 2.058 ? 0.052 us/op >> TestAdler32Perf.testAdler32Update 65536 avgt 25 3.994 ? 0.013 us/op > > Xubo Zhang has updated the pull request incrementally with one additional commit since the last revision: > > refactor adler32 algorithm to a new file x86/macroAssembler_x86_adler.cpp; added a scratch reg to vpmulld, and some other issues src/hotspot/cpu/x86/macroAssembler_x86.cpp line 3248: > 3246: > 3247: void MacroAssembler::vpmulld(XMMRegister dst, XMMRegister nds, AddressLiteral src, int vector_len, Register scratch_reg) { > 3248: // Used in sign-bit flipping with aligned address. You could remove the spurious comment here. src/hotspot/cpu/x86/macroAssembler_x86_adler.cpp line 32: > 30: #include "macroAssembler_x86.hpp" > 31: > 32: The updateBytesAdler32 should be under #ifdef _LP64, #endif. src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 5824: > 5822: __ enter(); // required for proper stackwalking of RuntimeStub frame > 5823: > 5824: __ vmovdqu(yshuf0, ExternalAddress((address) StubRoutines::x86::_adler32_shuf0_table)); For vmovdqu also it is good to be explicit with scratch register. src/hotspot/cpu/x86/vm_version_x86.cpp line 901: > 899: } > 900: > 901: if (supports_avx2() && UseAdler32Intrinsics) { This should be under #ifdef _LP64. For 32-bit, UseAdler32Intrinsics should be set to false. ------------- PR: https://git.openjdk.java.net/jdk/pull/3806 From jrose at openjdk.java.net Fri Apr 30 20:26:54 2021 From: jrose at openjdk.java.net (John R Rose) Date: Fri, 30 Apr 2021 20:26:54 GMT Subject: RFR: 8266074: Vtable-based CHA implementation In-Reply-To: References: Message-ID: On Tue, 27 Apr 2021 20:15:25 GMT, Vladimir Ivanov wrote: > As of now, Class Hierarchy Analysis (CHA) employs an approximate algorithm to enumerate all non-abstract methods in a class hierarchy. > > It served quite well for many years, but it accumulated significant complexity > to support different corner cases over time and inevitable evolution of the JVM > stretched the whole approach way too much (to the point where it become almost > impossible to extend the analysis any further). > > It turns out the root problem is the decision to reimplement method resolution > and method selection logic from scratch and to perform it on JVM internal > representation. It makes it very hard to reason about correctness and the > implementation becomes sensitive to changes in internal representation. > > So, the main motivation for the redesign is twofold: > * reduce maintenance burden and increase confidence in the code; > * unlock some long-awaited enhancements. > > Though I did experiment with relaxing existing constraints (e.g., enable default method support), > any possible enhancements are deliberately kept out of scope for the current PR. > (It does deliver a bit of minor enhancements front as the changes in > compiler/cha/StrengthReduceInterfaceCall.java manifest, but it's a side effect > of the other changes and was not the goal of the current work.) > > Proposed implementation (`LinkedConcreteMethodFinder`) mimics method invocation > and relies on vtable/itable information to detect target method for every > subclass it visits. It removes all the complexity associated with method > resolution and method selection logic and leaves only essential logic to prepare for method selection. > > Vtables are filled during class linkage, so new logic doesn't work on not yet linked classed. > Instead of supporting not yet linked case, it is simply ignored. It is safe to > skip them (treat as "effectively non-concrete") since it is guaranteed there > are no instances created yet. But it requires VM to check dependencies once a > class is linked. > > I ended up with 2 separate dependency validation passes (when class is loaded > and when it is linked). To avoid duplicated work, only dependencies > which may be affected by class initialization state change > (`unique_concrete_method_4`) are visited. > > (I experimented with merging passes into a single pass (delay the pass until > linkage is over), but it severely affected other class-related dependencies and > relevant optimizations.code.) > > Compiler Interface (CI) is changed to require users to provide complete information about the call site being analyzed. > > Old implementation is kept intact for now (will be removed later) to: > - JVMCI hasn't been migrated to the new implementation yet; > - enable verification that 2 implementations (old and new) agree on the results; > - temporarily keep an option to revert to the original implementation in case any regressions show up. > > Testing: > - [x] hs-tier1 - hs-tier9 > - [x] hs-tier1 - hs-tier4 w/ `-XX:-UseVtableBasedCHA` > - [x] performance testing > > Thanks! This is a major bit of stewardship. Here's a bit of old history: The approximate dependencies walk code was hacked in the earliest days, for devirtualization?a new and cool thing back then. At the same time the vtable code was hacked in, and both sets of logic were hacked until the bugs went away. It took a while for all of us to fully understand the VM we were building. (This is why we had to add ACC_SUPER and class loader ~dependencies~ constraints, for example.) A couple engineers cleaned up the vtable stuff to its present state, and I and others cleaned up the CHA logic to its present state, before you touched it. It?s great to see those two bodies of code converging; thank you very very much. Reviewed! One question, which the review doesn't depend on: Are get getting closer to being able to apply CHA to interfaces? Unique-implementor and unique-method optimizations on interfaces are important. I ask because of some comments that throw shade on interfaces in the unit tests. src/hotspot/share/code/dependencies.cpp line 1521: > 1519: selected_method = recv_klass->method_at_itable_or_null(_declaring_klass, _vtable_index, > 1520: implements_interface); // out parameter > 1521: assert(implements_interface, "not implemented"); Looking at `recv_klass->method_at_itable_or_null`, I wonder if there can be ?holes? in the itable for missing methods. They would lead to `AME` if called. They might also trigger your assert here: `assert(implements_interface, "not implemented")`. Is there some reason that `select_method` cannot possibly encounter a missing method? Answer to self: I don't remember whether the JVM creates itable methods on the fly, but I suppose it does, so the code would see an synthetic abstract method. (Decades ago we named those Miranda Methods because if you don't have a responding method "one will be provided for you".) And itables are just aliases of vtable slices, so the miranda placed in the vtable will be seen also in the itable. (Overall comment on this area of the code: It looks great, much better than when I touched it last. Thanks!) ------------- Marked as reviewed by jrose (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3727 From vlivanov at openjdk.java.net Fri Apr 30 20:38:56 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Fri, 30 Apr 2021 20:38:56 GMT Subject: RFR: 8266074: Vtable-based CHA implementation In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 20:24:23 GMT, John R Rose wrote: > Are get getting closer to being able to apply CHA to interfaces? Yes! Though it is always the case now that any interface method case can be strength-reduced to a virtual call (due to unique implementor constraint), I deliberately kept interface dispatch support in place. Once there's a reliable way to enumerate all implementors, it becomes straightforwad to apply CHA when interface type information can be trusted. And, as a first step, it would be very interesting to experiment with sealed interface support . ------------- PR: https://git.openjdk.java.net/jdk/pull/3727 From github.com+58006833+xbzhang99 at openjdk.java.net Fri Apr 30 21:15:20 2021 From: github.com+58006833+xbzhang99 at openjdk.java.net (Xubo Zhang) Date: Fri, 30 Apr 2021 21:15:20 GMT Subject: RFR: 8266332: Adler32 intrinsic for x86 64-bit platforms [v3] In-Reply-To: References: Message-ID: > Implement Adler32 intrinsic for x86 64-bit platform using vector instructions. > > For the following benchmark: > http://cr.openjdk.java.net/~pli/rfr/8216259/TestAdler32.java > > The optimization shows ~5x improvement. > > Base: > Benchmark (count) Mode Cnt Score Error Units > TestAdler32Perf.testAdler32Update 64 avgt 25 0.084 ? 0.001 us/op > TestAdler32Perf.testAdler32Update 128 avgt 25 0.104 ? 0.001 us/op > TestAdler32Perf.testAdler32Update 256 avgt 25 0.146 ? 0.002 us/op > TestAdler32Perf.testAdler32Update 512 avgt 25 0.226 ? 0.002 us/op > TestAdler32Perf.testAdler32Update 1024 avgt 25 0.390 ? 0.005 us/op > TestAdler32Perf.testAdler32Update 2048 avgt 25 0.714 ? 0.007 us/op > TestAdler32Perf.testAdler32Update 4096 avgt 25 1.359 ? 0.014 us/op > TestAdler32Perf.testAdler32Update 8192 avgt 25 2.751 ? 0.023 us/op > TestAdler32Perf.testAdler32Update 16384 avgt 25 5.494 ? 0.077 us/op > TestAdler32Perf.testAdler32Update 32768 avgt 25 11.058 ? 0.160 us/op > TestAdler32Perf.testAdler32Update 65536 avgt 25 22.198 ? 0.319 us/op > > > With patch: > Benchmark (count) Mode Cnt Score Error Units > TestAdler32Perf.testAdler32Update 64 avgt 25 0.020 ? 0.001 us/op > TestAdler32Perf.testAdler32Update 128 avgt 25 0.025 ? 0.001 us/op > TestAdler32Perf.testAdler32Update 256 avgt 25 0.031 ? 0.001 us/op > TestAdler32Perf.testAdler32Update 512 avgt 25 0.048 ? 0.001 us/op > TestAdler32Perf.testAdler32Update 1024 avgt 25 0.078 ? 0.001 us/op > TestAdler32Perf.testAdler32Update 2048 avgt 25 0.139 ? 0.002 us/op > TestAdler32Perf.testAdler32Update 4096 avgt 25 0.262 ? 0.004 us/op > TestAdler32Perf.testAdler32Update 8192 avgt 25 0.524 ? 0.010 us/op > TestAdler32Perf.testAdler32Update 16384 avgt 25 1.017 ? 0.022 us/op > TestAdler32Perf.testAdler32Update 32768 avgt 25 2.058 ? 0.052 us/op > TestAdler32Perf.testAdler32Update 65536 avgt 25 3.994 ? 0.013 us/op Xubo Zhang has updated the pull request incrementally with one additional commit since the last revision: set flag UseAdler32Intrinsics differently to based on 64 or 32-bit modes. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3806/files - new: https://git.openjdk.java.net/jdk/pull/3806/files/9d8e0230..57ec0b8c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3806&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3806&range=01-02 Stats: 12 lines in 4 files changed: 7 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3806.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3806/head:pull/3806 PR: https://git.openjdk.java.net/jdk/pull/3806 From vlivanov at openjdk.java.net Fri Apr 30 21:47:52 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Fri, 30 Apr 2021 21:47:52 GMT Subject: RFR: 8266074: Vtable-based CHA implementation In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 20:08:39 GMT, John R Rose wrote: >> As of now, Class Hierarchy Analysis (CHA) employs an approximate algorithm to enumerate all non-abstract methods in a class hierarchy. >> >> It served quite well for many years, but it accumulated significant complexity >> to support different corner cases over time and inevitable evolution of the JVM >> stretched the whole approach way too much (to the point where it become almost >> impossible to extend the analysis any further). >> >> It turns out the root problem is the decision to reimplement method resolution >> and method selection logic from scratch and to perform it on JVM internal >> representation. It makes it very hard to reason about correctness and the >> implementation becomes sensitive to changes in internal representation. >> >> So, the main motivation for the redesign is twofold: >> * reduce maintenance burden and increase confidence in the code; >> * unlock some long-awaited enhancements. >> >> Though I did experiment with relaxing existing constraints (e.g., enable default method support), >> any possible enhancements are deliberately kept out of scope for the current PR. >> (It does deliver a bit of minor enhancements front as the changes in >> compiler/cha/StrengthReduceInterfaceCall.java manifest, but it's a side effect >> of the other changes and was not the goal of the current work.) >> >> Proposed implementation (`LinkedConcreteMethodFinder`) mimics method invocation >> and relies on vtable/itable information to detect target method for every >> subclass it visits. It removes all the complexity associated with method >> resolution and method selection logic and leaves only essential logic to prepare for method selection. >> >> Vtables are filled during class linkage, so new logic doesn't work on not yet linked classed. >> Instead of supporting not yet linked case, it is simply ignored. It is safe to >> skip them (treat as "effectively non-concrete") since it is guaranteed there >> are no instances created yet. But it requires VM to check dependencies once a >> class is linked. >> >> I ended up with 2 separate dependency validation passes (when class is loaded >> and when it is linked). To avoid duplicated work, only dependencies >> which may be affected by class initialization state change >> (`unique_concrete_method_4`) are visited. >> >> (I experimented with merging passes into a single pass (delay the pass until >> linkage is over), but it severely affected other class-related dependencies and >> relevant optimizations.code.) >> >> Compiler Interface (CI) is changed to require users to provide complete information about the call site being analyzed. >> >> Old implementation is kept intact for now (will be removed later) to: >> - JVMCI hasn't been migrated to the new implementation yet; >> - enable verification that 2 implementations (old and new) agree on the results; >> - temporarily keep an option to revert to the original implementation in case any regressions show up. >> >> Testing: >> - [x] hs-tier1 - hs-tier9 >> - [x] hs-tier1 - hs-tier4 w/ `-XX:-UseVtableBasedCHA` >> - [x] performance testing >> >> Thanks! > > src/hotspot/share/code/dependencies.cpp line 1521: > >> 1519: selected_method = recv_klass->method_at_itable_or_null(_declaring_klass, _vtable_index, >> 1520: implements_interface); // out parameter >> 1521: assert(implements_interface, "not implemented"); > > Looking at `recv_klass->method_at_itable_or_null`, I wonder if there can be ?holes? in the itable for missing methods. They would lead to `AME` if called. They might also trigger your assert here: `assert(implements_interface, "not implemented")`. Is there some reason that `select_method` cannot possibly encounter a missing method? > > Answer to self: I don't remember whether the JVM creates itable methods on the fly, but I suppose it does, so the code would see an synthetic abstract method. (Decades ago we named those Miranda Methods because if you don't have a responding method "one will be provided for you".) And itables are just aliases of vtable slices, so the miranda placed in the vtable will be seen also in the itable. > > (Overall comment on this area of the code: It looks great, much better than when I touched it last. Thanks!) Regarding "holes" in itables: yes, it happens in practice. `select_method` is allowed to return a `NULL` and it is used by `LinkedConcreteMethodFinder` as a sentinel value for `AME` (when placed in `_found_methods` array). That's why `Dependencies::find_unique_concrete_method()` check `participant(0)`: Method* fm = wf.found_method(0); // Will be NULL if num_parts == 0. Klass* p = wf.participant(0); // Will be NULL if num_parts == 0. ... if (Dependencies::is_concrete_method(m, ctxk)) { if (fm == NULL && p == NULL) { // It turns out that m was always the only implementation. fm = m; } Now I think that it's not clear enough from the code. I'll elaborate on it in the additional comments. ------------- PR: https://git.openjdk.java.net/jdk/pull/3727 From vlivanov at openjdk.java.net Fri Apr 30 21:51:54 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Fri, 30 Apr 2021 21:51:54 GMT Subject: RFR: 8266074: Vtable-based CHA implementation In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 21:44:34 GMT, Vladimir Ivanov wrote: >> src/hotspot/share/code/dependencies.cpp line 1521: >> >>> 1519: selected_method = recv_klass->method_at_itable_or_null(_declaring_klass, _vtable_index, >>> 1520: implements_interface); // out parameter >>> 1521: assert(implements_interface, "not implemented"); >> >> Looking at `recv_klass->method_at_itable_or_null`, I wonder if there can be ?holes? in the itable for missing methods. They would lead to `AME` if called. They might also trigger your assert here: `assert(implements_interface, "not implemented")`. Is there some reason that `select_method` cannot possibly encounter a missing method? >> >> Answer to self: I don't remember whether the JVM creates itable methods on the fly, but I suppose it does, so the code would see an synthetic abstract method. (Decades ago we named those Miranda Methods because if you don't have a responding method "one will be provided for you".) And itables are just aliases of vtable slices, so the miranda placed in the vtable will be seen also in the itable. >> >> (Overall comment on this area of the code: It looks great, much better than when I touched it last. Thanks!) > > Regarding "holes" in itables: yes, it happens in practice. `select_method` is allowed to return a `NULL` and it is used by `LinkedConcreteMethodFinder` as a sentinel value for `AME` (when placed in `_found_methods` array). That's why `Dependencies::find_unique_concrete_method()` check `participant(0)`: > > Method* fm = wf.found_method(0); // Will be NULL if num_parts == 0. > Klass* p = wf.participant(0); // Will be NULL if num_parts == 0. > ... > if (Dependencies::is_concrete_method(m, ctxk)) { > if (fm == NULL && p == NULL) { > // It turns out that m was always the only implementation. > fm = m; > } > > > Now I think that it's not clear enough from the code. I'll elaborate on it in the additional comments. Regarding the assert: the itable should always be found. First, because only implementors are enumerated during the analysis (currently, subclasses of the unique direct implementor). Second, because itable stubs rely on itable contents when performing receiver subtype checks. So, all superinterfaces should have a corresponding itable present (even an empty one). ------------- PR: https://git.openjdk.java.net/jdk/pull/3727 From vlivanov at openjdk.java.net Fri Apr 30 22:05:52 2021 From: vlivanov at openjdk.java.net (Vladimir Ivanov) Date: Fri, 30 Apr 2021 22:05:52 GMT Subject: RFR: 8266074: Vtable-based CHA implementation In-Reply-To: References: <5GRZsKzjv3hRaV9LNgp2tQIaAmsUbIbGr4xGQDdkwus=.77bed390-12c6-4526-b8b1-c68f736b7c1c@github.com> Message-ID: <3Z7vXPRkLnBKfv84VVtXJI--I16HgEjydFtQflXkUBE=.44f5daab-6b9c-4e56-9aac-345b9b4d3a07@github.com> On Fri, 30 Apr 2021 20:13:19 GMT, Vladimir Kozlov wrote: >> The test assumes `UseVtableBasedCHA` is on and some of the assertions it makes fail with `-XX:-UseVtableBasedCHA`. So, it would require all the changes in the test logic have to be guarded by a check whether UseVtableBasedCHA is on or off. >> >> Considering `UseVtableBasedCHA` is turned on by default in the PR, I don't see much value in complicating the test. > > So only new implementation is tested with these changes in test. Got it. May be use: > `@requires vm.opt.final.UseVtableBasedCHA == true` I'm fine with both approaches. Explicitly setting the flag looked to me more robust and clearer communicating the intent. But if you prefer `@requires`, I'll use it. ------------- PR: https://git.openjdk.java.net/jdk/pull/3727 From kvn at openjdk.java.net Fri Apr 30 22:12:52 2021 From: kvn at openjdk.java.net (Vladimir Kozlov) Date: Fri, 30 Apr 2021 22:12:52 GMT Subject: RFR: 8266074: Vtable-based CHA implementation In-Reply-To: <3Z7vXPRkLnBKfv84VVtXJI--I16HgEjydFtQflXkUBE=.44f5daab-6b9c-4e56-9aac-345b9b4d3a07@github.com> References: <5GRZsKzjv3hRaV9LNgp2tQIaAmsUbIbGr4xGQDdkwus=.77bed390-12c6-4526-b8b1-c68f736b7c1c@github.com> <3Z7vXPRkLnBKfv84VVtXJI--I16HgEjydFtQflXkUBE=.44f5daab-6b9c-4e56-9aac-345b9b4d3a07@github.com> Message-ID: On Fri, 30 Apr 2021 22:03:11 GMT, Vladimir Ivanov wrote: >> So only new implementation is tested with these changes in test. Got it. May be use: >> `@requires vm.opt.final.UseVtableBasedCHA == true` > > I'm fine with both approaches. > > Explicitly setting the flag looked to me more robust and clearer communicating the intent. But if you prefer `@requires`, I'll use it. Let hear @iignatev opinion. ------------- PR: https://git.openjdk.java.net/jdk/pull/3727